From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30401 invoked by alias); 8 Aug 2012 22:05:03 -0000 Received: (qmail 30335 invoked by uid 22791); 8 Aug 2012 22:05:01 -0000 X-SWARE-Spam-Status: No, hits=-6.7 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 mx4-phx2.redhat.com (HELO mx4-phx2.redhat.com) (209.132.183.25) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 08 Aug 2012 22:04:35 +0000 Received: from zmail13.collab.prod.int.phx2.redhat.com (zmail13.collab.prod.int.phx2.redhat.com [10.5.83.15]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q78M4XaI024206; Wed, 8 Aug 2012 18:04:33 -0400 Date: Wed, 08 Aug 2012 22:05:00 -0000 From: Jon VanAlten To: Lukas Berk Cc: systemtap@sourceware.org, distro-pkg-dev@openjdk.java.net Message-ID: <1070281724.34752559.1344463473803.JavaMail.root@redhat.com> In-Reply-To: <20120808211122.GA17399@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/msg00180.txt.bz2 ----- Original Message ----- > From: "Lukas Berk" > To: "Jon VanAlten" > 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 [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