Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8330174

Protection zone for easier detection of accidental zero-nKlass use

XMLWordPrintable

    • Icon: Enhancement Enhancement
    • Resolution: Fixed
    • Icon: P4 P4
    • 25
    • 25
    • hotspot
    • b12

      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.

            stuefe Thomas Stuefe
            stuefe Thomas Stuefe
            Votes:
            0 Vote for this issue
            Watchers:
            9 Start watching this issue

              Created:
              Updated:
              Resolved: