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

(ref) SoftReference.setLifeExpectancy() to influence object retention

    XMLWordPrintable

    Details

    • Type: Enhancement
    • Status: Open
    • Priority: P5
    • Resolution: Unresolved
    • Affects Version/s: 6
    • Fix Version/s: None
    • Component/s: core-libs
    • Labels:
    • Subcomponent:
    • CPU:
      x86
    • OS:
      windows_xp

      Description

      A DESCRIPTION OF THE REQUEST :
      The current JVM's seems to clear SoftReferences depending on LRU and a JVM setting like -XX:SoftRefLRUPolicyMSPerMB and -server options.
      Mainly this means that all SoftReferences are handled the same, and life expectancy cannot be specified or be influences (except doing near busy get() on all SoftReferences used, "near busy gets" since LRU timeout cannot be read anywhere and SoftRefLRUPolicyMSPerMB default is 1000ms in client vm)


      JUSTIFICATION :
      For many applications the developer knows how long an object is expected to live as long memory is available

      EXPECTED VERSUS ACTUAL BEHAVIOR :
      EXPECTED -
      Influence the SoftReference LRU timeout, the problem can be solved by,
      adding one method to SoftReference.java:

      public void setLifeExpectancy(int ms)
      {
          timestamp += ms;
      }

      This would give the developer possibility to specify how long an object should be kept as long memory is available.
      ACTUAL -
      LRU timeout is currently influenced by -XX:SoftRefLRUPolicyMSPerMB and -server settings (and implementations can vary between JVM vendors)

      ---------- BEGIN SOURCE ----------
      import java.lang.ref.SoftReference;
      //the program result will match the description on http://java.sun.com/docs/hotspot/HotSpotFAQ.html, but in normal swing applications we see that Softreference are not kept longer than 1 sec, unless we specify JVM options -server, -Xms or -XX:SoftRefLRUPolicyMSPerMB or "near busy get" on SoftReference even we only use 11MB from a total heap of 23MB
      public class SoftReferenceDemo
      {
      public static void main(String[] args) throws Exception
      {
      System.out.println("starting with free / total bytes: "+Runtime.getRuntime().freeMemory()+" / "+Runtime.getRuntime().totalMemory());

      SoftReference ref = new SoftReference(new String("myobj"));

      System.out.println("allocating objects");

      Object[] allocateMBs = new Object[256000];
      for (int i = 0; i < allocateMBs.length; i++)
      {
      allocateMBs[i] = new Integer(i); //allocate mem
      }
      System.out.println("free / total bytes: "+Runtime.getRuntime().freeMemory()+" / "+Runtime.getRuntime().totalMemory());

      System.out.println("dereference objects");

      for (int i = 0; i < allocateMBs.length; i++)
      {
      allocateMBs[i] = null; //create garbage
      }

      Thread.sleep(2000);//make probable Gc has ran, and we exceed SoftReference LRU

      System.out.println("free / total bytes: "+Runtime.getRuntime().freeMemory()+" / "+Runtime.getRuntime().totalMemory());

      if (ref.get() == null)
      {
      System.out.println("You lost the object, even still plenty of memory is available or can be allocated from OS");
      }
      else
      {
      System.out.println("No problem");
      }
      }
      }

      ---------- END SOURCE ----------

      CUSTOMER SUBMITTED WORKAROUND :
      no real workarround for caching data efficiently

        Attachments

          Activity

            People

            Assignee:
            mr Mark Reinhold
            Reporter:
            ndcosta Nelson Dcosta (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Dates

              Created:
              Updated:
              Imported:
              Indexed: