Re: [RFC] Enhanced Garbage Collection Probe Points

[Jon VanAlten <jvanalte at redhat dot com>]

----- Original Message -----
> From: "Lukas Berk" <lberk@redhat.com>
> To: "Jon VanAlten" <jvanalte@redhat.com>
> Cc: systemtap@sourceware.org, distro-pkg-dev@openjdk.java.net
> Sent: Wednesday, August 8, 2012 5:11:23 PM
> Subject: Re: [RFC] Enhanced Garbage Collection Probe Points
> 
> * Jon VanAlten <jvanalte@redhat.com> [2012-08-08 16:38]:
> [...]
> > 
> > Hi Lukas,
> > 
> > I've had a look at the patch, and the rest of the thread
> > (especially the
> > tapset you posted, which made things a LOT more clear so thanks for
> > that).
> > I hope that you'll continue to refine the tapset and contribute
> > that as
> > well so that us java hackers who are brave enough to play with
> > Systemtap
> > have the nice friendly probe names and variables to work with!
> Thanks for taking a look, I'll make sure to include it in future
> revisions, ideally I'll have a gc_details.stp.in file that will have
> the
> .so path change based on the system it's being compiled for. (similar
> to
> the hotspot{,_jni}.stp.in and jstack.stp.in files already included)

Yep, that would be the Right Way for it to be included!

> > 
> > The patch itself seems fine, although I'll just have to trust you
> > that the
> > probes are in the right place as I'm not really a hotspot hacker
> > myself.
> > Really I would hope that someone who is more familiar with the GC
> > code
> > base will comment from that perspective.
> > 
> > I assume that none of these probes require any special VM args to
> > function?
> > A related question, and this might be hard to answer being rather
> > open
> > ended, but are you aware of any VM args that would affect/interfere
> > with
> > the functioning of these probes?
> The only arguments that I can think of that will immediately effect
> these probes are:
> -XX:+UseSerialGC
> -XX:+UseParallelGC
> -XX:+UseParallelOldGC
> -XX:+UseParNewGC
> -XX:+UseConcMarkSweepGc
> -XX:+UseG1GC
> which will force the JVM to use the designated type of garbage
> collection.  There may be more I'm missing (please let me know if
> there
> are).

Right, good to know.  I'd recommend documenting the specifics in
the tapset itself, much like is done for probes in hotspot.stp
(for example, monitor_wait).  No others come to mind, but there
sure are some esoteric options and I wouldn't presume to know them
all nor be familiar with the subtleties of their effects!

> > 
> > There is a begin and and end probe for some types of collection and
> > even
> > phases within collection, so it seems odd to me that for G1
> > stop-the-world
> > collection there is not.  Am I missing something?
> 
> My thought in adding the begin/end probes was to be able to track
> parallel operations and tie a specific pid to an collection/scavenge
> to
> an object.  That wouldn't be needed in serial operation.  However,
> now
> that I think about it, it could be useful to mark the beginning and
> end
> of 'serial' collections from a timing perspective, and its trivial to
> add (I'll include it in a revised patch).

On the other hand, some of these may be redundant.  See also from
hotspot.stp the probes mem_pool_gc_begin and mem_pool_gc_end.

cheers,
jon