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

[Andrew Dinn]

On Thu, 29 Jan 2026 23:10:48 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Run AOTCodeFlags test with multiple GCs
>
> I reproduced crash locally on linux-x64-debug (fast debug build)
> 
> $ make test CONF=fast TEST=runtime/cds/appcds/aotCode/AOTCodeFlags.java#parallel
> 
> 
> In hs_err file:
> 
> #  SIGSEGV (0xb) at pc=0x00007fe1eb77da6d, pid=12380, tid=12383
> #
> # JRE version: Java(TM) SE Runtime Environment (27.0) (fastdebug build 27-internal-vkozlov.open)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 27-internal-vkozlov.open, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, parallel gc, linux-amd64)
> # Problematic frame:
> # v  ~BufferBlob::final_blob (stub gen) 0x00007fe1eb77da6d
> ...
> Stack: [0x00007fe205c5c000,0x00007fe205d5d000],  sp=0x00007fe205d59790,  free space=1013k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> v  ~BufferBlob::final_blob (stub gen) 0x00007fe1eb77da6d
> J 416 c1 java.util.Arrays.copyOf([Ljava/lang/Object;ILjava/lang/Class;)[Ljava/lang/Object; java.base at 27-internal (40 bytes) @ 0x00007fe1e432044e [0x00007fe1e4320180+0x00000000000002ce]
> j  java.util.Arrays.copyOf([Ljava/lang/Object;I)[Ljava/lang/Object;+6 java.base at 27-internal
> j  java.lang.invoke.LambdaFormBuffer.startEdit()V+138 java.base at 27-internal
> j  java.lang.invoke.LambdaFormEditor.makeArgumentCombinationForm(ILjava/lang/invoke/MethodType;ZZ)Ljava/lang/invoke/LambdaForm;+8 java.base at 27-internal
> j  java.lang.invoke.LambdaFormEditor.filterArgumentForm(ILjava/lang/invoke/LambdaForm$BasicType;)Ljava/lang/invoke/LambdaForm;+108 java.base at 27-internal

@vnkozlov I think I found the x86 issue that was derailing the tests. I missed a necessary change to c1_LIRAssembler which ensures that ThreadIdentifier::unsafe_offset is encoded as an external address rather than a long constant.

The current patch also needs fixing to load G1 grain size and card table base from the AOT constants region when the cache is `on_for_dump()`. We ought to port that across to mainline as separate fixes rather than part of this patch. They don't strictly need to go in first although that would be less fragile.

Also, I noticed that the changes to the encode/decode klass methods in mainline and premain differ slightly on x86. In particular the move_and_en/decode methods in mainline don't special case 'on_for_dump()'. I'm not sure if that was an accident or not (the move_and_xxx variants might not have been used when generating adapters). However, we maybe also need to fix that.

Finally, as you say, we need to ensure that command line JVM configuration settings are not modified between assembly and production run. I guess that change really needs porting before this goes in.

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

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