Date: Fri, 22 Feb 2008 02:30:20 -0800 From: Mika Nystrom <mika@async.caltech.edu> To: Nick Johnson <freebsd@spatula.net> Cc: mika@camembert.async.caltech.edu, freebsd-java@freebsd.org Subject: Re: Memory leak in 1.5.0 JVM Message-ID: <200802221030.m1MAUKPX092160@camembert.async.caltech.edu> In-Reply-To: Your message of "Thu, 21 Feb 2008 22:29:37 PST." <20080221222313.O2617@turing>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Nick,
Thanks for the explanation! I guess I can just chalk up another
reason on my list of reasons "why I would never use Java for anything
I care about [given the choice]". Better garbage collectors were
described by Dijkstra et al... now 30 years ago.
This is what my NOP-program does after allocating a gigabyte (only
takes a couple of minutes on a Q6600):
Exception in thread "main" java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:574)
at Leakq.main(Leakq.java:14)
Mika
Nick Johnson writes:
>On Thu, 21 Feb 2008, Mika Nystrom wrote:
>
>> Out-running the garbage collector? I'm not used to Java, but in
>> Modula-3, the garbage collector gets called when you allocate memory,
>> is that not how it works in Java?
>
>In a word, no. Garbage collection in Java is asynchronous. In the Sun
>JVM there are several different garbage collection strategies. The
>default strategy uses multiple "generations"-- a "new" generation for
>short-lived objects; those objects that live through a new generation
>collection get promoted to one of many "survivor" spaces, and those that
survive collection there (either because of time or exhausting the size of
>the survivor space) get promoted to the "tenured" or "old" generation.
>Then there's a "permanent" generation for classes and other stuff.
>
>If you just sit and watch the memory size of a JVM process, it might
>appear to be "leaking" memory, but what's happening under the hood is far
>more complicated than that. The JVM will also grow to accomodate the
>amount of memory it has needed to allocate, but won't necessarily -shrink-
>again once those objects are garbage collected. In a long-running
>process, chances are that if a program needed 256M once, it's going to
>need it again.
>
>To get a real good idea of what's going on under the hood, look at tools
>like jvmstat and visualgc.
>
>This document will give you a much more detailed view than my rough
>outline here:
>
> http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html
>
> Nick
>
>
>--
>"Courage isn't just a matter of not being frightened, you know. It's being
> afraid and doing what you have to do anyway."
> Doctor Who - Planet of the Daleks
>This message has been brought to you by Nick Johnson 2.3b1 and the number 6.
>http://healerNick.com/ http://morons.org/ http://spatula.net/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200802221030.m1MAUKPX092160>