The changes look good to me. Thanks!! Roman
> http://cr.openjdk.java.net/~shade/8225048/webrev.01/ > > Some history: Shenandoah used to support x86_32 in "passive" mode long time > ago. This mode relies > only on stop-the-world GC to avoid implementing barriers (basically, runs > Degenerated GC all the > time). It was an interesting mode to see the footprint numbers you can get > with uncommits and > slimmer native pointers with really small microservice-size VMs. This mode > was dropped before > integration upstream, because many Shenandoah tests expect all > heuristics/modes to work properly, > and having the rudimentary x86_32 support was breaking tier1 tests. So we > disabled it. > > Today, we have significantly simplified runtime interface thanks to LRB and > elimination of separate > forwarding pointer slot, and we can build the fully concurrent x86_32 with > ease. This allows us to > maintain 32-bit cleanness in Shenandoah code, plus serves as the proof of > concept that Shenandoah > can be implemented on 32-bit platform. > > I am planning to backport this all the way to 8u, once other improvements are > backported, so keeping > the patch simple is paramount. > > A brief tour of changes: > > *) One minor change in build config to accept both x86_32 and x86_64 > (therefore, cc'ing build-dev); > this is the same check we had before reversal in jdk12; > > *) C1 changes need to disambiguate for single/double-cpu slots in CAS, this > is the same other > BarrierSets do; > > *) C2 changes need shenandoah_x86_32.ad to carry adapters for CAS barriers, > plus accept > StoreIConditional for raw ptr stores on some paths. > > *) SBSAssembler change reshuffles _LP64 checks to enable x86_32 paths. It > needs to deal with > UseCompressedOops blocks, getting threads into a separate register, etc.; > > *) Test changes enable running them on x86_32, and generally 32-bit > platforms -- I can split them > out, but they make little sense on their own, without having the product code > that actually uses them; > > Builds: {x86_32, x86_64} with/without PCH; other platform builds in CI > Testing: hotspot_gc_shenandoah, CTW tests, jcstress, ad-hoc footprint > experiments > > IIRC, Oracle does not build either x86_32 or Shenandoah, so I did not run it > through jdk-submit. >
