You are viewing a plain text version of this content. The canonical link for it is here.
Posted to kato-spec@incubator.apache.org by Daniel Julin <dp...@us.ibm.com> on 2009/04/11 01:44:07 UTC
Re: Kato API javadoc - the order in which entries are returned from
iterators
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
Posted by 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.
>>>>>
>>>>>
>>>>>
>
>
Re: Kato API javadoc - the order in which entries are returned from
iterators
Posted by 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
Posted by Stuart Monteith <st...@stoo.me.uk>.
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
Posted by Stuart Monteith <st...@stoo.me.uk>.
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.
>>