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.
EVALUATION
Currently testing backported fix on Ultra-II - customer saw issue on a SunFire-E6900 (SunOS 9)
02-05-2006
EVALUATION
Has this occurred since then?
###@###.### 2003-08-14
It still happened as of build b15.
###@###.### 2003-08-19
This seems to be an impossible failure in the signature iterator. I've added debug code which would tell us what happened if it occurs again but it hasn't been so I'm closing this as not reproducible for now.
###@###.### 2003-10-02
The bug is reproducible with tiger b23 after 3 days 9 hours ( I ran
4 bigapps in parallel )
###@###.### 2003-10-14
In the failing case the fingerprint as reported by the printing code I added to iterate_paramters is 0x00000000532ab338 but from looking at the core file, the fingerprint in the methodOop is 0x00000001532ab338, so the high word at the time it was read was still 0. methodOopDesc::set_fingerprint isn't thread safe since longs aren't guaranteed to be stored in a single atomic instruction. One thread can see half of the store and pass the test below, returning half of the fingerprint with the other half 0.
if ( mh->fingerprint() != CONST64(0) ) return mh->fingerprint();
###@###.### 2003-10-16
Using Atomic::cmpxchg (compare and exchange) jlong version to update
fingerprint field and check that the value either matches the fingerprint
value given or zero. There's no Atomic::store(jlong) defined for x86 so that's
why I didn't use that. I don't think I need an atomic read operation but maybe
_fingerprint field should be made volatile.
###@###.### 2003-11-04
4871438 methodOopDesc::set_fingerprint isn't thread safe
The C++ compiler doesn't generate atomic instructions for 64 bit sized
fields. One such field is _fingerprint in constMethodOopDesc. This field
is updated during execution when it is needed. It doesn't use a lock
because once the value is set, any other setters will reset it to the same
value if there is a race. Unfortunately, the setting instruction was not
atomic. If the compiler had generated a ldd for the field, the V9 manual
says it is atomic. Instead with -xarch=v8 (-client setting because client
still has to support v8) and -xarch=v8plus (-server setting), the C++
compiler generates two 32 bit loads to store the field.
The C++ compiler default is -xmemalign=4s (align to 4 bytes, signal unaligned).
They realize that they could generate better code and change the default
but are evaluating the effect on user libraries. We could change the VM
to use -xmemalign=8s but there might be problems with our code that reads
class files. We could try this out next release. (Thanks to
###@###.### for the explanation of this).
To fix, I use a known initial value and check both words against that
value to determine if the entire write has taken place before returning
the fingerprint. Otherwise, it returns zero. This doesn't rely on Atomic
operations (which doesn't work on LInux - another bug) or the alignment
of the field (which should always be aligned).
###@###.### 2003-11-14
*** (#1 of 1): 2004-06-11 08:43:03 PDT ###@###.###