incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Hall <ahall...@googlemail.com>
Subject Kato & Native Memory
Date Thu, 25 Jun 2009 11:30:22 GMT
Hi Folks,

Since this is my first posting I'll briefly introduce myself. My name is
Andrew Hall and I work in the IBM Java development team. My primary
interests are serviceability, debugging and, in particular, debugging native
memory problems in a Java environment.

One of the problems I see is users filling up their native address space
with Java artifacts with native backing like threads, classloaders and
direct byte buffers. One of the ways we could tackle this at JVM level is to
have counters for the native footprint for the various JVM subsystems - and
we could put this data in dumps and expose it via Kato. (I believe the
JRockit runtime already exposes this data.) This would allow users to see
how their Java artifacts affect native footprint. I think of this data as a
hierarchy of counters (SDK->VM->GC->Java Heap for example) - and I think it
would be good to maintain that structure in the API.

Other other area I'm thinking about at the moment is storage containing
eyecatchers. Since a most of the data we need to solve native memory issues
isn't in memory, we could add it by tagging storage as its allocated with a
header and/or footer containing a eyecatcher. We would need to extract
blocks surrounded by these eyecatchers from dumps post-mortem to analyze the
results. While the header format would be implementation specific, I think
extracting eyecatchered storage is a generic task that may belong on the
API.

I'm interested to hear if anyone else is facing similar problems and whether
this is something people feel should be supported through the Kato API.

Regards,

Andrew

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message