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