T
Twisted
I have a Java app I'm developing here that seems to have developed a
slow leak.
It spawns around 100 threads, which do various things with some shared
resources (mainly collections); the resources are locked (in a fixed
order) before use, so this shouldn't be a concurrency issue. These
collections are periodically either wiped or halved in size, when they
grow to certain sizes, so that they cannot cause the memory use of the
app to grow without bound.
Yet grow it does; the task eventually bloats up to 90+ meg and when it
gets to that size, it becomes slow and unstable. Then I start getting
crashes. Best case, weird exceptions or OutOfMemoryErrors (when there's
still 3/4 of the machine's physical RAM free!) pop up and it tries to
exit gracefully. Or it lurches to a halt (hangs, possibly taking the
IDE down with it if its debugger is attached to the process), or it
outright crashes (sigsegv in Hotspot VM).
Anyone have an idea what's happening here? Lots of objects are created
transiently and discarded -- is it possible the system GC isn't able to
keep up with the rate at which this occurs? (Translation: use less
threads, even if it means the app spends more time idling and less
accomplishing something useful.) Or is there a way that things might be
hanging around, and cruft slowly accumulating in memory that isn't
getting swept away? (Possibly a library call that uses a native method?
Native methods written in C could leak easily, unlike Java code.) Or
perhaps attaching a debugger is itself causing the bloat? (Objects the
debugger notices may hang around because the debugger hangs onto
references, which stop them being gc'd?)
JDK and JRE version 1.5.0_06.
slow leak.
It spawns around 100 threads, which do various things with some shared
resources (mainly collections); the resources are locked (in a fixed
order) before use, so this shouldn't be a concurrency issue. These
collections are periodically either wiped or halved in size, when they
grow to certain sizes, so that they cannot cause the memory use of the
app to grow without bound.
Yet grow it does; the task eventually bloats up to 90+ meg and when it
gets to that size, it becomes slow and unstable. Then I start getting
crashes. Best case, weird exceptions or OutOfMemoryErrors (when there's
still 3/4 of the machine's physical RAM free!) pop up and it tries to
exit gracefully. Or it lurches to a halt (hangs, possibly taking the
IDE down with it if its debugger is attached to the process), or it
outright crashes (sigsegv in Hotspot VM).
Anyone have an idea what's happening here? Lots of objects are created
transiently and discarded -- is it possible the system GC isn't able to
keep up with the rate at which this occurs? (Translation: use less
threads, even if it means the app spends more time idling and less
accomplishing something useful.) Or is there a way that things might be
hanging around, and cruft slowly accumulating in memory that isn't
getting swept away? (Possibly a library call that uses a native method?
Native methods written in C could leak easily, unlike Java code.) Or
perhaps attaching a debugger is itself causing the bloat? (Objects the
debugger notices may hang around because the debugger hangs onto
references, which stop them being gc'd?)
JDK and JRE version 1.5.0_06.