RE: HashMaps (WAS:RE: interface instead of implementation)
Well, we can get as detailed as people want. I just figured that, while we were throwing around ideas about what kind of programming paradigm and idioms we want, we may wish to consider using different kind of Reference objects or Collections that employ them (ala a WeakHashMap) in certain cases. Judiciously used WeakReferences can pay out in spades on memory usage, which can also mean a performance boost in processing time as the GC isn't running as freuqently. We could get more detailed in a discussion of this if you're interested, though...what aspects of Reference use did you want to discuss? -Original Message- From: Peter B. West [mailto:pbwest;powerup.com.au] Sent: Wednesday, November 06, 2002 6:55 PM To: [EMAIL PROTECTED] Subject: Re: HashMaps (WAS:RE: interface instead of implementation) Rhett, Jeremias, I was hoping there might be a little more detailed discussion here. I have no experience of WeakHashMaps or the various Reference objects, but I have been thinking about using Reference objects, rather than direct references, to point to the Nodes in my Tree, with the idea that at least the first iteration in a cache/retrieve cycle on a subtree could be handled transparently within the Tree. Peter Rhett Aultman wrote: Mostly it was for caching benefits. As I said, though, I haven't read enough code to know. I just thought I'd throw it out as a possibile way to save on memory usage when FOP processes large documents. *shrug* ;) -Original Message- From: Jeremias Maerki [mailto:dev.jeremias;greenmail.ch] For caching and if done correctly, yes, there could be benefits. WeakReferences can be used if you have objects you want to keep but you're not angry when they get swept away by the GC. Good for keeping images and fonts in memory, but for overall FOP I don't see any use case. Or can anyone think of another one? On 06.11.2002 18:16:47 Rhett Aultman wrote: You mentioned HashMaps briefly here. I suppose I could try auditing the code and answering my own question here, but I have very little free time in general. (Hopefully, I'll have more free time after Saturday...I've spent a lot of time for weeks studying for the GRE). So, I'll just ask- has anyone considered looking into the potential memory benefits of using WeakHashMaps instead of HashMaps? -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: HashMaps (WAS:RE: interface instead of implementation)
I didn't intend to kill that discussion with my response. I'm not a specialist on those Reference classes but I've heard enough to say that it can be tricky and should probably not be used just because it's sexy. I'd vote for not using them unless there is a real good reason. I'm not sure about your use case, but you might just have to do some research. I'm sorry not to be more of a help. Here's one URL describing the stuff in short. I'm sure there are better ones. http://developer.java.sun.com/developer/TechTips/1999/tt0511.html#tip2 On Thu, 07 Nov 2002 09:54:51 +1000 Peter B. West wrote: I was hoping there might be a little more detailed discussion here. I have no experience of WeakHashMaps or the various Reference objects, but I have been thinking about using Reference objects, rather than direct references, to point to the Nodes in my Tree, with the idea that at least the first iteration in a cache/retrieve cycle on a subtree could be handled transparently within the Tree. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: HashMaps (WAS:RE: interface instead of implementation)
Jeremias, Rhett, I didn't realise that Reference objects were sexy, which seems to imply that was not my reason for being interested in them. Basically, Rhett, I was prompting for peoples' experiences, if any. Jeremias Maerki wrote: I didn't intend to kill that discussion with my response. I'm not a specialist on those Reference classes but I've heard enough to say that it can be tricky and should probably not be used just because it's sexy. I'd vote for not using them unless there is a real good reason. I'm not sure about your use case, but you might just have to do some research. I'm sorry not to be more of a help. Say I have a tree, one line of which looks something like this: +---+---+-+---+-...-+---+ +-+-| 0 | P | | C | | C | | | +---+---+-+---+-...-+---+ | |^ | | | || +--+ +--... | || | | || v | | +---+-+-+-+---+-...-+---+ | +--+-R | P | | C | | C | | +---+---+-+---+-...-+---+ | ^ | | | | +--+ +--... | | | | | v | +---+---+-+---+-...-+---+ +-+-R | P | | C | | C | +---+---+-+---+-...-+---+ | | +--+ +--... | etc., where C are the child references, P are the parent references and R are the root references, necessary in this case because the root of the FO tree has turned into a singleton with a lot of the common data used by properties and FO nodes. 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. These things just sound interesting - sexy, even, now that you mention it - though I doubt their sex appeal was a strong motive for creating them. The raw documentation doesn't really give much of a feel for their potential. Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: HashMaps (WAS:RE: interface instead of implementation)
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]
Re: HashMaps (WAS:RE: interface instead of implementation)
Rhett, Thanks for this. Rhett Aultman wrote: 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? Not for now - this is percolating in the back of the mind - but I'll remember the offer. Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: HashMaps (WAS:RE: interface instead of implementation)
For caching and if done correctly, yes, there could be benefits. WeakReferences can be used if you have objects you want to keep but you're not angry when they get swept away by the GC. Good for keeping images and fonts in memory, but for overall FOP I don't see any use case. Or can anyone think of another one? On 06.11.2002 18:16:47 Rhett Aultman wrote: You mentioned HashMaps briefly here. I suppose I could try auditing the code and answering my own question here, but I have very little free time in general. (Hopefully, I'll have more free time after Saturday...I've spent a lot of time for weeks studying for the GRE). So, I'll just ask- has anyone considered looking into the potential memory benefits of using WeakHashMaps instead of HashMaps? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: HashMaps (WAS:RE: interface instead of implementation)
Mostly it was for caching benefits. As I said, though, I haven't read enough code to know. I just thought I'd throw it out as a possibile way to save on memory usage when FOP processes large documents. *shrug* ;) -Original Message- From: Jeremias Maerki [mailto:dev.jeremias;greenmail.ch] Sent: Wednesday, November 06, 2002 1:38 PM To: [EMAIL PROTECTED] Subject: Re: HashMaps (WAS:RE: interface instead of implementation) For caching and if done correctly, yes, there could be benefits. WeakReferences can be used if you have objects you want to keep but you're not angry when they get swept away by the GC. Good for keeping images and fonts in memory, but for overall FOP I don't see any use case. Or can anyone think of another one? On 06.11.2002 18:16:47 Rhett Aultman wrote: You mentioned HashMaps briefly here. I suppose I could try auditing the code and answering my own question here, but I have very little free time in general. (Hopefully, I'll have more free time after Saturday...I've spent a lot of time for weeks studying for the GRE). So, I'll just ask- has anyone considered looking into the potential memory benefits of using WeakHashMaps instead of HashMaps? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: HashMaps (WAS:RE: interface instead of implementation)
Rhett, Jeremias, I was hoping there might be a little more detailed discussion here. I have no experience of WeakHashMaps or the various Reference objects, but I have been thinking about using Reference objects, rather than direct references, to point to the Nodes in my Tree, with the idea that at least the first iteration in a cache/retrieve cycle on a subtree could be handled transparently within the Tree. Peter Rhett Aultman wrote: Mostly it was for caching benefits. As I said, though, I haven't read enough code to know. I just thought I'd throw it out as a possibile way to save on memory usage when FOP processes large documents. *shrug* ;) -Original Message- From: Jeremias Maerki [mailto:dev.jeremias;greenmail.ch] For caching and if done correctly, yes, there could be benefits. WeakReferences can be used if you have objects you want to keep but you're not angry when they get swept away by the GC. Good for keeping images and fonts in memory, but for overall FOP I don't see any use case. Or can anyone think of another one? On 06.11.2002 18:16:47 Rhett Aultman wrote: You mentioned HashMaps briefly here. I suppose I could try auditing the code and answering my own question here, but I have very little free time in general. (Hopefully, I'll have more free time after Saturday...I've spent a lot of time for weeks studying for the GRE). So, I'll just ask- has anyone considered looking into the potential memory benefits of using WeakHashMaps instead of HashMaps? -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
