On 22 feb 2012, at 11:22, A. Sundararajan wrote: > SA uses stop-the-world to debug "snapshot" of the process. BugSpot was > supposed to be a SA model where you can pause/resume and keep looking at > different snapshots (as well as use JDI to look at process state). But, it > was never implemented that way. Over the years lot of stuff accumulated > assuming the snapshot model as well.
So what does BugSpot have that HSDB does not (and the other way around)? Could one of them be retired? > And yes, JSDB may not be directly useful - but you can use most of > functionality CLHSDB using script "load" as Kris mentioned. So maybe CLHSDB can be improved and JSDB retired? > SOQL: Better option is to retrieve heap dump from core/process using jmap (or > SA internals) and view it by jhat or VisualVM. Same thing here? Thanks for the feedback, /Staffan > > -Sundar > > Krystal Mok wrote: >> Hi Staffan, >> >> There's at least another frontend, the SA Plugin for Visual VM. I think it >> only uses the BugSpotAgent for attaching/detaching, otherwise it doesn't use >> stuff from BugSpot. >> Other tools, e.g. jstack -m, jstack -F, jmap -F, etc., are not exactly SA >> frontends, but use the SA to implement their functionality. >> >> I use CLHSDB a lot when I poke around the internals of HotSpot. It's good >> for its purpose, except that history support is really weird, e.g. pressing >> up arrow give "^[[A". When I need commands not available in CLHSDB yet, I >> can write a JavaScript file and use "jsload" in CLHSDB to extend it with new >> commands. Example here: [1]. >> >> I seldom use JSDB directly, because the command style of CLHSDB works >> better, if the commands cover all the needs during a debugging session. When >> writing new commands for CLHSDB, sometimes I use the "jseval" command to try >> things out first, before actually writing them into a script file. That >> overlaps with what JSDB does, but of course prototyping in JSDB would be >> much nicer than in CLHSDB. >> >> On the top of my wishlist on CLHSDB, I'd wish for: >> 1. better input support (something like jline would be great) >> 2. AMD64 disassembler support (not frontend issue) >> 3. live stepping/breakpointing support (not frontend issue) >> >> If 2 and 3 is implemented, I might be able to spend more time in CLHSDB, >> where sometimes I have to use a native debugger like gdb. But these aren't >> frontend issue anyway. I'd be grateful for any advise on how to debug a >> product build HotSpot with gdb instead of CLHSDB, where a lot of debugging >> support functions are not available in HotSpot itself and the symbols are >> inconvenient to access. >> >> On the GUI side, Poonam did a presentation on the SA Plugin in JavaOne 2011. >> The "Future Plans" part sounds interesting. I think this plugin is the most >> visible way to use SA for most end users. It'd be great if it could be open >> sourced and made more extensible, say, embedding a variant of CLHSDB into >> this plugin. >> >> Regards, >> Kris Mok >> >> [1]: https://gist.github.com/1393698 >> On Wed, Feb 22, 2012 at 4:26 PM, Staffan Larsen <staffan.lar...@oracle.com >> <mailto:staffan.lar...@oracle.com>> wrote: >> >> I'm trying to figure out what the different front ends to SA are >> and how they differ. So far I have identified the following: >> >> HSDB - basic UI >> CLHSDB - command line version of HSDB >> BugSpot - improvement over HSDB ?? >> JSDB - JavaScript command line >> SOQL - Simple Object Query Language command line >> >> Have I missed any? >> >> What are your experiences with these? Which ones are most used? >> Should we maintain all of them? Can we consolidate them into one? >> Specifically: what is the difference between HSDB and BugSpot? >> >> I'd be happy for all and any feedback, >> /Staffan >> >> >
