Understanding ZGC details

Gil Tene gil at azul.com
Fri Jul 13 17:52:45 UTC 2018

> On Jul 13, 2018, at 10:35 AM, Simone Bordet <simone.bordet at gmail.com> wrote:
> Hi,
> first of all congrats and thanks for ZGC.
> I've been running a benchmark of mine
> (https://docs.cometd.org/current/reference/#_benchmarking), a
> Servlet-based chat application on top of Jetty, to compare G1,
> Shenandoah and ZGC.
> The hope is to produce some conference material to spread the word
> about ZGC (for which personally I have high expectations).
> Meanwhile I'm trying to understand a bit more about ZGC and I have few
> questions (I have read the GC handbook from Jones et al., but I'm new
> to Linux memory tricks so please pardon my ignorance on the matter; I
> have also watched Per's presentation at JFokus 2018).
> I don't quite get the mechanism of colored pointers and how it exactly works.
> I see that ZGC maps the heap space into 3 views (in
> ZPhysicalMemoryBacking::map()).
> What is the purpose of mapping into 3 views (I get the number 3, it's
> for the number of phases; but why cannot they be handled with just 1
> view)?
> Skimming around in the code - not deeply, I admit - seems to be that
> pointers to those views are always de-colored before being
> dereferenced, so I am a bit puzzled about those 3 views.
> Assuming I'm wrong, is the mechanism similar to C4, where a view is
> mprotect()-ed on a phase flip?
> If so, I am also assuming that this would generate a SEGV that will
> run some code that will fix the pointer. Can you please detail where
> is the SEGV handling code that does that?

Speaking about the C4 mechanism: while C4 does perform various mapping manipulations
for various reasons, LVB detection does not use SEGVs and does not rely on memory
protection. Instead, The C4 LVB fast path uses a test & jmp (a single u-op on x86) to verify
that the loaded reference is not in a "currently invalid" phase, with a slow path that fixes the
reference to be in a valid phase (doing whatever is needed to achieve that: ensure marking,
fixup to point to relocated object location, or perform actual object relocation if needed).

My understanding is the the ZGC barrier mechanism is doing pretty much the same thing
including the use of a test & jmp for the fast path. It is basically a C4 LVB.

BTW, adding Zing to the set of JVM configs you comparatively test above would be a good idea ;-)

> I'm stopping here feeling that I'm offroad already :)
> I'm sure if you put me back on the road I'll have more questions.
> Thanks!
> --
> Simone Bordet
> ---
> Finally, no matter how good the architecture and design are,
> to deliver bug-free software with optimal performance and reliability,
> the implementation technique must be flawless.   Victoria Livschitz

More information about the zgc-dev mailing list