It'd be useful for my JConch library. I do a similar stunt in the CacheMap, and I basically maintain two maps -- one with hard links and one with soft links.
~~ Robert. Jochen Theodorou wrote: > Hi all, > > recently someone had a strange problem with Groovy, a VM specific one. > He got OutOfMemoryErrors because his classes where not garbage collected > in the IBM VM, even though they were in Sun VM. We found out how to > solve the problem, but it seems specification did let room here for how > to collect classes if they are indirectly soft referenced. > > Another problem Groovy is facing atm is, that it uses a lot of > SoftReferences for caches, meaning memory will be consumed big time. The > funny thing is, that we wouldn't even need SoftReferences for these > caches, but there is simply no other possible way... unless you guys > here tell me a different story. > > Basically we have caches that map classes to helper structures, like our > meta class for example. The meta class is needed for almost any action > on the class, so we cache the class. We tried to use WeakReferences, but > that resulted in the meta class to be collected quite early, and since > the creation is expensive it proofed to be very bad the performance - > especially on low memory. > > If we keep that structure, then we would really need a different kind of > reference... One that allows us to make a hard reference from the class > object to our meta class. Something like: > > reference = new LinkingReference(x,y) > > cache management would then work with the reference, x and y would be > PhantomReferenced by the LinkingReference, but there would be a VM > generated hard link between x and y. No ReferenceQueue would be needed > for the hard reference, only for the references of the LinkingReference > to x and y. that would make live so much more easy for us... basically > we would need that for arbitrary objects, not only classes. If we had > that Groovy could run with a much lower memory profile and most of our > memory management structures (which are concurrent) could be removed. > > Of course I am no VM expert, and maybe John can comment on this, but the > hard reference management itself should be in the VM already, so what is > missing is to add a hard reference to an existing object... which may > invalidate some internal structures... > > I am also interested in knowing if such a reference would be of interest > for other language implementations as well. > > bye Jochen > -- ~~ Robert Fischer. Grails Training http://GroovyMag.com/training Smokejumper Consulting http://SmokejumperIT.com Enfranchised Mind Blog http://EnfranchisedMind.com/blog Check out my book, "Grails Persistence with GORM and GSQL"! http://www.smokejumperit.com/redirect.html --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
