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