RFC: Pick up jdk-13+22 to sh/jdk
Aleksey Shipilev
shade at redhat.com
Thu May 30 09:58:08 UTC 2019
jdk/jdk is somewhat stable at the moment, let's pick it up to sh/jdk. This is the penultimate
stepping stone for upstreaming x86_32 support. The merges were simple, but not trivial, but I
verified those are correct by diffing against jdk/jdk. We would check webrevs again once this merge
lands.
Changesets:
http://cr.openjdk.java.net/~shade/shenandoah/merges/jdk-13%2b22/changesets.txt
Notable ones:
8221507: Implement JFR Events for Shenandoah
8224495: Shenandoah: Do not rescan code roots in final mark pause if it is not degenerated GC
8224579: ResourceMark not declared in shenandoahRootProcessor.inline.hpp with
--disable-precompiled-headers
8224508: Shenandoah: Need to update thread roots in final mark for piggyback ref update cycle
8224525: Shenandoah: Eliminate shenandoah verifier's side-effects
8224529: [TESTBUG] JFR TestShenandoahHeapRegion* tests fail on build w/o Shenandoah
8224522: Shenandoah should apply barriers on deoptimization
8224667: Shenandoah: Post-LRB cleanup
8224679: Shenandoah: Make ShenandoahParallelCodeCacheIterator noncopyable
8224115: Shenandoah: Eliminate RWLock that protects recorded nmethod data array
8224751: Shenandoah: Shenandoah Verifier should select proper roots according to current GC cycle
8224584: Shenandoah: Eliminate forwarding pointer word
8224496: Shenandoah compilation fails with assert(is_CountedLoopEnd()) failed: invalid node class
8224970: ShenandoahRootScanner::roots_do assert is too strong
8224932: Shenandoah: Rename ShenandoahHeapLock, make it general purpose lock
8224875: Shenandoah: ParallelCleaning code unloading should take lock to protect shared code roots
Testing: hotspot_gc_shenandoah {x86_32, x86_64}, eyeballing the diff against jdk/jdk
--
Thanks,
-Aleksey
More information about the shenandoah-dev
mailing list