Thanks Dmitry and Staffan!
Kevin
On 25/06/13 19:47, Dmitry Samersoff wrote:
Kevin,
Looks good for me!
Thumbs up.
-Dmitry
On 2013-06-25 14:13, Kevin Walls wrote:
OK I'm coming back with a bit more change as well as those points.
http://cr.openjdk.java.net/~kevinw/8010278/webrev.03/
To cl
Kevin,
Looks good for me!
Thumbs up.
-Dmitry
On 2013-06-25 14:13, Kevin Walls wrote:
>
> OK I'm coming back with a bit more change as well as those points.
>
> http://cr.openjdk.java.net/~kevinw/8010278/webrev.03/
>
> To clarify what's going on: there are actually two sides to this which I
Looks good me (still).
/Staffan
On 25 jun 2013, at 12:13, Kevin Walls wrote:
>
> OK I'm coming back with a bit more change as well as those points.
>
> http://cr.openjdk.java.net/~kevinw/8010278/webrev.03/
>
> To clarify what's going on: there are actually two sides to this which I had
> pr
OK I'm coming back with a bit more change as well as those points.
http://cr.openjdk.java.net/~kevinw/8010278/webrev.03/
To clarify what's going on: there are actually two sides to this which I
had probably mixed up more than was necessary:
*existing debugger:* the HotSpotAgent is being crea
Thanks Kevin,
You answered all my questions ;)
-Dmitry
On 2013-06-24 18:53, Kevin Walls wrote:
> Thanks Dmitry --
>
> I'll come back with an update, but just a couple of responses...
>
>
>
> On 24/06/13 15:01, Dmitry Samersoff wrote:
>> On 2013-06-24 17:48, Kevin Walls wrote:
>>> Thanks Dmit
Thanks Dmitry --
I'll come back with an update, but just a couple of responses...
On 24/06/13 15:01, Dmitry Samersoff wrote:
On 2013-06-24 17:48, Kevin Walls wrote:
Thanks Dmitry --
CommandProcessor.java:
Yes, should make quit volatile.
HSDB.java:
The idea is to avoid System.exit as it i
On 2013-06-24 17:48, Kevin Walls wrote:
>
> Thanks Dmitry --
>
>
> CommandProcessor.java:
> Yes, should make quit volatile.
>
>
> HSDB.java:
> The idea is to avoid System.exit as it is really unfriendly when another
> app invokes the tool. The existing usage pattern is:
>
> new HSDB(args)
Thanks Dmitry --
CommandProcessor.java:
Yes, should make quit volatile.
HSDB.java:
The idea is to avoid System.exit as it is really unfriendly when another
app invokes the tool. The existing usage pattern is:
new HSDB(args).run();
..so avoiding System.exit() means making run() guard a
Kevin,
* CommandProcessor.java:
"quit" should be volatile.
* HSDB.java:
argError logic is not clean to me. Is it possible to just do return
after doUsage or use System.exit()?
* HotSpotAgent.java:
1.
You can probably check whether "debugger" variable is already set or not
and get rid of "
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
On 24 jun 2013, at 11:20, Staffan Larsen wrote:
>
> On 19 jun 2013, at 14:40, Kevin Walls 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
On 19 jun 2013, at 14:40, Kevin Walls 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 HSD
Hi Staffan --
And apologies from me for the slow turnaround. 8-)
Thanks for the suggestions, implementing them all.
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
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, core
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
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
16 matches
Mail list logo
