JDK-6948537 : CMS: BOT walkers observe out-of-thin-air zeros on sun4v sparc/CMT
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs17,6u19
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris,solaris_10
  • CPU: sparc
  • Submitted: 2010-04-29
  • Updated: 2014-05-12
  • Resolved: 2011-03-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other JDK 6 JDK 7 Other
1.4.2_31,hs17Fixed 6u21-revFixed 7Fixed hs17Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
BOT bulk-updates use memset(). However on Niagara memset() uses BIS
for speed and this exposes concurrent readers to out-of-thin-air zeroes,
which are fatal for concurrent BOT walks. Such concurrent reads of
BOT entries subject to concurrent update are possible with non-contiguous
spaces such as CMS (but not any other current GC in HotSpot).

Comments
For this fix to work we need to properly detect the actual CPU version. For the new SPARC-M series this detection was broken until "7188227: VM should recognize M-series SPARC" (https://bugs.openjdk.java.net/browse/JDK-7188227) was fixed.
14-10-2013

EVALUATION http://hg.openjdk.java.net/hsx/hsx17/baseline/rev/47d6ab4dec3b
22-04-2011

EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/3bfae429e2cf
03-05-2010

EVALUATION As far as i can tell, a day-one bug that was in the JVM waiting for the use of BIS by memset() to happen.
03-05-2010

EVALUATION As in description and suggested fix.
29-04-2010

WORK AROUND A big-hammer workaround that doesn't use the optimized libc_psr memset() is:- export LD_NOAUXFLTR=1 This may reduce performance of the JVM in general and of native code using memset() in particular. CAVEAT: if your application uses native code that depends on auxiliary filters on certrain platforms for correctness, such aplications may even break when auxiliary filters are turned off above.
29-04-2010

SUGGESTED FIX Preliminary webrev, under perf and test:- http://analemma.sfbay.sun.com/net/neeraja/export/ysr/memset/webrev/ When using CMS on sparc4v, do not use sparc4v-specific optimized memset() for BOT updates.
29-04-2010