RFR (M) 8225048: Shenandoah x86_32 support

[Erik Joelsson]

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.
>