34 messages in org.codehaus.groovy.devRe: [groovy-dev] Re: [groovy-user] Me...
FromSent OnAttachments
Alex TkachmanOct 16, 2008 2:30 pm 
Alex TkachmanOct 16, 2008 3:17 pm 
Jochen TheodorouOct 16, 2008 3:49 pm 
Tim QuinnOct 16, 2008 4:15 pm 
Alexander VeitOct 16, 2008 4:34 pm 
Jochen TheodorouOct 16, 2008 4:43 pm 
Tim QuinnOct 16, 2008 5:28 pm 
Jochen TheodorouOct 17, 2008 6:35 am 
Alex TkachmanOct 17, 2008 6:44 am 
Graeme RocherOct 17, 2008 6:54 am 
Jochen TheodorouOct 17, 2008 7:05 am 
Graeme RocherOct 17, 2008 7:14 am 
alex...@gmail.comOct 17, 2008 7:30 am 
Jochen TheodorouOct 17, 2008 7:36 am 
Alex TkachmanOct 17, 2008 9:51 am 
Jochen TheodorouOct 22, 2008 5:27 am 
Alex TkachmanOct 22, 2008 5:37 am 
Jochen TheodorouOct 22, 2008 6:05 am 
Alex TkachmanOct 22, 2008 6:08 am 
Jochen TheodorouOct 22, 2008 6:18 am.zip
Alex TkachmanOct 22, 2008 6:32 am 
Jochen TheodorouOct 22, 2008 7:06 am 
Guillaume LaforgeOct 22, 2008 7:08 am 
Alex TkachmanOct 22, 2008 7:11 am 
Guillaume LaforgeOct 22, 2008 7:21 am 
Jochen TheodorouOct 22, 2008 7:22 am 
Jochen TheodorouOct 22, 2008 7:39 am 
Jochen TheodorouOct 22, 2008 7:41 am 
Alex TkachmanOct 22, 2008 9:16 am 
Jochen TheodorouOct 22, 2008 10:11 am 
Jochen TheodorouOct 22, 2008 11:24 am 
Alex TkachmanOct 22, 2008 11:48 am 
Jochen TheodorouOct 22, 2008 2:07 pm 
Jochen TheodorouDec 22, 2008 12:52 pm 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: [groovy-dev] Re: [groovy-user] Memory leaks in GroovyActions...
From:Jochen Theodorou (blac@gmx.org)
Date:Oct 22, 2008 10:11:34 am
List:org.codehaus.groovy.dev

Alex Tkachman schrieb:

There is something I really don't like in this patch after brief look. What you did is kind of repetition of architecture of GoogleCollection. I mean ReferenceType enum and ManagedReference, which contains real strong, soft, weak of phantom reference.

never had a look at GoogleCollection, so I can't know ;) But if you are going to abstract the fact that you use different kinds of references, then I guess you end up with a solution similar to this.

What we had before was different - elements of internal data structures (especially entries in maps) were directly derived from java references, which allowed to use less memory.

if you inherit directly from SoftReference and others, then you loose the ability to abstract the reference type. As a result you had for example a weak and a soft map which did exactly the some, only one was using WeakReferences, while the other one was using SoftReferences. And about less memory... what do you think the current structure requires more in memory? before we had a subclass of the reference, now we have a subclass of ManagedReference, which holds the reference. The is-a has become a has-a, but has-a is hidden away. I don't think that this will require huge amounts of additional memory, just two more pointers.

It was done with purpose (and I did mesaurments) top make things faster and more memory efficient. Also I totally understand idea behind handler but very often (especially for performance critical data structure) handler is just this, so you just add unneeded operations.

Ah, I may understand now what you think... Ok, let me explain again...

I made an internal clas which subclasses the reference class and this class has the a point to the handler, where the handler is the information we want to carry with the references... like for example hash map entires. ManagedReferece has no a pointer to such a reference subclass and "this" is used for the handler object in the reference subclass... meaning the ManagedReference instance is the handler. When you now write code, you use and extend the ManagedRefernce class. There is no level of indirection invovled in this. The only place where the handler is actually used is after garbage collection, when you query the ReferenceQueue and finalize the handler. Only there. I very much doubt, that this has a major impact on performance, especially if that part of the code is never even called, like when the idling manager is used. For things like the map entry the oly difference is that you now do not directly call the get() method of the reference, but the get() method of the ManagedReference, which then calls the get() method of the reference. So there is one additional method call in between here. That may have a small impact, but how much can be said only after doing some performance measurements

bye blackdrag