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

Finalization not done at exit() and is unnecessarily unreliable

    XMLWordPrintable

    Details

    • Subcomponent:
    • Resolved In Build:
      1.1
    • CPU:
      sparc
    • OS:
      solaris_2.4
    • Verification:
      Not verified

      Description

      In an environment of conservative GC, there cannot be any guarantee that the
      finalize() method of a given object will ever be called before exit. In our runtime
      we don't call outstanding finalization at normal runtime exit, so we can't offer a
      guarantee that a finalize() method will be called at all. I think that this may be
      unnecessary.

      When the runtime exits, there may be objects needing finalization. We should at
      least call runFinalization() to synchronously finalize these on normal exit. However,
      just prior to actual exit all Java objects suddenly become logical garbage. We don't
      necessarily need to call GC to know that, and because of the conservative scanning
      we wouldn't want its opinion anyhow. Instead, we should be able to just take the
      HasFinalizerQ, the list of existing objects with finalize() methods, and move it
      (retaining appropriate order) onto the FinalizeMeQ, queueing *all* finalizable
      objects independent of the conservative scan. We can then finalize synchronously,
      and should know that we've got *everything*. We don't really want to touch the
      existing objects, because finalization may need some of them to do its job.

      If this can be made to work it would provide a guarantee that all finalizers *will*
      be called, although their calling could be arbitrarily delayed. But that's OK for
      someone running Purify on their C code, or who is using finalization to write out
      objects to a persistant object store.

      Of course, finalization might create threads and arbitrarily prolong the computation.
      I don't know whether at-exit finalization causes any new problems here, and need
      to think about that.

        Attachments

          Issue Links

            Activity

              People

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

                Dates

                Created:
                Updated:
                Resolved:
                Imported:
                Indexed: