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

[Vladimir Ivanov]

Vladimir, David, Andrew, thanks again for the feedback.

Updated version:
   http://cr.openjdk.java.net/~vlivanov/8138922/webrev.01

I moved method handle adapters generation to VM init phase and added 
verification logic to ensure there are no modifications to the 
StubCodeDesc::_list after that.

Also, slightly refactored java.lang.invoke initialization logic.

Best regards,
Vladimir Ivanov

On 2/10/16 9:13 PM, 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