United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4930919 race condition in MDO creation at back branch locations
JDK-4930919 : race condition in MDO creation at back branch locations

Details
Type:
Bug
Submit Date:
2003-10-01
Status:
Closed
Updated Date:
2011-04-23
Project Name:
JDK
Resolved Date:
2011-04-23
Component:
hotspot
OS:
generic
Sub-Component:
compiler
CPU:
generic
Priority:
P4
Resolution:
Fixed
Affected Versions:
6
Fixed Versions:
hs20 (b07)

Related Reports
Backport:
Backport:
Relates:

Sub Tasks

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
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
                                     
2003-10-01
EVALUATION

The description provides a fairly complete evaluation even without a test case.

###@###.### 2003-10-01
                                     
2003-10-01
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
mustang


                                     
2004-06-14
EVALUATION

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



Hardware and Software, Engineered to Work Together