Details
-
Type:
Bug
-
Status: Resolved
-
Priority:
P3
-
Resolution: Fixed
-
Affects Version/s: repo-valhalla
-
Fix Version/s: repo-valhalla
-
Component/s: hotspot
-
Subcomponent:
Description
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.
Attachments
Issue Links
- relates to
-
JDK-8225371 [lworld][c1] TestLWorld.java fails with -DVerifyVM=true
-
- Resolved
-