RFC: Pick up jdk/jdk -> sh/jdk at jdk-13+20+

Aleksey Shipilev shade at redhat.com
Tue May 14 12:06:25 UTC 2019


We need to pick up latest jdk/jdk for nofwdptr and x86_32 stabilization. Last week's jdk/jdk was
riddled with build/test failures, which seem to be resolved at current state. I don't think we want
to risk waiting for another tag, and instead merge at latest buildable changeset:

changeset:   55778:d7819bedfaaf
tag:         tip
user:        redestad
date:        Tue May 14 12:00:49 2019 +0200
summary:     8221478: Disable VerifySharedSpaces by default

There is one lingering fastdebug/accounting bug not fixed:
  https://bugs.openjdk.java.net/browse/JDK-8223502

...but again, it seems dubious to wait for it, as jdk/jdk may regress. I would deal with that bug
upstream as soon as possible. We would hopefully catch jdk-13+21 on Thursday as the follow-up.

This merge changesets:
  http://cr.openjdk.java.net/~shade/shenandoah/merges/jdk-13%2b20-plus/changesets.txt

Brings in:
  8222992: Shenandoah: Pre-evacuate all roots
  8223258: Shenandoah: SRP::process_all_roots_slow processes JvmtiExport weak oops twice
  8223389: Shenandoah optimizations fail with assert(!phase->exceeding_node_budget())
  8222738: Shenandoah: assert(is_Proj()) failed when running cometd benchmarks
  8223448: Shenandoah disabled barriers blocks omit LRB
  8223450: Disable Shenandoah C2 barriers verification for x86_32
  8223449: Unprotected UseCompressedOops block in gc/shenandoah/shenandoahBarrierSetC1_x86.cpp
  8223446: Shenandoah breaks alignment with some HumongousThreshold values
  8223447: Stabilize gc/shenandoah/TestStringDedupStress test
  8223570: Shenandoah needs to acquire lock before CLDG::clear_claimed_marks
  8222926: Shenandoah build fails with --with-jvm-features=-compiler1
  8223567: Rename ShenandoahBrooksPointer to ShenandoahForwarding
  8223583: Build failure after JDK-8223567 (Rename ShenandoahBrooksPointer to ShenandoahForwarding)
  8223427: [TESTBUG] Disable JTReg Shenandoah tests when Graal is enabled
  8223759: Shenandoah should allow arbitrarily low initial heap size
  8223762: Shenandoah: overflows in calculations involving heap capacity

This merge webrev:
  http://cr.openjdk.java.net/~shade/shenandoah/merges/jdk-13%2b20-plus/webrev.01/

I also eyeballed that current sh/jdk diff does not miss anything from nofwdptr patch.

Testing: hotspot_gc_shenandoah {fastdebug|release}

-- 
Thanks,
-Aleksey




More information about the shenandoah-dev mailing list