RFR (S) 8031818: Experimental VM flag for enforcing safe object construction

[Vladimir Kozlov]

On 1/30/14 2:54 PM, Aleksey Shipilev wrote:
> Yes we can.
> Do you want me to do this in this CR?

Yes, please.

Thanks,
Vladimir

>
> -Aleksey.
>
> On 01/31/2014 02:47 AM, Vladimir Kozlov wrote:
>> Can we simple separate stable stores to wrote_stable() with own code in
>> do_exit() and comments?
>>
>> Thanks,
>> Vladimir K
>>
>> On 1/30/14 2:14 PM, Aleksey Shipilev wrote:
>>> On 01/31/2014 01:53 AM, Vladimir Kozlov wrote:
>>>> hs-comp is closed for almost 2 weeks until SQE done all testing. Only
>>>> ppc merge related fixes are allowed.
>>>
>>> Understood, no pressure.
>>>
>>>> You check is_initializer() for all types of fields in do_exits(). But
>>>> is_final() is also set for @Stable field which could any methods based
>>>> on the comment in do_put_xxx().
>>>
>>> Well, that's disturbing.
>>>
>>> In pure spec-induced sense, the block emitting the barrier in do_exits()
>>> is only valid for initializers. That means, @Stable can indeed mimic its
>>> constructor store as the final field store. However, piggybacking on the
>>> same code to produce the barrier for an arbitrary method seems very
>>> error-prone (and even contradicting the comment in do_exits() which
>>> assumes [wrote_final == true] => [method.is_initializer() == true]).
>>>
>>> If @Stable writes out the value in an arbitrary method, then it requires
>>> release barrier on it's own. It is a pure luck finals _also_ have
>>> MemBar_Release, while they could have more relaxed form... especially
>>> when/if JMM 9 effort would allow this relaxation. Conflating memory
>>> semantics for finals and @Stable seems wrong.
>>>
>>> Hence, I think the change is sound. It keeps @Stable semantics for
>>> constructor stores. @Stable needs more work to emit release barriers for
>>> the arbitrary methods if required (why?), and I think given the failure
>>> scenario affects only non-TSO platforms, it can be done separately.
>>>
>>> Thoughts? (Vladimir Ivanov, please report in!)
>>>
>>> -Aleksey.
>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> On 1/30/14 12:15 PM, Aleksey Shipilev wrote:
>>>>> On 01/22/2014 11:13 PM, Aleksey Shipilev wrote:
>>>>>> On 01/22/2014 11:07 PM, Vladimir Kozlov wrote:
>>>>>>> Question first: can you wait about 2 weeks when we merge ppc64
>>>>>>> changes?
>>>>>>
>>>>>> I think we can wait. I don't want to collide with PPC merge either. In
>>>>>> fact, it would be even more convenient for us to grab PPC C2 in the
>>>>>> experiments from the mainline.
>>>>>
>>>>> Are we open already? I see PPC changes had collided with my patch. Even
>>>>> if it's too early to push the patch, I merged the upstream changes into
>>>>> the updated webrev:
>>>>>      http://cr.openjdk.java.net/~shade/8031818/webrev.01/
>>>>>
>>>>> Instead of introducing a new method, I rewired the predicate and
>>>>> rearranged the comments to make its structure clear. I think extracting
>>>>> method is not required now. Also, a few typos corrected.
>>>>>
>>>>> Testing:
>>>>>     - full cycle JPRT
>>>>>
>>>>> -Aleksey.
>>>>>
>>>
>