incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Poole <spoole...@googlemail.com>
Subject Re: Kato API javadoc - the order in which entries are returned from iterators
Date Wed, 15 Apr 2009 17:12:36 GMT
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 <stukato@stoo.me.uk> 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<JavaClass> getDefinedClasses(Order order);
>>   public Iterator<JavaClass> 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.
>>>>
>>>>
>>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message