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