From: Chris on
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.
From: Mike Schilling on
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?

Yes.

>
> 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.

I'd consider keeping the entire tree in memory, using nodes that are
as small as possible, ideally just pointers to its children and a
SoftReference to all the other information it represents.


From: Kevin McMurtrie on
In article <486e62ba$0$22390$9a6e19ea(a)news.newshosting.com>,
Chris <spam_me_not(a)goaway.com> 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.
From: Chris on

>
> 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.
From: Robert Klemme on
On 04.07.2008 20:18, 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.

I'd rather choose the mental model of sub graphs of the object graph.
Inside you can use hard refs but you need to make sure that all paths
into the subgraph you want to treat as an entity (GC wise) are soft.

> 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?

Yes.

> 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.

Yep, then make the parent ref a strong ref. This will ensure that
parents are always available. Downside is that as long as one leaf is
non collectible at least the path to the root stays as well.

Kind regards

robert