The test sets compile threshold to be zero
(-Djava.lang.invoke.MethodHandle.COMPILE_THRESHOLD=0 ). I think
compilation occurs on the first invoke.
Also, I ran the test on a jdk8 build without Vladimir's fix - I saw the
exception being thrown. I ran it by passing the above option in the
command line (outside jtreg).
-Sundar
On Thursday 16 January 2014 02:10 PM, Jochen Theodorou wrote:
Hi,
since I am indirectly the reporter of this bug I have one remark for
the test. The error happens only for compiled lambda forms. The given
test does imho not use a compiled lambda form. In other words, afaik
the test would pass without the fix. As such it would be useless as
regression test.
Am 15.01.2014 16:31, schrieb Vladimir Ivanov:
http://cr.openjdk.java.net/~vlivanov/8031502/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8031502
InvokeBytecodeGenerator can produce incorrect bytecode for a LambdaForm
when invoking a method from Object declared in an interface.
The problem is the following:
(1) java.lang.CharSequence interface declares abstract method
"String
toString()";
(2) after 8014013 fix, VM resolves
CharSequence::toString()/invokeInterface to
CharSequence::toString()/invokeVirtual;
(3) during LambdaForm compilation, CharSequence is considered
statically invocable (see
InvokeBytecodeGenerator::isStaticallyInvocable) and invokevirtual for
CharSequence::toString() is issued, which is wrong (invokevirtual throws
ICCE if it references an interface);
The fix is straightforward: during LambdaForm compilation, switch back
from invokevirtual to invokeinterface instruction when invoking a method
on an interface.
The fix is targeted for 8. Will be also integrated into 9.
Testing: regression test, jdk/test/java/lang/invoke, vm.mlvm.testlist,
nashorn, jruby.
Thanks!
Best regards,
Vladimir Ivanov
_______________________________________________
mlvm-dev mailing list
mlvm-...@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
