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 Mon, 06 Apr 2009 19:24:55 GMT
It's very nice being able to look at this javadoc -- thanks!

It might help to have a little introductory text in some of the key 
classes giving some context, something along the lines of the DTFJ 
example on your web site that opens a core dump and iterates through the 
threads.

I wonder if ImageThread should return interface RegisterSet, of which 
there would be various implementations for various CPU types, each 
containing a map from a Register enum to a RegisterValue.

I hadn't realized until I started looking through this javadoc how much 
easier the use of generics makes it to understand an API.  For example, 
under JavaClassLoader I see methods getCachedClasses() and 
getDefinedClasses(), but I can't tell from their signatures whether they 
return the same type or not.  That info is in the method descriptions, 
but it's a lot more work to flip back and forth between the Summary and 
the Detail.

Nicholas


Steve Poole wrote:
> On Mon, Apr 6, 2009 at 6:51 AM, Nicholas Sterling <Nicholas.Sterling@sun.com
>   
>> wrote:
>>     
>
>   
>> Great!  I've passed this on to the HotSpot folks for comment.
>>
>> I think I remember us talking about there being some provision for
>> accessing the vendor-specific VM constructs that implement the heap, etc.,
>> in addition to the Java objects in it.  Will that be done by, for example,
>> casting a JavaVM to a HotSpotVM and using the latter's extra methods?
>>
>>     
>
> That's the most obvious solution I think.
>
>   
>> Also, I'm seeing methods that return Iterator with no type (e.g. in
>> JavaMethod).  Is that just a temporary placeholder which will ultimately get
>> a type?
>>     
>
>
> That's an interesting question.   The reason for there being no type info is
> that the API was designed to compile and run on 1.4.2.
> We need to decide if that still makes sense.   I know that 1.4 is out of
> support by Sun and IBM.    What about Oracle?
>
>   
>> Nicholas
>>
>>
>>
>> Steve Poole wrote:
>>
>>     
>>> Well at last ! -  we actually have the API javdoc available -  it's here
>>> http://hudson.zones.apache.org/hudson/view/Kato/job/kato.api-head/javadoc/
>>>
>>> I'm certainly not going to hold this up as a the greatest javadoc in the
>>> world but its a good place to start.  I do feel that we have  finally
>>> arrived :-)
>>>
>>> The API has lots of "DTFJ"ness to it that needs to go but I'm really
>>> interested in intitial reactions to the javadoc -  is the form of the API
>>> what you expected?
>>>
>>>
>>> Moving on - there is still code needed to make the API work (we need to
>>> get
>>> the hprof support working)   but  we can make progress in the interim.  I
>>> want to move quickly towards having a regular heat beat where we are
>>> moving
>>> through the usecases that we have.  To do that we need to  get  up to
>>> speed
>>> with the API shape as it stands today.    Stuart has published some info
>>> on
>>> the  API but its not really sufficent for educational needs :-)
>>>
>>> Is it worth holding a conference call so that we can walk through the API
>>> to
>>> explain why its the shape it is or is everyone comfortable with just more
>>> doc?
>>>
>>> Cheers
>>>
>>> Steve
>>>
>>>
>>>
>>>       
>
>   

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