From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17216 invoked by alias); 29 Aug 2012 11:52:44 -0000 Received: (qmail 17207 invoked by uid 22791); 29 Aug 2012 11:52:43 -0000 X-SWARE-Spam-Status: No, hits=-3.0 required=5.0 tests=AWL,BAYES_00,KAM_MX3,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS,URIBL_BLACK X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 29 Aug 2012 11:52:24 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q7TBqNYq012070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 29 Aug 2012 07:52:23 -0400 Received: from springer.wildebeest.org (ovpn-113-60.phx2.redhat.com [10.3.113.60]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q7TBqMdq012632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Aug 2012 07:52:23 -0400 Received: by springer.wildebeest.org (Postfix, from userid 500) id 81FB84463C; Wed, 29 Aug 2012 13:52:21 +0200 (CEST) Message-ID: <1346241141.3052.58.camel@springer.wildebeest.org> Subject: Re: [RFC] Enhanced Garbage Collection Probe Points From: Mark Wielaard To: Lukas Berk Cc: Jon VanAlten , systemtap@sourceware.org, distro-pkg-dev@openjdk.java.net Date: Wed, 29 Aug 2012 11:52:00 -0000 In-Reply-To: <20120828212242.GA29101@redhat.com> References: <20120822203308.GA7445@redhat.com> <1651488727.58755626.1345838351275.JavaMail.root@redhat.com> <20120828212242.GA29101@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2012-q3/txt/msg00251.txt.bz2 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.ht= ml 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. > >=20 > > 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