RFR: 8372617: Save and restore stubgen stubs when using an AOT code cache [v4]

[Andrew Dinn]

On Mon, 26 Jan 2026 17:58:49 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Andrew Dinn has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - fix whitespace issue
>>  - remaining asmehra feedback
>
> Also several tests (including runtime/cds/appcds/aotCache/) filed when run with GC different from G1:
> 
> 
> #  SIGSEGV (0xb) at pc=0x00007f21738f106d, pid=3522829, tid=3522833
> #
> # JRE version: Java(TM) SE Runtime Environment (27.0) (fastdebug build 27-internal-2026-01-24-0025574.vladimir.kozlov.jdkgit2)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 27-internal-2026-01-24-0025574.vladimir.kozlov.jdkgit2, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, serial gc, linux-amd64)
> # Problematic frame:
> # v  ~BufferBlob::final_blob (stub gen) 0x00007f21738f106d
> 
> -XX:MaxRAMPercentage=4.16667 -XX:+UseSerialGC -Xlog:class+load -Dcom.sun.management.jmxremote=true -Xlog:arguments,aot,cds:file=HelloAOTCache-with-management-agent.production.log::filesize=0 -XX:AOTMode=on -XX:AOTCache=HelloAOTCache-with-management-agent.aot HelloAOTCacheApp
> 
> Stack: [0x00007f218dffc000,0x00007f218e0fd000],  sp=0x00007f218e0f7af0,  free space=1006k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> v  ~BufferBlob::final_blob (stub gen) 0x00007f21738f106d
> J 280 c1 java.util.Arrays.copyOf([Ljava/lang/Object;ILjava/lang/Class;)[Ljava/lang/Object; java.base at 27-internal (40 bytes) @ 0x00007f216c30d2ce [0x00007f216c30d000+0x00000000000002ce]
> J 378 c1 java.util.ArrayList.grow(I)[Ljava/lang/Object; java.base at 27-internal (60 bytes) @ 0x00007f216c30cc2c [0x00007f216c30cb00+0x000000000000012c]

@vnkozlov @ashu-mehra

I have added a hash table to speed up address to id translation during assembly and that now appears to be working correctly.

I also put a check into the table insert method to detect and refuse repeated registrations of externals. That allowed me to prune a few unnecessary additions from the `init_extrs` and `init_extrs2` methods of `AOTCodeAddressTable`.

The previous GC errors were to do with callouts from the Z and Shenandoah stubs currently in mainline that we did not have to deal with in the earlier premain version. I believe I have fixed this by adding the necessary external address initializations to `AOTCodeAddressTable::init_extrs`. I also modified the AOTCodeFlags test to run 4 times, with G1 (default), Z, Shenandoah and Parallel GCs, and it passed all 4 on aarch64. I have not yet tested it on x86_64 but I did get HelloWorld to work on both arches.

If this passes the PR gate plus any further testing you can do then that would be enough to allow the present PR to be integrated. That said, it would probably be better if we removed addition of the GC-specific externals from `init_extrs` and instead delegated responsibility to a static method of BarrierSetRuntime (and through it to BarrierSetNMethod and BarrierSetAssembler) called immediately after GC stub generation i.e. we can make the GC was responsible for adding the externals that it relies on. Likewise, when we integrate save and restore of nmethods into mainline (also when we merge this back into premain) we can delegate to the C1BarrierSet and C2BarrierSet in order to register externals that are specific to compiled C1 and C2 Java method code.

Should I make the delegation changes now?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28433#issuecomment-3816913020