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