Shenandoah 2.0

Roman Kennke rkennke at redhat.com
Mon Sep 30 21:24:30 UTC 2019


Hi Simone,

>> Regarding the traversal mode. It only has a single concurrent phase that
>> does all of marking, compacting and updating-references in a single
>> pass. It is book-ended by a pause each, similar to init-mark and
>> final-update-refs pause to do initialize the traversal and to do some
>> bookkeeping and cleanup stuff. The liveness data of one cycle feeds into
>> the cset decisions of the subsequent cycle.
> 
> Yes I tried to capture that into slide 53.
> Is it correct?

If I understand the slide correctly, then not. It still looks like there
3 phase, with overlap. It is really just one phase:

idle -> STW-init -> traversal (mark+evac+update) -> STW-end -> idle

and so on.

>> To be honest, I am not sure
>> this whole slide needs to exist or only serves to confuse people (even
>> more).
> 
> Oh. I thought it was ok to have 1 slide about traversal for completeness.
> Why you think it's confusing?
> And why you say "even more"?

Because concurrent GCs are confusing to begin with (what with moving
objects from under you feet while you go). Doing all in 1 phase is even
more so.

> I'd be happy to clarify or remove confusing stuff.

It's not you or your slides, it's the subject matter. If you like it,
leave Traversal GC in.

>> I'd probably add one or two comparison slides at the end that highlights
>> the pros and cons of each one.
> 
> "Each one" as in comparison between ZGC and Shenandoah

yes

>, or "each one"
> as in comparison between non-traversal and traversal?

no

>> That's what people usually want to know:
>> 'which concurrent GC is for me?'
> 
> My experience is typically divided in 2 here, at the ends of the spectrum.
> Many don't care at all - give them ZGC or Shenandoah to replace
> G1/CMS/Parallel because "it's better" and they switch blindly.
> Few are GC maniacs and put 42 command line options to tune everything
> because they read so on StackOverflow.
> Those that can tell apart ZGC and Shenandoah may have some idea
> already of what's better for their use case, but again they are savvy
> enough to try both and actually verify what's better for them.

Well, such slides would help the former 2 categories of users to become
more educated, and may also have something new for the experts in
category 3, I'd think :-)

> Honestly I can't tell myself.
> I like better ZGC for simplicity than Shenandoah.

>From users perspective, both are pretty much -XX:+UseZGC or
-XX:+UseShenandoahGC and not much to configure. Even power users will
rarely need much tuning, so yeah.

> OTOH, I think Shenandoah is more sophisticated and may deal/degrade
> better in edge cases (pacing, degenerate and full).
> Plus Shenandoah is available in many architectures, OSes, Java versions.

yeah, and compressed oops is a big deal for some users.

> In edge cases, I'd feel more confident in enlarging the heap than
> trying to tune edge cases.
> If both GCs are slightly overprovisioned in heap size (so that they
> never reach danger zone), GC pauses are basically a solved problem, so
> either ZGC or Shenandoah will do the job.
> I may be grossly oversimplifying here, but I'm open to hear opinions
> from the source ;)

Yeah that's pretty much it. Shenandoah's pacing/degrading helps with
avoiding the edge-cases even with tight heaps, there's not much to tune
for this either.

I hope this clarifies a little.

Roman



More information about the shenandoah-dev mailing list