RFR: 8199417: Modularize interpreter GC barriers

[Roman Kennke]

Ok, will do that.

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

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