Re: [gui-dev] Chasing possible memory leaks?

From: "Sam Berlin" <[email protected]>
> Hi Philippe,
>
> If you could resend this patch and explain where the optimizations are
> that will reduce our memory problems, we'll take a much closer look at
> it.
>
> Thanks much,
>   Sam

I'll have it ready in a few days when I come back home. For now my notebook
does not have it here.

It would be good to say that there's no "memory leak" here. True memory leak
can happen in Java, but it will be the fault of the internal VM
implementation , most often when it communicates with external native
libraries, but sometimes within the HotSpot compiler itself when it allocate
spaces that gets locked to store native code in current execution.

The memory usage patterns shown are not leaks, but "dead objects", that the
garbage collector will reclaim later, when its thread will have time for
that. But it's true that we should limit the number of dead objects, i.e.
objects allocated and then abandonned without any active reference, notably
temporary local objects when they are not justified and highly reusable
later, or those whose reference stored in a object member variable is
overwritten without checking that another appropriate object is already
there.

Shamefully the Java language and VM does not help us to trace easily the
initialization status of objects and control their lifetime or uniqueness.
The only tool offered is "final" which is not very helpful as it requires
early initialization of object members.

_______________________________________________
gui-dev mailing list
[email protected]
http://www.limewire.org/mailman/listinfo/gui-dev