× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



 >You are not guaranteed that system.gc() actually do anything.  It is a
hint. 
I was afraid it was something like that :-)

>If you do not want garbage collection you should reuse your objects
yourself instead of creating new one every time.

I may not have stated what I want clearly. I DO want garbage collection to
happen and as soon as certain variables are out of scope because of the 65k
they are holding of memory. But as you stated above it is all up to the JRE.

>But what is the problem?  If the garbage collection results in all the
memory you expect being available - and you don't mind the pause -  then you
are home free.

There in lies the problem. The hardware vendor that this is for is making
statements saying I am consuming way more than my applet should be allowed,
but I am looking at it thinking that I am not using more than 65k at a time
and it is instead the JRE on the device that is causing GC to be delayed
until the last possible moment.

I guess the thing I was most wondering about was the outStream object and
whether anyone thought that may be holding onto memory even after a flush?
My argument against that is sometimes there is a huge file being sent from
the device to the remote server and half way through transmitting it the
device will go down to 2MB and GC and then be back at 15MB. If the outStream
object was still holding onto the memory it wouldn't be able to be GC'd.

Thanks for your input Thorbjørn,
Aaron Bartell

-----Original Message-----
From: java400-l-bounces@xxxxxxxxxxxx [mailto:java400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Thorbjørn Ravn Andersen
Sent: Wednesday, March 01, 2006 2:32 AM
To: Java Programming on and around the iSeries / AS400
Subject: Re: Garbage Collection - OutputStream

albartell wrote:

>The problem:
>As you can see I have a output statement that calls on
>Runtime.getRuntime().freeMemory() used to see how much memory is 
>available at each asyncMethod(...) execution. The freeMemory() return 
>value starts out at about 15MB and continues to go down to 2MB and at 
>that point the JRE running on the device seems to think it is time to 
>run GC and the
>freeMemory() is bumped back up to 15MB.  I have attempted to put in
>System.gc() statements to do my own garbage collection, but that 
>doesn't seem to address the problem (or rather it doesn't affect the 
>value I am getting from freeMemory()).
> 
>
You are not guaranteed that system.gc() actually do anything.  It is a hint.


If you do not want garbage collection you should reuse your objects 
yourself instead of creating new one every time.    This is usually well 
described in Java performance articles.  Note that new is traditionally an
expensive operation.

But what is the problem?  If the garbage collection results in all the
memory you expect being available - and you don't mind the pause -  then you
are home free.  The problem would be if you leak memory e.g. if you still
have references to old objects lingering around.  This is usually found with
a profiler - doing so manually is a pain.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.