RFR: 8199417: Modularize interpreter GC barriers

[Erik Österlund]

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