incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicholas Sterling <Nicholas.Sterl...@Sun.COM>
Subject Re: Kato API javadoc
Date Thu, 09 Apr 2009 22:08:08 GMT


Steve Poole wrote:
> On Wed, Apr 8, 2009 at 7:37 AM, Nicholas Sterling <Nicholas.Sterling@sun.
>
> Rather than returning an Iterator for the objects on the heap, why not make
> JavaHeap extend Iterable?  That way we could write
>
>   for ( JavaObject object : heap ) { ... }
>
> without having to call getObjects().  If we are using generics, I believe
> this would work for both objects and sections, because we would extend both
> Iterable<JavaObject> and Iterable<ImageSection>,  i.e.
>
>   for ( JavaObject   object  : heap ) { ... }
>   for ( ImageSection section : heap ) { ... }
>
>   
>
> Two questions
>
> 1) Isn't an Iterable just an iterator under the covers?
>   
An Iterable is a thing which can *return* an Iterator via the iterator() 
method.  In a for-statement like those above, the thing after the colon 
has to be Iterable, because the compiler is going to generate code to 
ask for its Iterator.
> 2) I thought you could only have one Iterable implemented by a class?
>
>   
Unfortunately, you are right.  The following does not work:

    import java.util.ArrayList;

    public class GenericInterfaceTest
        _implements Iterable<String>, Iterable<Integer>_ {

        ArrayList<String>  strings  = new ArrayList<String >();
        ArrayList<Integer> integers = new ArrayList<Integer>();

        public GenericInterfaceTest() {
            strings.add("foo");
            strings.add("bar");
            integers.add(1);
            integers.add(2);
        }

        _public Iterator<String> iterator()_ {
            return strings.iterator();
        }

        _public Iterator<Integer> iterator()_ {
            return integers.iterator();
        }

        public static void main( String[] args ) {
            GenericInterfaceTest git = new GenericInterfaceTest();
            for ( String  string  : git ) { System.out.println( string  ); }
            for ( Integer integer : git ) { System.out.println( integer ); }
        }
    }

Since the method being interited from the interface, iterator(), only 
differs in its return type, it can't work.  Actually, I think 
implementing the same interface twice with different types is disallowed 
in any case because of type erasure 
<http://forums-beta.sun.com/thread.jspa?messageID=1418132>.

Presumably the list of sections is of manageable size, though, so we 
could have a method that returns a List of them, such that we could say

  for ( JavaObject   object  : heap            ) { ... }
  for ( ImageSection section : heap.sections() ) { ... }


>>> (3) At various times in the past, we had some discussions about
>>> potentially
>>> using a cursor-style API rather than an iterator, for large sets like the
>>> one from JavaHeap.getObjects(), to avoid excessive object allocation in
>>> the
>>> analyzer tool JVM.  How do you feel about that?
>>>
>>>
>>>       
>> Between fast allocation techniques, fast GC for short-lived objects, and
>> the use of escape analysis to enable stack allocation, I'm not sure there's
>> a big win in a cursor-style API.  Is the main disadvantage of a cursor-style
>> API that you have to copy objects if you want to remember them, as opposed
>> to just hanging on to references as they fly by?
>>     
>
>
> The big win for the cursor design is that you do not have to create any new
> objects when visiting a list - so you could argue that copying just what you
> want need is actually a blessing not a curse.
>
>   
Yes, I agree, and it may be worth doing.  But my point was that avoiding 
allocation and GC of short-lived objects is almost surely not a *big* 
win in a modern VM, and we should have reasonable expectations.  Let's 
suppose for the moment that the net effect of using a cursor approach is 
to make diagnostic tools doing mostly that kind of work, say, 5-10% 
faster -- is that worth forcing people to explicitly copy objects?  
Cursors were a big win at the time JDBC was created because object 
allocation and GC were huge performance problems at the time.

If we did use cursors, would clone() be sufficient to copy a JavaObject, 
or would a deeper copy be required?

Again, I'm not really opposed to the use of cursors.  I just don't want 
us to go that route in hopes of achieving a big performance benefit, 
because that's probably not realistic.

Nicholas





Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message