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

prepareFinalization() in gc.c doesn't trace FinalizeMeQ if HasFinalizerQ is null

    XMLWordPrintable

Details

    • 1.0.2
    • sparc
    • solaris_2.4
    • Not verified

    Description

      The garbage collector traces objects on the FinalizeMeQ and any object referenced
      from the BeingFinalized variable so that these objects pending finalization, or any
      objects they reference, won't be freed by GC. However, in the current implementa-
      tion of this in prepareFinalization() of gc.c, we only do this if HasFinalizerQ (a
      queue of all non-garbage objects that have finalize() methods) is empty. We
      should trace FinalizeMeQ and BeingFinalized in all cases.

      I'm reporting this as a low-priority bug as I don't yet have evidence that it can
      actually happen. It was reported by Bertrand Delsart of OSF, who I've asked
      whether he's seen something go wrong as a result, or if this is from staring at
      the code. It is certainly the case that even running a trivial main(), there are
      things on the HasFinalizerQ as a result of startup, and on shutdown I've
      observed that there are 2-3 things like objects for stdout loitering around
      keeping HasFinalizerQ from being null. However, in conjunction with finaliza-
      tion on exit, where we zero the HasFinalizerQ, any GC caused by finalization
      would not keep any garbage objects with finalizers around, so would certainly
      tickle this bug.

      Attachments

        Activity

          People

            tlindholsunw Timothy Lindholm (Inactive)
            tlindholsunw Timothy Lindholm (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: