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]

Thanks David!

dl

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