RFR: Eliminate extra forwarding pointer per object
Roman Kennke
rkennke at redhat.com
Tue May 7 15:59:40 UTC 2019
Until now, Shenandoah had the 'limitation' that it required an extra
word per object to keep the forwarding pointer. It either points to
itself (most of the time) or to the forwarded object when evacuated. The
forwarding pointer is updated atomically using CAS. This is the heart of
Shenandoah's evacuation protocol.
With LRB, we have the opportunity to eliminate that extra word. The
insight is that we really don't need the old copy of an object anymore
and we can store the forwarding pointer in the mark word of it. We would
distinguish a valid mark word from a forwarding pointer by checking the
lowest 2 bits: if they are 0b11 then it's forwarded, otherwise it's not.
0b11 is not a valid combination of bits otherwise. This is the same
protocol that is used by other GCs.
The evacuation protocol changes slightly to CAS into the mark word
instead of the extra word. But the basic mechanics are the same.
The extra decoding does not (significantly) affect performance because
it's only done in the mid/slow-path of the LRB. (As opposed to earlier
attempts at it where it'd have to be in the read-barrier.)
I've run SPECjvm2008. Performance benefits vary between 0 and ~+10%. One
exception is one of the scimarks which is negatively impacted. The
reason appears to be that this benchmark is very heavily contended on
synchronizer objects, and the tighter spacing negatively impacts it when
running with many threads. I don't consider this a true regression.
SPECjbb2015 shows +12% improvement in throughput and +9% improvement in
latency.
I propose to push it to shenandoah/jdk and bake it there a little before
upstreaming it into jdk/jdk.
Webrev:
http://cr.openjdk.java.net/~rkennke/eliminate-fwdptr/webrev.00/
Testing: hotspot_gc_shenandoah (x86,aarch64) specjvm, specjbb, most of
them many many times
Opinions?
Thanks,
Roman
More information about the shenandoah-dev
mailing list