At 2007-01-16T14:56:52+1300, Steve Holdoway wrote:
> jstat has been the most useful, but only points to a leak in the native
> layer. I suspect the mysql conduit ( kneejerk reaction! ) as it's pretty
> old, but cannot easily upgrade it, thanks to idiot developers ):
Ah well, if it's a leak in native code that's a whole 'nother story. :-)
If you suspect there is something funky going on with a Java<->native layer,
try running with the strict JNI checks enabled (-Xcheck:jni). The checking
in the IBM 5.0 runtime seems to find way more problems than any of the
others.
For general memory debugging there are lots of tools available. Valgrind is
pretty much the best tool available (except, perhaps, one or two expensive
commercial offerings) for debugging memory-related issues in native code.
It can be somewhat tricky to run Java applications under Valgrind, because
both of them tend to consume quite a bit of address space, so when you run
them together there's a good chance you'll run out of address space on a
32-bit machine.
I've had quite a bit of luck running Java VMs under the most recent versions
of Valgrind (3.1 upwards) and Valgrind tends to get less confused if you
disable Hotspot (-Xint) or the JITer if you're using a non-Sun runtime.
It's much easier to deal with if you can reduce the testcase to something
smaller than "the whole app", obviously.
A big disadvantage with Valgrind is that you can't use it in a production
environment because the application will run at least 10-100x slower, and
there's no way to attach and detach Valgrind from existing processes.
Cheers,
-mjg
--
Matthew Gregan |/
/| [EMAIL PROTECTED]
