Thanks Staffan,
Yes, the GUI does still close and the standalone HSDB ends, without
forcibly terminating the process if it's initiated by some other app.
Can I get anybody else interested in reviewing, commenting, etc...?
Thanks
Kevin
On 24/06/13 12:18, Staffan Larsen wrote:
On 24 jun 2013, at 11:20, Staffan Larsen<staffan.lar...@oracle.com> wrote:
On 19 jun 2013, at 14:40, Kevin Walls<kevin.wa...@oracle.com> wrote:
Hi Staffan --
And apologies from me for the slow turnaround. 8-)
Thanks for the suggestions, implementing them all.
Thanks.
http://cr.openjdk.java.net/~kevinw/8010278/webrev.02/
Also adding the same kind of change to the HSDB tool, a few changes there to
get the gui closing without using System.exit.
So how do I now exit the HSDB tool? Closing the window won't exit. File->Exit
won't exit. Or did I miss something?
I did miss that the workerThread is also terminated in closeUI() and that
causes the app to exit.
This looks good. Reviewed.
/Staffan
/Staffan
Additional feedback gratefully received...
Thanks
Kevin
On 05/06/13 12:00, Staffan Larsen wrote:
Some comments (sorry it took so long):
CLHSDB.java
- Can you move the jvmDebugger field to where the other fields are in the
class? Make it private, too.
- Remove start() and make run() public?
- Perhaps improve on the comment in run() saying that either jvmDebugger OR
pidText OR {execPath, coreFileName} should be set.
HotspotAgent.java
- Should sa.altHotSpotAgent be called sa.altDebugger ?
Tool.java
- Make jvmDebugger private.
Regards,
/Staffan
On 23 maj 2013, at 15:23, Kevin Walls<kevin.wa...@oracle.com> wrote:
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-)
