Oh, its certainly a memory leak, I said the *application* isn't leaking ram, as when I spent a few days w/ JProfiler profiling its memory and CPU usage on a completely different OS and JVM (xp, sun 1.4.2), it used a steady 2-3Mb (in addition to ~8-12 from the jvm), as opposed to on freebsd/kaffe where it starts with 17Mb and grows to 64Mb until it dumps core. Are there any known leaks in the jvm or javalib that I can check my usage against?
I don't mean to sound like "my code is perfect, the jvm is broken" - it may be some way I'm using objects that sun's gc deals with them in a different way than kaffe's. but whenever a jvm crashes and dumps core - and they all do sometimes - there's a problem in the jvm. hostile classes should be able to consume ram and cpu, but never dump core. (not that my code is hostile) Anyway, two questions - * in the gc/memory management code, there are certainly very good reasons to use __assert, but I only see a few references in mem/gc-incremental.c to OutOfMemoryError. are there some of these asserts that could make sense as OOMs? * does kaffe have a signal or some other mechanism that I can use to get a thread dump of a currently running application? I don't have a /proc/ to gcore & gdb with - I was thinking something along the lines of kill -QUIT / ^BREAK with sun's jvms? tia, -jr On Fri, 21 Nov 2003 03:08:03 -0800 "Kevin D. Kissell" <[EMAIL PROTECTED]> wrote: >Sure looks and sounds like a memory leak to me... Concerned about your privacy? Follow this link to get FREE encrypted email: https://www.hushmail.com/?l=2 Free, ultra-private instant messaging with Hush Messenger https://www.hushmail.com/services.php?subloc=messenger&l=434 Promote security and make money with the Hushmail Affiliate Program: https://www.hushmail.com/about.php?subloc=affiliate&l=427 _______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
