Re: RFR: Rename EFS in java.util.zip internals to something meaningful

On 5/16/18, 6:28 PM, Martin Buchholz wrote: Hi Xueming, I'd like you to do a code review 8203328: Rename EFS in java.util.zip internals to something meaningful http://cr.openjdk.java.net/~martin/webrevs/jdk/zip-EFS/ https://bugs.openj

Re: RFR 8203279 : Faster calculation of power of two

On 17/05/2018 1:01 PM, Ivan Gerasimov wrote: On 5/16/18 7:44 PM, David Holmes wrote: On 17/05/2018 12:30 PM, Ivan Gerasimov wrote: Hi David! On 5/16/18 6:12 PM, David Holmes wrote: Hi Ivan, Surely you need to back this up with some performance numbers! And verify not assume that number

Re: RFR 8203279 : Faster calculation of power of two

On 17/05/2018 12:55 PM, Martin Buchholz wrote: Hello Ivan, I've wondered about this myself. Probably the performance is architecture dependent. Probably a new method should be added to Integer and Long with @HotspotIntrinsicCandidate. That gives David another chance to practice his blind aarch64

Re: RFR 8203279 : Faster calculation of power of two

On 5/16/18 7:44 PM, David Holmes wrote: On 17/05/2018 12:30 PM, Ivan Gerasimov wrote: Hi David! On 5/16/18 6:12 PM, David Holmes wrote: Hi Ivan, Surely you need to back this up with some performance numbers! And verify not assume that numberOfLeadingZeroes is intrinsified! Yes, good po

Re: RFR 8203279 : Faster calculation of power of two

Hello Ivan, I've wondered about this myself. Probably the performance is architecture dependent. Probably a new method should be added to Integer and Long with @HotspotIntrinsicCandidate. That gives David another chance to practice his blind aarch64 assembly language coding skills. It's hard to gi

Re: RFR 8203279 : Faster calculation of power of two

On 17/05/2018 12:30 PM, Ivan Gerasimov wrote: Hi David! On 5/16/18 6:12 PM, David Holmes wrote: Hi Ivan, Surely you need to back this up with some performance numbers! And verify not assume that numberOfLeadingZeroes is intrinsified! Yes, good point. Please find the benchmark with the res

Re: RFR 8203279 : Faster calculation of power of two

Hi David! On 5/16/18 6:12 PM, David Holmes wrote: Hi Ivan, Surely you need to back this up with some performance numbers! And verify not assume that numberOfLeadingZeroes is intrinsified! Yes, good point. Please find the benchmark with the results here: http://cr.openjdk.java.net/~igerasim

RFR: Small cleanups in java.lang.ref

I've been confused by NULL vs null for years. 8203327: Small cleanups in java.lang.ref http://cr.openjdk.java.net/~martin/webrevs/jdk/Reference-cleanup/ https://bugs.openjdk.java.net/browse/JDK-8203327

RFR: Rename EFS in java.util.zip internals to something meaningful

Hi Xueming, I'd like you to do a code review 8203328: Rename EFS in java.util.zip internals to something meaningful http://cr.openjdk.java.net/~martin/webrevs/jdk/zip-EFS/ https://bugs.openjdk.java.net/browse/JDK-8203328

Re: RFR 8203279 : Faster calculation of power of two

Hi Ivan, Surely you need to back this up with some performance numbers! And verify not assume that numberOfLeadingZeroes is intrinsified! Cheers, David On 17/05/2018 10:32 AM, Ivan Gerasimov wrote: Hello! In a few places we have code that rounds an integer up to the nearest power of two.

Re: 8202076: test/jdk/java/io/File/WinSpecialFiles.java on windows with VS2017

Hi Ivan, On May 16, 2018, at 2:54 PM, Ivan Gerasimov wrote: > Maybe it is better to compare fileData.cFileName with the pathbuf to make > sure we're dealing with the correct file? Certainly making this change to the previous proposal would do no harm: --- a/src/java.base/windows/native/libjav

RFR: 8177276: MethodHandles.insertArguments doesn't specify IllegalArgumentException on index mismatch

Hi All, Please review fix for https://bugs.openjdk.java.net/browse/JDK-8177276 . http://cr.openjdk.java.net/~vtheeyarath/8177276/webrev.02/ The related CSR is https://bugs.openjdk.java.net/browse/JDK-8202991 . Regards Vivek

RFR 8203279 : Faster calculation of power of two

Hello! In a few places we have code that rounds an integer up to the nearest power of two. It is done with a series of RSHOTFs and ORs, but it can possibly be done faster with the use of Integer.numberOfLeadingZeros (assuming it is intrinsified). Would you please help review this trivial o

RFR (JDK11/JAXP/java.xml) 8198548: Initialization race in com.sun.org.apache.xerces.internal.impl.xpath.regex.Token.getRange() on Token.categories

Hi, Please review a fix on synchronization. The real change is the double-checked locking, all others are s/Token.categories/tmpMap/g. All JAXP tests passed. Before the fix, the test attached to JBS failed only once for me after 10,000 runs and then a few 1000 runs (impossible to get one wit

Re: 8202076: test/jdk/java/io/File/WinSpecialFiles.java on windows with VS2017

Hi Ivan, On May 16, 2018, at 2:54 PM, Ivan Gerasimov wrote: > I wonder if FileSystem.getLength() will start to return the file size when > the file name contains wildcards? Interesting point. A simple program verifies that this is the case: import java.io.File; public class FileLength {

Re: RFR: jsr166 jdk integration 2018-05

Sorry Stuart, but I'm joining the no-modCount barrage. To pick on the main issue... On 05/16/2018 05:21 PM, Stuart Marks wrote: > Suppose that a replaceAll() on another thread occurs, and that this is > allowed. Does the application care whether the eventual printout > contains partly new values

Re: RFR: jsr166 jdk integration 2018-05

On 17/05/2018 4:25 AM, Stuart Marks wrote: On 5/15/18 7:37 PM, David Holmes wrote: I'm still with Martin on this. It makes no sense to me to allow replacing one element to not cause CME, but replacing more than one does cause CME. This is inconsistent and confusing and the end result is the pr

Re: RFR: jsr166 jdk integration 2018-05

On Wed, May 16, 2018 at 2:21 PM, Stuart Marks wrote: > > > On 5/15/18 8:02 PM, Martin Buchholz wrote: > >> >> How many times the lock is acquired is an implementation detail, a >> non-obvious tradeoff even. >> vector.replaceAll holds the lock throughout, but vector.subList(0, >> size).replaceAll

Re: 8202076: test/jdk/java/io/File/WinSpecialFiles.java on windows with VS2017

Hi Brian! I wonder if FileSystem.getLength() will start to return the file size when the file name contains wildcards? Maybe it is better to compare fileData.cFileName with the pathbuf to make sure we're dealing with the correct file? With kind regards, Ivan On 5/16/18 2:37 PM, Brian Burk

8202076: test/jdk/java/io/File/WinSpecialFiles.java on windows with VS2017

https://bugs.openjdk.java.net/browse/JDK-8202076 http://cr.openjdk.java.net/~bpb/8202076/webrev.00/ If all else fails, obtain the file length via the FindFirstFileW function [1]. Thanks, Brian [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa364418(v=vs.85).aspx

Re: Bug Request: Please remove out-of-date files from bug

Done. Though you sent this to the wrong mailing list for a hotspot bug. David On 17/05/2018 1:36 AM, Adam Farley8 wrote: Hi All, In bug JDK-8190187, hotspot_hg_diff and jdk_hg_diff are out-of-date. Please can someone delete these files? Best Regards Adam Farley OpenJDK Team Runtimes IBM

Re: RFR: jsr166 jdk integration 2018-05

On 5/15/18 8:02 PM, Martin Buchholz wrote: How many times the lock is acquired is an implementation detail, a non-obvious tradeoff even. vector.replaceAll holds the lock throughout, but vector.subList(0, size).replaceAll holds the lock for each element (sigh ... racily (really a bug!)). In

Re: RFR: jsr166 jdk integration 2018-05

On Wed, May 16, 2018 at 11:25 AM, Stuart Marks wrote: > > > On 5/15/18 7:37 PM, David Holmes wrote: > >> I'm still with Martin on this. It makes no sense to me to allow replacing >> one element to not cause CME, but replacing more than one does cause CME. >> This is inconsistent and confusing and

Re: RFR: jsr166 jdk integration 2018-05

On 5/15/18 7:37 PM, David Holmes wrote: I'm still with Martin on this. It makes no sense to me to allow replacing one element to not cause CME, but replacing more than one does cause CME. This is inconsistent and confusing and the end result is the programmer won't know what to expect when or

Re: [core-libs] RFR (L): 8010319: Implementation of JEP 181: Nest-Based Access Control

HI, Nice thorough work on this, surprisingly tricky in some areas esp. MHs. Class — 3857 * If there is any error accessing the nest host, or the nest host is 3858 * in any way invalid, then {@code this} is returned. I am curious under what conditions this can arise. As a caller this

Re: Discussion: Efficient ByteBuffer -> String that avoids additional copying

On 5/16/18, 10:03 AM, Claes Redestad wrote: Hi, I'd just like to point out there's been some recent effort on this, see: https://bugs.openjdk.java.net/browse/JDK-8021560 .. which was RFR'd here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-February/051401.html I'm not sure

Re: Discussion: Efficient ByteBuffer -> String that avoids additional copying

Hi, I'd just like to point out there's been some recent effort on this, see:  https://bugs.openjdk.java.net/browse/JDK-8021560 .. which was RFR'd here:  http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-February/051401.html I'm not sure what the current status of that is, but seems th

Re: RFR JDK-8191533,jar --describe-module prints service provider class names in lower case

On 16/05/2018 17:11, Xueming Shen wrote: : http://cr.openjdk.java.net/~sherman/8191533/webrev Rename as suggested. The empty set change suggested seems to be an "incompatible" change for the output when the set indeed is empty :-) I'm not sure if anyone has already built dependency on it sinc

Discussion: Efficient ByteBuffer -> String that avoids additional copying

Paul, Would you mind explaining more about what you're looking for regarding this? I'm curious if `ByteBuffer#getString` is what you're after, or rather something similar to `String.from(ByteBuffer)`. I'll definitely have a look at jdk.internal.misc.SharedSecrets in the meantime. Thanks! - Jac

Re: RFR JDK-8191533,jar --describe-module prints service provider class names in lower case

On 5/16/18, 12:19 AM, Alan Bateman wrote: On 16/05/2018 00:51, Xueming Shen wrote: Hi, Please help review the change for JDK-8191533 issue: https://bugs.openjdk.java.net/browse/JDK-8191533 webrev: http://cr.openjdk.java.net/~sherman/8191533/webrev/ The jmod change has been verify by applying

Bug Request: Please remove out-of-date files from bug

Hi All, In bug JDK-8190187, hotspot_hg_diff and jdk_hg_diff are out-of-date. Please can someone delete these files? Best Regards Adam Farley OpenJDK Team Runtimes IBM Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Register

RFR: JDK-8190187: C++ code calling JNI_CreateJavaVM can be killed by Java - Final Email

Hi All, The code to resolve JDK-8190187 has been added to the bug, in hg_diff.txt. Could a committer please take the fix and: 1) Complete the CSR process for the new JNI Return code. 2) Commit the changes that contain the Return code. And, optionally, 3) Perform 1 and 2 for the jdwp agent ch

Re: RFR: 8203223: Signed integer overflow in ImageStrings::hash_code (libjimage.so)

On Wed, 2018-05-16 at 12:39 +0100, Alan Bateman wrote: > On 16/05/2018 09:02, Severin Gehwolf wrote: > > : > > New webrev: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203223/webrev.02/ > > > > This version looks okay to me. > > -Alan Thanks for the review! Cheers, Severin

Re: RFR: 8203223: Signed integer overflow in ImageStrings::hash_code (libjimage.so)

On 16/05/2018 09:02, Severin Gehwolf wrote: : New webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203223/webrev.02/ This version looks okay to me. -Alan

Re: RFR: 8203223: Signed integer overflow in ImageStrings::hash_code (libjimage.so)

On 05/16/2018 09:10 AM, Aleksey Shipilev wrote: > On 05/16/2018 10:02 AM, Severin Gehwolf wrote: >> $ bash imageFile.o.cmdline >> /disk/openjdk/upstream-sources/openjdk-hs/src/java.base/share/native/libjimage/imageFile.cpp:60:33: >> error: macro "assert" passed 2 arguments, but takes just 1 >>

Re: RFR: 8203223: Signed integer overflow in ImageStrings::hash_code (libjimage.so)

On 05/16/2018 10:02 AM, Severin Gehwolf wrote: > $ bash imageFile.o.cmdline > /disk/openjdk/upstream-sources/openjdk-hs/src/java.base/share/native/libjimage/imageFile.cpp:60:33: > error: macro "assert" passed 2 arguments, but takes just 1 > assert(seed > 0, "invariant"); Oh, WTF! So it is t

Re: RFR: 8203223: Signed integer overflow in ImageStrings::hash_code (libjimage.so)

Hi David, Aleksey, Thanks for the reviews! Comments inline. On Wed, 2018-05-16 at 12:01 +1000, David Holmes wrote: > +1 on both comments. > > In addition I'd prefer > > + u4 useed = (u4)seed; > > for clarity, rather than just 's'. Fixed. > Thanks, > David > > On 16/05/2018 2:16 AM, Alek

Re: RFR JDK-8191533,jar --describe-module prints service provider class names in lower case

On 16/05/2018 00:51, Xueming Shen wrote: Hi, Please help review the change for JDK-8191533 issue: https://bugs.openjdk.java.net/browse/JDK-8191533 webrev: http://cr.openjdk.java.net/~sherman/8191533/webrev/ The jmod change has been verify by applying jmod on those modules at jdk home. This lo

RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1

Hi Matthias, yes, reviewed. Best regards Christoph From: Baesken, Matthias Sent: Mittwoch, 16. Mai 2018 09:06 To: Langer, Christoph ; 'build-...@openjdk.java.net' ; ppc-aix-port-...@openjdk.java.net; core-libs-dev@openjdk.java.net Cc: Lindenmaier, Goetz Subject: RE: RFR : 8202322: AIX: symbol

RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1

Hi Christoph can I add you as second reviewer (other reviewer was Erik Joelsson) can push the change ? Best regards, Matthias From: Langer, Christoph Sent: Donnerstag, 26. April 2018 16:38 To: Baesken, Matthias ; 'build-...@openjdk.java.net' ; ppc-aix-port-...@openjdk.java.net; core-libs-d