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

[David Holmes]

Hi Vladimir,

On 12/02/2016 11:13 PM, Vladimir Ivanov wrote:
> 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.

That sounds good in principle, but this is not an area of the code I am 
familiar with.

Thanks,
David

> 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