RFR: 8199417: Modularize interpreter GC barriers
erik.osterlund at oracle.com
Mon Mar 26 12:59:23 UTC 2018
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.
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.
More information about the hotspot-dev