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.spit...@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
