Something like what you're describing might be doable with SoftReference objects.  
Basically, you could consider a SoftReference to be much like a regular reference 
except that, whereas the GC must respect regular references at all times, it's allowed 
to ignore SoftReferences when it's trying to free memory.  The guarantee is that 
SoftReferences will be broken before memory runs out (whereas, of course, regular ones 
aren't).  JVMs can do as they want with them (regarding the choice to reclaim or not) 
the rest of the time, but I don't think they're particularly aggressive on them.

In this case, if your pointers were SoftReferences, then everything would be in a 
GC-enforced expirable cache.  If a subtree is accessed prior to the GC reclaiming it, 
the accessing body would contain a hard reference to it.  The hard reference trumps 
the soft one, so the subtree is now safe from collection until the hard reference is 
released.  If the subtree's children should be held on to at this time, then it will 
need to hold hard references to them as well.

The biggest issue in working with References is in analyzing how the part of the 
program using SoftReferences will interact with the rest of the program.  An entire 
chunk of your program can use regular references internally, but if that chunk is 
softly referred to the rest of the program, the entire chunk can be GCed as needed.  
Using hard references internally in that subsystem, though, ensures that the entire 
subsystem is atomically GCed, whereas with soft references, anything could go at any 
time.

This can be a complex and dicey issue, and I'd be happy to discuss it with you 
further, but maybe we should take the conversation off-line, since it doesn't seem to 
be FOP specific?

-----Original Message-----
From: Peter B. West [mailto:pbwest@;powerup.com.au]
Sent: Thursday, November 07, 2002 10:21 AM
To: [EMAIL PROTECTED]
Subject: Re: HashMaps (WAS:RE: interface instead of implementation)

Instead of using direct references for the C and P pointers, I have been 
thinking vaguely about using "some kind of" indirect reference - type 
unknown as yet.  Ignoring R pointers for now, if I want to cache a 
subtree, the Reference objects seem to offer the possibility of 
indicating that the caching is required, and leaving the actual caching 
operation until GC demands it.  If the "cached" subtree is accessed in 
the meantime, it should be pushed to the end of the caching queue.  If 
the memory is reclaimed, the Reference object is alerted, and arranges 
to do the actual caching, then converts itself to a different kind of 
indirect reference, one which, when normally accessed, will arrange to 
retrieve the cached subtree, and reestablish it as a "pending".

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to