Thread: [java-gnome-hackers] java-gnome memory management issues
Brought to you by:
afcowie
From: Vreixo F. <met...@ya...> - 2008-08-26 11:18:23
|
Hi Andrew! I've started just now to review the Value issue, and that lead me to find another memory management problem. Entity subclasses (Context, Pattern, Surface) implement abstract Proxy.release() method, and they free there underlying C resources. However, when the Entity is garbage collected, the release() method is never called. The problem is the wrong design of that part. Proxy defines and abstract release() method, but its finalize() is not responsible for calling it. Instead, Proxy subclasses override the finalize() method with something like this: protected void finalize() { release(); super.finalize(); } Obviously, if release() is defined in Proxy, a better design would be having this piece of code there. However, Boxeds are a problem, as they're release only if owner == true. I think, however, that the code if (owner) { release(); owner = false; } super.finalize(); present in Boxed.finalize() should be really present in Boxed.release(), and define an abstract method in Boxed (free(), for example) that each Boxed subclass should implement. On the other side, I will also create a Proxy superclass (Pointer, maybe?) where the release() function will be defined, leaving on Proxy only the responsibility of handling the Proxy map. Values, for example, will inherit from Pointer instead of Proxy. I think that Boxeds may also inherit from Pointer instead of Proxy, but I need to think a bit more about it... we will see. Cheers Vreixo |
From: Andrew C. <an...@op...> - 2008-08-26 11:29:41
|
On Tue, 2008-08-26 at 21:18 +1000, Vreixo Formoso wrote: > However, when the Entity is garbage collected, the release() method is > never called. So, immediately, the problem is that someone (ahem) forgot to put a finalize() placeholder in Entity. That's easily fixed. > ... > Obviously, if release() is defined in Proxy, a better design would be > having this piece of code there. > I think, however, that the code > > if (owner) { > release(); > owner = false; > } > super.finalize(); THAT can go into Proxy's finalize() placeholder [or rather, Pointer's]. Let's leave the actual release() method abstract there. AfC Sydney -- Andrew Frederick Cowie Operational Dynamics is an operations and engineering consultancy focusing on IT strategy, organizational architecture, systems review, and effective procedures for change management. We actively carry out research and development in these areas on behalf of our clients, and enable successful use of open source in their mission critical enterprises, worldwide. http://www.operationaldynamics.com/ Sydney New York Toronto London |
From: Vreixo F. L. <met...@ya...> - 2008-08-26 15:13:46
|
Hi! I've pushed to my memmanag branch http://research.operationaldynamics.com/bzr/java-gnome/hackers/vreixo/memmanag/ several changes related to this thread: - I've created a Pointer class. The C ptr is stored as a long there. It defines an abstract release() and its finalize() takes care of calling release(). - Proxy now extends Pointer, and only holds the responsibility of maintaining the proxy map. - Boxed implements release() by taking care about owner flag. It defines an abstract free() function that each subtype implements, and where they should call underlying C free/unref function. - Value now extends Pointer instead of Proxy, there is no need to keep them stored in the map. I think we can do the same with Boxed, storing Boxeds in a map makes no sense, as denaturation will happen with boxeds anyway, because they have no ref. count system and the proxy is always garbage collected when it goes out of scope on java. Moreover, all boxeds should be final, so we have no denaturation problem at all (btw, why TreeIter is not final? it seems a bug). This branch fixes memory leaks on Cairo code, and improves memory usage with Values. It seems to work ok, all test cases pass. Conceptually it is more correct than current code. Wrong implementation CairoContext getSource() does not break now, but it can cause a memory leak if it is called more than once. The problem is hard to fix without an override. I'll take a look at it today. On the other side, I can't find any leak on GValue or gtk_list_store_set_value() as IRC subject suggest. Its usage seems correct, and it is correct on my system. Cheers Vreixo Novos endereços, o Yahoo! que você conhece. Crie um email novo com a sua cara @ymail.com ou @rocketmail.com. http://br.new.mail.yahoo.com/addresses |
From: Vreixo F. L. <met...@ya...> - 2008-08-26 15:18:09
|
Hi! > Wrong implementation CairoContext getSource() does not > break now, but it can cause a memory leak if it is called > more than once. The problem is hard to fix without an > override. I'll take a look at it today. > Is there any good reason to have Cairo Entity extend Proxy instead of Pointer? It seems not needed at all, and the problem is automatically fixed without that. Cheers Vreixo Novos endereços, o Yahoo! que você conhece. Crie um email novo com a sua cara @ymail.com ou @rocketmail.com. http://br.new.mail.yahoo.com/addresses |