RFR: 8199417: Modularize interpreter GC barriers (original) (raw)

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.

/Erik

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 storeat and loadat 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