[9] RFR (XS): 8138922: StubCodeDesc constructor publishes partially-constructed objects on StubCodeDesc::_list

[Vladimir Kozlov]

Static ++_count could be also problem since you incremented it before adding 'this' to list. Can you look?

Should we go though all our static fields and see if they have the same concurrent access problem?

Thanks,
Vladimir K

On 2/10/16 10:13 AM, Vladimir Ivanov wrote:
> http://cr.openjdk.java.net/~vlivanov/8138922/webrev.00
> https://bugs.openjdk.java.net/browse/JDK-8138922
>
> StubCodeDesc keeps a list of all descriptors rooted at StubCodeDesc::_list by placing newly instantiated objects there
> at the end of the constructor. Unfortunately, it doesn't guarantee that only fully-constructed objects are visible,
> because compiler (or HW) can reorder the stores.
>
> Since method handle adapters are generated on demand when j.l.i framework is initialized, it's possible there are
> readers iterating over the list at the moment. It's not a problem per se until everybody sees a consistent view of the
> list.
>
> The fix is to insert a StoreStore barrier before registering an object on the list.
>
> (I also considered moving MH adapter allocation to VM initialization phase before anybody reads the list, but it's
> non-trivial since MethodHandles::generate_adapters() has a number of implicit dependencies.)
>
> Testing: manual (verified StubCodeMark assembly), JPRT
>
> Thanks!
>
> Best regards,
> Vladimir Ivanov