JDK-8215196 : [Graal] vmTestbase/nsk/jvmti/PopFrame/popframe003/TestDescription.java fails with "changes for the arguments of the popped frame's method, did not remain current argument values"
Type:Bug
Component:hotspot
Sub-Component:jvmti
Affected Version:11,12
Priority:P5
Status:Open
Resolution:Unresolved
OS:generic
CPU:generic
Submitted:2018-12-11
Updated:2024-07-15
The Version table provides details related to the release that this issue/RFE will be addressed.
Unresolved : Release in which this issue/RFE will be addressed. Resolved: Release in which this issue/RFE has been resolved. Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
Fixed popframe003 fails with
TEST FAILED: changes for the arguments of the popped frame's method, did not remain
current argument values: i=0 l=0 d=0.0 c='\u0000'
Comments
Yes, the other compilers seem to handle this OK.
13-01-2019
Do the other compilers work okay with this? There is always a tension between tooling interfaces that assume the obvious behaviour, and compilers that try to optimise away things that they deem unnecessary. And of course compilers are smarter now than when the JVM TI spec was written. But if we go too far then things like JVM TI become unusable because the user won't know what may actually happen depending on which compiler is in use - that's not a good thing. And test writing is a nightmare because tests become so loose that they barely test anything!
12-01-2019
I think this could be considered a test bug, depending on how we interpret this from the JVMTI spec:
"Note however, that any changes to the arguments, which *occurred* in the *called* method, remain; when execution continues, the first instruction to execute will be the invoke."
If the method was compiled, and no change to the arguments occurred in the compiled method, but it would have occurred in the interpreted method, does that mean PopFrame has violated the JVMTI spec? The compiler is normally free to optimize out unneeded code.
If we interpret "occurred in the called method" to mean "actually occurred in the called method" then it's a test bug. If we interpreted it to mean "should have occurred in the called method, based on the bci and bytecodes", then it's a compiler bug.