|
From: Chris on 4 Jul 2008 14:18 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 4 Jul 2008 15:58 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 4 Jul 2008 17:00 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 5 Jul 2008 14:02 > > 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 5 Jul 2008 14:56
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 |