RFR: 8354887: Preserve runtime blobs in AOT code cache [v2]

[Vladimir Kozlov]

On Wed, 7 May 2025 09:52:23 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>>> I can recreate this test locally. Looking into it.
>> 
>> Looks like the code for C2 blobs generated in assembly phase is not correct.
>> For example, code for new_instance blob is:
>> 
>> 
>> [0.141s][550409][aot,codecache,stubs] Decoding CodeBlob, name: C2 Runtime new_instance, at  [0x00007fed0f904260, 0x00007fed0f9042b8]  88 bytes
>> [0.141s][550409][aot,codecache,stubs]  ;; N1: # out( B1 ) <- in( B3 B2 )  Freq: 1
>> [0.141s][550409][aot,codecache,stubs]  ;; B1: # out( B3 B2 ) <- BLOCK HEAD IS JUNK  Freq: 1
>> [0.141s][550409][aot,codecache,stubs]   0x00007fed0f904260:   sub    $0x8,%rsp
>> [0.141s][550409][aot,codecache,stubs]   0x00007fed0f904267:   mov    %rbp,(%rsp)
>> [0.141s][550409][aot,codecache,stubs]   0x00007fed0f90426b:   mov    %rsp,0x3e8(%r15)
>> [0.141s][550409][aot,codecache,stubs]   0x00007fed0f904272:   mov    %rsi,%rdi
>> [0.141s][550409][aot,codecache,stubs]   0x00007fed0f904275:   mov    %r15,%rsi
>> [0.141s][550409][aot,codecache,stubs]   0x00007fed0f904278:   movabs $0x7fed28908982,%r10
>> [0.141s][550409][aot,codecache,stubs]   0x00007fed0f904282:   call   *%r10
>> [0.141s][550409][aot,codecache,stubs]   0x00007fed0f904285:   nopl   0x0(%rax,%rax,1)
>> [0.141s][550409][aot,codecache,stubs]   0x00007fed0f90428d:   mov    %r12,0x3e8(%r15)
>> [0.141s][550409][aot,codecache,stubs]   0x00007fed0f904294:   mov    %r12,0x3f0(%r15)
>> [0.141s][550409][aot,codecache,stubs]   0x00007fed0f90429b:   mov    0x440(%r15),%rax
>> [0.141s][550409][aot,codecache,stubs]   0x00007fed0f9042a2:   mov    %r12,0x440(%r15)
>> [0.141s][550409][aot,codecache,stubs]   0x00007fed0f9042a9:   cmp    0x8(%r15),%r12
>> [0.141s][550409][aot,codecache,stubs]   0x00007fed0f9042ad:   jne    0x00007fed0f9042b1
>> [0.141s][550409][aot,codecache,stubs]  ;; B2: # out( N1 ) <- in( B1 )  Freq: 0.999999
>> [0.141s][550409][aot,codecache,stubs]   0x00007fed0f9042af:   pop    %rbp
>> [0.141s][550409][aot,codecache,stubs]   0x00007fed0f9042b0:   ret    
>> [0.141s][550409][aot,codecache,stubs]  ;; B3: # out( N1 ) <- in( B1 )  Freq: 1e-06
>> [0.141s][550409][aot,codecache,stubs]   0x00007fed0f9042b1:   pop    %rbp
>> [0.141s][550409][aot,codecache,stubs]   0x00007fed0f9042b2:   jmp    Stub::forward_exception
>> [0.141s][550409][aot,codecache,stubs]   0x00007fed0f9042b7:   hlt    
>> 
>> Look at the instructions generated after the call to runtime method:
>> 
>> 
>> [0.141s][550409][aot,codecache,stubs]   0x00007fed0f90428d:   mov    %r12,0x3e8(%r15)
>> [0.141s][550409][aot,codecache,stubs]   0x00007fed0f9042...
>
>> I suspect I missed porting a change from premain. @adinn @vnkozlov any idea what that could be?
> 
> @ashu-mehra Just to explain what is going on here:
> 
> This is a performance trick. When compressed oops base is null r12 (aka rheapbase) will have been initialized to zero so it can be used as a zero register. This allows, for example, a move instruction to employ a register operand immediate rather than include a 64 bit zero value in the instruction stream, which results in reduced code size. In this case the two moves are zeroing the current Java thread's frame anchor fields, last Java frame pc and sp, which are only set while the thread is in native.
> 
> This trick is fine when generated code is run in the same JVM but no use if the code is generated in a VM with zero compressed oops base then reloaded into a JVM where it is no longer null.
> 
> So, Vladimir's advice is to disable this trick when generating AOT code.

@adinn Do you remember why we commented `UseCompatibleCompressedOops` setting?:
https://github.com/openjdk/leyden/commit/478f86f9cd6df6b92c037c83d0540b9c5fe97e5c

It is still not enabled - how we are not crashing in premain?

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

PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2858861733