RE: RFR 8240524: Removed warnings from test classes

Hi Vipin, this all looks correct to me. When changing the copyright headers, you have to keep the first (initial) year and only update the second year. If this doesn’t exist, you’ll have to add it, e.g. Copyright (c) 1999, Oracle -> Copyright (c) 1999, 2020, Oracle I can fix that for you

Re: RFR(S): 8232081: Try to link all classes during dynamic CDS dump

Hi Calvin, Looks good. In JDK-8240244, I removed "ik->loader_type() != 0" because it's unclear what it means. I replaced with a new method InstanceKlass::is_shared_unregistered_class(). I think you can use this in your patch instead of adding loader_type() back. No need for new webrev.

Re: argfiles parsing broken for argfiles > 4096 bytes

Thanks for the report and investigation, bug confirmed, JDK-8240629 is filed to tacking the issue. https://bugs.openjdk.java.net/browse/JDK-8240629 Cheers, Henry > On Mar 5, 2020, at 11:43 AM, Robert Stupp wrote: > > Another note: I've also seen it appending a comment-line in >

Re: JDK 15 RFR of JDK-8240624: Note mapping of RoundingMode constants to equivalent IEEE 754-2019 policy

Hi Joe, > On Mar 5, 2020, at 2:43 PM, Joe Darcy wrote: > >> Looks fine. Do you think the IEEE 754-2019 attribute names should have some >> kind of formatting, e.g., @code or italics? > The IEEE standard uses normal next for those terms, no italics, bold, etc. ; > in this context, I think

Re: JDK 15 RFR of JDK-8240624: Note mapping of RoundingMode constants to equivalent IEEE 754-2019 policy

Hi Brian, On 3/5/2020 1:51 PM, Brian Burkhalter wrote: Hi Joe, On Mar 5, 2020, at 1:45 PM, Joe Darcy > wrote: Where such a mapping exists, it would be helpful to tie the policies represented by various RoundingMode constants to the equivalent rounding attribute

Re: [15] 8235792: LineNumberReader.getLineNumber() behavior is inconsistent with respect to EOF

Might anyone else have any comments on this thread the original post in which was [1]. Thanks, Brian [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-January/064417.html > On Jan 31, 2020, at 12:21 PM, Brian Burkhalter > wrote: > >> On Jan 31, 2020, at 12:20 PM, Alan Bateman

Re: JDK 15 RFR of JDK-8240624: Note mapping of RoundingMode constants to equivalent IEEE 754-2019 policy

Hi Joe, > On Mar 5, 2020, at 1:45 PM, Joe Darcy wrote: > > Where such a mapping exists, it would be helpful to tie the policies > represented by various RoundingMode constants to the equivalent rounding > attribute defined by IEEE 754-2019, the latest version of the floating-point >

JDK 15 RFR of JDK-8240624: Note mapping of RoundingMode constants to equivalent IEEE 754-2019 policy

Hello, Where such a mapping exists, it would be helpful to tie the policies represented by various RoundingMode constants to the equivalent rounding attribute defined by IEEE 754-2019, the latest version of the floating-point standard:     JDK-8240624: Note mapping of RoundingMode constants

Re: RFR 8239893: Windows handle Leak when starting processes using ProcessBuilder

Hi Roger, In the test, the error value (-1) from the native code seems silently suppressed. Should it be caught/reported in the java side? nit: copyright year in ProcessImpl.java -> 2020. Naoto On 3/5/20 12:51 PM, Roger Riggs wrote: Please review a change to the Windows ProcessImpl to

Re: RFR 8239893: Windows handle Leak when starting processes using ProcessBuilder

Hi Roger, > On Mar 5, 2020, at 12:51 PM, Roger Riggs wrote: > > Please review a change to the Windows ProcessImpl to ensure that the handles > created for the input and output streams of a process are closed when no > longer referenced. > > Unlike on Linux, there is no thread monitoring the

RFR 8239893: Windows handle Leak when starting processes using ProcessBuilder

Please review a change to the Windows ProcessImpl to ensure that the handles created for the input and output streams of a process are closed when no longer referenced. Unlike on Linux, there is no thread monitoring the process that can close the streams. The FileDescriptors are registered

Re: RFR(S): 8232081: Try to link all classes during dynamic CDS dump

On 3/5/20 9:17 AM, Ioi Lam wrote: Hi Calvin, Looks good overall. I just have two comment: I think this is not needed:  306 void ConstantPool::resolve_class_constants(TRAPS) {  307   Arguments::assert_is_dumping_archive(); I've reverted this change. because this function is used to

Re: argfiles parsing broken for argfiles > 4096 bytes

Another note: I've also seen it appending a comment-line in http://hg.openjdk.java.net/jdk-updates/jdk11u/annotate/20e49753c388/src/java.base/share/native/libjli/args.c#l296 with pctx->state==IN_COMMENT, but wasn't able to reconstruct the behavior with a "clean" argfile. But that behavior was also

Re: argfiles parsing broken for argfiles > 4096 bytes

Sorry for the broken formatting... I recently came across a bug in the java executable with an argfile that's larger than 4096 bytes, if a 4096-byte-chunk ends in a comment line. The bug happens when the last character of a comment line is the 4096th byte and the trailing newline is the first

RE: jpackage Linux rpath [EXTERNAL]

Yes. I talked to a coworker and realized I glossed over that part. We run jpackage to create an application image and then use InstallBuilder to create an installer. We have 6 Java applications and dozens of C++ applications that all go into one big installer. Andrew -Original

Re: jpackage Linux rpath [EXTERNAL]

Andrew, Thank you for sharing! As far as I can see you use jpackage to create application image. I think your solution is optimal for this scenario. - Alexey On 3/5/2020 1:57 PM, Auclair, Andrew wrote: Hi Alexey, Thanks for the response! I think we will continue to do what we're doing now

argfiles parsing broken for argfiles > 4096 bytes

Hi, I recently came across a bug in the java executable with an argfile that's larger than 4096 bytes, if a 4096-byte-chunk ends in a comment line. One bug happens when the last character of a comment line is the 4096th byte and the trailing newline is the first byte in the next chunk. In that

RE: jpackage Linux rpath [EXTERNAL]

Hi Alexey, Thanks for the response! I think we will continue to do what we're doing now because it works just fine and is pretty simple. If anyone d is interested, this is how we do it: We run everything through a doLast in our build.gradle file and run an exec {} for jpackage and then if

Re: jpackage Linux rpath

Hi Andrew, jpackage is providing similar functionality as javapackager, so I think you need to keep using patchelf with jpackage as you used it with javapackager. I assume you use jpackage in two phases. The first phase creates application image and you use patchelf on launchers created by

Re: RFC: JEP JDK-8208089: Implement C++14 Language Features

On 3/3/20 10:26 AM, Andrew Haley wrote: > But one of the few things of which I am certain is that we must not > allow the needs of backporting to determine the future of Java. That's > the way of staying in the past. Unpopular opinion: It's the enterprise customers that mainly pay for the

Re: RFR: 8222000: JFR: Process start event

Hi Erik, The update looks fine. On 3/5/20 12:21 PM, Erik Gahlin wrote: Hi Roger, Thanks for the feedback. Runtime.exec doesn't take arg[0] as a separate parameter, so it may make sense to not split it up in the event. For example, if plan is to execute "hg clone url", but the user forgets

Re: RFR: 8238665: Add JFR event for direct memory statistics

Yes, I think it is fine to export from java.base to jdk.jfr for this feature. If you would add support for other buffer pools, it should not be over MXBeans, but using classes/interfaces that is available in java.base. Erik On 2020-03-05 16:19, Denghui Dong wrote: Hi Alan and Erik, Sorry, 

RFR 8240524: Removed warnings from test classes

Hi All, Please review patch to remove warnings from test classes. Bug : https://bugs.openjdk.java.net/browse/JDK-8240524 Webrev : http://cr.openjdk.java.net/~clanger/webrevs/8240524.0/

Re: RFR: 8222000: JFR: Process start event

Hi Roger, Thanks for the feedback. Runtime.exec doesn't take arg[0] as a separate parameter, so it may make sense to not split it up in the event. For example, if plan is to execute "hg clone url", but the user forgets to add "hg", then it will look as if "clone" is the command, which could

Re: RFR(S): 8232081: Try to link all classes during dynamic CDS dump

Hi Calvin, Looks good overall. I just have two comment: I think this is not needed:  306 void ConstantPool::resolve_class_constants(TRAPS) {  307   Arguments::assert_is_dumping_archive(); because this function is used to resolve all Strings in the statically dumped classes to archive all the

[15] RFR: 8216332: Grapheme regex does not work with emoji sequences

Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8216332 The proposed changeset is located at: https://cr.openjdk.java.net/~naoto/8216332/webrev.00/ Before this fix, the rule GB11 (Do not break within emoji modifier sequences or emoji zwj

Re: RFR: 8238665: Add JFR event for direct memory statistics

Hi Alan and Erik, Sorry, I'm not sure if I fully understand what you mean. For this feature, I still think exporting jdk.internal.access to jdk.jfr is a good solutionsince there are some other packages has already exported to jdk.jfr in this module. Thanks, Denghui Dong

RE: RFR: 8211917: (zipfs) Creating or updating a JAR file system should put the MANIFEST.MF at the start

Hi Lance, The revised webrev is at http://cr.openjdk.java.net/~lancea/8211917/webrev.02/index.html This looks good to me now. Ship it  Cheers Christoph

jpackage Linux rpath

Hi, We are in the process of upgrading to jpackage in Java 14 from javapackager in Java 10. So far the transition has been smooth and we're really liking jpackage. One question has come up regarding our Linux install. Currently we are using Patchelf on CentOS to set an rpath for the

RE: RFR: 8239365: ProcessBuilder/Basic.java test modifications for AIX execution

Hi All, As mentioned by Tom, a third opinion is sought on the aforementioned minor test change. @Tom - I'd prefer to use the full version of the error messages to keep things clear, though I would not object to using your abbreviated version if it means getting the change in. So long as it

Re: RFR: 8222000: JFR: Process start event

Hi Erik, Would the event be more useful if the executable arg[0] was a separate field from the arguments? Though I exect it depends on what is later evaluating the event fields. If all of cmdarrray is being joined, then the event field name is more appropriately called 'command';  similar to

RE: RFR: 8222000: JFR: Process start event

Hi Erik, Looks good. Quite straightforward, thank you for adding this capability. Thanks Markus -Original Message- From: Erik Gahlin Sent: den 5 mars 2020 15:11 To: hotspot-jfr-dev ; core-libs-dev@openjdk.java.net Subject: RFR: 8222000: JFR: Process start event Hi Could I have

RFR: 8222000: JFR: Process start event

Hi Could I have review of a JFR event that is emitted when a process is started from Java. Bug: https://bugs.openjdk.java.net/browse/JDK-8222000 Webrev: http://cr.openjdk.java.net/~egahlin/8222000/ Testing: tier1,tier2 + jdk/jdk/jfr Thanks Erik

Re: RFR: 8211917: (zipfs) Creating or updating a JAR file system should put the MANIFEST.MF at the start

Hi Christoph > On Mar 5, 2020, at 4:03 AM, Langer, Christoph > wrote: > > Hi Lance, > > Thanks for addressing my points. Here my answer to those things which weren't > in full agreement yet: Please see below > >> I dislike a bit the fact that we introduce a new testng subfolder in >>

Re: RFR: 8238665: Add JFR event for direct memory statistics

We should avoid adding a dependency on java.management. The jdk.jfr module today only depends java.base so JFR can be used in constrained environments. All JMX related functionality is in jdk.management.jfr. Erik > On 5 Mar 2020, at 10:54, Denghui Dong wrote: > > Hi Alan, > > If I use

Re: RFR: 8238665: Add JFR event for direct memory statistics

On 05/03/2020 09:54, Denghui Dong wrote: Hi Alan, If I use ManagementFactoryHelper to get memory pools, I still need to modify src/java.management/share/classes/module-info.java to export sun.management, right? I should have been clearer in my comment. I think it should be possible to put

Re: RFR: 8238665: Add JFR event for direct memory statistics

Hi Alan, If I use ManagementFactoryHelper to get memory pools, I still need to modify src/java.management/share/classes/module-info.java to export sun.management, right? Thanks, Denghui Dong -- From:Alan Bateman Send

RE: RFR: 8211917: (zipfs) Creating or updating a JAR file system should put the MANIFEST.MF at the start

Hi Lance, Thanks for addressing my points. Here my answer to those things which weren't in full agreement yet: > I dislike a bit the fact that we introduce a new testng subfolder in > test/jdk/nio/zipfs. Wouldn’t it be possible to consolidate in the current test > folder? > > I am trying to

Re: RFR: 8238665: Add JFR event for direct memory statistics

On 05/03/2020 02:44, Denghui Dong wrote: Hi Erik, Updated. Webrev: http://cr.openjdk.java.net/~ddong/8238665/webrev.01/ ManagementFactoryHelper has a method to get the list of MXBeans for the buffer pools. That could be easily changed to return an unmodifable list. That would allow you to