Re: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll()

Thanks, looking into that. On 12/12/18 9:29 PM, Martin Buchholz wrote: When hacking on HashMap, one always needs to keep LinkedHashMap in the back of one's mind. If you use removeEldestEntry then the occupancy can never get beyond some limit. It may be weird to have elements that are part of

Re: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll()

Thanks Martin for finding this serious issue and the testcase. I understand the issue, but so far I've been unable to find effective enough solution that beats high/low head/tail bucket splitting. I'll keep looking into it and I'll propose a new patch or write some summary and results of my

Re: The meaning of the java.vendor property?

There's a configure flag for java.vendor (but not java.specification.vendor) which is a strong hint. --with-vendor-name Set vendor name. Among others, used to set the 'java.vendor' and 'java.vm.vendor' system properties. [not specified]

Re: RFR: 8215380: Backout accidental change to String::length

Hi Claes, Thank for catching this. Looks good. Note that the original changeset (JDK-8215281) went into JDK 12 before the RDP1 fork, so this fix should also go into JDK 12. That's a different repo now. It will then be auto-propagated to the JDK mainline ("JDK 13"). Since JDK-8215380 is a P3

Re: RFR: 8215380: Backout accidental change to String::length

+1 to revert to the prior version, Cheers, -Joe On 12/13/2018 3:20 PM, Claes Redestad wrote: Hi, I need to revert an accidental change to String.length Bug: https://bugs.openjdk.java.net/browse/JDK-8215380 Patch inlined below Running the accidentally pushed version in naive microbenchmarks

RFR: 8215380: Backout accidental change to String::length

Hi, I need to revert an accidental change to String.length Bug: https://bugs.openjdk.java.net/browse/JDK-8215380 Patch inlined below Running the accidentally pushed version in naive microbenchmarks showed that avoiding the shift operation can improve throughput of str.length() by a small

Re: RFR 8214761 : Bug in parallel Kahan summation implementation

Gentle ping. On 12/9/18 7:37 PM, Ivan Gerasimov wrote: Hello! DoubleSummaryStatistics takes advantage of Kahan summation algorithm to reduce the error of the total sum. Internally it maintains a field double sumCompensation, which keeps lower bits (which were rounded off) of the last

Re: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words

On 12/13/18 4:23 AM, Adam Farley8 wrote: Update: The revised webrev can be found here: http://cr.openjdk.java.net/~afarley/8215217/webrev/ I've now pushed this changeset. As a closing observation, I'll note that the original patch did find several vulgarities in OpenJDK. However, all of

The meaning of the java.vendor property?

I was wondering if it’s OK to modify the “java.vendor” system property as reported by System.getProperty() in our OpenJDK builds. Some binary OpenJDK distribution builders seem to be doing so, but others not. Is there a rule for this? The documentation does not seem exactly conclusive:

RFR 8215372: test/jdk/java/nio/file/DirectoryStream/Basic.java not correct for validating the use of a glob

Hi all, Attached is the patch for https://bugs.openjdk.java.net/browse/JDK-8215372 that addresses the test DirectoyStream/Basic.java which was not correctly validating newDirectoryStream using a glob: — $ hg diff test/jdk/java/nio/file/DirectoryStream/Basic.java diff -r 413c28945e0f

Re: Querstion about ForkJoinPool / SecurityManager interoperability

Should I prepare a webrev for this change? -Patrick Am 13.12.18 um 15:15 schrieb Doug Lea: > On 12/13/18 8:44 AM, Patrick Reinhart wrote: >> This special case could have been handled also by the >> InnocuousForkJoinWorkerThread >> could in my opinion be relaxed to accept null or the system

Re: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words

Thanks Lance, I had already volunteered to sponsor this. On 12/13/18 5:42 AM, Lance Andersen wrote: Looks fine. I can sponsor once approved if needed On Dec 13, 2018, at 7:27 AM, Aleksey Shipilev > wrote: On 12/13/18 1:23 PM, Adam Farley8 wrote: Update: The

Re: RFR JDK-8215300: additional changes to constants API

After the fact; looks good. Thanks, -Joe On 12/13/2018 7:17 AM, Brian Goetz wrote: +1 from me. Appears that it covers all the issues that were raised in the CSR and by JCK since integration. On Dec 13, 2018, at 10:14 AM, Vicente Romero wrote: Hi all, I have provided another iteration

Re: [PATCH] improve javadoc in TreeSet#add api documentation

Hello Stuart, Forgive me for delayed response. I was not well for a week, due to which lot of work got queued up in office. It took a while to sort it out. Your guidance was really helpful. And by end of this week I'll share first patch, containing document enhancements for SortedSet class.

Re: RFR JDK-8215300: additional changes to constants API

+1 from me. Appears that it covers all the issues that were raised in the CSR and by JCK since integration. > On Dec 13, 2018, at 10:14 AM, Vicente Romero > wrote: > > Hi all, > > I have provided another iteration to the webrev at [1]. This one includes > additional changes to make sure

Re: RFR JDK-8215300: additional changes to constants API

Hi all, I have provided another iteration to the webrev at [1]. This one includes additional changes to make sure that no array descriptor with more than 255 dimensions is created. Thanks, Vicente http://cr.openjdk.java.net/~vromero/8215300/webrev.01/ On 12/12/18 12:02 PM, Vicente Romero

Re: RFR 8215309 : Convert package.html files to package-info.java files

Thanks Daniel, I created a new issue JDK-8215361. On 12/13/2018 06:44 AM, Daniel Fuchs wrote: http://cr.openjdk.java.net/~rriggs/webrev-package-info-8215309/src/java.smartcardio/share/classes/javax/smartcardio/package-info.java could probably use {@link } instead of and {@code } instead

Re: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words

Hi Adam, The patch looks fine. Once the patch is committed, the zip file attached to the issue has no purpose and is just wasted space. Attaching the patch would waste less space but still be redundant. Best practice is to put the webrev's on cr.openjdk.java.net. A link from the issue to the

Re: Querstion about ForkJoinPool / SecurityManager interoperability

On 12/13/18 8:44 AM, Patrick Reinhart wrote: > > This special case could have been handled also by the > InnocuousForkJoinWorkerThread > could in my opinion be relaxed to accept null or the system classloader > to be set > using setContextClassLoader() Thanks. We should/will do this. The

Re: Querstion about ForkJoinPool / SecurityManager interoperability

Hi Dough, Thanks first of all for that quick answer... On 2018-12-13 14:23, Doug Lea wrote: On 12/13/18 7:36 AM, Patrick Reinhart wrote: Now the special case of using those special threads with no permission are only created when the ForkJoinPool is initialized with a security manager

Re: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words

Looks fine. I can sponsor once approved if needed > On Dec 13, 2018, at 7:27 AM, Aleksey Shipilev wrote: > > On 12/13/18 1:23 PM, Adam Farley8 wrote: >> Update: The revised webrev can be found here: >> http://cr.openjdk.java.net/~afarley/8215217/webrev/ >> >> It can also be found in the zip

Re: Querstion about ForkJoinPool / SecurityManager interoperability

On 12/13/18 7:36 AM, Patrick Reinhart wrote: > Now the special case of using those special threads with no permission > are only created when the ForkJoinPool is initialized with a security > manager installed at this point of time. If the security manager will be > installed later, it has not

Re: RFR: 8215281: Use String.isEmpty() where applicable in java.base

On 2018-12-13 14:06, Daniel Fuchs wrote: Looks good Claes! Thanks! I eyeballed the rest of the patch and found nothing wrong - but with a patch this size it would be easy to miss something. Yes, I've gone through it a couple of times now to be sure. Were you able to measure any

Re: RFR: 8215281: Use String.isEmpty() where applicable in java.base

Looks good Claes! I eyeballed the rest of the patch and found nothing wrong - but with a patch this size it would be easy to miss something. Were you able to measure any improvement after patching? best regards, -- daniel On 12/12/2018 17:06, Claes Redestad wrote: On 2018-12-12 17:54,

Querstion about ForkJoinPool / SecurityManager interoperability

Hi everybody, I'm not sure if this mailing list the correct one, if not please give me a note where to place that question. When trying to use the Weld SE with together with a SecurityManager and I got a exception thrown out of the ForkJoinWorkerThread: java.lang.SecurityException:

Re: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words

On 12/13/18 1:23 PM, Adam Farley8 wrote: > Update: The revised webrev can be found here: > http://cr.openjdk.java.net/~afarley/8215217/webrev/ > > It can also be found in the zip attached to the bug. Looks good to me. Thanks, -Aleksey

Re: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words

Update: The revised webrev can be found here: http://cr.openjdk.java.net/~afarley/8215217/webrev/ It can also be found in the zip attached to the bug. Best Regards Adam Farley IBM Runtimes Adam Farley8/UK/IBM wrote on 13/12/2018 11:49:12: > From: Adam Farley8/UK/IBM > To: Stuart Marks >

Re: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words

For a moment I had to check if this was 1st of April, but yikes! :) Thanks for cleaning it up. Cheers, Mario Il giorno mar 11 dic 2018 alle ore 16:33 Alan Bateman ha scritto: > > On 11/12/2018 15:03, Adam Farley8 wrote: > > Hey All, > > > > I've spotted 12 instances of swear words in OpenJDK

Re: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words

Hi Stuart, A good compromise. Well referenced. Yes, could you sponsor this change? Thanks, - Adam Stuart Marks wrote on 12/12/2018 00:38:32: ... > > > # HG changeset patch > # User afarley > # Date 1544574289 28800 > # Tue Dec 11 16:24:49 2018 -0800 > # Node ID

Re: RFR 8215309 : Convert package.html files to package-info.java files

Hi Roger, As a side note: http://cr.openjdk.java.net/~rriggs/webrev-package-info-8215309/src/java.smartcardio/share/classes/javax/smartcardio/package-info.java could probably use {@link } instead of and {@code } instead of at some places. Similarly the converted java.sql.rowset, java.sql,

Re: Proposal: Use new JDK_EXPORT decorator instead of JNIEXPORT

On 2018-12-12 13:17, David Holmes wrote: Okay I went away and did some homework ... Let me back up a bit and see if I have the evolution of this correctly. The native implementation of Java methods should be declared and defined with JNIEXPORT and JNICALL. JNIEXPORT controls the export

Re: RFR 8215309 : Convert package.html files to package-info.java files

Hi Roger, Thanks for doing this. The java.util.logging package-info looks good to me. best regards, -- daniel On 12/12/2018 19:03, Roger Riggs wrote: Please review a conversion of some package.html files to package-info.java files. This bunch targets packages:    package