[GR-70306] Add infrastructure for Shenandoah.

[graalvmbot]

This PR contains 2 commits at the moment:

• The 1st commit adds common infrastructure for native GCs such as G1 or Shenandoah. This commit will be merged to master in the next few days, so it will eventually disappear from this PR.
• The 2nd commit adds Shenandoah-specific logic.

How to use this together with the C++ code base:

• Clone the C++ code base and checkout the following branch: https://github.com/graalvm/labs-openjdk/tree/chaeubl/GR-70066
• Build a debug shared library from the C++ sources: make -j16 build_debug_ur_so
• Move the built library to a place where the linker can find it.
• Clone the mxand graal repository and checkout this branch in the graal repository.
  • change into the substratevm directory: cd graal/substratevm
  • set JAVA_HOME to a compatible JDK (I used labsjdk-ce-latest-25+37-jvmci-b06_amd64)
  • build the project: mx build
  • build a native executable for a HelloWorld:mx native-image -g -O0 --gc=shenandoah -H:ShenandoahDebugLevel=debug HelloWorld
  • run the native executable: ./helloworld
  • execution should crash in the C++ code during early startup (# guarantee(flag != nullptr) failed: unknown option) because the Shenandoah-specific logic is missing at the moment (e.g., the C++ code doesn't know about the option ShenandoahRegionSize).

Current limitations and open issues:

• useCompressedReferences in ShenandoahFeature.afterRegistration(...) is currently hardcoded to false.
• Read/Write barriers are currently completely disabled if --gc=shenandoah is specified, see SubstrateShenandoahBarrierSet. Methods related to the card table and the barriers are therefore unused at the moment, see ShenandoahHeap.addressOfCardTableAddress(...), ShenandoahLibrary.preWriteBarrierStub(...), and ShenandoahLibrary.postWriteBarrierStub(...). Note that Shenandoah will probably need to emit read barriers when accessing static fields (see JavaDoc on SubstrateShenandoahBarrierSet.fieldWriteBarrierType(...)).
• ShenandoahHeap.printGCInternalLocationInfo(...) is unimplemented at the moment. This method should print information about GC internal locations, such as the card table (see HeapImpl.printLocationInfo(...) for an example).
• DumpRegionInformation.printRegion(...) is unimplemented at the moment. This method should print information about a heap region (e.g., when a fatal error occurrs).
• The logic in ShenandoahHeap.getHeapBaseAlignment() might need to change.
• The @Uninterruptible reasons in ShenandoahAllocationSupport might not be relevant for Shenandoah.
• Only some MX beans are implemented at the moment, see ShenandoahRelatedMXBeans
• ShenandoahImageHeapInfo and ShenandoahImageHeapLayouter are rather generic at the moment, so more Shenandoah-specific logic might be needed there. Same applies to the object header, see ShenandoahObjectHeader.
• ShenandoahRegionType.Flags may need to change once you start using the image heap metadata on the C++ side (see argument image_heap_region_types in svm_gc_create(...)).

Suggested first steps:

• Add Shenandoah logic to C++ code base.
• Make the 1st part of the startup work (svm_gc_parse_options).
• Make the 2nd part of the startup work (svm_gc_create). For that, it will be necessary to initialize Shenandoah internal data structures so that Shenandoah knows about all the image heap regions.
• Make a HelloWorld work.
• Implement read/write barriers.
• Make a GC work that is triggered via System.gc()

[christianhaeubl]

@simonis : this PR provides the Java infrastructure for the Shenandoah integration into Native Image, see PR description above for more details. I also updated the C++ part accordingly, see https://github.com/graalvm/labs-openjdk/tree/chaeubl/GR-70066.

[simonis]

Thanks a lot, @christianhaeubl !

[simonis]

@christianhaeubl I could follow your excellent description and reproduce all the steps (except for #12373 which I think is not your fault :) until I ran into the guarantee you described. Will look into the details tomorrow..