LGTM
-- Igor
> On Oct 19, 2018, at 7:40 PM, JC Beyler wrote:
>
> Hi all,
>
> I pushed the webrev into the submit repo and it failed to build due to
> internal tests that have references to the NSK_CPP_STUB. Here is the new
> webrev:
>
> Webrev:
On 10/18/18 6:12 PM, Mandy Chung wrote:
On 10/18/18 12:27 AM, David Holmes wrote:
Hi Dean,
On 18/10/2018 2:06 PM, dean.l...@oracle.com wrote:
You're right, I missed that. I think the right thing to do is call
current_thread_exiting while holding the Threads_lock.
Then we can get rid of
Hi Chris,
Please review an updated version of the fix that makes the tests to use a
custom pattern while waiting for the command to complete.
Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.05/
Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
Thanks!
--Daniil
On
Hi Jc,
Updated fix:
http://cr.openjdk.java.net/~amenkov/exclusiveBind/webrev.01/
Moved shared code to new Debuggee class.
--alex
On 10/19/2018 10:34, JC Beyler wrote:
Hi Alex,
I remember seeing this same code so went looking for it and saw it in
JdbTest.java (you added it here it seems:
Hi Chris,
Done!
Here is the newest version:
http://cr.openjdk.java.net/~jcbeyler/8212535/webrev.01/
Thanks for the review!
Jc
On Fri, Oct 19, 2018 at 2:24 PM Chris Plummer
wrote:
> Hi JC,
>
> iterinstcls006.cpp: Can you fix the indentation of the second line.
>
> 98
Whenever I change only whitespace, I run a variant of
hg diff -wbB
to more easily see that it's truly only whitespace that has changed.
On Fri, Oct 19, 2018 at 1:47 PM, JC Beyler wrote:
> Hi all,
>
> Here is the first of three webrevs to remove spaces around (); I also
> removed any space
Hi JC,
iterinstcls006.cpp: Can you fix the indentation of the second
line.
98 NSK_COMPLAIN2("Local storage was corrupted: %s
,\n\texpected value: %s\n",
99 (char *)storage_ptr,
storage_data);
On 10/19/18 9:47 AM, Daniil Titov wrote:
Hi Gary and Chris,
I am resending the previous email since the table in that email got corrupted.
Below is what output jdb prints when a breakpoint is hit depending on what
suspended policy is used:
The current behavior.
SUSPEND_ALL:Prompt is
I think the line number info is useful. You could have multiple
breakpoint messages coming in for different breakpoints and different
threads. A message limited to "Breakpoint hit:" is not very useful in
that situation.
I agree having tests look for a simple prompt is probably not a good
Hi Jc,
On 10/19/2018 10:34, JC Beyler wrote:
Hi Alex,
I remember seeing this same code so went looking for it and saw it in
JdbTest.java (you added it here it seems:
http://hg.openjdk.java.net/jdk/jdk/rev/083e731da31a).
I have two few questions:
- Does it make sense to put this code in
+1
--alex
On 10/19/2018 11:07, Hohensee, Paul wrote:
Looks good.
Paul
*From: *serviceability-dev
on behalf of JC Beyler
*Date: *Thursday, October 18, 2018 at 9:44 PM
*To: *"serviceability-dev@openjdk.java.net"
*Subject: *RFR (M) 8212148: Remove remaining NSK_CPP_STUBs
Hi all,
Here
Looks good.
Paul
From: serviceability-dev on
behalf of JC Beyler
Date: Thursday, October 18, 2018 at 9:44 PM
To: "serviceability-dev@openjdk.java.net"
Subject: RFR (M) 8212148: Remove remaining NSK_CPP_STUBs
Hi all,
Here is the final webrev to remove the NSK_CPP_STUB! Please review the end
Hi Gary,
Just want to remind that jdb is a tool for developers, not a tool for
testing.
On 10/19/2018 00:54, gary.ad...@oracle.com wrote:
It's not clear to me if the omitted location information for the non
stopping
cases was intentional or not. It may be sufficient to know that the
event
Hi all,
jira: https://bugs.openjdk.java.net/browse/JDK-8212151
webrev: http://cr.openjdk.java.net/~amenkov/exclusiveBind/webrev/
The fix updates the test to allow debuggee to select available port
instead of using error-prone "getFreePort" approach.
--alex
Hi Gary and Chris,
I am resending the previous email since the table in that email got corrupted.
Below is what output jdb prints when a breakpoint is hit depending on what
suspended policy is used:
The current behavior.
SUSPEND_ALL:Prompt is printed ( e.g. "main[1]"), location is printed
Hi Gary and Chris,
Below is the table that shows what jdb output is printed when a breakpoint is
hit depending on what suspended policy is used:
SUSPEND POLICY | PROMPT PRINTED | LOCATION PRINTED
---
If we put the flag into deprecation, I’d like to keep it for a year so people
have time to change their monitoring code (one release to change their code,
and another to run with their new code), which would be two releases. I don’t
know how the deprecation process works either. Note that
Hi Paul,
On Fri, 2018-10-12 at 00:03 +, Hohensee, Paul wrote:
> Please review a backport to jdk8u.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8195115
> Webrev: http://cr.openjdk.java.net/~phh/8195115/webrev.05/
> JDK11 patch: http://hg.openjdk.java.net/jdk/jdk/rev/5d3c5af82654
>
>
Looks good to me.
Should the comment "58 steps" be "58 stops"?
On 10/18/18 6:42 PM, Alex Menkov wrote:
Hi all,
Please review small test fix for
https://bugs.openjdk.java.net/browse/JDK-8212665
webrev:
http://cr.openjdk.java.net/~amenkov/deferredStep_endOfCycle/webrev/
The test verifies that
It's not clear to me if the omitted location information for the non
stopping
cases was intentional or not. It may be sufficient to know that the
event fired
without the extra information.
I don't think a settable prompt is required either. There are plenty of
jdb commands that
could be used
20 matches
Mail list logo
