incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Julin <...@us.ibm.com>
Subject Re: Kato API javadoc - the order in which entries are returned from iterators
Date Sat, 11 Apr 2009 01:44:07 GMT

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