RFR: JDK-8210187: Explicit barriers for C2

[Roman Kennke]

Hi Erik,

I guess we do in-fact not strictly need them. 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.

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?

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