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

[Aleksey Shipilev]

Yes we can.
Do you want me to do this in this CR?

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