RFR: JDK-8210187: Explicit barriers for C2

[Erik Österlund]

Hi Roman,

On 2018-08-30 17:01, Roman Kennke wrote:
> Hi Erik,
>
> I guess we do in-fact not strictly need them.

Okay good. In that case I would prefer to not insert resolve barriers 
where they are not needed.

> However, we have encountered problems in the past with interesting edge-cases of the JMM that involve final or stable fields or arrays, that usually have to do with JNI, reflection or bad constructors that let uninitialized stuff escape. That's why we played it save and put the barriers in all relevant places.

Sure. That does not come as a surprise, and I can see how such things 
would be problematic. But the described problems seem to have little to 
do with the mentioned string intrinsics. They seem to just not be needed.

>  From a far away interface design perspective, those are still heap accesses and GCs might be interested in intercepting e.g. final values. Maybe keep the resolves there and augment them with something like ACCESS_FINAL and/or ACCESS_STABLE and let the backend decide what to do with it? For example, in Shenandoah we have an option to optimize for the final/stable stuff and exploit the UD in the JMM in our favour, or to be conservative in favour of crazy applications, that could react on such a decorator. WDYT?

If final and stable properties can be exploited by the GC, then 
annotating that explicitly with decorators makes sense to me. However, 
it seems more intuitive to me to make such annotations in the relevant 
accesses, and not in a resolve barrier. Or what do you think?

Thanks,
/Erik

> Thanks for looking at this?
> Roman
>
>
> Am 30. August 2018 16:38:15 MESZ schrieb "Erik Österlund" <erik.osterlund at oracle.com>:
>> Hi Roman,
>>
>> Looking at these resolve barriers, I see it used in a lot of char
>> arrays
>> of strings. Are you sure you need those at all? I thought they are
>> supposed to be immutable, and hence to-space invariant in the sense
>> that
>> whether you read from from-space or to-space (and hence don't chase the
>>
>> Brooks pointer), you will get equivalent values. If you do indeed not
>> need them, I would prefer to remove the involved resolve barriers.
>>
>> Thanks,
>> /Erik
>>
>> On 2018-08-30 12:03, Roman Kennke wrote:
>>> In order to support GCs like Shenandoah, we need some explicit read-
>> or
>>> write-barriers in a few places. We already introduced them in the
>>> runtime, interpreter and C1, this change intends to do the same for
>> C2.
>>> It follows pretty much the same design as we did in C1.
>>>
>>> It is a bit more involved because there are *much* more intrinsics in
>> C2
>>> land. Other than that it's pretty straightforward.
>>>
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8210187
>>> Webrev:
>>> http://cr.openjdk.java.net/~rkennke/JDK-8210187/webrev.00/
>>>
>>> Can I please get a review?
>>>
>>> Thanks,
>>> Roman
>>>