incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Poole <spoole...@googlemail.com>
Subject Re: Kato & Native Memory
Date Thu, 25 Jun 2009 14:07:56 GMT
Thanks for the input Andrew.

A few questions...

On Thu, Jun 25, 2009 at 12:30 PM, Andrew Hall <ahall451@googlemail.com>wrote:

> 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.
>

If we gave users this information what would they do with it?   I assume
that they would want to use it to influence their applications and
configurations.   Do you have anything to share about why users want this
information?

>
> 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 agree - its sort of the least we could do in this area :-)      How would
you want to see the data -  as a list  , a map (eyecatcher -> list of hits
)   or would this best be done by providing a visitor like mechanism?


> 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