Request for reviews (XS): 7011386: race in objArrayKlass::array_klass_impl (original) (raw)

Vladimir Kozlov vladimir.kozlov at oracle.com
Tue Jan 11 11:15:40 PST 2011

Tom,

Using oop_store() instead of oop_store_without_check() will generate barriers but it is overkill. I think marking receiver as volatile should be enough:

void set_higher_dimension(klassOop k) volatile { oop_store_without_check((oop*) &_higher_dimension, (oop) k); } void set_lower_dimension(klassOop k) volatile { oop_store_without_check((oop*) &_lower_dimension, (oop) k); }

Thanks, Vladimir

Tom Rodriguez wrote:

That look good, though I keep wondering if we need a barrier in between or if those fields really should be volatile. It seems like we're playing a little loose with the locking for these lazy values.

tom On Jan 11, 2011, at 9:54 AM, Vladimir Kozlov wrote:

http://cr.openjdk.java.net/~kvn/7011386/webrev

Fixed 7011386: race in objArrayKlass::arrayklassimpl Other threads may access lowerdimension field before it is initialized by thread which holds the lock in objArrayKlass::arrayklassimpl(). Move lowerdimension field initialization before higherdimension.

More information about the hotspot-runtime-dev mailing list