Build change looks good. /Erik
On 2019-05-30 04:44, Aleksey Shipilev wrote:
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.
