I've did some further investigation and the largest objects seem to be the
settings from org.apache.wicket.Application, particular the markupCache.
Tom
Thomas Singer wrote:
Well, our application class (derived from
org.apache.wicket.protocol.http.WebApplication) occurs near the top of
the list when sorting by retained size, but our code does not contain
dynamic elements. For me it looks strange, that there exist 3 instances
of our application class (we don't create them).
Tom
Maeder Thomas wrote:
Thomas,
the memory footprint per class usually doesn't really allow to pinpoint
the reference that causes a memory leak (usually the top entries are
char[], String, etc.). For that, you need to trace back to the reference
that should not be there. We use YourKit to great benefit (do I get
goodies now, comrades?). Yourkit can show the "retained size" of an
object. If one of your Objects shows up near the top of the list, that
is a good candidate.
alternatively, the hprof dump would be more helpful than HTML.
(some other) Thomas
<snip>
....
As already written a couple of weeks ago, we regularly get
OutOfMemoryErrors with our Wicket-based website. I've finally got a
heapdump.hprof and no entry above 3kByte size is from our code. If
someone from the Wicket team is interested, I can send the
html-instance information sorted by size or instance count.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
