RFR (round 1), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector (original) (raw)

Kim Barrett kim.barrett at oracle.com
Wed Nov 28 00:07:20 UTC 2018

On Nov 26, 2018, at 4:39 PM, Roman Kennke <rkennke at redhat.com> wrote: *) shared-gc - This is mostly boilerplate that is common to any GC - referenceProcessor.cpp has a little change to make one assert not fail (next to CMS and G1) - taskqueue.hpp has some small adjustments to enable subclassing

I've reviewed the shared-gc webrev. I only found a few trivial nits.

src/hotspot/share/gc/shared/gcName.hpp 42 NA, 43 Shenandoah,

Putting Shenandoah after NA seems odd.

src/hotspot/share/gc/shared/gcConfig.cpp 63 CMSGC_ONLY(static CMSArguments cmsArguments;) ... 69 SHENANDOAHGC_ONLY(static ShenandoahArguments shenandoahArguments;)

Code alignment should probably be updated.

Similarly here: 73 static const SupportedGC SupportedGCs[] = { ... 79 SHENANDOAHGC_ONLY_ARG(SupportedGC(UseShenandoahGC, CollectedHeap::Shenandoah, shenandoahArguments, "shenandoah gc"))

and here: 97 void GCConfig::fail_if_unsupported_gc_is_selected() { ... 105 NOT_SHENANDOAHGC(FAIL_IF_SELECTED(UseShenandoahGC, true));

src/hotspot/share/gc/shared/collectedHeap.hpp 92 // ShenandoahHeap

Moving it after ParallelScavengeHeap would give a better order.

src/hotspot/share/gc/shared/barrierSetConfig.hpp 36 SHENANDOAHGC_ONLY(f(Shenandoah))

Why is this "Shenandoah" while all the others are "BarrierSet"?

More information about the hotspot-gc-dev mailing list