[O/T] Re: Memory leak in 1.5.0 JVM

[Sam Baskinger]

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 at 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 at bob ~]$ 
>>
>> Sam
>>
>> -----Original Message-----
>> From: owner-freebsd-java at freebsd.org on behalf of Mika Nystrom
>> Sent: Thu 2/21/2008 9:07 PM
>> To: freebsd-java at freebsd.org
>> Cc: mika at 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 at 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 at alum.mit.edu
>> _______________________________________________
>> freebsd-java at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-java
>> To unsubscribe, send any mail to "freebsd-java-unsubscribe at freebsd.org"
>>     
>
>   


-- 
Sam Baskinger
Software Engineer

Lumeta - Securing the Network in the Face of Change

sbaskinger at lumeta.com
732.357.3545 (office)
732.564.0731 (fax)
Lumeta Corporation
220 Davidson Ave, 4th Floor
Somerset, NJ 08873 
www.lumeta.com