Re: RFR: 8194154: JDK crashes parsing path string contains '//' on linux

On 14/02/2018 23:52, yumin qi wrote: Brian,   Updated using RuntimeException, which will not need -ea so removed. http://cr.openjdk.java.net/~minqi/8194154/webrev1/ Can you explain why resolve has been changed to call normalize

Re: RFR: JDK-8197988, mach5 T2 test javax/net/ssl/interop/ClientHelloChromeInterOp.java failed after JDK-8164278

On 2/15/18, 12:15 AM, Alan Bateman wrote: On 15/02/2018 07:49, Xueming Shen wrote: Hi, Please help review the change for JDK-819798 issue: https://bugs.openjdk.java.net/browse/JDK-8197988 webrev: http://cr.openjdk.java.net/~sherman/8197988/webrev The change for JDK-8164278 caused a decoding

Re: RFR: JDK-8197988, mach5 T2 test javax/net/ssl/interop/ClientHelloChromeInterOp.java failed after JDK-8164278

On 15/02/2018 07:49, Xueming Shen wrote: Hi, Please help review the change for  JDK-819798 issue: https://bugs.openjdk.java.net/browse/JDK-8197988 webrev: http://cr.openjdk.java.net/~sherman/8197988/webrev The change for JDK-8164278 caused a decoding regression. A Tier2 test case, 

Re: RFR: 8041626: [Event Request] Shutdown reason

Looks fine to me. Thanks, David - On 15/02/2018 11:35 PM, Robin Westberg wrote: Hi again, Here’s the (hopefully) final version: Full: http://cr.openjdk.java.net/~rwestberg/8041626/webrev.02/ Incremental:

Re: [11] RFR JDK-8198249: Remove deprecated Runtime::runFinalizersOnExit and System::runFinalizersOnExit

This also changes the handling of (undeprecated) method runFinalization and that's obviously related but could be a separate changeset. We'll need to merge with my own pending change to Finalizer.java.

Re: [11] RFR JDK-8198249: Remove deprecated Runtime::runFinalizersOnExit and System::runFinalizersOnExit

Hi Mandy, On 16/02/2018 1:20 PM, mandy chung wrote: On 2/15/18 6:11 PM, David Holmes wrote: Hi Mandy, Good to see this go. A few minor comments. First I've added comments on the CSR as some of the doc changes don't read correctly. Thanks for catching it.  What do you think about this

Re: [11] RFR JDK-8198249: Remove deprecated Runtime::runFinalizersOnExit and System::runFinalizersOnExit

Hi Mandy, Good to see this go. A few minor comments. First I've added comments on the CSR as some of the doc changes don't read correctly. src/hotspot/share/runtime/thread.cpp This comment doesn't read correctly: ! // won't be run. Note that if a shutdown hook was registered //

Re: JEP [DRAFT]: Container aware Java

On 16/02/2018 4:30 AM, kedar mhaswade wrote: This appears useful. Will Runtime.getRuntime().availableProcessors() return the processors available to the container after this integration, or will a new API be provided? I have seen thread pools being misconfigured (e.g. it returns the number of

Re: [11] RFR JDK-8198249: Remove deprecated Runtime::runFinalizersOnExit and System::runFinalizersOnExit

On 2/15/18 6:11 PM, David Holmes wrote: Hi Mandy, Good to see this go. A few minor comments. First I've added comments on the CSR as some of the doc changes don't read correctly. Thanks for catching it.  What do you think about this revision: * All registered {@link

Re: [11] RFR JDK-8198249: Remove deprecated Runtime::runFinalizersOnExit and System::runFinalizersOnExit

On 2/15/18 3:06 PM, mandy chung wrote: Runtime.runFinalizersOnExit has been deprecated since 1.2 (1998) and deprecated for removal in JDK 9.  We analyzed the maven central artifacts few years ago that show very few uses of it.  I also survey a recent version of most of the maven artifacts that

Re: [11] RFR JDK-8198249: Remove deprecated Runtime::runFinalizersOnExit and System::runFinalizersOnExit

On 2/15/18 7:29 PM, Martin Buchholz wrote: This also changes the handling of (undeprecated) method runFinalization and that's obviously related but could be a separate changeset. I agree I should separate the runFinalization change.  I leave it in this webrev for now.  I will send out

Re: RFR: 8197812: (ref) Data race in Finalizer

On Thu, Feb 15, 2018 at 3:20 PM, mandy chung wrote: > > I have posted RFR to remove runFinalizersOnExit. I think your patch > would become cleaner as you may keep the remove method or inline in > runFinalizer method as your original patch has. > > Do you want to wait

Re: RFR: 8197812: (ref) Data race in Finalizer

Thanks, Mandy, changeset pushed. We are in agreement. On Thu, Feb 15, 2018 at 7:31 PM, mandy chung wrote: > > > On 2/15/18 7:13 PM, Martin Buchholz wrote: > > > > On Thu, Feb 15, 2018 at 3:20 PM, mandy chung > wrote: > >> >> I have posted RFR to

Re: RFR: 8197812: (ref) Data race in Finalizer

On 2/15/18 7:13 PM, Martin Buchholz wrote: On Thu, Feb 15, 2018 at 3:20 PM, mandy chung > wrote: I have posted RFR to remove runFinalizersOnExit.   I think your patch would become cleaner as you may keep the remove method or

8193818 : Remove unused single_step field from java.lang.Thread

On 19/12/2017 11:06, Alan Bateman wrote: I've been going through the fields in java.lang.Thread and I'm wondering if this field can be removed:     /* Whether or not to single_step this thread. */     private boolean single_step; This field was used in the original Classic VM (pre-OpenJDK

Re: RFR(xs): 8193909: Obsolete(remove) Co-operative Memory Management (CMM)

Hi, On Wed, 2018-02-14 at 13:45 -0800, sangheon.kim wrote: > Hi all, > > Could I have some reviews for CMM removal? > This is closed CR but some public codes also need small > modifications. > This CR is for removing stuff related to an Oracle JDK > module/package. > Changes are just removing

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

On 15/02/2018 12:13 AM, Adam Farley8 wrote: >> Hi All, >> >> -- Short version -- >> >> Could a committer please take the fix for JDK-8190187 (full code included >> in the bug) and: >> >> 1) Complete the CSR process for the new JNI Return code. >> 2) Commit the changes that contain (a) the new

Re: 8193818 : Remove unused single_step field from java.lang.Thread

On 15/02/2018 9:42 PM, Alan Bateman wrote: On 19/12/2017 11:06, Alan Bateman wrote: I've been going through the fields in java.lang.Thread and I'm wondering if this field can be removed:     /* Whether or not to single_step this thread. */     private boolean single_step; This field was

Re: 8193818 : Remove unused single_step field from java.lang.Thread

+1 > On Feb 15, 2018, at 6:42 AM, Alan Bateman wrote: > > On 19/12/2017 11:06, Alan Bateman wrote: >> I've been going through the fields in java.lang.Thread and I'm wondering if >> this field can be removed: >> >> /* Whether or not to single_step this thread. */ >>

Re: RFR: 8196959: NullPointerException in discovery003.java

+1 > On Feb 14, 2018, at 1:24 AM, Srinivas Dama wrote: > > Jim, > > May I have second review for this thread in core-libs-dev group. > > Regards, > Srinivas > > - Forwarded Message - > From: sundararajan.athijegannat...@oracle.com > To:

Re: RFR: 8041626: [Event Request] Shutdown reason

Hi again, Here’s the (hopefully) final version: Full: http://cr.openjdk.java.net/~rwestberg/8041626/webrev.02/ Incremental: http://cr.openjdk.java.net/~rwestberg/8041626/webrev.01-02/

8193819: Error message when module does not have a ModuleMainClass attribute is confusing

There's a typo in the launcher resource used for the error message when `java -m` fails because the module doesn't have a main class. The name of the attribute is "ModuleMainClass", not "MainClass". Trivial change. -Alan diff --git

Re: 8193819: Error message when module does not have a ModuleMainClass attribute is confusing

+1 -Sundar On 15/02/18, 7:30 PM, Alan Bateman wrote: There's a typo in the launcher resource used for the error message when `java -m` fails because the module doesn't have a main class. The name of the attribute is "ModuleMainClass", not "MainClass". Trivial change. -Alan diff --git

Re: RFR(xs): 8193909: Obsolete(remove) Co-operative Memory Management (CMM)

Hi Thomas, On 02/15/2018 03:32 AM, Thomas Schatzl wrote: Hi, On Wed, 2018-02-14 at 13:45 -0800, sangheon.kim wrote: Hi all, Could I have some reviews for CMM removal? This is closed CR but some public codes also need small modifications. This CR is for removing stuff related to an Oracle JDK

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

On 14/02/2018 14:13, Adam Farley8 wrote: >> Hi All, >> >> -- Short version -- >> >> Could a committer please take the fix for JDK-8190187 (full code included >> in the bug) and: >> >> 1) Complete the CSR process for the new JNI Return code. >> 2) Commit the changes that contain (a) the new return

RFR: 8197594 - String and character repeat

This is a pre-CSR code review [1] for String repeat methods (Enhancement). The proposal is to introduce four new methods; 1. public String repeat(final int count) 2. public static String repeat(final char ch, final int count) 3. public static String repeat(final int codepoint, final int count)

Re: RFR: 8197594 - String and character repeat

I suggest merging 1 and 4 by making it an instance method on CS with a default in CS and an override on string and string builder? Sent from my MacBook Wheel > On Feb 15, 2018, at 9:20 AM, Jim Laskey wrote: > > This is a pre-CSR code review [1] for String repeat

RFR: 8193660 Check SOURCE line in "release" file for closedjdk

I need to revise the resource file test created for JDK-8192837 The new bug is https://bugs.openjdk.java.net/browse/JDK-8193660 The webrev is located at http://cr.openjdk.java.net/~shurailine/8193660/webrev.00/ Any

Re: RFR: 8197812: (ref) Data race in Finalizer

On Wed, Feb 14, 2018 at 11:47 PM, Peter Levart wrote: > > Although not strictly necessary for correctness, for the time being, it > would be nice to be consistent in marking the Finalizer object "already > finalized" in both places. Either set both next and prev to this

Re: RFR: 8197594 - String and character repeat

Very reasonable approach. > On Feb 15, 2018, at 1:31 PM, Brian Goetz wrote: > > I suggest merging 1 and 4 by making it an instance method on CS with a > default in CS and an override on string and string builder? > > Sent from my MacBook Wheel > >> On Feb 15, 2018,

Re: RFR: 8041626: [Event Request] Shutdown reason

Hi Robin, Looks fine to me. (How is this tested?, Normal, exceptional, etc.) Thanks, Roger On 2/15/2018 8:35 AM, Robin Westberg wrote: Hi again, Here’s the (hopefully) final version: Full: http://cr.openjdk.java.net/~rwestberg/8041626/webrev.02/

JEP [DRAFT]: Container aware Java

I’d like to re-propose the following JEP that will enhance the Java runtime to be more container aware. This will add an Internal Java API that will provide container specific statistics. Some of the initial goals of the previous JEP proposal has been integrated into JDK 10 under an RFE

Re: RFR: 8194154: JDK crashes parsing path string contains '//' on linux

Alan, The real reason is if we do not change on resolve, the string passed into native canonicalize will be like "//./a/" which is not expected in native part. In native part, we resume that no more "//" in the path string (already normalized in java). We can fix this by either: 1) in

Re: RFR: 8197594 - String and character repeat

- Mail original - > De: "Ivan Gerasimov" > À: "Jim Laskey" , "core-libs-dev" > > Envoyé: Jeudi 15 Février 2018 20:36:44 > Objet: Re: RFR: 8197594 - String and character repeat > Hello! > > The link

Re: RFR: 8197594 - String and character repeat

Thank you Remi. Re final: Attila got into my head. > On Feb 15, 2018, at 4:24 PM, Remi Forax wrote: > > - Mail original - >> De: "Ivan Gerasimov" >> À: "Jim Laskey" , "core-libs-dev" >>

Re: RFR: 8197594 - String and character repeat

- Mail original - > De: "Jim Laskey" > À: "Remi Forax" > Cc: "Brian Goetz" , "core-libs-dev" > > Envoyé: Jeudi 15 Février 2018 21:16:48 > Objet: Re: RFR: 8197594 - String and character

Re: RFR: 8197594 - String and character repeat

I don't think there's a case for demand to merit having a repeat(CharSequence, int) at all. I did an analysis of usages of Guava's Strings.repeat on Google's codebase. Users might be rolling their own implementations, too, but this should be a very good proxy for demand.

Re: RFR: 8197594 - String and character repeat

Good to have the data. Thank you Louis. Sent from my iPhone > On Feb 15, 2018, at 4:52 PM, Louis Wasserman wrote: > > I don't think there's a case for demand to merit having a > repeat(CharSequence, int) at all. > > I did an analysis of usages of Guava's

Re: RFR: 8197594 - String and character repeat

This matches my intuition too. Sent from my MacBook Wheel > On Feb 15, 2018, at 12:52 PM, Louis Wasserman wrote: > > I don't think there's a case for demand to merit having a > repeat(CharSequence, int) at all. > > I did an analysis of usages of Guava's Strings.repeat

Re: RFR: 8197594 - String and character repeat

Hello! The link with the webrev returned 404, but I could find it at this location: http://cr.openjdk.java.net/~jlaskey/8197594/webrev-00/ A few minor comments: 1) This check: 2992 final long limit = (long)count * 2L; 2993 if ((long)Integer.MAX_VALUE < limit) { can

Re: RFR: 8197594 - String and character repeat

I'm not sure we need 4, it's just a convenient method that may be slower than if the user code calls toString() (because of profile pollution), so i'm not sure i pull it's own weight. And about adding a default method into CharSequence, the default method should return a CharSequence or String

Re: RFR: 8194154: JDK crashes parsing path string contains '//' on linux

Hi, Alan The real reason, for why File.getCanonicalPath() will fail after "user.dir" property changed is, in File.java: public String getCanonicalPath() throws IOException { if (isInvalid()) { throw new IOException("Invalid file path"); } return

Re: RFR: 8197594 - String and character repeat

Hi Jim, Its cleaner to do the API (CSR) review before and without the implementation. It helps keep the issues separate. Don't make statements about count == Integer.MAX_VALUE / 2. There is no point, unless it should throw IAE. On 2/15/2018 3:16 PM, Jim Laskey wrote: On Feb 15, 2018, at

Re: RFR: 8197594 - String and character repeat

> On Feb 15, 2018, at 3:36 PM, Ivan Gerasimov wrote: > > Hello! > > The link with the webrev returned 404, but I could find it at this location: > http://cr.openjdk.java.net/~jlaskey/8197594/webrev-00/ > > A few minor comments: > > 1) > > This check: > > 2992

Re: RFR: 8194154: JDK crashes parsing path string contains '//' on linux

On 15/02/2018 18:41, yumin qi wrote: There are two problems here, so become complex. 1) crash on parsing "//", which included in file path, on linux. This is fixed in UnixFileSystem.java in resolve function. 2) user.dir should be read only. This is fixed in both UnixFileSystem.java and

Re: RFR: 8197594 - String and character repeat

> On Feb 15, 2018, at 4:04 PM, Remi Forax wrote: > > I'm not sure we need 4, it's just a convenient method that may be slower than > if the user code calls toString() (because of profile pollution), > so i'm not sure i pull it's own weight. > > And about adding a default

Re: RFR: 8197594 - String and character repeat

Thank you Roger. > On Feb 15, 2018, at 4:38 PM, Roger Riggs wrote: > > Hi Jim, > > Its cleaner to do the API (CSR) review before and without the implementation. > It helps keep the issues separate. This was on advice from a member of the core libs team. He can speak up

Re: JEP [DRAFT]: Container aware Java

Sounds cool! Is this JEP only about providing the corresponding API or also about using it internally (within HotSpot and class library) to better adopt to environment the JVM is running in? Either way, looking forward to see (and test) the first implementation bits! Regards, Volker On Thu,

Re: RFR: 8194154: JDK crashes parsing path string contains '//' on linux

On 15/02/2018 17:25, yumin qi wrote: Alan,   The real reason is if we do not change on resolve, the string passed into native canonicalize will be like "//./a/" which is not expected in native part. In native part, we resume that no more "//" in the path string (already normalized in java).

Re: JEP [DRAFT]: Container aware Java

This appears useful. Will Runtime.getRuntime().availableProcessors() return the processors available to the container after this integration, or will a new API be provided? I have seen thread pools being misconfigured (e.g. it returns the number of processors available on the host which is far

Re: JEP [DRAFT]: Container aware Java

> On Feb 15, 2018, at 1:30 PM, kedar mhaswade wrote: > > This appears useful. > > Will Runtime.getRuntime().availableProcessors() return the processors > available to the container after this integration, or will a new API be > provided? I have seen thread pools

Re: RFR: 8194154: JDK crashes parsing path string contains '//' on linux

There are two problems here, so become complex. 1) crash on parsing "//", which included in file path, on linux. This is fixed in UnixFileSystem.java in resolve function. 2) user.dir should be read only. This is fixed in both UnixFileSystem.java and WinNTFileSystem.java. The test case covers two

Re: JEP [DRAFT]: Container aware Java

> On Feb 15, 2018, at 12:52 PM, Volker Simonis wrote: > > Sounds cool! > > Is this JEP only about providing the corresponding API or also about > using it internally (within HotSpot and class library) to better adopt > to environment the JVM is running in? Thanks

Re: RFR: 8194154: JDK crashes parsing path string contains '//' on linux

OK, let's work on a suitable test case. Thanks Yumin On Thu, Feb 15, 2018 at 9:41 AM, Alan Bateman wrote: > On 15/02/2018 17:25, yumin qi wrote: > >> Alan, >> >> The real reason is if we do not change on resolve, the string passed >> into native canonicalize will be

Re: RFR: 8041626: [Event Request] Shutdown reason

Hi Robin, Do you want a shutdown event for every call to Runtime::exit regardless where it is in the shutdown sequence?  or do you expect to get an event of the first thread calling JVM_Halt?  or the first thread starting the shutdown sequence but it may not be the thread halting? Mandy On

Re: RFR: JDK-8021560,(str) String constructors that take ByteBuffer

public String(ByteBuffer bytes, Charset cs); public String(ByteBuffer bytes, String csname); I think these constructors make good sense. They avoid an extra copy to an intermediate byte[]. One issue (also mentioned by Stephen Colebourne) is whether we need the csname overload. Arguably it's

Re: RFR: 8197594 - String and character repeat

On 2/15/2018 12:38 PM, Roger Riggs wrote: Hi Jim, Its cleaner to do the API (CSR) review before and without the implementation. It helps keep the issues separate. Don't make statements about count == Integer.MAX_VALUE / 2. There is no point, unless it should throw IAE. My general

[11] RFR JDK-8198249: Remove deprecated Runtime::runFinalizersOnExit and System::runFinalizersOnExit

Runtime.runFinalizersOnExit has been deprecated since 1.2 (1998) and deprecated for removal in JDK 9. We analyzed the maven central artifacts few years ago that show very few uses of it. I also survey a recent version of most of the maven artifacts that references runFinalizatsOnExit no longer

Re: RFR 8196298 Add null Reader and Writer

Hi everyone responded so far. How should we proceed now? -Patrick Am 07.02.2018 um 18:38 schrieb Patrick Reinhart: >> Am 07.02.2018 um 14:03 schrieb Alan Bateman : >> >> On 03/02/2018 17:05, Patrick Reinhart wrote: >>> : >>> I reworked the tests and Writer

Re: RFR: 8197812: (ref) Data race in Finalizer

Hi Martin, On 2/14/18 9:47 PM, Martin Buchholz wrote: Embarrassed by my failure to take runFinalizersOnExit into account, I tried to redo the patch to be actually correct. http://cr.openjdk.java.net/~martin/webrevs/jdk/Finalizer-data-race/

Re: RFR: JDK-8021560,(str) String constructors that take ByteBuffer

On 2/15/18, 1:55 PM, Stuart Marks wrote: On 2/13/18, 12:41 AM, Alan Bateman wrote: These four methods encode as many characters as possible into the destination byte[] or buffer but don't give any indication that the destination didn't have enough space to encode the entire string. I thus

Re: [11] RFR JDK-8198249: Remove deprecated Runtime::runFinalizersOnExit and System::runFinalizersOnExit

On 2/15/18 4:18 PM, Stuart Marks wrote: On 2/15/18 3:06 PM, mandy chung wrote: Runtime.runFinalizersOnExit has been deprecated since 1.2 (1998) and deprecated for removal in JDK 9.  We analyzed the maven central artifacts few years ago that show very few uses of it.  I also survey a recent