Details

    • Type: Sub-task
    • Status: Resolved
    • Priority: P2
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 9
    • Component/s: hotspot
    • Labels:
      None
    • Subcomponent:
      gc
    • Resolved In Build:
      b140
    • CPU:
      generic
    • OS:
      generic

      Description

      A concurrent collector may encounter a partially allocated object, e.g. one for which memory has been allocated but it is not yet really an object that the collector can parse or process. Allocation sets the klass to make the object parsable by the collector. This is done last of the low-level object creation initializations, with a release store to ensure that happens after necessary initialization (JDK-8165808).

      The collector distinguishes between those states (pre-object allocated blob vs actual object) using klass_or_null(). Uses of that function need to ensure the read of the klass occurs before reading other parts of the object, needing an acquire/loadload barrier matching the release_store of the klass.

      We don't want to make klass_or_null() quietly have acquire semantics. We want the acquire semantics to be obvious. Also, not all callers need acquire semantics, and for some it is probably even wrong. For example, many uses are in asserts; it would be undesirable to add an acquire barrier only in debug-mode, potentially making races even harder to debug.

      So we need a klass_or_null_acquire() that makes the acquire semantics explicit.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                kbarrett Kim Barrett
                Reporter:
                kbarrett Kim Barrett
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: