2013/5/16 David Holmes david.hol...@oracle.com:
+1
I think it should also blow at runtime unless people passes some fancy
argument (like -XX:recallRetired :), this way is easier for people to
fix their code, or, in case they can't, do workaround it.
Interesting suggestions but I for one
Hi,
Right, the test calls the correctly synchronized method in JDK7. The fix
for 6914123 in JDK8 moves synchronization to the other method (the one
taking CharSequence as parameter type), so in JDK8 it doesn't matter
which method is called, but in JDK7 it makes a difference. The same test
On 05/16/2013 09:44 AM, Mario Torre wrote:
2013/5/16 David Holmes david.hol...@oracle.com:
+1
I think it should also blow at runtime unless people passes some fancy
argument (like -XX:recallRetired :), this way is easier for people to
fix their code, or, in case they can't, do workaround it.
Hi,
There is another fix to avoid the use of mutable objects.
webrev: http://cr.openjdk.java.net/~xuelei/8010814/webrev.00/
Thanks,
Xuelei
On 15/05/2013 12:07, Eric Wang wrote:
Hi Alan,
Thanks for the suggestion, I have updated the fix again, Can you
please help to take a look?
http://cr.openjdk.java.net/~ewang/8004177/webrev.01/
http://cr.openjdk.java.net/%7Eewang/8004177/webrev.01/
Updated webrev looks good to me. Minor nit
On 05/16/2013 10:10 AM, Alan Bateman wrote:
On 15/05/2013 12:07, Eric Wang wrote:
Hi Alan,
Thanks for the suggestion, I have updated the fix again, Can you
please help to take a look?
http://cr.openjdk.java.net/~ewang/8004177/webrev.01/
http://cr.openjdk.java.net/%7Eewang/8004177/webrev.01/
Hi Xuelei
I'm busy on something else, so probably have no time (or cannot
concentrate) to read in details.
In my opinion, there are several cases as to whether to clone or not:
1. MUST NOT clone, because the value must be shared so that change at
one side appears on the other side.
2.
On 5/16/2013 5:22 PM, Weijun Wang wrote:
Hi Xuelei
I'm busy on something else, so probably have no time (or cannot
concentrate) to read in details.
Not urgent fix, so please review these request only when you available.
In my opinion, there are several cases as to whether to clone or not:
On 16/05/2013 7:07 PM, Alan Bateman wrote:
On 16/05/2013 05:08, David Holmes wrote:
Okay mea culpa - I was testing on the wrong JDK. I wrongly assumed
this would impact 7 as well but it doesn't as the bug was introduced
with the changes in 6914123.
Sorry about that.
Good to go. Has anyone
On 16/05/2013 6:19 PM, Chris Kirk wrote:
Dropping some of the accrued baggage would be good. Java has gone an
incredible distance without having a clear out. I for one believe that
it deserves one.
The way that @Retired is being proposed to being used makes me think
that I misunderstand the
Changeset: bb01cc14223c
Author:ewang
Date: 2013-05-16 10:59 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bb01cc14223c
8004177: test/java/lang/Thread/GenerifyStackTraces.java doesn't clean-up
Reviewed-by: alanb, dholmes, chegar
!
Just to clarify - you can't actually push it as you are not a jdk8
Committer. You will need a sponsor.
David
On 16/05/2013 1:39 AM, David Chase wrote:
Thanks, I'll bring it up to date.
On 2013-05-15, at 10:43 AM, Alan Bateman alan.bate...@oracle.com wrote:
The core-libs-dev is best for the
Bug description:
https://jbs.oracle.com/bugs/browse/JDK-7147084
http://bugs.sun.com/view_bug.do?bug_id=7147084
Here is the suggested fix:
http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-7147084/webrev.01/
Summary for v1 changes:
-- The set of handles that need to restore the
Hi all,
On Mon, 2013-05-13 at 13:55 +0200, Thomas Schatzl wrote:
Hi all,
I updated the test program and the patch in java.lang.ref.Reference
accordingly.
As for the problem of reproducibility, in my tests I had a 100%
reproduction rate with the previous version of the test.
However,
Looks fine Xuelei
best
Lance
On May 16, 2013, at 5:08 AM, Xuelei Fan wrote:
Hi,
There is another fix to avoid the use of mutable objects.
webrev: http://cr.openjdk.java.net/~xuelei/8010814/webrev.00/
Thanks,
Xuelei
Lance Andersen| Principal Member of Technical Staff |
Hi,
On Sat, 2013-05-11 at 09:45 +1000, David Holmes wrote:
On 11/05/2013 6:53 AM, Dean Long wrote:
On 5/10/2013 1:22 PM, Peter Levart wrote:
On 05/10/2013 10:08 PM, Peter Levart wrote:
On 05/10/2013 08:10 PM, Dean Long wrote:
If you really want to bullet-proof ReferenceHandler (and
On 16.05.2013 13:04, Alan Bateman wrote:
On 15/05/2013 22:19, Ivan Gerasimov wrote:
:
Of course you're right!
I should have waited for the compilation to finish before posting the
message.
Here's the updated webrev:
http://cr.openjdk.java.net/~dmeetry/8014657/webrev.1/
On 16/05/2013 11:03, David Holmes wrote:
Yes - I don't think we need @Retired as a stepping stone between
@Deprecated and gone. But to date @Deprecated's notion of some point
in the future is a future yet to materialize. :(
But that more general debate deserves it's own thread.
Yes, this
On 16/05/2013 03:46, Mandy Chung wrote:
On 5/15/2013 2:19 PM, Jim Gish wrote:
Please review http://cr.openjdk.java.net/~jgish/TestRB.7.1/
Looks fine. This fix gets the Glassfish to run on jdk8 as an interim
fix while allowing us to investigate a proper solution for jdk8.
Daniel mentioned
On May 16, 2013, at 2:00 PM, Alan Bateman alan.bate...@oracle.com wrote:
On 16/05/2013 11:03, David Holmes wrote:
Yes - I don't think we need @Retired as a stepping stone between @Deprecated
and gone. But to date @Deprecated's notion of some point in the future is
a future yet to
webrev: http://cr.openjdk.java.net/~drchase/7088419/webrev.01/
problem: Some applications spend a surprising amount of time computing CRC32s
(Not sure I'm supposed to be precise on an open mailing list). Recent Intel
architectures provide instructions that might be useful in addressing this.
Thanks.
Daniel -- could you please push
http://cr.openjdk.java.net/~jgish/TestRB.7.2/
http://cr.openjdk.java.net/%7Ejgish/TestRB.7.2/ ?
Jim
On 05/16/2013 08:13 AM, Alan Bateman wrote:
On 16/05/2013 03:46, Mandy Chung wrote:
On 5/15/2013 2:19 PM, Jim Gish wrote:
Please review
On 16/05/2013 15:50, David Chase wrote:
:
Parallel performance is a little harder to reason about on big x86 boxes (both
Intel and AMD), so I am leaving the threshold high. Dave Dice thought this
might be an artifact of cores being put into a power-saving mode and being slow
to wake (the
On May 16 2013, at 07:50 , David Chase wrote:
4) For CRC32, use the new-ish PCLMULQDQ instruction (64-bit by 64-bit
carryless multiply, yielding a 128-bit result) in the style described in
Intel's white paper on using this instruction to compute CRCs. All the
constants are different
Changeset: 74f91b7f4b66
Author:michaelm
Date: 2013-05-16 17:28 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/74f91b7f4b66
8012625: Incorrect handling of HTTP/1.1 Expect: 100-continue in
HttpURLConnection
Reviewed-by: alanb, chegar
!
Changeset: da203779cb33
Author:jgish
Date: 2013-05-16 11:19 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/da203779cb33
8013380: Removal of stack walk to find resource bundle breaks Glassfish startup
Summary: Use caller's classloader to load resource as an alternative to
Done
-- daniel
On 5/16/13 5:20 PM, Jim Gish wrote:
Thanks.
Daniel -- could you please push
http://cr.openjdk.java.net/~jgish/TestRB.7.2/
http://cr.openjdk.java.net/%7Ejgish/TestRB.7.2/ ?
Jim
On 05/16/2013 08:13 AM, Alan Bateman wrote:
On 16/05/2013 03:46, Mandy Chung wrote:
On 5/15/2013
On 2013-05-16, at 12:17 PM, Mike Duigou mike.dui...@oracle.com wrote:
I haven't looked at the details for the PCLMULQDQ instruction but a caryless
multiply could be of use to some of the crypto primitives as well (GHASH,
GMAC and probably others). Perhaps the property could be
Changeset: a8be9405bb4b
Author:khazra
Date: 2013-05-16 10:58 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a8be9405bb4b
7150552: network test hangs [macosx]
Summary: Remove usage of test/sun/net/www/httptest
Reviewed-by: chegar
! test/ProblemList.txt
!
Changeset: a13de892cefd
Author:ksrini
Date: 2013-05-15 18:26 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a13de892cefd
8001163: [pack200] should support attributes introduced by JSR-308
Reviewed-by: jrose
! src/share/classes/com/sun/java/util/jar/pack/Attribute.java
!
Changeset: 9abf5dc83823
Author:vinnie
Date: 2013-05-14 18:08 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9abf5dc83823
7194075: Various classes of sunec.jar are duplicated in rt.jar
Reviewed-by: mullan, vinnie
Contributed-by: Stephen Flores stephen.flo...@oracle.com
!
On 16/05/2013 15:50, David Chase wrote:
:
Parallel performance is a little harder to reason about on big x86 boxes (both
Intel and AMD), so I am leaving the threshold high. Dave Dice thought this
might be an artifact of cores being put into a power-saving mode and being slow
to wake (the
Changeset: 5e8959ab64af
Author:mchung
Date: 2013-05-16 15:08 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5e8959ab64af
4487672: (proxy) Proxy constructor should check for null argument
Reviewed-by: alanb, lancea
! src/share/classes/java/lang/reflect/Proxy.java
!
On 2013-05-16, at 5:27 PM, Alan Bateman alan.bate...@oracle.com wrote:
The current proposal doesn't change the API at this time but I wonder if you
have considered adding parallelUpdate methods to complement the serial
methods?
I'm not sure I understand. Right now, the update methods run
On May 16 2013, at 10:31 , David Chase wrote:
On 2013-05-16, at 12:17 PM, Mike Duigou mike.dui...@oracle.com wrote:
I haven't looked at the details for the PCLMULQDQ instruction but a caryless
multiply could be of use to some of the crypto primitives as well (GHASH,
GMAC and probably
On 2013-05-16, at 6:16 PM, Mike Duigou mike.dui...@oracle.com wrote:
Note that the instruction also works on 32-bit, and once the builds all use
sufficiently modern compilers, the same source code works for both.
Understood, but it's only going to be available on processors that support
I've cleaned up the test some with feedback from Brian Goetz:
http://cr.openjdk.java.net/~mduigou/JDK-8007398/3/webrev/
On May 16 2013, at 14:02 , Mike Duigou wrote:
On May 15 2013, at 19:09 , Joseph Darcy wrote:
Hi Mike,
Looks fine. Are you satisfied with the test coverage provided by
On 16/05/2013 8:48 PM, Thomas Schatzl wrote:
Hi,
On Sat, 2013-05-11 at 09:45 +1000, David Holmes wrote:
On 11/05/2013 6:53 AM, Dean Long wrote:
On 5/10/2013 1:22 PM, Peter Levart wrote:
On 05/10/2013 10:08 PM, Peter Levart wrote:
On 05/10/2013 08:10 PM, Dean Long wrote:
If you really
On 16/05/2013 8:44 PM, Thomas Schatzl wrote:
On Mon, 2013-05-13 at 13:55 +0200, Thomas Schatzl wrote:
I updated the test program and the patch in java.lang.ref.Reference
accordingly.
As for the problem of reproducibility, in my tests I had a 100%
reproduction rate with the previous version
Dave,
This is certainly significant work!
To get the mundane issues out of the way:
- C code uses indent of 2 in places instead of 4
There is a lot to try and digest here.
Why does the ASM not support Windows compiler?
David
On 17/05/2013 12:50 AM, David Chase wrote:
webrev:
On 2013-05-16, at 9:26 PM, David Holmes david.hol...@oracle.com wrote:
Dave,
This is certainly significant work!
To get the mundane issues out of the way:
- C code uses indent of 2 in places instead of 4
Okey-doke, I will reformat.
There is a lot to try and digest here.
Ask away,
On 17/05/2013 11:58 AM, David Chase wrote:
On 2013-05-16, at 9:26 PM, David Holmes david.hol...@oracle.com wrote:
Dave,
This is certainly significant work!
To get the mundane issues out of the way:
- C code uses indent of 2 in places instead of 4
Are you referring to the #ifdefs and
On 05/14/2013 01:54 PM, Brian Burkhalter wrote:
This is the first of an eventual four phases of performance
improvement of BigInteger for large integers.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4837946
Webrev:
http://cr.openjdk.java.net/~bpb/4837946/
This contains Alan
On 2013-05-16, at 10:15 PM, David Holmes david.hol...@oracle.com wrote:
BTW while at this code I don't understand the issue with size of long and
copying one at a time. Where are the unsigned longs? and should we be
using them if we don't even know they will be larger than unsigned ints?
On 17/05/2013 12:26 PM, David Chase wrote:
On 2013-05-16, at 10:15 PM, David Holmes david.hol...@oracle.com wrote:
BTW while at this code I don't understand the issue with size of long and copying one at a
time. Where are the unsigned longs? and should we be using them if we don't even
know
On 2013-05-16, at 11:06 PM, David Holmes david.hol...@oracle.com wrote:
On 17/05/2013 12:26 PM, David Chase wrote:
They're stored in unsigned long (that is how zlib declares them) and at
least on a Mac that is 8 bytes, not 4, so memmove/memcpy are not a good
idea. When the fast-path
On 05/15/2013 07:17 PM, Mike Duigou wrote:
Hello all;
This issue was originally part of JDK-8006627 (improve performance of
UUID parsing/formatting) but was split out because it could be split
out. I've been working incrementally on pieces of 8006627 as my time
permits.
Hi Mike,
A general comment regarding exceptional behaviour. There are a lot of
operations that involve composite operations (compose, andThen, or, and,
xor etc) and if the first operation throws an exception the second never
gets evaluated. Does this need to be spelled out somewhere or is
48 matches
Mail list logo
