Re: [java-gnome-hackers] java-gnome memory management issues

[Vreixo F. L. <met...@ya...>]

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