8079125: [aix] clean up Linux-specific code remnants in AIX coding
authorstuefe
Thu, 17 Dec 2015 08:23:51 +0100
changeset 35180 298594487e08
parent 35179 9e364645fdca
child 35181 06f0c4c4d10b
child 35185 31b4d3da482f
8079125: [aix] clean up Linux-specific code remnants in AIX coding Reviewed-by: goetz
hotspot/src/os/aix/vm/attachListener_aix.cpp
hotspot/src/os/aix/vm/jvm_aix.h
hotspot/src/os/aix/vm/osThread_aix.hpp
hotspot/src/os/aix/vm/os_aix.cpp
hotspot/src/os/aix/vm/os_aix.inline.hpp
hotspot/src/os/aix/vm/perfMemory_aix.cpp
--- a/hotspot/src/os/aix/vm/attachListener_aix.cpp	Wed Dec 16 19:30:10 2015 -0800
+++ b/hotspot/src/os/aix/vm/attachListener_aix.cpp	Thu Dec 17 08:23:51 2015 +0100
@@ -40,7 +40,7 @@
 #define UNIX_PATH_MAX   sizeof(((struct sockaddr_un *)0)->sun_path)
 #endif
 
-// The attach mechanism on Linux uses a UNIX domain socket. An attach listener
+// The attach mechanism on AIX  uses a UNIX domain socket. An attach listener
 // thread is created at startup or is created on-demand via a signal from
 // the client tool. The attach listener creates a socket and binds it to a file
 // in the filesystem. The attach listener then acts as a simple (single-
@@ -349,7 +349,7 @@
 
 // Dequeue an operation
 //
-// In the Linux implementation there is only a single operation and clients
+// In the Aix implementation there is only a single operation and clients
 // cannot queue commands (except at the socket level).
 //
 AixAttachOperation* AixAttachListener::dequeue() {
--- a/hotspot/src/os/aix/vm/jvm_aix.h	Wed Dec 16 19:30:10 2015 -0800
+++ b/hotspot/src/os/aix/vm/jvm_aix.h	Thu Dec 17 08:23:51 2015 +0100
@@ -81,11 +81,7 @@
 #define JNI_LIB_PREFIX "lib"
 #define JNI_LIB_SUFFIX ".so"
 
-// Hack: MAXPATHLEN is 4095 on some Linux and 4096 on others. This may
-//       cause problems if JVM and the rest of JDK are built on different
-//       Linux releases. Here we define JVM_MAXPATHLEN to be MAXPATHLEN + 1,
-//       so buffers declared in VM are always >= 4096.
-#define JVM_MAXPATHLEN MAXPATHLEN + 1
+#define JVM_MAXPATHLEN MAXPATHLEN
 
 #define JVM_R_OK    R_OK
 #define JVM_W_OK    W_OK
--- a/hotspot/src/os/aix/vm/osThread_aix.hpp	Wed Dec 16 19:30:10 2015 -0800
+++ b/hotspot/src/os/aix/vm/osThread_aix.hpp	Thu Dec 17 08:23:51 2015 +0100
@@ -87,7 +87,7 @@
   // ***************************************************************
 
  public:
-  // flags that support signal based suspend/resume on Linux are in a
+  // flags that support signal based suspend/resume on Aix are in a
   // separate class to avoid confusion with many flags in OSThread that
   // are used by VM level suspend/resume.
   os::SuspendResume sr;
--- a/hotspot/src/os/aix/vm/os_aix.cpp	Wed Dec 16 19:30:10 2015 -0800
+++ b/hotspot/src/os/aix/vm/os_aix.cpp	Thu Dec 17 08:23:51 2015 +0100
@@ -2875,10 +2875,6 @@
   act.sa_handler = (void (*)(int)) SR_handler;
 
   // SR_signum is blocked by default.
-  // 4528190 - We also need to block pthread restart signal (32 on all
-  // supported Linux platforms). Note that LinuxThreads need to block
-  // this signal for all threads to work properly. So we don't have
-  // to use hard-coded signal number when setting up the mask.
   pthread_sigmask(SIG_BLOCK, NULL, &act.sa_mask);
 
   if (sigaction(SR_signum, &act, 0) == -1) {
@@ -4497,62 +4493,6 @@
 }
 
 // Refer to the comments in os_solaris.cpp park-unpark.
-//
-// Beware -- Some versions of NPTL embody a flaw where pthread_cond_timedwait() can
-// hang indefinitely. For instance NPTL 0.60 on 2.4.21-4ELsmp is vulnerable.
-// For specifics regarding the bug see GLIBC BUGID 261237 :
-//    http://www.mail-archive.com/debian-glibc@lists.debian.org/msg10837.html.
-// Briefly, pthread_cond_timedwait() calls with an expiry time that's not in the future
-// will either hang or corrupt the condvar, resulting in subsequent hangs if the condvar
-// is used. (The simple C test-case provided in the GLIBC bug report manifests the
-// hang). The JVM is vulernable via sleep(), Object.wait(timo), LockSupport.parkNanos()
-// and monitorenter when we're using 1-0 locking. All those operations may result in
-// calls to pthread_cond_timedwait(). Using LD_ASSUME_KERNEL to use an older version
-// of libpthread avoids the problem, but isn't practical.
-//
-// Possible remedies:
-//
-// 1.   Establish a minimum relative wait time. 50 to 100 msecs seems to work.
-//      This is palliative and probabilistic, however. If the thread is preempted
-//      between the call to compute_abstime() and pthread_cond_timedwait(), more
-//      than the minimum period may have passed, and the abstime may be stale (in the
-//      past) resultin in a hang. Using this technique reduces the odds of a hang
-//      but the JVM is still vulnerable, particularly on heavily loaded systems.
-//
-// 2.   Modify park-unpark to use per-thread (per ParkEvent) pipe-pairs instead
-//      of the usual flag-condvar-mutex idiom. The write side of the pipe is set
-//      NDELAY. unpark() reduces to write(), park() reduces to read() and park(timo)
-//      reduces to poll()+read(). This works well, but consumes 2 FDs per extant
-//      thread.
-//
-// 3.   Embargo pthread_cond_timedwait() and implement a native "chron" thread
-//      that manages timeouts. We'd emulate pthread_cond_timedwait() by enqueuing
-//      a timeout request to the chron thread and then blocking via pthread_cond_wait().
-//      This also works well. In fact it avoids kernel-level scalability impediments
-//      on certain platforms that don't handle lots of active pthread_cond_timedwait()
-//      timers in a graceful fashion.
-//
-// 4.   When the abstime value is in the past it appears that control returns
-//      correctly from pthread_cond_timedwait(), but the condvar is left corrupt.
-//      Subsequent timedwait/wait calls may hang indefinitely. Given that, we
-//      can avoid the problem by reinitializing the condvar -- by cond_destroy()
-//      followed by cond_init() -- after all calls to pthread_cond_timedwait().
-//      It may be possible to avoid reinitialization by checking the return
-//      value from pthread_cond_timedwait(). In addition to reinitializing the
-//      condvar we must establish the invariant that cond_signal() is only called
-//      within critical sections protected by the adjunct mutex. This prevents
-//      cond_signal() from "seeing" a condvar that's in the midst of being
-//      reinitialized or that is corrupt. Sadly, this invariant obviates the
-//      desirable signal-after-unlock optimization that avoids futile context switching.
-//
-//      I'm also concerned that some versions of NTPL might allocate an auxilliary
-//      structure when a condvar is used or initialized. cond_destroy() would
-//      release the helper structure. Our reinitialize-after-timedwait fix
-//      put excessive stress on malloc/free and locks protecting the c-heap.
-//
-// We currently use (4). See the WorkAroundNTPLTimedWaitHang flag.
-// It may be possible to refine (4) by checking the kernel and NTPL verisons
-// and only enabling the work-around for vulnerable environments.
 
 // utility to compute the abstime argument to timedwait:
 // millis is the relative timeout time
@@ -4856,10 +4796,6 @@
     status = pthread_cond_wait (_cond, _mutex);
   } else {
     status = pthread_cond_timedwait (_cond, _mutex, &absTime);
-    if (status != 0 && WorkAroundNPTLTimedWaitHang) {
-      pthread_cond_destroy (_cond);
-      pthread_cond_init    (_cond, NULL);
-    }
   }
   assert_status(status == 0 || status == EINTR ||
                 status == ETIME || status == ETIMEDOUT,
@@ -4887,17 +4823,10 @@
   s = _counter;
   _counter = 1;
   if (s < 1) {
-    if (WorkAroundNPTLTimedWaitHang) {
-      status = pthread_cond_signal (_cond);
-      assert (status == 0, "invariant");
-      status = pthread_mutex_unlock(_mutex);
-      assert (status == 0, "invariant");
-    } else {
-      status = pthread_mutex_unlock(_mutex);
-      assert (status == 0, "invariant");
-      status = pthread_cond_signal (_cond);
-      assert (status == 0, "invariant");
-    }
+    status = pthread_mutex_unlock(_mutex);
+    assert (status == 0, "invariant");
+    status = pthread_cond_signal (_cond);
+    assert (status == 0, "invariant");
   } else {
     pthread_mutex_unlock(_mutex);
     assert (status == 0, "invariant");
--- a/hotspot/src/os/aix/vm/os_aix.inline.hpp	Wed Dec 16 19:30:10 2015 -0800
+++ b/hotspot/src/os/aix/vm/os_aix.inline.hpp	Thu Dec 17 08:23:51 2015 +0100
@@ -102,19 +102,15 @@
 }
 
 inline struct dirent* os::readdir(DIR* dirp, dirent *dbuf) {
-  dirent* p;
-  int status;
+  dirent* p = NULL;
   assert(dirp != NULL, "just checking");
 
-  // NOTE: Linux readdir_r (on RH 6.2 and 7.2 at least) is NOT like the POSIX
-  // version. Here is the doc for this function:
-  // http://www.gnu.org/manual/glibc-2.2.3/html_node/libc_262.html
-
-  if((status = ::readdir_r(dirp, dbuf, &p)) != 0) {
-    errno = status;
+  // AIX: slightly different from POSIX.
+  // On AIX, readdir_r returns 0 or != 0 and error details in errno.
+  if (::readdir_r(dirp, dbuf, &p) != 0) {
     return NULL;
-  } else
-    return p;
+  }
+  return p;
 }
 
 inline int os::closedir(DIR *dirp) {
--- a/hotspot/src/os/aix/vm/perfMemory_aix.cpp	Wed Dec 16 19:30:10 2015 -0800
+++ b/hotspot/src/os/aix/vm/perfMemory_aix.cpp	Thu Dec 17 08:23:51 2015 +0100
@@ -532,7 +532,6 @@
 
   char* pwbuf = NEW_C_HEAP_ARRAY(char, bufsize, mtInternal);
 
-  // POSIX interface to getpwuid_r is used on LINUX
   struct passwd* p;
   int result = getpwuid_r(uid, &pwent, pwbuf, (size_t)bufsize, &p);
 
@@ -983,7 +982,7 @@
 // memory region on success or NULL on failure. A return value of
 // NULL will ultimately disable the shared memory feature.
 //
-// On Solaris and Linux, the name space for shared memory objects
+// On AIX, Solaris and Linux, the name space for shared memory objects
 // is the file system name space.
 //
 // A monitoring application attaching to a JVM does not need to know