On 19 jun 2013, at 14:40, Kevin Walls <[email protected]> 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? /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<[email protected]> 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-) >>>> >>>> >
