

![]() | Start a set with this search |
![]() | Include this search in one of my sets |
![]() | Exclude this search from one of my sets |
![]() | Permalink to these results Paste this link in email or IM: |
| Atom feed for tracking future search results Paste this URL into your reader: |
34 messages in org.codehaus.groovy.devRe: [groovy-dev] Re: [groovy-user] Me...| From | Sent On | Attachments |
|---|---|---|
| Alex Tkachman | Oct 16, 2008 2:30 pm | |
| Alex Tkachman | Oct 16, 2008 3:17 pm | |
| Jochen Theodorou | Oct 16, 2008 3:49 pm | |
| Tim Quinn | Oct 16, 2008 4:15 pm | |
| Alexander Veit | Oct 16, 2008 4:34 pm | |
| Jochen Theodorou | Oct 16, 2008 4:43 pm | |
| Tim Quinn | Oct 16, 2008 5:28 pm | |
| Jochen Theodorou | Oct 17, 2008 6:35 am | |
| Alex Tkachman | Oct 17, 2008 6:44 am | |
| Graeme Rocher | Oct 17, 2008 6:54 am | |
| Jochen Theodorou | Oct 17, 2008 7:05 am | |
| Graeme Rocher | Oct 17, 2008 7:14 am | |
| alex...@gmail.com | Oct 17, 2008 7:30 am | |
| Jochen Theodorou | Oct 17, 2008 7:36 am | |
| Alex Tkachman | Oct 17, 2008 9:51 am | |
| Jochen Theodorou | Oct 22, 2008 5:27 am | |
| Alex Tkachman | Oct 22, 2008 5:37 am | |
| Jochen Theodorou | Oct 22, 2008 6:05 am | |
| Alex Tkachman | Oct 22, 2008 6:08 am | |
| Jochen Theodorou | Oct 22, 2008 6:18 am | .zip |
| Alex Tkachman | Oct 22, 2008 6:32 am | |
| Jochen Theodorou | Oct 22, 2008 7:06 am | |
| Guillaume Laforge | Oct 22, 2008 7:08 am | |
| Alex Tkachman | Oct 22, 2008 7:11 am | |
| Guillaume Laforge | Oct 22, 2008 7:21 am | |
| Jochen Theodorou | Oct 22, 2008 7:22 am | |
| Jochen Theodorou | Oct 22, 2008 7:39 am | |
| Jochen Theodorou | Oct 22, 2008 7:41 am | |
| Alex Tkachman | Oct 22, 2008 9:16 am | |
| Jochen Theodorou | Oct 22, 2008 10:11 am | |
| Jochen Theodorou | Oct 22, 2008 11:24 am | |
| Alex Tkachman | Oct 22, 2008 11:48 am | |
| Jochen Theodorou | Oct 22, 2008 2:07 pm | |
| Jochen Theodorou | Dec 22, 2008 12:52 pm |

![]() | Permalink for this message Paste this link in email or IM: |
![]() | Permalink for this thread 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 Groovy | Actions... |
|---|---|---|
| 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
-- Jochen "blackdrag" Theodorou The Groovy Project Tech Lead (http://groovy.codehaus.org) http://blackdragsview.blogspot.com/ http://www.g2one.com/
--------------------------------------------------------------------- To unsubscribe from this list, please visit:








.zip