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

[David Holmes]

After some side-bar discussions I'm withdrawing my objections to this 
change.

The basic background is that the compilers can perform actions under 
which the interpreter would have marked a CP entry as resolved, but the 
compilers leave it unresolved. This is not a problem for either the 
compilers or the interpreter (if it were to encounter such an entry it 
would trivially resolve it).

Having JVM TI consider a CP entry to a loaded class as being resolved 
when not marked as such, allows for the case where it "should" have been 
resolved but wasn't. There is an additional case where the CP entry 
really is unresolved (ie. no action has happened that would have caused 
the interpreter to resolve it) but the class is independently already 
loaded. That will also be reported as resolved but that is not a problem 
as resolution can be eager or lazy and this mimics eager resolution.

It's possible we may have a test somewhere that is relying on 
implementation knowledge to check for lazy resolution, but if we 
encounter such a test we will just re-educate it.

Thanks for your patience with this Dean.

Cheers,
David

On 6/09/2018 9:37 AM, David Holmes wrote:
> 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
>>>>>
>>>>
>>