RFR(S) 8209361: [AOT] Unexpected number of references for JVMTI_HEAP_REFERENCE_CONSTANT_POOL [111-->111]: 0 (expected at least 1)

[David Holmes]

Hi Dean,

Seems to me that if the test is expecting CP entries to be resolved but 
AOT does not resolve them, then either the test is wrong or AOT is 
wrong. Pretending they are resolved when not, to make the test pass, 
does not seem like the right fix.

David

On 6/09/2018 6:29 AM, coleen.phillimore at oracle.com wrote:
> Looks good.
> Coleen
> 
> On 8/30/18 8:20 PM, dean.long at oracle.com wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8209361
>> http://cr.openjdk.java.net/~dlong/8209361/webrev/
>>
>> Some JCK vm/jvmti/FollowReferences tests fail with AOT.  This is 
>> because code generated by JIT and AOT compilers might not resolve 
>> constant pool entries.  Making the compiled code resolve constant pool 
>> entries would hurt performance.  As far as I can tell, the JVMTI 
>> FollowReferences API is the only place this is visible, so I went with 
>> a localized fix.  The fix looks at unresolved constant pool entries 
>> and treats them as resolved if the class is loaded and accessible. 
>> Some entries can appear to be resolved early, but this is allowed by 
>> the JVM spec, and it meets all the requirements of a resolved symbolic 
>> reference (it will always return the same concrete class value, JVM 
>> spec section 5.4.3).
>>
>> dl
>>
>