RFR: 8198949: Modularize arraycopy stub routine GC barriers
rkennke at redhat.com
Tue Mar 13 09:26:36 UTC 2018
Am 09.03.2018 um 17:58 schrieb Erik Österlund:
> 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
> Thanks to Martin Doerr and Roman Kennke for providing platform specific
> code for PPC, S390 and AArch64.
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!
More information about the hotspot-dev