JDK-4930919 : race condition in MDO creation at back branch locations
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 6
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2003-10-01
  • Updated: 2011-04-23
  • Resolved: 2011-04-23
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.
JDK 6 JDK 7 Other
6u25Fixed 7Fixed hs20Fixed
Related Reports
Relates :  
Description
From Cliff Click (###@###.###)

I slightly optimized the creation of MDO's to better handle high contention
and took the existing race condition and made it much more common, but
the race exists in the current source drops of 1.5 and 1.4.2.  I get
this race condition all the time with fastdebug 32-bit Sparc running Volano on a
30-way US2 box.  It's much rarer on a faster box but it still happens.


200 threads are created and immediate begin executing the same method.
It rapidly hits the create-an-mdo state, and calls into the VM via
profile_interpreter.  Most (not all) of the 200 threads rush into the VM to
do this call.  There's a winner at the lock; the winner reports FAILURE
to create the MDO (in my system, contention will also report failure which
is how my race condition becomes common).

The failing thread returns a 0 from InterpreterRuntime::profile_method.

Switch to another of 200 threads; it runs into profile_method, takes the
lock and this time succeeds in making the MDO.  The MDO is stored
in the methodOop.

Back to the first failing thread.  Back in the interpreter, it calls
'set_method_data_pointer_offset' with the O0 argument.  This is
the only place that happens.  O0 is 0 (no MDO at the time profile_method
was called).  But it re-loads the MDO and discovers it's there.

set_method_data_pointer_offset then makes an MDI using an offset
of 0 instead of a proper offset.  You die sometime later.

Root cause of bug: querying the MDO field twice and expecting the same
answer both times.  First time is in the VM, in profile_method; second time
is an the ASM code, in set_method_data_pointer_offset.

Comments
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/dd031b2226de
11-01-2011

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mustang
14-06-2004

SUGGESTED FIX The profile_method() function could return an illegal (negative) value when no MDO is found. Then set_method_data_pointer() can avoid setting the mdp if it sees a negative offset. ###@###.### 2003-10-01
01-10-2003

EVALUATION The description provides a fairly complete evaluation even without a test case. ###@###.### 2003-10-01
01-10-2003