RFR: 8199417: Modularize interpreter GC barriers

Erik Österlund erik.osterlund at oracle.com
Mon Mar 26 14:37:16 UTC 2018

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.


> 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

More information about the hotspot-dev mailing list