Hi Brian,
This generally looks good, rather clever trick, i prefer it to using a cache.
I agree with Joe some comments are required as it is not immediately obvious
how this works.
The additional tests seem adequate (overflow of the overflow), it's easy to go
overboard e.g. you could test:
Can someone else give a second review on this.
Thank you
Tristan
On 01/07/2014 07:29 PM, David Holmes wrote:
On 7/01/2014 8:36 PM, Tristan Yan wrote:
Hi David
You're totally right. Sorry I ask you review it again.
http://cr.openjdk.java.net/~tyan/JDK-7027502/webrev.02/
Looks good now.
On Jan 9, 2014, at 10:52 AM, Tristan Yan tristan@oracle.com wrote:
Can someone else give a second review on this.
In a comment the bug you state:
here total_turns_taken is a static variable, it could affect by other tests
I don't quite know under what test circumstances that can
Changeset: 630a92015993
Author:psandoz
Date: 2014-01-09 10:52 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/630a92015993
8031187: DoubleStream.count is incorrect for a stream containing
Integer.MAX_VALUE elements
Reviewed-by: darcy
!
Thank you Paul
I change turn to local variable as well.
http://cr.openjdk.java.net/~tyan/JDK-7027502/webrev.03/
http://cr.openjdk.java.net/%7Etyan/JDK-7027502/webrev.03/
I am not sure I understand your second suggestion here, sum up
thread_turns of each Context(This is a fixed value)
On 9/01/2014 8:28 PM, Paul Sandoz wrote:
On Jan 9, 2014, at 10:52 AM, Tristan Yan tristan@oracle.com wrote:
Can someone else give a second review on this.
In a comment the bug you state:
here total_turns_taken is a static variable, it could affect by other tests
I don't quite know
On Jan 9, 2014, at 12:07 PM, Tristan Yan tristan@oracle.com wrote:
Thank you Paul
I change turn to local variable as well.
http://cr.openjdk.java.net/~tyan/JDK-7027502/webrev.03/
I am not sure I understand your second suggestion here, sum up thread_turns
of each Context(This is
On 9/01/2014 9:07 PM, Tristan Yan wrote:
Thank you Paul
I change turn to local variable as well.
http://cr.openjdk.java.net/~tyan/JDK-7027502/webrev.03/
http://cr.openjdk.java.net/%7Etyan/JDK-7027502/webrev.03/
Okay I think I get it now. Both MonitorTest and WaitersTest use the
Context
On 9/01/2014 9:27 PM, David Holmes wrote:
On 9/01/2014 9:07 PM, Tristan Yan wrote:
Thank you Paul
I change turn to local variable as well.
http://cr.openjdk.java.net/~tyan/JDK-7027502/webrev.03/
http://cr.openjdk.java.net/%7Etyan/JDK-7027502/webrev.03/
Okay I think I get it now. Both
Thanks David
I removed those pointless yield, is it okay you can sponsor this for me?
http://cr.openjdk.java.net/~tyan/JDK-7027502/webrev.04/
http://cr.openjdk.java.net/%7Etyan/JDK-7027502/webrev.04/
Regards
Tristan
On 01/09/2014 07:34 PM, David Holmes wrote:
On 9/01/2014 9:27 PM, David
On 09/01/2014 11:27, David Holmes wrote:
Okay I think I get it now. Both MonitorTest and WaitersTest use the
Context class, so if both tests run in the same VM the second test
will see the static total_turns_taken and turn in the state they
were left from the first test - hence the second
On Jan 9, 2014, at 1:48 AM, Paul Sandoz wrote:
This generally looks good, rather clever trick, i prefer it to using a cache.
I agree with Joe some comments are required as it is not immediately obvious
how this works.
I have some simpler comments almost done being redacted.
The
On 1/9/14 7:38 PM, Mandy Chung wrote:
On 1/9/2014 10:18 AM, Daniel Fuchs wrote:
OK - I removed the unnecessary calls.
http://cr.openjdk.java.net/~dfuchs/webrev_8031068-jdk9/webrev.02/
Thumbs up! Thanks for the update.
You have fixed a few test failures of this issue. Do you know if
there
On 9/01/2014 10:14 PM, Alan Bateman wrote:
On 09/01/2014 11:27, David Holmes wrote:
Okay I think I get it now. Both MonitorTest and WaitersTest use the
Context class, so if both tests run in the same VM the second test
will see the static total_turns_taken and turn in the state they
were left
Hi David
I wasn't able to reproduce this failure either in local or in our same
binaries running(This is a continuous running with same JDK binaries).
So intention for this code change is bringing this test back; add some
debug info and try to avoid possible issues in this test. I agree this
David/Peter you are right, the logs trace came from passed run, i am
trying to simulate the failure and get the logs for failed runs(2000+
runs done and still no failure), will get back to you once i have the
data from failed run. Sorry for the confusion.
---
Thanks
kalyan
On 01/08/2014
Hi All,
Please review the fix for JNI pending exception issues reported in
jdk-8029007. Thanks!
Webrev: http://cr.openjdk.java.net/~dxu/8029007/webrev.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8029007
-Dan
Looks ok to me.
I presume getThreadStateValues is simply no longer needed.
-Chris.
On 10 Jan 2014, at 06:31, Dan Xu dan...@oracle.com wrote:
Hi All,
Please review the fix for JNI pending exception issues reported in
jdk-8029007. Thanks!
Webrev:
18 matches
Mail list logo
