Is WorkAroundNPTLTimedWaitHang safe to disable?

[David Holmes]

David Dabbs said the following on 09/10/10 12:10:
> There is a Linux-specific VM product flag, WorkAroundNPTLTimedWaitHang.
> The comments in src/share/vm/runtime/globals.hpp describe the flag as 
> 
> 	(Unstable, Linux-specific) "avoid NPTL-FUTEX hang
> pthread_cond_timedwait"
> 
> Would this be a workaround for this issue?  
> 
> 	https://bugzilla.redhat.com/show_bug.cgi?id=217067

No it predates that issue by several years. See the comments in 
os_linux.cpp:

// 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.

> In any case, are there are guidelines for safely disabling this workaround?
> Guidelines, e.g. libc version, vendor.kernel.version, et cetera.

We have not tracked this. Given the widespread Linux/glibc versions 
people use, these workarounds tend to have to stay around a long time. A 
lot of code cleanups would be possible if we enforced a minimum 
kerbel+glibc version.

David Holmes




> 
> Many thanks,
> 
> David
> 
>