hg: jdk8/tl/jdk: 8012261: update policytool to support java.net.HttpURLPermission

Changeset: 0f7aaabed25f Author:weijun Date: 2013-05-18 10:15 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0f7aaabed25f 8012261: update policytool to support java.net.HttpURLPermission Reviewed-by: mullan ! src/share/classes/sun/security/tools/policytool/PolicyTool.java ! s

Re: Add getChars to CharSequence

Hi Martin, I had failed to notice that you were using 6813523 in your changeset. Since 6792262 is more specific can we switch to using that one? Mike On May 17 2013, at 16:42 , Mike Duigou wrote: > Hi Martin; > > There's a bug id we can use for this issue, an old RFE, JDK-6792262. > > I am

Re: Add getChars to CharSequence

Hi Martin; There's a bug id we can use for this issue, an old RFE, JDK-6792262. I am working on the internal CCC case Thanks, Mike On May 10 2013, at 17:15 , Martin Buchholz wrote: > > > > On Wed, May 8, 2013 at 5:30 PM, Mike Duigou wrote: > - Could use a @DataProivder for "CharSequen

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

On May 16 2013, at 20:52 , Alan Eliasen wrote: > 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

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

Sergey / David, Thanks for the observations. I am disinclined at this time to try to modify in any major way the algorithmic changes represented by the four previously identified phases of BigInteger performance improvement. These changes have been in the queue for a very long time so I think

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

On May 17, 2013, at 3:47 PM, Brian Burkhalter wrote: >> That seems like a lightweight but acceptable change to me. I have >> discussed this optimization before, and thought it might improve a small >> number of cases, but could make the base case of very small non-equal >> numbers slightly slo

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

On May 16, 2013, at 7:21 PM, Alan Eliasen wrote: >> I have reviewed this code including verifying all algorithms against >> the references suggested in the code as well as other sources in the >> literature. It all looks to be entirely correct and very clean and >> clear. > > Thanks very much

hg: jdk8/tl/langtools: 6885876: add comments to javac/util/Convert.java

Changeset: 0928f2cfbf8e Author:jjg Date: 2013-05-17 13:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0928f2cfbf8e 6885876: add comments to javac/util/Convert.java Reviewed-by: mduigou ! src/share/classes/com/sun/tools/javac/util/Convert.java

RE: RFR 8009581: Xpathexception does not honor initcause()

Aleksej, Should readObject call super.initCause instead of this.initCause? Maybe initCause should be only called if scause != null && super.getCause() == null. If super.getCause is not null initCause will always fail. Jason > Date: Fri, 17 May 2013

Re: RFR 8009581: Xpathexception does not honor initcause()

Alan, David and other team! Resending the previous RFR 8009581 v.1. It might lost among the pack posts. Best regards, Aleksej On 11.05.2013 23:43, Aleksej Efimov wrote: Hello Alan, David and other experts, I presents the second version of fix for XPathException class for your review: http://c

hg: jdk8/tl/jdk: 8011136: FileInputStream.available and skip inconsistencies

Changeset: 3b1450ee2bb9 Author:dxu Date: 2013-05-17 12:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3b1450ee2bb9 8011136: FileInputStream.available and skip inconsistencies Summary: Correct the behavior of available() and update related java specs for available() and sk

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

Thank you for the review David. Some of your suggestions had already been applied in the lambda repo but I've applied the rest and some additional cases (Predicate) that were similar. http://cr.openjdk.java.net/~mduigou/JDK-8004015/1/webrev/ Thanks! Mike On May 16 2013, at 21:36 , David Holme

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

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 intent of @Deprecated. Doesn't @Deprecated mean

hg: jdk8/tl/nashorn: 17 new changesets

Changeset: b754fb89367d Author:jlaskey Date: 2013-04-30 10:05 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/b754fb89367d 8006220: Simplify PropertyMaps Reviewed-by: hannesw, lagergren Contributed-by: james.las...@oracle.com ! src/jdk/nashorn/internal/codegen/MapCreator.

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

On 2013-05-17, at 12:13 PM, Paul Sandoz wrote: > On May 17, 2013, at 4:45 PM, David Chase wrote: > >> That is, turning the parallelism option into a static choice of method name >> is not a good way to go; it only works for programming in the small, and in >> general does not remove the need

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

On May 17, 2013, at 4:45 PM, David Chase wrote: > > On 2013-05-17, at 10:07 AM, Paul Sandoz wrote: >>> Baking it in as a static decision is just kicking the can down the road -- >>> once some module that computes CRCs as part of its larger work chooses >>> serial or parallel, what then, if t

hg: jdk8/tl/jdk: 2 new changesets

Changeset: 222da3d4692a Author:chegar Date: 2013-05-17 16:44 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/222da3d4692a 8014783: java/net/HttpURLPermission/HttpURLPermissionTest.java leaves files open Reviewed-by: michaelm ! test/java/net/HttpURLPermission/HttpURLPermission

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

On 2013-05-17, at 10:07 AM, Paul Sandoz wrote: >> Baking it in as a static decision is just kicking the can down the road -- >> once some module that computes CRCs as part of its larger work chooses >> serial or parallel, what then, if that module's client doesn't like that >> decision? >> >

Re: RFR 8014791: More ProblemList.txt updates (5/2013)

On 17/05/2013 12:22, Alan Bateman wrote: For java/net/HttpURLPermission/HttpURLPermissionTest.java then I assume that using try-with-resources around the code that opens the .ser files will sort this out (meaning might be as quick to just fix this one). For this, I propose to simply repla

hg: jdk8/tl/jdk: 2 new changesets

Changeset: 3981ad7ec458 Author:chegar Date: 2013-05-17 15:00 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3981ad7ec458 8014791: More ProblemList.txt updates (5/2013) Reviewed-by: alanb ! test/ProblemList.txt Changeset: fab0e4b682e8 Author:chegar Date: 2013-05-17

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

On 2013-05-17, at 9:55 AM, Doug Lea wrote: > A quick note while travelling... > >>> [*] In JDK 8 the Arrays.parallelSort methods use an array length >>> threshold of 2^13, arrays <= to that length will be sorted sequentially >>> and arrays > than will be sorted in parallel. IIUC the threshold w

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

On May 17, 2013, at 3:45 PM, David Chase wrote: > > On 2013-05-17, at 4:28 AM, Paul Sandoz wrote: > >> >> On May 17, 2013, at 12:09 AM, David Chase wrote: >> >>> >>> 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

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

There's been a little pushback against that use of forkjoin, though (as the author of the CRC/Adler work it seems like a reasonable idea to me). One worry I have had is that in a larger context we are worried not just about speed, but also about efficiency; using 4 threads for a 3x speedup is i

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

A quick note while travelling... >> [*] In JDK 8 the Arrays.parallelSort methods use an array length >> threshold of 2^13, arrays <= to that length will be sorted sequentially >> and arrays > than will be sorted in parallel. IIUC the threshold was >> chosen to ensure that Arrays.parallelSort is ~

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

On 2013-05-17, at 4:28 AM, Paul Sandoz wrote: > > On May 17, 2013, at 12:09 AM, David Chase wrote: > >> >> 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 co

Re: RFR 8014791: More ProblemList.txt updates (5/2013)

Thanks Alan, I'll make the changes to the formatting ( add space ), remove the addition of HttpURLPermissionTest, then push the change. -Chris. On 17/05/2013 12:22, Alan Bateman wrote: On 17/05/2013 11:54, Chris Hegarty wrote: There are a few networking tests failing recently. All have bugs

Re: RFR 8014791: More ProblemList.txt updates (5/2013)

On 17/05/2013 11:54, Chris Hegarty wrote: There are a few networking tests failing recently. All have bugs against them. These bugs will be address shortly, but since tl is integrating into master, for b91, next Tuesday, it is best to add them to the ProblemList so that the failures don't escap

RFR 8014791: More ProblemList.txt updates (5/2013)

There are a few networking tests failing recently. All have bugs against them. These bugs will be address shortly, but since tl is integrating into master, for b91, next Tuesday, it is best to add them to the ProblemList so that the failures don't escape into master. diff -r 06b410feed49 -r 1e

hg: jdk8/tl/jaxp: 8013900: More warnings compiling jaxp.

Changeset: 6443f5627744 Author:dfuchs Date: 2013-05-17 10:40 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/6443f5627744 8013900: More warnings compiling jaxp. Summary: Some internal implementation classes in Jaxp were redefining equals() without redefining hashCode(). This

hg: jdk8/tl/jdk: 8013900: More warnings compiling jaxp.

Changeset: 68209420aac2 Author:dfuchs Date: 2013-05-17 10:40 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/68209420aac2 8013900: More warnings compiling jaxp. Summary: Some internal implementation classes in Jaxp were redefining equals() without redefining hashCode(). This

Re: RFR: JDK-8011136 - FileInputStream.available and skip inconsistencies

On 15/05/2013 19:04, Dan Xu wrote: : Thanks for your review, I have updated wordings in the java doc. The new webrev can be reviewed at http://cr.openjdk.java.net/~dxu/8011136/webrev.01/ . -Dan Thanks for the updates, looks good to me.

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

On May 17, 2013, at 12:09 AM, David Chase wrote: > > 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 unders

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

Hi Brian, In the parallel thread I see a new implementation of CRC32 & Adler32. I don't mean new HW intrinsics, I mean parallel operation using ForkJoinPool. I think BigInteger operations may be a better candidate for such kind of parallelization. For example Karatsuba may be forkjoined natur

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

On Fri, 2013-05-17 at 10:47 +1000, David Holmes wrote: > 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 reproducib