RFR(S) 8209361: [AOT] Unexpected number of references for JVMTI_HEAP_REFERENCE_CONSTANT_POOL [111-->111]: 0 (expected at least 1)
david.holmes at oracle.com
Wed Sep 5 23:37:13 UTC 2018
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
> 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.
> 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.
> 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.
>> On 6/09/2018 6:29 AM, coleen.phillimore at oracle.com wrote:
>>> Looks good.
>>> On 8/30/18 8:20 PM, dean.long at oracle.com wrote:
>>>> 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).
More information about the hotspot-dev