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]
