On Wed, 29 May 2024 09:09:16 GMT, Matthias Baesken wrote:
> When running with ubsan - enabled binaries (--enable-ubsan),
> in the vmTestbase/nsk/jdi tests some cases of memset on nullptr destinations
> are detected in get_object_monitor_usage .
>
> // null out memory for robustness
>
On Wed, 29 May 2024 09:09:16 GMT, Matthias Baesken wrote:
> When running with ubsan - enabled binaries (--enable-ubsan),
> in the vmTestbase/nsk/jdi tests some cases of memset on nullptr destinations
> are detected in get_object_monitor_usage .
>
> // null out memory for robustness
>
On Wed, 20 Mar 2024 14:02:23 GMT, Richard Reingruber wrote:
>> This pr changes `JfrJvmtiAgent::retransform_classes()` and
>> `jfr_set_enabled` to switch to `WXWrite` before transitioning to the vm.
>>
>> Testing:
>> make test TEST=jdk/jfr/event/runtime/TestClassLoadEvent.java
>>
On Mon, 18 Mar 2024 13:14:41 GMT, Richard Reingruber wrote:
>> This pr changes `JfrJvmtiAgent::retransform_classes()` and
>> `jfr_set_enabled` to switch to `WXWrite` before transitioning to the vm.
>>
>> Testing:
>> make test TEST=jdk/jfr/event/runtime/TestClassLoadEvent.java
>>
On Tue, 27 Feb 2024 08:31: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
On Tue, 27 Feb 2024 07:48:00 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
On Mon, 19 Feb 2024 17:16:34 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
On Mon, 19 Feb 2024 10:05:17 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
On Thu, 1 Feb 2024 10:31:14 GMT, Thomas Stuefe wrote:
>> Suchismith Roy has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> spelling
>
> I'm busy with FOSDEM this week and probably next. Will look at this end of
> next week or the week
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
On Thu, 8 Feb 2024 10:26:05 GMT, Suchismith Roy wrote:
> > The trailing whitespace errors must get fixed (integration blocker).
>
> I am unable to resolve this. The spaces seem fine as i see it in the
> terminal. Could it be some other error ?
Strange. I don't see any whitespace problem,
On Tue, 6 Feb 2024 08:45:12 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
On Wed, 31 Jan 2024 11:22:27 GMT, Joachim Kern wrote:
>> The load library gets the entire library name, after construction from
>> dll_build_name. This is always a .so file name. When .so file name fails to
>> load, we fallback to .a filename.
>> Do i need to mention the filename as
On Mon, 5 Feb 2024 08:52: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
On Thu, 1 Feb 2024 09:42:00 GMT, Suchismith Roy wrote:
>> In addition, the nullptr check is important to avoid undefined behavior when
>> passing `pointer_to_dot` to any string function.
>
> Ok. So then may be we can return a nullptr and do a log_info(os) with the
> correct error report ?
On Thu, 1 Feb 2024 04:13:52 GMT, Martin Doerr wrote:
>> I didn't follow that. You mean i need to keep a check if it is null and
>> print it out ?
>
> An assertion is only used for debug builds. Such an error should be handled
> in product builds as well. I think an attem
On Wed, 31 Jan 2024 15:06:54 GMT, Suchismith Roy wrote:
>> src/hotspot/os/aix/os_aix.cpp line 1176:
>>
>>> 1174: strncpy(file_path,filename, buffer_length + 1);
>>> 1175: char* const pointer_to_dot = strrchr(file_path, '.');
>>> 1176: assert(pointer_to_dot != nullptr, "Attempting to load
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
On Tue, 30 Jan 2024 14:02:41 GMT, Matthias Baesken wrote:
>>> Yes there is a nice define in the AIX header
>>
>> *sigh* On linux, they go to some lengths to avoid this, using a __REDEFINE
>> mechanism. Oh well.
>>
>> Anyway, I think this particular can be resolved by not including the
>>
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
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
On Fri, 5 Jan 2024 12:10:59 GMT, Martin Doerr wrote:
> I have tried to build jextract
> (https://github.com/openjdk/jextract/tree/jdk22) with LLVM
> (https://github.com/llvm/llvm-project/releases/download/llvmorg-16.0.4/clang+llvm-16.0.4-powerpc64-ibm-aix-7.2.tar.xz).
> I notic
On Wed, 10 Jan 2024 11:49:05 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
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
On Fri, 22 Dec 2023 15:57:05 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
On Thu, 21 Dec 2023 11:45:36 GMT, Thomas Stuefe wrote:
>> In principle you are right, but in my opinion 1024 is an academical limit. I
>> never saw processes with more than a few dozen loaded libraries.
>
> Dynamic allocation also opens us up to potential initialization issues,
> unless we
On Thu, 21 Dec 2023 09:57:08 GMT, Thomas Stuefe wrote:
>> There will be only few libraries in the list. With this assumption Thomas
>> suggested to use just a simple array.
>
> Let's keep it simple. A linear array of only a few items is easily scanned,
> probably faster than pointer hopping
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
On Mon, 18 Dec 2023 10:25:57 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/hotspot/os/aix/os_aix.cpp line 1113:
>
>>
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
On Tue, 26 Sep 2023 11:41:52 GMT, Fredrik Bredberg
wrote:
>> Relativize initial_sp in interpreter frames.
>>
>> By changing the "initial_sp" (AKA "monitor_block_top" or "monitors" on
>> PowerPC) member in interpreter frames from being an absolute address into an
>> offset that is relative to
On Tue, 19 Sep 2023 09:00:01 GMT, Fredrik Bredberg
wrote:
> Relativize initial_sp in interpreter frames.
>
> By changing the "initial_sp" (AKA "monitor_block_top" or "monitors" on
> PowerPC) member in interpreter frames from being an absolute address into an
> offset that is relative to the
On Tue, 19 Sep 2023 09:00:01 GMT, Fredrik Bredberg
wrote:
> Relativize initial_sp in interpreter frames.
>
> By changing the "initial_sp" (AKA "monitor_block_top" or "monitors" on
> PowerPC) member in interpreter frames from being an absolute address into an
> offset that is relative to the
On Wed, 16 Aug 2023 08:09:42 GMT, Matthias Baesken wrote:
> AttachListener::pd_set_flag is the same across platforms (always returning
> JNI_ERR ). So it can be centralized or removed.
Nice cleanup!
-
Marked as reviewed by mdoerr (Reviewer).
PR Review:
On Fri, 23 Jun 2023 02:43:38 GMT, Julian Waters wrote:
>> C11 has been stable for a long time on all platforms, so native code can use
>> the standard alignas operator for alignment requirements
>
> Julian Waters has updated the pull request with a new target base due to a
> merge or a rebase.
On Mon, 12 Jun 2023 14:36:56 GMT, Martin Doerr wrote:
> Test fix for test failing on AIX because of undefined behavior in current
> implementation.
This pull request has now been integrated.
Changeset: 08eff92b
Author:Martin Doerr
URL:
https://git.openjdk.org/jdk21/
On Mon, 12 Jun 2023 14:36:56 GMT, Martin Doerr wrote:
> Test fix for test failing on AIX because of undefined behavior in current
> implementation.
Thanks for the review! I'm planning to integrate tomorrow.
-
PR Comment: https://git.openjdk.org/jdk21/pull/9#issuec
Test fix for test failing on AIX because of undefined behavior in current
implementation.
-
Commit messages:
- Backport cf9e6353cc6fe9e57a7a9883813d09892e7e7621
Changes: https://git.openjdk.org/jdk21/pull/9/files
Webrev: https://webrevs.openjdk.org/?repo=jdk21=9=00
Issue:
On Wed, 7 Jun 2023 14:04:14 GMT, JoKern65 wrote:
>> The sys_thread_3() function contains an empty while loop, which by the
>> standard can be optimized away. Please refer to discussion in
>> https://github.com/llvm/llvm-project/issues/60622
>> The xlc17 compiler is doing so, and IBM claims
On Tue, 6 Jun 2023 09:51:09 GMT, JoKern65 wrote:
> The sys_thread_3() function contains an empty while loop, which by the
> standard can be optimized away. Please refer to discussion in
> https://github.com/llvm/llvm-project/issues/60622
> The xlc17 compiler is doing so, and IBM claims that
On Fri, 2 Jun 2023 10:19:53 GMT, JoKern65 wrote:
> This pr is a split off from JDK-8308288: Fix xlc17 clang warnings in shared
> code https://github.com/openjdk/jdk/pull/14146
> It handles the part in security and servicability.
>
> Compiling on AIX with xlc17 which contains the new clang 15
On Tue, 6 Jun 2023 09:51:09 GMT, JoKern65 wrote:
> The sys_thread_3() function contains an empty while loop, which by the
> standard can be optimized away. Please refer to discussion in
> https://github.com/llvm/llvm-project/issues/60622
> The xlc17 compiler is doing so, and IBM claims that
On Fri, 2 Jun 2023 18:24:16 GMT, Y. Srinivas Ramakrishna
wrote:
>> Kelvin Nilsen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Force PLAB sizes to align on card-table size
>
>
On Fri, 2 Jun 2023 02:49:25 GMT, Kelvin Nilsen wrote:
>> OpenJDK Colleagues:
>>
>> Please review this proposed integration of Generational mode for Shenandoah
>> GC under https://bugs.openjdk.org/browse/JDK-8307314.
>>
>> Generational mode of Shenandoah is enabled by adding
>>
On Fri, 26 May 2023 20:46:29 GMT, Kelvin Nilsen wrote:
> OpenJDK Colleagues:
>
> Please review this proposed integration of Generational mode for Shenandoah
> GC under https://bugs.openjdk.org/browse/JDK-8307314.
>
> Generational mode of Shenandoah is enabled by adding
>
On Fri, 26 May 2023 16:58:41 GMT, Thomas Stuefe wrote:
>> The crazy thing is that `malloc` is defined! That means all places where we
>> use the term malloc are getting replaced without such a workaround. (E.g.
>> for log tags.)
>
> So, we do this only for malloc? Not for calloc,
On Fri, 26 May 2023 08:31:46 GMT, JoKern65 wrote:
>> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk
>> on AIX , we run into various "warnings as errors".
>> Some of those are in shared codebase and could be addressed by small
>> adjustments.
>> A lot of those
On Thu, 25 May 2023 15:04:32 GMT, Kim Barrett wrote:
>> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk
>> on AIX , we run into various "warnings as errors".
>> Some of those are in shared codebase and could be addressed by small
>> adjustments.
>> A lot of those
On Thu, 4 May 2023 09:50:23 GMT, Axel Boldt-Christmas
wrote:
>>> I'm getting build warnings on all linux platforms with gcc-11.3.0:
>>>
>>> ```
>>> src/hotspot/share/gc/z/zDriver.cpp:84:13: error: In the GNU C Library,
>>> "minor" is defined
>>> by . For historical compatibility, it is
>>>
On Wed, 3 May 2023 19:36:55 GMT, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please review the implementation of Generational ZGC, which can be turned on
>> by adding -XX:+ZGenerational in addition to using -XX:+UseZGC. Generational
>> ZGC is a major rewrite of the non-generational ZGC version
On Wed, 3 May 2023 10:55:49 GMT, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please review the implementation of Generational ZGC, which can be turned on
>> by adding -XX:+ZGenerational in addition to using -XX:+UseZGC. Generational
>> ZGC is a major rewrite of the non-generational ZGC version
On Wed, 3 May 2023 10:55:49 GMT, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please review the implementation of Generational ZGC, which can be turned on
>> by adding -XX:+ZGenerational in addition to using -XX:+UseZGC. Generational
>> ZGC is a major rewrite of the non-generational ZGC version
On Tue, 25 Apr 2023 13:19:36 GMT, Martin Doerr wrote:
> The code introduced by
> [JDK-8304303](https://bugs.openjdk.org/browse/JDK-8304303) uses
> `JNIHandles::make_local` which requires `JNIHandles::destroy_local` which is
> currently missing.
This pull request has now bee
On Tue, 25 Apr 2023 13:19:36 GMT, Martin Doerr wrote:
> The code introduced by
> [JDK-8304303](https://bugs.openjdk.org/browse/JDK-8304303) uses
> `JNIHandles::make_local` which requires `JNIHandles::destroy_local` which is
> currently missing.
Thanks for the reviews!
-
On Fri, 21 Apr 2023 20:26:12 GMT, Roger Riggs wrote:
>> Define an internal jdk.internal.util.Architecture enumeration and static
>> methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64,
On Mon, 17 Apr 2023 20:59:06 GMT, Roger Riggs wrote:
>> Define an internal jdk.internal.util.Architecture enumeration and static
>> methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64,
On Wed, 12 Apr 2023 17:31:49 GMT, Roger Riggs wrote:
>> Define an internal jdk.internal.util.Architecture enumeration and static
>> methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64,
On Tue, 11 Apr 2023 21:09:43 GMT, Roger Riggs wrote:
>> Define an internal jdk.internal.util.Architecture enumeration and static
>> methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64,
On Tue, 11 Apr 2023 18:35:56 GMT, Roger Riggs wrote:
>> Define an internal jdk.internal.util.Architecture enumeration and static
>> methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64,
On Tue, 11 Apr 2023 17:58:54 GMT, Roger Riggs wrote:
>> Define an internal jdk.internal.util.Architecture enumeration and static
>> methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64,
On Tue, 11 Apr 2023 17:58:54 GMT, Roger Riggs wrote:
>> Define an internal jdk.internal.util.Architecture enumeration and static
>> methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64,
On Tue, 11 Apr 2023 10:26:02 GMT, ExE Boss wrote:
>> test/jdk/jdk/internal/util/ArchTest.java line 128:
>>
>>> 126: case RISCV64 -> true;
>>> 127: case S390 -> false;
>>> 128: case PPC64 -> true;
>>
>> This is not always true. The PPC64 architecture supports
On Sat, 8 Apr 2023 18:00:53 GMT, Roger Riggs wrote:
>> Define an internal jdk.internal.util.Architecture enumeration and static
>> methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64,
On Tue, 28 Mar 2023 12:54:41 GMT, Amit Kumar wrote:
>> Matias Saavedra Silva has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> RISCV patch and aarch64 improvement
>
> src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp line 652:
>
On Thu, 23 Mar 2023 15:06:21 GMT, Matias Saavedra Silva
wrote:
>> Matias Saavedra Silva has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Improved comment for load-acquire aarch64
>
> src/hotspot/cpu/ppc/templateTable_ppc_64.cpp line
On Thu, 16 Mar 2023 09:07:27 GMT, Richard Reingruber wrote:
>> src/hotspot/cpu/ppc/templateTable_ppc_64.cpp line 3398:
>>
>>> 3396: const Bytecodes::Code code = bytecode();
>>> 3397: const bool is_invokeinterface = code ==
>>> Bytecodes::_invokeinterface;
>>> 3398: const bool
On Wed, 15 Mar 2023 18:45:00 GMT, Matias Saavedra Silva
wrote:
>> The current structure used to store the resolution information for
>> invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its
>> ambigious fields f1 and f2. This structure can hold information for fields,
On Thu, 19 Jan 2023 09:13:42 GMT, Fredrik Bredberg wrote:
>> Implementation of relativized locals in interpreter frames for x86. x64,
>> arm, aarch64, ppc64le and riscv.
>> Not relativized locals on zero and s390 but done some changes to cope with
>> the changed generic code.
>> Tested
On Wed, 18 Jan 2023 15:46:22 GMT, Fredrik Bredberg wrote:
>> The code uses ()[R12_scratch2]. I think your comment is confusing. Please
>> remove it or write something comprehensive. E.g. save R18_locals in
>> compressed format relative to the new top frame's FP (= current SP).
>
> See what you
On Tue, 17 Jan 2023 17:02:04 GMT, Fredrik Bredberg wrote:
>> src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp line 1035:
>>
>>> 1033: __ sub(R12_scratch2, R18_locals, R1_SP);
>>> 1034: __ srdi(R12_scratch2, R12_scratch2,
>>> Interpreter::logStackElementSize);
>>> 1035: // Now
On Tue, 17 Jan 2023 08:35:45 GMT, Fredrik Bredberg wrote:
>> Implementation of relativized locals in interpreter frames for x86. x64,
>> arm, aarch64, ppc64le and riscv.
>> Not relativized locals on zero and s390 but done some changes to cope with
>> the changed generic code.
>> Tested
On Tue, 17 Jan 2023 08:40:18 GMT, Fredrik Bredberg wrote:
> > Works on PPC64. Thanks! Tests have passed on other platforms as well.
>
> Does "other platforms" include S390?
No, @backwaterred you may want to check.
-
PR: https://git.openjdk.org/jdk/pull/11902
On Mon, 9 Jan 2023 10:30:06 GMT, Fredrik Bredberg wrote:
> Implementation of relativized locals in interpreter frames for x86. x64, arm,
> aarch64, ppc64le and riscv.
> Not relativized locals on zero and s390 but done some changes to cope with
> the changed generic code.
> Tested tier1-tier8
On Mon, 28 Nov 2022 12:14:59 GMT, Erik Österlund wrote:
>> The current loom code makes some assumptions about GC that will not work
>> with generational ZGC. We should make this code more GC agnostic, and
>> provide a better interface for talking to the GC.
>>
>> In particular,
>> 1) All GCs
On Mon, 28 Nov 2022 12:14:59 GMT, Erik Österlund wrote:
>> The current loom code makes some assumptions about GC that will not work
>> with generational ZGC. We should make this code more GC agnostic, and
>> provide a better interface for talking to the GC.
>>
>> In particular,
>> 1) All GCs
On Thu, 24 Nov 2022 10:59:41 GMT, Martin Doerr wrote:
> Related issue is fixed with
> [JDK-8228649](https://bugs.openjdk.org/browse/JDK-8228649)
> Test has passed.
This pull request has now been integrated.
Changeset: 012dafee
Author: Martin Doerr
URL:
https://git.openjd
On Thu, 24 Nov 2022 10:59:41 GMT, Martin Doerr wrote:
> Related issue is fixed with
> [JDK-8228649](https://bugs.openjdk.org/browse/JDK-8228649)
> Test has passed.
Thanks for the review!
-
PR: https://git.openjdk.org/jdk/pull/11351
On Thu, 24 Nov 2022 10:59:41 GMT, Martin Doerr wrote:
> Related issue is fixed with
> [JDK-8228649](https://bugs.openjdk.org/browse/JDK-8228649)
> Test has passed.
Thanks for the review! I'll probably integrate on Monday.
-
PR: https://git.openjdk.org/jdk/pull/11351
Related issue is fixed with
[JDK-8228649](https://bugs.openjdk.org/browse/JDK-8228649)
Test has passed.
-
Commit messages:
- 8297082: Remove sun/tools/jhsdb/BasicLauncherTest.java from problem list
Changes: https://git.openjdk.org/jdk/pull/11351/files
Webrev:
79 matches
Mail list logo
