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

[David Holmes]

On 6/09/2018 7:28 AM, dean.long at oracle.com wrote:
> 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. 

Based on what? When the JVM TI spec talks about a "resolved constant 
pool entry" the only definition for that comes from the JVMS! There is 
nothing else.

> 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'm not aware of any notion of "effectively or virtually resolved". What 
exactly are the compilers doing here?

I don't know where to find the test to determine exactly what the test 
is doing or why it expects to find occurrences of 
JVMTI_HEAP_REFERENCE_CONSTANT_POOL, but I again say either the test is 
wrong in its assumptions, or the compilers are wrong in their actions.

I think this needs a much more in-depth investigation and/or explanation.

David
-----

> 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
>>>>
>>>
>