RFR: 8198949: Modularize arraycopy stub routine GC barriers (original) (raw)

Erik Österlund erik.osterlund at oracle.com
Mon Mar 19 14:04:02 UTC 2018

Hi Roman,

Thank you for the review.

/Erik

On 2018-03-19 14:42, Roman Kennke wrote:

I liked BSCodeGen better, but BarrierSetAssembler is ok too. Go for it!

Roman

After some internal discussions, it turns out that the name "*BSCodeGen" was not so popular, and has been changed to *BarrierSetAssembler instead. I have rebased this on top of 8199604: Rename CardTableModRefBS to CardTableBarrierSet and went ahead with the performing the required renaming. New full webrev: http://cr.openjdk.java.net/~eosterlund/8198949/webrev.03/ New incremental webrev (from the rebased version): http://cr.openjdk.java.net/~eosterlund/8198949/webrev.0203/ Thanks, /Erik On 2018-03-13 10:47, Erik Österlund wrote: Hi Roman,

Thanks for the review. /Erik On 2018-03-13 10:26, Roman Kennke wrote: Am 09.03.2018 um 17:58 schrieb Erik Österlund: Hi,

The GC barriers for arraycopy stub routines are not as modular as they could be. They currently use switch statements to check which GC barrier set is being used, and call one or another barrier based on that, with registers already allocated in such a way that it can only be used for write barriers. My solution to the problem is to introduce a platform-specific GC barrier set code generator. The abstract super class is BarrierSetCodeGen, and you can get it from the active BarrierSet. A virtual call to the BarrierSetCodeGen generates the relevant GC barriers for the arraycopy stub routines. The BarrierSetCodeGen inheritance hierarchy exactly matches the corresponding BarrierSet inheritance hierarchy. In other words, every BarrierSet class has a corresponding BarrierSetCodeGen class. The various switch statements that generate different GC barriers depending on the enum type of the barrier set have been changed to call a corresponding virtual member function in the BarrierSetCodeGen class instead. Thanks to Martin Doerr and Roman Kennke for providing platform specific code for PPC, S390 and AArch64. Webrev: http://cr.openjdk.java.net/~eosterlund/8198949/webrev.00/ CR: https://bugs.openjdk.java.net/browse/JDK-8198949 Thanks, /Erik I looked over x86, aarch64 and shared code (in webrev.01), and it looks good to me! As I commented earlier in private, I would find it useful if the barriers could 'take over' the whole arraycopy, for example to do the pre- and post-barrier and arraycopy in one pass, instead of 3. However, let's keep that for later. Awesome work, thank you! Cheers, Roman

More information about the hotspot-dev mailing list