Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8225048

Shenandoah x86_32 support

XMLWordPrintable

    • Icon: Enhancement Enhancement
    • Resolution: Fixed
    • Icon: P3 P3
    • 13
    • 8-shenandoah, 11-shenandoah, 13
    • hotspot
    • gc
    • b24
    • x86

        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 on top of that. This allows us to maintain 32-bit cleanness in Shenandoah code, plus serves are proof of concept that Shenandoah can be implemented on 32-bit platform.

        A few compiler changes are needed to cover a corner cases that are needed for !LP64 paths, including the shenandoah_x86_32.ad file that carries Shenandoah CAS barriers. Otherwise most of the changes are in rewiring ShenandoahBarrierSetAssembler for x86 to properly share 32- and 64-bit paths. Plus there are test changes that make sure we don't run test we know would fail on 32-bit VMs.

        The patch passes hotspot_gc_shenandoah tests, CTW tests, jcstress.

              shade Aleksey Shipilev
              shade Aleksey Shipilev
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated:
                Resolved: