RFR: 8281268: Resolve duplication of test ClassTransformer class

2022-05-11 Thread KIRIYAMA Takuya
ClassTransformer.java is duplicated because ClassTransformer.java was copied from test/jdk/com/sun/jdi/lib/jdb to test/lib/jdk/test/lib/util at [JDK-8240908](https://bugs.openjdk.java.net/browse/JDK-8240908). test/lib/jdk/test/lib/util/ClassTransformer.java should be deleted and test/jdk/com/su

Re: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and XSLTErrorResources.java [v7]

2022-05-11 Thread Shruthi
On Wed, 11 May 2022 05:22:22 GMT, Shruthi wrote: >> Removing the Duplicate keys present in XSLTErrorResources.java and >> XPATHErrorResources.java >> >> The bug report for the same: https://bugs.openjdk.java.net/browse/JDK-8285097 > > Shruthi has updated the pull request incrementally with one

Re: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems

2022-05-11 Thread Ioi Lam
On Tue, 10 May 2022 12:29:10 GMT, Severin Gehwolf wrote: > Please review this change to the cgroup v1 subsystem which makes it more > resilient on some of the stranger systems. Unfortunately, I wasn't able to > re-create a similar system as the reporter. The idea of using the longest > substri

Re: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe

2022-05-11 Thread Michael Hall
Alexander > On May 11, 2022, at 11:38 PM, Alexander Matveev > wrote: > > Hi Michael, > >> On May 11, 2022, at 3:17 PM, Michael Hall wrote: >> >> Is this restricted somehow to Mac App Store applications? > Yes, helper tools (in our case JDK native commands) in Mac App Store > applications ca

Re: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe

2022-05-11 Thread Alexander Matveev
Hi Michael, > On May 11, 2022, at 3:17 PM, Michael Hall wrote: > > Is this restricted somehow to Mac App Store applications? Yes, helper tools (in our case JDK native commands) in Mac App Store applications cannot use same bundle ID as another application. Since we have bundle ID embedded in n

Re: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4]

2022-05-11 Thread David Holmes
On Wed, 11 May 2022 16:00:32 GMT, Maxim Kartashev wrote: >> Matthias Baesken has updated the pull request incrementally with one >> additional commit since the last revision: >> >> adjust API level to Windows 8 for security.cpp and do some cleanup > > This change seem to have made this group

Re: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe [v2]

2022-05-11 Thread Alexander Matveev
On Wed, 11 May 2022 21:58:46 GMT, Alexey Semenyuk wrote: >> Alexander Matveev has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8286122: [macos]: App bundle cannot upload to Mac App Store due to >> info.plist embedded in java exe [v2] > >

Re: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe [v2]

2022-05-11 Thread Alexander Matveev
> - It is not possible to support native JDK commands such as "java" inside Mac > App Store bundles due to embedded info.plist. Workarounds suggested in > JDK-8286122 does not seems to be visible. > - With proposed fix we will enforce "--strip-native-commands" option for > jlink, so native JDK

Re: RFR: 8286560: Remove user parameter from jdk.internal.perf.Perf.attach()

2022-05-11 Thread David Holmes
On Wed, 11 May 2022 23:08:32 GMT, Ioi Lam wrote: > The API `jdk.internal.perf.Perf.::attach(String user, int lvmid)` is never > used. It should be removed, and all the handling of a specified user name > should be removed. Nice cleanup! I checked back in JDK 7 and couldn't find any use of this

Re: RFR: 8286279: [vectorapi] Only check index of masked lanes if offset is out of array boundary for masked store

2022-05-11 Thread Xiaohong Gong
On Thu, 12 May 2022 03:36:31 GMT, Paul Sandoz wrote: >> Thanks for the review @PaulSandoz ! For the >> `VectorIntrinsics.checkFromIndexSize`, I'm afraid it's not suitable to be >> used here because the `outOfBounds` exception will be thrown if the offset >> is not inside of the valid array bou

Re: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature [v3]

2022-05-11 Thread Xiaohong Gong
On Wed, 11 May 2022 19:45:55 GMT, Paul Sandoz wrote: > I tried your test code with the patch and logged compilation > (`-XX:-TieredCompilation -XX:+PrintCompilation -XX:+PrintInlining > -XX:+PrintIntrinsics -Xbatch`) > > For `func` the first call to `VectorSupport::loadMasked` is intrinsic and

Re: RFR: 8286279: [vectorapi] Only check index of masked lanes if offset is out of array boundary for masked store

2022-05-11 Thread Paul Sandoz
On Thu, 12 May 2022 01:56:25 GMT, Xiaohong Gong wrote: >> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template >> line 4086: >> >>> 4084: } else { >>> 4085: $Type$Species vsp = vspecies(); >>> 4086: if (offset < 0 || offset > (a.leng

Re: RFR: 8283689: Update the foreign linker VM implementation [v7]

2022-05-11 Thread David Holmes
On Wed, 11 May 2022 20:27:42 GMT, Patricio Chilano Mateo wrote: >> I went ahead and implemented this suggestion. Now we block async exceptions >> in on_entry, and unblock in on_exit. > > Is it possible for these upcalls to be nested? If yes, we could add a boolean > to context to avoid unsetti

Re: RFR: 8283689: Update the foreign linker VM implementation [v10]

2022-05-11 Thread David Holmes
On Wed, 11 May 2022 17:51:31 GMT, Jorn Vernee wrote: >> Hi, >> >> This PR updates the VM implementation of the foreign linker, by bringing >> over commits from the panama-foreign repo. >> >> This is split off from the main JEP integration for 19, since we have >> limited resources to handle t

Re: RFR: 8286582: Build fails on macos aarch64 when using --with-zlib=bundled [v2]

2022-05-11 Thread Jaikiran Pai
On Wed, 11 May 2022 14:24:38 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which fixes build failures on macos >> when using `--with-zlib=bundled`? >> >> With this change the build now passes (tested both with bundled and system >> zlib variants). >> >> tier1, tier2 and

Re: RFR: JDK-8286615: Small refactor to SerializedLambda

2022-05-11 Thread Iris Clark
On Thu, 12 May 2022 00:10:28 GMT, Joe Darcy wrote: > Noticed by inspection during a CSR review, small refactoring to use a > message-cause exception constructor when one is available. > > Will update the copyright before a push. Marked as reviewed by iris (Reviewer). - PR: https:

Re: RFR: 8286279: [vectorapi] Only check index of masked lanes if offset is out of array boundary for masked store

2022-05-11 Thread Xiaohong Gong
On Wed, 11 May 2022 15:10:55 GMT, Paul Sandoz wrote: >> Checking whether the indexes of masked lanes are inside of the valid memory >> boundary is necessary for masked vector memory access. However, this could >> be saved if the given offset is inside of the vector range that could make >> sur

Re: RFR: 8286562: GCC 12 reports some compiler warnings [v4]

2022-05-11 Thread Yasumasa Suenaga
On Thu, 12 May 2022 01:27:30 GMT, Yasumasa Suenaga wrote: >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 >> on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should >> separate them by area. >> >> * -Wstringop-overflow >> *

Re: RFR: 8286562: GCC 12 reports some compiler warnings [v2]

2022-05-11 Thread Yasumasa Suenaga
On Wed, 11 May 2022 13:47:43 GMT, Kim Barrett wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Avoid pragma error in before GCC 12 > > src/jdk.jpackage/linux/native/applauncher/LinuxPackage.c line 193: > >> 191

Re: RFR: 8286562: GCC 12 reports some compiler warnings [v4]

2022-05-11 Thread Yasumasa Suenaga
> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on > Fedora 36. > As you can see, the warnings spreads several areas. Let me know if I should > separate them by area. > > * -Wstringop-overflow > * src/hotspot/share/oops/array.hpp > * > src/hotspot/share/jfr/

Re: RFR: 8286562: GCC 12 reports some compiler warnings [v2]

2022-05-11 Thread Yasumasa Suenaga
On Wed, 11 May 2022 13:43:55 GMT, Kim Barrett wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Avoid pragma error in before GCC 12 > > src/java.base/unix/native/libjli/java_md_common.c line 135: > >> 133: i

Re: RFR: 8286562: GCC 12 reports some compiler warnings [v3]

2022-05-11 Thread Yasumasa Suenaga
> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on > Fedora 36. > As you can see, the warnings spreads several areas. Let me know if I should > separate them by area. > > * -Wstringop-overflow > * src/hotspot/share/oops/array.hpp > * > src/hotspot/share/jfr/

Re: RFR: 8286562: GCC 12 reports some compiler warnings [v2]

2022-05-11 Thread Yasumasa Suenaga
On Wed, 11 May 2022 14:27:27 GMT, Kim Barrett wrote: >> src/java.base/share/native/libjli/java.c line 1629: >> >>> 1627: const char *arg = jargv[i]; >>> 1628: if (arg[0] == '-' && arg[1] == 'J') { >>> 1629: *nargv++ = (arg[2] == '\0') ? NULL : JLI_StringDup(arg + >>>

Re: RFR: JDK-8286615: Small refactor to SerializedLambda

2022-05-11 Thread Brian Burkhalter
On Thu, 12 May 2022 00:10:28 GMT, Joe Darcy wrote: > Noticed by inspection during a CSR review, small refactoring to use a > message-cause exception constructor when one is available. > > Will update the copyright before a push. Marked as reviewed by bpb (Reviewer). - PR: https:/

Re: RFR: 8286562: GCC 12 reports some compiler warnings [v2]

2022-05-11 Thread Yasumasa Suenaga
On Wed, 11 May 2022 13:35:43 GMT, Kim Barrett wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Avoid pragma error in before GCC 12 > > src/hotspot/share/utilities/compilerWarnings_gcc.hpp line 51: > >> 49: >>

Re: RFR: 8277493: [REDO] Quarantined jpackage apps are labeled as "damaged"

2022-05-11 Thread Alexey Semenyuk
On Wed, 4 May 2022 03:56:10 GMT, Alexander Matveev wrote: > - No changes to code provided by original fix. > - Added ad hoc signing on macOS aarch64, since macOS aarch64 cannot execute > unsigned code and code should be at least ad hoc signed. > - Signing of app bundle produced by AppContentTe

Re: RFR: 8277493: [REDO] Quarantined jpackage apps are labeled as "damaged"

2022-05-11 Thread Alexey Semenyuk
On Wed, 4 May 2022 03:56:10 GMT, Alexander Matveev wrote: > - No changes to code provided by original fix. > - Added ad hoc signing on macOS aarch64, since macOS aarch64 cannot execute > unsigned code and code should be at least ad hoc signed. > - Signing of app bundle produced by AppContentTe

Re: RFR: 8286562: GCC 12 reports some compiler warnings [v2]

2022-05-11 Thread Yasumasa Suenaga
On Wed, 11 May 2022 19:11:16 GMT, Phil Race wrote: >> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 462: >> >>> 460:HARFBUZZ_DISABLED_WARNINGS_gcc := type-limits >>> missing-field-initializers strict-aliasing >>> 461:HARFBUZZ_DISABLED_WARNINGS_CXX_gcc := reorder >>> delete-non-

RFR: JDK-8286615: Small refactor to SerializedLambda

2022-05-11 Thread Joe Darcy
Noticed by inspection during a CSR review, small refactoring to use a message-cause exception constructor when one is available. Will update the copyright before a push. - Commit messages: - JDK-8286615: Small refactor to SerializedLambda Changes: https://git.openjdk.java.net/jdk/

RFR: 8286560: Remove user parameter from jdk.internal.perf.Perf.attach()

2022-05-11 Thread Ioi Lam
The API `jdk.internal.perf.Perf.::attach(String user, int lvmid)` is never used. It should be removed, and all the handling of a specified user name should be removed. - Commit messages: - more cleanup - 8286560: Remove user parameter from jdk.internal.perf.Perf.attach() Changes:

Re: RFR: JDK-8286604: Update InputStream and OutputStream to use @implSpec

2022-05-11 Thread liach
On Wed, 11 May 2022 20:40:30 GMT, Joe Darcy wrote: > While doing a CSR review of another issue, I noticed some cases in > InputStream and OutputStream what would benefit from being upgraded to > implSpec and related javadoc tags. > > The "A subclass must provide an implementation of this metho

Re: RFR: 8286582: Build fails on macos aarch64 when using --with-zlib=bundled [v2]

2022-05-11 Thread Lance Andersen
On Wed, 11 May 2022 22:03:38 GMT, Magnus Ihse Bursie wrote: > It would not make sense to set the disabled warning in the configure script, > no. The current code looks perfectly fine. Disabled warnings per module are > set in the makefiles. OK, that you for your feedback regarding the makefile

Re: RFR: 8286582: Build fails on macos aarch64 when using --with-zlib=bundled [v2]

2022-05-11 Thread Lance Andersen
On Wed, 11 May 2022 14:24:38 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which fixes build failures on macos >> when using `--with-zlib=bundled`? >> >> With this change the build now passes (tested both with bundled and system >> zlib variants). >> >> tier1, tier2 and

Re: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe

2022-05-11 Thread Michael Hall
> On May 11, 2022, at 5:17 PM, Michael Hall wrote: > > I’m not real familiar with the build process. But would it be possible for > the user to build their own jdk that substitutes something else for the > colliding identifier that gets embedded? Or just change it in the current build so it

Re: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe

2022-05-11 Thread Michael Hall
Is this restricted somehow to Mac App Store applications? Is a warning issued as stripping native commands may break application functionality? Is it not possible for the user to provide their own Info.plist with a different bundle identifier that doesn’t collide? I’m not real familiar with

Re: RFR: 8286582: Build fails on macos aarch64 when using --with-zlib=bundled [v2]

2022-05-11 Thread Magnus Ihse Bursie
On Wed, 11 May 2022 19:14:54 GMT, Lance Andersen wrote: >> make/autoconf/lib-bundled.m4 line 220: >> >>> 218: if test "x$USE_EXTERNAL_LIBZ" = "xfalse"; then >>> 219: LIBZ_CFLAGS="$LIBZ_CFLAGS >>> -I$TOPDIR/src/java.base/share/native/libzip/zlib" >>> 220: if test "x$OPENJDK_TARGET_OS"

Re: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe

2022-05-11 Thread Alexey Semenyuk
On Wed, 11 May 2022 21:31:44 GMT, Alexander Matveev wrote: > - It is not possible to support native JDK commands such as "java" inside Mac > App Store bundles due to embedded info.plist. Workarounds suggested in > JDK-8286122 does not seems to be visible. > - With proposed fix we will enforce

Re: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe

2022-05-11 Thread Alexey Semenyuk
On Wed, 11 May 2022 21:31:44 GMT, Alexander Matveev wrote: > - It is not possible to support native JDK commands such as "java" inside Mac > App Store bundles due to embedded info.plist. Workarounds suggested in > JDK-8286122 does not seems to be visible. > - With proposed fix we will enforce

RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe

2022-05-11 Thread Alexander Matveev
- It is not possible to support native JDK commands such as "java" inside Mac App Store bundles due to embedded info.plist. Workarounds suggested in JDK-8286122 does not seems to be visible. - With proposed fix we will enforce "--strip-native-commands" option for jlink, so native JDK commands a

Re: Unused method sun.reflect.misc.MethodUtil.getPublicMethods

2022-05-11 Thread Mandy Chung
They are unused and leftover since JDK 7. It's good to remove them. Thanks Mandy On 4/30/22 7:48 AM, Andrey Turbanov wrote: Hello. I found a few methods in MethodUtil class which seem unused to me: getPublicMethods, getInterfaceMethods, getInternalPublicMethods ,addMethod. Are they somehow use

Re: RFR: JDK-8286604: Update InputStream and OutputStream to use @implSpec

2022-05-11 Thread Iris Clark
On Wed, 11 May 2022 20:40:30 GMT, Joe Darcy wrote: > While doing a CSR review of another issue, I noticed some cases in > InputStream and OutputStream what would benefit from being upgraded to > implSpec and related javadoc tags. > > The "A subclass must provide an implementation of this metho

Re: RFR: JDK-8286604: Update InputStream and OutputStream to use @implSpec

2022-05-11 Thread Lance Andersen
On Wed, 11 May 2022 20:40:30 GMT, Joe Darcy wrote: > While doing a CSR review of another issue, I noticed some cases in > InputStream and OutputStream what would benefit from being upgraded to > implSpec and related javadoc tags. > > The "A subclass must provide an implementation of this metho

Re: RFR: JDK-8286604: Update InputStream and OutputStream to use @implSpec

2022-05-11 Thread Brian Burkhalter
On Wed, 11 May 2022 20:40:30 GMT, Joe Darcy wrote: > While doing a CSR review of another issue, I noticed some cases in > InputStream and OutputStream what would benefit from being upgraded to > implSpec and related javadoc tags. > > The "A subclass must provide an implementation of this metho

Re: RFR: 8286200: SequenceInputStream::read(b, off, 0) returns -1 at EOF

2022-05-11 Thread Brian Burkhalter
On Wed, 11 May 2022 20:47:52 GMT, Brian Burkhalter wrote: > Modify the specification of `SequenceInputStream.read(byte[],int,int)` to > indicate that `-1` is returned at the EOF of the last stream even if `len` is > zero. The `InputStream.read(byte[],int,int)` specification indicates If len

RFR: 8286200: SequenceInputStream::read(b, off, 0) returns -1 at EOF

2022-05-11 Thread Brian Burkhalter
Modify the specification of `SequenceInputStream.read(byte[],int,int)` to indicate that `-1` is returned at the EOF of the last stream even if `len` is zero. - Commit messages: - 8286200: SequenceInputStream::read(b, off, 0) returns -1 at EOF Changes: https://git.openjdk.java.net/

Re: RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for all ZoneOffsets and returns GMT unexpected [v5]

2022-05-11 Thread Uwe Schindler
On Wed, 11 May 2022 20:04:39 GMT, Naoto Sato wrote: >> This is to extend the `Custom ID`s in `java.util.TimeZone` class to support >> second-level resolution, enabling round trips with `java.time.ZoneOffset`s. >> Corresponding CSR is also being drafted. > > Naoto Sato has updated the pull reque

RFR: JDK-8286604: Update InputStream and OutputStream to use @implSpec

2022-05-11 Thread Joe Darcy
While doing a CSR review of another issue, I noticed some cases in InputStream and OutputStream what would benefit from being upgraded to implSpec and related javadoc tags. The "A subclass must provide an implementation of this method." statements on several abstract methods don't add much valu

Re: RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for all ZoneOffsets and returns GMT unexpected [v5]

2022-05-11 Thread Joe Wang
On Wed, 11 May 2022 20:04:39 GMT, Naoto Sato wrote: >> This is to extend the `Custom ID`s in `java.util.TimeZone` class to support >> second-level resolution, enabling round trips with `java.time.ZoneOffset`s. >> Corresponding CSR is also being drafted. > > Naoto Sato has updated the pull reque

Re: RFR: 8283689: Update the foreign linker VM implementation [v7]

2022-05-11 Thread Patricio Chilano Mateo
On Wed, 11 May 2022 17:55:16 GMT, Jorn Vernee wrote: >> Oh nice! I was just thinking that the only possible way out of this >> conundrum would be to somehow block the delivery of async exceptions (at >> least outside of the user's exception handler). So, that seems to be exactly >> what we nee

Re: RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for all ZoneOffsets and returns GMT unexpected [v5]

2022-05-11 Thread Stephen Colebourne
On Wed, 11 May 2022 20:04:39 GMT, Naoto Sato wrote: >> This is to extend the `Custom ID`s in `java.util.TimeZone` class to support >> second-level resolution, enabling round trips with `java.time.ZoneOffset`s. >> Corresponding CSR is also being drafted. > > Naoto Sato has updated the pull reque

Re: RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for all ZoneOffsets and returns GMT unexpected [v5]

2022-05-11 Thread Naoto Sato
> This is to extend the `Custom ID`s in `java.util.TimeZone` class to support > second-level resolution, enabling round trips with `java.time.ZoneOffset`s. > Corresponding CSR is also being drafted. Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The i

Re: RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for all ZoneOffsets and returns GMT unexpected [v4]

2022-05-11 Thread Naoto Sato
On Wed, 11 May 2022 18:30:32 GMT, Joe Wang wrote: >> Naoto Sato has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Minor fixup > > src/java.base/share/classes/java/util/TimeZone.java line 80: > >> 78: * {@code GMT} Sign Hours {@co

Re: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature [v3]

2022-05-11 Thread Paul Sandoz
On Thu, 5 May 2022 08:56:07 GMT, Xiaohong Gong wrote: >> Currently the vector load with mask when the given index happens out of the >> array boundary is implemented with pure java scalar code to avoid the IOOBE >> (IndexOutOfBoundaryException). This is necessary for architectures that do >> n

Integrated: 8286441: Remove mode parameter from jdk.internal.perf.Perf.attach()

2022-05-11 Thread Ioi Lam
On Tue, 10 May 2022 04:00:29 GMT, Ioi Lam wrote: > The `mode` parameter for ` jdk.internal.perf.Perf.attach()` has never > supported the value `"rw"` since the source code was imported to the openjdk > repo more than 15 years ago. In fact HotSpot throws > `IllegalArgumentException` when such a

Re: RFR: 8286441: Remove mode parameter from jdk.internal.perf.Perf.attach()

2022-05-11 Thread Ioi Lam
On Tue, 10 May 2022 20:03:45 GMT, Alan Bateman wrote: >> The `mode` parameter for ` jdk.internal.perf.Perf.attach()` has never >> supported the value `"rw"` since the source code was imported to the openjdk >> repo more than 15 years ago. In fact HotSpot throws >> `IllegalArgumentException` wh

Re: RFR: 8286594: (zipfs) Improvements after JDK-8251329

2022-05-11 Thread Lance Andersen
On Wed, 11 May 2022 15:32:38 GMT, Christoph Langer wrote: > This augments the ZipException upon rejecting a Zip File containing entry > names with "." or ".." elements. > > It furthermore tries to clean up & compact the logic for detecting "." and > ".." and it adds a method IndexNode::nameAsS

Re: RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for all ZoneOffsets and returns GMT unexpected [v4]

2022-05-11 Thread Joe Wang
On Wed, 11 May 2022 17:04:41 GMT, Naoto Sato wrote: >> This is to extend the `Custom ID`s in `java.util.TimeZone` class to support >> second-level resolution, enabling round trips with `java.time.ZoneOffset`s. >> Corresponding CSR is also being drafted. > > Naoto Sato has updated the pull reque

Re: RFR: 8286582: Build fails on macos aarch64 when using --with-zlib=bundled [v2]

2022-05-11 Thread Lance Andersen
On Wed, 11 May 2022 15:03:56 GMT, Lance Andersen wrote: >> Jaikiran Pai has updated the pull request incrementally with four additional >> commits since the last revision: >> >> - copyright years >> - disable format-nonliteral warning when building LIBSPLASHSCREEN with >> bundled zlib >> -

Re: RFR: 8282664: Unroll by hand StringUTF16, StringLatin1, and Arrays polynomial hash loops [v12]

2022-05-11 Thread Paul Sandoz
On Tue, 10 May 2022 14:46:56 GMT, Ludovic Henry wrote: >> Despite the hash value being cached for Strings, computing the hash still >> represents a significant CPU usage for applications handling lots of text. >> >> Even though it would be generally better to do it through an enhancement to >>

Re: RFR: 8286562: GCC 12 reports some compiler warnings [v2]

2022-05-11 Thread Phil Race
On Wed, 11 May 2022 13:35:00 GMT, Kim Barrett wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Avoid pragma error in before GCC 12 > > make/modules/java.desktop/lib/Awt2dLibraries.gmk line 462: > >> 460:HAR

Re: RFR: 8286378: Address possibly lossy conversions in java.base [v3]

2022-05-11 Thread Alan Bateman
On Wed, 11 May 2022 16:30:41 GMT, Roger Riggs wrote: >> PR#8599 8244681: proposes to add compiler warnings for possible lossy >> conversions >> From the CSR: >> >> "If the type of the right-hand operand of a compound assignment is not >> assignment compatible with the type of the variable, a c

Re: RFR: 8286441: Remove mode parameter from jdk.internal.perf.Perf.attach() [v2]

2022-05-11 Thread Alan Bateman
On Wed, 11 May 2022 02:43:21 GMT, Ioi Lam wrote: >> The `mode` parameter for ` jdk.internal.perf.Perf.attach()` has never >> supported the value `"rw"` since the source code was imported to the openjdk >> repo more than 15 years ago. In fact HotSpot throws >> `IllegalArgumentException` when su

Re: RFR: 8286582: Build fails on macos aarch64 when using --with-zlib=bundled [v2]

2022-05-11 Thread Magnus Ihse Bursie
On Wed, 11 May 2022 14:24:38 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which fixes build failures on macos >> when using `--with-zlib=bundled`? >> >> With this change the build now passes (tested both with bundled and system >> zlib variants). >> >> tier1, tier2 and

Re: RFR: 8286582: Build fails on macos aarch64 when using --with-zlib=bundled [v2]

2022-05-11 Thread Magnus Ihse Bursie
On Wed, 11 May 2022 15:03:56 GMT, Lance Andersen wrote: >> Jaikiran Pai has updated the pull request incrementally with four additional >> commits since the last revision: >> >> - copyright years >> - disable format-nonliteral warning when building LIBSPLASHSCREEN with >> bundled zlib >> -

Re: RFR: 8285517: System.getenv() returns unexpected value if environment variable has non ASCII character [v7]

2022-05-11 Thread Roger Riggs
On Mon, 9 May 2022 12:30:19 GMT, Ichiroh Takiguchi wrote: >> On JDK19 with Linux ja_JP.eucjp locale, >> System.getenv() returns unexpected value if environment variable has >> Japanese EUC characters. >> It seems this issue happens because of JEP 400. >> Arguments for ProcessBuilder have same k

Re: RFR: 8283689: Update the foreign linker VM implementation [v7]

2022-05-11 Thread Jorn Vernee
On Wed, 11 May 2022 16:38:54 GMT, Jorn Vernee wrote: >> If you want to avoid processing asynchronous exceptions during this upcall >> you could block them (check NoAsyncExceptionDeliveryMark in >> JavaThread::exit()). Seems you could set the flag in >> ProgrammableUpcallhandler::on_entry() and

Re: RFR: 8283689: Update the foreign linker VM implementation [v10]

2022-05-11 Thread Jorn Vernee
> Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over > commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited > resources to handle this. As such, this PR might fall over to 20, but it > would b

Re: RFR: 8286378: Address possibly lossy conversions in java.base [v3]

2022-05-11 Thread Brian Burkhalter
On Wed, 11 May 2022 16:30:41 GMT, Roger Riggs wrote: >> PR#8599 8244681: proposes to add compiler warnings for possible lossy >> conversions >> From the CSR: >> >> "If the type of the right-hand operand of a compound assignment is not >> assignment compatible with the type of the variable, a c

Re: RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for all ZoneOffsets and returns GMT unexpected [v4]

2022-05-11 Thread Naoto Sato
> This is to extend the `Custom ID`s in `java.util.TimeZone` class to support > second-level resolution, enabling round trips with `java.time.ZoneOffset`s. > Corresponding CSR is also being drafted. Naoto Sato has updated the pull request incrementally with one additional commit since the last

Re: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v3]

2022-05-11 Thread Patrick Chen
I checked you pr look good to me @Roger Le mer. 11 mai 2022 à 15:35, Roger Riggs a écrit : > On Wed, 11 May 2022 13:27:38 GMT, Adam Sotona wrote: > > >> That's good to know. I think the tricky part is mostly about keeping > track of all these disabled warnings, so they are not kept around longe

Re: RFR: 8283689: Update the foreign linker VM implementation [v7]

2022-05-11 Thread Jorn Vernee
On Wed, 11 May 2022 16:20:32 GMT, Patricio Chilano Mateo wrote: >> Discussed this with Maurizio as well. >> >> My understanding is as follows: >> 1. Async exceptions are installed into a thread's `pending_exception` field >> by handshake at a safepoint >> 2. From there they are "thrown" (I gu

Re: RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for all ZoneOffsets and returns GMT unexpected [v3]

2022-05-11 Thread Naoto Sato
On Wed, 11 May 2022 09:00:45 GMT, Uwe Schindler wrote: >> I tried it out: If you create a ZoneId with prefixes "UT" and "UTC", they >> fail to convert to TimeZone. Same happens if you use this as String name in >> `TimeZone#getTimeZone(String)`. This is another bug / missing feature! It >> doe

Re: RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for all ZoneOffsets and returns GMT unexpected [v3]

2022-05-11 Thread Naoto Sato
> This is to extend the `Custom ID`s in `java.util.TimeZone` class to support > second-level resolution, enabling round trips with `java.time.ZoneOffset`s. > Corresponding CSR is also being drafted. Naoto Sato has updated the pull request incrementally with one additional commit since the last

Re: RFR: 8286378: Address possibly lossy conversions in java.base [v3]

2022-05-11 Thread Roger Riggs
> PR#8599 8244681: proposes to add compiler warnings for possible lossy > conversions > From the CSR: > > "If the type of the right-hand operand of a compound assignment is not > assignment compatible with the type of the variable, a cast is implied and > possible lossy conversion may silently

Re: RFR: 8286287: Reading file as UTF-16 causes Error which "shouldn't happen" [v2]

2022-05-11 Thread Roger Riggs
On Wed, 11 May 2022 15:52:59 GMT, Naoto Sato wrote: >> `String.decodeWithDecoder()` method requires the `CharsetDecoder` parameter >> replaces on malformed/unmappable characters with replacements. However, >> there was a code path that lacked to set the `CodingErrorAction.REPLACE` on >> the de

Re: RFR: 8283689: Update the foreign linker VM implementation [v7]

2022-05-11 Thread Patricio Chilano Mateo
On Wed, 11 May 2022 15:44:19 GMT, Jorn Vernee wrote: >> We have an exception handler in Java as well, so this code is only a fail >> safe. But, I think in the case of asynchronous exceptions this might be >> problematic if the exception is discovered by the current thread outside of >> the Jav

Re: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4]

2022-05-11 Thread Maxim Kartashev
On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is >> used to target a minimum Windows version we want to support. See also for >> more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/win

Re: RFR: 8286287: Reading file as UTF-16 causes Error which "shouldn't happen" [v2]

2022-05-11 Thread Naoto Sato
> `String.decodeWithDecoder()` method requires the `CharsetDecoder` parameter > replaces on malformed/unmappable characters with replacements. However, there > was a code path that lacked to set the `CodingErrorAction.REPLACE` on the > decoder. Unrelated, one typo in a test was also fixed. Naot

Re: RFR: 8283689: Update the foreign linker VM implementation [v9]

2022-05-11 Thread Jorn Vernee
On Wed, 11 May 2022 12:20:43 GMT, Jorn Vernee wrote: >> Any problems with migrating `CallConv` and `RegSpiller`away from ` VMReg* + >> int` to `GrowableArray`? > > I'll try migrating to `GrowableArray` Done. I've removed these accessors as well. - PR: https://git.openjdk.java.net/

Re: RFR: 8283689: Update the foreign linker VM implementation [v7]

2022-05-11 Thread Jorn Vernee
On Wed, 11 May 2022 12:05:29 GMT, Jorn Vernee wrote: >> src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 306: >> >>> 304: intptr_t exception_handler_offset = __ pc() - start; >>> 305: >>> 306: // Native caller has no idea how to handle exceptions, >> >> Can you elaborate, pl

RFR: 8286594: (zipfs) Improvements after JDK-8251329

2022-05-11 Thread Christoph Langer
This augments the ZipException upon rejecting a Zip File containing entry names with "." or ".." elements. It furthermore tries to clean up & compact the logic for detecting "." and ".." and it adds a method IndexNode:nameAsString() to return the node name as a String. - Commit me

Re: Can JDK-8190546 be re-opened or "how do I delete a file ending with a space on Windows"

2022-05-11 Thread Brian Burkhalter
Redirect discussion to nio-dev. Brian > On May 11, 2022, at 7:29 AM, Maxim Kartashev > wrote: > > Win32 documentation [1] kind of discourages the use of space at the very > end of a file name. Based on that, JDK-8190546 (File.toPath() reject > directory names with trailing space) had been clos

Re: RFR: 8286287: Reading file as UTF-16 causes Error which "shouldn't happen"

2022-05-11 Thread Brian Burkhalter
On Tue, 10 May 2022 20:22:39 GMT, Naoto Sato wrote: > `String.decodeWithDecoder()` method requires the `CharsetDecoder` parameter > replaces on malformed/unmappable characters with replacements. However, there > was a code path that lacked to set the `CodingErrorAction.REPLACE` on the > decode

Re: RFR: 8283689: Update the foreign linker VM implementation [v9]

2022-05-11 Thread Jorn Vernee
> Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over > commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited > resources to handle this. As such, this PR might fall over to 20. > > I've written

Re: RFR: 8286279: [vectorapi] Only check index of masked lanes if offset is out of array boundary for masked store

2022-05-11 Thread Paul Sandoz
On Tue, 10 May 2022 01:23:55 GMT, Xiaohong Gong wrote: > Checking whether the indexes of masked lanes are inside of the valid memory > boundary is necessary for masked vector memory access. However, this could be > saved if the given offset is inside of the vector range that could make sure >

Re: RFR: 8286582: Build fails on macos aarch64 when using --with-zlib=bundled [v2]

2022-05-11 Thread Lance Andersen
On Wed, 11 May 2022 14:24:38 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which fixes build failures on macos >> when using `--with-zlib=bundled`? >> >> With this change the build now passes (tested both with bundled and system >> zlib variants). >> >> tier1, tier2 and

Re: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature [v3]

2022-05-11 Thread Paul Sandoz
On Wed, 11 May 2022 03:23:13 GMT, Xiaohong Gong wrote: >> I modified the code of this PR to avoid the conversion of `boolean` to >> `int`, so a constant integer value is passed all the way through, and the >> masked load is made intrinsic from the method at which the constants are >> passed as

Re: RFR: 8286582: Build fails on macos aarch64 when using --with-zlib=bundled [v2]

2022-05-11 Thread Lance Andersen
On Wed, 11 May 2022 14:25:39 GMT, Jaikiran Pai wrote: >> I agree with Magnus and try to avoid changing the imported zlib code. > >> I did these changes locally but for some reason this format-nonliteral is >> not getting picked up while building that library. > > Turns out that was slightly in

Re: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v5]

2022-05-11 Thread Adam Sotona
> Please review this patch adding new lint option, **lossy-conversions**, to > javac to warn about type casts in compound assignments with possible lossy > conversions. > > The new lint warning is shown if the type of the right-hand operand of a > compound assignment is not assignment compatibl

Re: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v4]

2022-05-11 Thread Adam Sotona
> Please review this patch adding new lint option, **lossy-conversions**, to > javac to warn about type casts in compound assignments with possible lossy > conversions. > > The new lint warning is shown if the type of the right-hand operand of a > compound assignment is not assignment compatibl

Re: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v3]

2022-05-11 Thread Adam Sotona
On Wed, 11 May 2022 13:31:16 GMT, Roger Riggs wrote: >> Thanks for quick reaction. >> I'll keep my eyes on this race of patches and update this pull request >> accordingly or create a new PR. > > I put out a PR for java.base, but thought I'd wait until the javac fixe were > pushed before integr

Re: RFR: 8283689: Update the foreign linker VM implementation [v7]

2022-05-11 Thread Jorn Vernee
On Tue, 10 May 2022 20:38:05 GMT, Vladimir Ivanov wrote: >> Jorn Vernee has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 21 commits: >> >> - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 >> - Remove unneeded ComputeMoveOr

Re: RFR: 8283689: Update the foreign linker VM implementation [v7]

2022-05-11 Thread Jorn Vernee
On Wed, 11 May 2022 11:06:51 GMT, Jorn Vernee wrote: >> src/hotspot/share/opto/callGenerator.cpp line 1131: >> >>> 1129: >>> 1130: case vmIntrinsics::_linkToNative: >>> 1131: print_inlining_failure(C, callee, jvms->depth() - 1, jvms->bci(), >> >> Why is it unconditionally reported as i

Re: RFR: 8286582: Build fails on macos aarch64 when using --with-zlib=bundled [v2]

2022-05-11 Thread Jaikiran Pai
On Wed, 11 May 2022 11:52:55 GMT, Magnus Ihse Bursie wrote: >> Jaikiran Pai has updated the pull request incrementally with four additional >> commits since the last revision: >> >> - copyright years >> - disable format-nonliteral warning when building LIBSPLASHSCREEN with >> bundled zlib >>

Re: RFR: 8286582: Build fails on macos aarch64 when using --with-zlib=bundled [v2]

2022-05-11 Thread Jaikiran Pai
On Wed, 11 May 2022 12:50:39 GMT, Alan Bateman wrote: >> Thank you for these useful inputs Magnus. I did these changes locally but >> for some reason this format-nonliteral is not getting picked up while >> building that library. I will investigate and see what's going on. Will >> update the P

Re: RFR: 8286562: GCC 12 reports some compiler warnings [v2]

2022-05-11 Thread Kim Barrett
On Wed, 11 May 2022 13:56:44 GMT, Kim Barrett wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Avoid pragma error in before GCC 12 > > src/java.base/share/native/libjli/java.c line 1629: > >> 1627: cons

Re: RFR: 8283689: Update the foreign linker VM implementation [v7]

2022-05-11 Thread Jorn Vernee
On Tue, 10 May 2022 21:02:39 GMT, Vladimir Ivanov wrote: >> Jorn Vernee has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 21 commits: >> >> - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 >> - Remove unneeded ComputeMoveOr

Re: RFR: 8283689: Update the foreign linker VM implementation [v8]

2022-05-11 Thread Jorn Vernee
> Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over > commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited > resources to handle this. As such, this PR might fall over to 20. > > I've written

Re: RFR: 8286582: Build fails on macos aarch64 when using --with-zlib=bundled [v2]

2022-05-11 Thread Jaikiran Pai
> Can I please get a review of this change which fixes build failures on macos > when using `--with-zlib=bundled`? > > With this change the build now passes (tested both with bundled and system > zlib variants). > > tier1, tier2 and tier3 testing has been done and no related failures have > be

Re: RFR: 8286444: javac errors after JDK-8251329 are not helpful enough to find root cause

2022-05-11 Thread Sean Mullan
On Wed, 11 May 2022 05:39:42 GMT, Alan Bateman wrote: > > > It's probably ok, but the bug report is either incomplete or I am missing > > > something. It says "This can be improved to something like: ..." but the > > > same text as is emitted now is used. Can you fix this so I have a better >

  1   2   >