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

[dean.long at oracle.com]

Hi David.

Yes, it might feel wrong if we equate the CP tag with the JVM spec 
definition of resolved, but I don't feel that is necessary or accurate.  
I think it's more accurate to treat the system dictionary as the 
ultimate authority.  This change brings JVMTI in line with what the 
compilers have already been doing, it's just that AOT was first to 
expose the discrepancy.  I prefer to think of these symbolic references 
as effectively or virtually resolved, rather than pretend.

I could probably update the CP entry at the same time, to make it less 
pretend or add new APIs to make the abstraction more explicit, but I 
don't think that's necessary.  The JVM spec doesn't talk about CP tags.  
It talks about symbolic references and whether they return the same 
concrete value.

dl


On 9/5/18 2:00 PM, David Holmes wrote:
> 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
>>>
>>