Re: Controlling SoftReferences

Discussion in 'Java' started by Kevin McMurtrie, Jul 4, 2008.

  1. In article <486e62ba$0$22390$>,
    Chris <> wrote:

    > I'm implementing a memory-sensitive cache using
    > java.lang.ref.SoftReference. I'm wondering if I can control the sequence
    > in which the references are released.
    >
    > Here's the idea: three objects, A, B, and C. My main class holds a hard
    > reference to A. A holds a soft reference to B, and B holds a soft
    > reference to C.
    >
    > I never want B released unless C is also released. If I have C hold a
    > hard reference to B, will that achieve it?
    >
    > Here's the actual application: I'm writing a btree. I'd like to cache as
    > much as possible in memory, particularly upper-level parent nodes. I
    > can't use hard references, though, because we may have to operate in low
    > and unpredictable memory conditions. So A is the root node, B is a
    > non-leaf node, and C is a leaf node. I want leaf nodes released before
    > parent nodes, both for performance reasons and because navigating the
    > tree is easier if a node's parent is always available.
    >
    > Or maybe there's a better way to do this altogether. Any ideas welcome.


    Can you control which JVM is used? Sun's is an LRU model that will
    probably do what you want.

    I would never allow a program to get into the state where a partial
    cache must work. Sooner or later you'll hit a usage pattern where
    memory caching yields no hits and the program will die. I'd change the
    system requirements such that there is guaranteed to be enough memory or
    a fast enough disk/database to always work. Partial caching is valuable
    for reducing average latency but you don't want to bet the program's
    survival on it.

    Back in the Java 1.0 days, I created a tree of a data objects that
    implemented their own virtual memory. It had states to represent
    available memory: Lazy-load memory-only caching, memory caching with
    asynchronous flush to disk, and disk-only caching. The first two states
    were guestimated. The last state was implemented by catching
    OutOfMemoryError, rolling back a transaction, changing states, and
    resuming. Rolling back a change after running out of memory was hard to
    do! This tree of 40000 objects had to run in 90MB of memory and support
    about 100 concurrent read/write transactions at once. Multithreading
    never seemed hard after getting that working.

    --
    I will not see your reply if you use Google.
     
    Kevin McMurtrie, Jul 4, 2008
    #1
    1. Advertising

  2. In article <>,
    Chris <> wrote:

    > >
    > > Can you control which JVM is used? Sun's is an LRU model that will
    > > probably do what you want.
    > >

    >
    > Thanks, good suggestions.
    >
    > Do you have a reference for this? A little googling didn't turn it up.
    > If Sun clears softreferences in a lru sequence then my worries are over.


    http://blogs.sun.com/watt/resource/jvm-options-list.html

    -XX:SoftRefLRUPolicyMSPerMB=<value>

    Sun uses a very broken method of managing SoftReferences. You should
    know about their dirty secret if you're using them a for a significant
    portion of the total heap size. I've seen applications spend 99.99% of
    their CPU time in GC with in a 14 GB heap because, by default,
    SoftReferences were locked into memory for at least 4 hours or until the
    passing of several consecutive full GC failures. Several consecutive
    full GC failures doesn't happen quickly on a 14 GB heap.

    --
    I will not see your reply if you use Google.
     
    Kevin McMurtrie, Jul 6, 2008
    #2
    1. Advertising

  3. On 2008-07-06 09:00 +0100, Kevin McMurtrie allegedly wrote:
    > http://blogs.sun.com/watt/resource/jvm-options-list.html
    >
    > -XX:SoftRefLRUPolicyMSPerMB=<value>
    >
    > Sun uses a very broken method of managing SoftReferences. You should
    > know about their dirty secret if you're using them a for a
    > significant portion of the total heap size. I've seen applications
    > spend 99.99% of their CPU time in GC with in a 14 GB heap because, by
    > default, SoftReferences were locked into memory for at least 4 hours
    > or until the passing of several consecutive full GC failures.
    > Several consecutive full GC failures doesn't happen quickly on a 14
    > GB heap.


    Could you please elaborate on that, or rather, provide some papers? I
    distinctively remember testing code that depended on SoftReferences
    being released, and finding they were indeed properly released pretty
    quickly, maybe after prompting a GC'ion and a little yielding. I don't
    wish to call your claims wrong, but it would seem to me, given my
    experience, that they cannot be valid for each and every configuration
    and/or situation.

    --
    DF.
    to reply privately, change the top-level domain
    in the FROM address from "invalid" to "net"
     
    Daniele Futtorovic, Jul 7, 2008
    #3
  4. In article <g4t56o$hpp$>,
    Daniele Futtorovic <> wrote:

    > On 2008-07-06 09:00 +0100, Kevin McMurtrie allegedly wrote:
    > > http://blogs.sun.com/watt/resource/jvm-options-list.html
    > >
    > > -XX:SoftRefLRUPolicyMSPerMB=<value>
    > >
    > > Sun uses a very broken method of managing SoftReferences. You should
    > > know about their dirty secret if you're using them a for a
    > > significant portion of the total heap size. I've seen applications
    > > spend 99.99% of their CPU time in GC with in a 14 GB heap because, by
    > > default, SoftReferences were locked into memory for at least 4 hours
    > > or until the passing of several consecutive full GC failures.
    > > Several consecutive full GC failures doesn't happen quickly on a 14
    > > GB heap.

    >
    > Could you please elaborate on that, or rather, provide some papers? I
    > distinctively remember testing code that depended on SoftReferences
    > being released, and finding they were indeed properly released pretty
    > quickly, maybe after prompting a GC'ion and a little yielding. I don't
    > wish to call your claims wrong, but it would seem to me, given my
    > experience, that they cannot be valid for each and every configuration
    > and/or situation.


    I was curious about this, too. Apparently, it's more of a problem for a
    server JVM. SoftRefLRUPolicyMSPerMB is an "integer values representing
    milliseconds per MB of free memory." The Sun HotSpot FAQ says, "The Java
    HotSpot Server VM uses the maximum possible heap size (as set with the
    -Xmx option) to calculate free space remaining."

    14,000 MB * 1 ms/MB / 3600 s/h ~= 4 h

    <http://java.sun.com/docs/hotspot/HotSpotFAQ.html>

    --
    John B. Matthews
    trashgod at gmail dot com
    home dot woh dot rr dot com slash jbmatthews
     
    John B. Matthews, Jul 7, 2008
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Niv
    Replies:
    9
    Views:
    829
    Mike Treseler
    Jan 5, 2006
  2. Natty Gur

    Re: Controlling page from a Thread

    Natty Gur, Jun 26, 2003, in forum: ASP .Net
    Replies:
    11
    Views:
    1,213
  3. Kevin Spencer

    Re: Controlling Close button of browser

    Kevin Spencer, Jun 26, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    519
    Kevin Spencer
    Jun 26, 2003
  4. Jesper Nordenberg

    Using SoftReferences for caching

    Jesper Nordenberg, Feb 12, 2004, in forum: Java
    Replies:
    5
    Views:
    649
    Conor White
    Feb 15, 2004
  5. Joe
    Replies:
    11
    Views:
    839
    steve
    Apr 2, 2006
Loading...

Share This Page