Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v25]

2024-02-24 Thread Thomas Stuefe
On Tue, 20 Feb 2024 09:27:15 GMT, Suchismith Roy wrote: >> J2SE agent does not start and throws error when it tries to find the shared >> library ibm_16_am. >> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load >> fails.It fails to identify the shared library

Re: RFR: JDK-8252802: java launcher should set MALLOCOPTIONS and LDR_CNTRL in order to use 64KB pages on AIX

2024-02-19 Thread Thomas Stuefe
On Mon, 19 Feb 2024 05:52:22 GMT, Varada M wrote: > DeCapo Benchmark Results (3 runs) : > > Before : > = DaCapo 9.12 h2 PASSED in 281402 msec = > = DaCapo 9.12 h2 PASSED in 269818 msec = > = DaCapo 9.12 h2 PASSED in 279279 msec = > > After: > = DaCapo 9.12 h2

Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v23]

2024-02-19 Thread Thomas Stuefe
On Mon, 19 Feb 2024 13:25:28 GMT, Joachim Kern wrote: >> Thanks for the detailed explanation @JoKern65 . Do then in this errno check >> may not be necessary ? or can we still set errno and access it some way ? > > In this special case here I would not use errno, but the string returned in >

Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v22]

2024-02-16 Thread Thomas Stuefe
On Fri, 16 Feb 2024 12:25:39 GMT, Suchismith Roy wrote: > > > > Hi, > > > > some remarks: > > > > > > > > * there is no need for a copy for the first call to dll_load_library. > > > > Just hand in the string 1:1. > > > > * I would only do the *.a fallback loading if the error indicates that >

Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v22]

2024-02-15 Thread Thomas Stuefe
On Thu, 15 Feb 2024 17:50:23 GMT, Suchismith Roy wrote: > > Hi, > > some remarks: > > > > * there is no need for a copy for the first call to dll_load_library. Just > > hand in the string 1:1. > > * I would only do the *.a fallback loading if the error indicates that the > > *.so file had not

Re: RFR: 8325878: Require minimum Clang version 13

2024-02-15 Thread Thomas Stuefe
On Fri, 16 Feb 2024 04:46:24 GMT, Kim Barrett wrote: > > Unfortunately this will break my workflow on Linux - I use clang to build > > on Ubuntu 20.04, which is not that old, but it ships with clang 12. This is > > not a deal breaker, just annoying. > > That's unfortunate, but I think the

Re: RFR: 8314488: Compile the JDK as C++17 [v6]

2024-02-15 Thread Thomas Stuefe
On Mon, 5 Feb 2024 09:44:02 GMT, Magnus Ihse Bursie wrote: > > Sure, you can always install a newer GCC than the system one, but it's > > another thing that makes it harder for people to build OpenJDK. Having said > > that, C++17 is nice to have. > > @theRealAph I am still just hearing

Re: RFR: 8314488: Compile the JDK as C++17 [v6]

2024-02-15 Thread Thomas Stuefe
On Thu, 15 Feb 2024 15:54:56 GMT, Magnus Ihse Bursie wrote: > > I would like it if toolchain version bumps were discussed somewhere else > > first, not in a PR. (And apologies if it was and I missed that discussion). > > Yes, it definitely was. I posted a separate [mail to >

Re: RFR: 8314488: Compile the JDK as C++17 [v6]

2024-02-15 Thread Thomas Stuefe
On Thu, 11 Jan 2024 13:23:45 GMT, Julian Waters wrote: >> Compile the JDK as C++17, enabling the use of all C++17 language features > > Julian Waters has updated the pull request incrementally with one additional > commit since the last revision: > > Require clang 13 in toolchain.m4 Just on

Re: RFR: 8325878: Require minimum Clang version 13

2024-02-15 Thread Thomas Stuefe
On Thu, 15 Feb 2024 05:19:45 GMT, Kim Barrett wrote: > Please review this change that updates the minimum supported version of Clang > to be used for building OpenJDK from 3.5 to 13. > > This permits enabling C++17 (JDK-8314488), though Clang 5 might suffice for > that. A minimum of Clang 13

Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v22]

2024-02-15 Thread Thomas Stuefe
On Mon, 12 Feb 2024 18:04:21 GMT, Suchismith Roy wrote: >> J2SE agent does not start and throws error when it tries to find the shared >> library ibm_16_am. >> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load >> fails.It fails to identify the shared library

Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v13]

2024-02-01 Thread Thomas Stuefe
On Wed, 31 Jan 2024 13:17:21 GMT, Suchismith Roy wrote: >> J2SE agent does not start and throws error when it tries to find the shared >> library ibm_16_am. >> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load >> fails.It fails to identify the shared library

Re: RFR: 8307977: jcmd and jstack broken for target processes running with elevated capabilities

2024-01-30 Thread Thomas Stuefe
On Tue, 30 Jan 2024 10:47:22 GMT, Sebastian Lövdahl wrote: > 8307977: jcmd and jstack broken for target processes running with elevated > capabilities ping @jerboaa - PR Comment: https://git.openjdk.org/jdk/pull/17628#issuecomment-1916676356

Re: RFR: 8324659: GHA: Generic jtreg errors are not reported

2024-01-26 Thread Thomas Stuefe
On Thu, 25 Jan 2024 12:02:35 GMT, Aleksey Shipilev wrote: > When looking at [JDK-8324647](https://bugs.openjdk.org/browse/JDK-8324647), I > was surprised to see that GHA has this output: > > > Running test 'jtreg:test/lib-test:tier1' > /home/runner/work/jdk/jdk/test/lib-test/TEST.groups:

Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v9]

2024-01-26 Thread Thomas Stuefe
On Thu, 25 Jan 2024 11:04:03 GMT, Suchismith Roy wrote: > > For me the unresolved question is still: > > > > * do we want an unconditional load of *.a for a given *.so (have yet to see > > any documentation for this a-file duality) > > Yes. The documentation link - >

Re: jmx-dev RFR: JDK-8324637: [aix] Implement support for reporting swap space in jdk.management

2024-01-25 Thread Thomas Stuefe
On Thu, 25 Jan 2024 12:30:15 GMT, Matthias Baesken wrote: > The get_total_or_available_swap_space_size coding misses AIX support, we only > return 0. This should be enhanced. > The perfstat API can be used, see >

Re: RFR: JDK-8324637: [aix] Implement support for reporting swap space in jdk.management

2024-01-25 Thread Thomas Stuefe
On Thu, 25 Jan 2024 12:30:15 GMT, Matthias Baesken wrote: > The get_total_or_available_swap_space_size coding misses AIX support, we only > return 0. This should be enhanced. > The perfstat API can be used, see >

Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v9]

2024-01-23 Thread Thomas Stuefe
On Tue, 16 Jan 2024 08:36:49 GMT, Suchismith Roy wrote: >> J2SE agent does not start and throws error when it tries to find the shared >> library ibm_16_am. >> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load >> fails.It fails to identify the shared library

Re: RFR: JDK-8323330: [BACKOUT] JDK-8276809: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java shows JNI warning on Windows

2024-01-10 Thread Thomas Stuefe
On Wed, 10 Jan 2024 09:18:53 GMT, Matthias Baesken wrote: > There have been concerns raised about > [JDK-8276809](https://bugs.openjdk.org/browse/JDK-8276809) , so bring back > the old behavior. okay - Marked as reviewed by stuefe (Reviewer). PR Review:

Re: RFR: JDK-8276809: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java shows JNI warning on Windows

2024-01-09 Thread Thomas Stuefe
On Tue, 2 Jan 2024 15:03:12 GMT, Matthias Baesken wrote: > The new test java/awt/font/JNICheck/FreeTypeScalerJNICheck.java introduced > with https://bugs.openjdk.java.net/browse/JDK-8269223 adds -Xcheck:jni , and > shows on Windows server 2019 the following JNI warning , so the test fails on

Re: RFR: JDK-8276809: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java shows JNI warning on Windows

2024-01-08 Thread Thomas Stuefe
On Tue, 2 Jan 2024 15:03:12 GMT, Matthias Baesken wrote: > The new test java/awt/font/JNICheck/FreeTypeScalerJNICheck.java introduced > with https://bugs.openjdk.java.net/browse/JDK-8269223 adds -Xcheck:jni , and > shows on Windows server 2019 the following JNI warning , so the test fails on

Re: RFR: JDK-8320890: [AIX] Find a better way to mimic dl handle equality [v10]

2023-12-22 Thread Thomas Stuefe
On Fri, 22 Dec 2023 14:50:16 GMT, Joachim Kern wrote: >> On AIX, repeated calls to dlopen referring to the same shared library may >> result in different, unique dl handles to be returned from libc. In that it >> differs from typical libc implementations that cache dl handles. >> >> This

Re: RFR: JDK-8320890: [AIX] Find a better way to mimic dl handle equality [v8]

2023-12-21 Thread Thomas Stuefe
On Thu, 21 Dec 2023 11:54:17 GMT, Martin Doerr wrote: >> Dynamic allocation also opens us up to potential initialization issues, >> unless we explicitly use raw ::malloc. It should work, but I think its >> better avoided unless we really need it. > > Well we're fixing an academic issue by

Re: RFR: JDK-8320890: [AIX] Find a better way to mimic dl handle equality [v8]

2023-12-21 Thread Thomas Stuefe
On Thu, 21 Dec 2023 11:23:46 GMT, Joachim Kern wrote: >> I don't like introducing unnecessary limitations. Are we sure nobody will >> ever need more than 1024 handles? >> Can't we at least use a GrowableArray or something like that? > > In principle you are right, but in my opinion 1024 is an

Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v7]

2023-12-21 Thread Thomas Stuefe
On Thu, 21 Dec 2023 09:37:55 GMT, Suchismith Roy wrote: > > > > What happens if we accidentally attempt to load a "real" static > > > > library, which is also named *.a? Would dlopen() then crash? What would > > > > happen? > > > > > > > I don't think the problem is with *.a . They would

Re: RFR: JDK-8320890: [AIX] Find a better way to mimic dl handle equality [v8]

2023-12-21 Thread Thomas Stuefe
On Thu, 21 Dec 2023 09:37:57 GMT, Joachim Kern wrote: >> src/hotspot/os/aix/porting_aix.cpp line 916: >> >>> 914: constexpr int max_handletable = 1024; >>> 915: static int g_handletable_used = 0; >>> 916: static struct handletableentry g_handletable[max_handletable] = {{0, >>> 0, 0, 0}}; >>

Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v7]

2023-12-21 Thread Thomas Stuefe
On Thu, 21 Dec 2023 08:16:22 GMT, Suchismith Roy wrote: >> What happens if we accidentally attempt to load a "real" static library, >> which is also named *.a? Would dlopen() then crash? What would happen? > I don't think the problem is with *.a . They would load as the default > behaviour of

Re: RFR: JDK-8320890: [AIX] Find a better way to mimic dl handle equality [v8]

2023-12-20 Thread Thomas Stuefe
On Wed, 20 Dec 2023 14:53:06 GMT, Joachim Kern wrote: >> On AIX, repeated calls to dlopen referring to the same shared library may >> result in different, unique dl handles to be returned from libc. In that it >> differs from typical libc implementations that cache dl handles. >> >> This

Re: RFR: JDK-8320005 : Native library suffix impact on hotspot code in AIX [v7]

2023-12-20 Thread Thomas Stuefe
On Wed, 20 Dec 2023 11:16:03 GMT, Suchismith Roy wrote: >> J2SE agent does not start and throws error when it tries to find the shared >> library ibm_16_am. >> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load >> fails.It fails to identify the shared library

Re: RFR: 8314488: Compile the JDK as C++17 [v2]

2023-12-20 Thread Thomas Stuefe
On Fri, 15 Dec 2023 16:20:02 GMT, Kim Barrett wrote: >> Julian Waters has updated the pull request with a new target base due to a >> merge or a rebase. The incremental webrev excludes the unrelated changes >> brought in by the merge/rebase. The pull request contains five additional >>

Re: RFR: 8322417: Console read line with zero out should zero out when throwing exception

2023-12-19 Thread Thomas Stuefe
On Tue, 19 Dec 2023 12:47:53 GMT, Goetz Lindenmaier wrote: > …g exception > > After leaving the method by throwing an exception the data can not be cleaned > any more. Seems reasonable. - Marked as reviewed by stuefe (Reviewer). PR Review:

Re: RFR: JDK-8320890: [AIX] Find a better way to mimic dl handle equality [v4]

2023-12-19 Thread Thomas Stuefe
On Tue, 19 Dec 2023 12:37:33 GMT, Suchismith Roy wrote: >> The libpath parsing code is from me, so no license problems. > > Hi @JoKern65 Is this good to integrate now ? @suchismith1993 > Once this code goes in I can push in my changes. We are targeting the fix for > January. If you talk

Re: RFR: JDK-8320890: [AIX] Find a better way to mimic dl handle equality [v6]

2023-12-19 Thread Thomas Stuefe
On Mon, 18 Dec 2023 13:33:46 GMT, Thomas Stuefe wrote: >> Joachim Kern has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Followed Thomas proposals > > Well done. > > Releasing the mutex before asser

Re: RFR: JDK-8320890: [AIX] Find a better way to mimic dl handle equality [v5]

2023-12-18 Thread Thomas Stuefe
On Mon, 18 Dec 2023 11:12:23 GMT, Joachim Kern wrote: >> src/hotspot/os/aix/porting_aix.cpp line 1097: >> >>> 1095: } >>> 1096: >>> 1097: pthread_mutex_lock(_handletable_mutex); >> >> You can make your life a lot easier by defining an RAII object at the start >> of the file: >> >>

Re: RFR: JDK-8320890: [AIX] Find a better way to mimic dl handle equality [v5]

2023-12-18 Thread Thomas Stuefe
On Mon, 18 Dec 2023 10:35:48 GMT, Joachim Kern wrote: >> src/hotspot/os/aix/porting_aix.cpp line 990: >> >>> 988: if (env == nullptr) { >>> 989: // no LIBPATH, try with LD_LIBRARY_PATH >>> 990: env = getenv("LD_LIBRARY_PATH"); >> >> Is LD_LIBRARY_PATH a thing on AIX? I thought it is

Re: RFR: JDK-8320890: [AIX] Find a better way to mimic dl handle equality [v6]

2023-12-18 Thread Thomas Stuefe
On Mon, 18 Dec 2023 11:30:59 GMT, Joachim Kern wrote: >> On AIX, repeated calls to dlopen referring to the same shared library may >> result in different, unique dl handles to be returned from libc. In that it >> differs from typical libc implementations that cache dl handles. >> >> This

Re: RFR: JDK-8320890: [AIX] Find a better way to mimic dl handle equality [v5]

2023-12-18 Thread Thomas Stuefe
On Mon, 18 Dec 2023 10:06:34 GMT, Thomas Stuefe wrote: >> Joachim Kern has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - trailing whitespace >> - Following most of Thomas proposals > > src/hot

Re: RFR: JDK-8320890: [AIX] Find a better way to mimic dl handle equality [v5]

2023-12-18 Thread Thomas Stuefe
On Fri, 15 Dec 2023 11:57:51 GMT, Joachim Kern wrote: >> On AIX, repeated calls to dlopen referring to the same shared library may >> result in different, unique dl handles to be returned from libc. In that it >> differs from typical libc implementations that cache dl handles. >> >> This

Re: RFR: JDK-8320890: [AIX] Find a better way to mimic dl handle equality [v4]

2023-12-15 Thread Thomas Stuefe
On Fri, 15 Dec 2023 10:18:53 GMT, Joachim Kern wrote: >> src/hotspot/os/aix/os_aix.cpp line 206: >> >>> 204: constexpr int max_handletable = 1024; >>> 205: static int g_handletable_used = 0; >>> 206: static struct handletableentry g_handletable[max_handletable] = {{0, >>> 0, 0, 0}}; >> >> I

Re: RFR: JDK-8320890: [AIX] Find a better way to mimic dl handle equality [v4]

2023-12-15 Thread Thomas Stuefe
On Fri, 15 Dec 2023 09:57:19 GMT, Joachim Kern wrote: > If we omit the xcoff32 we have to ensure that no xcoff32 executable file > comes into play. xcoff32 is for 32-bit binaries. The AIX port only exists for 64-bit, and there will never be a 32-bit AIX port, so there is no reason for

Re: RFR: JDK-8320890: [AIX] Find a better way to mimic dl handle equality [v4]

2023-12-14 Thread Thomas Stuefe
On Fri, 15 Dec 2023 06:22:39 GMT, Thomas Stuefe wrote: >> Joachim Kern has updated the pull request incrementally with one additional >> commit since the last revision: >> >> followed the proposals > > src/hotspot/os/aix/os_aix.cpp line 1129: > >> 11

Re: RFR: JDK-8320890: [AIX] Find a better way to mimic dl handle equality [v4]

2023-12-14 Thread Thomas Stuefe
On Tue, 12 Dec 2023 14:05:48 GMT, Joachim Kern wrote: >> On AIX, repeated calls to dlopen referring to the same shared library may >> result in different, unique dl handles to be returned from libc. In that it >> differs from typical libc implementations that cache dl handles. >> >> This

Re: RFR: JDK-8320890: [AIX] Find a better way to mimic dl handle equality [v3]

2023-12-05 Thread Thomas Stuefe
On Tue, 5 Dec 2023 13:21:35 GMT, Thomas Stuefe wrote: >> Joachim Kern has updated the pull request incrementally with one additional >> commit since the last revision: >> >> encapsulate everything in os::Aix::dlopen > > src/hotspot/os/aix/os_aix.cpp line 31

Re: RFR: JDK-8320890: [AIX] Find a better way to mimic dl handle equality [v2]

2023-12-05 Thread Thomas Stuefe
On Mon, 4 Dec 2023 12:33:26 GMT, Joachim Kern wrote: >> On AIX, repeated calls to dlopen referring to the same shared library may >> result in different, unique dl handles to be returned from libc. In that it >> differs from typical libc implementations that cache dl handles. >> >> This

Re: RFR: JDK-8320890: [AIX] Find a better way to mimic dl handle equality [v3]

2023-12-05 Thread Thomas Stuefe
On Tue, 5 Dec 2023 12:11:46 GMT, Joachim Kern wrote: >> On AIX, repeated calls to dlopen referring to the same shared library may >> result in different, unique dl handles to be returned from libc. In that it >> differs from typical libc implementations that cache dl handles. >> >> This

Re: RFR: 8313816: Accessing jmethodID might lead to spurious crashes [v11]

2023-12-04 Thread Thomas Stuefe
On Mon, 4 Dec 2023 00:41:23 GMT, David Holmes wrote: > From the blog: > > > Yes! The methods are being deallocated for a class loader that is still > > alive. > > Okay so why does this happen and is it a reasonable thing to be happening? On > the surface it sounds wrong to deallocate

Re: RFR: 8320935: Move CDS config initialization code to cdsConfig.cpp [v2]

2023-12-01 Thread Thomas Stuefe
On Sat, 2 Dec 2023 00:38:58 GMT, Ioi Lam wrote: >> This is a simple clean up that moves the code for initializing the CDS >> config states from arguments.cpp to cdsConfig.cpp >> >> I renamed a few functions, but otherwise the code is unchanged. >> >> - `get_default_shared_archive_path()` ->

Re: RFR: 8313816: Accessing jmethodID might lead to spurious crashes [v11]

2023-11-30 Thread Thomas Stuefe
On Wed, 29 Nov 2023 11:49:31 GMT, Jaroslav Bachorik wrote: >> Please, review this fix for a corner case handling of `jmethodID` values. >> >> The issue is related to the interplay between `jmethodID` values and method >> redefinitions. Each `jmethodID` value is effectively a pointer to a

Re: RFR: 8320921: GHA: Parallelize hotspot_compiler test jobs

2023-11-29 Thread Thomas Stuefe
On Tue, 28 Nov 2023 18:15:56 GMT, Aleksey Shipilev wrote: > In current GHA, `hotspot_compiler` testing takes a long time, and often takes > the longest. On MacOS and Windows it routinely takes 60..80 minutes, while > other test groups run in 30..40 minutes. This often drags the total wall >

Re: RFR: JDK-8320005 : Native library suffix impact on hotspot code in AIX [v2]

2023-11-28 Thread Thomas Stuefe
On Tue, 28 Nov 2023 11:27:33 GMT, suchismith1993 wrote: > > > > @tstuefe 3rd parameter to pass the either of 2 things: > > 1. The JvmTiAgent object "agent", so that after shifting the > save_library_signature to os_aix,we can still access the agent object.-> For > this i tried importing

Re: RFR: JDK-8320005 : Native library suffix impact on hotspot code in AIX [v2]

2023-11-28 Thread Thomas Stuefe
On Mon, 27 Nov 2023 15:44:58 GMT, suchismith1993 wrote: > > > > i would have to repeat the line 1132 and 1139 in os_aix.cpp again , if > > > > the condition fails for .so files, because i have to reload it again > > > > and check if the .a exists. In the shared code i had repeat less number >

Re: RFR: JDK-8315706: com/sun/tools/attach/warnings/DynamicLoadWarningTest.java real fix for failure on AIX [v5]

2023-11-27 Thread Thomas Stuefe
On Mon, 27 Nov 2023 13:23:42 GMT, Thomas Stuefe wrote: >> Joachim Kern has updated the pull request incrementally with one additional >> commit since the last revision: >> >> adopt types > > This now causes problems with > > https://github.com/openjdk/jd

Re: RFR: JDK-8315706: com/sun/tools/attach/warnings/DynamicLoadWarningTest.java real fix for failure on AIX [v5]

2023-11-27 Thread Thomas Stuefe
On Fri, 15 Sep 2023 07:22:32 GMT, Joachim Kern wrote: >> After push of [JDK-8307478](https://bugs.openjdk.org/browse/JDK-8307478) , >> the following test started to fail on AIX : >> com/sun/tools/attach/warnings/DynamicLoadWarningTest.java; >> The problem was described in >>

Re: RFR: 8320699: Add parameter to skip progress logging of OutputAnalyzer

2023-11-24 Thread Thomas Stuefe
On Fri, 24 Nov 2023 10:34:02 GMT, Stefan Karlsson wrote: > Tests using ProcessTools.executeProcess gets the following output written to > stdout: > [2023-11-24T09:58:16.797540608Z] Gathering output for process 2517117 > [2023-11-24T09:58:23.070781345Z] Waiting for completion for process 2517117

Re: RFR: JDK-8320005 : Native library suffix impact on hotspot code in AIX [v2]

2023-11-24 Thread Thomas Stuefe
On Fri, 24 Nov 2023 11:45:25 GMT, suchismith1993 wrote: > > i would have to repeat the line 1132 and 1139 in os_aix.cpp again , if the > > condition fails for .so files, because i have to reload it again and check > > if the .a exists. In the shared code i had repeat less number of lines i >

Re: RFR: 8320691: Timeout handler on Windows takes 2 hours to complete [v2]

2023-11-24 Thread Thomas Stuefe
On Fri, 24 Nov 2023 09:51:07 GMT, Daniel Jeliński wrote: >> test/failure_handler/src/share/conf/windows.properties line 60: >> >>> 58: >>> 59: native.core.app=cdb >>> 60: native.core.args=-c ".dump /ma core.%p;qd" -p %p >> >> Just to double check that this is the right option. `/ma`

Re: RFR: 8320691: Timeout handler on Windows takes 2 hours to complete [v2]

2023-11-24 Thread Thomas Stuefe
On Fri, 24 Nov 2023 09:51:07 GMT, Daniel Jeliński wrote: >> test/failure_handler/src/share/conf/windows.properties line 60: >> >>> 58: >>> 59: native.core.app=cdb >>> 60: native.core.args=-c ".dump /ma core.%p;qd" -p %p >> >> Just to double check that this is the right option. `/ma`

Re: RFR: 8320691: Timeout handler on Windows takes 2 hours to complete

2023-11-24 Thread Thomas Stuefe
On Fri, 24 Nov 2023 07:58:18 GMT, Daniel Jeliński wrote: > The recent cdb versions do not support `.dump /f`: > > * > * .dump /f is not supported on a user mode process. * > *

Re: RFR: 8320691: Timeout handler on Windows takes 2 hours to complete

2023-11-24 Thread Thomas Stuefe
On Fri, 24 Nov 2023 07:58:18 GMT, Daniel Jeliński wrote: > The recent cdb versions do not support `.dump /f`: > > * > * .dump /f is not supported on a user mode process. * > *

Re: RFR: 8313816: Accessing jmethodID might lead to spurious crashes [v8]

2023-11-23 Thread Thomas Stuefe
On Thu, 23 Nov 2023 16:42:35 GMT, Jaroslav Bachorik wrote: >> Please, review this fix for a corner case handling of `jmethodID` values. >> >> The issue is related to the interplay between `jmethodID` values and method >> redefinitions. Each `jmethodID` value is effectively a pointer to a

Re: RFR: JDK-8320005 : Native library suffix impact on hotspot code in AIX [v2]

2023-11-23 Thread Thomas Stuefe
On Thu, 23 Nov 2023 17:05:29 GMT, suchismith1993 wrote: > > I'm not a big fan of this approach. We accumulate more and more "#ifdef > > AIX" in shared code because of many recent AIX additions. No other platform > > has such a large ifdef footprint in shared code. > > I argue that all of this

Re: RFR: 8313816: Accessing jmethodID might lead to spurious crashes [v2]

2023-11-23 Thread Thomas Stuefe
On Thu, 23 Nov 2023 14:15:54 GMT, Thomas Stuefe wrote: >> @dholmes-ora >>> Can't we just check method->method_holder() for null rather than passing in >>> a parameter like this? >> >> I have removed the argument and I am now performing the ch

Re: RFR: 8313816: Accessing jmethodID might lead to spurious crashes [v6]

2023-11-23 Thread Thomas Stuefe
On Thu, 23 Nov 2023 13:37:41 GMT, Jaroslav Bachorik wrote: >> Please, review this fix for a corner case handling of `jmethodID` values. >> >> The issue is related to the interplay between `jmethodID` values and method >> redefinitions. Each `jmethodID` value is effectively a pointer to a

Re: RFR: 8313816: Accessing jmethodID might lead to spurious crashes [v2]

2023-11-23 Thread Thomas Stuefe
On Thu, 23 Nov 2023 08:44:08 GMT, Jaroslav Bachorik wrote: >> Jaroslav Bachorik has updated the pull request incrementally with three >> additional commits since the last revision: >> >> - Clean up imports >> - Simplify Method::clear_jmethod_id() >> - Use correct copyrights > >

Re: RFR: JDK-8320005 : Native library suffix impact on hotspot code in AIX [v2]

2023-11-22 Thread Thomas Stuefe
On Thu, 23 Nov 2023 05:55:28 GMT, Thomas Stuefe wrote: >> suchismith1993 has updated the pull request incrementally with one >> additional commit since the last revision: >> >> change macro position > > src/hotspot/os/aix/os_aix.cpp line 3069: > >&g

Re: RFR: JDK-8320005 : Native library suffix impact on hotspot code in AIX [v2]

2023-11-22 Thread Thomas Stuefe
On Wed, 22 Nov 2023 16:24:24 GMT, suchismith1993 wrote: >> J2SE agent does not start and throws error when it tries to find the shared >> library ibm_16_am. >> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load >> fails.It fails to identify the shared library

Re: RFR: JDK-8320005 : Native library suffix impact on hotspot code in AIX [v2]

2023-11-22 Thread Thomas Stuefe
On Wed, 22 Nov 2023 16:24:24 GMT, suchismith1993 wrote: >> JDK-8320005 : Native library suffix impact on hotspot code in AIX > > suchismith1993 has updated the pull request incrementally with one additional > commit since the last revision: > > change macro position Hi, is this patch meant

Re: RFR: JDK-8320309: AIX: pthreads created by foreign test library don't work as expected

2023-11-22 Thread Thomas Stuefe
On Tue, 21 Nov 2023 10:09:04 GMT, Varada M wrote: > Following test fails due to missing pthread attributes on AIX : > java/foreign/TestUpcallAsync.java > java/foreign/stackwalk/TestAsyncStackWalk.java > java/foreign/loaderLookup/TestLoaderLookupJNI.java >

Re: RFR: 8320219: Actually resolve issues with goto labels in sspi [v3]

2023-11-17 Thread Thomas Stuefe
On Thu, 16 Nov 2023 04:40:53 GMT, Julian Waters wrote: >> I regret not actually addressing the issues with the goto labels in >> https://github.com/openjdk/jdk/pull/15996, where initialization of locals in >> sspi were jumped over by gotos to a certain label. I changed the >> initializations

Re: RFR: 8320219: Actually resolve issues with goto labels in sspi [v3]

2023-11-17 Thread Thomas Stuefe
On Fri, 17 Nov 2023 14:04:07 GMT, Julian Waters wrote: > > Can you please describe the problem you are trying to solve, and why you > > think it is worth solving. You describe the thought process you went > > through while doing the patch and possibly some other, older patch. As it > > is,

Re: RFR: 8320219: Actually resolve issues with goto labels in sspi [v3]

2023-11-17 Thread Thomas Stuefe
On Thu, 16 Nov 2023 04:40:53 GMT, Julian Waters wrote: >> I regret not actually addressing the issues with the goto labels in >> https://github.com/openjdk/jdk/pull/15996, I've as such fixed the issues >> with them properly this time, by simply deleting the labels and duplicating >> the code

Re: RFR: 8320053: GHA: Cross-compile gtest code [v2]

2023-11-15 Thread Thomas Stuefe
On Tue, 14 Nov 2023 11:04:43 GMT, Aleksey Shipilev wrote: >> Looking at why GHA did not catch >> [JDK-8320050](https://bugs.openjdk.org/browse/JDK-8320050), even though it >> builds hotspot, I realized we do not configure the build with gtest, which >> means we skip the build checks for gtest

Integrated: JDK-8318671: Potential uninitialized uintx value after JDK-8317683

2023-11-15 Thread Thomas Stuefe
On Tue, 24 Oct 2023 07:08:07 GMT, Thomas Stuefe wrote: > When using 'MemStat' CompileCommand, we accidentally register the command if > an invalid suboption had been specified. Fixed, added regression test > (verified). This pull request has now been integrated. Changeset: 2e34a2

Re: RFR: JDK-8318671: Potential uninitialized uintx value after JDK-8317683 [v6]

2023-11-15 Thread Thomas Stuefe
On Wed, 15 Nov 2023 06:22:58 GMT, Thomas Stuefe wrote: >> When using 'MemStat' CompileCommand, we accidentally register the command if >> an invalid suboption had been specified. Fixed, added regression test >> (verified). > > Thomas Stuefe has updated the pull reques

Re: RFR: JDK-8318671: Potential uninitialized uintx value after JDK-8317683 [v6]

2023-11-14 Thread Thomas Stuefe
> When using 'MemStat' CompileCommand, we accidentally register the command if > an invalid suboption had been specified. Fixed, added regression test > (verified). Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: feedb

Re: RFR: JDK-8318671: Potential uninitialized uintx value after JDK-8317683 [v5]

2023-11-14 Thread Thomas Stuefe
On Tue, 14 Nov 2023 15:03:42 GMT, Aleksey Shipilev wrote: >> Thomas Stuefe has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains six commits: >> >> - Merge branch 'master' into >> JDK-8318671-Potential-u

Re: RFR: JDK-8318671: Potential uninitialized uintx value after JDK-8317683 [v5]

2023-11-14 Thread Thomas Stuefe
On Mon, 13 Nov 2023 13:33:26 GMT, Thomas Stuefe wrote: >> When using 'MemStat' CompileCommand, we accidentally register the command if >> an invalid suboption had been specified. Fixed, added regression test >> (verified). > > Thomas Stuefe has updated the pull reques

Re: RFR: JDK-8318671: Potential uninitialized uintx value after JDK-8317683 [v5]

2023-11-13 Thread Thomas Stuefe
> When using 'MemStat' CompileCommand, we accidentally register the command if > an invalid suboption had been specified. Fixed, added regression test > (verified). Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now con

Re: RFR: JDK-8318671: Potential uninitialized uintx value after JDK-8317683 [v4]

2023-11-13 Thread Thomas Stuefe
On Mon, 13 Nov 2023 11:51:30 GMT, Tobias Hartmann wrote: > I think this is ready for integration given that both @dholmes-ora and > @jdksjolen are okay with it. Well, they did not approve yet; @jdksjolen or @dholmes-ora, if you are happy with this, could you hit the big green button please?

Integrated: JDK-8318636: Add jcmd to print annotated process memory map

2023-11-13 Thread Thomas Stuefe
On Sun, 22 Oct 2023 10:08:49 GMT, Thomas Stuefe wrote: > Analysts and supporters often use /proc/xx/maps to make sense of the memory > footprint of a process. > > Interpreting the memory map correctly can help when used as a complement to > other tools (e.g. NMT). There even

Re: RFR: JDK-8318636: Add jcmd to print annotated process memory map [v12]

2023-11-10 Thread Thomas Stuefe
On Fri, 10 Nov 2023 09:45:11 GMT, Johan Sjölen wrote: > Hi Thomas, > > Thanks for your hard work on this! LGTM. Thank you for your Review, Johan! - PR Comment: https://git.openjdk.org/jdk/pull/16301#issuecomment-1805489022

Re: RFR: JDK-8318636: Add jcmd to print annotated process memory map [v9]

2023-11-09 Thread Thomas Stuefe
On Thu, 9 Nov 2023 07:03:34 GMT, David Holmes wrote: >>> > As this adds a JCmd, doesn't this need both a CSR and a manual entry? >>> >>> * CSR: not sure; there are precedences for going with CSR and without >>> CSR. Since we get awfully close to JDK22 freeze, I would prefer for a CSR >>>

Re: RFR: JDK-8318636: Add jcmd to print annotated process memory map [v12]

2023-11-09 Thread Thomas Stuefe
e run): > > [example_system_map.txt](https://github.com/openjdk/jdk/files/13179054/example_system_map.txt) > > This patch adds the VM annotations for VMAs that are *mmaped*. I also have an > experimental patch that works with malloc'ed memory, but it is not ready yet > for

Re: RFR: JDK-8318636: Add jcmd to print annotated process memory map [v9]

2023-11-09 Thread Thomas Stuefe
On Thu, 9 Nov 2023 07:27:37 GMT, David Holmes wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Fix another windows error > > src/hotspot/share/services/diagnosticCommand.cpp lin

Re: RFR: JDK-8318636: Add jcmd to print annotated process memory map [v11]

2023-11-09 Thread Thomas Stuefe
e run): > > [example_system_map.txt](https://github.com/openjdk/jdk/files/13179054/example_system_map.txt) > > This patch adds the VM annotations for VMAs that are *mmaped*. I also have an > experimental patch that works with malloc'ed memory, but it is not ready yet > for

Re: RFR: JDK-8318636: Add jcmd to print annotated process memory map [v10]

2023-11-09 Thread Thomas Stuefe
e run): > > [example_system_map.txt](https://github.com/openjdk/jdk/files/13179054/example_system_map.txt) > > This patch adds the VM annotations for VMAs that are *mmaped*. I also have an > experimental patch that works with malloc'ed memory, but it is not ready yet > for

Re: RFR: JDK-8318636: Add jcmd to print annotated process memory map [v9]

2023-11-08 Thread Thomas Stuefe
On Thu, 9 Nov 2023 07:03:34 GMT, David Holmes wrote: > > > > As this adds a JCmd, doesn't this need both a CSR and a manual entry? > > > > > > > > > ``` > > > * CSR: not sure; there are precedences for going with CSR and without > > > CSR. Since we get awfully close to JDK22 freeze, I would

Re: RFR: JDK-8318636: Add jcmd to print annotated process memory map [v9]

2023-11-08 Thread Thomas Stuefe
On Wed, 8 Nov 2023 09:51:12 GMT, Johan Sjölen wrote: > As this adds a JCmd, doesn't this need both a CSR and a manual entry? - CSR: not sure; there are precedences for going with CSR and without CSR. Since we get awfully close to JDK22 freeze, I would prefer for a CSR not to be needed. Also

Re: RFR: JDK-8318636: Add jcmd to print annotated process memory map [v6]

2023-11-04 Thread Thomas Stuefe
On Wed, 1 Nov 2023 10:04:30 GMT, Johan Sjölen wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional >> commit since the last revision: >> >> fix various builds > > OK, went through the cache. Will continue later. @jdksjolen any

Re: RFR: JDK-8313790: [arm32] Specify -marm when building without an ABI profile [v2]

2023-11-04 Thread Thomas Stuefe
ause really rare but > tricky problems when combining static assembly and C++ code (See e.g. > JDK-8288719). > > I propose to always specify `-marm` as default, unless an ABI profile is > given, to prevent such errors. > > Thanks to @marchof for testing this. Thomas Stuefe has

Re: RFR: JDK-8318636: Add jcmd to print annotated process memory map [v9]

2023-11-03 Thread Thomas Stuefe
On Thu, 2 Nov 2023 17:42:29 GMT, Thomas Stuefe wrote: >> Analysts and supporters often use /proc/xx/maps to make sense of the memory >> footprint of a process. >> >> Interpreting the memory map correctly can help when used as a complement to >> other tools (e.g

Re: RFR: JDK-8318636: Add jcmd to print annotated process memory map [v6]

2023-11-02 Thread Thomas Stuefe
On Thu, 2 Nov 2023 15:25:14 GMT, Brice Dutheil wrote: >> This prints protection and offset. The former is interesting for obvious >> reasons (e.g. lets you tell apart stack guard regions from stack, or >> uncommitted from committed regions) and the latter interesting for some >> corner cases

Re: RFR: JDK-8318636: Add jcmd to print annotated process memory map [v9]

2023-11-02 Thread Thomas Stuefe
e run): > > [example_system_map.txt](https://github.com/openjdk/jdk/files/13179054/example_system_map.txt) > > This patch adds the VM annotations for VMAs that are *mmaped*. I also have an > experimental patch that works with malloc'ed memory, but it is not ready yet > for

Re: RFR: JDK-8318636: Add jcmd to print annotated process memory map [v8]

2023-11-02 Thread Thomas Stuefe
e run): > > [example_system_map.txt](https://github.com/openjdk/jdk/files/13179054/example_system_map.txt) > > This patch adds the VM annotations for VMAs that are *mmaped*. I also have an > experimental patch that works with malloc'ed memory, but it is not ready yet > for

Re: RFR: JDK-8318636: Add jcmd to print annotated process memory map [v7]

2023-11-02 Thread Thomas Stuefe
On Wed, 1 Nov 2023 15:38:46 GMT, Gerard Ziemski wrote: > LGTM > > Thank you for doing this! Thank you for reviewing, @gerard-ziemski ! - PR Comment: https://git.openjdk.org/jdk/pull/16301#issuecomment-1790665200

Re: RFR: JDK-8318636: Add jcmd to print annotated process memory map [v6]

2023-11-02 Thread Thomas Stuefe
On Wed, 1 Nov 2023 10:04:04 GMT, Johan Sjölen wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional >> commit since the last revision: >> >> fix various builds > > src/hotspot/share/nmt/memMapPrinter.cpp line 119: > >

Re: RFR: JDK-8318636: Add jcmd to print annotated process memory map [v6]

2023-11-02 Thread Thomas Stuefe
On Wed, 1 Nov 2023 10:46:21 GMT, Johan Sjölen wrote: >> Yes, it resulted in a significant performance gain for a test run where I >> interleaved non-committed and committed memory of the same tag. I may have >> been mistaken, of course. > > It being committed or reserved shouldn't matter (I

Re: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on the Microsoft Visual C compiler [v13]

2023-11-02 Thread Thomas Stuefe
On Thu, 2 Nov 2023 11:02:27 GMT, Julian Waters wrote: >> We should set the -permissive- flag for the Microsoft Visual C compiler, as >> was requested by the now backed out >> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes >> the Visual C compiler much less

Re: RFR: 8295159: DSO created with -ffast-math breaks Java floating-point arithmetic [v18]

2023-11-02 Thread Thomas Stuefe
On Fri, 27 Oct 2023 11:59:59 GMT, Andrew Haley wrote: >> A bug in GCC causes shared libraries linked with -ffast-math to disable >> denormal arithmetic. This breaks Java's floating-point semantics. >> >> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522 >> >> One solution is to

Re: RFR: JDK-8318636: Add jcmd to print annotated process memory map [v6]

2023-11-01 Thread Thomas Stuefe
On Wed, 1 Nov 2023 10:01:43 GMT, Johan Sjölen wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional >> commit since the last revision: >> >> fix various builds > > src/hotspot/share/nmt/memMapPrinter.cpp line 105: >

<    1   2   3   4   5   6   7   8   9   10   >