JDK-8207170 : [lworld] Tests fail with IncompatibleClassChangeError after "Add value types consistency checks" change
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: repo-valhalla
  • Priority: P1
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2018-07-12
  • Updated: 2018-07-19
  • Resolved: 2018-07-19
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.

To download the current JDK release, click here.
Other
repo-valhallaResolved
Related Reports
Duplicate :  
JDK-8207790 - [lworld] update reflection to generate ValueTypes attribute
Relates :  
JDK-8207238 - [lworld] ValueConstructorRef fails with ICCE with ValueTypes Consistency checking
Relates :  
JDK-8207207 - [lworld] test/jdk/valhalla/valuetypes/ValueBootstrapMethod fails with ICCE
Relates :  
JDK-8207239 - [lworld] ValueConstructorRef.java fails with ICCE after ValueTypes attribute checks
Description
Some tests fail with InvocationTargetException after http://hg.openjdk.java.net/valhalla/valhalla/rev/a5573f4f6392

test/langtools/tools/javac/valhalla/lworld-values/ValueConstructorRef.java:

java.lang.IncompatibleClassChangeError
	at ValueConstructorRef.main(ValueConstructorRef.java:46)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115)
	at java.base/java.lang.Thread.run(Thread.java:832)

test/hotspot/jtreg/compiler/valhalla/valuetypes/TestNewAcmp.java

[...]
Testing testEq02_1(null, null)
----------System.err:(20/1270)----------
java.lang.reflect.InvocationTargetException
	at jdk.internal.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at compiler.valhalla.valuetypes.TestNewAcmp.runTest(TestNewAcmp.java:1375)
	at compiler.valhalla.valuetypes.TestNewAcmp.run(TestNewAcmp.java:1401)
	at compiler.valhalla.valuetypes.TestNewAcmp.main(TestNewAcmp.java:1414)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115)
	at java.base/java.lang.Thread.run(Thread.java:832)
Caused by: java.lang.IncompatibleClassChangeError
	... 12 more
Comments
hotspot_valhalla and jdk_valhalla tests all pass with the fix for JDK-8207790 and JDK-8207194.
19-07-2018
I'm closing this as duplicate of JDK-8207790.
19-07-2018
ICCE now includes the info why the exception is thrown: ICCE thrown from TestNewAcmp.java: java.lang.reflect.InvocationTargetException at jdk.internal.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at compiler.valhalla.valuetypes.TestNewAcmp.runTest(TestNewAcmp.java:1375) at compiler.valhalla.valuetypes.TestNewAcmp.run(TestNewAcmp.java:1401) at compiler.valhalla.valuetypes.TestNewAcmp.main(TestNewAcmp.java:1414) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) at java.base/java.lang.Thread.run(Thread.java:832) Caused by: java.lang.IncompatibleClassChangeError: signature (Lcompiler/valhalla/valuetypes/MyValue;Lcompiler/valhalla/valuetypes/MyValue;)Z inconsistent value type: jdk.internal.reflect.GeneratedMethodAccessor7 compiler.valhalla.valuetypes.TestNewAcmp
16-07-2018
[~acorn] what are the three tests you referred to? FAILED: compiler/valhalla/valuetypes/TestLWorld.java FAILED: compiler/valhalla/valuetypes/TestNewAcmp.java FAILED: runtime/valhalla/valuetypes/ValueOops.java
16-07-2018
Thank you very much Harold - so this matches my hope that the TestNewAcmp failure actually has the same root cause - which is that Reflection is not generating ValueTypes attribute information. Mandy - if you could possibly first add basic reflection ValueTypes attribute generation - and then rerun the three tests here - and let us know what you find. Fingers crossed that may be sufficient to at least fix this one.
13-07-2018
hotspot/jtreg/compiler/valhalla/valuetypes/TestNewAcmp.java is failing here: V [libjvm.so+0xe5893f] InstanceKlass::check_signature_for_value_types_consistency(Symbol*, InstanceKlass*, InstanceKlass*, Thread*)+0x3df V [libjvm.so+0x1218b6a] LinkResolver::check_method_value_types_consistency(LinkInfo const&, methodHandle const&, Thread*)+0x16a V [libjvm.so+0x12197f9] LinkResolver::resolve_method(LinkInfo const&, Bytecodes::Code, Thread*)+0x229 V [libjvm.so+0x121c324] LinkResolver::linktime_resolve_virtual_method(LinkInfo const&, Thread*)+0x34 V [libjvm.so+0x1220c30] LinkResolver::resolve_invokevirtual(CallInfo&, Handle, constantPoolHandle const&, int, Thread*)+0xe0 V [libjvm.so+0x1220d5b] LinkResolver::resolve_invoke(CallInfo&, Handle, constantPoolHandle const&, int, Bytecodes::Code, Thread*)+0xab V [libjvm.so+0xe8bc25] InterpreterRuntime::resolve_invoke(JavaThread*, Bytecodes::Code)+0x1c5 V [libjvm.so+0xe946a3] InterpreterRuntime::resolve_from_cache(JavaThread*, Bytecodes::Code)+0xe3 j jdk.internal.reflect.GeneratedMethodAccessor7.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+48 J 149 c2 compiler.valhalla.valuetypes.TestNewAcmp.runTest(Ljava/lang/reflect/Method;[Ljava/lang/Object;II)V (489 bytes) @ 0x00007f144cbb0fa8 [0x00007f144cbb0740+0x0000000000000868] j compiler.valhalla.valuetypes.TestNewAcmp.run(I)V+101 j compiler.valhalla.valuetypes.TestNewAcmp.main([Ljava/lang/String;)V+20 ... In InstanceKlass::check_signature_for_value_types_consistency(), the variables have the following values when the check fails: k1: jdk/internal/reflect/GeneratedMethodAccessor7 k2: compiler/valhalla/valuetypes/TestNewAcmp name: compiler/valhalla/valuetypes/MyValue sym: compiler/valhalla/valuetypes/MyValue opinion1: 0 opinion2: 1 It looks like the problem is that jdk.internal.reflect.MethodAccessorGenerator generates GeneratedMethodAccessor7 without a needed ValueTypes attribute.
13-07-2018
Mandy, I opened a new bug to track ValueConstructorRef - 8207238 - and gave it to you. I hear you it may be a lambda issue. I wonder if we need the basic reflection generation of ValueTypes attribute first. Thank you for looking at these.
13-07-2018
test/langtools/tools/javac/valhalla/lworld-values/ValueConstructorRef.java failure may be the similar issue related to the use of lambda as in JDK-8207194. $ java -XX:+EnableValhalla -XX:+UnlockDiagnosticVMOptions -XX:+ShowHiddenFrames ValueConstructorRef Exception in thread "main" java.lang.IncompatibleClassChangeError at ValueConstructorRef$$Lambda$1/0x0000000800060840.get(<Unknown>:1000000) at ValueConstructorRef.main(ValueConstructorRef.java:46)
13-07-2018
Also JDK JTReg test valhalla/valuetypes/ValueBootstrapMethods.java fails when calling int hash = (int)hashCode.invoke(null, value); with: java.lang.reflect.InvocationTargetException at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at ValueBootstrapMethods.main(ValueBootstrapMethods.java:57) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) at java.base/java.lang.Thread.run(Thread.java:832) Caused by: java.lang.IncompatibleClassChangeError at ValueTest.hashCode(Unknown Source) ... 11 more It fails because it uses ASM to generate a class called ValueTest that references value type ValueBootstrapMethods$Value. But, the asm generator for ValueTest does not generate a ValueTypes attribute for it.
12-07-2018
The JDK JTReg java/lang/invoke/VarHandles/VarHandleTestAccess*.java tests now fail with: java.lang.AssertionError: SET. Incorrect throwable thrown, java.lang.IncompatibleClassChangeError. Expected class java.lang.UnsupportedOperationException expected [true] but found [false]
12-07-2018