RFR (M) 8225048: Shenandoah x86_32 support

[Aleksey Shipilev]

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.

-- 
Thanks,
-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20190530/96eced68/signature.asc>