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

[Aleksey Shipilev]

Ok, here you go:
 http://cr.openjdk.java.net/~shade/8031818/webrev.02/

Testing:
 - full JPRT cycle
 - microbenchmarks with -XX:(+|-)AlwaysSafeConstructors

Thanks,
-Aleksey

On 01/31/2014 03:19 AM, Vladimir Kozlov wrote:
> 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.
>>>>>>
>>>>
>>