AbstractInterpreter::is_not_reached wrongfully assumes reachability for invokedynamic

[David Holmes]

FYI: https://bugs.openjdk.org/browse/JDK-8359057

David

On 9/06/2025 4:29 am, me at xdark.dev wrote:
>
> Greetings,
> Since JDK-8301995 <https://bugs.openjdk.org/browse/JDK-8301995>, the 
> code to in AbstractInterpreter::is_not_reached(...) for invokedynamic 
> looks like this:
> ```
>       case Bytecodes::_invokedynamic: {
>         assert(invoke_bc.has_index_u4(code), "sanity");
>         int method_index = invoke_bc.get_index_u4(code);
>         return cpool->resolved_indy_entry_at(method_index)->is_resolved();
>       }
> ```
> Is this a bug? Before the change, the code looked like this:
> ```
>       case Bytecodes::_invokedynamic: {
>         assert(invoke_bc.has_index_u4(code), "sanity");
>         int method_index = invoke_bc.get_index_u4(code);
>         return 
> cpool->invokedynamic_cp_cache_entry_at(method_index)->is_f1_null();
>       }
> ```
> The comment for this method says:
> ```
> // Return true if the interpreter can prove that the given bytecode has
> // not yet been executed (in Java semantics, not in actual operation).
> ```
> Shouldn't the is_resolved check be negated? The code is two years old 
> since this change, and it seems like a regression. I'm unable to 
> submit a patch if that is the case, so, if this is a bug, It would be 
> great if someone would fix this.
> Thanks!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-runtime-dev/attachments/20250617/4372daeb/attachment.htm>