Re: RFC: Make test failed because of the locale LANG

Hi, First of all, I want to say sorry . Because of the problems with my mail client, this typography looks bad.I found the typography so bad on the webpage today. T_T These suggestions I just want to show some ideas. We can't make changes in each test case, because it is too much, and the chang

Re: RFR: 8221477: Inject os/cpu-specific constants into Unsafe from JVM

Hi Andrew, This seems fine in general but I have a few queries on some details: src/hotspot/share/classfile/javaClasses.hpp f(java_lang_Thread) \ + f(jdk_internal_misc_UnsafeConstants) \ f(java_lang_ThreadGroup) \ Is there a reason this needs to be shoved in there? Similarly with sr

Re: RFC: Make test failed because of the locale LANG

On 3/28/19 4:54 PM, David Holmes wrote: On 29/03/2019 1:59 am, Naoto Sato wrote: Hi, I don't think there is any *official* rule for the regression tests to succeed in any locale, but if the test case is locale sensitive such as in this case, I'd suggest it should correctly specify the locale

Re: RFC: Make test failed because of the locale LANG

On 29/03/2019 1:59 am, Naoto Sato wrote: Hi, I don't think there is any *official* rule for the regression tests to succeed in any locale, but if the test case is locale sensitive such as in this case, I'd suggest it should correctly specify the locale beforehand, or quit gracefully in genera

Re: RFR (JDK 13) 8220254: fix headings in java.xml

+1 > On Mar 28, 2019, at 5:47 PM, Joe Wang > wrote: > > Please review a patch for the wrong headings. This patch passed build with > the new doclint enabled and doccheck (thanks Jon!) > > JBS: https://bugs.openjdk.java.net/browse/JDK-8220254 >

RFR (JDK 13) 8220254: fix headings in java.xml

Please review a patch for the wrong headings. This patch passed build with the new doclint enabled and doccheck (thanks Jon!) JBS: https://bugs.openjdk.java.net/browse/JDK-8220254 webrev: http://cr.openjdk.java.net/~joehw/jdk13/8220254/webrev/ Thanks, Joe

Re: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified

Apologize for the delay, got distracted by other urgent things. I've got some surprising micro-benchmark results, and need to understand them before pushing the fix. I'll verify the results and then share details. With kind regards, Ivan On 3/28/19 9:41 AM, Roger Riggs wrote: Hi Andrew, I

Re: RFR: JDK-8221582: Rename jvm-args option to java-options

Hi Andy, webrev.02 looks fine. Thanks, Alexander On 3/28/2019 11:20 AM, Alexey Semenyuk wrote: Agreed. Would you like me to create a record to track this follow up clean up? - Alexey On 3/28/2019 2:01 PM, Andy Herrick wrote: On 3/28/2019 1:54 PM, Kevin Rushforth wrote: That seems like a

Re: Review Request: 8221530: Caller sensitive methods not handling caller = null when invoked by JNI code with no java frames on stack

On 28/03/2019 16:43, Mandy Chung wrote: : Updated webrev: http://cr.openjdk.java.net/~mchung/jdk13/webrevs/8221530/webrev.01 I think this looks okay. One minor nit is that newIllegalAccessException doesn't throw IAE. -Alan

Re: RFR: JDK-8221582: Rename jvm-args option to java-options

Agreed. Would you like me to create a record to track this follow up clean up? - Alexey On 3/28/2019 2:01 PM, Andy Herrick wrote: On 3/28/2019 1:54 PM, Kevin Rushforth wrote: That seems like a good cleanup. It could be done in a follow-on bug depending on what Andy wants to do. Yes - I t

Re: RFR: JDK-8221582: Rename jvm-args option to java-options

On 3/28/2019 1:54 PM, Kevin Rushforth wrote: That seems like a good cleanup. It could be done in a follow-on bug depending on what Andy wants to do. Yes - I think we should file this as a follow on fix. My main concern first was the public facing names, but as with other modified options,

Re: RFR: JDK-8221582: Rename jvm-args option to java-options

That seems like a good cleanup. It could be done in a follow-on bug depending on what Andy wants to do. -- Kevin On 3/28/2019 10:50 AM, Alexey Semenyuk wrote: Andy, IMHO if you are renaming defines in C++ code, it makes sense to rename variables/functions too: JVMArgs -> JavaArgs in http:/

Re: RFR: JDK-8221582: Rename jvm-args option to java-options

Andy, IMHO if you are renaming defines in C++ code, it makes sense to rename variables/functions too: JVMArgs -> JavaArgs in http://cr.openjdk.java.net/~herrick/8221582/webrev.02/src/jdk.jpackage/share/native/libapplauncher/Helpers.cpp.sdiff.html Package::ReadJVMArgs -> Package::ReadJavaArgs in

Re: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null.

On 3/27/19 7:18 AM, Lindenmaier, Goetz wrote: , is this example very clear to them that it won't be supported? You probably meant that for n().getNull().m() it is not printed that getNull() was called on the result of n()? Yes, I caught my error after I sent my example. This is a desig

Re: RFR: JDK-8221582: Rename jvm-args option to java-options

Other than that one, the rest looks good to me. I also tested it and it works as expected. +1 (pending the change Semyon noted) -- Kevin On 3/28/2019 10:00 AM, semyon.sadet...@oracle.com wrote: It looks like one was missed: src/demo/share/jpackage/JNLPConverter/src/jnlp/converter/JNLPConver

Re: RFR: 8221477: Inject os/cpu-specific constants into Unsafe from JVM

On Thu, Mar 28, 2019 at 5:56 PM Andrew Dinn wrote: > On 28/03/2019 15:22, Thomas Stüfe wrote: > > The second of those was actually intended to be iff. This is a common > > abbreviation used by English/US mathematicians and logicians to write > > 'if and only if' (it is also sometimes

Re: RFR: JDK-8221582: Rename jvm-args option to java-options

It looks like one was missed: src/demo/share/jpackage/JNLPConverter/src/jnlp/converter/JNLPConverter.java 609launchArgs.add("--jvm-args"); --Semyon On 3/28/19 8:59 AM, Victor D'yakov wrote: Alexander, Semyon, please review. Victor Forwarded Message Subject:

Re: RFR: 8221477: Inject os/cpu-specific constants into Unsafe from JVM

On 28/03/2019 15:22, Thomas Stüfe wrote: > The second of those was actually intended to be iff. This is a common > abbreviation used by English/US mathematicians and logicians to write > 'if and only if' (it is also sometimes written as <=>). Since you didn't > recognize it I guess

Re: Review Request: 8221530: Caller sensitive methods not handling caller = null when invoked by JNI code with no java frames on stack

On 3/28/19 7:48 AM, Peter Levart wrote: Hi, On 3/28/19 9:40 AM, Alan Bateman wrote: On 27/03/2019 23:17, Mandy Chung wrote: : The proposed fix is to perform proper access check.  When there is no caller frame, it only allows to access to public members of a public type in an unconditiona

Re: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified

Hi Andrew, I'm fine with Ivan's version too. Roger On 03/28/2019 12:13 PM, Andrew Leonard wrote: Roger, Ivan, thanks for your help discussing this issue. Fyi, I am off on leave for the next week, so I +1 Ivan's last webrev if that's the way you decide to go.. Thanks Andrew Andrew Leonard J

Re: RFR: 8221477: Inject os/cpu-specific constants into Unsafe from JVM

On 3/28/19 3:22 PM, Thomas Stüfe wrote: > On Thu, Mar 28, 2019 at 3:41 PM Andrew Dinn wrote: > >> s/iff/if >> The second of those was actually intended to be iff. This is a common >> abbreviation used by English/US mathematicians and logicians to write >> 'if and only if' (it is also sometimes wri

Re: RFR: 8216539: tools/jar/modularJar/Basic.java timed out

On 3/28/19 12:19 AM, Alan Bateman wrote: On 28/03/2019 00:23, Mandy Chung wrote: On 3/27/19 4:56 PM, Lance Andersen wrote: Hi Mandy, On Mar 27, 2019, at 7:23 PM, Mandy Chung > wrote: Hi Lance, Do you understand what takes so long for this test to run?

Re: RFR: 8221477: Inject os/cpu-specific constants into Unsafe from JVM

On 3/28/19 4:23 PM, Andrew Haley wrote: > Dijkstra: > > The notation iff is used for "if and only if". A few years ago, > while lecturing in Denmark, I used Fif instead, reasoning that since > "if and only if" was a symmetric concept its notation should be > symmetric also. Without knowin

Re: Review Request: 8221530: Caller sensitive methods not handling caller = null when invoked by JNI code with no java frames on stack

On 3/28/19 8:46 AM, Peter Levart wrote: On 3/28/19 4:08 PM, Alan Bateman wrote: On 28/03/2019 14:48, Peter Levart wrote: : In addition, if access from null caller is granted and it is performed to a member in a "concealed" package, there's no warning displayed The proposed check is that

Re: Review Request: 8221530: Caller sensitive methods not handling caller = null when invoked by JNI code with no java frames on stack

On 3/28/19 4:46 PM, Peter Levart wrote: Reflection.verifyMemberAccess() is called not only from AccessibleObject.slowVerifyAccess() but from elsewhere too. For example, from ReflectUtil.ensureMemberAccess which is used in @CS AtomicXxxFieldUpdater(s), or from @CS java.util.ServiceLoader.loa

Re: Request for sponsor: JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified

Roger, Ivan, thanks for your help discussing this issue. Fyi, I am off on leave for the next week, so I +1 Ivan's last webrev if that's the way you decide to go.. Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815

Re: RFC: Make test failed because of the locale LANG

Hi, I don't think there is any *official* rule for the regression tests to succeed in any locale, but if the test case is locale sensitive such as in this case, I'd suggest it should correctly specify the locale beforehand, or quit gracefully in general. For this specific case, I'd suggest n

Re: RFR: 8217338: [Containers] Improve systemd slice memory limit support

On Thu, 2019-03-28 at 11:37 -0400, Bob Vandette wrote: > Sorry for the delay. The update looks good. Thanks for the review, Bob. Any other Reviewer(s)? Thanks, Severin > Bob. > > > > On Mar 25, 2019, at 1:30 PM, Severin Gehwolf wrote: > > > > On Fri, 2019-03-22 at 14:25 -0400, Bob Vandette

Re: Review Request: 8221530: Caller sensitive methods not handling caller = null when invoked by JNI code with no java frames on stack

On 3/28/19 4:08 PM, Alan Bateman wrote: On 28/03/2019 14:48, Peter Levart wrote: : In addition, if access from null caller is granted and it is performed to a member in a "concealed" package, there's no warning displayed The proposed check is that the package is exported unconditionally so

Re: Review Request: 8221530: Caller sensitive methods not handling caller = null when invoked by JNI code with no java frames on stack

On 3/28/19 1:40 AM, Alan Bateman wrote: On 27/03/2019 23:17, Mandy Chung wrote: : The proposed fix is to perform proper access check.  When there is no caller frame, it only allows to access to public members of a public type in an unconditional exported API package. The approach seems re

Re: RFR: 8217338: [Containers] Improve systemd slice memory limit support

Sorry for the delay. The update looks good. Bob. > On Mar 25, 2019, at 1:30 PM, Severin Gehwolf wrote: > > On Fri, 2019-03-22 at 14:25 -0400, Bob Vandette wrote: >> Could you maybe combine subsystem_file_contents with >> subsystem_file_line_contents >> by adding an additional argument? > >

Re: RFR: 8221477: Inject os/cpu-specific constants into Unsafe from JVM

Btw congrats for finally getting JEP 352 to move on. That really took a while. Cheers, Thomas On Thu, Mar 28, 2019 at 4:22 PM Thomas Stüfe wrote: > > > On Thu, Mar 28, 2019 at 3:41 PM Andrew Dinn wrote: > >> On 28/03/2019 12:17, Thomas Stüfe wrote: >> > this looks fine, nits only: >> >> Thank

Re: RFR: 8221477: Inject os/cpu-specific constants into Unsafe from JVM

On Thu, Mar 28, 2019 at 3:41 PM Andrew Dinn wrote: > On 28/03/2019 12:17, Thomas Stüfe wrote: > > this looks fine, nits only: > > Thank you for the review, Thomas. I'll post a follow up webrev to > address the comments. Responses are inline. > > > UnsafeConstantsFixup::do_field() > > > > you coul

Re: Review Request: 8221530: Caller sensitive methods not handling caller = null when invoked by JNI code with no java frames on stack

On 28/03/2019 14:48, Peter Levart wrote: : In addition, if access from null caller is granted and it is performed to a member in a "concealed" package, there's no warning displayed The proposed check is that the package is exported unconditionally so it will fail, no warning needed. I think th

New candidate JEP: 352: Non-Volatile Mapped Byte Buffers

https://openjdk.java.net/jeps/352 - Mark

Re: Review Request: 8221530: Caller sensitive methods not handling caller = null when invoked by JNI code with no java frames on stack

On 3/28/19 3:48 PM, Peter Levart wrote: In addition, if access from null caller is granted and it is performed to a member in a "concealed" package, there's no warning displayed (the further logic in the AccessibleObject is skipped). What would it look like if AccessibleObject was left inta

Re: Review Request: 8221530: Caller sensitive methods not handling caller = null when invoked by JNI code with no java frames on stack

Hi, On 3/28/19 9:40 AM, Alan Bateman wrote: On 27/03/2019 23:17, Mandy Chung wrote: : The proposed fix is to perform proper access check.  When there is no caller frame, it only allows to access to public members of a public type in an unconditional exported API package. The approach seems

Re: RFR: 8221477: Inject os/cpu-specific constants into Unsafe from JVM

On 28/03/2019 12:17, Thomas Stüfe wrote: > this looks fine, nits only: Thank you for the review, Thomas. I'll post a follow up webrev to address the comments. Responses are inline. > UnsafeConstantsFixup::do_field() > > you could shrink that coding a bit by factoring out the checks, e.g.: > . .

Re: RFR: 8221477: Inject os/cpu-specific constants into Unsafe from JVM

Hi, this looks fine, nits only: UnsafeConstantsFixup::do_field() you could shrink that coding a bit by factoring out the checks, e.g.: static oop mirror_with_checks_from_field_descriptor(fieldDescriptor* fd) { oop mirror = fd->field_holder()->java_mirror(); assert(fd->field_holder() == System

RE: RFR: 8218547: Simplify JLI_Open on Windows in native code (libjli) - was : RE: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows

Hi Matthias, this looks good to me now. Let's wait for another review then. Best regards Christoph > -Original Message- > From: Baesken, Matthias > Sent: Donnerstag, 28. März 2019 12:39 > To: Langer, Christoph > Cc: core-libs-dev@openjdk.java.net; Alan Bateman > > Subject: RE: RFR: 821

RE: RFR: 8218547: Simplify JLI_Open on Windows in native code (libjli) - was : RE: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows

Hello here is another webrev , I adjusted test/jdk/tools/launcher/Arrrghs.java a bit taking your suggestions into account . Can I have a second review please ? http://cr.openjdk.java.net/~mbaesken/webrevs/8218547.2/webrev/ > As for the test, I think you could also check a jar in a shor

RFR: JDK-8221582: Rename jvm-args option to java-options

RFR: JDK-8221582: Rename jvm-args option to java-options Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). [1] - https://bugs.openjdk.java.net/browse/JDK-8221582 [2] - http://cr.openjdk.java.net/~herr

RE: RFR: 8218547: Simplify JLI_Open on Windows in native code (libjli) - was : RE: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows

Hi Matthias, the change to src/java.base/windows/native/libjli/java_md.c looks good to me now. As for the test, I think you could also check a jar in a short path to exercise both cases in JLI_Open. And a few nits: Line 506: better do: Path pelp = pcreated.resolve(elp.jar); Line 507: 2 space

RFR: 8221477: Inject os/cpu-specific constants into Unsafe from JVM

Could I please have reviews for this patch which changes the initialization of four os/cpu-specific static final constants used by class Unsafe. The patch injects values during JVM startup (along similar lines to how String field COMPACT_STRINGS is initialized) rather than retrieving them via nativ

Re: Review Request: 8221530: Caller sensitive methods not handling caller = null when invoked by JNI code with no java frames on stack

On 27/03/2019 23:17, Mandy Chung wrote: : The proposed fix is to perform proper access check.  When there is no caller frame, it only allows to access to public members of a public type in an unconditional exported API package. The approach seems reasonable to me and we should, at some point, t

Re: RFR: 8216539: tools/jar/modularJar/Basic.java timed out

On 28/03/2019 00:23, Mandy Chung wrote: On 3/27/19 4:56 PM, Lance Andersen wrote: Hi Mandy, On Mar 27, 2019, at 7:23 PM, Mandy Chung > wrote: Hi Lance, Do you understand what takes so long for this test to run? Well it is executing a lot of jar commands.