We need to make an adjustment to the link instructions used for libjava
in embedded builds, as defined in Defs-embedded.gmk
webrev: http://cr.openjdk.java.net/~dholmes/7109092/webrev/
Summary: system soft-float libraries need not have the level of accuracy
required by Java floating-point seman
On 23/11/2011 6:03 AM, Chris Hegarty wrote:
Looks good to me. Thanks for taking it.
+1
David
-Chris.
On 11/22/11 07:47 PM, Gary Adams wrote:
Here's another test that had an assumption that the threads
would terminate within a 10 second window. On a busy or
slow machine this limit may not be
Hi Darryl,
On 23/11/2011 4:32 AM, Darryl Mocek wrote:
I've resolved all issues given in the comments. Please review the
update. Webrev can be found here:
http://cr.openjdk.java.net/~dmocek/5035850/
Minor nit: in the test you took Mike's suggestion for the three
conditions to check but seem to
Thumbs up.
Thanks,
David
-
On 23/11/2011 1:57 AM, Gary Adams wrote:
Revised webrev is available :
- removed the latch logic not required for main to worker thread
coordination
- increased the timeout to allow service shutdown to 120 seconds
(will exit sooner if services finish)
- increased
Thumbs up from me.
David
On 23/11/2011 1:46 AM, Gary Adams wrote:
Revised webrev is available
- removed the loop on termination
- increased the original internal termination timeout
to 120 seconds.
The termination can exit sooner as the services are shutdown.
The 120 second timeout is consiste
Hi Neil,
On 22/11/2011 9:51 PM, Neil Richards wrote:
I've created a webrev [1] to address the problem reported in bug
7094995, where the ClearStaleZipFileInputStreams testcase leaves a
lingering GC inducing thread running after the test ends (when run in
agentvm mode), as spotted by Alan and men
Hi Sean,
The webrev looks good. Thanks for handling the ports of this change to all the
different source bases.
s'marks
On 11/21/11 9:19 AM, Seán Coffey wrote:
Some clean up of the RMI RegistryImpl class is necessary after late changes
made in the last set of update releases.
This is a webr
Hi,
java.util.zip.Adler32/CRC32 do not have update method that accepts
ByteBuffer.
As of JDK7, you have to copy the content of the ByteBuffer into a
byte[], then
invoke Adler32/CRC32.update() method, which might have significant
performance
impact for some applications. Here I'm proposing to a
Hello Joe
Le 22/11/11 04:20, Joe Darcy a écrit :
3) In if statements, replaced:
(a == 0.0d) && (Double.doubleToLongBits(a) == negativeZeroDoubleBits)
by
(Double.doubleToLongBits(a) == negativeZeroDoubleBits)
since the later implies the former.
The performance properties of the two versions o
Looks good to me. Thanks for taking it.
-Chris.
On 11/22/11 07:47 PM, Gary Adams wrote:
Here's another test that had an assumption that the threads
would terminate within a 10 second window. On a busy or
slow machine this limit may not be sufficient. Since the jtreg
harness uses 120 second defa
Here's another test that had an assumption that the threads
would terminate within a 10 second window. On a busy or
slow machine this limit may not be sufficient. Since the jtreg
harness uses 120 second default value for terminating a
test, the test should not be more restrictive.
http://cr.op
On 11/22/11 06:56 PM, Alan Bateman wrote:
On 22/11/2011 17:22, Neil Richards wrote:
:
Can you tell me, when jtreg decides to fire an interrupt at a test, has
it already concluded that the test has "failed" (or, at least, not
"passed") ?
With othervm (the default) then each test is run in its
On 22/11/2011 17:22, Neil Richards wrote:
:
Can you tell me, when jtreg decides to fire an interrupt at a test, has
it already concluded that the test has "failed" (or, at least, not
"passed") ?
With othervm (the default) then each test is run in its own VM so the process
termination will ens
I've resolved all issues given in the comments. Please review the
update. Webrev can be found here:
http://cr.openjdk.java.net/~dmocek/5035850/
Thanks,
Darryl
On 11/20/2011 05:31 PM, David Holmes wrote:
On 21/11/2011 5:39 AM, Rémi Forax wrote:
On 11/20/2011 08:14 PM, Alan Bateman wrote:
O
On Tue, 2011-11-22 at 17:22 +, Neil Richards wrote:
> On Tue, 2011-11-22 at 16:56 +, Chris Hegarty wrote:
> > This change does look good.
> >
> > Not directly related to your changes Neil, and I know we swallow
> > InterruptedException in many tests, but does it make sense to set
> > kee
On Tue, 2011-11-22 at 16:56 +, Chris Hegarty wrote:
> This change does look good.
>
> Not directly related to your changes Neil, and I know we swallow
> InterruptedException in many tests, but does it make sense to set
> keepRunning = false if the GcInducingThread is interrupted?
>
> jtreg
This change does look good.
Not directly related to your changes Neil, and I know we swallow
InterruptedException in many tests, but does it make sense to set
keepRunning = false if the GcInducingThread is interrupted?
jtreg will use Thread.interrupt when trying to "cleanup" after the test
h
On Tue, 2011-11-22 at 15:49 +, Alan Bateman wrote:
> On 22/11/2011 11:51, Neil Richards wrote:
> > Hi all,
> >
> > I've created a webrev [1] to address the problem reported in bug
> > 7094995, where the ClearStaleZipFileInputStreams testcase leaves a
> > lingering GC inducing thread running aft
Revised webrev is available :
- removed the latch logic not required for main to worker thread coordination
- increased the timeout to allow service shutdown to 120 seconds
(will exit sooner if services finish)
- increased delay after service shutdown to ensure
thread counts wi
On 22/11/2011 11:51, Neil Richards wrote:
Hi all,
I've created a webrev [1] to address the problem reported in bug
7094995, where the ClearStaleZipFileInputStreams testcase leaves a
lingering GC inducing thread running after the test ends (when run in
agentvm mode), as spotted by Alan and mentio
Revised webrev is available
- removed the loop on termination
- increased the original internal termination timeout
to 120 seconds.
The termination can exit sooner as the services are shutdown.
The 120 second timeout is consistent with the jtreg defaults,
but can also work standalo
Changeset: 1945abeb82a0
Author:mullan
Date: 2011-11-22 08:58 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1945abeb82a0
7093090: Reduce synchronization in java.security.Policy.getPolicyNoCheck
Reviewed-by: valeriep
! src/share/classes/java/security/Policy.java
Changeset: b
On 11/22/11 11:56 AM, Alan Bateman wrote:
On 22/11/2011 02:08, David Holmes wrote:
Chris - are you keeping on eye on these test changes and whether there
will be any sync'ing up needed with Doug's CVS?
I've been keepng an eye on these, from a distance ;-)
We have in the past pushed a f
On 22/11/2011 02:08, David Holmes wrote:
:
I support raising the timeout rather than waiting forever, as these
tests should be able to run standalone and in that case they should
not hang upon encountering a bug. I'm wary of assuming there is a
higher-level test harness involved. Also note th
Hi all,
I've created a webrev [1] to address the problem reported in bug
7094995, where the ClearStaleZipFileInputStreams testcase leaves a
lingering GC inducing thread running after the test ends (when run in
agentvm mode), as spotted by Alan and mentioned in another conversation
[2].
It modifie
Changeset: ee2fa62fb09f
Author:ngmr
Date: 2011-11-22 09:51 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ee2fa62fb09f
7114558: Inet4AddressImpl should use memset (rather than bzero) and NI_MAXHOST
(rather than MAXHOSTNAMELEN)
Reviewed-by: chegar
Contributed-by: Neil Richard
On 11/21/11 08:10 PM, Rob McKenna wrote:
webrev : http://cr.openjdk.java.net/~robm/7095949/webrev.00/
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7095949
Looks fine to me.
Thanks for porting this to 7u-dev. These intermittent failures are a
real pain!
-Chris.
-Rob
Changeset: 81987765cb81
Author:ngmr
Date: 2011-11-11 14:40 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/81987765cb81
7112670: Inet4AddressImpl should use getaddrinfo/getnameinfo
Reviewed-by: chegar, alanb, mduigou, ngmr
Contributed-by: Charles Lee
! src/solaris/native/jav
28 matches
Mail list logo
