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.