On Wed, 4 Feb 2026 12:47:54 GMT, Tobias Hartmann <[email protected]> wrote:

> Old mainline fix [JDK-8134389](https://bugs.openjdk.org/browse/JDK-8134389) 
> modified code in `Invoke::declared_type` to not use the return type of the 
> target signature but use the declared signature instead (see 
> [changeset](https://hg.openjdk.org/jdk9/jdk9/hotspot/rev/4191b33b3629) for 
> details). This was needed for method handle call sites to return 
> `java/lang/invoke/CallSite` instead of `java/lang/Object` or whatever the 
> target method return type would look like. The test 
> `compiler/jsr292/TestArrayReturnType.java` still reliably triggers this 
> scenario.
> 
> Now the problem is that the return type is re-computed on every call to 
> `Invoke::declared_type` but it might actually change from unloaded to loaded 
> in-between and therefore different `ciType` objects will be returned. In the 
> failing case, the return type first is
> `<ciObjArrayKlass name=[Ljava/lang/reflect/Field; loaded=false ident=1498 
> address=0x00007ae57d775728>` 
> and later it's `<ciObjArrayKlass name=[Ljava/lang/reflect/Field; loaded=true 
> ident=1508 address=0x00007ae57d7762a8>` (note the different `loaded` 
> property). This leads to an assertion failure in profiling because we invoke 
> CHA to improve a type that's already final because when we checked the type 
> earlier, it was still unloaded.
> 
> I think it's a general rule that the compiler interface needs to guarantee 
> consistency of types during compilation and therefore I adjusted the code to 
> only compute the return type once. This is a mainline issue and could be 
> fixed in mainline as well. However, as far as I can tell, only Valhalla is 
> currently affected because the Valhalla specific array load/store profiling 
> uses `LIRGenerator::profile_type` in more cases. Let's therefore only fix it 
> in Valhalla for now.
> 
> Thanks,
> Tobias

That looks good to me.

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

Marked as reviewed by chagedorn (Committer).

PR Review: 
https://git.openjdk.org/valhalla/pull/2031#pullrequestreview-3751797422

Reply via email to