Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Re: Controlling SoftReferences

Reply
Thread Tools

Re: Controlling SoftReferences

 
 
Kevin McMurtrie
Guest
Posts: n/a
 
      07-04-2008
In article <486e62ba$0$22390$(E-Mail Removed)> ,
Chris <(E-Mail Removed)> 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.
 
Reply With Quote
 
 
 
 
Kevin McMurtrie
Guest
Posts: n/a
 
      07-06-2008
In article <(E-Mail Removed)>,
Chris <(E-Mail Removed)> 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/j...ions-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.
 
Reply With Quote
 
 
 
 
Daniele Futtorovic
Guest
Posts: n/a
 
      07-07-2008
On 2008-07-06 09:00 +0100, Kevin McMurtrie allegedly wrote:
> http://blogs.sun.com/watt/resource/j...ions-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"
 
Reply With Quote
 
John B. Matthews
Guest
Posts: n/a
 
      07-07-2008
In article <g4t56o$hpp$(E-Mail Removed)>,
Daniele Futtorovic <(E-Mail Removed)> wrote:

> On 2008-07-06 09:00 +0100, Kevin McMurtrie allegedly wrote:
> > http://blogs.sun.com/watt/resource/j...ions-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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Memory leak and SoftReferences Joe Java 11 04-02-2006 09:35 PM
Controlling Window position Daniel Prince Firefox 0 04-15-2005 04:51 PM
Controlling Internet Access on a Home Network =?Utf-8?B?d2lyZWxlc3NiZWdpbm5lcg==?= Wireless Networking 5 03-05-2005 11:32 PM
Automatically controlling where a file will be saved based on file extension and/or origin Daniel Prince Firefox 6 12-11-2004 10:58 PM
Using SoftReferences for caching Jesper Nordenberg Java 5 02-15-2004 10:46 PM



Advertisments