United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 6948537 CMS: BOT walkers observe out-of-thin-air zeros on sun4v sparc/CMT
6948537 : CMS: BOT walkers observe out-of-thin-air zeros on sun4v sparc/CMT

Details
Type:
Bug
Submit Date:
2010-04-29
Status:
Closed
Updated Date:
2012-04-18
Project Name:
JDK
Resolved Date:
2011-03-07
Component:
hotspot
OS:
solaris,solaris_10
Sub-Component:
gc
CPU:
sparc
Priority:
P2
Resolution:
Fixed
Affected Versions:
hs17,6u19
Fixed Versions:
hs19

Related Reports
Backport:
JDK-2199774 - CMS: BOT walkers observe out-of-thin-air zeros on sun4v sparc/CMT
Backport:
JDK-2193020 - CMS: BOT walkers observe out-of-thin-air zeros on sun4v sparc/CMT
Backport:
JDK-2193339 - CMS: BOT walkers observe out-of-thin-air zeros on sun4v sparc/CMT
Backport:
JDK-2195904 - CMS: BOT walkers observe out-of-thin-air zeros on sun4v sparc/CMT
Backport:
JDK-2199484 - CMS: BOT walkers observe out-of-thin-air zeros on sun4v sparc/CMT
Backport:
JDK-2197874 - CMS: BOT walkers observe out-of-thin-air zeros on sun4v sparc/CMT
Backport:
JDK-2204492 - CMS: BOT walkers observe out-of-thin-air zeros on sun4v sparc/CMT
Backport:
JDK-2204491 - CMS: BOT walkers observe out-of-thin-air zeros on sun4v sparc/CMT
Backport:
JDK-2197580 - CMS: BOT walkers observe out-of-thin-air zeros on sun4v sparc/CMT
Relates:
JDK-7192128 - G1: Extend fix for 6948537 to G1's BOT
Relates:
JDK-6955836 - BVF for the bug 6872049
Relates:
JDK-6872049 - CMS: Failure in CompactibleFreeListSpace::block_size from ::block_start_unsafe()

Sub Tasks

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
EVALUATION

http://hg.openjdk.java.net/hsx/hsx17/baseline/rev/47d6ab4dec3b
2011-04-22 
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.
2010-05-03 
EVALUATION

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

As in description and suggested fix.
2010-04-29 
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.
2010-04-29 
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.
2010-04-29


Hardware and Software, Engineered to Work Together