Re: Ping!! Re: RFR: 8203357 Container Metrics

[Replying to all mailing-lists] Hi Misha, The ERROR_MARGIN in tests was introduced to make the tests stable. There are times where metric values (specifically CPU usage) can change drastically in between two reads. The metrics value got from the API and the cgroup file can be different and

RFR JDK-8204229: Formatter and String.format ignore the width with the percent modifier (%5%)

Hi, Please help review the change for JDK-8204229. It appears to be a overlook in the implementation. We do have a method print(String, Locale) that adjust the "padding spaces" issue: https://bugs.openjdk.java.net/browse/JDK-8204229 webrev: http://cr.openjdk.java.net/~sherman/8204229/webrev

Re: (trivial) RFR: 8204589: ProblemList failing launcher tests

Thanks Joe! Pushed. Should be in CI 753. David On 8/06/2018 12:22 PM, Joseph D. Darcy wrote: +1 -Joe On 6/7/2018 7:20 PM, David Holmes wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8204589 webrev: http://cr.openjdk.java.net/~dholmes/8204589/webrev/ After the push for:  JDK-8201274

Re: (trivial) RFR: 8204589: ProblemList failing launcher tests

+1 -Joe On 6/7/2018 7:20 PM, David Holmes wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8204589 webrev: http://cr.openjdk.java.net/~dholmes/8204589/webrev/ After the push for: JDK-8201274 Launch Single-File Source-Code Programs there are a few test failures in our CI testing, so

(trivial) RFR: 8204589: ProblemList failing launcher tests

Bug: https://bugs.openjdk.java.net/browse/JDK-8204589 webrev: http://cr.openjdk.java.net/~dholmes/8204589/webrev/ After the push for: JDK-8201274 Launch Single-File Source-Code Programs there are a few test failures in our CI testing, so they are being ProblemListed to keep tiers 1 and 2

Re: RFC: Experiment in accessing/managing persistent memory from Java

Hi Andrew, Jonathan, Sandhya gave an overview to a few of us Oracle folks. I agree with what Sandhya says regarding the API, a small surface, and on pursuing an unsafe intrinsic. I like it and would encourage the writing of a draft JEP, especially to give this visibility. I expect this will

Re: (XS) Review Request JDK-8204584: jdeps generates illegal dot file containing ranksep=0,600000

Looks OK to me. -- Jon On 06/07/2018 04:06 PM, mandy chung wrote: The dot files are generated and used as module graph in the docs build. The format of double should use no localization; otherwise an illegal ranksep attribute. Mandy diff --git

(XS) Review Request JDK-8204584: jdeps generates illegal dot file containing ranksep=0,600000

The dot files are generated and used as module graph in the docs build. The format of double should use no localization; otherwise an illegal ranksep attribute. Mandy diff --git a/src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleDotGraph.java

Re: Locale languageTag anomaly

Naoto, Thanks, and I guess I didn't think to check out the special case rules. Sorry about that. -- Jon On 06/07/2018 02:42 PM, Naoto Sato wrote: Hi Jon, JDK historically represents Norwegian Nynorsk language with no_NO_NY (JDK unique "NY" variant), because it predates the ISO 639-1:2002

Re: [JDK 11] RFR 8201528: Add new test to check for package versioning information in OpenJDK

Hi Chris, On 6/7/18 1:32 AM, Chris Yin wrote: Please review below new added test to check for package versioning information which customized in jar(s) manifest, many thanks bug: https://bugs.openjdk.java.net/browse/JDK-8201528 webrev: http://cr.openjdk.java.net/~xyin/8201528/webrev.00/

Re: Locale languageTag anomaly

Hi Jon, JDK historically represents Norwegian Nynorsk language with no_NO_NY (JDK unique "NY" variant), because it predates the ISO 639-1:2002 standard which introduced "nn" as the language code for Nynorsk. This legacy JDK locale is converted to BCP47 compliant language tag using "nn"

Re: Ping!! Re: RFR: 8203357 Container Metrics

Hi Bob, I looked at the tests. In general they look good. I am a bit concerned about the use of ERROR_MARGIN in one of the tests. We need to make sure that the tests are stable, and do not produce intermittent failures. Thank you, Misha On 6/7/18, 10:43 AM, Bob Vandette wrote: Can I

Re: RFR (XL): JDK-8204572 SetupJdkLibrary should setup SRC and -I flags automatically

Hello Magnus, Very nice refactoring! JdkNativeCompilation.gmk line 126-127 looks a bit long. There is an extra space on 126. Also, why not addprefix for adding -I instead of clunky foreach? Not that I care greatly, but I usually prefer that construct. Otherwise looks good. /Erik On

Locale languageTag anomaly

Regarding Locale.toLanguageTag, Locale.forLanguageTag Should I be surprised (i.e. is it a bug) that out of 736 installed locales in a standard build of JDK, exactly 1 locale fails the following round-trip test: locale.equals(Locale.forLanguageTag(locale.toLanguageTag())) The locale

Re: RFR 8204565 : (spec) Document java.{vm.}?specification.version system properties' relation to $FEATURE

Hi Brent, On 6/7/18 12:13 PM, Brent Christian wrote: Hi, Please review this doc-only change.  From the bug report: 'With the integration of JEP 322 "Time-Based Release Versioning" into JDK 10, VERSION_FEATURE is used to set the value of the system properties "java.specification.version" [1]

RFR (XL): JDK-8204572 SetupJdkLibrary should setup SRC and -I flags automatically

This change needs some background information. I've been working on simplifying and streamlining the compilation of native libraries of the JDK. Previously, I introduced the SetupJdkLibrary function, and started to get a better control of compiler flags. This patch continues on both paths.

RFR 8204565 : (spec) Document java.{vm.}?specification.version system properties' relation to $FEATURE

Hi, Please review this doc-only change. From the bug report: 'With the integration of JEP 322 "Time-Based Release Versioning" into JDK 10, VERSION_FEATURE is used to set the value of the system properties "java.specification.version" [1] and "java.vm.specification.version" [2] (though the

Ping!! Re: RFR: 8203357 Container Metrics

Can I get one more reviewer for this RFE so I can integrate it? > http://cr.openjdk.java.net/~bobv/8203357/webrev.01 Mandy Chung has reviewed this change. I’ve run Mach5 hotspot and core lib tests. I’ve reviewed the tests which were written by Harsha Wardhana I filed a CSR for the command

RE: RFR : 8204541 Correctly support AIX xlC 13.1 symbol visibility flags

Hello Christoph According to build log, if <#include "osSupport.hpp"> was there: "/home/jdktest/sandbox/jdk/build/aix-ppc64-normal-server-release/support/headers/java.base/jdk_internal_jimage_NativeImageBuffer.h", line 15.27: 1540-0040 (S) The text

Re: RFR: 8196990 :Resolve disabled warnings for libjli

+1 > On Jun 7, 2018, at 12:14 PM, Srinivas Dama wrote: > > Ok. Thank you Jim. > Please find revised webrev at > http://cr.openjdk.java.net/~sdama/8196990/webrev.01/. > > Regards, > Srinivas > > - Original Message - > From: james.las...@oracle.com > To: srinivas.d...@oracle.com,

Re: RFR: 8196990 :Resolve disabled warnings for libjli

Ok. Thank you Jim. Please find revised webrev at http://cr.openjdk.java.net/~sdama/8196990/webrev.01/. Regards, Srinivas - Original Message - From: james.las...@oracle.com To: srinivas.d...@oracle.com, core-libs-dev@openjdk.java.net Sent: Thursday, 7 June, 2018 7:37:48 PM GMT +05:30

Re: RFR: 8196990 :Resolve disabled warnings for libjli

traditionally there is a space after // simplify comment to something like (rest is redundant) // initialize to avoid -Werror=maybe-uninitialized issues from gcc 7.3 onwards. > On Jun 7, 2018, at 11:01 AM, Srinivas Dama wrote: > > Hi, > > Please review

Re: RFR: JDK-8202788: Explicitly reclaim cached thread-local direct buffers at thread exit

Peter, Inline. — Tony Printezis | @TonyPrintezis | tprinte...@twitter.com On June 7, 2018 at 5:21:43 AM, Peter Levart (peter.lev...@gmail.com) wrote: Hi Tony, Thanks for taking a look. Just a couple of comments inline... On 06/06/18 22:38, Tony Printezis wrote: - instead of

RFR: 8196990 :Resolve disabled warnings for libjli

Hi, Please review http://cr.openjdk.java.net/~sdama/8196990/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8196990 Regards, Srinivas

RE: RFR : 8204541 Correctly support AIX xlC 13.1 symbol visibility flags

Hi Ichiroh, what's the exact error message if you #include "osSupport.hpp"? (I have no xlC 13 at hand to try myself...) Best regards Christoph > -Original Message- > From: Ichiroh Takiguchi [mailto:taki...@linux.vnet.ibm.com] > Sent: Donnerstag, 7. Juni 2018 14:53 > To:

RFR : 8204541 Correctly support AIX xlC 13.1 symbol visibility flags

Hello. Could you review it ? Bug:https://bugs.openjdk.java.net/browse/JDK-8204541 Change: http://cr.openjdk.java.net/~clanger/webrevs/8204541.0/ Thanks, Ichiroh Takiguchi IBM Japan, Ltd. Original Message Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support

Re: [RFR] 8204539: improve error messages in matchJavaTZ [windows]

On 07/06/2018 13:03, Baesken, Matthias wrote: Hi Christoph you are correct I compiled it on the wrong platforms , stupid mistake ! Will send an updated web rev . * Also, mapFileName can't be used at this place, because it has already been free'ed there. Yes, makes sense. Will move

RE: [RFR] 8204539: improve error messages in matchJavaTZ [windows]

Hi Christoph you are correct I compiled it on the wrong platforms , stupid mistake ! Will send an updated web rev . * Also, mapFileName can't be used at this place, because it has already been free'ed there. Yes, makes sense. Will move the free-calls . Best regards, Matthias From:

RE: [RFR] 8204539: improve error messages in matchJavaTZ [windows]

Hi Matthias, in line 527, where the actual output is done, I think you would need to replace variable 'message' with 'outputMessage', otherwise I guess it won't compile?? Also, mapFileName can't be used at this place, because it has already been free'ed there. But in general the additions

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

Hi Ichiroh, your proposal seems to make sense. I have created a bug for this: https://bugs.openjdk.java.net/browse/JDK-8204541 Can you please generate a webrev (referencing this bug, -c option of webrev.ksh) and mail it over to me. Then I'll upload it and you can post an official RFR mail.

[RFR] 8204539: improve error messages in matchJavaTZ [windows]

Hi, could you please review this small change that improves the error messages in matchJavaTZ . A reason of the failure is added to the message , and also the offset where the error happened . Bug : https://bugs.openjdk.java.net/browse/JDK-8204539 Webrev :

RE: RFR: JDK8U Backport of 8186171: HashMap: Entry.setValue may not work after Iterator.remove() called for previous entries

Hi Martin, Thanks for input. I have added the missing trailing newline to the test. Please find below updated webrev details:- Webrev: http://cr.openjdk.java.net/~rpatil/8186171/webrev.01/ Regards, Deepak From: Martin Buchholz Sent: Wednesday, June 6, 2018 11:33 PM To: Deepak Kejriwal Cc:

Re: RFR: JDK-8202788: Explicitly reclaim cached thread-local direct buffers at thread exit

Hi Tony, Thanks for taking a look. Just a couple of comments inline... On 06/06/18 22:38, Tony Printezis wrote: - instead of overriding initialValue(), ThreadLocal.setInitialValue() calls TerminatingThreadLocal.register() at the right moment Thanks. I much prefer not having to introduce

[JDK 11] RFR 8201528: Add new test to check for package versioning information in OpenJDK

Please review below new added test to check for package versioning information which customized in jar(s) manifest, many thanks bug: https://bugs.openjdk.java.net/browse/JDK-8201528 webrev: http://cr.openjdk.java.net/~xyin/8201528/webrev.00/

Re: RFR 8204310 : Simpler RandomAccessFile.setLength() on Windows

Hi Alan! On 6/6/18 6:57 AM, Alan Bateman wrote: I think this should be okay but the Windows implementation has a long history of biting the fingers of anyone that dares touch it. Sometimes unexpected behavior changes only come to light long after the change. The recent mails here about Kafka