-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
P4
-
Affects Version/s: repo-valhalla
-
Component/s: hotspot
I wonder what this method is trying to do. This method only does something if `klass_is_exact` is true. But in that case, the TypeAryKlassPtr is a constant already. Should `exact_klass` return the correct ciKlass?
I believe there are 2 problems here:
- It may create a nonsensical ciKlass (a non-atomic nullable array).
- A TypeAryKlassPtr generally does not have a ciKlass, it only has that field for primitive arrays to differentiate boolean[], byte[], short[], char[], int[]. This fact is also kind of necessary, because there is no way to decide which would be the ciKlass for different kinds of T[] since there is no relationship between the nullable T[] and the null-restricted T[], especially if the type is not a constant. For arrays of value types, we also have different kinds of atomic refined types, too.
I believe there are 2 problems here:
- It may create a nonsensical ciKlass (a non-atomic nullable array).
- A TypeAryKlassPtr generally does not have a ciKlass, it only has that field for primitive arrays to differentiate boolean[], byte[], short[], char[], int[]. This fact is also kind of necessary, because there is no way to decide which would be the ciKlass for different kinds of T[] since there is no relationship between the nullable T[] and the null-restricted T[], especially if the type is not a constant. For arrays of value types, we also have different kinds of atomic refined types, too.
- relates to
-
JDK-8366705 [lworld] Re-work of arrays meta-data
-
- Resolved
-