incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart Monteith <>
Subject Re: Kato API javadoc - the order in which entries are returned from iterators
Date Wed, 15 Apr 2009 10:25:50 GMT
    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 


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.

View raw message