Re: [RFC] Enhanced Garbage Collection Probe Points

[Mark Wielaard <mjw@redhat.com>]

Hi Lukas,

On Tue, 2012-08-28 at 17:22 -0400, Lukas Berk wrote:
> > We have a hotspot.stp, a hotspot_jni.stp; maybe this one should be
> > hotspot_gc.stp?
> Done, its now included as hotspot_gc.stp.in

I like it this way. Thanks.

> > Adding this fluff to the existing systemtap.patch, may not be the
> > best way.  As I understand it, Mark is trying to get the existing
> > stuff upstream.  Combining this into same IcedTea patch may make
> > it more difficult if/when this upstreaming is eventually successful
> > and needs to be removed from IcedTea.  I'd suggest introducing a
> > separate patch to the icedtea sources.
> Makes sense to me, I've adjusted the autoconf files accordingly to
> include and apply patches/systemtap_gc.patch if icedtea is configure
> with --enable-systemtap.

That also looks good. For 6 I split up the original systemtap.patch into
separate patches too. See
http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2012-August/019851.html
Eventually all those patches should go directly into the forest (or
Andrew Hughes will kill me for polluting the tree with even more
patches) but lets do all those in one step later. For now the separate
patch is great.

Please do post and ping systemtap_gc.patch to
hotspot-gc-dev@openjdk.java.net one last time. It would be really good
if some hotspot gc hacker could comment. We can always try.

> > Well, I am basically OK with this aside from the things mentioned
> > above.  I guess remaining still is the question of testing these.  I
> > wouldn't block this based on lacking tests (the previous probes went
> > untested for ages before I added tests), but I also don't want this
> > to go in without a plan to eventually add tests; when we did add
> > tests for the other probes, we actually found regressions and even
> > things that had never properly worked iirc.
> > 
> > Have you given any thought to how you might add tests for these
> > probes to the existing set of probe tests?
> Ideally I'd have some java test programs that would be able to allocate
> enough objects to trigger collections.  As mentioned earlier, different
> gc algorithms can be specified with jvm options, but what would be
> tricky is controlling the gc invocation via jvm options in a reliable
> enough manner that we can reasonably expect scavenges to occur.  I would
> have to experiment with that to see if its possible, if anybody else
> knows how to easily do that please let me know.

Take a look at test/tapset/jstaptest.pl, make check-tapset-probes and
make check-tapset-jstack. You can probably do something similar. Please
ask if the test code looks too hairy (it probably is...).

Cheers,

Mark