RFR: 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"

[serguei.spitsyn at oracle.com]

Hi Chris and Alex,

(I've also included Dan, David and Dean to the mailing list)

We have to reach a consensus about this.

We have 3 options:

Option #1:
   The JIT optimization to delete a code which "looks useless"
   has to be disabled if can_pop_frame capability is enabled.
   Than this problem becomes a JIT compiler bug.

Option #2:
   Consider to relax the JVMTI PopFrame spec by changing it to something 
like:
   "Note however, that the original argument values are not
    preserved and can be changed by the called method;"
   Than this problem becomes a JVM TI spec bug.

Option #3:
   Consider it is Okay for compiler to eliminate useless code,
   so the argument values can be reinitialized by the PopFrame.
   Than this problem becomes just a test bug.


My preference is option #3.
The point is that if the arguments are not really used in
a method then restoring them to any values is a no-op.
It is really meaningless use case, so why should we care about it.

Thanks,
Serguei


On 11/11/19 3:17 AM, serguei.spitsyn at oracle.com wrote:
> Hi Alex,
>
> The fix itself looks Okay.
> Minor: replace in the comment: "compiler don't drop" => "compiler 
> doesn't drop".
>
> However, we still have to reach a consensus on how we treat this issue 
> (as Chris already commented).
>
> Thanks,
> Serguei
>
>
> On 11/8/19 15:22, Alex Menkov wrote:
>> Hi all,
>>
>> Please review the fix for
>> https://bugs.openjdk.java.net/browse/JDK-8215196
>> webrev:
>> http://cr.openjdk.java.net/~amenkov/jdk14/popframe_args/webrev/
>>
>> Currently PopFrame is disabled with JVMCI by [1], so for testing I 
>> reverted [1] changes.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8218025
>>
>> --alex
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20191205/be431f15/attachment.html>