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

Roman Kennke rkennke at redhat.com
Tue Mar 13 09:26:36 UTC 2018

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