Re: Kato API javadoc - the order in which entries are returned from iterators

[Steve Poole <sp...@googlemail.com>]

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 <st...@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.
>>>>
>>>>
>>>

Re: Kato API javadoc - the order in which entries are returned from iterators

[Stuart Monteith <st...@stoo.me.uk>]

I am curious as to what ordering would make sense - I think Dan would 
have elaborate on what ordering he does just now.
What do you mean by "fully connected"? At its extreme, as well as going 
from every JavaObject to their JavaClasses, you could go from a 
JavaClass to all of the JavaObjects that are instances of it.

Oh dear, I fear Dan is going to ask for that now :-)

Stuart

Steve Poole wrote:
> 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 <st...@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.
>>>>>
>>>>>
>>>>>           
>
>