RFR: 8199417: Modularize interpreter GC barriers

Roman Kennke rkennke at redhat.com
Mon Mar 26 13:10:16 UTC 2018

Ok, will do that.

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


> 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

More information about the hotspot-dev mailing list