Thanks, Per! I will do this. Check out round 3 when it arrives. ;-)
Roman Am 29.11.18 um 12:07 schrieb Per Liden: > Small comment on the build changes. Instead of checking for zero variant > here: > > + # Only enable Shenandoah on supported arches > + AC_MSG_CHECKING([if shenandoah can be built]) > + if HOTSPOT_CHECK_JVM_VARIANT(zero); then > + DISABLED_JVM_FEATURES="$DISABLED_JVM_FEATURES shenandoahgc" > + AC_MSG_RESULT([no, this JVM variant not supported]) > + else > > I think you should just add shanandoahgc to the existing check, here: > > # Disable unsupported GCs for Zero > if HOTSPOT_CHECK_JVM_VARIANT(zero); then > DISABLED_JVM_FEATURES="$DISABLED_JVM_FEATURES epsilongc g1gc zgc" > fi > > cheers, > Per > > On 11/26/18 11:47 PM, Erik Joelsson wrote: >> Build changes look ok to me. >> >> /Erik >> >> On 2018-11-26 13:39, Roman Kennke wrote: >>> Hi, >>> >>> This is the first round of changes for including Shenandoah GC into >>> mainline. >>> I divided the review into parts that roughly correspond to the >>> mailing lists >>> that would normally review it, and I divided it into 'shared' code >>> changes and >>> 'shenandoah' code changes (actually, mostly additions). The intend is to >>> eventually >>> push them as single 'combined' changeset, once reviewed. >>> >>> JEP: >>> https://openjdk.java.net/jeps/189 >>> Bug entry: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8214259 >>> >>> Webrevs: >>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/ >>> >>> For those who want to see the full change, have a look at the >>> shenandoah-complete >>> <http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/shenandoah-complete/> >>> >>> directory, >>> it contains the full combined webrev. Alternatively, there is the file >>> shenandoah-master.patch >>> <http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/shenandoah-master.patch>, >>> >>> which is what I intend to commit (and which should be equivalent to the >>> 'shenandoah-complete' webrev). >>> >>> Sections to review (at this point) are the following: >>> *) shenandoah-gc >>> <http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/shenandoah-gc/> >>> >>> - Actual Shenandoah implementation, almost completely residing in >>> gc/shenandoah >>> >>> *) shared-gc >>> <http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/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 >>> >>> *) shared-serviceability >>> <http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/shared-serviceability/> >>> >>> - The usual code to support another GC >>> >>> *) shared-runtime >>> <http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/shared-runtime/> >>> >>> - A number of friends declarations to allow Shenandoah iterators to >>> hook up with, >>> e.g. ClassLoaderData, CodeCache, etc >>> - Warning and disabling JFR LeakProfiler >>> - fieldDescriptor.hpp added is_stable() accessor, for use in >>> Shenandoah C2 optimizations >>> - Locks initialization in mutexLocker.cpp as usual >>> - VM operations defines for Shenandoah's VM ops >>> - globalDefinitions.hpp added UINT64_FORMAT_HEX_W for use in >>> Shenandoah's logging >>> - The usual macros in macro.hpp >>> >>> *) shared-build >>> <http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/shared-build/> >>> >>> - Add shenandoah feature, enabled by default, as agreed with >>> Vladimir K. beforehand >>> - Some flags for shenandoah-enabled compilation to get >>> SUPPORT_BARRIER_ON_PRIMITIVES >>> and SUPPORT_NOT_TO_SPACE_INVARIANT which is required for >>> Shenandoah's barriers >>> - --param inline-unit-growth=1000 settings for 2 shenandoah source >>> files, which is >>> useful to get the whole marking loop inlined (observed >>> significant >>> regression if we >>> don't) >>> >>> *) shared-tests >>> <http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/shared-tests/> >>> >>> - Test infrastructure to support Shenandoah >>> - Shenandoah test groups >>> - Exclude Shenandoah in various tests that can be run with >>> selected GC >>> - Enable/add configure for Shenandoah for tests that make sense to >>> run with it >>> >>> *) shenandoah-tests >>> <http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/shenandoah-tests/> >>> >>> - Shenandoah specific tests, most reside in gc/shenandoah >>> subdirectory >>> - A couple of tests configurations have been added, e.g. >>> TestGCBasherWithShenandoah.java >>> >>> I intentionally left out shared-compiler for now, because we have some >>> work left to do >>> there, but if you click around you'll find the patch anyway, in case you >>> want to take >>> a peek at it. >>> >>> We have regular builds on: >>> - {Linux} x {x86_64, x86_32, armhf, aarch64, ppc64el, s390x} >>> - {Windows} x {x86_64}, >>> - {MacOS X} x {x86_64} >>> >>> This also routinely passes: >>> - the new Shenandoah tests >>> - jcstress with/without aggressive Shenandoah verification >>> - specjvm2008 with/without aggressive Shenandoah verification >>> >>> >>> I'd like to thank my collegues at Red Hat: Christine Flood, she deserves >>> the credit for being the original inventor of Shenandoah, Aleksey >>> Shiplëv, Roland Westrelin & Zhengyu Gu for their countless >>> contributions, everybody else in Red Hat's OpenJDK team for testing, >>> advice and support, my collegues in Oracle's GC, runtime and compiler >>> teams for tirelessly helping with and reviewing all the GC interface and >>> related changes, and of course the many early adopters for reporting >>> bugs and success stories and feature requests: we wouldn't be here >>> without any of you! >>> >>> Best regards, >>> Roman >>>
