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

[David Holmes]

Hi Vladimir,

On 11/02/2016 4: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.

Are entries ever removed from the list?

The multi-threading aspects of this code are unclear. The on demand 
nature of method handle adapters may be exposing this code to 
concurrency issues that the code doesn't expect. ??

Thanks,
David

>
> (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