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

Andrew Dinn adinn at openjdk.org
Thu Feb 26 15:43:25 UTC 2026


On Tue, 24 Feb 2026 06:15:26 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add AOT logging for C strings
>
> Consider also next change (ignore `cds_code_size` code):
> https://github.com/openjdk/leyden/commit/2b1c82cb276c016ebde9df4145239a422c1fdaeb
> 
> and next related change:
> https://github.com/openjdk/leyden/commit/324de89dd1fd0b48662df9701c5dc678a5cc7cde

@vnkozlov I merged the AOT runtime constants patch into my tree in this [experimental branch](https://github.com/adinn/jdk/tree/save-stubgen-stubs-aotrc). When I build it I am still seeing the same crash in the x86 static code caused by a bad object handle pulled out of an array. This only manifests when I test with the bundle built on github. My local static x86 build runs fine. 

In the latest build I managed to diagnose the problem to something very specific (see attached hs_err file). The crash happens in `MethodTypeForm.canonicalize` which gets called from `MethodTypeForm.canonicalizeAll` to process a specific element of a `Class[]`. The `Class[]` is very likely to have been copied by a call to clone().

The error happens at the point where this code is executed

    static Class<?> canonicalize(Class<?> t, int how) {
        if (t == Object.class) {
            // no change, ever
        } else if (!t.isPrimitive()) { <===

TheA SEGV happens at address 0x00007fbaa4071e54 and the compiled method code is:

[Verified Entry Point]
  # {method} {0x0000000032927f98} 'canonicalize' '(Ljava/lang/Class;I)Ljava/lang/Class;' in 'java/lang/invoke/MethodTypeForm'
  # parm0:    rsi:rsi   = 'java/lang/Class'
  # parm1:    rdx       = int
  #           [sp+0x60]  (sp of caller)
  0x00007fbaa4071e00:   mov    %eax,-0x14000(%rsp)
  0x00007fbaa4071e07:   push   %rbp
  0x00007fbaa4071e08:   sub    $0x50,%rsp
  0x00007fbaa4071e0c:   cmpl   $0x8a20,0x60(%r15)
  0x00007fbaa4071e14:   je     0x00007fbaa4071e1b
  0x00007fbaa4071e16:   call   0x00007fbaab5ba920           ;   {runtime_call final_blob (stub gen)}
  0x00007fbaa4071e1b:   mov    %rsi,0x40(%rsp)
  0x00007fbaa4071e20:   movabs $0x7fba70013340,%rdi
  0x00007fbaa4071e2a:   mov    0x8(%rdi),%ebx
  0x00007fbaa4071e2d:   add    $0x2,%ebx
  0x00007fbaa4071e30:   mov    %ebx,0x8(%rdi)
  0x00007fbaa4071e33:   and    $0xffe,%ebx
  0x00007fbaa4071e39:   test   %ebx,%ebx
  0x00007fbaa4071e3b:   je     0x00007fbaa4071f8b
  0x00007fbaa4071e41:   movabs $0x40000082908w,%rdi          ;   {oop(a 'java/lang/Class'{0x0000040000082908} = 'java/lang/Object')}
  0x00007fbaa4071e4b:   cmp    %rdi,%rsi
  0x00007fbaa4071e4e:   je     0x00007fbaa4071f71
  0x00007fbaa4071e54:   movsbl 0x2c(%rsi),%edi              ; implicit exception: dispatches to 0x00007fbaa4071fac
  . . .


The value in RSI is:

RSI=0x0000200000414840


The error follows a failed compare of `rsi` against constant `0x40000082908` i.e. this is the compare to see if the incoming class is `java.lang.Object`. However, note that `0x0000200000414840` == `0x40000082908 << 3`.

So, the `Class<?>` object that has been pulled out of the array and passed as argument to `canonicalize` has been shifted left by 3. I'm not yet sure where this is happening. It may well be happening under a call to clone(). However, it may possibly be an invalid oop stored in the heap image. I'll keep looking.

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

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


More information about the hotspot-dev mailing list