On 2007.12.07., at 15:22, Jochen Theodorou wrote:
> Groovy uses a map with SoftReferences for the keys and values to store > the MetaClasses > >> This'll postpone its GC and subsequent >> unloading of its class loader, but is fortunately usually okay with >> regard to memory management semantics otherwise, even if it can cause >> higher temporary memory pressure (until soft references are cleared). >> As usual, the lunch is not free, but if implemented properly it won't >> lead to an OOME and all class garbage will get GCed even if with a >> bit >> of an additional delay. > > a bad effect we noticed is that a MetaClass might get collected > leading > to a cache miss in the next call, causing the recreation of the class > just to be collected again a later. This is bad, it slows down the > program very much. I thought about counting the recreations or > something > or to keep a fixed number of classes... something like this, but I > didn't come to a satisfying solution. There isn't one[*]. On the other hand, if you used strong references then there would be a different performance problem after a while, one due to exhausting the memory :-). With my recent changes to MOP code, I'm in the same shoes, but my past experience with using soft references isn't bad - GC will refrain from cleaning them while there's free memory, see <http://java.sun.com/docs/hotspot/HotSpotFAQ.html#gc_softrefs >. Basically, soft reference access is timestamped (efficiently), and GC will not clear a soft reference when last access is more recent (in seconds) than there is free memory (in megabytes). There's a command- line configurable factor (so you can say, i.e. you want 10 seconds of softref lifetime per free MB instead of the default 1 second). Also, client HotSpot uses currently allocated heap size as the maximum against which the free memory is calculated, while server HotSpot uses value of -Xmx, so server will rather expand heap than clean soft references, while the client will rather clean them than expand heap. That can make a lot of difference in your performance testing when - Xms != -Xmx :-) Attila. [*] Well, maybe there is. In FreeMarker's cache implementation, we have a hybrid strong/soft MRU cache with "m" strong and "n" soft slots that maintains the invariant that "m" most recently used entries are strongly referenced and "n" less recently used entries are softly referenced. (Intuitively, setting m=0 gives you a pure soft cache, setting n=0 gives a pure strong cache.) I was actually never entirely convinced that the increased complexity was worth it, but I heard back from some of our heavy-duty users and they swear by it, saying it caused a significant performance improvement when we introduced it... --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
