Re: RFR: 8329138: Convert JFR FileForceEvent to static mirror event [v2]

2024-04-01 Thread Alan Bateman
On Mon, 1 Apr 2024 23:37:21 GMT, Tim Prinzing wrote: >> Currently the JFR event FileForceEvent is generated by instrumenting the >> sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer >> mirror events with static methods. >> >> Added the event at

Re: RFR: 8329138: Convert JFR FileForceEvent to static mirror event [v2]

2024-04-01 Thread Alan Bateman
On Mon, 1 Apr 2024 23:37:21 GMT, Tim Prinzing wrote: >> Currently the JFR event FileForceEvent is generated by instrumenting the >> sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer >> mirror events with static methods. >> >> Added the event at

Re: RFR: 8329331: Intrinsify Unsafe::setMemory [v2]

2024-04-01 Thread David Holmes
On Mon, 1 Apr 2024 21:30:19 GMT, Scott Gibbons wrote: >> This code makes an intrinsic stub for `Unsafe::setMemory`. See [this >> PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this >> change. >> >> Overall, making this an intrinsic improves overall performance of >>

Re: RFR: 8329138: Convert JFR FileForceEvent to static mirror event [v2]

2024-04-01 Thread Tim Prinzing
> Currently the JFR event FileForceEvent is generated by instrumenting the > sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer > mirror events with static methods. > > Added the event at jdk.internal.event.FileForceEvent, and changed > jdk.jfr.events.FileForceEvent to

Integrated: 8329354: java/text/Format/MessageFormat/CompactSubFormats.java fails

2024-04-01 Thread Jie Fu
On Sat, 30 Mar 2024 02:26:32 GMT, Jie Fu wrote: > Hi all, > > java/text/Format/MessageFormat/CompactSubFormats.java fails in our testing > machines. > I'm not an expert in this area and just guess it can be fixed like this. > Please review it. > > Thanks. > Best regards, > Jie This pull

Re: RFR: 8329354: java/text/Format/MessageFormat/CompactSubFormats.java fails

2024-04-01 Thread Jie Fu
On Mon, 1 Apr 2024 16:55:45 GMT, Naoto Sato wrote: >> Hi all, >> >> java/text/Format/MessageFormat/CompactSubFormats.java fails in our testing >> machines. >> I'm not an expert in this area and just guess it can be fixed like this. >> Please review it. >> >> Thanks. >> Best regards, >> Jie >

Re: RFR: 8328995: launcher can't open jar files where the offset of the manifest is >4GB [v3]

2024-04-01 Thread Liam Miller-Cushon
On Fri, 29 Mar 2024 18:25:18 GMT, Jiangli Zhou wrote: >> it's in APPNOTE.TXT 4.5, the extra field structure is `header1+data1 + >> header2+data2 . . .`, and we have to iterate through to see if there's an >> entry that's a zip64 extended information extra field > > Thanks! That's helpful. I

Re: RFR: 8328995: launcher can't open jar files where the offset of the manifest is >4GB [v5]

2024-04-01 Thread Liam Miller-Cushon
> This change fixes a zip64 bug in the launcher that is prevent it from reading > the manifest of jars where the 'relative offset of local header' field in the > central directory entry is >4GB. As described in APPNOTE.TXT 4.5.3, the > offset is too large to be stored in the central directory

Re: RFR: 8328995: launcher can't open jar files where the offset of the manifest is >4GB [v3]

2024-04-01 Thread Liam Miller-Cushon
On Fri, 29 Mar 2024 17:40:59 GMT, Jiangli Zhou wrote: >> Liam Miller-Cushon has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Make cendsk an unsigned short > > src/java.base/share/native/libjli/parse_manifest.c line 503: > >> 501:

Re: RFR: 8328995: launcher can't open jar files where the offset of the manifest is >4GB [v4]

2024-04-01 Thread Liam Miller-Cushon
On Fri, 29 Mar 2024 19:54:31 GMT, Jiangli Zhou wrote: >> I think it doesn't matter, because the validation below only uses `cenoff`. >> If `cenoff` fits in 32 bits, we don't need to read the zip64 extra info. > > Thanks for the explanation. Could you please add a comment with the info > above

Re: RFR: 8329331: Intrinsify Unsafe::setMemory [v2]

2024-04-01 Thread Scott Gibbons
> This code makes an intrinsic stub for `Unsafe::setMemory`. See [this > PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this > change. > > Overall, making this an intrinsic improves overall performance of > `Unsafe::setMemory` by up to 4x for all buffer sizes. > >

Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v8]

2024-04-01 Thread Martin Doerr
On Mon, 1 Apr 2024 17:07:47 GMT, Suchismith Roy wrote: >> Allow support for both .a and .so files in AIX. >> If .so file is not found, allow fallback to .a extension. >> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516) > > Suchismith Roy has updated the pull request

Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v8]

2024-04-01 Thread Mandy Chung
On Mon, 1 Apr 2024 17:07:47 GMT, Suchismith Roy wrote: >> Allow support for both .a and .so files in AIX. >> If .so file is not found, allow fallback to .a extension. >> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516) > > Suchismith Roy has updated the pull request

Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v8]

2024-04-01 Thread Martin Doerr
On Mon, 1 Apr 2024 17:07:47 GMT, Suchismith Roy wrote: >> Allow support for both .a and .so files in AIX. >> If .so file is not found, allow fallback to .a extension. >> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516) > > Suchismith Roy has updated the pull request

Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v8]

2024-04-01 Thread Mandy Chung
On Mon, 1 Apr 2024 17:07:47 GMT, Suchismith Roy wrote: >> Allow support for both .a and .so files in AIX. >> If .so file is not found, allow fallback to .a extension. >> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516) > > Suchismith Roy has updated the pull request

Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v8]

2024-04-01 Thread Martin Doerr
On Mon, 1 Apr 2024 18:31:52 GMT, Mandy Chung wrote: > > Now, I'm getting "java.lang.UnsatisfiedLinkError: no libname.a in > > java.library.path" when trying `System.loadLibrary("libname.a")` even > > though the file exists in the library path. Is this intended? > > To load a library file, you

Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v8]

2024-04-01 Thread Mandy Chung
On Mon, 1 Apr 2024 18:02:26 GMT, Martin Doerr wrote: > Now, I'm getting "java.lang.UnsatisfiedLinkError: no libname.a in > java.library.path" when trying `System.loadLibrary("libname.a")` even though > the file exists in the library path. Is this intended? To load a library file, you should

Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v8]

2024-04-01 Thread Mandy Chung
On Mon, 1 Apr 2024 18:24:53 GMT, Mandy Chung wrote: >> Suchismith Roy has updated the pull request incrementally with one >> additional commit since the last revision: >> >> spaces > > src/java.base/aix/classes/jdk/internal/loader/ClassLoaderHelper.java line 48: > >> 46: * file may be

Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v8]

2024-04-01 Thread Mandy Chung
On Mon, 1 Apr 2024 17:07:47 GMT, Suchismith Roy wrote: >> Allow support for both .a and .so files in AIX. >> If .so file is not found, allow fallback to .a extension. >> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516) > > Suchismith Roy has updated the pull request

Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v8]

2024-04-01 Thread Martin Doerr
On Mon, 1 Apr 2024 17:07:47 GMT, Suchismith Roy wrote: >> Allow support for both .a and .so files in AIX. >> If .so file is not found, allow fallback to .a extension. >> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516) > > Suchismith Roy has updated the pull request

Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v8]

2024-04-01 Thread Suchismith Roy
> Allow support for both .a and .so files in AIX. > If .so file is not found, allow fallback to .a extension. > JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516) Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:

Re: RFR: 8329354: java/text/Format/MessageFormat/CompactSubFormats.java fails

2024-04-01 Thread Naoto Sato
On Sat, 30 Mar 2024 02:26:32 GMT, Jie Fu wrote: > Hi all, > > java/text/Format/MessageFormat/CompactSubFormats.java fails in our testing > machines. > I'm not an expert in this area and just guess it can be fixed like this. > Please review it. > > Thanks. > Best regards, > Jie LGTM. Thanks

Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v7]

2024-04-01 Thread Suchismith Roy
> Allow support for both .a and .so files in AIX. > If .so file is not found, allow fallback to .a extension. > JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516) Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:

Re: RFR: 8329354: java/text/Format/MessageFormat/CompactSubFormats.java fails

2024-04-01 Thread Jie Fu
On Sat, 30 Mar 2024 02:26:32 GMT, Jie Fu wrote: > Hi all, > > java/text/Format/MessageFormat/CompactSubFormats.java fails in our testing > machines. > I'm not an expert in this area and just guess it can be fixed like this. > Please review it. > > Thanks. > Best regards, > Jie May I get one

Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v6]

2024-04-01 Thread Suchismith Roy
On Thu, 28 Mar 2024 16:57:59 GMT, Mandy Chung wrote: > `System::loadLibrary("systeminfo")` should call `JVM_LoadLibrary` with > "/usr/lib/libsysteminfo.so" argument (let the .a file exists under > "/usr/lib") which in turn calls `os::dll_load`. JDK-8320005 changed > `os::dll_load` to first