On 21/11/2011 01:39, David Holmes wrote:
Never mind - Alan already tracked down reviews and did push.
Yes, I pushed the three that I thought had been reviewed and thoroughly
battered to death. There is a fourth one
(test/java/lang/ThreadGroup/Stop.java) that I need to double check who
the revi
On 11/21/11 5:37 AM, Alan Bateman wrote:
On 21/11/2011 01:39, David Holmes wrote:
Never mind - Alan already tracked down reviews and did push.
Yes, I pushed the three that I thought had been reviewed and
thoroughly battered to death. There is a fourth one
(test/java/lang/ThreadGroup/Stop.java)
On 11/21/11 05:44 AM, Gary Adams wrote:
On 11/21/11 5:37 AM, Alan Bateman wrote:
On 21/11/2011 01:39, David Holmes wrote:
Never mind - Alan already tracked down reviews and did push.
Yes, I pushed the three that I thought had been reviewed and thoroughly
battered to death. There is a fourth o
On 21/11/2011 10:17 PM, Gary Adams wrote:
On 11/21/11 05:44 AM, Gary Adams wrote:
On 11/21/11 5:37 AM, Alan Bateman wrote:
On 21/11/2011 01:39, David Holmes wrote:
Never mind - Alan already tracked down reviews and did push.
Yes, I pushed the three that I thought had been reviewed and
thoroug
On 21/11/2011 12:17, Gary Adams wrote:
Here's a fresh bug number to handle the volatile revision (pun intended)
7114125 java/util/Timer/KillThread.java should use volatile cross
thread variable declaration
Here's a fresh webrev for the proposed adjusted fix.
http://cr.openjdk.java.net/~gad
Changeset: 184578f3e8b9
Author:alanb
Date: 2011-11-21 12:51 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/184578f3e8b9
7084033: TEST_BUG: test/java/lang/ThreadGroup/Stop.java fails intermittently
Reviewed-by: forax, chegar, dholmes
Contributed-by: gary.ad...@oracle.com
! te
Changeset: 2db942c7eb9c
Author:alanb
Date: 2011-11-21 12:57 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2db942c7eb9c
7114125: TEST_BUG: java/util/Timer/KillThread.java should use volatile cross
thread variable declaration
Reviewed-by: dholmes, alanb
Contributed-by: gary.a
On 21/11/2011 12:45, Alan Bateman wrote:
On 21/11/2011 12:17, Gary Adams wrote:
Here's a fresh bug number to handle the volatile revision (pun intended)
7114125 java/util/Timer/KillThread.java should use volatile cross
thread variable declaration
Here's a fresh webrev for the proposed adjus
Le 21/11/2011 14:05, Alan Bateman a écrit :
On 21/11/2011 12:45, Alan Bateman wrote:
On 21/11/2011 12:17, Gary Adams wrote:
Here's a fresh bug number to handle the volatile revision (pun
intended)
7114125 java/util/Timer/KillThread.java should use volatile cross
thread variable declaration
Some clean up of the RMI RegistryImpl class is necessary after late changes
made in the last set of update releases.
This is a webrev to bring the code into sync with 6uX, 7uX.
The java.rmi.server.codebase property no longer needs to be parsed by the
registryImpl.
webrev : http://cr.openjdk.java
Thank you for the review David. I'll make the changes to the test
program as you have suggested and I will also update the bug report with
the comments you have given. I'll then send out an updated webrev.
Just to double-check, when you mention "But I don't see a way around it"
in regards to
The original complaint about the flakey mutex regression test is
that it was failing on slower machines. The delay at the end of
the processing is unnecessarily restrictive. Since the test harness
will terminate after 120 seconds if the test hangs, the test does
not have to terminate more quickly
On 21/11/2011 19:26, Gary Adams wrote:
The original complaint about the flakey mutex regression test is
that it was failing on slower machines. The delay at the end of
the processing is unnecessarily restrictive. Since the test harness
will terminate after 120 seconds if the test hangs, the test
webrev : http://cr.openjdk.java.net/~robm/7095949/webrev.00/
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7095949
-Rob
Not quite as sure about the internal timeouts in this regression test.
Here's a proposed change that cranks up the timeouts. Since the test
harness defaults to 2 minutes there's no reason the service termination
should timeout more quickly. For the thread startup, I added a countdown latch
so th
On 22/11/2011 4:29 AM, Brandon Passanisi wrote:
Thank you for the review David. I'll make the changes to the test
program as you have suggested and I will also update the bug report with
the comments you have given. I'll then send out an updated webrev. Just
to double-check, when you mention "But
Hello core-libs-dev. I am currently investigating the issues regarding
the following bug:
http://monaco.sfbay.sun.com/detail.jsf?cr=6178739
I have spent a good amount of time stepping through the simple
TestFormat code supplied in the bug report. I noticed some interesting
behavior when
Hi Gary,
On 22/11/2011 5:26 AM, Gary Adams wrote:
The original complaint about the flakey mutex regression test is
that it was failing on slower machines. The delay at the end of
the processing is unnecessarily restrictive. Since the test harness
will terminate after 120 seconds if the test hang
Gary,
On 22/11/2011 6:26 AM, Gary Adams wrote:
Not quite as sure about the internal timeouts in this regression test.
Here's a proposed change that cranks up the timeouts. Since the test
harness defaults to 2 minutes there's no reason the service termination
should timeout more quickly. For the
Hello Martin,
On 11/18/2011 6:29 AM, Martin Desruisseaux wrote:
Hello all
On December 1, 2010, "darcy" committed a slight performance
improvement to the StrictMath.min/max methods with floating point
arguments (commit 8aabca72877c). The calls to the
doubleToLongBits(double) method were repla
20 matches
Mail list logo
