RFR: 8199417: Modularize interpreter GC barriers

[Erik Österlund]

Hi Roman,

On 2018-03-26 15:10, Roman Kennke wrote:
> Ok, will do that.

Great, thanks.

> Your changes look ok to me (x86 and aarch64).

Thank you for the review.

/Erik

> Thanks,
> Roman
>
>> Thank you. As for primitive accesses, I think you have the best
>> knowledge about where these hooks must be in the code base, based on
>> your experience with Shenandoah. Therefore, I think it is probably best
>> if you add those hooks.
>>
>> Thanks,
>> /Erik
>>
>> On 2018-03-26 14:39, Roman Kennke wrote:
>>> Hi Erik,
>>>
>>> I like it.
>>>
>>> As far as I can see, the patch currently only handles oop stores and
>>> loads. Are you planning to add support for primitive access in the near
>>> future? Or else I can probably do that, or help with it (I know where to
>>> hook this up, based on Shenandoah experience).
>>>
>>> Thanks, Roman
>>>
>>>
>>>> The GC barriers for the interpreter are not as modular as they could be.
>>>> They currently use switch statements to check which GC barrier set is
>>>> being used, and call this or that barrier based on that, in a way that
>>>> assumes GCs only use write barriers.
>>>>
>>>> This patch modularizes this by generating accesses in the interpreter
>>>> with declarative semantics. Accesses to the heap may now use store_at
>>>> and load_at functions of the BarrierSetAssembler, passing along
>>>> appropriate arguments and decorators. Each concrete BarrierSetAssembler
>>>> can override the access completely or sprinkle some appropriate GC
>>>> barriers as necessary.
>>>>
>>>> Big thanks go to Martin Doerr and Roman Kennke, who helped plugging this
>>>> into S390, PPC and AArch64 respectively.
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.00/
>>>>
>>>> Bug:
>>>> https://bugs.openjdk.java.net/browse/JDK-8199417
>>>
>>>
>