-
Bug
-
Resolution: Fixed
-
P3
-
repo-valhalla
For the following bytecodes:
0: iload_0
1: ifeq 12
4: iconst_5
5: anewarray #2 // class "QV;"
8: astore_1
9: goto 18
12: bipush 10
14: anewarray #2 // class "QV;"
17: astore_1
>> 18: aload_1
19: iconst_0
20: aaload
At bytecode 18, the type of local #1 is merged. BlockBegin::try_merge() would just tag it as an object, losing the exact type information, which should be "[QV;".
Because the aaload bytecode at 20 doesn't carry type information, it has no idea whether it suppose to access a flattened array.
Only aaload/asstore seem to be affected. For example, getfield carry type information so it knows whether it's accessing a flattened field or not.
0: iload_0
1: ifeq 12
4: iconst_5
5: anewarray #2 // class "QV;"
8: astore_1
9: goto 18
12: bipush 10
14: anewarray #2 // class "QV;"
17: astore_1
>> 18: aload_1
19: iconst_0
20: aaload
At bytecode 18, the type of local #1 is merged. BlockBegin::try_merge() would just tag it as an object, losing the exact type information, which should be "[QV;".
Because the aaload bytecode at 20 doesn't carry type information, it has no idea whether it suppose to access a flattened array.
Only aaload/asstore seem to be affected. For example, getfield carry type information so it knows whether it's accessing a flattened field or not.
- relates to
-
JDK-8225371 [lworld][c1] TestLWorld.java fails with -DVerifyVM=true
-
- Resolved
-