RFR: 8010278 SA: provide mechanism for using an alternative SA debugger back-end.

[Kevin Walls]

Forgot to mention:

I moved the ClassDump Tool around a little so it was usable via a route 
other than calling main(), and added the constructor that takes a String 
for the pkgList, which saves using the system property to communicate 
what classes you want to dump 
(sun.jvm.hotspot.tools.jcore.PackageNameFilter has that constructor 
already).

Actually, considering the package filter name is always going to be 
sun.jvm.hotspot.tools.jcore.PackageNameFilter, let's have that as a 
default value when we call getProperty.  Similarly the getProperty for 
outputDir, and at that point I stop tweaking.

A little indenting was off also and I added a comment, so I redid the 
webrev:

http://cr.openjdk.java.net/~kevinw/8010278/webrev.01/

Thanks
Kevin



On 23/05/13 11:00, Kevin Walls wrote:
> Hi,
>
> As the Serviceability Agent has been _the_ new and interesting way to 
> find things post-mortem in the JVM [1], I'd like to propose an update 
> which continues that tradition.
>
> 8010278 SA: provide mechanism for using an alternative SA debugger 
> back-end.
> https://jbs.oracle.com/bugs/browse/JDK-8010278
> http://cr.openjdk.java.net/~kevinw/8010278/webrev.00/
>
> This is about making the SA more flexible, so we aren't tied to the 
> given native libraries to open cores/memory dumps.  Given this change, 
> a 3rd party debugger or tool can interact freely with the SA tools 
> (StackTrace, ObjectHistogram, etc...) and provide its own backend 
> implementation to actually open a core/memory dump.
>
> Primarily for platform-independent core file debugging.  If you ever 
> had to open a "foreign" core, find the right hardware, etc... this is 
> relevant.   I'm thinking of https://java.net/projects/kjdb which can 
> serve as a proof of concept.
>
> The changes are:
>
> The main redirection is in HotSpotAgent.java, where we respect a 
> property (i.e. -Dsa.altHotSpotAgent=...) to name an alternate debugger.
>
> Remove calls to System.exit.
>
> Tool classes (and CLHSDB) should have a constructor that takes a 
> JVMDebugger, to remove the assumption that a Tool's JVM will only ever 
> contain one debugee.  It doesn't address that VM is a singleton and if 
> a tool opens multiple sessions then they would need to be from the 
> same JVM version.
>
>
> Thanks
> Kevin
>
> [1]  If you weren't in a circa 1.4.2 demo of the SA when all you had 
> previously was a few fragile dbx macros, that got you a few very 
> specific details, the night vs. day comparison of no SA vs. SA could 
> be missed. 8-)
>
>