Re: 4646474 : BigInteger.pow() algorithm slow in 1.4.0

On 05/14/2013 07:11 PM, Brian Burkhalter wrote: > The test in this issue report > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4646474 > > is pretty much useless for comparative purposes after applying > 4837946 as the computed value is just a power of two which will be > handled very qui

Re: RFR : 8004015 : (S) Additional Functional Interface instance and static methods

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 this

Re: RFR : 8007398 : (S) Performance improvements for Int/Long toString() at Radix 2, 8, 16

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. > > http://cr.

Re: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32

On 2013-05-16, at 11:06 PM, David Holmes 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 algorithm is ena

Re: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32

On 17/05/2013 12:26 PM, David Chase wrote: On 2013-05-16, at 10:15 PM, David Holmes 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

Re: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32

On 2013-05-16, at 10:15 PM, David Holmes 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? The values are wel

Re: RFR: 4837946 - Faster multiplication and exponentiation of large integers

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

Re: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32

On 17/05/2013 11:58 AM, David Chase wrote: On 2013-05-16, at 9:26 PM, David Holmes 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 #defines? I just want to be s

Re: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32

On 2013-05-16, at 9:26 PM, David Holmes 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 #defines? I just want to be sure, because that's what I see at 2

Re: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32

On 2013-05-16, at 9:26 PM, David Holmes 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, I'll do my best. I

Re: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32

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: http://cr.openj

Re: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread

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 o

Re: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread

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 want

Re: RFR : 8007398 : (S) Performance improvements for Int/Long toString() at radix 2, 8, 16

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 pro

Re: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32

On 2013-05-16, at 6:16 PM, Mike Duigou 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 > also support EMT

Re: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32

On May 16 2013, at 10:31 , David Chase wrote: > > On 2013-05-16, at 12:17 PM, Mike Duigou 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 t

Re: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32

On 2013-05-16, at 5:27 PM, Alan Bateman 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 in parallel for suffi

hg: jdk8/tl/jdk: 4487672: (proxy) Proxy constructor should check for null argument

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 ! test/java/

Re: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32

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 par

Re: RFR : 8007398 : (S) Performance improvements for Int/Long toString() at Radix 2, 8, 16

On May 15 2013, at 19:09 , Joseph Darcy wrote: > Hi Mike, > > Looks fine. Are you satisfied with the test coverage provided by the existing > regression tests? I hadn't actually looked but it turns out the answer was "No, certainly not". I built a set of tests across all of the primitive inte

hg: jdk8/tl/jdk: 6 new changesets

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 ! make/sun/security/ec/Makefile

hg: jdk8/tl/jdk: 8001163: [pack200] should support attributes introduced by JSR-308

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 ! src/

hg: jdk8/tl/jdk: 7150552: network test hangs [macosx]

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 ! test/java/net/CookieH

Re: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32

On 2013-05-16, at 12:17 PM, Mike Duigou 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 > "sun.hotspot.x64.clmulSupported

Re: RFR: 8013380 - Removal of stack walk to find resource bundle breaks Glassfish startup

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/ ? Jim On 05/16/2013 08:13 AM, Alan Bateman wrote: On 16/05/2013 03:46, Mandy Chung wrote: On 5/15/2013

hg: jdk8/tl/jdk: 2 new changesets

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 thre

hg: jdk8/tl/jdk: 8014676: Java debugger may fail to run

Changeset: 81c449fd18fe Author:dmeetry Date: 2013-05-16 19:28 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/81c449fd18fe 8014676: Java debugger may fail to run Summary: The problem is observed when the binaries for windows are placed under a path which contains a space Revi

hg: jdk8/tl/jdk: 2 new changesets

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 ! src/share/classes/sun/net/www/protoc

Re: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32

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 be

Re: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32

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 par

Re: RFR: 8013380 - Removal of stack walk to find resource bundle breaks Glassfish startup

Thanks. Daniel -- could you please push http://cr.openjdk.java.net/~jgish/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 http://cr.o

RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32

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. See

Re: Time to put a stop to Thread.stop?

On May 16, 2013, at 2:00 PM, Alan Bateman 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 materialize. :( >>

Re: RFR: 8013380 - Removal of stack walk to find resource bundle breaks Glassfish startup

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 t

Re: Time to put a stop to Thread.stop?

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

Re: RFR [8014657] CheckedInputStream.skip allocates temporary buffer on every call

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/

Re: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread

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 Re

Re: Code review request, JDK-8010814, More buffers are stored or returned without cloning

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 | +1.781.

Re: RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread

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. > > H

Review request: JDK-7147084 (process) appA hangs when read output stream of appB which starts appC that runs forever (v.1)

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 inheri

Re: What's the correct repository on which to base changes to "jdk"?

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 wrote: The core-libs-dev is best for the java.util.zip code. You

hg: jdk8/tl/jdk: 8004177: test/java/lang/Thread/GenerifyStackTraces.java doesn't clean-up

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 ! test/java/lang/Thread/GenerifyStackTraces.ja

Re: Time to put a stop to Thread.stop?

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 int

Re: bug 8014477 Race in String.contentEquals

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 offe

Re: Code review request, JDK-8010814, More buffers are stored or returned without cloning

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

Re: Code review request, JDK-8010814, More buffers are stored or returned without cloning

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. MUST

Re: [PATCH] Review request: 8004177: test/java/lang/Thread/GenerifyStackTraces.java doesn't clean-up

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/

Re: [PATCH] Review request: 8004177: test/java/lang/Thread/GenerifyStackTraces.java doesn't clean-up

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/ Updated webrev looks good to me. Minor ni

Code review request, JDK-8010814, More buffers are stored or returned without cloning

Hi, There is another fix to avoid the use of mutable objects. webrev: http://cr.openjdk.java.net/~xuelei/8010814/webrev.00/ Thanks, Xuelei

Re: bug 8014477 Race in String.contentEquals

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 offered to sponsor this yet? It looks good to

Re: RFR [8014657] CheckedInputStream.skip allocates temporary buffer on every call

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/ The up

Re: Time to put a stop to Thread.stop?

On 05/16/2013 09:44 AM, Mario Torre wrote: 2013/5/16 David Holmes : +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 suggestion

Re: bug 8014477 Race in String.contentEquals

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 cou

Re: Time to put a stop to Thread.stop?

2013/5/16 David Holmes : >> +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 do not think