RFR: JDK-8330795 : C2: assert((uint)type <= T_CONFLICT && _zero_type[type] != nullptr) failed: bad type with -XX:-UseCompressedClassPointers

Cesar Soares Lucas cslucas at openjdk.org
Tue May 14 02:51:01 UTC 2024


On Mon, 13 May 2024 23:20:12 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Can you explain more why having klass field load is bad for your code?

The issue involves LoadNKlass, DecodeNKlass and NULL NKlass. It happens when splitting a LoadNKlass through a nullable Phi. In that process another "nullable" Phi of type TypeNarrowKlass may be created merging the "Klass'es" of the original Phi inputs. A NULL NarrowKlass seems to be something not quite well defined: for instance, there is no definition of "_zero_type" for T_METADATA which is the basic type of TypeNarrowKlass. The first commit in this PR was to add this definition. 

However, I think a better approach - than the one from first commit - maybe to instead of creating a Phi of type NarrowKlass create a Phi of type TypePtr that merges DecodeNKlass. By doing so I won't need to create a Phi with a NULL **NKlass** so the original patch isn't necessary. However, in my opinion, doing that is better left for a separate RFE + PR.

> Is it possible to handle such case (loading klass) as separate RFE later?

Yes, I think we can do it as a separate RFE. However, in my experiments klass field loading doesn't appear very often in the benchmarks and therefore may not be much worth the added complication.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19148#issuecomment-2109175690


More information about the hotspot-compiler-dev mailing list