RFR: 8198949: Modularize arraycopy stub routine GC barriers

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