From kato-spec-return-117-apmail-incubator-kato-spec-archive=incubator.apache.org@incubator.apache.org Wed Apr 15 17:13:09 2009 Return-Path: Delivered-To: apmail-incubator-kato-spec-archive@minotaur.apache.org Received: (qmail 1811 invoked from network); 15 Apr 2009 17:13:08 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 15 Apr 2009 17:13:08 -0000 Received: (qmail 32768 invoked by uid 500); 15 Apr 2009 17:13:07 -0000 Delivered-To: apmail-incubator-kato-spec-archive@incubator.apache.org Received: (qmail 32734 invoked by uid 500); 15 Apr 2009 17:13:07 -0000 Mailing-List: contact kato-spec-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: kato-spec@incubator.apache.org Delivered-To: mailing list kato-spec@incubator.apache.org Received: (qmail 32673 invoked by uid 99); 15 Apr 2009 17:13:07 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 15 Apr 2009 17:13:07 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of spoole167@googlemail.com designates 209.85.219.172 as permitted sender) Received: from [209.85.219.172] (HELO mail-ew0-f172.google.com) (209.85.219.172) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 15 Apr 2009 17:12:56 +0000 Received: by ewy20 with SMTP id 20so3302076ewy.12 for ; Wed, 15 Apr 2009 10:12:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=jaUWw36tacumtOhFlpxj4LnYOpsN0v/TfOBnzawDU0s=; b=PXPKndEbfbxw6rHH1pV6nI/J7sqxKYLcTcaSnS+WU36tgzeHzTW2v4XRcDID2vM39r Wbaj97QgZA2ZiQ1k3YRAYODWRpm6wY4r6JhLY6wFzeC81miz5BWQduk2gVUH+K5h2kIx 1NGC6TKTDqn6HlsWuZw+vmOZs9RbGCXPRI6FM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=vzwvcAgCkbkbF/v51dr/JtY/HJbEhkNG2moAFOvt95UQ6LwEhn8F84aMZK16rtSJPC ucHAtSQ4ul1/qb4a/3MNadef0TmPfJy3atllVhiZeG11ZVkADZZylWWwPGsH1zG0T0TE P8NfK/TFuCs7/4iWoVGdFvox/nlfMbWArTY4E= MIME-Version: 1.0 Received: by 10.216.30.206 with SMTP id k56mr25075wea.86.1239815556126; Wed, 15 Apr 2009 10:12:36 -0700 (PDT) In-Reply-To: <49E5EA57.5090403@stoo.me.uk> References: <49DA5707.3040301@Sun.COM> <85b044530904061331g9e382ach938b5287bab47ccb@mail.gmail.com> <49DA69EA.7000908@Sun.COM> <49DC4612.1040502@Sun.COM> <49E5B62E.6080600@stoo.me.uk> <49E5EA57.5090403@stoo.me.uk> Date: Wed, 15 Apr 2009 18:12:36 +0100 Message-ID: Subject: Re: Kato API javadoc - the order in which entries are returned from iterators From: Steve Poole To: kato-spec@incubator.apache.org Content-Type: multipart/alternative; boundary=0016e6dd89e8cf573804679b0d41 X-Virus-Checked: Checked by ClamAV on apache.org --0016e6dd89e8cf573804679b0d41 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I assume that the ordering required is related to the type of analysis/query being run. If a fully connected graph was available between the various elements would that remove the need for ordering? On Wed, Apr 15, 2009 at 3:08 PM, Stuart Monteith wrote: > A colleague of mine has pointed out how the JavaClass.getObject() method is > optional - it might return null - the JavaDoc repeats this. > Still, if there are classes on the heap, it would be useful to be able to > understand what they are. It does raise the question of why we have > JavaClass.getObject() at all. > > > Stuart Monteith wrote: > >> Hi, >> The link from JavaClass to it's JavaObject java/lang/Class instance but >> not vice-versa is a common problem, and I believe there should be a return >> path, simply because it is a typical thing to do. >> >> The situation with the ordering is even worse, things aren't returned in >> any defined order, with some exceptions (such as stack frames). >> However, which ordering would be correct? While there is certainly a case >> for evaluating the relationships between the JavaClasses, JavaClassLoader, >> JavaObjects, JavaMonitor (There is "JavaObject JavaMonitor.getObject()" but >> no "JavaMonitor JavaObject.getMonitor()") etc., we can enumerate all of >> them, but the ordering of results is a more general question. Are we >> discussing SQL/OQL as a solution to that? >> >> How would the ordering be specified? >> >> A simple, but fixed way would be to offer precanned ordering: >> >> public class JavaClassLoader { >> public enum Order { BYNAME, BYID, BYSUPERCLASSNAME, NONE}; >> >> public Iterator getDefinedClasses(Order order); >> public Iterator getCachedClasses(Order order); >> } >> >> Would this be sufficient, or would we like to do more? Very often there >> isn't a lot to be said about a particular object without reference to >> others. >> >> Stuart >> >> >> Daniel Julin wrote: >> >>> I like the idea of __asking__ the API if it could please give us the >>> entries in a particular order, but accepting the fact that maybe it can't >>> and dealing with that case explicitly when needed. >>> >>> What drives me crazy right now is having to expensively sort lots of >>> entries in my analyzer modules, and thinking that maybe the underlying >>> core >>> reader library could have given me these entries in the right order much >>> more cheaply, if only I could ask. >>> >>> Note that this principle of taking advantage of shortcuts that may >>> optionally be available in the core reader library implementation, may >>> not >>> be limited to the order of entries in iterators. For example, in the >>> current API, if you're looking at an instance of JavaObject that happens >>> to >>> be of type java/lang/Class, there is no direct way to get the JavaClass >>> corresponding to the class for which this object is the class object. You >>> have to go all the way around, enumerate all the JavaClassLoaders and all >>> their defined JavaClasses, until you find one whose JavaClass.getObject() >>> is equal to your original JavaObject. I believe this is because in some >>> implementations of the core readers, providing this direct link would be >>> just as expensive as the roundabout way that I just described. But I have >>> to believe that in some other core reader implementations, this link >>> could >>> be provided much more cheaply. So could we take advantage of it when >>> possible? >>> >>> >>> -- Daniel -- >>> >>> >>> Nicholas.Sterling@Sun.COM wrote on 2009-04-08 02:37:06 AM: >>> >>> >>> >>>> Daniel Julin wrote: >>>> >>>> >>>>> Some thoughts about these iterators, also based on earlier experiences >>>>> >>>>> >>>> with >>> >>> >>>> the DumpAnalyzer tool: >>>>> >>>>> >>>>> >>>> ... >>> >>> >>>> (2) The API does not actually define any specific order in which the >>>>> entries are returned by the various iterators, and I wish it would. For >>>>> example: >>>>> >>>>> * When walking through all the objects on a heap, some heap analysis >>>>> functions (and some file formats like PHD) require that the objects be >>>>> returned in the order corresponding to the increasing addresses where >>>>> >>>>> >>>> they >>> >>> >>>> are located on that heap. It turns out that, in all the >>>>> >>>>> >>>> implementations >>> >>> >>>> that I've seen so far, JavaHeap.getObjects() does provide that order, >>>>> >>>>> >>>> but >>> >>> >>>> nowhere does it say that I can count on it in every future >>>>> >>>>> >>>> implementation. >>> >>> >>>> Of course, for some future collector it might be difficult to produce >>>> the objects in that order. What if there were a way of setting the >>>> order you want, and if the provider can't do it, then it could throw an >>>> exception saying that that's unimplemented. >>>> >>>> >>> --0016e6dd89e8cf573804679b0d41--