Re: Garbage Collection - OutputStream

    Hi albartell,

    I think the most important thing is to limit the memory available to the
jre.  While reusing objects is a great strategy in a constarined
environment, you probably can't reuse everything.  If the vm thinks it has
up to 15 meg available, it will continue ( usually - everything may be up
for grabs in a custon J2ME runtime ) to allocate memory to the limit.  Does
the jre support -Xmxn or a similar option?  It appears to default to
approximately 15 meg now.

    Also, there's no particular reason to equate flush() with memory
deallocation.  That may be the case in a well written version, but the API
doesn't specify that.  In fact, the API for OutputStream.flush() says " The
flush method of OutputStream does nothing."  Therefore, you might want to
check that your subclass overrides flush() and actually does something.
Regardless, depending on assumed,  unspecified behavior will probably go
wrong at some point.  I'd set your outStream variable to null as soon as I
was done with it, to ensure gc eligibility.

    This last may no longer be true, but in a constrained environment I'd
probably do it just in case.  I'd have to check back to find the exact
document, but one I read mentioned that local, stack variables are just
overwritten on the next method call.  That's actually the time when they are
gc eligible, rather than immediately after method exit as we conceptually
understand.  The document pointed out that, if the number of arguments was
different, a previous stack variable could survive for some time.  For
example, if one method had three args, then the next had two, the third
variable could still hold on to memory.  Therefore, if you're in a place
where memory is a concern, it might make sense to go ahead and set locals,
especially ones that might hold a large amount of memory, to null within the
method to ensure gc eligibility.

HTH,


                                                         Joe Sam

Joe Sam Shirah -        http://www.conceptgo.com
conceptGO       -        Consulting/Development/Outsourcing
Java Filter Forum:       http://www.ibm.com/developerworks/java/
Just the JDBC FAQs: http://www.jguru.com/faq/JDBC
Going International?    http://www.jguru.com/faq/I18N
Que Java400?            http://www.jguru.com/faq/Java400


----- Original Message ----- 
From: "albartell" <albartell@xxxxxxxxx>
To: <java400-l@xxxxxxxxxxxx>
Sent: Tuesday, February 28, 2006 10:13 PM
Subject: Garbage Collection - OutputStream


> Hi all,
>
> I recently wrote some code against a J2ME device that takes image data
> received via a call-back method and sends it to a remote server via an
http
> OutputStream object. I have never really paid a ton of attention to
garbage
> collection because Java has always done it for me, but I am in a memory
> constrained runtime (32MB) and memory management is of the highest order.
>
> My question relates to the below asyncMethod(...) that receives in 65k
> chunks of data, copies it into a new byte array, and writes it the the
> HttpURLConnection's outStream object using write() which is immediately
> followed by a flush. After the "return false;" statement the newCopy byte
> array is no longer in scope and therefore ready to be garbage collected
> (from what I understand of GC). The outStream object is defined globablly
> and is NOT out of scope after each asyncMethod(...) call. Being that I
> called the outStream.flush() method I am assuming it would not be holding
> onto the 65k of image data for each call-back made to asyncmethod(...).
>
> 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()).
>
> Final question, I promise :-)
>
> So, is the outStream holding onto data somehow? Should I be looking at how
> this company wrote the JRE for their device(assuming they would have to
> create their own because it isn't running on a standard OS of any kind)?
>
> I have looked at a bunch of GC articles hoping to find my answers, but
have
> not yet found one that addresses the specific question I have.
>
> Thanks for any input,
> Aaron Bartell
>
> public class ResourceReader {
>
>     HttpURLConnection conn;
>     OutputStream outStream;
>
>   public class ResourceListener extends OperationResultAdapter {
>         public boolean asyncMethod(int blockNo, OutParamAcquireResource
oar)
> {
>
>                 Log.out("oar.data.length=" + oar.data.length + "
freemem="
> + Runtime.getRuntime().freeMemory() + "  blockNo=" + blockNo);
>                     byte[] newCopy = new byte[oar.data.length];
>                     System.arraycopy(oar.data, 0, newCopy, 0,
> oar.data.length);
>                     outStream.write(newCopy);
>                     outStream.flush();
>             return false;
>         }
>     }
>   }
>
> }
>