incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart Monteith <stuk...@stoo.me.uk>
Subject Re: Kato API javadoc - the order in which entries are returned from iterators
Date Wed, 15 Apr 2009 14:08:23 GMT
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
View raw message