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: https://webrevs.openj
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
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.
This pull request has now been integrated.
Changeset: 012dafee
Author: Martin Doerr
URL:
https://git.openjd
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 h
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 h
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
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 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 tier1-ti
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 &fp(
On Wed, 18 Jan 2023 15:46:22 GMT, Fredrik Bredberg wrote:
>> The code uses &sp()[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 y
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 tier1-ti
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, 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 is_invokedy
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 2294
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 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, X8
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 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, X
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, X
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, X
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, X
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, X
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, X
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, X
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 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 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 tha
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 tha
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 tha
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
>>> c
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 ch
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 chang
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, posix_memalign
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
> `-XX:+UnlockExperimen
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
>> `-XX:+UnlockExp
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
>
> src/hotspot/cpu/riscv/gc/shenandoah/c1/shenandoahBarrierSe
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 the
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 fr
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 the
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 that
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&pr=9&range=00
Issu
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#i
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 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 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: https://git.openjdk.org/jdk
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 f
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 f
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 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 cause
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 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 cause
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 has
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 expl
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 cause
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 ibm_16_am
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 cause
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 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 ibm_16_am
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 ibm_16_am
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
>> sta
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 ibm_16_am
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 a
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
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 ? @ts
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 ibm_16_am.
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 libfilenam
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 ibm_16_am.
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, eithe
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 ibm_16_am
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 afte
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 ibm_16_am
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 ibm_16_am
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 ibm_16_am
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 ibm_16_am
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
>> TEST_VM_OPTS=
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
>> TEST_VM_OPTS=
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
> memset(ret
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
> memset(ret
On Tue, 8 Oct 2024 16:30:47 GMT, Roman Kennke wrote:
>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>>
>> It is also a follow-up to #20640, which now also includes (and supersedes)
>> #20603 and #20605, plus the Tiny Class-Pointers parts that have been
>> previ
On Tue, 1 Oct 2024 15:46:01 GMT, Roman Kennke wrote:
>>> Indeed, I could re-enable all tests in:
>>>
>>> ```
>>> test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationMismatchedAccess.java
>>> test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java
>>> test/hotspot/jtreg/compiler/l
On Tue, 22 Oct 2024 13:53:03 GMT, Thomas Stuefe wrote:
>> I will do some benchmarks
>
> I did SpecJBB runs with shift of 6, 8 and 10, respectively, which amounts to
> Klass alignment of 64, 256 and 1K. Benchmark scores did not show a
> significant pattern. I did not measure CPU stats though.
>
On Thu, 19 Sep 2024 14:52:07 GMT, Martin Doerr wrote:
> The SA model of the UpcallStub doesn't work reliably on PPC64. We can use the
> Backchain which works for all Power Architecture 64-Bit ELF ABI compliant
> frames. (The backtrace should stop when hitting a non-compliant fram
On Thu, 19 Sep 2024 14:52:07 GMT, Martin Doerr wrote:
> The SA model of the UpcallStub doesn't work reliably on PPC64. We can use the
> Backchain which works for all Power Architecture 64-Bit ELF ABI compliant
> frames. (The backtrace should stop when hitting a non-compliant fram
On Thu, 19 Sep 2024 14:52:07 GMT, Martin Doerr wrote:
> The SA model of the UpcallStub doesn't work reliably on PPC64. We can use the
> Backchain which works for all Power Architecture 64-Bit ELF ABI compliant
> frames. (The backtrace should stop when hitting a non-compliant fram
Using the FP as raw_unextendedSP is wrong and causes problems like
[JDK-8339772](https://bugs.openjdk.org/browse/JDK-8339772).
"test/hotspot/jtreg/serviceability" tests have passed with this PR.
-
Commit messages:
- 8340657: [PPC64] SA determines wrong unextendedSP
Changes: https:/
On Mon, 23 Sep 2024 15:15:27 GMT, Martin Doerr wrote:
> Using the FP as raw_unextendedSP is wrong and causes problems like
> [JDK-8339772](https://bugs.openjdk.org/browse/JDK-8339772).
> "test/hotspot/jtreg/serviceability" tests have passed with this PR.
Tes
On Mon, 23 Sep 2024 15:15:27 GMT, Martin Doerr wrote:
> Using the FP as raw_unextendedSP is wrong and causes problems like
> [JDK-8339772](https://bugs.openjdk.org/browse/JDK-8339772).
> "test/hotspot/jtreg/serviceability" tests have passed with this PR.
This pull r
On Thu, 19 Sep 2024 14:52:07 GMT, Martin Doerr wrote:
> The SA model of the UpcallStub doesn't work reliably on PPC64. We can use the
> Backchain which works for all Power Architecture 64-Bit ELF ABI compliant
> frames. (The backtrace should stop when hitting a non-compliant fram
The SA model of the UpcallStub doesn't work reliably on PPC64. We can use the
Backchain which works for all Power Architecture 64-Bit ELF ABI compliant
frames. (The backtrace should stop when hitting a non-compliant frame which can
occur with some compiler options. Also see comment in JBS issue.
On Mon, 23 Sep 2024 15:15:27 GMT, Martin Doerr wrote:
> Using the FP as raw_unextendedSP is wrong and causes problems like
> [JDK-8339772](https://bugs.openjdk.org/browse/JDK-8339772).
> "test/hotspot/jtreg/serviceability" tests have passed with this PR.
Thanks a lot for l
On Thu, 24 Oct 2024 09:28:13 GMT, Amit Kumar wrote:
>>> But then, what exactly is the error? If it's just the test assuming that
>>> cache line size is log 6, then the test should be fixed for ppc, not
>>> hotspot.
>>
>> that is the problem, test assumes log2 of 6 for chacheline size
>
> PPC l
On Thu, 14 Nov 2024 23:39:08 GMT, Martin Doerr wrote:
>> William Kemper has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 510 commits:
>>
>> - Merge branch 'merge-latest' into great-genshen-pr
On Wed, 13 Nov 2024 19:32:53 GMT, William Kemper wrote:
>> This PR merges JEP 404, a generational mode for the Shenandoah garbage
>> collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We
>> would like to target JDK24 with this PR.
>
> William Kemper has updated the pull reques
On Tue, 26 Nov 2024 00:37:32 GMT, William Kemper wrote:
>> This PR merges JEP 404, a generational mode for the Shenandoah garbage
>> collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We
>> would like to target JDK24 with this PR.
>
> William Kemper has updated the pull reques
On Tue, 26 Nov 2024 00:37:32 GMT, William Kemper wrote:
>> This PR merges JEP 404, a generational mode for the Shenandoah garbage
>> collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We
>> would like to target JDK24 with this PR.
>
> William Kemper has updated the pull reques
On Mon, 16 Dec 2024 16:28:29 GMT, Laurence Cable wrote:
> again what's the use case?
Assume a customer uses a tool like the async profiler and causes a JVM crash by
doing that. A supporter looks at the hs_err file and wonders about what might
have happened. Such a hint would be very helpful.
On Mon, 16 Dec 2024 12:53:52 GMT, Matthias Baesken wrote:
>> We should output more information about the JVMTI agents in the hserr file.
>
> Matthias Baesken has updated the pull request incrementally with one
> additional commit since the last revision:
>
> adjust spaces in output
LGTM.
--
On Fri, 13 Dec 2024 12:18:13 GMT, Matthias Baesken wrote:
>> We should output more information about the JVMTI agents in the hserr file.
>
> Matthias Baesken has updated the pull request incrementally with one
> additional commit since the last revision:
>
> simplify coding
Nice enhancement!
On Thu, 19 Dec 2024 12:54:20 GMT, Coleen Phillimore wrote:
>> src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp line 690:
>>
>>> 688: push(state);
>>> 689:
>>> 690: // Skip if we don't have to unlock. (???is this right???)
>>
>> The logic seems consistent with other platforms. Not sure what y
1 - 100 of 116 matches
Mail list logo
