RFR: 8230797: ARM32-softfp: assertion in InterpreterRuntime::resolve_ldc [v2]
Christoph Göttschkes
cgo at openjdk.java.net
Mon Jul 12 09:56:53 UTC 2021
On Fri, 9 Jul 2021 01:44:07 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:
>> 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.
>
> I wonder if this also a problem if we only condy to a primitive type in the class file so that the resolved_references aren't created. Code from the rewriter:
>
>
> if (tag.is_method_handle() ||
> tag.is_method_type() ||
> tag.is_string() ||
> (tag.is_dynamic_constant() &&
> // keep regular ldc interpreter logic for condy primitives
> is_reference_type(Signature::basic_type(_pool->uncached_signature_ref_at(cp_index))))
> ) {
> int ref_index = cp_entry_to_resolved_references(cp_index);
I looked through the available condy test cases and think that this case should be covered by `CondyReturnPrimitiveTest.java` and probably `TestDynamicConstant.java`.
-------------
PR: https://git.openjdk.java.net/jdk/pull/4582
More information about the hotspot-runtime-dev
mailing list