RFR: 8230797: ARM32-softfp: assertion in InterpreterRuntime::resolve_ldc [v2]

[Coleen Phillimore]

On Thu, 8 Jul 2021 10:59:40 GMT, Christoph Göttschkes <cgo at openjdk.org> wrote:

>> src/hotspot/share/interpreter/interpreterRuntime.cpp line 193:
>> 
>>> 191:     Bytecode_loadconstant ldc2(m, last_frame.bci());
>>> 192:     int rindex = ldc2.cache_index();
>>> 193:     if (rindex < 0 && m->constants()->resolved_references_or_null() != NULL)
>> 
>> I don't see how the code can be running in the interpreter before the rewriter runs, which is in the link stage.
>> The cp_to_object_index() should return a negative number for the condy on primitive type case.
>
> I am not sure if I follow you. The problem here is that resolve_ldc is **not** called for a condy, but for a CONSTANT_double. Did you follow the discussion on the mailing list? The bot linked it just now, so you might have missed it.
> But regardless, returning _no_index_sentinel in cp_to_object_index would solve the current problem as well.
> 
> Regardless of what we do for this issue, I have to fix the root cause of all of this later on anyway (making arm32-softfp no longer try to load a CONSTANT_double using the condy helper methods).

I read but didn't match the discussion to the code that I was looking at, which wasn't the arm 32 code.

int ConstantPool::cp_to_object_index(int cp_index) {
  // this is harder don't do this so much.
  int i = reference_map()->find(cp_index);   <==== should crash here
  // We might not find the index for jsr292 call.
  return (i < 0) ? _no_index_sentinel : i;
}

The initial comment in the PR says something about the Double being the first thing executed before the cache is initialized, which is wrong, because the interpreter won't run before linking.  Linking creates the resolved_references and reference_map fields in the constant pool and cpCache. The problem is that if you fall through and use the condy for Double and there are NO other condys or anything creating the resolved_references array, the assert code should crash in cp_to_object_index.  This is because this pointer and _resolved_references aren't initialized for this class.

So the guard before cp_to_object_index would be fine, but put a comment like this.
// For ARM soft float, there may not be any resolved references.

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

PR: https://git.openjdk.java.net/jdk/pull/4582