RFR: JDK-8210187: Explicit barriers for C2

[Roman Kennke]

Hi Erik,

String arrays are a case of stable array, at least conceptually.

Another potential issue I am not sure of (don't 100% remember) is that C2 might optimize some string operations to modify the backing array in-place instead of copying.

Roman


Am 30. August 2018 17:20:13 MESZ schrieb "Erik Österlund" <erik.osterlund at oracle.com>:
>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
>>>>