After having reserved an address range for the Klass encoding range, we either:
a) Place CDS, then class space, into that address range
b) Place only class space in that range (if CDS is off).
In both cases, we might end up with the encoding base pointing to the start of the archive (unless we are allowed to and manage to run zero-based).
If we wrongly decode an nKlass-id of 0, and the encoding base is not null, the resulting pointer points to the start of the class range. That area is readable, albeit unused both CDS (a) and Metaspace (b) make sure that nothing can be placed there.
On debug this is rare - we usually catch an assert before on decode_not_null(Klass*). On release builds, we could have read an nKlassID of 0 from somewhere and then have decoded it and continued to use it. This happens and if it does, it is cumbersome to analyze.
Therefore, it would be good to establish a no-access zone at the encoding range's start and write protect it. Dereferencing such an nKlass would result in an immediate crash.
This would closely mimic what we do in the compressed-oops-enabled java heap.
a) Place CDS, then class space, into that address range
b) Place only class space in that range (if CDS is off).
In both cases, we might end up with the encoding base pointing to the start of the archive (unless we are allowed to and manage to run zero-based).
If we wrongly decode an nKlass-id of 0, and the encoding base is not null, the resulting pointer points to the start of the class range. That area is readable, albeit unused both CDS (a) and Metaspace (b) make sure that nothing can be placed there.
On debug this is rare - we usually catch an assert before on decode_not_null(Klass*). On release builds, we could have read an nKlassID of 0 from somewhere and then have decoded it and continued to use it. This happens and if it does, it is cumbersome to analyze.
Therefore, it would be good to establish a no-access zone at the encoding range's start and write protect it. Dereferencing such an nKlass would result in an immediate crash.
This would closely mimic what we do in the compressed-oops-enabled java heap.
- causes
-
JDK-8350768 Failing tests after JDK-8330174
-
- Closed
-
- relates to
-
JDK-8351040 [REDO] Protection zone for easier detection of accidental zero-nKlass use
-
- Open
-
- links to
-
Commit(master) openjdk/jdk/a70eba8e
-
Review(master) openjdk/jdk/19290
-
Review(master) openjdk/jdk/23190