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

(ref) Support for object pooling (using java.lang.ref subclasses)

    XMLWordPrintable

    Details

    • Type: Enhancement
    • Status: Open
    • Priority: P4
    • Resolution: Unresolved
    • Affects Version/s: 1.4.0, 1.4.1
    • Fix Version/s: None
    • Component/s: core-libs
    • Labels:
    • Subcomponent:
    • CPU:
      generic, x86
    • OS:
      generic, windows_2000

      Description



      Name: rmT116609 Date: 01/08/2002


       DESCRIPTION OF THE PROBLEM :

      Problem:
      Object pooling is a technique to improve performance by reusing objects rather than creating new ones. To pool
      objects, it is necessary to determine when there are no remaining references to the object, then place this object
      on a queue. There is currently no support in the JVM or Java APIs for detecting when an object has no remaining
      references. While Object.finalize() is eventually called when the object has no references and can be used to
      resurrect the object, but this technique will only work once because finalized() is guaranteed to only be called only
      once. The subclasses of java.lang.ref.Reference are likewise no help because by the time a reference is enqueued, its
      referant no longer available for resurrection.

      Thus, it falls to the developer to determine when an object is poolable. Effectively, the developer becomes responsible
      for memory management, with all the dangers that entails (and that Java generally avoids with automatic garbage collection).

      Proposal:

       Create two new types of java.lang.Reference that can be used to notify the developer when an object is poolable:

      java.lang.ref.FinalReference would be enqueued when there are no other strong references to the referant. However,
      unlike all other subclasses of java.lang.ref.Reference, the object would still be available for resurrection using
      Reference.get() when the reference is enqueued.

      java.lang.ref.SoftFinalReference would behave like FinalReference except that refereants will not be enqueued
      if there is a low memory condition (following the same algorithm as java.lang.ref.SoftReference). This would enable
      memory-sensitive pooling.

      Additional Benefits:

       One additionial advantage of FinalReference is that it would enable examination of an object (e.g. for logging
      purposes) before that object is garbage collected.


      STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
      1. Try to do pooling manually with a complex project.
      2. Get memory management problems :-)

      CUSTOMER WORKAROUND :

      Perform pooling manually and use sophisticated tools and lots of time to track down errors.
      (Review ID: 138035)
      ======================================================================

        Attachments

          Activity

            People

            Assignee:
            mr Mark Reinhold
            Reporter:
            rmandalasunw Ranjith Mandala (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Dates

              Created:
              Updated:
              Imported:
              Indexed: