Re: Re: Memory leak (Jim Rudnicki)

Jac Kersing <j.kersing-9+7/[email protected]> Thu, 27 May 2004 19:29:43 +0200 (CEST)
Newsgroups gmane.comp.hardware.microcontrollers.tini
Message-ID <[email protected]>
On Thu, 27 May 2004, Hong Wong wrote:

> The typical Java performs automatic garbage collection. By nulling 
> objects, you allow Java to recycle the memory for other purposes, 
> however, this is not the case with the TINI, at least not when I have 
> tried this.

Works on TINI as well. But note, the garbage collector starts when free 
ram drops below 64K, not before. BTW, you are not nulling the objects, 
you're destroying the references, making the object available for garbage 
collection.

> in my program, which causes my TINI to eventually reset itself and 
> sometimes makes it lose all its RAM data. Hence, a System.gc command was 
> my solution for my memory leak. 

System.gc can never be a solution for a memory leak. It does suggest the
garbage collector to start reclaiming memory, which will get rid of all
unreferenced objects after some time. It will not reclaim memory from
objects still being referenced. And it will never be able to reclaim
memory that's leaking as by definition leaked memory is 'lost'. 

Most real memory leaks in Java occur when an object has native methods 
allocating memory. When those objects are destroyed the natively allocated 
memory can stay around. Normally the memory would be released when 
finalizing the object, but some Java implementations (TINI for example) do 
not automaticaly run finalize code (see API_Diffs.txt)

Candidates for memory leaks are (generally speaking, DalSemi staff will be
able to tell if this is true for TINI as well) any object that has a
close() method that is not called before the reference to the object is
lost (by setting it to null)

> Also Chris, if you read the java docs for System.gc, you will find out 
> that it is a function that is dangerous to use in typical applications 
> because the programmer has no control over what Java  erases. 

The programmer has perfect control over what will not be erased. NO active
(== referenced) objects will be erased.

And while there may be memory leaks, conservative programming helps a lot. 
Below are the stats for TINI monitoring a X10 module...

tuvok /bin> stats

TINI slush Version 1.1
TINI OS 1.10 

System up time:
      Days: 606
     Hours: 18
   Minutes: 33
   Seconds: 47

Free RAM: 92096

Regards,

Jac

-- 
 Jac Kersing            Technical Consultant   The-Box Development
 j.kersing-9+7/[email protected]                         http://www.the-box.com 
_______________________________________________
TINI mailing list
TINI-6tN4nzCoH/[email protected]
To UNSUBSCRIBE, edit your profile, or see list archives:
http://lists.dalsemi.com/mailman/listinfo/tini