JDK-2135281 : methodOopDesc::set_fingerprint isn't thread safe
  • Type: Backport
  • Backport of: JDK-4871438
  • Component: hotspot
  • Sub-Component: runtime
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2006-03-03
  • Updated: 2012-10-13
  • Resolved: 2006-06-26
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
1.4.2_13 b01Fixed
Comments
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 ###@###.###
04-03-2006