Date: Fri, 22 Feb 2008 09:13:09 -0500 From: Sam Baskinger <sbaskinger@lumeta.com> To: Mika Nystrom <mika@async.caltech.edu> Cc: freebsd-java@freebsd.org Subject: [O/T] Re: Memory leak in 1.5.0 JVM Message-ID: <47BED875.4090906@lumeta.com> In-Reply-To: <200802220549.m1M5nJhd085207@camembert.async.caltech.edu> References: <200802220549.m1M5nJhd085207@camembert.async.caltech.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Slightly off topic, here is a link to Sun's Java 1.5.0 garbage collector. http://java.sun.com/j2se/1.5.0/docs/guide/vm/gc-ergonomics.html ... and here is the Java 5.0 GC tuning guide... http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html Interesting reading, but I doubt it holds the solution to the bad behavior your seeing. :( Sam Mika Nystrom wrote: > No, that does seem to fix it, also. Of course, I have no idea how > many times slower System.gc() is than thread.start()... > > 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? > > Hmmm...! > > I am testing this code because I am having some trouble with a > long-running server, which spaws a few new threads every two seconds > using Quartz, and I can't for the life of me see why its memory > usage is growing over time (it runs out of its 300 megs after about > two hours). But it could be something completely different in that > program, of course. > > Mika > > class Leakq { > > private static class MyThread extends Thread { > public void run() > { > > } > } > > public static void main (String[] args) > { > for(;;) { > Thread t = new MyThread(); > t.start(); > /*try { t.join(); } catch (Exception ex) { ; }*/ > System.gc(); > } > } > } > > > "Samuel R. Baskinger" writes: > >> Do you get the same results if you put a System.gc() after your thread spawn? Perhaps you are just out-running the garbage collector. :) >> >> I tried this on the diablog-jdk 1.5 on amd64 bsd and it runs quite nicely unmodified. >> >> [sam@bob ~]$ java -version >> java version "1.5.0" >> Java(TM) 2 Runtime Environment, Standard Edition (build diablo-1.5.0-b01) >> Java HotSpot(TM) 64-Bit Server VM (build diablo-1.5.0_07-b01, mixed mode) >> [sam@bob ~]$ >> >> Sam >> >> -----Original Message----- >> From: owner-freebsd-java@freebsd.org on behalf of Mika Nystrom >> Sent: Thu 2/21/2008 9:07 PM >> To: freebsd-java@freebsd.org >> Cc: mika@camembert.async.caltech.edu >> Subject: Memory leak in 1.5.0 JVM >> >> Hello there freebsd-java, >> >> I am running a binary downloaded 1.5.0 JVM on a FreeBSD 5.5 system: >> >> (167)rover:~/levinc/memleak>java -version >> java version "1.5.0" >> Java(TM) 2 Runtime Environment, Standard Edition (build diablo-1.5.0-b01) >> Java HotSpot(TM) Client VM (build diablo-1.5.0_07-b01, mixed mode) >> (168)rover:~/levinc/memleak>uname -a >> FreeBSD rover 5.5-RELEASE FreeBSD 5.5-RELEASE #4: Sat Nov 17 12:13:24 PST 2007 mika@rover:/usr/src/sys/i386/compile/ROVER i386 >> >> I have found the following program to leak memory on FreeBSD, but not on Windows with same Java 1.6.0, nor on Debian with gij 1.4.2: >> >> class Leakq { >> >> private static class MyThread extends Thread { >> public void run() >> { >> >> } >> } >> >> public static void main (String[] args) >> { >> for(;;) { >> (new MyThread()).start(); >> } >> } >> } >> >> Best regards, >> Mika Nystrom >> mika@alum.mit.edu >> _______________________________________________ >> freebsd-java@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-java >> To unsubscribe, send any mail to "freebsd-java-unsubscribe@freebsd.org" >> > > -- Sam Baskinger Software Engineer Lumeta - Securing the Network in the Face of Change sbaskinger@lumeta.com 732.357.3545 (office) 732.564.0731 (fax) Lumeta Corporation 220 Davidson Ave, 4th Floor Somerset, NJ 08873 www.lumeta.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47BED875.4090906>