In my opinion, the vast majority of these woes would be eliminated if
Class would have a map for custom values exposed to user code.
Something not unlike how ThreadLocal works for per-thread state
("ClassLocal"?)
Attila.
On 2009.03.10., at 12:21, 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
>
> --
> Jochen "blackdrag" Theodorou
> The Groovy Project Tech Lead (http://groovy.codehaus.org)
> http://blackdragsview.blogspot.com/
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
