The security tests look fine.
--Sean
On 11/01/2013 07:18 AM, Sergey Bylokhov wrote:
Hello.
Please review the fix for jdk 8.
Most of tests in the sound area, and some tests in the client,
java.lang, security, jmx etc has incorrect copyright.
According to the http://openjdk.java.net/faq
GPL v2 +
Hi Everyone
http://cr.openjdk.java.net/~pzhang/Tristan/7190106/webrev/
Description:
1. Convert shell script test to Java program test.
2. Using random server port by reusing Darryl Mocek's work to replace
fixed server port.
3. Using java Process class to start client process.
4. Also convert
On 10/31/13 10:22 PM, Tristan Yan wrote:
I am working on bug https://bugs.openjdk.java.net/browse/JDK-7190106. Based
on my research, it looks like the issue of fixed port was already addressed
by Stuart Marks in other RMI tests which are Java based. I would like to
reuse his solution, however it
/Hi Everyone
/
/I am working on bug https://bugs.openjdk.java.net/browse/JDK-8025198.
Root cause for this bug is //there is a race condition on below code.
//there is a very small chance that when 11th thread finishes
allStarted.countDown() and before check the count, 10th thread does
Webrev at:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.00/
This fixes the finalization implementation to invoke the finalize method
via shared secret so that it will call the same method as the bytecode
invocation.
The current implementation uses JNI_GetMethodID to find
Change looks good to me(not a reviewer).
Cheers,
Henry
On 11/01/2013 10:57 AM, Paul Sandoz wrote:
Hi,
This is a eating humble pie and should of correctly listened to Henry in
review kind of email :-)
The changes to DistinctOpTest recently committed result in a test failure,
since one of
Hi Tristan,
Without commenting on the specifics of this test, in my estimation we
should strongly favor rewriting shell tests as Java programs, as has
already largely been done in the langtools area:
Shelling Tests
https://blogs.oracle.com/jjg/entry/shelling_tests
-Joe
On
Changeset: cc80c03c41e4
Author:vromero
Date: 2013-11-01 19:08 +
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/cc80c03c41e4
8027660: javac crash while creating LVT entry for a local variable defined in
an inner block
Reviewed-by: jjg
Contributed-by:
2013/11/1 4:15 -0700, mandy.ch...@oracle.com:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.00/
Looks good.
Just one question: In Finalizer.java, at line 97 you look up the
JavaLangAccess object every single time. Is it worth caching that
earlier, maybe when the finalize
Changeset: 8b4e1421a9b7
Author:jlahoda
Date: 2013-11-01 21:43 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8b4e1421a9b7
8027310: Annotation Processor crashes with NPE
Summary: JCAnnotation.attribute is null when annotation type is unavailable
Reviewed-by: jjg,
Changeset: 6a6faa00acc4
Author:dxu
Date: 2013-11-01 14:40 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6a6faa00acc4
8027624: com/sun/crypto/provider/KeyFactory/TestProviderLeak.java unstable again
Reviewed-by: wetmore
!
Please review at your convenience:
Issue:
https://bugs.openjdk.java.net/browse/JDK-8027625
Patch:
--- a/test/java/math/BigInteger/ExtremeShiftingTests.java Fri Nov 01
14:40:03 2013 -0700
+++ b/test/java/math/BigInteger/ExtremeShiftingTests.java Fri Nov 01
17:03:04 2013 -0700
@@
Looks good to me.
-Dan
On 11/01/2013 05:07 PM, Brian Burkhalter wrote:
Please review at your convenience:
Issue:
https://bugs.openjdk.java.net/browse/JDK-8027625
Patch:
--- a/test/java/math/BigInteger/ExtremeShiftingTests.java Fri Nov 01
14:40:03 2013 -0700
+++
Hi Mandy,
Thank you. Patch looks good.
Regards,
Jeroen
-Original Message-
From: core-libs-dev-boun...@openjdk.java.net [mailto:core-libs-dev-
boun...@openjdk.java.net] On Behalf Of Mandy Chung
Sent: Friday, November 1, 2013 19:16
To: core-libs-dev@openjdk.java.net
Subject:
Hi Mandy (and Mark),
The getter can be optimized away, the static field can't, so this is probably a
tiny bit more expensive.
Regards,
Jeroen
-Original Message-
From: core-libs-dev-boun...@openjdk.java.net [mailto:core-libs-dev-
boun...@openjdk.java.net] On Behalf Of Mandy Chung
On 02/11/2013 00:07, Brian Burkhalter wrote:
Please review at your convenience:
Issue:
https://bugs.openjdk.java.net/browse/JDK-8027625
Patch:
Thanks for that, this test has been failing with OOME in some
environments since the recent change.
-Alan.
On 11/01/2013 10:11 PM, Mandy Chung wrote:
On 11/1/13 1:37 PM, mark.reinh...@oracle.com wrote:
2013/11/1 4:15 -0700, mandy.ch...@oracle.com:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.00/
Looks good.
Just one question: In Finalizer.java, at line 97 you look up the
On 01/11/2013 11:18, Sergey Bylokhov wrote:
Hello.
Please review the fix for jdk 8.
Most of tests in the sound area, and some tests in the client,
java.lang, security, jmx etc has incorrect copyright.
According to the http://openjdk.java.net/faq
GPL v2 + the Classpath exception for the class
On 02.11.2013 15:37, Alan Bateman wrote:
On 01/11/2013 11:18, Sergey Bylokhov wrote:
Hello.
Please review the fix for jdk 8.
Most of tests in the sound area, and some tests in the client,
java.lang, security, jmx etc has incorrect copyright.
According to the http://openjdk.java.net/faq
GPL v2
Hi,
I propose a set of straightforward optimizations of annotations in the
field of minimizing garbage creation and execution performance. Here's a
webrev containing the changes:
http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationOptimizations/webrev.01/
Changes grouped by class/method:
Changeset: adcc01f5bc93
Author:jrose
Date: 2013-11-02 20:08 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/adcc01f5bc93
8024635: Caching MethodType's descriptor string improves lambda linkage
performance
Summary: Better interpreted and compiled performance of operations in
Thank you Martin
I had code change. I took the similar way as you do here.
Please review the code change for JDK-8025198.
Description:
Race condition exists in the test ThrowingTasks.java. We should sync
CountDownLatch.countDown and CountDownLatch.getCount.
Hi Tristan,
On 4/11/2013 10:49 AM, Tristan Yan wrote:
Thank you Martin
I had code change. I took the similar way as you do here.
Please review the code change for JDK-8025198.
Description:
Race condition exists in the test ThrowingTasks.java. We should sync
CountDownLatch.countDown and
Hi Mandy,
On 2/11/2013 7:11 AM, Mandy Chung wrote:
On 11/1/13 1:37 PM, mark.reinh...@oracle.com wrote:
2013/11/1 4:15 -0700, mandy.ch...@oracle.com:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.00/
Looks good.
Just one question: In Finalizer.java, at line 97 you look up
On 4/11/2013 1:42 PM, Martin Buchholz wrote:
On Sun, Nov 3, 2013 at 5:09 PM, David Holmes david.hol...@oracle.comwrote:
Locking access to a CountDownLatch just seems inherently wrong. I get that
it is the atomicity of the two calls that we want, but this still seems
unpleasant. I've looked at
Thank you Martin
I updated the code as below
http://cr.openjdk.java.net/~ewang/tristan/JDK-8025198/webrev.02/
Thank you
On 11/04/2013 11:38 AM, Martin Buchholz wrote:
Tristan, I think your change it correct.
There are some stylistic improvements I would make:
- make lock final
- make
On 11/2/2013 3:41 AM, Peter Levart wrote:
On 11/01/2013 10:11 PM, Mandy Chung wrote:
On 11/1/13 1:37 PM, mark.reinh...@oracle.com wrote:
2013/11/1 4:15 -0700, mandy.ch...@oracle.com:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.00/
Looks good.
Just one question: In
On 11/3/2013 5:32 PM, David Holmes wrote:
Hi Mandy,
On 2/11/2013 7:11 AM, Mandy Chung wrote:
On 11/1/13 1:37 PM, mark.reinh...@oracle.com wrote:
2013/11/1 4:15 -0700, mandy.ch...@oracle.com:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.00/
Looks good.
Just one question:
Changeset: ae5f2130c3b9
Author:sundar
Date: 2013-11-01 19:54 +0530
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/ae5f2130c3b9
8027700: function redeclaration checks missing for declaration binding
instantiation
Reviewed-by: jlaskey, lagergren
!
Hi Mandy,
I'll wait for the updated webrev.
FYI I wasn't suggesting any VM changes regarding GetMethodID. I assumed,
incorrectly, that once you had the method ID you could query to see if
it was private. That said if you called GetMethodID on Object.class and
then did the CallVoidMethod(env,
On 11/04/2013 05:45 AM, Mandy Chung wrote:
On 11/3/2013 5:32 PM, David Holmes wrote:
Hi Mandy,
On 2/11/2013 7:11 AM, Mandy Chung wrote:
On 11/1/13 1:37 PM, mark.reinh...@oracle.com wrote:
2013/11/1 4:15 -0700, mandy.ch...@oracle.com:
On 4/11/2013 4:40 PM, Martin Buchholz wrote:
David and I might prefer a fix using AtomicInteger, but I don't think
there's anything incorrect with your fix - approved. Especially if you
have seen the flakiness has gone away. (I've never seen this test fail.)
+1
David
On Sun, Nov 3, 2013
On 11/04/2013 07:52 AM, Peter Levart wrote:
Also VM.awaitBooted seems inherently risky as a general method as
you would have to make sure that it is never called by the main VM
initialization thread. Perhaps handle this in
sun.misc.SharedSecrets.getJavaLangAccess so it is less 'general'?
On 11/04/2013 05:45 AM, Mandy Chung wrote:
That said I think Peter may be right that there could be races with
agents triggerring explicit finalization requests early in the VM
initialization process - which means any blocking operation dependent
on other parts of the initialization sequence
On 31/10/2013 19:54, huizhe wang wrote:
A quick fix to remove path for the temporary output file so that it's
created in the working directory instead:
http://cr.openjdk.java.net/~joehw/jdk8/8024876/webrev/
Just reading this now and wondering about xslFilename - is that closed
(as it's not
On 04/11/2013 08:33, Peter Levart wrote:
:
What about the following helper class in java.lang package:
If public then it leaks into the Java SE API. I think using
SharedSecrets should be okay, assuming we can sort out any potential
races getting to JavaLangAccess.
-Alan.
On 11/04/2013 09:48 AM, Alan Bateman wrote:
On 04/11/2013 08:33, Peter Levart wrote:
:
What about the following helper class in java.lang package:
If public then it leaks into the Java SE API. I think using
SharedSecrets should be okay, assuming we can sort out any potential
races getting to
On Nov 2, 2013, at 10:03 AM, Alan Bateman alan.bate...@oracle.com wrote:
On 01/11/2013 21:11, Mandy Chung wrote:
I was expecting that would get optimized during runtime and it's a simple
getter method. It's a good suggestion to cache it at the finalize thread
start time and here is the
My commit pulled in a bunch of local changes that should never have been
pushed (the import commit failed due to whitespace and when I re-issued
the commit I didn't restrict it to the single test file).
Can anyone roll this back on the actual server?
Thanks,
David
Original Message
On 04/11/2013 12:10, David Holmes wrote:
My commit pulled in a bunch of local changes that should never have
been pushed (the import commit failed due to whitespace and when I
re-issued the commit I didn't restrict it to the single test file).
Can anyone roll this back on the actual server?
On 4/11/2013 10:35 PM, Alan Bateman wrote:
On 04/11/2013 12:10, David Holmes wrote:
My commit pulled in a bunch of local changes that should never have
been pushed (the import commit failed due to whitespace and when I
re-issued the commit I didn't restrict it to the single test file).
Can
My commit for 8025198 dragged in unintended changes to:
! makefiles/CompileLaunchers.gmk
! makefiles/lib/CoreLibraries.gmk
! src/share/bin/java.c
See:
http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d19ab5da83cc
This reverts those changes:
http://cr.openjdk.java.net/~dholmes/8027755/webrev/
Changeset: 23982079ad49
Author:dholmes
Date: 2013-11-04 07:39 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/23982079ad49
8027755: Anti-delta incorrect push for 8025198
Reviewed-by: alanb
! makefiles/CompileLaunchers.gmk
! makefiles/lib/CoreLibraries.gmk
!
I'll sponsor this.
cheers
/Joel
On 31 okt 2013, at 01:33, Joseph Darcy joe.da...@oracle.com wrote:
Hi Andreas,
Approved; thanks,
-Joe
On 10/29/2013 3:26 AM, Andreas Lundblad wrote:
Hi,
Please review the fix for JDK-8016725 below.
Description:
DefaultMethodModeling.java and
Hi Peter,
As always, thanks for doing this!
On 2 nov 2013, at 22:58, Peter Levart peter.lev...@gmail.com wrote:
Hi,
I propose a set of straightforward optimizations of annotations in the field
of minimizing garbage creation and execution performance. Here's a webrev
containing the
Changeset: 92fb6baaebc4
Author:bpb
Date: 2013-11-04 08:05 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/92fb6baaebc4
8027625: test/java/math/BigInteger/ExtremeShiftingTests.java needs @run tag to
specify heap size
Summary: Add @run tag to specify heap size
Reviewed-by:
Changeset: 48449b5390fa
Author:michaelm
Date: 2013-11-04 17:47 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/48449b5390fa
8027687: The constructors of URLPermission class do not behave as described in
javad
Reviewed-by: chegar, mduigou
!
Changeset: 51b002381b35
Author:rfield
Date: 2013-11-04 10:12 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/51b002381b35
7194897: JSR 292: Cannot create more than 16 instances of an anonymous class
8027681: Lambda serialization fails once reflection proxy generation kicks in
Changeset: 78a0dcde6b67
Author:alundblad
Date: 2013-11-04 15:21 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/78a0dcde6b67
8016725: TEST_BUG: java/lang/reflect/Method/DefaultMethodModeling.java failing
intermittently
Summary: Moved DefaultMethodModeling.java to its own
On 11/3/13 10:52 PM, Peter Levart wrote:
On 11/04/2013 05:45 AM, Mandy Chung wrote:
On 11/3/2013 5:32 PM, David Holmes wrote:
Hi Mandy,
On 2/11/2013 7:11 AM, Mandy Chung wrote:
On 11/1/13 1:37 PM, mark.reinh...@oracle.com wrote:
2013/11/1 4:15 -0700, mandy.ch...@oracle.com:
Hi
Please review this small refactoring of the type annotations reflection code.
This fix just makes the types final since the code wasn't designed for
inheritance.
webrev: http://cr.openjdk.java.net/~jfranck/8027796/webrev.00/
jbs: https://bugs.openjdk.java.net/browse/JDK-8027796
cheers
Thank you all for the suggestions.
Before the VM initialization is completed, any agent ought to be careful
in what things it can do and what shouldn't do. I think it's reasonable
to ignore System.runFinalization if it's called at early startup phase.
I'm unclear if there is any use case
On 11/04/2013 07:12 PM, robert.fi...@oracle.com wrote:
Changeset: 51b002381b35
Author:rfield
Date: 2013-11-04 10:12 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/51b002381b35
7194897: JSR 292: Cannot create more than 16 instances of an anonymous class
8027681: Lambda
On 11/4/2013 12:38 AM, Alan Bateman wrote:
On 31/10/2013 19:54, huizhe wang wrote:
A quick fix to remove path for the temporary output file so that it's
created in the working directory instead:
http://cr.openjdk.java.net/~joehw/jdk8/8024876/webrev/
Just reading this now and wondering about
On Nov 4, 2013, at 1:37 PM, Remi Forax fo...@univ-mlv.fr wrote:
Note that while this fix is ok now,
it introduced a performance regression, doing reflection on a functional
method of an inner class
is faster than doing reflection on the functional method of a lambda proxy.
This particular
On 11/04/2013 11:56 PM, John Rose wrote:
On Nov 4, 2013, at 1:37 PM, Remi Forax fo...@univ-mlv.fr
mailto:fo...@univ-mlv.fr wrote:
Note that while this fix is ok now,
it introduced a performance regression, doing reflection on a
functional method of an inner class
is faster than doing
Changeset: 6d1f3ba68db2
Author:dxu
Date: 2013-11-04 15:48 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6d1f3ba68db2
8027612: java/io/File/MaxPathLength.java fails intermittently in the clean-up
stage
Reviewed-by: chegar
! test/java/io/File/MaxPathLength.java
Hi Mandy,
This all seems quite reasonable to me.
Two minor nits:
1. The delay ntil typo in Finalizer.java is still present.
2. In VM.java. booted need not be volatile now that it is only accessed
within a locked region. Also awaitBooted might as well be void as it can
only ever return true.
On 11/4/2013 6:03 PM, David Holmes wrote:
Hi Mandy,
This all seems quite reasonable to me.
Two minor nits:
1. The delay ntil typo in Finalizer.java is still present.
Missed that :(
2. In VM.java. booted need not be volatile now that it is only
accessed within a locked region. Also
On 5/11/2013 12:21 PM, Mandy Chung wrote:
On 11/4/2013 6:03 PM, David Holmes wrote:
Hi Mandy,
This all seems quite reasonable to me.
Two minor nits:
1. The delay ntil typo in Finalizer.java is still present.
Missed that :(
2. In VM.java. booted need not be volatile now that it is only
On 11/4/2013 6:29 PM, David Holmes wrote:
2. In VM.java. booted need not be volatile now that it is only
accessed within a locked region.
Oops my bad! The accessor wasn't synchronized but now is. Your call
whether to leave as is or revert to previous.
I'm fine with making isBooted() to a
David,
Rereading your comment and I think you misread the switch statement (see
my comments below). In any case, I revisited ThreadStateController.java
and looked int the potential races and have done further cleanup. Here
is the updated webrev.
Hi Mandy,
On 5/11/2013 1:20 PM, Mandy Chung wrote:
David,
Rereading your comment and I think you misread the switch statement (see
Yes I did - many times - sorry.
my comments below). In any case, I revisited ThreadStateController.java
and looked int the potential races and have done
Changeset: dcedc753fd09
Author:sundar
Date: 2013-11-04 18:52 +0530
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/dcedc753fd09
8027753: Support ScriptObject to JSObject, ScriptObjectMirror, Map, Bindings
auto-conversion as well as explicit wrap, unwrap
Reviewed-by: jlaskey,
On 11/05/2013 03:21 AM, Mandy Chung wrote:
On 11/4/2013 6:03 PM, David Holmes wrote:
Hi Mandy,
This all seems quite reasonable to me.
Two minor nits:
1. The delay ntil typo in Finalizer.java is still present.
Missed that :(
2. In VM.java. booted need not be volatile now that it is only
Hi Robert,
I think this fix is not complete. When one sets the system property
sun.reflect.noInflation=true, reflection proxy is still attempted to be
generated for anonymous classes (see
ReflectionFactory.newMethodAccessor/newConstructorAccessor).
I would also restructure the
On 04/11/2013 22:32, huizhe wang wrote:
:
It's closed, but outFilename was not. Since the behaviors are
different among parsers, I've added them all in a try-with-resources
statement.
Please review:
http://cr.openjdk.java.net/~joehw/jdk8/8024876/webrev/
Thanks, that makes it clear.
(I see
On Nov 4, 2013, at 8:36 PM, Joel Borggrén-Franck joel.fra...@oracle.com wrote:
Hi
Please review this small refactoring of the type annotations reflection code.
This fix just makes the types final since the code wasn't designed for
inheritance.
webrev:
On 11/04/2013 07:12 PM, robert.fi...@oracle.com wrote:
Changeset: 51b002381b35
Author:rfield
Date: 2013-11-04 10:12 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/51b002381b35
7194897: JSR 292: Cannot create more than 16 instances of an anonymous class
8027681: Lambda
Changeset: bda654c6d59c
Author:kshefov
Date: 2013-11-05 13:09 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/bda654c6d59c
8027708: NASHORN TEST: Create Nashorn test that draws image step-by-step using
JavaFX canvas.
Reviewed-by: jlaskey, lagergren
! make/build.xml
!
Ineexof(char) sounds like as fast and simpler?
Sent from my iPhone
On Nov 5, 2013, at 8:55 AM, Peter Levart peter.lev...@gmail.com wrote:
On 11/04/2013 07:12 PM, robert.fi...@oracle.com wrote:
Changeset: 51b002381b35
Author:rfield
Date: 2013-11-04 10:12 -0800
URL:
On Nov 5, 2013, at 3:21 AM, Mandy Chung mandy.ch...@oracle.com wrote:
2. In VM.java. booted need not be volatile now that it is only accessed
within a locked region. Also awaitBooted might as well be void as it can
only ever return true.
Fixed. Revised webrev at:
Following bugs have been fixed, related tests should be removed from
ProblemList:
8021230 (CODETOOLS-7900208
https://bugs.openjdk.java.net/browse/CODETOOLS-7900208has been
promoted in jtreg 4.1 b07)
java/lang/ThreadLocal/ThreadLocalSupplierTest.java generic-all
JDK-8026502
Hi John,
Speaking of names, the following test:
package pkg;
public class Test {
public static void main(String[] args)
{
Runnable r = () - {};
Class? c = r.getClass();
Class? ac = java.lang.reflect.Array.newInstance(c, 0).getClass();
Hi Peter,
Narrowing this to core-libs-dev.
On 5 nov 2013, at 09:25, Peter Levart peter.lev...@gmail.com wrote:
Hi Robert,
I think this fix is not complete. When one sets the system property
sun.reflect.noInflation=true, reflection proxy is still attempted to be
generated for anonymous
On 11/05/2013 10:33 AM, Joel Borggrén-Franck wrote:
I would also restructure the Method/Constructor accessor logic differently.
The check for ReflectUtil.isVMAnonymousClass() can be performed just once (in the
newMethodAccessor/newConstructorAccessor methods) and based on this check, create
Thanks Amy,
The updates look good to me. Just to confirm, have you verified that the
tests actually pass now?
-Chris.
On 05/11/2013 09:26, Amy Lu wrote:
Following bugs have been fixed, related tests should be removed from
ProblemList:
8021230 (CODETOOLS-7900208
On 05/11/2013 09:26, Amy Lu wrote:
:
Please review ProblemList.txt changes:
https://dl.dropboxusercontent.com/u/5812451/yl153753/8027822/webrev/index.html
This looks okay to me although I'm not sure about
sun/util/resources/TimeZone/Bug6317929.java (for some reason Aleksej
fixed the test
On 01/11/2013 17:57, Paul Sandoz wrote:
Hi,
This is a eating humble pie and should of correctly listened to Henry in
review kind of email :-)
The changes to DistinctOpTest recently committed result in a test failure,
since one of the tests is incorrectly asserting on a particular element,
On 5 nov 2013, at 10:51, Peter Levart peter.lev...@gmail.com wrote:
On 11/05/2013 10:33 AM, Joel Borggrén-Franck wrote:
I would also restructure the Method/Constructor accessor logic
differently. The check for ReflectUtil.isVMAnonymousClass() can be
performed just once (in the
On 05/11/2013 03:20, Mandy Chung wrote:
David,
Rereading your comment and I think you misread the switch statement (see
my comments below). In any case, I revisited ThreadStateController.java
and looked int the potential races and have done further cleanup. Here
is the updated webrev.
On 05/11/2013 02:21, Mandy Chung wrote:
Fixed. Revised webrev at:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.03/
I looked at the latest webrev.
Having runFinalization and runAllFinalizers be a no-open during
initialization is reasonable (it should never happen).
I
On Nov 5, 2013, at 8:26 AM, Peter Levart peter.lev...@gmail.com wrote:
P.S. I'm curious about the strange seemingly unneeded code fragments in
FinalizerThread and both Runnables. For example:
169 forkSecondaryFinalizer(new Runnable() {
170*private volatile boolean running;*
171
On Nov 5, 2013, at 11:11 AM, Alan Bateman alan.bate...@oracle.com wrote:
On 01/11/2013 17:57, Paul Sandoz wrote:
Hi,
This is a eating humble pie and should of correctly listened to Henry in
review kind of email :-)
The changes to DistinctOpTest recently committed result in a test
On 11/5/13 6:01 PM, Alan Bateman wrote:
On 05/11/2013 09:26, Amy Lu wrote:
:
Please review ProblemList.txt changes:
https://dl.dropboxusercontent.com/u/5812451/yl153753/8027822/webrev/index.html
This looks okay to me although I'm not sure about
sun/util/resources/TimeZone/Bug6317929.java
On 11/5/13 6:01 PM, Chris Hegarty wrote:
Thanks Amy,
The updates look good to me. Just to confirm, have you verified that
the tests actually pass now?
Yes, I tried them on one linux (as they are generic-all or linux-all)
and test PASS.
Thanks,
Amy
-Chris.
On 05/11/2013 09:26, Amy Lu
Changeset: d5b3f83ffc40
Author:psandoz
Date: 2013-11-05 12:08 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d5b3f83ffc40
8027712: DistinctOpTest fails for unordered test
Reviewed-by: henryjen, alanb
!
On 05/11/2013 10:59, Paul Sandoz wrote:
On Nov 5, 2013, at 8:26 AM, Peter Levartpeter.lev...@gmail.com wrote:
P.S. I'm curious about the strange seemingly unneeded code fragments in
FinalizerThread and both Runnables. For example:
169 forkSecondaryFinalizer(new Runnable() {
Thanks Amy,
I can sponsor this change for you.
-Chris.
On 05/11/2013 11:09, Amy Lu wrote:
On 11/5/13 6:01 PM, Alan Bateman wrote:
On 05/11/2013 09:26, Amy Lu wrote:
:
Please review ProblemList.txt changes:
https://dl.dropboxusercontent.com/u/5812451/yl153753/8027822/webrev/index.html
On 11/05/2013 12:33 PM, Chris Hegarty wrote:
On 05/11/2013 10:59, Paul Sandoz wrote:
On Nov 5, 2013, at 8:26 AM, Peter Levartpeter.lev...@gmail.com wrote:
P.S. I'm curious about the strange seemingly unneeded code fragments
in FinalizerThread and both Runnables. For example:
169
Hi,
Can I have a review for tzdata2013h integration [1]. The webrev link can
be located here [2].
The following test sets were executed on build with fix:
test/sun/util/calendar test/java/util/Calendar
test/sun/util/resources/TimeZone test/sun/util/calendar
test/java/util/TimeZone
Hello,
Updated version:
http://cr.openjdk.java.net/~serb/8027696/webrev.01/
Dates and spaces were fixed.
On 02.11.2013 15:37, Alan Bateman wrote:
On 01/11/2013 11:18, Sergey Bylokhov wrote:
Hello.
Please review the fix for jdk 8.
Most of tests in the sound area, and some tests in the client,
Hi,
Can I have a review for a 8027848 [1] bug fix . There is unimplemented
functionality related to the future GMT offset changes.
The ZoneInfoFile class doesn't analyses if there is such offset changes
and as a result incorrectly creates the ZoneInfo instance.
It was discovered during the
Adding i18n-dev as this is the mailing list where this area is maintained.
On 05/11/2013 17:26, Aleksej Efimov wrote:
Hi,
Can I have a review for a 8027848 [1] bug fix . There is unimplemented
functionality related to the future GMT offset changes.
The ZoneInfoFile class doesn't analyses if
On 05/11/2013 16:38, Aleksej Efimov wrote:
Hi,
Can I have a review for tzdata2013h integration [1]. The webrev link
can be located here [2].
The following test sets were executed on build with fix:
test/sun/util/calendar test/java/util/Calendar
test/sun/util/resources/TimeZone
Alan,
Thank you for advise.
I have executed the same test sets with -XX:-UseMathExactIntrinsics and,
as was expected, there is only one failure:
sun/util/calendar/zi/TestZoneInfo310.java.
-Aleksej
On 11/05/2013 09:50 PM, Alan Bateman wrote:
On 05/11/2013 16:38, Aleksej Efimov wrote:
Hi,
One final set of changes was required based upon cross platform testing.
The revised webrev which passes cross platform testing on all platforms is here:
http://cr.openjdk.java.net/~mduigou/JDK-8015068/3/webrev/
The changes are:
- I had to switch to using uname -s because Solaris doesn't
Aleksej,
For better performance
(1) the currT should be static final so we dont have to access the
System.curentTimeMillis() for each TimeZone/ZoneInfo instance.
(2) instead of iterating through the standardTransitions(), shouldn't we just
check the last one? given it's a sorted list.
btw, in
On 11/05/2013 10:50 AM, Xueming Shen wrote:
Aleksej,
For better performance
(1) the currT should be static final so we dont have to access the
System.curentTimeMillis() for each TimeZone/ZoneInfo instance.
(2) instead of iterating through the standardTransitions(), shouldn't we just
check the
Changeset: a8a044db575c
Author:joehw
Date: 2013-11-05 11:18 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a8a044db575c
8027860: [TEST_BUG] File not closed in
javax/xml/jaxp/parsers/8022548/XOMParserTest.java
Reviewed-by: alanb
!
1 - 100 of 84465 matches
Mail list logo
