Is WorkAroundNPTLTimedWaitHang safe to disable?

David Holmes David.Holmes at
Thu Sep 9 19:39:03 PDT 2010

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?  

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

// 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 
// For specifics regarding the bug see GLIBC BUGID 261237 :
// 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), 
// 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

More information about the hotspot-dev mailing list