From dholmes at openjdk.org  Thu Dec  1 00:09:21 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 1 Dec 2022 00:09:21 GMT
Subject: RFR: 8297389: resexhausted003 fails with
 assert(!thread->owns_locks()) failed: must release all locks when leaving VM
 [v3]
In-Reply-To: <uNoa_1yi6xIqGrMPQbNTIJBoU9kDYFueWhx4oyMfXTU=.48904340-c641-40b7-a225-4b186ea1bb32@github.com>
References: <FGpni8mDUm5PEVCRqcUg9Fn4AskWedWRL6TreaHahFU=.58f3f49f-23b9-4d67-a0eb-54139a6be675@github.com>
 <uNoa_1yi6xIqGrMPQbNTIJBoU9kDYFueWhx4oyMfXTU=.48904340-c641-40b7-a225-4b186ea1bb32@github.com>
Message-ID: <egwsUErsZfYPRQ5ELxoM6BqOvPLsxoX_go6N9VN7jwM=.580de8a0-8c90-4db5-9c29-0f7d7d912008@github.com>

On Mon, 28 Nov 2022 14:33:39 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> `Method::build_profiling_method_data` acquires the `MethodData_lock` when initializing `Method::_method_data` to prevent multiple allocations by different threads. The problem is that when metaspace allocation fails and `JvmtiExport::should_post_resource_exhausted()` is set, we assert during the `ThreadToNativeFromVM` transition in JVMTI code.
>> 
>> Since concurrent initialization is a rare event, I suggest to get rid of the lock and perform the initialization with a `cmpxchg`, similar to how method counters are initialized:
>> https://github.com/openjdk/jdk/blob/f4b5065c37e86f4b2ca26da6ce678febe4a52950/src/hotspot/share/oops/method.cpp#L644-L646
>> 
>> Since [current code](https://github.com/openjdk/jdk/blob/f4b5065c37e86f4b2ca26da6ce678febe4a52950/src/hotspot/share/oops/method.inline.hpp#L41-L46) in `Method::set_method_data` uses a `Atomic::release_store`, I added a `OrderAccess::release()`.
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Completely removed MethodData_lock

Changes seem okay but I'm not that familiar with the actual code here.

Thanks.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11316

From dholmes at openjdk.org  Thu Dec  1 00:29:33 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 1 Dec 2022 00:29:33 GMT
Subject: RFR: 8297427: Avoid keeping class loaders alive when executing
 ClassLoaderStatsVMOperation [v2]
In-Reply-To: <qVWmEYZDcXkHs5UN68wzWCFctsz_9zfg1XjdbG7FfKw=.1745c615-98ef-46cd-82df-590fd1673a1c@github.com>
References: <YdNWoA79MYjB7s-lcu1eYljYAGoV46gjbnYqX0PzJGc=.93d62d9d-0642-4a0d-9f90-b8b1885d4ace@github.com>
 <qVWmEYZDcXkHs5UN68wzWCFctsz_9zfg1XjdbG7FfKw=.1745c615-98ef-46cd-82df-590fd1673a1c@github.com>
Message-ID: <0f3IQ2iYzLmNzwRM6nYUvW7NK_EuawncqHhlhjjIX6g=.f4e4ec7e-3f6f-40cb-991e-100eb749b71e@github.com>

On Wed, 30 Nov 2022 09:08:52 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Please review this change to avoid keeping classes alive only due to the `ClassLoaderStatsVMOperation`.
>> 
>> **Summary**
>> The `ClassLoaderStatsVMOperation` is gathering statistics about the active class loaders in a safepoint. The way the `ClassLoaderDataGraph` is iterated will keep the class loaders live. This is not really needed since everything is done in a safepoint and nothing needs to be explicitly kept alive. This has not been a problem prior to concurrent class unloading in ZGC. With fully concurrent class unloading a `ClassLoaderStatsVMOperation` can occur during a collection and more classes than needed might be kept alive. This could in turn lead to premature Metaspace OOM. 
>> 
>> The solution is to not keep the class loaders alive due to the iteration in `ClassLoaderStatsVMOperation`.
>> 
>> **Testing**
>> * Added a new test that covers the two different ways a class could previously be kept alive by the VM operation. The test passes after the fix but failed before.  
>> * Mach5 tier 1-3
>
> Stefan Johansson has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Print object to ensure it is kept alive
>  - Revert "Axel comments to use templates"
>    
>    This reverts commit 8800ef089b62cf173147b68adb2ee993b7e72980.
>  - Revert "Missing include for minimal"
>    
>    This reverts commit 424e0f9d831279ba2d1986ebacb499f8d4a6c078.

A few drive-by comments on the test.

test/hotspot/jtreg/runtime/ClassUnload/UnloadTestDuringClassLoaderStatsVMOperation.java line 26:

> 24: /*
> 25:  * @test Class unloading test while triggering execution of ClassLoaderStats VM operations
> 26:  * @summary Make sure class unloading occur even if ClassLoaderStats VM operations are executed

Having a comment on `@test` and providing `@summary` seems redundant. I would just leave the summary.

You could/should(?) add a `@bug` line too.

test/hotspot/jtreg/runtime/ClassUnload/UnloadTestDuringClassLoaderStatsVMOperation.java line 30:

> 28:  * @modules java.base/jdk.internal.misc
> 29:  * @library /test/lib
> 30:  * @library classes

You can put multiple libraries on one `@library` - could save some jtreg  parsing time.

test/hotspot/jtreg/runtime/ClassUnload/UnloadTestDuringClassLoaderStatsVMOperation.java line 39:

> 37: import java.net.URLClassLoader;
> 38: 
> 39: import jdk.test.lib.classloader.ClassUnloadCommon;

Should imports be sorted and grouped ie.

import java.net.URLClassLoader;

import jdk.test.lib.classloader.ClassUnloadCommon;
import jdk.test.whitebox.WhiteBox;

? Not sure if we have a style-guide for this.

test/hotspot/jtreg/runtime/ClassUnload/UnloadTestDuringClassLoaderStatsVMOperation.java line 55:

> 53:             }
> 54:         };
> 55:         var clsThread = new Thread(task);

You don't need `task` here as you can just write the above as:

var clsThread = new Thread(() -> {
            while (true) {
                wb.forceClassLoaderStatsSafepoint();
            }
        });

test/hotspot/jtreg/runtime/ClassUnload/UnloadTestDuringClassLoaderStatsVMOperation.java line 75:

> 73:         ClassUnloadCommon.failIf(!wb.isClassAlive(className), className + " should be loaded and live");
> 74: 
> 75:         // Printing the object to ensure the class is kept alive. If the test

We should be using `Reference.reachabilityFence` to keep objects alive.

-------------

PR: https://git.openjdk.org/jdk/pull/11300

From jjg at openjdk.org  Thu Dec  1 00:53:23 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 1 Dec 2022 00:53:23 GMT
Subject: RFR: 8296710: Update to use jtreg 7.1
In-Reply-To: <4t-uTHoUVlflpzDnfuHO7TAnix7nNO1MGF28CJBjZBo=.deb056ac-6571-4c79-a272-680b923d58c5@github.com>
References: <4t-uTHoUVlflpzDnfuHO7TAnix7nNO1MGF28CJBjZBo=.deb056ac-6571-4c79-a272-680b923d58c5@github.com>
Message-ID: <ilsNgmMPrHB9Pm4jpbWYHTvxRF5_49JBZLbKEw_LwMI=.d9c2eba3-6aab-4bb4-9be3-bea34efc38ff@github.com>

On Tue, 29 Nov 2022 14:44:12 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg `7.1`.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.
> 
> This pull request was created by copying the following and using `7.1` at appropriate places:
> - https://github.com/openjdk/jdk/pull/9393

Marked as reviewed by jjg (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11416

From jrose at openjdk.org  Thu Dec  1 00:56:52 2022
From: jrose at openjdk.org (John R Rose)
Date: Thu, 1 Dec 2022 00:56:52 GMT
Subject: RFR: 8252584: HotSpot Style Guide should permit alignas [v2]
In-Reply-To: <pPy5eCgVCXREucMdNtbj_xx_h7oeZOhyYfh23RTMa8M=.7b59b2b3-8ca3-4c06-8824-a9ca661e2a32@github.com>
References: <wtpB01HooEIU2FxGS9E5KPIv1ogztEw-XYFRTUNw5Cw=.6e6625ee-5343-49d6-98f3-2962f269184d@github.com>
 <pPy5eCgVCXREucMdNtbj_xx_h7oeZOhyYfh23RTMa8M=.7b59b2b3-8ca3-4c06-8824-a9ca661e2a32@github.com>
Message-ID: <sN1Sd_AMpnFy6GlsrFJgOqcsT6UnRQkkUNdOvLLA11U=.f5396c03-9a6d-4a4f-923f-e5f31884801c@github.com>

On Sun, 27 Nov 2022 13:49:41 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Add alignas to the permitted features set. Though the corresponding entry mentions this should not be done for classes, there's no actual difference in practice with all our supported compilers, because their nonstandard syntax also has the same limitations and issues with dynamic allocation as the C++ alignas, and including such a restriction of falling back to ATTRIBUTE_ALIGNED in the case of classes in the style guide would ultimately not really serve much of a point
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rectify issues mentioned in review

Given that this declaration thingy has no portable meaning beyond max-align, it seems to be actually dangerous to use, for at least some of our use cases in HotSpot.  And for the use cases within max-align, the usual workarounds with unions and what-not will do the job, almost always.

In short, this syntax seems like the sort of sugary flaky treat we should avoid.  Making our sources less portable in order to make them more beautiful would be a bad bargain.

The ugly-but-reliable way we control stuff like is to concoct some kind of ugly macro, local to HotSpot, that has exactly the semantics that we require, and that is portable.

-------------

PR: https://git.openjdk.org/jdk/pull/11315

From fjiang at openjdk.org  Thu Dec  1 02:12:59 2022
From: fjiang at openjdk.org (Feilong Jiang)
Date: Thu, 1 Dec 2022 02:12:59 GMT
Subject: RFR: 8297697: RISC-V: Add support for SATP mode detection [v3]
In-Reply-To: <19LRRu8SCc6Qoar19Xr1XvA17ZIPehN12r4lVohh4G4=.833efe6b-c298-4875-af3d-74c95ef447eb@github.com>
References: <Xji-rRKv8AIaIZNkWPLycJo5RR1AsCXbxcf3fz9vrjM=.2d30a970-4ff4-449c-bd47-1443b59d2120@github.com>
 <lEyL9get5mVAM3E9yw4hf-uSHGD45a6P6CfwM10KIn4=.ef4f6a41-a7da-4e49-8193-11caec0c244b@github.com>
 <19LRRu8SCc6Qoar19Xr1XvA17ZIPehN12r4lVohh4G4=.833efe6b-c298-4875-af3d-74c95ef447eb@github.com>
Message-ID: <cK7FUQnvIbCNd2GenCivPfTeF1P8vwLyjo8U6uWfRFw=.f4efe016-c6ba-491c-8730-62d834bbd674@github.com>

On Wed, 30 Nov 2022 15:11:51 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> Feilong Jiang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove sv32
>
> Marked as reviewed by luhenry (Author).

@luhenry @RealFYang -- Thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/11388

From xlinzheng at openjdk.org  Thu Dec  1 03:14:19 2022
From: xlinzheng at openjdk.org (Xiaolin Zheng)
Date: Thu, 1 Dec 2022 03:14:19 GMT
Subject: RFR: 8297763: Fix missing stub code expansion before align() in
 shared trampolines [v2]
In-Reply-To: <QOm1rf2yvHIVvNhyiPG97YQOX-_5j1VjLoYKbl20lEQ=.98674f31-37eb-4967-bcfe-caad03b5d9ba@github.com>
References: <T5fCT6B-2hhjmlMaRuu5iHfMI-gxkuFJp3jtjGh7ZtM=.719d411d-da4f-482b-af14-c9caee93b865@github.com>
 <QOm1rf2yvHIVvNhyiPG97YQOX-_5j1VjLoYKbl20lEQ=.98674f31-37eb-4967-bcfe-caad03b5d9ba@github.com>
Message-ID: <1SR3oIsV3Km0iB96Inlafeh-gSJXILRZ9xJxQfjnyTw=.440a8653-2e6d-4e3d-98c8-ac427c900ebb@github.com>

On Wed, 30 Nov 2022 11:37:58 GMT, Xiaolin Zheng <xlinzheng at openjdk.org> wrote:

>> This patch fixes missing stub code expansion logic before `align()` for AArch64 and RISC-V.
>> 
>> The `align()` at most creates 4-byte padding, so a `NativeInstruction::instruction_size` is enough.
>> 
>> I am considering pre-calculating the total trampoline sizes and allocating them in batches, but maybe after this one, for this is a quick fix to unblock https://github.com/openjdk/jdk/pull/11188. Please see that thread.
>> 
>> The `assert_alignment(pc());` added in the RISC-V part shows that RVC doesn't change the trampoline stub / static stub logic, so there is no need to adjust the trampoline size for it. [1]
>> 
>> Tested AArch64 hotspot tier1~3, and 4 is still running; tested RISC-V hotspot tier1~2, and 3~4 are still running.
>> 
>> Thanks,
>> Xiaolin
>> 
>> [1] https://github.com/openjdk/jdk/blob/2deb318c9f047ec5a4b160d66a4b52f93688ec42/src/hotspot/cpu/riscv/macroAssembler_riscv.cpp#L3125-L3126
>
> Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix as to comments

Gentle ping - may I have a second review please (the AArch64 part of the changes)? The latest change has passed hotspot tier1~tier4 on both platforms.

-------------

PR: https://git.openjdk.org/jdk/pull/11414

From fjiang at openjdk.org  Thu Dec  1 04:05:11 2022
From: fjiang at openjdk.org (Feilong Jiang)
Date: Thu, 1 Dec 2022 04:05:11 GMT
Subject: Integrated: 8297697: RISC-V: Add support for SATP mode detection
In-Reply-To: <Xji-rRKv8AIaIZNkWPLycJo5RR1AsCXbxcf3fz9vrjM=.2d30a970-4ff4-449c-bd47-1443b59d2120@github.com>
References: <Xji-rRKv8AIaIZNkWPLycJo5RR1AsCXbxcf3fz9vrjM=.2d30a970-4ff4-449c-bd47-1443b59d2120@github.com>
Message-ID: <yYCgv8AErdyxOMl2t5VERM5W4HeKQCxuxI67-XBv_ZE=.2dfd90b4-8540-4c73-972e-6cae4a89c3ed@github.com>

On Mon, 28 Nov 2022 11:31:17 GMT, Feilong Jiang <fjiang at openjdk.org> wrote:

> RISC-V gets sv57-based virtual memory support since Linux 5.18 [1]. There are some reports of the OpenJDK RISC-V port crashing on Linux 5.18+ with QEMU-system 7.10+ when sv57 was enabled [2][3] as currently RISC-V port only supports up to sv48.
> As discussed in [3], given the fact that there are no existing boards or hardware even support anything more than sv48,
> we decide to add detection for SATP (Supervisor Address Translation and Protection) mode at JVM startup time if possible and explicitly issue a warning and stop early when sv57 is enabled.
> 
> When sv57 is enabled, the output of java -version would be:
> 
> 
> root at qemuriscv64:~# jdk/bin/java -version
> Error occurred during initialization of VM
> Unsupported satp mode: sv57
> 
> 
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aa5b537b0ecc16992577b013f11112d54c7ce869
> [2] https://mail.openjdk.org/pipermail/riscv-port-dev/2022-September/000639.html
> [3] https://mail.openjdk.org/pipermail/riscv-port-dev/2022-November/000681.html
> 
> Testing:
> 
> - QEMU-system with sv48/sv57-enabled Linux image `-version` test
> - HiFive Unmatched board (sv39) `-version` test

This pull request has now been integrated.

Changeset: f49acd52
Author:    Feilong Jiang <fjiang at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f49acd52594be3ec1e9682bda3ad69970dfd750d
Stats:     39 lines in 3 files changed: 38 ins; 0 del; 1 mod

8297697: RISC-V: Add support for SATP mode detection

Reviewed-by: fyang, luhenry

-------------

PR: https://git.openjdk.org/jdk/pull/11388

From jwaters at openjdk.org  Thu Dec  1 04:21:18 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 1 Dec 2022 04:21:18 GMT
Subject: RFR: 8297852: Backout 8252584 for the time being
In-Reply-To: <9rSgaMOb56fcYoRPJX6rgi1jcvzxQXsMqAod76PmF4s=.97ad88c3-1250-4aea-a1f9-1c78987a3ad6@github.com>
References: <9rSgaMOb56fcYoRPJX6rgi1jcvzxQXsMqAod76PmF4s=.97ad88c3-1250-4aea-a1f9-1c78987a3ad6@github.com>
Message-ID: <dgxRPIQwUrSn7Nf1I-1Kr7Yzrgbj2WLXkwc2azlXUws=.3e67c296-c27a-4873-a6f2-ff1918c02824@github.com>

On Wed, 30 Nov 2022 15:00:32 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Revert 8252584 temporarily (My mistake)

Thanks Kim, I'm really sorry about the goof

-------------

PR: https://git.openjdk.org/jdk/pull/11433

From jwaters at openjdk.org  Thu Dec  1 04:26:29 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 1 Dec 2022 04:26:29 GMT
Subject: Integrated: 8297852: Backout 8252584 for the time being
In-Reply-To: <9rSgaMOb56fcYoRPJX6rgi1jcvzxQXsMqAod76PmF4s=.97ad88c3-1250-4aea-a1f9-1c78987a3ad6@github.com>
References: <9rSgaMOb56fcYoRPJX6rgi1jcvzxQXsMqAod76PmF4s=.97ad88c3-1250-4aea-a1f9-1c78987a3ad6@github.com>
Message-ID: <7o8OZByh2I5em5T9eN-ITydl0hNb0jbXr5HoMgdnzLU=.cc74f25e-7fef-4a1c-9067-8b58286a5cf0@github.com>

On Wed, 30 Nov 2022 15:00:32 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Revert 8252584 temporarily (My mistake)

This pull request has now been integrated.

Changeset: 56048f97
Author:    Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/56048f9718d1104227795a23c02fa144543c07d0
Stats:     94 lines in 2 files changed: 0 ins; 92 del; 2 mod

8297852: Backout 8252584 for the time being

Reviewed-by: kbarrett

-------------

PR: https://git.openjdk.org/jdk/pull/11433

From jwaters at openjdk.org  Thu Dec  1 04:44:09 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 1 Dec 2022 04:44:09 GMT
Subject: RFR: 8297912: Redo 8252584 with the proper approval
Message-ID: <Lyv_ypxMsA5tjqJ3d4KwScyySdBcTo34lL8abbF4SoQ=.44f3b51c-30b8-428e-b715-6af70bccaaf5@github.com>

[8252584](https://bugs.openjdk.org/browse/JDK-8252584) was integrated too early due to a mistake on my part, we should redo it and go through the proper approval process this time

(The changes in this commit are exactly identical to 8252584)

-------------

Commit messages:
 - HotSpot Style Guide

Changes: https://git.openjdk.org/jdk/pull/11446/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11446&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297912
  Stats: 94 lines in 2 files changed: 92 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11446.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11446/head:pull/11446

PR: https://git.openjdk.org/jdk/pull/11446

From jwaters at openjdk.org  Thu Dec  1 04:46:55 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 1 Dec 2022 04:46:55 GMT
Subject: RFR: 8250269: Replace ATTRIBUTE_ALIGNED with alignas [v2]
In-Reply-To: <9QKV9cYFTo_1D8R-mI80lnewNkA0ceJNKFPbrvICxl4=.d6736b76-8324-4084-bede-6e144b4f6c04@github.com>
References: <9QKV9cYFTo_1D8R-mI80lnewNkA0ceJNKFPbrvICxl4=.d6736b76-8324-4084-bede-6e144b4f6c04@github.com>
Message-ID: <tgldEz1xG9-END10IQ3S62m6xYsNSUmL75Gqk1Obk6w=.794388cd-b1eb-4fc7-afcc-d503bb846adc@github.com>

> C++11 added the alignas attribute, for the purpose of specifying alignment on types, much like compiler specific syntax such as gcc's __attribute__((aligned(x))) or Visual C++'s __declspec(align(x)).
> 
> We can phase out the use of the macro in favor of the standard attribute. In the meantime, we can replace the toolchain specific definitions of ATTRIBUTE_ALIGNED with a portable definition. We might deprecate the use of the macro but changing its implementation quickly and cleanly applies the feature where the macro is being used.
> 
> Note: With certain parts of HotSpot using ATTRIBUTE_ALIGNED so indiscriminately, this commit will likely take some time to get right
> 
> This will require adding the alignas attribute to the list of language features approved for use in HotSpot code. (Ongoing at [8297912](https://github.com/openjdk/jdk/pull/11446))

Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  alignas

-------------

Changes: https://git.openjdk.org/jdk/pull/11431/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11431&range=01
  Stats: 8 lines in 3 files changed: 0 ins; 7 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11431.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11431/head:pull/11431

PR: https://git.openjdk.org/jdk/pull/11431

From thartmann at openjdk.org  Thu Dec  1 06:14:20 2022
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 1 Dec 2022 06:14:20 GMT
Subject: RFR: 8297389: resexhausted003 fails with
 assert(!thread->owns_locks()) failed: must release all locks when leaving VM
 [v3]
In-Reply-To: <uNoa_1yi6xIqGrMPQbNTIJBoU9kDYFueWhx4oyMfXTU=.48904340-c641-40b7-a225-4b186ea1bb32@github.com>
References: <FGpni8mDUm5PEVCRqcUg9Fn4AskWedWRL6TreaHahFU=.58f3f49f-23b9-4d67-a0eb-54139a6be675@github.com>
 <uNoa_1yi6xIqGrMPQbNTIJBoU9kDYFueWhx4oyMfXTU=.48904340-c641-40b7-a225-4b186ea1bb32@github.com>
Message-ID: <tDkG7sEGpMTYYxhAyn6mzeSVXMmOPYAnJ6TQwq3dk6E=.94844057-ecff-40ac-a952-00c42e64572b@github.com>

On Mon, 28 Nov 2022 14:33:39 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> `Method::build_profiling_method_data` acquires the `MethodData_lock` when initializing `Method::_method_data` to prevent multiple allocations by different threads. The problem is that when metaspace allocation fails and `JvmtiExport::should_post_resource_exhausted()` is set, we assert during the `ThreadToNativeFromVM` transition in JVMTI code.
>> 
>> Since concurrent initialization is a rare event, I suggest to get rid of the lock and perform the initialization with a `cmpxchg`, similar to how method counters are initialized:
>> https://github.com/openjdk/jdk/blob/f4b5065c37e86f4b2ca26da6ce678febe4a52950/src/hotspot/share/oops/method.cpp#L644-L646
>> 
>> Since [current code](https://github.com/openjdk/jdk/blob/f4b5065c37e86f4b2ca26da6ce678febe4a52950/src/hotspot/share/oops/method.inline.hpp#L41-L46) in `Method::set_method_data` uses a `Atomic::release_store`, I added a `OrderAccess::release()`.
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Completely removed MethodData_lock

Thanks, David!

-------------

PR: https://git.openjdk.org/jdk/pull/11316

From thomas.stuefe at gmail.com  Thu Dec  1 07:26:07 2022
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 1 Dec 2022 08:26:07 +0100
Subject: Extend Native Memory Tracking over the JDK ? (was: Proposal:
 track zlib native memory usage with NMT)
In-Reply-To: <cb8b2707-4f43-4e91-83ac-9d3b1f6df2bb@app.fastmail.com>
References: <CAA-vtUzvyqb_LZ9d1Z80oSvzyqpi89053O3B+oDZF4oZ85CuZg@mail.gmail.com>
 <c5db2105-3b78-0b77-779f-011c8649f476@oracle.com>
 <CAA-vtUxrP49w523EQ3yKFh4Zo5W+HMtqpGcsUxOEMkwZUOQ0zQ@mail.gmail.com>
 <a20d3253-47b6-41dc-b8e4-0b894137ed90@app.fastmail.com>
 <4f7deee9-366d-05a2-9268-09a25a138d8d@oracle.com>
 <cb8b2707-4f43-4e91-83ac-9d3b1f6df2bb@app.fastmail.com>
Message-ID: <CAA-vtUwPXTD71ztTbwL5ayzX1jFFjGq1VXGrJ3z=pBFGMdatVA@mail.gmail.com>

Hi Carter, Stefan,

thank you, I think it is good to have this discussion, it is important.

Side note, the discussion steered away from my original question - whether
to instrument the JDK with NMT. I still would love to discuss that, too.

About opening NMT up for user consumption, that is of course possible. But
I think the bigger question is which data we want to open for user
consumption, and at what granularity. And what contracts do we enter when
we do this.

NMT was originally a hotspot-dev-centric tool. It has a lot of
idiosyncrasies. Interpreting the results needs detailed knowledge about
hotspot memory management. Some examples:

- its reports are not consistent across JDK versions, not even across
different patch levels of the same JDK. So you cannot compare results, say,
between JDK11 and 17.
- before a certain version X (I believe JDK 11), the full thread stacks
were accounted for instead of just the in-use portion of the thread stacks.
I remember reading blogs about how thread stack consumption went down when
all that changed was NMT reporting.
- The memory sizes it shows may not have much to do with real RSS. It
systematically underreports some things, since it omits libc overhead and
retention, usage by system- and JNI libraries. But it also overreports
things since it mostly (not always) accounts in terms of "committed"
memory, which usually means mmap()ed or malloc()ed memory. But that is just
committed, not physical memory, it does not translate to RSS usage
directly. That memory may never be touched. OTOH NMT probes thread stacks
with mincore(), so for that section, "committed" really means "physical".

I am fine with opening up NMT via JFR. But does this mean we have to be
more consistent? Do we have to care about downward compatibility of NMT
reports? Are we then still free to redesign the tag system (see my original
mail) or will this tie us down with the current NMT tag system forever? As
a negative example, JFR exposes metaspace allocator details (chunk
statistics) which have been broken ever since JDK 16 when the underlying
implementation changed.

Therefore I am curious about what end users use NMT really for.

@Carter: can you give us examples of which NMT sections had been
particularly useful to you? Maybe we can define a subset to expose instead
of exposing all tags. E.g. I can see thread stack usage being very useful,
but things like ObjectMonitor footprint not so much.

Cheers, Thomas




On Wed, Nov 30, 2022 at 9:45 PM Carter Kozak <ckozak at ckozak.net> wrote:

> This looks fantastic, thank you so much! I can confirm that the proposed
> design would solve my use-case.
>
> I'd enjoy discussing the NMT event  contract somewhere more specific
> to the implementation, but I don't want to muddle this thread with
> implementation details.
>
> Carter Kozak
>
> On Wed, Nov 30, 2022, at 03:37, Stefan Johansson wrote:
>
> Hi Carter,
>
> Your mail made me pick up an old item from my wishlist: to have native
> memory tracking information available in JFR recordings. When we, in GC,
> do improvements to decrease the native memory overhead of our
> algorithms, NMT is a very good tool to track the progress. We have
> scripts that sound very similar to what you describe and more than once
> I've been thinking about adding this information into JFR. But it has
> not been a priority and the greater value has been unclear.
>
> Hearing that others might also benefit from such a change I took a
> discussion with the JFR team on how to best proceed with this. I have
> created a branch for this and will probably create a PR for it shortly,
> but I thought I would drop it here first:
> https://github.com/kstefanj/jdk/tree/8157023-jfr-events-for-nmt
>
> The change adds two new JFR events: one for the total usage and one for
> the usage of each memory type. These are sent only if Native Memory
> Tracking is turned on, and they are enabled in the default JFR profile
> with an interval of 1s. This might change during reviewing but it was a
> good starting point.
>
> With this you will be able to use JFR streaming to access the events
> from within your running process. I hope this will help your use cases
> and please let us know if you have any comments or suggestions.
>
> Thanks,
> Stefan
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20221201/21e28f7d/attachment-0001.htm>

From stuefe at openjdk.org  Thu Dec  1 07:39:12 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 1 Dec 2022 07:39:12 GMT
Subject: RFR: 8297912: Redo 8252584 with the proper approval
In-Reply-To: <Lyv_ypxMsA5tjqJ3d4KwScyySdBcTo34lL8abbF4SoQ=.44f3b51c-30b8-428e-b715-6af70bccaaf5@github.com>
References: <Lyv_ypxMsA5tjqJ3d4KwScyySdBcTo34lL8abbF4SoQ=.44f3b51c-30b8-428e-b715-6af70bccaaf5@github.com>
Message-ID: <Sicv5R257TmnOgiAqUkEzRt1ZmYRVdiMH22bxib8xBk=.69b6d831-7479-4e4e-8135-9e862f2b157d@github.com>

On Thu, 1 Dec 2022 04:34:56 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> [8252584](https://bugs.openjdk.org/browse/JDK-8252584) was integrated too early due to a mistake on my part, we should redo it and go through the proper approval process this time
> 
> (The changes in this commit are exactly identical to 8252584)

Hi Julian, 

could you give this PR/JBS please a speaking name, e.g. "HotSpot Style Guide should permit alignas
 (second attempt)". Nobody remembers all JBS issue numbers :)

Also, @rose00 voiced concerns in the original PR (https://github.com/openjdk/jdk/pull/11315#issuecomment-1332982465) which should be addressed first. I cautiously share his concerns for the moment.

Cheers, Thomas

-------------

PR: https://git.openjdk.org/jdk/pull/11446

From stuefe at openjdk.org  Thu Dec  1 08:10:49 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 1 Dec 2022 08:10:49 GMT
Subject: RFR: JDK-8296907: VMError: add optional callstacks,
 siginfo for secondary errors [v7]
In-Reply-To: <x1kul17oEaJ-UX6ZGPv8OcsxN8QfYlME_d39aSATk-Q=.f0e0169c-15f5-4b4b-8235-68f8e68ec43c@github.com>
References: <x1kul17oEaJ-UX6ZGPv8OcsxN8QfYlME_d39aSATk-Q=.f0e0169c-15f5-4b4b-8235-68f8e68ec43c@github.com>
Message-ID: <tp0aGlpBwTjO8ndOBOm4XegXTO0Afreji4PPfth7Clk=.c9d3b898-43bc-48c2-9117-d6b51d4591cb@github.com>

> This was motivated by discussions we had in https://github.com/openjdk/jdk/pull/11017.
> 
> To aid in analyzing secondary errors during error reporting, it would be useful to see their callstacks for secondary errors. But printing callstacks during error reporting is unsafe - if we get a second crash or assert, it will cause infinite recursion and interrupt error reporting. Also, the hs-err file would be quite verbose. Therefore this feature is optional and limited to debug builds. 
> 
> ---
> 
> Patch
> 
> - adds optional callstack/siginfo printing via debug-only switch `-XX:+ErrorLogSecondaryErrorDetails`.
> - fixes a bug in secondary error handling where we would use the global scratch buffer recursively (via stringStream); that could lead to confusing output since it is used by the error log stream already. We can print directly to that one instead.
> - Removed a stray newline from print_native_stack to clean output.
> - added regression testing for this feature. I removed my name from the test since we don't do this anymore.
> - added clarifying comments to the test and code
> - added SAP copyright to the regression test (we introduced it years ago for JDK-8065895)
> 
> Output looks like this:
> 
> 
> $ java ... -XX:+ErrorLogSecondaryErrorDetails
> 
> 
> will produce, for secondary errors, siginfo and call stack.
> 
> 
> [error occurred during error reporting (test secondary crash 1), id 0xb, SIGSEGV (0xb) at pc=0x00007fddfe8a0a61]
> [siginfo: si_signo: 11 (SIGSEGV), si_code: 128 (SI_KERNEL), si_addr: 0x0000000000000000]
> [stack: Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x1ceea61]  VMError::controlled_crash(int)+0x241  (vmError.cpp:1946)
> V  [libjvm.so+0x1cf413f]  VMError::report(outputStream*, bool)+0x46bf  (vmError.cpp:564)
> V  [libjvm.so+0x1cf516b]  VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x19b  (vmError.cpp:1709)
> V  [libjvm.so+0x1cf5e8f]  VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*, char const*, ...)+0x8f  (vmError.cpp:1467)
> V  [libjvm.so+0x1cf5ec2]  VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*)+0x22  (vmError.cpp:1473)
> V  [libjvm.so+0x1a549e7]  JVM_handle_linux_signal+0x1f7  (signals_posix.cpp:656)
> C  [libc.so.6+0x43090]
> V  [libjvm.so+0x11d6965]  JNI_CreateJavaVM+0x5b5  (jni.cpp:3662)
> C  [libjli.so+0x4013]  JavaMain+0x93  (java.c:1457)
> C  [libjli.so+0x800d]  ThreadJavaMain+0xd  (java_md.c:650)
> ]

Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - merge
 - Feedback Axel
 - Tone down requirement for successful regression test
 - Fix bug where crashing would not reset recursion; add stack frame limit
 - Merge branch 'master' into JDK-8296907-VMError-add-optional-callstacks-siginfo-for-secondary-errors
 - Feedback Axel
 - Merge branch 'JDK-8296907-VMError-add-optional-callstacks-siginfo-for-secondary-errors' of github.com:tstuefe/jdk into JDK-8296907-VMError-add-optional-callstacks-siginfo-for-secondary-errors
 - Update test/hotspot/jtreg/runtime/ErrorHandling/SecondaryErrorTest.java
   
   remove blank
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Feedback David
 - JDK-8296907-VMError-add-optional-callstacks-siginfo-for-secondary-errors

-------------

Changes: https://git.openjdk.org/jdk/pull/11118/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11118&range=06
  Stats: 140 lines in 6 files changed: 116 ins; 3 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/11118.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11118/head:pull/11118

PR: https://git.openjdk.org/jdk/pull/11118

From stuefe at openjdk.org  Thu Dec  1 08:10:52 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 1 Dec 2022 08:10:52 GMT
Subject: RFR: JDK-8296907: VMError: add optional callstacks,
 siginfo for secondary errors [v2]
In-Reply-To: <ZvxcBQflZf4qxygcXOsdL13zBeyww-V0lY-otI69kS4=.f2145e5f-8a38-4cd1-9ed2-a364d01b8128@github.com>
References: <x1kul17oEaJ-UX6ZGPv8OcsxN8QfYlME_d39aSATk-Q=.f0e0169c-15f5-4b4b-8235-68f8e68ec43c@github.com>
 <YtHH6c7C6qbfZgFogPjZbJO0WISUGkNAjRaPG09UaXM=.ec25e9eb-e607-429e-a6f4-c54a1edd662c@github.com>
 <ZvxcBQflZf4qxygcXOsdL13zBeyww-V0lY-otI69kS4=.f2145e5f-8a38-4cd1-9ed2-a364d01b8128@github.com>
Message-ID: <7HQa7zVHBiC6jK2-pKbTXhGzubD2x6pLDWA535sxhnI=.b4dafa2b-681a-494f-88b7-28a6026d67e4@github.com>

On Mon, 14 Nov 2022 05:16:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update test/hotspot/jtreg/runtime/ErrorHandling/SecondaryErrorTest.java
>>   
>>   remove blank
>>   
>>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>
> Seems reasonable in terms of the code, but I am curious how you expect this to be used in practice? If you get a secondary crash with this turned off then I would expect to use gdb on the core file to get the secondary stack, rather than using the new flag and hoping to reproduce the problem. To be useful it seems you would have to remember to run with this always enabled when developing/debugging. ??

@dholmes-ora do you have any objections to this? If you lack time, that is fine, then I try to get another reviewer.

-------------

PR: https://git.openjdk.org/jdk/pull/11118

From dlong at openjdk.org  Thu Dec  1 08:17:20 2022
From: dlong at openjdk.org (Dean Long)
Date: Thu, 1 Dec 2022 08:17:20 GMT
Subject: RFR: 8297389: resexhausted003 fails with
 assert(!thread->owns_locks()) failed: must release all locks when leaving VM
 [v3]
In-Reply-To: <uNoa_1yi6xIqGrMPQbNTIJBoU9kDYFueWhx4oyMfXTU=.48904340-c641-40b7-a225-4b186ea1bb32@github.com>
References: <FGpni8mDUm5PEVCRqcUg9Fn4AskWedWRL6TreaHahFU=.58f3f49f-23b9-4d67-a0eb-54139a6be675@github.com>
 <uNoa_1yi6xIqGrMPQbNTIJBoU9kDYFueWhx4oyMfXTU=.48904340-c641-40b7-a225-4b186ea1bb32@github.com>
Message-ID: <HTjQfVtzcy_t_fzY6eDrZEWxpwl66N0Nzuf2TzddCmg=.f278d881-b69e-44c9-b6be-d56185f8868e@github.com>

On Mon, 28 Nov 2022 14:33:39 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> `Method::build_profiling_method_data` acquires the `MethodData_lock` when initializing `Method::_method_data` to prevent multiple allocations by different threads. The problem is that when metaspace allocation fails and `JvmtiExport::should_post_resource_exhausted()` is set, we assert during the `ThreadToNativeFromVM` transition in JVMTI code.
>> 
>> Since concurrent initialization is a rare event, I suggest to get rid of the lock and perform the initialization with a `cmpxchg`, similar to how method counters are initialized:
>> https://github.com/openjdk/jdk/blob/f4b5065c37e86f4b2ca26da6ce678febe4a52950/src/hotspot/share/oops/method.cpp#L644-L646
>> 
>> Since [current code](https://github.com/openjdk/jdk/blob/f4b5065c37e86f4b2ca26da6ce678febe4a52950/src/hotspot/share/oops/method.inline.hpp#L41-L46) in `Method::set_method_data` uses a `Atomic::release_store`, I added a `OrderAccess::release()`.
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Completely removed MethodData_lock

Marked as reviewed by dlong (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11316

From rrich at openjdk.org  Thu Dec  1 08:40:01 2022
From: rrich at openjdk.org (Richard Reingruber)
Date: Thu, 1 Dec 2022 08:40:01 GMT
Subject: RFR: 8291302: ARM32: nmethod entry barriers support
In-Reply-To: <BJaszr0_haU4UZOyQQEA9P0SOlgtfTtGFBj9VSRD5SM=.ffd6af56-a51e-4627-90cb-0eb0e1bbd5e8@github.com>
References: <BJaszr0_haU4UZOyQQEA9P0SOlgtfTtGFBj9VSRD5SM=.ffd6af56-a51e-4627-90cb-0eb0e1bbd5e8@github.com>
Message-ID: <vENPpkRJ7ZlN6k5ymTCUUiESeWfx6ibyJdTpjPMIjvw=.445df16d-28ca-47ec-9a6b-2bbc1cd7ae95@github.com>

On Wed, 30 Nov 2022 20:26:23 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

> This PR implements nmethod entry barriers for ARM32. It has already been implemented for other ports and is related with JDK-8290025 "Remove the Sweeper".

Hi Aleksei,
thanks for picking up the work on ARM32 support of nmethod entry barriers.
Is my assumption correct that ARM32 supports neither ZGC nor ShenandoahGC? If so you could simplify the implementation.
Thanks, Richard.

src/hotspot/cpu/arm/gc/shared/barrierSetAssembler_arm.cpp line 221:

> 219:   // Subsequent loads of oops must occur after load of guard value.
> 220:   // BarrierSetNMethod::disarm sets guard with release semantics.
> 221:   __ membar(MacroAssembler::LoadLoad, tmp1);

Is my assumption correct that ARM32 supports neither ZGC nor ShenandoahGC?
If so then no memory barrier is needed as no oops are modified concurrently with G1 (and other GCs are not concurrent).
I'd recomment to implement `BarrierSetAssembler::nmethod_patching_type()` as on AARCH64 and replace the membar with an assertion that `NMethodPatchingType::stw_instruction_and_data_patch` is in effect.
@fisk wouldn't it be good if there was a shared method to query if oops (other values?) are modified concurrently?

src/hotspot/cpu/arm/gc/shared/barrierSetNMethod_arm.cpp line 87:

> 85:    to the interpreter if the nmethod has been unloaded. */
> 86: void BarrierSetNMethod::deoptimize(nmethod* nm, address* return_address_ptr) {
> 87: 

Again if neither ZGC nor ShenandoahGC are supported then you can leave this unimplemented. [`BarrierSetNMethod::nmethod_entry_barrier()`](https://github.com/openjdk/jdk/blob/fa0c599a003962cf3457bb49b9f771659532b5c3/src/hotspot/share/gc/shared/barrierSetNMethod.cpp#L72-L103) never returns false so the single [call site](https://github.com/openjdk/jdk/blob/fa0c599a003962cf3457bb49b9f771659532b5c3/src/hotspot/share/gc/shared/barrierSetNMethod.cpp#L181) cannot be reached unless you want to support `DeoptimizeNMethodBarriersALot` which IMO is not needed without support for ZGC/ShenandoahGC.

src/hotspot/cpu/arm/stubGenerator_arm.cpp line 2944:

> 2942:     __ BIND(deoptimize_label);
> 2943: 
> 2944:     __ ldr(Rtemp, Address(SP, 0));

If neither ZGC nor ShenandoahGC are supported then `deoptimization_label` will not be reached.

-------------

PR: https://git.openjdk.org/jdk/pull/11442

From thartmann at openjdk.org  Thu Dec  1 08:51:27 2022
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 1 Dec 2022 08:51:27 GMT
Subject: RFR: 8297389: resexhausted003 fails with
 assert(!thread->owns_locks()) failed: must release all locks when leaving VM
 [v3]
In-Reply-To: <uNoa_1yi6xIqGrMPQbNTIJBoU9kDYFueWhx4oyMfXTU=.48904340-c641-40b7-a225-4b186ea1bb32@github.com>
References: <FGpni8mDUm5PEVCRqcUg9Fn4AskWedWRL6TreaHahFU=.58f3f49f-23b9-4d67-a0eb-54139a6be675@github.com>
 <uNoa_1yi6xIqGrMPQbNTIJBoU9kDYFueWhx4oyMfXTU=.48904340-c641-40b7-a225-4b186ea1bb32@github.com>
Message-ID: <CSfLNgNi6YdNYHupDIzO2qeHNwtQbEvBDV8djLboO_Y=.975c8a2f-b5ef-435f-961b-c8121feae7b7@github.com>

On Mon, 28 Nov 2022 14:33:39 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> `Method::build_profiling_method_data` acquires the `MethodData_lock` when initializing `Method::_method_data` to prevent multiple allocations by different threads. The problem is that when metaspace allocation fails and `JvmtiExport::should_post_resource_exhausted()` is set, we assert during the `ThreadToNativeFromVM` transition in JVMTI code.
>> 
>> Since concurrent initialization is a rare event, I suggest to get rid of the lock and perform the initialization with a `cmpxchg`, similar to how method counters are initialized:
>> https://github.com/openjdk/jdk/blob/f4b5065c37e86f4b2ca26da6ce678febe4a52950/src/hotspot/share/oops/method.cpp#L644-L646
>> 
>> Since [current code](https://github.com/openjdk/jdk/blob/f4b5065c37e86f4b2ca26da6ce678febe4a52950/src/hotspot/share/oops/method.inline.hpp#L41-L46) in `Method::set_method_data` uses a `Atomic::release_store`, I added a `OrderAccess::release()`.
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Completely removed MethodData_lock

Thanks, Dean!

-------------

PR: https://git.openjdk.org/jdk/pull/11316

From thartmann at openjdk.org  Thu Dec  1 08:53:15 2022
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 1 Dec 2022 08:53:15 GMT
Subject: Integrated: 8297389: resexhausted003 fails with
 assert(!thread->owns_locks()) failed: must release all locks when leaving VM
In-Reply-To: <FGpni8mDUm5PEVCRqcUg9Fn4AskWedWRL6TreaHahFU=.58f3f49f-23b9-4d67-a0eb-54139a6be675@github.com>
References: <FGpni8mDUm5PEVCRqcUg9Fn4AskWedWRL6TreaHahFU=.58f3f49f-23b9-4d67-a0eb-54139a6be675@github.com>
Message-ID: <rTokyYFhyozjKVNbq5j-uxnLxK_uAUzTgtSlhBWbCb0=.5b8174b4-990f-41b1-bf13-0da199489756@github.com>

On Wed, 23 Nov 2022 11:56:45 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> `Method::build_profiling_method_data` acquires the `MethodData_lock` when initializing `Method::_method_data` to prevent multiple allocations by different threads. The problem is that when metaspace allocation fails and `JvmtiExport::should_post_resource_exhausted()` is set, we assert during the `ThreadToNativeFromVM` transition in JVMTI code.
> 
> Since concurrent initialization is a rare event, I suggest to get rid of the lock and perform the initialization with a `cmpxchg`, similar to how method counters are initialized:
> https://github.com/openjdk/jdk/blob/f4b5065c37e86f4b2ca26da6ce678febe4a52950/src/hotspot/share/oops/method.cpp#L644-L646
> 
> Since [current code](https://github.com/openjdk/jdk/blob/f4b5065c37e86f4b2ca26da6ce678febe4a52950/src/hotspot/share/oops/method.inline.hpp#L41-L46) in `Method::set_method_data` uses a `Atomic::release_store`, I added a `OrderAccess::release()`.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 9f24a6f4
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9f24a6f43c6a5e1fa92275e0a87af4f1f0603ba3
Stats:     39 lines in 5 files changed: 4 ins; 15 del; 20 mod

8297389: resexhausted003 fails with assert(!thread->owns_locks()) failed: must release all locks when leaving VM

Reviewed-by: dholmes, rrich, dlong

-------------

PR: https://git.openjdk.org/jdk/pull/11316

From sjohanss at openjdk.org  Thu Dec  1 08:56:55 2022
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Thu, 1 Dec 2022 08:56:55 GMT
Subject: RFR: 8297427: Avoid keeping class loaders alive when executing
 ClassLoaderStatsVMOperation [v3]
In-Reply-To: <YdNWoA79MYjB7s-lcu1eYljYAGoV46gjbnYqX0PzJGc=.93d62d9d-0642-4a0d-9f90-b8b1885d4ace@github.com>
References: <YdNWoA79MYjB7s-lcu1eYljYAGoV46gjbnYqX0PzJGc=.93d62d9d-0642-4a0d-9f90-b8b1885d4ace@github.com>
Message-ID: <zHsXJjPXLPJPJoVLoTT7RAzcMzCawADP2_ad6rbnq1k=.fe28eb2b-93de-4add-b223-9fb53d2b4660@github.com>

> Please review this change to avoid keeping classes alive only due to the `ClassLoaderStatsVMOperation`.
> 
> **Summary**
> The `ClassLoaderStatsVMOperation` is gathering statistics about the active class loaders in a safepoint. The way the `ClassLoaderDataGraph` is iterated will keep the class loaders live. This is not really needed since everything is done in a safepoint and nothing needs to be explicitly kept alive. This has not been a problem prior to concurrent class unloading in ZGC. With fully concurrent class unloading a `ClassLoaderStatsVMOperation` can occur during a collection and more classes than needed might be kept alive. This could in turn lead to premature Metaspace OOM. 
> 
> The solution is to not keep the class loaders alive due to the iteration in `ClassLoaderStatsVMOperation`.
> 
> **Testing**
> * Added a new test that covers the two different ways a class could previously be kept alive by the VM operation. The test passes after the fix but failed before.  
> * Mach5 tier 1-3

Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision:

  dholmes review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11300/files
  - new: https://git.openjdk.org/jdk/pull/11300/files/f6dba7f2..3c232f94

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11300&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11300&range=01-02

  Stats: 20 lines in 1 file changed: 6 ins; 3 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/11300.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11300/head:pull/11300

PR: https://git.openjdk.org/jdk/pull/11300

From coleenp at openjdk.org  Thu Dec  1 09:37:40 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 1 Dec 2022 09:37:40 GMT
Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable
In-Reply-To: <c4ophxMSfP2waXPjUz3x4N57crZdQQb-d_xsOIfGmCw=.0de5f1fa-d697-4ca2-aa7a-3c5a4e030236@github.com>
References: <Dj9YfY10SLn8dR1Ez3kEQe4tXm1q5W1TS8_4r3gBUsY=.6c38825a-86e5-4575-a509-683786d242a6@github.com>
 <m0UnY-x47SAtCGdPlMcUKfxd0lWRqURPb3u0wKNCT3w=.97f998ef-48f0-4b4f-a144-822ebcf7dc98@github.com>
 <WC0j16HlKWRzgKhC9xjs_ZQr-42Bk7_cMOOCK3rY-yo=.c5f6e693-7d51-4277-86ab-ad250967041c@github.com>
 <c4ophxMSfP2waXPjUz3x4N57crZdQQb-d_xsOIfGmCw=.0de5f1fa-d697-4ca2-aa7a-3c5a4e030236@github.com>
Message-ID: <vT5H2q2KdbKCZFOKbvppOVfX0MPor8anRIu6zpcOOXk=.45553098-fa84-4cc1-950f-18df1bc948a6@github.com>

On Mon, 28 Nov 2022 22:14:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> add() is supposed to add a new object with tag. There is an assert() in its body that checks it. By removing the assert, add() can be used for updating as well.
>
> Are you suggesting that `add`  can also act as a `replace` operation? I would think we would want a separate method for that.

Yes, this could have a replace operation that does below which would be better:

void JvmtiTagMapTable::replace(oop o, jlong tag) {
    JvmtiTagMapEntry key(o);
      bool is_added = _rrht_table.put(new_entry, tag);
      assert(!is_added, "should not be added");
}

-------------

PR: https://git.openjdk.org/jdk/pull/11288

From duke at openjdk.org  Thu Dec  1 09:37:42 2022
From: duke at openjdk.org (Afshin Zafari)
Date: Thu, 1 Dec 2022 09:37:42 GMT
Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable
In-Reply-To: <vT5H2q2KdbKCZFOKbvppOVfX0MPor8anRIu6zpcOOXk=.45553098-fa84-4cc1-950f-18df1bc948a6@github.com>
References: <Dj9YfY10SLn8dR1Ez3kEQe4tXm1q5W1TS8_4r3gBUsY=.6c38825a-86e5-4575-a509-683786d242a6@github.com>
 <m0UnY-x47SAtCGdPlMcUKfxd0lWRqURPb3u0wKNCT3w=.97f998ef-48f0-4b4f-a144-822ebcf7dc98@github.com>
 <WC0j16HlKWRzgKhC9xjs_ZQr-42Bk7_cMOOCK3rY-yo=.c5f6e693-7d51-4277-86ab-ad250967041c@github.com>
 <c4ophxMSfP2waXPjUz3x4N57crZdQQb-d_xsOIfGmCw=.0de5f1fa-d697-4ca2-aa7a-3c5a4e030236@github.com>
 <vT5H2q2KdbKCZFOKbvppOVfX0MPor8anRIu6zpcOOXk=.45553098-fa84-4cc1-950f-18df1bc948a6@github.com>
Message-ID: <YP3Fxvxi8U6zdSWDqb5yJXL9Ni1sDKl-qnMxyBINlIg=.1fd06d04-9434-4147-9efb-5cf5d383d5f2@github.com>

On Tue, 29 Nov 2022 23:07:15 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Are you suggesting that `add`  can also act as a `replace` operation? I would think we would want a separate method for that.
>
> Yes, this could have a replace operation that does below which would be better:
> 
> void JvmtiTagMapTable::replace(oop o, jlong tag) {
>     JvmtiTagMapEntry key(o);
>       bool is_added = _rrht_table.put(new_entry, tag);
>       assert(!is_added, "should not be added");
> }

I didn't notice the suggested name (`replace()`), so It is implemented as `update()` method.
It is tested locally by running tests vmTestbse/nsk/jvmti and vmTEstbase//nck/jdi.
tier1-5 are also passed.

-------------

PR: https://git.openjdk.org/jdk/pull/11288

From coleenp at openjdk.org  Thu Dec  1 09:37:46 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 1 Dec 2022 09:37:46 GMT
Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable
In-Reply-To: <Dj9YfY10SLn8dR1Ez3kEQe4tXm1q5W1TS8_4r3gBUsY=.6c38825a-86e5-4575-a509-683786d242a6@github.com>
References: <Dj9YfY10SLn8dR1Ez3kEQe4tXm1q5W1TS8_4r3gBUsY=.6c38825a-86e5-4575-a509-683786d242a6@github.com>
Message-ID: <xKFyqFkQJrznYaIcWmvz2_nNzfhAEqekx5kiTagk1WU=.9ca4dd17-248e-447b-a83e-0d72023e1cb1@github.com>

On Tue, 22 Nov 2022 14:48:11 GMT, Afshin Zafari <duke at openjdk.org> wrote:

> test of tier1-5 passed.

src/hotspot/share/prims/jvmtiTagMapTable.hpp line 41:

> 39:   JvmtiTagMapEntry* next() const {
> 40:     return (JvmtiTagMapEntry*)HashtableEntry<WeakHandle, mtServiceability>::next();
> 41:   }

This should add a comment above JvmtiTagMapEntry that the entry is the key (could be renamed JvmtiTagMapKey).  Also add a comment above that the oop is needed for lookup rather than creating a WeakHandle during lookup because the HeapWalker may walk soon to be dead objects and creating a WeakHandle for an otherwise dead object makes G1 unhappy.

-------------

PR: https://git.openjdk.org/jdk/pull/11288

From stuefe at openjdk.org  Thu Dec  1 09:54:53 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 1 Dec 2022 09:54:53 GMT
Subject: RFR: JDK-8296907: VMError: add optional callstacks,
 siginfo for secondary errors [v8]
In-Reply-To: <x1kul17oEaJ-UX6ZGPv8OcsxN8QfYlME_d39aSATk-Q=.f0e0169c-15f5-4b4b-8235-68f8e68ec43c@github.com>
References: <x1kul17oEaJ-UX6ZGPv8OcsxN8QfYlME_d39aSATk-Q=.f0e0169c-15f5-4b4b-8235-68f8e68ec43c@github.com>
Message-ID: <xBS-ff3743RJTgEhe7ug6-w6dA484dlWth9Fd-FSI_4=.4cc191f1-157c-40f3-a2b0-0b65c55d18d5@github.com>

> This was motivated by discussions we had in https://github.com/openjdk/jdk/pull/11017.
> 
> To aid in analyzing secondary errors during error reporting, it would be useful to see their callstacks for secondary errors. But printing callstacks during error reporting is unsafe - if we get a second crash or assert, it will cause infinite recursion and interrupt error reporting. Also, the hs-err file would be quite verbose. Therefore this feature is optional and limited to debug builds. 
> 
> ---
> 
> Patch
> 
> - adds optional callstack/siginfo printing via debug-only switch `-XX:+ErrorLogSecondaryErrorDetails`.
> - fixes a bug in secondary error handling where we would use the global scratch buffer recursively (via stringStream); that could lead to confusing output since it is used by the error log stream already. We can print directly to that one instead.
> - Removed a stray newline from print_native_stack to clean output.
> - added regression testing for this feature. I removed my name from the test since we don't do this anymore.
> - added clarifying comments to the test and code
> - added SAP copyright to the regression test (we introduced it years ago for JDK-8065895)
> 
> Output looks like this:
> 
> 
> $ java ... -XX:+ErrorLogSecondaryErrorDetails
> 
> 
> will produce, for secondary errors, siginfo and call stack.
> 
> 
> [error occurred during error reporting (test secondary crash 1), id 0xb, SIGSEGV (0xb) at pc=0x00007fddfe8a0a61]
> [siginfo: si_signo: 11 (SIGSEGV), si_code: 128 (SI_KERNEL), si_addr: 0x0000000000000000]
> [stack: Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x1ceea61]  VMError::controlled_crash(int)+0x241  (vmError.cpp:1946)
> V  [libjvm.so+0x1cf413f]  VMError::report(outputStream*, bool)+0x46bf  (vmError.cpp:564)
> V  [libjvm.so+0x1cf516b]  VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x19b  (vmError.cpp:1709)
> V  [libjvm.so+0x1cf5e8f]  VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*, char const*, ...)+0x8f  (vmError.cpp:1467)
> V  [libjvm.so+0x1cf5ec2]  VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*)+0x22  (vmError.cpp:1473)
> V  [libjvm.so+0x1a549e7]  JVM_handle_linux_signal+0x1f7  (signals_posix.cpp:656)
> C  [libc.so.6+0x43090]
> V  [libjvm.so+0x11d6965]  JNI_CreateJavaVM+0x5b5  (jni.cpp:3662)
> C  [libjli.so+0x4013]  JavaMain+0x93  (java.c:1457)
> C  [libjli.so+0x800d]  ThreadJavaMain+0xd  (java_md.c:650)
> ]

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  resolve conflict

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11118/files
  - new: https://git.openjdk.org/jdk/pull/11118/files/527be76c..00af4b99

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11118&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11118&range=06-07

  Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11118.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11118/head:pull/11118

PR: https://git.openjdk.org/jdk/pull/11118

From stuefe at openjdk.org  Thu Dec  1 10:01:54 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 1 Dec 2022 10:01:54 GMT
Subject: RFR: JDK-8296907: VMError: add optional callstacks,
 siginfo for secondary errors [v9]
In-Reply-To: <x1kul17oEaJ-UX6ZGPv8OcsxN8QfYlME_d39aSATk-Q=.f0e0169c-15f5-4b4b-8235-68f8e68ec43c@github.com>
References: <x1kul17oEaJ-UX6ZGPv8OcsxN8QfYlME_d39aSATk-Q=.f0e0169c-15f5-4b4b-8235-68f8e68ec43c@github.com>
Message-ID: <jOoyUzl0itwRtbeHzpB9NMX58IQrqsT3e6NirdgMlY4=.05fb129c-6a11-4b6b-970d-dc28f8e02d76@github.com>

> This was motivated by discussions we had in https://github.com/openjdk/jdk/pull/11017.
> 
> To aid in analyzing secondary errors during error reporting, it would be useful to see their callstacks for secondary errors. But printing callstacks during error reporting is unsafe - if we get a second crash or assert, it will cause infinite recursion and interrupt error reporting. Also, the hs-err file would be quite verbose. Therefore this feature is optional and limited to debug builds. 
> 
> ---
> 
> Patch
> 
> - adds optional callstack/siginfo printing via debug-only switch `-XX:+ErrorLogSecondaryErrorDetails`.
> - fixes a bug in secondary error handling where we would use the global scratch buffer recursively (via stringStream); that could lead to confusing output since it is used by the error log stream already. We can print directly to that one instead.
> - Removed a stray newline from print_native_stack to clean output.
> - added regression testing for this feature. I removed my name from the test since we don't do this anymore.
> - added clarifying comments to the test and code
> - added SAP copyright to the regression test (we introduced it years ago for JDK-8065895)
> 
> Output looks like this:
> 
> 
> $ java ... -XX:+ErrorLogSecondaryErrorDetails
> 
> 
> will produce, for secondary errors, siginfo and call stack.
> 
> 
> [error occurred during error reporting (test secondary crash 1), id 0xb, SIGSEGV (0xb) at pc=0x00007fddfe8a0a61]
> [siginfo: si_signo: 11 (SIGSEGV), si_code: 128 (SI_KERNEL), si_addr: 0x0000000000000000]
> [stack: Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x1ceea61]  VMError::controlled_crash(int)+0x241  (vmError.cpp:1946)
> V  [libjvm.so+0x1cf413f]  VMError::report(outputStream*, bool)+0x46bf  (vmError.cpp:564)
> V  [libjvm.so+0x1cf516b]  VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x19b  (vmError.cpp:1709)
> V  [libjvm.so+0x1cf5e8f]  VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*, char const*, ...)+0x8f  (vmError.cpp:1467)
> V  [libjvm.so+0x1cf5ec2]  VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*)+0x22  (vmError.cpp:1473)
> V  [libjvm.so+0x1a549e7]  JVM_handle_linux_signal+0x1f7  (signals_posix.cpp:656)
> C  [libc.so.6+0x43090]
> V  [libjvm.so+0x11d6965]  JNI_CreateJavaVM+0x5b5  (jni.cpp:3662)
> C  [libjli.so+0x4013]  JavaMain+0x93  (java.c:1457)
> C  [libjli.so+0x800d]  ThreadJavaMain+0xd  (java_md.c:650)
> ]

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  Feedback axel

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11118/files
  - new: https://git.openjdk.org/jdk/pull/11118/files/00af4b99..3d5880bf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11118&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11118&range=07-08

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11118.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11118/head:pull/11118

PR: https://git.openjdk.org/jdk/pull/11118

From stuefe at openjdk.org  Thu Dec  1 10:07:40 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 1 Dec 2022 10:07:40 GMT
Subject: RFR: JDK-8296907: VMError: add optional callstacks,
 siginfo for secondary errors [v10]
In-Reply-To: <x1kul17oEaJ-UX6ZGPv8OcsxN8QfYlME_d39aSATk-Q=.f0e0169c-15f5-4b4b-8235-68f8e68ec43c@github.com>
References: <x1kul17oEaJ-UX6ZGPv8OcsxN8QfYlME_d39aSATk-Q=.f0e0169c-15f5-4b4b-8235-68f8e68ec43c@github.com>
Message-ID: <jaE8Twi44sJj6bm7EuzgX5fvHdpwuVu4Id564wTSTCE=.5c3974ef-104e-4c3b-bc28-1f753fba5e55@github.com>

> This was motivated by discussions we had in https://github.com/openjdk/jdk/pull/11017.
> 
> To aid in analyzing secondary errors during error reporting, it would be useful to see their callstacks for secondary errors. But printing callstacks during error reporting is unsafe - if we get a second crash or assert, it will cause infinite recursion and interrupt error reporting. Also, the hs-err file would be quite verbose. Therefore this feature is optional and limited to debug builds. 
> 
> ---
> 
> Patch
> 
> - adds optional callstack/siginfo printing via debug-only switch `-XX:+ErrorLogSecondaryErrorDetails`.
> - fixes a bug in secondary error handling where we would use the global scratch buffer recursively (via stringStream); that could lead to confusing output since it is used by the error log stream already. We can print directly to that one instead.
> - Removed a stray newline from print_native_stack to clean output.
> - added regression testing for this feature. I removed my name from the test since we don't do this anymore.
> - added clarifying comments to the test and code
> - added SAP copyright to the regression test (we introduced it years ago for JDK-8065895)
> 
> Output looks like this:
> 
> 
> $ java ... -XX:+ErrorLogSecondaryErrorDetails
> 
> 
> will produce, for secondary errors, siginfo and call stack.
> 
> 
> [error occurred during error reporting (test secondary crash 1), id 0xb, SIGSEGV (0xb) at pc=0x00007fddfe8a0a61]
> [siginfo: si_signo: 11 (SIGSEGV), si_code: 128 (SI_KERNEL), si_addr: 0x0000000000000000]
> [stack: Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x1ceea61]  VMError::controlled_crash(int)+0x241  (vmError.cpp:1946)
> V  [libjvm.so+0x1cf413f]  VMError::report(outputStream*, bool)+0x46bf  (vmError.cpp:564)
> V  [libjvm.so+0x1cf516b]  VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x19b  (vmError.cpp:1709)
> V  [libjvm.so+0x1cf5e8f]  VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*, char const*, ...)+0x8f  (vmError.cpp:1467)
> V  [libjvm.so+0x1cf5ec2]  VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*)+0x22  (vmError.cpp:1473)
> V  [libjvm.so+0x1a549e7]  JVM_handle_linux_signal+0x1f7  (signals_posix.cpp:656)
> C  [libc.so.6+0x43090]
> V  [libjvm.so+0x11d6965]  JNI_CreateJavaVM+0x5b5  (jni.cpp:3662)
> C  [libjli.so+0x4013]  JavaMain+0x93  (java.c:1457)
> C  [libjli.so+0x800d]  ThreadJavaMain+0xd  (java_md.c:650)
> ]

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  fix test after merge

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11118/files
  - new: https://git.openjdk.org/jdk/pull/11118/files/3d5880bf..0bb59926

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11118&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11118&range=08-09

  Stats: 38 lines in 1 file changed: 0 ins; 32 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/11118.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11118/head:pull/11118

PR: https://git.openjdk.org/jdk/pull/11118

From stuefe at openjdk.org  Thu Dec  1 10:10:28 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 1 Dec 2022 10:10:28 GMT
Subject: RFR: JDK-8296907: VMError: add optional callstacks,
 siginfo for secondary errors [v11]
In-Reply-To: <x1kul17oEaJ-UX6ZGPv8OcsxN8QfYlME_d39aSATk-Q=.f0e0169c-15f5-4b4b-8235-68f8e68ec43c@github.com>
References: <x1kul17oEaJ-UX6ZGPv8OcsxN8QfYlME_d39aSATk-Q=.f0e0169c-15f5-4b4b-8235-68f8e68ec43c@github.com>
Message-ID: <bmVxR4kMTfct8Sl2BiNvFqd4MYENT5fFPlBHV3EnTlA=.dbba14ae-40d2-4ebe-b9d6-3b49ca1fc3c1@github.com>

> This was motivated by discussions we had in https://github.com/openjdk/jdk/pull/11017.
> 
> To aid in analyzing secondary errors during error reporting, it would be useful to see their callstacks for secondary errors. But printing callstacks during error reporting is unsafe - if we get a second crash or assert, it will cause infinite recursion and interrupt error reporting. Also, the hs-err file would be quite verbose. Therefore this feature is optional and limited to debug builds. 
> 
> ---
> 
> Patch
> 
> - adds optional callstack/siginfo printing via debug-only switch `-XX:+ErrorLogSecondaryErrorDetails`.
> - fixes a bug in secondary error handling where we would use the global scratch buffer recursively (via stringStream); that could lead to confusing output since it is used by the error log stream already. We can print directly to that one instead.
> - Removed a stray newline from print_native_stack to clean output.
> - added regression testing for this feature. I removed my name from the test since we don't do this anymore.
> - added clarifying comments to the test and code
> - added SAP copyright to the regression test (we introduced it years ago for JDK-8065895)
> 
> Output looks like this:
> 
> 
> $ java ... -XX:+ErrorLogSecondaryErrorDetails
> 
> 
> will produce, for secondary errors, siginfo and call stack.
> 
> 
> [error occurred during error reporting (test secondary crash 1), id 0xb, SIGSEGV (0xb) at pc=0x00007fddfe8a0a61]
> [siginfo: si_signo: 11 (SIGSEGV), si_code: 128 (SI_KERNEL), si_addr: 0x0000000000000000]
> [stack: Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x1ceea61]  VMError::controlled_crash(int)+0x241  (vmError.cpp:1946)
> V  [libjvm.so+0x1cf413f]  VMError::report(outputStream*, bool)+0x46bf  (vmError.cpp:564)
> V  [libjvm.so+0x1cf516b]  VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x19b  (vmError.cpp:1709)
> V  [libjvm.so+0x1cf5e8f]  VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*, char const*, ...)+0x8f  (vmError.cpp:1467)
> V  [libjvm.so+0x1cf5ec2]  VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*)+0x22  (vmError.cpp:1473)
> V  [libjvm.so+0x1a549e7]  JVM_handle_linux_signal+0x1f7  (signals_posix.cpp:656)
> C  [libc.so.6+0x43090]
> V  [libjvm.so+0x11d6965]  JNI_CreateJavaVM+0x5b5  (jni.cpp:3662)
> C  [libjli.so+0x4013]  JavaMain+0x93  (java.c:1457)
> C  [libjli.so+0x800d]  ThreadJavaMain+0xd  (java_md.c:650)
> ]

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  Revert accidental change

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11118/files
  - new: https://git.openjdk.org/jdk/pull/11118/files/0bb59926..ae92af84

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11118&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11118&range=09-10

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11118.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11118/head:pull/11118

PR: https://git.openjdk.org/jdk/pull/11118

From fyang at openjdk.org  Thu Dec  1 10:14:33 2022
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 1 Dec 2022 10:14:33 GMT
Subject: RFR: 8297763: Fix missing stub code expansion before align() in
 shared trampolines [v2]
In-Reply-To: <QOm1rf2yvHIVvNhyiPG97YQOX-_5j1VjLoYKbl20lEQ=.98674f31-37eb-4967-bcfe-caad03b5d9ba@github.com>
References: <T5fCT6B-2hhjmlMaRuu5iHfMI-gxkuFJp3jtjGh7ZtM=.719d411d-da4f-482b-af14-c9caee93b865@github.com>
 <QOm1rf2yvHIVvNhyiPG97YQOX-_5j1VjLoYKbl20lEQ=.98674f31-37eb-4967-bcfe-caad03b5d9ba@github.com>
Message-ID: <hXb-nZ_3CbhHULvpC11ZmgHK4hiKsQYTioGm4duTmFc=.4c457487-3edd-4b54-87af-1b3335192009@github.com>

On Wed, 30 Nov 2022 11:37:58 GMT, Xiaolin Zheng <xlinzheng at openjdk.org> wrote:

>> This patch fixes missing stub code expansion logic before `align()` for AArch64 and RISC-V.
>> 
>> The `align()` at most creates 4-byte padding, so a `NativeInstruction::instruction_size` is enough.
>> 
>> I am considering pre-calculating the total trampoline sizes and allocating them in batches, but maybe after this one, for this is a quick fix to unblock https://github.com/openjdk/jdk/pull/11188. Please see that thread.
>> 
>> The `assert_alignment(pc());` added in the RISC-V part shows that RVC doesn't change the trampoline stub / static stub logic, so there is no need to adjust the trampoline size for it. [1]
>> 
>> Tested AArch64 hotspot tier1~3, and 4 is still running; tested RISC-V hotspot tier1~2, and 3~4 are still running.
>> 
>> Thanks,
>> Xiaolin
>> 
>> [1] https://github.com/openjdk/jdk/blob/2deb318c9f047ec5a4b160d66a4b52f93688ec42/src/hotspot/cpu/riscv/macroAssembler_riscv.cpp#L3125-L3126
>
> Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix as to comments

Looks reasonable to me.

-------------

Marked as reviewed by fyang (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11414

From sjohanss at openjdk.org  Thu Dec  1 10:31:49 2022
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Thu, 1 Dec 2022 10:31:49 GMT
Subject: RFR: 8297427: Avoid keeping class loaders alive when executing
 ClassLoaderStatsVMOperation [v2]
In-Reply-To: <0f3IQ2iYzLmNzwRM6nYUvW7NK_EuawncqHhlhjjIX6g=.f4e4ec7e-3f6f-40cb-991e-100eb749b71e@github.com>
References: <YdNWoA79MYjB7s-lcu1eYljYAGoV46gjbnYqX0PzJGc=.93d62d9d-0642-4a0d-9f90-b8b1885d4ace@github.com>
 <qVWmEYZDcXkHs5UN68wzWCFctsz_9zfg1XjdbG7FfKw=.1745c615-98ef-46cd-82df-590fd1673a1c@github.com>
 <0f3IQ2iYzLmNzwRM6nYUvW7NK_EuawncqHhlhjjIX6g=.f4e4ec7e-3f6f-40cb-991e-100eb749b71e@github.com>
Message-ID: <0wEZi5IszIuWbihPdi8ZQxUDeMbWtHAGBrz3wwvqdFc=.598c912c-b77c-42a5-98d2-93fc74682935@github.com>

On Thu, 1 Dec 2022 00:25:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Stefan Johansson has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Print object to ensure it is kept alive
>>  - Revert "Axel comments to use templates"
>>    
>>    This reverts commit 8800ef089b62cf173147b68adb2ee993b7e72980.
>>  - Revert "Missing include for minimal"
>>    
>>    This reverts commit 424e0f9d831279ba2d1986ebacb499f8d4a6c078.
>
> A few drive-by comments on the test.

Thanks for your comments @dholmes-ora and for your reviews @stefank and @fisk.

-------------

PR: https://git.openjdk.org/jdk/pull/11300

From sjohanss at openjdk.org  Thu Dec  1 10:33:38 2022
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Thu, 1 Dec 2022 10:33:38 GMT
Subject: Integrated: 8297427: Avoid keeping class loaders alive when executing
 ClassLoaderStatsVMOperation
In-Reply-To: <YdNWoA79MYjB7s-lcu1eYljYAGoV46gjbnYqX0PzJGc=.93d62d9d-0642-4a0d-9f90-b8b1885d4ace@github.com>
References: <YdNWoA79MYjB7s-lcu1eYljYAGoV46gjbnYqX0PzJGc=.93d62d9d-0642-4a0d-9f90-b8b1885d4ace@github.com>
Message-ID: <d1hif9AHOIFWiqXl0CxZqrnRyfFcj1W_Ja0jLafud5o=.9b176059-4a99-47ea-bb26-01f624abe919@github.com>

On Tue, 22 Nov 2022 20:54:54 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> Please review this change to avoid keeping classes alive only due to the `ClassLoaderStatsVMOperation`.
> 
> **Summary**
> The `ClassLoaderStatsVMOperation` is gathering statistics about the active class loaders in a safepoint. The way the `ClassLoaderDataGraph` is iterated will keep the class loaders live. This is not really needed since everything is done in a safepoint and nothing needs to be explicitly kept alive. This has not been a problem prior to concurrent class unloading in ZGC. With fully concurrent class unloading a `ClassLoaderStatsVMOperation` can occur during a collection and more classes than needed might be kept alive. This could in turn lead to premature Metaspace OOM. 
> 
> The solution is to not keep the class loaders alive due to the iteration in `ClassLoaderStatsVMOperation`.
> 
> **Testing**
> * Added a new test that covers the two different ways a class could previously be kept alive by the VM operation. The test passes after the fix but failed before.  
> * Mach5 tier 1-3

This pull request has now been integrated.

Changeset: eea1a8a9
Author:    Stefan Johansson <sjohanss at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/eea1a8a95e172ef5221ab622d171f46cc6cbb598
Stats:     242 lines in 10 files changed: 237 ins; 0 del; 5 mod

8297427: Avoid keeping class loaders alive when executing ClassLoaderStatsVMOperation

Reviewed-by: eosterlund, stefank

-------------

PR: https://git.openjdk.org/jdk/pull/11300

From stefan.johansson at oracle.com  Thu Dec  1 10:52:50 2022
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Thu, 1 Dec 2022 11:52:50 +0100
Subject: [External] : Re: Extend Native Memory Tracking over the JDK ?
 (was: Proposal: track zlib native memory usage with NMT)
In-Reply-To: <CAA-vtUwPXTD71ztTbwL5ayzX1jFFjGq1VXGrJ3z=pBFGMdatVA@mail.gmail.com>
References: <CAA-vtUzvyqb_LZ9d1Z80oSvzyqpi89053O3B+oDZF4oZ85CuZg@mail.gmail.com>
 <c5db2105-3b78-0b77-779f-011c8649f476@oracle.com>
 <CAA-vtUxrP49w523EQ3yKFh4Zo5W+HMtqpGcsUxOEMkwZUOQ0zQ@mail.gmail.com>
 <a20d3253-47b6-41dc-b8e4-0b894137ed90@app.fastmail.com>
 <4f7deee9-366d-05a2-9268-09a25a138d8d@oracle.com>
 <cb8b2707-4f43-4e91-83ac-9d3b1f6df2bb@app.fastmail.com>
 <CAA-vtUwPXTD71ztTbwL5ayzX1jFFjGq1VXGrJ3z=pBFGMdatVA@mail.gmail.com>
Message-ID: <4a2dbc13-dc65-e8ba-a40c-ff6b1cef931d@oracle.com>

Hi Thomas and Carter,

I opened up a PR for this to allow more specific comments on the 
implementation:
https://github.com/openjdk/jdk/pull/11449

If this discussion leads to us not wanting to proceed with the change I 
will withdraw the PR.

Some more comments below.

On 2022-12-01 08:26, Thomas St?fe wrote:
> Hi Carter, Stefan,
> 
> thank you, I think it is good to have this discussion, it is important.
> 
> Side note, the discussion steered away from my original question - 
> whether to instrument the JDK with NMT. I still would love to discuss 
> that, too.
> 

Sorry for that :)

> About opening NMT up for user consumption, that is of course possible. 
> But I think the bigger question is which data we want to open for user 
> consumption, and at what granularity. And what contracts do we enter 
> when we do this.
> 

To me this is not so much opening it up, but just making it much simpler 
to get the already available data (JFR instead of jcmd). I get your 
point that when we make it easier it will likely get more visibility and 
that could generate expectations. To me the contract on these events 
should not be much harder than, for example, the contract we have on the 
format of GC logs. So we should not be locked down by this.

> NMT was originally a hotspot-dev-centric tool. It has a lot of 
> idiosyncrasies. Interpreting the results needs detailed knowledge about 
> hotspot memory management. Some examples:
> 
> - its reports are not consistent across JDK versions, not even across 
> different patch levels of the same JDK. So you cannot compare results, 
> say, between JDK11 and 17.
> - before a certain version X (I believe JDK 11), the full thread stacks 
> were accounted for instead of just the in-use portion of the thread 
> stacks. I remember reading blogs about how thread stack consumption went 
> down when all that changed was NMT reporting.
> - The memory sizes it shows may not have much to do with real RSS. It 
> systematically underreports some things, since it omits libc overhead 
> and retention, usage by system- and JNI libraries. But it also 
> overreports things since it mostly (not always) accounts in terms of 
> "committed" memory, which usually means mmap()ed or malloc()ed memory. 
> But that is just committed, not physical memory, it does not translate 
> to RSS usage directly. That memory may never be touched. OTOH NMT probes 
> thread stacks with mincore(), so for that section, "committed" really 
> means "physical".
> 

I agree that NMT is a low-level tool and that it's not perfect. But in 
some cases I think it's the best way to see the memory consumption of 
the JVM. Especially since you can zoom in on certain areas.

> I am fine with opening up NMT via JFR. But does this mean we have to be 
> more consistent? Do we have to care about downward compatibility of NMT 
> reports? Are we then still free to redesign the tag system (see my 
> original mail) or will this tie us down with the current NMT tag system 
> forever? As a negative example, JFR exposes metaspace allocator details 
> (chunk statistics) which have been broken ever since JDK 16 when the 
> underlying implementation changed.
> 

I think a tag based system for NMT would be awesome and it would be 
really sad if exposing the NMT information through JFR would stop us 
from doing this. Hopefully the only thing we need to do when improving 
NMT is to do CSRs. One possible way to avoid constraints even more would 
be to tag those events as "experimental" at first. This would signal 
that user should not rely on them.

> Therefore I am curious about what end users use NMT really for.
> 
> @Carter: can you give us examples of which NMT sections had been 
> particularly useful to you? Maybe we can define a subset to expose 
> instead of exposing all tags. E.g. I can see thread stack usage being 
> very useful, but things like ObjectMonitor footprint not so much.
>

I agree that not to many users would care about the ObjectMonitor 
footprint, but unless we get constrained by what we report I would like 
to report all. If there are constraints, this might be a good middle road.

Thanks,
Stefan

> Cheers, Thomas
> 
> 
> 
> 
> On Wed, Nov 30, 2022 at 9:45 PM Carter Kozak <ckozak at ckozak.net 
> <mailto:ckozak at ckozak.net>> wrote:
> 
>     __
>     This looks fantastic, thank you so much! I can confirm that the
>     proposed
>     design would solve my use-case.
> 
>     I'd enjoy discussing the NMT event? contract somewhere more specific
>     to the implementation, but I don't want to muddle this thread with
>     implementation details.
> 
>     Carter Kozak
> 
>     On Wed, Nov 30, 2022, at 03:37, Stefan Johansson wrote:
>>     Hi Carter,
>>
>>     Your mail made me pick up an old item from my wishlist: to have
>>     native
>>     memory tracking information available in JFR recordings. When we,
>>     in GC,
>>     do improvements to decrease the native memory overhead of our
>>     algorithms, NMT is a very good tool to track the progress. We have
>>     scripts that sound very similar to what you describe and more than
>>     once
>>     I've been thinking about adding this information into JFR. But it has
>>     not been a priority and the greater value has been unclear.
>>
>>     Hearing that others might also benefit from such a change I took a
>>     discussion with the JFR team on how to best proceed with this. I have
>>     created a branch for this and will probably create a PR for it
>>     shortly,
>>     but I thought I would drop it here first:
>>     https://github.com/kstefanj/jdk/tree/8157023-jfr-events-for-nmt
>>     <https://urldefense.com/v3/__https://github.com/kstefanj/jdk/tree/8157023-jfr-events-for-nmt__;!!ACWV5N9M2RV99hQ!IpI1Gbn4N8zH6ZeK20WzMC2bG8XfncJ3sH15GZk2mG3AozRbI4h6b1ZtAhWMNr4qsHE1_dLeDFZWtzF6LpA4XQ4zFFGN$>
>>
>>     The change adds two new JFR events: one for the total usage and
>>     one for
>>     the usage of each memory type. These are sent only if Native Memory
>>     Tracking is turned on, and they are enabled in the default JFR
>>     profile
>>     with an interval of 1s. This might change during reviewing but it
>>     was a
>>     good starting point.
>>
>>     With this you will be able to use JFR streaming to access the events
>>     from within your running process. I hope this will help your use
>>     cases
>>     and please let us know if you have any comments or suggestions.
>>
>>     Thanks,
>>     Stefan
> 

From sjohanss at openjdk.org  Thu Dec  1 10:58:31 2022
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Thu, 1 Dec 2022 10:58:31 GMT
Subject: RFR: 8157023: jfr events for nmt
Message-ID: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>

Please review this enhancement to include NMT information in JFR recordings.

**Summary**
Native Memory Tracking summary information can be obtained from a running VM using `jcmd` if started with `-XX:NativeMemoryTracking=summary/detail`. Using `jcmd` requires you to run a separate process and to parse the output to get the needed information. This change adds JFR events for NMT information to enable additional ways to consume the NMT data.

There are two new events added:
* _NativeMemoryUsage_ - The total native memory usage.
* _NativeMemoryUsagePart_ - The native memory usage for each component.

These events are sent periodically and by default the interval is 1s. This can of course be discussed, but that is the staring point. When NMT is not enabled on events will be sent.

**Testing**
* Added a simple test to verify that the events are sent as expected depending on if NMT is enabled or not.
* Mach5 sanity testing

-------------

Commit messages:
 - Update profile.jfc and explict disable NMT in test
 - Test comments from egahlin
 - Add missing newlines at end of files
 - Basic test for NMT events
 - egahlin comments
 - 8157023: Integrate NMT with JFR

Changes: https://git.openjdk.org/jdk/pull/11449/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11449&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8157023
  Stats: 300 lines in 8 files changed: 293 ins; 5 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11449.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11449/head:pull/11449

PR: https://git.openjdk.org/jdk/pull/11449

From duke at openjdk.org  Thu Dec  1 11:32:19 2022
From: duke at openjdk.org (Carter Kozak)
Date: Thu, 1 Dec 2022 11:32:19 GMT
Subject: RFR: 8157023: Integrate NMT with JFR
In-Reply-To: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
Message-ID: <uvfe5r95h067-c6M1apWu0ySUjvRBOnzaG-Tv1sp6ao=.9c7f0dae-0e85-4029-a4cd-7452a4d5c302@github.com>

On Thu, 1 Dec 2022 10:48:51 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> Please review this enhancement to include NMT information in JFR recordings.
> 
> **Summary**
> Native Memory Tracking summary information can be obtained from a running VM using `jcmd` if started with `-XX:NativeMemoryTracking=summary/detail`. Using `jcmd` requires you to run a separate process and to parse the output to get the needed information. This change adds JFR events for NMT information to enable additional ways to consume the NMT data.
> 
> There are two new events added:
> * _NativeMemoryUsage_ - The total native memory usage.
> * _NativeMemoryUsagePart_ - The native memory usage for each component.
> 
> These events are sent periodically and by default the interval is 1s. This can of course be discussed, but that is the staring point. When NMT is not enabled on events will be sent.
> 
> **Testing**
> * Added a simple test to verify that the events are sent as expected depending on if NMT is enabled or not.
> * Mach5 sanity testing

src/hotspot/share/jfr/metadata/metadata.xml line 709:

> 707:   </Event>
> 708: 
> 709:   <Event name="NativeMemoryUsagePart" category="Java Virtual Machine, Memory" label="Component Native Memory Usage" description="Native memory usage for a component" stackTrace="false" thread="false"

I found it odd that naming for native memory tracking ?parts? aren?t named consistently.  ?Category? might be more obvious. I don?t have a strong opinion, just thought I?d mention my observation.

src/hotspot/share/services/memReporter.cpp line 832:

> 830: 
> 831:   MemBaseline usage;
> 832:   usage.baseline(true);

In an ideal world we could report totals and category information from the same snapshot, however the periodic event infrastructure doesn?t seem to provide a great way to do that. I don?t think that?s a big deal, but may be worth documenting to avoid confusion as totals may be reported lower than the sum of the parts due to temporal drift.

An option I had considered is to define some form of larger ?NMTSummary? event with reserved+committed fields for each category as well as the totals. The reporting structure would align with the existing NMT summary tooling, but the event would need to be kept up to date with new NMT types, which may not be worthwhile (unless we can create dynamic events using the c apis, which would make things easier). Unclear how this data would be visualized out of the box. I don?t have as much context as I?d like around event design considerations, there may be other reasons I?m not aware of that this suggestion is a bad idea.

src/hotspot/share/services/memReporter.cpp line 861:

> 859: 
> 860:   MemBaseline usage;
> 861:   usage.baseline(true);

Perhaps we could collect event timing here, rather than reading the timer for each memory category? That way it?s easier to align events from a single snapshot.

for this sort of event, I?m not sure if it?s preferable to declare only a start time, start==end, or measure start and end time around the ?baseline(true)? call.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From sjohanss at openjdk.org  Thu Dec  1 12:22:33 2022
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Thu, 1 Dec 2022 12:22:33 GMT
Subject: RFR: 8157023: Integrate NMT with JFR
In-Reply-To: <uvfe5r95h067-c6M1apWu0ySUjvRBOnzaG-Tv1sp6ao=.9c7f0dae-0e85-4029-a4cd-7452a4d5c302@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <uvfe5r95h067-c6M1apWu0ySUjvRBOnzaG-Tv1sp6ao=.9c7f0dae-0e85-4029-a4cd-7452a4d5c302@github.com>
Message-ID: <Kzkoj8lv79TvttlGRK0aTte1_BZT6-vkMWd1pGoO1Ek=.599fa445-2b88-4ef8-ae7c-9e1e0c71eb22@github.com>

On Thu, 1 Dec 2022 11:26:03 GMT, Carter Kozak <duke at openjdk.org> wrote:

>> Please review this enhancement to include NMT information in JFR recordings.
>> 
>> **Summary**
>> Native Memory Tracking summary information can be obtained from a running VM using `jcmd` if started with `-XX:NativeMemoryTracking=summary/detail`. Using `jcmd` requires you to run a separate process and to parse the output to get the needed information. This change adds JFR events for NMT information to enable additional ways to consume the NMT data.
>> 
>> There are two new events added:
>> * _NativeMemoryUsage_ - The total native memory usage.
>> * _NativeMemoryUsagePart_ - The native memory usage for each component.
>> 
>> These events are sent periodically and by default the interval is 1s. This can of course be discussed, but that is the staring point. When NMT is not enabled on events will be sent.
>> 
>> **Testing**
>> * Added a simple test to verify that the events are sent as expected depending on if NMT is enabled or not.
>> * Mach5 sanity testing
>
> src/hotspot/share/jfr/metadata/metadata.xml line 709:
> 
>> 707:   </Event>
>> 708: 
>> 709:   <Event name="NativeMemoryUsagePart" category="Java Virtual Machine, Memory" label="Component Native Memory Usage" description="Native memory usage for a component" stackTrace="false" thread="false"
> 
> I found it odd that naming for native memory tracking ?parts? aren?t named consistently.  ?Category? might be more obvious. I don?t have a strong opinion, just thought I?d mention my observation.

Yes, these names have change a few times during dev and that's why it is out of sync. It should certainly be consistent, but it is really hard to come up with a great name for this. Especially since the different "parts" are so different, compare "GC" and "Object Monitors". Using "Category" has been discussed and I'm not against it, as always naming is very hard.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From sjohanss at openjdk.org  Thu Dec  1 12:30:15 2022
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Thu, 1 Dec 2022 12:30:15 GMT
Subject: RFR: 8157023: Integrate NMT with JFR
In-Reply-To: <uvfe5r95h067-c6M1apWu0ySUjvRBOnzaG-Tv1sp6ao=.9c7f0dae-0e85-4029-a4cd-7452a4d5c302@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <uvfe5r95h067-c6M1apWu0ySUjvRBOnzaG-Tv1sp6ao=.9c7f0dae-0e85-4029-a4cd-7452a4d5c302@github.com>
Message-ID: <xgmkKNIgrAiBWoieuv2rjwhZKs3gHVsW-WdDGypK-5o=.bbdaa17a-65df-4b9f-a14c-cc320d18cfaa@github.com>

On Thu, 1 Dec 2022 11:18:07 GMT, Carter Kozak <duke at openjdk.org> wrote:

>> Please review this enhancement to include NMT information in JFR recordings.
>> 
>> **Summary**
>> Native Memory Tracking summary information can be obtained from a running VM using `jcmd` if started with `-XX:NativeMemoryTracking=summary/detail`. Using `jcmd` requires you to run a separate process and to parse the output to get the needed information. This change adds JFR events for NMT information to enable additional ways to consume the NMT data.
>> 
>> There are two new events added:
>> * _NativeMemoryUsage_ - The total native memory usage.
>> * _NativeMemoryUsagePart_ - The native memory usage for each component.
>> 
>> These events are sent periodically and by default the interval is 1s. This can of course be discussed, but that is the staring point. When NMT is not enabled on events will be sent.
>> 
>> **Testing**
>> * Added a simple test to verify that the events are sent as expected depending on if NMT is enabled or not.
>> * Mach5 sanity testing
>
> src/hotspot/share/services/memReporter.cpp line 832:
> 
>> 830: 
>> 831:   MemBaseline usage;
>> 832:   usage.baseline(true);
> 
> In an ideal world we could report totals and category information from the same snapshot, however the periodic event infrastructure doesn?t seem to provide a great way to do that. I don?t think that?s a big deal, but may be worth documenting to avoid confusion as totals may be reported lower than the sum of the parts due to temporal drift.
> 
> An option I had considered is to define some form of larger ?NMTSummary? event with reserved+committed fields for each category as well as the totals. The reporting structure would align with the existing NMT summary tooling, but the event would need to be kept up to date with new NMT types, which may not be worthwhile (unless we can create dynamic events using the c apis, which would make things easier). Unclear how this data would be visualized out of the box. I don?t have as much context as I?d like around event design considerations, there may be other reasons I?m not aware of that this suggestion is a bad idea.

I agree, it would have been best if just one snapshot could have been used, but as you say the current infrastructure doesn't really support that. What we could do is to use the same event-type for total as for the parts and just let it have the "Memory Type" "Total", but that also feels kind of like a hack. I also agree that the difference should be small, but it might make sense to add a release note or something stating this information. 

I would really like the events to be fine grained and I think that would make us more forward compatible and it would support more use cases. When it comes to out of the box visualization I don't think there will be any, it will be up to however consumes the JFR/NMT data.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From sjohanss at openjdk.org  Thu Dec  1 12:36:12 2022
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Thu, 1 Dec 2022 12:36:12 GMT
Subject: RFR: 8157023: Integrate NMT with JFR
In-Reply-To: <uvfe5r95h067-c6M1apWu0ySUjvRBOnzaG-Tv1sp6ao=.9c7f0dae-0e85-4029-a4cd-7452a4d5c302@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <uvfe5r95h067-c6M1apWu0ySUjvRBOnzaG-Tv1sp6ao=.9c7f0dae-0e85-4029-a4cd-7452a4d5c302@github.com>
Message-ID: <hQ95SChyD6qS95W4AH-ZnGtLEqhHbEOTD0QpqqVHsQo=.22f82c13-d0a9-43d7-91c0-6864f8852e7a@github.com>

On Thu, 1 Dec 2022 11:06:24 GMT, Carter Kozak <duke at openjdk.org> wrote:

>> Please review this enhancement to include NMT information in JFR recordings.
>> 
>> **Summary**
>> Native Memory Tracking summary information can be obtained from a running VM using `jcmd` if started with `-XX:NativeMemoryTracking=summary/detail`. Using `jcmd` requires you to run a separate process and to parse the output to get the needed information. This change adds JFR events for NMT information to enable additional ways to consume the NMT data.
>> 
>> There are two new events added:
>> * _NativeMemoryUsage_ - The total native memory usage.
>> * _NativeMemoryUsagePart_ - The native memory usage for each component.
>> 
>> These events are sent periodically and by default the interval is 1s. This can of course be discussed, but that is the staring point. When NMT is not enabled on events will be sent.
>> 
>> **Testing**
>> * Added a simple test to verify that the events are sent as expected depending on if NMT is enabled or not.
>> * Mach5 sanity testing
>
> src/hotspot/share/services/memReporter.cpp line 861:
> 
>> 859: 
>> 860:   MemBaseline usage;
>> 861:   usage.baseline(true);
> 
> Perhaps we could collect event timing here, rather than reading the timer for each memory category? That way it?s easier to align events from a single snapshot.
> 
> for this sort of event, I?m not sure if it?s preferable to declare only a start time, start==end, or measure start and end time around the ?baseline(true)? call.

Sounds like a good idea. The only potential problem would be a thread view trying to visualize all event when they were sent and seeing a lot being exactly equal might be strange. I'll consult the JFR guys to see what's best to make it easy to verify which samples are from the same baseline.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From rehn at openjdk.org  Thu Dec  1 13:03:45 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Thu, 1 Dec 2022 13:03:45 GMT
Subject: RFR: 8297864: Dead code elimination
Message-ID: <va_DhGhbW7yeCHuFlm1vugbiqYHxZrRsNGhpE61HQ80=.8500833a-60ae-4805-854e-9c0f0bdfe0e4@github.com>

Please consider removing all this dead code.
I did not have any good way of splitting this up and I did not see any benefit is just splitting it up 'just because'.
There is one commit per file couple.
Not much else to say, passes t1-4 and I can build:
linux-aarch64-debug,linux-arm32-debug,linux-ppc64le-debug,linux-s390x-debug,linux-x86,linux-x86-debug,macosx-aarch64-debug,macosx-x64,macosx-x64-debug,windows-x64-debug,windows-x86-debug and zero-x64-debug
Some of them I also built release.

-------------

Commit messages:
 - vframeArray
 - vframe
 - timerTrace
 - timer
 - threadStatisticalInfo
 - threadSMR
 - threads
 - threadHeapSampler
 - thread
 - synchronizer
 - ... and 42 more: https://git.openjdk.org/jdk/compare/79411478...4dd56f2a

Changes: https://git.openjdk.org/jdk/pull/11439/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11439&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297864
  Stats: 1058 lines in 100 files changed: 0 ins; 1037 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/11439.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11439/head:pull/11439

PR: https://git.openjdk.org/jdk/pull/11439

From egahlin at openjdk.org  Thu Dec  1 13:09:11 2022
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 1 Dec 2022 13:09:11 GMT
Subject: RFR: 8157023: Integrate NMT with JFR
In-Reply-To: <hQ95SChyD6qS95W4AH-ZnGtLEqhHbEOTD0QpqqVHsQo=.22f82c13-d0a9-43d7-91c0-6864f8852e7a@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <uvfe5r95h067-c6M1apWu0ySUjvRBOnzaG-Tv1sp6ao=.9c7f0dae-0e85-4029-a4cd-7452a4d5c302@github.com>
 <hQ95SChyD6qS95W4AH-ZnGtLEqhHbEOTD0QpqqVHsQo=.22f82c13-d0a9-43d7-91c0-6864f8852e7a@github.com>
Message-ID: <j0gC8jNVZ4rtyfEZkvzLUDe8_2ocTpXDu6tsgiap_bo=.f09f5862-a334-4646-8627-ce5db327e596@github.com>

On Thu, 1 Dec 2022 12:32:12 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> src/hotspot/share/services/memReporter.cpp line 861:
>> 
>>> 859: 
>>> 860:   MemBaseline usage;
>>> 861:   usage.baseline(true);
>> 
>> Perhaps we could collect event timing here, rather than reading the timer for each memory category? That way it?s easier to align events from a single snapshot.
>> 
>> for this sort of event, I?m not sure if it?s preferable to declare only a start time, start==end, or measure start and end time around the ?baseline(true)? call.
>
> Sounds like a good idea. The only potential problem would be a thread view trying to visualize all event when they were sent and seeing a lot being exactly equal might be strange. I'll consult the JFR guys to see what's best to make it easy to verify which samples are from the same baseline.

Sounds good. We have tried to use the same timestamp for periodic events that come together. This simplifies processing of events, since the timestamp can be used as a key.

Looking at other periodic events, they only set period="everyChunk", which I think means startTime=false implicitly. I think it would be good if this follows the pattern.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From egahlin at openjdk.org  Thu Dec  1 13:27:15 2022
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 1 Dec 2022 13:27:15 GMT
Subject: RFR: 8157023: Integrate NMT with JFR
In-Reply-To: <xgmkKNIgrAiBWoieuv2rjwhZKs3gHVsW-WdDGypK-5o=.bbdaa17a-65df-4b9f-a14c-cc320d18cfaa@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <uvfe5r95h067-c6M1apWu0ySUjvRBOnzaG-Tv1sp6ao=.9c7f0dae-0e85-4029-a4cd-7452a4d5c302@github.com>
 <xgmkKNIgrAiBWoieuv2rjwhZKs3gHVsW-WdDGypK-5o=.bbdaa17a-65df-4b9f-a14c-cc320d18cfaa@github.com>
Message-ID: <eYMaJWbLShtnb2j08gOfnhHXsDg9OswIxQI8rvBqkSQ=.84d846f6-09f4-4f95-a632-08b1c975323d@github.com>

On Thu, 1 Dec 2022 12:27:42 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> src/hotspot/share/services/memReporter.cpp line 832:
>> 
>>> 830: 
>>> 831:   MemBaseline usage;
>>> 832:   usage.baseline(true);
>> 
>> In an ideal world we could report totals and category information from the same snapshot, however the periodic event infrastructure doesn?t seem to provide a great way to do that. I don?t think that?s a big deal, but may be worth documenting to avoid confusion as totals may be reported lower than the sum of the parts due to temporal drift.
>> 
>> An option I had considered is to define some form of larger ?NMTSummary? event with reserved+committed fields for each category as well as the totals. The reporting structure would align with the existing NMT summary tooling, but the event would need to be kept up to date with new NMT types, which may not be worthwhile (unless we can create dynamic events using the c apis, which would make things easier). Unclear how this data would be visualized out of the box. I don?t have as much context as I?d like around event design considerations, there may be other reasons I?m not aware of that this suggestion is a bad idea.
>
> I agree, it would have been best if just one snapshot could have been used, but as you say the current infrastructure doesn't really support that. What we could do is to use the same event-type for total as for the parts and just let it have the "Memory Type" "Total", but that also feels kind of like a hack. I also agree that the difference should be small, but it might make sense to add a release note or something stating this information. 
> 
> I would really like the events to be fine grained and I think that would make us more forward compatible and it would support more use cases. When it comes to out of the box visualization I don't think there will be any, it will be up to however consumes the JFR/NMT data.

I think we should design the events as if we could take everything in one snapshot. That way, we can improve the implementation later. It would be good to write in the event description of NativeMemoryUsage event that it may not add exactly up to the sum of NativeMemoryUsagePart events due to timing issues.

I will look into adding support for snapshots, but it will have to be a later release.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From luhenry at openjdk.org  Thu Dec  1 14:29:20 2022
From: luhenry at openjdk.org (Ludovic Henry)
Date: Thu, 1 Dec 2022 14:29:20 GMT
Subject: RFR: 8297763: Fix missing stub code expansion before align() in
 shared trampolines [v2]
In-Reply-To: <QOm1rf2yvHIVvNhyiPG97YQOX-_5j1VjLoYKbl20lEQ=.98674f31-37eb-4967-bcfe-caad03b5d9ba@github.com>
References: <T5fCT6B-2hhjmlMaRuu5iHfMI-gxkuFJp3jtjGh7ZtM=.719d411d-da4f-482b-af14-c9caee93b865@github.com>
 <QOm1rf2yvHIVvNhyiPG97YQOX-_5j1VjLoYKbl20lEQ=.98674f31-37eb-4967-bcfe-caad03b5d9ba@github.com>
Message-ID: <-kbTLt0YDgp2HlduI-y0qjs92T5kkknfv9yvIbqrbkU=.0193be64-0531-41d4-83f0-98feb0e5c32a@github.com>

On Wed, 30 Nov 2022 11:37:58 GMT, Xiaolin Zheng <xlinzheng at openjdk.org> wrote:

>> This patch fixes missing stub code expansion logic before `align()` for AArch64 and RISC-V.
>> 
>> The `align()` at most creates 4-byte padding, so a `NativeInstruction::instruction_size` is enough.
>> 
>> I am considering pre-calculating the total trampoline sizes and allocating them in batches, but maybe after this one, for this is a quick fix to unblock https://github.com/openjdk/jdk/pull/11188. Please see that thread.
>> 
>> The `assert_alignment(pc());` added in the RISC-V part shows that RVC doesn't change the trampoline stub / static stub logic, so there is no need to adjust the trampoline size for it. [1]
>> 
>> Tested AArch64 hotspot tier1~3, and 4 is still running; tested RISC-V hotspot tier1~2, and 3~4 are still running.
>> 
>> Thanks,
>> Xiaolin
>> 
>> [1] https://github.com/openjdk/jdk/blob/2deb318c9f047ec5a4b160d66a4b52f93688ec42/src/hotspot/cpu/riscv/macroAssembler_riscv.cpp#L3125-L3126
>
> Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix as to comments

Marked as reviewed by luhenry (Author).

-------------

PR: https://git.openjdk.org/jdk/pull/11414

From coleenp at openjdk.org  Thu Dec  1 14:39:26 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 1 Dec 2022 14:39:26 GMT
Subject: RFR: 8297864: Dead code elimination
In-Reply-To: <va_DhGhbW7yeCHuFlm1vugbiqYHxZrRsNGhpE61HQ80=.8500833a-60ae-4805-854e-9c0f0bdfe0e4@github.com>
References: <va_DhGhbW7yeCHuFlm1vugbiqYHxZrRsNGhpE61HQ80=.8500833a-60ae-4805-854e-9c0f0bdfe0e4@github.com>
Message-ID: <HWBYK3KRgRk58LPm7gS1LzMsXI0ud4SnEsImtbvHGDE=.44958feb-2259-49db-becb-6081d02e1389@github.com>

On Wed, 30 Nov 2022 18:10:09 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Please consider removing all this dead code.
> I did not have any good way of splitting this up and I did not see any benefit is just splitting it up 'just because'.
> There is one commit per file couple.
> Not much else to say, passes t1-4 and I can build:
> linux-aarch64-debug,linux-arm32-debug,linux-ppc64le-debug,linux-s390x-debug,linux-x86,linux-x86-debug,macosx-aarch64-debug,macosx-x64,macosx-x64-debug,windows-x64-debug,windows-x86-debug and zero-x64-debug
> Some of them I also built release.

I agree, splitting this up would just waste time.  Please run this tool more often! I see some things I should have removed in here, and some things that were proactively added can be added when there's code to use them.
Looks wonderful.  Will make the code easier to maintain.

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11439

From coleenp at openjdk.org  Thu Dec  1 14:57:07 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 1 Dec 2022 14:57:07 GMT
Subject: RFR: 8291830: jvmti/RedefineClasses/StressRedefine failed:
 assert(!is_null(v)) failed: narrow klass value can never be zero
Message-ID: <Mbg2-xljhBlEKcDh2PK5liK7-rBy-DUUsGo4JzdAal8=.e376169b-5cbd-4123-9f67-d4d219121bdc@github.com>

This has verification code that I'm going to remove so we can backport this.

-------------

Commit messages:
 - remove verification code.
 - 8291830: jvmti/RedefineClasses/StressRedefine failed: assert(!is_null(v)) failed: narrow klass value can never be zero

Changes: https://git.openjdk.org/jdk/pull/11444/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11444&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8291830
  Stats: 21 lines in 5 files changed: 9 ins; 4 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/11444.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11444/head:pull/11444

PR: https://git.openjdk.org/jdk/pull/11444

From duke at openjdk.org  Thu Dec  1 15:46:09 2022
From: duke at openjdk.org (Afshin Zafari)
Date: Thu, 1 Dec 2022 15:46:09 GMT
Subject: RFR: 8297766: Remove UseMallocOnly development option
Message-ID: <34gopg6h0xMvkDTyTltghkTZPl4IZdODxcCJMKN-Ki8=.8117d9d7-9325-482d-b232-49ca862413b2@github.com>

### Description
The UseMallocOnly development option was originally used to detect memory stomping bugs with Arena allocations when the JVM was first in development.

The option has had a few bugs and is not in general use. There are ideas to add another way of Arena canary checking.

### Patch:
All occurrences of UseMallocOnly are removed.

### Tests:
Local, gTests: resourceArea and Arena
Mach5: tier1-5

-------------

Commit messages:
 - 8297766: Remove UseMallocOnly development option
 - 8297766: Remove UseMallocOnly development option
 - UseMallocOnly instances are removed

Changes: https://git.openjdk.org/jdk/pull/11456/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11456&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297766
  Stats: 219 lines in 8 files changed: 1 ins; 196 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/11456.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11456/head:pull/11456

PR: https://git.openjdk.org/jdk/pull/11456

From rschmelter at openjdk.org  Thu Dec  1 16:07:08 2022
From: rschmelter at openjdk.org (Ralf Schmelter)
Date: Thu, 1 Dec 2022 16:07:08 GMT
Subject: RFR: JDK-8296907: VMError: add optional callstacks,
 siginfo for secondary errors [v11]
In-Reply-To: <bmVxR4kMTfct8Sl2BiNvFqd4MYENT5fFPlBHV3EnTlA=.dbba14ae-40d2-4ebe-b9d6-3b49ca1fc3c1@github.com>
References: <x1kul17oEaJ-UX6ZGPv8OcsxN8QfYlME_d39aSATk-Q=.f0e0169c-15f5-4b4b-8235-68f8e68ec43c@github.com>
 <bmVxR4kMTfct8Sl2BiNvFqd4MYENT5fFPlBHV3EnTlA=.dbba14ae-40d2-4ebe-b9d6-3b49ca1fc3c1@github.com>
Message-ID: <TIRVnzzV8rmLobs4gme6WXjspmVUQ5TnjqJJgrCr7O4=.3bc6d0fa-2ec3-4824-aafc-8f38d65b85d7@github.com>

On Thu, 1 Dec 2022 10:10:28 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> This was motivated by discussions we had in https://github.com/openjdk/jdk/pull/11017.
>> 
>> To aid in analyzing secondary errors during error reporting, it would be useful to see their callstacks for secondary errors. But printing callstacks during error reporting is unsafe - if we get a second crash or assert, it will cause infinite recursion and interrupt error reporting. Also, the hs-err file would be quite verbose. Therefore this feature is optional and limited to debug builds. 
>> 
>> ---
>> 
>> Patch
>> 
>> - adds optional callstack/siginfo printing via debug-only switch `-XX:+ErrorLogSecondaryErrorDetails`.
>> - fixes a bug in secondary error handling where we would use the global scratch buffer recursively (via stringStream); that could lead to confusing output since it is used by the error log stream already. We can print directly to that one instead.
>> - Removed a stray newline from print_native_stack to clean output.
>> - added regression testing for this feature. I removed my name and the bug id from the test since we don't do this anymore (?).
>> - added clarifying comments to the test and code
>> - added SAP copyright to the regression test (we introduced it years ago for JDK-8065895)
>> 
>> Output looks like this:
>> 
>> 
>> $ java ... -XX:+ErrorLogSecondaryErrorDetails
>> 
>> 
>> will produce, for secondary errors, siginfo and call stack.
>> 
>> 
>> [error occurred during error reporting (test secondary crash 1), id 0xb, SIGSEGV (0xb) at pc=0x00007fddfe8a0a61]
>> [siginfo: si_signo: 11 (SIGSEGV), si_code: 128 (SI_KERNEL), si_addr: 0x0000000000000000]
>> [stack: Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0x1ceea61]  VMError::controlled_crash(int)+0x241  (vmError.cpp:1946)
>> V  [libjvm.so+0x1cf413f]  VMError::report(outputStream*, bool)+0x46bf  (vmError.cpp:564)
>> V  [libjvm.so+0x1cf516b]  VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x19b  (vmError.cpp:1709)
>> V  [libjvm.so+0x1cf5e8f]  VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*, char const*, ...)+0x8f  (vmError.cpp:1467)
>> V  [libjvm.so+0x1cf5ec2]  VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*)+0x22  (vmError.cpp:1473)
>> V  [libjvm.so+0x1a549e7]  JVM_handle_linux_signal+0x1f7  (signals_posix.cpp:656)
>> C  [libc.so.6+0x43090]
>> V  [libjvm.so+0x11d6965]  JNI_CreateJavaVM+0x5b5  (jni.cpp:3662)
>> C  [libjli.so+0x4013]  JavaMain+0x93  (java.c:1457)
>> C  [libjli.so+0x800d]  ThreadJavaMain+0xd  (java_md.c:650)
>> ]
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert accidental change

Loks good to me. I woulld really advocate to make it usable in product builds.

src/hotspot/share/runtime/globals.hpp line 520:

> 518:           range(0, (uint64_t)max_jlong/1000)                                \
> 519:                                                                             \
> 520:   develop(bool, ErrorLogSecondaryErrorDetails, false,                       \

Making this a debug flag severely limits its usefulness. You would have to switch the VM to a debug VM, which might be hard for some customers. Since the change doesn't adds much code and there is no performance impact, I would make it diagnostic or product.

src/hotspot/share/utilities/vmError.cpp line 1507:

> 1505:         // Any information (signal, context, siginfo etc) printed here should use the function
> 1506:         // arguments, not the information stored in *this, since those describe the primary crash.
> 1507:         static char tmp[256]; // cannot use global scratch buffer

This is not thread safe. You could have parallel threads which trigger a secondary crash. Not sure if it will be a problem in practice, since it is rather rare. I would still use a local buffer, since 256 bytes is small.

src/hotspot/share/utilities/vmError.cpp line 1527:

> 1525:         {
> 1526:           if (ErrorLogSecondaryErrorDetails) {
> 1527:             static bool recursed = false;

Same as above. Would not work if we have parallel crashes, but I don't think it warrants making the code more complicated to catch this.

-------------

Marked as reviewed by rschmelter (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11118

From stuefe at openjdk.org  Thu Dec  1 16:21:52 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 1 Dec 2022 16:21:52 GMT
Subject: RFR: JDK-8296907: VMError: add optional callstacks,
 siginfo for secondary errors [v11]
In-Reply-To: <TIRVnzzV8rmLobs4gme6WXjspmVUQ5TnjqJJgrCr7O4=.3bc6d0fa-2ec3-4824-aafc-8f38d65b85d7@github.com>
References: <x1kul17oEaJ-UX6ZGPv8OcsxN8QfYlME_d39aSATk-Q=.f0e0169c-15f5-4b4b-8235-68f8e68ec43c@github.com>
 <bmVxR4kMTfct8Sl2BiNvFqd4MYENT5fFPlBHV3EnTlA=.dbba14ae-40d2-4ebe-b9d6-3b49ca1fc3c1@github.com>
 <TIRVnzzV8rmLobs4gme6WXjspmVUQ5TnjqJJgrCr7O4=.3bc6d0fa-2ec3-4824-aafc-8f38d65b85d7@github.com>
Message-ID: <gYmDTQsaK1Jp7BJ61-gnNB5NA1Xr4rhHgZl5TOciUUI=.2dd7f9a7-3de1-44b1-a1ab-58fc93792cd1@github.com>

On Thu, 1 Dec 2022 15:51:28 GMT, Ralf Schmelter <rschmelter at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert accidental change
>
> src/hotspot/share/runtime/globals.hpp line 520:
> 
>> 518:           range(0, (uint64_t)max_jlong/1000)                                \
>> 519:                                                                             \
>> 520:   develop(bool, ErrorLogSecondaryErrorDetails, false,                       \
> 
> Making this a debug flag severely limits its usefulness. You would have to switch the VM to a debug VM, which might be hard for some customers. Since the change doesn't adds much code and there is no performance impact, I would make it diagnostic or product.

You convinced me. I will make it a diagnostic product flag, by default off.

-------------

PR: https://git.openjdk.org/jdk/pull/11118

From stuefe at openjdk.org  Thu Dec  1 16:26:12 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 1 Dec 2022 16:26:12 GMT
Subject: RFR: JDK-8296907: VMError: add optional callstacks,
 siginfo for secondary errors [v11]
In-Reply-To: <TIRVnzzV8rmLobs4gme6WXjspmVUQ5TnjqJJgrCr7O4=.3bc6d0fa-2ec3-4824-aafc-8f38d65b85d7@github.com>
References: <x1kul17oEaJ-UX6ZGPv8OcsxN8QfYlME_d39aSATk-Q=.f0e0169c-15f5-4b4b-8235-68f8e68ec43c@github.com>
 <bmVxR4kMTfct8Sl2BiNvFqd4MYENT5fFPlBHV3EnTlA=.dbba14ae-40d2-4ebe-b9d6-3b49ca1fc3c1@github.com>
 <TIRVnzzV8rmLobs4gme6WXjspmVUQ5TnjqJJgrCr7O4=.3bc6d0fa-2ec3-4824-aafc-8f38d65b85d7@github.com>
Message-ID: <GYpDe9ul_1JwMpjwtipRdMgWPGnPQ2noiAbb-K6gkwk=.6ff16376-0df7-4000-a479-2276f42e8af8@github.com>

On Thu, 1 Dec 2022 15:59:48 GMT, Ralf Schmelter <rschmelter at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert accidental change
>
> src/hotspot/share/utilities/vmError.cpp line 1507:
> 
>> 1505:         // Any information (signal, context, siginfo etc) printed here should use the function
>> 1506:         // arguments, not the information stored in *this, since those describe the primary crash.
>> 1507:         static char tmp[256]; // cannot use global scratch buffer
> 
> This is not thread safe. You could have parallel threads which trigger a secondary crash. Not sure if it will be a problem in practice, since it is rather rare. I would still use a local buffer, since 256 bytes is small.

I'm not sure how this would happen: we only end up here if we are the original thread that triggered the first fault (_first_error_tid == me). Otherwise, we would end up in `os::infinite_sleep()` at lines 1455ff. If a different thread crashes inside signal handling, between signal handler start and infinite_sleep, it will just keep crashing endlessly and run out of stack.

> src/hotspot/share/utilities/vmError.cpp line 1527:
> 
>> 1525:         {
>> 1526:           if (ErrorLogSecondaryErrorDetails) {
>> 1527:             static bool recursed = false;
> 
> Same as above. Would not work if we have parallel crashes, but I don't think it warrants making the code more complicated to catch this.

See my answer above. My assumption here is we are singlethreaded, because all but the first thread end up sleeping.

-------------

PR: https://git.openjdk.org/jdk/pull/11118

From stuefe at openjdk.org  Thu Dec  1 16:36:25 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 1 Dec 2022 16:36:25 GMT
Subject: RFR: JDK-8296907: VMError: add optional callstacks,
 siginfo for secondary errors [v12]
In-Reply-To: <x1kul17oEaJ-UX6ZGPv8OcsxN8QfYlME_d39aSATk-Q=.f0e0169c-15f5-4b4b-8235-68f8e68ec43c@github.com>
References: <x1kul17oEaJ-UX6ZGPv8OcsxN8QfYlME_d39aSATk-Q=.f0e0169c-15f5-4b4b-8235-68f8e68ec43c@github.com>
Message-ID: <oxflPz5qkquAtnkHzN1SvOCysUV7ug1IUebbVK4n8ro=.e9904f64-1e92-41ec-8d8b-953b2d3344ce@github.com>

> This was motivated by discussions we had in https://github.com/openjdk/jdk/pull/11017.
> 
> To aid in analyzing secondary errors during error reporting, it would be useful to see their callstacks for secondary errors. But printing callstacks during error reporting is unsafe - if we get a second crash or assert, it will cause infinite recursion and interrupt error reporting. Also, the hs-err file would be quite verbose. Therefore this feature is optional and limited to debug builds. 
> 
> ---
> 
> Patch
> 
> - adds optional callstack/siginfo printing via debug-only switch `-XX:+ErrorLogSecondaryErrorDetails`.
> - fixes a bug in secondary error handling where we would use the global scratch buffer recursively (via stringStream); that could lead to confusing output since it is used by the error log stream already. We can print directly to that one instead.
> - Removed a stray newline from print_native_stack to clean output.
> - added regression testing for this feature. I removed my name and the bug id from the test since we don't do this anymore (?).
> - added clarifying comments to the test and code
> - added SAP copyright to the regression test (we introduced it years ago for JDK-8065895)
> 
> Output looks like this:
> 
> 
> $ java ... -XX:+ErrorLogSecondaryErrorDetails
> 
> 
> will produce, for secondary errors, siginfo and call stack.
> 
> 
> [error occurred during error reporting (test secondary crash 1), id 0xb, SIGSEGV (0xb) at pc=0x00007fddfe8a0a61]
> [siginfo: si_signo: 11 (SIGSEGV), si_code: 128 (SI_KERNEL), si_addr: 0x0000000000000000]
> [stack: Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x1ceea61]  VMError::controlled_crash(int)+0x241  (vmError.cpp:1946)
> V  [libjvm.so+0x1cf413f]  VMError::report(outputStream*, bool)+0x46bf  (vmError.cpp:564)
> V  [libjvm.so+0x1cf516b]  VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x19b  (vmError.cpp:1709)
> V  [libjvm.so+0x1cf5e8f]  VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*, char const*, ...)+0x8f  (vmError.cpp:1467)
> V  [libjvm.so+0x1cf5ec2]  VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*)+0x22  (vmError.cpp:1473)
> V  [libjvm.so+0x1a549e7]  JVM_handle_linux_signal+0x1f7  (signals_posix.cpp:656)
> C  [libc.so.6+0x43090]
> V  [libjvm.so+0x11d6965]  JNI_CreateJavaVM+0x5b5  (jni.cpp:3662)
> C  [libjli.so+0x4013]  JavaMain+0x93  (java.c:1457)
> C  [libjli.so+0x800d]  ThreadJavaMain+0xd  (java_md.c:650)
> ]

Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision:

 - Remove unused imports from test
 - Make ErrorLogSecondaryErrorDetails a diagnostic product flag

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11118/files
  - new: https://git.openjdk.org/jdk/pull/11118/files/ae92af84..b2457403

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11118&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11118&range=10-11

  Stats: 37 lines in 3 files changed: 8 ins; 16 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/11118.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11118/head:pull/11118

PR: https://git.openjdk.org/jdk/pull/11118

From stuefe at openjdk.org  Thu Dec  1 16:38:18 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 1 Dec 2022 16:38:18 GMT
Subject: RFR: JDK-8296907: VMError: add optional callstacks,
 siginfo for secondary errors [v11]
In-Reply-To: <TIRVnzzV8rmLobs4gme6WXjspmVUQ5TnjqJJgrCr7O4=.3bc6d0fa-2ec3-4824-aafc-8f38d65b85d7@github.com>
References: <x1kul17oEaJ-UX6ZGPv8OcsxN8QfYlME_d39aSATk-Q=.f0e0169c-15f5-4b4b-8235-68f8e68ec43c@github.com>
 <bmVxR4kMTfct8Sl2BiNvFqd4MYENT5fFPlBHV3EnTlA=.dbba14ae-40d2-4ebe-b9d6-3b49ca1fc3c1@github.com>
 <TIRVnzzV8rmLobs4gme6WXjspmVUQ5TnjqJJgrCr7O4=.3bc6d0fa-2ec3-4824-aafc-8f38d65b85d7@github.com>
Message-ID: <6RUAwhfdvWq0rQWrlyfI2AhnH1S2ls0KJkdvpO29Y1g=.2b36f616-46b1-4e63-a0c0-2e6ab0d14fd0@github.com>

On Thu, 1 Dec 2022 16:04:21 GMT, Ralf Schmelter <rschmelter at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert accidental change
>
> Loks good to me. I woulld really advocate to make it usable in product builds.

Hi @schmelter-sap, thanks a lot for the review! I made the flag a product flag as you suggested. Is this version still okay?

@xmas92 @dholmes-ora barring any objections, I plan to push tomorrow if all tests tonight are green.

Cheers, Thomas

-------------

PR: https://git.openjdk.org/jdk/pull/11118

From kvn at openjdk.org  Thu Dec  1 16:42:15 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 1 Dec 2022 16:42:15 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v4]
In-Reply-To: <6lfTT_Djcw8AsOUW09Kh5BSqxFhveF5ASItS8O_E3C8=.25a1cf8e-73b3-40f0-a531-1cc34264807a@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
 <6lfTT_Djcw8AsOUW09Kh5BSqxFhveF5ASItS8O_E3C8=.25a1cf8e-73b3-40f0-a531-1cc34264807a@github.com>
Message-ID: <VbyfTXc-AAn97fnHY_Wnt-zfe2MKsTQG-cLef1nQK28=.880af2dc-8157-4b94-b1e0-0006c91e326a@github.com>

On Wed, 2 Nov 2022 00:02:03 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
>> 
>>  - Migrate postaloc.cpp migrated away from references to pointers when it comes to Node_List.
>>    
>>    Co-authored-by: Vladimir Ivanov <vaivanov at openjdk.org>
>>  - Merge from JDK head
>>  - Revert "Push ScopedValue tests"
>>    
>>    This reverts commit d298edfa9eda48ace9a27f83d38320fe6ba79e67.
>>  - Push ScopedValue tests
>>  - More
>>  - Next
>>  - Next
>>  - Next
>>  - Next
>
> Minor comments/suggestions. Otherwise, looks good.

My initial testing passed. I will wait update which address latest @iwanowww comments before doing more testing.

-------------

PR: https://git.openjdk.org/jdk/pull/10920

From cstein at openjdk.org  Thu Dec  1 16:52:36 2022
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 1 Dec 2022 16:52:36 GMT
Subject: Integrated: 8296710: Update to use jtreg 7.1
In-Reply-To: <4t-uTHoUVlflpzDnfuHO7TAnix7nNO1MGF28CJBjZBo=.deb056ac-6571-4c79-a272-680b923d58c5@github.com>
References: <4t-uTHoUVlflpzDnfuHO7TAnix7nNO1MGF28CJBjZBo=.deb056ac-6571-4c79-a272-680b923d58c5@github.com>
Message-ID: <lZAtUZEOklC8hkoGANSV8U9RQosigGI36_pJft8Cpgk=.b18b40d7-32a1-4a25-95cf-159f554b4698@github.com>

On Tue, 29 Nov 2022 14:44:12 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg `7.1`.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.
> 
> This pull request was created by copying the following and using `7.1` at appropriate places:
> - https://github.com/openjdk/jdk/pull/9393

This pull request has now been integrated.

Changeset: c70d1e1b
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c70d1e1bd32c71e0d2df635bc565201a09084a83
Stats:     9 lines in 8 files changed: 0 ins; 0 del; 9 mod

8296710: Update to use jtreg 7.1

Reviewed-by: erikj, alanb, jjg

-------------

PR: https://git.openjdk.org/jdk/pull/11416

From duke at openjdk.org  Thu Dec  1 16:57:57 2022
From: duke at openjdk.org (Johannes Bechberger)
Date: Thu, 1 Dec 2022 16:57:57 GMT
Subject: RFR: 8297967: Make frame::safe_for_sender safer
Message-ID: <Cctc-M2HyUqIjpcRyTjmF46wKDqvBtnnYe5Mn45sdO8=.03bdf65f-bf98-48dc-b957-0c838003d46f@github.com>

Makes frame::safe_for_sender safer by using os::is_readable_pointer to check the location of the return address.

-------------

Commit messages:
 - 8297967: Make frame::safe_for_sender safer

Changes: https://git.openjdk.org/jdk/pull/11461/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11461&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297967
  Stats: 14 lines in 3 files changed: 10 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/11461.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11461/head:pull/11461

PR: https://git.openjdk.org/jdk/pull/11461

From egahlin at openjdk.org  Thu Dec  1 17:04:53 2022
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 1 Dec 2022 17:04:53 GMT
Subject: RFR: 8157023: Integrate NMT with JFR
In-Reply-To: <eYMaJWbLShtnb2j08gOfnhHXsDg9OswIxQI8rvBqkSQ=.84d846f6-09f4-4f95-a632-08b1c975323d@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <uvfe5r95h067-c6M1apWu0ySUjvRBOnzaG-Tv1sp6ao=.9c7f0dae-0e85-4029-a4cd-7452a4d5c302@github.com>
 <xgmkKNIgrAiBWoieuv2rjwhZKs3gHVsW-WdDGypK-5o=.bbdaa17a-65df-4b9f-a14c-cc320d18cfaa@github.com>
 <eYMaJWbLShtnb2j08gOfnhHXsDg9OswIxQI8rvBqkSQ=.84d846f6-09f4-4f95-a632-08b1c975323d@github.com>
Message-ID: <_wo1SsKdFblP2OVLjTxDigQQ5rHsoNAFNTPqA0fNzBo=.67d68e5d-1720-4c0f-9f51-49ddf8fb4ebd@github.com>

On Thu, 1 Dec 2022 13:22:42 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> I agree, it would have been best if just one snapshot could have been used, but as you say the current infrastructure doesn't really support that. What we could do is to use the same event-type for total as for the parts and just let it have the "Memory Type" "Total", but that also feels kind of like a hack. I also agree that the difference should be small, but it might make sense to add a release note or something stating this information. 
>> 
>> I would really like the events to be fine grained and I think that would make us more forward compatible and it would support more use cases. When it comes to out of the box visualization I don't think there will be any, it will be up to however consumes the JFR/NMT data.
>
> I think we should design the events as if we could take everything in one snapshot. That way, we can improve the implementation later. It would be good to write in the event description of NativeMemoryUsage event that it may not add exactly up to the sum of NativeMemoryUsagePart events due to timing issues.
> 
> I will look into adding support for snapshots, but it will have to be a later release.

Today, the call into JVM has the signature JVM::emitEvent(long eventTypeId, long timestamp, long when). If the timestamp is stored in jfr_periodic_timestamp when the call gets into native and the part event is emitted first, then it could look something like this:


static u8 jfr_periodic_timestamp;

struct JfrNmtTotal {
  u8 timestamp;
  u8 reserved;
  u8 committed;
};

static JfrNmtTotal last_nmt;

TRACE_REQUEST_FUNC(NativeMemoryUsagePart) {
   ...
   last_nmt.timestamp = jfr_periodic_timestamp;
   last_nmt.reserved = sum of reserved;
   last_nmt.committed = sum of committed;
}

TRACE_REQUEST_FUNC(NativeMemoryUsage) {
   if (jfr_periodic_timestamp == last_nmt.timestamp) {
       // use last_nmt
   } else {
      // calculate reserved and committed independently
  }
}


Periodic events are run in the same thread.

I don't know if the order of periodic event is the same as in metadata.xml but it could be fixed. This will handle the case where the events have different periods.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From aph at openjdk.org  Thu Dec  1 17:25:32 2022
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 1 Dec 2022 17:25:32 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v5]
In-Reply-To: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
Message-ID: <tPgDjBRu6q1Uv_Rh9ySe-W8MpJFpSr-swzlA-aihJeY=.d7a47512-313a-4626-97a4-ef4241efd671@github.com>

> This patch fixes the remaining null pointer dereference bugs that I know of.
> 
> For the main bug, C2 was using a null reference to indicate an uninitialized `Node_List`. I replaced the null reference with a static sentinel.
> 
> I also turned on `-fsanitize=null` and found and fixed a bunch of other null pointer dereferences. With this,I have run a full bootstrap and tier1 tests with `-fsanitize=null` enabled.
> 
> I have checked that the code generated by GCC is not worse in any significant way, so I don't expect to see any performance regressions.
> 
> I'd like to enable `-fsanitize=null` in debug builds to prevent regressions in this area. What do you think?

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Feedback from reviewers

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10920/files
  - new: https://git.openjdk.org/jdk/pull/10920/files/45e9e20f..26347b70

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10920&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10920&range=03-04

  Stats: 6 lines in 2 files changed: 0 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/10920.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10920/head:pull/10920

PR: https://git.openjdk.org/jdk/pull/10920

From aph at openjdk.org  Thu Dec  1 17:25:34 2022
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 1 Dec 2022 17:25:34 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v5]
In-Reply-To: <8p5DnhjjOlFQ6Tu_DEfJsvW7ac-MgQ8vP3_LSvocgGg=.16e04fa6-d7cc-4cc9-ade6-0fd8f83b4df4@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
 <6lfTT_Djcw8AsOUW09Kh5BSqxFhveF5ASItS8O_E3C8=.25a1cf8e-73b3-40f0-a531-1cc34264807a@github.com>
 <8p5DnhjjOlFQ6Tu_DEfJsvW7ac-MgQ8vP3_LSvocgGg=.16e04fa6-d7cc-4cc9-ade6-0fd8f83b4df4@github.com>
Message-ID: <xLM1FBSq5Msh4g_5VDjX8UcAH1jreAOrsMedC1pZO-U=.33e7b791-4ea4-4794-9f90-496c2854c2d3@github.com>

On Wed, 30 Nov 2022 20:00:04 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> src/hotspot/share/opto/bytecodeInfo.cpp line 66:
>> 
>>> 64:     assert(!caller_jvms->should_reexecute(), "there should be no reexecute bytecode with inlining");
>>> 65:   }
>>> 66:   assert(_caller_jvms == NULL
>> 
>> I'd reshape the code and either get rid of `_caller_jvms` initialization on line 47 or replace it with `_caller_jvms(NULL),`. 
>> 
>> Then, I'd guard `_caller_jvms` initialization by `caller_jvms != NULL` and move the assert under the guard:
>> 
>>   if (caller_jvms != NULL) {
>>     // Keep a private copy of the caller_jvms:
>>     _caller_jvms = new (C) JVMState(caller_jvms->method(), caller_tree->caller_jvms());
>>     _caller_jvms->set_bci(caller_jvms->bci());
>>     assert(!caller_jvms->should_reexecute(), "there should be no reexecute bytecode with inlining");
>>     assert(caller_jvms->same_calls_as(_caller_jvms), "consistent JVMS");
>>   }
>> 
>> 
>> Or introduce a helper method which does a shallow copy of `caller_jvms` as part of initializing store on line 47.
>
> Please, initialize `_caller_jvms` to `NULL` (on line 47), switch the null check to `caller_jvms` (on line 60), and  move the assert under the null check.

I'm sorry, I've been looking at this for a while, and I can't figure out what "move the assert under the null check" means. There are three asserts here, and two of them are under the `if (caller_jvms != NULL)` check.

-------------

PR: https://git.openjdk.org/jdk/pull/10920

From aph at openjdk.org  Thu Dec  1 17:25:35 2022
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 1 Dec 2022 17:25:35 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v5]
In-Reply-To: <xLM1FBSq5Msh4g_5VDjX8UcAH1jreAOrsMedC1pZO-U=.33e7b791-4ea4-4794-9f90-496c2854c2d3@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
 <6lfTT_Djcw8AsOUW09Kh5BSqxFhveF5ASItS8O_E3C8=.25a1cf8e-73b3-40f0-a531-1cc34264807a@github.com>
 <8p5DnhjjOlFQ6Tu_DEfJsvW7ac-MgQ8vP3_LSvocgGg=.16e04fa6-d7cc-4cc9-ade6-0fd8f83b4df4@github.com>
 <xLM1FBSq5Msh4g_5VDjX8UcAH1jreAOrsMedC1pZO-U=.33e7b791-4ea4-4794-9f90-496c2854c2d3@github.com>
Message-ID: <0saIh82rf2159AEVVl3pepMP9vGrPgQrIZDoyiKIz8A=.f909ddac-7fc3-451c-9a9d-0f4a38fdc2f2@github.com>

On Thu, 1 Dec 2022 17:21:45 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Please, initialize `_caller_jvms` to `NULL` (on line 47), switch the null check to `caller_jvms` (on line 60), and  move the assert under the null check.
>
> I'm sorry, I've been looking at this for a while, and I can't figure out what "move the assert under the null check" means. There are three asserts here, and two of them are under the `if (caller_jvms != NULL)` check.

> Please, initialize `_caller_jvms` to `NULL` (on line 47), switch the null check to `caller_jvms` (on line 60), a

Done.

-------------

PR: https://git.openjdk.org/jdk/pull/10920

From aph at openjdk.org  Thu Dec  1 17:25:36 2022
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 1 Dec 2022 17:25:36 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v5]
In-Reply-To: <pDjCV3HUo8yf-xjKiGKQNFiPT27vB9a2qrNnxMsnTNY=.ab22ee9a-2486-4705-964b-196d577c0cac@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
 <6lfTT_Djcw8AsOUW09Kh5BSqxFhveF5ASItS8O_E3C8=.25a1cf8e-73b3-40f0-a531-1cc34264807a@github.com>
 <rNi-kFIlucDsCkWt1AGcDDz7wCDR-9USkGquiNM9_2I=.ed6b5beb-bd3c-478b-b2d4-622d476e8251@github.com>
 <GXcLOnn_At_5Cej39psYTY58lWVL8HeQHhr8hUN7a5E=.0125c2af-6ea8-4b4b-bf04-ae5981b81c02@github.com>
 <WBzNXPj7q8bjEEbF7X8GnyMKZ0h6SV1mEnnoj9il3EA=.8183b8cb-c2d9-4e57-b5bc-64fb1d959d14@github.com>
 <zMVTB_IIo8yTZYZ7ymF9HdHB2DC2c2h0RvqdjPdvCrI=.104cfdf1-4cb1-47f7-8c18-aeb141dcbcdc@github.com>
 <pDjCV3HUo8yf-xjKiGKQNFiPT27vB9a2qrNnxMsnTNY=.ab22ee9a-2486-4705-964b-196d577c0cac@github.com>
Message-ID: <zRElQhbQGhVVRaimJeeMrSb8wJDbb5EfIy-SfvzGb0s=.dbb6bd88-3b66-41eb-9e91-72a981e68931@github.com>

On Wed, 30 Nov 2022 20:00:20 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Done. If you're happy with this I'll push after tests. Thanks!
>
> Thanks. Is the null check in `Node_Array` constructor still needed?

No.

-------------

PR: https://git.openjdk.org/jdk/pull/10920

From aph at openjdk.org  Thu Dec  1 17:30:34 2022
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 1 Dec 2022 17:30:34 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v33]
In-Reply-To: <_Gn9ItyEwKzyhunfxC5b6wz7BZzPg2qD_e-wvhEqR-Q=.5be37213-7be9-40c7-8503-392bacc1cfa9@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
 <lrGP8yOwAQ9WoHM5MesCdosl1FVpO6J_kLNVBY7W--M=.a1398409-df9e-4ff8-a061-f85bb6c6cbcc@github.com>
 <_Gn9ItyEwKzyhunfxC5b6wz7BZzPg2qD_e-wvhEqR-Q=.5be37213-7be9-40c7-8503-392bacc1cfa9@github.com>
Message-ID: <jTT0F31Yt1OlIx9I2TGd4sLo84_oZsfLrOo7Pb4_ajE=.fcf744fd-ede3-4c2d-927f-7456568ea8aa@github.com>

On Wed, 30 Nov 2022 21:34:59 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Unused variable
>
> src/hotspot/cpu/aarch64/aarch64.ad line 3635:
> 
>> 3633:       }
>> 3634:     } else if (_method->intrinsic_id() == vmIntrinsicID::_ensureMaterializedForStackWalk) {
>> 3635:       __ nop();
> 
> Please add a comment explaining why the nop is needed or desirable here.

It's there because C2 in this area is littered with bits of code that use magic offsets, and I don't know how to find them all. It seemed safest to keep everything the same size. Hence, a 4-byte NOP in AArch64 and a 5-byte NOP in x86.

> src/hotspot/cpu/x86/x86_64.ad line 2174:
> 
>> 2172:                      RELOC_DISP32);
>> 2173:     } else if (_method->intrinsic_id() == vmIntrinsicID::_ensureMaterializedForStackWalk) {
>> 2174:       __ addr_nop_5();
> 
> Needs a comment.  I guess this is because of how call sizes are computed.

Yes, that's my guess. I didn't want to change any offsets.

-------------

PR: https://git.openjdk.org/jdk/pull/10952

From aph at openjdk.org  Thu Dec  1 18:01:12 2022
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 1 Dec 2022 18:01:12 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v34]
In-Reply-To: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
Message-ID: <JBQqMQkdcd25MR8uGUrLKNRLlIRxCGKY357p2dTeFnM=.687e0ad9-bf64-4651-a6c6-ce06dbcca815@github.com>

> JEP 429 implementation.

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Feedback from reviewers

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10952/files
  - new: https://git.openjdk.org/jdk/pull/10952/files/37441eeb..4f2716a3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=33
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=32-33

  Stats: 9 lines in 2 files changed: 5 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10952.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10952/head:pull/10952

PR: https://git.openjdk.org/jdk/pull/10952

From vlivanov at openjdk.org  Thu Dec  1 18:02:24 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 1 Dec 2022 18:02:24 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v5]
In-Reply-To: <0saIh82rf2159AEVVl3pepMP9vGrPgQrIZDoyiKIz8A=.f909ddac-7fc3-451c-9a9d-0f4a38fdc2f2@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
 <6lfTT_Djcw8AsOUW09Kh5BSqxFhveF5ASItS8O_E3C8=.25a1cf8e-73b3-40f0-a531-1cc34264807a@github.com>
 <8p5DnhjjOlFQ6Tu_DEfJsvW7ac-MgQ8vP3_LSvocgGg=.16e04fa6-d7cc-4cc9-ade6-0fd8f83b4df4@github.com>
 <xLM1FBSq5Msh4g_5VDjX8UcAH1jreAOrsMedC1pZO-U=.33e7b791-4ea4-4794-9f90-496c2854c2d3@github.com>
 <0saIh82rf2159AEVVl3pepMP9vGrPgQrIZDoyiKIz8A=.f909ddac-7fc3-451c-9a9d-0f4a38fdc2f2@github.com>
Message-ID: <fI8eRD9gFvdHD63yNqJKA13ekCxfgRD-vvOICsoSzHU=.fffe4565-dd3a-4727-86dc-52468c239b89@github.com>

On Thu, 1 Dec 2022 17:22:12 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> I'm sorry, I've been looking at this for a while, and I can't figure out what "move the assert under the null check" means. There are three asserts here, and two of them are under the `if (caller_jvms != NULL)` check.
>
>> Please, initialize `_caller_jvms` to `NULL` (on line 47), switch the null check to `caller_jvms` (on line 60), a
> 
> Done.

I'm talking specifically about the assert you are adjusting:

assert(_caller_jvms->same_calls_as(caller_jvms), "consistent JVMS");

It can be left as is once it is under `caller_jvms != NULL`, since there's no need in `_caller_jvms == NULL` anymore.

-------------

PR: https://git.openjdk.org/jdk/pull/10920

From aph at openjdk.org  Thu Dec  1 18:01:15 2022
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 1 Dec 2022 18:01:15 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v33]
In-Reply-To: <00vRbThlo7WIZeqbqMNYNYQKiBH2aFP0O5d-swCOvtY=.f02f4b5a-fb86-4861-affd-000438b83b47@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
 <lrGP8yOwAQ9WoHM5MesCdosl1FVpO6J_kLNVBY7W--M=.a1398409-df9e-4ff8-a061-f85bb6c6cbcc@github.com>
 <00vRbThlo7WIZeqbqMNYNYQKiBH2aFP0O5d-swCOvtY=.f02f4b5a-fb86-4861-affd-000438b83b47@github.com>
Message-ID: <sEGbGnkCoDnklEgEleaM7GGtmE2YlZqZTuVKgA36GBs=.234fa9e9-165b-4a61-a4ba-451cc35789b6@github.com>

On Wed, 30 Nov 2022 21:39:40 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Unused variable
>
> src/hotspot/share/classfile/javaClasses.cpp line 1731:
> 
>> 1729: }
>> 1730: 
>> 1731: void java_lang_Thread::clear_scopedValueBindings(oop java_thread) {
> 
> It looks like there is only one caller of this method that takes an oop.  Would it make sense to have the caller check for the null oop, and assert that the oop is not null here?

Done.

-------------

PR: https://git.openjdk.org/jdk/pull/10952

From thomas.stuefe at gmail.com  Thu Dec  1 18:14:52 2022
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 1 Dec 2022 19:14:52 +0100
Subject: Extend Native Memory Tracking over the JDK ? (was: Proposal:
 track zlib native memory usage with NMT)
In-Reply-To: <CAA-vtUxrP49w523EQ3yKFh4Zo5W+HMtqpGcsUxOEMkwZUOQ0zQ@mail.gmail.com>
References: <CAA-vtUzvyqb_LZ9d1Z80oSvzyqpi89053O3B+oDZF4oZ85CuZg@mail.gmail.com>
 <c5db2105-3b78-0b77-779f-011c8649f476@oracle.com>
 <CAA-vtUxrP49w523EQ3yKFh4Zo5W+HMtqpGcsUxOEMkwZUOQ0zQ@mail.gmail.com>
Message-ID: <CAA-vtUxB8Z1CD9EYMaMT8OJjw6unwCYd7ONBvQRCVQqO4VTUZQ@mail.gmail.com>

Are there any opinions about whether or not to extend NMT across the JDK?

This blocks https://bugs.openjdk.org/browse/JDK-8296360, and I had a PR
prepared as https://github.com/openjdk/jdk/pull/10988. Originally I was
hoping to get this into JDK 20, but I don't think that is realistic
anymore. I am fine with postponing my work in favor of a baseline
discussion, but so far there is very little discussion about this topic.

How should I proceed?

Thanks, Thomas



On Wed, Nov 9, 2022 at 8:12 AM Thomas St?fe <thomas.stuefe at gmail.com> wrote:

> Hi Alan,
>
> (replaced hotspot-runtime-dev with hotspot-dev, since its more of a
> general topic)
>
> thank you for your time!
>
> I am very happy to talk this through. I think native memory observability
> in the JDK (and customer code!) is sorely lacking. Witness the countless
> "where did my native memory go" blog articles. At SAP we have been
> struggling with this topic for a long time and have come up with a mixture
> of solutions. The aforementioned tracker was one, which extended our
> version of NMT across the JDK. Our SapMachine MallocTracer, which allows us
> to trace uninstrumented customer code, another. We even experimented with
> exchanging the allocator (using jemalloc) to gain insights. But that is a
> whole different topic with deep logistical implications, I don't want to
> touch it here. Exchanging the allocator does not help to observe virtual
> memory or the brk segment, of course.
>
> And to make the picture complete, another insight we currently lack is the
> implicit allocator overhead, which can be very significant and is hidden by
> the libc. We also have observability for that in the SapMachine, and I miss
> it in OpenJDK.
>
> As you noticed, my original intent was just to instrument Zlib and
> possibly improve tracking for DBBs. Although, thinking beyond that, another
> attractive instrumentation target would be mapped NIO buffers at least.
>
> So I think native memory observability is important. Arguably we could
> even extend observability to cover other OS resources, e.g. file handles.
> If we shift code around, to java/Panama: data that move the java heap does
> not need to be tracked, but other memory will always come from one of the
> basic system APIs, regardless of who allocates it and where in the stack
> allocation happens. Be it native JDK code, Panama, or even customer JNI
> code.
>
> If we agree on the importance of native memory observability, then I
> believe NMT is the right tool for it. It is a good tool. The machinery is
> already there. It covers both C-heap and virtual memory APIs, as well as
> thread stacks, and could easily be extended to cover sbrk if needed. And I
> assume that whatever shape OpenJDK takes on in the future, there always
> will be a libjvm.so at its core, so we will always have it. But even if
> not, NMT could be separated from libjvm.so quite easily, since it has no
> deep ties with the JVM.
>
> About coupling JVM with outside code: We don't have to directly link
> against libjvm.so. We can keep things loose if the intent is to be runnable
> without a JVM, or be JVM-version-agnostic. That could take the form of a
> function-pointer interface like JVMTI. Or outside code could dynamically
> dlsym the JVM allocation hooks. In any case gracefully falling back to
> system allocation routines when necessary.
>
> And I agree, polluting the NMT tag space with outside meaning is ugly. I
> only did it because I planned to go no further than instrumenting Zlib and
> possibly DBBs. But if we take this further, my preferred solution would be
> a reserved tag range or -ranges for outside use, whose inner meaning would
> be opaque to the JVM. Kind of like SIGRTMIN+SIGRTMAX. Then, outside code
> could register tags and their meta information with the JVM, or we find a
> different way to convey the tag meaning to NMT (config files, or
> callbacks). That could even be opened up for customer use.
>
> This also touches on another question, that of NMT tag space. NMT tags are
> very useful since they allow cheap tracking without capturing call stacks.
> However, tags are underused and show growing pains since they are too
> one-dimensional and restrictive. We had competing interests in the past
> about tag granularity. It is all over the place. We have coarse-grained
> tags like "mtThread", and very fine-grained ones like "mtObjectMonitor".
> There are several ways we could improve, e.g., by making them combinable
> like UL does, or allowing for a hierarchy of them - either a hard-wired
> limited one like "domain"+"tag", or an unlimited tree-like one. Technically
> interesting since whatever the new encoding is, they still must fit into a
> malloc header. I opened https://bugs.openjdk.org/browse/JDK-8281819 to
> track ideas like these.
>
> Instrumenting Panama allocations, including the ability to tag
> allocations, would be a very good idea. For instance, if we ever remove the
> native Zlib layer and convert it to java using Panama, we can do the same
> with Panama I do now natively - use the Zlib zalloc interface to hook in
> JVM memory allocation functions. The result could be completely identical,
> and the end user looking at the NMT output need never know that anything
> changed.
>
> And that goes for all instrumentation - if today we add it to JNI code,
> and that code gets removed tomorrow, we can add it to Panama code too.
> Unless data structures move to the heap, in which case there is no need to
> track them.
>
> You mentioned that NMT was more of an in-house support tool. Our
> experience is different. Even though it was positioned as a tool for JVM
> developers, and we never cared for the backward compatibility or
> consistency, it gets used a *lot* by our customers. We have to explain its
> output frequently. Also, many blog articles exist documenting its use. So,
> maybe it would be okay to elevate it to a user-facing tool since it seems
> to occupy that role anyway. We may also open up consumption of NMT results
> via java APIs, or expose its results via MXBeans.
>
> If this is to be a JEP, okay, but I'm afraid it would stall things a bit.
> I am interested in getting a simpler and quicker solution for older support
> releases at least, possibly based on my PR. I know that would be
> unconventional though.
>
> Thank you,
>
> Thomas
>
>
> On Sun, Nov 6, 2022 at 9:31 AM Alan Bateman <Alan.Bateman at oracle.com>
> wrote:
>
>> On 04/11/2022 16:54, Thomas St?fe wrote:
>> > Hi all,
>> >
>> > I am currently working on https://bugs.openjdk.org/browse/JDK-8296360;
>> > I was preparing the final PR [1], but then Alan did ask me to discuss
>> > this on core-libs first.
>> >
>> > Backstory:
>> >
>> > NMT tracks hotspot native allocations but does not cover the JDK
>> > libraries (small exception: Unsafe.AllocateMemory). However, the
>> > native memory footprint of JDK libraries can be significant. We have
>> > no in-VM tracker for these and need tools like valgrind or our
>> > SapMachine MallocTracer [2] to observe them.
>>
>> Thanks for starting a discussion on this as this is a topic that
>> requires agreement from several areas. If this is the start of something
>> bigger, where you want to have all allocation sites in the libraries
>> using NMT, then I think it needs a write-up, maybe a JEP.
>>
>> For starters, I think it needs some agreement on using NMT for memory
>> allocated outside of libjvm. You mentioned Unsafe as an exception but
>> that is implemented in the VM so you get tracking for free, albeit I
>> think all allocations are in the "mtOther" category.
>>
>> A general concern is that it creates more coupling between the VM code
>> and the libraries code. As you probably know, we've removed most of the
>> dependences on JVM_* functions from non-core areas over many years. So I
>> think that needs consideration as I assume we don't want
>> memory/allocation.hpp declaring a dozen catagories for allocations done
>> in say java.desktop module for example. Maybe your proposal will be
>> strictly limited to java.base but even then, do we really want the VM
>> even knowing about categories that are specific to zip compression or
>> decompression?
>>
>> There are probably longer term trends that should be part of the
>> discussion too. One general trend is that "run time" is becoming more
>> and more a hybrid of code in libvm and the Java libraries. Lambdas,
>> module system, virtual threads implementations are a few examples in the
>> last few release. This comes with many "Java on Java" challenges,
>> including serviceability where users of the platform will expect tools
>> to just work and won't care where the code is. NMT is probably more for
>> support teams and not something that most developers will ever use but I
>> think is part of the challenge of having serviceability solutions "just
>> work".
>>
>> In addition to having more of the Java runtime written in Java, there
>> will likely be less JNI code in the future. It's very possible that the
>> JNI code (including the JNI methods in libzip) will be replaced with
>> code that uses Panama memory and linker APIs once they are become
>> permanent. The effect of that would to have a lot of the memory
>> allocations be tracked in the mtOther category again. Maybe integration
>> with memory tracking should be looked at in conjunction with these APIs
>> and this migration. I could imagine the proposed "Arena" API
>> (MemorySession in Java 19) having some integration with NMT and it might
>> be interesting to look into that.
>>
>> So yes, this topic does need broader discussion and it might be a bit
>> premature to start with a PR for libzip without talking about the bigger
>> picture first.
>>
>> -Alan
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20221201/11472e41/attachment-0001.htm>

From mdoerr at openjdk.org  Thu Dec  1 18:16:09 2022
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 1 Dec 2022 18:16:09 GMT
Subject: RFR: 8297967: Make frame::safe_for_sender safer
In-Reply-To: <Cctc-M2HyUqIjpcRyTjmF46wKDqvBtnnYe5Mn45sdO8=.03bdf65f-bf98-48dc-b957-0c838003d46f@github.com>
References: <Cctc-M2HyUqIjpcRyTjmF46wKDqvBtnnYe5Mn45sdO8=.03bdf65f-bf98-48dc-b957-0c838003d46f@github.com>
Message-ID: <PCsSkzdOCOqmet6YHeiNsbisnBqZzorKo8OqyEUbI4U=.834dad73-3af9-4305-ba21-497c16e05282@github.com>

On Thu, 1 Dec 2022 16:47:48 GMT, Johannes Bechberger <duke at openjdk.org> wrote:

> Makes frame::safe_for_sender safer by using os::is_readable_pointer to check the location of the return address.

src/hotspot/cpu/aarch64/frame_aarch64.cpp line 268:

> 266:   // Will the pc we fetch be non-zero (which we'll find at the oldest frame) and readable
> 267: 
> 268:   if (!os::is_readable_pointer(this->fp() + return_addr_offset * sizeof(address))) {

Address computation looks wrong: `fp()` returns an `intptr_t*`, so `return_addr_offset` gets scaled automatically before the addition. Wouldn't `thread->is_in_usable_stack(fp())` be a better check?

-------------

PR: https://git.openjdk.org/jdk/pull/11461

From aph at openjdk.org  Thu Dec  1 18:24:38 2022
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 1 Dec 2022 18:24:38 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v35]
In-Reply-To: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
Message-ID: <C6tDzFY5kyeKElIvJGNXlyb8xUkM8vwSduPIUBmqIv0=.33c28904-f95f-4d7e-83d8-4cac31303500@github.com>

> JEP 429 implementation.

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Feedback from reviewers

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10952/files
  - new: https://git.openjdk.org/jdk/pull/10952/files/4f2716a3..97a82b7e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=34
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=33-34

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10952.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10952/head:pull/10952

PR: https://git.openjdk.org/jdk/pull/10952

From aph at openjdk.org  Thu Dec  1 18:24:39 2022
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 1 Dec 2022 18:24:39 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v33]
In-Reply-To: <M18a3ZLOyyHRpwfez7cHkBr6ZNLUQq7VGfBm_VZhOYU=.b2fbaa34-d51a-4d69-a06f-3df096c2b65f@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
 <lrGP8yOwAQ9WoHM5MesCdosl1FVpO6J_kLNVBY7W--M=.a1398409-df9e-4ff8-a061-f85bb6c6cbcc@github.com>
 <M18a3ZLOyyHRpwfez7cHkBr6ZNLUQq7VGfBm_VZhOYU=.b2fbaa34-d51a-4d69-a06f-3df096c2b65f@github.com>
Message-ID: <kd8HANQad1t9iix1FYpGGxTxjj3r7B_H4LoY4xf9oXM=.df135f86-2690-491f-a62a-faa56eccdc33@github.com>

On Wed, 30 Nov 2022 21:47:47 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Unused variable
>
> src/hotspot/share/prims/jvm.cpp line 1385:
> 
>> 1383:   vframeStream vfst(thread);
>> 1384:   for(; !vfst.at_end(); vfst.next()) {
>> 1385:     int loc = 0;
> 
> Use -1 instead (see below)?

Good idea, thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/10952

From coleenp at openjdk.org  Thu Dec  1 18:32:35 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 1 Dec 2022 18:32:35 GMT
Subject: RFR: 8297766: Remove UseMallocOnly development option
In-Reply-To: <34gopg6h0xMvkDTyTltghkTZPl4IZdODxcCJMKN-Ki8=.8117d9d7-9325-482d-b232-49ca862413b2@github.com>
References: <34gopg6h0xMvkDTyTltghkTZPl4IZdODxcCJMKN-Ki8=.8117d9d7-9325-482d-b232-49ca862413b2@github.com>
Message-ID: <K0fmwm3EM_iSC9RSxlSwU9gc18XN3su4pmfTTGeuiFY=.76de2aa2-2dd1-4654-82db-17be33208139@github.com>

On Thu, 1 Dec 2022 15:37:56 GMT, Afshin Zafari <duke at openjdk.org> wrote:

> ### Description
> The UseMallocOnly development option was originally used to detect memory stomping bugs with Arena allocations when the JVM was first in development.
> 
> The option has had a few bugs and is not in general use. There are ideas to add another way of Arena canary checking.
> 
> ### Patch:
> All occurrences of UseMallocOnly are removed.
> 
> ### Tests:
> Local, gTests: resourceArea and Arena
> Mach5: tier1-5

Looks good!

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11456

From duke at openjdk.org  Thu Dec  1 18:35:36 2022
From: duke at openjdk.org (Johannes Bechberger)
Date: Thu, 1 Dec 2022 18:35:36 GMT
Subject: RFR: 8297967: Make frame::safe_for_sender safer
In-Reply-To: <PCsSkzdOCOqmet6YHeiNsbisnBqZzorKo8OqyEUbI4U=.834dad73-3af9-4305-ba21-497c16e05282@github.com>
References: <Cctc-M2HyUqIjpcRyTjmF46wKDqvBtnnYe5Mn45sdO8=.03bdf65f-bf98-48dc-b957-0c838003d46f@github.com>
 <PCsSkzdOCOqmet6YHeiNsbisnBqZzorKo8OqyEUbI4U=.834dad73-3af9-4305-ba21-497c16e05282@github.com>
Message-ID: <6I48vsfx_IkJs4HMzGUjds8r3Dg-awUlRLE6ouQpY8M=.50787fa8-14bd-4735-a3a2-4a2fb04c530f@github.com>

On Thu, 1 Dec 2022 18:14:03 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Wouldn't thread->is_in_usable_stack(fp()) be a better check?

No, this would check something different.

> Address computation looks wrong

But tests show that it seems to be correct.

-------------

PR: https://git.openjdk.org/jdk/pull/11461

From stuefe at openjdk.org  Thu Dec  1 18:44:55 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 1 Dec 2022 18:44:55 GMT
Subject: RFR: 8157023: Integrate NMT with JFR
In-Reply-To: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
Message-ID: <5etH99SkJXLDG9IeW1kNIjvCWU-Ydhbg5JBMZM34tFg=.7401c117-7dbb-4ea0-89e1-31bbe6f0d78b@github.com>

On Thu, 1 Dec 2022 10:48:51 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> Please review this enhancement to include NMT information in JFR recordings.
> 
> **Summary**
> Native Memory Tracking summary information can be obtained from a running VM using `jcmd` if started with `-XX:NativeMemoryTracking=summary/detail`. Using `jcmd` requires you to run a separate process and to parse the output to get the needed information. This change adds JFR events for NMT information to enable additional ways to consume the NMT data.
> 
> There are two new events added:
> * _NativeMemoryUsage_ - The total native memory usage.
> * _NativeMemoryUsagePart_ - The native memory usage for each component.
> 
> These events are sent periodically and by default the interval is 1s. This can of course be discussed, but that is the staring point. When NMT is not enabled on events will be sent.
> 
> **Testing**
> * Added a simple test to verify that the events are sent as expected depending on if NMT is enabled or not.
> * Mach5 sanity testing

Hi Stefan,

I think this looks interesting, and potentially very useful. But I am not yet convinced that exposing all tags is the way to go. For those who are interested, the original ML thread: https://mail.openjdk.org/pipermail/core-libs-dev/2022-December/097404.html. 

The number of values may expand considerably in the future: we may want to use tags in a far more fine-granular manner than we do now, and/or change their encoding - eg to work in a hierarchy, or groups, or in combined an UL-like fashion. So their number may expand, and their meaning change, which could render this report obsolete quickly. E.g. if we add tag hierarchies, do we then only report leaf tags? How useful would that be? If we allow tag combinations, how would we report that?

Also note that I currently work on a patch for showing NMT peak malloc values, see https://bugs.openjdk.org/browse/JDK-8297958. Peak values are very useful to have. So, do we expose them too? One more value per category. But leaving them out would render the JFR NMT report less useful.

Bottomline, I am not yet convinced that reporting all NMT categories is that useful. And it exposes implementation details that may cause breakage in the future. We could restrict them to a subset of useful ones, and only report that.

Another thought, for virtual memory mappings you report reserved and committed. But I doubt that "reserved" is really of much use. In itself, it does not cost anything, at least not on 64-bit. For a select few categories, it can signify the largest amount of committable memory (e.g. heap and code space) but those are already reported in JFR. So I think we could omit "reserved" and save a bunch of code and make the NMT JFR report less overwhelming.

Cheers, Thomas

src/hotspot/share/jfr/metadata/metadata.xml line 711:

> 709:   <Event name="NativeMemoryUsagePart" category="Java Virtual Machine, Memory" label="Component Native Memory Usage" description="Native memory usage for a component" stackTrace="false" thread="false"
> 710:     startTime="false" period="everyChunk">
> 711:     <Field type="string" name="type" label="Memory Type" description="Component allocating the native memory" />

Is there a better way than to re-transmit the category name with every event?

src/hotspot/share/jfr/metadata/metadata.xml line 712:

> 710:     startTime="false" period="everyChunk">
> 711:     <Field type="string" name="type" label="Memory Type" description="Component allocating the native memory" />
> 712:     <Field type="ulong" contentType="bytes" name="reserved" label="Reserved Memory" description="Reserved bytes by this component" />

See my comment above. I am not sure we need reserved. If not, we could cut out a lot of code.

src/hotspot/share/services/memReporter.cpp line 25:

> 23:  */
> 24: #include "precompiled.hpp"
> 25: #include "jfr/jfrEvents.hpp"

I think this is an intermixing of layers. I think it would be cleaner if if JFR accessed the current values from outside, instead of JFR knowledge leaking into NMT.

src/hotspot/share/services/memReporter.cpp line 36:

> 34: #include "utilities/globalDefinitions.hpp"
> 35: 
> 36: size_t MemReporterBase::reserved_total(const MallocMemory* malloc, const VirtualMemory* vm) {

Why the const removal?

src/hotspot/share/services/memReporter.cpp line 861:

> 859: 
> 860:   MemBaseline usage;
> 861:   usage.baseline(true);

Note that this is quite expensive. So it depends on how often we do this. How often are these samples taken?

Eg. Baseline.baseline does walk all thread stacks (so, probing all of them via mincore()). It also copies a lot of counters around. 

It is also not threadsafe. Are we at a safepoint here? Normally NMT reports are only done at safepoints.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From stuefe at openjdk.org  Thu Dec  1 18:55:02 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 1 Dec 2022 18:55:02 GMT
Subject: RFR: 8297766: Remove UseMallocOnly development option
In-Reply-To: <34gopg6h0xMvkDTyTltghkTZPl4IZdODxcCJMKN-Ki8=.8117d9d7-9325-482d-b232-49ca862413b2@github.com>
References: <34gopg6h0xMvkDTyTltghkTZPl4IZdODxcCJMKN-Ki8=.8117d9d7-9325-482d-b232-49ca862413b2@github.com>
Message-ID: <voCTdkgKWb5cEMNNLGebSUp78Qwrjqxbd6Xd4ibBrEI=.1011a314-2882-488a-80da-b53e24869155@github.com>

On Thu, 1 Dec 2022 15:37:56 GMT, Afshin Zafari <duke at openjdk.org> wrote:

> ### Description
> The UseMallocOnly development option was originally used to detect memory stomping bugs with Arena allocations when the JVM was first in development.
> 
> The option has had a few bugs and is not in general use. There are ideas to add another way of Arena canary checking.
> 
> ### Patch:
> All occurrences of UseMallocOnly are removed.
> 
> ### Tests:
> Local, gTests: resourceArea and Arena
> Mach5: tier1-5

Good riddance :-)

I think `HandleArea` can be simplified too. It does a lot of gymnastics to work around the UseMallocOnly mode.

I believe you can scratch `HandleArea::real_allocate_handle()` and redirect `HandleArea::allocate_handle()` to directly call `Arena::Amalloc`. Have not tested though.

-------------

Changes requested by stuefe (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11456

From stuefe at openjdk.org  Thu Dec  1 19:03:21 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 1 Dec 2022 19:03:21 GMT
Subject: RFR: 8157023: Integrate NMT with JFR
In-Reply-To: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
Message-ID: <8te1F1Q3WVdcBzCreCuYRl0jkedcYPHKb6QnFdOPpI4=.78118156-5d0f-43bc-89e1-8ff00d6edee9@github.com>

On Thu, 1 Dec 2022 10:48:51 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> Please review this enhancement to include NMT information in JFR recordings.
> 
> **Summary**
> Native Memory Tracking summary information can be obtained from a running VM using `jcmd` if started with `-XX:NativeMemoryTracking=summary/detail`. Using `jcmd` requires you to run a separate process and to parse the output to get the needed information. This change adds JFR events for NMT information to enable additional ways to consume the NMT data.
> 
> There are two new events added:
> * _NativeMemoryUsage_ - The total native memory usage.
> * _NativeMemoryUsagePart_ - The native memory usage for each component.
> 
> These events are sent periodically and by default the interval is 1s. This can of course be discussed, but that is the staring point. When NMT is not enabled on events will be sent.
> 
> **Testing**
> * Added a simple test to verify that the events are sent as expected depending on if NMT is enabled or not.
> * Mach5 sanity testing

A case for selecting a static set of values to be reported via JFR from the "raw" NMT category mass would be that not only it hides implementation details but makes defining a compound JFR event possible.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From stuefe at openjdk.org  Thu Dec  1 19:14:33 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 1 Dec 2022 19:14:33 GMT
Subject: RFR: 8297967: Make frame::safe_for_sender safer
In-Reply-To: <6I48vsfx_IkJs4HMzGUjds8r3Dg-awUlRLE6ouQpY8M=.50787fa8-14bd-4735-a3a2-4a2fb04c530f@github.com>
References: <Cctc-M2HyUqIjpcRyTjmF46wKDqvBtnnYe5Mn45sdO8=.03bdf65f-bf98-48dc-b957-0c838003d46f@github.com>
 <PCsSkzdOCOqmet6YHeiNsbisnBqZzorKo8OqyEUbI4U=.834dad73-3af9-4305-ba21-497c16e05282@github.com>
 <6I48vsfx_IkJs4HMzGUjds8r3Dg-awUlRLE6ouQpY8M=.50787fa8-14bd-4735-a3a2-4a2fb04c530f@github.com>
Message-ID: <j2-c0gbESwZPXw2AtYCo90VlsDsZhNpR4MsUWfqDMIA=.cad38277-95ac-4fbc-927c-c1b9cd58f318@github.com>

On Thu, 1 Dec 2022 18:32:54 GMT, Johannes Bechberger <duke at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/frame_aarch64.cpp line 268:
>> 
>>> 266:   // Will the pc we fetch be non-zero (which we'll find at the oldest frame) and readable
>>> 267: 
>>> 268:   if (!os::is_readable_pointer(this->fp() + return_addr_offset * sizeof(address))) {
>> 
>> Address computation looks wrong: `fp()` returns an `intptr_t*`, so `return_addr_offset` gets scaled automatically before the addition. Wouldn't `thread->is_in_usable_stack(fp())` be a better check?
>
>> Wouldn't thread->is_in_usable_stack(fp()) be a better check?
> 
> No, this would check something different.
> 
>> Address computation looks wrong
> 
> But tests show that it seems to be correct.

I think Martin is right.

-------------

PR: https://git.openjdk.org/jdk/pull/11461

From duke at openjdk.org  Thu Dec  1 19:14:34 2022
From: duke at openjdk.org (Johannes Bechberger)
Date: Thu, 1 Dec 2022 19:14:34 GMT
Subject: RFR: 8297967: Make frame::safe_for_sender safer
In-Reply-To: <j2-c0gbESwZPXw2AtYCo90VlsDsZhNpR4MsUWfqDMIA=.cad38277-95ac-4fbc-927c-c1b9cd58f318@github.com>
References: <Cctc-M2HyUqIjpcRyTjmF46wKDqvBtnnYe5Mn45sdO8=.03bdf65f-bf98-48dc-b957-0c838003d46f@github.com>
 <PCsSkzdOCOqmet6YHeiNsbisnBqZzorKo8OqyEUbI4U=.834dad73-3af9-4305-ba21-497c16e05282@github.com>
 <6I48vsfx_IkJs4HMzGUjds8r3Dg-awUlRLE6ouQpY8M=.50787fa8-14bd-4735-a3a2-4a2fb04c530f@github.com>
 <j2-c0gbESwZPXw2AtYCo90VlsDsZhNpR4MsUWfqDMIA=.cad38277-95ac-4fbc-927c-c1b9cd58f318@github.com>
Message-ID: <M5EciM5S2jcCWgWDNfXBY5J7o2QAlopzl69Y8hPaq70=.af4f37d3-3a0c-4dd4-963c-94ec6ffe7b8f@github.com>

On Thu, 1 Dec 2022 19:06:23 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>>> Wouldn't thread->is_in_usable_stack(fp()) be a better check?
>> 
>> No, this would check something different.
>> 
>>> Address computation looks wrong
>> 
>> But tests show that it seems to be correct.
>
> I think Martin is right.

With the first or the second point?

-------------

PR: https://git.openjdk.org/jdk/pull/11461

From duke at openjdk.org  Thu Dec  1 19:14:34 2022
From: duke at openjdk.org (Johannes Bechberger)
Date: Thu, 1 Dec 2022 19:14:34 GMT
Subject: RFR: 8297967: Make frame::safe_for_sender safer
In-Reply-To: <M5EciM5S2jcCWgWDNfXBY5J7o2QAlopzl69Y8hPaq70=.af4f37d3-3a0c-4dd4-963c-94ec6ffe7b8f@github.com>
References: <Cctc-M2HyUqIjpcRyTjmF46wKDqvBtnnYe5Mn45sdO8=.03bdf65f-bf98-48dc-b957-0c838003d46f@github.com>
 <PCsSkzdOCOqmet6YHeiNsbisnBqZzorKo8OqyEUbI4U=.834dad73-3af9-4305-ba21-497c16e05282@github.com>
 <6I48vsfx_IkJs4HMzGUjds8r3Dg-awUlRLE6ouQpY8M=.50787fa8-14bd-4735-a3a2-4a2fb04c530f@github.com>
 <j2-c0gbESwZPXw2AtYCo90VlsDsZhNpR4MsUWfqDMIA=.cad38277-95ac-4fbc-927c-c1b9cd58f318@github.com>
 <M5EciM5S2jcCWgWDNfXBY5J7o2QAlopzl69Y8hPaq70=.af4f37d3-3a0c-4dd4-963c-94ec6ffe7b8f@github.com>
Message-ID: <jdNoIh1N9_BCXaLsg18HsUd9PFUijLJgdtw9NazhXLQ=.7cd15710-0626-4f6e-b038-dac5624c115b@github.com>

On Thu, 1 Dec 2022 19:08:21 GMT, Johannes Bechberger <duke at openjdk.org> wrote:

>> I think Martin is right.
>
> With the first or the second point?

To his second point: You have to check the return address location, not just `fp()`.

-------------

PR: https://git.openjdk.org/jdk/pull/11461

From duke at openjdk.org  Thu Dec  1 19:18:25 2022
From: duke at openjdk.org (Johannes Bechberger)
Date: Thu, 1 Dec 2022 19:18:25 GMT
Subject: RFR: 8297967: Make frame::safe_for_sender safer
In-Reply-To: <jdNoIh1N9_BCXaLsg18HsUd9PFUijLJgdtw9NazhXLQ=.7cd15710-0626-4f6e-b038-dac5624c115b@github.com>
References: <Cctc-M2HyUqIjpcRyTjmF46wKDqvBtnnYe5Mn45sdO8=.03bdf65f-bf98-48dc-b957-0c838003d46f@github.com>
 <PCsSkzdOCOqmet6YHeiNsbisnBqZzorKo8OqyEUbI4U=.834dad73-3af9-4305-ba21-497c16e05282@github.com>
 <6I48vsfx_IkJs4HMzGUjds8r3Dg-awUlRLE6ouQpY8M=.50787fa8-14bd-4735-a3a2-4a2fb04c530f@github.com>
 <j2-c0gbESwZPXw2AtYCo90VlsDsZhNpR4MsUWfqDMIA=.cad38277-95ac-4fbc-927c-c1b9cd58f318@github.com>
 <M5EciM5S2jcCWgWDNfXBY5J7o2QAlopzl69Y8hPaq70=.af4f37d3-3a0c-4dd4-963c-94ec6ffe7b8f@github.com>
 <jdNoIh1N9_BCXaLsg18HsUd9PFUijLJgdtw9NazhXLQ=.7cd15710-0626-4f6e-b038-dac5624c115b@github.com>
Message-ID: <uZ0FxNNbjqX4-kPTeFai6gAtUV00fNLQrBJJc-1BofE=.3521e1f1-d0ab-4c9a-9520-d59376d66707@github.com>

On Thu, 1 Dec 2022 19:09:48 GMT, Johannes Bechberger <duke at openjdk.org> wrote:

>> With the first or the second point?
>
> To his second point: You have to check the return address location, not just `fp()`.

I stand correct, it also helps. I'll change the PR.

-------------

PR: https://git.openjdk.org/jdk/pull/11461

From duke at openjdk.org  Thu Dec  1 19:21:54 2022
From: duke at openjdk.org (Johannes Bechberger)
Date: Thu, 1 Dec 2022 19:21:54 GMT
Subject: RFR: 8297967: Make frame::safe_for_sender safer [v2]
In-Reply-To: <Cctc-M2HyUqIjpcRyTjmF46wKDqvBtnnYe5Mn45sdO8=.03bdf65f-bf98-48dc-b957-0c838003d46f@github.com>
References: <Cctc-M2HyUqIjpcRyTjmF46wKDqvBtnnYe5Mn45sdO8=.03bdf65f-bf98-48dc-b957-0c838003d46f@github.com>
Message-ID: <W7jCII0F-N-vINSt1vg_g0ejpVSv27GSlBtuKRyS790=.ec4382ea-28b1-4daa-8812-57a7b2be9e18@github.com>

> Makes frame::safe_for_sender safer by using os::is_readable_pointer to check the location of the return address.

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Imrove fix, thanks Martin

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11461/files
  - new: https://git.openjdk.org/jdk/pull/11461/files/01d5e721..a8903005

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11461&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11461&range=00-01

  Stats: 7 lines in 3 files changed: 4 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/11461.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11461/head:pull/11461

PR: https://git.openjdk.org/jdk/pull/11461

From kbarrett at openjdk.org  Thu Dec  1 20:03:35 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 1 Dec 2022 20:03:35 GMT
Subject: RFR: 8297830: aarch64: Make Address a discriminated union
 internally [v2]
In-Reply-To: <aP7eQIy57CcOuDDWStdWmefZIfIs_JYRV2Mpqwt5bAY=.34015ef8-fb4c-4276-a003-728dc02530ca@github.com>
References: <aP7eQIy57CcOuDDWStdWmefZIfIs_JYRV2Mpqwt5bAY=.34015ef8-fb4c-4276-a003-728dc02530ca@github.com>
Message-ID: <9SlZqWUpamBg__afJDYMcepR7c8VwWzzhIL_MXFQZ9Q=.3cc72c8e-9106-4a86-ad88-f61f27b80055@github.com>

> Please review this change to the aarch64 Address class.  It now uses an
> internal union, separating the literal and nonliteral cases.
> 
> This avoids leaving some fields uninitialized or initializing them to dummy
> values.  It also reduces the size of the Address class somewhat, though it's
> unclear whether that makes any noticeable difference.
> 
> Testing:
> mach5 tier1 for linux-aarch64 and macosx-aarch64
> mach5 tier2-5 for linux-aarch64

Kim Barrett 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 two additional commits since the last revision:

 - Merge branch 'master' into unionize2
 - unionize

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11429/files
  - new: https://git.openjdk.org/jdk/pull/11429/files/eb4f70b8..5b0571cc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11429&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11429&range=00-01

  Stats: 8750 lines in 270 files changed: 4843 ins; 2321 del; 1586 mod
  Patch: https://git.openjdk.org/jdk/pull/11429.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11429/head:pull/11429

PR: https://git.openjdk.org/jdk/pull/11429

From kbarrett at openjdk.org  Thu Dec  1 20:03:36 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 1 Dec 2022 20:03:36 GMT
Subject: RFR: 8297830: aarch64: Make Address a discriminated union
 internally [v2]
In-Reply-To: <5y76cUcUmXU65CqHVy12wRWidDj6QAifCRGryIx1-Hw=.e50e42f6-b765-4986-8754-5a2b91175505@github.com>
References: <aP7eQIy57CcOuDDWStdWmefZIfIs_JYRV2Mpqwt5bAY=.34015ef8-fb4c-4276-a003-728dc02530ca@github.com>
 <in_YbHtsyqlgu8Z4BR0D9U-cGYvuTvYDDCL_0WwP15s=.42fe7b60-592b-4f94-babc-249dd5761e0e@github.com>
 <_t8eVN9t_wi4Ap0MbkHbVzdBn8F1obrLd1k8FARg888=.19819b97-e9dc-4f42-b926-5843a12a4056@github.com>
 <5y76cUcUmXU65CqHVy12wRWidDj6QAifCRGryIx1-Hw=.e50e42f6-b765-4986-8754-5a2b91175505@github.com>
Message-ID: <BPxY9KShD7N6jWDYSSfg_ZCfosj5rsl6GbPymED1RFU=.1bed88ef-0406-4f98-bace-bf56652b0694@github.com>

On Wed, 30 Nov 2022 18:15:35 GMT, Andrew Haley <aph at openjdk.org> wrote:

>>> OK, thanks. It does seem to me a bit like moving the furniture around, but I have to admit it's an improvement. :-)
>> 
>> The driver for all these cleanups around aarch64 Address is that when I tried to fix JDK-8160404 I got (valid) compiler warnings here about UB.
>
>> The driver for all these cleanups around aarch64 Address is that when I tried to fix JDK-8160404 I got (valid) compiler warnings here about UB.
> 
> Aha! Thanks. It's good to have that here, in the discussion.

Thanks for reviews @theRealAph and @dcubed-ojdk .

-------------

PR: https://git.openjdk.org/jdk/pull/11429

From kbarrett at openjdk.org  Thu Dec  1 20:19:31 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 1 Dec 2022 20:19:31 GMT
Subject: Integrated: 8297830: aarch64: Make Address a discriminated union
 internally
In-Reply-To: <aP7eQIy57CcOuDDWStdWmefZIfIs_JYRV2Mpqwt5bAY=.34015ef8-fb4c-4276-a003-728dc02530ca@github.com>
References: <aP7eQIy57CcOuDDWStdWmefZIfIs_JYRV2Mpqwt5bAY=.34015ef8-fb4c-4276-a003-728dc02530ca@github.com>
Message-ID: <Xt5pHz6nT5e_x83S2JEOprQG8QKtviAbpEZUCNMc1mU=.6d6a068a-b064-4027-9f8a-08eae3b7a538@github.com>

On Wed, 30 Nov 2022 11:13:35 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to the aarch64 Address class.  It now uses an
> internal union, separating the literal and nonliteral cases.
> 
> This avoids leaving some fields uninitialized or initializing them to dummy
> values.  It also reduces the size of the Address class somewhat, though it's
> unclear whether that makes any noticeable difference.
> 
> Testing:
> mach5 tier1 for linux-aarch64 and macosx-aarch64
> mach5 tier2-5 for linux-aarch64

This pull request has now been integrated.

Changeset: 5a5ced3a
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5a5ced3a900a81fd0b0757017f4138ce97e2521e
Stats:     205 lines in 3 files changed: 110 ins; 16 del; 79 mod

8297830: aarch64: Make Address a discriminated union internally

Reviewed-by: aph, dcubed

-------------

PR: https://git.openjdk.org/jdk/pull/11429

From rehn at openjdk.org  Thu Dec  1 21:24:34 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Thu, 1 Dec 2022 21:24:34 GMT
Subject: RFR: 8297864: Dead code elimination [v2]
In-Reply-To: <va_DhGhbW7yeCHuFlm1vugbiqYHxZrRsNGhpE61HQ80=.8500833a-60ae-4805-854e-9c0f0bdfe0e4@github.com>
References: <va_DhGhbW7yeCHuFlm1vugbiqYHxZrRsNGhpE61HQ80=.8500833a-60ae-4805-854e-9c0f0bdfe0e4@github.com>
Message-ID: <KUPpZUVSn4u8nJGP5e781lLG5OIHoDE7WpRzpGHJVDQ=.ccd4de2a-6633-4e22-b331-cab45107b32d@github.com>

> Please consider removing all this dead code.
> I did not have any good way of splitting this up and I did not see any benefit is just splitting it up 'just because'.
> There is one commit per file couple.
> Not much else to say, passes t1-4 and I can build:
> linux-aarch64-debug,linux-arm32-debug,linux-ppc64le-debug,linux-s390x-debug,linux-x86,linux-x86-debug,macosx-aarch64-debug,macosx-x64,macosx-x64-debug,windows-x64-debug,windows-x86-debug and zero-x64-debug
> Some of them I also built release.

Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:

  Remove code missed in a merge

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11439/files
  - new: https://git.openjdk.org/jdk/pull/11439/files/4dd56f2a..480495ef

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11439&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11439&range=00-01

  Stats: 10 lines in 1 file changed: 0 ins; 10 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11439.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11439/head:pull/11439

PR: https://git.openjdk.org/jdk/pull/11439

From dholmes at openjdk.org  Fri Dec  2 02:53:11 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 2 Dec 2022 02:53:11 GMT
Subject: RFR: 8297766: Remove UseMallocOnly development option
In-Reply-To: <34gopg6h0xMvkDTyTltghkTZPl4IZdODxcCJMKN-Ki8=.8117d9d7-9325-482d-b232-49ca862413b2@github.com>
References: <34gopg6h0xMvkDTyTltghkTZPl4IZdODxcCJMKN-Ki8=.8117d9d7-9325-482d-b232-49ca862413b2@github.com>
Message-ID: <7bToEeIH0fw95AdYNI6WP1E0rGNq6mwFh7Diqa0DUrM=.31cfd8a4-53db-4d11-bce0-f06a13f26f08@github.com>

On Thu, 1 Dec 2022 15:37:56 GMT, Afshin Zafari <duke at openjdk.org> wrote:

> ### Description
> The UseMallocOnly development option was originally used to detect memory stomping bugs with Arena allocations when the JVM was first in development.
> 
> The option has had a few bugs and is not in general use. There are ideas to add another way of Arena canary checking.
> 
> ### Patch:
> All occurrences of UseMallocOnly are removed.
> 
> ### Tests:
> Local, gTests: resourceArea and Arena
> Mach5: tier1-5

Removal looks good! Nice cleanup.

Thanks.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11456

From dholmes at openjdk.org  Fri Dec  2 03:09:07 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 2 Dec 2022 03:09:07 GMT
Subject: RFR: 8297864: Dead code elimination [v2]
In-Reply-To: <KUPpZUVSn4u8nJGP5e781lLG5OIHoDE7WpRzpGHJVDQ=.ccd4de2a-6633-4e22-b331-cab45107b32d@github.com>
References: <va_DhGhbW7yeCHuFlm1vugbiqYHxZrRsNGhpE61HQ80=.8500833a-60ae-4805-854e-9c0f0bdfe0e4@github.com>
 <KUPpZUVSn4u8nJGP5e781lLG5OIHoDE7WpRzpGHJVDQ=.ccd4de2a-6633-4e22-b331-cab45107b32d@github.com>
Message-ID: <m9AsrIe0Zhz6GiXEIiViaQ5IZw2U091R_KD-4QBYsb8=.a252030c-3778-46c2-9a61-60f422aa9cb9@github.com>

On Thu, 1 Dec 2022 21:24:34 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Please consider removing all this dead code.
>> I did not have any good way of splitting this up and I did not see any benefit is just splitting it up 'just because'.
>> There is one commit per file couple.
>> Not much else to say, passes t1-4 and I can build:
>> linux-aarch64-debug,linux-arm32-debug,linux-ppc64le-debug,linux-s390x-debug,linux-x86,linux-x86-debug,macosx-aarch64-debug,macosx-x64,macosx-x64-debug,windows-x64-debug,windows-x86-debug and zero-x64-debug
>> Some of them I also built release.
>
> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove code missed in a merge

Hmm I think this warrants closer inspection to ensure there isn't a bug because something is unused (e.g. `is_in_asgct()` code in forte.cpp).

Also IIRC Loom knowingly integrated a lot of code that will only come in to play in future previews and so it may not be appropriate to cull it now. Perhaps @pchilano can comment?

-------------

PR: https://git.openjdk.org/jdk/pull/11439

From fyang at openjdk.org  Fri Dec  2 05:41:38 2022
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 2 Dec 2022 05:41:38 GMT
Subject: RFR: 8297967: Make frame::safe_for_sender safer [v2]
In-Reply-To: <W7jCII0F-N-vINSt1vg_g0ejpVSv27GSlBtuKRyS790=.ec4382ea-28b1-4daa-8812-57a7b2be9e18@github.com>
References: <Cctc-M2HyUqIjpcRyTjmF46wKDqvBtnnYe5Mn45sdO8=.03bdf65f-bf98-48dc-b957-0c838003d46f@github.com>
 <W7jCII0F-N-vINSt1vg_g0ejpVSv27GSlBtuKRyS790=.ec4382ea-28b1-4daa-8812-57a7b2be9e18@github.com>
Message-ID: <FWuqIBRIn1Y1ddcyZZLfsfx-_kDBI5AVurZwvQnw36M=.824e5311-399b-478e-b7ed-bb46eec4c2aa@github.com>

On Thu, 1 Dec 2022 19:21:54 GMT, Johannes Bechberger <duke at openjdk.org> wrote:

>> Makes frame::safe_for_sender safer by using os::is_readable_pointer to check the location of the return address.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Imrove fix, thanks Martin

src/hotspot/cpu/aarch64/frame_aarch64.cpp line 268:

> 266:   // Will the pc we fetch be non-zero (which we'll find at the oldest frame) and readable
> 267: 
> 268:   if (!thread->is_in_usable_stack((address)this->fp())) {

Is this check really necessary? 'fp_safe' is true when we come here. Then it looks to me that the two preceding checks has already ensured that condition 'thread->is_in_usable_stack((address)this->fp())' will always evaluate to true here.

[1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/frame_aarch64.cpp#L68
[2] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/frame_aarch64.cpp#L90

-------------

PR: https://git.openjdk.org/jdk/pull/11461

From duke at openjdk.org  Fri Dec  2 06:14:09 2022
From: duke at openjdk.org (Johannes Bechberger)
Date: Fri, 2 Dec 2022 06:14:09 GMT
Subject: RFR: 8297967: Make frame::safe_for_sender safer [v2]
In-Reply-To: <FWuqIBRIn1Y1ddcyZZLfsfx-_kDBI5AVurZwvQnw36M=.824e5311-399b-478e-b7ed-bb46eec4c2aa@github.com>
References: <Cctc-M2HyUqIjpcRyTjmF46wKDqvBtnnYe5Mn45sdO8=.03bdf65f-bf98-48dc-b957-0c838003d46f@github.com>
 <W7jCII0F-N-vINSt1vg_g0ejpVSv27GSlBtuKRyS790=.ec4382ea-28b1-4daa-8812-57a7b2be9e18@github.com>
 <FWuqIBRIn1Y1ddcyZZLfsfx-_kDBI5AVurZwvQnw36M=.824e5311-399b-478e-b7ed-bb46eec4c2aa@github.com>
Message-ID: <RejOSw1JjBA2pQFJGB3Dxj9cqjQa8YNFQi-GHVZByXE=.0cd28c78-5637-4057-9447-b542c5aaffda@github.com>

On Fri, 2 Dec 2022 05:38:23 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Imrove fix, thanks Martin
>
> src/hotspot/cpu/aarch64/frame_aarch64.cpp line 268:
> 
>> 266:   // Will the pc we fetch be non-zero (which we'll find at the oldest frame) and readable
>> 267: 
>> 268:   if (!thread->is_in_usable_stack((address)this->fp())) {
> 
> Is this check really necessary? 'fp_safe' is true when we come here. Then it looks to me that the two preceding checks has already ensured that condition 'thread->is_in_usable_stack((address)this->fp())' will always evaluate to true here.
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/frame_aarch64.cpp#L68
> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/frame_aarch64.cpp#L90

I'll get crashes in my fuzzing test case if I leave it out.

-------------

PR: https://git.openjdk.org/jdk/pull/11461

From dholmes at openjdk.org  Fri Dec  2 06:21:10 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 2 Dec 2022 06:21:10 GMT
Subject: RFR: 8297967: Make frame::safe_for_sender safer [v2]
In-Reply-To: <W7jCII0F-N-vINSt1vg_g0ejpVSv27GSlBtuKRyS790=.ec4382ea-28b1-4daa-8812-57a7b2be9e18@github.com>
References: <Cctc-M2HyUqIjpcRyTjmF46wKDqvBtnnYe5Mn45sdO8=.03bdf65f-bf98-48dc-b957-0c838003d46f@github.com>
 <W7jCII0F-N-vINSt1vg_g0ejpVSv27GSlBtuKRyS790=.ec4382ea-28b1-4daa-8812-57a7b2be9e18@github.com>
Message-ID: <von5goZqsx75r-ItON4mTgaDJFgamd2owraTwQ5U8qg=.0a09bc75-ba35-496f-9b1c-ff400a8e5a68@github.com>

On Thu, 1 Dec 2022 19:21:54 GMT, Johannes Bechberger <duke at openjdk.org> wrote:

>> Makes frame::safe_for_sender safer by using os::is_readable_pointer to check the location of the return address.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Imrove fix, thanks Martin

Changes requested by dholmes (Reviewer).

src/hotspot/cpu/aarch64/frame_aarch64.cpp line 45:

> 43: #include "runtime/stubRoutines.hpp"
> 44: #include "vmreg_aarch64.inline.hpp"
> 45: #include "runtime/os.hpp"

Please keep the include files in sorted order.

src/hotspot/cpu/x86/frame_x86.cpp line 260:

> 258:   if (!thread->is_in_usable_stack((address)this->fp())) {
> 259:     return false;
> 260:   }

This looks like a paste error - you've deleted a line that is needed and now you have two comment lines.

-------------

PR: https://git.openjdk.org/jdk/pull/11461

From dholmes at openjdk.org  Fri Dec  2 06:21:14 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 2 Dec 2022 06:21:14 GMT
Subject: RFR: 8297967: Make frame::safe_for_sender safer [v2]
In-Reply-To: <RejOSw1JjBA2pQFJGB3Dxj9cqjQa8YNFQi-GHVZByXE=.0cd28c78-5637-4057-9447-b542c5aaffda@github.com>
References: <Cctc-M2HyUqIjpcRyTjmF46wKDqvBtnnYe5Mn45sdO8=.03bdf65f-bf98-48dc-b957-0c838003d46f@github.com>
 <W7jCII0F-N-vINSt1vg_g0ejpVSv27GSlBtuKRyS790=.ec4382ea-28b1-4daa-8812-57a7b2be9e18@github.com>
 <FWuqIBRIn1Y1ddcyZZLfsfx-_kDBI5AVurZwvQnw36M=.824e5311-399b-478e-b7ed-bb46eec4c2aa@github.com>
 <RejOSw1JjBA2pQFJGB3Dxj9cqjQa8YNFQi-GHVZByXE=.0cd28c78-5637-4057-9447-b542c5aaffda@github.com>
Message-ID: <u8vLzfKWPN8ylMl_3rA9uKXYD1kc9u0PsnUpxr5fMCs=.a4248d04-bc0a-4661-be88-274ef8d297a5@github.com>

On Fri, 2 Dec 2022 06:11:33 GMT, Johannes Bechberger <duke at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/frame_aarch64.cpp line 268:
>> 
>>> 266:   // Will the pc we fetch be non-zero (which we'll find at the oldest frame) and readable
>>> 267: 
>>> 268:   if (!thread->is_in_usable_stack((address)this->fp())) {
>> 
>> Is this check really necessary? 'fp_safe' is true when we come here. Then it looks to me that the two preceding checks has already ensured that condition 'thread->is_in_usable_stack((address)this->fp())' will always evaluate to true here.
>> 
>> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/frame_aarch64.cpp#L68
>> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/frame_aarch64.cpp#L90
>
> I'll get crashes in my fuzzing test case if I leave it out.

I agree fp has already been validated.

-------------

PR: https://git.openjdk.org/jdk/pull/11461

From rehn at openjdk.org  Fri Dec  2 06:43:41 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Fri, 2 Dec 2022 06:43:41 GMT
Subject: RFR: 8297864: Dead code elimination [v2]
In-Reply-To: <m9AsrIe0Zhz6GiXEIiViaQ5IZw2U091R_KD-4QBYsb8=.a252030c-3778-46c2-9a61-60f422aa9cb9@github.com>
References: <va_DhGhbW7yeCHuFlm1vugbiqYHxZrRsNGhpE61HQ80=.8500833a-60ae-4805-854e-9c0f0bdfe0e4@github.com>
 <KUPpZUVSn4u8nJGP5e781lLG5OIHoDE7WpRzpGHJVDQ=.ccd4de2a-6633-4e22-b331-cab45107b32d@github.com>
 <m9AsrIe0Zhz6GiXEIiViaQ5IZw2U091R_KD-4QBYsb8=.a252030c-3778-46c2-9a61-60f422aa9cb9@github.com>
Message-ID: <neTD-2nUk8r2p1Ytc5iHcoP8pLWJFheXMwY0YcXrX30=.7c3170c1-c3e7-4ad0-a34f-3a3c253584c4@github.com>

On Fri, 2 Dec 2022 03:06:27 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hmm I think this warrants closer inspection to ensure there isn't a bug because something is unused (e.g. `is_in_asgct()` code in forte.cpp).

Maybe this flag was read by solaris studio or so, way back. No readers today.

> Also IIRC Loom knowingly integrated a lot of code that will only come in to play in future previews and so it may not be appropriate to cull it now. Perhaps @pchilano can comment?

The code is still in loom/fibers, when they merge with mainline they can choice to keep it in loom/fiber.
When they have new code using it, it will part of integrating that.

-------------

PR: https://git.openjdk.org/jdk/pull/11439

From duke at openjdk.org  Fri Dec  2 07:11:06 2022
From: duke at openjdk.org (Johannes Bechberger)
Date: Fri, 2 Dec 2022 07:11:06 GMT
Subject: RFR: 8297967: Make frame::safe_for_sender safer [v2]
In-Reply-To: <W7jCII0F-N-vINSt1vg_g0ejpVSv27GSlBtuKRyS790=.ec4382ea-28b1-4daa-8812-57a7b2be9e18@github.com>
References: <Cctc-M2HyUqIjpcRyTjmF46wKDqvBtnnYe5Mn45sdO8=.03bdf65f-bf98-48dc-b957-0c838003d46f@github.com>
 <W7jCII0F-N-vINSt1vg_g0ejpVSv27GSlBtuKRyS790=.ec4382ea-28b1-4daa-8812-57a7b2be9e18@github.com>
Message-ID: <N1qA9NJKUK2uH2aYDl-OH2TcyH0LSRkg4Mo6nMUENpI=.6951e690-ad78-4a2f-b282-4c56f951ed0b@github.com>

On Thu, 1 Dec 2022 19:21:54 GMT, Johannes Bechberger <duke at openjdk.org> wrote:

>> Makes frame::safe_for_sender safer by using os::is_readable_pointer to check the location of the return address.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Imrove fix, thanks Martin

I converted it back to a draft and look into next week with more vigor.

-------------

PR: https://git.openjdk.org/jdk/pull/11461

From rehn at openjdk.org  Fri Dec  2 07:14:35 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Fri, 2 Dec 2022 07:14:35 GMT
Subject: RFR: 8297864: Dead code elimination [v3]
In-Reply-To: <va_DhGhbW7yeCHuFlm1vugbiqYHxZrRsNGhpE61HQ80=.8500833a-60ae-4805-854e-9c0f0bdfe0e4@github.com>
References: <va_DhGhbW7yeCHuFlm1vugbiqYHxZrRsNGhpE61HQ80=.8500833a-60ae-4805-854e-9c0f0bdfe0e4@github.com>
Message-ID: <Ez7EMefJjwCfLV-uv8cPGgqd-YRzfxOslue8K4CnM38=.1bb9f918-652f-43af-8eee-5133cdd99469@github.com>

> Please consider removing all this dead code.
> I did not have any good way of splitting this up and I did not see any benefit is just splitting it up 'just because'.
> There is one commit per file couple.
> Not much else to say, passes t1-4 and I can build:
> linux-aarch64-debug,linux-arm32-debug,linux-ppc64le-debug,linux-s390x-debug,linux-x86,linux-x86-debug,macosx-aarch64-debug,macosx-x64,macosx-x64-debug,windows-x64-debug,windows-x86-debug and zero-x64-debug
> Some of them I also built release.

Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:

  Fixed whitespace nit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11439/files
  - new: https://git.openjdk.org/jdk/pull/11439/files/480495ef..cce07f52

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11439&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11439&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11439.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11439/head:pull/11439

PR: https://git.openjdk.org/jdk/pull/11439

From sspitsyn at openjdk.org  Fri Dec  2 07:26:17 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 2 Dec 2022 07:26:17 GMT
Subject: RFR: 8291830: jvmti/RedefineClasses/StressRedefine failed:
 assert(!is_null(v)) failed: narrow klass value can never be zero
In-Reply-To: <Mbg2-xljhBlEKcDh2PK5liK7-rBy-DUUsGo4JzdAal8=.e376169b-5cbd-4123-9f67-d4d219121bdc@github.com>
References: <Mbg2-xljhBlEKcDh2PK5liK7-rBy-DUUsGo4JzdAal8=.e376169b-5cbd-4123-9f67-d4d219121bdc@github.com>
Message-ID: <Xn-bdMbrLB53KTEWdS3qOdYnHwKjAYiScVk96KBe_4s=.949ecd1e-ff46-4cc9-9ced-0fc8d0cdc865@github.com>

On Thu, 1 Dec 2022 02:01:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The code for RedefineVerifyMark in redefinition replaces the OopHandle mirror so that the verification has the right mirror, but it really should just copy it.  Replacing an OopHandle in the ClassLoaderData didn't set the has_modified_oops flag so GC wasn't noticing that this handle is old.
> 
> Tested with tier1-4 and tier6 in progress (linux-x64 and windows-x64 done).

Coleen,
This looks good.
Wow, it is great you've found the root cause!
It was not easy for sure.
Thanks,
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11444

From stuefe at openjdk.org  Fri Dec  2 07:44:17 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 2 Dec 2022 07:44:17 GMT
Subject: RFR: JDK-8296907: VMError: add optional callstacks,
 siginfo for secondary errors [v12]
In-Reply-To: <oxflPz5qkquAtnkHzN1SvOCysUV7ug1IUebbVK4n8ro=.e9904f64-1e92-41ec-8d8b-953b2d3344ce@github.com>
References: <x1kul17oEaJ-UX6ZGPv8OcsxN8QfYlME_d39aSATk-Q=.f0e0169c-15f5-4b4b-8235-68f8e68ec43c@github.com>
 <oxflPz5qkquAtnkHzN1SvOCysUV7ug1IUebbVK4n8ro=.e9904f64-1e92-41ec-8d8b-953b2d3344ce@github.com>
Message-ID: <rp6qUYaiD6FrXWTYb_OCXAiaXPQM92uSdeGBHf1U8Eo=.5885d36f-31ec-4766-8450-6367ffd12a64@github.com>

On Thu, 1 Dec 2022 16:36:25 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> This was motivated by discussions we had in https://github.com/openjdk/jdk/pull/11017.
>> 
>> To aid in analyzing secondary errors during error reporting, it would be useful to see their callstacks for secondary errors. But printing callstacks during error reporting is unsafe - if we get a second crash or assert, it will cause infinite recursion and interrupt error reporting. Also, the hs-err file would be quite verbose. Therefore this feature is optional and limited to debug builds. 
>> 
>> ---
>> 
>> Patch
>> 
>> - adds optional callstack/siginfo printing via debug-only switch `-XX:+ErrorLogSecondaryErrorDetails`.
>> - fixes a bug in secondary error handling where we would use the global scratch buffer recursively (via stringStream); that could lead to confusing output since it is used by the error log stream already. We can print directly to that one instead.
>> - Removed a stray newline from print_native_stack to clean output.
>> - added regression testing for this feature. I removed my name and the bug id from the test since we don't do this anymore (?).
>> - added clarifying comments to the test and code
>> - added SAP copyright to the regression test (we introduced it years ago for JDK-8065895)
>> 
>> Output looks like this:
>> 
>> 
>> $ java ... -XX:+ErrorLogSecondaryErrorDetails
>> 
>> 
>> will produce, for secondary errors, siginfo and call stack.
>> 
>> 
>> [error occurred during error reporting (test secondary crash 1), id 0xb, SIGSEGV (0xb) at pc=0x00007fddfe8a0a61]
>> [siginfo: si_signo: 11 (SIGSEGV), si_code: 128 (SI_KERNEL), si_addr: 0x0000000000000000]
>> [stack: Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0x1ceea61]  VMError::controlled_crash(int)+0x241  (vmError.cpp:1946)
>> V  [libjvm.so+0x1cf413f]  VMError::report(outputStream*, bool)+0x46bf  (vmError.cpp:564)
>> V  [libjvm.so+0x1cf516b]  VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x19b  (vmError.cpp:1709)
>> V  [libjvm.so+0x1cf5e8f]  VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*, char const*, ...)+0x8f  (vmError.cpp:1467)
>> V  [libjvm.so+0x1cf5ec2]  VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*)+0x22  (vmError.cpp:1473)
>> V  [libjvm.so+0x1a549e7]  JVM_handle_linux_signal+0x1f7  (signals_posix.cpp:656)
>> C  [libc.so.6+0x43090]
>> V  [libjvm.so+0x11d6965]  JNI_CreateJavaVM+0x5b5  (jni.cpp:3662)
>> C  [libjli.so+0x4013]  JavaMain+0x93  (java.c:1457)
>> C  [libjli.so+0x800d]  ThreadJavaMain+0xd  (java_md.c:650)
>> ]
>
> Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove unused imports from test
>  - Make ErrorLogSecondaryErrorDetails a diagnostic product flag

Our nightly tests are green. GHA errors unrelated. I re-ran tests on 32-bit x86, all good. If I don't hear any objections, I will integrate later today.

-------------

PR: https://git.openjdk.org/jdk/pull/11118

From sjohanss at openjdk.org  Fri Dec  2 08:06:09 2022
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Fri, 2 Dec 2022 08:06:09 GMT
Subject: RFR: 8157023: Integrate NMT with JFR
In-Reply-To: <5etH99SkJXLDG9IeW1kNIjvCWU-Ydhbg5JBMZM34tFg=.7401c117-7dbb-4ea0-89e1-31bbe6f0d78b@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <5etH99SkJXLDG9IeW1kNIjvCWU-Ydhbg5JBMZM34tFg=.7401c117-7dbb-4ea0-89e1-31bbe6f0d78b@github.com>
Message-ID: <ZOYTp9BUze3EkwxKw23_gaSVw9YZcNpd3c_dgBsyVqo=.590510f7-9d96-4f3e-b565-8664db3d8f8d@github.com>

On Thu, 1 Dec 2022 13:00:11 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Please review this enhancement to include NMT information in JFR recordings.
>> 
>> **Summary**
>> Native Memory Tracking summary information can be obtained from a running VM using `jcmd` if started with `-XX:NativeMemoryTracking=summary/detail`. Using `jcmd` requires you to run a separate process and to parse the output to get the needed information. This change adds JFR events for NMT information to enable additional ways to consume the NMT data.
>> 
>> There are two new events added:
>> * _NativeMemoryUsage_ - The total native memory usage.
>> * _NativeMemoryUsagePart_ - The native memory usage for each component.
>> 
>> These events are sent periodically and by default the interval is 1s. This can of course be discussed, but that is the staring point. When NMT is not enabled on events will be sent.
>> 
>> **Testing**
>> * Added a simple test to verify that the events are sent as expected depending on if NMT is enabled or not.
>> * Mach5 sanity testing
>
> src/hotspot/share/services/memReporter.cpp line 36:
> 
>> 34: #include "utilities/globalDefinitions.hpp"
>> 35: 
>> 36: size_t MemReporterBase::reserved_total(const MallocMemory* malloc, const VirtualMemory* vm) {
> 
> Why the const removal?

I turned `reserved_total(...)` and `committed_total(...)`into a static helpers since they did not use any members. That way my new reporter did not have to inherit `MemReporter`.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From stuefe at openjdk.org  Fri Dec  2 08:09:17 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 2 Dec 2022 08:09:17 GMT
Subject: RFR: 8157023: Integrate NMT with JFR
In-Reply-To: <ZOYTp9BUze3EkwxKw23_gaSVw9YZcNpd3c_dgBsyVqo=.590510f7-9d96-4f3e-b565-8664db3d8f8d@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <5etH99SkJXLDG9IeW1kNIjvCWU-Ydhbg5JBMZM34tFg=.7401c117-7dbb-4ea0-89e1-31bbe6f0d78b@github.com>
 <ZOYTp9BUze3EkwxKw23_gaSVw9YZcNpd3c_dgBsyVqo=.590510f7-9d96-4f3e-b565-8664db3d8f8d@github.com>
Message-ID: <mBWyCfeVG6ERYrKkYpc-ti5rLuRAGLfa3uZP2oAek3Y=.bc8edb10-3080-40f3-81b6-b5684efcf358@github.com>

On Fri, 2 Dec 2022 08:04:01 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> src/hotspot/share/services/memReporter.cpp line 36:
>> 
>>> 34: #include "utilities/globalDefinitions.hpp"
>>> 35: 
>>> 36: size_t MemReporterBase::reserved_total(const MallocMemory* malloc, const VirtualMemory* vm) {
>> 
>> Why the const removal?
>
> I turned `reserved_total(...)` and `committed_total(...)`into a static helpers since they did not use any members. That way my new reporter did not have to inherit `MemReporter`.

Ah okay, I was blind, sorry.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From sjohanss at openjdk.org  Fri Dec  2 08:13:15 2022
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Fri, 2 Dec 2022 08:13:15 GMT
Subject: RFR: 8157023: Integrate NMT with JFR
In-Reply-To: <mBWyCfeVG6ERYrKkYpc-ti5rLuRAGLfa3uZP2oAek3Y=.bc8edb10-3080-40f3-81b6-b5684efcf358@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <5etH99SkJXLDG9IeW1kNIjvCWU-Ydhbg5JBMZM34tFg=.7401c117-7dbb-4ea0-89e1-31bbe6f0d78b@github.com>
 <ZOYTp9BUze3EkwxKw23_gaSVw9YZcNpd3c_dgBsyVqo=.590510f7-9d96-4f3e-b565-8664db3d8f8d@github.com>
 <mBWyCfeVG6ERYrKkYpc-ti5rLuRAGLfa3uZP2oAek3Y=.bc8edb10-3080-40f3-81b6-b5684efcf358@github.com>
Message-ID: <VNscnr2a4_M96_HN1Nvf7693KAfi87DYdqjSQaTh5Jc=.5f8b87c3-ab46-4fc2-8449-9e562217229d@github.com>

On Fri, 2 Dec 2022 08:07:09 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> I turned `reserved_total(...)` and `committed_total(...)`into a static helpers since they did not use any members. That way my new reporter did not have to inherit `MemReporter`.
>
> Ah okay, I was blind, sorry.

No problem, I actually asked my self the same question when I did a quick browse of the code before publishing :)

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From sjohanss at openjdk.org  Fri Dec  2 08:21:10 2022
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Fri, 2 Dec 2022 08:21:10 GMT
Subject: RFR: 8157023: Integrate NMT with JFR
In-Reply-To: <5etH99SkJXLDG9IeW1kNIjvCWU-Ydhbg5JBMZM34tFg=.7401c117-7dbb-4ea0-89e1-31bbe6f0d78b@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <5etH99SkJXLDG9IeW1kNIjvCWU-Ydhbg5JBMZM34tFg=.7401c117-7dbb-4ea0-89e1-31bbe6f0d78b@github.com>
Message-ID: <RWFlFXHufGin7YU3mWKCCmxwqgFhVdeLvpFSFALJaVY=.a03a15a5-9521-45f1-8e25-6170c4144cc5@github.com>

On Thu, 1 Dec 2022 17:44:53 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Please review this enhancement to include NMT information in JFR recordings.
>> 
>> **Summary**
>> Native Memory Tracking summary information can be obtained from a running VM using `jcmd` if started with `-XX:NativeMemoryTracking=summary/detail`. Using `jcmd` requires you to run a separate process and to parse the output to get the needed information. This change adds JFR events for NMT information to enable additional ways to consume the NMT data.
>> 
>> There are two new events added:
>> * _NativeMemoryUsage_ - The total native memory usage.
>> * _NativeMemoryUsagePart_ - The native memory usage for each component.
>> 
>> These events are sent periodically and by default the interval is 1s. This can of course be discussed, but that is the staring point. When NMT is not enabled on events will be sent.
>> 
>> **Testing**
>> * Added a simple test to verify that the events are sent as expected depending on if NMT is enabled or not.
>> * Mach5 sanity testing
>
> src/hotspot/share/jfr/metadata/metadata.xml line 711:
> 
>> 709:   <Event name="NativeMemoryUsagePart" category="Java Virtual Machine, Memory" label="Component Native Memory Usage" description="Native memory usage for a component" stackTrace="false" thread="false"
>> 710:     startTime="false" period="everyChunk">
>> 711:     <Field type="string" name="type" label="Memory Type" description="Component allocating the native memory" />
> 
> Is there a better way than to re-transmit the category name with every event?

There is a way to create special JFR types and instead just send an ID. This might make sense to save some extra memory. @egahlin, is there any drawback with creating custom type? Apart from the parsing needing an extra step.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From sjohanss at openjdk.org  Fri Dec  2 08:34:17 2022
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Fri, 2 Dec 2022 08:34:17 GMT
Subject: RFR: 8157023: Integrate NMT with JFR
In-Reply-To: <5etH99SkJXLDG9IeW1kNIjvCWU-Ydhbg5JBMZM34tFg=.7401c117-7dbb-4ea0-89e1-31bbe6f0d78b@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <5etH99SkJXLDG9IeW1kNIjvCWU-Ydhbg5JBMZM34tFg=.7401c117-7dbb-4ea0-89e1-31bbe6f0d78b@github.com>
Message-ID: <U2axxkaIiFTRP7RusW1xjDGIdXFA3sQEOC1TGz6MsdU=.61d2d963-e112-48e2-9473-2fccb7756f42@github.com>

On Thu, 1 Dec 2022 17:45:25 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Please review this enhancement to include NMT information in JFR recordings.
>> 
>> **Summary**
>> Native Memory Tracking summary information can be obtained from a running VM using `jcmd` if started with `-XX:NativeMemoryTracking=summary/detail`. Using `jcmd` requires you to run a separate process and to parse the output to get the needed information. This change adds JFR events for NMT information to enable additional ways to consume the NMT data.
>> 
>> There are two new events added:
>> * _NativeMemoryUsage_ - The total native memory usage.
>> * _NativeMemoryUsagePart_ - The native memory usage for each component.
>> 
>> These events are sent periodically and by default the interval is 1s. This can of course be discussed, but that is the staring point. When NMT is not enabled on events will be sent.
>> 
>> **Testing**
>> * Added a simple test to verify that the events are sent as expected depending on if NMT is enabled or not.
>> * Mach5 sanity testing
>
> src/hotspot/share/services/memReporter.cpp line 25:
> 
>> 23:  */
>> 24: #include "precompiled.hpp"
>> 25: #include "jfr/jfrEvents.hpp"
> 
> I think this is an intermixing of layers. I think it would be cleaner if if JFR accessed the current values from outside, instead of JFR knowledge leaking into NMT.

Not sure I agree, I see the `MemReporter` as the reporting layer and it now knows about JFR to be able to report through it.

We have in other places created small helpers that send the events to avoid including `jfrEvents.hpp` all over the place, and we could to that here as well. But I don't see a problem with having the reporter residing along side the other reporters.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From kbarrett at openjdk.org  Fri Dec  2 08:45:11 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 2 Dec 2022 08:45:11 GMT
Subject: RFR: 8297912: Redo 8252584: HotSpot Style Guide should permit
 alignas with the proper approval
In-Reply-To: <Lyv_ypxMsA5tjqJ3d4KwScyySdBcTo34lL8abbF4SoQ=.44f3b51c-30b8-428e-b715-6af70bccaaf5@github.com>
References: <Lyv_ypxMsA5tjqJ3d4KwScyySdBcTo34lL8abbF4SoQ=.44f3b51c-30b8-428e-b715-6af70bccaaf5@github.com>
Message-ID: <JXa9XFQ4rOHKLmaiqyojQKLrpHXSgvYNyRtJFXQ-bs8=.e2682791-97bb-487d-bb39-dc200e479a6b@github.com>

On Thu, 1 Dec 2022 04:34:56 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> [8252584](https://bugs.openjdk.org/browse/JDK-8252584) was integrated too early due to a mistake on my part, we should redo it and go through the proper approval process this time
> 
> (The changes in this commit are exactly identical to 8252584)

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11446

From kbarrett at openjdk.org  Fri Dec  2 08:45:13 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 2 Dec 2022 08:45:13 GMT
Subject: RFR: 8297912: Redo 8252584: HotSpot Style Guide should permit
 alignas with the proper approval
In-Reply-To: <Sicv5R257TmnOgiAqUkEzRt1ZmYRVdiMH22bxib8xBk=.69b6d831-7479-4e4e-8135-9e862f2b157d@github.com>
References: <Lyv_ypxMsA5tjqJ3d4KwScyySdBcTo34lL8abbF4SoQ=.44f3b51c-30b8-428e-b715-6af70bccaaf5@github.com>
 <Sicv5R257TmnOgiAqUkEzRt1ZmYRVdiMH22bxib8xBk=.69b6d831-7479-4e4e-8135-9e862f2b157d@github.com>
Message-ID: <eCAeDe5ORoZK54IrQanGLeu5JBYPDiwNAedr_PffcrA=.c9aa40b0-3bef-4935-9770-dde2a7fd84ee@github.com>

On Thu, 1 Dec 2022 07:36:58 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> could you give this PR/JBS please a speaking name, e.g. "HotSpot Style Guide should permit alignas (second attempt)". Nobody remembers all JBS issue numbers :)

+1

> Also, @rose00 voiced concerns in the original PR ([#11315 (comment)](https://github.com/openjdk/jdk/pull/11315#issuecomment-1332982465)) which should be addressed first. I cautiously share his concerns for the moment.

I had somewhat similar concerns to @rose00 at one point. We have
`ATTRIBUTE_ALIGNED` for this sort of thing; is `alignas` actually better? I
think it is, though perhaps weakly. It's a bit shorter and less noisy (which
some might not consider a positive). It is in most respects equivalent to our
macro, and will work for other compilers (I think there are some) without
needing to specialize the macro.

The proposal seems like a lot of words, describing significant restrictions.
The thing is, very nearly all of those words apply to our `ATTRIBUTE_ALIGNED`
macro too, but aren't written down anywhere.

So I approve of this change, though I won't be heartbroken if it is rejected.
If it's rejected, I'll mine it for documentation comments for our macro.

-------------

PR: https://git.openjdk.org/jdk/pull/11446

From sjohanss at openjdk.org  Fri Dec  2 09:06:22 2022
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Fri, 2 Dec 2022 09:06:22 GMT
Subject: RFR: 8157023: Integrate NMT with JFR
In-Reply-To: <5etH99SkJXLDG9IeW1kNIjvCWU-Ydhbg5JBMZM34tFg=.7401c117-7dbb-4ea0-89e1-31bbe6f0d78b@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <5etH99SkJXLDG9IeW1kNIjvCWU-Ydhbg5JBMZM34tFg=.7401c117-7dbb-4ea0-89e1-31bbe6f0d78b@github.com>
Message-ID: <84OX5QvbH9Bnuw6pl9jhcsvUif87oOsyEqpqKvbl1LE=.4dd2660d-dd34-4a89-a1b4-768c089a7991@github.com>

On Thu, 1 Dec 2022 18:23:34 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Please review this enhancement to include NMT information in JFR recordings.
>> 
>> **Summary**
>> Native Memory Tracking summary information can be obtained from a running VM using `jcmd` if started with `-XX:NativeMemoryTracking=summary/detail`. Using `jcmd` requires you to run a separate process and to parse the output to get the needed information. This change adds JFR events for NMT information to enable additional ways to consume the NMT data.
>> 
>> There are two new events added:
>> * _NativeMemoryUsage_ - The total native memory usage.
>> * _NativeMemoryUsagePart_ - The native memory usage for each component.
>> 
>> These events are sent periodically and by default the interval is 1s. This can of course be discussed, but that is the staring point. When NMT is not enabled on events will be sent.
>> 
>> **Testing**
>> * Added a simple test to verify that the events are sent as expected depending on if NMT is enabled or not.
>> * Mach5 sanity testing
>
> src/hotspot/share/services/memReporter.cpp line 861:
> 
>> 859: 
>> 860:   MemBaseline usage;
>> 861:   usage.baseline(true);
> 
> Note that this is quite expensive. So it depends on how often we do this. How often are these samples taken?
> 
> Eg. Baseline.baseline does walk all thread stacks (so, probing all of them via mincore()). It also copies a lot of counters around. 
> 
> It is also not threadsafe. Are we at a safepoint here? Normally NMT reports are only done at safepoints.

Haven't looked at the details of `baseline(bool summaryOnly)` that much, but since it `summaryOnly = true` I don't think it actually walk the thread stacks, right? 

We don't do this at a safepoint but looking at `MallocMemorySnapshot::copy_to(...)` it uses `ThreadCritical` to avoid things being cleaned out at the same time. Not sure if there are other thread safety problems though. I would expect this to have the same problems as a summary report triggered through `jcmd` because that isn't run at a safepoint either. But I do see that when used from `jcmd` we take a lock to serialize the NMT query, so we should probably do the same here.

  // Query lock is used to synchronize the access to tracking data.
  // So far, it is only used by JCmd query, but it may be used by
  // other tools.
  static inline Mutex* query_lock() {
    assert(NMTQuery_lock != NULL, "not initialized!");
    return NMTQuery_lock;
  }

So we certainly need to look closer at this. I would like to understand why the query lock is needed.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From sjohanss at openjdk.org  Fri Dec  2 09:31:05 2022
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Fri, 2 Dec 2022 09:31:05 GMT
Subject: RFR: 8157023: Integrate NMT with JFR
In-Reply-To: <5etH99SkJXLDG9IeW1kNIjvCWU-Ydhbg5JBMZM34tFg=.7401c117-7dbb-4ea0-89e1-31bbe6f0d78b@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <5etH99SkJXLDG9IeW1kNIjvCWU-Ydhbg5JBMZM34tFg=.7401c117-7dbb-4ea0-89e1-31bbe6f0d78b@github.com>
Message-ID: <l5PaDcRr8Uxk2KXhvfKP1FTFbVD2QIosVOHqVuXaun0=.925a675b-f986-451c-a92c-694c2d98d9ed@github.com>

On Thu, 1 Dec 2022 18:41:33 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> The number of values may expand considerably in the future: we may want to use tags in a far more fine-granular manner than we do now, and/or change their encoding - eg to work in a hierarchy, or groups, or in combined an UL-like fashion. So their number may expand, and their meaning change, which could render this report obsolete quickly. E.g. if we add tag hierarchies, do we then only report leaf tags? How useful would that be? If we allow tag combinations, how would we report that?
> 

As you know I would love to see a better way to tag allocations than the current. It is hard to answer how we would handle it when it comes but the current event structure could already handle for example multiple tags. The `type` field could look like "gc,remset" leaving it to the parser to decide how to handle this data. Not saying this is perfect or the way to go, but I would not like to engineer the initial solution to fit a possible future improvement. That said, we should of course try to avoid making design decisions that will restrict us going forward. One way would be to let those new events be `experimental` at first.

> Also note that I currently work on a patch for showing NMT peak malloc values, see https://bugs.openjdk.org/browse/JDK-8297958. Peak values are very useful to have. So, do we expose them too? One more value per category. But leaving them out would render the JFR NMT report less useful.
> 

This is another good question, my first thought was to include more information. Like the split between malloced and "mapped", but after some discussions we landed in just the two current valued. I don't see a problem adding the peak value, but would it also require the "normal" malloc value to make sense?

> Bottomline, I am not yet convinced that reporting all NMT categories is that useful. And it exposes implementation details that may cause breakage in the future. We could restrict them to a subset of useful ones, and only report that.
> 

I'm not against this, for obvious reasons I care mostly about GC, and I could see a benefit in just reporting a few "subsets". The problem I see with this is that someone might be needing something other that what we defined. We can of course add more later on, but right now when it is just around 30 events I think sending all is ok.

> Another thought, for virtual memory mappings you report reserved and committed. But I doubt that "reserved" is really of much use. In itself, it does not cost anything, at least not on 64-bit. For a select few categories, it can signify the largest amount of committable memory (e.g. heap and code space) but those are already reported in JFR. So I think we could omit "reserved" and save a bunch of code and make the NMT JFR report less overwhelming.
> 

I see your point, and I agree that committed is the most interesting one. The way I use it is exactly as you describe, it is an easy way to determine the max and even if that information is available through other events it is quite nice to have it bundled together.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From sjohanss at openjdk.org  Fri Dec  2 09:46:07 2022
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Fri, 2 Dec 2022 09:46:07 GMT
Subject: RFR: 8157023: Integrate NMT with JFR
In-Reply-To: <_wo1SsKdFblP2OVLjTxDigQQ5rHsoNAFNTPqA0fNzBo=.67d68e5d-1720-4c0f-9f51-49ddf8fb4ebd@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <uvfe5r95h067-c6M1apWu0ySUjvRBOnzaG-Tv1sp6ao=.9c7f0dae-0e85-4029-a4cd-7452a4d5c302@github.com>
 <xgmkKNIgrAiBWoieuv2rjwhZKs3gHVsW-WdDGypK-5o=.bbdaa17a-65df-4b9f-a14c-cc320d18cfaa@github.com>
 <eYMaJWbLShtnb2j08gOfnhHXsDg9OswIxQI8rvBqkSQ=.84d846f6-09f4-4f95-a632-08b1c975323d@github.com>
 <_wo1SsKdFblP2OVLjTxDigQQ5rHsoNAFNTPqA0fNzBo=.67d68e5d-1720-4c0f-9f51-49ddf8fb4ebd@github.com>
Message-ID: <guH2ktWI_bjvLCb9S2Vv4nLgnWGjq-FbUk1a9k-Kegg=.39a7bb8e-7dc9-46bd-b03f-fb41ce940a79@github.com>

On Thu, 1 Dec 2022 16:59:20 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> I think we should design the events as if we could take everything in one snapshot. That way, we can improve the implementation later. It would be good to write in the event description of NativeMemoryUsage event that it may not add exactly up to the sum of NativeMemoryUsagePart events due to timing issues.
>> 
>> I will look into adding support for snapshots, but it will have to be a later release.
>
> Today, the call into JVM has the signature JVM::emitEvent(long eventTypeId, long timestamp, long when). If the timestamp is stored in jfr_periodic_timestamp when the call gets into native and the part event is emitted first, then it could look something like this:
> 
> 
> static u8 jfr_periodic_timestamp;
> 
> struct JfrNmtTotal {
>   u8 timestamp;
>   u8 reserved;
>   u8 committed;
> };
> 
> static JfrNmtTotal last_nmt;
> 
> TRACE_REQUEST_FUNC(NativeMemoryUsagePart) {
>    ...
>    last_nmt.timestamp = jfr_periodic_timestamp;
>    last_nmt.reserved = sum of reserved;
>    last_nmt.committed = sum of committed;
> }
> 
> TRACE_REQUEST_FUNC(NativeMemoryUsage) {
>    if (jfr_periodic_timestamp == last_nmt.timestamp) {
>        // use last_nmt
>    } else {
>       // calculate reserved and committed independently
>   }
> }
> 
> 
> Periodic events are run in the same thread.
> 
> I don't know if the order of periodic event is the same as in metadata.xml but it could be fixed. This will handle the case where the events have different periods.

I just realized there is another problem with trying to share the baseline, the events might be configured to have different periods and then sharing will be strange. So step one: document it.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From epeter at openjdk.org  Fri Dec  2 10:07:27 2022
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 2 Dec 2022 10:07:27 GMT
Subject: RFR: 8294540: Remove Opaque2Node: it is broken and triggers assert
Message-ID: <3j2Rhe5W9Os-yy1Stqlh-h69SIebbVz2_nsfigH5jfY=.fe3c7faa-da70-4064-9687-d791cdc97acf@github.com>

As @chhagedorn nicely analyzed, `Opaque2` nodes seem to be broken.
https://github.com/openjdk/jdk/pull/10306

**Original idea behing Opaque2**
The idea was to avoid loop-exit values to have both the un-incremented phi-value and the incremented one. Having both may mean using 2 registers, where 1 register could be enough if we only carry the incremented value, and simply decrement after the loop. Opaque2 was inserted to prevent optimizations that would optimize (Phi + inc - inc) down to (Phi). We had a pattern (Phi + inc -> Opaque2 -> - inc), so the add/sub do not get collapsed. Many years back, that used to be fine, and we would only remove Opaque2 nodes once no IGVN round was run anymore. But now, we take Opaque2 nodes out of the graph and then run IGVN again, which undoes all of the effort.

**Must remove for now, maybe implement properly later**
For now we remove it, because they can trigger asserts, and is simply a rotten optimization. We think that this optimization should probably be done at the very end anyway, after the last IGVN round.

Performance tests indicate that removing it now does not lead to slowdown.

**Analysis of the assert**

In `PhaseIdealLoop::do_unroll`, we check that the main loop has the same limit in the zero-trip-guard as in the loop-exit. For that, we find the `Opaque1` node `opaq` for the zero-trip-guard limit. We compare its input with the `limit` from the loop-exit. This assert is useful, if we change loop-limits we must ensure they are in sync.

https://github.com/openjdk/jdk/blob/8c472e481676ed0ef475c4989477d5714880c59e/src/hotspot/share/opto/loopTransform.cpp#L2227-L2228

Unfortunately, we insert two separate `Opaque2` nodes for the zero-trip-guard and loop-exit in this example.
Sequence of events:
- We have 2 loops
- The second loop is pre-main-post split. The main loop eventually takes the pre-incremented Phi value of the first loop as its loop-limit.
- The first loop eventually detects that its pre-incremented Phi value is used, and inserts Opaque2 nodes for every use. Unfortunately, the zero-trip-guard `CmpI` and the loop-exit `CmpI` both are direct uses of that pre-incremented Phi (this is very rare, as it seems, usually there are other operations in between, and then it is a single use, that eventually feeds into zero-trip-guard and loop-exit-check).

![image](https://user-images.githubusercontent.com/32593061/205263253-b5b811cc-504e-4072-9d10-1bc134964c9d.png)

-------------

Commit messages:
 - 8294540: Remove Opaque2Node: it is broken and triggers asserts

Changes: https://git.openjdk.org/jdk/pull/11477/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11477&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294540
  Stats: 185 lines in 11 files changed: 1 ins; 170 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/11477.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11477/head:pull/11477

PR: https://git.openjdk.org/jdk/pull/11477

From aph at openjdk.org  Fri Dec  2 10:19:33 2022
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 2 Dec 2022 10:19:33 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v6]
In-Reply-To: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
Message-ID: <BlgmU61ejhlUYvDFqS4vdeD-KZPN1Gs93wP91Y0YE74=.f95c84af-7e10-4426-99f6-985c19d36506@github.com>

> This patch fixes the remaining null pointer dereference bugs that I know of.
> 
> For the main bug, C2 was using a null reference to indicate an uninitialized `Node_List`. I replaced the null reference with a static sentinel.
> 
> I also turned on `-fsanitize=null` and found and fixed a bunch of other null pointer dereferences. With this,I have run a full bootstrap and tier1 tests with `-fsanitize=null` enabled.
> 
> I have checked that the code generated by GCC is not worse in any significant way, so I don't expect to see any performance regressions.
> 
> I'd like to enable `-fsanitize=null` in debug builds to prevent regressions in this area. What do you think?

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Feedback from reviewers

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10920/files
  - new: https://git.openjdk.org/jdk/pull/10920/files/26347b70..063f70c3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10920&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10920&range=04-05

  Stats: 3 lines in 1 file changed: 1 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10920.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10920/head:pull/10920

PR: https://git.openjdk.org/jdk/pull/10920

From aph at openjdk.org  Fri Dec  2 10:19:34 2022
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 2 Dec 2022 10:19:34 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v6]
In-Reply-To: <fI8eRD9gFvdHD63yNqJKA13ekCxfgRD-vvOICsoSzHU=.fffe4565-dd3a-4727-86dc-52468c239b89@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
 <6lfTT_Djcw8AsOUW09Kh5BSqxFhveF5ASItS8O_E3C8=.25a1cf8e-73b3-40f0-a531-1cc34264807a@github.com>
 <8p5DnhjjOlFQ6Tu_DEfJsvW7ac-MgQ8vP3_LSvocgGg=.16e04fa6-d7cc-4cc9-ade6-0fd8f83b4df4@github.com>
 <xLM1FBSq5Msh4g_5VDjX8UcAH1jreAOrsMedC1pZO-U=.33e7b791-4ea4-4794-9f90-496c2854c2d3@github.com>
 <0saIh82rf2159AEVVl3pepMP9vGrPgQrIZDoyiKIz8A=.f909ddac-7fc3-451c-9a9d-0f4a38fdc2f2@github.com>
 <fI8eRD9gFvdHD63yNqJKA13ekCxfgRD-vvOICsoSzHU=.fffe4565-dd3a-4727-86dc-52468c239b89@github.com>
Message-ID: <3DnZiRF0m23T6-qY8XymIVO-d_Hn4AEKO-qeZfv47fI=.11ed313f-df15-4187-bf8d-1bf9880477d0@github.com>

On Thu, 1 Dec 2022 17:59:45 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>>> Please, initialize `_caller_jvms` to `NULL` (on line 47), switch the null check to `caller_jvms` (on line 60), a
>> 
>> Done.
>
> I'm talking specifically about the assert you are adjusting:
> 
> assert(_caller_jvms->same_calls_as(caller_jvms), "consistent JVMS");
> 
> It can be left as is once it is under `caller_jvms != NULL`, since there's no need in `_caller_jvms == NULL` anymore.

Got it, done. Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/10920

From stuefe at openjdk.org  Fri Dec  2 10:33:21 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 2 Dec 2022 10:33:21 GMT
Subject: RFR: 8157023: Integrate NMT with JFR
In-Reply-To: <l5PaDcRr8Uxk2KXhvfKP1FTFbVD2QIosVOHqVuXaun0=.925a675b-f986-451c-a92c-694c2d98d9ed@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <5etH99SkJXLDG9IeW1kNIjvCWU-Ydhbg5JBMZM34tFg=.7401c117-7dbb-4ea0-89e1-31bbe6f0d78b@github.com>
 <l5PaDcRr8Uxk2KXhvfKP1FTFbVD2QIosVOHqVuXaun0=.925a675b-f986-451c-a92c-694c2d98d9ed@github.com>
Message-ID: <IBlRVDETFl0xpVvcUKPF0Spko2Wgm7ScqRlg0OgmNT4=.a1c25637-1940-432e-a834-0e8c83272be2@github.com>

On Fri, 2 Dec 2022 09:28:27 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> > The number of values may expand considerably in the future: we may want to use tags in a far more fine-granular manner than we do now, and/or change their encoding - eg to work in a hierarchy, or groups, or in combined an UL-like fashion. So their number may expand, and their meaning change, which could render this report obsolete quickly. E.g. if we add tag hierarchies, do we then only report leaf tags? How useful would that be? If we allow tag combinations, how would we report that?
> 
> As you know I would love to see a better way to tag allocations than the current. It is hard to answer how we would handle it when it comes but the current event structure could already handle for example multiple tags. The `type` field could look like "gc,remset" leaving it to the parser to decide how to handle this data. Not saying this is perfect or the way to go, but I would not like to engineer the initial solution to fit a possible future improvement. That said, we should of course try to avoid making design decisions that will restrict us going forward. One way would be to let those new events be `experimental` at first.
> 
> > Also note that I currently work on a patch for showing NMT peak malloc values, see https://bugs.openjdk.org/browse/JDK-8297958. Peak values are very useful to have. So, do we expose them too? One more value per category. But leaving them out would render the JFR NMT report less useful.
> 
> This is another good question, my first thought was to include more information. Like the split between malloced and "mapped", but after some discussions we landed in just the two current valued. I don't see a problem adding the peak value, but would it also require the "normal" malloc value to make sense?
> 
> > Bottomline, I am not yet convinced that reporting all NMT categories is that useful. And it exposes implementation details that may cause breakage in the future. We could restrict them to a subset of useful ones, and only report that.
> 
> I'm not against this, for obvious reasons I care mostly about GC, and I could see a benefit in just reporting a few "subsets". The problem I see with this is that someone might be needing something other that what we defined. We can of course add more later on, but right now when it is just around 30 events I think sending all is ok.
> 
> > Another thought, for virtual memory mappings you report reserved and committed. But I doubt that "reserved" is really of much use. In itself, it does not cost anything, at least not on 64-bit. For a select few categories, it can signify the largest amount of committable memory (e.g. heap and code space) but those are already reported in JFR. So I think we could omit "reserved" and save a bunch of code and make the NMT JFR report less overwhelming.
> 
> I see your point, and I agree that committed is the most interesting one. The way I use it is exactly as you describe, it is an easy way to determine the max and even if that information is available through other events it is quite nice to have it bundled together.

Okay, you are convincing me :) you pre-selected a range of values to transmit, and that selection is necessarily biased and arbitrary, and others may find other selections valuable. But since its a matter of taste anyway, lets go with printing all tags as they are now. If we ever rebuild the tag system we'll think of something. I think omitting malloc vs mmap and malloc count is okay, and you are right, malloc peak makes sense only if we report malloc.

I still would argue for leaving out reserved, but won't press the point. If you and other reviewers think its useful, lets report it.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From sjohanss at openjdk.org  Fri Dec  2 10:33:21 2022
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Fri, 2 Dec 2022 10:33:21 GMT
Subject: RFR: 8157023: Integrate NMT with JFR
In-Reply-To: <84OX5QvbH9Bnuw6pl9jhcsvUif87oOsyEqpqKvbl1LE=.4dd2660d-dd34-4a89-a1b4-768c089a7991@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <5etH99SkJXLDG9IeW1kNIjvCWU-Ydhbg5JBMZM34tFg=.7401c117-7dbb-4ea0-89e1-31bbe6f0d78b@github.com>
 <84OX5QvbH9Bnuw6pl9jhcsvUif87oOsyEqpqKvbl1LE=.4dd2660d-dd34-4a89-a1b4-768c089a7991@github.com>
Message-ID: <lKhT7B2g2KL3rJ551N_D0D_sBdstIdUCAD5230diRj8=.5fbf36c9-e983-4b8c-a080-84fed14b6882@github.com>

On Fri, 2 Dec 2022 09:03:50 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> src/hotspot/share/services/memReporter.cpp line 861:
>> 
>>> 859: 
>>> 860:   MemBaseline usage;
>>> 861:   usage.baseline(true);
>> 
>> Note that this is quite expensive. So it depends on how often we do this. How often are these samples taken?
>> 
>> Eg. Baseline.baseline does walk all thread stacks (so, probing all of them via mincore()). It also copies a lot of counters around. 
>> 
>> It is also not threadsafe. Are we at a safepoint here? Normally NMT reports are only done at safepoints.
>
> Haven't looked at the details of `baseline(bool summaryOnly)` that much, but since it `summaryOnly = true` I don't think it actually walk the thread stacks, right? 
> 
> We don't do this at a safepoint but looking at `MallocMemorySnapshot::copy_to(...)` it uses `ThreadCritical` to avoid things being cleaned out at the same time. Not sure if there are other thread safety problems though. I would expect this to have the same problems as a summary report triggered through `jcmd` because that isn't run at a safepoint either. But I do see that when used from `jcmd` we take a lock to serialize the NMT query, so we should probably do the same here.
> 
>   // Query lock is used to synchronize the access to tracking data.
>   // So far, it is only used by JCmd query, but it may be used by
>   // other tools.
>   static inline Mutex* query_lock() {
>     assert(NMTQuery_lock != NULL, "not initialized!");
>     return NMTQuery_lock;
>   }
> 
> So we certainly need to look closer at this. I would like to understand why the query lock is needed.

Looking a bit more at this. To me it seems like we are protecting the stored baseline with the lock is:

class MemTracker : AllStatic {
...
  // Stored baseline
  static MemBaseline      _baseline;
...
};

That the `NMTDCmd` code uses through `MemTracker::get_baseline()`. So if the JFR events keep its own baseline we should be fine without the lock. Or am I missing something here?

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From egahlin at openjdk.org  Fri Dec  2 10:47:21 2022
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 2 Dec 2022 10:47:21 GMT
Subject: RFR: 8157023: Integrate NMT with JFR
In-Reply-To: <RWFlFXHufGin7YU3mWKCCmxwqgFhVdeLvpFSFALJaVY=.a03a15a5-9521-45f1-8e25-6170c4144cc5@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <5etH99SkJXLDG9IeW1kNIjvCWU-Ydhbg5JBMZM34tFg=.7401c117-7dbb-4ea0-89e1-31bbe6f0d78b@github.com>
 <RWFlFXHufGin7YU3mWKCCmxwqgFhVdeLvpFSFALJaVY=.a03a15a5-9521-45f1-8e25-6170c4144cc5@github.com>
Message-ID: <D_6GX-76My3kJzNfX3Xec_wFBs6Mr9oaMT5L5Nmqonk=.087710f5-304b-40a2-8545-e231f8674a6c@github.com>

On Fri, 2 Dec 2022 08:17:17 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> src/hotspot/share/jfr/metadata/metadata.xml line 711:
>> 
>>> 709:   <Event name="NativeMemoryUsagePart" category="Java Virtual Machine, Memory" label="Component Native Memory Usage" description="Native memory usage for a component" stackTrace="false" thread="false"
>>> 710:     startTime="false" period="everyChunk">
>>> 711:     <Field type="string" name="type" label="Memory Type" description="Component allocating the native memory" />
>> 
>> Is there a better way than to re-transmit the category name with every event?
>
> There is a way to create special JFR types and instead just send an ID. This might make sense to save some extra memory. @egahlin, is there any drawback with creating custom type? Apart from the parsing needing an extra step.

Not really. See for https://github.com/openjdk/jdk/blob/master/src/hotspot/share/jfr/metadata/jfrSerializer.hpp for how to serialize constants. Since the number of events are few and they are opt-in using a command line flag, I don't think it will make much of a difference from a performance perspective, but I don't think it will hurt either.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From stuefe at openjdk.org  Fri Dec  2 10:47:22 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 2 Dec 2022 10:47:22 GMT
Subject: RFR: 8157023: Integrate NMT with JFR
In-Reply-To: <lKhT7B2g2KL3rJ551N_D0D_sBdstIdUCAD5230diRj8=.5fbf36c9-e983-4b8c-a080-84fed14b6882@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <5etH99SkJXLDG9IeW1kNIjvCWU-Ydhbg5JBMZM34tFg=.7401c117-7dbb-4ea0-89e1-31bbe6f0d78b@github.com>
 <84OX5QvbH9Bnuw6pl9jhcsvUif87oOsyEqpqKvbl1LE=.4dd2660d-dd34-4a89-a1b4-768c089a7991@github.com>
 <lKhT7B2g2KL3rJ551N_D0D_sBdstIdUCAD5230diRj8=.5fbf36c9-e983-4b8c-a080-84fed14b6882@github.com>
Message-ID: <E6M6A0ycYcHCVsjhk0gCw8w5nSz3_m1lAGvArfC2h08=.a7091058-f44a-4f6c-9b64-a92d7e3e088e@github.com>

On Fri, 2 Dec 2022 10:27:16 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Haven't looked at the details of `baseline(bool summaryOnly)` that much, but since it `summaryOnly = true` I don't think it actually walk the thread stacks, right? 
>> 
>> We don't do this at a safepoint but looking at `MallocMemorySnapshot::copy_to(...)` it uses `ThreadCritical` to avoid things being cleaned out at the same time. Not sure if there are other thread safety problems though. I would expect this to have the same problems as a summary report triggered through `jcmd` because that isn't run at a safepoint either. But I do see that when used from `jcmd` we take a lock to serialize the NMT query, so we should probably do the same here.
>> 
>>   // Query lock is used to synchronize the access to tracking data.
>>   // So far, it is only used by JCmd query, but it may be used by
>>   // other tools.
>>   static inline Mutex* query_lock() {
>>     assert(NMTQuery_lock != NULL, "not initialized!");
>>     return NMTQuery_lock;
>>   }
>> 
>> So we certainly need to look closer at this. I would like to understand why the query lock is needed.
>
> Looking a bit more at this. To me it seems like we are protecting the stored baseline with the lock is:
> 
> class MemTracker : AllStatic {
> ...
>   // Stored baseline
>   static MemBaseline      _baseline;
> ...
> };
> 
> That the `NMTDCmd` code uses through `MemTracker::get_baseline()`. So if the JFR events keep its own baseline we should be fine without the lock. Or am I missing something here?

Hi @kstefanj ,

> Haven't looked at the details of `baseline(bool summaryOnly)` that much, but since it `summaryOnly = true` I don't think it actually walk the thread stacks, right?

I think we do, since summary info contains information about committed thread stack size. I think the call chain is 


MemBaseline::baseline()->
MemBaseline::baseline_summary()->
VirtualMemorySummary::snapshot()->
VirtualMemoryTracker::snapshot_thread_stacks()->
VirtualMemoryTracker::walk_virtual_memory()->
SnapshotThreadStackWalker::do_allocation_site()->
RegionIterator::next_committed()->
os::committed_in_range()->
mincore loop


> 
> We don't do this at a safepoint but looking at `MallocMemorySnapshot::copy_to(...)` it uses `ThreadCritical` to avoid things being cleaned out at the same time. Not sure if there are other thread safety problems though. I would expect this to have the same problems as a summary report triggered through `jcmd` because that isn't run at a safepoint either.

You are right, I could have sworn we do this with a VM op. Must have confused this with metaspace printing.

> But I do see that when used from `jcmd` we take a lock to serialize the NMT query, so we should probably do the same here.
> 
> ```
>   // Query lock is used to synchronize the access to tracking data.
>   // So far, it is only used by JCmd query, but it may be used by
>   // other tools.
>   static inline Mutex* query_lock() {
>     assert(NMTQuery_lock != NULL, "not initialized!");
>     return NMTQuery_lock;
>   }
> ```
> 
> So we certainly need to look closer at this. I would like to understand why the query lock is needed.

To serialize jcmds running in parallel. Since jcmd is done by the attach listener thread, the only way I can think of would be if someone in parallel executes the command via mbean? Not sure.

Note that there is no way to get consistent counter values across all categories anyway. All the counters are updated atomically without lock, and that is all we can afford in malloc. Counters are not synchronized among themselves.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From shade at openjdk.org  Fri Dec  2 10:54:03 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 2 Dec 2022 10:54:03 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v6]
In-Reply-To: <BlgmU61ejhlUYvDFqS4vdeD-KZPN1Gs93wP91Y0YE74=.f95c84af-7e10-4426-99f6-985c19d36506@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
 <BlgmU61ejhlUYvDFqS4vdeD-KZPN1Gs93wP91Y0YE74=.f95c84af-7e10-4426-99f6-985c19d36506@github.com>
Message-ID: <-Gx_fsiwHvInS5q3bAOQAxpaUgj0Qsn015pthmrE5jI=.2adeff80-dfd1-427a-b4a1-a54453dce4aa@github.com>

On Fri, 2 Dec 2022 10:19:33 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This patch fixes the remaining null pointer dereference bugs that I know of.
>> 
>> For the main bug, C2 was using a null reference to indicate an uninitialized `Node_List`. I replaced the null reference with a static sentinel.
>> 
>> I also turned on `-fsanitize=null` and found and fixed a bunch of other null pointer dereferences. With this,I have run a full bootstrap and tier1 tests with `-fsanitize=null` enabled.
>> 
>> I have checked that the code generated by GCC is not worse in any significant way, so I don't expect to see any performance regressions.
>> 
>> I'd like to enable `-fsanitize=null` in debug builds to prevent regressions in this area. What do you think?
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback from reviewers

src/hotspot/share/opto/postaloc.cpp line 259:

> 257:   if (!can_change_regs) {
> 258:     return blk_adjust;          // Only check stupid copies!
> 259:   }

Style nit here and in other places: weren't these blocks separated by newline before?

src/hotspot/share/utilities/globalDefinitions_gcc.hpp line 155:

> 153:   char* c = (char*)(void*)&dummyObj->field;     \
> 154:   return (size_t)(c - space);                   \
> 155: }()

I am very surprised this does not produce any warnings! Let me test this on different GCCs...

-------------

PR: https://git.openjdk.org/jdk/pull/10920

From egahlin at openjdk.org  Fri Dec  2 10:55:16 2022
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 2 Dec 2022 10:55:16 GMT
Subject: RFR: 8157023: Integrate NMT with JFR
In-Reply-To: <IBlRVDETFl0xpVvcUKPF0Spko2Wgm7ScqRlg0OgmNT4=.a1c25637-1940-432e-a834-0e8c83272be2@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <5etH99SkJXLDG9IeW1kNIjvCWU-Ydhbg5JBMZM34tFg=.7401c117-7dbb-4ea0-89e1-31bbe6f0d78b@github.com>
 <l5PaDcRr8Uxk2KXhvfKP1FTFbVD2QIosVOHqVuXaun0=.925a675b-f986-451c-a92c-694c2d98d9ed@github.com>
 <IBlRVDETFl0xpVvcUKPF0Spko2Wgm7ScqRlg0OgmNT4=.a1c25637-1940-432e-a834-0e8c83272be2@github.com>
Message-ID: <WkUY7sW-crChZ60T5dl_ZOFkSwKXGJ7Xzjs4oW8USA8=.05fedd85-edd4-4a85-bc74-010d27e90c16@github.com>

On Fri, 2 Dec 2022 10:28:28 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> I still would argue for leaving out reserved, but won't press the point. If you and other reviewers think its useful, lets report it.

If we feel the events or some fields are not mature, we could mark them experimental. For the events to be emitted, users will need to pass a command line flag, so I think 99% of all users will never enable them. I think these events will be mostly useful for Hotspot developers and support engineers.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From aph at openjdk.org  Fri Dec  2 11:05:12 2022
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 2 Dec 2022 11:05:12 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v6]
In-Reply-To: <-Gx_fsiwHvInS5q3bAOQAxpaUgj0Qsn015pthmrE5jI=.2adeff80-dfd1-427a-b4a1-a54453dce4aa@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
 <BlgmU61ejhlUYvDFqS4vdeD-KZPN1Gs93wP91Y0YE74=.f95c84af-7e10-4426-99f6-985c19d36506@github.com>
 <-Gx_fsiwHvInS5q3bAOQAxpaUgj0Qsn015pthmrE5jI=.2adeff80-dfd1-427a-b4a1-a54453dce4aa@github.com>
Message-ID: <qO8PccVbO_Ro4teqV3uFITYZK7aLxInsCltFgLDpAQ4=.6b04d82d-c68d-4334-beb4-2e05b98435a7@github.com>

On Fri, 2 Dec 2022 10:44:42 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Feedback from reviewers
>
> src/hotspot/share/opto/postaloc.cpp line 259:
> 
>> 257:   if (!can_change_regs) {
>> 258:     return blk_adjust;          // Only check stupid copies!
>> 259:   }
> 
> Style nit here and in other places: weren't these blocks separated by newline before?

I'm not sure what you mean. Can you make these Suggestions? Thanks.

> src/hotspot/share/utilities/globalDefinitions_gcc.hpp line 155:
> 
>> 153:   char* c = (char*)(void*)&dummyObj->field;     \
>> 154:   return (size_t)(c - space);                   \
>> 155: }()
> 
> I am very surprised this does not produce any warnings! Let me test this on different GCCs...

Of course we can't exclude the possibility of warnings, given that taking the offset of a field of a non-POD class is unspecified behaviour. Having said that, I'm not sure exactly what it'd be warning about.

-------------

PR: https://git.openjdk.org/jdk/pull/10920

From aph at openjdk.org  Fri Dec  2 11:05:13 2022
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 2 Dec 2022 11:05:13 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v6]
In-Reply-To: <qO8PccVbO_Ro4teqV3uFITYZK7aLxInsCltFgLDpAQ4=.6b04d82d-c68d-4334-beb4-2e05b98435a7@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
 <BlgmU61ejhlUYvDFqS4vdeD-KZPN1Gs93wP91Y0YE74=.f95c84af-7e10-4426-99f6-985c19d36506@github.com>
 <-Gx_fsiwHvInS5q3bAOQAxpaUgj0Qsn015pthmrE5jI=.2adeff80-dfd1-427a-b4a1-a54453dce4aa@github.com>
 <qO8PccVbO_Ro4teqV3uFITYZK7aLxInsCltFgLDpAQ4=.6b04d82d-c68d-4334-beb4-2e05b98435a7@github.com>
Message-ID: <b4o3tjV_EOG3mUrQYZ5MIeQ-ToFJHdVrBAfMzIWVWz4=.ce32ee96-2a3f-4960-9ef2-0ef56163768f@github.com>

On Fri, 2 Dec 2022 11:00:54 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> src/hotspot/share/utilities/globalDefinitions_gcc.hpp line 155:
>> 
>>> 153:   char* c = (char*)(void*)&dummyObj->field;     \
>>> 154:   return (size_t)(c - space);                   \
>>> 155: }()
>> 
>> I am very surprised this does not produce any warnings! Let me test this on different GCCs...
>
> Of course we can't exclude the possibility of warnings, given that taking the offset of a field of a non-POD class is unspecified behaviour. Having said that, I'm not sure exactly what it'd be warning about.

This restriction in C++ is unnecessary, really, since AFAIK this works on all implementations.

-------------

PR: https://git.openjdk.org/jdk/pull/10920

From sjohanss at openjdk.org  Fri Dec  2 11:54:07 2022
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Fri, 2 Dec 2022 11:54:07 GMT
Subject: RFR: 8157023: Integrate NMT with JFR
In-Reply-To: <E6M6A0ycYcHCVsjhk0gCw8w5nSz3_m1lAGvArfC2h08=.a7091058-f44a-4f6c-9b64-a92d7e3e088e@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <5etH99SkJXLDG9IeW1kNIjvCWU-Ydhbg5JBMZM34tFg=.7401c117-7dbb-4ea0-89e1-31bbe6f0d78b@github.com>
 <84OX5QvbH9Bnuw6pl9jhcsvUif87oOsyEqpqKvbl1LE=.4dd2660d-dd34-4a89-a1b4-768c089a7991@github.com>
 <lKhT7B2g2KL3rJ551N_D0D_sBdstIdUCAD5230diRj8=.5fbf36c9-e983-4b8c-a080-84fed14b6882@github.com>
 <E6M6A0ycYcHCVsjhk0gCw8w5nSz3_m1lAGvArfC2h08=.a7091058-f44a-4f6c-9b64-a92d7e3e088e@github.com>
Message-ID: <pg5eXOt5ALakpMZH8ZhCjkaPb7cMjZDrY--xCgQ5QIQ=.baa270b4-a53e-44f8-ae57-2491f606e27b@github.com>

On Fri, 2 Dec 2022 10:42:56 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> I think we do, since summary info contains information about committed thread stack size. 

You are totally correct, somehow missed that part of `VirtualMemorySummary::snapshot()`. So yes, we should really look at only doing one snapshot per period. Any feeling for exactly how expensive this walk is?

> To serialize jcmds running in parallel. Since jcmd is done by the attach listener thread, the only way I can think of would be if someone in parallel executes the command via mbean? Not sure.

Ok, so if executed via the mbean it would be executed in another thread but still use `DCMD::execute()` and the lock to make sure those are synchronized. Anyhow, do you agree with my above understanding that what is protected by the lock is the "cached baseline"? So as long as JFR doesn't use it, the lock should not be needed?

> Note that there is no way to get consistent counter values across all categories anyway. All the counters are updated atomically without lock, and that is all we can afford in malloc. Counters are not synchronized among themselves.

Agreed, this is a snapshot at a given point of a moving target.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From chagedorn at openjdk.org  Fri Dec  2 12:54:13 2022
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Fri, 2 Dec 2022 12:54:13 GMT
Subject: RFR: 8294540: Remove Opaque2Node: it is broken and triggers assert
In-Reply-To: <3j2Rhe5W9Os-yy1Stqlh-h69SIebbVz2_nsfigH5jfY=.fe3c7faa-da70-4064-9687-d791cdc97acf@github.com>
References: <3j2Rhe5W9Os-yy1Stqlh-h69SIebbVz2_nsfigH5jfY=.fe3c7faa-da70-4064-9687-d791cdc97acf@github.com>
Message-ID: <dVMk5g1JMsxXIGe-1WYehfCzxbGUrqiCOJRKLCzzGsw=.bc61ee84-c518-4139-b298-aae4cfe117f5@github.com>

On Fri, 2 Dec 2022 09:58:22 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> As @chhagedorn nicely analyzed, `Opaque2` nodes seem to be broken.
> https://github.com/openjdk/jdk/pull/10306
> 
> **Original idea behing Opaque2**
> The idea was to avoid loop-exit values to have both the un-incremented phi-value and the incremented one. Having both may mean using 2 registers, where 1 register could be enough if we only carry the incremented value, and simply decrement after the loop. Opaque2 was inserted to prevent optimizations that would optimize (Phi + inc - inc) down to (Phi). We had a pattern (Phi + inc -> Opaque2 -> - inc), so the add/sub do not get collapsed. Many years back, that used to be fine, and we would only remove Opaque2 nodes once no IGVN round was run anymore. But now, we take Opaque2 nodes out of the graph and then run IGVN again, which undoes all of the effort.
> 
> **Must remove for now, maybe implement properly later**
> For now we remove it, because they can trigger asserts, and is simply a rotten optimization. We think that this optimization should probably be done at the very end anyway, after the last IGVN round.
> 
> Performance tests indicate that removing it now does not lead to slowdown.
> 
> **Analysis of the assert**
> 
> In `PhaseIdealLoop::do_unroll`, we check that the main loop has the same limit in the zero-trip-guard as in the loop-exit. For that, we find the `Opaque1` node `opaq` for the zero-trip-guard limit. We compare its input with the `limit` from the loop-exit. This assert is useful, if we change loop-limits we must ensure they are in sync.
> 
> https://github.com/openjdk/jdk/blob/8c472e481676ed0ef475c4989477d5714880c59e/src/hotspot/share/opto/loopTransform.cpp#L2227-L2228
> 
> Unfortunately, we insert two separate `Opaque2` nodes for the zero-trip-guard and loop-exit in this example.
> Sequence of events:
> - We have 2 loops
> - The second loop is pre-main-post split. The main loop eventually takes the pre-incremented Phi value of the first loop as its loop-limit.
> - The first loop eventually detects that its pre-incremented Phi value is used, and inserts Opaque2 nodes for every use. Unfortunately, the zero-trip-guard `CmpI` and the loop-exit `CmpI` both are direct uses of that pre-incremented Phi (this is very rare, as it seems, usually there are other operations in between, and then it is a single use, that eventually feeds into zero-trip-guard and loop-exit-check).
> 
> ![image](https://user-images.githubusercontent.com/32593061/205263253-b5b811cc-504e-4072-9d10-1bc134964c9d.png)

Nice summary! I agree with this solution. A workaround for the assert seems to be complicated given that `Opaque2` nodes actually do not really fulfill their original purpose anymore as you've stated and also discussed in https://github.com/openjdk/jdk/pull/10306.

> Must remove for now, maybe implement properly later

Right, we could still come back to this optimization and implement it properly if it turns out to be beneficial.

src/hotspot/share/opto/loopTransform.cpp line 2292:

> 2290:       if (loop_head->unrolled_count() == 1) { // only for first unroll
> 2291:         assert(has_ctrl(opaq), "should have it");
> 2292:       }

Could directly be simplified into `assert(loop_head->unrolled_count() != 1 || has_ctrl(opaq), "should have opaque")`.

src/hotspot/share/opto/opaquenode.hpp line 79:

> 77:   int _opt; // what optimization it was used for
> 78:   virtual uint hash() const;
> 79:   virtual bool cmp(const Node &n ) const;

Suggestion:

  virtual bool cmp(const Node &n) const;

src/hotspot/share/opto/opaquenode.hpp line 81:

> 79: // temp register and an extra move).  If we "accidentally" optimize through
> 80: // this kind of a Node, we'll get slightly pessimal, but correct, code.  Thus
> 81: // it's OK to be slightly sloppy on optimizations here.

Not sure if we should also add this comment again to the `Opaque3` nodes as it suggests that it is okay to be sloppy with `Opaque3` as well (but then on the other hand, what exactly is the definition of being sloppy in the context of `Opaque3` nodes? So, it might be more confusing than actually helping).

-------------

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11477

From epeter at openjdk.org  Fri Dec  2 13:20:20 2022
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 2 Dec 2022 13:20:20 GMT
Subject: RFR: 8294540: Remove Opaque2Node: it is broken and triggers assert
In-Reply-To: <dVMk5g1JMsxXIGe-1WYehfCzxbGUrqiCOJRKLCzzGsw=.bc61ee84-c518-4139-b298-aae4cfe117f5@github.com>
References: <3j2Rhe5W9Os-yy1Stqlh-h69SIebbVz2_nsfigH5jfY=.fe3c7faa-da70-4064-9687-d791cdc97acf@github.com>
 <dVMk5g1JMsxXIGe-1WYehfCzxbGUrqiCOJRKLCzzGsw=.bc61ee84-c518-4139-b298-aae4cfe117f5@github.com>
Message-ID: <LRvtc47z2t0nDfIP9NwDz7CRuChnXsR11W1LMZ67Qco=.9dc54efe-cc41-4dc4-8500-08690810b607@github.com>

On Fri, 2 Dec 2022 12:37:42 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> As @chhagedorn nicely analyzed, `Opaque2` nodes seem to be broken.
>> https://github.com/openjdk/jdk/pull/10306
>> 
>> **Original idea behing Opaque2**
>> The idea was to avoid loop-exit values to have both the un-incremented phi-value and the incremented one. Having both may mean using 2 registers, where 1 register could be enough if we only carry the incremented value, and simply decrement after the loop. Opaque2 was inserted to prevent optimizations that would optimize (Phi + inc - inc) down to (Phi). We had a pattern (Phi + inc -> Opaque2 -> - inc), so the add/sub do not get collapsed. Many years back, that used to be fine, and we would only remove Opaque2 nodes once no IGVN round was run anymore. But now, we take Opaque2 nodes out of the graph and then run IGVN again, which undoes all of the effort.
>> 
>> **Must remove for now, maybe implement properly later**
>> For now we remove it, because they can trigger asserts, and is simply a rotten optimization. We think that this optimization should probably be done at the very end anyway, after the last IGVN round.
>> 
>> Performance tests indicate that removing it now does not lead to slowdown.
>> 
>> **Analysis of the assert**
>> 
>> In `PhaseIdealLoop::do_unroll`, we check that the main loop has the same limit in the zero-trip-guard as in the loop-exit. For that, we find the `Opaque1` node `opaq` for the zero-trip-guard limit. We compare its input with the `limit` from the loop-exit. This assert is useful, if we change loop-limits we must ensure they are in sync.
>> 
>> https://github.com/openjdk/jdk/blob/8c472e481676ed0ef475c4989477d5714880c59e/src/hotspot/share/opto/loopTransform.cpp#L2227-L2228
>> 
>> Unfortunately, we insert two separate `Opaque2` nodes for the zero-trip-guard and loop-exit in this example.
>> Sequence of events:
>> - We have 2 loops
>> - The second loop is pre-main-post split. The main loop eventually takes the pre-incremented Phi value of the first loop as its loop-limit.
>> - The first loop eventually detects that its pre-incremented Phi value is used, and inserts Opaque2 nodes for every use. Unfortunately, the zero-trip-guard `CmpI` and the loop-exit `CmpI` both are direct uses of that pre-incremented Phi (this is very rare, as it seems, usually there are other operations in between, and then it is a single use, that eventually feeds into zero-trip-guard and loop-exit-check).
>> 
>> ![image](https://user-images.githubusercontent.com/32593061/205263253-b5b811cc-504e-4072-9d10-1bc134964c9d.png)
>
> src/hotspot/share/opto/loopTransform.cpp line 2292:
> 
>> 2290:       if (loop_head->unrolled_count() == 1) { // only for first unroll
>> 2291:         assert(has_ctrl(opaq), "should have it");
>> 2292:       }
> 
> Could directly be simplified into `assert(loop_head->unrolled_count() != 1 || has_ctrl(opaq), "should have opaque")`.

will do that ?

> src/hotspot/share/opto/opaquenode.hpp line 79:
> 
>> 77:   int _opt; // what optimization it was used for
>> 78:   virtual uint hash() const;
>> 79:   virtual bool cmp(const Node &n ) const;
> 
> Suggestion:
> 
>   virtual bool cmp(const Node &n) const;

will do that ?

> src/hotspot/share/opto/opaquenode.hpp line 81:
> 
>> 79: // temp register and an extra move).  If we "accidentally" optimize through
>> 80: // this kind of a Node, we'll get slightly pessimal, but correct, code.  Thus
>> 81: // it's OK to be slightly sloppy on optimizations here.
> 
> Not sure if we should also add this comment again to the `Opaque3` nodes as it suggests that it is okay to be sloppy with `Opaque3` as well (but then on the other hand, what exactly is the definition of being sloppy in the context of `Opaque3` nodes? So, it might be more confusing than actually helping).

I would leave it out, unless if we are sure that it really applies to `Opaque3` Nodes.

-------------

PR: https://git.openjdk.org/jdk/pull/11477

From jwaters at openjdk.org  Fri Dec  2 13:21:06 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 2 Dec 2022 13:21:06 GMT
Subject: RFR: 8297912: HotSpot Style Guide should permit alignas (Second
 Proposal Attempt)
In-Reply-To: <eCAeDe5ORoZK54IrQanGLeu5JBYPDiwNAedr_PffcrA=.c9aa40b0-3bef-4935-9770-dde2a7fd84ee@github.com>
References: <Lyv_ypxMsA5tjqJ3d4KwScyySdBcTo34lL8abbF4SoQ=.44f3b51c-30b8-428e-b715-6af70bccaaf5@github.com>
 <Sicv5R257TmnOgiAqUkEzRt1ZmYRVdiMH22bxib8xBk=.69b6d831-7479-4e4e-8135-9e862f2b157d@github.com>
 <eCAeDe5ORoZK54IrQanGLeu5JBYPDiwNAedr_PffcrA=.c9aa40b0-3bef-4935-9770-dde2a7fd84ee@github.com>
Message-ID: <ap-aztdg2g4BweBRfvTdhTj-Iofat3gqVtCHnwgvQvE=.94907cd7-7be5-477f-81dd-cb56d26774f7@github.com>

On Fri, 2 Dec 2022 08:37:07 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Also, @rose00 voiced concerns in the original PR ([#11315 (comment)](https://github.com/openjdk/jdk/pull/11315#issuecomment-1332982465)) which should be addressed first. I cautiously share his concerns for the moment.

I actually missed John's concerns, but it seems like @kimbarrett has already beaten me to it in remarking that there's almost no difference (if at all) between `alignas` and the different syntax `ATTRIBUTE_ALIGNED` expands to, except for the former being a little stricter in certain cases (but this is not always a bad thing). For what it's worth though, Visual C++ does explicitly mention that both the __declspec and `alignas` are identical, and [strongly encourages using the C++ keyword instead](https://learn.microsoft.com/en-us/cpp/cpp/alignment-cpp-declarations?view=msvc-170)

I feel like this is one of those instances where there isn't much that would make one lean more towards either rejecting or accepting the change, but `alignas` is somewhat better defined than the compiler extensions, which is (at least to me) a small win

-------------

PR: https://git.openjdk.org/jdk/pull/11446

From duke at openjdk.org  Fri Dec  2 13:23:16 2022
From: duke at openjdk.org (Afshin Zafari)
Date: Fri, 2 Dec 2022 13:23:16 GMT
Subject: RFR: 8297766: Remove UseMallocOnly development option
In-Reply-To: <voCTdkgKWb5cEMNNLGebSUp78Qwrjqxbd6Xd4ibBrEI=.1011a314-2882-488a-80da-b53e24869155@github.com>
References: <34gopg6h0xMvkDTyTltghkTZPl4IZdODxcCJMKN-Ki8=.8117d9d7-9325-482d-b232-49ca862413b2@github.com>
 <voCTdkgKWb5cEMNNLGebSUp78Qwrjqxbd6Xd4ibBrEI=.1011a314-2882-488a-80da-b53e24869155@github.com>
Message-ID: <gAc3yY5t156E8MV8hdFRIqRHC078FZmoH0VOCcR5K90=.848c10cb-28eb-4bdb-8d83-4edc6e55ec80@github.com>

On Thu, 1 Dec 2022 18:51:21 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Good riddance :-)
> 
> I think `HandleArea` can be simplified too. It does a lot of gymnastics to work around the UseMallocOnly mode.
> 
> I believe you can scratch `HandleArea::real_allocate_handle()` and redirect `HandleArea::allocate_handle()` to directly call `Arena::Amalloc`. Have not tested though.

The current Call hierarchy is: 

HandleArea::allocate_handle()
  HandleArea::real_allocate_handle()
    Arena::internal_amalloc()

and your suggestion is:

HandleArea::allocate_handle()
  Arena::Amalloc()
    Arena::internal_malloc()

Question:
`Arena::Amalloc` has some more lines of code before calling `internal_malloc()`. So what to be done for these extra lines of codes? Can I simply replace `internal_malloc` with `Arena::Amalloc`?

-------------

PR: https://git.openjdk.org/jdk/pull/11456

From epeter at openjdk.org  Fri Dec  2 13:29:39 2022
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 2 Dec 2022 13:29:39 GMT
Subject: RFR: 8294540: Remove Opaque2Node: it is broken and triggers assert
 [v2]
In-Reply-To: <3j2Rhe5W9Os-yy1Stqlh-h69SIebbVz2_nsfigH5jfY=.fe3c7faa-da70-4064-9687-d791cdc97acf@github.com>
References: <3j2Rhe5W9Os-yy1Stqlh-h69SIebbVz2_nsfigH5jfY=.fe3c7faa-da70-4064-9687-d791cdc97acf@github.com>
Message-ID: <-M1KwwcakWJvHepuB7BR3gBswY3cHCApL_-Gi1MeJIw=.99cc9ff7-76a2-42ac-a58c-afced8bc7a42@github.com>

> As @chhagedorn nicely analyzed, `Opaque2` nodes seem to be broken.
> https://github.com/openjdk/jdk/pull/10306
> 
> **Original idea behing Opaque2**
> The idea was to avoid loop-exit values to have both the un-incremented phi-value and the incremented one. Having both may mean using 2 registers, where 1 register could be enough if we only carry the incremented value, and simply decrement after the loop. Opaque2 was inserted to prevent optimizations that would optimize (Phi + inc - inc) down to (Phi). We had a pattern (Phi + inc -> Opaque2 -> - inc), so the add/sub do not get collapsed. Many years back, that used to be fine, and we would only remove Opaque2 nodes once no IGVN round was run anymore. But now, we take Opaque2 nodes out of the graph and then run IGVN again, which undoes all of the effort.
> 
> **Must remove for now, maybe implement properly later**
> For now we remove it, because they can trigger asserts, and is simply a rotten optimization. We think that this optimization should probably be done at the very end anyway, after the last IGVN round.
> 
> Performance tests indicate that removing it now does not lead to slowdown.
> 
> **Analysis of the assert**
> 
> In `PhaseIdealLoop::do_unroll`, we check that the main loop has the same limit in the zero-trip-guard as in the loop-exit. For that, we find the `Opaque1` node `opaq` for the zero-trip-guard limit. We compare its input with the `limit` from the loop-exit. This assert is useful, if we change loop-limits we must ensure they are in sync.
> 
> https://github.com/openjdk/jdk/blob/8c472e481676ed0ef475c4989477d5714880c59e/src/hotspot/share/opto/loopTransform.cpp#L2227-L2228
> 
> Unfortunately, we insert two separate `Opaque2` nodes for the zero-trip-guard and loop-exit in this example.
> Sequence of events:
> - We have 2 loops
> - The second loop is pre-main-post split. The main loop eventually takes the pre-incremented Phi value of the first loop as its loop-limit.
> - The first loop eventually detects that its pre-incremented Phi value is used, and inserts Opaque2 nodes for every use. Unfortunately, the zero-trip-guard `CmpI` and the loop-exit `CmpI` both are direct uses of that pre-incremented Phi (this is very rare, as it seems, usually there are other operations in between, and then it is a single use, that eventually feeds into zero-trip-guard and loop-exit-check).
> 
> ![image](https://user-images.githubusercontent.com/32593061/205263253-b5b811cc-504e-4072-9d10-1bc134964c9d.png)

Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:

  Review suggestions from Christian

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11477/files
  - new: https://git.openjdk.org/jdk/pull/11477/files/36e2180c..17954728

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11477&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11477&range=00-01

  Stats: 5 lines in 3 files changed: 0 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/11477.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11477/head:pull/11477

PR: https://git.openjdk.org/jdk/pull/11477

From jpbempel at openjdk.org  Fri Dec  2 13:59:18 2022
From: jpbempel at openjdk.org (Jean-Philippe Bempel)
Date: Fri, 2 Dec 2022 13:59:18 GMT
Subject: RFR: 8157023: Integrate NMT with JFR
In-Reply-To: <WkUY7sW-crChZ60T5dl_ZOFkSwKXGJ7Xzjs4oW8USA8=.05fedd85-edd4-4a85-bc74-010d27e90c16@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <5etH99SkJXLDG9IeW1kNIjvCWU-Ydhbg5JBMZM34tFg=.7401c117-7dbb-4ea0-89e1-31bbe6f0d78b@github.com>
 <l5PaDcRr8Uxk2KXhvfKP1FTFbVD2QIosVOHqVuXaun0=.925a675b-f986-451c-a92c-694c2d98d9ed@github.com>
 <IBlRVDETFl0xpVvcUKPF0Spko2Wgm7ScqRlg0OgmNT4=.a1c25637-1940-432e-a834-0e8c83272be2@github.com>
 <WkUY7sW-crChZ60T5dl_ZOFkSwKXGJ7Xzjs4oW8USA8=.05fedd85-edd4-4a85-bc74-010d27e90c16@github.com>
Message-ID: <LU18LkapNzS9PxwR6stjmJQ5rJ6CbaljYzWPRNAaj-4=.773b12c7-d536-426a-ac96-67a9e060d634@github.com>

On Fri, 2 Dec 2022 10:51:15 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>  I think these events will be mostly useful for Hotspot developers and support engineers.

I respectfully disagree on that. In a container world, it's common to be hit by OOMKill when sizing the JVM correctly. Most people think only by the Java heap size, and forget about the native part. And when you do, there is few control or possible way to troubleshoot why the native part is going off what you expect. The only useful tool in this situation is NMT to be able to triage which space is the culprit.
see https://blog.arkey.fr/2020/11/30/off-heap-reconnaissance/

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From stuefe at openjdk.org  Fri Dec  2 14:10:13 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 2 Dec 2022 14:10:13 GMT
Subject: RFR: 8157023: Integrate NMT with JFR
In-Reply-To: <pg5eXOt5ALakpMZH8ZhCjkaPb7cMjZDrY--xCgQ5QIQ=.baa270b4-a53e-44f8-ae57-2491f606e27b@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <5etH99SkJXLDG9IeW1kNIjvCWU-Ydhbg5JBMZM34tFg=.7401c117-7dbb-4ea0-89e1-31bbe6f0d78b@github.com>
 <84OX5QvbH9Bnuw6pl9jhcsvUif87oOsyEqpqKvbl1LE=.4dd2660d-dd34-4a89-a1b4-768c089a7991@github.com>
 <lKhT7B2g2KL3rJ551N_D0D_sBdstIdUCAD5230diRj8=.5fbf36c9-e983-4b8c-a080-84fed14b6882@github.com>
 <E6M6A0ycYcHCVsjhk0gCw8w5nSz3_m1lAGvArfC2h08=.a7091058-f44a-4f6c-9b64-a92d7e3e088e@github.com>
 <pg5eXOt5ALakpMZH8ZhCjkaPb7cMjZDrY--xCgQ5QIQ=.baa270b4-a53e-44f8-ae57-2491f606e27b@github.com>
Message-ID: <LGrMBI8A4LaQOY9bQ4-R8XxjJ-K7fcejfnwbecZLqw4=.0aee1293-f403-4dac-9276-930a0ca7a56d@github.com>

On Fri, 2 Dec 2022 11:51:52 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Hi @kstefanj ,
>> 
>>> Haven't looked at the details of `baseline(bool summaryOnly)` that much, but since it `summaryOnly = true` I don't think it actually walk the thread stacks, right?
>> 
>> I think we do, since summary info contains information about committed thread stack size. I think the call chain is 
>> 
>> 
>> MemBaseline::baseline()->
>> MemBaseline::baseline_summary()->
>> VirtualMemorySummary::snapshot()->
>> VirtualMemoryTracker::snapshot_thread_stacks()->
>> VirtualMemoryTracker::walk_virtual_memory()->
>> SnapshotThreadStackWalker::do_allocation_site()->
>> RegionIterator::next_committed()->
>> os::committed_in_range()->
>> mincore loop
>> 
>> 
>>> 
>>> We don't do this at a safepoint but looking at `MallocMemorySnapshot::copy_to(...)` it uses `ThreadCritical` to avoid things being cleaned out at the same time. Not sure if there are other thread safety problems though. I would expect this to have the same problems as a summary report triggered through `jcmd` because that isn't run at a safepoint either.
>> 
>> You are right, I could have sworn we do this with a VM op. Must have confused this with metaspace printing.
>> 
>>> But I do see that when used from `jcmd` we take a lock to serialize the NMT query, so we should probably do the same here.
>>> 
>>> ```
>>>   // Query lock is used to synchronize the access to tracking data.
>>>   // So far, it is only used by JCmd query, but it may be used by
>>>   // other tools.
>>>   static inline Mutex* query_lock() {
>>>     assert(NMTQuery_lock != NULL, "not initialized!");
>>>     return NMTQuery_lock;
>>>   }
>>> ```
>>> 
>>> So we certainly need to look closer at this. I would like to understand why the query lock is needed.
>> 
>> To serialize jcmds running in parallel. Since jcmd is done by the attach listener thread, the only way I can think of would be if someone in parallel executes the command via mbean? Not sure.
>> 
>> Note that there is no way to get consistent counter values across all categories anyway. All the counters are updated atomically without lock, and that is all we can afford in malloc. Counters are not synchronized among themselves.
>
>> I think we do, since summary info contains information about committed thread stack size. 
> 
> You are totally correct, somehow missed that part of `VirtualMemorySummary::snapshot()`. So yes, we should really look at only doing one snapshot per period. Any feeling for exactly how expensive this walk is?
> 
>> To serialize jcmds running in parallel. Since jcmd is done by the attach listener thread, the only way I can think of would be if someone in parallel executes the command via mbean? Not sure.
> 
> Ok, so if executed via the mbean it would be executed in another thread but still use `DCMD::execute()` and the lock to make sure those are synchronized. Anyhow, do you agree with my above understanding that what is protected by the lock is the "cached baseline"? So as long as JFR doesn't use it, the lock should not be needed?
> 
>> Note that there is no way to get consistent counter values across all categories anyway. All the counters are updated atomically without lock, and that is all we can afford in malloc. Counters are not synchronized among themselves.
> 
> Agreed, this is a snapshot at a given point of a moving target.

> Looking a bit more at this. To me it seems like we are protecting the stored baseline with the lock is:
> 
> ```
> class MemTracker : AllStatic {
> ...
>   // Stored baseline
>   static MemBaseline      _baseline;
> ...
> };
> ```
> 
> That the `NMTDCmd` code uses through `MemTracker::get_baseline()`. So if the JFR events keep its own baseline we should be fine without the lock. Or am I missing something here?

I think this should be safe. 

But I still think about thread stack probing. Your sampler will compete via ThreadCritical with thread creation and destruction (and a number of other unrelated things) because it needs to walk the virtual memory region chains. I think NMT reporting was never planned to be done in high volume. 

I experimented a lot with a large number of threads and NMT thread stack probing. Its results are sometimes surprising, e.g. I regularly get much higher numbers from NMT than for process RSS. E.g. NMT tells me we have 4g committed thread stack when RSS is just 630M. This is without swapping.

So I am not sure how reliable thread stack probing actually is in reality. I know that Zhengyu put a lot of work into it and it needed a number of iterations. Since all the rest together is just reading out counters and reporting them, thread stack probing is the only unknown time-wise. It is O(n) over both number of threads and thread stack size and will potentially lock. We can improve matters somewhat with smarter locking, but the O(n) part remains.

Maybe leave that stuff out and just report the normal counters? Or can we live with large jitters here? This is a JFR question and I'm not a JFR developer :)

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From coleenp at openjdk.org  Fri Dec  2 14:13:22 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 2 Dec 2022 14:13:22 GMT
Subject: RFR: 8291830: jvmti/RedefineClasses/StressRedefine failed:
 assert(!is_null(v)) failed: narrow klass value can never be zero
In-Reply-To: <Mbg2-xljhBlEKcDh2PK5liK7-rBy-DUUsGo4JzdAal8=.e376169b-5cbd-4123-9f67-d4d219121bdc@github.com>
References: <Mbg2-xljhBlEKcDh2PK5liK7-rBy-DUUsGo4JzdAal8=.e376169b-5cbd-4123-9f67-d4d219121bdc@github.com>
Message-ID: <jsQ-YTRGtTrExiZkJmDi6WMRq6K8zd7J9FwztivpQII=.6b0ab1ed-d0a8-4675-b2ef-37f65d7b1034@github.com>

On Thu, 1 Dec 2022 02:01:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The code for RedefineVerifyMark in redefinition replaces the OopHandle mirror so that the verification has the right mirror, but it really should just copy it.  Replacing an OopHandle in the ClassLoaderData didn't set the has_modified_oops flag so GC wasn't noticing that this handle is old.
> 
> Tested with tier1-4 and tier6 in progress (linux-x64 and windows-x64 done).

Thanks Serguei!

-------------

PR: https://git.openjdk.org/jdk/pull/11444

From stuefe at openjdk.org  Fri Dec  2 14:21:56 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 2 Dec 2022 14:21:56 GMT
Subject: RFR: 8157023: Integrate NMT with JFR
In-Reply-To: <LU18LkapNzS9PxwR6stjmJQ5rJ6CbaljYzWPRNAaj-4=.773b12c7-d536-426a-ac96-67a9e060d634@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <5etH99SkJXLDG9IeW1kNIjvCWU-Ydhbg5JBMZM34tFg=.7401c117-7dbb-4ea0-89e1-31bbe6f0d78b@github.com>
 <l5PaDcRr8Uxk2KXhvfKP1FTFbVD2QIosVOHqVuXaun0=.925a675b-f986-451c-a92c-694c2d98d9ed@github.com>
 <IBlRVDETFl0xpVvcUKPF0Spko2Wgm7ScqRlg0OgmNT4=.a1c25637-1940-432e-a834-0e8c83272be2@github.com>
 <WkUY7sW-crChZ60T5dl_ZOFkSwKXGJ7Xzjs4oW8USA8=.05fedd85-edd4-4a85-bc74-010d27e90c16@github.com>
 <LU18LkapNzS9PxwR6stjmJQ5rJ6CbaljYzWPRNAaj-4=.773b12c7-d536-426a-ac96-67a9e060d634@github.com>
Message-ID: <CAr0STfVbRpPLZ-Z2Hv-p6MM2rPP5yCKbOleMIDjmII=.122bd69e-6e78-4ab6-8318-7c4a9c6b40f0@github.com>

On Fri, 2 Dec 2022 13:56:37 GMT, Jean-Philippe Bempel <jpbempel at openjdk.org> wrote:

> > I think these events will be mostly useful for Hotspot developers and support engineers.
> 
> I respectfully disagree on that. In a container world, it's common to be hit by OOMKill when sizing the JVM correctly. Most people think only by the Java heap size, and forget about the native part. And when you do, there is few control or possible way to troubleshoot why the native part is going off what you expect. The only useful tool in this situation is NMT to be able to triage which space is the culprit. see https://blog.arkey.fr/2020/11/30/off-heap-reconnaissance/

Hi @jpbempel,

this is currently being discussed as part of https://mail.openjdk.org/pipermail/core-libs-dev/2022-December/097391.html and https://mail.openjdk.org/pipermail/core-libs-dev/2022-November/096369.html. Feel free to take part! I am especially interested in seeing concrete examples where NMT did help customers to lower memory footprint.

Cheers, Thomas

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From stuefe at openjdk.org  Fri Dec  2 14:35:11 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 2 Dec 2022 14:35:11 GMT
Subject: RFR: 8297766: Remove UseMallocOnly development option
In-Reply-To: <gAc3yY5t156E8MV8hdFRIqRHC078FZmoH0VOCcR5K90=.848c10cb-28eb-4bdb-8d83-4edc6e55ec80@github.com>
References: <34gopg6h0xMvkDTyTltghkTZPl4IZdODxcCJMKN-Ki8=.8117d9d7-9325-482d-b232-49ca862413b2@github.com>
 <voCTdkgKWb5cEMNNLGebSUp78Qwrjqxbd6Xd4ibBrEI=.1011a314-2882-488a-80da-b53e24869155@github.com>
 <gAc3yY5t156E8MV8hdFRIqRHC078FZmoH0VOCcR5K90=.848c10cb-28eb-4bdb-8d83-4edc6e55ec80@github.com>
Message-ID: <gCiVmA23KE7NFCDv2UgR8RLkYd3gdLqQqz2Vv7QLYUE=.c9c2f914-3e12-457a-ab88-db519a5db59c@github.com>

On Fri, 2 Dec 2022 13:19:14 GMT, Afshin Zafari <duke at openjdk.org> wrote:

> > Good riddance :-)
> > I think `HandleArea` can be simplified too. It does a lot of gymnastics to work around the UseMallocOnly mode.
> > I believe you can scratch `HandleArea::real_allocate_handle()` and redirect `HandleArea::allocate_handle()` to directly call `Arena::Amalloc`. Have not tested though.
> 
> The current Call hierarchy is:
> 
> ```
> HandleArea::allocate_handle()
>   HandleArea::real_allocate_handle()
>     Arena::internal_amalloc()
> ```
> 
> and your suggestion is:
> 
> ```
> HandleArea::allocate_handle()
>   Arena::Amalloc()
>     Arena::internal_malloc()
> ```
> 
> Question: `Arena::Amalloc` has some more lines of code before calling `internal_malloc()`. So what to be done for these extra lines of codes? Can I simply replace `internal_malloc` with `Arena::Amalloc`?

Looking at this closer, I would call either `internal_malloc` or `AmallocWords` in `allocate_handle`. Both come to almost the same now, with UseMallocOnly gone.

`Amalloc` would give you automatic alignment to word location. Which would be harmless in this case, oop is word sized too, but I rather assert the correct alignment here than to align.

(Backstory: HandleArea contains, basically, an array of oop. oop are word sized. For HandleArea to work correctly, the oop in it must sit "tight", no interleaving of alignment paddings or whatnot. Therefore one should not align, even out of accident.)

HTH, Thomas

-------------

PR: https://git.openjdk.org/jdk/pull/11456

From sjohanss at openjdk.org  Fri Dec  2 14:44:18 2022
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Fri, 2 Dec 2022 14:44:18 GMT
Subject: RFR: 8157023: Integrate NMT with JFR
In-Reply-To: <WkUY7sW-crChZ60T5dl_ZOFkSwKXGJ7Xzjs4oW8USA8=.05fedd85-edd4-4a85-bc74-010d27e90c16@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <5etH99SkJXLDG9IeW1kNIjvCWU-Ydhbg5JBMZM34tFg=.7401c117-7dbb-4ea0-89e1-31bbe6f0d78b@github.com>
 <l5PaDcRr8Uxk2KXhvfKP1FTFbVD2QIosVOHqVuXaun0=.925a675b-f986-451c-a92c-694c2d98d9ed@github.com>
 <IBlRVDETFl0xpVvcUKPF0Spko2Wgm7ScqRlg0OgmNT4=.a1c25637-1940-432e-a834-0e8c83272be2@github.com>
 <WkUY7sW-crChZ60T5dl_ZOFkSwKXGJ7Xzjs4oW8USA8=.05fedd85-edd4-4a85-bc74-010d27e90c16@github.com>
Message-ID: <vGdGDiWrLfa8Royoe55ZjNUPs0wJMSET60u6mp7_saA=.557d50c3-0728-4069-b1f4-e6c60a7d4f9d@github.com>

On Fri, 2 Dec 2022 10:51:15 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> > I still would argue for leaving out reserved, but won't press the point. If you and other reviewers think its useful, lets report it.
> 
> If we feel the events or some fields are not mature, we could mark them experimental. For the events to be emitted, users will need to pass a command line flag, so I think 99% of all users will never enable them. I think these events will be mostly useful for Hotspot developers and support engineers.

For experimental events I think they are emitted as normal events, just not show by default in JMC, right?

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From stuefe at openjdk.org  Fri Dec  2 14:50:00 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 2 Dec 2022 14:50:00 GMT
Subject: RFR: 8157023: Integrate NMT with JFR
In-Reply-To: <U2axxkaIiFTRP7RusW1xjDGIdXFA3sQEOC1TGz6MsdU=.61d2d963-e112-48e2-9473-2fccb7756f42@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <5etH99SkJXLDG9IeW1kNIjvCWU-Ydhbg5JBMZM34tFg=.7401c117-7dbb-4ea0-89e1-31bbe6f0d78b@github.com>
 <U2axxkaIiFTRP7RusW1xjDGIdXFA3sQEOC1TGz6MsdU=.61d2d963-e112-48e2-9473-2fccb7756f42@github.com>
Message-ID: <ejvQErDtxOIIH4VHDzIzDAT1Uy2mi56tVFr-W-u3D8g=.e88577cf-6ff6-45f9-821a-b0af08a53b4e@github.com>

On Fri, 2 Dec 2022 08:30:11 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> src/hotspot/share/services/memReporter.cpp line 25:
>> 
>>> 23:  */
>>> 24: #include "precompiled.hpp"
>>> 25: #include "jfr/jfrEvents.hpp"
>> 
>> I think this is an intermixing of layers. I think it would be cleaner if if JFR accessed the current values from outside, instead of JFR knowledge leaking into NMT.
>
> Not sure I agree, I see the `MemReporter` as the reporting layer and it now knows about JFR to be able to report through it.
> 
> We have in other places created small helpers that send the events to avoid including `jfrEvents.hpp` all over the place, and we could to that here as well. But I don't see a problem with having the reporter residing along side the other reporters.

Okay.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From bdutheil at openjdk.org  Fri Dec  2 14:53:33 2022
From: bdutheil at openjdk.org (Brice Dutheil)
Date: Fri, 2 Dec 2022 14:53:33 GMT
Subject: RFR: 8157023: Integrate NMT with JFR
In-Reply-To: <CAr0STfVbRpPLZ-Z2Hv-p6MM2rPP5yCKbOleMIDjmII=.122bd69e-6e78-4ab6-8318-7c4a9c6b40f0@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <5etH99SkJXLDG9IeW1kNIjvCWU-Ydhbg5JBMZM34tFg=.7401c117-7dbb-4ea0-89e1-31bbe6f0d78b@github.com>
 <l5PaDcRr8Uxk2KXhvfKP1FTFbVD2QIosVOHqVuXaun0=.925a675b-f986-451c-a92c-694c2d98d9ed@github.com>
 <IBlRVDETFl0xpVvcUKPF0Spko2Wgm7ScqRlg0OgmNT4=.a1c25637-1940-432e-a834-0e8c83272be2@github.com>
 <WkUY7sW-crChZ60T5dl_ZOFkSwKXGJ7Xzjs4oW8USA8=.05fedd85-edd4-4a85-bc74-010d27e90c16@github.com>
 <LU18LkapNzS9PxwR6stjmJQ5rJ6CbaljYzWPRNAaj-4=.773b12c7-d536-426a-ac96-67a9e060d634@github.com>
 <CAr0STfVbRpPLZ-Z2Hv-p6MM2rPP5yCKbOleMIDjmII=.122bd69e-6e78-4ab6-8318-7c4a9c6b40f0@github.com>
Message-ID: <bc_qez7kdDSgdyIKAfpEYhFYEXVRMdkSHOPzKf2-wJY=.e1ab8bd8-332f-4f4f-ab68-0fc8a8a75045@github.com>

On Fri, 2 Dec 2022 14:18:21 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Feel free to take part! I am especially interested in seeing concrete examples where NMT did help customers to lower memory footprint.

Actually it's not as much as reducing the memory footprint as it is sizing properly the memory constraints in a deployment unit (either the container and/or the JVM itself). That said this story goes beyond components's memory as reported by NMT to consider the actual process RSS as the dominant metric against OOMKills.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From pchilanomate at openjdk.org  Fri Dec  2 15:05:10 2022
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 2 Dec 2022 15:05:10 GMT
Subject: RFR: 8297864: Dead code elimination [v2]
In-Reply-To: <m9AsrIe0Zhz6GiXEIiViaQ5IZw2U091R_KD-4QBYsb8=.a252030c-3778-46c2-9a61-60f422aa9cb9@github.com>
References: <va_DhGhbW7yeCHuFlm1vugbiqYHxZrRsNGhpE61HQ80=.8500833a-60ae-4805-854e-9c0f0bdfe0e4@github.com>
 <KUPpZUVSn4u8nJGP5e781lLG5OIHoDE7WpRzpGHJVDQ=.ccd4de2a-6633-4e22-b331-cab45107b32d@github.com>
 <m9AsrIe0Zhz6GiXEIiViaQ5IZw2U091R_KD-4QBYsb8=.a252030c-3778-46c2-9a61-60f422aa9cb9@github.com>
Message-ID: <FtQ8tsS6Cx3HWV-PiY_TVyGaoJ4_3S_5mBbPgIDtv7M=.8f8a75cb-28d3-4a43-b89b-068fafcbee6b@github.com>

On Fri, 2 Dec 2022 03:06:27 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hmm I think this warrants closer inspection to ensure there isn't a bug because something is unused (e.g. `is_in_asgct()` code in forte.cpp).
> 
> Also IIRC Loom knowingly integrated a lot of code that will only come in to play in future previews and so it may not be appropriate to cull it now. Perhaps @pchilano can comment?
>
I took a look at the Loom related dead code. I see it's mostly just unused short helper methods, but other than that don't see any removal that would add complexity with future work. If some of those actually turn out to be useful we can bring them back with the related change.

-------------

PR: https://git.openjdk.org/jdk/pull/11439

From eosterlund at openjdk.org  Fri Dec  2 15:05:47 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 2 Dec 2022 15:05:47 GMT
Subject: RFR: 8291830: jvmti/RedefineClasses/StressRedefine failed:
 assert(!is_null(v)) failed: narrow klass value can never be zero
In-Reply-To: <Mbg2-xljhBlEKcDh2PK5liK7-rBy-DUUsGo4JzdAal8=.e376169b-5cbd-4123-9f67-d4d219121bdc@github.com>
References: <Mbg2-xljhBlEKcDh2PK5liK7-rBy-DUUsGo4JzdAal8=.e376169b-5cbd-4123-9f67-d4d219121bdc@github.com>
Message-ID: <DXqtY-SLKB8xkKu_cSIeXG5BiwSIOv5iZ33OzhoK718=.e627d352-f68f-4254-9c86-e7c778965537@github.com>

On Thu, 1 Dec 2022 02:01:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The code for RedefineVerifyMark in redefinition replaces the OopHandle mirror so that the verification has the right mirror, but it really should just copy it.  Replacing an OopHandle in the ClassLoaderData didn't set the has_modified_oops flag so GC wasn't noticing that this handle is old.
> 
> Tested with tier1-4 and tier6 in progress (linux-x64 and windows-x64 done).

Looks good.

-------------

Marked as reviewed by eosterlund (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11444

From sjohanss at openjdk.org  Fri Dec  2 15:36:16 2022
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Fri, 2 Dec 2022 15:36:16 GMT
Subject: RFR: 8157023: Integrate NMT with JFR
In-Reply-To: <LGrMBI8A4LaQOY9bQ4-R8XxjJ-K7fcejfnwbecZLqw4=.0aee1293-f403-4dac-9276-930a0ca7a56d@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <5etH99SkJXLDG9IeW1kNIjvCWU-Ydhbg5JBMZM34tFg=.7401c117-7dbb-4ea0-89e1-31bbe6f0d78b@github.com>
 <84OX5QvbH9Bnuw6pl9jhcsvUif87oOsyEqpqKvbl1LE=.4dd2660d-dd34-4a89-a1b4-768c089a7991@github.com>
 <lKhT7B2g2KL3rJ551N_D0D_sBdstIdUCAD5230diRj8=.5fbf36c9-e983-4b8c-a080-84fed14b6882@github.com>
 <E6M6A0ycYcHCVsjhk0gCw8w5nSz3_m1lAGvArfC2h08=.a7091058-f44a-4f6c-9b64-a92d7e3e088e@github.com>
 <pg5eXOt5ALakpMZH8ZhCjkaPb7cMjZDrY--xCgQ5QIQ=.baa270b4-a53e-44f8-ae57-2491f606e27b@github.com>
 <LGrMBI8A4LaQOY9bQ4-R8XxjJ-K7fcejfnwbecZLqw4=.0aee1293-f403-4dac-9276-930a0ca7a56d@github.com>
Message-ID: <o6WidA4pXIleYI9XX1CZmMV0_-vpEi4UDhEcNLw3BAQ=.9df66ca3-6ece-4d1a-8e25-a7869b18949d@github.com>

On Fri, 2 Dec 2022 14:08:02 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>>> I think we do, since summary info contains information about committed thread stack size. 
>> 
>> You are totally correct, somehow missed that part of `VirtualMemorySummary::snapshot()`. So yes, we should really look at only doing one snapshot per period. Any feeling for exactly how expensive this walk is?
>> 
>>> To serialize jcmds running in parallel. Since jcmd is done by the attach listener thread, the only way I can think of would be if someone in parallel executes the command via mbean? Not sure.
>> 
>> Ok, so if executed via the mbean it would be executed in another thread but still use `DCMD::execute()` and the lock to make sure those are synchronized. Anyhow, do you agree with my above understanding that what is protected by the lock is the "cached baseline"? So as long as JFR doesn't use it, the lock should not be needed?
>> 
>>> Note that there is no way to get consistent counter values across all categories anyway. All the counters are updated atomically without lock, and that is all we can afford in malloc. Counters are not synchronized among themselves.
>> 
>> Agreed, this is a snapshot at a given point of a moving target.
>
>> Looking a bit more at this. To me it seems like we are protecting the stored baseline with the lock is:
>> 
>> ```
>> class MemTracker : AllStatic {
>> ...
>>   // Stored baseline
>>   static MemBaseline      _baseline;
>> ...
>> };
>> ```
>> 
>> That the `NMTDCmd` code uses through `MemTracker::get_baseline()`. So if the JFR events keep its own baseline we should be fine without the lock. Or am I missing something here?
> 
> I think this should be safe. 
> 
> But I still think about thread stack probing. Your sampler will compete via ThreadCritical with thread creation and destruction (and a number of other unrelated things) because it needs to walk the virtual memory region chains. I think NMT reporting was never planned to be done in high volume. 
> 
> I experimented a lot with a large number of threads and NMT thread stack probing. Its results are sometimes surprising, e.g. I regularly get much higher numbers from NMT than for process RSS. E.g. NMT tells me we have 4g committed thread stack when RSS is just 630M. This is without swapping.
> 
> So I am not sure how reliable thread stack probing actually is in reality. I know that Zhengyu put a lot of work into it and it needed a number of iterations. Since all the rest together is just reading out counters and reporting them, thread stack probing is the only unknown time-wise. It is O(n) over both number of threads and thread stack size and will potentially lock. We can improve matters somewhat with smarter locking, but the O(n) part remains.
> 
> Maybe leave that stuff out and just report the normal counters? Or can we live with large jitters here? This is a JFR question and I'm not a JFR developer :)

Yes, maybe creating a special baseline-call that skips the thread-stacks would be ok. As you say, if these are expensive it might be problematic to do them in the periodic thread.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From sjohanss at openjdk.org  Fri Dec  2 15:39:52 2022
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Fri, 2 Dec 2022 15:39:52 GMT
Subject: RFR: 8157023: Integrate NMT with JFR [v2]
In-Reply-To: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
Message-ID: <7MunRi3rxCpz4mk9VmuV2MixTHklxSKjbuW5SmdiGGU=.31447ad0-1c44-4f45-891d-053bed30ddb7@github.com>

> Please review this enhancement to include NMT information in JFR recordings.
> 
> **Summary**
> Native Memory Tracking summary information can be obtained from a running VM using `jcmd` if started with `-XX:NativeMemoryTracking=summary/detail`. Using `jcmd` requires you to run a separate process and to parse the output to get the needed information. This change adds JFR events for NMT information to enable additional ways to consume the NMT data.
> 
> There are two new events added:
> * _NativeMemoryUsage_ - The total native memory usage.
> * _NativeMemoryUsagePart_ - The native memory usage for each component.
> 
> These events are sent periodically and by default the interval is 1s. This can of course be discussed, but that is the staring point. When NMT is not enabled on events will be sent.
> 
> **Testing**
> * Added a simple test to verify that the events are sent as expected depending on if NMT is enabled or not.
> * Mach5 sanity testing

Stefan Johansson has updated the pull request incrementally with two additional commits since the last revision:

 - Some refactoring after comments
 - egahlin and carterkozak comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11449/files
  - new: https://git.openjdk.org/jdk/pull/11449/files/b3af872b..57ab6576

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11449&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11449&range=00-01

  Stats: 281 lines in 10 files changed: 179 ins; 80 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/11449.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11449/head:pull/11449

PR: https://git.openjdk.org/jdk/pull/11449

From pchilanomate at openjdk.org  Fri Dec  2 15:40:22 2022
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 2 Dec 2022 15:40:22 GMT
Subject: RFR: 8297864: Dead code elimination [v3]
In-Reply-To: <Ez7EMefJjwCfLV-uv8cPGgqd-YRzfxOslue8K4CnM38=.1bb9f918-652f-43af-8eee-5133cdd99469@github.com>
References: <va_DhGhbW7yeCHuFlm1vugbiqYHxZrRsNGhpE61HQ80=.8500833a-60ae-4805-854e-9c0f0bdfe0e4@github.com>
 <Ez7EMefJjwCfLV-uv8cPGgqd-YRzfxOslue8K4CnM38=.1bb9f918-652f-43af-8eee-5133cdd99469@github.com>
Message-ID: <Db3TjUaV_vqG6vgrbaUFn3WWlPPN2QHLK_2vK1DP8tQ=.d279ce12-afc4-4314-bfca-276c07c6fe36@github.com>

On Fri, 2 Dec 2022 07:14:35 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Please consider removing all this dead code.
>> I did not have any good way of splitting this up and I did not see any benefit is just splitting it up 'just because'.
>> There is one commit per file couple.
>> Not much else to say, passes t1-4 and I can build:
>> linux-aarch64-debug,linux-arm32-debug,linux-ppc64le-debug,linux-s390x-debug,linux-x86,linux-x86-debug,macosx-aarch64-debug,macosx-x64,macosx-x64-debug,windows-x64-debug,windows-x86-debug and zero-x64-debug
>> Some of them I also built release.
>
> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed whitespace nit

Looks good to me!

Thanks,
Patricio

-------------

Marked as reviewed by pchilanomate (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11439

From sjohanss at openjdk.org  Fri Dec  2 15:43:53 2022
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Fri, 2 Dec 2022 15:43:53 GMT
Subject: RFR: 8157023: Integrate NMT with JFR [v2]
In-Reply-To: <7MunRi3rxCpz4mk9VmuV2MixTHklxSKjbuW5SmdiGGU=.31447ad0-1c44-4f45-891d-053bed30ddb7@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <7MunRi3rxCpz4mk9VmuV2MixTHklxSKjbuW5SmdiGGU=.31447ad0-1c44-4f45-891d-053bed30ddb7@github.com>
Message-ID: <nuDi1WCo6b1iHIsKIc5DJEM3gxRbiLvQN1z75QkDivQ=.c34a87c1-32d3-48cf-8201-1f106f03499e@github.com>

On Fri, 2 Dec 2022 15:39:52 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Please review this enhancement to include NMT information in JFR recordings.
>> 
>> **Summary**
>> Native Memory Tracking summary information can be obtained from a running VM using `jcmd` if started with `-XX:NativeMemoryTracking=summary/detail`. Using `jcmd` requires you to run a separate process and to parse the output to get the needed information. This change adds JFR events for NMT information to enable additional ways to consume the NMT data.
>> 
>> There are two new events added:
>> * _NativeMemoryUsage_ - The total native memory usage.
>> * _NativeMemoryUsagePart_ - The native memory usage for each component.
>> 
>> These events are sent periodically and by default the interval is 1s. This can of course be discussed, but that is the staring point. When NMT is not enabled on events will be sent.
>> 
>> **Testing**
>> * Added a simple test to verify that the events are sent as expected depending on if NMT is enabled or not.
>> * Mach5 sanity testing
>
> Stefan Johansson has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Some refactoring after comments
>  - egahlin and carterkozak comments

Pushed some changes inspired by the discussion here. Not all things have been handled, but I think this is a step in the right direction. 
* The baseline is re-used if newer than 50ms, so if the two events are configured to occur with the same period they should be using the same baseline. I also save the  time of the baseline and use that in all events using that baseline.
* I swapped the event-names, or rather `NativeMemoryUsage` is not the event with a type, and we instead have `NativeMemoryUsageTotal` for the total event. This way we don't have to come up with something better for "part", and "total" is good.
* Also move the JFR-reporting to its own file to get better separation. 

Still some more open questions, like:
* Should we include reserved?
* Should we skip thread probing when doing the baseline?

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From rehn at openjdk.org  Fri Dec  2 15:50:18 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Fri, 2 Dec 2022 15:50:18 GMT
Subject: RFR: 8297864: Dead code elimination [v3]
In-Reply-To: <HWBYK3KRgRk58LPm7gS1LzMsXI0ud4SnEsImtbvHGDE=.44958feb-2259-49db-becb-6081d02e1389@github.com>
References: <va_DhGhbW7yeCHuFlm1vugbiqYHxZrRsNGhpE61HQ80=.8500833a-60ae-4805-854e-9c0f0bdfe0e4@github.com>
 <HWBYK3KRgRk58LPm7gS1LzMsXI0ud4SnEsImtbvHGDE=.44958feb-2259-49db-becb-6081d02e1389@github.com>
Message-ID: <T2YgsOdo-hanJars2RAN3hciXkWOUuDC0RPsIOfn3uU=.af23e7d1-8f0b-428d-a370-e154d83573db@github.com>

On Thu, 1 Dec 2022 14:36:58 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed whitespace nit
>
> I agree, splitting this up would just waste time.  Please run this tool more often! I see some things I should have removed in here, and some things that were proactively added can be added when there's code to use them.
> Looks wonderful.  Will make the code easier to maintain.

Thanks @coleenp and @pchilano !

-------------

PR: https://git.openjdk.org/jdk/pull/11439

From stuefe at openjdk.org  Fri Dec  2 16:36:59 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 2 Dec 2022 16:36:59 GMT
Subject: RFR: 8157023: Integrate NMT with JFR [v2]
In-Reply-To: <nuDi1WCo6b1iHIsKIc5DJEM3gxRbiLvQN1z75QkDivQ=.c34a87c1-32d3-48cf-8201-1f106f03499e@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <7MunRi3rxCpz4mk9VmuV2MixTHklxSKjbuW5SmdiGGU=.31447ad0-1c44-4f45-891d-053bed30ddb7@github.com>
 <nuDi1WCo6b1iHIsKIc5DJEM3gxRbiLvQN1z75QkDivQ=.c34a87c1-32d3-48cf-8201-1f106f03499e@github.com>
Message-ID: <loglNHtE7_iO0hs-kzzL02G4cX-6bm81hEduuOCqQuU=.068734c5-3562-4eb2-9b58-a9c592eb26a7@github.com>

On Fri, 2 Dec 2022 15:41:04 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> Pushed some changes inspired by the discussion here. Not all things have been handled, but I think this is a step in the right direction.
> 
>     * The baseline is re-used if newer than 50ms, so if the two events are configured to occur with the same period they should be using the same baseline. I also save the  time of the baseline and use that in all events using that baseline.

I did some tests and on my box probing 20k threads - if we get ThreadCritical right away - takes about 50-100ms.

> 
>     * I swapped the event-names, or rather `NativeMemoryUsage` is not the event with a type, and we instead have `NativeMemoryUsageTotal` for the total event. This way we don't have to come up with something better for "part", and "total" is good.
> 
>     * Also move the JFR-reporting to its own file to get better separation.
> 

I like this, thank you.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From coleenp at openjdk.org  Fri Dec  2 17:02:13 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 2 Dec 2022 17:02:13 GMT
Subject: RFR: 8291830: jvmti/RedefineClasses/StressRedefine failed:
 assert(!is_null(v)) failed: narrow klass value can never be zero [v2]
In-Reply-To: <Mbg2-xljhBlEKcDh2PK5liK7-rBy-DUUsGo4JzdAal8=.e376169b-5cbd-4123-9f67-d4d219121bdc@github.com>
References: <Mbg2-xljhBlEKcDh2PK5liK7-rBy-DUUsGo4JzdAal8=.e376169b-5cbd-4123-9f67-d4d219121bdc@github.com>
Message-ID: <RHbDkQwCAjp0-7gtqybpJAK_ZaWfdjZ-vOTvbeU-9ew=.c3d3d9f8-992d-4b32-9f62-5a0725e02eff@github.com>

> The code for RedefineVerifyMark in redefinition replaces the OopHandle mirror so that the verification has the right mirror, but it really should just copy it.  Replacing an OopHandle in the ClassLoaderData didn't set the has_modified_oops flag so GC wasn't noticing that this handle is old.
> 
> Tested with tier1-4 and tier6 in progress (linux-x64 and windows-x64 done).

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Kim's offline improvements.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11444/files
  - new: https://git.openjdk.org/jdk/pull/11444/files/2f8d5517..483da5e5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11444&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11444&range=00-01

  Stats: 9 lines in 3 files changed: 0 ins; 3 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/11444.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11444/head:pull/11444

PR: https://git.openjdk.org/jdk/pull/11444

From egahlin at openjdk.org  Fri Dec  2 17:16:23 2022
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 2 Dec 2022 17:16:23 GMT
Subject: RFR: 8157023: Integrate NMT with JFR [v2]
In-Reply-To: <vGdGDiWrLfa8Royoe55ZjNUPs0wJMSET60u6mp7_saA=.557d50c3-0728-4069-b1f4-e6c60a7d4f9d@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <5etH99SkJXLDG9IeW1kNIjvCWU-Ydhbg5JBMZM34tFg=.7401c117-7dbb-4ea0-89e1-31bbe6f0d78b@github.com>
 <l5PaDcRr8Uxk2KXhvfKP1FTFbVD2QIosVOHqVuXaun0=.925a675b-f986-451c-a92c-694c2d98d9ed@github.com>
 <IBlRVDETFl0xpVvcUKPF0Spko2Wgm7ScqRlg0OgmNT4=.a1c25637-1940-432e-a834-0e8c83272be2@github.com>
 <WkUY7sW-crChZ60T5dl_ZOFkSwKXGJ7Xzjs4oW8USA8=.05fedd85-edd4-4a85-bc74-010d27e90c16@github.com>
 <vGdGDiWrLfa8Royoe55ZjNUPs0wJMSET60u6mp7_saA=.557d50c3-0728-4069-b1f4-e6c60a7d4f9d@github.com>
Message-ID: <7UkZ00S16O-Rzy8zZN_I9Eb4PowPiAvmK235FVYb8Q0=.9e73633d-af9e-44d7-8d84-179961d324a8@github.com>

On Fri, 2 Dec 2022 14:42:11 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> For experimental events I think they are emitted as normal events, just not show by default in JMC, right?

Yes, you need to enable a checkbox in a preference dialog.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From kbarrett at openjdk.org  Fri Dec  2 17:18:12 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 2 Dec 2022 17:18:12 GMT
Subject: RFR: 8291830: jvmti/RedefineClasses/StressRedefine failed:
 assert(!is_null(v)) failed: narrow klass value can never be zero [v2]
In-Reply-To: <RHbDkQwCAjp0-7gtqybpJAK_ZaWfdjZ-vOTvbeU-9ew=.c3d3d9f8-992d-4b32-9f62-5a0725e02eff@github.com>
References: <Mbg2-xljhBlEKcDh2PK5liK7-rBy-DUUsGo4JzdAal8=.e376169b-5cbd-4123-9f67-d4d219121bdc@github.com>
 <RHbDkQwCAjp0-7gtqybpJAK_ZaWfdjZ-vOTvbeU-9ew=.c3d3d9f8-992d-4b32-9f62-5a0725e02eff@github.com>
Message-ID: <LI8LnWEEmbigCyXE8W06_kTMkAKnW8ykOOWzx1syYuo=.be0c17d3-0121-4f5a-8193-e3e5729dc427@github.com>

On Fri, 2 Dec 2022 17:02:13 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The code for RedefineVerifyMark in redefinition replaces the OopHandle mirror so that the verification has the right mirror, but it really should just copy it.  Replacing an OopHandle in the ClassLoaderData didn't set the has_modified_oops flag so GC wasn't noticing that this handle is old.
>> 
>> Tested with tier1-4 and tier6 in progress (linux-x64 and windows-x64 done).
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Kim's offline improvements.

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11444

From egahlin at openjdk.org  Fri Dec  2 17:20:12 2022
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 2 Dec 2022 17:20:12 GMT
Subject: RFR: 8157023: Integrate NMT with JFR [v2]
In-Reply-To: <CAr0STfVbRpPLZ-Z2Hv-p6MM2rPP5yCKbOleMIDjmII=.122bd69e-6e78-4ab6-8318-7c4a9c6b40f0@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <5etH99SkJXLDG9IeW1kNIjvCWU-Ydhbg5JBMZM34tFg=.7401c117-7dbb-4ea0-89e1-31bbe6f0d78b@github.com>
 <l5PaDcRr8Uxk2KXhvfKP1FTFbVD2QIosVOHqVuXaun0=.925a675b-f986-451c-a92c-694c2d98d9ed@github.com>
 <IBlRVDETFl0xpVvcUKPF0Spko2Wgm7ScqRlg0OgmNT4=.a1c25637-1940-432e-a834-0e8c83272be2@github.com>
 <WkUY7sW-crChZ60T5dl_ZOFkSwKXGJ7Xzjs4oW8USA8=.05fedd85-edd4-4a85-bc74-010d27e90c16@github.com>
 <LU18LkapNzS9PxwR6stjmJQ5rJ6CbaljYzWPRNAaj-4=.773b12c7-d536-426a-ac96-67a9e060d634@github.com>
 <CAr0STfVbRpPLZ-Z2Hv-p6MM2rPP5yCKbOleMIDjmII=.122bd69e-6e78-4ab6-8318-7c4a9c6b40f0@github.com>
Message-ID: <7w283X4Kb24M6A0ztXtE3FyolIvQkYJfqpXAsJjAxIA=.52649f81-3c7e-4deb-8722-fa6bb648eea2@github.com>

On Fri, 2 Dec 2022 14:18:21 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> I respectfully disagree on that. In a container world, it's common to be hit by OOMKill when sizing the JVM correctly. Most people think only by the Java heap size, and forget about the native part. And when you do, there is few control or possible way to troubleshoot why the native part is going off what you expect. The only useful tool in this situation is NMT to be able to triage which space is the culprit. see https://blog.arkey.fr/2020/11/30/off-heap-reconnaissance/

Thanks, good to know.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From jvernee at openjdk.org  Fri Dec  2 17:42:51 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 2 Dec 2022 17:42:51 GMT
Subject: RFR: 8296477: Foreign linker implementation update following JEP
 434 [v10]
In-Reply-To: <CGd4JSefJvfEVkZEfORzthEIeV53kLk_UkZHAhJGrQ0=.7741b5f2-2227-4017-8164-d54fb9d30d10@github.com>
References: <CGd4JSefJvfEVkZEfORzthEIeV53kLk_UkZHAhJGrQ0=.7741b5f2-2227-4017-8164-d54fb9d30d10@github.com>
Message-ID: <Te2ZS9wAT5n_r8s3Uu6w7UBiueX4MTtkDYaaznp6w4E=.e44ca44c-3a2d-49bd-b1ca-39b5ce756bc7@github.com>

> Pull in linker implementation changes, that include non-trivial changes to VM code, from the panama-foreign repo into the main JDK.
> 
> This is split off from the main JEP integration to make reviewing easier.
> 
> This includes the following patches:
> 
> 1. https://github.com/openjdk/panama-foreign/pull/698
> 2. https://github.com/openjdk/panama-foreign/pull/699
> 3. (part of) https://github.com/openjdk/panama-foreign/pull/731
> 4. https://github.com/openjdk/panama-foreign/pull/740
> 5. https://github.com/openjdk/panama-foreign/pull/746
> 6. https://github.com/openjdk/panama-foreign/pull/742
> 7. https://github.com/openjdk/panama-foreign/pull/743
> 
> Probably the biggest change to the code comes from replacing `VMReg` - which can not represent offsets into the stack that are not a multiple of the VM's stack slot size (32-bits) - with the new `VMStorage` class, which can describe byte offsets into the stack, as well as having a register mask to indicate only certain register segments.
> 
> The only part of 3. that is in this PR is the part that turns the `VMStorage` class in Java into a record.
> 
> Please refer to the PR of each individual patch for a more detailed description.

Jorn Vernee 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 25 additional commits since the last revision:

 - Merge branch 'PR_20' into VM_Changes
 - Merge branch 'PR_20' into VM_Changes
 - use Arena in example
 - Merge branch 'PR_20' into VM_Changes
 - drop .inline from vmstorage header names
 - 8296973: saving errno on a value-returning function crashes the JVM
   
   Reviewed-by: mcimadamore
 - fix stubs
 - constexpr some functions
 - Review pt1
 - Tweak copyright headers
 - ... and 15 more: https://git.openjdk.org/jdk/compare/ea28395b...6e94e452

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11019/files
  - new: https://git.openjdk.org/jdk/pull/11019/files/75917216..6e94e452

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11019&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11019&range=08-09

  Stats: 67862 lines in 1342 files changed: 30668 ins; 21968 del; 15226 mod
  Patch: https://git.openjdk.org/jdk/pull/11019.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11019/head:pull/11019

PR: https://git.openjdk.org/jdk/pull/11019

From jpbempel at openjdk.org  Fri Dec  2 17:57:18 2022
From: jpbempel at openjdk.org (Jean-Philippe Bempel)
Date: Fri, 2 Dec 2022 17:57:18 GMT
Subject: RFR: 8157023: Integrate NMT with JFR [v2]
In-Reply-To: <7w283X4Kb24M6A0ztXtE3FyolIvQkYJfqpXAsJjAxIA=.52649f81-3c7e-4deb-8722-fa6bb648eea2@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <5etH99SkJXLDG9IeW1kNIjvCWU-Ydhbg5JBMZM34tFg=.7401c117-7dbb-4ea0-89e1-31bbe6f0d78b@github.com>
 <l5PaDcRr8Uxk2KXhvfKP1FTFbVD2QIosVOHqVuXaun0=.925a675b-f986-451c-a92c-694c2d98d9ed@github.com>
 <IBlRVDETFl0xpVvcUKPF0Spko2Wgm7ScqRlg0OgmNT4=.a1c25637-1940-432e-a834-0e8c83272be2@github.com>
 <WkUY7sW-crChZ60T5dl_ZOFkSwKXGJ7Xzjs4oW8USA8=.05fedd85-edd4-4a85-bc74-010d27e90c16@github.com>
 <LU18LkapNzS9PxwR6stjmJQ5rJ6CbaljYzWPRNAaj-4=.773b12c7-d536-426a-ac96-67a9e060d634@github.com>
 <CAr0STfVbRpPLZ-Z2Hv-p6MM2rPP5yCKbOleMIDjmII=.122bd69e-6e78-4ab6-8318-7c4a9c6b40f0@github.com>
 <7w283X4Kb24M6A0ztXtE3FyolIvQkYJfqpXAsJjAxIA=.52649f81-3c7e-4deb-8722-fa6bb648eea2@github.com>
Message-ID: <9u0aKFjtkHxX2RJu9ZIhqGeTIAhbfmYKWxWOzzmtRf8=.20a29ad1-2d58-414c-9aa8-9a20545af8db@github.com>

On Fri, 2 Dec 2022 17:16:19 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> > I respectfully disagree on that. In a container world, it's common to be hit by OOMKill when sizing the JVM correctly. Most people think only by the Java heap size, and forget about the native part. And when you do, there is few control or possible way to troubleshoot why the native part is going off what you expect. The only useful tool in this situation is NMT to be able to triage which space is the culprit. see https://blog.arkey.fr/2020/11/30/off-heap-reconnaissance/
> 
> Thanks, good to know.

Also some are so desperate to get NMT stats/metrics dynamically:
https://github.com/mcabaj/nmt-metrics
https://github.com/opentable/otj-jvm/blob/master/src/main/java/com/opentable/jvm/Nmt.java

I think I have also seen published as JMX MBean

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From coleenp at openjdk.org  Fri Dec  2 17:57:19 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 2 Dec 2022 17:57:19 GMT
Subject: RFR: 8291830: jvmti/RedefineClasses/StressRedefine failed:
 assert(!is_null(v)) failed: narrow klass value can never be zero [v2]
In-Reply-To: <RHbDkQwCAjp0-7gtqybpJAK_ZaWfdjZ-vOTvbeU-9ew=.c3d3d9f8-992d-4b32-9f62-5a0725e02eff@github.com>
References: <Mbg2-xljhBlEKcDh2PK5liK7-rBy-DUUsGo4JzdAal8=.e376169b-5cbd-4123-9f67-d4d219121bdc@github.com>
 <RHbDkQwCAjp0-7gtqybpJAK_ZaWfdjZ-vOTvbeU-9ew=.c3d3d9f8-992d-4b32-9f62-5a0725e02eff@github.com>
Message-ID: <sScK5pZGHVGGUF5VzWcg-_wNmFa4rbwg25evGdAKKcI=.c3f79b58-4078-44ba-8013-defbcbeff8f1@github.com>

On Fri, 2 Dec 2022 17:02:13 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The code for RedefineVerifyMark in redefinition replaces the OopHandle mirror so that the verification has the right mirror, but it really should just copy it.  Replacing an OopHandle in the ClassLoaderData didn't set the has_modified_oops flag so GC wasn't noticing that this handle is old.
>> 
>> Tested with tier1-4 and tier6 in progress (linux-x64 and windows-x64 done).
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Kim's offline improvements.

Thanks for reviewing Serguei, Erik.  Kim, thank you for the cleaner implementation with swap and for reviewing.

-------------

PR: https://git.openjdk.org/jdk/pull/11444

From vlivanov at openjdk.org  Fri Dec  2 18:10:00 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 2 Dec 2022 18:10:00 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v6]
In-Reply-To: <BlgmU61ejhlUYvDFqS4vdeD-KZPN1Gs93wP91Y0YE74=.f95c84af-7e10-4426-99f6-985c19d36506@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
 <BlgmU61ejhlUYvDFqS4vdeD-KZPN1Gs93wP91Y0YE74=.f95c84af-7e10-4426-99f6-985c19d36506@github.com>
Message-ID: <xIpFlY8gHxTmKbS8QeSXq6YAwAVV0sM3B438LWu9iJY=.96251abd-f938-4543-9654-ae9613b6ec27@github.com>

On Fri, 2 Dec 2022 10:19:33 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This patch fixes the remaining null pointer dereference bugs that I know of.
>> 
>> For the main bug, C2 was using a null reference to indicate an uninitialized `Node_List`. I replaced the null reference with a static sentinel.
>> 
>> I also turned on `-fsanitize=null` and found and fixed a bunch of other null pointer dereferences. With this,I have run a full bootstrap and tier1 tests with `-fsanitize=null` enabled.
>> 
>> I have checked that the code generated by GCC is not worse in any significant way, so I don't expect to see any performance regressions.
>> 
>> I'd like to enable `-fsanitize=null` in debug builds to prevent regressions in this area. What do you think?
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback from reviewers

Looks good. Thanks.

-------------

Marked as reviewed by vlivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10920

From vlivanov at openjdk.org  Fri Dec  2 18:10:04 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 2 Dec 2022 18:10:04 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v6]
In-Reply-To: <qO8PccVbO_Ro4teqV3uFITYZK7aLxInsCltFgLDpAQ4=.6b04d82d-c68d-4334-beb4-2e05b98435a7@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
 <BlgmU61ejhlUYvDFqS4vdeD-KZPN1Gs93wP91Y0YE74=.f95c84af-7e10-4426-99f6-985c19d36506@github.com>
 <-Gx_fsiwHvInS5q3bAOQAxpaUgj0Qsn015pthmrE5jI=.2adeff80-dfd1-427a-b4a1-a54453dce4aa@github.com>
 <qO8PccVbO_Ro4teqV3uFITYZK7aLxInsCltFgLDpAQ4=.6b04d82d-c68d-4334-beb4-2e05b98435a7@github.com>
Message-ID: <urSvf2KjP46IPHogZ09ZIxIjd5Y-I0hcvahRKRwBKnQ=.a3cf82e6-6891-403f-81a8-76a564de3b66@github.com>

On Fri, 2 Dec 2022 10:58:26 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> src/hotspot/share/opto/postaloc.cpp line 259:
>> 
>>> 257:   if (!can_change_regs) {
>>> 258:     return blk_adjust;          // Only check stupid copies!
>>> 259:   }
>> 
>> Style nit here and in other places: weren't these blocks separated by newline before?
>
> I'm not sure what you mean. Can you make these Suggestions? Thanks.

> weren't these blocks separated by newline before?

They were, but also there were no braces around.

-------------

PR: https://git.openjdk.org/jdk/pull/10920

From coleenp at openjdk.org  Fri Dec  2 18:12:13 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 2 Dec 2022 18:12:13 GMT
Subject: RFR: 8297766: Remove UseMallocOnly development option
In-Reply-To: <34gopg6h0xMvkDTyTltghkTZPl4IZdODxcCJMKN-Ki8=.8117d9d7-9325-482d-b232-49ca862413b2@github.com>
References: <34gopg6h0xMvkDTyTltghkTZPl4IZdODxcCJMKN-Ki8=.8117d9d7-9325-482d-b232-49ca862413b2@github.com>
Message-ID: <kZNcQmsVKua913uXhtBfoQUfzgMuaWc4_X2llFhsRbw=.d1f51e18-2326-49e1-953e-3a04a08bdf33@github.com>

On Thu, 1 Dec 2022 15:37:56 GMT, Afshin Zafari <duke at openjdk.org> wrote:

> ### Description
> The UseMallocOnly development option was originally used to detect memory stomping bugs with Arena allocations when the JVM was first in development.
> 
> The option has had a few bugs and is not in general use. There are ideas to add another way of Arena canary checking.
> 
> ### Patch:
> All occurrences of UseMallocOnly are removed.
> 
> ### Tests:
> Local, gTests: resourceArea and Arena
> Mach5: tier1-5

I added real_allocate_handle()  - I don't see why not keep it, with the comment about UseMallocOnly removed.

-------------

PR: https://git.openjdk.org/jdk/pull/11456

From aph at openjdk.org  Fri Dec  2 18:22:11 2022
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 2 Dec 2022 18:22:11 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v6]
In-Reply-To: <xIpFlY8gHxTmKbS8QeSXq6YAwAVV0sM3B438LWu9iJY=.96251abd-f938-4543-9654-ae9613b6ec27@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
 <BlgmU61ejhlUYvDFqS4vdeD-KZPN1Gs93wP91Y0YE74=.f95c84af-7e10-4426-99f6-985c19d36506@github.com>
 <xIpFlY8gHxTmKbS8QeSXq6YAwAVV0sM3B438LWu9iJY=.96251abd-f938-4543-9654-ae9613b6ec27@github.com>
Message-ID: <0CNGGszgk6rjws_OY8g3RfYioeZmZxYG6J1NDne012c=.3606d48d-a36e-431f-a936-6686824081c7@github.com>

On Fri, 2 Dec 2022 18:06:19 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Feedback from reviewers
>
> Looks good. Thanks.

> My initial testing passed. I will wait update which address latest @iwanowww comments before doing more testing.

OK, I'll push after your ack.

-------------

PR: https://git.openjdk.org/jdk/pull/10920

From aph at openjdk.org  Fri Dec  2 18:22:12 2022
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 2 Dec 2022 18:22:12 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v6]
In-Reply-To: <urSvf2KjP46IPHogZ09ZIxIjd5Y-I0hcvahRKRwBKnQ=.a3cf82e6-6891-403f-81a8-76a564de3b66@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
 <BlgmU61ejhlUYvDFqS4vdeD-KZPN1Gs93wP91Y0YE74=.f95c84af-7e10-4426-99f6-985c19d36506@github.com>
 <-Gx_fsiwHvInS5q3bAOQAxpaUgj0Qsn015pthmrE5jI=.2adeff80-dfd1-427a-b4a1-a54453dce4aa@github.com>
 <qO8PccVbO_Ro4teqV3uFITYZK7aLxInsCltFgLDpAQ4=.6b04d82d-c68d-4334-beb4-2e05b98435a7@github.com>
 <urSvf2KjP46IPHogZ09ZIxIjd5Y-I0hcvahRKRwBKnQ=.a3cf82e6-6891-403f-81a8-76a564de3b66@github.com>
Message-ID: <cHEMNzuksDmdsXt2L6lDxFJRkEx5OCFXe4PYFdS5EDI=.9b88c84a-5b89-44a5-8a27-263bcb3a54f7@github.com>

On Fri, 2 Dec 2022 18:06:07 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> I'm not sure what you mean. Can you make these Suggestions? Thanks.
>
>> weren't these blocks separated by newline before?
> 
> They were, but also there were no braces around.

?

-------------

PR: https://git.openjdk.org/jdk/pull/10920

From shade at openjdk.org  Fri Dec  2 18:27:10 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 2 Dec 2022 18:27:10 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v6]
In-Reply-To: <BlgmU61ejhlUYvDFqS4vdeD-KZPN1Gs93wP91Y0YE74=.f95c84af-7e10-4426-99f6-985c19d36506@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
 <BlgmU61ejhlUYvDFqS4vdeD-KZPN1Gs93wP91Y0YE74=.f95c84af-7e10-4426-99f6-985c19d36506@github.com>
Message-ID: <MdoGh8i9uzrpWWT76ut32allrNPs1dgR4HDhTBSfxcc=.26674707-b5d7-4eb6-b2a8-a90c54d2d981@github.com>

On Fri, 2 Dec 2022 10:19:33 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This patch fixes the remaining null pointer dereference bugs that I know of.
>> 
>> For the main bug, C2 was using a null reference to indicate an uninitialized `Node_List`. I replaced the null reference with a static sentinel.
>> 
>> I also turned on `-fsanitize=null` and found and fixed a bunch of other null pointer dereferences. With this,I have run a full bootstrap and tier1 tests with `-fsanitize=null` enabled.
>> 
>> I have checked that the code generated by GCC is not worse in any significant way, so I don't expect to see any performance regressions.
>> 
>> I'd like to enable `-fsanitize=null` in debug builds to prevent regressions in this area. What do you think?
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback from reviewers

Marked as reviewed by shade (Reviewer).

src/hotspot/share/opto/postaloc.cpp line 259:

> 257:   if (!can_change_regs) {
> 258:     return blk_adjust;          // Only check stupid copies!
> 259:   }

Suggestion:

  }

src/hotspot/share/opto/postaloc.cpp line 264:

> 262:   if (value == NULL || regnd == NULL) {
> 263:     return blk_adjust;
> 264:   }

Suggestion:

  }

-------------

PR: https://git.openjdk.org/jdk/pull/10920

From shade at openjdk.org  Fri Dec  2 18:27:13 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 2 Dec 2022 18:27:13 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v6]
In-Reply-To: <qO8PccVbO_Ro4teqV3uFITYZK7aLxInsCltFgLDpAQ4=.6b04d82d-c68d-4334-beb4-2e05b98435a7@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
 <BlgmU61ejhlUYvDFqS4vdeD-KZPN1Gs93wP91Y0YE74=.f95c84af-7e10-4426-99f6-985c19d36506@github.com>
 <-Gx_fsiwHvInS5q3bAOQAxpaUgj0Qsn015pthmrE5jI=.2adeff80-dfd1-427a-b4a1-a54453dce4aa@github.com>
 <qO8PccVbO_Ro4teqV3uFITYZK7aLxInsCltFgLDpAQ4=.6b04d82d-c68d-4334-beb4-2e05b98435a7@github.com>
Message-ID: <inY8lqRNnZ3_7SLUoPZOYexEWl0xpC0LBIWw66ett1E=.4f255674-6efa-4e12-a5cc-7a0440cee619@github.com>

On Fri, 2 Dec 2022 10:58:26 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> src/hotspot/share/opto/postaloc.cpp line 259:
>> 
>>> 257:   if (!can_change_regs) {
>>> 258:     return blk_adjust;          // Only check stupid copies!
>>> 259:   }
>> 
>> Style nit here and in other places: weren't these blocks separated by newline before?
>
> I'm not sure what you mean. Can you make these Suggestions? Thanks.

See suggestions. I think the style is to have: 


  // Comment
  if (do_something) {
    some_code_here()
  }

  // Comment
  ...

-------------

PR: https://git.openjdk.org/jdk/pull/10920

From shade at openjdk.org  Fri Dec  2 18:27:14 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 2 Dec 2022 18:27:14 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v6]
In-Reply-To: <b4o3tjV_EOG3mUrQYZ5MIeQ-ToFJHdVrBAfMzIWVWz4=.ce32ee96-2a3f-4960-9ef2-0ef56163768f@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
 <BlgmU61ejhlUYvDFqS4vdeD-KZPN1Gs93wP91Y0YE74=.f95c84af-7e10-4426-99f6-985c19d36506@github.com>
 <-Gx_fsiwHvInS5q3bAOQAxpaUgj0Qsn015pthmrE5jI=.2adeff80-dfd1-427a-b4a1-a54453dce4aa@github.com>
 <qO8PccVbO_Ro4teqV3uFITYZK7aLxInsCltFgLDpAQ4=.6b04d82d-c68d-4334-beb4-2e05b98435a7@github.com>
 <b4o3tjV_EOG3mUrQYZ5MIeQ-ToFJHdVrBAfMzIWVWz4=.ce32ee96-2a3f-4960-9ef2-0ef56163768f@github.com>
Message-ID: <fLYyPsnZR7loYYM3-ACxoRd5foarE1R3BWdkBSaNIXU=.5f21974e-29e2-4ccb-a0ca-76185672411f@github.com>

On Fri, 2 Dec 2022 11:01:31 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Of course we can't exclude the possibility of warnings, given that taking the offset of a field of a non-POD class is unspecified behaviour. Having said that, I'm not sure exactly what it'd be warning about.
>
> This restriction in C++ is unnecessary, really, since AFAIK this works on all implementations.

This seems to work on GCCs 9..12 in {x86_64, x86_32, aarch64}.

-------------

PR: https://git.openjdk.org/jdk/pull/10920

From kvn at openjdk.org  Fri Dec  2 18:33:11 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 2 Dec 2022 18:33:11 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v6]
In-Reply-To: <BlgmU61ejhlUYvDFqS4vdeD-KZPN1Gs93wP91Y0YE74=.f95c84af-7e10-4426-99f6-985c19d36506@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
 <BlgmU61ejhlUYvDFqS4vdeD-KZPN1Gs93wP91Y0YE74=.f95c84af-7e10-4426-99f6-985c19d36506@github.com>
Message-ID: <2M-OLpJDr_cTLM92dfKbQRVs2Rf6CTGVqFPLc__osME=.4cb18e38-1f71-49d5-89c5-37b7afcf7c51@github.com>

On Fri, 2 Dec 2022 10:19:33 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This patch fixes the remaining null pointer dereference bugs that I know of.
>> 
>> For the main bug, C2 was using a null reference to indicate an uninitialized `Node_List`. I replaced the null reference with a static sentinel.
>> 
>> I also turned on `-fsanitize=null` and found and fixed a bunch of other null pointer dereferences. With this,I have run a full bootstrap and tier1 tests with `-fsanitize=null` enabled.
>> 
>> I have checked that the code generated by GCC is not worse in any significant way, so I don't expect to see any performance regressions.
>> 
>> I'd like to enable `-fsanitize=null` in debug builds to prevent regressions in this area. What do you think?
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback from reviewers

I started testing v05 version.

-------------

PR: https://git.openjdk.org/jdk/pull/10920

From coleenp at openjdk.org  Fri Dec  2 19:12:19 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 2 Dec 2022 19:12:19 GMT
Subject: Integrated: 8291830: jvmti/RedefineClasses/StressRedefine failed:
 assert(!is_null(v)) failed: narrow klass value can never be zero
In-Reply-To: <Mbg2-xljhBlEKcDh2PK5liK7-rBy-DUUsGo4JzdAal8=.e376169b-5cbd-4123-9f67-d4d219121bdc@github.com>
References: <Mbg2-xljhBlEKcDh2PK5liK7-rBy-DUUsGo4JzdAal8=.e376169b-5cbd-4123-9f67-d4d219121bdc@github.com>
Message-ID: <FroybJbxud9h21Hz5BoXiTeWUhZg8zUnynf9W_VMiqY=.e155c6cb-d91d-448a-9a53-a85ab529e8df@github.com>

On Thu, 1 Dec 2022 02:01:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The code for RedefineVerifyMark in redefinition replaces the OopHandle mirror so that the verification has the right mirror, but it really should just copy it.  Replacing an OopHandle in the ClassLoaderData didn't set the has_modified_oops flag so GC wasn't noticing that this handle is old.
> 
> Tested with tier1-4 and tier6 in progress (linux-x64 and windows-x64 done).

This pull request has now been integrated.

Changeset: fb6fd032
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fb6fd03233b0eb001e2995d20a079b6af31d2b9b
Stats:     18 lines in 5 files changed: 6 ins; 4 del; 8 mod

8291830: jvmti/RedefineClasses/StressRedefine failed: assert(!is_null(v)) failed: narrow klass value can never be zero

Reviewed-by: sspitsyn, eosterlund, kbarrett

-------------

PR: https://git.openjdk.org/jdk/pull/11444

From kvn at openjdk.org  Fri Dec  2 19:28:07 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 2 Dec 2022 19:28:07 GMT
Subject: RFR: 8297912: HotSpot Style Guide should permit alignas (Second
 Proposal Attempt)
In-Reply-To: <Lyv_ypxMsA5tjqJ3d4KwScyySdBcTo34lL8abbF4SoQ=.44f3b51c-30b8-428e-b715-6af70bccaaf5@github.com>
References: <Lyv_ypxMsA5tjqJ3d4KwScyySdBcTo34lL8abbF4SoQ=.44f3b51c-30b8-428e-b715-6af70bccaaf5@github.com>
Message-ID: <TKWpBnmgMgtdngPh9Lc-kLN06eZHuqO6Yl6WOWnM-B4=.dc89b7f8-0d62-47c7-9025-80dbfb3b34a3@github.com>

On Thu, 1 Dec 2022 04:34:56 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> [8252584](https://bugs.openjdk.org/browse/JDK-8252584) was integrated too early due to a mistake on my part, we should redo it and go through the proper approval process this time
> 
> (The changes in this commit are exactly identical to 8252584)

I would vote for using C++ feature which provides similar functionality just to avoid supporting our own implementation.
To have our own implementation was justified before as John R. commented.
That is assuming **ALL** C++ compilers we use today to compile HotSpot code do exactly the same thing.
So before approving this change we need to make sure we (Oracle and OpenJDK community) test #11431 on all our platforms.

-------------

PR: https://git.openjdk.org/jdk/pull/11446

From kvn at openjdk.org  Fri Dec  2 20:02:11 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 2 Dec 2022 20:02:11 GMT
Subject: RFR: 8294540: Remove Opaque2Node: it is broken and triggers assert
 [v2]
In-Reply-To: <-M1KwwcakWJvHepuB7BR3gBswY3cHCApL_-Gi1MeJIw=.99cc9ff7-76a2-42ac-a58c-afced8bc7a42@github.com>
References: <3j2Rhe5W9Os-yy1Stqlh-h69SIebbVz2_nsfigH5jfY=.fe3c7faa-da70-4064-9687-d791cdc97acf@github.com>
 <-M1KwwcakWJvHepuB7BR3gBswY3cHCApL_-Gi1MeJIw=.99cc9ff7-76a2-42ac-a58c-afced8bc7a42@github.com>
Message-ID: <G-dJi1rsa53QGJU1APqYg1DLBTZp1aEz0dXLJBua68s=.fcfc9a14-7677-4725-8e5a-02024d32b4cb@github.com>

On Fri, 2 Dec 2022 13:29:39 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> As @chhagedorn nicely analyzed, `Opaque2` nodes seem to be broken.
>> https://github.com/openjdk/jdk/pull/10306
>> 
>> **Original idea behing Opaque2**
>> The idea was to avoid loop-exit values to have both the un-incremented phi-value and the incremented one. Having both may mean using 2 registers, where 1 register could be enough if we only carry the incremented value, and simply decrement after the loop. Opaque2 was inserted to prevent optimizations that would optimize (Phi + inc - inc) down to (Phi). We had a pattern (Phi + inc -> Opaque2 -> - inc), so the add/sub do not get collapsed. Many years back, that used to be fine, and we would only remove Opaque2 nodes once no IGVN round was run anymore. But now, we take Opaque2 nodes out of the graph and then run IGVN again, which undoes all of the effort.
>> 
>> **Must remove for now, maybe implement properly later**
>> For now we remove it, because they can trigger asserts, and is simply a rotten optimization. We think that this optimization should probably be done at the very end anyway, after the last IGVN round.
>> 
>> Performance tests indicate that removing it now does not lead to slowdown.
>> 
>> **Analysis of the assert**
>> 
>> In `PhaseIdealLoop::do_unroll`, we check that the main loop has the same limit in the zero-trip-guard as in the loop-exit. For that, we find the `Opaque1` node `opaq` for the zero-trip-guard limit. We compare its input with the `limit` from the loop-exit. This assert is useful, if we change loop-limits we must ensure they are in sync.
>> 
>> https://github.com/openjdk/jdk/blob/8c472e481676ed0ef475c4989477d5714880c59e/src/hotspot/share/opto/loopTransform.cpp#L2227-L2228
>> 
>> Unfortunately, we insert two separate `Opaque2` nodes for the zero-trip-guard and loop-exit in this example.
>> Sequence of events:
>> - We have 2 loops
>> - The second loop is pre-main-post split. The main loop eventually takes the pre-incremented Phi value of the first loop as its loop-limit.
>> - The first loop eventually detects that its pre-incremented Phi value is used, and inserts Opaque2 nodes for every use. Unfortunately, the zero-trip-guard `CmpI` and the loop-exit `CmpI` both are direct uses of that pre-incremented Phi (this is very rare, as it seems, usually there are other operations in between, and then it is a single use, that eventually feeds into zero-trip-guard and loop-exit-check).
>> 
>> ![image](https://user-images.githubusercontent.com/32593061/205263253-b5b811cc-504e-4072-9d10-1bc134964c9d.png)
>
> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review suggestions from Christian

I agree with removal of `Opaque2`.

On side note, please file RFE to rename all `Opaque` nodes to something meaningful.
With removal of `Opaque2` numbering is broken. Originally it was only 2 such nodes but now we have 4 and it become hassle to find what they do and why we have so many.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11477

From stuefe at openjdk.org  Fri Dec  2 21:02:09 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 2 Dec 2022 21:02:09 GMT
Subject: RFR: 8297766: Remove UseMallocOnly development option
In-Reply-To: <kZNcQmsVKua913uXhtBfoQUfzgMuaWc4_X2llFhsRbw=.d1f51e18-2326-49e1-953e-3a04a08bdf33@github.com>
References: <34gopg6h0xMvkDTyTltghkTZPl4IZdODxcCJMKN-Ki8=.8117d9d7-9325-482d-b232-49ca862413b2@github.com>
 <kZNcQmsVKua913uXhtBfoQUfzgMuaWc4_X2llFhsRbw=.d1f51e18-2326-49e1-953e-3a04a08bdf33@github.com>
Message-ID: <hg-ZpDojo2ibQJ00O34Xafr0UJzKXiJySycU0g8sEGs=.cea3fc04-2b1b-426f-88b9-8dcf0bd0b400@github.com>

On Fri, 2 Dec 2022 18:10:08 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I added real_allocate_handle() - I don't see why not keep it, with the comment about UseMallocOnly removed.

I was under the impression that its sole job was to circumvent UseMallocOnly by calling internal_malloc directly. But I see it also initializes the allocated slot. Okay, lets keep it.

In that case the patch looks good for me. Sorry for holding it up.

-------------

PR: https://git.openjdk.org/jdk/pull/11456

From stuefe at openjdk.org  Fri Dec  2 21:09:13 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 2 Dec 2022 21:09:13 GMT
Subject: RFR: 8297766: Remove UseMallocOnly development option
In-Reply-To: <34gopg6h0xMvkDTyTltghkTZPl4IZdODxcCJMKN-Ki8=.8117d9d7-9325-482d-b232-49ca862413b2@github.com>
References: <34gopg6h0xMvkDTyTltghkTZPl4IZdODxcCJMKN-Ki8=.8117d9d7-9325-482d-b232-49ca862413b2@github.com>
Message-ID: <aFHogrwNle5w1e2wXKJVAHNZSKx7kKR0Ig3OB3jvM8k=.bc4f53f8-53b7-4c93-85fb-6d550531cdb1@github.com>

On Thu, 1 Dec 2022 15:37:56 GMT, Afshin Zafari <duke at openjdk.org> wrote:

> ### Description
> The UseMallocOnly development option was originally used to detect memory stomping bugs with Arena allocations when the JVM was first in development.
> 
> The option has had a few bugs and is not in general use. There are ideas to add another way of Arena canary checking.
> 
> ### Patch:
> All occurrences of UseMallocOnly are removed.
> 
> ### Tests:
> Local, gTests: resourceArea and Arena
> Mach5: tier1-5

Marked as reviewed by stuefe (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11456

From stuefe at openjdk.org  Fri Dec  2 21:09:21 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 2 Dec 2022 21:09:21 GMT
Subject: RFR: 8157023: Integrate NMT with JFR [v2]
In-Reply-To: <9u0aKFjtkHxX2RJu9ZIhqGeTIAhbfmYKWxWOzzmtRf8=.20a29ad1-2d58-414c-9aa8-9a20545af8db@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <5etH99SkJXLDG9IeW1kNIjvCWU-Ydhbg5JBMZM34tFg=.7401c117-7dbb-4ea0-89e1-31bbe6f0d78b@github.com>
 <l5PaDcRr8Uxk2KXhvfKP1FTFbVD2QIosVOHqVuXaun0=.925a675b-f986-451c-a92c-694c2d98d9ed@github.com>
 <IBlRVDETFl0xpVvcUKPF0Spko2Wgm7ScqRlg0OgmNT4=.a1c25637-1940-432e-a834-0e8c83272be2@github.com>
 <WkUY7sW-crChZ60T5dl_ZOFkSwKXGJ7Xzjs4oW8USA8=.05fedd85-edd4-4a85-bc74-010d27e90c16@github.com>
 <LU18LkapNzS9PxwR6stjmJQ5rJ6CbaljYzWPRNAaj-4=.773b12c7-d536-426a-ac96-67a9e060d634@github.com>
 <CAr0STfVbRpPLZ-Z2Hv-p6MM2rPP5yCKbOleMIDjmII=.122bd69e-6e78-4ab6-8318-7c4a9c6b40f0@github.com>
 <7w283X4Kb24M6A0ztXtE3FyolIvQkYJfqpXAsJjAxIA=.52649f81-3c7e-4deb-8722-fa6bb648eea2@github.com>
 <9u0aKFjtkHxX2RJu9ZIhqGeTIAhbfmYKWxWOzzmtRf8=.20a29ad1-2d58-414c-9aa8-9a20545af8db@github.com>
Message-ID: <1VvGjIgLrjPs8deOnhuwmVUl2zRpWU1anw2pojdPlSs=.e1b328aa-a4d3-46b6-be71-58d97c96879f@github.com>

On Fri, 2 Dec 2022 17:54:52 GMT, Jean-Philippe Bempel <jpbempel at openjdk.org> wrote:

> 
> Also some are so desperate to get NMT stats/metrics dynamically: https://github.com/mcabaj/nmt-metrics https://github.com/opentable/otj-jvm/blob/master/src/main/java/com/opentable/jvm/Nmt.java
> 
> I think I have also seen published as JMX MBean

SapMachine can generate it dynamically on low error situations. https://github.com/SAP/SapMachine/wiki/SapMachine-High-Memory-Reports

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From duke at openjdk.org  Fri Dec  2 23:36:03 2022
From: duke at openjdk.org (Johannes Bechberger)
Date: Fri, 2 Dec 2022 23:36:03 GMT
Subject: RFR: 8297967: Make frame::safe_for_sender safer [v2]
In-Reply-To: <u8vLzfKWPN8ylMl_3rA9uKXYD1kc9u0PsnUpxr5fMCs=.a4248d04-bc0a-4661-be88-274ef8d297a5@github.com>
References: <Cctc-M2HyUqIjpcRyTjmF46wKDqvBtnnYe5Mn45sdO8=.03bdf65f-bf98-48dc-b957-0c838003d46f@github.com>
 <W7jCII0F-N-vINSt1vg_g0ejpVSv27GSlBtuKRyS790=.ec4382ea-28b1-4daa-8812-57a7b2be9e18@github.com>
 <FWuqIBRIn1Y1ddcyZZLfsfx-_kDBI5AVurZwvQnw36M=.824e5311-399b-478e-b7ed-bb46eec4c2aa@github.com>
 <RejOSw1JjBA2pQFJGB3Dxj9cqjQa8YNFQi-GHVZByXE=.0cd28c78-5637-4057-9447-b542c5aaffda@github.com>
 <u8vLzfKWPN8ylMl_3rA9uKXYD1kc9u0PsnUpxr5fMCs=.a4248d04-bc0a-4661-be88-274ef8d297a5@github.com>
Message-ID: <vs0st_tG0PwfNYpeURj4j2wSCsBDJgWA-tebEhbRCk4=.beb08fad-d931-4bcf-8c49-6bc886c55761@github.com>

On Fri, 2 Dec 2022 06:18:50 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I'll get crashes in my fuzzing test case if I leave it out.
>
> I agree fp has already been validated.

But has fp + return_addr_offset?

-------------

PR: https://git.openjdk.org/jdk/pull/11461

From kvn at openjdk.org  Sat Dec  3 00:45:05 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sat, 3 Dec 2022 00:45:05 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v6]
In-Reply-To: <BlgmU61ejhlUYvDFqS4vdeD-KZPN1Gs93wP91Y0YE74=.f95c84af-7e10-4426-99f6-985c19d36506@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
 <BlgmU61ejhlUYvDFqS4vdeD-KZPN1Gs93wP91Y0YE74=.f95c84af-7e10-4426-99f6-985c19d36506@github.com>
Message-ID: <pJ9bHn3dvBGt7kkQ2a9n-Zvrvj1fJzkvftUnBX0MEfc=.ba03f8e3-4e04-42f5-8a8c-a8923bb61559@github.com>

On Fri, 2 Dec 2022 10:19:33 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This patch fixes the remaining null pointer dereference bugs that I know of.
>> 
>> For the main bug, C2 was using a null reference to indicate an uninitialized `Node_List`. I replaced the null reference with a static sentinel.
>> 
>> I also turned on `-fsanitize=null` and found and fixed a bunch of other null pointer dereferences. With this,I have run a full bootstrap and tier1 tests with `-fsanitize=null` enabled.
>> 
>> I have checked that the code generated by GCC is not worse in any significant way, so I don't expect to see any performance regressions.
>> 
>> I'd like to enable `-fsanitize=null` in debug builds to prevent regressions in this area. What do you think?
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback from reviewers

My testing of v05 passed.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10920

From chagedorn at openjdk.org  Sat Dec  3 01:09:01 2022
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Sat, 3 Dec 2022 01:09:01 GMT
Subject: RFR: 8294540: Remove Opaque2Node: it is broken and triggers assert
 [v2]
In-Reply-To: <G-dJi1rsa53QGJU1APqYg1DLBTZp1aEz0dXLJBua68s=.fcfc9a14-7677-4725-8e5a-02024d32b4cb@github.com>
References: <3j2Rhe5W9Os-yy1Stqlh-h69SIebbVz2_nsfigH5jfY=.fe3c7faa-da70-4064-9687-d791cdc97acf@github.com>
 <-M1KwwcakWJvHepuB7BR3gBswY3cHCApL_-Gi1MeJIw=.99cc9ff7-76a2-42ac-a58c-afced8bc7a42@github.com>
 <G-dJi1rsa53QGJU1APqYg1DLBTZp1aEz0dXLJBua68s=.fcfc9a14-7677-4725-8e5a-02024d32b4cb@github.com>
Message-ID: <6kpmQHPq695Q9QqXCML6zkzs4OuzHPNHpYzAitA7iDQ=.27bec11c-cc07-4f0c-af9a-46bdeae15693@github.com>

On Fri, 2 Dec 2022 19:59:56 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> On side note, please file RFE to rename all `Opaque` nodes to something meaningful. With removal of `Opaque2` numbering is broken. Originally it was only 2 such nodes but now we have 4 and it become hassle to find what they do and why we have so many.

That is a good idea. I've planned to rename `Opaque4` nodes and get rid of some of their usages in the redesign of the skeleton predicates ([JDK-8288981](https://bugs.openjdk.org/browse/JDK-8288981)). But it could already be done earlier together with renaming the other opaque nodes now that we get rid of `Opaque2` nodes.

-------------

PR: https://git.openjdk.org/jdk/pull/11477

From fyang at openjdk.org  Sat Dec  3 04:25:59 2022
From: fyang at openjdk.org (Fei Yang)
Date: Sat, 3 Dec 2022 04:25:59 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v6]
In-Reply-To: <fLYyPsnZR7loYYM3-ACxoRd5foarE1R3BWdkBSaNIXU=.5f21974e-29e2-4ccb-a0ca-76185672411f@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
 <BlgmU61ejhlUYvDFqS4vdeD-KZPN1Gs93wP91Y0YE74=.f95c84af-7e10-4426-99f6-985c19d36506@github.com>
 <-Gx_fsiwHvInS5q3bAOQAxpaUgj0Qsn015pthmrE5jI=.2adeff80-dfd1-427a-b4a1-a54453dce4aa@github.com>
 <qO8PccVbO_Ro4teqV3uFITYZK7aLxInsCltFgLDpAQ4=.6b04d82d-c68d-4334-beb4-2e05b98435a7@github.com>
 <b4o3tjV_EOG3mUrQYZ5MIeQ-ToFJHdVrBAfMzIWVWz4=.ce32ee96-2a3f-4960-9ef2-0ef56163768f@github.com>
 <fLYyPsnZR7loYYM3-ACxoRd5foarE1R3BWdkBSaNIXU=.5f21974e-29e2-4ccb-a0ca-76185672411f@github.com>
Message-ID: <s7AynR1CNMKTrOHmAnXRUclYXWScoJTrpLLdH6dhAVQ=.58ed6851-505d-47e7-a2a5-a51ea781fab5@github.com>

On Fri, 2 Dec 2022 18:12:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This restriction in C++ is unnecessary, really, since AFAIK this works on all implementations.
>
> This seems to work on GCCs 9..12 in {x86_64, x86_32, aarch64}.

FYI: I have verified this also works with GCC version 11.3.0 on linux-riscv64 platform.

-------------

PR: https://git.openjdk.org/jdk/pull/10920

From aph at openjdk.org  Sat Dec  3 10:25:07 2022
From: aph at openjdk.org (Andrew Haley)
Date: Sat, 3 Dec 2022 10:25:07 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v6]
In-Reply-To: <s7AynR1CNMKTrOHmAnXRUclYXWScoJTrpLLdH6dhAVQ=.58ed6851-505d-47e7-a2a5-a51ea781fab5@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
 <BlgmU61ejhlUYvDFqS4vdeD-KZPN1Gs93wP91Y0YE74=.f95c84af-7e10-4426-99f6-985c19d36506@github.com>
 <-Gx_fsiwHvInS5q3bAOQAxpaUgj0Qsn015pthmrE5jI=.2adeff80-dfd1-427a-b4a1-a54453dce4aa@github.com>
 <qO8PccVbO_Ro4teqV3uFITYZK7aLxInsCltFgLDpAQ4=.6b04d82d-c68d-4334-beb4-2e05b98435a7@github.com>
 <b4o3tjV_EOG3mUrQYZ5MIeQ-ToFJHdVrBAfMzIWVWz4=.ce32ee96-2a3f-4960-9ef2-0ef56163768f@github.com>
 <fLYyPsnZR7loYYM3-ACxoRd5foarE1R3BWdkBSaNIXU=.5f21974e-29e2-4ccb-a0ca-76185672411f@github.com>
 <s7AynR1CNMKTrOHmAnXRUclYXWScoJTrpLLdH6dhAVQ=.58ed6851-505d-47e7-a2a5-a51ea781fab5@github.com>
Message-ID: <YrObZ-AMkq6SwiXtk_qhke4mFXlyg6BIgqDfdKjScpU=.ae45ca15-24ae-4748-b069-46e34c36e54a@github.com>

On Sat, 3 Dec 2022 04:23:25 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> This seems to work on GCCs 9..12 in {x86_64, x86_32, aarch64}.
>
> FYI: I have verified this also works with GCC version 11.3.0 on linux-riscv64 platform.

Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/10920

From kbarrett at openjdk.org  Sun Dec  4 11:07:05 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 4 Dec 2022 11:07:05 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v6]
In-Reply-To: <BlgmU61ejhlUYvDFqS4vdeD-KZPN1Gs93wP91Y0YE74=.f95c84af-7e10-4426-99f6-985c19d36506@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
 <BlgmU61ejhlUYvDFqS4vdeD-KZPN1Gs93wP91Y0YE74=.f95c84af-7e10-4426-99f6-985c19d36506@github.com>
Message-ID: <5XghOZvyut9Es6W8cwzhuMVv0QRvGyjYioiS_yw7-rM=.849d9533-ddbf-44ab-bc9c-7eac1d1918e2@github.com>

On Fri, 2 Dec 2022 10:19:33 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This patch fixes the remaining null pointer dereference bugs that I know of.
>> 
>> For the main bug, C2 was using a null reference to indicate an uninitialized `Node_List`. I replaced the null reference with a static sentinel.
>> 
>> I also turned on `-fsanitize=null` and found and fixed a bunch of other null pointer dereferences. With this,I have run a full bootstrap and tier1 tests with `-fsanitize=null` enabled.
>> 
>> I have checked that the code generated by GCC is not worse in any significant way, so I don't expect to see any performance regressions.
>> 
>> I'd like to enable `-fsanitize=null` in debug builds to prevent regressions in this area. What do you think?
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback from reviewers

Just noticed this PR, and have only skimmed through it.  I have an idea for an alternative way to write `offset_of`
that I *think* might be better.  I'm going to try it out and report back.  That doesn't have to hold you up if you want
to proceed.

-------------

PR: https://git.openjdk.org/jdk/pull/10920

From kbarrett at openjdk.org  Sun Dec  4 12:06:38 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 4 Dec 2022 12:06:38 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v6]
In-Reply-To: <BlgmU61ejhlUYvDFqS4vdeD-KZPN1Gs93wP91Y0YE74=.f95c84af-7e10-4426-99f6-985c19d36506@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
 <BlgmU61ejhlUYvDFqS4vdeD-KZPN1Gs93wP91Y0YE74=.f95c84af-7e10-4426-99f6-985c19d36506@github.com>
Message-ID: <lFEz8AOhp_gBimT5XCzSfTdPO5kC9m1DM5ek7YXh5Cg=.c3fa3b84-d899-4694-9992-39c064eda89a@github.com>

On Fri, 2 Dec 2022 10:19:33 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This patch fixes the remaining null pointer dereference bugs that I know of.
>> 
>> For the main bug, C2 was using a null reference to indicate an uninitialized `Node_List`. I replaced the null reference with a static sentinel.
>> 
>> I also turned on `-fsanitize=null` and found and fixed a bunch of other null pointer dereferences. With this,I have run a full bootstrap and tier1 tests with `-fsanitize=null` enabled.
>> 
>> I have checked that the code generated by GCC is not worse in any significant way, so I don't expect to see any performance regressions.
>> 
>> I'd like to enable `-fsanitize=null` in debug builds to prevent regressions in this area. What do you think?
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback from reviewers

Regarding enabling `fsanitize=null` by default in debug builds, that may run afoul of incompatibilities between
sanitizers and `_FORTIFY_SOURCE`, which we already use in fastdebug builds.  See `FLAGS_SETUP_OPTIMIZATION`
in flags-cflags.m4, where `_FORTIFY_SOURCE` is setup unless ASan is enabled.

-------------

PR: https://git.openjdk.org/jdk/pull/10920

From kbarrett at openjdk.org  Sun Dec  4 15:11:03 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 4 Dec 2022 15:11:03 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v6]
In-Reply-To: <BlgmU61ejhlUYvDFqS4vdeD-KZPN1Gs93wP91Y0YE74=.f95c84af-7e10-4426-99f6-985c19d36506@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
 <BlgmU61ejhlUYvDFqS4vdeD-KZPN1Gs93wP91Y0YE74=.f95c84af-7e10-4426-99f6-985c19d36506@github.com>
Message-ID: <ua00w1fE2Z6zjpBjR24B5vVoU2yAcQoSYskNraObfQ4=.76c48947-13ca-44f8-858e-d734da2ec410@github.com>

On Fri, 2 Dec 2022 10:19:33 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This patch fixes the remaining null pointer dereference bugs that I know of.
>> 
>> For the main bug, C2 was using a null reference to indicate an uninitialized `Node_List`. I replaced the null reference with a static sentinel.
>> 
>> I also turned on `-fsanitize=null` and found and fixed a bunch of other null pointer dereferences. With this,I have run a full bootstrap and tier1 tests with `-fsanitize=null` enabled.
>> 
>> I have checked that the code generated by GCC is not worse in any significant way, so I don't expect to see any performance regressions.
>> 
>> I'd like to enable `-fsanitize=null` in debug builds to prevent regressions in this area. What do you think?
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback from reviewers

> Just noticed this PR, and have only skimmed through it. I have an idea for an alternative way to write `offset_of` that I _think_ might be better. I'm going to try it out and report back. That doesn't have to hold you up if you want to proceed.

That idea for an alternative `offset_of` implementation didn't pan out.  And I wasn't able to make disabling the
`-Winvalid-offsetof` warning within that macro work.  But now I'm wondering why it is being changed?  If I take
your changes except backout the `offset_of` change, and build with `-fsanitize=null` (for now by co-opting the
`--enable-asan` config option, since there's more to it than just adding that option to `--with-extra-cxxflags`),
that works (with gcc11.3).  So what is the `offset_of` change about?

-------------

PR: https://git.openjdk.org/jdk/pull/10920

From jwaters at openjdk.org  Sun Dec  4 18:16:09 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 4 Dec 2022 18:16:09 GMT
Subject: RFR: 8250269: Replace ATTRIBUTE_ALIGNED with alignas [v3]
In-Reply-To: <9QKV9cYFTo_1D8R-mI80lnewNkA0ceJNKFPbrvICxl4=.d6736b76-8324-4084-bede-6e144b4f6c04@github.com>
References: <9QKV9cYFTo_1D8R-mI80lnewNkA0ceJNKFPbrvICxl4=.d6736b76-8324-4084-bede-6e144b4f6c04@github.com>
Message-ID: <f8nQMqdeqd6Ex5KUH0QVpZwRqZguTH3wwMCKU4oFoqY=.bd9a44db-373d-4f36-88f8-d1d6bc500530@github.com>

> C++11 added the alignas attribute, for the purpose of specifying alignment on types, much like compiler specific syntax such as gcc's __attribute__((aligned(x))) or Visual C++'s __declspec(align(x)).
> 
> We can phase out the use of the macro in favor of the standard attribute. In the meantime, we can replace the toolchain specific definitions of ATTRIBUTE_ALIGNED with a portable definition. We might deprecate the use of the macro but changing its implementation quickly and cleanly applies the feature where the macro is being used.
> 
> Note: With certain parts of HotSpot using ATTRIBUTE_ALIGNED so indiscriminately, this commit will likely take some time to get right
> 
> This will require adding the alignas attribute to the list of language features approved for use in HotSpot code. (Ongoing at [8297912](https://github.com/openjdk/jdk/pull/11446))

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 two additional commits since the last revision:

 - Merge branch 'openjdk:master' into alignas
 - alignas

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11431/files
  - new: https://git.openjdk.org/jdk/pull/11431/files/047a0b1b..e617e5cb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11431&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11431&range=01-02

  Stats: 20419 lines in 319 files changed: 5751 ins; 13672 del; 996 mod
  Patch: https://git.openjdk.org/jdk/pull/11431.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11431/head:pull/11431

PR: https://git.openjdk.org/jdk/pull/11431

From jwaters at openjdk.org  Sun Dec  4 18:18:00 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 4 Dec 2022 18:18:00 GMT
Subject: RFR: 8297912: HotSpot Style Guide should permit alignas (Second
 Proposal Attempt) [v2]
In-Reply-To: <Lyv_ypxMsA5tjqJ3d4KwScyySdBcTo34lL8abbF4SoQ=.44f3b51c-30b8-428e-b715-6af70bccaaf5@github.com>
References: <Lyv_ypxMsA5tjqJ3d4KwScyySdBcTo34lL8abbF4SoQ=.44f3b51c-30b8-428e-b715-6af70bccaaf5@github.com>
Message-ID: <58rvZjSeJKCKUkZd4xEsQxaQjgGWs-V4IPBpSNutc0g=.883e96aa-b385-4019-80f5-69b56e732e20@github.com>

> [8252584](https://bugs.openjdk.org/browse/JDK-8252584) was integrated too early due to a mistake on my part, we should redo it and go through the proper approval process this time
> 
> (The changes in this commit are exactly identical to 8252584)

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 two additional commits since the last revision:

 - Merge branch 'openjdk:master' into style
 - HotSpot Style Guide

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11446/files
  - new: https://git.openjdk.org/jdk/pull/11446/files/2fb10863..792b96a2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11446&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11446&range=00-01

  Stats: 20419 lines in 319 files changed: 5751 ins; 13672 del; 996 mod
  Patch: https://git.openjdk.org/jdk/pull/11446.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11446/head:pull/11446

PR: https://git.openjdk.org/jdk/pull/11446

From stuefe at openjdk.org  Sun Dec  4 19:25:59 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sun, 4 Dec 2022 19:25:59 GMT
Subject: RFR: JDK-8293313: NMT: Rework MallocLimit
Message-ID: <-KHeOvjwe5Osf05XWQuO5ELZUs-ogUVj25xCouJaDaU=.b0906406-dd44-4eb4-be76-debe83867249@github.com>

Rework NMT `MallocLimit` to make it more useful for native OOM analysis. Also remove `MallocMaxTestWords`, which had been mostly redundant with NMT (for background, see JDK-8293292).


### Background

Some months ago we had [JDK-8291919](https://bugs.openjdk.org/browse/JDK-8291919), a compiler regression that caused compiler arenas to grow boundlessly. Process was usually OOM-killed before we could take a look, so this was difficult to analyze.

To improve analysis options, we added NMT *malloc limits* with [JDK-8291878](https://bugs.openjdk.org/browse/JDK-8291878). Malloc limits let us set one or multiple limits to malloc load. Surpassing a limit causes the VM to stop with a fatal error in the allocation function, giving us a hs-err file and a core right at the point that (probably) causes the leak. This makes error analysis a lot simpler, and is also valuable for regression-testing footprint usage.

Some people wished for a way to not end with a fatal error but to mimic a native OOM (causing os::malloc to return NULL). This would allow us to test resilience in the face of native OOMs, among other things.

### Patch

- Expands the `MallocLimit` option syntax, allowing for an "oom mode" that mimics an oom:



Global form:
-XX:MallocLimit=<size>[:<mode>]
Category-specific form:
-XX:MallocLimit=<category>:<size>[:<mode>][,<category>:<size>[:<mode>] ...]
Examples:
-XX:MallocLimit=3g
-XX:MallocLimit=3g:oom
-XX:MallocLimit=compiler:200m:oom


- moves parsing of `-XX:MallocLimit` out of arguments.cpp into `mallocLimit.hpp/cpp`, and rewrites it.

- changes when limits are checked. Before, the limits were checked *after* the allocation that caused the threshold overflow. Now we check beforehand.

- removes `MallocMaxTestWords`, replacing its uses with `MallocLimit`

- adds new gtests and new jtreg tests

- removes a bunch of jtreg tests which are now better served by the new gtests.

- gives us more precise error messages upon reaching a limit. For example:

before:

#  fatal error: MallocLimit: category "Compiler" reached limit (size: 20997680, limit: 20971520)


now:

#  fatal error: MallocLimit: reached category "Compiler" limit (triggering allocation size: 1920B, allocated so far: 20505K, limit: 20480K)

-------------

Commit messages:
 - MallocLimit

Changes: https://git.openjdk.org/jdk/pull/11371/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11371&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293313
  Stats: 992 lines in 21 files changed: 639 ins; 266 del; 87 mod
  Patch: https://git.openjdk.org/jdk/pull/11371.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11371/head:pull/11371

PR: https://git.openjdk.org/jdk/pull/11371

From dholmes at openjdk.org  Mon Dec  5 00:13:55 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 5 Dec 2022 00:13:55 GMT
Subject: RFR: JDK-8296907: VMError: add optional callstacks,
 siginfo for secondary errors [v12]
In-Reply-To: <oxflPz5qkquAtnkHzN1SvOCysUV7ug1IUebbVK4n8ro=.e9904f64-1e92-41ec-8d8b-953b2d3344ce@github.com>
References: <x1kul17oEaJ-UX6ZGPv8OcsxN8QfYlME_d39aSATk-Q=.f0e0169c-15f5-4b4b-8235-68f8e68ec43c@github.com>
 <oxflPz5qkquAtnkHzN1SvOCysUV7ug1IUebbVK4n8ro=.e9904f64-1e92-41ec-8d8b-953b2d3344ce@github.com>
Message-ID: <loJaw4zL1GqSJ-ojhDsQRHL2ndRyaFS0EqNdA9I3hB4=.b9657e61-c2bb-4a01-a6ed-273f226a49ad@github.com>

On Thu, 1 Dec 2022 16:36:25 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> This was motivated by discussions we had in https://github.com/openjdk/jdk/pull/11017.
>> 
>> To aid in analyzing secondary errors during error reporting, it would be useful to see their callstacks for secondary errors. But printing callstacks during error reporting is unsafe - if we get a second crash or assert, it will cause infinite recursion and interrupt error reporting. Also, the hs-err file would be quite verbose. Therefore this feature is optional and limited to debug builds. 
>> 
>> ---
>> 
>> Patch
>> 
>> - adds optional callstack/siginfo printing via debug-only switch `-XX:+ErrorLogSecondaryErrorDetails`.
>> - fixes a bug in secondary error handling where we would use the global scratch buffer recursively (via stringStream); that could lead to confusing output since it is used by the error log stream already. We can print directly to that one instead.
>> - Removed a stray newline from print_native_stack to clean output.
>> - added regression testing for this feature. I removed my name and the bug id from the test since we don't do this anymore (?).
>> - added clarifying comments to the test and code
>> - added SAP copyright to the regression test (we introduced it years ago for JDK-8065895)
>> 
>> Output looks like this:
>> 
>> 
>> $ java ... -XX:+ErrorLogSecondaryErrorDetails
>> 
>> 
>> will produce, for secondary errors, siginfo and call stack.
>> 
>> 
>> [error occurred during error reporting (test secondary crash 1), id 0xb, SIGSEGV (0xb) at pc=0x00007fddfe8a0a61]
>> [siginfo: si_signo: 11 (SIGSEGV), si_code: 128 (SI_KERNEL), si_addr: 0x0000000000000000]
>> [stack: Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0x1ceea61]  VMError::controlled_crash(int)+0x241  (vmError.cpp:1946)
>> V  [libjvm.so+0x1cf413f]  VMError::report(outputStream*, bool)+0x46bf  (vmError.cpp:564)
>> V  [libjvm.so+0x1cf516b]  VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x19b  (vmError.cpp:1709)
>> V  [libjvm.so+0x1cf5e8f]  VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*, char const*, ...)+0x8f  (vmError.cpp:1467)
>> V  [libjvm.so+0x1cf5ec2]  VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*)+0x22  (vmError.cpp:1473)
>> V  [libjvm.so+0x1a549e7]  JVM_handle_linux_signal+0x1f7  (signals_posix.cpp:656)
>> C  [libc.so.6+0x43090]
>> V  [libjvm.so+0x11d6965]  JNI_CreateJavaVM+0x5b5  (jni.cpp:3662)
>> C  [libjli.so+0x4013]  JavaMain+0x93  (java.c:1457)
>> C  [libjli.so+0x800d]  ThreadJavaMain+0xd  (java_md.c:650)
>> ]
>
> Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove unused imports from test
>  - Make ErrorLogSecondaryErrorDetails a diagnostic product flag

No objections from me, we will see how this works out in practice.

-------------

PR: https://git.openjdk.org/jdk/pull/11118

From pli at openjdk.org  Mon Dec  5 01:58:58 2022
From: pli at openjdk.org (Pengfei Li)
Date: Mon, 5 Dec 2022 01:58:58 GMT
Subject: RFR: 8297689: Fix incorrect result of Short.reverseBytes() call in
 loops
In-Reply-To: <yv1aUlZMKpLVbXZmkSqZtWLlDTa-5PeX6pzzBu1Rrb8=.6ef681fe-6dbd-4dab-9ee0-61f59fbeb024@github.com>
References: <yv1aUlZMKpLVbXZmkSqZtWLlDTa-5PeX6pzzBu1Rrb8=.6ef681fe-6dbd-4dab-9ee0-61f59fbeb024@github.com>
Message-ID: <7m440EBF_ieeg_F2949KCwkMZ1Eicv0EppR7l6in--M=.874eb130-b6ff-46fe-90c5-15c848f9c369@github.com>

On Wed, 30 Nov 2022 07:20:11 GMT, Pengfei Li <pli at openjdk.org> wrote:

> Recently, we find calling `Short.reverseBytes()` in loops may generate incorrect result if the code is compiled by C2. Below is a simple case to reproduce.
> 
> 
> class Foo {
>   static final int SIZE = 50;
>   static int a[] = new int[SIZE];
> 
>   static void test() {
>     for (int i = 0; i < SIZE; i++) {
>       a[i] = Short.reverseBytes((short) a[i]);
>     }
>   }
> 
>   public static void main(String[] args) throws Exception {
>     Class.forName("java.lang.Short");
>     a[25] = 16;
>     test();
>     System.out.println(a[25]);
>   }
> }
> 
> // $ java -Xint Foo
> // 4096
> // $ java -Xcomp -XX:-TieredCompilation -XX:CompileOnly=Foo.test Foo
> // 268435456
> 
> 
> In this case, the `reverseBytes()` call is intrinsified and transformed into a `ReverseBytesS` node. But then C2 compiler incorrectly vectorizes it into `ReverseBytesV` with int type. C2 `Op_ReverseBytes*` has short, char, int and long versions. Their behaviors are different for different data sizes. In superword, subword operation itself doesn't have precise data size info. Instead, the data size info comes from memory operations in its use-def chain. Hence, vectorization of `reverseBytes()` is valid only if the data size is consistent with the type size of the caller's class. But current C2 compiler code lacks fine-grained type checks for `ReverseBytes*` in vector transformation. It results in `reverseBytes()` call from Short or Character class with int load/store gets vectorized incorrectly in above case.
> 
> To fix the issue, this patch adds more checks in `VectorNode::opcode()`. T_BYTE is a special case for `Op_ReverseBytes*`. As the Java Byte class doesn't have `reverseBytes()` method so there's no `Op_ReverseBytesB`. But T_BYTE may still appear in VectorAPI calls. In this patch we still use `Op_ReverseBytesI` for T_BYTE to ensure vector intrinsification succeeds.
> 
> Tested with hotspot::hotspot_all_no_apps, jdk tier1~3 and langtools tier1 on x86 and AArch64, no issue is found.

@jatin-bhateja Do you have any comments on this change?

-------------

PR: https://git.openjdk.org/jdk/pull/11427

From xlinzheng at openjdk.org  Mon Dec  5 03:14:49 2022
From: xlinzheng at openjdk.org (Xiaolin Zheng)
Date: Mon, 5 Dec 2022 03:14:49 GMT
Subject: RFR: 8297763: Fix missing stub code expansion before align() in
 shared trampolines [v2]
In-Reply-To: <hXb-nZ_3CbhHULvpC11ZmgHK4hiKsQYTioGm4duTmFc=.4c457487-3edd-4b54-87af-1b3335192009@github.com>
References: <T5fCT6B-2hhjmlMaRuu5iHfMI-gxkuFJp3jtjGh7ZtM=.719d411d-da4f-482b-af14-c9caee93b865@github.com>
 <QOm1rf2yvHIVvNhyiPG97YQOX-_5j1VjLoYKbl20lEQ=.98674f31-37eb-4967-bcfe-caad03b5d9ba@github.com>
 <hXb-nZ_3CbhHULvpC11ZmgHK4hiKsQYTioGm4duTmFc=.4c457487-3edd-4b54-87af-1b3335192009@github.com>
Message-ID: <1IBO-R3hp-lsMbzp0tEJtcyO6PZeoaxGFpgC_btEyVM=.7e05dea4-8650-451a-a93c-971e71859e3c@github.com>

On Thu, 1 Dec 2022 10:12:01 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix as to comments
>
> Looks reasonable to me.

Thanks for the reviews @RealFYang @luhenry! (The GHA failure is not related)

-------------

PR: https://git.openjdk.org/jdk/pull/11414

From xlinzheng at openjdk.org  Mon Dec  5 04:29:11 2022
From: xlinzheng at openjdk.org (Xiaolin Zheng)
Date: Mon, 5 Dec 2022 04:29:11 GMT
Subject: RFR: 8298075: RISC-V: Implement post-call NOPs
Message-ID: <inZ_2fowZZQz0C53E2h4zURoyQIwZcJaBfhC4zwFyb8=.cbc7e361-9bad-48ce-b6d4-c3a8fe2e1cba@github.com>

Same as [JDK-8287567](https://bugs.openjdk.org/browse/JDK-8287567), we need to implement post-call NOPs in the RISC-V backend.

We use `li32` to implement it. `li32` will signed-extend the loaded imm32 to a 64-bit register. However, our reader`NativePostCallNop::displacement()` only needs the low 32 bits value so we are safe.

The current post-call NOP is like:

nop                    (always 4-byte, used for deoptimization, please see `NativePostCallNop::make_deopt()`)
lui zr, <imm20>        (always 4-byte)
addiw zr, zr, <imm12>  (always 4-byte)


The code size here is the same as the AArch64 counterpart, 12 bytes.

The logic of setting the post-call NOP displacement is at `install_post_call_nop_displacement()` [1] when nmethods are being installed, so no one is running post-call NOPs when we are patching them.

One can check them by directly using `java --enable-preview -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly`.

Tested hotspot tier1~4 and jdk tier1~4 using fastdebug by force turning on `--enable-preview`; SPECjbb2015 and dacapo were tested without regressions found.

Thanks,
Xiaolin

[1] https://github.com/openjdk/jdk/blob/b49fd920b6690a8b828c85e45c10e5c4c54d2022/src/hotspot/share/code/nmethod.cpp#L1078-L1107

-------------

Commit messages:
 - May I take a ride?
 - RISC-V: Implement post-call NOPs

Changes: https://git.openjdk.org/jdk/pull/11502/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11502&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298075
  Stats: 39 lines in 6 files changed: 32 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/11502.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11502/head:pull/11502

PR: https://git.openjdk.org/jdk/pull/11502

From xlinzheng at openjdk.org  Mon Dec  5 04:45:02 2022
From: xlinzheng at openjdk.org (Xiaolin Zheng)
Date: Mon, 5 Dec 2022 04:45:02 GMT
Subject: RFR: 8298075: RISC-V: Implement post-call NOPs [v2]
In-Reply-To: <inZ_2fowZZQz0C53E2h4zURoyQIwZcJaBfhC4zwFyb8=.cbc7e361-9bad-48ce-b6d4-c3a8fe2e1cba@github.com>
References: <inZ_2fowZZQz0C53E2h4zURoyQIwZcJaBfhC4zwFyb8=.cbc7e361-9bad-48ce-b6d4-c3a8fe2e1cba@github.com>
Message-ID: <ZutmQEDBBwhDrCWpyfntabJhFO2Yd6s4hjsUVwBoqdc=.64ac53b9-92f7-4db4-9610-1e79aa67ce4e@github.com>

> Same as [JDK-8287567](https://bugs.openjdk.org/browse/JDK-8287567), we need to implement post-call NOPs in the RISC-V backend.
> 
> We use `li32` to implement it. `li32` will signed-extend the loaded imm32 to a 64-bit register. However, our reader `NativePostCallNop::displacement()` only needs the low 32 bits value so we are safe.
> 
> The current post-call NOP is like:
> 
> nop                    (always 4-byte, used for deoptimization, please see `NativePostCallNop::make_deopt()`)
> lui zr, <imm20>        (always 4-byte)
> addiw zr, zr, <imm12>  (always 4-byte)
> 
> 
> The code size here is the same as the AArch64 counterpart, 12 bytes.
> 
> The logic of setting the post-call NOP displacement is at `install_post_call_nop_displacement()` [1] when nmethods are being installed, so no one is running post-call NOPs when we are patching them.
> 
> One can check them by directly using `java --enable-preview -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly`.
> 
> Tested hotspot tier1~4 and jdk tier1~4 using fastdebug by force turning on `--enable-preview`; SPECjbb2015 and dacapo were tested without regressions found. Skynet JMH benchmark seems to have an improvement from `8662ms/op -> 8495ms/op`.
> 
> Thanks,
> Xiaolin
> 
> [1] https://github.com/openjdk/jdk/blob/b49fd920b6690a8b828c85e45c10e5c4c54d2022/src/hotspot/share/code/nmethod.cpp#L1078-L1107

Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision:

  ASSERT: JDK-8288078

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11502/files
  - new: https://git.openjdk.org/jdk/pull/11502/files/4eb4ed93..c8fffe8a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11502&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11502&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11502.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11502/head:pull/11502

PR: https://git.openjdk.org/jdk/pull/11502

From xlinzheng at openjdk.org  Mon Dec  5 04:53:06 2022
From: xlinzheng at openjdk.org (Xiaolin Zheng)
Date: Mon, 5 Dec 2022 04:53:06 GMT
Subject: RFR: 8298075: RISC-V: Implement post-call NOPs [v3]
In-Reply-To: <inZ_2fowZZQz0C53E2h4zURoyQIwZcJaBfhC4zwFyb8=.cbc7e361-9bad-48ce-b6d4-c3a8fe2e1cba@github.com>
References: <inZ_2fowZZQz0C53E2h4zURoyQIwZcJaBfhC4zwFyb8=.cbc7e361-9bad-48ce-b6d4-c3a8fe2e1cba@github.com>
Message-ID: <xMEcjdDuKZ8gp-McOsb-zADkmNUFZQdfteY5pshX3TY=.ad6f4996-8370-48e7-bea5-c2ed2282a601@github.com>

> Same as [JDK-8287567](https://bugs.openjdk.org/browse/JDK-8287567), we need to implement post-call NOPs in the RISC-V backend.
> 
> We use `li32` to implement it. `li32` will signed-extend the loaded imm32 to a 64-bit register. However, our reader `NativePostCallNop::displacement()` only needs the low 32 bits value so we are safe.
> 
> The current post-call NOP is like:
> 
> nop                    (always 4-byte, used for deoptimization, please see `NativePostCallNop::make_deopt()`)
> lui zr, <imm20>        (always 4-byte)
> addiw zr, zr, <imm12>  (always 4-byte)
> 
> 
> The code size here is the same as the AArch64 counterpart, 12 bytes.
> 
> The logic of setting the post-call NOP displacement is at `install_post_call_nop_displacement()` [1] when nmethods are being installed, so no one is running post-call NOPs when we are patching them.
> 
> One can check them by directly using `java --enable-preview -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly`.
> 
> Tested hotspot tier1~4 and jdk tier1~4 using fastdebug by force turning on `--enable-preview`; SPECjbb2015 and dacapo were tested without regressions found. Skynet JMH benchmark seems to have an improvement from `8662ms/op -> 8495ms/op`.
> 
> Thanks,
> Xiaolin
> 
> [1] https://github.com/openjdk/jdk/blob/b49fd920b6690a8b828c85e45c10e5c4c54d2022/src/hotspot/share/code/nmethod.cpp#L1078-L1107

Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision:

  Better to remove the ASSERT for we already use assert()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11502/files
  - new: https://git.openjdk.org/jdk/pull/11502/files/c8fffe8a..8fb83ac3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11502&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11502&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11502.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11502/head:pull/11502

PR: https://git.openjdk.org/jdk/pull/11502

From dholmes at openjdk.org  Mon Dec  5 06:49:37 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 5 Dec 2022 06:49:37 GMT
Subject: RFR: 8297864: Dead code elimination [v3]
In-Reply-To: <Ez7EMefJjwCfLV-uv8cPGgqd-YRzfxOslue8K4CnM38=.1bb9f918-652f-43af-8eee-5133cdd99469@github.com>
References: <va_DhGhbW7yeCHuFlm1vugbiqYHxZrRsNGhpE61HQ80=.8500833a-60ae-4805-854e-9c0f0bdfe0e4@github.com>
 <Ez7EMefJjwCfLV-uv8cPGgqd-YRzfxOslue8K4CnM38=.1bb9f918-652f-43af-8eee-5133cdd99469@github.com>
Message-ID: <-E99RGu6KpBC2gpJbI4gcmTn2KmUs8KUIrFUH0vncoI=.4d72ffb7-ced4-438a-9ace-4710a5ea6c79@github.com>

On Fri, 2 Dec 2022 07:14:35 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Please consider removing all this dead code.
>> I did not have any good way of splitting this up and I did not see any benefit is just splitting it up 'just because'.
>> There is one commit per file couple.
>> Not much else to say, passes t1-4 and I can build:
>> linux-aarch64-debug,linux-arm32-debug,linux-ppc64le-debug,linux-s390x-debug,linux-x86,linux-x86-debug,macosx-aarch64-debug,macosx-x64,macosx-x64-debug,windows-x64-debug,windows-x86-debug and zero-x64-debug
>> Some of them I also built release.
>
> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed whitespace nit

FTR: The `is_in_asgct` dead code was created by "JDK-8290025: Remove the Sweeper"

-------------

PR: https://git.openjdk.org/jdk/pull/11439

From aboldtch at openjdk.org  Mon Dec  5 06:58:16 2022
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 5 Dec 2022 06:58:16 GMT
Subject: RFR: JDK-8296907: VMError: add optional callstacks,
 siginfo for secondary errors [v12]
In-Reply-To: <oxflPz5qkquAtnkHzN1SvOCysUV7ug1IUebbVK4n8ro=.e9904f64-1e92-41ec-8d8b-953b2d3344ce@github.com>
References: <x1kul17oEaJ-UX6ZGPv8OcsxN8QfYlME_d39aSATk-Q=.f0e0169c-15f5-4b4b-8235-68f8e68ec43c@github.com>
 <oxflPz5qkquAtnkHzN1SvOCysUV7ug1IUebbVK4n8ro=.e9904f64-1e92-41ec-8d8b-953b2d3344ce@github.com>
Message-ID: <G7oAoQqTh_Hnmg8FDAllVhQrK9xiv1rf78v1W-3bMdA=.1f4ea601-89f3-495c-b6eb-3b3d9744066d@github.com>

On Thu, 1 Dec 2022 16:36:25 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> This was motivated by discussions we had in https://github.com/openjdk/jdk/pull/11017.
>> 
>> To aid in analyzing secondary errors during error reporting, it would be useful to see their callstacks for secondary errors. But printing callstacks during error reporting is unsafe - if we get a second crash or assert, it will cause infinite recursion and interrupt error reporting. Also, the hs-err file would be quite verbose. Therefore this feature is optional and limited to debug builds. 
>> 
>> ---
>> 
>> Patch
>> 
>> - adds optional callstack/siginfo printing via debug-only switch `-XX:+ErrorLogSecondaryErrorDetails`.
>> - fixes a bug in secondary error handling where we would use the global scratch buffer recursively (via stringStream); that could lead to confusing output since it is used by the error log stream already. We can print directly to that one instead.
>> - Removed a stray newline from print_native_stack to clean output.
>> - added regression testing for this feature. I removed my name and the bug id from the test since we don't do this anymore (?).
>> - added clarifying comments to the test and code
>> - added SAP copyright to the regression test (we introduced it years ago for JDK-8065895)
>> 
>> Output looks like this:
>> 
>> 
>> $ java ... -XX:+ErrorLogSecondaryErrorDetails
>> 
>> 
>> will produce, for secondary errors, siginfo and call stack.
>> 
>> 
>> [error occurred during error reporting (test secondary crash 1), id 0xb, SIGSEGV (0xb) at pc=0x00007fddfe8a0a61]
>> [siginfo: si_signo: 11 (SIGSEGV), si_code: 128 (SI_KERNEL), si_addr: 0x0000000000000000]
>> [stack: Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0x1ceea61]  VMError::controlled_crash(int)+0x241  (vmError.cpp:1946)
>> V  [libjvm.so+0x1cf413f]  VMError::report(outputStream*, bool)+0x46bf  (vmError.cpp:564)
>> V  [libjvm.so+0x1cf516b]  VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x19b  (vmError.cpp:1709)
>> V  [libjvm.so+0x1cf5e8f]  VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*, char const*, ...)+0x8f  (vmError.cpp:1467)
>> V  [libjvm.so+0x1cf5ec2]  VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*)+0x22  (vmError.cpp:1473)
>> V  [libjvm.so+0x1a549e7]  JVM_handle_linux_signal+0x1f7  (signals_posix.cpp:656)
>> C  [libc.so.6+0x43090]
>> V  [libjvm.so+0x11d6965]  JNI_CreateJavaVM+0x5b5  (jni.cpp:3662)
>> C  [libjli.so+0x4013]  JavaMain+0x93  (java.c:1457)
>> C  [libjli.so+0x800d]  ThreadJavaMain+0xd  (java_md.c:650)
>> ]
>
> Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove unused imports from test
>  - Make ErrorLogSecondaryErrorDetails a diagnostic product flag

Marked as reviewed by aboldtch (Committer).

-------------

PR: https://git.openjdk.org/jdk/pull/11118

From chagedorn at openjdk.org  Mon Dec  5 07:05:54 2022
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 5 Dec 2022 07:05:54 GMT
Subject: RFR: 8294540: Remove Opaque2Node: it is broken and triggers assert
 [v2]
In-Reply-To: <-M1KwwcakWJvHepuB7BR3gBswY3cHCApL_-Gi1MeJIw=.99cc9ff7-76a2-42ac-a58c-afced8bc7a42@github.com>
References: <3j2Rhe5W9Os-yy1Stqlh-h69SIebbVz2_nsfigH5jfY=.fe3c7faa-da70-4064-9687-d791cdc97acf@github.com>
 <-M1KwwcakWJvHepuB7BR3gBswY3cHCApL_-Gi1MeJIw=.99cc9ff7-76a2-42ac-a58c-afced8bc7a42@github.com>
Message-ID: <IpR1B9ozhQ1y20QjOJy9jrXBC7o6Zusb8gL1Iw1CqOE=.d26b8fec-712c-4574-8f33-fcc4d2a2f97b@github.com>

On Fri, 2 Dec 2022 13:29:39 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> As @chhagedorn nicely analyzed, `Opaque2` nodes seem to be broken.
>> https://github.com/openjdk/jdk/pull/10306
>> 
>> **Original idea behing Opaque2**
>> The idea was to avoid loop-exit values to have both the un-incremented phi-value and the incremented one. Having both may mean using 2 registers, where 1 register could be enough if we only carry the incremented value, and simply decrement after the loop. Opaque2 was inserted to prevent optimizations that would optimize (Phi + inc - inc) down to (Phi). We had a pattern (Phi + inc -> Opaque2 -> - inc), so the add/sub do not get collapsed. Many years back, that used to be fine, and we would only remove Opaque2 nodes once no IGVN round was run anymore. But now, we take Opaque2 nodes out of the graph and then run IGVN again, which undoes all of the effort.
>> 
>> **Must remove for now, maybe implement properly later**
>> For now we remove it, because they can trigger asserts, and is simply a rotten optimization. We think that this optimization should probably be done at the very end anyway, after the last IGVN round.
>> 
>> Performance tests indicate that removing it now does not lead to slowdown.
>> 
>> **Analysis of the assert**
>> 
>> In `PhaseIdealLoop::do_unroll`, we check that the main loop has the same limit in the zero-trip-guard as in the loop-exit. For that, we find the `Opaque1` node `opaq` for the zero-trip-guard limit. We compare its input with the `limit` from the loop-exit. This assert is useful, if we change loop-limits we must ensure they are in sync.
>> 
>> https://github.com/openjdk/jdk/blob/8c472e481676ed0ef475c4989477d5714880c59e/src/hotspot/share/opto/loopTransform.cpp#L2227-L2228
>> 
>> Unfortunately, we insert two separate `Opaque2` nodes for the zero-trip-guard and loop-exit in this example.
>> Sequence of events:
>> - We have 2 loops
>> - The second loop is pre-main-post split. The main loop eventually takes the pre-incremented Phi value of the first loop as its loop-limit.
>> - The first loop eventually detects that its pre-incremented Phi value is used, and inserts Opaque2 nodes for every use. Unfortunately, the zero-trip-guard `CmpI` and the loop-exit `CmpI` both are direct uses of that pre-incremented Phi (this is very rare, as it seems, usually there are other operations in between, and then it is a single use, that eventually feeds into zero-trip-guard and loop-exit-check).
>> 
>> ![image](https://user-images.githubusercontent.com/32593061/205263253-b5b811cc-504e-4072-9d10-1bc134964c9d.png)
>
> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review suggestions from Christian

Update looks good!

-------------

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11477

From stuefe at openjdk.org  Mon Dec  5 07:11:05 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 5 Dec 2022 07:11:05 GMT
Subject: RFR: JDK-8296907: VMError: add optional callstacks,
 siginfo for secondary errors [v12]
In-Reply-To: <G7oAoQqTh_Hnmg8FDAllVhQrK9xiv1rf78v1W-3bMdA=.1f4ea601-89f3-495c-b6eb-3b3d9744066d@github.com>
References: <x1kul17oEaJ-UX6ZGPv8OcsxN8QfYlME_d39aSATk-Q=.f0e0169c-15f5-4b4b-8235-68f8e68ec43c@github.com>
 <oxflPz5qkquAtnkHzN1SvOCysUV7ug1IUebbVK4n8ro=.e9904f64-1e92-41ec-8d8b-953b2d3344ce@github.com>
 <G7oAoQqTh_Hnmg8FDAllVhQrK9xiv1rf78v1W-3bMdA=.1f4ea601-89f3-495c-b6eb-3b3d9744066d@github.com>
Message-ID: <6C52bygwi-axPB7w4hdA5inhtgF5q-QwE2tagtp9N3Q=.0ef362b2-cd51-4140-8a48-2dc393fe8855@github.com>

On Mon, 5 Dec 2022 06:55:08 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove unused imports from test
>>  - Make ErrorLogSecondaryErrorDetails a diagnostic product flag
>
> Marked as reviewed by aboldtch (Committer).

Thanks @xmas92 and @schmelter-sap for reviewing!

-------------

PR: https://git.openjdk.org/jdk/pull/11118

From stuefe at openjdk.org  Mon Dec  5 07:13:23 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 5 Dec 2022 07:13:23 GMT
Subject: Integrated: JDK-8296907: VMError: add optional callstacks,
 siginfo for secondary errors
In-Reply-To: <x1kul17oEaJ-UX6ZGPv8OcsxN8QfYlME_d39aSATk-Q=.f0e0169c-15f5-4b4b-8235-68f8e68ec43c@github.com>
References: <x1kul17oEaJ-UX6ZGPv8OcsxN8QfYlME_d39aSATk-Q=.f0e0169c-15f5-4b4b-8235-68f8e68ec43c@github.com>
Message-ID: <SMqFyPo2Yv1jN7sN7qCruQd1bwAjaktxBMsXd3CON1o=.b7e427fb-ac5e-4bf0-9811-5b7e48f3fa82@github.com>

On Sat, 12 Nov 2022 10:52:33 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> This was motivated by discussions we had in https://github.com/openjdk/jdk/pull/11017.
> 
> To aid in analyzing secondary errors during error reporting, it would be useful to see their callstacks for secondary errors. But printing callstacks during error reporting is unsafe - if we get a second crash or assert, it will cause infinite recursion and interrupt error reporting. Also, the hs-err file would be quite verbose. Therefore this feature is optional and limited to debug builds. 
> 
> ---
> 
> Patch
> 
> - adds optional callstack/siginfo printing via debug-only switch `-XX:+ErrorLogSecondaryErrorDetails`.
> - fixes a bug in secondary error handling where we would use the global scratch buffer recursively (via stringStream); that could lead to confusing output since it is used by the error log stream already. We can print directly to that one instead.
> - Removed a stray newline from print_native_stack to clean output.
> - added regression testing for this feature. I removed my name and the bug id from the test since we don't do this anymore (?).
> - added clarifying comments to the test and code
> - added SAP copyright to the regression test (we introduced it years ago for JDK-8065895)
> 
> Output looks like this:
> 
> 
> $ java ... -XX:+ErrorLogSecondaryErrorDetails
> 
> 
> will produce, for secondary errors, siginfo and call stack.
> 
> 
> [error occurred during error reporting (test secondary crash 1), id 0xb, SIGSEGV (0xb) at pc=0x00007fddfe8a0a61]
> [siginfo: si_signo: 11 (SIGSEGV), si_code: 128 (SI_KERNEL), si_addr: 0x0000000000000000]
> [stack: Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x1ceea61]  VMError::controlled_crash(int)+0x241  (vmError.cpp:1946)
> V  [libjvm.so+0x1cf413f]  VMError::report(outputStream*, bool)+0x46bf  (vmError.cpp:564)
> V  [libjvm.so+0x1cf516b]  VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x19b  (vmError.cpp:1709)
> V  [libjvm.so+0x1cf5e8f]  VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*, char const*, ...)+0x8f  (vmError.cpp:1467)
> V  [libjvm.so+0x1cf5ec2]  VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*)+0x22  (vmError.cpp:1473)
> V  [libjvm.so+0x1a549e7]  JVM_handle_linux_signal+0x1f7  (signals_posix.cpp:656)
> C  [libc.so.6+0x43090]
> V  [libjvm.so+0x11d6965]  JNI_CreateJavaVM+0x5b5  (jni.cpp:3662)
> C  [libjli.so+0x4013]  JavaMain+0x93  (java.c:1457)
> C  [libjli.so+0x800d]  ThreadJavaMain+0xd  (java_md.c:650)
> ]

This pull request has now been integrated.

Changeset: 3b3bbe54
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3b3bbe5487c0d86305f953528884b1ee78ca359f
Stats:     108 lines in 5 files changed: 74 ins; 6 del; 28 mod

8296907: VMError: add optional callstacks, siginfo for secondary errors

Reviewed-by: aboldtch, rschmelter

-------------

PR: https://git.openjdk.org/jdk/pull/11118

From stuefe at openjdk.org  Mon Dec  5 08:07:25 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 5 Dec 2022 08:07:25 GMT
Subject: RFR: JDK-8296995: ostream should handle snprintf(3) errors in
 release builds [v2]
In-Reply-To: <lXBQPLCrniDiyp9OAfVdsHq3xVNsxxTWymy_1cSaiHg=.0f341fe2-7bcc-4640-bf2e-0f1883ee22e4@github.com>
References: <lXBQPLCrniDiyp9OAfVdsHq3xVNsxxTWymy_1cSaiHg=.0f341fe2-7bcc-4640-bf2e-0f1883ee22e4@github.com>
Message-ID: <NwPLthMM9usps18JQUWX8lHFpY2BNT83FstuJNcQx78=.aec8d348-c542-4d9b-a735-9a64134807c4@github.com>

> Small fix for a very unlikely problem. 
> 
> All streams in ostream.hpp end up using `os::snprintf()`, which uses `::vsnprintf()`. `vsnprintf(3)`can fail and return -1. 
> 
> The chance for this to happen is small. snprintf errors are usually encoding errors though not always (see third example at https://stackoverflow.com/questions/65334245/what-is-an-encoding-error-for-sprintf-that-should-return-1). I found "%ls" in one place in windows coding, so I am not sure we can always exclude the possibility of wide strings being used in our code base, or that of printing with outside-provided format strings.
> 
> In case of an error, we assert in debug builds. We don't handle this condition in release builds. In release builds this situation later gets misdiagnosed as a buffer overflow because we cast the signedness of the result away (see `outputStream::do_vsnprintf()`). 
> 
> I think it is just safer to handle this condition, especially since the patch is super trivial.
> 
> ---
> 
> Patch : in release builds, we treat this condition as an empty string write. I considered printing a clear marker into the stream instead, e.g. "ENCODING ERROR", and I'm open to suggestions.

Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  JDK-8296995-ostream-handle-sprintf-errors

-------------

Changes: https://git.openjdk.org/jdk/pull/11160/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11160&range=01
  Stats: 33 lines in 2 files changed: 33 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11160.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11160/head:pull/11160

PR: https://git.openjdk.org/jdk/pull/11160

From epeter at openjdk.org  Mon Dec  5 08:31:43 2022
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 5 Dec 2022 08:31:43 GMT
Subject: RFR: 8294540: Remove Opaque2Node: it is broken and triggers assert
 [v2]
In-Reply-To: <6kpmQHPq695Q9QqXCML6zkzs4OuzHPNHpYzAitA7iDQ=.27bec11c-cc07-4f0c-af9a-46bdeae15693@github.com>
References: <3j2Rhe5W9Os-yy1Stqlh-h69SIebbVz2_nsfigH5jfY=.fe3c7faa-da70-4064-9687-d791cdc97acf@github.com>
 <-M1KwwcakWJvHepuB7BR3gBswY3cHCApL_-Gi1MeJIw=.99cc9ff7-76a2-42ac-a58c-afced8bc7a42@github.com>
 <G-dJi1rsa53QGJU1APqYg1DLBTZp1aEz0dXLJBua68s=.fcfc9a14-7677-4725-8e5a-02024d32b4cb@github.com>
 <6kpmQHPq695Q9QqXCML6zkzs4OuzHPNHpYzAitA7iDQ=.27bec11c-cc07-4f0c-af9a-46bdeae15693@github.com>
Message-ID: <UWK1Icky1GlMdci5WBV1v2cYgXkMzjQrDD3XkhHUv_k=.ec03cf9a-528e-4e60-b35b-458fffdca310@github.com>

On Sat, 3 Dec 2022 01:05:22 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> I agree with removal of `Opaque2`.
>> 
>> On side note, please file RFE to rename all `Opaque` nodes to something meaningful.
>> With removal of `Opaque2` numbering is broken. Originally it was only 2 such nodes but now we have 4 and it become hassle to find what they do and why we have so many.
>
>> On side note, please file RFE to rename all `Opaque` nodes to something meaningful. With removal of `Opaque2` numbering is broken. Originally it was only 2 such nodes but now we have 4 and it become hassle to find what they do and why we have so many.
> 
> That is a good idea. I've planned to rename `Opaque4` nodes and get rid of some of their usages in the redesign of the skeleton predicates ([JDK-8288981](https://bugs.openjdk.org/browse/JDK-8288981)). But it could already be done earlier together with renaming the other opaque nodes now that we get rid of `Opaque2` nodes.

Thanks @chhagedorn for the previous investigation into Opaque2, and the review! Thanks @vnkozlov for the review!
I created two RFE, one for re-investigation/re-implementation of Opaque2, and one for renaming of Opaque nodes in general.

-------------

PR: https://git.openjdk.org/jdk/pull/11477

From epeter at openjdk.org  Mon Dec  5 08:33:38 2022
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 5 Dec 2022 08:33:38 GMT
Subject: Integrated: 8294540: Remove Opaque2Node: it is broken and triggers
 assert
In-Reply-To: <3j2Rhe5W9Os-yy1Stqlh-h69SIebbVz2_nsfigH5jfY=.fe3c7faa-da70-4064-9687-d791cdc97acf@github.com>
References: <3j2Rhe5W9Os-yy1Stqlh-h69SIebbVz2_nsfigH5jfY=.fe3c7faa-da70-4064-9687-d791cdc97acf@github.com>
Message-ID: <-kY_ShhAb6DnMlS8w-tgqZ5enbbbbm7GZZDPRLx4jgE=.6fe033c2-4317-44be-810e-2dc1c03c1347@github.com>

On Fri, 2 Dec 2022 09:58:22 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> As @chhagedorn nicely analyzed, `Opaque2` nodes seem to be broken.
> https://github.com/openjdk/jdk/pull/10306
> 
> **Original idea behing Opaque2**
> The idea was to avoid loop-exit values to have both the un-incremented phi-value and the incremented one. Having both may mean using 2 registers, where 1 register could be enough if we only carry the incremented value, and simply decrement after the loop. Opaque2 was inserted to prevent optimizations that would optimize (Phi + inc - inc) down to (Phi). We had a pattern (Phi + inc -> Opaque2 -> - inc), so the add/sub do not get collapsed. Many years back, that used to be fine, and we would only remove Opaque2 nodes once no IGVN round was run anymore. But now, we take Opaque2 nodes out of the graph and then run IGVN again, which undoes all of the effort.
> 
> **Must remove for now, maybe implement properly later**
> For now we remove it, because they can trigger asserts, and is simply a rotten optimization. We think that this optimization should probably be done at the very end anyway, after the last IGVN round.
> 
> Performance tests indicate that removing it now does not lead to slowdown.
> 
> Filed [JDK-8298019](https://bugs.openjdk.org/browse/JDK-8298019) for future investigation / reimplementation.
> 
> **Analysis of the assert**
> 
> In `PhaseIdealLoop::do_unroll`, we check that the main loop has the same limit in the zero-trip-guard as in the loop-exit. For that, we find the `Opaque1` node `opaq` for the zero-trip-guard limit. We compare its input with the `limit` from the loop-exit. This assert is useful, if we change loop-limits we must ensure they are in sync.
> 
> https://github.com/openjdk/jdk/blob/8c472e481676ed0ef475c4989477d5714880c59e/src/hotspot/share/opto/loopTransform.cpp#L2227-L2228
> 
> Unfortunately, we insert two separate `Opaque2` nodes for the zero-trip-guard and loop-exit in this example.
> Sequence of events:
> - We have 2 loops
> - The second loop is pre-main-post split. The main loop eventually takes the pre-incremented Phi value of the first loop as its loop-limit.
> - The first loop eventually detects that its pre-incremented Phi value is used, and inserts Opaque2 nodes for every use. Unfortunately, the zero-trip-guard `CmpI` and the loop-exit `CmpI` both are direct uses of that pre-incremented Phi (this is very rare, as it seems, usually there are other operations in between, and then it is a single use, that eventually feeds into zero-trip-guard and loop-exit-check).
> 
> ![image](https://user-images.githubusercontent.com/32593061/205263253-b5b811cc-504e-4072-9d10-1bc134964c9d.png)

This pull request has now been integrated.

Changeset: 619b68c5
Author:    Emanuel Peter <epeter at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/619b68c5d1908de335cefd536963cadd57472925
Stats:     188 lines in 11 files changed: 1 ins; 172 del; 15 mod

8294540: Remove Opaque2Node: it is broken and triggers assert

Reviewed-by: chagedorn, kvn

-------------

PR: https://git.openjdk.org/jdk/pull/11477

From aboldtch at openjdk.org  Mon Dec  5 09:41:06 2022
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 5 Dec 2022 09:41:06 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v6]
In-Reply-To: <YrObZ-AMkq6SwiXtk_qhke4mFXlyg6BIgqDfdKjScpU=.ae45ca15-24ae-4748-b069-46e34c36e54a@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
 <BlgmU61ejhlUYvDFqS4vdeD-KZPN1Gs93wP91Y0YE74=.f95c84af-7e10-4426-99f6-985c19d36506@github.com>
 <-Gx_fsiwHvInS5q3bAOQAxpaUgj0Qsn015pthmrE5jI=.2adeff80-dfd1-427a-b4a1-a54453dce4aa@github.com>
 <qO8PccVbO_Ro4teqV3uFITYZK7aLxInsCltFgLDpAQ4=.6b04d82d-c68d-4334-beb4-2e05b98435a7@github.com>
 <b4o3tjV_EOG3mUrQYZ5MIeQ-ToFJHdVrBAfMzIWVWz4=.ce32ee96-2a3f-4960-9ef2-0ef56163768f@github.com>
 <fLYyPsnZR7loYYM3-ACxoRd5foarE1R3BWdkBSaNIXU=.5f21974e-29e2-4ccb-a0ca-76185672411f@github.com>
 <s7AynR1CNMKTrOHmAnXRUclYXWScoJTrpLLdH6dhAVQ=.58ed6851-505d-47e7-a2a5-a51ea781fab5@github.com>
 <YrObZ-AMkq6SwiXtk_qhke4mFXlyg6BIgqDfdKjScpU=.ae45ca15-24ae-4748-b069-46e34c36e54a@github.com>
Message-ID: <O-c_pZEBs-xUiMhyPkMiz1DyfasjhTNjF_tgAVfLGMk=.7cd96ad6-22fb-4e91-80e3-fa4f73080256@github.com>

On Sat, 3 Dec 2022 10:22:41 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> FYI: I have verified this also works with GCC version 11.3.0 on linux-riscv64 platform.
>
> Thanks.

How does this behave with respect to alignment?
The previous implementation used 16 which is at least aligned to `std::max_align_t` (for all hotspots build systems?) 
My understanding is that `char space[sizeof (klass)];` is 1-byte aligned, so `dummyObj` may be misaligned.

-------------

PR: https://git.openjdk.org/jdk/pull/10920

From stuefe at openjdk.org  Mon Dec  5 10:04:51 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 5 Dec 2022 10:04:51 GMT
Subject: RFR: JDK-8296360: Track native memory used by zlib via NMT
Message-ID: <WW7_ad6YUZQ26hrK4idngOcwkotxiJr1PAyfP29Lj64=.5779f834-b617-4295-b69e-c37c796f5268@github.com>

This patch adds NMT tracking to the zlib.

*Please note: we currently discuss whether NMT can be expanded across the JDK in this ML discussion [1]. This PR depends on the outcome of that discussion and won't proceed unless greenlighted. But since [1] is stalled, I post the PR for RFR to get some feedback on the code itself and for people to try it out.*

NMT tracks hotspot native allocations but does not cover the JDK (apart from small exceptions). But the native memory
footprint of JDK libraries can be very significant. Recently we had a customer whose zlib footprint went into the ~40GB range. We analyzed the problem with an in-house memory tracker, but things would have been a lot simpler using NMT.

This patch instruments the zlib via zalloc hooks, which is minimally invasive. It does not touch zlib sources, so it works with both the bundled zlib and system zlib. All the instrumentation happens in the JVM zlib wrapper.


-         j.u.zip (deflate) (reserved=624, committed=624)
                            (malloc=624 #3) 
 
-         j.u.zip (inflate) (reserved=221377904, committed=221377904)
                            (malloc=221377904 #60877) 
 
-               Zip (other) (reserved=8163446896, committed=8163446896)
                            (malloc=8163446896 #182622) 


[1] https://mail.openjdk.org/pipermail/core-libs-dev/2022-November/096197.html

-------------

Commit messages:
 - JDK-8296360-Track-native-memory-used-by-zlib-via-NMT

Changes: https://git.openjdk.org/jdk/pull/10988/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10988&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296360
  Stats: 192 lines in 9 files changed: 179 ins; 1 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/10988.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10988/head:pull/10988

PR: https://git.openjdk.org/jdk/pull/10988

From lkorinth at openjdk.org  Mon Dec  5 10:17:18 2022
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 5 Dec 2022 10:17:18 GMT
Subject: RFR: 8296401: ConcurrentHashTable::bulk_delete might miss to
 delete some objects [v2]
In-Reply-To: <rWw3Hb1baG5eslMgFnOdEP1Q4avhfYc3uTpjdB9DaP0=.23f34ff0-eff9-421b-9e70-7f119fd90e5d@github.com>
References: <rWw3Hb1baG5eslMgFnOdEP1Q4avhfYc3uTpjdB9DaP0=.23f34ff0-eff9-421b-9e70-7f119fd90e5d@github.com>
Message-ID: <ORWIi13F7iZdTzskBbnki-fNF_5aqIeZS7Qqy0QHWXs=.c2c28891-fa6a-4b44-b7dc-b1ab89a2fc32@github.com>

> ConcurrentHashTable::bulk_delete might miss to delete some objects if a bucket has more than 256 entries. Current uses of ConcurrentHashTable are not harmed by this behaviour. 
> 
> I modified gtest:ConcurrentHashTable to detect the problem (first commit), and fixed the problem in the code (second commit).
> 
> Tests passes tier1-3.

Leo Korinth has updated the pull request incrementally with two additional commits since the last revision:

 - growable stacked
 - Revert "working!"
   
   This reverts commit 5366f22c7202eaa2182976c084d02e9af4f56de0.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10983/files
  - new: https://git.openjdk.org/jdk/pull/10983/files/5366f22c..4508c0b8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10983&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10983&range=00-01

  Stats: 40 lines in 2 files changed: 7 ins; 4 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/10983.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10983/head:pull/10983

PR: https://git.openjdk.org/jdk/pull/10983

From alanb at openjdk.org  Mon Dec  5 10:21:16 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 5 Dec 2022 10:21:16 GMT
Subject: RFR: JDK-8296360: Track native memory used by zlib via NMT
In-Reply-To: <WW7_ad6YUZQ26hrK4idngOcwkotxiJr1PAyfP29Lj64=.5779f834-b617-4295-b69e-c37c796f5268@github.com>
References: <WW7_ad6YUZQ26hrK4idngOcwkotxiJr1PAyfP29Lj64=.5779f834-b617-4295-b69e-c37c796f5268@github.com>
Message-ID: <KJs409qazlVA8j2QV9nDLmyomZg3s0RTtIEkpWJxK-A=.f0f7a88c-0b68-4601-ab70-8d25c3ae4f88@github.com>

On Fri, 4 Nov 2022 14:35:00 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> This patch adds NMT tracking to the zlib.
> 
> *Please note: we currently discuss whether NMT can be expanded across the JDK in this ML discussion [1]. This PR depends on the outcome of that discussion and won't proceed unless greenlighted. But since [1] is stalled, I post the PR for RFR to get some feedback on the code itself and for people to try it out.*
> 
> NMT tracks hotspot native allocations but does not cover the JDK (apart from small exceptions). But the native memory
> footprint of JDK libraries can be very significant. Recently we had a customer whose zlib footprint went into the ~40GB range. We analyzed the problem with an in-house memory tracker, but things would have been a lot simpler using NMT.
> 
> This patch instruments the zlib via zalloc hooks, which is minimally invasive. It does not touch zlib sources, so it works with both the bundled zlib and system zlib. All the instrumentation happens in the JVM zlib wrapper.
> 
> 
> -         j.u.zip (deflate) (reserved=624, committed=624)
>                             (malloc=624 #3) 
>  
> -         j.u.zip (inflate) (reserved=221377904, committed=221377904)
>                             (malloc=221377904 #60877) 
>  
> -               Zip (other) (reserved=8163446896, committed=8163446896)
>                             (malloc=8163446896 #182622) 
> 
> 
> [1] https://mail.openjdk.org/pipermail/core-libs-dev/2022-November/096197.html

I think it's a bit premature to mark this review. The discussion thread "Extend Native Memory Tracking over the JDK ?" needs more discussion and input from others. We need to be forward looking in those discussions as it is very likely that the JNI functions and memory allocation will move to Panama in the future. Also we need to think about the maintainable and be able to manage catagories in the libs code without needing to add to allocation.hpp - I suspect this is probably something you've thought about already.

-------------

PR: https://git.openjdk.org/jdk/pull/10988

From sjohanss at openjdk.org  Mon Dec  5 10:21:18 2022
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Mon, 5 Dec 2022 10:21:18 GMT
Subject: RFR: 8157023: Integrate NMT with JFR [v2]
In-Reply-To: <loglNHtE7_iO0hs-kzzL02G4cX-6bm81hEduuOCqQuU=.068734c5-3562-4eb2-9b58-a9c592eb26a7@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <7MunRi3rxCpz4mk9VmuV2MixTHklxSKjbuW5SmdiGGU=.31447ad0-1c44-4f45-891d-053bed30ddb7@github.com>
 <nuDi1WCo6b1iHIsKIc5DJEM3gxRbiLvQN1z75QkDivQ=.c34a87c1-32d3-48cf-8201-1f106f03499e@github.com>
 <loglNHtE7_iO0hs-kzzL02G4cX-6bm81hEduuOCqQuU=.068734c5-3562-4eb2-9b58-a9c592eb26a7@github.com>
Message-ID: <PVsAjqoDY7gVuby8MvfooZmEQqikd_R6YOwl_JK7Gf4=.9aa2208a-6ffd-4199-8722-66bf26d03195@github.com>

On Fri, 2 Dec 2022 16:34:41 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> I did some tests and on my box probing 20k threads - if we get ThreadCritical right away - takes about 50-100ms.

Ok, so the summary is stalled that long because somebody is already in a `ThreadCritical` (like registering a new thread stack) or do you mean that the actual baseline (stack-walk) takes that long, so we potentially stall other caller of `ThreadCritical`?

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From mcimadamore at openjdk.org  Mon Dec  5 10:31:52 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 5 Dec 2022 10:31:52 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v39]
In-Reply-To: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
Message-ID: <-V_N0Cvh4J0vKNbBYdFcow9E8yFHRIjya8n69MpDSuY=.9626ee4d-95b6-41e4-b21e-395e79840388@github.com>

> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.org/jeps/434

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Fix Preview annotation for JEP 434

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10872/files
  - new: https://git.openjdk.org/jdk/pull/10872/files/8b5dc0f0..33b834ca

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=38
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=37-38

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10872.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872

PR: https://git.openjdk.org/jdk/pull/10872

From rehn at openjdk.org  Mon Dec  5 10:34:16 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 5 Dec 2022 10:34:16 GMT
Subject: Integrated: 8297864: Dead code elimination
In-Reply-To: <va_DhGhbW7yeCHuFlm1vugbiqYHxZrRsNGhpE61HQ80=.8500833a-60ae-4805-854e-9c0f0bdfe0e4@github.com>
References: <va_DhGhbW7yeCHuFlm1vugbiqYHxZrRsNGhpE61HQ80=.8500833a-60ae-4805-854e-9c0f0bdfe0e4@github.com>
Message-ID: <6fK4qh_ZUc92Dt9fFbM0Pn0uL1A2sU08d9a_FMlZWqw=.7f995c98-c915-4aef-be3e-d18b3dc3801d@github.com>

On Wed, 30 Nov 2022 18:10:09 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Please consider removing all this dead code.
> I did not have any good way of splitting this up and I did not see any benefit is just splitting it up 'just because'.
> There is one commit per file couple.
> Not much else to say, passes t1-4 and I can build:
> linux-aarch64-debug,linux-arm32-debug,linux-ppc64le-debug,linux-s390x-debug,linux-x86,linux-x86-debug,macosx-aarch64-debug,macosx-x64,macosx-x64-debug,windows-x64-debug,windows-x86-debug and zero-x64-debug
> Some of them I also built release.

This pull request has now been integrated.

Changeset: d523d9d0
Author:    Robbin Ehn <rehn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d523d9d081a3bc698abcf493e038779a29eb47ea
Stats:     1058 lines in 100 files changed: 0 ins; 1047 del; 11 mod

8297864: Dead code elimination

Reviewed-by: coleenp, pchilanomate

-------------

PR: https://git.openjdk.org/jdk/pull/11439

From stuefe at openjdk.org  Mon Dec  5 10:41:05 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 5 Dec 2022 10:41:05 GMT
Subject: RFR: 8157023: Integrate NMT with JFR [v2]
In-Reply-To: <PVsAjqoDY7gVuby8MvfooZmEQqikd_R6YOwl_JK7Gf4=.9aa2208a-6ffd-4199-8722-66bf26d03195@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <7MunRi3rxCpz4mk9VmuV2MixTHklxSKjbuW5SmdiGGU=.31447ad0-1c44-4f45-891d-053bed30ddb7@github.com>
 <nuDi1WCo6b1iHIsKIc5DJEM3gxRbiLvQN1z75QkDivQ=.c34a87c1-32d3-48cf-8201-1f106f03499e@github.com>
 <loglNHtE7_iO0hs-kzzL02G4cX-6bm81hEduuOCqQuU=.068734c5-3562-4eb2-9b58-a9c592eb26a7@github.com>
 <PVsAjqoDY7gVuby8MvfooZmEQqikd_R6YOwl_JK7Gf4=.9aa2208a-6ffd-4199-8722-66bf26d03195@github.com>
Message-ID: <Jd2GVvZds__Y6Q3eONsH0mCzwLU3oPmazcHtxJNkKnk=.47c4923d-f2f2-4ebe-9e12-fc57061deb6e@github.com>

On Mon, 5 Dec 2022 10:16:56 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> > I did some tests and on my box probing 20k threads - if we get ThreadCritical right away - takes about 50-100ms.
> 
> Ok, so the summary is stalled that long because somebody is already in a `ThreadCritical` (like registering a new thread stack) or do you mean that the actual baseline (stack-walk) takes that long, so we potentially stall other caller of `ThreadCritical`?

I see both.

I have a test with 20k threads. On my machine time under ThreadCritical fluctuates between 30 and 70 ms (I measured debug before accidentally, this is for a release VM). When there is high thread activity (e.g. 20k threads joining), time until we get ThreadCritical can be up to 20 seconds.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From aboldtch at openjdk.org  Mon Dec  5 10:42:12 2022
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 5 Dec 2022 10:42:12 GMT
Subject: RFR: 8296401: ConcurrentHashTable::bulk_delete might miss to
 delete some objects [v2]
In-Reply-To: <ORWIi13F7iZdTzskBbnki-fNF_5aqIeZS7Qqy0QHWXs=.c2c28891-fa6a-4b44-b7dc-b1ab89a2fc32@github.com>
References: <rWw3Hb1baG5eslMgFnOdEP1Q4avhfYc3uTpjdB9DaP0=.23f34ff0-eff9-421b-9e70-7f119fd90e5d@github.com>
 <ORWIi13F7iZdTzskBbnki-fNF_5aqIeZS7Qqy0QHWXs=.c2c28891-fa6a-4b44-b7dc-b1ab89a2fc32@github.com>
Message-ID: <8b8bHTmw4VI4Lvi-5FX20UFstJN0z_T3SdkkawuHS08=.21c6db38-7ab6-492c-a6c5-b6763d5bd3ea@github.com>

On Mon, 5 Dec 2022 10:17:18 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> ConcurrentHashTable::bulk_delete might miss to delete some objects if a bucket has more than 256 entries. Current uses of ConcurrentHashTable are not harmed by this behaviour. 
>> 
>> I modified gtest:ConcurrentHashTable to detect the problem (first commit), and fixed the problem in the code (second commit).
>> 
>> Tests passes tier1-3.
>
> Leo Korinth has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - growable stacked
>  - Revert "working!"
>    
>    This reverts commit 5366f22c7202eaa2182976c084d02e9af4f56de0.

src/hotspot/share/utilities/concurrentHashTable.inline.hpp line 524:

> 522:     }
> 523:     for (size_t node_it = 0; node_it < nd; node_it++) {
> 524:       Node* ndel = node_it < BULK_DELETE_LIMIT ? ndel_stack[node_it] : extra.at(node_it - BULK_DELETE_LIMIT);

Needs to be a reference (`Node*& ndel`) or `DEBUG_ONLY(ndel = (Node*)POISON_PTR;)` will be a no-op.

-------------

PR: https://git.openjdk.org/jdk/pull/10983

From lkorinth at openjdk.org  Mon Dec  5 10:48:55 2022
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 5 Dec 2022 10:48:55 GMT
Subject: RFR: 8296401: ConcurrentHashTable::bulk_delete might miss to
 delete some objects
In-Reply-To: <srzYQG8vQxXtFu8IYd4LzHoFZo6VR8_D_9e5wlek0u4=.c3fb4829-6de5-428e-9b70-f34aeba9c55f@github.com>
References: <rWw3Hb1baG5eslMgFnOdEP1Q4avhfYc3uTpjdB9DaP0=.23f34ff0-eff9-421b-9e70-7f119fd90e5d@github.com>
 <srzYQG8vQxXtFu8IYd4LzHoFZo6VR8_D_9e5wlek0u4=.c3fb4829-6de5-428e-9b70-f34aeba9c55f@github.com>
Message-ID: <XlpaIj9dRjwUPkQTmLqfWNx7r4afKUu5cE4xUDRwNgw=.96918f61-bb6d-4d92-995d-d763adf6df63@github.com>

On Mon, 7 Nov 2022 21:01:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Thanks for the explanation. What is the point of having a BULK_DELETE_LIMIT?

One advantage is that you can stack allocate the buffer needed to temporary store the pointers. I guess the original idea was to loop, and reuse the stack buffer as I did in my first implementation (now reverted, thanks to comments from Robbin). The problem with doing that is that you can not guarantee progress. If you could find a hash collision, you could possibly fill the bucket faster than the system could empty it. My new implementation will instead of an extra loop, use a growable array  to fill extra data. The new implementation will thus only read the bucket head once, and the problem will not appear.  The growable array is initialized with a  zero argument, which to my understanding of the code does *not* allocate any backing array. Thus I think the code should be almost equally performant on normal cases with a bucket size <= 256. If the user of the hash table has buckets sized above 256, the exponential growing of the extra array will start at a very small size and it will
  not be optimal. It will work, and that is IMO enough. 

I have also tried two other solutions:
1) Using a normal array (but then I need to count the length of the list before allocating, and optionally reuse the predicate function). This will maybe hurt normal usage performance.
2) Dynamically allocate the growable array (only) if we need it. The code was not as good looking although I guess it could be somewhat faster on really big buckets (but then performance really does not matter and we should arguably assert). 

Do you have any good code to benchmark this change?

-------------

PR: https://git.openjdk.org/jdk/pull/10983

From stuefe at openjdk.org  Mon Dec  5 10:52:38 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 5 Dec 2022 10:52:38 GMT
Subject: RFR: 8157023: Integrate NMT with JFR [v2]
In-Reply-To: <7MunRi3rxCpz4mk9VmuV2MixTHklxSKjbuW5SmdiGGU=.31447ad0-1c44-4f45-891d-053bed30ddb7@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <7MunRi3rxCpz4mk9VmuV2MixTHklxSKjbuW5SmdiGGU=.31447ad0-1c44-4f45-891d-053bed30ddb7@github.com>
Message-ID: <rYKc-CYI3PQ-5LpubScCbBHH2kGeRXeygXufuq5kCBw=.78c5ba2c-037b-46b8-a826-366213e557a4@github.com>

On Fri, 2 Dec 2022 15:39:52 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Please review this enhancement to include NMT information in JFR recordings.
>> 
>> **Summary**
>> Native Memory Tracking summary information can be obtained from a running VM using `jcmd` if started with `-XX:NativeMemoryTracking=summary/detail`. Using `jcmd` requires you to run a separate process and to parse the output to get the needed information. This change adds JFR events for NMT information to enable additional ways to consume the NMT data.
>> 
>> There are two new events added:
>> * _NativeMemoryUsage_ - The total native memory usage.
>> * _NativeMemoryUsagePart_ - The native memory usage for each component.
>> 
>> These events are sent periodically and by default the interval is 1s. This can of course be discussed, but that is the staring point. When NMT is not enabled on events will be sent.
>> 
>> **Testing**
>> * Added a simple test to verify that the events are sent as expected depending on if NMT is enabled or not.
>> * Mach5 sanity testing
>
> Stefan Johansson has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Some refactoring after comments
>  - egahlin and carterkozak comments

How about we give you an NMT API which returns the relevant data in one structure and allows to selectively disable some portions of it? That would have some advantages:
- we could "fake" a consistent view by fixing small discrepancies ad-hoc
- you choose how expensive you want to get
- we could hide the nitty gritty of result retrieving (e.g. mtNone, mtChunk handling etc) at least in part from using code like JFR.
- would be reusable.

something like 

struct nmt_data_t {
  malloc_data_t md;  // collection of n malloc counters
  virtmem_data_t vd; // collection of n (reserved/committed) pairs
  threadstack_data_t tsd;  // reserved + committed thread stack size
  int num_threads;
  bool has_md;
  bool has_vd;
  bool has_tsd;
};

void get_nmt_statistics(nmt_data_t* out, options);


You can then leave out more expensive options like thread stacks at will.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From lkorinth at openjdk.org  Mon Dec  5 10:57:17 2022
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 5 Dec 2022 10:57:17 GMT
Subject: RFR: 8296401: ConcurrentHashTable::bulk_delete might miss to
 delete some objects [v2]
In-Reply-To: <ORWIi13F7iZdTzskBbnki-fNF_5aqIeZS7Qqy0QHWXs=.c2c28891-fa6a-4b44-b7dc-b1ab89a2fc32@github.com>
References: <rWw3Hb1baG5eslMgFnOdEP1Q4avhfYc3uTpjdB9DaP0=.23f34ff0-eff9-421b-9e70-7f119fd90e5d@github.com>
 <ORWIi13F7iZdTzskBbnki-fNF_5aqIeZS7Qqy0QHWXs=.c2c28891-fa6a-4b44-b7dc-b1ab89a2fc32@github.com>
Message-ID: <fLVOLqwB1i1y1Johzx5W46EXVzYONX0hp2N4pXejGSM=.7519fa95-4838-48a6-ad17-c61e26ee6a98@github.com>

On Mon, 5 Dec 2022 10:17:18 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> ConcurrentHashTable::bulk_delete might miss to delete some objects if a bucket has more than 256 entries. Current uses of ConcurrentHashTable are not harmed by this behaviour. 
>> 
>> I modified gtest:ConcurrentHashTable to detect the problem (first commit), and fixed the problem in the code (second commit).
>> 
>> Tests passes tier1-3.
>
> Leo Korinth has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - growable stacked
>  - Revert "working!"
>    
>    This reverts commit 5366f22c7202eaa2182976c084d02e9af4f56de0.

And also please check the code carefully, because no normal (java) code will stress it. The added test case of mine will test the code somewhat.

-------------

PR: https://git.openjdk.org/jdk/pull/10983

From sundar at openjdk.org  Mon Dec  5 11:03:15 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Mon, 5 Dec 2022 11:03:15 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v39]
In-Reply-To: <-V_N0Cvh4J0vKNbBYdFcow9E8yFHRIjya8n69MpDSuY=.9626ee4d-95b6-41e4-b21e-395e79840388@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <-V_N0Cvh4J0vKNbBYdFcow9E8yFHRIjya8n69MpDSuY=.9626ee4d-95b6-41e4-b21e-395e79840388@github.com>
Message-ID: <dlBXl0vH7TAofMfxNSZiciwGxWjfx4ieul41FSocySU=.a65380d2-6c91-4ce7-be9a-002c0f4b66f1@github.com>

On Mon, 5 Dec 2022 10:31:52 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.org/jeps/434
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix Preview annotation for JEP 434

LGTM

-------------

Marked as reviewed by sundar (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10872

From rkennke at amazon.de  Mon Dec  5 11:03:18 2022
From: rkennke at amazon.de (Kennke, Roman)
Date: Mon, 5 Dec 2022 12:03:18 +0100
Subject: Extend Native Memory Tracking over the JDK ? (was: Proposal:
 track zlib native memory usage with NMT)
In-Reply-To: <CAA-vtUxB8Z1CD9EYMaMT8OJjw6unwCYd7ONBvQRCVQqO4VTUZQ@mail.gmail.com>
References: <CAA-vtUzvyqb_LZ9d1Z80oSvzyqpi89053O3B+oDZF4oZ85CuZg@mail.gmail.com>
 <c5db2105-3b78-0b77-779f-011c8649f476@oracle.com>
 <CAA-vtUxrP49w523EQ3yKFh4Zo5W+HMtqpGcsUxOEMkwZUOQ0zQ@mail.gmail.com>
 <CAA-vtUxB8Z1CD9EYMaMT8OJjw6unwCYd7ONBvQRCVQqO4VTUZQ@mail.gmail.com>
Message-ID: <5ceac3c4-4cc7-2ce5-822c-0ad498b1c476@amazon.de>

Hi Thomas,

I very much like the idea and also your proposals how to do it. Insights 
in JDK's native memory usage is sorely lacking and would be very useful! 
I don't have all that much to add about the details beyond what you 
already covered, though :-)

Cheers,
Roman


> Are there any opinions about whether or not to extend NMT across the JDK?
> 
> This blocks https://bugs.openjdk.org/browse/JDK-8296360 
> <https://bugs.openjdk.org/browse/JDK-8296360>, and I had a PR prepared 
> as https://github.com/openjdk/jdk/pull/10988 
> <https://github.com/openjdk/jdk/pull/10988>. Originally I was hoping to 
> get this into JDK 20, but I don't think that is realistic anymore. I am 
> fine with postponing my work in favor of a baseline discussion, but so 
> far there is very little discussion about this topic.
> 
> How should I proceed?
> 
> Thanks, Thomas
> 
> 
> 
> On Wed, Nov 9, 2022 at 8:12 AM Thomas St?fe <thomas.stuefe at gmail.com 
> <mailto:thomas.stuefe at gmail.com>> wrote:
> 
>     Hi Alan,
> 
>     (replaced hotspot-runtime-dev with hotspot-dev, since its more of a
>     general topic)
> 
>     thank?you for your time!
> 
>     I am very happy to talk this through. I think native memory
>     observability in the JDK (and customer code!) is sorely lacking.
>     Witness the countless "where did my native memory go" blog articles.
>     At SAP we have been struggling with this topic for a long time and
>     have come up with a mixture of solutions. The aforementioned tracker
>     was one, which extended our version of NMT across the JDK. Our
>     SapMachine MallocTracer, which allows us to trace uninstrumented
>     customer code, another. We even experimented with exchanging the
>     allocator (using jemalloc) to gain insights. But that is a whole
>     different topic with deep logistical implications, I don't want to
>     touch it here. Exchanging the allocator does not help to observe
>     virtual memory or the brk segment, of course.
> 
>     And to make the picture complete, another insight we currently lack
>     is the implicit allocator overhead, which can be very significant
>     and is hidden by the libc. We also have observability for that in
>     the SapMachine, and I miss it in OpenJDK.
> 
>     As you noticed, my original intent was just to instrument Zlib and
>     possibly improve tracking for DBBs. Although, thinking beyond that,
>     another attractive instrumentation target would be mapped NIO
>     buffers at least.
> 
>     So I think native memory observability is important. Arguably we
>     could even extend observability to cover other OS resources, e.g.
>     file handles. If we shift code around, to java/Panama: data that
>     move the java heap does not need to be tracked, but other memory
>     will always come from one of the basic system APIs, regardless of
>     who allocates it and where in the stack allocation happens. Be it
>     native JDK code, Panama, or even customer JNI code.
> 
>     If we agree on the importance of native memory observability, then I
>     believe NMT is the right tool for it. It is a good?tool.?The
>     machinery is already there. It covers both C-heap and virtual memory
>     APIs, as well as thread stacks, and could easily be extended to
>     cover sbrk if needed. And I assume that whatever shape OpenJDK takes
>     on in the future, there always will be a libjvm.so at its core, so
>     we will always have it. But even if not, NMT could be separated from
>     libjvm.so quite easily, since it has no deep ties with the JVM.
> 
>     About coupling JVM with outside code: We don't have to directly link
>     against libjvm.so. We can keep things loose if the intent is to be
>     runnable without a JVM, or be JVM-version-agnostic. That could take
>     the form of a function-pointer interface like JVMTI. Or outside code
>     could dynamically dlsym the JVM allocation hooks. In any case
>     gracefully falling back to system allocation routines when necessary.
> 
>     And I agree, polluting the NMT tag space with outside meaning is
>     ugly. I only did it because I planned to go no further than
>     instrumenting Zlib and possibly DBBs. But if we take this further,
>     my preferred solution would be a reserved tag range or -ranges for
>     outside use, whose?inner meaning would be opaque to the JVM. Kind of
>     like SIGRTMIN+SIGRTMAX. Then, outside code could register tags and
>     their meta information with the JVM, or we find a different way to
>     convey the tag meaning to NMT (config files, or callbacks). That
>     could even be opened up for customer use.
> 
>     This also touches on another question, that of NMT tag space. NMT
>     tags are very useful since they allow cheap tracking without
>     capturing call stacks. However, tags are underused and show growing
>     pains since they are too one-dimensional and restrictive. We had
>     competing interests in the past about tag granularity. It is?all
>     over the place. We have coarse-grained tags like "mtThread", and
>     very fine-grained ones like "mtObjectMonitor". There are several
>     ways we could improve, e.g., by making them combinable like UL does,
>     or allowing for a hierarchy of them - either a hard-wired limited
>     one like "domain"+"tag", or an unlimited tree-like one. Technically
>     interesting since whatever the new encoding is, they still must fit
>     into a malloc header. I opened
>     https://bugs.openjdk.org/browse/JDK-8281819
>     <https://bugs.openjdk.org/browse/JDK-8281819> to track ideas like these.
> 
>     Instrumenting Panama allocations, including the ability to tag
>     allocations, would be a very good idea. For instance, if we ever
>     remove the native Zlib layer and convert it to java using Panama, we
>     can do the same with Panama I do now natively - use the Zlib zalloc
>     interface to hook in JVM memory allocation functions. The result
>     could be completely identical, and the end user looking at the NMT
>     output need never know that anything changed.
> 
>     And that goes for all instrumentation - if today we add it to JNI
>     code, and that code gets removed tomorrow, we can add it to Panama
>     code too. Unless data structures move to the heap, in which case
>     there is no need to track them.
> 
>     You mentioned that NMT was more of an in-house support tool. Our
>     experience is different. Even though it was positioned as a tool for
>     JVM developers, and we never cared for the backward compatibility or
>     consistency, it gets used a *lot* by our customers. We have to
>     explain its output frequently. Also, many blog articles exist
>     documenting its use. So, maybe it would be okay to elevate it to a
>     user-facing tool since it seems to occupy that role anyway. We may
>     also open up consumption of NMT results via java APIs, or expose its
>     results via MXBeans.
> 
>     If this is to be a JEP, okay, but I'm afraid it would stall things a
>     bit. I am interested in getting a simpler and quicker solution for
>     older support releases at?least, possibly based on my PR. I know
>     that would be unconventional though.
> 
>     Thank you,
> 
>     Thomas
> 
> 
>     On Sun, Nov 6, 2022 at 9:31 AM Alan Bateman <Alan.Bateman at oracle.com
>     <mailto:Alan.Bateman at oracle.com>> wrote:
> 
>         On 04/11/2022 16:54, Thomas St?fe wrote:
>          > Hi all,
>          >
>          > I am currently working on
>         https://bugs.openjdk.org/browse/JDK-8296360
>         <https://bugs.openjdk.org/browse/JDK-8296360>;
>          > I was preparing the final PR [1], but then Alan did ask me to
>         discuss
>          > this on core-libs first.
>          >
>          > Backstory:
>          >
>          > NMT tracks hotspot native allocations but does not cover the JDK
>          > libraries (small exception: Unsafe.AllocateMemory). However, the
>          > native memory footprint of JDK libraries can be significant.
>         We have
>          > no in-VM tracker for these and need tools like valgrind or our
>          > SapMachine MallocTracer [2] to observe them.
> 
>         Thanks for starting a discussion on this as this is a topic that
>         requires agreement from several areas. If this is the start of
>         something
>         bigger, where you want to have all allocation sites in the
>         libraries
>         using NMT, then I think it needs a write-up, maybe a JEP.
> 
>         For starters, I think it needs some agreement on using NMT for
>         memory
>         allocated outside of libjvm. You mentioned Unsafe as an
>         exception but
>         that is implemented in the VM so you get tracking for free,
>         albeit I
>         think all allocations are in the "mtOther" category.
> 
>         A general concern is that it creates more coupling between the
>         VM code
>         and the libraries code. As you probably know, we've removed most
>         of the
>         dependences on JVM_* functions from non-core areas over many
>         years. So I
>         think that needs consideration as I assume we don't want
>         memory/allocation.hpp declaring a dozen catagories for
>         allocations done
>         in say java.desktop module for example. Maybe your proposal will be
>         strictly limited to java.base but even then, do we really want
>         the VM
>         even knowing about categories that are specific to zip
>         compression or
>         decompression?
> 
>         There are probably longer term trends that should be part of the
>         discussion too. One general trend is that "run time" is becoming
>         more
>         and more a hybrid of code in libvm and the Java libraries. Lambdas,
>         module system, virtual threads implementations are a few
>         examples in the
>         last few release. This comes with many "Java on Java" challenges,
>         including serviceability where users of the platform will expect
>         tools
>         to just work and won't care where the code is. NMT is probably
>         more for
>         support teams and not something that most developers will ever
>         use but I
>         think is part of the challenge of having serviceability
>         solutions "just
>         work".
> 
>         In addition to having more of the Java runtime written in Java,
>         there
>         will likely be less JNI code in the future. It's very possible
>         that the
>         JNI code (including the JNI methods in libzip) will be replaced
>         with
>         code that uses Panama memory and linker APIs once they are become
>         permanent. The effect of that would to have a lot of the memory
>         allocations be tracked in the mtOther category again. Maybe
>         integration
>         with memory tracking should be looked at in conjunction with
>         these APIs
>         and this migration. I could imagine the proposed "Arena" API
>         (MemorySession in Java 19) having some integration with NMT and
>         it might
>         be interesting to look into that.
> 
>         So yes, this topic does need broader discussion and it might be
>         a bit
>         premature to start with a PR for libzip without talking about
>         the bigger
>         picture first.
> 
>         -Alan
> 
> 
> 



Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879



From iwalulya at openjdk.org  Mon Dec  5 11:04:04 2022
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 5 Dec 2022 11:04:04 GMT
Subject: RFR: 8296401: ConcurrentHashTable::bulk_delete might miss to
 delete some objects
In-Reply-To: <XlpaIj9dRjwUPkQTmLqfWNx7r4afKUu5cE4xUDRwNgw=.96918f61-bb6d-4d92-995d-d763adf6df63@github.com>
References: <rWw3Hb1baG5eslMgFnOdEP1Q4avhfYc3uTpjdB9DaP0=.23f34ff0-eff9-421b-9e70-7f119fd90e5d@github.com>
 <srzYQG8vQxXtFu8IYd4LzHoFZo6VR8_D_9e5wlek0u4=.c3fb4829-6de5-428e-9b70-f34aeba9c55f@github.com>
 <XlpaIj9dRjwUPkQTmLqfWNx7r4afKUu5cE4xUDRwNgw=.96918f61-bb6d-4d92-995d-d763adf6df63@github.com>
Message-ID: <-46D7o9D9hweEylWT61buGVsoYYFZLlKezzaBgt7GvQ=.7e7b3755-98cb-4696-ba07-0ba3b7046a4a@github.com>

On Mon, 5 Dec 2022 10:44:54 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> If the user of the hash table has buckets sized above 256, the exponential growing of the extra array will start at a very small size and it will not be optimal. It will work, and that is IMO enough.

I thought the benefit of having a `BULK_DELETE_LIMIT` was to limit the cleanup done by an individual thread. This effectively limits the duration of the critical section.

-------------

PR: https://git.openjdk.org/jdk/pull/10983

From aboldtch at openjdk.org  Mon Dec  5 11:07:17 2022
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 5 Dec 2022 11:07:17 GMT
Subject: RFR: 8296401: ConcurrentHashTable::bulk_delete might miss to
 delete some objects [v2]
In-Reply-To: <ORWIi13F7iZdTzskBbnki-fNF_5aqIeZS7Qqy0QHWXs=.c2c28891-fa6a-4b44-b7dc-b1ab89a2fc32@github.com>
References: <rWw3Hb1baG5eslMgFnOdEP1Q4avhfYc3uTpjdB9DaP0=.23f34ff0-eff9-421b-9e70-7f119fd90e5d@github.com>
 <ORWIi13F7iZdTzskBbnki-fNF_5aqIeZS7Qqy0QHWXs=.c2c28891-fa6a-4b44-b7dc-b1ab89a2fc32@github.com>
Message-ID: <XZ3F8cy5EA3J_SUQRYR-drN-GpoV6xyQhsSWqdX-3o0=.064697f2-d431-42ed-bd60-688aa50f8b39@github.com>

On Mon, 5 Dec 2022 10:17:18 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> ConcurrentHashTable::bulk_delete might miss to delete some objects if a bucket has more than 256 entries. Current uses of ConcurrentHashTable are not harmed by this behaviour. 
>> 
>> I modified gtest:ConcurrentHashTable to detect the problem (first commit), and fixed the problem in the code (second commit).
>> 
>> Tests passes tier1-3.
>
> Leo Korinth has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - growable stacked
>  - Revert "working!"
>    
>    This reverts commit 5366f22c7202eaa2182976c084d02e9af4f56de0.

src/hotspot/share/utilities/concurrentHashTable.inline.hpp line 993:

> 991:   Node* const volatile * rem_n_prev = bucket->first_ptr();
> 992:   Node* rem_n = bucket->first();
> 993:   for (dels = 0; rem_n != nullptr; ++dels) {

`dels` is incremented even when `eval_f(rem_n->value())` is false. This means that the return value may be overcounting, and there will be uninitialized pointer values in the `ndel` array.

-------------

PR: https://git.openjdk.org/jdk/pull/10983

From sjohanss at openjdk.org  Mon Dec  5 11:33:02 2022
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Mon, 5 Dec 2022 11:33:02 GMT
Subject: RFR: 8157023: Integrate NMT with JFR [v2]
In-Reply-To: <Jd2GVvZds__Y6Q3eONsH0mCzwLU3oPmazcHtxJNkKnk=.47c4923d-f2f2-4ebe-9e12-fc57061deb6e@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <7MunRi3rxCpz4mk9VmuV2MixTHklxSKjbuW5SmdiGGU=.31447ad0-1c44-4f45-891d-053bed30ddb7@github.com>
 <nuDi1WCo6b1iHIsKIc5DJEM3gxRbiLvQN1z75QkDivQ=.c34a87c1-32d3-48cf-8201-1f106f03499e@github.com>
 <loglNHtE7_iO0hs-kzzL02G4cX-6bm81hEduuOCqQuU=.068734c5-3562-4eb2-9b58-a9c592eb26a7@github.com>
 <PVsAjqoDY7gVuby8MvfooZmEQqikd_R6YOwl_JK7Gf4=.9aa2208a-6ffd-4199-8722-66bf26d03195@github.com>
 <Jd2GVvZds__Y6Q3eONsH0mCzwLU3oPmazcHtxJNkKnk=.47c4923d-f2f2-4ebe-9e12-fc57061deb6e@github.com>
Message-ID: <3IRul9fEBgY48bviFGafaXiR3WYpd7JbFofTz9viMnw=.ef28cf0c-c062-41c6-a920-f9b764744c33@github.com>

On Mon, 5 Dec 2022 10:38:40 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> I have a test with 20k threads. On my machine time under ThreadCritical fluctuates between 30 and 70 ms (I measured debug before accidentally, this is for a release VM). When there is high thread activity (e.g. 20k threads joining), time until we get ThreadCritical can be up to 20 seconds.

Yes, looked a bit at the code and having a lot of threads getting created and dying looks problematic. But I assume this would be problematic even without anyone reading the NMT data. A lot of threads being created would still compete for the `ThreadCritical` (when NMT is enabled), right?

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From aph at openjdk.org  Mon Dec  5 11:33:42 2022
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 5 Dec 2022 11:33:42 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v6]
In-Reply-To: <O-c_pZEBs-xUiMhyPkMiz1DyfasjhTNjF_tgAVfLGMk=.7cd96ad6-22fb-4e91-80e3-fa4f73080256@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
 <BlgmU61ejhlUYvDFqS4vdeD-KZPN1Gs93wP91Y0YE74=.f95c84af-7e10-4426-99f6-985c19d36506@github.com>
 <-Gx_fsiwHvInS5q3bAOQAxpaUgj0Qsn015pthmrE5jI=.2adeff80-dfd1-427a-b4a1-a54453dce4aa@github.com>
 <qO8PccVbO_Ro4teqV3uFITYZK7aLxInsCltFgLDpAQ4=.6b04d82d-c68d-4334-beb4-2e05b98435a7@github.com>
 <b4o3tjV_EOG3mUrQYZ5MIeQ-ToFJHdVrBAfMzIWVWz4=.ce32ee96-2a3f-4960-9ef2-0ef56163768f@github.com>
 <fLYyPsnZR7loYYM3-ACxoRd5foarE1R3BWdkBSaNIXU=.5f21974e-29e2-4ccb-a0ca-76185672411f@github.com>
 <s7AynR1CNMKTrOHmAnXRUclYXWScoJTrpLLdH6dhAVQ=.58ed6851-505d-47e7-a2a5-a51ea781fab5@github.com>
 <YrObZ-AMkq6SwiXtk_qhke4mFXlyg6BIgqDfdKjScpU=.ae45ca15-24ae-4748-b069-46e34c36e54a@github.com>
 <O-c_pZEBs-xUiMhyPkMiz1DyfasjhTNjF_tgAVfLGMk=.7cd96ad6-22fb-4e91-80e3-fa4f73080256@github.com>
Message-ID: <v-BZ4nKnRdOdpwUdneFYyFxh8SK98hOBE2dAFUvl9hQ=.f38ddac1-b600-4e38-b583-f016781f4c9a@github.com>

On Mon, 5 Dec 2022 09:38:45 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> How does this behave with respect to alignment? The previous implementation used 16 which is at least aligned to `std::max_align_t` (for all hotspots build systems?) My understanding is that `char space[sizeof (klass)];` is 1-byte aligned, so `dummyObj` may be misaligned.

That's an interesting point. I don't propose to trawl the standard for exact wording, but as far as I recall it's _accesses_ to misaligned members that are problematic.

-------------

PR: https://git.openjdk.org/jdk/pull/10920

From aph at openjdk.org  Mon Dec  5 11:40:05 2022
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 5 Dec 2022 11:40:05 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v6]
In-Reply-To: <ua00w1fE2Z6zjpBjR24B5vVoU2yAcQoSYskNraObfQ4=.76c48947-13ca-44f8-858e-d734da2ec410@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
 <BlgmU61ejhlUYvDFqS4vdeD-KZPN1Gs93wP91Y0YE74=.f95c84af-7e10-4426-99f6-985c19d36506@github.com>
 <ua00w1fE2Z6zjpBjR24B5vVoU2yAcQoSYskNraObfQ4=.76c48947-13ca-44f8-858e-d734da2ec410@github.com>
Message-ID: <uQ96boBKOhNhBEf9AHvwmG4E-xrXwZsLTjGigTKmHQw=.00363382-cec2-4b14-8dc0-0feb2a7909e5@github.com>

On Sun, 4 Dec 2022 15:08:43 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> > Just noticed this PR, and have only skimmed through it. I have an idea for an alternative way to write `offset_of` that I _think_ might be better. I'm going to try it out and report back. That doesn't have to hold you up if you want to proceed.
> 
> That idea for an alternative `offset_of` implementation didn't pan out. And I wasn't able to make disabling the `-Winvalid-offsetof` warning within that macro work. But now I'm wondering why it is being changed? If I take your changes except backout the `offset_of` change, and build with `-fsanitize=null` (for now by co-opting the `--enable-asan` config option, since there's more to it than just adding that option to `--with-extra-cxxflags`), that works (with gcc11.3). So what is the `offset_of` change about?

I saw the warning trigger, or I wouldn't have known that there was any problem. I've been using gcc HEAD to try to get the fullest set of warnings.

I'm pretty sure that

`(size_t)((intx)&(((klass*)16)->field) - 16)`

is no more well defined than

`(size_t)((intx)&(((klass*)0)->field))`

-------------

PR: https://git.openjdk.org/jdk/pull/10920

From rkennke at openjdk.org  Mon Dec  5 11:42:04 2022
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 5 Dec 2022 11:42:04 GMT
Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity
In-Reply-To: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
References: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
Message-ID: <HHco2DtzasIVpdbYmZvz1dJuq9A4N1CTeDsHZxjLM4c=.d1b3091c-9069-4f29-a4e0-78d5e7145c76@github.com>

On Tue, 8 Nov 2022 20:18:09 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details.
> 
> Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements.
> 
> Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16.
> 
> Testing:
>  - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390)
>  - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390)
>  - [x] tier1 (x86_64, x86_32, aarch64, riscv)
>  - [x] tier2 (x86_64, aarch64, riscv)
>  - [x] tier3 (x86_64, riscv)

Hello again,
Would anybody be interested in reviewing this PR?

Thanks,
Roman

-------------

PR: https://git.openjdk.org/jdk/pull/11044

From aph at openjdk.org  Mon Dec  5 12:06:02 2022
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 5 Dec 2022 12:06:02 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v36]
In-Reply-To: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
Message-ID: <Thg5oAO4bkvHbYX2IUVCorreq5h6NKv2buMul9A-sEo=.7f3524d7-94e9-42f4-96e7-9e23181decc7@github.com>

> JEP 429 implementation.

Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 69 commits:

 - Merge https://github.com/openjdk/jdk into JDK-8286666
 - Feedback from reviewers
 - Feedback from reviewers
 - Unused variable
 - Cleanup
 - Cleanup
 - Merge branch 'JDK-8286666' of https://github.com/theRealAph/jdk into JDK-8286666
 - Update src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java
   
   Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>
 - Reviewer feedback
 - Merge branch 'JDK-8286666' of https://github.com/theRealAph/jdk into JDK-8286666
 - ... and 59 more: https://git.openjdk.org/jdk/compare/dea2161f...702d7444

-------------

Changes: https://git.openjdk.org/jdk/pull/10952/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=35
  Stats: 3333 lines in 62 files changed: 2909 ins; 254 del; 170 mod
  Patch: https://git.openjdk.org/jdk/pull/10952.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10952/head:pull/10952

PR: https://git.openjdk.org/jdk/pull/10952

From aph at openjdk.org  Mon Dec  5 12:31:15 2022
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 5 Dec 2022 12:31:15 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v37]
In-Reply-To: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
Message-ID: <gqONKOkeEWYFbAbSNukCiJHu4kEF4UYYyvlyvY_Ijrw=.4ed88dde-08ef-4c4f-b39c-50cbce2bb575@github.com>

> JEP 429 implementation.

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Add comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10952/files
  - new: https://git.openjdk.org/jdk/pull/10952/files/702d7444..dcae81b4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=36
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=35-36

  Stats: 4 lines in 2 files changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10952.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10952/head:pull/10952

PR: https://git.openjdk.org/jdk/pull/10952

From mdoerr at openjdk.org  Mon Dec  5 12:40:47 2022
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 5 Dec 2022 12:40:47 GMT
Subject: RFR: 8291302: ARM32: nmethod entry barriers support
In-Reply-To: <vENPpkRJ7ZlN6k5ymTCUUiESeWfx6ibyJdTpjPMIjvw=.445df16d-28ca-47ec-9a6b-2bbc1cd7ae95@github.com>
References: <BJaszr0_haU4UZOyQQEA9P0SOlgtfTtGFBj9VSRD5SM=.ffd6af56-a51e-4627-90cb-0eb0e1bbd5e8@github.com>
 <vENPpkRJ7ZlN6k5ymTCUUiESeWfx6ibyJdTpjPMIjvw=.445df16d-28ca-47ec-9a6b-2bbc1cd7ae95@github.com>
Message-ID: <MvWj6e6BaqAiu-k1lRqf96Uc16JlbykXsRrNGeLHVkw=.c6ba6c5c-c62b-4f42-a4a3-177ef7826571@github.com>

On Thu, 1 Dec 2022 08:09:42 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> This PR implements nmethod entry barriers for ARM32. It has already been implemented for other ports and is related with JDK-8290025 "Remove the Sweeper".
>
> src/hotspot/cpu/arm/gc/shared/barrierSetNMethod_arm.cpp line 87:
> 
>> 85:    to the interpreter if the nmethod has been unloaded. */
>> 86: void BarrierSetNMethod::deoptimize(nmethod* nm, address* return_address_ptr) {
>> 87: 
> 
> Again if neither ZGC nor ShenandoahGC are supported then you can leave this unimplemented. [`BarrierSetNMethod::nmethod_entry_barrier()`](https://github.com/openjdk/jdk/blob/fa0c599a003962cf3457bb49b9f771659532b5c3/src/hotspot/share/gc/shared/barrierSetNMethod.cpp#L72-L103) never returns false so the single [call site](https://github.com/openjdk/jdk/blob/fa0c599a003962cf3457bb49b9f771659532b5c3/src/hotspot/share/gc/shared/barrierSetNMethod.cpp#L181) cannot be reached unless you want to support `DeoptimizeNMethodBarriersALot` which IMO is not needed without support for ZGC/ShenandoahGC.

Isn't there a jtreg test which triggers the deoptimization somehow?

-------------

PR: https://git.openjdk.org/jdk/pull/11442

From stuefe at openjdk.org  Mon Dec  5 12:42:58 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 5 Dec 2022 12:42:58 GMT
Subject: RFR: 8157023: Integrate NMT with JFR [v2]
In-Reply-To: <3IRul9fEBgY48bviFGafaXiR3WYpd7JbFofTz9viMnw=.ef28cf0c-c062-41c6-a920-f9b764744c33@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <7MunRi3rxCpz4mk9VmuV2MixTHklxSKjbuW5SmdiGGU=.31447ad0-1c44-4f45-891d-053bed30ddb7@github.com>
 <nuDi1WCo6b1iHIsKIc5DJEM3gxRbiLvQN1z75QkDivQ=.c34a87c1-32d3-48cf-8201-1f106f03499e@github.com>
 <loglNHtE7_iO0hs-kzzL02G4cX-6bm81hEduuOCqQuU=.068734c5-3562-4eb2-9b58-a9c592eb26a7@github.com>
 <PVsAjqoDY7gVuby8MvfooZmEQqikd_R6YOwl_JK7Gf4=.9aa2208a-6ffd-4199-8722-66bf26d03195@github.com>
 <Jd2GVvZds__Y6Q3eONsH0mCzwLU3oPmazcHtxJNkKnk=.47c4923d-f2f2-4ebe-9e12-fc57061deb6e@github.com>
 <3IRul9fEBgY48bviFGafaXiR3WYpd7JbFofTz9viMnw=.ef28cf0c-c062-41c6-a920-f9b764744c33@github.com>
Message-ID: <Jqxie2GzROUVqq3n97Xmhd7_-WUosgFS8O8QUDrIl4M=.5d59bcb2-eecc-4dba-83a0-f3fdec460c01@github.com>

On Mon, 5 Dec 2022 11:30:44 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> > I have a test with 20k threads. On my machine time under ThreadCritical fluctuates between 30 and 70 ms (I measured debug before accidentally, this is for a release VM). When there is high thread activity (e.g. 20k threads joining), time until we get ThreadCritical can be up to 20 seconds.
> 
> Yes, looked a bit at the code and having a lot of threads getting created and dying looks problematic. But I assume this would be problematic even without anyone reading the NMT data. A lot of threads being created would still compete for the `ThreadCritical` (when NMT is enabled), right?

Sure, but the time windows are tiny compared to thread stack probing. 

My base concern is that you now use NMT queries in a new context that puts more demands on performance and pause time. With a jcmd, nobody cared if it took two seconds.

One example where this could matter: https://github.com/openjdk/jdk/pull/11401 introduces displaying shareable memory, but only for a single use case (CDS). One could conceivably want to expand on that and display all shareable memory. A very trivial and cool way to implement that would be to ask the OS when printing: is this memory region private or shareable? This would spare us any bookkeeping and print what arguably is the "truth". But this probing depends on the number of memory segments, and may take time, and that may not be admissible if running under JFR.

That is why I think a custom API as I proposed before would be good. Because ~90% of NMT data can be queried without any problems. So you could have a very nice 90% solution now, and for the problem cases like thread stacks we think of something down the road. E.g. a low priority low frequency sampler thread that updates thread stack sizes once per 10 seconds or so. Or that is adaptive wrt number of threads.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From thomas.stuefe at gmail.com  Mon Dec  5 12:43:47 2022
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 5 Dec 2022 13:43:47 +0100
Subject: Extend Native Memory Tracking over the JDK ? (was: Proposal:
 track zlib native memory usage with NMT)
In-Reply-To: <5ceac3c4-4cc7-2ce5-822c-0ad498b1c476@amazon.de>
References: <CAA-vtUzvyqb_LZ9d1Z80oSvzyqpi89053O3B+oDZF4oZ85CuZg@mail.gmail.com>
 <c5db2105-3b78-0b77-779f-011c8649f476@oracle.com>
 <CAA-vtUxrP49w523EQ3yKFh4Zo5W+HMtqpGcsUxOEMkwZUOQ0zQ@mail.gmail.com>
 <CAA-vtUxB8Z1CD9EYMaMT8OJjw6unwCYd7ONBvQRCVQqO4VTUZQ@mail.gmail.com>
 <5ceac3c4-4cc7-2ce5-822c-0ad498b1c476@amazon.de>
Message-ID: <CAA-vtUwBu2PiB-0fxh0HjbEaTU=qpz7kpQ96Ud9qz3MrSsm3xg@mail.gmail.com>

Thank you for the positive encouragement, Roman :-)

Cheers, Thomas

On Mon, Dec 5, 2022 at 12:03 PM Kennke, Roman <rkennke at amazon.de> wrote:

> Hi Thomas,
>
> I very much like the idea and also your proposals how to do it. Insights
> in JDK's native memory usage is sorely lacking and would be very useful!
> I don't have all that much to add about the details beyond what you
> already covered, though :-)
>
> Cheers,
> Roman
>
>
> > Are there any opinions about whether or not to extend NMT across the JDK?
> >
> > This blocks https://bugs.openjdk.org/browse/JDK-8296360
> > <https://bugs.openjdk.org/browse/JDK-8296360>, and I had a PR prepared
> > as https://github.com/openjdk/jdk/pull/10988
> > <https://github.com/openjdk/jdk/pull/10988>. Originally I was hoping to
> > get this into JDK 20, but I don't think that is realistic anymore. I am
> > fine with postponing my work in favor of a baseline discussion, but so
> > far there is very little discussion about this topic.
> >
> > How should I proceed?
> >
> > Thanks, Thomas
> >
> >
> >
> > On Wed, Nov 9, 2022 at 8:12 AM Thomas St?fe <thomas.stuefe at gmail.com
> > <mailto:thomas.stuefe at gmail.com>> wrote:
> >
> >     Hi Alan,
> >
> >     (replaced hotspot-runtime-dev with hotspot-dev, since its more of a
> >     general topic)
> >
> >     thank you for your time!
> >
> >     I am very happy to talk this through. I think native memory
> >     observability in the JDK (and customer code!) is sorely lacking.
> >     Witness the countless "where did my native memory go" blog articles.
> >     At SAP we have been struggling with this topic for a long time and
> >     have come up with a mixture of solutions. The aforementioned tracker
> >     was one, which extended our version of NMT across the JDK. Our
> >     SapMachine MallocTracer, which allows us to trace uninstrumented
> >     customer code, another. We even experimented with exchanging the
> >     allocator (using jemalloc) to gain insights. But that is a whole
> >     different topic with deep logistical implications, I don't want to
> >     touch it here. Exchanging the allocator does not help to observe
> >     virtual memory or the brk segment, of course.
> >
> >     And to make the picture complete, another insight we currently lack
> >     is the implicit allocator overhead, which can be very significant
> >     and is hidden by the libc. We also have observability for that in
> >     the SapMachine, and I miss it in OpenJDK.
> >
> >     As you noticed, my original intent was just to instrument Zlib and
> >     possibly improve tracking for DBBs. Although, thinking beyond that,
> >     another attractive instrumentation target would be mapped NIO
> >     buffers at least.
> >
> >     So I think native memory observability is important. Arguably we
> >     could even extend observability to cover other OS resources, e.g.
> >     file handles. If we shift code around, to java/Panama: data that
> >     move the java heap does not need to be tracked, but other memory
> >     will always come from one of the basic system APIs, regardless of
> >     who allocates it and where in the stack allocation happens. Be it
> >     native JDK code, Panama, or even customer JNI code.
> >
> >     If we agree on the importance of native memory observability, then I
> >     believe NMT is the right tool for it. It is a good tool. The
> >     machinery is already there. It covers both C-heap and virtual memory
> >     APIs, as well as thread stacks, and could easily be extended to
> >     cover sbrk if needed. And I assume that whatever shape OpenJDK takes
> >     on in the future, there always will be a libjvm.so at its core, so
> >     we will always have it. But even if not, NMT could be separated from
> >     libjvm.so quite easily, since it has no deep ties with the JVM.
> >
> >     About coupling JVM with outside code: We don't have to directly link
> >     against libjvm.so. We can keep things loose if the intent is to be
> >     runnable without a JVM, or be JVM-version-agnostic. That could take
> >     the form of a function-pointer interface like JVMTI. Or outside code
> >     could dynamically dlsym the JVM allocation hooks. In any case
> >     gracefully falling back to system allocation routines when necessary.
> >
> >     And I agree, polluting the NMT tag space with outside meaning is
> >     ugly. I only did it because I planned to go no further than
> >     instrumenting Zlib and possibly DBBs. But if we take this further,
> >     my preferred solution would be a reserved tag range or -ranges for
> >     outside use, whose inner meaning would be opaque to the JVM. Kind of
> >     like SIGRTMIN+SIGRTMAX. Then, outside code could register tags and
> >     their meta information with the JVM, or we find a different way to
> >     convey the tag meaning to NMT (config files, or callbacks). That
> >     could even be opened up for customer use.
> >
> >     This also touches on another question, that of NMT tag space. NMT
> >     tags are very useful since they allow cheap tracking without
> >     capturing call stacks. However, tags are underused and show growing
> >     pains since they are too one-dimensional and restrictive. We had
> >     competing interests in the past about tag granularity. It is all
> >     over the place. We have coarse-grained tags like "mtThread", and
> >     very fine-grained ones like "mtObjectMonitor". There are several
> >     ways we could improve, e.g., by making them combinable like UL does,
> >     or allowing for a hierarchy of them - either a hard-wired limited
> >     one like "domain"+"tag", or an unlimited tree-like one. Technically
> >     interesting since whatever the new encoding is, they still must fit
> >     into a malloc header. I opened
> >     https://bugs.openjdk.org/browse/JDK-8281819
> >     <https://bugs.openjdk.org/browse/JDK-8281819> to track ideas like
> these.
> >
> >     Instrumenting Panama allocations, including the ability to tag
> >     allocations, would be a very good idea. For instance, if we ever
> >     remove the native Zlib layer and convert it to java using Panama, we
> >     can do the same with Panama I do now natively - use the Zlib zalloc
> >     interface to hook in JVM memory allocation functions. The result
> >     could be completely identical, and the end user looking at the NMT
> >     output need never know that anything changed.
> >
> >     And that goes for all instrumentation - if today we add it to JNI
> >     code, and that code gets removed tomorrow, we can add it to Panama
> >     code too. Unless data structures move to the heap, in which case
> >     there is no need to track them.
> >
> >     You mentioned that NMT was more of an in-house support tool. Our
> >     experience is different. Even though it was positioned as a tool for
> >     JVM developers, and we never cared for the backward compatibility or
> >     consistency, it gets used a *lot* by our customers. We have to
> >     explain its output frequently. Also, many blog articles exist
> >     documenting its use. So, maybe it would be okay to elevate it to a
> >     user-facing tool since it seems to occupy that role anyway. We may
> >     also open up consumption of NMT results via java APIs, or expose its
> >     results via MXBeans.
> >
> >     If this is to be a JEP, okay, but I'm afraid it would stall things a
> >     bit. I am interested in getting a simpler and quicker solution for
> >     older support releases at least, possibly based on my PR. I know
> >     that would be unconventional though.
> >
> >     Thank you,
> >
> >     Thomas
> >
> >
> >     On Sun, Nov 6, 2022 at 9:31 AM Alan Bateman <Alan.Bateman at oracle.com
> >     <mailto:Alan.Bateman at oracle.com>> wrote:
> >
> >         On 04/11/2022 16:54, Thomas St?fe wrote:
> >          > Hi all,
> >          >
> >          > I am currently working on
> >         https://bugs.openjdk.org/browse/JDK-8296360
> >         <https://bugs.openjdk.org/browse/JDK-8296360>;
> >          > I was preparing the final PR [1], but then Alan did ask me to
> >         discuss
> >          > this on core-libs first.
> >          >
> >          > Backstory:
> >          >
> >          > NMT tracks hotspot native allocations but does not cover the
> JDK
> >          > libraries (small exception: Unsafe.AllocateMemory). However,
> the
> >          > native memory footprint of JDK libraries can be significant.
> >         We have
> >          > no in-VM tracker for these and need tools like valgrind or our
> >          > SapMachine MallocTracer [2] to observe them.
> >
> >         Thanks for starting a discussion on this as this is a topic that
> >         requires agreement from several areas. If this is the start of
> >         something
> >         bigger, where you want to have all allocation sites in the
> >         libraries
> >         using NMT, then I think it needs a write-up, maybe a JEP.
> >
> >         For starters, I think it needs some agreement on using NMT for
> >         memory
> >         allocated outside of libjvm. You mentioned Unsafe as an
> >         exception but
> >         that is implemented in the VM so you get tracking for free,
> >         albeit I
> >         think all allocations are in the "mtOther" category.
> >
> >         A general concern is that it creates more coupling between the
> >         VM code
> >         and the libraries code. As you probably know, we've removed most
> >         of the
> >         dependences on JVM_* functions from non-core areas over many
> >         years. So I
> >         think that needs consideration as I assume we don't want
> >         memory/allocation.hpp declaring a dozen catagories for
> >         allocations done
> >         in say java.desktop module for example. Maybe your proposal will
> be
> >         strictly limited to java.base but even then, do we really want
> >         the VM
> >         even knowing about categories that are specific to zip
> >         compression or
> >         decompression?
> >
> >         There are probably longer term trends that should be part of the
> >         discussion too. One general trend is that "run time" is becoming
> >         more
> >         and more a hybrid of code in libvm and the Java libraries.
> Lambdas,
> >         module system, virtual threads implementations are a few
> >         examples in the
> >         last few release. This comes with many "Java on Java" challenges,
> >         including serviceability where users of the platform will expect
> >         tools
> >         to just work and won't care where the code is. NMT is probably
> >         more for
> >         support teams and not something that most developers will ever
> >         use but I
> >         think is part of the challenge of having serviceability
> >         solutions "just
> >         work".
> >
> >         In addition to having more of the Java runtime written in Java,
> >         there
> >         will likely be less JNI code in the future. It's very possible
> >         that the
> >         JNI code (including the JNI methods in libzip) will be replaced
> >         with
> >         code that uses Panama memory and linker APIs once they are become
> >         permanent. The effect of that would to have a lot of the memory
> >         allocations be tracked in the mtOther category again. Maybe
> >         integration
> >         with memory tracking should be looked at in conjunction with
> >         these APIs
> >         and this migration. I could imagine the proposed "Arena" API
> >         (MemorySession in Java 19) having some integration with NMT and
> >         it might
> >         be interesting to look into that.
> >
> >         So yes, this topic does need broader discussion and it might be
> >         a bit
> >         premature to start with a PR for libzip without talking about
> >         the bigger
> >         picture first.
> >
> >         -Alan
> >
> >
> >
>
>
>
> Amazon Development Center Germany GmbH
> Krausenstr. 38
> 10117 Berlin
> Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
> Sitz: Berlin
> Ust-ID: DE 289 237 879
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20221205/24f5e52d/attachment-0001.htm>

From xlinzheng at openjdk.org  Mon Dec  5 12:47:17 2022
From: xlinzheng at openjdk.org (Xiaolin Zheng)
Date: Mon, 5 Dec 2022 12:47:17 GMT
Subject: Integrated: 8297763: Fix missing stub code expansion before align() in
 shared trampolines
In-Reply-To: <T5fCT6B-2hhjmlMaRuu5iHfMI-gxkuFJp3jtjGh7ZtM=.719d411d-da4f-482b-af14-c9caee93b865@github.com>
References: <T5fCT6B-2hhjmlMaRuu5iHfMI-gxkuFJp3jtjGh7ZtM=.719d411d-da4f-482b-af14-c9caee93b865@github.com>
Message-ID: <9fhjZfzbcrn5nKaBTlKqRtyD7oK9dE-jUNsm5NdD2jw=.d5d7e1f1-13f4-4d35-bf72-e1aa31bfd776@github.com>

On Tue, 29 Nov 2022 13:43:20 GMT, Xiaolin Zheng <xlinzheng at openjdk.org> wrote:

> This patch fixes missing stub code expansion logic before `align()` for AArch64 and RISC-V.
> 
> The `align()` at most creates 4-byte padding, so a `NativeInstruction::instruction_size` is enough.
> 
> I am considering pre-calculating the total trampoline sizes and allocating them in batches, but maybe after this one, for this is a quick fix to unblock https://github.com/openjdk/jdk/pull/11188. Please see that thread.
> 
> The `assert_alignment(pc());` added in the RISC-V part shows that RVC doesn't change the trampoline stub / static stub logic, so there is no need to adjust the trampoline size for it. [1]
> 
> Tested AArch64 hotspot tier1~3, and 4 is still running; tested RISC-V hotspot tier1~2, and 3~4 are still running.
> 
> Thanks,
> Xiaolin
> 
> [1] https://github.com/openjdk/jdk/blob/2deb318c9f047ec5a4b160d66a4b52f93688ec42/src/hotspot/cpu/riscv/macroAssembler_riscv.cpp#L3125-L3126

This pull request has now been integrated.

Changeset: f9e0f1d5
Author:    Xiaolin Zheng <xlinzheng at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f9e0f1d5b3663db5de0532e9d9ce41312bf35ed3
Stats:     19 lines in 3 files changed: 17 ins; 0 del; 2 mod

8297763: Fix missing stub code expansion before align() in shared trampolines

Reviewed-by: fyang, luhenry

-------------

PR: https://git.openjdk.org/jdk/pull/11414

From sjohanss at openjdk.org  Mon Dec  5 12:56:11 2022
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Mon, 5 Dec 2022 12:56:11 GMT
Subject: RFR: 8157023: Integrate NMT with JFR [v2]
In-Reply-To: <7MunRi3rxCpz4mk9VmuV2MixTHklxSKjbuW5SmdiGGU=.31447ad0-1c44-4f45-891d-053bed30ddb7@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <7MunRi3rxCpz4mk9VmuV2MixTHklxSKjbuW5SmdiGGU=.31447ad0-1c44-4f45-891d-053bed30ddb7@github.com>
Message-ID: <6AbCj6BP2IGbslCOEgYc3rwClN1b8wCmNaPpC_FMutI=.c29988a7-fed1-4614-9d3d-ca3973068d82@github.com>

On Fri, 2 Dec 2022 15:39:52 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Please review this enhancement to include NMT information in JFR recordings.
>> 
>> **Summary**
>> Native Memory Tracking summary information can be obtained from a running VM using `jcmd` if started with `-XX:NativeMemoryTracking=summary/detail`. Using `jcmd` requires you to run a separate process and to parse the output to get the needed information. This change adds JFR events for NMT information to enable additional ways to consume the NMT data.
>> 
>> There are two new events added:
>> * _NativeMemoryUsage_ - The total native memory usage.
>> * _NativeMemoryUsagePart_ - The native memory usage for each component.
>> 
>> These events are sent periodically and by default the interval is 1s. This can of course be discussed, but that is the staring point. When NMT is not enabled on events will be sent.
>> 
>> **Testing**
>> * Added a simple test to verify that the events are sent as expected depending on if NMT is enabled or not.
>> * Mach5 sanity testing
>
> Stefan Johansson has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Some refactoring after comments
>  - egahlin and carterkozak comments

This message somehow slipped past me.

> How about we give you an NMT API which returns the relevant data in one structure and allows to selectively disable some portions of it? That would have some advantages:
> 
>     * we could "fake" a consistent view by fixing small discrepancies ad-hoc
> 
>     * you choose how expensive you want to get
> 
>     * we could hide the nitty gritty of result retrieving (e.g. mtNone, mtChunk handling etc) at least in part from using code like JFR.
> 
>     * would be reusable.
> 
> 
> something like
> 
> ```
> struct nmt_data_t {
>   malloc_data_t md;  // collection of n malloc counters
>   virtmem_data_t vd; // collection of n (reserved/committed) pairs
>   threadstack_data_t tsd;  // reserved + committed thread stack size
>   int num_threads;
>   bool has_md;
>   bool has_vd;
>   bool has_tsd;
> };
> 
> void get_nmt_statistics(nmt_data_t* out, options);
> ```
> 
> You can then leave out more expensive options like thread stacks at will.

I like this, its along the same lines as what I've been thinking about as a potential solution. But I was thinking about always skipping threadstacks to make it simple and maybe try to fit it into the existing "baseline" abstraction. But this type of API would certainly fit my needs much better.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From lkorinth at openjdk.org  Mon Dec  5 13:00:47 2022
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 5 Dec 2022 13:00:47 GMT
Subject: RFR: 8296401: ConcurrentHashTable::bulk_delete might miss to
 delete some objects [v2]
In-Reply-To: <XZ3F8cy5EA3J_SUQRYR-drN-GpoV6xyQhsSWqdX-3o0=.064697f2-d431-42ed-bd60-688aa50f8b39@github.com>
References: <rWw3Hb1baG5eslMgFnOdEP1Q4avhfYc3uTpjdB9DaP0=.23f34ff0-eff9-421b-9e70-7f119fd90e5d@github.com>
 <ORWIi13F7iZdTzskBbnki-fNF_5aqIeZS7Qqy0QHWXs=.c2c28891-fa6a-4b44-b7dc-b1ab89a2fc32@github.com>
 <XZ3F8cy5EA3J_SUQRYR-drN-GpoV6xyQhsSWqdX-3o0=.064697f2-d431-42ed-bd60-688aa50f8b39@github.com>
Message-ID: <qoV_ABB5MTpeZU2WfYZ-a3mKk-hy-bSYZgqi02KTuXI=.7f429a41-63af-433d-b885-5c43da699bae@github.com>

On Mon, 5 Dec 2022 11:05:02 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - growable stacked
>>  - Revert "working!"
>>    
>>    This reverts commit 5366f22c7202eaa2182976c084d02e9af4f56de0.
>
> src/hotspot/share/utilities/concurrentHashTable.inline.hpp line 993:
> 
>> 991:   Node* const volatile * rem_n_prev = bucket->first_ptr();
>> 992:   Node* rem_n = bucket->first();
>> 993:   for (dels = 0; rem_n != nullptr; ++dels) {
> 
> `dels` is incremented even when `eval_f(rem_n->value())` is false. This means that the return value may be overcounting, and there will be uninitialized pointer values in the `ndel` array.

Thanks! that was bad from my part :-(

-------------

PR: https://git.openjdk.org/jdk/pull/10983

From stuefe at openjdk.org  Mon Dec  5 13:03:42 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 5 Dec 2022 13:03:42 GMT
Subject: RFR: 8157023: Integrate NMT with JFR [v2]
In-Reply-To: <6AbCj6BP2IGbslCOEgYc3rwClN1b8wCmNaPpC_FMutI=.c29988a7-fed1-4614-9d3d-ca3973068d82@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <7MunRi3rxCpz4mk9VmuV2MixTHklxSKjbuW5SmdiGGU=.31447ad0-1c44-4f45-891d-053bed30ddb7@github.com>
 <6AbCj6BP2IGbslCOEgYc3rwClN1b8wCmNaPpC_FMutI=.c29988a7-fed1-4614-9d3d-ca3973068d82@github.com>
Message-ID: <_4A_Rv8UojxKHnINj75a1IKTupJnHpz5bMXT57shP7s=.282028c3-6836-48f9-9936-9a26ef4c3c7d@github.com>

On Mon, 5 Dec 2022 12:53:52 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> I like this, its along the same lines as what I've been thinking about as a potential solution. But I was thinking about always skipping threadstacks to make it simple and maybe try to fit it into the existing "baseline" abstraction. But this type of API would certainly fit my needs much better.

Wanna do it, or should I do it in a separate RFR and you wait for me? Not sure if you plan to bring this into JDK20. Time's ticking...

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From duke at openjdk.org  Mon Dec  5 10:57:27 2022
From: duke at openjdk.org (Afshin Zafari)
Date: Mon, 5 Dec 2022 10:57:27 GMT
Subject: RFR: 8297766: Remove UseMallocOnly development option [v2]
In-Reply-To: <34gopg6h0xMvkDTyTltghkTZPl4IZdODxcCJMKN-Ki8=.8117d9d7-9325-482d-b232-49ca862413b2@github.com>
References: <34gopg6h0xMvkDTyTltghkTZPl4IZdODxcCJMKN-Ki8=.8117d9d7-9325-482d-b232-49ca862413b2@github.com>
Message-ID: <pQbc72b3ilccJRpjxMltE5V_syPvoK1U6MwBq9G8A3M=.a0362976-7cf7-4fe6-ace2-3499fde7374f@github.com>

> ### Description
> The UseMallocOnly development option was originally used to detect memory stomping bugs with Arena allocations when the JVM was first in development.
> 
> The option has had a few bugs and is not in general use. There are ideas to add another way of Arena canary checking.
> 
> ### Patch:
> All occurrences of UseMallocOnly are removed.
> 
> ### Tests:
> Local, gTests: resourceArea and Arena
> Mach5: tier1-5

Afshin Zafari 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 four additional commits since the last revision:

 - 8297766: Remove UseMallocOnly development option
 - 8297766: Remove UseMallocOnly development option
 - 8297766: Remove UseMallocOnly development option
 - UseMallocOnly instances are removed

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11456/files
  - new: https://git.openjdk.org/jdk/pull/11456/files/0ab592bd..6cdd0b70

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11456&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11456&range=00-01

  Stats: 17317 lines in 369 files changed: 3045 ins; 13746 del; 526 mod
  Patch: https://git.openjdk.org/jdk/pull/11456.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11456/head:pull/11456

PR: https://git.openjdk.org/jdk/pull/11456

From duke at openjdk.org  Mon Dec  5 13:08:24 2022
From: duke at openjdk.org (Afshin Zafari)
Date: Mon, 5 Dec 2022 13:08:24 GMT
Subject: RFR: 8297766: Remove UseMallocOnly development option
In-Reply-To: <hg-ZpDojo2ibQJ00O34Xafr0UJzKXiJySycU0g8sEGs=.cea3fc04-2b1b-426f-88b9-8dcf0bd0b400@github.com>
References: <34gopg6h0xMvkDTyTltghkTZPl4IZdODxcCJMKN-Ki8=.8117d9d7-9325-482d-b232-49ca862413b2@github.com>
 <kZNcQmsVKua913uXhtBfoQUfzgMuaWc4_X2llFhsRbw=.d1f51e18-2326-49e1-953e-3a04a08bdf33@github.com>
 <hg-ZpDojo2ibQJ00O34Xafr0UJzKXiJySycU0g8sEGs=.cea3fc04-2b1b-426f-88b9-8dcf0bd0b400@github.com>
Message-ID: <vuoGBUlCnk50E5aaCy0RWxCSkAjEIPgWGDhrI_6Swec=.a8e49fae-d26f-4d3f-a5af-6ecf78135ddb@github.com>

On Fri, 2 Dec 2022 20:59:28 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> I added real_allocate_handle() - I don't see why not keep it, with the comment about UseMallocOnly removed.

The UseMallocOnly in the comment is removed.

-------------

PR: https://git.openjdk.org/jdk/pull/11456

From stuefe at openjdk.org  Mon Dec  5 13:08:27 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 5 Dec 2022 13:08:27 GMT
Subject: RFR: 8297766: Remove UseMallocOnly development option [v2]
In-Reply-To: <pQbc72b3ilccJRpjxMltE5V_syPvoK1U6MwBq9G8A3M=.a0362976-7cf7-4fe6-ace2-3499fde7374f@github.com>
References: <34gopg6h0xMvkDTyTltghkTZPl4IZdODxcCJMKN-Ki8=.8117d9d7-9325-482d-b232-49ca862413b2@github.com>
 <pQbc72b3ilccJRpjxMltE5V_syPvoK1U6MwBq9G8A3M=.a0362976-7cf7-4fe6-ace2-3499fde7374f@github.com>
Message-ID: <MBBu9GB6YCwa9PMB5FVXWysRXdH9KIdqbljQlcS9RD8=.5a84fc8e-369a-4f94-8311-859adb2d2c0b@github.com>

On Mon, 5 Dec 2022 10:57:27 GMT, Afshin Zafari <duke at openjdk.org> wrote:

>> ### Description
>> The UseMallocOnly development option was originally used to detect memory stomping bugs with Arena allocations when the JVM was first in development.
>> 
>> The option has had a few bugs and is not in general use. There are ideas to add another way of Arena canary checking.
>> 
>> ### Patch:
>> All occurrences of UseMallocOnly are removed.
>> 
>> ### Tests:
>> Local, gTests: resourceArea and Arena
>> Mach5: tier1-5
>
> Afshin Zafari 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 four additional commits since the last revision:
> 
>  - 8297766: Remove UseMallocOnly development option
>  - 8297766: Remove UseMallocOnly development option
>  - 8297766: Remove UseMallocOnly development option
>  - UseMallocOnly instances are removed

Thank you! Looks good to me. I can sponsor for you, but I believe you need integrate first.

-------------

PR: https://git.openjdk.org/jdk/pull/11456

From xlinzheng at openjdk.org  Mon Dec  5 13:09:11 2022
From: xlinzheng at openjdk.org (Xiaolin Zheng)
Date: Mon, 5 Dec 2022 13:09:11 GMT
Subject: RFR: 8297763: Fix missing stub code expansion before align() in
 shared trampolines [v2]
In-Reply-To: <QOm1rf2yvHIVvNhyiPG97YQOX-_5j1VjLoYKbl20lEQ=.98674f31-37eb-4967-bcfe-caad03b5d9ba@github.com>
References: <T5fCT6B-2hhjmlMaRuu5iHfMI-gxkuFJp3jtjGh7ZtM=.719d411d-da4f-482b-af14-c9caee93b865@github.com>
 <QOm1rf2yvHIVvNhyiPG97YQOX-_5j1VjLoYKbl20lEQ=.98674f31-37eb-4967-bcfe-caad03b5d9ba@github.com>
Message-ID: <uipT5yGjDpmysKn6Jprey0MKDO8uZV082HQ0gfRqw1k=.611f1918-97ba-4edc-aab9-e4e5f0333396@github.com>

On Wed, 30 Nov 2022 11:37:58 GMT, Xiaolin Zheng <xlinzheng at openjdk.org> wrote:

>> This patch fixes missing stub code expansion logic before `align()` for AArch64 and RISC-V.
>> 
>> The `align()` at most creates 4-byte padding, so a `NativeInstruction::instruction_size` is enough.
>> 
>> I am considering pre-calculating the total trampoline sizes and allocating them in batches, but maybe after this one, for this is a quick fix to unblock https://github.com/openjdk/jdk/pull/11188. Please see that thread.
>> 
>> The `assert_alignment(pc());` added in the RISC-V part shows that RVC doesn't change the trampoline stub / static stub logic, so there is no need to adjust the trampoline size for it. [1]
>> 
>> Tested AArch64 hotspot tier1~3, and 4 is still running; tested RISC-V hotspot tier1~2, and 3~4 are still running.
>> 
>> Thanks,
>> Xiaolin
>> 
>> [1] https://github.com/openjdk/jdk/blob/2deb318c9f047ec5a4b160d66a4b52f93688ec42/src/hotspot/cpu/riscv/macroAssembler_riscv.cpp#L3125-L3126
>
> Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix as to comments

Thank you, Tobias!

-------------

PR: https://git.openjdk.org/jdk/pull/11414

From sjohanss at openjdk.org  Mon Dec  5 13:11:11 2022
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Mon, 5 Dec 2022 13:11:11 GMT
Subject: RFR: 8157023: Integrate NMT with JFR [v2]
In-Reply-To: <_4A_Rv8UojxKHnINj75a1IKTupJnHpz5bMXT57shP7s=.282028c3-6836-48f9-9936-9a26ef4c3c7d@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <7MunRi3rxCpz4mk9VmuV2MixTHklxSKjbuW5SmdiGGU=.31447ad0-1c44-4f45-891d-053bed30ddb7@github.com>
 <6AbCj6BP2IGbslCOEgYc3rwClN1b8wCmNaPpC_FMutI=.c29988a7-fed1-4614-9d3d-ca3973068d82@github.com>
 <_4A_Rv8UojxKHnINj75a1IKTupJnHpz5bMXT57shP7s=.282028c3-6836-48f9-9936-9a26ef4c3c7d@github.com>
Message-ID: <2jYwtMYh04GDyfNZBj8uqoG5wMmDDK3S3oQnr7fwhGU=.db88199a-9a15-451e-919a-ad2777845998@github.com>

On Mon, 5 Dec 2022 13:01:26 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > I like this, its along the same lines as what I've been thinking about as a potential solution. But I was thinking about always skipping threadstacks to make it simple and maybe try to fit it into the existing "baseline" abstraction. But this type of API would certainly fit my needs much better.
> 
> Wanna do it, or should I do it in a separate RFR and you wait for me? Not sure if you plan to bring this into JDK20. Time's ticking...

Would be nice with JDK20 =) Including it in this one would be quickest, but a separate PR would be the cleanest solution. At the same time, adding an API without any usage can some times raise more questions.

I can take a stab at it. Only thing I'm not clear about exactly what you mean is:
we could hide the nitty gritty of result retrieving (e.g. mtNone, mtChunk handling etc) at least in part from using code like JFR.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From eosterlund at openjdk.org  Mon Dec  5 13:12:13 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 5 Dec 2022 13:12:13 GMT
Subject: RFR: 8297235: ZGC: assert(regs[i] != regs[j]) failed: Multiple
 uses of register: rax
In-Reply-To: <jYsSVWwRPyRKvs8HYIwp6Ar5Z0XISOwp1DM4A0AgdOQ=.378c74fb-a4e1-45a5-82b0-838c2fcba43a@github.com>
References: <jYsSVWwRPyRKvs8HYIwp6Ar5Z0XISOwp1DM4A0AgdOQ=.378c74fb-a4e1-45a5-82b0-838c2fcba43a@github.com>
Message-ID: <Necyf3ZKH2QnClJ_g3qBpS9ZNjMDGY_ZPu2z83KFZiY=.3adb5615-db8c-4a63-98e6-0af2df922742@github.com>

On Tue, 29 Nov 2022 09:50:11 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Tests java/util/stream/test/org/openjdk/tests/java/util/* with -XX:+UseZGC -Xcomp -XX:-TieredCompilation crashes with `assert(regs[i] != regs[j]) failed: Multiple uses of register: rax`. More specifically compilation of java.util.concurrent.ForkJoinTask::awaitDone.
> 
> The reason seems to be that the compare value and the memory input ends up sharing a register. (Uses Unsafe CAS which CAS an object reference into a field of that object, `oldval: rax` and `mem: [rax+offset]`). The Z load barrier stub dispatch implementation require that the reference and reference address occupy distinct registers. In the loadP nodes this is established by marking all but the memory TEMP which results in no sharing.
> 
> This is not possible for the CompareAndSwapP / CompareAndExchangeP nodes as the compare value is an input node. 
> 
> The solution proposed here is less than ideal as it makes the CAS nodes require one extra TEMP register, which in the common case is unused. This puts unnecessary extra strain on the register allocation. The problem is that there is no way currently (that I can find) to express in .ad that a memory input must not share registers with a specific other input. 
> 
> There is an alternative solution for this specific crash which does not use a second TEMP register (see commit: cfd5ced4e97e986fc10c5a8721b543cd3101c58a). It accomplish this by using the same trick that the aarch64 Z CAS node uses which is to specify the memory as indirect which results in the address being LEA into a register. However from what I can see this does not guarantee that the address and the reference does not share a register (`oldval: rax` and `mem: [rax]`). So it is theoretically broken, (and so is the aarch64 implementation). 
> 
> It is unclear to me if there is ever a way for C2 to generation a CAS which compares the address of the field with its content. 
> 
> I call on anyone with more knowledge about `adlc` and `C2` for feedback. And specifically I want to open up a discussion with these points:
> * Is there some other way of expressing in the .ad file that a memory input should not share some register?
>   * If not, is this a worthwhile RFE? As it seems to be a patterned used at least in other places in Z.
> * Will the indirect input ever share a register with oldval and/or are the aarch64/riscv implementations broken because of this? How about ppc?
> 
> Testing: linux-x64 zgc tagged tests tier 1-7 and some specific crashing tests with `-XX:+UseZGC -Xcomp -XX:-TieredCompilation` (in: java/util/stream/, java/util/concurrent/)

I think that changing memory to indirect in the mach node matching solves the conjoint register problem. The address then becomes a field, and the type of the expected value is an oop. For them to be the same register would be seemingly impossible.

-------------

PR: https://git.openjdk.org/jdk/pull/11410

From lkorinth at openjdk.org  Mon Dec  5 13:12:25 2022
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 5 Dec 2022 13:12:25 GMT
Subject: RFR: 8296401: ConcurrentHashTable::bulk_delete might miss to
 delete some objects [v3]
In-Reply-To: <rWw3Hb1baG5eslMgFnOdEP1Q4avhfYc3uTpjdB9DaP0=.23f34ff0-eff9-421b-9e70-7f119fd90e5d@github.com>
References: <rWw3Hb1baG5eslMgFnOdEP1Q4avhfYc3uTpjdB9DaP0=.23f34ff0-eff9-421b-9e70-7f119fd90e5d@github.com>
Message-ID: <Cev5LpXT4yrKeAETGjEFXJUibd1vgPb1z8Pch20m0ec=.524f5887-294e-4c7d-a2f1-05e4667399ab@github.com>

> ConcurrentHashTable::bulk_delete might miss to delete some objects if a bucket has more than 256 entries. Current uses of ConcurrentHashTable are not harmed by this behaviour. 
> 
> I modified gtest:ConcurrentHashTable to detect the problem (first commit), and fixed the problem in the code (second commit).
> 
> Tests passes tier1-3.

Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:

  fix counting bug

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10983/files
  - new: https://git.openjdk.org/jdk/pull/10983/files/4508c0b8..1292acbf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10983&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10983&range=01-02

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10983.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10983/head:pull/10983

PR: https://git.openjdk.org/jdk/pull/10983

From duke at openjdk.org  Mon Dec  5 13:16:44 2022
From: duke at openjdk.org (Afshin Zafari)
Date: Mon, 5 Dec 2022 13:16:44 GMT
Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v2]
In-Reply-To: <Dj9YfY10SLn8dR1Ez3kEQe4tXm1q5W1TS8_4r3gBUsY=.6c38825a-86e5-4575-a509-683786d242a6@github.com>
References: <Dj9YfY10SLn8dR1Ez3kEQe4tXm1q5W1TS8_4r3gBUsY=.6c38825a-86e5-4575-a509-683786d242a6@github.com>
Message-ID: <yhzD_0pdvCEtA9UVulZ_mDq9sO82qwINAUBgjA3pLqE=.7465110b-b732-4b0d-8054-da1ff1764296@github.com>

> test of tier1-5 passed.

Afshin Zafari 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 seven additional commits since the last revision:

 - 8292741: Convert JvmtiTagMapTable to ResourceHashtable
 - Merge branch 'jvmti_tagmap' of http://github.com/afshin-zafari/jdk into jvmti_tagmap
 - JBS-8292741: Convert JvmtiTagMapTable to ResourceHashtable
 - 8292741: Convert JvmtiTagMapTable to ResourceHashtable
 - 8292741: Convert JvmtiTagMapTable to ResourceHashtable
 - Added update interface instead of Remove-Add pair.
 - JBS-8292741: Convert JvmtiTagMapTable to ResourceHashtable

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11288/files
  - new: https://git.openjdk.org/jdk/pull/11288/files/0bcd27d0..cd0ca72c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11288&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11288&range=00-01

  Stats: 62256 lines in 1240 files changed: 26769 ins; 22309 del; 13178 mod
  Patch: https://git.openjdk.org/jdk/pull/11288.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11288/head:pull/11288

PR: https://git.openjdk.org/jdk/pull/11288

From dnsimon at openjdk.org  Mon Dec  5 13:24:59 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 5 Dec 2022 13:24:59 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at runtime
Message-ID: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>

Libgraal is compiled ahead of time and should not need any JVMCI Java code to be dynamically loaded at runtime. Prior to this PR, this is not the case due to:

* Code to copy system properties from the HotSpot heap into the libgraal heap. This is in `jdk.vm.ci.services.Services.initializeSavedProperties(byte[])` and `jdk.vm.ci.services.Services.serializeSavedProperties()`. This code should be moved to `java.base/jdk.internal.vm.VMSupport`.
* Code to translate exceptions from the HotSpot heap into the libgraal heap and vice versa. This code should be moved from `jdk.internal.vm.ci//jdk.vm.ci.hotspot.TranslatedException` to `java.base/jdk.internal.vm.VMSupport`.

This PR makes the above changes. As a result, it's possible to build a JDK image that includes (and uses) libgraal but does not include `jdk.internal.vm.ci` or `jdk.internal.vm.compiler`. This both reduces footprint and better isolates the JAVMCI and the Graal compiler as accessing these components from Java code is now impossible.

-------------

Commit messages:
 - move JVMCI exception translation support into VMSupport
 - move JVMCITraceMark blocks within scope of C2V_BLOCK (GR-40773)
 - move JVMCI system properties support into VMSupport
 - only resolve jdk.internal.vm.ci if it is present on the file system

Changes: https://git.openjdk.org/jdk/pull/11513/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11513&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298099
  Stats: 1414 lines in 20 files changed: 607 ins; 706 del; 101 mod
  Patch: https://git.openjdk.org/jdk/pull/11513.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11513/head:pull/11513

PR: https://git.openjdk.org/jdk/pull/11513

From stuefe at openjdk.org  Mon Dec  5 13:30:10 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 5 Dec 2022 13:30:10 GMT
Subject: RFR: 8157023: Integrate NMT with JFR [v2]
In-Reply-To: <2jYwtMYh04GDyfNZBj8uqoG5wMmDDK3S3oQnr7fwhGU=.db88199a-9a15-451e-919a-ad2777845998@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <7MunRi3rxCpz4mk9VmuV2MixTHklxSKjbuW5SmdiGGU=.31447ad0-1c44-4f45-891d-053bed30ddb7@github.com>
 <6AbCj6BP2IGbslCOEgYc3rwClN1b8wCmNaPpC_FMutI=.c29988a7-fed1-4614-9d3d-ca3973068d82@github.com>
 <_4A_Rv8UojxKHnINj75a1IKTupJnHpz5bMXT57shP7s=.282028c3-6836-48f9-9936-9a26ef4c3c7d@github.com>
 <2jYwtMYh04GDyfNZBj8uqoG5wMmDDK3S3oQnr7fwhGU=.db88199a-9a15-451e-919a-ad2777845998@github.com>
Message-ID: <pNzYJp-c6uqWTSXpME-d1nx2vHZucSQzhXBhyDXv7ZM=.90b44fb3-6216-410e-a99e-44c2f23c3b30@github.com>

On Mon, 5 Dec 2022 13:08:50 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> I can take a stab at it. Only thing I'm not clear about exactly what you mean is: we could hide the nitty gritty of result retrieving (e.g. mtNone, mtChunk handling etc) at least in part from using code like JFR.

Reporting is not always 1:1 wrt MEMFLAGS. Some are special:

- mtNone should not really exist, and we want to remove it. StefanK did some preparatory work already. NMT reporter just prints an empty line, I think. I would just leave it out.
- mtChunk is special because Arenas are in this weird role where they are arena memory, but then they are malloced. So reporting must report mtChunk allocations for chunks that belong to an arena under the arena's MEMFLAG. In my experiences, this breaks easily. But I see that is taken care of as part of the baseline() function (See MallocMemorySnapshot::make_adjustment()). So maybe you don't want to do anything here.

But if you follow the breadcrumb of what MemReporter does, you should be fine.

p.s. my peak display change is up for review, I would be happy if you could give it an eye? https://github.com/openjdk/jdk/pull/11497

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From duke at openjdk.org  Mon Dec  5 13:33:52 2022
From: duke at openjdk.org (Afshin Zafari)
Date: Mon, 5 Dec 2022 13:33:52 GMT
Subject: Integrated: 8297766: Remove UseMallocOnly development option
In-Reply-To: <34gopg6h0xMvkDTyTltghkTZPl4IZdODxcCJMKN-Ki8=.8117d9d7-9325-482d-b232-49ca862413b2@github.com>
References: <34gopg6h0xMvkDTyTltghkTZPl4IZdODxcCJMKN-Ki8=.8117d9d7-9325-482d-b232-49ca862413b2@github.com>
Message-ID: <hsUlKR6Kc8aOi4CQwlItaw74bjzM8AoXqKppNacxaQU=.2d7ba81c-2ed9-4bba-a20f-c6e42d390c1b@github.com>

On Thu, 1 Dec 2022 15:37:56 GMT, Afshin Zafari <duke at openjdk.org> wrote:

> ### Description
> The UseMallocOnly development option was originally used to detect memory stomping bugs with Arena allocations when the JVM was first in development.
> 
> The option has had a few bugs and is not in general use. There are ideas to add another way of Arena canary checking.
> 
> ### Patch:
> All occurrences of UseMallocOnly are removed.
> 
> ### Tests:
> Local, gTests: resourceArea and Arena
> Mach5: tier1-5

This pull request has now been integrated.

Changeset: bd381886
Author:    Afshin Zafari <afshin.zafari at oracle.com>
Committer: Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bd381886e0f39d0e48b555b5e3167565d6a6b40d
Stats:     220 lines in 9 files changed: 1 ins; 197 del; 22 mod

8297766: Remove UseMallocOnly development option

Reviewed-by: coleenp, stuefe, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/11456

From alanb at openjdk.org  Mon Dec  5 13:35:03 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 5 Dec 2022 13:35:03 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime
In-Reply-To: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
Message-ID: <Ztw0UpACX_jczeIl57EbOa6BOpiFVWeACn3CowQSgZE=.d6776252-4478-4bb9-8555-9bb17af43051@github.com>

On Mon, 5 Dec 2022 13:16:25 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> Libgraal is compiled ahead of time and should not need any JVMCI Java code to be dynamically loaded at runtime. Prior to this PR, this is not the case due to:
> 
> * Code to copy system properties from the HotSpot heap into the libgraal heap. This is in `jdk.vm.ci.services.Services.initializeSavedProperties(byte[])` and `jdk.vm.ci.services.Services.serializeSavedProperties()`. This code should be moved to `java.base/jdk.internal.vm.VMSupport`.
> * Code to translate exceptions from the HotSpot heap into the libgraal heap and vice versa. This code should be moved from `jdk.internal.vm.ci//jdk.vm.ci.hotspot.TranslatedException` to `java.base/jdk.internal.vm.VMSupport`.
> 
> This PR makes the above changes. As a result, it's possible to build a JDK image that includes (and uses) libgraal but does not include `jdk.internal.vm.ci` or `jdk.internal.vm.compiler`. This both reduces footprint and better isolates the JAVMCI and the Graal compiler as accessing these components from Java code is now impossible.

src/hotspot/share/classfile/classLoader.cpp line 1419:

> 1417: 
> 1418: // Returns true if jdk.internal.vm.ci is present on the file system.
> 1419: bool ClassLoader::has_jvmci_module() {

Would it be more useful to pass the module name so that the function tests if the module is is in the run-time image so that ClassLoader doesn't need to know the name "jdk.internal.vm.ci"?

-------------

PR: https://git.openjdk.org/jdk/pull/11513

From lkorinth at openjdk.org  Mon Dec  5 13:38:09 2022
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 5 Dec 2022 13:38:09 GMT
Subject: RFR: 8296401: ConcurrentHashTable::bulk_delete might miss to
 delete some objects
In-Reply-To: <-46D7o9D9hweEylWT61buGVsoYYFZLlKezzaBgt7GvQ=.7e7b3755-98cb-4696-ba07-0ba3b7046a4a@github.com>
References: <rWw3Hb1baG5eslMgFnOdEP1Q4avhfYc3uTpjdB9DaP0=.23f34ff0-eff9-421b-9e70-7f119fd90e5d@github.com>
 <srzYQG8vQxXtFu8IYd4LzHoFZo6VR8_D_9e5wlek0u4=.c3fb4829-6de5-428e-9b70-f34aeba9c55f@github.com>
 <XlpaIj9dRjwUPkQTmLqfWNx7r4afKUu5cE4xUDRwNgw=.96918f61-bb6d-4d92-995d-d763adf6df63@github.com>
 <-46D7o9D9hweEylWT61buGVsoYYFZLlKezzaBgt7GvQ=.7e7b3755-98cb-4696-ba07-0ba3b7046a4a@github.com>
Message-ID: <oh4H4jjhdQ2TR37v4PsDr99lVtux72HC5gnUkCo5TgQ=.620d2b25-916c-42a5-b655-1cdf5dbd2328@github.com>

On Mon, 5 Dec 2022 11:00:22 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> > If the user of the hash table has buckets sized above 256, the exponential growing of the extra array will start at a very small size and it will not be optimal. It will work, and that is IMO enough.
> 
> I thought the benefit of having a `BULK_DELETE_LIMIT` was to limit the cleanup done by an individual thread. This effectively limits the duration of the critical section.

That is true. Do you think that is a problem with the new implementation?

-------------

PR: https://git.openjdk.org/jdk/pull/10983

From sjohanss at openjdk.org  Mon Dec  5 13:47:56 2022
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Mon, 5 Dec 2022 13:47:56 GMT
Subject: RFR: 8157023: Integrate NMT with JFR [v2]
In-Reply-To: <pNzYJp-c6uqWTSXpME-d1nx2vHZucSQzhXBhyDXv7ZM=.90b44fb3-6216-410e-a99e-44c2f23c3b30@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <7MunRi3rxCpz4mk9VmuV2MixTHklxSKjbuW5SmdiGGU=.31447ad0-1c44-4f45-891d-053bed30ddb7@github.com>
 <6AbCj6BP2IGbslCOEgYc3rwClN1b8wCmNaPpC_FMutI=.c29988a7-fed1-4614-9d3d-ca3973068d82@github.com>
 <_4A_Rv8UojxKHnINj75a1IKTupJnHpz5bMXT57shP7s=.282028c3-6836-48f9-9936-9a26ef4c3c7d@github.com>
 <2jYwtMYh04GDyfNZBj8uqoG5wMmDDK3S3oQnr7fwhGU=.db88199a-9a15-451e-919a-ad2777845998@github.com>
 <pNzYJp-c6uqWTSXpME-d1nx2vHZucSQzhXBhyDXv7ZM=.90b44fb3-6216-410e-a99e-44c2f23c3b30@github.com>
Message-ID: <KEjpG_kQBs4qb3T4O4yV-vA52K2i2c_1BXopn5H6oDA=.2d739f10-2b65-4f37-bdab-319baf69b524@github.com>

On Mon, 5 Dec 2022 13:26:07 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > I can take a stab at it. Only thing I'm not clear about exactly what you mean is: we could hide the nitty gritty of result retrieving (e.g. mtNone, mtChunk handling etc) at least in part from using code like JFR.
> 
> Reporting is not always 1:1 wrt MEMFLAGS. Some are special:
> 
>     * mtNone should not really exist, and we want to remove it. StefanK did some preparatory work already. NMT reporter just prints an empty line, I think. I would just leave it out.
> 
Agree, should probably exclude that one.
>     * mtChunk is special because Arenas are in this weird role where they are arena memory, but then they are malloced. So reporting must report mtChunk allocations for chunks that belong to an arena under the arena's MEMFLAG. In my experiences, this breaks easily. But I see that is taken care of as part of the baseline() function (See MallocMemorySnapshot::make_adjustment()). So maybe you don't want to do anything here.
> 
I looked at that and decided to not dig into it, thanks for the explanation. 

> 
> But if you follow the breadcrumb of what MemReporter does, you should be fine.
> 
A very quick look at what your API could look like if I try to use the same style as currently used in NMT and creating something that works similar to `MemBaseline`. I ended up with:

struct VirtualMemoryPair {
  size_t reserved;
  size_t committed;
};

struct MemSnapshotOptions {
  bool include_malloc;
  bool include_vm;
  bool include_thread_stacks;
};

class MemSnapshot {
private:
  size_t _malloc_snapshot[mt_number_of_types];
  VirtualMemoryPair _vm_snapshot[mt_number_of_types];
  VirtualMemoryPair _thread_stack_snapshot;

  bool _has_malloc_snapshot;
  bool _has_vm_snapshot;
  bool _has_thread_stack_snapshot;

public:
  MemSnapshot(MemSnapshotOptions options);
  void snap();
};


So basically you create your `MemSnapshot` with a set of options and then "snap" it to update. Not sure if there is a use-case where one want a single snapshot but want to call it with different options. What do you think about this? 

If going with this approach I plan to add getters like:

size_t getReserved(MEMFLAGS);
size_t getCommitted(MEMFLAGS);

Not sure if it makes sense to have getters for the individual "snapshots", also not sure if one should assert that no one calls it using mtThreadStack/mtThread if that options is off. Or just report the cheap numbers.

> p.s. my peak display change is up for review, I would be happy if you could give it an eye? #11497

I'll try to find time tomorrow or later today.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From dnsimon at openjdk.org  Mon Dec  5 13:49:28 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 5 Dec 2022 13:49:28 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v2]
In-Reply-To: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
Message-ID: <WgaYQgGsrCaoiwDikHOB0em7NhpCugMEVevsNKByQrE=.3a67835a-633c-4b29-be22-bcb2fc2ba40a@github.com>

> Libgraal is compiled ahead of time and should not need any JVMCI Java code to be dynamically loaded at runtime. Prior to this PR, this is not the case due to:
> 
> * Code to copy system properties from the HotSpot heap into the libgraal heap. This is in `jdk.vm.ci.services.Services.initializeSavedProperties(byte[])` and `jdk.vm.ci.services.Services.serializeSavedProperties()`. This code should be moved to `java.base/jdk.internal.vm.VMSupport`.
> * Code to translate exceptions from the HotSpot heap into the libgraal heap and vice versa. This code should be moved from `jdk.internal.vm.ci//jdk.vm.ci.hotspot.TranslatedException` to `java.base/jdk.internal.vm.VMSupport`.
> 
> This PR makes the above changes. As a result, it's possible to build a JDK image that includes (and uses) libgraal but does not include `jdk.internal.vm.ci` or `jdk.internal.vm.compiler`. This both reduces footprint and better isolates the JAVMCI and the Graal compiler as accessing these components from Java code is now impossible.

Doug Simon has updated the pull request incrementally with one additional commit since the last revision:

  generalized ClassLoader::has_jvmci_module to is_module_resolvable

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11513/files
  - new: https://git.openjdk.org/jdk/pull/11513/files/b91f31fe..3e89d402

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11513&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11513&range=00-01

  Stats: 9 lines in 3 files changed: 3 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/11513.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11513/head:pull/11513

PR: https://git.openjdk.org/jdk/pull/11513

From mcimadamore at openjdk.org  Mon Dec  5 13:49:46 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 5 Dec 2022 13:49:46 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v39]
In-Reply-To: <-V_N0Cvh4J0vKNbBYdFcow9E8yFHRIjya8n69MpDSuY=.9626ee4d-95b6-41e4-b21e-395e79840388@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <-V_N0Cvh4J0vKNbBYdFcow9E8yFHRIjya8n69MpDSuY=.9626ee4d-95b6-41e4-b21e-395e79840388@github.com>
Message-ID: <hkjubM7yW4kkYAetu0kuCJy9wPQ_Llluj47lYXIc_8A=.2fc0c63b-d71f-4b18-af52-a6aa286b742d@github.com>

On Mon, 5 Dec 2022 10:31:52 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.org/jeps/434
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix Preview annotation for JEP 434

Note: there are 4 tests failing in x86:
* MemoryLayoutPrincipalTotalityTest
* MemoryLayoutTypeRetentionTest
* TestLargeSegmentCopy
* TestLinker

These failures are addressed in the dependent PR: https://git.openjdk.org/jdk/pull/11019, which will be integrated immediately after these changes

-------------

PR: https://git.openjdk.org/jdk/pull/10872

From jvernee at openjdk.org  Mon Dec  5 13:51:30 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 5 Dec 2022 13:51:30 GMT
Subject: RFR: 8296477: Foreign linker implementation update following JEP
 434 [v11]
In-Reply-To: <CGd4JSefJvfEVkZEfORzthEIeV53kLk_UkZHAhJGrQ0=.7741b5f2-2227-4017-8164-d54fb9d30d10@github.com>
References: <CGd4JSefJvfEVkZEfORzthEIeV53kLk_UkZHAhJGrQ0=.7741b5f2-2227-4017-8164-d54fb9d30d10@github.com>
Message-ID: <Fo9HNIRgbhTLnJXkapP1_qjB2fEgTRHD8UarM09L5pQ=.2189d888-4987-4737-ab5b-1580a0f25b7d@github.com>

> Pull in linker implementation changes, that include non-trivial changes to VM code, from the panama-foreign repo into the main JDK.
> 
> This is split off from the main JEP integration to make reviewing easier.
> 
> This includes the following patches:
> 
> 1. https://github.com/openjdk/panama-foreign/pull/698
> 2. https://github.com/openjdk/panama-foreign/pull/699
> 3. (part of) https://github.com/openjdk/panama-foreign/pull/731
> 4. https://github.com/openjdk/panama-foreign/pull/740
> 5. https://github.com/openjdk/panama-foreign/pull/746
> 6. https://github.com/openjdk/panama-foreign/pull/742
> 7. https://github.com/openjdk/panama-foreign/pull/743
> 
> Probably the biggest change to the code comes from replacing `VMReg` - which can not represent offsets into the stack that are not a multiple of the VM's stack slot size (32-bits) - with the new `VMStorage` class, which can describe byte offsets into the stack, as well as having a register mask to indicate only certain register segments.
> 
> The only part of 3. that is in this PR is the part that turns the `VMStorage` class in Java into a record.
> 
> Please refer to the PR of each individual patch for a more detailed description.

Jorn Vernee 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 26 additional commits since the last revision:

 - Merge branch 'PR_20' into VM_Changes
 - Merge branch 'PR_20' into VM_Changes
 - Merge branch 'PR_20' into VM_Changes
 - use Arena in example
 - Merge branch 'PR_20' into VM_Changes
 - drop .inline from vmstorage header names
 - 8296973: saving errno on a value-returning function crashes the JVM
   
   Reviewed-by: mcimadamore
 - fix stubs
 - constexpr some functions
 - Review pt1
 - ... and 16 more: https://git.openjdk.org/jdk/compare/7b86f7b8...2949f997

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11019/files
  - new: https://git.openjdk.org/jdk/pull/11019/files/6e94e452..2949f997

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11019&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11019&range=09-10

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11019.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11019/head:pull/11019

PR: https://git.openjdk.org/jdk/pull/11019

From stuefe at openjdk.org  Mon Dec  5 13:54:21 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 5 Dec 2022 13:54:21 GMT
Subject: RFR: 8157023: Integrate NMT with JFR [v2]
In-Reply-To: <7MunRi3rxCpz4mk9VmuV2MixTHklxSKjbuW5SmdiGGU=.31447ad0-1c44-4f45-891d-053bed30ddb7@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <7MunRi3rxCpz4mk9VmuV2MixTHklxSKjbuW5SmdiGGU=.31447ad0-1c44-4f45-891d-053bed30ddb7@github.com>
Message-ID: <RZ9Im6_Tc3WfjegtsedgUixcMya7Ja53B1fOEyXhyVY=.e2422f36-5e05-43ce-8656-1730a96aedd6@github.com>

On Fri, 2 Dec 2022 15:39:52 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Please review this enhancement to include NMT information in JFR recordings.
>> 
>> **Summary**
>> Native Memory Tracking summary information can be obtained from a running VM using `jcmd` if started with `-XX:NativeMemoryTracking=summary/detail`. Using `jcmd` requires you to run a separate process and to parse the output to get the needed information. This change adds JFR events for NMT information to enable additional ways to consume the NMT data.
>> 
>> There are two new events added:
>> * _NativeMemoryUsage_ - The total native memory usage.
>> * _NativeMemoryUsagePart_ - The native memory usage for each component.
>> 
>> These events are sent periodically and by default the interval is 1s. This can of course be discussed, but that is the staring point. When NMT is not enabled on events will be sent.
>> 
>> **Testing**
>> * Added a simple test to verify that the events are sent as expected depending on if NMT is enabled or not.
>> * Mach5 sanity testing
>
> Stefan Johansson has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Some refactoring after comments
>  - egahlin and carterkozak comments

Looks good. Small simplification, instead of "_has_xxx" boolean flags, just use your MemSnapshotOptions as member.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From mcimadamore at openjdk.org  Mon Dec  5 13:55:22 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 5 Dec 2022 13:55:22 GMT
Subject: Integrated: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview)
In-Reply-To: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
Message-ID: <7Ara-NxY9rdQzABZPYR9T-N7b1XLY99_6J-dG3cr2NY=.4151c690-0138-4ffd-a763-ff2456754189@github.com>

On Wed, 26 Oct 2022 13:11:50 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.org/jeps/434

This pull request has now been integrated.

Changeset: 73baadce
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/73baadceb60029f6340c1327118aeb59971c2434
Stats:     13808 lines in 255 files changed: 5780 ins; 4448 del; 3580 mod

8295044: Implementation of Foreign Function and Memory API (Second Preview)

Co-authored-by: Jorn Vernee <jvernee at openjdk.org>
Co-authored-by: Per Minborg <pminborg at openjdk.org>
Co-authored-by: Maurizio Cimadamore <mcimadamore at openjdk.org>
Reviewed-by: jvernee, pminborg, psandoz, alanb, sundar

-------------

PR: https://git.openjdk.org/jdk/pull/10872

From dnsimon at openjdk.org  Mon Dec  5 13:55:50 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 5 Dec 2022 13:55:50 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v2]
In-Reply-To: <Ztw0UpACX_jczeIl57EbOa6BOpiFVWeACn3CowQSgZE=.d6776252-4478-4bb9-8555-9bb17af43051@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
 <Ztw0UpACX_jczeIl57EbOa6BOpiFVWeACn3CowQSgZE=.d6776252-4478-4bb9-8555-9bb17af43051@github.com>
Message-ID: <a-ppZa-5xUyxJpp5lZ30BVyVRo8HzFpXwFGHCkicExg=.3f5a3ebc-5306-4738-9f36-f2bcc2ab9f5b@github.com>

On Mon, 5 Dec 2022 13:32:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   generalized ClassLoader::has_jvmci_module to is_module_resolvable
>
> src/hotspot/share/classfile/classLoader.cpp line 1419:
> 
>> 1417: 
>> 1418: // Returns true if jdk.internal.vm.ci is present on the file system.
>> 1419: bool ClassLoader::has_jvmci_module() {
> 
> Would it be more useful to pass the module name so that the function tests if the module is is in the run-time image so that ClassLoader doesn't need to know the name "jdk.internal.vm.ci"?

Yes, good idea: [3e89d40253b70251f9a2facce4b1d8d69701c045](https://github.com/openjdk/jdk/pull/11513/commits/3e89d40253b70251f9a2facce4b1d8d69701c045)
I also fixed a bug due in the size computation of `path`. Ideally, I'd factor out and re-use the same code in `ClassLoader::add_to_exploded_build_list`. However, the latter uses a `ResourceMark` which is not available when calling `is_module_resolvable` early in VM startup before `JavaThread` is initialized.

-------------

PR: https://git.openjdk.org/jdk/pull/11513

From dnsimon at openjdk.org  Mon Dec  5 13:55:51 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 5 Dec 2022 13:55:51 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v2]
In-Reply-To: <WgaYQgGsrCaoiwDikHOB0em7NhpCugMEVevsNKByQrE=.3a67835a-633c-4b29-be22-bcb2fc2ba40a@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
 <WgaYQgGsrCaoiwDikHOB0em7NhpCugMEVevsNKByQrE=.3a67835a-633c-4b29-be22-bcb2fc2ba40a@github.com>
Message-ID: <y4lLPk5mDrJNa9vzgiI5WyEJmfbsSRfBBi0QQNdZeEs=.24e2a234-f42e-456f-82a0-3c7fd05dc9c5@github.com>

On Mon, 5 Dec 2022 13:49:28 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Libgraal is compiled ahead of time and should not need any JVMCI Java code to be dynamically loaded at runtime. Prior to this PR, this is not the case due to:
>> 
>> * Code to copy system properties from the HotSpot heap into the libgraal heap. This is in `jdk.vm.ci.services.Services.initializeSavedProperties(byte[])` and `jdk.vm.ci.services.Services.serializeSavedProperties()`. This code should be moved to `java.base/jdk.internal.vm.VMSupport`.
>> * Code to translate exceptions from the HotSpot heap into the libgraal heap and vice versa. This code should be moved from `jdk.internal.vm.ci//jdk.vm.ci.hotspot.TranslatedException` to `java.base/jdk.internal.vm.VMSupport`.
>> 
>> This PR makes the above changes. As a result, it's possible to build a JDK image that includes (and uses) libgraal but does not include `jdk.internal.vm.ci` or `jdk.internal.vm.compiler`. This both reduces footprint and better isolates the JAVMCI and the Graal compiler as accessing these components from Java code is now impossible.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   generalized ClassLoader::has_jvmci_module to is_module_resolvable

src/hotspot/share/classfile/classLoader.hpp line 378:

> 376: 
> 377:   // Determines if the `module_name` module is resolvable.
> 378:   static bool is_module_resolvable(const char* module_name);

Is "resolvable" the right concept here? Or should it be something like "findable" instead?

-------------

PR: https://git.openjdk.org/jdk/pull/11513

From avoitylov at openjdk.org  Mon Dec  5 14:19:55 2022
From: avoitylov at openjdk.org (Aleksei Voitylov)
Date: Mon, 5 Dec 2022 14:19:55 GMT
Subject: RFR: 8291302: ARM32: nmethod entry barriers support [v2]
In-Reply-To: <BJaszr0_haU4UZOyQQEA9P0SOlgtfTtGFBj9VSRD5SM=.ffd6af56-a51e-4627-90cb-0eb0e1bbd5e8@github.com>
References: <BJaszr0_haU4UZOyQQEA9P0SOlgtfTtGFBj9VSRD5SM=.ffd6af56-a51e-4627-90cb-0eb0e1bbd5e8@github.com>
Message-ID: <JghFO_YuAWdgvKFJpaUzuiaeLYjRrRav4hfR0u2LkWw=.529baf93-df04-4c3a-9ed2-fd884f2cd60b@github.com>

> This PR implements nmethod entry barriers for ARM32. It has already been implemented for other ports and is related with JDK-8290025 "Remove the Sweeper".

Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:

  save float registers

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11442/files
  - new: https://git.openjdk.org/jdk/pull/11442/files/828c39d0..34a17994

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11442&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11442&range=00-01

  Stats: 10 lines in 2 files changed: 8 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11442.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11442/head:pull/11442

PR: https://git.openjdk.org/jdk/pull/11442

From avoitylov at openjdk.org  Mon Dec  5 14:23:28 2022
From: avoitylov at openjdk.org (Aleksei Voitylov)
Date: Mon, 5 Dec 2022 14:23:28 GMT
Subject: RFR: 8291302: ARM32: nmethod entry barriers support [v2]
In-Reply-To: <MvWj6e6BaqAiu-k1lRqf96Uc16JlbykXsRrNGeLHVkw=.c6ba6c5c-c62b-4f42-a4a3-177ef7826571@github.com>
References: <BJaszr0_haU4UZOyQQEA9P0SOlgtfTtGFBj9VSRD5SM=.ffd6af56-a51e-4627-90cb-0eb0e1bbd5e8@github.com>
 <vENPpkRJ7ZlN6k5ymTCUUiESeWfx6ibyJdTpjPMIjvw=.445df16d-28ca-47ec-9a6b-2bbc1cd7ae95@github.com>
 <MvWj6e6BaqAiu-k1lRqf96Uc16JlbykXsRrNGeLHVkw=.c6ba6c5c-c62b-4f42-a4a3-177ef7826571@github.com>
Message-ID: <HxQV6kEQtYJIeUi66Ww8CTqY1oDyhFa2w9-VoPnSZHc=.30bee5ca-6bb8-4dbb-b793-c251172fe38e@github.com>

On Mon, 5 Dec 2022 12:37:09 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> src/hotspot/cpu/arm/gc/shared/barrierSetNMethod_arm.cpp line 87:
>> 
>>> 85:    to the interpreter if the nmethod has been unloaded. */
>>> 86: void BarrierSetNMethod::deoptimize(nmethod* nm, address* return_address_ptr) {
>>> 87: 
>> 
>> Again if neither ZGC nor ShenandoahGC are supported then you can leave this unimplemented. [`BarrierSetNMethod::nmethod_entry_barrier()`](https://github.com/openjdk/jdk/blob/fa0c599a003962cf3457bb49b9f771659532b5c3/src/hotspot/share/gc/shared/barrierSetNMethod.cpp#L72-L103) never returns false so the single [call site](https://github.com/openjdk/jdk/blob/fa0c599a003962cf3457bb49b9f771659532b5c3/src/hotspot/share/gc/shared/barrierSetNMethod.cpp#L181) cannot be reached unless you want to support `DeoptimizeNMethodBarriersALot` which IMO is not needed without support for ZGC/ShenandoahGC.
>
> Isn't there a jtreg test which triggers the deoptimization somehow?

I could not find jtreg tests that specially target deoptimization codepath but one can trigger and test it using a benchmark, e.g. dacapo lusearch with +DeoptimizeNMethodBarriersALot key.

-------------

PR: https://git.openjdk.org/jdk/pull/11442

From avoitylov at openjdk.org  Mon Dec  5 14:32:33 2022
From: avoitylov at openjdk.org (Aleksei Voitylov)
Date: Mon, 5 Dec 2022 14:32:33 GMT
Subject: RFR: 8291302: ARM32: nmethod entry barriers support [v2]
In-Reply-To: <DtHvGM7UYziT5t9mqAihHlOR7WqwoE7RMvHY0Pt3PJU=.47aaab8a-9c1a-4158-9925-3f75df9d14b2@github.com>
References: <BJaszr0_haU4UZOyQQEA9P0SOlgtfTtGFBj9VSRD5SM=.ffd6af56-a51e-4627-90cb-0eb0e1bbd5e8@github.com>
 <DtHvGM7UYziT5t9mqAihHlOR7WqwoE7RMvHY0Pt3PJU=.47aaab8a-9c1a-4158-9925-3f75df9d14b2@github.com>
Message-ID: <RXudoUnidMSIhhnC6zeRgV6oYa9P-jA9h1FwkaJUAng=.378adf58-e522-483e-b670-2a3af9ffe0f0@github.com>

On Wed, 30 Nov 2022 21:01:04 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   save float registers
>
> When you call the nmethod entry barrier slow path, floating point arguments are live, but can get clobbered by the C++ runtime. You need to save them. That's probably why you can't print in the slow path without crashing.

@fisk @reinrich Thank you for your suggestions. This iteration saves floating registers and can successfully log deoptimization. I'd prefer to keep the code in line with the same code for other ports and not carve out memory barriers by hand, if @reinrich would agree. This also allows a more straightforward port for additional GCs in the future, should there be any demand.

-------------

PR: https://git.openjdk.org/jdk/pull/11442

From jvernee at openjdk.org  Mon Dec  5 14:43:06 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 5 Dec 2022 14:43:06 GMT
Subject: RFR: 8296477: Foreign linker implementation update following JEP
 434 [v12]
In-Reply-To: <CGd4JSefJvfEVkZEfORzthEIeV53kLk_UkZHAhJGrQ0=.7741b5f2-2227-4017-8164-d54fb9d30d10@github.com>
References: <CGd4JSefJvfEVkZEfORzthEIeV53kLk_UkZHAhJGrQ0=.7741b5f2-2227-4017-8164-d54fb9d30d10@github.com>
Message-ID: <8IKeJaZMLm4Wbr5q7RITfR6auB1raU-jzQODNKnnHCQ=.ba354806-e514-47fa-802a-0370d6fe5792@github.com>

> Pull in linker implementation changes, that include non-trivial changes to VM code, from the panama-foreign repo into the main JDK.
> 
> This is split off from the main JEP integration to make reviewing easier.
> 
> This includes the following patches:
> 
> 1. https://github.com/openjdk/panama-foreign/pull/698
> 2. https://github.com/openjdk/panama-foreign/pull/699
> 3. (part of) https://github.com/openjdk/panama-foreign/pull/731
> 4. https://github.com/openjdk/panama-foreign/pull/740
> 5. https://github.com/openjdk/panama-foreign/pull/746
> 6. https://github.com/openjdk/panama-foreign/pull/742
> 7. https://github.com/openjdk/panama-foreign/pull/743
> 
> Probably the biggest change to the code comes from replacing `VMReg` - which can not represent offsets into the stack that are not a multiple of the VM's stack slot size (32-bits) - with the new `VMStorage` class, which can describe byte offsets into the stack, as well as having a register mask to indicate only certain register segments.
> 
> The only part of 3. that is in this PR is the part that turns the `VMStorage` class in Java into a record.
> 
> Please refer to the PR of each individual patch for a more detailed description.

Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 98 commits:

 - Merge master
 - Merge branch 'PR_20' into VM_Changes
 - Fix Preview annotation for JEP 434
 - Merge branch 'PR_20' into VM_Changes
 - Merge branch 'master' into PR_20
 - Address review comments
 - Address review comments
 - Merge branch 'PR_20' into VM_Changes
 - Merge branch 'master' into PR_20
 - Address review comment
 - ... and 88 more: https://git.openjdk.org/jdk/compare/73baadce...c153ffff

-------------

Changes: https://git.openjdk.org/jdk/pull/11019/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11019&range=11
  Stats: 2909 lines in 73 files changed: 1974 ins; 318 del; 617 mod
  Patch: https://git.openjdk.org/jdk/pull/11019.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11019/head:pull/11019

PR: https://git.openjdk.org/jdk/pull/11019

From jvernee at openjdk.org  Mon Dec  5 14:48:24 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 5 Dec 2022 14:48:24 GMT
Subject: RFR: 8296477: Foreign linker implementation update following JEP
 434 [v13]
In-Reply-To: <CGd4JSefJvfEVkZEfORzthEIeV53kLk_UkZHAhJGrQ0=.7741b5f2-2227-4017-8164-d54fb9d30d10@github.com>
References: <CGd4JSefJvfEVkZEfORzthEIeV53kLk_UkZHAhJGrQ0=.7741b5f2-2227-4017-8164-d54fb9d30d10@github.com>
Message-ID: <ZniTDJz6929Hav9i2kSTAeHLGTwk0sKAsEQ4esSSJx0=.6f2bf536-484a-44cb-b77d-86405c3853fd@github.com>

> Pull in linker implementation changes, that include non-trivial changes to VM code, from the panama-foreign repo into the main JDK.
> 
> This is split off from the main JEP integration to make reviewing easier.
> 
> This includes the following patches:
> 
> 1. https://github.com/openjdk/panama-foreign/pull/698
> 2. https://github.com/openjdk/panama-foreign/pull/699
> 3. (part of) https://github.com/openjdk/panama-foreign/pull/731
> 4. https://github.com/openjdk/panama-foreign/pull/740
> 5. https://github.com/openjdk/panama-foreign/pull/746
> 6. https://github.com/openjdk/panama-foreign/pull/742
> 7. https://github.com/openjdk/panama-foreign/pull/743
> 
> Probably the biggest change to the code comes from replacing `VMReg` - which can not represent offsets into the stack that are not a multiple of the VM's stack slot size (32-bits) - with the new `VMStorage` class, which can describe byte offsets into the stack, as well as having a register mask to indicate only certain register segments.
> 
> The only part of 3. that is in this PR is the part that turns the `VMStorage` class in Java into a record.
> 
> Please refer to the PR of each individual patch for a more detailed description.

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Remove spurious imports

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11019/files
  - new: https://git.openjdk.org/jdk/pull/11019/files/c153ffff..754faca2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11019&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11019&range=11-12

  Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11019.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11019/head:pull/11019

PR: https://git.openjdk.org/jdk/pull/11019

From jbhateja at openjdk.org  Mon Dec  5 14:50:17 2022
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 5 Dec 2022 14:50:17 GMT
Subject: RFR: 8297689: Fix incorrect result of Short.reverseBytes() call in
 loops
In-Reply-To: <yv1aUlZMKpLVbXZmkSqZtWLlDTa-5PeX6pzzBu1Rrb8=.6ef681fe-6dbd-4dab-9ee0-61f59fbeb024@github.com>
References: <yv1aUlZMKpLVbXZmkSqZtWLlDTa-5PeX6pzzBu1Rrb8=.6ef681fe-6dbd-4dab-9ee0-61f59fbeb024@github.com>
Message-ID: <OXsrLxDdaBPdxmvQKXmNls23YKxKrlc4-Ca3zQxuwp4=.a4445686-8b22-4163-a93d-3069b58cf180@github.com>

On Wed, 30 Nov 2022 07:20:11 GMT, Pengfei Li <pli at openjdk.org> wrote:

> Recently, we find calling `Short.reverseBytes()` in loops may generate incorrect result if the code is compiled by C2. Below is a simple case to reproduce.
> 
> 
> class Foo {
>   static final int SIZE = 50;
>   static int a[] = new int[SIZE];
> 
>   static void test() {
>     for (int i = 0; i < SIZE; i++) {
>       a[i] = Short.reverseBytes((short) a[i]);
>     }
>   }
> 
>   public static void main(String[] args) throws Exception {
>     Class.forName("java.lang.Short");
>     a[25] = 16;
>     test();
>     System.out.println(a[25]);
>   }
> }
> 
> // $ java -Xint Foo
> // 4096
> // $ java -Xcomp -XX:-TieredCompilation -XX:CompileOnly=Foo.test Foo
> // 268435456
> 
> 
> In this case, the `reverseBytes()` call is intrinsified and transformed into a `ReverseBytesS` node. But then C2 compiler incorrectly vectorizes it into `ReverseBytesV` with int type. C2 `Op_ReverseBytes*` has short, char, int and long versions. Their behaviors are different for different data sizes. In superword, subword operation itself doesn't have precise data size info. Instead, the data size info comes from memory operations in its use-def chain. Hence, vectorization of `reverseBytes()` is valid only if the data size is consistent with the type size of the caller's class. But current C2 compiler code lacks fine-grained type checks for `ReverseBytes*` in vector transformation. It results in `reverseBytes()` call from Short or Character class with int load/store gets vectorized incorrectly in above case.
> 
> To fix the issue, this patch adds more checks in `VectorNode::opcode()`. T_BYTE is a special case for `Op_ReverseBytes*`. As the Java Byte class doesn't have `reverseBytes()` method so there's no `Op_ReverseBytesB`. But T_BYTE may still appear in VectorAPI calls. In this patch we still use `Op_ReverseBytesI` for T_BYTE to ensure vector intrinsification succeeds.
> 
> Tested with hotspot::hotspot_all_no_apps, jdk tier1~3 and langtools tier1 on x86 and AArch64, no issue is found.

Marked as reviewed by jbhateja (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11427

From jbhateja at openjdk.org  Mon Dec  5 14:50:17 2022
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 5 Dec 2022 14:50:17 GMT
Subject: RFR: 8297689: Fix incorrect result of Short.reverseBytes() call in
 loops
In-Reply-To: <OXsrLxDdaBPdxmvQKXmNls23YKxKrlc4-Ca3zQxuwp4=.a4445686-8b22-4163-a93d-3069b58cf180@github.com>
References: <yv1aUlZMKpLVbXZmkSqZtWLlDTa-5PeX6pzzBu1Rrb8=.6ef681fe-6dbd-4dab-9ee0-61f59fbeb024@github.com>
 <OXsrLxDdaBPdxmvQKXmNls23YKxKrlc4-Ca3zQxuwp4=.a4445686-8b22-4163-a93d-3069b58cf180@github.com>
Message-ID: <GrgGNmwtG_W8d_TgFzCIXAN9Mw1PGVNtx79b4--znwA=.c96fd936-5c6b-4060-a024-57678e7cca0e@github.com>

On Mon, 5 Dec 2022 14:45:49 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Recently, we find calling `Short.reverseBytes()` in loops may generate incorrect result if the code is compiled by C2. Below is a simple case to reproduce.
>> 
>> 
>> class Foo {
>>   static final int SIZE = 50;
>>   static int a[] = new int[SIZE];
>> 
>>   static void test() {
>>     for (int i = 0; i < SIZE; i++) {
>>       a[i] = Short.reverseBytes((short) a[i]);
>>     }
>>   }
>> 
>>   public static void main(String[] args) throws Exception {
>>     Class.forName("java.lang.Short");
>>     a[25] = 16;
>>     test();
>>     System.out.println(a[25]);
>>   }
>> }
>> 
>> // $ java -Xint Foo
>> // 4096
>> // $ java -Xcomp -XX:-TieredCompilation -XX:CompileOnly=Foo.test Foo
>> // 268435456
>> 
>> 
>> In this case, the `reverseBytes()` call is intrinsified and transformed into a `ReverseBytesS` node. But then C2 compiler incorrectly vectorizes it into `ReverseBytesV` with int type. C2 `Op_ReverseBytes*` has short, char, int and long versions. Their behaviors are different for different data sizes. In superword, subword operation itself doesn't have precise data size info. Instead, the data size info comes from memory operations in its use-def chain. Hence, vectorization of `reverseBytes()` is valid only if the data size is consistent with the type size of the caller's class. But current C2 compiler code lacks fine-grained type checks for `ReverseBytes*` in vector transformation. It results in `reverseBytes()` call from Short or Character class with int load/store gets vectorized incorrectly in above case.
>> 
>> To fix the issue, this patch adds more checks in `VectorNode::opcode()`. T_BYTE is a special case for `Op_ReverseBytes*`. As the Java Byte class doesn't have `reverseBytes()` method so there's no `Op_ReverseBytesB`. But T_BYTE may still appear in VectorAPI calls. In this patch we still use `Op_ReverseBytesI` for T_BYTE to ensure vector intrinsification succeeds.
>> 
>> Tested with hotspot::hotspot_all_no_apps, jdk tier1~3 and langtools tier1 on x86 and AArch64, no issue is found.
>
> Marked as reviewed by jbhateja (Reviewer).

> @jatin-bhateja Do you have any comments on this change?

LGTM. Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/11427

From jvernee at openjdk.org  Mon Dec  5 14:50:35 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 5 Dec 2022 14:50:35 GMT
Subject: Integrated: 8296477: Foreign linker implementation update following
 JEP 434
In-Reply-To: <CGd4JSefJvfEVkZEfORzthEIeV53kLk_UkZHAhJGrQ0=.7741b5f2-2227-4017-8164-d54fb9d30d10@github.com>
References: <CGd4JSefJvfEVkZEfORzthEIeV53kLk_UkZHAhJGrQ0=.7741b5f2-2227-4017-8164-d54fb9d30d10@github.com>
Message-ID: <rSP-4Lakd5GW9U6HJZH_0sB_KPaaAP-i6_qN8lgss34=.e92cd7f8-15e8-410a-97dd-e8472fdaaaee@github.com>

On Mon, 7 Nov 2022 14:34:45 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Pull in linker implementation changes, that include non-trivial changes to VM code, from the panama-foreign repo into the main JDK.
> 
> This is split off from the main JEP integration to make reviewing easier.
> 
> This includes the following patches:
> 
> 1. https://github.com/openjdk/panama-foreign/pull/698
> 2. https://github.com/openjdk/panama-foreign/pull/699
> 3. (part of) https://github.com/openjdk/panama-foreign/pull/731
> 4. https://github.com/openjdk/panama-foreign/pull/740
> 5. https://github.com/openjdk/panama-foreign/pull/746
> 6. https://github.com/openjdk/panama-foreign/pull/742
> 7. https://github.com/openjdk/panama-foreign/pull/743
> 
> Probably the biggest change to the code comes from replacing `VMReg` - which can not represent offsets into the stack that are not a multiple of the VM's stack slot size (32-bits) - with the new `VMStorage` class, which can describe byte offsets into the stack, as well as having a register mask to indicate only certain register segments.
> 
> The only part of 3. that is in this PR is the part that turns the `VMStorage` class in Java into a record.
> 
> Please refer to the PR of each individual patch for a more detailed description.

This pull request has now been integrated.

Changeset: 0452c39f
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0452c39fecb7fa4962b00868cb20a50e5f7ab1a7
Stats:     2904 lines in 72 files changed: 1969 ins; 318 del; 617 mod

8296477: Foreign linker implementation update following JEP 434

Co-authored-by: Jorn Vernee <jvernee at openjdk.org>
Co-authored-by: Nick Gasson <ngasson at openjdk.org>
Co-authored-by: Per Minborg <pminborg at openjdk.org>
Reviewed-by: rehn, mcimadamore, vlivanov

-------------

PR: https://git.openjdk.org/jdk/pull/11019

From stuefe at openjdk.org  Mon Dec  5 14:56:18 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 5 Dec 2022 14:56:18 GMT
Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity
In-Reply-To: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
References: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
Message-ID: <1R_ePwUJKNgBklR3_r6KXJJsTAhRcMmkd0Vh-ZAGb_s=.997dab78-f36f-4c2e-9023-0fb3556cf0cc@github.com>

On Tue, 8 Nov 2022 20:18:09 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details.
> 
> Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements.
> 
> Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16.
> 
> Testing:
>  - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390)
>  - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390)
>  - [x] tier1 (x86_64, x86_32, aarch64, riscv)
>  - [x] tier2 (x86_64, aarch64, riscv)
>  - [x] tier3 (x86_64, riscv)

Hi Roman,

nice work. Remarks inline.

Are these all adaptations needed? I wonder about things like SA that know data structure layout.

I ran the SAP nightlies with your patch and, as a test, UseCompressedClassPointers off. That generated a ton of noise unfortunately because many tests were unable to cope. A bunch of tests that created int arrays with Integer.MAX_VALUE-2 failed, but I soon discovered that they also fail in stock if you disable narrow class pointers.

But still, I think it would be useful to disable compressed class pointers (if not set at the command line, make the default false), if only temporarily, and then see which tests fail. I won't have any more time for this before the next year, unfortunately.

Cheers, Thomas

src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp line 199:

> 197: 
> 198:   // Zero first 4 bytes, if start offset is not word aligned.
> 199:   if (!is_aligned(hdr_size_in_bytes, BytesPerWord)) {

Add assertion for alignment to BytesPerInt?

src/hotspot/cpu/x86/macroAssembler_x86.cpp line 4120:

> 4118: // Preserves the contents of address, destroys the contents length_in_bytes and temp.
> 4119: void MacroAssembler::zero_memory(Register address, Register length_in_bytes, int offset_in_bytes, Register temp) {
> 4120:   assert(address != length_in_bytes && address != temp && temp != length_in_bytes, "registers must be different");

While you are here, use "assert_different_registers"?

src/hotspot/cpu/x86/macroAssembler_x86.cpp line 4121:

> 4119: void MacroAssembler::zero_memory(Register address, Register length_in_bytes, int offset_in_bytes, Register temp) {
> 4120:   assert(address != length_in_bytes && address != temp && temp != length_in_bytes, "registers must be different");
> 4121:   assert((offset_in_bytes & (BytesPerInt - 1)) == 0, "offset must be a multiple of BytesPerInt");

use is_aligned() (here and in other places)?

src/hotspot/cpu/x86/macroAssembler_x86.cpp line 4139:

> 4137:   jcc(Assembler::zero, done);
> 4138: #endif
> 4139: 

Just a style nit, my preference would have been to keep the assert section below at the beginning of the function since it guards the entry arguments. Change it to test for length_in_bytes alignment to BytesPerInt. Or, to either BytesPerInt or BytesPerWords, depending on how offset_in_bytes is aligned.

src/hotspot/share/oops/arrayOop.hpp line 141:

> 139: 
> 140:     const size_t max_size_bytes = align_down(SIZE_MAX - base_offset_in_bytes(type), MinObjAlignmentInBytes);
> 141:     const size_t max_elements_per_size_t = max_size_bytes / type2aelembytes(type);

Can we add an assert for max_size_bytes % type2aelembytes(type) == 0?

src/hotspot/share/oops/arrayOop.hpp line 148:

> 146:       // overflowing an int when we add the header. See CRs 4718400 and 7110613.
> 147:       int header_size_words = align_up(base_offset_in_bytes(type), HeapWordSize) / HeapWordSize;
> 148:       return align_down(max_jint - header_size_words, MinObjAlignment);

I somehow was under the impression that for smaller types we should now have a larger max, since we can fit more elements.

src/hotspot/share/oops/objArrayOop.hpp line 84:

> 82:     size_t osz = align_object_size(size_words);
> 83:     assert(osz < max_jint, "no overflow");
> 84:     return osz;

Here, and for some of the other basic functions, some gtests would be nice. Mainly to test outliers like -UseCompressedClassPointers +UseCompressedOops, and with different values for ObjAlignmentInBytes. Can be as simple as this:


TEST_VM(objArrayOopDesc, osize) {
  static const struct {
    int objal; bool ccp; bool coops; int result;
  } x[] = {
//    ObjAligInB, UseCCP, UseCoops, object size in heap words
#ifdef _LP64
    { 8,          false,  false,    4 }, // 20 byte header, 8 byte oops
    { 8,          false,  true,     3 }, // 20 byte header, 4 byte oops
    { 8,          true,   false,    3 }, // 16 byte header, 8 byte oops
    { 8,          true,   true,     3 },  // 16 byte header, 4 byte oops
    { 256, ..... 
    // etc..
#else
    { 8,          false,  false,    4 }, // 12 byte header, 4 byte oops, wordsize 4
#endif
    { -1, false, false, -1 }
  };
  for (int i = 0; x[i].result != -1; i++) {
    if (x[i].objal == (int)ObjectAlignmentInBytes && x[i].ccp == UseCompressedClassPointers && x[i].coops == UseCompressedOops) {
      EXPECT_EQ(objArrayOopDesc::object_size(1), (size_t)x[i].result);
    }
  }
}


and then execute them via the gtest jtreg runner with different settings. For examples, see e.g. https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/gtest/NMTGtests.java 

64bit, UseCCP, UseCoops

test/hotspot/jtreg/runtime/FieldLayout/ArrayBaseOffsets.java line 37:

> 35:  * @modules java.base/jdk.internal.misc
> 36:  * @run main/othervm -XX:+UseCompressedClassPointers ArrayBaseOffsets
> 37:  */

I'd run all permutations of +-UseCCP +-UseCoops

-------------

PR: https://git.openjdk.org/jdk/pull/11044

From stuefe at openjdk.org  Mon Dec  5 14:56:21 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 5 Dec 2022 14:56:21 GMT
Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity
In-Reply-To: <1R_ePwUJKNgBklR3_r6KXJJsTAhRcMmkd0Vh-ZAGb_s=.997dab78-f36f-4c2e-9023-0fb3556cf0cc@github.com>
References: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
 <1R_ePwUJKNgBklR3_r6KXJJsTAhRcMmkd0Vh-ZAGb_s=.997dab78-f36f-4c2e-9023-0fb3556cf0cc@github.com>
Message-ID: <BrkNEsaULOQoRzo2_NTWhk38L79QyV30LlZxvVJmWqc=.6f34cbbb-dff6-4f57-bf82-6d080c307d34@github.com>

On Mon, 5 Dec 2022 12:57:12 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details.
>> 
>> Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements.
>> 
>> Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16.
>> 
>> Testing:
>>  - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390)
>>  - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390)
>>  - [x] tier1 (x86_64, x86_32, aarch64, riscv)
>>  - [x] tier2 (x86_64, aarch64, riscv)
>>  - [x] tier3 (x86_64, riscv)
>
> src/hotspot/share/oops/arrayOop.hpp line 141:
> 
>> 139: 
>> 140:     const size_t max_size_bytes = align_down(SIZE_MAX - base_offset_in_bytes(type), MinObjAlignmentInBytes);
>> 141:     const size_t max_elements_per_size_t = max_size_bytes / type2aelembytes(type);
> 
> Can we add an assert for max_size_bytes % type2aelembytes(type) == 0?

Also, this is pre-existing, but I wonder why this section exists for 64-bit. Regardless of the array type, we will cap out below and return INT_MAX-2 or -3, depending on UseCCP. Why even bother calculating this? Am I missing something?

-------------

PR: https://git.openjdk.org/jdk/pull/11044

From mdoerr at openjdk.org  Mon Dec  5 14:57:02 2022
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 5 Dec 2022 14:57:02 GMT
Subject: RFR: 8291302: ARM32: nmethod entry barriers support [v2]
In-Reply-To: <JghFO_YuAWdgvKFJpaUzuiaeLYjRrRav4hfR0u2LkWw=.529baf93-df04-4c3a-9ed2-fd884f2cd60b@github.com>
References: <BJaszr0_haU4UZOyQQEA9P0SOlgtfTtGFBj9VSRD5SM=.ffd6af56-a51e-4627-90cb-0eb0e1bbd5e8@github.com>
 <JghFO_YuAWdgvKFJpaUzuiaeLYjRrRav4hfR0u2LkWw=.529baf93-df04-4c3a-9ed2-fd884f2cd60b@github.com>
Message-ID: <eEgeEjW5rY-XUYoIPAo3glxmhKESfURCutuiICm9dkU=.c6198a1b-3798-4c99-b7ff-7bad5a314130@github.com>

On Mon, 5 Dec 2022 14:19:55 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

>> This PR implements nmethod entry barriers for ARM32. It has already been implemented for other ports and is related with JDK-8290025 "Remove the Sweeper".
>
> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   save float registers

Please note that the memory barrier has caused a performance regression on PPC64 (as on AArch64): https://bugs.openjdk.org/browse/JDK-8295069
I'd probably assert `nmethod_patching_type() == NMethodPatchingType::stw_instruction_and_data_patch` instead of emitting a memory barrier because `LoadLoad` may or may not be strong enough depending on usage (e.g. generational ZGC uses instruction patching as well).

-------------

PR: https://git.openjdk.org/jdk/pull/11442

From jvernee at openjdk.org  Mon Dec  5 14:58:15 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 5 Dec 2022 14:58:15 GMT
Subject: RFR: 8297729: Replace GrowableArray in ComputeMoveOrder with hash
 table [v2]
In-Reply-To: <Ri3rjM85k80rxq7ZGW8aSHOu-ScyvzVukhVGo649UkM=.784d7aad-248f-4d20-9c5a-a7c765b6b6ab@github.com>
References: <Ri3rjM85k80rxq7ZGW8aSHOu-ScyvzVukhVGo649UkM=.784d7aad-248f-4d20-9c5a-a7c765b6b6ab@github.com>
Message-ID: <Va6l8fWbYDtFv5fXpthjeFKQdqlkuCQmIjeNCxRPNP0=.cf1544f9-111d-438d-b9ce-4d20d3f7b955@github.com>

> Replaces the GrowableArray 'table' in ComputeMoveOrder with a real hash table.
> 
> Through testing, I found that sometimes this array is blown up to several thousand elements, most of which are `NULL`. Using a hash table prevents this large wastage.
> 
> I've touched up some of the surrounding code as well. Mostly style changes, but I've also removed the `BasicType` field from the `Move` and `MoveOperation` structs, since it was unused, and added frame data storages to the fast path for stack args as well, since both are allocated on the stack.
> 
> Testing: `jdk_foreign` test suite.

Jorn Vernee 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 86 additional commits since the last revision:

 - Drop redundant friend decl
 - improve hash slightly
 - Use hashtable in ComputeMoveOrder + general cleanup
 - use Arena in example
 - Merge branch 'PR_20' into VM_Changes
 - Address more review comments
 - Fix bad @throws in MemorySegment::copy methods
 - Address review comments
 - Fix typo in SegmentScope javadoc
 - Fix @since tag in SegmentScope
 - ... and 76 more: https://git.openjdk.org/jdk/compare/884c0f38...6b10ae38

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11392/files
  - new: https://git.openjdk.org/jdk/pull/11392/files/6b10ae38..6b10ae38

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11392&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11392&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11392.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11392/head:pull/11392

PR: https://git.openjdk.org/jdk/pull/11392

From dnsimon at openjdk.org  Mon Dec  5 15:12:00 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 5 Dec 2022 15:12:00 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v3]
In-Reply-To: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
Message-ID: <4s8KhdEGfNlL4pFBC7oqVrXR0bqPp7eocJmd8i49YCo=.b937f324-8d14-4d0f-9bb1-36cf33a59f7b@github.com>

> Libgraal is compiled ahead of time and should not need any JVMCI Java code to be dynamically loaded at runtime. Prior to this PR, this is not the case due to:
> 
> * Code to copy system properties from the HotSpot heap into the libgraal heap. This is in `jdk.vm.ci.services.Services.initializeSavedProperties(byte[])` and `jdk.vm.ci.services.Services.serializeSavedProperties()`. This code should be moved to `java.base/jdk.internal.vm.VMSupport`.
> * Code to translate exceptions from the HotSpot heap into the libgraal heap and vice versa. This code should be moved from `jdk.internal.vm.ci//jdk.vm.ci.hotspot.TranslatedException` to `java.base/jdk.internal.vm.VMSupport`.
> 
> This PR makes the above changes. As a result, it's possible to build a JDK image that includes (and uses) libgraal but does not include `jdk.internal.vm.ci` or `jdk.internal.vm.compiler`. This both reduces footprint and better isolates the JAVMCI and the Graal compiler as accessing these components from Java code is now impossible.

Doug Simon has updated the pull request incrementally with one additional commit since the last revision:

  share code to create the exploded path for a module and avoid stack-based variable length array

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11513/files
  - new: https://git.openjdk.org/jdk/pull/11513/files/3e89d402..7b147f2f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11513&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11513&range=01-02

  Stats: 28 lines in 1 file changed: 15 ins; 11 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11513.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11513/head:pull/11513

PR: https://git.openjdk.org/jdk/pull/11513

From iwalulya at openjdk.org  Mon Dec  5 15:14:12 2022
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 5 Dec 2022 15:14:12 GMT
Subject: RFR: 8296401: ConcurrentHashTable::bulk_delete might miss to
 delete some objects
In-Reply-To: <oh4H4jjhdQ2TR37v4PsDr99lVtux72HC5gnUkCo5TgQ=.620d2b25-916c-42a5-b655-1cdf5dbd2328@github.com>
References: <rWw3Hb1baG5eslMgFnOdEP1Q4avhfYc3uTpjdB9DaP0=.23f34ff0-eff9-421b-9e70-7f119fd90e5d@github.com>
 <srzYQG8vQxXtFu8IYd4LzHoFZo6VR8_D_9e5wlek0u4=.c3fb4829-6de5-428e-9b70-f34aeba9c55f@github.com>
 <XlpaIj9dRjwUPkQTmLqfWNx7r4afKUu5cE4xUDRwNgw=.96918f61-bb6d-4d92-995d-d763adf6df63@github.com>
 <-46D7o9D9hweEylWT61buGVsoYYFZLlKezzaBgt7GvQ=.7e7b3755-98cb-4696-ba07-0ba3b7046a4a@github.com>
 <oh4H4jjhdQ2TR37v4PsDr99lVtux72HC5gnUkCo5TgQ=.620d2b25-916c-42a5-b655-1cdf5dbd2328@github.com>
Message-ID: <_bNq28p7YDTdicn_-pwN-xB-CHeMUUtTsJfCLTV_CGw=.d82a1a64-7f07-472d-af3c-427fba8598d1@github.com>

On Mon, 5 Dec 2022 13:35:32 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> That is true. Do you think that is a problem with the new implementation?
The change overrides the intentions of `BULK_DELETE_LIMIT ` so it would be better to change the name of that constant.

-------------

PR: https://git.openjdk.org/jdk/pull/10983

From jvernee at openjdk.org  Mon Dec  5 15:41:33 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 5 Dec 2022 15:41:33 GMT
Subject: RFR: 8297729: Replace GrowableArray in ComputeMoveOrder with hash
 table [v3]
In-Reply-To: <Ri3rjM85k80rxq7ZGW8aSHOu-ScyvzVukhVGo649UkM=.784d7aad-248f-4d20-9c5a-a7c765b6b6ab@github.com>
References: <Ri3rjM85k80rxq7ZGW8aSHOu-ScyvzVukhVGo649UkM=.784d7aad-248f-4d20-9c5a-a7c765b6b6ab@github.com>
Message-ID: <SMYlVfEGdz9ml-b1QjfvTqLYYyZzcqiaXAhAX_6FUck=.c702fd05-4327-4b26-a961-0949e580866d@github.com>

> Replaces the GrowableArray 'table' in ComputeMoveOrder with a real hash table.
> 
> Through testing, I found that sometimes this array is blown up to several thousand elements, most of which are `NULL`. Using a hash table prevents this large wastage.
> 
> I've touched up some of the surrounding code as well. Mostly style changes, but I've also removed the `BasicType` field from the `Move` and `MoveOperation` structs, since it was unused, and added frame data storages to the fast path for stack args as well, since both are allocated on the stack.
> 
> Testing: `jdk_foreign` test suite.

Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Drop redundant friend decl
 - improve hash slightly
 - Use hashtable in ComputeMoveOrder + general cleanup

-------------

Changes: https://git.openjdk.org/jdk/pull/11392/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11392&range=02
  Stats: 61 lines in 2 files changed: 20 ins; 10 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/11392.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11392/head:pull/11392

PR: https://git.openjdk.org/jdk/pull/11392

From alanb at openjdk.org  Mon Dec  5 16:02:11 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 5 Dec 2022 16:02:11 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v2]
In-Reply-To: <y4lLPk5mDrJNa9vzgiI5WyEJmfbsSRfBBi0QQNdZeEs=.24e2a234-f42e-456f-82a0-3c7fd05dc9c5@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
 <WgaYQgGsrCaoiwDikHOB0em7NhpCugMEVevsNKByQrE=.3a67835a-633c-4b29-be22-bcb2fc2ba40a@github.com>
 <y4lLPk5mDrJNa9vzgiI5WyEJmfbsSRfBBi0QQNdZeEs=.24e2a234-f42e-456f-82a0-3c7fd05dc9c5@github.com>
Message-ID: <QYgHuAV90EyFwfNKauCVbQlKfWn9eBywsWGk57WrAgI=.21985534-6c5a-4bba-a35d-b727a6ae4ba4@github.com>

On Mon, 5 Dec 2022 13:53:07 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   generalized ClassLoader::has_jvmci_module to is_module_resolvable
>
> src/hotspot/share/classfile/classLoader.hpp line 378:
> 
>> 376: 
>> 377:   // Determines if the `module_name` module is resolvable.
>> 378:   static bool is_module_resolvable(const char* module_name);
> 
> Is "resolvable" the right concept here? Or should it be something like "findable" instead?

Assuming --limit-modules isn't used, it is testing if the module is "observable".

-------------

PR: https://git.openjdk.org/jdk/pull/11513

From avoitylov at openjdk.org  Mon Dec  5 16:30:10 2022
From: avoitylov at openjdk.org (Aleksei Voitylov)
Date: Mon, 5 Dec 2022 16:30:10 GMT
Subject: RFR: 8291302: ARM32: nmethod entry barriers support [v3]
In-Reply-To: <BJaszr0_haU4UZOyQQEA9P0SOlgtfTtGFBj9VSRD5SM=.ffd6af56-a51e-4627-90cb-0eb0e1bbd5e8@github.com>
References: <BJaszr0_haU4UZOyQQEA9P0SOlgtfTtGFBj9VSRD5SM=.ffd6af56-a51e-4627-90cb-0eb0e1bbd5e8@github.com>
Message-ID: <CvCmZ8kG6ZPsDJjDoCpixYpAi7f0HGy_xSQgt0s8zac=.440f9eea-6855-42a0-9434-c779ccda5e3f@github.com>

> This PR implements nmethod entry barriers for ARM32. It has already been implemented for other ports and is related with JDK-8290025 "Remove the Sweeper".

Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:

  remove membar

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11442/files
  - new: https://git.openjdk.org/jdk/pull/11442/files/34a17994..02439515

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11442&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11442&range=01-02

  Stats: 20 lines in 4 files changed: 11 ins; 4 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/11442.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11442/head:pull/11442

PR: https://git.openjdk.org/jdk/pull/11442

From avoitylov at openjdk.org  Mon Dec  5 16:30:11 2022
From: avoitylov at openjdk.org (Aleksei Voitylov)
Date: Mon, 5 Dec 2022 16:30:11 GMT
Subject: RFR: 8291302: ARM32: nmethod entry barriers support [v3]
In-Reply-To: <CvCmZ8kG6ZPsDJjDoCpixYpAi7f0HGy_xSQgt0s8zac=.440f9eea-6855-42a0-9434-c779ccda5e3f@github.com>
References: <BJaszr0_haU4UZOyQQEA9P0SOlgtfTtGFBj9VSRD5SM=.ffd6af56-a51e-4627-90cb-0eb0e1bbd5e8@github.com>
 <CvCmZ8kG6ZPsDJjDoCpixYpAi7f0HGy_xSQgt0s8zac=.440f9eea-6855-42a0-9434-c779ccda5e3f@github.com>
Message-ID: <vtSJ_j3M_8dDtOuOPE0J9MpfzkruGbbtI5gsXdhl2UA=.8bfd0429-da62-45b7-9cae-735de627adf4@github.com>

On Mon, 5 Dec 2022 16:21:30 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

>> This PR implements nmethod entry barriers for ARM32. It has already been implemented for other ports and is related with JDK-8290025 "Remove the Sweeper".
>
> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove membar

The removed membar can be added later if and when support for other GCs is added to ARM32.

-------------

PR: https://git.openjdk.org/jdk/pull/11442

From avoitylov at openjdk.org  Mon Dec  5 16:30:13 2022
From: avoitylov at openjdk.org (Aleksei Voitylov)
Date: Mon, 5 Dec 2022 16:30:13 GMT
Subject: RFR: 8291302: ARM32: nmethod entry barriers support [v3]
In-Reply-To: <vENPpkRJ7ZlN6k5ymTCUUiESeWfx6ibyJdTpjPMIjvw=.445df16d-28ca-47ec-9a6b-2bbc1cd7ae95@github.com>
References: <BJaszr0_haU4UZOyQQEA9P0SOlgtfTtGFBj9VSRD5SM=.ffd6af56-a51e-4627-90cb-0eb0e1bbd5e8@github.com>
 <vENPpkRJ7ZlN6k5ymTCUUiESeWfx6ibyJdTpjPMIjvw=.445df16d-28ca-47ec-9a6b-2bbc1cd7ae95@github.com>
Message-ID: <yXHL12HCx4xOqUa1BFQBrNwEBUDHzKCBLIWm7i173XI=.1258f4b6-bd02-41d5-96f2-381ee8278d15@github.com>

On Thu, 1 Dec 2022 08:09:29 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove membar
>
> src/hotspot/cpu/arm/gc/shared/barrierSetAssembler_arm.cpp line 221:
> 
>> 219:   // Subsequent loads of oops must occur after load of guard value.
>> 220:   // BarrierSetNMethod::disarm sets guard with release semantics.
>> 221:   __ membar(MacroAssembler::LoadLoad, tmp1);
> 
> Is my assumption correct that ARM32 supports neither ZGC nor ShenandoahGC?
> If so then no memory barrier is needed as no oops are modified concurrently with G1 (and other GCs are not concurrent).
> I'd recomment to implement `BarrierSetAssembler::nmethod_patching_type()` as on AARCH64 and replace the membar with an assertion that `NMethodPatchingType::stw_instruction_and_data_patch` is in effect.
> @fisk wouldn't it be good if there was a shared method to query if oops (other values?) are modified concurrently?

The membar is now removed.

-------------

PR: https://git.openjdk.org/jdk/pull/11442

From coleenp at openjdk.org  Mon Dec  5 17:10:19 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 5 Dec 2022 17:10:19 GMT
Subject: RFR: 8297729: Replace GrowableArray in ComputeMoveOrder with hash
 table [v3]
In-Reply-To: <SMYlVfEGdz9ml-b1QjfvTqLYYyZzcqiaXAhAX_6FUck=.c702fd05-4327-4b26-a961-0949e580866d@github.com>
References: <Ri3rjM85k80rxq7ZGW8aSHOu-ScyvzVukhVGo649UkM=.784d7aad-248f-4d20-9c5a-a7c765b6b6ab@github.com>
 <SMYlVfEGdz9ml-b1QjfvTqLYYyZzcqiaXAhAX_6FUck=.c702fd05-4327-4b26-a961-0949e580866d@github.com>
Message-ID: <3npr6eNZbJXq7reXXE8Uh0nQsFUt5m0eBvOuJACbcek=.9247dfc3-0c54-468a-888d-514f0698642d@github.com>

On Mon, 5 Dec 2022 15:41:33 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Replaces the GrowableArray 'table' in ComputeMoveOrder with a real hash table.
>> 
>> Through testing, I found that sometimes this array is blown up to several thousand elements, most of which are `NULL`. Using a hash table prevents this large wastage.
>> 
>> I've touched up some of the surrounding code as well. Mostly style changes, but I've also removed the `BasicType` field from the `Move` and `MoveOperation` structs, since it was unused, and added frame data storages to the fast path for stack args as well, since both are allocated on the stack.
>> 
>> Testing: `jdk_foreign` test suite.
>
> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Drop redundant friend decl
>  - improve hash slightly
>  - Use hashtable in ComputeMoveOrder + general cleanup

Seems ok.

src/hotspot/share/prims/foreignGlobals.cpp line 200:

> 198:     mtInternal,
> 199:     ComputeMoveOrder::hash,
> 200:     ::operator==

Is this the same as primitive_equals ?

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11392

From coleenp at openjdk.org  Mon Dec  5 17:10:22 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 5 Dec 2022 17:10:22 GMT
Subject: RFR: 8297729: Replace GrowableArray in ComputeMoveOrder with hash
 table [v3]
In-Reply-To: <3npr6eNZbJXq7reXXE8Uh0nQsFUt5m0eBvOuJACbcek=.9247dfc3-0c54-468a-888d-514f0698642d@github.com>
References: <Ri3rjM85k80rxq7ZGW8aSHOu-ScyvzVukhVGo649UkM=.784d7aad-248f-4d20-9c5a-a7c765b6b6ab@github.com>
 <SMYlVfEGdz9ml-b1QjfvTqLYYyZzcqiaXAhAX_6FUck=.c702fd05-4327-4b26-a961-0949e580866d@github.com>
 <3npr6eNZbJXq7reXXE8Uh0nQsFUt5m0eBvOuJACbcek=.9247dfc3-0c54-468a-888d-514f0698642d@github.com>
Message-ID: <r93xOVbaN_mH9_ojjXQmnJUqQf--7oS1IbckeoXx-bI=.9f275086-b962-4d3a-a128-6894bc85ce7c@github.com>

On Mon, 5 Dec 2022 16:39:20 GMT, Coleen Phillimore <coleenp at openjdk.org> 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 three commits:
>> 
>>  - Drop redundant friend decl
>>  - improve hash slightly
>>  - Use hashtable in ComputeMoveOrder + general cleanup
>
> src/hotspot/share/prims/foreignGlobals.cpp line 200:
> 
>> 198:     mtInternal,
>> 199:     ComputeMoveOrder::hash,
>> 200:     ::operator==
> 
> Is this the same as primitive_equals ?

would prefer primitive_equals or use the default parameter.

-------------

PR: https://git.openjdk.org/jdk/pull/11392

From jvernee at openjdk.org  Mon Dec  5 17:10:23 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 5 Dec 2022 17:10:23 GMT
Subject: RFR: 8297729: Replace GrowableArray in ComputeMoveOrder with hash
 table [v3]
In-Reply-To: <r93xOVbaN_mH9_ojjXQmnJUqQf--7oS1IbckeoXx-bI=.9f275086-b962-4d3a-a128-6894bc85ce7c@github.com>
References: <Ri3rjM85k80rxq7ZGW8aSHOu-ScyvzVukhVGo649UkM=.784d7aad-248f-4d20-9c5a-a7c765b6b6ab@github.com>
 <SMYlVfEGdz9ml-b1QjfvTqLYYyZzcqiaXAhAX_6FUck=.c702fd05-4327-4b26-a961-0949e580866d@github.com>
 <3npr6eNZbJXq7reXXE8Uh0nQsFUt5m0eBvOuJACbcek=.9247dfc3-0c54-468a-888d-514f0698642d@github.com>
 <r93xOVbaN_mH9_ojjXQmnJUqQf--7oS1IbckeoXx-bI=.9f275086-b962-4d3a-a128-6894bc85ce7c@github.com>
Message-ID: <r5Ueaftkq6vLbKZrdBtfx_xzg9Vya2T6jOYTKg9Ld8k=.d17ea17b-837a-4fd9-b78c-800419a3c109@github.com>

On Mon, 5 Dec 2022 17:02:46 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/prims/foreignGlobals.cpp line 200:
>> 
>>> 198:     mtInternal,
>>> 199:     ComputeMoveOrder::hash,
>>> 200:     ::operator==
>> 
>> Is this the same as primitive_equals ?
>
> would prefer primitive_equals or use the default parameter.

This is referencing the global `operator==` defined for `VMStorage` here: https://github.com/openjdk/jdk/blob/6a7a0db587446160e77c9ac225669e5a0c9bc638/src/hotspot/share/prims/vmstorage.hpp#L92

If you like, I can define a wrapper similar to the `hash` function for this as well.

-------------

PR: https://git.openjdk.org/jdk/pull/11392

From jvernee at openjdk.org  Mon Dec  5 17:10:23 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 5 Dec 2022 17:10:23 GMT
Subject: RFR: 8297729: Replace GrowableArray in ComputeMoveOrder with hash
 table [v3]
In-Reply-To: <r5Ueaftkq6vLbKZrdBtfx_xzg9Vya2T6jOYTKg9Ld8k=.d17ea17b-837a-4fd9-b78c-800419a3c109@github.com>
References: <Ri3rjM85k80rxq7ZGW8aSHOu-ScyvzVukhVGo649UkM=.784d7aad-248f-4d20-9c5a-a7c765b6b6ab@github.com>
 <SMYlVfEGdz9ml-b1QjfvTqLYYyZzcqiaXAhAX_6FUck=.c702fd05-4327-4b26-a961-0949e580866d@github.com>
 <3npr6eNZbJXq7reXXE8Uh0nQsFUt5m0eBvOuJACbcek=.9247dfc3-0c54-468a-888d-514f0698642d@github.com>
 <r93xOVbaN_mH9_ojjXQmnJUqQf--7oS1IbckeoXx-bI=.9f275086-b962-4d3a-a128-6894bc85ce7c@github.com>
 <r5Ueaftkq6vLbKZrdBtfx_xzg9Vya2T6jOYTKg9Ld8k=.d17ea17b-837a-4fd9-b78c-800419a3c109@github.com>
Message-ID: <iJA2H91ZK1i4ixeyhnrTIauE30TvAemdXvruILCDSP4=.b8038cb0-99a3-439f-ac30-a92780423521@github.com>

On Mon, 5 Dec 2022 17:03:46 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> would prefer primitive_equals or use the default parameter.
>
> This is referencing the global `operator==` defined for `VMStorage` here: https://github.com/openjdk/jdk/blob/6a7a0db587446160e77c9ac225669e5a0c9bc638/src/hotspot/share/prims/vmstorage.hpp#L92
> 
> If you like, I can define a wrapper similar to the `hash` function for this as well.

Actually, now that you mention it. I think we need another `equals` function that ignores the `segment_mask_or_size` field just like the `hash` function does.

I will update the PR.

-------------

PR: https://git.openjdk.org/jdk/pull/11392

From dnsimon at openjdk.org  Mon Dec  5 17:21:18 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 5 Dec 2022 17:21:18 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v2]
In-Reply-To: <QYgHuAV90EyFwfNKauCVbQlKfWn9eBywsWGk57WrAgI=.21985534-6c5a-4bba-a35d-b727a6ae4ba4@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
 <WgaYQgGsrCaoiwDikHOB0em7NhpCugMEVevsNKByQrE=.3a67835a-633c-4b29-be22-bcb2fc2ba40a@github.com>
 <y4lLPk5mDrJNa9vzgiI5WyEJmfbsSRfBBi0QQNdZeEs=.24e2a234-f42e-456f-82a0-3c7fd05dc9c5@github.com>
 <QYgHuAV90EyFwfNKauCVbQlKfWn9eBywsWGk57WrAgI=.21985534-6c5a-4bba-a35d-b727a6ae4ba4@github.com>
Message-ID: <0olqajdnsOZJqQC5xBjXS3ckays3qNmgcYk4at6tsCc=.baeb2628-eee8-430c-a101-b93ad7a51e58@github.com>

On Mon, 5 Dec 2022 15:58:19 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/hotspot/share/classfile/classLoader.hpp line 378:
>> 
>>> 376: 
>>> 377:   // Determines if the `module_name` module is resolvable.
>>> 378:   static bool is_module_resolvable(const char* module_name);
>> 
>> Is "resolvable" the right concept here? Or should it be something like "findable" instead?
>
> Assuming --limit-modules isn't used, it is testing if the module is "observable".

I assume this function should therefore be named `is_module_observable`?

-------------

PR: https://git.openjdk.org/jdk/pull/11513

From dnsimon at openjdk.org  Mon Dec  5 17:33:50 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 5 Dec 2022 17:33:50 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v2]
In-Reply-To: <0olqajdnsOZJqQC5xBjXS3ckays3qNmgcYk4at6tsCc=.baeb2628-eee8-430c-a101-b93ad7a51e58@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
 <WgaYQgGsrCaoiwDikHOB0em7NhpCugMEVevsNKByQrE=.3a67835a-633c-4b29-be22-bcb2fc2ba40a@github.com>
 <y4lLPk5mDrJNa9vzgiI5WyEJmfbsSRfBBi0QQNdZeEs=.24e2a234-f42e-456f-82a0-3c7fd05dc9c5@github.com>
 <QYgHuAV90EyFwfNKauCVbQlKfWn9eBywsWGk57WrAgI=.21985534-6c5a-4bba-a35d-b727a6ae4ba4@github.com>
 <0olqajdnsOZJqQC5xBjXS3ckays3qNmgcYk4at6tsCc=.baeb2628-eee8-430c-a101-b93ad7a51e58@github.com>
Message-ID: <34Xd2rKs-dAQSCf2dNwwrTZ3uFmFjCYsqagEF3aE0Z8=.e689feb9-dc85-4d24-af4a-e43f46276eb0@github.com>

On Mon, 5 Dec 2022 17:17:16 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Assuming --limit-modules isn't used, it is testing if the module is "observable".
>
> I assume this function should therefore be named `is_module_observable`?

How about this:

// Determines if the named module is present in the
// modules jimage file or in the exploded modules directory.
static bool is_module_observable(const char* module_name);

-------------

PR: https://git.openjdk.org/jdk/pull/11513

From dnsimon at openjdk.org  Mon Dec  5 17:45:25 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 5 Dec 2022 17:45:25 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v4]
In-Reply-To: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
Message-ID: <nm5MBsIexi02WmVomf-rKb-xWg064Pqg9WMKxb18PBw=.9d5209a3-675e-4ee2-a4d5-05ff14934fb3@github.com>

> Libgraal is compiled ahead of time and should not need any JVMCI Java code to be dynamically loaded at runtime. Prior to this PR, this is not the case due to:
> 
> * Code to copy system properties from the HotSpot heap into the libgraal heap. This is in `jdk.vm.ci.services.Services.initializeSavedProperties(byte[])` and `jdk.vm.ci.services.Services.serializeSavedProperties()`. This code should be moved to `java.base/jdk.internal.vm.VMSupport`.
> * Code to translate exceptions from the HotSpot heap into the libgraal heap and vice versa. This code should be moved from `jdk.internal.vm.ci//jdk.vm.ci.hotspot.TranslatedException` to `java.base/jdk.internal.vm.VMSupport`.
> 
> This PR makes the above changes. As a result, it's possible to build a JDK image that includes (and uses) libgraal but does not include `jdk.internal.vm.ci` or `jdk.internal.vm.compiler`. This both reduces footprint and better isolates the JAVMCI and the Graal compiler as accessing these components from Java code is now impossible.

Doug Simon has updated the pull request incrementally with one additional commit since the last revision:

  renamed is_module_resolvable to is_module_observable

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11513/files
  - new: https://git.openjdk.org/jdk/pull/11513/files/7b147f2f..29e100b3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11513&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11513&range=02-03

  Stats: 9 lines in 4 files changed: 1 ins; 4 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/11513.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11513/head:pull/11513

PR: https://git.openjdk.org/jdk/pull/11513

From jvernee at openjdk.org  Mon Dec  5 17:48:18 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 5 Dec 2022 17:48:18 GMT
Subject: RFR: 8297729: Replace GrowableArray in ComputeMoveOrder with hash
 table [v4]
In-Reply-To: <Ri3rjM85k80rxq7ZGW8aSHOu-ScyvzVukhVGo649UkM=.784d7aad-248f-4d20-9c5a-a7c765b6b6ab@github.com>
References: <Ri3rjM85k80rxq7ZGW8aSHOu-ScyvzVukhVGo649UkM=.784d7aad-248f-4d20-9c5a-a7c765b6b6ab@github.com>
Message-ID: <7_QJczeDSQXX_WvmBdQElDnv0JOpkLamadBgGrcbcng=.00d425e5-2932-4dfb-9381-a1f1910effbe@github.com>

> Replaces the GrowableArray 'table' in ComputeMoveOrder with a real hash table.
> 
> Through testing, I found that sometimes this array is blown up to several thousand elements, most of which are `NULL`. Using a hash table prevents this large wastage.
> 
> I've touched up some of the surrounding code as well. Mostly style changes, but I've also removed the `BasicType` field from the `Move` and `MoveOperation` structs, since it was unused, and added frame data storages to the fast path for stack args as well, since both are allocated on the stack.
> 
> Testing: `jdk_foreign` test suite.

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Use specialized equals function

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11392/files
  - new: https://git.openjdk.org/jdk/pull/11392/files/40e66a7c..22ae2770

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11392&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11392&range=02-03

  Stats: 10 lines in 1 file changed: 6 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11392.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11392/head:pull/11392

PR: https://git.openjdk.org/jdk/pull/11392

From jvernee at openjdk.org  Mon Dec  5 17:48:18 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 5 Dec 2022 17:48:18 GMT
Subject: RFR: 8297729: Replace GrowableArray in ComputeMoveOrder with hash
 table [v3]
In-Reply-To: <iJA2H91ZK1i4ixeyhnrTIauE30TvAemdXvruILCDSP4=.b8038cb0-99a3-439f-ac30-a92780423521@github.com>
References: <Ri3rjM85k80rxq7ZGW8aSHOu-ScyvzVukhVGo649UkM=.784d7aad-248f-4d20-9c5a-a7c765b6b6ab@github.com>
 <SMYlVfEGdz9ml-b1QjfvTqLYYyZzcqiaXAhAX_6FUck=.c702fd05-4327-4b26-a961-0949e580866d@github.com>
 <3npr6eNZbJXq7reXXE8Uh0nQsFUt5m0eBvOuJACbcek=.9247dfc3-0c54-468a-888d-514f0698642d@github.com>
 <r93xOVbaN_mH9_ojjXQmnJUqQf--7oS1IbckeoXx-bI=.9f275086-b962-4d3a-a128-6894bc85ce7c@github.com>
 <r5Ueaftkq6vLbKZrdBtfx_xzg9Vya2T6jOYTKg9Ld8k=.d17ea17b-837a-4fd9-b78c-800419a3c109@github.com>
 <iJA2H91ZK1i4ixeyhnrTIauE30TvAemdXvruILCDSP4=.b8038cb0-99a3-439f-ac30-a92780423521@github.com>
Message-ID: <Qp-RRwJHwgwtuW_hbvRePa3hlDsTnF1wiV4OpXzOqE4=.af18c54e-b07c-41cd-bbb7-acdffd76e7a6@github.com>

On Mon, 5 Dec 2022 17:05:38 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This is referencing the global `operator==` defined for `VMStorage` here: https://github.com/openjdk/jdk/blob/6a7a0db587446160e77c9ac225669e5a0c9bc638/src/hotspot/share/prims/vmstorage.hpp#L92
>> 
>> If you like, I can define a wrapper similar to the `hash` function for this as well.
>
> Actually, now that you mention it. I think we need another `equals` function that ignores the `segment_mask_or_size` field just like the `hash` function does.
> 
> I will update the PR.

I've added a specialized `equals` function that ignores the `segment_mask_or_size` field, and changed the template parameter to use that.

-------------

PR: https://git.openjdk.org/jdk/pull/11392

From jsjolen at openjdk.org  Mon Dec  5 18:01:17 2022
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 5 Dec 2022 18:01:17 GMT
Subject: RFR: 8297729: Replace GrowableArray in ComputeMoveOrder with hash
 table [v4]
In-Reply-To: <7_QJczeDSQXX_WvmBdQElDnv0JOpkLamadBgGrcbcng=.00d425e5-2932-4dfb-9381-a1f1910effbe@github.com>
References: <Ri3rjM85k80rxq7ZGW8aSHOu-ScyvzVukhVGo649UkM=.784d7aad-248f-4d20-9c5a-a7c765b6b6ab@github.com>
 <7_QJczeDSQXX_WvmBdQElDnv0JOpkLamadBgGrcbcng=.00d425e5-2932-4dfb-9381-a1f1910effbe@github.com>
Message-ID: <0rKx3AMPanaRjBmdq7LIdTohR4biCKDh5MJ5Hzddc_M=.30d39fd9-7dbe-464e-ae0a-c7717b0209e8@github.com>

On Mon, 5 Dec 2022 17:48:18 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Replaces the GrowableArray 'table' in ComputeMoveOrder with a real hash table.
>> 
>> Through testing, I found that sometimes this array is blown up to several thousand elements, most of which are `NULL`. Using a hash table prevents this large wastage.
>> 
>> I've touched up some of the surrounding code as well. Mostly style changes, but I've also removed the `BasicType` field from the `Move` and `MoveOperation` structs, since it was unused, and added frame data storages to the fast path for stack args as well, since both are allocated on the stack.
>> 
>> Testing: `jdk_foreign` test suite.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use specialized equals function

Looks good, thank you for the changes.

-------------

Marked as reviewed by jsjolen (Committer).

PR: https://git.openjdk.org/jdk/pull/11392

From jvernee at openjdk.org  Mon Dec  5 20:50:26 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 5 Dec 2022 20:50:26 GMT
Subject: Integrated: 8297729: Replace GrowableArray in ComputeMoveOrder with
 hash table
In-Reply-To: <Ri3rjM85k80rxq7ZGW8aSHOu-ScyvzVukhVGo649UkM=.784d7aad-248f-4d20-9c5a-a7c765b6b6ab@github.com>
References: <Ri3rjM85k80rxq7ZGW8aSHOu-ScyvzVukhVGo649UkM=.784d7aad-248f-4d20-9c5a-a7c765b6b6ab@github.com>
Message-ID: <gHHUL8FkvxXjoOP3263Ax_tE-NeFoOB2mGaMDPxrviY=.2383293b-6fd3-40cf-9d33-e0061fb1ce11@github.com>

On Mon, 28 Nov 2022 16:51:31 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Replaces the GrowableArray 'table' in ComputeMoveOrder with a real hash table.
> 
> Through testing, I found that sometimes this array is blown up to several thousand elements, most of which are `NULL`. Using a hash table prevents this large wastage.
> 
> I've touched up some of the surrounding code as well. Mostly style changes, but I've also removed the `BasicType` field from the `Move` and `MoveOperation` structs, since it was unused, and added frame data storages to the fast path for stack args as well, since both are allocated on the stack.
> 
> Testing: `jdk_foreign` test suite.

This pull request has now been integrated.

Changeset: da0917a2
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/da0917a2ae148ccb415accffbe1117a3dc5fdf2d
Stats:     64 lines in 2 files changed: 23 ins; 10 del; 31 mod

8297729: Replace GrowableArray in ComputeMoveOrder with hash table

Reviewed-by: coleenp, jsjolen

-------------

PR: https://git.openjdk.org/jdk/pull/11392

From mdoerr at openjdk.org  Mon Dec  5 21:02:25 2022
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 5 Dec 2022 21:02:25 GMT
Subject: RFR: 8291302: ARM32: nmethod entry barriers support [v3]
In-Reply-To: <HxQV6kEQtYJIeUi66Ww8CTqY1oDyhFa2w9-VoPnSZHc=.30bee5ca-6bb8-4dbb-b793-c251172fe38e@github.com>
References: <BJaszr0_haU4UZOyQQEA9P0SOlgtfTtGFBj9VSRD5SM=.ffd6af56-a51e-4627-90cb-0eb0e1bbd5e8@github.com>
 <vENPpkRJ7ZlN6k5ymTCUUiESeWfx6ibyJdTpjPMIjvw=.445df16d-28ca-47ec-9a6b-2bbc1cd7ae95@github.com>
 <MvWj6e6BaqAiu-k1lRqf96Uc16JlbykXsRrNGeLHVkw=.c6ba6c5c-c62b-4f42-a4a3-177ef7826571@github.com>
 <HxQV6kEQtYJIeUi66Ww8CTqY1oDyhFa2w9-VoPnSZHc=.30bee5ca-6bb8-4dbb-b793-c251172fe38e@github.com>
Message-ID: <efoYEfblx-p7w1qtzFAVmaPOO_GaH56CxwtnJ3IYong=.b58afa5b-dda1-444d-b4ef-363ea252ce85@github.com>

On Mon, 5 Dec 2022 14:21:03 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

>> Isn't there a jtreg test which triggers the deoptimization somehow?
>
> I could not find jtreg tests that specially target deoptimization codepath but one can trigger and test it using a benchmark, e.g. dacapo lusearch with +DeoptimizeNMethodBarriersALot key.

ok, thanks for checking

-------------

PR: https://git.openjdk.org/jdk/pull/11442

From kbarrett at openjdk.org  Mon Dec  5 21:05:28 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 5 Dec 2022 21:05:28 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v6]
In-Reply-To: <v-BZ4nKnRdOdpwUdneFYyFxh8SK98hOBE2dAFUvl9hQ=.f38ddac1-b600-4e38-b583-f016781f4c9a@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
 <BlgmU61ejhlUYvDFqS4vdeD-KZPN1Gs93wP91Y0YE74=.f95c84af-7e10-4426-99f6-985c19d36506@github.com>
 <-Gx_fsiwHvInS5q3bAOQAxpaUgj0Qsn015pthmrE5jI=.2adeff80-dfd1-427a-b4a1-a54453dce4aa@github.com>
 <qO8PccVbO_Ro4teqV3uFITYZK7aLxInsCltFgLDpAQ4=.6b04d82d-c68d-4334-beb4-2e05b98435a7@github.com>
 <b4o3tjV_EOG3mUrQYZ5MIeQ-ToFJHdVrBAfMzIWVWz4=.ce32ee96-2a3f-4960-9ef2-0ef56163768f@github.com>
 <fLYyPsnZR7loYYM3-ACxoRd5foarE1R3BWdkBSaNIXU=.5f21974e-29e2-4ccb-a0ca-76185672411f@github.com>
 <s7AynR1CNMKTrOHmAnXRUclYXWScoJTrpLLdH6dhAVQ=.58ed6851-505d-47e7-a2a5-a51ea781fab5@github.com>
 <YrObZ-AMkq6SwiXtk_qhke4mFXlyg6BIgqDfdKjScpU=.ae45ca15-24ae-4748-b069-46e34c36e54a@github.com>
 <O-c_pZEBs-xUiMhyPkMiz1DyfasjhTNjF_tgAVfLGMk=.7cd96ad6-22fb-4e91-80e3-fa4f73080256@github.com>
 <v-BZ4nKnRdOdpwUdneFYyFxh8SK98hOBE2dAFUvl9hQ=.f38ddac1-b600-4e38-b583-f016781f4c9a@github.com>
Message-ID: <wZsNBqc51WtFJ6YYU12TeucbjWh2DSaDEZyIphFGFY4=.32748d34-f564-4e21-9f35-cc38b6e0f510@github.com>

On Mon, 5 Dec 2022 11:30:17 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> How does this behave with respect to alignment?
>> The previous implementation used 16 which is at least aligned to `std::max_align_t` (for all hotspots build systems?) 
>> My understanding is that `char space[sizeof (klass)];` is 1-byte aligned, so `dummyObj` may be misaligned.
>
>> How does this behave with respect to alignment? The previous implementation used 16 which is at least aligned to `std::max_align_t` (for all hotspots build systems?) My understanding is that `char space[sizeof (klass)];` is 1-byte aligned, so `dummyObj` may be misaligned.
> 
> That's an interesting point. I don't propose to trawl the standard for exact wording, but as far as I recall it's _accesses_ to misaligned members that are problematic.

I had wondered the same thing, and had already spent some time trawling the
standard. I think the only way to get a misaligned pointer (without using
`#pragma pack`) involves casts. The relevant `reinterpret_cast` is defined as
being equivalent to `static_cast` to `void*` then `static_cast` to `T*` (C++14
5.2.10/7). There it says round trip cast is okay with same alignment
requirements, but is silent about when they are different. However,
`static_cast` from `void*` to `T*` is okay if the address satisfies the
alignment requirement for `T`, else unspecified (C++14 5.2.9/13).

So if the space buffer is misaligned for the klass type, the cast will have an
unspecified result. There may also be a question regarding whether
`&dummyObj->field` constitutes an access.  I recall a gcc bug with a long
discussion about whether `&x[n]` constituted an access (with gcc maintainers
saying yes), but I couldn't refind that bug today.

I think the safe thing to do is to align the space buffer.  The simplest way
to do that would be with `alignas`, but using that is pending approval:
https://git.openjdk.org/jdk/pull/11446. `ATTRIBUTE_ALIGNED` is the HotSpot
macro for that.

-------------

PR: https://git.openjdk.org/jdk/pull/10920

From kbarrett at openjdk.org  Mon Dec  5 21:21:31 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 5 Dec 2022 21:21:31 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v6]
In-Reply-To: <BlgmU61ejhlUYvDFqS4vdeD-KZPN1Gs93wP91Y0YE74=.f95c84af-7e10-4426-99f6-985c19d36506@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
 <BlgmU61ejhlUYvDFqS4vdeD-KZPN1Gs93wP91Y0YE74=.f95c84af-7e10-4426-99f6-985c19d36506@github.com>
Message-ID: <CjM0Fhl3p4y2-MsR0akOWL5W5vu5ScALtRKgV6A2sBM=.3b5491a3-d0a3-44d4-8e76-ba233e9bff71@github.com>

On Fri, 2 Dec 2022 10:19:33 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This patch fixes the remaining null pointer dereference bugs that I know of.
>> 
>> For the main bug, C2 was using a null reference to indicate an uninitialized `Node_List`. I replaced the null reference with a static sentinel.
>> 
>> I also turned on `-fsanitize=null` and found and fixed a bunch of other null pointer dereferences. With this,I have run a full bootstrap and tier1 tests with `-fsanitize=null` enabled.
>> 
>> I have checked that the code generated by GCC is not worse in any significant way, so I don't expect to see any performance regressions.
>> 
>> I'd like to enable `-fsanitize=null` in debug builds to prevent regressions in this area. What do you think?
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback from reviewers

Changes requested by kbarrett (Reviewer).

src/hotspot/share/runtime/vmStructs.hpp line 193:

> 191: #define CHECK_NONSTATIC_VM_STRUCT_ENTRY(typeName, fieldName, type) {               \
> 192:     char space[sizeof (typeName)];                                                 \
> 193:     typeName *dummyObj = (typeName *)space; type* dummy = &dummyObj->fieldName;    \

The member value type checking could be written more explicitly (and IMO more
clearly, though metaprogramming :) ) as:


#define CHECK_NONSTATIC_VM_STRUCT_ENTRY(typeName, fieldName, type) { \
  std::static_assert( \
    std::is_convertible< \
      std::add_pointer_t<decltype(std::declval<typeName>().fieldName)>, \
      std::add_pointer_t<type>>::value, \
    "type mismatch for " XSTR(fieldName) " member of " XSTR(typeName)); \
  assert(offset_of(typeName, fieldName) < sizeof(typeName), "..."); \
}


except that uses `std::declval`, which is in `<utility>`, which is not (yet)
permitted for use in HotSpot code.  Maybe that will change someday.  In the
meantime, we could add our own definition to globalUtilities.hpp, since it is
quite trivial.


template<typename T>
std::add_rvalue_reference_t<T> declval() noexcept;


I tried using `std::is_same` instead of `std::is_convertible`, which seems
like it might be better. However, there were a number of failures because some
uses are not exact matches. There were differences in volatile, in base vs
derived types, and reference vs non-reference types (if you drop the
conversion to pointers).

This dodges the whole question of alignment of the space buffer.

src/hotspot/share/runtime/vmStructs.hpp line 194:

> 192:     char space[sizeof (typeName)];                                                 \
> 193:     typeName *dummyObj = (typeName *)space; type* dummy = &dummyObj->fieldName;    \
> 194:     assert(offset_of(typeName, fieldName) < sizeof(typeName), "Illegal nonstatic struct entry, field offset too large"); \

I think what this assert is really trying to do is verify that fieldName designates an ordinary data member
rather than a static data member.  That's probably possible to determine via some metaprogramming
rather than using `offset_of`.  I'll see if I can come up with something.

src/hotspot/share/runtime/vmStructs.hpp line 202:

> 200:     typedef type dummyvtype; typeName *dummyObj = (typeName *)space;               \
> 201:     volatile dummyvtype* dummy = &dummyObj->fieldName;                             \
> 202:   }

I think a better definition for this macro is

#define CHECK_VOLATILE_NONSTATIC_VM_STRUCT_ENTRY(typeName, fieldName, type) \
  CHECK_NONSTATIC_VM_STRUCT_ENTRY(typeName, fieldName, std::add_volatile_t<type>)

(and `#include <type_traits>`)

-------------

PR: https://git.openjdk.org/jdk/pull/10920

From kbarrett at openjdk.org  Mon Dec  5 21:41:25 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 5 Dec 2022 21:41:25 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v6]
In-Reply-To: <BlgmU61ejhlUYvDFqS4vdeD-KZPN1Gs93wP91Y0YE74=.f95c84af-7e10-4426-99f6-985c19d36506@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
 <BlgmU61ejhlUYvDFqS4vdeD-KZPN1Gs93wP91Y0YE74=.f95c84af-7e10-4426-99f6-985c19d36506@github.com>
Message-ID: <TzE0svhIx5HOY1bPGiatw_Fsdvs4wu_RZxev-q_9FwE=.9eaecf15-5e4f-4f38-9df7-45f2a6bd32a6@github.com>

On Fri, 2 Dec 2022 10:19:33 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This patch fixes the remaining null pointer dereference bugs that I know of.
>> 
>> For the main bug, C2 was using a null reference to indicate an uninitialized `Node_List`. I replaced the null reference with a static sentinel.
>> 
>> I also turned on `-fsanitize=null` and found and fixed a bunch of other null pointer dereferences. With this,I have run a full bootstrap and tier1 tests with `-fsanitize=null` enabled.
>> 
>> I have checked that the code generated by GCC is not worse in any significant way, so I don't expect to see any performance regressions.
>> 
>> I'd like to enable `-fsanitize=null` in debug builds to prevent regressions in this area. What do you think?
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback from reviewers

Changes requested by kbarrett (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10920

From kbarrett at openjdk.org  Mon Dec  5 21:41:30 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 5 Dec 2022 21:41:30 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v6]
In-Reply-To: <CjM0Fhl3p4y2-MsR0akOWL5W5vu5ScALtRKgV6A2sBM=.3b5491a3-d0a3-44d4-8e76-ba233e9bff71@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
 <BlgmU61ejhlUYvDFqS4vdeD-KZPN1Gs93wP91Y0YE74=.f95c84af-7e10-4426-99f6-985c19d36506@github.com>
 <CjM0Fhl3p4y2-MsR0akOWL5W5vu5ScALtRKgV6A2sBM=.3b5491a3-d0a3-44d4-8e76-ba233e9bff71@github.com>
Message-ID: <i23liLi2SF97LeQgvIy_zR8iZJb7OayDRbbssnPiKV8=.858c1067-c8c2-4ee6-a9a4-14a9382448d3@github.com>

On Mon, 5 Dec 2022 21:18:18 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Feedback from reviewers
>
> src/hotspot/share/runtime/vmStructs.hpp line 194:
> 
>> 192:     char space[sizeof (typeName)];                                                 \
>> 193:     typeName *dummyObj = (typeName *)space; type* dummy = &dummyObj->fieldName;    \
>> 194:     assert(offset_of(typeName, fieldName) < sizeof(typeName), "Illegal nonstatic struct entry, field offset too large"); \
> 
> I think what this assert is really trying to do is verify that fieldName designates an ordinary data member
> rather than a static data member.  That's probably possible to determine via some metaprogramming
> rather than using `offset_of`.  I'll see if I can come up with something.

The test of an ordinary data member turns out to be pretty simple, but doesn't work here.  Some of the "fieldName" values are not actually data members!  They are "paths to values", like `_data[0]` and `_metadata._klass`.  Oh well.

-------------

PR: https://git.openjdk.org/jdk/pull/10920

From dholmes at openjdk.org  Tue Dec  6 00:08:42 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 6 Dec 2022 00:08:42 GMT
Subject: RFR: 8292674: ReportJNIFatalError should print all java frames
Message-ID: <-ipNtt5PSZ2d7VUBSoduPyNwnW2GeN_y0Dcs95qI8HU=.c4771172-01dd-49ae-8f4a-9d5cbd6c6dad@github.com>

When JNI reports errors and warnings and produces a stack trace, we need to see the exact Java code that was being executed. The existing `JavaThread::print_stack` that is used is only for platform/carrier threads and doesn't show any mounted virtual thread. So we introduce a new `JavaThread::print_virtual_stack_on` method to print the mounted virtual thread's stack, and we add `JavaThread::print_jni_stack` as a utility for JNI to call that dispatches to the appropriate function based on the thread type.

The existing test `hotspot/jtreg/runtime/jni/checked/TestPrimitiveArrayCriticalWithBadParam.java` was modified to test regular and virtual threads, and to expect to see the specific stack frame of the Java native method.

Additional manual testing of the JNI `FatalError` method was done by direct fault injection in modified JDK code.

Sanity testing: Oracle tiers 1-4 (to include our -Xcheck:jni run in tier4)

Thanks,
David

-------------

Commit messages:
 - 8292674: ReportJNIFatalError should print all java frames

Changes: https://git.openjdk.org/jdk/pull/11503/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11503&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292674
  Stats: 95 lines in 6 files changed: 79 ins; 3 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/11503.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11503/head:pull/11503

PR: https://git.openjdk.org/jdk/pull/11503

From haosun at openjdk.org  Tue Dec  6 04:28:04 2022
From: haosun at openjdk.org (Hao Sun)
Date: Tue, 6 Dec 2022 04:28:04 GMT
Subject: RFR: 8292289: [vectorapi] Improve the implementation of
 VectorTestNode [v13]
In-Reply-To: <955ScdreoJQ7PG5cXUmly_giKjOJx8ouU8oy1DX_GEA=.7c59dbbb-4a3b-4f35-a951-4cf0aaa6a047@github.com>
References: <IcR6eOr6iM1b9B1I1zUQnI2J9hQAmdSRHYc9CdIGW5E=.3b8dd64d-2eff-4659-b75a-81c4b008e41a@github.com>
 <955ScdreoJQ7PG5cXUmly_giKjOJx8ouU8oy1DX_GEA=.7c59dbbb-4a3b-4f35-a951-4cf0aaa6a047@github.com>
Message-ID: <BnDOAcTq3gjayANa3p1dL5Y3szwlU7VRbF-cgsi4uXQ=.c1c8b28c-8458-4985-9292-96e3ae4fea98@github.com>

On Tue, 29 Nov 2022 14:38:57 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> This patch modifies the node generation of `VectorSupport::test` to emit a `CMoveINode`, which is picked up by `BoolNode::Ideal(PhaseGVN*, bool)` to connect the `VectorTestNode` directly to the `BoolNode`, removing the redundant operations of materialising the test result in a GP register and do a `CmpI` to get back the flags. As a result, `VectorMask<T>::alltrue` is compiled into machine codes:
>> 
>>         vptest xmm0, xmm1
>>         jb if_true
>>     if_false:
>> 
>> instead of:
>> 
>>         vptest xmm0, xmm1
>>         setb r10
>>         movzbl r10
>>         testl r10
>>         jne if_true
>>     if_false:
>> 
>> The results of `jdk.incubator.vector.ArrayMismatchBenchmark` shows noticeable improvements:
>> 
>>                                                                                        Before                  After
>>     Benchmark                                      Prefix    Size   Mode  Cnt       Score      Error       Score     Error    Units  Change
>>     ArrayMismatchBenchmark.mismatchVectorByte         0.5       9  thrpt   10  217345.383 ? 8316.444  222279.381 ? 2660.983  ops/ms   +2.3%
>>     ArrayMismatchBenchmark.mismatchVectorByte         0.5     257  thrpt   10  113918.406 ? 1618.836  116268.691 ? 1291.899  ops/ms   +2.1%
>>     ArrayMismatchBenchmark.mismatchVectorByte         0.5  100000  thrpt   10     702.066 ?   72.862     797.806 ?   16.429  ops/ms  +13.6%
>>     ArrayMismatchBenchmark.mismatchVectorByte         1.0       9  thrpt   10  146096.564 ? 2401.258  145338.910 ?  687.453  ops/ms   -0.5%
>>     ArrayMismatchBenchmark.mismatchVectorByte         1.0     257  thrpt   10   60598.181 ? 1259.397   69041.519 ? 1073.156  ops/ms  +13.9%
>>     ArrayMismatchBenchmark.mismatchVectorByte         1.0  100000  thrpt   10     316.814 ?   10.975     408.770 ?    5.281  ops/ms  +29.0%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       0.5       9  thrpt   10  195674.549 ? 1200.166  188482.433 ? 1872.076  ops/ms   -3.7%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       0.5     257  thrpt   10   44357.169 ?  473.013   42293.411 ? 2838.255  ops/ms   -4.7%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       0.5  100000  thrpt   10      68.199 ?    5.410      67.628 ?    3.241  ops/ms   -0.8%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       1.0       9  thrpt   10  107722.450 ? 1677.607  111060.400 ?  982.230  ops/ms   +3.1%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       1.0     257  thrpt   10   16692.645 ? 1002.599   21440.506 ? 1618.266  ops/ms  +28.4%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       1.0  100000  thrpt   10      32.984 ?    0.548      33.202 ?    2.365  ops/ms   +0.7%
>>     ArrayMismatchBenchmark.mismatchVectorInt          0.5       9  thrpt   10  335458.217 ? 3154.842  379944.254 ? 5703.134  ops/ms  +13.3%
>>     ArrayMismatchBenchmark.mismatchVectorInt          0.5     257  thrpt   10   58505.302 ?  786.312   56721.368 ? 2497.052  ops/ms   -3.0%
>>     ArrayMismatchBenchmark.mismatchVectorInt          0.5  100000  thrpt   10     133.037 ?   11.415     139.537 ?    4.667  ops/ms   +4.9%
>>     ArrayMismatchBenchmark.mismatchVectorInt          1.0       9  thrpt   10  117943.802 ? 2281.349  112409.365 ? 2110.055  ops/ms   -4.7%
>>     ArrayMismatchBenchmark.mismatchVectorInt          1.0     257  thrpt   10   27060.015 ?  795.619   33756.613 ?  826.533  ops/ms  +24.7%
>>     ArrayMismatchBenchmark.mismatchVectorInt          1.0  100000  thrpt   10      57.558 ?    8.927      66.951 ?    4.381  ops/ms  +16.3%
>>     ArrayMismatchBenchmark.mismatchVectorLong         0.5       9  thrpt   10  182963.715 ? 1042.497  182438.405 ? 2120.832  ops/ms   -0.3%
>>     ArrayMismatchBenchmark.mismatchVectorLong         0.5     257  thrpt   10   36672.215 ?  614.821   35397.398 ? 1609.235  ops/ms   -3.5%
>>     ArrayMismatchBenchmark.mismatchVectorLong         0.5  100000  thrpt   10      66.438 ?    2.142      65.427 ?    2.270  ops/ms   -1.5%
>>     ArrayMismatchBenchmark.mismatchVectorLong         1.0       9  thrpt   10  110393.047 ?  497.853  115165.845 ? 5381.674  ops/ms   +4.3%
>>     ArrayMismatchBenchmark.mismatchVectorLong         1.0     257  thrpt   10   14720.765 ?  661.350   19871.096 ?  201.464  ops/ms  +35.0%
>>     ArrayMismatchBenchmark.mismatchVectorLong         1.0  100000  thrpt   10      30.760 ?    0.821      31.933 ?    1.352  ops/ms   +3.8%
>> 
>> I have not been able to conduct throughout testing on AVX512 and Aarch64 so any help would be invaluable. Thank you very much.
>
> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 30 commits:
> 
>  - Merge branch 'master' into improveVTest
>  - Merge branch 'master' into improveVTest
>  - redundant casts
>  - remove untaken code paths
>  - Merge branch 'master' into improveVTest
>  - Merge branch 'master' into improveVTest
>  - Merge branch 'master' into improveVTest
>  - fix merge problems
>  - Merge branch 'master' into improveVTest
>  - refactor x86
>  - ... and 20 more: https://git.openjdk.org/jdk/compare/2f83b5c4...1fec3d30

I'm running some tests on AArch64 platform (both Neon and SVE).

test/hotspot/jtreg/compiler/vectorapi/TestVectorTest.java line 31:

> 29: /*
> 30:  * @test
> 31:  * @bug 8278471

A copy-paste error here?

Suggestion:

 * @bug 8292289

-------------

PR: https://git.openjdk.org/jdk/pull/9855

From dholmes at openjdk.org  Tue Dec  6 04:57:11 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 6 Dec 2022 04:57:11 GMT
Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v2]
In-Reply-To: <yhzD_0pdvCEtA9UVulZ_mDq9sO82qwINAUBgjA3pLqE=.7465110b-b732-4b0d-8054-da1ff1764296@github.com>
References: <Dj9YfY10SLn8dR1Ez3kEQe4tXm1q5W1TS8_4r3gBUsY=.6c38825a-86e5-4575-a509-683786d242a6@github.com>
 <yhzD_0pdvCEtA9UVulZ_mDq9sO82qwINAUBgjA3pLqE=.7465110b-b732-4b0d-8054-da1ff1764296@github.com>
Message-ID: <2R1SvRfKINep3LbJNfi35pZbDaKSbJY-SHCtvEOfz08=.39007aa6-aff1-4d30-9e8e-882f172d1c98@github.com>

On Mon, 5 Dec 2022 13:16:44 GMT, Afshin Zafari <duke at openjdk.org> wrote:

>> test of tier1-5 passed.
>
> Afshin Zafari 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 seven additional commits since the last revision:
> 
>  - 8292741: Convert JvmtiTagMapTable to ResourceHashtable
>  - Merge branch 'jvmti_tagmap' of http://github.com/afshin-zafari/jdk into jvmti_tagmap
>  - JBS-8292741: Convert JvmtiTagMapTable to ResourceHashtable
>  - 8292741: Convert JvmtiTagMapTable to ResourceHashtable
>  - 8292741: Convert JvmtiTagMapTable to ResourceHashtable
>  - Added update interface instead of Remove-Add pair.
>  - JBS-8292741: Convert JvmtiTagMapTable to ResourceHashtable

This PR seems to be broken now - full of unexpected changes.

-------------

PR: https://git.openjdk.org/jdk/pull/11288

From dholmes at openjdk.org  Tue Dec  6 05:17:02 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 6 Dec 2022 05:17:02 GMT
Subject: RFR: 8297967: Make frame::safe_for_sender safer [v2]
In-Reply-To: <vs0st_tG0PwfNYpeURj4j2wSCsBDJgWA-tebEhbRCk4=.beb08fad-d931-4bcf-8c49-6bc886c55761@github.com>
References: <Cctc-M2HyUqIjpcRyTjmF46wKDqvBtnnYe5Mn45sdO8=.03bdf65f-bf98-48dc-b957-0c838003d46f@github.com>
 <W7jCII0F-N-vINSt1vg_g0ejpVSv27GSlBtuKRyS790=.ec4382ea-28b1-4daa-8812-57a7b2be9e18@github.com>
 <FWuqIBRIn1Y1ddcyZZLfsfx-_kDBI5AVurZwvQnw36M=.824e5311-399b-478e-b7ed-bb46eec4c2aa@github.com>
 <RejOSw1JjBA2pQFJGB3Dxj9cqjQa8YNFQi-GHVZByXE=.0cd28c78-5637-4057-9447-b542c5aaffda@github.com>
 <u8vLzfKWPN8ylMl_3rA9uKXYD1kc9u0PsnUpxr5fMCs=.a4248d04-bc0a-4661-be88-274ef8d297a5@github.com>
 <vs0st_tG0PwfNYpeURj4j2wSCsBDJgWA-tebEhbRCk4=.beb08fad-d931-4bcf-8c49-6bc886c55761@github.com>
Message-ID: <7kRWzMPPMa04KSKXQKj-V7VFYgbbWtjFiw9erejlU3o=.c0ba5205-96fe-450b-808f-f91beecb0632@github.com>

On Fri, 2 Dec 2022 23:33:26 GMT, Johannes Bechberger <duke at openjdk.org> wrote:

>> I agree fp has already been validated.
>
> But has fp + return_addr_offset been checked?

Probably not, but not relevant to the comments about line  268.

-------------

PR: https://git.openjdk.org/jdk/pull/11461

From dholmes at openjdk.org  Tue Dec  6 06:04:08 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 6 Dec 2022 06:04:08 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v4]
In-Reply-To: <nm5MBsIexi02WmVomf-rKb-xWg064Pqg9WMKxb18PBw=.9d5209a3-675e-4ee2-a4d5-05ff14934fb3@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
 <nm5MBsIexi02WmVomf-rKb-xWg064Pqg9WMKxb18PBw=.9d5209a3-675e-4ee2-a4d5-05ff14934fb3@github.com>
Message-ID: <l12fdSbAv-DiEfAt29C4mOXFRoNaWjTVuW3_aSElIiI=.f8ec8d7e-84ec-4551-a9f3-e9aa116bb84e@github.com>

On Mon, 5 Dec 2022 17:45:25 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Libgraal is compiled ahead of time and should not need any JVMCI Java code to be dynamically loaded at runtime. Prior to this PR, this is not the case due to:
>> 
>> * Code to copy system properties from the HotSpot heap into the libgraal heap. This is in `jdk.vm.ci.services.Services.initializeSavedProperties(byte[])` and `jdk.vm.ci.services.Services.serializeSavedProperties()`. This code should be moved to `java.base/jdk.internal.vm.VMSupport`.
>> * Code to translate exceptions from the HotSpot heap into the libgraal heap and vice versa. This code should be moved from `jdk.internal.vm.ci//jdk.vm.ci.hotspot.TranslatedException` to `java.base/jdk.internal.vm.VMSupport`.
>> 
>> This PR makes the above changes. As a result, it's possible to build a JDK image that includes (and uses) libgraal but does not include `jdk.internal.vm.ci` or `jdk.internal.vm.compiler`. This both reduces footprint and better isolates the JAVMCI and the Graal compiler as accessing these components from Java code is now impossible.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   renamed is_module_resolvable to is_module_observable

Sorry Doug not a full review (not familiar enough with code) but a few drive-by nits.

Thanks.

src/hotspot/share/jvmci/jvmci.cpp line 233:

> 231:     Thread* thread = Thread::current_or_null_safe();
> 232:     if (thread != nullptr && thread->is_Java_thread()) {
> 233:       ResourceMark rm;

You can pass `thread` to the rm constructor to save an internal lookup.

src/hotspot/share/jvmci/jvmci.cpp line 234:

> 232:     if (thread != nullptr && thread->is_Java_thread()) {
> 233:       ResourceMark rm;
> 234:       JavaThreadState state = ((JavaThread*) thread)->thread_state();

Please use `JavaThread::cast(thread)`

src/hotspot/share/jvmci/jvmci.cpp line 241:

> 239:         // resolve the j.l.Thread object unless the thread is in
> 240:         // one of the states above.
> 241:         tty->print("JVMCITrace-%d[%s@" INTPTR_FORMAT "]:%*c", level, thread->type_name(), p2i(thread), level, ' ');

I think the current preferred style is to use PTR_FORMAT here.

src/hotspot/share/runtime/arguments.cpp line 1958:

> 1956:         AddProperty, UnwriteableProperty, InternalProperty);
> 1957:     if (ClassLoader::is_module_observable("jdk.internal.vm.ci")) {
> 1958:       if(!create_numbered_module_property("jdk.module.addmods", "jdk.internal.vm.ci", addmods_count++)) {

Nit: space after `if` please

src/java.base/share/classes/jdk/internal/vm/TranslatedException.java line 2:

> 1: /*
> 2:  * Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved.

If you just moved the file the original copyright year should remain - this is not new code.

-------------

Changes requested by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11513

From jcking at openjdk.org  Tue Dec  6 06:25:11 2022
From: jcking at openjdk.org (Justin King)
Date: Tue, 6 Dec 2022 06:25:11 GMT
Subject: RFR: JDK-8298084: Memory leak in Method::build_profiling_method_data
Message-ID: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>

Resolve memory leak related to `MethodData::_extra_data_lock` in `Method::build_profiling_method_data` by defining `MethodData::release_C_heap_structures` and calling it where appropriate before deallocating `MethodData`.

-------------

Commit messages:
 - Memory leak in MethodData

Changes: https://git.openjdk.org/jdk/pull/11526/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11526&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298084
  Stats: 17 lines in 3 files changed: 11 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/11526.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11526/head:pull/11526

PR: https://git.openjdk.org/jdk/pull/11526

From dholmes at openjdk.org  Tue Dec  6 07:05:11 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 6 Dec 2022 07:05:11 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data
In-Reply-To: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
Message-ID: <nItn8_5nJ8EPz83o1shXf15bTFvq7UTtUxg1CPzW6n8=.95df8828-a2e1-475c-9bf8-943265261327@github.com>

On Tue, 6 Dec 2022 06:13:23 GMT, Justin King <jcking at openjdk.org> wrote:

> Resolve memory leak related to `MethodData::_extra_data_lock` in `Method::build_profiling_method_data` by defining `MethodData::release_C_heap_structures` and calling it where appropriate before deallocating `MethodData`.

I'm somewhat confused by the existing code. We have:

// Destroy MethodData
method_data()->~MethodData();

which doesn't actually delete the `MethodData` it just runs the destructor. So where is the `MethodData` object actually allocated, and when is that freed? I would expect the lock to disappear at the same time if it is embedded in the `MethodData` object.

-------------

PR: https://git.openjdk.org/jdk/pull/11526

From stuefe at openjdk.org  Tue Dec  6 07:07:33 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 6 Dec 2022 07:07:33 GMT
Subject: RFR: JDK-8293313: NMT: Rework MallocLimit [v2]
In-Reply-To: <-KHeOvjwe5Osf05XWQuO5ELZUs-ogUVj25xCouJaDaU=.b0906406-dd44-4eb4-be76-debe83867249@github.com>
References: <-KHeOvjwe5Osf05XWQuO5ELZUs-ogUVj25xCouJaDaU=.b0906406-dd44-4eb4-be76-debe83867249@github.com>
Message-ID: <oHhvAIHzm_lNExlXTDsSbwfYejjr0B_SOz7gS_URH84=.45c8cdf6-5965-4e82-962c-208e0a095443@github.com>

> Rework NMT `MallocLimit` to make it more useful for native OOM analysis. Also remove `MallocMaxTestWords`, which had been mostly redundant with NMT (for background, see JDK-8293292).
> 
> 
> ### Background
> 
> Some months ago we had [JDK-8291919](https://bugs.openjdk.org/browse/JDK-8291919), a compiler regression that caused compiler arenas to grow boundlessly. Process was usually OOM-killed before we could take a look, so this was difficult to analyze.
> 
> To improve analysis options, we added NMT *malloc limits* with [JDK-8291878](https://bugs.openjdk.org/browse/JDK-8291878). Malloc limits let us set one or multiple limits to malloc load. Surpassing a limit causes the VM to stop with a fatal error in the allocation function, giving us a hs-err file and a core right at the point that (probably) causes the leak. This makes error analysis a lot simpler, and is also valuable for regression-testing footprint usage.
> 
> Some people wished for a way to not end with a fatal error but to mimic a native OOM (causing os::malloc to return NULL). This would allow us to test resilience in the face of native OOMs, among other things.
> 
> ### Patch
> 
> - Expands the `MallocLimit` option syntax, allowing for an "oom mode" that mimics an oom:
> 
> 
> 
> Global form:
> -XX:MallocLimit=<size>[:<mode>]
> Category-specific form:
> -XX:MallocLimit=<category>:<size>[:<mode>][,<category>:<size>[:<mode>] ...]
> Examples:
> -XX:MallocLimit=3g
> -XX:MallocLimit=3g:oom
> -XX:MallocLimit=compiler:200m:oom
> 
> 
> - moves parsing of `-XX:MallocLimit` out of arguments.cpp into `mallocLimit.hpp/cpp`, and rewrites it.
> 
> - changes when limits are checked. Before, the limits were checked *after* the allocation that caused the threshold overflow. Now we check beforehand.
> 
> - removes `MallocMaxTestWords`, replacing its uses with `MallocLimit`
> 
> - adds new gtests and new jtreg tests
> 
> - removes a bunch of jtreg tests which are now better served by the new gtests.
> 
> - gives us more precise error messages upon reaching a limit. For example:
> 
> before:
> 
> #  fatal error: MallocLimit: category "Compiler" reached limit (size: 20997680, limit: 20971520)
> 
> 
> now:
> 
> #  fatal error: MallocLimit: reached category "Compiler" limit (triggering allocation size: 1920B, allocated so far: 20505K, limit: 20480K)

Thomas Stuefe 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 two additional commits since the last revision:

 - Merge branch 'master' into JDK-8293313-NMT-fake-oom
 - MallocLimit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11371/files
  - new: https://git.openjdk.org/jdk/pull/11371/files/a3622a36..7184b1b0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11371&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11371&range=00-01

  Stats: 81643 lines in 1434 files changed: 37632 ins; 35425 del; 8586 mod
  Patch: https://git.openjdk.org/jdk/pull/11371.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11371/head:pull/11371

PR: https://git.openjdk.org/jdk/pull/11371

From jcking at openjdk.org  Tue Dec  6 07:11:34 2022
From: jcking at openjdk.org (Justin King)
Date: Tue, 6 Dec 2022 07:11:34 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data
In-Reply-To: <nItn8_5nJ8EPz83o1shXf15bTFvq7UTtUxg1CPzW6n8=.95df8828-a2e1-475c-9bf8-943265261327@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
 <nItn8_5nJ8EPz83o1shXf15bTFvq7UTtUxg1CPzW6n8=.95df8828-a2e1-475c-9bf8-943265261327@github.com>
Message-ID: <p-mg_NMxLIbDN62eD9ltFU-VSVBTFkp03G_PZhseIoY=.91ece816-90c5-4e40-84a9-9b24fdad93a4@github.com>

On Tue, 6 Dec 2022 07:01:16 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I'm somewhat confused by the existing code. We have:
> 
> ```
> // Destroy MethodData
> method_data()->~MethodData();
> ```
> 
> which doesn't actually delete the `MethodData` it just runs the destructor. So where is the `MethodData` object actually allocated, and when is that freed? I would expect the lock to disappear at the same time if it is embedded in the `MethodData` object.

Mutex used to be a value member (this change switches it to be a pointer), so ~MethodData actually deleted the lock and its associated data. However calling the destructor like that, and then accessing fields later is really sketchy and I am pretty sure undefined behavior to some extent.

Many of the other Metadata derived classes use `deallocate_contents()` to release other metadata objects and `release_C_heap_structures()` to cleanup non-metadata memory. So I was just attempting to be consistent.

https://github.com/openjdk/jdk/commit/86fdbc0f85de6494cd7f6a5ad12d745ea382df93 addressed the original leak and called the destructor directly, but a more recent change re-introduced another leak.

-------------

PR: https://git.openjdk.org/jdk/pull/11526

From jcking at openjdk.org  Tue Dec  6 07:11:36 2022
From: jcking at openjdk.org (Justin King)
Date: Tue, 6 Dec 2022 07:11:36 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data
In-Reply-To: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
Message-ID: <rau2c-qBXp4GO23CwOayqYnNWSJhFYqo6mNv9SvFvlQ=.af0eed10-fb95-4911-9dad-695f8413df8f@github.com>

On Tue, 6 Dec 2022 06:13:23 GMT, Justin King <jcking at openjdk.org> wrote:

> Resolve memory leak related to `MethodData::_extra_data_lock` in `Method::build_profiling_method_data` by defining `MethodData::release_C_heap_structures` and calling it where appropriate before deallocating `MethodData`.

The Metadata derived classes also do not really use destructors at all. None of them are called directly under normal circumstances.

-------------

PR: https://git.openjdk.org/jdk/pull/11526

From fyang at openjdk.org  Tue Dec  6 07:50:07 2022
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 6 Dec 2022 07:50:07 GMT
Subject: RFR: 8298075: RISC-V: Implement post-call NOPs [v3]
In-Reply-To: <xMEcjdDuKZ8gp-McOsb-zADkmNUFZQdfteY5pshX3TY=.ad6f4996-8370-48e7-bea5-c2ed2282a601@github.com>
References: <inZ_2fowZZQz0C53E2h4zURoyQIwZcJaBfhC4zwFyb8=.cbc7e361-9bad-48ce-b6d4-c3a8fe2e1cba@github.com>
 <xMEcjdDuKZ8gp-McOsb-zADkmNUFZQdfteY5pshX3TY=.ad6f4996-8370-48e7-bea5-c2ed2282a601@github.com>
Message-ID: <OUtM8LMDO_-j50IsVHkh2ohEUVHmvC0x8PM7aj7BGwo=.e92b378d-c12d-45f4-a0fd-b36d1f685ca6@github.com>

On Mon, 5 Dec 2022 04:53:06 GMT, Xiaolin Zheng <xlinzheng at openjdk.org> wrote:

>> Same as [JDK-8287567](https://bugs.openjdk.org/browse/JDK-8287567), we need to implement post-call NOPs in the RISC-V backend.
>> 
>> We use `li32` to implement it. `li32` will signed-extend the loaded imm32 to a 64-bit register. However, our reader `NativePostCallNop::displacement()` only needs the low 32 bits value so we are safe.
>> 
>> The current post-call NOP is like:
>> 
>> nop                    (always 4-byte, used for deoptimization, please see `NativePostCallNop::make_deopt()`)
>> lui zr, <imm20>        (always 4-byte)
>> addiw zr, zr, <imm12>  (always 4-byte)
>> 
>> 
>> The code size here is the same as the AArch64 counterpart, 12 bytes.
>> 
>> The logic of setting the post-call NOP displacement is at `install_post_call_nop_displacement()` [1] when nmethods are being installed, so no one is running post-call NOPs when we are patching them.
>> 
>> One can check them by directly using `java --enable-preview -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly`.
>> 
>> Tested hotspot tier1~4 and jdk tier1~4 using fastdebug by force turning on `--enable-preview`; SPECjbb2015 and dacapo were tested without regressions found. Skynet JMH benchmark seems to have an improvement from `8662ms/op -> 8495ms/op`.
>> 
>> Thanks,
>> Xiaolin
>> 
>> [1] https://github.com/openjdk/jdk/blob/b49fd920b6690a8b828c85e45c10e5c4c54d2022/src/hotspot/share/code/nmethod.cpp#L1078-L1107
>
> Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Better to remove the ASSERT for we already use assert()

src/hotspot/cpu/riscv/nativeInst_riscv.cpp line 448:

> 446: 
> 447: int NativePostCallNop::displacement() const {
> 448:   // discard the high 32-bit

Suggestion: // Discard the high 32 bits

-------------

PR: https://git.openjdk.org/jdk/pull/11502

From duke at openjdk.org  Tue Dec  6 08:10:01 2022
From: duke at openjdk.org (Johannes Bechberger)
Date: Tue, 6 Dec 2022 08:10:01 GMT
Subject: RFR: 8297967: Make frame::safe_for_sender safer [v2]
In-Reply-To: <7kRWzMPPMa04KSKXQKj-V7VFYgbbWtjFiw9erejlU3o=.c0ba5205-96fe-450b-808f-f91beecb0632@github.com>
References: <Cctc-M2HyUqIjpcRyTjmF46wKDqvBtnnYe5Mn45sdO8=.03bdf65f-bf98-48dc-b957-0c838003d46f@github.com>
 <W7jCII0F-N-vINSt1vg_g0ejpVSv27GSlBtuKRyS790=.ec4382ea-28b1-4daa-8812-57a7b2be9e18@github.com>
 <FWuqIBRIn1Y1ddcyZZLfsfx-_kDBI5AVurZwvQnw36M=.824e5311-399b-478e-b7ed-bb46eec4c2aa@github.com>
 <RejOSw1JjBA2pQFJGB3Dxj9cqjQa8YNFQi-GHVZByXE=.0cd28c78-5637-4057-9447-b542c5aaffda@github.com>
 <u8vLzfKWPN8ylMl_3rA9uKXYD1kc9u0PsnUpxr5fMCs=.a4248d04-bc0a-4661-be88-274ef8d297a5@github.com>
 <vs0st_tG0PwfNYpeURj4j2wSCsBDJgWA-tebEhbRCk4=.beb08fad-d931-4bcf-8c49-6bc886c55761@github.com>
 <7kRWzMPPMa04KSKXQKj-V7VFYgbbWtjFiw9erejlU3o=.c0ba5205-96fe-450b-808f-f91beecb0632@github.com>
Message-ID: <E_3wvnKPJOmgU7ZhSJLEYVeHCUVYe4ojzglFWhXTrmk=.c0e02bb3-2a15-4291-a478-36955d76d200@github.com>

On Tue, 6 Dec 2022 05:15:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> But has fp + return_addr_offset been checked?
>
> Probably not, but not relevant to the comments about line  268.

You're right. I'm going to look into it today more thoroughly.

-------------

PR: https://git.openjdk.org/jdk/pull/11461

From haosun at openjdk.org  Tue Dec  6 08:26:56 2022
From: haosun at openjdk.org (Hao Sun)
Date: Tue, 6 Dec 2022 08:26:56 GMT
Subject: RFR: 8292289: [vectorapi] Improve the implementation of
 VectorTestNode [v13]
In-Reply-To: <955ScdreoJQ7PG5cXUmly_giKjOJx8ouU8oy1DX_GEA=.7c59dbbb-4a3b-4f35-a951-4cf0aaa6a047@github.com>
References: <IcR6eOr6iM1b9B1I1zUQnI2J9hQAmdSRHYc9CdIGW5E=.3b8dd64d-2eff-4659-b75a-81c4b008e41a@github.com>
 <955ScdreoJQ7PG5cXUmly_giKjOJx8ouU8oy1DX_GEA=.7c59dbbb-4a3b-4f35-a951-4cf0aaa6a047@github.com>
Message-ID: <qNY8aaImh56RU2YhrssH3ONcdKzuFqivAY932mnZ0kM=.2e2405e2-0133-4e65-b7ee-ee501da4fccc@github.com>

On Tue, 29 Nov 2022 14:38:57 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> This patch modifies the node generation of `VectorSupport::test` to emit a `CMoveINode`, which is picked up by `BoolNode::Ideal(PhaseGVN*, bool)` to connect the `VectorTestNode` directly to the `BoolNode`, removing the redundant operations of materialising the test result in a GP register and do a `CmpI` to get back the flags. As a result, `VectorMask<T>::alltrue` is compiled into machine codes:
>> 
>>         vptest xmm0, xmm1
>>         jb if_true
>>     if_false:
>> 
>> instead of:
>> 
>>         vptest xmm0, xmm1
>>         setb r10
>>         movzbl r10
>>         testl r10
>>         jne if_true
>>     if_false:
>> 
>> The results of `jdk.incubator.vector.ArrayMismatchBenchmark` shows noticeable improvements:
>> 
>>                                                                                        Before                  After
>>     Benchmark                                      Prefix    Size   Mode  Cnt       Score      Error       Score     Error    Units  Change
>>     ArrayMismatchBenchmark.mismatchVectorByte         0.5       9  thrpt   10  217345.383 ? 8316.444  222279.381 ? 2660.983  ops/ms   +2.3%
>>     ArrayMismatchBenchmark.mismatchVectorByte         0.5     257  thrpt   10  113918.406 ? 1618.836  116268.691 ? 1291.899  ops/ms   +2.1%
>>     ArrayMismatchBenchmark.mismatchVectorByte         0.5  100000  thrpt   10     702.066 ?   72.862     797.806 ?   16.429  ops/ms  +13.6%
>>     ArrayMismatchBenchmark.mismatchVectorByte         1.0       9  thrpt   10  146096.564 ? 2401.258  145338.910 ?  687.453  ops/ms   -0.5%
>>     ArrayMismatchBenchmark.mismatchVectorByte         1.0     257  thrpt   10   60598.181 ? 1259.397   69041.519 ? 1073.156  ops/ms  +13.9%
>>     ArrayMismatchBenchmark.mismatchVectorByte         1.0  100000  thrpt   10     316.814 ?   10.975     408.770 ?    5.281  ops/ms  +29.0%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       0.5       9  thrpt   10  195674.549 ? 1200.166  188482.433 ? 1872.076  ops/ms   -3.7%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       0.5     257  thrpt   10   44357.169 ?  473.013   42293.411 ? 2838.255  ops/ms   -4.7%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       0.5  100000  thrpt   10      68.199 ?    5.410      67.628 ?    3.241  ops/ms   -0.8%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       1.0       9  thrpt   10  107722.450 ? 1677.607  111060.400 ?  982.230  ops/ms   +3.1%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       1.0     257  thrpt   10   16692.645 ? 1002.599   21440.506 ? 1618.266  ops/ms  +28.4%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       1.0  100000  thrpt   10      32.984 ?    0.548      33.202 ?    2.365  ops/ms   +0.7%
>>     ArrayMismatchBenchmark.mismatchVectorInt          0.5       9  thrpt   10  335458.217 ? 3154.842  379944.254 ? 5703.134  ops/ms  +13.3%
>>     ArrayMismatchBenchmark.mismatchVectorInt          0.5     257  thrpt   10   58505.302 ?  786.312   56721.368 ? 2497.052  ops/ms   -3.0%
>>     ArrayMismatchBenchmark.mismatchVectorInt          0.5  100000  thrpt   10     133.037 ?   11.415     139.537 ?    4.667  ops/ms   +4.9%
>>     ArrayMismatchBenchmark.mismatchVectorInt          1.0       9  thrpt   10  117943.802 ? 2281.349  112409.365 ? 2110.055  ops/ms   -4.7%
>>     ArrayMismatchBenchmark.mismatchVectorInt          1.0     257  thrpt   10   27060.015 ?  795.619   33756.613 ?  826.533  ops/ms  +24.7%
>>     ArrayMismatchBenchmark.mismatchVectorInt          1.0  100000  thrpt   10      57.558 ?    8.927      66.951 ?    4.381  ops/ms  +16.3%
>>     ArrayMismatchBenchmark.mismatchVectorLong         0.5       9  thrpt   10  182963.715 ? 1042.497  182438.405 ? 2120.832  ops/ms   -0.3%
>>     ArrayMismatchBenchmark.mismatchVectorLong         0.5     257  thrpt   10   36672.215 ?  614.821   35397.398 ? 1609.235  ops/ms   -3.5%
>>     ArrayMismatchBenchmark.mismatchVectorLong         0.5  100000  thrpt   10      66.438 ?    2.142      65.427 ?    2.270  ops/ms   -1.5%
>>     ArrayMismatchBenchmark.mismatchVectorLong         1.0       9  thrpt   10  110393.047 ?  497.853  115165.845 ? 5381.674  ops/ms   +4.3%
>>     ArrayMismatchBenchmark.mismatchVectorLong         1.0     257  thrpt   10   14720.765 ?  661.350   19871.096 ?  201.464  ops/ms  +35.0%
>>     ArrayMismatchBenchmark.mismatchVectorLong         1.0  100000  thrpt   10      30.760 ?    0.821      31.933 ?    1.352  ops/ms   +3.8%
>> 
>> I have not been able to conduct throughout testing on AVX512 and Aarch64 so any help would be invaluable. Thank you very much.
>
> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 30 commits:
> 
>  - Merge branch 'master' into improveVTest
>  - Merge branch 'master' into improveVTest
>  - redundant casts
>  - remove untaken code paths
>  - Merge branch 'master' into improveVTest
>  - Merge branch 'master' into improveVTest
>  - Merge branch 'master' into improveVTest
>  - fix merge problems
>  - Merge branch 'master' into improveVTest
>  - refactor x86
>  - ... and 20 more: https://git.openjdk.org/jdk/compare/2f83b5c4...1fec3d30

test/hotspot/jtreg/compiler/vectorapi/TestVectorTest.java line 49:

> 47: 
> 48:     @Test
> 49:     @IR(failOn = {IRNode.CMP_I, IRNode.CMOVEI})

Should be `CMOVE_I`.
Suggestion:

    @IR(failOn = {IRNode.CMP_I, IRNode.CMOVE_I})

test/hotspot/jtreg/compiler/vectorapi/TestVectorTest.java line 58:

> 56:     @Test
> 57:     @IR(failOn = {IRNode.CMP_I})
> 58:     @IR(counts = {IRNode.VECTOR_TEST, "1", IRNode.CMOVEI, "1"})

ditto

-------------

PR: https://git.openjdk.org/jdk/pull/9855

From dnsimon at openjdk.org  Tue Dec  6 08:59:02 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 6 Dec 2022 08:59:02 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v4]
In-Reply-To: <l12fdSbAv-DiEfAt29C4mOXFRoNaWjTVuW3_aSElIiI=.f8ec8d7e-84ec-4551-a9f3-e9aa116bb84e@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
 <nm5MBsIexi02WmVomf-rKb-xWg064Pqg9WMKxb18PBw=.9d5209a3-675e-4ee2-a4d5-05ff14934fb3@github.com>
 <l12fdSbAv-DiEfAt29C4mOXFRoNaWjTVuW3_aSElIiI=.f8ec8d7e-84ec-4551-a9f3-e9aa116bb84e@github.com>
Message-ID: <sJOLTlt6mjfVSLsXdLQMgirI06mdYjGW0tuO2Ueht8s=.e3d8eb38-c4a6-4e43-9e01-3b9ecb385b41@github.com>

On Tue, 6 Dec 2022 05:28:24 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   renamed is_module_resolvable to is_module_observable
>
> src/hotspot/share/jvmci/jvmci.cpp line 234:
> 
>> 232:     if (thread != nullptr && thread->is_Java_thread()) {
>> 233:       ResourceMark rm;
>> 234:       JavaThreadState state = ((JavaThread*) thread)->thread_state();
> 
> Please use `JavaThread::cast(thread)`

I've made this change. Out of interest, I grep'ed through `src/hotspot` and found a few other instances of `(JavaThread*)` style casts. While most of these are probably older code, I'm wondering what the guidelines are in this area. I assume `JavaThread::cast` should be preferred always given the assertion checking it does?

-------------

PR: https://git.openjdk.org/jdk/pull/11513

From lkorinth at openjdk.org  Tue Dec  6 09:00:07 2022
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 6 Dec 2022 09:00:07 GMT
Subject: RFR: 8296401: ConcurrentHashTable::bulk_delete might miss to
 delete some objects [v2]
In-Reply-To: <8b8bHTmw4VI4Lvi-5FX20UFstJN0z_T3SdkkawuHS08=.21c6db38-7ab6-492c-a6c5-b6763d5bd3ea@github.com>
References: <rWw3Hb1baG5eslMgFnOdEP1Q4avhfYc3uTpjdB9DaP0=.23f34ff0-eff9-421b-9e70-7f119fd90e5d@github.com>
 <ORWIi13F7iZdTzskBbnki-fNF_5aqIeZS7Qqy0QHWXs=.c2c28891-fa6a-4b44-b7dc-b1ab89a2fc32@github.com>
 <8b8bHTmw4VI4Lvi-5FX20UFstJN0z_T3SdkkawuHS08=.21c6db38-7ab6-492c-a6c5-b6763d5bd3ea@github.com>
Message-ID: <_WW3Hyt32-PxzkcqXPCVj4AFqSE46cGUZk--Enn0FUY=.61e6ee26-9d9c-44a5-82d0-acf813a4f361@github.com>

On Mon, 5 Dec 2022 10:39:45 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - growable stacked
>>  - Revert "working!"
>>    
>>    This reverts commit 5366f22c7202eaa2182976c084d02e9af4f56de0.
>
> src/hotspot/share/utilities/concurrentHashTable.inline.hpp line 524:
> 
>> 522:     }
>> 523:     for (size_t node_it = 0; node_it < nd; node_it++) {
>> 524:       Node* ndel = node_it < BULK_DELETE_LIMIT ? ndel_stack[node_it] : extra.at(node_it - BULK_DELETE_LIMIT);
> 
> Needs to be a reference (`Node*& ndel`) or `DEBUG_ONLY(ndel = (Node*)POISON_PTR;)` will be a no-op.

Will fix, thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/10983

From pli at openjdk.org  Tue Dec  6 09:16:05 2022
From: pli at openjdk.org (Pengfei Li)
Date: Tue, 6 Dec 2022 09:16:05 GMT
Subject: RFR: 8297689: Fix incorrect result of Short.reverseBytes() call in
 loops
In-Reply-To: <GrgGNmwtG_W8d_TgFzCIXAN9Mw1PGVNtx79b4--znwA=.c96fd936-5c6b-4060-a024-57678e7cca0e@github.com>
References: <yv1aUlZMKpLVbXZmkSqZtWLlDTa-5PeX6pzzBu1Rrb8=.6ef681fe-6dbd-4dab-9ee0-61f59fbeb024@github.com>
 <OXsrLxDdaBPdxmvQKXmNls23YKxKrlc4-Ca3zQxuwp4=.a4445686-8b22-4163-a93d-3069b58cf180@github.com>
 <GrgGNmwtG_W8d_TgFzCIXAN9Mw1PGVNtx79b4--znwA=.c96fd936-5c6b-4060-a024-57678e7cca0e@github.com>
Message-ID: <xemPjFkA-OZjQsa3N2Z51CKr2XdW-WHvgQ1TySxhGpA=.e6593e99-a4b7-4356-8ed9-a213dba226f5@github.com>

On Mon, 5 Dec 2022 14:46:12 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Marked as reviewed by jbhateja (Reviewer).
>
>> @jatin-bhateja Do you have any comments on this change?
> 
> LGTM. Thanks.

Thanks @jatin-bhateja for your review. I will integrate this.

-------------

PR: https://git.openjdk.org/jdk/pull/11427

From pli at openjdk.org  Tue Dec  6 09:19:39 2022
From: pli at openjdk.org (Pengfei Li)
Date: Tue, 6 Dec 2022 09:19:39 GMT
Subject: Integrated: 8297689: Fix incorrect result of Short.reverseBytes() call
 in loops
In-Reply-To: <yv1aUlZMKpLVbXZmkSqZtWLlDTa-5PeX6pzzBu1Rrb8=.6ef681fe-6dbd-4dab-9ee0-61f59fbeb024@github.com>
References: <yv1aUlZMKpLVbXZmkSqZtWLlDTa-5PeX6pzzBu1Rrb8=.6ef681fe-6dbd-4dab-9ee0-61f59fbeb024@github.com>
Message-ID: <pWroGRQdG6V4R4I3psEk0dNzXp2vKfELady_sLT4Thk=.b7f9afec-0f1b-48c4-b94a-6898a859a59c@github.com>

On Wed, 30 Nov 2022 07:20:11 GMT, Pengfei Li <pli at openjdk.org> wrote:

> Recently, we find calling `Short.reverseBytes()` in loops may generate incorrect result if the code is compiled by C2. Below is a simple case to reproduce.
> 
> 
> class Foo {
>   static final int SIZE = 50;
>   static int a[] = new int[SIZE];
> 
>   static void test() {
>     for (int i = 0; i < SIZE; i++) {
>       a[i] = Short.reverseBytes((short) a[i]);
>     }
>   }
> 
>   public static void main(String[] args) throws Exception {
>     Class.forName("java.lang.Short");
>     a[25] = 16;
>     test();
>     System.out.println(a[25]);
>   }
> }
> 
> // $ java -Xint Foo
> // 4096
> // $ java -Xcomp -XX:-TieredCompilation -XX:CompileOnly=Foo.test Foo
> // 268435456
> 
> 
> In this case, the `reverseBytes()` call is intrinsified and transformed into a `ReverseBytesS` node. But then C2 compiler incorrectly vectorizes it into `ReverseBytesV` with int type. C2 `Op_ReverseBytes*` has short, char, int and long versions. Their behaviors are different for different data sizes. In superword, subword operation itself doesn't have precise data size info. Instead, the data size info comes from memory operations in its use-def chain. Hence, vectorization of `reverseBytes()` is valid only if the data size is consistent with the type size of the caller's class. But current C2 compiler code lacks fine-grained type checks for `ReverseBytes*` in vector transformation. It results in `reverseBytes()` call from Short or Character class with int load/store gets vectorized incorrectly in above case.
> 
> To fix the issue, this patch adds more checks in `VectorNode::opcode()`. T_BYTE is a special case for `Op_ReverseBytes*`. As the Java Byte class doesn't have `reverseBytes()` method so there's no `Op_ReverseBytesB`. But T_BYTE may still appear in VectorAPI calls. In this patch we still use `Op_ReverseBytesI` for T_BYTE to ensure vector intrinsification succeeds.
> 
> Tested with hotspot::hotspot_all_no_apps, jdk tier1~3 and langtools tier1 on x86 and AArch64, no issue is found.

This pull request has now been integrated.

Changeset: a6139985
Author:    Pengfei Li <pli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a61399854a9db8e3c0cb3f391fa557cb37e02571
Stats:     166 lines in 6 files changed: 160 ins; 2 del; 4 mod

8297689: Fix incorrect result of Short.reverseBytes() call in loops

Reviewed-by: thartmann, jbhateja

-------------

PR: https://git.openjdk.org/jdk/pull/11427

From dnsimon at openjdk.org  Tue Dec  6 09:47:29 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 6 Dec 2022 09:47:29 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v5]
In-Reply-To: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
Message-ID: <kU-NHwhiGEJLa7-o38UCemcxhU8WR_ijQBMGOAknOTs=.57d0341c-30af-4c39-ab42-4278fdfb2e5d@github.com>

> Libgraal is compiled ahead of time and should not need any JVMCI Java code to be dynamically loaded at runtime. Prior to this PR, this is not the case due to:
> 
> * Code to copy system properties from the HotSpot heap into the libgraal heap. This is in `jdk.vm.ci.services.Services.initializeSavedProperties(byte[])` and `jdk.vm.ci.services.Services.serializeSavedProperties()`. This code should be moved to `java.base/jdk.internal.vm.VMSupport`.
> * Code to translate exceptions from the HotSpot heap into the libgraal heap and vice versa. This code should be moved from `jdk.internal.vm.ci//jdk.vm.ci.hotspot.TranslatedException` to `java.base/jdk.internal.vm.VMSupport`.
> 
> This PR makes the above changes. As a result, it's possible to build a JDK image that includes (and uses) libgraal but does not include `jdk.internal.vm.ci` or `jdk.internal.vm.compiler`. This both reduces footprint and better isolates the JAVMCI and the Graal compiler as accessing these components from Java code is now impossible.

Doug Simon has updated the pull request incrementally with two additional commits since the last revision:

 - incorporate review feedback [skip ci]
 - removed hard-coded module name [skip ci]

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11513/files
  - new: https://git.openjdk.org/jdk/pull/11513/files/29e100b3..342d5e3c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11513&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11513&range=03-04

  Stats: 6 lines in 4 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/11513.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11513/head:pull/11513

PR: https://git.openjdk.org/jdk/pull/11513

From xlinzheng at openjdk.org  Tue Dec  6 09:54:20 2022
From: xlinzheng at openjdk.org (Xiaolin Zheng)
Date: Tue, 6 Dec 2022 09:54:20 GMT
Subject: RFR: 8298075: RISC-V: Implement post-call NOPs [v4]
In-Reply-To: <inZ_2fowZZQz0C53E2h4zURoyQIwZcJaBfhC4zwFyb8=.cbc7e361-9bad-48ce-b6d4-c3a8fe2e1cba@github.com>
References: <inZ_2fowZZQz0C53E2h4zURoyQIwZcJaBfhC4zwFyb8=.cbc7e361-9bad-48ce-b6d4-c3a8fe2e1cba@github.com>
Message-ID: <n6raYiRp2H_KUs6FJuC-A9kNAq5F_A3yoGanivVIklI=.a82a5917-5008-4e94-863a-851a868620a1@github.com>

> Same as [JDK-8287567](https://bugs.openjdk.org/browse/JDK-8287567), we need to implement post-call NOPs in the RISC-V backend.
> 
> We use `li32` to implement it. `li32` will signed-extend the loaded imm32 to a 64-bit register. However, our reader `NativePostCallNop::displacement()` only needs the low 32 bits value so we are safe.
> 
> The current post-call NOP is like:
> 
> nop                    (always 4-byte, used for deoptimization, please see `NativePostCallNop::make_deopt()`)
> lui zr, <imm20>        (always 4-byte)
> addiw zr, zr, <imm12>  (always 4-byte)
> 
> 
> The code size here is the same as the AArch64 counterpart, 12 bytes.
> 
> The logic of setting the post-call NOP displacement is at `install_post_call_nop_displacement()` [1] when nmethods are being installed, so no one is running post-call NOPs when we are patching them.
> 
> One can check them by directly using `java --enable-preview -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly`.
> 
> Tested hotspot tier1~4 and jdk tier1~4 using fastdebug by force turning on `--enable-preview`; SPECjbb2015 and dacapo were tested without regressions found. Skynet JMH benchmark seems to have an improvement from `8662ms/op -> 8495ms/op`.
> 
> Thanks,
> Xiaolin
> 
> [1] https://github.com/openjdk/jdk/blob/b49fd920b6690a8b828c85e45c10e5c4c54d2022/src/hotspot/share/code/nmethod.cpp#L1078-L1107

Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision:

  Capital

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11502/files
  - new: https://git.openjdk.org/jdk/pull/11502/files/8fb83ac3..9146aaa4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11502&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11502&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11502.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11502/head:pull/11502

PR: https://git.openjdk.org/jdk/pull/11502

From xlinzheng at openjdk.org  Tue Dec  6 09:54:23 2022
From: xlinzheng at openjdk.org (Xiaolin Zheng)
Date: Tue, 6 Dec 2022 09:54:23 GMT
Subject: RFR: 8298075: RISC-V: Implement post-call NOPs [v3]
In-Reply-To: <OUtM8LMDO_-j50IsVHkh2ohEUVHmvC0x8PM7aj7BGwo=.e92b378d-c12d-45f4-a0fd-b36d1f685ca6@github.com>
References: <inZ_2fowZZQz0C53E2h4zURoyQIwZcJaBfhC4zwFyb8=.cbc7e361-9bad-48ce-b6d4-c3a8fe2e1cba@github.com>
 <xMEcjdDuKZ8gp-McOsb-zADkmNUFZQdfteY5pshX3TY=.ad6f4996-8370-48e7-bea5-c2ed2282a601@github.com>
 <OUtM8LMDO_-j50IsVHkh2ohEUVHmvC0x8PM7aj7BGwo=.e92b378d-c12d-45f4-a0fd-b36d1f685ca6@github.com>
Message-ID: <K1XxoC9p_Smump9VWDHGGAnLK5IsANg9ZrbrwbjQlhw=.bb9ca741-0193-4d5a-abf0-47032defaf4d@github.com>

On Tue, 6 Dec 2022 07:47:46 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Better to remove the ASSERT for we already use assert()
>
> src/hotspot/cpu/riscv/nativeInst_riscv.cpp line 448:
> 
>> 446: 
>> 447: int NativePostCallNop::displacement() const {
>> 448:   // discard the high 32-bit
> 
> Suggestion: // Discard the high 32 bits

Thank you - done.

-------------

PR: https://git.openjdk.org/jdk/pull/11502

From aboldtch at openjdk.org  Tue Dec  6 09:57:39 2022
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 6 Dec 2022 09:57:39 GMT
Subject: RFR: 8297235: ZGC: assert(regs[i] != regs[j]) failed: Multiple
 uses of register: rax [v2]
In-Reply-To: <jYsSVWwRPyRKvs8HYIwp6Ar5Z0XISOwp1DM4A0AgdOQ=.378c74fb-a4e1-45a5-82b0-838c2fcba43a@github.com>
References: <jYsSVWwRPyRKvs8HYIwp6Ar5Z0XISOwp1DM4A0AgdOQ=.378c74fb-a4e1-45a5-82b0-838c2fcba43a@github.com>
Message-ID: <rm0HdbjtmwDm_ClqNUypFHEOGjSPSEP4AOnbjMIvSyY=.780dcf62-8411-47d9-a097-cdc3d2e3bd9c@github.com>

> Tests java/util/stream/test/org/openjdk/tests/java/util/* with -XX:+UseZGC -Xcomp -XX:-TieredCompilation crashes with `assert(regs[i] != regs[j]) failed: Multiple uses of register: rax`. More specifically compilation of java.util.concurrent.ForkJoinTask::awaitDone.
> 
> The reason seems to be that the compare value and the memory input ends up sharing a register. (Uses Unsafe CAS which CAS an object reference into a field of that object, `oldval: rax` and `mem: [rax+offset]`). The Z load barrier stub dispatch implementation require that the reference and reference address occupy distinct registers. In the loadP nodes this is established by marking all but the memory TEMP which results in no sharing.
> 
> This is not possible for the CompareAndSwapP / CompareAndExchangeP nodes as the compare value is an input node. 
> 
> The solution proposed here is less than ideal as it makes the CAS nodes require one extra TEMP register, which in the common case is unused. This puts unnecessary extra strain on the register allocation. The problem is that there is no way currently (that I can find) to express in .ad that a memory input must not share registers with a specific other input. 
> 
> There is an alternative solution for this specific crash which does not use a second TEMP register (see commit: cfd5ced4e97e986fc10c5a8721b543cd3101c58a). It accomplish this by using the same trick that the aarch64 Z CAS node uses which is to specify the memory as indirect which results in the address being LEA into a register. However from what I can see this does not guarantee that the address and the reference does not share a register (`oldval: rax` and `mem: [rax]`). So it is theoretically broken, (and so is the aarch64 implementation). 
> 
> It is unclear to me if there is ever a way for C2 to generation a CAS which compares the address of the field with its content. 
> 
> I call on anyone with more knowledge about `adlc` and `C2` for feedback. And specifically I want to open up a discussion with these points:
> * Is there some other way of expressing in the .ad file that a memory input should not share some register?
>   * If not, is this a worthwhile RFE? As it seems to be a patterned used at least in other places in Z.
> * Will the indirect input ever share a register with oldval and/or are the aarch64/riscv implementations broken because of this? How about ppc?
> 
> Testing: linux-x64 zgc tagged tests tier 1-7 and some specific crashing tests with `-XX:+UseZGC -Xcomp -XX:-TieredCompilation` (in: java/util/stream/, java/util/concurrent/)

Axel Boldt-Christmas has updated the pull request incrementally with two additional commits since the last revision:

 - indirect zXChgP as well
 - indirect alternative

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11410/files
  - new: https://git.openjdk.org/jdk/pull/11410/files/74f7567b..42a72c1e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11410&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11410&range=00-01

  Stats: 20 lines in 1 file changed: 1 ins; 6 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/11410.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11410/head:pull/11410

PR: https://git.openjdk.org/jdk/pull/11410

From eosterlund at openjdk.org  Tue Dec  6 10:05:30 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 6 Dec 2022 10:05:30 GMT
Subject: RFR: 8295258: Add BasicType argument to
 AccessInternal::decorator_fixup
In-Reply-To: <YBwrHyKAaMXOp3FPiulhZik-LMKaTPbQOS5Li2NqVlQ=.7aa77dca-5d76-4b79-99de-1de5c1410fad@github.com>
References: <YBwrHyKAaMXOp3FPiulhZik-LMKaTPbQOS5Li2NqVlQ=.7aa77dca-5d76-4b79-99de-1de5c1410fad@github.com>
Message-ID: <JsWMfzOzI-stn0mxOi5IA2O1677ZdG0XsTxiX2s94DE=.99f89c05-63e6-49bb-9a1d-3717064e38ca@github.com>

On Thu, 13 Oct 2022 10:24:15 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> There are call sites of the access API that does not specify the `INTERNAL_VALUE_IS_OOP` decorator for some reference type access. Change it so that `AccessInternal::decorator_fixup` is able to add this decorator by passing in the `BasicType` of the access.
> 
> Testing: Oracle platforms tier 1-3 and GHA

Looks good.

-------------

Marked as reviewed by eosterlund (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10692

From duke at openjdk.org  Tue Dec  6 10:06:53 2022
From: duke at openjdk.org (Afshin Zafari)
Date: Tue, 6 Dec 2022 10:06:53 GMT
Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v3]
In-Reply-To: <Dj9YfY10SLn8dR1Ez3kEQe4tXm1q5W1TS8_4r3gBUsY=.6c38825a-86e5-4575-a509-683786d242a6@github.com>
References: <Dj9YfY10SLn8dR1Ez3kEQe4tXm1q5W1TS8_4r3gBUsY=.6c38825a-86e5-4575-a509-683786d242a6@github.com>
Message-ID: <4Lu6vFSdEefYOpSkb9-SVZtuIImXfl53AngEB3aGnCI=.b9ecadcb-b32c-4288-a2e8-72d3e888c0fc@github.com>

> test of tier1-5 passed.

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  8292741: Convert JvmtiTagMapTable to ResourceHashtable

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11288/files
  - new: https://git.openjdk.org/jdk/pull/11288/files/cd0ca72c..32392428

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11288&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11288&range=01-02

  Stats: 56 lines in 3 files changed: 2 ins; 11 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/11288.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11288/head:pull/11288

PR: https://git.openjdk.org/jdk/pull/11288

From aboldtch at openjdk.org  Tue Dec  6 10:08:32 2022
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 6 Dec 2022 10:08:32 GMT
Subject: RFR: 8297235: ZGC: assert(regs[i] != regs[j]) failed: Multiple
 uses of register: rax [v2]
In-Reply-To: <rm0HdbjtmwDm_ClqNUypFHEOGjSPSEP4AOnbjMIvSyY=.780dcf62-8411-47d9-a097-cdc3d2e3bd9c@github.com>
References: <jYsSVWwRPyRKvs8HYIwp6Ar5Z0XISOwp1DM4A0AgdOQ=.378c74fb-a4e1-45a5-82b0-838c2fcba43a@github.com>
 <rm0HdbjtmwDm_ClqNUypFHEOGjSPSEP4AOnbjMIvSyY=.780dcf62-8411-47d9-a097-cdc3d2e3bd9c@github.com>
Message-ID: <Kab6rcOUG23tl9dw5ctDAJv_4dNz8j6R430WgA5EM8o=.f2710f78-9668-4d00-8285-65a945bcbf54@github.com>

On Tue, 6 Dec 2022 09:57:39 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Tests java/util/stream/test/org/openjdk/tests/java/util/* with -XX:+UseZGC -Xcomp -XX:-TieredCompilation crashes with `assert(regs[i] != regs[j]) failed: Multiple uses of register: rax`. More specifically compilation of java.util.concurrent.ForkJoinTask::awaitDone.
>> 
>> The reason seems to be that the compare value and the memory input ends up sharing a register. (Uses Unsafe CAS which CAS an object reference into a field of that object, `oldval: rax` and `mem: [rax+offset]`). The Z load barrier stub dispatch implementation require that the reference and reference address occupy distinct registers. In the loadP nodes this is established by marking all but the memory TEMP which results in no sharing.
>> 
>> This is not possible for the CompareAndSwapP / CompareAndExchangeP nodes as the compare value is an input node. 
>> 
>> The solution proposed here is less than ideal as it makes the CAS nodes require one extra TEMP register, which in the common case is unused. This puts unnecessary extra strain on the register allocation. The problem is that there is no way currently (that I can find) to express in .ad that a memory input must not share registers with a specific other input. 
>> 
>> There is an alternative solution for this specific crash which does not use a second TEMP register (see commit: cfd5ced4e97e986fc10c5a8721b543cd3101c58a). It accomplish this by using the same trick that the aarch64 Z CAS node uses which is to specify the memory as indirect which results in the address being LEA into a register. However from what I can see this does not guarantee that the address and the reference does not share a register (`oldval: rax` and `mem: [rax]`). So it is theoretically broken, (and so is the aarch64 implementation). 
>> 
>> It is unclear to me if there is ever a way for C2 to generation a CAS which compares the address of the field with its content. 
>> 
>> I call on anyone with more knowledge about `adlc` and `C2` for feedback. And specifically I want to open up a discussion with these points:
>> * Is there some other way of expressing in the .ad file that a memory input should not share some register?
>>   * If not, is this a worthwhile RFE? As it seems to be a patterned used at least in other places in Z.
>> * Will the indirect input ever share a register with oldval and/or are the aarch64/riscv implementations broken because of this? How about ppc?
>> 
>> Testing: linux-x64 zgc tagged tests tier 1-7 and some specific crashing tests with `-XX:+UseZGC -Xcomp -XX:-TieredCompilation` (in: java/util/stream/, java/util/concurrent/)
>
> Axel Boldt-Christmas has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - indirect zXChgP as well
>  - indirect alternative

Changed all nodes to `indirect` memory inputs to ensure disjoint registers.

-------------

PR: https://git.openjdk.org/jdk/pull/11410

From dsamersoff at openjdk.org  Tue Dec  6 10:14:14 2022
From: dsamersoff at openjdk.org (Dmitry Samersoff)
Date: Tue, 6 Dec 2022 10:14:14 GMT
Subject: RFR: 8291302: ARM32: nmethod entry barriers support [v3]
In-Reply-To: <yXHL12HCx4xOqUa1BFQBrNwEBUDHzKCBLIWm7i173XI=.1258f4b6-bd02-41d5-96f2-381ee8278d15@github.com>
References: <BJaszr0_haU4UZOyQQEA9P0SOlgtfTtGFBj9VSRD5SM=.ffd6af56-a51e-4627-90cb-0eb0e1bbd5e8@github.com>
 <vENPpkRJ7ZlN6k5ymTCUUiESeWfx6ibyJdTpjPMIjvw=.445df16d-28ca-47ec-9a6b-2bbc1cd7ae95@github.com>
 <yXHL12HCx4xOqUa1BFQBrNwEBUDHzKCBLIWm7i173XI=.1258f4b6-bd02-41d5-96f2-381ee8278d15@github.com>
Message-ID: <4LXD-jXwQQ9bH3BzHWprQSxSaOlh_81cWa-hm9_s180=.bd5b0d72-ec05-418e-95ea-bb4e96b02bc6@github.com>

On Mon, 5 Dec 2022 16:24:09 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

>> src/hotspot/cpu/arm/gc/shared/barrierSetAssembler_arm.cpp line 221:
>> 
>>> 219:   // Subsequent loads of oops must occur after load of guard value.
>>> 220:   // BarrierSetNMethod::disarm sets guard with release semantics.
>>> 221:   __ membar(MacroAssembler::LoadLoad, tmp1);
>> 
>> Is my assumption correct that ARM32 supports neither ZGC nor ShenandoahGC?
>> If so then no memory barrier is needed as no oops are modified concurrently with G1 (and other GCs are not concurrent).
>> I'd recomment to implement `BarrierSetAssembler::nmethod_patching_type()` as on AARCH64 and replace the membar with an assertion that `NMethodPatchingType::stw_instruction_and_data_patch` is in effect.
>> @fisk wouldn't it be good if there was a shared method to query if oops (other values?) are modified concurrently?
>
> The membar is now removed.

I'm second to the proposal to move nmethod_patching_type() to shared code.

-------------

PR: https://git.openjdk.org/jdk/pull/11442

From xlinzheng at openjdk.org  Tue Dec  6 10:33:31 2022
From: xlinzheng at openjdk.org (Xiaolin Zheng)
Date: Tue, 6 Dec 2022 10:33:31 GMT
Subject: RFR: 8298075: RISC-V: Implement post-call NOPs [v5]
In-Reply-To: <inZ_2fowZZQz0C53E2h4zURoyQIwZcJaBfhC4zwFyb8=.cbc7e361-9bad-48ce-b6d4-c3a8fe2e1cba@github.com>
References: <inZ_2fowZZQz0C53E2h4zURoyQIwZcJaBfhC4zwFyb8=.cbc7e361-9bad-48ce-b6d4-c3a8fe2e1cba@github.com>
Message-ID: <MIQJcqxuYeItDxkc2I_Vw7z0o-lRJezPPsEWOYkwaxY=.503b314e-3ed3-409b-86c3-efbb1dc19ce6@github.com>

> Same as [JDK-8287567](https://bugs.openjdk.org/browse/JDK-8287567), we need to implement post-call NOPs in the RISC-V backend.
> 
> We use `li32` to implement it. `li32` will signed-extend the loaded imm32 to a 64-bit register. However, our reader `NativePostCallNop::displacement()` only needs the low 32 bits value so we are safe.
> 
> The current post-call NOP is like:
> 
> nop                    (always 4-byte, used for deoptimization, please see `NativePostCallNop::make_deopt()`)
> lui zr, <imm20>        (always 4-byte)
> addiw zr, zr, <imm12>  (always 4-byte)
> 
> 
> The code size here is the same as the AArch64 counterpart, 12 bytes.
> 
> The logic of setting the post-call NOP displacement is at `install_post_call_nop_displacement()` [1] when nmethods are being installed, so no one is running post-call NOPs when we are patching them.
> 
> One can check them by directly using `java --enable-preview -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly`.
> 
> Tested hotspot tier1~4 and jdk tier1~4 using fastdebug by force turning on `--enable-preview`; SPECjbb2015 and dacapo were tested without regressions found. Skynet JMH benchmark seems to have an improvement from `8662ms/op -> 8495ms/op`.
> 
> Thanks,
> Xiaolin
> 
> [1] https://github.com/openjdk/jdk/blob/b49fd920b6690a8b828c85e45c10e5c4c54d2022/src/hotspot/share/code/nmethod.cpp#L1078-L1107

Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision:

  -

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11502/files
  - new: https://git.openjdk.org/jdk/pull/11502/files/9146aaa4..bb5e4633

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11502&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11502&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11502.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11502/head:pull/11502

PR: https://git.openjdk.org/jdk/pull/11502

From xlinzheng at openjdk.org  Tue Dec  6 10:41:59 2022
From: xlinzheng at openjdk.org (Xiaolin Zheng)
Date: Tue, 6 Dec 2022 10:41:59 GMT
Subject: RFR: 8298075: RISC-V: Implement post-call NOPs [v6]
In-Reply-To: <inZ_2fowZZQz0C53E2h4zURoyQIwZcJaBfhC4zwFyb8=.cbc7e361-9bad-48ce-b6d4-c3a8fe2e1cba@github.com>
References: <inZ_2fowZZQz0C53E2h4zURoyQIwZcJaBfhC4zwFyb8=.cbc7e361-9bad-48ce-b6d4-c3a8fe2e1cba@github.com>
Message-ID: <ORZHK2_0RTYb9rtYkX_JXTTcex_LryeoYT3rk6mrIxs=.6743e193-2cc6-49b9-a896-befd73206072@github.com>

> Same as [JDK-8287567](https://bugs.openjdk.org/browse/JDK-8287567), we need to implement post-call NOPs in the RISC-V backend.
> 
> We use `li32` to implement it. `li32` will signed-extend the loaded imm32 to a 64-bit register. However, our reader `NativePostCallNop::displacement()` only needs the low 32 bits value so we are safe.
> 
> The current post-call NOP is like:
> 
> nop                    (always 4-byte, used for deoptimization, please see `NativePostCallNop::make_deopt()`)
> lui zr, <imm20>        (always 4-byte)
> addiw zr, zr, <imm12>  (always 4-byte)
> 
> 
> The code size here is the same as the AArch64 counterpart, 12 bytes.
> 
> The logic of setting the post-call NOP displacement is at `install_post_call_nop_displacement()` [1] when nmethods are being installed, so no one is running post-call NOPs when we are patching them.
> 
> One can check them by directly using `java --enable-preview -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly`.
> 
> Tested hotspot tier1~4 and jdk tier1~4 using fastdebug by force turning on `--enable-preview`; SPECjbb2015 and dacapo were tested without regressions found. Skynet JMH benchmark seems to have an improvement from `8662ms/op -> 8495ms/op`.
> 
> Thanks,
> Xiaolin
> 
> [1] https://github.com/openjdk/jdk/blob/b49fd920b6690a8b828c85e45c10e5c4c54d2022/src/hotspot/share/code/nmethod.cpp#L1078-L1107

Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision:

  Plural form...

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11502/files
  - new: https://git.openjdk.org/jdk/pull/11502/files/bb5e4633..21142c15

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11502&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11502&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11502.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11502/head:pull/11502

PR: https://git.openjdk.org/jdk/pull/11502

From sjohanss at openjdk.org  Tue Dec  6 11:54:37 2022
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Tue, 6 Dec 2022 11:54:37 GMT
Subject: RFR: 8157023: Integrate NMT with JFR [v3]
In-Reply-To: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
Message-ID: <CPYmGbn5ElMPM6ai1Cn15NoR4z4Wka-C-G09T91Tszk=.6d99c5b0-4077-4553-85f3-22f5008f66d5@github.com>

> Please review this enhancement to include NMT information in JFR recordings.
> 
> **Summary**
> Native Memory Tracking summary information can be obtained from a running VM using `jcmd` if started with `-XX:NativeMemoryTracking=summary/detail`. Using `jcmd` requires you to run a separate process and to parse the output to get the needed information. This change adds JFR events for NMT information to enable additional ways to consume the NMT data.
> 
> There are two new events added:
> * _NativeMemoryUsage_ - The total native memory usage.
> * _NativeMemoryUsagePart_ - The native memory usage for each component.
> 
> These events are sent periodically and by default the interval is 1s. This can of course be discussed, but that is the staring point. When NMT is not enabled on events will be sent.
> 
> **Testing**
> * Added a simple test to verify that the events are sent as expected depending on if NMT is enabled or not.
> * Mach5 sanity testing

Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision:

  Special snapshot for NMT events in JFR

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11449/files
  - new: https://git.openjdk.org/jdk/pull/11449/files/57ab6576..04017864

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11449&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11449&range=01-02

  Stats: 263 lines in 5 files changed: 200 ins; 26 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/11449.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11449/head:pull/11449

PR: https://git.openjdk.org/jdk/pull/11449

From sjohanss at openjdk.org  Tue Dec  6 12:01:18 2022
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Tue, 6 Dec 2022 12:01:18 GMT
Subject: RFR: 8157023: Integrate NMT with JFR [v3]
In-Reply-To: <CPYmGbn5ElMPM6ai1Cn15NoR4z4Wka-C-G09T91Tszk=.6d99c5b0-4077-4553-85f3-22f5008f66d5@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <CPYmGbn5ElMPM6ai1Cn15NoR4z4Wka-C-G09T91Tszk=.6d99c5b0-4077-4553-85f3-22f5008f66d5@github.com>
Message-ID: <f6MSozwGsCmhKGxVPw-8qVky6uTJMsm1nAVHsRunEmo=.311ba28d-6b39-4f5b-8f97-3ed8b112385d@github.com>

On Tue, 6 Dec 2022 11:54:37 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Please review this enhancement to include NMT information in JFR recordings.
>> 
>> **Summary**
>> Native Memory Tracking summary information can be obtained from a running VM using `jcmd` if started with `-XX:NativeMemoryTracking=summary/detail`. Using `jcmd` requires you to run a separate process and to parse the output to get the needed information. This change adds JFR events for NMT information to enable additional ways to consume the NMT data.
>> 
>> There are two new events added:
>> * _NativeMemoryUsage_ - The total native memory usage.
>> * _NativeMemoryUsagePart_ - The native memory usage for each component.
>> 
>> These events are sent periodically and by default the interval is 1s. This can of course be discussed, but that is the staring point. When NMT is not enabled on events will be sent.
>> 
>> **Testing**
>> * Added a simple test to verify that the events are sent as expected depending on if NMT is enabled or not.
>> * Mach5 sanity testing
>
> Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Special snapshot for NMT events in JFR

Updated the change as discussed above. Summary of the changes:
* New `MemSnapshot` class that can be configured to not walk the thread stacks
* Using this for JFR events (thread stacks are not walked)
* Skipping `mtNone` when sending events
* Not grouping `mtThread` and `mtThreadStack` as text report is doing, they are reported as individual events. 
* Handling `mtChunk` as MemBaseline to avoid double counting, which leads to keeping a `ThreadCritical` for over the "malloc snapshot" to make sure we have consistent values.

I'm not totally sure I think there need to be options to skip malloc and vm snapshot, but I included it since it was proposed and discussed. I have no strong opinion, but I think they could be always included.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From kbarrett at openjdk.org  Tue Dec  6 12:34:47 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 6 Dec 2022 12:34:47 GMT
Subject: RFR: 8293824: gc/whitebox/TestConcMarkCycleWB.java failed
 "RuntimeException: assertTrue: expected true, was false" [v2]
In-Reply-To: <74AnEqLugaEU80XMNm8edtWBmK8gOFMirnZT1rdj1jI=.6ab039c0-3db5-4336-9aa7-867166b79cda@github.com>
References: <74AnEqLugaEU80XMNm8edtWBmK8gOFMirnZT1rdj1jI=.6ab039c0-3db5-4336-9aa7-867166b79cda@github.com>
Message-ID: <dM4t6tEt_ECKHylcGy7v2lL8FOXa1j336ycPFt07Jnc=.1b984fe9-d268-4384-85d9-0984fff815a6@github.com>

> Please review this change to WhiteBox and some tests involving G1 concurrent GCs.
> 
> Some tests currently use WhiteBox.g1StartConcMarkCycle() to trigger a
> concurrent GC.  Many of them follow it with a loop waiting for a concurrent
> cycle to not be in progress.  A few also preceed that call with a similar
> loop, since that call does nothing and returns false if a concurrent cycle is
> already in progress.  Those tests typically want to ensure there was a
> concurrent cycle that was started after some setup.
> 
> The failing test calls that function, asserting that it returned true, e.g. a
> new concurrent cycle was started.
> 
> There are various problems with this, due to races with concurrent cycles
> started automatically and possibly aborted (by full GCs) concurrent cycles,
> making some of these tests unreliable in some configurations.
> 
> For example, the test failure associated with this bug intermittently arises
> when running with `-Xcomp`, triggering a concurrent cycle before the explicit
> requests by the test, causing the explicit request to fail (because there is
> already one in progress), failing the assert.  Waiting for there not to be an
> in-progress cycle before the explicit request just narrows the race window.
> 
> We have a different mechanism for controlling concurrent cycles, the
> concurrent GC breakpoint mechanism.  By adding a counter specifically for such
> cycles, we can use GC breakpoints to ensure only the concurrent cycles the
> test wants are occurring, and can verify they completed successfully.
> 
> So we change tests using WhiteBox.g1StartConcMarkCycle() to instead use GC
> breakpoints, along with the new WhiteBox.g1CompletedConcurrentMarkCycles() to
> avoid racing request problems and to detect aborted cycles.  Since it is no
> longer used, WhiteBox.g1StartConcMarkCycle() is removed.
> 
> Testing:
> mach5 tier1-6

Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - use new whitebox api for running conc gc
 - Merge branch 'master' into test-concmark
 - copyrights
 - remove WB.g1StartConcMarkCyle
 - update tests
 - add utility GC breakpoint functions
 - add G1ConcurrentMark::completed_mark_cycles() and whitebox access

-------------

Changes: https://git.openjdk.org/jdk/pull/11435/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11435&range=01
  Stats: 281 lines in 22 files changed: 96 ins; 131 del; 54 mod
  Patch: https://git.openjdk.org/jdk/pull/11435.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11435/head:pull/11435

PR: https://git.openjdk.org/jdk/pull/11435

From eosterlund at openjdk.org  Tue Dec  6 12:55:08 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 6 Dec 2022 12:55:08 GMT
Subject: RFR: 8297235: ZGC: assert(regs[i] != regs[j]) failed: Multiple
 uses of register: rax [v2]
In-Reply-To: <rm0HdbjtmwDm_ClqNUypFHEOGjSPSEP4AOnbjMIvSyY=.780dcf62-8411-47d9-a097-cdc3d2e3bd9c@github.com>
References: <jYsSVWwRPyRKvs8HYIwp6Ar5Z0XISOwp1DM4A0AgdOQ=.378c74fb-a4e1-45a5-82b0-838c2fcba43a@github.com>
 <rm0HdbjtmwDm_ClqNUypFHEOGjSPSEP4AOnbjMIvSyY=.780dcf62-8411-47d9-a097-cdc3d2e3bd9c@github.com>
Message-ID: <-arq1zqCxRuduy61u2dK3Xw_5pqAtK4mqON9DUYOexY=.62173499-5730-4f75-a293-f7c8c1060cab@github.com>

On Tue, 6 Dec 2022 09:57:39 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Tests java/util/stream/test/org/openjdk/tests/java/util/* with -XX:+UseZGC -Xcomp -XX:-TieredCompilation crashes with `assert(regs[i] != regs[j]) failed: Multiple uses of register: rax`. More specifically compilation of java.util.concurrent.ForkJoinTask::awaitDone.
>> 
>> The reason seems to be that the compare value and the memory input ends up sharing a register. (Uses Unsafe CAS which CAS an object reference into a field of that object, `oldval: rax` and `mem: [rax+offset]`). The Z load barrier stub dispatch implementation require that the reference and reference address occupy distinct registers. In the loadP nodes this is established by marking all but the memory TEMP which results in no sharing.
>> 
>> This is not possible for the CompareAndSwapP / CompareAndExchangeP nodes as the compare value is an input node. 
>> 
>> The solution proposed here is less than ideal as it makes the CAS nodes require one extra TEMP register, which in the common case is unused. This puts unnecessary extra strain on the register allocation. The problem is that there is no way currently (that I can find) to express in .ad that a memory input must not share registers with a specific other input. 
>> 
>> There is an alternative solution for this specific crash which does not use a second TEMP register (see commit: cfd5ced4e97e986fc10c5a8721b543cd3101c58a). It accomplish this by using the same trick that the aarch64 Z CAS node uses which is to specify the memory as indirect which results in the address being LEA into a register. However from what I can see this does not guarantee that the address and the reference does not share a register (`oldval: rax` and `mem: [rax]`). So it is theoretically broken, (and so is the aarch64 implementation). 
>> 
>> It is unclear to me if there is ever a way for C2 to generation a CAS which compares the address of the field with its content. 
>> 
>> I call on anyone with more knowledge about `adlc` and `C2` for feedback. And specifically I want to open up a discussion with these points:
>> * Is there some other way of expressing in the .ad file that a memory input should not share some register?
>>   * If not, is this a worthwhile RFE? As it seems to be a patterned used at least in other places in Z.
>> * Will the indirect input ever share a register with oldval and/or are the aarch64/riscv implementations broken because of this? How about ppc?
>> 
>> Testing: linux-x64 zgc tagged tests tier 1-7 and some specific crashing tests with `-XX:+UseZGC -Xcomp -XX:-TieredCompilation` (in: java/util/stream/, java/util/concurrent/)
>
> Axel Boldt-Christmas has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - indirect zXChgP as well
>  - indirect alternative

Looks good!

-------------

Marked as reviewed by eosterlund (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11410

From duke at openjdk.org  Tue Dec  6 13:00:34 2022
From: duke at openjdk.org (Johannes Bechberger)
Date: Tue, 6 Dec 2022 13:00:34 GMT
Subject: RFR: 8297967: Make frame::safe_for_sender safer [v3]
In-Reply-To: <Cctc-M2HyUqIjpcRyTjmF46wKDqvBtnnYe5Mn45sdO8=.03bdf65f-bf98-48dc-b957-0c838003d46f@github.com>
References: <Cctc-M2HyUqIjpcRyTjmF46wKDqvBtnnYe5Mn45sdO8=.03bdf65f-bf98-48dc-b957-0c838003d46f@github.com>
Message-ID: <LbBox9cLe5dtgeApK-ObyTEb-7CNtfCf8qoY2aXF1Ck=.fb09d91e-6469-418b-8e45-97d47d22a9f5@github.com>

> Makes frame::safe_for_sender safer by using os::is_readable_pointer to check the location of the return address.

Johannes Bechberger has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  Make frame::safe_for_sender safer with SafeFetch

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11461/files
  - new: https://git.openjdk.org/jdk/pull/11461/files/a8903005..f7762551

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11461&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11461&range=01-02

  Stats: 26 lines in 4 files changed: 5 ins; 16 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/11461.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11461/head:pull/11461

PR: https://git.openjdk.org/jdk/pull/11461

From duke at openjdk.org  Tue Dec  6 13:00:37 2022
From: duke at openjdk.org (Johannes Bechberger)
Date: Tue, 6 Dec 2022 13:00:37 GMT
Subject: RFR: 8297967: Make frame::safe_for_sender safer [v2]
In-Reply-To: <W7jCII0F-N-vINSt1vg_g0ejpVSv27GSlBtuKRyS790=.ec4382ea-28b1-4daa-8812-57a7b2be9e18@github.com>
References: <Cctc-M2HyUqIjpcRyTjmF46wKDqvBtnnYe5Mn45sdO8=.03bdf65f-bf98-48dc-b957-0c838003d46f@github.com>
 <W7jCII0F-N-vINSt1vg_g0ejpVSv27GSlBtuKRyS790=.ec4382ea-28b1-4daa-8812-57a7b2be9e18@github.com>
Message-ID: <52N29BY4CldJMqd1K8epyGQ-B8ax6oBC_XP5pSRtarI=.33c654d9-3170-4adc-a862-fa1e28035c48@github.com>

On Thu, 1 Dec 2022 19:21:54 GMT, Johannes Bechberger <duke at openjdk.org> wrote:

>> Makes frame::safe_for_sender safer by using os::is_readable_pointer to check the location of the return address.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Imrove fix, thanks Martin

My new version just uses `SafeFetchN` in the place where I consistently get segfaults in my fuzzer and it works.

The issue might happen when ASGCT (and my ASGST for which I wrote a fuzzer) are called with modified sp and fp, which async-profiler might do.

-------------

PR: https://git.openjdk.org/jdk/pull/11461

From stuefe at openjdk.org  Tue Dec  6 13:09:21 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 6 Dec 2022 13:09:21 GMT
Subject: RFR: 8157023: Integrate NMT with JFR [v3]
In-Reply-To: <CPYmGbn5ElMPM6ai1Cn15NoR4z4Wka-C-G09T91Tszk=.6d99c5b0-4077-4553-85f3-22f5008f66d5@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <CPYmGbn5ElMPM6ai1Cn15NoR4z4Wka-C-G09T91Tszk=.6d99c5b0-4077-4553-85f3-22f5008f66d5@github.com>
Message-ID: <5nCzSDxaca_61r8x5HdtCmT0adPGE84rHcFWH1dZQd8=.f2c52ff7-13b9-43ab-9bc3-02dbb4c31a20@github.com>

On Tue, 6 Dec 2022 11:54:37 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Please review this enhancement to include NMT information in JFR recordings.
>> 
>> **Summary**
>> Native Memory Tracking summary information can be obtained from a running VM using `jcmd` if started with `-XX:NativeMemoryTracking=summary/detail`. Using `jcmd` requires you to run a separate process and to parse the output to get the needed information. This change adds JFR events for NMT information to enable additional ways to consume the NMT data.
>> 
>> There are two new events added:
>> * _NativeMemoryUsage_ - The total native memory usage.
>> * _NativeMemoryUsagePart_ - The native memory usage for each component.
>> 
>> These events are sent periodically and by default the interval is 1s. This can of course be discussed, but that is the staring point. When NMT is not enabled on events will be sent.
>> 
>> **Testing**
>> * Added a simple test to verify that the events are sent as expected depending on if NMT is enabled or not.
>> * Mach5 sanity testing
>
> Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Special snapshot for NMT events in JFR

Hi @kstefanj ,

Getting closer. See remarks. I did not look closely at the JFR side of things, just the NMT code.

Cheers, Thomas

src/hotspot/share/services/memJfrReporter.hpp line 47:

> 45: class MemJFRSnapshot : public AllStatic {
> 46: private:
> 47:   // The baseline age threshold in millie seconds. If older

s/millie seconds/milliseconds?

src/hotspot/share/services/memSnapshot.cpp line 59:

> 57:   // is deducted from mtChunk in the end to give correct values.
> 58:   ThreadCritical tc;
> 59:   MallocMemorySnapshot* ms = MallocMemorySummary::as_snapshot();

make `const MallocMemorySnapshot*` - this is the one true copy of the real counters, since as_snapshot does not copy. We don't want to modify it.

src/hotspot/share/services/memSnapshot.cpp line 64:

> 62:   for (int i = 0; i < mt_number_of_types; i++) {
> 63:     MEMFLAGS flag = NMTUtil::index_to_flag(i);
> 64:     MallocMemory* mm = ms->by_type(flag);

Make const too, and could you please add a const variant for MallocMemorySnapshot::by_type?

src/hotspot/share/services/memSnapshot.cpp line 68:

> 66:     total_arena_size +=  mm->arena_size();
> 67:   }
> 68:   assert(total_arena_size == ms->total_arena(), "Mismatch in accounting");

Could fail intermittently since all counters are updated asynchronously. The snapshot can be modified below us while we assemble this MemSnapshot. I think that's fine, but I would just use the accumulated counter here.

src/hotspot/share/services/memSnapshot.cpp line 93:

> 91:   // Total virtual memory size.
> 92:   _vm_total.reserved = vms->total_reserved();
> 93:   _vm_total.committed = vms->total_committed();

Here too, this is the live snapshot which can be modified while we iterate over its counters. If you want to appear consistent, I would add up committed and reserved above and use those instead of the total counter from vms.

src/hotspot/share/services/memSnapshot.cpp line 99:

> 97:   if (_snapshot_options.update_thread_stacks) {
> 98:     walk_thread_stacks();
> 99:   }

It does not make sense to walk_thread_stacks independently from the VM snapshot, since it piggy-backs on it. I would move this into the _snapshot_options.include_vm condition.

src/hotspot/share/services/memSnapshot.hpp line 42:

> 40: };
> 41: 
> 42: class MemSnapshot : public CHeapObj<mtNMT> {

Can we name this not Snapshot but something different? We already have MallocMemorySnapshot and methods like "as_snapshot", which have nothing to do with this layer.

proposals:

`NMTData`
`NMTStatistics`
`NMTStatSet`

.... 
....

-------------

Changes requested by stuefe (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11449

From alanb at openjdk.org  Tue Dec  6 13:16:43 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 6 Dec 2022 13:16:43 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v5]
In-Reply-To: <kU-NHwhiGEJLa7-o38UCemcxhU8WR_ijQBMGOAknOTs=.57d0341c-30af-4c39-ab42-4278fdfb2e5d@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
 <kU-NHwhiGEJLa7-o38UCemcxhU8WR_ijQBMGOAknOTs=.57d0341c-30af-4c39-ab42-4278fdfb2e5d@github.com>
Message-ID: <-vjDxNaafm1m5UERR31dFXH7jdljWTKzsDjntS8v6zs=.4c777f1e-695f-42de-a4b5-0cb0f332243c@github.com>

On Tue, 6 Dec 2022 09:47:29 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Libgraal is compiled ahead of time and should not need any JVMCI Java code to be dynamically loaded at runtime. Prior to this PR, this is not the case due to:
>> 
>> * Code to copy system properties from the HotSpot heap into the libgraal heap. This is in `jdk.vm.ci.services.Services.initializeSavedProperties(byte[])` and `jdk.vm.ci.services.Services.serializeSavedProperties()`. This code should be moved to `java.base/jdk.internal.vm.VMSupport`.
>> * Code to translate exceptions from the HotSpot heap into the libgraal heap and vice versa. This code should be moved from `jdk.internal.vm.ci//jdk.vm.ci.hotspot.TranslatedException` to `java.base/jdk.internal.vm.VMSupport`.
>> 
>> This PR makes the above changes. As a result, it's possible to build a JDK image that includes (and uses) libgraal but does not include `jdk.internal.vm.ci` or `jdk.internal.vm.compiler`. This both reduces footprint and better isolates the JAVMCI and the Graal compiler as accessing these components from Java code is now impossible.
>
> Doug Simon has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - incorporate review feedback [skip ci]
>  - removed hard-coded module name [skip ci]

src/java.base/share/classes/jdk/internal/vm/TranslatedException.java line 44:

> 42:  */
> 43: @SuppressWarnings("serial")
> 44: final class TranslatedException extends Exception {

Would it be possible to re-format this to avoid the wildly long (150+) lines? This seems to be moving jdk.vm.ci.hotspot.TranslatedException and hard to see what is going on.

src/java.base/share/classes/jdk/internal/vm/VMSupport.java line 66:

> 64:      *               only contains String keys and values.
> 65:      */
> 66:     private static byte[] serializePropertiesToByteArray(Properties p, boolean filter) throws IOException {

I think we need more context as to why there are non-String system properties in use here.

src/java.base/share/classes/jdk/internal/vm/VMSupport.java line 106:

> 104:         }
> 105:         if (props.get("oome") != null) {
> 106:             throw new OutOfMemoryError("forced OOME");

I don't think code in java.base should be checking for a property named "oome".  Is this for a test that sets this system property on the command line?

-------------

PR: https://git.openjdk.org/jdk/pull/11513

From sjohanss at openjdk.org  Tue Dec  6 13:17:29 2022
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Tue, 6 Dec 2022 13:17:29 GMT
Subject: RFR: 8157023: Integrate NMT with JFR [v3]
In-Reply-To: <5nCzSDxaca_61r8x5HdtCmT0adPGE84rHcFWH1dZQd8=.f2c52ff7-13b9-43ab-9bc3-02dbb4c31a20@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <CPYmGbn5ElMPM6ai1Cn15NoR4z4Wka-C-G09T91Tszk=.6d99c5b0-4077-4553-85f3-22f5008f66d5@github.com>
 <5nCzSDxaca_61r8x5HdtCmT0adPGE84rHcFWH1dZQd8=.f2c52ff7-13b9-43ab-9bc3-02dbb4c31a20@github.com>
Message-ID: <8TDMjZUMK8IF-SOQRwJ3sIsmDxuhpxY5cXUcGGcSCfM=.28d78a46-65b8-4be0-aeaa-dfebb0bacf7c@github.com>

On Tue, 6 Dec 2022 12:18:04 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Special snapshot for NMT events in JFR
>
> src/hotspot/share/services/memSnapshot.cpp line 68:
> 
>> 66:     total_arena_size +=  mm->arena_size();
>> 67:   }
>> 68:   assert(total_arena_size == ms->total_arena(), "Mismatch in accounting");
> 
> Could fail intermittently since all counters are updated asynchronously. The snapshot can be modified below us while we assemble this MemSnapshot. I think that's fine, but I would just use the accumulated counter here.

Good point, was about to add other verification as well but stayed away just because of this issue. But didn't think about it when I added this.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From sjohanss at openjdk.org  Tue Dec  6 13:36:06 2022
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Tue, 6 Dec 2022 13:36:06 GMT
Subject: RFR: 8157023: Integrate NMT with JFR [v3]
In-Reply-To: <5nCzSDxaca_61r8x5HdtCmT0adPGE84rHcFWH1dZQd8=.f2c52ff7-13b9-43ab-9bc3-02dbb4c31a20@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <CPYmGbn5ElMPM6ai1Cn15NoR4z4Wka-C-G09T91Tszk=.6d99c5b0-4077-4553-85f3-22f5008f66d5@github.com>
 <5nCzSDxaca_61r8x5HdtCmT0adPGE84rHcFWH1dZQd8=.f2c52ff7-13b9-43ab-9bc3-02dbb4c31a20@github.com>
Message-ID: <K-IkTW19EmF02G_O2O_CsmocE0xe0iP6Wemvf3H1KCQ=.b2867b0d-c14d-4c76-a647-90709fa533f6@github.com>

On Tue, 6 Dec 2022 12:53:31 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Special snapshot for NMT events in JFR
>
> src/hotspot/share/services/memSnapshot.cpp line 99:
> 
>> 97:   if (_snapshot_options.update_thread_stacks) {
>> 98:     walk_thread_stacks();
>> 99:   }
> 
> It does not make sense to walk_thread_stacks independently from the VM snapshot, since it piggy-backs on it. I would move this into the _snapshot_options.include_vm condition.

True and this is why I kind of think malloc and vm should not be optional. But I can move this into the "vm" condition.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From lkorinth at openjdk.org  Tue Dec  6 13:45:50 2022
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 6 Dec 2022 13:45:50 GMT
Subject: RFR: 8296401: ConcurrentHashTable::bulk_delete might miss to
 delete some objects
In-Reply-To: <_bNq28p7YDTdicn_-pwN-xB-CHeMUUtTsJfCLTV_CGw=.d82a1a64-7f07-472d-af3c-427fba8598d1@github.com>
References: <rWw3Hb1baG5eslMgFnOdEP1Q4avhfYc3uTpjdB9DaP0=.23f34ff0-eff9-421b-9e70-7f119fd90e5d@github.com>
 <srzYQG8vQxXtFu8IYd4LzHoFZo6VR8_D_9e5wlek0u4=.c3fb4829-6de5-428e-9b70-f34aeba9c55f@github.com>
 <XlpaIj9dRjwUPkQTmLqfWNx7r4afKUu5cE4xUDRwNgw=.96918f61-bb6d-4d92-995d-d763adf6df63@github.com>
 <-46D7o9D9hweEylWT61buGVsoYYFZLlKezzaBgt7GvQ=.7e7b3755-98cb-4696-ba07-0ba3b7046a4a@github.com>
 <oh4H4jjhdQ2TR37v4PsDr99lVtux72HC5gnUkCo5TgQ=.620d2b25-916c-42a5-b655-1cdf5dbd2328@github.com>
 <_bNq28p7YDTdicn_-pwN-xB-CHeMUUtTsJfCLTV_CGw=.d82a1a64-7f07-472d-af3c-427fba8598d1@github.com>
Message-ID: <u6q4wu2XAkhfwRnUo9YZIbKQLby_obt1cECdFIG0e_w=.b2616c79-1bc3-4efb-bd97-3ebfc4c753c0@github.com>

On Mon, 5 Dec 2022 15:12:00 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> > That is true. Do you think that is a problem with the new implementation?
> > The change overrides the intentions of `BULK_DELETE_LIMIT ` so it would be better to change the name of that constant.

Is `STACK_BUFFER_SIZE` good enough, or do you have a better suggestion? I would also prefer to make it look less like a C macro and use the alternative casing `StackBufferSize`, is that OK?

-------------

PR: https://git.openjdk.org/jdk/pull/10983

From sjohanss at openjdk.org  Tue Dec  6 14:00:47 2022
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Tue, 6 Dec 2022 14:00:47 GMT
Subject: RFR: 8157023: Integrate NMT with JFR [v3]
In-Reply-To: <5nCzSDxaca_61r8x5HdtCmT0adPGE84rHcFWH1dZQd8=.f2c52ff7-13b9-43ab-9bc3-02dbb4c31a20@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <CPYmGbn5ElMPM6ai1Cn15NoR4z4Wka-C-G09T91Tszk=.6d99c5b0-4077-4553-85f3-22f5008f66d5@github.com>
 <5nCzSDxaca_61r8x5HdtCmT0adPGE84rHcFWH1dZQd8=.f2c52ff7-13b9-43ab-9bc3-02dbb4c31a20@github.com>
Message-ID: <7h_yHywAtdvulVXw1hVhqCVARaexGTar6BtTXz3KYBc=.910b12d1-c0ec-482a-b72a-09f87ec9a606@github.com>

On Tue, 6 Dec 2022 12:47:13 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Special snapshot for NMT events in JFR
>
> src/hotspot/share/services/memSnapshot.hpp line 42:
> 
>> 40: };
>> 41: 
>> 42: class MemSnapshot : public CHeapObj<mtNMT> {
> 
> Can we name this not Snapshot but something different? We already have MallocMemorySnapshot and methods like "as_snapshot", which have nothing to do with this layer.
> 
> proposals:
> 
> `NMTData`
> `NMTStatistics`
> `NMTStatSet`
> 
> .... 
> ....

I assume you don't think `NMTSnapshot` is good much better =) I can't come up with something much better than your suggestions, `NMTUsage` is not perfect either (sound like the usage cause by NMT). If we don't go with the NMT-prefix I think something like `MemUsage`or `NativeMemoryUsage` would make sense. Looking at the other reporting classes connected to NMT they are named `Mem`-something. So I think `MemUsage`, what do you think?

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From duke at openjdk.org  Tue Dec  6 14:07:59 2022
From: duke at openjdk.org (Johannes Bechberger)
Date: Tue, 6 Dec 2022 14:07:59 GMT
Subject: RFR: 8297967: Make frame::safe_for_sender safer [v3]
In-Reply-To: <LbBox9cLe5dtgeApK-ObyTEb-7CNtfCf8qoY2aXF1Ck=.fb09d91e-6469-418b-8e45-97d47d22a9f5@github.com>
References: <Cctc-M2HyUqIjpcRyTjmF46wKDqvBtnnYe5Mn45sdO8=.03bdf65f-bf98-48dc-b957-0c838003d46f@github.com>
 <LbBox9cLe5dtgeApK-ObyTEb-7CNtfCf8qoY2aXF1Ck=.fb09d91e-6469-418b-8e45-97d47d22a9f5@github.com>
Message-ID: <8KsHu2ypfzPixM85aVHG9GkBk5Da4goHxEpO5-D9mOg=.73e43e00-2c58-4dd7-bb6b-b389d492a076@github.com>

On Tue, 6 Dec 2022 13:00:34 GMT, Johannes Bechberger <duke at openjdk.org> wrote:

>> Makes frame::safe_for_sender safer by using os::is_readable_pointer to check the location of the return address.
>
> Johannes Bechberger has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   Make frame::safe_for_sender safer with SafeFetch

I added a few more safe fetches, safe_for_sender should now be guarded against any broken fp.

-------------

PR: https://git.openjdk.org/jdk/pull/11461

From duke at openjdk.org  Tue Dec  6 14:05:46 2022
From: duke at openjdk.org (Johannes Bechberger)
Date: Tue, 6 Dec 2022 14:05:46 GMT
Subject: RFR: 8297967: Make frame::safe_for_sender safer [v4]
In-Reply-To: <Cctc-M2HyUqIjpcRyTjmF46wKDqvBtnnYe5Mn45sdO8=.03bdf65f-bf98-48dc-b957-0c838003d46f@github.com>
References: <Cctc-M2HyUqIjpcRyTjmF46wKDqvBtnnYe5Mn45sdO8=.03bdf65f-bf98-48dc-b957-0c838003d46f@github.com>
Message-ID: <e3vJR9zIIQhpNIZS6iKXDbWc_MfAuFS7qoA8te_NGKE=.564f894d-6d4f-4336-b74c-25fc3b25594c@github.com>

> Makes frame::safe_for_sender safer by using os::is_readable_pointer to check the location of the return address.

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  More SafeFetch

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11461/files
  - new: https://git.openjdk.org/jdk/pull/11461/files/f7762551..32cced6e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11461&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11461&range=02-03

  Stats: 24 lines in 4 files changed: 24 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11461.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11461/head:pull/11461

PR: https://git.openjdk.org/jdk/pull/11461

From qamai at openjdk.org  Tue Dec  6 14:24:39 2022
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 6 Dec 2022 14:24:39 GMT
Subject: RFR: 8292289: [vectorapi] Improve the implementation of
 VectorTestNode [v14]
In-Reply-To: <IcR6eOr6iM1b9B1I1zUQnI2J9hQAmdSRHYc9CdIGW5E=.3b8dd64d-2eff-4659-b75a-81c4b008e41a@github.com>
References: <IcR6eOr6iM1b9B1I1zUQnI2J9hQAmdSRHYc9CdIGW5E=.3b8dd64d-2eff-4659-b75a-81c4b008e41a@github.com>
Message-ID: <Jo8mnLoA_9Pb8TzocN6zG5s2PGGVxS53s6XP_5CasLo=.de864d1a-51b5-4ceb-b12d-1d20e34735d7@github.com>

> This patch modifies the node generation of `VectorSupport::test` to emit a `CMoveINode`, which is picked up by `BoolNode::Ideal(PhaseGVN*, bool)` to connect the `VectorTestNode` directly to the `BoolNode`, removing the redundant operations of materialising the test result in a GP register and do a `CmpI` to get back the flags. As a result, `VectorMask<T>::alltrue` is compiled into machine codes:
> 
>         vptest xmm0, xmm1
>         jb if_true
>     if_false:
> 
> instead of:
> 
>         vptest xmm0, xmm1
>         setb r10
>         movzbl r10
>         testl r10
>         jne if_true
>     if_false:
> 
> The results of `jdk.incubator.vector.ArrayMismatchBenchmark` shows noticeable improvements:
> 
>                                                                                        Before                  After
>     Benchmark                                      Prefix    Size   Mode  Cnt       Score      Error       Score     Error    Units  Change
>     ArrayMismatchBenchmark.mismatchVectorByte         0.5       9  thrpt   10  217345.383 ? 8316.444  222279.381 ? 2660.983  ops/ms   +2.3%
>     ArrayMismatchBenchmark.mismatchVectorByte         0.5     257  thrpt   10  113918.406 ? 1618.836  116268.691 ? 1291.899  ops/ms   +2.1%
>     ArrayMismatchBenchmark.mismatchVectorByte         0.5  100000  thrpt   10     702.066 ?   72.862     797.806 ?   16.429  ops/ms  +13.6%
>     ArrayMismatchBenchmark.mismatchVectorByte         1.0       9  thrpt   10  146096.564 ? 2401.258  145338.910 ?  687.453  ops/ms   -0.5%
>     ArrayMismatchBenchmark.mismatchVectorByte         1.0     257  thrpt   10   60598.181 ? 1259.397   69041.519 ? 1073.156  ops/ms  +13.9%
>     ArrayMismatchBenchmark.mismatchVectorByte         1.0  100000  thrpt   10     316.814 ?   10.975     408.770 ?    5.281  ops/ms  +29.0%
>     ArrayMismatchBenchmark.mismatchVectorDouble       0.5       9  thrpt   10  195674.549 ? 1200.166  188482.433 ? 1872.076  ops/ms   -3.7%
>     ArrayMismatchBenchmark.mismatchVectorDouble       0.5     257  thrpt   10   44357.169 ?  473.013   42293.411 ? 2838.255  ops/ms   -4.7%
>     ArrayMismatchBenchmark.mismatchVectorDouble       0.5  100000  thrpt   10      68.199 ?    5.410      67.628 ?    3.241  ops/ms   -0.8%
>     ArrayMismatchBenchmark.mismatchVectorDouble       1.0       9  thrpt   10  107722.450 ? 1677.607  111060.400 ?  982.230  ops/ms   +3.1%
>     ArrayMismatchBenchmark.mismatchVectorDouble       1.0     257  thrpt   10   16692.645 ? 1002.599   21440.506 ? 1618.266  ops/ms  +28.4%
>     ArrayMismatchBenchmark.mismatchVectorDouble       1.0  100000  thrpt   10      32.984 ?    0.548      33.202 ?    2.365  ops/ms   +0.7%
>     ArrayMismatchBenchmark.mismatchVectorInt          0.5       9  thrpt   10  335458.217 ? 3154.842  379944.254 ? 5703.134  ops/ms  +13.3%
>     ArrayMismatchBenchmark.mismatchVectorInt          0.5     257  thrpt   10   58505.302 ?  786.312   56721.368 ? 2497.052  ops/ms   -3.0%
>     ArrayMismatchBenchmark.mismatchVectorInt          0.5  100000  thrpt   10     133.037 ?   11.415     139.537 ?    4.667  ops/ms   +4.9%
>     ArrayMismatchBenchmark.mismatchVectorInt          1.0       9  thrpt   10  117943.802 ? 2281.349  112409.365 ? 2110.055  ops/ms   -4.7%
>     ArrayMismatchBenchmark.mismatchVectorInt          1.0     257  thrpt   10   27060.015 ?  795.619   33756.613 ?  826.533  ops/ms  +24.7%
>     ArrayMismatchBenchmark.mismatchVectorInt          1.0  100000  thrpt   10      57.558 ?    8.927      66.951 ?    4.381  ops/ms  +16.3%
>     ArrayMismatchBenchmark.mismatchVectorLong         0.5       9  thrpt   10  182963.715 ? 1042.497  182438.405 ? 2120.832  ops/ms   -0.3%
>     ArrayMismatchBenchmark.mismatchVectorLong         0.5     257  thrpt   10   36672.215 ?  614.821   35397.398 ? 1609.235  ops/ms   -3.5%
>     ArrayMismatchBenchmark.mismatchVectorLong         0.5  100000  thrpt   10      66.438 ?    2.142      65.427 ?    2.270  ops/ms   -1.5%
>     ArrayMismatchBenchmark.mismatchVectorLong         1.0       9  thrpt   10  110393.047 ?  497.853  115165.845 ? 5381.674  ops/ms   +4.3%
>     ArrayMismatchBenchmark.mismatchVectorLong         1.0     257  thrpt   10   14720.765 ?  661.350   19871.096 ?  201.464  ops/ms  +35.0%
>     ArrayMismatchBenchmark.mismatchVectorLong         1.0  100000  thrpt   10      30.760 ?    0.821      31.933 ?    1.352  ops/ms   +3.8%
> 
> I have not been able to conduct throughout testing on AVX512 and Aarch64 so any help would be invaluable. Thank you very much.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  fix test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9855/files
  - new: https://git.openjdk.org/jdk/pull/9855/files/1fec3d30..8d9ebed9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9855&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9855&range=12-13

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/9855.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9855/head:pull/9855

PR: https://git.openjdk.org/jdk/pull/9855

From qamai at openjdk.org  Tue Dec  6 14:35:17 2022
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 6 Dec 2022 14:35:17 GMT
Subject: RFR: 8292289: [vectorapi] Improve the implementation of
 VectorTestNode [v13]
In-Reply-To: <BnDOAcTq3gjayANa3p1dL5Y3szwlU7VRbF-cgsi4uXQ=.c1c8b28c-8458-4985-9292-96e3ae4fea98@github.com>
References: <IcR6eOr6iM1b9B1I1zUQnI2J9hQAmdSRHYc9CdIGW5E=.3b8dd64d-2eff-4659-b75a-81c4b008e41a@github.com>
 <955ScdreoJQ7PG5cXUmly_giKjOJx8ouU8oy1DX_GEA=.7c59dbbb-4a3b-4f35-a951-4cf0aaa6a047@github.com>
 <BnDOAcTq3gjayANa3p1dL5Y3szwlU7VRbF-cgsi4uXQ=.c1c8b28c-8458-4985-9292-96e3ae4fea98@github.com>
Message-ID: <brNKLLSunu76lfuCdNLuPwphP5sg56u8t8G0ry8KaNo=.71634238-9641-4d66-a4c3-4bb16a1a1027@github.com>

On Tue, 6 Dec 2022 04:25:58 GMT, Hao Sun <haosun at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 30 commits:
>> 
>>  - Merge branch 'master' into improveVTest
>>  - Merge branch 'master' into improveVTest
>>  - redundant casts
>>  - remove untaken code paths
>>  - Merge branch 'master' into improveVTest
>>  - Merge branch 'master' into improveVTest
>>  - Merge branch 'master' into improveVTest
>>  - fix merge problems
>>  - Merge branch 'master' into improveVTest
>>  - refactor x86
>>  - ... and 20 more: https://git.openjdk.org/jdk/compare/2f83b5c4...1fec3d30
>
> I'm running some tests on AArch64 platform (both Neon and SVE).

@shqking Thanks a lot for your reviews, I have addressed those in the commits

-------------

PR: https://git.openjdk.org/jdk/pull/9855

From haosun at openjdk.org  Tue Dec  6 14:39:05 2022
From: haosun at openjdk.org (Hao Sun)
Date: Tue, 6 Dec 2022 14:39:05 GMT
Subject: RFR: 8292289: [vectorapi] Improve the implementation of
 VectorTestNode [v14]
In-Reply-To: <Jo8mnLoA_9Pb8TzocN6zG5s2PGGVxS53s6XP_5CasLo=.de864d1a-51b5-4ceb-b12d-1d20e34735d7@github.com>
References: <IcR6eOr6iM1b9B1I1zUQnI2J9hQAmdSRHYc9CdIGW5E=.3b8dd64d-2eff-4659-b75a-81c4b008e41a@github.com>
 <Jo8mnLoA_9Pb8TzocN6zG5s2PGGVxS53s6XP_5CasLo=.de864d1a-51b5-4ceb-b12d-1d20e34735d7@github.com>
Message-ID: <U__5t1-RAovkPp07HT_pw4hX63ZvK4-rqHjuqgmkMWw=.cb75c74a-532a-4bd5-a726-b8a99c5fde35@github.com>

On Tue, 6 Dec 2022 14:24:39 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> This patch modifies the node generation of `VectorSupport::test` to emit a `CMoveINode`, which is picked up by `BoolNode::Ideal(PhaseGVN*, bool)` to connect the `VectorTestNode` directly to the `BoolNode`, removing the redundant operations of materialising the test result in a GP register and do a `CmpI` to get back the flags. As a result, `VectorMask<T>::alltrue` is compiled into machine codes:
>> 
>>         vptest xmm0, xmm1
>>         jb if_true
>>     if_false:
>> 
>> instead of:
>> 
>>         vptest xmm0, xmm1
>>         setb r10
>>         movzbl r10
>>         testl r10
>>         jne if_true
>>     if_false:
>> 
>> The results of `jdk.incubator.vector.ArrayMismatchBenchmark` shows noticeable improvements:
>> 
>>                                                                                        Before                  After
>>     Benchmark                                      Prefix    Size   Mode  Cnt       Score      Error       Score     Error    Units  Change
>>     ArrayMismatchBenchmark.mismatchVectorByte         0.5       9  thrpt   10  217345.383 ? 8316.444  222279.381 ? 2660.983  ops/ms   +2.3%
>>     ArrayMismatchBenchmark.mismatchVectorByte         0.5     257  thrpt   10  113918.406 ? 1618.836  116268.691 ? 1291.899  ops/ms   +2.1%
>>     ArrayMismatchBenchmark.mismatchVectorByte         0.5  100000  thrpt   10     702.066 ?   72.862     797.806 ?   16.429  ops/ms  +13.6%
>>     ArrayMismatchBenchmark.mismatchVectorByte         1.0       9  thrpt   10  146096.564 ? 2401.258  145338.910 ?  687.453  ops/ms   -0.5%
>>     ArrayMismatchBenchmark.mismatchVectorByte         1.0     257  thrpt   10   60598.181 ? 1259.397   69041.519 ? 1073.156  ops/ms  +13.9%
>>     ArrayMismatchBenchmark.mismatchVectorByte         1.0  100000  thrpt   10     316.814 ?   10.975     408.770 ?    5.281  ops/ms  +29.0%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       0.5       9  thrpt   10  195674.549 ? 1200.166  188482.433 ? 1872.076  ops/ms   -3.7%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       0.5     257  thrpt   10   44357.169 ?  473.013   42293.411 ? 2838.255  ops/ms   -4.7%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       0.5  100000  thrpt   10      68.199 ?    5.410      67.628 ?    3.241  ops/ms   -0.8%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       1.0       9  thrpt   10  107722.450 ? 1677.607  111060.400 ?  982.230  ops/ms   +3.1%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       1.0     257  thrpt   10   16692.645 ? 1002.599   21440.506 ? 1618.266  ops/ms  +28.4%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       1.0  100000  thrpt   10      32.984 ?    0.548      33.202 ?    2.365  ops/ms   +0.7%
>>     ArrayMismatchBenchmark.mismatchVectorInt          0.5       9  thrpt   10  335458.217 ? 3154.842  379944.254 ? 5703.134  ops/ms  +13.3%
>>     ArrayMismatchBenchmark.mismatchVectorInt          0.5     257  thrpt   10   58505.302 ?  786.312   56721.368 ? 2497.052  ops/ms   -3.0%
>>     ArrayMismatchBenchmark.mismatchVectorInt          0.5  100000  thrpt   10     133.037 ?   11.415     139.537 ?    4.667  ops/ms   +4.9%
>>     ArrayMismatchBenchmark.mismatchVectorInt          1.0       9  thrpt   10  117943.802 ? 2281.349  112409.365 ? 2110.055  ops/ms   -4.7%
>>     ArrayMismatchBenchmark.mismatchVectorInt          1.0     257  thrpt   10   27060.015 ?  795.619   33756.613 ?  826.533  ops/ms  +24.7%
>>     ArrayMismatchBenchmark.mismatchVectorInt          1.0  100000  thrpt   10      57.558 ?    8.927      66.951 ?    4.381  ops/ms  +16.3%
>>     ArrayMismatchBenchmark.mismatchVectorLong         0.5       9  thrpt   10  182963.715 ? 1042.497  182438.405 ? 2120.832  ops/ms   -0.3%
>>     ArrayMismatchBenchmark.mismatchVectorLong         0.5     257  thrpt   10   36672.215 ?  614.821   35397.398 ? 1609.235  ops/ms   -3.5%
>>     ArrayMismatchBenchmark.mismatchVectorLong         0.5  100000  thrpt   10      66.438 ?    2.142      65.427 ?    2.270  ops/ms   -1.5%
>>     ArrayMismatchBenchmark.mismatchVectorLong         1.0       9  thrpt   10  110393.047 ?  497.853  115165.845 ? 5381.674  ops/ms   +4.3%
>>     ArrayMismatchBenchmark.mismatchVectorLong         1.0     257  thrpt   10   14720.765 ?  661.350   19871.096 ?  201.464  ops/ms  +35.0%
>>     ArrayMismatchBenchmark.mismatchVectorLong         1.0  100000  thrpt   10      30.760 ?    0.821      31.933 ?    1.352  ops/ms   +3.8%
>> 
>> I have not been able to conduct throughout testing on AVX512 and Aarch64 so any help would be invaluable. Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix test

My test passed.

### Performance testing.

Here shows the data on AArch64 Neon.

                                                                                          Before                 After
  Benchmark                                       (prefix)  (size)   Mode  Cnt        Score      Error       Score      Error   Units  Change
  ArrayMismatchBenchmark.mismatchVectorByte            0.5       9  thrpt    5   188228.938 ? 1304.492  188036.510 ? 1566.468  ops/ms   -0.1%
  ArrayMismatchBenchmark.mismatchVectorByte            0.5     257  thrpt    5    50714.740 ?  251.973   52319.498 ?   73.201  ops/ms    3.2%
  ArrayMismatchBenchmark.mismatchVectorByte            0.5  100000  thrpt    5      188.442 ?    0.829     226.975 ?    1.196  ops/ms   20.4%
  ArrayMismatchBenchmark.mismatchVectorByte            1.0       9  thrpt    5   107464.833 ?    7.967  107461.853 ?   17.613  ops/ms    0.0%
  ArrayMismatchBenchmark.mismatchVectorByte            1.0     257  thrpt    5    27873.228 ?  298.765   28854.655 ?  108.520  ops/ms    3.5%
  ArrayMismatchBenchmark.mismatchVectorByte            1.0  100000  thrpt    5       91.318 ?    0.032      90.234 ?    0.049  ops/ms   -1.2%
  ArrayMismatchBenchmark.mismatchVectorDouble          0.5       9  thrpt    5   104424.609 ?   35.394  111375.725 ?  336.651  ops/ms    6.7%
  ArrayMismatchBenchmark.mismatchVectorDouble          0.5     257  thrpt    5     9466.861 ?   46.815    9523.362 ?   12.216  ops/ms    0.6%
  ArrayMismatchBenchmark.mismatchVectorDouble          0.5  100000  thrpt    5       21.572 ?    0.054      22.462 ?    0.273  ops/ms    4.1%
  ArrayMismatchBenchmark.mismatchVectorDouble          1.0       9  thrpt    5    65201.598 ? 1202.724   70891.579 ?  576.866  ops/ms    8.7%
  ArrayMismatchBenchmark.mismatchVectorDouble          1.0     257  thrpt    5     3931.683 ?    0.432    4241.834 ?    0.531  ops/ms    7.9%
  ArrayMismatchBenchmark.mismatchVectorDouble          1.0  100000  thrpt    5        9.641 ?    0.005      10.209 ?    0.007  ops/ms    5.9%
  ArrayMismatchBenchmark.mismatchVectorInt             0.5       9  thrpt    5   112517.132 ? 1266.658  117607.730 ?  658.935  ops/ms    4.5%
  ArrayMismatchBenchmark.mismatchVectorInt             0.5     257  thrpt    5    14627.711 ?  135.210   19549.735 ?  169.208  ops/ms   33.6%
  ArrayMismatchBenchmark.mismatchVectorInt             0.5  100000  thrpt    5       40.599 ?    0.116      45.500 ?    0.105  ops/ms   12.1%
  ArrayMismatchBenchmark.mismatchVectorInt             1.0       9  thrpt    5    86951.685 ?  770.519   88705.394 ?  112.681  ops/ms    2.0%
  ArrayMismatchBenchmark.mismatchVectorInt             1.0     257  thrpt    5     8229.636 ?    6.450    9400.670 ?    0.555  ops/ms   14.2%
  ArrayMismatchBenchmark.mismatchVectorInt             1.0  100000  thrpt    5       20.437 ?    0.032      25.996 ?    0.142  ops/ms   27.2%
  ArrayMismatchBenchmark.mismatchVectorLong            0.5       9  thrpt    5    98752.429 ?    8.477  106053.731 ?  168.779  ops/ms    7.4%
  ArrayMismatchBenchmark.mismatchVectorLong            0.5     257  thrpt    5     9486.680 ?  113.035    9888.039 ?   10.357  ops/ms    4.2%
  ArrayMismatchBenchmark.mismatchVectorLong            0.5  100000  thrpt    5       22.884 ?    0.118      22.469 ?    0.096  ops/ms   -1.8%
  ArrayMismatchBenchmark.mismatchVectorLong            1.0       9  thrpt    5    72150.373 ?  441.019   71092.863 ?  746.174  ops/ms   -1.5%
  ArrayMismatchBenchmark.mismatchVectorLong            1.0     257  thrpt    5     4604.599 ?   42.457    4690.037 ?    7.356  ops/ms    1.9%
  ArrayMismatchBenchmark.mismatchVectorLong            1.0  100000  thrpt    5       11.147 ?    0.013      11.423 ?    0.012  ops/ms    2.5%

Here shows the data on AArch64 256-bit SVE.

                                                                                           Before                 After
  Benchmark                                       (prefix)  (size)   Mode  Cnt        Score       Error       Score       Error   Units  Change
  ArrayMismatchBenchmark.mismatchVectorByte            0.5       9  thrpt    5   332188.434 ?  1867.441  326994.114 ?  9458.795  ops/ms   -1.6%
  ArrayMismatchBenchmark.mismatchVectorByte            0.5     257  thrpt    5   107444.966 ?  5050.526  100516.133 ?  1436.484  ops/ms   -6.4%
  ArrayMismatchBenchmark.mismatchVectorByte            0.5  100000  thrpt    5      440.107 ?     0.135     460.557 ?     0.276  ops/ms    4.6%
  ArrayMismatchBenchmark.mismatchVectorByte            1.0       9  thrpt    5   194751.414 ?  1218.965  196489.976 ?    70.422  ops/ms    0.9%
  ArrayMismatchBenchmark.mismatchVectorByte            1.0     257  thrpt    5    68305.755 ?   102.463   71301.912 ?   214.791  ops/ms    4.4%
  ArrayMismatchBenchmark.mismatchVectorByte            1.0  100000  thrpt    5      213.639 ?     0.310     212.501 ?     0.200  ops/ms   -0.5%
  ArrayMismatchBenchmark.mismatchVectorDouble          0.5       9  thrpt    5   184926.046 ?  1429.361  197673.463 ?  2065.066  ops/ms    6.9%
  ArrayMismatchBenchmark.mismatchVectorDouble          0.5     257  thrpt    5    27664.974 ?   211.233   30272.798 ?   122.976  ops/ms    9.4%
  ArrayMismatchBenchmark.mismatchVectorDouble          0.5  100000  thrpt    5       82.780 ?     0.078      72.316 ?     0.121  ops/ms  -12.6%
  ArrayMismatchBenchmark.mismatchVectorDouble          1.0       9  thrpt    5   133433.039 ?    23.047  138097.066 ?   321.764  ops/ms    3.5%
  ArrayMismatchBenchmark.mismatchVectorDouble          1.0     257  thrpt    5     9332.847 ?    47.940    9679.395 ?    15.648  ops/ms    3.7%
  ArrayMismatchBenchmark.mismatchVectorDouble          1.0  100000  thrpt    5       25.563 ?     0.010      29.525 ?     1.410  ops/ms   15.5%
  ArrayMismatchBenchmark.mismatchVectorInt             0.5       9  thrpt    5   409670.146 ? 15888.302  385940.625 ?  6430.431  ops/ms   -5.8%
  ArrayMismatchBenchmark.mismatchVectorInt             0.5     257  thrpt    5    36565.150 ?  1295.056   39837.700 ?    82.828  ops/ms    8.9%
  ArrayMismatchBenchmark.mismatchVectorInt             0.5  100000  thrpt    5      115.997 ?     0.986     112.612 ?     0.280  ops/ms   -2.9%
  ArrayMismatchBenchmark.mismatchVectorInt             1.0       9  thrpt    5   153095.509 ?   760.043  159605.937 ?   114.691  ops/ms    4.3%
  ArrayMismatchBenchmark.mismatchVectorInt             1.0     257  thrpt    5    20747.445 ?    28.624   21301.590 ?    64.918  ops/ms    2.7%
  ArrayMismatchBenchmark.mismatchVectorInt             1.0  100000  thrpt    5       52.865 ?     0.033      53.757 ?     0.134  ops/ms    1.7%
  ArrayMismatchBenchmark.mismatchVectorLong            0.5       9  thrpt    5   177529.884 ?   145.103  178435.461 ?  2410.473  ops/ms    0.5%
  ArrayMismatchBenchmark.mismatchVectorLong            0.5     257  thrpt    5    20538.232 ?     7.532   20563.490 ?    53.205  ops/ms    0.1%
  ArrayMismatchBenchmark.mismatchVectorLong            0.5  100000  thrpt    5       50.875 ?     0.736      52.826 ?     0.058  ops/ms    3.8%
  ArrayMismatchBenchmark.mismatchVectorLong            1.0       9  thrpt    5   135797.506 ?   333.638  138437.942 ?    97.186  ops/ms    1.9%
  ArrayMismatchBenchmark.mismatchVectorLong            1.0     257  thrpt    5    10561.460 ?    74.946   10337.813 ?    39.726  ops/ms   -2.1%
  ArrayMismatchBenchmark.mismatchVectorLong            1.0  100000  thrpt    5       26.027 ?     0.020      26.224 ?     0.046  ops/ms    0.8%

I think the performance is acceptable.

### Jtreg testing

1) on AARCH64 Neon, I ran tier1~3.
2) on AArch64 SVE, I ran the cases under the following directories

  "test/hotspot/jtreg/compiler/vectorapi/"
  "test/jdk/jdk/incubator/vector/"
  "test/hotspot/jtreg/compiler/vectorization/"


Besides the **CMOVE_I** issue in `TestVectorTest.java` as I mentioned before, all other test cases passed.

-------------

PR: https://git.openjdk.org/jdk/pull/9855

From alanb at openjdk.org  Tue Dec  6 14:55:27 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 6 Dec 2022 14:55:27 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v37]
In-Reply-To: <gqONKOkeEWYFbAbSNukCiJHu4kEF4UYYyvlyvY_Ijrw=.4ed88dde-08ef-4c4f-b39c-50cbce2bb575@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
 <gqONKOkeEWYFbAbSNukCiJHu4kEF4UYYyvlyvY_Ijrw=.4ed88dde-08ef-4c4f-b39c-50cbce2bb575@github.com>
Message-ID: <RSMGtY27a9G3yWykX4UU2ebj4r-Uqw0pJIvDTJ7w3Ck=.c9f2e6b6-7a87-4189-9458-37a415eb2fa7@github.com>

On Mon, 5 Dec 2022 12:31:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> JEP 429 implementation.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10952

From stuefe at openjdk.org  Tue Dec  6 14:59:07 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 6 Dec 2022 14:59:07 GMT
Subject: RFR: 8157023: Integrate NMT with JFR [v3]
In-Reply-To: <7h_yHywAtdvulVXw1hVhqCVARaexGTar6BtTXz3KYBc=.910b12d1-c0ec-482a-b72a-09f87ec9a606@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <CPYmGbn5ElMPM6ai1Cn15NoR4z4Wka-C-G09T91Tszk=.6d99c5b0-4077-4553-85f3-22f5008f66d5@github.com>
 <5nCzSDxaca_61r8x5HdtCmT0adPGE84rHcFWH1dZQd8=.f2c52ff7-13b9-43ab-9bc3-02dbb4c31a20@github.com>
 <7h_yHywAtdvulVXw1hVhqCVARaexGTar6BtTXz3KYBc=.910b12d1-c0ec-482a-b72a-09f87ec9a606@github.com>
Message-ID: <ZA8ebg-GEponuE7Tx5AUo208rrri1_sMELv9lGmc7Go=.dd685d09-1a98-46d2-b847-31429491d6fa@github.com>

On Tue, 6 Dec 2022 13:58:36 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> src/hotspot/share/services/memSnapshot.hpp line 42:
>> 
>>> 40: };
>>> 41: 
>>> 42: class MemSnapshot : public CHeapObj<mtNMT> {
>> 
>> Can we name this not Snapshot but something different? We already have MallocMemorySnapshot and methods like "as_snapshot", which have nothing to do with this layer.
>> 
>> proposals:
>> 
>> `NMTData`
>> `NMTStatistics`
>> `NMTStatSet`
>> 
>> .... 
>> ....
>
> I assume you don't think `NMTSnapshot` is good much better =) I can't come up with something much better than your suggestions, `NMTUsage` is not perfect either (sound like the usage cause by NMT). If we don't go with the NMT-prefix I think something like `MemUsage`or `NativeMemoryUsage` would make sense. Looking at the other reporting classes connected to NMT they are named `Mem`-something. So I think `MemUsage`, what do you think?

Good. Up to you.

I wish we would allow C++ namespaces, having all in something like "namespace nmt". Then it does not hurt so much if names are a bit more generic.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From sjohanss at openjdk.org  Tue Dec  6 15:02:32 2022
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Tue, 6 Dec 2022 15:02:32 GMT
Subject: RFR: 8157023: Integrate NMT with JFR [v3]
In-Reply-To: <ZA8ebg-GEponuE7Tx5AUo208rrri1_sMELv9lGmc7Go=.dd685d09-1a98-46d2-b847-31429491d6fa@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <CPYmGbn5ElMPM6ai1Cn15NoR4z4Wka-C-G09T91Tszk=.6d99c5b0-4077-4553-85f3-22f5008f66d5@github.com>
 <5nCzSDxaca_61r8x5HdtCmT0adPGE84rHcFWH1dZQd8=.f2c52ff7-13b9-43ab-9bc3-02dbb4c31a20@github.com>
 <7h_yHywAtdvulVXw1hVhqCVARaexGTar6BtTXz3KYBc=.910b12d1-c0ec-482a-b72a-09f87ec9a606@github.com>
 <ZA8ebg-GEponuE7Tx5AUo208rrri1_sMELv9lGmc7Go=.dd685d09-1a98-46d2-b847-31429491d6fa@github.com>
Message-ID: <mWE3nfcn4JOrkDu-9bom6rB8ECVwOP9FmyEYPb3WxOM=.0479da1b-8fa8-470c-8b72-4630046c0871@github.com>

On Tue, 6 Dec 2022 14:56:44 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> I assume you don't think `NMTSnapshot` is good much better =) I can't come up with something much better than your suggestions, `NMTUsage` is not perfect either (sound like the usage cause by NMT). If we don't go with the NMT-prefix I think something like `MemUsage`or `NativeMemoryUsage` would make sense. Looking at the other reporting classes connected to NMT they are named `Mem`-something. So I think `MemUsage`, what do you think?
>
> Good. Up to you.
> 
> I wish we would allow C++ namespaces, having all in something like "namespace nmt". Then it does not hurt so much if names are a bit more generic.

I'll go with `MemUsage`, normally I would have spent some more time trying to come up with something better, but Thursday is getting closer :)

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From sjohanss at openjdk.org  Tue Dec  6 15:07:03 2022
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Tue, 6 Dec 2022 15:07:03 GMT
Subject: RFR: 8157023: Integrate NMT with JFR [v2]
In-Reply-To: <RZ9Im6_Tc3WfjegtsedgUixcMya7Ja53B1fOEyXhyVY=.e2422f36-5e05-43ce-8656-1730a96aedd6@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <7MunRi3rxCpz4mk9VmuV2MixTHklxSKjbuW5SmdiGGU=.31447ad0-1c44-4f45-891d-053bed30ddb7@github.com>
 <RZ9Im6_Tc3WfjegtsedgUixcMya7Ja53B1fOEyXhyVY=.e2422f36-5e05-43ce-8656-1730a96aedd6@github.com>
Message-ID: <WwNqtxslBxTXGUVvrqxU7r6q4GQJ9lw25l_C6lScJEI=.3a3c2554-65c5-4b51-a5ea-db4c4d2a42d0@github.com>

On Mon, 5 Dec 2022 13:49:55 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Stefan Johansson has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Some refactoring after comments
>>  - egahlin and carterkozak comments
>
> Looks good. Small simplification, instead of "_has_xxx" boolean flags, just use your MemSnapshotOptions as member.

Another thing @tstuefe, have you double checked my accounting around `mtChunk`? I tried to mimic what's done for the baseline and normal print-reports. Looks correct?

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From stuefe at openjdk.org  Tue Dec  6 15:10:21 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 6 Dec 2022 15:10:21 GMT
Subject: RFR: 8157023: Integrate NMT with JFR [v3]
In-Reply-To: <CPYmGbn5ElMPM6ai1Cn15NoR4z4Wka-C-G09T91Tszk=.6d99c5b0-4077-4553-85f3-22f5008f66d5@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <CPYmGbn5ElMPM6ai1Cn15NoR4z4Wka-C-G09T91Tszk=.6d99c5b0-4077-4553-85f3-22f5008f66d5@github.com>
Message-ID: <oKSy2h2eANYq5eopXLhkkr039WdfqbHyQdQOQL3Es3w=.a5d57ead-e429-4ae4-8409-e21d60b1faa5@github.com>

On Tue, 6 Dec 2022 11:54:37 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Please review this enhancement to include NMT information in JFR recordings.
>> 
>> **Summary**
>> Native Memory Tracking summary information can be obtained from a running VM using `jcmd` if started with `-XX:NativeMemoryTracking=summary/detail`. Using `jcmd` requires you to run a separate process and to parse the output to get the needed information. This change adds JFR events for NMT information to enable additional ways to consume the NMT data.
>> 
>> There are two new events added:
>> * _NativeMemoryUsage_ - The total native memory usage.
>> * _NativeMemoryUsagePart_ - The native memory usage for each component.
>> 
>> These events are sent periodically and by default the interval is 1s. This can of course be discussed, but that is the staring point. When NMT is not enabled on events will be sent.
>> 
>> **Testing**
>> * Added a simple test to verify that the events are sent as expected depending on if NMT is enabled or not.
>> * Mach5 sanity testing
>
> Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Special snapshot for NMT events in JFR

src/hotspot/share/services/memSnapshot.cpp line 66:

> 64:     MallocMemory* mm = ms->by_type(flag);
> 65:     _malloc_snapshot[i] = mm->malloc_size() + mm->arena_size();
> 66:     total_arena_size +=  mm->arena_size();

Another issue I just noticed is that you now account for memory in owned arena chunks twice, once as mtChunk, and once as arena memory for the owning arena. This is a similar issue as I described in https://github.com/openjdk/jdk/pull/11497#discussion_r1041093340 .

The correct way would be to do a real snapshot with a copy, which calls `MallocMemorySnapshot::make_adjustment()`. But that is expensive. The way you do it, by directly looking at the counters, is faster. Therefore - and because I plan to improve this anyway - my recommendation would be to just omit mtChunk for the moment.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From thartmann at openjdk.org  Tue Dec  6 15:29:00 2022
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 6 Dec 2022 15:29:00 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data
In-Reply-To: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
Message-ID: <qO5maAqpam3RWzS_kbaNdN5OOZyMjJTCUfzGgYVDNE4=.bc22922b-a193-4bd1-9588-af43c1c20572@github.com>

On Tue, 6 Dec 2022 06:13:23 GMT, Justin King <jcking at openjdk.org> wrote:

> Resolve memory leak related to `MethodData::_extra_data_lock` in `Method::build_profiling_method_data` by defining `MethodData::release_C_heap_structures` and calling it where appropriate before deallocating `MethodData`.

FTR, I changed this code with [JDK-8297389](https://bugs.openjdk.org/browse/JDK-8297389) and thereby accidentally introduced the leak. Thanks for fixing!

The fix looks good to me, but I'm not an expert in that area.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11526

From stuefe at openjdk.org  Tue Dec  6 15:36:07 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 6 Dec 2022 15:36:07 GMT
Subject: RFR: 8157023: Integrate NMT with JFR [v2]
In-Reply-To: <RZ9Im6_Tc3WfjegtsedgUixcMya7Ja53B1fOEyXhyVY=.e2422f36-5e05-43ce-8656-1730a96aedd6@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <7MunRi3rxCpz4mk9VmuV2MixTHklxSKjbuW5SmdiGGU=.31447ad0-1c44-4f45-891d-053bed30ddb7@github.com>
 <RZ9Im6_Tc3WfjegtsedgUixcMya7Ja53B1fOEyXhyVY=.e2422f36-5e05-43ce-8656-1730a96aedd6@github.com>
Message-ID: <YkA2oaeWt2qaz9wWpAJuMgOrnDcIdyt90g9NHqlUQys=.041ba0a3-c593-4882-8636-4ffdf3cae99c@github.com>

On Mon, 5 Dec 2022 13:49:55 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Stefan Johansson has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Some refactoring after comments
>>  - egahlin and carterkozak comments
>
> Looks good. Small simplification, instead of "_has_xxx" boolean flags, just use your MemSnapshotOptions as member.

> Another thing @tstuefe, have you double checked my accounting around `mtChunk`? I tried to mimic what's done for the baseline and normal print-reports. Looks correct?

Forget my last comment about mtChunk. I think what you do is correct.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From sjohanss at openjdk.org  Tue Dec  6 15:36:08 2022
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Tue, 6 Dec 2022 15:36:08 GMT
Subject: RFR: 8157023: Integrate NMT with JFR [v2]
In-Reply-To: <YkA2oaeWt2qaz9wWpAJuMgOrnDcIdyt90g9NHqlUQys=.041ba0a3-c593-4882-8636-4ffdf3cae99c@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <7MunRi3rxCpz4mk9VmuV2MixTHklxSKjbuW5SmdiGGU=.31447ad0-1c44-4f45-891d-053bed30ddb7@github.com>
 <RZ9Im6_Tc3WfjegtsedgUixcMya7Ja53B1fOEyXhyVY=.e2422f36-5e05-43ce-8656-1730a96aedd6@github.com>
 <YkA2oaeWt2qaz9wWpAJuMgOrnDcIdyt90g9NHqlUQys=.041ba0a3-c593-4882-8636-4ffdf3cae99c@github.com>
Message-ID: <d9N8GIiys3eVxBvOBxOZBwfgj2Sx1aOSoWGzDG8fz9U=.e92952b8-0e7a-45b5-ba8e-4c33d2f38aaf@github.com>

On Tue, 6 Dec 2022 15:12:54 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > Another thing @tstuefe, have you double checked my accounting around `mtChunk`? I tried to mimic what's done for the baseline and normal print-reports. Looks correct?
> 
> Forget my last comment about mtChunk. I think what you do is correct.

Thanks for double checking it and for the explanation in the other PR.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From dnsimon at openjdk.org  Tue Dec  6 15:46:47 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 6 Dec 2022 15:46:47 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v5]
In-Reply-To: <-vjDxNaafm1m5UERR31dFXH7jdljWTKzsDjntS8v6zs=.4c777f1e-695f-42de-a4b5-0cb0f332243c@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
 <kU-NHwhiGEJLa7-o38UCemcxhU8WR_ijQBMGOAknOTs=.57d0341c-30af-4c39-ab42-4278fdfb2e5d@github.com>
 <-vjDxNaafm1m5UERR31dFXH7jdljWTKzsDjntS8v6zs=.4c777f1e-695f-42de-a4b5-0cb0f332243c@github.com>
Message-ID: <ZSSq3Pl4Nu-BlC_ccliJcYZ9j297sAFUoybpgBrw0Uo=.5aeec02c-d235-4e07-bb23-bc038d512221@github.com>

On Tue, 6 Dec 2022 13:02:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Doug Simon has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - incorporate review feedback [skip ci]
>>  - removed hard-coded module name [skip ci]
>
> src/java.base/share/classes/jdk/internal/vm/TranslatedException.java line 44:
> 
>> 42:  */
>> 43: @SuppressWarnings("serial")
>> 44: final class TranslatedException extends Exception {
> 
> Would it be possible to re-format this to avoid the wildly long (150+) lines? This seems to be moving jdk.vm.ci.hotspot.TranslatedException and hard to see what is going on.

Is there some tool support for formatting Java source code to meet OpenJDK coding guidelines? Rather unfortunate that one has to do this manually and reviewers have to spend time manually checking it.

> src/java.base/share/classes/jdk/internal/vm/VMSupport.java line 66:
> 
>> 64:      *               only contains String keys and values.
>> 65:      */
>> 66:     private static byte[] serializePropertiesToByteArray(Properties p, boolean filter) throws IOException {
> 
> I think we need more context as to why there are non-String system properties in use here.

This parameter exists to allow a caller to pass in a `Properties` object that is guaranteed to have only String keys and so does not need the extra filtering done in this method. I'll refactor the code to make it clearer.

> src/java.base/share/classes/jdk/internal/vm/VMSupport.java line 106:
> 
>> 104:         }
>> 105:         if (props.get("oome") != null) {
>> 106:             throw new OutOfMemoryError("forced OOME");
> 
> I don't think code in java.base should be checking for a property named "oome".  Is this for a test that sets this system property on the command line?

Sorry, that's debug code that I will remove.

-------------

PR: https://git.openjdk.org/jdk/pull/11513

From mcimadamore at openjdk.org  Tue Dec  6 15:47:11 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 6 Dec 2022 15:47:11 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v37]
In-Reply-To: <gqONKOkeEWYFbAbSNukCiJHu4kEF4UYYyvlyvY_Ijrw=.4ed88dde-08ef-4c4f-b39c-50cbce2bb575@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
 <gqONKOkeEWYFbAbSNukCiJHu4kEF4UYYyvlyvY_Ijrw=.4ed88dde-08ef-4c4f-b39c-50cbce2bb575@github.com>
Message-ID: <zQWHj3qsDpB_8k0Myg0DiKy79YEXjeqkEqfr6_aqYOQ=.f6eb337e-d84b-44ed-9c33-5650da147602@github.com>

On Mon, 5 Dec 2022 12:31:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> JEP 429 implementation.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10952

From dnsimon at openjdk.org  Tue Dec  6 16:06:34 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 6 Dec 2022 16:06:34 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v6]
In-Reply-To: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
Message-ID: <7f0PjG00BGhLCA3Kjlohhp3YGB_Xv8BPexToz66PxWc=.cb042f58-79b2-4c80-a5d4-245e95227858@github.com>

> Libgraal is compiled ahead of time and should not need any JVMCI Java code to be dynamically loaded at runtime. Prior to this PR, this is not the case due to:
> 
> * Code to copy system properties from the HotSpot heap into the libgraal heap. This is in `jdk.vm.ci.services.Services.initializeSavedProperties(byte[])` and `jdk.vm.ci.services.Services.serializeSavedProperties()`. This code should be moved to `java.base/jdk.internal.vm.VMSupport`.
> * Code to translate exceptions from the HotSpot heap into the libgraal heap and vice versa. This code should be moved from `jdk.internal.vm.ci//jdk.vm.ci.hotspot.TranslatedException` to `java.base/jdk.internal.vm.VMSupport`.
> 
> This PR makes the above changes. As a result, it's possible to build a JDK image that includes (and uses) libgraal but does not include `jdk.internal.vm.ci` or `jdk.internal.vm.compiler`. This both reduces footprint and better isolates the JAVMCI and the Graal compiler as accessing these components from Java code is now impossible.

Doug Simon has updated the pull request incrementally with four additional commits since the last revision:

 - formatting to avoid very long lines [skip ci]
 - removed debug code [skip ci]
 - clarify Properties filtering [skip ci]
 - remove debug code [skip ci]

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11513/files
  - new: https://git.openjdk.org/jdk/pull/11513/files/342d5e3c..bdbe7cf2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11513&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11513&range=04-05

  Stats: 66 lines in 2 files changed: 23 ins; 14 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/11513.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11513/head:pull/11513

PR: https://git.openjdk.org/jdk/pull/11513

From cstein at openjdk.org  Tue Dec  6 16:18:39 2022
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 6 Dec 2022 16:18:39 GMT
Subject: RFR: 8298178: Update to use jtreg 7.1.1
Message-ID: <OSZiA8tGDZf_iCQu3jdEoMPqT81lAdrxtXGCJbqaO6c=.174ef6d0-7584-4712-9ff1-235e3fcd72d3@github.com>

Please review the change to update to using jtreg 7.1.1.

The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.

This pull request was created by copying the following and using 7.1.1 at appropriate places:
- https://github.com/openjdk/jdk/pull/11416

-------------

Commit messages:
 - 8298178: Update to use jtreg 7.1.1

Changes: https://git.openjdk.org/jdk/pull/11542/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11542&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298178
  Stats: 9 lines in 8 files changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/11542.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11542/head:pull/11542

PR: https://git.openjdk.org/jdk/pull/11542

From cstein at openjdk.org  Tue Dec  6 16:18:40 2022
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 6 Dec 2022 16:18:40 GMT
Subject: RFR: 8298178: Update to use jtreg 7.1.1
In-Reply-To: <OSZiA8tGDZf_iCQu3jdEoMPqT81lAdrxtXGCJbqaO6c=.174ef6d0-7584-4712-9ff1-235e3fcd72d3@github.com>
References: <OSZiA8tGDZf_iCQu3jdEoMPqT81lAdrxtXGCJbqaO6c=.174ef6d0-7584-4712-9ff1-235e3fcd72d3@github.com>
Message-ID: <DpjzUNDkTEhe5okO87rinHGfKI_5TdH_YcF3i0sVkq8=.bcec390d-771b-4fc4-a092-d5cf8685a542@github.com>

On Tue, 6 Dec 2022 16:07:44 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 7.1.1.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.
> 
> This pull request was created by copying the following and using 7.1.1 at appropriate places:
> - https://github.com/openjdk/jdk/pull/11416

Fails due to missing tag `jtreg-7.1.1+1` at https://github.com/openjdk/jtreg/commit/3ea7f9f8fe7389d0eadc8cd02df38431043dd6fe

-------------

PR: https://git.openjdk.org/jdk/pull/11542

From stuefe at openjdk.org  Tue Dec  6 16:28:17 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 6 Dec 2022 16:28:17 GMT
Subject: RFR: 8157023: Integrate NMT with JFR [v3]
In-Reply-To: <mWE3nfcn4JOrkDu-9bom6rB8ECVwOP9FmyEYPb3WxOM=.0479da1b-8fa8-470c-8b72-4630046c0871@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <CPYmGbn5ElMPM6ai1Cn15NoR4z4Wka-C-G09T91Tszk=.6d99c5b0-4077-4553-85f3-22f5008f66d5@github.com>
 <5nCzSDxaca_61r8x5HdtCmT0adPGE84rHcFWH1dZQd8=.f2c52ff7-13b9-43ab-9bc3-02dbb4c31a20@github.com>
 <7h_yHywAtdvulVXw1hVhqCVARaexGTar6BtTXz3KYBc=.910b12d1-c0ec-482a-b72a-09f87ec9a606@github.com>
 <ZA8ebg-GEponuE7Tx5AUo208rrri1_sMELv9lGmc7Go=.dd685d09-1a98-46d2-b847-31429491d6fa@github.com>
 <mWE3nfcn4JOrkDu-9bom6rB8ECVwOP9FmyEYPb3WxOM=.0479da1b-8fa8-470c-8b72-4630046c0871@github.com>
Message-ID: <OwlxrE9T8Hhgzg9ZL8oKlNx_2F3uP13RLlcJypzEBvU=.eee3cadc-dfe7-4ac9-ac65-b6b585a70497@github.com>

On Tue, 6 Dec 2022 15:00:01 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Good. Up to you.
>> 
>> I wish we would allow C++ namespaces, having all in something like "namespace nmt". Then it does not hurt so much if names are a bit more generic.
>
> I'll go with `MemUsage`, normally I would have spent some more time trying to come up with something better, but Thursday is getting closer :)

We always can revamp.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From sjohanss at openjdk.org  Tue Dec  6 16:42:54 2022
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Tue, 6 Dec 2022 16:42:54 GMT
Subject: RFR: 8157023: Integrate NMT with JFR [v4]
In-Reply-To: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
Message-ID: <m_u3J5WSeZE3d7VatREoc1pbTkG4txNAmfZcRz1eTpc=.341a61ef-0381-40fe-b195-955c163949c8@github.com>

> Please review this enhancement to include NMT information in JFR recordings.
> 
> **Summary**
> Native Memory Tracking summary information can be obtained from a running VM using `jcmd` if started with `-XX:NativeMemoryTracking=summary/detail`. Using `jcmd` requires you to run a separate process and to parse the output to get the needed information. This change adds JFR events for NMT information to enable additional ways to consume the NMT data.
> 
> There are two new events added:
> * _NativeMemoryUsage_ - The total native memory usage.
> * _NativeMemoryUsagePart_ - The native memory usage for each component.
> 
> These events are sent periodically and by default the interval is 1s. This can of course be discussed, but that is the staring point. When NMT is not enabled on events will be sent.
> 
> **Testing**
> * Added a simple test to verify that the events are sent as expected depending on if NMT is enabled or not.
> * Mach5 sanity testing

Stefan Johansson has updated the pull request incrementally with three additional commits since the last revision:

 - Rename the files
 - Renaming and updating comments
 - tstuefe review - no rename

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11449/files
  - new: https://git.openjdk.org/jdk/pull/11449/files/04017864..0b3668bf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11449&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11449&range=02-03

  Stats: 438 lines in 8 files changed: 211 ins; 198 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/11449.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11449/head:pull/11449

PR: https://git.openjdk.org/jdk/pull/11449

From sjohanss at openjdk.org  Tue Dec  6 16:42:56 2022
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Tue, 6 Dec 2022 16:42:56 GMT
Subject: RFR: 8157023: Integrate NMT with JFR [v3]
In-Reply-To: <CPYmGbn5ElMPM6ai1Cn15NoR4z4Wka-C-G09T91Tszk=.6d99c5b0-4077-4553-85f3-22f5008f66d5@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <CPYmGbn5ElMPM6ai1Cn15NoR4z4Wka-C-G09T91Tszk=.6d99c5b0-4077-4553-85f3-22f5008f66d5@github.com>
Message-ID: <ICxjcH0ceDoWOSWuk8vCcCdhsK_Vil9jzJnT1H2ZYwA=.7da1067a-3e5f-49c4-a767-2bccda6581bb@github.com>

On Tue, 6 Dec 2022 11:54:37 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Please review this enhancement to include NMT information in JFR recordings.
>> 
>> **Summary**
>> Native Memory Tracking summary information can be obtained from a running VM using `jcmd` if started with `-XX:NativeMemoryTracking=summary/detail`. Using `jcmd` requires you to run a separate process and to parse the output to get the needed information. This change adds JFR events for NMT information to enable additional ways to consume the NMT data.
>> 
>> There are two new events added:
>> * _NativeMemoryUsage_ - The total native memory usage.
>> * _NativeMemoryUsagePart_ - The native memory usage for each component.
>> 
>> These events are sent periodically and by default the interval is 1s. This can of course be discussed, but that is the staring point. When NMT is not enabled on events will be sent.
>> 
>> **Testing**
>> * Added a simple test to verify that the events are sent as expected depending on if NMT is enabled or not.
>> * Mach5 sanity testing
>
> Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Special snapshot for NMT events in JFR

I hope all comments have been addressed now. I went with `NMTUsage` after all, turns out there was already a `MemoryUsage` class in the same folder.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From dnsimon at openjdk.org  Tue Dec  6 16:53:21 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 6 Dec 2022 16:53:21 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v5]
In-Reply-To: <ZSSq3Pl4Nu-BlC_ccliJcYZ9j297sAFUoybpgBrw0Uo=.5aeec02c-d235-4e07-bb23-bc038d512221@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
 <kU-NHwhiGEJLa7-o38UCemcxhU8WR_ijQBMGOAknOTs=.57d0341c-30af-4c39-ab42-4278fdfb2e5d@github.com>
 <-vjDxNaafm1m5UERR31dFXH7jdljWTKzsDjntS8v6zs=.4c777f1e-695f-42de-a4b5-0cb0f332243c@github.com>
 <ZSSq3Pl4Nu-BlC_ccliJcYZ9j297sAFUoybpgBrw0Uo=.5aeec02c-d235-4e07-bb23-bc038d512221@github.com>
Message-ID: <YYb6ipJjooXfXoFyWhz_Sus76yoDgkB5OIKvFTsYsWA=.c1a15d4f-c6b1-4610-b110-dbab35b14667@github.com>

On Tue, 6 Dec 2022 15:41:20 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/vm/VMSupport.java line 66:
>> 
>>> 64:      *               only contains String keys and values.
>>> 65:      */
>>> 66:     private static byte[] serializePropertiesToByteArray(Properties p, boolean filter) throws IOException {
>> 
>> I think we need more context as to why there are non-String system properties in use here.
>
> This parameter exists to allow a caller to pass in a `Properties` object that is guaranteed to have only String keys and so does not need the extra filtering done in this method. I'll refactor the code to make it clearer.

Hopefully this makes it clearer: https://github.com/openjdk/jdk/pull/11513/commits/5c610798fe4eaed7efeb2eebcf1e5db47714caee

-------------

PR: https://git.openjdk.org/jdk/pull/11513

From stuefe at openjdk.org  Tue Dec  6 16:57:42 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 6 Dec 2022 16:57:42 GMT
Subject: RFR: 8157023: Integrate NMT with JFR [v4]
In-Reply-To: <m_u3J5WSeZE3d7VatREoc1pbTkG4txNAmfZcRz1eTpc=.341a61ef-0381-40fe-b195-955c163949c8@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <m_u3J5WSeZE3d7VatREoc1pbTkG4txNAmfZcRz1eTpc=.341a61ef-0381-40fe-b195-955c163949c8@github.com>
Message-ID: <8bjmT6fK9Z1DYrEoomzI72NVsanm0MpepDw5bmVlAh0=.acf833a2-9b26-47a3-8805-9b2e2cbbd4ba@github.com>

On Tue, 6 Dec 2022 16:42:54 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Please review this enhancement to include NMT information in JFR recordings.
>> 
>> **Summary**
>> Native Memory Tracking summary information can be obtained from a running VM using `jcmd` if started with `-XX:NativeMemoryTracking=summary/detail`. Using `jcmd` requires you to run a separate process and to parse the output to get the needed information. This change adds JFR events for NMT information to enable additional ways to consume the NMT data.
>> 
>> There are two new events added:
>> * _NativeMemoryUsage_ - The total native memory usage.
>> * _NativeMemoryUsagePart_ - The native memory usage for each component.
>> 
>> These events are sent periodically and by default the interval is 1s. This can of course be discussed, but that is the staring point. When NMT is not enabled on events will be sent.
>> 
>> **Testing**
>> * Added a simple test to verify that the events are sent as expected depending on if NMT is enabled or not.
>> * Mach5 sanity testing
>
> Stefan Johansson has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Rename the files
>  - Renaming and updating comments
>  - tstuefe review - no rename

NMT changes look good to me. Thanks for taking my input :)

-------------

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11449

From erikj at openjdk.org  Tue Dec  6 17:24:43 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 6 Dec 2022 17:24:43 GMT
Subject: RFR: 8298178: Update to use jtreg 7.1.1
In-Reply-To: <OSZiA8tGDZf_iCQu3jdEoMPqT81lAdrxtXGCJbqaO6c=.174ef6d0-7584-4712-9ff1-235e3fcd72d3@github.com>
References: <OSZiA8tGDZf_iCQu3jdEoMPqT81lAdrxtXGCJbqaO6c=.174ef6d0-7584-4712-9ff1-235e3fcd72d3@github.com>
Message-ID: <WaxaNiKlHmIKgFGXDqswGhrbLjtfezJ0ceIFR2gCo7M=.7bb864d4-b3d4-473a-977e-83c410d9bceb@github.com>

On Tue, 6 Dec 2022 16:07:44 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 7.1.1.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.
> 
> This pull request was created by copying the following and using 7.1.1 at appropriate places:
> - https://github.com/openjdk/jdk/pull/11416

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11542

From cstein at openjdk.org  Tue Dec  6 17:31:03 2022
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 6 Dec 2022 17:31:03 GMT
Subject: RFR: 8298178: Update to use jtreg 7.1.1
In-Reply-To: <OSZiA8tGDZf_iCQu3jdEoMPqT81lAdrxtXGCJbqaO6c=.174ef6d0-7584-4712-9ff1-235e3fcd72d3@github.com>
References: <OSZiA8tGDZf_iCQu3jdEoMPqT81lAdrxtXGCJbqaO6c=.174ef6d0-7584-4712-9ff1-235e3fcd72d3@github.com>
Message-ID: <442ULv75pFX-axmZePsFEhAqdTqj0ms-Sn6WpZXB8Bw=.e6997aac-9b1f-4f81-9af0-864ba1dfd853@github.com>

On Tue, 6 Dec 2022 16:07:44 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 7.1.1.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.
> 
> This pull request was created by copying the following and using 7.1.1 at appropriate places:
> - https://github.com/openjdk/jdk/pull/11416

Tag [jtreg-7.1.1+1](https://github.com/openjdk/jtreg/releases/tag/jtreg-7.1.1+1) was just added. Is it possible to restart "pre-submit tests" without performing a "noop" (touching a file) commit?

-------------

PR: https://git.openjdk.org/jdk/pull/11542

From mdoerr at openjdk.org  Tue Dec  6 17:41:05 2022
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 6 Dec 2022 17:41:05 GMT
Subject: RFR: 8297967: Make frame::safe_for_sender safer [v4]
In-Reply-To: <e3vJR9zIIQhpNIZS6iKXDbWc_MfAuFS7qoA8te_NGKE=.564f894d-6d4f-4336-b74c-25fc3b25594c@github.com>
References: <Cctc-M2HyUqIjpcRyTjmF46wKDqvBtnnYe5Mn45sdO8=.03bdf65f-bf98-48dc-b957-0c838003d46f@github.com>
 <e3vJR9zIIQhpNIZS6iKXDbWc_MfAuFS7qoA8te_NGKE=.564f894d-6d4f-4336-b74c-25fc3b25594c@github.com>
Message-ID: <EoJxu3V3_H64TGPYtODZPBwkTNqdXmOPJ1Z9_IvOC5k=.5877b4e2-e690-44db-b575-052602862349@github.com>

On Tue, 6 Dec 2022 14:05:46 GMT, Johannes Bechberger <duke at openjdk.org> wrote:

>> Makes frame::safe_for_sender safer by using os::is_readable_pointer to check the location of the return address.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More SafeFetch

Quite a few SafeFetch checks! But it's only used for profiling purposes, so checking a bit more sounds ok to me. Let's hear what other people think.
Please update the description and the JBS issue according to your new version and describe how broken values may reach this function.

-------------

PR: https://git.openjdk.org/jdk/pull/11461

From cstein at openjdk.org  Tue Dec  6 17:45:06 2022
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 6 Dec 2022 17:45:06 GMT
Subject: RFR: 8298178: Update to use jtreg 7.1.1 [v2]
In-Reply-To: <OSZiA8tGDZf_iCQu3jdEoMPqT81lAdrxtXGCJbqaO6c=.174ef6d0-7584-4712-9ff1-235e3fcd72d3@github.com>
References: <OSZiA8tGDZf_iCQu3jdEoMPqT81lAdrxtXGCJbqaO6c=.174ef6d0-7584-4712-9ff1-235e3fcd72d3@github.com>
Message-ID: <_4nUcA_FoL0cLK-FE825zUMfVQ15bM0e0YNPmxe0reA=.799970b2-9770-4f5a-9cee-9a1197a6d431@github.com>

> Please review the change to update to using jtreg 7.1.1.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.
> 
> This pull request was created by copying the following and using 7.1.1 at appropriate places:
> - https://github.com/openjdk/jdk/pull/11416

Christian Stein has updated the pull request incrementally with two additional commits since the last revision:

 - Restart actions
 - [skip ci] Prepare restart of actions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11542/files
  - new: https://git.openjdk.org/jdk/pull/11542/files/35c49b7e..de8f785e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11542&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11542&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11542.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11542/head:pull/11542

PR: https://git.openjdk.org/jdk/pull/11542

From cstein at openjdk.org  Tue Dec  6 17:48:25 2022
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 6 Dec 2022 17:48:25 GMT
Subject: RFR: 8298178: Update to use jtreg 7.1.1 [v3]
In-Reply-To: <OSZiA8tGDZf_iCQu3jdEoMPqT81lAdrxtXGCJbqaO6c=.174ef6d0-7584-4712-9ff1-235e3fcd72d3@github.com>
References: <OSZiA8tGDZf_iCQu3jdEoMPqT81lAdrxtXGCJbqaO6c=.174ef6d0-7584-4712-9ff1-235e3fcd72d3@github.com>
Message-ID: <htSNzX0Tc8YPWY-ufy1AIfJxj_tpeGmjnang73y75Mg=.9c106ab7-1ddc-40df-8e30-b31d29c69b2c@github.com>

> Please review the change to update to using jtreg 7.1.1.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.
> 
> This pull request was created by copying the following and using 7.1.1 at appropriate places:
> - https://github.com/openjdk/jdk/pull/11416

Christian Stein has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains two commits:

 - [skip ci] Prepare restart of actions
 - 8298178: Update to use jtreg 7.1.1

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11542/files
  - new: https://git.openjdk.org/jdk/pull/11542/files/de8f785e..96fcbf96

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11542&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11542&range=01-02

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11542.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11542/head:pull/11542

PR: https://git.openjdk.org/jdk/pull/11542

From cstein at openjdk.org  Tue Dec  6 17:50:14 2022
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 6 Dec 2022 17:50:14 GMT
Subject: RFR: 8298178: Update to use jtreg 7.1.1 [v2]
In-Reply-To: <_4nUcA_FoL0cLK-FE825zUMfVQ15bM0e0YNPmxe0reA=.799970b2-9770-4f5a-9cee-9a1197a6d431@github.com>
References: <OSZiA8tGDZf_iCQu3jdEoMPqT81lAdrxtXGCJbqaO6c=.174ef6d0-7584-4712-9ff1-235e3fcd72d3@github.com>
 <_4nUcA_FoL0cLK-FE825zUMfVQ15bM0e0YNPmxe0reA=.799970b2-9770-4f5a-9cee-9a1197a6d431@github.com>
Message-ID: <sh57rFLn0TBgSOd48dEAsELiZwLskYyjHqU95JqEedA=.6de2e612-53c9-4956-855f-4b6f2d5bb235@github.com>

On Tue, 6 Dec 2022 17:45:06 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review the change to update to using jtreg 7.1.1.
>> 
>> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.
>> 
>> This pull request was created by copying the following and using 7.1.1 at appropriate places:
>> - https://github.com/openjdk/jdk/pull/11416
>
> Christian Stein has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restart actions
>  - [skip ci] Prepare restart of actions

Restarted actions are running at: https://github.com/sormuras/jdk/actions/runs/3632002366

-------------

PR: https://git.openjdk.org/jdk/pull/11542

From kvn at openjdk.org  Tue Dec  6 18:35:11 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 6 Dec 2022 18:35:11 GMT
Subject: RFR: 8292289: [vectorapi] Improve the implementation of
 VectorTestNode [v14]
In-Reply-To: <Jo8mnLoA_9Pb8TzocN6zG5s2PGGVxS53s6XP_5CasLo=.de864d1a-51b5-4ceb-b12d-1d20e34735d7@github.com>
References: <IcR6eOr6iM1b9B1I1zUQnI2J9hQAmdSRHYc9CdIGW5E=.3b8dd64d-2eff-4659-b75a-81c4b008e41a@github.com>
 <Jo8mnLoA_9Pb8TzocN6zG5s2PGGVxS53s6XP_5CasLo=.de864d1a-51b5-4ceb-b12d-1d20e34735d7@github.com>
Message-ID: <yjdwKWZjnnksDToa8VjADonYWydgQUHiKwXpyj87SXM=.b23722c8-f497-41ae-a8c2-e06d64abebbc@github.com>

On Tue, 6 Dec 2022 14:24:39 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> This patch modifies the node generation of `VectorSupport::test` to emit a `CMoveINode`, which is picked up by `BoolNode::Ideal(PhaseGVN*, bool)` to connect the `VectorTestNode` directly to the `BoolNode`, removing the redundant operations of materialising the test result in a GP register and do a `CmpI` to get back the flags. As a result, `VectorMask<T>::alltrue` is compiled into machine codes:
>> 
>>         vptest xmm0, xmm1
>>         jb if_true
>>     if_false:
>> 
>> instead of:
>> 
>>         vptest xmm0, xmm1
>>         setb r10
>>         movzbl r10
>>         testl r10
>>         jne if_true
>>     if_false:
>> 
>> The results of `jdk.incubator.vector.ArrayMismatchBenchmark` shows noticeable improvements:
>> 
>>                                                                                        Before                  After
>>     Benchmark                                      Prefix    Size   Mode  Cnt       Score      Error       Score     Error    Units  Change
>>     ArrayMismatchBenchmark.mismatchVectorByte         0.5       9  thrpt   10  217345.383 ? 8316.444  222279.381 ? 2660.983  ops/ms   +2.3%
>>     ArrayMismatchBenchmark.mismatchVectorByte         0.5     257  thrpt   10  113918.406 ? 1618.836  116268.691 ? 1291.899  ops/ms   +2.1%
>>     ArrayMismatchBenchmark.mismatchVectorByte         0.5  100000  thrpt   10     702.066 ?   72.862     797.806 ?   16.429  ops/ms  +13.6%
>>     ArrayMismatchBenchmark.mismatchVectorByte         1.0       9  thrpt   10  146096.564 ? 2401.258  145338.910 ?  687.453  ops/ms   -0.5%
>>     ArrayMismatchBenchmark.mismatchVectorByte         1.0     257  thrpt   10   60598.181 ? 1259.397   69041.519 ? 1073.156  ops/ms  +13.9%
>>     ArrayMismatchBenchmark.mismatchVectorByte         1.0  100000  thrpt   10     316.814 ?   10.975     408.770 ?    5.281  ops/ms  +29.0%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       0.5       9  thrpt   10  195674.549 ? 1200.166  188482.433 ? 1872.076  ops/ms   -3.7%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       0.5     257  thrpt   10   44357.169 ?  473.013   42293.411 ? 2838.255  ops/ms   -4.7%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       0.5  100000  thrpt   10      68.199 ?    5.410      67.628 ?    3.241  ops/ms   -0.8%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       1.0       9  thrpt   10  107722.450 ? 1677.607  111060.400 ?  982.230  ops/ms   +3.1%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       1.0     257  thrpt   10   16692.645 ? 1002.599   21440.506 ? 1618.266  ops/ms  +28.4%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       1.0  100000  thrpt   10      32.984 ?    0.548      33.202 ?    2.365  ops/ms   +0.7%
>>     ArrayMismatchBenchmark.mismatchVectorInt          0.5       9  thrpt   10  335458.217 ? 3154.842  379944.254 ? 5703.134  ops/ms  +13.3%
>>     ArrayMismatchBenchmark.mismatchVectorInt          0.5     257  thrpt   10   58505.302 ?  786.312   56721.368 ? 2497.052  ops/ms   -3.0%
>>     ArrayMismatchBenchmark.mismatchVectorInt          0.5  100000  thrpt   10     133.037 ?   11.415     139.537 ?    4.667  ops/ms   +4.9%
>>     ArrayMismatchBenchmark.mismatchVectorInt          1.0       9  thrpt   10  117943.802 ? 2281.349  112409.365 ? 2110.055  ops/ms   -4.7%
>>     ArrayMismatchBenchmark.mismatchVectorInt          1.0     257  thrpt   10   27060.015 ?  795.619   33756.613 ?  826.533  ops/ms  +24.7%
>>     ArrayMismatchBenchmark.mismatchVectorInt          1.0  100000  thrpt   10      57.558 ?    8.927      66.951 ?    4.381  ops/ms  +16.3%
>>     ArrayMismatchBenchmark.mismatchVectorLong         0.5       9  thrpt   10  182963.715 ? 1042.497  182438.405 ? 2120.832  ops/ms   -0.3%
>>     ArrayMismatchBenchmark.mismatchVectorLong         0.5     257  thrpt   10   36672.215 ?  614.821   35397.398 ? 1609.235  ops/ms   -3.5%
>>     ArrayMismatchBenchmark.mismatchVectorLong         0.5  100000  thrpt   10      66.438 ?    2.142      65.427 ?    2.270  ops/ms   -1.5%
>>     ArrayMismatchBenchmark.mismatchVectorLong         1.0       9  thrpt   10  110393.047 ?  497.853  115165.845 ? 5381.674  ops/ms   +4.3%
>>     ArrayMismatchBenchmark.mismatchVectorLong         1.0     257  thrpt   10   14720.765 ?  661.350   19871.096 ?  201.464  ops/ms  +35.0%
>>     ArrayMismatchBenchmark.mismatchVectorLong         1.0  100000  thrpt   10      30.760 ?    0.821      31.933 ?    1.352  ops/ms   +3.8%
>> 
>> I have not been able to conduct throughout testing on AVX512 and Aarch64 so any help would be invaluable. Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix test

I would need to run testing again and also do our performance testing.

-------------

PR: https://git.openjdk.org/jdk/pull/9855

From iwalulya at openjdk.org  Tue Dec  6 19:40:07 2022
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Tue, 6 Dec 2022 19:40:07 GMT
Subject: RFR: 8293824: gc/whitebox/TestConcMarkCycleWB.java failed
 "RuntimeException: assertTrue: expected true, was false" [v2]
In-Reply-To: <dM4t6tEt_ECKHylcGy7v2lL8FOXa1j336ycPFt07Jnc=.1b984fe9-d268-4384-85d9-0984fff815a6@github.com>
References: <74AnEqLugaEU80XMNm8edtWBmK8gOFMirnZT1rdj1jI=.6ab039c0-3db5-4336-9aa7-867166b79cda@github.com>
 <dM4t6tEt_ECKHylcGy7v2lL8FOXa1j336ycPFt07Jnc=.1b984fe9-d268-4384-85d9-0984fff815a6@github.com>
Message-ID: <EXP4eCMltTG3jrqBvZdydUEb3z3aOGMSt8jNkSFEfxg=.7c7c292f-3eba-4278-b278-02a9ffdd9ffa@github.com>

On Tue, 6 Dec 2022 12:34:47 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to WhiteBox and some tests involving G1 concurrent GCs.
>> 
>> Some tests currently use WhiteBox.g1StartConcMarkCycle() to trigger a
>> concurrent GC.  Many of them follow it with a loop waiting for a concurrent
>> cycle to not be in progress.  A few also preceed that call with a similar
>> loop, since that call does nothing and returns false if a concurrent cycle is
>> already in progress.  Those tests typically want to ensure there was a
>> concurrent cycle that was started after some setup.
>> 
>> The failing test calls that function, asserting that it returned true, e.g. a
>> new concurrent cycle was started.
>> 
>> There are various problems with this, due to races with concurrent cycles
>> started automatically and possibly aborted (by full GCs) concurrent cycles,
>> making some of these tests unreliable in some configurations.
>> 
>> For example, the test failure associated with this bug intermittently arises
>> when running with `-Xcomp`, triggering a concurrent cycle before the explicit
>> requests by the test, causing the explicit request to fail (because there is
>> already one in progress), failing the assert.  Waiting for there not to be an
>> in-progress cycle before the explicit request just narrows the race window.
>> 
>> We have a different mechanism for controlling concurrent cycles, the
>> concurrent GC breakpoint mechanism.  By adding a counter specifically for such
>> cycles, we can use GC breakpoints to ensure only the concurrent cycles the
>> test wants are occurring, and can verify they completed successfully.
>> 
>> So we change tests using WhiteBox.g1StartConcMarkCycle() to instead use GC
>> breakpoints, along with the new WhiteBox.g1CompletedConcurrentMarkCycles() to
>> avoid racing request problems and to detect aborted cycles.  Since it is no
>> longer used, WhiteBox.g1StartConcMarkCycle() is removed.
>> 
>> Testing:
>> mach5 tier1-6
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - use new whitebox api for running conc gc
>  - Merge branch 'master' into test-concmark
>  - copyrights
>  - remove WB.g1StartConcMarkCyle
>  - update tests
>  - add utility GC breakpoint functions
>  - add G1ConcurrentMark::completed_mark_cycles() and whitebox access

Lgtm!

Minor comments:

test/hotspot/jtreg/gc/g1/humongousObjects/objectGraphTest/GCTokens.java line 36:

> 34:     public static final String WB_INITIATED_YOUNG_GC = "Young (Normal) (WhiteBox Initiated Young GC)";
> 35:     public static final String WB_INITIATED_MIXED_GC = "Young (Mixed) (WhiteBox Initiated Young GC)";
> 36:     public static final String WB_INITIATED_CMC = "WhiteBox Initiated Run to Breakpoint";

`WB_INITIATED_CMC = "WhiteBox Initiated Run to Concurrent GC Breakpoint"; ` as we indicate below that `String CMC = "Concurrent Mark)"`

test/hotspot/jtreg/gc/stress/TestStressRSetCoarsening.java line 296:

> 294:                     // Number of references went down.
> 295:                     // Need to provoke recalculation of RSet.
> 296:                     WB.g1RunConcurrentGC(false);

probably use `WB.g1RunConcurrentGC();` overload for consistency with other calls

-------------

Marked as reviewed by iwalulya (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11435

From sjohanss at openjdk.org  Tue Dec  6 20:36:33 2022
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Tue, 6 Dec 2022 20:36:33 GMT
Subject: RFR: 8157023: Integrate NMT with JFR [v2]
In-Reply-To: <YkA2oaeWt2qaz9wWpAJuMgOrnDcIdyt90g9NHqlUQys=.041ba0a3-c593-4882-8636-4ffdf3cae99c@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <7MunRi3rxCpz4mk9VmuV2MixTHklxSKjbuW5SmdiGGU=.31447ad0-1c44-4f45-891d-053bed30ddb7@github.com>
 <RZ9Im6_Tc3WfjegtsedgUixcMya7Ja53B1fOEyXhyVY=.e2422f36-5e05-43ce-8656-1730a96aedd6@github.com>
 <YkA2oaeWt2qaz9wWpAJuMgOrnDcIdyt90g9NHqlUQys=.041ba0a3-c593-4882-8636-4ffdf3cae99c@github.com>
Message-ID: <MOrjB84NhmBsQLBTng7v8WNZQ8ajqWWDPUPOzLPXEdk=.7a4f571f-75cc-4c75-af35-2d3c99e857d7@github.com>

On Tue, 6 Dec 2022 15:12:54 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Looks good. Small simplification, instead of "_has_xxx" boolean flags, just use your MemSnapshotOptions as member.
>
>> Another thing @tstuefe, have you double checked my accounting around `mtChunk`? I tried to mimic what's done for the baseline and normal print-reports. Looks correct?
> 
> Forget my last comment about mtChunk. I think what you do is correct.

Thanks @tstuefe, will try to get a JFR reviewer on board as well and get this in before the fork.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From egahlin at openjdk.org  Tue Dec  6 20:38:13 2022
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 6 Dec 2022 20:38:13 GMT
Subject: RFR: 8298175: JFR: Common timestamp for periodic events
Message-ID: <4bP-aYZidz-BbflACIv0qfc_8dpSNF6INArPJJ9wJQo=.a57084a7-d403-4975-a524-f33a2f0cf1fa@github.com>

Could I have review of infrastructure that makes it easier to write periodic events with the same timestamp.

Testing: jdk/jdk/jfr + tier1 + tier2

Thanks
Erik

-------------

Commit messages:
 - Fixes
 - Fixes
 - Initial

Changes: https://git.openjdk.org/jdk/pull/11541/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11541&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298175
  Stats: 24 lines in 5 files changed: 12 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/11541.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11541/head:pull/11541

PR: https://git.openjdk.org/jdk/pull/11541

From cstein at openjdk.org  Tue Dec  6 20:54:52 2022
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 6 Dec 2022 20:54:52 GMT
Subject: Integrated: 8298178: Update to use jtreg 7.1.1
In-Reply-To: <OSZiA8tGDZf_iCQu3jdEoMPqT81lAdrxtXGCJbqaO6c=.174ef6d0-7584-4712-9ff1-235e3fcd72d3@github.com>
References: <OSZiA8tGDZf_iCQu3jdEoMPqT81lAdrxtXGCJbqaO6c=.174ef6d0-7584-4712-9ff1-235e3fcd72d3@github.com>
Message-ID: <bZ95FikXXwOfFnn7nor8EnwNTmcPK1yc6djOUS8PmQc=.2f8fb567-dde6-474a-b583-8f201a8bc65e@github.com>

On Tue, 6 Dec 2022 16:07:44 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 7.1.1.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.
> 
> This pull request was created by copying the following and using 7.1.1 at appropriate places:
> - https://github.com/openjdk/jdk/pull/11416

This pull request has now been integrated.

Changeset: 2cdc0195
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2cdc0195655317cb0b04f76fd8dce5e40bf52774
Stats:     9 lines in 8 files changed: 0 ins; 0 del; 9 mod

8298178: Update to use jtreg 7.1.1

Reviewed-by: erikj

-------------

PR: https://git.openjdk.org/jdk/pull/11542

From aph at openjdk.org  Tue Dec  6 21:14:07 2022
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 6 Dec 2022 21:14:07 GMT
Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator) [v38]
In-Reply-To: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
Message-ID: <YtZE5ynehR7OS2NxVjxuouIiIO4JwvEdzNiDQn-04NE=.5dd48b0f-5473-4ce3-a2cf-006ad428d997@github.com>

> JEP 429 implementation.

Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 71 commits:

 - Merge from JDK mainline
 - Add comment
 - Merge https://github.com/openjdk/jdk into JDK-8286666
 - Feedback from reviewers
 - Feedback from reviewers
 - Unused variable
 - Cleanup
 - Cleanup
 - Merge branch 'JDK-8286666' of https://github.com/theRealAph/jdk into JDK-8286666
 - Update src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java
   
   Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>
 - ... and 61 more: https://git.openjdk.org/jdk/compare/2cdc0195...46fa1389

-------------

Changes: https://git.openjdk.org/jdk/pull/10952/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=37
  Stats: 3336 lines in 62 files changed: 2913 ins; 254 del; 169 mod
  Patch: https://git.openjdk.org/jdk/pull/10952.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10952/head:pull/10952

PR: https://git.openjdk.org/jdk/pull/10952

From dholmes at openjdk.org  Tue Dec  6 22:40:08 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 6 Dec 2022 22:40:08 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data
In-Reply-To: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
Message-ID: <eXBjf5CE6SDQu5dZdVwSNDzeKTQpMnE267ugZDFBBcE=.235fce2e-7195-499d-89c5-37b504145968@github.com>

On Tue, 6 Dec 2022 06:13:23 GMT, Justin King <jcking at openjdk.org> wrote:

> Resolve memory leak related to `MethodData::_extra_data_lock` in `Method::build_profiling_method_data` by defining `MethodData::release_C_heap_structures` and calling it where appropriate before deallocating `MethodData`.

I'm struggling to see how [JDK-8297389](https://bugs.openjdk.org/browse/JDK-8297389) affected this. ??

-------------

PR: https://git.openjdk.org/jdk/pull/11526

From dholmes at openjdk.org  Wed Dec  7 00:46:12 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 7 Dec 2022 00:46:12 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data
In-Reply-To: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
Message-ID: <_ZlxgEIa-gRzcquPC-HwywlMUUD-87RuAAcNZybipXc=.cd2db8ec-0e2d-4a39-ba8b-f974ccda0d3a@github.com>

On Tue, 6 Dec 2022 06:13:23 GMT, Justin King <jcking at openjdk.org> wrote:

> Resolve memory leak related to `MethodData::_extra_data_lock` in `Method::build_profiling_method_data` by defining `MethodData::release_C_heap_structures` and calling it where appropriate before deallocating `MethodData`.

Also see:

https://mail.openjdk.org/pipermail/hotspot-dev/2019-October/039783.html

The use of the Mutex* causes a performance issue.

-------------

PR: https://git.openjdk.org/jdk/pull/11526

From dholmes at openjdk.org  Wed Dec  7 00:50:45 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 7 Dec 2022 00:50:45 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data
In-Reply-To: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
Message-ID: <dO-CUzXO_ArX9yagkWkpFM7cKRZILWV8qi8rCQtZqw0=.4ff57481-c2ed-4f7e-a8b9-42f1410791f2@github.com>

On Tue, 6 Dec 2022 06:13:23 GMT, Justin King <jcking at openjdk.org> wrote:

> Resolve memory leak related to `MethodData::_extra_data_lock` in `Method::build_profiling_method_data` by defining `MethodData::release_C_heap_structures` and calling it where appropriate before deallocating `MethodData`.

Reading:

https://mail.openjdk.org/pipermail/hotspot-dev/2019-October/039783.html

also refreshed me on the whole delete vs destructor issue.

-------------

PR: https://git.openjdk.org/jdk/pull/11526

From kvn at openjdk.org  Wed Dec  7 01:49:08 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 7 Dec 2022 01:49:08 GMT
Subject: RFR: 8292289: [vectorapi] Improve the implementation of
 VectorTestNode [v14]
In-Reply-To: <Jo8mnLoA_9Pb8TzocN6zG5s2PGGVxS53s6XP_5CasLo=.de864d1a-51b5-4ceb-b12d-1d20e34735d7@github.com>
References: <IcR6eOr6iM1b9B1I1zUQnI2J9hQAmdSRHYc9CdIGW5E=.3b8dd64d-2eff-4659-b75a-81c4b008e41a@github.com>
 <Jo8mnLoA_9Pb8TzocN6zG5s2PGGVxS53s6XP_5CasLo=.de864d1a-51b5-4ceb-b12d-1d20e34735d7@github.com>
Message-ID: <6ZglmG06MHiOYd8prubF1p0U6epmNbaCO8d9f__10Nc=.c2abf2f9-4155-46a8-85b2-2a1e79deeb67@github.com>

On Tue, 6 Dec 2022 14:24:39 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> This patch modifies the node generation of `VectorSupport::test` to emit a `CMoveINode`, which is picked up by `BoolNode::Ideal(PhaseGVN*, bool)` to connect the `VectorTestNode` directly to the `BoolNode`, removing the redundant operations of materialising the test result in a GP register and do a `CmpI` to get back the flags. As a result, `VectorMask<T>::alltrue` is compiled into machine codes:
>> 
>>         vptest xmm0, xmm1
>>         jb if_true
>>     if_false:
>> 
>> instead of:
>> 
>>         vptest xmm0, xmm1
>>         setb r10
>>         movzbl r10
>>         testl r10
>>         jne if_true
>>     if_false:
>> 
>> The results of `jdk.incubator.vector.ArrayMismatchBenchmark` shows noticeable improvements:
>> 
>>                                                                                        Before                  After
>>     Benchmark                                      Prefix    Size   Mode  Cnt       Score      Error       Score     Error    Units  Change
>>     ArrayMismatchBenchmark.mismatchVectorByte         0.5       9  thrpt   10  217345.383 ? 8316.444  222279.381 ? 2660.983  ops/ms   +2.3%
>>     ArrayMismatchBenchmark.mismatchVectorByte         0.5     257  thrpt   10  113918.406 ? 1618.836  116268.691 ? 1291.899  ops/ms   +2.1%
>>     ArrayMismatchBenchmark.mismatchVectorByte         0.5  100000  thrpt   10     702.066 ?   72.862     797.806 ?   16.429  ops/ms  +13.6%
>>     ArrayMismatchBenchmark.mismatchVectorByte         1.0       9  thrpt   10  146096.564 ? 2401.258  145338.910 ?  687.453  ops/ms   -0.5%
>>     ArrayMismatchBenchmark.mismatchVectorByte         1.0     257  thrpt   10   60598.181 ? 1259.397   69041.519 ? 1073.156  ops/ms  +13.9%
>>     ArrayMismatchBenchmark.mismatchVectorByte         1.0  100000  thrpt   10     316.814 ?   10.975     408.770 ?    5.281  ops/ms  +29.0%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       0.5       9  thrpt   10  195674.549 ? 1200.166  188482.433 ? 1872.076  ops/ms   -3.7%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       0.5     257  thrpt   10   44357.169 ?  473.013   42293.411 ? 2838.255  ops/ms   -4.7%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       0.5  100000  thrpt   10      68.199 ?    5.410      67.628 ?    3.241  ops/ms   -0.8%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       1.0       9  thrpt   10  107722.450 ? 1677.607  111060.400 ?  982.230  ops/ms   +3.1%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       1.0     257  thrpt   10   16692.645 ? 1002.599   21440.506 ? 1618.266  ops/ms  +28.4%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       1.0  100000  thrpt   10      32.984 ?    0.548      33.202 ?    2.365  ops/ms   +0.7%
>>     ArrayMismatchBenchmark.mismatchVectorInt          0.5       9  thrpt   10  335458.217 ? 3154.842  379944.254 ? 5703.134  ops/ms  +13.3%
>>     ArrayMismatchBenchmark.mismatchVectorInt          0.5     257  thrpt   10   58505.302 ?  786.312   56721.368 ? 2497.052  ops/ms   -3.0%
>>     ArrayMismatchBenchmark.mismatchVectorInt          0.5  100000  thrpt   10     133.037 ?   11.415     139.537 ?    4.667  ops/ms   +4.9%
>>     ArrayMismatchBenchmark.mismatchVectorInt          1.0       9  thrpt   10  117943.802 ? 2281.349  112409.365 ? 2110.055  ops/ms   -4.7%
>>     ArrayMismatchBenchmark.mismatchVectorInt          1.0     257  thrpt   10   27060.015 ?  795.619   33756.613 ?  826.533  ops/ms  +24.7%
>>     ArrayMismatchBenchmark.mismatchVectorInt          1.0  100000  thrpt   10      57.558 ?    8.927      66.951 ?    4.381  ops/ms  +16.3%
>>     ArrayMismatchBenchmark.mismatchVectorLong         0.5       9  thrpt   10  182963.715 ? 1042.497  182438.405 ? 2120.832  ops/ms   -0.3%
>>     ArrayMismatchBenchmark.mismatchVectorLong         0.5     257  thrpt   10   36672.215 ?  614.821   35397.398 ? 1609.235  ops/ms   -3.5%
>>     ArrayMismatchBenchmark.mismatchVectorLong         0.5  100000  thrpt   10      66.438 ?    2.142      65.427 ?    2.270  ops/ms   -1.5%
>>     ArrayMismatchBenchmark.mismatchVectorLong         1.0       9  thrpt   10  110393.047 ?  497.853  115165.845 ? 5381.674  ops/ms   +4.3%
>>     ArrayMismatchBenchmark.mismatchVectorLong         1.0     257  thrpt   10   14720.765 ?  661.350   19871.096 ?  201.464  ops/ms  +35.0%
>>     ArrayMismatchBenchmark.mismatchVectorLong         1.0  100000  thrpt   10      30.760 ?    0.821      31.933 ?    1.352  ops/ms   +3.8%
>> 
>> I have not been able to conduct throughout testing on AVX512 and Aarch64 so any help would be invaluable. Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix test

Regular testing passed. I am waiting performance results.

-------------

PR: https://git.openjdk.org/jdk/pull/9855

From coleenp at openjdk.org  Wed Dec  7 02:25:15 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 7 Dec 2022 02:25:15 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data
In-Reply-To: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
Message-ID: <xFJ_0pjT4VvLoDOhlHqRtQ8t-s1giN_Bi_TwkqRlbxY=.64254017-1d4b-47e0-88a6-c1db75026bed@github.com>

On Tue, 6 Dec 2022 06:13:23 GMT, Justin King <jcking at openjdk.org> wrote:

> Resolve memory leak related to `MethodData::_extra_data_lock` in `Method::build_profiling_method_data` by defining `MethodData::release_C_heap_structures` and calling it where appropriate before deallocating `MethodData`.

src/hotspot/share/oops/methodData.cpp line 1826:

> 1824: 
> 1825: void MethodData::deallocate_contents(ClassLoaderData* loader_data) {
> 1826:   assert(_extra_data_lock == NULL, "memory leak");

I don't know why you didn't make deallocate_contents call release_C_heap_structures, like the other metadata deallocate_contents functions do?

-------------

PR: https://git.openjdk.org/jdk/pull/11526

From coleenp at openjdk.org  Wed Dec  7 02:58:05 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 7 Dec 2022 02:58:05 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data
In-Reply-To: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
Message-ID: <DSjN-1_cuY3_HEZhwRGWNL-seBWTKvWmCPz6tMeiHQQ=.0c2ddb10-6325-4d3e-8cc7-ff989f8b51c0@github.com>

On Tue, 6 Dec 2022 06:13:23 GMT, Justin King <jcking at openjdk.org> wrote:

> Resolve memory leak related to `MethodData::_extra_data_lock` in `Method::build_profiling_method_data` by defining `MethodData::release_C_heap_structures` and calling it where appropriate before deallocating `MethodData`.

This looks correct.

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11526

From coleenp at openjdk.org  Wed Dec  7 02:58:07 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 7 Dec 2022 02:58:07 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data
In-Reply-To: <xFJ_0pjT4VvLoDOhlHqRtQ8t-s1giN_Bi_TwkqRlbxY=.64254017-1d4b-47e0-88a6-c1db75026bed@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
 <xFJ_0pjT4VvLoDOhlHqRtQ8t-s1giN_Bi_TwkqRlbxY=.64254017-1d4b-47e0-88a6-c1db75026bed@github.com>
Message-ID: <AC69gwBn7MWbULysNAMKGX1UK0iblCVyAnf7lKay1Z4=.1dbf2387-be9c-4dd0-8074-3a269e7c66c1@github.com>

On Wed, 7 Dec 2022 02:22:30 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Resolve memory leak related to `MethodData::_extra_data_lock` in `Method::build_profiling_method_data` by defining `MethodData::release_C_heap_structures` and calling it where appropriate before deallocating `MethodData`.
>
> src/hotspot/share/oops/methodData.cpp line 1826:
> 
>> 1824: 
>> 1825: void MethodData::deallocate_contents(ClassLoaderData* loader_data) {
>> 1826:   assert(_extra_data_lock == NULL, "memory leak");
> 
> I don't know why you didn't make deallocate_contents call release_C_heap_structures, like the other metadata deallocate_contents functions do?

I see why.  InstanceKlass release_C_heap_structures is called for class unloading so frees everything in its tree, and deallocate_contents does the same thing except for the constant pool, because the ConstantPool deallocate_contents calls its own release_C_heap_structures.  Methods are attached to InstanceKlass so let InstanceKlass call release_C_heap_structures for them, except for this case that was added for MethodData here.

-------------

PR: https://git.openjdk.org/jdk/pull/11526

From dholmes at openjdk.org  Wed Dec  7 04:36:01 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 7 Dec 2022 04:36:01 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v4]
In-Reply-To: <sJOLTlt6mjfVSLsXdLQMgirI06mdYjGW0tuO2Ueht8s=.e3d8eb38-c4a6-4e43-9e01-3b9ecb385b41@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
 <nm5MBsIexi02WmVomf-rKb-xWg064Pqg9WMKxb18PBw=.9d5209a3-675e-4ee2-a4d5-05ff14934fb3@github.com>
 <l12fdSbAv-DiEfAt29C4mOXFRoNaWjTVuW3_aSElIiI=.f8ec8d7e-84ec-4551-a9f3-e9aa116bb84e@github.com>
 <sJOLTlt6mjfVSLsXdLQMgirI06mdYjGW0tuO2Ueht8s=.e3d8eb38-c4a6-4e43-9e01-3b9ecb385b41@github.com>
Message-ID: <kydwXWlhR6pT95VvYlGgd3Hk0JIRxJxUFsO2gOceiLY=.b65421ab-8965-422f-b55c-9a1bb1f26b73@github.com>

On Tue, 6 Dec 2022 08:56:47 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> src/hotspot/share/jvmci/jvmci.cpp line 234:
>> 
>>> 232:     if (thread != nullptr && thread->is_Java_thread()) {
>>> 233:       ResourceMark rm;
>>> 234:       JavaThreadState state = ((JavaThread*) thread)->thread_state();
>> 
>> Please use `JavaThread::cast(thread)`
>
> I've made this change. Out of interest, I grep'ed through `src/hotspot` and found a few other instances of `(JavaThread*)` style casts. While most of these are probably older code, I'm wondering what the guidelines are in this area. I assume `JavaThread::cast` should be preferred always given the assertion checking it does?

Yes `JavaThread::cast(t)` is preferred. We did a lot of cleanup work ensuring we use `JavaThread` when always dealing with a `JavaThread`, and so reduce the places we need to cast. I'm a little surprised we still have some raw casts left as I thought we had cleaned them all up. I will check and file another cleanup RFE. Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/11513

From dholmes at openjdk.org  Wed Dec  7 05:25:11 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 7 Dec 2022 05:25:11 GMT
Subject: RFR: 8298175: JFR: Common timestamp for periodic events
In-Reply-To: <4bP-aYZidz-BbflACIv0qfc_8dpSNF6INArPJJ9wJQo=.a57084a7-d403-4975-a524-f33a2f0cf1fa@github.com>
References: <4bP-aYZidz-BbflACIv0qfc_8dpSNF6INArPJJ9wJQo=.a57084a7-d403-4975-a524-f33a2f0cf1fa@github.com>
Message-ID: <AID97DSpWwE4w5ALhZ3z3-zmsY54p0CHvA-d0Zba2xY=.58e941b9-c9be-4fba-b233-f1cbcd5d46e8@github.com>

On Tue, 6 Dec 2022 15:31:22 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of infrastructure that makes it easier to write periodic events with the same timestamp.
> 
> Testing: jdk/jdk/jfr + tier1 + tier2
> 
> Thanks
> Erik

This seems okay. A couple of comments below.

Thanks.

src/jdk.jfr/share/classes/jdk/jfr/internal/RequestEngine.java line 211:

> 209:         long last = lastTimeMillis;
> 210:         // Bug 9000556 - current time millis has rather lame resolution
> 211:         // The use of os::elapsed_counter() is deliberate here, we don't

While you are here can you delete this comment block, or suitably modify it so that it makes sense for the code that follows. Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/11541

From dholmes at openjdk.org  Wed Dec  7 05:25:12 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 7 Dec 2022 05:25:12 GMT
Subject: RFR: 8298175: JFR: Common timestamp for periodic events
In-Reply-To: <AID97DSpWwE4w5ALhZ3z3-zmsY54p0CHvA-d0Zba2xY=.58e941b9-c9be-4fba-b233-f1cbcd5d46e8@github.com>
References: <4bP-aYZidz-BbflACIv0qfc_8dpSNF6INArPJJ9wJQo=.a57084a7-d403-4975-a524-f33a2f0cf1fa@github.com>
 <AID97DSpWwE4w5ALhZ3z3-zmsY54p0CHvA-d0Zba2xY=.58e941b9-c9be-4fba-b233-f1cbcd5d46e8@github.com>
Message-ID: <PrzX2Q5ymD2JHxKzyz5MUk3-M0snx6NyYbQCoso3YPA=.7f3797ec-b975-44d1-b2ad-fa93509614ec@github.com>

On Wed, 7 Dec 2022 05:15:54 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Could I have review of infrastructure that makes it easier to write periodic events with the same timestamp.
>> 
>> Testing: jdk/jdk/jfr + tier1 + tier2
>> 
>> Thanks
>> Erik
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/RequestEngine.java line 211:
> 
>> 209:         long last = lastTimeMillis;
>> 210:         // Bug 9000556 - current time millis has rather lame resolution
>> 211:         // The use of os::elapsed_counter() is deliberate here, we don't
> 
> While you are here can you delete this comment block, or suitably modify it so that it makes sense for the code that follows. Thanks.

Actually what is all this `lastTimeMillis` code for? And how does it relate to the passed in timestamp?

-------------

PR: https://git.openjdk.org/jdk/pull/11541

From egahlin at openjdk.org  Wed Dec  7 05:49:03 2022
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 7 Dec 2022 05:49:03 GMT
Subject: RFR: 8298175: JFR: Common timestamp for periodic events
In-Reply-To: <PrzX2Q5ymD2JHxKzyz5MUk3-M0snx6NyYbQCoso3YPA=.7f3797ec-b975-44d1-b2ad-fa93509614ec@github.com>
References: <4bP-aYZidz-BbflACIv0qfc_8dpSNF6INArPJJ9wJQo=.a57084a7-d403-4975-a524-f33a2f0cf1fa@github.com>
 <AID97DSpWwE4w5ALhZ3z3-zmsY54p0CHvA-d0Zba2xY=.58e941b9-c9be-4fba-b233-f1cbcd5d46e8@github.com>
 <PrzX2Q5ymD2JHxKzyz5MUk3-M0snx6NyYbQCoso3YPA=.7f3797ec-b975-44d1-b2ad-fa93509614ec@github.com>
Message-ID: <JPBF8_Y4VzqPMWuNxYSpODkefMlD-kK_PWAQiTZ2c1I=.a097d726-5d6c-45e4-a24a-cda55b26b643@github.com>

On Wed, 7 Dec 2022 05:19:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/jdk.jfr/share/classes/jdk/jfr/internal/RequestEngine.java line 211:
>> 
>>> 209:         long last = lastTimeMillis;
>>> 210:         // Bug 9000556 - current time millis has rather lame resolution
>>> 211:         // The use of os::elapsed_counter() is deliberate here, we don't
>> 
>> While you are here can you delete this comment block, or suitably modify it so that it makes sense for the code that follows. Thanks.
>
> Actually what is all this `lastTimeMillis` code for? And how does it relate to the passed in timestamp?

In Oracle JDK 8, the loop for emitting periodic events was written in native. With the rewrite that happened in JDK 9, the native logic was moved to Java, but to ensure that the mechanism worked the same, the implementation was largely kept as is. Therefore the name run_requests(...). 

The timestamps in that method, for example lastTimeMillis, make sure events are emitted at the correct time, for example, one event could have the period 5s and the other 7s.

The timestamp I added is a timestamp that could be used when committing the event in native, for example:

     EventJVMInformation event(UNTIMED);
     event.set_jvmName(VM_Version::vm_name());
     event.set_endtime(timestamp());
     event.commit();

I can see if I can make the comment and naming of the variable more clear.

-------------

PR: https://git.openjdk.org/jdk/pull/11541

From never at openjdk.org  Wed Dec  7 06:09:57 2022
From: never at openjdk.org (Tom Rodriguez)
Date: Wed, 7 Dec 2022 06:09:57 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v6]
In-Reply-To: <7f0PjG00BGhLCA3Kjlohhp3YGB_Xv8BPexToz66PxWc=.cb042f58-79b2-4c80-a5d4-245e95227858@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
 <7f0PjG00BGhLCA3Kjlohhp3YGB_Xv8BPexToz66PxWc=.cb042f58-79b2-4c80-a5d4-245e95227858@github.com>
Message-ID: <E3RhlFkSBKQAdsidbcRTWny4F-oUEuHOfO0mMyCzORI=.3114bd9d-5e93-4e07-8244-fc0570607161@github.com>

On Tue, 6 Dec 2022 16:06:34 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Libgraal is compiled ahead of time and should not need any JVMCI Java code to be dynamically loaded at runtime. Prior to this PR, this is not the case due to:
>> 
>> * Code to copy system properties from the HotSpot heap into the libgraal heap. This is in `jdk.vm.ci.services.Services.initializeSavedProperties(byte[])` and `jdk.vm.ci.services.Services.serializeSavedProperties()`. This code should be moved to `java.base/jdk.internal.vm.VMSupport`.
>> * Code to translate exceptions from the HotSpot heap into the libgraal heap and vice versa. This code should be moved from `jdk.internal.vm.ci//jdk.vm.ci.hotspot.TranslatedException` to `java.base/jdk.internal.vm.VMSupport`.
>> 
>> This PR makes the above changes. As a result, it's possible to build a JDK image that includes (and uses) libgraal but does not include `jdk.internal.vm.ci` or `jdk.internal.vm.compiler`. This both reduces footprint and better isolates the JAVMCI and the Graal compiler as accessing these components from Java code is now impossible.
>
> Doug Simon has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - formatting to avoid very long lines [skip ci]
>  - removed debug code [skip ci]
>  - clarify Properties filtering [skip ci]
>  - remove debug code [skip ci]

Marked as reviewed by never (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11513

From egahlin at openjdk.org  Wed Dec  7 07:07:13 2022
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 7 Dec 2022 07:07:13 GMT
Subject: RFR: 8298175: JFR: Common timestamp for periodic events [v2]
In-Reply-To: <4bP-aYZidz-BbflACIv0qfc_8dpSNF6INArPJJ9wJQo=.a57084a7-d403-4975-a524-f33a2f0cf1fa@github.com>
References: <4bP-aYZidz-BbflACIv0qfc_8dpSNF6INArPJJ9wJQo=.a57084a7-d403-4975-a524-f33a2f0cf1fa@github.com>
Message-ID: <8flzSdzQU0xymX-UKIw3P5VJtgmV2Nkg3YRMBnHw5Ac=.c67497f7-0d43-42bb-a06b-d3c116b14e02@github.com>

> Could I have review of infrastructure that makes it easier to write periodic events with the same timestamp.
> 
> Testing: jdk/jdk/jfr + tier1 + tier2
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:

  Update request loop

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11541/files
  - new: https://git.openjdk.org/jdk/pull/11541/files/96146720..605f1290

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11541&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11541&range=00-01

  Stats: 8 lines in 1 file changed: 0 ins; 3 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/11541.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11541/head:pull/11541

PR: https://git.openjdk.org/jdk/pull/11541

From duke at openjdk.org  Wed Dec  7 07:42:13 2022
From: duke at openjdk.org (Yichen Yan)
Date: Wed, 7 Dec 2022 07:42:13 GMT
Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v17]
In-Reply-To: <v-LA3R9EgJGM_01c54w4H8ahI7BGPuKGSSpj2Ms7L84=.8dac50eb-2131-4413-a05f-be2e5db9eff0@github.com>
References: <fWd_NIunUhDXwy8uZSno90GC-PM8pFCey-pAMxxO0rI=.0fede0e4-1438-4321-bc8d-d11565389cae@github.com>
 <v-LA3R9EgJGM_01c54w4H8ahI7BGPuKGSSpj2Ms7L84=.8dac50eb-2131-4413-a05f-be2e5db9eff0@github.com>
Message-ID: <aAl1JS-JF6JXpXdiFyE7bOgOe46Y3pvApgtseKQSB_M=.45dcf873-8366-4a11-bc02-8c3d692e0a23@github.com>

On Tue, 29 Nov 2022 07:57:36 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> May I have this update reviewed?
>> 
>> The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure.  The build could pass if warnings are disabled for codes that use sprintf method.  For the long run, the sprintf could be replaced with snprintf.  This patch is trying to check if snprintf could be used.
>> 
>> Thanks,
>> Xuelei
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment for snprintf_checked

Any update on this? xcode 14 build has been broken for a while.

-------------

PR: https://git.openjdk.org/jdk/pull/11115

From jcking at openjdk.org  Wed Dec  7 07:44:50 2022
From: jcking at openjdk.org (Justin King)
Date: Wed, 7 Dec 2022 07:44:50 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data
In-Reply-To: <_ZlxgEIa-gRzcquPC-HwywlMUUD-87RuAAcNZybipXc=.cd2db8ec-0e2d-4a39-ba8b-f974ccda0d3a@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
 <_ZlxgEIa-gRzcquPC-HwywlMUUD-87RuAAcNZybipXc=.cd2db8ec-0e2d-4a39-ba8b-f974ccda0d3a@github.com>
Message-ID: <_6kp8XFp5Wpm6N5B6F8SdjN3fIy4PcG-SjBJ0_mxtKE=.d2ed6c42-1b77-4b9a-a6e6-1f661f0617a0@github.com>

On Wed, 7 Dec 2022 00:44:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Also see:
> 
> https://mail.openjdk.org/pipermail/hotspot-dev/2019-October/039783.html
> 
> The use of the Mutex* causes a performance issue.

@dholmes-ora Should we just have `MetadataFactory::free_metadata` call the destructor for `T` right after `deallocate_contents` and immediately before deallocating? The compiler will be smart enough to omit the call for types that are trivially destructible. That would also solve this bug, preserve any performance, and ensure it cannot happen again easily. It is fairly easy to forget to call `release_c_heap_structures`.

-------------

PR: https://git.openjdk.org/jdk/pull/11526

From thartmann at openjdk.org  Wed Dec  7 07:44:51 2022
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 7 Dec 2022 07:44:51 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data
In-Reply-To: <eXBjf5CE6SDQu5dZdVwSNDzeKTQpMnE267ugZDFBBcE=.235fce2e-7195-499d-89c5-37b504145968@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
 <eXBjf5CE6SDQu5dZdVwSNDzeKTQpMnE267ugZDFBBcE=.235fce2e-7195-499d-89c5-37b504145968@github.com>
Message-ID: <aZAVMU4nBozsELORr3WAbofXDyloBtxsapeTVL9h_P8=.80a35e02-5adb-40d1-a0cf-f0fc2566115d@github.com>

On Tue, 6 Dec 2022 22:36:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I'm struggling to see how [JDK-8297389](https://bugs.openjdk.org/browse/JDK-8297389) affected this. ??

[JDK-8297389](https://bugs.openjdk.org/browse/JDK-8297389) added the call to `MetadataFactory::free_metadata` in `Method::build_profiling_method_data` which does not free `MethodData::_extra_data_lock`. As Coleen explained: "Methods are attached to InstanceKlass so let InstanceKlass call release_C_heap_structures for them, except for this case that was added for MethodData here."

-------------

PR: https://git.openjdk.org/jdk/pull/11526

From jcking at openjdk.org  Wed Dec  7 07:49:01 2022
From: jcking at openjdk.org (Justin King)
Date: Wed, 7 Dec 2022 07:49:01 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data
In-Reply-To: <_6kp8XFp5Wpm6N5B6F8SdjN3fIy4PcG-SjBJ0_mxtKE=.d2ed6c42-1b77-4b9a-a6e6-1f661f0617a0@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
 <_ZlxgEIa-gRzcquPC-HwywlMUUD-87RuAAcNZybipXc=.cd2db8ec-0e2d-4a39-ba8b-f974ccda0d3a@github.com>
 <_6kp8XFp5Wpm6N5B6F8SdjN3fIy4PcG-SjBJ0_mxtKE=.d2ed6c42-1b77-4b9a-a6e6-1f661f0617a0@github.com>
Message-ID: <YG1up95JQpQmsj52R4VuMorEb41bJZNzyh91o2IRZuM=.40b059e5-d602-4166-b32e-cd57dd41ddc2@github.com>

On Wed, 7 Dec 2022 07:41:08 GMT, Justin King <jcking at openjdk.org> wrote:

> > Also see:
> > https://mail.openjdk.org/pipermail/hotspot-dev/2019-October/039783.html
> > The use of the Mutex* causes a performance issue.
> 
> @dholmes-ora Should we just have `MetadataFactory::free_metadata` call the destructor for `T` right after `deallocate_contents` and immediately before deallocating? The compiler will be smart enough to omit the call for types that are trivially destructible. That would also solve this bug, preserve any performance, and ensure it cannot happen again easily. It is fairly easy to forget to call `release_c_heap_structures`.

This would also assume `MetadataFactory::free_metadata` is always called with the most base class, since I believe Metadata objects don't have virtual destructors.

-------------

PR: https://git.openjdk.org/jdk/pull/11526

From xuelei at openjdk.org  Wed Dec  7 08:14:07 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 7 Dec 2022 08:14:07 GMT
Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v17]
In-Reply-To: <v-LA3R9EgJGM_01c54w4H8ahI7BGPuKGSSpj2Ms7L84=.8dac50eb-2131-4413-a05f-be2e5db9eff0@github.com>
References: <fWd_NIunUhDXwy8uZSno90GC-PM8pFCey-pAMxxO0rI=.0fede0e4-1438-4321-bc8d-d11565389cae@github.com>
 <v-LA3R9EgJGM_01c54w4H8ahI7BGPuKGSSpj2Ms7L84=.8dac50eb-2131-4413-a05f-be2e5db9eff0@github.com>
Message-ID: <yTZnKEPhgKZR7kJMf-ZJEC40yM1dFCHdTtfGgS6ezHI=.aee5aa13-7a92-4de1-a54d-89eef6fb2351@github.com>

On Tue, 29 Nov 2022 07:57:36 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> May I have this update reviewed?
>> 
>> The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure.  The build could pass if warnings are disabled for codes that use sprintf method.  For the long run, the sprintf could be replaced with snprintf.  This patch is trying to check if snprintf could be used.
>> 
>> Thanks,
>> Xuelei
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment for snprintf_checked

Could I have the last update reviewed?

-------------

PR: https://git.openjdk.org/jdk/pull/11115

From dholmes at openjdk.org  Wed Dec  7 08:14:13 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 7 Dec 2022 08:14:13 GMT
Subject: RFR: 8298175: JFR: Common timestamp for periodic events [v2]
In-Reply-To: <8flzSdzQU0xymX-UKIw3P5VJtgmV2Nkg3YRMBnHw5Ac=.c67497f7-0d43-42bb-a06b-d3c116b14e02@github.com>
References: <4bP-aYZidz-BbflACIv0qfc_8dpSNF6INArPJJ9wJQo=.a57084a7-d403-4975-a524-f33a2f0cf1fa@github.com>
 <8flzSdzQU0xymX-UKIw3P5VJtgmV2Nkg3YRMBnHw5Ac=.c67497f7-0d43-42bb-a06b-d3c116b14e02@github.com>
Message-ID: <TvojjwowmhSPIFV6gulRe0TXjcynnxltbXfvdJLDU-M=.ec486ec3-91c2-415d-93cd-8d012ad48d12@github.com>

On Wed, 7 Dec 2022 07:07:13 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of infrastructure that makes it easier to write periodic events with the same timestamp.
>> 
>> Testing: jdk/jdk/jfr + tier1 + tier2
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update request loop

Thanks for the update.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11541

From thartmann at openjdk.org  Wed Dec  7 08:27:05 2022
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 7 Dec 2022 08:27:05 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data
In-Reply-To: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
Message-ID: <0pS4ATILRogqOh9329DopW2y5RWtuNoLJHJo3ceJtb0=.3eeb16a2-d5eb-4dbc-813c-79b8589472c6@github.com>

On Tue, 6 Dec 2022 06:13:23 GMT, Justin King <jcking at openjdk.org> wrote:

> Resolve memory leak related to `MethodData::_extra_data_lock` in `Method::build_profiling_method_data` by defining `MethodData::release_C_heap_structures` and calling it where appropriate before deallocating `MethodData`.

src/hotspot/share/oops/method.cpp line 602:

> 600: 
> 601:   if (!Atomic::replace_if_null(&method->_method_data, method_data)) {
> 602:     method_data->release_C_heap_structures();

What about leaving the `_extra_data_lock` as is and explicitly calling `~MethodData()` here?

-------------

PR: https://git.openjdk.org/jdk/pull/11526

From aboldtch at openjdk.org  Wed Dec  7 08:31:13 2022
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 7 Dec 2022 08:31:13 GMT
Subject: Integrated: 8295258: Add BasicType argument to
 AccessInternal::decorator_fixup
In-Reply-To: <YBwrHyKAaMXOp3FPiulhZik-LMKaTPbQOS5Li2NqVlQ=.7aa77dca-5d76-4b79-99de-1de5c1410fad@github.com>
References: <YBwrHyKAaMXOp3FPiulhZik-LMKaTPbQOS5Li2NqVlQ=.7aa77dca-5d76-4b79-99de-1de5c1410fad@github.com>
Message-ID: <aAr0pAIBYWdU3dZbtpGSGpebUcspuDaJkmPlEvx_5Hs=.2a50897b-4a41-4988-86c5-9b6d10f7edba@github.com>

On Thu, 13 Oct 2022 10:24:15 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> There are call sites of the access API that does not specify the `INTERNAL_VALUE_IS_OOP` decorator for some reference type access. Change it so that `AccessInternal::decorator_fixup` is able to add this decorator by passing in the `BasicType` of the access.
> 
> Testing: Oracle platforms tier 1-3 and GHA

This pull request has now been integrated.

Changeset: 085f96cb
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/085f96cb1a9be3e55da5801069a800e322649a8f
Stats:     19 lines in 9 files changed: 2 ins; 0 del; 17 mod

8295258: Add BasicType argument to AccessInternal::decorator_fixup

Reviewed-by: stefank, eosterlund

-------------

PR: https://git.openjdk.org/jdk/pull/10692

From dholmes at openjdk.org  Wed Dec  7 08:31:47 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 7 Dec 2022 08:31:47 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data
In-Reply-To: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
Message-ID: <R-MXqlrpHkS9gsOdC0ZnNrt4QS5gaN7tN7y_i_cvpIU=.a2c46930-f54d-41a2-88db-c3547e4d3e0f@github.com>

On Tue, 6 Dec 2022 06:13:23 GMT, Justin King <jcking at openjdk.org> wrote:

> Resolve memory leak related to `MethodData::_extra_data_lock` in `Method::build_profiling_method_data` by defining `MethodData::release_C_heap_structures` and calling it where appropriate before deallocating `MethodData`.

I see how [JDK-8297389](https://bugs.openjdk.org/browse/JDK-8297389) caused this now but am unclear how to truly fix it. The memory management aspects of all this are extremely convoluted. In the context of [JDK-8297389](https://bugs.openjdk.org/browse/JDK-8297389) if it needs to free a MethodData that it allocated, then I would expect that to be a complete freeing - not sure why it doesn't call the destructor to handle things as that is what the destructor is for.

-------------

PR: https://git.openjdk.org/jdk/pull/11526

From stefank at openjdk.org  Wed Dec  7 08:43:02 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 7 Dec 2022 08:43:02 GMT
Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity
In-Reply-To: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
References: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
Message-ID: <zK45ITO6l5zN1r9PcEdse6MwJ0j0lGxy0XJFzBsmw7o=.e31cb84e-70ce-4deb-b8e0-60f41974007d@github.com>

On Tue, 8 Nov 2022 20:18:09 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details.
> 
> Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements.
> 
> Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16.
> 
> Testing:
>  - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390)
>  - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390)
>  - [x] tier1 (x86_64, x86_32, aarch64, riscv)
>  - [x] tier2 (x86_64, aarch64, riscv)
>  - [x] tier3 (x86_64, riscv)

Changes requested by stefank (Reviewer).

src/hotspot/share/gc/shared/collectedHeap.cpp line 435:

> 433: 
> 434: void CollectedHeap::zap_filler_array_with(HeapWord* start, size_t words, juint value) {
> 435:   int payload_start = align_up(arrayOopDesc::base_offset_in_bytes(T_INT), HeapWordSize) / HeapWordSize;

I see this in a number of places in the patch. Could you explain why this is correct? If base offset is not HeapWordSize aligned, then it looks like payload_start * HeapWordSize would be larger than the base offset.

src/hotspot/share/gc/z/zObjArrayAllocator.cpp line 55:

> 53:   const size_t header = arrayOopDesc::base_offset_in_bytes(element_type);
> 54:   size_t byte_size = _word_size * BytesPerWord;
> 55:   const size_t payload_size = byte_size - header;

Generational ZGC needs it to be able to write colored NULLs in object arrays, so a byte-centric approach will not work for us. Could you rewrite the code to take care of the "unaligned" 32 bits at the start of the array, and leave the word-centric segmented-clearing loop intact?

-------------

PR: https://git.openjdk.org/jdk/pull/11044

From lbourges at openjdk.org  Wed Dec  7 08:49:04 2022
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Wed, 7 Dec 2022 08:49:04 GMT
Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v17]
In-Reply-To: <v-LA3R9EgJGM_01c54w4H8ahI7BGPuKGSSpj2Ms7L84=.8dac50eb-2131-4413-a05f-be2e5db9eff0@github.com>
References: <fWd_NIunUhDXwy8uZSno90GC-PM8pFCey-pAMxxO0rI=.0fede0e4-1438-4321-bc8d-d11565389cae@github.com>
 <v-LA3R9EgJGM_01c54w4H8ahI7BGPuKGSSpj2Ms7L84=.8dac50eb-2131-4413-a05f-be2e5db9eff0@github.com>
Message-ID: <cz_T0QQD9hZhfJK6lju8jzPJ1wWrrtmTzDftMcje9qQ=.bc2f89ff-da8c-48fd-805d-c5337d6571af@github.com>

On Tue, 29 Nov 2022 07:57:36 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> May I have this update reviewed?
>> 
>> The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure.  The build could pass if warnings are disabled for codes that use sprintf method.  For the long run, the sprintf could be replaced with snprintf.  This patch is trying to check if snprintf could be used.
>> 
>> Thanks,
>> Xuelei
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment for snprintf_checked

I will have a look, I am affected too

-------------

PR: https://git.openjdk.org/jdk/pull/11115

From jcking at openjdk.org  Wed Dec  7 08:50:00 2022
From: jcking at openjdk.org (Justin King)
Date: Wed, 7 Dec 2022 08:50:00 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data
In-Reply-To: <0pS4ATILRogqOh9329DopW2y5RWtuNoLJHJo3ceJtb0=.3eeb16a2-d5eb-4dbc-813c-79b8589472c6@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
 <0pS4ATILRogqOh9329DopW2y5RWtuNoLJHJo3ceJtb0=.3eeb16a2-d5eb-4dbc-813c-79b8589472c6@github.com>
Message-ID: <Yyu4NEdh3X-FO1Qr9HmxLYQXU2g3Z45UVkVnQPMdiaA=.046fda94-4ef8-457e-84d4-f4d197bbda80@github.com>

On Wed, 7 Dec 2022 08:08:30 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Resolve memory leak related to `MethodData::_extra_data_lock` in `Method::build_profiling_method_data` by defining `MethodData::release_C_heap_structures` and calling it where appropriate before deallocating `MethodData`.
>
> src/hotspot/share/oops/method.cpp line 602:
> 
>> 600: 
>> 601:   if (!Atomic::replace_if_null(&method->_method_data, method_data)) {
>> 602:     method_data->release_C_heap_structures();
> 
> What about leaving the `_extra_data_lock` as is and explicitly calling `~MethodData()` here?

We can, but in general calling a member function after calling a destructor is likely undefined behavior. The lifetime of the object has ended.

-------------

PR: https://git.openjdk.org/jdk/pull/11526

From jcking at openjdk.org  Wed Dec  7 08:53:15 2022
From: jcking at openjdk.org (Justin King)
Date: Wed, 7 Dec 2022 08:53:15 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data
In-Reply-To: <R-MXqlrpHkS9gsOdC0ZnNrt4QS5gaN7tN7y_i_cvpIU=.a2c46930-f54d-41a2-88db-c3547e4d3e0f@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
 <R-MXqlrpHkS9gsOdC0ZnNrt4QS5gaN7tN7y_i_cvpIU=.a2c46930-f54d-41a2-88db-c3547e4d3e0f@github.com>
Message-ID: <PZWOIyvbUG8a3UlONYTiT0GKB5FWPvj6d5dt9zMuwqw=.20a562ab-ad86-4eab-8e63-184c40df84a1@github.com>

On Wed, 7 Dec 2022 08:28:18 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I see how [JDK-8297389](https://bugs.openjdk.org/browse/JDK-8297389) caused this now but am unclear how to truly fix it. The memory management aspects of all this are extremely convoluted. In the context of [JDK-8297389](https://bugs.openjdk.org/browse/JDK-8297389) if it needs to free a MethodData that it allocated, then I would expect that to be a complete freeing - not sure why it doesn't call the destructor to handle things as that is what the destructor is for.

IMO the destructor should just be called from MetadataFactory::free_metadata before returning the memory to the underlying arena. That way the destructor is the last thing called and not accessed again. Destructors mark the end of the objects lifetime.

-------------

PR: https://git.openjdk.org/jdk/pull/11526

From thartmann at openjdk.org  Wed Dec  7 09:09:01 2022
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 7 Dec 2022 09:09:01 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data
In-Reply-To: <PZWOIyvbUG8a3UlONYTiT0GKB5FWPvj6d5dt9zMuwqw=.20a562ab-ad86-4eab-8e63-184c40df84a1@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
 <R-MXqlrpHkS9gsOdC0ZnNrt4QS5gaN7tN7y_i_cvpIU=.a2c46930-f54d-41a2-88db-c3547e4d3e0f@github.com>
 <PZWOIyvbUG8a3UlONYTiT0GKB5FWPvj6d5dt9zMuwqw=.20a562ab-ad86-4eab-8e63-184c40df84a1@github.com>
Message-ID: <Ijvw2xFZkjxRnpi9fb7VotoSaezmKLp_Ya0-Hs_wgq4=.d1e1b879-cf92-4d11-b17c-155ffb4a6dbd@github.com>

On Wed, 7 Dec 2022 08:50:31 GMT, Justin King <jcking at openjdk.org> wrote:

> IMO the destructor should just be called from MetadataFactory::free_metadata before returning the memory to the underlying arena. That way the destructor is the last thing called and not accessed again. Destructors mark the end of the objects lifetime.

Yes, that does sound like the right thing to do.

-------------

PR: https://git.openjdk.org/jdk/pull/11526

From thartmann at openjdk.org  Wed Dec  7 09:18:05 2022
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 7 Dec 2022 09:18:05 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data
In-Reply-To: <Yyu4NEdh3X-FO1Qr9HmxLYQXU2g3Z45UVkVnQPMdiaA=.046fda94-4ef8-457e-84d4-f4d197bbda80@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
 <0pS4ATILRogqOh9329DopW2y5RWtuNoLJHJo3ceJtb0=.3eeb16a2-d5eb-4dbc-813c-79b8589472c6@github.com>
 <Yyu4NEdh3X-FO1Qr9HmxLYQXU2g3Z45UVkVnQPMdiaA=.046fda94-4ef8-457e-84d4-f4d197bbda80@github.com>
Message-ID: <dIOh3d-k_1YlfCAW7-erNNgNb5cNrbeZFyur12WxkFw=.945dc385-de8c-4416-b4be-bd05be7c8622@github.com>

On Wed, 7 Dec 2022 08:47:38 GMT, Justin King <jcking at openjdk.org> wrote:

>> src/hotspot/share/oops/method.cpp line 602:
>> 
>>> 600: 
>>> 601:   if (!Atomic::replace_if_null(&method->_method_data, method_data)) {
>>> 602:     method_data->release_C_heap_structures();
>> 
>> What about leaving the `_extra_data_lock` as is and explicitly calling `~MethodData()` here?
>
> We can, but in general calling a member function after calling a destructor is likely undefined behavior. The lifetime of the object has ended.

Right, I thought that it wouldn't make things worse because we already call the destructor in current code, but here we call `free_metadata` right after which performs all kinds of accesses on `method_data`. Not an option then.

@dholmes-ora Is that what you were suggesting when you said "not sure why it doesn't call the destructor to handle things as that is what the destructor is for"?

-------------

PR: https://git.openjdk.org/jdk/pull/11526

From dholmes at openjdk.org  Wed Dec  7 09:26:13 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 7 Dec 2022 09:26:13 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data
In-Reply-To: <R-MXqlrpHkS9gsOdC0ZnNrt4QS5gaN7tN7y_i_cvpIU=.a2c46930-f54d-41a2-88db-c3547e4d3e0f@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
 <R-MXqlrpHkS9gsOdC0ZnNrt4QS5gaN7tN7y_i_cvpIU=.a2c46930-f54d-41a2-88db-c3547e4d3e0f@github.com>
Message-ID: <Cd6-KN9sdwCyH2CMZ14yWBzuTrgc1ccRd7HHyKDrarw=.a24540c3-f8d1-4323-b1a8-9328387c2030@github.com>

On Wed, 7 Dec 2022 08:28:18 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Resolve memory leak related to `MethodData::_extra_data_lock` in `Method::build_profiling_method_data` by defining `MethodData::release_C_heap_structures` and calling it where appropriate before deallocating `MethodData`.
>
> I see how [JDK-8297389](https://bugs.openjdk.org/browse/JDK-8297389) caused this now but am unclear how to truly fix it. The memory management aspects of all this are extremely convoluted. In the context of [JDK-8297389](https://bugs.openjdk.org/browse/JDK-8297389) if it needs to free a MethodData that it allocated, then I would expect that to be a complete freeing - not sure why it doesn't call the destructor to handle things as that is what the destructor is for.

@dholmes-ora Is that what you were suggesting when you said "not sure why it doesn't call the destructor to handle things as that is what the destructor is for"?

Yes - though as I said the memory management here is so convoluted that it is hard for me to see in detail if that is correct.

-------------

PR: https://git.openjdk.org/jdk/pull/11526

From jpai at openjdk.org  Wed Dec  7 09:27:16 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 7 Dec 2022 09:27:16 GMT
Subject: RFR: 8296477: Foreign linker implementation update following JEP
 434 [v2]
In-Reply-To: <adPNJWEXLNY6LPaqX2N0eeiYUQDyRlp4rfJBqZYWoNI=.5ee36196-7bb8-4e28-adde-3cdd09eab781@github.com>
References: <CGd4JSefJvfEVkZEfORzthEIeV53kLk_UkZHAhJGrQ0=.7741b5f2-2227-4017-8164-d54fb9d30d10@github.com>
 <dMQ238rubrgCcyRv-456L2yibOvwrz1gWFPUOQTM5TQ=.31dcad26-a466-4806-ab72-33eb1c89a6ef@github.com>
 <i6cFFRmj8BY5ykF4ROioLuh1J0kFrKTRgyHf4fIFeSM=.aeeba4fe-3efa-4b3d-b31e-3f428b0c33f5@github.com>
 <adPNJWEXLNY6LPaqX2N0eeiYUQDyRlp4rfJBqZYWoNI=.5ee36196-7bb8-4e28-adde-3cdd09eab781@github.com>
Message-ID: <-hS98wCfpghUkzWuyf0MzhpIpCIjOiDDitZ39kx4aeU=.c2dbc3eb-a649-489e-b0cb-eb14d7f55dbf@github.com>

On Thu, 10 Nov 2022 15:22:45 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> test/jdk/ProblemList.txt line 484:
>> 
>>> 482: # jdk_foreign
>>> 483: 
>>> 484: java/foreign/callarranger/TestAarch64CallArranger.java generic-x86
>> 
>> Should we exclude these tests on 32 bits in the jtreg header (as I think we do for other tests) ?
>
> I'm not sure what the conventional move here would be. Adding them to the problem list doesn't seem to make the failures go away in GHA at least. I can exclude them with `@requires` as well.

Hello Jorn,

> Adding them to the problem list doesn't seem to make the failures go away in GHA at least.

It appears that these 2 problem listed lines are malformed (it's missing a bug id in each of these lines https://openjdk.org/guide/#problemlisting-jtreg-tests) Maybe that's why those tests didn't get problem listed in the GHA runs?

-------------

PR: https://git.openjdk.org/jdk/pull/11019

From stuefe at openjdk.org  Wed Dec  7 09:41:18 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 7 Dec 2022 09:41:18 GMT
Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v17]
In-Reply-To: <v-LA3R9EgJGM_01c54w4H8ahI7BGPuKGSSpj2Ms7L84=.8dac50eb-2131-4413-a05f-be2e5db9eff0@github.com>
References: <fWd_NIunUhDXwy8uZSno90GC-PM8pFCey-pAMxxO0rI=.0fede0e4-1438-4321-bc8d-d11565389cae@github.com>
 <v-LA3R9EgJGM_01c54w4H8ahI7BGPuKGSSpj2Ms7L84=.8dac50eb-2131-4413-a05f-be2e5db9eff0@github.com>
Message-ID: <wtfe3m7FrVWssfUYna5S0oWNL6Xhz4UQRb-4V2tvvmc=.3356deec-bbe2-4372-ac3a-2cdc620fae67@github.com>

On Tue, 29 Nov 2022 07:57:36 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> May I have this update reviewed?
>> 
>> The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure.  The build could pass if warnings are disabled for codes that use sprintf method.  For the long run, the sprintf could be replaced with snprintf.  This patch is trying to check if snprintf could be used.
>> 
>> Thanks,
>> Xuelei
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment for snprintf_checked

I looked through all the code and found only some minor issues. I would appreciate more eyes on this, though.

I still think this would have been less work (for author and reviewers) had we converted the code to stringStream right away in the hotspot. stringStream takes care of a lot of this boilerplate stuff.

src/hotspot/os/bsd/attachListener_bsd.cpp line 260:

> 258:   // name ("load", "datadump", ...), and <arg> is an argument
> 259:   int expected_str_count = 2 + AttachOperation::arg_count_max;
> 260:   const int max_len = (ver_str_len + 1) + (AttachOperation::name_length_max + 1) +

This makes `max_len` a runtime variable, before it was a compile time constant. Below, we use it to create the buf array. IIRC creating an array with a variable runtime length is a non-standard compiler extension. I am surprised this even builds.

src/hotspot/share/adlc/output_c.cpp line 46:

> 44:   va_end(args);
> 45:   assert(result >= 0, "snprintf error");
> 46:   assert(static_cast<size_t>(result) < len, "snprintf truncated");

Question, what is this assert? The standard CRT assert? Will it fire always, or just in debug?

src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp line 311:

> 309:   for (int i = 0; i < len ; i++) {
> 310:     VMStructEntry vmField = JVMCIVMStructs::localHotSpotVMStructs[i];
> 311:     const size_t name_buf_size = strlen(vmField.typeName) + strlen(vmField.fieldName) + 3 /* "::" */;

nit, could you make this "+ 2 + 1" instead? That makes it a bit clearer that the last byte is for \0

src/hotspot/share/runtime/os.cpp line 102:

> 100: }
> 101: 
> 102: int os::snprintf_checked(char* buf, size_t len, const char* fmt, ...) {

Can you please assert for buffer len > 0 and < some reasonable max, e.g. 1 gb? Protects us against neg overflows and other errors.

src/hotspot/share/runtime/os.cpp line 108:

> 106:   va_end(args);
> 107:   assert(result >= 0, "os::snprintf error");
> 108:   assert(static_cast<size_t>(result) < len, "os::snprintf truncated");

Can you please provide a printout for the truncated string? Proposal:

```assert(static_cast<size_t>(result) < len, "os::snprintf truncated ("%.200s...")", buf);```

src/hotspot/share/utilities/utf8.cpp line 227:

> 225:     } else {
> 226:       if (p + 6 >= end) break;      // string is truncated
> 227:       os::snprintf_checked(p, 7, "\\u%04x", c);  // counting terminating zero in

I had to think a while until I was sure this is correct :-) 
We are sure that c can never be > 0xFFFFFF (6 digits), right? But if that is false, code had been wrong before too.

-------------

PR: https://git.openjdk.org/jdk/pull/11115

From aph at openjdk.org  Wed Dec  7 10:17:17 2022
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 7 Dec 2022 10:17:17 GMT
Subject: Integrated: JDK-8286666: JEP 429: Implementation of Scoped Values
 (Incubator)
In-Reply-To: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
References: <GzS4FCR3pe2UG9degJJV3dP2RwUG8X8BTVpYobXldIs=.4c6dedaa-98d4-4288-8f55-bfd3c6b88c79@github.com>
Message-ID: <6WicDtGmG6FUGBr116x5HgTN4uUo_ATSOJLKDbhfU1U=.996af1fa-d13b-41e5-853e-dfe242823baf@github.com>

On Wed, 2 Nov 2022 16:23:34 GMT, Andrew Haley <aph at openjdk.org> wrote:

> JEP 429 implementation.

This pull request has now been integrated.

Changeset: 221e1a42
Author:    Andrew Haley <aph at openjdk.org>
Committer: Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/221e1a426070088b819ddc37b7ca77d9d8626eb4
Stats:     3336 lines in 62 files changed: 2913 ins; 254 del; 169 mod

8286666: JEP 429: Implementation of Scoped Values (Incubator)

Reviewed-by: psandoz, dlong, alanb, mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/10952

From iwalulya at openjdk.org  Wed Dec  7 10:30:29 2022
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Wed, 7 Dec 2022 10:30:29 GMT
Subject: RFR: 8296401: ConcurrentHashTable::bulk_delete might miss to
 delete some objects
In-Reply-To: <u6q4wu2XAkhfwRnUo9YZIbKQLby_obt1cECdFIG0e_w=.b2616c79-1bc3-4efb-bd97-3ebfc4c753c0@github.com>
References: <rWw3Hb1baG5eslMgFnOdEP1Q4avhfYc3uTpjdB9DaP0=.23f34ff0-eff9-421b-9e70-7f119fd90e5d@github.com>
 <srzYQG8vQxXtFu8IYd4LzHoFZo6VR8_D_9e5wlek0u4=.c3fb4829-6de5-428e-9b70-f34aeba9c55f@github.com>
 <XlpaIj9dRjwUPkQTmLqfWNx7r4afKUu5cE4xUDRwNgw=.96918f61-bb6d-4d92-995d-d763adf6df63@github.com>
 <-46D7o9D9hweEylWT61buGVsoYYFZLlKezzaBgt7GvQ=.7e7b3755-98cb-4696-ba07-0ba3b7046a4a@github.com>
 <oh4H4jjhdQ2TR37v4PsDr99lVtux72HC5gnUkCo5TgQ=.620d2b25-916c-42a5-b655-1cdf5dbd2328@github.com>
 <_bNq28p7YDTdicn_-pwN-xB-CHeMUUtTsJfCLTV_CGw=.d82a1a64-7f07-472d-af3c-427fba8598d1@github.com>
 <u6q4wu2XAkhfwRnUo9YZIbKQLby_obt1cECdFIG0e_w=.b2616c79-1bc3-4efb-bd97-3ebfc4c753c0@github.com>
Message-ID: <k2asHk_Oj3bvLhKmXZWVeb04627QWe2Lh-Y1IoiEIC0=.6b7cbc0e-48be-416a-8f6d-d2ca67c73db7@github.com>

On Tue, 6 Dec 2022 13:42:47 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> > > That is true. Do you think that is a problem with the new implementation?
> > > The change overrides the intentions of `BULK_DELETE_LIMIT ` so it would be better to change the name of that constant.
> 
> Is `STACK_BUFFER_SIZE` good enough, or do you have a better suggestion? I would also prefer to make it look less like a C macro and use the alternative casing `StackBufferSize`, is that OK?

The name is fine by me, however, you need a comment to motivate the use of the stack array instead of a growable array right away

-------------

PR: https://git.openjdk.org/jdk/pull/10983

From mbaesken at openjdk.org  Wed Dec  7 11:54:53 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 7 Dec 2022 11:54:53 GMT
Subject: RFR: JDK-8296995: ostream should handle snprintf(3) errors in
 release builds [v2]
In-Reply-To: <NwPLthMM9usps18JQUWX8lHFpY2BNT83FstuJNcQx78=.aec8d348-c542-4d9b-a735-9a64134807c4@github.com>
References: <lXBQPLCrniDiyp9OAfVdsHq3xVNsxxTWymy_1cSaiHg=.0f341fe2-7bcc-4640-bf2e-0f1883ee22e4@github.com>
 <NwPLthMM9usps18JQUWX8lHFpY2BNT83FstuJNcQx78=.aec8d348-c542-4d9b-a735-9a64134807c4@github.com>
Message-ID: <Cwbfnvg1AanuRevh_RE8NFjLhFMzfoPC1Esbzde8tDg=.867b0d20-dfbe-4166-835d-fc2b10453c08@github.com>

On Mon, 5 Dec 2022 08:07:25 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Small fix for a very unlikely problem. 
>> 
>> All streams in ostream.hpp end up using `os::snprintf()`, which uses `::vsnprintf()`. `vsnprintf(3)`can fail and return -1. 
>> 
>> The chance for this to happen is small. snprintf errors are usually encoding errors though not always (see third example at https://stackoverflow.com/questions/65334245/what-is-an-encoding-error-for-sprintf-that-should-return-1). I found "%ls" in one place in windows coding, so I am not sure we can always exclude the possibility of wide strings being used in our code base, or that of printing with outside-provided format strings.
>> 
>> In case of an error, we assert in debug builds but don't handle it in release. There, this situation gets misdiagnosed later as a buffer overflow because we cast the signedness of the result away (see `outputStream::do_vsnprintf()`). 
>> 
>> ---
>> 
>> The patch is trivial. The most exciting thing is the gtest, I guess.
>> 
>> In release builds, we now treat this condition as an empty string write. I considered printing a clear marker into the stream instead, e.g. "ENCODING ERROR", but ultimately did not do it.
>
> Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   JDK-8296995-ostream-handle-sprintf-errors

Looks good to me.
I thought about adding some (potentially optional) log or trace in case required_len < 0 but probably it is good as it is.
Please adjust  copyright year in [test_ostream.cpp](https://github.com/openjdk/jdk/pull/11160/files#diff-c0d2076833ffa15ad831383a8ddc594763aef71e53276afeddc8bdaf1b4e887e) .

-------------

Marked as reviewed by mbaesken (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11160

From mdoerr at openjdk.org  Wed Dec  7 12:01:34 2022
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 7 Dec 2022 12:01:34 GMT
Subject: RFR: JDK-8296995: ostream should handle snprintf(3) errors in
 release builds [v2]
In-Reply-To: <NwPLthMM9usps18JQUWX8lHFpY2BNT83FstuJNcQx78=.aec8d348-c542-4d9b-a735-9a64134807c4@github.com>
References: <lXBQPLCrniDiyp9OAfVdsHq3xVNsxxTWymy_1cSaiHg=.0f341fe2-7bcc-4640-bf2e-0f1883ee22e4@github.com>
 <NwPLthMM9usps18JQUWX8lHFpY2BNT83FstuJNcQx78=.aec8d348-c542-4d9b-a735-9a64134807c4@github.com>
Message-ID: <wn5bIQ2CNFU8FBf0BkICZeP2Y64H0VXwu1C01kwSG4c=.d6b501ee-dfde-4baa-b850-daf5e77ddb16@github.com>

On Mon, 5 Dec 2022 08:07:25 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Small fix for a very unlikely problem. 
>> 
>> All streams in ostream.hpp end up using `os::snprintf()`, which uses `::vsnprintf()`. `vsnprintf(3)`can fail and return -1. 
>> 
>> The chance for this to happen is small. snprintf errors are usually encoding errors though not always (see third example at https://stackoverflow.com/questions/65334245/what-is-an-encoding-error-for-sprintf-that-should-return-1). I found "%ls" in one place in windows coding, so I am not sure we can always exclude the possibility of wide strings being used in our code base, or that of printing with outside-provided format strings.
>> 
>> In case of an error, we assert in debug builds but don't handle it in release. There, this situation gets misdiagnosed later as a buffer overflow because we cast the signedness of the result away (see `outputStream::do_vsnprintf()`). 
>> 
>> ---
>> 
>> The patch is trivial. The most exciting thing is the gtest, I guess.
>> 
>> In release builds, we now treat this condition as an empty string write. I considered printing a clear marker into the stream instead, e.g. "ENCODING ERROR", but ultimately did not do it.
>
> Thomas Stuefe 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 one additional commit since the last revision:
> 
>   JDK-8296995-ostream-handle-sprintf-errors

test/hotspot/gtest/utilities/test_ostream.cpp line 130:

> 128:   ::memset(buf, 'X', sizeof(buf));
> 129:   int n = ::snprintf(buf + 1, sizeof(buf) - 2, "HALLO %ls", w);
> 130:   if (n == -1) { // yes, we get an error. Retry using stringStream.

Can it happen that we don't get an error, here? If so, the ASSERT below still expects one, so, the test will fail. Correct?

-------------

PR: https://git.openjdk.org/jdk/pull/11160

From duke at openjdk.org  Wed Dec  7 12:09:24 2022
From: duke at openjdk.org (Johannes Bechberger)
Date: Wed, 7 Dec 2022 12:09:24 GMT
Subject: RFR: 8297967: Make frame::safe_for_sender safer [v5]
In-Reply-To: <Cctc-M2HyUqIjpcRyTjmF46wKDqvBtnnYe5Mn45sdO8=.03bdf65f-bf98-48dc-b957-0c838003d46f@github.com>
References: <Cctc-M2HyUqIjpcRyTjmF46wKDqvBtnnYe5Mn45sdO8=.03bdf65f-bf98-48dc-b957-0c838003d46f@github.com>
Message-ID: <dLF4GX7MUGBJe5tHJuwGT4aKjMaiONH5Ncuym01cp5g=.e334b35e-daab-485c-ae0d-5183eca9d69d@github.com>

> Makes frame::safe_for_sender safer by using os::is_readable_pointer to check the location of the return address.

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Remove check for value that might be null

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11461/files
  - new: https://git.openjdk.org/jdk/pull/11461/files/32cced6e..971553fc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11461&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11461&range=03-04

  Stats: 4 lines in 4 files changed: 0 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11461.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11461/head:pull/11461

PR: https://git.openjdk.org/jdk/pull/11461

From fyang at openjdk.org  Wed Dec  7 13:11:58 2022
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 7 Dec 2022 13:11:58 GMT
Subject: RFR: 8298075: RISC-V: Implement post-call NOPs [v6]
In-Reply-To: <ORZHK2_0RTYb9rtYkX_JXTTcex_LryeoYT3rk6mrIxs=.6743e193-2cc6-49b9-a896-befd73206072@github.com>
References: <inZ_2fowZZQz0C53E2h4zURoyQIwZcJaBfhC4zwFyb8=.cbc7e361-9bad-48ce-b6d4-c3a8fe2e1cba@github.com>
 <ORZHK2_0RTYb9rtYkX_JXTTcex_LryeoYT3rk6mrIxs=.6743e193-2cc6-49b9-a896-befd73206072@github.com>
Message-ID: <cCfOtWYOtpM0R3WvvNESUZ_IkYWhL40Xtj56rr--Ung=.68226b06-1da6-4959-aae6-cbde42062d60@github.com>

On Tue, 6 Dec 2022 10:41:59 GMT, Xiaolin Zheng <xlinzheng at openjdk.org> wrote:

>> Same as [JDK-8287567](https://bugs.openjdk.org/browse/JDK-8287567), we need to implement post-call NOPs in the RISC-V backend.
>> 
>> We use `li32` to implement it. `li32` will signed-extend the loaded imm32 to a 64-bit register. However, our reader `NativePostCallNop::displacement()` only needs the low 32 bits value so we are safe.
>> 
>> The current post-call NOP is like:
>> 
>> nop                    (always 4-byte, used for deoptimization, please see `NativePostCallNop::make_deopt()`)
>> lui zr, <imm20>        (always 4-byte)
>> addiw zr, zr, <imm12>  (always 4-byte)
>> 
>> 
>> The code size here is the same as the AArch64 counterpart, 12 bytes.
>> 
>> The logic of setting the post-call NOP displacement is at `install_post_call_nop_displacement()` [1] when nmethods are being installed, so no one is running post-call NOPs when we are patching them.
>> 
>> One can check them by directly using `java --enable-preview -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly`.
>> 
>> Tested hotspot tier1~4 and jdk tier1~4 using fastdebug by force turning on `--enable-preview`; SPECjbb2015 and dacapo were tested without regressions found. Skynet JMH benchmark seems to have an improvement from `8662ms/op -> 8495ms/op`.
>> 
>> Thanks,
>> Xiaolin
>> 
>> [1] https://github.com/openjdk/jdk/blob/b49fd920b6690a8b828c85e45c10e5c4c54d2022/src/hotspot/share/code/nmethod.cpp#L1078-L1107
>
> Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Plural form...

Change looks good. I also performed regular benchmark tests (Dacapo, specjbb,2015, Renaissance) for this change and I didn't notice regressions from the numbers. So I guess it should be safe to have this.

-------------

Marked as reviewed by fyang (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11502

From stuefe at openjdk.org  Wed Dec  7 13:46:05 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 7 Dec 2022 13:46:05 GMT
Subject: RFR: JDK-8296995: ostream should handle snprintf(3) errors in
 release builds [v2]
In-Reply-To: <wn5bIQ2CNFU8FBf0BkICZeP2Y64H0VXwu1C01kwSG4c=.d6b501ee-dfde-4baa-b850-daf5e77ddb16@github.com>
References: <lXBQPLCrniDiyp9OAfVdsHq3xVNsxxTWymy_1cSaiHg=.0f341fe2-7bcc-4640-bf2e-0f1883ee22e4@github.com>
 <NwPLthMM9usps18JQUWX8lHFpY2BNT83FstuJNcQx78=.aec8d348-c542-4d9b-a735-9a64134807c4@github.com>
 <wn5bIQ2CNFU8FBf0BkICZeP2Y64H0VXwu1C01kwSG4c=.d6b501ee-dfde-4baa-b850-daf5e77ddb16@github.com>
Message-ID: <MJKFZBWLSK-Qe6Bg5w3ouePec5hbN5M3WzqcVurFMds=.4e635591-470d-42f2-abcf-4fea9accc3ef@github.com>

On Wed, 7 Dec 2022 11:58:30 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Thomas Stuefe 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 one additional commit since the last revision:
>> 
>>   JDK-8296995-ostream-handle-sprintf-errors
>
> test/hotspot/gtest/utilities/test_ostream.cpp line 130:
> 
>> 128:   ::memset(buf, 'X', sizeof(buf));
>> 129:   int n = ::snprintf(buf + 1, sizeof(buf) - 2, "HALLO %ls", w);
>> 130:   if (n == -1) { // yes, we get an error. Retry using stringStream.
> 
> Can it happen that we don't get an error, here? If so, the ASSERT below still expects one, so, the test will fail. Correct?

Good catch. I added the death test afterwards. I'll fix it.

-------------

PR: https://git.openjdk.org/jdk/pull/11160

From mgronlun at openjdk.org  Wed Dec  7 13:50:06 2022
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 7 Dec 2022 13:50:06 GMT
Subject: RFR: 8157023: Integrate NMT with JFR [v4]
In-Reply-To: <m_u3J5WSeZE3d7VatREoc1pbTkG4txNAmfZcRz1eTpc=.341a61ef-0381-40fe-b195-955c163949c8@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <m_u3J5WSeZE3d7VatREoc1pbTkG4txNAmfZcRz1eTpc=.341a61ef-0381-40fe-b195-955c163949c8@github.com>
Message-ID: <eANdeA06DRBZQDXkpn_dNwBWnYmYVtqWeGmSeZDVVTg=.14c01ac2-a0fd-4638-abbc-eca31a38b7a9@github.com>

On Tue, 6 Dec 2022 16:42:54 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Please review this enhancement to include NMT information in JFR recordings.
>> 
>> **Summary**
>> Native Memory Tracking summary information can be obtained from a running VM using `jcmd` if started with `-XX:NativeMemoryTracking=summary/detail`. Using `jcmd` requires you to run a separate process and to parse the output to get the needed information. This change adds JFR events for NMT information to enable additional ways to consume the NMT data.
>> 
>> There are two new events added:
>> * _NativeMemoryUsage_ - The total native memory usage.
>> * _NativeMemoryUsagePart_ - The native memory usage for each component.
>> 
>> These events are sent periodically and by default the interval is 1s. This can of course be discussed, but that is the staring point. When NMT is not enabled on events will be sent.
>> 
>> **Testing**
>> * Added a simple test to verify that the events are sent as expected depending on if NMT is enabled or not.
>> * Mach5 sanity testing
>
> Stefan Johansson has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Rename the files
>  - Renaming and updating comments
>  - tstuefe review - no rename

src/hotspot/share/jfr/metadata/metadata.xml line 711:

> 709:   <Event name="NativeMemoryUsage" category="Java Virtual Machine, Memory" label="Native Memory Usage Per Type"
> 710:     description="Native memory usage for a given memory type in the JVM" period="everyChunk">
> 711:     <Field type="string" name="type" label="Memory Type" description="Type used for the native memory allocation" />

Suggest turning this type "string" into a JFR-constant type, like "JfrNMTType" to only send id's, instead of the entire strings. Can be done in a follow-up change.

src/hotspot/share/services/memJfrReporter.cpp line 67:

> 65:   Ticks timestamp = MemJFRCurrentUsage::get_timestamp();
> 66: 
> 67:   EventNativeMemoryUsageTotal event;

Since you are explicitly setting the startTime field yourself, you can pass 'UNTIMED' to the event constructor. This will bypass the automatic setting of _starttime as part of the constructor.

EventNativeMemoryUsageTotal event(UNTIMED);

src/hotspot/share/services/memJfrReporter.cpp line 75:

> 73: 
> 74: void MemJFRReporter::send_type_event(const Ticks& starttime, const char* type, size_t reserved, size_t committed) {
> 75:   EventNativeMemoryUsage event;

Since you are explicitly setting the startTime field yourself, you can pass 'UNTIMED' to the event constructor. This will bypass the automatic setting of _starttime as part of the constructor.

EventNativeMemoryUsage event(UNTIMED);

src/hotspot/share/services/memJfrReporter.hpp line 45:

> 43: // Helper class to avoid refreshing the NMTUsage to often and allow
> 44: // the two JFR events to use the same data.
> 45: class MemJFRCurrentUsage : public AllStatic {

Move to .cpp file to because only used internally. Does not even have to be a class, can only be static fields and accessors.

src/jdk.jfr/share/conf/jfr/default.jfc line 516:

> 514: 
> 515:     <event name="jdk.NativeMemoryUsage">
> 516:       <setting name="enabled" control="gc-enabled-normal">true</setting>

gc-enabled-normal? Should this really be tied to a gc control? An NMT control to be introduced?

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From stuefe at openjdk.org  Wed Dec  7 14:03:14 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 7 Dec 2022 14:03:14 GMT
Subject: RFR: JDK-8296995: ostream should handle snprintf(3) errors in
 release builds [v2]
In-Reply-To: <NwPLthMM9usps18JQUWX8lHFpY2BNT83FstuJNcQx78=.aec8d348-c542-4d9b-a735-9a64134807c4@github.com>
References: <lXBQPLCrniDiyp9OAfVdsHq3xVNsxxTWymy_1cSaiHg=.0f341fe2-7bcc-4640-bf2e-0f1883ee22e4@github.com>
 <NwPLthMM9usps18JQUWX8lHFpY2BNT83FstuJNcQx78=.aec8d348-c542-4d9b-a735-9a64134807c4@github.com>
Message-ID: <xlEgvz4RRr9xi15egZlzvv39tV9M-fd-xeI1AmPJIVk=.b90ad279-33a0-42a2-a841-4e2e2e67f60d@github.com>

On Mon, 5 Dec 2022 08:07:25 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Small fix for a very unlikely problem. 
>> 
>> All streams in ostream.hpp end up using `os::snprintf()`, which uses `::vsnprintf()`. `vsnprintf(3)`can fail and return -1. 
>> 
>> The chance for this to happen is small. snprintf errors are usually encoding errors though not always (see third example at https://stackoverflow.com/questions/65334245/what-is-an-encoding-error-for-sprintf-that-should-return-1). I found "%ls" in one place in windows coding, so I am not sure we can always exclude the possibility of wide strings being used in our code base, or that of printing with outside-provided format strings.
>> 
>> In case of an error, we assert in debug builds but don't handle it in release. There, this situation gets misdiagnosed later as a buffer overflow because we cast the signedness of the result away (see `outputStream::do_vsnprintf()`). 
>> 
>> ---
>> 
>> The patch is trivial. The most exciting thing is the gtest, I guess.
>> 
>> In release builds, we now treat this condition as an empty string write. I considered printing a clear marker into the stream instead, e.g. "ENCODING ERROR", but ultimately did not do it.
>
> Thomas Stuefe 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 one additional commit since the last revision:
> 
>   JDK-8296995-ostream-handle-sprintf-errors

@TheRealMDoerr : fixed, tested on debug

-------------

PR: https://git.openjdk.org/jdk/pull/11160

From mdoerr at openjdk.org  Wed Dec  7 14:05:03 2022
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 7 Dec 2022 14:05:03 GMT
Subject: RFR: JDK-8296995: ostream should handle snprintf(3) errors in
 release builds [v3]
In-Reply-To: <Bdg6H0QXAZj8jk9vKoAn6UdW4TT5CvpfoGpdopvfaz4=.e6c2ea04-23d2-4fd5-b7fc-cccfda27963c@github.com>
References: <lXBQPLCrniDiyp9OAfVdsHq3xVNsxxTWymy_1cSaiHg=.0f341fe2-7bcc-4640-bf2e-0f1883ee22e4@github.com>
 <Bdg6H0QXAZj8jk9vKoAn6UdW4TT5CvpfoGpdopvfaz4=.e6c2ea04-23d2-4fd5-b7fc-cccfda27963c@github.com>
Message-ID: <vIQ3eUEJ4hkN9FFfrZ_b_0WRxKqIaU86nIFfx_LQsn0=.60c05a1b-8b4f-4aa5-99bf-8892cdf2c950@github.com>

On Wed, 7 Dec 2022 14:03:11 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Small fix for a very unlikely problem. 
>> 
>> All streams in ostream.hpp end up using `os::snprintf()`, which uses `::vsnprintf()`. `vsnprintf(3)`can fail and return -1. 
>> 
>> The chance for this to happen is small. snprintf errors are usually encoding errors though not always (see third example at https://stackoverflow.com/questions/65334245/what-is-an-encoding-error-for-sprintf-that-should-return-1). I found "%ls" in one place in windows coding, so I am not sure we can always exclude the possibility of wide strings being used in our code base, or that of printing with outside-provided format strings.
>> 
>> In case of an error, we assert in debug builds but don't handle it in release. There, this situation gets misdiagnosed later as a buffer overflow because we cast the signedness of the result away (see `outputStream::do_vsnprintf()`). 
>> 
>> ---
>> 
>> The patch is trivial. The most exciting thing is the gtest, I guess.
>> 
>> In release builds, we now treat this condition as an empty string write. I considered printing a clear marker into the stream instead, e.g. "ENCODING ERROR", but ultimately did not do it.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback martin

Thanks for the update! LGTM. Please update the test's Copyright header as requested by Matthias.

-------------

Marked as reviewed by mdoerr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11160

From egahlin at openjdk.org  Wed Dec  7 14:02:41 2022
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 7 Dec 2022 14:02:41 GMT
Subject: RFR: 8157023: Integrate NMT with JFR [v4]
In-Reply-To: <eANdeA06DRBZQDXkpn_dNwBWnYmYVtqWeGmSeZDVVTg=.14c01ac2-a0fd-4638-abbc-eca31a38b7a9@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <m_u3J5WSeZE3d7VatREoc1pbTkG4txNAmfZcRz1eTpc=.341a61ef-0381-40fe-b195-955c163949c8@github.com>
 <eANdeA06DRBZQDXkpn_dNwBWnYmYVtqWeGmSeZDVVTg=.14c01ac2-a0fd-4638-abbc-eca31a38b7a9@github.com>
Message-ID: <WygDMFUxzsVidG-JcjFdIrq5xoDdANvDaCPxSUBNzf0=.302b26cc-1197-4ba7-b07f-7da0a62945fc@github.com>

On Wed, 7 Dec 2022 13:46:47 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Stefan Johansson has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Rename the files
>>  - Renaming and updating comments
>>  - tstuefe review - no rename
>
> src/jdk.jfr/share/conf/jfr/default.jfc line 516:
> 
>> 514: 
>> 515:     <event name="jdk.NativeMemoryUsage">
>> 516:       <setting name="enabled" control="gc-enabled-normal">true</setting>
> 
> gc-enabled-normal? Should this really be tied to a gc control? An NMT control to be introduced?

Since users need to pass a command line flag to enable the event, I think it can be on by default, and use included gc-enabled-normal

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From stuefe at openjdk.org  Wed Dec  7 14:03:11 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 7 Dec 2022 14:03:11 GMT
Subject: RFR: JDK-8296995: ostream should handle snprintf(3) errors in
 release builds [v3]
In-Reply-To: <lXBQPLCrniDiyp9OAfVdsHq3xVNsxxTWymy_1cSaiHg=.0f341fe2-7bcc-4640-bf2e-0f1883ee22e4@github.com>
References: <lXBQPLCrniDiyp9OAfVdsHq3xVNsxxTWymy_1cSaiHg=.0f341fe2-7bcc-4640-bf2e-0f1883ee22e4@github.com>
Message-ID: <Bdg6H0QXAZj8jk9vKoAn6UdW4TT5CvpfoGpdopvfaz4=.e6c2ea04-23d2-4fd5-b7fc-cccfda27963c@github.com>

> Small fix for a very unlikely problem. 
> 
> All streams in ostream.hpp end up using `os::snprintf()`, which uses `::vsnprintf()`. `vsnprintf(3)`can fail and return -1. 
> 
> The chance for this to happen is small. snprintf errors are usually encoding errors though not always (see third example at https://stackoverflow.com/questions/65334245/what-is-an-encoding-error-for-sprintf-that-should-return-1). I found "%ls" in one place in windows coding, so I am not sure we can always exclude the possibility of wide strings being used in our code base, or that of printing with outside-provided format strings.
> 
> In case of an error, we assert in debug builds but don't handle it in release. There, this situation gets misdiagnosed later as a buffer overflow because we cast the signedness of the result away (see `outputStream::do_vsnprintf()`). 
> 
> ---
> 
> The patch is trivial. The most exciting thing is the gtest, I guess.
> 
> In release builds, we now treat this condition as an empty string write. I considered printing a clear marker into the stream instead, e.g. "ENCODING ERROR", but ultimately did not do it.

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  feedback martin

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11160/files
  - new: https://git.openjdk.org/jdk/pull/11160/files/0e1236e1..086a6ec3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11160&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11160&range=01-02

  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11160.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11160/head:pull/11160

PR: https://git.openjdk.org/jdk/pull/11160

From stuefe at openjdk.org  Wed Dec  7 14:15:59 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 7 Dec 2022 14:15:59 GMT
Subject: RFR: JDK-8296995: ostream should handle snprintf(3) errors in
 release builds [v4]
In-Reply-To: <lXBQPLCrniDiyp9OAfVdsHq3xVNsxxTWymy_1cSaiHg=.0f341fe2-7bcc-4640-bf2e-0f1883ee22e4@github.com>
References: <lXBQPLCrniDiyp9OAfVdsHq3xVNsxxTWymy_1cSaiHg=.0f341fe2-7bcc-4640-bf2e-0f1883ee22e4@github.com>
Message-ID: <u6OdTYGrgAOLV8wQH31tEWUFyZ5lwTqHy3T-p-LIBWw=.e018a885-4a1c-4a01-b2ad-df99dd64dc26@github.com>

> Small fix for a very unlikely problem. 
> 
> All streams in ostream.hpp end up using `os::snprintf()`, which uses `::vsnprintf()`. `vsnprintf(3)`can fail and return -1. 
> 
> The chance for this to happen is small. snprintf errors are usually encoding errors though not always (see third example at https://stackoverflow.com/questions/65334245/what-is-an-encoding-error-for-sprintf-that-should-return-1). I found "%ls" in one place in windows coding, so I am not sure we can always exclude the possibility of wide strings being used in our code base, or that of printing with outside-provided format strings.
> 
> In case of an error, we assert in debug builds but don't handle it in release. There, this situation gets misdiagnosed later as a buffer overflow because we cast the signedness of the result away (see `outputStream::do_vsnprintf()`). 
> 
> ---
> 
> The patch is trivial. The most exciting thing is the gtest, I guess.
> 
> In release builds, we now treat this condition as an empty string write. I considered printing a clear marker into the stream instead, e.g. "ENCODING ERROR", but ultimately did not do it.

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  fix copyright

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11160/files
  - new: https://git.openjdk.org/jdk/pull/11160/files/086a6ec3..b41f13d4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11160&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11160&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11160.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11160/head:pull/11160

PR: https://git.openjdk.org/jdk/pull/11160

From stuefe at openjdk.org  Wed Dec  7 14:16:00 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 7 Dec 2022 14:16:00 GMT
Subject: RFR: JDK-8296995: ostream should handle snprintf(3) errors in
 release builds [v3]
In-Reply-To: <vIQ3eUEJ4hkN9FFfrZ_b_0WRxKqIaU86nIFfx_LQsn0=.60c05a1b-8b4f-4aa5-99bf-8892cdf2c950@github.com>
References: <lXBQPLCrniDiyp9OAfVdsHq3xVNsxxTWymy_1cSaiHg=.0f341fe2-7bcc-4640-bf2e-0f1883ee22e4@github.com>
 <Bdg6H0QXAZj8jk9vKoAn6UdW4TT5CvpfoGpdopvfaz4=.e6c2ea04-23d2-4fd5-b7fc-cccfda27963c@github.com>
 <vIQ3eUEJ4hkN9FFfrZ_b_0WRxKqIaU86nIFfx_LQsn0=.60c05a1b-8b4f-4aa5-99bf-8892cdf2c950@github.com>
Message-ID: <piDBbQUQ7KGq8FhqhG_frM6HV4g-HRe87f5UZ5wYJPE=.f4400396-60aa-4836-8bd7-3f2debb7a2b9@github.com>

On Wed, 7 Dec 2022 14:02:33 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Thanks for the update! LGTM. Please update the test's Copyright header as requested by Matthias.

Thanks! I missed Matthias note, thanks for reminding me.

-------------

PR: https://git.openjdk.org/jdk/pull/11160

From mgronlun at openjdk.org  Wed Dec  7 14:16:33 2022
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 7 Dec 2022 14:16:33 GMT
Subject: RFR: 8157023: Integrate NMT with JFR [v4]
In-Reply-To: <m_u3J5WSeZE3d7VatREoc1pbTkG4txNAmfZcRz1eTpc=.341a61ef-0381-40fe-b195-955c163949c8@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <m_u3J5WSeZE3d7VatREoc1pbTkG4txNAmfZcRz1eTpc=.341a61ef-0381-40fe-b195-955c163949c8@github.com>
Message-ID: <XDvoJ4Q8BIeM_c4ZcJR3rw1nhk_XScTe7AhpM7ay7QQ=.eb1c563f-a0ef-4489-bf3c-1c0c7e47e9c3@github.com>

On Tue, 6 Dec 2022 16:42:54 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Please review this enhancement to include NMT information in JFR recordings.
>> 
>> **Summary**
>> Native Memory Tracking summary information can be obtained from a running VM using `jcmd` if started with `-XX:NativeMemoryTracking=summary/detail`. Using `jcmd` requires you to run a separate process and to parse the output to get the needed information. This change adds JFR events for NMT information to enable additional ways to consume the NMT data.
>> 
>> There are two new events added:
>> * _NativeMemoryUsage_ - The total native memory usage.
>> * _NativeMemoryUsagePart_ - The native memory usage for each component.
>> 
>> These events are sent periodically and by default the interval is 1s. This can of course be discussed, but that is the staring point. When NMT is not enabled on events will be sent.
>> 
>> **Testing**
>> * Added a simple test to verify that the events are sent as expected depending on if NMT is enabled or not.
>> * Mach5 sanity testing
>
> Stefan Johansson has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Rename the files
>  - Renaming and updating comments
>  - tstuefe review - no rename

test/jdk/jdk/jfr/event/runtime/TestNativeMemoryUsageEvents.java line 97:

> 95:     private static void generateEvents(Recording recording) throws Exception {
> 96:         // Enable the two types of events for "everyChunk", it will give
> 97:         // an event att the beginning of the chunk as well as the end.

"att" -> "at"

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From mgronlun at openjdk.org  Wed Dec  7 14:23:42 2022
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 7 Dec 2022 14:23:42 GMT
Subject: RFR: 8298175: JFR: Common timestamp for periodic events [v2]
In-Reply-To: <8flzSdzQU0xymX-UKIw3P5VJtgmV2Nkg3YRMBnHw5Ac=.c67497f7-0d43-42bb-a06b-d3c116b14e02@github.com>
References: <4bP-aYZidz-BbflACIv0qfc_8dpSNF6INArPJJ9wJQo=.a57084a7-d403-4975-a524-f33a2f0cf1fa@github.com>
 <8flzSdzQU0xymX-UKIw3P5VJtgmV2Nkg3YRMBnHw5Ac=.c67497f7-0d43-42bb-a06b-d3c116b14e02@github.com>
Message-ID: <qDE8hzR3kJgt4Qo9f37XdqgurfODoRcpV7ZCkgKLcBA=.97b2eb2d-62a0-4746-9b64-bf3ab97a01fc@github.com>

On Wed, 7 Dec 2022 07:07:13 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of infrastructure that makes it easier to write periodic events with the same timestamp.
>> 
>> Testing: jdk/jdk/jfr + tier1 + tier2
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update request loop

Marked as reviewed by mgronlun (Reviewer).

src/jdk.jfr/share/classes/jdk/jfr/internal/RequestEngine.java line 210:

> 208:     private static long run_requests(Collection<RequestHook> entries, long eventTimestamp) {
> 209:         long last = lastTimeMillis;
> 210:         // The interval for periodic events are typically at least 1 s, so

"are" -> "is"

-------------

PR: https://git.openjdk.org/jdk/pull/11541

From sjohanss at openjdk.org  Wed Dec  7 14:51:05 2022
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Wed, 7 Dec 2022 14:51:05 GMT
Subject: RFR: 8157023: Integrate NMT with JFR [v4]
In-Reply-To: <eANdeA06DRBZQDXkpn_dNwBWnYmYVtqWeGmSeZDVVTg=.14c01ac2-a0fd-4638-abbc-eca31a38b7a9@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <m_u3J5WSeZE3d7VatREoc1pbTkG4txNAmfZcRz1eTpc=.341a61ef-0381-40fe-b195-955c163949c8@github.com>
 <eANdeA06DRBZQDXkpn_dNwBWnYmYVtqWeGmSeZDVVTg=.14c01ac2-a0fd-4638-abbc-eca31a38b7a9@github.com>
Message-ID: <WkwdsgUJGSdcCBZ5mkrfRtCy_XhBo71T11Kd6d6-w_o=.f68f60a7-c28c-495e-bb8e-6f49b5f89b7b@github.com>

On Wed, 7 Dec 2022 13:21:42 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Stefan Johansson has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Rename the files
>>  - Renaming and updating comments
>>  - tstuefe review - no rename
>
> src/hotspot/share/jfr/metadata/metadata.xml line 711:
> 
>> 709:   <Event name="NativeMemoryUsage" category="Java Virtual Machine, Memory" label="Native Memory Usage Per Type"
>> 710:     description="Native memory usage for a given memory type in the JVM" period="everyChunk">
>> 711:     <Field type="string" name="type" label="Memory Type" description="Type used for the native memory allocation" />
> 
> Suggest turning this type "string" into a JFR-constant type, like "JfrNMTType" to only send id's, instead of the entire strings. Can be done in a follow-up change.

I prefer to do this at a later point, created [JDK-8298278](https://bugs.openjdk.org/browse/JDK-8298278) to track this.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From sjohanss at openjdk.org  Wed Dec  7 14:51:09 2022
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Wed, 7 Dec 2022 14:51:09 GMT
Subject: RFR: 8157023: Integrate NMT with JFR [v4]
In-Reply-To: <WygDMFUxzsVidG-JcjFdIrq5xoDdANvDaCPxSUBNzf0=.302b26cc-1197-4ba7-b07f-7da0a62945fc@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <m_u3J5WSeZE3d7VatREoc1pbTkG4txNAmfZcRz1eTpc=.341a61ef-0381-40fe-b195-955c163949c8@github.com>
 <eANdeA06DRBZQDXkpn_dNwBWnYmYVtqWeGmSeZDVVTg=.14c01ac2-a0fd-4638-abbc-eca31a38b7a9@github.com>
 <WygDMFUxzsVidG-JcjFdIrq5xoDdANvDaCPxSUBNzf0=.302b26cc-1197-4ba7-b07f-7da0a62945fc@github.com>
Message-ID: <ASAoP_VAzewa6ZFfxANfskDgenIjFBKYc7HDGEh2cd0=.28e0a856-4e3c-48b7-888b-9ccd1991acc4@github.com>

On Wed, 7 Dec 2022 13:58:18 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> src/jdk.jfr/share/conf/jfr/default.jfc line 516:
>> 
>>> 514: 
>>> 515:     <event name="jdk.NativeMemoryUsage">
>>> 516:       <setting name="enabled" control="gc-enabled-normal">true</setting>
>> 
>> gc-enabled-normal? Should this really be tied to a gc control? An NMT control to be introduced?
>
> Since users need to pass a command line flag to enable the event, I think it can be on by default, and use included gc-enabled-normal

Talked to @egahlin about this and maybe not optimal to tie it to a gc control, but fine for now. This does not affect the VM, just JMC.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From sjohanss at openjdk.org  Wed Dec  7 15:05:14 2022
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Wed, 7 Dec 2022 15:05:14 GMT
Subject: RFR: 8157023: Integrate NMT with JFR [v4]
In-Reply-To: <eANdeA06DRBZQDXkpn_dNwBWnYmYVtqWeGmSeZDVVTg=.14c01ac2-a0fd-4638-abbc-eca31a38b7a9@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <m_u3J5WSeZE3d7VatREoc1pbTkG4txNAmfZcRz1eTpc=.341a61ef-0381-40fe-b195-955c163949c8@github.com>
 <eANdeA06DRBZQDXkpn_dNwBWnYmYVtqWeGmSeZDVVTg=.14c01ac2-a0fd-4638-abbc-eca31a38b7a9@github.com>
Message-ID: <8XKAonknsJVZ9sOcrVP-xFuuYVKr1e50-MeBeQJy_Is=.2c5e6a3c-63bb-4fff-b803-f8db9a1c6c6d@github.com>

On Wed, 7 Dec 2022 13:45:43 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Stefan Johansson has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Rename the files
>>  - Renaming and updating comments
>>  - tstuefe review - no rename
>
> src/hotspot/share/services/memJfrReporter.hpp line 45:
> 
>> 43: // Helper class to avoid refreshing the NMTUsage to often and allow
>> 44: // the two JFR events to use the same data.
>> 45: class MemJFRCurrentUsage : public AllStatic {
> 
> Move to .cpp file to because only used internally. Does not even have to be a class, can only be static fields and accessors. But no big deal, at your will.

Moved it but kept the class structure to better show how things hang together :)

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From sjohanss at openjdk.org  Wed Dec  7 15:11:58 2022
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Wed, 7 Dec 2022 15:11:58 GMT
Subject: RFR: 8157023: Integrate NMT with JFR [v5]
In-Reply-To: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
Message-ID: <5OWgF37Jj3kVRSDHCv1MxSbMnLEDtgoK9CiAxqJPBVI=.3e4e72f3-e8fd-4be3-a032-2b281058fecc@github.com>

> Please review this enhancement to include NMT information in JFR recordings.
> 
> **Summary**
> Native Memory Tracking summary information can be obtained from a running VM using `jcmd` if started with `-XX:NativeMemoryTracking=summary/detail`. Using `jcmd` requires you to run a separate process and to parse the output to get the needed information. This change adds JFR events for NMT information to enable additional ways to consume the NMT data.
> 
> There are two new events added:
> * _NativeMemoryUsage_ - The total native memory usage.
> * _NativeMemoryUsagePart_ - The native memory usage for each component.
> 
> These events are sent periodically and by default the interval is 1s. This can of course be discussed, but that is the staring point. When NMT is not enabled on events will be sent.
> 
> **Testing**
> * Added a simple test to verify that the events are sent as expected depending on if NMT is enabled or not.
> * Mach5 sanity testing

Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision:

  mgonlun review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11449/files
  - new: https://git.openjdk.org/jdk/pull/11449/files/0b3668bf..2335255e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11449&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11449&range=03-04

  Stats: 37 lines in 3 files changed: 16 ins; 16 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/11449.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11449/head:pull/11449

PR: https://git.openjdk.org/jdk/pull/11449

From mgronlun at openjdk.org  Wed Dec  7 15:21:06 2022
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 7 Dec 2022 15:21:06 GMT
Subject: RFR: 8157023: Integrate NMT with JFR [v5]
In-Reply-To: <5OWgF37Jj3kVRSDHCv1MxSbMnLEDtgoK9CiAxqJPBVI=.3e4e72f3-e8fd-4be3-a032-2b281058fecc@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <5OWgF37Jj3kVRSDHCv1MxSbMnLEDtgoK9CiAxqJPBVI=.3e4e72f3-e8fd-4be3-a032-2b281058fecc@github.com>
Message-ID: <yVPbTGNR-Kvy8ygvgiGQ34lmNjUpql93deAkMvcyoc0=.c247ce29-0d3c-418f-8d20-660d81f44d8d@github.com>

On Wed, 7 Dec 2022 15:11:58 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Please review this enhancement to include NMT information in JFR recordings.
>> 
>> **Summary**
>> Native Memory Tracking summary information can be obtained from a running VM using `jcmd` if started with `-XX:NativeMemoryTracking=summary/detail`. Using `jcmd` requires you to run a separate process and to parse the output to get the needed information. This change adds JFR events for NMT information to enable additional ways to consume the NMT data.
>> 
>> There are two new events added:
>> * _NativeMemoryUsage_ - The total native memory usage.
>> * _NativeMemoryUsagePart_ - The native memory usage for each component.
>> 
>> These events are sent periodically and by default the interval is 1s. This can of course be discussed, but that is the staring point. When NMT is not enabled on events will be sent.
>> 
>> **Testing**
>> * Added a simple test to verify that the events are sent as expected depending on if NMT is enabled or not.
>> * Mach5 sanity testing
>
> Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   mgonlun review

Marked as reviewed by mgronlun (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From sjohanss at openjdk.org  Wed Dec  7 15:21:07 2022
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Wed, 7 Dec 2022 15:21:07 GMT
Subject: RFR: 8157023: Integrate NMT with JFR [v5]
In-Reply-To: <yVPbTGNR-Kvy8ygvgiGQ34lmNjUpql93deAkMvcyoc0=.c247ce29-0d3c-418f-8d20-660d81f44d8d@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <5OWgF37Jj3kVRSDHCv1MxSbMnLEDtgoK9CiAxqJPBVI=.3e4e72f3-e8fd-4be3-a032-2b281058fecc@github.com>
 <yVPbTGNR-Kvy8ygvgiGQ34lmNjUpql93deAkMvcyoc0=.c247ce29-0d3c-418f-8d20-660d81f44d8d@github.com>
Message-ID: <fKoBI9H5n58iphdxxg-PhCncA76mBtIr7l4Qc51DZ1g=.718a3a69-670f-4998-a166-ae46db2d1309@github.com>

On Wed, 7 Dec 2022 15:16:22 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   mgonlun review
>
> Marked as reviewed by mgronlun (Reviewer).

Thanks for the review @mgronlun, will wait a bit for GH actions and some other testing to finish before integrating.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From egahlin at openjdk.org  Wed Dec  7 15:25:03 2022
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 7 Dec 2022 15:25:03 GMT
Subject: RFR: 8298175: JFR: Common timestamp for periodic events [v3]
In-Reply-To: <4bP-aYZidz-BbflACIv0qfc_8dpSNF6INArPJJ9wJQo=.a57084a7-d403-4975-a524-f33a2f0cf1fa@github.com>
References: <4bP-aYZidz-BbflACIv0qfc_8dpSNF6INArPJJ9wJQo=.a57084a7-d403-4975-a524-f33a2f0cf1fa@github.com>
Message-ID: <S19qtsFb-OnGunS1zw1mL_VLlB5R6T3AVVnDmQtrfEk=.1cb28d27-59e8-4383-b99e-4ae6e525fb2e@github.com>

> Could I have review of infrastructure that makes it easier to write periodic events with the same timestamp.
> 
> Testing: jdk/jdk/jfr + tier1 + tier2
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:

  Add support for periodic types

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11541/files
  - new: https://git.openjdk.org/jdk/pull/11541/files/605f1290..638803b2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11541&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11541&range=01-02

  Stats: 28 lines in 5 files changed: 13 ins; 0 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/11541.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11541/head:pull/11541

PR: https://git.openjdk.org/jdk/pull/11541

From egahlin at openjdk.org  Wed Dec  7 15:33:12 2022
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 7 Dec 2022 15:33:12 GMT
Subject: RFR: 8157023: Integrate NMT with JFR [v5]
In-Reply-To: <5OWgF37Jj3kVRSDHCv1MxSbMnLEDtgoK9CiAxqJPBVI=.3e4e72f3-e8fd-4be3-a032-2b281058fecc@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <5OWgF37Jj3kVRSDHCv1MxSbMnLEDtgoK9CiAxqJPBVI=.3e4e72f3-e8fd-4be3-a032-2b281058fecc@github.com>
Message-ID: <Ns4UDeT8NgY7NhI0lIq-H7Rf7s85cX8ZhnLnr621wb0=.938fad54-b9f6-473f-ba4e-fbf633ed71f3@github.com>

On Wed, 7 Dec 2022 15:11:58 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Please review this enhancement to include NMT information in JFR recordings.
>> 
>> **Summary**
>> Native Memory Tracking summary information can be obtained from a running VM using `jcmd` if started with `-XX:NativeMemoryTracking=summary/detail`. Using `jcmd` requires you to run a separate process and to parse the output to get the needed information. This change adds JFR events for NMT information to enable additional ways to consume the NMT data.
>> 
>> There are two new events added:
>> * _NativeMemoryUsage_ - The total native memory usage.
>> * _NativeMemoryUsagePart_ - The native memory usage for each component.
>> 
>> These events are sent periodically and by default the interval is 1s. This can of course be discussed, but that is the staring point. When NMT is not enabled on events will be sent.
>> 
>> **Testing**
>> * Added a simple test to verify that the events are sent as expected depending on if NMT is enabled or not.
>> * Mach5 sanity testing
>
> Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   mgonlun review

Marked as reviewed by egahlin (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From sjohanss at openjdk.org  Wed Dec  7 15:36:47 2022
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Wed, 7 Dec 2022 15:36:47 GMT
Subject: RFR: 8157023: Integrate NMT with JFR [v5]
In-Reply-To: <7w283X4Kb24M6A0ztXtE3FyolIvQkYJfqpXAsJjAxIA=.52649f81-3c7e-4deb-8722-fa6bb648eea2@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <5etH99SkJXLDG9IeW1kNIjvCWU-Ydhbg5JBMZM34tFg=.7401c117-7dbb-4ea0-89e1-31bbe6f0d78b@github.com>
 <l5PaDcRr8Uxk2KXhvfKP1FTFbVD2QIosVOHqVuXaun0=.925a675b-f986-451c-a92c-694c2d98d9ed@github.com>
 <IBlRVDETFl0xpVvcUKPF0Spko2Wgm7ScqRlg0OgmNT4=.a1c25637-1940-432e-a834-0e8c83272be2@github.com>
 <WkUY7sW-crChZ60T5dl_ZOFkSwKXGJ7Xzjs4oW8USA8=.05fedd85-edd4-4a85-bc74-010d27e90c16@github.com>
 <LU18LkapNzS9PxwR6stjmJQ5rJ6CbaljYzWPRNAaj-4=.773b12c7-d536-426a-ac96-67a9e060d634@github.com>
 <CAr0STfVbRpPLZ-Z2Hv-p6MM2rPP5yCKbOleMIDjmII=.122bd69e-6e78-4ab6-8318-7c4a9c6b40f0@github.com>
 <7w283X4Kb24M6A0ztXtE3FyolIvQkYJfqpXAsJjAxIA=.52649f81-3c7e-4deb-8722-fa6bb648eea2@github.com>
Message-ID: <xiZxFlBspM4w79SX2iu6jA9EVdtzsSx-fS_KxVod9PE=.f704cfe0-5406-4b91-a184-4e85646d7869@github.com>

On Fri, 2 Dec 2022 17:16:19 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>>> > I think these events will be mostly useful for Hotspot developers and support engineers.
>>> 
>>> I respectfully disagree on that. In a container world, it's common to be hit by OOMKill when sizing the JVM correctly. Most people think only by the Java heap size, and forget about the native part. And when you do, there is few control or possible way to troubleshoot why the native part is going off what you expect. The only useful tool in this situation is NMT to be able to triage which space is the culprit. see https://blog.arkey.fr/2020/11/30/off-heap-reconnaissance/
>> 
>> Hi @jpbempel,
>> 
>> this is currently being discussed as part of https://mail.openjdk.org/pipermail/core-libs-dev/2022-December/097391.html and https://mail.openjdk.org/pipermail/core-libs-dev/2022-November/096369.html. Feel free to take part! I am especially interested in seeing concrete examples where NMT did help customers to lower memory footprint.
>> 
>> Cheers, Thomas
>
>> I respectfully disagree on that. In a container world, it's common to be hit by OOMKill when sizing the JVM correctly. Most people think only by the Java heap size, and forget about the native part. And when you do, there is few control or possible way to troubleshoot why the native part is going off what you expect. The only useful tool in this situation is NMT to be able to triage which space is the culprit. see https://blog.arkey.fr/2020/11/30/off-heap-reconnaissance/
> 
> Thanks, good to know.

Thanks for the review @egahlin

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From stuefe at openjdk.org  Wed Dec  7 15:44:13 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 7 Dec 2022 15:44:13 GMT
Subject: RFR: 8157023: Integrate NMT with JFR [v5]
In-Reply-To: <5OWgF37Jj3kVRSDHCv1MxSbMnLEDtgoK9CiAxqJPBVI=.3e4e72f3-e8fd-4be3-a032-2b281058fecc@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <5OWgF37Jj3kVRSDHCv1MxSbMnLEDtgoK9CiAxqJPBVI=.3e4e72f3-e8fd-4be3-a032-2b281058fecc@github.com>
Message-ID: <86tHRbLAmxAQXlaDnOFt2CYv93zDxDbiSnzFBZK3Z68=.79d6da4e-e310-47dc-83c2-2a04d8f5930e@github.com>

On Wed, 7 Dec 2022 15:11:58 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Please review this enhancement to include NMT information in JFR recordings.
>> 
>> **Summary**
>> Native Memory Tracking summary information can be obtained from a running VM using `jcmd` if started with `-XX:NativeMemoryTracking=summary/detail`. Using `jcmd` requires you to run a separate process and to parse the output to get the needed information. This change adds JFR events for NMT information to enable additional ways to consume the NMT data.
>> 
>> There are two new events added:
>> * _NativeMemoryUsage_ - The total native memory usage.
>> * _NativeMemoryUsagePart_ - The native memory usage for each component.
>> 
>> These events are sent periodically and by default the interval is 1s. This can of course be discussed, but that is the staring point. When NMT is not enabled on events will be sent.
>> 
>> **Testing**
>> * Added a simple test to verify that the events are sent as expected depending on if NMT is enabled or not.
>> * Mach5 sanity testing
>
> Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   mgonlun review

Still good. I like that the usage classes moved out of the interface.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From lbourges at openjdk.org  Wed Dec  7 16:02:21 2022
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Wed, 7 Dec 2022 16:02:21 GMT
Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v17]
In-Reply-To: <wtfe3m7FrVWssfUYna5S0oWNL6Xhz4UQRb-4V2tvvmc=.3356deec-bbe2-4372-ac3a-2cdc620fae67@github.com>
References: <fWd_NIunUhDXwy8uZSno90GC-PM8pFCey-pAMxxO0rI=.0fede0e4-1438-4321-bc8d-d11565389cae@github.com>
 <v-LA3R9EgJGM_01c54w4H8ahI7BGPuKGSSpj2Ms7L84=.8dac50eb-2131-4413-a05f-be2e5db9eff0@github.com>
 <wtfe3m7FrVWssfUYna5S0oWNL6Xhz4UQRb-4V2tvvmc=.3356deec-bbe2-4372-ac3a-2cdc620fae67@github.com>
Message-ID: <D2GcLWUTfyqFoBuUa9JXarKRz_j1xwjNSoyBTfs6PE4=.b52f7b27-acf3-40c1-8fd1-8afa2003f9bd@github.com>

On Wed, 7 Dec 2022 08:35:52 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comment for snprintf_checked
>
> src/hotspot/os/bsd/attachListener_bsd.cpp line 260:
> 
>> 258:   // name ("load", "datadump", ...), and <arg> is an argument
>> 259:   int expected_str_count = 2 + AttachOperation::arg_count_max;
>> 260:   const int max_len = (ver_str_len + 1) + (AttachOperation::name_length_max + 1) +
> 
> This makes `max_len` a runtime variable, before it was a compile time constant. Below, we use it to create the buf array. IIRC creating an array with a variable runtime length is a non-standard compiler extension. I am surprised this even builds.

better to keep sizeof(ver_str) here (const)

-------------

PR: https://git.openjdk.org/jdk/pull/11115

From luhenry at openjdk.org  Wed Dec  7 16:41:07 2022
From: luhenry at openjdk.org (Ludovic Henry)
Date: Wed, 7 Dec 2022 16:41:07 GMT
Subject: RFR: 8298075: RISC-V: Implement post-call NOPs [v6]
In-Reply-To: <ORZHK2_0RTYb9rtYkX_JXTTcex_LryeoYT3rk6mrIxs=.6743e193-2cc6-49b9-a896-befd73206072@github.com>
References: <inZ_2fowZZQz0C53E2h4zURoyQIwZcJaBfhC4zwFyb8=.cbc7e361-9bad-48ce-b6d4-c3a8fe2e1cba@github.com>
 <ORZHK2_0RTYb9rtYkX_JXTTcex_LryeoYT3rk6mrIxs=.6743e193-2cc6-49b9-a896-befd73206072@github.com>
Message-ID: <ctJfJjsdze_9qgUOgf4-E3mnrhPtm_tgbwgQEOR9bEE=.3c6b5567-b374-42ff-8c6e-be408548aaf8@github.com>

On Tue, 6 Dec 2022 10:41:59 GMT, Xiaolin Zheng <xlinzheng at openjdk.org> wrote:

>> Same as [JDK-8287567](https://bugs.openjdk.org/browse/JDK-8287567), we need to implement post-call NOPs in the RISC-V backend.
>> 
>> We use `li32` to implement it. `li32` will signed-extend the loaded imm32 to a 64-bit register. However, our reader `NativePostCallNop::displacement()` only needs the low 32 bits value so we are safe.
>> 
>> The current post-call NOP is like:
>> 
>> nop                    (always 4-byte, used for deoptimization, please see `NativePostCallNop::make_deopt()`)
>> lui zr, <imm20>        (always 4-byte)
>> addiw zr, zr, <imm12>  (always 4-byte)
>> 
>> 
>> The code size here is the same as the AArch64 counterpart, 12 bytes.
>> 
>> The logic of setting the post-call NOP displacement is at `install_post_call_nop_displacement()` [1] when nmethods are being installed, so no one is running post-call NOPs when we are patching them.
>> 
>> One can check them by directly using `java --enable-preview -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly`.
>> 
>> Tested hotspot tier1~4 and jdk tier1~4 using fastdebug by force turning on `--enable-preview`; SPECjbb2015 and dacapo were tested without regressions found. Skynet JMH benchmark seems to have an improvement from `8662ms/op -> 8495ms/op`.
>> 
>> Thanks,
>> Xiaolin
>> 
>> [1] https://github.com/openjdk/jdk/blob/b49fd920b6690a8b828c85e45c10e5c4c54d2022/src/hotspot/share/code/nmethod.cpp#L1078-L1107
>
> Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Plural form...

Marked as reviewed by luhenry (Committer).

-------------

PR: https://git.openjdk.org/jdk/pull/11502

From stuefe at openjdk.org  Wed Dec  7 17:57:36 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 7 Dec 2022 17:57:36 GMT
Subject: RFR: JDK-8298298: NMT: count deltas are printed with 32-bit signed
 size
Message-ID: <ZbO2OJmcF2KfCodEuccCdLaT9uqDahRmqn8d3juth5A=.f5c5704b-0a92-4307-b5cd-b37516140eaa@github.com>

Deltas for counts in NMT differential reports are shown as signed int, restricting them to +-2g. So on large 64-bit machines they can conceivably overflow. These counts are number of malloc blocks, or number of classes, or threads.

Patch changes delta printing from int to ssize_t.

Note that I don't worry about overflowing SSIZE_MIN|MAX here. These are counts of existing things (malloc blocks, classes etc) and we just cannot have that many things. Same is true for 32-bit, where ssize_t is int: can never overflow for any of the used counters, and if it does, its an accounting error.

Note we have the same problem with diff sizes. I expect [8281213](https://bugs.openjdk.org/browse/JDK-8281213) to fix that.

-------------

Commit messages:
 - JDK-8298298-nmt-count-deltas-32-bit

Changes: https://git.openjdk.org/jdk/pull/11568/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11568&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298298
  Stats: 15 lines in 3 files changed: 8 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/11568.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11568/head:pull/11568

PR: https://git.openjdk.org/jdk/pull/11568

From stuefe at openjdk.org  Wed Dec  7 17:57:37 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 7 Dec 2022 17:57:37 GMT
Subject: RFR: JDK-8298298: NMT: count deltas are printed with 32-bit signed
 size
In-Reply-To: <ZbO2OJmcF2KfCodEuccCdLaT9uqDahRmqn8d3juth5A=.f5c5704b-0a92-4307-b5cd-b37516140eaa@github.com>
References: <ZbO2OJmcF2KfCodEuccCdLaT9uqDahRmqn8d3juth5A=.f5c5704b-0a92-4307-b5cd-b37516140eaa@github.com>
Message-ID: <WOs-_Ujk3z-drqEND6rcjvta5G4fLZ4tUwVGoljRUcA=.f079d8b5-06bf-4f57-8db4-0dffdb30df1e@github.com>

On Wed, 7 Dec 2022 17:10:18 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Deltas for counts in NMT differential reports are shown as signed int, restricting them to +-2g. So on large 64-bit machines they can conceivably overflow. These counts are number of malloc blocks, or number of classes, or threads.
> 
> Patch changes delta printing from int to ssize_t.
> 
> Note that I don't worry about overflowing SSIZE_MIN|MAX here. These are counts of existing things (malloc blocks, classes etc) and we just cannot have that many things. Same is true for 32-bit, where ssize_t is int: can never overflow for any of the used counters, and if it does, its an accounting error.
> 
> Note we have the same problem with diff sizes. I expect [8281213](https://bugs.openjdk.org/browse/JDK-8281213) to fix that.

Tested: fastdebug and release for 32-bit/64-bit, runtime/NMT and NMT gtests

-------------

PR: https://git.openjdk.org/jdk/pull/11568

From alanb at openjdk.org  Wed Dec  7 18:47:06 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Dec 2022 18:47:06 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v6]
In-Reply-To: <7f0PjG00BGhLCA3Kjlohhp3YGB_Xv8BPexToz66PxWc=.cb042f58-79b2-4c80-a5d4-245e95227858@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
 <7f0PjG00BGhLCA3Kjlohhp3YGB_Xv8BPexToz66PxWc=.cb042f58-79b2-4c80-a5d4-245e95227858@github.com>
Message-ID: <NOQNyJbhwHflQHgEMtkIZnh7FJ4K8Q095DYxACb30yg=.47ecac25-789b-4b9a-99be-7d40eeadcd2c@github.com>

On Tue, 6 Dec 2022 16:06:34 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Libgraal is compiled ahead of time and should not need any JVMCI Java code to be dynamically loaded at runtime. Prior to this PR, this is not the case due to:
>> 
>> * Code to copy system properties from the HotSpot heap into the libgraal heap. This is in `jdk.vm.ci.services.Services.initializeSavedProperties(byte[])` and `jdk.vm.ci.services.Services.serializeSavedProperties()`. This code should be moved to `java.base/jdk.internal.vm.VMSupport`.
>> * Code to translate exceptions from the HotSpot heap into the libgraal heap and vice versa. This code should be moved from `jdk.internal.vm.ci//jdk.vm.ci.hotspot.TranslatedException` to `java.base/jdk.internal.vm.VMSupport`.
>> 
>> This PR makes the above changes. As a result, it's possible to build a JDK image that includes (and uses) libgraal but does not include `jdk.internal.vm.ci` or `jdk.internal.vm.compiler`. This both reduces footprint and better isolates the JAVMCI and the Graal compiler as accessing these components from Java code is now impossible.
>
> Doug Simon has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - formatting to avoid very long lines [skip ci]
>  - removed debug code [skip ci]
>  - clarify Properties filtering [skip ci]
>  - remove debug code [skip ci]

src/java.base/share/classes/jdk/internal/vm/TranslatedException.java line 128:

> 126:         // Try create with reflection first.
> 127:         try {
> 128:             Class<?> cls = Class.forName(className);

A question about the Class.forName usage here. Class.forName uses the defining class loader of the current class so I'm wondering if the exceptions to be decoded are always of a type defined to the boot loader? jdk.internal.vm.ci is defined to the boot loader so this code hasn't really changed, it's just "new" to java.base in this PR.

-------------

PR: https://git.openjdk.org/jdk/pull/11513

From kvn at openjdk.org  Wed Dec  7 18:47:16 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 7 Dec 2022 18:47:16 GMT
Subject: RFR: 8292289: [vectorapi] Improve the implementation of
 VectorTestNode [v14]
In-Reply-To: <Jo8mnLoA_9Pb8TzocN6zG5s2PGGVxS53s6XP_5CasLo=.de864d1a-51b5-4ceb-b12d-1d20e34735d7@github.com>
References: <IcR6eOr6iM1b9B1I1zUQnI2J9hQAmdSRHYc9CdIGW5E=.3b8dd64d-2eff-4659-b75a-81c4b008e41a@github.com>
 <Jo8mnLoA_9Pb8TzocN6zG5s2PGGVxS53s6XP_5CasLo=.de864d1a-51b5-4ceb-b12d-1d20e34735d7@github.com>
Message-ID: <MeWOERLVkAl7rrsPqAFR23UeiLCntkyPM5jqerJXtEU=.1d987dbb-9b2b-4d4b-811e-47b5f46f635a@github.com>

On Tue, 6 Dec 2022 14:24:39 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> This patch modifies the node generation of `VectorSupport::test` to emit a `CMoveINode`, which is picked up by `BoolNode::Ideal(PhaseGVN*, bool)` to connect the `VectorTestNode` directly to the `BoolNode`, removing the redundant operations of materialising the test result in a GP register and do a `CmpI` to get back the flags. As a result, `VectorMask<T>::alltrue` is compiled into machine codes:
>> 
>>         vptest xmm0, xmm1
>>         jb if_true
>>     if_false:
>> 
>> instead of:
>> 
>>         vptest xmm0, xmm1
>>         setb r10
>>         movzbl r10
>>         testl r10
>>         jne if_true
>>     if_false:
>> 
>> The results of `jdk.incubator.vector.ArrayMismatchBenchmark` shows noticeable improvements:
>> 
>>                                                                                        Before                  After
>>     Benchmark                                      Prefix    Size   Mode  Cnt       Score      Error       Score     Error    Units  Change
>>     ArrayMismatchBenchmark.mismatchVectorByte         0.5       9  thrpt   10  217345.383 ? 8316.444  222279.381 ? 2660.983  ops/ms   +2.3%
>>     ArrayMismatchBenchmark.mismatchVectorByte         0.5     257  thrpt   10  113918.406 ? 1618.836  116268.691 ? 1291.899  ops/ms   +2.1%
>>     ArrayMismatchBenchmark.mismatchVectorByte         0.5  100000  thrpt   10     702.066 ?   72.862     797.806 ?   16.429  ops/ms  +13.6%
>>     ArrayMismatchBenchmark.mismatchVectorByte         1.0       9  thrpt   10  146096.564 ? 2401.258  145338.910 ?  687.453  ops/ms   -0.5%
>>     ArrayMismatchBenchmark.mismatchVectorByte         1.0     257  thrpt   10   60598.181 ? 1259.397   69041.519 ? 1073.156  ops/ms  +13.9%
>>     ArrayMismatchBenchmark.mismatchVectorByte         1.0  100000  thrpt   10     316.814 ?   10.975     408.770 ?    5.281  ops/ms  +29.0%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       0.5       9  thrpt   10  195674.549 ? 1200.166  188482.433 ? 1872.076  ops/ms   -3.7%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       0.5     257  thrpt   10   44357.169 ?  473.013   42293.411 ? 2838.255  ops/ms   -4.7%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       0.5  100000  thrpt   10      68.199 ?    5.410      67.628 ?    3.241  ops/ms   -0.8%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       1.0       9  thrpt   10  107722.450 ? 1677.607  111060.400 ?  982.230  ops/ms   +3.1%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       1.0     257  thrpt   10   16692.645 ? 1002.599   21440.506 ? 1618.266  ops/ms  +28.4%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       1.0  100000  thrpt   10      32.984 ?    0.548      33.202 ?    2.365  ops/ms   +0.7%
>>     ArrayMismatchBenchmark.mismatchVectorInt          0.5       9  thrpt   10  335458.217 ? 3154.842  379944.254 ? 5703.134  ops/ms  +13.3%
>>     ArrayMismatchBenchmark.mismatchVectorInt          0.5     257  thrpt   10   58505.302 ?  786.312   56721.368 ? 2497.052  ops/ms   -3.0%
>>     ArrayMismatchBenchmark.mismatchVectorInt          0.5  100000  thrpt   10     133.037 ?   11.415     139.537 ?    4.667  ops/ms   +4.9%
>>     ArrayMismatchBenchmark.mismatchVectorInt          1.0       9  thrpt   10  117943.802 ? 2281.349  112409.365 ? 2110.055  ops/ms   -4.7%
>>     ArrayMismatchBenchmark.mismatchVectorInt          1.0     257  thrpt   10   27060.015 ?  795.619   33756.613 ?  826.533  ops/ms  +24.7%
>>     ArrayMismatchBenchmark.mismatchVectorInt          1.0  100000  thrpt   10      57.558 ?    8.927      66.951 ?    4.381  ops/ms  +16.3%
>>     ArrayMismatchBenchmark.mismatchVectorLong         0.5       9  thrpt   10  182963.715 ? 1042.497  182438.405 ? 2120.832  ops/ms   -0.3%
>>     ArrayMismatchBenchmark.mismatchVectorLong         0.5     257  thrpt   10   36672.215 ?  614.821   35397.398 ? 1609.235  ops/ms   -3.5%
>>     ArrayMismatchBenchmark.mismatchVectorLong         0.5  100000  thrpt   10      66.438 ?    2.142      65.427 ?    2.270  ops/ms   -1.5%
>>     ArrayMismatchBenchmark.mismatchVectorLong         1.0       9  thrpt   10  110393.047 ?  497.853  115165.845 ? 5381.674  ops/ms   +4.3%
>>     ArrayMismatchBenchmark.mismatchVectorLong         1.0     257  thrpt   10   14720.765 ?  661.350   19871.096 ?  201.464  ops/ms  +35.0%
>>     ArrayMismatchBenchmark.mismatchVectorLong         1.0  100000  thrpt   10      30.760 ?    0.821      31.933 ?    1.352  ops/ms   +3.8%
>> 
>> I have not been able to conduct throughout testing on AVX512 and Aarch64 so any help would be invaluable. Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix test

Rerunning DaCapo and Renaissance which shows some variations.

-------------

PR: https://git.openjdk.org/jdk/pull/9855

From alanb at openjdk.org  Wed Dec  7 18:47:09 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Dec 2022 18:47:09 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v5]
In-Reply-To: <YYb6ipJjooXfXoFyWhz_Sus76yoDgkB5OIKvFTsYsWA=.c1a15d4f-c6b1-4610-b110-dbab35b14667@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
 <kU-NHwhiGEJLa7-o38UCemcxhU8WR_ijQBMGOAknOTs=.57d0341c-30af-4c39-ab42-4278fdfb2e5d@github.com>
 <-vjDxNaafm1m5UERR31dFXH7jdljWTKzsDjntS8v6zs=.4c777f1e-695f-42de-a4b5-0cb0f332243c@github.com>
 <ZSSq3Pl4Nu-BlC_ccliJcYZ9j297sAFUoybpgBrw0Uo=.5aeec02c-d235-4e07-bb23-bc038d512221@github.com>
 <YYb6ipJjooXfXoFyWhz_Sus76yoDgkB5OIKvFTsYsWA=.c1a15d4f-c6b1-4610-b110-dbab35b14667@github.com>
Message-ID: <JNiF-VQnHQCFWGxrumE-PBNRklD7W4Sta9jIfucDBwY=.f55b3a62-6b23-4131-95ca-045617f4794b@github.com>

On Tue, 6 Dec 2022 16:50:47 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This parameter exists to allow a caller to pass in a `Properties` object that is guaranteed to have only String keys and so does not need the extra filtering done in this method. I'll refactor the code to make it clearer.
>
> Hopefully this makes it clearer: https://github.com/openjdk/jdk/pull/11513/commits/5c610798fe4eaed7efeb2eebcf1e5db47714caee

Thanks. I initially assumed it was done to support non-String key/values but it's actually an optimization because the save properties are always Strings.

-------------

PR: https://git.openjdk.org/jdk/pull/11513

From sjohanss at openjdk.org  Wed Dec  7 18:48:01 2022
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Wed, 7 Dec 2022 18:48:01 GMT
Subject: Integrated: 8157023: Integrate NMT with JFR
In-Reply-To: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
Message-ID: <uJN1l30HgCVEOLvRJWDHAF8_Sp1OA__CyXk_KR7-Y28=.bd87a32e-1de8-47a9-9db9-bf154f87a003@github.com>

On Thu, 1 Dec 2022 10:48:51 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> Please review this enhancement to include NMT information in JFR recordings.
> 
> **Summary**
> Native Memory Tracking summary information can be obtained from a running VM using `jcmd` if started with `-XX:NativeMemoryTracking=summary/detail`. Using `jcmd` requires you to run a separate process and to parse the output to get the needed information. This change adds JFR events for NMT information to enable additional ways to consume the NMT data.
> 
> There are two new events added:
> * _NativeMemoryUsage_ - The total native memory usage.
> * _NativeMemoryUsagePart_ - The native memory usage for each component.
> 
> These events are sent periodically and by default the interval is 1s. This can of course be discussed, but that is the staring point. When NMT is not enabled on events will be sent.
> 
> **Testing**
> * Added a simple test to verify that the events are sent as expected depending on if NMT is enabled or not.
> * Mach5 sanity testing

This pull request has now been integrated.

Changeset: 3b8c7ef8
Author:    Stefan Johansson <sjohanss at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3b8c7ef8e705764942c4f3df872e3e47021a37f4
Stats:     587 lines in 14 files changed: 579 ins; 5 del; 3 mod

8157023: Integrate NMT with JFR

Reviewed-by: stuefe, mgronlun, egahlin

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From alanb at openjdk.org  Wed Dec  7 18:47:04 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Dec 2022 18:47:04 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v5]
In-Reply-To: <ZSSq3Pl4Nu-BlC_ccliJcYZ9j297sAFUoybpgBrw0Uo=.5aeec02c-d235-4e07-bb23-bc038d512221@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
 <kU-NHwhiGEJLa7-o38UCemcxhU8WR_ijQBMGOAknOTs=.57d0341c-30af-4c39-ab42-4278fdfb2e5d@github.com>
 <-vjDxNaafm1m5UERR31dFXH7jdljWTKzsDjntS8v6zs=.4c777f1e-695f-42de-a4b5-0cb0f332243c@github.com>
 <ZSSq3Pl4Nu-BlC_ccliJcYZ9j297sAFUoybpgBrw0Uo=.5aeec02c-d235-4e07-bb23-bc038d512221@github.com>
Message-ID: <f_31mygaR5hzqOiPgVY0afF-4FgQbFmgf18PcNgpHPU=.065267c4-effa-41e3-80a1-52d25e63c3d4@github.com>

On Tue, 6 Dec 2022 15:44:04 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/vm/TranslatedException.java line 44:
>> 
>>> 42:  */
>>> 43: @SuppressWarnings("serial")
>>> 44: final class TranslatedException extends Exception {
>> 
>> Would it be possible to re-format this to avoid the wildly long (150+) lines? This seems to be moving jdk.vm.ci.hotspot.TranslatedException and hard to see what is going on.
>
> Is there some tool support for formatting Java source code to meet OpenJDK coding guidelines? Rather unfortunate that one has to do this manually and reviewers have to spend time manually checking it.

There isn't a code or agreed conventions. The cleanup in the latest version looks okay.

-------------

PR: https://git.openjdk.org/jdk/pull/11513

From dnsimon at openjdk.org  Wed Dec  7 19:33:05 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 7 Dec 2022 19:33:05 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v6]
In-Reply-To: <NOQNyJbhwHflQHgEMtkIZnh7FJ4K8Q095DYxACb30yg=.47ecac25-789b-4b9a-99be-7d40eeadcd2c@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
 <7f0PjG00BGhLCA3Kjlohhp3YGB_Xv8BPexToz66PxWc=.cb042f58-79b2-4c80-a5d4-245e95227858@github.com>
 <NOQNyJbhwHflQHgEMtkIZnh7FJ4K8Q095DYxACb30yg=.47ecac25-789b-4b9a-99be-7d40eeadcd2c@github.com>
Message-ID: <GNh8FuYL1GL-KBYgrCTaed6w5Q7jLBG3U_f6oVkAyG8=.6ae80825-2b1d-4f22-a6f1-0bcb783d90c2@github.com>

On Wed, 7 Dec 2022 18:42:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Doug Simon has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - formatting to avoid very long lines [skip ci]
>>  - removed debug code [skip ci]
>>  - clarify Properties filtering [skip ci]
>>  - remove debug code [skip ci]
>
> src/java.base/share/classes/jdk/internal/vm/TranslatedException.java line 128:
> 
>> 126:         // Try create with reflection first.
>> 127:         try {
>> 128:             Class<?> cls = Class.forName(className);
> 
> A question about the Class.forName usage here. Class.forName uses the defining class loader of the current class so I'm wondering if the exceptions to be decoded are always of a type defined to the boot loader? jdk.internal.vm.ci is defined to the boot loader so this code hasn't really changed, it's just "new" to java.base in this PR.

The exceptions can be of any type and defined by any loader. In the case that Class.forName fails, the name of the original exception type is shown as part of `TranslationException.toString()`. Combined with the stack trace, this has always been sufficient to understand the origin of an exception thrown on a HotSpot/libjvmci mixed stack.

-------------

PR: https://git.openjdk.org/jdk/pull/11513

From coleenp at openjdk.org  Wed Dec  7 19:35:44 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 7 Dec 2022 19:35:44 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data
In-Reply-To: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
Message-ID: <DEwFOGMJfmR4EmHepjV6veGEMsh69wfF8sDLCJreSKM=.e66a40f0-1cb8-41c0-9a32-0c50da9494cc@github.com>

On Tue, 6 Dec 2022 06:13:23 GMT, Justin King <jcking at openjdk.org> wrote:

> Resolve memory leak related to `MethodData::_extra_data_lock` in `Method::build_profiling_method_data` by defining `MethodData::release_C_heap_structures` and calling it where appropriate before deallocating `MethodData`.

No, do not make MetadataFactory::free_metadata call the destructor.  It might break other metadata that is passed to it.  It would require special consideration and redo the whole design of the thing.  Yes, the memory management is convoluted here.
The release_C_heap_structures() call is the right thing to do here.

-------------

PR: https://git.openjdk.org/jdk/pull/11526

From dnsimon at openjdk.org  Wed Dec  7 19:49:47 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 7 Dec 2022 19:49:47 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v7]
In-Reply-To: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
Message-ID: <Epv-jPCuClG7VfVJjqdP3FrqzDLnvxpqSmp_nx3eZP8=.6cabdece-b484-4b24-8d5f-8bdeb222a691@github.com>

> Libgraal is compiled ahead of time and should not need any JVMCI Java code to be dynamically loaded at runtime. Prior to this PR, this is not the case due to:
> 
> * Code to copy system properties from the HotSpot heap into the libgraal heap. This is in `jdk.vm.ci.services.Services.initializeSavedProperties(byte[])` and `jdk.vm.ci.services.Services.serializeSavedProperties()`. This code should be moved to `java.base/jdk.internal.vm.VMSupport`.
> * Code to translate exceptions from the HotSpot heap into the libgraal heap and vice versa. This code should be moved from `jdk.internal.vm.ci//jdk.vm.ci.hotspot.TranslatedException` to `java.base/jdk.internal.vm.VMSupport`.
> 
> This PR makes the above changes. As a result, it's possible to build a JDK image that includes (and uses) libgraal but does not include `jdk.internal.vm.ci` or `jdk.internal.vm.compiler`. This both reduces footprint and better isolates the JAVMCI and the Graal compiler as accessing these components from Java code is now impossible.

Doug Simon 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 14 additional commits since the last revision:

 - Merge remote-tracking branch 'openjdk-jdk/master' into JDK-8298099
 - formatting to avoid very long lines [skip ci]
 - removed debug code [skip ci]
 - clarify Properties filtering [skip ci]
 - remove debug code [skip ci]
 - incorporate review feedback [skip ci]
 - removed hard-coded module name [skip ci]
 - renamed is_module_resolvable to is_module_observable
 - share code to create the exploded path for a module and avoid stack-based variable length array
 - generalized ClassLoader::has_jvmci_module to is_module_resolvable
 - ... and 4 more: https://git.openjdk.org/jdk/compare/a1a75a56...f5219b20

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11513/files
  - new: https://git.openjdk.org/jdk/pull/11513/files/bdbe7cf2..f5219b20

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11513&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11513&range=05-06

  Stats: 29076 lines in 626 files changed: 16520 ins; 7341 del; 5215 mod
  Patch: https://git.openjdk.org/jdk/pull/11513.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11513/head:pull/11513

PR: https://git.openjdk.org/jdk/pull/11513

From pchilanomate at openjdk.org  Wed Dec  7 20:04:19 2022
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 7 Dec 2022 20:04:19 GMT
Subject: RFR: 8292674: ReportJNIFatalError should print all java frames
In-Reply-To: <-ipNtt5PSZ2d7VUBSoduPyNwnW2GeN_y0Dcs95qI8HU=.c4771172-01dd-49ae-8f4a-9d5cbd6c6dad@github.com>
References: <-ipNtt5PSZ2d7VUBSoduPyNwnW2GeN_y0Dcs95qI8HU=.c4771172-01dd-49ae-8f4a-9d5cbd6c6dad@github.com>
Message-ID: <GUt22sBkIVy_z7CfVh_9KOD_cWgsYXE_KrwrMlsHzg4=.61252a55-4b6e-4d1f-bc13-a2764aca2815@github.com>

On Mon, 5 Dec 2022 06:58:32 GMT, David Holmes <dholmes at openjdk.org> wrote:

> When JNI reports errors and warnings and produces a stack trace, we need to see the exact Java code that was being executed. The existing `JavaThread::print_stack` that is used is only for platform/carrier threads and doesn't show any mounted virtual thread. So we introduce a new `JavaThread::print_virtual_stack_on` method to print the mounted virtual thread's stack, and we add `JavaThread::print_jni_stack` as a utility for JNI to call that dispatches to the appropriate function based on the thread type.
> 
> The existing test `hotspot/jtreg/runtime/jni/checked/TestPrimitiveArrayCriticalWithBadParam.java` was modified to test regular and virtual threads, and to expect to see the specific stack frame of the Java native method.
> 
> Additional manual testing of the JNI `FatalError` method was done by direct fault injection in modified JDK code.
> 
> Sanity testing: Oracle tiers 1-4 (to include our -Xcheck:jni run in tier4)
> 
> Thanks,
> David

Looks good to me. Some comments below.

Thanks,
Patricio

src/hotspot/share/prims/jniCheck.cpp line 145:

> 143: static void ReportJNIWarning(JavaThread* thr, const char *msg) {
> 144:   tty->print_cr("WARNING in native method: %s", msg);
> 145:   thr->print_jni_stack();

There is another print_stack() call in check_pending_exception() that wasn't changed. Was that intended?

src/hotspot/share/runtime/javaThread.cpp line 1758:

> 1756:       // Print out lock information
> 1757:       if (JavaMonitorsInStackTrace) {
> 1758:         jvf->print_lock_info_on(st, count);

I see this method looks for objects that are locked in this frame and prints their klass. At least for interpretedVFrame we get the oops from the BasicObjectLocks in the stack so that would already require to set _process_frames. Don't understand completely how the compiled case works but would certainly need that too (and should probably also set _update_map). I see that's actually how JavaThread::print_stack_on() defines them.

test/hotspot/jtreg/runtime/jni/checked/TestPrimitiveArrayCriticalWithBadParam.java line 32:

> 30:  * @comment Tests reporting with regular thread and virtual thread.
> 31:  * @library /test/lib
> 32:  * @enablePreview

Don't we need @requires vm.continuations also? I remember having failures on the linux-x86 tests because of this, but don't see those runs in your Github actions to double check.

-------------

PR: https://git.openjdk.org/jdk/pull/11503

From alanb at openjdk.org  Wed Dec  7 20:42:02 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Dec 2022 20:42:02 GMT
Subject: RFR: 8292674: ReportJNIFatalError should print all java frames
In-Reply-To: <GUt22sBkIVy_z7CfVh_9KOD_cWgsYXE_KrwrMlsHzg4=.61252a55-4b6e-4d1f-bc13-a2764aca2815@github.com>
References: <-ipNtt5PSZ2d7VUBSoduPyNwnW2GeN_y0Dcs95qI8HU=.c4771172-01dd-49ae-8f4a-9d5cbd6c6dad@github.com>
 <GUt22sBkIVy_z7CfVh_9KOD_cWgsYXE_KrwrMlsHzg4=.61252a55-4b6e-4d1f-bc13-a2764aca2815@github.com>
Message-ID: <o0WgVq6ow8gAPINQSAGskr93Mwt239_jEt34GXGLu24=.8c9f346f-08bb-4174-ab03-0c159db1439f@github.com>

On Wed, 7 Dec 2022 18:09:56 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Don't we need @requires vm.continuations also? I remember having failures on the linux-x86 tests because of this, but don't see those runs in your Github actions to double check.

You can quickly test this by running the test with -XX:-VMContinuations rather than waiting for GHA. I suspect it should pass as this test is just checking for the "FATAL ERROR" and bad param strings so should be okay with the alt implementation of virtual threads used on x86_32 and other platforms without a port.

-------------

PR: https://git.openjdk.org/jdk/pull/11503

From dholmes at openjdk.org  Wed Dec  7 20:58:59 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 7 Dec 2022 20:58:59 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data
In-Reply-To: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
Message-ID: <k38BJuXcD14AGeChXZ2G98PKBZjlB9qxh_Js39t6t9c=.1fb285aa-420b-4b10-a33b-8d02ae504e3c@github.com>

On Tue, 6 Dec 2022 06:13:23 GMT, Justin King <jcking at openjdk.org> wrote:

> Resolve memory leak related to `MethodData::_extra_data_lock` in `Method::build_profiling_method_data` by defining `MethodData::release_C_heap_structures` and calling it where appropriate before deallocating `MethodData`.

Perhaps an oversimplification, but we are missing a destructor call so the solution seems to be to put that destructor call back for that missing case. If we can't always call the destructor then we need to be selective about it.

Replacing the destructor with release_C_heap_structures and changing from embedded mutex to independent mutex, seems a lot of changes for one missing destructor.

-------------

PR: https://git.openjdk.org/jdk/pull/11526

From pchilanomate at openjdk.org  Wed Dec  7 21:07:12 2022
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 7 Dec 2022 21:07:12 GMT
Subject: RFR: 8292674: ReportJNIFatalError should print all java frames
In-Reply-To: <o0WgVq6ow8gAPINQSAGskr93Mwt239_jEt34GXGLu24=.8c9f346f-08bb-4174-ab03-0c159db1439f@github.com>
References: <-ipNtt5PSZ2d7VUBSoduPyNwnW2GeN_y0Dcs95qI8HU=.c4771172-01dd-49ae-8f4a-9d5cbd6c6dad@github.com>
 <GUt22sBkIVy_z7CfVh_9KOD_cWgsYXE_KrwrMlsHzg4=.61252a55-4b6e-4d1f-bc13-a2764aca2815@github.com>
 <o0WgVq6ow8gAPINQSAGskr93Mwt239_jEt34GXGLu24=.8c9f346f-08bb-4174-ab03-0c159db1439f@github.com>
Message-ID: <txi85Ic7N9HjeJIOpIouEmWt9r2c0_MfLTxvInmTnrQ=.4469a8ea-88c8-450f-90b4-2bae54a4fd2e@github.com>

On Wed, 7 Dec 2022 20:39:48 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> test/hotspot/jtreg/runtime/jni/checked/TestPrimitiveArrayCriticalWithBadParam.java line 32:
>> 
>>> 30:  * @comment Tests reporting with regular thread and virtual thread.
>>> 31:  * @library /test/lib
>>> 32:  * @enablePreview
>> 
>> Don't we need @requires vm.continuations also? I remember having failures on the linux-x86 tests because of this, but don't see those runs in your Github actions to double check.
>
>> Don't we need @requires vm.continuations also? I remember having failures on the linux-x86 tests because of this, but don't see those runs in your Github actions to double check.
> 
> You can quickly test this by running the test with -XX:-VMContinuations rather than waiting for GHA. I suspect it should pass as this test is just checking for the "FATAL ERROR" and bad param strings so should be okay with the alt implementation of virtual threads used on x86_32 and other platforms without a port.

Thanks for the tip @AlanBateman. I run it with -XX:-VMContinuations and verified it works.

-------------

PR: https://git.openjdk.org/jdk/pull/11503

From xuelei at openjdk.org  Wed Dec  7 21:25:11 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 7 Dec 2022 21:25:11 GMT
Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v18]
In-Reply-To: <fWd_NIunUhDXwy8uZSno90GC-PM8pFCey-pAMxxO0rI=.0fede0e4-1438-4321-bc8d-d11565389cae@github.com>
References: <fWd_NIunUhDXwy8uZSno90GC-PM8pFCey-pAMxxO0rI=.0fede0e4-1438-4321-bc8d-d11565389cae@github.com>
Message-ID: <ZXz5ouPFy3NE2vq1ymjOLWsp2OsvsEuAcsPDKjPpOLs=.5aac3ce6-38ed-49f2-b28d-3a0106eced05@github.com>

> Hi,
> 
> May I have this update reviewed?
> 
> The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure.  The build could pass if warnings are disabled for codes that use sprintf method.  For the long run, the sprintf could be replaced with snprintf.  This patch is trying to check if snprintf could be used.
> 
> Thanks,
> Xuelei

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  update on review feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11115/files
  - new: https://git.openjdk.org/jdk/pull/11115/files/c7dd001b..c391535c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11115&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11115&range=16-17

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11115.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11115/head:pull/11115

PR: https://git.openjdk.org/jdk/pull/11115

From xuelei at openjdk.org  Wed Dec  7 21:25:11 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 7 Dec 2022 21:25:11 GMT
Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v17]
In-Reply-To: <D2GcLWUTfyqFoBuUa9JXarKRz_j1xwjNSoyBTfs6PE4=.b52f7b27-acf3-40c1-8fd1-8afa2003f9bd@github.com>
References: <fWd_NIunUhDXwy8uZSno90GC-PM8pFCey-pAMxxO0rI=.0fede0e4-1438-4321-bc8d-d11565389cae@github.com>
 <v-LA3R9EgJGM_01c54w4H8ahI7BGPuKGSSpj2Ms7L84=.8dac50eb-2131-4413-a05f-be2e5db9eff0@github.com>
 <wtfe3m7FrVWssfUYna5S0oWNL6Xhz4UQRb-4V2tvvmc=.3356deec-bbe2-4372-ac3a-2cdc620fae67@github.com>
 <D2GcLWUTfyqFoBuUa9JXarKRz_j1xwjNSoyBTfs6PE4=.b52f7b27-acf3-40c1-8fd1-8afa2003f9bd@github.com>
Message-ID: <PdDhXspwAJltsGlRzXfAjHTdiKrZ_zW-EtOlhb6jJ9k=.01c28967-4d6e-489b-a52a-df643e353680@github.com>

On Wed, 7 Dec 2022 16:00:04 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

>> src/hotspot/os/bsd/attachListener_bsd.cpp line 260:
>> 
>>> 258:   // name ("load", "datadump", ...), and <arg> is an argument
>>> 259:   int expected_str_count = 2 + AttachOperation::arg_count_max;
>>> 260:   const int max_len = (ver_str_len + 1) + (AttachOperation::name_length_max + 1) +
>> 
>> This makes `max_len` a runtime variable, before it was a compile time constant. Below, we use it to create the buf array. IIRC creating an array with a variable runtime length is a non-standard compiler extension. I am surprised this even builds.
>
> better to keep sizeof(ver_str) here (const)

Updated to use sizeof.

-------------

PR: https://git.openjdk.org/jdk/pull/11115

From xuelei at openjdk.org  Wed Dec  7 21:25:13 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 7 Dec 2022 21:25:13 GMT
Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v17]
In-Reply-To: <wtfe3m7FrVWssfUYna5S0oWNL6Xhz4UQRb-4V2tvvmc=.3356deec-bbe2-4372-ac3a-2cdc620fae67@github.com>
References: <fWd_NIunUhDXwy8uZSno90GC-PM8pFCey-pAMxxO0rI=.0fede0e4-1438-4321-bc8d-d11565389cae@github.com>
 <v-LA3R9EgJGM_01c54w4H8ahI7BGPuKGSSpj2Ms7L84=.8dac50eb-2131-4413-a05f-be2e5db9eff0@github.com>
 <wtfe3m7FrVWssfUYna5S0oWNL6Xhz4UQRb-4V2tvvmc=.3356deec-bbe2-4372-ac3a-2cdc620fae67@github.com>
Message-ID: <26aqt5pBpt8pWZs7EciRLqThpaxg8LpvYSSL4Dccw14=.cdfe05cc-919d-4fa8-a0bc-75a74d845209@github.com>

On Wed, 7 Dec 2022 08:46:45 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comment for snprintf_checked
>
> src/hotspot/share/adlc/output_c.cpp line 46:
> 
>> 44:   va_end(args);
>> 45:   assert(result >= 0, "snprintf error");
>> 46:   assert(static_cast<size_t>(result) < len, "snprintf truncated");
> 
> Question, what is this assert? The standard CRT assert? Will it fire always, or just in debug?

The assert is defined in adlc.hpp, as follow:
`#define assert(cond, msg) { if (!(cond)) { fprintf(stderr, "assert fails %s %d: %s\n", __FILE__, __LINE__, msg); abort(); }}
`

I think it will fire always.

> src/hotspot/share/runtime/os.cpp line 102:
> 
>> 100: }
>> 101: 
>> 102: int os::snprintf_checked(char* buf, size_t len, const char* fmt, ...) {
> 
> Can you please assert for buffer len > 0 and < some reasonable max, e.g. 1 gb? Protects us against neg overflows and other errors.

I may be hesitate for the checking. The behavior maybe unclear if a size_t value could be negative and if it is possible the max limit is too small in practice.  If it is necessary, the svnprintf() could do that instead.

> src/hotspot/share/runtime/os.cpp line 108:
> 
>> 106:   va_end(args);
>> 107:   assert(result >= 0, "os::snprintf error");
>> 108:   assert(static_cast<size_t>(result) < len, "os::snprintf truncated");
> 
> Can you please provide a printout for the truncated string? Proposal:
> 
> ```assert(static_cast<size_t>(result) < len, "os::snprintf truncated ("%.200s...")", buf);```

I'm not sure if there is sensitive information in the buf.  Dumping the string may result in sensitive information leaking.

> src/hotspot/share/utilities/utf8.cpp line 227:
> 
>> 225:     } else {
>> 226:       if (p + 6 >= end) break;      // string is truncated
>> 227:       os::snprintf_checked(p, 7, "\\u%04x", c);  // counting terminating zero in
> 
> I had to think a while until I was sure this is correct :-) 
> We are sure that c can never be > 0xFFFFFF (6 digits), right? But if that is false, code had been wrong before too.

I think so as it used to work.

-------------

PR: https://git.openjdk.org/jdk/pull/11115

From pminborg at openjdk.org  Wed Dec  7 22:04:11 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 7 Dec 2022 22:04:11 GMT
Subject: RFR: 8298277: Replace "session" with "scope" for FFM access
Message-ID: <CexwefXXOExmjkTj8JOWdwKjXuUxnX6gUGc16_ZPFTk=.d6d26344-ed1f-4c26-9ef5-ab0daef3ca67@github.com>

This PR suggests renaming various names from "session" to "scope" in accordance with https://openjdk.org/jeps/434

The PRs contains changes for several sub-components.

-------------

Commit messages:
 - Rename session to scope

Changes: https://git.openjdk.org/jdk/pull/11573/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11573&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298277
  Stats: 2783 lines in 98 files changed: 954 ins; 955 del; 874 mod
  Patch: https://git.openjdk.org/jdk/pull/11573.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11573/head:pull/11573

PR: https://git.openjdk.org/jdk/pull/11573

From dholmes at openjdk.org  Wed Dec  7 22:14:08 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 7 Dec 2022 22:14:08 GMT
Subject: RFR: 8292674: ReportJNIFatalError should print all java frames
In-Reply-To: <GUt22sBkIVy_z7CfVh_9KOD_cWgsYXE_KrwrMlsHzg4=.61252a55-4b6e-4d1f-bc13-a2764aca2815@github.com>
References: <-ipNtt5PSZ2d7VUBSoduPyNwnW2GeN_y0Dcs95qI8HU=.c4771172-01dd-49ae-8f4a-9d5cbd6c6dad@github.com>
 <GUt22sBkIVy_z7CfVh_9KOD_cWgsYXE_KrwrMlsHzg4=.61252a55-4b6e-4d1f-bc13-a2764aca2815@github.com>
Message-ID: <2dzXaJtpy14ISzD5WvHFKJyTbL7lY4je6DX9eGoi8oQ=.622805db-c981-4039-aee6-741e83c77bc7@github.com>

On Wed, 7 Dec 2022 20:01:34 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> When JNI reports errors and warnings and produces a stack trace, we need to see the exact Java code that was being executed. The existing `JavaThread::print_stack` that is used is only for platform/carrier threads and doesn't show any mounted virtual thread. So we introduce a new `JavaThread::print_virtual_stack_on` method to print the mounted virtual thread's stack, and we add `JavaThread::print_jni_stack` as a utility for JNI to call that dispatches to the appropriate function based on the thread type.
>> 
>> The existing test `hotspot/jtreg/runtime/jni/checked/TestPrimitiveArrayCriticalWithBadParam.java` was modified to test regular and virtual threads, and to expect to see the specific stack frame of the Java native method.
>> 
>> Additional manual testing of the JNI `FatalError` method was done by direct fault injection in modified JDK code.
>> 
>> Sanity testing: Oracle tiers 1-4 (to include our -Xcheck:jni run in tier4)
>> 
>> Thanks,
>> David
>
> Looks good to me. Some comments below.
> 
> Thanks,
> Patricio

Thanks for looking at this @pchilano . I've made changes and will re-test before updating the PR. I'm retargetting this to JDK 21 now.

> src/hotspot/share/prims/jniCheck.cpp line 145:
> 
>> 143: static void ReportJNIWarning(JavaThread* thr, const char *msg) {
>> 144:   tty->print_cr("WARNING in native method: %s", msg);
>> 145:   thr->print_jni_stack();
> 
> There is another print_stack() call in check_pending_exception() that wasn't changed. Was that intended?

That was an oversight. I've changed it now too.

> src/hotspot/share/runtime/javaThread.cpp line 1758:
> 
>> 1756:       // Print out lock information
>> 1757:       if (JavaMonitorsInStackTrace) {
>> 1758:         jvf->print_lock_info_on(st, count);
> 
> I see this method looks for objects that are locked in this frame and prints their klass. At least for interpretedVFrame we get the oops from the BasicObjectLocks in the stack so that would already require to set _process_frames. Don't understand completely how the compiled case works but would certainly need that too (and should probably also set _update_map). I see that's actually how JavaThread::print_stack_on() defines them.

Okay so if I want to process monitors I need to change the register map to match the one in `print_stack_on` with regards to update and process frame. Re-testing now.

-------------

PR: https://git.openjdk.org/jdk/pull/11503

From dholmes at openjdk.org  Wed Dec  7 22:14:10 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 7 Dec 2022 22:14:10 GMT
Subject: RFR: 8292674: ReportJNIFatalError should print all java frames
In-Reply-To: <txi85Ic7N9HjeJIOpIouEmWt9r2c0_MfLTxvInmTnrQ=.4469a8ea-88c8-450f-90b4-2bae54a4fd2e@github.com>
References: <-ipNtt5PSZ2d7VUBSoduPyNwnW2GeN_y0Dcs95qI8HU=.c4771172-01dd-49ae-8f4a-9d5cbd6c6dad@github.com>
 <GUt22sBkIVy_z7CfVh_9KOD_cWgsYXE_KrwrMlsHzg4=.61252a55-4b6e-4d1f-bc13-a2764aca2815@github.com>
 <o0WgVq6ow8gAPINQSAGskr93Mwt239_jEt34GXGLu24=.8c9f346f-08bb-4174-ab03-0c159db1439f@github.com>
 <txi85Ic7N9HjeJIOpIouEmWt9r2c0_MfLTxvInmTnrQ=.4469a8ea-88c8-450f-90b4-2bae54a4fd2e@github.com>
Message-ID: <Z-06tgL48ONeo1ou1HkehG1dPna9u7BT1rM-jJI1KLI=.98ea802f-6aa5-4cf9-96c8-e7cb529720a7@github.com>

On Wed, 7 Dec 2022 21:04:48 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>>> Don't we need @requires vm.continuations also? I remember having failures on the linux-x86 tests because of this, but don't see those runs in your Github actions to double check.
>> 
>> You can quickly test this by running the test with -XX:-VMContinuations rather than waiting for GHA. I suspect it should pass as this test is just checking for the "FATAL ERROR" and bad param strings so should be okay with the alt implementation of virtual threads used on x86_32 and other platforms without a port.
>
> Thanks for the tip @AlanBateman. I run it with -XX:-VMContinuations and verified it works.

Added.

-------------

PR: https://git.openjdk.org/jdk/pull/11503

From dnsimon at openjdk.org  Wed Dec  7 22:14:16 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 7 Dec 2022 22:14:16 GMT
Subject: Integrated: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime
In-Reply-To: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
Message-ID: <Z888XwHvLdlIcqHiBpGGMMOvNvVJQxqq8ZyTSorPe0M=.be4404cf-a383-4e95-a2c5-af5e81c57a20@github.com>

On Mon, 5 Dec 2022 13:16:25 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> Libgraal is compiled ahead of time and should not need any JVMCI Java code to be dynamically loaded at runtime. Prior to this PR, this is not the case due to:
> 
> * Code to copy system properties from the HotSpot heap into the libgraal heap. This is in `jdk.vm.ci.services.Services.initializeSavedProperties(byte[])` and `jdk.vm.ci.services.Services.serializeSavedProperties()`. This code should be moved to `java.base/jdk.internal.vm.VMSupport`.
> * Code to translate exceptions from the HotSpot heap into the libgraal heap and vice versa. This code should be moved from `jdk.internal.vm.ci//jdk.vm.ci.hotspot.TranslatedException` to `java.base/jdk.internal.vm.VMSupport`.
> 
> This PR makes the above changes. As a result, it's possible to build a JDK image that includes (and uses) libgraal but does not include `jdk.internal.vm.ci` or `jdk.internal.vm.compiler`. This both reduces footprint and better isolates the JAVMCI and the Graal compiler as accessing these components from Java code is now impossible.

This pull request has now been integrated.

Changeset: 8b69a2e4
Author:    Doug Simon <dnsimon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8b69a2e434ad2fa3369079622b57afb973d5bd9a
Stats:     1438 lines in 20 files changed: 628 ins; 714 del; 96 mod

8298099: [JVMCI] decouple libgraal from JVMCI module at runtime

Reviewed-by: never

-------------

PR: https://git.openjdk.org/jdk/pull/11513

From dholmes at openjdk.org  Wed Dec  7 22:17:29 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 7 Dec 2022 22:17:29 GMT
Subject: RFR: 8292674: ReportJNIFatalError should print all java frames
In-Reply-To: <Z-06tgL48ONeo1ou1HkehG1dPna9u7BT1rM-jJI1KLI=.98ea802f-6aa5-4cf9-96c8-e7cb529720a7@github.com>
References: <-ipNtt5PSZ2d7VUBSoduPyNwnW2GeN_y0Dcs95qI8HU=.c4771172-01dd-49ae-8f4a-9d5cbd6c6dad@github.com>
 <GUt22sBkIVy_z7CfVh_9KOD_cWgsYXE_KrwrMlsHzg4=.61252a55-4b6e-4d1f-bc13-a2764aca2815@github.com>
 <o0WgVq6ow8gAPINQSAGskr93Mwt239_jEt34GXGLu24=.8c9f346f-08bb-4174-ab03-0c159db1439f@github.com>
 <txi85Ic7N9HjeJIOpIouEmWt9r2c0_MfLTxvInmTnrQ=.4469a8ea-88c8-450f-90b4-2bae54a4fd2e@github.com>
 <Z-06tgL48ONeo1ou1HkehG1dPna9u7BT1rM-jJI1KLI=.98ea802f-6aa5-4cf9-96c8-e7cb529720a7@github.com>
Message-ID: <dxc2eGUV15Of5Jv_eF96f9_5m9R_M6n9qFeDbkNRvCc=.976d7878-14be-4c1c-8736-ca0098ec4a2c@github.com>

On Wed, 7 Dec 2022 22:09:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Thanks for the tip @AlanBateman. I run it with -XX:-VMContinuations and verified it works.
>
> Added.

GitHub hid the follow up comments from me for some reason. So I don't need to add it afterall.

-------------

PR: https://git.openjdk.org/jdk/pull/11503

From dholmes at openjdk.org  Wed Dec  7 22:53:37 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 7 Dec 2022 22:53:37 GMT
Subject: RFR: 8292674: ReportJNIFatalError should print all java frames
 [v2]
In-Reply-To: <-ipNtt5PSZ2d7VUBSoduPyNwnW2GeN_y0Dcs95qI8HU=.c4771172-01dd-49ae-8f4a-9d5cbd6c6dad@github.com>
References: <-ipNtt5PSZ2d7VUBSoduPyNwnW2GeN_y0Dcs95qI8HU=.c4771172-01dd-49ae-8f4a-9d5cbd6c6dad@github.com>
Message-ID: <Eo_w2BJXoaIKImQhppUGZ_Thuv4JhnniAgHuqNwHfpU=.6b999b11-fa4d-4a20-b864-e0c9bd15eb07@github.com>

> When JNI reports errors and warnings and produces a stack trace, we need to see the exact Java code that was being executed. The existing `JavaThread::print_stack` that is used is only for platform/carrier threads and doesn't show any mounted virtual thread. So we introduce a new `JavaThread::print_virtual_stack_on` method to print the mounted virtual thread's stack, and we add `JavaThread::print_jni_stack` as a utility for JNI to call that dispatches to the appropriate function based on the thread type.
> 
> The existing test `hotspot/jtreg/runtime/jni/checked/TestPrimitiveArrayCriticalWithBadParam.java` was modified to test regular and virtual threads, and to expect to see the specific stack frame of the Java native method.
> 
> Additional manual testing of the JNI `FatalError` method was done by direct fault injection in modified JDK code.
> 
> Sanity testing: Oracle tiers 1-4 (to include our -Xcheck:jni run in tier4)
> 
> Thanks,
> David

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Changed RegisterMap to include process_frame and update, for object monitor examination.
  Updated stack printing for exception checks.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11503/files
  - new: https://git.openjdk.org/jdk/pull/11503/files/249dc2fb..fa1d7b0c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11503&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11503&range=00-01

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/11503.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11503/head:pull/11503

PR: https://git.openjdk.org/jdk/pull/11503

From jvernee at openjdk.org  Wed Dec  7 23:00:08 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 7 Dec 2022 23:00:08 GMT
Subject: RFR: 8298277: Replace "session" with "scope" for FFM access
In-Reply-To: <CexwefXXOExmjkTj8JOWdwKjXuUxnX6gUGc16_ZPFTk=.d6d26344-ed1f-4c26-9ef5-ab0daef3ca67@github.com>
References: <CexwefXXOExmjkTj8JOWdwKjXuUxnX6gUGc16_ZPFTk=.d6d26344-ed1f-4c26-9ef5-ab0daef3ca67@github.com>
Message-ID: <NVww6vH-lGykHhFN-FTkh9qJISEpm-_UZK0Khnyszuo=.b3b3f542-7851-4fae-a645-20851c129ad8@github.com>

On Wed, 7 Dec 2022 21:55:43 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR suggests renaming various names from "session" to "scope" in accordance with https://openjdk.org/jeps/434
> 
> The PRs contains changes for several sub-components.

src/java.base/share/classes/jdk/internal/foreign/MemoryScopeImpl.java line 53:

> 51:  * access is possible when a scope is being closed (see {@link jdk.internal.misc.ScopedMemoryAccess}).
> 52:  */
> 53: public abstract sealed class MemoryScopeImpl

Since the interface is called `SegmentScope`, I think `SegmentScopeImpl` would be a better name here.

-------------

PR: https://git.openjdk.org/jdk/pull/11573

From mcimadamore at openjdk.org  Wed Dec  7 23:37:03 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 7 Dec 2022 23:37:03 GMT
Subject: RFR: 8298277: Replace "session" with "scope" for FFM access
In-Reply-To: <CexwefXXOExmjkTj8JOWdwKjXuUxnX6gUGc16_ZPFTk=.d6d26344-ed1f-4c26-9ef5-ab0daef3ca67@github.com>
References: <CexwefXXOExmjkTj8JOWdwKjXuUxnX6gUGc16_ZPFTk=.d6d26344-ed1f-4c26-9ef5-ab0daef3ca67@github.com>
Message-ID: <LQIRMsp-_xSIkyeIrGgVgumF0jv08Kloq_24W5l0PF4=.e6ccb023-35e0-4bc4-ac67-f2f42fb8b076@github.com>

On Wed, 7 Dec 2022 21:55:43 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR suggests renaming various names from "session" to "scope" in accordance with https://openjdk.org/jeps/434
> 
> The PRs contains changes for several sub-components.

I think we should split this PR into multiple parts:
* there are some good javadoc changes in here to the Vector API docs
* there are some test changes, where some of the names are out of date
* the majority of changes, which is caused by MemorySessionImpl -> MemoryScopeImpl is the part I'm less sure about. I think leaving that as is might be fine for now.

-------------

PR: https://git.openjdk.org/jdk/pull/11573

From dholmes at openjdk.org  Thu Dec  8 00:38:13 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 8 Dec 2022 00:38:13 GMT
Subject: RFR: 8292674: ReportJNIFatalError should print all java frames
 [v3]
In-Reply-To: <-ipNtt5PSZ2d7VUBSoduPyNwnW2GeN_y0Dcs95qI8HU=.c4771172-01dd-49ae-8f4a-9d5cbd6c6dad@github.com>
References: <-ipNtt5PSZ2d7VUBSoduPyNwnW2GeN_y0Dcs95qI8HU=.c4771172-01dd-49ae-8f4a-9d5cbd6c6dad@github.com>
Message-ID: <PISgFTzLXnZ2ag2SvndnR_R2VuWpWSX35MiTZEguWEs=.0d44d450-15e4-4f8f-bd92-6f68f6226cb8@github.com>

> When JNI reports errors and warnings and produces a stack trace, we need to see the exact Java code that was being executed. The existing `JavaThread::print_stack` that is used is only for platform/carrier threads and doesn't show any mounted virtual thread. So we introduce a new `JavaThread::print_virtual_stack_on` method to print the mounted virtual thread's stack, and we add `JavaThread::print_jni_stack` as a utility for JNI to call that dispatches to the appropriate function based on the thread type.
> 
> The existing test `hotspot/jtreg/runtime/jni/checked/TestPrimitiveArrayCriticalWithBadParam.java` was modified to test regular and virtual threads, and to expect to see the specific stack frame of the Java native method.
> 
> Additional manual testing of the JNI `FatalError` method was done by direct fault injection in modified JDK code.
> 
> Sanity testing: Oracle tiers 1-4 (to include our -Xcheck:jni run in tier4)
> 
> Thanks,
> David

David Holmes 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 three additional commits since the last revision:

 - Merge branch 'master' into 8292674-ReportJNIFatalError-v2
 - Changed RegisterMap to include process_frame and update, for object monitor examination.
   Updated stack printing for exception checks.
 - 8292674: ReportJNIFatalError should print all java frames

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11503/files
  - new: https://git.openjdk.org/jdk/pull/11503/files/fa1d7b0c..f4fd2893

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11503&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11503&range=01-02

  Stats: 85869 lines in 1440 files changed: 40908 ins; 36431 del; 8530 mod
  Patch: https://git.openjdk.org/jdk/pull/11503.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11503/head:pull/11503

PR: https://git.openjdk.org/jdk/pull/11503

From xlinzheng at openjdk.org  Thu Dec  8 02:02:02 2022
From: xlinzheng at openjdk.org (Xiaolin Zheng)
Date: Thu, 8 Dec 2022 02:02:02 GMT
Subject: RFR: 8298075: RISC-V: Implement post-call NOPs [v6]
In-Reply-To: <cCfOtWYOtpM0R3WvvNESUZ_IkYWhL40Xtj56rr--Ung=.68226b06-1da6-4959-aae6-cbde42062d60@github.com>
References: <inZ_2fowZZQz0C53E2h4zURoyQIwZcJaBfhC4zwFyb8=.cbc7e361-9bad-48ce-b6d4-c3a8fe2e1cba@github.com>
 <ORZHK2_0RTYb9rtYkX_JXTTcex_LryeoYT3rk6mrIxs=.6743e193-2cc6-49b9-a896-befd73206072@github.com>
 <cCfOtWYOtpM0R3WvvNESUZ_IkYWhL40Xtj56rr--Ung=.68226b06-1da6-4959-aae6-cbde42062d60@github.com>
Message-ID: <g7B8sPJyAz7SL_SIjP_zglbBeMa9tP1AiXZdogQUB5M=.eac9480b-c95a-465a-aa65-2af1c8f1430a@github.com>

On Wed, 7 Dec 2022 13:09:52 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Plural form...
>
> Change looks good. I also performed regular benchmark tests (Dacapo, specjbb,2015, Renaissance) for this change and I didn't notice regressions from the numbers. So I guess it should be safe to have this.

Thank you for reviewing @RealFYang @luhenry and the additional testing!

-------------

PR: https://git.openjdk.org/jdk/pull/11502

From dholmes at openjdk.org  Thu Dec  8 02:19:06 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 8 Dec 2022 02:19:06 GMT
Subject: RFR: 8157023: Integrate NMT with JFR [v5]
In-Reply-To: <5OWgF37Jj3kVRSDHCv1MxSbMnLEDtgoK9CiAxqJPBVI=.3e4e72f3-e8fd-4be3-a032-2b281058fecc@github.com>
References: <C-R2pNTlUWhdr5doc_KNK5jjPvfeq8LTUfEQAb6gxmo=.bf7f7f04-21ab-40c4-9d3a-275068507e13@github.com>
 <5OWgF37Jj3kVRSDHCv1MxSbMnLEDtgoK9CiAxqJPBVI=.3e4e72f3-e8fd-4be3-a032-2b281058fecc@github.com>
Message-ID: <2ibDLSZZkSyPusJvZ8esUtAepOYGyUWgKuQ5kI7G9Pg=.292b5632-e2a6-4abc-b107-5aebb2a5fc57@github.com>

On Wed, 7 Dec 2022 15:11:58 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Please review this enhancement to include NMT information in JFR recordings.
>> 
>> **Summary**
>> Native Memory Tracking summary information can be obtained from a running VM using `jcmd` if started with `-XX:NativeMemoryTracking=summary/detail`. Using `jcmd` requires you to run a separate process and to parse the output to get the needed information. This change adds JFR events for NMT information to enable additional ways to consume the NMT data.
>> 
>> There are two new events added:
>> * _NativeMemoryUsage_ - The total native memory usage.
>> * _NativeMemoryUsagePart_ - The native memory usage for each component.
>> 
>> These events are sent periodically and by default the interval is 1s. This can of course be discussed, but that is the staring point. When NMT is not enabled on events will be sent.
>> 
>> **Testing**
>> * Added a simple test to verify that the events are sent as expected depending on if NMT is enabled or not.
>> * Mach5 sanity testing
>
> Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   mgonlun review

The new test is failing in our tier3 testing.

-------------

PR: https://git.openjdk.org/jdk/pull/11449

From xlinzheng at openjdk.org  Thu Dec  8 02:23:29 2022
From: xlinzheng at openjdk.org (Xiaolin Zheng)
Date: Thu, 8 Dec 2022 02:23:29 GMT
Subject: Integrated: 8298075: RISC-V: Implement post-call NOPs
In-Reply-To: <inZ_2fowZZQz0C53E2h4zURoyQIwZcJaBfhC4zwFyb8=.cbc7e361-9bad-48ce-b6d4-c3a8fe2e1cba@github.com>
References: <inZ_2fowZZQz0C53E2h4zURoyQIwZcJaBfhC4zwFyb8=.cbc7e361-9bad-48ce-b6d4-c3a8fe2e1cba@github.com>
Message-ID: <Owugm9uRbdgh6MvgW3m7JNugi1BcDSbhaLG-aXDIoMo=.811eeb6a-c77b-459b-90c1-d23e934eefa6@github.com>

On Mon, 5 Dec 2022 04:22:49 GMT, Xiaolin Zheng <xlinzheng at openjdk.org> wrote:

> Same as [JDK-8287567](https://bugs.openjdk.org/browse/JDK-8287567), we need to implement post-call NOPs in the RISC-V backend.
> 
> We use `li32` to implement it. `li32` will signed-extend the loaded imm32 to a 64-bit register. However, our reader `NativePostCallNop::displacement()` only needs the low 32 bits value so we are safe.
> 
> The current post-call NOP is like:
> 
> nop                    (always 4-byte, used for deoptimization, please see `NativePostCallNop::make_deopt()`)
> lui zr, <imm20>        (always 4-byte)
> addiw zr, zr, <imm12>  (always 4-byte)
> 
> 
> The code size here is the same as the AArch64 counterpart, 12 bytes.
> 
> The logic of setting the post-call NOP displacement is at `install_post_call_nop_displacement()` [1] when nmethods are being installed, so no one is running post-call NOPs when we are patching them.
> 
> One can check them by directly using `java --enable-preview -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly`.
> 
> Tested hotspot tier1~4 and jdk tier1~4 using fastdebug by force turning on `--enable-preview`; SPECjbb2015 and dacapo were tested without regressions found. Skynet JMH benchmark seems to have an improvement from `8662ms/op -> 8495ms/op`.
> 
> Thanks,
> Xiaolin
> 
> [1] https://github.com/openjdk/jdk/blob/b49fd920b6690a8b828c85e45c10e5c4c54d2022/src/hotspot/share/code/nmethod.cpp#L1078-L1107

This pull request has now been integrated.

Changeset: 74f346b3
Author:    Xiaolin Zheng <xlinzheng at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/74f346b33f7fa053ad5c99ef85baa32b7fb12fa6
Stats:     37 lines in 6 files changed: 30 ins; 0 del; 7 mod

8298075: RISC-V: Implement post-call NOPs

Reviewed-by: fyang, luhenry

-------------

PR: https://git.openjdk.org/jdk/pull/11502

From dholmes at openjdk.org  Thu Dec  8 02:45:59 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 8 Dec 2022 02:45:59 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v7]
In-Reply-To: <Epv-jPCuClG7VfVJjqdP3FrqzDLnvxpqSmp_nx3eZP8=.6cabdece-b484-4b24-8d5f-8bdeb222a691@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
 <Epv-jPCuClG7VfVJjqdP3FrqzDLnvxpqSmp_nx3eZP8=.6cabdece-b484-4b24-8d5f-8bdeb222a691@github.com>
Message-ID: <uUejDzqERXU8dOfhQ6SCZfL0ULhj39zQkLhLQXajPuY=.589ad396-46c2-43e8-9ca5-0df6e43e468c@github.com>

On Wed, 7 Dec 2022 19:49:47 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Libgraal is compiled ahead of time and should not need any JVMCI Java code to be dynamically loaded at runtime. Prior to this PR, this is not the case due to:
>> 
>> * Code to copy system properties from the HotSpot heap into the libgraal heap. This is in `jdk.vm.ci.services.Services.initializeSavedProperties(byte[])` and `jdk.vm.ci.services.Services.serializeSavedProperties()`. This code should be moved to `java.base/jdk.internal.vm.VMSupport`.
>> * Code to translate exceptions from the HotSpot heap into the libgraal heap and vice versa. This code should be moved from `jdk.internal.vm.ci//jdk.vm.ci.hotspot.TranslatedException` to `java.base/jdk.internal.vm.VMSupport`.
>> 
>> This PR makes the above changes. As a result, it's possible to build a JDK image that includes (and uses) libgraal but does not include `jdk.internal.vm.ci` or `jdk.internal.vm.compiler`. This both reduces footprint and better isolates the JAVMCI and the Graal compiler as accessing these components from Java code is now impossible.
>
> Doug Simon 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 14 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'openjdk-jdk/master' into JDK-8298099
>  - formatting to avoid very long lines [skip ci]
>  - removed debug code [skip ci]
>  - clarify Properties filtering [skip ci]
>  - remove debug code [skip ci]
>  - incorporate review feedback [skip ci]
>  - removed hard-coded module name [skip ci]
>  - renamed is_module_resolvable to is_module_observable
>  - share code to create the exploded path for a module and avoid stack-based variable length array
>  - generalized ClassLoader::has_jvmci_module to is_module_resolvable
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/5927a4d6...f5219b20

@dougxc Two reviews are needed for all non-trivial hotspot changes, and this also warranted a review from core-libs! Your discussions with Alan still seemed to be in-progress.

-------------

PR: https://git.openjdk.org/jdk/pull/11513

From xuelei at openjdk.org  Thu Dec  8 03:23:04 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 8 Dec 2022 03:23:04 GMT
Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v18]
In-Reply-To: <ZXz5ouPFy3NE2vq1ymjOLWsp2OsvsEuAcsPDKjPpOLs=.5aac3ce6-38ed-49f2-b28d-3a0106eced05@github.com>
References: <fWd_NIunUhDXwy8uZSno90GC-PM8pFCey-pAMxxO0rI=.0fede0e4-1438-4321-bc8d-d11565389cae@github.com>
 <ZXz5ouPFy3NE2vq1ymjOLWsp2OsvsEuAcsPDKjPpOLs=.5aac3ce6-38ed-49f2-b28d-3a0106eced05@github.com>
Message-ID: <v1J6TyDfIHfEuNV7RMx7hhK722imh9R3ZCYIUF_HOpE=.b267add0-86c2-4197-9e8c-81c32bcdd908@github.com>

On Wed, 7 Dec 2022 21:25:11 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> May I have this update reviewed?
>> 
>> The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure.  The build could pass if warnings are disabled for codes that use sprintf method.  For the long run, the sprintf could be replaced with snprintf.  This patch is trying to check if snprintf could be used.
>> 
>> Thanks,
>> Xuelei
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update on review feedback

> With the exception of these errors in cmstypes.c
> 
> /Users/mjh/Documents/GitHub/jdk/src/java.desktop/share/native/liblcms/cmstypes.c:3441:132: error: parameter 'SizeOfTag' set but not used [-Werror,-Wunused-but-set-parameter] void *Type_ProfileSequenceId_Read(struct _cms_typehandler_struct* self, cmsIOHANDLER* io, cmsUInt32Number* nItems, cmsUInt32Number SizeOfTag) ^ /Users/mjh/Documents/GitHub/jdk/src/java.desktop/share/native/liblcms/cmstypes.c:5137:125: error: parameter 'SizeOfTag' set but not used [-Werror,-Wunused-but-set-parameter] void *Type_Dictionary_Read(struct _cms_typehandler_struct* self, cmsIOHANDLER* io, cmsUInt32Number* nItems, cmsUInt32Number SizeOfTag) ^ 2 errors generated.
> 
> I had seen this sometime back. The same workaround of adding?
> 
> cmsUNUSED_PARAMETER(SizeOfTag); // mjh
> 
> To the two methods, which I had noticed included elsewhere in the code, still appears to work.
> 

The SizeOfTag issue was tracked with https://bugs.openjdk.org/browse/JDK-8283221.

> I first noticed the sprintf issue in later releases of Xcode 13. It isn?t just Xcode 14.
> 

In the [Apple Developer Documentation](https://developer.apple.com/documentation/kernel/1441083-sprintf), there is a note for sprintf, "macOS 10.12?10.13.1 Deprecated".  It looks like that deprecation was backported.

-------------

PR: https://git.openjdk.org/jdk/pull/11115

From jcking at openjdk.org  Thu Dec  8 05:01:11 2022
From: jcking at openjdk.org (Justin King)
Date: Thu, 8 Dec 2022 05:01:11 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data [v2]
In-Reply-To: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
Message-ID: <s14hz9aYsn-tMZV1DJ80Fqux5MR-SsSIAvCYL_sjK20=.696674d1-f1f7-4375-8813-cd504a700977@github.com>

> Resolve memory leak related to `MethodData::_extra_data_lock` in `Method::build_profiling_method_data` by defining `MethodData::release_C_heap_structures` and calling it where appropriate before deallocating `MethodData`.

Justin King has updated the pull request incrementally with one additional commit since the last revision:

  Fix memory leak by calling destructor
  
  Signed-off-by: Justin King <jcking at google.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11526/files
  - new: https://git.openjdk.org/jdk/pull/11526/files/fc35f765..fbced7d3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11526&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11526&range=00-01

  Stats: 17 lines in 3 files changed: 0 ins; 10 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/11526.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11526/head:pull/11526

PR: https://git.openjdk.org/jdk/pull/11526

From jcking at openjdk.org  Thu Dec  8 05:02:59 2022
From: jcking at openjdk.org (Justin King)
Date: Thu, 8 Dec 2022 05:02:59 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data
In-Reply-To: <k38BJuXcD14AGeChXZ2G98PKBZjlB9qxh_Js39t6t9c=.1fb285aa-420b-4b10-a33b-8d02ae504e3c@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
 <k38BJuXcD14AGeChXZ2G98PKBZjlB9qxh_Js39t6t9c=.1fb285aa-420b-4b10-a33b-8d02ae504e3c@github.com>
Message-ID: <4cSj7HpnCz1bt3av__0e4rqhFrKVIyiuIGYzIZUFMLE=.1e374941-fcc8-40cf-9264-16fff18f6a5c@github.com>

On Wed, 7 Dec 2022 20:56:53 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Perhaps an oversimplification, but we are missing a destructor call so the solution seems to be to put that destructor call back for that missing case. If we can't always call the destructor then we need to be selective about it.
> 
> Replacing the destructor with release_C_heap_structures and changing from embedded mutex to independent mutex, seems a lot of changes for one missing destructor.

Fair. For now I just reverted back to calling the destructor directly, as that is the path of least resistence to fixing this leak ahead of JDK 20. However, using the destructor like this is very suspect.  I filed https://bugs.openjdk.org/browse/JDK-8298346 to revisit how this is done.

-------------

PR: https://git.openjdk.org/jdk/pull/11526

From dholmes at openjdk.org  Thu Dec  8 05:49:47 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 8 Dec 2022 05:49:47 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data [v2]
In-Reply-To: <s14hz9aYsn-tMZV1DJ80Fqux5MR-SsSIAvCYL_sjK20=.696674d1-f1f7-4375-8813-cd504a700977@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
 <s14hz9aYsn-tMZV1DJ80Fqux5MR-SsSIAvCYL_sjK20=.696674d1-f1f7-4375-8813-cd504a700977@github.com>
Message-ID: <n_lHBpUda9I4nSDf_m-AUE0kUJFIoWmoEbMOQuUospA=.698e93cb-0bd5-4d12-abb7-47b861f2887a@github.com>

On Thu, 8 Dec 2022 05:01:11 GMT, Justin King <jcking at openjdk.org> wrote:

>> Resolve memory leak related to `MethodData::_extra_data_lock` in `Method::build_profiling_method_data` by calling `MethodData::~MethodData()`.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix memory leak by calling destructor
>   
>   Signed-off-by: Justin King <jcking at google.com>

Sorry, the destructor has to, of course, be used in a safe manner - I didn't mean to imply otherwise. Given what `free_metadata` does with the `md` we can't call the destructor before calling it. Perhaps we can add a default parameter `bool invoke_destructor = false` to `free_metadata`, to then call the destructor at the right point (which would be before or after `md->deallocate_contents`).

-------------

PR: https://git.openjdk.org/jdk/pull/11526

From jcking at openjdk.org  Thu Dec  8 05:58:10 2022
From: jcking at openjdk.org (Justin King)
Date: Thu, 8 Dec 2022 05:58:10 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data [v2]
In-Reply-To: <n_lHBpUda9I4nSDf_m-AUE0kUJFIoWmoEbMOQuUospA=.698e93cb-0bd5-4d12-abb7-47b861f2887a@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
 <s14hz9aYsn-tMZV1DJ80Fqux5MR-SsSIAvCYL_sjK20=.696674d1-f1f7-4375-8813-cd504a700977@github.com>
 <n_lHBpUda9I4nSDf_m-AUE0kUJFIoWmoEbMOQuUospA=.698e93cb-0bd5-4d12-abb7-47b861f2887a@github.com>
Message-ID: <80qOKYHdv-lJkTCVIP4BaQ5WM7jwSjBddr6qnsUiiYk=.45769a91-132b-441e-b289-fa24d8c2f50d@github.com>

On Thu, 8 Dec 2022 05:45:53 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Sorry, the destructor has to, of course, be used in a safe manner - I didn't mean to imply otherwise. Given what `free_metadata` does with the `md` we can't call the destructor before calling it. Perhaps we can add a default parameter `bool invoke_destructor = false` to `free_metadata`, to then call the destructor at the right point (which would be before or after `md->deallocate_contents`).

Yeah, that is what I was thinking. https://github.com/jcking/jdk/commit/5f1aad3723b56566428df7b4780ef2d5ca87f29d is an example of this approach. Though it requires making `Metadata` hierarchy have virtual destructors to work as expected. Which should be fine, as it already has virtual functions. Happy to move that commit here if that would be the preferred approach.

-------------

PR: https://git.openjdk.org/jdk/pull/11526

From dholmes at openjdk.org  Thu Dec  8 06:01:54 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 8 Dec 2022 06:01:54 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data [v2]
In-Reply-To: <80qOKYHdv-lJkTCVIP4BaQ5WM7jwSjBddr6qnsUiiYk=.45769a91-132b-441e-b289-fa24d8c2f50d@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
 <s14hz9aYsn-tMZV1DJ80Fqux5MR-SsSIAvCYL_sjK20=.696674d1-f1f7-4375-8813-cd504a700977@github.com>
 <n_lHBpUda9I4nSDf_m-AUE0kUJFIoWmoEbMOQuUospA=.698e93cb-0bd5-4d12-abb7-47b861f2887a@github.com>
 <80qOKYHdv-lJkTCVIP4BaQ5WM7jwSjBddr6qnsUiiYk=.45769a91-132b-441e-b289-fa24d8c2f50d@github.com>
Message-ID: <rhtLOGsriEhTlma8QC6aQdSNc3pBvSrwJQrby8tcGNo=.c407d892-8a98-4167-bfb0-8db90647b348@github.com>

On Thu, 8 Dec 2022 05:53:43 GMT, Justin King <jcking at openjdk.org> wrote:

> Yeah, that is what I was thinking. https://github.com/jcking/jdk/commit/5f1aad3723b56566428df7b4780ef2d5ca87f29d is an example of this approach.

That is somewhat more elaborate/complex than I envisaged - and I'm not sure all those C++ features are usable in hotspot at present. Can we just add a specialized version of `free_metadata` for `MethodData` which takes the extra parameter?

-------------

PR: https://git.openjdk.org/jdk/pull/11526

From jcking at openjdk.org  Thu Dec  8 06:11:37 2022
From: jcking at openjdk.org (Justin King)
Date: Thu, 8 Dec 2022 06:11:37 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data [v3]
In-Reply-To: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
Message-ID: <nEe081zmXNTe54jvliGAslXj-AyRZB_ONXWM0xux5jI=.6396f8af-1314-4948-bfb5-7f22a0be4d62@github.com>

> Resolve memory leak related to `MethodData::_extra_data_lock` in `Method::build_profiling_method_data` by calling `MethodData::~MethodData()`.

Justin King has updated the pull request incrementally with one additional commit since the last revision:

  Add argument to MetadataFactory::free_metadata indicating whether destructor should be invoked
  
  Signed-off-by: Justin King <jcking at google.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11526/files
  - new: https://git.openjdk.org/jdk/pull/11526/files/fbced7d3..7295e140

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11526&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11526&range=01-02

  Stats: 14 lines in 2 files changed: 7 ins; 3 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/11526.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11526/head:pull/11526

PR: https://git.openjdk.org/jdk/pull/11526

From jcking at openjdk.org  Thu Dec  8 06:11:39 2022
From: jcking at openjdk.org (Justin King)
Date: Thu, 8 Dec 2022 06:11:39 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data [v2]
In-Reply-To: <s14hz9aYsn-tMZV1DJ80Fqux5MR-SsSIAvCYL_sjK20=.696674d1-f1f7-4375-8813-cd504a700977@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
 <s14hz9aYsn-tMZV1DJ80Fqux5MR-SsSIAvCYL_sjK20=.696674d1-f1f7-4375-8813-cd504a700977@github.com>
Message-ID: <jxHVaV2gHiHY9wqauhGc4moiBdF63BjLifxw89LE1Z8=.76f7ba9c-5bc7-4c01-aabe-674ecdc78717@github.com>

On Thu, 8 Dec 2022 05:01:11 GMT, Justin King <jcking at openjdk.org> wrote:

>> Resolve memory leak related to `MethodData::_extra_data_lock` in `Method::build_profiling_method_data` by calling `MethodData::~MethodData()`.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix memory leak by calling destructor
>   
>   Signed-off-by: Justin King <jcking at google.com>

> > Yeah, that is what I was thinking. [jcking at 5f1aad3](https://github.com/jcking/jdk/commit/5f1aad3723b56566428df7b4780ef2d5ca87f29d) is an example of this approach.
> 
> That is somewhat more elaborate/complex than I envisaged - and I'm not sure all those C++ features are usable in hotspot at present. Can we just add a specialized version of `free_metadata` for `MethodData` which takes the extra parameter?

That works for me, though all those features should be C++11 and C++14. Added a default argument to `MetadataFactory::free_metadata` that controls whether the destructor is invoked. If is false by default.

-------------

PR: https://git.openjdk.org/jdk/pull/11526

From jcking at openjdk.org  Thu Dec  8 06:14:48 2022
From: jcking at openjdk.org (Justin King)
Date: Thu, 8 Dec 2022 06:14:48 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data [v4]
In-Reply-To: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
Message-ID: <YZtV1CxSsTO5olTT4RuWCSwLWh5dZnAL1eEmmcH06C0=.e928d094-5ce0-417f-aef7-8e771a01f00b@github.com>

> Resolve memory leak related to `MethodData::_extra_data_lock` in `Method::build_profiling_method_data` by calling `MethodData::~MethodData()`.

Justin King has updated the pull request incrementally with one additional commit since the last revision:

  Update include order to be alphabetical
  
  Signed-off-by: Justin King <jcking at google.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11526/files
  - new: https://git.openjdk.org/jdk/pull/11526/files/7295e140..56004f54

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11526&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11526&range=02-03

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11526.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11526/head:pull/11526

PR: https://git.openjdk.org/jdk/pull/11526

From dholmes at openjdk.org  Thu Dec  8 06:32:04 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 8 Dec 2022 06:32:04 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data [v4]
In-Reply-To: <YZtV1CxSsTO5olTT4RuWCSwLWh5dZnAL1eEmmcH06C0=.e928d094-5ce0-417f-aef7-8e771a01f00b@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
 <YZtV1CxSsTO5olTT4RuWCSwLWh5dZnAL1eEmmcH06C0=.e928d094-5ce0-417f-aef7-8e771a01f00b@github.com>
Message-ID: <h7KvPsyWWvBuaGFAUvkKh4RNLh7YmTiFTrjeKkk5ZPA=.34594540-8f2f-4ff6-84b4-f1b06f83a0ac@github.com>

On Thu, 8 Dec 2022 06:14:48 GMT, Justin King <jcking at openjdk.org> wrote:

>> Resolve memory leak related to `MethodData::_extra_data_lock` in `Method::build_profiling_method_data` by calling `MethodData::~MethodData()`.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update include order to be alphabetical
>   
>   Signed-off-by: Justin King <jcking at google.com>

src/hotspot/share/memory/metadataFactory.hpp line 77:

> 75:       if (invoke_destructor) {
> 76:         using U = typename RemoveCV<typename RemovePointer<T>::type>::type;
> 77:         md->~U();

I was actually thinking of a template specialization for MethodData, but I guess this works. Lets see what others think.

-------------

PR: https://git.openjdk.org/jdk/pull/11526

From alanb at openjdk.org  Thu Dec  8 07:17:05 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 Dec 2022 07:17:05 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v2]
In-Reply-To: <34Xd2rKs-dAQSCf2dNwwrTZ3uFmFjCYsqagEF3aE0Z8=.e689feb9-dc85-4d24-af4a-e43f46276eb0@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
 <WgaYQgGsrCaoiwDikHOB0em7NhpCugMEVevsNKByQrE=.3a67835a-633c-4b29-be22-bcb2fc2ba40a@github.com>
 <y4lLPk5mDrJNa9vzgiI5WyEJmfbsSRfBBi0QQNdZeEs=.24e2a234-f42e-456f-82a0-3c7fd05dc9c5@github.com>
 <QYgHuAV90EyFwfNKauCVbQlKfWn9eBywsWGk57WrAgI=.21985534-6c5a-4bba-a35d-b727a6ae4ba4@github.com>
 <0olqajdnsOZJqQC5xBjXS3ckays3qNmgcYk4at6tsCc=.baeb2628-eee8-430c-a101-b93ad7a51e58@github.com>
 <34Xd2rKs-dAQSCf2dNwwrTZ3uFmFjCYsqagEF3aE0Z8=.e689feb9-dc85-4d24-af4a-e43f46276eb0@github.com>
Message-ID: <LdDnpIT5iW8JFAJtprJGs-z1U1HcTECso2eQdnpdnys=.cb280f52-91a7-4a0a-80bc-09c51a0476d5@github.com>

On Mon, 5 Dec 2022 17:30:24 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> I assume this function should therefore be named `is_module_observable`?
>
> How about this:
> 
> // Determines if the named module is present in the
> // modules jimage file or in the exploded modules directory.
> static bool is_module_observable(const char* module_name);

That looks okay to me. I don't have any other comments on this part.

-------------

PR: https://git.openjdk.org/jdk/pull/11513

From alanb at openjdk.org  Thu Dec  8 07:17:08 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 Dec 2022 07:17:08 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v5]
In-Reply-To: <ZSSq3Pl4Nu-BlC_ccliJcYZ9j297sAFUoybpgBrw0Uo=.5aeec02c-d235-4e07-bb23-bc038d512221@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
 <kU-NHwhiGEJLa7-o38UCemcxhU8WR_ijQBMGOAknOTs=.57d0341c-30af-4c39-ab42-4278fdfb2e5d@github.com>
 <-vjDxNaafm1m5UERR31dFXH7jdljWTKzsDjntS8v6zs=.4c777f1e-695f-42de-a4b5-0cb0f332243c@github.com>
 <ZSSq3Pl4Nu-BlC_ccliJcYZ9j297sAFUoybpgBrw0Uo=.5aeec02c-d235-4e07-bb23-bc038d512221@github.com>
Message-ID: <LZfRrVFPWdDMPWQzW_NBv-_emCUGS2Ok3Uj7QKXz844=.6a761d30-318d-4ecd-994a-06d36cad4169@github.com>

On Tue, 6 Dec 2022 15:44:28 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/vm/VMSupport.java line 106:
>> 
>>> 104:         }
>>> 105:         if (props.get("oome") != null) {
>>> 106:             throw new OutOfMemoryError("forced OOME");
>> 
>> I don't think code in java.base should be checking for a property named "oome".  Is this for a test that sets this system property on the command line?
>
> Sorry, that's debug code that I will remove.

Thanks, I couldn't see it set as a property anywhere so didn't know why it was there. I don't have any comments on this area.

-------------

PR: https://git.openjdk.org/jdk/pull/11513

From dnsimon at openjdk.org  Thu Dec  8 07:53:14 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 8 Dec 2022 07:53:14 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v7]
In-Reply-To: <Epv-jPCuClG7VfVJjqdP3FrqzDLnvxpqSmp_nx3eZP8=.6cabdece-b484-4b24-8d5f-8bdeb222a691@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
 <Epv-jPCuClG7VfVJjqdP3FrqzDLnvxpqSmp_nx3eZP8=.6cabdece-b484-4b24-8d5f-8bdeb222a691@github.com>
Message-ID: <Nba9HbLP9tyLc4OMqJUYru8j77jq2F_wFZfc47diafM=.94f14e64-ab6f-4c9f-9c85-b77f3f41366c@github.com>

On Wed, 7 Dec 2022 19:49:47 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Libgraal is compiled ahead of time and should not need any JVMCI Java code to be dynamically loaded at runtime. Prior to this PR, this is not the case due to:
>> 
>> * Code to copy system properties from the HotSpot heap into the libgraal heap. This is in `jdk.vm.ci.services.Services.initializeSavedProperties(byte[])` and `jdk.vm.ci.services.Services.serializeSavedProperties()`. This code should be moved to `java.base/jdk.internal.vm.VMSupport`.
>> * Code to translate exceptions from the HotSpot heap into the libgraal heap and vice versa. This code should be moved from `jdk.internal.vm.ci//jdk.vm.ci.hotspot.TranslatedException` to `java.base/jdk.internal.vm.VMSupport`.
>> 
>> This PR makes the above changes. As a result, it's possible to build a JDK image that includes (and uses) libgraal but does not include `jdk.internal.vm.ci` or `jdk.internal.vm.compiler`. This both reduces footprint and better isolates the JAVMCI and the Graal compiler as accessing these components from Java code is now impossible.
>
> Doug Simon 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 14 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'openjdk-jdk/master' into JDK-8298099
>  - formatting to avoid very long lines [skip ci]
>  - removed debug code [skip ci]
>  - clarify Properties filtering [skip ci]
>  - remove debug code [skip ci]
>  - incorporate review feedback [skip ci]
>  - removed hard-coded module name [skip ci]
>  - renamed is_module_resolvable to is_module_observable
>  - share code to create the exploded path for a module and avoid stack-based variable length array
>  - generalized ClassLoader::has_jvmci_module to is_module_resolvable
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/fbca1fb5...f5219b20

Sorry I checked with Alan over Slack who said to go ahead with merging.

-------------

PR: https://git.openjdk.org/jdk/pull/11513

From thartmann at openjdk.org  Thu Dec  8 07:54:06 2022
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 8 Dec 2022 07:54:06 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data [v4]
In-Reply-To: <YZtV1CxSsTO5olTT4RuWCSwLWh5dZnAL1eEmmcH06C0=.e928d094-5ce0-417f-aef7-8e771a01f00b@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
 <YZtV1CxSsTO5olTT4RuWCSwLWh5dZnAL1eEmmcH06C0=.e928d094-5ce0-417f-aef7-8e771a01f00b@github.com>
Message-ID: <D6GkgJuuRsENpiWDUHsmvZNTGRyDxYIs-hXGEZRBPzo=.8174fa03-0490-4e91-ab25-572390cbaab8@github.com>

On Thu, 8 Dec 2022 06:14:48 GMT, Justin King <jcking at openjdk.org> wrote:

>> Resolve memory leak related to `MethodData::_extra_data_lock` in `Method::build_profiling_method_data` by calling `MethodData::~MethodData()`.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update include order to be alphabetical
>   
>   Signed-off-by: Justin King <jcking at google.com>

Looks reasonable to me. A comment wouldn't hurt.

-------------

PR: https://git.openjdk.org/jdk/pull/11526

From alanb at openjdk.org  Thu Dec  8 07:56:14 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 Dec 2022 07:56:14 GMT
Subject: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at
 runtime [v7]
In-Reply-To: <Nba9HbLP9tyLc4OMqJUYru8j77jq2F_wFZfc47diafM=.94f14e64-ab6f-4c9f-9c85-b77f3f41366c@github.com>
References: <9rD0TyrGLQOgFlkz-f9973nzzg9YYPnWx7I33cDys8o=.e7a6039c-09f3-4cfd-b685-f640d613614a@github.com>
 <Epv-jPCuClG7VfVJjqdP3FrqzDLnvxpqSmp_nx3eZP8=.6cabdece-b484-4b24-8d5f-8bdeb222a691@github.com>
 <Nba9HbLP9tyLc4OMqJUYru8j77jq2F_wFZfc47diafM=.94f14e64-ab6f-4c9f-9c85-b77f3f41366c@github.com>
Message-ID: <6mFOj50jr2eBCcb8YkXYiyUij9h_1yUwDHehHxAkTXA=.2b014841-c6d4-4a7d-bbb0-3a1c906ed6eb@github.com>

On Thu, 8 Dec 2022 07:51:00 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> Sorry I checked with Alan over Slack who said to go ahead with merging.

Yeah, I was busy at the time and didn't get a chance to say that I didn't have any more comments/issues.

-------------

PR: https://git.openjdk.org/jdk/pull/11513

From jcking at openjdk.org  Thu Dec  8 08:13:15 2022
From: jcking at openjdk.org (Justin King)
Date: Thu, 8 Dec 2022 08:13:15 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data [v5]
In-Reply-To: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
Message-ID: <j9QbVLQK-gxpvw43cFizoCQcvNilShUiYHy6Yzn-yTE=.131eb1b0-48e2-49ff-808b-76d72c1a8605@github.com>

> Resolve memory leak related to `MethodData::_extra_data_lock` in `Method::build_profiling_method_data` by calling `MethodData::~MethodData()`.

Justin King has updated the pull request incrementally with one additional commit since the last revision:

  Add comments as suggested by review
  
  Signed-off-by: Justin King <jcking at google.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11526/files
  - new: https://git.openjdk.org/jdk/pull/11526/files/56004f54..1fc897dc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11526&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11526&range=03-04

  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11526.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11526/head:pull/11526

PR: https://git.openjdk.org/jdk/pull/11526

From pminborg at openjdk.org  Thu Dec  8 08:17:44 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 8 Dec 2022 08:17:44 GMT
Subject: RFR: 8298277: Replace "session" with "scope" for FFM access [v2]
In-Reply-To: <CexwefXXOExmjkTj8JOWdwKjXuUxnX6gUGc16_ZPFTk=.d6d26344-ed1f-4c26-9ef5-ab0daef3ca67@github.com>
References: <CexwefXXOExmjkTj8JOWdwKjXuUxnX6gUGc16_ZPFTk=.d6d26344-ed1f-4c26-9ef5-ab0daef3ca67@github.com>
Message-ID: <4y6q6GtQvTrNyp-oA_DtSESbC_jNHX5v1VxOaJRaiVQ=.1b5357b1-9bd3-43e3-8d53-7f4c5714e523@github.com>

> This PR suggests renaming various names from "session" to "scope" in accordance with https://openjdk.org/jeps/434
> 
> The PRs contains changes for several sub-components.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Revert renaming of MemorySessionImpl

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11573/files
  - new: https://git.openjdk.org/jdk/pull/11573/files/71a5e29c..39f09aa0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11573&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11573&range=00-01

  Stats: 172 lines in 25 files changed: 0 ins; 0 del; 172 mod
  Patch: https://git.openjdk.org/jdk/pull/11573.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11573/head:pull/11573

PR: https://git.openjdk.org/jdk/pull/11573

From jcking at openjdk.org  Thu Dec  8 08:19:28 2022
From: jcking at openjdk.org (Justin King)
Date: Thu, 8 Dec 2022 08:19:28 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data [v4]
In-Reply-To: <D6GkgJuuRsENpiWDUHsmvZNTGRyDxYIs-hXGEZRBPzo=.8174fa03-0490-4e91-ab25-572390cbaab8@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
 <YZtV1CxSsTO5olTT4RuWCSwLWh5dZnAL1eEmmcH06C0=.e928d094-5ce0-417f-aef7-8e771a01f00b@github.com>
 <D6GkgJuuRsENpiWDUHsmvZNTGRyDxYIs-hXGEZRBPzo=.8174fa03-0490-4e91-ab25-572390cbaab8@github.com>
Message-ID: <MnvF_KEP9Ttqeba89nWHRCvwuF59ynFN6zMlarvg678=.18549baf-8a1f-411f-be14-5230a730aae9@github.com>

On Thu, 8 Dec 2022 07:51:27 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Looks reasonable to me (took me a bit to understand the template metaprogamming involved). A comment wouldn't hurt.

Fair, added some comments.

-------------

PR: https://git.openjdk.org/jdk/pull/11526

From jcking at openjdk.org  Thu Dec  8 08:19:26 2022
From: jcking at openjdk.org (Justin King)
Date: Thu, 8 Dec 2022 08:19:26 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data [v6]
In-Reply-To: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
Message-ID: <wS4niiWCO0Q8K0kjLCtooIMF_KtVPO2_e3FgbVSP8W8=.5f798928-dc87-41e6-a856-89f9a633944a@github.com>

> Resolve memory leak related to `MethodData::_extra_data_lock` in `Method::build_profiling_method_data` by calling `MethodData::~MethodData()`.

Justin King has updated the pull request incrementally with one additional commit since the last revision:

  Add comment to metaprogramming usage
  
  Signed-off-by: Justin King <jcking at google.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11526/files
  - new: https://git.openjdk.org/jdk/pull/11526/files/1fc897dc..d745f437

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11526&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11526&range=04-05

  Stats: 6 lines in 1 file changed: 2 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/11526.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11526/head:pull/11526

PR: https://git.openjdk.org/jdk/pull/11526

From jcking at openjdk.org  Thu Dec  8 08:19:29 2022
From: jcking at openjdk.org (Justin King)
Date: Thu, 8 Dec 2022 08:19:29 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data [v6]
In-Reply-To: <dIOh3d-k_1YlfCAW7-erNNgNb5cNrbeZFyur12WxkFw=.945dc385-de8c-4416-b4be-bd05be7c8622@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
 <0pS4ATILRogqOh9329DopW2y5RWtuNoLJHJo3ceJtb0=.3eeb16a2-d5eb-4dbc-813c-79b8589472c6@github.com>
 <Yyu4NEdh3X-FO1Qr9HmxLYQXU2g3Z45UVkVnQPMdiaA=.046fda94-4ef8-457e-84d4-f4d197bbda80@github.com>
 <dIOh3d-k_1YlfCAW7-erNNgNb5cNrbeZFyur12WxkFw=.945dc385-de8c-4416-b4be-bd05be7c8622@github.com>
Message-ID: <115GRIwqnq7Id-mYRtQiWhWzNH586cg1sYA6uayl40c=.00b9c500-039c-4759-af7c-5af45a8d28ef@github.com>

On Wed, 7 Dec 2022 09:14:16 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> We can, but in general calling a member function after calling a destructor is likely undefined behavior. The lifetime of the object has ended.
>
> Right, I thought that it wouldn't make things worse because we already call the destructor in current code, but here we call `free_metadata` right after which performs all kinds of accesses on `method_data`. Not an option then.
> 
> @dholmes-ora Is that what you were suggesting when you said "not sure why it doesn't call the destructor to handle things as that is what the destructor is for"?

Copying reply from below.

> Yes - though as I said the memory management here is so convoluted that it is hard for me to see in detail if that is correct.

-------------

PR: https://git.openjdk.org/jdk/pull/11526

From thartmann at openjdk.org  Thu Dec  8 08:29:09 2022
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 8 Dec 2022 08:29:09 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data [v6]
In-Reply-To: <wS4niiWCO0Q8K0kjLCtooIMF_KtVPO2_e3FgbVSP8W8=.5f798928-dc87-41e6-a856-89f9a633944a@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
 <wS4niiWCO0Q8K0kjLCtooIMF_KtVPO2_e3FgbVSP8W8=.5f798928-dc87-41e6-a856-89f9a633944a@github.com>
Message-ID: <k5KLpS5YSOScTbMvOqSYN3wetkkBrOKKqwkOxKvhFsY=.41a34171-d887-4e2a-8a39-aa3271459ded@github.com>

On Thu, 8 Dec 2022 08:19:26 GMT, Justin King <jcking at openjdk.org> wrote:

>> Resolve memory leak related to `MethodData::_extra_data_lock` in `Method::build_profiling_method_data` by calling `MethodData::~MethodData()`.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment to metaprogramming usage
>   
>   Signed-off-by: Justin King <jcking at google.com>

Thanks. Looks good to me.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11526

From stuefe at openjdk.org  Thu Dec  8 08:56:17 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 8 Dec 2022 08:56:17 GMT
Subject: RFR: JDK-8298298: NMT: count deltas are printed with 32-bit signed
 size [v2]
In-Reply-To: <ZbO2OJmcF2KfCodEuccCdLaT9uqDahRmqn8d3juth5A=.f5c5704b-0a92-4307-b5cd-b37516140eaa@github.com>
References: <ZbO2OJmcF2KfCodEuccCdLaT9uqDahRmqn8d3juth5A=.f5c5704b-0a92-4307-b5cd-b37516140eaa@github.com>
Message-ID: <Gag2hO344ircxvvTl2mNObf-37vL0-YuQnuRvUtpIJI=.384b5d4f-b930-4942-86c4-993b1cc05d47@github.com>

> Deltas for counts in NMT differential reports are shown as signed int, restricting them to +-2g. These counts are number of malloc blocks, or number of classes, or number of threads. In all cases number of physically existing somethings.
> 
> On large 64-bit machines they can conceivably overflow. Well, at least the malloc block counters. Granted, mallocing even just >2g number of 1 byte blocks costs about 40-50GB due to overhead in libc and NMT (on glibc). But it is conceivable.
> 
> Patch changes delta printing from int to ssize_t.
> 
> Note that I don't worry about overflowing SSIZE_MIN or SSIZE_MAX here. That would be ridiculous: we just cannot have that many physically existing things. Not on 64bit, not even on 32-bit where ssize_t is int, since in both cases the address space would be the limit. So, if the counters are that large, we have a different problem (probably counter overflow), and so we assert, resp. in release, ignore it.
> 
> Note we have the same problem with diff sizes. I expect [8281213](https://bugs.openjdk.org/browse/JDK-8281213) to fix that.

Thomas Stuefe 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 three additional commits since the last revision:

 - Factor out delta-ing and assert ranges
 - Merge branch 'master' into JDK-8298298-nmt-count-deltas-32-bit
 - JDK-8298298-nmt-count-deltas-32-bit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11568/files
  - new: https://git.openjdk.org/jdk/pull/11568/files/a92ff83d..22a577f2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11568&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11568&range=00-01

  Stats: 6052 lines in 110 files changed: 4114 ins; 1510 del; 428 mod
  Patch: https://git.openjdk.org/jdk/pull/11568.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11568/head:pull/11568

PR: https://git.openjdk.org/jdk/pull/11568

From aboldtch at openjdk.org  Thu Dec  8 09:01:08 2022
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 8 Dec 2022 09:01:08 GMT
Subject: RFR: 8297235: ZGC: assert(regs[i] != regs[j]) failed: Multiple
 uses of register: rax [v3]
In-Reply-To: <jYsSVWwRPyRKvs8HYIwp6Ar5Z0XISOwp1DM4A0AgdOQ=.378c74fb-a4e1-45a5-82b0-838c2fcba43a@github.com>
References: <jYsSVWwRPyRKvs8HYIwp6Ar5Z0XISOwp1DM4A0AgdOQ=.378c74fb-a4e1-45a5-82b0-838c2fcba43a@github.com>
Message-ID: <0fGmbCvEUHokqoFR0ndPwd7yA5I_SS-MlBneCPP3LqY=.c4b67306-e5bb-4af5-8875-adba9ea9d0f1@github.com>

> Tests java/util/stream/test/org/openjdk/tests/java/util/* with -XX:+UseZGC -Xcomp -XX:-TieredCompilation crashes with `assert(regs[i] != regs[j]) failed: Multiple uses of register: rax`. More specifically compilation of java.util.concurrent.ForkJoinTask::awaitDone.
> 
> The reason seems to be that the compare value and the memory input ends up sharing a register. (Uses Unsafe CAS which CAS an object reference into a field of that object, `oldval: rax` and `mem: [rax+offset]`). The Z load barrier stub dispatch implementation require that the reference and reference address occupy distinct registers. In the loadP nodes this is established by marking all but the memory TEMP which results in no sharing.
> 
> This is not possible for the CompareAndSwapP / CompareAndExchangeP nodes as the compare value is an input node. 
> 
> The solution proposed here is less than ideal as it makes the CAS nodes require one extra TEMP register, which in the common case is unused. This puts unnecessary extra strain on the register allocation. The problem is that there is no way currently (that I can find) to express in .ad that a memory input must not share registers with a specific other input. 
> 
> There is an alternative solution for this specific crash which does not use a second TEMP register (see commit: cfd5ced4e97e986fc10c5a8721b543cd3101c58a). It accomplish this by using the same trick that the aarch64 Z CAS node uses which is to specify the memory as indirect which results in the address being LEA into a register. However from what I can see this does not guarantee that the address and the reference does not share a register (`oldval: rax` and `mem: [rax]`). So it is theoretically broken, (and so is the aarch64 implementation). 
> 
> It is unclear to me if there is ever a way for C2 to generation a CAS which compares the address of the field with its content. 
> 
> I call on anyone with more knowledge about `adlc` and `C2` for feedback. And specifically I want to open up a discussion with these points:
> * Is there some other way of expressing in the .ad file that a memory input should not share some register?
>   * If not, is this a worthwhile RFE? As it seems to be a patterned used at least in other places in Z.
> * Will the indirect input ever share a register with oldval and/or are the aarch64/riscv implementations broken because of this? How about ppc?
> 
> Testing: linux-x64 zgc tagged tests tier 1-7 and some specific crashing tests with `-XX:+UseZGC -Xcomp -XX:-TieredCompilation` (in: java/util/stream/, java/util/concurrent/)

Axel Boldt-Christmas 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 commits since the last revision:

 - Remove problem listed tests
 - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8297235
 - indirect zXChgP as well
 - indirect alternative
 - JDK-8297235: ZGC: assert(regs[i] != regs[j]) failed: Multiple uses of register: rax

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11410/files
  - new: https://git.openjdk.org/jdk/pull/11410/files/42a72c1e..0c715331

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11410&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11410&range=01-02

  Stats: 116454 lines in 1834 files changed: 56104 ins; 41536 del; 18814 mod
  Patch: https://git.openjdk.org/jdk/pull/11410.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11410/head:pull/11410

PR: https://git.openjdk.org/jdk/pull/11410

From stuefe at openjdk.org  Thu Dec  8 09:07:09 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 8 Dec 2022 09:07:09 GMT
Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v18]
In-Reply-To: <ZXz5ouPFy3NE2vq1ymjOLWsp2OsvsEuAcsPDKjPpOLs=.5aac3ce6-38ed-49f2-b28d-3a0106eced05@github.com>
References: <fWd_NIunUhDXwy8uZSno90GC-PM8pFCey-pAMxxO0rI=.0fede0e4-1438-4321-bc8d-d11565389cae@github.com>
 <ZXz5ouPFy3NE2vq1ymjOLWsp2OsvsEuAcsPDKjPpOLs=.5aac3ce6-38ed-49f2-b28d-3a0106eced05@github.com>
Message-ID: <9SD4Q9Q0iaiFRmRKJg-BIvEnD2OOh24o--wyY5pz9hY=.fb56475d-230b-47e0-9044-42dd930338aa@github.com>

On Wed, 7 Dec 2022 21:25:11 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> May I have this update reviewed?
>> 
>> The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure.  The build could pass if warnings are disabled for codes that use sprintf method.  For the long run, the sprintf could be replaced with snprintf.  This patch is trying to check if snprintf could be used.
>> 
>> Thanks,
>> Xuelei
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update on review feedback

Good from my side. But someone else should look as well. It's fiddly stuff.

-------------

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11115

From qamai at openjdk.org  Thu Dec  8 09:14:19 2022
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 8 Dec 2022 09:14:19 GMT
Subject: RFR: 8292289: [vectorapi] Improve the implementation of
 VectorTestNode [v14]
In-Reply-To: <MeWOERLVkAl7rrsPqAFR23UeiLCntkyPM5jqerJXtEU=.1d987dbb-9b2b-4d4b-811e-47b5f46f635a@github.com>
References: <IcR6eOr6iM1b9B1I1zUQnI2J9hQAmdSRHYc9CdIGW5E=.3b8dd64d-2eff-4659-b75a-81c4b008e41a@github.com>
 <Jo8mnLoA_9Pb8TzocN6zG5s2PGGVxS53s6XP_5CasLo=.de864d1a-51b5-4ceb-b12d-1d20e34735d7@github.com>
 <MeWOERLVkAl7rrsPqAFR23UeiLCntkyPM5jqerJXtEU=.1d987dbb-9b2b-4d4b-811e-47b5f46f635a@github.com>
Message-ID: <VsyNu6ZZz8vRIVBl_y_Yg7cj1k5NXmJEAd1yBe7eN2o=.a0c2dc46-2064-47f7-8929-9ba1cf963c12@github.com>

On Wed, 7 Dec 2022 18:45:06 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix test
>
> Rerunning DaCapo and Renaissance which shows some variations.

@vnkozlov I believe `VectorTestNode` is only used in Vector API, which should not affect those benchmarks?

-------------

PR: https://git.openjdk.org/jdk/pull/9855

From kvn at openjdk.org  Thu Dec  8 09:24:06 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 8 Dec 2022 09:24:06 GMT
Subject: RFR: 8292289: [vectorapi] Improve the implementation of
 VectorTestNode [v14]
In-Reply-To: <Jo8mnLoA_9Pb8TzocN6zG5s2PGGVxS53s6XP_5CasLo=.de864d1a-51b5-4ceb-b12d-1d20e34735d7@github.com>
References: <IcR6eOr6iM1b9B1I1zUQnI2J9hQAmdSRHYc9CdIGW5E=.3b8dd64d-2eff-4659-b75a-81c4b008e41a@github.com>
 <Jo8mnLoA_9Pb8TzocN6zG5s2PGGVxS53s6XP_5CasLo=.de864d1a-51b5-4ceb-b12d-1d20e34735d7@github.com>
Message-ID: <pz7bbehqMFM40rjV8dwg8LLtZiLyfYualjfY52E_-9A=.27e1a72e-bec6-47bb-8975-a9ac50dc8839@github.com>

On Tue, 6 Dec 2022 14:24:39 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> This patch modifies the node generation of `VectorSupport::test` to emit a `CMoveINode`, which is picked up by `BoolNode::Ideal(PhaseGVN*, bool)` to connect the `VectorTestNode` directly to the `BoolNode`, removing the redundant operations of materialising the test result in a GP register and do a `CmpI` to get back the flags. As a result, `VectorMask<T>::alltrue` is compiled into machine codes:
>> 
>>         vptest xmm0, xmm1
>>         jb if_true
>>     if_false:
>> 
>> instead of:
>> 
>>         vptest xmm0, xmm1
>>         setb r10
>>         movzbl r10
>>         testl r10
>>         jne if_true
>>     if_false:
>> 
>> The results of `jdk.incubator.vector.ArrayMismatchBenchmark` shows noticeable improvements:
>> 
>>                                                                                        Before                  After
>>     Benchmark                                      Prefix    Size   Mode  Cnt       Score      Error       Score     Error    Units  Change
>>     ArrayMismatchBenchmark.mismatchVectorByte         0.5       9  thrpt   10  217345.383 ? 8316.444  222279.381 ? 2660.983  ops/ms   +2.3%
>>     ArrayMismatchBenchmark.mismatchVectorByte         0.5     257  thrpt   10  113918.406 ? 1618.836  116268.691 ? 1291.899  ops/ms   +2.1%
>>     ArrayMismatchBenchmark.mismatchVectorByte         0.5  100000  thrpt   10     702.066 ?   72.862     797.806 ?   16.429  ops/ms  +13.6%
>>     ArrayMismatchBenchmark.mismatchVectorByte         1.0       9  thrpt   10  146096.564 ? 2401.258  145338.910 ?  687.453  ops/ms   -0.5%
>>     ArrayMismatchBenchmark.mismatchVectorByte         1.0     257  thrpt   10   60598.181 ? 1259.397   69041.519 ? 1073.156  ops/ms  +13.9%
>>     ArrayMismatchBenchmark.mismatchVectorByte         1.0  100000  thrpt   10     316.814 ?   10.975     408.770 ?    5.281  ops/ms  +29.0%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       0.5       9  thrpt   10  195674.549 ? 1200.166  188482.433 ? 1872.076  ops/ms   -3.7%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       0.5     257  thrpt   10   44357.169 ?  473.013   42293.411 ? 2838.255  ops/ms   -4.7%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       0.5  100000  thrpt   10      68.199 ?    5.410      67.628 ?    3.241  ops/ms   -0.8%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       1.0       9  thrpt   10  107722.450 ? 1677.607  111060.400 ?  982.230  ops/ms   +3.1%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       1.0     257  thrpt   10   16692.645 ? 1002.599   21440.506 ? 1618.266  ops/ms  +28.4%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       1.0  100000  thrpt   10      32.984 ?    0.548      33.202 ?    2.365  ops/ms   +0.7%
>>     ArrayMismatchBenchmark.mismatchVectorInt          0.5       9  thrpt   10  335458.217 ? 3154.842  379944.254 ? 5703.134  ops/ms  +13.3%
>>     ArrayMismatchBenchmark.mismatchVectorInt          0.5     257  thrpt   10   58505.302 ?  786.312   56721.368 ? 2497.052  ops/ms   -3.0%
>>     ArrayMismatchBenchmark.mismatchVectorInt          0.5  100000  thrpt   10     133.037 ?   11.415     139.537 ?    4.667  ops/ms   +4.9%
>>     ArrayMismatchBenchmark.mismatchVectorInt          1.0       9  thrpt   10  117943.802 ? 2281.349  112409.365 ? 2110.055  ops/ms   -4.7%
>>     ArrayMismatchBenchmark.mismatchVectorInt          1.0     257  thrpt   10   27060.015 ?  795.619   33756.613 ?  826.533  ops/ms  +24.7%
>>     ArrayMismatchBenchmark.mismatchVectorInt          1.0  100000  thrpt   10      57.558 ?    8.927      66.951 ?    4.381  ops/ms  +16.3%
>>     ArrayMismatchBenchmark.mismatchVectorLong         0.5       9  thrpt   10  182963.715 ? 1042.497  182438.405 ? 2120.832  ops/ms   -0.3%
>>     ArrayMismatchBenchmark.mismatchVectorLong         0.5     257  thrpt   10   36672.215 ?  614.821   35397.398 ? 1609.235  ops/ms   -3.5%
>>     ArrayMismatchBenchmark.mismatchVectorLong         0.5  100000  thrpt   10      66.438 ?    2.142      65.427 ?    2.270  ops/ms   -1.5%
>>     ArrayMismatchBenchmark.mismatchVectorLong         1.0       9  thrpt   10  110393.047 ?  497.853  115165.845 ? 5381.674  ops/ms   +4.3%
>>     ArrayMismatchBenchmark.mismatchVectorLong         1.0     257  thrpt   10   14720.765 ?  661.350   19871.096 ?  201.464  ops/ms  +35.0%
>>     ArrayMismatchBenchmark.mismatchVectorLong         1.0  100000  thrpt   10      30.760 ?    0.821      31.933 ?    1.352  ops/ms   +3.8%
>> 
>> I have not been able to conduct throughout testing on AVX512 and Aarch64 so any help would be invaluable. Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix test

Marked as reviewed by kvn (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9855

From kvn at openjdk.org  Thu Dec  8 09:24:09 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 8 Dec 2022 09:24:09 GMT
Subject: RFR: 8292289: [vectorapi] Improve the implementation of
 VectorTestNode [v14]
In-Reply-To: <MeWOERLVkAl7rrsPqAFR23UeiLCntkyPM5jqerJXtEU=.1d987dbb-9b2b-4d4b-811e-47b5f46f635a@github.com>
References: <IcR6eOr6iM1b9B1I1zUQnI2J9hQAmdSRHYc9CdIGW5E=.3b8dd64d-2eff-4659-b75a-81c4b008e41a@github.com>
 <Jo8mnLoA_9Pb8TzocN6zG5s2PGGVxS53s6XP_5CasLo=.de864d1a-51b5-4ceb-b12d-1d20e34735d7@github.com>
 <MeWOERLVkAl7rrsPqAFR23UeiLCntkyPM5jqerJXtEU=.1d987dbb-9b2b-4d4b-811e-47b5f46f635a@github.com>
Message-ID: <wUvjUsdbWh3bH5EpbfM2R6b4jPKd3qDvk4GbOOaE8HY=.a1a3b206-8f73-44b3-9afb-a087a0b74001@github.com>

On Wed, 7 Dec 2022 18:45:06 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix test
>
> Rerunning DaCapo and Renaissance which shows some variations.

> @vnkozlov I believe `VectorTestNode` is only used in Vector API, which should not affect those benchmarks?

Yes, but you have changes in general code related to `Cmp` node.
I see that DaCapo don't show regression after rerun. Renaissance is still running and numbers are "all over places" - it is not stable.

Anyway, I am approving this changes based on data I got.

-------------

PR: https://git.openjdk.org/jdk/pull/9855

From lbourges at openjdk.org  Thu Dec  8 09:47:14 2022
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Thu, 8 Dec 2022 09:47:14 GMT
Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v18]
In-Reply-To: <ZXz5ouPFy3NE2vq1ymjOLWsp2OsvsEuAcsPDKjPpOLs=.5aac3ce6-38ed-49f2-b28d-3a0106eced05@github.com>
References: <fWd_NIunUhDXwy8uZSno90GC-PM8pFCey-pAMxxO0rI=.0fede0e4-1438-4321-bc8d-d11565389cae@github.com>
 <ZXz5ouPFy3NE2vq1ymjOLWsp2OsvsEuAcsPDKjPpOLs=.5aac3ce6-38ed-49f2-b28d-3a0106eced05@github.com>
Message-ID: <UkJ3bNkFSLgngGKNO4XnQP98wRfdMcxpWfIJ-OLg82M=.fb9dcc4d-1656-43f0-8465-a41fd678d5e7@github.com>

On Wed, 7 Dec 2022 21:25:11 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> May I have this update reviewed?
>> 
>> The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure.  The build could pass if warnings are disabled for codes that use sprintf method.  For the long run, the sprintf could be replaced with snprintf.  This patch is trying to check if snprintf could be used.
>> 
>> Thanks,
>> Xuelei
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update on review feedback

I will try building openjdk20 with this patch tonight on mbp 2015, macos 13, xcode 14...

-------------

PR: https://git.openjdk.org/jdk/pull/11115

From shade at openjdk.org  Thu Dec  8 10:39:33 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 8 Dec 2022 10:39:33 GMT
Subject: RFR: JDK-8298298: NMT: count deltas are printed with 32-bit signed
 size [v2]
In-Reply-To: <Gag2hO344ircxvvTl2mNObf-37vL0-YuQnuRvUtpIJI=.384b5d4f-b930-4942-86c4-993b1cc05d47@github.com>
References: <ZbO2OJmcF2KfCodEuccCdLaT9uqDahRmqn8d3juth5A=.f5c5704b-0a92-4307-b5cd-b37516140eaa@github.com>
 <Gag2hO344ircxvvTl2mNObf-37vL0-YuQnuRvUtpIJI=.384b5d4f-b930-4942-86c4-993b1cc05d47@github.com>
Message-ID: <F0j7gWkZgd6v0bhR27-o8ZT6IU9mtslH577QRueuGTY=.38d75256-1768-4935-b944-05655347c225@github.com>

On Thu, 8 Dec 2022 08:56:17 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Deltas for counts in NMT differential reports are shown as signed int, restricting them to +-2g. These counts are number of malloc blocks, or number of classes, or number of threads. In all cases number of physically existing somethings.
>> 
>> On large 64-bit machines they can conceivably overflow. Well, at least the malloc block counters. Granted, mallocing even just >2g number of 1 byte blocks costs about 40-50GB due to overhead in libc and NMT (on glibc). But it is conceivable.
>> 
>> Patch changes delta printing from int to ssize_t.
>> 
>> Note that I don't worry about overflowing SSIZE_MIN or SSIZE_MAX here. That would be ridiculous: we just cannot have that many physically existing things. Not on 64bit, not even on 32-bit where ssize_t is int, since in both cases the address space would be the limit. So, if the counters are that large, we have a different problem (probably counter overflow), and so we assert, resp. in release, ignore it.
>> 
>> Note we have the same problem with diff sizes. I expect [8281213](https://bugs.openjdk.org/browse/JDK-8281213) to fix that.
>
> Thomas Stuefe 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 three additional commits since the last revision:
> 
>  - Factor out delta-ing and assert ranges
>  - Merge branch 'master' into JDK-8298298-nmt-count-deltas-32-bit
>  - JDK-8298298-nmt-count-deltas-32-bit

Looks okay to me.

Windows builds are failing in GHA, though.

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11568

From stefank at openjdk.org  Thu Dec  8 11:13:54 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 8 Dec 2022 11:13:54 GMT
Subject: RFR: 8298376: ZGC: thaws stackChunk with stale oops
Message-ID: <HoYZilP9V9gNhBjvJzCmxzE2wMzs5TmM_qjZZof_fi4=.0819f7cc-ec68-4847-a46a-3af928339415@github.com>

During the recent ZGC + Loom rewrites JDK-8296875 a bug was introduced, which causes Loom to thaw stackChunks with stale oops.

Before that change we made sure that only the GC performed load barriers on the cont oop in stackChunk, so that we could use the oop state as an indication of the age of the stackChunk. That information was then used in ZCollectedHeap::requires_barriers.

In Generational ZGC we changed the implementation of requires_barriers, so that the rest of the JVM didn't need to have special-handling of the cont oop. However, when upstreaming the changes in JDK-8296875 we purposefully didn't update requires_barriers, but we incorrectly brought over the removal of the special-handling of the cont oop.

To limit the fix for this bug, I propose that we restore the special-handling of the cont oop.

I've tested this with a reproducer running Fuzz.java + ZGC.

-------------

Depends on: https://git.openjdk.org/jdk/pull/11582

Commit messages:
 - 8298376: ZGC: thaws stackChunk with stale oops

Changes: https://git.openjdk.org/jdk/pull/11585/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11585&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298376
  Stats: 19 lines in 4 files changed: 15 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/11585.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11585/head:pull/11585

PR: https://git.openjdk.org/jdk/pull/11585

From duke at openjdk.org  Thu Dec  8 11:14:05 2022
From: duke at openjdk.org (Afshin Zafari)
Date: Thu, 8 Dec 2022 11:14:05 GMT
Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v4]
In-Reply-To: <Dj9YfY10SLn8dR1Ez3kEQe4tXm1q5W1TS8_4r3gBUsY=.6c38825a-86e5-4575-a509-683786d242a6@github.com>
References: <Dj9YfY10SLn8dR1Ez3kEQe4tXm1q5W1TS8_4r3gBUsY=.6c38825a-86e5-4575-a509-683786d242a6@github.com>
Message-ID: <Fq2lfQygbSjTFlG4wiRruydTKlcIx01PCvonxvWTKwM=.47daff44-6d56-4dba-843b-56508285542c@github.com>

> test of tier1-5 passed.

Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Merge branch 'jvmti_tagmap' of http://github.com/afshin-zafari/jdk into jvmti_tagmap
 - 8292741: Convert JvmtiTagMapTable to ResourceHashtable
 - 8292741: Convert JvmtiTagMapTable to ResourceHashtable
 - Merge branch 'jvmti_tagmap' of http://github.com/afshin-zafari/jdk into jvmti_tagmap
 - JBS-8292741: Convert JvmtiTagMapTable to ResourceHashtable
 - 8292741: Convert JvmtiTagMapTable to ResourceHashtable
 - 8292741: Convert JvmtiTagMapTable to ResourceHashtable
 - Added update interface instead of Remove-Add pair.
 - JBS-8292741: Convert JvmtiTagMapTable to ResourceHashtable
 - Clean commit.

-------------

Changes: https://git.openjdk.org/jdk/pull/11288/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11288&range=03
  Stats: 282 lines in 4 files changed: 42 ins; 104 del; 136 mod
  Patch: https://git.openjdk.org/jdk/pull/11288.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11288/head:pull/11288

PR: https://git.openjdk.org/jdk/pull/11288

From stefank at openjdk.org  Thu Dec  8 11:31:49 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 8 Dec 2022 11:31:49 GMT
Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC
Message-ID: <BOJ4yH2GtNWXDVXMKwPw9Ic359dnBK8Sb9tDw3a5Qmc=.197acbb0-3ed6-418f-8bcf-70ef4b67de5e@github.com>

The JfrVFrameStream is used while generating stack traces for events. One of the events are the ZPage allocation event. This event is sometimes sent when ZGC is relocating. The current implementation of JfrVFrameStream uses WalkContinuation::include, which causes JFR to walk the continuation and perform GC barriers. This is problematic, since ZGC has a requirement that we never perform load barriers while running the relocation code. If we do, we might end up performing other reloctions from the the relocation code, and in some cases that causes dead locks.

I propose that JFR doesn't walk the continuations when sending events. An alternative could be to limit this to ZGC, but I'd like to get some feedback around that from JFR / Loom devs.

We've been testing this patch in the Generational ZGC repository.

-------------

Commit messages:
 - 8298377: JfrVframeStream causes deadlocks in ZGC

Changes: https://git.openjdk.org/jdk/pull/11586/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11586&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298377
  Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11586.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11586/head:pull/11586

PR: https://git.openjdk.org/jdk/pull/11586

From eosterlund at openjdk.org  Thu Dec  8 11:34:11 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 8 Dec 2022 11:34:11 GMT
Subject: RFR: 8298376: ZGC: thaws stackChunk with stale oops
In-Reply-To: <HoYZilP9V9gNhBjvJzCmxzE2wMzs5TmM_qjZZof_fi4=.0819f7cc-ec68-4847-a46a-3af928339415@github.com>
References: <HoYZilP9V9gNhBjvJzCmxzE2wMzs5TmM_qjZZof_fi4=.0819f7cc-ec68-4847-a46a-3af928339415@github.com>
Message-ID: <KYy0YQfut4ZQtUi9DcmqThygNkS7FJQcTPVvhoAqkew=.2d01c452-e83b-42d5-95bb-50aaf053178a@github.com>

On Thu, 8 Dec 2022 11:05:10 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> During the recent ZGC + Loom rewrites JDK-8296875 a bug was introduced, which causes Loom to thaw stackChunks with stale oops.
> 
> Before that change we made sure that only the GC performed load barriers on the cont oop in stackChunk, so that we could use the oop state as an indication of the age of the stackChunk. That information was then used in ZCollectedHeap::requires_barriers.
> 
> In Generational ZGC we changed the implementation of requires_barriers, so that the rest of the JVM didn't need to have special-handling of the cont oop. However, when upstreaming the changes in JDK-8296875 we purposefully didn't update requires_barriers, but we incorrectly brought over the removal of the special-handling of the cont oop.
> 
> To limit the fix for this bug, I propose that we restore the special-handling of the cont oop.
> 
> I've tested this with a reproducer running Fuzz.java + ZGC.

Looks good.

-------------

Marked as reviewed by eosterlund (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11585

From egahlin at openjdk.org  Thu Dec  8 12:05:06 2022
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 8 Dec 2022 12:05:06 GMT
Subject: Integrated: 8298175: JFR: Common timestamp for periodic events
In-Reply-To: <4bP-aYZidz-BbflACIv0qfc_8dpSNF6INArPJJ9wJQo=.a57084a7-d403-4975-a524-f33a2f0cf1fa@github.com>
References: <4bP-aYZidz-BbflACIv0qfc_8dpSNF6INArPJJ9wJQo=.a57084a7-d403-4975-a524-f33a2f0cf1fa@github.com>
Message-ID: <bqyTuaesvE_sZqkSZTavF09YjGrWVfB1pvBkNOQoKdM=.75c538bb-1671-4abd-948d-69240791fff2@github.com>

On Tue, 6 Dec 2022 15:31:22 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of infrastructure that makes it easier to write periodic events with the same timestamp.
> 
> Testing: jdk/jdk/jfr + tier1 + tier2
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: 9353899b
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9353899bc5564827826ed94c0530497ff828e01b
Stats:     48 lines in 6 files changed: 25 ins; 3 del; 20 mod

8298175: JFR: Common timestamp for periodic events

Reviewed-by: dholmes, mgronlun

-------------

PR: https://git.openjdk.org/jdk/pull/11541

From pminborg at openjdk.org  Thu Dec  8 13:05:00 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 8 Dec 2022 13:05:00 GMT
Subject: RFR: 8298277: Replace "session" with "scope" for FFM access [v2]
In-Reply-To: <4y6q6GtQvTrNyp-oA_DtSESbC_jNHX5v1VxOaJRaiVQ=.1b5357b1-9bd3-43e3-8d53-7f4c5714e523@github.com>
References: <CexwefXXOExmjkTj8JOWdwKjXuUxnX6gUGc16_ZPFTk=.d6d26344-ed1f-4c26-9ef5-ab0daef3ca67@github.com>
 <4y6q6GtQvTrNyp-oA_DtSESbC_jNHX5v1VxOaJRaiVQ=.1b5357b1-9bd3-43e3-8d53-7f4c5714e523@github.com>
Message-ID: <RlgO9nlJZIXTZ4fz3RsmY31lFV-y2rgtA32PCV-pg7E=.0ce4621b-b503-4c5a-bc4d-3e7faeacdf3d@github.com>

On Thu, 8 Dec 2022 08:17:44 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR suggests renaming various names from "session" to "scope" in accordance with https://openjdk.org/jeps/434
>> 
>> The PRs contains changes for several sub-components.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert renaming of MemorySessionImpl

I am going to close this PR in favor of several other smaller ones.

-------------

PR: https://git.openjdk.org/jdk/pull/11573

From pminborg at openjdk.org  Thu Dec  8 13:05:03 2022
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 8 Dec 2022 13:05:03 GMT
Subject: Withdrawn: 8298277: Replace "session" with "scope" for FFM access
In-Reply-To: <CexwefXXOExmjkTj8JOWdwKjXuUxnX6gUGc16_ZPFTk=.d6d26344-ed1f-4c26-9ef5-ab0daef3ca67@github.com>
References: <CexwefXXOExmjkTj8JOWdwKjXuUxnX6gUGc16_ZPFTk=.d6d26344-ed1f-4c26-9ef5-ab0daef3ca67@github.com>
Message-ID: <0LEwHE6mc-JRS1H07g0SE-jUVPFapFVFxJrreAT8EJI=.a3ed1f57-6126-4324-97c8-86d69f2b67d6@github.com>

On Wed, 7 Dec 2022 21:55:43 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR suggests renaming various names from "session" to "scope" in accordance with https://openjdk.org/jeps/434
> 
> The PRs contains changes for several sub-components.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/11573

From mgronlun at openjdk.org  Thu Dec  8 13:32:03 2022
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 8 Dec 2022 13:32:03 GMT
Subject: RFR: 8298379: JFR: Some UNTIMED events only sets endTime
Message-ID: <HvYT0wt_TeV1cffNx4DD_8cI5AR4ijQpvM_sGTO2RCg=.4293f248-d7b1-442a-bfb3-40f008779ab3@github.com>

Greetings,

It was pointed out that some UNTIMED events only call set_endtime(), and not the corresponding set_starttime(), for example some events in jfrPeriodic.cpp. UNTIMED events need to have both timestamps set, because the UNTIMED parameter denotes that the user takes on the responsibility for controlling time stamping.

This change rectifies a few places by adding the corresponding set_starttime() call.

Test: jdk_jfr

Thanks
Markus

-------------

Commit messages:
 - 8298379

Changes: https://git.openjdk.org/jdk/pull/11592/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11592&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298379
  Stats: 13 lines in 5 files changed: 9 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/11592.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11592/head:pull/11592

PR: https://git.openjdk.org/jdk/pull/11592

From ehelin at openjdk.org  Thu Dec  8 13:32:05 2022
From: ehelin at openjdk.org (Erik Helin)
Date: Thu, 8 Dec 2022 13:32:05 GMT
Subject: RFR: 8298379: JFR: Some UNTIMED events only sets endTime
In-Reply-To: <HvYT0wt_TeV1cffNx4DD_8cI5AR4ijQpvM_sGTO2RCg=.4293f248-d7b1-442a-bfb3-40f008779ab3@github.com>
References: <HvYT0wt_TeV1cffNx4DD_8cI5AR4ijQpvM_sGTO2RCg=.4293f248-d7b1-442a-bfb3-40f008779ab3@github.com>
Message-ID: <_vV4fX4JHzRPYOzuVDNdeTPUxsHjiJ72408DYnwxQ8o=.0a1b2de6-a179-4734-8548-c40bb52d08bb@github.com>

On Thu, 8 Dec 2022 13:22:35 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> It was pointed out that some UNTIMED events only call set_endtime(), and not the corresponding set_starttime(), for example some events in jfrPeriodic.cpp. UNTIMED events need to have both timestamps set, because the UNTIMED parameter denotes that the user takes on the responsibility for controlling time stamping.
> 
> This change rectifies a few places by adding the corresponding set_starttime() call.
> 
> Test: jdk_jfr
> 
> Thanks
> Markus

src/hotspot/share/gc/shared/objectCountEventSender.cpp line 57:

> 55:   T event(UNTIMED);
> 56:   if (event.should_commit()) {
> 57:     event.set_endtime(timestamp);

Suggestion:

    event.set_starttime(timestamp);

-------------

PR: https://git.openjdk.org/jdk/pull/11592

From mgronlun at openjdk.org  Thu Dec  8 13:36:53 2022
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 8 Dec 2022 13:36:53 GMT
Subject: RFR: 8298379: JFR: Some UNTIMED events only sets endTime [v2]
In-Reply-To: <HvYT0wt_TeV1cffNx4DD_8cI5AR4ijQpvM_sGTO2RCg=.4293f248-d7b1-442a-bfb3-40f008779ab3@github.com>
References: <HvYT0wt_TeV1cffNx4DD_8cI5AR4ijQpvM_sGTO2RCg=.4293f248-d7b1-442a-bfb3-40f008779ab3@github.com>
Message-ID: <Qc56rriHGrpaIngHSdqA8fKnUSDwmYfEksyplCQkjLg=.2b12a8bc-cc5d-41c2-8864-922d707f08ed@github.com>

> Greetings,
> 
> It was pointed out that some UNTIMED events only call set_endtime(), and not the corresponding set_starttime(), for example some events in jfrPeriodic.cpp. UNTIMED events need to have both timestamps set, because the UNTIMED parameter denotes that the user takes on the responsibility for controlling time stamping.
> 
> This change rectifies a few places by adding the corresponding set_starttime() call.
> 
> Test: jdk_jfr
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  typo and additionals

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11592/files
  - new: https://git.openjdk.org/jdk/pull/11592/files/3dfa329f..2407c6cf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11592&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11592&range=00-01

  Stats: 3 lines in 3 files changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11592.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11592/head:pull/11592

PR: https://git.openjdk.org/jdk/pull/11592

From mgronlun at openjdk.org  Thu Dec  8 13:39:44 2022
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 8 Dec 2022 13:39:44 GMT
Subject: RFR: 8298379: JFR: Some UNTIMED events only sets endTime [v3]
In-Reply-To: <HvYT0wt_TeV1cffNx4DD_8cI5AR4ijQpvM_sGTO2RCg=.4293f248-d7b1-442a-bfb3-40f008779ab3@github.com>
References: <HvYT0wt_TeV1cffNx4DD_8cI5AR4ijQpvM_sGTO2RCg=.4293f248-d7b1-442a-bfb3-40f008779ab3@github.com>
Message-ID: <8c1TT8Gxbp2Amz02uul5bWBmq6nO9FypBFTcXKXm4S8=.d2671c23-440f-4fa8-b4c0-8335ce2cf152@github.com>

> Greetings,
> 
> It was pointed out that some UNTIMED events only call set_endtime(), and not the corresponding set_starttime(), for example some events in jfrPeriodic.cpp. UNTIMED events need to have both timestamps set, because the UNTIMED parameter denotes that the user takes on the responsibility for controlling time stamping.
> 
> This change rectifies a few places by adding the corresponding set_starttime() call.
> 
> Test: jdk_jfr
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  copyright

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11592/files
  - new: https://git.openjdk.org/jdk/pull/11592/files/2407c6cf..f1acc1f5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11592&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11592&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11592.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11592/head:pull/11592

PR: https://git.openjdk.org/jdk/pull/11592

From ehelin at openjdk.org  Thu Dec  8 13:41:19 2022
From: ehelin at openjdk.org (Erik Helin)
Date: Thu, 8 Dec 2022 13:41:19 GMT
Subject: RFR: 8298379: JFR: Some UNTIMED events only sets endTime [v3]
In-Reply-To: <8c1TT8Gxbp2Amz02uul5bWBmq6nO9FypBFTcXKXm4S8=.d2671c23-440f-4fa8-b4c0-8335ce2cf152@github.com>
References: <HvYT0wt_TeV1cffNx4DD_8cI5AR4ijQpvM_sGTO2RCg=.4293f248-d7b1-442a-bfb3-40f008779ab3@github.com>
 <8c1TT8Gxbp2Amz02uul5bWBmq6nO9FypBFTcXKXm4S8=.d2671c23-440f-4fa8-b4c0-8335ce2cf152@github.com>
Message-ID: <Eof-nwG_86zKpTxMT5Mj1pIOgu0rStW5bEKwscjLIUc=.4f96ed89-8813-402f-956f-03c878aa02b2@github.com>

On Thu, 8 Dec 2022 13:39:44 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> It was pointed out that some UNTIMED events only call set_endtime(), and not the corresponding set_starttime(), for example some events in jfrPeriodic.cpp. UNTIMED events need to have both timestamps set, because the UNTIMED parameter denotes that the user takes on the responsibility for controlling time stamping.
>> 
>> This change rectifies a few places by adding the corresponding set_starttime() call.
>> 
>> Test: jdk_jfr
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright

Looks good, thanks @mgronlun for fixing!

-------------

Marked as reviewed by ehelin (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11592

From egahlin at openjdk.org  Thu Dec  8 13:45:42 2022
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 8 Dec 2022 13:45:42 GMT
Subject: RFR: 8298379: JFR: Some UNTIMED events only sets endTime [v3]
In-Reply-To: <8c1TT8Gxbp2Amz02uul5bWBmq6nO9FypBFTcXKXm4S8=.d2671c23-440f-4fa8-b4c0-8335ce2cf152@github.com>
References: <HvYT0wt_TeV1cffNx4DD_8cI5AR4ijQpvM_sGTO2RCg=.4293f248-d7b1-442a-bfb3-40f008779ab3@github.com>
 <8c1TT8Gxbp2Amz02uul5bWBmq6nO9FypBFTcXKXm4S8=.d2671c23-440f-4fa8-b4c0-8335ce2cf152@github.com>
Message-ID: <9uoe_aP0Q4uE0NWhfIrxRTVWN9T68BlJ1dVPsn-YlfI=.e05c7a1a-95e6-49f8-8426-b009a9e059ee@github.com>

On Thu, 8 Dec 2022 13:39:44 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> It was pointed out that some UNTIMED events only call set_endtime(), and not the corresponding set_starttime(), for example some events in jfrPeriodic.cpp. UNTIMED events need to have both timestamps set, because the UNTIMED parameter denotes that the user takes on the responsibility for controlling time stamping.
>> 
>> This change rectifies a few places by adding the corresponding set_starttime() call.
>> 
>> Test: jdk_jfr
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright

Marked as reviewed by egahlin (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11592

From qamai at openjdk.org  Thu Dec  8 13:46:49 2022
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 8 Dec 2022 13:46:49 GMT
Subject: RFR: 8292289: [vectorapi] Improve the implementation of
 VectorTestNode [v14]
In-Reply-To: <wUvjUsdbWh3bH5EpbfM2R6b4jPKd3qDvk4GbOOaE8HY=.a1a3b206-8f73-44b3-9afb-a087a0b74001@github.com>
References: <IcR6eOr6iM1b9B1I1zUQnI2J9hQAmdSRHYc9CdIGW5E=.3b8dd64d-2eff-4659-b75a-81c4b008e41a@github.com>
 <Jo8mnLoA_9Pb8TzocN6zG5s2PGGVxS53s6XP_5CasLo=.de864d1a-51b5-4ceb-b12d-1d20e34735d7@github.com>
 <MeWOERLVkAl7rrsPqAFR23UeiLCntkyPM5jqerJXtEU=.1d987dbb-9b2b-4d4b-811e-47b5f46f635a@github.com>
 <wUvjUsdbWh3bH5EpbfM2R6b4jPKd3qDvk4GbOOaE8HY=.a1a3b206-8f73-44b3-9afb-a087a0b74001@github.com>
Message-ID: <uQeVsYqwDhU2peIgw3_JS4zEdWyN8G0ljus9z15gnr0=.358aabfa-2ee8-4c7a-9f6d-2c9842325d99@github.com>

On Thu, 8 Dec 2022 09:21:47 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Rerunning DaCapo and Renaissance which shows some variations.
>
>> @vnkozlov I believe `VectorTestNode` is only used in Vector API, which should not affect those benchmarks?
> 
> Yes, but you have changes in general code related to `Cmp` node.
> I see that DaCapo don't show regression after rerun. Renaissance is still running and numbers are "all over places" - it is not stable.
> 
> Anyway, I am approving this changes based on data I got.

@vnkozlov Ah I get it, thanks a lot for your reviews, can I merge the patch now?

-------------

PR: https://git.openjdk.org/jdk/pull/9855

From mgronlun at openjdk.org  Thu Dec  8 13:49:05 2022
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 8 Dec 2022 13:49:05 GMT
Subject: RFR: 8298379: JFR: Some UNTIMED events only sets endTime [v3]
In-Reply-To: <8c1TT8Gxbp2Amz02uul5bWBmq6nO9FypBFTcXKXm4S8=.d2671c23-440f-4fa8-b4c0-8335ce2cf152@github.com>
References: <HvYT0wt_TeV1cffNx4DD_8cI5AR4ijQpvM_sGTO2RCg=.4293f248-d7b1-442a-bfb3-40f008779ab3@github.com>
 <8c1TT8Gxbp2Amz02uul5bWBmq6nO9FypBFTcXKXm4S8=.d2671c23-440f-4fa8-b4c0-8335ce2cf152@github.com>
Message-ID: <yso6P0W9orVGL1wJBC4HhN0QyDSEq2vokZ1pLgJuTvg=.9c15424b-b61d-481c-b39e-2a7ed2e05846@github.com>

On Thu, 8 Dec 2022 13:39:44 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> It was pointed out that some UNTIMED events only call set_endtime(), and not the corresponding set_starttime(), for example some events in jfrPeriodic.cpp. UNTIMED events need to have both timestamps set, because the UNTIMED parameter denotes that the user takes on the responsibility for controlling time stamping.
>> 
>> This change rectifies a few places by adding the corresponding set_starttime() call.
>> 
>> Test: jdk_jfr
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright

Thanks @ehelin for reporting and reviewing this!

-------------

PR: https://git.openjdk.org/jdk/pull/11592

From mgronlun at openjdk.org  Thu Dec  8 13:55:19 2022
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 8 Dec 2022 13:55:19 GMT
Subject: RFR: 8298379: JFR: Some UNTIMED events only sets endTime [v4]
In-Reply-To: <HvYT0wt_TeV1cffNx4DD_8cI5AR4ijQpvM_sGTO2RCg=.4293f248-d7b1-442a-bfb3-40f008779ab3@github.com>
References: <HvYT0wt_TeV1cffNx4DD_8cI5AR4ijQpvM_sGTO2RCg=.4293f248-d7b1-442a-bfb3-40f008779ab3@github.com>
Message-ID: <YNL-UGsW0VjTb50xnDj1KBrU5izwxhDXom7-RaVwM4Y=.86fc6028-ebda-4234-8c3d-e79748b1f9f8@github.com>

> Greetings,
> 
> It was pointed out that some UNTIMED events only call set_endtime(), and not the corresponding set_starttime(), for example some events in jfrPeriodic.cpp. UNTIMED events need to have both timestamps set, because the UNTIMED parameter denotes that the user takes on the responsibility for controlling time stamping.
> 
> This change rectifies a few places by adding the corresponding set_starttime() call.
> 
> Test: jdk_jfr
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  typo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11592/files
  - new: https://git.openjdk.org/jdk/pull/11592/files/f1acc1f5..556931f5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11592&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11592&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11592.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11592/head:pull/11592

PR: https://git.openjdk.org/jdk/pull/11592

From coleenp at openjdk.org  Thu Dec  8 14:31:12 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 8 Dec 2022 14:31:12 GMT
Subject: RFR: 8296955: Kitchensink.java failed with
 "double free or corruption (!prev): <addr>"
Message-ID: <ohHNo_-q_Nyj57YDmnDJHlZUrnoxE_uPvvynghR1dLo=.4bd7125c-a1a5-491a-8b1d-dde47a9203b7@github.com>

Thanks to Kim for the diagnosis of this problem.  G1 cleans up nmethods in parallel threads during a safepoint and may post or queue unload events to be posted.  The event posting creates jmethodIDs.  The jmethodID code assumes that it's thread safe in a safepoint, which it is not.
I removed this optimization, which isn't much of an optimization and is unsafe in the modern code.
Tested with tier1-5, where 5 found the original bug.
I'll also rebase this to JDK 20 repository and close this, but here's a preview.

-------------

Commit messages:
 - 8296955: Kitchensink.java failed with "double free or corruption (!prev): <addr>"

Changes: https://git.openjdk.org/jdk/pull/11594/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11594&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296955
  Stats: 50 lines in 2 files changed: 2 ins; 32 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/11594.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11594/head:pull/11594

PR: https://git.openjdk.org/jdk/pull/11594

From mgronlun at openjdk.org  Thu Dec  8 14:42:32 2022
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 8 Dec 2022 14:42:32 GMT
Subject: Integrated: 8298379: JFR: Some UNTIMED events only sets endTime
In-Reply-To: <HvYT0wt_TeV1cffNx4DD_8cI5AR4ijQpvM_sGTO2RCg=.4293f248-d7b1-442a-bfb3-40f008779ab3@github.com>
References: <HvYT0wt_TeV1cffNx4DD_8cI5AR4ijQpvM_sGTO2RCg=.4293f248-d7b1-442a-bfb3-40f008779ab3@github.com>
Message-ID: <FywImgl3Q60t59LdR6YQNKHvg7esokBhkQRf9ctT3Lg=.b7b5d576-b8e9-4d7b-be14-edf6607bfb3c@github.com>

On Thu, 8 Dec 2022 13:22:35 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> It was pointed out that some UNTIMED events only call set_endtime(), and not the corresponding set_starttime(), for example some events in jfrPeriodic.cpp. UNTIMED events need to have both timestamps set, because the UNTIMED parameter denotes that the user takes on the responsibility for controlling time stamping.
> 
> This change rectifies a few places by adding the corresponding set_starttime() call.
> 
> Test: jdk_jfr
> 
> Thanks
> Markus

This pull request has now been integrated.

Changeset: c084431f
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c084431fae8c9f9b5a157cdaca484f63cbd6691a
Stats:     16 lines in 7 files changed: 11 ins; 1 del; 4 mod

8298379: JFR: Some UNTIMED events only sets endTime

Reviewed-by: ehelin, egahlin

-------------

PR: https://git.openjdk.org/jdk/pull/11592

From ludovic at rivosinc.com  Thu Dec  8 15:19:02 2022
From: ludovic at rivosinc.com (Ludovic Henry)
Date: Thu, 8 Dec 2022 12:19:02 -0300
Subject: Difference in behaviour in native math library
Message-ID: <CADT88DtZqejo8v44NR01HTogK70azyHiCcWrTWOf8EcXBjRWgw@mail.gmail.com>

Hello,

I've noticed that some Math trigonometry tests are failing in the GNU Mauve
test suite. From digging into it, it's related to NaN values being passed
to java.lang.Math trigonometry functions, and how these values are handled
in the native libm library.

Given the following C test case compiled and run with `gcc acos.c -lm &&
./a.out`

```
#include <stdint.h>
#include <math.h>
#include <stdlib.h>
#include <stdio.h>

void main(int argc, char* argv[]) {
    int64_t bitsNaN = 0x7fff800000000000L;
    double valNaN = *((double*)&bitsNaN);

    double resD = acos(valNaN);
    int64_t res = *((int64_t*)&resD);
    if (!(res == bitsNaN)) {
        printf("expected 0x%lx but got 0x%lx\n", bitsNaN, res);
        exit(1);
    }
}
```

On a Linux-x64, the test succeeds, but on Linux-RISC-V, the test fails.

You've the same test failure in the equivalent Java code:

```
public class acos {
    public static void main (String[] args) {
        long bitsNaN = 0x7fff800000000000L;
        double valNaN = Double.longBitsToDouble(bitsNaN);

        long res = Double.doubleToRawLongBits(Math.acos(valNaN));
        if (!(res == bitsNaN)) {
            throw new RuntimeException(String.format("expected 0x%x but got
0x%x", bitsNaN, res));
        }
    }
}
```

What approach should we take in these cases? Is it that the test case is
wrong, and should assume that given a NaN, any value of NaN returned is
valid? Or should we make sure that the behavior is the same across
platforms and that we "fix" any difference in behavior of the native
library?

Cheers,
Ludovic
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20221208/bc744020/attachment.htm>

From avoitylov at openjdk.org  Thu Dec  8 15:02:18 2022
From: avoitylov at openjdk.org (Aleksei Voitylov)
Date: Thu, 8 Dec 2022 15:02:18 GMT
Subject: RFR: 8291302: ARM32: nmethod entry barriers support [v4]
In-Reply-To: <BJaszr0_haU4UZOyQQEA9P0SOlgtfTtGFBj9VSRD5SM=.ffd6af56-a51e-4627-90cb-0eb0e1bbd5e8@github.com>
References: <BJaszr0_haU4UZOyQQEA9P0SOlgtfTtGFBj9VSRD5SM=.ffd6af56-a51e-4627-90cb-0eb0e1bbd5e8@github.com>
Message-ID: <hjEeA3EFQ8HmiK65iRm7WKXX4tmVKC187eEHE_FPOSg=.3a2f657d-f207-4e60-9023-65808595ecc6@github.com>

> This PR implements nmethod entry barriers for ARM32. It has already been implemented for other ports and is related with JDK-8290025 "Remove the Sweeper".

Aleksei Voitylov 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 four additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8291302-3
 - remove membar
 - save float registers
 - 8291302: ARM32: nmethod entry barriers support

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11442/files
  - new: https://git.openjdk.org/jdk/pull/11442/files/02439515..079a1a9b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11442&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11442&range=02-03

  Stats: 81291 lines in 1215 files changed: 38190 ins; 35583 del; 7518 mod
  Patch: https://git.openjdk.org/jdk/pull/11442.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11442/head:pull/11442

PR: https://git.openjdk.org/jdk/pull/11442

From pchilanomate at openjdk.org  Thu Dec  8 15:23:04 2022
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 8 Dec 2022 15:23:04 GMT
Subject: RFR: 8292674: ReportJNIFatalError should print all java frames
 [v3]
In-Reply-To: <PISgFTzLXnZ2ag2SvndnR_R2VuWpWSX35MiTZEguWEs=.0d44d450-15e4-4f8f-bd92-6f68f6226cb8@github.com>
References: <-ipNtt5PSZ2d7VUBSoduPyNwnW2GeN_y0Dcs95qI8HU=.c4771172-01dd-49ae-8f4a-9d5cbd6c6dad@github.com>
 <PISgFTzLXnZ2ag2SvndnR_R2VuWpWSX35MiTZEguWEs=.0d44d450-15e4-4f8f-bd92-6f68f6226cb8@github.com>
Message-ID: <PG8ZxNcv-URGEqv333RlezioTJwYSi6WVsYNqa4yPGs=.b3c9ceb6-46bf-4008-a975-6e575c8f5d27@github.com>

On Thu, 8 Dec 2022 00:38:13 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> When JNI reports errors and warnings and produces a stack trace, we need to see the exact Java code that was being executed. The existing `JavaThread::print_stack` that is used is only for platform/carrier threads and doesn't show any mounted virtual thread. So we introduce a new `JavaThread::print_virtual_stack_on` method to print the mounted virtual thread's stack, and we add `JavaThread::print_jni_stack` as a utility for JNI to call that dispatches to the appropriate function based on the thread type.
>> 
>> The existing test `hotspot/jtreg/runtime/jni/checked/TestPrimitiveArrayCriticalWithBadParam.java` was modified to test regular and virtual threads, and to expect to see the specific stack frame of the Java native method.
>> 
>> Additional manual testing of the JNI `FatalError` method was done by direct fault injection in modified JDK code.
>> 
>> Sanity testing: Oracle tiers 1-4 (to include our -Xcheck:jni run in tier4)
>> 
>> Thanks,
>> David
>
> David Holmes 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 three additional commits since the last revision:
> 
>  - Merge branch 'master' into 8292674-ReportJNIFatalError-v2
>  - Changed RegisterMap to include process_frame and update, for object monitor examination.
>    Updated stack printing for exception checks.
>  - 8292674: ReportJNIFatalError should print all java frames

Looks good, thanks David!

-------------

Marked as reviewed by pchilanomate (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11503

From duke at openjdk.org  Thu Dec  8 16:17:05 2022
From: duke at openjdk.org (Afshin Zafari)
Date: Thu, 8 Dec 2022 16:17:05 GMT
Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v5]
In-Reply-To: <Dj9YfY10SLn8dR1Ez3kEQe4tXm1q5W1TS8_4r3gBUsY=.6c38825a-86e5-4575-a509-683786d242a6@github.com>
References: <Dj9YfY10SLn8dR1Ez3kEQe4tXm1q5W1TS8_4r3gBUsY=.6c38825a-86e5-4575-a509-683786d242a6@github.com>
Message-ID: <y1kDOv0ldcW-hLtsB9mEzE2J51opef_YiaEprpoO2E0=.f875f420-d5a8-4ccf-8f86-5eea3d769ac5@github.com>

> test of tier1-5 passed.

Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - 8292741: Convert JvmtiTagMapTable to ResourceHashtable
 - 8292741: Convert JvmtiTagMapTable to ResourceHashtable
 - Added update interface instead of Remove-Add pair.
 - JBS-8292741: Convert JvmtiTagMapTable to ResourceHashtable

-------------

Changes: https://git.openjdk.org/jdk/pull/11288/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11288&range=04
  Stats: 288 lines in 4 files changed: 45 ins; 121 del; 122 mod
  Patch: https://git.openjdk.org/jdk/pull/11288.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11288/head:pull/11288

PR: https://git.openjdk.org/jdk/pull/11288

From kvn at openjdk.org  Thu Dec  8 16:21:21 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 8 Dec 2022 16:21:21 GMT
Subject: RFR: 8292289: [vectorapi] Improve the implementation of
 VectorTestNode [v14]
In-Reply-To: <Jo8mnLoA_9Pb8TzocN6zG5s2PGGVxS53s6XP_5CasLo=.de864d1a-51b5-4ceb-b12d-1d20e34735d7@github.com>
References: <IcR6eOr6iM1b9B1I1zUQnI2J9hQAmdSRHYc9CdIGW5E=.3b8dd64d-2eff-4659-b75a-81c4b008e41a@github.com>
 <Jo8mnLoA_9Pb8TzocN6zG5s2PGGVxS53s6XP_5CasLo=.de864d1a-51b5-4ceb-b12d-1d20e34735d7@github.com>
Message-ID: <ktPAxsfjUrCU2pOgc1TCEc_Rwz2mmmwcbzkYPehp3Zc=.ac9e06df-3a10-4b7c-bdfa-04a697ecc63d@github.com>

On Tue, 6 Dec 2022 14:24:39 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> This patch modifies the node generation of `VectorSupport::test` to emit a `CMoveINode`, which is picked up by `BoolNode::Ideal(PhaseGVN*, bool)` to connect the `VectorTestNode` directly to the `BoolNode`, removing the redundant operations of materialising the test result in a GP register and do a `CmpI` to get back the flags. As a result, `VectorMask<T>::alltrue` is compiled into machine codes:
>> 
>>         vptest xmm0, xmm1
>>         jb if_true
>>     if_false:
>> 
>> instead of:
>> 
>>         vptest xmm0, xmm1
>>         setb r10
>>         movzbl r10
>>         testl r10
>>         jne if_true
>>     if_false:
>> 
>> The results of `jdk.incubator.vector.ArrayMismatchBenchmark` shows noticeable improvements:
>> 
>>                                                                                        Before                  After
>>     Benchmark                                      Prefix    Size   Mode  Cnt       Score      Error       Score     Error    Units  Change
>>     ArrayMismatchBenchmark.mismatchVectorByte         0.5       9  thrpt   10  217345.383 ? 8316.444  222279.381 ? 2660.983  ops/ms   +2.3%
>>     ArrayMismatchBenchmark.mismatchVectorByte         0.5     257  thrpt   10  113918.406 ? 1618.836  116268.691 ? 1291.899  ops/ms   +2.1%
>>     ArrayMismatchBenchmark.mismatchVectorByte         0.5  100000  thrpt   10     702.066 ?   72.862     797.806 ?   16.429  ops/ms  +13.6%
>>     ArrayMismatchBenchmark.mismatchVectorByte         1.0       9  thrpt   10  146096.564 ? 2401.258  145338.910 ?  687.453  ops/ms   -0.5%
>>     ArrayMismatchBenchmark.mismatchVectorByte         1.0     257  thrpt   10   60598.181 ? 1259.397   69041.519 ? 1073.156  ops/ms  +13.9%
>>     ArrayMismatchBenchmark.mismatchVectorByte         1.0  100000  thrpt   10     316.814 ?   10.975     408.770 ?    5.281  ops/ms  +29.0%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       0.5       9  thrpt   10  195674.549 ? 1200.166  188482.433 ? 1872.076  ops/ms   -3.7%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       0.5     257  thrpt   10   44357.169 ?  473.013   42293.411 ? 2838.255  ops/ms   -4.7%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       0.5  100000  thrpt   10      68.199 ?    5.410      67.628 ?    3.241  ops/ms   -0.8%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       1.0       9  thrpt   10  107722.450 ? 1677.607  111060.400 ?  982.230  ops/ms   +3.1%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       1.0     257  thrpt   10   16692.645 ? 1002.599   21440.506 ? 1618.266  ops/ms  +28.4%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       1.0  100000  thrpt   10      32.984 ?    0.548      33.202 ?    2.365  ops/ms   +0.7%
>>     ArrayMismatchBenchmark.mismatchVectorInt          0.5       9  thrpt   10  335458.217 ? 3154.842  379944.254 ? 5703.134  ops/ms  +13.3%
>>     ArrayMismatchBenchmark.mismatchVectorInt          0.5     257  thrpt   10   58505.302 ?  786.312   56721.368 ? 2497.052  ops/ms   -3.0%
>>     ArrayMismatchBenchmark.mismatchVectorInt          0.5  100000  thrpt   10     133.037 ?   11.415     139.537 ?    4.667  ops/ms   +4.9%
>>     ArrayMismatchBenchmark.mismatchVectorInt          1.0       9  thrpt   10  117943.802 ? 2281.349  112409.365 ? 2110.055  ops/ms   -4.7%
>>     ArrayMismatchBenchmark.mismatchVectorInt          1.0     257  thrpt   10   27060.015 ?  795.619   33756.613 ?  826.533  ops/ms  +24.7%
>>     ArrayMismatchBenchmark.mismatchVectorInt          1.0  100000  thrpt   10      57.558 ?    8.927      66.951 ?    4.381  ops/ms  +16.3%
>>     ArrayMismatchBenchmark.mismatchVectorLong         0.5       9  thrpt   10  182963.715 ? 1042.497  182438.405 ? 2120.832  ops/ms   -0.3%
>>     ArrayMismatchBenchmark.mismatchVectorLong         0.5     257  thrpt   10   36672.215 ?  614.821   35397.398 ? 1609.235  ops/ms   -3.5%
>>     ArrayMismatchBenchmark.mismatchVectorLong         0.5  100000  thrpt   10      66.438 ?    2.142      65.427 ?    2.270  ops/ms   -1.5%
>>     ArrayMismatchBenchmark.mismatchVectorLong         1.0       9  thrpt   10  110393.047 ?  497.853  115165.845 ? 5381.674  ops/ms   +4.3%
>>     ArrayMismatchBenchmark.mismatchVectorLong         1.0     257  thrpt   10   14720.765 ?  661.350   19871.096 ?  201.464  ops/ms  +35.0%
>>     ArrayMismatchBenchmark.mismatchVectorLong         1.0  100000  thrpt   10      30.760 ?    0.821      31.933 ?    1.352  ops/ms   +3.8%
>> 
>> I have not been able to conduct throughout testing on AVX512 and Aarch64 so any help would be invaluable. Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix test

Yes, you can integrate.

-------------

PR: https://git.openjdk.org/jdk/pull/9855

From ludovic at rivosinc.com  Thu Dec  8 16:26:30 2022
From: ludovic at rivosinc.com (Ludovic Henry)
Date: Thu, 8 Dec 2022 13:26:30 -0300
Subject: Difference in behaviour in native math library
In-Reply-To: <CADT88DtZqejo8v44NR01HTogK70azyHiCcWrTWOf8EcXBjRWgw@mail.gmail.com>
References: <CADT88DtZqejo8v44NR01HTogK70azyHiCcWrTWOf8EcXBjRWgw@mail.gmail.com>
Message-ID: <CADT88DuxtUt+0OYMZeSKek1GAwEQEVXMuRK+moc4xHA9w--01Q@mail.gmail.com>

Adding the right address for core-libs-dev.

On Thu, Dec 8, 2022 at 12:19 PM Ludovic Henry <ludovic at rivosinc.com> wrote:

> Hello,
>
> I've noticed that some Math trigonometry tests are failing in the GNU
> Mauve test suite. From digging into it, it's related to NaN values being
> passed to java.lang.Math trigonometry functions, and how these values are
> handled in the native libm library.
>
> Given the following C test case compiled and run with `gcc acos.c -lm &&
> ./a.out`
>
> ```
> #include <stdint.h>
> #include <math.h>
> #include <stdlib.h>
> #include <stdio.h>
>
> void main(int argc, char* argv[]) {
>     int64_t bitsNaN = 0x7fff800000000000L;
>     double valNaN = *((double*)&bitsNaN);
>
>     double resD = acos(valNaN);
>     int64_t res = *((int64_t*)&resD);
>     if (!(res == bitsNaN)) {
>         printf("expected 0x%lx but got 0x%lx\n", bitsNaN, res);
>         exit(1);
>     }
> }
> ```
>
> On a Linux-x64, the test succeeds, but on Linux-RISC-V, the test fails.
>
> You've the same test failure in the equivalent Java code:
>
> ```
> public class acos {
>     public static void main (String[] args) {
>         long bitsNaN = 0x7fff800000000000L;
>         double valNaN = Double.longBitsToDouble(bitsNaN);
>
>         long res = Double.doubleToRawLongBits(Math.acos(valNaN));
>         if (!(res == bitsNaN)) {
>             throw new RuntimeException(String.format("expected 0x%x but
> got 0x%x", bitsNaN, res));
>         }
>     }
> }
> ```
>
> What approach should we take in these cases? Is it that the test case is
> wrong, and should assume that given a NaN, any value of NaN returned is
> valid? Or should we make sure that the behavior is the same across
> platforms and that we "fix" any difference in behavior of the native
> library?
>
> Cheers,
> Ludovic
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20221208/18cc52d7/attachment.htm>

From kbarrett at openjdk.org  Thu Dec  8 16:33:08 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 8 Dec 2022 16:33:08 GMT
Subject: RFR: 8297912: HotSpot Style Guide should permit alignas (Second
 Proposal Attempt) [v2]
In-Reply-To: <58rvZjSeJKCKUkZd4xEsQxaQjgGWs-V4IPBpSNutc0g=.883e96aa-b385-4019-80f5-69b56e732e20@github.com>
References: <Lyv_ypxMsA5tjqJ3d4KwScyySdBcTo34lL8abbF4SoQ=.44f3b51c-30b8-428e-b715-6af70bccaaf5@github.com>
 <58rvZjSeJKCKUkZd4xEsQxaQjgGWs-V4IPBpSNutc0g=.883e96aa-b385-4019-80f5-69b56e732e20@github.com>
Message-ID: <KIMVhrOWmnrhtg9nkbzuKsjSUHpym3CvFq-oyNwdSGE=.ad25cb11-4209-44ee-8032-292e9f4c57bd@github.com>

On Sun, 4 Dec 2022 18:18:00 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> [8252584](https://bugs.openjdk.org/browse/JDK-8252584) was integrated too early due to a mistake on my part, we should redo it and go through the proper approval process this time
>> 
>> (The changes in this commit are exactly identical to 8252584)
>
> 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 two additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into style
>  - HotSpot Style Guide

A benefit of `alignas` is that the argument can be a type, in which case it's
alignment is used. gcc's `__attribute__((aligned(N)))` requires `N` be the
alignment value. One could obtain that from a type using `alignof(T)` or
`std::alignment_of<T>` (though `alignof` is not yet approved for use in
HotSpot - [JDK-8274400](https://bugs.openjdk.org/browse/JDK-8274400)).

Also, the alternative of using std::aligned_storage or std::aligned_union has
problems - [JDK-8298399](https://bugs.openjdk.org/browse/JDK-8298399).

Another advantage compared to our macro workaround is that this isn't
something that can be optional for a port. Some uses may really require the
alignment request be honored, such as aligning a char[] for use as aligned
storage. If a port doesn't define `ATTRIBUTE_ALIGNED` (so uses the empty
default) then we can't use it for that purpose in shared code. (Note that
globalDefinitions_xlc.hpp does NOT define this macro. That's potentially a
bug.)

-------------

PR: https://git.openjdk.org/jdk/pull/11446

From duke at openjdk.org  Thu Dec  8 16:35:02 2022
From: duke at openjdk.org (Afshin Zafari)
Date: Thu, 8 Dec 2022 16:35:02 GMT
Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v6]
In-Reply-To: <Dj9YfY10SLn8dR1Ez3kEQe4tXm1q5W1TS8_4r3gBUsY=.6c38825a-86e5-4575-a509-683786d242a6@github.com>
References: <Dj9YfY10SLn8dR1Ez3kEQe4tXm1q5W1TS8_4r3gBUsY=.6c38825a-86e5-4575-a509-683786d242a6@github.com>
Message-ID: <CAadhYl-qA2Imw97BP70VnGhnhJNRodGjf5qq_LiFxY=.089e4ae7-fd8a-433c-b8c2-9e9e117cfdb0@github.com>

> test of tier1-5 passed.

Afshin Zafari 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 six additional commits since the last revision:

 - 8292741: Convert JvmtiTagMapTable to ResourceHashtable
 - Merge branch 'master' into jvmti_tagmap
 - 8292741: Convert JvmtiTagMapTable to ResourceHashtable
 - 8292741: Convert JvmtiTagMapTable to ResourceHashtable
 - Added update interface instead of Remove-Add pair.
 - JBS-8292741: Convert JvmtiTagMapTable to ResourceHashtable

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11288/files
  - new: https://git.openjdk.org/jdk/pull/11288/files/6ef59dff..4c00ac8f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11288&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11288&range=04-05

  Stats: 81589 lines in 1191 files changed: 40421 ins; 34464 del; 6704 mod
  Patch: https://git.openjdk.org/jdk/pull/11288.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11288/head:pull/11288

PR: https://git.openjdk.org/jdk/pull/11288

From kbarrett at openjdk.org  Thu Dec  8 16:40:46 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 8 Dec 2022 16:40:46 GMT
Subject: RFR: 8297912: HotSpot Style Guide should permit alignas (Second
 Proposal Attempt) [v2]
In-Reply-To: <58rvZjSeJKCKUkZd4xEsQxaQjgGWs-V4IPBpSNutc0g=.883e96aa-b385-4019-80f5-69b56e732e20@github.com>
References: <Lyv_ypxMsA5tjqJ3d4KwScyySdBcTo34lL8abbF4SoQ=.44f3b51c-30b8-428e-b715-6af70bccaaf5@github.com>
 <58rvZjSeJKCKUkZd4xEsQxaQjgGWs-V4IPBpSNutc0g=.883e96aa-b385-4019-80f5-69b56e732e20@github.com>
Message-ID: <LGjuu_yThdgBGIZt9X9yTb1m4FPHs7x9iqzzizAQ4Co=.bbee95af-6e03-4259-ba6c-082ad9fd1356@github.com>

On Sun, 4 Dec 2022 18:18:00 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> [8252584](https://bugs.openjdk.org/browse/JDK-8252584) was integrated too early due to a mistake on my part, we should redo it and go through the proper approval process this time
>> 
>> (The changes in this commit are exactly identical to 8252584)
>
> 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 two additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into style
>  - HotSpot Style Guide

The MSVC implementation of `ATTRIBUTE_ALIGNED` using `__declspec(align(N))` has the same
limitation of needing the alignment value, and not being usable for types.

I happened to run into both the limitation to alignment values problem and
the lack of an XLC definition for ATTRIBUTE_ALIGNED today.

-------------

PR: https://git.openjdk.org/jdk/pull/11446

From coleenp at openjdk.org  Thu Dec  8 16:40:55 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 8 Dec 2022 16:40:55 GMT
Subject: Withdrawn: 8296955: Kitchensink.java failed with
 "double free or corruption (!prev): <addr>"
In-Reply-To: <ohHNo_-q_Nyj57YDmnDJHlZUrnoxE_uPvvynghR1dLo=.4bd7125c-a1a5-491a-8b1d-dde47a9203b7@github.com>
References: <ohHNo_-q_Nyj57YDmnDJHlZUrnoxE_uPvvynghR1dLo=.4bd7125c-a1a5-491a-8b1d-dde47a9203b7@github.com>
Message-ID: <Oi5gBEuPNnMJLZeSigGzGuVR7wVf0Nrdy64husi3Kl0=.d0a8780e-16cd-462b-b1dc-8c8bd9725caf@github.com>

On Thu, 8 Dec 2022 14:22:15 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Thanks to Kim for the diagnosis of this problem.  G1 cleans up nmethods in parallel threads during a safepoint and may post or queue unload events to be posted.  The event posting creates jmethodIDs.  The jmethodID code assumes that it's thread safe in a safepoint, which it is not.
> I removed this optimization, which isn't much of an optimization and is unsafe in the modern code.
> Tested with tier1-5, where 5 found the original bug.
> I'll also rebase this to JDK 20 repository and close this, but here's a preview.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/11594

From duke at openjdk.org  Thu Dec  8 16:56:40 2022
From: duke at openjdk.org (Afshin Zafari)
Date: Thu, 8 Dec 2022 16:56:40 GMT
Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v7]
In-Reply-To: <Dj9YfY10SLn8dR1Ez3kEQe4tXm1q5W1TS8_4r3gBUsY=.6c38825a-86e5-4575-a509-683786d242a6@github.com>
References: <Dj9YfY10SLn8dR1Ez3kEQe4tXm1q5W1TS8_4r3gBUsY=.6c38825a-86e5-4575-a509-683786d242a6@github.com>
Message-ID: <pRcbuNmrpRkRA8lOJfYlEVWo3W766EMs6Gw5raXbZPs=.66222c03-5a36-43be-a9c9-080d046d73d7@github.com>

> test of tier1-5 passed.

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  8292741: Convert JvmtiTagMapTable to ResourceHashtable

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11288/files
  - new: https://git.openjdk.org/jdk/pull/11288/files/4c00ac8f..d55d7612

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11288&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11288&range=05-06

  Stats: 19 lines in 1 file changed: 0 ins; 19 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11288.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11288/head:pull/11288

PR: https://git.openjdk.org/jdk/pull/11288

From joe.darcy at oracle.com  Thu Dec  8 17:31:07 2022
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Thu, 8 Dec 2022 09:31:07 -0800
Subject: Difference in behaviour in native math library
In-Reply-To: <CADT88DuxtUt+0OYMZeSKek1GAwEQEVXMuRK+moc4xHA9w--01Q@mail.gmail.com>
References: <CADT88DtZqejo8v44NR01HTogK70azyHiCcWrTWOf8EcXBjRWgw@mail.gmail.com>
 <CADT88DuxtUt+0OYMZeSKek1GAwEQEVXMuRK+moc4xHA9w--01Q@mail.gmail.com>
Message-ID: <6bc2bc45-a730-e445-51a4-53ae6ecb653e@oracle.com>

Hello,

Okay, so it looks like the test is expected the same bit pattern to be 
used for a NaN output if a NaN was used as an input.

That isn't necessarily unreasonable, but it is *not* required by the 
specifications for the Math or StrictMath method, spec for Math.acos:

> Returns the arc cosine of a value; the returned angle is in the range 
> 0.0 through /pi/. Special case:
>
>   * If the argument is NaN or its absolute value is greater than 1,
>     then the result is NaN.
>   * If the argument is |1.0|, the result is positive zero.
>
> The computed result must be within 1 ulp of the exact result. Results 
> must be semi-monotonic.
>
https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/lang/Math.html#acos(double)

On a NaN argument, any NaN bit pattern is valid per the spec. Even if 
you're trying to return the same NaN, there can be challenges to doing 
so depending on how the underlying processor handles signaling NaNs, a 
concept which doesn't exist in the Java platform.

HTH,

-Joe

On 12/8/2022 8:26 AM, Ludovic Henry wrote:
> Adding the right address for core-libs-dev.
>
> On Thu, Dec 8, 2022 at 12:19 PM Ludovic Henry <ludovic at rivosinc.com> 
> wrote:
>
>     Hello,
>
>     I've noticed that some Math trigonometry tests are failing in the
>     GNU Mauve test suite. From digging into it, it's related to NaN
>     values being passed to java.lang.Math trigonometry functions, and
>     how these values are handled in the native libm library.
>
>     Given the following C test case compiled and run with `gcc acos.c
>     -lm && ./a.out`
>
>     ```
>     #include <stdint.h>
>     #include <math.h>
>     #include <stdlib.h>
>     #include <stdio.h>
>
>     void main(int argc, char* argv[]) {
>     ? ? int64_t bitsNaN = 0x7fff800000000000L;
>     ? ? double valNaN = *((double*)&bitsNaN);
>
>     ? ? double resD = acos(valNaN);
>     ? ? int64_t res = *((int64_t*)&resD);
>     ? ? if (!(res == bitsNaN)) {
>     ? ? ? ? printf("expected 0x%lx but got 0x%lx\n", bitsNaN, res);
>     ? ? ? ? exit(1);
>     ? ? }
>     }
>     ```
>
>     On a Linux-x64, the test succeeds, but on Linux-RISC-V, the test
>     fails.
>
>     You've the same test failure in the equivalent Java code:
>
>     ```
>     public class acos {
>     ? ? public static void main (String[] args) {
>     ? ? ? ? long bitsNaN = 0x7fff800000000000L;
>     ? ? ? ? double valNaN = Double.longBitsToDouble(bitsNaN);
>
>     ? ? ? ? long res = Double.doubleToRawLongBits(Math.acos(valNaN));
>     ? ? ? ? if (!(res == bitsNaN)) {
>     ? ? ? ? ? ? throw new RuntimeException(String.format("expected
>     0x%x but got 0x%x", bitsNaN, res));
>     ? ? ? ? }
>     ? ? }
>     }
>     ```
>
>     What approach should we take in these cases? Is it that the test
>     case is wrong, and should assume that given a NaN, any value of
>     NaN returned is valid? Or should we make sure that the behavior is
>     the same across platforms and that we "fix" any difference in
>     behavior of the native library?
>
>     Cheers,
>     Ludovic
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20221208/c5ac1eb5/attachment.htm>

From kbarrett at openjdk.org  Thu Dec  8 17:49:17 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 8 Dec 2022 17:49:17 GMT
Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v18]
In-Reply-To: <ZXz5ouPFy3NE2vq1ymjOLWsp2OsvsEuAcsPDKjPpOLs=.5aac3ce6-38ed-49f2-b28d-3a0106eced05@github.com>
References: <fWd_NIunUhDXwy8uZSno90GC-PM8pFCey-pAMxxO0rI=.0fede0e4-1438-4321-bc8d-d11565389cae@github.com>
 <ZXz5ouPFy3NE2vq1ymjOLWsp2OsvsEuAcsPDKjPpOLs=.5aac3ce6-38ed-49f2-b28d-3a0106eced05@github.com>
Message-ID: <WzB-dDx87yYUsyDI-yNxxLdlo_jgC80KfSuVtbh92r8=.e2595631-3427-4af5-8d1d-b8c613431a32@github.com>

On Wed, 7 Dec 2022 21:25:11 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> May I have this update reviewed?
>> 
>> The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure.  The build could pass if warnings are disabled for codes that use sprintf method.  For the long run, the sprintf could be replaced with snprintf.  This patch is trying to check if snprintf could be used.
>> 
>> Thanks,
>> Xuelei
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update on review feedback

Looks good.  A couple of minor nits that you can address or not.

src/hotspot/share/adlc/formssel.cpp line 28:

> 26: #include "adlc.hpp"
> 27: 
> 28: #define remaining_buflen(buffer, position) (sizeof(buffer) - (position - buffer))

Consider additional parenthesis, e.g. `((position) - (buffer))`.

src/hotspot/share/adlc/formssel.cpp line 1538:

> 1536:       }
> 1537:       // Add predicate to working buffer
> 1538:       snprintf_checked(s, remaining_buflen(buf, s), "/*%s*/(",(char*)i._key);

[pre-existing] the result from this snprintf could be used instead of strlen in the next line.

src/hotspot/share/adlc/output_c.cpp line 546:

> 544:     char* args = new char [36 + 1];
> 545: 
> 546:     snprintf_checked(args, 37, "0x%x, 0x%x, %u",

Instead of 37, consider `36 + 1` to be clearly from the line above.  Or give that value a name.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11115

From ludovic at rivosinc.com  Thu Dec  8 18:01:23 2022
From: ludovic at rivosinc.com (Ludovic Henry)
Date: Thu, 8 Dec 2022 15:01:23 -0300
Subject: Difference in behaviour in native math library
In-Reply-To: <mhng-a511c6fe-5e68-41ca-8e2f-a89f2788ad17@palmer-ri-x1c9a>
References: <CADT88DuxtUt+0OYMZeSKek1GAwEQEVXMuRK+moc4xHA9w--01Q@mail.gmail.com>
 <mhng-a511c6fe-5e68-41ca-8e2f-a89f2788ad17@palmer-ri-x1c9a>
Message-ID: <CADT88DvmACxJCzGMck_ccg704tra5UcCOKH1zmUsDEuszc0Srg@mail.gmail.com>

Hi,

Yes, this is very much a difference of behavior at the libm/libc level. I'm
trying to figure out whether that behavior difference is acceptable from
the libm/libc level (is it considered a bug to behave differently across
architectures in that case?). If that behaviour is acceptable in libm/libc,
then is it acceptable to behave differently in Java across architectures?

>From your answer Palmer, the difference _might_ not be acceptable in the
glibc test suite (I haven't check why the tests are failing). I'm still
trying to figure that one out.

>From your answer Joe, the difference _is_ acceptable from the
documentation. IMO the question becomes whether it's a case of the
implementation details bleeding into the API and whether we want to be 100%
compatible to avoid further issues. The fix for that could be a simple
`RISCV_ONLY(if (isnan(v)) return v);` or equivalent
in src/java.base/share/native/libjava/StrictMath.c to match the behavior
without any extra cost for other platforms.

Thanks,
Ludovic

On Thu, Dec 8, 2022 at 2:50 PM Palmer Dabbelt <palmer at dabbelt.com> wrote:

> On Thu, 08 Dec 2022 08:26:30 PST (-0800), ludovic at rivosinc.com wrote:
> > Adding the right address for core-libs-dev.
> >
> > On Thu, Dec 8, 2022 at 12:19 PM Ludovic Henry <ludovic at rivosinc.com>
> wrote:
> >
> >> Hello,
> >>
> >> I've noticed that some Math trigonometry tests are failing in the GNU
> >> Mauve test suite. From digging into it, it's related to NaN values being
> >> passed to java.lang.Math trigonometry functions, and how these values
> are
> >> handled in the native libm library.
> >>
> >> Given the following C test case compiled and run with `gcc acos.c -lm &&
> >> ./a.out`
> >>
> >> ```
> >> #include <stdint.h>
> >> #include <math.h>
> >> #include <stdlib.h>
> >> #include <stdio.h>
> >>
> >> void main(int argc, char* argv[]) {
> >>     int64_t bitsNaN = 0x7fff800000000000L;
> >>     double valNaN = *((double*)&bitsNaN);
> >>
> >>     double resD = acos(valNaN);
> >>     int64_t res = *((int64_t*)&resD);
> >>     if (!(res == bitsNaN)) {
> >>         printf("expected 0x%lx but got 0x%lx\n", bitsNaN, res);
> >>         exit(1);
> >>     }
> >> }
> >> ```
> >>
> >> On a Linux-x64, the test succeeds, but on Linux-RISC-V, the test fails.
> >>
> >> You've the same test failure in the equivalent Java code:
> >>
> >> ```
> >> public class acos {
> >>     public static void main (String[] args) {
> >>         long bitsNaN = 0x7fff800000000000L;
> >>         double valNaN = Double.longBitsToDouble(bitsNaN);
> >>
> >>         long res = Double.doubleToRawLongBits(Math.acos(valNaN));
> >>         if (!(res == bitsNaN)) {
> >>             throw new RuntimeException(String.format("expected 0x%x but
> >> got 0x%x", bitsNaN, res));
> >>         }
> >>     }
> >> }
> >> ```
> >>
> >> What approach should we take in these cases? Is it that the test case is
> >> wrong, and should assume that given a NaN, any value of NaN returned is
> >> valid? Or should we make sure that the behavior is the same across
> >> platforms and that we "fix" any difference in behavior of the native
> >> library?
>
> It might just be a glibc bug, we're failing the acos() tests:
>
> https://sourceware.org/glibc/wiki/Release/2.35#RISC-V_.28rv64imafdc.2Flp64d.29
> .  I haven't looked at why, but they do have some nan-related bits in
> there.
>
> >>
> >> Cheers,
> >> Ludovic
> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20221208/ce6170ee/attachment-0001.htm>

From ludovic at rivosinc.com  Thu Dec  8 18:25:51 2022
From: ludovic at rivosinc.com (Ludovic Henry)
Date: Thu, 8 Dec 2022 15:25:51 -0300
Subject: Difference in behaviour in native math library
In-Reply-To: <CADT88DvmACxJCzGMck_ccg704tra5UcCOKH1zmUsDEuszc0Srg@mail.gmail.com>
References: <CADT88DuxtUt+0OYMZeSKek1GAwEQEVXMuRK+moc4xHA9w--01Q@mail.gmail.com>
 <mhng-a511c6fe-5e68-41ca-8e2f-a89f2788ad17@palmer-ri-x1c9a>
 <CADT88DvmACxJCzGMck_ccg704tra5UcCOKH1zmUsDEuszc0Srg@mail.gmail.com>
Message-ID: <CADT88DuwuCCkcMdeFb1trk4wvUJcPDiYcYpPgdMpcMSbsUXj_A@mail.gmail.com>

I've submitted the question to the glibc mailing list at
https://sourceware.org/pipermail/libc-alpha/2022-December/143909.html, I'll
keep you posted on any news.

On Thu, Dec 8, 2022 at 3:01 PM Ludovic Henry <ludovic at rivosinc.com> wrote:

> Hi,
>
> Yes, this is very much a difference of behavior at the libm/libc level.
> I'm trying to figure out whether that behavior difference is acceptable
> from the libm/libc level (is it considered a bug to behave differently
> across architectures in that case?). If that behaviour is acceptable in
> libm/libc, then is it acceptable to behave differently in Java across
> architectures?
>
> From your answer Palmer, the difference _might_ not be acceptable in the
> glibc test suite (I haven't check why the tests are failing). I'm still
> trying to figure that one out.
>
> From your answer Joe, the difference _is_ acceptable from the
> documentation. IMO the question becomes whether it's a case of the
> implementation details bleeding into the API and whether we want to be 100%
> compatible to avoid further issues. The fix for that could be a simple
> `RISCV_ONLY(if (isnan(v)) return v);` or equivalent
> in src/java.base/share/native/libjava/StrictMath.c to match the behavior
> without any extra cost for other platforms.
>
> Thanks,
> Ludovic
>
> On Thu, Dec 8, 2022 at 2:50 PM Palmer Dabbelt <palmer at dabbelt.com> wrote:
>
>> On Thu, 08 Dec 2022 08:26:30 PST (-0800), ludovic at rivosinc.com wrote:
>> > Adding the right address for core-libs-dev.
>> >
>> > On Thu, Dec 8, 2022 at 12:19 PM Ludovic Henry <ludovic at rivosinc.com>
>> wrote:
>> >
>> >> Hello,
>> >>
>> >> I've noticed that some Math trigonometry tests are failing in the GNU
>> >> Mauve test suite. From digging into it, it's related to NaN values
>> being
>> >> passed to java.lang.Math trigonometry functions, and how these values
>> are
>> >> handled in the native libm library.
>> >>
>> >> Given the following C test case compiled and run with `gcc acos.c -lm
>> &&
>> >> ./a.out`
>> >>
>> >> ```
>> >> #include <stdint.h>
>> >> #include <math.h>
>> >> #include <stdlib.h>
>> >> #include <stdio.h>
>> >>
>> >> void main(int argc, char* argv[]) {
>> >>     int64_t bitsNaN = 0x7fff800000000000L;
>> >>     double valNaN = *((double*)&bitsNaN);
>> >>
>> >>     double resD = acos(valNaN);
>> >>     int64_t res = *((int64_t*)&resD);
>> >>     if (!(res == bitsNaN)) {
>> >>         printf("expected 0x%lx but got 0x%lx\n", bitsNaN, res);
>> >>         exit(1);
>> >>     }
>> >> }
>> >> ```
>> >>
>> >> On a Linux-x64, the test succeeds, but on Linux-RISC-V, the test fails.
>> >>
>> >> You've the same test failure in the equivalent Java code:
>> >>
>> >> ```
>> >> public class acos {
>> >>     public static void main (String[] args) {
>> >>         long bitsNaN = 0x7fff800000000000L;
>> >>         double valNaN = Double.longBitsToDouble(bitsNaN);
>> >>
>> >>         long res = Double.doubleToRawLongBits(Math.acos(valNaN));
>> >>         if (!(res == bitsNaN)) {
>> >>             throw new RuntimeException(String.format("expected 0x%x but
>> >> got 0x%x", bitsNaN, res));
>> >>         }
>> >>     }
>> >> }
>> >> ```
>> >>
>> >> What approach should we take in these cases? Is it that the test case
>> is
>> >> wrong, and should assume that given a NaN, any value of NaN returned is
>> >> valid? Or should we make sure that the behavior is the same across
>> >> platforms and that we "fix" any difference in behavior of the native
>> >> library?
>>
>> It might just be a glibc bug, we're failing the acos() tests:
>>
>> https://sourceware.org/glibc/wiki/Release/2.35#RISC-V_.28rv64imafdc.2Flp64d.29
>> .  I haven't looked at why, but they do have some nan-related bits in
>> there.
>>
>> >>
>> >> Cheers,
>> >> Ludovic
>> >>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20221208/89165d8b/attachment.htm>

From joe.darcy at oracle.com  Thu Dec  8 19:08:21 2022
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Thu, 8 Dec 2022 11:08:21 -0800
Subject: Difference in behaviour in native math library
In-Reply-To: <CADT88DvmACxJCzGMck_ccg704tra5UcCOKH1zmUsDEuszc0Srg@mail.gmail.com>
References: <CADT88DuxtUt+0OYMZeSKek1GAwEQEVXMuRK+moc4xHA9w--01Q@mail.gmail.com>
 <mhng-a511c6fe-5e68-41ca-8e2f-a89f2788ad17@palmer-ri-x1c9a>
 <CADT88DvmACxJCzGMck_ccg704tra5UcCOKH1zmUsDEuszc0Srg@mail.gmail.com>
Message-ID: <fdd372da-ba10-655b-1596-ed9ca3a607a6@oracle.com>


On 12/8/2022 10:01 AM, Ludovic Henry wrote:
> Hi,
>
> Yes, this is very much a difference of behavior at the libm/libc 
> level. I'm trying to figure out whether that behavior difference is 
> acceptable from the libm/libc level (is it considered a bug to behave 
> differently across architectures in that case?). If that behaviour is 
> acceptable in libm/libc, then is it acceptable to behave differently 
> in Java across architectures?
>
> From your answer Palmer, the difference _might_ not be acceptable in 
> the glibc test suite (I haven't check why the tests are failing). I'm 
> still trying to figure that one out.
>
> From your answer Joe, the difference _is_ acceptable from the 
> documentation. IMO the question becomes whether it's a case of the 
> implementation details bleeding into the API and whether we want to be 
> 100% compatible to avoid further issues. The fix for that could be a 
> simple `RISCV_ONLY(if (isnan(v)) return v);` or equivalent 
> in?src/java.base/share/native/libjava/StrictMath.c to match the 
> behavior without any extra cost for other platforms.


I would not support changing the library native sources (or Java 
sources) in this way to accommodate NaN handling.

-Joe

>
> Thanks,
> Ludovic
>
> On Thu, Dec 8, 2022 at 2:50 PM Palmer Dabbelt <palmer at dabbelt.com> wrote:
>
>     On Thu, 08 Dec 2022 08:26:30 PST (-0800), ludovic at rivosinc.com wrote:
>     > Adding the right address for core-libs-dev.
>     >
>     > On Thu, Dec 8, 2022 at 12:19 PM Ludovic Henry
>     <ludovic at rivosinc.com> wrote:
>     >
>     >> Hello,
>     >>
>     >> I've noticed that some Math trigonometry tests are failing in
>     the GNU
>     >> Mauve test suite. From digging into it, it's related to NaN
>     values being
>     >> passed to java.lang.Math trigonometry functions, and how these
>     values are
>     >> handled in the native libm library.
>     >>
>     >> Given the following C test case compiled and run with `gcc
>     acos.c -lm &&
>     >> ./a.out`
>     >>
>     >> ```
>     >> #include <stdint.h>
>     >> #include <math.h>
>     >> #include <stdlib.h>
>     >> #include <stdio.h>
>     >>
>     >> void main(int argc, char* argv[]) {
>     >>? ? ?int64_t bitsNaN = 0x7fff800000000000L;
>     >>? ? ?double valNaN = *((double*)&bitsNaN);
>     >>
>     >>? ? ?double resD = acos(valNaN);
>     >>? ? ?int64_t res = *((int64_t*)&resD);
>     >>? ? ?if (!(res == bitsNaN)) {
>     >>? ? ? ? ?printf("expected 0x%lx but got 0x%lx\n", bitsNaN, res);
>     >>? ? ? ? ?exit(1);
>     >>? ? ?}
>     >> }
>     >> ```
>     >>
>     >> On a Linux-x64, the test succeeds, but on Linux-RISC-V, the
>     test fails.
>     >>
>     >> You've the same test failure in the equivalent Java code:
>     >>
>     >> ```
>     >> public class acos {
>     >>? ? ?public static void main (String[] args) {
>     >>? ? ? ? ?long bitsNaN = 0x7fff800000000000L;
>     >>? ? ? ? ?double valNaN = Double.longBitsToDouble(bitsNaN);
>     >>
>     >>? ? ? ? ?long res = Double.doubleToRawLongBits(Math.acos(valNaN));
>     >>? ? ? ? ?if (!(res == bitsNaN)) {
>     >>? ? ? ? ? ? ?throw new RuntimeException(String.format("expected
>     0x%x but
>     >> got 0x%x", bitsNaN, res));
>     >>? ? ? ? ?}
>     >>? ? ?}
>     >> }
>     >> ```
>     >>
>     >> What approach should we take in these cases? Is it that the
>     test case is
>     >> wrong, and should assume that given a NaN, any value of NaN
>     returned is
>     >> valid? Or should we make sure that the behavior is the same across
>     >> platforms and that we "fix" any difference in behavior of the
>     native
>     >> library?
>
>     It might just be a glibc bug, we're failing the acos() tests:
>     https://sourceware.org/glibc/wiki/Release/2.35#RISC-V_.28rv64imafdc.2Flp64d.29
>
>     .? I haven't looked at why, but they do have some nan-related bits in
>     there.
>
>     >>
>     >> Cheers,
>     >> Ludovic
>     >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20221208/5bae7f13/attachment-0001.htm>

From stuefe at openjdk.org  Thu Dec  8 19:11:35 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 8 Dec 2022 19:11:35 GMT
Subject: RFR: 8297912: HotSpot Style Guide should permit alignas (Second
 Proposal Attempt) [v2]
In-Reply-To: <58rvZjSeJKCKUkZd4xEsQxaQjgGWs-V4IPBpSNutc0g=.883e96aa-b385-4019-80f5-69b56e732e20@github.com>
References: <Lyv_ypxMsA5tjqJ3d4KwScyySdBcTo34lL8abbF4SoQ=.44f3b51c-30b8-428e-b715-6af70bccaaf5@github.com>
 <58rvZjSeJKCKUkZd4xEsQxaQjgGWs-V4IPBpSNutc0g=.883e96aa-b385-4019-80f5-69b56e732e20@github.com>
Message-ID: <3Bjoj86AsGo7teV6Cew_nxBkpVLbGJoXQ6K0Ux4YeW8=.6634ebcc-3757-42b9-8d56-da2520a1f602@github.com>

On Sun, 4 Dec 2022 18:18:00 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> [8252584](https://bugs.openjdk.org/browse/JDK-8252584) was integrated too early due to a mistake on my part, we should redo it and go through the proper approval process this time
>> 
>> (The changes in this commit are exactly identical to 8252584)
>
> 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 two additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into style
>  - HotSpot Style Guide

Okay, I'm convinced.

-------------

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11446

From coleenp at openjdk.org  Thu Dec  8 19:25:20 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 8 Dec 2022 19:25:20 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data [v6]
In-Reply-To: <wS4niiWCO0Q8K0kjLCtooIMF_KtVPO2_e3FgbVSP8W8=.5f798928-dc87-41e6-a856-89f9a633944a@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
 <wS4niiWCO0Q8K0kjLCtooIMF_KtVPO2_e3FgbVSP8W8=.5f798928-dc87-41e6-a856-89f9a633944a@github.com>
Message-ID: <BCzC4Jf9Yg5DaKumDSorghmq-vRKW3zUl9PR9BzB1Gw=.012cce31-e8d1-428d-9df0-0fbce3c3af20@github.com>

On Thu, 8 Dec 2022 08:19:26 GMT, Justin King <jcking at openjdk.org> wrote:

>> Resolve memory leak related to `MethodData::_extra_data_lock` in `Method::build_profiling_method_data` by calling `MethodData::~MethodData()`.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment to metaprogramming usage
>   
>   Signed-off-by: Justin King <jcking at google.com>

I don't like the additional c++ code for the exceptional case of MethodData.  The lifetime of Metadata and it will leak for class unloading.  I think fixing this to be more rational for the general case would be better via the RFE that you submitted.

src/hotspot/share/oops/method.cpp line 148:

> 146: #endif
> 147:     // Destroy MethodData
> 148:     method_data()->~MethodData();

You still need this here.  This is for the class unloading path.

-------------

Changes requested by coleenp (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11526

From ludovic at rivosinc.com  Thu Dec  8 19:27:44 2022
From: ludovic at rivosinc.com (Ludovic Henry)
Date: Thu, 8 Dec 2022 16:27:44 -0300
Subject: Difference in behaviour in native math library
In-Reply-To: <fdd372da-ba10-655b-1596-ed9ca3a607a6@oracle.com>
References: <CADT88DuxtUt+0OYMZeSKek1GAwEQEVXMuRK+moc4xHA9w--01Q@mail.gmail.com>
 <mhng-a511c6fe-5e68-41ca-8e2f-a89f2788ad17@palmer-ri-x1c9a>
 <CADT88DvmACxJCzGMck_ccg704tra5UcCOKH1zmUsDEuszc0Srg@mail.gmail.com>
 <fdd372da-ba10-655b-1596-ed9ca3a607a6@oracle.com>
Message-ID: <CADT88DudMeQ6akYbz7an+QXXQrqBbn_0hTw4Hu28959ZaQxpUw@mail.gmail.com>

Hi Joe,

I got an answer on the glibc mailing list, and the overall answer is "it is
the expected behavior" [1].

>From your answer, IIUC, you would want things to stand as-is, and it's the
test case that should be fixed, correct?

Ludovic

[1] https://sourceware.org/pipermail/libc-alpha/2022-December/143912.html

On Thu, Dec 8, 2022 at 4:08 PM Joseph D. Darcy <joe.darcy at oracle.com> wrote:

>
> On 12/8/2022 10:01 AM, Ludovic Henry wrote:
>
> Hi,
>
> Yes, this is very much a difference of behavior at the libm/libc level.
> I'm trying to figure out whether that behavior difference is acceptable
> from the libm/libc level (is it considered a bug to behave differently
> across architectures in that case?). If that behaviour is acceptable in
> libm/libc, then is it acceptable to behave differently in Java across
> architectures?
>
> From your answer Palmer, the difference _might_ not be acceptable in the
> glibc test suite (I haven't check why the tests are failing). I'm still
> trying to figure that one out.
>
> From your answer Joe, the difference _is_ acceptable from the
> documentation. IMO the question becomes whether it's a case of the
> implementation details bleeding into the API and whether we want to be 100%
> compatible to avoid further issues. The fix for that could be a simple
> `RISCV_ONLY(if (isnan(v)) return v);` or equivalent
> in src/java.base/share/native/libjava/StrictMath.c to match the behavior
> without any extra cost for other platforms.
>
>
> I would not support changing the library native sources (or Java sources)
> in this way to accommodate NaN handling.
>
> -Joe
>
>
> Thanks,
> Ludovic
>
> On Thu, Dec 8, 2022 at 2:50 PM Palmer Dabbelt <palmer at dabbelt.com> wrote:
>
>> On Thu, 08 Dec 2022 08:26:30 PST (-0800), ludovic at rivosinc.com wrote:
>> > Adding the right address for core-libs-dev.
>> >
>> > On Thu, Dec 8, 2022 at 12:19 PM Ludovic Henry <ludovic at rivosinc.com>
>> wrote:
>> >
>> >> Hello,
>> >>
>> >> I've noticed that some Math trigonometry tests are failing in the GNU
>> >> Mauve test suite. From digging into it, it's related to NaN values
>> being
>> >> passed to java.lang.Math trigonometry functions, and how these values
>> are
>> >> handled in the native libm library.
>> >>
>> >> Given the following C test case compiled and run with `gcc acos.c -lm
>> &&
>> >> ./a.out`
>> >>
>> >> ```
>> >> #include <stdint.h>
>> >> #include <math.h>
>> >> #include <stdlib.h>
>> >> #include <stdio.h>
>> >>
>> >> void main(int argc, char* argv[]) {
>> >>     int64_t bitsNaN = 0x7fff800000000000L;
>> >>     double valNaN = *((double*)&bitsNaN);
>> >>
>> >>     double resD = acos(valNaN);
>> >>     int64_t res = *((int64_t*)&resD);
>> >>     if (!(res == bitsNaN)) {
>> >>         printf("expected 0x%lx but got 0x%lx\n", bitsNaN, res);
>> >>         exit(1);
>> >>     }
>> >> }
>> >> ```
>> >>
>> >> On a Linux-x64, the test succeeds, but on Linux-RISC-V, the test fails.
>> >>
>> >> You've the same test failure in the equivalent Java code:
>> >>
>> >> ```
>> >> public class acos {
>> >>     public static void main (String[] args) {
>> >>         long bitsNaN = 0x7fff800000000000L;
>> >>         double valNaN = Double.longBitsToDouble(bitsNaN);
>> >>
>> >>         long res = Double.doubleToRawLongBits(Math.acos(valNaN));
>> >>         if (!(res == bitsNaN)) {
>> >>             throw new RuntimeException(String.format("expected 0x%x but
>> >> got 0x%x", bitsNaN, res));
>> >>         }
>> >>     }
>> >> }
>> >> ```
>> >>
>> >> What approach should we take in these cases? Is it that the test case
>> is
>> >> wrong, and should assume that given a NaN, any value of NaN returned is
>> >> valid? Or should we make sure that the behavior is the same across
>> >> platforms and that we "fix" any difference in behavior of the native
>> >> library?
>>
>> It might just be a glibc bug, we're failing the acos() tests:
>>
>> https://sourceware.org/glibc/wiki/Release/2.35#RISC-V_.28rv64imafdc.2Flp64d.29
>> .  I haven't looked at why, but they do have some nan-related bits in
>> there.
>>
>> >>
>> >> Cheers,
>> >> Ludovic
>> >>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20221208/84b71aa9/attachment-0001.htm>

From stuefe at openjdk.org  Thu Dec  8 19:29:53 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 8 Dec 2022 19:29:53 GMT
Subject: RFR: JDK-8298298: NMT: count deltas are printed with 32-bit signed
 size [v2]
In-Reply-To: <F0j7gWkZgd6v0bhR27-o8ZT6IU9mtslH577QRueuGTY=.38d75256-1768-4935-b944-05655347c225@github.com>
References: <ZbO2OJmcF2KfCodEuccCdLaT9uqDahRmqn8d3juth5A=.f5c5704b-0a92-4307-b5cd-b37516140eaa@github.com>
 <Gag2hO344ircxvvTl2mNObf-37vL0-YuQnuRvUtpIJI=.384b5d4f-b930-4942-86c4-993b1cc05d47@github.com>
 <F0j7gWkZgd6v0bhR27-o8ZT6IU9mtslH577QRueuGTY=.38d75256-1768-4935-b944-05655347c225@github.com>
Message-ID: <6vEtbDsBObQtKbQvtKQLsQTHSO5C5pLnQ-0A8XjKE0Y=.4fa1d13f-aa46-4ddf-afb2-cdba459b87dd@github.com>

On Thu, 8 Dec 2022 10:36:14 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Looks okay to me.

Thanks!

> Windows builds are failing in GHA, though.

Really, Windows? No SSIZE_MAX? Sigh

-------------

PR: https://git.openjdk.org/jdk/pull/11568

From xuelei at openjdk.org  Thu Dec  8 19:41:16 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 8 Dec 2022 19:41:16 GMT
Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v19]
In-Reply-To: <fWd_NIunUhDXwy8uZSno90GC-PM8pFCey-pAMxxO0rI=.0fede0e4-1438-4321-bc8d-d11565389cae@github.com>
References: <fWd_NIunUhDXwy8uZSno90GC-PM8pFCey-pAMxxO0rI=.0fede0e4-1438-4321-bc8d-d11565389cae@github.com>
Message-ID: <W8Ac5RQQcrQmv0Z_dU-lwhu1ny1MjgGq7xvnObMFTlU=.c4eeee8b-535e-4394-99db-10a7918e8733@github.com>

> Hi,
> 
> May I have this update reviewed?
> 
> The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure.  The build could pass if warnings are disabled for codes that use sprintf method.  For the long run, the sprintf could be replaced with snprintf.  This patch is trying to check if snprintf could be used.
> 
> Thanks,
> Xuelei

Xue-Lei Andrew Fan 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 24 additional commits since the last revision:

 - adlc update per review
 - Merge
 - update on review feedback
 - comment for snprintf_checked
 - use checked snprintf for adlc
 - use checked snprintf
 - no check on adlc
 - revert use of assert
 - extra sizeof typo
 - more size_t updare for windows build
 - ... and 14 more: https://git.openjdk.org/jdk/compare/bc6e44f6...49bb58fd

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11115/files
  - new: https://git.openjdk.org/jdk/pull/11115/files/c391535c..49bb58fd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11115&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11115&range=17-18

  Stats: 67182 lines in 1253 files changed: 30641 ins; 21894 del; 14647 mod
  Patch: https://git.openjdk.org/jdk/pull/11115.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11115/head:pull/11115

PR: https://git.openjdk.org/jdk/pull/11115

From xuelei at openjdk.org  Thu Dec  8 19:41:21 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 8 Dec 2022 19:41:21 GMT
Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v18]
In-Reply-To: <WzB-dDx87yYUsyDI-yNxxLdlo_jgC80KfSuVtbh92r8=.e2595631-3427-4af5-8d1d-b8c613431a32@github.com>
References: <fWd_NIunUhDXwy8uZSno90GC-PM8pFCey-pAMxxO0rI=.0fede0e4-1438-4321-bc8d-d11565389cae@github.com>
 <ZXz5ouPFy3NE2vq1ymjOLWsp2OsvsEuAcsPDKjPpOLs=.5aac3ce6-38ed-49f2-b28d-3a0106eced05@github.com>
 <WzB-dDx87yYUsyDI-yNxxLdlo_jgC80KfSuVtbh92r8=.e2595631-3427-4af5-8d1d-b8c613431a32@github.com>
Message-ID: <0_3PyFqYlLwLgoa6GvDpc6MF__wWqCahDo0niQL7VCU=.3aa55141-e361-499e-b0d4-289c971e3fec@github.com>

On Thu, 8 Dec 2022 17:19:56 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update on review feedback
>
> src/hotspot/share/adlc/formssel.cpp line 28:
> 
>> 26: #include "adlc.hpp"
>> 27: 
>> 28: #define remaining_buflen(buffer, position) (sizeof(buffer) - (position - buffer))
> 
> Consider additional parenthesis, e.g. `((position) - (buffer))`.

It makes sense to me.  Thanks!

> src/hotspot/share/adlc/formssel.cpp line 1538:
> 
>> 1536:       }
>> 1537:       // Add predicate to working buffer
>> 1538:       snprintf_checked(s, remaining_buflen(buf, s), "/*%s*/(",(char*)i._key);
> 
> [pre-existing] the result from this snprintf could be used instead of strlen in the next line.

I'm not very sure of why "+=" is used yet.  I would like to leave as it is.

> src/hotspot/share/adlc/output_c.cpp line 546:
> 
>> 544:     char* args = new char [36 + 1];
>> 545: 
>> 546:     snprintf_checked(args, 37, "0x%x, 0x%x, %u",
> 
> Instead of 37, consider `36 + 1` to be clearly from the line above.  Or give that value a name.

Updated to use 36 + 1.

-------------

PR: https://git.openjdk.org/jdk/pull/11115

From stuefe at openjdk.org  Thu Dec  8 19:41:45 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 8 Dec 2022 19:41:45 GMT
Subject: RFR: JDK-8298298: NMT: count deltas are printed with 32-bit signed
 size [v3]
In-Reply-To: <ZbO2OJmcF2KfCodEuccCdLaT9uqDahRmqn8d3juth5A=.f5c5704b-0a92-4307-b5cd-b37516140eaa@github.com>
References: <ZbO2OJmcF2KfCodEuccCdLaT9uqDahRmqn8d3juth5A=.f5c5704b-0a92-4307-b5cd-b37516140eaa@github.com>
Message-ID: <BJru39Gpr-JRK0pgX9-TkpZGRGiAJZbL8FFrOmsLv_w=.24c2bfa5-b5d5-49b9-896d-6018d69ce6fb@github.com>

> Deltas for counts in NMT differential reports are shown as signed int, restricting them to +-2g. These counts are number of malloc blocks, or number of classes, or number of threads. In all cases number of physically existing somethings.
> 
> On large 64-bit machines they can conceivably overflow. Well, at least the malloc block counters. Granted, mallocing even just >2g number of 1 byte blocks costs about 40-50GB due to overhead in libc and NMT (on glibc). But it is conceivable.
> 
> Patch changes delta printing from int to ssize_t.
> 
> Note that I don't worry about overflowing SSIZE_MIN or SSIZE_MAX here. That would be ridiculous: we just cannot have that many physically existing things. Not on 64bit, not even on 32-bit where ssize_t is int, since in both cases the address space would be the limit. So, if the counters are that large, we have a different problem (probably counter overflow), and so we assert, resp. in release, ignore it.
> 
> Note we have the same problem with diff sizes. I expect [8281213](https://bugs.openjdk.org/browse/JDK-8281213) to fix that.

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  Provide SSIZE_MAX, SSIZE_MIN for windows

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11568/files
  - new: https://git.openjdk.org/jdk/pull/11568/files/22a577f2..5bc8d60a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11568&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11568&range=01-02

  Stats: 10 lines in 1 file changed: 10 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11568.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11568/head:pull/11568

PR: https://git.openjdk.org/jdk/pull/11568

From coleenp at openjdk.org  Thu Dec  8 20:06:34 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 8 Dec 2022 20:06:34 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data [v6]
In-Reply-To: <wS4niiWCO0Q8K0kjLCtooIMF_KtVPO2_e3FgbVSP8W8=.5f798928-dc87-41e6-a856-89f9a633944a@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
 <wS4niiWCO0Q8K0kjLCtooIMF_KtVPO2_e3FgbVSP8W8=.5f798928-dc87-41e6-a856-89f9a633944a@github.com>
Message-ID: <mwMriyRw74Xqp3s9aunjhGVoq-7QMZ9urqBIpIQC70U=.7f21183e-a041-4010-a9e1-925ac64cf60b@github.com>

On Thu, 8 Dec 2022 08:19:26 GMT, Justin King <jcking at openjdk.org> wrote:

>> Resolve memory leak related to `MethodData::_extra_data_lock` in `Method::build_profiling_method_data` by calling `MethodData::~MethodData()`.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment to metaprogramming usage
>   
>   Signed-off-by: Justin King <jcking at google.com>

The first commit made the most sense to me in the context of this code.

-------------

PR: https://git.openjdk.org/jdk/pull/11526

From coleenp at openjdk.org  Thu Dec  8 20:06:39 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 8 Dec 2022 20:06:39 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data [v4]
In-Reply-To: <h7KvPsyWWvBuaGFAUvkKh4RNLh7YmTiFTrjeKkk5ZPA=.34594540-8f2f-4ff6-84b4-f1b06f83a0ac@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
 <YZtV1CxSsTO5olTT4RuWCSwLWh5dZnAL1eEmmcH06C0=.e928d094-5ce0-417f-aef7-8e771a01f00b@github.com>
 <h7KvPsyWWvBuaGFAUvkKh4RNLh7YmTiFTrjeKkk5ZPA=.34594540-8f2f-4ff6-84b4-f1b06f83a0ac@github.com>
Message-ID: <QnLhWcmVsj86nkt1g1McatV4sU_yF5ZYTSx6eTsuqgU=.48d8f344-3172-462a-9037-8938cc27a4ed@github.com>

On Thu, 8 Dec 2022 06:29:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Justin King has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update include order to be alphabetical
>>   
>>   Signed-off-by: Justin King <jcking at google.com>
>
> src/hotspot/share/memory/metadataFactory.hpp line 77:
> 
>> 75:       if (invoke_destructor) {
>> 76:         using U = typename RemoveCV<typename RemovePointer<T>::type>::type;
>> 77:         md->~U();
> 
> I was actually thinking of a template specialization for MethodData, but I guess this works. Lets see what others think.

I don't think you can do this here.  The preceding deallocate_contents() function will deallocate the metadata so this might crash.  It's like calling the destructor after the delete operator.
Maybe before it the deallocate contents call?
Specializing for MethodData might work if you add code to tell InstanceKlass::deallocate_contents() not to call release_C_heap_structures on methods.

-------------

PR: https://git.openjdk.org/jdk/pull/11526

From coleenp at openjdk.org  Thu Dec  8 20:20:42 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 8 Dec 2022 20:20:42 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data [v4]
In-Reply-To: <QnLhWcmVsj86nkt1g1McatV4sU_yF5ZYTSx6eTsuqgU=.48d8f344-3172-462a-9037-8938cc27a4ed@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
 <YZtV1CxSsTO5olTT4RuWCSwLWh5dZnAL1eEmmcH06C0=.e928d094-5ce0-417f-aef7-8e771a01f00b@github.com>
 <h7KvPsyWWvBuaGFAUvkKh4RNLh7YmTiFTrjeKkk5ZPA=.34594540-8f2f-4ff6-84b4-f1b06f83a0ac@github.com>
 <QnLhWcmVsj86nkt1g1McatV4sU_yF5ZYTSx6eTsuqgU=.48d8f344-3172-462a-9037-8938cc27a4ed@github.com>
Message-ID: <bxiePVwUY6wAcdwHDf06tD4f2h2UCEvQnkmI0-xHI6c=.a71ec50b-9835-43ee-b19a-9e1058ee6104@github.com>

On Thu, 8 Dec 2022 20:00:24 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/memory/metadataFactory.hpp line 77:
>> 
>>> 75:       if (invoke_destructor) {
>>> 76:         using U = typename RemoveCV<typename RemovePointer<T>::type>::type;
>>> 77:         md->~U();
>> 
>> I was actually thinking of a template specialization for MethodData, but I guess this works. Lets see what others think.
>
> I don't think you can do this here.  The preceding deallocate_contents() function will deallocate the metadata so this might crash.  It's like calling the destructor after the delete operator.
> Maybe before it the deallocate contents call?
> Specializing for MethodData might work if you add code to tell InstanceKlass::deallocate_contents() not to call release_C_heap_structures on methods.

Also don't you have to free this?
    FailedSpeculation::free_failed_speculations(method_data()->get_failed_speculations_address());

-------------

PR: https://git.openjdk.org/jdk/pull/11526

From qamai at openjdk.org  Thu Dec  8 20:25:40 2022
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 8 Dec 2022 20:25:40 GMT
Subject: RFR: 8292289: [vectorapi] Improve the implementation of
 VectorTestNode [v14]
In-Reply-To: <Jo8mnLoA_9Pb8TzocN6zG5s2PGGVxS53s6XP_5CasLo=.de864d1a-51b5-4ceb-b12d-1d20e34735d7@github.com>
References: <IcR6eOr6iM1b9B1I1zUQnI2J9hQAmdSRHYc9CdIGW5E=.3b8dd64d-2eff-4659-b75a-81c4b008e41a@github.com>
 <Jo8mnLoA_9Pb8TzocN6zG5s2PGGVxS53s6XP_5CasLo=.de864d1a-51b5-4ceb-b12d-1d20e34735d7@github.com>
Message-ID: <vHUBLM_eQeOyXV2TWEohyS5zQfV0k5zHUvz4gOy7_wM=.beefa04b-a388-440c-b794-34a7600f7f4d@github.com>

On Tue, 6 Dec 2022 14:24:39 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> This patch modifies the node generation of `VectorSupport::test` to emit a `CMoveINode`, which is picked up by `BoolNode::Ideal(PhaseGVN*, bool)` to connect the `VectorTestNode` directly to the `BoolNode`, removing the redundant operations of materialising the test result in a GP register and do a `CmpI` to get back the flags. As a result, `VectorMask<T>::alltrue` is compiled into machine codes:
>> 
>>         vptest xmm0, xmm1
>>         jb if_true
>>     if_false:
>> 
>> instead of:
>> 
>>         vptest xmm0, xmm1
>>         setb r10
>>         movzbl r10
>>         testl r10
>>         jne if_true
>>     if_false:
>> 
>> The results of `jdk.incubator.vector.ArrayMismatchBenchmark` shows noticeable improvements:
>> 
>>                                                                                        Before                  After
>>     Benchmark                                      Prefix    Size   Mode  Cnt       Score      Error       Score     Error    Units  Change
>>     ArrayMismatchBenchmark.mismatchVectorByte         0.5       9  thrpt   10  217345.383 ? 8316.444  222279.381 ? 2660.983  ops/ms   +2.3%
>>     ArrayMismatchBenchmark.mismatchVectorByte         0.5     257  thrpt   10  113918.406 ? 1618.836  116268.691 ? 1291.899  ops/ms   +2.1%
>>     ArrayMismatchBenchmark.mismatchVectorByte         0.5  100000  thrpt   10     702.066 ?   72.862     797.806 ?   16.429  ops/ms  +13.6%
>>     ArrayMismatchBenchmark.mismatchVectorByte         1.0       9  thrpt   10  146096.564 ? 2401.258  145338.910 ?  687.453  ops/ms   -0.5%
>>     ArrayMismatchBenchmark.mismatchVectorByte         1.0     257  thrpt   10   60598.181 ? 1259.397   69041.519 ? 1073.156  ops/ms  +13.9%
>>     ArrayMismatchBenchmark.mismatchVectorByte         1.0  100000  thrpt   10     316.814 ?   10.975     408.770 ?    5.281  ops/ms  +29.0%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       0.5       9  thrpt   10  195674.549 ? 1200.166  188482.433 ? 1872.076  ops/ms   -3.7%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       0.5     257  thrpt   10   44357.169 ?  473.013   42293.411 ? 2838.255  ops/ms   -4.7%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       0.5  100000  thrpt   10      68.199 ?    5.410      67.628 ?    3.241  ops/ms   -0.8%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       1.0       9  thrpt   10  107722.450 ? 1677.607  111060.400 ?  982.230  ops/ms   +3.1%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       1.0     257  thrpt   10   16692.645 ? 1002.599   21440.506 ? 1618.266  ops/ms  +28.4%
>>     ArrayMismatchBenchmark.mismatchVectorDouble       1.0  100000  thrpt   10      32.984 ?    0.548      33.202 ?    2.365  ops/ms   +0.7%
>>     ArrayMismatchBenchmark.mismatchVectorInt          0.5       9  thrpt   10  335458.217 ? 3154.842  379944.254 ? 5703.134  ops/ms  +13.3%
>>     ArrayMismatchBenchmark.mismatchVectorInt          0.5     257  thrpt   10   58505.302 ?  786.312   56721.368 ? 2497.052  ops/ms   -3.0%
>>     ArrayMismatchBenchmark.mismatchVectorInt          0.5  100000  thrpt   10     133.037 ?   11.415     139.537 ?    4.667  ops/ms   +4.9%
>>     ArrayMismatchBenchmark.mismatchVectorInt          1.0       9  thrpt   10  117943.802 ? 2281.349  112409.365 ? 2110.055  ops/ms   -4.7%
>>     ArrayMismatchBenchmark.mismatchVectorInt          1.0     257  thrpt   10   27060.015 ?  795.619   33756.613 ?  826.533  ops/ms  +24.7%
>>     ArrayMismatchBenchmark.mismatchVectorInt          1.0  100000  thrpt   10      57.558 ?    8.927      66.951 ?    4.381  ops/ms  +16.3%
>>     ArrayMismatchBenchmark.mismatchVectorLong         0.5       9  thrpt   10  182963.715 ? 1042.497  182438.405 ? 2120.832  ops/ms   -0.3%
>>     ArrayMismatchBenchmark.mismatchVectorLong         0.5     257  thrpt   10   36672.215 ?  614.821   35397.398 ? 1609.235  ops/ms   -3.5%
>>     ArrayMismatchBenchmark.mismatchVectorLong         0.5  100000  thrpt   10      66.438 ?    2.142      65.427 ?    2.270  ops/ms   -1.5%
>>     ArrayMismatchBenchmark.mismatchVectorLong         1.0       9  thrpt   10  110393.047 ?  497.853  115165.845 ? 5381.674  ops/ms   +4.3%
>>     ArrayMismatchBenchmark.mismatchVectorLong         1.0     257  thrpt   10   14720.765 ?  661.350   19871.096 ?  201.464  ops/ms  +35.0%
>>     ArrayMismatchBenchmark.mismatchVectorLong         1.0  100000  thrpt   10      30.760 ?    0.821      31.933 ?    1.352  ops/ms   +3.8%
>> 
>> I have not been able to conduct throughout testing on AVX512 and Aarch64 so any help would be invaluable. Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix test

Thank everyone for your kind reviews and suggestions.

-------------

PR: https://git.openjdk.org/jdk/pull/9855

From qamai at openjdk.org  Thu Dec  8 20:28:35 2022
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 8 Dec 2022 20:28:35 GMT
Subject: Integrated: 8292289: [vectorapi] Improve the implementation of
 VectorTestNode
In-Reply-To: <IcR6eOr6iM1b9B1I1zUQnI2J9hQAmdSRHYc9CdIGW5E=.3b8dd64d-2eff-4659-b75a-81c4b008e41a@github.com>
References: <IcR6eOr6iM1b9B1I1zUQnI2J9hQAmdSRHYc9CdIGW5E=.3b8dd64d-2eff-4659-b75a-81c4b008e41a@github.com>
Message-ID: <-MU2RIz9khfb6sbHP_8eKUMut_PsmYlLteCRL8f2FnE=.8488795b-80be-4ac7-a223-4211740d8800@github.com>

On Fri, 12 Aug 2022 13:50:29 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> This patch modifies the node generation of `VectorSupport::test` to emit a `CMoveINode`, which is picked up by `BoolNode::Ideal(PhaseGVN*, bool)` to connect the `VectorTestNode` directly to the `BoolNode`, removing the redundant operations of materialising the test result in a GP register and do a `CmpI` to get back the flags. As a result, `VectorMask<T>::alltrue` is compiled into machine codes:
> 
>         vptest xmm0, xmm1
>         jb if_true
>     if_false:
> 
> instead of:
> 
>         vptest xmm0, xmm1
>         setb r10
>         movzbl r10
>         testl r10
>         jne if_true
>     if_false:
> 
> The results of `jdk.incubator.vector.ArrayMismatchBenchmark` shows noticeable improvements:
> 
>                                                                                        Before                  After
>     Benchmark                                      Prefix    Size   Mode  Cnt       Score      Error       Score     Error    Units  Change
>     ArrayMismatchBenchmark.mismatchVectorByte         0.5       9  thrpt   10  217345.383 ? 8316.444  222279.381 ? 2660.983  ops/ms   +2.3%
>     ArrayMismatchBenchmark.mismatchVectorByte         0.5     257  thrpt   10  113918.406 ? 1618.836  116268.691 ? 1291.899  ops/ms   +2.1%
>     ArrayMismatchBenchmark.mismatchVectorByte         0.5  100000  thrpt   10     702.066 ?   72.862     797.806 ?   16.429  ops/ms  +13.6%
>     ArrayMismatchBenchmark.mismatchVectorByte         1.0       9  thrpt   10  146096.564 ? 2401.258  145338.910 ?  687.453  ops/ms   -0.5%
>     ArrayMismatchBenchmark.mismatchVectorByte         1.0     257  thrpt   10   60598.181 ? 1259.397   69041.519 ? 1073.156  ops/ms  +13.9%
>     ArrayMismatchBenchmark.mismatchVectorByte         1.0  100000  thrpt   10     316.814 ?   10.975     408.770 ?    5.281  ops/ms  +29.0%
>     ArrayMismatchBenchmark.mismatchVectorDouble       0.5       9  thrpt   10  195674.549 ? 1200.166  188482.433 ? 1872.076  ops/ms   -3.7%
>     ArrayMismatchBenchmark.mismatchVectorDouble       0.5     257  thrpt   10   44357.169 ?  473.013   42293.411 ? 2838.255  ops/ms   -4.7%
>     ArrayMismatchBenchmark.mismatchVectorDouble       0.5  100000  thrpt   10      68.199 ?    5.410      67.628 ?    3.241  ops/ms   -0.8%
>     ArrayMismatchBenchmark.mismatchVectorDouble       1.0       9  thrpt   10  107722.450 ? 1677.607  111060.400 ?  982.230  ops/ms   +3.1%
>     ArrayMismatchBenchmark.mismatchVectorDouble       1.0     257  thrpt   10   16692.645 ? 1002.599   21440.506 ? 1618.266  ops/ms  +28.4%
>     ArrayMismatchBenchmark.mismatchVectorDouble       1.0  100000  thrpt   10      32.984 ?    0.548      33.202 ?    2.365  ops/ms   +0.7%
>     ArrayMismatchBenchmark.mismatchVectorInt          0.5       9  thrpt   10  335458.217 ? 3154.842  379944.254 ? 5703.134  ops/ms  +13.3%
>     ArrayMismatchBenchmark.mismatchVectorInt          0.5     257  thrpt   10   58505.302 ?  786.312   56721.368 ? 2497.052  ops/ms   -3.0%
>     ArrayMismatchBenchmark.mismatchVectorInt          0.5  100000  thrpt   10     133.037 ?   11.415     139.537 ?    4.667  ops/ms   +4.9%
>     ArrayMismatchBenchmark.mismatchVectorInt          1.0       9  thrpt   10  117943.802 ? 2281.349  112409.365 ? 2110.055  ops/ms   -4.7%
>     ArrayMismatchBenchmark.mismatchVectorInt          1.0     257  thrpt   10   27060.015 ?  795.619   33756.613 ?  826.533  ops/ms  +24.7%
>     ArrayMismatchBenchmark.mismatchVectorInt          1.0  100000  thrpt   10      57.558 ?    8.927      66.951 ?    4.381  ops/ms  +16.3%
>     ArrayMismatchBenchmark.mismatchVectorLong         0.5       9  thrpt   10  182963.715 ? 1042.497  182438.405 ? 2120.832  ops/ms   -0.3%
>     ArrayMismatchBenchmark.mismatchVectorLong         0.5     257  thrpt   10   36672.215 ?  614.821   35397.398 ? 1609.235  ops/ms   -3.5%
>     ArrayMismatchBenchmark.mismatchVectorLong         0.5  100000  thrpt   10      66.438 ?    2.142      65.427 ?    2.270  ops/ms   -1.5%
>     ArrayMismatchBenchmark.mismatchVectorLong         1.0       9  thrpt   10  110393.047 ?  497.853  115165.845 ? 5381.674  ops/ms   +4.3%
>     ArrayMismatchBenchmark.mismatchVectorLong         1.0     257  thrpt   10   14720.765 ?  661.350   19871.096 ?  201.464  ops/ms  +35.0%
>     ArrayMismatchBenchmark.mismatchVectorLong         1.0  100000  thrpt   10      30.760 ?    0.821      31.933 ?    1.352  ops/ms   +3.8%
> 
> I have not been able to conduct throughout testing on AVX512 and Aarch64 so any help would be invaluable. Thank you very much.

This pull request has now been integrated.

Changeset: 3dfadeeb
Author:    Quan Anh Mai <qamai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3dfadeebd023efb03a400f2b2656567a4154421a
Stats:     494 lines in 23 files changed: 215 ins; 170 del; 109 mod

8292289: [vectorapi] Improve the implementation of VectorTestNode

Reviewed-by: xgong, kvn

-------------

PR: https://git.openjdk.org/jdk/pull/9855

From coleenp at openjdk.org  Thu Dec  8 20:31:05 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 8 Dec 2022 20:31:05 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data [v6]
In-Reply-To: <wS4niiWCO0Q8K0kjLCtooIMF_KtVPO2_e3FgbVSP8W8=.5f798928-dc87-41e6-a856-89f9a633944a@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
 <wS4niiWCO0Q8K0kjLCtooIMF_KtVPO2_e3FgbVSP8W8=.5f798928-dc87-41e6-a856-89f9a633944a@github.com>
Message-ID: <jW0j9YpNfgdzlW5glrSFVW0ttW5StmylLnvOiwpSLsc=.c046fba6-1a24-4448-9e88-a73c935d305d@github.com>

On Thu, 8 Dec 2022 08:19:26 GMT, Justin King <jcking at openjdk.org> wrote:

>> Resolve memory leak related to `MethodData::_extra_data_lock` in `Method::build_profiling_method_data` by calling `MethodData::~MethodData()`.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment to metaprogramming usage
>   
>   Signed-off-by: Justin King <jcking at google.com>

I can't find why we thought it was more performant to embed the mutex in MethodData.

> Though it requires making Metadata hierarchy have virtual destructors to work as expected. Which should be fine, as it already has virtual functions.

Not everything that calls free_metadata is a Metadata object.  Some are MetaspaceObj and don't have virtual pointers.

-------------

PR: https://git.openjdk.org/jdk/pull/11526

From coleenp at openjdk.org  Thu Dec  8 21:30:16 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 8 Dec 2022 21:30:16 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data [v6]
In-Reply-To: <wS4niiWCO0Q8K0kjLCtooIMF_KtVPO2_e3FgbVSP8W8=.5f798928-dc87-41e6-a856-89f9a633944a@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
 <wS4niiWCO0Q8K0kjLCtooIMF_KtVPO2_e3FgbVSP8W8=.5f798928-dc87-41e6-a856-89f9a633944a@github.com>
Message-ID: <SP5N-xoPxECnjky5nEGMXd6h4gO2txAlA9dDsHpsZeI=.05fe21b4-4aeb-4708-a976-05a6b05ca7b2@github.com>

On Thu, 8 Dec 2022 08:19:26 GMT, Justin King <jcking at openjdk.org> wrote:

>> Resolve memory leak related to `MethodData::_extra_data_lock` in `Method::build_profiling_method_data` by calling `MethodData::~MethodData()`.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment to metaprogramming usage
>   
>   Signed-off-by: Justin King <jcking at google.com>

https://github.com/openjdk/jdk/pull/11601

I think I have an alternative and I posted how it's supposed to work in https://bugs.openjdk.org/browse/JDK-8298346.

-------------

PR: https://git.openjdk.org/jdk/pull/11526

From pchilanomate at openjdk.org  Thu Dec  8 21:31:09 2022
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 8 Dec 2022 21:31:09 GMT
Subject: RFR: 8298376: ZGC: thaws stackChunk with stale oops
In-Reply-To: <HoYZilP9V9gNhBjvJzCmxzE2wMzs5TmM_qjZZof_fi4=.0819f7cc-ec68-4847-a46a-3af928339415@github.com>
References: <HoYZilP9V9gNhBjvJzCmxzE2wMzs5TmM_qjZZof_fi4=.0819f7cc-ec68-4847-a46a-3af928339415@github.com>
Message-ID: <3WKe10sn6FIBKkoQmlojc3xaDqJyxGcJrxF7pVCGOSc=.df915475-6449-43a9-bd59-cf5cfcaf798e@github.com>

On Thu, 8 Dec 2022 11:05:10 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> During the recent ZGC + Loom rewrites JDK-8296875 a bug was introduced, which causes Loom to thaw stackChunks with stale oops.
> 
> Before that change we made sure that only the GC performed load barriers on the cont oop in stackChunk, so that we could use the oop state as an indication of the age of the stackChunk. That information was then used in ZCollectedHeap::requires_barriers.
> 
> In Generational ZGC we changed the implementation of requires_barriers, so that the rest of the JVM didn't need to have special-handling of the cont oop. However, when upstreaming the changes in JDK-8296875 we purposefully didn't update requires_barriers, but we incorrectly brought over the removal of the special-handling of the cont oop.
> 
> To limit the fix for this bug, I propose that we restore the special-handling of the cont oop.
> 
> I've tested this with a reproducer running Fuzz.java + ZGC.

Looks good, thanks for adding the comment.

-------------

Marked as reviewed by pchilanomate (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11585

From dholmes at openjdk.org  Thu Dec  8 21:44:13 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 8 Dec 2022 21:44:13 GMT
Subject: RFR: JDK-8298298: NMT: count deltas are printed with 32-bit signed
 size [v3]
In-Reply-To: <BJru39Gpr-JRK0pgX9-TkpZGRGiAJZbL8FFrOmsLv_w=.24c2bfa5-b5d5-49b9-896d-6018d69ce6fb@github.com>
References: <ZbO2OJmcF2KfCodEuccCdLaT9uqDahRmqn8d3juth5A=.f5c5704b-0a92-4307-b5cd-b37516140eaa@github.com>
 <BJru39Gpr-JRK0pgX9-TkpZGRGiAJZbL8FFrOmsLv_w=.24c2bfa5-b5d5-49b9-896d-6018d69ce6fb@github.com>
Message-ID: <V0LdeL6tQW6lLQ00jB9siVTqdvI-lTe7nJn5uCFfzUc=.6090e4c5-500f-4c5c-9293-83c336717041@github.com>

On Thu, 8 Dec 2022 19:41:45 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Deltas for counts in NMT differential reports are shown as signed int, restricting them to +-2g. These counts are number of malloc blocks, or number of classes, or number of threads. In all cases number of physically existing somethings.
>> 
>> On large 64-bit machines they can conceivably overflow. Well, at least the malloc block counters. Granted, mallocing even just >2g number of 1 byte blocks costs about 40-50GB due to overhead in libc and NMT (on glibc). But it is conceivable.
>> 
>> Patch changes delta printing from int to ssize_t.
>> 
>> Note that I don't worry about overflowing SSIZE_MIN or SSIZE_MAX here. That would be ridiculous: we just cannot have that many physically existing things. Not on 64bit, not even on 32-bit where ssize_t is int, since in both cases the address space would be the limit. So, if the counters are that large, we have a different problem (probably counter overflow), and so we assert, resp. in release, ignore it.
>> 
>> Note we have the same problem with diff sizes. I expect [8281213](https://bugs.openjdk.org/browse/JDK-8281213) to fix that.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Provide SSIZE_MAX, SSIZE_MIN for windows

Seems reasonable.

Thanks.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11568

From dholmes at openjdk.org  Thu Dec  8 23:35:45 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 8 Dec 2022 23:35:45 GMT
Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC
In-Reply-To: <BOJ4yH2GtNWXDVXMKwPw9Ic359dnBK8Sb9tDw3a5Qmc=.197acbb0-3ed6-418f-8bcf-70ef4b67de5e@github.com>
References: <BOJ4yH2GtNWXDVXMKwPw9Ic359dnBK8Sb9tDw3a5Qmc=.197acbb0-3ed6-418f-8bcf-70ef4b67de5e@github.com>
Message-ID: <Puf_btAdsKm8w4zx72mQKE4DCWUqM7iH98pq8G4q9ns=.40a7f975-d0ce-4828-a7c6-0d0d2ec1f558@github.com>

On Thu, 8 Dec 2022 11:23:57 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The JfrVFrameStream is used while generating stack traces for events. One of the events are the ZPage allocation event. This event is sometimes sent when ZGC is relocating. The current implementation of JfrVFrameStream uses WalkContinuation::include, which causes JFR to walk the continuation and perform GC barriers. This is problematic, since ZGC has a requirement that we never perform load barriers while running the relocation code. If we do, we might end up performing other reloctions from the the relocation code, and in some cases that causes dead locks.
> 
> I propose that JFR doesn't walk the continuations when sending events. An alternative could be to limit this to ZGC, but I'd like to get some feedback around that from JFR / Loom devs.
> 
> We've been testing this patch in the Generational ZGC repository.

What is the impact of this change on the stacktrace?

-------------

PR: https://git.openjdk.org/jdk/pull/11586

From dholmes at openjdk.org  Fri Dec  9 00:00:18 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 9 Dec 2022 00:00:18 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data [v6]
In-Reply-To: <BCzC4Jf9Yg5DaKumDSorghmq-vRKW3zUl9PR9BzB1Gw=.012cce31-e8d1-428d-9df0-0fbce3c3af20@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
 <wS4niiWCO0Q8K0kjLCtooIMF_KtVPO2_e3FgbVSP8W8=.5f798928-dc87-41e6-a856-89f9a633944a@github.com>
 <BCzC4Jf9Yg5DaKumDSorghmq-vRKW3zUl9PR9BzB1Gw=.012cce31-e8d1-428d-9df0-0fbce3c3af20@github.com>
Message-ID: <0PnHcuikWzbkHxkekPqfYHU_XfH31WLB_uWAL2RZEQ8=.41cd3f14-05e2-4b02-bd43-14ea1999fbac@github.com>

On Thu, 8 Dec 2022 19:20:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Justin King has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add comment to metaprogramming usage
>>   
>>   Signed-off-by: Justin King <jcking at google.com>
>
> src/hotspot/share/oops/method.cpp line 148:
> 
>> 146: #endif
>> 147:     // Destroy MethodData
>> 148:     method_data()->~MethodData();
> 
> You still need this here.  This is for the class unloading path.

I agree this needs to remain else we are removing other destructor calls, not just adding back the one currently missing. But it raises the question for me as to why we have two distinct code paths to clean up the MethodData: one from `Method::release_C_heap_structures` and the other from `Method::deallocate_contents`? Aren't there code paths where both of those would be executed and we would then call the destructor twice?

-------------

PR: https://git.openjdk.org/jdk/pull/11526

From dholmes at openjdk.org  Fri Dec  9 00:24:03 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 9 Dec 2022 00:24:03 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data [v6]
In-Reply-To: <0PnHcuikWzbkHxkekPqfYHU_XfH31WLB_uWAL2RZEQ8=.41cd3f14-05e2-4b02-bd43-14ea1999fbac@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
 <wS4niiWCO0Q8K0kjLCtooIMF_KtVPO2_e3FgbVSP8W8=.5f798928-dc87-41e6-a856-89f9a633944a@github.com>
 <BCzC4Jf9Yg5DaKumDSorghmq-vRKW3zUl9PR9BzB1Gw=.012cce31-e8d1-428d-9df0-0fbce3c3af20@github.com>
 <0PnHcuikWzbkHxkekPqfYHU_XfH31WLB_uWAL2RZEQ8=.41cd3f14-05e2-4b02-bd43-14ea1999fbac@github.com>
Message-ID: <x9mkoCSZaopBpWk--ngdG_7erkAYWTSrJLWUFT3Z1iM=.1c6aaa7b-7a77-44d8-b3ab-bdb05a663b3e@github.com>

On Thu, 8 Dec 2022 23:57:46 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/oops/method.cpp line 148:
>> 
>>> 146: #endif
>>> 147:     // Destroy MethodData
>>> 148:     method_data()->~MethodData();
>> 
>> You still need this here.  This is for the class unloading path.
>
> I agree this needs to remain else we are removing other destructor calls, not just adding back the one currently missing. But it raises the question for me as to why we have two distinct code paths to clean up the MethodData: one from `Method::release_C_heap_structures` and the other from `Method::deallocate_contents`? Aren't there code paths where both of those would be executed and we would then call the destructor twice?

I just saw the other comments point to the comment in JDK-8298346 so no need to respond to this.

-------------

PR: https://git.openjdk.org/jdk/pull/11526

From dholmes at openjdk.org  Fri Dec  9 01:53:40 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 9 Dec 2022 01:53:40 GMT
Subject: RFR: 8292674: ReportJNIFatalError should print all java frames
 [v4]
In-Reply-To: <-ipNtt5PSZ2d7VUBSoduPyNwnW2GeN_y0Dcs95qI8HU=.c4771172-01dd-49ae-8f4a-9d5cbd6c6dad@github.com>
References: <-ipNtt5PSZ2d7VUBSoduPyNwnW2GeN_y0Dcs95qI8HU=.c4771172-01dd-49ae-8f4a-9d5cbd6c6dad@github.com>
Message-ID: <uUWb1njnLGXpTVPEx-n4QElmN9urKxquYk2n0TcaMVg=.221b1735-4325-4aae-91f5-2ba1b832ff58@github.com>

> When JNI reports errors and warnings and produces a stack trace, we need to see the exact Java code that was being executed. The existing `JavaThread::print_stack` that is used is only for platform/carrier threads and doesn't show any mounted virtual thread. So we introduce a new `JavaThread::print_virtual_stack_on` method to print the mounted virtual thread's stack, and we add `JavaThread::print_jni_stack` as a utility for JNI to call that dispatches to the appropriate function based on the thread type.
> 
> The existing test `hotspot/jtreg/runtime/jni/checked/TestPrimitiveArrayCriticalWithBadParam.java` was modified to test regular and virtual threads, and to expect to see the specific stack frame of the Java native method.
> 
> Additional manual testing of the JNI `FatalError` method was done by direct fault injection in modified JDK code.
> 
> Sanity testing: Oracle tiers 1-4 (to include our -Xcheck:jni run in tier4)
> 
> Thanks,
> David

David Holmes 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 four additional commits since the last revision:

 - Merge branch 'master' into 8292674-ReportJNIFatalError-v2
 - Merge branch 'master' into 8292674-ReportJNIFatalError-v2
 - Changed RegisterMap to include process_frame and update, for object monitor examination.
   Updated stack printing for exception checks.
 - 8292674: ReportJNIFatalError should print all java frames

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11503/files
  - new: https://git.openjdk.org/jdk/pull/11503/files/f4fd2893..b96f02d1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11503&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11503&range=02-03

  Stats: 6777 lines in 161 files changed: 5833 ins; 390 del; 554 mod
  Patch: https://git.openjdk.org/jdk/pull/11503.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11503/head:pull/11503

PR: https://git.openjdk.org/jdk/pull/11503

From jcking at openjdk.org  Fri Dec  9 05:34:09 2022
From: jcking at openjdk.org (Justin King)
Date: Fri, 9 Dec 2022 05:34:09 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data [v6]
In-Reply-To: <jW0j9YpNfgdzlW5glrSFVW0ttW5StmylLnvOiwpSLsc=.c046fba6-1a24-4448-9e88-a73c935d305d@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
 <wS4niiWCO0Q8K0kjLCtooIMF_KtVPO2_e3FgbVSP8W8=.5f798928-dc87-41e6-a856-89f9a633944a@github.com>
 <jW0j9YpNfgdzlW5glrSFVW0ttW5StmylLnvOiwpSLsc=.c046fba6-1a24-4448-9e88-a73c935d305d@github.com>
Message-ID: <4M1RjVKyDfMxnjS4mY2ftkjYy-PpOLXC_u18XkFBdcQ=.5c042064-61de-4755-a32a-4eff261a46c9@github.com>

On Thu, 8 Dec 2022 20:28:45 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I can't find why we thought it was more performant to embed the mutex in MethodData.

If I had to guess, its because it removes an allocation. Mutex currently performs strdup on the name. So creating a Mutex via `new` requires 2 allocations. Embedding it requires 1.

-------------

PR: https://git.openjdk.org/jdk/pull/11526

From jcking at openjdk.org  Fri Dec  9 06:24:59 2022
From: jcking at openjdk.org (Justin King)
Date: Fri, 9 Dec 2022 06:24:59 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data [v6]
In-Reply-To: <wS4niiWCO0Q8K0kjLCtooIMF_KtVPO2_e3FgbVSP8W8=.5f798928-dc87-41e6-a856-89f9a633944a@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
 <wS4niiWCO0Q8K0kjLCtooIMF_KtVPO2_e3FgbVSP8W8=.5f798928-dc87-41e6-a856-89f9a633944a@github.com>
Message-ID: <yzgLf33LqCezCK145A16U4gEZeoHpewQ_Ffeahg5mao=.2baeb70a-85a5-49b5-baae-46fca9be7d0f@github.com>

On Thu, 8 Dec 2022 08:19:26 GMT, Justin King <jcking at openjdk.org> wrote:

>> Resolve memory leak related to `MethodData::_extra_data_lock` in `Method::build_profiling_method_data` by calling `MethodData::~MethodData()`.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment to metaprogramming usage
>   
>   Signed-off-by: Justin King <jcking at google.com>

> See: #11601 Was there a test for this?

Not directly, with the proposed approach (I left a comment as I was still a little confused), it might actually be possible. However it will be much easier to catch once I upstream LSan. Speaking of that, I filed https://bugs.openjdk.org/browse/JDK-8298445 as I have been meaning to.

-------------

PR: https://git.openjdk.org/jdk/pull/11526

From stuefe at openjdk.org  Fri Dec  9 06:57:57 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 9 Dec 2022 06:57:57 GMT
Subject: RFR: JDK-8298298: NMT: count deltas are printed with 32-bit signed
 size [v3]
In-Reply-To: <V0LdeL6tQW6lLQ00jB9siVTqdvI-lTe7nJn5uCFfzUc=.6090e4c5-500f-4c5c-9293-83c336717041@github.com>
References: <ZbO2OJmcF2KfCodEuccCdLaT9uqDahRmqn8d3juth5A=.f5c5704b-0a92-4307-b5cd-b37516140eaa@github.com>
 <BJru39Gpr-JRK0pgX9-TkpZGRGiAJZbL8FFrOmsLv_w=.24c2bfa5-b5d5-49b9-896d-6018d69ce6fb@github.com>
 <V0LdeL6tQW6lLQ00jB9siVTqdvI-lTe7nJn5uCFfzUc=.6090e4c5-500f-4c5c-9293-83c336717041@github.com>
Message-ID: <Wa2hgrtQotoTmIKlcQzGBVYQviRSa9JOlTLRN6GqAZY=.f837f6f3-3060-40c5-8e13-a1a6ea270ab4@github.com>

On Thu, 8 Dec 2022 21:42:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Seems reasonable.
> 
> Thanks.

Thanks, David!

-------------

PR: https://git.openjdk.org/jdk/pull/11568

From rehn at openjdk.org  Fri Dec  9 08:44:59 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Fri, 9 Dec 2022 08:44:59 GMT
Subject: RFR: 8292674: ReportJNIFatalError should print all java frames
 [v4]
In-Reply-To: <uUWb1njnLGXpTVPEx-n4QElmN9urKxquYk2n0TcaMVg=.221b1735-4325-4aae-91f5-2ba1b832ff58@github.com>
References: <-ipNtt5PSZ2d7VUBSoduPyNwnW2GeN_y0Dcs95qI8HU=.c4771172-01dd-49ae-8f4a-9d5cbd6c6dad@github.com>
 <uUWb1njnLGXpTVPEx-n4QElmN9urKxquYk2n0TcaMVg=.221b1735-4325-4aae-91f5-2ba1b832ff58@github.com>
Message-ID: <zC7Sw1liRMkX_BMH0bm0hUGLBjPBjnYoOsuqMMrMjWE=.a67af3d0-8642-47d9-ab3a-cfe40f9e16d3@github.com>

On Fri, 9 Dec 2022 01:53:40 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> When JNI reports errors and warnings and produces a stack trace, we need to see the exact Java code that was being executed. The existing `JavaThread::print_stack` that is used is only for platform/carrier threads and doesn't show any mounted virtual thread. So we introduce a new `JavaThread::print_virtual_stack_on` method to print the mounted virtual thread's stack, and we add `JavaThread::print_jni_stack` as a utility for JNI to call that dispatches to the appropriate function based on the thread type.
>> 
>> The existing test `hotspot/jtreg/runtime/jni/checked/TestPrimitiveArrayCriticalWithBadParam.java` was modified to test regular and virtual threads, and to expect to see the specific stack frame of the Java native method.
>> 
>> Additional manual testing of the JNI `FatalError` method was done by direct fault injection in modified JDK code.
>> 
>> Sanity testing: Oracle tiers 1-4 (to include our -Xcheck:jni run in tier4)
>> 
>> Thanks,
>> David
>
> David Holmes 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 four additional commits since the last revision:
> 
>  - Merge branch 'master' into 8292674-ReportJNIFatalError-v2
>  - Merge branch 'master' into 8292674-ReportJNIFatalError-v2
>  - Changed RegisterMap to include process_frame and update, for object monitor examination.
>    Updated stack printing for exception checks.
>  - 8292674: ReportJNIFatalError should print all java frames

Looks good, thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/11503

From duke at openjdk.org  Fri Dec  9 10:34:00 2022
From: duke at openjdk.org (Afshin Zafari)
Date: Fri, 9 Dec 2022 10:34:00 GMT
Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v2]
In-Reply-To: <2R1SvRfKINep3LbJNfi35pZbDaKSbJY-SHCtvEOfz08=.39007aa6-aff1-4d30-9e8e-882f172d1c98@github.com>
References: <Dj9YfY10SLn8dR1Ez3kEQe4tXm1q5W1TS8_4r3gBUsY=.6c38825a-86e5-4575-a509-683786d242a6@github.com>
 <yhzD_0pdvCEtA9UVulZ_mDq9sO82qwINAUBgjA3pLqE=.7465110b-b732-4b0d-8054-da1ff1764296@github.com>
 <2R1SvRfKINep3LbJNfi35pZbDaKSbJY-SHCtvEOfz08=.39007aa6-aff1-4d30-9e8e-882f172d1c98@github.com>
Message-ID: <QyJe30epjraoL13OUGf3r-VJeb7gojzzzU5ytopZApI=.61de9ace-1a19-418a-a648-9a2323500893@github.com>

On Tue, 6 Dec 2022 04:54:50 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This PR seems to be broken now - full of unexpected changes.

The PR changed files are correct now.

-------------

PR: https://git.openjdk.org/jdk/pull/11288

From stuefe at openjdk.org  Fri Dec  9 10:40:37 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 9 Dec 2022 10:40:37 GMT
Subject: RFR: JDK-8298298: NMT: count deltas are printed with 32-bit signed
 size [v4]
In-Reply-To: <ZbO2OJmcF2KfCodEuccCdLaT9uqDahRmqn8d3juth5A=.f5c5704b-0a92-4307-b5cd-b37516140eaa@github.com>
References: <ZbO2OJmcF2KfCodEuccCdLaT9uqDahRmqn8d3juth5A=.f5c5704b-0a92-4307-b5cd-b37516140eaa@github.com>
Message-ID: <p1U9cRKl0J85Ibh_Jml7eonxR_O559-6ZLrJu4Ry_Wo=.3b2d21c5-237e-4567-9d86-6f391013627f@github.com>

> Deltas for counts in NMT differential reports are shown as signed int, restricting them to +-2g. These counts are number of malloc blocks, or number of classes, or number of threads. In all cases number of physically existing somethings.
> 
> On large 64-bit machines they can conceivably overflow. Well, at least the malloc block counters. Granted, mallocing even just >2g number of 1 byte blocks costs about 40-50GB due to overhead in libc and NMT (on glibc). But it is conceivable.
> 
> Patch changes delta printing from int to ssize_t.
> 
> Note that I don't worry about overflowing SSIZE_MIN or SSIZE_MAX here. That would be ridiculous: we just cannot have that many physically existing things. Not on 64bit, not even on 32-bit where ssize_t is int, since in both cases the address space would be the limit. So, if the counters are that large, we have a different problem (probably counter overflow), and so we assert, resp. in release, ignore it.
> 
> Note we have the same problem with diff sizes. I expect [8281213](https://bugs.openjdk.org/browse/JDK-8281213) to fix that.

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  work around Windows weirdness where we cannot print INT_MIN (-2147483648)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11568/files
  - new: https://git.openjdk.org/jdk/pull/11568/files/5bc8d60a..2d848169

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11568&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11568&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11568.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11568/head:pull/11568

PR: https://git.openjdk.org/jdk/pull/11568

From thartmann at openjdk.org  Fri Dec  9 11:06:02 2022
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 9 Dec 2022 11:06:02 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data [v6]
In-Reply-To: <wS4niiWCO0Q8K0kjLCtooIMF_KtVPO2_e3FgbVSP8W8=.5f798928-dc87-41e6-a856-89f9a633944a@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
 <wS4niiWCO0Q8K0kjLCtooIMF_KtVPO2_e3FgbVSP8W8=.5f798928-dc87-41e6-a856-89f9a633944a@github.com>
Message-ID: <mSLwbFtCZwJ497RkubErvyzyQvxdfbbcgPNPBmuEJjU=.0a9891e2-7bcb-4cd0-9c5a-9bc0fa59af95@github.com>

On Thu, 8 Dec 2022 08:19:26 GMT, Justin King <jcking at openjdk.org> wrote:

>> Resolve memory leak related to `MethodData::_extra_data_lock` in `Method::build_profiling_method_data` by calling `MethodData::~MethodData()`.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment to metaprogramming usage
>   
>   Signed-off-by: Justin King <jcking at google.com>

I'm leaving this to the runtime experts to review but the PR needs to be rebased for JDK 20 in any case.

-------------

Changes requested by thartmann (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11526

From coleenp at openjdk.org  Fri Dec  9 12:27:59 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 9 Dec 2022 12:27:59 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data [v6]
In-Reply-To: <wS4niiWCO0Q8K0kjLCtooIMF_KtVPO2_e3FgbVSP8W8=.5f798928-dc87-41e6-a856-89f9a633944a@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
 <wS4niiWCO0Q8K0kjLCtooIMF_KtVPO2_e3FgbVSP8W8=.5f798928-dc87-41e6-a856-89f9a633944a@github.com>
Message-ID: <-sH5M8TqDC48uXPMfVjHBVTGsuVLBMnCHfp2ji0TTSQ=.54357ef4-5532-42e0-81b0-8fc36ce5f5b1@github.com>

On Thu, 8 Dec 2022 08:19:26 GMT, Justin King <jcking at openjdk.org> wrote:

>> Resolve memory leak related to `MethodData::_extra_data_lock` in `Method::build_profiling_method_data` by calling `MethodData::~MethodData()`.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment to metaprogramming usage
>   
>   Signed-off-by: Justin King <jcking at google.com>

I want to take over this fix and I will rebase it to JDK 20.  Sorry for being so late to remembering how this code works.  The LSan tool sounds great.  I'll pay attention to that now.

-------------

PR: https://git.openjdk.org/jdk/pull/11526

From jwaters at openjdk.org  Fri Dec  9 12:33:06 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 9 Dec 2022 12:33:06 GMT
Subject: RFR: 8297912: HotSpot Style Guide should permit alignas (Second
 Proposal Attempt) [v3]
In-Reply-To: <Lyv_ypxMsA5tjqJ3d4KwScyySdBcTo34lL8abbF4SoQ=.44f3b51c-30b8-428e-b715-6af70bccaaf5@github.com>
References: <Lyv_ypxMsA5tjqJ3d4KwScyySdBcTo34lL8abbF4SoQ=.44f3b51c-30b8-428e-b715-6af70bccaaf5@github.com>
Message-ID: <IR4wZ0h1SIeSAFLjug036bqINNJQrQFD90VTplI6jM4=.6af0451a-5523-4aa2-9a3e-6af66f6e059d@github.com>

> [8252584](https://bugs.openjdk.org/browse/JDK-8252584) was integrated too early due to a mistake on my part, we should redo it and go through the proper approval process this time
> 
> (The changes in this commit are exactly identical to 8252584)

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Style

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11446/files
  - new: https://git.openjdk.org/jdk/pull/11446/files/792b96a2..33759314

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11446&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11446&range=01-02

  Stats: 12 lines in 2 files changed: 1 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/11446.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11446/head:pull/11446

PR: https://git.openjdk.org/jdk/pull/11446

From jwaters at openjdk.org  Fri Dec  9 12:33:08 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 9 Dec 2022 12:33:08 GMT
Subject: RFR: 8297912: HotSpot Style Guide should permit alignas (Second
 Proposal Attempt) [v2]
In-Reply-To: <58rvZjSeJKCKUkZd4xEsQxaQjgGWs-V4IPBpSNutc0g=.883e96aa-b385-4019-80f5-69b56e732e20@github.com>
References: <Lyv_ypxMsA5tjqJ3d4KwScyySdBcTo34lL8abbF4SoQ=.44f3b51c-30b8-428e-b715-6af70bccaaf5@github.com>
 <58rvZjSeJKCKUkZd4xEsQxaQjgGWs-V4IPBpSNutc0g=.883e96aa-b385-4019-80f5-69b56e732e20@github.com>
Message-ID: <WuvPImgv0DYTp2M9VvB6FahPCaMcJmqlJdzC1PGBCNU=.fa5c19c8-52cc-4661-8e19-8e2f8532ab54@github.com>

On Sun, 4 Dec 2022 18:18:00 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> [8252584](https://bugs.openjdk.org/browse/JDK-8252584) was integrated too early due to a mistake on my part, we should redo it and go through the proper approval process this time
>> 
>> (The changes in this commit are exactly identical to 8252584)
>
> 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 two additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into style
>  - HotSpot Style Guide

Don't mind me, just making it look a little better

-------------

PR: https://git.openjdk.org/jdk/pull/11446

From coleenp at openjdk.org  Fri Dec  9 12:35:36 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 9 Dec 2022 12:35:36 GMT
Subject: [jdk20] RFR: 8296955: Kitchensink.java failed with
 "double free or corruption (!prev): <addr>"
Message-ID: <-rew__nvw1aQv6-lfTVkU-DGA_rjP4JypTsIj2ozblI=.21be566f-c364-4537-86b6-35e7d12e3e4e@github.com>

Thanks to Kim for the diagnosis of this problem.  G1 cleans up nmethods in parallel threads during a safepoint and may post or queue unload events to be posted.  The event posting creates jmethodIDs.  The jmethodID code assumes that it's thread safe in a safepoint, which it is not.
I removed this optimization, which isn't much of an optimization (did run some sanity performance tests) and is unsafe in the modern code.
Tested with tier1-7, where tier5 found the original bug.

-------------

Commit messages:
 - 8296955: Kitchensink.java failed with "double free or corruption (!prev): <addr>"

Changes: https://git.openjdk.org/jdk20/pull/10/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=10&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296955
  Stats: 89 lines in 3 files changed: 14 ins; 50 del; 25 mod
  Patch: https://git.openjdk.org/jdk20/pull/10.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/10/head:pull/10

PR: https://git.openjdk.org/jdk20/pull/10

From coleenp at openjdk.org  Fri Dec  9 12:35:38 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 9 Dec 2022 12:35:38 GMT
Subject: [jdk20] RFR: 8296955: Kitchensink.java failed with
 "double free or corruption (!prev): <addr>"
In-Reply-To: <-rew__nvw1aQv6-lfTVkU-DGA_rjP4JypTsIj2ozblI=.21be566f-c364-4537-86b6-35e7d12e3e4e@github.com>
References: <-rew__nvw1aQv6-lfTVkU-DGA_rjP4JypTsIj2ozblI=.21be566f-c364-4537-86b6-35e7d12e3e4e@github.com>
Message-ID: <C2-RUzQ_9L84746JOAlljGGVT5YJxUS4T13lOSsThUc=.85211790-80c0-4ac5-8491-2ccc946b4595@github.com>

On Fri, 9 Dec 2022 12:27:42 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Thanks to Kim for the diagnosis of this problem.  G1 cleans up nmethods in parallel threads during a safepoint and may post or queue unload events to be posted.  The event posting creates jmethodIDs.  The jmethodID code assumes that it's thread safe in a safepoint, which it is not.
> I removed this optimization, which isn't much of an optimization (did run some sanity performance tests) and is unsafe in the modern code.
> Tested with tier1-7, where tier5 found the original bug.

The JmethodIdCreation_lock used to be a safepoint checking lock, and have higher rank.  It's now a no-safepoint lock and has a relatively low ranking so this change is safer from rank checking than when it was first written.

-------------

PR: https://git.openjdk.org/jdk20/pull/10

From jcking at openjdk.org  Fri Dec  9 12:39:54 2022
From: jcking at openjdk.org (Justin King)
Date: Fri, 9 Dec 2022 12:39:54 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data [v6]
In-Reply-To: <wS4niiWCO0Q8K0kjLCtooIMF_KtVPO2_e3FgbVSP8W8=.5f798928-dc87-41e6-a856-89f9a633944a@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
 <wS4niiWCO0Q8K0kjLCtooIMF_KtVPO2_e3FgbVSP8W8=.5f798928-dc87-41e6-a856-89f9a633944a@github.com>
Message-ID: <4nCE51hAjTZxFOTdx30a8wEW1z1sXDK6Mx_g_LpLp1c=.c837ba04-1338-4d25-947b-fc801bec8b84@github.com>

On Thu, 8 Dec 2022 08:19:26 GMT, Justin King <jcking at openjdk.org> wrote:

>> Resolve memory leak related to `MethodData::_extra_data_lock` in `Method::build_profiling_method_data` by calling `MethodData::~MethodData()`.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment to metaprogramming usage
>   
>   Signed-off-by: Justin King <jcking at google.com>

Sure, no problem! Will be faster that way. Feel free to tag the other issue
related to convoluted memory management. Maybe dropping that comment in
related code and resolving it. Awkward but well documented is just as good.

On Fri, Dec 9, 2022, 5:54 PM Coleen Phillimore ***@***.***>
wrote:

> I want to take over this fix and I will rebase it to JDK 20. Sorry for
> being so late to remembering how this code works. The LSan tool sounds
> great. I'll pay attention to that now.
>
> ?
> Reply to this email directly, view it on GitHub
> <https://github.com/openjdk/jdk/pull/11526#issuecomment-1344243663>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAHTURQDPA544PWCOYWEFXDWMMQG7ANCNFSM6AAAAAASVDQ4QQ>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>

-------------

PR: https://git.openjdk.org/jdk/pull/11526

From stuefe at openjdk.org  Fri Dec  9 13:14:09 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 9 Dec 2022 13:14:09 GMT
Subject: RFR: JDK-8298298: NMT: count deltas are printed with 32-bit signed
 size [v5]
In-Reply-To: <ZbO2OJmcF2KfCodEuccCdLaT9uqDahRmqn8d3juth5A=.f5c5704b-0a92-4307-b5cd-b37516140eaa@github.com>
References: <ZbO2OJmcF2KfCodEuccCdLaT9uqDahRmqn8d3juth5A=.f5c5704b-0a92-4307-b5cd-b37516140eaa@github.com>
Message-ID: <cG0y-Mk04MxD5AdYkb9iU13O5Qg_S8tQh9x36F7LnR8=.5ecafc6c-75b8-4d61-9660-72affb8b0cf7@github.com>

> Deltas for counts in NMT differential reports are shown as signed int, restricting them to +-2g. These counts are number of malloc blocks, or number of classes, or number of threads. In all cases number of physically existing somethings.
> 
> On large 64-bit machines they can conceivably overflow. Well, at least the malloc block counters. Granted, mallocing even just >2g number of 1 byte blocks costs about 40-50GB due to overhead in libc and NMT (on glibc). But it is conceivable.
> 
> Patch changes delta printing from int to ssize_t.
> 
> Note that I don't worry about overflowing SSIZE_MIN or SSIZE_MAX here. That would be ridiculous: we just cannot have that many physically existing things. Not on 64bit, not even on 32-bit where ssize_t is int, since in both cases the address space would be the limit. So, if the counters are that large, we have a different problem (probably counter overflow), and so we assert, resp. in release, ignore it.
> 
> Note we have the same problem with diff sizes. I expect [8281213](https://bugs.openjdk.org/browse/JDK-8281213) to fix that.

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11568/files
  - new: https://git.openjdk.org/jdk/pull/11568/files/2d848169..8299613e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11568&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11568&range=03-04

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11568.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11568/head:pull/11568

PR: https://git.openjdk.org/jdk/pull/11568

From stuefe at openjdk.org  Fri Dec  9 13:26:32 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 9 Dec 2022 13:26:32 GMT
Subject: RFR: JDK-8298298: NMT: count deltas are printed with 32-bit signed
 size [v6]
In-Reply-To: <ZbO2OJmcF2KfCodEuccCdLaT9uqDahRmqn8d3juth5A=.f5c5704b-0a92-4307-b5cd-b37516140eaa@github.com>
References: <ZbO2OJmcF2KfCodEuccCdLaT9uqDahRmqn8d3juth5A=.f5c5704b-0a92-4307-b5cd-b37516140eaa@github.com>
Message-ID: <swyWHWyxufeGo5T-JPE4xxWobbb4LAFUWXlQWc9N42I=.c3aa9ffb-cbc3-4ebe-9813-6739064a3bef@github.com>

> Deltas for counts in NMT differential reports are shown as signed int, restricting them to +-2g. These counts are number of malloc blocks, or number of classes, or number of threads. In all cases number of physically existing somethings.
> 
> On large 64-bit machines they can conceivably overflow. Well, at least the malloc block counters. Granted, mallocing even just >2g number of 1 byte blocks costs about 40-50GB due to overhead in libc and NMT (on glibc). But it is conceivable.
> 
> Patch changes delta printing from int to ssize_t.
> 
> Note that I don't worry about overflowing SSIZE_MIN or SSIZE_MAX here. That would be ridiculous: we just cannot have that many physically existing things. Not on 64bit, not even on 32-bit where ssize_t is int, since in both cases the address space would be the limit. So, if the counters are that large, we have a different problem (probably counter overflow), and so we assert, resp. in release, ignore it.
> 
> Note we have the same problem with diff sizes. I expect [8281213](https://bugs.openjdk.org/browse/JDK-8281213) to fix that.

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  Provide INT64_PLUS_FORMAT

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11568/files
  - new: https://git.openjdk.org/jdk/pull/11568/files/8299613e..8a124873

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11568&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11568&range=04-05

  Stats: 10 lines in 2 files changed: 10 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11568.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11568/head:pull/11568

PR: https://git.openjdk.org/jdk/pull/11568

From stuefe at openjdk.org  Fri Dec  9 13:29:47 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 9 Dec 2022 13:29:47 GMT
Subject: RFR: JDK-8298298: NMT: count deltas are printed with 32-bit signed
 size [v7]
In-Reply-To: <ZbO2OJmcF2KfCodEuccCdLaT9uqDahRmqn8d3juth5A=.f5c5704b-0a92-4307-b5cd-b37516140eaa@github.com>
References: <ZbO2OJmcF2KfCodEuccCdLaT9uqDahRmqn8d3juth5A=.f5c5704b-0a92-4307-b5cd-b37516140eaa@github.com>
Message-ID: <lgnue-mVLZzbnPszx5i9IWBezjBiNFfCNsk0Pr0zrNE=.aa69188f-8e3d-473c-bbc0-15a9d937f23e@github.com>

> Deltas for counts in NMT differential reports are shown as signed int, restricting them to +-2g. These counts are number of malloc blocks, or number of classes, or number of threads. In all cases number of physically existing somethings.
> 
> On large 64-bit machines they can conceivably overflow. Well, at least the malloc block counters. Granted, mallocing even just >2g number of 1 byte blocks costs about 40-50GB due to overhead in libc and NMT (on glibc). But it is conceivable.
> 
> Patch changes delta printing from int to ssize_t.
> 
> Note that I don't worry about overflowing SSIZE_MIN or SSIZE_MAX here. That would be ridiculous: we just cannot have that many physically existing things. Not on 64bit, not even on 32-bit where ssize_t is int, since in both cases the address space would be the limit. So, if the counters are that large, we have a different problem (probably counter overflow), and so we assert, resp. in release, ignore it.
> 
> Note we have the same problem with diff sizes. I expect [8281213](https://bugs.openjdk.org/browse/JDK-8281213) to fix that.

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  Revert "Provide INT64_PLUS_FORMAT"
  
  This reverts commit 8a124873e09cf1e229228103c3dad622b0e913f9.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11568/files
  - new: https://git.openjdk.org/jdk/pull/11568/files/8a124873..6f6ab88a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11568&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11568&range=05-06

  Stats: 10 lines in 2 files changed: 0 ins; 10 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11568.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11568/head:pull/11568

PR: https://git.openjdk.org/jdk/pull/11568

From stefank at openjdk.org  Fri Dec  9 14:54:09 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 9 Dec 2022 14:54:09 GMT
Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC
In-Reply-To: <Puf_btAdsKm8w4zx72mQKE4DCWUqM7iH98pq8G4q9ns=.40a7f975-d0ce-4828-a7c6-0d0d2ec1f558@github.com>
References: <BOJ4yH2GtNWXDVXMKwPw9Ic359dnBK8Sb9tDw3a5Qmc=.197acbb0-3ed6-418f-8bcf-70ef4b67de5e@github.com>
 <Puf_btAdsKm8w4zx72mQKE4DCWUqM7iH98pq8G4q9ns=.40a7f975-d0ce-4828-a7c6-0d0d2ec1f558@github.com>
Message-ID: <lN-tnCa5vyMWJW5b6Y0X_ph_lVlkYvIkdw0A-EDa_U0=.d7a68f7a-f995-4b49-a2b4-d905c96db62f@github.com>

On Thu, 8 Dec 2022 23:33:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

> What is the impact of this change on the stacktrace?

I hope @pron or the JFR team can help answering this.

-------------

PR: https://git.openjdk.org/jdk/pull/11586

From rpressler at openjdk.org  Fri Dec  9 14:54:10 2022
From: rpressler at openjdk.org (Ron Pressler)
Date: Fri, 9 Dec 2022 14:54:10 GMT
Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC
In-Reply-To: <BOJ4yH2GtNWXDVXMKwPw9Ic359dnBK8Sb9tDw3a5Qmc=.197acbb0-3ed6-418f-8bcf-70ef4b67de5e@github.com>
References: <BOJ4yH2GtNWXDVXMKwPw9Ic359dnBK8Sb9tDw3a5Qmc=.197acbb0-3ed6-418f-8bcf-70ef4b67de5e@github.com>
Message-ID: <l9hDFmlOYmB9rovJrAfcu7MGgfMVesVL4brZFM6jbtc=.c763dace-9943-4f16-ba84-377c59b7530b@github.com>

On Thu, 8 Dec 2022 11:23:57 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The JfrVFrameStream is used while generating stack traces for events. One of the events are the ZPage allocation event. This event is sometimes sent when ZGC is relocating. The current implementation of JfrVFrameStream uses WalkContinuation::include, which causes JFR to walk the continuation and perform GC barriers. This is problematic, since ZGC has a requirement that we never perform load barriers while running the relocation code. If we do, we might end up performing other reloctions from the the relocation code, and in some cases that causes dead locks.
> 
> I propose that JFR doesn't walk the continuations when sending events. An alternative could be to limit this to ZGC, but I'd like to get some feedback around that from JFR / Loom devs.
> 
> We've been testing this patch in the Generational ZGC repository.

It means that some arbitrary prefix of continuation frames, starting with the oldest, will not be in the stack trace. E.g., if the stack trace is A -> B -> C -> D -> E, it's possible that the resulting trace will contain only, say, C -> D -> E, or D -> E etc.

-------------

PR: https://git.openjdk.org/jdk/pull/11586

From stefank at openjdk.org  Fri Dec  9 14:54:10 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 9 Dec 2022 14:54:10 GMT
Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC
In-Reply-To: <BOJ4yH2GtNWXDVXMKwPw9Ic359dnBK8Sb9tDw3a5Qmc=.197acbb0-3ed6-418f-8bcf-70ef4b67de5e@github.com>
References: <BOJ4yH2GtNWXDVXMKwPw9Ic359dnBK8Sb9tDw3a5Qmc=.197acbb0-3ed6-418f-8bcf-70ef4b67de5e@github.com>
Message-ID: <aYGTGrmckskBOEwz3ZnLWQ6Q15vJeA61iPDBscJxAlY=.25bdb109-41f0-4a5c-a7ba-a698c5c47e6c@github.com>

On Thu, 8 Dec 2022 11:23:57 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The JfrVFrameStream is used while generating stack traces for events. One of the events are the ZPage allocation event. This event is sometimes sent when ZGC is relocating. The current implementation of JfrVFrameStream uses WalkContinuation::include, which causes JFR to walk the continuation and perform GC barriers. This is problematic, since ZGC has a requirement that we never perform load barriers while running the relocation code. If we do, we might end up performing other reloctions from the the relocation code, and in some cases that causes dead locks.
> 
> I propose that JFR doesn't walk the continuations when sending events. An alternative could be to limit this to ZGC, but I'd like to get some feedback around that from JFR / Loom devs.
> 
> We've been testing this patch in the Generational ZGC repository.

FYI: I reran testing to reproduce this deadlock and hit an assert instead. The assert happens because we trigger stack walking on a frame form the stack watermark processing:

#  assert(is_stack_watermark_processing_started(thread != nullptr ? thread : JavaThread::current())) failed: Not processed


V  [libjvm.dylib+0x563c48]  report_vm_error(char const*, int, char const*, char const*, ...)+0x80
V  [libjvm.dylib+0x4f055c]  ContinuationEntry::cont_oop(JavaThread const*) const+0x124
V  [libjvm.dylib+0x51e850]  Continuation::top_frame(frame const&, RegisterMap*)+0x128
V  [libjvm.dylib+0x90a9c4]  JfrVframeStream::next_vframe()+0xdc
V  [libjvm.dylib+0x90b168]  JfrStackTrace::record(JavaThread*, frame const&, int)+0x30c
V  [libjvm.dylib+0x90b348]  JfrStackTrace::record(JavaThread*, int)+0xbc
V  [libjvm.dylib+0x90c0d4]  JfrStackTraceRepository::record(JavaThread*, int, JfrStackFrame*, unsigned int)+0x38
V  [libjvm.dylib+0x110ab74]  JfrEvent<EventZPageAllocation>::write_event()+0x8c
V  [libjvm.dylib+0x1108a6c]  EventZPageAllocation::commit(unsigned long long, unsigned long long, unsigned long long, unsigned long long, unsigned int, bool)+0x174
V  [libjvm.dylib+0x1107134]  ZPageAllocator::alloc_page(unsigned char, unsigned long, ZAllocationFlags)+0x1c4
V  [libjvm.dylib+0x10e3eb8]  ZHeap::alloc_page(unsigned char, unsigned long, ZAllocationFlags)+0x1c
V  [libjvm.dylib+0x1105004]  ZObjectAllocator::alloc_page(unsigned char, unsigned long, ZAllocationFlags)+0x6c
V  [libjvm.dylib+0x1105300]  ZObjectAllocator::alloc_object_in_shared_page(ZPage**, unsigned char, unsigned long, unsigned long, ZAllocationFlags)+0x160
V  [libjvm.dylib+0x110591c]  ZObjectAllocator::alloc_object_for_relocation(ZPageTable const*, unsigned long)+0x28
V  [libjvm.dylib+0x111451c]  ZRelocate::relocate_object(ZForwarding*, unsigned long) const+0x1b4
V  [libjvm.dylib+0x5a1030]  oop ZBarrier::barrier<&(ZBarrier::is_good_or_null_fast_path(unsigned long)), &(ZBarrier::load_barrier_on_oop_slow_path(unsigned long))>(oop volatile*, oop)+0xa0
V  [libjvm.dylib+0xf48a40]  ZBarrier::load_barrier_on_oop_field(oop volatile*)+0x88
V  [libjvm.dylib+0x10d05a4]  ZLoadBarrierOopClosure::do_oop(oop*)+0x18
V  [libjvm.dylib+0x7bc81c]  HandleArea::oops_do(OopClosure*)+0xa0
V  [libjvm.dylib+0x89b834]  JavaThread::oops_do_no_frames(OopClosure*, CodeBlobClosure*)+0x64
V  [libjvm.dylib+0x111d4f4]  ZStackWatermark::start_processing_impl(void*)+0xb0
V  [libjvm.dylib+0xef5aa4]  StackWatermark::on_safepoint()+0x6c
V  [libjvm.dylib+0xe8c578]  SafepointMechanism::process(JavaThread*, bool, bool)+0xa0
V  [libjvm.dylib+0x86bfd0]  JavaCallWrapper::JavaCallWrapper(methodHandle const&, Handle, JavaValue*, JavaThread*)+0x174
V  [libjvm.dylib+0x86d65c]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x2dc
V  [libjvm.dylib+0x86cecc]  JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0xd0
V  [libjvm.dylib+0xef8ae4]  LiveFrameStream::create_primitive_slot_instance(StackValueCollection*, int, BasicType, JavaThread*)+0x200
V  [libjvm.dylib+0xef8d70]  LiveFrameStream::values_to_object_array(StackValueCollection*, JavaThread*)+0x1b4
V  [libjvm.dylib+0xef80e8]  LiveFrameStream::fill_live_stackframe(Handle, methodHandle const&, JavaThread*)+0x144
V  [libjvm.dylib+0xef7f84]  LiveFrameStream::fill_frame(int, objArrayHandle, methodHandle const&, JavaThread*)+0x1b8
V  [libjvm.dylib+0xef79bc]  StackWalk::fill_in_frames(long, BaseFrameStream&, int, int, objArrayHandle, int&, JavaThread*)+0x64c
V  [libjvm.dylib+0xef9f20]  StackWalk::fetchNextBatch(Handle, long, long, int, int, objArrayHandle, JavaThread*)+0x2d0
V  [libjvm.dylib+0x9a41b0]  JVM_MoreStackWalk+0x420
J 1762  java.lang.StackStreamFactory$AbstractStackWalker.fetchStackFrames(JJII[Ljava/lang/Object;)I java.base at 21-internal (0 bytes) @ 0x0000000113f7aa78 [0x0000000113f7a9c0+0x00000000000000b8]

-------------

PR: https://git.openjdk.org/jdk/pull/11586

From lkorinth at openjdk.org  Fri Dec  9 16:01:32 2022
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 Dec 2022 16:01:32 GMT
Subject: RFR: 8296401: ConcurrentHashTable::bulk_delete might miss to
 delete some objects [v4]
In-Reply-To: <rWw3Hb1baG5eslMgFnOdEP1Q4avhfYc3uTpjdB9DaP0=.23f34ff0-eff9-421b-9e70-7f119fd90e5d@github.com>
References: <rWw3Hb1baG5eslMgFnOdEP1Q4avhfYc3uTpjdB9DaP0=.23f34ff0-eff9-421b-9e70-7f119fd90e5d@github.com>
Message-ID: <6ZUCgz2b71EEVugCGQvcOmTxVMv9QWUHqcxJ7P5bebc=.62696dc9-962c-427f-b9f6-6919ba3186c6@github.com>

> ConcurrentHashTable::bulk_delete might miss to delete some objects if a bucket has more than 256 entries. Current uses of ConcurrentHashTable are not harmed by this behaviour. 
> 
> I modified gtest:ConcurrentHashTable to detect the problem (first commit), and fixed the problem in the code (second commit).
> 
> Tests passes tier1-3.

Leo Korinth has updated the pull request incrementally with two additional commits since the last revision:

 - renam stack limit, and add comments
 - Make ndel a reference to a pointer so that we can poison it. Also fix
   POISON_PTR to be of correct type (the pointer is const, not the memory
   pointed to).

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10983/files
  - new: https://git.openjdk.org/jdk/pull/10983/files/1292acbf..da74384f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10983&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10983&range=02-03

  Stats: 20 lines in 2 files changed: 9 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/10983.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10983/head:pull/10983

PR: https://git.openjdk.org/jdk/pull/10983

From coleenp at openjdk.org  Fri Dec  9 16:23:06 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 9 Dec 2022 16:23:06 GMT
Subject: [jdk20] RFR: 8298084: Memory leak in
 Method::build_profiling_method_data
Message-ID: <C9g5yB0uAHEc3BUu8JImdl9hOJUqFeDosqrIJWtYOlk=.7b3aea19-771a-4b9d-af5f-2716a2bac11a@github.com>

This change fixes the MethodData leak by calling the destructor in both the release_C_heap_structures conditionally and by calling the MethodData destructor in the MetadataFactory::free_metadata method.
Thanks to @jcking for working on the patch and discussion.
Tested with tier1-4.

-------------

Commit messages:
 - 8298084: Memory leak in Method::build_profiling_method_data

Changes: https://git.openjdk.org/jdk20/pull/13/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=13&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298084
  Stats: 35 lines in 6 files changed: 22 ins; 1 del; 12 mod
  Patch: https://git.openjdk.org/jdk20/pull/13.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/13/head:pull/13

PR: https://git.openjdk.org/jdk20/pull/13

From stuefe at openjdk.org  Fri Dec  9 17:46:56 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 9 Dec 2022 17:46:56 GMT
Subject: RFR: JDK-8298298: NMT: count deltas are printed with 32-bit signed
 size [v7]
In-Reply-To: <lgnue-mVLZzbnPszx5i9IWBezjBiNFfCNsk0Pr0zrNE=.aa69188f-8e3d-473c-bbc0-15a9d937f23e@github.com>
References: <ZbO2OJmcF2KfCodEuccCdLaT9uqDahRmqn8d3juth5A=.f5c5704b-0a92-4307-b5cd-b37516140eaa@github.com>
 <lgnue-mVLZzbnPszx5i9IWBezjBiNFfCNsk0Pr0zrNE=.aa69188f-8e3d-473c-bbc0-15a9d937f23e@github.com>
Message-ID: <ks_g9beg2yFIq_AYSDWJAAoslEC7-dCoYRGJg7T59gc=.c068084e-5972-4476-bd59-145af6d84c1e@github.com>

On Fri, 9 Dec 2022 13:29:47 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Deltas for counts in NMT differential reports are shown as signed int, restricting them to +-2g. These counts are number of malloc blocks, or number of classes, or number of threads. In all cases number of physically existing somethings.
>> 
>> On large 64-bit machines they can conceivably overflow. Well, at least the malloc block counters. Granted, mallocing even just >2g number of 1 byte blocks costs about 40-50GB due to overhead in libc and NMT (on glibc). But it is conceivable.
>> 
>> Patch changes delta printing from int to ssize_t.
>> 
>> Note that I don't worry about overflowing SSIZE_MIN or SSIZE_MAX here. That would be ridiculous: we just cannot have that many physically existing things. Not on 64bit, not even on 32-bit where ssize_t is int, since in both cases the address space would be the limit. So, if the counters are that large, we have a different problem (probably counter overflow), and so we assert, resp. in release, ignore it.
>> 
>> Note we have the same problem with diff sizes. I expect [8281213](https://bugs.openjdk.org/browse/JDK-8281213) to fix that.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Provide INT64_PLUS_FORMAT"
>   
>   This reverts commit 8a124873e09cf1e229228103c3dad622b0e913f9.

All tests are good.

-------------

PR: https://git.openjdk.org/jdk/pull/11568

From stuefe at openjdk.org  Fri Dec  9 17:50:56 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 9 Dec 2022 17:50:56 GMT
Subject: Integrated: JDK-8298298: NMT: count deltas are printed with 32-bit
 signed size
In-Reply-To: <ZbO2OJmcF2KfCodEuccCdLaT9uqDahRmqn8d3juth5A=.f5c5704b-0a92-4307-b5cd-b37516140eaa@github.com>
References: <ZbO2OJmcF2KfCodEuccCdLaT9uqDahRmqn8d3juth5A=.f5c5704b-0a92-4307-b5cd-b37516140eaa@github.com>
Message-ID: <OvQG-vph-QuitaAf45n7WDvmMHEyKaamFvQjgVr1JX4=.bc67745c-1d43-4a40-8ff0-ab186957a075@github.com>

On Wed, 7 Dec 2022 17:10:18 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Deltas for counts in NMT differential reports are shown as signed int, restricting them to +-2g. These counts are number of malloc blocks, or number of classes, or number of threads. In all cases number of physically existing somethings.
> 
> On large 64-bit machines they can conceivably overflow. Well, at least the malloc block counters. Granted, mallocing even just >2g number of 1 byte blocks costs about 40-50GB due to overhead in libc and NMT (on glibc). But it is conceivable.
> 
> Patch changes delta printing from int to ssize_t.
> 
> Note that I don't worry about overflowing SSIZE_MIN or SSIZE_MAX here. That would be ridiculous: we just cannot have that many physically existing things. Not on 64bit, not even on 32-bit where ssize_t is int, since in both cases the address space would be the limit. So, if the counters are that large, we have a different problem (probably counter overflow), and so we assert, resp. in release, ignore it.
> 
> Note we have the same problem with diff sizes. I expect [8281213](https://bugs.openjdk.org/browse/JDK-8281213) to fix that.

This pull request has now been integrated.

Changeset: f729f5b6
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f729f5b6d01b0d3a0ee21f50199ca30935c8237a
Stats:     49 lines in 4 files changed: 34 ins; 1 del; 14 mod

8298298: NMT: count deltas are printed with 32-bit signed size

Reviewed-by: shade, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/11568

From lbourges at openjdk.org  Fri Dec  9 17:57:36 2022
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Fri, 9 Dec 2022 17:57:36 GMT
Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v19]
In-Reply-To: <W8Ac5RQQcrQmv0Z_dU-lwhu1ny1MjgGq7xvnObMFTlU=.c4eeee8b-535e-4394-99db-10a7918e8733@github.com>
References: <fWd_NIunUhDXwy8uZSno90GC-PM8pFCey-pAMxxO0rI=.0fede0e4-1438-4321-bc8d-d11565389cae@github.com>
 <W8Ac5RQQcrQmv0Z_dU-lwhu1ny1MjgGq7xvnObMFTlU=.c4eeee8b-535e-4394-99db-10a7918e8733@github.com>
Message-ID: <ZNMA7VkpPAMRNRlblkKI8VObwPEbwn-yHdwctV3SyDA=.7ea85145-1f37-4120-851d-bbc3d1e35332@github.com>

On Thu, 8 Dec 2022 19:41:16 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> May I have this update reviewed?
>> 
>> The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure.  The build could pass if warnings are disabled for codes that use sprintf method.  For the long run, the sprintf could be replaced with snprintf.  This patch is trying to check if snprintf could be used.
>> 
>> Thanks,
>> Xuelei
>
> Xue-Lei Andrew Fan 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 24 additional commits since the last revision:
> 
>  - adlc update per review
>  - Merge
>  - update on review feedback
>  - comment for snprintf_checked
>  - use checked snprintf for adlc
>  - use checked snprintf
>  - no check on adlc
>  - revert use of assert
>  - extra sizeof typo
>  - more size_t updare for windows build
>  - ... and 14 more: https://git.openjdk.org/jdk/compare/2309602b...49bb58fd

LGTM, build on macos 13 + xcode 14.1 (x64): OK

I run successfully few applications with built jdk image...


Configuration summary:
* Name:           macosx-x86_64-server-release
* Debug level:    release
* HS debug level: product
* JVM variants:   server
* JVM features:   server: 'cds compiler1 compiler2 dtrace epsilongc g1gc jfr jni-check jvmci jvmti management parallelgc serialgc services shenandoahgc vm-structs zgc' 
* OpenJDK target: OS: macosx, CPU architecture: x86, address length: 64
* Version string: 20-internal-adhoc.jmmc.jdk-gh (20-internal)
* Source date:    1670605929 (2022-12-09T17:12:09Z)

Tools summary:
* Boot JDK:       openjdk version "20-ea" 2023-03-21 OpenJDK Runtime Environment (build 20-ea+26-2022) OpenJDK 64-Bit Server VM (build 20-ea+26-2022, mixed mode, sharing) (at /Users/jmmc/apps/jdk-20.jdk/Contents/Home)
* Toolchain:      clang (clang/LLVM from Xcode 14.1)
* Sysroot:        /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.0.sdk
* C Compiler:     Version 14.0.0 (at /usr/bin/clang)
* C++ Compiler:   Version 14.0.0 (at /usr/bin/clang++)

-------------

PR: https://git.openjdk.org/jdk/pull/11115

From jwilhelm at openjdk.org  Fri Dec  9 18:54:02 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Fri, 9 Dec 2022 18:54:02 GMT
Subject: RFR: Merge jdk20
Message-ID: <623yCPD6mDuZDBu16Bw0mumoJwDQvMbOyhM6baxvAME=.a307baef-104b-4790-9ef1-454a44400953@github.com>

Forwardport JDK 20 -> JDK 21

-------------

Commit messages:
 - Merge
 - 8298225: [AIX] Disable PPC64LE continuations on AIX
 - 8298463: tools/javac/modules/EdgeCases.java fails on Windows after JDK-8297988
 - 8298353: C2 fails with assert(opaq->outcnt() == 1 && opaq->in(1) == limit) failed
 - 8298340: java/net/httpclient/CancelRequestTest.java fails with AssertionError: Found some subscribers for testPostInterrupt
 - 8298455: JFR: Add logging to TestClose.java
 - 8297988: NPE in JavacTypes.getOverriddenMethods from doclint
 - 8298402: ProblemList javax/swing/JFileChooser/4847375/bug4847375.java on windows-x64

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=11614&range=00.0
 - jdk20: https://webrevs.openjdk.org/?repo=jdk&pr=11614&range=00.1

Changes: https://git.openjdk.org/jdk/pull/11614/files
  Stats: 262 lines in 13 files changed: 250 ins; 1 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/11614.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11614/head:pull/11614

PR: https://git.openjdk.org/jdk/pull/11614

From lkorinth at openjdk.org  Fri Dec  9 19:05:24 2022
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 Dec 2022 19:05:24 GMT
Subject: RFR: 8296401: ConcurrentHashTable::bulk_delete might miss to
 delete some objects [v4]
In-Reply-To: <6ZUCgz2b71EEVugCGQvcOmTxVMv9QWUHqcxJ7P5bebc=.62696dc9-962c-427f-b9f6-6919ba3186c6@github.com>
References: <rWw3Hb1baG5eslMgFnOdEP1Q4avhfYc3uTpjdB9DaP0=.23f34ff0-eff9-421b-9e70-7f119fd90e5d@github.com>
 <6ZUCgz2b71EEVugCGQvcOmTxVMv9QWUHqcxJ7P5bebc=.62696dc9-962c-427f-b9f6-6919ba3186c6@github.com>
Message-ID: <7YMv3T-aW0nEqqUvKfe5BsI7z2qhyHKCMA3MvbA5qnY=.ede8f6c2-8670-4e22-b5d8-12161474707b@github.com>

On Fri, 9 Dec 2022 16:01:32 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> ConcurrentHashTable::bulk_delete might miss to delete some objects if a bucket has more than 256 entries. Current uses of ConcurrentHashTable are not harmed by this behaviour. 
>> 
>> I modified gtest:ConcurrentHashTable to detect the problem (first commit), and fixed the problem in the code (second commit).
>> 
>> Tests passes tier1-3.
>
> Leo Korinth has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - renam stack limit, and add comments
>  - Make ndel a reference to a pointer so that we can poison it. Also fix
>    POISON_PTR to be of correct type (the pointer is const, not the memory
>    pointed to).

I will fix the build issue.

-------------

PR: https://git.openjdk.org/jdk/pull/10983

From lkorinth at openjdk.org  Fri Dec  9 19:54:48 2022
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 Dec 2022 19:54:48 GMT
Subject: RFR: 8296401: ConcurrentHashTable::bulk_delete might miss to
 delete some objects [v5]
In-Reply-To: <rWw3Hb1baG5eslMgFnOdEP1Q4avhfYc3uTpjdB9DaP0=.23f34ff0-eff9-421b-9e70-7f119fd90e5d@github.com>
References: <rWw3Hb1baG5eslMgFnOdEP1Q4avhfYc3uTpjdB9DaP0=.23f34ff0-eff9-421b-9e70-7f119fd90e5d@github.com>
Message-ID: <3Fnpqamf7GB_EaNVYVO-yuykUOzwhOOCOf_sIBE4334=.7951828c-1e7f-499c-883c-a2f239df28c0@github.com>

> ConcurrentHashTable::bulk_delete might miss to delete some objects if a bucket has more than 256 entries. Current uses of ConcurrentHashTable are not harmed by this behaviour. 
> 
> I modified gtest:ConcurrentHashTable to detect the problem (first commit), and fixed the problem in the code (second commit).
> 
> Tests passes tier1-3.

Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:

  GrowableArray is indexed by int :-(

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10983/files
  - new: https://git.openjdk.org/jdk/pull/10983/files/da74384f..9cae9ddb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10983&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10983&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10983.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10983/head:pull/10983

PR: https://git.openjdk.org/jdk/pull/10983

From jwilhelm at openjdk.org  Fri Dec  9 22:03:09 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Fri, 9 Dec 2022 22:03:09 GMT
Subject: Integrated: Merge jdk20
In-Reply-To: <623yCPD6mDuZDBu16Bw0mumoJwDQvMbOyhM6baxvAME=.a307baef-104b-4790-9ef1-454a44400953@github.com>
References: <623yCPD6mDuZDBu16Bw0mumoJwDQvMbOyhM6baxvAME=.a307baef-104b-4790-9ef1-454a44400953@github.com>
Message-ID: <7u7OtmjFU9bcXtf2gL0ig1tG-_zgP0g0R__V68W7MLo=.6a2e0eef-313c-4df5-8769-dcab1961b6ac@github.com>

On Fri, 9 Dec 2022 18:45:40 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 20 -> JDK 21

This pull request has now been integrated.

Changeset: 715bf704
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/715bf7045968e341182e61343651f464a437f83f
Stats:     262 lines in 13 files changed: 250 ins; 1 del; 11 mod

Merge

-------------

PR: https://git.openjdk.org/jdk/pull/11614

From xuelei at openjdk.org  Fri Dec  9 22:41:54 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 9 Dec 2022 22:41:54 GMT
Subject: Integrated: 8296812: sprintf is deprecated in Xcode 14
In-Reply-To: <fWd_NIunUhDXwy8uZSno90GC-PM8pFCey-pAMxxO0rI=.0fede0e4-1438-4321-bc8d-d11565389cae@github.com>
References: <fWd_NIunUhDXwy8uZSno90GC-PM8pFCey-pAMxxO0rI=.0fede0e4-1438-4321-bc8d-d11565389cae@github.com>
Message-ID: <ao641OUbrIlOJ6DuQbB95Oh5lVN1V5lol1IE60A3Rr8=.6658bc07-ee13-4981-bc80-9990279ae6c8@github.com>

On Fri, 11 Nov 2022 22:41:19 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have this update reviewed?
> 
> The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure.  The build could pass if warnings are disabled for codes that use sprintf method.  For the long run, the sprintf could be replaced with snprintf.  This patch is trying to check if snprintf could be used.
> 
> Thanks,
> Xuelei

This pull request has now been integrated.

Changeset: 478ef389
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/478ef389dc3767edfbe21d10a7f7f1522c648c2e
Stats:     145 lines in 26 files changed: 45 ins; 4 del; 96 mod

8296812: sprintf is deprecated in Xcode 14

Reviewed-by: stuefe, prr, kbarrett, lucy

-------------

PR: https://git.openjdk.org/jdk/pull/11115

From kbarrett at openjdk.org  Fri Dec  9 23:20:04 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 9 Dec 2022 23:20:04 GMT
Subject: RFR: 8293824: gc/whitebox/TestConcMarkCycleWB.java failed
 "RuntimeException: assertTrue: expected true, was false" [v2]
In-Reply-To: <EXP4eCMltTG3jrqBvZdydUEb3z3aOGMSt8jNkSFEfxg=.7c7c292f-3eba-4278-b278-02a9ffdd9ffa@github.com>
References: <74AnEqLugaEU80XMNm8edtWBmK8gOFMirnZT1rdj1jI=.6ab039c0-3db5-4336-9aa7-867166b79cda@github.com>
 <dM4t6tEt_ECKHylcGy7v2lL8FOXa1j336ycPFt07Jnc=.1b984fe9-d268-4384-85d9-0984fff815a6@github.com>
 <EXP4eCMltTG3jrqBvZdydUEb3z3aOGMSt8jNkSFEfxg=.7c7c292f-3eba-4278-b278-02a9ffdd9ffa@github.com>
Message-ID: <4WLjFkvG6AOhio51nAx-MHe7pTEquJeK0Xh8ybp3UBY=.0305e33f-6e0a-4510-9af4-daf46168a1cf@github.com>

On Tue, 6 Dec 2022 19:32:13 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
>> 
>>  - use new whitebox api for running conc gc
>>  - Merge branch 'master' into test-concmark
>>  - copyrights
>>  - remove WB.g1StartConcMarkCyle
>>  - update tests
>>  - add utility GC breakpoint functions
>>  - add G1ConcurrentMark::completed_mark_cycles() and whitebox access
>
> test/hotspot/jtreg/gc/stress/TestStressRSetCoarsening.java line 296:
> 
>> 294:                     // Number of references went down.
>> 295:                     // Need to provoke recalculation of RSet.
>> 296:                     WB.g1RunConcurrentGC(false);
> 
> probably use `WB.g1RunConcurrentGC();` overload for consistency with other calls

Suppression of detection of failure to complete a cycle here was intentional.
In some configurations (like with `-Xcomp`) in this stress test, a full GC may
occur during and abort the concurrent cycle. I saw this intermittently in
testing.

-------------

PR: https://git.openjdk.org/jdk/pull/11435

From kbarrett at openjdk.org  Fri Dec  9 23:27:07 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 9 Dec 2022 23:27:07 GMT
Subject: RFR: 8293824: gc/whitebox/TestConcMarkCycleWB.java failed
 "RuntimeException: assertTrue: expected true, was false" [v2]
In-Reply-To: <EXP4eCMltTG3jrqBvZdydUEb3z3aOGMSt8jNkSFEfxg=.7c7c292f-3eba-4278-b278-02a9ffdd9ffa@github.com>
References: <74AnEqLugaEU80XMNm8edtWBmK8gOFMirnZT1rdj1jI=.6ab039c0-3db5-4336-9aa7-867166b79cda@github.com>
 <dM4t6tEt_ECKHylcGy7v2lL8FOXa1j336ycPFt07Jnc=.1b984fe9-d268-4384-85d9-0984fff815a6@github.com>
 <EXP4eCMltTG3jrqBvZdydUEb3z3aOGMSt8jNkSFEfxg=.7c7c292f-3eba-4278-b278-02a9ffdd9ffa@github.com>
Message-ID: <zOOCKWJW2b4tZrAJj3MCHEXs0C7j_2yEe-3mGNQb4mg=.05bfe5a5-cca4-429c-95c3-6c443cf6da3a@github.com>

On Tue, 6 Dec 2022 19:33:42 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
>> 
>>  - use new whitebox api for running conc gc
>>  - Merge branch 'master' into test-concmark
>>  - copyrights
>>  - remove WB.g1StartConcMarkCyle
>>  - update tests
>>  - add utility GC breakpoint functions
>>  - add G1ConcurrentMark::completed_mark_cycles() and whitebox access
>
> test/hotspot/jtreg/gc/g1/humongousObjects/objectGraphTest/GCTokens.java line 36:
> 
>> 34:     public static final String WB_INITIATED_YOUNG_GC = "Young (Normal) (WhiteBox Initiated Young GC)";
>> 35:     public static final String WB_INITIATED_MIXED_GC = "Young (Mixed) (WhiteBox Initiated Young GC)";
>> 36:     public static final String WB_INITIATED_CMC = "WhiteBox Initiated Run to Breakpoint";
> 
> `WB_INITIATED_CMC = "WhiteBox Initiated Run to Concurrent GC Breakpoint"; ` as we indicate below that `String CMC = "Concurrent Mark)"`

Sorry, I don't understand the question/comment?  The change to the string
reflects what is logged by the VM now that we're using GC breakpoints to
control the collection.  The logging being matched with CMC didn't change.

-------------

PR: https://git.openjdk.org/jdk/pull/11435

From kbarrett at openjdk.org  Sat Dec 10 16:34:03 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 10 Dec 2022 16:34:03 GMT
Subject: [jdk20] RFR: 8296955: Kitchensink.java failed with
 "double free or corruption (!prev): <addr>"
In-Reply-To: <-rew__nvw1aQv6-lfTVkU-DGA_rjP4JypTsIj2ozblI=.21be566f-c364-4537-86b6-35e7d12e3e4e@github.com>
References: <-rew__nvw1aQv6-lfTVkU-DGA_rjP4JypTsIj2ozblI=.21be566f-c364-4537-86b6-35e7d12e3e4e@github.com>
Message-ID: <rqYi7166vpuLC2mBSn-CHvJG_bTROvw8LalGL7f2Vcs=.7ff38c80-91f4-4a92-80e6-a1a4e24b6a15@github.com>

On Fri, 9 Dec 2022 12:27:42 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Thanks to Kim for the diagnosis of this problem.  G1 cleans up nmethods in parallel threads during a safepoint and may post or queue unload events to be posted.  The event posting creates jmethodIDs.  The jmethodID code assumes that it's thread safe in a safepoint, which it is not.
> I removed this optimization, which isn't much of an optimization (did run some sanity performance tests) and is unsafe in the modern code.
> Tested with tier1-7, where tier5 found the original bug.

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/10

From eosterlund at openjdk.org  Sat Dec 10 17:09:03 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Sat, 10 Dec 2022 17:09:03 GMT
Subject: [jdk20] RFR: 8296955: Kitchensink.java failed with
 "double free or corruption (!prev): <addr>"
In-Reply-To: <-rew__nvw1aQv6-lfTVkU-DGA_rjP4JypTsIj2ozblI=.21be566f-c364-4537-86b6-35e7d12e3e4e@github.com>
References: <-rew__nvw1aQv6-lfTVkU-DGA_rjP4JypTsIj2ozblI=.21be566f-c364-4537-86b6-35e7d12e3e4e@github.com>
Message-ID: <mk-1syaVwSazbKWXOZ0xQVUoK8nxEsqheHvyl3XVzzs=.a34ec4f4-7c1e-45a3-b7d6-236bafb84c88@github.com>

On Fri, 9 Dec 2022 12:27:42 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Thanks to Kim for the diagnosis of this problem.  G1 cleans up nmethods in parallel threads during a safepoint and may post or queue unload events to be posted.  The event posting creates jmethodIDs.  The jmethodID code assumes that it's thread safe in a safepoint, which it is not.
> I removed this optimization, which isn't much of an optimization (did run some sanity performance tests) and is unsafe in the modern code.
> Tested with tier1-7, where tier5 found the original bug.

Looks good.

-------------

Marked as reviewed by eosterlund (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/10

From stuefe at openjdk.org  Sun Dec 11 08:11:51 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sun, 11 Dec 2022 08:11:51 GMT
Subject: RFR: JDK-8296360: Track native memory used by zlib via NMT
In-Reply-To: <WW7_ad6YUZQ26hrK4idngOcwkotxiJr1PAyfP29Lj64=.5779f834-b617-4295-b69e-c37c796f5268@github.com>
References: <WW7_ad6YUZQ26hrK4idngOcwkotxiJr1PAyfP29Lj64=.5779f834-b617-4295-b69e-c37c796f5268@github.com>
Message-ID: <xhsyZ2MDoNmiagKhpZ9NiuCJAmLn3e_taiKD-FrZvOM=.2f610488-8c37-4774-b89e-b9f3118b0348@github.com>

On Fri, 4 Nov 2022 14:35:00 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> This patch adds NMT tracking to the zlib.
> 
> *Please note: we currently discuss whether NMT can be expanded across the JDK in this ML discussion [1]. This PR depends on the outcome of that discussion and won't proceed unless greenlighted. But since [1] is stalled, I post the PR for RFR to get some feedback on the code itself and for people to try it out.*
> 
> NMT tracks hotspot native allocations but does not cover the JDK (apart from small exceptions). But the native memory
> footprint of JDK libraries can be very significant. Recently we had a customer whose zlib footprint went into the ~40GB range. We analyzed the problem with an in-house memory tracker, but things would have been a lot simpler using NMT.
> 
> This patch instruments the zlib via zalloc hooks, which is minimally invasive. It does not touch zlib sources, so it works with both the bundled zlib and system zlib. All the instrumentation happens in the JVM zlib wrapper.
> 
> 
> -         j.u.zip (deflate) (reserved=624, committed=624)
>                             (malloc=624 #3) 
>  
> -         j.u.zip (inflate) (reserved=221377904, committed=221377904)
>                             (malloc=221377904 #60877) 
>  
> -               Zip (other) (reserved=8163446896, committed=8163446896)
>                             (malloc=8163446896 #182622) 
> 
> 
> [1] https://mail.openjdk.org/pipermail/core-libs-dev/2022-November/096197.html

Withdrawing for now; let's see how our discussion goes.

-------------

PR: https://git.openjdk.org/jdk/pull/10988

From kbarrett at openjdk.org  Sun Dec 11 17:34:55 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 11 Dec 2022 17:34:55 GMT
Subject: [jdk20] RFR: 8298084: Memory leak in
 Method::build_profiling_method_data
In-Reply-To: <C9g5yB0uAHEc3BUu8JImdl9hOJUqFeDosqrIJWtYOlk=.7b3aea19-771a-4b9d-af5f-2716a2bac11a@github.com>
References: <C9g5yB0uAHEc3BUu8JImdl9hOJUqFeDosqrIJWtYOlk=.7b3aea19-771a-4b9d-af5f-2716a2bac11a@github.com>
Message-ID: <R6yAdAMtsv7vbpg136bsQfbgM3CUJBQ9IrzdGt6z_pg=.8dd35c45-374c-410f-9a20-555bf5f2c3d0@github.com>

On Fri, 9 Dec 2022 16:16:00 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change fixes the MethodData leak by calling the destructor in both the release_C_heap_structures conditionally and by calling the MethodData destructor in the MetadataFactory::free_metadata method.
> Thanks to @jcking for working on the patch and discussion.
> Tested with tier1-4.

Changes requested by kbarrett (Reviewer).

src/hotspot/share/memory/metadataFactory.hpp line 79:

> 77:       // T is a potentially const or volatile qualified pointer. Remove the pointer and any const
> 78:       // or volatile so we can call the destructor of the type T points to.
> 79:       using U = typename RemoveCV<typename RemovePointer<T>::type>::type;

Use `std::remove_pointer<T>` and `std::remove_cv<T>` from `<type_traits>` in
preference to our pre-C++11/14 workarounds. You can also avoid `typename` and
`::type` by using the "_t"-suffixed versions. So

using U = std::remove_cv_t<std::remove_pointer_t<T>>;

And "If requested" in the comment? That suggests some conditionalization, of
which there is none. Maybe something like "Most of the cleanup is done via
deallocate_contents, but some types require some additional cleanup via the
destructor."

-------------

PR: https://git.openjdk.org/jdk20/pull/13

From dholmes at openjdk.org  Mon Dec 12 00:12:33 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 12 Dec 2022 00:12:33 GMT
Subject: RFR: 8292674: ReportJNIFatalError should print all java frames
 [v4]
In-Reply-To: <zC7Sw1liRMkX_BMH0bm0hUGLBjPBjnYoOsuqMMrMjWE=.a67af3d0-8642-47d9-ab3a-cfe40f9e16d3@github.com>
References: <-ipNtt5PSZ2d7VUBSoduPyNwnW2GeN_y0Dcs95qI8HU=.c4771172-01dd-49ae-8f4a-9d5cbd6c6dad@github.com>
 <uUWb1njnLGXpTVPEx-n4QElmN9urKxquYk2n0TcaMVg=.221b1735-4325-4aae-91f5-2ba1b832ff58@github.com>
 <zC7Sw1liRMkX_BMH0bm0hUGLBjPBjnYoOsuqMMrMjWE=.a67af3d0-8642-47d9-ab3a-cfe40f9e16d3@github.com>
Message-ID: <7cks2rwv_i_Q_8Y7Wqoj-cuZ6x1l75Ke0aZ1jbq0kxQ=.d7a97d70-609f-4553-87dd-b4c8c30f6674@github.com>

On Fri, 9 Dec 2022 08:42:15 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> David Holmes 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 four additional commits since the last revision:
>> 
>>  - Merge branch 'master' into 8292674-ReportJNIFatalError-v2
>>  - Merge branch 'master' into 8292674-ReportJNIFatalError-v2
>>  - Changed RegisterMap to include process_frame and update, for object monitor examination.
>>    Updated stack printing for exception checks.
>>  - 8292674: ReportJNIFatalError should print all java frames
>
> Looks good, thanks!

Thanks for looking at this @robehn , but can you hit the approve button please :)

-------------

PR: https://git.openjdk.org/jdk/pull/11503

From dholmes at openjdk.org  Mon Dec 12 01:00:58 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 12 Dec 2022 01:00:58 GMT
Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v7]
In-Reply-To: <pRcbuNmrpRkRA8lOJfYlEVWo3W766EMs6Gw5raXbZPs=.66222c03-5a36-43be-a9c9-080d046d73d7@github.com>
References: <Dj9YfY10SLn8dR1Ez3kEQe4tXm1q5W1TS8_4r3gBUsY=.6c38825a-86e5-4575-a509-683786d242a6@github.com>
 <pRcbuNmrpRkRA8lOJfYlEVWo3W766EMs6Gw5raXbZPs=.66222c03-5a36-43be-a9c9-080d046d73d7@github.com>
Message-ID: <AYhCxPKMsfdFV8iiAy9oHn4vtW8qd5zJPEbJQb6qZBk=.70e1d24b-fdbd-4d62-8319-073247eae8b6@github.com>

On Thu, 8 Dec 2022 16:56:40 GMT, Afshin Zafari <duke at openjdk.org> wrote:

>> test of tier1-5 passed.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8292741: Convert JvmtiTagMapTable to ResourceHashtable

I'm still seeing a few oddities in the code. Overall it is very hard in the PR to get a good sense of the conversion process, but it seems fairly reasonable. It is hard to see how all the different parts of the APIs connect e.g. to understand why some methods are returning boolean values that are always true.

Also please do not force-push.

src/hotspot/share/prims/jvmtiTagMap.cpp line 1262:

> 1260:   // and record the reference and tag value.
> 1261:   //
> 1262:   bool do_entry(JvmtiTagMapKey& key, jlong& value) {

I still see no point in this method returning a bool when it only ever returns true.

src/hotspot/share/prims/jvmtiTagMapTable.cpp line 114:

> 112:   JvmtiTagMapKey new_entry(obj);
> 113:   bool is_updated = _table.put(new_entry, tag) == false;
> 114:   assert(is_updated, "should be updated and not added");

This API is confusing. You have `add` and `replace` but in product mode an `add` can `replace` and a `replace` can `add`. It isn't clear if these should be allowed rare conditions or fatal errors.

-------------

PR: https://git.openjdk.org/jdk/pull/11288

From dholmes at openjdk.org  Mon Dec 12 01:00:58 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 12 Dec 2022 01:00:58 GMT
Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v7]
In-Reply-To: <m0UnY-x47SAtCGdPlMcUKfxd0lWRqURPb3u0wKNCT3w=.97f998ef-48f0-4b4f-a144-822ebcf7dc98@github.com>
References: <Dj9YfY10SLn8dR1Ez3kEQe4tXm1q5W1TS8_4r3gBUsY=.6c38825a-86e5-4575-a509-683786d242a6@github.com>
 <m0UnY-x47SAtCGdPlMcUKfxd0lWRqURPb3u0wKNCT3w=.97f998ef-48f0-4b4f-a144-822ebcf7dc98@github.com>
Message-ID: <0pbB8d_Ihehf2KgV16rg4dh7cLy_eeZE2lGwovLEiBs=.4a05bd73-4252-449a-ae46-448fda30e2e6@github.com>

On Mon, 28 Nov 2022 01:23:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8292741: Convert JvmtiTagMapTable to ResourceHashtable
>
> src/hotspot/share/prims/jvmtiTagMapTable.cpp line 88:
> 
>> 86: }
>> 87: 
>> 88: JvmtiTagMapTable::~JvmtiTagMapTable() {
> 
> Is this the only use of `clear`? If so we can just inline its code here and remove it from the API.

This issue is not resolved.

-------------

PR: https://git.openjdk.org/jdk/pull/11288

From dholmes at openjdk.org  Mon Dec 12 01:00:58 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 12 Dec 2022 01:00:58 GMT
Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v7]
In-Reply-To: <c4ophxMSfP2waXPjUz3x4N57crZdQQb-d_xsOIfGmCw=.0de5f1fa-d697-4ca2-aa7a-3c5a4e030236@github.com>
References: <Dj9YfY10SLn8dR1Ez3kEQe4tXm1q5W1TS8_4r3gBUsY=.6c38825a-86e5-4575-a509-683786d242a6@github.com>
 <m0UnY-x47SAtCGdPlMcUKfxd0lWRqURPb3u0wKNCT3w=.97f998ef-48f0-4b4f-a144-822ebcf7dc98@github.com>
 <WC0j16HlKWRzgKhC9xjs_ZQr-42Bk7_cMOOCK3rY-yo=.c5f6e693-7d51-4277-86ab-ad250967041c@github.com>
 <c4ophxMSfP2waXPjUz3x4N57crZdQQb-d_xsOIfGmCw=.0de5f1fa-d697-4ca2-aa7a-3c5a4e030236@github.com>
Message-ID: <hwUPLRsR8KBXbUhay4GFQD5xFkKET08WIhlXD7XbQNM=.83b07297-8e80-4210-baff-be5538297932@github.com>

On Mon, 28 Nov 2022 22:17:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> ResourceHashTable::put() returns true if the Key,Value is added, false if the Value is updated.
>
> But this doesn't do that, so ??

This issue is not resolved.

-------------

PR: https://git.openjdk.org/jdk/pull/11288

From dholmes at openjdk.org  Mon Dec 12 01:19:52 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 12 Dec 2022 01:19:52 GMT
Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC
In-Reply-To: <BOJ4yH2GtNWXDVXMKwPw9Ic359dnBK8Sb9tDw3a5Qmc=.197acbb0-3ed6-418f-8bcf-70ef4b67de5e@github.com>
References: <BOJ4yH2GtNWXDVXMKwPw9Ic359dnBK8Sb9tDw3a5Qmc=.197acbb0-3ed6-418f-8bcf-70ef4b67de5e@github.com>
Message-ID: <asJ1PrVGE8XkRF9_ubdojPmPzi8uijPEuhrIkhajszI=.e5d1e5a8-f912-4285-8a6d-976d84e88e6b@github.com>

On Thu, 8 Dec 2022 11:23:57 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The JfrVFrameStream is used while generating stack traces for events. One of the events are the ZPage allocation event. This event is sometimes sent when ZGC is relocating. The current implementation of JfrVFrameStream uses WalkContinuation::include, which causes JFR to walk the continuation and perform GC barriers. This is problematic, since ZGC has a requirement that we never perform load barriers while running the relocation code. If we do, we might end up performing other reloctions from the the relocation code, and in some cases that causes dead locks.
> 
> I propose that JFR doesn't walk the continuations when sending events. An alternative could be to limit this to ZGC, but I'd like to get some feedback around that from JFR / Loom devs.
> 
> We've been testing this patch in the Generational ZGC repository.

It doesn't seem reasonable to me to truncate VT stacks in all JFR events just because there is an issue with one ZGC event.

Any events triggered from the GC internals could potentially try to do things with Java objects that are not permitted given the current state of the GC. This seems like a general problem that the JFR event mechanism needs to resolve.

-------------

PR: https://git.openjdk.org/jdk/pull/11586

From jcking at openjdk.org  Mon Dec 12 03:45:48 2022
From: jcking at openjdk.org (Justin King)
Date: Mon, 12 Dec 2022 03:45:48 GMT
Subject: RFR: JDK-8298084: Memory leak in
 Method::build_profiling_method_data [v6]
In-Reply-To: <-sH5M8TqDC48uXPMfVjHBVTGsuVLBMnCHfp2ji0TTSQ=.54357ef4-5532-42e0-81b0-8fc36ce5f5b1@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
 <wS4niiWCO0Q8K0kjLCtooIMF_KtVPO2_e3FgbVSP8W8=.5f798928-dc87-41e6-a856-89f9a633944a@github.com>
 <-sH5M8TqDC48uXPMfVjHBVTGsuVLBMnCHfp2ji0TTSQ=.54357ef4-5532-42e0-81b0-8fc36ce5f5b1@github.com>
Message-ID: <ZrIBruxww98u9YiWdDVlBXXIEpqVemSbnRvrpGKr0qY=.51fdfff3-87aa-4baa-beab-39e0f36b188c@github.com>

On Fri, 9 Dec 2022 12:24:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Justin King has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add comment to metaprogramming usage
>>   
>>   Signed-off-by: Justin King <jcking at google.com>
>
> I want to take over this fix and I will rebase it to JDK 20.  Sorry for being so late to remembering how this code works.  The LSan tool sounds great.  I'll pay attention to that now.

Withdrawing in favor of @coleenp pull requests.

-------------

PR: https://git.openjdk.org/jdk/pull/11526

From jcking at openjdk.org  Mon Dec 12 03:45:49 2022
From: jcking at openjdk.org (Justin King)
Date: Mon, 12 Dec 2022 03:45:49 GMT
Subject: Withdrawn: JDK-8298084: Memory leak in
 Method::build_profiling_method_data
In-Reply-To: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
References: <sGikcSUuR2gJkmoHpNFGXKJhwP35RoQ-895pmTgNb74=.3e4adb8f-bd81-47c1-997e-c44a0df39b73@github.com>
Message-ID: <G1g0rzZsi5PpK5v_XgPvsIatUnDE1S1AkowaaUyfwE8=.efefb610-dd1c-4131-b583-d5eda7e33a37@github.com>

On Tue, 6 Dec 2022 06:13:23 GMT, Justin King <jcking at openjdk.org> wrote:

> Resolve memory leak related to `MethodData::_extra_data_lock` in `Method::build_profiling_method_data` by calling `MethodData::~MethodData()`.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/11526

From stefank at openjdk.org  Mon Dec 12 09:04:52 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 12 Dec 2022 09:04:52 GMT
Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC
In-Reply-To: <asJ1PrVGE8XkRF9_ubdojPmPzi8uijPEuhrIkhajszI=.e5d1e5a8-f912-4285-8a6d-976d84e88e6b@github.com>
References: <BOJ4yH2GtNWXDVXMKwPw9Ic359dnBK8Sb9tDw3a5Qmc=.197acbb0-3ed6-418f-8bcf-70ef4b67de5e@github.com>
 <asJ1PrVGE8XkRF9_ubdojPmPzi8uijPEuhrIkhajszI=.e5d1e5a8-f912-4285-8a6d-976d84e88e6b@github.com>
Message-ID: <ky9MpV9FZGaGDMCon2b7rMQjtnyFL9C3D7SRnOxw4vM=.b00fa010-233c-4763-9b30-5ec6db68af00@github.com>

On Mon, 12 Dec 2022 01:16:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Any events triggered from the GC internals could potentially try to do things with Java objects that are not permitted given the current state of the GC. This seems like a general problem that the JFR event mechanism needs to resolve.

FWIW, we have had other problems when sending JFR events from GC internals. So far, the JFR team has found solutions to deal with those issues.

@pron @mgronlund @egahlin do you have a suggestion on how to move forward with this issue?

-------------

PR: https://git.openjdk.org/jdk/pull/11586

From iwalulya at openjdk.org  Mon Dec 12 09:36:50 2022
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 12 Dec 2022 09:36:50 GMT
Subject: RFR: 8293824: gc/whitebox/TestConcMarkCycleWB.java failed
 "RuntimeException: assertTrue: expected true, was false" [v2]
In-Reply-To: <zOOCKWJW2b4tZrAJj3MCHEXs0C7j_2yEe-3mGNQb4mg=.05bfe5a5-cca4-429c-95c3-6c443cf6da3a@github.com>
References: <74AnEqLugaEU80XMNm8edtWBmK8gOFMirnZT1rdj1jI=.6ab039c0-3db5-4336-9aa7-867166b79cda@github.com>
 <dM4t6tEt_ECKHylcGy7v2lL8FOXa1j336ycPFt07Jnc=.1b984fe9-d268-4384-85d9-0984fff815a6@github.com>
 <EXP4eCMltTG3jrqBvZdydUEb3z3aOGMSt8jNkSFEfxg=.7c7c292f-3eba-4278-b278-02a9ffdd9ffa@github.com>
 <zOOCKWJW2b4tZrAJj3MCHEXs0C7j_2yEe-3mGNQb4mg=.05bfe5a5-cca4-429c-95c3-6c443cf6da3a@github.com>
Message-ID: <E8L0OcmmrnwNRXOTxfnDWLZxsrIOatUDlgujbfVaSbM=.ab91bf26-acc8-4d01-bf4e-3a610a35cc22@github.com>

On Fri, 9 Dec 2022 23:24:25 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> test/hotspot/jtreg/gc/g1/humongousObjects/objectGraphTest/GCTokens.java line 36:
>> 
>>> 34:     public static final String WB_INITIATED_YOUNG_GC = "Young (Normal) (WhiteBox Initiated Young GC)";
>>> 35:     public static final String WB_INITIATED_MIXED_GC = "Young (Mixed) (WhiteBox Initiated Young GC)";
>>> 36:     public static final String WB_INITIATED_CMC = "WhiteBox Initiated Run to Breakpoint";
>> 
>> `WB_INITIATED_CMC = "WhiteBox Initiated Run to Concurrent GC Breakpoint"; ` as we indicate below that `String CMC = "Concurrent Mark)"`
>
> Sorry, I don't understand the question/comment?  The change to the string
> reflects what is logged by the VM now that we're using GC breakpoints to
> control the collection.  The logging being matched with CMC didn't change.

ok, then it is fine.

-------------

PR: https://git.openjdk.org/jdk/pull/11435

From sspitsyn at openjdk.org  Mon Dec 12 10:28:04 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 12 Dec 2022 10:28:04 GMT
Subject: [jdk20] RFR: 8296955: Kitchensink.java failed with
 "double free or corruption (!prev): <addr>"
In-Reply-To: <-rew__nvw1aQv6-lfTVkU-DGA_rjP4JypTsIj2ozblI=.21be566f-c364-4537-86b6-35e7d12e3e4e@github.com>
References: <-rew__nvw1aQv6-lfTVkU-DGA_rjP4JypTsIj2ozblI=.21be566f-c364-4537-86b6-35e7d12e3e4e@github.com>
Message-ID: <qO_EGAE9swEaCRwwjJazx6ZJBLfG2rtDLmZ2yem76js=.04b62fce-2642-44c1-9848-9784c53dc6c2@github.com>

On Fri, 9 Dec 2022 12:27:42 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Thanks to Kim for the diagnosis of this problem.  G1 cleans up nmethods in parallel threads during a safepoint and may post or queue unload events to be posted.  The event posting creates jmethodIDs.  The jmethodID code assumes that it's thread safe in a safepoint, which it is not.
> I removed this optimization, which isn't much of an optimization (did run some sanity performance tests) and is unsafe in the modern code.
> Tested with tier1-7, where tier5 found the original bug.

Looks good.
Thanks,
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/10

From ayang at openjdk.org  Mon Dec 12 11:20:01 2022
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 12 Dec 2022 11:20:01 GMT
Subject: RFR: 8297235: ZGC: assert(regs[i] != regs[j]) failed: Multiple
 uses of register: rax [v3]
In-Reply-To: <0fGmbCvEUHokqoFR0ndPwd7yA5I_SS-MlBneCPP3LqY=.c4b67306-e5bb-4af5-8875-adba9ea9d0f1@github.com>
References: <jYsSVWwRPyRKvs8HYIwp6Ar5Z0XISOwp1DM4A0AgdOQ=.378c74fb-a4e1-45a5-82b0-838c2fcba43a@github.com>
 <0fGmbCvEUHokqoFR0ndPwd7yA5I_SS-MlBneCPP3LqY=.c4b67306-e5bb-4af5-8875-adba9ea9d0f1@github.com>
Message-ID: <S5Uq9PD1taDCGC7Dseo1irrG8btl4C2O3gqhIhMo6B8=.9b5aabd1-1493-414e-bbbc-89cd1d123ab2@github.com>

On Thu, 8 Dec 2022 09:01:08 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Tests java/util/stream/test/org/openjdk/tests/java/util/* with -XX:+UseZGC -Xcomp -XX:-TieredCompilation crashes with `assert(regs[i] != regs[j]) failed: Multiple uses of register: rax`. More specifically compilation of java.util.concurrent.ForkJoinTask::awaitDone.
>> 
>> The reason seems to be that the compare value and the memory input ends up sharing a register. (Uses Unsafe CAS which CAS an object reference into a field of that object, `oldval: rax` and `mem: [rax+offset]`). The Z load barrier stub dispatch implementation require that the reference and reference address occupy distinct registers. In the loadP nodes this is established by marking all but the memory TEMP which results in no sharing.
>> 
>> This is not possible for the CompareAndSwapP / CompareAndExchangeP nodes as the compare value is an input node. 
>> 
>> The solution proposed here is less than ideal as it makes the CAS nodes require one extra TEMP register, which in the common case is unused. This puts unnecessary extra strain on the register allocation. The problem is that there is no way currently (that I can find) to express in .ad that a memory input must not share registers with a specific other input. 
>> 
>> There is an alternative solution for this specific crash which does not use a second TEMP register (see commit: cfd5ced4e97e986fc10c5a8721b543cd3101c58a). It accomplish this by using the same trick that the aarch64 Z CAS node uses which is to specify the memory as indirect which results in the address being LEA into a register. However from what I can see this does not guarantee that the address and the reference does not share a register (`oldval: rax` and `mem: [rax]`). So it is theoretically broken, (and so is the aarch64 implementation). 
>> 
>> It is unclear to me if there is ever a way for C2 to generation a CAS which compares the address of the field with its content. 
>> 
>> I call on anyone with more knowledge about `adlc` and `C2` for feedback. And specifically I want to open up a discussion with these points:
>> * Is there some other way of expressing in the .ad file that a memory input should not share some register?
>>   * If not, is this a worthwhile RFE? As it seems to be a patterned used at least in other places in Z.
>> * Will the indirect input ever share a register with oldval and/or are the aarch64/riscv implementations broken because of this? How about ppc?
>> 
>> Testing: linux-x64 zgc tagged tests tier 1-7 and some specific crashing tests with `-XX:+UseZGC -Xcomp -XX:-TieredCompilation` (in: java/util/stream/, java/util/concurrent/)
>
> Axel Boldt-Christmas 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 commits since the last revision:
> 
>  - Remove problem listed tests
>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8297235
>  - indirect zXChgP as well
>  - indirect alternative
>  - JDK-8297235: ZGC: assert(regs[i] != regs[j]) failed: Multiple uses of register: rax

Marked as reviewed by ayang (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11410

From aph at openjdk.org  Mon Dec 12 12:47:12 2022
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 12 Dec 2022 12:47:12 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v7]
In-Reply-To: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
Message-ID: <ikldOJjJK5g4tdTsWrc_B_akZS3rVDS7VGqUXyK78Gg=.ddd1e186-60d9-42cc-a9e9-fa0271407fe0@github.com>

> This patch fixes the remaining null pointer dereference bugs that I know of.
> 
> For the main bug, C2 was using a null reference to indicate an uninitialized `Node_List`. I replaced the null reference with a static sentinel.
> 
> I also turned on `-fsanitize=null` and found and fixed a bunch of other null pointer dereferences. With this,I have run a full bootstrap and tier1 tests with `-fsanitize=null` enabled.
> 
> I have checked that the code generated by GCC is not worse in any significant way, so I don't expect to see any performance regressions.
> 
> I'd like to enable `-fsanitize=null` in debug builds to prevent regressions in this area. What do you think?

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Align temp buffer used by offset_of().

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10920/files
  - new: https://git.openjdk.org/jdk/pull/10920/files/063f70c3..429a6300

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10920&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10920&range=05-06

  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/10920.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10920/head:pull/10920

PR: https://git.openjdk.org/jdk/pull/10920

From mgronlun at openjdk.org  Mon Dec 12 13:17:50 2022
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 12 Dec 2022 13:17:50 GMT
Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC
In-Reply-To: <BOJ4yH2GtNWXDVXMKwPw9Ic359dnBK8Sb9tDw3a5Qmc=.197acbb0-3ed6-418f-8bcf-70ef4b67de5e@github.com>
References: <BOJ4yH2GtNWXDVXMKwPw9Ic359dnBK8Sb9tDw3a5Qmc=.197acbb0-3ed6-418f-8bcf-70ef4b67de5e@github.com>
Message-ID: <Pig3FFvZCCDgWU2ily_SuTxFF67dT1TYUP3-SYc2Lgs=.191aa752-d671-4223-aaff-fc1c13d59a33@github.com>

On Thu, 8 Dec 2022 11:23:57 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The JfrVFrameStream is used while generating stack traces for events. One of the events are the ZPage allocation event. This event is sometimes sent when ZGC is relocating. The current implementation of JfrVFrameStream uses WalkContinuation::include, which causes JFR to walk the continuation and perform GC barriers. This is problematic, since ZGC has a requirement that we never perform load barriers while running the relocation code. If we do, we might end up performing other reloctions from the the relocation code, and in some cases that causes dead locks.
> 
> I propose that JFR doesn't walk the continuations when sending events. An alternative could be to limit this to ZGC, but I'd like to get some feedback around that from JFR / Loom devs.
> 
> We've been testing this patch in the Generational ZGC repository.

How important is the stack trace information for the ZPageAllocation event? What is it used for, i.e. does it give the user any information to change their code? Is it used for ZGC devs to do what exactly? See paths that trigger barriers?

-------------

PR: https://git.openjdk.org/jdk/pull/11586

From stefank at openjdk.org  Mon Dec 12 13:40:43 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 12 Dec 2022 13:40:43 GMT
Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC
In-Reply-To: <Pig3FFvZCCDgWU2ily_SuTxFF67dT1TYUP3-SYc2Lgs=.191aa752-d671-4223-aaff-fc1c13d59a33@github.com>
References: <BOJ4yH2GtNWXDVXMKwPw9Ic359dnBK8Sb9tDw3a5Qmc=.197acbb0-3ed6-418f-8bcf-70ef4b67de5e@github.com>
 <Pig3FFvZCCDgWU2ily_SuTxFF67dT1TYUP3-SYc2Lgs=.191aa752-d671-4223-aaff-fc1c13d59a33@github.com>
Message-ID: <toxdxQanXk8ZgUgLaWccjN4d7U1XRcawTP-_3rmvVak=.74a49152-a20d-4afd-bc87-a30f295ab0b0@github.com>

On Mon, 12 Dec 2022 13:15:24 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> How important is the stack trace information for the ZPageAllocation event?

I don't know. I don't have any experience with looking at JFR Events with Loom stacks.

> What is it used for, i.e. does it give the user any information to change their code?

It's used as a way to see where the application spends a long time (> 1ms) in allocations, which is a cause for latency problems. Some reasons for long allocations: lock contention, over-provisioned machine, large object allocations, not using -Xms == -Xms + AlwaysPreTouch, etc.

> Is it used for ZGC devs to do what exactly? 

To look for scalability issues in the JVM. For those use-cases I have not really cared about the stack traces.

-------------

PR: https://git.openjdk.org/jdk/pull/11586

From aph at openjdk.org  Mon Dec 12 14:01:01 2022
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 12 Dec 2022 14:01:01 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v7]
In-Reply-To: <ikldOJjJK5g4tdTsWrc_B_akZS3rVDS7VGqUXyK78Gg=.ddd1e186-60d9-42cc-a9e9-fa0271407fe0@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
 <ikldOJjJK5g4tdTsWrc_B_akZS3rVDS7VGqUXyK78Gg=.ddd1e186-60d9-42cc-a9e9-fa0271407fe0@github.com>
Message-ID: <3RQ0PrBacQSFWDIsH4DPOVHpgzg0Zg9zf_7MHiqOyiU=.d85f7118-73cc-4601-88db-95075edcfb45@github.com>

On Mon, 12 Dec 2022 12:47:12 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This patch fixes the remaining null pointer dereference bugs that I know of.
>> 
>> For the main bug, C2 was using a null reference to indicate an uninitialized `Node_List`. I replaced the null reference with a static sentinel.
>> 
>> I also turned on `-fsanitize=null` and found and fixed a bunch of other null pointer dereferences. With this,I have run a full bootstrap and tier1 tests with `-fsanitize=null` enabled.
>> 
>> I have checked that the code generated by GCC is not worse in any significant way, so I don't expect to see any performance regressions.
>> 
>> I'd like to enable `-fsanitize=null` in debug builds to prevent regressions in this area. What do you think?
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Align temp buffer used by offset_of().

src/hotspot/share/utilities/globalDefinitions_gcc.hpp line 151:

> 149: #define offset_of(klass,field)                          \
> 150: []() {                                                  \
> 151:   char space[sizeof (klass)] ATTRIBUTE_ALIGNED(16);     \

So I aligned this, and it constant folds everything nicely.
I have a nagging worry in the back of my mind that on some platforms this might be over-aligned, which would be another instancde of unspecified behaviour, but i don't think we have any supported targets where this might be a problem.

-------------

PR: https://git.openjdk.org/jdk/pull/10920

From mgronlun at openjdk.org  Mon Dec 12 14:08:20 2022
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 12 Dec 2022 14:08:20 GMT
Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC
In-Reply-To: <BOJ4yH2GtNWXDVXMKwPw9Ic359dnBK8Sb9tDw3a5Qmc=.197acbb0-3ed6-418f-8bcf-70ef4b67de5e@github.com>
References: <BOJ4yH2GtNWXDVXMKwPw9Ic359dnBK8Sb9tDw3a5Qmc=.197acbb0-3ed6-418f-8bcf-70ef4b67de5e@github.com>
Message-ID: <Ra-ZadmcVM5VMugm3M4f0z8EaTcW0q_etM_Y3OJyxhY=.435d7fe8-35e7-4040-a779-2aa49dc8fe44@github.com>

On Thu, 8 Dec 2022 11:23:57 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The JfrVFrameStream is used while generating stack traces for events. One of the events are the ZPage allocation event. This event is sometimes sent when ZGC is relocating. The current implementation of JfrVFrameStream uses WalkContinuation::include, which causes JFR to walk the continuation and perform GC barriers. This is problematic, since ZGC has a requirement that we never perform load barriers while running the relocation code. If we do, we might end up performing other reloctions from the the relocation code, and in some cases that causes dead locks.
> 
> I propose that JFR doesn't walk the continuations when sending events. An alternative could be to limit this to ZGC, but I'd like to get some feedback around that from JFR / Loom devs.
> 
> We've been testing this patch in the Generational ZGC repository.

It is a complicated problem to solve; I remember spending a long time resolving the recursivity issues involved with the introduction of Virtual Threads.

Previously in JFR, a few paths were selected as a function of the event type but removed long since because it requires maintaining a list of sensitive event types that all must check. The "skip" value could perhaps be conditionalized behind UseZGC and for the ZGC event types only. It requires passing through the event type and said list of sensitive types.

Or maybe we can introduce an additional attribute in metadata.xml, that way we only need to check the individual event type, not a set of event types.

-------------

PR: https://git.openjdk.org/jdk/pull/11586

From aph at openjdk.org  Mon Dec 12 14:12:19 2022
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 12 Dec 2022 14:12:19 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v8]
In-Reply-To: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
Message-ID: <S5Tn5QzQsgCR4ZUr8_IanRnCBvEo9Udda29CDKeARD4=.643504c5-fd5b-4213-b864-fea0ff1b5daf@github.com>

> This patch fixes the remaining null pointer dereference bugs that I know of.
> 
> For the main bug, C2 was using a null reference to indicate an uninitialized `Node_List`. I replaced the null reference with a static sentinel.
> 
> I also turned on `-fsanitize=null` and found and fixed a bunch of other null pointer dereferences. With this,I have run a full bootstrap and tier1 tests with `-fsanitize=null` enabled.
> 
> I have checked that the code generated by GCC is not worse in any significant way, so I don't expect to see any performance regressions.
> 
> I'd like to enable `-fsanitize=null` in debug builds to prevent regressions in this area. What do you think?

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Reviewer feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10920/files
  - new: https://git.openjdk.org/jdk/pull/10920/files/429a6300..812ce8fc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10920&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10920&range=06-07

  Stats: 7 lines in 2 files changed: 1 ins; 3 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10920.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10920/head:pull/10920

PR: https://git.openjdk.org/jdk/pull/10920

From rehn at openjdk.org  Mon Dec 12 14:46:08 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 12 Dec 2022 14:46:08 GMT
Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v7]
In-Reply-To: <AYhCxPKMsfdFV8iiAy9oHn4vtW8qd5zJPEbJQb6qZBk=.70e1d24b-fdbd-4d62-8319-073247eae8b6@github.com>
References: <Dj9YfY10SLn8dR1Ez3kEQe4tXm1q5W1TS8_4r3gBUsY=.6c38825a-86e5-4575-a509-683786d242a6@github.com>
 <pRcbuNmrpRkRA8lOJfYlEVWo3W766EMs6Gw5raXbZPs=.66222c03-5a36-43be-a9c9-080d046d73d7@github.com>
 <AYhCxPKMsfdFV8iiAy9oHn4vtW8qd5zJPEbJQb6qZBk=.70e1d24b-fdbd-4d62-8319-073247eae8b6@github.com>
Message-ID: <lND3ca-9yfFRsrELQgA9EBv8q7rPlpopLJwtCZP7Mns=.728c1527-e978-4f51-a76b-7e41a3faa91c@github.com>

On Mon, 12 Dec 2022 00:58:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Also please do not force-push.

FYI: I'm not sure it even was possible to fix the "full of unexpected changes" without force push.
Even if it was, the effort required to fix it without force push would be pretty significant.
So I'd say this one of those exceptions to the rule :)

-------------

PR: https://git.openjdk.org/jdk/pull/11288

From aph at openjdk.org  Mon Dec 12 14:51:22 2022
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 12 Dec 2022 14:51:22 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v9]
In-Reply-To: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
Message-ID: <tWNHj4sT_rLcfaX3oyU-NtuCn95s8fkOyQa7opXWipg=.32388fd8-9e32-4aa2-918e-bba26dbeb5b6@github.com>

> This patch fixes the remaining null pointer dereference bugs that I know of.
> 
> For the main bug, C2 was using a null reference to indicate an uninitialized `Node_List`. I replaced the null reference with a static sentinel.
> 
> I also turned on `-fsanitize=null` and found and fixed a bunch of other null pointer dereferences. With this,I have run a full bootstrap and tier1 tests with `-fsanitize=null` enabled.
> 
> I have checked that the code generated by GCC is not worse in any significant way, so I don't expect to see any performance regressions.
> 
> I'd like to enable `-fsanitize=null` in debug builds to prevent regressions in this area. What do you think?

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Reviewer feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10920/files
  - new: https://git.openjdk.org/jdk/pull/10920/files/812ce8fc..35e93fe8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10920&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10920&range=07-08

  Stats: 12 lines in 1 file changed: 7 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/10920.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10920/head:pull/10920

PR: https://git.openjdk.org/jdk/pull/10920

From aph at openjdk.org  Mon Dec 12 14:51:25 2022
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 12 Dec 2022 14:51:25 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v6]
In-Reply-To: <CjM0Fhl3p4y2-MsR0akOWL5W5vu5ScALtRKgV6A2sBM=.3b5491a3-d0a3-44d4-8e76-ba233e9bff71@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
 <BlgmU61ejhlUYvDFqS4vdeD-KZPN1Gs93wP91Y0YE74=.f95c84af-7e10-4426-99f6-985c19d36506@github.com>
 <CjM0Fhl3p4y2-MsR0akOWL5W5vu5ScALtRKgV6A2sBM=.3b5491a3-d0a3-44d4-8e76-ba233e9bff71@github.com>
Message-ID: <66h6XyPj2M-F1sgyoFzGc6j9Aw5RtBKExrgro3lanow=.1b39bfa3-2077-4e92-b13f-0de3068fef2f@github.com>

On Mon, 5 Dec 2022 21:15:47 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Feedback from reviewers
>
> src/hotspot/share/runtime/vmStructs.hpp line 193:
> 
>> 191: #define CHECK_NONSTATIC_VM_STRUCT_ENTRY(typeName, fieldName, type) {               \
>> 192:     char space[sizeof (typeName)];                                                 \
>> 193:     typeName *dummyObj = (typeName *)space; type* dummy = &dummyObj->fieldName;    \
> 
> The member value type checking could be written more explicitly (and IMO more
> clearly, though metaprogramming :) ) as:
> 
> 
> #define CHECK_NONSTATIC_VM_STRUCT_ENTRY(typeName, fieldName, type) { \
>   std::static_assert( \
>     std::is_convertible< \
>       std::add_pointer_t<decltype(std::declval<typeName>().fieldName)>, \
>       std::add_pointer_t<type>>::value, \
>     "type mismatch for " XSTR(fieldName) " member of " XSTR(typeName)); \
>   assert(offset_of(typeName, fieldName) < sizeof(typeName), "..."); \
> }
> 
> 
> except that uses `std::declval`, which is in `<utility>`, which is not (yet)
> permitted for use in HotSpot code.  Maybe that will change someday.  In the
> meantime, we could add our own definition to globalUtilities.hpp, since it is
> quite trivial.
> 
> 
> template<typename T>
> std::add_rvalue_reference_t<T> declval() noexcept;
> 
> 
> I tried using `std::is_same` instead of `std::is_convertible`, which seems
> like it might be better. However, there were a number of failures because some
> uses are not exact matches. There were differences in volatile, in base vs
> derived types, and reference vs non-reference types (if you drop the
> conversion to pointers).
> 
> This dodges the whole question of alignment of the space buffer.

Done.

-------------

PR: https://git.openjdk.org/jdk/pull/10920

From duke at openjdk.org  Mon Dec 12 14:53:05 2022
From: duke at openjdk.org (Afshin Zafari)
Date: Mon, 12 Dec 2022 14:53:05 GMT
Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v7]
In-Reply-To: <lND3ca-9yfFRsrELQgA9EBv8q7rPlpopLJwtCZP7Mns=.728c1527-e978-4f51-a76b-7e41a3faa91c@github.com>
References: <Dj9YfY10SLn8dR1Ez3kEQe4tXm1q5W1TS8_4r3gBUsY=.6c38825a-86e5-4575-a509-683786d242a6@github.com>
 <pRcbuNmrpRkRA8lOJfYlEVWo3W766EMs6Gw5raXbZPs=.66222c03-5a36-43be-a9c9-080d046d73d7@github.com>
 <AYhCxPKMsfdFV8iiAy9oHn4vtW8qd5zJPEbJQb6qZBk=.70e1d24b-fdbd-4d62-8319-073247eae8b6@github.com>
 <lND3ca-9yfFRsrELQgA9EBv8q7rPlpopLJwtCZP7Mns=.728c1527-e978-4f51-a76b-7e41a3faa91c@github.com>
Message-ID: <ac9pd1wuUr7rmnGMF-AuBdKoU2yFyMEExmCXy69MdUU=.4b3d0eb1-bb49-4d09-b42f-23cc45d6f2f3@github.com>

On Mon, 12 Dec 2022 14:44:03 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> > Also please do not force-push.
> 
> FYI: I'm not sure it even was possible to fix the "full of unexpected changes" without force push. Even if it was, the effort required to fix it without force push would be pretty significant. So I'd say this one of those exceptions to the rule :)

I did 2 mistakes: rebase my branch while a PR was in progress, and force-push my changes
After getting help from colleagues, I had to do another force-push to get back my branch to its state before the mistakes.

-------------

PR: https://git.openjdk.org/jdk/pull/11288

From ngasson at openjdk.org  Mon Dec 12 15:28:49 2022
From: ngasson at openjdk.org (Nick Gasson)
Date: Mon, 12 Dec 2022 15:28:49 GMT
Subject: RFR: 8298482: Implement ParallelGC NUMAStats for Linux
Message-ID: <PPSEKqySzLiykISEVNPLc1NE3f_a_J8SFCxXqtMDvBQ=.030e5332-1bc0-4fd5-b20e-bb2afc5c6960@github.com>

ParallelGC has a seemingly useful option -XX:+NUMAStats that prints detailed information in GC.heap_info about which NUMA node pages in the eden space are bound to.  However as far as I can tell this only ever worked on Solaris and is not implemented on any of the systems we currently support.  This patch implements it on Linux using the move_pages system call.

The function os::get_page_info() and accompanying struct page_info was just a thin wrapper around the Solaris meminfo(2) syscall and was never ported to other systems so I've just removed it rather than try to emulate its interface.

There's also a method MutableNUMASpace::LGRPSpace::scan_pages() which attempts to find pages on the wrong NUMA node and frees them so that they have another chance to be allocated on the correct node by the first-touching thread, but I think this has always been a no-op on non-Solaris so perhaps should also be removed.  On Linux it shouldn't be necessary as you can bind pages to the desired node directly.

I don't know what the performance of this option was like on Solaris but on Linux the move_pages call can be quite slow: I measured about 25ms/GB on my system.  At the moment we call LGRPSpace::accumulate_statistics() twice per GC cycle: I removed the second call as it's likely to see a lot of uncommitted pages if the spaces were just resized. MutableNUMASpace::print_on() also calls accumulate_statistics() directly and since that's the only place this data is used, maybe we can drop the call from MutableNUMASpace::accumulate_statistics() as well?

Example output:


 PSYoungGen      total 4290560K, used 835628K [0x00000006aac00000, 0x0000000800000000, 0x0000000800000000)
  eden space 3096576K, 1% used [0x00000006aac00000,0x00000007176a9f48,0x0000000767c00000)
    lgrp 0 space 1761280K, 2% used [0x00000006aac00000,0x00000006acfc4980,0x0000000716400000)
    local/remote/unbiased/uncommitted: 1671168K/0K/0K/90112K, large/small pages: 0/440320
    lgrp 1 space 1335296K, 46% used [0x0000000716400000,0x000000073c2abb18,0x0000000767c00000)
    local/remote/unbiased/uncommitted: 1335296K/0K/0K/0K, large/small pages: 0/333824
  from space 1193984K, 65% used [0x00000007b7200000,0x00000007e6b9c778,0x0000000800000000)
  to   space 1247232K, 0% used [0x0000000767c00000,0x0000000767c00000,0x00000007b3e00000)


After testing this with SPECjbb for a while I noticed some pages always end up bound to the wrong node.  I think this is a regression caused by JDK-8283935 but I'll raise a separate ticket for that.

-------------

Commit messages:
 - 8298482: Implement ParallelGC NUMAStats for Linux

Changes: https://git.openjdk.org/jdk/pull/11635/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11635&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298482
  Stats: 42 lines in 6 files changed: 7 ins; 14 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/11635.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11635/head:pull/11635

PR: https://git.openjdk.org/jdk/pull/11635

From kbarrett at openjdk.org  Mon Dec 12 15:34:46 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 12 Dec 2022 15:34:46 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v9]
In-Reply-To: <tWNHj4sT_rLcfaX3oyU-NtuCn95s8fkOyQa7opXWipg=.32388fd8-9e32-4aa2-918e-bba26dbeb5b6@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
 <tWNHj4sT_rLcfaX3oyU-NtuCn95s8fkOyQa7opXWipg=.32388fd8-9e32-4aa2-918e-bba26dbeb5b6@github.com>
Message-ID: <PmAM3TcsjhmrEbFd0jQszic8lQLyWckKuAn9VB3UhGQ=.335271ed-c312-4b59-ac47-92e133f599c1@github.com>

On Mon, 12 Dec 2022 14:51:22 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This patch fixes the remaining null pointer dereference bugs that I know of.
>> 
>> For the main bug, C2 was using a null reference to indicate an uninitialized `Node_List`. I replaced the null reference with a static sentinel.
>> 
>> I also turned on `-fsanitize=null` and found and fixed a bunch of other null pointer dereferences. With this,I have run a full bootstrap and tier1 tests with `-fsanitize=null` enabled.
>> 
>> I have checked that the code generated by GCC is not worse in any significant way, so I don't expect to see any performance regressions.
>> 
>> I'd like to enable `-fsanitize=null` in debug builds to prevent regressions in this area. What do you think?
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reviewer feedback

src/hotspot/share/runtime/vmStructs.hpp line 193:

> 191: // Converts any type T to a reference type.
> 192: template<typename T>
> 193: std::add_rvalue_reference_t<T> declval() noexcept;

I think I'd prefer this was in globalDefinitions.hpp rather than squirreled away in this obscure location.  But maybe that can wait until someone else needs it.  (And maybe by then we can use std::declval :) )

-------------

PR: https://git.openjdk.org/jdk/pull/10920

From kbarrett at openjdk.org  Mon Dec 12 15:34:49 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 12 Dec 2022 15:34:49 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v7]
In-Reply-To: <3RQ0PrBacQSFWDIsH4DPOVHpgzg0Zg9zf_7MHiqOyiU=.d85f7118-73cc-4601-88db-95075edcfb45@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
 <ikldOJjJK5g4tdTsWrc_B_akZS3rVDS7VGqUXyK78Gg=.ddd1e186-60d9-42cc-a9e9-fa0271407fe0@github.com>
 <3RQ0PrBacQSFWDIsH4DPOVHpgzg0Zg9zf_7MHiqOyiU=.d85f7118-73cc-4601-88db-95075edcfb45@github.com>
Message-ID: <4p38g-UfGuZEsg5XCPBtsx0MltiLa1_XnIVcQVMmHe0=.fa2dd765-ac03-4290-bec5-a3a76764356d@github.com>

On Mon, 12 Dec 2022 13:59:00 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Align temp buffer used by offset_of().
>
> src/hotspot/share/utilities/globalDefinitions_gcc.hpp line 151:
> 
>> 149: #define offset_of(klass,field)                          \
>> 150: []() {                                                  \
>> 151:   char space[sizeof (klass)] ATTRIBUTE_ALIGNED(16);     \
> 
> So I aligned this, and it constant folds everything nicely.
> I have a nagging worry in the back of my mind that on some platforms this might be over-aligned, which would be another instancde of unspecified behaviour, but i don't think we have any supported targets where this might be a problem.

Is 16 over-aligned on 32bit platforms?  Too bad https://git.openjdk.org/jdk/pull/11446 isn't approved yet, else you could use `alignas(std::max_align_t)`.  (I wouldn't object if you were forward-looking here, though can't speak for anyone else.)

-------------

PR: https://git.openjdk.org/jdk/pull/10920

From kbarrett at openjdk.org  Mon Dec 12 15:44:52 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 12 Dec 2022 15:44:52 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v9]
In-Reply-To: <tWNHj4sT_rLcfaX3oyU-NtuCn95s8fkOyQa7opXWipg=.32388fd8-9e32-4aa2-918e-bba26dbeb5b6@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
 <tWNHj4sT_rLcfaX3oyU-NtuCn95s8fkOyQa7opXWipg=.32388fd8-9e32-4aa2-918e-bba26dbeb5b6@github.com>
Message-ID: <Tw4OrgBWFlkJA8XEO_AISZ32ZvpBGUPhsuprtLAoeRY=.a16df657-29b2-4f6a-9601-a6e2540e4c95@github.com>

On Mon, 12 Dec 2022 14:51:22 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This patch fixes the remaining null pointer dereference bugs that I know of.
>> 
>> For the main bug, C2 was using a null reference to indicate an uninitialized `Node_List`. I replaced the null reference with a static sentinel.
>> 
>> I also turned on `-fsanitize=null` and found and fixed a bunch of other null pointer dereferences. With this,I have run a full bootstrap and tier1 tests with `-fsanitize=null` enabled.
>> 
>> I have checked that the code generated by GCC is not worse in any significant way, so I don't expect to see any performance regressions.
>> 
>> I'd like to enable `-fsanitize=null` in debug builds to prevent regressions in this area. What do you think?
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reviewer feedback

src/hotspot/share/utilities/globalDefinitions_gcc.hpp line 151:

> 149: #define offset_of(klass,field)                          \
> 150: []() {                                                  \
> 151:   char space[sizeof (klass)] ATTRIBUTE_ALIGNED(16);     \

Is 16 over-aligned on 32bit platforms? Too bad https://git.openjdk.org/jdk/pull/11446 isn't approved yet, else you could use alignas(std::max_align_t). (I wouldn't object if you were forward-looking here, though can't speak for anyone else.)

-------------

PR: https://git.openjdk.org/jdk/pull/10920

From coleenp at openjdk.org  Mon Dec 12 17:04:01 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 12 Dec 2022 17:04:01 GMT
Subject: [jdk20] RFR: 8296955: Kitchensink.java failed with
 "double free or corruption (!prev): <addr>"
In-Reply-To: <-rew__nvw1aQv6-lfTVkU-DGA_rjP4JypTsIj2ozblI=.21be566f-c364-4537-86b6-35e7d12e3e4e@github.com>
References: <-rew__nvw1aQv6-lfTVkU-DGA_rjP4JypTsIj2ozblI=.21be566f-c364-4537-86b6-35e7d12e3e4e@github.com>
Message-ID: <tZ69yKUhg2960_TeQEtIHj7Qhn3_cqBi98wZxjzGmMA=.8f3ec398-5ff7-4383-9370-0766f0d8fa7c@github.com>

On Fri, 9 Dec 2022 12:27:42 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Thanks to Kim for the diagnosis of this problem.  G1 cleans up nmethods in parallel threads during a safepoint and may post or queue unload events to be posted.  The event posting creates jmethodIDs.  The jmethodID code assumes that it's thread safe in a safepoint, which it is not.
> I removed this optimization, which isn't much of an optimization (did run some sanity performance tests) and is unsafe in the modern code.
> Tested with tier1-7, where tier5 found the original bug.

Thanks Serguei, Erik and Kim.

-------------

PR: https://git.openjdk.org/jdk20/pull/10

From coleenp at openjdk.org  Mon Dec 12 17:08:38 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 12 Dec 2022 17:08:38 GMT
Subject: [jdk20] RFR: 8298084: Memory leak in
 Method::build_profiling_method_data [v2]
In-Reply-To: <C9g5yB0uAHEc3BUu8JImdl9hOJUqFeDosqrIJWtYOlk=.7b3aea19-771a-4b9d-af5f-2716a2bac11a@github.com>
References: <C9g5yB0uAHEc3BUu8JImdl9hOJUqFeDosqrIJWtYOlk=.7b3aea19-771a-4b9d-af5f-2716a2bac11a@github.com>
Message-ID: <FKpX03r3nt3YhRtVFURpibssfoUjlhpzNq3MhIBB1ho=.a1b743ec-3d02-4b4a-a5f5-445a1600f85b@github.com>

> This change fixes the MethodData leak by calling the destructor in both the release_C_heap_structures conditionally and by calling the MethodData destructor in the MetadataFactory::free_metadata method.
> Thanks to @jcking for working on the patch and discussion.
> Tested with tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix metaprogramming

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/13/files
  - new: https://git.openjdk.org/jdk20/pull/13/files/0bc9abab..e195cd85

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=13&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=13&range=00-01

  Stats: 5 lines in 1 file changed: 1 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk20/pull/13.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/13/head:pull/13

PR: https://git.openjdk.org/jdk20/pull/13

From coleenp at openjdk.org  Mon Dec 12 17:21:21 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 12 Dec 2022 17:21:21 GMT
Subject: [jdk20] RFR: 8298084: Memory leak in
 Method::build_profiling_method_data [v2]
In-Reply-To: <R6yAdAMtsv7vbpg136bsQfbgM3CUJBQ9IrzdGt6z_pg=.8dd35c45-374c-410f-9a20-555bf5f2c3d0@github.com>
References: <C9g5yB0uAHEc3BUu8JImdl9hOJUqFeDosqrIJWtYOlk=.7b3aea19-771a-4b9d-af5f-2716a2bac11a@github.com>
 <R6yAdAMtsv7vbpg136bsQfbgM3CUJBQ9IrzdGt6z_pg=.8dd35c45-374c-410f-9a20-555bf5f2c3d0@github.com>
Message-ID: <82Cfs1I07bdEH7dywpYf9ymESnVhsX5zjsZJJfHJRNw=.6f761c7d-cc46-4f9d-bdc1-7d6fa321e6fe@github.com>

On Sun, 11 Dec 2022 17:30:55 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix metaprogramming
>
> src/hotspot/share/memory/metadataFactory.hpp line 79:
> 
>> 77:       // T is a potentially const or volatile qualified pointer. Remove the pointer and any const
>> 78:       // or volatile so we can call the destructor of the type T points to.
>> 79:       using U = typename RemoveCV<typename RemovePointer<T>::type>::type;
> 
> Use `std::remove_pointer<T>` and `std::remove_cv<T>` from `<type_traits>` in
> preference to our pre-C++11/14 workarounds. You can also avoid `typename` and
> `::type` by using the "_t"-suffixed versions. So
> 
> using U = std::remove_cv_t<std::remove_pointer_t<T>>;
> 
> And "If requested" in the comment? That suggests some conditionalization, of
> which there is none. Maybe something like "Most of the cleanup is done via
> deallocate_contents, but some types require some additional cleanup via the
> destructor."

I fixed this as suggested.  Thanks.

-------------

PR: https://git.openjdk.org/jdk20/pull/13

From aph at openjdk.org  Mon Dec 12 17:35:57 2022
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 12 Dec 2022 17:35:57 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v10]
In-Reply-To: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
Message-ID: <LcsuctvHHy_sSPFlz3akeorXM0DoL3UrYDCeVvzB7hM=.ffd8d927-4313-4f69-a97e-a34debad4b0a@github.com>

> This patch fixes the remaining null pointer dereference bugs that I know of.
> 
> For the main bug, C2 was using a null reference to indicate an uninitialized `Node_List`. I replaced the null reference with a static sentinel.
> 
> I also turned on `-fsanitize=null` and found and fixed a bunch of other null pointer dereferences. With this,I have run a full bootstrap and tier1 tests with `-fsanitize=null` enabled.
> 
> I have checked that the code generated by GCC is not worse in any significant way, so I don't expect to see any performance regressions.
> 
> I'd like to enable `-fsanitize=null` in debug builds to prevent regressions in this area. What do you think?

Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - Merge from HEAD
 - Reviewer feedback
 - Reviewer feedback
 - Align temp buffer used by offset_of().
 - Feedback from reviewers
 - Feedback from reviewers
 - Migrate postaloc.cpp migrated away from references to pointers when it comes to Node_List.
   
   Co-authored-by: Vladimir Ivanov <vaivanov at openjdk.org>
 - Merge from JDK head
 - Revert "Push ScopedValue tests"
   
   This reverts commit d298edfa9eda48ace9a27f83d38320fe6ba79e67.
 - Push ScopedValue tests
 - ... and 5 more: https://git.openjdk.org/jdk/compare/56c438bf...59802eb4

-------------

Changes: https://git.openjdk.org/jdk/pull/10920/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10920&range=09
  Stats: 81 lines in 6 files changed: 44 ins; 1 del; 36 mod
  Patch: https://git.openjdk.org/jdk/pull/10920.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10920/head:pull/10920

PR: https://git.openjdk.org/jdk/pull/10920

From kbarrett at openjdk.org  Mon Dec 12 17:39:16 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 12 Dec 2022 17:39:16 GMT
Subject: [jdk20] RFR: 8298084: Memory leak in
 Method::build_profiling_method_data [v2]
In-Reply-To: <FKpX03r3nt3YhRtVFURpibssfoUjlhpzNq3MhIBB1ho=.a1b743ec-3d02-4b4a-a5f5-445a1600f85b@github.com>
References: <C9g5yB0uAHEc3BUu8JImdl9hOJUqFeDosqrIJWtYOlk=.7b3aea19-771a-4b9d-af5f-2716a2bac11a@github.com>
 <FKpX03r3nt3YhRtVFURpibssfoUjlhpzNq3MhIBB1ho=.a1b743ec-3d02-4b4a-a5f5-445a1600f85b@github.com>
Message-ID: <gd4Sv7ftFwAd_NeHmspb0AiivSXZkc69dBt1KQo_So4=.5b4de23b-07f6-4001-be4b-141b734aa49a@github.com>

On Mon, 12 Dec 2022 17:08:38 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change fixes the MethodData leak by calling the destructor in both the release_C_heap_structures conditionally and by calling the MethodData destructor in the MetadataFactory::free_metadata method.
>> Thanks to @jcking for working on the patch and discussion.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix metaprogramming

Marked as reviewed by kbarrett (Reviewer).

src/hotspot/share/memory/metadataFactory.hpp line 78:

> 76:       // T is a potentially const or volatile qualified pointer. Remove the pointer and any const
> 77:       // or volatile so we can call the destructor of the type T points to.
> 78:       using U = std::remove_cv_t<std::remove_pointer_t<T>>;

Could get rid of `remove_pointer` by changing the function parameter from `T md` to `T* md`.  Apologies for not thinking of that earlier.

-------------

PR: https://git.openjdk.org/jdk20/pull/13

From coleenp at openjdk.org  Mon Dec 12 17:43:09 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 12 Dec 2022 17:43:09 GMT
Subject: [jdk20] RFR: 8298084: Memory leak in
 Method::build_profiling_method_data [v2]
In-Reply-To: <gd4Sv7ftFwAd_NeHmspb0AiivSXZkc69dBt1KQo_So4=.5b4de23b-07f6-4001-be4b-141b734aa49a@github.com>
References: <C9g5yB0uAHEc3BUu8JImdl9hOJUqFeDosqrIJWtYOlk=.7b3aea19-771a-4b9d-af5f-2716a2bac11a@github.com>
 <FKpX03r3nt3YhRtVFURpibssfoUjlhpzNq3MhIBB1ho=.a1b743ec-3d02-4b4a-a5f5-445a1600f85b@github.com>
 <gd4Sv7ftFwAd_NeHmspb0AiivSXZkc69dBt1KQo_So4=.5b4de23b-07f6-4001-be4b-141b734aa49a@github.com>
Message-ID: <wnhJVrnLQ5K_4fRZl0lfN105abiiq26QXmyFVtiyMWQ=.56fdd90a-c8e9-4cb0-8b58-ba2f9e75db4d@github.com>

On Mon, 12 Dec 2022 17:34:35 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix metaprogramming
>
> src/hotspot/share/memory/metadataFactory.hpp line 78:
> 
>> 76:       // T is a potentially const or volatile qualified pointer. Remove the pointer and any const
>> 77:       // or volatile so we can call the destructor of the type T points to.
>> 78:       using U = std::remove_cv_t<std::remove_pointer_t<T>>;
> 
> Could get rid of `remove_pointer` by changing the function parameter from `T md` to `T* md`.  Apologies for not thinking of that earlier.

The compiler seems not unhappy with that.

-------------

PR: https://git.openjdk.org/jdk20/pull/13

From iwalulya at openjdk.org  Mon Dec 12 17:48:02 2022
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 12 Dec 2022 17:48:02 GMT
Subject: RFR: 8293824: gc/whitebox/TestConcMarkCycleWB.java failed
 "RuntimeException: assertTrue: expected true, was false" [v2]
In-Reply-To: <dM4t6tEt_ECKHylcGy7v2lL8FOXa1j336ycPFt07Jnc=.1b984fe9-d268-4384-85d9-0984fff815a6@github.com>
References: <74AnEqLugaEU80XMNm8edtWBmK8gOFMirnZT1rdj1jI=.6ab039c0-3db5-4336-9aa7-867166b79cda@github.com>
 <dM4t6tEt_ECKHylcGy7v2lL8FOXa1j336ycPFt07Jnc=.1b984fe9-d268-4384-85d9-0984fff815a6@github.com>
Message-ID: <vnO8v_f4KLL9qTzDU9tRK9fGbiHpQNJA81CWItvRljA=.356b8790-4f88-47fb-9ed4-4fcd0c9ce780@github.com>

On Tue, 6 Dec 2022 12:34:47 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to WhiteBox and some tests involving G1 concurrent GCs.
>> 
>> Some tests currently use WhiteBox.g1StartConcMarkCycle() to trigger a
>> concurrent GC.  Many of them follow it with a loop waiting for a concurrent
>> cycle to not be in progress.  A few also preceed that call with a similar
>> loop, since that call does nothing and returns false if a concurrent cycle is
>> already in progress.  Those tests typically want to ensure there was a
>> concurrent cycle that was started after some setup.
>> 
>> The failing test calls that function, asserting that it returned true, e.g. a
>> new concurrent cycle was started.
>> 
>> There are various problems with this, due to races with concurrent cycles
>> started automatically and possibly aborted (by full GCs) concurrent cycles,
>> making some of these tests unreliable in some configurations.
>> 
>> For example, the test failure associated with this bug intermittently arises
>> when running with `-Xcomp`, triggering a concurrent cycle before the explicit
>> requests by the test, causing the explicit request to fail (because there is
>> already one in progress), failing the assert.  Waiting for there not to be an
>> in-progress cycle before the explicit request just narrows the race window.
>> 
>> We have a different mechanism for controlling concurrent cycles, the
>> concurrent GC breakpoint mechanism.  By adding a counter specifically for such
>> cycles, we can use GC breakpoints to ensure only the concurrent cycles the
>> test wants are occurring, and can verify they completed successfully.
>> 
>> So we change tests using WhiteBox.g1StartConcMarkCycle() to instead use GC
>> breakpoints, along with the new WhiteBox.g1CompletedConcurrentMarkCycles() to
>> avoid racing request problems and to detect aborted cycles.  Since it is no
>> longer used, WhiteBox.g1StartConcMarkCycle() is removed.
>> 
>> Testing:
>> mach5 tier1-6
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - use new whitebox api for running conc gc
>  - Merge branch 'master' into test-concmark
>  - copyrights
>  - remove WB.g1StartConcMarkCyle
>  - update tests
>  - add utility GC breakpoint functions
>  - add G1ConcurrentMark::completed_mark_cycles() and whitebox access

Changes requested by iwalulya (Reviewer).

test/lib/jdk/test/whitebox/WhiteBox.java line 177:

> 175:   // successful (e.g. it was aborted), then throws RuntimeException if
> 176:   // errorIfFail is true, returning false otherwise.
> 177:   public boolean g1RunConcurrentGC(boolean errorIfFail) {

Failure detection as described in the comment above is turned off for all test cases. Please verify if that is intentional.

-------------

PR: https://git.openjdk.org/jdk/pull/11435

From coleenp at openjdk.org  Mon Dec 12 17:51:25 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 12 Dec 2022 17:51:25 GMT
Subject: [jdk20] RFR: 8298084: Memory leak in
 Method::build_profiling_method_data [v3]
In-Reply-To: <C9g5yB0uAHEc3BUu8JImdl9hOJUqFeDosqrIJWtYOlk=.7b3aea19-771a-4b9d-af5f-2716a2bac11a@github.com>
References: <C9g5yB0uAHEc3BUu8JImdl9hOJUqFeDosqrIJWtYOlk=.7b3aea19-771a-4b9d-af5f-2716a2bac11a@github.com>
Message-ID: <yOvhSY98FRUuMUF3vAd0cqG9AWjypujSl-Qy3dpzf2A=.9c2c85cf-699b-4f49-8cdc-9a08a934039b@github.com>

> This change fixes the MethodData leak by calling the destructor in both the release_C_heap_structures conditionally and by calling the MethodData destructor in the MetadataFactory::free_metadata method.
> Thanks to @jcking for working on the patch and discussion.
> Tested with tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Even more metaprogramming improvements

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/13/files
  - new: https://git.openjdk.org/jdk20/pull/13/files/e195cd85..11fcdba0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=13&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=13&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk20/pull/13.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/13/head:pull/13

PR: https://git.openjdk.org/jdk20/pull/13

From aph at openjdk.org  Mon Dec 12 17:53:34 2022
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 12 Dec 2022 17:53:34 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v11]
In-Reply-To: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
Message-ID: <MjEptQ4_lH6M_MeU479y0Sq5xFmQ65iRtg9cMhuZKLg=.fbde09d7-a116-42aa-9ca0-1173b9bdbf96@github.com>

> This patch fixes the remaining null pointer dereference bugs that I know of.
> 
> For the main bug, C2 was using a null reference to indicate an uninitialized `Node_List`. I replaced the null reference with a static sentinel.
> 
> I also turned on `-fsanitize=null` and found and fixed a bunch of other null pointer dereferences. With this,I have run a full bootstrap and tier1 tests with `-fsanitize=null` enabled.
> 
> I have checked that the code generated by GCC is not worse in any significant way, so I don't expect to see any performance regressions.
> 
> I'd like to enable `-fsanitize=null` in debug builds to prevent regressions in this area. What do you think?

Andrew Haley has updated the pull request incrementally with three additional commits since the last revision:

 - Reviewer feedback
 - Fix merge
 - Fix merge

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10920/files
  - new: https://git.openjdk.org/jdk/pull/10920/files/59802eb4..7caa719b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10920&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10920&range=09-10

  Stats: 28 lines in 4 files changed: 6 ins; 21 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10920.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10920/head:pull/10920

PR: https://git.openjdk.org/jdk/pull/10920

From aph at openjdk.org  Mon Dec 12 17:53:37 2022
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 12 Dec 2022 17:53:37 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v9]
In-Reply-To: <PmAM3TcsjhmrEbFd0jQszic8lQLyWckKuAn9VB3UhGQ=.335271ed-c312-4b59-ac47-92e133f599c1@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
 <tWNHj4sT_rLcfaX3oyU-NtuCn95s8fkOyQa7opXWipg=.32388fd8-9e32-4aa2-918e-bba26dbeb5b6@github.com>
 <PmAM3TcsjhmrEbFd0jQszic8lQLyWckKuAn9VB3UhGQ=.335271ed-c312-4b59-ac47-92e133f599c1@github.com>
Message-ID: <iybPiC5kNSANEJA9vwID0YtJhrpFtis5vhXCm-NXX3s=.1a1ba50c-6c2b-4063-9036-5d680aec778b@github.com>

On Mon, 12 Dec 2022 15:22:23 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reviewer feedback
>
> src/hotspot/share/runtime/vmStructs.hpp line 193:
> 
>> 191: // Converts any type T to a reference type.
>> 192: template<typename T>
>> 193: std::add_rvalue_reference_t<T> declval() noexcept;
> 
> I think I'd prefer this was in globalDefinitions.hpp rather than squirreled away in this obscure location.  But maybe that can wait until someone else needs it.  (And maybe by then we can use std::declval :) )

I tried that, but it needed <type_traits> in globalDefinitions.hpp, so I backed off. How's this?

-------------

PR: https://git.openjdk.org/jdk/pull/10920

From aph at openjdk.org  Mon Dec 12 17:58:42 2022
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 12 Dec 2022 17:58:42 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v12]
In-Reply-To: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
Message-ID: <7czO98hN1RCtbvgzsaYqaBg5bELBGrS8q-yfREW1jFU=.5307712a-78b5-4092-9890-00f3a500d079@github.com>

> This patch fixes the remaining null pointer dereference bugs that I know of.
> 
> For the main bug, C2 was using a null reference to indicate an uninitialized `Node_List`. I replaced the null reference with a static sentinel.
> 
> I also turned on `-fsanitize=null` and found and fixed a bunch of other null pointer dereferences. With this,I have run a full bootstrap and tier1 tests with `-fsanitize=null` enabled.
> 
> I have checked that the code generated by GCC is not worse in any significant way, so I don't expect to see any performance regressions.
> 
> I'd like to enable `-fsanitize=null` in debug builds to prevent regressions in this area. What do you think?

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/share/opto/postaloc.cpp
  
  Co-authored-by: Aleksey Shipil?v <shade at redhat.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10920/files
  - new: https://git.openjdk.org/jdk/pull/10920/files/7caa719b..1a12fcb8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10920&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10920&range=10-11

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10920.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10920/head:pull/10920

PR: https://git.openjdk.org/jdk/pull/10920

From eosterlund at openjdk.org  Mon Dec 12 18:02:13 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 12 Dec 2022 18:02:13 GMT
Subject: [jdk20] RFR: 8298084: Memory leak in
 Method::build_profiling_method_data [v3]
In-Reply-To: <yOvhSY98FRUuMUF3vAd0cqG9AWjypujSl-Qy3dpzf2A=.9c2c85cf-699b-4f49-8cdc-9a08a934039b@github.com>
References: <C9g5yB0uAHEc3BUu8JImdl9hOJUqFeDosqrIJWtYOlk=.7b3aea19-771a-4b9d-af5f-2716a2bac11a@github.com>
 <yOvhSY98FRUuMUF3vAd0cqG9AWjypujSl-Qy3dpzf2A=.9c2c85cf-699b-4f49-8cdc-9a08a934039b@github.com>
Message-ID: <Fk-YQHmkkqrjE1rkPHbwe8oV84csqIxiXZcM8UCnOGU=.f20480fb-8d47-4d68-b81b-47c8ef7fc57c@github.com>

On Mon, 12 Dec 2022 17:51:25 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change fixes the MethodData leak by calling the destructor in both the release_C_heap_structures conditionally and by calling the MethodData destructor in the MetadataFactory::free_metadata method.
>> Thanks to @jcking for working on the patch and discussion.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Even more metaprogramming improvements

Looks good.

-------------

Marked as reviewed by eosterlund (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/13

From coleenp at openjdk.org  Mon Dec 12 18:02:59 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 12 Dec 2022 18:02:59 GMT
Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v7]
In-Reply-To: <pRcbuNmrpRkRA8lOJfYlEVWo3W766EMs6Gw5raXbZPs=.66222c03-5a36-43be-a9c9-080d046d73d7@github.com>
References: <Dj9YfY10SLn8dR1Ez3kEQe4tXm1q5W1TS8_4r3gBUsY=.6c38825a-86e5-4575-a509-683786d242a6@github.com>
 <pRcbuNmrpRkRA8lOJfYlEVWo3W766EMs6Gw5raXbZPs=.66222c03-5a36-43be-a9c9-080d046d73d7@github.com>
Message-ID: <lwKPbL65Fiqa0ltWWTC8yJLzRWOGSMwR61Bp1gyBECI=.bd37636f-3ec8-4977-9acc-fb315a93b7b3@github.com>

On Thu, 8 Dec 2022 16:56:40 GMT, Afshin Zafari <duke at openjdk.org> wrote:

>> test of tier1-5 passed.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8292741: Convert JvmtiTagMapTable to ResourceHashtable

I have a couple of minor comments but this looks good.  This hashtable was more problematic to convert so good job!

src/hotspot/share/prims/jvmtiTagMapTable.cpp line 117:

> 115: JvmtiTagMapEntry* JvmtiTagMapTable::find(oop obj) {
> 116:   if (obj->fast_no_hash_check()) {
> 117:     // Objects in the table all have a hashcode.

Can you keep this comment?

src/hotspot/share/prims/jvmtiTagMapTable.hpp line 72:

> 70: typedef
> 71: ResizeableResourceHashtable <JvmtiTagMapKey, jlong,
> 72:                               AnyObj::C_HEAP, mtInternal,

This should be mtServiceability rather than mtInternal.

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11288

From aph at openjdk.org  Mon Dec 12 18:06:11 2022
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 12 Dec 2022 18:06:11 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v9]
In-Reply-To: <Tw4OrgBWFlkJA8XEO_AISZ32ZvpBGUPhsuprtLAoeRY=.a16df657-29b2-4f6a-9601-a6e2540e4c95@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
 <tWNHj4sT_rLcfaX3oyU-NtuCn95s8fkOyQa7opXWipg=.32388fd8-9e32-4aa2-918e-bba26dbeb5b6@github.com>
 <Tw4OrgBWFlkJA8XEO_AISZ32ZvpBGUPhsuprtLAoeRY=.a16df657-29b2-4f6a-9601-a6e2540e4c95@github.com>
Message-ID: <dKrFbcVarO55bh6647Y7jmAVnR70W-RlMrb2prpk-1w=.ee48cdf1-a4b5-464a-a849-98ba4703b124@github.com>

On Mon, 12 Dec 2022 15:41:27 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reviewer feedback
>
> src/hotspot/share/utilities/globalDefinitions_gcc.hpp line 151:
> 
>> 149: #define offset_of(klass,field)                          \
>> 150: []() {                                                  \
>> 151:   char space[sizeof (klass)] ATTRIBUTE_ALIGNED(16);     \
> 
> Is 16 over-aligned on 32bit platforms? Too bad https://git.openjdk.org/jdk/pull/11446 isn't approved yet, else you could use alignas(std::max_align_t). (I wouldn't object if you were forward-looking here, though can't speak for anyone else.)

I'll leave it at 16. This is a bug fix, and I don't want it to have a dependency on [JDK-8297912](https://bugs.openjdk.org/browse/JDK-8297912), a P4 Enhancement.

-------------

PR: https://git.openjdk.org/jdk/pull/10920

From aph at openjdk.org  Mon Dec 12 18:10:02 2022
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 12 Dec 2022 18:10:02 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v13]
In-Reply-To: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
Message-ID: <prn6Lx2d7rj6zcQfeyHwHuqlOe4qGM_KkorFM2bjey8=.ceaccb88-8d45-4ae8-8170-df8319cde58f@github.com>

> This patch fixes the remaining null pointer dereference bugs that I know of.
> 
> For the main bug, C2 was using a null reference to indicate an uninitialized `Node_List`. I replaced the null reference with a static sentinel.
> 
> I also turned on `-fsanitize=null` and found and fixed a bunch of other null pointer dereferences. With this,I have run a full bootstrap and tier1 tests with `-fsanitize=null` enabled.
> 
> I have checked that the code generated by GCC is not worse in any significant way, so I don't expect to see any performance regressions.
> 
> I'd like to enable `-fsanitize=null` in debug builds to prevent regressions in this area. What do you think?

Andrew Haley has updated the pull request incrementally with two additional commits since the last revision:

 - Merge branch 'JDK-8294902' of https://github.com/theRealAph/jdk into JDK-8294902
 - Reviewer feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10920/files
  - new: https://git.openjdk.org/jdk/pull/10920/files/1a12fcb8..033dfa0a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10920&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10920&range=11-12

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10920.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10920/head:pull/10920

PR: https://git.openjdk.org/jdk/pull/10920

From coleenp at openjdk.org  Mon Dec 12 18:15:04 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 12 Dec 2022 18:15:04 GMT
Subject: [jdk20] RFR: 8298084: Memory leak in
 Method::build_profiling_method_data [v3]
In-Reply-To: <yOvhSY98FRUuMUF3vAd0cqG9AWjypujSl-Qy3dpzf2A=.9c2c85cf-699b-4f49-8cdc-9a08a934039b@github.com>
References: <C9g5yB0uAHEc3BUu8JImdl9hOJUqFeDosqrIJWtYOlk=.7b3aea19-771a-4b9d-af5f-2716a2bac11a@github.com>
 <yOvhSY98FRUuMUF3vAd0cqG9AWjypujSl-Qy3dpzf2A=.9c2c85cf-699b-4f49-8cdc-9a08a934039b@github.com>
Message-ID: <yJCSZ6JidFosaV5QLzItIgveE1SBt418tgvnlGVg50U=.cce415f8-7c3b-4efc-9d43-71d2b953ba12@github.com>

On Mon, 12 Dec 2022 17:51:25 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change fixes the MethodData leak by calling the destructor in both the release_C_heap_structures conditionally and by calling the MethodData destructor in the MetadataFactory::free_metadata method.
>> Thanks to @jcking for working on the patch and discussion.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Even more metaprogramming improvements

Thanks Erik and Kim.  @TobiHartmann and @jcking, do you want to review?

-------------

PR: https://git.openjdk.org/jdk20/pull/13

From aph at openjdk.org  Mon Dec 12 18:27:29 2022
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 12 Dec 2022 18:27:29 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v14]
In-Reply-To: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
Message-ID: <6ZFPsfu99pGTcTnnIhx1JnTqbUliCRBibiWSCLCKKH0=.37d10ce4-9db8-49c5-b9d8-5865e466171a@github.com>

> This patch fixes the remaining null pointer dereference bugs that I know of.
> 
> For the main bug, C2 was using a null reference to indicate an uninitialized `Node_List`. I replaced the null reference with a static sentinel.
> 
> I also turned on `-fsanitize=null` and found and fixed a bunch of other null pointer dereferences. With this,I have run a full bootstrap and tier1 tests with `-fsanitize=null` enabled.
> 
> I have checked that the code generated by GCC is not worse in any significant way, so I don't expect to see any performance regressions.
> 
> I'd like to enable `-fsanitize=null` in debug builds to prevent regressions in this area. What do you think?

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Reviewer feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10920/files
  - new: https://git.openjdk.org/jdk/pull/10920/files/033dfa0a..6460847c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10920&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10920&range=12-13

  Stats: 12 lines in 2 files changed: 5 ins; 6 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10920.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10920/head:pull/10920

PR: https://git.openjdk.org/jdk/pull/10920

From kbarrett at openjdk.org  Mon Dec 12 18:27:31 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 12 Dec 2022 18:27:31 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v9]
In-Reply-To: <dKrFbcVarO55bh6647Y7jmAVnR70W-RlMrb2prpk-1w=.ee48cdf1-a4b5-464a-a849-98ba4703b124@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
 <tWNHj4sT_rLcfaX3oyU-NtuCn95s8fkOyQa7opXWipg=.32388fd8-9e32-4aa2-918e-bba26dbeb5b6@github.com>
 <Tw4OrgBWFlkJA8XEO_AISZ32ZvpBGUPhsuprtLAoeRY=.a16df657-29b2-4f6a-9601-a6e2540e4c95@github.com>
 <dKrFbcVarO55bh6647Y7jmAVnR70W-RlMrb2prpk-1w=.ee48cdf1-a4b5-464a-a849-98ba4703b124@github.com>
Message-ID: <m16gERNrRXlkPysPYiuZOTnReOtwYxTPwrWfWAcrIl8=.d9511de2-7a3d-4cc9-9288-777369e8f81d@github.com>

On Mon, 12 Dec 2022 18:03:35 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> src/hotspot/share/utilities/globalDefinitions_gcc.hpp line 151:
>> 
>>> 149: #define offset_of(klass,field)                          \
>>> 150: []() {                                                  \
>>> 151:   char space[sizeof (klass)] ATTRIBUTE_ALIGNED(16);     \
>> 
>> Is 16 over-aligned on 32bit platforms? Too bad https://git.openjdk.org/jdk/pull/11446 isn't approved yet, else you could use alignas(std::max_align_t). (I wouldn't object if you were forward-looking here, though can't speak for anyone else.)
>
> I'll leave it at 16. This is a bug fix, and I don't want it to have a dependency on [JDK-8297912](https://bugs.openjdk.org/browse/JDK-8297912), a P4 Enhancement.

OK.

-------------

PR: https://git.openjdk.org/jdk/pull/10920

From kbarrett at openjdk.org  Mon Dec 12 18:27:33 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 12 Dec 2022 18:27:33 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v13]
In-Reply-To: <prn6Lx2d7rj6zcQfeyHwHuqlOe4qGM_KkorFM2bjey8=.ceaccb88-8d45-4ae8-8170-df8319cde58f@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
 <prn6Lx2d7rj6zcQfeyHwHuqlOe4qGM_KkorFM2bjey8=.ceaccb88-8d45-4ae8-8170-df8319cde58f@github.com>
Message-ID: <bHmaI0WpClOqz2sxiJyAr3KKXhS2gkuDgCVCtdf9Mhw=.9aed0c82-d62c-4f8a-8366-d0cb904b5c4c@github.com>

On Mon, 12 Dec 2022 18:10:02 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This patch fixes the remaining null pointer dereference bugs that I know of.
>> 
>> For the main bug, C2 was using a null reference to indicate an uninitialized `Node_List`. I replaced the null reference with a static sentinel.
>> 
>> I also turned on `-fsanitize=null` and found and fixed a bunch of other null pointer dereferences. With this,I have run a full bootstrap and tier1 tests with `-fsanitize=null` enabled.
>> 
>> I have checked that the code generated by GCC is not worse in any significant way, so I don't expect to see any performance regressions.
>> 
>> I'd like to enable `-fsanitize=null` in debug builds to prevent regressions in this area. What do you think?
>
> Andrew Haley has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'JDK-8294902' of https://github.com/theRealAph/jdk into JDK-8294902
>  - Reviewer feedback

src/hotspot/share/utilities/globalDefinitions_gcc.hpp line 178:

> 176: // Converts any type T to a reference type.
> 177: template<typename T>
> 178: std::add_rvalue_reference_t<T> declval() noexcept;

Why is this in the gcc-specific file?  How can this even work? The use in vmStructs.cpp is in shared code.

-------------

PR: https://git.openjdk.org/jdk/pull/10920

From aph at openjdk.org  Mon Dec 12 18:27:34 2022
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 12 Dec 2022 18:27:34 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v13]
In-Reply-To: <bHmaI0WpClOqz2sxiJyAr3KKXhS2gkuDgCVCtdf9Mhw=.9aed0c82-d62c-4f8a-8366-d0cb904b5c4c@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
 <prn6Lx2d7rj6zcQfeyHwHuqlOe4qGM_KkorFM2bjey8=.ceaccb88-8d45-4ae8-8170-df8319cde58f@github.com>
 <bHmaI0WpClOqz2sxiJyAr3KKXhS2gkuDgCVCtdf9Mhw=.9aed0c82-d62c-4f8a-8366-d0cb904b5c4c@github.com>
Message-ID: <JojoTpzEavH5BkCqD6rzG7K9xvPKtzWs5xzaSxTb2Ck=.856e7d0b-c5fa-44ee-b6a2-02b3ac4e5d1a@github.com>

On Mon, 12 Dec 2022 18:20:03 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Andrew Haley has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge branch 'JDK-8294902' of https://github.com/theRealAph/jdk into JDK-8294902
>>  - Reviewer feedback
>
> src/hotspot/share/utilities/globalDefinitions_gcc.hpp line 178:
> 
>> 176: // Converts any type T to a reference type.
>> 177: template<typename T>
>> 178: std::add_rvalue_reference_t<T> declval() noexcept;
> 
> Why is this in the gcc-specific file?  How can this even work? The use in vmStructs.cpp is in shared code.

Oh, I pushed an incomplete change, sorry. I'm done now.

-------------

PR: https://git.openjdk.org/jdk/pull/10920

From aph at openjdk.org  Mon Dec 12 18:34:42 2022
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 12 Dec 2022 18:34:42 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v15]
In-Reply-To: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
Message-ID: <z-p8OebTt3P2y3PnKDuuDnuQJu5TPleYh8SJYs3YCFY=.3accd113-8b1c-4c79-9d7f-93ccf40750f3@github.com>

> This patch fixes the remaining null pointer dereference bugs that I know of.
> 
> For the main bug, C2 was using a null reference to indicate an uninitialized `Node_List`. I replaced the null reference with a static sentinel.
> 
> I also turned on `-fsanitize=null` and found and fixed a bunch of other null pointer dereferences. With this,I have run a full bootstrap and tier1 tests with `-fsanitize=null` enabled.
> 
> I have checked that the code generated by GCC is not worse in any significant way, so I don't expect to see any performance regressions.
> 
> I'd like to enable `-fsanitize=null` in debug builds to prevent regressions in this area. What do you think?

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Whitespace

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10920/files
  - new: https://git.openjdk.org/jdk/pull/10920/files/6460847c..1682381c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10920&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10920&range=13-14

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10920.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10920/head:pull/10920

PR: https://git.openjdk.org/jdk/pull/10920

From aph at openjdk.org  Mon Dec 12 18:44:22 2022
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 12 Dec 2022 18:44:22 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v16]
In-Reply-To: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
Message-ID: <42H7oL49YA3VoxBr4RPfZT5f3v6AeEgV0iGmXx63UnQ=.eb518482-1142-4db5-b560-6ebeab613d9c@github.com>

> This patch fixes the remaining null pointer dereference bugs that I know of.
> 
> For the main bug, C2 was using a null reference to indicate an uninitialized `Node_List`. I replaced the null reference with a static sentinel.
> 
> I also turned on `-fsanitize=null` and found and fixed a bunch of other null pointer dereferences. With this,I have run a full bootstrap and tier1 tests with `-fsanitize=null` enabled.
> 
> I have checked that the code generated by GCC is not worse in any significant way, so I don't expect to see any performance regressions.
> 
> I'd like to enable `-fsanitize=null` in debug builds to prevent regressions in this area. What do you think?

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Typo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10920/files
  - new: https://git.openjdk.org/jdk/pull/10920/files/1682381c..1d42c92e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10920&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10920&range=14-15

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10920.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10920/head:pull/10920

PR: https://git.openjdk.org/jdk/pull/10920

From kbarrett at openjdk.org  Mon Dec 12 18:48:47 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 12 Dec 2022 18:48:47 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v16]
In-Reply-To: <42H7oL49YA3VoxBr4RPfZT5f3v6AeEgV0iGmXx63UnQ=.eb518482-1142-4db5-b560-6ebeab613d9c@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
 <42H7oL49YA3VoxBr4RPfZT5f3v6AeEgV0iGmXx63UnQ=.eb518482-1142-4db5-b560-6ebeab613d9c@github.com>
Message-ID: <L_ddfvScPXkAoW-BuT_ZfHPGMiRbYKzvy5iw3EsrrWM=.9c436d53-64b2-42a1-ade0-6bea54a5791e@github.com>

On Mon, 12 Dec 2022 18:44:22 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This patch fixes the remaining null pointer dereference bugs that I know of.
>> 
>> For the main bug, C2 was using a null reference to indicate an uninitialized `Node_List`. I replaced the null reference with a static sentinel.
>> 
>> I also turned on `-fsanitize=null` and found and fixed a bunch of other null pointer dereferences. With this,I have run a full bootstrap and tier1 tests with `-fsanitize=null` enabled.
>> 
>> I have checked that the code generated by GCC is not worse in any significant way, so I don't expect to see any performance regressions.
>> 
>> I'd like to enable `-fsanitize=null` in debug builds to prevent regressions in this area. What do you think?
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Typo

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10920

From kbarrett at openjdk.org  Mon Dec 12 18:51:05 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 12 Dec 2022 18:51:05 GMT
Subject: RFR: 8293824: gc/whitebox/TestConcMarkCycleWB.java failed
 "RuntimeException: assertTrue: expected true, was false" [v2]
In-Reply-To: <vnO8v_f4KLL9qTzDU9tRK9fGbiHpQNJA81CWItvRljA=.356b8790-4f88-47fb-9ed4-4fcd0c9ce780@github.com>
References: <74AnEqLugaEU80XMNm8edtWBmK8gOFMirnZT1rdj1jI=.6ab039c0-3db5-4336-9aa7-867166b79cda@github.com>
 <dM4t6tEt_ECKHylcGy7v2lL8FOXa1j336ycPFt07Jnc=.1b984fe9-d268-4384-85d9-0984fff815a6@github.com>
 <vnO8v_f4KLL9qTzDU9tRK9fGbiHpQNJA81CWItvRljA=.356b8790-4f88-47fb-9ed4-4fcd0c9ce780@github.com>
Message-ID: <ULTmQvkm4nJs3nLAFKMLXAj4YPnQAPsk1avIKB9SfPo=.a1976321-c1eb-40d6-9458-1918135796c8@github.com>

On Mon, 12 Dec 2022 17:44:12 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
>> 
>>  - use new whitebox api for running conc gc
>>  - Merge branch 'master' into test-concmark
>>  - copyrights
>>  - remove WB.g1StartConcMarkCyle
>>  - update tests
>>  - add utility GC breakpoint functions
>>  - add G1ConcurrentMark::completed_mark_cycles() and whitebox access
>
> test/lib/jdk/test/whitebox/WhiteBox.java line 177:
> 
>> 175:   // successful (e.g. it was aborted), then throws RuntimeException if
>> 176:   // errorIfFail is true, returning false otherwise.
>> 177:   public boolean g1RunConcurrentGC(boolean errorIfFail) {
> 
> Failure detection as described in the comment above is turned off for all test cases. Please verify if that is intentional.

Drat!  That's NOT intentional.  Fixing and retesting now.  Thanks for spotting it.

-------------

PR: https://git.openjdk.org/jdk/pull/11435

From kvn at openjdk.org  Mon Dec 12 21:26:57 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 12 Dec 2022 21:26:57 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v16]
In-Reply-To: <42H7oL49YA3VoxBr4RPfZT5f3v6AeEgV0iGmXx63UnQ=.eb518482-1142-4db5-b560-6ebeab613d9c@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
 <42H7oL49YA3VoxBr4RPfZT5f3v6AeEgV0iGmXx63UnQ=.eb518482-1142-4db5-b560-6ebeab613d9c@github.com>
Message-ID: <rSGqFZiorVEHnqesYHl_hK2P7VKl-CCYosF66npMVQw=.0f15ba50-5c48-43d3-9271-460b0638b95f@github.com>

On Mon, 12 Dec 2022 18:44:22 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This patch fixes the remaining null pointer dereference bugs that I know of.
>> 
>> For the main bug, C2 was using a null reference to indicate an uninitialized `Node_List`. I replaced the null reference with a static sentinel.
>> 
>> I also turned on `-fsanitize=null` and found and fixed a bunch of other null pointer dereferences. With this,I have run a full bootstrap and tier1 tests with `-fsanitize=null` enabled.
>> 
>> I have checked that the code generated by GCC is not worse in any significant way, so I don't expect to see any performance regressions.
>> 
>> I'd like to enable `-fsanitize=null` in debug builds to prevent regressions in this area. What do you think?
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Typo

Let me test the latest version before you push.

-------------

PR: https://git.openjdk.org/jdk/pull/10920

From dcubed at openjdk.org  Mon Dec 12 21:46:49 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 12 Dec 2022 21:46:49 GMT
Subject: [jdk20] RFR: 8296955: Kitchensink.java failed with
 "double free or corruption (!prev): <addr>"
In-Reply-To: <-rew__nvw1aQv6-lfTVkU-DGA_rjP4JypTsIj2ozblI=.21be566f-c364-4537-86b6-35e7d12e3e4e@github.com>
References: <-rew__nvw1aQv6-lfTVkU-DGA_rjP4JypTsIj2ozblI=.21be566f-c364-4537-86b6-35e7d12e3e4e@github.com>
Message-ID: <Y1CIBeqQG_HJQ48fczAu9HGs7Wg11RcIWU9trlYZJuM=.a3d069dc-c594-4024-a994-d1d42c555ce3@github.com>

On Fri, 9 Dec 2022 12:27:42 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Thanks to Kim for the diagnosis of this problem.  G1 cleans up nmethods in parallel threads during a safepoint and may post or queue unload events to be posted.  The event posting creates jmethodIDs.  The jmethodID code assumes that it's thread safe in a safepoint, which it is not.
> I removed this optimization, which isn't much of an optimization (did run some sanity performance tests) and is unsafe in the modern code.
> Tested with tier1-7, where tier5 found the original bug.

Thumbs up. The 'load_data' -> 'cld' changes were distracting, but then I saw
that the functions had this:

void Method::foo_method(ClassLoaderData* loader_data, ...
  ClassLoaderData* cld = loader_data;

And I can't remember why we did that so very long ago...

Thanks for including the testing info!!

This pattern:

    if (Threads::number_of_threads() == 0 ||
        SafepointSynchronize::is_at_safepoint()) {

is common in JVM/TI code as a way to determine if it is "safe"
to do something without a lock. We probably need to audit the
uses of that pattern and see if there's anything else that has to
be updated in the face of more parallelism during safepoints.

src/hotspot/share/oops/method.cpp line 2185:

> 2183:   // Also have to add the method to the list safely, which the lock
> 2184:   // protects as well.
> 2185:   assert(JmethodIdCreation_lock->owned_by_self(), "sanity check");

I jeep going back and forth about changing this from `assert` to
`guarantee` for at least a few complete test cycles. However, we
are post code fork so it would be difficult to justify switching it
back in 3 or so builds. Switching to a `guarantee` would also
mean another round of perf testing and I don't want you to have
to do that either.

I'll keep my eyes open on the two CIs...

-------------

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/10

From dcubed at openjdk.org  Mon Dec 12 21:46:49 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 12 Dec 2022 21:46:49 GMT
Subject: [jdk20] RFR: 8296955: Kitchensink.java failed with
 "double free or corruption (!prev): <addr>"
In-Reply-To: <rqYi7166vpuLC2mBSn-CHvJG_bTROvw8LalGL7f2Vcs=.7ff38c80-91f4-4a92-80e6-a1a4e24b6a15@github.com>
References: <-rew__nvw1aQv6-lfTVkU-DGA_rjP4JypTsIj2ozblI=.21be566f-c364-4537-86b6-35e7d12e3e4e@github.com>
 <rqYi7166vpuLC2mBSn-CHvJG_bTROvw8LalGL7f2Vcs=.7ff38c80-91f4-4a92-80e6-a1a4e24b6a15@github.com>
Message-ID: <10MPZc9xD1DZlYbupLeXTiVbSTNcRbOf5-uDp4F9HAI=.0b25417e-9a7c-4fd3-bd1e-d11e61a94167@github.com>

On Sat, 10 Dec 2022 16:31:57 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Thanks to Kim for the diagnosis of this problem.  G1 cleans up nmethods in parallel threads during a safepoint and may post or queue unload events to be posted.  The event posting creates jmethodIDs.  The jmethodID code assumes that it's thread safe in a safepoint, which it is not.
>> I removed this optimization, which isn't much of an optimization (did run some sanity performance tests) and is unsafe in the modern code.
>> Tested with tier1-7, where tier5 found the original bug.
>
> Looks good.

@kimbarrett , @fisk, @sspitsyn and @coleenp - It is nice to see so many
reviewers on a post-code fork fix!

-------------

PR: https://git.openjdk.org/jdk20/pull/10

From dholmes at openjdk.org  Tue Dec 13 00:05:01 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 13 Dec 2022 00:05:01 GMT
Subject: RFR: 8292674: ReportJNIFatalError should print all java frames
 [v4]
In-Reply-To: <uUWb1njnLGXpTVPEx-n4QElmN9urKxquYk2n0TcaMVg=.221b1735-4325-4aae-91f5-2ba1b832ff58@github.com>
References: <-ipNtt5PSZ2d7VUBSoduPyNwnW2GeN_y0Dcs95qI8HU=.c4771172-01dd-49ae-8f4a-9d5cbd6c6dad@github.com>
 <uUWb1njnLGXpTVPEx-n4QElmN9urKxquYk2n0TcaMVg=.221b1735-4325-4aae-91f5-2ba1b832ff58@github.com>
Message-ID: <0bxcqJMIblj-wZzb98N8m0ETQuz0WILUhd1UjHsdgJc=.2699d1df-2111-417d-bc60-1ba19fef7e3b@github.com>

On Fri, 9 Dec 2022 01:53:40 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> When JNI reports errors and warnings and produces a stack trace, we need to see the exact Java code that was being executed. The existing `JavaThread::print_stack` that is used is only for platform/carrier threads and doesn't show any mounted virtual thread. So we introduce a new `JavaThread::print_virtual_stack_on` method to print the mounted virtual thread's stack, and we add `JavaThread::print_jni_stack` as a utility for JNI to call that dispatches to the appropriate function based on the thread type.
>> 
>> The existing test `hotspot/jtreg/runtime/jni/checked/TestPrimitiveArrayCriticalWithBadParam.java` was modified to test regular and virtual threads, and to expect to see the specific stack frame of the Java native method.
>> 
>> Additional manual testing of the JNI `FatalError` method was done by direct fault injection in modified JDK code.
>> 
>> Sanity testing: Oracle tiers 1-4 (to include our -Xcheck:jni run in tier4)
>> 
>> Thanks,
>> David
>
> David Holmes 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 four additional commits since the last revision:
> 
>  - Merge branch 'master' into 8292674-ReportJNIFatalError-v2
>  - Merge branch 'master' into 8292674-ReportJNIFatalError-v2
>  - Changed RegisterMap to include process_frame and update, for object monitor examination.
>    Updated stack printing for exception checks.
>  - 8292674: ReportJNIFatalError should print all java frames

Seems Robbin is not around.

-------------

PR: https://git.openjdk.org/jdk/pull/11503

From dholmes at openjdk.org  Tue Dec 13 00:08:50 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 13 Dec 2022 00:08:50 GMT
Subject: Integrated: 8292674: ReportJNIFatalError should print all java frames
In-Reply-To: <-ipNtt5PSZ2d7VUBSoduPyNwnW2GeN_y0Dcs95qI8HU=.c4771172-01dd-49ae-8f4a-9d5cbd6c6dad@github.com>
References: <-ipNtt5PSZ2d7VUBSoduPyNwnW2GeN_y0Dcs95qI8HU=.c4771172-01dd-49ae-8f4a-9d5cbd6c6dad@github.com>
Message-ID: <2MTeFBjfpLtU7-0ftBil-VT_6QyXGmfo8nWjqHa-Rjs=.f36137dc-5bba-4812-ace8-ead8a9218ed6@github.com>

On Mon, 5 Dec 2022 06:58:32 GMT, David Holmes <dholmes at openjdk.org> wrote:

> When JNI reports errors and warnings and produces a stack trace, we need to see the exact Java code that was being executed. The existing `JavaThread::print_stack` that is used is only for platform/carrier threads and doesn't show any mounted virtual thread. So we introduce a new `JavaThread::print_virtual_stack_on` method to print the mounted virtual thread's stack, and we add `JavaThread::print_jni_stack` as a utility for JNI to call that dispatches to the appropriate function based on the thread type.
> 
> The existing test `hotspot/jtreg/runtime/jni/checked/TestPrimitiveArrayCriticalWithBadParam.java` was modified to test regular and virtual threads, and to expect to see the specific stack frame of the Java native method.
> 
> Additional manual testing of the JNI `FatalError` method was done by direct fault injection in modified JDK code.
> 
> Sanity testing: Oracle tiers 1-4 (to include our -Xcheck:jni run in tier4)
> 
> Thanks,
> David

This pull request has now been integrated.

Changeset: 829cbc2c
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/829cbc2cb16cfe4ad23df934768cb820e79511d8
Stats:     96 lines in 6 files changed: 79 ins; 3 del; 14 mod

8292674: ReportJNIFatalError should print all java frames

Reviewed-by: pchilanomate

-------------

PR: https://git.openjdk.org/jdk/pull/11503

From dholmes at openjdk.org  Tue Dec 13 00:19:08 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 13 Dec 2022 00:19:08 GMT
Subject: [jdk20] RFR: 8298084: Memory leak in
 Method::build_profiling_method_data [v3]
In-Reply-To: <yOvhSY98FRUuMUF3vAd0cqG9AWjypujSl-Qy3dpzf2A=.9c2c85cf-699b-4f49-8cdc-9a08a934039b@github.com>
References: <C9g5yB0uAHEc3BUu8JImdl9hOJUqFeDosqrIJWtYOlk=.7b3aea19-771a-4b9d-af5f-2716a2bac11a@github.com>
 <yOvhSY98FRUuMUF3vAd0cqG9AWjypujSl-Qy3dpzf2A=.9c2c85cf-699b-4f49-8cdc-9a08a934039b@github.com>
Message-ID: <oD-YnjsN14b4ogxrRFd4_YOwGohga9PMXH9GRmph8uQ=.5d7f1ebd-2455-4c42-8522-8c43e88b7598@github.com>

On Mon, 12 Dec 2022 17:51:25 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change fixes the MethodData leak by calling the destructor in both the release_C_heap_structures conditionally and by calling the MethodData destructor in the MetadataFactory::free_metadata method.
>> Thanks to @jcking for working on the patch and discussion.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Even more metaprogramming improvements

Not sure about some of the incidental changes - see below.

Thanks.

src/hotspot/share/memory/metadataFactory.hpp line 77:

> 75:       // destructors and/or cleanup using deallocate_contents.
> 76:       // T is a potentially const or volatile qualified pointer. Remove the pointer and any const
> 77:       // or volatile so we can call the destructor of the type T points to.

Comment needs updating now you don't need to remove the pointer.

src/hotspot/share/oops/instanceKlass.cpp line 2675:

> 2673:   if (release_sub_metadata) {
> 2674:     methods_do(method_release_C_heap_structures);
> 2675:   }

I don't understand this aspect of the change. It seems unrelated to the missing destructor issue and seems to cause a significant change in behaviour as we will no longer call `methods_do` when called from `deallocate_contents` with the renamed `false` argument.

-------------

PR: https://git.openjdk.org/jdk20/pull/13

From dholmes at openjdk.org  Tue Dec 13 00:34:53 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 13 Dec 2022 00:34:53 GMT
Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v7]
In-Reply-To: <pRcbuNmrpRkRA8lOJfYlEVWo3W766EMs6Gw5raXbZPs=.66222c03-5a36-43be-a9c9-080d046d73d7@github.com>
References: <Dj9YfY10SLn8dR1Ez3kEQe4tXm1q5W1TS8_4r3gBUsY=.6c38825a-86e5-4575-a509-683786d242a6@github.com>
 <pRcbuNmrpRkRA8lOJfYlEVWo3W766EMs6Gw5raXbZPs=.66222c03-5a36-43be-a9c9-080d046d73d7@github.com>
Message-ID: <YRrS4EsSvEa_A6-bUg-E5YlvH40a_nkGCoXpelgaB4Q=.1607e6fc-3e91-4944-a50b-c860689147dc@github.com>

On Thu, 8 Dec 2022 16:56:40 GMT, Afshin Zafari <duke at openjdk.org> wrote:

>> test of tier1-5 passed.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8292741: Convert JvmtiTagMapTable to ResourceHashtable

The alternative to force-push would have been just to create a new PR.

-------------

PR: https://git.openjdk.org/jdk/pull/11288

From coleenp at openjdk.org  Tue Dec 13 00:51:28 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 13 Dec 2022 00:51:28 GMT
Subject: [jdk20] RFR: 8296955: Kitchensink.java failed with
 "double free or corruption (!prev): <addr>"
In-Reply-To: <10MPZc9xD1DZlYbupLeXTiVbSTNcRbOf5-uDp4F9HAI=.0b25417e-9a7c-4fd3-bd1e-d11e61a94167@github.com>
References: <-rew__nvw1aQv6-lfTVkU-DGA_rjP4JypTsIj2ozblI=.21be566f-c364-4537-86b6-35e7d12e3e4e@github.com>
 <rqYi7166vpuLC2mBSn-CHvJG_bTROvw8LalGL7f2Vcs=.7ff38c80-91f4-4a92-80e6-a1a4e24b6a15@github.com>
 <10MPZc9xD1DZlYbupLeXTiVbSTNcRbOf5-uDp4F9HAI=.0b25417e-9a7c-4fd3-bd1e-d11e61a94167@github.com>
Message-ID: <Tahljd2qC2BNw_8Femp280mdcA7jDbrdcLPdwSwM-HI=.218db3ef-84b7-47e0-b9ad-3afaffc877d3@github.com>

On Mon, 12 Dec 2022 21:44:08 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Looks good.
>
> @kimbarrett , @fisk, @sspitsyn and @coleenp - It is nice to see so many
> reviewers on a post-code fork fix!

Thanks for looking at this @dcubed-ojdk .  I agree we should audit code that thinks operations are safe at a safepoint but might not be.  Thanks for the code review.

-------------

PR: https://git.openjdk.org/jdk20/pull/10

From coleenp at openjdk.org  Tue Dec 13 00:51:30 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 13 Dec 2022 00:51:30 GMT
Subject: [jdk20] RFR: 8296955: Kitchensink.java failed with
 "double free or corruption (!prev): <addr>"
In-Reply-To: <Y1CIBeqQG_HJQ48fczAu9HGs7Wg11RcIWU9trlYZJuM=.a3d069dc-c594-4024-a994-d1d42c555ce3@github.com>
References: <-rew__nvw1aQv6-lfTVkU-DGA_rjP4JypTsIj2ozblI=.21be566f-c364-4537-86b6-35e7d12e3e4e@github.com>
 <Y1CIBeqQG_HJQ48fczAu9HGs7Wg11RcIWU9trlYZJuM=.a3d069dc-c594-4024-a994-d1d42c555ce3@github.com>
Message-ID: <pjPUurKASwljCvXNmo7XU6H7iX54ZKAZAA-M3ePW5Yo=.8a286ac1-ee16-472a-94bf-6e061389a9ad@github.com>

On Mon, 12 Dec 2022 21:42:22 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Thanks to Kim for the diagnosis of this problem.  G1 cleans up nmethods in parallel threads during a safepoint and may post or queue unload events to be posted.  The event posting creates jmethodIDs.  The jmethodID code assumes that it's thread safe in a safepoint, which it is not.
>> I removed this optimization, which isn't much of an optimization (did run some sanity performance tests) and is unsafe in the modern code.
>> Tested with tier1-7, where tier5 found the original bug.
>
> src/hotspot/share/oops/method.cpp line 2185:
> 
>> 2183:   // Also have to add the method to the list safely, which the lock
>> 2184:   // protects as well.
>> 2185:   assert(JmethodIdCreation_lock->owned_by_self(), "sanity check");
> 
> I keep going back and forth about changing this from `assert` to
> `guarantee` for at least a few complete test cycles. However, we
> are post code fork so it would be difficult to justify switching it
> back in 3 or so builds. Switching to a `guarantee` would also
> mean another round of perf testing and I don't want you to have
> to do that either.
> 
> I'll keep my eyes open on the two CIs...

Yes, thanks I don't usually use guarantees and as you said, it's late in the testing cycle.  Thanks for keeping an eye on it.

-------------

PR: https://git.openjdk.org/jdk20/pull/10

From coleenp at openjdk.org  Tue Dec 13 00:53:31 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 13 Dec 2022 00:53:31 GMT
Subject: [jdk20] Integrated: 8296955: Kitchensink.java failed with
 "double free or corruption (!prev): <addr>"
In-Reply-To: <-rew__nvw1aQv6-lfTVkU-DGA_rjP4JypTsIj2ozblI=.21be566f-c364-4537-86b6-35e7d12e3e4e@github.com>
References: <-rew__nvw1aQv6-lfTVkU-DGA_rjP4JypTsIj2ozblI=.21be566f-c364-4537-86b6-35e7d12e3e4e@github.com>
Message-ID: <G_whr3tJ1xWwk2-IOK6NcAs0rV9PjHbreaiTdrNrGUQ=.f5983e00-fc6c-465b-ab43-1580ebf14c3e@github.com>

On Fri, 9 Dec 2022 12:27:42 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Thanks to Kim for the diagnosis of this problem.  G1 cleans up nmethods in parallel threads during a safepoint and may post or queue unload events to be posted.  The event posting creates jmethodIDs.  The jmethodID code assumes that it's thread safe in a safepoint, which it is not.
> I removed this optimization, which isn't much of an optimization (did run some sanity performance tests) and is unsafe in the modern code.
> Tested with tier1-7, where tier5 found the original bug.

This pull request has now been integrated.

Changeset: d4531903
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/d4531903007dbe8dcdd163e423d23e8cefba61c8
Stats:     89 lines in 3 files changed: 14 ins; 50 del; 25 mod

8296955: Kitchensink.java failed with "double free or corruption (!prev): <addr>"

Reviewed-by: kbarrett, eosterlund, sspitsyn, dcubed

-------------

PR: https://git.openjdk.org/jdk20/pull/10

From coleenp at openjdk.org  Tue Dec 13 00:54:06 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 13 Dec 2022 00:54:06 GMT
Subject: [jdk20] RFR: 8298084: Memory leak in
 Method::build_profiling_method_data [v3]
In-Reply-To: <oD-YnjsN14b4ogxrRFd4_YOwGohga9PMXH9GRmph8uQ=.5d7f1ebd-2455-4c42-8522-8c43e88b7598@github.com>
References: <C9g5yB0uAHEc3BUu8JImdl9hOJUqFeDosqrIJWtYOlk=.7b3aea19-771a-4b9d-af5f-2716a2bac11a@github.com>
 <yOvhSY98FRUuMUF3vAd0cqG9AWjypujSl-Qy3dpzf2A=.9c2c85cf-699b-4f49-8cdc-9a08a934039b@github.com>
 <oD-YnjsN14b4ogxrRFd4_YOwGohga9PMXH9GRmph8uQ=.5d7f1ebd-2455-4c42-8522-8c43e88b7598@github.com>
Message-ID: <w03IA2IehVFL1QMv9DNmfj84WYh8PDIeHMJiNfgYM_8=.f0b141d0-e6c6-4a3d-8c9d-50b7849f3144@github.com>

On Tue, 13 Dec 2022 00:10:16 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Even more metaprogramming improvements
>
> src/hotspot/share/memory/metadataFactory.hpp line 77:
> 
>> 75:       // destructors and/or cleanup using deallocate_contents.
>> 76:       // T is a potentially const or volatile qualified pointer. Remove the pointer and any const
>> 77:       // or volatile so we can call the destructor of the type T points to.
> 
> Comment needs updating now you don't need to remove the pointer.

Fixed.  Thanks for catching that.

-------------

PR: https://git.openjdk.org/jdk20/pull/13

From coleenp at openjdk.org  Tue Dec 13 00:58:40 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 13 Dec 2022 00:58:40 GMT
Subject: [jdk20] RFR: 8298084: Memory leak in
 Method::build_profiling_method_data [v3]
In-Reply-To: <oD-YnjsN14b4ogxrRFd4_YOwGohga9PMXH9GRmph8uQ=.5d7f1ebd-2455-4c42-8522-8c43e88b7598@github.com>
References: <C9g5yB0uAHEc3BUu8JImdl9hOJUqFeDosqrIJWtYOlk=.7b3aea19-771a-4b9d-af5f-2716a2bac11a@github.com>
 <yOvhSY98FRUuMUF3vAd0cqG9AWjypujSl-Qy3dpzf2A=.9c2c85cf-699b-4f49-8cdc-9a08a934039b@github.com>
 <oD-YnjsN14b4ogxrRFd4_YOwGohga9PMXH9GRmph8uQ=.5d7f1ebd-2455-4c42-8522-8c43e88b7598@github.com>
Message-ID: <mzIUiE1mp8oqfdmKHPzf_H-ccB11q3nRUUVrM2B048c=.bb4a05a9-3065-45bb-bceb-0d56132bd5e7@github.com>

On Tue, 13 Dec 2022 00:13:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Even more metaprogramming improvements
>
> src/hotspot/share/oops/instanceKlass.cpp line 2675:
> 
>> 2673:   if (release_sub_metadata) {
>> 2674:     methods_do(method_release_C_heap_structures);
>> 2675:   }
> 
> I don't understand this aspect of the change. It seems unrelated to the missing destructor issue and seems to cause a significant change in behaviour as we will no longer call `methods_do` when called from `deallocate_contents` with the renamed `false` argument.

This boolean prevents us from calling the MethodData destructor twice and releasing MethodData C heap memory twice.  InstanceKlass::deallocate_contents calls release_C_heap_structures with it false, and then calls through the Metadata pointer hierarchy to MetadataFactory::free_metadata, which calls the MethodData destructor and MethodData::deallocate_contents which calls MethodData::release_C_heap_structures().   This is the delegation scheme for releasing metadata between InstanceKlass and ConstantPool.

InstanceKlass::release_C_heap_structures() is also called during class unloading and must walk the whole metadata, releasing C heap memory.  It's passed true. It doesn't go through deallocate_contents because the metadata is freed together at the same time with the metaspace that contains it.

-------------

PR: https://git.openjdk.org/jdk20/pull/13

From dholmes at openjdk.org  Tue Dec 13 01:19:35 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 13 Dec 2022 01:19:35 GMT
Subject: [jdk20] RFR: 8298084: Memory leak in
 Method::build_profiling_method_data [v3]
In-Reply-To: <yOvhSY98FRUuMUF3vAd0cqG9AWjypujSl-Qy3dpzf2A=.9c2c85cf-699b-4f49-8cdc-9a08a934039b@github.com>
References: <C9g5yB0uAHEc3BUu8JImdl9hOJUqFeDosqrIJWtYOlk=.7b3aea19-771a-4b9d-af5f-2716a2bac11a@github.com>
 <yOvhSY98FRUuMUF3vAd0cqG9AWjypujSl-Qy3dpzf2A=.9c2c85cf-699b-4f49-8cdc-9a08a934039b@github.com>
Message-ID: <W5WE1qXCBreIDT51yT9Pt6LTSFldfFfipzJftYIzdk0=.34767674-61a5-454f-9cb3-aebbd29db423@github.com>

On Mon, 12 Dec 2022 17:51:25 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change fixes the MethodData leak by calling the destructor in both the release_C_heap_structures conditionally and by calling the MethodData destructor in the MetadataFactory::free_metadata method.
>> Thanks to @jcking for working on the patch and discussion.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Even more metaprogramming improvements

Thanks Coleen. A couple of further nits on comments but otherwise this seems okay.

src/hotspot/share/oops/instanceKlass.cpp line 600:

> 598:   // Can't release the constant pool here because the constant pool can be
> 599:   // deallocated separately from the InstanceKlass for default methods and
> 600:   // redefine classes.

Does this comment make sense when the parameter doesn't actually control release of the CP?

src/hotspot/share/oops/instanceKlass.cpp line 2667:

> 2665: }
> 2666: 
> 2667: // Called also by InstanceKlass::deallocate_contents, with false for release_constant_pool.

Comment needs updating.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/13

From dholmes at openjdk.org  Tue Dec 13 01:19:37 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 13 Dec 2022 01:19:37 GMT
Subject: [jdk20] RFR: 8298084: Memory leak in
 Method::build_profiling_method_data [v3]
In-Reply-To: <mzIUiE1mp8oqfdmKHPzf_H-ccB11q3nRUUVrM2B048c=.bb4a05a9-3065-45bb-bceb-0d56132bd5e7@github.com>
References: <C9g5yB0uAHEc3BUu8JImdl9hOJUqFeDosqrIJWtYOlk=.7b3aea19-771a-4b9d-af5f-2716a2bac11a@github.com>
 <yOvhSY98FRUuMUF3vAd0cqG9AWjypujSl-Qy3dpzf2A=.9c2c85cf-699b-4f49-8cdc-9a08a934039b@github.com>
 <oD-YnjsN14b4ogxrRFd4_YOwGohga9PMXH9GRmph8uQ=.5d7f1ebd-2455-4c42-8522-8c43e88b7598@github.com>
 <mzIUiE1mp8oqfdmKHPzf_H-ccB11q3nRUUVrM2B048c=.bb4a05a9-3065-45bb-bceb-0d56132bd5e7@github.com>
Message-ID: <XAAa6WGODzNJpWGuAomaWdBZHrkPxInxNR5c9ZUxNGM=.b754d013-e47f-4f61-9cfa-2d1d41fc52f2@github.com>

On Tue, 13 Dec 2022 00:56:30 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/oops/instanceKlass.cpp line 2675:
>> 
>>> 2673:   if (release_sub_metadata) {
>>> 2674:     methods_do(method_release_C_heap_structures);
>>> 2675:   }
>> 
>> I don't understand this aspect of the change. It seems unrelated to the missing destructor issue and seems to cause a significant change in behaviour as we will no longer call `methods_do` when called from `deallocate_contents` with the renamed `false` argument.
>
> This boolean prevents us from calling the MethodData destructor twice and releasing MethodData C heap memory twice.  InstanceKlass::deallocate_contents calls release_C_heap_structures with it false, and then calls through the Metadata pointer hierarchy to MetadataFactory::free_metadata, which calls the MethodData destructor and MethodData::deallocate_contents which calls MethodData::release_C_heap_structures().   This is the delegation scheme for releasing metadata between InstanceKlass and ConstantPool.
> 
> InstanceKlass::release_C_heap_structures() is also called during class unloading and must walk the whole metadata, releasing C heap memory.  It's passed true. It doesn't go through deallocate_contents because the metadata is freed together at the same time with the metaspace that contains it.

Thanks Coleen I see now how the code has been shuffled around:

Old code:

InstanceKlass::deallocate_contents
-> release_C_heap_structures(/* release_sub_metadata */ false);
  -> methods_do(method_release_C_heap_structures);
    -> m->release_C_heap_structures
      -> method_data()->~MethodData();
-> deallocate_methods(loader_data, methods());
  -> MetadataFactory::free_metadata(loader_data, method);

New code:

InstanceKlass::deallocate_contents
-> release_C_heap_structures(/* release_sub_metadata */ false);
-> deallocate_methods(loader_data, methods());
  -> MetadataFactory::free_metadata(loader_data, method);
    -> method_data()->~MethodData();

-------------

PR: https://git.openjdk.org/jdk20/pull/13

From coleenp at openjdk.org  Tue Dec 13 01:25:23 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 13 Dec 2022 01:25:23 GMT
Subject: [jdk20] RFR: 8298084: Memory leak in
 Method::build_profiling_method_data [v4]
In-Reply-To: <C9g5yB0uAHEc3BUu8JImdl9hOJUqFeDosqrIJWtYOlk=.7b3aea19-771a-4b9d-af5f-2716a2bac11a@github.com>
References: <C9g5yB0uAHEc3BUu8JImdl9hOJUqFeDosqrIJWtYOlk=.7b3aea19-771a-4b9d-af5f-2716a2bac11a@github.com>
Message-ID: <Al9NT4yMLvpAdNTMDXHyZwvC7NFlcZGEPNXUMcj8noQ=.0f2857ed-43ff-46f8-a5a2-a58f8faea3ad@github.com>

> This change fixes the MethodData leak by calling the destructor in both the release_C_heap_structures conditionally and by calling the MethodData destructor in the MetadataFactory::free_metadata method.
> Thanks to @jcking for working on the patch and discussion.
> Tested with tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Update comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/13/files
  - new: https://git.openjdk.org/jdk20/pull/13/files/11fcdba0..6deb5f46

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=13&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=13&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk20/pull/13.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/13/head:pull/13

PR: https://git.openjdk.org/jdk20/pull/13

From coleenp at openjdk.org  Tue Dec 13 02:26:22 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 13 Dec 2022 02:26:22 GMT
Subject: [jdk20] RFR: 8298084: Memory leak in
 Method::build_profiling_method_data [v3]
In-Reply-To: <W5WE1qXCBreIDT51yT9Pt6LTSFldfFfipzJftYIzdk0=.34767674-61a5-454f-9cb3-aebbd29db423@github.com>
References: <C9g5yB0uAHEc3BUu8JImdl9hOJUqFeDosqrIJWtYOlk=.7b3aea19-771a-4b9d-af5f-2716a2bac11a@github.com>
 <yOvhSY98FRUuMUF3vAd0cqG9AWjypujSl-Qy3dpzf2A=.9c2c85cf-699b-4f49-8cdc-9a08a934039b@github.com>
 <W5WE1qXCBreIDT51yT9Pt6LTSFldfFfipzJftYIzdk0=.34767674-61a5-454f-9cb3-aebbd29db423@github.com>
Message-ID: <ERiZciVcQI5ZZk5-uCPyL_2kDtgM-klc-W2Hz2ZCKAg=.4c5e16fe-d40c-4f4b-b060-420ae30354c6@github.com>

On Tue, 13 Dec 2022 01:15:18 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Even more metaprogramming improvements
>
> src/hotspot/share/oops/instanceKlass.cpp line 600:
> 
>> 598:   // Can't release the constant pool here because the constant pool can be
>> 599:   // deallocated separately from the InstanceKlass for default methods and
>> 600:   // redefine classes.
> 
> Does this comment make sense when the parameter doesn't actually control release of the CP?

It should be inclusive of MethodData also.

-------------

PR: https://git.openjdk.org/jdk20/pull/13

From coleenp at openjdk.org  Tue Dec 13 02:26:24 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 13 Dec 2022 02:26:24 GMT
Subject: [jdk20] RFR: 8298084: Memory leak in
 Method::build_profiling_method_data [v3]
In-Reply-To: <XAAa6WGODzNJpWGuAomaWdBZHrkPxInxNR5c9ZUxNGM=.b754d013-e47f-4f61-9cfa-2d1d41fc52f2@github.com>
References: <C9g5yB0uAHEc3BUu8JImdl9hOJUqFeDosqrIJWtYOlk=.7b3aea19-771a-4b9d-af5f-2716a2bac11a@github.com>
 <yOvhSY98FRUuMUF3vAd0cqG9AWjypujSl-Qy3dpzf2A=.9c2c85cf-699b-4f49-8cdc-9a08a934039b@github.com>
 <oD-YnjsN14b4ogxrRFd4_YOwGohga9PMXH9GRmph8uQ=.5d7f1ebd-2455-4c42-8522-8c43e88b7598@github.com>
 <mzIUiE1mp8oqfdmKHPzf_H-ccB11q3nRUUVrM2B048c=.bb4a05a9-3065-45bb-bceb-0d56132bd5e7@github.com>
 <XAAa6WGODzNJpWGuAomaWdBZHrkPxInxNR5c9ZUxNGM=.b754d013-e47f-4f61-9cfa-2d1d41fc52f2@github.com>
Message-ID: <PLAaDukllJYPPYy-dGGvH2S7vEdqyekTd6IVI4Hgonw=.c2b38b44-bfcb-45d1-bb83-de195b406567@github.com>

On Tue, 13 Dec 2022 01:16:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This boolean prevents us from calling the MethodData destructor twice and releasing MethodData C heap memory twice.  InstanceKlass::deallocate_contents calls release_C_heap_structures with it false, and then calls through the Metadata pointer hierarchy to MetadataFactory::free_metadata, which calls the MethodData destructor and MethodData::deallocate_contents which calls MethodData::release_C_heap_structures().   This is the delegation scheme for releasing metadata between InstanceKlass and ConstantPool.
>> 
>> InstanceKlass::release_C_heap_structures() is also called during class unloading and must walk the whole metadata, releasing C heap memory.  It's passed true. It doesn't go through deallocate_contents because the metadata is freed together at the same time with the metaspace that contains it.
>
> Thanks Coleen I see now how the code has been shuffled around:
> 
> Old code:
> 
> InstanceKlass::deallocate_contents
> -> release_C_heap_structures(/* release_sub_metadata */ false);
>   -> methods_do(method_release_C_heap_structures);
>     -> m->release_C_heap_structures
>       -> method_data()->~MethodData();
> -> deallocate_methods(loader_data, methods());
>   -> MetadataFactory::free_metadata(loader_data, method);
> 
> New code:
> 
> InstanceKlass::deallocate_contents
> -> release_C_heap_structures(/* release_sub_metadata */ false);
> -> deallocate_methods(loader_data, methods());
>   -> MetadataFactory::free_metadata(loader_data, method);
>     -> method_data()->~MethodData();

Yes, plus releasing the JVMCI thing that MethodData points to also.

-------------

PR: https://git.openjdk.org/jdk20/pull/13

From coleenp at openjdk.org  Tue Dec 13 02:33:52 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 13 Dec 2022 02:33:52 GMT
Subject: [jdk20] RFR: 8298084: Memory leak in
 Method::build_profiling_method_data [v5]
In-Reply-To: <C9g5yB0uAHEc3BUu8JImdl9hOJUqFeDosqrIJWtYOlk=.7b3aea19-771a-4b9d-af5f-2716a2bac11a@github.com>
References: <C9g5yB0uAHEc3BUu8JImdl9hOJUqFeDosqrIJWtYOlk=.7b3aea19-771a-4b9d-af5f-2716a2bac11a@github.com>
Message-ID: <irDcR2_eplmOgnKSnllY5m9CqVMMdQ3L9r_6m639oc0=.71c0013b-0a22-4619-9c94-915fc4f71e25@github.com>

> This change fixes the MethodData leak by calling the destructor in both the release_C_heap_structures conditionally and by calling the MethodData destructor in the MetadataFactory::free_metadata method.
> Thanks to @jcking for working on the patch and discussion.
> Tested with tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  More comment updates.

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/13/files
  - new: https://git.openjdk.org/jdk20/pull/13/files/6deb5f46..9cccf6c7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=13&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=13&range=03-04

  Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk20/pull/13.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/13/head:pull/13

PR: https://git.openjdk.org/jdk20/pull/13

From coleenp at openjdk.org  Tue Dec 13 02:44:44 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 13 Dec 2022 02:44:44 GMT
Subject: [jdk20] RFR: 8298084: Memory leak in
 Method::build_profiling_method_data [v6]
In-Reply-To: <C9g5yB0uAHEc3BUu8JImdl9hOJUqFeDosqrIJWtYOlk=.7b3aea19-771a-4b9d-af5f-2716a2bac11a@github.com>
References: <C9g5yB0uAHEc3BUu8JImdl9hOJUqFeDosqrIJWtYOlk=.7b3aea19-771a-4b9d-af5f-2716a2bac11a@github.com>
Message-ID: <HD178saqlltDnejw-11N8q07Ar5hiuurZ3QVfXf-83Q=.21ee1872-d079-4db5-ab0a-059f15313a09@github.com>

> This change fixes the MethodData leak by calling the destructor in both the release_C_heap_structures conditionally and by calling the MethodData destructor in the MetadataFactory::free_metadata method.
> Thanks to @jcking for working on the patch and discussion.
> Tested with tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Even more comment updates.  Removed word salad.

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/13/files
  - new: https://git.openjdk.org/jdk20/pull/13/files/9cccf6c7..95ecbc3c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=13&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=13&range=04-05

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk20/pull/13.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/13/head:pull/13

PR: https://git.openjdk.org/jdk20/pull/13

From jcking at openjdk.org  Tue Dec 13 03:37:50 2022
From: jcking at openjdk.org (Justin King)
Date: Tue, 13 Dec 2022 03:37:50 GMT
Subject: [jdk20] RFR: 8298084: Memory leak in
 Method::build_profiling_method_data [v6]
In-Reply-To: <HD178saqlltDnejw-11N8q07Ar5hiuurZ3QVfXf-83Q=.21ee1872-d079-4db5-ab0a-059f15313a09@github.com>
References: <C9g5yB0uAHEc3BUu8JImdl9hOJUqFeDosqrIJWtYOlk=.7b3aea19-771a-4b9d-af5f-2716a2bac11a@github.com>
 <HD178saqlltDnejw-11N8q07Ar5hiuurZ3QVfXf-83Q=.21ee1872-d079-4db5-ab0a-059f15313a09@github.com>
Message-ID: <qtCmXEFlLEGxWpnC3pm3Qu_O1HFVKsx4IZ-oEC9oitw=.db531a83-3dfb-4076-b0b4-891ccc37fd81@github.com>

On Tue, 13 Dec 2022 02:44:44 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change fixes the MethodData leak by calling the destructor in both the release_C_heap_structures conditionally and by calling the MethodData destructor in the MetadataFactory::free_metadata method.
>> Thanks to @jcking for working on the patch and discussion.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Even more comment updates.  Removed word salad.

Marked as reviewed by jcking (Author).

src/hotspot/share/memory/metadataFactory.hpp line 76:

> 74:       // that needs to be destructed to release resources. Most Metadata derived classes have noop
> 75:       // destructors and/or cleanup using deallocate_contents.
> 76:       // T is a potentially const or volatile qualified pointer. Remove any const

We'll given the template, T by itself is no longer a pointer so its just potentially const or volatile qualified. But that is pedantic.

-------------

PR: https://git.openjdk.org/jdk20/pull/13

From kvn at openjdk.org  Tue Dec 13 04:24:45 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 13 Dec 2022 04:24:45 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v16]
In-Reply-To: <42H7oL49YA3VoxBr4RPfZT5f3v6AeEgV0iGmXx63UnQ=.eb518482-1142-4db5-b560-6ebeab613d9c@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
 <42H7oL49YA3VoxBr4RPfZT5f3v6AeEgV0iGmXx63UnQ=.eb518482-1142-4db5-b560-6ebeab613d9c@github.com>
Message-ID: <kMZ5m4Tkl-CFkuXex9eCbZJmJLardSluLhRQlKn3LTo=.223b9a6d-c156-49bb-aaa0-2707b7b1067d@github.com>

On Mon, 12 Dec 2022 18:44:22 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This patch fixes the remaining null pointer dereference bugs that I know of.
>> 
>> For the main bug, C2 was using a null reference to indicate an uninitialized `Node_List`. I replaced the null reference with a static sentinel.
>> 
>> I also turned on `-fsanitize=null` and found and fixed a bunch of other null pointer dereferences. With this,I have run a full bootstrap and tier1 tests with `-fsanitize=null` enabled.
>> 
>> I have checked that the code generated by GCC is not worse in any significant way, so I don't expect to see any performance regressions.
>> 
>> I'd like to enable `-fsanitize=null` in debug builds to prevent regressions in this area. What do you think?
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Typo

My testing passed clean.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10920

From dholmes at openjdk.org  Tue Dec 13 05:15:56 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 13 Dec 2022 05:15:56 GMT
Subject: [jdk20] RFR: 8298084: Memory leak in
 Method::build_profiling_method_data [v6]
In-Reply-To: <HD178saqlltDnejw-11N8q07Ar5hiuurZ3QVfXf-83Q=.21ee1872-d079-4db5-ab0a-059f15313a09@github.com>
References: <C9g5yB0uAHEc3BUu8JImdl9hOJUqFeDosqrIJWtYOlk=.7b3aea19-771a-4b9d-af5f-2716a2bac11a@github.com>
 <HD178saqlltDnejw-11N8q07Ar5hiuurZ3QVfXf-83Q=.21ee1872-d079-4db5-ab0a-059f15313a09@github.com>
Message-ID: <-55m6oPdwVRKB18adAwe9sc7HX-UzXAmSezm7DUOHXQ=.871016cb-b23e-431a-9c73-e8c5da032ebe@github.com>

On Tue, 13 Dec 2022 02:44:44 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change fixes the MethodData leak by calling the destructor in both the release_C_heap_structures conditionally and by calling the MethodData destructor in the MetadataFactory::free_metadata method.
>> Thanks to @jcking for working on the patch and discussion.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Even more comment updates.  Removed word salad.

Marked as reviewed by dholmes (Reviewer).

-------------

PR: https://git.openjdk.org/jdk20/pull/13

From rehn at openjdk.org  Tue Dec 13 08:24:50 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 13 Dec 2022 08:24:50 GMT
Subject: RFR: 8292674: ReportJNIFatalError should print all java frames
 [v4]
In-Reply-To: <uUWb1njnLGXpTVPEx-n4QElmN9urKxquYk2n0TcaMVg=.221b1735-4325-4aae-91f5-2ba1b832ff58@github.com>
References: <-ipNtt5PSZ2d7VUBSoduPyNwnW2GeN_y0Dcs95qI8HU=.c4771172-01dd-49ae-8f4a-9d5cbd6c6dad@github.com>
 <uUWb1njnLGXpTVPEx-n4QElmN9urKxquYk2n0TcaMVg=.221b1735-4325-4aae-91f5-2ba1b832ff58@github.com>
Message-ID: <OnjHGoROI9DllNHmRp_5o5FehEMxA4XD0qVnaZxjHQk=.c722573d-61cd-435f-a5cf-1f626c87ec20@github.com>

On Fri, 9 Dec 2022 01:53:40 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> When JNI reports errors and warnings and produces a stack trace, we need to see the exact Java code that was being executed. The existing `JavaThread::print_stack` that is used is only for platform/carrier threads and doesn't show any mounted virtual thread. So we introduce a new `JavaThread::print_virtual_stack_on` method to print the mounted virtual thread's stack, and we add `JavaThread::print_jni_stack` as a utility for JNI to call that dispatches to the appropriate function based on the thread type.
>> 
>> The existing test `hotspot/jtreg/runtime/jni/checked/TestPrimitiveArrayCriticalWithBadParam.java` was modified to test regular and virtual threads, and to expect to see the specific stack frame of the Java native method.
>> 
>> Additional manual testing of the JNI `FatalError` method was done by direct fault injection in modified JDK code.
>> 
>> Sanity testing: Oracle tiers 1-4 (to include our -Xcheck:jni run in tier4)
>> 
>> Thanks,
>> David
>
> David Holmes 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 four additional commits since the last revision:
> 
>  - Merge branch 'master' into 8292674-ReportJNIFatalError-v2
>  - Merge branch 'master' into 8292674-ReportJNIFatalError-v2
>  - Changed RegisterMap to include process_frame and update, for object monitor examination.
>    Updated stack printing for exception checks.
>  - 8292674: ReportJNIFatalError should print all java frames

Sorry, not sure why I missed your ping.

-------------

PR: https://git.openjdk.org/jdk/pull/11503

From ayang at openjdk.org  Tue Dec 13 08:34:17 2022
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 13 Dec 2022 08:34:17 GMT
Subject: RFR: 8298636: Fix return value in WB_CountAliveClasses and
 WB_GetSymbolRefcount
Message-ID: <5CSk9c7fs5uIR4No4c-fRsGsl70bLAIzOlnW_QeHEAg=.241eac0e-28dc-4963-9bc5-a06e9491df29@github.com>

Simple change of conforming to the return type.

-------------

Commit messages:
 - wb-return-jint

Changes: https://git.openjdk.org/jdk/pull/11643/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11643&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298636
  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11643.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11643/head:pull/11643

PR: https://git.openjdk.org/jdk/pull/11643

From thartmann at openjdk.org  Tue Dec 13 08:36:54 2022
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 13 Dec 2022 08:36:54 GMT
Subject: [jdk20] RFR: 8298084: Memory leak in
 Method::build_profiling_method_data [v6]
In-Reply-To: <HD178saqlltDnejw-11N8q07Ar5hiuurZ3QVfXf-83Q=.21ee1872-d079-4db5-ab0a-059f15313a09@github.com>
References: <C9g5yB0uAHEc3BUu8JImdl9hOJUqFeDosqrIJWtYOlk=.7b3aea19-771a-4b9d-af5f-2716a2bac11a@github.com>
 <HD178saqlltDnejw-11N8q07Ar5hiuurZ3QVfXf-83Q=.21ee1872-d079-4db5-ab0a-059f15313a09@github.com>
Message-ID: <tZN2NLydTaqhq9BGBJHbIRY97bGjnawAa8U5IAoG6Aw=.af72a637-aa0d-4f25-9cbf-8844d1caf8b6@github.com>

On Tue, 13 Dec 2022 02:44:44 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change fixes the MethodData leak by calling the destructor in both the release_C_heap_structures conditionally and by calling the MethodData destructor in the MetadataFactory::free_metadata method.
>> Thanks to @jcking for working on the patch and discussion.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Even more comment updates.  Removed word salad.

Looks good to me. Thanks for fixing!

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/13

From rcastanedalo at openjdk.org  Tue Dec 13 09:03:43 2022
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Tue, 13 Dec 2022 09:03:43 GMT
Subject: RFR: 8297235: ZGC: assert(regs[i] != regs[j]) failed: Multiple
 uses of register: rax [v3]
In-Reply-To: <0fGmbCvEUHokqoFR0ndPwd7yA5I_SS-MlBneCPP3LqY=.c4b67306-e5bb-4af5-8875-adba9ea9d0f1@github.com>
References: <jYsSVWwRPyRKvs8HYIwp6Ar5Z0XISOwp1DM4A0AgdOQ=.378c74fb-a4e1-45a5-82b0-838c2fcba43a@github.com>
 <0fGmbCvEUHokqoFR0ndPwd7yA5I_SS-MlBneCPP3LqY=.c4b67306-e5bb-4af5-8875-adba9ea9d0f1@github.com>
Message-ID: <W2G4bZG6dRlsbf6SqhziGEKacPipIefOxprkVYZ95Ew=.adfd991b-cdac-4e37-a154-4ee88f721c31@github.com>

On Thu, 8 Dec 2022 09:01:08 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Tests java/util/stream/test/org/openjdk/tests/java/util/* with -XX:+UseZGC -Xcomp -XX:-TieredCompilation crashes with `assert(regs[i] != regs[j]) failed: Multiple uses of register: rax`. More specifically compilation of java.util.concurrent.ForkJoinTask::awaitDone.
>> 
>> The reason seems to be that the compare value and the memory input ends up sharing a register. (Uses Unsafe CAS which CAS an object reference into a field of that object, `oldval: rax` and `mem: [rax+offset]`). The Z load barrier stub dispatch implementation require that the reference and reference address occupy distinct registers. In the loadP nodes this is established by marking all but the memory TEMP which results in no sharing.
>> 
>> This is not possible for the CompareAndSwapP / CompareAndExchangeP nodes as the compare value is an input node. 
>> 
>> The solution proposed here is less than ideal as it makes the CAS nodes require one extra TEMP register, which in the common case is unused. This puts unnecessary extra strain on the register allocation. The problem is that there is no way currently (that I can find) to express in .ad that a memory input must not share registers with a specific other input. 
>> 
>> There is an alternative solution for this specific crash which does not use a second TEMP register (see commit: cfd5ced4e97e986fc10c5a8721b543cd3101c58a). It accomplish this by using the same trick that the aarch64 Z CAS node uses which is to specify the memory as indirect which results in the address being LEA into a register. However from what I can see this does not guarantee that the address and the reference does not share a register (`oldval: rax` and `mem: [rax]`). So it is theoretically broken, (and so is the aarch64 implementation). 
>> 
>> It is unclear to me if there is ever a way for C2 to generation a CAS which compares the address of the field with its content. 
>> 
>> I call on anyone with more knowledge about `adlc` and `C2` for feedback. And specifically I want to open up a discussion with these points:
>> * Is there some other way of expressing in the .ad file that a memory input should not share some register?
>>   * If not, is this a worthwhile RFE? As it seems to be a patterned used at least in other places in Z.
>> * Will the indirect input ever share a register with oldval and/or are the aarch64/riscv implementations broken because of this? How about ppc?
>> 
>> Testing: linux-x64 zgc tagged tests tier 1-7 and some specific crashing tests with `-XX:+UseZGC -Xcomp -XX:-TieredCompilation` (in: java/util/stream/, java/util/concurrent/)
>
> Axel Boldt-Christmas 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 commits since the last revision:
> 
>  - Remove problem listed tests
>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8297235
>  - indirect zXChgP as well
>  - indirect alternative
>  - JDK-8297235: ZGC: assert(regs[i] != regs[j]) failed: Multiple uses of register: rax

I agree with @fisk's analysis above: the proposed solution should be safe as long as the first CompareAndSwap operand (`mem`) has a non-zero offset (which should at least be the case in the failing Unsafe-based patterns): the register allocator will then treat `mem` and `oldval` as two distinct, interfering values and assign them different registers.

I attached a [minimal reproducer](https://bugs.openjdk.org/secure/attachment/102007/Reproducer.java) to the JBS issue, feel free to include it in this PR as a test case if you think it adds value.

   I do not think there is a general way to express the constraint you want in .ad files, but I am not an expert in this area, maybe someone at Intel could comment on this (@sviswa7, @jatin-bhateja?). I also do not have a feeling for what would be the benefit vs. cost of implementing such construct. An alternative approach could be to enforce the constraint at the C2 IR level, by adding some kind of pseudo-node redefining the input to the first `CompareAndSwap` operand so that it always interferes with `oldval`.

   Regarding the impact on other architectures, it seems they all follow the solution proposed here, so they should be as safe as in this case, that is, as long as C2 does not generate a CAS comparing the address of the field with its content. I cannot think how C2 could generate such pattern - which of course is not a guarantee that it will never do it ;).

-------------

Marked as reviewed by rcastanedalo (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11410

From coleenp at openjdk.org  Tue Dec 13 13:04:20 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 13 Dec 2022 13:04:20 GMT
Subject: [jdk20] RFR: 8298084: Memory leak in
 Method::build_profiling_method_data [v6]
In-Reply-To: <HD178saqlltDnejw-11N8q07Ar5hiuurZ3QVfXf-83Q=.21ee1872-d079-4db5-ab0a-059f15313a09@github.com>
References: <C9g5yB0uAHEc3BUu8JImdl9hOJUqFeDosqrIJWtYOlk=.7b3aea19-771a-4b9d-af5f-2716a2bac11a@github.com>
 <HD178saqlltDnejw-11N8q07Ar5hiuurZ3QVfXf-83Q=.21ee1872-d079-4db5-ab0a-059f15313a09@github.com>
Message-ID: <JEOHS9LMAM8hegb7cu1eu144MDPxjS9hvLyWusFusw0=.b57680c0-a12e-47e3-81b6-83992121800c@github.com>

On Tue, 13 Dec 2022 02:44:44 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change fixes the MethodData leak by calling the destructor in both the release_C_heap_structures conditionally and by calling the MethodData destructor in the MetadataFactory::free_metadata method.
>> Thanks to @jcking for working on the patch and discussion.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Even more comment updates.  Removed word salad.

Thanks for the reviews David, Justin and Tobias.

-------------

PR: https://git.openjdk.org/jdk20/pull/13

From coleenp at openjdk.org  Tue Dec 13 13:04:21 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 13 Dec 2022 13:04:21 GMT
Subject: [jdk20] RFR: 8298084: Memory leak in
 Method::build_profiling_method_data [v6]
In-Reply-To: <qtCmXEFlLEGxWpnC3pm3Qu_O1HFVKsx4IZ-oEC9oitw=.db531a83-3dfb-4076-b0b4-891ccc37fd81@github.com>
References: <C9g5yB0uAHEc3BUu8JImdl9hOJUqFeDosqrIJWtYOlk=.7b3aea19-771a-4b9d-af5f-2716a2bac11a@github.com>
 <HD178saqlltDnejw-11N8q07Ar5hiuurZ3QVfXf-83Q=.21ee1872-d079-4db5-ab0a-059f15313a09@github.com>
 <qtCmXEFlLEGxWpnC3pm3Qu_O1HFVKsx4IZ-oEC9oitw=.db531a83-3dfb-4076-b0b4-891ccc37fd81@github.com>
Message-ID: <p1aUgMPWQ2Lg7VQDqgFPhhWlF43Dd2mWqbAMC9wD31o=.d1970731-8151-4b58-8bbb-0313ad141339@github.com>

On Tue, 13 Dec 2022 03:31:32 GMT, Justin King <jcking at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Even more comment updates.  Removed word salad.
>
> src/hotspot/share/memory/metadataFactory.hpp line 76:
> 
>> 74:       // that needs to be destructed to release resources. Most Metadata derived classes have noop
>> 75:       // destructors and/or cleanup using deallocate_contents.
>> 76:       // T is a potentially const or volatile qualified pointer. Remove any const
> 
> We'll given the template, T by itself is no longer a pointer so its just potentially const or volatile qualified. But that is pedantic.

I just want to leave it because you're right but pointer is a readable noun here.

-------------

PR: https://git.openjdk.org/jdk20/pull/13

From coleenp at openjdk.org  Tue Dec 13 13:06:18 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 13 Dec 2022 13:06:18 GMT
Subject: [jdk20] Integrated: 8298084: Memory leak in
 Method::build_profiling_method_data
In-Reply-To: <C9g5yB0uAHEc3BUu8JImdl9hOJUqFeDosqrIJWtYOlk=.7b3aea19-771a-4b9d-af5f-2716a2bac11a@github.com>
References: <C9g5yB0uAHEc3BUu8JImdl9hOJUqFeDosqrIJWtYOlk=.7b3aea19-771a-4b9d-af5f-2716a2bac11a@github.com>
Message-ID: <T_OQ0mgRejVcdxI-mM0ArZyeC7ArlmfAO-m25E5R3aQ=.26cf2fce-e887-4cff-861a-e420ea4f3c84@github.com>

On Fri, 9 Dec 2022 16:16:00 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change fixes the MethodData leak by calling the destructor in both the release_C_heap_structures conditionally and by calling the MethodData destructor in the MetadataFactory::free_metadata method.
> Thanks to @jcking for working on the patch and discussion.
> Tested with tier1-4.

This pull request has now been integrated.

Changeset: 04b8d0cf
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/04b8d0cf5c964e16c583b66d9ab43a8c9a85fd72
Stats:     39 lines in 6 files changed: 21 ins; 1 del; 17 mod

8298084: Memory leak in Method::build_profiling_method_data

Co-authored-by: Justin King <jcking at openjdk.org>
Reviewed-by: kbarrett, eosterlund, dholmes, jcking, thartmann

-------------

PR: https://git.openjdk.org/jdk20/pull/13

From jwilhelm at openjdk.org  Tue Dec 13 14:03:29 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 13 Dec 2022 14:03:29 GMT
Subject: RFR: Merge jdk20
Message-ID: <SpKZ4RayXNrZIkyJXsXpquHbpqWmaeyrPOHOKFM2Mbc=.6b7ecb89-df7a-43d6-b5dc-50bd6d2075d8@github.com>

Forwardport JDK 20 -> JDK 21

-------------

Commit messages:
 - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20
 - 8298084: Memory leak in Method::build_profiling_method_data
 - 8296955: Kitchensink.java failed with "double free or corruption (!prev): <addr>"
 - 8298488: [macos13] tools/jpackage tests failing with "Exit code: 137" on macOS
 - 8297288: Example code in Scanner class
 - 8298271: java/security/SignedJar/spi-calendar-provider/TestSPISigned.java failing on Windows
 - 8298459: Fix msys2 linking and handling out of tree build directory for source zip creation

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=11651&range=00.0
 - jdk20: https://webrevs.openjdk.org/?repo=jdk&pr=11651&range=00.1

Changes: https://git.openjdk.org/jdk/pull/11651/files
  Stats: 181 lines in 15 files changed: 60 ins; 57 del; 64 mod
  Patch: https://git.openjdk.org/jdk/pull/11651.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11651/head:pull/11651

PR: https://git.openjdk.org/jdk/pull/11651

From aboldtch at openjdk.org  Tue Dec 13 15:45:56 2022
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 13 Dec 2022 15:45:56 GMT
Subject: Integrated: 8297235: ZGC: assert(regs[i] != regs[j]) failed: Multiple
 uses of register: rax
In-Reply-To: <jYsSVWwRPyRKvs8HYIwp6Ar5Z0XISOwp1DM4A0AgdOQ=.378c74fb-a4e1-45a5-82b0-838c2fcba43a@github.com>
References: <jYsSVWwRPyRKvs8HYIwp6Ar5Z0XISOwp1DM4A0AgdOQ=.378c74fb-a4e1-45a5-82b0-838c2fcba43a@github.com>
Message-ID: <p6emQJLGgz0iAhK3ViqPMjJZLRJ4pbYQ8g9b6Tt--C8=.d360051c-d602-4551-a8a6-8e4aa0e9f6f9@github.com>

On Tue, 29 Nov 2022 09:50:11 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Tests java/util/stream/test/org/openjdk/tests/java/util/* with -XX:+UseZGC -Xcomp -XX:-TieredCompilation crashes with `assert(regs[i] != regs[j]) failed: Multiple uses of register: rax`. More specifically compilation of java.util.concurrent.ForkJoinTask::awaitDone.
> 
> The reason seems to be that the compare value and the memory input ends up sharing a register. (Uses Unsafe CAS which CAS an object reference into a field of that object, `oldval: rax` and `mem: [rax+offset]`). The Z load barrier stub dispatch implementation require that the reference and reference address occupy distinct registers. In the loadP nodes this is established by marking all but the memory TEMP which results in no sharing.
> 
> This is not possible for the CompareAndSwapP / CompareAndExchangeP nodes as the compare value is an input node. 
> 
> The solution proposed here is less than ideal as it makes the CAS nodes require one extra TEMP register, which in the common case is unused. This puts unnecessary extra strain on the register allocation. The problem is that there is no way currently (that I can find) to express in .ad that a memory input must not share registers with a specific other input. 
> 
> There is an alternative solution for this specific crash which does not use a second TEMP register (see commit: cfd5ced4e97e986fc10c5a8721b543cd3101c58a). It accomplish this by using the same trick that the aarch64 Z CAS node uses which is to specify the memory as indirect which results in the address being LEA into a register. However from what I can see this does not guarantee that the address and the reference does not share a register (`oldval: rax` and `mem: [rax]`). So it is theoretically broken, (and so is the aarch64 implementation). 
> 
> It is unclear to me if there is ever a way for C2 to generation a CAS which compares the address of the field with its content. 
> 
> I call on anyone with more knowledge about `adlc` and `C2` for feedback. And specifically I want to open up a discussion with these points:
> * Is there some other way of expressing in the .ad file that a memory input should not share some register?
>   * If not, is this a worthwhile RFE? As it seems to be a patterned used at least in other places in Z.
> * Will the indirect input ever share a register with oldval and/or are the aarch64/riscv implementations broken because of this? How about ppc?
> 
> Testing: linux-x64 zgc tagged tests tier 1-7 and some specific crashing tests with `-XX:+UseZGC -Xcomp -XX:-TieredCompilation` (in: java/util/stream/, java/util/concurrent/)

This pull request has now been integrated.

Changeset: 042b7062
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/042b7062f19b313f31b228bd96d2a74cc1165ab9
Stats:     121 lines in 2 files changed: 21 ins; 90 del; 10 mod

8297235: ZGC: assert(regs[i] != regs[j]) failed: Multiple uses of register: rax

Reviewed-by: eosterlund, ayang, rcastanedalo

-------------

PR: https://git.openjdk.org/jdk/pull/11410

From aboldtch at openjdk.org  Tue Dec 13 16:02:46 2022
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 13 Dec 2022 16:02:46 GMT
Subject: [jdk20] RFR: 8297235: ZGC: assert(regs[i] != regs[j]) failed: Multiple
 uses of register: rax
Message-ID: <Hk-XWr3tjPojiZAg7anEvGBzvKcG6j12qh7-FwGkUbc=.aedb34a9-ae5e-44a5-82c9-406be2992f1a@github.com>

Hi all,

This pull request contains a backport of commit [042b7062](https://github.com/openjdk/jdk/commit/042b7062f19b313f31b228bd96d2a74cc1165ab9) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Axel Boldt-Christmas on 13 Dec 2022 and was reviewed by Erik ?sterlund, Albert Mingkun Yang and Roberto Casta?eda Lozano.

Thanks!

-------------

Commit messages:
 - Backport 042b7062f19b313f31b228bd96d2a74cc1165ab9

Changes: https://git.openjdk.org/jdk20/pull/25/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=25&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297235
  Stats: 121 lines in 2 files changed: 21 ins; 90 del; 10 mod
  Patch: https://git.openjdk.org/jdk20/pull/25.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/25/head:pull/25

PR: https://git.openjdk.org/jdk20/pull/25

From aph at openjdk.org  Tue Dec 13 16:32:04 2022
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 13 Dec 2022 16:32:04 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v16]
In-Reply-To: <kMZ5m4Tkl-CFkuXex9eCbZJmJLardSluLhRQlKn3LTo=.223b9a6d-c156-49bb-aaa0-2707b7b1067d@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
 <42H7oL49YA3VoxBr4RPfZT5f3v6AeEgV0iGmXx63UnQ=.eb518482-1142-4db5-b560-6ebeab613d9c@github.com>
 <kMZ5m4Tkl-CFkuXex9eCbZJmJLardSluLhRQlKn3LTo=.223b9a6d-c156-49bb-aaa0-2707b7b1067d@github.com>
Message-ID: <1xRzL48i5fFiF-qVxeeKlzktfyzZZF5KYGtsmJ5SebQ=.68e62b72-98e7-4753-9a9a-648851699164@github.com>

On Tue, 13 Dec 2022 04:22:18 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> My testing passed clean.

OK for https://github.com/openjdk/jdk20/pull/26 ?

-------------

PR: https://git.openjdk.org/jdk/pull/10920

From thartmann at openjdk.org  Tue Dec 13 16:32:08 2022
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 13 Dec 2022 16:32:08 GMT
Subject: [jdk20] RFR: 8297235: ZGC: assert(regs[i] != regs[j]) failed:
 Multiple uses of register: rax
In-Reply-To: <Hk-XWr3tjPojiZAg7anEvGBzvKcG6j12qh7-FwGkUbc=.aedb34a9-ae5e-44a5-82c9-406be2992f1a@github.com>
References: <Hk-XWr3tjPojiZAg7anEvGBzvKcG6j12qh7-FwGkUbc=.aedb34a9-ae5e-44a5-82c9-406be2992f1a@github.com>
Message-ID: <ckKbyRWVJ6_Hpp-6SELzjNftu4eBHpDT9eAcHieh3Rc=.4cbe9392-02ad-4ed7-bc2e-3ddf4b405d28@github.com>

On Tue, 13 Dec 2022 15:51:45 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [042b7062](https://github.com/openjdk/jdk/commit/042b7062f19b313f31b228bd96d2a74cc1165ab9) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Axel Boldt-Christmas on 13 Dec 2022 and was reviewed by Erik ?sterlund, Albert Mingkun Yang and Roberto Casta?eda Lozano.
> 
> Thanks!

Looks good.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/25

From aph at openjdk.org  Tue Dec 13 16:37:09 2022
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 13 Dec 2022 16:37:09 GMT
Subject: [jdk20] RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references
Message-ID: <HbMCF1mYRJV5TEjuO4iGR6qxMPRr8V5yTHXEynHr1zk=.1844dbc0-dd13-458b-8c9a-f618038ef8af@github.com>

JDK-8294902: Undefined Behavior in C2 regalloc with null references

-------------

Commit messages:
 - JDK-8294902: Undefined Behavior in C2 regalloc with null references

Changes: https://git.openjdk.org/jdk20/pull/26/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=26&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294902
  Stats: 64 lines in 7 files changed: 28 ins; 1 del; 35 mod
  Patch: https://git.openjdk.org/jdk20/pull/26.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/26/head:pull/26

PR: https://git.openjdk.org/jdk20/pull/26

From rehn at openjdk.org  Tue Dec 13 16:43:12 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 13 Dec 2022 16:43:12 GMT
Subject: RFR: 8296401: ConcurrentHashTable::bulk_delete might miss to
 delete some objects [v5]
In-Reply-To: <3Fnpqamf7GB_EaNVYVO-yuykUOzwhOOCOf_sIBE4334=.7951828c-1e7f-499c-883c-a2f239df28c0@github.com>
References: <rWw3Hb1baG5eslMgFnOdEP1Q4avhfYc3uTpjdB9DaP0=.23f34ff0-eff9-421b-9e70-7f119fd90e5d@github.com>
 <3Fnpqamf7GB_EaNVYVO-yuykUOzwhOOCOf_sIBE4334=.7951828c-1e7f-499c-883c-a2f239df28c0@github.com>
Message-ID: <CoXQUACQgbwcBQ47qPvwffKYHwJ91mn6gwe-d7wm8Qc=.96b54cb2-49e2-4ae9-9633-e635a90fdb4d@github.com>

On Fri, 9 Dec 2022 19:54:48 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> ConcurrentHashTable::bulk_delete might miss to delete some objects if a bucket has more than 256 entries. Current uses of ConcurrentHashTable are not harmed by this behaviour. 
>> 
>> I modified gtest:ConcurrentHashTable to detect the problem (first commit), and fixed the problem in the code (second commit).
>> 
>> Tests passes tier1-3.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   GrowableArray is indexed by int :-(

Looks good, thanks.

-------------

Marked as reviewed by rehn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10983

From jwilhelm at openjdk.org  Tue Dec 13 16:46:07 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 13 Dec 2022 16:46:07 GMT
Subject: Integrated: Merge jdk20
In-Reply-To: <SpKZ4RayXNrZIkyJXsXpquHbpqWmaeyrPOHOKFM2Mbc=.6b7ecb89-df7a-43d6-b5dc-50bd6d2075d8@github.com>
References: <SpKZ4RayXNrZIkyJXsXpquHbpqWmaeyrPOHOKFM2Mbc=.6b7ecb89-df7a-43d6-b5dc-50bd6d2075d8@github.com>
Message-ID: <LENLR7kTbJlO0PXG0D_YRgHDc0zYyJrge12segDYdeY=.6cf72ca8-4535-4bf4-ade7-d901366dcde9@github.com>

On Tue, 13 Dec 2022 13:55:12 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 20 -> JDK 21

This pull request has now been integrated.

Changeset: 23e18275
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/23e18275ac2a7297ba806a1835fabb7141949967
Stats:     181 lines in 15 files changed: 60 ins; 57 del; 64 mod

Merge

-------------

PR: https://git.openjdk.org/jdk/pull/11651

From kvn at openjdk.org  Tue Dec 13 17:54:58 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 13 Dec 2022 17:54:58 GMT
Subject: [jdk20] RFR: JDK-8294902: Undefined Behavior in C2 regalloc with
 null references
In-Reply-To: <HbMCF1mYRJV5TEjuO4iGR6qxMPRr8V5yTHXEynHr1zk=.1844dbc0-dd13-458b-8c9a-f618038ef8af@github.com>
References: <HbMCF1mYRJV5TEjuO4iGR6qxMPRr8V5yTHXEynHr1zk=.1844dbc0-dd13-458b-8c9a-f618038ef8af@github.com>
Message-ID: <62ZxK9QctY0O6QxGtSsWdirEO5UCrlBBAbBpfcRqO1U=.b2ec857d-df3d-40db-93bc-9c07e60b981c@github.com>

On Tue, 13 Dec 2022 16:27:37 GMT, Andrew Haley <aph at openjdk.org> wrote:

> JDK-8294902: Undefined Behavior in C2 regalloc with null references

Looks good. Matches original changes.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/26

From vlivanov at openjdk.org  Tue Dec 13 18:02:04 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 13 Dec 2022 18:02:04 GMT
Subject: [jdk20] RFR: JDK-8294902: Undefined Behavior in C2 regalloc with
 null references
In-Reply-To: <HbMCF1mYRJV5TEjuO4iGR6qxMPRr8V5yTHXEynHr1zk=.1844dbc0-dd13-458b-8c9a-f618038ef8af@github.com>
References: <HbMCF1mYRJV5TEjuO4iGR6qxMPRr8V5yTHXEynHr1zk=.1844dbc0-dd13-458b-8c9a-f618038ef8af@github.com>
Message-ID: <oQVgIzM2trgC1U8-Eh96CrPPk3xGEdIWaqqltCM7m4w=.bbf4504a-0292-490f-8eba-e83836dde9fb@github.com>

On Tue, 13 Dec 2022 16:27:37 GMT, Andrew Haley <aph at openjdk.org> wrote:

> JDK-8294902: Undefined Behavior in C2 regalloc with null references

Looks good.

-------------

Marked as reviewed by vlivanov (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/26

From iwalulya at openjdk.org  Tue Dec 13 18:07:12 2022
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Tue, 13 Dec 2022 18:07:12 GMT
Subject: RFR: 8296401: ConcurrentHashTable::bulk_delete might miss to
 delete some objects [v5]
In-Reply-To: <3Fnpqamf7GB_EaNVYVO-yuykUOzwhOOCOf_sIBE4334=.7951828c-1e7f-499c-883c-a2f239df28c0@github.com>
References: <rWw3Hb1baG5eslMgFnOdEP1Q4avhfYc3uTpjdB9DaP0=.23f34ff0-eff9-421b-9e70-7f119fd90e5d@github.com>
 <3Fnpqamf7GB_EaNVYVO-yuykUOzwhOOCOf_sIBE4334=.7951828c-1e7f-499c-883c-a2f239df28c0@github.com>
Message-ID: <M2g22rbsQQvOEozJRRvSE1xfzHKYBBF7Hd_mZbFryAY=.e64368f4-0999-4b14-83c0-d74064561d01@github.com>

On Fri, 9 Dec 2022 19:54:48 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> ConcurrentHashTable::bulk_delete might miss to delete some objects if a bucket has more than 256 entries. Current uses of ConcurrentHashTable are not harmed by this behaviour. 
>> 
>> I modified gtest:ConcurrentHashTable to detect the problem (first commit), and fixed the problem in the code (second commit).
>> 
>> Tests passes tier1-3.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   GrowableArray is indexed by int :-(

Marked as reviewed by iwalulya (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10983

From coleenp at openjdk.org  Tue Dec 13 18:37:30 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 13 Dec 2022 18:37:30 GMT
Subject: RFR: 8298475: Remove JVM_ACC_PROMOTED_FLAGS
Message-ID: <tAJIUt9u0ZDYHBmSdyuItQqlrh0wWBAbPEjpK17JlP8=.55ba3fd8-4b5a-47bb-9550-6322e3d8c303@github.com>

These access flags were implemented to enable passing access flag values from Method* to InstanceKlass*, but only covered one flag.  Towards only have access flags represent read-only flags in the class file, remove this and pass has_localvariable_table up to InstanceKlass in classfile parsing, like we do with other flags.
Tested with tier1-4.

-------------

Commit messages:
 - 8298475: Remove JVM_ACC_PROMOTED_FLAGS

Changes: https://git.openjdk.org/jdk/pull/11655/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11655&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298475
  Stats: 62 lines in 10 files changed: 21 ins; 22 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/11655.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11655/head:pull/11655

PR: https://git.openjdk.org/jdk/pull/11655

From sspitsyn at openjdk.org  Tue Dec 13 19:21:57 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 13 Dec 2022 19:21:57 GMT
Subject: RFR: 8298475: Remove JVM_ACC_PROMOTED_FLAGS
In-Reply-To: <tAJIUt9u0ZDYHBmSdyuItQqlrh0wWBAbPEjpK17JlP8=.55ba3fd8-4b5a-47bb-9550-6322e3d8c303@github.com>
References: <tAJIUt9u0ZDYHBmSdyuItQqlrh0wWBAbPEjpK17JlP8=.55ba3fd8-4b5a-47bb-9550-6322e3d8c303@github.com>
Message-ID: <Qj7ne9yDIfvJy4Hc7zaYFe4nsJCPkdWZBPP9fHpkceI=.b18ff666-dc9b-48ef-9e50-86d8ee1d753a@github.com>

On Tue, 13 Dec 2022 18:28:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> These access flags were implemented to enable passing access flag values from Method* to InstanceKlass*, but only covered one flag.  Towards only have access flags represent read-only flags in the class file, remove this and pass has_localvariable_table up to InstanceKlass in classfile parsing, like we do with other flags.
> Tested with tier1-4.

I like this fix.
It looks good.
Thanks,
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11655

From duke at openjdk.org  Tue Dec 13 19:59:10 2022
From: duke at openjdk.org (duke)
Date: Tue, 13 Dec 2022 19:59:10 GMT
Subject: Withdrawn: 8291714: Implement a Multi-Reader Single-Writer mutex for
 Hotspot
In-Reply-To: <Gq8Ci4GZW1jVRfd8NPc7IImtnY2TYO7kyo8FFYaMQzs=.9e62b134-bed1-4970-a840-ee217f6d5e98@github.com>
References: <Gq8Ci4GZW1jVRfd8NPc7IImtnY2TYO7kyo8FFYaMQzs=.9e62b134-bed1-4970-a840-ee217f6d5e98@github.com>
Message-ID: <cb9nS4RKA2lzuEqMzaY5hV0G7bssKJCPDvU-QMMUXyY=.d0ae4e19-574d-48c3-9b0b-90a62056c3fd@github.com>

On Thu, 11 Aug 2022 15:18:10 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> May I please have a review for this PR which implements a `MRWMutex` class for Hotspot?
> 
> This PR does 3 things:
> 
> * Adds a port of ZGC's MRSW mutex (see [0]) to Hotspot
> * Adds some new utilities for writing multi-threaded tests.
> * Adds some tests for MRSW Mutex using these new utilities
> 
> The ticket has some comments which might be worth checking out: https://bugs.openjdk.org/browse/JDK-8291714
> 
> [0] Original source code here: https://github.com/openjdk/zgc/blob/zgc_generational/src/hotspot/share/gc/z/zJNICritical.cpp

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/9838

From coleenp at openjdk.org  Tue Dec 13 20:23:10 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 13 Dec 2022 20:23:10 GMT
Subject: RFR: 8298475: Remove JVM_ACC_PROMOTED_FLAGS
In-Reply-To: <tAJIUt9u0ZDYHBmSdyuItQqlrh0wWBAbPEjpK17JlP8=.55ba3fd8-4b5a-47bb-9550-6322e3d8c303@github.com>
References: <tAJIUt9u0ZDYHBmSdyuItQqlrh0wWBAbPEjpK17JlP8=.55ba3fd8-4b5a-47bb-9550-6322e3d8c303@github.com>
Message-ID: <H2IseGKooSWIHHxiH3rsEx2ZM9ovEZ2HwW8BZByltc4=.6103f2c4-c303-4e1f-b7d8-bba8d7111ee2@github.com>

On Tue, 13 Dec 2022 18:28:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> These access flags were implemented to enable passing access flag values from Method* to InstanceKlass*, but only covered one flag.  Towards only have access flags represent read-only flags in the class file, remove this and pass has_localvariable_table up to InstanceKlass in classfile parsing, like we do with other flags.
> Tested with tier1-4.

Thank you Serguei!

-------------

PR: https://git.openjdk.org/jdk/pull/11655

From dcubed at openjdk.org  Tue Dec 13 20:47:06 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 13 Dec 2022 20:47:06 GMT
Subject: RFR: 8298475: Remove JVM_ACC_PROMOTED_FLAGS
In-Reply-To: <tAJIUt9u0ZDYHBmSdyuItQqlrh0wWBAbPEjpK17JlP8=.55ba3fd8-4b5a-47bb-9550-6322e3d8c303@github.com>
References: <tAJIUt9u0ZDYHBmSdyuItQqlrh0wWBAbPEjpK17JlP8=.55ba3fd8-4b5a-47bb-9550-6322e3d8c303@github.com>
Message-ID: <8KsIHXtchDelcarz7Pv4To9FmUNgN-soRt7qif3CgQk=.07cb2c0d-446a-485b-9c02-a3e4e59ece61@github.com>

On Tue, 13 Dec 2022 18:28:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> These access flags were implemented to enable passing access flag values from Method* to InstanceKlass*, but only covered one flag.  Towards only have access flags represent read-only flags in the class file, remove this and pass has_localvariable_table up to InstanceKlass in classfile parsing, like we do with other flags.
> Tested with tier1-4.

Thumbs up. I definitely like this cleanup/fix.

Thanks for including the testing info.

src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 4376:

> 4374:   if (scratch_class->has_localvariable_table() !=
> 4375:       the_class->has_localvariable_table()) {
> 4376:    the_class->set_has_localvariable_table(scratch_class->has_localvariable_table());

nit: need one more space for indent.

-------------

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11655

From coleenp at openjdk.org  Tue Dec 13 22:00:04 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 13 Dec 2022 22:00:04 GMT
Subject: RFR: 8298475: Remove JVM_ACC_PROMOTED_FLAGS [v2]
In-Reply-To: <tAJIUt9u0ZDYHBmSdyuItQqlrh0wWBAbPEjpK17JlP8=.55ba3fd8-4b5a-47bb-9550-6322e3d8c303@github.com>
References: <tAJIUt9u0ZDYHBmSdyuItQqlrh0wWBAbPEjpK17JlP8=.55ba3fd8-4b5a-47bb-9550-6322e3d8c303@github.com>
Message-ID: <raia13plfZ-BS23NceXuwYp6Ns4TrAtw5EeLCH7VGww=.2baa09d3-4a1d-4973-8872-170cb5432bde@github.com>

> These access flags were implemented to enable passing access flag values from Method* to InstanceKlass*, but only covered one flag.  Towards only have access flags represent read-only flags in the class file, remove this and pass has_localvariable_table up to InstanceKlass in classfile parsing, like we do with other flags.
> Tested with tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Add a space

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11655/files
  - new: https://git.openjdk.org/jdk/pull/11655/files/6f80df95..90ec438a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11655&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11655&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11655.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11655/head:pull/11655

PR: https://git.openjdk.org/jdk/pull/11655

From coleenp at openjdk.org  Tue Dec 13 22:00:05 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 13 Dec 2022 22:00:05 GMT
Subject: RFR: 8298475: Remove JVM_ACC_PROMOTED_FLAGS
In-Reply-To: <tAJIUt9u0ZDYHBmSdyuItQqlrh0wWBAbPEjpK17JlP8=.55ba3fd8-4b5a-47bb-9550-6322e3d8c303@github.com>
References: <tAJIUt9u0ZDYHBmSdyuItQqlrh0wWBAbPEjpK17JlP8=.55ba3fd8-4b5a-47bb-9550-6322e3d8c303@github.com>
Message-ID: <EzhlMYxakaQ_a2HOkuWrHQCxZ9Vruvas5kU_zwgeHJs=.8b2bb97e-9a3f-4010-b16e-58c79973429f@github.com>

On Tue, 13 Dec 2022 18:28:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> These access flags were implemented to enable passing access flag values from Method* to InstanceKlass*, but only covered one flag.  Towards only have access flags represent read-only flags in the class file, remove this and pass has_localvariable_table up to InstanceKlass in classfile parsing, like we do with other flags.
> Tested with tier1-4.

Thanks Dan!

-------------

PR: https://git.openjdk.org/jdk/pull/11655

From coleenp at openjdk.org  Tue Dec 13 22:00:05 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 13 Dec 2022 22:00:05 GMT
Subject: RFR: 8298475: Remove JVM_ACC_PROMOTED_FLAGS [v2]
In-Reply-To: <8KsIHXtchDelcarz7Pv4To9FmUNgN-soRt7qif3CgQk=.07cb2c0d-446a-485b-9c02-a3e4e59ece61@github.com>
References: <tAJIUt9u0ZDYHBmSdyuItQqlrh0wWBAbPEjpK17JlP8=.55ba3fd8-4b5a-47bb-9550-6322e3d8c303@github.com>
 <8KsIHXtchDelcarz7Pv4To9FmUNgN-soRt7qif3CgQk=.07cb2c0d-446a-485b-9c02-a3e4e59ece61@github.com>
Message-ID: <5D0J_bzyAga5GUgiy3l-zbRno2_WZJY2iKC7aCkZEWo=.28e40165-fb46-4f5b-8476-f59991ff369b@github.com>

On Tue, 13 Dec 2022 20:42:04 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add a space
>
> src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 4376:
> 
>> 4374:   if (scratch_class->has_localvariable_table() !=
>> 4375:       the_class->has_localvariable_table()) {
>> 4376:    the_class->set_has_localvariable_table(scratch_class->has_localvariable_table());
> 
> nit: need one more space for indent.

Got it, thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/11655

From dholmes at openjdk.org  Wed Dec 14 00:56:39 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 14 Dec 2022 00:56:39 GMT
Subject: RFR: 8298475: Remove JVM_ACC_PROMOTED_FLAGS [v2]
In-Reply-To: <raia13plfZ-BS23NceXuwYp6Ns4TrAtw5EeLCH7VGww=.2baa09d3-4a1d-4973-8872-170cb5432bde@github.com>
References: <tAJIUt9u0ZDYHBmSdyuItQqlrh0wWBAbPEjpK17JlP8=.55ba3fd8-4b5a-47bb-9550-6322e3d8c303@github.com>
 <raia13plfZ-BS23NceXuwYp6Ns4TrAtw5EeLCH7VGww=.2baa09d3-4a1d-4973-8872-170cb5432bde@github.com>
Message-ID: <8NCZpFiEVPPZuc3ceO4fIeZ-NUHD-y38tMVht9ddowo=.e11fb128-b21c-42c5-bdd2-e60065980123@github.com>

On Tue, 13 Dec 2022 22:00:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> These access flags were implemented to enable passing access flag values from Method* to InstanceKlass*, but only covered one flag.  Towards only have access flags represent read-only flags in the class file, remove this and pass has_localvariable_table up to InstanceKlass in classfile parsing, like we do with other flags.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a space

Changes looks good. One query below.

Thanks.

src/hotspot/share/oops/instanceKlassMiscStatus.cpp line 64:

> 62: #ifdef ASSERT
> 63: void InstanceKlassMiscStatus::assert_is_safe(bool set) {
> 64:   // Setting a flag is safe if it's set once or at a safepoint. RedefineClasses can set or

Is this a generally true statement, or only true for specific flags?

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11655

From dholmes at openjdk.org  Wed Dec 14 00:59:19 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 14 Dec 2022 00:59:19 GMT
Subject: RFR: 8298636: Fix return value in WB_CountAliveClasses and
 WB_GetSymbolRefcount
In-Reply-To: <5CSk9c7fs5uIR4No4c-fRsGsl70bLAIzOlnW_QeHEAg=.241eac0e-28dc-4963-9bc5-a06e9491df29@github.com>
References: <5CSk9c7fs5uIR4No4c-fRsGsl70bLAIzOlnW_QeHEAg=.241eac0e-28dc-4963-9bc5-a06e9491df29@github.com>
Message-ID: <BNdVemiOmoBNIDrIEOBOPgTjoez97A7UFFhSU4DNGCY=.87c30575-9bfe-4a10-a1e7-b411a247677b@github.com>

On Tue, 13 Dec 2022 08:26:43 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of conforming to the return type.

Good and trivial.

Thanks.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11643

From mennen at openjdk.org  Wed Dec 14 03:47:06 2022
From: mennen at openjdk.org (Michael Ennen)
Date: Wed, 14 Dec 2022 03:47:06 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview) [v39]
In-Reply-To: <hkjubM7yW4kkYAetu0kuCJy9wPQ_Llluj47lYXIc_8A=.2fc0c63b-d71f-4b18-af52-a6aa286b742d@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
 <-V_N0Cvh4J0vKNbBYdFcow9E8yFHRIjya8n69MpDSuY=.9626ee4d-95b6-41e4-b21e-395e79840388@github.com>
 <hkjubM7yW4kkYAetu0kuCJy9wPQ_Llluj47lYXIc_8A=.2fc0c63b-d71f-4b18-af52-a6aa286b742d@github.com>
Message-ID: <91WlM45Ykemls6D5vtXZMIIqjjECQTLVuJFhTLYXq-I=.4e670ac0-f1ff-480e-b18e-cea98d01bd6f@github.com>

On Mon, 5 Dec 2022 13:46:09 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix Preview annotation for JEP 434
>
> Note: there are 4 tests failing in x86:
> * MemoryLayoutPrincipalTotalityTest
> * MemoryLayoutTypeRetentionTest
> * TestLargeSegmentCopy
> * TestLinker
> 
> These failures are addressed in the dependent PR: https://git.openjdk.org/jdk/pull/11019, which will be integrated immediately after these changes

@mcimadamore This PR made my code in [java-vulkan](https://github.com/brcolow/java-vulkan/commit/171f167782eea538b19b60d5fa73e9f75a112f6d) much cleaner! Nice work!

-------------

PR: https://git.openjdk.org/jdk/pull/10872

From aboldtch at openjdk.org  Wed Dec 14 06:57:56 2022
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 14 Dec 2022 06:57:56 GMT
Subject: RFR: 8296401: ConcurrentHashTable::bulk_delete might miss to
 delete some objects [v5]
In-Reply-To: <3Fnpqamf7GB_EaNVYVO-yuykUOzwhOOCOf_sIBE4334=.7951828c-1e7f-499c-883c-a2f239df28c0@github.com>
References: <rWw3Hb1baG5eslMgFnOdEP1Q4avhfYc3uTpjdB9DaP0=.23f34ff0-eff9-421b-9e70-7f119fd90e5d@github.com>
 <3Fnpqamf7GB_EaNVYVO-yuykUOzwhOOCOf_sIBE4334=.7951828c-1e7f-499c-883c-a2f239df28c0@github.com>
Message-ID: <kDmF4W0mG19nPuvezxtdGcktjEVz7AwfYqUR0joS1gk=.b17734fd-be91-4eae-8709-33c79b8c2706@github.com>

On Fri, 9 Dec 2022 19:54:48 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> ConcurrentHashTable::bulk_delete might miss to delete some objects if a bucket has more than 256 entries. Current uses of ConcurrentHashTable are not harmed by this behaviour. 
>> 
>> I modified gtest:ConcurrentHashTable to detect the problem (first commit), and fixed the problem in the code (second commit).
>> 
>> Tests passes tier1-3.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   GrowableArray is indexed by int :-(

Marked as reviewed by aboldtch (Committer).

-------------

PR: https://git.openjdk.org/jdk/pull/10983

From rcastanedalo at openjdk.org  Wed Dec 14 10:04:12 2022
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 14 Dec 2022 10:04:12 GMT
Subject: [jdk20] RFR: 8297235: ZGC: assert(regs[i] != regs[j]) failed:
 Multiple uses of register: rax
In-Reply-To: <Hk-XWr3tjPojiZAg7anEvGBzvKcG6j12qh7-FwGkUbc=.aedb34a9-ae5e-44a5-82c9-406be2992f1a@github.com>
References: <Hk-XWr3tjPojiZAg7anEvGBzvKcG6j12qh7-FwGkUbc=.aedb34a9-ae5e-44a5-82c9-406be2992f1a@github.com>
Message-ID: <RRwia7OpQuff9QUu2GUxb5t0dFE01HoskBG8NVmBx2U=.e7fc492a-b13b-4235-a3bf-76f6d0fe2b60@github.com>

On Tue, 13 Dec 2022 15:51:45 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [042b7062](https://github.com/openjdk/jdk/commit/042b7062f19b313f31b228bd96d2a74cc1165ab9) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Axel Boldt-Christmas on 13 Dec 2022 and was reviewed by Erik ?sterlund, Albert Mingkun Yang and Roberto Casta?eda Lozano.
> 
> Thanks!

Marked as reviewed by rcastanedalo (Reviewer).

-------------

PR: https://git.openjdk.org/jdk20/pull/25

From stefank at openjdk.org  Wed Dec 14 11:11:00 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 14 Dec 2022 11:11:00 GMT
Subject: RFR: 8298376: ZGC: thaws stackChunk with stale oops [v2]
In-Reply-To: <HoYZilP9V9gNhBjvJzCmxzE2wMzs5TmM_qjZZof_fi4=.0819f7cc-ec68-4847-a46a-3af928339415@github.com>
References: <HoYZilP9V9gNhBjvJzCmxzE2wMzs5TmM_qjZZof_fi4=.0819f7cc-ec68-4847-a46a-3af928339415@github.com>
Message-ID: <pHBwcZ_hftW5MlGNoh0ipgaPM6sJ2FYj4iageOOnmp4=.3b8e884b-d4db-409f-9fdf-e87421e97bfe@github.com>

> During the recent ZGC + Loom rewrites JDK-8296875 a bug was introduced, which causes Loom to thaw stackChunks with stale oops.
> 
> Before that change we made sure that only the GC performed load barriers on the cont oop in stackChunk, so that we could use the oop state as an indication of the age of the stackChunk. That information was then used in ZCollectedHeap::requires_barriers.
> 
> In Generational ZGC we changed the implementation of requires_barriers, so that the rest of the JVM didn't need to have special-handling of the cont oop. However, when upstreaming the changes in JDK-8296875 we purposefully didn't update requires_barriers, but we incorrectly brought over the removal of the special-handling of the cont oop.
> 
> To limit the fix for this bug, I propose that we restore the special-handling of the cont oop.
> 
> I've tested this with a reproducer running Fuzz.java + ZGC.

Stefan Karlsson has updated the pull request incrementally with 104 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into 8298376_zgc_loom_thaw_stale_oops
 - 8298371: monitors_on_stack extracts unprocessed oops
   
   Reviewed-by: pchilanomate, rehn
 - 8298513: vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy009/TestDescription.java fails with usage tracker
   
   Reviewed-by: cjplummer, sspitsyn, lmesnik
 - 8298514: vmTestbase/nsk/jdi/EventRequestManager/threadDeathRequests/thrdeathreq002/TestDescription.java fails with usage tracker
   
   Reviewed-by: cjplummer, sspitsyn
 - 8298524: Debug function to trace reachability of CDS archived heap objects
   
   Reviewed-by: ccheung
 - Merge
 - 8298084: Memory leak in Method::build_profiling_method_data
   
   Co-authored-by: Justin King <jcking at openjdk.org>
   Reviewed-by: kbarrett, eosterlund, dholmes, jcking, thartmann
 - 8296955: Kitchensink.java failed with "double free or corruption (!prev): <addr>"
   
   Reviewed-by: kbarrett, eosterlund, sspitsyn, dcubed
 - 8298488: [macos13] tools/jpackage tests failing with "Exit code: 137" on macOS
   
   Reviewed-by: asemenyuk
 - 8297288: Example code in Scanner class
   
   Reviewed-by: lancea, bpb, alanb
 - ... and 94 more: https://git.openjdk.org/jdk/compare/bb7183bf...da98a785

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11585/files
  - new: https://git.openjdk.org/jdk/pull/11585/files/bb7183bf..da98a785

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11585&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11585&range=00-01

  Stats: 20519 lines in 493 files changed: 14764 ins; 4129 del; 1626 mod
  Patch: https://git.openjdk.org/jdk/pull/11585.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11585/head:pull/11585

PR: https://git.openjdk.org/jdk/pull/11585

From ayang at openjdk.org  Wed Dec 14 12:45:55 2022
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 14 Dec 2022 12:45:55 GMT
Subject: RFR: 8298636: Fix return value in WB_CountAliveClasses and
 WB_GetSymbolRefcount
In-Reply-To: <5CSk9c7fs5uIR4No4c-fRsGsl70bLAIzOlnW_QeHEAg=.241eac0e-28dc-4963-9bc5-a06e9491df29@github.com>
References: <5CSk9c7fs5uIR4No4c-fRsGsl70bLAIzOlnW_QeHEAg=.241eac0e-28dc-4963-9bc5-a06e9491df29@github.com>
Message-ID: <Ain4vf_3nN_UsUpKIPXKl9dBZDlpvKZpm75D2_thfSs=.3bb25e1e-eed6-4d36-a391-e4cba823fb7c@github.com>

On Tue, 13 Dec 2022 08:26:43 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of conforming to the return type.

Thanks for the review.

-------------

PR: https://git.openjdk.org/jdk/pull/11643

From coleenp at openjdk.org  Wed Dec 14 12:49:08 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 14 Dec 2022 12:49:08 GMT
Subject: RFR: 8298475: Remove JVM_ACC_PROMOTED_FLAGS [v3]
In-Reply-To: <tAJIUt9u0ZDYHBmSdyuItQqlrh0wWBAbPEjpK17JlP8=.55ba3fd8-4b5a-47bb-9550-6322e3d8c303@github.com>
References: <tAJIUt9u0ZDYHBmSdyuItQqlrh0wWBAbPEjpK17JlP8=.55ba3fd8-4b5a-47bb-9550-6322e3d8c303@github.com>
Message-ID: <YLa3GZtaLqAAYOOctrLD8BSATqE_narazrYiylom034=.5a549ae0-2df7-4dd8-a1ee-c7b86d87ae07@github.com>

> These access flags were implemented to enable passing access flag values from Method* to InstanceKlass*, but only covered one flag.  Towards only have access flags represent read-only flags in the class file, remove this and pass has_localvariable_table up to InstanceKlass in classfile parsing, like we do with other flags.
> Tested with tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Missed a comment fix.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11655/files
  - new: https://git.openjdk.org/jdk/pull/11655/files/90ec438a..346317a4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11655&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11655&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11655.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11655/head:pull/11655

PR: https://git.openjdk.org/jdk/pull/11655

From coleenp at openjdk.org  Wed Dec 14 12:49:08 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 14 Dec 2022 12:49:08 GMT
Subject: RFR: 8298475: Remove JVM_ACC_PROMOTED_FLAGS [v2]
In-Reply-To: <raia13plfZ-BS23NceXuwYp6Ns4TrAtw5EeLCH7VGww=.2baa09d3-4a1d-4973-8872-170cb5432bde@github.com>
References: <tAJIUt9u0ZDYHBmSdyuItQqlrh0wWBAbPEjpK17JlP8=.55ba3fd8-4b5a-47bb-9550-6322e3d8c303@github.com>
 <raia13plfZ-BS23NceXuwYp6Ns4TrAtw5EeLCH7VGww=.2baa09d3-4a1d-4973-8872-170cb5432bde@github.com>
Message-ID: <idc_Z7TW8r1s6bPH6HusXtW6KJRHyxBuOv9-vcT9o38=.38caaa56-3d5f-4fb3-8417-0c8e2db278bb@github.com>

On Tue, 13 Dec 2022 22:00:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> These access flags were implemented to enable passing access flag values from Method* to InstanceKlass*, but only covered one flag.  Towards only have access flags represent read-only flags in the class file, remove this and pass has_localvariable_table up to InstanceKlass in classfile parsing, like we do with other flags.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a space

Thanks for the reviews, Serguei, Dan and David.  I missed fixing a comment but it's trivial.

-------------

PR: https://git.openjdk.org/jdk/pull/11655

From coleenp at openjdk.org  Wed Dec 14 12:49:09 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 14 Dec 2022 12:49:09 GMT
Subject: RFR: 8298475: Remove JVM_ACC_PROMOTED_FLAGS [v2]
In-Reply-To: <8NCZpFiEVPPZuc3ceO4fIeZ-NUHD-y38tMVht9ddowo=.e11fb128-b21c-42c5-bdd2-e60065980123@github.com>
References: <tAJIUt9u0ZDYHBmSdyuItQqlrh0wWBAbPEjpK17JlP8=.55ba3fd8-4b5a-47bb-9550-6322e3d8c303@github.com>
 <raia13plfZ-BS23NceXuwYp6Ns4TrAtw5EeLCH7VGww=.2baa09d3-4a1d-4973-8872-170cb5432bde@github.com>
 <8NCZpFiEVPPZuc3ceO4fIeZ-NUHD-y38tMVht9ddowo=.e11fb128-b21c-42c5-bdd2-e60065980123@github.com>
Message-ID: <FEYLf88BVTnF1sD4lat6FUQj8qDZgC-HqWYYXbSjkOI=.8f783344-baeb-40be-bf15-58f6d7fa0d20@github.com>

On Wed, 14 Dec 2022 00:51:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add a space
>
> src/hotspot/share/oops/instanceKlassMiscStatus.cpp line 64:
> 
>> 62: #ifdef ASSERT
>> 63: void InstanceKlassMiscStatus::assert_is_safe(bool set) {
>> 64:   // Setting a flag is safe if it's set once or at a safepoint. RedefineClasses can set or
> 
> Is this a generally true statement, or only true for specific flags?

For InstanceKlass, it's true.  There are flags that are set at runtime outside a safepoint that require atomic bit set (is_being_redefined for example) that are in AccessFlags.  They would fail this test.  The flags in MiscStatus::_flags pass this test.

-------------

PR: https://git.openjdk.org/jdk/pull/11655

From ayang at openjdk.org  Wed Dec 14 12:49:21 2022
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 14 Dec 2022 12:49:21 GMT
Subject: Integrated: 8298636: Fix return value in WB_CountAliveClasses and
 WB_GetSymbolRefcount
In-Reply-To: <5CSk9c7fs5uIR4No4c-fRsGsl70bLAIzOlnW_QeHEAg=.241eac0e-28dc-4963-9bc5-a06e9491df29@github.com>
References: <5CSk9c7fs5uIR4No4c-fRsGsl70bLAIzOlnW_QeHEAg=.241eac0e-28dc-4963-9bc5-a06e9491df29@github.com>
Message-ID: <Pc-H8JKKqCkxzGHveeSZW1otB-NOYsmhi1DW78tGKVA=.9b42152a-eaa9-4e58-9420-58a95a6dcd34@github.com>

On Tue, 13 Dec 2022 08:26:43 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of conforming to the return type.

This pull request has now been integrated.

Changeset: 9ee50370
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9ee5037055a85a5d457a31392dc4ce1ca6c47768
Stats:     6 lines in 1 file changed: 4 ins; 0 del; 2 mod

8298636: Fix return value in WB_CountAliveClasses and WB_GetSymbolRefcount

Reviewed-by: dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/11643

From coleenp at openjdk.org  Wed Dec 14 12:53:13 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 14 Dec 2022 12:53:13 GMT
Subject: Integrated: 8298475: Remove JVM_ACC_PROMOTED_FLAGS
In-Reply-To: <tAJIUt9u0ZDYHBmSdyuItQqlrh0wWBAbPEjpK17JlP8=.55ba3fd8-4b5a-47bb-9550-6322e3d8c303@github.com>
References: <tAJIUt9u0ZDYHBmSdyuItQqlrh0wWBAbPEjpK17JlP8=.55ba3fd8-4b5a-47bb-9550-6322e3d8c303@github.com>
Message-ID: <jfJnkmw57OeKRz1_wPJP_342LHY8RpCMzLw57CTGWzg=.5d77b717-3a2e-49fe-a4c5-0534eedb7024@github.com>

On Tue, 13 Dec 2022 18:28:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> These access flags were implemented to enable passing access flag values from Method* to InstanceKlass*, but only covered one flag.  Towards only have access flags represent read-only flags in the class file, remove this and pass has_localvariable_table up to InstanceKlass in classfile parsing, like we do with other flags.
> Tested with tier1-4.

This pull request has now been integrated.

Changeset: 2e801e16
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2e801e16ec40ce0e25d8679e21d7da347c52d7be
Stats:     63 lines in 10 files changed: 21 ins; 22 del; 20 mod

8298475: Remove JVM_ACC_PROMOTED_FLAGS

Reviewed-by: sspitsyn, dcubed, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/11655

From coleenp at openjdk.org  Wed Dec 14 13:11:05 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 14 Dec 2022 13:11:05 GMT
Subject: RFR: 8298376: ZGC: thaws stackChunk with stale oops [v2]
In-Reply-To: <pHBwcZ_hftW5MlGNoh0ipgaPM6sJ2FYj4iageOOnmp4=.3b8e884b-d4db-409f-9fdf-e87421e97bfe@github.com>
References: <HoYZilP9V9gNhBjvJzCmxzE2wMzs5TmM_qjZZof_fi4=.0819f7cc-ec68-4847-a46a-3af928339415@github.com>
 <pHBwcZ_hftW5MlGNoh0ipgaPM6sJ2FYj4iageOOnmp4=.3b8e884b-d4db-409f-9fdf-e87421e97bfe@github.com>
Message-ID: <S_9VuNSpJCk1ggj6uXZF8WnHiJMaZ9A3xvpZTzgrOCU=.8b2ffe93-f4e5-4e99-a156-6edbbff6599d@github.com>

On Wed, 14 Dec 2022 11:11:00 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> During the recent ZGC + Loom rewrites JDK-8296875 a bug was introduced, which causes Loom to thaw stackChunks with stale oops.
>> 
>> Before that change we made sure that only the GC performed load barriers on the cont oop in stackChunk, so that we could use the oop state as an indication of the age of the stackChunk. That information was then used in ZCollectedHeap::requires_barriers.
>> 
>> In Generational ZGC we changed the implementation of requires_barriers, so that the rest of the JVM didn't need to have special-handling of the cont oop. However, when upstreaming the changes in JDK-8296875 we purposefully didn't update requires_barriers, but we incorrectly brought over the removal of the special-handling of the cont oop.
>> 
>> To limit the fix for this bug, I propose that we restore the special-handling of the cont oop.
>> 
>> I've tested this with a reproducer running Fuzz.java + ZGC.
>
> Stefan Karlsson has updated the pull request incrementally with 104 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8298376_zgc_loom_thaw_stale_oops
>  - 8298371: monitors_on_stack extracts unprocessed oops
>    
>    Reviewed-by: pchilanomate, rehn
>  - 8298513: vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy009/TestDescription.java fails with usage tracker
>    
>    Reviewed-by: cjplummer, sspitsyn, lmesnik
>  - 8298514: vmTestbase/nsk/jdi/EventRequestManager/threadDeathRequests/thrdeathreq002/TestDescription.java fails with usage tracker
>    
>    Reviewed-by: cjplummer, sspitsyn
>  - 8298524: Debug function to trace reachability of CDS archived heap objects
>    
>    Reviewed-by: ccheung
>  - Merge
>  - 8298084: Memory leak in Method::build_profiling_method_data
>    
>    Co-authored-by: Justin King <jcking at openjdk.org>
>    Reviewed-by: kbarrett, eosterlund, dholmes, jcking, thartmann
>  - 8296955: Kitchensink.java failed with "double free or corruption (!prev): <addr>"
>    
>    Reviewed-by: kbarrett, eosterlund, sspitsyn, dcubed
>  - 8298488: [macos13] tools/jpackage tests failing with "Exit code: 137" on macOS
>    
>    Reviewed-by: asemenyuk
>  - 8297288: Example code in Scanner class
>    
>    Reviewed-by: lancea, bpb, alanb
>  - ... and 94 more: https://git.openjdk.org/jdk/compare/bb7183bf...da98a785

Should this be fixed for JDK 20?

-------------

PR: https://git.openjdk.org/jdk/pull/11585

From stefank at openjdk.org  Wed Dec 14 13:14:55 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 14 Dec 2022 13:14:55 GMT
Subject: RFR: 8298376: ZGC: thaws stackChunk with stale oops [v2]
In-Reply-To: <S_9VuNSpJCk1ggj6uXZF8WnHiJMaZ9A3xvpZTzgrOCU=.8b2ffe93-f4e5-4e99-a156-6edbbff6599d@github.com>
References: <HoYZilP9V9gNhBjvJzCmxzE2wMzs5TmM_qjZZof_fi4=.0819f7cc-ec68-4847-a46a-3af928339415@github.com>
 <pHBwcZ_hftW5MlGNoh0ipgaPM6sJ2FYj4iageOOnmp4=.3b8e884b-d4db-409f-9fdf-e87421e97bfe@github.com>
 <S_9VuNSpJCk1ggj6uXZF8WnHiJMaZ9A3xvpZTzgrOCU=.8b2ffe93-f4e5-4e99-a156-6edbbff6599d@github.com>
Message-ID: <Ysk98j4-Apxq7-EMbU4jsGjrkEAdtE-bTqfFs8AxjQs=.e796145d-6566-4106-ad10-b52e440f84a0@github.com>

On Wed, 14 Dec 2022 13:09:05 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Should this be fixed for JDK 20?

Yes. I'll backport this after pushing to 21.

-------------

PR: https://git.openjdk.org/jdk/pull/11585

From duke at openjdk.org  Wed Dec 14 13:16:03 2022
From: duke at openjdk.org (Afshin Zafari)
Date: Wed, 14 Dec 2022 13:16:03 GMT
Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v7]
In-Reply-To: <lwKPbL65Fiqa0ltWWTC8yJLzRWOGSMwR61Bp1gyBECI=.bd37636f-3ec8-4977-9acc-fb315a93b7b3@github.com>
References: <Dj9YfY10SLn8dR1Ez3kEQe4tXm1q5W1TS8_4r3gBUsY=.6c38825a-86e5-4575-a509-683786d242a6@github.com>
 <pRcbuNmrpRkRA8lOJfYlEVWo3W766EMs6Gw5raXbZPs=.66222c03-5a36-43be-a9c9-080d046d73d7@github.com>
 <lwKPbL65Fiqa0ltWWTC8yJLzRWOGSMwR61Bp1gyBECI=.bd37636f-3ec8-4977-9acc-fb315a93b7b3@github.com>
Message-ID: <Q9-fSqxoZsiloyzne4d6xkMVHyodymvBSTnFGsUP6_E=.c6fb8602-b14e-4636-ac24-5fd1b354f093@github.com>

On Mon, 12 Dec 2022 17:58:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8292741: Convert JvmtiTagMapTable to ResourceHashtable
>
> src/hotspot/share/prims/jvmtiTagMapTable.cpp line 117:
> 
>> 115: JvmtiTagMapEntry* JvmtiTagMapTable::find(oop obj) {
>> 116:   if (obj->fast_no_hash_check()) {
>> 117:     // Objects in the table all have a hashcode.
> 
> Can you keep this comment?

Done

> src/hotspot/share/prims/jvmtiTagMapTable.hpp line 72:
> 
>> 70: typedef
>> 71: ResizeableResourceHashtable <JvmtiTagMapKey, jlong,
>> 72:                               AnyObj::C_HEAP, mtInternal,
> 
> This should be mtServiceability rather than mtInternal.

Done

-------------

PR: https://git.openjdk.org/jdk/pull/11288

From duke at openjdk.org  Wed Dec 14 13:30:10 2022
From: duke at openjdk.org (Afshin Zafari)
Date: Wed, 14 Dec 2022 13:30:10 GMT
Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v7]
In-Reply-To: <AYhCxPKMsfdFV8iiAy9oHn4vtW8qd5zJPEbJQb6qZBk=.70e1d24b-fdbd-4d62-8319-073247eae8b6@github.com>
References: <Dj9YfY10SLn8dR1Ez3kEQe4tXm1q5W1TS8_4r3gBUsY=.6c38825a-86e5-4575-a509-683786d242a6@github.com>
 <pRcbuNmrpRkRA8lOJfYlEVWo3W766EMs6Gw5raXbZPs=.66222c03-5a36-43be-a9c9-080d046d73d7@github.com>
 <AYhCxPKMsfdFV8iiAy9oHn4vtW8qd5zJPEbJQb6qZBk=.70e1d24b-fdbd-4d62-8319-073247eae8b6@github.com>
Message-ID: <HRWkSOl_pNUKuNpFlYFO_2i38XzEVvpQZysch4DFGXE=.574941d1-6991-445e-882a-796b467a8a6b@github.com>

On Mon, 12 Dec 2022 00:40:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8292741: Convert JvmtiTagMapTable to ResourceHashtable
>
> src/hotspot/share/prims/jvmtiTagMap.cpp line 1262:
> 
>> 1260:   // and record the reference and tag value.
>> 1261:   //
>> 1262:   bool do_entry(JvmtiTagMapKey& key, jlong& value) {
> 
> I still see no point in this method returning a bool when it only ever returns true.

In the `iterate` method of ResourceHashTable, in respurceHash.hpp lines 227-240 copied here, requires a function that returns boolean. If returned false the iterate will break.

 template<typename Function>
  void iterate(Function function) const { // lambda enabled API
    Node* const* bucket = table();
    const unsigned sz = table_size();
    while (bucket < bucket_at(sz)) {
      Node* node = *bucket;
      while (node != NULL) {
        bool cont = function(node->_key, node->_value);    // <--------------******
        if (!cont) { return; }
        node = node->_next;
      }
      ++bucket;
    }
  }

The other `iterate` methods are wrappers around this one.
Always returning true means to continue iterating over all the existing items. 
The former base table for jvmtiTagMapTable needs the `do_entry` be `void`.

-------------

PR: https://git.openjdk.org/jdk/pull/11288

From aph at openjdk.org  Wed Dec 14 13:35:03 2022
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 14 Dec 2022 13:35:03 GMT
Subject: [jdk20] Integrated: JDK-8294902: Undefined Behavior in C2 regalloc
 with null references
In-Reply-To: <HbMCF1mYRJV5TEjuO4iGR6qxMPRr8V5yTHXEynHr1zk=.1844dbc0-dd13-458b-8c9a-f618038ef8af@github.com>
References: <HbMCF1mYRJV5TEjuO4iGR6qxMPRr8V5yTHXEynHr1zk=.1844dbc0-dd13-458b-8c9a-f618038ef8af@github.com>
Message-ID: <OrsNo0xQ_e0Nf_JEJbaU3tJqXM8yqQMGRCjgvfji8ZE=.3952536f-980f-432d-b334-25c89dda5892@github.com>

On Tue, 13 Dec 2022 16:27:37 GMT, Andrew Haley <aph at openjdk.org> wrote:

> JDK-8294902: Undefined Behavior in C2 regalloc with null references

This pull request has now been integrated.

Changeset: 0bbc4181
Author:    Andrew Haley <aph at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/0bbc4181cdbccfc3a542f306ce1902cc2e9f36cb
Stats:     64 lines in 7 files changed: 28 ins; 1 del; 35 mod

8294902: Undefined Behavior in C2 regalloc with null references

Reviewed-by: kvn, vlivanov

-------------

PR: https://git.openjdk.org/jdk20/pull/26

From lkorinth at openjdk.org  Wed Dec 14 14:04:18 2022
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 14 Dec 2022 14:04:18 GMT
Subject: RFR: 8292170: Convert CodeRootSetTable to use ResourceHashtable
Message-ID: <BdRsUwTHeM7gAUg1udRTeG-gv2S4slO0zYl5Ys21Pyw=.5701b960-0ecb-4c67-9d11-88d103b2bd0f@github.com>

I am replacing the old hash table with ResourceHashtable. In the process I am also removing the redundant `_length` field. By removing the `_length` field, a lot of asserts can be removed as the length will trivially match the length of the underlying table.

I would like to have feedback on the addition of `unlink_destruct(Function&& should_remove)`. I added it because I prefer to use a functor object that can be used by lambdas instead of an iterator object. However, I did add code to "destruct" resource objects when they are removed instead of just letting them be to reflect that we use `delete` on c-heap objects. Maybe I should remove this "improvement" and then maybe implement the function by calling the existing unlink?

-------------

Commit messages:
 - 8292170: Convert CodeRootSetTable to use ResourceHashtable

Changes: https://git.openjdk.org/jdk/pull/11675/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11675&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292170
  Stats: 146 lines in 5 files changed: 38 ins; 83 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/11675.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11675/head:pull/11675

PR: https://git.openjdk.org/jdk/pull/11675

From aboldtch at openjdk.org  Wed Dec 14 14:13:03 2022
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 14 Dec 2022 14:13:03 GMT
Subject: [jdk20] Integrated: 8297235: ZGC: assert(regs[i] != regs[j]) failed:
 Multiple uses of register: rax
In-Reply-To: <Hk-XWr3tjPojiZAg7anEvGBzvKcG6j12qh7-FwGkUbc=.aedb34a9-ae5e-44a5-82c9-406be2992f1a@github.com>
References: <Hk-XWr3tjPojiZAg7anEvGBzvKcG6j12qh7-FwGkUbc=.aedb34a9-ae5e-44a5-82c9-406be2992f1a@github.com>
Message-ID: <u9TCaV5ZWhQRAOKDVNatFLyc_dEvisKSYTVeP49vx5Q=.d942a416-3531-4f03-a491-1e64e4b16b66@github.com>

On Tue, 13 Dec 2022 15:51:45 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [042b7062](https://github.com/openjdk/jdk/commit/042b7062f19b313f31b228bd96d2a74cc1165ab9) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Axel Boldt-Christmas on 13 Dec 2022 and was reviewed by Erik ?sterlund, Albert Mingkun Yang and Roberto Casta?eda Lozano.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 581f9f23
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/581f9f2306835680cd6d5dbbe37f610fb4de4677
Stats:     121 lines in 2 files changed: 21 ins; 90 del; 10 mod

8297235: ZGC: assert(regs[i] != regs[j]) failed: Multiple uses of register: rax

Reviewed-by: thartmann, rcastanedalo
Backport-of: 042b7062f19b313f31b228bd96d2a74cc1165ab9

-------------

PR: https://git.openjdk.org/jdk20/pull/25

From stefank at openjdk.org  Wed Dec 14 14:37:53 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 14 Dec 2022 14:37:53 GMT
Subject: Integrated: 8298376: ZGC: thaws stackChunk with stale oops
In-Reply-To: <HoYZilP9V9gNhBjvJzCmxzE2wMzs5TmM_qjZZof_fi4=.0819f7cc-ec68-4847-a46a-3af928339415@github.com>
References: <HoYZilP9V9gNhBjvJzCmxzE2wMzs5TmM_qjZZof_fi4=.0819f7cc-ec68-4847-a46a-3af928339415@github.com>
Message-ID: <9QDd_JcTpOv6qLdHF_x6VMJVBC4_pIfIGnQDRciEBq4=.6df7b737-fd6e-416a-bd9a-49f8d61343d8@github.com>

On Thu, 8 Dec 2022 11:05:10 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> During the recent ZGC + Loom rewrites JDK-8296875 a bug was introduced, which causes Loom to thaw stackChunks with stale oops.
> 
> Before that change we made sure that only the GC performed load barriers on the cont oop in stackChunk, so that we could use the oop state as an indication of the age of the stackChunk. That information was then used in ZCollectedHeap::requires_barriers.
> 
> In Generational ZGC we changed the implementation of requires_barriers, so that the rest of the JVM didn't need to have special-handling of the cont oop. However, when upstreaming the changes in JDK-8296875 we purposefully didn't update requires_barriers, but we incorrectly brought over the removal of the special-handling of the cont oop.
> 
> To limit the fix for this bug, I propose that we restore the special-handling of the cont oop.
> 
> I've tested this with a reproducer running Fuzz.java + ZGC.

This pull request has now been integrated.

Changeset: ed8a2120
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ed8a2120ca1e9756c6ab5eeebfe24c15d549f04e
Stats:     19 lines in 4 files changed: 15 ins; 0 del; 4 mod

8298376: ZGC: thaws stackChunk with stale oops

Reviewed-by: eosterlund, pchilanomate

-------------

PR: https://git.openjdk.org/jdk/pull/11585

From coleenp at openjdk.org  Wed Dec 14 14:52:42 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 14 Dec 2022 14:52:42 GMT
Subject: RFR: 8292170: Convert CodeRootSetTable to use ResourceHashtable
In-Reply-To: <BdRsUwTHeM7gAUg1udRTeG-gv2S4slO0zYl5Ys21Pyw=.5701b960-0ecb-4c67-9d11-88d103b2bd0f@github.com>
References: <BdRsUwTHeM7gAUg1udRTeG-gv2S4slO0zYl5Ys21Pyw=.5701b960-0ecb-4c67-9d11-88d103b2bd0f@github.com>
Message-ID: <WMe0NKYtTMct92Lr7n4l7-6w5xA-0AvLYjSoPXre-8k=.bdb90f9b-7d94-44c9-ba9b-dcfd6f12cef7@github.com>

On Wed, 14 Dec 2022 13:45:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> I am replacing the old hash table with ResourceHashtable. In the process I am also removing the redundant `_length` field. By removing the `_length` field, a lot of asserts can be removed as the length will trivially match the length of the underlying table.
> 
> I would like to have feedback on the addition of `unlink_destruct(Function&& should_remove)`. I added it because I prefer to use a functor object that can be used by lambdas instead of an iterator object. However, I did add code to "destruct" resource objects when they are removed instead of just letting them be to reflect that we use `delete` on c-heap objects. Maybe I should remove this "improvement" and then maybe implement the function by calling the existing unlink?

I'm happy to see this change coming!

src/hotspot/share/utilities/resourceHash.hpp line 277:

> 275:   }
> 276: 
> 277:   // The argument should_remove() have the signature: bool Function(K const&, V const&).

Can you make the unlink a separate change?  I think unlink with the Function argument should be an overload of unlink() and implemented like the iterate function. I don't immediately understand the additional &&s.
If it's a separate change, we can fix the other callers to use lambdas, which would be nicer.
Also, I think calling the ResourceObj destructor is another discussion - they are not typically used and I think the discussion should be somewhere else.

-------------

PR: https://git.openjdk.org/jdk/pull/11675

From duke at openjdk.org  Wed Dec 14 15:13:56 2022
From: duke at openjdk.org (Afshin Zafari)
Date: Wed, 14 Dec 2022 15:13:56 GMT
Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v7]
In-Reply-To: <AYhCxPKMsfdFV8iiAy9oHn4vtW8qd5zJPEbJQb6qZBk=.70e1d24b-fdbd-4d62-8319-073247eae8b6@github.com>
References: <Dj9YfY10SLn8dR1Ez3kEQe4tXm1q5W1TS8_4r3gBUsY=.6c38825a-86e5-4575-a509-683786d242a6@github.com>
 <pRcbuNmrpRkRA8lOJfYlEVWo3W766EMs6Gw5raXbZPs=.66222c03-5a36-43be-a9c9-080d046d73d7@github.com>
 <AYhCxPKMsfdFV8iiAy9oHn4vtW8qd5zJPEbJQb6qZBk=.70e1d24b-fdbd-4d62-8319-073247eae8b6@github.com>
Message-ID: <b9toj2PH0oXmGw518_K63jBcebPBdenErs2T7i0suYg=.f118313b-ea1e-4b7d-befa-8253f2250a33@github.com>

On Mon, 12 Dec 2022 00:50:27 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8292741: Convert JvmtiTagMapTable to ResourceHashtable
>
> src/hotspot/share/prims/jvmtiTagMapTable.cpp line 114:
> 
>> 112:   JvmtiTagMapKey new_entry(obj);
>> 113:   bool is_updated = _table.put(new_entry, tag) == false;
>> 114:   assert(is_updated, "should be updated and not added");
> 
> This API is confusing. You have `add` and `replace` but in product mode an `add` can `replace` and a `replace` can `add`. It isn't clear if these should be allowed rare conditions or fatal errors.

I agree that this is ambigious. The `jvmtiTagMap` calls `add/update` methods of `jvmtiTagMapTable` which in turn calls `resourceHashTable` methods `put` and `put_if_absent`.
`put` and `put_if_absent` can be used for both adding and updating and reporting it in returned values.
`jvmtiTagMap` calls to `jvmtiTagMapTable` add/update  DO NOT CARE about the returned values. For these calls, it doesn't mater if an add (update) method resulted in an update (add). 
So which one of the following cases would be correct?
 - Based on the `jvmtiTagMap` calls, let the add/update be void and ignore the differences of what really happens in the table. Or
 - Based on the `resourceHashTable` bool-valued `put` and `put_if_absent` methods, let the add/update be bool-values and leave the decision on "what really happened in the table" to the callers in `jvmtiTagMap`. (current implementation)

-------------

PR: https://git.openjdk.org/jdk/pull/11288

From rkennke at openjdk.org  Wed Dec 14 15:47:00 2022
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 14 Dec 2022 15:47:00 GMT
Subject: RFR: 8291555: Replace stack-locking with fast-locking [v8]
In-Reply-To: <Z8Gxg_4zh13llvce7INDaFCirCegSt2U56btzhfnfa4=.1a042e6a-b446-4dc2-887b-fd7cc3ca79c7@github.com>
References: <mgQHdsI_oHeWVQEOQNQLrfplcvatEauNPfq1rEswJF4=.cc842c02-e7e0-4f72-95a0-1033ce101cfe@github.com>
 <Z8Gxg_4zh13llvce7INDaFCirCegSt2U56btzhfnfa4=.1a042e6a-b446-4dc2-887b-fd7cc3ca79c7@github.com>
Message-ID: <uJzSX87ytRapdMh4cdkRgQsXuCe-m22S8r-Hxi0N_-M=.9942fa85-c496-426c-9165-8a3d53a19320@github.com>

On Fri, 28 Oct 2022 09:32:58 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change replaces the current stack-locking implementation with a fast-locking scheme that retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation. And because of the very racy nature, this turns out to be very complex and involved a variant of the inflation protocol to ensure that the object header is stable. 
>> 
>> What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock.
>> 
>> This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations. The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal protocols.
>> 
>> In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking.
>> 
>> One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread.
>> 
>> As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it.
>> 
>> This change enables to simplify (and speed-up!) a lot of code:
>> 
>> - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header.
>> - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR
>> 
>> ### Benchmarks
>> 
>> All benchmarks are run on server-class metal machines. The JVM settings are always: `-Xmx20g -Xms20g -XX:+UseParallelGC`. All benchmarks are ms/ops, less is better.
>> 
>> #### DaCapo/AArch64
>> 
>> Those measurements have been taken on a Graviton2 box with 64 CPU cores (an AWS m6g.metal instance). It is using DaCapo evaluation version, git hash 309e1fa (download file dacapo-evaluation-git+309e1fa.jar). I needed to exclude cassandra, h2o & kafka benchmarks because of incompatibility with JDK20. Benchmarks that showed results far off the baseline or showed high variance have been repeated and I am reporting results with the most bias *against* fast-locking. The sunflow benchmark is really far off the mark - the baseline run with stack-locking exhibited very high run-to-run variance and generally much worse performance, while with fast-locking the variance was very low and the results very stable between runs. I wouldn't trust that benchmark - I mean what is it actually doing that a change in locking shows >30% perf difference?
>> 
>> benchmark | baseline | fast-locking | % | size
>> -- | -- | -- | -- | --
>> avrora | 27859 | 27563 | 1.07% | large
>> batik | 20786 | 20847 | -0.29% | large
>> biojava | 27421 | 27334 | 0.32% | default
>> eclipse | 59918 | 60522 | -1.00% | large
>> fop | 3670 | 3678 | -0.22% | default
>> graphchi | 2088 | 2060 | 1.36% | default
>> h2 | 297391 | 291292 | 2.09% | huge
>> jme | 8762 | 8877 | -1.30% | default
>> jython | 18938 | 18878 | 0.32% | default
>> luindex | 1339 | 1325 | 1.06% | default
>> lusearch | 918 | 936 | -1.92% | default
>> pmd | 58291 | 58423 | -0.23% | large
>> sunflow | 32617 | 24961 | 30.67% | large
>> tomcat | 25481 | 25992 | -1.97% | large
>> tradebeans | 314640 | 311706 | 0.94% | huge
>> tradesoap | 107473 | 110246 | -2.52% | huge
>> xalan | 6047 | 5882 | 2.81% | default
>> zxing | 970 | 926 | 4.75% | default
>> 
>> #### DaCapo/x86_64
>> 
>> The following measurements have been taken on an Intel Xeon Scalable Processors (Cascade Lake 8252C) (an AWS m5zn.metal instance). All the same settings and considerations as in the measurements above.
>> 
>> benchmark | baseline | fast-Locking | % | size
>> -- | -- | -- | -- | --
>> avrora | 127690 | 126749 | 0.74% | large
>> batik | 12736 | 12641 | 0.75% | large
>> biojava | 15423 | 15404 | 0.12% | default
>> eclipse | 41174 | 41498 | -0.78% | large
>> fop | 2184 | 2172 | 0.55% | default
>> graphchi | 1579 | 1560 | 1.22% | default
>> h2 | 227614 | 230040 | -1.05% | huge
>> jme | 8591 | 8398 | 2.30% | default
>> jython | 13473 | 13356 | 0.88% | default
>> luindex | 824 | 813 | 1.35% | default
>> lusearch | 962 | 968 | -0.62% | default
>> pmd | 40827 | 39654 | 2.96% | large
>> sunflow | 53362 | 43475 | 22.74% | large
>> tomcat | 27549 | 28029 | -1.71% | large
>> tradebeans | 190757 | 190994 | -0.12% | huge
>> tradesoap | 68099 | 67934 | 0.24% | huge
>> xalan | 7969 | 8178 | -2.56% | default
>> zxing | 1176 | 1148 | 2.44% | default
>> 
>> #### Renaissance/AArch64
>> 
>> This tests Renaissance/JMH version 0.14.1 on same machines as DaCapo above, with same JVM settings.
>> 
>> benchmark | baseline | fast-locking | %
>> -- | -- | -- | --
>> AkkaUct | 2558.832 | 2513.594 | 1.80%
>> Reactors | 14715.626 | 14311.246 | 2.83%
>> Als | 1851.485 | 1869.622 | -0.97%
>> ChiSquare | 1007.788 | 1003.165 | 0.46%
>> GaussMix | 1157.491 | 1149.969 | 0.65%
>> LogRegression | 717.772 | 733.576 | -2.15%
>> MovieLens | 7916.181 | 8002.226 | -1.08%
>> NaiveBayes | 395.296 | 386.611 | 2.25%
>> PageRank | 4294.939 | 4346.333 | -1.18%
>> FjKmeans | 496.076 | 493.873 | 0.45%
>> FutureGenetic | 2578.504 | 2589.255 | -0.42%
>> Mnemonics | 4898.886 | 4903.689 | -0.10%
>> ParMnemonics | 4260.507 | 4210.121 | 1.20%
>> Scrabble | 139.37 | 138.312 | 0.76%
>> RxScrabble | 320.114 | 322.651 | -0.79%
>> Dotty | 1056.543 | 1068.492 | -1.12%
>> ScalaDoku | 3443.117 | 3449.477 | -0.18%
>> ScalaKmeans | 259.384 | 258.648 | 0.28%
>> Philosophers | 24333.311 | 23438.22 | 3.82%
>> ScalaStmBench7 | 1102.43 | 1115.142 | -1.14%
>> FinagleChirper | 6814.192 | 6853.38 | -0.57%
>> FinagleHttp | 4762.902 | 4807.564 | -0.93%
>> 
>> #### Renaissance/x86_64
>> 
>> benchmark | baseline | fast-locking | %
>> -- | -- | -- | --
>> AkkaUct | 1117.185 | 1116.425 | 0.07%
>> Reactors | 11561.354 | 11812.499 | -2.13%
>> Als | 1580.838 | 1575.318 | 0.35%
>> ChiSquare | 459.601 | 467.109 | -1.61%
>> GaussMix | 705.944 | 685.595 | 2.97%
>> LogRegression | 659.944 | 656.428 | 0.54%
>> MovieLens | 7434.303 | 7592.271 | -2.08%
>> NaiveBayes | 413.482 | 417.369 | -0.93%
>> PageRank | 3259.233 | 3276.589 | -0.53%
>> FjKmeans | 946.429 | 938.991 | 0.79%
>> FutureGenetic | 1760.672 | 1815.272 | -3.01%
>> ParMnemonics | 2016.917 | 2033.101 | -0.80%
>> Scrabble | 147.996 | 150.084 | -1.39%
>> RxScrabble | 177.755 | 177.956 | -0.11%
>> Dotty | 673.754 | 683.919 | -1.49%
>> ScalaDoku | 2193.562 | 1958.419 | 12.01%
>> ScalaKmeans | 165.376 | 168.925 | -2.10%
>> ScalaStmBench7 | 1080.187 | 1049.184 | 2.95%
>> Philosophers | 14268.449 | 13308.87 | 7.21%
>> FinagleChirper | 4722.13 | 4688.3 | 0.72%
>> FinagleHttp | 3497.241 | 3605.118 | -2.99%
>> 
>> Some renaissance benchmarks are missing: DecTree, DbShootout and Neo4jAnalytics are not compatible with JDK20. The remaining benchmarks show very high run-to-run variance, which I am investigating (and probably addressing with running them much more often.
>> 
>> I have also run another benchmark, which is a popular Java JVM benchmark, with workloads wrapped in JMH and very slightly modified to run with newer JDKs, but I won't publish the results because I am not sure about the licensing terms. They look similar to the measurements above (i.e. +/- 2%, nothing very suspicious).
>> 
>> Please let me know if you want me to run any other workloads, or, even better, run them yourself and report here.
>> 
>> ### Testing
>>  - [x] tier1 (x86_64, aarch64, x86_32)
>>  - [x] tier2 (x86_64, aarch64)
>>  - [x] tier3 (x86_64, aarch64)
>>  - [x] tier4 (x86_64, aarch64)
>>  - [x] jcstress 3-days -t sync -af GLOBAL (x86_64, aarch64)
>
> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into fast-locking
>  - Merge remote-tracking branch 'upstream/master' into fast-locking
>  - Merge remote-tracking branch 'upstream/master' into fast-locking
>  - More RISC-V fixes
>  - Merge remote-tracking branch 'origin/fast-locking' into fast-locking
>  - RISC-V port
>  - Revert "Re-use r0 in call to unlock_object()"
>    
>    This reverts commit ebbcb615a788998596f403b47b72cf133cb9de46.
>  - Merge remote-tracking branch 'origin/fast-locking' into fast-locking
>  - Fix number of rt args to complete_monitor_locking_C, remove some comments
>  - Re-use r0 in call to unlock_object()
>  - ... and 27 more: https://git.openjdk.org/jdk/compare/4b89fce0...3f0acba4

Closing this in favour of #10907.

-------------

PR: https://git.openjdk.org/jdk/pull/10590

From rkennke at openjdk.org  Wed Dec 14 15:47:01 2022
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 14 Dec 2022 15:47:01 GMT
Subject: Withdrawn: 8291555: Replace stack-locking with fast-locking
In-Reply-To: <mgQHdsI_oHeWVQEOQNQLrfplcvatEauNPfq1rEswJF4=.cc842c02-e7e0-4f72-95a0-1033ce101cfe@github.com>
References: <mgQHdsI_oHeWVQEOQNQLrfplcvatEauNPfq1rEswJF4=.cc842c02-e7e0-4f72-95a0-1033ce101cfe@github.com>
Message-ID: <p0EgZVB2jmWeP-jWPkdBsETwo6oZKzSe73JyLlhsve8=.e3fd0bca-7c0d-4b9e-97f9-75f2fd5c054a@github.com>

On Thu, 6 Oct 2022 10:23:04 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> This change replaces the current stack-locking implementation with a fast-locking scheme that retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation. And because of the very racy nature, this turns out to be very complex and involved a variant of the inflation protocol to ensure that the object header is stable. 
> 
> What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock.
> 
> This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations. The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal protocols.
> 
> In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking.
> 
> One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread.
> 
> As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it.
> 
> This change enables to simplify (and speed-up!) a lot of code:
> 
> - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header.
> - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR
> 
> ### Benchmarks
> 
> All benchmarks are run on server-class metal machines. The JVM settings are always: `-Xmx20g -Xms20g -XX:+UseParallelGC`. All benchmarks are ms/ops, less is better.
> 
> #### DaCapo/AArch64
> 
> Those measurements have been taken on a Graviton2 box with 64 CPU cores (an AWS m6g.metal instance). It is using DaCapo evaluation version, git hash 309e1fa (download file dacapo-evaluation-git+309e1fa.jar). I needed to exclude cassandra, h2o & kafka benchmarks because of incompatibility with JDK20. Benchmarks that showed results far off the baseline or showed high variance have been repeated and I am reporting results with the most bias *against* fast-locking. The sunflow benchmark is really far off the mark - the baseline run with stack-locking exhibited very high run-to-run variance and generally much worse performance, while with fast-locking the variance was very low and the results very stable between runs. I wouldn't trust that benchmark - I mean what is it actually doing that a change in locking shows >30% perf difference?
> 
> benchmark | baseline | fast-locking | % | size
> -- | -- | -- | -- | --
> avrora | 27859 | 27563 | 1.07% | large
> batik | 20786 | 20847 | -0.29% | large
> biojava | 27421 | 27334 | 0.32% | default
> eclipse | 59918 | 60522 | -1.00% | large
> fop | 3670 | 3678 | -0.22% | default
> graphchi | 2088 | 2060 | 1.36% | default
> h2 | 297391 | 291292 | 2.09% | huge
> jme | 8762 | 8877 | -1.30% | default
> jython | 18938 | 18878 | 0.32% | default
> luindex | 1339 | 1325 | 1.06% | default
> lusearch | 918 | 936 | -1.92% | default
> pmd | 58291 | 58423 | -0.23% | large
> sunflow | 32617 | 24961 | 30.67% | large
> tomcat | 25481 | 25992 | -1.97% | large
> tradebeans | 314640 | 311706 | 0.94% | huge
> tradesoap | 107473 | 110246 | -2.52% | huge
> xalan | 6047 | 5882 | 2.81% | default
> zxing | 970 | 926 | 4.75% | default
> 
> #### DaCapo/x86_64
> 
> The following measurements have been taken on an Intel Xeon Scalable Processors (Cascade Lake 8252C) (an AWS m5zn.metal instance). All the same settings and considerations as in the measurements above.
> 
> benchmark | baseline | fast-Locking | % | size
> -- | -- | -- | -- | --
> avrora | 127690 | 126749 | 0.74% | large
> batik | 12736 | 12641 | 0.75% | large
> biojava | 15423 | 15404 | 0.12% | default
> eclipse | 41174 | 41498 | -0.78% | large
> fop | 2184 | 2172 | 0.55% | default
> graphchi | 1579 | 1560 | 1.22% | default
> h2 | 227614 | 230040 | -1.05% | huge
> jme | 8591 | 8398 | 2.30% | default
> jython | 13473 | 13356 | 0.88% | default
> luindex | 824 | 813 | 1.35% | default
> lusearch | 962 | 968 | -0.62% | default
> pmd | 40827 | 39654 | 2.96% | large
> sunflow | 53362 | 43475 | 22.74% | large
> tomcat | 27549 | 28029 | -1.71% | large
> tradebeans | 190757 | 190994 | -0.12% | huge
> tradesoap | 68099 | 67934 | 0.24% | huge
> xalan | 7969 | 8178 | -2.56% | default
> zxing | 1176 | 1148 | 2.44% | default
> 
> #### Renaissance/AArch64
> 
> This tests Renaissance/JMH version 0.14.1 on same machines as DaCapo above, with same JVM settings.
> 
> benchmark | baseline | fast-locking | %
> -- | -- | -- | --
> AkkaUct | 2558.832 | 2513.594 | 1.80%
> Reactors | 14715.626 | 14311.246 | 2.83%
> Als | 1851.485 | 1869.622 | -0.97%
> ChiSquare | 1007.788 | 1003.165 | 0.46%
> GaussMix | 1157.491 | 1149.969 | 0.65%
> LogRegression | 717.772 | 733.576 | -2.15%
> MovieLens | 7916.181 | 8002.226 | -1.08%
> NaiveBayes | 395.296 | 386.611 | 2.25%
> PageRank | 4294.939 | 4346.333 | -1.18%
> FjKmeans | 496.076 | 493.873 | 0.45%
> FutureGenetic | 2578.504 | 2589.255 | -0.42%
> Mnemonics | 4898.886 | 4903.689 | -0.10%
> ParMnemonics | 4260.507 | 4210.121 | 1.20%
> Scrabble | 139.37 | 138.312 | 0.76%
> RxScrabble | 320.114 | 322.651 | -0.79%
> Dotty | 1056.543 | 1068.492 | -1.12%
> ScalaDoku | 3443.117 | 3449.477 | -0.18%
> ScalaKmeans | 259.384 | 258.648 | 0.28%
> Philosophers | 24333.311 | 23438.22 | 3.82%
> ScalaStmBench7 | 1102.43 | 1115.142 | -1.14%
> FinagleChirper | 6814.192 | 6853.38 | -0.57%
> FinagleHttp | 4762.902 | 4807.564 | -0.93%
> 
> #### Renaissance/x86_64
> 
> benchmark | baseline | fast-locking | %
> -- | -- | -- | --
> AkkaUct | 1117.185 | 1116.425 | 0.07%
> Reactors | 11561.354 | 11812.499 | -2.13%
> Als | 1580.838 | 1575.318 | 0.35%
> ChiSquare | 459.601 | 467.109 | -1.61%
> GaussMix | 705.944 | 685.595 | 2.97%
> LogRegression | 659.944 | 656.428 | 0.54%
> MovieLens | 7434.303 | 7592.271 | -2.08%
> NaiveBayes | 413.482 | 417.369 | -0.93%
> PageRank | 3259.233 | 3276.589 | -0.53%
> FjKmeans | 946.429 | 938.991 | 0.79%
> FutureGenetic | 1760.672 | 1815.272 | -3.01%
> ParMnemonics | 2016.917 | 2033.101 | -0.80%
> Scrabble | 147.996 | 150.084 | -1.39%
> RxScrabble | 177.755 | 177.956 | -0.11%
> Dotty | 673.754 | 683.919 | -1.49%
> ScalaDoku | 2193.562 | 1958.419 | 12.01%
> ScalaKmeans | 165.376 | 168.925 | -2.10%
> ScalaStmBench7 | 1080.187 | 1049.184 | 2.95%
> Philosophers | 14268.449 | 13308.87 | 7.21%
> FinagleChirper | 4722.13 | 4688.3 | 0.72%
> FinagleHttp | 3497.241 | 3605.118 | -2.99%
> 
> Some renaissance benchmarks are missing: DecTree, DbShootout and Neo4jAnalytics are not compatible with JDK20. The remaining benchmarks show very high run-to-run variance, which I am investigating (and probably addressing with running them much more often.
> 
> I have also run another benchmark, which is a popular Java JVM benchmark, with workloads wrapped in JMH and very slightly modified to run with newer JDKs, but I won't publish the results because I am not sure about the licensing terms. They look similar to the measurements above (i.e. +/- 2%, nothing very suspicious).
> 
> Please let me know if you want me to run any other workloads, or, even better, run them yourself and report here.
> 
> ### Testing
>  - [x] tier1 (x86_64, aarch64, x86_32)
>  - [x] tier2 (x86_64, aarch64)
>  - [x] tier3 (x86_64, aarch64)
>  - [x] tier4 (x86_64, aarch64)
>  - [x] jcstress 3-days -t sync -af GLOBAL (x86_64, aarch64)

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/10590

From jwilhelm at openjdk.org  Wed Dec 14 17:11:21 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Wed, 14 Dec 2022 17:11:21 GMT
Subject: RFR: Merge jdk20
Message-ID: <MfIrkifsuA1GWjwbhgOaCGmwBUSkPIy0QZnt_yUJoj0=.e5687e4f-5661-4593-8e8d-f061b3bf705f@github.com>

Forwardport JDK 20 -> JDK 21

-------------

Commit messages:
 - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20
 - 8297235: ZGC: assert(regs[i] != regs[j]) failed: Multiple uses of register: rax
 - 8298649: JFR: RemoteRecordingStream support for checkpoint event sizes beyond u4
 - 8298296: gc/TestFullGCCount.java fails with "System.gc collections miscounted."
 - 8294902: Undefined Behavior in C2 regalloc with null references
 - 8298425: System.console().readLine() hangs in jshell
 - 8298520: C2: assert(found_opaque == res) failed: wrong pattern
 - 8298527: Cygwin's uname -m returns different string than before
 - 8298700: Typo in DocTree comment
 - 8297305: Clarify that javax.lang.model.util.Elements.overrides is irreflexive
 - ... and 1 more: https://git.openjdk.org/jdk/compare/c05dbac3...873a7e3a

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=11678&range=00.0
 - jdk20: https://webrevs.openjdk.org/?repo=jdk&pr=11678&range=00.1

Changes: https://git.openjdk.org/jdk/pull/11678/files
  Stats: 216 lines in 17 files changed: 132 ins; 41 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/11678.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11678/head:pull/11678

PR: https://git.openjdk.org/jdk/pull/11678

From coleenp at openjdk.org  Wed Dec 14 19:01:08 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 14 Dec 2022 19:01:08 GMT
Subject: RFR: 8298794: Remove JVM_ACC_PROMOTED_FLAGS breaks minimal build
Message-ID: <55pS7LWvDHhUMf9H0Fuw9VM1KuksSOnLkTWffbIkmvE=.70e97b70-286f-4ebc-91ad-0d9d8f0dfc18@github.com>

Please review this trivial fix to fix the minimal build.  Testing is in progress.

-------------

Commit messages:
 - 8298794: Remove JVM_ACC_PROMOTED_FLAGS breaks minimal build

Changes: https://git.openjdk.org/jdk/pull/11680/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11680&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298794
  Stats: 3 lines in 1 file changed: 1 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11680.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11680/head:pull/11680

PR: https://git.openjdk.org/jdk/pull/11680

From ayang at openjdk.org  Wed Dec 14 19:05:06 2022
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 14 Dec 2022 19:05:06 GMT
Subject: RFR: 8298794: Remove JVM_ACC_PROMOTED_FLAGS breaks minimal build
In-Reply-To: <55pS7LWvDHhUMf9H0Fuw9VM1KuksSOnLkTWffbIkmvE=.70e97b70-286f-4ebc-91ad-0d9d8f0dfc18@github.com>
References: <55pS7LWvDHhUMf9H0Fuw9VM1KuksSOnLkTWffbIkmvE=.70e97b70-286f-4ebc-91ad-0d9d8f0dfc18@github.com>
Message-ID: <NbC9oa3SVsYtRElzVWi6Ly9W6M6Unub8Q-_galowTMw=.49787374-0bca-4767-adfc-2fd6c36d7756@github.com>

On Wed, 14 Dec 2022 18:38:38 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this trivial fix to fix the minimal build.  Testing is in progress.

Marked as reviewed by ayang (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11680

From coleenp at openjdk.org  Wed Dec 14 19:44:05 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 14 Dec 2022 19:44:05 GMT
Subject: RFR: 8298794: Remove JVM_ACC_PROMOTED_FLAGS breaks minimal build
In-Reply-To: <55pS7LWvDHhUMf9H0Fuw9VM1KuksSOnLkTWffbIkmvE=.70e97b70-286f-4ebc-91ad-0d9d8f0dfc18@github.com>
References: <55pS7LWvDHhUMf9H0Fuw9VM1KuksSOnLkTWffbIkmvE=.70e97b70-286f-4ebc-91ad-0d9d8f0dfc18@github.com>
Message-ID: <MTVl5IbIzm87GFBIxU_HvVaQNs4YhDcDjkFRwiqBpz8=.01083173-4427-435c-8d21-218a2a14c5b5@github.com>

On Wed, 14 Dec 2022 18:38:38 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this trivial fix to fix the minimal build.  Testing is in progress.

Thanks Albert and letting me know about the minimal failure.

-------------

PR: https://git.openjdk.org/jdk/pull/11680

From dcubed at openjdk.org  Wed Dec 14 19:56:05 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 14 Dec 2022 19:56:05 GMT
Subject: RFR: 8298794: Remove JVM_ACC_PROMOTED_FLAGS breaks minimal build
In-Reply-To: <55pS7LWvDHhUMf9H0Fuw9VM1KuksSOnLkTWffbIkmvE=.70e97b70-286f-4ebc-91ad-0d9d8f0dfc18@github.com>
References: <55pS7LWvDHhUMf9H0Fuw9VM1KuksSOnLkTWffbIkmvE=.70e97b70-286f-4ebc-91ad-0d9d8f0dfc18@github.com>
Message-ID: <hCa4PjUWXfZ81ePrTkI9c15MFMzN8-aigdk8L5f6IsY=.cef2afab-3694-4d10-aaa1-a8b3ca60b324@github.com>

On Wed, 14 Dec 2022 18:38:38 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this trivial fix to fix the minimal build.  Testing is in progress.

Thumbs up.

Yup. The single use in IK_FLAGS_SET macro in share/oops/instanceKlassMiscStatus.hpp
is not protected by an INCLUDE_CDS. Sorry for missing that.

-------------

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11680

From jwilhelm at openjdk.org  Wed Dec 14 21:51:13 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Wed, 14 Dec 2022 21:51:13 GMT
Subject: Integrated: Merge jdk20
In-Reply-To: <MfIrkifsuA1GWjwbhgOaCGmwBUSkPIy0QZnt_yUJoj0=.e5687e4f-5661-4593-8e8d-f061b3bf705f@github.com>
References: <MfIrkifsuA1GWjwbhgOaCGmwBUSkPIy0QZnt_yUJoj0=.e5687e4f-5661-4593-8e8d-f061b3bf705f@github.com>
Message-ID: <I5vQumlhaL6cXwuMXUTwTNcFmgSqghC2VhvOpXP-fDk=.a1608d39-d043-4bdd-9711-ff01a50a67fa@github.com>

On Wed, 14 Dec 2022 16:59:54 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 20 -> JDK 21

This pull request has now been integrated.

Changeset: a130c8a6
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a130c8a6688fcdda92e0f6295ec06f1591382328
Stats:     216 lines in 17 files changed: 132 ins; 41 del; 43 mod

Merge

-------------

PR: https://git.openjdk.org/jdk/pull/11678

From dholmes at openjdk.org  Wed Dec 14 22:31:55 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 14 Dec 2022 22:31:55 GMT
Subject: RFR: 8298241: Replace C-style casts with JavaThread::cast
Message-ID: <6NksENBkkBRd2KR0c5kYlmruycaqoGx-Z_-h6lkb9ms=.a133b578-12a3-4ca6-9636-0159e305c5a5@github.com>

This is a simple cleanup RFE to get rid of old-style C casts in relation to JavaThread.

In many cases involving NULL/nullptr the cast could just be dropped. Sometimes a static cast is needed to disambiguate overloads.

A couple of reinterpret_cast are needed when doing int/ptr conversion.

static_cast is used for void* conversion.

The other changes should be self explanatory.

The changes in

src/hotspot/os_cpu/bsd_aarch64/javaThread_bsd_aarch64.cpp
src/hotspot/os_cpu/windows_aarch64/javaThread_windows_aarch64.cpp

are a bit more extensive. That code was using an alias for `this` which is completely unnecessary (and the alias creation was using the cast). This could be factored out if thought necessary.

I grep'd as best I could for the old C-style casts but can't be certain I got them all.

Testing: 
 - all builds in our tiers1-5
 - local linux x64 product, slowdebug and fastdebug
 - GHA (TBD)
 - Sanity testing tiers 1-3
Thanks.

-------------

Commit messages:
 - 8298241: Replace C-style casts with JavaThread::cast

Changes: https://git.openjdk.org/jdk/pull/11682/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11682&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298241
  Stats: 44 lines in 19 files changed: 0 ins; 11 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/11682.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11682/head:pull/11682

PR: https://git.openjdk.org/jdk/pull/11682

From coleenp at openjdk.org  Wed Dec 14 23:09:20 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 14 Dec 2022 23:09:20 GMT
Subject: RFR: 8298794: Remove JVM_ACC_PROMOTED_FLAGS breaks minimal build
In-Reply-To: <55pS7LWvDHhUMf9H0Fuw9VM1KuksSOnLkTWffbIkmvE=.70e97b70-286f-4ebc-91ad-0d9d8f0dfc18@github.com>
References: <55pS7LWvDHhUMf9H0Fuw9VM1KuksSOnLkTWffbIkmvE=.70e97b70-286f-4ebc-91ad-0d9d8f0dfc18@github.com>
Message-ID: <AyMyazm1YTbcTw23M9oGjmgINL8fE7561E9qNUpjGOY=.e5b213e9-c368-44b0-a434-55bd2b128b43@github.com>

On Wed, 14 Dec 2022 18:38:38 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this trivial fix to fix the minimal build.  Testing is in progress.

Thanks Dan.  The IK_FLAGS_SET macro shouldn't be protected but neither should the assert_is_safe.

-------------

PR: https://git.openjdk.org/jdk/pull/11680

From coleenp at openjdk.org  Wed Dec 14 23:12:08 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 14 Dec 2022 23:12:08 GMT
Subject: Integrated: 8298794: Remove JVM_ACC_PROMOTED_FLAGS breaks minimal
 build
In-Reply-To: <55pS7LWvDHhUMf9H0Fuw9VM1KuksSOnLkTWffbIkmvE=.70e97b70-286f-4ebc-91ad-0d9d8f0dfc18@github.com>
References: <55pS7LWvDHhUMf9H0Fuw9VM1KuksSOnLkTWffbIkmvE=.70e97b70-286f-4ebc-91ad-0d9d8f0dfc18@github.com>
Message-ID: <Ka1nGPTIMNa5o-Tbh-eqKYQYGCf6Pbuu_UHdbX-OJ1Q=.e5248ff9-0698-4d4b-afc4-f30c6e22e498@github.com>

On Wed, 14 Dec 2022 18:38:38 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this trivial fix to fix the minimal build.  Testing is in progress.

This pull request has now been integrated.

Changeset: 3ef38241
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3ef382416f5ff38cd44fa8d4e552f1935156e765
Stats:     3 lines in 1 file changed: 1 ins; 2 del; 0 mod

8298794: Remove JVM_ACC_PROMOTED_FLAGS breaks minimal build

Reviewed-by: ayang, dcubed

-------------

PR: https://git.openjdk.org/jdk/pull/11680

From coleenp at openjdk.org  Wed Dec 14 23:16:04 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 14 Dec 2022 23:16:04 GMT
Subject: RFR: 8298241: Replace C-style casts with JavaThread::cast
In-Reply-To: <6NksENBkkBRd2KR0c5kYlmruycaqoGx-Z_-h6lkb9ms=.a133b578-12a3-4ca6-9636-0159e305c5a5@github.com>
References: <6NksENBkkBRd2KR0c5kYlmruycaqoGx-Z_-h6lkb9ms=.a133b578-12a3-4ca6-9636-0159e305c5a5@github.com>
Message-ID: <VDvRcKx4eq82WkTk09zViPS6TWYLN520AS_MAVfn04w=.270f4ea0-9d02-4d10-b3f1-c40b582b3db1@github.com>

On Wed, 14 Dec 2022 22:22:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This is a simple cleanup RFE to get rid of old-style C casts in relation to JavaThread.
> 
> In many cases involving NULL/nullptr the cast could just be dropped. Sometimes a static cast is needed to disambiguate overloads.
> 
> A couple of reinterpret_cast are needed when doing int/ptr conversion.
> 
> static_cast is used for void* conversion.
> 
> The other changes should be self explanatory.
> 
> The changes in
> 
> src/hotspot/os_cpu/bsd_aarch64/javaThread_bsd_aarch64.cpp
> src/hotspot/os_cpu/windows_aarch64/javaThread_windows_aarch64.cpp
> 
> are a bit more extensive. That code was using an alias for `this` which is completely unnecessary (and the alias creation was using the cast). This could be factored out if thought necessary.
> 
> I grep'd as best I could for the old C-style casts but can't be certain I got them all.
> 
> Testing: 
>  - all builds in our tiers1-5
>  - local linux x64 product, slowdebug and fastdebug
>  - GHA (TBD)
>  - Sanity testing tiers 1-3
> Thanks.

Looks good!

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11682

From dholmes at openjdk.org  Thu Dec 15 01:41:04 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 15 Dec 2022 01:41:04 GMT
Subject: RFR: 8298241: Replace C-style casts with JavaThread::cast
In-Reply-To: <VDvRcKx4eq82WkTk09zViPS6TWYLN520AS_MAVfn04w=.270f4ea0-9d02-4d10-b3f1-c40b582b3db1@github.com>
References: <6NksENBkkBRd2KR0c5kYlmruycaqoGx-Z_-h6lkb9ms=.a133b578-12a3-4ca6-9636-0159e305c5a5@github.com>
 <VDvRcKx4eq82WkTk09zViPS6TWYLN520AS_MAVfn04w=.270f4ea0-9d02-4d10-b3f1-c40b582b3db1@github.com>
Message-ID: <Xowyy7U9c1M61D2qQWdWV50ye--bQ8TAff0VC6DY3oc=.9b416256-fed8-48bb-94a3-36ff4e480b23@github.com>

On Wed, 14 Dec 2022 23:13:30 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This is a simple cleanup RFE to get rid of old-style C casts in relation to JavaThread.
>> 
>> In many cases involving NULL/nullptr the cast could just be dropped. Sometimes a static cast is needed to disambiguate overloads.
>> 
>> A couple of reinterpret_cast are needed when doing int/ptr conversion.
>> 
>> static_cast is used for void* conversion.
>> 
>> The other changes should be self explanatory.
>> 
>> The changes in
>> 
>> src/hotspot/os_cpu/bsd_aarch64/javaThread_bsd_aarch64.cpp
>> src/hotspot/os_cpu/windows_aarch64/javaThread_windows_aarch64.cpp
>> 
>> are a bit more extensive. That code was using an alias for `this` which is completely unnecessary (and the alias creation was using the cast). This could be factored out if thought necessary.
>> 
>> I grep'd as best I could for the old C-style casts but can't be certain I got them all.
>> 
>> Testing: 
>>  - all builds in our tiers1-5
>>  - local linux x64 product, slowdebug and fastdebug
>>  - GHA
>>  - Sanity testing tiers 1-3
>> Thanks.
>
> Looks good!

Thanks @coleenp !

-------------

PR: https://git.openjdk.org/jdk/pull/11682

From dholmes at openjdk.org  Thu Dec 15 01:56:09 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 15 Dec 2022 01:56:09 GMT
Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v7]
In-Reply-To: <HRWkSOl_pNUKuNpFlYFO_2i38XzEVvpQZysch4DFGXE=.574941d1-6991-445e-882a-796b467a8a6b@github.com>
References: <Dj9YfY10SLn8dR1Ez3kEQe4tXm1q5W1TS8_4r3gBUsY=.6c38825a-86e5-4575-a509-683786d242a6@github.com>
 <pRcbuNmrpRkRA8lOJfYlEVWo3W766EMs6Gw5raXbZPs=.66222c03-5a36-43be-a9c9-080d046d73d7@github.com>
 <AYhCxPKMsfdFV8iiAy9oHn4vtW8qd5zJPEbJQb6qZBk=.70e1d24b-fdbd-4d62-8319-073247eae8b6@github.com>
 <HRWkSOl_pNUKuNpFlYFO_2i38XzEVvpQZysch4DFGXE=.574941d1-6991-445e-882a-796b467a8a6b@github.com>
Message-ID: <31ZthS6SqGpb-qVWc9EOZFk0x2KYf16KDL5hecw8HmY=.b1ee5b8e-1be0-4c20-bb33-c68d7202d0b2@github.com>

On Wed, 14 Dec 2022 13:28:02 GMT, Afshin Zafari <duke at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiTagMap.cpp line 1262:
>> 
>>> 1260:   // and record the reference and tag value.
>>> 1261:   //
>>> 1262:   bool do_entry(JvmtiTagMapKey& key, jlong& value) {
>> 
>> I still see no point in this method returning a bool when it only ever returns true.
>
> In the `iterate` method of ResourceHashTable, in respurceHash.hpp lines 227-240 copied here, requires a function that returns boolean. If returned false the iterate will break.
> 
>  template<typename Function>
>   void iterate(Function function) const { // lambda enabled API
>     Node* const* bucket = table();
>     const unsigned sz = table_size();
>     while (bucket < bucket_at(sz)) {
>       Node* node = *bucket;
>       while (node != NULL) {
>         bool cont = function(node->_key, node->_value);    // <--------------******
>         if (!cont) { return; }
>         node = node->_next;
>       }
>       ++bucket;
>     }
>   }
> 
> The other `iterate` methods are wrappers around this one.
> Always returning true means to continue iterating over all the existing items. 
> The former base table for jvmtiTagMapTable needs the `do_entry` be `void`.

Okay in that case please add to the comment preceding this method:

// Always return true so the iteration continues.

-------------

PR: https://git.openjdk.org/jdk/pull/11288

From dholmes at openjdk.org  Thu Dec 15 02:00:13 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 15 Dec 2022 02:00:13 GMT
Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v7]
In-Reply-To: <b9toj2PH0oXmGw518_K63jBcebPBdenErs2T7i0suYg=.f118313b-ea1e-4b7d-befa-8253f2250a33@github.com>
References: <Dj9YfY10SLn8dR1Ez3kEQe4tXm1q5W1TS8_4r3gBUsY=.6c38825a-86e5-4575-a509-683786d242a6@github.com>
 <pRcbuNmrpRkRA8lOJfYlEVWo3W766EMs6Gw5raXbZPs=.66222c03-5a36-43be-a9c9-080d046d73d7@github.com>
 <AYhCxPKMsfdFV8iiAy9oHn4vtW8qd5zJPEbJQb6qZBk=.70e1d24b-fdbd-4d62-8319-073247eae8b6@github.com>
 <b9toj2PH0oXmGw518_K63jBcebPBdenErs2T7i0suYg=.f118313b-ea1e-4b7d-befa-8253f2250a33@github.com>
Message-ID: <aHvI4KPu-GzjL8cZRvgosPRa7_6RHYGNB5hkwWjf4Ps=.909d90c0-e550-4409-8d0a-e25aee2895b9@github.com>

On Wed, 14 Dec 2022 15:11:55 GMT, Afshin Zafari <duke at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiTagMapTable.cpp line 114:
>> 
>>> 112:   JvmtiTagMapKey new_entry(obj);
>>> 113:   bool is_updated = _table.put(new_entry, tag) == false;
>>> 114:   assert(is_updated, "should be updated and not added");
>> 
>> This API is confusing. You have `add` and `replace` but in product mode an `add` can `replace` and a `replace` can `add`. It isn't clear if these should be allowed rare conditions or fatal errors.
>
> I agree that this is ambigious. The `jvmtiTagMap` calls `add/update` methods of `jvmtiTagMapTable` which in turn calls `resourceHashTable` methods `put` and `put_if_absent`.
> `put` and `put_if_absent` can be used for both adding and updating and reporting it in returned values.
> `jvmtiTagMap` calls to `jvmtiTagMapTable` add/update  DO NOT CARE about the returned values. For these calls, it doesn't mater if an add (update) method resulted in an update (add). 
> So which one of the following cases would be correct?
>  - Based on the `jvmtiTagMap` calls, let the add/update be void and ignore the differences of what really happens in the table. Or
>  - Based on the `resourceHashTable` bool-valued `put` and `put_if_absent` methods, let the add/update be bool-values and leave the decision on "what really happened in the table" to the callers in `jvmtiTagMap`. (current implementation)

The issue is not the underlying RHT methods but the semantics of the `jvmtiTagMap` methods. If a call to add always expects to add then it should be a fatal error if it actually did an update as that indicates something is broken. Similarly if an update actually does an add.

-------------

PR: https://git.openjdk.org/jdk/pull/11288

From stefank at openjdk.org  Thu Dec 15 07:11:06 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 15 Dec 2022 07:11:06 GMT
Subject: RFR: 8298241: Replace C-style casts with JavaThread::cast
In-Reply-To: <6NksENBkkBRd2KR0c5kYlmruycaqoGx-Z_-h6lkb9ms=.a133b578-12a3-4ca6-9636-0159e305c5a5@github.com>
References: <6NksENBkkBRd2KR0c5kYlmruycaqoGx-Z_-h6lkb9ms=.a133b578-12a3-4ca6-9636-0159e305c5a5@github.com>
Message-ID: <JsFAinF_LqKouAWpOBNbllBFpvgnTrFQblRbJnufwDY=.b149b9f0-6faa-4c5f-a1b9-a2dc59602a81@github.com>

On Wed, 14 Dec 2022 22:22:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This is a simple cleanup RFE to get rid of old-style C casts in relation to JavaThread.
> 
> In many cases involving NULL/nullptr the cast could just be dropped. Sometimes a static cast is needed to disambiguate overloads.
> 
> A couple of reinterpret_cast are needed when doing int/ptr conversion.
> 
> static_cast is used for void* conversion.
> 
> The other changes should be self explanatory.
> 
> The changes in
> 
> src/hotspot/os_cpu/bsd_aarch64/javaThread_bsd_aarch64.cpp
> src/hotspot/os_cpu/windows_aarch64/javaThread_windows_aarch64.cpp
> 
> are a bit more extensive. That code was using an alias for `this` which is completely unnecessary (and the alias creation was using the cast). This could be factored out if thought necessary.
> 
> I grep'd as best I could for the old C-style casts but can't be certain I got them all.
> 
> Testing: 
>  - all builds in our tiers1-5
>  - local linux x64 product, slowdebug and fastdebug
>  - GHA
>  - Sanity testing tiers 1-3
> Thanks.

Marked as reviewed by stefank (Reviewer).

src/hotspot/share/runtime/frame.cpp line 1568:

> 1566:     }
> 1567:   }
> 1568:   // if (error) { tty->cr(); print_on(nullptr, tty); }

This probably need the same cast as in print_frame_layout, to disambiguate the call.

-------------

PR: https://git.openjdk.org/jdk/pull/11682

From kbarrett at openjdk.org  Thu Dec 15 08:15:14 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 15 Dec 2022 08:15:14 GMT
Subject: RFR: 8293824: gc/whitebox/TestConcMarkCycleWB.java failed
 "RuntimeException: assertTrue: expected true, was false" [v2]
In-Reply-To: <dM4t6tEt_ECKHylcGy7v2lL8FOXa1j336ycPFt07Jnc=.1b984fe9-d268-4384-85d9-0984fff815a6@github.com>
References: <74AnEqLugaEU80XMNm8edtWBmK8gOFMirnZT1rdj1jI=.6ab039c0-3db5-4336-9aa7-867166b79cda@github.com>
 <dM4t6tEt_ECKHylcGy7v2lL8FOXa1j336ycPFt07Jnc=.1b984fe9-d268-4384-85d9-0984fff815a6@github.com>
Message-ID: <4Z_Y2cfiY1eBi9XdRD4nt1C5OdM6tfmCsZ91ZPh3g-Y=.c741757b-9c61-429e-a5ba-6608663c9618@github.com>

On Tue, 6 Dec 2022 12:34:47 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to WhiteBox and some tests involving G1 concurrent GCs.
>> 
>> Some tests currently use WhiteBox.g1StartConcMarkCycle() to trigger a
>> concurrent GC.  Many of them follow it with a loop waiting for a concurrent
>> cycle to not be in progress.  A few also preceed that call with a similar
>> loop, since that call does nothing and returns false if a concurrent cycle is
>> already in progress.  Those tests typically want to ensure there was a
>> concurrent cycle that was started after some setup.
>> 
>> The failing test calls that function, asserting that it returned true, e.g. a
>> new concurrent cycle was started.
>> 
>> There are various problems with this, due to races with concurrent cycles
>> started automatically and possibly aborted (by full GCs) concurrent cycles,
>> making some of these tests unreliable in some configurations.
>> 
>> For example, the test failure associated with this bug intermittently arises
>> when running with `-Xcomp`, triggering a concurrent cycle before the explicit
>> requests by the test, causing the explicit request to fail (because there is
>> already one in progress), failing the assert.  Waiting for there not to be an
>> in-progress cycle before the explicit request just narrows the race window.
>> 
>> We have a different mechanism for controlling concurrent cycles, the
>> concurrent GC breakpoint mechanism.  By adding a counter specifically for such
>> cycles, we can use GC breakpoints to ensure only the concurrent cycles the
>> test wants are occurring, and can verify they completed successfully.
>> 
>> So we change tests using WhiteBox.g1StartConcMarkCycle() to instead use GC
>> breakpoints, along with the new WhiteBox.g1CompletedConcurrentMarkCycles() to
>> avoid racing request problems and to detect aborted cycles.  Since it is no
>> longer used, WhiteBox.g1StartConcMarkCycle() is removed.
>> 
>> Testing:
>> mach5 tier1-6
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - use new whitebox api for running conc gc
>  - Merge branch 'master' into test-concmark
>  - copyrights
>  - remove WB.g1StartConcMarkCyle
>  - update tests
>  - add utility GC breakpoint functions
>  - add G1ConcurrentMark::completed_mark_cycles() and whitebox access

I'm going to need to retarget this to jdk20.  Also, this change makes JDK-8298215 a reliable failure instead of very intermittent.  So closing this PR and I'll create a new one later, after doing something about JDK-8298215.

-------------

PR: https://git.openjdk.org/jdk/pull/11435

From kbarrett at openjdk.org  Thu Dec 15 08:15:15 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 15 Dec 2022 08:15:15 GMT
Subject: Withdrawn: 8293824: gc/whitebox/TestConcMarkCycleWB.java failed
 "RuntimeException: assertTrue: expected true, was false"
In-Reply-To: <74AnEqLugaEU80XMNm8edtWBmK8gOFMirnZT1rdj1jI=.6ab039c0-3db5-4336-9aa7-867166b79cda@github.com>
References: <74AnEqLugaEU80XMNm8edtWBmK8gOFMirnZT1rdj1jI=.6ab039c0-3db5-4336-9aa7-867166b79cda@github.com>
Message-ID: <2OxnEPlAFI1UT4CkIwTvVvQNkB380OF61ePr68osA6Y=.e4af7fcd-7828-4451-98e7-b5340d7e0499@github.com>

On Wed, 30 Nov 2022 16:40:19 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to WhiteBox and some tests involving G1 concurrent GCs.
> 
> Some tests currently use WhiteBox.g1StartConcMarkCycle() to trigger a
> concurrent GC.  Many of them follow it with a loop waiting for a concurrent
> cycle to not be in progress.  A few also preceed that call with a similar
> loop, since that call does nothing and returns false if a concurrent cycle is
> already in progress.  Those tests typically want to ensure there was a
> concurrent cycle that was started after some setup.
> 
> The failing test calls that function, asserting that it returned true, e.g. a
> new concurrent cycle was started.
> 
> There are various problems with this, due to races with concurrent cycles
> started automatically and possibly aborted (by full GCs) concurrent cycles,
> making some of these tests unreliable in some configurations.
> 
> For example, the test failure associated with this bug intermittently arises
> when running with `-Xcomp`, triggering a concurrent cycle before the explicit
> requests by the test, causing the explicit request to fail (because there is
> already one in progress), failing the assert.  Waiting for there not to be an
> in-progress cycle before the explicit request just narrows the race window.
> 
> We have a different mechanism for controlling concurrent cycles, the
> concurrent GC breakpoint mechanism.  By adding a counter specifically for such
> cycles, we can use GC breakpoints to ensure only the concurrent cycles the
> test wants are occurring, and can verify they completed successfully.
> 
> So we change tests using WhiteBox.g1StartConcMarkCycle() to instead use GC
> breakpoints, along with the new WhiteBox.g1CompletedConcurrentMarkCycles() to
> avoid racing request problems and to detect aborted cycles.  Since it is no
> longer used, WhiteBox.g1StartConcMarkCycle() is removed.
> 
> Testing:
> mach5 tier1-6

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/11435

From sspitsyn at openjdk.org  Thu Dec 15 08:51:05 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 15 Dec 2022 08:51:05 GMT
Subject: RFR: 8298241: Replace C-style casts with JavaThread::cast
In-Reply-To: <6NksENBkkBRd2KR0c5kYlmruycaqoGx-Z_-h6lkb9ms=.a133b578-12a3-4ca6-9636-0159e305c5a5@github.com>
References: <6NksENBkkBRd2KR0c5kYlmruycaqoGx-Z_-h6lkb9ms=.a133b578-12a3-4ca6-9636-0159e305c5a5@github.com>
Message-ID: <4SiC0hWeVuGEwNx0no014TsccBFSzbaX9KHmCCXyEb8=.00a0e52d-f928-4c78-a4d6-dab85428ea2f@github.com>

On Wed, 14 Dec 2022 22:22:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This is a simple cleanup RFE to get rid of old-style C casts in relation to JavaThread.
> 
> In many cases involving NULL/nullptr the cast could just be dropped. Sometimes a static cast is needed to disambiguate overloads.
> 
> A couple of reinterpret_cast are needed when doing int/ptr conversion.
> 
> static_cast is used for void* conversion.
> 
> The other changes should be self explanatory.
> 
> The changes in
> 
> src/hotspot/os_cpu/bsd_aarch64/javaThread_bsd_aarch64.cpp
> src/hotspot/os_cpu/windows_aarch64/javaThread_windows_aarch64.cpp
> 
> are a bit more extensive. That code was using an alias for `this` which is completely unnecessary (and the alias creation was using the cast). This could be factored out if thought necessary.
> 
> I grep'd as best I could for the old C-style casts but can't be certain I got them all.
> 
> Testing: 
>  - all builds in our tiers1-5
>  - local linux x64 product, slowdebug and fastdebug
>  - GHA
>  - Sanity testing tiers 1-3
> Thanks.

Looks good.
Thanks,
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11682

From stefank at openjdk.org  Thu Dec 15 09:44:03 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 15 Dec 2022 09:44:03 GMT
Subject: [jdk20] RFR: 8298376: ZGC: thaws stackChunk with stale oops
Message-ID: <_EYoFjHxBJ79MU9TCIfRi0mprN83buCHvehnBxsaOl4=.f4c9cace-8908-4ec8-b04d-4e35acece590@github.com>

8298376: ZGC: thaws stackChunk with stale oops

-------------

Commit messages:
 - Backport ed8a2120ca1e9756c6ab5eeebfe24c15d549f04e

Changes: https://git.openjdk.org/jdk20/pull/37/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=37&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298376
  Stats: 19 lines in 4 files changed: 15 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk20/pull/37.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/37/head:pull/37

PR: https://git.openjdk.org/jdk20/pull/37

From rkennke at openjdk.org  Thu Dec 15 10:55:57 2022
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 15 Dec 2022 10:55:57 GMT
Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v2]
In-Reply-To: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
References: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
Message-ID: <pu6xatwRtKjKwuvD8jENLgeD8CKfG7LqXvw-pnLDJN0=.63700531-7e36-4df6-a95b-4ee0fbada0d4@github.com>

> See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details.
> 
> Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements.
> 
> Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16.
> 
> Testing:
>  - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390)
>  - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390)
>  - [x] tier1 (x86_64, x86_32, aarch64, riscv)
>  - [x] tier2 (x86_64, aarch64, riscv)
>  - [x] tier3 (x86_64, riscv)

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Various fixes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11044/files
  - new: https://git.openjdk.org/jdk/pull/11044/files/42caf4bd..72b3ce26

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=00-01

  Stats: 71 lines in 12 files changed: 34 ins; 10 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/11044.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11044/head:pull/11044

PR: https://git.openjdk.org/jdk/pull/11044

From aph at openjdk.org  Thu Dec 15 11:09:11 2022
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 15 Dec 2022 11:09:11 GMT
Subject: RFR: JDK-8294902: Undefined Behavior in C2 regalloc with null
 references [v16]
In-Reply-To: <42H7oL49YA3VoxBr4RPfZT5f3v6AeEgV0iGmXx63UnQ=.eb518482-1142-4db5-b560-6ebeab613d9c@github.com>
References: <mF8Lu-7gPvjgcY-Oy30aoKaJgBQwohBSMbs6BQovz24=.4b995332-90a9-440f-899b-07f7cbb3054c@github.com>
 <42H7oL49YA3VoxBr4RPfZT5f3v6AeEgV0iGmXx63UnQ=.eb518482-1142-4db5-b560-6ebeab613d9c@github.com>
Message-ID: <0U5hPR3wQy0otwh9Z1KopAa6f0brX_jxaz6fOgyte8o=.4325c37b-7716-4fc3-b65a-9e4f4fc50cf6@github.com>

On Mon, 12 Dec 2022 18:44:22 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This patch fixes the remaining null pointer dereference bugs that I know of.
>> 
>> For the main bug, C2 was using a null reference to indicate an uninitialized `Node_List`. I replaced the null reference with a static sentinel.
>> 
>> I also turned on `-fsanitize=null` and found and fixed a bunch of other null pointer dereferences. With this,I have run a full bootstrap and tier1 tests with `-fsanitize=null` enabled.
>> 
>> I have checked that the code generated by GCC is not worse in any significant way, so I don't expect to see any performance regressions.
>> 
>> I'd like to enable `-fsanitize=null` in debug builds to prevent regressions in this area. What do you think?
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Typo

I pushed this to JDK 20, but in the process I forgot to include my co-authors in the commit.

My apologies to everyone, especially Vladimir Ivanov. You know who you are.

-------------

PR: https://git.openjdk.org/jdk/pull/10920

From stefank at openjdk.org  Thu Dec 15 11:47:07 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 15 Dec 2022 11:47:07 GMT
Subject: [jdk20] Integrated: 8298376: ZGC: thaws stackChunk with stale oops
In-Reply-To: <_EYoFjHxBJ79MU9TCIfRi0mprN83buCHvehnBxsaOl4=.f4c9cace-8908-4ec8-b04d-4e35acece590@github.com>
References: <_EYoFjHxBJ79MU9TCIfRi0mprN83buCHvehnBxsaOl4=.f4c9cace-8908-4ec8-b04d-4e35acece590@github.com>
Message-ID: <BXHX90QT_lokieUIlx2zfUSsBqdJ-ID99kst1smGIu0=.8329d074-c174-4b24-b8c4-5f4000b76b83@github.com>

On Thu, 15 Dec 2022 09:34:17 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> 8298376: ZGC: thaws stackChunk with stale oops

This pull request has now been integrated.

Changeset: 48f61273
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/48f6127325108e573b41d19213e65af99956a31f
Stats:     19 lines in 4 files changed: 15 ins; 0 del; 4 mod

8298376: ZGC: thaws stackChunk with stale oops

Backport-of: ed8a2120ca1e9756c6ab5eeebfe24c15d549f04e

-------------

PR: https://git.openjdk.org/jdk20/pull/37

From lkorinth at openjdk.org  Thu Dec 15 12:05:08 2022
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 15 Dec 2022 12:05:08 GMT
Subject: RFR: 8292170: Convert CodeRootSetTable to use ResourceHashtable
In-Reply-To: <WMe0NKYtTMct92Lr7n4l7-6w5xA-0AvLYjSoPXre-8k=.bdb90f9b-7d94-44c9-ba9b-dcfd6f12cef7@github.com>
References: <BdRsUwTHeM7gAUg1udRTeG-gv2S4slO0zYl5Ys21Pyw=.5701b960-0ecb-4c67-9d11-88d103b2bd0f@github.com>
 <WMe0NKYtTMct92Lr7n4l7-6w5xA-0AvLYjSoPXre-8k=.bdb90f9b-7d94-44c9-ba9b-dcfd6f12cef7@github.com>
Message-ID: <vRCpvcaw0fpIp3rhcxWL-3YmMPSTHFxyhlo9f5B-oGA=.0f0bddc6-10c5-4c09-b2cc-c16dee215f0c@github.com>

On Wed, 14 Dec 2022 14:48:42 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I am replacing the old hash table with ResourceHashtable. In the process I am also removing the redundant `_length` field. By removing the `_length` field, a lot of asserts can be removed as the length will trivially match the length of the underlying table.
>> 
>> I would like to have feedback on the addition of `unlink_destruct(Function&& should_remove)`. I added it because I prefer to use a functor object that can be used by lambdas instead of an iterator object. However, I did add code to "destruct" resource objects when they are removed instead of just letting them be to reflect that we use `delete` on c-heap objects. Maybe I should remove this "improvement" and then maybe implement the function by calling the existing unlink?
>
> src/hotspot/share/utilities/resourceHash.hpp line 277:
> 
>> 275:   }
>> 276: 
>> 277:   // The argument should_remove() have the signature: bool Function(K const&, V const&).
> 
> Can you make the unlink a separate change?  I think unlink with the Function argument should be an overload of unlink() and implemented like the iterate function. I don't immediately understand the additional &&s.
> If it's a separate change, we can fix the other callers to use lambdas, which would be nicer.
> Also, I think calling the ResourceObj destructor is another discussion - they are not typically used and I think the discussion should be somewhere else.

I will rework it.

-------------

PR: https://git.openjdk.org/jdk/pull/11675

From sspitsyn at openjdk.org  Thu Dec 15 12:09:09 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 15 Dec 2022 12:09:09 GMT
Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling one
 virtual thread transitions
Message-ID: <z8NCIbPeF0WzTEzXGyNxlnuOF_52vbV90p4B15xThFk=.b12cfe49-d27d-4e65-9027-796985005c14@github.com>

Now the `JvmtiVTMSTransitionDisabler` mechanism supports disabling VTMS transitions for all virtual threads only. It should also support disabling transitions for any specific virtual thread as well. This will improve scalability of the JVMTI functions operating on target virtual threads as the functions can be executed concurrently without blocking each other execution when target virtual threads are different.
New constructor `JvmtiVTMSTransitionDisabler(jthread vthread)` is added which has jthread parameter of the target virtual thread.

Testing:
  mach5 jobs are TBD:
   - all JVMTI, JDWP, JDI and JDB tests have to be run
   - Kitchensink
   - tier5

-------------

Commit messages:
 - fix trailing white spaces in javaClasses.cpp and jvmtiThreadState.cpp
 - 8298853: JvmtiVTMSTransitionDisabler should support disabling one virtual thread transitions

Changes: https://git.openjdk.org/jdk/pull/11690/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11690&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298853
  Stats: 161 lines in 7 files changed: 110 ins; 2 del; 49 mod
  Patch: https://git.openjdk.org/jdk/pull/11690.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11690/head:pull/11690

PR: https://git.openjdk.org/jdk/pull/11690

From rkennke at openjdk.org  Thu Dec 15 13:08:46 2022
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 15 Dec 2022 13:08:46 GMT
Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v3]
In-Reply-To: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
References: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
Message-ID: <Uh0GAgQFcTlyclNoAz69QeJuo3WJssT0sVs7Py0vx5M=.42ac1037-a94c-427a-88a6-1841e3ac1a04@github.com>

> See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details.
> 
> Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements.
> 
> Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16.
> 
> Testing:
>  - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390)
>  - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390)
>  - [x] tier1 (x86_64, x86_32, aarch64, riscv)
>  - [x] tier2 (x86_64, aarch64, riscv)
>  - [x] tier3 (x86_64, riscv)

Roman Kennke has updated the pull request incrementally with three additional commits since the last revision:

 - Some tests
 - Run all permutations of ArrayBaseOffsets test
 - Some more fixes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11044/files
  - new: https://git.openjdk.org/jdk/pull/11044/files/72b3ce26..f8a9298b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=01-02

  Stats: 261 lines in 6 files changed: 245 ins; 8 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/11044.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11044/head:pull/11044

PR: https://git.openjdk.org/jdk/pull/11044

From rkennke at openjdk.org  Thu Dec 15 13:12:48 2022
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 15 Dec 2022 13:12:48 GMT
Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v4]
In-Reply-To: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
References: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
Message-ID: <jkgG8U3KmKAL2QILsoIpF2yulBoyMtXDEkdOqj4s2A8=.b1121fbf-3ee6-451b-9a26-f3608c2ccba7@github.com>

> See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details.
> 
> Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements.
> 
> Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16.
> 
> Testing:
>  - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390)
>  - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390)
>  - [x] tier1 (x86_64, x86_32, aarch64, riscv)
>  - [x] tier2 (x86_64, aarch64, riscv)
>  - [x] tier3 (x86_64, riscv)

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Test for 32bit build

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11044/files
  - new: https://git.openjdk.org/jdk/pull/11044/files/f8a9298b..a279e12c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=02-03

  Stats: 13 lines in 1 file changed: 13 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11044.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11044/head:pull/11044

PR: https://git.openjdk.org/jdk/pull/11044

From jwaters at openjdk.org  Thu Dec 15 13:13:10 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 15 Dec 2022 13:13:10 GMT
Subject: RFR: 8297912: HotSpot Style Guide should permit alignas (Second
 Proposal Attempt) [v3]
In-Reply-To: <IR4wZ0h1SIeSAFLjug036bqINNJQrQFD90VTplI6jM4=.6af0451a-5523-4aa2-9a3e-6af66f6e059d@github.com>
References: <Lyv_ypxMsA5tjqJ3d4KwScyySdBcTo34lL8abbF4SoQ=.44f3b51c-30b8-428e-b715-6af70bccaaf5@github.com>
 <IR4wZ0h1SIeSAFLjug036bqINNJQrQFD90VTplI6jM4=.6af0451a-5523-4aa2-9a3e-6af66f6e059d@github.com>
Message-ID: <AMn5_2N1SSWENfGG6f_l5DbhH9bQYD20NdIVKuSjM5g=.acc82d22-05a0-4337-8bcf-7d9ca35fd219@github.com>

On Fri, 9 Dec 2022 12:33:06 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> [8252584](https://bugs.openjdk.org/browse/JDK-8252584) was integrated too early due to a mistake on my part, we should redo it and go through the proper approval process this time
>> 
>> (The changes in this commit are exactly identical to 8252584)
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Style

I'll leave integration of this up to someone else, for convenience

-------------

PR: https://git.openjdk.org/jdk/pull/11446

From rkennke at openjdk.org  Thu Dec 15 13:15:09 2022
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 15 Dec 2022 13:15:09 GMT
Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v4]
In-Reply-To: <BrkNEsaULOQoRzo2_NTWhk38L79QyV30LlZxvVJmWqc=.6f34cbbb-dff6-4f57-bf82-6d080c307d34@github.com>
References: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
 <1R_ePwUJKNgBklR3_r6KXJJsTAhRcMmkd0Vh-ZAGb_s=.997dab78-f36f-4c2e-9023-0fb3556cf0cc@github.com>
 <BrkNEsaULOQoRzo2_NTWhk38L79QyV30LlZxvVJmWqc=.6f34cbbb-dff6-4f57-bf82-6d080c307d34@github.com>
Message-ID: <EPgN_37bwjCThUfK05BRr5wWrW2uRi-fXM2ZxMcFL64=.d7dbaaa6-d49d-4d2c-8f65-85fa330d4ca6@github.com>

On Mon, 5 Dec 2022 13:41:58 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/share/oops/arrayOop.hpp line 141:
>> 
>>> 139: 
>>> 140:     const size_t max_size_bytes = align_down(SIZE_MAX - base_offset_in_bytes(type), MinObjAlignmentInBytes);
>>> 141:     const size_t max_elements_per_size_t = max_size_bytes / type2aelembytes(type);
>> 
>> Can we add an assert for max_size_bytes % type2aelembytes(type) == 0?
>
> Also, this is pre-existing, but I wonder why this section exists for 64-bit. Regardless of the array type, we will cap out below and return INT_MAX-2 or -3, depending on UseCCP. Why even bother calculating this? Am I missing something?

Yes, indeed. I improved the calculation, and it now only reduces INT_MAX for element types where it is actually needed (64-bit-types on 64bit builds, and >=32-bit-types on 32-bit-builds). Smaller types would not cause the overflow (see also tests in test_arrayOop.cpp, which I also improved a little).

-------------

PR: https://git.openjdk.org/jdk/pull/11044

From rkennke at openjdk.org  Thu Dec 15 13:23:10 2022
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 15 Dec 2022 13:23:10 GMT
Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v4]
In-Reply-To: <zK45ITO6l5zN1r9PcEdse6MwJ0j0lGxy0XJFzBsmw7o=.e31cb84e-70ce-4deb-b8e0-60f41974007d@github.com>
References: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
 <zK45ITO6l5zN1r9PcEdse6MwJ0j0lGxy0XJFzBsmw7o=.e31cb84e-70ce-4deb-b8e0-60f41974007d@github.com>
Message-ID: <hW9k93DX23bR3Gd3U0AsZMQocpXo0pZrxk-2p5uAxEo=.d1cf737c-4aaa-4e14-b195-159375f12135@github.com>

On Wed, 7 Dec 2022 08:04:54 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test for 32bit build
>
> src/hotspot/share/gc/shared/collectedHeap.cpp line 435:
> 
>> 433: 
>> 434: void CollectedHeap::zap_filler_array_with(HeapWord* start, size_t words, juint value) {
>> 435:   int payload_start = align_up(arrayOopDesc::base_offset_in_bytes(T_INT), HeapWordSize) / HeapWordSize;
> 
> I see this in a number of places in the patch. Could you explain why this is correct? If base offset is not HeapWordSize aligned, then it looks like payload_start * HeapWordSize would be larger than the base offset.

Good catch! I modified this section so that it explicitely zaps the leading unaligned element. I checked other similar patterns in the code, they do look correct, but I modified them to use heap_word_size() instead for clarity.

> src/hotspot/share/gc/z/zObjArrayAllocator.cpp line 55:
> 
>> 53:   const size_t header = arrayOopDesc::base_offset_in_bytes(element_type);
>> 54:   size_t byte_size = _word_size * BytesPerWord;
>> 55:   const size_t payload_size = byte_size - header;
> 
> Generational ZGC needs it to be able to write colored NULLs in object arrays, so a byte-centric approach will not work for us. Could you rewrite the code to take care of the "unaligned" 32 bits at the start of the array, and leave the word-centric segmented-clearing loop intact?

Right. I restored the previous code and align-up the base offset. Object arrays in ZGC would not use the leading unaligned 32bits anyway, afaik.

-------------

PR: https://git.openjdk.org/jdk/pull/11044

From rkennke at openjdk.org  Thu Dec 15 13:23:12 2022
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 15 Dec 2022 13:23:12 GMT
Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v4]
In-Reply-To: <1R_ePwUJKNgBklR3_r6KXJJsTAhRcMmkd0Vh-ZAGb_s=.997dab78-f36f-4c2e-9023-0fb3556cf0cc@github.com>
References: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
 <1R_ePwUJKNgBklR3_r6KXJJsTAhRcMmkd0Vh-ZAGb_s=.997dab78-f36f-4c2e-9023-0fb3556cf0cc@github.com>
Message-ID: <jPOLS2GTpBAcFLwkooJclGd0G_3V5oedjrt0IxHOGLU=.d4c20855-f242-463e-80bc-82e43ee418bf@github.com>

On Mon, 5 Dec 2022 13:45:38 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test for 32bit build
>
> src/hotspot/share/oops/arrayOop.hpp line 148:
> 
>> 146:       // overflowing an int when we add the header. See CRs 4718400 and 7110613.
>> 147:       int header_size_words = align_up(base_offset_in_bytes(type), HeapWordSize) / HeapWordSize;
>> 148:       return align_down(max_jint - header_size_words, MinObjAlignment);
> 
> I somehow was under the impression that for smaller types we should now have a larger max, since we can fit more elements.

Yes, but this doesn't have much to do with that it now fits better, but because smaller types would not cause the overflow. This was pre-existing, but I improved the calculation here anyway. Also, I filed:

https://bugs.openjdk.org/browse/JDK-8298863

to try and fix the remaining places where int is used for object size in words, and then we could use max_jint for all types.

-------------

PR: https://git.openjdk.org/jdk/pull/11044

From luhenry at openjdk.org  Thu Dec 15 13:27:11 2022
From: luhenry at openjdk.org (Ludovic Henry)
Date: Thu, 15 Dec 2022 13:27:11 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v13]
In-Reply-To: <d5iY-dwoEXUM9u1-exI-nkWwd9Hv-1QhVFSACbLtsz0=.2f040010-af30-40a5-8f19-1c5e3f8a01cd@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <pW8HHmh-dQnjrRftd052fBQVulqe_z5KldY76Hp-OmI=.a7a2b6e6-a182-45d2-bd11-16a406126482@github.com>
 <d5iY-dwoEXUM9u1-exI-nkWwd9Hv-1QhVFSACbLtsz0=.2f040010-af30-40a5-8f19-1c5e3f8a01cd@github.com>
Message-ID: <wvu5T2bGen5XIPti0lzD930sfSlqiXeTmAuxoE_xNds=.2203a097-0a97-46fa-a68f-ec7381ab337f@github.com>

On Wed, 16 Nov 2022 18:18:55 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Missing & 0xff in StringLatin1::hashCode
>
> I'm getting pulled into other tasks and would request for this to be either accepted as-is, rejected or picked up by someone else to rewrite it to something that can be accepted.
> 
> Obviously I'm biased towards acceptance: While imperfect, it provides improved testing - both functional and performance-wise - and establishes a significantly improved benchmark for more future-proof solutions to beat. There are many ways to iteratively improve upon this solution, some of which would even simplify the implementation. But in the face of upcoming changes that might allow C2 to optimize these kinds of loops without intrinsic support I am not sure spending more time on perfecting the current patch is worth our while.
> 
> Rejecting it might be the reasonable thing to do, too, especially if the C2 loop optimizations @iwanowww points out might be coming around sooner rather than later. Even if that's not coming soon, the PR at hand adds a chunk of complexity for the compiler team to maintain.

@cl4es @iwanowww is that change still good to go forward? What else would you like to see for it to be merged? Thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/10847

From rkennke at openjdk.org  Thu Dec 15 13:48:42 2022
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 15 Dec 2022 13:48:42 GMT
Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v5]
In-Reply-To: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
References: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
Message-ID: <jRETYotBUMAmU0carVZsYUdct2SsE5DzVj7xEkCSxw8=.0e671699-cc4e-4865-8b75-de7ffc627ec0@github.com>

> See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details.
> 
> Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements.
> 
> Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16.
> 
> Testing:
>  - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390)
>  - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390)
>  - [x] tier1 (x86_64, x86_32, aarch64, riscv)
>  - [x] tier2 (x86_64, aarch64, riscv)
>  - [x] tier3 (x86_64, riscv)

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  SA adjustments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11044/files
  - new: https://git.openjdk.org/jdk/pull/11044/files/a279e12c..ca491adc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=03-04

  Stats: 15 lines in 1 file changed: 7 ins; 5 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/11044.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11044/head:pull/11044

PR: https://git.openjdk.org/jdk/pull/11044

From rkennke at openjdk.org  Thu Dec 15 13:51:09 2022
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 15 Dec 2022 13:51:09 GMT
Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v5]
In-Reply-To: <1R_ePwUJKNgBklR3_r6KXJJsTAhRcMmkd0Vh-ZAGb_s=.997dab78-f36f-4c2e-9023-0fb3556cf0cc@github.com>
References: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
 <1R_ePwUJKNgBklR3_r6KXJJsTAhRcMmkd0Vh-ZAGb_s=.997dab78-f36f-4c2e-9023-0fb3556cf0cc@github.com>
Message-ID: <m9bO997U4x0q3IXQ9VbtCzy-xtvt-Nz0OcAcMcpVyPM=.2a086fa0-e92b-4498-9ead-2f50814e17db@github.com>

On Mon, 5 Dec 2022 14:52:15 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Are these all adaptations needed? I wonder about things like SA that know data structure layout.

Indeed, SA requires some changes too. Somewhat surprisingly it worked without changes, even in the context of Lilliput but this was perhaps only because several inconsistencies there added up to yield the correct result in the end. :-D 

> I ran the SAP nightlies with your patch and, as a test, UseCompressedClassPointers off. That generated a ton of noise unfortunately because many tests were unable to cope. A bunch of tests that created int arrays with Integer.MAX_VALUE-2 failed, but I soon discovered that they also fail in stock if you disable narrow class pointers.
> 

Yes. In Lilliput I needed to change some tests because of this. But it doesn't seem very relevant here.

> But still, I think it would be useful to disable compressed class pointers (if not set at the command line, make the default false), if only temporarily, and then see which tests fail. I won't have any more time for this before the next year, unfortunately.

Will do that.

I believe I addressed your and @stefank's requests. When you find time, I'd be happy about another round of review.

Thanks,
Roman

-------------

PR: https://git.openjdk.org/jdk/pull/11044

From lkorinth at openjdk.org  Thu Dec 15 13:56:27 2022
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 15 Dec 2022 13:56:27 GMT
Subject: RFR: 8292170: Convert CodeRootSetTable to use ResourceHashtable
 [v2]
In-Reply-To: <BdRsUwTHeM7gAUg1udRTeG-gv2S4slO0zYl5Ys21Pyw=.5701b960-0ecb-4c67-9d11-88d103b2bd0f@github.com>
References: <BdRsUwTHeM7gAUg1udRTeG-gv2S4slO0zYl5Ys21Pyw=.5701b960-0ecb-4c67-9d11-88d103b2bd0f@github.com>
Message-ID: <5HXRei7TWJJd_DCB-WI8as28GgqjIDAiHDf9u1vYt8A=.bfe2699e-5527-4ef4-a684-f36c579c7f1a@github.com>

> I am replacing the old hash table with ResourceHashtable. In the process I am also removing the redundant `_length` field. By removing the `_length` field, a lot of asserts can be removed as the length will trivially match the length of the underlying table.
> 
> I would like to have feedback on the addition of `unlink_destruct(Function&& should_remove)`. I added it because I prefer to use a functor object that can be used by lambdas instead of an iterator object. However, I did add code to "destruct" resource objects when they are removed instead of just letting them be to reflect that we use `delete` on c-heap objects. Maybe I should remove this "improvement" and then maybe implement the function by calling the existing unlink?

Leo Korinth has updated the pull request incrementally with two additional commits since the last revision:

 - copyrights
 - use iter function interface instead, make closure NONCOPYABLE

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11675/files
  - new: https://git.openjdk.org/jdk/pull/11675/files/df19ac4c..4861d0d3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11675&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11675&range=00-01

  Stats: 37 lines in 5 files changed: 1 ins; 30 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/11675.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11675/head:pull/11675

PR: https://git.openjdk.org/jdk/pull/11675

From lkorinth at openjdk.org  Thu Dec 15 13:59:05 2022
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 15 Dec 2022 13:59:05 GMT
Subject: RFR: 8292170: Convert CodeRootSetTable to use ResourceHashtable
In-Reply-To: <BdRsUwTHeM7gAUg1udRTeG-gv2S4slO0zYl5Ys21Pyw=.5701b960-0ecb-4c67-9d11-88d103b2bd0f@github.com>
References: <BdRsUwTHeM7gAUg1udRTeG-gv2S4slO0zYl5Ys21Pyw=.5701b960-0ecb-4c67-9d11-88d103b2bd0f@github.com>
Message-ID: <Qw7aGcijkSAHxp1FkAU08jbphmfizEpuPwIXv-UNJ5Q=.309a4e19-8317-4405-8013-33ff6c66759e@github.com>

On Wed, 14 Dec 2022 13:45:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> I am replacing the old hash table with ResourceHashtable. In the process I am also removing the redundant `_length` field. By removing the `_length` field, a lot of asserts can be removed as the length will trivially match the length of the underlying table.
> 
> I would like to have feedback on the addition of `unlink_destruct(Function&& should_remove)`. I added it because I prefer to use a functor object that can be used by lambdas instead of an iterator object. However, I did add code to "destruct" resource objects when they are removed instead of just letting them be to reflect that we use `delete` on c-heap objects. Maybe I should remove this "improvement" and then maybe implement the function by calling the existing unlink?

I changed the code to use the original iterator interface and made the closure NONCOPYABLE. Also updated copyrights.

-------------

PR: https://git.openjdk.org/jdk/pull/11675

From stefank at openjdk.org  Thu Dec 15 14:03:10 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 15 Dec 2022 14:03:10 GMT
Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v5]
In-Reply-To: <hW9k93DX23bR3Gd3U0AsZMQocpXo0pZrxk-2p5uAxEo=.d1cf737c-4aaa-4e14-b195-159375f12135@github.com>
References: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
 <zK45ITO6l5zN1r9PcEdse6MwJ0j0lGxy0XJFzBsmw7o=.e31cb84e-70ce-4deb-b8e0-60f41974007d@github.com>
 <hW9k93DX23bR3Gd3U0AsZMQocpXo0pZrxk-2p5uAxEo=.d1cf737c-4aaa-4e14-b195-159375f12135@github.com>
Message-ID: <rJZx1Firx3sNzgOqSvK93wCx1uaIFe5XZ580qmWbn94=.d8ca1932-e32d-4986-b6e3-5c87954b15e6@github.com>

On Thu, 15 Dec 2022 13:20:37 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> src/hotspot/share/gc/z/zObjArrayAllocator.cpp line 55:
>> 
>>> 53:   const size_t header = arrayOopDesc::base_offset_in_bytes(element_type);
>>> 54:   size_t byte_size = _word_size * BytesPerWord;
>>> 55:   const size_t payload_size = byte_size - header;
>> 
>> Generational ZGC needs it to be able to write colored NULLs in object arrays, so a byte-centric approach will not work for us. Could you rewrite the code to take care of the "unaligned" 32 bits at the start of the array, and leave the word-centric segmented-clearing loop intact?
>
> Right. I restored the previous code and align-up the base offset. Object arrays in ZGC would not use the leading unaligned 32bits anyway, afaik.

Note that even though the classes are named ObjArrayAllocator, this path is used for primitive arrays as well. I've wanted to change the name, but haven't gotten to it yet.

-------------

PR: https://git.openjdk.org/jdk/pull/11044

From coleenp at openjdk.org  Thu Dec 15 14:21:07 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 15 Dec 2022 14:21:07 GMT
Subject: RFR: 8292170: Convert CodeRootSetTable to use ResourceHashtable
 [v2]
In-Reply-To: <5HXRei7TWJJd_DCB-WI8as28GgqjIDAiHDf9u1vYt8A=.bfe2699e-5527-4ef4-a684-f36c579c7f1a@github.com>
References: <BdRsUwTHeM7gAUg1udRTeG-gv2S4slO0zYl5Ys21Pyw=.5701b960-0ecb-4c67-9d11-88d103b2bd0f@github.com>
 <5HXRei7TWJJd_DCB-WI8as28GgqjIDAiHDf9u1vYt8A=.bfe2699e-5527-4ef4-a684-f36c579c7f1a@github.com>
Message-ID: <RYrdRzuoZPo7KABN2KggcvTBfhljw_So_XcR0bAcJHU=.1b54c134-e73b-4806-a37a-b4a3b2e26766@github.com>

On Thu, 15 Dec 2022 13:56:27 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> I am replacing the old hash table with ResourceHashtable. In the process I am also removing the redundant `_length` field. By removing the `_length` field, a lot of asserts can be removed as the length will trivially match the length of the underlying table.
>> 
>> I would like to have feedback on the addition of `unlink_destruct(Function&& should_remove)`. I added it because I prefer to use a functor object that can be used by lambdas instead of an iterator object. However, I did add code to "destruct" resource objects when they are removed instead of just letting them be to reflect that we use `delete` on c-heap objects. Maybe I should remove this "improvement" and then maybe implement the function by calling the existing unlink?
>
> Leo Korinth has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - copyrights
>  - use iter function interface instead, make closure NONCOPYABLE

Well this looks A LOT better than the old hashtable and I'm hitting approve but I don't know this code so take that with a grain of salt.  Thank you.

src/hotspot/share/gc/g1/g1CodeCacheRemSet.cpp line 73:

> 71:   _table.iterate_all([&](nmethod* nm, nmethod* _) {
> 72:     blk->do_code_blob(nm);
> 73:   });

cool use of lambdas.

src/hotspot/share/gc/g1/g1CodeCacheRemSet.cpp line 222:

> 220:   CleanCallback should_clean(owner);
> 221:   if (_table != NULL) {
> 222:     _table->remove_if(should_clean);

remove_if is a template function but it's only called here.  Does it need to be a template function?

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11675

From rkennke at openjdk.org  Thu Dec 15 15:54:57 2022
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 15 Dec 2022 15:54:57 GMT
Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v6]
In-Reply-To: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
References: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
Message-ID: <uQgoq55LObm_o53nK1fmwUWWhWiaU60bA5fN7cIerlQ=.5be7209d-5f0e-4c6d-a9cc-2b242a942562@github.com>

> See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details.
> 
> Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements.
> 
> Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16.
> 
> Testing:
>  - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390)
>  - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390)
>  - [x] tier1 (x86_64, x86_32, aarch64, riscv)
>  - [x] tier2 (x86_64, aarch64, riscv)
>  - [x] tier3 (x86_64, riscv)

Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:

 - Clean cast warning from size_t to int
 - Clear leading 32bits in Z array allocator

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11044/files
  - new: https://git.openjdk.org/jdk/pull/11044/files/ca491adc..77e2ace4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=04-05

  Stats: 12 lines in 2 files changed: 9 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/11044.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11044/head:pull/11044

PR: https://git.openjdk.org/jdk/pull/11044

From rkennke at openjdk.org  Thu Dec 15 15:54:58 2022
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 15 Dec 2022 15:54:58 GMT
Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v6]
In-Reply-To: <rJZx1Firx3sNzgOqSvK93wCx1uaIFe5XZ580qmWbn94=.d8ca1932-e32d-4986-b6e3-5c87954b15e6@github.com>
References: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
 <zK45ITO6l5zN1r9PcEdse6MwJ0j0lGxy0XJFzBsmw7o=.e31cb84e-70ce-4deb-b8e0-60f41974007d@github.com>
 <hW9k93DX23bR3Gd3U0AsZMQocpXo0pZrxk-2p5uAxEo=.d1cf737c-4aaa-4e14-b195-159375f12135@github.com>
 <rJZx1Firx3sNzgOqSvK93wCx1uaIFe5XZ580qmWbn94=.d8ca1932-e32d-4986-b6e3-5c87954b15e6@github.com>
Message-ID: <BW2-dGQUWa-lhad65TstxoKYJqcOX9Z7QmL12StWfR0=.a70a9d7b-776f-44d7-b815-b6c1d4520b34@github.com>

On Thu, 15 Dec 2022 14:00:12 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Right. I restored the previous code and align-up the base offset. Object arrays in ZGC would not use the leading unaligned 32bits anyway, afaik.
>
> Note that even though the classes are named ObjArrayAllocator, this path is used for primitive arrays as well. I've wanted to change the name, but haven't gotten to it yet.

Oh dear! Ok, I've added a section to properly clean the leading 32 bits if necessary, and verified by running some Z tests with -XX:-UseCompressedClassPointers. Thanks for pointing this out!

-------------

PR: https://git.openjdk.org/jdk/pull/11044

From iwalulya at openjdk.org  Thu Dec 15 15:57:11 2022
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Thu, 15 Dec 2022 15:57:11 GMT
Subject: RFR: 8292170: Convert CodeRootSetTable to use ResourceHashtable
 [v2]
In-Reply-To: <5HXRei7TWJJd_DCB-WI8as28GgqjIDAiHDf9u1vYt8A=.bfe2699e-5527-4ef4-a684-f36c579c7f1a@github.com>
References: <BdRsUwTHeM7gAUg1udRTeG-gv2S4slO0zYl5Ys21Pyw=.5701b960-0ecb-4c67-9d11-88d103b2bd0f@github.com>
 <5HXRei7TWJJd_DCB-WI8as28GgqjIDAiHDf9u1vYt8A=.bfe2699e-5527-4ef4-a684-f36c579c7f1a@github.com>
Message-ID: <UK8rK575wPnX1g4053UWLpq1B1hYouZzcbKBqXibkes=.befba6c8-0d6b-489a-b73c-78201f4c7bb7@github.com>

On Thu, 15 Dec 2022 13:56:27 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> I am replacing the old hash table with ResourceHashtable. In the process I am also removing the redundant `_length` field. By removing the `_length` field, a lot of asserts can be removed as the length will trivially match the length of the underlying table.
>> 
>> I would like to have feedback on the addition of `unlink_destruct(Function&& should_remove)`. I added it because I prefer to use a functor object that can be used by lambdas instead of an iterator object. However, I did add code to "destruct" resource objects when they are removed instead of just letting them be to reflect that we use `delete` on c-heap objects. Maybe I should remove this "improvement" and then maybe implement the function by calling the existing unlink?
>
> Leo Korinth has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - copyrights
>  - use iter function interface instead, make closure NONCOPYABLE

Changes requested by iwalulya (Reviewer).

src/hotspot/share/gc/g1/g1CodeCacheRemSet.cpp line 42:

> 40: G1CodeRootSetTable* volatile G1CodeRootSetTable::_purge_list = NULL;
> 41: 
> 42: size_t G1CodeRootSetTable::mem_size() {

G1CodeRootSetTable::* definitions in `g1CodeCacheRemSet.cpp` make `g1CodeRootSetTable.hpp` seem redundant. Either add `g1CodeRootSetTable.cpp` or move the `G1CodeRootSetTable` declaration to `g1CodeCacheRemSet.hpp`

src/hotspot/share/gc/g1/g1CodeRootSetTable.hpp line 43:

> 41:   G1CodeRootSetTable* _purge_next;
> 42: 
> 43:   unsigned int compute_hash(nmethod* nm) {

Change makes this dead code

-------------

PR: https://git.openjdk.org/jdk/pull/11675

From lkorinth at openjdk.org  Thu Dec 15 15:57:12 2022
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 15 Dec 2022 15:57:12 GMT
Subject: RFR: 8292170: Convert CodeRootSetTable to use ResourceHashtable
 [v2]
In-Reply-To: <UK8rK575wPnX1g4053UWLpq1B1hYouZzcbKBqXibkes=.befba6c8-0d6b-489a-b73c-78201f4c7bb7@github.com>
References: <BdRsUwTHeM7gAUg1udRTeG-gv2S4slO0zYl5Ys21Pyw=.5701b960-0ecb-4c67-9d11-88d103b2bd0f@github.com>
 <5HXRei7TWJJd_DCB-WI8as28GgqjIDAiHDf9u1vYt8A=.bfe2699e-5527-4ef4-a684-f36c579c7f1a@github.com>
 <UK8rK575wPnX1g4053UWLpq1B1hYouZzcbKBqXibkes=.befba6c8-0d6b-489a-b73c-78201f4c7bb7@github.com>
Message-ID: <rKP_osxT-ZKnkU1d5AppTjtaoVZsjQ-FfbsSDVlYDKI=.067694ca-7533-4135-9440-b7931b5c3f5b@github.com>

On Thu, 15 Dec 2022 15:49:22 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - copyrights
>>  - use iter function interface instead, make closure NONCOPYABLE
>
> src/hotspot/share/gc/g1/g1CodeCacheRemSet.cpp line 42:
> 
>> 40: G1CodeRootSetTable* volatile G1CodeRootSetTable::_purge_list = NULL;
>> 41: 
>> 42: size_t G1CodeRootSetTable::mem_size() {
> 
> G1CodeRootSetTable::* definitions in `g1CodeCacheRemSet.cpp` make `g1CodeRootSetTable.hpp` seem redundant. Either add `g1CodeRootSetTable.cpp` or move the `G1CodeRootSetTable` declaration to `g1CodeCacheRemSet.hpp`

I will merge them.

-------------

PR: https://git.openjdk.org/jdk/pull/11675

From lkorinth at openjdk.org  Thu Dec 15 15:57:14 2022
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 15 Dec 2022 15:57:14 GMT
Subject: RFR: 8292170: Convert CodeRootSetTable to use ResourceHashtable
 [v2]
In-Reply-To: <RYrdRzuoZPo7KABN2KggcvTBfhljw_So_XcR0bAcJHU=.1b54c134-e73b-4806-a37a-b4a3b2e26766@github.com>
References: <BdRsUwTHeM7gAUg1udRTeG-gv2S4slO0zYl5Ys21Pyw=.5701b960-0ecb-4c67-9d11-88d103b2bd0f@github.com>
 <5HXRei7TWJJd_DCB-WI8as28GgqjIDAiHDf9u1vYt8A=.bfe2699e-5527-4ef4-a684-f36c579c7f1a@github.com>
 <RYrdRzuoZPo7KABN2KggcvTBfhljw_So_XcR0bAcJHU=.1b54c134-e73b-4806-a37a-b4a3b2e26766@github.com>
Message-ID: <sNHp6_CRmTbQtAkdE-irgONQ887El0Rf0g-3UPv-S2o=.2c2d1d9a-13f1-43c7-951c-0aaac9f53def@github.com>

On Thu, 15 Dec 2022 14:15:51 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - copyrights
>>  - use iter function interface instead, make closure NONCOPYABLE
>
> src/hotspot/share/gc/g1/g1CodeCacheRemSet.cpp line 222:
> 
>> 220:   CleanCallback should_clean(owner);
>> 221:   if (_table != NULL) {
>> 222:     _table->remove_if(should_clean);
> 
> remove_if is a template function but it's only called here.  Does it need to be a template function?

It does not, I will fix this.

-------------

PR: https://git.openjdk.org/jdk/pull/11675

From duke at openjdk.org  Thu Dec 15 15:59:11 2022
From: duke at openjdk.org (Ismael Juma)
Date: Thu, 15 Dec 2022 15:59:11 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v13]
In-Reply-To: <pW8HHmh-dQnjrRftd052fBQVulqe_z5KldY76Hp-OmI=.a7a2b6e6-a182-45d2-bd11-16a406126482@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <pW8HHmh-dQnjrRftd052fBQVulqe_z5KldY76Hp-OmI=.a7a2b6e6-a182-45d2-bd11-16a406126482@github.com>
Message-ID: <Xg9-_61r0KV5EzLlHiRgmr7JmcixExTuE3n0h2_QWTQ=.1031b959-a696-428c-bf0a-2a7f7c65c95a@github.com>

On Fri, 11 Nov 2022 13:00:06 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops.
>> 
>> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases.
>> 
>> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front.
>> 
>> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads.
>> 
>> With the most recent fixes the x64 intrinsic results on my workstation look like this:
>> 
>> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.199 ?  0.017  ns/op
>> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     6.933 ?  0.049  ns/op
>> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    29.935 ?  0.221  ns/op
>> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  1596.982 ?  7.020  ns/op
>> 
>> Baseline:
>> 
>> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.200 ?  0.013  ns/op
>> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     9.424 ?  0.122  ns/op
>> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    90.541 ?  0.512  ns/op
>> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  9425.321 ? 67.630  ns/op
>> 
>> I.e. no measurable overhead compared to baseline even for `size == 1`.
>> 
>> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good.
>> 
>> Benchmark for `Arrays.hashCode`:
>> 
>> Benchmark              (size)  Mode  Cnt     Score    Error  Units
>> ArraysHashCode.bytes        1  avgt    5     1.884 ?  0.013  ns/op
>> ArraysHashCode.bytes       10  avgt    5     6.955 ?  0.040  ns/op
>> ArraysHashCode.bytes      100  avgt    5    87.218 ?  0.595  ns/op
>> ArraysHashCode.bytes    10000  avgt    5  9419.591 ? 38.308  ns/op
>> ArraysHashCode.chars        1  avgt    5     2.200 ?  0.010  ns/op
>> ArraysHashCode.chars       10  avgt    5     6.935 ?  0.034  ns/op
>> ArraysHashCode.chars      100  avgt    5    30.216 ?  0.134  ns/op
>> ArraysHashCode.chars    10000  avgt    5  1601.629 ?  6.418  ns/op
>> ArraysHashCode.ints         1  avgt    5     2.200 ?  0.007  ns/op
>> ArraysHashCode.ints        10  avgt    5     6.936 ?  0.034  ns/op
>> ArraysHashCode.ints       100  avgt    5    29.412 ?  0.268  ns/op
>> ArraysHashCode.ints     10000  avgt    5  1610.578 ?  7.785  ns/op
>> ArraysHashCode.shorts       1  avgt    5     1.885 ?  0.012  ns/op
>> ArraysHashCode.shorts      10  avgt    5     6.961 ?  0.034  ns/op
>> ArraysHashCode.shorts     100  avgt    5    87.095 ?  0.417  ns/op
>> ArraysHashCode.shorts   10000  avgt    5  9420.617 ? 50.089  ns/op
>> 
>> Baseline:
>> 
>> Benchmark              (size)  Mode  Cnt     Score    Error  Units
>> ArraysHashCode.bytes        1  avgt    5     3.213 ?  0.207  ns/op
>> ArraysHashCode.bytes       10  avgt    5     8.483 ?  0.040  ns/op
>> ArraysHashCode.bytes      100  avgt    5    90.315 ?  0.655  ns/op
>> ArraysHashCode.bytes    10000  avgt    5  9422.094 ? 62.402  ns/op
>> ArraysHashCode.chars        1  avgt    5     3.040 ?  0.066  ns/op
>> ArraysHashCode.chars       10  avgt    5     8.497 ?  0.074  ns/op
>> ArraysHashCode.chars      100  avgt    5    90.074 ?  0.387  ns/op
>> ArraysHashCode.chars    10000  avgt    5  9420.474 ? 41.619  ns/op
>> ArraysHashCode.ints         1  avgt    5     2.827 ?  0.019  ns/op
>> ArraysHashCode.ints        10  avgt    5     7.727 ?  0.043  ns/op
>> ArraysHashCode.ints       100  avgt    5    89.405 ?  0.593  ns/op
>> ArraysHashCode.ints     10000  avgt    5  9426.539 ? 51.308  ns/op
>> ArraysHashCode.shorts       1  avgt    5     3.071 ?  0.062  ns/op
>> ArraysHashCode.shorts      10  avgt    5     8.168 ?  0.049  ns/op
>> ArraysHashCode.shorts     100  avgt    5    90.399 ?  0.292  ns/op
>> ArraysHashCode.shorts   10000  avgt    5  9420.171 ? 44.474  ns/op
>> 
>> 
>> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missing & 0xff in StringLatin1::hashCode

Are the C2 loop optimizations happening any time soon? If not, it seems pretty sensible to take this very significant win for a very common path. We can always remove it once the C2 loop optimizations can achieve results that are as good.

-------------

PR: https://git.openjdk.org/jdk/pull/10847

From lkorinth at openjdk.org  Thu Dec 15 16:05:10 2022
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 15 Dec 2022 16:05:10 GMT
Subject: RFR: 8292170: Convert CodeRootSetTable to use ResourceHashtable
 [v2]
In-Reply-To: <UK8rK575wPnX1g4053UWLpq1B1hYouZzcbKBqXibkes=.befba6c8-0d6b-489a-b73c-78201f4c7bb7@github.com>
References: <BdRsUwTHeM7gAUg1udRTeG-gv2S4slO0zYl5Ys21Pyw=.5701b960-0ecb-4c67-9d11-88d103b2bd0f@github.com>
 <5HXRei7TWJJd_DCB-WI8as28GgqjIDAiHDf9u1vYt8A=.bfe2699e-5527-4ef4-a684-f36c579c7f1a@github.com>
 <UK8rK575wPnX1g4053UWLpq1B1hYouZzcbKBqXibkes=.befba6c8-0d6b-489a-b73c-78201f4c7bb7@github.com>
Message-ID: <qNGkn8P_aOAQl6wEZNUhwb9tYNJ-5EyXIQXg0mTR7W8=.7b0549f1-d463-4f3d-b8cc-94383e751de6@github.com>

On Thu, 15 Dec 2022 15:50:05 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - copyrights
>>  - use iter function interface instead, make closure NONCOPYABLE
>
> src/hotspot/share/gc/g1/g1CodeRootSetTable.hpp line 43:
> 
>> 41:   G1CodeRootSetTable* _purge_next;
>> 42: 
>> 43:   unsigned int compute_hash(nmethod* nm) {
> 
> Change makes this dead code

I do not understand, I am still "using"  Table in `mem_size`, or did you mean something else?

-------------

PR: https://git.openjdk.org/jdk/pull/11675

From iwalulya at openjdk.org  Thu Dec 15 16:05:10 2022
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Thu, 15 Dec 2022 16:05:10 GMT
Subject: RFR: 8292170: Convert CodeRootSetTable to use ResourceHashtable
 [v2]
In-Reply-To: <qNGkn8P_aOAQl6wEZNUhwb9tYNJ-5EyXIQXg0mTR7W8=.7b0549f1-d463-4f3d-b8cc-94383e751de6@github.com>
References: <BdRsUwTHeM7gAUg1udRTeG-gv2S4slO0zYl5Ys21Pyw=.5701b960-0ecb-4c67-9d11-88d103b2bd0f@github.com>
 <5HXRei7TWJJd_DCB-WI8as28GgqjIDAiHDf9u1vYt8A=.bfe2699e-5527-4ef4-a684-f36c579c7f1a@github.com>
 <UK8rK575wPnX1g4053UWLpq1B1hYouZzcbKBqXibkes=.befba6c8-0d6b-489a-b73c-78201f4c7bb7@github.com>
 <qNGkn8P_aOAQl6wEZNUhwb9tYNJ-5EyXIQXg0mTR7W8=.7b0549f1-d463-4f3d-b8cc-94383e751de6@github.com>
Message-ID: <G6Swkz0Mw38SL7Pf_mYP_jcP7WZvrp4emrhsI9wPxpI=.e5cfbfcf-8b95-4909-a10a-6d0b1bc362a8@github.com>

On Thu, 15 Dec 2022 16:00:36 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/g1CodeRootSetTable.hpp line 43:
>> 
>>> 41:   G1CodeRootSetTable* _purge_next;
>>> 42: 
>>> 43:   unsigned int compute_hash(nmethod* nm) {
>> 
>> Change makes this dead code
>
> I do not understand, I am still "using"  Table in `mem_size`, or did you mean something else?

`unsigned int compute_hash(nmethod* nm) {` function,  sorry for not being clear

-------------

PR: https://git.openjdk.org/jdk/pull/11675

From lkorinth at openjdk.org  Thu Dec 15 16:15:10 2022
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 15 Dec 2022 16:15:10 GMT
Subject: RFR: 8292170: Convert CodeRootSetTable to use ResourceHashtable
 [v2]
In-Reply-To: <G6Swkz0Mw38SL7Pf_mYP_jcP7WZvrp4emrhsI9wPxpI=.e5cfbfcf-8b95-4909-a10a-6d0b1bc362a8@github.com>
References: <BdRsUwTHeM7gAUg1udRTeG-gv2S4slO0zYl5Ys21Pyw=.5701b960-0ecb-4c67-9d11-88d103b2bd0f@github.com>
 <5HXRei7TWJJd_DCB-WI8as28GgqjIDAiHDf9u1vYt8A=.bfe2699e-5527-4ef4-a684-f36c579c7f1a@github.com>
 <UK8rK575wPnX1g4053UWLpq1B1hYouZzcbKBqXibkes=.befba6c8-0d6b-489a-b73c-78201f4c7bb7@github.com>
 <qNGkn8P_aOAQl6wEZNUhwb9tYNJ-5EyXIQXg0mTR7W8=.7b0549f1-d463-4f3d-b8cc-94383e751de6@github.com>
 <G6Swkz0Mw38SL7Pf_mYP_jcP7WZvrp4emrhsI9wPxpI=.e5cfbfcf-8b95-4909-a10a-6d0b1bc362a8@github.com>
Message-ID: <lB9I63fdyD0NRzSiwbVD63z-gxtlFbHZgoJrf29WBak=.ebfabb5d-eb86-423c-9509-9dc5cc5e56a7@github.com>

On Thu, 15 Dec 2022 16:02:01 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> I do not understand, I am still "using"  Table in `mem_size`, or did you mean something else?
>
> `unsigned int compute_hash(nmethod* nm) {` function,  sorry for not being clear

Yes, will fix, nice find!

-------------

PR: https://git.openjdk.org/jdk/pull/11675

From lkorinth at openjdk.org  Thu Dec 15 16:19:37 2022
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 15 Dec 2022 16:19:37 GMT
Subject: RFR: 8292170: Convert CodeRootSetTable to use ResourceHashtable
 [v3]
In-Reply-To: <BdRsUwTHeM7gAUg1udRTeG-gv2S4slO0zYl5Ys21Pyw=.5701b960-0ecb-4c67-9d11-88d103b2bd0f@github.com>
References: <BdRsUwTHeM7gAUg1udRTeG-gv2S4slO0zYl5Ys21Pyw=.5701b960-0ecb-4c67-9d11-88d103b2bd0f@github.com>
Message-ID: <H-mQpvo2mM7d43WzuRGYoA0lSvAbRbvVUCxZHRYvU8w=.d2198ed3-1dcb-4965-a708-acc954bd9766@github.com>

> I am replacing the old hash table with ResourceHashtable. In the process I am also removing the redundant `_length` field. By removing the `_length` field, a lot of asserts can be removed as the length will trivially match the length of the underlying table.
> 
> I would like to have feedback on the addition of `unlink_destruct(Function&& should_remove)`. I added it because I prefer to use a functor object that can be used by lambdas instead of an iterator object. However, I did add code to "destruct" resource objects when they are removed instead of just letting them be to reflect that we use `delete` on c-heap objects. Maybe I should remove this "improvement" and then maybe implement the function by calling the existing unlink?

Leo Korinth has updated the pull request incrementally with three additional commits since the last revision:

 - remove specialized hash
 - inline g1CodeRootSetTable.hpp
 - remove unused template

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11675/files
  - new: https://git.openjdk.org/jdk/pull/11675/files/4861d0d3..0887a73e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11675&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11675&range=01-02

  Stats: 121 lines in 4 files changed: 41 ins; 78 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11675.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11675/head:pull/11675

PR: https://git.openjdk.org/jdk/pull/11675

From rkennke at openjdk.org  Thu Dec 15 19:05:34 2022
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 15 Dec 2022 19:05:34 GMT
Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v7]
In-Reply-To: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
References: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
Message-ID: <poFOV7Cqt2G6grEhbFcnPyoGTc8c7cqDCgLivs-fpTs=.2d5e060f-d220-4f55-91f4-597127c87358@github.com>

> See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details.
> 
> Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements.
> 
> Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16.
> 
> Testing:
>  - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390)
>  - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390)
>  - [x] tier1 (x86_64, x86_32, aarch64, riscv)
>  - [x] tier2 (x86_64, aarch64, riscv)
>  - [x] tier3 (x86_64, riscv)

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Fix another cast warning

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11044/files
  - new: https://git.openjdk.org/jdk/pull/11044/files/77e2ace4..4ec977cf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11044.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11044/head:pull/11044

PR: https://git.openjdk.org/jdk/pull/11044

From kvn at openjdk.org  Thu Dec 15 19:38:05 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 15 Dec 2022 19:38:05 GMT
Subject: RFR: 8297912: HotSpot Style Guide should permit alignas (Second
 Proposal Attempt) [v3]
In-Reply-To: <IR4wZ0h1SIeSAFLjug036bqINNJQrQFD90VTplI6jM4=.6af0451a-5523-4aa2-9a3e-6af66f6e059d@github.com>
References: <Lyv_ypxMsA5tjqJ3d4KwScyySdBcTo34lL8abbF4SoQ=.44f3b51c-30b8-428e-b715-6af70bccaaf5@github.com>
 <IR4wZ0h1SIeSAFLjug036bqINNJQrQFD90VTplI6jM4=.6af0451a-5523-4aa2-9a3e-6af66f6e059d@github.com>
Message-ID: <hXfy0baFoUhtNGnhCocngLMbKaukO4WWMYRf-8yHlVY=.ea881c3b-b3c3-4acb-bff1-122acf1eb7fa@github.com>

On Fri, 9 Dec 2022 12:33:06 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> [8252584](https://bugs.openjdk.org/browse/JDK-8252584) was integrated too early due to a mistake on my part, we should redo it and go through the proper approval process this time
>> 
>> (The changes in this commit are exactly identical to 8252584)
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Style

Per process I approve these changes.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11446

From jwaters at openjdk.org  Thu Dec 15 19:42:09 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 15 Dec 2022 19:42:09 GMT
Subject: Integrated: 8297912: HotSpot Style Guide should permit alignas (Second
 Proposal Attempt)
In-Reply-To: <Lyv_ypxMsA5tjqJ3d4KwScyySdBcTo34lL8abbF4SoQ=.44f3b51c-30b8-428e-b715-6af70bccaaf5@github.com>
References: <Lyv_ypxMsA5tjqJ3d4KwScyySdBcTo34lL8abbF4SoQ=.44f3b51c-30b8-428e-b715-6af70bccaaf5@github.com>
Message-ID: <gZxdzSOd5us3tXxzz2R1M-GHhoCB_YyvhzvxfSpRK2E=.8b045070-aa20-4f77-8878-12d81d5c9990@github.com>

On Thu, 1 Dec 2022 04:34:56 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> [8252584](https://bugs.openjdk.org/browse/JDK-8252584) was integrated too early due to a mistake on my part, we should redo it and go through the proper approval process this time
> 
> (The changes in this commit are exactly identical to 8252584)

This pull request has now been integrated.

Changeset: ae8988e8
Author:    Julian Waters <jwaters at openjdk.org>
Committer: Vladimir Kozlov <kvn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ae8988e834032d9d6a4b644c3ebf9ee1957c9522
Stats:     95 lines in 2 files changed: 93 ins; 0 del; 2 mod

8297912: HotSpot Style Guide should permit alignas (Second Proposal Attempt)

Reviewed-by: kbarrett, stuefe, kvn

-------------

PR: https://git.openjdk.org/jdk/pull/11446

From dholmes at openjdk.org  Thu Dec 15 21:20:31 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 15 Dec 2022 21:20:31 GMT
Subject: RFR: 8298241: Replace C-style casts with JavaThread::cast [v2]
In-Reply-To: <6NksENBkkBRd2KR0c5kYlmruycaqoGx-Z_-h6lkb9ms=.a133b578-12a3-4ca6-9636-0159e305c5a5@github.com>
References: <6NksENBkkBRd2KR0c5kYlmruycaqoGx-Z_-h6lkb9ms=.a133b578-12a3-4ca6-9636-0159e305c5a5@github.com>
Message-ID: <KAvi9L8L4IPTdYnx9nS-ffl0AIZJfUQsolcgZIzGlqQ=.27175c05-ff52-4cd0-b6c4-7881a8d2170d@github.com>

> This is a simple cleanup RFE to get rid of old-style C casts in relation to JavaThread.
> 
> In many cases involving NULL/nullptr the cast could just be dropped. Sometimes a static cast is needed to disambiguate overloads.
> 
> A couple of reinterpret_cast are needed when doing int/ptr conversion.
> 
> static_cast is used for void* conversion.
> 
> The other changes should be self explanatory.
> 
> The changes in
> 
> src/hotspot/os_cpu/bsd_aarch64/javaThread_bsd_aarch64.cpp
> src/hotspot/os_cpu/windows_aarch64/javaThread_windows_aarch64.cpp
> 
> are a bit more extensive. That code was using an alias for `this` which is completely unnecessary (and the alias creation was using the cast). This could be factored out if thought necessary.
> 
> I grep'd as best I could for the old C-style casts but can't be certain I got them all.
> 
> Testing: 
>  - all builds in our tiers1-5
>  - local linux x64 product, slowdebug and fastdebug
>  - GHA
>  - Sanity testing tiers 1-3
> Thanks.

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Fixed commented examle.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11682/files
  - new: https://git.openjdk.org/jdk/pull/11682/files/5641507a..34f2745d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11682&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11682&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11682.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11682/head:pull/11682

PR: https://git.openjdk.org/jdk/pull/11682

From dholmes at openjdk.org  Thu Dec 15 21:20:31 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 15 Dec 2022 21:20:31 GMT
Subject: RFR: 8298241: Replace C-style casts with JavaThread::cast [v2]
In-Reply-To: <JsFAinF_LqKouAWpOBNbllBFpvgnTrFQblRbJnufwDY=.b149b9f0-6faa-4c5f-a1b9-a2dc59602a81@github.com>
References: <6NksENBkkBRd2KR0c5kYlmruycaqoGx-Z_-h6lkb9ms=.a133b578-12a3-4ca6-9636-0159e305c5a5@github.com>
 <JsFAinF_LqKouAWpOBNbllBFpvgnTrFQblRbJnufwDY=.b149b9f0-6faa-4c5f-a1b9-a2dc59602a81@github.com>
Message-ID: <zxH8hNrL8AAaIIU5paKV5Pk0EJ_L_v8R9Yt3uXglWvk=.ddc4204f-7e09-434e-997f-aa04c9820f7c@github.com>

On Thu, 15 Dec 2022 07:07:26 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed commented examle.
>
> Marked as reviewed by stefank (Reviewer).

Thanks for the reviews @stefank  and @sspitsyn !

> src/hotspot/share/runtime/frame.cpp line 1568:
> 
>> 1566:     }
>> 1567:   }
>> 1568:   // if (error) { tty->cr(); print_on(nullptr, tty); }
> 
> This probably need the same cast as in print_frame_layout, to disambiguate the call.

Fixed

-------------

PR: https://git.openjdk.org/jdk/pull/11682

From dholmes at openjdk.org  Thu Dec 15 21:20:32 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 15 Dec 2022 21:20:32 GMT
Subject: Integrated: 8298241: Replace C-style casts with JavaThread::cast
In-Reply-To: <6NksENBkkBRd2KR0c5kYlmruycaqoGx-Z_-h6lkb9ms=.a133b578-12a3-4ca6-9636-0159e305c5a5@github.com>
References: <6NksENBkkBRd2KR0c5kYlmruycaqoGx-Z_-h6lkb9ms=.a133b578-12a3-4ca6-9636-0159e305c5a5@github.com>
Message-ID: <lPTq5YGLAbONseoFbglraWLSYLRoM-sVS3NsbHm6PTI=.1706b724-bf2e-4a36-b311-18cc89ebc0b0@github.com>

On Wed, 14 Dec 2022 22:22:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This is a simple cleanup RFE to get rid of old-style C casts in relation to JavaThread.
> 
> In many cases involving NULL/nullptr the cast could just be dropped. Sometimes a static cast is needed to disambiguate overloads.
> 
> A couple of reinterpret_cast are needed when doing int/ptr conversion.
> 
> static_cast is used for void* conversion.
> 
> The other changes should be self explanatory.
> 
> The changes in
> 
> src/hotspot/os_cpu/bsd_aarch64/javaThread_bsd_aarch64.cpp
> src/hotspot/os_cpu/windows_aarch64/javaThread_windows_aarch64.cpp
> 
> are a bit more extensive. That code was using an alias for `this` which is completely unnecessary (and the alias creation was using the cast). This could be factored out if thought necessary.
> 
> I grep'd as best I could for the old C-style casts but can't be certain I got them all.
> 
> Testing: 
>  - all builds in our tiers1-5
>  - local linux x64 product, slowdebug and fastdebug
>  - GHA
>  - Sanity testing tiers 1-3
> Thanks.

This pull request has now been integrated.

Changeset: 3cdbd878
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3cdbd878e68dc1131093137a7357710ad303ae8c
Stats:     44 lines in 19 files changed: 0 ins; 11 del; 33 mod

8298241: Replace C-style casts with JavaThread::cast

Reviewed-by: coleenp, stefank, sspitsyn

-------------

PR: https://git.openjdk.org/jdk/pull/11682

From dnsimon at openjdk.org  Thu Dec 15 22:24:09 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 15 Dec 2022 22:24:09 GMT
Subject: RFR: 8298241: Replace C-style casts with JavaThread::cast [v2]
In-Reply-To: <KAvi9L8L4IPTdYnx9nS-ffl0AIZJfUQsolcgZIzGlqQ=.27175c05-ff52-4cd0-b6c4-7881a8d2170d@github.com>
References: <6NksENBkkBRd2KR0c5kYlmruycaqoGx-Z_-h6lkb9ms=.a133b578-12a3-4ca6-9636-0159e305c5a5@github.com>
 <KAvi9L8L4IPTdYnx9nS-ffl0AIZJfUQsolcgZIzGlqQ=.27175c05-ff52-4cd0-b6c4-7881a8d2170d@github.com>
Message-ID: <izLJUuJdorQMconqmP3EeP1-VewJARmWsO40L9nWE-s=.43fbdb21-8557-4047-8ec6-fca84af6901b@github.com>

On Thu, 15 Dec 2022 21:20:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This is a simple cleanup RFE to get rid of old-style C casts in relation to JavaThread.
>> 
>> In many cases involving NULL/nullptr the cast could just be dropped. Sometimes a static cast is needed to disambiguate overloads.
>> 
>> A couple of reinterpret_cast are needed when doing int/ptr conversion.
>> 
>> static_cast is used for void* conversion.
>> 
>> The other changes should be self explanatory.
>> 
>> The changes in
>> 
>> src/hotspot/os_cpu/bsd_aarch64/javaThread_bsd_aarch64.cpp
>> src/hotspot/os_cpu/windows_aarch64/javaThread_windows_aarch64.cpp
>> 
>> are a bit more extensive. That code was using an alias for `this` which is completely unnecessary (and the alias creation was using the cast). This could be factored out if thought necessary.
>> 
>> I grep'd as best I could for the old C-style casts but can't be certain I got them all.
>> 
>> Testing: 
>>  - all builds in our tiers1-5
>>  - local linux x64 product, slowdebug and fastdebug
>>  - GHA
>>  - Sanity testing tiers 1-3
>> Thanks.
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed commented examle.

Is it possible to add a test based on grep to prevent re-introduction of the unwanted C-style casts?

-------------

PR: https://git.openjdk.org/jdk/pull/11682

From dholmes at openjdk.org  Fri Dec 16 02:24:07 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 16 Dec 2022 02:24:07 GMT
Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling
 one virtual thread transitions
In-Reply-To: <z8NCIbPeF0WzTEzXGyNxlnuOF_52vbV90p4B15xThFk=.b12cfe49-d27d-4e65-9027-796985005c14@github.com>
References: <z8NCIbPeF0WzTEzXGyNxlnuOF_52vbV90p4B15xThFk=.b12cfe49-d27d-4e65-9027-796985005c14@github.com>
Message-ID: <avFztZhk1NDj_YekziZXXUKwiuGEWhFWabEsn010qmY=.07faf892-3bdb-4ea9-92a1-4763c77315a0@github.com>

On Thu, 15 Dec 2022 11:51:10 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Now the `JvmtiVTMSTransitionDisabler` mechanism supports disabling VTMS transitions for all virtual threads only. It should also support disabling transitions for any specific virtual thread as well. This will improve scalability of the JVMTI functions operating on target virtual threads as the functions can be executed concurrently without blocking each other execution when target virtual threads are different.
> New constructor `JvmtiVTMSTransitionDisabler(jthread vthread)` is added which has jthread parameter of the target virtual thread.
> 
> Testing:
>   mach5 jobs are TBD (preliminary testing was completed):
>    - all JVMTI, JDWP, JDI and JDB tests have to be run
>    - Kitchensink
>    - tier5

Seems logical though I'm not familiar with the existing mechanisms. A few minor comments.

Thanks.

src/hotspot/share/classfile/javaClasses.cpp line 1745:

> 1743:   int val = VTMS_transition_disable_count(java_thread);
> 1744:   java_thread->int_field_put(_jvmti_VTMS_transition_disable_count_offset, val - 1);
> 1745: }

These are not thread-safe functions. What constraints exist for using these methods safely?
Update: looks like they must be called with the lock held so we should assert that.
Should also assert the count never goes negative (which I assume would be an error?).

src/hotspot/share/prims/jvmtiThreadState.cpp line 252:

> 250:     return; // JvmtiVTMSTransitionDisabler is no-op without virtual threads
> 251:   }
> 252:   if (Thread::current_or_null() == NULL) {

Nit: please use `nullptr` in new code

src/hotspot/share/prims/jvmtiThreadState.cpp line 273:

> 271:   }
> 272:   _is_SR = is_SR;
> 273:   _vthread = NULL;

Nit: should initialize in init list

src/hotspot/share/prims/jvmtiThreadState.cpp line 298:

> 296:   HandleMark hm(thread);
> 297:   Handle vth = Handle(thread, JNIHandles::resolve_external_guard(_vthread));
> 298:   if (!java_lang_VirtualThread::is_instance(vth())) {

How can this condition not be true? Should it be an assertion?

src/hotspot/share/prims/jvmtiThreadState.cpp line 304:

> 302: 
> 303:   ThreadBlockInVM tbivm(thread);
> 304:   MonitorLocker ml(JvmtiVTMSTransition_lock, Mutex::_no_safepoint_check_flag);

Aside: this pattern looks very odd. Why not just lock with the safepoint check?

-------------

PR: https://git.openjdk.org/jdk/pull/11690

From dholmes at openjdk.org  Fri Dec 16 07:16:05 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 16 Dec 2022 07:16:05 GMT
Subject: RFR: 8295974: jni_FatalError and Xcheck:jni warnings should print the
 native stack when there are no Java frames
Message-ID: <s_Ttmm80UcUu6OOWSZKD95u18WWZufwlMKPW-Gw9ZeE=.b77b8d96-8249-4754-8a0f-1bcf032f465c@github.com>

If a JNI Fatal error, or a JNI warning (from Xcheck:jni) is triggered in "top-level" native code (such as the launcher itself, or a freshly attached native thread) then there is no stack printed as there are no Java frames. This enhancement changes that so that we print the native stack, similarly to how error reporting does. We reuse VMError::print_native _stack to do this, but it could be argued this should be moved to a more general purpose utility class - suggestions welcome.

Testing:
  - manual fault injection (see bug report)
  - tiers 1-4

Thanks.

-------------

Commit messages:
 - Remove unnecessary include
 - 8295974: jni_FatalError and Xcheck:jni warnings should print the native stack when there are no Java frames
 - Merge branch 'master' into 8295974-jni-fatal-native
 - Interim commit with alternate code options.

Changes: https://git.openjdk.org/jdk/pull/11703/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11703&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295974
  Stats: 30 lines in 2 files changed: 16 ins; 9 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/11703.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11703/head:pull/11703

PR: https://git.openjdk.org/jdk/pull/11703

From duke at openjdk.org  Fri Dec 16 08:04:52 2022
From: duke at openjdk.org (Afshin Zafari)
Date: Fri, 16 Dec 2022 08:04:52 GMT
Subject: RFR: 8298128: runtime/ErrorHandling/TestSigInfoInHsErrFile.java fails
 to find pattern with slowdebug
Message-ID: <l_-0Uq121JKyIh09JDZ23uSYQPZbLwpg_8GOXRnEuKY=.1655ef89-b023-4653-bc05-e4318ce9399a@github.com>

### Description
The following problems found and solved:

1) Reporting which regex pattern did not match with error messages was incorrect. To report the mismatched pattern, the head of the pattern list was peeked, while it was the already peeked item from that did not match. So the next pattern to the mismatched one was reported.

2) The pattern for finding a crash was incorrectly set to "# .*VMError::controlled_crash.*", while it has to be "# .*crash_with_segfault.*".

3) `crash_with_segfault` function is too small and was `inline`d in compiler optimisations. So it was not in the stack trace when the error message is created.

### Patch
1 and 2 corrected and added the `NOINLINE` to  the `crash_with_segfault` signature. The same applied for `crash_with_sigfpe` function.

### Test
runtime/ErrorHandling/* and tier1-5

-------------

Commit messages:
 - Merge branch 'master' into _8298128
 - 8298128: runtime/ErrorHandling/TestSigInfoInHsErrFile.java fails to find pattern with slowdebug

Changes: https://git.openjdk.org/jdk/pull/11704/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11704&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298128
  Stats: 14 lines in 4 files changed: 8 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/11704.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11704/head:pull/11704

PR: https://git.openjdk.org/jdk/pull/11704

From rehn at openjdk.org  Fri Dec 16 08:30:03 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Fri, 16 Dec 2022 08:30:03 GMT
Subject: RFR: 8298128: runtime/ErrorHandling/TestSigInfoInHsErrFile.java
 fails to find pattern with slowdebug
In-Reply-To: <l_-0Uq121JKyIh09JDZ23uSYQPZbLwpg_8GOXRnEuKY=.1655ef89-b023-4653-bc05-e4318ce9399a@github.com>
References: <l_-0Uq121JKyIh09JDZ23uSYQPZbLwpg_8GOXRnEuKY=.1655ef89-b023-4653-bc05-e4318ce9399a@github.com>
Message-ID: <MIuV0knr1C1JCkI04zOF6yF1vm0PSve-pv3xe50bDFY=.a8bf5036-8193-4561-9b9b-1e1a120b934f@github.com>

On Fri, 16 Dec 2022 07:56:39 GMT, Afshin Zafari <duke at openjdk.org> wrote:

> ### Description
> The following problems found and solved:
> 
> 1) Reporting which regex pattern did not match with error messages was incorrect. To report the mismatched pattern, the head of the pattern list was peeked, while it was the already peeked item from that did not match. So the next pattern to the mismatched one was reported.
> 
> 2) The pattern for finding a crash was incorrectly set to "# .*VMError::controlled_crash.*", while it has to be "# .*crash_with_segfault.*".
> 
> 3) `crash_with_segfault` function is too small and was `inline`d in compiler optimisations. So it was not in the stack trace when the error message is created.
> 
> ### Patch
> 1 and 2 corrected and added the `NOINLINE` to  the `crash_with_segfault` signature. The same applied for `crash_with_sigfpe` function.
> 
> ### Test
> runtime/ErrorHandling/* and tier1-5

Seems good to me! Thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/11704

From duke at openjdk.org  Fri Dec 16 09:38:13 2022
From: duke at openjdk.org (Damon Fenacci)
Date: Fri, 16 Dec 2022 09:38:13 GMT
Subject: RFR: 8283740: C1: Convert flag TwoOperandLIRForm to a constant on all
 platforms
Message-ID: <docGN73VgNwGZojMnrVyvZqCnRBlDKEyw4xTscqa0qc=.d263a7b3-5c40-4835-897b-f35b8bacd843@github.com>

The  _TwoOperandLIRForm_ flag (LIR requires src1 and dst to match in binary LIR ops) can be set at runtime but each platform defines a default value that is the only one accepted. Although some platform could theoretically support both, there is no realistic scenario for this.
The flag is removed in favour of a constant. This is defined as enum and its assigned value is defined in the platform-specific def.

-------------

Commit messages:
 - JDK-8283740: C1: Convert flag TwoOperandLIRForm to a constant on all platforms

Changes: https://git.openjdk.org/jdk/pull/11671/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11671&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8283740
  Stats: 62 lines in 19 files changed: 29 ins; 9 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/11671.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11671/head:pull/11671

PR: https://git.openjdk.org/jdk/pull/11671

From thartmann at openjdk.org  Fri Dec 16 09:38:14 2022
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 16 Dec 2022 09:38:14 GMT
Subject: RFR: 8283740: C1: Convert flag TwoOperandLIRForm to a constant on
 all platforms
In-Reply-To: <docGN73VgNwGZojMnrVyvZqCnRBlDKEyw4xTscqa0qc=.d263a7b3-5c40-4835-897b-f35b8bacd843@github.com>
References: <docGN73VgNwGZojMnrVyvZqCnRBlDKEyw4xTscqa0qc=.d263a7b3-5c40-4835-897b-f35b8bacd843@github.com>
Message-ID: <duwY0GMAMKdK36opl5GD7-5F1aEpxXEuDlvtX9qMz3Q=.f6fc4039-3b61-4700-87a2-fb6b4d4839de@github.com>

On Wed, 14 Dec 2022 12:51:58 GMT, Damon Fenacci <duke at openjdk.org> wrote:

> The  _TwoOperandLIRForm_ flag (LIR requires src1 and dst to match in binary LIR ops) can be set at runtime but each platform defines a default value that is the only one accepted. Although some platform could theoretically support both, there is no realistic scenario for this.
> The flag is removed in favour of a constant. This is defined as enum and its assigned value is defined in the platform-specific def.

That looks good to me but I think all these platform dependent constants should be converted to `static const` declarations at some point. From what I understand, enums are used here only [for historical reasons](https://stackoverflow.com/questions/899917/why-do-people-use-enums-in-c-as-constants-while-they-can-use-const). Could you file a follow-up RFE to investigate?

And FTR:

Due to bugs in certain (very old) compilers, there is widespread use of enums and avoidance of in-class initialization of static integral constant members. Compilers having such bugs are no longer supported. Except where an enum is semantically appropriate, new code should use integral constants.

https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11671

From chagedorn at openjdk.org  Fri Dec 16 09:38:14 2022
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Fri, 16 Dec 2022 09:38:14 GMT
Subject: RFR: 8283740: C1: Convert flag TwoOperandLIRForm to a constant on
 all platforms
In-Reply-To: <docGN73VgNwGZojMnrVyvZqCnRBlDKEyw4xTscqa0qc=.d263a7b3-5c40-4835-897b-f35b8bacd843@github.com>
References: <docGN73VgNwGZojMnrVyvZqCnRBlDKEyw4xTscqa0qc=.d263a7b3-5c40-4835-897b-f35b8bacd843@github.com>
Message-ID: <Z8DhK_4TBZS4rLGiaVsM_sUCrXw8PKaJtnseFCejICg=.1e6809e3-c68f-4553-8972-93a9ad188d8d@github.com>

On Wed, 14 Dec 2022 12:51:58 GMT, Damon Fenacci <duke at openjdk.org> wrote:

> The  _TwoOperandLIRForm_ flag (LIR requires src1 and dst to match in binary LIR ops) can be set at runtime but each platform defines a default value that is the only one accepted. Although some platform could theoretically support both, there is no realistic scenario for this.
> The flag is removed in favour of a constant. This is defined as enum and its assigned value is defined in the platform-specific def.

That looks good to me!

> That looks good to me but I think all these platform dependent constants should be converted to `static const` declarations at some point. From what I understand, enums are used here only [for historical reasons](https://stackoverflow.com/questions/899917/why-do-people-use-enums-in-c-as-constants-while-they-can-use-const). Could you file a follow-up RFE to investigate?

That's a good idea to clean this up as well at some point. But probably too much for this PR. So, I agree to file a separate RFE for it.

-------------

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11671

From duke at openjdk.org  Fri Dec 16 09:39:17 2022
From: duke at openjdk.org (Damon Fenacci)
Date: Fri, 16 Dec 2022 09:39:17 GMT
Subject: RFR: 8295661: CompileTask::compile_id() should be passed as int
Message-ID: <jI2RAttXag70ZVdNJerrImx6NmKgIF5fTJDShiWkn6U=.766cff6a-8af5-4eb1-a6be-861a4c15092a@github.com>

Changed return type of `CompileTask::compile_id()` from `int` to `uint`.
Also modified the type everywhere `compile_id` is used (parameters, local variables, string formatting, constant assignments) *as much as possible*.
Added *asserts* to check for valid value range where not possible.

-------------

Commit messages:
 - JDK-8295661 correct indentation and update copyright year
 - JDK-8295661 change type of _compile_id field from uint to int and fix all inconsistencies (make al compile IDs int)
 - Revert "JDK-8295661: CompileTask::compile_id() should return uint instead of int"
 - Revert "JDK-8295661 fix assert conditions"
 - Revert "JDK-8295661 fix indentation/white spaces"
 - Revert "JDK-8295661 revert wrong parameter name change"
 - Revert "JDK-8295661 update copyright date"
 - Revert "Update src/hotspot/share/c1/c1_Compilation.cpp"
 - Revert "JDK-8295661 review fixes"
 - JDK-8295661 review fixes
 - ... and 6 more: https://git.openjdk.org/jdk/compare/a37de62d...b9111ef5

Changes: https://git.openjdk.org/jdk/pull/11630/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11630&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295661
  Stats: 47 lines in 9 files changed: 0 ins; 2 del; 45 mod
  Patch: https://git.openjdk.org/jdk/pull/11630.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11630/head:pull/11630

PR: https://git.openjdk.org/jdk/pull/11630

From thartmann at openjdk.org  Fri Dec 16 09:39:18 2022
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 16 Dec 2022 09:39:18 GMT
Subject: RFR: 8295661: CompileTask::compile_id() should be passed as int
In-Reply-To: <jI2RAttXag70ZVdNJerrImx6NmKgIF5fTJDShiWkn6U=.766cff6a-8af5-4eb1-a6be-861a4c15092a@github.com>
References: <jI2RAttXag70ZVdNJerrImx6NmKgIF5fTJDShiWkn6U=.766cff6a-8af5-4eb1-a6be-861a4c15092a@github.com>
Message-ID: <pXt4dITny-kHdCvlClKLTBWT-tve10jaSu5Xm-TCpqQ=.55f6ba96-5fe0-49da-94fb-03e80383092e@github.com>

On Mon, 12 Dec 2022 11:29:55 GMT, Damon Fenacci <duke at openjdk.org> wrote:

> Changed return type of `CompileTask::compile_id()` from `int` to `uint`.
> Also modified the type everywhere `compile_id` is used (parameters, local variables, string formatting, constant assignments) *as much as possible*.
> Added *asserts* to check for valid value range where not possible.

Looks good, I added a few comments. Someone more familiar with JVMCI should have a look as well.

Marked as reviewed by thartmann (Reviewer).

Using unsigned int consistently feels appropriate to represent a compilation id, especially since we are already mixing unsigned and signed integers. But given the impact on JVMCI and the leakage into Java code which does not support an unsigned int, it's reasonable to use int consistently instead. The updated changes look good to me.

Thanks for making these changes. Looks good!

Thanks Tom. The intention of this change was mainly consistency, not avoiding a potential overflow.

src/hotspot/share/c1/c1_Compilation.cpp line 616:

> 614: Compilation::~Compilation() {
> 615:   // simulate crash during compilation
> 616:   assert(CICrashAt >= UINT_MAX || _env->compile_id() != CICrashAt, "just as planned");

I'm wondering if we should remove the `CICrashAt >= UINT_MAX` part to catch an UINT overflow before it can happen?

Suggestion:

  assert(_env->compile_id() != CICrashAt, "just as planned");

src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 1182:

> 1180: C2V_END
> 1181: 
> 1182: C2V_VMENTRY_0(juint, allocateCompileId, (JNIEnv* env, jobject, ARGUMENT_PAIR(method), int entry_bci))

This is called from Java code which does not have an unsigned int. I think we need to leave this as `jint` here.

src/hotspot/share/jvmci/jvmciEnv.cpp line 1625:

> 1623:   if (cb == (CodeBlob*) code) {
> 1624:     nmethod* nm = cb->as_nmethod_or_null();
> 1625:     assert(compile_id_snapshot >= 0, "negative compile id snapshot");

That's something to check with the JVMCI experts but I'm wondering why `compile_id_snapshot` is a jlong whereas the compile id is a jint.

src/hotspot/share/jvmci/jvmciRuntime.cpp line 2025:

> 2023:   assert(compile_state->task()->compile_id() <= INT_MAX, "compile id too big");
> 2024:   JVMCIObject result_object = JVMCIENV->call_HotSpotJVMCIRuntime_compileMethod(receiver, jvmci_method, entry_bci,
> 2025:                                                                      (jlong) compile_state, (int) compile_state->task()->compile_id());

Should be a cast to `jint`, right?

Suggestion:

                                                                     (jlong) compile_state, (jint) compile_state->task()->compile_id());

src/hotspot/share/opto/idealGraphPrinter.cpp line 231:

> 229: }
> 230: 
> 231: void IdealGraphPrinter::print_prop(const char *name, unsigned int val) {

Did you test these changes with IGV?

src/hotspot/share/runtime/sharedRuntime.cpp line 3106:

> 3104: 
> 3105:     const uint compile_id = CompileBroker::assign_compile_id(method, CompileBroker::standard_entry_bci);
> 3106: 

But `compile_id` could still be 0, right?

-------------

PR: https://git.openjdk.org/jdk/pull/11630Marked as reviewed by thartmann (Reviewer).

From duke at openjdk.org  Fri Dec 16 09:39:18 2022
From: duke at openjdk.org (Damon Fenacci)
Date: Fri, 16 Dec 2022 09:39:18 GMT
Subject: RFR: 8295661: CompileTask::compile_id() should be passed as int
In-Reply-To: <jI2RAttXag70ZVdNJerrImx6NmKgIF5fTJDShiWkn6U=.766cff6a-8af5-4eb1-a6be-861a4c15092a@github.com>
References: <jI2RAttXag70ZVdNJerrImx6NmKgIF5fTJDShiWkn6U=.766cff6a-8af5-4eb1-a6be-861a4c15092a@github.com>
Message-ID: <0JZT6zek7pAk2X2st0HlV57CZoJlpbYoYa5DelgzJ6w=.e920cc74-eeaf-4d22-94bb-a55e7070b6db@github.com>

On Mon, 12 Dec 2022 11:29:55 GMT, Damon Fenacci <duke at openjdk.org> wrote:

> Changed return type of `CompileTask::compile_id()` from `int` to `uint`.
> Also modified the type everywhere `compile_id` is used (parameters, local variables, string formatting, constant assignments) *as much as possible*.
> Added *asserts* to check for valid value range where not possible.

Thanks a lot for the review. I should have addressed all your comments.

-------------

PR: https://git.openjdk.org/jdk/pull/11630

From dnsimon at openjdk.org  Fri Dec 16 09:39:18 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 16 Dec 2022 09:39:18 GMT
Subject: RFR: 8295661: CompileTask::compile_id() should be passed as int
In-Reply-To: <jI2RAttXag70ZVdNJerrImx6NmKgIF5fTJDShiWkn6U=.766cff6a-8af5-4eb1-a6be-861a4c15092a@github.com>
References: <jI2RAttXag70ZVdNJerrImx6NmKgIF5fTJDShiWkn6U=.766cff6a-8af5-4eb1-a6be-861a4c15092a@github.com>
Message-ID: <Ln2AR_4VaT4MfpTSxsEN9xp1hZ7dImEuN1969WB1Lgo=.43096c11-1fa3-4c94-9ebb-4c6bc8484413@github.com>

On Mon, 12 Dec 2022 11:29:55 GMT, Damon Fenacci <duke at openjdk.org> wrote:

> Changed return type of `CompileTask::compile_id()` from `int` to `uint`.
> Also modified the type everywhere `compile_id` is used (parameters, local variables, string formatting, constant assignments) *as much as possible*.
> Added *asserts* to check for valid value range where not possible.

The JVMCI changes in this PR look correct. @tkrodriguez could also please look them over.

-------------

Marked as reviewed by dnsimon (Committer).

PR: https://git.openjdk.org/jdk/pull/11630

From never at openjdk.org  Fri Dec 16 09:39:18 2022
From: never at openjdk.org (Tom Rodriguez)
Date: Fri, 16 Dec 2022 09:39:18 GMT
Subject: RFR: 8295661: CompileTask::compile_id() should be passed as int
In-Reply-To: <jI2RAttXag70ZVdNJerrImx6NmKgIF5fTJDShiWkn6U=.766cff6a-8af5-4eb1-a6be-861a4c15092a@github.com>
References: <jI2RAttXag70ZVdNJerrImx6NmKgIF5fTJDShiWkn6U=.766cff6a-8af5-4eb1-a6be-861a4c15092a@github.com>
Message-ID: <a-3EO2kO_-U4S3wOfYMEiyzaaoy7hWmKmdTOdd4OGTo=.f8987b80-49c6-495a-9ea2-e34a44c99a7f@github.com>

On Mon, 12 Dec 2022 11:29:55 GMT, Damon Fenacci <duke at openjdk.org> wrote:

> Changed return type of `CompileTask::compile_id()` from `int` to `uint`.
> Also modified the type everywhere `compile_id` is used (parameters, local variables, string formatting, constant assignments) *as much as possible*.
> Added *asserts* to check for valid value range where not possible.

Marked as reviewed by never (Reviewer).

Why isn't the proper fix to simply change the `CompileTask::_compile_id` to an int?  Every other piece of code thinks it's an int so we should that declaration be controlling?  `CompileBroker::assign_compile_id` returns int which seems much more definitive to me.  Is there some known problem with running out of compile ids in the in signed range?

If this range is really being promoted to unsigned int then I think this needs to be properly exposed all the way through the JVMCI API with some new API to expose it as a long.  Simply adding asserts for something we believe can legally occur really isn't sufficient.

If we were really worried about overflow then I think it should be promoted to a jlong since the difference between the signed and unsigned range is really relatively small.  I think the required changes to JVMCI could be made in a backward compatible way where there is new API treats it as long.  The primary place where this is exposed is in `HotSpotCompilationRequest.getId`.  The old API could be made to throw an exception if it encounters a too large id.  Anyway if we want to address that issue I can probably provide the required JVMCI changes.

-------------

PR: https://git.openjdk.org/jdk/pull/11630

From duke at openjdk.org  Fri Dec 16 09:39:19 2022
From: duke at openjdk.org (Damon Fenacci)
Date: Fri, 16 Dec 2022 09:39:19 GMT
Subject: RFR: 8295661: CompileTask::compile_id() should be passed as int
In-Reply-To: <a-3EO2kO_-U4S3wOfYMEiyzaaoy7hWmKmdTOdd4OGTo=.f8987b80-49c6-495a-9ea2-e34a44c99a7f@github.com>
References: <jI2RAttXag70ZVdNJerrImx6NmKgIF5fTJDShiWkn6U=.766cff6a-8af5-4eb1-a6be-861a4c15092a@github.com>
 <a-3EO2kO_-U4S3wOfYMEiyzaaoy7hWmKmdTOdd4OGTo=.f8987b80-49c6-495a-9ea2-e34a44c99a7f@github.com>
Message-ID: <dxQZASQcaKkr4VW7fcVe_sKEfoRyUvd5kMLMFM9mr78=.496457e3-1d28-4ec5-9faf-e8f49c0eed07@github.com>

On Mon, 12 Dec 2022 18:50:40 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> Changed return type of `CompileTask::compile_id()` from `int` to `uint`.
>> Also modified the type everywhere `compile_id` is used (parameters, local variables, string formatting, constant assignments) *as much as possible*.
>> Added *asserts* to check for valid value range where not possible.
>
> Why isn't the proper fix to simply change the `CompileTask::_compile_id` to an int?  Every other piece of code thinks it's an int so we should that declaration be controlling?  `CompileBroker::assign_compile_id` returns int which seems much more definitive to me.  Is there some known problem with running out of compile ids in the in signed range?
> 
> If this range is really being promoted to unsigned int then I think this needs to be properly exposed all the way through the JVMCI API with some new API to expose it as a long.  Simply adding asserts for something we believe can legally occur really isn't sufficient.

@tkrodriguez thanks a lot for your insight. I see your point: the pragmatic approach you propose is surely more appropriate. Reverting the change.

@tkrodriguez @TobiHartmann @dougxc I've reverted the previous changes and changed `CompileTask::_compile_id` to an `int` instead. I've also changed the type of the compile id from `uint` to `int` in a few other places to make things consistent.

> If we were really worried about overflow then I think it should be promoted to a jlong since the difference between the signed and unsigned range is really relatively small.  I think the required changes to JVMCI could be made in a backward compatible way where there is new API treats it as long.  The primary place where this is exposed is in `HotSpotCompilationRequest.getId`.  The old API could be made to throw an exception if it encounters a too large id.  Anyway if we want to address that issue I can probably provide the required JVMCI changes.

Thanks @tkrodriguez @TobiHartmann @dougxc for the reviews!

-------------

PR: https://git.openjdk.org/jdk/pull/11630

From duke at openjdk.org  Fri Dec 16 09:39:19 2022
From: duke at openjdk.org (Damon Fenacci)
Date: Fri, 16 Dec 2022 09:39:19 GMT
Subject: RFR: 8295661: CompileTask::compile_id() should be passed as int
In-Reply-To: <pXt4dITny-kHdCvlClKLTBWT-tve10jaSu5Xm-TCpqQ=.55f6ba96-5fe0-49da-94fb-03e80383092e@github.com>
References: <jI2RAttXag70ZVdNJerrImx6NmKgIF5fTJDShiWkn6U=.766cff6a-8af5-4eb1-a6be-861a4c15092a@github.com>
 <pXt4dITny-kHdCvlClKLTBWT-tve10jaSu5Xm-TCpqQ=.55f6ba96-5fe0-49da-94fb-03e80383092e@github.com>
Message-ID: <nAawbDfXYgwHp6SrdwYErGUosVitfuB9RbBVFbfjVLM=.6f81e773-fe33-4c6b-8ac3-d6f5274facdb@github.com>

On Mon, 12 Dec 2022 12:12:09 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Changed return type of `CompileTask::compile_id()` from `int` to `uint`.
>> Also modified the type everywhere `compile_id` is used (parameters, local variables, string formatting, constant assignments) *as much as possible*.
>> Added *asserts* to check for valid value range where not possible.
>
> src/hotspot/share/c1/c1_Compilation.cpp line 616:
> 
>> 614: Compilation::~Compilation() {
>> 615:   // simulate crash during compilation
>> 616:   assert(CICrashAt >= UINT_MAX || _env->compile_id() != CICrashAt, "just as planned");
> 
> I'm wondering if we should remove the `CICrashAt >= UINT_MAX` part to catch an UINT overflow before it can happen?
> 
> Suggestion:
> 
>   assert(_env->compile_id() != CICrashAt, "just as planned");

OK

> src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 1182:
> 
>> 1180: C2V_END
>> 1181: 
>> 1182: C2V_VMENTRY_0(juint, allocateCompileId, (JNIEnv* env, jobject, ARGUMENT_PAIR(method), int entry_bci))
> 
> This is called from Java code which does not have an unsigned int. I think we need to leave this as `jint` here.

Reverted to `jint`. I also added an assert to check for big `uint` values.

> src/hotspot/share/jvmci/jvmciEnv.cpp line 1625:
> 
>> 1623:   if (cb == (CodeBlob*) code) {
>> 1624:     nmethod* nm = cb->as_nmethod_or_null();
>> 1625:     assert(compile_id_snapshot >= 0, "negative compile id snapshot");
> 
> That's something to check with the JVMCI experts but I'm wondering why `compile_id_snapshot` is a jlong whereas the compile id is a jint.

OK. Strange indeed!

> src/hotspot/share/jvmci/jvmciRuntime.cpp line 2025:
> 
>> 2023:   assert(compile_state->task()->compile_id() <= INT_MAX, "compile id too big");
>> 2024:   JVMCIObject result_object = JVMCIENV->call_HotSpotJVMCIRuntime_compileMethod(receiver, jvmci_method, entry_bci,
>> 2025:                                                                      (jlong) compile_state, (int) compile_state->task()->compile_id());
> 
> Should be a cast to `jint`, right?
> 
> Suggestion:
> 
>                                                                      (jlong) compile_state, (jint) compile_state->task()->compile_id());

I'm not sure. I just noticed that the signature of the called method has an `int` argument:

`JVMCIObject JVMCIEnv::call_HotSpotJVMCIRuntime_compileMethod (JVMCIObject runtime, JVMCIObject method, int entry_bci, jlong compile_state, int id)`

> src/hotspot/share/opto/idealGraphPrinter.cpp line 231:
> 
>> 229: }
>> 230: 
>> 231: void IdealGraphPrinter::print_prop(const char *name, unsigned int val) {
> 
> Did you test these changes with IGV?

I've ran `java -XX:PrintIdealGraphLevel=4 -Xcomp -XX:PrintIdealGraphFile=graph.xml` with some extra prints in the new and old `print_prop` methods (to check that they were actually used).

> src/hotspot/share/runtime/sharedRuntime.cpp line 3106:
> 
>> 3104: 
>> 3105:     const uint compile_id = CompileBroker::assign_compile_id(method, CompileBroker::standard_entry_bci);
>> 3106: 
> 
> But `compile_id` could still be 0, right?

Right! I've put the assert statement back.

-------------

PR: https://git.openjdk.org/jdk/pull/11630

From dnsimon at openjdk.org  Fri Dec 16 09:39:19 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 16 Dec 2022 09:39:19 GMT
Subject: RFR: 8295661: CompileTask::compile_id() should be passed as int
In-Reply-To: <nAawbDfXYgwHp6SrdwYErGUosVitfuB9RbBVFbfjVLM=.6f81e773-fe33-4c6b-8ac3-d6f5274facdb@github.com>
References: <jI2RAttXag70ZVdNJerrImx6NmKgIF5fTJDShiWkn6U=.766cff6a-8af5-4eb1-a6be-861a4c15092a@github.com>
 <pXt4dITny-kHdCvlClKLTBWT-tve10jaSu5Xm-TCpqQ=.55f6ba96-5fe0-49da-94fb-03e80383092e@github.com>
 <nAawbDfXYgwHp6SrdwYErGUosVitfuB9RbBVFbfjVLM=.6f81e773-fe33-4c6b-8ac3-d6f5274facdb@github.com>
Message-ID: <b15SkOfeDzm0hQo_e7Bru-bZGez4D8zEy6Rv9QCmTl4=.f6c849ec-3537-4bc8-b40b-3dad424da473@github.com>

On Mon, 12 Dec 2022 13:35:26 GMT, Damon Fenacci <duke at openjdk.org> wrote:

>> src/hotspot/share/jvmci/jvmciEnv.cpp line 1625:
>> 
>>> 1623:   if (cb == (CodeBlob*) code) {
>>> 1624:     nmethod* nm = cb->as_nmethod_or_null();
>>> 1625:     assert(compile_id_snapshot >= 0, "negative compile id snapshot");
>> 
>> That's something to check with the JVMCI experts but I'm wondering why `compile_id_snapshot` is a jlong whereas the compile id is a jint.
>
> OK. Strange indeed!

It's a good question and unfortunately I cannot recall the reason. Maybe @tkrodriguez can. In any case, I don't think it impacts this change.

-------------

PR: https://git.openjdk.org/jdk/pull/11630

From never at openjdk.org  Fri Dec 16 09:39:19 2022
From: never at openjdk.org (Tom Rodriguez)
Date: Fri, 16 Dec 2022 09:39:19 GMT
Subject: RFR: 8295661: CompileTask::compile_id() should be passed as int
In-Reply-To: <b15SkOfeDzm0hQo_e7Bru-bZGez4D8zEy6Rv9QCmTl4=.f6c849ec-3537-4bc8-b40b-3dad424da473@github.com>
References: <jI2RAttXag70ZVdNJerrImx6NmKgIF5fTJDShiWkn6U=.766cff6a-8af5-4eb1-a6be-861a4c15092a@github.com>
 <pXt4dITny-kHdCvlClKLTBWT-tve10jaSu5Xm-TCpqQ=.55f6ba96-5fe0-49da-94fb-03e80383092e@github.com>
 <nAawbDfXYgwHp6SrdwYErGUosVitfuB9RbBVFbfjVLM=.6f81e773-fe33-4c6b-8ac3-d6f5274facdb@github.com>
 <b15SkOfeDzm0hQo_e7Bru-bZGez4D8zEy6Rv9QCmTl4=.f6c849ec-3537-4bc8-b40b-3dad424da473@github.com>
Message-ID: <SHMa-XQvcSIrI6W63M3F2RwKuHv5gFjor_TjT7LZmLo=.f76bf49b-db2c-4807-b962-a96f2da05377@github.com>

On Mon, 12 Dec 2022 14:44:28 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> OK. Strange indeed!
>
> It's a good question and unfortunately I cannot recall the reason. Maybe @tkrodriguez can. In any case, I don't think it impacts this change.

That's far enough back that I don't really know why I used jlong.  Its type should really match the real compile id type whatever that is.  It's also fully internal to the JVMCI implementation so you can change it without affecting Graal.

-------------

PR: https://git.openjdk.org/jdk/pull/11630

From rkennke at openjdk.org  Fri Dec 16 10:00:12 2022
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 16 Dec 2022 10:00:12 GMT
Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v8]
In-Reply-To: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
References: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
Message-ID: <A1jiF7842FDOvtFII2actTqOpq43HB1mwzehPkMIp8Q=.20a92523-2ba3-4c8b-bbcc-83b6c4c5aaf5@github.com>

> See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details.
> 
> Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements.
> 
> Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16.
> 
> Testing:
>  - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390)
>  - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390)
>  - [x] tier1 (x86_64, x86_32, aarch64, riscv)
>  - [x] tier2 (x86_64, aarch64, riscv)
>  - [x] tier3 (x86_64, riscv)

Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:

 - Revert relaxation of array length
 - Add guards to ArrayBaseOffsets test to allow running with -UseCompressedClassPointers

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11044/files
  - new: https://git.openjdk.org/jdk/pull/11044/files/4ec977cf..8e5c9f9f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=06-07

  Stats: 17 lines in 5 files changed: 2 ins; 10 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/11044.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11044/head:pull/11044

PR: https://git.openjdk.org/jdk/pull/11044

From rkennke at openjdk.org  Fri Dec 16 11:30:31 2022
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 16 Dec 2022 11:30:31 GMT
Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v9]
In-Reply-To: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
References: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
Message-ID: <6JAHc7tZPU_0SixBnMBEA6YECtrkq9zWjs3W8LZaymk=.b71a46f5-b147-42a7-b334-9de5f53a0dde@github.com>

> See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details.
> 
> Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements.
> 
> Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16.
> 
> Testing:
>  - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390)
>  - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390)
>  - [x] tier1 (x86_64, x86_32, aarch64, riscv)
>  - [x] tier2 (x86_64, aarch64, riscv)
>  - [x] tier3 (x86_64, riscv)

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Fix cast warning

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11044/files
  - new: https://git.openjdk.org/jdk/pull/11044/files/8e5c9f9f..b12d99cc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=07-08

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11044.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11044/head:pull/11044

PR: https://git.openjdk.org/jdk/pull/11044

From lkorinth at openjdk.org  Fri Dec 16 12:47:48 2022
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 16 Dec 2022 12:47:48 GMT
Subject: RFR: 8292170: Convert CodeRootSetTable to use ResourceHashtable
 [v3]
In-Reply-To: <H-mQpvo2mM7d43WzuRGYoA0lSvAbRbvVUCxZHRYvU8w=.d2198ed3-1dcb-4965-a708-acc954bd9766@github.com>
References: <BdRsUwTHeM7gAUg1udRTeG-gv2S4slO0zYl5Ys21Pyw=.5701b960-0ecb-4c67-9d11-88d103b2bd0f@github.com>
 <H-mQpvo2mM7d43WzuRGYoA0lSvAbRbvVUCxZHRYvU8w=.d2198ed3-1dcb-4965-a708-acc954bd9766@github.com>
Message-ID: <aPvnq1BtYRj-oKknYXR7U1ruNFrWhltNhM9zF6pZafU=.2d3c280f-78d1-45a7-8540-4677d9ffac99@github.com>

On Thu, 15 Dec 2022 16:19:37 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> I am replacing the old hash table with ResourceHashtable. In the process I am also removing the redundant `_length` field. By removing the `_length` field, a lot of asserts can be removed as the length will trivially match the length of the underlying table.
>> 
>> I would like to have feedback on the addition of `unlink_destruct(Function&& should_remove)`. I added it because I prefer to use a functor object that can be used by lambdas instead of an iterator object. However, I did add code to "destruct" resource objects when they are removed instead of just letting them be to reflect that we use `delete` on c-heap objects. Maybe I should remove this "improvement" and then maybe implement the function by calling the existing unlink?
>
> Leo Korinth has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - remove specialized hash
>  - inline g1CodeRootSetTable.hpp
>  - remove unused template

Ivan has found a test error, and it looks like I have a bug.

-------------

PR: https://git.openjdk.org/jdk/pull/11675

From jwilhelm at openjdk.org  Fri Dec 16 13:33:14 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Fri, 16 Dec 2022 13:33:14 GMT
Subject: RFR: Merge jdk20
Message-ID: <YSHTcwXEKi0AYIOzrJy89CKa6GDNBwOXsUj0qcvrtz0=.249e0882-9bd1-49da-abcd-19e0a3d9ef5b@github.com>

Forwardport JDK 20 -> JDK 21

-------------

Commit messages:
 - Merge
 - 8298797: Specification of some restricted methods is incorrect
 - 8287699: jdk/jfr/api/consumer/TestRecordingFileWrite.java fails with exception: java.lang.Exception: Found event that should not be there.
 - 8297979: ZGC: Ensure consistent MemoryUsage from MemoryMXBean.getHeapMemoryUsage()
 - 8298083: The "CheckBox/RadioButton[Enabled/Disabled].textForeground" stoped working
 - 8298888: ProblemList gc/g1/TestVerifyGCType.java on linux and macosx
 - 7093322: (fs spec) Files.newBufferedWriter should be clear when coding errors are detected
 - 8298050: Add links to graph output for javadoc
 - 8298376: ZGC: thaws stackChunk with stale oops
 - 8298727: Trees.getPath may crash for unnamed package
 - ... and 1 more: https://git.openjdk.org/jdk/compare/ac2fcf3f...f069db65

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=11710&range=00.0
 - jdk20: https://webrevs.openjdk.org/?repo=jdk&pr=11710&range=00.1

Changes: https://git.openjdk.org/jdk/pull/11710/files
  Stats: 250 lines in 15 files changed: 180 ins; 52 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/11710.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11710/head:pull/11710

PR: https://git.openjdk.org/jdk/pull/11710

From jwaters at openjdk.org  Fri Dec 16 15:36:21 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 16 Dec 2022 15:36:21 GMT
Subject: RFR: 8250269: Replace ATTRIBUTE_ALIGNED with alignas [v4]
In-Reply-To: <9QKV9cYFTo_1D8R-mI80lnewNkA0ceJNKFPbrvICxl4=.d6736b76-8324-4084-bede-6e144b4f6c04@github.com>
References: <9QKV9cYFTo_1D8R-mI80lnewNkA0ceJNKFPbrvICxl4=.d6736b76-8324-4084-bede-6e144b4f6c04@github.com>
Message-ID: <lYE2qV_vCTU8UcdTpnBbM4p--gv7vYmPyGW2k-bsgxM=.448b34f3-30ba-429a-a634-69d26289985a@github.com>

> C++11 added the alignas attribute, for the purpose of specifying alignment on types, much like compiler specific syntax such as gcc's __attribute__((aligned(x))) or Visual C++'s __declspec(align(x)).
> 
> We can phase out the use of the macro in favor of the standard attribute. In the meantime, we can replace the toolchain specific definitions of ATTRIBUTE_ALIGNED with a portable definition. We might deprecate the use of the macro but changing its implementation quickly and cleanly applies the feature where the macro is being used.
> 
> Note: With certain parts of HotSpot using ATTRIBUTE_ALIGNED so indiscriminately, this commit will likely take some time to get right
> 
> This will require adding the alignas attribute to the list of language features approved for use in HotSpot code. (Ongoing at [8297912](https://github.com/openjdk/jdk/pull/11446))

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 three additional commits since the last revision:

 - Merge branch 'openjdk:master' into alignas
 - Merge branch 'openjdk:master' into alignas
 - alignas

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11431/files
  - new: https://git.openjdk.org/jdk/pull/11431/files/e617e5cb..1d69a46f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11431&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11431&range=02-03

  Stats: 70360 lines in 1214 files changed: 39489 ins; 23580 del; 7291 mod
  Patch: https://git.openjdk.org/jdk/pull/11431.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11431/head:pull/11431

PR: https://git.openjdk.org/jdk/pull/11431

From jwilhelm at openjdk.org  Fri Dec 16 15:52:00 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Fri, 16 Dec 2022 15:52:00 GMT
Subject: Integrated: Merge jdk20
In-Reply-To: <YSHTcwXEKi0AYIOzrJy89CKa6GDNBwOXsUj0qcvrtz0=.249e0882-9bd1-49da-abcd-19e0a3d9ef5b@github.com>
References: <YSHTcwXEKi0AYIOzrJy89CKa6GDNBwOXsUj0qcvrtz0=.249e0882-9bd1-49da-abcd-19e0a3d9ef5b@github.com>
Message-ID: <z_G2NJpaW0cmxQZFzSX6rOdwLniXiNqi1pJnO1i3px0=.5f7eff5b-3931-4541-b0b1-717d7e2eecd6@github.com>

On Fri, 16 Dec 2022 13:25:55 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 20 -> JDK 21

This pull request has now been integrated.

Changeset: 3696711e
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3696711efa566fb776d6923da86e17b0e1e22964
Stats:     250 lines in 15 files changed: 180 ins; 52 del; 18 mod

Merge

-------------

PR: https://git.openjdk.org/jdk/pull/11710

From sspitsyn at openjdk.org  Fri Dec 16 14:17:49 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 16 Dec 2022 14:17:49 GMT
Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling
 one virtual thread transitions
In-Reply-To: <avFztZhk1NDj_YekziZXXUKwiuGEWhFWabEsn010qmY=.07faf892-3bdb-4ea9-92a1-4763c77315a0@github.com>
References: <z8NCIbPeF0WzTEzXGyNxlnuOF_52vbV90p4B15xThFk=.b12cfe49-d27d-4e65-9027-796985005c14@github.com>
 <avFztZhk1NDj_YekziZXXUKwiuGEWhFWabEsn010qmY=.07faf892-3bdb-4ea9-92a1-4763c77315a0@github.com>
Message-ID: <qMgIdVTFTLxfv9yv-I3_XXlTd18VcycuFEkCVRQy4fk=.48f36b22-a8ff-438a-b517-18cd82441401@github.com>

On Fri, 16 Dec 2022 02:16:36 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Now the `JvmtiVTMSTransitionDisabler` mechanism supports disabling VTMS transitions for all virtual threads only. It should also support disabling transitions for any specific virtual thread as well. This will improve scalability of the JVMTI functions operating on target virtual threads as the functions can be executed concurrently without blocking each other execution when target virtual threads are different.
>> New constructor `JvmtiVTMSTransitionDisabler(jthread vthread)` is added which has jthread parameter of the target virtual thread.
>> 
>> Testing:
>>   mach5 jobs are TBD (preliminary testing was completed):
>>    - all JVMTI, JDWP, JDI and JDB tests have to be run
>>    - Kitchensink
>>    - tier5
>
> src/hotspot/share/prims/jvmtiThreadState.cpp line 304:
> 
>> 302: 
>> 303:   ThreadBlockInVM tbivm(thread);
>> 304:   MonitorLocker ml(JvmtiVTMSTransition_lock, Mutex::_no_safepoint_check_flag);
> 
> Aside: this pattern looks very odd. Why not just lock with the safepoint check?

@dholmes-ora
Thank you for looking at this fix and for the comments.
I will on replying and resolving them.

-------------

PR: https://git.openjdk.org/jdk/pull/11690

From duke at openjdk.org  Fri Dec 16 19:25:27 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Fri, 16 Dec 2022 19:25:27 GMT
Subject: [jdk20] RFR: 8298893: Rename option UsePolyIntrinsics to
 UsePoly1305Intrinsics
Message-ID: <7vlroOyHCMzL1r3QRgkC-lNo3I3bNUfVj_zvSpw8wd8=.1f2f1782-ed68-4044-ab69-f31833c78690@github.com>

Fix for better documentation. FYI @jnimeh

-------------

Commit messages:
 - fix for better documentation

Changes: https://git.openjdk.org/jdk20/pull/49/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=49&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298893
  Stats: 8 lines in 5 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk20/pull/49.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/49/head:pull/49

PR: https://git.openjdk.org/jdk20/pull/49

From jnimeh at openjdk.org  Fri Dec 16 19:25:27 2022
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Fri, 16 Dec 2022 19:25:27 GMT
Subject: [jdk20] RFR: 8298893: Rename option UsePolyIntrinsics to
 UsePoly1305Intrinsics
In-Reply-To: <7vlroOyHCMzL1r3QRgkC-lNo3I3bNUfVj_zvSpw8wd8=.1f2f1782-ed68-4044-ab69-f31833c78690@github.com>
References: <7vlroOyHCMzL1r3QRgkC-lNo3I3bNUfVj_zvSpw8wd8=.1f2f1782-ed68-4044-ab69-f31833c78690@github.com>
Message-ID: <AQYAYnn6uoaF6ggbXhiEp3y7rHYvqASWZ_lO1Ji9ILY=.3e4cd68a-060e-45b7-87b9-f99a547556bf@github.com>

On Fri, 16 Dec 2022 19:14:07 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

> Fix for better documentation. FYI @jnimeh

Thanks for making this change.  The changes look good to me.

When this is integrated I will take care of man page/doc changes for both our intrinsics.  Two other items of note:

- Please remember to update the release note with the modified name (JDK-8297970)
- You might need to modify this issue to be a P3 bug rather than P5 RFE in order for it to get backported into JDK 20, which we want it to be.

-------------

Marked as reviewed by jnimeh (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/49

From duke at openjdk.org  Fri Dec 16 19:29:52 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Fri, 16 Dec 2022 19:29:52 GMT
Subject: [jdk20] RFR: 8298893: Rename option UsePolyIntrinsics to
 UsePoly1305Intrinsics
In-Reply-To: <AQYAYnn6uoaF6ggbXhiEp3y7rHYvqASWZ_lO1Ji9ILY=.3e4cd68a-060e-45b7-87b9-f99a547556bf@github.com>
References: <7vlroOyHCMzL1r3QRgkC-lNo3I3bNUfVj_zvSpw8wd8=.1f2f1782-ed68-4044-ab69-f31833c78690@github.com>
 <AQYAYnn6uoaF6ggbXhiEp3y7rHYvqASWZ_lO1Ji9ILY=.3e4cd68a-060e-45b7-87b9-f99a547556bf@github.com>
Message-ID: <fs0YhbS-xViduo8vkfkDOOfRhRZzsUwcod2w5pv7GjU=.41baadcb-d59b-4af9-bf5a-f13c226e5da9@github.com>

On Fri, 16 Dec 2022 19:22:14 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> Fix for better documentation. FYI @jnimeh
>
> When this is integrated I will take care of man page/doc changes for both our intrinsics.  Two other items of note:
> 
> - Please remember to update the release note with the modified name (JDK-8297970)
> - You might need to modify this issue to be a P3 bug rather than P5 RFE in order for it to get backported into JDK 20, which we want it to be.

@jnimeh  
- Ah, I just noticed that @chhagedorn changed the issue overnight. Can change it back to P3 and against jdk20?
- yep, will change the release note, thanks for the reminder

-------------

PR: https://git.openjdk.org/jdk20/pull/49

From kvn at openjdk.org  Fri Dec 16 19:35:48 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 16 Dec 2022 19:35:48 GMT
Subject: [jdk20] RFR: 8298893: Rename option UsePolyIntrinsics to
 UsePoly1305Intrinsics
In-Reply-To: <7vlroOyHCMzL1r3QRgkC-lNo3I3bNUfVj_zvSpw8wd8=.1f2f1782-ed68-4044-ab69-f31833c78690@github.com>
References: <7vlroOyHCMzL1r3QRgkC-lNo3I3bNUfVj_zvSpw8wd8=.1f2f1782-ed68-4044-ab69-f31833c78690@github.com>
Message-ID: <xzLkgmG6qNJt7JyjNmeFx-XttFqemmqynDyrkPb5J_4=.a6586ba9-cfeb-4553-807c-ff97e41fb2b3@github.com>

On Fri, 16 Dec 2022 19:14:07 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

> Fix for better documentation. FYI @jnimeh

We are in RDP1 phase. Enhancement changes require approval by following process:
https://openjdk.org/jeps/3#Late-Enhancement-Request-Process

-------------

PR: https://git.openjdk.org/jdk20/pull/49

From jnimeh at openjdk.org  Fri Dec 16 19:35:48 2022
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Fri, 16 Dec 2022 19:35:48 GMT
Subject: [jdk20] RFR: 8298893: Rename option UsePolyIntrinsics to
 UsePoly1305Intrinsics
In-Reply-To: <7vlroOyHCMzL1r3QRgkC-lNo3I3bNUfVj_zvSpw8wd8=.1f2f1782-ed68-4044-ab69-f31833c78690@github.com>
References: <7vlroOyHCMzL1r3QRgkC-lNo3I3bNUfVj_zvSpw8wd8=.1f2f1782-ed68-4044-ab69-f31833c78690@github.com>
Message-ID: <raIZthrNccz9vQaZi3dIFLPE-ytnaqPjRay_VLf650s=.58210d65-3f2a-4a97-b37f-080f81b364fa@github.com>

On Fri, 16 Dec 2022 19:14:07 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

> Fix for better documentation. FYI @jnimeh

I would think you'd need to make a backport for JDK 20.  Perhaps there you can set the backport to Bug/P3.

-------------

PR: https://git.openjdk.org/jdk20/pull/49

From dcubed at openjdk.org  Fri Dec 16 19:52:50 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 16 Dec 2022 19:52:50 GMT
Subject: RFR: 8298128: runtime/ErrorHandling/TestSigInfoInHsErrFile.java
 fails to find pattern with slowdebug
In-Reply-To: <l_-0Uq121JKyIh09JDZ23uSYQPZbLwpg_8GOXRnEuKY=.1655ef89-b023-4653-bc05-e4318ce9399a@github.com>
References: <l_-0Uq121JKyIh09JDZ23uSYQPZbLwpg_8GOXRnEuKY=.1655ef89-b023-4653-bc05-e4318ce9399a@github.com>
Message-ID: <jRLcoru7lFue2upS4-fUpKjWuVNw5CA3_hGbp6uSK5A=.65dfbf76-2017-4f85-a8f5-5d3539c63283@github.com>

On Fri, 16 Dec 2022 07:56:39 GMT, Afshin Zafari <duke at openjdk.org> wrote:

> ### Description
> The following problems found and solved:
> 
> 1) Reporting which regex pattern did not match with error messages was incorrect. To report the mismatched pattern, the head of the pattern list was peeked, while it was the already peeked item from that did not match. So the next pattern to the mismatched one was reported.
> 
> 2) The pattern for finding a crash was incorrectly set to "# .*VMError::controlled_crash.*", while it has to be "# .*crash_with_segfault.*".
> 
> 3) `crash_with_segfault` function is too small and was `inline`d in compiler optimisations. So it was not in the stack trace when the error message is created.
> 
> ### Patch
> 1 and 2 corrected and added the `NOINLINE` to  the `crash_with_segfault` signature. The same applied for `crash_with_sigfpe` function.
> 
> ### Test
> runtime/ErrorHandling/* and tier1-5

Thumbs up. Thanks for the careful analysis and including
your testing information.

I've only posted nit comments about typos.

test/hotspot/jtreg/runtime/ErrorHandling/HsErrFileUtils.java line 138:

> 136:                     throw new RuntimeException("hs-err file incomplete (first missing pattern: " + currentPositivePattern.pattern() + ")");
> 137:                 } else {
> 138:                     // Impossible to reach here, where stack is not empty and currentPositivePattern which peeked from stack is null.

nit typo: s/which peeked/which was peeked/

test/hotspot/jtreg/runtime/ErrorHandling/HsErrFileUtils.java line 139:

> 137:                 } else {
> 138:                     // Impossible to reach here, where stack is not empty and currentPositivePattern which peeked from stack is null.
> 139:                     // Beacuse, peek from stack returns null only when it is empty or has a null item.

nit typo: s/Beacuse/Because/

test/hotspot/jtreg/runtime/ErrorHandling/TestSigInfoInHsErrFile.java line 69:

> 67:     patterns.add(Pattern.compile("# *Problematic frame.*"));
> 68:     patterns.add(Pattern.compile("# .*crash_with_segfault.*"));
> 69: 

Please delete the extra blank line.

-------------

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11704

From duke at openjdk.org  Fri Dec 16 20:00:50 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Fri, 16 Dec 2022 20:00:50 GMT
Subject: [jdk20] RFR: 8298893: Rename option UsePolyIntrinsics to
 UsePoly1305Intrinsics
In-Reply-To: <7vlroOyHCMzL1r3QRgkC-lNo3I3bNUfVj_zvSpw8wd8=.1f2f1782-ed68-4044-ab69-f31833c78690@github.com>
References: <7vlroOyHCMzL1r3QRgkC-lNo3I3bNUfVj_zvSpw8wd8=.1f2f1782-ed68-4044-ab69-f31833c78690@github.com>
Message-ID: <SAqihQu478ZaPYX7lQQDBJFPYHbJXei476bD4-tK-vQ=.c41b2f0b-1145-4429-bd85-891c23f1fa0f@github.com>

On Fri, 16 Dec 2022 19:14:07 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

> Fix for better documentation. FYI @jnimeh

I think there is some confusion.. I had originally opened a "bug" against jdk20 (per a discussion with Jamil). Last night the issue got switched to a P5 enhancement against dev.

So as to not add to the confusion, not going to touch the issue or the PR until someone tells me otherwise? @jnimeh @vnkozlov @chhagedorn  ?

-------------

PR: https://git.openjdk.org/jdk20/pull/49

From kvn at openjdk.org  Fri Dec 16 20:25:49 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 16 Dec 2022 20:25:49 GMT
Subject: [jdk20] RFR: 8298893: Rename option UsePolyIntrinsics to
 UsePoly1305Intrinsics
In-Reply-To: <SAqihQu478ZaPYX7lQQDBJFPYHbJXei476bD4-tK-vQ=.c41b2f0b-1145-4429-bd85-891c23f1fa0f@github.com>
References: <7vlroOyHCMzL1r3QRgkC-lNo3I3bNUfVj_zvSpw8wd8=.1f2f1782-ed68-4044-ab69-f31833c78690@github.com>
 <SAqihQu478ZaPYX7lQQDBJFPYHbJXei476bD4-tK-vQ=.c41b2f0b-1145-4429-bd85-891c23f1fa0f@github.com>
Message-ID: <1NZIzResTCJJvznrzw5TPa_1WBBvqDLzjMmnHDCq1KY=.1f59068e-6da0-42df-90f3-3bbcba40cbe0@github.com>

On Fri, 16 Dec 2022 19:58:07 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> Fix for better documentation. FYI @jnimeh
>
> I think there is some confusion.. I had originally opened a "bug" against jdk20 (per a discussion with Jamil). Last night the issue got switched to a P5 enhancement against dev.
> 
> So as to not add to the confusion, not going to touch the issue or the PR until someone tells me otherwise? @jnimeh @vnkozlov @chhagedorn  ?

@vpaprotsk 
Such renaming is enhancement. But these changes are simple and will be approved for JDK 20.
It is easy to follow process I pointed: add label and comment to [JDK-8298893](https://bugs.openjdk.org/browse/JDK-8298893). And wait approval.
Note, for documentation changes you don't need approval during RDP1.

-------------

PR: https://git.openjdk.org/jdk20/pull/49

From duke at openjdk.org  Fri Dec 16 20:45:50 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Fri, 16 Dec 2022 20:45:50 GMT
Subject: [jdk20] RFR: 8298893: Rename option UsePolyIntrinsics to
 UsePoly1305Intrinsics
In-Reply-To: <7vlroOyHCMzL1r3QRgkC-lNo3I3bNUfVj_zvSpw8wd8=.1f2f1782-ed68-4044-ab69-f31833c78690@github.com>
References: <7vlroOyHCMzL1r3QRgkC-lNo3I3bNUfVj_zvSpw8wd8=.1f2f1782-ed68-4044-ab69-f31833c78690@github.com>
Message-ID: <iPD1vExIY115H4L7lCX1XmfVz5VgOBNH-8b8ROaeYnA=.03937239-270e-4e34-9499-7be74637dfb7@github.com>

On Fri, 16 Dec 2022 19:14:07 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

> Fix for better documentation. FYI @jnimeh

Added a comment and labels to the JBS issue. I think thats it, but let me know what else I've missed or what else need fixin'

-------------

PR: https://git.openjdk.org/jdk20/pull/49

From kvn at openjdk.org  Fri Dec 16 20:55:47 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 16 Dec 2022 20:55:47 GMT
Subject: [jdk20] RFR: 8298893: Rename option UsePolyIntrinsics to
 UsePoly1305Intrinsics
In-Reply-To: <iPD1vExIY115H4L7lCX1XmfVz5VgOBNH-8b8ROaeYnA=.03937239-270e-4e34-9499-7be74637dfb7@github.com>
References: <7vlroOyHCMzL1r3QRgkC-lNo3I3bNUfVj_zvSpw8wd8=.1f2f1782-ed68-4044-ab69-f31833c78690@github.com>
 <iPD1vExIY115H4L7lCX1XmfVz5VgOBNH-8b8ROaeYnA=.03937239-270e-4e34-9499-7be74637dfb7@github.com>
Message-ID: <E_U__lR25qTjHHb7aYRdeIWHV3xbOX3sDiEoe7ExT1s=.87c588aa-b1fd-4306-a6f8-8abfe8972e14@github.com>

On Fri, 16 Dec 2022 20:43:31 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

> Added a comment and labels to the JBS issue. I think thats it, but let me know what else I've missed or what else need fixin'

Good. We have to wait when Mark approve it or delegate.

-------------

PR: https://git.openjdk.org/jdk20/pull/49

From sviswanathan at openjdk.org  Fri Dec 16 21:43:56 2022
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 16 Dec 2022 21:43:56 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v13]
In-Reply-To: <pW8HHmh-dQnjrRftd052fBQVulqe_z5KldY76Hp-OmI=.a7a2b6e6-a182-45d2-bd11-16a406126482@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <pW8HHmh-dQnjrRftd052fBQVulqe_z5KldY76Hp-OmI=.a7a2b6e6-a182-45d2-bd11-16a406126482@github.com>
Message-ID: <35kCBSJh0N-kNpJyUDG7jr7p0aejbNDnVbZw6XdxZlM=.f0c1314e-707d-407f-b7bf-ea016d6800f1@github.com>

On Fri, 11 Nov 2022 13:00:06 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops.
>> 
>> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases.
>> 
>> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front.
>> 
>> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads.
>> 
>> With the most recent fixes the x64 intrinsic results on my workstation look like this:
>> 
>> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.199 ?  0.017  ns/op
>> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     6.933 ?  0.049  ns/op
>> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    29.935 ?  0.221  ns/op
>> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  1596.982 ?  7.020  ns/op
>> 
>> Baseline:
>> 
>> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.200 ?  0.013  ns/op
>> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     9.424 ?  0.122  ns/op
>> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    90.541 ?  0.512  ns/op
>> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  9425.321 ? 67.630  ns/op
>> 
>> I.e. no measurable overhead compared to baseline even for `size == 1`.
>> 
>> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good.
>> 
>> Benchmark for `Arrays.hashCode`:
>> 
>> Benchmark              (size)  Mode  Cnt     Score    Error  Units
>> ArraysHashCode.bytes        1  avgt    5     1.884 ?  0.013  ns/op
>> ArraysHashCode.bytes       10  avgt    5     6.955 ?  0.040  ns/op
>> ArraysHashCode.bytes      100  avgt    5    87.218 ?  0.595  ns/op
>> ArraysHashCode.bytes    10000  avgt    5  9419.591 ? 38.308  ns/op
>> ArraysHashCode.chars        1  avgt    5     2.200 ?  0.010  ns/op
>> ArraysHashCode.chars       10  avgt    5     6.935 ?  0.034  ns/op
>> ArraysHashCode.chars      100  avgt    5    30.216 ?  0.134  ns/op
>> ArraysHashCode.chars    10000  avgt    5  1601.629 ?  6.418  ns/op
>> ArraysHashCode.ints         1  avgt    5     2.200 ?  0.007  ns/op
>> ArraysHashCode.ints        10  avgt    5     6.936 ?  0.034  ns/op
>> ArraysHashCode.ints       100  avgt    5    29.412 ?  0.268  ns/op
>> ArraysHashCode.ints     10000  avgt    5  1610.578 ?  7.785  ns/op
>> ArraysHashCode.shorts       1  avgt    5     1.885 ?  0.012  ns/op
>> ArraysHashCode.shorts      10  avgt    5     6.961 ?  0.034  ns/op
>> ArraysHashCode.shorts     100  avgt    5    87.095 ?  0.417  ns/op
>> ArraysHashCode.shorts   10000  avgt    5  9420.617 ? 50.089  ns/op
>> 
>> Baseline:
>> 
>> Benchmark              (size)  Mode  Cnt     Score    Error  Units
>> ArraysHashCode.bytes        1  avgt    5     3.213 ?  0.207  ns/op
>> ArraysHashCode.bytes       10  avgt    5     8.483 ?  0.040  ns/op
>> ArraysHashCode.bytes      100  avgt    5    90.315 ?  0.655  ns/op
>> ArraysHashCode.bytes    10000  avgt    5  9422.094 ? 62.402  ns/op
>> ArraysHashCode.chars        1  avgt    5     3.040 ?  0.066  ns/op
>> ArraysHashCode.chars       10  avgt    5     8.497 ?  0.074  ns/op
>> ArraysHashCode.chars      100  avgt    5    90.074 ?  0.387  ns/op
>> ArraysHashCode.chars    10000  avgt    5  9420.474 ? 41.619  ns/op
>> ArraysHashCode.ints         1  avgt    5     2.827 ?  0.019  ns/op
>> ArraysHashCode.ints        10  avgt    5     7.727 ?  0.043  ns/op
>> ArraysHashCode.ints       100  avgt    5    89.405 ?  0.593  ns/op
>> ArraysHashCode.ints     10000  avgt    5  9426.539 ? 51.308  ns/op
>> ArraysHashCode.shorts       1  avgt    5     3.071 ?  0.062  ns/op
>> ArraysHashCode.shorts      10  avgt    5     8.168 ?  0.049  ns/op
>> ArraysHashCode.shorts     100  avgt    5    90.399 ?  0.292  ns/op
>> ArraysHashCode.shorts   10000  avgt    5  9420.171 ? 44.474  ns/op
>> 
>> 
>> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missing & 0xff in StringLatin1::hashCode

src/java.base/share/classes/java/lang/StringUTF16.java line 418:

> 416:             return 0;
> 417:         } else {
> 418:             return ArraysSupport.vectorizedHashCode(value, ArraysSupport.UTF16);

Special case for 1 missing here.

-------------

PR: https://git.openjdk.org/jdk/pull/10847

From sviswanathan at openjdk.org  Fri Dec 16 23:29:55 2022
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 16 Dec 2022 23:29:55 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v13]
In-Reply-To: <pW8HHmh-dQnjrRftd052fBQVulqe_z5KldY76Hp-OmI=.a7a2b6e6-a182-45d2-bd11-16a406126482@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <pW8HHmh-dQnjrRftd052fBQVulqe_z5KldY76Hp-OmI=.a7a2b6e6-a182-45d2-bd11-16a406126482@github.com>
Message-ID: <_2HYrbXOe6zVuLXHywoy_AjCcGMYR266BcwKUZEA5fs=.1e6f7640-7580-4ff3-ace6-f18f27efbb23@github.com>

On Fri, 11 Nov 2022 13:00:06 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops.
>> 
>> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases.
>> 
>> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front.
>> 
>> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads.
>> 
>> With the most recent fixes the x64 intrinsic results on my workstation look like this:
>> 
>> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.199 ?  0.017  ns/op
>> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     6.933 ?  0.049  ns/op
>> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    29.935 ?  0.221  ns/op
>> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  1596.982 ?  7.020  ns/op
>> 
>> Baseline:
>> 
>> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.200 ?  0.013  ns/op
>> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     9.424 ?  0.122  ns/op
>> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    90.541 ?  0.512  ns/op
>> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  9425.321 ? 67.630  ns/op
>> 
>> I.e. no measurable overhead compared to baseline even for `size == 1`.
>> 
>> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good.
>> 
>> Benchmark for `Arrays.hashCode`:
>> 
>> Benchmark              (size)  Mode  Cnt     Score    Error  Units
>> ArraysHashCode.bytes        1  avgt    5     1.884 ?  0.013  ns/op
>> ArraysHashCode.bytes       10  avgt    5     6.955 ?  0.040  ns/op
>> ArraysHashCode.bytes      100  avgt    5    87.218 ?  0.595  ns/op
>> ArraysHashCode.bytes    10000  avgt    5  9419.591 ? 38.308  ns/op
>> ArraysHashCode.chars        1  avgt    5     2.200 ?  0.010  ns/op
>> ArraysHashCode.chars       10  avgt    5     6.935 ?  0.034  ns/op
>> ArraysHashCode.chars      100  avgt    5    30.216 ?  0.134  ns/op
>> ArraysHashCode.chars    10000  avgt    5  1601.629 ?  6.418  ns/op
>> ArraysHashCode.ints         1  avgt    5     2.200 ?  0.007  ns/op
>> ArraysHashCode.ints        10  avgt    5     6.936 ?  0.034  ns/op
>> ArraysHashCode.ints       100  avgt    5    29.412 ?  0.268  ns/op
>> ArraysHashCode.ints     10000  avgt    5  1610.578 ?  7.785  ns/op
>> ArraysHashCode.shorts       1  avgt    5     1.885 ?  0.012  ns/op
>> ArraysHashCode.shorts      10  avgt    5     6.961 ?  0.034  ns/op
>> ArraysHashCode.shorts     100  avgt    5    87.095 ?  0.417  ns/op
>> ArraysHashCode.shorts   10000  avgt    5  9420.617 ? 50.089  ns/op
>> 
>> Baseline:
>> 
>> Benchmark              (size)  Mode  Cnt     Score    Error  Units
>> ArraysHashCode.bytes        1  avgt    5     3.213 ?  0.207  ns/op
>> ArraysHashCode.bytes       10  avgt    5     8.483 ?  0.040  ns/op
>> ArraysHashCode.bytes      100  avgt    5    90.315 ?  0.655  ns/op
>> ArraysHashCode.bytes    10000  avgt    5  9422.094 ? 62.402  ns/op
>> ArraysHashCode.chars        1  avgt    5     3.040 ?  0.066  ns/op
>> ArraysHashCode.chars       10  avgt    5     8.497 ?  0.074  ns/op
>> ArraysHashCode.chars      100  avgt    5    90.074 ?  0.387  ns/op
>> ArraysHashCode.chars    10000  avgt    5  9420.474 ? 41.619  ns/op
>> ArraysHashCode.ints         1  avgt    5     2.827 ?  0.019  ns/op
>> ArraysHashCode.ints        10  avgt    5     7.727 ?  0.043  ns/op
>> ArraysHashCode.ints       100  avgt    5    89.405 ?  0.593  ns/op
>> ArraysHashCode.ints     10000  avgt    5  9426.539 ? 51.308  ns/op
>> ArraysHashCode.shorts       1  avgt    5     3.071 ?  0.062  ns/op
>> ArraysHashCode.shorts      10  avgt    5     8.168 ?  0.049  ns/op
>> ArraysHashCode.shorts     100  avgt    5    90.399 ?  0.292  ns/op
>> ArraysHashCode.shorts   10000  avgt    5  9420.171 ? 44.474  ns/op
>> 
>> 
>> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missing & 0xff in StringLatin1::hashCode

src/hotspot/cpu/x86/stubRoutines_x86.cpp line 230:

> 228: #endif // _LP64
> 229: 
> 230: jint StubRoutines::x86::_arrays_hashcode_powers_of_31[] =

This should be declared only for LP64.

src/hotspot/cpu/x86/vm_version_x86.cpp line 1671:

> 1669:   }
> 1670:   if (UseAVX >= 2) {
> 1671:     FLAG_SET_ERGO_IF_DEFAULT(UseVectorizedHashCodeIntrinsic, true);

This could be just FLAG_SET_DEFAULT instead of FLAG_SET_ERGO_IF_DEFAULT.

-------------

PR: https://git.openjdk.org/jdk/pull/10847

From sviswanathan at openjdk.org  Fri Dec 16 23:29:57 2022
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 16 Dec 2022 23:29:57 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v13]
In-Reply-To: <qxFxCcOGasCUw3NBap82yIuqJi-D3p1JY7MSDjejtEU=.5ac1a504-d754-4d2b-95d3-68384834f721@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <pW8HHmh-dQnjrRftd052fBQVulqe_z5KldY76Hp-OmI=.a7a2b6e6-a182-45d2-bd11-16a406126482@github.com>
 <IEqn-D6Umb4bhYeCvw6d-riT_R7Y6aag-wdMKDHfxSM=.22808600-b52d-49ea-9a39-9f5b27fe2f24@github.com>
 <qxFxCcOGasCUw3NBap82yIuqJi-D3p1JY7MSDjejtEU=.5ac1a504-d754-4d2b-95d3-68384834f721@github.com>
Message-ID: <NxYrMWFSWyOSFsg_bt1A0Umhr-JWFMVsJMDQk7sYYb4=.d49e8812-1203-4847-9229-4cf337e49f00@github.com>

On Sun, 13 Nov 2022 20:57:44 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> src/hotspot/cpu/x86/x86_64.ad line 12073:
>> 
>>> 12071:                          legRegD tmp_vec13, rRegI tmp1, rRegI tmp2, rRegI tmp3, rFlagsReg cr)
>>> 12072: %{
>>> 12073:   predicate(UseAVX >= 2 && ((VectorizedHashCodeNode*)n)->mode() == VectorizedHashCodeNode::LATIN1);
>> 
>> If you represent `VectorizedHashCodeNode::mode()` as an input, it would allow to abstract over supported modes and come up with a single AD instruction. Take a look at `VectorMaskCmp` for an example (not a perfect one though since it has both _predicate member and constant input which is redundant).
>
> Thanks for the pointer, I'll check it out!

I agree with Vladimir, adding mode as another input will help. Please take a look at the RoundDoubleModeNode.

-------------

PR: https://git.openjdk.org/jdk/pull/10847

From duke at openjdk.org  Sat Dec 17 06:07:56 2022
From: duke at openjdk.org (duke)
Date: Sat, 17 Dec 2022 06:07:56 GMT
Subject: Withdrawn: 8294954: Remove superfluous ResourceMarks when using
 LogStream
In-Reply-To: <yX03ZPbDND-IFGLRSMh-KxneV7SeCodySNeUXdbyI_k=.daa676ea-2057-45b0-9107-73894fd69b09@github.com>
References: <yX03ZPbDND-IFGLRSMh-KxneV7SeCodySNeUXdbyI_k=.daa676ea-2057-45b0-9107-73894fd69b09@github.com>
Message-ID: <YNc5XIcMUPrKXsj3rADvSvKZjmAOrm2iQD3AH_GKewc=.52e9d52b-e586-48b7-9a71-50950b6c3a62@github.com>

On Fri, 7 Oct 2022 11:19:55 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> I went through all of the places where LogStreams are created and removed the unnecessary ResourceMarks. I also added a ResourceMark in one place, where it was needed because of a call to `::name_and_sig_as_C_string` and moved one to the smallest scope where it is used.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/10602

From duke at openjdk.org  Sat Dec 17 10:25:40 2022
From: duke at openjdk.org (Afshin Zafari)
Date: Sat, 17 Dec 2022 10:25:40 GMT
Subject: RFR: 8298128: runtime/ErrorHandling/TestSigInfoInHsErrFile.java
 fails to find pattern with slowdebug [v2]
In-Reply-To: <l_-0Uq121JKyIh09JDZ23uSYQPZbLwpg_8GOXRnEuKY=.1655ef89-b023-4653-bc05-e4318ce9399a@github.com>
References: <l_-0Uq121JKyIh09JDZ23uSYQPZbLwpg_8GOXRnEuKY=.1655ef89-b023-4653-bc05-e4318ce9399a@github.com>
Message-ID: <PaM4mf-9mOl1Q52LATxFWRkh5SqkMeo2ltFeYdw_5NM=.2695f1ea-6744-44d4-b851-cca5db9e60ae@github.com>

> ### Description
> The following problems found and solved:
> 
> 1) Reporting which regex pattern did not match with error messages was incorrect. To report the mismatched pattern, the head of the pattern list was peeked, while it was the already peeked item from that did not match. So the next pattern to the mismatched one was reported.
> 
> 2) The pattern for finding a crash was incorrectly set to "# .*VMError::controlled_crash.*", while it has to be "# .*crash_with_segfault.*".
> 
> 3) `crash_with_segfault` function is too small and was `inline`d in compiler optimisations. So it was not in the stack trace when the error message is created.
> 
> ### Patch
> 1 and 2 corrected and added the `NOINLINE` to  the `crash_with_segfault` signature. The same applied for `crash_with_sigfpe` function.
> 
> ### Test
> runtime/ErrorHandling/* and tier1-5

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  8298128: runtime/ErrorHandling/TestSigInfoInHsErrFile.java fails to find pattern with slowdebug

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11704/files
  - new: https://git.openjdk.org/jdk/pull/11704/files/0fc85607..04a11f6b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11704&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11704&range=00-01

  Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11704.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11704/head:pull/11704

PR: https://git.openjdk.org/jdk/pull/11704

From dcubed at openjdk.org  Sat Dec 17 13:58:47 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Sat, 17 Dec 2022 13:58:47 GMT
Subject: RFR: 8298128: runtime/ErrorHandling/TestSigInfoInHsErrFile.java
 fails to find pattern with slowdebug [v2]
In-Reply-To: <PaM4mf-9mOl1Q52LATxFWRkh5SqkMeo2ltFeYdw_5NM=.2695f1ea-6744-44d4-b851-cca5db9e60ae@github.com>
References: <l_-0Uq121JKyIh09JDZ23uSYQPZbLwpg_8GOXRnEuKY=.1655ef89-b023-4653-bc05-e4318ce9399a@github.com>
 <PaM4mf-9mOl1Q52LATxFWRkh5SqkMeo2ltFeYdw_5NM=.2695f1ea-6744-44d4-b851-cca5db9e60ae@github.com>
Message-ID: <Ok7-s4595a3X2JEmXbLDCIShoWRpAH_p_5A_ucNp_s8=.2ebc2002-a82e-411d-a858-2bfc6ca45822@github.com>

On Sat, 17 Dec 2022 10:25:40 GMT, Afshin Zafari <duke at openjdk.org> wrote:

>> ### Description
>> The following problems found and solved:
>> 
>> 1) Reporting which regex pattern did not match with error messages was incorrect. To report the mismatched pattern, the head of the pattern list was peeked, while it was the already peeked item from that did not match. So the next pattern to the mismatched one was reported.
>> 
>> 2) The pattern for finding a crash was incorrectly set to "# .*VMError::controlled_crash.*", while it has to be "# .*crash_with_segfault.*".
>> 
>> 3) `crash_with_segfault` function is too small and was `inline`d in compiler optimisations. So it was not in the stack trace when the error message is created.
>> 
>> ### Patch
>> 1 and 2 corrected and added the `NOINLINE` to  the `crash_with_segfault` signature. The same applied for `crash_with_sigfpe` function.
>> 
>> ### Test
>> runtime/ErrorHandling/* and tier1-5
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8298128: runtime/ErrorHandling/TestSigInfoInHsErrFile.java fails to find pattern with slowdebug

Still thumbs up

-------------

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11704

From dcubed at openjdk.org  Sat Dec 17 14:46:56 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Sat, 17 Dec 2022 14:46:56 GMT
Subject: RFR: 8297235: ZGC: assert(regs[i] != regs[j]) failed: Multiple
 uses of register: rax [v3]
In-Reply-To: <0fGmbCvEUHokqoFR0ndPwd7yA5I_SS-MlBneCPP3LqY=.c4b67306-e5bb-4af5-8875-adba9ea9d0f1@github.com>
References: <jYsSVWwRPyRKvs8HYIwp6Ar5Z0XISOwp1DM4A0AgdOQ=.378c74fb-a4e1-45a5-82b0-838c2fcba43a@github.com>
 <0fGmbCvEUHokqoFR0ndPwd7yA5I_SS-MlBneCPP3LqY=.c4b67306-e5bb-4af5-8875-adba9ea9d0f1@github.com>
Message-ID: <ZM1yIeT0ivSOKMz55eIILL_cOvOPFDUe47JexGTohoI=.e60dbef3-73f0-4ed0-8333-837d8cb6fc87@github.com>

On Thu, 8 Dec 2022 09:01:08 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Tests java/util/stream/test/org/openjdk/tests/java/util/* with -XX:+UseZGC -Xcomp -XX:-TieredCompilation crashes with `assert(regs[i] != regs[j]) failed: Multiple uses of register: rax`. More specifically compilation of java.util.concurrent.ForkJoinTask::awaitDone.
>> 
>> The reason seems to be that the compare value and the memory input ends up sharing a register. (Uses Unsafe CAS which CAS an object reference into a field of that object, `oldval: rax` and `mem: [rax+offset]`). The Z load barrier stub dispatch implementation require that the reference and reference address occupy distinct registers. In the loadP nodes this is established by marking all but the memory TEMP which results in no sharing.
>> 
>> This is not possible for the CompareAndSwapP / CompareAndExchangeP nodes as the compare value is an input node. 
>> 
>> The solution proposed here is less than ideal as it makes the CAS nodes require one extra TEMP register, which in the common case is unused. This puts unnecessary extra strain on the register allocation. The problem is that there is no way currently (that I can find) to express in .ad that a memory input must not share registers with a specific other input. 
>> 
>> There is an alternative solution for this specific crash which does not use a second TEMP register (see commit: cfd5ced4e97e986fc10c5a8721b543cd3101c58a). It accomplish this by using the same trick that the aarch64 Z CAS node uses which is to specify the memory as indirect which results in the address being LEA into a register. However from what I can see this does not guarantee that the address and the reference does not share a register (`oldval: rax` and `mem: [rax]`). So it is theoretically broken, (and so is the aarch64 implementation). 
>> 
>> It is unclear to me if there is ever a way for C2 to generation a CAS which compares the address of the field with its content. 
>> 
>> I call on anyone with more knowledge about `adlc` and `C2` for feedback. And specifically I want to open up a discussion with these points:
>> * Is there some other way of expressing in the .ad file that a memory input should not share some register?
>>   * If not, is this a worthwhile RFE? As it seems to be a patterned used at least in other places in Z.
>> * Will the indirect input ever share a register with oldval and/or are the aarch64/riscv implementations broken because of this? How about ppc?
>> 
>> Testing: linux-x64 zgc tagged tests tier 1-7 and some specific crashing tests with `-XX:+UseZGC -Xcomp -XX:-TieredCompilation` (in: java/util/stream/, java/util/concurrent/)
>
> Axel Boldt-Christmas 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 commits since the last revision:
> 
>  - Remove problem listed tests
>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8297235
>  - indirect zXChgP as well
>  - indirect alternative
>  - JDK-8297235: ZGC: assert(regs[i] != regs[j]) failed: Multiple uses of register: rax

This PR removed all entries from test/jdk/ProblemList-zgc.txt including this entry:

jdk/internal/vm/Continuation/Fuzz.java#default 8298058 generic-x64

which has nothing to do with this bug fix. I'll restore that entry with a new bug shortly.

-------------

PR: https://git.openjdk.org/jdk/pull/11410

From dholmes at openjdk.org  Sat Dec 17 22:17:52 2022
From: dholmes at openjdk.org (David Holmes)
Date: Sat, 17 Dec 2022 22:17:52 GMT
Subject: RFR: 8298128: runtime/ErrorHandling/TestSigInfoInHsErrFile.java
 fails to find pattern with slowdebug [v2]
In-Reply-To: <PaM4mf-9mOl1Q52LATxFWRkh5SqkMeo2ltFeYdw_5NM=.2695f1ea-6744-44d4-b851-cca5db9e60ae@github.com>
References: <l_-0Uq121JKyIh09JDZ23uSYQPZbLwpg_8GOXRnEuKY=.1655ef89-b023-4653-bc05-e4318ce9399a@github.com>
 <PaM4mf-9mOl1Q52LATxFWRkh5SqkMeo2ltFeYdw_5NM=.2695f1ea-6744-44d4-b851-cca5db9e60ae@github.com>
Message-ID: <hHPRkDwuL85zA7tACI7lEReUwjaC8TOTB6g3szrvGGs=.d6ef2f50-6ec4-45c1-acf0-e3953f004b7e@github.com>

On Sat, 17 Dec 2022 10:25:40 GMT, Afshin Zafari <duke at openjdk.org> wrote:

>> ### Description
>> The following problems found and solved:
>> 
>> 1) Reporting which regex pattern did not match with error messages was incorrect. To report the mismatched pattern, the head of the pattern list was peeked, while it was the already peeked item from that did not match. So the next pattern to the mismatched one was reported.
>> 
>> 2) The pattern for finding a crash was incorrectly set to "# .*VMError::controlled_crash.*", while it has to be "# .*crash_with_segfault.*".
>> 
>> 3) `crash_with_segfault` function is too small and was `inline`d in compiler optimisations. So it was not in the stack trace when the error message is created.
>> 
>> ### Patch
>> 1 and 2 corrected and added the `NOINLINE` to  the `crash_with_segfault` signature. The same applied for `crash_with_sigfpe` function.
>> 
>> ### Test
>> runtime/ErrorHandling/* and tier1-5
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8298128: runtime/ErrorHandling/TestSigInfoInHsErrFile.java fails to find pattern with slowdebug

test/hotspot/jtreg/runtime/ErrorHandling/HsErrFileUtils.java line 138:

> 136:                     throw new RuntimeException("hs-err file incomplete (first missing pattern: " + currentPositivePattern.pattern() + ")");
> 137:                 } else {
> 138:                     // Impossible to reach here, where stack is not empty and currentPositivePattern which was peeked from stack is null.

If this is impossible to reach then why put in the null check? If the impossible were to happen you would get a NPE.

-------------

PR: https://git.openjdk.org/jdk/pull/11704

From duke at openjdk.org  Sun Dec 18 18:01:49 2022
From: duke at openjdk.org (Afshin Zafari)
Date: Sun, 18 Dec 2022 18:01:49 GMT
Subject: RFR: 8298128: runtime/ErrorHandling/TestSigInfoInHsErrFile.java
 fails to find pattern with slowdebug [v2]
In-Reply-To: <hHPRkDwuL85zA7tACI7lEReUwjaC8TOTB6g3szrvGGs=.d6ef2f50-6ec4-45c1-acf0-e3953f004b7e@github.com>
References: <l_-0Uq121JKyIh09JDZ23uSYQPZbLwpg_8GOXRnEuKY=.1655ef89-b023-4653-bc05-e4318ce9399a@github.com>
 <PaM4mf-9mOl1Q52LATxFWRkh5SqkMeo2ltFeYdw_5NM=.2695f1ea-6744-44d4-b851-cca5db9e60ae@github.com>
 <hHPRkDwuL85zA7tACI7lEReUwjaC8TOTB6g3szrvGGs=.d6ef2f50-6ec4-45c1-acf0-e3953f004b7e@github.com>
Message-ID: <rb2oaZo-3KC0ku80zS2kR9rkygZXFS0j1vAymg3z4NI=.d296788f-03b5-4631-bb1c-08d045759e13@github.com>

On Sat, 17 Dec 2022 22:15:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8298128: runtime/ErrorHandling/TestSigInfoInHsErrFile.java fails to find pattern with slowdebug
>
> test/hotspot/jtreg/runtime/ErrorHandling/HsErrFileUtils.java line 138:
> 
>> 136:                     throw new RuntimeException("hs-err file incomplete (first missing pattern: " + currentPositivePattern.pattern() + ")");
>> 137:                 } else {
>> 138:                     // Impossible to reach here, where stack is not empty and currentPositivePattern which was peeked from stack is null.
> 
> If this is impossible to reach then why put in the null check? If the impossible were to happen you would get a NPE.

`currentPositivePattern` is null checked before any usage. Therefore, the other parts of the code are guarded against NPE.
For using `currentPositivePattern`, I should also check it against `null`. Then, the `else { ...} ` part became unreachable. I just put this part for future contributors. Maybe the comments only are enough for that.
What is better: remove else part? or improve the comments? or both?

-------------

PR: https://git.openjdk.org/jdk/pull/11704

From dholmes at openjdk.org  Sun Dec 18 21:36:51 2022
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 18 Dec 2022 21:36:51 GMT
Subject: RFR: 8298128: runtime/ErrorHandling/TestSigInfoInHsErrFile.java
 fails to find pattern with slowdebug [v2]
In-Reply-To: <rb2oaZo-3KC0ku80zS2kR9rkygZXFS0j1vAymg3z4NI=.d296788f-03b5-4631-bb1c-08d045759e13@github.com>
References: <l_-0Uq121JKyIh09JDZ23uSYQPZbLwpg_8GOXRnEuKY=.1655ef89-b023-4653-bc05-e4318ce9399a@github.com>
 <PaM4mf-9mOl1Q52LATxFWRkh5SqkMeo2ltFeYdw_5NM=.2695f1ea-6744-44d4-b851-cca5db9e60ae@github.com>
 <hHPRkDwuL85zA7tACI7lEReUwjaC8TOTB6g3szrvGGs=.d6ef2f50-6ec4-45c1-acf0-e3953f004b7e@github.com>
 <rb2oaZo-3KC0ku80zS2kR9rkygZXFS0j1vAymg3z4NI=.d296788f-03b5-4631-bb1c-08d045759e13@github.com>
Message-ID: <FVYy88ECfQHlYSuwxLS45TZza6vfUXyhOsrIFOekutg=.bc4f11c1-03c1-4a5e-ae74-00dfee86110d@github.com>

On Sun, 18 Dec 2022 17:58:38 GMT, Afshin Zafari <duke at openjdk.org> wrote:

>> test/hotspot/jtreg/runtime/ErrorHandling/HsErrFileUtils.java line 138:
>> 
>>> 136:                     throw new RuntimeException("hs-err file incomplete (first missing pattern: " + currentPositivePattern.pattern() + ")");
>>> 137:                 } else {
>>> 138:                     // Impossible to reach here, where stack is not empty and currentPositivePattern which was peeked from stack is null.
>> 
>> If this is impossible to reach then why put in the null check? If the impossible were to happen you would get a NPE.
>
> `currentPositivePattern` is null checked before any usage. Therefore, the other parts of the code are guarded against NPE.
> For using `currentPositivePattern`, I should also check it against `null`. Then, the `else { ...} ` part became unreachable. I just put this part for future contributors. Maybe the comments only are enough for that.
> What is better: remove else part? or improve the comments? or both?

IMO all you need here is simply:

// Found all positive pattern?
if (!positivePatternStack.isEmpty()) {
    throw new RuntimeException("hs-err file incomplete (first missing pattern: " + currentPositivePattern.pattern() + ")");
}

-------------

PR: https://git.openjdk.org/jdk/pull/11704

From dholmes at openjdk.org  Sun Dec 18 21:49:51 2022
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 18 Dec 2022 21:49:51 GMT
Subject: RFR: 8298128: runtime/ErrorHandling/TestSigInfoInHsErrFile.java
 fails to find pattern with slowdebug [v2]
In-Reply-To: <PaM4mf-9mOl1Q52LATxFWRkh5SqkMeo2ltFeYdw_5NM=.2695f1ea-6744-44d4-b851-cca5db9e60ae@github.com>
References: <l_-0Uq121JKyIh09JDZ23uSYQPZbLwpg_8GOXRnEuKY=.1655ef89-b023-4653-bc05-e4318ce9399a@github.com>
 <PaM4mf-9mOl1Q52LATxFWRkh5SqkMeo2ltFeYdw_5NM=.2695f1ea-6744-44d4-b851-cca5db9e60ae@github.com>
Message-ID: <abOmIaLsqt-I_DTICd8vaPlBhs5wkYLqllCl3wz_9Ss=.0931c4ed-a22e-474d-b274-041cf4c7ccd9@github.com>

On Sat, 17 Dec 2022 10:25:40 GMT, Afshin Zafari <duke at openjdk.org> wrote:

>> ### Description
>> The following problems found and solved:
>> 
>> 1) Reporting which regex pattern did not match with error messages was incorrect. To report the mismatched pattern, the head of the pattern list was peeked, while it was the already peeked item from that did not match. So the next pattern to the mismatched one was reported.
>> 
>> 2) The pattern for finding a crash was incorrectly set to "# .*VMError::controlled_crash.*", while it has to be "# .*crash_with_segfault.*".
>> 
>> 3) `crash_with_segfault` function is too small and was `inline`d in compiler optimisations. So it was not in the stack trace when the error message is created.
>> 
>> ### Patch
>> 1 and 2 corrected and added the `NOINLINE` to  the `crash_with_segfault` signature. The same applied for `crash_with_sigfpe` function.
>> 
>> ### Test
>> runtime/ErrorHandling/* and tier1-5
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8298128: runtime/ErrorHandling/TestSigInfoInHsErrFile.java fails to find pattern with slowdebug

The error was only occurring on a slow debug build, has the fix been tested on all builds?

Thanks.

src/hotspot/share/utilities/vmError.cpp line 1806:

> 1804: // Crash with an authentic sigfpe
> 1805: volatile int sigfpe_int = 0;
> 1806: static void NOINLINE crash_with_sigfpe() {

Did you consider ALWAYSINLINE instead so the tests could be left unchanged?

-------------

PR: https://git.openjdk.org/jdk/pull/11704

From dholmes at openjdk.org  Mon Dec 19 04:48:52 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 19 Dec 2022 04:48:52 GMT
Subject: RFR: 8298241: Replace C-style casts with JavaThread::cast [v2]
In-Reply-To: <izLJUuJdorQMconqmP3EeP1-VewJARmWsO40L9nWE-s=.43fbdb21-8557-4047-8ec6-fca84af6901b@github.com>
References: <6NksENBkkBRd2KR0c5kYlmruycaqoGx-Z_-h6lkb9ms=.a133b578-12a3-4ca6-9636-0159e305c5a5@github.com>
 <KAvi9L8L4IPTdYnx9nS-ffl0AIZJfUQsolcgZIzGlqQ=.27175c05-ff52-4cd0-b6c4-7881a8d2170d@github.com>
 <izLJUuJdorQMconqmP3EeP1-VewJARmWsO40L9nWE-s=.43fbdb21-8557-4047-8ec6-fca84af6901b@github.com>
Message-ID: <et4SKQCYCds_m2PYTS6eYOHLRAfvEEOoH1IkOVBxTOI=.439377b2-06d2-4528-8a6f-f37adf699810@github.com>

On Thu, 15 Dec 2022 22:21:35 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed commented examle.
>
> Is it possible to add a test based on grep to prevent re-introduction of the unwanted C-style casts?

Sorry @dougxc only found your comment by accident. AFAIK we don't have any such style of tests that would try to check the source code for an anti-pattern. Our test suites don't have access to the src tree when they run.

-------------

PR: https://git.openjdk.org/jdk/pull/11682

From chagedorn at openjdk.org  Mon Dec 19 08:21:51 2022
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 19 Dec 2022 08:21:51 GMT
Subject: [jdk20] RFR: 8298893: Rename option UsePolyIntrinsics to
 UsePoly1305Intrinsics
In-Reply-To: <7vlroOyHCMzL1r3QRgkC-lNo3I3bNUfVj_zvSpw8wd8=.1f2f1782-ed68-4044-ab69-f31833c78690@github.com>
References: <7vlroOyHCMzL1r3QRgkC-lNo3I3bNUfVj_zvSpw8wd8=.1f2f1782-ed68-4044-ab69-f31833c78690@github.com>
Message-ID: <xAR6RbMVJ75SQLEJZh-n2_j4VeNbY81YWNXAKgeOFSg=.2896ceca-13af-4235-b876-46b781a3b4cb@github.com>

On Fri, 16 Dec 2022 19:14:07 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

> Fix for better documentation. FYI @jnimeh

> @vpaprotsk Such renaming is enhancement. But these changes are simple and will be approved for JDK 20. It is easy to follow process I pointed: add label and comment to [JDK-8298893](https://bugs.openjdk.org/browse/JDK-8298893). And wait approval. Note, for documentation changes you don't need approval during RDP1.

Sorry for the confusing and thanks @vnkozlov for jumping in and providing pointers to still get this into JDK 20. As Vladimir has mentioned, a flag renaming is an enhancement. But since it's low-risk, this should be easily approved for JDK 20.

src/hotspot/share/runtime/globals.hpp line 241:

> 239:           "Use intrinsics for java.util.Base64")                            \
> 240:                                                                             \
> 241:   product(bool, UsePoly1305Intrinsics, false, DIAGNOSTIC,                       \

You should fix the alignment of the `` here.

-------------

PR: https://git.openjdk.org/jdk20/pull/49

From duke at openjdk.org  Mon Dec 19 08:46:49 2022
From: duke at openjdk.org (Damon Fenacci)
Date: Mon, 19 Dec 2022 08:46:49 GMT
Subject: RFR: 8283740: C1: Convert flag TwoOperandLIRForm to a constant on
 all platforms
In-Reply-To: <duwY0GMAMKdK36opl5GD7-5F1aEpxXEuDlvtX9qMz3Q=.f6fc4039-3b61-4700-87a2-fb6b4d4839de@github.com>
References: <docGN73VgNwGZojMnrVyvZqCnRBlDKEyw4xTscqa0qc=.d263a7b3-5c40-4835-897b-f35b8bacd843@github.com>
 <duwY0GMAMKdK36opl5GD7-5F1aEpxXEuDlvtX9qMz3Q=.f6fc4039-3b61-4700-87a2-fb6b4d4839de@github.com>
Message-ID: <8RWfG72OyUcbMbmzIuA9o6aYLgENgf94rTu_mJPdWfw=.6520e1f3-dcc2-41f3-a7b5-5be880075518@github.com>

On Wed, 14 Dec 2022 13:39:26 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> The  _TwoOperandLIRForm_ flag (LIR requires src1 and dst to match in binary LIR ops) can be set at runtime but each platform defines a default value that is the only one accepted. Although some platform could theoretically support both, there is no realistic scenario for this.
>> The flag is removed in favour of a constant. This is defined as enum and its assigned value is defined in the platform-specific def.
>
> And FTR:
> 
> Due to bugs in certain (very old) compilers, there is widespread use of enums and avoidance of in-class initialization of static integral constant members. Compilers having such bugs are no longer supported. Except where an enum is semantically appropriate, new code should use integral constants.
> 
> https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md

@TobiHartmann @chhagedorn thanks for the review!

-------------

PR: https://git.openjdk.org/jdk/pull/11671

From duke at openjdk.org  Mon Dec 19 08:47:54 2022
From: duke at openjdk.org (Damon Fenacci)
Date: Mon, 19 Dec 2022 08:47:54 GMT
Subject: RFR: 8295661: CompileTask::compile_id() should be passed as int
In-Reply-To: <pXt4dITny-kHdCvlClKLTBWT-tve10jaSu5Xm-TCpqQ=.55f6ba96-5fe0-49da-94fb-03e80383092e@github.com>
References: <jI2RAttXag70ZVdNJerrImx6NmKgIF5fTJDShiWkn6U=.766cff6a-8af5-4eb1-a6be-861a4c15092a@github.com>
 <pXt4dITny-kHdCvlClKLTBWT-tve10jaSu5Xm-TCpqQ=.55f6ba96-5fe0-49da-94fb-03e80383092e@github.com>
Message-ID: <207bzPTXcKPuZjIifJzMdApzShAEHTKP6OH9qS3YCbQ=.8b1f402a-4dc6-42c8-8483-9860c102c9cf@github.com>

On Tue, 13 Dec 2022 16:57:29 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Changed return type of `CompileTask::compile_id()` from `int` to `uint`.
>> Also modified the type everywhere `compile_id` is used (parameters, local variables, string formatting, constant assignments) *as much as possible*.
>> Added *asserts* to check for valid value range where not possible.
>
> Thanks Tom. The intention of this change was mainly consistency, not avoiding a potential overflow.

@TobiHartmann @tkrodriguez @dougxc thanks for your reviews.

-------------

PR: https://git.openjdk.org/jdk/pull/11630

From duke at openjdk.org  Mon Dec 19 08:52:00 2022
From: duke at openjdk.org (Damon Fenacci)
Date: Mon, 19 Dec 2022 08:52:00 GMT
Subject: Integrated: 8283740: C1: Convert flag TwoOperandLIRForm to a constant
 on all platforms
In-Reply-To: <docGN73VgNwGZojMnrVyvZqCnRBlDKEyw4xTscqa0qc=.d263a7b3-5c40-4835-897b-f35b8bacd843@github.com>
References: <docGN73VgNwGZojMnrVyvZqCnRBlDKEyw4xTscqa0qc=.d263a7b3-5c40-4835-897b-f35b8bacd843@github.com>
Message-ID: <iZZ3TG3zsZyGGlY68XC1y8GMvERNdiDWTowJbQGfAlc=.d21093d6-6f49-4279-8125-8af79d03b1f5@github.com>

On Wed, 14 Dec 2022 12:51:58 GMT, Damon Fenacci <duke at openjdk.org> wrote:

> The  _TwoOperandLIRForm_ flag (LIR requires src1 and dst to match in binary LIR ops) can be set at runtime but each platform defines a default value that is the only one accepted. Although some platform could theoretically support both, there is no realistic scenario for this.
> The flag is removed in favour of a constant. This is defined as enum and its assigned value is defined in the platform-specific def.

This pull request has now been integrated.

Changeset: 86d588b0
Author:    Damon Fenacci <damon.fenacci at oracle.com>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/86d588b035d09141d807dbed6b91d9909782d61a
Stats:     62 lines in 19 files changed: 29 ins; 9 del; 24 mod

8283740: C1: Convert flag TwoOperandLIRForm to a constant on all platforms

Reviewed-by: thartmann, chagedorn

-------------

PR: https://git.openjdk.org/jdk/pull/11671

From duke at openjdk.org  Mon Dec 19 08:53:57 2022
From: duke at openjdk.org (Damon Fenacci)
Date: Mon, 19 Dec 2022 08:53:57 GMT
Subject: Integrated: 8295661: CompileTask::compile_id() should be passed as int
In-Reply-To: <jI2RAttXag70ZVdNJerrImx6NmKgIF5fTJDShiWkn6U=.766cff6a-8af5-4eb1-a6be-861a4c15092a@github.com>
References: <jI2RAttXag70ZVdNJerrImx6NmKgIF5fTJDShiWkn6U=.766cff6a-8af5-4eb1-a6be-861a4c15092a@github.com>
Message-ID: <Qt5HM04cSPhp-T996RxxC45O84T_lm1cv_j5SSccCYM=.5a8bb949-3292-4ef3-916e-204c9b32a270@github.com>

On Mon, 12 Dec 2022 11:29:55 GMT, Damon Fenacci <duke at openjdk.org> wrote:

> Changed return type of `CompileTask::compile_id()` from `int` to `uint`.
> Also modified the type everywhere `compile_id` is used (parameters, local variables, string formatting, constant assignments) *as much as possible*.
> Added *asserts* to check for valid value range where not possible.

This pull request has now been integrated.

Changeset: 8e49fcdd
Author:    Damon Fenacci <damon.fenacci at oracle.com>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8e49fcdde4fef5a8db36823b35d409ba2c9ec47b
Stats:     47 lines in 9 files changed: 0 ins; 2 del; 45 mod

8295661: CompileTask::compile_id() should be passed as int

Reviewed-by: thartmann, dnsimon, never

-------------

PR: https://git.openjdk.org/jdk/pull/11630

From thartmann at openjdk.org  Mon Dec 19 08:56:59 2022
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 19 Dec 2022 08:56:59 GMT
Subject: [jdk20] RFR: 8298893: Rename option UsePolyIntrinsics to
 UsePoly1305Intrinsics
In-Reply-To: <7vlroOyHCMzL1r3QRgkC-lNo3I3bNUfVj_zvSpw8wd8=.1f2f1782-ed68-4044-ab69-f31833c78690@github.com>
References: <7vlroOyHCMzL1r3QRgkC-lNo3I3bNUfVj_zvSpw8wd8=.1f2f1782-ed68-4044-ab69-f31833c78690@github.com>
Message-ID: <pJqIg1EoFURnSkTTBjhCfGWvmKsmFOCelAF_CyJUASU=.f9e381a6-4617-4802-9a83-2b6e3cc8f04b@github.com>

On Fri, 16 Dec 2022 19:14:07 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

> Fix for better documentation. FYI @jnimeh

Looks good to me. Just FTR, I think such flag renamings are non-trivial and therefore require two reviews before integration.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/49

From dnsimon at openjdk.org  Mon Dec 19 09:03:52 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 19 Dec 2022 09:03:52 GMT
Subject: RFR: 8298241: Replace C-style casts with JavaThread::cast [v2]
In-Reply-To: <KAvi9L8L4IPTdYnx9nS-ffl0AIZJfUQsolcgZIzGlqQ=.27175c05-ff52-4cd0-b6c4-7881a8d2170d@github.com>
References: <6NksENBkkBRd2KR0c5kYlmruycaqoGx-Z_-h6lkb9ms=.a133b578-12a3-4ca6-9636-0159e305c5a5@github.com>
 <KAvi9L8L4IPTdYnx9nS-ffl0AIZJfUQsolcgZIzGlqQ=.27175c05-ff52-4cd0-b6c4-7881a8d2170d@github.com>
Message-ID: <TmX_7s4peISIMYQFly_4wQaMwY8aQZ46jrnGPfoea8E=.76ee21d8-9b95-426d-8acc-629f4085ebb3@github.com>

On Thu, 15 Dec 2022 21:20:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This is a simple cleanup RFE to get rid of old-style C casts in relation to JavaThread.
>> 
>> In many cases involving NULL/nullptr the cast could just be dropped. Sometimes a static cast is needed to disambiguate overloads.
>> 
>> A couple of reinterpret_cast are needed when doing int/ptr conversion.
>> 
>> static_cast is used for void* conversion.
>> 
>> The other changes should be self explanatory.
>> 
>> The changes in
>> 
>> src/hotspot/os_cpu/bsd_aarch64/javaThread_bsd_aarch64.cpp
>> src/hotspot/os_cpu/windows_aarch64/javaThread_windows_aarch64.cpp
>> 
>> are a bit more extensive. That code was using an alias for `this` which is completely unnecessary (and the alias creation was using the cast). This could be factored out if thought necessary.
>> 
>> I grep'd as best I could for the old C-style casts but can't be certain I got them all.
>> 
>> Testing: 
>>  - all builds in our tiers1-5
>>  - local linux x64 product, slowdebug and fastdebug
>>  - GHA
>>  - Sanity testing tiers 1-3
>> Thanks.
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed commented examle.

Ok, thanks. That's a shame. It seems like being able to run style checkers and other linters would be useful in cases like this.

-------------

PR: https://git.openjdk.org/jdk/pull/11682

From sspitsyn at openjdk.org  Mon Dec 19 11:36:49 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 19 Dec 2022 11:36:49 GMT
Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling
 one virtual thread transitions
In-Reply-To: <avFztZhk1NDj_YekziZXXUKwiuGEWhFWabEsn010qmY=.07faf892-3bdb-4ea9-92a1-4763c77315a0@github.com>
References: <z8NCIbPeF0WzTEzXGyNxlnuOF_52vbV90p4B15xThFk=.b12cfe49-d27d-4e65-9027-796985005c14@github.com>
 <avFztZhk1NDj_YekziZXXUKwiuGEWhFWabEsn010qmY=.07faf892-3bdb-4ea9-92a1-4763c77315a0@github.com>
Message-ID: <ZwBg1VPb2EyJ6jlzUvus5dg-7C9kpoWVLSmCi46t0Y4=.7d12b318-d1e4-4d64-b222-2d489425dd5c@github.com>

On Fri, 16 Dec 2022 02:10:09 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Now the `JvmtiVTMSTransitionDisabler` mechanism supports disabling VTMS transitions for all virtual threads only. It should also support disabling transitions for any specific virtual thread as well. This will improve scalability of the JVMTI functions operating on target virtual threads as the functions can be executed concurrently without blocking each other execution when target virtual threads are different.
>> New constructor `JvmtiVTMSTransitionDisabler(jthread vthread)` is added which has jthread parameter of the target virtual thread.
>> 
>> Testing:
>>   mach5 jobs are TBD (preliminary testing was completed):
>>    - all JVMTI, JDWP, JDI and JDB tests have to be run
>>    - Kitchensink
>>    - tier5
>
> src/hotspot/share/classfile/javaClasses.cpp line 1745:
> 
>> 1743:   int val = VTMS_transition_disable_count(java_thread);
>> 1744:   java_thread->int_field_put(_jvmti_VTMS_transition_disable_count_offset, val - 1);
>> 1745: }
> 
> These are not thread-safe functions. What constraints exist for using these methods safely?
> Update: looks like they must be called with the lock held so we should assert that.
> Should also assert the count never goes negative (which I assume would be an error?).

Each of these two functions is called just once with the lock held.
I feel that asserting this would be an overkill but I can add it if you still think it is important.
I've added assert for negative count.

> src/hotspot/share/prims/jvmtiThreadState.cpp line 252:
> 
>> 250:     return; // JvmtiVTMSTransitionDisabler is no-op without virtual threads
>> 251:   }
>> 252:   if (Thread::current_or_null() == NULL) {
> 
> Nit: please use `nullptr` in new code

Done.

-------------

PR: https://git.openjdk.org/jdk/pull/11690

From sspitsyn at openjdk.org  Mon Dec 19 11:50:53 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 19 Dec 2022 11:50:53 GMT
Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling
 one virtual thread transitions
In-Reply-To: <avFztZhk1NDj_YekziZXXUKwiuGEWhFWabEsn010qmY=.07faf892-3bdb-4ea9-92a1-4763c77315a0@github.com>
References: <z8NCIbPeF0WzTEzXGyNxlnuOF_52vbV90p4B15xThFk=.b12cfe49-d27d-4e65-9027-796985005c14@github.com>
 <avFztZhk1NDj_YekziZXXUKwiuGEWhFWabEsn010qmY=.07faf892-3bdb-4ea9-92a1-4763c77315a0@github.com>
Message-ID: <wRIHAFn8t_kId4Sch_o3GoYIQRn8PjoRzbEqtNInDG8=.44193e8c-7af6-42d8-ab15-933f35d01d87@github.com>

On Fri, 16 Dec 2022 02:14:24 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Now the `JvmtiVTMSTransitionDisabler` mechanism supports disabling VTMS transitions for all virtual threads only. It should also support disabling transitions for any specific virtual thread as well. This will improve scalability of the JVMTI functions operating on target virtual threads as the functions can be executed concurrently without blocking each other execution when target virtual threads are different.
>> New constructor `JvmtiVTMSTransitionDisabler(jthread vthread)` is added which has jthread parameter of the target virtual thread.
>> 
>> Testing:
>>   mach5 jobs are TBD (preliminary testing was completed):
>>    - all JVMTI, JDWP, JDI and JDB tests have to be run
>>    - Kitchensink
>>    - tier5
>
> src/hotspot/share/prims/jvmtiThreadState.cpp line 273:
> 
>> 271:   }
>> 272:   _is_SR = is_SR;
>> 273:   _vthread = NULL;
> 
> Nit: should initialize in init list

Done.

-------------

PR: https://git.openjdk.org/jdk/pull/11690

From sspitsyn at openjdk.org  Mon Dec 19 12:17:51 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 19 Dec 2022 12:17:51 GMT
Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling
 one virtual thread transitions
In-Reply-To: <avFztZhk1NDj_YekziZXXUKwiuGEWhFWabEsn010qmY=.07faf892-3bdb-4ea9-92a1-4763c77315a0@github.com>
References: <z8NCIbPeF0WzTEzXGyNxlnuOF_52vbV90p4B15xThFk=.b12cfe49-d27d-4e65-9027-796985005c14@github.com>
 <avFztZhk1NDj_YekziZXXUKwiuGEWhFWabEsn010qmY=.07faf892-3bdb-4ea9-92a1-4763c77315a0@github.com>
Message-ID: <_NNiyosa79YVtmnwq_IXZzID3OBLP0IuSq4JgocZIEc=.be1e860e-71f3-4407-8251-eb074ad02c8d@github.com>

On Fri, 16 Dec 2022 02:15:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Now the `JvmtiVTMSTransitionDisabler` mechanism supports disabling VTMS transitions for all virtual threads only. It should also support disabling transitions for any specific virtual thread as well. This will improve scalability of the JVMTI functions operating on target virtual threads as the functions can be executed concurrently without blocking each other execution when target virtual threads are different.
>> New constructor `JvmtiVTMSTransitionDisabler(jthread vthread)` is added which has jthread parameter of the target virtual thread.
>> 
>> Testing:
>>   mach5 jobs are TBD (preliminary testing was completed):
>>    - all JVMTI, JDWP, JDI and JDB tests have to be run
>>    - Kitchensink
>>    - tier5
>
> src/hotspot/share/prims/jvmtiThreadState.cpp line 298:
> 
>> 296:   HandleMark hm(thread);
>> 297:   Handle vth = Handle(thread, JNIHandles::resolve_external_guard(_vthread));
>> 298:   if (!java_lang_VirtualThread::is_instance(vth())) {
> 
> How can this condition not be true? Should it be an assertion?

The JvmtiVTMSTransitionDisabler has to be a no-op for a non-virtual thread.
It is to avoid different branches for virtual and non-virtual cases and use this in `jvmtiEnv.cpp`:
`  JvmtiVTMSTransitionDisabler disabler(thread);`
I've added comments that mark no-op cases.

-------------

PR: https://git.openjdk.org/jdk/pull/11690

From sspitsyn at openjdk.org  Mon Dec 19 12:29:49 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 19 Dec 2022 12:29:49 GMT
Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling
 one virtual thread transitions
In-Reply-To: <qMgIdVTFTLxfv9yv-I3_XXlTd18VcycuFEkCVRQy4fk=.48f36b22-a8ff-438a-b517-18cd82441401@github.com>
References: <z8NCIbPeF0WzTEzXGyNxlnuOF_52vbV90p4B15xThFk=.b12cfe49-d27d-4e65-9027-796985005c14@github.com>
 <avFztZhk1NDj_YekziZXXUKwiuGEWhFWabEsn010qmY=.07faf892-3bdb-4ea9-92a1-4763c77315a0@github.com>
 <qMgIdVTFTLxfv9yv-I3_XXlTd18VcycuFEkCVRQy4fk=.48f36b22-a8ff-438a-b517-18cd82441401@github.com>
Message-ID: <FciN5R1fhkiQICgwQWzP9uPvPfuG1zVcnAqdlxZvEEM=.08d708c3-03a6-4d9f-a842-16951632668d@github.com>

On Fri, 16 Dec 2022 14:14:54 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiThreadState.cpp line 304:
>> 
>>> 302: 
>>> 303:   ThreadBlockInVM tbivm(thread);
>>> 304:   MonitorLocker ml(JvmtiVTMSTransition_lock, Mutex::_no_safepoint_check_flag);
>> 
>> Aside: this pattern looks very odd. Why not just lock with the safepoint check?
>
> @dholmes-ora
> Thank you for looking at this fix and for the comments.
> I will on replying and resolving them.

This update just follows the common pattern which was introduced about two years ago. At the moment I do not remember the exact reason. This code needs to wait for the counter to become zero and to use `ThreadBlockInVM` which can reach a safepoint in the destructor. Can we lock with a safepoint check in this case? Or we should get rid of the `ThreadBlockInVM` then?
I'll check if this can be fixed.

-------------

PR: https://git.openjdk.org/jdk/pull/11690

From sspitsyn at openjdk.org  Mon Dec 19 12:50:11 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 19 Dec 2022 12:50:11 GMT
Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling
 one virtual thread transitions [v2]
In-Reply-To: <z8NCIbPeF0WzTEzXGyNxlnuOF_52vbV90p4B15xThFk=.b12cfe49-d27d-4e65-9027-796985005c14@github.com>
References: <z8NCIbPeF0WzTEzXGyNxlnuOF_52vbV90p4B15xThFk=.b12cfe49-d27d-4e65-9027-796985005c14@github.com>
Message-ID: <a6kdfgn1ErASsGmUs2oaL-QG5c5HjJylwtY7gxNv6pw=.8855ca62-67b6-43ab-aeec-418a45fb002f@github.com>

> Now the `JvmtiVTMSTransitionDisabler` mechanism supports disabling VTMS transitions for all virtual threads only. It should also support disabling transitions for any specific virtual thread as well. This will improve scalability of the JVMTI functions operating on target virtual threads as the functions can be executed concurrently without blocking each other execution when target virtual threads are different.
> New constructor `JvmtiVTMSTransitionDisabler(jthread vthread)` is added which has jthread parameter of the target virtual thread.
> 
> Testing:
>   mach5 jobs are TBD (preliminary testing was completed):
>    - all JVMTI, JDWP, JDI and JDB tests have to be run
>    - Kitchensink
>    - tier5

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review comments are addressed

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11690/files
  - new: https://git.openjdk.org/jdk/pull/11690/files/641f21f0..2603eebb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11690&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11690&range=00-01

  Stats: 21 lines in 3 files changed: 6 ins; 4 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/11690.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11690/head:pull/11690

PR: https://git.openjdk.org/jdk/pull/11690

From eosterlund at openjdk.org  Mon Dec 19 15:32:48 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 19 Dec 2022 15:32:48 GMT
Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC
In-Reply-To: <BOJ4yH2GtNWXDVXMKwPw9Ic359dnBK8Sb9tDw3a5Qmc=.197acbb0-3ed6-418f-8bcf-70ef4b67de5e@github.com>
References: <BOJ4yH2GtNWXDVXMKwPw9Ic359dnBK8Sb9tDw3a5Qmc=.197acbb0-3ed6-418f-8bcf-70ef4b67de5e@github.com>
Message-ID: <zb6CHXOhKOorjQfE8JUWzSab1_E6cC7xEx80Z3DhqmI=.140ddc8e-fe6f-4c4c-ac0f-8f24cb2cef1a@github.com>

On Thu, 8 Dec 2022 11:23:57 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The JfrVFrameStream is used while generating stack traces for events. One of the events are the ZPage allocation event. This event is sometimes sent when ZGC is relocating. The current implementation of JfrVFrameStream uses WalkContinuation::include, which causes JFR to walk the continuation and perform GC barriers. This is problematic, since ZGC has a requirement that we never perform load barriers while running the relocation code. If we do, we might end up performing other reloctions from the the relocation code, and in some cases that causes dead locks.
> 
> I propose that JFR doesn't walk the continuations when sending events. An alternative could be to limit this to ZGC, but I'd like to get some feedback around that from JFR / Loom devs.
> 
> We've been testing this patch in the Generational ZGC repository.

In Deoptimization::unpack_frames we set the frame anchor SP to null across a critical section in which the stack isn't very parseable for tracing tools like JFR, which protects against stack walks there. We could use a very similar solution when doing the processing of the stack watermark - essentially annotate that while we do that, we don't really want any stack tracing here, by clearing the anchor last Java SP. Would that constitute a more desirable solution?

-------------

PR: https://git.openjdk.org/jdk/pull/11586

From mgronlun at openjdk.org  Mon Dec 19 16:33:50 2022
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 19 Dec 2022 16:33:50 GMT
Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC
In-Reply-To: <BOJ4yH2GtNWXDVXMKwPw9Ic359dnBK8Sb9tDw3a5Qmc=.197acbb0-3ed6-418f-8bcf-70ef4b67de5e@github.com>
References: <BOJ4yH2GtNWXDVXMKwPw9Ic359dnBK8Sb9tDw3a5Qmc=.197acbb0-3ed6-418f-8bcf-70ef4b67de5e@github.com>
Message-ID: <DoeGqI3dKcTxKkYV4z4WoW4yn7Dsg9ff3h0OSKn2sO4=.d388419e-885e-48be-aca8-15499595c37d@github.com>

On Thu, 8 Dec 2022 11:23:57 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The JfrVFrameStream is used while generating stack traces for events. One of the events are the ZPage allocation event. This event is sometimes sent when ZGC is relocating. The current implementation of JfrVFrameStream uses WalkContinuation::include, which causes JFR to walk the continuation and perform GC barriers. This is problematic, since ZGC has a requirement that we never perform load barriers while running the relocation code. If we do, we might end up performing other reloctions from the the relocation code, and in some cases that causes dead locks.
> 
> I propose that JFR doesn't walk the continuations when sending events. An alternative could be to limit this to ZGC, but I'd like to get some feedback around that from JFR / Loom devs.
> 
> We've been testing this patch in the Generational ZGC repository.

I would prefer if this problem could be solved without introducing an association to the event type. It is a solution that would work ok with the current implementation, but with future, upcoming implementations, it will be more challenging to maintain the association with the event type.

-------------

PR: https://git.openjdk.org/jdk/pull/11586

From duke at openjdk.org  Mon Dec 19 17:07:10 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Mon, 19 Dec 2022 17:07:10 GMT
Subject: [jdk20] RFR: 8298893: Rename option UsePolyIntrinsics to
 UsePoly1305Intrinsics [v2]
In-Reply-To: <xAR6RbMVJ75SQLEJZh-n2_j4VeNbY81YWNXAKgeOFSg=.2896ceca-13af-4235-b876-46b781a3b4cb@github.com>
References: <7vlroOyHCMzL1r3QRgkC-lNo3I3bNUfVj_zvSpw8wd8=.1f2f1782-ed68-4044-ab69-f31833c78690@github.com>
 <xAR6RbMVJ75SQLEJZh-n2_j4VeNbY81YWNXAKgeOFSg=.2896ceca-13af-4235-b876-46b781a3b4cb@github.com>
Message-ID: <88IjJiZ3-c14pzLMSfPE6i1P-gobDkxiuk3jcKb1tfc=.4aa4652f-585b-4790-910e-13f7e001deac@github.com>

On Mon, 19 Dec 2022 08:14:50 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   whitespace
>
> src/hotspot/share/runtime/globals.hpp line 241:
> 
>> 239:           "Use intrinsics for java.util.Base64")                            \
>> 240:                                                                             \
>> 241:   product(bool, UsePoly1305Intrinsics, false, DIAGNOSTIC,                       \
> 
> You should fix the alignment of the `` here.

done. thanks for spotting this

-------------

PR: https://git.openjdk.org/jdk20/pull/49

From duke at openjdk.org  Mon Dec 19 17:07:10 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Mon, 19 Dec 2022 17:07:10 GMT
Subject: [jdk20] RFR: 8298893: Rename option UsePolyIntrinsics to
 UsePoly1305Intrinsics [v2]
In-Reply-To: <7vlroOyHCMzL1r3QRgkC-lNo3I3bNUfVj_zvSpw8wd8=.1f2f1782-ed68-4044-ab69-f31833c78690@github.com>
References: <7vlroOyHCMzL1r3QRgkC-lNo3I3bNUfVj_zvSpw8wd8=.1f2f1782-ed68-4044-ab69-f31833c78690@github.com>
Message-ID: <hznfrjCGVMMsnmhtoXfnFZ-06C-NVOUG7ZZOv5L2UEU=.0c344193-2a72-4fc6-bb2a-e8f7d37396fa@github.com>

> Fix for better documentation. FYI @jnimeh

Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:

  whitespace

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/49/files
  - new: https://git.openjdk.org/jdk20/pull/49/files/a4faddeb..c31781b0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=49&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=49&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk20/pull/49.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/49/head:pull/49

PR: https://git.openjdk.org/jdk20/pull/49

From dholmes at openjdk.org  Tue Dec 20 04:39:53 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 20 Dec 2022 04:39:53 GMT
Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling
 one virtual thread transitions [v2]
In-Reply-To: <_NNiyosa79YVtmnwq_IXZzID3OBLP0IuSq4JgocZIEc=.be1e860e-71f3-4407-8251-eb074ad02c8d@github.com>
References: <z8NCIbPeF0WzTEzXGyNxlnuOF_52vbV90p4B15xThFk=.b12cfe49-d27d-4e65-9027-796985005c14@github.com>
 <avFztZhk1NDj_YekziZXXUKwiuGEWhFWabEsn010qmY=.07faf892-3bdb-4ea9-92a1-4763c77315a0@github.com>
 <_NNiyosa79YVtmnwq_IXZzID3OBLP0IuSq4JgocZIEc=.be1e860e-71f3-4407-8251-eb074ad02c8d@github.com>
Message-ID: <FbnwqCrpU6T6MTTxecAjf_rmiqgdCoUEtJkFm4k0qZo=.cd5706eb-6eac-4965-a353-c80ab0af0806@github.com>

On Mon, 19 Dec 2022 12:13:42 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiThreadState.cpp line 298:
>> 
>>> 296:   HandleMark hm(thread);
>>> 297:   Handle vth = Handle(thread, JNIHandles::resolve_external_guard(_vthread));
>>> 298:   if (!java_lang_VirtualThread::is_instance(vth())) {
>> 
>> How can this condition not be true? Should it be an assertion?
>
> The JvmtiVTMSTransitionDisabler has to be a no-op for a non-virtual thread. It is to avoid different branches where it is possible for virtual and non-virtual cases and use this in `jvmtiEnv.cpp`:
> `  JvmtiVTMSTransitionDisabler disabler(thread);`
> I've added comments that mark no-op cases.

I see. I assumed the name `_vthread` implied it was actually known to be a vthread. Really the field and parameters should just be called `thread`.

-------------

PR: https://git.openjdk.org/jdk/pull/11690

From dholmes at openjdk.org  Tue Dec 20 04:54:51 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 20 Dec 2022 04:54:51 GMT
Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling
 one virtual thread transitions [v2]
In-Reply-To: <ZwBg1VPb2EyJ6jlzUvus5dg-7C9kpoWVLSmCi46t0Y4=.7d12b318-d1e4-4d64-b222-2d489425dd5c@github.com>
References: <z8NCIbPeF0WzTEzXGyNxlnuOF_52vbV90p4B15xThFk=.b12cfe49-d27d-4e65-9027-796985005c14@github.com>
 <avFztZhk1NDj_YekziZXXUKwiuGEWhFWabEsn010qmY=.07faf892-3bdb-4ea9-92a1-4763c77315a0@github.com>
 <ZwBg1VPb2EyJ6jlzUvus5dg-7C9kpoWVLSmCi46t0Y4=.7d12b318-d1e4-4d64-b222-2d489425dd5c@github.com>
Message-ID: <Lv2eRWx2m12BhpKiZnBQkiDYa_TiKVQguEjE7JpxBII=.1628ed0a-d674-4986-9b2f-88523782bf55@github.com>

On Mon, 19 Dec 2022 11:32:40 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/classfile/javaClasses.cpp line 1745:
>> 
>>> 1743:   int val = VTMS_transition_disable_count(java_thread);
>>> 1744:   java_thread->int_field_put(_jvmti_VTMS_transition_disable_count_offset, val - 1);
>>> 1745: }
>> 
>> These are not thread-safe functions. What constraints exist for using these methods safely?
>> Update: looks like they must be called with the lock held so we should assert that.
>> Should also assert the count never goes negative (which I assume would be an error?).
>
> Each of these two functions is called just once with the lock held.
> I feel that asserting this would be an overkill but I can add it if you still think it is important.
> I've added assert for negative count.

asserts would be good please else someone may use them somewhere else without locking.

-------------

PR: https://git.openjdk.org/jdk/pull/11690

From dholmes at openjdk.org  Tue Dec 20 04:54:52 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 20 Dec 2022 04:54:52 GMT
Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling
 one virtual thread transitions [v2]
In-Reply-To: <FciN5R1fhkiQICgwQWzP9uPvPfuG1zVcnAqdlxZvEEM=.08d708c3-03a6-4d9f-a842-16951632668d@github.com>
References: <z8NCIbPeF0WzTEzXGyNxlnuOF_52vbV90p4B15xThFk=.b12cfe49-d27d-4e65-9027-796985005c14@github.com>
 <avFztZhk1NDj_YekziZXXUKwiuGEWhFWabEsn010qmY=.07faf892-3bdb-4ea9-92a1-4763c77315a0@github.com>
 <qMgIdVTFTLxfv9yv-I3_XXlTd18VcycuFEkCVRQy4fk=.48f36b22-a8ff-438a-b517-18cd82441401@github.com>
 <FciN5R1fhkiQICgwQWzP9uPvPfuG1zVcnAqdlxZvEEM=.08d708c3-03a6-4d9f-a842-16951632668d@github.com>
Message-ID: <-fbjOn9Wsqar-pUqBT_qNslZvj7qBmTnWuTEkuZFt-M=.85e31c4e-0371-4aac-81f3-e37475abde10@github.com>

On Mon, 19 Dec 2022 12:27:08 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> @dholmes-ora
>> Thank you for looking at this fix and for the comments.
>> I will on replying and resolving them.
>
> This update just follows the common pattern which was introduced about two years ago. At the moment I do not remember the exact reason. This code needs to wait for the counter to become zero and to use `ThreadBlockInVM` which can reach a safepoint in the destructor. Can we lock with a safepoint check in this case? Or we should get rid of the `ThreadBlockInVM` then?
> I'll check if this can be fixed.

This can be a separate RFE if the reason for it being a nosafepoint lock no longer holds. It would be cleaner to use a normal safepoint checking lock than to artificially make the thread safepoint-safe before using it.

-------------

PR: https://git.openjdk.org/jdk/pull/11690

From dholmes at openjdk.org  Tue Dec 20 04:54:54 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 20 Dec 2022 04:54:54 GMT
Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling
 one virtual thread transitions [v2]
In-Reply-To: <a6kdfgn1ErASsGmUs2oaL-QG5c5HjJylwtY7gxNv6pw=.8855ca62-67b6-43ab-aeec-418a45fb002f@github.com>
References: <z8NCIbPeF0WzTEzXGyNxlnuOF_52vbV90p4B15xThFk=.b12cfe49-d27d-4e65-9027-796985005c14@github.com>
 <a6kdfgn1ErASsGmUs2oaL-QG5c5HjJylwtY7gxNv6pw=.8855ca62-67b6-43ab-aeec-418a45fb002f@github.com>
Message-ID: <aicRGswOTXYdHRo60_OXhVRCWVQorewLRpMukkvMyas=.fb2af9d3-49b3-4fdd-a029-ef9d9929a915@github.com>

On Mon, 19 Dec 2022 12:50:11 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Now the `JvmtiVTMSTransitionDisabler` mechanism supports disabling VTMS transitions for all virtual threads only. It should also support disabling transitions for any specific virtual thread as well. This will improve scalability of the JVMTI functions operating on target virtual threads as the functions can be executed concurrently without blocking each other execution when target virtual threads are different.
>> New constructor `JvmtiVTMSTransitionDisabler(jthread vthread)` is added which has jthread parameter of the target virtual thread.
>> 
>> Testing:
>>   mach5 jobs are TBD (preliminary testing was completed):
>>    - all JVMTI, JDWP, JDI and JDB tests have to be run
>>    - Kitchensink
>>    - tier5
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments are addressed

src/hotspot/share/prims/jvmtiThreadState.hpp line 88:

> 86: 
> 87:   bool _is_SR;                                           // is suspender or resumer
> 88:   jthread _vthread;                                      // virtual thread to disable transitions for

Please don't call this `_vthread` as it may or may not be a virtual thread.

-------------

PR: https://git.openjdk.org/jdk/pull/11690

From eosterlund at openjdk.org  Tue Dec 20 06:03:47 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 20 Dec 2022 06:03:47 GMT
Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC
In-Reply-To: <DoeGqI3dKcTxKkYV4z4WoW4yn7Dsg9ff3h0OSKn2sO4=.d388419e-885e-48be-aca8-15499595c37d@github.com>
References: <BOJ4yH2GtNWXDVXMKwPw9Ic359dnBK8Sb9tDw3a5Qmc=.197acbb0-3ed6-418f-8bcf-70ef4b67de5e@github.com>
 <DoeGqI3dKcTxKkYV4z4WoW4yn7Dsg9ff3h0OSKn2sO4=.d388419e-885e-48be-aca8-15499595c37d@github.com>
Message-ID: <ClmBO8J6cf-3JopE7sUBDdtbknhaV6zML8mD5TvEeNw=.c69531d8-083a-4a31-bc29-82b995df7af3@github.com>

On Mon, 19 Dec 2022 16:31:18 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> I would prefer if this problem could be solved without introducing an association to the event type. It is a solution that would work ok with the current implementation, but with future, upcoming implementations, it will be more challenging to maintain the association with the event type.

In my proposed solution there is no association to the event type. We just say the stack shouldn't be parsed during stack watermark processing, whatever events might be interested in doing so.

-------------

PR: https://git.openjdk.org/jdk/pull/11586

From eosterlund at openjdk.org  Tue Dec 20 07:12:29 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 20 Dec 2022 07:12:29 GMT
Subject: RFR: 8299072: java_lang_ref_Reference::clear_referent should be GC
 agnostic
Message-ID: <TdoMMvxcNRmL_AxzSGZeTXt79zn0zOAjM31mgC7i3t0=.a3605d22-90b5-4cf2-97fb-eef7313d81bc@github.com>

The current java_lang_ref_Reference::clear_referent implementation performs a raw reference clear. That doesn't work well with upcoming GC algorithms. It should be made GC agnostic by going through the normal access API.

-------------

Commit messages:
 - 8299072: java_lang_ref_Reference::clear_referent should be GC agnostic

Changes: https://git.openjdk.org/jdk/pull/11736/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11736&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299072
  Stats: 8 lines in 5 files changed: 5 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/11736.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11736/head:pull/11736

PR: https://git.openjdk.org/jdk/pull/11736

From dholmes at openjdk.org  Tue Dec 20 08:15:50 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 20 Dec 2022 08:15:50 GMT
Subject: RFR: 8299072: java_lang_ref_Reference::clear_referent should be GC
 agnostic
In-Reply-To: <TdoMMvxcNRmL_AxzSGZeTXt79zn0zOAjM31mgC7i3t0=.a3605d22-90b5-4cf2-97fb-eef7313d81bc@github.com>
References: <TdoMMvxcNRmL_AxzSGZeTXt79zn0zOAjM31mgC7i3t0=.a3605d22-90b5-4cf2-97fb-eef7313d81bc@github.com>
Message-ID: <8je3w2XaNdQEAKx0lLHp2T2UXkOUqEV0ks-2TFL2AJE=.fbf307d0-9833-4465-a914-3a7e9f05d12b@github.com>

On Tue, 20 Dec 2022 07:05:34 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> The current java_lang_ref_Reference::clear_referent implementation performs a raw reference clear. That doesn't work well with upcoming GC algorithms. It should be made GC agnostic by going through the normal access API.

So `clear_referent` is made GC agnostic, but then all the existing GC's are changed to use the original raw version? Why do they not use the GC agnostic version - performance?

-------------

PR: https://git.openjdk.org/jdk/pull/11736

From eosterlund at openjdk.org  Tue Dec 20 08:24:48 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 20 Dec 2022 08:24:48 GMT
Subject: RFR: 8299072: java_lang_ref_Reference::clear_referent should be GC
 agnostic
In-Reply-To: <8je3w2XaNdQEAKx0lLHp2T2UXkOUqEV0ks-2TFL2AJE=.fbf307d0-9833-4465-a914-3a7e9f05d12b@github.com>
References: <TdoMMvxcNRmL_AxzSGZeTXt79zn0zOAjM31mgC7i3t0=.a3605d22-90b5-4cf2-97fb-eef7313d81bc@github.com>
 <8je3w2XaNdQEAKx0lLHp2T2UXkOUqEV0ks-2TFL2AJE=.fbf307d0-9833-4465-a914-3a7e9f05d12b@github.com>
Message-ID: <JprNFBBGioIRmTFCnd66xp99_SYg4n0teHx0T5k7isE=.22c8b8c5-0d2a-42fd-a033-c8a6fac20f18@github.com>

On Tue, 20 Dec 2022 08:12:41 GMT, David Holmes <dholmes at openjdk.org> wrote:

> So `clear_referent` is made GC agnostic, but then all the existing GC's are changed to use the original raw version? Why do they not use the GC agnostic version - performance?

The usual reasoning we have is that a GC implementation itself is allowed to use "raw" accesses. Because it knows exactly what it needs to do and when. But the shared runtime code should not do that, because it does not know every GC implementation nor should it have to. Therefore, only the shared runtime part is changed to be GC agnostic. The GC implementation code (in this case reference processors) should continue to use raw accesses.

-------------

PR: https://git.openjdk.org/jdk/pull/11736

From eosterlund at openjdk.org  Tue Dec 20 08:38:50 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 20 Dec 2022 08:38:50 GMT
Subject: RFR: 8299079: Better interface nmethod oop accesses
Message-ID: <XUnYphaHNdOvTPk48hRm_9-brWEJN6o22iMUyTl4HxU=.e8b89be3-da28-4f97-b335-6bd09d39993e@github.com>

Today when oops are read from nmethods, we use the same interfacing that we would use to read any other IN_NATIVE oops. That isn't enough for generational ZGC. The nmethod oops are rather different from other IN_NATIVE oops in that they are encoded in the machine code as direct pointers. Normally, IN_NATIVE oops with generational ZGC are not direct pointers, but are colored pointered that can be converted to direct pointers by going through a load barrier. For nmethod oops, that conversion requires external knowledge from the surrounding nmethod. I propose a new NMethodAccess to interface better with the GC.

-------------

Commit messages:
 - 8299079: Better interface nmethod oop accesses

Changes: https://git.openjdk.org/jdk/pull/11738/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11738&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299079
  Stats: 24 lines in 3 files changed: 10 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/11738.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11738/head:pull/11738

PR: https://git.openjdk.org/jdk/pull/11738

From kbarrett at openjdk.org  Tue Dec 20 09:15:49 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 20 Dec 2022 09:15:49 GMT
Subject: RFR: 8299072: java_lang_ref_Reference::clear_referent should be GC
 agnostic
In-Reply-To: <TdoMMvxcNRmL_AxzSGZeTXt79zn0zOAjM31mgC7i3t0=.a3605d22-90b5-4cf2-97fb-eef7313d81bc@github.com>
References: <TdoMMvxcNRmL_AxzSGZeTXt79zn0zOAjM31mgC7i3t0=.a3605d22-90b5-4cf2-97fb-eef7313d81bc@github.com>
Message-ID: <e4UIms5Vi8GvRORLRmqA12R69ASdjjkX6xVbbYsYapw=.05c9a80e-b2af-4a62-bcf0-acc3d1bb7d98@github.com>

On Tue, 20 Dec 2022 07:05:34 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> The current java_lang_ref_Reference::clear_referent implementation performs a raw reference clear. That doesn't work well with upcoming GC algorithms. It should be made GC agnostic by going through the normal access API.

Looks good.  Mea culpa I think.

-------------

PR: https://git.openjdk.org/jdk/pull/11736

From eosterlund at openjdk.org  Tue Dec 20 09:20:49 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 20 Dec 2022 09:20:49 GMT
Subject: RFR: 8299072: java_lang_ref_Reference::clear_referent should be GC
 agnostic
In-Reply-To: <e4UIms5Vi8GvRORLRmqA12R69ASdjjkX6xVbbYsYapw=.05c9a80e-b2af-4a62-bcf0-acc3d1bb7d98@github.com>
References: <TdoMMvxcNRmL_AxzSGZeTXt79zn0zOAjM31mgC7i3t0=.a3605d22-90b5-4cf2-97fb-eef7313d81bc@github.com>
 <e4UIms5Vi8GvRORLRmqA12R69ASdjjkX6xVbbYsYapw=.05c9a80e-b2af-4a62-bcf0-acc3d1bb7d98@github.com>
Message-ID: <qvBsMpkhQeRsyeK3TgvRedKEtIdCK9uwicH9yuNQxE0=.aaaece06-463f-4615-afde-8ffaf71ddbce@github.com>

On Tue, 20 Dec 2022 09:12:48 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> The current java_lang_ref_Reference::clear_referent implementation performs a raw reference clear. That doesn't work well with upcoming GC algorithms. It should be made GC agnostic by going through the normal access API.
>
> Looks good.  Mea culpa I think.

Thanks for the review, @kimbarrett!

-------------

PR: https://git.openjdk.org/jdk/pull/11736

From chagedorn at openjdk.org  Tue Dec 20 09:36:51 2022
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 20 Dec 2022 09:36:51 GMT
Subject: [jdk20] RFR: 8298893: Rename option UsePolyIntrinsics to
 UsePoly1305Intrinsics [v2]
In-Reply-To: <hznfrjCGVMMsnmhtoXfnFZ-06C-NVOUG7ZZOv5L2UEU=.0c344193-2a72-4fc6-bb2a-e8f7d37396fa@github.com>
References: <7vlroOyHCMzL1r3QRgkC-lNo3I3bNUfVj_zvSpw8wd8=.1f2f1782-ed68-4044-ab69-f31833c78690@github.com>
 <hznfrjCGVMMsnmhtoXfnFZ-06C-NVOUG7ZZOv5L2UEU=.0c344193-2a72-4fc6-bb2a-e8f7d37396fa@github.com>
Message-ID: <ggDUMTeOf29JkvljW2Le1sXa8P6JJZneY-e0FdPRpLM=.0179f504-af98-49a2-b141-9145ee378eef@github.com>

On Mon, 19 Dec 2022 17:07:10 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> Fix for better documentation. FYI @jnimeh
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   whitespace

Marked as reviewed by chagedorn (Reviewer).

-------------

PR: https://git.openjdk.org/jdk20/pull/49

From egahlin at openjdk.org  Tue Dec 20 10:02:47 2022
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 20 Dec 2022 10:02:47 GMT
Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC
In-Reply-To: <ClmBO8J6cf-3JopE7sUBDdtbknhaV6zML8mD5TvEeNw=.c69531d8-083a-4a31-bc29-82b995df7af3@github.com>
References: <BOJ4yH2GtNWXDVXMKwPw9Ic359dnBK8Sb9tDw3a5Qmc=.197acbb0-3ed6-418f-8bcf-70ef4b67de5e@github.com>
 <DoeGqI3dKcTxKkYV4z4WoW4yn7Dsg9ff3h0OSKn2sO4=.d388419e-885e-48be-aca8-15499595c37d@github.com>
 <ClmBO8J6cf-3JopE7sUBDdtbknhaV6zML8mD5TvEeNw=.c69531d8-083a-4a31-bc29-82b995df7af3@github.com>
Message-ID: <wZO4SEsBHqM8TkUDmZiTxrB5nLK0Of3qYt2dNIWDDaQ=.81584eaf-355d-4eb1-b884-50f43c03878c@github.com>

On Tue, 20 Dec 2022 06:01:28 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> In my proposed solution there is no association to the event type. We just say the stack shouldn't be parsed during stack watermark processing, whatever events might be interested in doing so.

With your solution, would JFR stack walking be abandoned, or would it continue with the current stack trace once watermark processing is complete?

-------------

PR: https://git.openjdk.org/jdk/pull/11586

From eosterlund at openjdk.org  Tue Dec 20 10:07:50 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 20 Dec 2022 10:07:50 GMT
Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC
In-Reply-To: <wZO4SEsBHqM8TkUDmZiTxrB5nLK0Of3qYt2dNIWDDaQ=.81584eaf-355d-4eb1-b884-50f43c03878c@github.com>
References: <BOJ4yH2GtNWXDVXMKwPw9Ic359dnBK8Sb9tDw3a5Qmc=.197acbb0-3ed6-418f-8bcf-70ef4b67de5e@github.com>
 <DoeGqI3dKcTxKkYV4z4WoW4yn7Dsg9ff3h0OSKn2sO4=.d388419e-885e-48be-aca8-15499595c37d@github.com>
 <ClmBO8J6cf-3JopE7sUBDdtbknhaV6zML8mD5TvEeNw=.c69531d8-083a-4a31-bc29-82b995df7af3@github.com>
 <wZO4SEsBHqM8TkUDmZiTxrB5nLK0Of3qYt2dNIWDDaQ=.81584eaf-355d-4eb1-b884-50f43c03878c@github.com>
Message-ID: <QsUxGjoDzTsb9KLkbFEL-fQdZRnw4ZrAExaGUiRQGcU=.0f8752e2-5601-494a-bebb-e122c0913392@github.com>

On Tue, 20 Dec 2022 10:00:06 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> > In my proposed solution there is no association to the event type. We just say the stack shouldn't be parsed during stack watermark processing, whatever events might be interested in doing so.
> 
> With your solution, would JFR stack walking be abandoned, or would it continue with the current stack trace once watermark processing is complete?

It would be abandonned, and that is how it works for some other sensitive parts of the VM where we just don't want stack tracing.

-------------

PR: https://git.openjdk.org/jdk/pull/11586

From sspitsyn at openjdk.org  Tue Dec 20 10:12:51 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 20 Dec 2022 10:12:51 GMT
Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling
 one virtual thread transitions [v2]
In-Reply-To: <Lv2eRWx2m12BhpKiZnBQkiDYa_TiKVQguEjE7JpxBII=.1628ed0a-d674-4986-9b2f-88523782bf55@github.com>
References: <z8NCIbPeF0WzTEzXGyNxlnuOF_52vbV90p4B15xThFk=.b12cfe49-d27d-4e65-9027-796985005c14@github.com>
 <avFztZhk1NDj_YekziZXXUKwiuGEWhFWabEsn010qmY=.07faf892-3bdb-4ea9-92a1-4763c77315a0@github.com>
 <ZwBg1VPb2EyJ6jlzUvus5dg-7C9kpoWVLSmCi46t0Y4=.7d12b318-d1e4-4d64-b222-2d489425dd5c@github.com>
 <Lv2eRWx2m12BhpKiZnBQkiDYa_TiKVQguEjE7JpxBII=.1628ed0a-d674-4986-9b2f-88523782bf55@github.com>
Message-ID: <BiKOzYehMJZ4VxXsuDi1Gl5hx2FJD95IQXKmwJdT0zs=.dbd8c799-03ca-4c03-b1a2-c02fbfc59afc@github.com>

On Tue, 20 Dec 2022 04:51:52 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Each of these two functions is called just once with the lock held.
>> I feel that asserting this would be an overkill but I can add it if you still think it is important.
>> I've added assert for negative count.
>
> asserts would be good please else someone may use them somewhere else without locking.

Done.

-------------

PR: https://git.openjdk.org/jdk/pull/11690

From sspitsyn at openjdk.org  Tue Dec 20 10:20:49 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 20 Dec 2022 10:20:49 GMT
Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling
 one virtual thread transitions [v2]
In-Reply-To: <FbnwqCrpU6T6MTTxecAjf_rmiqgdCoUEtJkFm4k0qZo=.cd5706eb-6eac-4965-a353-c80ab0af0806@github.com>
References: <z8NCIbPeF0WzTEzXGyNxlnuOF_52vbV90p4B15xThFk=.b12cfe49-d27d-4e65-9027-796985005c14@github.com>
 <avFztZhk1NDj_YekziZXXUKwiuGEWhFWabEsn010qmY=.07faf892-3bdb-4ea9-92a1-4763c77315a0@github.com>
 <_NNiyosa79YVtmnwq_IXZzID3OBLP0IuSq4JgocZIEc=.be1e860e-71f3-4407-8251-eb074ad02c8d@github.com>
 <FbnwqCrpU6T6MTTxecAjf_rmiqgdCoUEtJkFm4k0qZo=.cd5706eb-6eac-4965-a353-c80ab0af0806@github.com>
Message-ID: <F389lTmHjCViotVsD0_Ay3PjN69pxz2Ehbj5tkj18u0=.f229e478-bd5e-4890-9be0-474f7db86f38@github.com>

On Tue, 20 Dec 2022 04:37:32 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The JvmtiVTMSTransitionDisabler has to be a no-op for a non-virtual thread. It is to avoid different branches where it is possible for virtual and non-virtual cases and use this in `jvmtiEnv.cpp`:
>> `  JvmtiVTMSTransitionDisabler disabler(thread);`
>> I've added comments that mark no-op cases.
>
> I see. I assumed the name `_vthread` implied it was actually known to be a vthread. Really the field and parameters should just be called `thread`.

Okay, renamed now.

-------------

PR: https://git.openjdk.org/jdk/pull/11690

From sspitsyn at openjdk.org  Tue Dec 20 10:20:51 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 20 Dec 2022 10:20:51 GMT
Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling
 one virtual thread transitions [v2]
In-Reply-To: <aicRGswOTXYdHRo60_OXhVRCWVQorewLRpMukkvMyas=.fb2af9d3-49b3-4fdd-a029-ef9d9929a915@github.com>
References: <z8NCIbPeF0WzTEzXGyNxlnuOF_52vbV90p4B15xThFk=.b12cfe49-d27d-4e65-9027-796985005c14@github.com>
 <a6kdfgn1ErASsGmUs2oaL-QG5c5HjJylwtY7gxNv6pw=.8855ca62-67b6-43ab-aeec-418a45fb002f@github.com>
 <aicRGswOTXYdHRo60_OXhVRCWVQorewLRpMukkvMyas=.fb2af9d3-49b3-4fdd-a029-ef9d9929a915@github.com>
Message-ID: <d9eUQfObyP1aUctc78-_qMyZnDA-7ZCppEYuM41c4UQ=.7bec0491-7297-45a4-bf63-4c3ec7d5f770@github.com>

On Tue, 20 Dec 2022 04:50:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review comments are addressed
>
> src/hotspot/share/prims/jvmtiThreadState.hpp line 88:
> 
>> 86: 
>> 87:   bool _is_SR;                                           // is suspender or resumer
>> 88:   jthread _vthread;                                      // virtual thread to disable transitions for
> 
> Please don't call this `_vthread` as it may or may not be a virtual thread.

Fixed now.

-------------

PR: https://git.openjdk.org/jdk/pull/11690

From sspitsyn at openjdk.org  Tue Dec 20 10:24:53 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 20 Dec 2022 10:24:53 GMT
Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling
 one virtual thread transitions [v2]
In-Reply-To: <-fbjOn9Wsqar-pUqBT_qNslZvj7qBmTnWuTEkuZFt-M=.85e31c4e-0371-4aac-81f3-e37475abde10@github.com>
References: <z8NCIbPeF0WzTEzXGyNxlnuOF_52vbV90p4B15xThFk=.b12cfe49-d27d-4e65-9027-796985005c14@github.com>
 <avFztZhk1NDj_YekziZXXUKwiuGEWhFWabEsn010qmY=.07faf892-3bdb-4ea9-92a1-4763c77315a0@github.com>
 <qMgIdVTFTLxfv9yv-I3_XXlTd18VcycuFEkCVRQy4fk=.48f36b22-a8ff-438a-b517-18cd82441401@github.com>
 <FciN5R1fhkiQICgwQWzP9uPvPfuG1zVcnAqdlxZvEEM=.08d708c3-03a6-4d9f-a842-16951632668d@github.com>
 <-fbjOn9Wsqar-pUqBT_qNslZvj7qBmTnWuTEkuZFt-M=.85e31c4e-0371-4aac-81f3-e37475abde10@github.com>
Message-ID: <50W4OIGSyCQhBbg0qJ2Ie_9H-R0LSsWJqCT_E5FR7KI=.803c3631-2f33-41e7-b7fb-ef85ded74f03@github.com>

On Tue, 20 Dec 2022 04:49:46 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This update just follows the common pattern which was introduced about two years ago. At the moment I do not remember the exact reason. This code needs to wait for the counter to become zero and to use `ThreadBlockInVM` which can reach a safepoint in the destructor. Can we lock with a safepoint check in this case? Or we should get rid of the `ThreadBlockInVM` then?
>> I'll check if this can be fixed.
>
> This can be a separate RFE if the reason for it being a nosafepoint lock no longer holds. It would be cleaner to use a normal safepoint checking lock than to artificially make the thread safepoint-safe before using it.

Agreed. I was thinking about a separate RFE. I started seeing some failures in the S/R related tests with the removed `ThreadBlockInVM` and `_no_safepoint_check_flag`. Need to investigated why. Otherwise, it seems to be working well.

-------------

PR: https://git.openjdk.org/jdk/pull/11690

From jsjolen at openjdk.org  Tue Dec 20 10:28:49 2022
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 20 Dec 2022 10:28:49 GMT
Subject: RFR: 8295974: jni_FatalError and Xcheck:jni warnings should print
 the native stack when there are no Java frames
In-Reply-To: <s_Ttmm80UcUu6OOWSZKD95u18WWZufwlMKPW-Gw9ZeE=.b77b8d96-8249-4754-8a0f-1bcf032f465c@github.com>
References: <s_Ttmm80UcUu6OOWSZKD95u18WWZufwlMKPW-Gw9ZeE=.b77b8d96-8249-4754-8a0f-1bcf032f465c@github.com>
Message-ID: <5hEjPx0QqT-2U_vPwGfteQa49LpP3eGJbffRcaoqqpk=.e341140c-ea7b-4278-8994-0773230834e5@github.com>

On Fri, 16 Dec 2022 07:07:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

> If a JNI Fatal error, or a JNI warning (from Xcheck:jni) is triggered in "top-level" native code (such as the launcher itself, or a freshly attached native thread) then there is no stack printed as there are no Java frames. This enhancement changes that so that we print the native stack, similarly to how error reporting does. We reuse VMError::print_native _stack to do this, but it could be argued this should be moved to a more general purpose utility class - suggestions welcome.
> 
> Testing:
>   - manual fault injection (see bug report)
>   - tiers 1-4
> 
> Thanks.

Hi David, the change looks good to me. Is there a particular reason that you chose resource allocation here instead of allocating the buffer on the stack? It should have the same effect.

-------------

PR: https://git.openjdk.org/jdk/pull/11703

From mgronlun at openjdk.org  Tue Dec 20 10:51:51 2022
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 20 Dec 2022 10:51:51 GMT
Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC
In-Reply-To: <QsUxGjoDzTsb9KLkbFEL-fQdZRnw4ZrAExaGUiRQGcU=.0f8752e2-5601-494a-bebb-e122c0913392@github.com>
References: <BOJ4yH2GtNWXDVXMKwPw9Ic359dnBK8Sb9tDw3a5Qmc=.197acbb0-3ed6-418f-8bcf-70ef4b67de5e@github.com>
 <DoeGqI3dKcTxKkYV4z4WoW4yn7Dsg9ff3h0OSKn2sO4=.d388419e-885e-48be-aca8-15499595c37d@github.com>
 <ClmBO8J6cf-3JopE7sUBDdtbknhaV6zML8mD5TvEeNw=.c69531d8-083a-4a31-bc29-82b995df7af3@github.com>
 <wZO4SEsBHqM8TkUDmZiTxrB5nLK0Of3qYt2dNIWDDaQ=.81584eaf-355d-4eb1-b884-50f43c03878c@github.com>
 <QsUxGjoDzTsb9KLkbFEL-fQdZRnw4ZrAExaGUiRQGcU=.0f8752e2-5601-494a-bebb-e122c0913392@github.com>
Message-ID: <hfg7v4DLTiuIAZP0UHPr7o-__sAwyoJyVt2MsA-s1M4=.fb03c389-0961-450f-ab91-14708f718083@github.com>

On Tue, 20 Dec 2022 10:05:05 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> In my proposed solution there is no association to the event type. We just say the stack shouldn't be parsed during stack watermark processing, whatever events might be interested in doing so.

How would this relate to asynchronous stackwalking? I assume the solution involves not setting the ljf? What if another thread, for example the JFR Sampler Thread interrupts and walks the stack? It will use the CPU context, not the ljf.

-------------

PR: https://git.openjdk.org/jdk/pull/11586

From eosterlund at openjdk.org  Tue Dec 20 11:09:53 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 20 Dec 2022 11:09:53 GMT
Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC
In-Reply-To: <hfg7v4DLTiuIAZP0UHPr7o-__sAwyoJyVt2MsA-s1M4=.fb03c389-0961-450f-ab91-14708f718083@github.com>
References: <BOJ4yH2GtNWXDVXMKwPw9Ic359dnBK8Sb9tDw3a5Qmc=.197acbb0-3ed6-418f-8bcf-70ef4b67de5e@github.com>
 <DoeGqI3dKcTxKkYV4z4WoW4yn7Dsg9ff3h0OSKn2sO4=.d388419e-885e-48be-aca8-15499595c37d@github.com>
 <ClmBO8J6cf-3JopE7sUBDdtbknhaV6zML8mD5TvEeNw=.c69531d8-083a-4a31-bc29-82b995df7af3@github.com>
 <wZO4SEsBHqM8TkUDmZiTxrB5nLK0Of3qYt2dNIWDDaQ=.81584eaf-355d-4eb1-b884-50f43c03878c@github.com>
 <QsUxGjoDzTsb9KLkbFEL-fQdZRnw4ZrAExaGUiRQGcU=.0f8752e2-5601-494a-bebb-e122c0913392@github.com>
 <hfg7v4DLTiuIAZP0UHPr7o-__sAwyoJyVt2MsA-s1M4=.fb03c389-0961-450f-ab91-14708f718083@github.com>
Message-ID: <L7fSBllj00FO35kB_BUv5ZFqSKPXZ6ntA1RdDA_WBZc=.21c5bc7c-9ddb-4374-9beb-f6a07d7b0fb7@github.com>

On Tue, 20 Dec 2022 10:49:32 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> > In my proposed solution there is no association to the event type. We just say the stack shouldn't be parsed during stack watermark processing, whatever events might be interested in doing so.
> 
> 
> 
> How would this relate to asynchronous stackwalking? I assume the solution involves not setting the ljf? What if another thread, for example the JFR Sampler Thread interrupts and walks the stack? It will use the CPU context, not the ljf.

Does async profiling walk continuations? I would assume not.

-------------

PR: https://git.openjdk.org/jdk/pull/11586

From jwilhelm at openjdk.org  Tue Dec 20 11:13:46 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 20 Dec 2022 11:13:46 GMT
Subject: RFR: Merge jdk20
Message-ID: <m3v45C3WNjtXMERnETYkUxK26uH2AXGrUHf64gA4IQo=.265ed2e3-2da7-4bdc-9fe0-e20d69a6d437@github.com>

Forwardport JDK 20 -> JDK 21

-------------

Commit messages:
 - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20
 - 8298784: JFR: Test chunk integrity
 - 8298215: gc/g1/TestVerifyGCType.java failed with "Missing expected verification pattern Verifying After GC for: Pause Young (Prepare Mixed): expected true, was false"
 - 4958969: ObjectOutputStream example leads to non-working code
 - 8298699: java/lang/reflect/IllegalArgumentsTest.java times out with slowdebug bits
 - 4512626: Non-editable JTextArea provides no visual indication of keyboard focus
 - 8277074: Qualified exported types show up in JavaDoc
 - 8298894: java/lang/Thread/virtual/stress/Skynet.java timed out and threw OutOfMemoryError
 - 8298987: ProblemList jdk/internal/vm/Continuation/Fuzz.java#default with ZGC on X64
 - 8298905: Test "java/awt/print/PrinterJob/ImagePrinting/PrintARGBImage.java" fails because the frames of instruction does not display
 - ... and 6 more: https://git.openjdk.org/jdk/compare/36de61c4...d70f5831

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=11739&range=00.0
 - jdk20: https://webrevs.openjdk.org/?repo=jdk&pr=11739&range=00.1

Changes: https://git.openjdk.org/jdk/pull/11739/files
  Stats: 2286 lines in 125 files changed: 1286 ins; 609 del; 391 mod
  Patch: https://git.openjdk.org/jdk/pull/11739.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11739/head:pull/11739

PR: https://git.openjdk.org/jdk/pull/11739

From mgronlun at openjdk.org  Tue Dec 20 11:19:51 2022
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 20 Dec 2022 11:19:51 GMT
Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC
In-Reply-To: <BOJ4yH2GtNWXDVXMKwPw9Ic359dnBK8Sb9tDw3a5Qmc=.197acbb0-3ed6-418f-8bcf-70ef4b67de5e@github.com>
References: <BOJ4yH2GtNWXDVXMKwPw9Ic359dnBK8Sb9tDw3a5Qmc=.197acbb0-3ed6-418f-8bcf-70ef4b67de5e@github.com>
Message-ID: <H1CUu7ch-7UjQgqA9dYmlxPUW7xvC4PcUcGyTLtrgXw=.4a3fc244-4328-443d-a5d3-b8ada6af93f5@github.com>

On Thu, 8 Dec 2022 11:23:57 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The JfrVFrameStream is used while generating stack traces for events. One of the events are the ZPage allocation event. This event is sometimes sent when ZGC is relocating. The current implementation of JfrVFrameStream uses WalkContinuation::include, which causes JFR to walk the continuation and perform GC barriers. This is problematic, since ZGC has a requirement that we never perform load barriers while running the relocation code. If we do, we might end up performing other reloctions from the the relocation code, and in some cases that causes dead locks.
> 
> I propose that JFR doesn't walk the continuations when sending events. An alternative could be to limit this to ZGC, but I'd like to get some feedback around that from JFR / Loom devs.
> 
> We've been testing this patch in the Generational ZGC repository.

Why would it not?

-------------

PR: https://git.openjdk.org/jdk/pull/11586

From mgronlun at openjdk.org  Tue Dec 20 11:24:49 2022
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 20 Dec 2022 11:24:49 GMT
Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC
In-Reply-To: <L7fSBllj00FO35kB_BUv5ZFqSKPXZ6ntA1RdDA_WBZc=.21c5bc7c-9ddb-4374-9beb-f6a07d7b0fb7@github.com>
References: <BOJ4yH2GtNWXDVXMKwPw9Ic359dnBK8Sb9tDw3a5Qmc=.197acbb0-3ed6-418f-8bcf-70ef4b67de5e@github.com>
 <DoeGqI3dKcTxKkYV4z4WoW4yn7Dsg9ff3h0OSKn2sO4=.d388419e-885e-48be-aca8-15499595c37d@github.com>
 <ClmBO8J6cf-3JopE7sUBDdtbknhaV6zML8mD5TvEeNw=.c69531d8-083a-4a31-bc29-82b995df7af3@github.com>
 <wZO4SEsBHqM8TkUDmZiTxrB5nLK0Of3qYt2dNIWDDaQ=.81584eaf-355d-4eb1-b884-50f43c03878c@github.com>
 <QsUxGjoDzTsb9KLkbFEL-fQdZRnw4ZrAExaGUiRQGcU=.0f8752e2-5601-494a-bebb-e122c0913392@github.com>
 <hfg7v4DLTiuIAZP0UHPr7o-__sAwyoJyVt2MsA-s1M4=.fb03c389-0961-450f-ab91-14708f718083@github.com>
 <L7fSBllj00FO35kB_BUv5ZFqSKPXZ6ntA1RdDA_WBZc=.21c5bc7c-9ddb-4374-9beb-f6a07d7b0fb7@github.com>
Message-ID: <kaFEzNVtjolbrpBKZ2bK878bhAAVsGYtTMpT1STEvEA=.b5493b92-bc40-44e4-9c50-8e7c0a2141ca@github.com>

On Tue, 20 Dec 2022 11:07:18 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> > > In my proposed solution there is no association to the event type. We just say the stack shouldn't be parsed during stack watermark processing, whatever events might be interested in doing so.
> > 
> > 
> > How would this relate to asynchronous stackwalking? I assume the solution involves not setting the ljf? What if another thread, for example the JFR Sampler Thread interrupts and walks the stack? It will use the CPU context, not the ljf.
> 
> Does async profiling walk continuations? I would assume not.


JfrVframeStream::JfrVframeStream(JavaThread* jt, const frame& fr, bool stop_at_java_call_stub, bool async_mode) :   vframeStreamCommon(RegisterMap(jt,
                                 RegisterMap::UpdateMap::skip,
                                 RegisterMap::ProcessFrames::skip,
                                 RegisterMap::WalkContinuation::include)),

-------------

PR: https://git.openjdk.org/jdk/pull/11586

From eosterlund at openjdk.org  Tue Dec 20 11:32:49 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 20 Dec 2022 11:32:49 GMT
Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC
In-Reply-To: <kaFEzNVtjolbrpBKZ2bK878bhAAVsGYtTMpT1STEvEA=.b5493b92-bc40-44e4-9c50-8e7c0a2141ca@github.com>
References: <BOJ4yH2GtNWXDVXMKwPw9Ic359dnBK8Sb9tDw3a5Qmc=.197acbb0-3ed6-418f-8bcf-70ef4b67de5e@github.com>
 <DoeGqI3dKcTxKkYV4z4WoW4yn7Dsg9ff3h0OSKn2sO4=.d388419e-885e-48be-aca8-15499595c37d@github.com>
 <ClmBO8J6cf-3JopE7sUBDdtbknhaV6zML8mD5TvEeNw=.c69531d8-083a-4a31-bc29-82b995df7af3@github.com>
 <wZO4SEsBHqM8TkUDmZiTxrB5nLK0Of3qYt2dNIWDDaQ=.81584eaf-355d-4eb1-b884-50f43c03878c@github.com>
 <QsUxGjoDzTsb9KLkbFEL-fQdZRnw4ZrAExaGUiRQGcU=.0f8752e2-5601-494a-bebb-e122c0913392@github.com>
 <hfg7v4DLTiuIAZP0UHPr7o-__sAwyoJyVt2MsA-s1M4=.fb03c389-0961-450f-ab91-14708f718083@github.com>
 <L7fSBllj00FO35kB_BUv5ZFqSKPXZ6ntA1RdDA_WBZc=.21c5bc7c-9ddb-4374-9beb-f6a07d7b0fb7@github.com>
 <kaFEzNVtjolbrpBKZ2bK878bhAAVsGYtTMpT1STEvEA=.b5493b92-bc40-44e4-9c50-8e7c0a2141ca@github.com>
Message-ID: <GOnvDbiDLY4vjJPByTk8vOK8MNPRal9nv0s-0gd8Mi8=.606d08a8-0914-4e9d-b6b5-031e21be7771@github.com>

On Tue, 20 Dec 2022 11:22:07 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> > > > In my proposed solution there is no association to the event type. We just say the stack shouldn't be parsed during stack watermark processing, whatever events might be interested in doing so.
> 
> > > 
> 
> > > 
> 
> > > How would this relate to asynchronous stackwalking? I assume the solution involves not setting the ljf? What if another thread, for example the JFR Sampler Thread interrupts and walks the stack? It will use the CPU context, not the ljf.
> 
> > 
> 
> > Does async profiling walk continuations? I would assume not.
> 
> 
> 
> ```
> 
> JfrVframeStream::JfrVframeStream(JavaThread* jt, const frame& fr, bool stop_at_java_call_stub, bool async_mode) :   vframeStreamCommon(RegisterMap(jt,
> 
>                                  RegisterMap::UpdateMap::skip,
> 
>                                  RegisterMap::ProcessFrames::skip,
> 
>                                  RegisterMap::WalkContinuation::include)),
> 
> ```

If the JFR sampler thread calls start_processing while locking out safepoints, the async stack walk should be fine. We would know the continuation oop is fixed then.

-------------

PR: https://git.openjdk.org/jdk/pull/11586

From mgronlun at openjdk.org  Tue Dec 20 11:32:50 2022
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 20 Dec 2022 11:32:50 GMT
Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC
In-Reply-To: <GOnvDbiDLY4vjJPByTk8vOK8MNPRal9nv0s-0gd8Mi8=.606d08a8-0914-4e9d-b6b5-031e21be7771@github.com>
References: <BOJ4yH2GtNWXDVXMKwPw9Ic359dnBK8Sb9tDw3a5Qmc=.197acbb0-3ed6-418f-8bcf-70ef4b67de5e@github.com>
 <DoeGqI3dKcTxKkYV4z4WoW4yn7Dsg9ff3h0OSKn2sO4=.d388419e-885e-48be-aca8-15499595c37d@github.com>
 <ClmBO8J6cf-3JopE7sUBDdtbknhaV6zML8mD5TvEeNw=.c69531d8-083a-4a31-bc29-82b995df7af3@github.com>
 <wZO4SEsBHqM8TkUDmZiTxrB5nLK0Of3qYt2dNIWDDaQ=.81584eaf-355d-4eb1-b884-50f43c03878c@github.com>
 <QsUxGjoDzTsb9KLkbFEL-fQdZRnw4ZrAExaGUiRQGcU=.0f8752e2-5601-494a-bebb-e122c0913392@github.com>
 <hfg7v4DLTiuIAZP0UHPr7o-__sAwyoJyVt2MsA-s1M4=.fb03c389-0961-450f-ab91-14708f718083@github.com>
 <L7fSBllj00FO35kB_BUv5ZFqSKPXZ6ntA1RdDA_WBZc=.21c5bc7c-9ddb-4374-9beb-f6a07d7b0fb7@github.com>
 <kaFEzNVtjolbrpBKZ2bK878bhAAVsGYtTMpT1STEvEA=.b5493b92-bc40-44e4-9c50-8e7c0a2141ca@github.com>
 <GOnvDbiDLY4vjJPByTk8vOK8MNPRal9nv0s-0gd8Mi8=.606d08a8-0914-4e9d-b6b5-031e21be7771@github.com>
Message-ID: <XMRyTz9onryRvKdVyd66yiCqbrfDkcf8Kk5p5wrn8hY=.36847d0d-9df5-4e53-98bd-2849619c761f@github.com>

On Tue, 20 Dec 2022 11:26:27 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> > > > > In my proposed solution there is no association to the event type. We just say the stack shouldn't be parsed during stack watermark processing, whatever events might be interested in doing so.
> > 
> > 
> > > >
> > 
> > 
> > > >
> > 
> > 
> > > > How would this relate to asynchronous stackwalking? I assume the solution involves not setting the ljf? What if another thread, for example the JFR Sampler Thread interrupts and walks the stack? It will use the CPU context, not the ljf.
> > 
> > 
> > > 
> > 
> > 
> > > Does async profiling walk continuations? I would assume not.
> > 
> > 
> > ```
> > 
> > JfrVframeStream::JfrVframeStream(JavaThread* jt, const frame& fr, bool stop_at_java_call_stub, bool async_mode) :   vframeStreamCommon(RegisterMap(jt,
> > 
> >                                  RegisterMap::UpdateMap::skip,
> > 
> >                                  RegisterMap::ProcessFrames::skip,
> > 
> >                                  RegisterMap::WalkContinuation::include)),
> > ```
> 
> If the JFR sampler thread calls start_processing while locking out safepoints, the async stack walk should be fine. We would know the continuation oop is fixed then.

Great - it is, it is holding the Threads_lock

-------------

PR: https://git.openjdk.org/jdk/pull/11586

From eosterlund at openjdk.org  Tue Dec 20 11:32:50 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 20 Dec 2022 11:32:50 GMT
Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC
In-Reply-To: <XMRyTz9onryRvKdVyd66yiCqbrfDkcf8Kk5p5wrn8hY=.36847d0d-9df5-4e53-98bd-2849619c761f@github.com>
References: <BOJ4yH2GtNWXDVXMKwPw9Ic359dnBK8Sb9tDw3a5Qmc=.197acbb0-3ed6-418f-8bcf-70ef4b67de5e@github.com>
 <DoeGqI3dKcTxKkYV4z4WoW4yn7Dsg9ff3h0OSKn2sO4=.d388419e-885e-48be-aca8-15499595c37d@github.com>
 <ClmBO8J6cf-3JopE7sUBDdtbknhaV6zML8mD5TvEeNw=.c69531d8-083a-4a31-bc29-82b995df7af3@github.com>
 <wZO4SEsBHqM8TkUDmZiTxrB5nLK0Of3qYt2dNIWDDaQ=.81584eaf-355d-4eb1-b884-50f43c03878c@github.com>
 <QsUxGjoDzTsb9KLkbFEL-fQdZRnw4ZrAExaGUiRQGcU=.0f8752e2-5601-494a-bebb-e122c0913392@github.com>
 <hfg7v4DLTiuIAZP0UHPr7o-__sAwyoJyVt2MsA-s1M4=.fb03c389-0961-450f-ab91-14708f718083@github.com>
 <L7fSBllj00FO35kB_BUv5ZFqSKPXZ6ntA1RdDA_WBZc=.21c5bc7c-9ddb-4374-9beb-f6a07d7b0fb7@github.com>
 <kaFEzNVtjolbrpBKZ2bK878bhAAVsGYtTMpT1STEvEA=.b5493b92-bc40-44e4-9c50-8e7c0a2141ca@github.com>
 <GOnvDbiDLY4vjJPByTk8vOK8MNPRal9nv0s-0gd8Mi8=.606d08a8-0914-4e9d-b6b5-031e21be7771@github.com>
 <XMRyTz9onryRvKdVyd66yiCqbrfDkcf8Kk5p5wrn8hY=.36847d0d-9df5-4e53-98bd-2849619c761f@github.com>
Message-ID: <tS9AwKeGg3e9yfx7YZJdC-3wchVvK2DXy8YLoEuH50Q=.fbf322ea-3c3a-4973-9594-ed26e2e89964@github.com>

On Tue, 20 Dec 2022 11:28:08 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> > > > > > In my proposed solution there is no association to the event type. We just say the stack shouldn't be parsed during stack watermark processing, whatever events might be interested in doing so.
> 
> > > 
> 
> > > 
> 
> > > > >
> 
> > > 
> 
> > > 
> 
> > > > >
> 
> > > 
> 
> > > 
> 
> > > > > How would this relate to asynchronous stackwalking? I assume the solution involves not setting the ljf? What if another thread, for example the JFR Sampler Thread interrupts and walks the stack? It will use the CPU context, not the ljf.
> 
> > > 
> 
> > > 
> 
> > > > 
> 
> > > 
> 
> > > 
> 
> > > > Does async profiling walk continuations? I would assume not.
> 
> > > 
> 
> > > 
> 
> > > ```
> 
> > > 
> 
> > > JfrVframeStream::JfrVframeStream(JavaThread* jt, const frame& fr, bool stop_at_java_call_stub, bool async_mode) :   vframeStreamCommon(RegisterMap(jt,
> 
> > > 
> 
> > >                                  RegisterMap::UpdateMap::skip,
> 
> > > 
> 
> > >                                  RegisterMap::ProcessFrames::skip,
> 
> > > 
> 
> > >                                  RegisterMap::WalkContinuation::include)),
> 
> > > ```
> 
> > 
> 
> > If the JFR sampler thread calls start_processing while locking out safepoints, the async stack walk should be fine. We would know the continuation oop is fixed then.
> 
> 
> 
> Great - it is, it is holding the Threads_lock

Great. Sounds like we have a plan. I will create a patch.

-------------

PR: https://git.openjdk.org/jdk/pull/11586

From jwilhelm at openjdk.org  Tue Dec 20 11:47:31 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 20 Dec 2022 11:47:31 GMT
Subject: RFR: Merge jdk20 [v2]
In-Reply-To: <m3v45C3WNjtXMERnETYkUxK26uH2AXGrUHf64gA4IQo=.265ed2e3-2da7-4bdc-9fe0-e20d69a6d437@github.com>
References: <m3v45C3WNjtXMERnETYkUxK26uH2AXGrUHf64gA4IQo=.265ed2e3-2da7-4bdc-9fe0-e20d69a6d437@github.com>
Message-ID: <FnOGkSoOkKJfJ5JjgZo7uwEF2JILRWkjhHgWx1sprIc=.38ff283a-01ab-401c-9411-f0d8c86702b6@github.com>

> Forwardport JDK 20 -> JDK 21

Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 107 commits:

 - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20
 - 8298865: Excessive memory allocation in CipherOutputStream AEAD decryption
   
   Reviewed-by: valeriep, ascarpino
 - 8299043: test/jdk/javax/swing/AbstractButton/5049549/bug5049549.java fails with java.lang.NullPointerException
   
   Reviewed-by: serb
 - 8298974: Add ftcolor.c to imported freetype sources
   
   Reviewed-by: serb
 - 8299044: test/jdk/javax/swing/JComboBox/JComboBoxBorderTest.java fails on non mac
   
   Reviewed-by: serb, honkar
 - 8299045: tools/doclint/BadPackageCommentTest.java fails after JDK-8298943
   
   Reviewed-by: vromero
 - 8298943: Missing escapes for single quote marks in compiler.properties
   
   Reviewed-by: jjg
 - 8298701: Cleanup SA entries in ProblemList-zgc.txt.
   
   Reviewed-by: sspitsyn, amenkov
 - 8298470: Short cut java.lang.Object super class loading
   
   Reviewed-by: dholmes, iklam
 - 8299022: Linux ppc64le and s390x build issues after JDK-8160404
   
   Reviewed-by: mdoerr, lucy
 - ... and 97 more: https://git.openjdk.org/jdk/compare/3dd2cfab...d70f5831

-------------

Changes: https://git.openjdk.org/jdk/pull/11739/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11739&range=01
  Stats: 13539 lines in 425 files changed: 8409 ins; 3097 del; 2033 mod
  Patch: https://git.openjdk.org/jdk/pull/11739.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11739/head:pull/11739

PR: https://git.openjdk.org/jdk/pull/11739

From jwilhelm at openjdk.org  Tue Dec 20 11:47:33 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 20 Dec 2022 11:47:33 GMT
Subject: Integrated: Merge jdk20
In-Reply-To: <m3v45C3WNjtXMERnETYkUxK26uH2AXGrUHf64gA4IQo=.265ed2e3-2da7-4bdc-9fe0-e20d69a6d437@github.com>
References: <m3v45C3WNjtXMERnETYkUxK26uH2AXGrUHf64gA4IQo=.265ed2e3-2da7-4bdc-9fe0-e20d69a6d437@github.com>
Message-ID: <pk7xFH2bCEPTLw_KlI3RkDUTMMlze8j0j2fNKoqnm5Q=.49972633-6c2a-41af-be30-114c9f119772@github.com>

On Tue, 20 Dec 2022 10:57:44 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 20 -> JDK 21

This pull request has now been integrated.

Changeset: c5a4a7a6
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c5a4a7a679ec76cb08a999a198e5c73e9cd9d2f0
Stats:     2286 lines in 125 files changed: 1286 ins; 609 del; 391 mod

Merge

-------------

PR: https://git.openjdk.org/jdk/pull/11739

From aboldtch at openjdk.org  Tue Dec 20 11:53:27 2022
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 20 Dec 2022 11:53:27 GMT
Subject: RFR: 8299089: Instrument global jni handles with tag to make them
 distinguishable
Message-ID: <dHb4TMxgR1O4h2v2LXkpx1rSwk6SLqr-4do-e8KbLfY=.b4c32322-7cb6-42c4-bc21-e338cfcade31@github.com>

Weak global jni handles are tagged so the GC can distinguish them when resolving the object. Today there is no cheap way of distinguishing global jni handles from local jni handles. For generational ZGC the OopStorage handles and the thread local handles semantical difference requires the handles to be distinguishable. 

This enhancements instruments the jni handles with a global tag similarly to the jweak tag. 

Note: 
 * the s390 implementation has minimal changes and requires improvement.
 * There is room for enchantment here to create the same abstraction that ppc uses for all platforms, i.e. move the resolve_jobject from the MacroAssembler to the BarrierSetAssembler which allows for more optimised code for GCs that can treat local and global handles the same. 

Testing: GHA. Oracle supported platforms tier1-3. Will run higher tiers. Has also been tested on the generational branch of ZGC for over three months. Requires testing on non Oracle platforms.

-------------

Commit messages:
 - UPSTREAM: JNI Global Handle Non Oracle Platforms
 - UPSTREAM: JNI Global Handle Change

Changes: https://git.openjdk.org/jdk/pull/11740/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11740&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299089
  Stats: 453 lines in 35 files changed: 300 ins; 57 del; 96 mod
  Patch: https://git.openjdk.org/jdk/pull/11740.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11740/head:pull/11740

PR: https://git.openjdk.org/jdk/pull/11740

From aboldtch at openjdk.org  Tue Dec 20 14:59:55 2022
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 20 Dec 2022 14:59:55 GMT
Subject: RFR: 8296469: Instrument VMError::report with reentrant iteration
 step for register and stack printing [v4]
In-Reply-To: <s2wlyE6OjqTazCsro-keOXqXvYMqwHEp8YdMZhCdQXs=.37245c9a-5891-42b8-b961-55d1a7a30af5@github.com>
References: <s2wlyE6OjqTazCsro-keOXqXvYMqwHEp8YdMZhCdQXs=.37245c9a-5891-42b8-b961-55d1a7a30af5@github.com>
Message-ID: <cJ_6RA48RtPHfb2IIT9RRQRIQ2LsDw_VmlKdBqMdEek=.bd2a232f-5a5f-41c9-bbd5-9bcc3b07dc91@github.com>

> Add reentrant step logic to VMError::report with an inner loop which enable the logic to recover at every step of the iteration.
> 
> Before this change, if printing one register/stack position crashes then no more registers/stack positions will be printed.
> 
> After this change even if the VM is unstable and some registers print_location crashes the hs_err printing will recover and keep attempting to print the rest of the registers or stack values.
> 
> Enables the following
> ```C++
> REENTRANT_STEP_IF("printing register info", _verbose && _context && _thread && Universe::is_fully_initialized())
>   os::print_register_info_header(st, _context);
> 
>   REENTRANT_LOOP_START(os::print_nth_register_info_max_index())
>     // decode register contents if possible
>     ResourceMark rm(_thread);
>     os::print_nth_register_info(st, REENTRANT_ITERATION_STEP, _context);
>   REENTRANT_LOOP_END
> 
>   st->cr();
> 
> 
> Testing: tier 1 and compiled Linux-x64/aarch64, MacOS-x64/aarch64, Windows x64 and cross-compiled Linux-x86/riscv/arm/ppc/s390x (GHA and some local)

Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Restructure os::print_register_info interface
 - Code syle and line length
 - Merge Fix
 - Merge remote-tracking branch 'upstream_jdk/master' into vmerror_report_register_stack_reentrant
 - Fix whitespace
 - Add reentrant reentry limits
 - Add os::print_register_info_header
 - VMError::report reentrant for register and stack print

-------------

Changes: https://git.openjdk.org/jdk/pull/11017/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11017&range=03
  Stats: 786 lines in 19 files changed: 488 ins; 88 del; 210 mod
  Patch: https://git.openjdk.org/jdk/pull/11017.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11017/head:pull/11017

PR: https://git.openjdk.org/jdk/pull/11017

From aboldtch at openjdk.org  Tue Dec 20 14:59:57 2022
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 20 Dec 2022 14:59:57 GMT
Subject: RFR: 8296469: Instrument VMError::report with reentrant iteration
 step for register and stack printing [v3]
In-Reply-To: <WlBdSGKAURXKFLdQuJn9-kcEf3HvMXC21j0PGW32tYE=.a97c9263-2236-4f7f-ac5b-ef0a98e0fccd@github.com>
References: <s2wlyE6OjqTazCsro-keOXqXvYMqwHEp8YdMZhCdQXs=.37245c9a-5891-42b8-b961-55d1a7a30af5@github.com>
 <WlBdSGKAURXKFLdQuJn9-kcEf3HvMXC21j0PGW32tYE=.a97c9263-2236-4f7f-ac5b-ef0a98e0fccd@github.com>
Message-ID: <LpHyoyA1blqffS7KgQk2ON3cdOVFVK1zKL0-Tq6tpm4=.e36e3341-9753-4776-ac1c-e6b9efb98153@github.com>

On Mon, 21 Nov 2022 06:01:46 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Add reentrant step logic to VMError::report with an inner loop which enable the logic to recover at every step of the iteration.
>> 
>> Before this change, if printing one register/stack position crashes then no more registers/stack positions will be printed.
>> 
>> After this change even if the VM is unstable and some registers print_location crashes the hs_err printing will recover and keep attempting to print the rest of the registers or stack values.
>> 
>> Enables the following
>> ```C++
>> REENTRANT_STEP_IF("printing register info", _verbose && _context && _thread && Universe::is_fully_initialized())
>>   os::print_register_info_header(st, _context);
>> 
>>   REENTRANT_LOOP_START(os::print_nth_register_info_max_index())
>>     // decode register contents if possible
>>     ResourceMark rm(_thread);
>>     os::print_nth_register_info(st, REENTRANT_ITERATION_STEP, _context);
>>   REENTRANT_LOOP_END
>> 
>>   st->cr();
>> 
>> 
>> Testing: tier 1 and compiled Linux-x64/aarch64, MacOS-x64/aarch64, Windows x64 and cross-compiled Linux-x86/riscv/arm/ppc/s390x (GHA and some local)
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix whitespace

Sorry for the late reply. Felt no need to push anything related to this into 20.

> > Added some limitations on reentry of a reentrant step. It will now break the inner loop if:
> > ```
> > * It is the fourth time reentering this step
> > 
> > * It is the eight time reentering any reentrant step
> > 
> > * The stack headroom is less than 64K
> > 
> > * A timeout has been issued
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > The post loop logic of a reentrant step is given another timeout window. Currently all it does is make sure there are line breaks after the step output, but I imagine this can be useful incase some reentrant step logic is used where the loop builds up some data structure and the post logic prints it.
> > All of the limit constants are just picked rather ad-hoc. Would be nice to have some extra feedback on this.
> 
> I think the approach is better, but I'm not a big fan of the broadened os interface and the fact that error-handling-specifics now leak into the os interface.
> 

I rewrote the code so the os interface is simply:
```c++
  static void print_register_info(outputStream* st, int n, const void* context);
  static int  printable_register_count();

It simply allows querying for how many printable registers there are and asking it to print a register's content on an outputStream given a context. I do not believe that any error handling specifics leaks into the interface, if anything it is more agnostic interface now. The previous `print_register_info` was written to output data which fits in with hs_err printing. This approach just prints one register's info followed by a newline.

> How about letting the print function fill in an opaque continuation object instead? Something like:
> 
> ```
> // Print register information; optionally re-startable. If (*continuation_info) is null,
> // register printing starts with the first register, otherwise beyond whatever point
> // it had been interrupted before.
> void os::print_register_info(const ucontext_t* context, outputStream* st, void** continuation_info);
> ```
> 
> `continuation_info` can have any shape or form the platform-specific implementation wants. It does not have to be visible or known on the outside. It can exist as a struct only in the os_xxx.cpp file. Or, the platform could just hide an integer in the pointer and use it as restart point.
> 
> The standard `os::print_register_info(const ucontext_t*, outputStream*)` can then be implemented with a dummy continuation info that does nothing:
> 
> ```
> os::print_register_info(const ucontext_t* c, outputStream* st) {
>   void* info;
>   os_print_register_info(c, st, &info);
> }
> ```
> 
> If that is too C-ish for you, there can be a C++ equivalent via runtime polymorphy. In any case, the charm would be that you can re-start register printing without having to know specific implementation details. You just hand in the continuation object. In a very primitive form, without the need for further STEP macros, that could even look like this:
> 
> ```
> void* print_reg_continuation_info = nullptr;
> ...
> STEP(print_register_info_attempt_1)
> { os::print_register_info(context, st, &print_reg_continuation_info); }
> STEP(print_register_info_attempt_2)
> { os::print_register_info(context, st, &print_reg_continuation_info); }
> STEP(print_register_info_attempt_3)
> { os::print_register_info(context, st, &print_reg_continuation_info); }
> ```
> 
> (for this simple approach to work, os::print_register_info() would have recognize a completed printing by the content of continuation info).
> 
> In theory, we could use a similar pattern for call stack printing too.
> 

The problem I see with this approach is that if the storage of the continuation must either be dynamic and managed or static and global. Both I do not think fit with error reporting. Dynamic has too many side effects and will be unstable. If the storage lives statically inside the os object file then we have a global state and the `os::print_register_info` will be locked to the error printing or some mechanism has to be added to manage the global state of the program if the `os::os::print_register_info` is to be used from any other location. It is possible to create some construct which can at least hold any platform specific construct and have the storage be inside `vmError`, but this solution is often ugly and hard to make work correctly with the C++ object model. 

Maybe there are different opinions here, but I think such an approach should be avoided as it is harder to reason about. 
I think that having a reentrant step with previously mentioned semantics is easier to reason about and read than having repeated code with some externally managed state. 

> As a side note, I have not been idle since print_register_info() not working bugs me too. I found that many reasons for it not working are caused by only a few bugs. oopDesc::print_on() could do a lot more error checking before printing Klass* for instance. And we also could do more error checking when printing object array elements. I have a patch open, but won't make it before JDK 20 freeze, and probably not before my holidays either. If someone else wants to do it, that would be fine with me too.
> 
> Cheers, Thomas

Sounds good. I will continue to monitor the progress on vmError. Will mostly be focusing on ZGC related issues for the coming months. But will be happy to review any PRs that improve the he_err printing.

-------------

PR: https://git.openjdk.org/jdk/pull/11017

From aboldtch at openjdk.org  Tue Dec 20 16:38:32 2022
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 20 Dec 2022 16:38:32 GMT
Subject: RFR: 8299125: UnifiedOopRef in JFR leakprofiler should treat thread
 local oops correctly
Message-ID: <rWycrBShM6izhFHt_--oBN7kgdhnYVDVUjUz_5hxd00=.2b6bf0af-18ec-43c2-9856-db6ce8ba2a43@github.com>

In a similar vain to [JDK-8299089](https://bugs.openjdk.org/browse/JDK-8299089) there are different semantics for OopStorage and thread local oops. UnifiedOopRef in the jfr leakprofiler must be able to distinguish these and treat them appropriately.

Testing: Running test at the moment. Has been running on the generational branch of ZGC for over three months. Not many tests exercise the leakprofiler. x86_32 has mostly been tested with GHA. 

Note: The accessBackend changes are only there to facilitate comparing OopLoadProxy objects directly with nullptr instead of creating and comparing with an `oop()` / `oop(NULL)`. Can be backed out of this PR and put in a different RFE instead.

-------------

Commit messages:
 - UPSTREAM: UnifiedOopRef changes

Changes: https://git.openjdk.org/jdk/pull/11741/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11741&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299125
  Stats: 100 lines in 4 files changed: 76 ins; 6 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/11741.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11741/head:pull/11741

PR: https://git.openjdk.org/jdk/pull/11741

From jwilhelm at openjdk.org  Tue Dec 20 19:49:09 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 20 Dec 2022 19:49:09 GMT
Subject: RFR: Merge jdk20
Message-ID: <f9m-NKslnFwzmaIBb3F-RVzKOtIQ-m45vsWvjMeeAFM=.75160a42-4482-44b9-bb25-bff6e4872e6f@github.com>

Forwardport JDK 20 -> JDK 21

-------------

Commit messages:
 - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20
 - 8299123: [BACKOUT] 4512626 Non-editable JTextArea provides no visual indication of keyboard focus
 - 8298162: Test PrintClasses hits assert when run with code that retransform classes
 - 8298061: vmTestbase/nsk/sysdict/vm/stress/btree/btree012/btree012.java failed with "fatal error: refcount has gone to zero"
 - 8298968: G1: Incorrect merged remset stats

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=11744&range=00.0
 - jdk20: https://webrevs.openjdk.org/?repo=jdk&pr=11744&range=00.1

Changes: https://git.openjdk.org/jdk/pull/11744/files
  Stats: 258 lines in 8 files changed: 75 ins; 61 del; 122 mod
  Patch: https://git.openjdk.org/jdk/pull/11744.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11744/head:pull/11744

PR: https://git.openjdk.org/jdk/pull/11744

From redestad at openjdk.org  Tue Dec 20 19:57:55 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 20 Dec 2022 19:57:55 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v13]
In-Reply-To: <_2HYrbXOe6zVuLXHywoy_AjCcGMYR266BcwKUZEA5fs=.1e6f7640-7580-4ff3-ace6-f18f27efbb23@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <pW8HHmh-dQnjrRftd052fBQVulqe_z5KldY76Hp-OmI=.a7a2b6e6-a182-45d2-bd11-16a406126482@github.com>
 <_2HYrbXOe6zVuLXHywoy_AjCcGMYR266BcwKUZEA5fs=.1e6f7640-7580-4ff3-ace6-f18f27efbb23@github.com>
Message-ID: <xEjDlEzYJlPt8HhGk9xE6z57yAwT246Nl0yNpMP3riI=.9aca27c6-348f-4ad2-bff3-4e0262053135@github.com>

On Fri, 16 Dec 2022 22:58:23 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Missing & 0xff in StringLatin1::hashCode
>
> src/hotspot/cpu/x86/vm_version_x86.cpp line 1671:
> 
>> 1669:   }
>> 1670:   if (UseAVX >= 2) {
>> 1671:     FLAG_SET_ERGO_IF_DEFAULT(UseVectorizedHashCodeIntrinsic, true);
> 
> This could be just FLAG_SET_DEFAULT instead of FLAG_SET_ERGO_IF_DEFAULT.

Right, it seems HW-dependent intrinsics in generally doesn't mark that they've been enabled ergonomically, rather just make it on "by default" when support is available.

> src/java.base/share/classes/java/lang/StringUTF16.java line 418:
> 
>> 416:             return 0;
>> 417:         } else {
>> 418:             return ArraysSupport.vectorizedHashCode(value, ArraysSupport.UTF16);
> 
> Special case for 1 missing here.

Intentionally left out. Array length is always even for `UTF16` arrays, but we could add a case for `2` that'd return `getChar(bytes, 0)` but I didn't see much of a win when I tested this.

-------------

PR: https://git.openjdk.org/jdk/pull/10847

From redestad at openjdk.org  Tue Dec 20 20:21:57 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 20 Dec 2022 20:21:57 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v13]
In-Reply-To: <_2HYrbXOe6zVuLXHywoy_AjCcGMYR266BcwKUZEA5fs=.1e6f7640-7580-4ff3-ace6-f18f27efbb23@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <pW8HHmh-dQnjrRftd052fBQVulqe_z5KldY76Hp-OmI=.a7a2b6e6-a182-45d2-bd11-16a406126482@github.com>
 <_2HYrbXOe6zVuLXHywoy_AjCcGMYR266BcwKUZEA5fs=.1e6f7640-7580-4ff3-ace6-f18f27efbb23@github.com>
Message-ID: <_h335iIGqDY-NVIC2k0TYzwb6gZS06ynM76d4-nJaUk=.eb491368-9c6f-4edd-8527-ef8f28c45d20@github.com>

On Fri, 16 Dec 2022 23:00:53 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Missing & 0xff in StringLatin1::hashCode
>
> src/hotspot/cpu/x86/stubRoutines_x86.cpp line 230:
> 
>> 228: #endif // _LP64
>> 229: 
>> 230: jint StubRoutines::x86::_arrays_hashcode_powers_of_31[] =
> 
> This should be declared only for LP64.

Hmm, I guess same goes for all the new `arrays_hashcode` methods in `c2_MacroAssembler_x86`, since we only wire this up properly on 64-bit. I'll make a pass to put `_LP64` guards around all new methods.

-------------

PR: https://git.openjdk.org/jdk/pull/10847

From jwilhelm at openjdk.org  Tue Dec 20 20:25:54 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 20 Dec 2022 20:25:54 GMT
Subject: Integrated: Merge jdk20
In-Reply-To: <f9m-NKslnFwzmaIBb3F-RVzKOtIQ-m45vsWvjMeeAFM=.75160a42-4482-44b9-bb25-bff6e4872e6f@github.com>
References: <f9m-NKslnFwzmaIBb3F-RVzKOtIQ-m45vsWvjMeeAFM=.75160a42-4482-44b9-bb25-bff6e4872e6f@github.com>
Message-ID: <50b6om_LcOMPSvd_OGuo2sXmamBxtL1AQo5kVQ7-nUE=.23a2bb67-52c6-4e68-98b9-7cad6e675883@github.com>

On Tue, 20 Dec 2022 19:41:28 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 20 -> JDK 21

This pull request has now been integrated.

Changeset: 386db071
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/386db07143883f85307138eca2f0305d997a2171
Stats:     258 lines in 8 files changed: 75 ins; 61 del; 122 mod

Merge

-------------

PR: https://git.openjdk.org/jdk/pull/11744

From sspitsyn at openjdk.org  Tue Dec 20 20:52:10 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 20 Dec 2022 20:52:10 GMT
Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling
 one virtual thread transitions [v3]
In-Reply-To: <z8NCIbPeF0WzTEzXGyNxlnuOF_52vbV90p4B15xThFk=.b12cfe49-d27d-4e65-9027-796985005c14@github.com>
References: <z8NCIbPeF0WzTEzXGyNxlnuOF_52vbV90p4B15xThFk=.b12cfe49-d27d-4e65-9027-796985005c14@github.com>
Message-ID: <FDyv8oX5HVbkRMGV2q86Zv5iRrNEf4YQ0J2RbwxE4aU=.7457681a-5149-4fa2-baaf-15484a58f267@github.com>

> Now the `JvmtiVTMSTransitionDisabler` mechanism supports disabling VTMS transitions for all virtual threads only. It should also support disabling transitions for any specific virtual thread as well. This will improve scalability of the JVMTI functions operating on target virtual threads as the functions can be executed concurrently without blocking each other execution when target virtual threads are different.
> New constructor `JvmtiVTMSTransitionDisabler(jthread vthread)` is added which has jthread parameter of the target virtual thread.
> 
> Testing:
>   mach5 jobs are TBD (preliminary testing was completed):
>    - all JVMTI, JDWP, JDI and JDB tests have to be run
>    - Kitchensink
>    - tier5

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  address wqsecond round review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11690/files
  - new: https://git.openjdk.org/jdk/pull/11690/files/2603eebb..7783992f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11690&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11690&range=01-02

  Stats: 15 lines in 3 files changed: 2 ins; 0 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/11690.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11690/head:pull/11690

PR: https://git.openjdk.org/jdk/pull/11690

From redestad at openjdk.org  Tue Dec 20 21:11:40 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 20 Dec 2022 21:11:40 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v14]
In-Reply-To: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
Message-ID: <fU9foJNSAmSImvl8PN0di4DTJc30iMSaOAPPf0tm290=.95de7241-ea06-4a51-9c5e-c3acf260f83f@github.com>

> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops.
> 
> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases.
> 
> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front.
> 
> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads.
> 
> With the most recent fixes the x64 intrinsic results on my workstation look like this:
> 
> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.199 ?  0.017  ns/op
> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     6.933 ?  0.049  ns/op
> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    29.935 ?  0.221  ns/op
> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  1596.982 ?  7.020  ns/op
> 
> Baseline:
> 
> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.200 ?  0.013  ns/op
> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     9.424 ?  0.122  ns/op
> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    90.541 ?  0.512  ns/op
> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  9425.321 ? 67.630  ns/op
> 
> I.e. no measurable overhead compared to baseline even for `size == 1`.
> 
> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good.
> 
> Benchmark for `Arrays.hashCode`:
> 
> Benchmark              (size)  Mode  Cnt     Score    Error  Units
> ArraysHashCode.bytes        1  avgt    5     1.884 ?  0.013  ns/op
> ArraysHashCode.bytes       10  avgt    5     6.955 ?  0.040  ns/op
> ArraysHashCode.bytes      100  avgt    5    87.218 ?  0.595  ns/op
> ArraysHashCode.bytes    10000  avgt    5  9419.591 ? 38.308  ns/op
> ArraysHashCode.chars        1  avgt    5     2.200 ?  0.010  ns/op
> ArraysHashCode.chars       10  avgt    5     6.935 ?  0.034  ns/op
> ArraysHashCode.chars      100  avgt    5    30.216 ?  0.134  ns/op
> ArraysHashCode.chars    10000  avgt    5  1601.629 ?  6.418  ns/op
> ArraysHashCode.ints         1  avgt    5     2.200 ?  0.007  ns/op
> ArraysHashCode.ints        10  avgt    5     6.936 ?  0.034  ns/op
> ArraysHashCode.ints       100  avgt    5    29.412 ?  0.268  ns/op
> ArraysHashCode.ints     10000  avgt    5  1610.578 ?  7.785  ns/op
> ArraysHashCode.shorts       1  avgt    5     1.885 ?  0.012  ns/op
> ArraysHashCode.shorts      10  avgt    5     6.961 ?  0.034  ns/op
> ArraysHashCode.shorts     100  avgt    5    87.095 ?  0.417  ns/op
> ArraysHashCode.shorts   10000  avgt    5  9420.617 ? 50.089  ns/op
> 
> Baseline:
> 
> Benchmark              (size)  Mode  Cnt     Score    Error  Units
> ArraysHashCode.bytes        1  avgt    5     3.213 ?  0.207  ns/op
> ArraysHashCode.bytes       10  avgt    5     8.483 ?  0.040  ns/op
> ArraysHashCode.bytes      100  avgt    5    90.315 ?  0.655  ns/op
> ArraysHashCode.bytes    10000  avgt    5  9422.094 ? 62.402  ns/op
> ArraysHashCode.chars        1  avgt    5     3.040 ?  0.066  ns/op
> ArraysHashCode.chars       10  avgt    5     8.497 ?  0.074  ns/op
> ArraysHashCode.chars      100  avgt    5    90.074 ?  0.387  ns/op
> ArraysHashCode.chars    10000  avgt    5  9420.474 ? 41.619  ns/op
> ArraysHashCode.ints         1  avgt    5     2.827 ?  0.019  ns/op
> ArraysHashCode.ints        10  avgt    5     7.727 ?  0.043  ns/op
> ArraysHashCode.ints       100  avgt    5    89.405 ?  0.593  ns/op
> ArraysHashCode.ints     10000  avgt    5  9426.539 ? 51.308  ns/op
> ArraysHashCode.shorts       1  avgt    5     3.071 ?  0.062  ns/op
> ArraysHashCode.shorts      10  avgt    5     8.168 ?  0.049  ns/op
> ArraysHashCode.shorts     100  avgt    5    90.399 ?  0.292  ns/op
> ArraysHashCode.shorts   10000  avgt    5  9420.171 ? 44.474  ns/op
> 
> 
> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement.

Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 64 commits:

 - Pass the constant mode node through, removing need for all but one instruct declarations
 - FLAG_SET_DEFAULT
 - Merge branch 'master' into 8282664-polyhash
 - Merge branch 'master' into 8282664-polyhash
 - Missing & 0xff in StringLatin1::hashCode
 - Qualified guess on shenandoahSupport fix-up
 - Whitespace
 - Final touch-ups, restored 2-stride with dependency chain breakage
 - Minor cleanup
 - Revert accidental ModuleHashes change
 - ... and 54 more: https://git.openjdk.org/jdk/compare/8dfb6d76...c9e7c561

-------------

Changes: https://git.openjdk.org/jdk/pull/10847/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=13
  Stats: 1021 lines in 33 files changed: 962 ins; 8 del; 51 mod
  Patch: https://git.openjdk.org/jdk/pull/10847.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10847/head:pull/10847

PR: https://git.openjdk.org/jdk/pull/10847

From redestad at openjdk.org  Tue Dec 20 21:13:55 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 20 Dec 2022 21:13:55 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v13]
In-Reply-To: <PrXrcgFzP4mr0ZI5WrUizT0Sz_wtTl6AJLS_mvW89dQ=.ae6c18d4-8f5e-48cf-b0bf-8d8db7852346@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <pW8HHmh-dQnjrRftd052fBQVulqe_z5KldY76Hp-OmI=.a7a2b6e6-a182-45d2-bd11-16a406126482@github.com>
 <6lAQI6kDDTGbskylHcWReX8ExaB6qkwgqoai7E6ikZY=.8a69a63c-453d-4bbd-8c76-4d477bfb77fe@github.com>
 <mAsTs03BWlAM_YhHXHBNsaJIQqrX95deQyYAYkJwrmE=.7e36f69c-dffc-462a-bf8a-7614153bf8c4@github.com>
 <PrXrcgFzP4mr0ZI5WrUizT0Sz_wtTl6AJLS_mvW89dQ=.ae6c18d4-8f5e-48cf-b0bf-8d8db7852346@github.com>
Message-ID: <a_7dEeMU-LeSDU1irFR-zAjfM_zKhnosJmEe19TyQsA=.d94df28d-8a97-4463-a3f5-e5e39d6b21e4@github.com>

On Mon, 14 Nov 2022 18:28:53 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>>> Also, I'd like to note that C2 auto-vectorization support is not too far away from being able to optimize hash code computations. At some point, I was able to achieve some promising results with modest tweaking of SuperWord pass: https://github.com/iwanowww/jdk/blob/superword/notes.txt http://cr.openjdk.java.net/~vlivanov/superword.reduction/webrev.00/
>> 
>> Intriguing. How far off is this - and do you think it'll be able to match the efficiency we see here with a memoized coefficient table etc?
>> 
>> If we turn this intrinsic into a stub we might also be able to reuse the optimization in other places, including from within the VM (calculating String hashCodes happen in a couple of places, including String deduplication). So I think there are still a few compelling reasons to go the manual route and continue on this path.
>
>> How far off is this ...?
> 
> Back then it looked way too constrained (tight constraints on code shapes). But I considered it as a generally applicable optimization. 
> 
>>  ... do you think it'll be able to match the efficiency we see here with a memoized coefficient table etc?
> 
> Yes, it is able to build the constant table at runtime when folding multiplications of constant coefficients produced during loop unrolling and then packing scalars into a constant vector.
> 
> Moreover, briefly looking at the code shape, the vectorizer would produce a more optimal loop shape (pre-loop would align vector accesses and would use 512-bit vectors when available; vector post-loop could help as well).

Passing the constant node through as an input as suggested by @iwanowww and @sviswa7 meant we could eliminate most of the `instruct` blocks, removing a significant chunk of code and a little bit of complexity from the proposed patch.

-------------

PR: https://git.openjdk.org/jdk/pull/10847

From dholmes at openjdk.org  Tue Dec 20 21:21:51 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 20 Dec 2022 21:21:51 GMT
Subject: RFR: 8299072: java_lang_ref_Reference::clear_referent should be GC
 agnostic
In-Reply-To: <TdoMMvxcNRmL_AxzSGZeTXt79zn0zOAjM31mgC7i3t0=.a3605d22-90b5-4cf2-97fb-eef7313d81bc@github.com>
References: <TdoMMvxcNRmL_AxzSGZeTXt79zn0zOAjM31mgC7i3t0=.a3605d22-90b5-4cf2-97fb-eef7313d81bc@github.com>
Message-ID: <h1q2skmwBMkzZdIpgF6G4DEENc3lkstwAhzWmeIo3g8=.c9b66a4f-f9e0-42b7-9638-4308c944355c@github.com>

On Tue, 20 Dec 2022 07:05:34 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> The current java_lang_ref_Reference::clear_referent implementation performs a raw reference clear. That doesn't work well with upcoming GC algorithms. It should be made GC agnostic by going through the normal access API.

Okay - thanks for the explanation. Looks good.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11736

From coleenp at openjdk.org  Tue Dec 20 23:07:48 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 20 Dec 2022 23:07:48 GMT
Subject: RFR: 8295974: jni_FatalError and Xcheck:jni warnings should print
 the native stack when there are no Java frames
In-Reply-To: <s_Ttmm80UcUu6OOWSZKD95u18WWZufwlMKPW-Gw9ZeE=.b77b8d96-8249-4754-8a0f-1bcf032f465c@github.com>
References: <s_Ttmm80UcUu6OOWSZKD95u18WWZufwlMKPW-Gw9ZeE=.b77b8d96-8249-4754-8a0f-1bcf032f465c@github.com>
Message-ID: <gclpEsBvcVNeGTmtO8NvwKxHK2XRLyuo8BRYbRkXiVM=.3565eeff-817f-4602-a6cc-02b6fd2b0738@github.com>

On Fri, 16 Dec 2022 07:07:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

> If a JNI Fatal error, or a JNI warning (from Xcheck:jni) is triggered in "top-level" native code (such as the launcher itself, or a freshly attached native thread) then there is no stack printed as there are no Java frames. This enhancement changes that so that we print the native stack, similarly to how error reporting does. We reuse VMError::print_native _stack to do this, but it could be argued this should be moved to a more general purpose utility class - suggestions welcome.
> 
> Testing:
>   - manual fault injection (see bug report)
>   - tiers 1-4
> 
> Thanks.

This looks like a nice improvement.  Do you have a test for it, or do the existing Xcheck:jni tests exercise this?  I'd prefer JavaThread::print_jni_stack() moved to VMError rather than VMError::print_native_stack moved to JavaThread.

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11703

From sviswanathan at openjdk.org  Wed Dec 21 00:14:54 2022
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 21 Dec 2022 00:14:54 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v13]
In-Reply-To: <a_7dEeMU-LeSDU1irFR-zAjfM_zKhnosJmEe19TyQsA=.d94df28d-8a97-4463-a3f5-e5e39d6b21e4@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <pW8HHmh-dQnjrRftd052fBQVulqe_z5KldY76Hp-OmI=.a7a2b6e6-a182-45d2-bd11-16a406126482@github.com>
 <6lAQI6kDDTGbskylHcWReX8ExaB6qkwgqoai7E6ikZY=.8a69a63c-453d-4bbd-8c76-4d477bfb77fe@github.com>
 <mAsTs03BWlAM_YhHXHBNsaJIQqrX95deQyYAYkJwrmE=.7e36f69c-dffc-462a-bf8a-7614153bf8c4@github.com>
 <PrXrcgFzP4mr0ZI5WrUizT0Sz_wtTl6AJLS_mvW89dQ=.ae6c18d4-8f5e-48cf-b0bf-8d8db7852346@github.com>
 <a_7dEeMU-LeSDU1irFR-zAjfM_zKhnosJmEe19TyQsA=.d94df28d-8a97-4463-a3f5-e5e39d6b21e4@github.com>
Message-ID: <HcQ7WJUZIa-jvv-COz7L3XGOLqMkV5fHf_l-4tmdj6k=.8ba6ebce-b84c-4bfd-954d-44ca693421b8@github.com>

On Tue, 20 Dec 2022 21:11:18 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>>> How far off is this ...?
>> 
>> Back then it looked way too constrained (tight constraints on code shapes). But I considered it as a generally applicable optimization. 
>> 
>>>  ... do you think it'll be able to match the efficiency we see here with a memoized coefficient table etc?
>> 
>> Yes, it is able to build the constant table at runtime when folding multiplications of constant coefficients produced during loop unrolling and then packing scalars into a constant vector.
>> 
>> Moreover, briefly looking at the code shape, the vectorizer would produce a more optimal loop shape (pre-loop would align vector accesses and would use 512-bit vectors when available; vector post-loop could help as well).
>
> Passing the constant node through as an input as suggested by @iwanowww and @sviswa7 meant we could eliminate most of the `instruct` blocks, removing a significant chunk of code and a little bit of complexity from the proposed patch.

@cl4es Thanks for passing the constant node through, the code looks much cleaner now. The attached patch should handle the signed bytes/shorts as well. Please take a look. 
[signed.patch](https://github.com/openjdk/jdk/files/10273480/signed.patch)

-------------

PR: https://git.openjdk.org/jdk/pull/10847

From sviswanathan at openjdk.org  Wed Dec 21 01:58:59 2022
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 21 Dec 2022 01:58:59 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v14]
In-Reply-To: <fU9foJNSAmSImvl8PN0di4DTJc30iMSaOAPPf0tm290=.95de7241-ea06-4a51-9c5e-c3acf260f83f@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <fU9foJNSAmSImvl8PN0di4DTJc30iMSaOAPPf0tm290=.95de7241-ea06-4a51-9c5e-c3acf260f83f@github.com>
Message-ID: <-qoflnp34219qc7cA_xaazdxkbFkEOzdZfCbOeYPCxA=.5f57ad5e-a099-425d-81e1-87e2eda09cf2@github.com>

On Tue, 20 Dec 2022 21:11:40 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops.
>> 
>> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases.
>> 
>> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front.
>> 
>> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads.
>> 
>> With the most recent fixes the x64 intrinsic results on my workstation look like this:
>> 
>> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.199 ?  0.017  ns/op
>> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     6.933 ?  0.049  ns/op
>> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    29.935 ?  0.221  ns/op
>> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  1596.982 ?  7.020  ns/op
>> 
>> Baseline:
>> 
>> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.200 ?  0.013  ns/op
>> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     9.424 ?  0.122  ns/op
>> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    90.541 ?  0.512  ns/op
>> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  9425.321 ? 67.630  ns/op
>> 
>> I.e. no measurable overhead compared to baseline even for `size == 1`.
>> 
>> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good.
>> 
>> Benchmark for `Arrays.hashCode`:
>> 
>> Benchmark              (size)  Mode  Cnt     Score    Error  Units
>> ArraysHashCode.bytes        1  avgt    5     1.884 ?  0.013  ns/op
>> ArraysHashCode.bytes       10  avgt    5     6.955 ?  0.040  ns/op
>> ArraysHashCode.bytes      100  avgt    5    87.218 ?  0.595  ns/op
>> ArraysHashCode.bytes    10000  avgt    5  9419.591 ? 38.308  ns/op
>> ArraysHashCode.chars        1  avgt    5     2.200 ?  0.010  ns/op
>> ArraysHashCode.chars       10  avgt    5     6.935 ?  0.034  ns/op
>> ArraysHashCode.chars      100  avgt    5    30.216 ?  0.134  ns/op
>> ArraysHashCode.chars    10000  avgt    5  1601.629 ?  6.418  ns/op
>> ArraysHashCode.ints         1  avgt    5     2.200 ?  0.007  ns/op
>> ArraysHashCode.ints        10  avgt    5     6.936 ?  0.034  ns/op
>> ArraysHashCode.ints       100  avgt    5    29.412 ?  0.268  ns/op
>> ArraysHashCode.ints     10000  avgt    5  1610.578 ?  7.785  ns/op
>> ArraysHashCode.shorts       1  avgt    5     1.885 ?  0.012  ns/op
>> ArraysHashCode.shorts      10  avgt    5     6.961 ?  0.034  ns/op
>> ArraysHashCode.shorts     100  avgt    5    87.095 ?  0.417  ns/op
>> ArraysHashCode.shorts   10000  avgt    5  9420.617 ? 50.089  ns/op
>> 
>> Baseline:
>> 
>> Benchmark              (size)  Mode  Cnt     Score    Error  Units
>> ArraysHashCode.bytes        1  avgt    5     3.213 ?  0.207  ns/op
>> ArraysHashCode.bytes       10  avgt    5     8.483 ?  0.040  ns/op
>> ArraysHashCode.bytes      100  avgt    5    90.315 ?  0.655  ns/op
>> ArraysHashCode.bytes    10000  avgt    5  9422.094 ? 62.402  ns/op
>> ArraysHashCode.chars        1  avgt    5     3.040 ?  0.066  ns/op
>> ArraysHashCode.chars       10  avgt    5     8.497 ?  0.074  ns/op
>> ArraysHashCode.chars      100  avgt    5    90.074 ?  0.387  ns/op
>> ArraysHashCode.chars    10000  avgt    5  9420.474 ? 41.619  ns/op
>> ArraysHashCode.ints         1  avgt    5     2.827 ?  0.019  ns/op
>> ArraysHashCode.ints        10  avgt    5     7.727 ?  0.043  ns/op
>> ArraysHashCode.ints       100  avgt    5    89.405 ?  0.593  ns/op
>> ArraysHashCode.ints     10000  avgt    5  9426.539 ? 51.308  ns/op
>> ArraysHashCode.shorts       1  avgt    5     3.071 ?  0.062  ns/op
>> ArraysHashCode.shorts      10  avgt    5     8.168 ?  0.049  ns/op
>> ArraysHashCode.shorts     100  avgt    5    90.399 ?  0.292  ns/op
>> ArraysHashCode.shorts   10000  avgt    5  9420.171 ? 44.474  ns/op
>> 
>> 
>> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement.
>
> Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 64 commits:
> 
>  - Pass the constant mode node through, removing need for all but one instruct declarations
>  - FLAG_SET_DEFAULT
>  - Merge branch 'master' into 8282664-polyhash
>  - Merge branch 'master' into 8282664-polyhash
>  - Missing & 0xff in StringLatin1::hashCode
>  - Qualified guess on shenandoahSupport fix-up
>  - Whitespace
>  - Final touch-ups, restored 2-stride with dependency chain breakage
>  - Minor cleanup
>  - Revert accidental ModuleHashes change
>  - ... and 54 more: https://git.openjdk.org/jdk/compare/8dfb6d76...c9e7c561

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 3420:

> 3418:   arrays_hashcode_elload(tmp3, Address(ary1, index, Address::times(elsize), -elsize), eltype, is_string_hashcode);
> 3419:   addl(result, tmp3);
> 3420:   jmp(END);

This jmp can be removed.

-------------

PR: https://git.openjdk.org/jdk/pull/10847

From sviswanathan at openjdk.org  Wed Dec 21 01:59:01 2022
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 21 Dec 2022 01:59:01 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v13]
In-Reply-To: <xEjDlEzYJlPt8HhGk9xE6z57yAwT246Nl0yNpMP3riI=.9aca27c6-348f-4ad2-bff3-4e0262053135@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <pW8HHmh-dQnjrRftd052fBQVulqe_z5KldY76Hp-OmI=.a7a2b6e6-a182-45d2-bd11-16a406126482@github.com>
 <_2HYrbXOe6zVuLXHywoy_AjCcGMYR266BcwKUZEA5fs=.1e6f7640-7580-4ff3-ace6-f18f27efbb23@github.com>
 <xEjDlEzYJlPt8HhGk9xE6z57yAwT246Nl0yNpMP3riI=.9aca27c6-348f-4ad2-bff3-4e0262053135@github.com>
Message-ID: <2l2l7-2EKQr3UORegtVHtWN0uf9AUH8awtUPvC0MfS0=.8f94982f-f399-4ffd-b494-117cb73bf606@github.com>

On Tue, 20 Dec 2022 19:52:34 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/StringUTF16.java line 418:
>> 
>>> 416:             return 0;
>>> 417:         } else {
>>> 418:             return ArraysSupport.vectorizedHashCode(value, ArraysSupport.UTF16);
>> 
>> Special case for 1 missing here.
>
> Intentionally left out. Array length is always even for `UTF16` arrays, but we could add a case for `2` that'd return `getChar(bytes, 0)` but I didn't see much of a win when I tested this.

I do see a 1.5x gain with this special case added:
       return switch (value.length) {
            case 0 -> 0;
            case 2 -> getChar(value, 0);
            default -> ArraysSupport.vectorizedHashCode(value, ArraysSupport.UTF16);
        };
before: 0.987 ns/op 
after: 0.640 ns/op

-------------

PR: https://git.openjdk.org/jdk/pull/10847

From dholmes at openjdk.org  Wed Dec 21 03:33:48 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 21 Dec 2022 03:33:48 GMT
Subject: RFR: 8295974: jni_FatalError and Xcheck:jni warnings should print
 the native stack when there are no Java frames
In-Reply-To: <5hEjPx0QqT-2U_vPwGfteQa49LpP3eGJbffRcaoqqpk=.e341140c-ea7b-4278-8994-0773230834e5@github.com>
References: <s_Ttmm80UcUu6OOWSZKD95u18WWZufwlMKPW-Gw9ZeE=.b77b8d96-8249-4754-8a0f-1bcf032f465c@github.com>
 <5hEjPx0QqT-2U_vPwGfteQa49LpP3eGJbffRcaoqqpk=.e341140c-ea7b-4278-8994-0773230834e5@github.com>
Message-ID: <oU2XpKZ02tz64UZ0OurXllKrF6-Xr-Rwu8WRz_wkKyk=.9d44a53a-7cf3-4e3b-8cd5-bf7b1836e34d@github.com>

On Tue, 20 Dec 2022 10:25:58 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> If a JNI Fatal error, or a JNI warning (from Xcheck:jni) is triggered in "top-level" native code (such as the launcher itself, or a freshly attached native thread) then there is no stack printed as there are no Java frames. This enhancement changes that so that we print the native stack, similarly to how error reporting does. We reuse VMError::print_native _stack to do this, but it could be argued this should be moved to a more general purpose utility class - suggestions welcome.
>> 
>> Testing:
>>   - manual fault injection (see bug report)
>>   - tiers 1-4
>> 
>> Thanks.
>
> Hi David, the change looks good to me. Is there a particular reason that you chose resource allocation here instead of allocating the buffer on the stack? It should have the same effect.

Thanks for looking at this @jdksjolen .

>  Is there a particular reason that you chose resource allocation here instead of allocating the buffer on the stack?

Just a general aversion to putting large buffers on the stack. We've had issues in the past where they've triggered StackOverflowError. Though that really shouldn't be an issue in this case as we have no Java frames on the stack to begin with.

-------------

PR: https://git.openjdk.org/jdk/pull/11703

From dholmes at openjdk.org  Wed Dec 21 03:43:51 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 21 Dec 2022 03:43:51 GMT
Subject: RFR: 8295974: jni_FatalError and Xcheck:jni warnings should print
 the native stack when there are no Java frames
In-Reply-To: <gclpEsBvcVNeGTmtO8NvwKxHK2XRLyuo8BRYbRkXiVM=.3565eeff-817f-4602-a6cc-02b6fd2b0738@github.com>
References: <s_Ttmm80UcUu6OOWSZKD95u18WWZufwlMKPW-Gw9ZeE=.b77b8d96-8249-4754-8a0f-1bcf032f465c@github.com>
 <gclpEsBvcVNeGTmtO8NvwKxHK2XRLyuo8BRYbRkXiVM=.3565eeff-817f-4602-a6cc-02b6fd2b0738@github.com>
Message-ID: <_5u4dGPpN3KLwo55s-YMuo_qoddoMM2q_KK-6dfkB8I=.13d3c932-e1bf-464e-b678-9a00ebde102b@github.com>

On Tue, 20 Dec 2022 23:04:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> If a JNI Fatal error, or a JNI warning (from Xcheck:jni) is triggered in "top-level" native code (such as the launcher itself, or a freshly attached native thread) then there is no stack printed as there are no Java frames. This enhancement changes that so that we print the native stack, similarly to how error reporting does. We reuse VMError::print_native _stack to do this, but it could be argued this should be moved to a more general purpose utility class - suggestions welcome.
>> 
>> Testing:
>>   - manual fault injection (see bug report)
>>   - tiers 1-4
>> 
>> Thanks.
>
> This looks like a nice improvement.  Do you have a test for it, or do the existing Xcheck:jni tests exercise this?  I'd prefer JavaThread::print_jni_stack() moved to VMError rather than VMError::print_native_stack moved to JavaThread.

Thanks for looking at this @coleenp .

> Do you have a test for it, or do the existing Xcheck:jni tests exercise this? 

No regression tests for this, I tested by manually adjusting the launcher code to force an error and an existing test to force a warning. I could look at creating a regression test though.

> I'd prefer JavaThread::print_jni_stack() moved to VMError rather than VMError::print_native_stack moved to JavaThread.

Well I wasn't suggesting moving `print_native_stack` into `JavaThread`, but the current usage isn't related to `VMError` so it could be moved somewhere more general, or I can just leave it.

-------------

PR: https://git.openjdk.org/jdk/pull/11703

From xlinzheng at openjdk.org  Wed Dec 21 03:47:25 2022
From: xlinzheng at openjdk.org (Xiaolin Zheng)
Date: Wed, 21 Dec 2022 03:47:25 GMT
Subject: RFR: 8299162: Refactor shared trampoline emission logic
Message-ID: <AL-gr6iomKiTRXxy3U3QB6pU-jk8RQvaCi5uWt4Dfuw=.244449d5-4abe-441a-b2a1-9926173e73e6@github.com>

After the quick fix [JDK-8297763](https://bugs.openjdk.org/browse/JDK-8297763), shared trampoline logic gets a bit verbose. If we can turn to batch emission of trampoline stubs, pre-calculating the total size, and pre-allocating them, then we can remove the CodeBuffer expansion checks each time and clean up the code around.


[Stub Code]
...
<shared trampoline stub1, (A):>
  align(), emitting nothing or a 4-byte padding
  <..., (B)>    <-- multiple relocations at the pc: __ relocate(<the pc here>, trampoline_stub_Relocation::spec())
  <...>
  <..., (C)>
<shared trampoline stub2:>
  align(), emitting nothing or a 4-byte padding
  <...>        <-- multiple relocations at the pc: __ relocate(<the pc here>, trampoline_stub_Relocation::spec())
  <...>
  <...>
<shared trampoline stub3:>
  align(), emitting nothing or a 4-byte padding
  <...>        <-- multiple relocations at the pc: __ relocate(<the pc here>, trampoline_stub_Relocation::spec())
  <...>
  <...>


Here, the `pc_at_(C) - pc_at_(B)` is the fixed length `NativeCallTrampolineStub::instruction_size`; but the `pc_at_(B) - pc_at_(A)` may be a 0 or 4, which is not a fixed-length value.

So originally:
The logic of the lambda `emit()` inside the `emit_shared_trampolines()` when emitting a shared trampoline:

We are at (A) -> 
do an align() -> 
We are at (B) -> 
emit lots of relocations bound to this shared trampoline at (B) -> 
do an emit_trampoline_stub() -> 
We are at (C)


After this patch:

We are at (A) -> 
do an emit_trampoline_stub(), which contains an align() already ->
We are at (C) directly ->
reversely calculate the (B) address, for `pc_at_(C) - pc_at_(B)` is a fixed-length value -> 
emit lots of relocations bound to this shared trampoline at (B)


Theoretically the same. Just a code refactoring and we can remove some checks inside and make the code clean.

Tested AArch64 hotspot tier1~4 with fastdebug build twice; Tested RISC-V hotspot tier1~4 with fastdebug build on hardware once.


Thanks,
Xiaolin

-------------

Commit messages:
 - Refactor and cleanup for shared trampolines

Changes: https://git.openjdk.org/jdk/pull/11749/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11749&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299162
  Stats: 104 lines in 9 files changed: 44 ins; 29 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/11749.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11749/head:pull/11749

PR: https://git.openjdk.org/jdk/pull/11749

From xlinzheng at openjdk.org  Wed Dec 21 04:57:35 2022
From: xlinzheng at openjdk.org (Xiaolin Zheng)
Date: Wed, 21 Dec 2022 04:57:35 GMT
Subject: RFR: 8299168: RISC-V: Fix MachNode size mismatch for
 MacroAssembler::_verify_oops*
Message-ID: <hQxJLqN5qMtfsAgoHRN3iLTCpX1pSs2eJZigFGbM-DU=.3e187efe-9fe8-419b-ba28-32b88d7488af@github.com>

Nearly the same as [JDK-8285437](https://bugs.openjdk.org/browse/JDK-8285437). MachNode size should match in scratch emission and real emission phases. The address of the local char buffer is a random value, but when RVC is enabled, the `movptr`, containing `lui+addi+slli+addi+slli`, with another dangling `addi` at last to load the immediate address of the special local char buffer may get compressed depending on the char buffer's different addresses. So the size may at last mismatch. Due to this part containing implicit fixed-length semantics, it shall be a reasonable fix to add an `IncompressibleRegion` for these two special positions to disable automatic RVC transformations.

`test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestDFlags.java` in hotspot tier4 can reflect this issue. It contains a `vm.flagless` so it didn't run in my local environment until recently.

Tested Hotspot tier1~4 with fastdebug build on physical hardware along with some other patches.

Thanks,
Xiaolin

-------------

Commit messages:
 - Fix: Special treatment since C2's scratch emision needs independent fixed length

Changes: https://git.openjdk.org/jdk/pull/11750/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11750&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299168
  Stats: 14 lines in 1 file changed: 6 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/11750.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11750/head:pull/11750

PR: https://git.openjdk.org/jdk/pull/11750

From fyang at openjdk.org  Wed Dec 21 07:35:49 2022
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 21 Dec 2022 07:35:49 GMT
Subject: RFR: 8299168: RISC-V: Fix MachNode size mismatch for
 MacroAssembler::_verify_oops*
In-Reply-To: <hQxJLqN5qMtfsAgoHRN3iLTCpX1pSs2eJZigFGbM-DU=.3e187efe-9fe8-419b-ba28-32b88d7488af@github.com>
References: <hQxJLqN5qMtfsAgoHRN3iLTCpX1pSs2eJZigFGbM-DU=.3e187efe-9fe8-419b-ba28-32b88d7488af@github.com>
Message-ID: <NAtRDahXrPNSsjt__CLBeLs8y45_6-bhk8Z0cVHI1hA=.59a25b9f-8db1-43c2-837b-6a7796cb7fd5@github.com>

On Wed, 21 Dec 2022 04:47:51 GMT, Xiaolin Zheng <xlinzheng at openjdk.org> wrote:

> Nearly the same as [JDK-8285437](https://bugs.openjdk.org/browse/JDK-8285437). MachNode size should match in scratch emission and real emission phases. The address of the local char buffer is a random value, but when RVC is enabled, the `movptr`, containing `lui+addi+slli+addi+slli`, with another dangling `addi` at last to load the immediate address of the special local char buffer may get compressed depending on the char buffer's different addresses. So the size may at last mismatch. Due to this part containing implicit fixed-length semantics, it shall be a reasonable fix to add an `IncompressibleRegion` for these two special positions to disable automatic RVC transformations.
> 
> `test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestDFlags.java` in hotspot tier4 can reflect this issue. It contains a `vm.flagless` so it didn't run in my local environment until recently.
> 
> Tested Hotspot tier1~4 with fastdebug build on physical hardware along with some other patches.
> 
> Thanks,
> Xiaolin

Looks like the code comments could be further improved. Did you checked other possible occurrences else where?

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 414:

> 412:     // The length of the instruction sequence emitted should be independent
> 413:     // of the value of the local char buffer address so that the size of mach
> 414:     // nodes for scratch emit and normal emit matches.

Suggestion: 
"
    // The length of the instruction sequence emitted should not depend
    // on the address of the char buffer so that the size of mach nodes for
    // scratch emit and normal emit matches.
"

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 459:

> 457:     // The length of the instruction sequence emitted should be independent
> 458:     // of the value of the local char buffer address so that the size of mach
> 459:     // nodes for scratch emit and normal emit matches.

Same as above.

-------------

PR: https://git.openjdk.org/jdk/pull/11750

From xlinzheng at openjdk.org  Wed Dec 21 07:43:15 2022
From: xlinzheng at openjdk.org (Xiaolin Zheng)
Date: Wed, 21 Dec 2022 07:43:15 GMT
Subject: RFR: 8299168: RISC-V: Fix MachNode size mismatch for
 MacroAssembler::_verify_oops* [v2]
In-Reply-To: <hQxJLqN5qMtfsAgoHRN3iLTCpX1pSs2eJZigFGbM-DU=.3e187efe-9fe8-419b-ba28-32b88d7488af@github.com>
References: <hQxJLqN5qMtfsAgoHRN3iLTCpX1pSs2eJZigFGbM-DU=.3e187efe-9fe8-419b-ba28-32b88d7488af@github.com>
Message-ID: <MOAIRaf4pSV2DfT6tksaohzqAs_UoRjcovxKb_VUHHA=.2925a312-d06f-4f6c-8f64-10d0202f4ac4@github.com>

> Nearly the same as [JDK-8285437](https://bugs.openjdk.org/browse/JDK-8285437). MachNode size should match in scratch emission and real emission phases. The address of the local char buffer is a random value, but when RVC is enabled, the `movptr`, containing `lui+addi+slli+addi+slli`, with another dangling `addi` at last to load the immediate address of the special local char buffer may get compressed depending on the char buffer's different addresses. So the size may at last mismatch. Due to this part containing implicit fixed-length semantics, it shall be a reasonable fix to add an `IncompressibleRegion` for these two special positions to disable automatic RVC transformations.
> 
> `test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestDFlags.java` in hotspot tier4 can reflect this issue. It contains a `vm.flagless` so it didn't run in my local environment until recently.
> 
> Tested Hotspot tier1~4 with fastdebug build on physical hardware along with some other patches.
> 
> Thanks,
> Xiaolin

Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision:

  Fix as to comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11750/files
  - new: https://git.openjdk.org/jdk/pull/11750/files/c81155fd..669cc427

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11750&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11750&range=00-01

  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/11750.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11750/head:pull/11750

PR: https://git.openjdk.org/jdk/pull/11750

From xlinzheng at openjdk.org  Wed Dec 21 07:45:51 2022
From: xlinzheng at openjdk.org (Xiaolin Zheng)
Date: Wed, 21 Dec 2022 07:45:51 GMT
Subject: RFR: 8299168: RISC-V: Fix MachNode size mismatch for
 MacroAssembler::_verify_oops* [v2]
In-Reply-To: <NAtRDahXrPNSsjt__CLBeLs8y45_6-bhk8Z0cVHI1hA=.59a25b9f-8db1-43c2-837b-6a7796cb7fd5@github.com>
References: <hQxJLqN5qMtfsAgoHRN3iLTCpX1pSs2eJZigFGbM-DU=.3e187efe-9fe8-419b-ba28-32b88d7488af@github.com>
 <NAtRDahXrPNSsjt__CLBeLs8y45_6-bhk8Z0cVHI1hA=.59a25b9f-8db1-43c2-837b-6a7796cb7fd5@github.com>
Message-ID: <xjxaMjkVu99QjTYR76ehnj3hnehtiYg8jN0FLXxPmu8=.ec897a7e-6ae0-4342-a8c3-fbf79c2f87bc@github.com>

On Wed, 21 Dec 2022 07:33:33 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Looks like the code comments could be further improved. Did you checked other possible occurrences else where?

Thanks for the comment suggestions. Yes, checked - only the two places are special that we need to adapt to C2's code emission strategies. Fails only under the `-XX:+VerifyOops` with a fastdebug build here.

-------------

PR: https://git.openjdk.org/jdk/pull/11750

From fyang at openjdk.org  Wed Dec 21 07:50:49 2022
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 21 Dec 2022 07:50:49 GMT
Subject: RFR: 8299168: RISC-V: Fix MachNode size mismatch for
 MacroAssembler::_verify_oops* [v2]
In-Reply-To: <MOAIRaf4pSV2DfT6tksaohzqAs_UoRjcovxKb_VUHHA=.2925a312-d06f-4f6c-8f64-10d0202f4ac4@github.com>
References: <hQxJLqN5qMtfsAgoHRN3iLTCpX1pSs2eJZigFGbM-DU=.3e187efe-9fe8-419b-ba28-32b88d7488af@github.com>
 <MOAIRaf4pSV2DfT6tksaohzqAs_UoRjcovxKb_VUHHA=.2925a312-d06f-4f6c-8f64-10d0202f4ac4@github.com>
Message-ID: <VdKZ6hYVYhsvL2jmgpSHX0oiXIen-8iGnrT7PKEfXks=.55cd4db2-30df-4139-a1c9-7610420cee0f@github.com>

On Wed, 21 Dec 2022 07:43:15 GMT, Xiaolin Zheng <xlinzheng at openjdk.org> wrote:

>> Nearly the same as [JDK-8285437](https://bugs.openjdk.org/browse/JDK-8285437). MachNode size should match in scratch emission and real emission phases. The address of the local char buffer is a random value, but when RVC is enabled, the `movptr`, containing `lui+addi+slli+addi+slli`, with another dangling `addi` at last to load the immediate address of the special local char buffer may get compressed depending on the char buffer's different addresses. So the size may at last mismatch. Due to this part containing implicit fixed-length semantics, it shall be a reasonable fix to add an `IncompressibleRegion` for these two special positions to disable automatic RVC transformations.
>> 
>> `test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestDFlags.java` in hotspot tier4 can reflect this issue. It contains a `vm.flagless` so it didn't run in my local environment until recently.
>> 
>> Tested Hotspot tier1~4 with fastdebug build on physical hardware along with some other patches.
>> 
>> Thanks,
>> Xiaolin
>
> Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix as to comments

Updated changes looks good. Thanks.

-------------

Marked as reviewed by fyang (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11750

From rehn at openjdk.org  Wed Dec 21 08:42:49 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 21 Dec 2022 08:42:49 GMT
Subject: RFR: 8295974: jni_FatalError and Xcheck:jni warnings should print
 the native stack when there are no Java frames
In-Reply-To: <s_Ttmm80UcUu6OOWSZKD95u18WWZufwlMKPW-Gw9ZeE=.b77b8d96-8249-4754-8a0f-1bcf032f465c@github.com>
References: <s_Ttmm80UcUu6OOWSZKD95u18WWZufwlMKPW-Gw9ZeE=.b77b8d96-8249-4754-8a0f-1bcf032f465c@github.com>
Message-ID: <-91fpPpi3yhQMZZ7WoGZ_7bCqu9yan9SI7drBlSYjGM=.b967bc1a-6f6c-4d25-be66-9c19c6470417@github.com>

On Fri, 16 Dec 2022 07:07:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

> If a JNI Fatal error, or a JNI warning (from Xcheck:jni) is triggered in "top-level" native code (such as the launcher itself, or a freshly attached native thread) then there is no stack printed as there are no Java frames. This enhancement changes that so that we print the native stack, similarly to how error reporting does. We reuse VMError::print_native _stack to do this, but it could be argued this should be moved to a more general purpose utility class - suggestions welcome.
> 
> Testing:
>   - manual fault injection (see bug report)
>   - tiers 1-4
> 
> Thanks.

Yes, the stack-walking code spread out in different places, we should make an effort here.

Looks good, thank!

-------------

Marked as reviewed by rehn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11703

From dholmes at openjdk.org  Wed Dec 21 09:36:52 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 21 Dec 2022 09:36:52 GMT
Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling
 one virtual thread transitions [v3]
In-Reply-To: <FDyv8oX5HVbkRMGV2q86Zv5iRrNEf4YQ0J2RbwxE4aU=.7457681a-5149-4fa2-baaf-15484a58f267@github.com>
References: <z8NCIbPeF0WzTEzXGyNxlnuOF_52vbV90p4B15xThFk=.b12cfe49-d27d-4e65-9027-796985005c14@github.com>
 <FDyv8oX5HVbkRMGV2q86Zv5iRrNEf4YQ0J2RbwxE4aU=.7457681a-5149-4fa2-baaf-15484a58f267@github.com>
Message-ID: <Ht7qFb5htBFbSLuCZ-dA1IUc_cI-2YOS894SojO6wbg=.bd65f2d0-fc22-4e3e-b243-e152a3bd671f@github.com>

On Tue, 20 Dec 2022 20:52:10 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Now the `JvmtiVTMSTransitionDisabler` mechanism supports disabling VTMS transitions for all virtual threads only. It should also support disabling transitions for any specific virtual thread as well. This will improve scalability of the JVMTI functions operating on target virtual threads as the functions can be executed concurrently without blocking each other execution when target virtual threads are different.
>> New constructor `JvmtiVTMSTransitionDisabler(jthread vthread)` is added which has jthread parameter of the target virtual thread.
>> 
>> Testing:
>>   mach5 jobs are TBD (preliminary testing was completed):
>>    - all JVMTI, JDWP, JDI and JDB tests have to be run
>>    - Kitchensink
>>    - tier5
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address wqsecond round review comments

One nit with the "is locked" asserts but otherwise looks good. Thanks for the updates!

src/hotspot/share/classfile/javaClasses.cpp line 1739:

> 1737: void java_lang_Thread::inc_VTMS_transition_disable_count(oop java_thread) {
> 1738:   int val = VTMS_transition_disable_count(java_thread);
> 1739:   assert(JvmtiVTMSTransition_lock->is_locked(), "Must be locked");

You want to use `owned_by_self()` for these assertions - thanks.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11690

From dholmes at openjdk.org  Wed Dec 21 09:43:49 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 21 Dec 2022 09:43:49 GMT
Subject: RFR: 8299089: Instrument global jni handles with tag to make them
 distinguishable
In-Reply-To: <dHb4TMxgR1O4h2v2LXkpx1rSwk6SLqr-4do-e8KbLfY=.b4c32322-7cb6-42c4-bc21-e338cfcade31@github.com>
References: <dHb4TMxgR1O4h2v2LXkpx1rSwk6SLqr-4do-e8KbLfY=.b4c32322-7cb6-42c4-bc21-e338cfcade31@github.com>
Message-ID: <o7ALPBMRdsaozWmsK4wRpu1VoYDQueJCdPvCwtZST28=.113d4b17-e334-473e-9fc2-4f7680aeebc9@github.com>

On Tue, 20 Dec 2022 11:44:33 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Today there is no cheap way of distinguishing global jni handles from local jni handles.

So is the code you added "cheap"? Else what is the performance hit for adding this? Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/11740

From dholmes at openjdk.org  Wed Dec 21 09:56:50 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 21 Dec 2022 09:56:50 GMT
Subject: RFR: 8295974: jni_FatalError and Xcheck:jni warnings should print
 the native stack when there are no Java frames
In-Reply-To: <-91fpPpi3yhQMZZ7WoGZ_7bCqu9yan9SI7drBlSYjGM=.b967bc1a-6f6c-4d25-be66-9c19c6470417@github.com>
References: <s_Ttmm80UcUu6OOWSZKD95u18WWZufwlMKPW-Gw9ZeE=.b77b8d96-8249-4754-8a0f-1bcf032f465c@github.com>
 <-91fpPpi3yhQMZZ7WoGZ_7bCqu9yan9SI7drBlSYjGM=.b967bc1a-6f6c-4d25-be66-9c19c6470417@github.com>
Message-ID: <NRSrxpZi_7s6i9lRhWchiUSzoaqgT-zuAx5S8Bq4Bd0=.191ffabd-ef1c-4092-8ee3-218a21fb942e@github.com>

On Wed, 21 Dec 2022 08:39:55 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> If a JNI Fatal error, or a JNI warning (from Xcheck:jni) is triggered in "top-level" native code (such as the launcher itself, or a freshly attached native thread) then there is no stack printed as there are no Java frames. This enhancement changes that so that we print the native stack, similarly to how error reporting does. We reuse VMError::print_native _stack to do this, but it could be argued this should be moved to a more general purpose utility class - suggestions welcome.
>> 
>> Testing:
>>   - manual fault injection (see bug report)
>>   - tiers 1-4
>> 
>> Thanks.
>
> Yes, the stack-walking code spread out in different places, we should make an effort here.
> 
> Looks good, thank!

Thanks for the review @robehn . I will file a RFE to consolidate the different native stack walking related code.

-------------

PR: https://git.openjdk.org/jdk/pull/11703

From aboldtch at openjdk.org  Wed Dec 21 12:31:49 2022
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 21 Dec 2022 12:31:49 GMT
Subject: RFR: 8299089: Instrument global jni handles with tag to make them
 distinguishable
In-Reply-To: <dHb4TMxgR1O4h2v2LXkpx1rSwk6SLqr-4do-e8KbLfY=.b4c32322-7cb6-42c4-bc21-e338cfcade31@github.com>
References: <dHb4TMxgR1O4h2v2LXkpx1rSwk6SLqr-4do-e8KbLfY=.b4c32322-7cb6-42c4-bc21-e338cfcade31@github.com>
Message-ID: <3-dPtaLdy3ei4W5pTc7hyiMMMxAcGKon5XYckdgdcp8=.ea0af244-2f03-44c6-a101-ab206f9c2187@github.com>

On Tue, 20 Dec 2022 11:44:33 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Weak global jni handles are tagged so the GC can distinguish them when resolving the object. Today there is no cheap way of distinguishing global jni handles from local jni handles. For generational ZGC the OopStorage handles and the thread local handles semantical difference requires the handles to be distinguishable. 
> 
> This enhancements instruments the jni handles with a global tag similarly to the jweak tag. 
> 
> Note: 
>  * the s390 implementation has minimal changes and requires improvement.
>  * There is room for enchantment here to create the same abstraction that ppc uses for all platforms, i.e. move the resolve_jobject from the MacroAssembler to the BarrierSetAssembler which allows for more optimised code for GCs that can treat local and global handles the same. 
> 
> Testing: GHA. Oracle supported platforms tier1-3. Will run higher tiers. Has also been tested on the generational branch of ZGC for over three months. Requires testing on non Oracle platforms.

The new mechanism for distinguishing global jni handles is the same as the old mechanism for distinguishing weak global jni handles. That is a tag bit in the lower address bits. 

The actual tagging when creating a new global handle is negligible as creating a handle will be dominated by allocating in OopStorage and memory accesses. 

However the biggest change will be to code which resolves jobjects, both in generated code and in the runtime. The change essentially boils down to the following:

if (is_jweak_tagged(handle)) { 
     result = NativeAccess<ON_PHANTOM_OOP_REF>::oop_load(jweak_ptr(handle));
+  } else if (is_global_tagged(handle)) {
+    result = NativeAccess<>::oop_load(global_ptr(handle));
   } else {
-    result = NativeAccess<>::oop_load(jobject_ptr(handle));
+    result = *jobject_ptr(handle);
} 

where `is_*_tagged(handle)` checks the tag and `*_ptr(handle)` untags / removes the tag bits. 

As mentioned in the PR there is some room of improvement here. For example for G1 `NativeAccess<>::oop_load(untagged_ptr(handle));` is equivalent to `*untagged_ptr(handle)` because they are strong and needs no barriers. For the runtime code I do not believe that it matters but the generated code (in this case for G1) can be generated to be almost equivalent to the current generation with the only change being clearing the tag bits. This is already implemented for ppc. But I thought this could be for future RFE (adding `resolve_jobject` to `BarrierSetAssembler` and specialise for GCs), while this PR focuses on making the baseline code actually respect the semantics of our storage areas and their respective access invariants. 

There are also improvements to be made when we generate code from a context where we know that the jobject will be a global handle (upcall stub is one example). This is already done in the JFR write checkpoint epilogue and `LibraryCallKit::inline_native_getEventWriter` code, where resolving the jobject is simply:
```c++
assert(is_global_tagged(handle), "");
return NativeAccess<>::oop_load(global_ptr(handle));


The change to jniFastGetField will only ever see a difference if some platform has different performance characteristics when clearing the lowest bit vs clearing the two lowest bits. (Which I highly doubt)

Regardless I will be running performance testing over the holidays.

-------------

PR: https://git.openjdk.org/jdk/pull/11740

From eosterlund at openjdk.org  Wed Dec 21 16:20:51 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Wed, 21 Dec 2022 16:20:51 GMT
Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC
In-Reply-To: <BOJ4yH2GtNWXDVXMKwPw9Ic359dnBK8Sb9tDw3a5Qmc=.197acbb0-3ed6-418f-8bcf-70ef4b67de5e@github.com>
References: <BOJ4yH2GtNWXDVXMKwPw9Ic359dnBK8Sb9tDw3a5Qmc=.197acbb0-3ed6-418f-8bcf-70ef4b67de5e@github.com>
Message-ID: <lJJnx5e6yW0N_mo_5ghr1s1q3WtftLxhRVkykOSwAoM=.871f9d04-08ad-49bd-90d5-437d89205d25@github.com>

On Thu, 8 Dec 2022 11:23:57 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The JfrVFrameStream is used while generating stack traces for events. One of the events are the ZPage allocation event. This event is sometimes sent when ZGC is relocating. The current implementation of JfrVFrameStream uses WalkContinuation::include, which causes JFR to walk the continuation and perform GC barriers. This is problematic, since ZGC has a requirement that we never perform load barriers while running the relocation code. If we do, we might end up performing other reloctions from the the relocation code, and in some cases that causes dead locks.
> 
> I propose that JFR doesn't walk the continuations when sending events. An alternative could be to limit this to ZGC, but I'd like to get some feedback around that from JFR / Loom devs.
> 
> We've been testing this patch in the Generational ZGC repository.

I have a branch here with a single commit for my proposed fix: https://github.com/fisk/jdk/tree/8298377_jfr_stack_trace
If you like it I can try to figure out how to hijack this PR. I basically create a new DisableStackTracingMark class, that does what deopt does today, and sprinkles it in our ZGC stack watermark processing, and make sure the JFR tracing thread starts processing on the threads it samples.

-------------

PR: https://git.openjdk.org/jdk/pull/11586

From redestad at openjdk.org  Wed Dec 21 17:01:17 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 21 Dec 2022 17:01:17 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v15]
In-Reply-To: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
Message-ID: <IXuNCeg52JvoM46OEEbYH6jBsNIdcGpQJxHFUpUom8k=.77f5ffc6-9b3b-42f5-81af-7be02542d4cc@github.com>

> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops.
> 
> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases.
> 
> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front.
> 
> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads.
> 
> With the most recent fixes the x64 intrinsic results on my workstation look like this:
> 
> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.199 ?  0.017  ns/op
> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     6.933 ?  0.049  ns/op
> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    29.935 ?  0.221  ns/op
> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  1596.982 ?  7.020  ns/op
> 
> Baseline:
> 
> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.200 ?  0.013  ns/op
> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     9.424 ?  0.122  ns/op
> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    90.541 ?  0.512  ns/op
> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  9425.321 ? 67.630  ns/op
> 
> I.e. no measurable overhead compared to baseline even for `size == 1`.
> 
> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good.
> 
> Benchmark for `Arrays.hashCode`:
> 
> Benchmark              (size)  Mode  Cnt     Score    Error  Units
> ArraysHashCode.bytes        1  avgt    5     1.884 ?  0.013  ns/op
> ArraysHashCode.bytes       10  avgt    5     6.955 ?  0.040  ns/op
> ArraysHashCode.bytes      100  avgt    5    87.218 ?  0.595  ns/op
> ArraysHashCode.bytes    10000  avgt    5  9419.591 ? 38.308  ns/op
> ArraysHashCode.chars        1  avgt    5     2.200 ?  0.010  ns/op
> ArraysHashCode.chars       10  avgt    5     6.935 ?  0.034  ns/op
> ArraysHashCode.chars      100  avgt    5    30.216 ?  0.134  ns/op
> ArraysHashCode.chars    10000  avgt    5  1601.629 ?  6.418  ns/op
> ArraysHashCode.ints         1  avgt    5     2.200 ?  0.007  ns/op
> ArraysHashCode.ints        10  avgt    5     6.936 ?  0.034  ns/op
> ArraysHashCode.ints       100  avgt    5    29.412 ?  0.268  ns/op
> ArraysHashCode.ints     10000  avgt    5  1610.578 ?  7.785  ns/op
> ArraysHashCode.shorts       1  avgt    5     1.885 ?  0.012  ns/op
> ArraysHashCode.shorts      10  avgt    5     6.961 ?  0.034  ns/op
> ArraysHashCode.shorts     100  avgt    5    87.095 ?  0.417  ns/op
> ArraysHashCode.shorts   10000  avgt    5  9420.617 ? 50.089  ns/op
> 
> Baseline:
> 
> Benchmark              (size)  Mode  Cnt     Score    Error  Units
> ArraysHashCode.bytes        1  avgt    5     3.213 ?  0.207  ns/op
> ArraysHashCode.bytes       10  avgt    5     8.483 ?  0.040  ns/op
> ArraysHashCode.bytes      100  avgt    5    90.315 ?  0.655  ns/op
> ArraysHashCode.bytes    10000  avgt    5  9422.094 ? 62.402  ns/op
> ArraysHashCode.chars        1  avgt    5     3.040 ?  0.066  ns/op
> ArraysHashCode.chars       10  avgt    5     8.497 ?  0.074  ns/op
> ArraysHashCode.chars      100  avgt    5    90.074 ?  0.387  ns/op
> ArraysHashCode.chars    10000  avgt    5  9420.474 ? 41.619  ns/op
> ArraysHashCode.ints         1  avgt    5     2.827 ?  0.019  ns/op
> ArraysHashCode.ints        10  avgt    5     7.727 ?  0.043  ns/op
> ArraysHashCode.ints       100  avgt    5    89.405 ?  0.593  ns/op
> ArraysHashCode.ints     10000  avgt    5  9426.539 ? 51.308  ns/op
> ArraysHashCode.shorts       1  avgt    5     3.071 ?  0.062  ns/op
> ArraysHashCode.shorts      10  avgt    5     8.168 ?  0.049  ns/op
> ArraysHashCode.shorts     100  avgt    5    90.399 ?  0.292  ns/op
> ArraysHashCode.shorts   10000  avgt    5  9420.171 ? 44.474  ns/op
> 
> 
> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement.

Claes Redestad has updated the pull request incrementally with two additional commits since the last revision:

 - Handle signed subword arrays, contributed by @sviswa7
 - @sviswa7 comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10847/files
  - new: https://git.openjdk.org/jdk/pull/10847/files/c9e7c561..16733c4d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=13-14

  Stats: 51 lines in 3 files changed: 36 ins; 6 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/10847.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10847/head:pull/10847

PR: https://git.openjdk.org/jdk/pull/10847

From redestad at openjdk.org  Wed Dec 21 17:04:07 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 21 Dec 2022 17:04:07 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v14]
In-Reply-To: <-qoflnp34219qc7cA_xaazdxkbFkEOzdZfCbOeYPCxA=.5f57ad5e-a099-425d-81e1-87e2eda09cf2@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <fU9foJNSAmSImvl8PN0di4DTJc30iMSaOAPPf0tm290=.95de7241-ea06-4a51-9c5e-c3acf260f83f@github.com>
 <-qoflnp34219qc7cA_xaazdxkbFkEOzdZfCbOeYPCxA=.5f57ad5e-a099-425d-81e1-87e2eda09cf2@github.com>
Message-ID: <bclAawiKeVSb0AFZtA84gepj1BLL1twPZS0qOubFgfs=.15c44a2b-9085-46f3-a073-352dad5bf70c@github.com>

On Wed, 21 Dec 2022 01:02:35 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 64 commits:
>> 
>>  - Pass the constant mode node through, removing need for all but one instruct declarations
>>  - FLAG_SET_DEFAULT
>>  - Merge branch 'master' into 8282664-polyhash
>>  - Merge branch 'master' into 8282664-polyhash
>>  - Missing & 0xff in StringLatin1::hashCode
>>  - Qualified guess on shenandoahSupport fix-up
>>  - Whitespace
>>  - Final touch-ups, restored 2-stride with dependency chain breakage
>>  - Minor cleanup
>>  - Revert accidental ModuleHashes change
>>  - ... and 54 more: https://git.openjdk.org/jdk/compare/8dfb6d76...c9e7c561
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 3420:
> 
>> 3418:   arrays_hashcode_elload(tmp3, Address(ary1, index, Address::times(elsize), -elsize), eltype, is_string_hashcode);
>> 3419:   addl(result, tmp3);
>> 3420:   jmp(END);
> 
> This jmp can be removed.

Ok, special-cased for `value.length == 2`, removed the superfluous `jmp`, and committed your patch to implement the vectorization for `short`s and signed `byte`s.

-------------

PR: https://git.openjdk.org/jdk/pull/10847

From redestad at openjdk.org  Wed Dec 21 17:29:23 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 21 Dec 2022 17:29:23 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v16]
In-Reply-To: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
Message-ID: <cPQkHqc5OHG2ytU7dCawy438CddgDCTQFzHvjloUxaE=.3216df79-1f3f-45e9-97c0-acb5a304b1ae@github.com>

> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops.
> 
> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases.
> 
> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front.
> 
> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads.
> 
> With the most recent fixes the x64 intrinsic results on my workstation look like this:
> 
> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.199 ?  0.017  ns/op
> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     6.933 ?  0.049  ns/op
> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    29.935 ?  0.221  ns/op
> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  1596.982 ?  7.020  ns/op
> 
> Baseline:
> 
> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.200 ?  0.013  ns/op
> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     9.424 ?  0.122  ns/op
> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    90.541 ?  0.512  ns/op
> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  9425.321 ? 67.630  ns/op
> 
> I.e. no measurable overhead compared to baseline even for `size == 1`.
> 
> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good.
> 
> Benchmark for `Arrays.hashCode`:
> 
> Benchmark              (size)  Mode  Cnt     Score    Error  Units
> ArraysHashCode.bytes        1  avgt    5     1.884 ?  0.013  ns/op
> ArraysHashCode.bytes       10  avgt    5     6.955 ?  0.040  ns/op
> ArraysHashCode.bytes      100  avgt    5    87.218 ?  0.595  ns/op
> ArraysHashCode.bytes    10000  avgt    5  9419.591 ? 38.308  ns/op
> ArraysHashCode.chars        1  avgt    5     2.200 ?  0.010  ns/op
> ArraysHashCode.chars       10  avgt    5     6.935 ?  0.034  ns/op
> ArraysHashCode.chars      100  avgt    5    30.216 ?  0.134  ns/op
> ArraysHashCode.chars    10000  avgt    5  1601.629 ?  6.418  ns/op
> ArraysHashCode.ints         1  avgt    5     2.200 ?  0.007  ns/op
> ArraysHashCode.ints        10  avgt    5     6.936 ?  0.034  ns/op
> ArraysHashCode.ints       100  avgt    5    29.412 ?  0.268  ns/op
> ArraysHashCode.ints     10000  avgt    5  1610.578 ?  7.785  ns/op
> ArraysHashCode.shorts       1  avgt    5     1.885 ?  0.012  ns/op
> ArraysHashCode.shorts      10  avgt    5     6.961 ?  0.034  ns/op
> ArraysHashCode.shorts     100  avgt    5    87.095 ?  0.417  ns/op
> ArraysHashCode.shorts   10000  avgt    5  9420.617 ? 50.089  ns/op
> 
> Baseline:
> 
> Benchmark              (size)  Mode  Cnt     Score    Error  Units
> ArraysHashCode.bytes        1  avgt    5     3.213 ?  0.207  ns/op
> ArraysHashCode.bytes       10  avgt    5     8.483 ?  0.040  ns/op
> ArraysHashCode.bytes      100  avgt    5    90.315 ?  0.655  ns/op
> ArraysHashCode.bytes    10000  avgt    5  9422.094 ? 62.402  ns/op
> ArraysHashCode.chars        1  avgt    5     3.040 ?  0.066  ns/op
> ArraysHashCode.chars       10  avgt    5     8.497 ?  0.074  ns/op
> ArraysHashCode.chars      100  avgt    5    90.074 ?  0.387  ns/op
> ArraysHashCode.chars    10000  avgt    5  9420.474 ? 41.619  ns/op
> ArraysHashCode.ints         1  avgt    5     2.827 ?  0.019  ns/op
> ArraysHashCode.ints        10  avgt    5     7.727 ?  0.043  ns/op
> ArraysHashCode.ints       100  avgt    5    89.405 ?  0.593  ns/op
> ArraysHashCode.ints     10000  avgt    5  9426.539 ? 51.308  ns/op
> ArraysHashCode.shorts       1  avgt    5     3.071 ?  0.062  ns/op
> ArraysHashCode.shorts      10  avgt    5     8.168 ?  0.049  ns/op
> ArraysHashCode.shorts     100  avgt    5    90.399 ?  0.292  ns/op
> ArraysHashCode.shorts   10000  avgt    5  9420.171 ? 44.474  ns/op
> 
> 
> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Treat Op_VectorizedHashCode as other similar Ops in split_unique_types

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10847/files
  - new: https://git.openjdk.org/jdk/pull/10847/files/16733c4d..62e98e1b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=14-15

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10847.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10847/head:pull/10847

PR: https://git.openjdk.org/jdk/pull/10847

From sviswanathan at openjdk.org  Wed Dec 21 18:13:54 2022
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 21 Dec 2022 18:13:54 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v16]
In-Reply-To: <cPQkHqc5OHG2ytU7dCawy438CddgDCTQFzHvjloUxaE=.3216df79-1f3f-45e9-97c0-acb5a304b1ae@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <cPQkHqc5OHG2ytU7dCawy438CddgDCTQFzHvjloUxaE=.3216df79-1f3f-45e9-97c0-acb5a304b1ae@github.com>
Message-ID: <fwuK3HPC0oiK1zhQnn7fg2oEgq-PZ00BVCmXbGHjx84=.3095e021-88bd-4f8a-a03f-2a66063d5b5b@github.com>

On Wed, 21 Dec 2022 17:29:23 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops.
>> 
>> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases.
>> 
>> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front.
>> 
>> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads.
>> 
>> With the most recent fixes the x64 intrinsic results on my workstation look like this:
>> 
>> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.199 ?  0.017  ns/op
>> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     6.933 ?  0.049  ns/op
>> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    29.935 ?  0.221  ns/op
>> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  1596.982 ?  7.020  ns/op
>> 
>> Baseline:
>> 
>> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.200 ?  0.013  ns/op
>> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     9.424 ?  0.122  ns/op
>> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    90.541 ?  0.512  ns/op
>> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  9425.321 ? 67.630  ns/op
>> 
>> I.e. no measurable overhead compared to baseline even for `size == 1`.
>> 
>> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good.
>> 
>> Benchmark for `Arrays.hashCode`:
>> 
>> Benchmark              (size)  Mode  Cnt     Score    Error  Units
>> ArraysHashCode.bytes        1  avgt    5     1.884 ?  0.013  ns/op
>> ArraysHashCode.bytes       10  avgt    5     6.955 ?  0.040  ns/op
>> ArraysHashCode.bytes      100  avgt    5    87.218 ?  0.595  ns/op
>> ArraysHashCode.bytes    10000  avgt    5  9419.591 ? 38.308  ns/op
>> ArraysHashCode.chars        1  avgt    5     2.200 ?  0.010  ns/op
>> ArraysHashCode.chars       10  avgt    5     6.935 ?  0.034  ns/op
>> ArraysHashCode.chars      100  avgt    5    30.216 ?  0.134  ns/op
>> ArraysHashCode.chars    10000  avgt    5  1601.629 ?  6.418  ns/op
>> ArraysHashCode.ints         1  avgt    5     2.200 ?  0.007  ns/op
>> ArraysHashCode.ints        10  avgt    5     6.936 ?  0.034  ns/op
>> ArraysHashCode.ints       100  avgt    5    29.412 ?  0.268  ns/op
>> ArraysHashCode.ints     10000  avgt    5  1610.578 ?  7.785  ns/op
>> ArraysHashCode.shorts       1  avgt    5     1.885 ?  0.012  ns/op
>> ArraysHashCode.shorts      10  avgt    5     6.961 ?  0.034  ns/op
>> ArraysHashCode.shorts     100  avgt    5    87.095 ?  0.417  ns/op
>> ArraysHashCode.shorts   10000  avgt    5  9420.617 ? 50.089  ns/op
>> 
>> Baseline:
>> 
>> Benchmark              (size)  Mode  Cnt     Score    Error  Units
>> ArraysHashCode.bytes        1  avgt    5     3.213 ?  0.207  ns/op
>> ArraysHashCode.bytes       10  avgt    5     8.483 ?  0.040  ns/op
>> ArraysHashCode.bytes      100  avgt    5    90.315 ?  0.655  ns/op
>> ArraysHashCode.bytes    10000  avgt    5  9422.094 ? 62.402  ns/op
>> ArraysHashCode.chars        1  avgt    5     3.040 ?  0.066  ns/op
>> ArraysHashCode.chars       10  avgt    5     8.497 ?  0.074  ns/op
>> ArraysHashCode.chars      100  avgt    5    90.074 ?  0.387  ns/op
>> ArraysHashCode.chars    10000  avgt    5  9420.474 ? 41.619  ns/op
>> ArraysHashCode.ints         1  avgt    5     2.827 ?  0.019  ns/op
>> ArraysHashCode.ints        10  avgt    5     7.727 ?  0.043  ns/op
>> ArraysHashCode.ints       100  avgt    5    89.405 ?  0.593  ns/op
>> ArraysHashCode.ints     10000  avgt    5  9426.539 ? 51.308  ns/op
>> ArraysHashCode.shorts       1  avgt    5     3.071 ?  0.062  ns/op
>> ArraysHashCode.shorts      10  avgt    5     8.168 ?  0.049  ns/op
>> ArraysHashCode.shorts     100  avgt    5    90.399 ?  0.292  ns/op
>> ArraysHashCode.shorts   10000  avgt    5  9420.171 ? 44.474  ns/op
>> 
>> 
>> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Treat Op_VectorizedHashCode as other similar Ops in split_unique_types

The PR looks good to me.

-------------

Marked as reviewed by sviswanathan (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10847

From kvn at openjdk.org  Wed Dec 21 18:21:49 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 21 Dec 2022 18:21:49 GMT
Subject: [jdk20] RFR: 8298893: Rename option UsePolyIntrinsics to
 UsePoly1305Intrinsics [v2]
In-Reply-To: <hznfrjCGVMMsnmhtoXfnFZ-06C-NVOUG7ZZOv5L2UEU=.0c344193-2a72-4fc6-bb2a-e8f7d37396fa@github.com>
References: <7vlroOyHCMzL1r3QRgkC-lNo3I3bNUfVj_zvSpw8wd8=.1f2f1782-ed68-4044-ab69-f31833c78690@github.com>
 <hznfrjCGVMMsnmhtoXfnFZ-06C-NVOUG7ZZOv5L2UEU=.0c344193-2a72-4fc6-bb2a-e8f7d37396fa@github.com>
Message-ID: <6bHWeF2OwzWf7jJgaeK7TPIQFG5gpkEfMvmAMn4i74w=.676e58e1-ee35-4133-a7f5-f543ecc109b9@github.com>

On Mon, 19 Dec 2022 17:07:10 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> Fix for better documentation. FYI @jnimeh
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   whitespace

This late enhancement request for JDK 20 was approved.

-------------

PR: https://git.openjdk.org/jdk20/pull/49

From duke at openjdk.org  Wed Dec 21 18:46:50 2022
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Wed, 21 Dec 2022 18:46:50 GMT
Subject: [jdk20] Integrated: 8298893: Rename option UsePolyIntrinsics to
 UsePoly1305Intrinsics
In-Reply-To: <7vlroOyHCMzL1r3QRgkC-lNo3I3bNUfVj_zvSpw8wd8=.1f2f1782-ed68-4044-ab69-f31833c78690@github.com>
References: <7vlroOyHCMzL1r3QRgkC-lNo3I3bNUfVj_zvSpw8wd8=.1f2f1782-ed68-4044-ab69-f31833c78690@github.com>
Message-ID: <MIekI2fLAHAyfdm9z35018my8-Hc_ticLPZX9c6VF4Q=.ffd405ec-fc72-4f72-ae9c-e41657579e6b@github.com>

On Fri, 16 Dec 2022 19:14:07 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

> Fix for better documentation. FYI @jnimeh

This pull request has now been integrated.

Changeset: 22007a1e
Author:    Volodymyr Paprotski <volodymyr.paprotski at intel.com>
Committer: Sandhya Viswanathan <sviswanathan at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/22007a1e387a1b8e897c6fbb056377b7ddc6ec00
Stats:     8 lines in 5 files changed: 0 ins; 0 del; 8 mod

8298893: Rename option UsePolyIntrinsics to UsePoly1305Intrinsics

Reviewed-by: jnimeh, chagedorn, thartmann

-------------

PR: https://git.openjdk.org/jdk20/pull/49

From kvn at openjdk.org  Wed Dec 21 19:10:49 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 21 Dec 2022 19:10:49 GMT
Subject: RFR: 8299079: Better interface nmethod oop accesses
In-Reply-To: <XUnYphaHNdOvTPk48hRm_9-brWEJN6o22iMUyTl4HxU=.e8b89be3-da28-4f97-b335-6bd09d39993e@github.com>
References: <XUnYphaHNdOvTPk48hRm_9-brWEJN6o22iMUyTl4HxU=.e8b89be3-da28-4f97-b335-6bd09d39993e@github.com>
Message-ID: <A2Xr4W05-WFRycXTyGWEtlo1Sy9mnD_1xHLEFyXxavE=.7001504d-b239-4af2-8b27-0b7ab45670a3@github.com>

On Tue, 20 Dec 2022 08:29:09 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> Today when oops are read from nmethods, we use the same interfacing that we would use to read any other IN_NATIVE oops. That isn't enough for generational ZGC. The nmethod oops are rather different from other IN_NATIVE oops in that they are encoded in the machine code as direct pointers. Normally, IN_NATIVE oops with generational ZGC are not direct pointers, but are colored pointered that can be converted to direct pointers by going through a load barrier. For nmethod oops, that conversion requires external knowledge from the surrounding nmethod. I propose a new NMethodAccess to interface better with the GC.

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11738

From sspitsyn at openjdk.org  Wed Dec 21 21:14:51 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 21 Dec 2022 21:14:51 GMT
Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling
 one virtual thread transitions [v3]
In-Reply-To: <FDyv8oX5HVbkRMGV2q86Zv5iRrNEf4YQ0J2RbwxE4aU=.7457681a-5149-4fa2-baaf-15484a58f267@github.com>
References: <z8NCIbPeF0WzTEzXGyNxlnuOF_52vbV90p4B15xThFk=.b12cfe49-d27d-4e65-9027-796985005c14@github.com>
 <FDyv8oX5HVbkRMGV2q86Zv5iRrNEf4YQ0J2RbwxE4aU=.7457681a-5149-4fa2-baaf-15484a58f267@github.com>
Message-ID: <G370oypp5RYcXMh8W-vL1oG1S6SDzWM3foYBhPRnngU=.d606629b-d87d-405e-b57e-3101f0771cd0@github.com>

On Tue, 20 Dec 2022 20:52:10 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Now the `JvmtiVTMSTransitionDisabler` mechanism supports disabling VTMS transitions for all virtual threads only. It should also support disabling transitions for any specific virtual thread as well. This will improve scalability of the JVMTI functions operating on target virtual threads as the functions can be executed concurrently without blocking each other execution when target virtual threads are different.
>> New constructor `JvmtiVTMSTransitionDisabler(jthread vthread)` is added which has jthread parameter of the target virtual thread.
>> 
>> Testing:
>>   mach5 jobs are TBD (preliminary testing was completed):
>>    - all JVMTI, JDWP, JDI and JDB tests have to be run
>>    - Kitchensink
>>    - tier5
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address wqsecond round review comments

David, thank you a lot for review!

-------------

PR: https://git.openjdk.org/jdk/pull/11690

From sspitsyn at openjdk.org  Wed Dec 21 21:14:53 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 21 Dec 2022 21:14:53 GMT
Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling
 one virtual thread transitions [v3]
In-Reply-To: <Ht7qFb5htBFbSLuCZ-dA1IUc_cI-2YOS894SojO6wbg=.bd65f2d0-fc22-4e3e-b243-e152a3bd671f@github.com>
References: <z8NCIbPeF0WzTEzXGyNxlnuOF_52vbV90p4B15xThFk=.b12cfe49-d27d-4e65-9027-796985005c14@github.com>
 <FDyv8oX5HVbkRMGV2q86Zv5iRrNEf4YQ0J2RbwxE4aU=.7457681a-5149-4fa2-baaf-15484a58f267@github.com>
 <Ht7qFb5htBFbSLuCZ-dA1IUc_cI-2YOS894SojO6wbg=.bd65f2d0-fc22-4e3e-b243-e152a3bd671f@github.com>
Message-ID: <OvwJurM11fILwrAsACvk6_VRKaAg11TPX6eEiYVb1GM=.d320a011-f6fc-4799-9e86-220cb9bc1752@github.com>

On Wed, 21 Dec 2022 09:31:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address wqsecond round review comments
>
> src/hotspot/share/classfile/javaClasses.cpp line 1739:
> 
>> 1737: void java_lang_Thread::inc_VTMS_transition_disable_count(oop java_thread) {
>> 1738:   int val = VTMS_transition_disable_count(java_thread);
>> 1739:   assert(JvmtiVTMSTransition_lock->is_locked(), "Must be locked");
> 
> You want to use `owned_by_self()` for these assertions - thanks.

You are right. Fixed now.

-------------

PR: https://git.openjdk.org/jdk/pull/11690

From sspitsyn at openjdk.org  Wed Dec 21 21:14:54 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 21 Dec 2022 21:14:54 GMT
Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling
 one virtual thread transitions [v3]
In-Reply-To: <50W4OIGSyCQhBbg0qJ2Ie_9H-R0LSsWJqCT_E5FR7KI=.803c3631-2f33-41e7-b7fb-ef85ded74f03@github.com>
References: <z8NCIbPeF0WzTEzXGyNxlnuOF_52vbV90p4B15xThFk=.b12cfe49-d27d-4e65-9027-796985005c14@github.com>
 <avFztZhk1NDj_YekziZXXUKwiuGEWhFWabEsn010qmY=.07faf892-3bdb-4ea9-92a1-4763c77315a0@github.com>
 <qMgIdVTFTLxfv9yv-I3_XXlTd18VcycuFEkCVRQy4fk=.48f36b22-a8ff-438a-b517-18cd82441401@github.com>
 <FciN5R1fhkiQICgwQWzP9uPvPfuG1zVcnAqdlxZvEEM=.08d708c3-03a6-4d9f-a842-16951632668d@github.com>
 <-fbjOn9Wsqar-pUqBT_qNslZvj7qBmTnWuTEkuZFt-M=.85e31c4e-0371-4aac-81f3-e37475abde10@github.com>
 <50W4OIGSyCQhBbg0qJ2Ie_9H-R0LSsWJqCT_E5FR7KI=.803c3631-2f33-41e7-b7fb-ef85ded74f03@github.com>
Message-ID: <h1PP4PQv4tqOF4gIf5Vll_DjeZ-W6hcrIQSJzE8lZ7Q=.52327ce8-2d42-49fe-9c2a-a0133daa2495@github.com>

On Tue, 20 Dec 2022 10:22:03 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This can be a separate RFE if the reason for it being a nosafepoint lock no longer holds. It would be cleaner to use a normal safepoint checking lock than to artificially make the thread safepoint-safe before using it.
>
> Agreed. I was thinking about a separate RFE. I started seeing some failures in the S/R related tests with the removed `ThreadBlockInVM` and `_no_safepoint_check_flag`. Need to investigated why. Otherwise, it seems to be working well.

As I see there can be some problems with the JVMTI Suspend/Resume but it is worth to investigate anyway.
So, I've filed an RFE:
[JDK-8299240](https://bugs.openjdk.org/browse/JDK-8299240): rank of JvmtiVTMSTransition_lock can be safepoint

-------------

PR: https://git.openjdk.org/jdk/pull/11690

From sspitsyn at openjdk.org  Wed Dec 21 21:33:28 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 21 Dec 2022 21:33:28 GMT
Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling
 one virtual thread transitions [v4]
In-Reply-To: <z8NCIbPeF0WzTEzXGyNxlnuOF_52vbV90p4B15xThFk=.b12cfe49-d27d-4e65-9027-796985005c14@github.com>
References: <z8NCIbPeF0WzTEzXGyNxlnuOF_52vbV90p4B15xThFk=.b12cfe49-d27d-4e65-9027-796985005c14@github.com>
Message-ID: <goPSrd1KFzUyD3FjIgzJuBrBnfAzOy5gHakGaVWo-Vc=.a2812923-b41e-490f-bb7c-dd7e87976ef1@github.com>

> Now the `JvmtiVTMSTransitionDisabler` mechanism supports disabling VTMS transitions for all virtual threads only. It should also support disabling transitions for any specific virtual thread as well. This will improve scalability of the JVMTI functions operating on target virtual threads as the functions can be executed concurrently without blocking each other execution when target virtual threads are different.
> New constructor `JvmtiVTMSTransitionDisabler(jthread vthread)` is added which has jthread parameter of the target virtual thread.
> 
> Testing:
>   mach5 jobs are TBD (preliminary testing was completed):
>    - all JVMTI, JDWP, JDI and JDB tests have to be run
>    - Kitchensink
>    - tier5

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  use owned_by_self vs is_locked in JvmtiVTMSTransition_lock asserts

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11690/files
  - new: https://git.openjdk.org/jdk/pull/11690/files/7783992f..3c73fae3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11690&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11690&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11690.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11690/head:pull/11690

PR: https://git.openjdk.org/jdk/pull/11690

From jwilhelm at openjdk.org  Wed Dec 21 23:25:52 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Wed, 21 Dec 2022 23:25:52 GMT
Subject: RFR: Merge jdk20
Message-ID: <0xaeZuF6GgxwolCQSpQDkMLgWEclWAxo-1ap7iRED9A=.bc32b592-312b-4593-8307-19436a758d77@github.com>

Forwardport JDK 20 -> JDK 21

-------------

Commit messages:
 - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20
 - 8298893: Rename option UsePolyIntrinsics to UsePoly1305Intrinsics
 - 8298726: (fs) Change PollingWatchService to record last modified time as FileTime rather than milliseconds
 - 8298642: ParallelGC -XX:+UseNUMA eden spaces allocated on wrong node
 - 8298588: WebSockets: HandshakeUrlEncodingTest unnecessarily depends on a response body
 - 8299156: Broken link in jdk.compiler/module-info.java
 - 8298947: compiler/codecache/MHIntrinsicAllocFailureTest.java fails intermittently
 - 8299147: Minor accessibility errors in the specs and man index pages

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jdk/pull/11759/files
  Stats: 16 lines in 9 files changed: 4 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/11759.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11759/head:pull/11759

PR: https://git.openjdk.org/jdk/pull/11759

From dholmes at openjdk.org  Wed Dec 21 23:38:49 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 21 Dec 2022 23:38:49 GMT
Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling
 one virtual thread transitions [v4]
In-Reply-To: <goPSrd1KFzUyD3FjIgzJuBrBnfAzOy5gHakGaVWo-Vc=.a2812923-b41e-490f-bb7c-dd7e87976ef1@github.com>
References: <z8NCIbPeF0WzTEzXGyNxlnuOF_52vbV90p4B15xThFk=.b12cfe49-d27d-4e65-9027-796985005c14@github.com>
 <goPSrd1KFzUyD3FjIgzJuBrBnfAzOy5gHakGaVWo-Vc=.a2812923-b41e-490f-bb7c-dd7e87976ef1@github.com>
Message-ID: <8gjfuA4VUyyPnIy8p9AphoKnGkXGngZH8tUNtRKXrBY=.6b9c4e77-ea59-4c6e-96a2-040568a5d38f@github.com>

On Wed, 21 Dec 2022 21:33:28 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Now the `JvmtiVTMSTransitionDisabler` mechanism supports disabling VTMS transitions for all virtual threads only. It should also support disabling transitions for any specific virtual thread as well. This will improve scalability of the JVMTI functions operating on target virtual threads as the functions can be executed concurrently without blocking each other execution when target virtual threads are different.
>> New constructor `JvmtiVTMSTransitionDisabler(jthread vthread)` is added which has jthread parameter of the target virtual thread.
>> 
>> Testing:
>>   mach5 jobs are TBD (preliminary testing was completed):
>>    - all JVMTI, JDWP, JDI and JDB tests have to be run
>>    - Kitchensink
>>    - tier5
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use owned_by_self vs is_locked in JvmtiVTMSTransition_lock asserts

Marked as reviewed by dholmes (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11690

From jwilhelm at openjdk.org  Wed Dec 21 23:53:56 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Wed, 21 Dec 2022 23:53:56 GMT
Subject: Integrated: Merge jdk20
In-Reply-To: <0xaeZuF6GgxwolCQSpQDkMLgWEclWAxo-1ap7iRED9A=.bc32b592-312b-4593-8307-19436a758d77@github.com>
References: <0xaeZuF6GgxwolCQSpQDkMLgWEclWAxo-1ap7iRED9A=.bc32b592-312b-4593-8307-19436a758d77@github.com>
Message-ID: <fk09a_rJzzd5ENJyEkwmohXv1-vcdSSjCbh_EqtL3yo=.27c8aaf5-693f-4c33-88ff-f04c6bee857f@github.com>

On Wed, 21 Dec 2022 23:18:08 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 20 -> JDK 21

This pull request has now been integrated.

Changeset: 34cdda5b
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/34cdda5b8359cce33c2d4f92a41a620aea4f96e7
Stats:     16 lines in 9 files changed: 4 ins; 0 del; 12 mod

Merge

-------------

PR: https://git.openjdk.org/jdk/pull/11759

From kbarrett at openjdk.org  Thu Dec 22 02:12:47 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 22 Dec 2022 02:12:47 GMT
Subject: [jdk20] RFR: 8293824: gc/whitebox/TestConcMarkCycleWB.java failed
 "RuntimeException: assertTrue: expected true, was false"
Message-ID: <-LJBut4ETHYR8IDgKzvkumizSmDfB5uPUys0F282gfc=.152bea6b-1156-4280-a149-2cfe3a234a9c@github.com>

Please review this change to WhiteBox and some tests involving G1 concurrent GCs.

Some tests currently use WhiteBox.g1StartConcMarkCycle() to trigger a
concurrent GC.  Many of them follow it with a loop waiting for a concurrent
cycle to not be in progress.  A few also preceed that call with a similar
loop, since that call does nothing and returns false if a concurrent cycle is
already in progress.  Those tests typically want to ensure there was a
concurrent cycle that was started after some setup.

The failing test calls that function, asserting that it returned true, e.g. a
new concurrent cycle was started.

There are various problems with this, due to races with concurrent cycles
started automatically, and due to possibly aborted (by full GCs) concurrent cycles,
making some of these tests unreliable in some configurations.

For example, the test failure associated with this bug intermittently arises
when running with `-Xcomp`, triggering a concurrent cycle before the explicit
request by the test, causing the explicit request to fail (because there is
already one in progress), failing the assert.  Waiting for there not to be an
in-progress cycle before the explicit request just narrows the race window.

We have a different mechanism in WhiteBox for controlling concurrent cycles,
the concurrent GC breakpoint mechanism.  By adding a counter specifically for
such cycles, we can use GC breakpoints to ensure only the concurrent cycles
the test wants are occurring, and can verify they completed successfully.

So we change tests using WhiteBox.g1StartConcMarkCycle() to instead use GC
breakpoints, along with the new WhiteBox.g1CompletedConcurrentMarkCycles() to
avoid racing request problems and to detect aborted cycles.  Since it is no
longer used, WhiteBox.g1StartConcMarkCycle() is removed.  The test that began
this adventure (TestConcMarkCycleWB.java) is also removed, since it no longer
serves any purpose, having been purely a test of that removed function.

Testing:
mach5 tier1-7 - running the changed tests on a variety of platforms with a
variety of configurations.

-------------

Commit messages:
 - use gc breakpoints to perform conc gc

Changes: https://git.openjdk.org/jdk20/pull/71/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=71&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293824
  Stats: 288 lines in 24 files changed: 98 ins; 131 del; 59 mod
  Patch: https://git.openjdk.org/jdk20/pull/71.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/71/head:pull/71

PR: https://git.openjdk.org/jdk20/pull/71

From fyang at openjdk.org  Thu Dec 22 03:30:51 2022
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 22 Dec 2022 03:30:51 GMT
Subject: RFR: 8299162: Refactor shared trampoline emission logic
In-Reply-To: <AL-gr6iomKiTRXxy3U3QB6pU-jk8RQvaCi5uWt4Dfuw=.244449d5-4abe-441a-b2a1-9926173e73e6@github.com>
References: <AL-gr6iomKiTRXxy3U3QB6pU-jk8RQvaCi5uWt4Dfuw=.244449d5-4abe-441a-b2a1-9926173e73e6@github.com>
Message-ID: <Wz3Jy5s2Fuee3akhVclkc3CJ7FsdtNU9P7TjYUd_3mc=.d4ae65bc-16ee-4d97-b134-d3cad8d5c4ac@github.com>

On Wed, 21 Dec 2022 03:39:15 GMT, Xiaolin Zheng <xlinzheng at openjdk.org> wrote:

> After the quick fix [JDK-8297763](https://bugs.openjdk.org/browse/JDK-8297763), shared trampoline logic gets a bit verbose. If we can turn to batch emission of trampoline stubs, pre-calculating the total size, and pre-allocating them, then we can remove the CodeBuffer expansion checks each time and clean up the code around.
> 
> 
> [Stub Code]
> ...
> <shared trampoline stub1, (A):>
>   __ align()  // emit nothing or a 4-byte padding
>               <-- (B) emit multiple relocations at the pc: __ relocate(<the pc here>, trampoline_stub_Relocation::spec())
>   __ ldr()
>   __ br()
>   __ emit_int64()
> <shared trampoline stub2, (C):>
>   __ align()  // emit nothing or a 4-byte padding
>               <-- emit multiple relocations at the pc: __ relocate(<the pc here>, trampoline_stub_Relocation::spec())
>   __ ldr()    
>   __ br()
>   __ emit_int64()
> <shared trampoline stub3:>
>   __ align()  // emit nothing or a 4-byte padding
>               <-- emit multiple relocations at the pc: __ relocate(<the pc here>, trampoline_stub_Relocation::spec())
>   __ ldr()
>   __ br()
>   __ emit_int64()
> 
> 
> Here, the `pc_at_(C) - pc_at_(B)` is the fixed length `NativeCallTrampolineStub::instruction_size`; but the `pc_at_(B) - pc_at_(A)` may be a 0 or 4, which is not a fixed-length value.
> 
> So originally:
> The logic of the lambda `emit()` inside the `emit_shared_trampolines()` when emitting a shared trampoline:
> 
> We are at (A) -> 
> do an align() -> 
> We are at (B) -> 
> emit lots of relocations bound to this shared trampoline at (B) -> 
> do an emit_trampoline_stub() -> 
> We are at (C)
> 
> 
> After this patch:
> 
> We are at (A) -> 
> do an emit_trampoline_stub(), which contains an align() already ->
> We are at (C) directly ->
> reversely calculate the (B) address, for `pc_at_(C) - pc_at_(B)` is a fixed-length value -> 
> emit lots of relocations bound to this shared trampoline at (B)
> 
> 
> Theoretically the same. Just a code refactoring and we can remove some checks inside and make the code clean.
> 
> Tested AArch64 hotspot tier1~4 with fastdebug build twice; Tested RISC-V hotspot tier1~4 with fastdebug build on hardware once.
> 
> 
> Thanks,
> Xiaolin

I see you switched to use the __ idiom. Could you please keep a new line after the macro definition and before un-definition?

-------------

Changes requested by fyang (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11749

From xlinzheng at openjdk.org  Thu Dec 22 03:44:11 2022
From: xlinzheng at openjdk.org (Xiaolin Zheng)
Date: Thu, 22 Dec 2022 03:44:11 GMT
Subject: RFR: 8299162: Refactor shared trampoline emission logic [v2]
In-Reply-To: <AL-gr6iomKiTRXxy3U3QB6pU-jk8RQvaCi5uWt4Dfuw=.244449d5-4abe-441a-b2a1-9926173e73e6@github.com>
References: <AL-gr6iomKiTRXxy3U3QB6pU-jk8RQvaCi5uWt4Dfuw=.244449d5-4abe-441a-b2a1-9926173e73e6@github.com>
Message-ID: <2AQOqhItBwarWAAf3o64HQnJqGLN7hRd96krydvJxeM=.22d31e24-c43d-44fb-b54b-d1ea86893883@github.com>

> After the quick fix [JDK-8297763](https://bugs.openjdk.org/browse/JDK-8297763), shared trampoline logic gets a bit verbose. If we can turn to batch emission of trampoline stubs, pre-calculating the total size, and pre-allocating them, then we can remove the CodeBuffer expansion checks each time and clean up the code around.
> 
> 
> [Stub Code]
> ...
> <shared trampoline stub1, (A):>
>   __ align()  // emit nothing or a 4-byte padding
>               <-- (B) emit multiple relocations at the pc: __ relocate(<the pc here>, trampoline_stub_Relocation::spec())
>   __ ldr()
>   __ br()
>   __ emit_int64()
> <shared trampoline stub2, (C):>
>   __ align()  // emit nothing or a 4-byte padding
>               <-- emit multiple relocations at the pc: __ relocate(<the pc here>, trampoline_stub_Relocation::spec())
>   __ ldr()    
>   __ br()
>   __ emit_int64()
> <shared trampoline stub3:>
>   __ align()  // emit nothing or a 4-byte padding
>               <-- emit multiple relocations at the pc: __ relocate(<the pc here>, trampoline_stub_Relocation::spec())
>   __ ldr()
>   __ br()
>   __ emit_int64()
> 
> 
> Here, the `pc_at_(C) - pc_at_(B)` is the fixed length `NativeCallTrampolineStub::instruction_size`; but the `pc_at_(B) - pc_at_(A)` may be a 0 or 4, which is not a fixed-length value.
> 
> So originally:
> The logic of the lambda `emit()` inside the `emit_shared_trampolines()` when emitting a shared trampoline:
> 
> We are at (A) -> 
> do an align() -> 
> We are at (B) -> 
> emit lots of relocations bound to this shared trampoline at (B) -> 
> do an emit_trampoline_stub() -> 
> We are at (C)
> 
> 
> After this patch:
> 
> We are at (A) -> 
> do an emit_trampoline_stub(), which contains an align() already ->
> We are at (C) directly ->
> reversely calculate the (B) address, for `pc_at_(C) - pc_at_(B)` is a fixed-length value -> 
> emit lots of relocations bound to this shared trampoline at (B)
> 
> 
> Theoretically the same. Just a code refactoring and we can remove some checks inside and make the code clean.
> 
> Tested AArch64 hotspot tier1~4 with fastdebug build twice; Tested RISC-V hotspot tier1~4 with fastdebug build on hardware once.
> 
> 
> Thanks,
> Xiaolin

Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision:

  __

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11749/files
  - new: https://git.openjdk.org/jdk/pull/11749/files/ac93f3c6..aefe74ff

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11749&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11749&range=00-01

  Stats: 6 lines in 3 files changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11749.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11749/head:pull/11749

PR: https://git.openjdk.org/jdk/pull/11749

From dholmes at openjdk.org  Thu Dec 22 04:30:51 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 22 Dec 2022 04:30:51 GMT
Subject: RFR: 8299079: Better interface nmethod oop accesses
In-Reply-To: <XUnYphaHNdOvTPk48hRm_9-brWEJN6o22iMUyTl4HxU=.e8b89be3-da28-4f97-b335-6bd09d39993e@github.com>
References: <XUnYphaHNdOvTPk48hRm_9-brWEJN6o22iMUyTl4HxU=.e8b89be3-da28-4f97-b335-6bd09d39993e@github.com>
Message-ID: <2yCreauBOu1kZYsjdROSSjgVng0Woy4AdVVmlxsMI8I=.a7154dfe-7631-4e56-8573-fd71b83b96ad@github.com>

On Tue, 20 Dec 2022 08:29:09 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> Today when oops are read from nmethods, we use the same interfacing that we would use to read any other IN_NATIVE oops. That isn't enough for generational ZGC. The nmethod oops are rather different from other IN_NATIVE oops in that they are encoded in the machine code as direct pointers. Normally, IN_NATIVE oops with generational ZGC are not direct pointers, but are colored pointered that can be converted to direct pointers by going through a load barrier. For nmethod oops, that conversion requires external knowledge from the surrounding nmethod. I propose a new NMethodAccess to interface better with the GC.

A couple of minor nits, but the new API looks fine. Thanks.

src/hotspot/share/code/nmethod.cpp line 1465:

> 1463:     return NULL;
> 1464:   }
> 1465: 

Nit: the extra blank lines are unnecessary.

src/hotspot/share/oops/access.hpp line 289:

> 287: 
> 288: // Helper for performing accesses in nmethods. These accesses
> 289: // may resolve an accessor on a GC barrier set

Nit: period at end of sentence please.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11738

From jwaters at openjdk.org  Thu Dec 22 04:50:50 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Dec 2022 04:50:50 GMT
Subject: RFR: 8274400: HotSpot Style Guide should permit use of alignof
Message-ID: <3IdeZGaGcFB1-DbVugn0P9v8vRQMLURzHFRSpAm46NA=.09bf4dd8-b652-49c3-b9a5-ad3f58dfbcc3@github.com>

The alignof operator was added by C++11. It returns the alignment for the given type. Various metaprogramming usages exist, in particular when using std::aligned_storage. Use of this operator should be permitted in HotSpot code.

-------------

Commit messages:
 - HotSpot Style Guide should permit use of alignof

Changes: https://git.openjdk.org/jdk/pull/11761/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11761&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8274400
  Stats: 5 lines in 2 files changed: 5 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11761.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11761/head:pull/11761

PR: https://git.openjdk.org/jdk/pull/11761

From jwaters at openjdk.org  Thu Dec 22 04:50:50 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Dec 2022 04:50:50 GMT
Subject: RFR: 8274400: HotSpot Style Guide should permit use of alignof
In-Reply-To: <3IdeZGaGcFB1-DbVugn0P9v8vRQMLURzHFRSpAm46NA=.09bf4dd8-b652-49c3-b9a5-ad3f58dfbcc3@github.com>
References: <3IdeZGaGcFB1-DbVugn0P9v8vRQMLURzHFRSpAm46NA=.09bf4dd8-b652-49c3-b9a5-ad3f58dfbcc3@github.com>
Message-ID: <pbikN3xFFL-Iu0P9eDsKbymzB4q9eNK_xSaXFGFiPyg=.3c1a7d5d-79c8-4388-a6e9-101d43c83f94@github.com>

On Thu, 22 Dec 2022 04:39:47 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> The alignof operator was added by C++11. It returns the alignment for the given type. Various metaprogramming usages exist, in particular when using std::aligned_storage. Use of this operator should be permitted in HotSpot code.

I do have a more detailed writeup sitting around, but ultimately decided it was overkill for such a simple operator. I will leave it here for now though


### alignof

`alignof`
([n2341](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2341.pdf))
is permitted alongside `alignas` for querying the alignment of a complete object
type, an array type with a complete element type, or a reference type to either as
an alternative to `std::alignment_of<>`. `std::alignment_of<>` precedes the
operator in the development of the language and just returns the corresponding
`alignof` value, the operator simply provides less verbose syntax for doing so.

-------------

PR: https://git.openjdk.org/jdk/pull/11761

From jwaters at openjdk.org  Thu Dec 22 04:51:27 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Dec 2022 04:51:27 GMT
Subject: RFR: 8250269: Replace ATTRIBUTE_ALIGNED with alignas [v5]
In-Reply-To: <9QKV9cYFTo_1D8R-mI80lnewNkA0ceJNKFPbrvICxl4=.d6736b76-8324-4084-bede-6e144b4f6c04@github.com>
References: <9QKV9cYFTo_1D8R-mI80lnewNkA0ceJNKFPbrvICxl4=.d6736b76-8324-4084-bede-6e144b4f6c04@github.com>
Message-ID: <kb42cdMSGRL4d7zdhZ-SO9yfctZ1wGMuqCXg-BhMFlU=.0edb7f71-222a-4dca-a3e4-dc6d0f09497b@github.com>

> C++11 added the alignas attribute, for the purpose of specifying alignment on types, much like compiler specific syntax such as gcc's __attribute__((aligned(x))) or Visual C++'s __declspec(align(x)).
> 
> We can phase out the use of the macro in favor of the standard attribute. In the meantime, we can replace the toolchain specific definitions of ATTRIBUTE_ALIGNED with a portable definition. We might deprecate the use of the macro but changing its implementation quickly and cleanly applies the feature where the macro is being used.
> 
> Note: With certain parts of HotSpot using ATTRIBUTE_ALIGNED so indiscriminately, this commit will likely take some time to get right
> 
> This will require adding the alignas attribute to the list of language features approved for use in HotSpot code. (Ongoing at [8297912](https://github.com/openjdk/jdk/pull/11446))

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 four additional commits since the last revision:

 - Merge branch 'openjdk:master' into alignas
 - Merge branch 'openjdk:master' into alignas
 - Merge branch 'openjdk:master' into alignas
 - alignas

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11431/files
  - new: https://git.openjdk.org/jdk/pull/11431/files/1d69a46f..3f3a3625

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11431&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11431&range=03-04

  Stats: 5442 lines in 254 files changed: 3263 ins; 990 del; 1189 mod
  Patch: https://git.openjdk.org/jdk/pull/11431.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11431/head:pull/11431

PR: https://git.openjdk.org/jdk/pull/11431

From jwaters at openjdk.org  Thu Dec 22 04:57:28 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Dec 2022 04:57:28 GMT
Subject: RFR: 8250269: Replace ATTRIBUTE_ALIGNED with alignas [v6]
In-Reply-To: <9QKV9cYFTo_1D8R-mI80lnewNkA0ceJNKFPbrvICxl4=.d6736b76-8324-4084-bede-6e144b4f6c04@github.com>
References: <9QKV9cYFTo_1D8R-mI80lnewNkA0ceJNKFPbrvICxl4=.d6736b76-8324-4084-bede-6e144b4f6c04@github.com>
Message-ID: <hiKTODg7TexH-sB4tWWIN7fshQ_At_eUN7c5dVZ5f-k=.c0310be1-4be8-49ec-bfa9-680895dd76d9@github.com>

> C++11 added the alignas attribute, for the purpose of specifying alignment on types, much like compiler specific syntax such as gcc's __attribute__((aligned(x))) or Visual C++'s __declspec(align(x)).
> 
> We can phase out the use of the macro in favor of the standard attribute. In the meantime, we can replace the compiler specific definitions of ATTRIBUTE_ALIGNED with a portable definition. We might deprecate the use of the macro but changing its implementation quickly and cleanly applies the feature where the macro is being used.
> 
> Note: With certain parts of HotSpot using ATTRIBUTE_ALIGNED so indiscriminately, this commit will likely take some time to get right
> 
> This will require adding the alignas attribute to the list of language features approved for use in HotSpot code. (Completed with [8297912](https://github.com/openjdk/jdk/pull/11446))

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  ATTRIBUTE_ALIGNED(16)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11431/files
  - new: https://git.openjdk.org/jdk/pull/11431/files/3f3a3625..ea968de2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11431&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11431&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11431.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11431/head:pull/11431

PR: https://git.openjdk.org/jdk/pull/11431

From dholmes at openjdk.org  Thu Dec 22 08:03:26 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 22 Dec 2022 08:03:26 GMT
Subject: RFR: 8295974: jni_FatalError and Xcheck:jni warnings should print
 the native stack when there are no Java frames [v2]
In-Reply-To: <s_Ttmm80UcUu6OOWSZKD95u18WWZufwlMKPW-Gw9ZeE=.b77b8d96-8249-4754-8a0f-1bcf032f465c@github.com>
References: <s_Ttmm80UcUu6OOWSZKD95u18WWZufwlMKPW-Gw9ZeE=.b77b8d96-8249-4754-8a0f-1bcf032f465c@github.com>
Message-ID: <1PhUGM_yK7Mub10f-HfRxTGPwml6DMV6ayQ2ARZaHAQ=.40a1c60b-cc85-4c16-b29f-e8a9b1d0910e@github.com>

> If a JNI Fatal error, or a JNI warning (from Xcheck:jni) is triggered in "top-level" native code (such as the launcher itself, or a freshly attached native thread) then there is no stack printed as there are no Java frames. This enhancement changes that so that we print the native stack, similarly to how error reporting does. We reuse VMError::print_native _stack to do this, but it could be argued this should be moved to a more general purpose utility class - suggestions welcome.
> 
> Testing:
>   - manual fault injection (see bug report)
>   - tiers 1-4
> 
> Thanks.

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Added a regression test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11703/files
  - new: https://git.openjdk.org/jdk/pull/11703/files/e5df3b2c..c85b30b8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11703&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11703&range=00-01

  Stats: 185 lines in 2 files changed: 185 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11703.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11703/head:pull/11703

PR: https://git.openjdk.org/jdk/pull/11703

From lkorinth at openjdk.org  Thu Dec 22 10:59:44 2022
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 22 Dec 2022 10:59:44 GMT
Subject: RFR: 8296401: ConcurrentHashTable::bulk_delete might miss to
 delete some objects [v6]
In-Reply-To: <rWw3Hb1baG5eslMgFnOdEP1Q4avhfYc3uTpjdB9DaP0=.23f34ff0-eff9-421b-9e70-7f119fd90e5d@github.com>
References: <rWw3Hb1baG5eslMgFnOdEP1Q4avhfYc3uTpjdB9DaP0=.23f34ff0-eff9-421b-9e70-7f119fd90e5d@github.com>
Message-ID: <UeuY3UfyEXh5PJ66fxOcNfHahQkXbdZXLB7wkBH9edw=.5560b0d8-0082-4102-abd8-64b430beca04@github.com>

> ConcurrentHashTable::bulk_delete might miss to delete some objects if a bucket has more than 256 entries. Current uses of ConcurrentHashTable are not harmed by this behaviour. 
> 
> I modified gtest:ConcurrentHashTable to detect the problem (first commit), and fixed the problem in the code (second commit).
> 
> Tests passes tier1-3.

Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:

  growable array is limited by (signed) int, this should not be a problem

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10983/files
  - new: https://git.openjdk.org/jdk/pull/10983/files/9cae9ddb..b9d8b105

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10983&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10983&range=04-05

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10983.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10983/head:pull/10983

PR: https://git.openjdk.org/jdk/pull/10983

From lkorinth at openjdk.org  Thu Dec 22 11:02:53 2022
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 22 Dec 2022 11:02:53 GMT
Subject: RFR: 8296401: ConcurrentHashTable::bulk_delete might miss to
 delete some objects [v5]
In-Reply-To: <3Fnpqamf7GB_EaNVYVO-yuykUOzwhOOCOf_sIBE4334=.7951828c-1e7f-499c-883c-a2f239df28c0@github.com>
References: <rWw3Hb1baG5eslMgFnOdEP1Q4avhfYc3uTpjdB9DaP0=.23f34ff0-eff9-421b-9e70-7f119fd90e5d@github.com>
 <3Fnpqamf7GB_EaNVYVO-yuykUOzwhOOCOf_sIBE4334=.7951828c-1e7f-499c-883c-a2f239df28c0@github.com>
Message-ID: <3lzz74O8ahZS0VqjP0oHSMclT8rl3j5F-pu_8mYwgMo=.9073e108-3286-4f7d-a2f8-2ebd53b809f3@github.com>

On Fri, 9 Dec 2022 19:54:48 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> ConcurrentHashTable::bulk_delete might miss to delete some objects if a bucket has more than 256 entries. Current uses of ConcurrentHashTable are not harmed by this behaviour. 
>> 
>> I modified gtest:ConcurrentHashTable to detect the problem (first commit), and fixed the problem in the code (second commit).
>> 
>> Tests passes tier1-3.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   GrowableArray is indexed by int :-(

Hi, I just updated the code to use a `guarantee` line. I would have preferred to have a growable aray  that is not limited by an `int`. If we get 2^31 element buckets, I think it is best to exit the VM...

-------------

PR: https://git.openjdk.org/jdk/pull/10983

From redestad at openjdk.org  Thu Dec 22 13:12:54 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 22 Dec 2022 13:12:54 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v13]
In-Reply-To: <HcQ7WJUZIa-jvv-COz7L3XGOLqMkV5fHf_l-4tmdj6k=.8ba6ebce-b84c-4bfd-954d-44ca693421b8@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <pW8HHmh-dQnjrRftd052fBQVulqe_z5KldY76Hp-OmI=.a7a2b6e6-a182-45d2-bd11-16a406126482@github.com>
 <6lAQI6kDDTGbskylHcWReX8ExaB6qkwgqoai7E6ikZY=.8a69a63c-453d-4bbd-8c76-4d477bfb77fe@github.com>
 <mAsTs03BWlAM_YhHXHBNsaJIQqrX95deQyYAYkJwrmE=.7e36f69c-dffc-462a-bf8a-7614153bf8c4@github.com>
 <PrXrcgFzP4mr0ZI5WrUizT0Sz_wtTl6AJLS_mvW89dQ=.ae6c18d4-8f5e-48cf-b0bf-8d8db7852346@github.com>
 <a_7dEeMU-LeSDU1irFR-zAjfM_zKhnosJmEe19TyQsA=.d94df28d-8a97-4463-a3f5-e5e39d6b21e4@github.com>
 <HcQ7WJUZIa-jvv-COz7L3XGOLqMkV5fHf_l-4tmdj6k=.8ba6ebce-b84c-4bfd-954d-44ca693421b8@github.com>
Message-ID: <GwPWVNPHk3QnaOvUHwLV8skXet8ybGQ6Wgi4es9Ds1s=.cb28475d-97fd-422b-aa6e-694f32314e21@github.com>

On Wed, 21 Dec 2022 00:11:34 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Passing the constant node through as an input as suggested by @iwanowww and @sviswa7 meant we could eliminate most of the `instruct` blocks, removing a significant chunk of code and a little bit of complexity from the proposed patch.
>
> @cl4es Thanks for passing the constant node through, the code looks much cleaner now. The attached patch should handle the signed bytes/shorts as well. Please take a look. 
> [signed.patch](https://github.com/openjdk/jdk/files/10273480/signed.patch)

I ran tests and some quick microbenchmarking to validate @sviswa7's patch to activate vectorization for `short` and `byte` arrays and it looks good:

Before:

Benchmark                   (size)  Mode  Cnt     Score    Error  Units
ArraysHashCode.bytes         10000  avgt    5  7845.586 ? 23.440  ns/op
ArraysHashCode.chars         10000  avgt    5  1203.163 ? 11.995  ns/op
ArraysHashCode.ints          10000  avgt    5  1131.915 ?  7.843  ns/op
ArraysHashCode.multibytes    10000  avgt    5  4136.487 ?  5.790  ns/op
ArraysHashCode.multichars    10000  avgt    5   671.328 ? 17.629  ns/op
ArraysHashCode.multiints     10000  avgt    5   699.051 ?  8.135  ns/op
ArraysHashCode.multishorts   10000  avgt    5  4139.300 ? 10.633  ns/op
ArraysHashCode.shorts        10000  avgt    5  7844.019 ? 26.071  ns/op


After: 

Benchmark                   (size)  Mode  Cnt     Score    Error  Units
ArraysHashCode.bytes         10000  avgt    5  1193.208 ?  1.965  ns/op
ArraysHashCode.chars         10000  avgt    5  1193.311 ?  5.941  ns/op
ArraysHashCode.ints          10000  avgt    5  1132.592 ? 10.410  ns/op
ArraysHashCode.multibytes    10000  avgt    5   657.343 ? 25.343  ns/op
ArraysHashCode.multichars    10000  avgt    5   672.668 ?  5.229  ns/op
ArraysHashCode.multiints     10000  avgt    5   697.143 ?  3.929  ns/op
ArraysHashCode.multishorts   10000  avgt    5   666.738 ? 12.236  ns/op
ArraysHashCode.shorts        10000  avgt    5  1193.563 ?  5.449  ns/op

-------------

PR: https://git.openjdk.org/jdk/pull/10847

From eosterlund at openjdk.org  Thu Dec 22 14:46:47 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 22 Dec 2022 14:46:47 GMT
Subject: RFR: 8299072: java_lang_ref_Reference::clear_referent should be GC
 agnostic
In-Reply-To: <8je3w2XaNdQEAKx0lLHp2T2UXkOUqEV0ks-2TFL2AJE=.fbf307d0-9833-4465-a914-3a7e9f05d12b@github.com>
References: <TdoMMvxcNRmL_AxzSGZeTXt79zn0zOAjM31mgC7i3t0=.a3605d22-90b5-4cf2-97fb-eef7313d81bc@github.com>
 <8je3w2XaNdQEAKx0lLHp2T2UXkOUqEV0ks-2TFL2AJE=.fbf307d0-9833-4465-a914-3a7e9f05d12b@github.com>
Message-ID: <xkioNNqFA9kfEw8CxzadtxeYZ02wiMhY_XGQtV1cgeY=.dc2949f2-1447-46a4-86df-d795393210c0@github.com>

On Tue, 20 Dec 2022 08:12:41 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The current java_lang_ref_Reference::clear_referent implementation performs a raw reference clear. That doesn't work well with upcoming GC algorithms. It should be made GC agnostic by going through the normal access API.
>
> So `clear_referent` is made GC agnostic, but then all the existing GC's are changed to use the original raw version? Why do they not use the GC agnostic version - performance?

Thanks for the review, @dholmes-ora!

-------------

PR: https://git.openjdk.org/jdk/pull/11736

From eosterlund at openjdk.org  Thu Dec 22 14:47:51 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 22 Dec 2022 14:47:51 GMT
Subject: RFR: 8299079: Better interface nmethod oop accesses
In-Reply-To: <A2Xr4W05-WFRycXTyGWEtlo1Sy9mnD_1xHLEFyXxavE=.7001504d-b239-4af2-8b27-0b7ab45670a3@github.com>
References: <XUnYphaHNdOvTPk48hRm_9-brWEJN6o22iMUyTl4HxU=.e8b89be3-da28-4f97-b335-6bd09d39993e@github.com>
 <A2Xr4W05-WFRycXTyGWEtlo1Sy9mnD_1xHLEFyXxavE=.7001504d-b239-4af2-8b27-0b7ab45670a3@github.com>
Message-ID: <Mpo2QQl-J39pt97qCzRK8uhwoelulNkjUTzFn3U5Zj0=.419ff475-c03e-49ff-9ab8-2be8df96439d@github.com>

On Wed, 21 Dec 2022 19:07:38 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Today when oops are read from nmethods, we use the same interfacing that we would use to read any other IN_NATIVE oops. That isn't enough for generational ZGC. The nmethod oops are rather different from other IN_NATIVE oops in that they are encoded in the machine code as direct pointers. Normally, IN_NATIVE oops with generational ZGC are not direct pointers, but are colored pointered that can be converted to direct pointers by going through a load barrier. For nmethod oops, that conversion requires external knowledge from the surrounding nmethod. I propose a new NMethodAccess to interface better with the GC.
>
> Good.

Thanks for the reviews, @vnkozlov and @dholmes-ora! Will fix the nits before integrating.

-------------

PR: https://git.openjdk.org/jdk/pull/11738

From eosterlund at openjdk.org  Thu Dec 22 14:54:05 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 22 Dec 2022 14:54:05 GMT
Subject: RFR: 8299079: Better interface nmethod oop accesses [v2]
In-Reply-To: <XUnYphaHNdOvTPk48hRm_9-brWEJN6o22iMUyTl4HxU=.e8b89be3-da28-4f97-b335-6bd09d39993e@github.com>
References: <XUnYphaHNdOvTPk48hRm_9-brWEJN6o22iMUyTl4HxU=.e8b89be3-da28-4f97-b335-6bd09d39993e@github.com>
Message-ID: <SI4sdappx4BOVOJ73YXNX6UIXNE71XpJsD0dDPC8qkk=.7f25175e-8da5-4a91-b5c5-d2ff9badd0eb@github.com>

> Today when oops are read from nmethods, we use the same interfacing that we would use to read any other IN_NATIVE oops. That isn't enough for generational ZGC. The nmethod oops are rather different from other IN_NATIVE oops in that they are encoded in the machine code as direct pointers. Normally, IN_NATIVE oops with generational ZGC are not direct pointers, but are colored pointered that can be converted to direct pointers by going through a load barrier. For nmethod oops, that conversion requires external knowledge from the surrounding nmethod. I propose a new NMethodAccess to interface better with the GC.

Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:

  Nits from David

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11738/files
  - new: https://git.openjdk.org/jdk/pull/11738/files/f9577ba8..2568b45c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11738&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11738&range=00-01

  Stats: 6 lines in 2 files changed: 0 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/11738.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11738/head:pull/11738

PR: https://git.openjdk.org/jdk/pull/11738

From coleenp at openjdk.org  Thu Dec 22 15:03:51 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 22 Dec 2022 15:03:51 GMT
Subject: RFR: 8295974: jni_FatalError and Xcheck:jni warnings should print
 the native stack when there are no Java frames [v2]
In-Reply-To: <1PhUGM_yK7Mub10f-HfRxTGPwml6DMV6ayQ2ARZaHAQ=.40a1c60b-cc85-4c16-b29f-e8a9b1d0910e@github.com>
References: <s_Ttmm80UcUu6OOWSZKD95u18WWZufwlMKPW-Gw9ZeE=.b77b8d96-8249-4754-8a0f-1bcf032f465c@github.com>
 <1PhUGM_yK7Mub10f-HfRxTGPwml6DMV6ayQ2ARZaHAQ=.40a1c60b-cc85-4c16-b29f-e8a9b1d0910e@github.com>
Message-ID: <673GZG6_4T_H9JwsuQlcGoyFMoCoAec7OcYXWFQ_JX4=.725bcc66-a73a-42b0-90a5-34e5119c1415@github.com>

On Thu, 22 Dec 2022 08:03:26 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> If a JNI Fatal error, or a JNI warning (from Xcheck:jni) is triggered in "top-level" native code (such as the launcher itself, or a freshly attached native thread) then there is no stack printed as there are no Java frames. This enhancement changes that so that we print the native stack, similarly to how error reporting does. We reuse VMError::print_native _stack to do this, but it could be argued this should be moved to a more general purpose utility class - suggestions welcome.
>> 
>> Testing:
>>   - manual fault injection (see bug report)
>>   - tiers 1-4
>> 
>> Thanks.
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added a regression test

I have just one request - disabling the core file would make this run better.

test/hotspot/jtreg/runtime/jni/nativeStack/TestNativeStack.java line 32:

> 30:  *          the native stack is present as expected.
> 31:  * @comment The native code only supports POSIX so no windows testing
> 32:  * @driver TestNativeStack

Can you make this test not dump a core file?

test/hotspot/jtreg/runtime/jni/nativeStack/TestNativeStack.java line 65:

> 63:                                          "TestNativeStack$Main",
> 64:                                          "error");
> 65:         oa.reportDiagnosticSummary();

So this just prints out the stack trace but doesn't do a shouldContain or some verification of the elements?  I presume because this would be unreliable?  This seems ok, but just checking.  I think it's still worth having a regression test because this looked hard to write and if the stack in the messages do disappear, it'll save someone from having to rewrite this.

-------------

PR: https://git.openjdk.org/jdk/pull/11703

From iwalulya at openjdk.org  Thu Dec 22 16:14:48 2022
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Thu, 22 Dec 2022 16:14:48 GMT
Subject: [jdk20] RFR: 8293824: gc/whitebox/TestConcMarkCycleWB.java failed
 "RuntimeException: assertTrue: expected true, was false"
In-Reply-To: <-LJBut4ETHYR8IDgKzvkumizSmDfB5uPUys0F282gfc=.152bea6b-1156-4280-a149-2cfe3a234a9c@github.com>
References: <-LJBut4ETHYR8IDgKzvkumizSmDfB5uPUys0F282gfc=.152bea6b-1156-4280-a149-2cfe3a234a9c@github.com>
Message-ID: <KDWDqPiHkgakhFDbNdeWz5erUt1A2CBCXvk2SfwpkMw=.70bed1bf-5922-404f-8159-ee31cf1ed2bf@github.com>

On Thu, 22 Dec 2022 02:04:30 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to WhiteBox and some tests involving G1 concurrent GCs.
> 
> Some tests currently use WhiteBox.g1StartConcMarkCycle() to trigger a
> concurrent GC.  Many of them follow it with a loop waiting for a concurrent
> cycle to not be in progress.  A few also preceed that call with a similar
> loop, since that call does nothing and returns false if a concurrent cycle is
> already in progress.  Those tests typically want to ensure there was a
> concurrent cycle that was started after some setup.
> 
> The failing test calls that function, asserting that it returned true, e.g. a
> new concurrent cycle was started.
> 
> There are various problems with this, due to races with concurrent cycles
> started automatically, and due to possibly aborted (by full GCs) concurrent cycles,
> making some of these tests unreliable in some configurations.
> 
> For example, the test failure associated with this bug intermittently arises
> when running with `-Xcomp`, triggering a concurrent cycle before the explicit
> request by the test, causing the explicit request to fail (because there is
> already one in progress), failing the assert.  Waiting for there not to be an
> in-progress cycle before the explicit request just narrows the race window.
> 
> We have a different mechanism in WhiteBox for controlling concurrent cycles,
> the concurrent GC breakpoint mechanism.  By adding a counter specifically for
> such cycles, we can use GC breakpoints to ensure only the concurrent cycles
> the test wants are occurring, and can verify they completed successfully.
> 
> So we change tests using WhiteBox.g1StartConcMarkCycle() to instead use GC
> breakpoints, along with the new WhiteBox.g1CompletedConcurrentMarkCycles() to
> avoid racing request problems and to detect aborted cycles.  Since it is no
> longer used, WhiteBox.g1StartConcMarkCycle() is removed.  The test that began
> this adventure (TestConcMarkCycleWB.java) is also removed, since it no longer
> serves any purpose, having been purely a test of that removed function.
> 
> Testing:
> mach5 tier1-7 - running the changed tests on a variety of platforms with a
> variety of configurations.

Lgtm!

-------------

Marked as reviewed by iwalulya (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/71

From sspitsyn at openjdk.org  Thu Dec 22 19:50:53 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 22 Dec 2022 19:50:53 GMT
Subject: RFR: 8295974: jni_FatalError and Xcheck:jni warnings should print
 the native stack when there are no Java frames [v2]
In-Reply-To: <1PhUGM_yK7Mub10f-HfRxTGPwml6DMV6ayQ2ARZaHAQ=.40a1c60b-cc85-4c16-b29f-e8a9b1d0910e@github.com>
References: <s_Ttmm80UcUu6OOWSZKD95u18WWZufwlMKPW-Gw9ZeE=.b77b8d96-8249-4754-8a0f-1bcf032f465c@github.com>
 <1PhUGM_yK7Mub10f-HfRxTGPwml6DMV6ayQ2ARZaHAQ=.40a1c60b-cc85-4c16-b29f-e8a9b1d0910e@github.com>
Message-ID: <-TFYqWIn-eh4W2iMmNOJmE8EFPtsUyUFksInJa1zpc4=.5c4c9a51-70bc-4c13-9c47-12332a088921@github.com>

On Thu, 22 Dec 2022 08:03:26 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> If a JNI Fatal error, or a JNI warning (from Xcheck:jni) is triggered in "top-level" native code (such as the launcher itself, or a freshly attached native thread) then there is no stack printed as there are no Java frames. This enhancement changes that so that we print the native stack, similarly to how error reporting does. We reuse VMError::print_native _stack to do this, but it could be argued this should be moved to a more general purpose utility class - suggestions welcome.
>> 
>> Testing:
>>   - manual fault injection (see bug report)
>>   - tiers 1-4
>> 
>> Thanks.
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added a regression test

test/hotspot/jtreg/runtime/jni/nativeStack/libnativeStack.c line 95:

> 93: JNIEXPORT void JNICALL
> 94: Java_TestNativeStack_triggerJNIStackTrace
> 95: (JNIEnv *env, jclass cls, jboolean warning) {

There is a static variable "warning" and an argument with the same name.
The argument is never used.
My guess is that intention was to store the argument value in the static variable.

-------------

PR: https://git.openjdk.org/jdk/pull/11703

From sspitsyn at openjdk.org  Thu Dec 22 19:56:49 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 22 Dec 2022 19:56:49 GMT
Subject: RFR: 8295974: jni_FatalError and Xcheck:jni warnings should print
 the native stack when there are no Java frames [v2]
In-Reply-To: <1PhUGM_yK7Mub10f-HfRxTGPwml6DMV6ayQ2ARZaHAQ=.40a1c60b-cc85-4c16-b29f-e8a9b1d0910e@github.com>
References: <s_Ttmm80UcUu6OOWSZKD95u18WWZufwlMKPW-Gw9ZeE=.b77b8d96-8249-4754-8a0f-1bcf032f465c@github.com>
 <1PhUGM_yK7Mub10f-HfRxTGPwml6DMV6ayQ2ARZaHAQ=.40a1c60b-cc85-4c16-b29f-e8a9b1d0910e@github.com>
Message-ID: <yturIU-ag8sR2p6lGBW-CrhTDXCQYyuh1SLkNYFy5fY=.b85ff917-99c5-4fa8-8f87-0611bcbe5dd6@github.com>

On Thu, 22 Dec 2022 08:03:26 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> If a JNI Fatal error, or a JNI warning (from Xcheck:jni) is triggered in "top-level" native code (such as the launcher itself, or a freshly attached native thread) then there is no stack printed as there are no Java frames. This enhancement changes that so that we print the native stack, similarly to how error reporting does. We reuse VMError::print_native _stack to do this, but it could be argued this should be moved to a more general purpose utility class - suggestions welcome.
>> 
>> Testing:
>>   - manual fault injection (see bug report)
>>   - tiers 1-4
>> 
>> Thanks.
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added a regression test

This looks good in general but I've inlined a couple of questions.

src/hotspot/share/runtime/javaThread.cpp line 1689:

> 1687:       return;
> 1688:     }
> 1689:     frame f = os::current_frame();

Is the function `JavaThread::print_jni_stack()` to print current JavaThread only or it was initially designed to print any JavaThread?

-------------

PR: https://git.openjdk.org/jdk/pull/11703

From kbarrett at openjdk.org  Thu Dec 22 20:06:50 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 22 Dec 2022 20:06:50 GMT
Subject: RFR: 8274400: HotSpot Style Guide should permit use of alignof
In-Reply-To: <3IdeZGaGcFB1-DbVugn0P9v8vRQMLURzHFRSpAm46NA=.09bf4dd8-b652-49c3-b9a5-ad3f58dfbcc3@github.com>
References: <3IdeZGaGcFB1-DbVugn0P9v8vRQMLURzHFRSpAm46NA=.09bf4dd8-b652-49c3-b9a5-ad3f58dfbcc3@github.com>
Message-ID: <S8zZSnZEdFRx7Bs6p4P2O6AHFA8k7Cn3zsGPYh16KEs=.1a8cc240-08da-44f7-a98a-8d1b9322a18d@github.com>

On Thu, 22 Dec 2022 04:39:47 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> The alignof operator was added by C++11. It returns the alignment for the given type. Various metaprogramming usages exist, in particular when using std::aligned_storage. Use of this operator should be permitted in HotSpot code.

Changes requested by kbarrett (Reviewer).

What is the use-case for permitting use of `alignof`?  Usually we don't add
such permits without some use-case in mind.

An obvious use-case was for computing the alignment of a type for use in
ATTRIBUTE_ALIGNED (which currently has compiler-specific implementations that
only support alignment values, though see JDK-8250269). But since we can now
use `alignas` directly (JDK-8297912), that's no longer important.

The use-case mentioned in the RFE (JDK-8274400), using it with
std::aligned_storage, is also not important (or is even counter-productive) -
see JDK-8298399.

I'm not opposed to permitting the use of `alignof`, but wondering why we
might need it.

doc/hotspot-style.md line 1060:

> 1058: 
> 1059: * `alignof`
> 1060: ([n2341](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2341.pdf))

Should say that `alignof` should be used instead of `std::alignment_of`.

-------------

PR: https://git.openjdk.org/jdk/pull/11761

From sspitsyn at openjdk.org  Thu Dec 22 20:18:59 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 22 Dec 2022 20:18:59 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v2]
In-Reply-To: <mBAIPYIyFTsHqBrLMOSuKna6IR-wbWgF1IVxnl2JGe0=.7c7fac27-8946-412e-9f27-d34ebec273c8@github.com>
References: <Q9aSWyhdNcS73UVmoosyrDRJZnqqAPk_G99quTgutxA=.76691773-e4c2-4190-bc6d-e54d11f1ae33@github.com>
 <mBAIPYIyFTsHqBrLMOSuKna6IR-wbWgF1IVxnl2JGe0=.7c7fac27-8946-412e-9f27-d34ebec273c8@github.com>
Message-ID: <2z4gV3aDtKkV50pWAs-mLvlmITcV3v7rlg0WJ17Lajg=.2f7ef31e-42bf-48f6-bceb-e70c9136992c@github.com>

On Wed, 23 Nov 2022 10:14:23 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This problem has two sides.
>> One is that the `VirtualThread::run() `cashes the field `notifyJvmtiEvents` value.
>> It caused the native method `notifyJvmtiUnmountBegin()` not called after the field `notifyJvmtiEvents`
>> value has been set to `true` when an agent library is loaded into running VM.
>> The fix is to get rid of this cashing.
>> Another is that enabling `notifyJvmtiEvents` notifications needs a synchronization.
>> Otherwise, a VTMS transition start can be missed which will cause some asserts to fire.
>> The fix is to use a JvmtiVTMSTransitionDisabler helper for sync.
>> 
>> Testing:
>> The originally failed tests are passed now:
>> 
>> runtime/vthread/RedefineClass.java
>> runtime/vthread/TestObjectAllocationSampleEvent.java 
>> 
>> In progress:
>> Run the tiers 1-6 to make sure there are no regression.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove caching if notifyJvmtiEvents in yieldContinuation

This is artificial comment to keep the PR alive.

-------------

PR: https://git.openjdk.org/jdk/pull/11304

From dholmes at openjdk.org  Thu Dec 22 21:03:29 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 22 Dec 2022 21:03:29 GMT
Subject: RFR: 8295974: jni_FatalError and Xcheck:jni warnings should print
 the native stack when there are no Java frames [v3]
In-Reply-To: <s_Ttmm80UcUu6OOWSZKD95u18WWZufwlMKPW-Gw9ZeE=.b77b8d96-8249-4754-8a0f-1bcf032f465c@github.com>
References: <s_Ttmm80UcUu6OOWSZKD95u18WWZufwlMKPW-Gw9ZeE=.b77b8d96-8249-4754-8a0f-1bcf032f465c@github.com>
Message-ID: <M4A8Yg9l8tl1AQGF9raz8DgNqurMPmzgtuVeBagGrzY=.f47407ea-f55f-4c65-ab27-b18378e9637d@github.com>

> If a JNI Fatal error, or a JNI warning (from Xcheck:jni) is triggered in "top-level" native code (such as the launcher itself, or a freshly attached native thread) then there is no stack printed as there are no Java frames. This enhancement changes that so that we print the native stack, similarly to how error reporting does. We reuse VMError::print_native _stack to do this, but it could be argued this should be moved to a more general purpose utility class - suggestions welcome.
> 
> Testing:
>   - manual fault injection (see bug report)
>   - tiers 1-4
> 
> Thanks.

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Update test files

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11703/files
  - new: https://git.openjdk.org/jdk/pull/11703/files/c85b30b8..4144c6f1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11703&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11703&range=01-02

  Stats: 20 lines in 3 files changed: 12 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/11703.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11703/head:pull/11703

PR: https://git.openjdk.org/jdk/pull/11703

From dholmes at openjdk.org  Thu Dec 22 21:03:29 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 22 Dec 2022 21:03:29 GMT
Subject: RFR: 8295974: jni_FatalError and Xcheck:jni warnings should print
 the native stack when there are no Java frames [v2]
In-Reply-To: <673GZG6_4T_H9JwsuQlcGoyFMoCoAec7OcYXWFQ_JX4=.725bcc66-a73a-42b0-90a5-34e5119c1415@github.com>
References: <s_Ttmm80UcUu6OOWSZKD95u18WWZufwlMKPW-Gw9ZeE=.b77b8d96-8249-4754-8a0f-1bcf032f465c@github.com>
 <1PhUGM_yK7Mub10f-HfRxTGPwml6DMV6ayQ2ARZaHAQ=.40a1c60b-cc85-4c16-b29f-e8a9b1d0910e@github.com>
 <673GZG6_4T_H9JwsuQlcGoyFMoCoAec7OcYXWFQ_JX4=.725bcc66-a73a-42b0-90a5-34e5119c1415@github.com>
Message-ID: <dzxJTJZ0TF0kII227pGvSJo156taS0IINJlWriKd0aE=.ab22e229-bc4c-492d-97cb-ca633c72df54@github.com>

On Thu, 22 Dec 2022 15:01:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added a regression test
>
> I have just one request - disabling the core file would make this run better.

Bah! Sorry @coleenp  and @sspitsyn  the committed version of the test was not up to date. Fixing.

-------------

PR: https://git.openjdk.org/jdk/pull/11703

From dholmes at openjdk.org  Thu Dec 22 21:05:52 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 22 Dec 2022 21:05:52 GMT
Subject: RFR: 8295974: jni_FatalError and Xcheck:jni warnings should print
 the native stack when there are no Java frames [v2]
In-Reply-To: <yturIU-ag8sR2p6lGBW-CrhTDXCQYyuh1SLkNYFy5fY=.b85ff917-99c5-4fa8-8f87-0611bcbe5dd6@github.com>
References: <s_Ttmm80UcUu6OOWSZKD95u18WWZufwlMKPW-Gw9ZeE=.b77b8d96-8249-4754-8a0f-1bcf032f465c@github.com>
 <1PhUGM_yK7Mub10f-HfRxTGPwml6DMV6ayQ2ARZaHAQ=.40a1c60b-cc85-4c16-b29f-e8a9b1d0910e@github.com>
 <yturIU-ag8sR2p6lGBW-CrhTDXCQYyuh1SLkNYFy5fY=.b85ff917-99c5-4fa8-8f87-0611bcbe5dd6@github.com>
Message-ID: <jE5FmEyhAeQ6rcaCXPl3PetBei9KR7ottGqTq0th6kA=.1f1c99dd-17bb-4dbf-a885-877f82bbb868@github.com>

On Thu, 22 Dec 2022 19:52:22 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added a regression test
>
> src/hotspot/share/runtime/javaThread.cpp line 1689:
> 
>> 1687:       return;
>> 1688:     }
>> 1689:     frame f = os::current_frame();
> 
> Is the function `JavaThread::print_jni_stack()` to print current JavaThread only or it was initially designed to print any JavaThread?

It is only used for the current thread. That is a mistake on my part making it look like it works for any thread - it potentially could but only if the target was made safe.

Good catch!

-------------

PR: https://git.openjdk.org/jdk/pull/11703

From coleenp at openjdk.org  Thu Dec 22 21:12:52 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 22 Dec 2022 21:12:52 GMT
Subject: RFR: 8295974: jni_FatalError and Xcheck:jni warnings should print
 the native stack when there are no Java frames [v3]
In-Reply-To: <M4A8Yg9l8tl1AQGF9raz8DgNqurMPmzgtuVeBagGrzY=.f47407ea-f55f-4c65-ab27-b18378e9637d@github.com>
References: <s_Ttmm80UcUu6OOWSZKD95u18WWZufwlMKPW-Gw9ZeE=.b77b8d96-8249-4754-8a0f-1bcf032f465c@github.com>
 <M4A8Yg9l8tl1AQGF9raz8DgNqurMPmzgtuVeBagGrzY=.f47407ea-f55f-4c65-ab27-b18378e9637d@github.com>
Message-ID: <ifRDJYYfi-pqt8jMOWJl0uWE_NpHrQ8elkIHcYrWSBI=.61ca21e5-60c9-4d6b-b651-2d678f442ce6@github.com>

On Thu, 22 Dec 2022 21:03:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> If a JNI Fatal error, or a JNI warning (from Xcheck:jni) is triggered in "top-level" native code (such as the launcher itself, or a freshly attached native thread) then there is no stack printed as there are no Java frames. This enhancement changes that so that we print the native stack, similarly to how error reporting does. We reuse VMError::print_native _stack to do this, but it could be argued this should be moved to a more general purpose utility class - suggestions welcome.
>> 
>> Testing:
>>   - manual fault injection (see bug report)
>>   - tiers 1-4
>> 
>> Thanks.
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test files

Looks great.

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11703

From coleenp at openjdk.org  Thu Dec 22 21:12:54 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 22 Dec 2022 21:12:54 GMT
Subject: RFR: 8295974: jni_FatalError and Xcheck:jni warnings should print
 the native stack when there are no Java frames [v2]
In-Reply-To: <673GZG6_4T_H9JwsuQlcGoyFMoCoAec7OcYXWFQ_JX4=.725bcc66-a73a-42b0-90a5-34e5119c1415@github.com>
References: <s_Ttmm80UcUu6OOWSZKD95u18WWZufwlMKPW-Gw9ZeE=.b77b8d96-8249-4754-8a0f-1bcf032f465c@github.com>
 <1PhUGM_yK7Mub10f-HfRxTGPwml6DMV6ayQ2ARZaHAQ=.40a1c60b-cc85-4c16-b29f-e8a9b1d0910e@github.com>
 <673GZG6_4T_H9JwsuQlcGoyFMoCoAec7OcYXWFQ_JX4=.725bcc66-a73a-42b0-90a5-34e5119c1415@github.com>
Message-ID: <tlFTxvaf6xm5AdPJZtHrXw8pwNxMIJDaxGYi5-YjkUU=.59fa70e0-c94d-4d74-829b-a74b2e50e4bd@github.com>

On Thu, 22 Dec 2022 15:00:43 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added a regression test
>
> test/hotspot/jtreg/runtime/jni/nativeStack/TestNativeStack.java line 65:
> 
>> 63:                                          "TestNativeStack$Main",
>> 64:                                          "error");
>> 65:         oa.reportDiagnosticSummary();
> 
> So this just prints out the stack trace but doesn't do a shouldContain or some verification of the elements?  I presume because this would be unreliable?  This seems ok, but just checking.  I think it's still worth having a regression test because this looked hard to write and if the stack in the messages do disappear, it'll save someone from having to rewrite this.

Oh, that's much better!

-------------

PR: https://git.openjdk.org/jdk/pull/11703

From coleenp at openjdk.org  Thu Dec 22 21:12:55 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 22 Dec 2022 21:12:55 GMT
Subject: RFR: 8295974: jni_FatalError and Xcheck:jni warnings should print
 the native stack when there are no Java frames [v2]
In-Reply-To: <tlFTxvaf6xm5AdPJZtHrXw8pwNxMIJDaxGYi5-YjkUU=.59fa70e0-c94d-4d74-829b-a74b2e50e4bd@github.com>
References: <s_Ttmm80UcUu6OOWSZKD95u18WWZufwlMKPW-Gw9ZeE=.b77b8d96-8249-4754-8a0f-1bcf032f465c@github.com>
 <1PhUGM_yK7Mub10f-HfRxTGPwml6DMV6ayQ2ARZaHAQ=.40a1c60b-cc85-4c16-b29f-e8a9b1d0910e@github.com>
 <673GZG6_4T_H9JwsuQlcGoyFMoCoAec7OcYXWFQ_JX4=.725bcc66-a73a-42b0-90a5-34e5119c1415@github.com>
 <tlFTxvaf6xm5AdPJZtHrXw8pwNxMIJDaxGYi5-YjkUU=.59fa70e0-c94d-4d74-829b-a74b2e50e4bd@github.com>
Message-ID: <r5y_DslGhYDJzoRqw6Zvq-9i3L-gnGfrLMo5adQIzLw=.792140d6-9fef-43bc-ba5e-4aa0457ce9fb@github.com>

On Thu, 22 Dec 2022 21:08:06 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> test/hotspot/jtreg/runtime/jni/nativeStack/TestNativeStack.java line 65:
>> 
>>> 63:                                          "TestNativeStack$Main",
>>> 64:                                          "error");
>>> 65:         oa.reportDiagnosticSummary();
>> 
>> So this just prints out the stack trace but doesn't do a shouldContain or some verification of the elements?  I presume because this would be unreliable?  This seems ok, but just checking.  I think it's still worth having a regression test because this looked hard to write and if the stack in the messages do disappear, it'll save someone from having to rewrite this.
>
> Oh, that's much better!

And I see it doesn't create core dump, which is great.

-------------

PR: https://git.openjdk.org/jdk/pull/11703

From sspitsyn at openjdk.org  Thu Dec 22 21:48:55 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 22 Dec 2022 21:48:55 GMT
Subject: RFR: 8295974: jni_FatalError and Xcheck:jni warnings should print
 the native stack when there are no Java frames [v3]
In-Reply-To: <M4A8Yg9l8tl1AQGF9raz8DgNqurMPmzgtuVeBagGrzY=.f47407ea-f55f-4c65-ab27-b18378e9637d@github.com>
References: <s_Ttmm80UcUu6OOWSZKD95u18WWZufwlMKPW-Gw9ZeE=.b77b8d96-8249-4754-8a0f-1bcf032f465c@github.com>
 <M4A8Yg9l8tl1AQGF9raz8DgNqurMPmzgtuVeBagGrzY=.f47407ea-f55f-4c65-ab27-b18378e9637d@github.com>
Message-ID: <r4QSyHINvdp-dCCXOaifrutVcHGr3YrcNSyF3pSKLVU=.12661f9c-8f3d-40a8-9a01-8f29f29d4a57@github.com>

On Thu, 22 Dec 2022 21:03:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> If a JNI Fatal error, or a JNI warning (from Xcheck:jni) is triggered in "top-level" native code (such as the launcher itself, or a freshly attached native thread) then there is no stack printed as there are no Java frames. This enhancement changes that so that we print the native stack, similarly to how error reporting does. We reuse VMError::print_native _stack to do this, but it could be argued this should be moved to a more general purpose utility class - suggestions welcome.
>> 
>> Testing:
>>   - manual fault injection (see bug report)
>>   - tiers 1-4
>> 
>> Thanks.
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test files

Thank you for update and answers.
Looks good.
Thanks,
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11703

From pchilanomate at openjdk.org  Thu Dec 22 22:08:52 2022
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 22 Dec 2022 22:08:52 GMT
Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling
 one virtual thread transitions [v4]
In-Reply-To: <goPSrd1KFzUyD3FjIgzJuBrBnfAzOy5gHakGaVWo-Vc=.a2812923-b41e-490f-bb7c-dd7e87976ef1@github.com>
References: <z8NCIbPeF0WzTEzXGyNxlnuOF_52vbV90p4B15xThFk=.b12cfe49-d27d-4e65-9027-796985005c14@github.com>
 <goPSrd1KFzUyD3FjIgzJuBrBnfAzOy5gHakGaVWo-Vc=.a2812923-b41e-490f-bb7c-dd7e87976ef1@github.com>
Message-ID: <7s1CyW4SOVZDr43ozNlTD0sgG_qVkS60BcQrmSbCVd4=.50ea4b9d-91c4-41b0-9bc6-3f2b1d3cfeff@github.com>

On Wed, 21 Dec 2022 21:33:28 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Now the `JvmtiVTMSTransitionDisabler` mechanism supports disabling VTMS transitions for all virtual threads only. It should also support disabling transitions for any specific virtual thread as well. This will improve scalability of the JVMTI functions operating on target virtual threads as the functions can be executed concurrently without blocking each other execution when target virtual threads are different.
>> New constructor `JvmtiVTMSTransitionDisabler(jthread vthread)` is added which has jthread parameter of the target virtual thread.
>> 
>> Testing:
>>   mach5 jobs are TBD (preliminary testing was completed):
>>    - all JVMTI, JDWP, JDI and JDB tests have to be run
>>    - Kitchensink
>>    - tier5
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use owned_by_self vs is_locked in JvmtiVTMSTransition_lock asserts

Hi Serguei,

Some comments on the changes below.

Thanks,
Patricio

src/hotspot/share/prims/jvmtiThreadState.cpp line 310:

> 308:     ml.wait(10); // wait while there is an active suspender or resumer
> 309:   }
> 310:   Atomic::inc(&_VTMS_transition_disable_for_one_count);

I don't understand the purpose of this counter. We only seem to write to it and the only place where it is checked is to do a notify, but I don't see a corresponding check-and-wait on that counter somewhere else, as we do with _VTMS_transition_disable_for_all_count.

src/hotspot/share/prims/jvmtiThreadState.cpp line 315:

> 313:     ml.wait(10); // wait while the virtual thread is in transition
> 314:   }
> 315:   java_lang_Thread::inc_VTMS_transition_disable_count(vth());

I think this sequence coupled with how start_VTMS_transition() works can have races. So the check vstate->is_in_VTMS_transition() could return false, but before we execute inc_VTMS_transition_disable_count() the target could have already called and returned from start_VTMS_transition(). 
Just to test this I added a nanosleep() call in between those two, and an assert before returning from JvmtiVTMSTransitionDisabler::JvmtiVTMSTransitionDisabler(jthread thread) that the target is not in the middle of a transition. Running the serviceability/jvmti/vthread/ tests gives me some crashes in that assert. Test patch: https://github.com/pchilano/jdk/commit/9bc22771bf324f69bc4f5a9786f1b21937aab3c7

If I compare with how the "disable all" case works, in there, the target transitioning sets a variable(_VTMS_transition_count) and then reads another one(_VTMS_transition_disable_for_all_count) set by the transition disabler. The transition disabler does the same but with the variables reversed, i.e. sets _VTMS_transition_disable_for_all_count and then reads _VTMS_transition_count. This correctly makes sure that if we read the value that allow us to return from the method then we have already written the flag that will stop the other thread. But in this "single" case I don't see the same pattern.

-------------

PR: https://git.openjdk.org/jdk/pull/11690

From kbarrett at openjdk.org  Thu Dec 22 23:13:37 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 22 Dec 2022 23:13:37 GMT
Subject: RFR: 8299254: Support dealing with standard assert macro
Message-ID: <6VQwFg9prwXbOwp_asHA4-Wru6PdKvaRN8MGiU24_sw=.1cafd8ea-e7e4-4a9d-a8ba-4f0cf87621d2@github.com>

Please review this change to provide and use mechanisms for dealing with uses
of the standard assert macro (from <assert.h> or <cassert>) in 3rd party code
that we use in HotSpot.

We provide a pair of utility header files, to be included before and after a
header that may use (and so include) the standard assert macro.  These new
headers provide a scope in which the HotSpot assert macro is not defined, and
then reinstated after.

We also define NDEBUG in release builds of HotSpot, so any uses of the
standard assert macro in such 3rd party code will be disabled.

Finally, we use the new utility headers in some gtests and in our gtest
wrapper header (unittest.hpp), eliminating problems the gtest implementation
and with some versions of some standard libraries that the tests use.

Testing:
mach5 tier1

-------------

Commit messages:
 - define NDEBUG in HotSpot release builds
 - use vmassert_uninstall/reinstall in gtests
 - utility for manipulating HotSpot assert macro

Changes: https://git.openjdk.org/jdk/pull/11770/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11770&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299254
  Stats: 122 lines in 8 files changed: 102 ins; 16 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/11770.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11770/head:pull/11770

PR: https://git.openjdk.org/jdk/pull/11770

From sspitsyn at openjdk.org  Thu Dec 22 23:13:54 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 22 Dec 2022 23:13:54 GMT
Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling
 one virtual thread transitions [v4]
In-Reply-To: <7s1CyW4SOVZDr43ozNlTD0sgG_qVkS60BcQrmSbCVd4=.50ea4b9d-91c4-41b0-9bc6-3f2b1d3cfeff@github.com>
References: <z8NCIbPeF0WzTEzXGyNxlnuOF_52vbV90p4B15xThFk=.b12cfe49-d27d-4e65-9027-796985005c14@github.com>
 <goPSrd1KFzUyD3FjIgzJuBrBnfAzOy5gHakGaVWo-Vc=.a2812923-b41e-490f-bb7c-dd7e87976ef1@github.com>
 <7s1CyW4SOVZDr43ozNlTD0sgG_qVkS60BcQrmSbCVd4=.50ea4b9d-91c4-41b0-9bc6-3f2b1d3cfeff@github.com>
Message-ID: <b5bNwMJkE-CUBWPz7swfk6WEhzCNTJwR1YKAaO1dySA=.c13298d6-07f8-4364-afba-1c0e928ec58d@github.com>

On Thu, 22 Dec 2022 22:06:19 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Hi Serguei,
> 
> Some comments on the changes below.
> 
> Thanks, Patricio

Thank you for reviewing it, Patricio!

> src/hotspot/share/prims/jvmtiThreadState.cpp line 310:
> 
>> 308:     ml.wait(10); // wait while there is an active suspender or resumer
>> 309:   }
>> 310:   Atomic::inc(&_VTMS_transition_disable_for_one_count);
> 
> I don't understand the purpose of this counter. We only seem to write to it and the only place where it is checked is to do a notify, but I don't see a corresponding check-and-wait on that counter somewhere else, as we do with _VTMS_transition_disable_for_all_count.

Good catch.

> Hi Serguei,
> 
> Some comments on the changes below.
> 
> Thanks, Patricio

Thank you for reviewing it, Patricio!

-------------

PR: https://git.openjdk.org/jdk/pull/11690

From sspitsyn at openjdk.org  Fri Dec 23 00:28:52 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 23 Dec 2022 00:28:52 GMT
Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling
 one virtual thread transitions [v4]
In-Reply-To: <7s1CyW4SOVZDr43ozNlTD0sgG_qVkS60BcQrmSbCVd4=.50ea4b9d-91c4-41b0-9bc6-3f2b1d3cfeff@github.com>
References: <z8NCIbPeF0WzTEzXGyNxlnuOF_52vbV90p4B15xThFk=.b12cfe49-d27d-4e65-9027-796985005c14@github.com>
 <goPSrd1KFzUyD3FjIgzJuBrBnfAzOy5gHakGaVWo-Vc=.a2812923-b41e-490f-bb7c-dd7e87976ef1@github.com>
 <7s1CyW4SOVZDr43ozNlTD0sgG_qVkS60BcQrmSbCVd4=.50ea4b9d-91c4-41b0-9bc6-3f2b1d3cfeff@github.com>
Message-ID: <RHwxbYE3qlRhGAIMz3T-ftQcariBnFZIXLH6RVujc4w=.3cc96094-c16a-492e-857c-4c2f71c6f98b@github.com>

On Thu, 22 Dec 2022 21:55:02 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use owned_by_self vs is_locked in JvmtiVTMSTransition_lock asserts
>
> src/hotspot/share/prims/jvmtiThreadState.cpp line 315:
> 
>> 313:     ml.wait(10); // wait while the virtual thread is in transition
>> 314:   }
>> 315:   java_lang_Thread::inc_VTMS_transition_disable_count(vth());
> 
> I think this sequence coupled with how start_VTMS_transition() works can have races. So the check vstate->is_in_VTMS_transition() could return false, but before we execute inc_VTMS_transition_disable_count() the target could have already called and returned from start_VTMS_transition(). 
> Just to test this I added a nanosleep() call in between those two, and an assert before returning from JvmtiVTMSTransitionDisabler::JvmtiVTMSTransitionDisabler(jthread thread) that the target is not in the middle of a transition. Running the serviceability/jvmti/vthread/ tests gives me some crashes in that assert. Test patch: https://github.com/pchilano/jdk/commit/9bc22771bf324f69bc4f5a9786f1b21937aab3c7
> 
> If I compare with how the "disable all" case works, in there, the target transitioning sets a variable(_VTMS_transition_count) and then reads another one(_VTMS_transition_disable_for_all_count) set by the transition disabler. The transition disabler does the same but with the variables reversed, i.e. sets _VTMS_transition_disable_for_all_count and then reads _VTMS_transition_count. This correctly makes sure that if we read the value that allow us to return from the method then we have already written the flag that will stop the other thread. But in this "single" case I don't see the same pattern.

I see the problem. Good catch, thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/11690

From dholmes at openjdk.org  Fri Dec 23 01:18:34 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 23 Dec 2022 01:18:34 GMT
Subject: RFR: 8295974: jni_FatalError and Xcheck:jni warnings should print
 the native stack when there are no Java frames [v4]
In-Reply-To: <s_Ttmm80UcUu6OOWSZKD95u18WWZufwlMKPW-Gw9ZeE=.b77b8d96-8249-4754-8a0f-1bcf032f465c@github.com>
References: <s_Ttmm80UcUu6OOWSZKD95u18WWZufwlMKPW-Gw9ZeE=.b77b8d96-8249-4754-8a0f-1bcf032f465c@github.com>
Message-ID: <74PlFZv9YmJ8Of15S94tirJvrqyeI7uv4FNoqQL17Zw=.238d37c1-52cb-4f04-b262-db650b4aa0c4@github.com>

> If a JNI Fatal error, or a JNI warning (from Xcheck:jni) is triggered in "top-level" native code (such as the launcher itself, or a freshly attached native thread) then there is no stack printed as there are no Java frames. This enhancement changes that so that we print the native stack, similarly to how error reporting does. We reuse VMError::print_native _stack to do this, but it could be argued this should be moved to a more general purpose utility class - suggestions welcome.
> 
> Testing:
>   - manual fault injection (see bug report)
>   - tiers 1-4
> 
> Thanks.

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Move assertion and make clear print_jni_stack is only for current thread.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11703/files
  - new: https://git.openjdk.org/jdk/pull/11703/files/4144c6f1..6c3319af

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11703&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11703&range=02-03

  Stats: 4 lines in 2 files changed: 1 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11703.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11703/head:pull/11703

PR: https://git.openjdk.org/jdk/pull/11703

From dholmes at openjdk.org  Fri Dec 23 01:23:49 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 23 Dec 2022 01:23:49 GMT
Subject: RFR: 8295974: jni_FatalError and Xcheck:jni warnings should print
 the native stack when there are no Java frames [v3]
In-Reply-To: <ifRDJYYfi-pqt8jMOWJl0uWE_NpHrQ8elkIHcYrWSBI=.61ca21e5-60c9-4d6b-b651-2d678f442ce6@github.com>
References: <s_Ttmm80UcUu6OOWSZKD95u18WWZufwlMKPW-Gw9ZeE=.b77b8d96-8249-4754-8a0f-1bcf032f465c@github.com>
 <M4A8Yg9l8tl1AQGF9raz8DgNqurMPmzgtuVeBagGrzY=.f47407ea-f55f-4c65-ab27-b18378e9637d@github.com>
 <ifRDJYYfi-pqt8jMOWJl0uWE_NpHrQ8elkIHcYrWSBI=.61ca21e5-60c9-4d6b-b651-2d678f442ce6@github.com>
Message-ID: <qXuLs5-dXzle6h4LEPXH8n1l8eCsab04sf6uy3p6Osg=.049b0d3b-13bd-4d47-bb43-d02d68f0e383@github.com>

On Thu, 22 Dec 2022 21:09:59 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update test files
>
> Looks great.

Thanks for re-reviewing the test @coleenp  and @sspitsyn ! Unfortunately I forgot to push the minor tweak to make it clear `print_jni_stack` is only for the current thread. Too much of a rush before the break. :( I'll resubmit testing and integrate this next year.

-------------

PR: https://git.openjdk.org/jdk/pull/11703

From dholmes at openjdk.org  Fri Dec 23 03:55:52 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 23 Dec 2022 03:55:52 GMT
Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling
 one virtual thread transitions [v4]
In-Reply-To: <goPSrd1KFzUyD3FjIgzJuBrBnfAzOy5gHakGaVWo-Vc=.a2812923-b41e-490f-bb7c-dd7e87976ef1@github.com>
References: <z8NCIbPeF0WzTEzXGyNxlnuOF_52vbV90p4B15xThFk=.b12cfe49-d27d-4e65-9027-796985005c14@github.com>
 <goPSrd1KFzUyD3FjIgzJuBrBnfAzOy5gHakGaVWo-Vc=.a2812923-b41e-490f-bb7c-dd7e87976ef1@github.com>
Message-ID: <1cusw61Gi5mniDMgMLWH0kQS3b02o5D--dUTcS9xTs8=.f633221e-d334-403f-93de-ebbfb81a8e13@github.com>

On Wed, 21 Dec 2022 21:33:28 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Now the `JvmtiVTMSTransitionDisabler` mechanism supports disabling VTMS transitions for all virtual threads only. It should also support disabling transitions for any specific virtual thread as well. This will improve scalability of the JVMTI functions operating on target virtual threads as the functions can be executed concurrently without blocking each other execution when target virtual threads are different.
>> New constructor `JvmtiVTMSTransitionDisabler(jthread vthread)` is added which has jthread parameter of the target virtual thread.
>> 
>> Testing:
>>   mach5 jobs are TBD (preliminary testing was completed):
>>    - all JVMTI, JDWP, JDI and JDB tests have to be run
>>    - Kitchensink
>>    - tier5
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use owned_by_self vs is_locked in JvmtiVTMSTransition_lock asserts

Changes requested by dholmes (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11690

From dholmes at openjdk.org  Fri Dec 23 03:55:54 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 23 Dec 2022 03:55:54 GMT
Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling
 one virtual thread transitions [v4]
In-Reply-To: <RHwxbYE3qlRhGAIMz3T-ftQcariBnFZIXLH6RVujc4w=.3cc96094-c16a-492e-857c-4c2f71c6f98b@github.com>
References: <z8NCIbPeF0WzTEzXGyNxlnuOF_52vbV90p4B15xThFk=.b12cfe49-d27d-4e65-9027-796985005c14@github.com>
 <goPSrd1KFzUyD3FjIgzJuBrBnfAzOy5gHakGaVWo-Vc=.a2812923-b41e-490f-bb7c-dd7e87976ef1@github.com>
 <7s1CyW4SOVZDr43ozNlTD0sgG_qVkS60BcQrmSbCVd4=.50ea4b9d-91c4-41b0-9bc6-3f2b1d3cfeff@github.com>
 <RHwxbYE3qlRhGAIMz3T-ftQcariBnFZIXLH6RVujc4w=.3cc96094-c16a-492e-857c-4c2f71c6f98b@github.com>
Message-ID: <6UL6R9_tf9tsHC-BfSryrSklaGzAWidbEoj3VvJ3Uaw=.371c4ade-e653-4623-aa1c-82b81df7901d@github.com>

On Fri, 23 Dec 2022 00:26:02 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiThreadState.cpp line 315:
>> 
>>> 313:     ml.wait(10); // wait while the virtual thread is in transition
>>> 314:   }
>>> 315:   java_lang_Thread::inc_VTMS_transition_disable_count(vth());
>> 
>> I think this sequence coupled with how start_VTMS_transition() works can have races. So the check vstate->is_in_VTMS_transition() could return false, but before we execute inc_VTMS_transition_disable_count() the target could have already called and returned from start_VTMS_transition(). 
>> Just to test this I added a nanosleep() call in between those two, and an assert before returning from JvmtiVTMSTransitionDisabler::JvmtiVTMSTransitionDisabler(jthread thread) that the target is not in the middle of a transition. Running the serviceability/jvmti/vthread/ tests gives me some crashes in that assert. Test patch: https://github.com/pchilano/jdk/commit/9bc22771bf324f69bc4f5a9786f1b21937aab3c7
>> 
>> If I compare with how the "disable all" case works, in there, the target transitioning sets a variable(_VTMS_transition_count) and then reads another one(_VTMS_transition_disable_for_all_count) set by the transition disabler. The transition disabler does the same but with the variables reversed, i.e. sets _VTMS_transition_disable_for_all_count and then reads _VTMS_transition_count. This correctly makes sure that if we read the value that allow us to return from the method then we have already written the flag that will stop the other thread. But in this "single" case I don't see the same pattern.
>
> I see the problem. Good catch, thanks!

Yep my bad in earlier review. The one case needs the same synchronization/coordination as the all case.

-------------

PR: https://git.openjdk.org/jdk/pull/11690

From xlinzheng at openjdk.org  Fri Dec 23 03:56:53 2022
From: xlinzheng at openjdk.org (Xiaolin Zheng)
Date: Fri, 23 Dec 2022 03:56:53 GMT
Subject: RFR: 8299168: RISC-V: Fix MachNode size mismatch for
 MacroAssembler::_verify_oops* [v2]
In-Reply-To: <VdKZ6hYVYhsvL2jmgpSHX0oiXIen-8iGnrT7PKEfXks=.55cd4db2-30df-4139-a1c9-7610420cee0f@github.com>
References: <hQxJLqN5qMtfsAgoHRN3iLTCpX1pSs2eJZigFGbM-DU=.3e187efe-9fe8-419b-ba28-32b88d7488af@github.com>
 <MOAIRaf4pSV2DfT6tksaohzqAs_UoRjcovxKb_VUHHA=.2925a312-d06f-4f6c-8f64-10d0202f4ac4@github.com>
 <VdKZ6hYVYhsvL2jmgpSHX0oiXIen-8iGnrT7PKEfXks=.55cd4db2-30df-4139-a1c9-7610420cee0f@github.com>
Message-ID: <bsAahSMWyY2BYxvhTVzCDRaAn4NR_GEXmim1h0s9uQ4=.4b8bb386-c851-4aa0-b7d5-c94ed28ecd3f@github.com>

On Wed, 21 Dec 2022 07:48:18 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix as to comments
>
> Updated changes looks good. Thanks.

Thanks for reviewing! @RealFYang

-------------

PR: https://git.openjdk.org/jdk/pull/11750

From xlinzheng at openjdk.org  Fri Dec 23 09:25:54 2022
From: xlinzheng at openjdk.org (Xiaolin Zheng)
Date: Fri, 23 Dec 2022 09:25:54 GMT
Subject: Integrated: 8299168: RISC-V: Fix MachNode size mismatch for
 MacroAssembler::_verify_oops*
In-Reply-To: <hQxJLqN5qMtfsAgoHRN3iLTCpX1pSs2eJZigFGbM-DU=.3e187efe-9fe8-419b-ba28-32b88d7488af@github.com>
References: <hQxJLqN5qMtfsAgoHRN3iLTCpX1pSs2eJZigFGbM-DU=.3e187efe-9fe8-419b-ba28-32b88d7488af@github.com>
Message-ID: <Jjhhdaciah5iBi9GWLUiSABsljZ2fJEZ4e2zRdDCgSs=.f0e0da80-7fe8-4bba-8f2e-5fb57d5e8019@github.com>

On Wed, 21 Dec 2022 04:47:51 GMT, Xiaolin Zheng <xlinzheng at openjdk.org> wrote:

> Nearly the same as [JDK-8285437](https://bugs.openjdk.org/browse/JDK-8285437). MachNode size should match in scratch emission and real emission phases. The address of the local char buffer is a random value, but when RVC is enabled, the `movptr`, containing `lui+addi+slli+addi+slli`, with another dangling `addi` at last to load the immediate address of the special local char buffer may get compressed depending on the char buffer's different addresses. So the size may at last mismatch. Due to this part containing implicit fixed-length semantics, it shall be a reasonable fix to add an `IncompressibleRegion` for these two special positions to disable automatic RVC transformations.
> 
> `test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestDFlags.java` in hotspot tier4 can reflect this issue. It contains a `vm.flagless` so it didn't run in my local environment until recently.
> 
> Tested Hotspot tier1~4 with fastdebug build on physical hardware along with some other patches.
> 
> Thanks,
> Xiaolin

This pull request has now been integrated.

Changeset: 2f4098e1
Author:    Xiaolin Zheng <xlinzheng at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2f4098e1dc9c97e706d70008e473f9c4496cbc8a
Stats:     14 lines in 1 file changed: 6 ins; 0 del; 8 mod

8299168: RISC-V: Fix MachNode size mismatch for MacroAssembler::_verify_oops*

Reviewed-by: fyang

-------------

PR: https://git.openjdk.org/jdk/pull/11750

From eosterlund at openjdk.org  Fri Dec 23 09:40:52 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 23 Dec 2022 09:40:52 GMT
Subject: RFR: 8299089: Instrument global jni handles with tag to make them
 distinguishable
In-Reply-To: <dHb4TMxgR1O4h2v2LXkpx1rSwk6SLqr-4do-e8KbLfY=.b4c32322-7cb6-42c4-bc21-e338cfcade31@github.com>
References: <dHb4TMxgR1O4h2v2LXkpx1rSwk6SLqr-4do-e8KbLfY=.b4c32322-7cb6-42c4-bc21-e338cfcade31@github.com>
Message-ID: <Zp-KrhMNSv9yh0Y9ME2lb8CDlDCx3SklEU5BnIckhKo=.80765227-ca27-4f32-8cf0-7a3462e697ed@github.com>

On Tue, 20 Dec 2022 11:44:33 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Weak global jni handles are tagged so the GC can distinguish them when resolving the object. Today there is no cheap way of distinguishing global jni handles from local jni handles. For generational ZGC the OopStorage handles and the thread local handles semantical difference requires the handles to be distinguishable. 
> 
> This enhancements instruments the jni handles with a global tag similarly to the jweak tag. 
> 
> Note: 
>  * the s390 implementation has minimal changes and requires improvement.
>  * There is room for enchantment here to create the same abstraction that ppc uses for all platforms, i.e. move the resolve_jobject from the MacroAssembler to the BarrierSetAssembler which allows for more optimised code for GCs that can treat local and global handles the same. 
> 
> Testing: GHA. Oracle supported platforms tier1-3. Will run higher tiers. Has also been tested on the generational branch of ZGC for over three months. Requires testing on non Oracle platforms.

Looks good.

-------------

Marked as reviewed by eosterlund (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11740

From eosterlund at openjdk.org  Fri Dec 23 09:47:49 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 23 Dec 2022 09:47:49 GMT
Subject: RFR: 8299125: UnifiedOopRef in JFR leakprofiler should treat
 thread local oops correctly
In-Reply-To: <rWycrBShM6izhFHt_--oBN7kgdhnYVDVUjUz_5hxd00=.2b6bf0af-18ec-43c2-9856-db6ce8ba2a43@github.com>
References: <rWycrBShM6izhFHt_--oBN7kgdhnYVDVUjUz_5hxd00=.2b6bf0af-18ec-43c2-9856-db6ce8ba2a43@github.com>
Message-ID: <JGzpMcvhWxQKzj6f-VzBKBnDxwPc-j_d0dq_EPXxFKU=.f83c27dd-b31b-4431-8b8d-f75c229a5965@github.com>

On Tue, 20 Dec 2022 16:30:47 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> In a similar vain to [JDK-8299089](https://bugs.openjdk.org/browse/JDK-8299089) there are different semantics for OopStorage and thread local oops. UnifiedOopRef in the jfr leakprofiler must be able to distinguish these and treat them appropriately.
> 
> Testing: Running test at the moment. Has been running on the generational branch of ZGC for over three months. Not many tests exercise the leakprofiler. x86_32 has mostly been tested with GHA. 
> 
> Note: The accessBackend changes are only there to facilitate comparing OopLoadProxy objects directly with nullptr instead of creating and comparing with an `oop()` / `oop(NULL)`. Can be backed out of this PR and put in a different RFE instead.

Hmm. So we have IN_NATIVE accesses tagged as encode_in_native, and essentially AS_RAW accesses encoded as encode_non_barriered. I usually don't pick on naming, but the term "non-barriered" seems to stray away from already established terminology. I would prefer if the mentions of "non_barriered" changed to "as_raw" for consistency.

-------------

Changes requested by eosterlund (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11741

From erikj at openjdk.org  Fri Dec 23 13:46:49 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 23 Dec 2022 13:46:49 GMT
Subject: RFR: 8299254: Support dealing with standard assert macro
In-Reply-To: <6VQwFg9prwXbOwp_asHA4-Wru6PdKvaRN8MGiU24_sw=.1cafd8ea-e7e4-4a9d-a8ba-4f0cf87621d2@github.com>
References: <6VQwFg9prwXbOwp_asHA4-Wru6PdKvaRN8MGiU24_sw=.1cafd8ea-e7e4-4a9d-a8ba-4f0cf87621d2@github.com>
Message-ID: <pEgRqVtkm-S_ydKjXoYoaBXwiFBPUuXTTzh_1dFWh0Y=.ce9b92f2-19d2-4c6e-8bb5-cf5b24f821f6@github.com>

On Thu, 22 Dec 2022 23:05:03 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to provide and use mechanisms for dealing with uses
> of the standard assert macro (from <assert.h> or <cassert>) in 3rd party code
> that we use in HotSpot.
> 
> We provide a pair of utility header files, to be included before and after a
> header that may use (and so include) the standard assert macro.  These new
> headers provide a scope in which the HotSpot assert macro is not defined, and
> then reinstated after.
> 
> We also define NDEBUG in release builds of HotSpot, so any uses of the
> standard assert macro in such 3rd party code will be disabled.
> 
> Finally, we use the new utility headers in some gtests and in our gtest
> wrapper header (unittest.hpp), eliminating problems the gtest implementation
> and with some versions of some standard libraries that the tests use.
> 
> Testing:
> mach5 tier1

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11770

From eosterlund at openjdk.org  Fri Dec 23 14:02:30 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 23 Dec 2022 14:02:30 GMT
Subject: RFR: 8299032: Interface IN_NATIVE oop stores for C2
Message-ID: <61HZ-hCw_ZoDZCtsDLsz-tfPE6S7Ox_1nXApLQnZ1SU=.60c813cf-a5d8-4a3c-a2a1-86d7af05d042@github.com>

Loom added the first IN_NATIVE oop store to C2 code, when switching the current virtual thread of a platform thread. Instead of interfacing this properly, a raw store was used. But a future GC algorithm, such as generational ZGC, might not work well with raw stores. We should add support to the access API for this. Looks like Shenandoah was already missing something here as they do concurrent root processing requiring SATB barriers on IN_NATIVE oop stores. It is not in the scope of this PR to fix the Shenandoah bug - someone working on Shenandoah should do this. This PR merely adds an interface such that GCs that need to do something different here, can do that. Serial, Parallel and G1 don't need to do anything for IN_NATIVE stores as they do STW root processing. ZGC doesn't (yet) have store barriers at all, and hence doesn't need to do anything special either.

-------------

Commit messages:
 - 8299032: Interface IN_NATIVE oop stores for C2

Changes: https://git.openjdk.org/jdk/pull/11777/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11777&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299032
  Stats: 8 lines in 2 files changed: 0 ins; 7 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11777.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11777/head:pull/11777

PR: https://git.openjdk.org/jdk/pull/11777

From eosterlund at openjdk.org  Fri Dec 23 14:14:59 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 23 Dec 2022 14:14:59 GMT
Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC
Message-ID: <1rK2mzryGeyI-Yak0rUIqYZBuK5zrxCYwPe9zJbjHpY=.5471f1af-f8b8-4219-ae93-8b5a5fecaad9@github.com>

The JfrVFrameStream is used while generating stack traces for events. One of the events are the ZPage allocation event. This event is sometimes sent when ZGC is relocating. The current implementation of JfrVFrameStream uses WalkContinuation::include, which causes JFR to walk the continuation and perform GC barriers. This is problematic, since ZGC has a requirement that we never perform load barriers while running the relocation code. If we do, we might end up performing other reloctions from the the relocation code, and in some cases that causes dead locks. 

I propose that JFR doesn't walk the stack during stack watermark processing. This PR implements that change. This PR replaces https://github.com/openjdk/jdk/pull/11586

-------------

Commit messages:
 - 8298377: JfrVframeStream causes deadlocks in ZGC

Changes: https://git.openjdk.org/jdk/pull/11778/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11778&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298377
  Stats: 189 lines in 10 files changed: 160 ins; 12 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/11778.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11778/head:pull/11778

PR: https://git.openjdk.org/jdk/pull/11778

From eosterlund at openjdk.org  Fri Dec 23 14:53:38 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 23 Dec 2022 14:53:38 GMT
Subject: RFR: 8298377: JfrVframeStream causes deadlocks in ZGC [v2]
In-Reply-To: <1rK2mzryGeyI-Yak0rUIqYZBuK5zrxCYwPe9zJbjHpY=.5471f1af-f8b8-4219-ae93-8b5a5fecaad9@github.com>
References: <1rK2mzryGeyI-Yak0rUIqYZBuK5zrxCYwPe9zJbjHpY=.5471f1af-f8b8-4219-ae93-8b5a5fecaad9@github.com>
Message-ID: <ly1-vfTwZXJCmIX3qIKtufRelUnz5bWH7ie8_8MEbTM=.00913bbf-bc09-463b-a8cd-9f3b02a3766f@github.com>

> The JfrVFrameStream is used while generating stack traces for events. One of the events are the ZPage allocation event. This event is sometimes sent when ZGC is relocating. The current implementation of JfrVFrameStream uses WalkContinuation::include, which causes JFR to walk the continuation and perform GC barriers. This is problematic, since ZGC has a requirement that we never perform load barriers while running the relocation code. If we do, we might end up performing other reloctions from the the relocation code, and in some cases that causes dead locks. 
> 
> I propose that JFR doesn't walk the stack during stack watermark processing. This PR implements that change. This PR replaces https://github.com/openjdk/jdk/pull/11586

Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:

  Fix release build

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11778/files
  - new: https://git.openjdk.org/jdk/pull/11778/files/17f2ea06..5bd03153

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11778&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11778&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11778.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11778/head:pull/11778

PR: https://git.openjdk.org/jdk/pull/11778

From eosterlund at openjdk.org  Fri Dec 23 14:58:37 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 23 Dec 2022 14:58:37 GMT
Subject: RFR: 8299312: Clean up BarrierSetNMethod
Message-ID: <i0V5ZWw127zyTS-E0fdZo3QxhCaHvtyEKO82ndoep9c=.bda9f431-0779-4c50-92e5-033d2fe22d9c@github.com>

The terminology in BarrierSetNMethod is not crisp. In platform code we talk about a per-nmethod "guard value", but on shared level we call the same value arm value or disarm value in different contexts. But it really depends on the value whether the nmethod is disarmed or armed. We should embrace the "guard value" terminology and lift it in to the shared code level.
We also have more functionality than we need on platform level. The platform level only needs to know how to deoptimize, and how to set/get the guard value of an nmethod. The more specific functionality should be moved to the shared code and be expressed in terms of said setter/getter.

-------------

Commit messages:
 - Fix Shenandoah build
 - 8299312: Clean up BarrierSetNMethod

Changes: https://git.openjdk.org/jdk/pull/11774/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11774&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299312
  Stats: 159 lines in 26 files changed: 10 ins; 73 del; 76 mod
  Patch: https://git.openjdk.org/jdk/pull/11774.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11774/head:pull/11774

PR: https://git.openjdk.org/jdk/pull/11774

From mdoerr at openjdk.org  Fri Dec 23 15:23:52 2022
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 23 Dec 2022 15:23:52 GMT
Subject: RFR: 8291302: ARM32: nmethod entry barriers support [v4]
In-Reply-To: <hjEeA3EFQ8HmiK65iRm7WKXX4tmVKC187eEHE_FPOSg=.3a2f657d-f207-4e60-9023-65808595ecc6@github.com>
References: <BJaszr0_haU4UZOyQQEA9P0SOlgtfTtGFBj9VSRD5SM=.ffd6af56-a51e-4627-90cb-0eb0e1bbd5e8@github.com>
 <hjEeA3EFQ8HmiK65iRm7WKXX4tmVKC187eEHE_FPOSg=.3a2f657d-f207-4e60-9023-65808595ecc6@github.com>
Message-ID: <dU-ujEhIgFNlhXPGsGfFcdptzyRNpt_z9C6PfEK4kPk=.42e30805-be38-4092-9f8c-c71dd61c9630@github.com>

On Thu, 8 Dec 2022 15:02:18 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

>> This PR implements nmethod entry barriers for ARM32. It has already been implemented for other ports and is related with JDK-8290025 "Remove the Sweeper".
>
> Aleksei Voitylov 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 four additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8291302-3
>  - remove membar
>  - save float registers
>  - 8291302: ARM32: nmethod entry barriers support

LGTM, but I'm not an arm 32 expert.

-------------

Marked as reviewed by mdoerr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11442

From rrich at openjdk.org  Fri Dec 23 15:48:51 2022
From: rrich at openjdk.org (Richard Reingruber)
Date: Fri, 23 Dec 2022 15:48:51 GMT
Subject: RFR: 8291302: ARM32: nmethod entry barriers support [v4]
In-Reply-To: <hjEeA3EFQ8HmiK65iRm7WKXX4tmVKC187eEHE_FPOSg=.3a2f657d-f207-4e60-9023-65808595ecc6@github.com>
References: <BJaszr0_haU4UZOyQQEA9P0SOlgtfTtGFBj9VSRD5SM=.ffd6af56-a51e-4627-90cb-0eb0e1bbd5e8@github.com>
 <hjEeA3EFQ8HmiK65iRm7WKXX4tmVKC187eEHE_FPOSg=.3a2f657d-f207-4e60-9023-65808595ecc6@github.com>
Message-ID: <tWluq9mn88KI9TqhOIjtj1i4eZWfNXdh0OoPtQzW5S4=.1495d312-3505-42bc-ba02-235e8073b065@github.com>

On Thu, 8 Dec 2022 15:02:18 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

>> This PR implements nmethod entry barriers for ARM32. It has already been implemented for other ports and is related with JDK-8290025 "Remove the Sweeper".
>
> Aleksei Voitylov 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 four additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8291302-3
>  - remove membar
>  - save float registers
>  - 8291302: ARM32: nmethod entry barriers support

The changes look good to me. I'm not familiar with arm32 details, though.
You might want to open an RFE to port JDK-8290700 to arm32.
Thanks, Richard.

-------------

Marked as reviewed by rrich (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11442

From jwaters at openjdk.org  Fri Dec 23 18:05:21 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 23 Dec 2022 18:05:21 GMT
Subject: RFR: 8250269: Replace ATTRIBUTE_ALIGNED with alignas [v7]
In-Reply-To: <9QKV9cYFTo_1D8R-mI80lnewNkA0ceJNKFPbrvICxl4=.d6736b76-8324-4084-bede-6e144b4f6c04@github.com>
References: <9QKV9cYFTo_1D8R-mI80lnewNkA0ceJNKFPbrvICxl4=.d6736b76-8324-4084-bede-6e144b4f6c04@github.com>
Message-ID: <rPrji91qMRRNZ7K00_tTGQ84u6CoB4hmT6yce9uFdHM=.e86d28b8-9a7c-4bb9-8fce-15efd304ded0@github.com>

> C++11 added the alignas attribute, for the purpose of specifying alignment on types, much like compiler specific syntax such as gcc's __attribute__((aligned(x))) or Visual C++'s __declspec(align(x)).
> 
> We can phase out the use of the macro in favor of the standard attribute. In the meantime, we can replace the compiler specific definitions of ATTRIBUTE_ALIGNED with a portable definition. We might deprecate the use of the macro but changing its implementation quickly and cleanly applies the feature where the macro is being used.
> 
> Note: With certain parts of HotSpot using ATTRIBUTE_ALIGNED so indiscriminately, this commit will likely take some time to get right
> 
> This will require adding the alignas attribute to the list of language features approved for use in HotSpot code. (Completed with [8297912](https://github.com/openjdk/jdk/pull/11446))

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 six additional commits since the last revision:

 - Merge branch 'openjdk:master' into alignas
 - ATTRIBUTE_ALIGNED(16)
 - Merge branch 'openjdk:master' into alignas
 - Merge branch 'openjdk:master' into alignas
 - Merge branch 'openjdk:master' into alignas
 - alignas

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11431/files
  - new: https://git.openjdk.org/jdk/pull/11431/files/ea968de2..2482e70a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11431&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11431&range=05-06

  Stats: 1424 lines in 312 files changed: 520 ins; 150 del; 754 mod
  Patch: https://git.openjdk.org/jdk/pull/11431.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11431/head:pull/11431

PR: https://git.openjdk.org/jdk/pull/11431

From lkorinth at openjdk.org  Fri Dec 23 22:50:23 2022
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 23 Dec 2022 22:50:23 GMT
Subject: RFR: 8292170: Convert CodeRootSetTable to use ResourceHashtable
 [v4]
In-Reply-To: <BdRsUwTHeM7gAUg1udRTeG-gv2S4slO0zYl5Ys21Pyw=.5701b960-0ecb-4c67-9d11-88d103b2bd0f@github.com>
References: <BdRsUwTHeM7gAUg1udRTeG-gv2S4slO0zYl5Ys21Pyw=.5701b960-0ecb-4c67-9d11-88d103b2bd0f@github.com>
Message-ID: <DIz1vLD41XeqnbGx1ZBNVZkyty00Xf-iNQnbRstWpto=.874de835-d03c-41e2-be3b-f7d6eb5ffbc7@github.com>

> I am replacing the old hash table with ResourceHashtable. In the process I am also removing the redundant `_length` field. By removing the `_length` field, a lot of asserts can be removed as the length will trivially match the length of the underlying table.
> 
> I would like to have feedback on the addition of `unlink_destruct(Function&& should_remove)`. I added it because I prefer to use a functor object that can be used by lambdas instead of an iterator object. However, I did add code to "destruct" resource objects when they are removed instead of just letting them be to reflect that we use `delete` on c-heap objects. Maybe I should remove this "improvement" and then maybe implement the function by calling the existing unlink?

Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:

  can not use contains in combination with add without a lock

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11675/files
  - new: https://git.openjdk.org/jdk/pull/11675/files/0887a73e..32976d38

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11675&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11675&range=02-03

  Stats: 5 lines in 1 file changed: 0 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/11675.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11675/head:pull/11675

PR: https://git.openjdk.org/jdk/pull/11675

From luhenry at openjdk.org  Fri Dec 23 22:53:55 2022
From: luhenry at openjdk.org (Ludovic Henry)
Date: Fri, 23 Dec 2022 22:53:55 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v16]
In-Reply-To: <cPQkHqc5OHG2ytU7dCawy438CddgDCTQFzHvjloUxaE=.3216df79-1f3f-45e9-97c0-acb5a304b1ae@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <cPQkHqc5OHG2ytU7dCawy438CddgDCTQFzHvjloUxaE=.3216df79-1f3f-45e9-97c0-acb5a304b1ae@github.com>
Message-ID: <SMBfjuXn6QGSDX90RguJm7iQ__bTrpeUT6ETOCwPcXs=.d861a25e-961a-4dd3-95c7-09e0434e27ad@github.com>

On Wed, 21 Dec 2022 17:29:23 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops.
>> 
>> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases.
>> 
>> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front.
>> 
>> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads.
>> 
>> With the most recent fixes the x64 intrinsic results on my workstation look like this:
>> 
>> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.199 ?  0.017  ns/op
>> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     6.933 ?  0.049  ns/op
>> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    29.935 ?  0.221  ns/op
>> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  1596.982 ?  7.020  ns/op
>> 
>> Baseline:
>> 
>> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.200 ?  0.013  ns/op
>> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     9.424 ?  0.122  ns/op
>> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    90.541 ?  0.512  ns/op
>> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  9425.321 ? 67.630  ns/op
>> 
>> I.e. no measurable overhead compared to baseline even for `size == 1`.
>> 
>> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good.
>> 
>> Benchmark for `Arrays.hashCode`:
>> 
>> Benchmark              (size)  Mode  Cnt     Score    Error  Units
>> ArraysHashCode.bytes        1  avgt    5     1.884 ?  0.013  ns/op
>> ArraysHashCode.bytes       10  avgt    5     6.955 ?  0.040  ns/op
>> ArraysHashCode.bytes      100  avgt    5    87.218 ?  0.595  ns/op
>> ArraysHashCode.bytes    10000  avgt    5  9419.591 ? 38.308  ns/op
>> ArraysHashCode.chars        1  avgt    5     2.200 ?  0.010  ns/op
>> ArraysHashCode.chars       10  avgt    5     6.935 ?  0.034  ns/op
>> ArraysHashCode.chars      100  avgt    5    30.216 ?  0.134  ns/op
>> ArraysHashCode.chars    10000  avgt    5  1601.629 ?  6.418  ns/op
>> ArraysHashCode.ints         1  avgt    5     2.200 ?  0.007  ns/op
>> ArraysHashCode.ints        10  avgt    5     6.936 ?  0.034  ns/op
>> ArraysHashCode.ints       100  avgt    5    29.412 ?  0.268  ns/op
>> ArraysHashCode.ints     10000  avgt    5  1610.578 ?  7.785  ns/op
>> ArraysHashCode.shorts       1  avgt    5     1.885 ?  0.012  ns/op
>> ArraysHashCode.shorts      10  avgt    5     6.961 ?  0.034  ns/op
>> ArraysHashCode.shorts     100  avgt    5    87.095 ?  0.417  ns/op
>> ArraysHashCode.shorts   10000  avgt    5  9420.617 ? 50.089  ns/op
>> 
>> Baseline:
>> 
>> Benchmark              (size)  Mode  Cnt     Score    Error  Units
>> ArraysHashCode.bytes        1  avgt    5     3.213 ?  0.207  ns/op
>> ArraysHashCode.bytes       10  avgt    5     8.483 ?  0.040  ns/op
>> ArraysHashCode.bytes      100  avgt    5    90.315 ?  0.655  ns/op
>> ArraysHashCode.bytes    10000  avgt    5  9422.094 ? 62.402  ns/op
>> ArraysHashCode.chars        1  avgt    5     3.040 ?  0.066  ns/op
>> ArraysHashCode.chars       10  avgt    5     8.497 ?  0.074  ns/op
>> ArraysHashCode.chars      100  avgt    5    90.074 ?  0.387  ns/op
>> ArraysHashCode.chars    10000  avgt    5  9420.474 ? 41.619  ns/op
>> ArraysHashCode.ints         1  avgt    5     2.827 ?  0.019  ns/op
>> ArraysHashCode.ints        10  avgt    5     7.727 ?  0.043  ns/op
>> ArraysHashCode.ints       100  avgt    5    89.405 ?  0.593  ns/op
>> ArraysHashCode.ints     10000  avgt    5  9426.539 ? 51.308  ns/op
>> ArraysHashCode.shorts       1  avgt    5     3.071 ?  0.062  ns/op
>> ArraysHashCode.shorts      10  avgt    5     8.168 ?  0.049  ns/op
>> ArraysHashCode.shorts     100  avgt    5    90.399 ?  0.292  ns/op
>> ArraysHashCode.shorts   10000  avgt    5  9420.171 ? 44.474  ns/op
>> 
>> 
>> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Treat Op_VectorizedHashCode as other similar Ops in split_unique_types

Marked as reviewed by luhenry (Committer).

-------------

PR: https://git.openjdk.org/jdk/pull/10847

From sspitsyn at openjdk.org  Sat Dec 24 04:14:07 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 24 Dec 2022 04:14:07 GMT
Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling
 one virtual thread transitions [v5]
In-Reply-To: <z8NCIbPeF0WzTEzXGyNxlnuOF_52vbV90p4B15xThFk=.b12cfe49-d27d-4e65-9027-796985005c14@github.com>
References: <z8NCIbPeF0WzTEzXGyNxlnuOF_52vbV90p4B15xThFk=.b12cfe49-d27d-4e65-9027-796985005c14@github.com>
Message-ID: <ONO1PEI-tgHm4z4-mppmc-st3WhwecI3z9T-xKz4KgY=.0c905a1c-8124-4cb0-aecb-8bc377486600@github.com>

> Now the `JvmtiVTMSTransitionDisabler` mechanism supports disabling VTMS transitions for all virtual threads only. It should also support disabling transitions for any specific virtual thread as well. This will improve scalability of the JVMTI functions operating on target virtual threads as the functions can be executed concurrently without blocking each other execution when target virtual threads are different.
> New constructor `JvmtiVTMSTransitionDisabler(jthread vthread)` is added which has jthread parameter of the target virtual thread.
> 
> Testing:
>   mach5 jobs are TBD (preliminary testing was completed):
>    - all JVMTI, JDWP, JDI and JDB tests have to be run
>    - Kitchensink
>    - tier5

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  fix race between VTMS_transition_disable_for_one and start_VTMS_transition

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11690/files
  - new: https://git.openjdk.org/jdk/pull/11690/files/3c73fae3..3effc27d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11690&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11690&range=03-04

  Stats: 38 lines in 7 files changed: 18 ins; 16 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/11690.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11690/head:pull/11690

PR: https://git.openjdk.org/jdk/pull/11690

From sspitsyn at openjdk.org  Sat Dec 24 04:45:48 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 24 Dec 2022 04:45:48 GMT
Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling
 one virtual thread transitions [v4]
In-Reply-To: <6UL6R9_tf9tsHC-BfSryrSklaGzAWidbEoj3VvJ3Uaw=.371c4ade-e653-4623-aa1c-82b81df7901d@github.com>
References: <z8NCIbPeF0WzTEzXGyNxlnuOF_52vbV90p4B15xThFk=.b12cfe49-d27d-4e65-9027-796985005c14@github.com>
 <goPSrd1KFzUyD3FjIgzJuBrBnfAzOy5gHakGaVWo-Vc=.a2812923-b41e-490f-bb7c-dd7e87976ef1@github.com>
 <7s1CyW4SOVZDr43ozNlTD0sgG_qVkS60BcQrmSbCVd4=.50ea4b9d-91c4-41b0-9bc6-3f2b1d3cfeff@github.com>
 <RHwxbYE3qlRhGAIMz3T-ftQcariBnFZIXLH6RVujc4w=.3cc96094-c16a-492e-857c-4c2f71c6f98b@github.com>
 <6UL6R9_tf9tsHC-BfSryrSklaGzAWidbEoj3VvJ3Uaw=.371c4ade-e653-4623-aa1c-82b81df7901d@github.com>
Message-ID: <dwrQa7OWbP-3vYthmfWnQYV4o65f3gyZOTfMwLQ_Kxw=.ff6fc287-a100-4fbc-af1a-da8168ca67ec@github.com>

On Fri, 23 Dec 2022 03:53:19 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I see the problem. Good catch, thanks!
>
> Yep my bad in earlier review. The one case needs the same synchronization/coordination as the all case.

I've moved the `is_in_VTMS_transition()` from `JvmtiThreadState` to `java_lang_Thread (in javaClasses.cpp)`.  My initial implementation had this but at some point I decided to use `JvmtiThreadState::is_in_VTMS_transition()` for optimization purposes.
It introduced a problem as the `JvmtiThreadState` can be absent at the point where it is needed for sync.
I've also fixed race between `VTMS_transition_disable_for_one()` and `start_VTMS_transition()`. It was tested with the nanosleep delays and the assert from Patricio.
Also, one assert has been removed from `jvmtiEnvThreadState.cpp` as it became not always correct.

-------------

PR: https://git.openjdk.org/jdk/pull/11690

From iklam at openjdk.org  Sat Dec 24 05:00:51 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 24 Dec 2022 05:00:51 GMT
Subject: RFR: 8292170: Convert CodeRootSetTable to use ResourceHashtable
 [v4]
In-Reply-To: <DIz1vLD41XeqnbGx1ZBNVZkyty00Xf-iNQnbRstWpto=.874de835-d03c-41e2-be3b-f7d6eb5ffbc7@github.com>
References: <BdRsUwTHeM7gAUg1udRTeG-gv2S4slO0zYl5Ys21Pyw=.5701b960-0ecb-4c67-9d11-88d103b2bd0f@github.com>
 <DIz1vLD41XeqnbGx1ZBNVZkyty00Xf-iNQnbRstWpto=.874de835-d03c-41e2-be3b-f7d6eb5ffbc7@github.com>
Message-ID: <51wTA2TBRihuiQnFfY2JPQLJErKrvsFhrrpFFH8he34=.ab38ab01-761a-44c2-bbf7-ac5432d23a61@github.com>

On Fri, 23 Dec 2022 22:50:23 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> I am replacing the old hash table with ResourceHashtable. In the process I am also removing the redundant `_length` field. By removing the `_length` field, a lot of asserts can be removed as the length will trivially match the length of the underlying table.
>> 
>> I would like to have feedback on the addition of `unlink_destruct(Function&& should_remove)`. I added it because I prefer to use a functor object that can be used by lambdas instead of an iterator object. However, I did add code to "destruct" resource objects when they are removed instead of just letting them be to reflect that we use `delete` on c-heap objects. Maybe I should remove this "improvement" and then maybe implement the function by calling the existing unlink?
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   can not use contains in combination with add without a lock

src/hotspot/share/gc/g1/g1CodeCacheRemSet.cpp line 44:

> 42:   return sizeof(*this) +
> 43:     _table.table_size() * sizeof(Table::Node*) +
> 44:     _table.number_of_entries() * sizeof(Table::Node);

Instead of exporting Table::Node and the details of the implementation, maybe ResourceHashtable should have a function that returns its footprint? I don't know what name we usually use for that. Maybe `ResourceHashtable::mem_size()` to follow the example of `G1CodeRootSetTable::mem_size()`?

-------------

PR: https://git.openjdk.org/jdk/pull/11675

From bulasevich at openjdk.org  Sat Dec 24 05:15:50 2022
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Sat, 24 Dec 2022 05:15:50 GMT
Subject: RFR: 8291302: ARM32: nmethod entry barriers support [v4]
In-Reply-To: <hjEeA3EFQ8HmiK65iRm7WKXX4tmVKC187eEHE_FPOSg=.3a2f657d-f207-4e60-9023-65808595ecc6@github.com>
References: <BJaszr0_haU4UZOyQQEA9P0SOlgtfTtGFBj9VSRD5SM=.ffd6af56-a51e-4627-90cb-0eb0e1bbd5e8@github.com>
 <hjEeA3EFQ8HmiK65iRm7WKXX4tmVKC187eEHE_FPOSg=.3a2f657d-f207-4e60-9023-65808595ecc6@github.com>
Message-ID: <9KuyAH7dqMxyNlU5Fu2MoTrfRotTTY7QLwJ8td0gASg=.3080b010-b863-4690-a112-f21c01e3f5f0@github.com>

On Thu, 8 Dec 2022 15:02:18 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

>> This PR implements nmethod entry barriers for ARM32. It has already been implemented for other ports and is related with JDK-8290025 "Remove the Sweeper".
>
> Aleksei Voitylov 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 four additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8291302-3
>  - remove membar
>  - save float registers
>  - 8291302: ARM32: nmethod entry barriers support

Looks good!

-------------

PR: https://git.openjdk.org/jdk/pull/11442

From kbarrett at openjdk.org  Sat Dec 24 06:51:58 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 24 Dec 2022 06:51:58 GMT
Subject: [jdk20] RFR: 8293824: gc/whitebox/TestConcMarkCycleWB.java failed
 "RuntimeException: assertTrue: expected true, was false"
In-Reply-To: <-LJBut4ETHYR8IDgKzvkumizSmDfB5uPUys0F282gfc=.152bea6b-1156-4280-a149-2cfe3a234a9c@github.com>
References: <-LJBut4ETHYR8IDgKzvkumizSmDfB5uPUys0F282gfc=.152bea6b-1156-4280-a149-2cfe3a234a9c@github.com>
Message-ID: <SrUgx448r-lYaUKGZjvnNGyPIhQTeHujxNAC82j9SWY=.8d8b4d69-9d5f-4a03-9aea-5f8ee677fa49@github.com>

On Thu, 22 Dec 2022 02:04:30 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to WhiteBox and some tests involving G1 concurrent GCs.
> 
> Some tests currently use WhiteBox.g1StartConcMarkCycle() to trigger a
> concurrent GC.  Many of them follow it with a loop waiting for a concurrent
> cycle to not be in progress.  A few also preceed that call with a similar
> loop, since that call does nothing and returns false if a concurrent cycle is
> already in progress.  Those tests typically want to ensure there was a
> concurrent cycle that was started after some setup.
> 
> The failing test calls that function, asserting that it returned true, e.g. a
> new concurrent cycle was started.
> 
> There are various problems with this, due to races with concurrent cycles
> started automatically, and due to possibly aborted (by full GCs) concurrent cycles,
> making some of these tests unreliable in some configurations.
> 
> For example, the test failure associated with this bug intermittently arises
> when running with `-Xcomp`, triggering a concurrent cycle before the explicit
> request by the test, causing the explicit request to fail (because there is
> already one in progress), failing the assert.  Waiting for there not to be an
> in-progress cycle before the explicit request just narrows the race window.
> 
> We have a different mechanism in WhiteBox for controlling concurrent cycles,
> the concurrent GC breakpoint mechanism.  By adding a counter specifically for
> such cycles, we can use GC breakpoints to ensure only the concurrent cycles
> the test wants are occurring, and can verify they completed successfully.
> 
> So we change tests using WhiteBox.g1StartConcMarkCycle() to instead use GC
> breakpoints, along with the new WhiteBox.g1CompletedConcurrentMarkCycles() to
> avoid racing request problems and to detect aborted cycles.  Since it is no
> longer used, WhiteBox.g1StartConcMarkCycle() is removed.  The test that began
> this adventure (TestConcMarkCycleWB.java) is also removed, since it no longer
> serves any purpose, having been purely a test of that removed function.
> 
> Testing:
> mach5 tier1-7 - running the changed tests on a variety of platforms with a
> variety of configurations.

BTW, after this change `GCCause::_wb_conc_mark` appears to no longer ever be issued.  I'm planning to remove it under the rubric of JDK-8235737.

-------------

PR: https://git.openjdk.org/jdk20/pull/71

From avoitylov at openjdk.org  Sat Dec 24 09:31:50 2022
From: avoitylov at openjdk.org (Aleksei Voitylov)
Date: Sat, 24 Dec 2022 09:31:50 GMT
Subject: RFR: 8291302: ARM32: nmethod entry barriers support [v2]
In-Reply-To: <eEgeEjW5rY-XUYoIPAo3glxmhKESfURCutuiICm9dkU=.c6198a1b-3798-4c99-b7ff-7bad5a314130@github.com>
References: <BJaszr0_haU4UZOyQQEA9P0SOlgtfTtGFBj9VSRD5SM=.ffd6af56-a51e-4627-90cb-0eb0e1bbd5e8@github.com>
 <JghFO_YuAWdgvKFJpaUzuiaeLYjRrRav4hfR0u2LkWw=.529baf93-df04-4c3a-9ed2-fd884f2cd60b@github.com>
 <eEgeEjW5rY-XUYoIPAo3glxmhKESfURCutuiICm9dkU=.c6198a1b-3798-4c99-b7ff-7bad5a314130@github.com>
Message-ID: <hMFrgKGUhR-JaCT8_Y5Zfg6KLFGT-hMC18eB2XzzbW4=.f2457582-afee-4939-99b5-6fb7ed5791a4@github.com>

On Mon, 5 Dec 2022 14:54:51 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   save float registers
>
> Please note that the memory barrier has caused a performance regression on PPC64 (as on AArch64): https://bugs.openjdk.org/browse/JDK-8295069
> I'd probably assert `nmethod_patching_type() == NMethodPatchingType::stw_instruction_and_data_patch` instead of emitting a memory barrier because `LoadLoad` may or may not be strong enough depending on usage (e.g. generational ZGC uses instruction patching as well).

@TheRealMDoerr @reinrich @bulasevich thank you for your reviews!

-------------

PR: https://git.openjdk.org/jdk/pull/11442

From avoitylov at openjdk.org  Sat Dec 24 09:31:54 2022
From: avoitylov at openjdk.org (Aleksei Voitylov)
Date: Sat, 24 Dec 2022 09:31:54 GMT
Subject: RFR: 8291302: ARM32: nmethod entry barriers support [v4]
In-Reply-To: <DtHvGM7UYziT5t9mqAihHlOR7WqwoE7RMvHY0Pt3PJU=.47aaab8a-9c1a-4158-9925-3f75df9d14b2@github.com>
References: <BJaszr0_haU4UZOyQQEA9P0SOlgtfTtGFBj9VSRD5SM=.ffd6af56-a51e-4627-90cb-0eb0e1bbd5e8@github.com>
 <DtHvGM7UYziT5t9mqAihHlOR7WqwoE7RMvHY0Pt3PJU=.47aaab8a-9c1a-4158-9925-3f75df9d14b2@github.com>
Message-ID: <WFt2twDmT8Tv5ikCfuoff6KcCimlunErBgaq9hMix5g=.05258f6d-96ba-4407-9439-daafc40f5dbd@github.com>

On Wed, 30 Nov 2022 21:01:04 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> Aleksei Voitylov 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 four additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into JDK-8291302-3
>>  - remove membar
>>  - save float registers
>>  - 8291302: ARM32: nmethod entry barriers support
>
> When you call the nmethod entry barrier slow path, floating point arguments are live, but can get clobbered by the C++ runtime. You need to save them. That's probably why you can't print in the slow path without crashing.

@fisk do you have any further comments? I'd like to have this in to continue working on Loom.

-------------

PR: https://git.openjdk.org/jdk/pull/11442

From aph at openjdk.org  Sat Dec 24 10:09:54 2022
From: aph at openjdk.org (Andrew Haley)
Date: Sat, 24 Dec 2022 10:09:54 GMT
Subject: RFR: 8291302: ARM32: nmethod entry barriers support [v4]
In-Reply-To: <hjEeA3EFQ8HmiK65iRm7WKXX4tmVKC187eEHE_FPOSg=.3a2f657d-f207-4e60-9023-65808595ecc6@github.com>
References: <BJaszr0_haU4UZOyQQEA9P0SOlgtfTtGFBj9VSRD5SM=.ffd6af56-a51e-4627-90cb-0eb0e1bbd5e8@github.com>
 <hjEeA3EFQ8HmiK65iRm7WKXX4tmVKC187eEHE_FPOSg=.3a2f657d-f207-4e60-9023-65808595ecc6@github.com>
Message-ID: <huYnoScjesHduOdFrvoju9V3SDPjonMX0hjedqNFpA0=.130b2b86-7a1a-4fba-9410-619282d84a59@github.com>

On Thu, 8 Dec 2022 15:02:18 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

>> This PR implements nmethod entry barriers for ARM32. It has already been implemented for other ports and is related with JDK-8290025 "Remove the Sweeper".
>
> Aleksei Voitylov 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 four additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8291302-3
>  - remove membar
>  - save float registers
>  - 8291302: ARM32: nmethod entry barriers support

src/hotspot/cpu/arm/arm.ad line 294:

> 292: 
> 293:   if (C->stub_function() == NULL && BarrierSet::barrier_set()->barrier_set_nmethod() != NULL) {
> 294:     st->print("ldr  t0, [guard]\n\t");

Suggestion:

    st->print("ldr t0, [guard]\n\t");

-------------

PR: https://git.openjdk.org/jdk/pull/11442

From aph at openjdk.org  Sat Dec 24 10:17:51 2022
From: aph at openjdk.org (Andrew Haley)
Date: Sat, 24 Dec 2022 10:17:51 GMT
Subject: RFR: 8291302: ARM32: nmethod entry barriers support [v4]
In-Reply-To: <hjEeA3EFQ8HmiK65iRm7WKXX4tmVKC187eEHE_FPOSg=.3a2f657d-f207-4e60-9023-65808595ecc6@github.com>
References: <BJaszr0_haU4UZOyQQEA9P0SOlgtfTtGFBj9VSRD5SM=.ffd6af56-a51e-4627-90cb-0eb0e1bbd5e8@github.com>
 <hjEeA3EFQ8HmiK65iRm7WKXX4tmVKC187eEHE_FPOSg=.3a2f657d-f207-4e60-9023-65808595ecc6@github.com>
Message-ID: <YgU4zHOuvTpcTBME6m56Hr_kEaACj3nsL-O9nBS88X4=.de668160-274c-4ed3-8fcb-278255ac3d45@github.com>

On Thu, 8 Dec 2022 15:02:18 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

>> This PR implements nmethod entry barriers for ARM32. It has already been implemented for other ports and is related with JDK-8290025 "Remove the Sweeper".
>
> Aleksei Voitylov 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 four additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8291302-3
>  - remove membar
>  - save float registers
>  - 8291302: ARM32: nmethod entry barriers support

src/hotspot/cpu/arm/gc/shared/barrierSetAssembler_arm.cpp line 207:

> 205: 
> 206:   Register tmp0 = Rtemp;
> 207:   Register tmp1 = R5; // wrong register here will lead to crash

Why specifically `R5` ? Please add a comment.

src/hotspot/cpu/arm/gc/shared/barrierSetAssembler_arm.cpp line 214:

> 212: 
> 213:   // The are no GCs that require memory barrier on arm32 now
> 214: #ifndef PRODUCT

Suggestion:

#ifdef ASSERT

-------------

PR: https://git.openjdk.org/jdk/pull/11442

From aph at openjdk.org  Sat Dec 24 10:32:52 2022
From: aph at openjdk.org (Andrew Haley)
Date: Sat, 24 Dec 2022 10:32:52 GMT
Subject: RFR: 8291302: ARM32: nmethod entry barriers support [v4]
In-Reply-To: <hjEeA3EFQ8HmiK65iRm7WKXX4tmVKC187eEHE_FPOSg=.3a2f657d-f207-4e60-9023-65808595ecc6@github.com>
References: <BJaszr0_haU4UZOyQQEA9P0SOlgtfTtGFBj9VSRD5SM=.ffd6af56-a51e-4627-90cb-0eb0e1bbd5e8@github.com>
 <hjEeA3EFQ8HmiK65iRm7WKXX4tmVKC187eEHE_FPOSg=.3a2f657d-f207-4e60-9023-65808595ecc6@github.com>
Message-ID: <GMjLJRLU7cXlUpah1f_k-L5z00zixz2s3zeI9CeqgO8=.13c34b52-2548-463f-9edf-4899b285a1a6@github.com>

On Thu, 8 Dec 2022 15:02:18 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

>> This PR implements nmethod entry barriers for ARM32. It has already been implemented for other ports and is related with JDK-8290025 "Remove the Sweeper".
>
> Aleksei Voitylov 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 four additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8291302-3
>  - remove membar
>  - save float registers
>  - 8291302: ARM32: nmethod entry barriers support

Looks reasonable. Please consider my cleanups.

src/hotspot/cpu/arm/arm.ad line 303:

> 301:     st->print("skip:\n\t");
> 302:   }
> 303: }

I wonder if this stuff should be in `barrierSetAssembler` ? Just a thought.

src/hotspot/cpu/arm/gc/shared/barrierSetNMethod_arm.cpp line 40:

> 38: // The constant below reflects the size of the barrier
> 39: // in barrierSetAssembler_arm.cpp
> 40: static const int entry_barrier_bytes = 36;

Suggestion:

static const int entry_barrier_bytes = 9 * NativeInstruction::size();

-------------

Marked as reviewed by aph (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11442

From alexandr.miloslavskiy at syntevo.com  Sat Dec 24 13:18:36 2022
From: alexandr.miloslavskiy at syntevo.com (Alexandr Miloslavskiy)
Date: Sat, 24 Dec 2022 16:18:36 +0300
Subject: Potential sensitive information leak through JVM crash logs
Message-ID: <7b8f09fe-b25f-18c2-57e2-d9a284965ff0@syntevo.com>

Hello,

For a quick understanding, consider the following potential 
hs_err_pid*.log file:

----------------------------------------
...
stack at sp + 2 slots: 0x00000000c0401098 is an oop: org.x.y.z
{0x00000000c0401098} - klass: 'org/x/y/z'
  - ---- fields (total size 141 words):
  ...
  - 'x' 'Lorg/a/b/c;' @184  NULL (0)
  - 'myPasswordString' 'Ljava/lang/String;' @188  "My password:
correct-horse-battery-staple"{0x00000000c0b01ef0} (c0b01ef0)
  - 'y' 'Ljava/lang/String;' @192  "foobar"
...
stack at sp + 3 slots: 0x00007fb06effd7c0 is pointing into the stack for 
thread: 0x00007fb0680240f0
...
----------------------------------------

Here, crash log accidentally exposes a sensitive bit of user's 
information (the password).

In our product, when JVM crashes, we ask user to send a crash report.
But users shouldn't be worried that said report may contain something 
really sensitive.

For this reason, since we upgraded to JDK that has this feature, we 
decided to strip these object dumps from the crash log before sending it.

So far we decided to strip all lines starting from `- ---- fields` until 
one of
1) `stack at sp + 3 slots` where `+ 3` is exactly 1 more than
    previously seen `stack at sp + 2 slots`
2) a line that starts with `R??=` where ?? is any two chars,
    to handle registers
3) next section in crash log such as
    'Registers:' or
    '---------------  P R O C E S S  ---------------'.

It can be seen how it's not convenient and not very reliable to strip 
due to parsing issues. Especially when a String contains embedded \n, 
which prevents the easy solution to strip all lines beginning with ` - `
(see example crash log above).

We propose the following possible solutions:
1) Add some unique marker to begin and end of each object dump, so that 
everything between the markers can be stripped.
2) Otherwise, ensure that Strings don't span to next line when there's 
an embedded \n.

For your reference, a typical crash log can be seen in [1], where object 
dumps are seen in both sections
'Register to memory mapping:'
'Stack slot to memory mapping:'

According to my research, the feature of dumping objects in crash logs 
was (accidentally?) introduced in commit:
   5e557d86 by Kevin Walls, 2021-06-08 01:26:13
   8266967: debug.cpp utility find() should print Java Object fields.

[1] https://bugs.openjdk.org/browse/JDK-8284988

From avoitylov at openjdk.org  Mon Dec 26 10:31:12 2022
From: avoitylov at openjdk.org (Aleksei Voitylov)
Date: Mon, 26 Dec 2022 10:31:12 GMT
Subject: RFR: 8291302: ARM32: nmethod entry barriers support [v5]
In-Reply-To: <BJaszr0_haU4UZOyQQEA9P0SOlgtfTtGFBj9VSRD5SM=.ffd6af56-a51e-4627-90cb-0eb0e1bbd5e8@github.com>
References: <BJaszr0_haU4UZOyQQEA9P0SOlgtfTtGFBj9VSRD5SM=.ffd6af56-a51e-4627-90cb-0eb0e1bbd5e8@github.com>
Message-ID: <ge7HPHYoX-hUsNwQvmpp7_dGUGV5viDuYU9ga_RkGFQ=.8355cf3a-b370-48b7-8e23-78e00326377d@github.com>

> This PR implements nmethod entry barriers for ARM32. It has already been implemented for other ports and is related with JDK-8290025 "Remove the Sweeper".

Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:

  address review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11442/files
  - new: https://git.openjdk.org/jdk/pull/11442/files/079a1a9b..aa7fc860

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11442&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11442&range=03-04

  Stats: 7 lines in 4 files changed: 3 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/11442.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11442/head:pull/11442

PR: https://git.openjdk.org/jdk/pull/11442

From avoitylov at openjdk.org  Mon Dec 26 10:32:53 2022
From: avoitylov at openjdk.org (Aleksei Voitylov)
Date: Mon, 26 Dec 2022 10:32:53 GMT
Subject: RFR: 8291302: ARM32: nmethod entry barriers support [v4]
In-Reply-To: <GMjLJRLU7cXlUpah1f_k-L5z00zixz2s3zeI9CeqgO8=.13c34b52-2548-463f-9edf-4899b285a1a6@github.com>
References: <BJaszr0_haU4UZOyQQEA9P0SOlgtfTtGFBj9VSRD5SM=.ffd6af56-a51e-4627-90cb-0eb0e1bbd5e8@github.com>
 <hjEeA3EFQ8HmiK65iRm7WKXX4tmVKC187eEHE_FPOSg=.3a2f657d-f207-4e60-9023-65808595ecc6@github.com>
 <GMjLJRLU7cXlUpah1f_k-L5z00zixz2s3zeI9CeqgO8=.13c34b52-2548-463f-9edf-4899b285a1a6@github.com>
Message-ID: <eW6DS6uY0CLqGqP4dPNSLt5nGCXEALDLqymHvHoMbgU=.1ca82925-36a5-4593-bd60-1669ab2fd1e9@github.com>

On Sat, 24 Dec 2022 10:30:23 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Aleksei Voitylov 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 four additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into JDK-8291302-3
>>  - remove membar
>>  - save float registers
>>  - 8291302: ARM32: nmethod entry barriers support
>
> Looks reasonable. Please consider my cleanups.

Thanks @theRealAph . Your suggestions for cleanups are addressed.

-------------

PR: https://git.openjdk.org/jdk/pull/11442

From jwaters at openjdk.org  Mon Dec 26 16:03:35 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 26 Dec 2022 16:03:35 GMT
Subject: RFR: 8250269: Replace ATTRIBUTE_ALIGNED with alignas [v8]
In-Reply-To: <9QKV9cYFTo_1D8R-mI80lnewNkA0ceJNKFPbrvICxl4=.d6736b76-8324-4084-bede-6e144b4f6c04@github.com>
References: <9QKV9cYFTo_1D8R-mI80lnewNkA0ceJNKFPbrvICxl4=.d6736b76-8324-4084-bede-6e144b4f6c04@github.com>
Message-ID: <RwI1h36ZFp1CHG89X_IhLZcZzFXlFTS_zryaHdrinCo=.b7555026-d174-4586-acbf-30d085191ef1@github.com>

> C++11 added the alignas attribute, for the purpose of specifying alignment on types, much like compiler specific syntax such as gcc's __attribute__((aligned(x))) or Visual C++'s __declspec(align(x)).
> 
> We can phase out the use of the macro in favor of the standard attribute. In the meantime, we can replace the compiler specific definitions of ATTRIBUTE_ALIGNED with a portable definition. We might deprecate the use of the macro but changing its implementation quickly and cleanly applies the feature where the macro is being used.
> 
> Note: With certain parts of HotSpot using ATTRIBUTE_ALIGNED so indiscriminately, this commit will likely take some time to get right
> 
> This will require adding the alignas attribute to the list of language features approved for use in HotSpot code. (Completed with [8297912](https://github.com/openjdk/jdk/pull/11446))

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 seven additional commits since the last revision:

 - Merge branch 'openjdk:master' into alignas
 - Merge branch 'openjdk:master' into alignas
 - ATTRIBUTE_ALIGNED(16)
 - Merge branch 'openjdk:master' into alignas
 - Merge branch 'openjdk:master' into alignas
 - Merge branch 'openjdk:master' into alignas
 - alignas

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11431/files
  - new: https://git.openjdk.org/jdk/pull/11431/files/2482e70a..7df2abf1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11431&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11431&range=06-07

  Stats: 251 lines in 10 files changed: 176 ins; 36 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/11431.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11431/head:pull/11431

PR: https://git.openjdk.org/jdk/pull/11431

From jwaters at openjdk.org  Mon Dec 26 16:13:20 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 26 Dec 2022 16:13:20 GMT
Subject: RFR: 8274400: HotSpot Style Guide should permit use of alignof
 [v2]
In-Reply-To: <3IdeZGaGcFB1-DbVugn0P9v8vRQMLURzHFRSpAm46NA=.09bf4dd8-b652-49c3-b9a5-ad3f58dfbcc3@github.com>
References: <3IdeZGaGcFB1-DbVugn0P9v8vRQMLURzHFRSpAm46NA=.09bf4dd8-b652-49c3-b9a5-ad3f58dfbcc3@github.com>
Message-ID: <1YZL6wmSuJh2DL2XGhBeSxotq8SxD1_tzJJsXWNScVg=.10ddbf8a-f584-413a-adf8-f3ef6c747aa8@github.com>

> The alignof operator was added by C++11. It returns the alignment for the given type. Various metaprogramming usages exist, in particular when using std::aligned_storage. Use of this operator should be permitted in HotSpot code.

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 three additional commits since the last revision:

 - More Descriptive Version
 - Merge remote-tracking branch 'upstream/master' into alignof
 - HotSpot Style Guide should permit use of alignof

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11761/files
  - new: https://git.openjdk.org/jdk/pull/11761/files/0862132e..5ec061a4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11761&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11761&range=00-01

  Stats: 1704 lines in 324 files changed: 720 ins; 191 del; 793 mod
  Patch: https://git.openjdk.org/jdk/pull/11761.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11761/head:pull/11761

PR: https://git.openjdk.org/jdk/pull/11761

From jwaters at openjdk.org  Mon Dec 26 16:14:52 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 26 Dec 2022 16:14:52 GMT
Subject: RFR: 8274400: HotSpot Style Guide should permit use of alignof
 [v2]
In-Reply-To: <S8zZSnZEdFRx7Bs6p4P2O6AHFA8k7Cn3zsGPYh16KEs=.1a8cc240-08da-44f7-a98a-8d1b9322a18d@github.com>
References: <3IdeZGaGcFB1-DbVugn0P9v8vRQMLURzHFRSpAm46NA=.09bf4dd8-b652-49c3-b9a5-ad3f58dfbcc3@github.com>
 <S8zZSnZEdFRx7Bs6p4P2O6AHFA8k7Cn3zsGPYh16KEs=.1a8cc240-08da-44f7-a98a-8d1b9322a18d@github.com>
Message-ID: <zRFAaaLDqNRydAu0OUaC1GxUGjYS1-PuMPmn3ESKhX8=.abcc29f4-125e-4e20-bd77-f16c94ca6aa7@github.com>

On Thu, 22 Dec 2022 20:03:37 GMT, Kim Barrett <kbarrett at openjdk.org> 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 three additional commits since the last revision:
>> 
>>  - More Descriptive Version
>>  - Merge remote-tracking branch 'upstream/master' into alignof
>>  - HotSpot Style Guide should permit use of alignof
>
> doc/hotspot-style.md line 1060:
> 
>> 1058: 
>> 1059: * `alignof`
>> 1060: ([n2341](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2341.pdf))
> 
> Should say that `alignof` should be used instead of `std::alignment_of`.

Got it, swapped to the more descriptive version to mention this. I'll discuss about the reasons for permitting it little later, right now I'm somewhat swamped by build-dev stuff

-------------

PR: https://git.openjdk.org/jdk/pull/11761

From kbarrett at openjdk.org  Mon Dec 26 23:56:50 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 26 Dec 2022 23:56:50 GMT
Subject: RFR: 8274400: HotSpot Style Guide should permit use of alignof
 [v2]
In-Reply-To: <1YZL6wmSuJh2DL2XGhBeSxotq8SxD1_tzJJsXWNScVg=.10ddbf8a-f584-413a-adf8-f3ef6c747aa8@github.com>
References: <3IdeZGaGcFB1-DbVugn0P9v8vRQMLURzHFRSpAm46NA=.09bf4dd8-b652-49c3-b9a5-ad3f58dfbcc3@github.com>
 <1YZL6wmSuJh2DL2XGhBeSxotq8SxD1_tzJJsXWNScVg=.10ddbf8a-f584-413a-adf8-f3ef6c747aa8@github.com>
Message-ID: <tAwGBwmmS57x6ck8bIjygwTn5peY6uZu3FciBhFnsps=.cb781a36-90e1-40f0-b524-14cbbb31b533@github.com>

On Mon, 26 Dec 2022 16:13:20 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> The alignof operator was added by C++11. It returns the alignment for the given type. Various metaprogramming usages exist, in particular when using std::aligned_storage. Use of this operator should be permitted in HotSpot code.
>
> 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 three additional commits since the last revision:
> 
>  - More Descriptive Version
>  - Merge remote-tracking branch 'upstream/master' into alignof
>  - HotSpot Style Guide should permit use of alignof

doc/hotspot-style.md line 708:

> 706: operator in the development of the language and just returns the corresponding
> 707: `alignof` value, the operator simply provides less verbose syntax for doing so.
> 708: Newer code should prefer `alignof` to `std::alignment_of<>` if possible.

Some of this is extraneous, explaining what `alignof` does, which one can get
elsewhere.  (We don't need to summarize/duplicate that information here.)
Something short and simple like this is sufficient:

Use of `alignof`
([n2341](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2341.pdf))
is permitted.  It should be used instead of `std::alignment_of<>`.

(We don't need to talk about "Newer code" - I'm pretty sure we have no uses of `std::alignment_of<>`
in HotSpot.)

-------------

PR: https://git.openjdk.org/jdk/pull/11761

From jcking at openjdk.org  Tue Dec 27 08:41:49 2022
From: jcking at openjdk.org (Justin King)
Date: Tue, 27 Dec 2022 08:41:49 GMT
Subject: RFR: 8274400: HotSpot Style Guide should permit use of alignof
 [v2]
In-Reply-To: <1YZL6wmSuJh2DL2XGhBeSxotq8SxD1_tzJJsXWNScVg=.10ddbf8a-f584-413a-adf8-f3ef6c747aa8@github.com>
References: <3IdeZGaGcFB1-DbVugn0P9v8vRQMLURzHFRSpAm46NA=.09bf4dd8-b652-49c3-b9a5-ad3f58dfbcc3@github.com>
 <1YZL6wmSuJh2DL2XGhBeSxotq8SxD1_tzJJsXWNScVg=.10ddbf8a-f584-413a-adf8-f3ef6c747aa8@github.com>
Message-ID: <gW8Tcg8FwMZsPJ2DtFi2JwqUYepWgDvyLW92x9RwaGw=.0b3fb84d-47a8-4cda-b405-7efd91c6c5ad@github.com>

On Mon, 26 Dec 2022 16:13:20 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> The alignof operator was added by C++11. It returns the alignment for the given type. Various metaprogramming usages exist, in particular when using std::aligned_storage. Use of this operator should be permitted in HotSpot code.
>
> 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 three additional commits since the last revision:
> 
>  - More Descriptive Version
>  - Merge remote-tracking branch 'upstream/master' into alignof
>  - HotSpot Style Guide should permit use of alignof

FYI `std::aligned_storage` and `std::aligned_union` are deprecated in C++23 and will eventually be removed in future versions.

So shifting toward `alignas` and `alignof` makes the most sense, as proposed.

-------------

PR: https://git.openjdk.org/jdk/pull/11761

From mernst at openjdk.org  Tue Dec 27 14:26:39 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Tue, 27 Dec 2022 14:26:39 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v3]
In-Reply-To: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
Message-ID: <G6y9-__VIQjwSKAhHqAaBz9XhPTAsANIlDIZqrlAlow=.efb3bc20-d266-4717-84ee-b970989f8e44@github.com>

> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge ../jdk-openjdk into typos-typos
 - Reinstate typos in Apache code that is copied into the JDK
 - Merge ../jdk-openjdk into typos-typos
 - Remove file that was removed upstream
 - Fix inconsistency in capitalization
 - Undo change in zlip
 - Fix typos

-------------

Changes: https://git.openjdk.org/jdk/pull/10029/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10029&range=02
  Stats: 11 lines in 10 files changed: 0 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/10029.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10029/head:pull/10029

PR: https://git.openjdk.org/jdk/pull/10029

From mernst at openjdk.org  Tue Dec 27 14:26:40 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Tue, 27 Dec 2022 14:26:40 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <o4GUMwlhtn6ng4FZjHRzZ3iqJD0dlAWKnXsufxhmbqk=.4920d482-3bba-4814-88b6-6a7e839349e2@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
 <gOXCJJl7JqlhdMiDjhu5kbAGieFHPelXHl_XvNG3Pyw=.881b6edb-36c1-4044-99da-18b45b28a69b@github.com>
 <o4GUMwlhtn6ng4FZjHRzZ3iqJD0dlAWKnXsufxhmbqk=.4920d482-3bba-4814-88b6-6a7e839349e2@github.com>
Message-ID: <KQM3bb5WQ1wCnIsc8lnqTrD54nkWyrhnHyk7hkSfp70=.5924492b-d7e8-4a26-bbe7-f78f0c9f9959@github.com>

On Mon, 28 Nov 2022 09:00:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Could someone who knows the undocumented ins and outs of creating JDK pull requests could split this pull request up into multiple PRs?  Then it can be merged, rather than wasting all the effort that went into it.
>
>> Could someone who knows the undocumented ins and outs of creating JDK pull requests could split this pull request up into multiple PRs? Then it can be merged, rather than wasting all the effort that went into it.
> 
> I've raised https://github.com/openjdk/jdk/pull/11385 for one set of changes from this current PR. I'll pick up the other ones shortly in different PRs.

Many thanks to those (especially @jaikiran) who helped to merge many of these typo fixes.
I have pulled master and resolved merge conflicts.  Only 11 typo fixes remain.
Could someone shepherd those into the codebase?  Thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/10029

From duke at openjdk.org  Tue Dec 27 14:44:06 2022
From: duke at openjdk.org (Christoph)
Date: Tue, 27 Dec 2022 14:44:06 GMT
Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v19]
In-Reply-To: <W8Ac5RQQcrQmv0Z_dU-lwhu1ny1MjgGq7xvnObMFTlU=.c4eeee8b-535e-4394-99db-10a7918e8733@github.com>
References: <fWd_NIunUhDXwy8uZSno90GC-PM8pFCey-pAMxxO0rI=.0fede0e4-1438-4321-bc8d-d11565389cae@github.com>
 <W8Ac5RQQcrQmv0Z_dU-lwhu1ny1MjgGq7xvnObMFTlU=.c4eeee8b-535e-4394-99db-10a7918e8733@github.com>
Message-ID: <IjQKyb39LaSWsKhpb9QqokFE0LzkytGH324VkE3H1yM=.e6f4a4d6-dff7-494c-9eda-cfa7e1e52844@github.com>

On Thu, 8 Dec 2022 19:41:16 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> May I have this update reviewed?
>> 
>> The sprintf is deprecated in Xcode 14 because of security concerns, and the use of it causing building failure.  The build could pass if warnings are disabled for codes that use sprintf method.  For the long run, the sprintf could be replaced with snprintf.  This patch is trying to check if snprintf could be used.
>> 
>> Thanks,
>> Xuelei
>
> Xue-Lei Andrew Fan 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 24 additional commits since the last revision:
> 
>  - adlc update per review
>  - Merge
>  - update on review feedback
>  - comment for snprintf_checked
>  - use checked snprintf for adlc
>  - use checked snprintf
>  - no check on adlc
>  - revert use of assert
>  - extra sizeof typo
>  - more size_t updare for windows build
>  - ... and 14 more: https://git.openjdk.org/jdk/compare/3a3bbe53...49bb58fd

I just stumbled across this issue as well, make images did succeed, only the test is now failing with the same error
mac os 13.1 with XCode 14.2 on macbook M1 pro 
commit: 
11fd651ab1820770e3c65cd49589416098987a87 


ERROR: Build failed for target 'run-test-tier1' in configuration 'macosx-aarch64-server-release' (exit code 2) 

=== Output from failing command(s) repeated here ===
* For target support_test_hotspot_jtreg_native_support_libAsyncExceptionOnMonitorEnter_libAsyncExceptionOnMonitorEnter.o:

-------------

PR: https://git.openjdk.org/jdk/pull/11115

From xuelei at openjdk.org  Tue Dec 27 19:43:58 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 27 Dec 2022 19:43:58 GMT
Subject: RFR: 8296812: sprintf is deprecated in Xcode 14 [v19]
In-Reply-To: <IjQKyb39LaSWsKhpb9QqokFE0LzkytGH324VkE3H1yM=.e6f4a4d6-dff7-494c-9eda-cfa7e1e52844@github.com>
References: <fWd_NIunUhDXwy8uZSno90GC-PM8pFCey-pAMxxO0rI=.0fede0e4-1438-4321-bc8d-d11565389cae@github.com>
 <W8Ac5RQQcrQmv0Z_dU-lwhu1ny1MjgGq7xvnObMFTlU=.c4eeee8b-535e-4394-99db-10a7918e8733@github.com>
 <IjQKyb39LaSWsKhpb9QqokFE0LzkytGH324VkE3H1yM=.e6f4a4d6-dff7-494c-9eda-cfa7e1e52844@github.com>
Message-ID: <h75W5m-3jUgO0q1V9h2_RhhWuC_r4sTPVNsUbzrsjtA=.fef0b4dd-a9a0-4145-b421-57b90628d701@github.com>

On Tue, 27 Dec 2022 14:40:36 GMT, Christoph <duke at openjdk.org> wrote:

> ERROR: Build failed for target 'run-test-tier1' in configuration 'macosx-aarch64-server-release' (exit code 2) 
> 
[JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) was filled to track the issue.  Thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/11115

From xuelei at openjdk.org  Wed Dec 28 06:00:28 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 28 Dec 2022 06:00:28 GMT
Subject: RFR: 8299378: sprintf is deprecated in Xcode 14
Message-ID: <g_gb9vcjdqturNiGlYlZytFzJFgKUlcpq5JRAkCeUbE=.cc7e47b3-037b-4efd-8b2e-5ed17061961f@github.com>

The `sprintf` is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812), but the test was not covered. The failure was [reported later](https://github.com/openjdk/jdk/pull/11115#issuecomment-1344973773), while gtest is enabled for building.

This patch is just to make sure the building could pass.   Other than that, the use of `sprintf` in other places are not touched.

-------------

Commit messages:
 - 8299378: sprintf is deprecated in Xcode 14

Changes: https://git.openjdk.org/jdk/pull/11793/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11793&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299378
  Stats: 5 lines in 3 files changed: 1 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/11793.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11793/head:pull/11793

PR: https://git.openjdk.org/jdk/pull/11793

From jcking at openjdk.org  Wed Dec 28 06:10:49 2022
From: jcking at openjdk.org (Justin King)
Date: Wed, 28 Dec 2022 06:10:49 GMT
Subject: RFR: JDK-8299386: Refactor metaprogramming to use <type_traits>
Message-ID: <4IgAzvExdRfJLSpdv2zIG1hMdZHJLKOv62FMP6IyAPg=.bf4322b6-83ed-4cc7-a1e7-81333079afd8@github.com>

Cleanup `metaprogramming/` to just use implementations from `<type_traits>` that are available in C++11 and onward.

-------------

Commit messages:
 - Add back missing template declaration
 - Refactor metaprogramming to use <type_traits>

Changes: https://git.openjdk.org/jdk/pull/11794/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11794&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299386
  Stats: 120 lines in 16 files changed: 11 ins; 69 del; 40 mod
  Patch: https://git.openjdk.org/jdk/pull/11794.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11794/head:pull/11794

PR: https://git.openjdk.org/jdk/pull/11794

From xuelei at openjdk.org  Wed Dec 28 07:01:19 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 28 Dec 2022 07:01:19 GMT
Subject: RFR: 8299378: sprintf is deprecated in Xcode 14 [v2]
In-Reply-To: <g_gb9vcjdqturNiGlYlZytFzJFgKUlcpq5JRAkCeUbE=.cc7e47b3-037b-4efd-8b2e-5ed17061961f@github.com>
References: <g_gb9vcjdqturNiGlYlZytFzJFgKUlcpq5JRAkCeUbE=.cc7e47b3-037b-4efd-8b2e-5ed17061961f@github.com>
Message-ID: <iHSGIbeizrwxLfkyNO9sMKgbQcG1IJhHHgTol1MNGd4=.4aba4421-c311-4caf-9d52-7db12bb8373c@github.com>

> The `sprintf` is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812), but the test was not covered. The failure was [reported later](https://github.com/openjdk/jdk/pull/11115#issuecomment-1344973773), while gtest is enabled for building.
> 
> This patch is just to make sure the building could pass.   Other than that, the use of `sprintf` in other places are not touched.

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  include os

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11793/files
  - new: https://git.openjdk.org/jdk/pull/11793/files/623b566c..3d5f9d43

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11793&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11793&range=00-01

  Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11793.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11793/head:pull/11793

PR: https://git.openjdk.org/jdk/pull/11793

From kbarrett at openjdk.org  Wed Dec 28 08:04:53 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 28 Dec 2022 08:04:53 GMT
Subject: RFR: JDK-8299386: Refactor metaprogramming to use <type_traits>
In-Reply-To: <4IgAzvExdRfJLSpdv2zIG1hMdZHJLKOv62FMP6IyAPg=.bf4322b6-83ed-4cc7-a1e7-81333079afd8@github.com>
References: <4IgAzvExdRfJLSpdv2zIG1hMdZHJLKOv62FMP6IyAPg=.bf4322b6-83ed-4cc7-a1e7-81333079afd8@github.com>
Message-ID: <Nzg0u_WEWkmS7zwbfXY_9IxeavVKEzWG73CR8ehrPQk=.36596edf-3f70-49b4-8734-e0f314345740@github.com>

On Wed, 28 Dec 2022 06:00:59 GMT, Justin King <jcking at openjdk.org> wrote:

> Cleanup `metaprogramming/` to just use implementations from `<type_traits>` that are available in C++11 and onward.

I started out intending to suggest replacing some of these changes by instead
updating the uses of a couple that are rarely used, and getting rid of the
associated pre-C++11 synonyms entirely. But it turns out most are rarely used,
leading me to question this change almost in its entirety.

I think better would be a series of changes to replace uses of the synonyms
with the corresponding element from <type_traits> and delete the synonyms.  I
say "a series of changes" because I would prefer it not be done all in one
changeset, for easier reviewing.

I suggest making an exception for EnableIf, because of the number of uses and
because I'm hoping we'll be able to revise them in a better way in the not too
distant future. Many of the uses are for function SFINAE, where the syntax is
pretty horrible. We have the newer form of function SFINAE available (see
ENABLE_IF), but I think in many/most cases even better would be to use C++17
constexpr if. That's why I haven't proposed rewriting any of them using
ENABLE_IF. I'm hopeful that using C++17 isn't too far away, now that there
seems to be a compiler available for the aix-ppc port.

src/hotspot/share/metaprogramming/integralConstant.hpp line 50:

> 48: 
> 49: // A bool valued IntegralConstant whose value is true.
> 50: using TrueType = std::true_type;

Outside of the implementation of our pre-C++11 metaprogramming tools, there are only a very small number of uses of this type.  It would be better to update those uses.

src/hotspot/share/metaprogramming/integralConstant.hpp line 53:

> 51: 
> 52: // A bool valued IntegralConstant whose value is false.
> 53: using FalseType = std::false_type;

I think there are no uses of FalseType outside of the implementation of our pre-C++11 metaprogramming tools.  Since I'm proposing we update uses of those and eliminate our synonyms, that will likely render this type unused.

src/hotspot/share/metaprogramming/isArray.hpp line 33:

> 31: 
> 32: template <typename T>
> 33: using IsArray = std::is_array<T>;

There is only one use of IsArray (in zSafeDelete.inline.hpp).  It would be better to update that use and delete this file.

src/hotspot/share/metaprogramming/isConst.hpp line 33:

> 31: 
> 32: template <typename T>
> 33: using IsConst = std::is_const<T>;

There is only one use of IsConst (in oopStorage.inline.hpp).  It would be better to update that use and delete this file.

src/hotspot/share/metaprogramming/isFloatingPoint.hpp line 36:

> 34: 
> 35: template <typename T>
> 36: using IsFloatingPoint = std::is_floating_point<T>;

There are only two uses of IsFloatingPoint (in accessBackend.hpp).  It would be better to update those uses and delete this file.

src/hotspot/share/metaprogramming/isIntegral.hpp line 41:

> 39: 
> 40: // This metafunction returns true iff the type T (irrespective of CV qualifiers)
> 41: // is a signed integral type. Note that this is false for enums.

IsSignedIntegral and IsUnsignedIntegral don't seem to be used anymore.

src/hotspot/share/metaprogramming/isVolatile.hpp line 33:

> 31: 
> 32: template <typename T>
> 33: using IsVolatile = std::is_volatile<T>;

There are only two uses if IsVolatile (in accessBackend.hpp).  It would be better to update those uses and delete this file.

src/hotspot/share/metaprogramming/removeCV.hpp line 31:

> 29: 
> 30: template <typename T>
> 31: using RemoveCV = std::remove_cv<T>;

After some of the changes proposed here there are only a couple of uses of RemoveCV remaining (in atomic.hpp).  It would be better to update those uses and delete this file.

src/hotspot/share/metaprogramming/removeExtent.hpp line 31:

> 29: 
> 30: template <typename T>
> 31: using RemoveExtent = std::remove_extent<T>;

There is only one use of RemoveExtent.  It would be better to update that use and delete this file.

src/hotspot/share/metaprogramming/removePointer.hpp line 35:

> 33: 
> 34: template <typename T>
> 35: using RemovePointer = std::remove_pointer<T>;

RemovePointer is no longer used, and this file can be deleted.

src/hotspot/share/metaprogramming/removeReference.hpp line 35:

> 33: 
> 34: template <typename T>
> 35: using RemoveReference = std::remove_reference<T>;

After the change to define Decay in terms of std::decay, RemoveReference is no longer used and this file can be deleted.

-------------

PR: https://git.openjdk.org/jdk/pull/11794

From jwaters at openjdk.org  Wed Dec 28 10:41:21 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 28 Dec 2022 10:41:21 GMT
Subject: RFR: 8250269: Replace ATTRIBUTE_ALIGNED with alignas [v9]
In-Reply-To: <9QKV9cYFTo_1D8R-mI80lnewNkA0ceJNKFPbrvICxl4=.d6736b76-8324-4084-bede-6e144b4f6c04@github.com>
References: <9QKV9cYFTo_1D8R-mI80lnewNkA0ceJNKFPbrvICxl4=.d6736b76-8324-4084-bede-6e144b4f6c04@github.com>
Message-ID: <5B1XbekC0mW1mMpp2YqV_iIu_T2918Omjw3D86Xv2-g=.c4203915-a728-4438-bd3d-f319c9766de0@github.com>

> C++11 added the alignas attribute, for the purpose of specifying alignment on types, much like compiler specific syntax such as gcc's __attribute__((aligned(x))) or Visual C++'s __declspec(align(x)).
> 
> We can phase out the use of the macro in favor of the standard attribute. In the meantime, we can replace the compiler specific definitions of ATTRIBUTE_ALIGNED with a portable definition. We might deprecate the use of the macro but changing its implementation quickly and cleanly applies the feature where the macro is being used.
> 
> Note: With certain parts of HotSpot using ATTRIBUTE_ALIGNED so indiscriminately, this commit will likely take some time to get right
> 
> This will require adding the alignas attribute to the list of language features approved for use in HotSpot code. (Completed with [8297912](https://github.com/openjdk/jdk/pull/11446))

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 eight additional commits since the last revision:

 - Merge branch 'openjdk:master' into alignas
 - Merge branch 'openjdk:master' into alignas
 - Merge branch 'openjdk:master' into alignas
 - ATTRIBUTE_ALIGNED(16)
 - Merge branch 'openjdk:master' into alignas
 - Merge branch 'openjdk:master' into alignas
 - Merge branch 'openjdk:master' into alignas
 - alignas

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11431/files
  - new: https://git.openjdk.org/jdk/pull/11431/files/7df2abf1..bc90cca4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11431&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11431&range=07-08

  Stats: 76 lines in 3 files changed: 35 ins; 17 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/11431.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11431/head:pull/11431

PR: https://git.openjdk.org/jdk/pull/11431

From jwaters at openjdk.org  Wed Dec 28 10:44:51 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 28 Dec 2022 10:44:51 GMT
Subject: RFR: 8274400: HotSpot Style Guide should permit use of alignof
 [v2]
In-Reply-To: <tAwGBwmmS57x6ck8bIjygwTn5peY6uZu3FciBhFnsps=.cb781a36-90e1-40f0-b524-14cbbb31b533@github.com>
References: <3IdeZGaGcFB1-DbVugn0P9v8vRQMLURzHFRSpAm46NA=.09bf4dd8-b652-49c3-b9a5-ad3f58dfbcc3@github.com>
 <1YZL6wmSuJh2DL2XGhBeSxotq8SxD1_tzJJsXWNScVg=.10ddbf8a-f584-413a-adf8-f3ef6c747aa8@github.com>
 <tAwGBwmmS57x6ck8bIjygwTn5peY6uZu3FciBhFnsps=.cb781a36-90e1-40f0-b524-14cbbb31b533@github.com>
Message-ID: <Mwp-E79Y09NQih0L8QU8vu4sjNnGE3q5dNP6mcVIdPI=.e1400228-1ad3-4b71-83c4-b8bc1ebabf17@github.com>

On Mon, 26 Dec 2022 23:54:00 GMT, Kim Barrett <kbarrett at openjdk.org> 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 three additional commits since the last revision:
>> 
>>  - More Descriptive Version
>>  - Merge remote-tracking branch 'upstream/master' into alignof
>>  - HotSpot Style Guide should permit use of alignof
>
> doc/hotspot-style.md line 708:
> 
>> 706: operator in the development of the language and just returns the corresponding
>> 707: `alignof` value, the operator simply provides less verbose syntax for doing so.
>> 708: Newer code should prefer `alignof` to `std::alignment_of<>` if possible.
> 
> Some of this is extraneous, explaining what `alignof` does, which one can get
> elsewhere.  (We don't need to summarize/duplicate that information here.)
> Something short and simple like this is sufficient:
> 
> Use of `alignof`
> ([n2341](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2341.pdf))
> is permitted.  It should be used instead of `std::alignment_of<>`.
> 
> (We don't need to talk about "Newer code" - I'm pretty sure we have no uses of `std::alignment_of<>`
> in HotSpot.)

Will do, thanks

-------------

PR: https://git.openjdk.org/jdk/pull/11761

From jwaters at openjdk.org  Wed Dec 28 11:02:06 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 28 Dec 2022 11:02:06 GMT
Subject: RFR: 8274400: HotSpot Style Guide should permit use of alignof
 [v3]
In-Reply-To: <3IdeZGaGcFB1-DbVugn0P9v8vRQMLURzHFRSpAm46NA=.09bf4dd8-b652-49c3-b9a5-ad3f58dfbcc3@github.com>
References: <3IdeZGaGcFB1-DbVugn0P9v8vRQMLURzHFRSpAm46NA=.09bf4dd8-b652-49c3-b9a5-ad3f58dfbcc3@github.com>
Message-ID: <hJlJYmqs5vmbej3_eQxT8Uchva8m4chMrSAlQsd7ki0=.4f7f52ec-0e5b-4f2d-ac01-ca3fef0ba7b2@github.com>

> The alignof operator was added by C++11. It returns the alignment for the given type. Various metaprogramming usages exist, in particular when using std::aligned_storage. Use of this operator should be permitted in HotSpot code.

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 commits since the last revision:

 - Make section more brief
 - Merge remote-tracking branch 'upstream/master' into alignof
 - More Descriptive Version
 - Merge remote-tracking branch 'upstream/master' into alignof
 - HotSpot Style Guide should permit use of alignof

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11761/files
  - new: https://git.openjdk.org/jdk/pull/11761/files/5ec061a4..ac2c2c3f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11761&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11761&range=01-02

  Stats: 91 lines in 5 files changed: 35 ins; 23 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/11761.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11761/head:pull/11761

PR: https://git.openjdk.org/jdk/pull/11761

From jcking at openjdk.org  Thu Dec 29 02:57:54 2022
From: jcking at openjdk.org (Justin King)
Date: Thu, 29 Dec 2022 02:57:54 GMT
Subject: RFR: JDK-8299402: Remove metaprogramming/isVolatile.hpp
Message-ID: <583ZyfXsqKBjcSXWsfGhVpMJsyfEpiVZzXKu9_zxaWo=.06aeb6b5-142d-4c1c-b8fa-7400d08c4f54@github.com>

Code cleanup of pre-C++11 <type_traits> implementations.

-------------

Commit messages:
 - Remove related test
 - Remove metaprogramming/isVolatile.hpp

Changes: https://git.openjdk.org/jdk/pull/11801/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11801&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299402
  Stats: 83 lines in 3 files changed: 1 ins; 80 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11801.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11801/head:pull/11801

PR: https://git.openjdk.org/jdk/pull/11801

From jcking at openjdk.org  Thu Dec 29 03:04:37 2022
From: jcking at openjdk.org (Justin King)
Date: Thu, 29 Dec 2022 03:04:37 GMT
Subject: RFR: JDK-8299397: Remove metaprogramming/isFloatingPoint.hpp
Message-ID: <BisRnxBXgzrtdBnJyB_k9YfFVlQ0fHxE5jMX5gAY4Yc=.3c2a878b-451e-491f-a803-847b8cbd6e14@github.com>

Code cleanup of pre-C++11 <type_traits> implementations.

-------------

Commit messages:
 - Remove metaprogramming/isFloatingPoint.hpp

Changes: https://git.openjdk.org/jdk/pull/11802/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11802&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299397
  Stats: 99 lines in 3 files changed: 1 ins; 96 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11802.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11802/head:pull/11802

PR: https://git.openjdk.org/jdk/pull/11802

From jcking at openjdk.org  Thu Dec 29 03:07:49 2022
From: jcking at openjdk.org (Justin King)
Date: Thu, 29 Dec 2022 03:07:49 GMT
Subject: RFR: JDK-8299386: Refactor metaprogramming to use <type_traits>
In-Reply-To: <Nzg0u_WEWkmS7zwbfXY_9IxeavVKEzWG73CR8ehrPQk=.36596edf-3f70-49b4-8734-e0f314345740@github.com>
References: <4IgAzvExdRfJLSpdv2zIG1hMdZHJLKOv62FMP6IyAPg=.bf4322b6-83ed-4cc7-a1e7-81333079afd8@github.com>
 <Nzg0u_WEWkmS7zwbfXY_9IxeavVKEzWG73CR8ehrPQk=.36596edf-3f70-49b4-8734-e0f314345740@github.com>
Message-ID: <5KnDhoiJr_V_xPtrId6Eo7vWzJrj-gQBNVWCd4JWetI=.4bd3c129-9919-4384-981c-fbc5b4ff4076@github.com>

On Wed, 28 Dec 2022 08:02:21 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Cleanup `metaprogramming/` to just use implementations from `<type_traits>` that are available in C++11 and onward.
>
> I started out intending to suggest replacing some of these changes by instead
> updating the uses of a couple that are rarely used, and getting rid of the
> associated pre-C++11 synonyms entirely. But it turns out most are rarely used,
> leading me to question this change almost in its entirety.
> 
> I think better would be a series of changes to replace uses of the synonyms
> with the corresponding element from <type_traits> and delete the synonyms.  I
> say "a series of changes" because I would prefer it not be done all in one
> changeset, for easier reviewing.
> 
> I suggest making an exception for EnableIf, because of the number of uses and
> because I'm hoping we'll be able to revise them in a better way in the not too
> distant future. Many of the uses are for function SFINAE, where the syntax is
> pretty horrible. We have the newer form of function SFINAE available (see
> ENABLE_IF), but I think in many/most cases even better would be to use C++17
> constexpr if. That's why I haven't proposed rewriting any of them using
> ENABLE_IF. I'm hopeful that using C++17 isn't too far away, now that there
> seems to be a compiler available for the aix-ppc port.

@kimbarrett I created 6 separate issues and associated PRs to deal with parts of them in isolation, so far.

JDK-8299399, JDK-8299396, JDK-8299395, JDK-8299398, JDK-8299402, and JDK-8299397.

Once those are in I'll re-visit this and see how we can chop the remaining work and remove most of what remains of `metaprogramming/`, minus `enableIf.hpp`, `logic.hpp`, and `primitiveConversions.hpp`.

@kimbarrett Though once its just those three files, it begs the question of whether having `metaprogramming/` itself is necessary. Maybe it makes more sense to have a single header under `utilities/`?

-------------

PR: https://git.openjdk.org/jdk/pull/11794

From kbarrett at openjdk.org  Thu Dec 29 06:40:48 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 29 Dec 2022 06:40:48 GMT
Subject: RFR: JDK-8299402: Remove metaprogramming/isVolatile.hpp
In-Reply-To: <583ZyfXsqKBjcSXWsfGhVpMJsyfEpiVZzXKu9_zxaWo=.06aeb6b5-142d-4c1c-b8fa-7400d08c4f54@github.com>
References: <583ZyfXsqKBjcSXWsfGhVpMJsyfEpiVZzXKu9_zxaWo=.06aeb6b5-142d-4c1c-b8fa-7400d08c4f54@github.com>
Message-ID: <Xmb3p38mVzoEceAkDBWms8lG0J6fpDcUbgndlTlWXi4=.1a413c0b-ec1e-414f-a878-3f659f433c27@github.com>

On Thu, 29 Dec 2022 02:49:43 GMT, Justin King <jcking at openjdk.org> wrote:

> Code cleanup of pre-C++11 <type_traits> implementations.

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11801

From kbarrett at openjdk.org  Thu Dec 29 06:44:48 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 29 Dec 2022 06:44:48 GMT
Subject: RFR: JDK-8299397: Remove metaprogramming/isFloatingPoint.hpp
In-Reply-To: <BisRnxBXgzrtdBnJyB_k9YfFVlQ0fHxE5jMX5gAY4Yc=.3c2a878b-451e-491f-a803-847b8cbd6e14@github.com>
References: <BisRnxBXgzrtdBnJyB_k9YfFVlQ0fHxE5jMX5gAY4Yc=.3c2a878b-451e-491f-a803-847b8cbd6e14@github.com>
Message-ID: <oHGBmb9tMkiBVXlCfOEMDhqOaL1606jECy6d9o88-QY=.3294697c-50c9-41c5-b5dc-9c94f7ae5d08@github.com>

On Thu, 29 Dec 2022 02:58:18 GMT, Justin King <jcking at openjdk.org> wrote:

> Code cleanup of pre-C++11 <type_traits> implementations.

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11802

From kbarrett at openjdk.org  Thu Dec 29 06:51:47 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 29 Dec 2022 06:51:47 GMT
Subject: RFR: JDK-8299386: Refactor metaprogramming to use <type_traits>
In-Reply-To: <Nzg0u_WEWkmS7zwbfXY_9IxeavVKEzWG73CR8ehrPQk=.36596edf-3f70-49b4-8734-e0f314345740@github.com>
References: <4IgAzvExdRfJLSpdv2zIG1hMdZHJLKOv62FMP6IyAPg=.bf4322b6-83ed-4cc7-a1e7-81333079afd8@github.com>
 <Nzg0u_WEWkmS7zwbfXY_9IxeavVKEzWG73CR8ehrPQk=.36596edf-3f70-49b4-8734-e0f314345740@github.com>
Message-ID: <KghLnWMI7AMGNXYB-gqcLodkgzguqD8OKraHIwDiL9A=.add6aae6-90be-45f2-84b5-74ff24cfd186@github.com>

On Wed, 28 Dec 2022 08:02:21 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Cleanup `metaprogramming/` to just use implementations from `<type_traits>` that are available in C++11 and onward.
>
> I started out intending to suggest replacing some of these changes by instead
> updating the uses of a couple that are rarely used, and getting rid of the
> associated pre-C++11 synonyms entirely. But it turns out most are rarely used,
> leading me to question this change almost in its entirety.
> 
> I think better would be a series of changes to replace uses of the synonyms
> with the corresponding element from <type_traits> and delete the synonyms.  I
> say "a series of changes" because I would prefer it not be done all in one
> changeset, for easier reviewing.
> 
> I suggest making an exception for EnableIf, because of the number of uses and
> because I'm hoping we'll be able to revise them in a better way in the not too
> distant future. Many of the uses are for function SFINAE, where the syntax is
> pretty horrible. We have the newer form of function SFINAE available (see
> ENABLE_IF), but I think in many/most cases even better would be to use C++17
> constexpr if. That's why I haven't proposed rewriting any of them using
> ENABLE_IF. I'm hopeful that using C++17 isn't too far away, now that there
> seems to be a compiler available for the aix-ppc port.

> @kimbarrett Though once its just those three files, it begs the question of whether having `metaprogramming/` itself is necessary. Maybe it makes more sense to have a single header under `utilities/`?

I'm hopeful that we'll soon have C++17, which will similarly remove the need for logical.hpp.  There aren't many uses of those metafunctions either.  So I think there's no point in moving it.

I've already described what I think should be done with EnableIf, so again no point in moving it.

PrimitiveConversions::cast<T> => std::bit_cast<T>, but that's in C++20, so likely still some way out for us.
And the PrimitiveConversions::Translate is our own thing.
So it might make sense to move that someday, but I don't see any need to hurry.

-------------

PR: https://git.openjdk.org/jdk/pull/11794

From kbarrett at openjdk.org  Thu Dec 29 07:24:50 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 29 Dec 2022 07:24:50 GMT
Subject: RFR: JDK-8299386: Refactor metaprogramming to use <type_traits>
In-Reply-To: <KghLnWMI7AMGNXYB-gqcLodkgzguqD8OKraHIwDiL9A=.add6aae6-90be-45f2-84b5-74ff24cfd186@github.com>
References: <4IgAzvExdRfJLSpdv2zIG1hMdZHJLKOv62FMP6IyAPg=.bf4322b6-83ed-4cc7-a1e7-81333079afd8@github.com>
 <Nzg0u_WEWkmS7zwbfXY_9IxeavVKEzWG73CR8ehrPQk=.36596edf-3f70-49b4-8734-e0f314345740@github.com>
 <KghLnWMI7AMGNXYB-gqcLodkgzguqD8OKraHIwDiL9A=.add6aae6-90be-45f2-84b5-74ff24cfd186@github.com>
Message-ID: <l18_54WJIP0y9ptgEQZ8qCtqpdlhw_xAeHSWeGryvzI=.a48ecb71-4479-43f0-9b9c-a967db37f25c@github.com>

On Thu, 29 Dec 2022 06:48:44 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> I started out intending to suggest replacing some of these changes by instead
>> updating the uses of a couple that are rarely used, and getting rid of the
>> associated pre-C++11 synonyms entirely. But it turns out most are rarely used,
>> leading me to question this change almost in its entirety.
>> 
>> I think better would be a series of changes to replace uses of the synonyms
>> with the corresponding element from <type_traits> and delete the synonyms.  I
>> say "a series of changes" because I would prefer it not be done all in one
>> changeset, for easier reviewing.
>> 
>> I suggest making an exception for EnableIf, because of the number of uses and
>> because I'm hoping we'll be able to revise them in a better way in the not too
>> distant future. Many of the uses are for function SFINAE, where the syntax is
>> pretty horrible. We have the newer form of function SFINAE available (see
>> ENABLE_IF), but I think in many/most cases even better would be to use C++17
>> constexpr if. That's why I haven't proposed rewriting any of them using
>> ENABLE_IF. I'm hopeful that using C++17 isn't too far away, now that there
>> seems to be a compiler available for the aix-ppc port.
>
>> @kimbarrett Though once its just those three files, it begs the question of whether having `metaprogramming/` itself is necessary. Maybe it makes more sense to have a single header under `utilities/`?
> 
> I'm hopeful that we'll soon have C++17, which will similarly remove the need for logical.hpp.  There aren't many uses of those metafunctions either.  So I think there's no point in moving it.
> 
> I've already described what I think should be done with EnableIf, so again no point in moving it.
> 
> PrimitiveConversions::cast<T> => std::bit_cast<T>, but that's in C++20, so likely still some way out for us.
> And the PrimitiveConversions::Translate is our own thing.
> So it might make sense to move that someday, but I don't see any need to hurry.

> @kimbarrett I created 6 separate issues and associated PRs to deal with parts of them in isolation, so far.
> 
> JDK-8299399, JDK-8299396, JDK-8299395, JDK-8299398, JDK-8299402, and JDK-8299397.
> 
> Once those are in I'll re-visit this and see how we can chop the remaining work and remove most of what remains of `metaprogramming/`, minus `enableIf.hpp`, `logic.hpp`, and `primitiveConversions.hpp`.

Thanks.  Those PRs were very easy to review.

-------------

PR: https://git.openjdk.org/jdk/pull/11794

From jnimeh at openjdk.org  Thu Dec 29 15:47:37 2022
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Thu, 29 Dec 2022 15:47:37 GMT
Subject: [jdk20] RFR: 8298592: Add java man page documentation for ChaCha20
 and Poly1305 intrinsics [v2]
In-Reply-To: <OC1amLXm3taRXvqssBwzYLzS_MEy_fCqccBkPOo9Vxo=.e9581221-3bae-49e5-bcb9-43ad70f659ac@github.com>
References: <OC1amLXm3taRXvqssBwzYLzS_MEy_fCqccBkPOo9Vxo=.e9581221-3bae-49e5-bcb9-43ad70f659ac@github.com>
Message-ID: <EkTKgvQk5kG_qhq5qPvyGYyxOF-yXqoy5LSeRaUJi2o=.5098a110-4b51-4adf-b7c5-19eb698fb36f@github.com>

> This adds documentation to the `java(1)` man page for new ChaCha20 and Poly1305 intrinsics, highlighting the diagnostic flags that were delivered in those feature enhancements.  This is similar to what has already been done for AES and GHASH diagnostic flags.
> 
> - JBS: https://bugs.openjdk.org/browse/JDK-8298592
> - Flags were delivered in ( openjdk/jdk#7702 for ChaCha20 and openjdk/jdk#10582 for Poly1305, with a minor change to the Poly1305 flag name in #49 )

Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision:

  Add highlighting for intrinsic diag switch title

-------------

Changes:
  - all: https://git.openjdk.org/jdk20/pull/78/files
  - new: https://git.openjdk.org/jdk20/pull/78/files/83b7df59..4b0c4cd6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=78&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=78&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk20/pull/78.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/78/head:pull/78

PR: https://git.openjdk.org/jdk20/pull/78

From weijun at openjdk.org  Thu Dec 29 20:47:02 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 29 Dec 2022 20:47:02 GMT
Subject: [jdk20] RFR: 8298592: Add java man page documentation for ChaCha20
 and Poly1305 intrinsics [v2]
In-Reply-To: <EkTKgvQk5kG_qhq5qPvyGYyxOF-yXqoy5LSeRaUJi2o=.5098a110-4b51-4adf-b7c5-19eb698fb36f@github.com>
References: <OC1amLXm3taRXvqssBwzYLzS_MEy_fCqccBkPOo9Vxo=.e9581221-3bae-49e5-bcb9-43ad70f659ac@github.com>
 <EkTKgvQk5kG_qhq5qPvyGYyxOF-yXqoy5LSeRaUJi2o=.5098a110-4b51-4adf-b7c5-19eb698fb36f@github.com>
Message-ID: <kxCRYX5UznDM65ljKq9Mzk1mj9WofTfkd6e2SnUAIFQ=.50f58bf4-6739-4e61-b324-cefcece1b2e3@github.com>

On Thu, 29 Dec 2022 15:47:37 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> This adds documentation to the `java(1)` man page for new ChaCha20 and Poly1305 intrinsics, highlighting the diagnostic flags that were delivered in those feature enhancements.  This is similar to what has already been done for AES and GHASH diagnostic flags.
>> 
>> - JBS: https://bugs.openjdk.org/browse/JDK-8298592
>> - Flags were delivered in ( openjdk/jdk#7702 for ChaCha20 and openjdk/jdk#10582 for Poly1305, with a minor change to the Poly1305 flag name in #49 )
>
> Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add highlighting for intrinsic diag switch title

Marked as reviewed by weijun (Reviewer).

-------------

PR: https://git.openjdk.org/jdk20/pull/78

From jnimeh at openjdk.org  Thu Dec 29 22:38:01 2022
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Thu, 29 Dec 2022 22:38:01 GMT
Subject: [jdk20] Integrated: 8298592: Add java man page documentation for
 ChaCha20 and Poly1305 intrinsics
In-Reply-To: <OC1amLXm3taRXvqssBwzYLzS_MEy_fCqccBkPOo9Vxo=.e9581221-3bae-49e5-bcb9-43ad70f659ac@github.com>
References: <OC1amLXm3taRXvqssBwzYLzS_MEy_fCqccBkPOo9Vxo=.e9581221-3bae-49e5-bcb9-43ad70f659ac@github.com>
Message-ID: <7u_1vMLUmsiYoCiAvJC1D6ayHzfLN-vsyXIgU5bhJrU=.c5a803a9-ad97-4616-8c16-801121d4e732@github.com>

On Wed, 28 Dec 2022 15:54:49 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

> This adds documentation to the `java(1)` man page for new ChaCha20 and Poly1305 intrinsics, highlighting the diagnostic flags that were delivered in those feature enhancements.  This is similar to what has already been done for AES and GHASH diagnostic flags.
> 
> - JBS: https://bugs.openjdk.org/browse/JDK-8298592
> - Flags were delivered in ( openjdk/jdk#7702 for ChaCha20 and openjdk/jdk#10582 for Poly1305, with a minor change to the Poly1305 flag name in #49 )

This pull request has now been integrated.

Changeset: 37f8b059
Author:    Jamil Nimeh <jnimeh at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/37f8b059c1c9245e7f3af90d6ed47c862fee54a3
Stats:     16 lines in 1 file changed: 16 ins; 0 del; 0 mod

8298592: Add java man page documentation for ChaCha20 and Poly1305 intrinsics

Reviewed-by: weijun

-------------

PR: https://git.openjdk.org/jdk20/pull/78

From kbarrett at openjdk.org  Fri Dec 30 02:11:50 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 30 Dec 2022 02:11:50 GMT
Subject: RFR: 8274400: HotSpot Style Guide should permit use of alignof
 [v3]
In-Reply-To: <hJlJYmqs5vmbej3_eQxT8Uchva8m4chMrSAlQsd7ki0=.4f7f52ec-0e5b-4f2d-ac01-ca3fef0ba7b2@github.com>
References: <3IdeZGaGcFB1-DbVugn0P9v8vRQMLURzHFRSpAm46NA=.09bf4dd8-b652-49c3-b9a5-ad3f58dfbcc3@github.com>
 <hJlJYmqs5vmbej3_eQxT8Uchva8m4chMrSAlQsd7ki0=.4f7f52ec-0e5b-4f2d-ac01-ca3fef0ba7b2@github.com>
Message-ID: <1VvY0OUOTV6QoOICCC7D-bossOFuNcElgxJwOK0ATcg=.4d805893-07a4-4c0c-b9c0-82a2ee3be0cf@github.com>

On Wed, 28 Dec 2022 11:02:06 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> The alignof operator was added by C++11. It returns the alignment for the given type. Various metaprogramming usages exist, in particular when using std::aligned_storage. Use of this operator should be permitted in HotSpot code.
>
> 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 commits since the last revision:
> 
>  - Make section more brief
>  - Merge remote-tracking branch 'upstream/master' into alignof
>  - More Descriptive Version
>  - Merge remote-tracking branch 'upstream/master' into alignof
>  - HotSpot Style Guide should permit use of alignof

> What is the use-case for permitting use of `alignof`? Usually we don't add such permits without some use-case in mind.
> [...] 
> I'm not opposed to permitting the use of `alignof`, but wondering why we might need it.

Responding to myself, I've found a usage category where `alignof` would be appropriate.  We have various
places where we are aligning a pointer to the size of some type, where it would be more appropriate to align to the
alignment of that type.  See, for example, `Message::calc_size()` (logging/logAsyncWriter.hpp), which uses
`sizeof(void*)` where it seems like it should be using `alignof(Message)`.

-------------

PR: https://git.openjdk.org/jdk/pull/11761

From kbarrett at openjdk.org  Fri Dec 30 02:36:51 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 30 Dec 2022 02:36:51 GMT
Subject: RFR: 8274400: HotSpot Style Guide should permit use of alignof
 [v3]
In-Reply-To: <hJlJYmqs5vmbej3_eQxT8Uchva8m4chMrSAlQsd7ki0=.4f7f52ec-0e5b-4f2d-ac01-ca3fef0ba7b2@github.com>
References: <3IdeZGaGcFB1-DbVugn0P9v8vRQMLURzHFRSpAm46NA=.09bf4dd8-b652-49c3-b9a5-ad3f58dfbcc3@github.com>
 <hJlJYmqs5vmbej3_eQxT8Uchva8m4chMrSAlQsd7ki0=.4f7f52ec-0e5b-4f2d-ac01-ca3fef0ba7b2@github.com>
Message-ID: <vomnJeFvECyE1oYi4JQb99L3yStcx-CEFdE8hIkP5QE=.9ca8c9ba-2c24-4686-a5c2-c1a5c92120e0@github.com>

On Wed, 28 Dec 2022 11:02:06 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> The alignof operator was added by C++11. It returns the alignment for the given type. Various metaprogramming usages exist, in particular when using std::aligned_storage. Use of this operator should be permitted in HotSpot code.
>
> 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 commits since the last revision:
> 
>  - Make section more brief
>  - Merge remote-tracking branch 'upstream/master' into alignof
>  - More Descriptive Version
>  - Merge remote-tracking branch 'upstream/master' into alignof
>  - HotSpot Style Guide should permit use of alignof

Changes requested by kbarrett (Reviewer).

doc/hotspot-style.md line 706:

> 704: alternative to `std::alignment_of<>`. The template precedes the operator
> 705: in the language, so `alignof` should be preferred to `std::alignment_of<>`
> 706: if possible.

`alignof` doesn't "check" anything. And this is still overly verbose. Keep it
simple. I was going to suggest using this:
"`alignof`(ref...) is permitted.  Use `alignof` instead of `std::alignment_of<>`."

But I think better is to add `alignof` to the "### Additional Permitted
Features" list, and change the place where inclusion of `<type_traits>` is
discussed, adding a restriction against using `std::alignment_of<>`. There one
can justify the restriction by noting the trait class preceded the operator
and provides the same functionality. We're probably going to want additional
restrictions for `<type_traits>` because of
https://bugs.openjdk.org/browse/JDK-8298399.

So edit that section like so:

* `#include <type_traits>` with restrictions (see below).
...

Some definitions from `<type_traits>` should not be used.
* `std::alignment_of<>` has been superseded by `alignof`, which should be used instead.

-------------

PR: https://git.openjdk.org/jdk/pull/11761

From jwaters at openjdk.org  Fri Dec 30 13:52:50 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 30 Dec 2022 13:52:50 GMT
Subject: RFR: 8274400: HotSpot Style Guide should permit use of alignof
 [v3]
In-Reply-To: <vomnJeFvECyE1oYi4JQb99L3yStcx-CEFdE8hIkP5QE=.9ca8c9ba-2c24-4686-a5c2-c1a5c92120e0@github.com>
References: <3IdeZGaGcFB1-DbVugn0P9v8vRQMLURzHFRSpAm46NA=.09bf4dd8-b652-49c3-b9a5-ad3f58dfbcc3@github.com>
 <hJlJYmqs5vmbej3_eQxT8Uchva8m4chMrSAlQsd7ki0=.4f7f52ec-0e5b-4f2d-ac01-ca3fef0ba7b2@github.com>
 <vomnJeFvECyE1oYi4JQb99L3yStcx-CEFdE8hIkP5QE=.9ca8c9ba-2c24-4686-a5c2-c1a5c92120e0@github.com>
Message-ID: <k_wkFGxxE3gGh-CgAI_5i0XEyfgYBsHs5AUvugI9caY=.b08d3d3e-e2e4-437a-afef-5388dcd5108f@github.com>

On Fri, 30 Dec 2022 02:33:31 GMT, Kim Barrett <kbarrett at openjdk.org> 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 commits since the last revision:
>> 
>>  - Make section more brief
>>  - Merge remote-tracking branch 'upstream/master' into alignof
>>  - More Descriptive Version
>>  - Merge remote-tracking branch 'upstream/master' into alignof
>>  - HotSpot Style Guide should permit use of alignof
>
> doc/hotspot-style.md line 706:
> 
>> 704: alternative to `std::alignment_of<>`. The template precedes the operator
>> 705: in the language, so `alignof` should be preferred to `std::alignment_of<>`
>> 706: if possible.
> 
> `alignof` doesn't "check" anything. And this is still overly verbose. Keep it
> simple. I was going to suggest using this:
> "`alignof`(ref...) is permitted.  Use `alignof` instead of `std::alignment_of<>`."
> 
> But I think better is to add `alignof` to the "### Additional Permitted
> Features" list, and change the place where inclusion of `<type_traits>` is
> discussed, adding a restriction against using `std::alignment_of<>`. There one
> can justify the restriction by noting the trait class preceded the operator
> and provides the same functionality. We're probably going to want additional
> restrictions for `<type_traits>` because of
> https://bugs.openjdk.org/browse/JDK-8298399.
> 
> So edit that section like so:
> 
> * `#include <type_traits>` with restrictions (see below).
> ...
> 
> Some definitions from `<type_traits>` should not be used.
> * `std::alignment_of<>` has been superseded by `alignof`, which should be used instead.

Will do, thanks

-------------

PR: https://git.openjdk.org/jdk/pull/11761

From jwaters at openjdk.org  Fri Dec 30 13:59:13 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 30 Dec 2022 13:59:13 GMT
Subject: RFR: 8274400: HotSpot Style Guide should permit use of alignof
 [v4]
In-Reply-To: <3IdeZGaGcFB1-DbVugn0P9v8vRQMLURzHFRSpAm46NA=.09bf4dd8-b652-49c3-b9a5-ad3f58dfbcc3@github.com>
References: <3IdeZGaGcFB1-DbVugn0P9v8vRQMLURzHFRSpAm46NA=.09bf4dd8-b652-49c3-b9a5-ad3f58dfbcc3@github.com>
Message-ID: <FzrfugP54f_eydBjRNLTjrkMU5R0uBDhadQ4NHs_Hqc=.d33341e7-bc8b-4733-b006-9cab1f94874a@github.com>

> The alignof operator was added by C++11. It returns the alignment for the given type. Various metaprogramming usages exist, in particular when using std::aligned_storage. Use of this operator should be permitted in HotSpot code.

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 seven additional commits since the last revision:

 - <type_traits>
 - Merge remote-tracking branch 'upstream/master' into alignof
 - Make section more brief
 - Merge remote-tracking branch 'upstream/master' into alignof
 - More Descriptive Version
 - Merge remote-tracking branch 'upstream/master' into alignof
 - HotSpot Style Guide should permit use of alignof

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11761/files
  - new: https://git.openjdk.org/jdk/pull/11761/files/ac2c2c3f..cc5c61a4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11761&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11761&range=02-03

  Stats: 50 lines in 6 files changed: 18 ins; 26 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/11761.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11761/head:pull/11761

PR: https://git.openjdk.org/jdk/pull/11761

From jwaters at openjdk.org  Fri Dec 30 16:48:27 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 30 Dec 2022 16:48:27 GMT
Subject: RFR: 8250269: Replace ATTRIBUTE_ALIGNED with alignas [v10]
In-Reply-To: <9QKV9cYFTo_1D8R-mI80lnewNkA0ceJNKFPbrvICxl4=.d6736b76-8324-4084-bede-6e144b4f6c04@github.com>
References: <9QKV9cYFTo_1D8R-mI80lnewNkA0ceJNKFPbrvICxl4=.d6736b76-8324-4084-bede-6e144b4f6c04@github.com>
Message-ID: <r0PWvnZJfjHpufPUDgs4DKSQy7mEsCIxKVBwyiwuC0E=.9bcf22a8-032d-4247-b7d0-bab0d4c67ad8@github.com>

> C++11 added the alignas attribute, for the purpose of specifying alignment on types, much like compiler specific syntax such as gcc's __attribute__((aligned(x))) or Visual C++'s __declspec(align(x)).
> 
> We can phase out the use of the macro in favor of the standard attribute. In the meantime, we can replace the compiler specific definitions of ATTRIBUTE_ALIGNED with a portable definition. We might deprecate the use of the macro but changing its implementation quickly and cleanly applies the feature where the macro is being used.
> 
> Note: With certain parts of HotSpot using ATTRIBUTE_ALIGNED so indiscriminately, this commit will likely take some time to get right
> 
> This will require adding the alignas attribute to the list of language features approved for use in HotSpot code. (Completed with [8297912](https://github.com/openjdk/jdk/pull/11446))

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 ten additional commits since the last revision:

 - Merge branch 'openjdk:master' into alignas
 - Merge branch 'openjdk:master' into alignas
 - Merge branch 'openjdk:master' into alignas
 - Merge branch 'openjdk:master' into alignas
 - ATTRIBUTE_ALIGNED(16)
 - Merge branch 'openjdk:master' into alignas
 - Merge branch 'openjdk:master' into alignas
 - Merge branch 'openjdk:master' into alignas
 - alignas

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11431/files
  - new: https://git.openjdk.org/jdk/pull/11431/files/bc90cca4..d32d7b67

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11431&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11431&range=08-09

  Stats: 12 lines in 4 files changed: 0 ins; 8 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/11431.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11431/head:pull/11431

PR: https://git.openjdk.org/jdk/pull/11431

From kbarrett at openjdk.org  Sat Dec 31 04:22:52 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 31 Dec 2022 04:22:52 GMT
Subject: RFR: 8274400: HotSpot Style Guide should permit use of alignof
 [v4]
In-Reply-To: <FzrfugP54f_eydBjRNLTjrkMU5R0uBDhadQ4NHs_Hqc=.d33341e7-bc8b-4733-b006-9cab1f94874a@github.com>
References: <3IdeZGaGcFB1-DbVugn0P9v8vRQMLURzHFRSpAm46NA=.09bf4dd8-b652-49c3-b9a5-ad3f58dfbcc3@github.com>
 <FzrfugP54f_eydBjRNLTjrkMU5R0uBDhadQ4NHs_Hqc=.d33341e7-bc8b-4733-b006-9cab1f94874a@github.com>
Message-ID: <KCpDELJ-kHmFyYVXsw53zq5wKEKYopsl2t0Via2PJaI=.f1176a5d-c9f4-455e-8007-16c3eefe22a1@github.com>

On Fri, 30 Dec 2022 13:59:13 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> The alignof operator was added by C++11. It returns the alignment for the given type. Various metaprogramming usages exist, in particular when using std::aligned_storage. Use of this operator should be permitted in HotSpot code.
>
> 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 seven additional commits since the last revision:
> 
>  - <type_traits>
>  - Merge remote-tracking branch 'upstream/master' into alignof
>  - Make section more brief
>  - Merge remote-tracking branch 'upstream/master' into alignof
>  - More Descriptive Version
>  - Merge remote-tracking branch 'upstream/master' into alignof
>  - HotSpot Style Guide should permit use of alignof

Changes requested by kbarrett (Reviewer).

doc/hotspot-style.md line 575:

> 573: * `#include <new>` to use placement `new`, `std::nothrow`, and `std::nothrow_t`.
> 574: * `#include <limits>` to use `std::numeric_limits`.
> 575: * `#include <type_traits>` with some considerations, listed below.

s/considerations/restrictions/

doc/hotspot-style.md line 578:

> 576: * `#include <cstddef>` to use `std::nullptr_t` and `std::max_align_t`.
> 577: 
> 578: Certain declarations from `<type_traits>` should be avoided.

s/should be avoided/are forbidden/

doc/hotspot-style.md line 581:

> 579: 
> 580: * `std::alignment_of<>` has been superseded by `alignof`, and the newer
> 581: operator should be preferred over it instead, whenever possible.

No need for weasel words like "whenever possible".  Simply

* `std::alignment_of<>`. It has been superseded by `alignof` expressions.

-------------

PR: https://git.openjdk.org/jdk/pull/11761

From jwaters at openjdk.org  Sat Dec 31 17:17:51 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 31 Dec 2022 17:17:51 GMT
Subject: RFR: 8274400: HotSpot Style Guide should permit use of alignof
 [v4]
In-Reply-To: <KCpDELJ-kHmFyYVXsw53zq5wKEKYopsl2t0Via2PJaI=.f1176a5d-c9f4-455e-8007-16c3eefe22a1@github.com>
References: <3IdeZGaGcFB1-DbVugn0P9v8vRQMLURzHFRSpAm46NA=.09bf4dd8-b652-49c3-b9a5-ad3f58dfbcc3@github.com>
 <FzrfugP54f_eydBjRNLTjrkMU5R0uBDhadQ4NHs_Hqc=.d33341e7-bc8b-4733-b006-9cab1f94874a@github.com>
 <KCpDELJ-kHmFyYVXsw53zq5wKEKYopsl2t0Via2PJaI=.f1176a5d-c9f4-455e-8007-16c3eefe22a1@github.com>
Message-ID: <dBCCrlcRJrZpHp7M0bLLyo3gPyx6x8p4tlzH4raL6i4=.4a033c45-e547-4883-9544-bdde953ae929@github.com>

On Sat, 31 Dec 2022 04:18:44 GMT, Kim Barrett <kbarrett at openjdk.org> 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 seven additional commits since the last revision:
>> 
>>  - <type_traits>
>>  - Merge remote-tracking branch 'upstream/master' into alignof
>>  - Make section more brief
>>  - Merge remote-tracking branch 'upstream/master' into alignof
>>  - More Descriptive Version
>>  - Merge remote-tracking branch 'upstream/master' into alignof
>>  - HotSpot Style Guide should permit use of alignof
>
> doc/hotspot-style.md line 581:
> 
>> 579: 
>> 580: * `std::alignment_of<>` has been superseded by `alignof`, and the newer
>> 581: operator should be preferred over it instead, whenever possible.
> 
> No need for weasel words like "whenever possible".  Simply
> 
> * `std::alignment_of<>`. It has been superseded by `alignof` expressions.

I'm not sure if it's a good idea to entirely forbid `std::alignment_of<>`? While `alignof` should be used over it most of the time, I'm somewhat certain it and it's other counterpart from C++17 (may) have certain differences from `alignof` in newer versions of the language (especially when used with templates and in metaprogramming contexts), which is why I chose to avoid having to take those issues into account for now by simply saying the latter should always be preferred over the former (Similar to how nullptr vs NULL is discussed in the Style Guide). Maybe I could word it better though

-------------

PR: https://git.openjdk.org/jdk/pull/11761

From jwaters at openjdk.org  Sat Dec 31 17:21:49 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 31 Dec 2022 17:21:49 GMT
Subject: RFR: 8274400: HotSpot Style Guide should permit use of alignof
 [v4]
In-Reply-To: <dBCCrlcRJrZpHp7M0bLLyo3gPyx6x8p4tlzH4raL6i4=.4a033c45-e547-4883-9544-bdde953ae929@github.com>
References: <3IdeZGaGcFB1-DbVugn0P9v8vRQMLURzHFRSpAm46NA=.09bf4dd8-b652-49c3-b9a5-ad3f58dfbcc3@github.com>
 <FzrfugP54f_eydBjRNLTjrkMU5R0uBDhadQ4NHs_Hqc=.d33341e7-bc8b-4733-b006-9cab1f94874a@github.com>
 <KCpDELJ-kHmFyYVXsw53zq5wKEKYopsl2t0Via2PJaI=.f1176a5d-c9f4-455e-8007-16c3eefe22a1@github.com>
 <dBCCrlcRJrZpHp7M0bLLyo3gPyx6x8p4tlzH4raL6i4=.4a033c45-e547-4883-9544-bdde953ae929@github.com>
Message-ID: <yUV76aczlCynqhRJHnA0C4Axg8y0bDCJByzOeTbcIbA=.2df88dd9-40f2-4a2b-be0e-37db6eecf0eb@github.com>

On Sat, 31 Dec 2022 17:14:47 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> doc/hotspot-style.md line 581:
>> 
>>> 579: 
>>> 580: * `std::alignment_of<>` has been superseded by `alignof`, and the newer
>>> 581: operator should be preferred over it instead, whenever possible.
>> 
>> No need for weasel words like "whenever possible".  Simply
>> 
>> * `std::alignment_of<>`. It has been superseded by `alignof` expressions.
>
> I'm not sure if it's a good idea to entirely forbid `std::alignment_of<>`? While `alignof` should be used over it most of the time, I'm somewhat certain it and it's other counterpart from C++17 (may) have certain differences from `alignof` in newer versions of the language (especially when used with templates and in metaprogramming contexts), which is why I chose to avoid having to take those issues into account for now by simply saying the latter should always be preferred over the former (Similar to how nullptr vs NULL is discussed in the Style Guide). Maybe I could word it better though

Something like this perhaps?

- Prefer `alignof` ([n2341](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2341.pdf)) to `std::alignment_of<>`. The template has been superseded by the newer operator.

-------------

PR: https://git.openjdk.org/jdk/pull/11761