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: JSR 326: Post mortem JVM Diagnostics API - Developing the Specification
Date Tue, 06 Jan 2009 00:21:31 GMT

Steve Poole wrote:
>> Don't you think it would be better to do this for NetBeans?  :^)  :^)
> I don't have an axe to grind here :-)  I personally ike Eclipse above
> Netbeans and have written quite a few eclipse plugins.  However it would be
> good
> to have a plugin for another IDE to help validate that our assumptions on
> what a ui program looks like are valid.    There is ample oppotunity to
> include
> a NetBeans plugin but my team doesn't have the expertise to wite it.
> Any volunteers?
While I would certainly encourage trying to keep the GUI code reasonably 
well abstracted in the tool, I suspect that it would work well enough 
simply to write it for Eclipse and then port it later.  I would probably 
have an easier time convincing somebody at Sun to port an existing tool 
to NetBeans than to participate in its development anyway.  Hopefully if 
changes were made in the process of doing the port, they could be 
accepted back into the Kato project.  It might be easier to just write 
an Eclipse plugin (with some mindfulness of the desire to port it later) 
without having to ensure that the code is entirely IDE-agnostic out of 
the gate.

Of course, if there's somebody in the group who wants to do a NetBeans 
module, I'm all for it.
>> Notice that with this approach you could actually compare the results of
>> running the same app on two different VMs.  There would be lots of
>> differences between the two runtimes, but who cares -- the analysis modules
>> would extract only the parts that are relevant to the comparison.
> Yes understand.   I wonder if we could do the same with the other query
> languages.    
It appears that OQL supports the usual set operations: UNION, INTERSECT, 
EXCEPT.  Except is MINUS (or MINUS ALL; they probably have both variants).
> My thought was that it would be too expensive to dump a dump
> into a database and then query it -  I expected  that the query support
> would need to be built "under the covers"  into the API so that we could
> have it as close to the data as possible and allow implementors the
> oppotunity for parrellisation and other optimisations.
Yes, I suspect that often it would be easier just to do the work while 
traversing the heap.  Other times you might get done faster by 
extracting the 0.01% of the info in the heap that matters to you and 
then poking around at it.  But in either case you could use OQL; we 
might just want to build in a mechanism for storing the results of one 
march through the heap and then traversing that in further passes.


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