RFR: 8198949: Modularize arraycopy stub routine GC barriers

Erik Österlund erik.osterlund at oracle.com
Tue Mar 13 09:47:24 UTC 2018

Hi Roman,

Thanks for the review.


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