From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5140 invoked by alias); 8 Aug 2012 20:37:56 -0000 Received: (qmail 5133 invoked by uid 22791); 8 Aug 2012 20:37:55 -0000 X-SWARE-Spam-Status: No, hits=-6.0 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx3-phx2.redhat.com (HELO mx3-phx2.redhat.com) (209.132.183.24) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 08 Aug 2012 20:37:38 +0000 Received: from zmail13.collab.prod.int.phx2.redhat.com (zmail13.collab.prod.int.phx2.redhat.com [10.5.83.15]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q78Kbbf1002479; Wed, 8 Aug 2012 16:37:37 -0400 Date: Wed, 08 Aug 2012 20:37:00 -0000 From: Jon VanAlten To: Lukas Berk Cc: systemtap@sourceware.org, distro-pkg-dev@openjdk.java.net Message-ID: <1956303607.34675944.1344458257034.JavaMail.root@redhat.com> In-Reply-To: <20120802131039.GA1955@redhat.com> Subject: Re: [RFC] Enhanced Garbage Collection Probe Points MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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/msg00178.txt.bz2 ----- Original Message ----- > From: "Lukas Berk" > To: distro-pkg-dev@openjdk.java.net > Cc: systemtap@sourceware.org > Sent: Thursday, August 2, 2012 9:10:40 AM > Subject: [RFC] Enhanced Garbage Collection Probe Points > > Hey, > > I've been working on adding improved probe point within the garbage > collection system. This will allow system administrators using > various > tools to better analyze which garbage collection algorithms are > effective and java developers to better understand how (often) their > objects are being collected. > > Specific probe points that I've aimed to include are: > > - G1, concurrent mark sweep, parallel mark sweep, and tenured > collections > > - new generation definitions > > - parallel scavenges > > - parallel compaction > > - object 'moves/resizes' between memory addresses > > Please note that the attached patch should be appended to the > patch/systemtap.patch file. Any feedback or suggestions would be > greatly appreciated. > 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! 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? 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? Other than that; great start, this definitely has stuff interesting from a Thermostat perspective and the potential for more :D cheers, jon