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

[Kevin Walls]

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-)