From iklam at openjdk.org  Wed Mar  1 00:58:04 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 1 Mar 2023 00:58:04 GMT
Subject: RFR: JDK-8302989: Add missing INCLUDE_CDS checks
In-Reply-To: <Ssc0qZgYTMHWJ9lEqXze9L-pe2dPQR_kOtRKbcyuXho=.3747f96c-f646-4fd1-8002-78b5e93167e5@github.com>
References: <kBV8fNo_CWJL2MoXgAckFhuAFgQ3RGZjFKAKnl8xfV8=.233bb652-8508-4065-92ea-7873b1c765f3@github.com>
 <yF5oOztl0mY9ISoVpZh56Xap9j8_lO1pvajpFjHxS6A=.10d23e5d-4373-4a69-b35f-3837fa716768@github.com>
 <Ssc0qZgYTMHWJ9lEqXze9L-pe2dPQR_kOtRKbcyuXho=.3747f96c-f646-4fd1-8002-78b5e93167e5@github.com>
Message-ID: <eyAgX3zxb6hjyPSO7zKu2EzxLXjL0tvh04F9eWZJDnw=.dfade686-1403-41cf-940e-0aa3401b7f83@github.com>

On Tue, 28 Feb 2023 13:02:22 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > It may be more profitable (and less work) if we change these variables to `const` when CDS is disabled:
> > ```
> > extern bool DumpSharedSpaces;
> > extern bool DynamicDumpSharedSpaces;
> > extern bool RequireSharedSpaces;
> > extern "C" {
> > // Make sure UseSharedSpaces is accessible to the serviceability agent.
> > extern JNIEXPORT jboolean UseSharedSpaces;
> > }
> > ```
> >   
> > But some changes may be needed in SA.
> 
> Hi Ioi, do you think this should be done for all 4 bools ? Btw. when adding a const to UseSharedSpaces I run into something like this (when compiling with gcc, seems there is some issue when const is used together with JNIEXPORT , any ideas why ? ` globalDefinitions.cpp:50:26: error: 'visibility' attribute ignored [-Werror=attributes]`

I think it should be done for all four bools.

UseSharedSpaces is accessed by SA in src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java. I would suggest adding this:


  public boolean isSharingEnabled() {
    if (sharingEnabled == null) {
<<<<<
      Boolean sharingConfigured = getSharingConfigured(); // with similar "lookup" logic as below ...
      if (!sharingConfigured.booleanValue()) {
        sharingEnabled = sharingConfigured; // INCLUDE_CDS is disabled
        return false;
      }
>>>>>
       Address address = VM.getVM().getDebugger().lookup(null, "UseSharedSpaces");
        if (address == null && getOS().equals("win32")) {
            // On Win32 symbols are prefixed with the dll name. So look for
            // UseSharedSpaces as a symbol in jvm.dll.
            address = VM.getVM().getDebugger().lookup(null, "jvm!UseSharedSpaces");
        }
        sharingEnabled = address.getJBooleanAt(0);
    }
    return sharingEnabled.booleanValue();
  }


Then we can change globalDefinitions.cpp to something like:


#if INCLUDE_CDS
// Old CDS options
bool DumpSharedSpaces;
bool DynamicDumpSharedSpaces;
bool RequireSharedSpaces;
extern "C" {
JNIEXPORT jboolean UseSharedSpaces = true; // for SA
JNIEXPORT jboolean SharingConfigured= true; // for SA
}
#else
extern "C" {
JNIEXPORT jboolean SharingConfigured= false; // for SA
}
#endif


You may need to test with a build that has SA enabled but CDS disabled. I am not sure if this is a supported combination.

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

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

From kbarrett at openjdk.org  Wed Mar  1 02:49:39 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 1 Mar 2023 02:49:39 GMT
Subject: RFR: 8302798: Refactor -XX:+UseOSErrorReporting for noreturn crash
 reporting [v2]
In-Reply-To: <elVA1mzItfJ7bnnfSpEUVprtbnnSx1zT_eoXnV2sviU=.13e2d4dc-74b0-4051-8852-04caf2c81196@github.com>
References: <elVA1mzItfJ7bnnfSpEUVprtbnnSx1zT_eoXnV2sviU=.13e2d4dc-74b0-4051-8852-04caf2c81196@github.com>
Message-ID: <cdY_mFh0aGAeccyNM-4OgCDqMRqglZeXka6gE06fYPM=.e036581e-b1c0-4b4a-9fb2-08f61718f726@github.com>

> Please review this change to the implementation of the Windows-specific option
> UseOSErrorReporting, toward allowing crash reporting functions to be declared
> noreturn.  VMError::report_and_die no longer conditionally returns if the
> Windows-only option UseOSErrorReporting is true.
> 
> The Windows-only sections of report_and_die now call RaiseFailFastException
> (https://learn.microsoft.com/en-us/windows/win32/api/errhandlingapi/nf-errhandlingapi-raisefailfastexception),
> which immediately invokes WER (Windows Error Reporting) if it is enabled,
> without executing structured exception handler.  If WER is not enabled, it
> just immediately terminates the program.  Thus, we no longer return to walk up
> thestructured exception handler chain to pop out at the top as unhandled in
> order to invoke WER.
> 
> This permits declaring report_and_die as [[noreturn]], once some functions
> from the os class are also so declared.  Also adding that attribute as
> appropriate to other functions in the os class.  This of course assumes
> the use of [[noreturn]] in HotSpot code is approved (JDK-8302124).
> 
> There is a pre-existing bug that I'll be reporting separately.  If
> UseOSErrorReporting and CreateCoredumpOnCrash are both true, we create an
> empty .mdmp file.  We shouldn't create that file when UseOSErrorReporting.
> 
> Testing:
> mach5 tier1-3
> 
> Manual testing with the following, to verify desired behavior.
> 
> -XX:ErrorHandlerTest=N
> 1: assertion failure
> 2: guarantee failure
> 14: SIGSEGV
> 15: divide by zero
> path/to/bin/java \
>   -XX:+UnlockDiagnosticVMOptions \
>   -XX:+ErrorLogSecondaryErrorDetails \
>   -XX:+UseOSErrorReporting \
>   -XX:ErrorHandlerTest=1 \
>   TestDebug.java
> 
> --- TestDebug.java ---
> import java.lang.String;
> public class TestDebug {
>     static private volatile String dummy;
>     public static void main(String[] args) throws Exception {
>         while (true) {
>             dummy = new String("foo bar");
>         }
>     }
> }
> --- end TestDebug.java ---
> 
> The state of WER can be examined and modified using Power Shell commands
> {Get,Enable,Disable}-WindowsErrorReporting.
> 
> The state of reporting WER captured errors can be examined and modified using
> Control Panel > Security and Maintenance > Maintenance : Report Problems [on,off]
> 
> With Report Problems off, reports are placed in
> c:\ProgramData\Microsoft\Windows\WER\ReportArchive
> 
> I verified that executing the above test with WER enabled adds an entry in
> that directory, but not when it's disabled.  Also nothing is added there when
> the test is run with -XX:-UseOSErrorReporting.

Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:

  remove failfast cuttoff of secondary errors

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12759/files
  - new: https://git.openjdk.org/jdk/pull/12759/files/2e39a1b8..e3717037

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

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

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

From duke at openjdk.org  Wed Mar  1 04:11:05 2023
From: duke at openjdk.org (Amit Kumar)
Date: Wed, 1 Mar 2023 04:11:05 GMT
Subject: RFR: 8303210: [linux, Windows] Enable UseSystemMemoryBarrier by
 default if possible [v3]
In-Reply-To: <osex7Bks3vqpGMHMyXfMH03l-KeyW6yR6Sq8CpKN09s=.d7f78abe-1c29-4bd4-89c3-d9bd777ab47e@github.com>
References: <9eZo1xYNGhjMSC9lDXKtkO1eyU_H-Veuh1AeP3CPKbg=.69b6c4ff-a3ef-439f-8468-21fec9de1825@github.com>
 <osex7Bks3vqpGMHMyXfMH03l-KeyW6yR6Sq8CpKN09s=.d7f78abe-1c29-4bd4-89c3-d9bd777ab47e@github.com>
Message-ID: <97IuCUIDtTNr5sodrGE3PcPUugt3UT2eZPqvCmqNhWo=.26c6c856-d3a3-4541-8b7e-7b2654e16ec6@github.com>

On Tue, 28 Feb 2023 05:26:22 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> I'd like to enable UseSystemMemoryBarrier by default on supported Operating Systems in order to improve performance of thread state transitions (I/O, JNI, foreign function calls, JIT compiler threads, etc.). See JBS issue for more details.
>> Unfortunately, the feature was not yet implemented on all platforms. I added the code, but need the platform maintainers to check if it can be used reliably (and ideally if the performance improves). It's easy to switch it off again in case of problems.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve logging.

Build and tier1 test are okay with this patch, except one new failure (it could be just a random failure, unrelated to this patch)
compiler/jsr292/ContinuousCallSiteTargetChange.java 

But @TheRealMDoerr I'm not sure about how to perform regression, will catch up with Tyler for it and post the result.

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

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

From kbarrett at openjdk.org  Wed Mar  1 04:46:53 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 1 Mar 2023 04:46:53 GMT
Subject: RFR: 8303418: Improve parameter and variable names in BitMap
Message-ID: <LkA8PloAB0eQanDBr7eWx9_5EG5-6WByhZk19NxVcEw=.34afb33b-5e55-44a9-93bd-d701b62679c6@github.com>

Please review this change to names in BitMap.

- Parameters that designate a bit in a BitMap are named "bit".
- Parameters that designate a word in the underlying BitMap storage are named "word".
- Parameters that designate a range are named "beg" and "end" resp.

Added helper function `flipped_word` for use by `get_next_bit_impl`, replacing
the odd overload for `map`.

In `get_next_bit_impl`, prefixed the variables "index" and "limit" with
"word_" to make clear the units.

Testing:
mach5 tier1

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

Commit messages:
 - improve names in get_next_bit_impl
 - cleanup parameter names

Changes: https://git.openjdk.org/jdk/pull/12798/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12798&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303418
  Stats: 53 lines in 3 files changed: 5 ins; 1 del; 47 mod
  Patch: https://git.openjdk.org/jdk/pull/12798.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12798/head:pull/12798

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

From mdoerr at openjdk.org  Wed Mar  1 05:20:05 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 1 Mar 2023 05:20:05 GMT
Subject: RFR: 8303210: [linux, Windows] Enable UseSystemMemoryBarrier by
 default if possible [v3]
In-Reply-To: <97IuCUIDtTNr5sodrGE3PcPUugt3UT2eZPqvCmqNhWo=.26c6c856-d3a3-4541-8b7e-7b2654e16ec6@github.com>
References: <9eZo1xYNGhjMSC9lDXKtkO1eyU_H-Veuh1AeP3CPKbg=.69b6c4ff-a3ef-439f-8468-21fec9de1825@github.com>
 <osex7Bks3vqpGMHMyXfMH03l-KeyW6yR6Sq8CpKN09s=.d7f78abe-1c29-4bd4-89c3-d9bd777ab47e@github.com>
 <97IuCUIDtTNr5sodrGE3PcPUugt3UT2eZPqvCmqNhWo=.26c6c856-d3a3-4541-8b7e-7b2654e16ec6@github.com>
Message-ID: <zs5E_HmI7Gkvy2yWxW_vb278c1T5M9_O4NVqegi-7d0=.dba75d27-61d1-4bb7-bdee-88e6943c3639@github.com>

On Wed, 1 Mar 2023 04:08:44 GMT, Amit Kumar <duke at openjdk.org> wrote:

> Build and tier1 test are okay with this patch, except one new failure (it could be just a random failure, unrelated to this patch) compiler/jsr292/ContinuousCallSiteTargetChange.java
> 
> But @TheRealMDoerr I'm not sure about how to perform regression, will catch up with Tyler for it and post the result.

Thanks for checking! "ContinuousCallSiteTargetChange.java" often fails. It's probably unrelated. I guess I'll change my plan and only make the feature available for now since there are some drawbacks which prevent us from enabling it by default on all platforms.

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

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

From mdoerr at openjdk.org  Wed Mar  1 05:20:08 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 1 Mar 2023 05:20:08 GMT
Subject: RFR: 8303210: [linux, Windows] Enable UseSystemMemoryBarrier by
 default if possible [v3]
In-Reply-To: <5fRZQL_fESuAYk3W5hdNEMl8dtcAPrWMUardVietcgI=.c550b7c9-5586-4d1e-83bf-2e0d67d00784@github.com>
References: <9eZo1xYNGhjMSC9lDXKtkO1eyU_H-Veuh1AeP3CPKbg=.69b6c4ff-a3ef-439f-8468-21fec9de1825@github.com>
 <osex7Bks3vqpGMHMyXfMH03l-KeyW6yR6Sq8CpKN09s=.d7f78abe-1c29-4bd4-89c3-d9bd777ab47e@github.com>
 <5fRZQL_fESuAYk3W5hdNEMl8dtcAPrWMUardVietcgI=.c550b7c9-5586-4d1e-83bf-2e0d67d00784@github.com>
Message-ID: <GyqChHCsI1nufXv51cmr2HrxhEW1q95lY0Im7FAPj6k=.13873370-fc5c-42ef-a969-7c476bb05198@github.com>

On Tue, 28 Feb 2023 06:28:42 GMT, David Holmes <dholmes at openjdk.org> wrote:

> There is also a 7.9% regression on Aarch64 with the Renaissance-Scala-Kmeans benchmark.
> 
> And 6% on Renaissance-ParMnemonics on Aarch64 (but a 7% improvement on x64 for this one).
> 
> This may have to be an opt-in potential optimisation, for which we would need a full-fledged product flag (not experimental or diagnostic).

Thanks a lot for measuring! It's very unfortunate that this nice OS feature performs poorly in some cases! So, I'll keep it off by default for now (hoping that there will be some improvement in the future).

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

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

From mdoerr at openjdk.org  Wed Mar  1 05:31:34 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 1 Mar 2023 05:31:34 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v4]
In-Reply-To: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
Message-ID: <RCrpL42YgGIsEQ9pUEc9F10x8uoN-lQKQsn3MB9Nb8E=.17e7cd1e-d700-4097-907b-7999ca58ce4f@github.com>

> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
> 
> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
> 
> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
> 
> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2.
> 
> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
> 
> I had to make changes to shared code and code for other platforms:
> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE).

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  HFA: Add support for nested structures. See JDK-8300294.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12708/files
  - new: https://git.openjdk.org/jdk/pull/12708/files/a4d844f7..b461d80c

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

  Stats: 37 lines in 2 files changed: 24 ins; 0 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/12708.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12708/head:pull/12708

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

From kbarrett at openjdk.org  Wed Mar  1 06:08:33 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 1 Mar 2023 06:08:33 GMT
Subject: RFR: 8303418: Improve parameter and variable names in BitMap [v2]
In-Reply-To: <LkA8PloAB0eQanDBr7eWx9_5EG5-6WByhZk19NxVcEw=.34afb33b-5e55-44a9-93bd-d701b62679c6@github.com>
References: <LkA8PloAB0eQanDBr7eWx9_5EG5-6WByhZk19NxVcEw=.34afb33b-5e55-44a9-93bd-d701b62679c6@github.com>
Message-ID: <BgmgbttSgJTgNl0E_UNGTP8SWRKfwKjVRRLTA0q4xuc=.bd5be179-31dd-4157-b3df-accd0a9c3120@github.com>

> Please review this change to names in BitMap.
> 
> - Parameters that designate a bit in a BitMap are named "bit".
> - Parameters that designate a word in the underlying BitMap storage are named "word".
> - Parameters that designate a range are named "beg" and "end" resp.
> 
> Added helper function `flipped_word` for use by `get_next_bit_impl`, replacing
> the odd overload for `map`.
> 
> In `get_next_bit_impl`, prefixed the variables "index" and "limit" with
> "word_" to make clear the units.
> 
> Testing:
> mach5 tier1

Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:

  copyrights

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12798/files
  - new: https://git.openjdk.org/jdk/pull/12798/files/cccf2fc0..59138b0f

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

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

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

From mdoerr at openjdk.org  Wed Mar  1 06:12:54 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 1 Mar 2023 06:12:54 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v5]
In-Reply-To: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
Message-ID: <3kCGyBFd4OIVzBcT_6KQIvJIFCGVRTRq2dy3qKP0Piw=.ef00d405-43e7-402a-a1d3-1ebaed3b7830@github.com>

> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
> 
> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
> 
> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
> 
> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2.
> 
> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
> 
> I had to make changes to shared code and code for other platforms:
> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE).

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  Minor cleanup.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12708/files
  - new: https://git.openjdk.org/jdk/pull/12708/files/b461d80c..75b5c78f

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

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

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

From mdoerr at openjdk.org  Wed Mar  1 06:12:59 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 1 Mar 2023 06:12:59 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v3]
In-Reply-To: <ubsdQFbNzTtdhNeZwCJyA5BRc2mR4AmQwk6hgJOlBy0=.6974c426-eeb2-4212-8038-9a8e00a0e7de@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com>
 <ubsdQFbNzTtdhNeZwCJyA5BRc2mR4AmQwk6hgJOlBy0=.6974c426-eeb2-4212-8038-9a8e00a0e7de@github.com>
Message-ID: <BBG9hXGzEvl3hP3ER4DsxXoIpviA2vFLL_zDFlum3SQ=.69624d20-6f42-4537-a0fd-0275723432b6@github.com>

On Tue, 28 Feb 2023 16:54:50 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove size restriction for structs. Add TODO for Big Endian.
>
> src/hotspot/cpu/ppc/downcallLinker_ppc.cpp line 343:
> 
>> 341: 
>> 342:   __ flush();
>> 343:   // Disassembler::decode((u_char*)start, (u_char*)__ pc(), tty);
> 
> Leftover commented code?
> 
> (note that the stub can also be disassembled with `-Xlog:foreign+downcall=trace` now)

Removed. Thanks for the hint!

> src/hotspot/cpu/ppc/upcallLinker_ppc.cpp line 356:
> 
>> 354:   }
>> 355: #endif
>> 356:   //blob->print_on(tty);
> 
> Leftover commented code?

Removed.

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

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

From mdoerr at openjdk.org  Wed Mar  1 06:13:03 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 1 Mar 2023 06:13:03 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v5]
In-Reply-To: <ubsdQFbNzTtdhNeZwCJyA5BRc2mR4AmQwk6hgJOlBy0=.6974c426-eeb2-4212-8038-9a8e00a0e7de@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com>
 <ubsdQFbNzTtdhNeZwCJyA5BRc2mR4AmQwk6hgJOlBy0=.6974c426-eeb2-4212-8038-9a8e00a0e7de@github.com>
Message-ID: <zRFNJjI_Uf0J9IX0BNOlefnqYeLr0yXIWExV3QELxoE=.540bc264-e619-4704-aa4c-fb1d12e9bc7c@github.com>

On Wed, 22 Feb 2023 20:25:07 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Minor cleanup.
>
> src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/CallArranger.java line 81:
> 
>> 79:         new VMStorage[] { f1, f2, f3, f4, f5, f6, f7, f8 }, // FP output
>> 80:         new VMStorage[] { r0, r2, r3, r4, r5, r6, r7, r8, r9, r10, r11, r12 }, // volatile GP
>> 81:         new VMStorage[] { f0, f1, f2, f3, f4, f5, f6, f7, f8, f9, f10, f11, f12, f13 }, // volatile FP
> 
> Note that argument registers are assumed volatile, so they don't have to be duplicated here.

Removed.

> src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/linux/LinuxPPC64CallArranger.java line 33:
> 
>> 31:  * PPC64 CallArranger specialized for Linux ABI.
>> 32:  */
>> 33: public class LinuxPPC64CallArranger extends CallArranger {
> 
> I don't really see the point in having a separate subclass with `CallArranger` being abstract, unless you are planning to add other implementations later?
> 
> (edit: see also later comment in CallArranger https://github.com/openjdk/jdk/pull/12708#discussion_r1120753657)

AIX support will need to get implemented, yet. I guess @backwaterred will work on it.

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

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

From mdoerr at openjdk.org  Wed Mar  1 06:20:11 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 1 Mar 2023 06:20:11 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v3]
In-Reply-To: <ubsdQFbNzTtdhNeZwCJyA5BRc2mR4AmQwk6hgJOlBy0=.6974c426-eeb2-4212-8038-9a8e00a0e7de@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com>
 <ubsdQFbNzTtdhNeZwCJyA5BRc2mR4AmQwk6hgJOlBy0=.6974c426-eeb2-4212-8038-9a8e00a0e7de@github.com>
Message-ID: <qU7SxQT7HxFsAtOI-THlfN9rPVZ2G52wYCkCcJO2B9M=.1000fd60-24ce-4be1-96f4-ae4617ed25c4@github.com>

On Tue, 28 Feb 2023 19:45:28 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove size restriction for structs. Add TODO for Big Endian.
>
> src/hotspot/cpu/ppc/downcallLinker_ppc.cpp line 133:
> 
>> 131:   Register callerSP            = R2, // C/C++ uses R2 as TOC, but we can reuse it here
>> 132:            tmp                 = R11_scratch1, // same as shuffle_reg
>> 133:            call_target_address = R12_scratch2; // same as _abi._scratch2 (ABIv2 requires this reg!)
> 
> Do I understand correctly that the ABI requires the register to be used for the call to be `R12`? How does that make a difference? I guess in some cases the callee might want to know the address through which it is called? (so it looks at `R12`)

ABI v2 requires R12 to point to the function entry point. It is used to access constants relative to it.

> src/hotspot/cpu/ppc/downcallLinker_ppc.cpp line 154:
> 
>> 152:   // (abi_reg_args is abi_minframe plus space for 8 argument register spill slots)
>> 153:   assert(_abi._shadow_space_bytes == frame::abi_minframe_size, "expected space according to ABI");
>> 154:   int allocated_frame_size = frame::abi_minframe_size + MAX2(_input_registers.length(), 8) * BytesPerWord;
> 
> This is hard-coding an assumption about the ABI that's being called. Ok for now.
> 
> If it needs to be addressed in the future, it could be done by adding another field to `ABIDescriptor` like `min_stack_arg_bytes`, or something like that (which is set to zero for other ABIs). It seems to be different from `shadow_space` since it's also used by the caller to put stack arguments.

Yeah, I think this should be done on demand.

> src/hotspot/cpu/ppc/foreignGlobals_ppc.cpp line 229:
> 
>> 227: 
>> 228: void ArgumentShuffle::pd_generate(MacroAssembler* masm, VMStorage tmp, int in_stk_bias, int out_stk_bias, const StubLocations& locs) const {
>> 229:   Register callerSP = as_Register(tmp); // preset
> 
> It looks like `tmp` is being used to hold the caller's SP. I'm guessing this can not be computed the same way as we do on x86 and aarch64? (based on `RBP`, `RFP_BIAS`)
> 
> If you want, you could add another register argument to `pd_generate` that is just invalid/unused on other platforms. That way you could use `tmp` for the shuffling instead of having to go through the stack. (looks like `R0` is already used in some cases as a temp register)

There's no BP register. It could get loaded from the back chain, but would still need a register. R0 is always available as scratch reg, so there's no need to pass it. (Note that I'm not going through stack because of the lack of registers.)
Yeah, maybe passing callerSP separately would make it better readable on PPC64. Not sure if it's worth changing.

> src/hotspot/cpu/ppc/upcallLinker_ppc.cpp line 137:
> 
>> 135:   ArgumentShuffle arg_shuffle(in_sig_bt, total_in_args, out_sig_bt, total_out_args, &in_conv, &out_conv, shuffle_reg);
>> 136:   // The Java call uses the JIT ABI, but we also call C.
>> 137:   int out_arg_area = MAX2(frame::jit_out_preserve_size + arg_shuffle.out_arg_bytes(), (int)frame::abi_reg_args_size);
> 
> We need `frame::abi_reg_args_size` since we call `on_entry`/`on_exit` which require the stack space I guess?

Correct. C functions are allowed to write into the space which is part of the caller's frame.

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

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

From mdoerr at openjdk.org  Wed Mar  1 06:28:12 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 1 Mar 2023 06:28:12 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v3]
In-Reply-To: <ubsdQFbNzTtdhNeZwCJyA5BRc2mR4AmQwk6hgJOlBy0=.6974c426-eeb2-4212-8038-9a8e00a0e7de@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com>
 <ubsdQFbNzTtdhNeZwCJyA5BRc2mR4AmQwk6hgJOlBy0=.6974c426-eeb2-4212-8038-9a8e00a0e7de@github.com>
Message-ID: <o-KUCh-4KiedhUwAZZzQkKFGLTBb1vvK8gEbQvTIHCU=.4036daac-5ece-47c5-b9f6-0e9609dc5e04@github.com>

On Tue, 28 Feb 2023 20:00:15 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove size restriction for structs. Add TODO for Big Endian.
>
> src/hotspot/cpu/ppc/upcallLinker_ppc.cpp line 240:
> 
>> 238:   __ ld(call_target_address, in_bytes(Method::from_compiled_offset()), R19_method);
>> 239:   __ mtctr(call_target_address);
>> 240:   __ bctrl();
> 
> Ok, I see. I guess there is some special purpose register called `CTR` which we are moving to for `bctrl` here. Does ABIv2 require that move to always come from `R12`? (from the comment in downcallLinker).
> 
> (I'm trying to understand the requirements for possibly tweaking shared code).

There's no instruction which can use a GP reg as branch target directly. That's why we use CTR.
In this case, using R12 is not required since we call Java and our PPC64 VM code does not rely on it.
If we were calling C, using R12 would be required by ABI v2.

> src/hotspot/cpu/ppc/upcallLinker_ppc.cpp line 347:
> 
>> 345:   FunctionDescriptor* fd = (FunctionDescriptor*)fd_addr;
>> 346:   fd->set_entry(fd_addr + sizeof(FunctionDescriptor));
>> 347: #endif
> 
> Had to do a double take. Looks like we're not the only one who are using the name `FunctionDescriptor` :)

Yeah, ABI v1 (Big Endian) treats function pointers as pointers to a structure called `FunctionDescriptor` which contains the entry point plus additional information like a pointer to a constant table.

> src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/CallArranger.java line 286:
> 
>> 284:                 // "no partial DW rule": Mark first stack slot to get filled.
>> 285:                 // Note: Can only happen with forArguments = true.
>> 286:                 VMStorage overlappingReg = null;
> 
> `overlappingReg` is initialized along all branches, so it's not needed to assign `null` here (and then javac will check it is actually assigned before use)

Removed.

> src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/TypeClass.java line 66:
> 
>> 64:     }
>> 65: 
>> 66:     static boolean isHomogeneousFloatAggregate(MemoryLayout type, boolean useABIv2) {
> 
> Note that we had to make some changes to this routine on AArch64, since it didn't properly account for nested structs/unions and arrays. See: https://github.com/openjdk/panama-foreign/pull/780
> 
> Just as a heads up, in case PPC needs changes too.

Thanks for the hint! I just added the code since it is known to be needed, small and doesn't break any of the existing tests. I'll need to test and possibly debug the various cases, yet.

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

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

From mdoerr at openjdk.org  Wed Mar  1 06:41:09 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 1 Mar 2023 06:41:09 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v3]
In-Reply-To: <wBVqRDFM23KM8fjjPtUFNdW56FYsSpvOAVvHmpdjbzo=.7c429606-ac19-4f36-8e25-459534983924@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com>
 <HT8kQfjS98dYHeAMcNL5latokRiw3YK8npxl5yCD4hw=.28b19bac-cbfa-4461-a1db-c899c55b7485@github.com>
 <wBVqRDFM23KM8fjjPtUFNdW56FYsSpvOAVvHmpdjbzo=.7c429606-ac19-4f36-8e25-459534983924@github.com>
Message-ID: <QMh_faUf_LLUf68WrZiFxmPHiFcHDBfKDg3g-oekBeg=.096acd06-65c4-4357-ad4a-4089b5478fff@github.com>

On Fri, 24 Feb 2023 07:17:30 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Some more remarks about other issues:
>> - Uploaded my simple reproducer to [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
>> - Using oversized load / stores is problematic. Don't forget that OpenJDK still supports Big Endian platforms (AIX, s390x).
>> - The result of `NativeCallingConvention::calling_convention` is interpreted as size, but it returns the max offset. That's off by one slot. Should I file a bug for that? (PPC64 is not affected because it doesn't use the result.)
>> - Since the membar on the return path was mentioned: I think it would be good to enable UseSystemMemoryBarrier by default on operating systems which support it. Maybe we should discuss this with @robehn.
>
>>     * Uploaded my simple reproducer to [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
> 
> Thanks!
> 
>>     * Using oversized load / stores is problematic. Don't forget that OpenJDK still supports Big Endian platforms (AIX, s390x).
> 
> You're right. I realized that it's also problematic for heap segments, for which we can't do oversized accesses. I am working on another solution that splits up the loads/stores into power-of-two sized chunks: https://github.com/openjdk/panama-foreign/compare/foreign-memaccess+abi...JornVernee:panama-foreign:OOB That patch is just a POC at this point though. Also, I don't think it works for BE at the moment (need to flip the offset for BE, I think. Just like we do in Unsafe).
> 
>>     * The result of `NativeCallingConvention::calling_convention` is interpreted as size, but it returns the max offset. That's off by one slot. Should I file a bug for that? (PPC64 is not affected because it doesn't use the result.)
> 
> I'm not sure there's an issue there. Note that the 'max offset' is computed as `reg.offset() + reg.stack_size()`, so that should get us the size we need to allocate for the stack arguments. (e.g. 2 ints being passed at offset 0 and 4, would make max offset 4 + 4 = 8, which gives the size needed for the 2 ints). Computing the max offset instead of just summing the sizes of the stack arguments is needed since stack arguments can be sparsely placed in some cases on Mac/AArch64.
> 
>>     * Since the membar on the return path was mentioned: I think it would be good to enable UseSystemMemoryBarrier by default on operating systems which support it. Maybe we should discuss this with @robehn.
> 
> ~I don't think we've done that much testing with UseSystemMemoryBarrier since it was added~. I'm a bit nervous about turning it on by default since it's currently also used for JNI. Let's see what Robbin thinks.

@JornVernee: Thanks a lot for your detailed review! I have quite a few TODOs which include:
- Include my tests for the HFA corner cases.
- Try to improve handling of the overlapping registers as you suggested.
- Check nesting of HFA.

There will surely be more when looking into Big Endian support after merging with your recent work on https://github.com/openjdk/panama-foreign/compare/foreign-memaccess+abi...JornVernee:panama-foreign:OOB
We should get rid of oversized accesses on PPC64, too.
Thanks for sharing your plans to intrisify `linkToNative` in C2 later. I guess we should do more preparation work on all platforms when that gets addressed.

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

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

From fyang at openjdk.org  Wed Mar  1 07:03:06 2023
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 1 Mar 2023 07:03:06 GMT
Subject: RFR: 8303210: [linux, Windows] Enable UseSystemMemoryBarrier by
 default if possible [v3]
In-Reply-To: <osex7Bks3vqpGMHMyXfMH03l-KeyW6yR6Sq8CpKN09s=.d7f78abe-1c29-4bd4-89c3-d9bd777ab47e@github.com>
References: <9eZo1xYNGhjMSC9lDXKtkO1eyU_H-Veuh1AeP3CPKbg=.69b6c4ff-a3ef-439f-8468-21fec9de1825@github.com>
 <osex7Bks3vqpGMHMyXfMH03l-KeyW6yR6Sq8CpKN09s=.d7f78abe-1c29-4bd4-89c3-d9bd777ab47e@github.com>
Message-ID: <UHryx0Oy89jQ9EdoTCjR4-oo0MKmoozbwPJU1kG4B7M=.cd00b793-5718-4a95-927e-89b6dd89731f@github.com>

On Tue, 28 Feb 2023 05:26:22 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> I'd like to enable UseSystemMemoryBarrier by default on supported Operating Systems in order to improve performance of thread state transitions (I/O, JNI, foreign function calls, JIT compiler threads, etc.). See JBS issue for more details.
>> Unfortunately, the feature was not yet implemented on all platforms. I added the code, but need the platform maintainers to check if it can be used reliably (and ideally if the performance improves). It's easy to switch it off again in case of problems.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve logging.

bootcycle and tier1-3 test good on linux-riscv64 platform. I think it will be safer to explicitly include "runtime/globals.hpp":


diff --git a/src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp b/src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp
index d0083f932df..117145ac137 100644
--- a/src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp
+++ b/src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp
@@ -44,6 +44,7 @@
 #include "prims/methodHandles.hpp"
 #include "runtime/continuation.hpp"
 #include "runtime/continuationEntry.inline.hpp"
+#include "runtime/globals.hpp"
 #include "runtime/jniHandles.hpp"
 #include "runtime/safepointMechanism.hpp"
 #include "runtime/sharedRuntime.hpp"
diff --git a/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp b/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp
index 3a259d4ba18..ff7b40c2695 100644
--- a/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp
+++ b/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp
@@ -45,6 +45,7 @@
 #include "runtime/arguments.hpp"
 #include "runtime/deoptimization.hpp"
 #include "runtime/frame.inline.hpp"
+#include "runtime/globals.hpp"
 #include "runtime/jniHandles.hpp"
 #include "runtime/sharedRuntime.hpp"
 #include "runtime/stubRoutines.hpp"

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

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

From stuefe at openjdk.org  Wed Mar  1 07:13:08 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 1 Mar 2023 07:13:08 GMT
Subject: RFR: 8302798: Refactor -XX:+UseOSErrorReporting for noreturn crash
 reporting [v2]
In-Reply-To: <cdY_mFh0aGAeccyNM-4OgCDqMRqglZeXka6gE06fYPM=.e036581e-b1c0-4b4a-9fb2-08f61718f726@github.com>
References: <elVA1mzItfJ7bnnfSpEUVprtbnnSx1zT_eoXnV2sviU=.13e2d4dc-74b0-4051-8852-04caf2c81196@github.com>
 <cdY_mFh0aGAeccyNM-4OgCDqMRqglZeXka6gE06fYPM=.e036581e-b1c0-4b4a-9fb2-08f61718f726@github.com>
Message-ID: <jDcu1JqmloiEEXIGNflwJ_WhE6-gLBivBCR11LEJU6U=.9f5f24c2-28ba-4615-8b77-7ff6b2b46759@github.com>

On Wed, 1 Mar 2023 02:49:39 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to the implementation of the Windows-specific option
>> UseOSErrorReporting, toward allowing crash reporting functions to be declared
>> noreturn.  VMError::report_and_die no longer conditionally returns if the
>> Windows-only option UseOSErrorReporting is true.
>> 
>> The Windows-only sections of report_and_die now call RaiseFailFastException
>> (https://learn.microsoft.com/en-us/windows/win32/api/errhandlingapi/nf-errhandlingapi-raisefailfastexception),
>> which immediately invokes WER (Windows Error Reporting) if it is enabled,
>> without executing structured exception handler.  If WER is not enabled, it
>> just immediately terminates the program.  Thus, we no longer return to walk up
>> thestructured exception handler chain to pop out at the top as unhandled in
>> order to invoke WER.
>> 
>> This permits declaring report_and_die as [[noreturn]], once some functions
>> from the os class are also so declared.  Also adding that attribute as
>> appropriate to other functions in the os class.  This of course assumes
>> the use of [[noreturn]] in HotSpot code is approved (JDK-8302124).
>> 
>> There is a pre-existing bug that I'll be reporting separately.  If
>> UseOSErrorReporting and CreateCoredumpOnCrash are both true, we create an
>> empty .mdmp file.  We shouldn't create that file when UseOSErrorReporting.
>> 
>> Testing:
>> mach5 tier1-3
>> 
>> Manual testing with the following, to verify desired behavior.
>> 
>> -XX:ErrorHandlerTest=N
>> 1: assertion failure
>> 2: guarantee failure
>> 14: SIGSEGV
>> 15: divide by zero
>> path/to/bin/java \
>>   -XX:+UnlockDiagnosticVMOptions \
>>   -XX:+ErrorLogSecondaryErrorDetails \
>>   -XX:+UseOSErrorReporting \
>>   -XX:ErrorHandlerTest=1 \
>>   TestDebug.java
>> 
>> --- TestDebug.java ---
>> import java.lang.String;
>> public class TestDebug {
>>     static private volatile String dummy;
>>     public static void main(String[] args) throws Exception {
>>         while (true) {
>>             dummy = new String("foo bar");
>>         }
>>     }
>> }
>> --- end TestDebug.java ---
>> 
>> The state of WER can be examined and modified using Power Shell commands
>> {Get,Enable,Disable}-WindowsErrorReporting.
>> 
>> The state of reporting WER captured errors can be examined and modified using
>> Control Panel > Security and Maintenance > Maintenance : Report Problems [on,off]
>> 
>> With Report Problems off, reports are placed in
>> c:\ProgramData\Microsoft\Windows\WER\ReportArchive
>> 
>> I verified that executing the above test with WER enabled adds an entry in
>> that directory, but not when it's disabled.  Also nothing is added there when
>> the test is run with -XX:-UseOSErrorReporting.
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove failfast cuttoff of secondary errors

LGTM

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

Marked as reviewed by stuefe (Reviewer).

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

From duke at openjdk.org  Wed Mar  1 08:27:08 2023
From: duke at openjdk.org (Jan Kratochvil)
Date: Wed, 1 Mar 2023 08:27:08 GMT
Subject: RFR: 8302191: Performance degradation for float/double modulo on
 Linux [v2]
In-Reply-To: <aN2pZG7isT9g2x7jsq0Q4ZUghGGYN7pWmspxNvuepwI=.ec07624b-2a7a-4f5d-a428-b9d1246d64dd@github.com>
References: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
 <CR6FSWocHu8YjQQrPRqkOTetmbZ-WYHLZlEeWLbsVfM=.71d2e6bf-7a6c-488b-8c4f-b71d9df21044@github.com>
 <jOXvH6Ozm5_xK1bEYzdvgkUAbgP4pu0aonYxbA0itNo=.a7ffbdf6-fba5-49c0-bd63-3996ea317ec4@github.com>
 <aN2pZG7isT9g2x7jsq0Q4ZUghGGYN7pWmspxNvuepwI=.ec07624b-2a7a-4f5d-a428-b9d1246d64dd@github.com>
Message-ID: <fXFz8XPFS6hYhWdKVmYNje94JJRxI1CgiG-Wtq848ZA=.6593d314-130f-483d-878c-35e63249c2d7@github.com>

On Tue, 28 Feb 2023 12:41:07 GMT, Jan Kratochvil <duke at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/vm/floatingpoint/DremFrem.java line 44:
>> 
>>> 42:  * Java bytecode drem is defined as C fmod (not C drem==remainder).
>>> 43:  * GCC since 93ba85fdd253b4b9cf2b9e54e8e5969b1a3db098 has slow fmod().
>>> 44:  * Testcase is based on: https://stackoverflow.com/a/55673220/2995591
>> 
>> That could be a problem. What is the license for code shown on StackOverflow?
>
> A nice catch. I have tried to get a compatible license, we'll see: https://github.com/cirosantilli/java-cheat/pull/3

It is now resolved, the testcase code is now relicensed as GPLv2+.

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

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

From duke at openjdk.org  Wed Mar  1 08:52:06 2023
From: duke at openjdk.org (Jan Kratochvil)
Date: Wed, 1 Mar 2023 08:52:06 GMT
Subject: RFR: 8302191: Performance degradation for float/double modulo on
 Linux [v2]
In-Reply-To: <jOXvH6Ozm5_xK1bEYzdvgkUAbgP4pu0aonYxbA0itNo=.a7ffbdf6-fba5-49c0-bd63-3996ea317ec4@github.com>
References: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
 <CR6FSWocHu8YjQQrPRqkOTetmbZ-WYHLZlEeWLbsVfM=.71d2e6bf-7a6c-488b-8c4f-b71d9df21044@github.com>
 <jOXvH6Ozm5_xK1bEYzdvgkUAbgP4pu0aonYxbA0itNo=.a7ffbdf6-fba5-49c0-bd63-3996ea317ec4@github.com>
Message-ID: <50HcTSZYkWhmyRTTSpQsJJ9Dv28R_RnY1XflczBBxeg=.7c6c1e71-7129-4bc2-9ab5-f5dde541f0a9@github.com>

On Mon, 27 Feb 2023 01:16:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Jan Kratochvil 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:
>> 
>>   8302191: Performance degradation for float/double modulo on Linux
>
> src/hotspot/cpu/x86/sharedRuntime_x86.cpp line 87:
> 
>> 85: #endif //COMPILER1
>> 86: 
>> 87: JRT_LEAF(jfloat, SharedRuntime::frem(jfloat  x, jfloat  y))
> 
> Nit: extra space before x and y.

I agree but FYI it was just copy-pasted from existing source:
> `-JRT_LEAF(jfloat, SharedRuntime::frem(jfloat  x, jfloat  y))`

> src/hotspot/share/runtime/sharedRuntime.cpp line 236:
> 
>> 234: const julong double_infinity  = CONST64(0x7FF0000000000000);
>> 235: 
>> 236: #ifndef X86
> 
> I wonder if the WIN64 workaround is actually needed/valid for non-X86 windows?

It is true the comment says:
> 64-bit Windows on amd64 returns the wrong values for infinity operands.
I have left the workaround really just for AMD64 Windows now. I am going to get it regression tested on aarch64 if that is enough.

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

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

From duke at openjdk.org  Wed Mar  1 08:56:44 2023
From: duke at openjdk.org (Jan Kratochvil)
Date: Wed, 1 Mar 2023 08:56:44 GMT
Subject: RFR: 8302191: Performance degradation for float/double modulo on
 Linux [v3]
In-Reply-To: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
References: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
Message-ID: <CcNC2KYN2ySvyrAnY26-lOgtCIDjQPr8ujSWMON0FqI=.98f62714-3b8f-45b7-8b34-3c82a1fb8353@github.com>

> I have OCA already processed/approved. I am not Author but my Author request is being processed these days (sent to Rob McKenna).
> I did regression test x86_64 OpenJDK-8. I will leave other regression testing on GHA.
> The patch (and former GCC performance regression) affects only x86_64+i686.

Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:

  Update according to the upstream review by David Holmes.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12508/files
  - new: https://git.openjdk.org/jdk/pull/12508/files/d00f1a5a..44ba5348

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

  Stats: 66 lines in 3 files changed: 30 ins; 30 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/12508.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12508/head:pull/12508

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

From eosterlund at openjdk.org  Wed Mar  1 09:21:58 2023
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Wed, 1 Mar 2023 09:21:58 GMT
Subject: RFR: 8302780: Add support for vectorized arraycopy GC barriers
 [v7]
In-Reply-To: <SU-lpFUY3nGTCSM5k7HrOR2xGgNhPFRNDFUa6JBNEMQ=.2ceac514-334b-4201-8f7b-f17b9ebf3505@github.com>
References: <SU-lpFUY3nGTCSM5k7HrOR2xGgNhPFRNDFUa6JBNEMQ=.2ceac514-334b-4201-8f7b-f17b9ebf3505@github.com>
Message-ID: <3Pj7rn9qShfBoskPL0APjSp_uFqSbe59oJOHIwnGZwo=.68853563-53cc-4988-aa26-7f64aabafd58@github.com>

> So far, the arraycopy stubs have performed some kind of bulk pre/post barriers for arraycopy, which have been good enough, and allowed the copying itself to be done with plain loads and stores. For generational ZGC, this approach is not good enough, and we need barriers for the actual copying, but instead don't need the pre/post barriers. To prepare the JVM for generational ZGC, we need to add an API for arraycopy barriers.

Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:

  Helper stack object aarch64

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12670/files
  - new: https://git.openjdk.org/jdk/pull/12670/files/8d2b8f41..888e4cb0

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

  Stats: 446 lines in 1 file changed: 73 ins; 242 del; 131 mod
  Patch: https://git.openjdk.org/jdk/pull/12670.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12670/head:pull/12670

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

From mbaesken at openjdk.org  Wed Mar  1 09:24:39 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 1 Mar 2023 09:24:39 GMT
Subject: RFR: JDK-8302989: Add missing INCLUDE_CDS checks [v2]
In-Reply-To: <kBV8fNo_CWJL2MoXgAckFhuAFgQ3RGZjFKAKnl8xfV8=.233bb652-8508-4065-92ea-7873b1c765f3@github.com>
References: <kBV8fNo_CWJL2MoXgAckFhuAFgQ3RGZjFKAKnl8xfV8=.233bb652-8508-4065-92ea-7873b1c765f3@github.com>
Message-ID: <kC0i6N44wUExbim6e2SCu5QCCpEGxRTEeRCGMRe__Fs=.46f19345-c54b-4e9b-bd8d-5c38dc4846a1@github.com>

> The cds only coding in hotspot is usually guarded with the INCLUDE_CDS macro so that it can be removed at compile time in case the correct configure flags are set.
> However at some places INCLUDE_CDS is missing and should be added.
> 
> One question - should (additionally to the UseSharedSpaces code section)  the DumpSharedSpaces code sections be guarded as well with INCLUDE_CDS macros ?

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Make SharedSpaces related vars const and false in non CDS mode

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12691/files
  - new: https://git.openjdk.org/jdk/pull/12691/files/6c22a2a7..5dff9614

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

  Stats: 46 lines in 4 files changed: 45 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12691.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12691/head:pull/12691

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

From eosterlund at openjdk.org  Wed Mar  1 09:29:12 2023
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Wed, 1 Mar 2023 09:29:12 GMT
Subject: RFR: 8302780: Add support for vectorized arraycopy GC barriers
 [v6]
In-Reply-To: <2g2QqIWkC2a7QyVzPkX-QW3LcMrti6-AMwuFPqe752o=.c63ae268-69be-4770-b642-544633c1cf8f@github.com>
References: <SU-lpFUY3nGTCSM5k7HrOR2xGgNhPFRNDFUa6JBNEMQ=.2ceac514-334b-4201-8f7b-f17b9ebf3505@github.com>
 <47e5gQJkZn7ldGv3n2cyQoZSAT9YpWWvIwXnbxhdGuQ=.643a4652-204b-4689-85a4-9378e8a587b3@github.com>
 <2g2QqIWkC2a7QyVzPkX-QW3LcMrti6-AMwuFPqe752o=.c63ae268-69be-4770-b642-544633c1cf8f@github.com>
Message-ID: <1NdlCJpW9kP6N1prWI-pXRBFCooYppayETd83JdBEkE=.df3ed4f4-b685-4377-8284-40b4a3cedf5e@github.com>

On Tue, 28 Feb 2023 10:34:17 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add comment
>
> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 720:
> 
>> 718:       t4 = r7, t5 = r11, t6 = r12, t7 = r13;
>> 719:     const Register stride = r14;
>> 720:     const Register gct1 = r8, gct2 = r9, gct3 = r10;
> 
> Please don't alias rscratch1 and rscratch2. Many macros use them, and this is a bug waiting to happen.

I view the GC barriers in spirit as being one of said macros, they just happen to be in a different file. We could have them in the macroAssembler file, but choose to not clutter it with GC specifics, and moved it to a different file instead.
The main reason I selected r8 and r9 for the GC temp registers, is that we have run out of C ABI caller saved registers in copy_memory. All other registers in [r0, r17] are already used, and the arraycopy stubs are called with the C ABI, hence expecting any callee saved register to either not be touched or be saved in the callee, making them poor choices for temp registers. While a different selection could be made, using for example a callee saved register such as r20 and r21, I'd have to push the registers in the prologue and pop them in the epilogue of the arraycopy stubs, which seems a bit awkward if it can be avoided. I'm open to doing that, but it doesn't spark joy. So I thought I'd explain the choice here. What do you think?

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

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

From eosterlund at openjdk.org  Wed Mar  1 09:32:29 2023
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Wed, 1 Mar 2023 09:32:29 GMT
Subject: RFR: 8302780: Add support for vectorized arraycopy GC barriers
 [v6]
In-Reply-To: <nLy9emUIdTkhV1t48otOXxgMwJ_eU6ittB6QA0X7JYo=.c8f0e35b-d41e-4a98-9538-7bfbb6a0a77f@github.com>
References: <SU-lpFUY3nGTCSM5k7HrOR2xGgNhPFRNDFUa6JBNEMQ=.2ceac514-334b-4201-8f7b-f17b9ebf3505@github.com>
 <47e5gQJkZn7ldGv3n2cyQoZSAT9YpWWvIwXnbxhdGuQ=.643a4652-204b-4689-85a4-9378e8a587b3@github.com>
 <nLy9emUIdTkhV1t48otOXxgMwJ_eU6ittB6QA0X7JYo=.c8f0e35b-d41e-4a98-9538-7bfbb6a0a77f@github.com>
Message-ID: <SsRePM6dkPRzWTX5vD-Of9vcCURYSZyKMr4DYfBif8U=.8423d374-1ee6-4fba-9561-f40517fe9490@github.com>

On Tue, 28 Feb 2023 13:48:23 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add comment
>
> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 812:
> 
>> 810:       bs_asm->copy_load_at(_masm, decorators, type, 32,
>> 811:                            v2, v3, Address(__ pre(s, 8 * unit)),
>> 812:                            gct1, gct2, gcvt1);
> 
> All this extreme cut-and-paste manual unrolling is very hard to read, maintain, and review.
> I wasn't going to say anything, because it's Erik, and what do I know! But I must push back here, this is too much.
> Please consider these style changes.

I updated the PR with a helper stack object encapsulating the choice of GC temp registers, types, decorators, etc, so that each line removes all the noise and becomes more readable. Do you like it? If yes, do you also want your proposed loop constructions in the new more compact form? I'm okay either way.

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

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

From kbarrett at openjdk.org  Wed Mar  1 09:54:09 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 1 Mar 2023 09:54:09 GMT
Subject: RFR: 8302798: Refactor -XX:+UseOSErrorReporting for noreturn crash
 reporting [v2]
In-Reply-To: <6VenuisSudRu06LiySSGslFxVuvMh9GpY1elHkahExU=.5b06f61d-7635-48b0-b139-da102ceb2fcf@github.com>
References: <elVA1mzItfJ7bnnfSpEUVprtbnnSx1zT_eoXnV2sviU=.13e2d4dc-74b0-4051-8852-04caf2c81196@github.com>
 <6VenuisSudRu06LiySSGslFxVuvMh9GpY1elHkahExU=.5b06f61d-7635-48b0-b139-da102ceb2fcf@github.com>
Message-ID: <joYVbvGpgBLsQRE9D_VhrAty-24rdmgVTKgj64b7dOE=.aafaa8ac-31d7-4842-a79a-3e018874ff6c@github.com>

On Mon, 27 Feb 2023 21:57:37 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove failfast cuttoff of secondary errors
>
> This is a nice solution and thank you for going the extra step of verifying that the code supports WER.

Thanks for reviews @coleenp and @tstuefe .

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

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

From eosterlund at openjdk.org  Wed Mar  1 09:54:15 2023
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Wed, 1 Mar 2023 09:54:15 GMT
Subject: RFR: 8302780: Add support for vectorized arraycopy GC barriers
 [v6]
In-Reply-To: <1NdlCJpW9kP6N1prWI-pXRBFCooYppayETd83JdBEkE=.df3ed4f4-b685-4377-8284-40b4a3cedf5e@github.com>
References: <SU-lpFUY3nGTCSM5k7HrOR2xGgNhPFRNDFUa6JBNEMQ=.2ceac514-334b-4201-8f7b-f17b9ebf3505@github.com>
 <47e5gQJkZn7ldGv3n2cyQoZSAT9YpWWvIwXnbxhdGuQ=.643a4652-204b-4689-85a4-9378e8a587b3@github.com>
 <2g2QqIWkC2a7QyVzPkX-QW3LcMrti6-AMwuFPqe752o=.c63ae268-69be-4770-b642-544633c1cf8f@github.com>
 <1NdlCJpW9kP6N1prWI-pXRBFCooYppayETd83JdBEkE=.df3ed4f4-b685-4377-8284-40b4a3cedf5e@github.com>
Message-ID: <RfZT2ILh5aTTS01W2zpsGMH6GgeBYnAhuqy_JGw6JZ4=.0a000408-dfba-4e66-8b18-40d6c92b703e@github.com>

On Wed, 1 Mar 2023 09:25:58 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 720:
>> 
>>> 718:       t4 = r7, t5 = r11, t6 = r12, t7 = r13;
>>> 719:     const Register stride = r14;
>>> 720:     const Register gct1 = r8, gct2 = r9, gct3 = r10;
>> 
>> Please don't alias rscratch1 and rscratch2. Many macros use them, and this is a bug waiting to happen.
>
> I view the GC barriers in spirit as being one of said macros, they just happen to be in a different file. We could have them in the macroAssembler file, but choose to not clutter it with GC specifics, and moved it to a different file instead.
> The main reason I selected r8 and r9 for the GC temp registers, is that we have run out of C ABI caller saved registers in copy_memory. All other registers in [r0, r17] are already used, and the arraycopy stubs are called with the C ABI, hence expecting any callee saved register to either not be touched or be saved in the callee, making them poor choices for temp registers. While a different selection could be made, using for example a callee saved register such as r20 and r21, I'd have to push the registers in the prologue and pop them in the epilogue of the arraycopy stubs, which seems a bit awkward if it can be avoided. I'm open to doing that, but it doesn't spark joy. So I thought I'd explain the choice here. What do you think?

Note also that the arraycopy stubs were already using r8 and r9 as temp registers. I just moved their use to GC barriers, so only they need to deal with their inherent scratchyness, while the temp registers used in the client code can use registers that are not scratchy, which was not the case before.

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

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

From iklam at openjdk.org  Wed Mar  1 10:00:06 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 1 Mar 2023 10:00:06 GMT
Subject: RFR: JDK-8302989: Add missing INCLUDE_CDS checks [v2]
In-Reply-To: <kC0i6N44wUExbim6e2SCu5QCCpEGxRTEeRCGMRe__Fs=.46f19345-c54b-4e9b-bd8d-5c38dc4846a1@github.com>
References: <kBV8fNo_CWJL2MoXgAckFhuAFgQ3RGZjFKAKnl8xfV8=.233bb652-8508-4065-92ea-7873b1c765f3@github.com>
 <kC0i6N44wUExbim6e2SCu5QCCpEGxRTEeRCGMRe__Fs=.46f19345-c54b-4e9b-bd8d-5c38dc4846a1@github.com>
Message-ID: <D94A_iYhqCAvpWC87xWqEIAs7DQtw68zdetsZQc5pQ8=.8a39311a-60b2-4d83-969e-f48a74278d5b@github.com>

On Wed, 1 Mar 2023 09:24:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The cds only coding in hotspot is usually guarded with the INCLUDE_CDS macro so that it can be removed at compile time in case the correct configure flags are set.
>> However at some places INCLUDE_CDS is missing and should be added.
>> 
>> One question - should (additionally to the UseSharedSpaces code section)  the DumpSharedSpaces code sections be guarded as well with INCLUDE_CDS macros ?
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make SharedSpaces related vars const and false in non CDS mode

src/hotspot/share/utilities/globalDefinitions.hpp line 594:

> 592: #else
> 593: // in non CDS mode do not export it
> 594: extern const bool UseSharedSpaces;

How about this?


const bool RequireSharedSpaces = false;


This will allow the C++ compiler to eliminate all code that depend on this value when `INCLUDE_CDS` is false.

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

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

From kbarrett at openjdk.org  Wed Mar  1 10:25:06 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 1 Mar 2023 10:25:06 GMT
Subject: RFR: 8302798: Refactor -XX:+UseOSErrorReporting for noreturn crash
 reporting [v3]
In-Reply-To: <elVA1mzItfJ7bnnfSpEUVprtbnnSx1zT_eoXnV2sviU=.13e2d4dc-74b0-4051-8852-04caf2c81196@github.com>
References: <elVA1mzItfJ7bnnfSpEUVprtbnnSx1zT_eoXnV2sviU=.13e2d4dc-74b0-4051-8852-04caf2c81196@github.com>
Message-ID: <e2seVQWyK6KOjyo8gGmxeJfPbXBV0QibpBAm6jYAsJE=.27f3fdfc-7763-409e-be1c-3fe61e3905b7@github.com>

> Please review this change to the implementation of the Windows-specific option
> UseOSErrorReporting, toward allowing crash reporting functions to be declared
> noreturn.  VMError::report_and_die no longer conditionally returns if the
> Windows-only option UseOSErrorReporting is true.
> 
> The Windows-only sections of report_and_die now call RaiseFailFastException
> (https://learn.microsoft.com/en-us/windows/win32/api/errhandlingapi/nf-errhandlingapi-raisefailfastexception),
> which immediately invokes WER (Windows Error Reporting) if it is enabled,
> without executing structured exception handler.  If WER is not enabled, it
> just immediately terminates the program.  Thus, we no longer return to walk up
> thestructured exception handler chain to pop out at the top as unhandled in
> order to invoke WER.
> 
> This permits declaring report_and_die as [[noreturn]], once some functions
> from the os class are also so declared.  Also adding that attribute as
> appropriate to other functions in the os class.  This of course assumes
> the use of [[noreturn]] in HotSpot code is approved (JDK-8302124).
> 
> There is a pre-existing bug that I'll be reporting separately.  If
> UseOSErrorReporting and CreateCoredumpOnCrash are both true, we create an
> empty .mdmp file.  We shouldn't create that file when UseOSErrorReporting.
> 
> Testing:
> mach5 tier1-3
> 
> Manual testing with the following, to verify desired behavior.
> 
> -XX:ErrorHandlerTest=N
> 1: assertion failure
> 2: guarantee failure
> 14: SIGSEGV
> 15: divide by zero
> path/to/bin/java \
>   -XX:+UnlockDiagnosticVMOptions \
>   -XX:+ErrorLogSecondaryErrorDetails \
>   -XX:+UseOSErrorReporting \
>   -XX:ErrorHandlerTest=1 \
>   TestDebug.java
> 
> --- TestDebug.java ---
> import java.lang.String;
> public class TestDebug {
>     static private volatile String dummy;
>     public static void main(String[] args) throws Exception {
>         while (true) {
>             dummy = new String("foo bar");
>         }
>     }
> }
> --- end TestDebug.java ---
> 
> The state of WER can be examined and modified using Power Shell commands
> {Get,Enable,Disable}-WindowsErrorReporting.
> 
> The state of reporting WER captured errors can be examined and modified using
> Control Panel > Security and Maintenance > Maintenance : Report Problems [on,off]
> 
> With Report Problems off, reports are placed in
> c:\ProgramData\Microsoft\Windows\WER\ReportArchive
> 
> I verified that executing the above test with WER enabled adds an entry in
> that directory, but not when it's disabled.  Also nothing is added there when
> the test is run with -XX:-UseOSErrorReporting.

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 three additional commits since the last revision:

 - Merge branch 'master' into failfast
 - remove failfast cuttoff of secondary errors
 - failfast

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12759/files
  - new: https://git.openjdk.org/jdk/pull/12759/files/e3717037..8a7c86ee

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

  Stats: 3684 lines in 195 files changed: 2505 ins; 453 del; 726 mod
  Patch: https://git.openjdk.org/jdk/pull/12759.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12759/head:pull/12759

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

From kbarrett at openjdk.org  Wed Mar  1 10:25:07 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 1 Mar 2023 10:25:07 GMT
Subject: Integrated: 8302798: Refactor -XX:+UseOSErrorReporting for noreturn
 crash reporting
In-Reply-To: <elVA1mzItfJ7bnnfSpEUVprtbnnSx1zT_eoXnV2sviU=.13e2d4dc-74b0-4051-8852-04caf2c81196@github.com>
References: <elVA1mzItfJ7bnnfSpEUVprtbnnSx1zT_eoXnV2sviU=.13e2d4dc-74b0-4051-8852-04caf2c81196@github.com>
Message-ID: <RXEiYWj3OsQQuqp67XX-bCDcp53z1ymIYTgn9KITbhw=.879726d8-13f8-4081-89f6-3b1e733ca426@github.com>

On Mon, 27 Feb 2023 10:19:50 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to the implementation of the Windows-specific option
> UseOSErrorReporting, toward allowing crash reporting functions to be declared
> noreturn.  VMError::report_and_die no longer conditionally returns if the
> Windows-only option UseOSErrorReporting is true.
> 
> The Windows-only sections of report_and_die now call RaiseFailFastException
> (https://learn.microsoft.com/en-us/windows/win32/api/errhandlingapi/nf-errhandlingapi-raisefailfastexception),
> which immediately invokes WER (Windows Error Reporting) if it is enabled,
> without executing structured exception handler.  If WER is not enabled, it
> just immediately terminates the program.  Thus, we no longer return to walk up
> thestructured exception handler chain to pop out at the top as unhandled in
> order to invoke WER.
> 
> This permits declaring report_and_die as [[noreturn]], once some functions
> from the os class are also so declared.  Also adding that attribute as
> appropriate to other functions in the os class.  This of course assumes
> the use of [[noreturn]] in HotSpot code is approved (JDK-8302124).
> 
> There is a pre-existing bug that I'll be reporting separately.  If
> UseOSErrorReporting and CreateCoredumpOnCrash are both true, we create an
> empty .mdmp file.  We shouldn't create that file when UseOSErrorReporting.
> 
> Testing:
> mach5 tier1-3
> 
> Manual testing with the following, to verify desired behavior.
> 
> -XX:ErrorHandlerTest=N
> 1: assertion failure
> 2: guarantee failure
> 14: SIGSEGV
> 15: divide by zero
> path/to/bin/java \
>   -XX:+UnlockDiagnosticVMOptions \
>   -XX:+ErrorLogSecondaryErrorDetails \
>   -XX:+UseOSErrorReporting \
>   -XX:ErrorHandlerTest=1 \
>   TestDebug.java
> 
> --- TestDebug.java ---
> import java.lang.String;
> public class TestDebug {
>     static private volatile String dummy;
>     public static void main(String[] args) throws Exception {
>         while (true) {
>             dummy = new String("foo bar");
>         }
>     }
> }
> --- end TestDebug.java ---
> 
> The state of WER can be examined and modified using Power Shell commands
> {Get,Enable,Disable}-WindowsErrorReporting.
> 
> The state of reporting WER captured errors can be examined and modified using
> Control Panel > Security and Maintenance > Maintenance : Report Problems [on,off]
> 
> With Report Problems off, reports are placed in
> c:\ProgramData\Microsoft\Windows\WER\ReportArchive
> 
> I verified that executing the above test with WER enabled adds an entry in
> that directory, but not when it's disabled.  Also nothing is added there when
> the test is run with -XX:-UseOSErrorReporting.

This pull request has now been integrated.

Changeset: 539a4951
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/539a4951eee914da15a00cbd04ebc6a2c59b8f23
Stats:     51 lines in 5 files changed: 22 ins; 8 del; 21 mod

8302798: Refactor -XX:+UseOSErrorReporting for noreturn crash reporting

Reviewed-by: coleenp, stuefe

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

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

From eosterlund at openjdk.org  Wed Mar  1 10:56:31 2023
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Wed, 1 Mar 2023 10:56:31 GMT
Subject: RFR: 8302780: Add support for vectorized arraycopy GC barriers
 [v8]
In-Reply-To: <SU-lpFUY3nGTCSM5k7HrOR2xGgNhPFRNDFUa6JBNEMQ=.2ceac514-334b-4201-8f7b-f17b9ebf3505@github.com>
References: <SU-lpFUY3nGTCSM5k7HrOR2xGgNhPFRNDFUa6JBNEMQ=.2ceac514-334b-4201-8f7b-f17b9ebf3505@github.com>
Message-ID: <BWqOjj4KikZ2Mj14NNMdbAhMaY0rsj0289AEAQFqegw=.af04f90a-7548-4bfd-8399-ab5a763b8dd1@github.com>

> So far, the arraycopy stubs have performed some kind of bulk pre/post barriers for arraycopy, which have been good enough, and allowed the copying itself to be done with plain loads and stores. For generational ZGC, this approach is not good enough, and we need barriers for the actual copying, but instead don't need the pre/post barriers. To prepare the JVM for generational ZGC, we need to add an API for arraycopy barriers.

Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:

  Add comment about r15 useage

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12670/files
  - new: https://git.openjdk.org/jdk/pull/12670/files/888e4cb0..d03a5c29

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

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

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

From eosterlund at openjdk.org  Wed Mar  1 10:56:33 2023
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Wed, 1 Mar 2023 10:56:33 GMT
Subject: RFR: 8302780: Add support for vectorized arraycopy GC barriers
 [v6]
In-Reply-To: <44kCeVWFrSGQEcehVV5G_EowMs26zWcuv5KmDbYv9Mc=.f49cb445-de78-4932-aefc-1839fd0be611@github.com>
References: <SU-lpFUY3nGTCSM5k7HrOR2xGgNhPFRNDFUa6JBNEMQ=.2ceac514-334b-4201-8f7b-f17b9ebf3505@github.com>
 <47e5gQJkZn7ldGv3n2cyQoZSAT9YpWWvIwXnbxhdGuQ=.643a4652-204b-4689-85a4-9378e8a587b3@github.com>
 <44kCeVWFrSGQEcehVV5G_EowMs26zWcuv5KmDbYv9Mc=.f49cb445-de78-4932-aefc-1839fd0be611@github.com>
Message-ID: <3nz9PRPYzYVszMpwatVR3TbeFZsdT0jHpZ6lHqgJbSA=.12875265-8044-41c7-8e12-3b2851be8b08@github.com>

On Tue, 28 Feb 2023 12:28:02 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add comment
>
> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 1270:
> 
>> 1268:     Label copy4, copy8, copy16, copy32, copy80, copy_big, finish;
>> 1269:     const Register t2 = r5, t3 = r6, t4 = r7, t5 = r11;
>> 1270:     const Register t6 = r12, t7 = r13, t8 = r14, t9 = r15;
> 
> I find the usage of r15 in `copy_memory` a bit confusing. If I get it right, it is used
> 1. as a temporary register (aliased as `t9`) for 16-bytes copying (L1407-1437),
> 2. as a temporary register (in its raw form, i.e. not via `t9`) passed explicitly to `copy_memory_small` (L1518-1548), and
> 3. as a "special" register passed implicitly to the generated `copy_longs` stubs (L1557-1574).
> 
> I think it would be clearer if `t9` was used instead of `r15` for case 2) and then perhaps a comment was added before calling the generated `copy_longs` stubs mentioning that `t9` cannot be used from then on because it aliases with `r15`.

Since r15 is part of the ABI contract across different generated stubs, I'd prefer to not change it to t9 as when you scroll through the different functions, it isn't clear that t9 isn't just used locally as a temporary register, but is used across stubs, even though it isn't passed as parameter with the name "t9" said stubs. I did however add a comment explaining when we start using r15 is count and that we can't use t9 any more after that point. I hope that's okay.

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

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

From duke at openjdk.org  Wed Mar  1 11:11:48 2023
From: duke at openjdk.org (Jan Kratochvil)
Date: Wed, 1 Mar 2023 11:11:48 GMT
Subject: RFR: 8302191: Performance degradation for float/double modulo on
 Linux [v4]
In-Reply-To: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
References: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
Message-ID: <nc0sD6m_j9L8DoC45wqYqvLK1A_P1RH065kFNeeh8kA=.cc60cc10-d222-415b-8d2e-65759942e4d1@github.com>

> I have OCA already processed/approved. I am not Author but my Author request is being processed these days (sent to Rob McKenna).
> I did regression test x86_64 OpenJDK-8. I will leave other regression testing on GHA.
> The patch (and former GCC performance regression) affects only x86_64+i686.

Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:

  Fix WIN32 vs. WIN64.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12508/files
  - new: https://git.openjdk.org/jdk/pull/12508/files/44ba5348..4b7756f3

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

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

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

From rrich at openjdk.org  Wed Mar  1 11:18:47 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 1 Mar 2023 11:18:47 GMT
Subject: RFR: 8296440: Remove Method* handling from cleanup_inline_caches_impl
Message-ID: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>

This PR replaces cleaning of static stubs in CompiledMethod::cleanup_inline_caches_impl() with a guarantee that it is actually not needed because the holder of the embedded target Method* is alive if the caller nmethod is not unloading.

The holder of the target Method* has to be alive because it is reachable from the caller nmethod's oop pool. This is checked by `check_path_to_callee()` when a statically bound call gets resolved.

C2i entry barriers can be removed for the same reason.

Testing:

Many rounds in our CI testing which includes most JCK and JTREG tests, Renaissance benchmark and SAP specific tests with fastdebug and release builds on the standard platforms plus PPC64.

I've also done tier1 and tier2 tests with -XX:-Inline and tier1 tests with ZGC.

I've started hotspot and jdk tier1 tests with -Xcomp. They were not finished when I stopped them after 24h.

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

Commit messages:
 - Remove MacroAssembler::resolve_weak_handle()
 - Remove keep_alive_offset() and holder_offset() from CLD
 - Remove MacroAssembler::load_method_holder_cld()
 - Remove c2i entry barrier
 - Check dependency for statically bound call

Changes: https://git.openjdk.org/jdk/pull/12802/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12802&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296440
  Stats: 367 lines in 26 files changed: 74 ins; 283 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/12802.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12802/head:pull/12802

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

From mbaesken at openjdk.org  Wed Mar  1 11:30:02 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 1 Mar 2023 11:30:02 GMT
Subject: RFR: JDK-8302989: Add missing INCLUDE_CDS checks [v2]
In-Reply-To: <D94A_iYhqCAvpWC87xWqEIAs7DQtw68zdetsZQc5pQ8=.8a39311a-60b2-4d83-969e-f48a74278d5b@github.com>
References: <kBV8fNo_CWJL2MoXgAckFhuAFgQ3RGZjFKAKnl8xfV8=.233bb652-8508-4065-92ea-7873b1c765f3@github.com>
 <kC0i6N44wUExbim6e2SCu5QCCpEGxRTEeRCGMRe__Fs=.46f19345-c54b-4e9b-bd8d-5c38dc4846a1@github.com>
 <D94A_iYhqCAvpWC87xWqEIAs7DQtw68zdetsZQc5pQ8=.8a39311a-60b2-4d83-969e-f48a74278d5b@github.com>
Message-ID: <Rr2AaOX0OnWVBM3-GqzimZpF_T1m4XVLh7o_cnRFyLI=.318bc73f-61e2-4347-b119-74d908d963ff@github.com>

On Wed, 1 Mar 2023 09:57:28 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make SharedSpaces related vars const and false in non CDS mode
>
> src/hotspot/share/utilities/globalDefinitions.hpp line 594:
> 
>> 592: #else
>> 593: // in non CDS mode do not export it
>> 594: extern const bool UseSharedSpaces;
> 
> How about this?
> 
> 
> const bool RequireSharedSpaces = false;
> 
> 
> This will allow the C++ compiler to eliminate all code that depend on this value when `INCLUDE_CDS` is false.

Hi Ioi, I set this already some lines above (in the non-INCLUDE_CDS case).

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

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

From tschatzl at openjdk.org  Wed Mar  1 11:38:14 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 1 Mar 2023 11:38:14 GMT
Subject: RFR: 8303418: Improve parameter and variable names in BitMap [v2]
In-Reply-To: <BgmgbttSgJTgNl0E_UNGTP8SWRKfwKjVRRLTA0q4xuc=.bd5be179-31dd-4157-b3df-accd0a9c3120@github.com>
References: <LkA8PloAB0eQanDBr7eWx9_5EG5-6WByhZk19NxVcEw=.34afb33b-5e55-44a9-93bd-d701b62679c6@github.com>
 <BgmgbttSgJTgNl0E_UNGTP8SWRKfwKjVRRLTA0q4xuc=.bd5be179-31dd-4157-b3df-accd0a9c3120@github.com>
Message-ID: <abReZF9HNyWPSQ0UDnkSI_tCu4KSoTW10c7unnAwSg0=.e8c46d3f-7dad-40fe-b797-9bd8f125b34a@github.com>

On Wed, 1 Mar 2023 06:08:33 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to names in BitMap.
>> 
>> - Parameters that designate a bit in a BitMap are named "bit".
>> - Parameters that designate a word in the underlying BitMap storage are named "word".
>> - Parameters that designate a range are named "beg" and "end" resp.
>> 
>> Added helper function `flipped_word` for use by `get_next_bit_impl`, replacing
>> the odd overload for `map`.
>> 
>> In `get_next_bit_impl`, prefixed the variables "index" and "limit" with
>> "word_" to make clear the units.
>> 
>> Testing:
>> mach5 tier1
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyrights

Lgtm.

It would be great to also fix the unusual spacing between method names and the parameter brackets (and the method body brackets) a little, but that can be a different issue.

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

Marked as reviewed by tschatzl (Reviewer).

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

From duke at openjdk.org  Wed Mar  1 11:59:07 2023
From: duke at openjdk.org (Jan Kratochvil)
Date: Wed, 1 Mar 2023 11:59:07 GMT
Subject: RFR: 8302191: Performance degradation for float/double modulo on
 Linux [v2]
In-Reply-To: <4A9Uw_YcF6d1bg751wsOJJeLT1Mfx8b6Ne5MUSUvdrs=.de62d0d6-ccdb-402c-94be-800328cc622d@github.com>
References: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
 <CR6FSWocHu8YjQQrPRqkOTetmbZ-WYHLZlEeWLbsVfM=.71d2e6bf-7a6c-488b-8c4f-b71d9df21044@github.com>
 <4A9Uw_YcF6d1bg751wsOJJeLT1Mfx8b6Ne5MUSUvdrs=.de62d0d6-ccdb-402c-94be-800328cc622d@github.com>
Message-ID: <dtXK0U4JMhTuMQKD3gK4-6ZIZAOAOGty4gXvBL1Q0_w=.a3ff3932-4d2e-4471-86ca-793acefdfeab@github.com>

On Mon, 27 Feb 2023 02:23:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Jan Kratochvil has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
>> 
>>   8302191: Performance degradation for float/double modulo on Linux
>
> src/hotspot/cpu/x86/sharedRuntime_x86.cpp line 97:
> 
>> 95: jne    1b        \n\
>> 96: "
>> 97:     :"=t"(retval)
> 
> This doesn't compile on Windows
> 
>  c:\sb\prod\1677461706\workspace\open\src\hotspot\cpu\x86\sharedRuntime_x86.cpp(97): error C2059: syntax error: ':'
> c:\sb\prod\1677461706\workspace\open\src\hotspot\cpu\x86\sharedRuntime_x86.cpp(114): error C2059: syntax error: ':'
> 
> I assume this asm is gcc based.

Thanks for reporting it, I am no longer providing the asm variant on any Windows platform.

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

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

From duke at openjdk.org  Wed Mar  1 12:03:54 2023
From: duke at openjdk.org (Jan Kratochvil)
Date: Wed, 1 Mar 2023 12:03:54 GMT
Subject: RFR: 8302191: Performance degradation for float/double modulo on
 Linux [v5]
In-Reply-To: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
References: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
Message-ID: <o8gBuzq9Pfc4aYnmo3cPGXwVo4cbouH0delXsoz4kEI=.7a6c9412-f7c4-4c07-91ea-8cb5c0b9da6a@github.com>

> I have OCA already processed/approved. I am not Author but my Author request is being processed these days (sent to Rob McKenna).
> I did regression test x86_64 OpenJDK-8. I will leave other regression testing on GHA.
> The patch (and former GCC performance regression) affects only x86_64+i686.

Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:

  Fix copyright author.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12508/files
  - new: https://git.openjdk.org/jdk/pull/12508/files/4b7756f3..a04ee993

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

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

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

From duke at openjdk.org  Wed Mar  1 12:03:59 2023
From: duke at openjdk.org (Jan Kratochvil)
Date: Wed, 1 Mar 2023 12:03:59 GMT
Subject: RFR: 8302191: Performance degradation for float/double modulo on
 Linux [v2]
In-Reply-To: <jOXvH6Ozm5_xK1bEYzdvgkUAbgP4pu0aonYxbA0itNo=.a7ffbdf6-fba5-49c0-bd63-3996ea317ec4@github.com>
References: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
 <CR6FSWocHu8YjQQrPRqkOTetmbZ-WYHLZlEeWLbsVfM=.71d2e6bf-7a6c-488b-8c4f-b71d9df21044@github.com>
 <jOXvH6Ozm5_xK1bEYzdvgkUAbgP4pu0aonYxbA0itNo=.a7ffbdf6-fba5-49c0-bd63-3996ea317ec4@github.com>
Message-ID: <lf2CixC8YTB2GtTRSr2_vT8TPYzUaThBZjVHFw_umdA=.b3e15a1c-db4e-4798-996d-cc4249f65df7@github.com>

On Mon, 27 Feb 2023 01:01:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Jan Kratochvil 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:
>> 
>>   8302191: Performance degradation for float/double modulo on Linux
>
> test/micro/org/openjdk/bench/vm/floatingpoint/DremFrem.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2023 Oracle and/or its affiliates. All rights reserved.
> 
> Oracle did not write this code so it should have your own copyright on it, unless you copied it from other OpenJDK code in which case it could have dual copyright.

I have put there Azul now.

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

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

From iklam at openjdk.org  Wed Mar  1 12:30:05 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 1 Mar 2023 12:30:05 GMT
Subject: RFR: JDK-8302989: Add missing INCLUDE_CDS checks [v2]
In-Reply-To: <Rr2AaOX0OnWVBM3-GqzimZpF_T1m4XVLh7o_cnRFyLI=.318bc73f-61e2-4347-b119-74d908d963ff@github.com>
References: <kBV8fNo_CWJL2MoXgAckFhuAFgQ3RGZjFKAKnl8xfV8=.233bb652-8508-4065-92ea-7873b1c765f3@github.com>
 <kC0i6N44wUExbim6e2SCu5QCCpEGxRTEeRCGMRe__Fs=.46f19345-c54b-4e9b-bd8d-5c38dc4846a1@github.com>
 <D94A_iYhqCAvpWC87xWqEIAs7DQtw68zdetsZQc5pQ8=.8a39311a-60b2-4d83-969e-f48a74278d5b@github.com>
 <Rr2AaOX0OnWVBM3-GqzimZpF_T1m4XVLh7o_cnRFyLI=.318bc73f-61e2-4347-b119-74d908d963ff@github.com>
Message-ID: <BuCxJoq8h8XasiTZ_6foYa1BJ0BI7h4vyQik68Gct7E=.2b5745de-9059-4aa5-a196-43c15a5122ec@github.com>

On Wed, 1 Mar 2023 11:26:51 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> src/hotspot/share/utilities/globalDefinitions.hpp line 594:
>> 
>>> 592: #else
>>> 593: // in non CDS mode do not export it
>>> 594: extern const bool UseSharedSpaces;
>> 
>> How about this?
>> 
>> 
>> const bool RequireSharedSpaces = false;
>> 
>> 
>> This will allow the C++ compiler to eliminate all code that depend on this value when `INCLUDE_CDS` is false.
>
> Hi Ioi, I set this already some lines above (in the non-INCLUDE_CDS case).

You need to remove the `extern` keyword, and add the definition of `= false` in globalDefinitions.hpp.

Then, the corresponding definition should be removed from globalDefinitions.cpp.

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

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

From duke at openjdk.org  Wed Mar  1 12:41:05 2023
From: duke at openjdk.org (Johannes Bechberger)
Date: Wed, 1 Mar 2023 12:41:05 GMT
Subject: RFR: 8303444: AsyncGetCallTrace obtains too few frames with
 instrumentation agent
Message-ID: <rAvZDo493q-tR1yf02t2ObLyUzt5DVpd90g1GogCNW8=.19d9c95f-38b0-4acc-8411-8494ced5079f@github.com>

This fixes the bug by removing the faulty completeness check for runtime blobs.

I tested it using the [trace_validation](https://github.com/parttimenerd/trace_validation) tool successfully as described in the issue. I furthermore ran the [jdk-profiling-tester](https://github.com/parttimenerd/jdk-profiling-tester) to ensure that this fix did not introduce any stability issues and ran the serviceability JTREG tests successfully.

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

Commit messages:
 - Don't check for completeness of runtime stubs

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

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

From coleenp at openjdk.org  Wed Mar  1 12:42:10 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 1 Mar 2023 12:42:10 GMT
Subject: RFR: 8292059: Do not inline InstanceKlass::allocate_instance()
In-Reply-To: <ZSJBTzuC4wVuKdqSLLTgw4Pds2oX5wah0Ub6rFux_tc=.c4e2ae89-cadb-4ccd-9eee-034583cf7200@github.com>
References: <ZSJBTzuC4wVuKdqSLLTgw4Pds2oX5wah0Ub6rFux_tc=.c4e2ae89-cadb-4ccd-9eee-034583cf7200@github.com>
Message-ID: <9ZXi9uNa5ETIhldKLCDAYojtXTGEg-5EexLwHNE2zhI=.026815b3-3117-4184-be4c-5fdf42c2655f@github.com>

On Tue, 28 Feb 2023 11:11:54 GMT, Afshin Zafari <duke at openjdk.org> wrote:

> The inline and not-inline versions of the method is stress tested to compare the performance difference. The statistics are drawn in the following charts. The vertical axis is in milliseconds.
> 
> ![chart (2)](https://user-images.githubusercontent.com/4697012/221848555-2884313e-9d26-41c9-a265-3f1ce295b17b.png)
> 
> ![chart (3)](https://user-images.githubusercontent.com/4697012/221863810-94118677-b4af-468f-90c6-5ea365ae3588.png)

I don't know about these numbers but if this is not a neutral change for performance based on looking at the code and callers, I don't know what is.

src/hotspot/share/oops/instanceKlass.inline.hpp line 188:

> 186: }
> 187: 
> 188: inline instanceOop InstanceKlass::allocate_instance(oop java_class, TRAPS) {

In moving this, can you eliminate any #includes at the top?  And migrate them to .cpp files that might need them.

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

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

From epeter at openjdk.org  Wed Mar  1 12:59:09 2023
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 1 Mar 2023 12:59:09 GMT
Subject: RFR: 8302144: Move ZeroTLABTest.java to tier3 [v2]
In-Reply-To: <tkH4cUsQm94XMhtBzBcn6kXWkDmpEM9EYJwM0fmEzPM=.beecbd13-23b2-40eb-8d3c-841fcc6d3484@github.com>
References: <tkH4cUsQm94XMhtBzBcn6kXWkDmpEM9EYJwM0fmEzPM=.beecbd13-23b2-40eb-8d3c-841fcc6d3484@github.com>
Message-ID: <PXhQNLCIjh_gtdoqOvLZEhwK94F77vQ5AgLBkBYrwpE=.59f6aee6-d8f1-4837-b9ae-21a0bc510c62@github.com>

> This is a "Hello World" test for the flags `UseTLAB` and `ZeroTLAB`, running with `-Xcomp`. It takes about 30seconds.
> This test does not need to run on `tier1`. So I pushed it out to `tier3`.
> 
> Moved it to tier3, by adding it to hotspot_slow_compiler, which is excluded from tier1 and tier2.

Emanuel Peter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - merge from master
 - 8302144: Move ZeroTLABTest.java to tier3

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

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

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

From jvernee at openjdk.org  Wed Mar  1 13:06:09 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 1 Mar 2023 13:06:09 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v3]
In-Reply-To: <QMh_faUf_LLUf68WrZiFxmPHiFcHDBfKDg3g-oekBeg=.096acd06-65c4-4357-ad4a-4089b5478fff@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com>
 <HT8kQfjS98dYHeAMcNL5latokRiw3YK8npxl5yCD4hw=.28b19bac-cbfa-4461-a1db-c899c55b7485@github.com>
 <wBVqRDFM23KM8fjjPtUFNdW56FYsSpvOAVvHmpdjbzo=.7c429606-ac19-4f36-8e25-459534983924@github.com>
 <QMh_faUf_LLUf68WrZiFxmPHiFcHDBfKDg3g-oekBeg=.096acd06-65c4-4357-ad4a-4089b5478fff@github.com>
Message-ID: <rN8d70AKZqqg81BhJl2lsd4SXUOSyMqziBec_T_nKu4=.f31e048f-5ca6-44d9-95a8-5f3d1ff85ef6@github.com>

On Wed, 1 Mar 2023 06:37:45 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> There will surely be more when looking into Big Endian support after merging with your recent work on https://github.com/openjdk/panama-foreign/compare/foreign-memaccess+abi...JornVernee:panama-foreign:OOB

I will try to move this into the mainline ahead of the JEP PR (process allowing). As well as another testing coverage patch for nested structs/unions: https://github.com/openjdk/panama-foreign/pull/780.

> Thanks for sharing your plans to intrisify linkToNative in C2 later. I guess we should do more preparation work on all platforms when that gets addressed.

WRT this: we had intrinsification in the past as well (https://github.com/openjdk/panama-foreign/pull/609), but it was removed since we also removed 'trivial' calls at some point (and then the intrinsics were not used). Now that trivial calls are back on the menu, it might be interesting to look at re-adding intrinsics as well.

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

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

From mdoerr at openjdk.org  Wed Mar  1 13:06:13 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 1 Mar 2023 13:06:13 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v3]
In-Reply-To: <ubsdQFbNzTtdhNeZwCJyA5BRc2mR4AmQwk6hgJOlBy0=.6974c426-eeb2-4212-8038-9a8e00a0e7de@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com>
 <ubsdQFbNzTtdhNeZwCJyA5BRc2mR4AmQwk6hgJOlBy0=.6974c426-eeb2-4212-8038-9a8e00a0e7de@github.com>
Message-ID: <mo8rpizKpaAts6jpIZaQjgBZkCZE7uZaxaBW2j6mNxw=.4834669e-db31-4989-85d1-8bf94aabf651@github.com>

On Tue, 28 Feb 2023 20:51:50 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove size restriction for structs. Add TODO for Big Endian.
>
> src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/CallArranger.java line 68:
> 
>> 66: public abstract class CallArranger {
>> 67:     // Linux PPC64 Little Endian uses ABI v2.
>> 68:     private static final boolean useABIv2 = ByteOrder.nativeOrder() == ByteOrder.LITTLE_ENDIAN;
> 
> Now that I'm here. This could be a potentially interesting case for having 2 subclasses of CallArranger: one for `useABIv2 == true` and one for `false`.

Yeah, let's wait until we know what changes we need for AIX (and Big Endian linux).

> src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/CallArranger.java line 293:
> 
>> 291:                 } else {
>> 292:                     overlappingReg = new VMStorage(StorageType.STACK_AND_FLOAT,
>> 293:                                                    (short) STACK_SLOT_SIZE, (int) stackOffset - 4);
> 
> I think you could remove the mixed VMStorage types here relatively easily by returning a `VMStorage[][]`, where each element is a single element array, but then for the `needOverlapping` case add another element to the array for the extra store (instead of replacing the existing one).
> 
> Then when unboxing a `STRUCT_HFA`,  `dup` the result of the `bufferLoad` and then do 2 `vmStore`s (one for each element).
> 
> For boxing, you could just ignore the extra storage, and just `vmLoad` the first one (or, whichever one you like :))

Thanks! I need to find extra time for this. Sounds like a good idea and I may be able to get rid of some nasty code.

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

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

From simonis at openjdk.org  Wed Mar  1 13:39:04 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Wed, 1 Mar 2023 13:39:04 GMT
Subject: RFR: 8302783: Improve CRC32C intrinsic with crypto pmull on
 AArch64
In-Reply-To: <W21GIbXjV68chGAqGzNItlNHLh4l5O72uyonPlsmzZ8=.02147b96-9a7c-49ae-88f0-f12f2143b7c5@github.com>
References: <W21GIbXjV68chGAqGzNItlNHLh4l5O72uyonPlsmzZ8=.02147b96-9a7c-49ae-88f0-f12f2143b7c5@github.com>
Message-ID: <FpjvYxp7kwbpE54FxaCF84hQLPHQYbZuW-PC9wlYzBA=.7473420f-5c42-493c-84fc-f2cf5984a3b7@github.com>

On Fri, 17 Feb 2023 19:59:24 GMT, Yi-Fan Tsai <duke at openjdk.org> wrote:

> This change adds a pmull-based CRC32C intrinsic, and it is more performant than the existing crc32c-instruction-based intrinsic on Neoverse V1. The benchmark shows 10 - 99% improvement. The improvement comes from the execution throughput increase of pmull/pmull2 from 1 on Neoverse N1 to 4 on Neoverse V1 while the latency remains 2 while the throughput of CRC32C instructions did not changed. 
> 
> The pmull-based CRC32C intrinsic is enabled by the existing option UseCryptoPmullForCRC32 which also enables the pmull-based CRC32 intrinsic. The option requires crc32c instructions, eor3 in SHA3, and 64-bit pmull/pmull2 in Cryptographic Extension.
> 
> With this change, there will be only two different CRC32C intrinsics, crc32c and pmull, while there are four CRC32 intrinsics.
> 
> The following test has passed.
> test/hotspot/jtreg/compiler/intrinsics/zip/TestCRC32C.java
> 
> The throughput reported by [the micro benchmark](https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/java/util/TestCRC32C.java) is measured on an EC2 c7g instance. The optimization shows 10 - 99% improvement when the input is at least 384 bytes.
> 
> | input               | 64         | 128        | 256        | 384        | 511        | 512        | 1,024      |
> | ------------- | ---------- | ---------- | ---------- | ---------- | ---------- | ---------- | ---------- |
> |  improvement  | 1.60%      | 0.00%      | 0.00%      | 15.24%     | 10.76%     | 34.32%     | 72.39%     |
> 
> | input               | 2,048      | 4,096      | 8,192      | 16,384     | 32,768     | 65,536     |
> | ------------- | ---------- | ---------- | ---------- | ---------- | ---------- | ---------- |
> |  improvement  | 84.96%     | 92.59%     | 96.19%     | 98.02%     | 99.32%     | 98.36%     |
> 
> 
> Baseline
> 
> Benchmark                    (count)   Mode  Cnt       Score      Error   Units
> TestCRC32C.testCRC32CUpdate       64  thrpt   12  196575.739 ? 1824.113  ops/ms
> TestCRC32C.testCRC32CUpdate      128  thrpt   12  123666.570 ?    2.730  ops/ms
> TestCRC32C.testCRC32CUpdate      256  thrpt   12   70188.989 ?    2.002  ops/ms
> TestCRC32C.testCRC32CUpdate      384  thrpt   12   49000.690 ?    1.421  ops/ms
> TestCRC32C.testCRC32CUpdate      511  thrpt   12   34106.279 ?   25.390  ops/ms
> TestCRC32C.testCRC32CUpdate      512  thrpt   12   37638.349 ?    1.039  ops/ms
> TestCRC32C.testCRC32CUpdate     1024  thrpt   12   19526.513 ?    0.439  ops/ms
> TestCRC32C.testCRC32CUpdate     2048  thrpt   12    9951.392 ?    4.803  ops/ms
> TestCRC32C.testCRC32CUpdate     4096  thrpt   12    5023.268 ?    0.240  ops/ms
> TestCRC32C.testCRC32CUpdate     8192  thrpt   12    2523.877 ?    0.062  ops/ms
> TestCRC32C.testCRC32CUpdate    16384  thrpt   12    1265.011 ?    0.047  ops/ms
> TestCRC32C.testCRC32CUpdate    32768  thrpt   12     632.291 ?    0.058  ops/ms
> TestCRC32C.testCRC32CUpdate    65536  thrpt   12     315.396 ?    0.160  ops/ms
> 
> 
> Crypto pmull
> 
> Benchmark                    (count)   Mode  Cnt       Score     Error   Units
> TestCRC32C.testCRC32CUpdate       64  thrpt   12  199726.599 ? 166.477  ops/ms
> TestCRC32C.testCRC32CUpdate      128  thrpt   12  123669.385 ?   1.821  ops/ms
> TestCRC32C.testCRC32CUpdate      256  thrpt   12   70188.727 ?   1.313  ops/ms
> TestCRC32C.testCRC32CUpdate      384  thrpt   12   56468.837 ?  76.524  ops/ms
> TestCRC32C.testCRC32CUpdate      511  thrpt   12   37777.205 ? 406.431  ops/ms
> TestCRC32C.testCRC32CUpdate      512  thrpt   12   50554.555 ?  17.169  ops/ms
> TestCRC32C.testCRC32CUpdate     1024  thrpt   12   33661.006 ? 140.471  ops/ms
> TestCRC32C.testCRC32CUpdate     2048  thrpt   12   18406.482 ? 205.952  ops/ms
> TestCRC32C.testCRC32CUpdate     4096  thrpt   12    9674.159 ?  20.390  ops/ms
> TestCRC32C.testCRC32CUpdate     8192  thrpt   12    4951.562 ?   6.566  ops/ms
> TestCRC32C.testCRC32CUpdate    16384  thrpt   12    2504.970 ?   1.883  ops/ms
> TestCRC32C.testCRC32CUpdate    32768  thrpt   12    1260.278 ?   0.484  ops/ms
> TestCRC32C.testCRC32CUpdate    65536  thrpt   12     625.608 ?   0.300  ops/ms

Change looks good.

Thanks,
Volker

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

Marked as reviewed by simonis (Reviewer).

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

From duke at openjdk.org  Wed Mar  1 14:38:03 2023
From: duke at openjdk.org (Johannes Bechberger)
Date: Wed, 1 Mar 2023 14:38:03 GMT
Subject: RFR: 8303444: AsyncGetCallTrace obtains too few frames with
 instrumentation agent
In-Reply-To: <rAvZDo493q-tR1yf02t2ObLyUzt5DVpd90g1GogCNW8=.19d9c95f-38b0-4acc-8411-8494ced5079f@github.com>
References: <rAvZDo493q-tR1yf02t2ObLyUzt5DVpd90g1GogCNW8=.19d9c95f-38b0-4acc-8411-8494ced5079f@github.com>
Message-ID: <fA9u1Mnrm2u8Ax9WMEVeh2upz1fLzKSDgy2oosKmnhY=.445090b3-327d-4eda-81bb-f018a363ef07@github.com>

On Wed, 1 Mar 2023 12:32:19 GMT, Johannes Bechberger <duke at openjdk.org> wrote:

> This fixes the bug by removing the faulty completeness check for runtime blobs.
> 
> I tested it using the [trace_validation](https://github.com/parttimenerd/trace_validation) tool successfully as described in the issue. I furthermore ran the [jdk-profiling-tester](https://github.com/parttimenerd/jdk-profiling-tester) to ensure that this fix did not introduce any stability issues and ran the serviceability JTREG tests successfully.

The problem seems to stem from runtime stubs generated for GC load barriers. These stubs are marked with a `frame_never_safe` value for `_frame_complete_offset`. This then causes `is_frame_complete_at` to return always false for these codeblobs. It might be that there were problems in the past (before 2008) with walking over these frames, but neither GetStackTrace nor the the current implementation of AsyncGetCallTrace have any problems.

It might be that walking over these frames got only implemented in the recent years.

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

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

From jcking at openjdk.org  Wed Mar  1 15:53:25 2023
From: jcking at openjdk.org (Justin King)
Date: Wed, 1 Mar 2023 15:53:25 GMT
Subject: RFR: JDK-8300783: Consolidate byteswap implementations [v14]
In-Reply-To: <-b783DPmWbWFeigKf7F7SFYddDKwErM4AdFcfRx01eM=.5794fa08-a0d7-4761-a449-8ebfd639e30d@github.com>
References: <MLBMwI7xt4IKgpb3AHXJ_J11Ibhijp_q2RFtLJOwHpA=.b7da6b6b-69b8-426d-8eab-c7c3aaa0847e@github.com>
 <-b783DPmWbWFeigKf7F7SFYddDKwErM4AdFcfRx01eM=.5794fa08-a0d7-4761-a449-8ebfd639e30d@github.com>
Message-ID: <9Z_vNHvdrpNCZriJVv4fmLju4PTmAMPHeJ5sEJ5OsTI=.6b1e1bbf-b3b4-4fa5-9b1c-c61eb8f0459b@github.com>

On Wed, 15 Feb 2023 15:39:14 GMT, Justin King <jcking at openjdk.org> wrote:

>> Deduplicate byte swapping implementations by consolidating them into `utilities/byteswap.hpp`, following `std::byteswap` introduced in C++23. Further simplification of `Bytes` will follow in https://github.com/openjdk/jdk/pull/12078.
>
> Justin King 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:
> 
>  - Merge remote-tracking branch 'upstream/master' into byteswap
>  - Update based on review
>    
>    Signed-off-by: Justin King <jcking at google.com>
>  - Fix copyright
>    
>    Signed-off-by: Justin King <jcking at google.com>
>  - Update copyright
>    
>    Signed-off-by: Justin King <jcking at google.com>
>  - Add missing include
>    
>    Signed-off-by: Justin King <jcking at google.com>
>  - Remove unused include
>    
>    Signed-off-by: Justin King <jcking at google.com>
>  - Reorganize tests
>    
>    Signed-off-by: Justin King <jcking at google.com>
>  - Fix test
>    
>    Signed-off-by: Justin King <jcking at google.com>
>  - Merge remote-tracking branch 'upstream/master' into byteswap
>  - Be restrict on requiring 1, 2, 4, or 8 byte integers
>    
>    Signed-off-by: Justin King <jcking at google.com>
>  - ... and 14 more: https://git.openjdk.org/jdk/compare/a469507d...223d733b

Friendly poke for a second reviewer.

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

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

From kvn at openjdk.org  Wed Mar  1 17:37:16 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 1 Mar 2023 17:37:16 GMT
Subject: RFR: 8302144: Move ZeroTLABTest.java to tier3 [v2]
In-Reply-To: <PXhQNLCIjh_gtdoqOvLZEhwK94F77vQ5AgLBkBYrwpE=.59f6aee6-d8f1-4837-b9ae-21a0bc510c62@github.com>
References: <tkH4cUsQm94XMhtBzBcn6kXWkDmpEM9EYJwM0fmEzPM=.beecbd13-23b2-40eb-8d3c-841fcc6d3484@github.com>
 <PXhQNLCIjh_gtdoqOvLZEhwK94F77vQ5AgLBkBYrwpE=.59f6aee6-d8f1-4837-b9ae-21a0bc510c62@github.com>
Message-ID: <0J9V3m35smWUpAttCIwF-r86K0Br3a6lsj0Btim0eIg=.606b25c8-b1f2-4358-9c9a-3f4541017fc5@github.com>

On Wed, 1 Mar 2023 12:59:09 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> This is a "Hello World" test for the flags `UseTLAB` and `ZeroTLAB`, running with `-Xcomp`. It takes about 30seconds.
>> This test does not need to run on `tier1`. So I pushed it out to `tier3`.
>> 
>> Moved it to tier3, by adding it to hotspot_slow_compiler, which is excluded from tier1 and tier2.
>
> Emanuel Peter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - merge from master
>  - 8302144: Move ZeroTLABTest.java to tier3

Agree.

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

Marked as reviewed by kvn (Reviewer).

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

From dnsimon at openjdk.org  Wed Mar  1 18:38:19 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 1 Mar 2023 18:38:19 GMT
Subject: RFR: 8303431: [JVMCI] libgraal annotation API
Message-ID: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>

This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for accessing annotations. The main differences from `java.lang.reflect.AnnotatedElement` are:
* Each `Annotated` method explicitly specifies the annotation type(s) for which it wants annotation data. That is, there is no direct equivalent of `AnnotatedElement.getAnnotations()`.
* Annotation data is returned in a map-like object (of type `jdk.vm.ci.meta.AnnotationData`) instead of in an `Annotation` object. This works better for libgraal as it avoids the need for annotation types to be loaded and included in libgraal.
 
To demonstrate the new API, here's an example in terms `java.lang.reflect.AnnotatedElement` (which `ResolvedJavaType` implements):

    ResolvedJavaMethod method = ...;
    ExplodeLoop a = method.getAnnotation(ExplodeLoop.class);
    return switch (a.kind()) {
        case FULL_UNROLL -> LoopExplosionKind.FULL_UNROLL;
        case FULL_UNROLL_UNTIL_RETURN -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
        ...
    }


The same code using the new API:


    ResolvedJavaMethod method = ...;
    ResolvedJavaType explodeLoopType = ...;
    AnnotationData a = method.getAnnotationDataFor(explodeLoopType);
    return switch (a.getEnum("kind").getName()) {
        case "FULL_UNROLL" -> LoopExplosionKind.FULL_UNROLL;
        case "FULL_UNROLL_UNTIL_RETURN" -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
        ...
    }


The implementation relies on new methods in `jdk.internal.vm.VMSupport` for parsing annotations and serializing/deserializing to/from a byte array. This allows the annotation data to be passed from the HotSpot heap to the libgraal heap.

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

Commit messages:
 - made AnnotationDataDecoder package-private
 - add annotation API to JVMCI

Changes: https://git.openjdk.org/jdk/pull/12810/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12810&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303431
  Stats: 2666 lines in 33 files changed: 2614 ins; 24 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/12810.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12810/head:pull/12810

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

From redestad at openjdk.org  Wed Mar  1 19:15:10 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 1 Mar 2023 19:15:10 GMT
Subject: RFR: 8292059: Do not inline InstanceKlass::allocate_instance()
In-Reply-To: <ZSJBTzuC4wVuKdqSLLTgw4Pds2oX5wah0Ub6rFux_tc=.c4e2ae89-cadb-4ccd-9eee-034583cf7200@github.com>
References: <ZSJBTzuC4wVuKdqSLLTgw4Pds2oX5wah0Ub6rFux_tc=.c4e2ae89-cadb-4ccd-9eee-034583cf7200@github.com>
Message-ID: <-W9KBy9yRFPK3L5GHdhGkkHE1YRqh--NNuRFgPnpVx4=.e4459e3a-fb59-4f57-a05d-7445abf182aa@github.com>

On Tue, 28 Feb 2023 11:11:54 GMT, Afshin Zafari <duke at openjdk.org> wrote:

> The inline and not-inline versions of the method is stress tested to compare the performance difference. The statistics are drawn in the following charts. The vertical axis is in milliseconds.
> 
> ![chart (2)](https://user-images.githubusercontent.com/4697012/221848555-2884313e-9d26-41c9-a265-3f1ce295b17b.png)
> 
> ![chart (3)](https://user-images.githubusercontent.com/4697012/221863810-94118677-b4af-468f-90c6-5ea365ae3588.png)

I'm also skeptical as to the relevance of these numbers. `allocate_instance(oop, TRAPS)` is nowhere near GC code, so my guess is that there's run-to-run variation on whatever the workload is here.

I'm not against removing this inlining. I did it as a minor part of another startup optimization after checking that the inlining was size-neutral and noticing that this meant a speed-up in interpreter and C1 for some relatively common JNI calls. It might still be marginally beneficial there, but if there's a measurable impact on compilation time and header complexity then who am I to object.

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

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

From stuefe at openjdk.org  Wed Mar  1 21:03:25 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 1 Mar 2023 21:03:25 GMT
Subject: RFR: 8302798: Refactor -XX:+UseOSErrorReporting for noreturn crash
 reporting
In-Reply-To: <UlxG5APPvP9qCUgXX2R6hkkvjIFG6RyR0ZzDIn4sFQA=.a5881b29-aa4a-42c4-8a5f-d17d915f8d55@github.com>
References: <elVA1mzItfJ7bnnfSpEUVprtbnnSx1zT_eoXnV2sviU=.13e2d4dc-74b0-4051-8852-04caf2c81196@github.com>
 <mzNaNRLgW8d35UdZT2KTJaO5t3W2l3jEAQPOgVROfJY=.2132f50d-e3e7-43b9-bf0c-0b899d4a1a63@github.com>
 <UlxG5APPvP9qCUgXX2R6hkkvjIFG6RyR0ZzDIn4sFQA=.a5881b29-aa4a-42c4-8a5f-d17d915f8d55@github.com>
Message-ID: <tEjUNu2u7CyxacnebE-hY5RBad-YxqFaWIl5e6Gnh4Q=.d44ef973-5993-40b6-8637-83e512395b4b@github.com>

On Mon, 27 Feb 2023 12:27:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > So ... this approach skips the VM error reporting and goes straight to WER?
> 
> Strike that - no it doesn't. Okay I have to admit I'm not at all clear on what the existing unwinding process actually looks like, and how the new fix affects that.

I don't think there is unwinding as we know it (calling destructors etc). IIRC on x64 there is a chain of data structures that correlate with stack levels, and each data structure is associated with a range of PCs. On crash the code just locates the correct data structure for the crash PC, grabs the exception handler address from that structure and invokes that. If that handler returns "CONTINUE_SEARCH" it walks the chain up to the next data structure and invokes that. With this patch we don't return CONTINUE_SEARCH anymore but end the process right away.

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

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

From dholmes at openjdk.org  Thu Mar  2 04:05:15 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 2 Mar 2023 04:05:15 GMT
Subject: RFR: 8302191: Performance degradation for float/double modulo on
 Linux [v5]
In-Reply-To: <o8gBuzq9Pfc4aYnmo3cPGXwVo4cbouH0delXsoz4kEI=.7a6c9412-f7c4-4c07-91ea-8cb5c0b9da6a@github.com>
References: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
 <o8gBuzq9Pfc4aYnmo3cPGXwVo4cbouH0delXsoz4kEI=.7a6c9412-f7c4-4c07-91ea-8cb5c0b9da6a@github.com>
Message-ID: <OoYoMXL5HyAVVvSpbj-lqGeOb9xNPKSVdQHDlYVr9Wo=.36a530a9-1921-4e92-8bb7-be8a48f02448@github.com>

On Wed, 1 Mar 2023 12:03:54 GMT, Jan Kratochvil <duke at openjdk.org> wrote:

>> I have OCA already processed/approved. I am not Author but my Author request is being processed these days (sent to Rob McKenna).
>> I did regression test x86_64 OpenJDK-8. I will leave other regression testing on GHA.
>> The patch (and former GCC performance regression) affects only x86_64+i686.
>
> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright author.

You can't move the _WIN64 workaround to the sharedRuntime_x86.cpp file as that code is also used by Windows-Aarch64. Whether it needs the workaround or not is another matter, but unless proven otherwise we have to assume it does.

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

Changes requested by dholmes (Reviewer).

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

From mdoerr at openjdk.org  Thu Mar  2 04:48:43 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 2 Mar 2023 04:48:43 GMT
Subject: RFR: 8303210: [linux, Windows] Enable UseSystemMemoryBarrier by
 default if possible [v4]
In-Reply-To: <9eZo1xYNGhjMSC9lDXKtkO1eyU_H-Veuh1AeP3CPKbg=.69b6c4ff-a3ef-439f-8468-21fec9de1825@github.com>
References: <9eZo1xYNGhjMSC9lDXKtkO1eyU_H-Veuh1AeP3CPKbg=.69b6c4ff-a3ef-439f-8468-21fec9de1825@github.com>
Message-ID: <_5_YBJ25wS7iSZHP3l3JCkDfsEwJAxOvb5TFYxogKQg=.f7fc4158-7519-4d64-811a-3bfdbe0d53e8@github.com>

> I'd like to enable UseSystemMemoryBarrier by default on supported Operating Systems in order to improve performance of thread state transitions (I/O, JNI, foreign function calls, JIT compiler threads, etc.). See JBS issue for more details.
> Unfortunately, the feature was not yet implemented on all platforms. I added the code, but need the platform maintainers to check if it can be used reliably (and ideally if the performance improves). It's easy to switch it off again in case of problems.

Martin Doerr has updated the pull request incrementally with two additional commits since the last revision:

 - Make it a regular product flag and keep it off by default.
 - Add includes for riscv.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12753/files
  - new: https://git.openjdk.org/jdk/pull/12753/files/4660291f..b7278798

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

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

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

From mdoerr at openjdk.org  Thu Mar  2 04:48:45 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 2 Mar 2023 04:48:45 GMT
Subject: RFR: 8303210: [linux, Windows] Enable UseSystemMemoryBarrier by
 default if possible [v3]
In-Reply-To: <UHryx0Oy89jQ9EdoTCjR4-oo0MKmoozbwPJU1kG4B7M=.cd00b793-5718-4a95-927e-89b6dd89731f@github.com>
References: <9eZo1xYNGhjMSC9lDXKtkO1eyU_H-Veuh1AeP3CPKbg=.69b6c4ff-a3ef-439f-8468-21fec9de1825@github.com>
 <osex7Bks3vqpGMHMyXfMH03l-KeyW6yR6Sq8CpKN09s=.d7f78abe-1c29-4bd4-89c3-d9bd777ab47e@github.com>
 <UHryx0Oy89jQ9EdoTCjR4-oo0MKmoozbwPJU1kG4B7M=.cd00b793-5718-4a95-927e-89b6dd89731f@github.com>
Message-ID: <4OUteKRXlzDsD5WYteulbdtGRZHLhZimdP-d9IWkEx4=.eb057247-54ba-4156-bd58-90049c36b544@github.com>

On Wed, 1 Mar 2023 07:00:34 GMT, Fei Yang <fyang at openjdk.org> wrote:

> bootcycle and tier1-3 test good on linux-riscv64 platform. I think it will be safer to explicitly include "runtime/globals.hpp":

Thanks for testing! Added the includes.

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

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

From mdoerr at openjdk.org  Thu Mar  2 04:48:45 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 2 Mar 2023 04:48:45 GMT
Subject: RFR: 8303210: [linux, Windows] Enable UseSystemMemoryBarrier by
 default if possible [v3]
In-Reply-To: <osex7Bks3vqpGMHMyXfMH03l-KeyW6yR6Sq8CpKN09s=.d7f78abe-1c29-4bd4-89c3-d9bd777ab47e@github.com>
References: <9eZo1xYNGhjMSC9lDXKtkO1eyU_H-Veuh1AeP3CPKbg=.69b6c4ff-a3ef-439f-8468-21fec9de1825@github.com>
 <osex7Bks3vqpGMHMyXfMH03l-KeyW6yR6Sq8CpKN09s=.d7f78abe-1c29-4bd4-89c3-d9bd777ab47e@github.com>
Message-ID: <OWdIGAPxlYfFAAUX_ylx4eFFVKSUUBZEKymxa4W8X_4=.51aedcbf-7cbd-4753-b4e5-e6465cc9b31a@github.com>

On Tue, 28 Feb 2023 05:26:22 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> I'd like to enable UseSystemMemoryBarrier by default on supported Operating Systems in order to improve performance of thread state transitions (I/O, JNI, foreign function calls, JIT compiler threads, etc.). See JBS issue for more details.
>> Unfortunately, the feature was not yet implemented on all platforms. I added the code, but need the platform maintainers to check if it can be used reliably (and ideally if the performance improves). It's easy to switch it off again in case of problems.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve logging.

I have made it a regular product flag and keep it off by default. I'll need a CSR, now.

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

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

From mdoerr at openjdk.org  Thu Mar  2 06:43:15 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 2 Mar 2023 06:43:15 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v6]
In-Reply-To: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
Message-ID: <iRXiOJgPjsuml_7oD_bJgUFt_a36KK78oI-OFirRQ0o=.3b064e17-b15a-4e47-9656-9ebac2c36026@github.com>

> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
> 
> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
> 
> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
> 
> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Will get addressed separately: [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
> 
> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
> 
> I had to make changes to shared code and code for other platforms:
> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit.

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  Add test for HFA corner cases.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12708/files
  - new: https://git.openjdk.org/jdk/pull/12708/files/75b5c78f..c96e1120

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

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

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

From epeter at openjdk.org  Thu Mar  2 07:25:23 2023
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 2 Mar 2023 07:25:23 GMT
Subject: Integrated: 8302144: Move ZeroTLABTest.java to tier3
In-Reply-To: <tkH4cUsQm94XMhtBzBcn6kXWkDmpEM9EYJwM0fmEzPM=.beecbd13-23b2-40eb-8d3c-841fcc6d3484@github.com>
References: <tkH4cUsQm94XMhtBzBcn6kXWkDmpEM9EYJwM0fmEzPM=.beecbd13-23b2-40eb-8d3c-841fcc6d3484@github.com>
Message-ID: <wXy5VEyuAC6JbODTeW_yM7HTD3YK9cDxAKup4_f-Ro0=.9afcd2c3-04b8-46bd-9626-3c597bb802a8@github.com>

On Fri, 17 Feb 2023 16:09:31 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> This is a "Hello World" test for the flags `UseTLAB` and `ZeroTLAB`, running with `-Xcomp`. It takes about 30seconds.
> This test does not need to run on `tier1`. So I pushed it out to `tier3`.
> 
> Moved it to tier3, by adding it to hotspot_slow_compiler, which is excluded from tier1 and tier2.

This pull request has now been integrated.

Changeset: 99f5687e
Author:    Emanuel Peter <epeter at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/99f5687eb192b249a4a4533578f56b131fb8f234
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8302144: Move ZeroTLABTest.java to tier3

Reviewed-by: thartmann, kvn

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

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

From epeter at openjdk.org  Thu Mar  2 07:25:22 2023
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 2 Mar 2023 07:25:22 GMT
Subject: RFR: 8302144: Move ZeroTLABTest.java to tier3 [v2]
In-Reply-To: <9Zu7yAXxztPf84rwNxjbzcID97P5PRVj2k7WR8iRexE=.24646832-7270-464b-a221-920ef64bfc5a@github.com>
References: <tkH4cUsQm94XMhtBzBcn6kXWkDmpEM9EYJwM0fmEzPM=.beecbd13-23b2-40eb-8d3c-841fcc6d3484@github.com>
 <9Zu7yAXxztPf84rwNxjbzcID97P5PRVj2k7WR8iRexE=.24646832-7270-464b-a221-920ef64bfc5a@github.com>
Message-ID: <_dEm89ldxBNwxu_AKiPkO0dvpNQNjOu53exjemUT8fY=.ac1913e0-b321-40e3-8941-f36428a2af5b@github.com>

On Mon, 20 Feb 2023 07:32:34 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Emanuel Peter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - merge from master
>>  - 8302144: Move ZeroTLABTest.java to tier3
>
> Looks good.

Thanks @TobiHartmann @vnkozlov for the reviews!

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

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

From aboldtch at openjdk.org  Thu Mar  2 07:45:13 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 2 Mar 2023 07:45:13 GMT
Subject: RFR: 8303418: Improve parameter and variable names in BitMap [v2]
In-Reply-To: <BgmgbttSgJTgNl0E_UNGTP8SWRKfwKjVRRLTA0q4xuc=.bd5be179-31dd-4157-b3df-accd0a9c3120@github.com>
References: <LkA8PloAB0eQanDBr7eWx9_5EG5-6WByhZk19NxVcEw=.34afb33b-5e55-44a9-93bd-d701b62679c6@github.com>
 <BgmgbttSgJTgNl0E_UNGTP8SWRKfwKjVRRLTA0q4xuc=.bd5be179-31dd-4157-b3df-accd0a9c3120@github.com>
Message-ID: <Mj9wTL7rJi--QE4yNXE4y2L5-eqoYDiuaMK8mGrs2ow=.07d4502e-52a9-42be-8e2f-9583ed19bd3e@github.com>

On Wed, 1 Mar 2023 06:08:33 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to names in BitMap.
>> 
>> - Parameters that designate a bit in a BitMap are named "bit".
>> - Parameters that designate a word in the underlying BitMap storage are named "word".
>> - Parameters that designate a range are named "beg" and "end" resp.
>> 
>> Added helper function `flipped_word` for use by `get_next_bit_impl`, replacing
>> the odd overload for `map`.
>> 
>> In `get_next_bit_impl`, prefixed the variables "index" and "limit" with
>> "word_" to make clear the units.
>> 
>> Testing:
>> mach5 tier1
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyrights

Nice to see a _bit_ more consistency in the parameter names here.

Not 100% sold on the use of `bit` for a single bit index. But at least consistency makes it clearer. 

As long as `beg` and `end` are used for `[beg,end)` ranges then the names are appropriate. If they ever start to deviate from the `std::begin` and `std::end` semantics they should be changed to avoid confusion.

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

Marked as reviewed by aboldtch (Committer).

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

From duke at openjdk.org  Thu Mar  2 07:57:00 2023
From: duke at openjdk.org (Amit Kumar)
Date: Thu, 2 Mar 2023 07:57:00 GMT
Subject: RFR: 8302328: [s390x] Simplify asm_assert definition
Message-ID: <51VAVmniXPGE4sgcdw2AnU1hqZn2fVJRyDEbrt3AyyU=.b70f59dc-8397-4da4-b36b-266766434b19@github.com>

This PR cleanups some assert statements and specifies branch condition at calling site itself. Remaining asm_assert methods are inlined as well.

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

Commit messages:
 - added inline keyword before function implementation
 - inlined assert method
 - relocation code shortening
 - inline asm_assert
 - update header and cleanup
 - removed asm_assert{ne, high, low}
 - removed asm_assert_eq and asm_assert_static functionality
 - introduce branch conditions

Changes: https://git.openjdk.org/jdk/pull/12822/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12822&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302328
  Stats: 172 lines in 14 files changed: 50 ins; 79 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/12822.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12822/head:pull/12822

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

From sspitsyn at openjdk.org  Thu Mar  2 08:53:11 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 2 Mar 2023 08:53:11 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: <CKIA4ziqH3mQbJuq6hRo67KsdVImBqsTRyEATJ_qYOo=.8de47e82-6d4d-4d74-b55c-83deaaa13ad9@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

Need to keep this PR alive for a while.

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

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

From duke at openjdk.org  Thu Mar  2 08:54:06 2023
From: duke at openjdk.org (Amit Kumar)
Date: Thu, 2 Mar 2023 08:54:06 GMT
Subject: RFR: 8302328: [s390x] Simplify asm_assert definition
In-Reply-To: <51VAVmniXPGE4sgcdw2AnU1hqZn2fVJRyDEbrt3AyyU=.b70f59dc-8397-4da4-b36b-266766434b19@github.com>
References: <51VAVmniXPGE4sgcdw2AnU1hqZn2fVJRyDEbrt3AyyU=.b70f59dc-8397-4da4-b36b-266766434b19@github.com>
Message-ID: <zA0b__-tSg_NWqpUVaD0VaZ3kL7p4vwawfyiXDeW-fk=.eeeb06da-6ba3-49b4-bf1c-32e59d6986fa@github.com>

On Thu, 2 Mar 2023 07:49:05 GMT, Amit Kumar <duke at openjdk.org> wrote:

> This PR cleanups some assert statements and specifies branch condition at calling site itself. Remaining asm_assert methods are inlined as well.

@backwaterred @RealLucy @TheRealMDoerr 

please review & provide your suggestions :)

Thanks

It's an s390x-specific PR, So linux-x86 failures are not related.

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

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

From rcastanedalo at openjdk.org  Thu Mar  2 08:56:17 2023
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Thu, 2 Mar 2023 08:56:17 GMT
Subject: RFR: 8302780: Add support for vectorized arraycopy GC barriers
 [v6]
In-Reply-To: <3nz9PRPYzYVszMpwatVR3TbeFZsdT0jHpZ6lHqgJbSA=.12875265-8044-41c7-8e12-3b2851be8b08@github.com>
References: <SU-lpFUY3nGTCSM5k7HrOR2xGgNhPFRNDFUa6JBNEMQ=.2ceac514-334b-4201-8f7b-f17b9ebf3505@github.com>
 <47e5gQJkZn7ldGv3n2cyQoZSAT9YpWWvIwXnbxhdGuQ=.643a4652-204b-4689-85a4-9378e8a587b3@github.com>
 <44kCeVWFrSGQEcehVV5G_EowMs26zWcuv5KmDbYv9Mc=.f49cb445-de78-4932-aefc-1839fd0be611@github.com>
 <3nz9PRPYzYVszMpwatVR3TbeFZsdT0jHpZ6lHqgJbSA=.12875265-8044-41c7-8e12-3b2851be8b08@github.com>
Message-ID: <4GE8QumAJzRXPGKFAAXqOiJpM2fUTxfbSUKnQDnDOB0=.62c4e6f6-2063-488e-90a9-f4708bbf032a@github.com>

On Wed, 1 Mar 2023 10:51:53 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 1270:
>> 
>>> 1268:     Label copy4, copy8, copy16, copy32, copy80, copy_big, finish;
>>> 1269:     const Register t2 = r5, t3 = r6, t4 = r7, t5 = r11;
>>> 1270:     const Register t6 = r12, t7 = r13, t8 = r14, t9 = r15;
>> 
>> I find the usage of r15 in `copy_memory` a bit confusing. If I get it right, it is used
>> 1. as a temporary register (aliased as `t9`) for 16-bytes copying (L1407-1437),
>> 2. as a temporary register (in its raw form, i.e. not via `t9`) passed explicitly to `copy_memory_small` (L1518-1548), and
>> 3. as a "special" register passed implicitly to the generated `copy_longs` stubs (L1557-1574).
>> 
>> I think it would be clearer if `t9` was used instead of `r15` for case 2) and then perhaps a comment was added before calling the generated `copy_longs` stubs mentioning that `t9` cannot be used from then on because it aliases with `r15`.
>
> Since r15 is part of the ABI contract across different generated stubs, I'd prefer to not change it to t9 as when you scroll through the different functions, it isn't clear that t9 isn't just used locally as a temporary register, but is used across stubs, even though it isn't passed as parameter with the name "t9" said stubs. I did however add a comment explaining when we start using r15 is count and that we can't use t9 any more after that point. I hope that's okay.

The comment helps, thanks!

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

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

From rcastanedalo at openjdk.org  Thu Mar  2 09:18:26 2023
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Thu, 2 Mar 2023 09:18:26 GMT
Subject: RFR: 8302780: Add support for vectorized arraycopy GC barriers
 [v8]
In-Reply-To: <BWqOjj4KikZ2Mj14NNMdbAhMaY0rsj0289AEAQFqegw=.af04f90a-7548-4bfd-8399-ab5a763b8dd1@github.com>
References: <SU-lpFUY3nGTCSM5k7HrOR2xGgNhPFRNDFUa6JBNEMQ=.2ceac514-334b-4201-8f7b-f17b9ebf3505@github.com>
 <BWqOjj4KikZ2Mj14NNMdbAhMaY0rsj0289AEAQFqegw=.af04f90a-7548-4bfd-8399-ab5a763b8dd1@github.com>
Message-ID: <UrZD6IsIiDp9Fdqc2LPq5uZhrke-AEuZYeakmtAgjlA=.d89ec381-7fb0-4486-8b83-7a10536fc5bd@github.com>

On Wed, 1 Mar 2023 10:56:31 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> So far, the arraycopy stubs have performed some kind of bulk pre/post barriers for arraycopy, which have been good enough, and allowed the copying itself to be done with plain loads and stores. For generational ZGC, this approach is not good enough, and we need barriers for the actual copying, but instead don't need the pre/post barriers. To prepare the JVM for generational ZGC, we need to add an API for arraycopy barriers.
>
> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment about r15 useage

> All this extreme cut-and-paste manual unrolling is very hard to read, maintain, and review.
I wasn't going to say anything, because it's Erik, and what do I know! But I must push back here, this is too much.
Please consider these style changes.

In my opinion, the (very much needed) changes you suggest are outside the scope of this PR, which is about lifting the memory accesses, in their existing form, to a barrier API-level. Conflating this with your suggested changes would make it harder to review this PR, which is sufficiently complex in its current form. I totally agree that your suggestions would improve readability and maintainability, but couldn't we apply them in a follow-up RFE?

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

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

From kbarrett at openjdk.org  Thu Mar  2 09:34:12 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 2 Mar 2023 09:34:12 GMT
Subject: RFR: 8303418: Improve parameter and variable names in BitMap [v2]
In-Reply-To: <Mj9wTL7rJi--QE4yNXE4y2L5-eqoYDiuaMK8mGrs2ow=.07d4502e-52a9-42be-8e2f-9583ed19bd3e@github.com>
References: <LkA8PloAB0eQanDBr7eWx9_5EG5-6WByhZk19NxVcEw=.34afb33b-5e55-44a9-93bd-d701b62679c6@github.com>
 <BgmgbttSgJTgNl0E_UNGTP8SWRKfwKjVRRLTA0q4xuc=.bd5be179-31dd-4157-b3df-accd0a9c3120@github.com>
 <Mj9wTL7rJi--QE4yNXE4y2L5-eqoYDiuaMK8mGrs2ow=.07d4502e-52a9-42be-8e2f-9583ed19bd3e@github.com>
Message-ID: <DFlViTZdUkRe09wlzLnXwFKUaC_AF4cX9VKjzFSY3BI=.1099ff1c-2451-4810-81b9-cdd39a3759e5@github.com>

On Thu, 2 Mar 2023 07:42:16 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Not 100% sold on the use of `bit` for a single bit index. But at least consistency makes it clearer.

In this change I was mostly trying to remove outliers in parameter naming.
I'm not wedded to either `bit` or `word`, but that is the common usage.

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

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

From kbarrett at openjdk.org  Thu Mar  2 09:45:00 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 2 Mar 2023 09:45:00 GMT
Subject: RFR: 8303418: Improve parameter and variable names in BitMap [v3]
In-Reply-To: <LkA8PloAB0eQanDBr7eWx9_5EG5-6WByhZk19NxVcEw=.34afb33b-5e55-44a9-93bd-d701b62679c6@github.com>
References: <LkA8PloAB0eQanDBr7eWx9_5EG5-6WByhZk19NxVcEw=.34afb33b-5e55-44a9-93bd-d701b62679c6@github.com>
Message-ID: <hD-9ddWPC6sEPzbdbC7FHn4Xmt44OgGEcsesUd484eI=.00e82884-ed84-4466-abf0-d4f88e0c0f8b@github.com>

> Please review this change to names in BitMap.
> 
> - Parameters that designate a bit in a BitMap are named "bit".
> - Parameters that designate a word in the underlying BitMap storage are named "word".
> - Parameters that designate a range are named "beg" and "end" resp.
> 
> Added helper function `flipped_word` for use by `get_next_bit_impl`, replacing
> the odd overload for `map`.
> 
> In `get_next_bit_impl`, prefixed the variables "index" and "limit" with
> "word_" to make clear the units.
> 
> Testing:
> mach5 tier1

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 four additional commits since the last revision:

 - Merge branch 'master' into improve-bitmap-varnames
 - copyrights
 - improve names in get_next_bit_impl
 - cleanup parameter names

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12798/files
  - new: https://git.openjdk.org/jdk/pull/12798/files/59138b0f..cb665e54

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

  Stats: 3035 lines in 106 files changed: 2058 ins; 624 del; 353 mod
  Patch: https://git.openjdk.org/jdk/pull/12798.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12798/head:pull/12798

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

From kbarrett at openjdk.org  Thu Mar  2 09:45:04 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 2 Mar 2023 09:45:04 GMT
Subject: RFR: 8303418: Improve parameter and variable names in BitMap [v2]
In-Reply-To: <abReZF9HNyWPSQ0UDnkSI_tCu4KSoTW10c7unnAwSg0=.e8c46d3f-7dad-40fe-b797-9bd8f125b34a@github.com>
References: <LkA8PloAB0eQanDBr7eWx9_5EG5-6WByhZk19NxVcEw=.34afb33b-5e55-44a9-93bd-d701b62679c6@github.com>
 <BgmgbttSgJTgNl0E_UNGTP8SWRKfwKjVRRLTA0q4xuc=.bd5be179-31dd-4157-b3df-accd0a9c3120@github.com>
 <abReZF9HNyWPSQ0UDnkSI_tCu4KSoTW10c7unnAwSg0=.e8c46d3f-7dad-40fe-b797-9bd8f125b34a@github.com>
Message-ID: <MSnb5wT2yhutIbaSfflWRq6ndt1_JbDyHMDF0ohXMOE=.c4962fdf-eacc-494b-8d17-117964f442fe@github.com>

On Wed, 1 Mar 2023 11:34:53 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   copyrights
>
> Lgtm.
> 
> It would be great to also fix the unusual spacing between method names and the parameter brackets (and the method body brackets) a little, but that can be a different issue.

Thanks for reviews @tschatzl and @xmas92

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

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

From kbarrett at openjdk.org  Thu Mar  2 09:49:15 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 2 Mar 2023 09:49:15 GMT
Subject: Integrated: 8303418: Improve parameter and variable names in BitMap
In-Reply-To: <LkA8PloAB0eQanDBr7eWx9_5EG5-6WByhZk19NxVcEw=.34afb33b-5e55-44a9-93bd-d701b62679c6@github.com>
References: <LkA8PloAB0eQanDBr7eWx9_5EG5-6WByhZk19NxVcEw=.34afb33b-5e55-44a9-93bd-d701b62679c6@github.com>
Message-ID: <efreQB17qWVe60gavvR57Y6rT6I-JTEwyZKkMLy7PZU=.c2c75e89-4eca-44d5-acd4-026499c9d38a@github.com>

On Wed, 1 Mar 2023 04:39:19 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to names in BitMap.
> 
> - Parameters that designate a bit in a BitMap are named "bit".
> - Parameters that designate a word in the underlying BitMap storage are named "word".
> - Parameters that designate a range are named "beg" and "end" resp.
> 
> Added helper function `flipped_word` for use by `get_next_bit_impl`, replacing
> the odd overload for `map`.
> 
> In `get_next_bit_impl`, prefixed the variables "index" and "limit" with
> "word_" to make clear the units.
> 
> Testing:
> mach5 tier1

This pull request has now been integrated.

Changeset: 3091744f
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3091744fff56ae08861f28b87c1de27738c4c62b
Stats:     55 lines in 3 files changed: 5 ins; 1 del; 49 mod

8303418: Improve parameter and variable names in BitMap

Reviewed-by: tschatzl, aboldtch

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

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

From aph at openjdk.org  Thu Mar  2 09:54:12 2023
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 2 Mar 2023 09:54:12 GMT
Subject: RFR: 8302780: Add support for vectorized arraycopy GC barriers
 [v6]
In-Reply-To: <RfZT2ILh5aTTS01W2zpsGMH6GgeBYnAhuqy_JGw6JZ4=.0a000408-dfba-4e66-8b18-40d6c92b703e@github.com>
References: <SU-lpFUY3nGTCSM5k7HrOR2xGgNhPFRNDFUa6JBNEMQ=.2ceac514-334b-4201-8f7b-f17b9ebf3505@github.com>
 <47e5gQJkZn7ldGv3n2cyQoZSAT9YpWWvIwXnbxhdGuQ=.643a4652-204b-4689-85a4-9378e8a587b3@github.com>
 <2g2QqIWkC2a7QyVzPkX-QW3LcMrti6-AMwuFPqe752o=.c63ae268-69be-4770-b642-544633c1cf8f@github.com>
 <1NdlCJpW9kP6N1prWI-pXRBFCooYppayETd83JdBEkE=.df3ed4f4-b685-4377-8284-40b4a3cedf5e@github.com>
 <RfZT2ILh5aTTS01W2zpsGMH6GgeBYnAhuqy_JGw6JZ4=.0a000408-dfba-4e66-8b18-40d6c92b703e@github.com>
Message-ID: <oFA1mEXKs3IoiaI-5ZlguJtks0_HpUWOcGPSExVlkl8=.480ca41c-0df2-4ce9-a59a-9b4a2ead3e6a@github.com>

On Wed, 1 Mar 2023 09:51:22 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> Note also that the arraycopy stubs were already using r8 and r9 as temp registers. I just moved their use to GC barriers, so only they need to deal with their inherent scratchyness, while the temp registers used in the client code can use registers that are not scratchy, which was not the case before.

The use of scratch registers in the AArch64 GC barriers was _already_ buggy and error prone, which resulted in serious and hard-to-find bugs. If you need to use the scratch registers in stubs, please, please don't alias them. Call them `rscratch1` and `rscratch2`.

Using scratch registers is safe as long as the code follows a couple of rules. Don't alias them, and if an inner macro is called from another macro, it's often safer to pass scratch registers to the inner macro explicitly. I know we're not consistent about this.

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

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

From aph at openjdk.org  Thu Mar  2 10:01:21 2023
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 2 Mar 2023 10:01:21 GMT
Subject: RFR: 8302780: Add support for vectorized arraycopy GC barriers
 [v6]
In-Reply-To: <SsRePM6dkPRzWTX5vD-Of9vcCURYSZyKMr4DYfBif8U=.8423d374-1ee6-4fba-9561-f40517fe9490@github.com>
References: <SU-lpFUY3nGTCSM5k7HrOR2xGgNhPFRNDFUa6JBNEMQ=.2ceac514-334b-4201-8f7b-f17b9ebf3505@github.com>
 <47e5gQJkZn7ldGv3n2cyQoZSAT9YpWWvIwXnbxhdGuQ=.643a4652-204b-4689-85a4-9378e8a587b3@github.com>
 <nLy9emUIdTkhV1t48otOXxgMwJ_eU6ittB6QA0X7JYo=.c8f0e35b-d41e-4a98-9538-7bfbb6a0a77f@github.com>
 <SsRePM6dkPRzWTX5vD-Of9vcCURYSZyKMr4DYfBif8U=.8423d374-1ee6-4fba-9561-f40517fe9490@github.com>
Message-ID: <XmcClrrGSrtrmQR8EoXNcwVlx8R-hvjN_m1KPnzpzz0=.67f24732-5965-4840-a8b4-0314c2183325@github.com>

On Wed, 1 Mar 2023 09:29:14 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 812:
>> 
>>> 810:       bs_asm->copy_load_at(_masm, decorators, type, 32,
>>> 811:                            v2, v3, Address(__ pre(s, 8 * unit)),
>>> 812:                            gct1, gct2, gcvt1);
>> 
>> All this extreme cut-and-paste manual unrolling is very hard to read, maintain, and review.
>> I wasn't going to say anything, because it's Erik, and what do I know! But I must push back here, this is too much.
>> Please consider these style changes.
>
> I updated the PR with a helper stack object encapsulating the choice of GC temp registers, types, decorators, etc, so that each line removes all the noise and becomes more readable. Do you like it? If yes, do you also want your proposed loop constructions in the new more compact form? I'm okay either way.

The more compact form is a _huge_ improvement. I believe that using loops rather than hand-unrolling the code would make it even better!

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

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

From aph at openjdk.org  Thu Mar  2 10:06:26 2023
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 2 Mar 2023 10:06:26 GMT
Subject: RFR: 8302780: Add support for vectorized arraycopy GC barriers
 [v8]
In-Reply-To: <UrZD6IsIiDp9Fdqc2LPq5uZhrke-AEuZYeakmtAgjlA=.d89ec381-7fb0-4486-8b83-7a10536fc5bd@github.com>
References: <SU-lpFUY3nGTCSM5k7HrOR2xGgNhPFRNDFUa6JBNEMQ=.2ceac514-334b-4201-8f7b-f17b9ebf3505@github.com>
 <BWqOjj4KikZ2Mj14NNMdbAhMaY0rsj0289AEAQFqegw=.af04f90a-7548-4bfd-8399-ab5a763b8dd1@github.com>
 <UrZD6IsIiDp9Fdqc2LPq5uZhrke-AEuZYeakmtAgjlA=.d89ec381-7fb0-4486-8b83-7a10536fc5bd@github.com>
Message-ID: <gvDgRkVLCWKo7eMNg09fMG2u59Z7B6RwPmEkYl-9588=.54ec61a2-e086-41a4-9ebe-9b459c26e9f7@github.com>

On Thu, 2 Mar 2023 09:15:34 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> > All this extreme cut-and-paste manual unrolling is very hard to read, maintain, and review.
> > I wasn't going to say anything, because it's Erik, and what do I know! But I must push back here, this is too much.
> > Please consider these style changes.
> 
> In my opinion, the (very much needed) changes you suggest are outside the scope of this PR, which is about lifting the memory accesses, in their existing form, to a barrier API-level. Conflating this with your suggested changes would make it harder to review this PR, which is sufficiently complex in its current form. I totally agree that your suggestions would improve readability and maintainability, but couldn't we apply them in a follow-up RFE?

I disagree in every way. The added complexity, which is fixed so it no longer matters, made it near-impossible for me to reason about this PR.  And, as John Rose put it, like any good carpenter we should clean up as we work.

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

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

From duke at openjdk.org  Thu Mar  2 10:14:00 2023
From: duke at openjdk.org (Amit Kumar)
Date: Thu, 2 Mar 2023 10:14:00 GMT
Subject: RFR: 8303147: [s390x] fast & slow debug builds are broken
Message-ID: <_ZdU0STu6HC-2e2UuIXJPe7RslDoKVDPLYXSGJFAwkA=.7639982c-26d7-4a93-8e6f-2d0171b71477@github.com>

This PR fixes broken fast debug and slow debug build for s390x-arch. tier1 test are completed and results are not affect after this patch.

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

Commit messages:
 - build fix for s390x

Changes: https://git.openjdk.org/jdk/pull/12825/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12825&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303147
  Stats: 53 lines in 12 files changed: 35 ins; 13 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/12825.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12825/head:pull/12825

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

From prappo at openjdk.org  Thu Mar  2 12:13:14 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 2 Mar 2023 12:13:14 GMT
Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments
Message-ID: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>

Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.

The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:


    diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
    --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
    +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
    @@ -17084,7 +17084,7 @@
                      throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
     <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
     <div class="block"><code>readObject</code> is called to restore the state of the
    - (@code BasicPermission} from a stream.</div>
    + <code>BasicPermission</code> from a stream.</div>
     <dl class="notes">
     <dt>Parameters:</dt>
     <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>

Notes
-----

* I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
* I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
* I will update copyright years after (and if) the fix had been approved, as required.

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

Commit messages:
 - Initial commit

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

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

From duke at openjdk.org  Thu Mar  2 13:17:05 2023
From: duke at openjdk.org (Jan Kratochvil)
Date: Thu, 2 Mar 2023 13:17:05 GMT
Subject: RFR: 8302191: Performance degradation for float/double modulo on
 Linux [v5]
In-Reply-To: <OoYoMXL5HyAVVvSpbj-lqGeOb9xNPKSVdQHDlYVr9Wo=.36a530a9-1921-4e92-8bb7-be8a48f02448@github.com>
References: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
 <o8gBuzq9Pfc4aYnmo3cPGXwVo4cbouH0delXsoz4kEI=.7a6c9412-f7c4-4c07-91ea-8cb5c0b9da6a@github.com>
 <OoYoMXL5HyAVVvSpbj-lqGeOb9xNPKSVdQHDlYVr9Wo=.36a530a9-1921-4e92-8bb7-be8a48f02448@github.com>
Message-ID: <z6yn-ke23WZj0ik9w7g9u530jWDXdo5hUQ7SK819ao4=.d4908bff-c1eb-4c14-bd3b-9373db90ce63@github.com>

On Thu, 2 Mar 2023 04:02:13 GMT, David Holmes <dholmes at openjdk.org> wrote:

> You can't move the _WIN64 workaround to the sharedRuntime_x86.cpp file as that code is also used by Windows-Aarch64. Whether it needs the workaround or not is another matter, but unless proven otherwise we have to assume it does.

I hope/believe the bug affects only amd64 and not aarch64. I want to verify it but I have some difficulty getting remote access to such Windows boxes, I am working on the verification.

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

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

From mullan at openjdk.org  Thu Mar  2 13:24:07 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 2 Mar 2023 13:24:07 GMT
Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments
In-Reply-To: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
Message-ID: <GCwAXDcnMpAJDHxB9QMEP9UmwTYemW62F7RUdNaEVk8=.8b73051d-d3a8-4fac-ac48-efc3864d33bc@github.com>

On Thu, 2 Mar 2023 12:03:44 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
> 
> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
> 
> 
>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>     @@ -17084,7 +17084,7 @@
>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>      <div class="block"><code>readObject</code> is called to restore the state of the
>     - (@code BasicPermission} from a stream.</div>
>     + <code>BasicPermission</code> from a stream.</div>
>      <dl class="notes">
>      <dt>Parameters:</dt>
>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
> 
> Notes
> -----
> 
> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
> * I will update copyright years after (and if) the fix had been approved, as required.

security related changes look fine.

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

Marked as reviewed by mullan (Reviewer).

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

From iwalulya at openjdk.org  Thu Mar  2 13:56:04 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Thu, 2 Mar 2023 13:56:04 GMT
Subject: RFR: 8191565: Last-ditch Full GC should also move humongous objects
Message-ID: <58l059EvQI6HNQyjUYSGYEWt6x-c1yvtmfX1QWfinH8=.87517ba1-ec81-4b9f-a41b-b05c8d33cf3d@github.com>

Hi All,

Please review this change to move humongous regions during the Last-Ditch full gc ( on `do_maximal_compaction`). This change will enable G1 to avoid encountering Out-Of-Memory errors that may occur due to the fragmentation of memory regions caused by the allocation of large memory blocks.

Here's how it works: At the end of `phase2_prepare_compaction`, G1 performs a serial compaction process for regular objects, which results in the heap being divided into two parts. The first part is a densely populated prefix that contains all the regular objects that have been moved. The second part consists of the remaining heap space, which may contain free regions, uncommitted regions, and regions that are not compacting. By moving/compacting the humongous objects in the second part of the heap closer to the dense prefix, G1 reduces the region fragmentation and avoids running into OOM errors.

We have enabled for G1 the Jtreg test that was previously used only for Shenandoah to test such workload. 

Testing: Tier 1-3

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

Commit messages:
 - restructure
 - add test
 - breakout large functioons
 - working prototype

Changes: https://git.openjdk.org/jdk/pull/12830/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12830&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8191565
  Stats: 333 lines in 13 files changed: 318 ins; 9 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/12830.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12830/head:pull/12830

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

From mbaesken at openjdk.org  Thu Mar  2 16:27:32 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 2 Mar 2023 16:27:32 GMT
Subject: RFR: JDK-8302989: Add missing INCLUDE_CDS checks [v3]
In-Reply-To: <kBV8fNo_CWJL2MoXgAckFhuAFgQ3RGZjFKAKnl8xfV8=.233bb652-8508-4065-92ea-7873b1c765f3@github.com>
References: <kBV8fNo_CWJL2MoXgAckFhuAFgQ3RGZjFKAKnl8xfV8=.233bb652-8508-4065-92ea-7873b1c765f3@github.com>
Message-ID: <i619e3l156DnYwsJB7id-5AahSUqdZINDXaDtRo56DA=.f4fdf096-c1f9-48e0-b75a-58776e5f3dd4@github.com>

> The cds only coding in hotspot is usually guarded with the INCLUDE_CDS macro so that it can be removed at compile time in case the correct configure flags are set.
> However at some places INCLUDE_CDS is missing and should be added.
> 
> One question - should (additionally to the UseSharedSpaces code section)  the DumpSharedSpaces code sections be guarded as well with INCLUDE_CDS macros ?

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  adjust some cds related vars

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12691/files
  - new: https://git.openjdk.org/jdk/pull/12691/files/5dff9614..33eb5631

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

  Stats: 18 lines in 2 files changed: 2 ins; 14 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12691.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12691/head:pull/12691

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

From mbaesken at openjdk.org  Thu Mar  2 16:30:16 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 2 Mar 2023 16:30:16 GMT
Subject: RFR: JDK-8302989: Add missing INCLUDE_CDS checks [v2]
In-Reply-To: <BuCxJoq8h8XasiTZ_6foYa1BJ0BI7h4vyQik68Gct7E=.2b5745de-9059-4aa5-a196-43c15a5122ec@github.com>
References: <kBV8fNo_CWJL2MoXgAckFhuAFgQ3RGZjFKAKnl8xfV8=.233bb652-8508-4065-92ea-7873b1c765f3@github.com>
 <kC0i6N44wUExbim6e2SCu5QCCpEGxRTEeRCGMRe__Fs=.46f19345-c54b-4e9b-bd8d-5c38dc4846a1@github.com>
 <D94A_iYhqCAvpWC87xWqEIAs7DQtw68zdetsZQc5pQ8=.8a39311a-60b2-4d83-969e-f48a74278d5b@github.com>
 <Rr2AaOX0OnWVBM3-GqzimZpF_T1m4XVLh7o_cnRFyLI=.318bc73f-61e2-4347-b119-74d908d963ff@github.com>
 <BuCxJoq8h8XasiTZ_6foYa1BJ0BI7h4vyQik68Gct7E=.2b5745de-9059-4aa5-a196-43c15a5122ec@github.com>
Message-ID: <bOoXqCQif8I39pq6lY3DKkR5MT3Dot24sDT6f5AE95Y=.5df81928-75f0-421e-b35b-eb4d89581b56@github.com>

On Wed, 1 Mar 2023 12:27:29 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Hi Ioi, I set this already some lines above (in the non-INCLUDE_CDS case).
>
> You need to remove the `extern` keyword, and add the definition of `= false` in globalDefinitions.hpp.
> 
> Then, the corresponding definition should be removed from globalDefinitions.cpp.

Hi Ioi, I adjusted the *SharedSpaces in  globalDefinitions.cpp / globalDefinitions.hpp  .

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

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

From rkennke at openjdk.org  Thu Mar  2 16:34:05 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 2 Mar 2023 16:34:05 GMT
Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity
 [v29]
In-Reply-To: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
References: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
Message-ID: <JGFfC6AtNbUmZn869nqTOIcBTK6pQ5-A0vG8PaSMCh8=.16e94e69-2540-4059-a42c-f855c8babd45@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:

  Rename payload_start -> payload_offset

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11044/files
  - new: https://git.openjdk.org/jdk/pull/11044/files/572de842..95b85b65

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=28
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=27-28

  Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 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 stuefe at openjdk.org  Thu Mar  2 16:37:47 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 2 Mar 2023 16:37:47 GMT
Subject: RFR: JDK-8293114: GC should trim the native heap [v10]
In-Reply-To: <23KpPM4oPV6F1nz3g5CvIqvuX-ANcsMH4GuVNXjR-Lw=.b8d0fa2d-bb85-4899-8e21-f68ea64b988d@github.com>
References: <23KpPM4oPV6F1nz3g5CvIqvuX-ANcsMH4GuVNXjR-Lw=.b8d0fa2d-bb85-4899-8e21-f68ea64b988d@github.com>
Message-ID: <nLY0-EnPBxtsCVJbxAzJTUZS7jZitqGFvWt-Rzn0lu4=.4e9bd442-0480-4894-b17f-e9d4b465ecec@github.com>

> (This PR is in draft and still getting worked on. The description below is obsolete and does not reflect its current state)
> 
> -------------------------------------------
> 
> This RFE adds the option to auto-trim the Glibc heap as part of the GC cycle. If the VM process suffered high temporary malloc spikes (regardless whether from JVM- or user code), this could recover significant amounts of memory.
> 
> We discussed this a year ago [1], but the item got pushed to the bottom of my work pile, therefore it took longer than I thought.
> 
> ### Motivation
> 
> The Glibc allocator is reluctant to return memory to the OS, much more so than other allocators. Temporary malloc spikes often carry over as permanent RSS increase. 
> 
> Note that C-heap retention is difficult to observe. Since it is freed memory, it won't show up in NMT, it is just a part of private RSS.
> 
> Theoretically, retained memory is not lost since it will be reused by future mallocs. Retaining memory is therefore a bet on the future behavior of the app. The allocator bets on the application needing memory in the near future, and to satisfy that need via malloc. 
> 
> But an app's malloc load can fluctuate wildly, with temporary spikes and long idle periods. And if the app rolls its own custom allocators atop of mmap, as hotspot does, a lot of that memory cannot be reused even though it counts toward its memory footprint.
> 
> To help, Glibc exports an API to trim the C-heap: `malloc_trim(3)`. With JDK 18 [2], SAP contributed a new jcmd command to *manually* trim the C-heap on Linux. This RFE adds a complementary way to trim automatically.
> 
> #### Is this even a problem?
> 
> Do we have high malloc spikes in the JVM process? We assume that malloc load from hotspot is usually low since hotspot typically clusters allocations into custom areas - metaspace, code heap, arenas. 
> 
> But arenas are subject to Glibc mem retention too. I was surprised by that since I assumed 32k arena chunks were too big to be subject of Glibc retention. But I saw in experiments that high arena peaks often cause lasting RSS increase. 
> 
> And of course, both hotspot and JDK do a lot of finer-granular mallocs outside of custom allocators.
> 
> But many cases of high memory retention in Glibc I have seen in third-party JNI code. Libraries allocate large buffers via malloc as temporary buffers. In fact, since we introduced the jcmd "System.trim_native_heap", some of our customers started to call this command periodically in scripts to counter these issues.
> 
> Therefore I think while high malloc spikes are atypical for a JVM process, they can happen. Having a way to auto-trim the native heap makes sense.
> 
> ### When should we trim?
> 
> We want to trim when we know there is a lull in malloc activity coming. But we have no knowledge of the future.
> 
> We could build a heuristic based on malloc frequency. But on closer inspection that is difficult. We cannot use NMT, since NMT has no complete picture (only knows hotspot) and is usually disabled in production anyway. The only way to get *all* mallocs would be to use Glibc malloc hooks. We have done so in desperate cases at SAP, but Glibc removed malloc hooks in 2.35. It would be a messy solution anyway; best to avoid it.
> 
> The next best thing is synchronizing with the larger C-heap users in the VM: compiler and GC. But compiler turns out not to be such a problem, since the compiler uses arenas, and arena chunks are buffered in a free pool with a five-second delay. That means compiler activity that happens in bursts, like at VM startup, will just shuffle arena chunks around from/to the arena free pool, never bothering to call malloc or free.
> 
> That leaves the GC, which was also the experts' recommendation in last year's discussion [1]. Most GCs do uncommit, and trimming the native heap fits well into this. And we want to time the trim to not get into the way of a GC. Plus, integrating trims into the GC cycle lets us reuse GC logging and timing, thereby making RSS changes caused by trim-native visible to the analyst.
> 
> 
> ### How it works:
> 
> Patch adds new options (experimental for now, and shared among all GCs):
> 
> 
> -XX:+GCTrimNativeHeap
> -XX:GCTrimNativeHeapInterval=<seconds> (defaults to 60)
> 
> 
> `GCTrimNativeHeap` is off by default. If enabled, it will cause the VM to trim the native heap on full GCs as well as periodically. The period is defined by `GCTrimNativeHeapInterval`. Periodic trimming can be completely switched off with `GCTrimNativeHeapInterval=0`; in that case, we will only trim on full GCs.
> 
> ### Examples:
> 
> This is an artificial test that causes two high malloc spikes with long idle periods. Observe how RSS recovers with trim but stays up without trim. The trim interval was set to 15 seconds for the test, and no GC was invoked here; this is periodic trimming.
> 
> ![alloc-test](http://cr.openjdk.java.net/~stuefe/other/autotrim/rss-all-collectors.png)
> 
> (See here for parameters: [run script](http://cr.openjdk.java.net/~stuefe/other/autotrim/run-all.sh) )
> 
> Spring pet clinic boots up, then idles. Once with, once without trim, with the trim interval at 60 seconds default. Of course, if it were actually doing something instead of idling, trim effects would be smaller. But the point of trimming is to recover memory in idle periods.
> 
> ![petclinic bootup](http://cr.openjdk.java.net/~stuefe/other/autotrim/spring-petclinic-rss-with-and-without-trim.png))
> 
> (See here for parameters: [run script](http://cr.openjdk.java.net/~stuefe/other/autotrim/run-petclinic-boot.sh) )
> 
> 
> 
> ### Implementation
> 
> One problem I faced when implementing this was that trimming was non-interruptable. GCs usually split the uncommit work into smaller portions, which is impossible for `malloc_trim()`.
> 
> So very slow trims could introduce longer GC pauses. I did not want this, therefore I implemented two ways to trim:
> 1) GCs can opt to trim asynchronously. In that case, a `NativeTrimmer` thread runs on behalf of the GC and takes care of all trimming. The GC just nudges the `NativeTrimmer` at the end of its GC cycle, but the trim itself runs concurrently.
> 2) GCs can do the trim inside their own thread, synchronously. It will have to wait until the trim is done.
> 
> (1) has the advantage of giving us periodic trims even without GC activity (Shenandoah does this out of the box).
> 
> #### Serial
> 
> Serial does the trimming synchronously as part of a full GC, and only then. I did not want to spawn a separate thread for the SerialGC. Therefore Serial is the only GC that does not offer periodic trimming, it just trims on full GC.
> 
> #### Parallel, G1, Z
> 
> All of them do the trimming asynchronously via `NativeTrimmer`. They schedule the native trim at the end of a full collection. They also pause the trimming at the beginning of a cycle to not trim during GCs.
> 
> #### Shenandoah
> 
> Shenandoah does the trimming synchronously in its service thread, similar to how it handles uncommits. Since the service thread already runs concurrently and continuously, it can do periodic trimming; no need to spin a new thread. And this way we can reuse the Shenandoah timing classes.
> 
> ### Patch details
> 
> - adds three new functions to the `os` namespace:
>   - `os::trim_native_heap()` implementing trim
>   - `os::can_trim_native_heap()` and `os::should_trim_native_heap()` to return whether platform supports trimming resp. whether the platform considers trimming to be useful.
> - replaces implementation of the cmd "System.trim_native_heap" with the new `os::trim_native_heap`
> - provides a new wrapper function wrapping the tedious `mallinfo()` vs `mallinfo2()` business: `os::Linux::get_mallinfo()`
> - adds a GC-shared utility class, `GCTrimNative`, that takes care of trimming and GC-logging and houses the `NativeTrimmer` thread class.
> - adds a regression test
> 
> 
> ### Tests
> 
> Tested older Glibc (2.31), and newer Glibc (2.35) (`mallinfo()` vs` mallinfo2()`), on Linux x64.
> 
> The rest of the tests will be done by GHA and in our SAP nightlies.
> 
> 
> ### Remarks
> 
> #### How about other allocators?
> 
> I have seen this retention problem mainly with the Glibc and the AIX libc. Muslc returns memory more eagerly to the OS. I also tested with jemalloc and found it also reclaims more aggressively, therefore I don't think MacOS or BSD are affected that much by retention either.
> 
> #### Trim costs?
> 
> Trim-native is a tradeoff between memory and performance. We pay
> - The cost to do the trim depends on how much is trimmed. Time ranges on my machine between < 1ms for no-op trims, to ~800ms for 32GB trims.
> - The cost for re-acquiring the memory, should the memory be needed again, is the second cost factor.
> 
> #### Predicting malloc_trim effects?
> 
> `ShenandoahUncommit` avoids uncommits if they are not necessary, thus avoiding work and gc log spamming. I liked that and tried to follow that example. Tried to devise a way to predict the effect trim could have based on allocator info from mallinfo(3). That was quite frustrating since the documentation was confusing and I had to do a lot of experimenting. In the end, I came up with a heuristic to prevent obviously pointless trim attempts; see `os::should_trim_native_heap()`.  I am not completely happy with it.
> 
> #### glibc.malloc.trim_threshold?
> 
> glibc has a tunable that looks like it could influence the willingness of Glibc to return memory to the OS, the "trim_threshold". In practice, I could not get it to do anything useful. Regardless of the setting, it never seemed to influence the trimming behavior. Even if it would work, I'm not sure we'd want to use that, since by doing malloc_trim manually we can space out the trims as we see fit, instead of paying the trim price for free(3).
> 
> 
> - [1] https://mail.openjdk.org/pipermail/hotspot-dev/2021-August/054323.html
> - [2] https://bugs.openjdk.org/browse/JDK-8269345

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

 - wip
 - Merge branch 'master' into JDK-8293114-GC-trim-native
 - wip
 - merge master
 - wip
 - wip
 - rename GCTrimNative TrimNative
 - rename NativeTrimmer
 - rename
 - src/hotspot/share/gc/shared/gcTrimNativeHeap.cpp
 - ... and 24 more: https://git.openjdk.org/jdk/compare/99f5687e...5d41312e

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

Changes: https://git.openjdk.org/jdk/pull/10085/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10085&range=09
  Stats: 1246 lines in 21 files changed: 1241 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/10085.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10085/head:pull/10085

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

From matsaave at openjdk.org  Thu Mar  2 16:55:23 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 2 Mar 2023 16:55:23 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry
Message-ID: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>

The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 

This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.

Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.

The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.

This change supports the following platforms: x86, aarch64, PPC, and RISCV

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

Commit messages:
 - PPC and RISCV port
 - 8301995: Move invokedynamic resolution information out of the cpCache

Changes: https://git.openjdk.org/jdk/pull/12778/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12778&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301995
  Stats: 1418 lines in 54 files changed: 1036 ins; 168 del; 214 mod
  Patch: https://git.openjdk.org/jdk/pull/12778.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12778/head:pull/12778

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

From aturbanov at openjdk.org  Thu Mar  2 18:49:05 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 2 Mar 2023 18:49:05 GMT
Subject: RFR: 8302191: Performance degradation for float/double modulo on
 Linux [v5]
In-Reply-To: <o8gBuzq9Pfc4aYnmo3cPGXwVo4cbouH0delXsoz4kEI=.7a6c9412-f7c4-4c07-91ea-8cb5c0b9da6a@github.com>
References: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
 <o8gBuzq9Pfc4aYnmo3cPGXwVo4cbouH0delXsoz4kEI=.7a6c9412-f7c4-4c07-91ea-8cb5c0b9da6a@github.com>
Message-ID: <BReZXdo8A-4Woro9ydKovAUatzV2p8Cg1vK4XQejAv0=.2911747b-6b47-4fb3-ac3e-203200b4680c@github.com>

On Wed, 1 Mar 2023 12:03:54 GMT, Jan Kratochvil <duke at openjdk.org> wrote:

>> I have OCA already processed/approved. I am not Author but my Author request is being processed these days (sent to Rob McKenna).
>> I did regression test x86_64 OpenJDK-8. I will leave other regression testing on GHA.
>> The patch (and former GCC performance regression) affects only x86_64+i686.
>
> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright author.

test/micro/org/openjdk/bench/vm/floatingpoint/DremFrem.java line 177:

> 175:             double quiet_nan2     = Double.longBitsToDouble(0x7ffc000000000002l);
> 176:             double signaling_nan1 = Double.longBitsToDouble(0x7ffa000000000001l);
> 177:             double signaling_nan2 = Double.longBitsToDouble(0x7ffa000000000002l);

Suggestion:

            double quiet_nan1     = Double.longBitsToDouble(0x7ffc000000000001L);
            double quiet_nan2     = Double.longBitsToDouble(0x7ffc000000000002L);
            double signaling_nan1 = Double.longBitsToDouble(0x7ffa000000000001L);
            double signaling_nan2 = Double.longBitsToDouble(0x7ffa000000000002L);

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

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

From prr at openjdk.org  Thu Mar  2 21:29:04 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 2 Mar 2023 21:29:04 GMT
Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments
In-Reply-To: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
Message-ID: <LDJs1K7coRg4R4EWiETtoqjNIaZchHUjyKAg2madLSM=.11763787-9322-4863-8ca9-242447a9c6de@github.com>

On Thu, 2 Mar 2023 12:03:44 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
> 
> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
> 
> 
>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>     @@ -17084,7 +17084,7 @@
>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>      <div class="block"><code>readObject</code> is called to restore the state of the
>     - (@code BasicPermission} from a stream.</div>
>     + <code>BasicPermission</code> from a stream.</div>
>      <dl class="notes">
>      <dt>Parameters:</dt>
>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
> 
> Notes
> -----
> 
> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
> * I will update copyright years after (and if) the fix had been approved, as required.

java.desktop changes are fine

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

Marked as reviewed by prr (Reviewer).

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

From ayang at openjdk.org  Thu Mar  2 21:57:06 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 2 Mar 2023 21:57:06 GMT
Subject: RFR: 8303534: Merge CompactibleSpace into ContiguousSpace
Message-ID: <dPNxDwwSW0wlk4Fv6eYg8dsClKdfjNV9si2WZS2Npi0=.c4f52214-c8a1-4fe6-a513-9fb1e0995ae0@github.com>

Simple refactoring of merging two types.

Test: tier1-5

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

Commit messages:
 - merge-type

Changes: https://git.openjdk.org/jdk/pull/12841/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12841&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303534
  Stats: 191 lines in 14 files changed: 27 ins; 122 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/12841.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12841/head:pull/12841

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

From cjplummer at openjdk.org  Thu Mar  2 22:14:04 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 2 Mar 2023 22:14:04 GMT
Subject: RFR: 8303534: Merge CompactibleSpace into ContiguousSpace
In-Reply-To: <dPNxDwwSW0wlk4Fv6eYg8dsClKdfjNV9si2WZS2Npi0=.c4f52214-c8a1-4fe6-a513-9fb1e0995ae0@github.com>
References: <dPNxDwwSW0wlk4Fv6eYg8dsClKdfjNV9si2WZS2Npi0=.c4f52214-c8a1-4fe6-a513-9fb1e0995ae0@github.com>
Message-ID: <ZK00wsej78TXdL6axczghJOeArUI_d6C9et6zJkbU7Q=.2ec9ece0-bf99-463b-9b39-155b0f872eab@github.com>

On Thu, 2 Mar 2023 21:49:39 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple refactoring of merging two types.
> 
> Test: tier1-5

Copyrights need updating in a few files.

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

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

From dholmes at openjdk.org  Thu Mar  2 22:14:15 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 2 Mar 2023 22:14:15 GMT
Subject: RFR: 8302191: Performance degradation for float/double modulo on
 Linux [v5]
In-Reply-To: <z6yn-ke23WZj0ik9w7g9u530jWDXdo5hUQ7SK819ao4=.d4908bff-c1eb-4c14-bd3b-9373db90ce63@github.com>
References: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
 <o8gBuzq9Pfc4aYnmo3cPGXwVo4cbouH0delXsoz4kEI=.7a6c9412-f7c4-4c07-91ea-8cb5c0b9da6a@github.com>
 <OoYoMXL5HyAVVvSpbj-lqGeOb9xNPKSVdQHDlYVr9Wo=.36a530a9-1921-4e92-8bb7-be8a48f02448@github.com>
 <z6yn-ke23WZj0ik9w7g9u530jWDXdo5hUQ7SK819ao4=.d4908bff-c1eb-4c14-bd3b-9373db90ce63@github.com>
Message-ID: <r0eyygTLdh54NRqotvLoFEQSWRBVPIgb_zft_HNVbvU=.e2e5ad1d-2908-4579-835d-3ee82f525381@github.com>

On Thu, 2 Mar 2023 13:13:56 GMT, Jan Kratochvil <duke at openjdk.org> wrote:

> I hope/believe the bug affects only amd64 and not aarch64. I want to verify it but I have some difficulty getting remote access to such Windows boxes, I am working on the verification.

IIUC the workaround is needed for a bug in Visual Studio, so verification would require testing binaries built with all version of VS that we allow to build the JDK. Otherwise we need a definitive statement about which version of VS the bug was fixed in and/or that the bug does not exist in the VS libraries used for Aarch64.

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

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

From cjplummer at openjdk.org  Thu Mar  2 22:18:08 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 2 Mar 2023 22:18:08 GMT
Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments
In-Reply-To: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
Message-ID: <63UHTjtrUOVGBTwRt_M4QJ7aqBnuAGqekNTTTl3GM74=.ddedac04-ff87-40b9-9ea7-6b6d26d9d202@github.com>

On Thu, 2 Mar 2023 12:03:44 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
> 
> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
> 
> 
>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>     @@ -17084,7 +17084,7 @@
>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>      <div class="block"><code>readObject</code> is called to restore the state of the
>     - (@code BasicPermission} from a stream.</div>
>     + <code>BasicPermission</code> from a stream.</div>
>      <dl class="notes">
>      <dt>Parameters:</dt>
>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
> 
> Notes
> -----
> 
> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
> * I will update copyright years after (and if) the fix had been approved, as required.

The SA changes (jdk.hotspot.agent) look fine.

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

Marked as reviewed by cjplummer (Reviewer).

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

From phh at openjdk.org  Thu Mar  2 22:26:11 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Thu, 2 Mar 2023 22:26:11 GMT
Subject: RFR: 8302783: Improve CRC32C intrinsic with crypto pmull on
 AArch64
In-Reply-To: <W21GIbXjV68chGAqGzNItlNHLh4l5O72uyonPlsmzZ8=.02147b96-9a7c-49ae-88f0-f12f2143b7c5@github.com>
References: <W21GIbXjV68chGAqGzNItlNHLh4l5O72uyonPlsmzZ8=.02147b96-9a7c-49ae-88f0-f12f2143b7c5@github.com>
Message-ID: <hhxfU_vRdtk0XW7ujbxw60lzozyfsEt0RLujAsvLuss=.a9109227-aaad-4513-abae-3fddc53bbde6@github.com>

On Fri, 17 Feb 2023 19:59:24 GMT, Yi-Fan Tsai <duke at openjdk.org> wrote:

> This change adds a pmull-based CRC32C intrinsic, and it is more performant than the existing crc32c-instruction-based intrinsic on Neoverse V1. The benchmark shows 10 - 99% improvement. The improvement comes from the execution throughput increase of pmull/pmull2 from 1 on Neoverse N1 to 4 on Neoverse V1 while the latency remains 2 while the throughput of CRC32C instructions did not changed. 
> 
> The pmull-based CRC32C intrinsic is enabled by the existing option UseCryptoPmullForCRC32 which also enables the pmull-based CRC32 intrinsic. The option requires crc32c instructions, eor3 in SHA3, and 64-bit pmull/pmull2 in Cryptographic Extension.
> 
> With this change, there will be only two different CRC32C intrinsics, crc32c and pmull, while there are four CRC32 intrinsics.
> 
> The following test has passed.
> test/hotspot/jtreg/compiler/intrinsics/zip/TestCRC32C.java
> 
> The throughput reported by [the micro benchmark](https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/java/util/TestCRC32C.java) is measured on an EC2 c7g instance. The optimization shows 10 - 99% improvement when the input is at least 384 bytes.
> 
> | input               | 64         | 128        | 256        | 384        | 511        | 512        | 1,024      |
> | ------------- | ---------- | ---------- | ---------- | ---------- | ---------- | ---------- | ---------- |
> |  improvement  | 1.60%      | 0.00%      | 0.00%      | 15.24%     | 10.76%     | 34.32%     | 72.39%     |
> 
> | input               | 2,048      | 4,096      | 8,192      | 16,384     | 32,768     | 65,536     |
> | ------------- | ---------- | ---------- | ---------- | ---------- | ---------- | ---------- |
> |  improvement  | 84.96%     | 92.59%     | 96.19%     | 98.02%     | 99.32%     | 98.36%     |
> 
> 
> Baseline
> 
> Benchmark                    (count)   Mode  Cnt       Score      Error   Units
> TestCRC32C.testCRC32CUpdate       64  thrpt   12  196575.739 ? 1824.113  ops/ms
> TestCRC32C.testCRC32CUpdate      128  thrpt   12  123666.570 ?    2.730  ops/ms
> TestCRC32C.testCRC32CUpdate      256  thrpt   12   70188.989 ?    2.002  ops/ms
> TestCRC32C.testCRC32CUpdate      384  thrpt   12   49000.690 ?    1.421  ops/ms
> TestCRC32C.testCRC32CUpdate      511  thrpt   12   34106.279 ?   25.390  ops/ms
> TestCRC32C.testCRC32CUpdate      512  thrpt   12   37638.349 ?    1.039  ops/ms
> TestCRC32C.testCRC32CUpdate     1024  thrpt   12   19526.513 ?    0.439  ops/ms
> TestCRC32C.testCRC32CUpdate     2048  thrpt   12    9951.392 ?    4.803  ops/ms
> TestCRC32C.testCRC32CUpdate     4096  thrpt   12    5023.268 ?    0.240  ops/ms
> TestCRC32C.testCRC32CUpdate     8192  thrpt   12    2523.877 ?    0.062  ops/ms
> TestCRC32C.testCRC32CUpdate    16384  thrpt   12    1265.011 ?    0.047  ops/ms
> TestCRC32C.testCRC32CUpdate    32768  thrpt   12     632.291 ?    0.058  ops/ms
> TestCRC32C.testCRC32CUpdate    65536  thrpt   12     315.396 ?    0.160  ops/ms
> 
> 
> Crypto pmull
> 
> Benchmark                    (count)   Mode  Cnt       Score     Error   Units
> TestCRC32C.testCRC32CUpdate       64  thrpt   12  199726.599 ? 166.477  ops/ms
> TestCRC32C.testCRC32CUpdate      128  thrpt   12  123669.385 ?   1.821  ops/ms
> TestCRC32C.testCRC32CUpdate      256  thrpt   12   70188.727 ?   1.313  ops/ms
> TestCRC32C.testCRC32CUpdate      384  thrpt   12   56468.837 ?  76.524  ops/ms
> TestCRC32C.testCRC32CUpdate      511  thrpt   12   37777.205 ? 406.431  ops/ms
> TestCRC32C.testCRC32CUpdate      512  thrpt   12   50554.555 ?  17.169  ops/ms
> TestCRC32C.testCRC32CUpdate     1024  thrpt   12   33661.006 ? 140.471  ops/ms
> TestCRC32C.testCRC32CUpdate     2048  thrpt   12   18406.482 ? 205.952  ops/ms
> TestCRC32C.testCRC32CUpdate     4096  thrpt   12    9674.159 ?  20.390  ops/ms
> TestCRC32C.testCRC32CUpdate     8192  thrpt   12    4951.562 ?   6.566  ops/ms
> TestCRC32C.testCRC32CUpdate    16384  thrpt   12    2504.970 ?   1.883  ops/ms
> TestCRC32C.testCRC32CUpdate    32768  thrpt   12    1260.278 ?   0.484  ops/ms
> TestCRC32C.testCRC32CUpdate    65536  thrpt   12     625.608 ?   0.300  ops/ms

Lgtm.

The linux-x86 pre-submit test failure is caused by a test using -XX:+UseCompressedClassPointers, which is an invalid switch for 32-bit JVMs.

The linux-cross-compile pre-submit test failure is a compile-time failure in src/hotspot/cpu/arm/interpreterRT_arm.cpp, which latter is not touched by this patch.

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

Marked as reviewed by phh (Reviewer).

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

From darcy at openjdk.org  Thu Mar  2 22:31:14 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 2 Mar 2023 22:31:14 GMT
Subject: RFR: 8302191: Performance degradation for float/double modulo on
 Linux [v5]
In-Reply-To: <o8gBuzq9Pfc4aYnmo3cPGXwVo4cbouH0delXsoz4kEI=.7a6c9412-f7c4-4c07-91ea-8cb5c0b9da6a@github.com>
References: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
 <o8gBuzq9Pfc4aYnmo3cPGXwVo4cbouH0delXsoz4kEI=.7a6c9412-f7c4-4c07-91ea-8cb5c0b9da6a@github.com>
Message-ID: <rvmRsoPkjyTPF-AG80rGqBo3oPpTgnuzqqAT_obLRaY=.185307f7-f00d-48f6-9dc9-c5b291a81cf3@github.com>

On Wed, 1 Mar 2023 12:03:54 GMT, Jan Kratochvil <duke at openjdk.org> wrote:

>> I have OCA already processed/approved. I am not Author but my Author request is being processed these days (sent to Rob McKenna).
>> I did regression test x86_64 OpenJDK-8. I will leave other regression testing on GHA.
>> The patch (and former GCC performance regression) affects only x86_64+i686.
>
> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright author.

test/micro/org/openjdk/bench/vm/floatingpoint/DremFrem.java line 174:

> 172:             double inf_minus_inf  = Double.POSITIVE_INFINITY - Double.POSITIVE_INFINITY;
> 173:             double inf_times_zero = Double.POSITIVE_INFINITY * 0.0f;
> 174:             double quiet_nan1     = Double.longBitsToDouble(0x7ffc000000000001l);

Nit: whether or not a particular NaN bit pattern is quiet or signalling is an architecture-specific determination, it is not specified by the IEEE 754 standard.

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

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

From duke at openjdk.org  Thu Mar  2 22:44:14 2023
From: duke at openjdk.org (Yi-Fan Tsai)
Date: Thu, 2 Mar 2023 22:44:14 GMT
Subject: Integrated: 8302783: Improve CRC32C intrinsic with crypto pmull on
 AArch64
In-Reply-To: <W21GIbXjV68chGAqGzNItlNHLh4l5O72uyonPlsmzZ8=.02147b96-9a7c-49ae-88f0-f12f2143b7c5@github.com>
References: <W21GIbXjV68chGAqGzNItlNHLh4l5O72uyonPlsmzZ8=.02147b96-9a7c-49ae-88f0-f12f2143b7c5@github.com>
Message-ID: <7Yn_j1nryz0tjnGOXMjUy_Hp3JbgEIc63z8Z_uXm92Q=.2f6c9cc4-20d7-4d56-8d94-e32565540413@github.com>

On Fri, 17 Feb 2023 19:59:24 GMT, Yi-Fan Tsai <duke at openjdk.org> wrote:

> This change adds a pmull-based CRC32C intrinsic, and it is more performant than the existing crc32c-instruction-based intrinsic on Neoverse V1. The benchmark shows 10 - 99% improvement. The improvement comes from the execution throughput increase of pmull/pmull2 from 1 on Neoverse N1 to 4 on Neoverse V1 while the latency remains 2 while the throughput of CRC32C instructions did not changed. 
> 
> The pmull-based CRC32C intrinsic is enabled by the existing option UseCryptoPmullForCRC32 which also enables the pmull-based CRC32 intrinsic. The option requires crc32c instructions, eor3 in SHA3, and 64-bit pmull/pmull2 in Cryptographic Extension.
> 
> With this change, there will be only two different CRC32C intrinsics, crc32c and pmull, while there are four CRC32 intrinsics.
> 
> The following test has passed.
> test/hotspot/jtreg/compiler/intrinsics/zip/TestCRC32C.java
> 
> The throughput reported by [the micro benchmark](https://github.com/openjdk/jdk/blob/master/test/micro/org/openjdk/bench/java/util/TestCRC32C.java) is measured on an EC2 c7g instance. The optimization shows 10 - 99% improvement when the input is at least 384 bytes.
> 
> | input               | 64         | 128        | 256        | 384        | 511        | 512        | 1,024      |
> | ------------- | ---------- | ---------- | ---------- | ---------- | ---------- | ---------- | ---------- |
> |  improvement  | 1.60%      | 0.00%      | 0.00%      | 15.24%     | 10.76%     | 34.32%     | 72.39%     |
> 
> | input               | 2,048      | 4,096      | 8,192      | 16,384     | 32,768     | 65,536     |
> | ------------- | ---------- | ---------- | ---------- | ---------- | ---------- | ---------- |
> |  improvement  | 84.96%     | 92.59%     | 96.19%     | 98.02%     | 99.32%     | 98.36%     |
> 
> 
> Baseline
> 
> Benchmark                    (count)   Mode  Cnt       Score      Error   Units
> TestCRC32C.testCRC32CUpdate       64  thrpt   12  196575.739 ? 1824.113  ops/ms
> TestCRC32C.testCRC32CUpdate      128  thrpt   12  123666.570 ?    2.730  ops/ms
> TestCRC32C.testCRC32CUpdate      256  thrpt   12   70188.989 ?    2.002  ops/ms
> TestCRC32C.testCRC32CUpdate      384  thrpt   12   49000.690 ?    1.421  ops/ms
> TestCRC32C.testCRC32CUpdate      511  thrpt   12   34106.279 ?   25.390  ops/ms
> TestCRC32C.testCRC32CUpdate      512  thrpt   12   37638.349 ?    1.039  ops/ms
> TestCRC32C.testCRC32CUpdate     1024  thrpt   12   19526.513 ?    0.439  ops/ms
> TestCRC32C.testCRC32CUpdate     2048  thrpt   12    9951.392 ?    4.803  ops/ms
> TestCRC32C.testCRC32CUpdate     4096  thrpt   12    5023.268 ?    0.240  ops/ms
> TestCRC32C.testCRC32CUpdate     8192  thrpt   12    2523.877 ?    0.062  ops/ms
> TestCRC32C.testCRC32CUpdate    16384  thrpt   12    1265.011 ?    0.047  ops/ms
> TestCRC32C.testCRC32CUpdate    32768  thrpt   12     632.291 ?    0.058  ops/ms
> TestCRC32C.testCRC32CUpdate    65536  thrpt   12     315.396 ?    0.160  ops/ms
> 
> 
> Crypto pmull
> 
> Benchmark                    (count)   Mode  Cnt       Score     Error   Units
> TestCRC32C.testCRC32CUpdate       64  thrpt   12  199726.599 ? 166.477  ops/ms
> TestCRC32C.testCRC32CUpdate      128  thrpt   12  123669.385 ?   1.821  ops/ms
> TestCRC32C.testCRC32CUpdate      256  thrpt   12   70188.727 ?   1.313  ops/ms
> TestCRC32C.testCRC32CUpdate      384  thrpt   12   56468.837 ?  76.524  ops/ms
> TestCRC32C.testCRC32CUpdate      511  thrpt   12   37777.205 ? 406.431  ops/ms
> TestCRC32C.testCRC32CUpdate      512  thrpt   12   50554.555 ?  17.169  ops/ms
> TestCRC32C.testCRC32CUpdate     1024  thrpt   12   33661.006 ? 140.471  ops/ms
> TestCRC32C.testCRC32CUpdate     2048  thrpt   12   18406.482 ? 205.952  ops/ms
> TestCRC32C.testCRC32CUpdate     4096  thrpt   12    9674.159 ?  20.390  ops/ms
> TestCRC32C.testCRC32CUpdate     8192  thrpt   12    4951.562 ?   6.566  ops/ms
> TestCRC32C.testCRC32CUpdate    16384  thrpt   12    2504.970 ?   1.883  ops/ms
> TestCRC32C.testCRC32CUpdate    32768  thrpt   12    1260.278 ?   0.484  ops/ms
> TestCRC32C.testCRC32CUpdate    65536  thrpt   12     625.608 ?   0.300  ops/ms

This pull request has now been integrated.

Changeset: f3abc406
Author:    Yi-Fan Tsai <yftsai at amazon.com>
Committer: Paul Hohensee <phh at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f3abc4063de658418283aee1f552c4b4976e5211
Stats:     78 lines in 3 files changed: 77 ins; 0 del; 1 mod

8302783: Improve CRC32C intrinsic with crypto pmull on AArch64

Reviewed-by: simonis, phh

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

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

From dholmes at openjdk.org  Thu Mar  2 22:47:05 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 2 Mar 2023 22:47:05 GMT
Subject: RFR: 8286781: Replace the deprecated/obsolete gethostbyname and
 inet_addr calls
Message-ID: <hTpw51fgF4gk1I60vdXDpEWpZlISh4v_eNfoOQw2hds=.9a07f8c1-0af4-454b-8a9e-37d83403f7c0@github.com>

We can replace `gethostbyname`, which is deprecated on Windows and Linux, with `getaddrinfo`. This API is available on all supported platforms and so can be placed in shared code. @djelinski pointed out that `getaddrinfo` can resolve both IP addresses and host names so the two step approach used in `networkStream::connect` is not necessary and we can do away with `os::get_host_by_name()` completely.

The build is updated to enable winsock deprecation warnings, and now we need to use `ws2_32.lib` we can drop `wsock32.lib` (as it is basically a subset - again thanks @djelinski ).

Testing
    - all Oracle builds in tiers 1-5
    - All GHA builds

The actual code change has to be manually tested because the code is only used by Ideal Graph Printing to connect to the Ideal Graph Visualizer. I've manually tested on Windows and Linux and @tobiasholenstein tested macOS.

Thanks.

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

Commit messages:
 - 8286781: Replace the deprecated/obsolete gethostbyname and inet_addr calls

Changes: https://git.openjdk.org/jdk/pull/12842/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12842&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8286781
  Stats: 41 lines in 6 files changed: 13 ins; 17 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/12842.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12842/head:pull/12842

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

From dholmes at openjdk.org  Thu Mar  2 22:53:05 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 2 Mar 2023 22:53:05 GMT
Subject: RFR: 8286781: Replace the deprecated/obsolete gethostbyname and
 inet_addr calls
In-Reply-To: <hTpw51fgF4gk1I60vdXDpEWpZlISh4v_eNfoOQw2hds=.9a07f8c1-0af4-454b-8a9e-37d83403f7c0@github.com>
References: <hTpw51fgF4gk1I60vdXDpEWpZlISh4v_eNfoOQw2hds=.9a07f8c1-0af4-454b-8a9e-37d83403f7c0@github.com>
Message-ID: <dMVXktyEDykRhegtZ2XT4bHXiZrlcAo2bFRnZrBBhWQ=.56bcb75d-18bd-4d1e-bca7-6a53ff6aca49@github.com>

On Thu, 2 Mar 2023 22:35:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

> We can replace `gethostbyname`, which is deprecated on Windows and Linux, with `getaddrinfo`. This API is available on all supported platforms and so can be placed in shared code. @djelinski pointed out that `getaddrinfo` can resolve both IP addresses and host names so the two step approach used in `networkStream::connect` is not necessary and we can do away with `os::get_host_by_name()` completely.
> 
> The build is updated to enable winsock deprecation warnings, and now we need to use `ws2_32.lib` we can drop `wsock32.lib` (as it is basically a subset - again thanks @djelinski ).
> 
> Testing
>     - all Oracle builds in tiers 1-5
>     - All GHA builds
> 
> The actual code change has to be manually tested because the code is only used by Ideal Graph Printing to connect to the Ideal Graph Visualizer. I've manually tested on Windows and Linux and @tobiasholenstein tested macOS.
> 
> Thanks.

I forgot to mention I have no way to test on AIX so if someone were able to do that, that would be good. Thanks. I know it builds okay.

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

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

From dholmes at openjdk.org  Fri Mar  3 00:34:22 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 3 Mar 2023 00:34:22 GMT
Subject: RFR: JDK-8302801: Remove fdlibm C sources [v3]
In-Reply-To: <3ePedpVieHDjKofsLHTwEI2xiCfEZ047Ewb4hwxSjiQ=.368af0f3-935e-4be8-9bc7-dbda01decf5c@github.com>
References: <fFJoo_g2Rqg062mR5ftOMCF6y9JrrlpW6wO1Vz0OeMI=.3a124adf-6ddf-4ab2-90d9-d26a400d09c7@github.com>
 <3ePedpVieHDjKofsLHTwEI2xiCfEZ047Ewb4hwxSjiQ=.368af0f3-935e-4be8-9bc7-dbda01decf5c@github.com>
Message-ID: <SQBv8zAPbjba-Lfaskmx0ikv-sHXw1sqd5bJX18GtNY=.0e2d5f9a-ed79-45c6-b40b-faf39af4af69@github.com>

On Thu, 2 Mar 2023 19:55:39 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> While the review of https://github.com/openjdk/jdk/pull/12800 finishes up, I thought I'd get out for the review the next phase of the FDLIBM port: removing the FDLIBM C sources from the repo.
>> 
>> A repo with the changes for JDK-8302027 and this PR successful build on the default set of platform and successfully run tier 1 tests, which includes tests of the math library.
>> 
>> There are a few remaining references to the case-independent string "fdlibm" in the make directory and HotSpot sources. HotSpot contains a partial fork for FDLIBM (a tine of FDLIBM?) to use for intrinsics. The remaining make machinery contains logic to determine what set of gcc options can be used for the compile.
>> 
>> The intention of this change is to remove use of FDLIBM for the core libraries.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

Hotspot changes are okay but I'm a bit confused about what the hotspot code will now be used for?

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

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

From dholmes at openjdk.org  Fri Mar  3 00:41:06 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 3 Mar 2023 00:41:06 GMT
Subject: RFR: JDK-8302801: Remove fdlibm C sources [v3]
In-Reply-To: <3ePedpVieHDjKofsLHTwEI2xiCfEZ047Ewb4hwxSjiQ=.368af0f3-935e-4be8-9bc7-dbda01decf5c@github.com>
References: <fFJoo_g2Rqg062mR5ftOMCF6y9JrrlpW6wO1Vz0OeMI=.3a124adf-6ddf-4ab2-90d9-d26a400d09c7@github.com>
 <3ePedpVieHDjKofsLHTwEI2xiCfEZ047Ewb4hwxSjiQ=.368af0f3-935e-4be8-9bc7-dbda01decf5c@github.com>
Message-ID: <zkwCY1tlEhTj2nLNpXr749z6K3QbWtouC2XHyygBdhw=.0d839578-6a93-4d97-b669-5e8aa6cc0f91@github.com>

On Thu, 2 Mar 2023 19:55:39 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> While the review of https://github.com/openjdk/jdk/pull/12800 finishes up, I thought I'd get out for the review the next phase of the FDLIBM port: removing the FDLIBM C sources from the repo.
>> 
>> A repo with the changes for JDK-8302027 and this PR successful build on the default set of platform and successfully run tier 1 tests, which includes tests of the math library.
>> 
>> There are a few remaining references to the case-independent string "fdlibm" in the make directory and HotSpot sources. HotSpot contains a partial fork for FDLIBM (a tine of FDLIBM?) to use for intrinsics. The remaining make machinery contains logic to determine what set of gcc options can be used for the compile.
>> 
>> The intention of this change is to remove use of FDLIBM for the core libraries.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

Actually this is really my lack of understanding about the current code: why do we intrinsify `Math` but not `StrictMath`?

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

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

From dholmes at openjdk.org  Fri Mar  3 01:03:16 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 3 Mar 2023 01:03:16 GMT
Subject: RFR: JDK-8302989: Add missing INCLUDE_CDS checks [v3]
In-Reply-To: <i619e3l156DnYwsJB7id-5AahSUqdZINDXaDtRo56DA=.f4fdf096-c1f9-48e0-b75a-58776e5f3dd4@github.com>
References: <kBV8fNo_CWJL2MoXgAckFhuAFgQ3RGZjFKAKnl8xfV8=.233bb652-8508-4065-92ea-7873b1c765f3@github.com>
 <i619e3l156DnYwsJB7id-5AahSUqdZINDXaDtRo56DA=.f4fdf096-c1f9-48e0-b75a-58776e5f3dd4@github.com>
Message-ID: <AIWt3I5uWb6Mm2RF-QT_56np5i3oYs3Mmtqqf84W5xA=.ecf61d5f-6d7c-4b87-8638-4c687b3aaa89@github.com>

On Thu, 2 Mar 2023 16:27:32 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The cds only coding in hotspot is usually guarded with the INCLUDE_CDS macro so that it can be removed at compile time in case the correct configure flags are set.
>> However at some places INCLUDE_CDS is missing and should be added.
>> 
>> One question - should (additionally to the UseSharedSpaces code section)  the DumpSharedSpaces code sections be guarded as well with INCLUDE_CDS macros ?
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust some cds related vars

src/hotspot/share/runtime/arguments.cpp line 1460:

> 1458: #if INCLUDE_CDS
> 1459:     UseSharedSpaces = false;
> 1460: #endif

This doesn't make sense - the entire `no_shared_spaces` method is only meaningful on a JVM with CDS. Otherwise `-Xshare:on` should immediately be rejected. ??

src/hotspot/share/runtime/arguments.cpp line 2675:

> 2673:       xshare_auto_cmd_line = true;
> 2674:     // -Xshare:off
> 2675:     } else if (match_option(option, "-Xshare:off")) {

These flags should all immediately be rejected if used in a non-CDS build. Yes this is pre-existing but it now looks totally broken with the new changes. There should be something like:

#ifndef INCLUDE_CDS
} else if (match_option(option, "-Xshare")) {  // or whatever we need to match the prefix only
  warning("Option %s is not supported in this VM", option);
#else 
// process flags as usual
#endif

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

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

From kvn at openjdk.org  Fri Mar  3 01:05:12 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 3 Mar 2023 01:05:12 GMT
Subject: RFR: JDK-8302801: Remove fdlibm C sources [v3]
In-Reply-To: <SQBv8zAPbjba-Lfaskmx0ikv-sHXw1sqd5bJX18GtNY=.0e2d5f9a-ed79-45c6-b40b-faf39af4af69@github.com>
References: <fFJoo_g2Rqg062mR5ftOMCF6y9JrrlpW6wO1Vz0OeMI=.3a124adf-6ddf-4ab2-90d9-d26a400d09c7@github.com>
 <3ePedpVieHDjKofsLHTwEI2xiCfEZ047Ewb4hwxSjiQ=.368af0f3-935e-4be8-9bc7-dbda01decf5c@github.com>
 <SQBv8zAPbjba-Lfaskmx0ikv-sHXw1sqd5bJX18GtNY=.0e2d5f9a-ed79-45c6-b40b-faf39af4af69@github.com>
Message-ID: <zLhbTONwBdDToc6BgrFtdxGqJN1g_sSR6MvgihHbu3Q=.fba60f45-92d6-4b7d-89c5-63397f0efdf4@github.com>

On Fri, 3 Mar 2023 00:31:12 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hotspot changes are okay but I'm a bit confused about what the hotspot code will now be used for?

`SharedRuntime::*` runtime math functions are used on platforms where there are no HW instructions or intrinsics (Zero VM). JIT compiled code may also call them in such case (or when intrinsics disabled with flag):
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/library_call.cpp#L1815

Consider them as default intrinsics for all platforms (since they are written in C). They are faster than interpreting bytecode.

They are also needed for results consistency - the same code is used by Interpreter and JITed code.

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

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

From iklam at openjdk.org  Fri Mar  3 01:16:13 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 3 Mar 2023 01:16:13 GMT
Subject: RFR: JDK-8302989: Add missing INCLUDE_CDS checks [v2]
In-Reply-To: <bOoXqCQif8I39pq6lY3DKkR5MT3Dot24sDT6f5AE95Y=.5df81928-75f0-421e-b35b-eb4d89581b56@github.com>
References: <kBV8fNo_CWJL2MoXgAckFhuAFgQ3RGZjFKAKnl8xfV8=.233bb652-8508-4065-92ea-7873b1c765f3@github.com>
 <kC0i6N44wUExbim6e2SCu5QCCpEGxRTEeRCGMRe__Fs=.46f19345-c54b-4e9b-bd8d-5c38dc4846a1@github.com>
 <D94A_iYhqCAvpWC87xWqEIAs7DQtw68zdetsZQc5pQ8=.8a39311a-60b2-4d83-969e-f48a74278d5b@github.com>
 <Rr2AaOX0OnWVBM3-GqzimZpF_T1m4XVLh7o_cnRFyLI=.318bc73f-61e2-4347-b119-74d908d963ff@github.com>
 <BuCxJoq8h8XasiTZ_6foYa1BJ0BI7h4vyQik68Gct7E=.2b5745de-9059-4aa5-a196-43c15a5122ec@github.com>
 <bOoXqCQif8I39pq6lY3DKkR5MT3Dot24sDT6f5AE95Y=.5df81928-75f0-421e-b35b-eb4d89581b56@github.com>
Message-ID: <pwd98JZ1LseZH48Lw9cmG_hHKrtg1StY1FoxAjAfurQ=.afa376d9-c28d-4a58-91a3-2921ba70ee1b@github.com>

On Thu, 2 Mar 2023 16:27:32 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> You need to remove the `extern` keyword, and add the definition of `= false` in globalDefinitions.hpp.
>> 
>> Then, the corresponding definition should be removed from globalDefinitions.cpp.
>
> Hi Ioi, I adjusted the *SharedSpaces in  globalDefinitions.cpp / globalDefinitions.hpp  .

I am on vacation now so I won?t be able to follow up with the review. Please feel free to integrate after you get enough reviews.

Just a general comment. For blocks that are enclosed with ?if (UseSharedSpace) {?}?, there?s no need to put them inside #if as these blocks will be elided by the C++ compiler. That way the code will be less messy.

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

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

From darcy at openjdk.org  Fri Mar  3 02:06:06 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 3 Mar 2023 02:06:06 GMT
Subject: RFR: JDK-8302801: Remove fdlibm C sources [v3]
In-Reply-To: <zkwCY1tlEhTj2nLNpXr749z6K3QbWtouC2XHyygBdhw=.0d839578-6a93-4d97-b669-5e8aa6cc0f91@github.com>
References: <fFJoo_g2Rqg062mR5ftOMCF6y9JrrlpW6wO1Vz0OeMI=.3a124adf-6ddf-4ab2-90d9-d26a400d09c7@github.com>
 <3ePedpVieHDjKofsLHTwEI2xiCfEZ047Ewb4hwxSjiQ=.368af0f3-935e-4be8-9bc7-dbda01decf5c@github.com>
 <zkwCY1tlEhTj2nLNpXr749z6K3QbWtouC2XHyygBdhw=.0d839578-6a93-4d97-b669-5e8aa6cc0f91@github.com>
Message-ID: <ApCyv1epyNYBqDuKp2-ICZ21f_8U5d9cmT1oN69p4DM=.ef507018-3dde-4398-af68-c11e0783d356@github.com>

On Fri, 3 Mar 2023 00:38:18 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Actually this is really my lack of understanding about the current code: why do we intrinsify `Math` but not `StrictMath`?

In brief, the Math methods are allowed implementation flexibility in terms of their algorithm but the StrictMath methods are not. The "interesting" StrictMath methods are required to use the FDLIBM algorithms.

(One exception is StrictMath.sqrt. Since sqrt is required to be correctly rounded, there is only one correct answer for any given argument and StrictMath.sqrt can be intrinsified to a hardware sqrt instruction just like Math.sqrt can.)

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

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

From darcy at openjdk.org  Fri Mar  3 02:10:15 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 3 Mar 2023 02:10:15 GMT
Subject: RFR: JDK-8302801: Remove fdlibm C sources [v3]
In-Reply-To: <zLhbTONwBdDToc6BgrFtdxGqJN1g_sSR6MvgihHbu3Q=.fba60f45-92d6-4b7d-89c5-63397f0efdf4@github.com>
References: <fFJoo_g2Rqg062mR5ftOMCF6y9JrrlpW6wO1Vz0OeMI=.3a124adf-6ddf-4ab2-90d9-d26a400d09c7@github.com>
 <3ePedpVieHDjKofsLHTwEI2xiCfEZ047Ewb4hwxSjiQ=.368af0f3-935e-4be8-9bc7-dbda01decf5c@github.com>
 <SQBv8zAPbjba-Lfaskmx0ikv-sHXw1sqd5bJX18GtNY=.0e2d5f9a-ed79-45c6-b40b-faf39af4af69@github.com>
 <zLhbTONwBdDToc6BgrFtdxGqJN1g_sSR6MvgihHbu3Q=.fba60f45-92d6-4b7d-89c5-63397f0efdf4@github.com>
Message-ID: <nk0rENG0ld2v3qzZhM1dOhGTmPd3pz_Ov5IJv46P3WU=.c71cae7e-0228-4417-9283-745fd813548b@github.com>

On Fri, 3 Mar 2023 01:02:40 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Hotspot changes are okay but I'm a bit confused about what the hotspot code will now be used for?

I'm not 100% positive if the current __kernel_rem_pio2 code would be in use. IIRC, back when we used the fsin/fcos instructions to intrinsify sin/cos on the x87 FPU, to meet Java semantics we needed to do argument reduction into the range supported by fsin/fcos. Perhaps  __kernel_rem_pio2 is a hold-over from that time? I believe my recent sin/cos algorithms for instrincs wouldn't need to use these pathways.

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

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

From eliu at openjdk.org  Fri Mar  3 03:02:13 2023
From: eliu at openjdk.org (Eric Liu)
Date: Fri, 3 Mar 2023 03:02:13 GMT
Subject: RFR: 8301012: [vectorapi]: Intrinsify CompressBitsV/ExpandBitsV
 and add the AArch64 SVE backend implementation
In-Reply-To: <RaPIEa3D1wT6isue-1l_ILYJ6FCWSeNJ-T8QXtoxnUk=.05a804b5-9b2f-4486-aad4-53f00a3a6ab3@github.com>
References: <RaPIEa3D1wT6isue-1l_ILYJ6FCWSeNJ-T8QXtoxnUk=.05a804b5-9b2f-4486-aad4-53f00a3a6ab3@github.com>
Message-ID: <-sLl5-N5rwoXIV6jNaUOaXOybanJif2SBVTVque9L84=.3bce4551-05c1-4bec-849d-0869be75a9ca@github.com>

On Mon, 6 Feb 2023 17:23:20 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

> This patch adds mid-end compiler vector IR nodes for the scalar CompressBits and ExpandBits nodes - CompressBitsV and ExpandBitsV and also adds aarch64 backend support for these nodes using SVE2 instructions (included in the svebitperm feature). As there are direct instructions in SVE2 that map to these operations, a huge speed up in performance can be observed and it might significantly benefit all those workloads that extensively run these operations on an SVE2(with svebitperm feature) supporting machine.
> 
> All the JTREG tests under "test/jdk/jdk/incubator/vector" pass successfully with this patch on an SVE2 machine.
> The JMH tests - COMPRESS_BITS and EXPAND_BITS from [1] and [2] were run on a 128-bit vector length, SVE2 and svebitperm supporting aarch64 machine. Following are the gains observed with this patch -
> 
> 
> Benchmark                       (length)  Mode    Cnt   Gain
> IntMaxVector.COMPRESS_BITS      1024      thrpt   15    81.68x
> IntMaxVector.EXPAND_BITS        1024      thrpt   15    85.65x
> LongMaxVector.COMPRESS_BITS     1024      thrpt   15    70.78x
> LongMaxVector.EXPAND_BITS       1024      thrpt   15    76.31x
> 
> 
> The "Gain" column is the ratio between the throughput of benchmark runs with this patch and that of benchmark runs without this patch. This patch does not change the performance of these operations for all other machines that do not support these instructions or when run on a different architecture.
> With this patch, vectorization of CompressBits and ExpandBits operations happens only through vectorapi for aarch64. Autovectorization does not take place as the current JDK source does not contain aarch64 backend implementation for scalar CompressBits and ExpandBits. However, this PR - https://github.com/openjdk/jdk/pull/10537 adds aarch64 backend implementaton for CompressBits and ExpandBits and may lead to autovectorization of these nodes as well eventually but this PR is a standalone one and not dependent on the scalar implementation.
> 
> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/IntMaxVector.java 
> [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/LongMaxVector.java

Marked as reviewed by eliu (Committer).

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

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

From mdoerr at openjdk.org  Fri Mar  3 04:04:06 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 3 Mar 2023 04:04:06 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v7]
In-Reply-To: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
Message-ID: <VDkBLzoZWEGI7ujcZtK7k4OMOBAqEf-jzPjlsjeU9NU=.9272e1f9-6f75-40f1-acc7-9efc01880f10@github.com>

> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
> 
> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
> 
> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
> 
> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Will get addressed separately: [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
> 
> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
> 
> I had to make changes to shared code and code for other platforms:
> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit.

Martin Doerr 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 branch 'master' into PPC64_Panama
 - Add test for HFA corner cases.
 - Minor cleanup.
 - HFA: Add support for nested structures. See JDK-8300294.
 - Remove size restriction for structs. Add TODO for Big Endian.
 - Clean fix for NativeMemorySegmentImpl issue with byteSize 0.
 - Initial Panama implementation.

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

Changes: https://git.openjdk.org/jdk/pull/12708/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=06
  Stats: 2247 lines in 59 files changed: 2139 ins; 1 del; 107 mod
  Patch: https://git.openjdk.org/jdk/pull/12708.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12708/head:pull/12708

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

From kbarrett at openjdk.org  Fri Mar  3 04:12:59 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 3 Mar 2023 04:12:59 GMT
Subject: RFR: 8302189: Mark assertion failures noreturn
Message-ID: <4gLeUT6_5s6WpG-b-0146d490ZRgBq_JON1-5P3Wgtk=.e0bc3fd3-fce0-47b8-9478-1de796128731@github.com>

Also 8302799: Refactor Debugging variable usage for noreturn crash reporting

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

Commit messages:
 - new implementation of Debugging
 - noreturn attributes

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

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

From kbarrett at openjdk.org  Fri Mar  3 04:21:06 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 3 Mar 2023 04:21:06 GMT
Subject: RFR: 8302189: Mark assertion failures noreturn
In-Reply-To: <4gLeUT6_5s6WpG-b-0146d490ZRgBq_JON1-5P3Wgtk=.e0bc3fd3-fce0-47b8-9478-1de796128731@github.com>
References: <4gLeUT6_5s6WpG-b-0146d490ZRgBq_JON1-5P3Wgtk=.e0bc3fd3-fce0-47b8-9478-1de796128731@github.com>
Message-ID: <QKLz54gTvEeylu4GXuzM0c627gCCgg8SOmpTz-rkXQQ=.ed569c43-a050-41f8-af75-f231225298b9@github.com>

On Fri, 3 Mar 2023 04:04:25 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Also 8302799: Refactor Debugging variable usage for noreturn crash reporting

make/hotspot/lib/CompileJvm.gmk line 103:

> 101: DISABLED_WARNINGS_xlc := tautological-compare shift-negative-value
> 102: 
> 103: DISABLED_WARNINGS_microsoft := 4624 4244 4291 4146 4127 4722

I forgot to mention this in the PR summary.  New warning suppression for
4722: 'function' : destructor never returns, potential memory leak
We have various destructors calling ShouldNotCallThis, ShouldNotReachHere,
or the like, which triggers this warning.  It might be possible to deal with
some (but not all) of those by deleting the destructor.  The warning doesn't
seem all that useful to us, so I just suppressed it.

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

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

From dholmes at openjdk.org  Fri Mar  3 04:38:07 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 3 Mar 2023 04:38:07 GMT
Subject: RFR: 8302189: Mark assertion failures noreturn
In-Reply-To: <4gLeUT6_5s6WpG-b-0146d490ZRgBq_JON1-5P3Wgtk=.e0bc3fd3-fce0-47b8-9478-1de796128731@github.com>
References: <4gLeUT6_5s6WpG-b-0146d490ZRgBq_JON1-5P3Wgtk=.e0bc3fd3-fce0-47b8-9478-1de796128731@github.com>
Message-ID: <PhwlkTOKz7EsK0wAlY-IRGfno3c9TEqNf9WJIc3mVTg=.3f9273af-44e5-4d8f-beb4-0bc2b774b9d1@github.com>

On Fri, 3 Mar 2023 04:04:25 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Also 8302799: Refactor Debugging variable usage for noreturn crash reporting

A few initial comments while I try to digest this.

I don't use these particular debugging mechanism, neither Debugger nor BREAKPOINT, but it seems potentially problematic to me that the removed BREAKPOINTs happened after the error was reported, and IIUC the new mechanism will activate before the error is reported.

Thanks.

make/hotspot/lib/CompileJvm.gmk line 103:

> 101: DISABLED_WARNINGS_xlc := tautological-compare shift-negative-value
> 102: 
> 103: DISABLED_WARNINGS_microsoft := 4624 4244 4291 4146 4127 4722

It is annoying that we don't document what these warnings are. :(

src/hotspot/share/utilities/debug.cpp line 85:

> 83:   if (is_enabled()) {
> 84:     fatal("Multiple Debugging contexts");
> 85:   }

This seems too restrictive as you could hit different DebuggingContexts in different threads. ??

src/hotspot/share/utilities/debug.cpp line 290:

> 288:  private:
> 289:   ResourceMark _rm;
> 290:   DebuggingContext _debugging;

Why a different initialization syntax here?

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

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

From mdoerr at openjdk.org  Fri Mar  3 04:43:40 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 3 Mar 2023 04:43:40 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v8]
In-Reply-To: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
Message-ID: <gdBxxV9X7uS5e5dSxdXK-7CFBTTH95EuI9gzPbUpHjM=.78ab4118-9325-45c7-a607-5be4fe050a9e@github.com>

> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
> 
> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
> 
> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
> 
> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Will get addressed separately: [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
> 
> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
> 
> I had to make changes to shared code and code for other platforms:
> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit.

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  Fix merge bug.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12708/files
  - new: https://git.openjdk.org/jdk/pull/12708/files/d71f0f0a..f23edd8e

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

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

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

From darcy at openjdk.org  Fri Mar  3 06:01:17 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 3 Mar 2023 06:01:17 GMT
Subject: RFR: 8302191: Performance degradation for float/double modulo on
 Linux [v5]
In-Reply-To: <o8gBuzq9Pfc4aYnmo3cPGXwVo4cbouH0delXsoz4kEI=.7a6c9412-f7c4-4c07-91ea-8cb5c0b9da6a@github.com>
References: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
 <o8gBuzq9Pfc4aYnmo3cPGXwVo4cbouH0delXsoz4kEI=.7a6c9412-f7c4-4c07-91ea-8cb5c0b9da6a@github.com>
Message-ID: <eGuNxq2-JbQJlW1WwdUlEUuMfZPkznLpcxbUs9tQc1c=.ed231601-04b4-49d6-8664-7d5f44d455da@github.com>

On Wed, 1 Mar 2023 12:03:54 GMT, Jan Kratochvil <duke at openjdk.org> wrote:

>> I have OCA already processed/approved. I am not Author but my Author request is being processed these days (sent to Rob McKenna).
>> I did regression test x86_64 OpenJDK-8. I will leave other regression testing on GHA.
>> The patch (and former GCC performance regression) affects only x86_64+i686.
>
> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright author.

src/hotspot/cpu/x86/sharedRuntime_x86.cpp line 129:

> 127: // GCC had slow fmod():
> 128: // since https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=4f2611b6e872c40e0bf4da38ff05df8c8fe0ee64
> 129: // until https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=8020c9c42349f51f75239b9d35a2be41848a97bd

We typically list such URLs in the bug database rather than the source code.

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

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

From kbarrett at openjdk.org  Fri Mar  3 07:33:06 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 3 Mar 2023 07:33:06 GMT
Subject: RFR: 8286781: Replace the deprecated/obsolete gethostbyname and
 inet_addr calls
In-Reply-To: <hTpw51fgF4gk1I60vdXDpEWpZlISh4v_eNfoOQw2hds=.9a07f8c1-0af4-454b-8a9e-37d83403f7c0@github.com>
References: <hTpw51fgF4gk1I60vdXDpEWpZlISh4v_eNfoOQw2hds=.9a07f8c1-0af4-454b-8a9e-37d83403f7c0@github.com>
Message-ID: <KCx5TxPnI3Mtj_Ksa9tru_IysRVy7w2hBBhCaI22u9o=.0f73d4aa-fac9-4f2d-b731-59b0daa820a1@github.com>

On Thu, 2 Mar 2023 22:35:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

> We can replace `gethostbyname`, which is deprecated on Windows and Linux, with `getaddrinfo`. This API is available on all supported platforms and so can be placed in shared code. @djelinski pointed out that `getaddrinfo` can resolve both IP addresses and host names so the two step approach used in `networkStream::connect` is not necessary and we can do away with `os::get_host_by_name()` completely.
> 
> The build is updated to enable winsock deprecation warnings, and now we need to use `ws2_32.lib` we can drop `wsock32.lib` (as it is basically a subset - again thanks @djelinski ).
> 
> Testing
>     - all Oracle builds in tiers 1-5
>     - All GHA builds
> 
> The actual code change has to be manually tested because the code is only used by Ideal Graph Printing to connect to the Ideal Graph Visualizer. I've manually tested on Windows and Linux and @tobiasholenstein tested macOS.
> 
> Thanks.

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

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

From mbaesken at openjdk.org  Fri Mar  3 08:07:20 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 3 Mar 2023 08:07:20 GMT
Subject: RFR: JDK-8302989: Add missing INCLUDE_CDS checks [v2]
In-Reply-To: <pwd98JZ1LseZH48Lw9cmG_hHKrtg1StY1FoxAjAfurQ=.afa376d9-c28d-4a58-91a3-2921ba70ee1b@github.com>
References: <kBV8fNo_CWJL2MoXgAckFhuAFgQ3RGZjFKAKnl8xfV8=.233bb652-8508-4065-92ea-7873b1c765f3@github.com>
 <kC0i6N44wUExbim6e2SCu5QCCpEGxRTEeRCGMRe__Fs=.46f19345-c54b-4e9b-bd8d-5c38dc4846a1@github.com>
 <D94A_iYhqCAvpWC87xWqEIAs7DQtw68zdetsZQc5pQ8=.8a39311a-60b2-4d83-969e-f48a74278d5b@github.com>
 <Rr2AaOX0OnWVBM3-GqzimZpF_T1m4XVLh7o_cnRFyLI=.318bc73f-61e2-4347-b119-74d908d963ff@github.com>
 <BuCxJoq8h8XasiTZ_6foYa1BJ0BI7h4vyQik68Gct7E=.2b5745de-9059-4aa5-a196-43c15a5122ec@github.com>
 <bOoXqCQif8I39pq6lY3DKkR5MT3Dot24sDT6f5AE95Y=.5df81928-75f0-421e-b35b-eb4d89581b56@github.com>
 <pwd98JZ1LseZH48Lw9cmG_hHKrtg1StY1FoxAjAfurQ=.afa376d9-c28d-4a58-91a3-2921ba70ee1b@github.com>
Message-ID: <Hsb8tKrjd4tpl3WjBpBxc1JdHJObEzKI3XDPX0n13ZY=.f9840232-2772-464f-a3e6-98ddd679c4ba@github.com>

On Fri, 3 Mar 2023 01:13:18 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Hi Ioi, I adjusted the *SharedSpaces in  globalDefinitions.cpp / globalDefinitions.hpp  .
>
> I am on vacation now so I won?t be able to follow up with the review. Please feel free to integrate after you get enough reviews.
> 
> Just a general comment. For blocks that are enclosed with ?if (UseSharedSpace) {?}?, there?s no need to put them inside #if as these blocks will be elided by the C++ compiler. That way the code will be less messy.

Hi Ioi, thanks for the feedback.  Mostly you are correct, the `#if`  blocks are not needed any more at most places. Should I remove them at least from my patch now or keep them?  But I think there are a few exceptions - at some places the coding attempts to set the *SharedSpaces flags and this does not compile any more after switching to const.  So there the  `#if`  blocks have to stay.

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

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

From aivanov at openjdk.org  Fri Mar  3 08:28:19 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 3 Mar 2023 08:28:19 GMT
Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments
In-Reply-To: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
Message-ID: <zGeNBZ-3vU9GABEYOeUorRTJAMzyQzN-97Rx6qKisaY=.87335367-efc7-4c48-b866-de39a9d9c9e2@github.com>

On Thu, 2 Mar 2023 12:03:44 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
> 
> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
> 
> 
>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>     @@ -17084,7 +17084,7 @@
>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>      <div class="block"><code>readObject</code> is called to restore the state of the
>     - (@code BasicPermission} from a stream.</div>
>     + <code>BasicPermission</code> from a stream.</div>
>      <dl class="notes">
>      <dt>Parameters:</dt>
>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
> 
> Notes
> -----
> 
> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
> * I will update copyright years after (and if) the fix had been approved, as required.

Looks good to me.

I looked through all the changes, paying more attention to the client area.

src/java.base/share/classes/java/lang/invoke/BootstrapMethodInvoker.java line 257:

> 255: 
> 256:     /**
> 257:      * @return true iff the BSM method type exactly matches

I assume ?iff? should ?if??

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2866:

> 2864:      * Merge multiple abstract methods. The preferred method is a method that is a subsignature
> 2865:      * of all the other signatures and whose return type is more specific {@link MostSpecificReturnCheck}.
> 2866:      * The resulting preferred method has a thrown clause that is the intersection of the merged

Is it ??has a {@code throws} clause???

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

Marked as reviewed by aivanov (Reviewer).

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

From mbaesken at openjdk.org  Fri Mar  3 08:37:25 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 3 Mar 2023 08:37:25 GMT
Subject: RFR: JDK-8302989: Add missing INCLUDE_CDS checks [v3]
In-Reply-To: <AIWt3I5uWb6Mm2RF-QT_56np5i3oYs3Mmtqqf84W5xA=.ecf61d5f-6d7c-4b87-8638-4c687b3aaa89@github.com>
References: <kBV8fNo_CWJL2MoXgAckFhuAFgQ3RGZjFKAKnl8xfV8=.233bb652-8508-4065-92ea-7873b1c765f3@github.com>
 <i619e3l156DnYwsJB7id-5AahSUqdZINDXaDtRo56DA=.f4fdf096-c1f9-48e0-b75a-58776e5f3dd4@github.com>
 <AIWt3I5uWb6Mm2RF-QT_56np5i3oYs3Mmtqqf84W5xA=.ecf61d5f-6d7c-4b87-8638-4c687b3aaa89@github.com>
Message-ID: <wN7sSDJ_BOED2YDdcMwWxVAfgS4FBTs6nMwKQOhI7vc=.c198741d-f758-4104-a6a2-17d2f32cb0da@github.com>

On Fri, 3 Mar 2023 00:50:09 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   adjust some cds related vars
>
> src/hotspot/share/runtime/arguments.cpp line 1460:
> 
>> 1458: #if INCLUDE_CDS
>> 1459:     UseSharedSpaces = false;
>> 1460: #endif
> 
> This doesn't make sense - the entire `no_shared_spaces` method is only meaningful on a JVM with CDS. Otherwise `-Xshare:on` should immediately be rejected. ??

Hi David, unfortunately this has to stay for now, otherwise we would try to set a const in the CDS-disabled build, this does not compile.
Maybe it would make sense to guard the whole function `no_shared_spaces`  and adjust the calls/usages but I would prefer a separate issue for this.

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

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

From eosterlund at openjdk.org  Fri Mar  3 08:51:37 2023
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 3 Mar 2023 08:51:37 GMT
Subject: RFR: 8302780: Add support for vectorized arraycopy GC barriers
 [v9]
In-Reply-To: <SU-lpFUY3nGTCSM5k7HrOR2xGgNhPFRNDFUa6JBNEMQ=.2ceac514-334b-4201-8f7b-f17b9ebf3505@github.com>
References: <SU-lpFUY3nGTCSM5k7HrOR2xGgNhPFRNDFUa6JBNEMQ=.2ceac514-334b-4201-8f7b-f17b9ebf3505@github.com>
Message-ID: <GDdK137W1CzKue6dDF57b1M8cK93-iQQb8FyU004Oig=.22fd7da5-437d-4b04-b637-54562928ee61@github.com>

> So far, the arraycopy stubs have performed some kind of bulk pre/post barriers for arraycopy, which have been good enough, and allowed the copying itself to be done with plain loads and stores. For generational ZGC, this approach is not good enough, and we need barriers for the actual copying, but instead don't need the pre/post barriers. To prepare the JVM for generational ZGC, we need to add an API for arraycopy barriers.

Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:

  Remove rscratch aliasing

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12670/files
  - new: https://git.openjdk.org/jdk/pull/12670/files/d03a5c29..28efe5d8

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

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

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

From eosterlund at openjdk.org  Fri Mar  3 08:51:38 2023
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 3 Mar 2023 08:51:38 GMT
Subject: RFR: 8302780: Add support for vectorized arraycopy GC barriers
 [v6]
In-Reply-To: <oFA1mEXKs3IoiaI-5ZlguJtks0_HpUWOcGPSExVlkl8=.480ca41c-0df2-4ce9-a59a-9b4a2ead3e6a@github.com>
References: <SU-lpFUY3nGTCSM5k7HrOR2xGgNhPFRNDFUa6JBNEMQ=.2ceac514-334b-4201-8f7b-f17b9ebf3505@github.com>
 <47e5gQJkZn7ldGv3n2cyQoZSAT9YpWWvIwXnbxhdGuQ=.643a4652-204b-4689-85a4-9378e8a587b3@github.com>
 <2g2QqIWkC2a7QyVzPkX-QW3LcMrti6-AMwuFPqe752o=.c63ae268-69be-4770-b642-544633c1cf8f@github.com>
 <1NdlCJpW9kP6N1prWI-pXRBFCooYppayETd83JdBEkE=.df3ed4f4-b685-4377-8284-40b4a3cedf5e@github.com>
 <RfZT2ILh5aTTS01W2zpsGMH6GgeBYnAhuqy_JGw6JZ4=.0a000408-dfba-4e66-8b18-40d6c92b703e@github.com>
 <oFA1mEXKs3IoiaI-5ZlguJtks0_HpUWOcGPSExVlkl8=.480ca41c-0df2-4ce9-a59a-9b4a2ead3e6a@github.com>
Message-ID: <VLzspIxqyo9K4LZmjpFa3tcQFyJD4Ij2nClmTBDEJso=.ab1e9570-e969-4344-857b-2e5508bb6a17@github.com>

On Thu, 2 Mar 2023 09:51:03 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Note also that the arraycopy stubs were already using r8 and r9 as temp registers. I just moved their use to GC barriers, so only they need to deal with their inherent scratchyness, while the temp registers used in the client code can use registers that are not scratchy, which was not the case before.
>
>> Note also that the arraycopy stubs were already using r8 and r9 as temp registers. I just moved their use to GC barriers, so only they need to deal with their inherent scratchyness, while the temp registers used in the client code can use registers that are not scratchy, which was not the case before.
> 
> The use of scratch registers in the AArch64 GC barriers was _already_ buggy and error prone, which resulted in serious and hard-to-find bugs. If you need to use the scratch registers in stubs, please, please don't alias them. Call them `rscratch1` and `rscratch2`.
> 
> Using scratch registers is safe as long as the code follows a couple of rules. Don't alias them, and if an inner macro is called from another macro, it's often safer to pass scratch registers to the inner macro explicitly. I know we're not consistent about this.

I see. Yeah I'd love to go more and more towards the more explicit approach. I removed the aliasing so we pass in rscratch1 and rscratch2 instead of r8 and r9.

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

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

From mbaesken at openjdk.org  Fri Mar  3 08:55:07 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 3 Mar 2023 08:55:07 GMT
Subject: RFR: JDK-8302989: Add missing INCLUDE_CDS checks [v4]
In-Reply-To: <kBV8fNo_CWJL2MoXgAckFhuAFgQ3RGZjFKAKnl8xfV8=.233bb652-8508-4065-92ea-7873b1c765f3@github.com>
References: <kBV8fNo_CWJL2MoXgAckFhuAFgQ3RGZjFKAKnl8xfV8=.233bb652-8508-4065-92ea-7873b1c765f3@github.com>
Message-ID: <dkwL4nBOs2Sh6R-tiu0xVFTioOXKZDXInHk6GW3BpWE=.c5d327fc-9e63-4c9d-b223-ea7aa8753b80@github.com>

> The cds only coding in hotspot is usually guarded with the INCLUDE_CDS macro so that it can be removed at compile time in case the correct configure flags are set.
> However at some places INCLUDE_CDS is missing and should be added.
> 
> One question - should (additionally to the UseSharedSpaces code section)  the DumpSharedSpaces code sections be guarded as well with INCLUDE_CDS macros ?

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Adjust arguments handling

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12691/files
  - new: https://git.openjdk.org/jdk/pull/12691/files/33eb5631..937ca5bf

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

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

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

From mbaesken at openjdk.org  Fri Mar  3 08:55:12 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 3 Mar 2023 08:55:12 GMT
Subject: RFR: JDK-8302989: Add missing INCLUDE_CDS checks [v3]
In-Reply-To: <AIWt3I5uWb6Mm2RF-QT_56np5i3oYs3Mmtqqf84W5xA=.ecf61d5f-6d7c-4b87-8638-4c687b3aaa89@github.com>
References: <kBV8fNo_CWJL2MoXgAckFhuAFgQ3RGZjFKAKnl8xfV8=.233bb652-8508-4065-92ea-7873b1c765f3@github.com>
 <i619e3l156DnYwsJB7id-5AahSUqdZINDXaDtRo56DA=.f4fdf096-c1f9-48e0-b75a-58776e5f3dd4@github.com>
 <AIWt3I5uWb6Mm2RF-QT_56np5i3oYs3Mmtqqf84W5xA=.ecf61d5f-6d7c-4b87-8638-4c687b3aaa89@github.com>
Message-ID: <BdKmjmfoj8NPYM5IVo6CMlvJoKZCrUpg5stS2qCtH5o=.c0e80813-2b34-446d-91d9-ae670e39b8d8@github.com>

On Fri, 3 Mar 2023 00:58:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   adjust some cds related vars
>
> src/hotspot/share/runtime/arguments.cpp line 2675:
> 
>> 2673:       xshare_auto_cmd_line = true;
>> 2674:     // -Xshare:off
>> 2675:     } else if (match_option(option, "-Xshare:off")) {
> 
> These flags should all immediately be rejected if used in a non-CDS build. Yes this is pre-existing but it now looks totally broken with the new changes. There should be something like:
> 
> #ifndef INCLUDE_CDS
> } else if (match_option(option, "-Xshare")) {  // or whatever we need to match the prefix only
>   warning("Option %s is not supported in this VM", option);
> #else 
> // process flags as usual
> #endif

Hi David,  I adjusted the coding following your request (however we need to use `#if`  not  `#ifndef`   here).

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

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

From prappo at openjdk.org  Fri Mar  3 09:41:06 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 3 Mar 2023 09:41:06 GMT
Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments
In-Reply-To: <zGeNBZ-3vU9GABEYOeUorRTJAMzyQzN-97Rx6qKisaY=.87335367-efc7-4c48-b866-de39a9d9c9e2@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
 <zGeNBZ-3vU9GABEYOeUorRTJAMzyQzN-97Rx6qKisaY=.87335367-efc7-4c48-b866-de39a9d9c9e2@github.com>
Message-ID: <Bzi35xfPH43Jupv65o86ErKvkPYaJdNV7cDIX7BBorc=.34e6522f-ec1e-41ee-b254-32713288bc79@github.com>

On Thu, 2 Mar 2023 16:23:17 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
>> 
>> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
>> 
>> 
>>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>>     @@ -17084,7 +17084,7 @@
>>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>>      <div class="block"><code>readObject</code> is called to restore the state of the
>>     - (@code BasicPermission} from a stream.</div>
>>     + <code>BasicPermission</code> from a stream.</div>
>>      <dl class="notes">
>>      <dt>Parameters:</dt>
>>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
>> 
>> Notes
>> -----
>> 
>> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
>> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
>> * I will update copyright years after (and if) the fix had been approved, as required.
>
> src/java.base/share/classes/java/lang/invoke/BootstrapMethodInvoker.java line 257:
> 
>> 255: 
>> 256:     /**
>> 257:      * @return true iff the BSM method type exactly matches
> 
> I assume ?iff? should ?if??

Here and elsewhere in this file "iff" might mean [if and only if](https://en.wikipedia.org/wiki/If_and_only_if), which would make sense. (FWIW, there are a few hundred occurrences of the word "iff" in src.)

@cl4es (Claes Redestad), as the author of those lines would you like to chime in?

Since Claes might read this, I note that when I changed unsupported `{@see}` to `{@link}` thoughtout this file, my IDE could not resolve one of the links: `java.lang.invoke.LambdaMetafactory#metafactory(MethodHandles.Lookup,String,Class,MethodType,MethodHandle,MethodType)`

While there's a similarly-name method with slightly different parameters, I refrained from using it:
`java.lang.invoke.LambdaMetafactory#metafactory(MethodHandles.Lookup,String,MethodType,MethodType,MethodHandle,MethodType)`.

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

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

From prappo at openjdk.org  Fri Mar  3 09:44:13 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 3 Mar 2023 09:44:13 GMT
Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments
In-Reply-To: <zGeNBZ-3vU9GABEYOeUorRTJAMzyQzN-97Rx6qKisaY=.87335367-efc7-4c48-b866-de39a9d9c9e2@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
 <zGeNBZ-3vU9GABEYOeUorRTJAMzyQzN-97Rx6qKisaY=.87335367-efc7-4c48-b866-de39a9d9c9e2@github.com>
Message-ID: <5TgKeBVz0u1hCa1qOiC7Y46DJvUtDIsDa1wv2I4tAX8=.8575f968-0685-450d-8d77-16523cd7531a@github.com>

On Fri, 3 Mar 2023 08:15:49 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
>> 
>> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
>> 
>> 
>>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>>     @@ -17084,7 +17084,7 @@
>>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>>      <div class="block"><code>readObject</code> is called to restore the state of the
>>     - (@code BasicPermission} from a stream.</div>
>>     + <code>BasicPermission</code> from a stream.</div>
>>      <dl class="notes">
>>      <dt>Parameters:</dt>
>>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
>> 
>> Notes
>> -----
>> 
>> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
>> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
>> * I will update copyright years after (and if) the fix had been approved, as required.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2866:
> 
>> 2864:      * Merge multiple abstract methods. The preferred method is a method that is a subsignature
>> 2865:      * of all the other signatures and whose return type is more specific {@link MostSpecificReturnCheck}.
>> 2866:      * The resulting preferred method has a thrown clause that is the intersection of the merged
> 
> Is it ??has a {@code throws} clause???

Thanks! I'll add this to a separate PR.

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

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

From aph at openjdk.org  Fri Mar  3 09:45:22 2023
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 3 Mar 2023 09:45:22 GMT
Subject: RFR: 8302780: Add support for vectorized arraycopy GC barriers
 [v9]
In-Reply-To: <GDdK137W1CzKue6dDF57b1M8cK93-iQQb8FyU004Oig=.22fd7da5-437d-4b04-b637-54562928ee61@github.com>
References: <SU-lpFUY3nGTCSM5k7HrOR2xGgNhPFRNDFUa6JBNEMQ=.2ceac514-334b-4201-8f7b-f17b9ebf3505@github.com>
 <GDdK137W1CzKue6dDF57b1M8cK93-iQQb8FyU004Oig=.22fd7da5-437d-4b04-b637-54562928ee61@github.com>
Message-ID: <tbo1WZ_X6afUDKOTjqwB8fn9TqUFzr7B335tSK8Vfw4=.9fa026f7-3e75-462c-896c-64e05c18f084@github.com>

On Fri, 3 Mar 2023 08:51:37 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> So far, the arraycopy stubs have performed some kind of bulk pre/post barriers for arraycopy, which have been good enough, and allowed the copying itself to be done with plain loads and stores. For generational ZGC, this approach is not good enough, and we need barriers for the actual copying, but instead don't need the pre/post barriers. To prepare the JVM for generational ZGC, we need to add an API for arraycopy barriers.
>
> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove rscratch aliasing

That's good enough for me. Thanks.

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

Marked as reviewed by aph (Reviewer).

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

From eosterlund at openjdk.org  Fri Mar  3 09:45:23 2023
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 3 Mar 2023 09:45:23 GMT
Subject: RFR: 8302780: Add support for vectorized arraycopy GC barriers
 [v6]
In-Reply-To: <XmcClrrGSrtrmQR8EoXNcwVlx8R-hvjN_m1KPnzpzz0=.67f24732-5965-4840-a8b4-0314c2183325@github.com>
References: <SU-lpFUY3nGTCSM5k7HrOR2xGgNhPFRNDFUa6JBNEMQ=.2ceac514-334b-4201-8f7b-f17b9ebf3505@github.com>
 <47e5gQJkZn7ldGv3n2cyQoZSAT9YpWWvIwXnbxhdGuQ=.643a4652-204b-4689-85a4-9378e8a587b3@github.com>
 <nLy9emUIdTkhV1t48otOXxgMwJ_eU6ittB6QA0X7JYo=.c8f0e35b-d41e-4a98-9538-7bfbb6a0a77f@github.com>
 <SsRePM6dkPRzWTX5vD-Of9vcCURYSZyKMr4DYfBif8U=.8423d374-1ee6-4fba-9561-f40517fe9490@github.com>
 <XmcClrrGSrtrmQR8EoXNcwVlx8R-hvjN_m1KPnzpzz0=.67f24732-5965-4840-a8b4-0314c2183325@github.com>
Message-ID: <bVQr5unWVH4T6ip_iFJLqUAsz91cFGepm3ZaH7-lPj4=.350b1735-750b-4087-95ab-ced514fc4f40@github.com>

On Thu, 2 Mar 2023 09:58:04 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> I updated the PR with a helper stack object encapsulating the choice of GC temp registers, types, decorators, etc, so that each line removes all the noise and becomes more readable. Do you like it? If yes, do you also want your proposed loop constructions in the new more compact form? I'm okay either way.
>
> The more compact form is a _huge_ improvement. I believe that using loops rather than hand-unrolling the code would make it even better!

I think you are right that the loop form is easier to understand and maintain. But I think it makes it harder to convince myself that I didn't accidentally change the logic with this patch. I'm up for doing it as a follow-up RFE. Does that sound okay?

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

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

From dholmes at openjdk.org  Fri Mar  3 09:56:35 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 3 Mar 2023 09:56:35 GMT
Subject: RFR: 8286781: Replace the deprecated/obsolete gethostbyname and
 inet_addr calls [v2]
In-Reply-To: <hTpw51fgF4gk1I60vdXDpEWpZlISh4v_eNfoOQw2hds=.9a07f8c1-0af4-454b-8a9e-37d83403f7c0@github.com>
References: <hTpw51fgF4gk1I60vdXDpEWpZlISh4v_eNfoOQw2hds=.9a07f8c1-0af4-454b-8a9e-37d83403f7c0@github.com>
Message-ID: <3jFBC6xN7K5rRI3NUQODmTV3Fo03iRajvhNpd5Tolek=.6a2058a2-dc3d-4341-95e7-4eae498d3e1b@github.com>

> We can replace `gethostbyname`, which is deprecated on Windows and Linux, with `getaddrinfo`. This API is available on all supported platforms and so can be placed in shared code. @djelinski pointed out that `getaddrinfo` can resolve both IP addresses and host names so the two step approach used in `networkStream::connect` is not necessary and we can do away with `os::get_host_by_name()` completely.
> 
> The build is updated to enable winsock deprecation warnings, and now we need to use `ws2_32.lib` we can drop `wsock32.lib` (as it is basically a subset - again thanks @djelinski ).
> 
> Testing
>     - all Oracle builds in tiers 1-5
>     - All GHA builds
> 
> The actual code change has to be manually tested because the code is only used by Ideal Graph Printing to connect to the Ideal Graph Visualizer. I've manually tested on Windows and Linux and @tobiasholenstein tested macOS.
> 
> Thanks.

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Restrict getaddrinfo to IPv4 only as per the rest of the code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12842/files
  - new: https://git.openjdk.org/jdk/pull/12842/files/81f15e05..8b6f6317

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

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

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

From redestad at openjdk.org  Fri Mar  3 10:12:13 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 3 Mar 2023 10:12:13 GMT
Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments
In-Reply-To: <Bzi35xfPH43Jupv65o86ErKvkPYaJdNV7cDIX7BBorc=.34e6522f-ec1e-41ee-b254-32713288bc79@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
 <zGeNBZ-3vU9GABEYOeUorRTJAMzyQzN-97Rx6qKisaY=.87335367-efc7-4c48-b866-de39a9d9c9e2@github.com>
 <Bzi35xfPH43Jupv65o86ErKvkPYaJdNV7cDIX7BBorc=.34e6522f-ec1e-41ee-b254-32713288bc79@github.com>
Message-ID: <-U8YFFuXm_hMf-bY1AVCRauRrE-fRYRxrx_yf38ZL1A=.d50884c5-cc4b-489a-b817-828faf876c76@github.com>

On Fri, 3 Mar 2023 09:38:13 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/BootstrapMethodInvoker.java line 257:
>> 
>>> 255: 
>>> 256:     /**
>>> 257:      * @return true iff the BSM method type exactly matches
>> 
>> I assume ?iff? should ?if??
>
> Here and elsewhere in this file "iff" might mean [if and only if](https://en.wikipedia.org/wiki/If_and_only_if), which would make sense. (FWIW, there are a few hundred occurrences of the word "iff" in src.)
> 
> @cl4es (Claes Redestad), as the author of those lines would you like to chime in?
> 
> Since Claes might read this, I note that when I changed unsupported `{@see}` to `{@link}` thoughtout this file, my IDE could not resolve one of the links: `java.lang.invoke.LambdaMetafactory#metafactory(MethodHandles.Lookup,String,Class,MethodType,MethodHandle,MethodType)`
> 
> While there's a similarly-name method with slightly different parameters, I refrained from using it:
> `java.lang.invoke.LambdaMetafactory#metafactory(MethodHandles.Lookup,String,MethodType,MethodType,MethodHandle,MethodType)`.

Yes, iff means if-and-only-if and is used for extra precision in formal logic, mathematics. As @pavelrappo points out it's a relatively common occurrence in the OpenJDK sources, though perhaps not in the public javadocs. Perhaps a bit pretentious, but mostly a terse way to say "return true if the BSM method type exactly matches X, otherwise false".

The broken link stems from the fact that the method I was targeting (a way to use condy for lambda proxy singletons rather than a `MethodHandle.constant`) was never integrated. We'll look at either getting that done (@briangoetz suggested the time might be ready for it) or remove this currently pointless static bootstrap specialization test.

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

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

From eosterlund at openjdk.org  Fri Mar  3 10:45:17 2023
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 3 Mar 2023 10:45:17 GMT
Subject: RFR: 8302780: Add support for vectorized arraycopy GC barriers
 [v8]
In-Reply-To: <gvDgRkVLCWKo7eMNg09fMG2u59Z7B6RwPmEkYl-9588=.54ec61a2-e086-41a4-9ebe-9b459c26e9f7@github.com>
References: <SU-lpFUY3nGTCSM5k7HrOR2xGgNhPFRNDFUa6JBNEMQ=.2ceac514-334b-4201-8f7b-f17b9ebf3505@github.com>
 <BWqOjj4KikZ2Mj14NNMdbAhMaY0rsj0289AEAQFqegw=.af04f90a-7548-4bfd-8399-ab5a763b8dd1@github.com>
 <UrZD6IsIiDp9Fdqc2LPq5uZhrke-AEuZYeakmtAgjlA=.d89ec381-7fb0-4486-8b83-7a10536fc5bd@github.com>
 <gvDgRkVLCWKo7eMNg09fMG2u59Z7B6RwPmEkYl-9588=.54ec61a2-e086-41a4-9ebe-9b459c26e9f7@github.com>
Message-ID: <BQC5cMBLieK2mURVlS5tuCkDQQsLHdiZWrbe33rfz_I=.46a156d2-9b1f-4fd3-8404-b718e1a6f4ff@github.com>

On Thu, 2 Mar 2023 10:02:59 GMT, Andrew Haley <aph at openjdk.org> wrote:

>>> All this extreme cut-and-paste manual unrolling is very hard to read, maintain, and review.
>> I wasn't going to say anything, because it's Erik, and what do I know! But I must push back here, this is too much.
>> Please consider these style changes.
>> 
>> In my opinion, the (very much needed) changes you suggest are outside the scope of this PR, which is about lifting the memory accesses, in their existing form, to a barrier API-level. Conflating this with your suggested changes would make it harder to review this PR, which is sufficiently complex in its current form. I totally agree that your suggestions would improve readability and maintainability, but couldn't we apply them in a follow-up RFE?
>
>> > All this extreme cut-and-paste manual unrolling is very hard to read, maintain, and review.
>> > I wasn't going to say anything, because it's Erik, and what do I know! But I must push back here, this is too much.
>> > Please consider these style changes.
>> 
>> In my opinion, the (very much needed) changes you suggest are outside the scope of this PR, which is about lifting the memory accesses, in their existing form, to a barrier API-level. Conflating this with your suggested changes would make it harder to review this PR, which is sufficiently complex in its current form. I totally agree that your suggestions would improve readability and maintainability, but couldn't we apply them in a follow-up RFE?
> 
> I disagree in every way. The added complexity, which is fixed so it no longer matters, made it near-impossible for me to reason about this PR.  And, as John Rose put it, like any good carpenter we should clean up as we work.

Thanks for the review @theRealAph! And thanks also to @robcasloz, @albertnetymk and @RealFYang.

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

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

From mdoerr at openjdk.org  Fri Mar  3 10:55:57 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 3 Mar 2023 10:55:57 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v9]
In-Reply-To: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
Message-ID: <NZy_byi8YPIN-djp_5eB6SmpRMY4utVaE4Dp0s9umAk=.049fcae5-c18a-41d6-9a4a-dece88a623c6@github.com>

> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
> 
> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
> 
> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
> 
> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Will get addressed separately: [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
> 
> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
> 
> I had to make changes to shared code and code for other platforms:
> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit.

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  Handle HFA corner cases with overlapping registers in Java.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12708/files
  - new: https://git.openjdk.org/jdk/pull/12708/files/f23edd8e..98e242c2

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

  Stats: 53 lines in 4 files changed: 16 ins; 20 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/12708.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12708/head:pull/12708

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

From mdoerr at openjdk.org  Fri Mar  3 11:02:18 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 3 Mar 2023 11:02:18 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v3]
In-Reply-To: <mo8rpizKpaAts6jpIZaQjgBZkCZE7uZaxaBW2j6mNxw=.4834669e-db31-4989-85d1-8bf94aabf651@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com>
 <ubsdQFbNzTtdhNeZwCJyA5BRc2mR4AmQwk6hgJOlBy0=.6974c426-eeb2-4212-8038-9a8e00a0e7de@github.com>
 <mo8rpizKpaAts6jpIZaQjgBZkCZE7uZaxaBW2j6mNxw=.4834669e-db31-4989-85d1-8bf94aabf651@github.com>
Message-ID: <YkhWKXHt2GFUUiP-ausNrlugie2UlaDAfs2k4vlrjWY=.16c04132-6156-4069-9160-1703d8d2c3cf@github.com>

On Wed, 1 Mar 2023 06:26:20 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/CallArranger.java line 293:
>> 
>>> 291:                 } else {
>>> 292:                     overlappingReg = new VMStorage(StorageType.STACK_AND_FLOAT,
>>> 293:                                                    (short) STACK_SLOT_SIZE, (int) stackOffset - 4);
>> 
>> I think you could remove the mixed VMStorage types here relatively easily by returning a `VMStorage[][]`, where each element is a single element array, but then for the `needOverlapping` case add another element to the array for the extra store (instead of replacing the existing one).
>> 
>> Then when unboxing a `STRUCT_HFA`,  `dup` the result of the `bufferLoad` and then do 2 `vmStore`s (one for each element).
>> 
>> For boxing, you could just ignore the extra storage, and just `vmLoad` the first one (or, whichever one you like :))
>
> Thanks! I need to find extra time for this. Sounds like a good idea and I may be able to get rid of some nasty code.

Done by https://github.com/openjdk/jdk/pull/12708/commits/98e242c24c07ea977b7709b9f8d0c10ce87e84c0 (using a record instead of a `VMStorage[][]` because I think this is better readable). Note that it's a bit more complicated. I couldn't use your `dup` trick, because I need to put the value into a GP reg and one half of it to a FP reg. The Panama code doesn't support that (IllegalArgumentException: Invalid operand type: interface java.lang.foreign.MemorySegment. float expected).

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

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

From djelinski at openjdk.org  Fri Mar  3 11:23:14 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 3 Mar 2023 11:23:14 GMT
Subject: RFR: 8286781: Replace the deprecated/obsolete gethostbyname and
 inet_addr calls [v2]
In-Reply-To: <3jFBC6xN7K5rRI3NUQODmTV3Fo03iRajvhNpd5Tolek=.6a2058a2-dc3d-4341-95e7-4eae498d3e1b@github.com>
References: <hTpw51fgF4gk1I60vdXDpEWpZlISh4v_eNfoOQw2hds=.9a07f8c1-0af4-454b-8a9e-37d83403f7c0@github.com>
 <3jFBC6xN7K5rRI3NUQODmTV3Fo03iRajvhNpd5Tolek=.6a2058a2-dc3d-4341-95e7-4eae498d3e1b@github.com>
Message-ID: <_OvnSTx31PuBeUlYl9mJzN7AspzmRzF6cumv2HH5xfw=.dc4b5910-74e4-4e0d-b886-c4213bc32f23@github.com>

On Fri, 3 Mar 2023 09:56:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> We can replace `gethostbyname`, which is deprecated on Windows and Linux, with `getaddrinfo`. This API is available on all supported platforms and so can be placed in shared code. @djelinski pointed out that `getaddrinfo` can resolve both IP addresses and host names so the two step approach used in `networkStream::connect` is not necessary and we can do away with `os::get_host_by_name()` completely.
>> 
>> The build is updated to enable winsock deprecation warnings, and now we need to use `ws2_32.lib` we can drop `wsock32.lib` (as it is basically a subset - again thanks @djelinski ).
>> 
>> Testing
>>     - all Oracle builds in tiers 1-5
>>     - All GHA builds
>> 
>> The actual code change has to be manually tested because the code is only used by Ideal Graph Printing to connect to the Ideal Graph Visualizer. I've manually tested on Windows and Linux and @tobiasholenstein tested macOS.
>> 
>> Thanks.
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restrict getaddrinfo to IPv4 only as per the rest of the code

Marked as reviewed by djelinski (Committer).

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

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

From duke at openjdk.org  Fri Mar  3 11:31:56 2023
From: duke at openjdk.org (Jan Kratochvil)
Date: Fri, 3 Mar 2023 11:31:56 GMT
Subject: RFR: 8302191: Performance degradation for float/double modulo on
 Linux [v6]
In-Reply-To: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
References: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
Message-ID: <YV7AJ8DtacGKJ2xhbM7iMaG1MHybnXC4mfdn5dcTloI=.0b1bb05b-1c84-46c0-b553-e6fcea988838@github.com>

> I have OCA already processed/approved. I am not Author but my Author request is being processed these days (sent to Rob McKenna).
> I did regression test x86_64 OpenJDK-8. I will leave other regression testing on GHA.
> The patch (and former GCC performance regression) affects only x86_64+i686.

Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:

  Uppercase L - a review by turbanoff.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12508/files
  - new: https://git.openjdk.org/jdk/pull/12508/files/a04ee993..390d06c2

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

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

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

From aivanov at openjdk.org  Fri Mar  3 11:34:16 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 3 Mar 2023 11:34:16 GMT
Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments
In-Reply-To: <-U8YFFuXm_hMf-bY1AVCRauRrE-fRYRxrx_yf38ZL1A=.d50884c5-cc4b-489a-b817-828faf876c76@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
 <zGeNBZ-3vU9GABEYOeUorRTJAMzyQzN-97Rx6qKisaY=.87335367-efc7-4c48-b866-de39a9d9c9e2@github.com>
 <Bzi35xfPH43Jupv65o86ErKvkPYaJdNV7cDIX7BBorc=.34e6522f-ec1e-41ee-b254-32713288bc79@github.com>
 <-U8YFFuXm_hMf-bY1AVCRauRrE-fRYRxrx_yf38ZL1A=.d50884c5-cc4b-489a-b817-828faf876c76@github.com>
Message-ID: <GIf5QraCfE1MexPnWsXUMEWFPYoWpu-80I1N7bB6ffk=.728f82a3-fe8f-40d3-8dbd-c6a9fa5e031a@github.com>

On Fri, 3 Mar 2023 10:09:27 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Yes, iff means if-and-only-if and is used for extra precision in formal logic, mathematics.

I've never come across it before. With your explanations, it makes perfect sense.

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

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

From duke at openjdk.org  Fri Mar  3 11:46:16 2023
From: duke at openjdk.org (Jan Kratochvil)
Date: Fri, 3 Mar 2023 11:46:16 GMT
Subject: RFR: 8302191: Performance degradation for float/double modulo on
 Linux [v5]
In-Reply-To: <rvmRsoPkjyTPF-AG80rGqBo3oPpTgnuzqqAT_obLRaY=.185307f7-f00d-48f6-9dc9-c5b291a81cf3@github.com>
References: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
 <o8gBuzq9Pfc4aYnmo3cPGXwVo4cbouH0delXsoz4kEI=.7a6c9412-f7c4-4c07-91ea-8cb5c0b9da6a@github.com>
 <rvmRsoPkjyTPF-AG80rGqBo3oPpTgnuzqqAT_obLRaY=.185307f7-f00d-48f6-9dc9-c5b291a81cf3@github.com>
Message-ID: <KCAOzqiF5k7Hun-bk4la09byA8SwpEe9RV6uZrGhCmY=.48dde20d-bd2e-463d-bcbf-6574e399a02a@github.com>

On Thu, 2 Mar 2023 22:27:45 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix copyright author.
>
> test/micro/org/openjdk/bench/vm/floatingpoint/DremFrem.java line 174:
> 
>> 172:             double inf_minus_inf  = Double.POSITIVE_INFINITY - Double.POSITIVE_INFINITY;
>> 173:             double inf_times_zero = Double.POSITIVE_INFINITY * 0.0f;
>> 174:             double quiet_nan1     = Double.longBitsToDouble(0x7ffc000000000001l);
> 
> Nit: whether or not a particular NaN bit pattern is quiet or signalling is an architecture-specific determination, it is not specified by the IEEE 754 standard.

First I disagree:
- [it makes formal recommendations for the encoding of the signaling/quiet NaN state.](https://en.wikipedia.org/wiki/IEEE_754-2008_revision#Clause_6:_Infinity,_NaNs,_and_sign_bit)
- [A signaling NaN bit string should be encoded with the first bit of the trailing significand field being 0](https://irem.univ-reunion.fr/IMG/pdf/ieee-754-2008.pdf#page=47)

Second the testcase tests just compatibility as AFAIK Java does not support the signaling.

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

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

From duke at openjdk.org  Fri Mar  3 11:51:47 2023
From: duke at openjdk.org (Jan Kratochvil)
Date: Fri, 3 Mar 2023 11:51:47 GMT
Subject: RFR: 8302191: Performance degradation for float/double modulo on
 Linux [v7]
In-Reply-To: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
References: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
Message-ID: <Ca_tMzcN_AtT0ci6PA9RW9yBa5dn92MFgrpMlQsUwmw=.5c8797c6-d30f-4d3a-88b6-20067833f0e1@github.com>

> I have OCA already processed/approved. I am not Author but my Author request is being processed these days (sent to Rob McKenna).
> I did regression test x86_64 OpenJDK-8. I will leave other regression testing on GHA.
> The patch (and former GCC performance regression) affects only x86_64+i686.

Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:

  Remove comments to be moved to JBS (Bug System) - a review by jddarcy.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12508/files
  - new: https://git.openjdk.org/jdk/pull/12508/files/390d06c2..ef4cd57a

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

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

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

From duke at openjdk.org  Fri Mar  3 11:51:52 2023
From: duke at openjdk.org (Jan Kratochvil)
Date: Fri, 3 Mar 2023 11:51:52 GMT
Subject: RFR: 8302191: Performance degradation for float/double modulo on
 Linux [v5]
In-Reply-To: <eGuNxq2-JbQJlW1WwdUlEUuMfZPkznLpcxbUs9tQc1c=.ed231601-04b4-49d6-8664-7d5f44d455da@github.com>
References: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
 <o8gBuzq9Pfc4aYnmo3cPGXwVo4cbouH0delXsoz4kEI=.7a6c9412-f7c4-4c07-91ea-8cb5c0b9da6a@github.com>
 <eGuNxq2-JbQJlW1WwdUlEUuMfZPkznLpcxbUs9tQc1c=.ed231601-04b4-49d6-8664-7d5f44d455da@github.com>
Message-ID: <5IxJHzZ9p0cnxA7WQ6U23XCVEw7e2Yp9ye47uu76Y4E=.761cf840-9dca-40df-92e1-26b3d2a0786e@github.com>

On Fri, 3 Mar 2023 05:58:37 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix copyright author.
>
> src/hotspot/cpu/x86/sharedRuntime_x86.cpp line 129:
> 
>> 127: // GCC had slow fmod():
>> 128: // since https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=4f2611b6e872c40e0bf4da38ff05df8c8fe0ee64
>> 129: // until https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=8020c9c42349f51f75239b9d35a2be41848a97bd
> 
> We typically list such URLs in the bug database rather than the source code.

I have removed it (but I do not like it much). Also removed it from the testcase. I will add it to JBS after I can login to my new account.

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

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

From duke at openjdk.org  Fri Mar  3 11:53:48 2023
From: duke at openjdk.org (Afshin Zafari)
Date: Fri, 3 Mar 2023 11:53:48 GMT
Subject: RFR: 8292059: Do not inline InstanceKlass::allocate_instance()
 [v2]
In-Reply-To: <ZSJBTzuC4wVuKdqSLLTgw4Pds2oX5wah0Ub6rFux_tc=.c4e2ae89-cadb-4ccd-9eee-034583cf7200@github.com>
References: <ZSJBTzuC4wVuKdqSLLTgw4Pds2oX5wah0Ub6rFux_tc=.c4e2ae89-cadb-4ccd-9eee-034583cf7200@github.com>
Message-ID: <8koli6nAbt8Rx4Je8MRic0dPloLTb9IiUyw25BvUI0s=.07267dc7-d2a1-4426-8876-1e41b1a248ac@github.com>

> The inline and not-inline versions of the method is stress tested to compare the performance difference. The statistics are drawn in the following charts. The vertical axis is in milliseconds.
> 
> ![chart (2)](https://user-images.githubusercontent.com/4697012/221848555-2884313e-9d26-41c9-a265-3f1ce295b17b.png)
> 
> ![chart (3)](https://user-images.githubusercontent.com/4697012/221863810-94118677-b4af-468f-90c6-5ea365ae3588.png)

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  8292059: Do not inline InstanceKlass::allocate_instance()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12782/files
  - new: https://git.openjdk.org/jdk/pull/12782/files/48d5a430..30a5734c

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

  Stats: 38 lines in 8 files changed: 13 ins; 17 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/12782.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12782/head:pull/12782

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

From duke at openjdk.org  Fri Mar  3 11:58:17 2023
From: duke at openjdk.org (Afshin Zafari)
Date: Fri, 3 Mar 2023 11:58:17 GMT
Subject: RFR: 8292059: Do not inline InstanceKlass::allocate_instance()
 [v2]
In-Reply-To: <9ZXi9uNa5ETIhldKLCDAYojtXTGEg-5EexLwHNE2zhI=.026815b3-3117-4184-be4c-5fdf42c2655f@github.com>
References: <ZSJBTzuC4wVuKdqSLLTgw4Pds2oX5wah0Ub6rFux_tc=.c4e2ae89-cadb-4ccd-9eee-034583cf7200@github.com>
 <9ZXi9uNa5ETIhldKLCDAYojtXTGEg-5EexLwHNE2zhI=.026815b3-3117-4184-be4c-5fdf42c2655f@github.com>
Message-ID: <1W22QvJKaoJVRI5Wrx6DZEizGOxHsiSAEoLkHsCauQY=.6e934949-d854-49f8-9e1e-5786c0d04c8f@github.com>

On Wed, 1 Mar 2023 12:38:59 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8292059: Do not inline InstanceKlass::allocate_instance()
>
> src/hotspot/share/oops/instanceKlass.inline.hpp line 188:
> 
>> 186: }
>> 187: 
>> 188: inline instanceOop InstanceKlass::allocate_instance(oop java_class, TRAPS) {
> 
> In moving this, can you eliminate any #includes at the top?  And migrate them to .cpp files that might need them.

All the #include headers are removed except the `utilities/devirtualizer.inline.hpp`. The .cpp files that need it should include it before `oops/instanceKlass.inline.hpp` which violates the _sorted header filename_ in the coding style rules.

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

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

From duke at openjdk.org  Fri Mar  3 12:07:54 2023
From: duke at openjdk.org (Jan Kratochvil)
Date: Fri, 3 Mar 2023 12:07:54 GMT
Subject: RFR: 8302191: Performance degradation for float/double modulo on
 Linux [v8]
In-Reply-To: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
References: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
Message-ID: <GkHVwDR66YUHCCSb_vTfyJtfrRV26aeNBxCuyqkvdBU=.6b7b1c82-50a7-4a25-94ab-13dc21431ca9@github.com>

> I have OCA already processed/approved. I am not Author but my Author request is being processed these days (sent to Rob McKenna).
> I did regression test x86_64 OpenJDK-8. I will leave other regression testing on GHA.
> The patch (and former GCC performance regression) affects only x86_64+i686.

Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:

  Always include the _WIN64 workaround - a review by dholmes-ora.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12508/files
  - new: https://git.openjdk.org/jdk/pull/12508/files/ef4cd57a..873562c8

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

  Stats: 71 lines in 2 files changed: 34 ins; 34 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12508.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12508/head:pull/12508

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

From duke at openjdk.org  Fri Mar  3 12:07:58 2023
From: duke at openjdk.org (Jan Kratochvil)
Date: Fri, 3 Mar 2023 12:07:58 GMT
Subject: RFR: 8302191: Performance degradation for float/double modulo on
 Linux [v2]
In-Reply-To: <50HcTSZYkWhmyRTTSpQsJJ9Dv28R_RnY1XflczBBxeg=.7c6c1e71-7129-4bc2-9ab5-f5dde541f0a9@github.com>
References: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
 <CR6FSWocHu8YjQQrPRqkOTetmbZ-WYHLZlEeWLbsVfM=.71d2e6bf-7a6c-488b-8c4f-b71d9df21044@github.com>
 <jOXvH6Ozm5_xK1bEYzdvgkUAbgP4pu0aonYxbA0itNo=.a7ffbdf6-fba5-49c0-bd63-3996ea317ec4@github.com>
 <50HcTSZYkWhmyRTTSpQsJJ9Dv28R_RnY1XflczBBxeg=.7c6c1e71-7129-4bc2-9ab5-f5dde541f0a9@github.com>
Message-ID: <LitdVIukdRC7RzI_hkd50Lhy8qXd1OF7H_siiK168qM=.b9299c26-d544-4441-8563-adcd89086d5c@github.com>

On Wed, 1 Mar 2023 08:48:58 GMT, Jan Kratochvil <duke at openjdk.org> wrote:

>> src/hotspot/share/runtime/sharedRuntime.cpp line 236:
>> 
>>> 234: const julong double_infinity  = CONST64(0x7FF0000000000000);
>>> 235: 
>>> 236: #ifndef X86
>> 
>> I wonder if the WIN64 workaround is actually needed/valid for non-X86 windows?
>
> It is true the comment says:
>> 64-bit Windows on amd64 returns the wrong values for infinity operands.
> 
> I have left the workaround really just for AMD64 Windows now. I am going to get it regression tested on aarch64 if that is enough.

So the _WIN64 workaround will be always there.

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

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

From ayang at openjdk.org  Fri Mar  3 12:30:38 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 3 Mar 2023 12:30:38 GMT
Subject: RFR: 8303534: Merge CompactibleSpace into ContiguousSpace [v2]
In-Reply-To: <dPNxDwwSW0wlk4Fv6eYg8dsClKdfjNV9si2WZS2Npi0=.c4f52214-c8a1-4fe6-a513-9fb1e0995ae0@github.com>
References: <dPNxDwwSW0wlk4Fv6eYg8dsClKdfjNV9si2WZS2Npi0=.c4f52214-c8a1-4fe6-a513-9fb1e0995ae0@github.com>
Message-ID: <Y5ecs6y1UVWsigb317U2bmJP608sJ_jVk6g77HDUFpo=.cf9c490d-bdbd-4297-9a0c-172518a8285e@github.com>

> Simple refactoring of merging two types.
> 
> Test: tier1-5

Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:

  copyright-year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12841/files
  - new: https://git.openjdk.org/jdk/pull/12841/files/dc9f901f..da1931a1

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

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

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

From mbaesken at openjdk.org  Fri Mar  3 13:03:03 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 3 Mar 2023 13:03:03 GMT
Subject: RFR: JDK-8303575: adjust Xen handling on Linux aarch64
Message-ID: <Pudap47AEtkkc8vtRirSNBUb4jdEHFIhhGd8IPEw0dg=.dc2f524d-7ade-49ff-b603-620adc3bcaf8@github.com>

After [JDK-8301050](https://bugs.openjdk.org/browse/JDK-8301050) the Xen handling on aarch64 should be slightly adjusted.
The output in VM_Version::print_platform_virtualization_info was missed and needs to be added for Xen.
Additionally a new XenPVHVM virtualization type could be introduced because this describes the Xen on aarch64 better.
See also https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/virtualization-on-arm-with-xen where the naming is used.

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

Commit messages:
 - JDK-8303575

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

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

From duke at openjdk.org  Fri Mar  3 13:45:11 2023
From: duke at openjdk.org (Jan Kratochvil)
Date: Fri, 3 Mar 2023 13:45:11 GMT
Subject: RFR: 8302191: Performance degradation for float/double modulo on
 Linux [v9]
In-Reply-To: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
References: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
Message-ID: <cE1Rx7P-qflRs1y7BrpsD5amJDRjCRku5DT_scRArfY=.fc54c292-0090-4fb0-ac5b-c2fd6dc06039@github.com>

> I have OCA already processed/approved. I am not Author but my Author request is being processed these days (sent to Rob McKenna).
> I did regression test x86_64 OpenJDK-8. I will leave other regression testing on GHA.
> The patch (and former GCC performance regression) affects only x86_64+i686.

Jan Kratochvil 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 remote-tracking branch 'origin/master' into modulo
 - Always include the _WIN64 workaround - a review by dholmes-ora.
 - Remove comments to be moved to JBS (Bug System) - a review by jddarcy.
 - Uppercase L - a review by turbanoff.
 - Fix copyright author.
 - Fix WIN32 vs. WIN64.
 - Update according to the upstream review by David Holmes.
 - 8302191: Performance degradation for float/double modulo on Linux

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12508/files
  - new: https://git.openjdk.org/jdk/pull/12508/files/873562c8..cdcf89d7

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

  Stats: 18454 lines in 676 files changed: 11810 ins; 3539 del; 3105 mod
  Patch: https://git.openjdk.org/jdk/pull/12508.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12508/head:pull/12508

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

From tschatzl at openjdk.org  Fri Mar  3 14:58:12 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 3 Mar 2023 14:58:12 GMT
Subject: RFR: 8191565: Last-ditch Full GC should also move humongous
 objects
In-Reply-To: <58l059EvQI6HNQyjUYSGYEWt6x-c1yvtmfX1QWfinH8=.87517ba1-ec81-4b9f-a41b-b05c8d33cf3d@github.com>
References: <58l059EvQI6HNQyjUYSGYEWt6x-c1yvtmfX1QWfinH8=.87517ba1-ec81-4b9f-a41b-b05c8d33cf3d@github.com>
Message-ID: <eslWdlOHn-3GPGU3n5lbvaORyw2xvLmp6yY03eRapqk=.a53fa4f9-1629-459d-8c75-ad11596e873d@github.com>

On Thu, 2 Mar 2023 13:48:10 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi All,
> 
> Please review this change to move humongous regions during the Last-Ditch full gc ( on `do_maximal_compaction`). This change will enable G1 to avoid encountering Out-Of-Memory errors that may occur due to the fragmentation of memory regions caused by the allocation of large memory blocks.
> 
> Here's how it works: At the end of `phase2_prepare_compaction`, G1 performs a serial compaction process for regular objects, which results in the heap being divided into two parts. The first part is a densely populated prefix that contains all the regular objects that have been moved. The second part consists of the remaining heap space, which may contain free regions, uncommitted regions, and regions that are not compacting. By moving/compacting the humongous objects in the second part of the heap closer to the dense prefix, G1 reduces the region fragmentation and avoids running into OOM errors.
> 
> We have enabled for G1 the Jtreg test that was previously used only for Shenandoah to test such workload. 
> 
> Testing: Tier 1-3

Changes requested by tschatzl (Reviewer).

src/hotspot/share/gc/g1/g1FullCollector.hpp line 87:

> 85:   G1FullGCCompactionPoint   _serial_compaction_point;
> 86:   G1FullGCCompactionPoint   _humongous_compaction_point;
> 87:   GrowableArray<HeapRegion*>* _humongous_compaction_regions;

This could be a `GrowableArrayCHeap<HeapRegion*, mtGC> _humongous_compaction_region` to avoid the necessity for explicit new/delete. Afaics there is no reassignment of that variable ever.

src/hotspot/share/gc/g1/g1FullCollector.hpp line 150:

> 148: 
> 149:   inline void add_humongous_region(HeapRegion* hr) { _humongous_compaction_regions->append(hr); }
> 150:   GrowableArray<HeapRegion*>* humongous_compaction_regions() { return _humongous_compaction_regions; }

Please move to the `.inline.hpp` file.

src/hotspot/share/gc/g1/g1FullGCCompactTask.cpp line 59:

> 57: 
> 58:   size_t size = obj->size();
> 59:   // copy object and reinit its mark

Suggestion:

  // Copy object and reinit its mark.

src/hotspot/share/gc/g1/g1FullGCCompactTask.cpp line 117:

> 115: }
> 116: 
> 117: void G1FullGCCompactTask::reset_humongous_metadata(HeapRegion* start_hr, uint num_regions, size_t word_size) {

Maybe this could somehow be refactored with `G1CollectedHeap::humongous_obj_allocate_initialize_regions`; probably not easily.

src/hotspot/share/gc/g1/g1FullGCCompactTask.cpp line 174:

> 172:   size_t word_size = obj->size();
> 173: 
> 174:   uint num_regions = (uint) G1CollectedHeap::humongous_obj_size_in_regions(word_size);

Suggestion:

  uint num_regions = (uint)G1CollectedHeap::humongous_obj_size_in_regions(word_size);

src/hotspot/share/gc/g1/g1FullGCCompactionPoint.cpp line 153:

> 151:   oop obj = cast_to_oop(hr->bottom());
> 152:   size_t obj_size = obj->size();
> 153:   int num_regions = (int) G1CollectedHeap::humongous_obj_size_in_regions(obj_size);

Please use signed int (or why not `size_t`?)

src/hotspot/share/gc/g1/g1FullGCCompactionPoint.cpp line 159:

> 157:   }
> 158: 
> 159:   // Find contiguous compaction target regions for the humongous object

Suggestion:

  // Find contiguous compaction target regions for the humongous object.

src/hotspot/share/gc/g1/g1FullGCCompactionPoint.cpp line 160:

> 158: 
> 159:   // Find contiguous compaction target regions for the humongous object
> 160:   Pair<uint, uint> range = find_contiguous_before(hr, num_regions);

(I'm suprised that MSVC does not complain here passing an int to the uint parameter)

src/hotspot/share/gc/g1/g1FullGCCompactionPoint.cpp line 165:

> 163: 
> 164:   if (range_begin == range_end) {
> 165:     // No contiguous compaction target regions found, so the object cannot be moved

Suggestion:

    // No contiguous compaction target regions found, so the object cannot be moved.

src/hotspot/share/gc/g1/g1FullGCCompactionPoint.cpp line 172:

> 170:   _collector->marker(0)->preserved_stack()->push_if_necessary(obj, obj->mark());
> 171: 
> 172:   HeapRegion* destn_hr = _compaction_regions->at(range_begin);

I would prefer `dest_hr` instead of `destn_hr` as abbreviation for "destination". It seems unusual.

src/hotspot/share/gc/g1/g1FullGCCompactionPoint.cpp line 176:

> 174:   assert(obj->is_forwarded(), "Object must be forwarded!");
> 175: 
> 176:   // Add the humongous object regions to the compaction point

Suggestion:

  // Add the humongous object regions to the compaction point.

src/hotspot/share/gc/g1/g1FullGCCompactionPoint.cpp line 205:

> 203:     // Check if the current region and the previous region are contiguous.
> 204:     bool regions_are_contiguous = (_compaction_regions->at(range_end)->hrm_index() - _compaction_regions->at(range_end - 1)->hrm_index()) == 1;
> 205:     contiguous_region_count =  regions_are_contiguous ? contiguous_region_count + 1 : 1;

Suggestion:

    contiguous_region_count = regions_are_contiguous ? contiguous_region_count + 1 : 1;

src/hotspot/share/gc/g1/heapRegion.inline.hpp line 192:

> 190: }
> 191: 
> 192: inline void HeapRegion::reset_compacted_humongous_after_full_gc(HeapWord* new_top) {

This method could probably just call `reset_compacted_after_full_gc` as they are identical. (I am not suggestion to remove this method, although I'm not completely sure it's useful).

src/hotspot/share/utilities/growableArray.hpp line 261:

> 259: 
> 260:   // Remove all elements in the range [start - end). The order is preserved.
> 261:   void erase(int start, int end) {

I'd probably name this new method `remove_range` instead of using something completely unrelated.

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

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

From kvn at openjdk.org  Fri Mar  3 16:24:11 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 3 Mar 2023 16:24:11 GMT
Subject: RFR: 8303415: Add VM_Version::is_intrinsic_supported(id)
Message-ID: <Oq9PJR6MEDvSwpCmCR7_f7j-jELMDv2XLBXP242Wvio=.8ac95e70-3bf4-4150-9455-eea3c63018ba@github.com>

Currently we check VM flags, directives and JIT compiler support when we generate intrinsics. 
We have *product* VM flags for most intrinsics and set them in VM based on HW support. 
But not all intrinsics have such flags and it is not scalable to add new *product* flag for each new intrinsic. 
Also we have `-XX:DisableIntrinsic=<id>` and `-XX:ControlIntrinsic=<id>` flags to control intrinsics from command line. We don't need specific flags for that. 

I propose to add new `VM_Version::is_intrinsic_supported(id)` method to check platform support for intrinsic without adding new flag. I used it for `_floatToFloat16` intrinsic for my work on [JDK-8302976](https://bugs.openjdk.org/browse/JDK-8302976).

Additional fixes:
Fixed Interpreter to skip intrinsics if they are disabled with flag.
Moved Interpreter's `InlineIntrinsics` flag check into one place in shared code.
Added separate interpreter id for `_dsqrt_strict` so it could be disabled separately from regular `_dsqrt`.
Added missing `native` mark to `_currentThread`.
Removed unused `AbstractInterpreter::in_native_entry()`.
Cleanup C2 intrinsic checks code.

Tested tier1-4,xcomp,stress. Also ran tier1-3,xcomp with `-XX:-InlineIntrinsics`.

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

Commit messages:
 - 8303415: Add VM_Version::is_intrinsic_supported(id)

Changes: https://git.openjdk.org/jdk/pull/12858/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12858&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303415
  Stats: 335 lines in 25 files changed: 214 ins; 82 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/12858.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12858/head:pull/12858

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

From duke at openjdk.org  Fri Mar  3 16:49:00 2023
From: duke at openjdk.org (Afshin Zafari)
Date: Fri, 3 Mar 2023 16:49:00 GMT
Subject: Integrated: 8301117: Remove old_size param from
 ResizeableResourceHashtable::resize()
In-Reply-To: <huotMgXFs-BDCIY8RU1xIBG8rELgpYYVNBBjmLEBYUc=.061bab76-e5af-4dc6-ac3f-82d245ac5a0f@github.com>
References: <huotMgXFs-BDCIY8RU1xIBG8rELgpYYVNBBjmLEBYUc=.061bab76-e5af-4dc6-ac3f-82d245ac5a0f@github.com>
Message-ID: <NU7V63iDRaiZ-pYsnl7na8nIfJXjOcjdgBwqT-qpp_A=.f6226199-3b7b-4cbb-bc74-e74bd973ff18@github.com>

On Sat, 18 Feb 2023 15:31:46 GMT, Afshin Zafari <duke at openjdk.org> wrote:

> `old_size` is removed from the function parameters in definitions and calls.
> `table_size` is used as old size.
> ### Test
> mach5 tiers 1-5.

This pull request has now been integrated.

Changeset: ae797c64
Author:    Afshin Zafari <Afshin.zafari at oracle.com>
Committer: Calvin Cheung <ccheung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ae797c64afc61a0b1c8fbc48f56b2c41f54a7301
Stats:     4 lines in 2 files changed: 0 ins; 0 del; 4 mod

8301117: Remove old_size param from ResizeableResourceHashtable::resize()

Reviewed-by: dholmes, coleenp

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

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

From coleenp at openjdk.org  Fri Mar  3 16:57:20 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 3 Mar 2023 16:57:20 GMT
Subject: RFR: 8292059: Do not inline InstanceKlass::allocate_instance()
 [v2]
In-Reply-To: <8koli6nAbt8Rx4Je8MRic0dPloLTb9IiUyw25BvUI0s=.07267dc7-d2a1-4426-8876-1e41b1a248ac@github.com>
References: <ZSJBTzuC4wVuKdqSLLTgw4Pds2oX5wah0Ub6rFux_tc=.c4e2ae89-cadb-4ccd-9eee-034583cf7200@github.com>
 <8koli6nAbt8Rx4Je8MRic0dPloLTb9IiUyw25BvUI0s=.07267dc7-d2a1-4426-8876-1e41b1a248ac@github.com>
Message-ID: <UayUypze2lbH6zknkTAz-2ihMwb4SgulUZyrr1kSYqo=.1ea01faf-227b-49b4-82b7-c1b875d43b00@github.com>

On Fri, 3 Mar 2023 11:53:48 GMT, Afshin Zafari <duke at openjdk.org> wrote:

>> The inline and not-inline versions of the method is stress tested to compare the performance difference. The statistics are drawn in the following charts. The vertical axis is in milliseconds.
>> 
>> ![chart (2)](https://user-images.githubusercontent.com/4697012/221848555-2884313e-9d26-41c9-a265-3f1ce295b17b.png)
>> 
>> ![chart (3)](https://user-images.githubusercontent.com/4697012/221863810-94118677-b4af-468f-90c6-5ea365ae3588.png)
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8292059: Do not inline InstanceKlass::allocate_instance()

I have one suggested change but you should point out that the parameter change is an optimization that replaces some of the inlined benefits.

src/hotspot/share/oops/instanceKlass.cpp line 1390:

> 1388: }
> 1389: 
> 1390: instanceOop InstanceKlass::allocate_instance(InstanceKlass* ik, TRAPS) {

Should this have a null check on ik, like in the inlined function that it replaced?

src/hotspot/share/prims/jvmtiEnvBase.cpp line 28:

> 26: #include "classfile/classLoaderDataGraph.hpp"
> 27: #include "classfile/javaClasses.inline.hpp"
> 28: #include "classfile/vmSymbols.hpp"

I assume this is a transitive include, so good to put it in the file where it's used.

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

Changes requested by coleenp (Reviewer).

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

From coleenp at openjdk.org  Fri Mar  3 16:57:23 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 3 Mar 2023 16:57:23 GMT
Subject: RFR: 8292059: Do not inline InstanceKlass::allocate_instance()
 [v2]
In-Reply-To: <1W22QvJKaoJVRI5Wrx6DZEizGOxHsiSAEoLkHsCauQY=.6e934949-d854-49f8-9e1e-5786c0d04c8f@github.com>
References: <ZSJBTzuC4wVuKdqSLLTgw4Pds2oX5wah0Ub6rFux_tc=.c4e2ae89-cadb-4ccd-9eee-034583cf7200@github.com>
 <9ZXi9uNa5ETIhldKLCDAYojtXTGEg-5EexLwHNE2zhI=.026815b3-3117-4184-be4c-5fdf42c2655f@github.com>
 <1W22QvJKaoJVRI5Wrx6DZEizGOxHsiSAEoLkHsCauQY=.6e934949-d854-49f8-9e1e-5786c0d04c8f@github.com>
Message-ID: <AIPEEiYAZJ3EE7PAqbRFSx4EMFCYm5bQAMmhWtYICrk=.abcfd832-11b6-4cdb-8d51-46c7987ca13c@github.com>

On Fri, 3 Mar 2023 11:55:14 GMT, Afshin Zafari <duke at openjdk.org> wrote:

>> src/hotspot/share/oops/instanceKlass.inline.hpp line 188:
>> 
>>> 186: }
>>> 187: 
>>> 188: inline instanceOop InstanceKlass::allocate_instance(oop java_class, TRAPS) {
>> 
>> In moving this, can you eliminate any #includes at the top?  And migrate them to .cpp files that might need them.
>
> All the #include headers are removed except the `utilities/devirtualizer.inline.hpp`. The .cpp files that need it should include it before `oops/instanceKlass.inline.hpp` which violates the _sorted header filename_ in the coding style rules.

Good.  I think devirtualizer.inline.hpp is used by the GC inlined functions so should remain here.

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

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

From cjplummer at openjdk.org  Fri Mar  3 17:41:14 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 3 Mar 2023 17:41:14 GMT
Subject: RFR: 8303534: Merge CompactibleSpace into ContiguousSpace [v2]
In-Reply-To: <Y5ecs6y1UVWsigb317U2bmJP608sJ_jVk6g77HDUFpo=.cf9c490d-bdbd-4297-9a0c-172518a8285e@github.com>
References: <dPNxDwwSW0wlk4Fv6eYg8dsClKdfjNV9si2WZS2Npi0=.c4f52214-c8a1-4fe6-a513-9fb1e0995ae0@github.com>
 <Y5ecs6y1UVWsigb317U2bmJP608sJ_jVk6g77HDUFpo=.cf9c490d-bdbd-4297-9a0c-172518a8285e@github.com>
Message-ID: <8gVdjyz3i-jfbjjlZ9Cw84YNqZzqDLmn9gmF68VyLbs=.074e5e4a-1564-4244-8df2-cb97974ce68d@github.com>

On Fri, 3 Mar 2023 12:30:38 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple refactoring of merging two types.
>> 
>> Test: tier1-5
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright-year

SA changes look good.

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

Marked as reviewed by cjplummer (Reviewer).

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

From dnsimon at openjdk.org  Fri Mar  3 17:55:42 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 3 Mar 2023 17:55:42 GMT
Subject: RFR: 8303588: [JVMCI] make JVMCI source directories conform with
 standard layout
Message-ID: <1uJ1B_Mo_V1nye9Mvp59QFMvaW5-0wZeg_irFdc3MEA=.5f50a9ee-7b9b-4afd-b8d9-1e883cb37db8@github.com>

The layout of the sources in `jdk.internal.vm.ci` stems from their initial development outside the JDK where they adopted a layout influenced by Eclipse.

There's no good reason for maintaining this layout any more. Moving to a standard layout also means IDEs will be able to make sense of the JVMCI sources in `src.zip`.

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

Commit messages:
 - made JVMCI source directories conform with standard layout

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

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

From dnsimon at openjdk.org  Fri Mar  3 18:00:12 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 3 Mar 2023 18:00:12 GMT
Subject: RFR: 8303577: [JVMCI] OOME causes crash while translating exceptions
Message-ID: <tP7cn6cW3NkzhXP1WfAhFTq3p2GfMMI3lzmZBYNNEh0=.30ca6b53-1cff-416a-8035-76569787c008@github.com>

JDK-8297431 added code for special handling of OutOfMemoryError when translating an exception between libjvmci and HotSpot[1].
Unfortunately, this code was deleted by JDK-8298099 when moving the exception translation mechanism to VMSupport[2].
This causes the VM to crash when an OOME occurs while translating an exception from HotSpot to libjvmci.
This PR revives the deleted code.

This bug was found by running `test/jdk/java/util/concurrent/locks/Lock/OOMEInAQS.java` on libgraal. The fix now makes the test pass.

[1] https://github.com/openjdk/jdk/commit/952e10055135613e8ea2b818a4f35842936f5633#diff-4d3a3b7e7e12e1d5b4cf3e4677d9e0de5e9df3bbf1bbfa0d8d43d12098d67dc4R222-R234
[2] https://github.com/openjdk/jdk/commit/8b69a2e434ad2fa3369079622b57afb973d5bd9a#diff-7292551772c27b7152a3333f03cbbad90a897c5e37c6a97d4026be835e6d8fe1R121-R125

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

Commit messages:
 - decodeAndThrowThrowable needs to handle error codes

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

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

From kvn at openjdk.org  Fri Mar  3 18:06:15 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 3 Mar 2023 18:06:15 GMT
Subject: RFR: 8303588: [JVMCI] make JVMCI source directories conform with
 standard layout
In-Reply-To: <1uJ1B_Mo_V1nye9Mvp59QFMvaW5-0wZeg_irFdc3MEA=.5f50a9ee-7b9b-4afd-b8d9-1e883cb37db8@github.com>
References: <1uJ1B_Mo_V1nye9Mvp59QFMvaW5-0wZeg_irFdc3MEA=.5f50a9ee-7b9b-4afd-b8d9-1e883cb37db8@github.com>
Message-ID: <NdFDZBRAW8-TiGufW_y2TpZi_Kn_XPBd-_AvjXhBQHM=.b901b87c-eacb-4f59-adb7-ae3aa8cfd901@github.com>

On Fri, 3 Mar 2023 17:47:20 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> The layout of the sources in `jdk.internal.vm.ci` stems from their initial development outside the JDK where they adopted a layout influenced by Eclipse.
> 
> There's no good reason for maintaining this layout any more. Moving to a standard layout also means IDEs will be able to make sense of the JVMCI sources in `src.zip`.

Good.
Please, test it in mach5.

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

Marked as reviewed by kvn (Reviewer).

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

From kvn at openjdk.org  Fri Mar  3 18:08:37 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 3 Mar 2023 18:08:37 GMT
Subject: RFR: 8303577: [JVMCI] OOME causes crash while translating
 exceptions
In-Reply-To: <tP7cn6cW3NkzhXP1WfAhFTq3p2GfMMI3lzmZBYNNEh0=.30ca6b53-1cff-416a-8035-76569787c008@github.com>
References: <tP7cn6cW3NkzhXP1WfAhFTq3p2GfMMI3lzmZBYNNEh0=.30ca6b53-1cff-416a-8035-76569787c008@github.com>
Message-ID: <kHlMq4QljW_Y61Loe934e4rwB7e2lwJwTFj4arrUOqM=.719fbdd2-2204-4508-84f6-123739e4b457@github.com>

On Fri, 3 Mar 2023 15:40:01 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> JDK-8297431 added code for special handling of OutOfMemoryError when translating an exception between libjvmci and HotSpot[1].
> Unfortunately, this code was deleted by JDK-8298099 when moving the exception translation mechanism to VMSupport[2].
> This causes the VM to crash when an OOME occurs while translating an exception from HotSpot to libjvmci.
> This PR revives the deleted code.
> 
> This bug was found by running `test/jdk/java/util/concurrent/locks/Lock/OOMEInAQS.java` on libgraal. The fix now makes the test pass.
> 
> [1] https://github.com/openjdk/jdk/commit/952e10055135613e8ea2b818a4f35842936f5633#diff-4d3a3b7e7e12e1d5b4cf3e4677d9e0de5e9df3bbf1bbfa0d8d43d12098d67dc4R222-R234
> [2] https://github.com/openjdk/jdk/commit/8b69a2e434ad2fa3369079622b57afb973d5bd9a#diff-7292551772c27b7152a3333f03cbbad90a897c5e37c6a97d4026be835e6d8fe1R121-R125

Good.

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

Marked as reviewed by kvn (Reviewer).

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

From dholmes at openjdk.org  Fri Mar  3 21:25:06 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 3 Mar 2023 21:25:06 GMT
Subject: RFR: 8286781: Replace the deprecated/obsolete gethostbyname and
 inet_addr calls [v2]
In-Reply-To: <KCx5TxPnI3Mtj_Ksa9tru_IysRVy7w2hBBhCaI22u9o=.0f73d4aa-fac9-4f2d-b731-59b0daa820a1@github.com>
References: <hTpw51fgF4gk1I60vdXDpEWpZlISh4v_eNfoOQw2hds=.9a07f8c1-0af4-454b-8a9e-37d83403f7c0@github.com>
 <KCx5TxPnI3Mtj_Ksa9tru_IysRVy7w2hBBhCaI22u9o=.0f73d4aa-fac9-4f2d-b731-59b0daa820a1@github.com>
Message-ID: <z7NwxP1BlJ1tqnd7tz6NPSIWp3OqpXBHH_jztZTELIY=.61c5f1db-2d18-49f2-a495-c6302115c858@github.com>

On Fri, 3 Mar 2023 07:30:39 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Restrict getaddrinfo to IPv4 only as per the rest of the code
>
> Looks good.

Thanks for the reviews @kimbarrett  and @djelinski ! I'll leave this till early next week to integrate.

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

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

From sviswanathan at openjdk.org  Sat Mar  4 01:15:19 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Sat, 4 Mar 2023 01:15:19 GMT
Subject: RFR: 8302191: Performance degradation for float/double modulo on
 Linux [v9]
In-Reply-To: <cE1Rx7P-qflRs1y7BrpsD5amJDRjCRku5DT_scRArfY=.fc54c292-0090-4fb0-ac5b-c2fd6dc06039@github.com>
References: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
 <cE1Rx7P-qflRs1y7BrpsD5amJDRjCRku5DT_scRArfY=.fc54c292-0090-4fb0-ac5b-c2fd6dc06039@github.com>
Message-ID: <_z7GiZvqh8NpSWzxLMKrcQB_0g_xz8lneN9LOI6DedI=.6453aa68-1f70-4662-897c-04537214cd8a@github.com>

On Fri, 3 Mar 2023 13:45:11 GMT, Jan Kratochvil <duke at openjdk.org> wrote:

>> I have OCA already processed/approved. I am not Author but my Author request is being processed these days (sent to Rob McKenna).
>> I did regression test x86_64 OpenJDK-8. I will leave other regression testing on GHA.
>> The patch (and former GCC performance regression) affects only x86_64+i686.
>
> Jan Kratochvil 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 remote-tracking branch 'origin/master' into modulo
>  - Always include the _WIN64 workaround - a review by dholmes-ora.
>  - Remove comments to be moved to JBS (Bug System) - a review by jddarcy.
>  - Uppercase L - a review by turbanoff.
>  - Fix copyright author.
>  - Fix WIN32 vs. WIN64.
>  - Update according to the upstream review by David Holmes.
>  - 8302191: Performance degradation for float/double modulo on Linux

Very nice performance increase. The only concern I have is that the x87 fpu control (using fldcw instruction) is not set in 64 bit builds by the JVM anymore explicitly.  It is only set in the 32bit builds. Maybe @iwanowww or @shipilev have some thoughts on this.

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

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

From duke at openjdk.org  Sat Mar  4 02:28:43 2023
From: duke at openjdk.org (Jan Kratochvil)
Date: Sat, 4 Mar 2023 02:28:43 GMT
Subject: RFR: 8302191: Performance degradation for float/double modulo on
 Linux [v10]
In-Reply-To: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
References: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
Message-ID: <BZzGkFY8NqP3p7n2bpwgzx2d36xFsY2jDPHIw-g6qyg=.5a908fbb-047f-4145-9827-38aa10a0c30a@github.com>

> I have OCA already processed/approved. I am not Author but my Author request is being processed these days (sent to Rob McKenna).
> I did regression test x86_64 OpenJDK-8. I will leave other regression testing on GHA.
> The patch (and former GCC performance regression) affects only x86_64+i686.

Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:

  Fix win32 broken build.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12508/files
  - new: https://git.openjdk.org/jdk/pull/12508/files/cdcf89d7..3e1c05d0

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

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

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

From stuefe at openjdk.org  Sat Mar  4 07:05:45 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 4 Mar 2023 07:05:45 GMT
Subject: RFR: JDK-8296995: ostream should handle snprintf(3) errors in
 release builds [v5]
In-Reply-To: <lXBQPLCrniDiyp9OAfVdsHq3xVNsxxTWymy_1cSaiHg=.0f341fe2-7bcc-4640-bf2e-0f1883ee22e4@github.com>
References: <lXBQPLCrniDiyp9OAfVdsHq3xVNsxxTWymy_1cSaiHg=.0f341fe2-7bcc-4640-bf2e-0f1883ee22e4@github.com>
Message-ID: <87tTzvYaPryNHP6mcel-CEqUU6u8JoTo4VeQ0itFkN8=.a7fe6454-605d-4f64-925e-e5a51c844c78@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 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:

 - copyrights
 - erge branch 'master' into JDK-8296995-ostream-handle-sprintf-errors
 - fix copyright
 - feedback martin
 - JDK-8296995-ostream-handle-sprintf-errors

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11160/files
  - new: https://git.openjdk.org/jdk/pull/11160/files/b41f13d4..407345ca

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

  Stats: 384575 lines in 5749 files changed: 193196 ins; 138159 del; 53220 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 kbarrett at openjdk.org  Sat Mar  4 11:19:12 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 4 Mar 2023 11:19:12 GMT
Subject: RFR: 8302189: Mark assertion failures noreturn
In-Reply-To: <PhwlkTOKz7EsK0wAlY-IRGfno3c9TEqNf9WJIc3mVTg=.3f9273af-44e5-4d8f-beb4-0bc2b774b9d1@github.com>
References: <4gLeUT6_5s6WpG-b-0146d490ZRgBq_JON1-5P3Wgtk=.e0bc3fd3-fce0-47b8-9478-1de796128731@github.com>
 <PhwlkTOKz7EsK0wAlY-IRGfno3c9TEqNf9WJIc3mVTg=.3f9273af-44e5-4d8f-beb4-0bc2b774b9d1@github.com>
Message-ID: <stprjbPE3-XC5_Zmi7XvJ_eGVwHInOD1CbG1m_CdXkI=.d7ee8808-d60c-4f37-97c8-5cff4b96efa2@github.com>

On Fri, 3 Mar 2023 04:35:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I don't use these particular debugging mechanism, neither Debugger nor BREAKPOINT, but it seems potentially problematic to me that the removed BREAKPOINTs happened after the error was reported, and IIUC the new mechanism will activate before the error is reported.

The removed BREAKPOINTs were not happening after the error was reported.
Normally the report functions would report and die, without reaching the
BREAKPOINT at all.  They were only reachable when "Debugging" was enabled by
being in one of the manually invoked "commands", which disabled the report
function and made it return immediately to the BREAKPOINT, which isn't really
very interesting because in one of these commands we want to just "ignore"
errors entirely.

> make/hotspot/lib/CompileJvm.gmk line 103:
> 
>> 101: DISABLED_WARNINGS_xlc := tautological-compare shift-negative-value
>> 102: 
>> 103: DISABLED_WARNINGS_microsoft := 4624 4244 4291 4146 4127 4722
> 
> It is annoying that we don't document what these warnings are. :(

I've made the same comment in the past.  This time I decided to do something about it:
https://bugs.openjdk.org/browse/JDK-8303618
Document disabled C/C++ warnings on Windows

> src/hotspot/share/utilities/debug.cpp line 85:
> 
>> 83:   if (is_enabled()) {
>> 84:     fatal("Multiple Debugging contexts");
>> 85:   }
> 
> This seems too restrictive as you could hit different DebuggingContexts in different threads. ??

This facility is only intended for use by manually invoked commands while the program is stopped in a debugger. Multi-threaded use is not an issue (and was not supported previously either). I don't think there are any nested uses either, but I've now run across a couple of places where nesting could be useful. So I'm changing the state from a simple bool to a nesting counter.

> src/hotspot/share/utilities/debug.cpp line 290:
> 
>> 288:  private:
>> 289:   ResourceMark _rm;
>> 290:   DebuggingContext _debugging;
> 
> Why a different initialization syntax here?

I don't understand the question?  These are member variable declarations.

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

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

From kbarrett at openjdk.org  Sat Mar  4 11:23:58 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 4 Mar 2023 11:23:58 GMT
Subject: RFR: 8302189: Mark assertion failures noreturn [v2]
In-Reply-To: <4gLeUT6_5s6WpG-b-0146d490ZRgBq_JON1-5P3Wgtk=.e0bc3fd3-fce0-47b8-9478-1de796128731@github.com>
References: <4gLeUT6_5s6WpG-b-0146d490ZRgBq_JON1-5P3Wgtk=.e0bc3fd3-fce0-47b8-9478-1de796128731@github.com>
Message-ID: <BMN3OJv9QTo0bNa_BvIMuldsCZDRD1-YjiN826iXbG0=.44fd41e9-ea55-437a-9c0a-294d5daaea71@github.com>

> Also 8302799: Refactor Debugging variable usage for noreturn crash reporting

Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:

  make Debugging::_enabled a nesting counter

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12845/files
  - new: https://git.openjdk.org/jdk/pull/12845/files/ca68e500..f296ab62

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

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

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

From jwaters at openjdk.org  Sat Mar  4 19:01:15 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 4 Mar 2023 19:01:15 GMT
Subject: RFR: 8250269: Replace ATTRIBUTE_ALIGNED with alignas [v15]
In-Reply-To: <yIMSrBNH1uzWpx6VlqoK8x-WgEAzEOCP7PEpJyeQg48=.fef82236-f599-416d-8de0-f5f61d6ad96e@github.com>
References: <9QKV9cYFTo_1D8R-mI80lnewNkA0ceJNKFPbrvICxl4=.d6736b76-8324-4084-bede-6e144b4f6c04@github.com>
 <yIMSrBNH1uzWpx6VlqoK8x-WgEAzEOCP7PEpJyeQg48=.fef82236-f599-416d-8de0-f5f61d6ad96e@github.com>
Message-ID: <HBJxDfX7dIkvZSd1Wh0mFBCXlIxG6isfOs_R86I9Ykw=.a6c30bd5-ca24-478d-91b4-a0fe755d0b59@github.com>

On Sat, 4 Feb 2023 15:05:06 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> 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 15 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into alignas
>  - alignas
>  - Merge branch 'openjdk:master' into alignas
>  - Merge branch 'openjdk:master' into alignas
>  - Merge branch 'openjdk:master' into alignas
>  - Merge branch 'openjdk:master' into alignas
>  - Merge branch 'openjdk:master' into alignas
>  - Merge branch 'openjdk:master' into alignas
>  - Merge branch 'openjdk:master' into alignas
>  - Merge branch 'openjdk:master' into alignas
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/9971522f...a621bb62

:(

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

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

From dnsimon at openjdk.org  Sat Mar  4 21:49:02 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Sat, 4 Mar 2023 21:49:02 GMT
Subject: RFR: 8303588: [JVMCI] make JVMCI source directories conform with
 standard layout
In-Reply-To: <NdFDZBRAW8-TiGufW_y2TpZi_Kn_XPBd-_AvjXhBQHM=.b901b87c-eacb-4f59-adb7-ae3aa8cfd901@github.com>
References: <1uJ1B_Mo_V1nye9Mvp59QFMvaW5-0wZeg_irFdc3MEA=.5f50a9ee-7b9b-4afd-b8d9-1e883cb37db8@github.com>
 <NdFDZBRAW8-TiGufW_y2TpZi_Kn_XPBd-_AvjXhBQHM=.b901b87c-eacb-4f59-adb7-ae3aa8cfd901@github.com>
Message-ID: <77AUCWTeYZOzVv-uRmie21wQ6Csaz2_FCVseAwFXtrs=.9941a87f-4a8e-4089-aff6-db8297a15c9d@github.com>

On Fri, 3 Mar 2023 18:02:22 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Please, test it in mach5

Done - please see link in issue. All 6 failures are not related to this change.

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

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

From dnsimon at openjdk.org  Sat Mar  4 21:55:12 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Sat, 4 Mar 2023 21:55:12 GMT
Subject: RFR: 8303588: [JVMCI] make JVMCI source directories conform with
 standard layout
In-Reply-To: <NdFDZBRAW8-TiGufW_y2TpZi_Kn_XPBd-_AvjXhBQHM=.b901b87c-eacb-4f59-adb7-ae3aa8cfd901@github.com>
References: <1uJ1B_Mo_V1nye9Mvp59QFMvaW5-0wZeg_irFdc3MEA=.5f50a9ee-7b9b-4afd-b8d9-1e883cb37db8@github.com>
 <NdFDZBRAW8-TiGufW_y2TpZi_Kn_XPBd-_AvjXhBQHM=.b901b87c-eacb-4f59-adb7-ae3aa8cfd901@github.com>
Message-ID: <pmV8c_wC8z4XHNTA2KmnEEyFlMIx3LOK67hvWg2x6xE=.5ce27e23-cc74-41fb-b839-5acfd6be8e0f@github.com>

On Fri, 3 Mar 2023 18:02:22 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> The layout of the sources in `jdk.internal.vm.ci` stems from their initial development outside the JDK where they adopted a layout influenced by Eclipse.
>> 
>> There's no good reason for maintaining this layout any more. Moving to a standard layout also means IDEs will be able to make sense of the JVMCI sources in `src.zip`.
>
> Good.
> Please, test it in mach5.

Thanks for the review @vnkozlov . Since @tkrodriguez approved an internal review for these changes, I'm going to integrate.

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

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

From dnsimon at openjdk.org  Sat Mar  4 21:55:15 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Sat, 4 Mar 2023 21:55:15 GMT
Subject: Integrated: 8303588: [JVMCI] make JVMCI source directories conform
 with standard layout
In-Reply-To: <1uJ1B_Mo_V1nye9Mvp59QFMvaW5-0wZeg_irFdc3MEA=.5f50a9ee-7b9b-4afd-b8d9-1e883cb37db8@github.com>
References: <1uJ1B_Mo_V1nye9Mvp59QFMvaW5-0wZeg_irFdc3MEA=.5f50a9ee-7b9b-4afd-b8d9-1e883cb37db8@github.com>
Message-ID: <mwqhFU0FURJBF5nuKQmbIRkbtOYckjfuMyzHWZy_158=.9e2354e2-6abd-414a-b6c6-0b56be4c40e0@github.com>

On Fri, 3 Mar 2023 17:47:20 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> The layout of the sources in `jdk.internal.vm.ci` stems from their initial development outside the JDK where they adopted a layout influenced by Eclipse.
> 
> There's no good reason for maintaining this layout any more. Moving to a standard layout also means IDEs will be able to make sense of the JVMCI sources in `src.zip`.

This pull request has now been integrated.

Changeset: 9fdbf3cf
Author:    Doug Simon <dnsimon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9fdbf3cfc4bf58daa93807b47e403536e4681e90
Stats:     20 lines in 209 files changed: 0 ins; 20 del; 0 mod

8303588: [JVMCI] make JVMCI source directories conform with standard layout

Reviewed-by: kvn

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

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

From darcy at openjdk.org  Sun Mar  5 06:19:06 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sun, 5 Mar 2023 06:19:06 GMT
Subject: RFR: JDK-8302801: Remove fdlibm C sources [v4]
In-Reply-To: <fFJoo_g2Rqg062mR5ftOMCF6y9JrrlpW6wO1Vz0OeMI=.3a124adf-6ddf-4ab2-90d9-d26a400d09c7@github.com>
References: <fFJoo_g2Rqg062mR5ftOMCF6y9JrrlpW6wO1Vz0OeMI=.3a124adf-6ddf-4ab2-90d9-d26a400d09c7@github.com>
Message-ID: <Uc4nhjQFqZXY6fJscwzD38Z_CYgvcWMCEN1BFE1qNy8=.6a5e8b6c-d082-46e5-bc79-7cb7d24273b5@github.com>

> While the review of https://github.com/openjdk/jdk/pull/12800 finishes up, I thought I'd get out for the review the next phase of the FDLIBM port: removing the FDLIBM C sources from the repo.
> 
> A repo with the changes for JDK-8302027 and this PR successful build on the default set of platform and successfully run tier 1 tests, which includes tests of the math library.
> 
> There are a few remaining references to the case-independent string "fdlibm" in the make directory and HotSpot sources. HotSpot contains a partial fork for FDLIBM (a tine of FDLIBM?) to use for intrinsics. The remaining make machinery contains logic to determine what set of gcc options can be used for the compile.
> 
> The intention of this change is to remove use of FDLIBM for the core libraries.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:

 - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8302801-expr
 - Respond to review feedback.
 - Respond to review feedback and add description of transliteration process.
 - JDK-8302801: Remove fdlibm C sources
 - Update src/java.base/share/classes/java/lang/FdLibm.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Update src/java.base/share/classes/java/lang/FdLibm.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Update src/java.base/share/classes/java/lang/FdLibm.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Update src/java.base/share/classes/java/lang/FdLibm.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Update src/java.base/share/classes/java/lang/FdLibm.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Update src/java.base/share/classes/java/lang/FdLibm.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - ... and 10 more: https://git.openjdk.org/jdk/compare/1bb39a95...437a8fce

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

Changes: https://git.openjdk.org/jdk/pull/12821/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12821&range=03
  Stats: 6643 lines in 65 files changed: 20 ins; 6613 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/12821.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12821/head:pull/12821

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

From jwaters at openjdk.org  Sun Mar  5 15:39:14 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 5 Mar 2023 15:39:14 GMT
Subject: RFR: 8302189: Mark assertion failures noreturn [v2]
In-Reply-To: <stprjbPE3-XC5_Zmi7XvJ_eGVwHInOD1CbG1m_CdXkI=.d7ee8808-d60c-4f37-97c8-5cff4b96efa2@github.com>
References: <4gLeUT6_5s6WpG-b-0146d490ZRgBq_JON1-5P3Wgtk=.e0bc3fd3-fce0-47b8-9478-1de796128731@github.com>
 <PhwlkTOKz7EsK0wAlY-IRGfno3c9TEqNf9WJIc3mVTg=.3f9273af-44e5-4d8f-beb4-0bc2b774b9d1@github.com>
 <stprjbPE3-XC5_Zmi7XvJ_eGVwHInOD1CbG1m_CdXkI=.d7ee8808-d60c-4f37-97c8-5cff4b96efa2@github.com>
Message-ID: <RpSNK9GIjArbtBrThlIAAOmHNSAI7LSYDgOf8G6dtoM=.10720821-fe1b-47d1-8b4a-4935b6a15223@github.com>

On Sat, 4 Mar 2023 11:16:03 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> make/hotspot/lib/CompileJvm.gmk line 103:
>> 
>>> 101: DISABLED_WARNINGS_xlc := tautological-compare shift-negative-value
>>> 102: 
>>> 103: DISABLED_WARNINGS_microsoft := 4624 4244 4291 4146 4127 4722
>> 
>> It is annoying that we don't document what these warnings are. :(
>
> I've made the same comment in the past.  This time I decided to do something about it:
> https://bugs.openjdk.org/browse/JDK-8303618
> Document disabled C/C++ warnings on Windows

Looks like something I can help with, will assign the enhancement to myself

>> src/hotspot/share/utilities/debug.cpp line 290:
>> 
>>> 288:  private:
>>> 289:   ResourceMark _rm;
>>> 290:   DebuggingContext _debugging;
>> 
>> Why a different initialization syntax here?
>
> I don't understand the question?  These are member variable declarations.

I believe David is asking about why these particular member names were changed

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

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

From darcy at openjdk.org  Sun Mar  5 17:13:09 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sun, 5 Mar 2023 17:13:09 GMT
Subject: RFR: JDK-8302801: Remove fdlibm C sources [v4]
In-Reply-To: <3JvuLUDJO3_dzKHOsMocC6kGDEmnIQo_7uobd-VTzHg=.22565440-42ae-4d26-9d74-2cbb7c63f9ea@github.com>
References: <fFJoo_g2Rqg062mR5ftOMCF6y9JrrlpW6wO1Vz0OeMI=.3a124adf-6ddf-4ab2-90d9-d26a400d09c7@github.com>
 <W3_m-0cY0KTUdcoT5QUpxCBbB9P8QNedMSlL7ob-_94=.818f6ff9-b559-4313-a72e-1e07913b4dc9@github.com>
 <3JvuLUDJO3_dzKHOsMocC6kGDEmnIQo_7uobd-VTzHg=.22565440-42ae-4d26-9d74-2cbb7c63f9ea@github.com>
Message-ID: <uQoZHReFrel_izPKlfqwudhAYE_WA8flqfqJYO-LvCU=.d9428c55-ec5f-4843-af00-a0f5a41c2c63@github.com>

On Thu, 2 Mar 2023 18:27:09 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> make/autoconf/buildjdk-spec.gmk.in line 85:
>> 
>>> 83: JVM_LIBS := @OPENJDK_BUILD_JVM_LIBS@
>>> 84: 
>>> 85: FDLIBM_CFLAGS := @OPENJDK_BUILD_FDLIBM_CFLAGS@
>> 
>> If the hotspot build still needs `FDLIBM_CFLAGS`, then this line needs to stay.
>
> Okay; added back.

PS Successful Mach 5 job of default builds and tier 1 tests with this make line present.

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

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

From alanb at openjdk.org  Sun Mar  5 19:21:09 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 5 Mar 2023 19:21:09 GMT
Subject: RFR: JDK-8302801: Remove fdlibm C sources [v4]
In-Reply-To: <Uc4nhjQFqZXY6fJscwzD38Z_CYgvcWMCEN1BFE1qNy8=.6a5e8b6c-d082-46e5-bc79-7cb7d24273b5@github.com>
References: <fFJoo_g2Rqg062mR5ftOMCF6y9JrrlpW6wO1Vz0OeMI=.3a124adf-6ddf-4ab2-90d9-d26a400d09c7@github.com>
 <Uc4nhjQFqZXY6fJscwzD38Z_CYgvcWMCEN1BFE1qNy8=.6a5e8b6c-d082-46e5-bc79-7cb7d24273b5@github.com>
Message-ID: <vBrgkF0eiSHRVZVufKvfRbZXscKrUDQ4tgL2haNiKg8=.704fade8-a203-41d4-a86e-a1db37a0a64e@github.com>

On Sun, 5 Mar 2023 06:19:06 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> While the review of https://github.com/openjdk/jdk/pull/12800 finishes up, I thought I'd get out for the review the next phase of the FDLIBM port: removing the FDLIBM C sources from the repo.
>> 
>> A repo with the changes for JDK-8302027 and this PR successful build on the default set of platform and successfully run tier 1 tests, which includes tests of the math library.
>> 
>> There are a few remaining references to the case-independent string "fdlibm" in the make directory and HotSpot sources. HotSpot contains a partial fork for FDLIBM (a tine of FDLIBM?) to use for intrinsics. The remaining make machinery contains logic to determine what set of gcc options can be used for the compile.
>> 
>> The intention of this change is to remove use of FDLIBM for the core libraries.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
> 
>  - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8302801-expr
>  - Respond to review feedback.
>  - Respond to review feedback and add description of transliteration process.
>  - JDK-8302801: Remove fdlibm C sources
>  - Update src/java.base/share/classes/java/lang/FdLibm.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update src/java.base/share/classes/java/lang/FdLibm.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update src/java.base/share/classes/java/lang/FdLibm.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update src/java.base/share/classes/java/lang/FdLibm.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update src/java.base/share/classes/java/lang/FdLibm.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update src/java.base/share/classes/java/lang/FdLibm.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/1bb39a95...437a8fce

I don't have any other comments on this, looks good.

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

Marked as reviewed by alanb (Reviewer).

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

From clanger at openjdk.org  Sun Mar  5 20:46:24 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Sun, 5 Mar 2023 20:46:24 GMT
Subject: RFR: JDK-8302320: AsyncGetCallTrace obtains too few frames in
 sanity test [v6]
In-Reply-To: <ZExSIuGxZu1gYcEmsVBLweVtBIfLerE0hJYQ985ersc=.a59975fc-ce00-41d3-b05c-24b8e646bb41@github.com>
References: <rgDlPuJYBhLWIP9ZWx44nE1v8bm_dhNtCJtU1S6JA48=.a9018b41-7e54-4c13-bedb-627613e1fd2b@github.com>
 <ZExSIuGxZu1gYcEmsVBLweVtBIfLerE0hJYQ985ersc=.a59975fc-ce00-41d3-b05c-24b8e646bb41@github.com>
Message-ID: <KyycoQ_DCw166BNXOE_KM59hjMT1k6MrUtAa1NVtXpY=.453dcd54-b1e1-4563-ba6e-b2a95d525e75@github.com>

On Tue, 21 Feb 2023 08:58:50 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Extends the existing AsyncGetCallTrace test case and fixes the issue.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update full name

> [db483a3](https://github.com/openjdk/jdk/commit/db483a38a815f85bd9668749674b5f0f6e4b27b4).

You need to do that on the [commit](https://github.com/openjdk/jdk/commit/db483a38a815f85bd9668749674b5f0f6e4b27b4), not on the PR. However, not sure whether your author role is sufficient and everything Github is set up correctly...

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

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

From dnsimon at openjdk.org  Sun Mar  5 22:08:07 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Sun, 5 Mar 2023 22:08:07 GMT
Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v2]
In-Reply-To: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>
References: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>
Message-ID: <HxN95BXbcVPIlKwADW76OaVDJh7oC6OYfGkp9j8vez4=.eb16bc40-c088-460b-826d-66b0eebd8157@github.com>

> This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for accessing annotations. The main differences from `java.lang.reflect.AnnotatedElement` are:
> * Each `Annotated` method explicitly specifies the annotation type(s) for which it wants annotation data. That is, there is no direct equivalent of `AnnotatedElement.getAnnotations()`.
> * Annotation data is returned in a map-like object (of type `jdk.vm.ci.meta.AnnotationData`) instead of in an `Annotation` object. This works better for libgraal as it avoids the need for annotation types to be loaded and included in libgraal.
>  
> To demonstrate the new API, here's an example in terms `java.lang.reflect.AnnotatedElement` (which `ResolvedJavaType` implements):
> 
>     ResolvedJavaMethod method = ...;
>     ExplodeLoop a = method.getAnnotation(ExplodeLoop.class);
>     return switch (a.kind()) {
>         case FULL_UNROLL -> LoopExplosionKind.FULL_UNROLL;
>         case FULL_UNROLL_UNTIL_RETURN -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>         ...
>     }
> 
> 
> The same code using the new API:
> 
> 
>     ResolvedJavaMethod method = ...;
>     ResolvedJavaType explodeLoopType = ...;
>     AnnotationData a = method.getAnnotationDataFor(explodeLoopType);
>     return switch (a.getEnum("kind").getName()) {
>         case "FULL_UNROLL" -> LoopExplosionKind.FULL_UNROLL;
>         case "FULL_UNROLL_UNTIL_RETURN" -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>         ...
>     }
> 
> 
> The implementation relies on new methods in `jdk.internal.vm.VMSupport` for parsing annotations and serializing/deserializing to/from a byte array. This allows the annotation data to be passed from the HotSpot heap to the libgraal heap.

Doug Simon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - added support for inherited annotations
 - Merge branch 'master' into JDK-8303431
 - made AnnotationDataDecoder package-private
 - add annotation API to JVMCI

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

Changes: https://git.openjdk.org/jdk/pull/12810/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12810&range=01
  Stats: 2752 lines in 33 files changed: 2700 ins; 24 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/12810.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12810/head:pull/12810

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

From dholmes at openjdk.org  Sun Mar  5 22:28:11 2023
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 5 Mar 2023 22:28:11 GMT
Subject: RFR: JDK-8302801: Remove fdlibm C sources [v4]
In-Reply-To: <Uc4nhjQFqZXY6fJscwzD38Z_CYgvcWMCEN1BFE1qNy8=.6a5e8b6c-d082-46e5-bc79-7cb7d24273b5@github.com>
References: <fFJoo_g2Rqg062mR5ftOMCF6y9JrrlpW6wO1Vz0OeMI=.3a124adf-6ddf-4ab2-90d9-d26a400d09c7@github.com>
 <Uc4nhjQFqZXY6fJscwzD38Z_CYgvcWMCEN1BFE1qNy8=.6a5e8b6c-d082-46e5-bc79-7cb7d24273b5@github.com>
Message-ID: <tajuJTkpssx47QdOcXvWemf-CbC5-MxqYssvIHeJz1Q=.45674d41-67fe-40d2-b62d-f9bf4351dc8c@github.com>

On Sun, 5 Mar 2023 06:19:06 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> While the review of https://github.com/openjdk/jdk/pull/12800 finishes up, I thought I'd get out for the review the next phase of the FDLIBM port: removing the FDLIBM C sources from the repo.
>> 
>> A repo with the changes for JDK-8302027 and this PR successful build on the default set of platform and successfully run tier 1 tests, which includes tests of the math library.
>> 
>> There are a few remaining references to the case-independent string "fdlibm" in the make directory and HotSpot sources. HotSpot contains a partial fork for FDLIBM (a tine of FDLIBM?) to use for intrinsics. The remaining make machinery contains logic to determine what set of gcc options can be used for the compile.
>> 
>> The intention of this change is to remove use of FDLIBM for the core libraries.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
> 
>  - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8302801-expr
>  - Respond to review feedback.
>  - Respond to review feedback and add description of transliteration process.
>  - JDK-8302801: Remove fdlibm C sources
>  - Update src/java.base/share/classes/java/lang/FdLibm.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update src/java.base/share/classes/java/lang/FdLibm.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update src/java.base/share/classes/java/lang/FdLibm.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update src/java.base/share/classes/java/lang/FdLibm.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update src/java.base/share/classes/java/lang/FdLibm.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update src/java.base/share/classes/java/lang/FdLibm.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/1bb39a95...437a8fce

Marked as reviewed by dholmes (Reviewer).

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

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

From dnsimon at openjdk.org  Sun Mar  5 22:37:38 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Sun, 5 Mar 2023 22:37:38 GMT
Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v3]
In-Reply-To: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>
References: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>
Message-ID: <S01OqjUpY3g_c60VORZQ2UOT7LiyJtdCucB2kjHOhV4=.0c7d83a5-323a-4f92-be2d-c04518088c8e@github.com>

> This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for accessing annotations. The main differences from `java.lang.reflect.AnnotatedElement` are:
> * Each `Annotated` method explicitly specifies the annotation type(s) for which it wants annotation data. That is, there is no direct equivalent of `AnnotatedElement.getAnnotations()`.
> * Annotation data is returned in a map-like object (of type `jdk.vm.ci.meta.AnnotationData`) instead of in an `Annotation` object. This works better for libgraal as it avoids the need for annotation types to be loaded and included in libgraal.
>  
> To demonstrate the new API, here's an example in terms `java.lang.reflect.AnnotatedElement` (which `ResolvedJavaType` implements):
> 
>     ResolvedJavaMethod method = ...;
>     ExplodeLoop a = method.getAnnotation(ExplodeLoop.class);
>     return switch (a.kind()) {
>         case FULL_UNROLL -> LoopExplosionKind.FULL_UNROLL;
>         case FULL_UNROLL_UNTIL_RETURN -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>         ...
>     }
> 
> 
> The same code using the new API:
> 
> 
>     ResolvedJavaMethod method = ...;
>     ResolvedJavaType explodeLoopType = ...;
>     AnnotationData a = method.getAnnotationDataFor(explodeLoopType);
>     return switch (a.getEnum("kind").getName()) {
>         case "FULL_UNROLL" -> LoopExplosionKind.FULL_UNROLL;
>         case "FULL_UNROLL_UNTIL_RETURN" -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>         ...
>     }
> 
> 
> The implementation relies on new methods in `jdk.internal.vm.VMSupport` for parsing annotations and serializing/deserializing to/from a byte array. This allows the annotation data to be passed from the HotSpot heap to the libgraal heap.

Doug Simon has updated the pull request incrementally with one additional commit since the last revision:

  fixed whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12810/files
  - new: https://git.openjdk.org/jdk/pull/12810/files/8743e8b9..3dd5ef9c

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

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

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

From kvn at openjdk.org  Mon Mar  6 03:08:17 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 6 Mar 2023 03:08:17 GMT
Subject: RFR: JDK-8302801: Remove fdlibm C sources [v4]
In-Reply-To: <Uc4nhjQFqZXY6fJscwzD38Z_CYgvcWMCEN1BFE1qNy8=.6a5e8b6c-d082-46e5-bc79-7cb7d24273b5@github.com>
References: <fFJoo_g2Rqg062mR5ftOMCF6y9JrrlpW6wO1Vz0OeMI=.3a124adf-6ddf-4ab2-90d9-d26a400d09c7@github.com>
 <Uc4nhjQFqZXY6fJscwzD38Z_CYgvcWMCEN1BFE1qNy8=.6a5e8b6c-d082-46e5-bc79-7cb7d24273b5@github.com>
Message-ID: <-GBkdRKUf-hykdFTOo44ZVnuJSyhGzfCid3xeUHuMb0=.9225c4b6-65f8-4e54-8dac-c300872f660b@github.com>

On Sun, 5 Mar 2023 06:19:06 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> While the review of https://github.com/openjdk/jdk/pull/12800 finishes up, I thought I'd get out for the review the next phase of the FDLIBM port: removing the FDLIBM C sources from the repo.
>> 
>> A repo with the changes for JDK-8302027 and this PR successful build on the default set of platform and successfully run tier 1 tests, which includes tests of the math library.
>> 
>> There are a few remaining references to the case-independent string "fdlibm" in the make directory and HotSpot sources. HotSpot contains a partial fork for FDLIBM (a tine of FDLIBM?) to use for intrinsics. The remaining make machinery contains logic to determine what set of gcc options can be used for the compile.
>> 
>> The intention of this change is to remove use of FDLIBM for the core libraries.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
> 
>  - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8302801-expr
>  - Respond to review feedback.
>  - Respond to review feedback and add description of transliteration process.
>  - JDK-8302801: Remove fdlibm C sources
>  - Update src/java.base/share/classes/java/lang/FdLibm.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update src/java.base/share/classes/java/lang/FdLibm.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update src/java.base/share/classes/java/lang/FdLibm.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update src/java.base/share/classes/java/lang/FdLibm.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update src/java.base/share/classes/java/lang/FdLibm.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update src/java.base/share/classes/java/lang/FdLibm.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/1bb39a95...437a8fce

HotSpot changes look good.

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

Marked as reviewed by kvn (Reviewer).

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

From aboldtch at openjdk.org  Mon Mar  6 07:08:19 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 6 Mar 2023 07:08:19 GMT
Subject: RFR: 8300926: Several startup regressions ~6-70% in 21-b6 all
 platforms [v6]
In-Reply-To: <nXKSskpVRVCjCKFaz5S00u1LZXlpsMzbxmCzFfyZFcY=.0d2f92c8-4afc-43eb-a818-86f0bc50e03a@github.com>
References: <yAP6c7wzGguBfKuzvbjMZdnaqydAz4PFn0pgR1UGj9s=.ce872f5d-3f7a-4e24-99d5-da5e80855ea4@github.com>
 <nXKSskpVRVCjCKFaz5S00u1LZXlpsMzbxmCzFfyZFcY=.0d2f92c8-4afc-43eb-a818-86f0bc50e03a@github.com>
Message-ID: <kKCcL0NUamcwIPSn698FOlgWzt_t9ZS-S_vL40m_oBQ=.3576009b-018b-453b-9094-1a14d4dd7578@github.com>

On Thu, 23 Feb 2023 20:14:32 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi all, please consider.
>> 
>> The original issue was when thread 1 asked to deopt nmethod set X and thread 2 asked for the same or a subset of X.
>> All method will already be marked, but the actual deoptimizing, not entrant, patching PC on stacks and patching post call nops, was not done yet. Which meant thread 2 could 'pass' thread 1.
>> Most places did deopt under Compile_lock, thus this is not an issue, but WB and clearCallSiteContext do not.
>> 
>> Since a handshakes may take long before completion and Compile_lock is used for so much more than deopts.
>> The fix in https://bugs.openjdk.org/browse/JDK-8299074 instead always emitted a handshake even when everything was already marked. (instead of adding Compile_lock to all places)
>> 
>> This turnout to be problematic in the startup, for example the number of deopt handshakes in jetty dry run startup went from 5 to 39 handshakes.
>> 
>> This fix first adds a barrier for which you do not pass until the requested deopts have happened and it coalesces the handshakes.
>> Secondly it moves handshakes part out of the Compile_lock where it is possible.
>> 
>> Which means we fix the performance bug and we reduce the contention on Compile_lock, meaning higher throughput in compiler and things such as class-loading.
>> 
>> It passes t1-t7 with flying colours! t8 still not completed and I'm redoing some testing due to last minute simplifications.
>> 
>> Thanks, Robbin
>
> Robbin Ehn has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Comment fixes
>  - Include/fwd fixes

src/hotspot/share/prims/whitebox.cpp line 798:

> 796:       result += mh->method_holder()->mark_osr_nmethods(&deopt_scope, mh());
> 797:     } else if (mh->code() != nullptr) {
> 798:       deopt_scope.mark(mh->code());

I was working on a patch based on top of this one and had a crash here.

The second call to `mh->code()` returned a `nullptr`. It looks racy to me and seems like the only thing protecting `CompileMethod::code()` is the `CompiledMethod_lock` which is not held here. 

Regardless `mh->code()` should probably only be loaded once. (Or at least not re-loaded after the nullptr check)

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

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

From kbarrett at openjdk.org  Mon Mar  6 07:35:00 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 6 Mar 2023 07:35:00 GMT
Subject: RFR: 8303621: BitMap::iterate should support lambdas and other
 function objects
Message-ID: <G6DDCDP5PMEOH43G8GNeamEnSMNO_4gMsqQ_zuTUZA8=.1608a894-0707-4d87-b022-e7ee318b69f6@github.com>

Please review this enhancement of BitMap::iterate to support lambdas and other
function objects as the operation being applied to the set bit indices. Some
for-loops using BitMap::get_next_one_offset have been changed to use
BitMap::iterate with a lambda.

(One reason for changing the for-loops is that I'm considering a change to the
get_next_one_offset API, and reducing the number of direct uses will simplify
that.)

For convenience, the function can either return void (always iterate over the
whole range) or bool (stop iteration if returns false).  Iteration using
closure objects invoked via a do_bit member function are now implemented by
being wrapped in a lambda, so get the same convenience.  (Though, of course,
if the closure is derived from BitMapClosure then do_bit returns bool.)

The unit tests are written as "early" tests, not requiring an initialized VM.
They also avoid any C heap allocation (even though C heap allocation has very
early support). This is done to minimize the requirements for running the
tests, since BitMap is used in a lot of places. This attempts to run these
tests before uses. (Yes, I know about JDK-8257226; maybe that will be fixed
someday.) (Some existing BitMap gtests should be modified to do similarly; see
JDK-8303636.)

Testing:
mach5 tier1-7

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

Commit messages:
 - use iterate with lambda
 - bitmap iteration supports lambda

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

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

From eosterlund at openjdk.org  Mon Mar  6 08:01:28 2023
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 6 Mar 2023 08:01:28 GMT
Subject: Integrated: 8302780: Add support for vectorized arraycopy GC barriers
In-Reply-To: <SU-lpFUY3nGTCSM5k7HrOR2xGgNhPFRNDFUa6JBNEMQ=.2ceac514-334b-4201-8f7b-f17b9ebf3505@github.com>
References: <SU-lpFUY3nGTCSM5k7HrOR2xGgNhPFRNDFUa6JBNEMQ=.2ceac514-334b-4201-8f7b-f17b9ebf3505@github.com>
Message-ID: <iRXIbMVK-XdnaDOAwZUuZXzWCYosb3XxQ8u4RMK8uNE=.dda53f82-3468-406a-9e95-b4499a778f4e@github.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
On Mon, 20 Feb 2023 15:23:04 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> So far, the arraycopy stubs have performed some kind of bulk pre/post barriers for arraycopy, which have been good enough, and allowed the copying itself to be done with plain loads and stores. For generational ZGC, this approach is not good enough, and we need barriers for the actual copying, but instead don't need the pre/post barriers. To prepare the JVM for generational ZGC, we need to add an API for arraycopy barriers.

This pull request has now been integrated.

Changeset: 5f153e05
Author:    Erik ?sterlund <eosterlund at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5f153e056b1929a306b0907f4528bbd2766699c2
Stats:     970 lines in 11 files changed: 663 ins; 30 del; 277 mod

8302780: Add support for vectorized arraycopy GC barriers

Co-authored-by: Yadong Wang <yadongwang at openjdk.org>
Reviewed-by: ayang, fyang, rcastanedalo, aph

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

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

From rcastanedalo at openjdk.org  Mon Mar  6 08:42:31 2023
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 6 Mar 2023 08:42:31 GMT
Subject: RFR: 8302780: Add support for vectorized arraycopy GC barriers
 [v8]
In-Reply-To: <gvDgRkVLCWKo7eMNg09fMG2u59Z7B6RwPmEkYl-9588=.54ec61a2-e086-41a4-9ebe-9b459c26e9f7@github.com>
References: <SU-lpFUY3nGTCSM5k7HrOR2xGgNhPFRNDFUa6JBNEMQ=.2ceac514-334b-4201-8f7b-f17b9ebf3505@github.com>
 <BWqOjj4KikZ2Mj14NNMdbAhMaY0rsj0289AEAQFqegw=.af04f90a-7548-4bfd-8399-ab5a763b8dd1@github.com>
 <UrZD6IsIiDp9Fdqc2LPq5uZhrke-AEuZYeakmtAgjlA=.d89ec381-7fb0-4486-8b83-7a10536fc5bd@github.com>
 <gvDgRkVLCWKo7eMNg09fMG2u59Z7B6RwPmEkYl-9588=.54ec61a2-e086-41a4-9ebe-9b459c26e9f7@github.com>
Message-ID: <KNokEh-aK8l5eVzZFb39mQjEK7tYdLaF0LgJ-lIx7nQ=.ef3b8b4e-bb52-4a48-9602-02125ef96d41@github.com>

On Thu, 2 Mar 2023 10:02:59 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > In my opinion, the (very much needed) changes you suggest are outside the scope of this PR, which is about lifting the memory accesses, in their existing form, to a barrier API-level. Conflating this with your suggested changes would make it harder to review this PR, which is sufficiently complex in its current form. I totally agree that your suggestions would improve readability and maintainability, but couldn't we apply them in a follow-up RFE?
> 
> I disagree in every way. The added complexity, which is fixed so it no longer matters, made it near-impossible for me to reason about this PR. And, as John Rose put it, like any good carpenter we should clean up as we work.

Just to be clear, my comment was specifically about the loop re-rolling part of your suggestions. I see now that this was not clear in my comment, sorry about that.

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

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

From aboldtch at openjdk.org  Mon Mar  6 09:00:06 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 6 Mar 2023 09:00:06 GMT
Subject: RFR: 8303621: BitMap::iterate should support lambdas and other
 function objects
In-Reply-To: <G6DDCDP5PMEOH43G8GNeamEnSMNO_4gMsqQ_zuTUZA8=.1608a894-0707-4d87-b022-e7ee318b69f6@github.com>
References: <G6DDCDP5PMEOH43G8GNeamEnSMNO_4gMsqQ_zuTUZA8=.1608a894-0707-4d87-b022-e7ee318b69f6@github.com>
Message-ID: <-3SOW9HL0EDTdD3UdOXl1w2z1do67Y7CltyoXYYL-aY=.0d69ad12-d9b3-4819-81cb-fb34ff2eee63@github.com>

On Mon, 6 Mar 2023 07:27:23 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this enhancement of BitMap::iterate to support lambdas and other
> function objects as the operation being applied to the set bit indices. Some
> for-loops using BitMap::get_next_one_offset have been changed to use
> BitMap::iterate with a lambda.
> 
> (One reason for changing the for-loops is that I'm considering a change to the
> get_next_one_offset API, and reducing the number of direct uses will simplify
> that.)
> 
> For convenience, the function can either return void (always iterate over the
> whole range) or bool (stop iteration if returns false).  Iteration using
> closure objects invoked via a do_bit member function are now implemented by
> being wrapped in a lambda, so get the same convenience.  (Though, of course,
> if the closure is derived from BitMapClosure then do_bit returns bool.)
> 
> The unit tests are written as "early" tests, not requiring an initialized VM.
> They also avoid any C heap allocation (even though C heap allocation has very
> early support). This is done to minimize the requirements for running the
> tests, since BitMap is used in a lot of places. This attempts to run these
> tests before uses. (Yes, I know about JDK-8257226; maybe that will be fixed
> someday.) (Some existing BitMap gtests should be modified to do similarly; see
> JDK-8303636.)
> 
> Testing:
> mach5 tier1-7

lgtm.

Nice cleanup, makes code easier to read.

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

Marked as reviewed by aboldtch (Committer).

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

From tschatzl at openjdk.org  Mon Mar  6 09:39:03 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 6 Mar 2023 09:39:03 GMT
Subject: RFR: 8303621: BitMap::iterate should support lambdas and other
 function objects
In-Reply-To: <G6DDCDP5PMEOH43G8GNeamEnSMNO_4gMsqQ_zuTUZA8=.1608a894-0707-4d87-b022-e7ee318b69f6@github.com>
References: <G6DDCDP5PMEOH43G8GNeamEnSMNO_4gMsqQ_zuTUZA8=.1608a894-0707-4d87-b022-e7ee318b69f6@github.com>
Message-ID: <aUxNxTNaJyGD6WzSj1fTuNCUIK0jOp6TS1-dPdRYRKk=.0175c62d-f702-4091-b05c-2a9fc527fef8@github.com>

On Mon, 6 Mar 2023 07:27:23 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this enhancement of BitMap::iterate to support lambdas and other
> function objects as the operation being applied to the set bit indices. Some
> for-loops using BitMap::get_next_one_offset have been changed to use
> BitMap::iterate with a lambda.
> 
> (One reason for changing the for-loops is that I'm considering a change to the
> get_next_one_offset API, and reducing the number of direct uses will simplify
> that.)
> 
> For convenience, the function can either return void (always iterate over the
> whole range) or bool (stop iteration if returns false).  Iteration using
> closure objects invoked via a do_bit member function are now implemented by
> being wrapped in a lambda, so get the same convenience.  (Though, of course,
> if the closure is derived from BitMapClosure then do_bit returns bool.)
> 
> The unit tests are written as "early" tests, not requiring an initialized VM.
> They also avoid any C heap allocation (even though C heap allocation has very
> early support). This is done to minimize the requirements for running the
> tests, since BitMap is used in a lot of places. This attempts to run these
> tests before uses. (Yes, I know about JDK-8257226; maybe that will be fixed
> someday.) (Some existing BitMap gtests should be modified to do similarly; see
> JDK-8303636.)
> 
> Testing:
> mach5 tier1-7

Marked as reviewed by tschatzl (Reviewer).

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

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

From tschatzl at openjdk.org  Mon Mar  6 09:41:12 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 6 Mar 2023 09:41:12 GMT
Subject: RFR: 8303534: Merge CompactibleSpace into ContiguousSpace [v2]
In-Reply-To: <Y5ecs6y1UVWsigb317U2bmJP608sJ_jVk6g77HDUFpo=.cf9c490d-bdbd-4297-9a0c-172518a8285e@github.com>
References: <dPNxDwwSW0wlk4Fv6eYg8dsClKdfjNV9si2WZS2Npi0=.c4f52214-c8a1-4fe6-a513-9fb1e0995ae0@github.com>
 <Y5ecs6y1UVWsigb317U2bmJP608sJ_jVk6g77HDUFpo=.cf9c490d-bdbd-4297-9a0c-172518a8285e@github.com>
Message-ID: <tT81RD8JdA31EBCauGuUtj9ksrR5KI2deds2PE5-_jc=.61b8bdb2-6dae-4e77-8cf3-ce2e388db03a@github.com>

On Fri, 3 Mar 2023 12:30:38 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple refactoring of merging two types.
>> 
>> Test: tier1-5
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright-year

Marked as reviewed by tschatzl (Reviewer).

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

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

From kbarrett at openjdk.org  Mon Mar  6 10:15:36 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 6 Mar 2023 10:15:36 GMT
Subject: RFR: 8303621: BitMap::iterate should support lambdas and other
 function objects
In-Reply-To: <G6DDCDP5PMEOH43G8GNeamEnSMNO_4gMsqQ_zuTUZA8=.1608a894-0707-4d87-b022-e7ee318b69f6@github.com>
References: <G6DDCDP5PMEOH43G8GNeamEnSMNO_4gMsqQ_zuTUZA8=.1608a894-0707-4d87-b022-e7ee318b69f6@github.com>
Message-ID: <AKhOQrKDcCIMboN8ObIBh1NMGQq8FYf21aa3sDRmW4o=.27c0cce4-e9c7-47e7-9deb-f60180c2f99c@github.com>

On Mon, 6 Mar 2023 07:27:23 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this enhancement of BitMap::iterate to support lambdas and other
> function objects as the operation being applied to the set bit indices. Some
> for-loops using BitMap::get_next_one_offset have been changed to use
> BitMap::iterate with a lambda.
> 
> (One reason for changing the for-loops is that I'm considering a change to the
> get_next_one_offset API, and reducing the number of direct uses will simplify
> that.)
> 
> For convenience, the function can either return void (always iterate over the
> whole range) or bool (stop iteration if returns false).  Iteration using
> closure objects invoked via a do_bit member function are now implemented by
> being wrapped in a lambda, so get the same convenience.  (Though, of course,
> if the closure is derived from BitMapClosure then do_bit returns bool.)
> 
> The unit tests are written as "early" tests, not requiring an initialized VM.
> They also avoid any C heap allocation (even though C heap allocation has very
> early support). This is done to minimize the requirements for running the
> tests, since BitMap is used in a lot of places. This attempts to run these
> tests before uses. (Yes, I know about JDK-8257226; maybe that will be fixed
> someday.) (Some existing BitMap gtests should be modified to do similarly; see
> JDK-8303636.)
> 
> Testing:
> mach5 tier1-7

src/hotspot/share/utilities/bitMap.hpp line 273:

> 271:   // terminates early.  Otherwise, the result must be convertible to bool.
> 272:   //
> 273:   // - cl->do_bit(i) is a valid expression whose result is convertible to bool.

This description was an intermediate that I wasn't finished with, and isn't correct since it doesn't
describe `cl->do_bit(i)` as potentially returning void, which is supported by the implementation.
I seem to have lost the final version, and will need to rewrite it.

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

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

From iwalulya at openjdk.org  Mon Mar  6 10:22:27 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 6 Mar 2023 10:22:27 GMT
Subject: RFR: 8191565: Last-ditch Full GC should also move humongous
 objects [v2]
In-Reply-To: <58l059EvQI6HNQyjUYSGYEWt6x-c1yvtmfX1QWfinH8=.87517ba1-ec81-4b9f-a41b-b05c8d33cf3d@github.com>
References: <58l059EvQI6HNQyjUYSGYEWt6x-c1yvtmfX1QWfinH8=.87517ba1-ec81-4b9f-a41b-b05c8d33cf3d@github.com>
Message-ID: <zBpBWEG2BUS8-FIZ1V-JRiq1x8yifAGRQL11KSZSilo=.eaa8371b-a3cf-4acc-a7d6-28e9d8945444@github.com>

> Hi All,
> 
> Please review this change to move humongous regions during the Last-Ditch full gc ( on `do_maximal_compaction`). This change will enable G1 to avoid encountering Out-Of-Memory errors that may occur due to the fragmentation of memory regions caused by the allocation of large memory blocks.
> 
> Here's how it works: At the end of `phase2_prepare_compaction`, G1 performs a serial compaction process for regular objects, which results in the heap being divided into two parts. The first part is a densely populated prefix that contains all the regular objects that have been moved. The second part consists of the remaining heap space, which may contain free regions, uncommitted regions, and regions that are not compacting. By moving/compacting the humongous objects in the second part of the heap closer to the dense prefix, G1 reduces the region fragmentation and avoids running into OOM errors.
> 
> We have enabled for G1 the Jtreg test that was previously used only for Shenandoah to test such workload. 
> 
> Testing: Tier 1-3

Ivan Walulya has updated the pull request incrementally with two additional commits since the last revision:

 - Refactor resetting humongous metadata
 - Thomas review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12830/files
  - new: https://git.openjdk.org/jdk/pull/12830/files/f4951d37..6f8dd514

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

  Stats: 219 lines in 12 files changed: 71 ins; 103 del; 45 mod
  Patch: https://git.openjdk.org/jdk/pull/12830.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12830/head:pull/12830

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

From kbarrett at openjdk.org  Mon Mar  6 10:33:36 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 6 Mar 2023 10:33:36 GMT
Subject: RFR: 8303621: BitMap::iterate should support lambdas and other
 function objects [v2]
In-Reply-To: <G6DDCDP5PMEOH43G8GNeamEnSMNO_4gMsqQ_zuTUZA8=.1608a894-0707-4d87-b022-e7ee318b69f6@github.com>
References: <G6DDCDP5PMEOH43G8GNeamEnSMNO_4gMsqQ_zuTUZA8=.1608a894-0707-4d87-b022-e7ee318b69f6@github.com>
Message-ID: <CmS2TJp8CqKBnTMA0NAPRTR3InnCUUWsf3ykV-VQWZI=.6af78463-cdc3-4142-b81b-379e43a4ac1f@github.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
> Please review this enhancement of BitMap::iterate to support lambdas and other
> function objects as the operation being applied to the set bit indices. Some
> for-loops using BitMap::get_next_one_offset have been changed to use
> BitMap::iterate with a lambda.
> 
> (One reason for changing the for-loops is that I'm considering a change to the
> get_next_one_offset API, and reducing the number of direct uses will simplify
> that.)
> 
> For convenience, the function can either return void (always iterate over the
> whole range) or bool (stop iteration if returns false).  Iteration using
> closure objects invoked via a do_bit member function are now implemented by
> being wrapped in a lambda, so get the same convenience.  (Though, of course,
> if the closure is derived from BitMapClosure then do_bit returns bool.)
> 
> The unit tests are written as "early" tests, not requiring an initialized VM.
> They also avoid any C heap allocation (even though C heap allocation has very
> early support). This is done to minimize the requirements for running the
> tests, since BitMap is used in a lot of places. This attempts to run these
> tests before uses. (Yes, I know about JDK-8257226; maybe that will be fixed
> someday.) (Some existing BitMap gtests should be modified to do similarly; see
> JDK-8303636.)
> 
> Testing:
> mach5 tier1-7

Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:

  improve description of iterate

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12876/files
  - new: https://git.openjdk.org/jdk/pull/12876/files/a4f46bdc..a1befdf3

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

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

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

From tschatzl at openjdk.org  Mon Mar  6 10:50:20 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 6 Mar 2023 10:50:20 GMT
Subject: RFR: 8303621: BitMap::iterate should support lambdas and other
 function objects [v2]
In-Reply-To: <CmS2TJp8CqKBnTMA0NAPRTR3InnCUUWsf3ykV-VQWZI=.6af78463-cdc3-4142-b81b-379e43a4ac1f@github.com>
References: <G6DDCDP5PMEOH43G8GNeamEnSMNO_4gMsqQ_zuTUZA8=.1608a894-0707-4d87-b022-e7ee318b69f6@github.com>
 <CmS2TJp8CqKBnTMA0NAPRTR3InnCUUWsf3ykV-VQWZI=.6af78463-cdc3-4142-b81b-379e43a4ac1f@github.com>
Message-ID: <nSLtuRunGIBroFDiuouKsG7HKS8wcm67Ds5RFy7hiZs=.d5893306-e27e-4fd2-bf3a-320dfa3f226a@github.com>

On Mon, 6 Mar 2023 10:33:36 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this enhancement of BitMap::iterate to support lambdas and other
>> function objects as the operation being applied to the set bit indices. Some
>> for-loops using BitMap::get_next_one_offset have been changed to use
>> BitMap::iterate with a lambda.
>> 
>> (One reason for changing the for-loops is that I'm considering a change to the
>> get_next_one_offset API, and reducing the number of direct uses will simplify
>> that.)
>> 
>> For convenience, the function can either return void (always iterate over the
>> whole range) or bool (stop iteration if returns false).  Iteration using
>> closure objects invoked via a do_bit member function are now implemented by
>> being wrapped in a lambda, so get the same convenience.  (Though, of course,
>> if the closure is derived from BitMapClosure then do_bit returns bool.)
>> 
>> The unit tests are written as "early" tests, not requiring an initialized VM.
>> They also avoid any C heap allocation (even though C heap allocation has very
>> early support). This is done to minimize the requirements for running the
>> tests, since BitMap is used in a lot of places. This attempts to run these
>> tests before uses. (Yes, I know about JDK-8257226; maybe that will be fixed
>> someday.) (Some existing BitMap gtests should be modified to do similarly; see
>> JDK-8303636.)
>> 
>> Testing:
>> mach5 tier1-7
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve description of iterate

Still good.

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

Marked as reviewed by tschatzl (Reviewer).

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

From aboldtch at openjdk.org  Mon Mar  6 11:02:10 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 6 Mar 2023 11:02:10 GMT
Subject: RFR: 8303621: BitMap::iterate should support lambdas and other
 function objects [v2]
In-Reply-To: <CmS2TJp8CqKBnTMA0NAPRTR3InnCUUWsf3ykV-VQWZI=.6af78463-cdc3-4142-b81b-379e43a4ac1f@github.com>
References: <G6DDCDP5PMEOH43G8GNeamEnSMNO_4gMsqQ_zuTUZA8=.1608a894-0707-4d87-b022-e7ee318b69f6@github.com>
 <CmS2TJp8CqKBnTMA0NAPRTR3InnCUUWsf3ykV-VQWZI=.6af78463-cdc3-4142-b81b-379e43a4ac1f@github.com>
Message-ID: <xjwpw0XlA4OcU03etXEEaSL34nNwKh87R66yFThYLq4=.6c3bcb29-e200-45ba-a85c-28ba903df731@github.com>

On Mon, 6 Mar 2023 10:33:36 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this enhancement of BitMap::iterate to support lambdas and other
>> function objects as the operation being applied to the set bit indices. Some
>> for-loops using BitMap::get_next_one_offset have been changed to use
>> BitMap::iterate with a lambda.
>> 
>> (One reason for changing the for-loops is that I'm considering a change to the
>> get_next_one_offset API, and reducing the number of direct uses will simplify
>> that.)
>> 
>> For convenience, the function can either return void (always iterate over the
>> whole range) or bool (stop iteration if returns false).  Iteration using
>> closure objects invoked via a do_bit member function are now implemented by
>> being wrapped in a lambda, so get the same convenience.  (Though, of course,
>> if the closure is derived from BitMapClosure then do_bit returns bool.)
>> 
>> The unit tests are written as "early" tests, not requiring an initialized VM.
>> They also avoid any C heap allocation (even though C heap allocation has very
>> early support). This is done to minimize the requirements for running the
>> tests, since BitMap is used in a lot of places. This attempts to run these
>> tests before uses. (Yes, I know about JDK-8257226; maybe that will be fixed
>> someday.) (Some existing BitMap gtests should be modified to do similarly; see
>> JDK-8303636.)
>> 
>> Testing:
>> mach5 tier1-7
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve description of iterate

Marked as reviewed by aboldtch (Committer).

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

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

From stefank at openjdk.org  Mon Mar  6 13:35:22 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 6 Mar 2023 13:35:22 GMT
Subject: RFR: 8292059: Do not inline InstanceKlass::allocate_instance()
 [v2]
In-Reply-To: <8koli6nAbt8Rx4Je8MRic0dPloLTb9IiUyw25BvUI0s=.07267dc7-d2a1-4426-8876-1e41b1a248ac@github.com>
References: <ZSJBTzuC4wVuKdqSLLTgw4Pds2oX5wah0Ub6rFux_tc=.c4e2ae89-cadb-4ccd-9eee-034583cf7200@github.com>
 <8koli6nAbt8Rx4Je8MRic0dPloLTb9IiUyw25BvUI0s=.07267dc7-d2a1-4426-8876-1e41b1a248ac@github.com>
Message-ID: <Q0otxbSu4G0hCzOvBHsIZ4J9kiMyLzdaGHaJwju9054=.1afaae94-15e6-40d6-b244-262420b73633@github.com>

On Fri, 3 Mar 2023 11:53:48 GMT, Afshin Zafari <duke at openjdk.org> wrote:

>> The inline and not-inline versions of the method is stress tested to compare the performance difference. The statistics are drawn in the following charts. The vertical axis is in milliseconds.
>> 
>> ![chart (2)](https://user-images.githubusercontent.com/4697012/221848555-2884313e-9d26-41c9-a265-3f1ce295b17b.png)
>> 
>> ![chart (3)](https://user-images.githubusercontent.com/4697012/221863810-94118677-b4af-468f-90c6-5ea365ae3588.png)
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8292059: Do not inline InstanceKlass::allocate_instance()

There's a lot of changes to includes that needs to be restored / cleaned. I've marked them below:

src/hotspot/share/memory/iterator.inline.hpp line 35:

> 33: #include "oops/compressedOops.inline.hpp"
> 34: #include "oops/klass.hpp"
> 35: #include "utilities/devirtualizer.inline.hpp"

Sort order is wrong.

src/hotspot/share/oops/instanceKlass.inline.hpp line 28:

> 26: #define SHARE_OOPS_INSTANCEKLASS_INLINE_HPP
> 27: 
> 28: #include "oops/instanceKlass.hpp"

All these includes should *not* be removed.

src/hotspot/share/oops/oop.inline.hpp line 36:

> 34: #include "oops/arrayOop.hpp"
> 35: #include "oops/compressedOops.inline.hpp"
> 36: #include "oops/klass.inline.hpp"

Sort order.

src/hotspot/share/prims/jvmtiEnvBase.cpp line 28:

> 26: #include "classfile/classLoaderDataGraph.hpp"
> 27: #include "classfile/javaClasses.inline.hpp"
> 28: #include "classfile/vmSymbols.hpp"

Sort order.

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

Changes requested by stefank (Reviewer).

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

From stefank at openjdk.org  Mon Mar  6 13:39:19 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 6 Mar 2023 13:39:19 GMT
Subject: RFR: 8292059: Do not inline InstanceKlass::allocate_instance()
 [v2]
In-Reply-To: <8koli6nAbt8Rx4Je8MRic0dPloLTb9IiUyw25BvUI0s=.07267dc7-d2a1-4426-8876-1e41b1a248ac@github.com>
References: <ZSJBTzuC4wVuKdqSLLTgw4Pds2oX5wah0Ub6rFux_tc=.c4e2ae89-cadb-4ccd-9eee-034583cf7200@github.com>
 <8koli6nAbt8Rx4Je8MRic0dPloLTb9IiUyw25BvUI0s=.07267dc7-d2a1-4426-8876-1e41b1a248ac@github.com>
Message-ID: <M6-FTQ7djx8MoflW6USJYQt-p7rEuzMgBIB1AKHlFZY=.98bf79d7-4c02-4a8d-9deb-144fc72e98a5@github.com>

On Fri, 3 Mar 2023 11:53:48 GMT, Afshin Zafari <duke at openjdk.org> wrote:

>> The inline and not-inline versions of the method is stress tested to compare the performance difference. The statistics are drawn in the following charts. The vertical axis is in milliseconds.
>> 
>> ![chart (2)](https://user-images.githubusercontent.com/4697012/221848555-2884313e-9d26-41c9-a265-3f1ce295b17b.png)
>> 
>> ![chart (3)](https://user-images.githubusercontent.com/4697012/221863810-94118677-b4af-468f-90c6-5ea365ae3588.png)
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8292059: Do not inline InstanceKlass::allocate_instance()

What is the motivation to change the parameter from `oop java_class` to `InstanceKlass*`? The call sites are now much noisier and harder to read.

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

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

From thomas.stuefe at gmail.com  Mon Mar  6 14:18:56 2023
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 6 Mar 2023 15:18:56 +0100
Subject: alignas and clang
Message-ID: <CAA-vtUxtai4m68sc_hahTXuuzEFxJnRQc3-rjbigKha1LqHYpg@mail.gmail.com>

Hi,

I'm not sure if this has been discussed before. With alignas, on clang, if
the natural type of the data has a larger alignment than what I requested
with alignas, I get a compile error if the specified alignment is smaller
than what would be the natural alignment of the type.

Example:

struct alignas(2) XX {
  void* p;
};

gives: error: requested alignment is less than minimum alignment of 8 for
type 'XX'

Happens on both MacOS and Linux clang build. Does not happen with GCC. Does
not happen with ATTRIBUTE_ALIGN(2).

Is this a clang bug? The standard [1] says:

"The object or the type declared by such a declaration will have its
alignment requirement equal to the strictest (largest) non-zero expression
of all alignas specifiers used in the declaration, unless it would weaken
the natural alignment of the type. "

That reads to me like gcc is correct.

This is a bit of a drawback compared to ATTRIBUTE_ALIGN, especially if
coding for different 32-bit and 64-bit platforms.

[1] https://en.cppreference.com/w/cpp/language/alignas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20230306/1d46cf1d/attachment-0001.htm>

From eosterlund at openjdk.org  Mon Mar  6 15:04:37 2023
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 6 Mar 2023 15:04:37 GMT
Subject: RFR: 8296469: Instrument VMError::report with reentrant iteration
 step for register and stack printing [v9]
In-Reply-To: <faDgjMse2Qwb7_8iLAq1j-h7Hwqt28vQJMbIjhTSuAM=.4d8095b3-aa6f-4190-8806-4edb7e37a256@github.com>
References: <s2wlyE6OjqTazCsro-keOXqXvYMqwHEp8YdMZhCdQXs=.37245c9a-5891-42b8-b961-55d1a7a30af5@github.com>
 <faDgjMse2Qwb7_8iLAq1j-h7Hwqt28vQJMbIjhTSuAM=.4d8095b3-aa6f-4190-8806-4edb7e37a256@github.com>
Message-ID: <5La1Nl4tQg06WqJWG4Tou6QoEXdnS8l_YTddxJbYHyE=.89395bb9-1570-4bc0-98e9-355da8412c89@github.com>

On Mon, 20 Feb 2023 07:15:23 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 with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Merge remote-tracking branch 'upstream_jdk/master' into vmerror_report_register_stack_reentrant
>  - Add test
>  - Fix and strengthen print_stack_location
>  - Missed variable rename
>  - Copyright
>  - Rework logic and use continuation state for reattempts
>  - Merge remote-tracking branch 'upstream_jdk/master' into vmerror_report_register_stack_reentrant
>  - Restructure os::print_register_info interface
>  - Code syle and line length
>  - Merge Fix
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/2009dc2b...2e12b4a5

Just a naming nit, otherwise it looks good.

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

> 173: static bool check_stack_headroom(Thread* thread,
> 174:                                  size_t headroom) {
> 175:   static const address stack_top    = thread != nullptr

We typically call "stack_top "stack_base", and "stack_bottom" we call "stack_end".

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

Marked as reviewed by eosterlund (Reviewer).

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

From tanksherman27 at gmail.com  Mon Mar  6 15:22:17 2023
From: tanksherman27 at gmail.com (Julian Waters)
Date: Mon, 6 Mar 2023 23:22:17 +0800
Subject: alignas and clang
In-Reply-To: <CAA-vtUxtai4m68sc_hahTXuuzEFxJnRQc3-rjbigKha1LqHYpg@mail.gmail.com>
References: <CAA-vtUxtai4m68sc_hahTXuuzEFxJnRQc3-rjbigKha1LqHYpg@mail.gmail.com>
Message-ID: <CAP2b4GNe86xXM+-BKOzTgb89Tngmo2-O4cU7Jt+EQqvnu_XM6g@mail.gmail.com>

Hi Thomas,

>From what I know gcc is actually the one that's not correct here, a bigger
alignment is considered stricter in C++ (though the Standard really should
make this much clearer) since a lower alignment value results in more
possible addresses, hence making the type's alignment weaker, and alignas
is very explicitly forbidden from weakening alignment, especially the
regular (unmodified) minimum alignment of said type. I don't know if there
are places where we purposely weaken type alignment in HotSpot though

best regards,
Julian

On Mon, Mar 6, 2023 at 10:19?PM Thomas St?fe <thomas.stuefe at gmail.com>
wrote:

> Hi,
>
> I'm not sure if this has been discussed before. With alignas, on clang, if
> the natural type of the data has a larger alignment than what I requested
> with alignas, I get a compile error if the specified alignment is smaller
> than what would be the natural alignment of the type.
>
> Example:
>
> struct alignas(2) XX {
>   void* p;
> };
>
> gives: error: requested alignment is less than minimum alignment of 8 for
> type 'XX'
>
> Happens on both MacOS and Linux clang build. Does not happen with GCC.
> Does not happen with ATTRIBUTE_ALIGN(2).
>
> Is this a clang bug? The standard [1] says:
>
> "The object or the type declared by such a declaration will have its
> alignment requirement equal to the strictest (largest) non-zero expression
> of all alignas specifiers used in the declaration, unless it would weaken
> the natural alignment of the type. "
>
> That reads to me like gcc is correct.
>
> This is a bit of a drawback compared to ATTRIBUTE_ALIGN, especially if
> coding for different 32-bit and 64-bit platforms.
>
> [1] https://en.cppreference.com/w/cpp/language/alignas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20230306/4d0b347d/attachment.htm>

From thomas.stuefe at gmail.com  Mon Mar  6 15:52:39 2023
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 6 Mar 2023 16:52:39 +0100
Subject: alignas and clang
In-Reply-To: <CAP2b4GNe86xXM+-BKOzTgb89Tngmo2-O4cU7Jt+EQqvnu_XM6g@mail.gmail.com>
References: <CAA-vtUxtai4m68sc_hahTXuuzEFxJnRQc3-rjbigKha1LqHYpg@mail.gmail.com>
 <CAP2b4GNe86xXM+-BKOzTgb89Tngmo2-O4cU7Jt+EQqvnu_XM6g@mail.gmail.com>
Message-ID: <CAA-vtUyGJjuz5Aj=ApBAAGxb=-mtMFKUOecPgpWt4G5HcsaFTQ@mail.gmail.com>

Hi Julian,

On Mon, Mar 6, 2023 at 4:22?PM Julian Waters <tanksherman27 at gmail.com>
wrote:

> Hi Thomas,
>
> From what I know gcc is actually the one that's not correct here, a bigger
> alignment is considered stricter in C++ (though the Standard really should
> make this much clearer) since a lower alignment value results in more
> possible addresses, hence making the type's alignment weaker, and alignas
> is very explicitly forbidden from weakening alignment, especially the
> regular (unmodified) minimum alignment of said type.
>

gcc does not weaken the alignment, though. It just chooses whatever is
larger: natural or explicitly given alignment. So it behaves to spec,
provided I understand the spec.

I don't know if there are places where we purposely weaken type alignment
> in HotSpot though
>

Not weaken, and not purposefully. But the specified alignment may be
smaller than the natural one, and the natural (hah) thing to do would be to
choose whatever's larger.

For example, from https://github.com/openjdk/jdk/pull/12879:

template <class T> struct MyContainer {
  union alignas(alignof(T)) DataHolder {
    char bytes[sizeof(T)];
    void* p;
  };
  DataHolder d;
};

So, I want the compiler to allocate storage aligned for T, but postpone the
actual construction of T. I also want to keep the thing in a freelist,
hence the next pointer (here its a union, but that does not matter for the
problem).

For T=int, on 64-bit, I would have expected the compiler to generate
DataHolder with an alignment requirement of 8 since T needs 4 and void*
needs 8. But the compiler does not accept this. However, clang accepts
ATTRIBUTE_ALIGNED and then does what gcc does.

Cheers, Thomas


> best regards,
> Julian
>
> On Mon, Mar 6, 2023 at 10:19?PM Thomas St?fe <thomas.stuefe at gmail.com>
> wrote:
>
>> Hi,
>>
>> I'm not sure if this has been discussed before. With alignas, on clang,
>> if the natural type of the data has a larger alignment than what I
>> requested with alignas, I get a compile error if the specified alignment is
>> smaller than what would be the natural alignment of the type.
>>
>> Example:
>>
>> struct alignas(2) XX {
>>   void* p;
>> };
>>
>> gives: error: requested alignment is less than minimum alignment of 8 for
>> type 'XX'
>>
>> Happens on both MacOS and Linux clang build. Does not happen with GCC.
>> Does not happen with ATTRIBUTE_ALIGN(2).
>>
>> Is this a clang bug? The standard [1] says:
>>
>> "The object or the type declared by such a declaration will have its
>> alignment requirement equal to the strictest (largest) non-zero expression
>> of all alignas specifiers used in the declaration, unless it would weaken
>> the natural alignment of the type. "
>>
>> That reads to me like gcc is correct.
>>
>> This is a bit of a drawback compared to ATTRIBUTE_ALIGN, especially if
>> coding for different 32-bit and 64-bit platforms.
>>
>> [1] https://en.cppreference.com/w/cpp/language/alignas
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20230306/8d1cdfc4/attachment-0001.htm>

From never at openjdk.org  Mon Mar  6 16:13:47 2023
From: never at openjdk.org (Tom Rodriguez)
Date: Mon, 6 Mar 2023 16:13:47 GMT
Subject: RFR: 8303577: [JVMCI] OOME causes crash while translating
 exceptions
In-Reply-To: <tP7cn6cW3NkzhXP1WfAhFTq3p2GfMMI3lzmZBYNNEh0=.30ca6b53-1cff-416a-8035-76569787c008@github.com>
References: <tP7cn6cW3NkzhXP1WfAhFTq3p2GfMMI3lzmZBYNNEh0=.30ca6b53-1cff-416a-8035-76569787c008@github.com>
Message-ID: <S8PCn5vJ8-HuWHD-8wWz1UlgbX90uykXyGrebEMWrYo=.2761280e-1fda-4f35-b426-fe9f43b5f15f@github.com>

On Fri, 3 Mar 2023 15:40:01 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> JDK-8297431 added code for special handling of OutOfMemoryError when translating an exception between libjvmci and HotSpot[1].
> Unfortunately, this code was deleted by JDK-8298099 when moving the exception translation mechanism to VMSupport[2].
> This causes the VM to crash when an OOME occurs while translating an exception from HotSpot to libjvmci.
> This PR revives the deleted code.
> 
> This bug was found by running `test/jdk/java/util/concurrent/locks/Lock/OOMEInAQS.java` on libgraal. The fix now makes the test pass.
> 
> Note that the code modified in `src/java.base/share/classes/jdk/internal/vm/VMSupport.java` is JVMCI specific and was original added by [JDK-8298099](https://git.openjdk.org/jdk/pull/11513).
> 
> [1] https://github.com/openjdk/jdk/commit/952e10055135613e8ea2b818a4f35842936f5633#diff-4d3a3b7e7e12e1d5b4cf3e4677d9e0de5e9df3bbf1bbfa0d8d43d12098d67dc4R222-R234
> [2] https://github.com/openjdk/jdk/commit/8b69a2e434ad2fa3369079622b57afb973d5bd9a#diff-7292551772c27b7152a3333f03cbbad90a897c5e37c6a97d4026be835e6d8fe1R121-R125

Marked as reviewed by never (Reviewer).

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

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

From dnsimon at openjdk.org  Mon Mar  6 16:14:01 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 6 Mar 2023 16:14:01 GMT
Subject: RFR: 8303577: [JVMCI] OOME causes crash while translating
 exceptions
In-Reply-To: <kHlMq4QljW_Y61Loe934e4rwB7e2lwJwTFj4arrUOqM=.719fbdd2-2204-4508-84f6-123739e4b457@github.com>
References: <tP7cn6cW3NkzhXP1WfAhFTq3p2GfMMI3lzmZBYNNEh0=.30ca6b53-1cff-416a-8035-76569787c008@github.com>
 <kHlMq4QljW_Y61Loe934e4rwB7e2lwJwTFj4arrUOqM=.719fbdd2-2204-4508-84f6-123739e4b457@github.com>
Message-ID: <ZjS0e55uuHguT6Q8TvM3GsIGlBWky9ngxqNNs_-9uWs=.6b88acc2-ff50-40d4-bceb-d3511eeaac4f@github.com>

On Fri, 3 Mar 2023 18:05:51 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> JDK-8297431 added code for special handling of OutOfMemoryError when translating an exception between libjvmci and HotSpot[1].
>> Unfortunately, this code was deleted by JDK-8298099 when moving the exception translation mechanism to VMSupport[2].
>> This causes the VM to crash when an OOME occurs while translating an exception from HotSpot to libjvmci.
>> This PR revives the deleted code.
>> 
>> This bug was found by running `test/jdk/java/util/concurrent/locks/Lock/OOMEInAQS.java` on libgraal. The fix now makes the test pass.
>> 
>> Note that the code modified in `src/java.base/share/classes/jdk/internal/vm/VMSupport.java` is JVMCI specific and was original added by [JDK-8298099](https://git.openjdk.org/jdk/pull/11513).
>> 
>> [1] https://github.com/openjdk/jdk/commit/952e10055135613e8ea2b818a4f35842936f5633#diff-4d3a3b7e7e12e1d5b4cf3e4677d9e0de5e9df3bbf1bbfa0d8d43d12098d67dc4R222-R234
>> [2] https://github.com/openjdk/jdk/commit/8b69a2e434ad2fa3369079622b57afb973d5bd9a#diff-7292551772c27b7152a3333f03cbbad90a897c5e37c6a97d4026be835e6d8fe1R121-R125
>
> Good.

Thanks for the reviews @vnkozlov and @tkrodriguez .

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

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

From dnsimon at openjdk.org  Mon Mar  6 16:14:02 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 6 Mar 2023 16:14:02 GMT
Subject: Integrated: 8303577: [JVMCI] OOME causes crash while translating
 exceptions
In-Reply-To: <tP7cn6cW3NkzhXP1WfAhFTq3p2GfMMI3lzmZBYNNEh0=.30ca6b53-1cff-416a-8035-76569787c008@github.com>
References: <tP7cn6cW3NkzhXP1WfAhFTq3p2GfMMI3lzmZBYNNEh0=.30ca6b53-1cff-416a-8035-76569787c008@github.com>
Message-ID: <RUezeDUpKVYd8Fh0I6T0X_wIMqGNd1L0QBsLSNZ01lA=.a090ad8b-d691-4deb-a89e-3001cc01655c@github.com>

On Fri, 3 Mar 2023 15:40:01 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> JDK-8297431 added code for special handling of OutOfMemoryError when translating an exception between libjvmci and HotSpot[1].
> Unfortunately, this code was deleted by JDK-8298099 when moving the exception translation mechanism to VMSupport[2].
> This causes the VM to crash when an OOME occurs while translating an exception from HotSpot to libjvmci.
> This PR revives the deleted code.
> 
> This bug was found by running `test/jdk/java/util/concurrent/locks/Lock/OOMEInAQS.java` on libgraal. The fix now makes the test pass.
> 
> Note that the code modified in `src/java.base/share/classes/jdk/internal/vm/VMSupport.java` is JVMCI specific and was original added by [JDK-8298099](https://git.openjdk.org/jdk/pull/11513).
> 
> [1] https://github.com/openjdk/jdk/commit/952e10055135613e8ea2b818a4f35842936f5633#diff-4d3a3b7e7e12e1d5b4cf3e4677d9e0de5e9df3bbf1bbfa0d8d43d12098d67dc4R222-R234
> [2] https://github.com/openjdk/jdk/commit/8b69a2e434ad2fa3369079622b57afb973d5bd9a#diff-7292551772c27b7152a3333f03cbbad90a897c5e37c6a97d4026be835e6d8fe1R121-R125

This pull request has now been integrated.

Changeset: cac81ddc
Author:    Doug Simon <dnsimon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cac81ddc9259168a5b12c290ae2ce7db25a729fc
Stats:     31 lines in 5 files changed: 22 ins; 0 del; 9 mod

8303577: [JVMCI] OOME causes crash while translating exceptions

Reviewed-by: kvn, never

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

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

From tanksherman27 at gmail.com  Mon Mar  6 16:22:29 2023
From: tanksherman27 at gmail.com (Julian Waters)
Date: Tue, 7 Mar 2023 00:22:29 +0800
Subject: alignas and clang
In-Reply-To: <CAA-vtUyGJjuz5Aj=ApBAAGxb=-mtMFKUOecPgpWt4G5HcsaFTQ@mail.gmail.com>
References: <CAA-vtUxtai4m68sc_hahTXuuzEFxJnRQc3-rjbigKha1LqHYpg@mail.gmail.com>
 <CAP2b4GNe86xXM+-BKOzTgb89Tngmo2-O4cU7Jt+EQqvnu_XM6g@mail.gmail.com>
 <CAA-vtUyGJjuz5Aj=ApBAAGxb=-mtMFKUOecPgpWt4G5HcsaFTQ@mail.gmail.com>
Message-ID: <CAP2b4GOg1gX2bg=G18h9Z9svL7M9+gPX46b4TVxH=4iX=DgR5Q@mail.gmail.com>

Ahhh, I see what you mean. Seems to me that this may actually be compiler
dependent, since C++14 simply states such situations are ill-formed and
makes no promises of instead choosing the larger alignment when
this happens. Does seem to be pretty annoying in that case :(

Love that pun though, on another note :P

best regards,
Julian

On Mon, Mar 6, 2023 at 11:52?PM Thomas St?fe <thomas.stuefe at gmail.com>
wrote:

> Hi Julian,
>
> On Mon, Mar 6, 2023 at 4:22?PM Julian Waters <tanksherman27 at gmail.com>
> wrote:
>
>> Hi Thomas,
>>
>> From what I know gcc is actually the one that's not correct here, a
>> bigger alignment is considered stricter in C++ (though the Standard really
>> should make this much clearer) since a lower alignment value results in
>> more possible addresses, hence making the type's alignment weaker, and
>> alignas is very explicitly forbidden from weakening alignment, especially
>> the regular (unmodified) minimum alignment of said type.
>>
>
> gcc does not weaken the alignment, though. It just chooses whatever is
> larger: natural or explicitly given alignment. So it behaves to spec,
> provided I understand the spec.
>
> I don't know if there are places where we purposely weaken type alignment
>> in HotSpot though
>>
>
> Not weaken, and not purposefully. But the specified alignment may be
> smaller than the natural one, and the natural (hah) thing to do would be to
> choose whatever's larger.
>
> For example, from https://github.com/openjdk/jdk/pull/12879:
>
> template <class T> struct MyContainer {
>   union alignas(alignof(T)) DataHolder {
>     char bytes[sizeof(T)];
>     void* p;
>   };
>   DataHolder d;
> };
>
> So, I want the compiler to allocate storage aligned for T, but postpone
> the actual construction of T. I also want to keep the thing in a freelist,
> hence the next pointer (here its a union, but that does not matter for the
> problem).
>
> For T=int, on 64-bit, I would have expected the compiler to generate
> DataHolder with an alignment requirement of 8 since T needs 4 and void*
> needs 8. But the compiler does not accept this. However, clang accepts
> ATTRIBUTE_ALIGNED and then does what gcc does.
>
> Cheers, Thomas
>
>
>> best regards,
>> Julian
>>
>> On Mon, Mar 6, 2023 at 10:19?PM Thomas St?fe <thomas.stuefe at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I'm not sure if this has been discussed before. With alignas, on clang,
>>> if the natural type of the data has a larger alignment than what I
>>> requested with alignas, I get a compile error if the specified alignment is
>>> smaller than what would be the natural alignment of the type.
>>>
>>> Example:
>>>
>>> struct alignas(2) XX {
>>>   void* p;
>>> };
>>>
>>> gives: error: requested alignment is less than minimum alignment of 8
>>> for type 'XX'
>>>
>>> Happens on both MacOS and Linux clang build. Does not happen with GCC.
>>> Does not happen with ATTRIBUTE_ALIGN(2).
>>>
>>> Is this a clang bug? The standard [1] says:
>>>
>>> "The object or the type declared by such a declaration will have its
>>> alignment requirement equal to the strictest (largest) non-zero expression
>>> of all alignas specifiers used in the declaration, unless it would weaken
>>> the natural alignment of the type. "
>>>
>>> That reads to me like gcc is correct.
>>>
>>> This is a bit of a drawback compared to ATTRIBUTE_ALIGN, especially if
>>> coding for different 32-bit and 64-bit platforms.
>>>
>>> [1] https://en.cppreference.com/w/cpp/language/alignas
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20230307/a6c61fcd/attachment-0001.htm>

From jcking at openjdk.org  Mon Mar  6 16:30:33 2023
From: jcking at openjdk.org (Justin King)
Date: Mon, 6 Mar 2023 16:30:33 GMT
Subject: RFR: JDK-8300783: Consolidate byteswap implementations [v8]
In-Reply-To: <4T6ba7HVAkPmaau2WD3FRRyOlmEz7MDX5nz2UM-rfms=.58f59fc2-6030-4d9f-914f-5f37df4fb95e@github.com>
References: <MLBMwI7xt4IKgpb3AHXJ_J11Ibhijp_q2RFtLJOwHpA=.b7da6b6b-69b8-426d-8eab-c7c3aaa0847e@github.com>
 <v9HNX5mxr8cyTkf-Go6M62giQnF2ltlOnX36VwxfAn4=.3e2b489f-0dbb-4f7b-a685-9a32748847b2@github.com>
 <4T6ba7HVAkPmaau2WD3FRRyOlmEz7MDX5nz2UM-rfms=.58f59fc2-6030-4d9f-914f-5f37df4fb95e@github.com>
Message-ID: <XN9WbwkPShg_FCuesZ5vg4qkI-4J0tJA80Iz753HtWo=.e3c8cc91-6329-4aba-b038-d5d7b81c8661@github.com>

On Wed, 25 Jan 2023 12:31:11 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 comment
>>   
>>   Signed-off-by: Justin King <jcking at google.com>
>
> CI run was fine wrt these changes.

@dholmes-ora Poke. :)

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

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

From jvernee at openjdk.org  Mon Mar  6 16:42:10 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 6 Mar 2023 16:42:10 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v3]
In-Reply-To: <QMh_faUf_LLUf68WrZiFxmPHiFcHDBfKDg3g-oekBeg=.096acd06-65c4-4357-ad4a-4089b5478fff@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com>
 <HT8kQfjS98dYHeAMcNL5latokRiw3YK8npxl5yCD4hw=.28b19bac-cbfa-4461-a1db-c899c55b7485@github.com>
 <wBVqRDFM23KM8fjjPtUFNdW56FYsSpvOAVvHmpdjbzo=.7c429606-ac19-4f36-8e25-459534983924@github.com>
 <QMh_faUf_LLUf68WrZiFxmPHiFcHDBfKDg3g-oekBeg=.096acd06-65c4-4357-ad4a-4089b5478fff@github.com>
Message-ID: <hJkc1ozy4f7BIvXZ_xQ3HRttVsBs0ceUIMmq4cDWrzQ=.bc3223f5-cb33-46c7-9708-ab40ba5943b0@github.com>

On Wed, 1 Mar 2023 06:37:45 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>>>     * Uploaded my simple reproducer to [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
>> 
>> Thanks!
>> 
>>>     * Using oversized load / stores is problematic. Don't forget that OpenJDK still supports Big Endian platforms (AIX, s390x).
>> 
>> You're right. I realized that it's also problematic for heap segments, for which we can't do oversized accesses. I am working on another solution that splits up the loads/stores into power-of-two sized chunks: https://github.com/openjdk/panama-foreign/compare/foreign-memaccess+abi...JornVernee:panama-foreign:OOB That patch is just a POC at this point though. Also, I don't think it works for BE at the moment (need to flip the offset for BE, I think. Just like we do in Unsafe).
>> 
>>>     * The result of `NativeCallingConvention::calling_convention` is interpreted as size, but it returns the max offset. That's off by one slot. Should I file a bug for that? (PPC64 is not affected because it doesn't use the result.)
>> 
>> I'm not sure there's an issue there. Note that the 'max offset' is computed as `reg.offset() + reg.stack_size()`, so that should get us the size we need to allocate for the stack arguments. (e.g. 2 ints being passed at offset 0 and 4, would make max offset 4 + 4 = 8, which gives the size needed for the 2 ints). Computing the max offset instead of just summing the sizes of the stack arguments is needed since stack arguments can be sparsely placed in some cases on Mac/AArch64.
>> 
>>>     * Since the membar on the return path was mentioned: I think it would be good to enable UseSystemMemoryBarrier by default on operating systems which support it. Maybe we should discuss this with @robehn.
>> 
>> ~I don't think we've done that much testing with UseSystemMemoryBarrier since it was added~. I'm a bit nervous about turning it on by default since it's currently also used for JNI. Let's see what Robbin thinks.
>
> @JornVernee: Thanks a lot for your detailed review! I have quite a few TODOs which include:
> - Include my tests for the HFA corner cases.
> - Try to improve handling of the overlapping registers as you suggested.
> - Check nesting of HFA.
> 
> There will surely be more when looking into Big Endian support after merging with your recent work on https://github.com/openjdk/panama-foreign/compare/foreign-memaccess+abi...JornVernee:panama-foreign:OOB
> We should get rid of oversized accesses on PPC64, too.
> Thanks for sharing your plans to intrisify `linkToNative` in C2 later. I guess we should do more preparation work on all platforms when that gets addressed.

@TheRealMDoerr I've moved the support for structs/unions that are not a power of 2 in size to this repo, so you should be able to merge the master branch to get it now.

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

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

From fparain at openjdk.org  Mon Mar  6 16:47:39 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 6 Mar 2023 16:47:39 GMT
Subject: RFR: 8292818: replace 96-bit representation for field metadata with
 variable-sized streams
Message-ID: <vdiacOO3JUyy4sWGkDXNBMUT7cG3XYe79mOvYru9uMM=.9c556675-7ffd-4c09-a428-6d64dffef209@github.com>

Please review this change re-implementing the FieldInfo data structure.

The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of stong typing and semantic overloading, and a poor memory efficiency.

The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information).

More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818

Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM.

The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format.

Tested with mach5, tier 1 to 7.

Thank you.

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

Commit messages:
 - Merge remote-tracking branch 'upstream/master' into fieldinfo_unsigned5
 - Reimplementation of FieldInfo as an unsigned5 stream

Changes: https://git.openjdk.org/jdk/pull/12855/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12855&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292818
  Stats: 1699 lines in 52 files changed: 897 ins; 446 del; 356 mod
  Patch: https://git.openjdk.org/jdk/pull/12855.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12855/head:pull/12855

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

From thomas.stuefe at gmail.com  Mon Mar  6 17:58:55 2023
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 6 Mar 2023 18:58:55 +0100
Subject: alignas and clang
In-Reply-To: <CAP2b4GOg1gX2bg=G18h9Z9svL7M9+gPX46b4TVxH=4iX=DgR5Q@mail.gmail.com>
References: <CAA-vtUxtai4m68sc_hahTXuuzEFxJnRQc3-rjbigKha1LqHYpg@mail.gmail.com>
 <CAP2b4GNe86xXM+-BKOzTgb89Tngmo2-O4cU7Jt+EQqvnu_XM6g@mail.gmail.com>
 <CAA-vtUyGJjuz5Aj=ApBAAGxb=-mtMFKUOecPgpWt4G5HcsaFTQ@mail.gmail.com>
 <CAP2b4GOg1gX2bg=G18h9Z9svL7M9+gPX46b4TVxH=4iX=DgR5Q@mail.gmail.com>
Message-ID: <CAA-vtUwZB9ATLEY4OvJODzQFTDxbaT+dEOweP1wbX_=LwmD6nA@mail.gmail.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
On Mon, Mar 6, 2023 at 5:23?PM Julian Waters <tanksherman27 at gmail.com>
wrote:

> Ahhh, I see what you mean. Seems to me that this may actually be compiler
> dependent, since C++14 simply states such situations are ill-formed and
> makes no promises of instead choosing the larger alignment when
> this happens.
>

Oh, you are right, I stopped reading before it got interesting.

"If the strictest (largest) alignas on a declaration is weaker than the
alignment it would have without any alignas specifiers (that is, weaker
than its natural alignment or weaker than alignas on another declaration of
the same object or type), the program is ill-formed."

Never mind then, I'll find a different solution.

Thanks for thinking this through with me!

Cheers,  Thomas

Does seem to be pretty annoying in that case :(
>
> Love that pun though, on another note :P
>
> best regards,
> Julian
>
> On Mon, Mar 6, 2023 at 11:52?PM Thomas St?fe <thomas.stuefe at gmail.com>
> wrote:
>
>> Hi Julian,
>>
>> On Mon, Mar 6, 2023 at 4:22?PM Julian Waters <tanksherman27 at gmail.com>
>> wrote:
>>
>>> Hi Thomas,
>>>
>>> From what I know gcc is actually the one that's not correct here, a
>>> bigger alignment is considered stricter in C++ (though the Standard really
>>> should make this much clearer) since a lower alignment value results in
>>> more possible addresses, hence making the type's alignment weaker, and
>>> alignas is very explicitly forbidden from weakening alignment, especially
>>> the regular (unmodified) minimum alignment of said type.
>>>
>>
>> gcc does not weaken the alignment, though. It just chooses whatever is
>> larger: natural or explicitly given alignment. So it behaves to spec,
>> provided I understand the spec.
>>
>> I don't know if there are places where we purposely weaken type alignment
>>> in HotSpot though
>>>
>>
>> Not weaken, and not purposefully. But the specified alignment may be
>> smaller than the natural one, and the natural (hah) thing to do would be to
>> choose whatever's larger.
>>
>> For example, from https://github.com/openjdk/jdk/pull/12879:
>>
>> template <class T> struct MyContainer {
>>   union alignas(alignof(T)) DataHolder {
>>     char bytes[sizeof(T)];
>>     void* p;
>>   };
>>   DataHolder d;
>> };
>>
>> So, I want the compiler to allocate storage aligned for T, but postpone
>> the actual construction of T. I also want to keep the thing in a freelist,
>> hence the next pointer (here its a union, but that does not matter for the
>> problem).
>>
>> For T=int, on 64-bit, I would have expected the compiler to generate
>> DataHolder with an alignment requirement of 8 since T needs 4 and void*
>> needs 8. But the compiler does not accept this. However, clang accepts
>> ATTRIBUTE_ALIGNED and then does what gcc does.
>>
>> Cheers, Thomas
>>
>>
>>> best regards,
>>> Julian
>>>
>>> On Mon, Mar 6, 2023 at 10:19?PM Thomas St?fe <thomas.stuefe at gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm not sure if this has been discussed before. With alignas, on clang,
>>>> if the natural type of the data has a larger alignment than what I
>>>> requested with alignas, I get a compile error if the specified alignment is
>>>> smaller than what would be the natural alignment of the type.
>>>>
>>>> Example:
>>>>
>>>> struct alignas(2) XX {
>>>>   void* p;
>>>> };
>>>>
>>>> gives: error: requested alignment is less than minimum alignment of 8
>>>> for type 'XX'
>>>>
>>>> Happens on both MacOS and Linux clang build. Does not happen with GCC.
>>>> Does not happen with ATTRIBUTE_ALIGN(2).
>>>>
>>>> Is this a clang bug? The standard [1] says:
>>>>
>>>> "The object or the type declared by such a declaration will have its
>>>> alignment requirement equal to the strictest (largest) non-zero expression
>>>> of all alignas specifiers used in the declaration, unless it would weaken
>>>> the natural alignment of the type. "
>>>>
>>>> That reads to me like gcc is correct.
>>>>
>>>> This is a bit of a drawback compared to ATTRIBUTE_ALIGN, especially if
>>>> coding for different 32-bit and 64-bit platforms.
>>>>
>>>> [1] https://en.cppreference.com/w/cpp/language/alignas
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20230306/ec45bb46/attachment-0001.htm>

From prappo at openjdk.org  Mon Mar  6 20:22:48 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 6 Mar 2023 20:22:48 GMT
Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments
 [v2]
In-Reply-To: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
Message-ID: <cwRZFQxyddrtPWS__nVK0l1Lu-dL3lnlR3rODiLfncA=.2f5b214e-9ae7-492a-b09a-81ef4077a26e@github.com>

> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
> 
> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
> 
> 
>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>     @@ -17084,7 +17084,7 @@
>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>      <div class="block"><code>readObject</code> is called to restore the state of the
>     - (@code BasicPermission} from a stream.</div>
>     + <code>BasicPermission</code> from a stream.</div>
>      <dl class="notes">
>      <dt>Parameters:</dt>
>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
> 
> Notes
> -----
> 
> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
> * I will update copyright years after (and if) the fix had been approved, as required.

Pavel Rappo 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 8303480
 - Initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12826/files
  - new: https://git.openjdk.org/jdk/pull/12826/files/d2f4a553..87166408

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

  Stats: 13433 lines in 415 files changed: 9003 ins; 2610 del; 1820 mod
  Patch: https://git.openjdk.org/jdk/pull/12826.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12826/head:pull/12826

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

From inakonechnyy at openjdk.org  Mon Mar  6 20:28:40 2023
From: inakonechnyy at openjdk.org (Ilarion Nakonechnyy)
Date: Mon, 6 Mar 2023 20:28:40 GMT
Subject: RFR: 8302491: NoClassDefFoundError omits the original cause of an
 error [v5]
In-Reply-To: <L-pfBfK4TKl5KUWpPEcbs-IkhwimgJZ-SOrbSG3exeA=.5e883f22-de9b-4eec-9e98-8ee954a7996b@github.com>
References: <L-pfBfK4TKl5KUWpPEcbs-IkhwimgJZ-SOrbSG3exeA=.5e883f22-de9b-4eec-9e98-8ee954a7996b@github.com>
Message-ID: <0UEtpYm8TvljAdj3FQI5LYfjHxXPBWBfFD0lDsLojJA=.d259d5df-24b8-4b93-8fb3-feafc696deab@github.com>

> The proposed approach added a new function for getting the cause of an exception -`java_lang_Throwable::get_cause_simple `, that gets called within `InstanceKlass::add_initialization_error`  if an old one `java_lang_Throwable::get_cause_with_stack_trace` didn't succeed because of an exception during the VM call. The simple function doesn't call the VM for getting a stack trace but fills in any other information about an exception.
> 
> Besides that, the discovering information about an exception was added to `ConstantPoolCacheEntry::save_and_throw_indy_exc` function. 
> 
> Jtreg for reproducing the issue also was added to the commit. 
> The commit was tested with tier1 tests.

Ilarion Nakonechnyy has updated the pull request incrementally with one additional commit since the last revision:

  1/ create_initialization_error(): return empty exception, if
  EIIE creation failed.
  2/ remove testcase

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12566/files
  - new: https://git.openjdk.org/jdk/pull/12566/files/5c9c1ffe..adf139fa

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

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

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

From jjg at openjdk.org  Mon Mar  6 20:31:18 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 6 Mar 2023 20:31:18 GMT
Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments
 [v2]
In-Reply-To: <GIf5QraCfE1MexPnWsXUMEWFPYoWpu-80I1N7bB6ffk=.728f82a3-fe8f-40d3-8dbd-c6a9fa5e031a@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
 <zGeNBZ-3vU9GABEYOeUorRTJAMzyQzN-97Rx6qKisaY=.87335367-efc7-4c48-b866-de39a9d9c9e2@github.com>
 <Bzi35xfPH43Jupv65o86ErKvkPYaJdNV7cDIX7BBorc=.34e6522f-ec1e-41ee-b254-32713288bc79@github.com>
 <-U8YFFuXm_hMf-bY1AVCRauRrE-fRYRxrx_yf38ZL1A=.d50884c5-cc4b-489a-b817-828faf876c76@github.com>
 <GIf5QraCfE1MexPnWsXUMEWFPYoWpu-80I1N7bB6ffk=.728f82a3-fe8f-40d3-8dbd-c6a9fa5e031a@github.com>
Message-ID: <ZXfrODW3U49MwVjsf7erqcN1x3lsi5dyU5SSaETKruY=.616faeb3-663f-4191-8bec-8fc0c9eba48d@github.com>

On Fri, 3 Mar 2023 11:31:04 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Yes, iff means if-and-only-if and is used for extra precision in formal logic, mathematics. As @pavelrappo points out it's a relatively common occurrence in the OpenJDK sources, though perhaps not in the public javadocs. Perhaps a bit pretentious, but mostly a terse way to say "return true if the BSM method type exactly matches X, otherwise false".
>> 
>> The broken link stems from the fact that the method I was targeting (a way to use condy for lambda proxy singletons rather than a `MethodHandle.constant`) was never integrated. We'll look at either getting that done (@briangoetz suggested the time might be ready for it) or remove this currently pointless static bootstrap specialization test.
>
>> Yes, iff means if-and-only-if and is used for extra precision in formal logic, mathematics.
> 
> I've never come across it before. With your explanations, it makes perfect sense.

I would recommend (separately) changing `iff` to the expanded form `if and only if`

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

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

From jjg at openjdk.org  Mon Mar  6 20:36:13 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 6 Mar 2023 20:36:13 GMT
Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments
 [v2]
In-Reply-To: <cwRZFQxyddrtPWS__nVK0l1Lu-dL3lnlR3rODiLfncA=.2f5b214e-9ae7-492a-b09a-81ef4077a26e@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
 <cwRZFQxyddrtPWS__nVK0l1Lu-dL3lnlR3rODiLfncA=.2f5b214e-9ae7-492a-b09a-81ef4077a26e@github.com>
Message-ID: <ztCzFqlAYLpzLdZY0K_GgKPNNOvqF9FNTbDh5ZEg-lk=.3aa6a92b-a286-4760-bdc4-425f48e53a6f@github.com>

On Mon, 6 Mar 2023 20:22:48 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
>> 
>> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
>> 
>> 
>>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>>     @@ -17084,7 +17084,7 @@
>>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>>      <div class="block"><code>readObject</code> is called to restore the state of the
>>     - (@code BasicPermission} from a stream.</div>
>>     + <code>BasicPermission</code> from a stream.</div>
>>      <dl class="notes">
>>      <dt>Parameters:</dt>
>>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
>> 
>> Notes
>> -----
>> 
>> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
>> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
>> * I will update copyright years after (and if) the fix had been approved, as required.
>
> Pavel Rappo 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 8303480
>  - Initial commit

Marked as reviewed by jjg (Reviewer).

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

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

From lancea at openjdk.org  Mon Mar  6 20:39:17 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 6 Mar 2023 20:39:17 GMT
Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments
 [v2]
In-Reply-To: <cwRZFQxyddrtPWS__nVK0l1Lu-dL3lnlR3rODiLfncA=.2f5b214e-9ae7-492a-b09a-81ef4077a26e@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
 <cwRZFQxyddrtPWS__nVK0l1Lu-dL3lnlR3rODiLfncA=.2f5b214e-9ae7-492a-b09a-81ef4077a26e@github.com>
Message-ID: <RWgaYiwcqLzeKKbnHxAAnPlwk1ndum8VkwVOnvJAbMM=.e0a4507f-dd64-41c8-89c6-70ceb8d34995@github.com>

On Mon, 6 Mar 2023 20:22:48 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
>> 
>> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
>> 
>> 
>>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>>     @@ -17084,7 +17084,7 @@
>>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>>      <div class="block"><code>readObject</code> is called to restore the state of the
>>     - (@code BasicPermission} from a stream.</div>
>>     + <code>BasicPermission</code> from a stream.</div>
>>      <dl class="notes">
>>      <dt>Parameters:</dt>
>>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
>> 
>> Notes
>> -----
>> 
>> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
>> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
>> * I will update copyright years after (and if) the fix had been approved, as required.
>
> Pavel Rappo 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 8303480
>  - Initial commit

Marked as reviewed by lancea (Reviewer).

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

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

From xliu at openjdk.org  Mon Mar  6 21:24:16 2023
From: xliu at openjdk.org (Xin Liu)
Date: Mon, 6 Mar 2023 21:24:16 GMT
Subject: RFR: 8301136: Improve unlink() and unlink_all() of
 ResourceHashtableBase [v5]
In-Reply-To: <9GAFUt_y36yObC0oOhzxNC05Y8Ja_fkUPxvhZCuFSPY=.255df6aa-d417-4277-9799-a9208e758158@github.com>
References: <Tqq1KY1B3iGRAVtESg4dEOP6cVZWkLVU6Rc_pHh9Uwo=.d2581151-724d-4e38-a24d-a78b94332356@github.com>
 <Jx-iXszYbBusmtlnUjn7Hq6kg5ppQooErA80Oq4A0Hk=.63d3eea6-c154-48a3-ab7b-a269cd02ba27@github.com>
 <9GAFUt_y36yObC0oOhzxNC05Y8Ja_fkUPxvhZCuFSPY=.255df6aa-d417-4277-9799-a9208e758158@github.com>
Message-ID: <ZbOOpYxdqaQJz-Il3wexGfY4D4nRUQc-n0gcDN5_oBk=.f715ff46-bfab-46fa-bf4a-176e8dc56c76@github.com>

On Sun, 29 Jan 2023 06:41:10 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add lambda API unlink(Function f) per reviewers' request.
>
> I updated [JDK-8301296](https://bugs.openjdk.org/browse/JDK-8301296) to clarify the problems with the current ResourceHashtable design and my proposal for fixing them.
> 
> I think the above proposed fixes shouldn't block the progress of this PR, which is just an optimization that maintains the current behavior. So let's continue the discussions here.
> 
> There are two parts of this PR:
> 
> [1] For the optimization (counting the number of entries and exit the loop early), do you have any performance data that shows this is beneficial?
> 
> For this optimization to be beneficial, we must have two conditions -- (a) the table is too large so it's likely to have many unused entries, and (b) the hash function is bad so most of the unused entries are at the end of the table.
> 
> For (a), maybe it's better to change the table to ResizeableResourceHashtable?
> For (b), maybe you can also print out the occupancy of the table in your traces like this one (in your earlier PR https://github.com/openjdk/jdk/pull/12016)
> 
> 
> [12.824s][debug][hashtables] table_size = 109, break at 68
> 
> 
> If we have many entries (e.g., 40) but they all pack to the front end of the table, that means we have a bad hash function.
> 
> [2] As I suggested earlier, we should consolidate the code to use a single unlink loop, so you can apply this counting optimization in a single place. 
> 
> I am not quite sure why you would need the following in your "wrapper" functions:
> 
> 
> if (clean) {
>   *ptr = node->_next;
> } else {
>   ptr = &(node->_next);
> }
> 
> 
> and
> 
> 
> if (node->_next == nullptr) {
>   // nullify the bucket when reach the end of linked list.
>   *ptr = nullptr;
> }
> 
> 
> I wrote a version of the consolidated loop that's much simpler. It also aligns with the old code so the diff is more readable:
> 
> https://github.com/openjdk/jdk/compare/master...iklam:jdk:8301136-resource-hash-unlink-all-suggestion
> 
> Note that I have both `unlink_all()` and `unlink_all(Function function)`, that's because the current API allows the user function to do two things (a) check if the entry should be freed, (b) perform special clean up on the entry. So if you want to free all entries but need to perform special clean up, you'd call  `unlink_all(Function function)`.

hi, @iklam, 

I found that the dominating way to remove elements in resoureHashTable is its destructor. 
I ran some Renaissance benchmarks and observed the similar thing. 

In particular, it's very common to call destructor for an empty resourceHashtable. I think we should apply to the shortcut optimization in JDK-8300184 in the destructor. 



?  jdk git:(JDK-8301136) ./build/linux-x86_64-server-release/images/jdk/bin/java -Xlog:hashtables=debug --version
[0.052s][debug][hashtables] ResourceHashtableBase destructor: entries = 0
[0.052s][debug][hashtables] ResourceHashtableBase table_size = 1031, break at 0, removed = 0
[0.052s][debug][hashtables] ResourceHashtableBase destructor: entries = 0
[0.052s][debug][hashtables] ResourceHashtableBase table_size = 1031, break at 0, removed = 0
[0.063s][debug][hashtables] ResourceHashtableBase destructor: entries = 0
[0.063s][debug][hashtables] ResourceHashtableBase table_size = 1031, break at 0, removed = 0
[0.063s][debug][hashtables] ResourceHashtableBase destructor: entries = 0
[0.063s][debug][hashtables] ResourceHashtableBase table_size = 1031, break at 0, removed = 0
[0.063s][debug][hashtables] ResourceHashtableBase destructor: entries = 0
[0.063s][debug][hashtables] ResourceHashtableBase table_size = 1031, break at 0, removed = 0
[0.063s][debug][hashtables] ResourceHashtableBase destructor: entries = 0
[0.063s][debug][hashtables] ResourceHashtableBase table_size = 1031, break at 0, removed = 0
[0.063s][debug][hashtables] ResourceHashtableBase destructor: entries = 0
[0.063s][debug][hashtables] ResourceHashtableBase table_size = 1031, break at 0, removed = 0
[0.072s][debug][hashtables] ResourceHashtableBase destructor: entries = 0
[0.072s][debug][hashtables] ResourceHashtableBase table_size = 1031, break at 0, removed = 0
openjdk 21-internal 2023-09-19
OpenJDK Runtime Environment (build 21-internal-adhoc.xxinliu.jdk)
OpenJDK 64-Bit Server VM (build 21-internal-adhoc.xxinliu.jdk, mixed mode, sharing)
[0.073s][debug][hashtables] ResourceHashtableBase destructor: entries = 0
[0.073s][debug][hashtables] ResourceHashtableBase table_size = 1031, break at 0, removed = 0
[0.073s][debug][hashtables] ResourceHashtableBase destructor: entries = 0
[0.073s][debug][hashtables] ResourceHashtableBase table_size = 1031, break at 0, removed = 0
[0.073s][debug][hashtables] ResourceHashtableBase destructor: entries = 0
[0.073s][debug][hashtables] ResourceHashtableBase table_size = 1031, break at 0, removed = 0
[0.073s][debug][hashtables] ResourceHashtableBase destructor: entries = 0
[0.073s][debug][hashtables] ResourceHashtableBase table_size = 1031, break at 0, removed = 0
[0.073s][debug][hashtables] ResourceHashtableBase destructor: entries = 0
[0.073s][debug][hashtables] ResourceHashtableBase table_size = 1031, break at 0, removed = 0

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

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

From rriggs at openjdk.org  Mon Mar  6 21:29:08 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 6 Mar 2023 21:29:08 GMT
Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments
 [v2]
In-Reply-To: <cwRZFQxyddrtPWS__nVK0l1Lu-dL3lnlR3rODiLfncA=.2f5b214e-9ae7-492a-b09a-81ef4077a26e@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
 <cwRZFQxyddrtPWS__nVK0l1Lu-dL3lnlR3rODiLfncA=.2f5b214e-9ae7-492a-b09a-81ef4077a26e@github.com>
Message-ID: <xJn3JEoOJduXQZ9MF4uueB3KdIC4T_3roLNAWSQ8mZM=.4d80d353-a5e3-4cc4-87b3-320643f8cc36@github.com>

On Mon, 6 Mar 2023 20:22:48 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
>> 
>> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
>> 
>> 
>>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>>     @@ -17084,7 +17084,7 @@
>>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>>      <div class="block"><code>readObject</code> is called to restore the state of the
>>     - (@code BasicPermission} from a stream.</div>
>>     + <code>BasicPermission</code> from a stream.</div>
>>      <dl class="notes">
>>      <dt>Parameters:</dt>
>>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
>> 
>> Notes
>> -----
>> 
>> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
>> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
>> * I will update copyright years after (and if) the fix had been approved, as required.
>
> Pavel Rappo 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 8303480
>  - Initial commit

Marked as reviewed by rriggs (Reviewer).

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

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

From dholmes at openjdk.org  Tue Mar  7 01:19:29 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 7 Mar 2023 01:19:29 GMT
Subject: RFR: 8296469: Instrument VMError::report with reentrant iteration
 step for register and stack printing [v9]
In-Reply-To: <5La1Nl4tQg06WqJWG4Tou6QoEXdnS8l_YTddxJbYHyE=.89395bb9-1570-4bc0-98e9-355da8412c89@github.com>
References: <s2wlyE6OjqTazCsro-keOXqXvYMqwHEp8YdMZhCdQXs=.37245c9a-5891-42b8-b961-55d1a7a30af5@github.com>
 <faDgjMse2Qwb7_8iLAq1j-h7Hwqt28vQJMbIjhTSuAM=.4d8095b3-aa6f-4190-8806-4edb7e37a256@github.com>
 <5La1Nl4tQg06WqJWG4Tou6QoEXdnS8l_YTddxJbYHyE=.89395bb9-1570-4bc0-98e9-355da8412c89@github.com>
Message-ID: <2DFTvxr-u0lXBoxjEjR5PPuJr69dl_r-IVsm67cqDV0=.07382883-e874-418e-9eab-bfe826d7d499@github.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
On Mon, 6 Mar 2023 15:00:31 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> 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 15 commits:
>> 
>>  - Merge remote-tracking branch 'upstream_jdk/master' into vmerror_report_register_stack_reentrant
>>  - Add test
>>  - Fix and strengthen print_stack_location
>>  - Missed variable rename
>>  - Copyright
>>  - Rework logic and use continuation state for reattempts
>>  - Merge remote-tracking branch 'upstream_jdk/master' into vmerror_report_register_stack_reentrant
>>  - Restructure os::print_register_info interface
>>  - Code syle and line length
>>  - Merge Fix
>>  - ... and 5 more: https://git.openjdk.org/jdk/compare/2009dc2b...2e12b4a5
>
> src/hotspot/share/utilities/vmError.cpp line 175:
> 
>> 173: static bool check_stack_headroom(Thread* thread,
>> 174:                                  size_t headroom) {
>> 175:   static const address stack_top    = thread != nullptr
> 
> We typically call "stack_top "stack_base", and "stack_bottom" we call "stack_end".

There is existing code in this file that uses this naming:

 STEP_IF("printing stack bounds", _verbose)
    st->print("Stack: ");

    address stack_top;
    size_t stack_size;

    if (_thread) {
      stack_top = _thread->stack_base();
      stack_size = _thread->stack_size();
    } else {
      stack_top = os::current_stack_base();
      stack_size = os::current_stack_size();
    }

    address stack_bottom = stack_top - stack_size;
    st->print("[" PTR_FORMAT "," PTR_FORMAT "]", p2i(stack_bottom), p2i(stack_top));

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

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

From dholmes at openjdk.org  Tue Mar  7 01:29:13 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 7 Mar 2023 01:29:13 GMT
Subject: RFR: 8302189: Mark assertion failures noreturn [v2]
In-Reply-To: <RpSNK9GIjArbtBrThlIAAOmHNSAI7LSYDgOf8G6dtoM=.10720821-fe1b-47d1-8b4a-4935b6a15223@github.com>
References: <4gLeUT6_5s6WpG-b-0146d490ZRgBq_JON1-5P3Wgtk=.e0bc3fd3-fce0-47b8-9478-1de796128731@github.com>
 <PhwlkTOKz7EsK0wAlY-IRGfno3c9TEqNf9WJIc3mVTg=.3f9273af-44e5-4d8f-beb4-0bc2b774b9d1@github.com>
 <stprjbPE3-XC5_Zmi7XvJ_eGVwHInOD1CbG1m_CdXkI=.d7ee8808-d60c-4f37-97c8-5cff4b96efa2@github.com>
 <RpSNK9GIjArbtBrThlIAAOmHNSAI7LSYDgOf8G6dtoM=.10720821-fe1b-47d1-8b4a-4935b6a15223@github.com>
Message-ID: <wRRYvubBcZFz4COeCGSq35vsMfBAslzlKtuJSKU4iSc=.58b0917d-c377-431d-b4cc-25a2d529fc71@github.com>

On Sun, 5 Mar 2023 15:36:30 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> I don't understand the question?  These are member variable declarations.
>
> I believe David is asking about why these particular member names were changed

No I'm comparing the syntax used elsewhere:

DebuggingContext debugging{};

with that used here:

DebuggingContext debugging;

why the braces in most cases but not here?

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

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

From dholmes at openjdk.org  Tue Mar  7 01:32:14 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 7 Mar 2023 01:32:14 GMT
Subject: RFR: 8302189: Mark assertion failures noreturn [v2]
In-Reply-To: <stprjbPE3-XC5_Zmi7XvJ_eGVwHInOD1CbG1m_CdXkI=.d7ee8808-d60c-4f37-97c8-5cff4b96efa2@github.com>
References: <4gLeUT6_5s6WpG-b-0146d490ZRgBq_JON1-5P3Wgtk=.e0bc3fd3-fce0-47b8-9478-1de796128731@github.com>
 <PhwlkTOKz7EsK0wAlY-IRGfno3c9TEqNf9WJIc3mVTg=.3f9273af-44e5-4d8f-beb4-0bc2b774b9d1@github.com>
 <stprjbPE3-XC5_Zmi7XvJ_eGVwHInOD1CbG1m_CdXkI=.d7ee8808-d60c-4f37-97c8-5cff4b96efa2@github.com>
Message-ID: <Z1n-h7a_gEQRR5j9xPlUEP5vrtdHOaQq31bAzMT7fTI=.997e933f-f59a-43ec-a738-794d5dab9d0e@github.com>

On Sat, 4 Mar 2023 11:16:10 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> src/hotspot/share/utilities/debug.cpp line 85:
>> 
>>> 83:   if (is_enabled()) {
>>> 84:     fatal("Multiple Debugging contexts");
>>> 85:   }
>> 
>> This seems too restrictive as you could hit different DebuggingContexts in different threads. ??
>
> This facility is only intended for use by manually invoked commands while the program is stopped in a debugger. Multi-threaded use is not an issue (and was not supported previously either). I don't think there are any nested uses either, but I've now run across a couple of places where nesting could be useful. So I'm changing the state from a simple bool to a nesting counter.

Okay I hadn't realized the process was basically "suspended" when this was activated - as I said I never use this stuff.

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

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

From kim.barrett at oracle.com  Tue Mar  7 01:38:39 2023
From: kim.barrett at oracle.com (Kim Barrett)
Date: Tue, 7 Mar 2023 01:38:39 +0000
Subject: alignas and clang
In-Reply-To: <CAA-vtUwZB9ATLEY4OvJODzQFTDxbaT+dEOweP1wbX_=LwmD6nA@mail.gmail.com>
References: <CAA-vtUxtai4m68sc_hahTXuuzEFxJnRQc3-rjbigKha1LqHYpg@mail.gmail.com>
 <CAP2b4GNe86xXM+-BKOzTgb89Tngmo2-O4cU7Jt+EQqvnu_XM6g@mail.gmail.com>
 <CAA-vtUyGJjuz5Aj=ApBAAGxb=-mtMFKUOecPgpWt4G5HcsaFTQ@mail.gmail.com>
 <CAP2b4GOg1gX2bg=G18h9Z9svL7M9+gPX46b4TVxH=4iX=DgR5Q@mail.gmail.com>
 <CAA-vtUwZB9ATLEY4OvJODzQFTDxbaT+dEOweP1wbX_=LwmD6nA@mail.gmail.com>
Message-ID: <33A01455-A0AB-48AD-9968-9AAA3EB66E4D@oracle.com>

> On Mar 6, 2023, at 12:58 PM, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
> On Mon, Mar 6, 2023 at 5:23?PM Julian Waters <tanksherman27 at gmail.com> wrote:
> Ahhh, I see what you mean. Seems to me that this may actually be compiler dependent, since C++14 simply states such situations are ill-formed and makes no promises of instead choosing the larger alignment when this happens.
> 
> Oh, you are right, I stopped reading before it got interesting.
> 
> "If the strictest (largest) alignas on a declaration is weaker than the alignment it would have without any alignas specifiers (that is, weaker than its natural alignment or weaker than alignas on another declaration of the same object or type), the program is ill-formed."
> 
> Never mind then, I'll find a different solution.

It looks like you found the explanation for the error.

In case you forgot or hadn?t noticed, a solution is to use multiple `alignas` attributes for the declaration,
and include one which provides the ?natural? alignment.  There?s even an example of doing this in the
standard - C++14 7.6.2/7.

So you could add `alignas(void*)` to the alignment specifiers in the example.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20230307/3f7361c5/signature-0001.asc>

From darcy at openjdk.org  Tue Mar  7 01:39:14 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 7 Mar 2023 01:39:14 GMT
Subject: RFR: JDK-8302801: Remove fdlibm C sources [v4]
In-Reply-To: <uQoZHReFrel_izPKlfqwudhAYE_WA8flqfqJYO-LvCU=.d9428c55-ec5f-4843-af00-a0f5a41c2c63@github.com>
References: <fFJoo_g2Rqg062mR5ftOMCF6y9JrrlpW6wO1Vz0OeMI=.3a124adf-6ddf-4ab2-90d9-d26a400d09c7@github.com>
 <W3_m-0cY0KTUdcoT5QUpxCBbB9P8QNedMSlL7ob-_94=.818f6ff9-b559-4313-a72e-1e07913b4dc9@github.com>
 <3JvuLUDJO3_dzKHOsMocC6kGDEmnIQo_7uobd-VTzHg=.22565440-42ae-4d26-9d74-2cbb7c63f9ea@github.com>
 <uQoZHReFrel_izPKlfqwudhAYE_WA8flqfqJYO-LvCU=.d9428c55-ec5f-4843-af00-a0f5a41c2c63@github.com>
Message-ID: <IcSmoF7Zhuyjaru60zJZvnGxByyN-mAiqHpPJ1mYMRc=.bc38a415-0e05-4592-aec1-45d6fcaa259d@github.com>

On Sun, 5 Mar 2023 17:10:08 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> PS Successful Mach 5 job of default builds and tier 1 tests with this make line present.

PPS And for extra measure as suggested by David Holmes, a tier 1 through 5 build job was also successful.

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

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

From dholmes at openjdk.org  Tue Mar  7 01:40:14 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 7 Mar 2023 01:40:14 GMT
Subject: RFR: 8302189: Mark assertion failures noreturn [v2]
In-Reply-To: <BMN3OJv9QTo0bNa_BvIMuldsCZDRD1-YjiN826iXbG0=.44fd41e9-ea55-437a-9c0a-294d5daaea71@github.com>
References: <4gLeUT6_5s6WpG-b-0146d490ZRgBq_JON1-5P3Wgtk=.e0bc3fd3-fce0-47b8-9478-1de796128731@github.com>
 <BMN3OJv9QTo0bNa_BvIMuldsCZDRD1-YjiN826iXbG0=.44fd41e9-ea55-437a-9c0a-294d5daaea71@github.com>
Message-ID: <T17qJbSmSkh9QDSoeq7C739FMZa_hweq5Fi_eoTsUSw=.8e735a5a-7812-412d-9163-3481961a8b67@github.com>

On Sat, 4 Mar 2023 11:23:58 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Also 8302799: Refactor Debugging variable usage for noreturn crash reporting
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make Debugging::_enabled a nesting counter

Okay other than the one outstanding minor syntax query, I have nothing further to add.

Thanks.

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

Marked as reviewed by dholmes (Reviewer).

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

From cslucas at openjdk.org  Tue Mar  7 01:51:13 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Tue, 7 Mar 2023 01:51:13 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects
 participating in allocation merges
Message-ID: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>

Can I please get reviews for this PR to add support for the rematerialization of scalar-replaced objects that participate in allocation merges?

The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested.

With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N:

![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png)

What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1:

![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png)

This PR adds support scalar replacing allocations participating in merges that are used *only* as debug information in SafePointNode and its subclasses. Although there is a performance benefit in doing scalar replacement in this scenario only, the goal of this PR is mainly to add infrastructure to support the rematerialization of SR objects participating in merges. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP, Load+AddP, primarily) subsequently.

The approach I used is pretty straightforward. It consists basically in: 1) Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a new Class to support rematerialization of SR objects part of merges; 3) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 4) Patch C2 to generate unique types for SR objects participating in allocation merges used only as debug information.

I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression that might be related. I also tested with several applications and didn't see any failure.

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

Commit messages:
 - Add support for rematerializing scalar replaced objects participating in allocation merges

Changes: https://git.openjdk.org/jdk/pull/12897/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8287061
  Stats: 1803 lines in 18 files changed: 1653 ins; 9 del; 141 mod
  Patch: https://git.openjdk.org/jdk/pull/12897.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12897/head:pull/12897

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

From dholmes at openjdk.org  Tue Mar  7 01:51:20 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 7 Mar 2023 01:51:20 GMT
Subject: RFR: 8302191: Performance degradation for float/double modulo on
 Linux [v10]
In-Reply-To: <BZzGkFY8NqP3p7n2bpwgzx2d36xFsY2jDPHIw-g6qyg=.5a908fbb-047f-4145-9827-38aa10a0c30a@github.com>
References: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
 <BZzGkFY8NqP3p7n2bpwgzx2d36xFsY2jDPHIw-g6qyg=.5a908fbb-047f-4145-9827-38aa10a0c30a@github.com>
Message-ID: <gnj0nIACHh3hKqsVaMDIL5aziqG80_8pwjFYpulJ-mA=.57bcad08-cf2f-499f-9ba1-cdcd20dedc3b@github.com>

On Sat, 4 Mar 2023 02:28:43 GMT, Jan Kratochvil <duke at openjdk.org> wrote:

>> I have OCA already processed/approved. I am not Author but my Author request is being processed these days (sent to Rob McKenna).
>> I did regression test x86_64 OpenJDK-8. I will leave other regression testing on GHA.
>> The patch (and former GCC performance regression) affects only x86_64+i686.
>
> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix win32 broken build.

Changes requested by dholmes (Reviewer).

src/hotspot/share/runtime/sharedRuntime.cpp line 238:

> 236: #endif
> 237: 
> 238: #if !defined(TARGET_COMPILER_gcc) || defined(_WIN64)

That is the wrong condition - it would activate for any non-Windows, non-gcc compiler. This code is only for _WIN64 is it not? regardless of the (theoretical) compiler used on win64?

src/hotspot/share/runtime/sharedRuntime.cpp line 272:

> 270: #endif
> 271: JRT_END
> 272: #endif // !X86 || _WIN64

!X86 ???

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

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

From dholmes at openjdk.org  Tue Mar  7 02:07:31 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 7 Mar 2023 02:07:31 GMT
Subject: RFR: 8302491: NoClassDefFoundError omits the original cause of an
 error [v5]
In-Reply-To: <0UEtpYm8TvljAdj3FQI5LYfjHxXPBWBfFD0lDsLojJA=.d259d5df-24b8-4b93-8fb3-feafc696deab@github.com>
References: <L-pfBfK4TKl5KUWpPEcbs-IkhwimgJZ-SOrbSG3exeA=.5e883f22-de9b-4eec-9e98-8ee954a7996b@github.com>
 <0UEtpYm8TvljAdj3FQI5LYfjHxXPBWBfFD0lDsLojJA=.d259d5df-24b8-4b93-8fb3-feafc696deab@github.com>
Message-ID: <aPvk5CskmkYH1DWQjsc2HAZG3FVDRYF79BF87ZmWN34=.aa85d351-ea6c-48f4-a6e8-2053985ca390@github.com>

On Mon, 6 Mar 2023 20:28:40 GMT, Ilarion Nakonechnyy <inakonechnyy at openjdk.org> wrote:

>> The proposed approach added a new function for getting the cause of an exception -`java_lang_Throwable::get_cause_simple `, that gets called within `InstanceKlass::add_initialization_error`  if an old one `java_lang_Throwable::get_cause_with_stack_trace` didn't succeed because of an exception during the VM call. The simple function doesn't call the VM for getting a stack trace but fills in any other information about an exception.
>> 
>> Besides that, the discovering information about an exception was added to `ConstantPoolCacheEntry::save_and_throw_indy_exc` function. 
>> 
>> Jtreg for reproducing the issue also was added to the commit. 
>> The commit was tested with tier1 tests.
>
> Ilarion Nakonechnyy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   1/ create_initialization_error(): return empty exception, if
>   EIIE creation failed.
>   2/ remove testcase

Thanks for the updates. Mostly just nits with comments and names.

src/hotspot/share/classfile/javaClasses.cpp line 2741:

> 2739: 
> 2740:   // Throw ExceptionInInitializerError as the cause with this exception in
> 2741:   // the message and stack trace.

I thought I'd flagged this earlier - this comment is not correct. Suggestion for a method-level comment (which allows removing a comment further down).

// Creates an ExceptionInInitializerError to be recorded as the initialization error when class initialization
// failed due to the passed in `throwable`. We cannot save `throwable` directly due to issues with keeping alive
// all objects referenced via its stacktrace. So instead we save a new EIIE instance, with the same message and 
// symbolic stacktrace of `throwable`.

src/hotspot/share/classfile/javaClasses.cpp line 2756:

> 2754: 
> 2755:   Symbol* exception_name = vmSymbols::java_lang_ExceptionInInitializerError();
> 2756:   Handle h_cause = Exceptions::new_exception(current, exception_name, st.as_string());

Existing: h_cause in an inappropriate name as this is not the "cause" of anything. Suggest simply h_eiie

src/hotspot/share/classfile/javaClasses.cpp line 2758:

> 2756:   Handle h_cause = Exceptions::new_exception(current, exception_name, st.as_string());
> 2757:   // If new_exception returns a different exception while creating the exception,
> 2758:   // abandon the attempts to save initialization error and return null.

Nit: save _the_ initialization error ...

src/hotspot/share/classfile/javaClasses.cpp line 2760:

> 2758:   // abandon the attempts to save initialization error and return null.
> 2759:   // We can't just return an original throwable (that is get passed as a parameter),
> 2760:   // because it would keep all the caller classes alive.

Delete this.

src/hotspot/share/oops/instanceKlass.cpp line 983:

> 981:   // this would be still be helpful.
> 982:   JavaThread* THREAD = current;
> 983:   Handle cause = java_lang_Throwable::create_initialization_error(current, exception);

Nit: s/cause/init_error/

src/hotspot/share/oops/instanceKlass.cpp line 987:

> 985:     CLEAR_PENDING_EXCEPTION;
> 986:     return;
> 987:   }

We still need to return if we got null.

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

Changes requested by dholmes (Reviewer).

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

From dholmes at openjdk.org  Tue Mar  7 02:42:22 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 7 Mar 2023 02:42:22 GMT
Subject: RFR: JDK-8300783: Consolidate byteswap implementations [v8]
In-Reply-To: <XN9WbwkPShg_FCuesZ5vg4qkI-4J0tJA80Iz753HtWo=.e3c8cc91-6329-4aba-b038-d5d7b81c8661@github.com>
References: <MLBMwI7xt4IKgpb3AHXJ_J11Ibhijp_q2RFtLJOwHpA=.b7da6b6b-69b8-426d-8eab-c7c3aaa0847e@github.com>
 <v9HNX5mxr8cyTkf-Go6M62giQnF2ltlOnX36VwxfAn4=.3e2b489f-0dbb-4f7b-a685-9a32748847b2@github.com>
 <4T6ba7HVAkPmaau2WD3FRRyOlmEz7MDX5nz2UM-rfms=.58f59fc2-6030-4d9f-914f-5f37df4fb95e@github.com>
 <XN9WbwkPShg_FCuesZ5vg4qkI-4J0tJA80Iz753HtWo=.e3c8cc91-6329-4aba-b038-d5d7b81c8661@github.com>
Message-ID: <7SrHCI-9DW8abOV4cIMPkNt6NF9T7Czx_brOJAZtizQ=.f80ef739-4103-44c2-a7cf-5fb47500864b@github.com>

On Mon, 6 Mar 2023 16:27:26 GMT, Justin King <jcking at openjdk.org> wrote:

>> CI run was fine wrt these changes.
>
> @dholmes-ora Poke. :)

Sorry @jcking but as I previously indicated I'm not qualified to review the details of this. But I will see if I can get someone else to.

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

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

From dholmes at openjdk.org  Tue Mar  7 02:55:19 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 7 Mar 2023 02:55:19 GMT
Subject: RFR: JDK-8302989: Add missing INCLUDE_CDS checks [v3]
In-Reply-To: <wN7sSDJ_BOED2YDdcMwWxVAfgS4FBTs6nMwKQOhI7vc=.c198741d-f758-4104-a6a2-17d2f32cb0da@github.com>
References: <kBV8fNo_CWJL2MoXgAckFhuAFgQ3RGZjFKAKnl8xfV8=.233bb652-8508-4065-92ea-7873b1c765f3@github.com>
 <i619e3l156DnYwsJB7id-5AahSUqdZINDXaDtRo56DA=.f4fdf096-c1f9-48e0-b75a-58776e5f3dd4@github.com>
 <AIWt3I5uWb6Mm2RF-QT_56np5i3oYs3Mmtqqf84W5xA=.ecf61d5f-6d7c-4b87-8638-4c687b3aaa89@github.com>
 <wN7sSDJ_BOED2YDdcMwWxVAfgS4FBTs6nMwKQOhI7vc=.c198741d-f758-4104-a6a2-17d2f32cb0da@github.com>
Message-ID: <WwrR-Rfo_cpjtGd5SVEJDcy0-4DwwFoSEefcN-X2kUI=.4ba26802-07dd-498d-ba15-5ed9d6f6fd20@github.com>

On Fri, 3 Mar 2023 08:34:21 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> src/hotspot/share/runtime/arguments.cpp line 1460:
>> 
>>> 1458: #if INCLUDE_CDS
>>> 1459:     UseSharedSpaces = false;
>>> 1460: #endif
>> 
>> This doesn't make sense - the entire `no_shared_spaces` method is only meaningful on a JVM with CDS. Otherwise `-Xshare:on` should immediately be rejected. ??
>
> Hi David, unfortunately this has to stay for now, otherwise we would try to set a const in the CDS-disabled build, this does not compile.
> Maybe it would make sense to guard the whole function `no_shared_spaces`  and adjust the calls/usages but I would prefer a separate issue for this.

AFAICS all calls to `no_shared_spaces` are already within INCLUDE_CDS regions so the function itself can also be INCLUDE_CDS only.

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

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

From xliu at openjdk.org  Tue Mar  7 04:34:37 2023
From: xliu at openjdk.org (Xin Liu)
Date: Tue, 7 Mar 2023 04:34:37 GMT
Subject: RFR: 8301136: Improve unlink() and unlink_all() of
 ResourceHashtableBase [v6]
In-Reply-To: <Tqq1KY1B3iGRAVtESg4dEOP6cVZWkLVU6Rc_pHh9Uwo=.d2581151-724d-4e38-a24d-a78b94332356@github.com>
References: <Tqq1KY1B3iGRAVtESg4dEOP6cVZWkLVU6Rc_pHh9Uwo=.d2581151-724d-4e38-a24d-a78b94332356@github.com>
Message-ID: <VnoXmGM8wHxmCxzULt0JIdPvY7lR8iSIH2XFU8zmLN4=.0a8d9fef-40c1-4afa-8db8-c12daa5574b2@github.com>

> 1. Apply the same idea of JDK-8300184 to unlink().
> 2. Because ResourceHashtableBase doesn't support copy assignment, client of it has to purge all elements first when it needs to assign it. We would like provide a specialized version called 'unlink_all()'.  We don't need to update each node's _next in this case. We only nullify all buckets. 
> 3. This patch also provides a specialized version of unlink_all() for destructor. We don't even update buckets. it's dead anyway.

Xin Liu 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:

 - Add log to dump information in removal APIs.
 - Merge branch 'master' into JDK-8301136
 - Add lambda API unlink(Function f) per reviewers' request.
 - Use unlink_all() in JvmtiTagMapTable::clear.
 - Add a template for unlink(), unlink_all() and dtor.
 - Quit early if cnt is zero.
 - 8301136: Improve unlink() and unlink_all() of ResourceHashtableBase

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12213/files
  - new: https://git.openjdk.org/jdk/pull/12213/files/086750e4..8b3bb2df

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

  Stats: 104740 lines in 2885 files changed: 47853 ins; 25265 del; 31622 mod
  Patch: https://git.openjdk.org/jdk/pull/12213.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12213/head:pull/12213

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

From xliu at openjdk.org  Tue Mar  7 05:04:09 2023
From: xliu at openjdk.org (Xin Liu)
Date: Tue, 7 Mar 2023 05:04:09 GMT
Subject: RFR: 8301136: Improve unlink() and unlink_all() of
 ResourceHashtableBase [v6]
In-Reply-To: <VnoXmGM8wHxmCxzULt0JIdPvY7lR8iSIH2XFU8zmLN4=.0a8d9fef-40c1-4afa-8db8-c12daa5574b2@github.com>
References: <Tqq1KY1B3iGRAVtESg4dEOP6cVZWkLVU6Rc_pHh9Uwo=.d2581151-724d-4e38-a24d-a78b94332356@github.com>
 <VnoXmGM8wHxmCxzULt0JIdPvY7lR8iSIH2XFU8zmLN4=.0a8d9fef-40c1-4afa-8db8-c12daa5574b2@github.com>
Message-ID: <1Z3kA8O-iyd5aVsc8-Jqzpe8uSz5-HIeYsltKlMGrtI=.879e0dae-5e1c-46d2-aeed-f4a397558f37@github.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
On Tue, 7 Mar 2023 04:34:37 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> 1. Apply the same idea of JDK-8300184 to unlink().
>> 2. Because ResourceHashtableBase doesn't support copy assignment, client of it has to purge all elements first when it needs to assign it. We would like provide a specialized version called 'unlink_all()'.  We don't need to update each node's _next in this case. We only nullify all buckets. 
>> 3. This patch also provides a specialized version of unlink_all() for destructor. We don't even update buckets. it's dead anyway.
>
> Xin Liu 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:
> 
>  - Add log to dump information in removal APIs.
>  - Merge branch 'master' into JDK-8301136
>  - Add lambda API unlink(Function f) per reviewers' request.
>  - Use unlink_all() in JvmtiTagMapTable::clear.
>  - Add a template for unlink(), unlink_all() and dtor.
>  - Quit early if cnt is zero.
>  - 8301136: Improve unlink() and unlink_all() of ResourceHashtableBase

I uploaded the hashtable logs of Renaissance/finagle-chirper. The reason I looked in it is that it produces the most logs in runtime. It yields 14,422 lines of log for the tag 'hashtables'.  One interesting thing is that 9,166 or 63.5% of them is to remove an empty ResourceHashable.


$awk -F '[ ,]' '$15 == 0 {print $0}' finagle-chirper-hashtables.log  | wc -l
9166


"break at 0" below indicates that we effectively skip any iteration.


[2.151s][debug][hashtables] ResourceHashtableBase table_size = 1031, break at 0, removed 0 out of 0


For the remaining non-trivial entries, 5254 out of 5256 is to remove all elements. They are all from destructor. Current patch only invokes `unlink_all()` in JVMTI. We don't use jvmti in the test. 


awk -F '[ ,]' '$12 == $15 {print $0}' finagle-chirper-hashtables-nontrivial.log|wc -l
5254


Overall, 14,063 or 97.5% of logs breaks earlier and save some useless iterations. 

 awk -F '[ ,]' '$5 != $9 {print $0}' finagle-chirper-hashtables.log   | wc -l
14063


Conclusion:
 1. We need to optimize 'destructor' of resourceHashtable. In particular, we should apply  the optimization of JDK-8300184 to it.
 2. we should consider to specialize "unlink_all".

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

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

From xliu at openjdk.org  Tue Mar  7 05:14:24 2023
From: xliu at openjdk.org (Xin Liu)
Date: Tue, 7 Mar 2023 05:14:24 GMT
Subject: RFR: 8301136: Improve unlink() and unlink_all() of
 ResourceHashtableBase [v5]
In-Reply-To: <9GAFUt_y36yObC0oOhzxNC05Y8Ja_fkUPxvhZCuFSPY=.255df6aa-d417-4277-9799-a9208e758158@github.com>
References: <Tqq1KY1B3iGRAVtESg4dEOP6cVZWkLVU6Rc_pHh9Uwo=.d2581151-724d-4e38-a24d-a78b94332356@github.com>
 <Jx-iXszYbBusmtlnUjn7Hq6kg5ppQooErA80Oq4A0Hk=.63d3eea6-c154-48a3-ab7b-a269cd02ba27@github.com>
 <9GAFUt_y36yObC0oOhzxNC05Y8Ja_fkUPxvhZCuFSPY=.255df6aa-d417-4277-9799-a9208e758158@github.com>
Message-ID: <ufo7qAy_U-65L5vD2KRyCf8OYecGIrYd8LKCq9r_vEE=.e8acdc7b-3637-4427-bac6-d38d2359fb7c@github.com>

On Sun, 29 Jan 2023 06:41:10 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add lambda API unlink(Function f) per reviewers' request.
>
> I updated [JDK-8301296](https://bugs.openjdk.org/browse/JDK-8301296) to clarify the problems with the current ResourceHashtable design and my proposal for fixing them.
> 
> I think the above proposed fixes shouldn't block the progress of this PR, which is just an optimization that maintains the current behavior. So let's continue the discussions here.
> 
> There are two parts of this PR:
> 
> [1] For the optimization (counting the number of entries and exit the loop early), do you have any performance data that shows this is beneficial?
> 
> For this optimization to be beneficial, we must have two conditions -- (a) the table is too large so it's likely to have many unused entries, and (b) the hash function is bad so most of the unused entries are at the end of the table.
> 
> For (a), maybe it's better to change the table to ResizeableResourceHashtable?
> For (b), maybe you can also print out the occupancy of the table in your traces like this one (in your earlier PR https://github.com/openjdk/jdk/pull/12016)
> 
> 
> [12.824s][debug][hashtables] table_size = 109, break at 68
> 
> 
> If we have many entries (e.g., 40) but they all pack to the front end of the table, that means we have a bad hash function.
> 
> [2] As I suggested earlier, we should consolidate the code to use a single unlink loop, so you can apply this counting optimization in a single place. 
> 
> I am not quite sure why you would need the following in your "wrapper" functions:
> 
> 
> if (clean) {
>   *ptr = node->_next;
> } else {
>   ptr = &(node->_next);
> }
> 
> 
> and
> 
> 
> if (node->_next == nullptr) {
>   // nullify the bucket when reach the end of linked list.
>   *ptr = nullptr;
> }
> 
> 
> I wrote a version of the consolidated loop that's much simpler. It also aligns with the old code so the diff is more readable:
> 
> https://github.com/openjdk/jdk/compare/master...iklam:jdk:8301136-resource-hash-unlink-all-suggestion
> 
> Note that I have both `unlink_all()` and `unlink_all(Function function)`, that's because the current API allows the user function to do two things (a) check if the entry should be freed, (b) perform special clean up on the entry. So if you want to free all entries but need to perform special clean up, you'd call  `unlink_all(Function function)`.

@iklam 

Like you said, I mixed up 2 things. My real intention is to introduce a new api `unlink_all()` because I used it in my project. 

I understand that you want me to refactor unlink(Iterator) using lambda. In order to have an efficient unlink_all() and dtor, I have to factor out unlink_impl(). It's private and acts as the algorithmic template.

What should I do now?  Should I split this JBS issue into 2? One is for the optimization and the other one for "unlink_all()"? that would make thing easier to review. 

thanks,
--lx

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

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

From kbarrett at openjdk.org  Tue Mar  7 06:02:14 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 7 Mar 2023 06:02:14 GMT
Subject: RFR: 8302189: Mark assertion failures noreturn [v2]
In-Reply-To: <wRRYvubBcZFz4COeCGSq35vsMfBAslzlKtuJSKU4iSc=.58b0917d-c377-431d-b4cc-25a2d529fc71@github.com>
References: <4gLeUT6_5s6WpG-b-0146d490ZRgBq_JON1-5P3Wgtk=.e0bc3fd3-fce0-47b8-9478-1de796128731@github.com>
 <PhwlkTOKz7EsK0wAlY-IRGfno3c9TEqNf9WJIc3mVTg=.3f9273af-44e5-4d8f-beb4-0bc2b774b9d1@github.com>
 <stprjbPE3-XC5_Zmi7XvJ_eGVwHInOD1CbG1m_CdXkI=.d7ee8808-d60c-4f37-97c8-5cff4b96efa2@github.com>
 <RpSNK9GIjArbtBrThlIAAOmHNSAI7LSYDgOf8G6dtoM=.10720821-fe1b-47d1-8b4a-4935b6a15223@github.com>
 <wRRYvubBcZFz4COeCGSq35vsMfBAslzlKtuJSKU4iSc=.58b0917d-c377-431d-b4cc-25a2d529fc71@github.com>
Message-ID: <G3kIZM5S8ZPJuEXtyvHO_5hIlJtHrxQl2gDzaWMBrto=.8b3d9a68-28c4-454c-80ea-5ca47f9ee715@github.com>

On Tue, 7 Mar 2023 01:25:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I believe David is asking about why these particular member names were changed
>
> No I'm comparing the syntax used elsewhere:
> 
> DebuggingContext debugging{};
> 
> with that used here:
> 
> DebuggingContext debugging;
> 
> why the braces in most cases but not here?

"syntax used elsewhere" are declarations of local variables initialized with _value initialization_ (which is _default initialization_ for this type).  "that used here" is a member variable declaration in the Command class, where the initialization occurs elsewhere (in the constructor of the Command class [*]).  They are entirely different syntactic entities.  Does that help?  Or am I still not understanding your question?

[*] With C++11, data members can have default initializers, but that's not an approved feature for HotSpot.

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

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

From dholmes at openjdk.org  Tue Mar  7 06:28:15 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 7 Mar 2023 06:28:15 GMT
Subject: RFR: 8302189: Mark assertion failures noreturn [v2]
In-Reply-To: <G3kIZM5S8ZPJuEXtyvHO_5hIlJtHrxQl2gDzaWMBrto=.8b3d9a68-28c4-454c-80ea-5ca47f9ee715@github.com>
References: <4gLeUT6_5s6WpG-b-0146d490ZRgBq_JON1-5P3Wgtk=.e0bc3fd3-fce0-47b8-9478-1de796128731@github.com>
 <PhwlkTOKz7EsK0wAlY-IRGfno3c9TEqNf9WJIc3mVTg=.3f9273af-44e5-4d8f-beb4-0bc2b774b9d1@github.com>
 <stprjbPE3-XC5_Zmi7XvJ_eGVwHInOD1CbG1m_CdXkI=.d7ee8808-d60c-4f37-97c8-5cff4b96efa2@github.com>
 <RpSNK9GIjArbtBrThlIAAOmHNSAI7LSYDgOf8G6dtoM=.10720821-fe1b-47d1-8b4a-4935b6a15223@github.com>
 <wRRYvubBcZFz4COeCGSq35vsMfBAslzlKtuJSKU4iSc=.58b0917d-c377-431d-b4cc-25a2d529fc71@github.com>
 <G3kIZM5S8ZPJuEXtyvHO_5hIlJtHrxQl2gDzaWMBrto=.8b3d9a68-28c4-454c-80ea-5ca47f9ee715@github.com>
Message-ID: <jb94pJMCj-cggxBaRz-fiZH8uh6i4vG_cxstyIuQR30=.b7c5f6b9-8617-41f3-af3e-2f19b59e4818@github.com>

On Tue, 7 Mar 2023 05:58:57 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> No I'm comparing the syntax used elsewhere:
>> 
>> DebuggingContext debugging{};
>> 
>> with that used here:
>> 
>> DebuggingContext debugging;
>> 
>> why the braces in most cases but not here?
>
> "syntax used elsewhere" are declarations of local variables initialized with _value initialization_ (which is _default initialization_ for this type).  "that used here" is a member variable declaration in the Command class, where the initialization occurs elsewhere (in the constructor of the Command class [*]).  They are entirely different syntactic entities.  Does that help?  Or am I still not understanding your question?
> 
> [*] With C++11, data members can have default initializers, but that's not an approved feature for HotSpot.

Sorry I was fixated on the weirdness (to me) of the {} initialization. I missed the fact these were different kinds of declarations.

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

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

From dholmes at openjdk.org  Tue Mar  7 08:15:20 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 7 Mar 2023 08:15:20 GMT
Subject: RFR: 8292818: replace 96-bit representation for field metadata
 with variable-sized streams
In-Reply-To: <vdiacOO3JUyy4sWGkDXNBMUT7cG3XYe79mOvYru9uMM=.9c556675-7ffd-4c09-a428-6d64dffef209@github.com>
References: <vdiacOO3JUyy4sWGkDXNBMUT7cG3XYe79mOvYru9uMM=.9c556675-7ffd-4c09-a428-6d64dffef209@github.com>
Message-ID: <OsVOS3ysSlx4bku4AOnDcy-E5VHzL0iPJj-Tx-Cb3ZQ=.43cbdec2-5c34-4fa9-b88a-7288a3b019fb@github.com>

On Fri, 3 Mar 2023 14:50:34 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review this change re-implementing the FieldInfo data structure.
> 
> The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency.
> 
> The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information).
> 
> More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818
> 
> Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM.
> 
> The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format.
> 
> Tested with mach5, tier 1 to 7.
> 
> Thank you.

HI Fred,

I've taken one pass through this but it is a huge set of changes to try and digest. At this stage just a bunch of style nits.

Thanks.

src/hotspot/share/classfile/classFileParser.cpp line 1632:

> 1630:     {
> 1631:       debug_only(NoSafepointVerifier nsv;)
> 1632:       for(int i = 0; i < _temp_field_info->length(); i++) {

Nit: space after 'for' please

src/hotspot/share/classfile/classFileParser.cpp line 2012:

> 2010: void ClassFileParser::FieldAnnotationCollector::apply_to(FieldInfo* f) {
> 2011:   if (is_contended())
> 2012:   // Setting the contended group also set the contended bit in field flags

Nit: s/set/sets/

src/hotspot/share/oops/fieldInfo.cpp line 30:

> 28: 
> 29: void FieldInfo::print(outputStream* os, ConstantPool* cp) {
> 30:   os->print_cr("index=%d name_index=%d name=%s signature_index=%d signature=%s offset=%d AccessFlags=%d FieldFlags=%d initval_index=%d gen_signature_index=%d, gen_signature=%s contended_group=%d",

Nit: please break up this line

src/hotspot/share/oops/fieldInfo.cpp line 120:

> 118:   *java_fields_count = r.next_uint();
> 119:   *injected_fields_count = r.next_uint();
> 120:   while(r.has_next()) {

Nit: space before (

src/hotspot/share/oops/fieldInfo.cpp line 135:

> 133:   int java_field_count = r.next_uint();
> 134:   int injected_fields_count = r.next_uint();
> 135:   while(r.has_next()) {

Nit: space before (

src/hotspot/share/oops/fieldInfo.cpp line 140:

> 138:     fi.print(os, cp);
> 139:   }
> 140: }

Newline needed at EOF

src/hotspot/share/oops/fieldInfo.inline.hpp line 135:

> 133:     new_flags = old_flags | mask;
> 134:     witness = Atomic::cmpxchg(&flags, old_flags, new_flags);
> 135:   } while(witness != old_flags);

Nit: space before (

src/hotspot/share/oops/fieldInfo.inline.hpp line 155:

> 153: inline void FieldStatus::update_access_watched(bool z) { update_flag(_fs_access_watched, z); }
> 154: inline void FieldStatus::update_modification_watched(bool z) { update_flag(_fs_modification_watched, z); }
> 155: inline void FieldStatus::update_initialized_final_update(bool z) {update_flag(_initialized_final_update, z); }

Nit: space after {

src/hotspot/share/oops/fieldStreams.hpp line 43:

> 41:  protected:
> 42:   const Array<u1>* _fieldinfo_stream;
> 43:   FieldInfoReader   _reader;

Nit variable name alignment seems off

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

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

From ayang at openjdk.org  Tue Mar  7 08:16:36 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 7 Mar 2023 08:16:36 GMT
Subject: RFR: 8303534: Merge CompactibleSpace into ContiguousSpace [v2]
In-Reply-To: <Y5ecs6y1UVWsigb317U2bmJP608sJ_jVk6g77HDUFpo=.cf9c490d-bdbd-4297-9a0c-172518a8285e@github.com>
References: <dPNxDwwSW0wlk4Fv6eYg8dsClKdfjNV9si2WZS2Npi0=.c4f52214-c8a1-4fe6-a513-9fb1e0995ae0@github.com>
 <Y5ecs6y1UVWsigb317U2bmJP608sJ_jVk6g77HDUFpo=.cf9c490d-bdbd-4297-9a0c-172518a8285e@github.com>
Message-ID: <sCQx95NymykLEikHh1_kcLr1x6VMsS_M8Tmf9hf-CsE=.d9693e9c-00b5-4ab6-a05d-8a09301416db@github.com>

On Fri, 3 Mar 2023 12:30:38 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple refactoring of merging two types.
>> 
>> Test: tier1-5
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright-year

Thanks for the review.

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

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

From ayang at openjdk.org  Tue Mar  7 08:16:39 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 7 Mar 2023 08:16:39 GMT
Subject: Integrated: 8303534: Merge CompactibleSpace into ContiguousSpace
In-Reply-To: <dPNxDwwSW0wlk4Fv6eYg8dsClKdfjNV9si2WZS2Npi0=.c4f52214-c8a1-4fe6-a513-9fb1e0995ae0@github.com>
References: <dPNxDwwSW0wlk4Fv6eYg8dsClKdfjNV9si2WZS2Npi0=.c4f52214-c8a1-4fe6-a513-9fb1e0995ae0@github.com>
Message-ID: <6U7ZF7mVsSZrtPD76uzRubWX5vFJTzeteT9nCjOu-Ko=.092d53b2-6aad-4930-b4a2-ffce14080ef6@github.com>

On Thu, 2 Mar 2023 21:49:39 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple refactoring of merging two types.
> 
> Test: tier1-5

This pull request has now been integrated.

Changeset: 7fbfc884
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7fbfc884f0980169e8c08167d59147222728b66b
Stats:     197 lines in 14 files changed: 27 ins; 122 del; 48 mod

8303534: Merge CompactibleSpace into ContiguousSpace

Reviewed-by: cjplummer, tschatzl

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

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

From rehn at openjdk.org  Tue Mar  7 08:25:06 2023
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 7 Mar 2023 08:25:06 GMT
Subject: RFR: 8300926: Several startup regressions ~6-70% in 21-b6 all
 platforms [v7]
In-Reply-To: <yAP6c7wzGguBfKuzvbjMZdnaqydAz4PFn0pgR1UGj9s=.ce872f5d-3f7a-4e24-99d5-da5e80855ea4@github.com>
References: <yAP6c7wzGguBfKuzvbjMZdnaqydAz4PFn0pgR1UGj9s=.ce872f5d-3f7a-4e24-99d5-da5e80855ea4@github.com>
Message-ID: <cJFnZXJ-hmObxgs9sB-wzy6RMJnqEoVuQjcR8gvsyc4=.61c5786a-c392-4c57-9b40-3e8a15241ade@github.com>

> Hi all, please consider.
> 
> The original issue was when thread 1 asked to deopt nmethod set X and thread 2 asked for the same or a subset of X.
> All method will already be marked, but the actual deoptimizing, not entrant, patching PC on stacks and patching post call nops, was not done yet. Which meant thread 2 could 'pass' thread 1.
> Most places did deopt under Compile_lock, thus this is not an issue, but WB and clearCallSiteContext do not.
> 
> Since a handshakes may take long before completion and Compile_lock is used for so much more than deopts.
> The fix in https://bugs.openjdk.org/browse/JDK-8299074 instead always emitted a handshake even when everything was already marked. (instead of adding Compile_lock to all places)
> 
> This turnout to be problematic in the startup, for example the number of deopt handshakes in jetty dry run startup went from 5 to 39 handshakes.
> 
> This fix first adds a barrier for which you do not pass until the requested deopts have happened and it coalesces the handshakes.
> Secondly it moves handshakes part out of the Compile_lock where it is possible.
> 
> Which means we fix the performance bug and we reduce the contention on Compile_lock, meaning higher throughput in compiler and things such as class-loading.
> 
> It passes t1-t7 with flying colours! t8 still not completed and I'm redoing some testing due to last minute simplifications.
> 
> Thanks, Robbin

Robbin Ehn 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 'master' into 8300926
 - Comment fixes
 - Include/fwd fixes
 - More review fixes
 - Coleen fix
 - Review fixes 2
 - Review fixes
 - Fixed WS
 - Deopt scopes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12585/files
  - new: https://git.openjdk.org/jdk/pull/12585/files/e1162979..16732f1d

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

  Stats: 36623 lines in 1278 files changed: 23503 ins; 7075 del; 6045 mod
  Patch: https://git.openjdk.org/jdk/pull/12585.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12585/head:pull/12585

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

From stefank at openjdk.org  Tue Mar  7 08:32:45 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 7 Mar 2023 08:32:45 GMT
Subject: RFR: 8303621: BitMap::iterate should support lambdas and other
 function objects [v2]
In-Reply-To: <CmS2TJp8CqKBnTMA0NAPRTR3InnCUUWsf3ykV-VQWZI=.6af78463-cdc3-4142-b81b-379e43a4ac1f@github.com>
References: <G6DDCDP5PMEOH43G8GNeamEnSMNO_4gMsqQ_zuTUZA8=.1608a894-0707-4d87-b022-e7ee318b69f6@github.com>
 <CmS2TJp8CqKBnTMA0NAPRTR3InnCUUWsf3ykV-VQWZI=.6af78463-cdc3-4142-b81b-379e43a4ac1f@github.com>
Message-ID: <UJgT7R2E2pWBIHrSfknknUjpRe6lxxSkdjbvNcHMuGc=.d7cd49ee-c438-4ca5-92aa-07785f888ec4@github.com>

On Mon, 6 Mar 2023 10:33:36 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this enhancement of BitMap::iterate to support lambdas and other
>> function objects as the operation being applied to the set bit indices. Some
>> for-loops using BitMap::get_next_one_offset have been changed to use
>> BitMap::iterate with a lambda.
>> 
>> (One reason for changing the for-loops is that I'm considering a change to the
>> get_next_one_offset API, and reducing the number of direct uses will simplify
>> that.)
>> 
>> For convenience, the function can either return void (always iterate over the
>> whole range) or bool (stop iteration if returns false).  Iteration using
>> closure objects invoked via a do_bit member function are now implemented by
>> being wrapped in a lambda, so get the same convenience.  (Though, of course,
>> if the closure is derived from BitMapClosure then do_bit returns bool.)
>> 
>> The unit tests are written as "early" tests, not requiring an initialized VM.
>> They also avoid any C heap allocation (even though C heap allocation has very
>> early support). This is done to minimize the requirements for running the
>> tests, since BitMap is used in a lot of places. This attempts to run these
>> tests before uses. (Yes, I know about JDK-8257226; maybe that will be fixed
>> someday.) (Some existing BitMap gtests should be modified to do similarly; see
>> JDK-8303636.)
>> 
>> Testing:
>> mach5 tier1-7
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve description of iterate

Thanks for doing this change. This aligns well with what we currently have in the Generational ZGC repository.

I have one style comment that I think could help the readability of the code.

src/hotspot/share/utilities/bitMap.inline.hpp line 273:

> 271:     }
> 272:   }
> 273: }

IMHO, this is an eyesore that I prefer if it could be hidden away a bit. Could we create an `invoke` function that that calls this, and change the code to:

template <typename Function>
inline bool BitMap::iterate(Function function, idx_t beg, idx_t end) const {
  for (idx_t index = beg; true; ++index) {
    index = get_next_one_offset(index, end);
    if (index >= end) {
      return true;
    } else if (!invoke(function, index)) {
      return false;
    }
  }
}


And also add a comment why we need IterateInvoker?

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

Changes requested by stefank (Reviewer).

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

From duke at openjdk.org  Tue Mar  7 08:51:53 2023
From: duke at openjdk.org (Jan Kratochvil)
Date: Tue, 7 Mar 2023 08:51:53 GMT
Subject: RFR: 8302191: Performance degradation for float/double modulo on
 Linux [v11]
In-Reply-To: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
References: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
Message-ID: <l8C8ei0a9cA9Z8q8Eppac-akguhejxvLI4F5C5ellUQ=.6fc61dd7-c5b4-486b-a4d1-6b06d87485c5@github.com>

> I have OCA already processed/approved. I am not Author but my Author request is being processed these days (sent to Rob McKenna).
> I did regression test x86_64 OpenJDK-8. I will leave other regression testing on GHA.
> The patch (and former GCC performance regression) affects only x86_64+i686.

Jan Kratochvil 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 11 additional commits since the last revision:

 - Fix #endif comment - found by dholmes-ora.
 - Merge branch 'master' into modulo
 - Fix win32 broken build.
 - Merge remote-tracking branch 'origin/master' into modulo
 - Always include the _WIN64 workaround - a review by dholmes-ora.
 - Remove comments to be moved to JBS (Bug System) - a review by jddarcy.
 - Uppercase L - a review by turbanoff.
 - Fix copyright author.
 - Fix WIN32 vs. WIN64.
 - Update according to the upstream review by David Holmes.
 - ... and 1 more: https://git.openjdk.org/jdk/compare/b7d54b25...e4ff04dc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12508/files
  - new: https://git.openjdk.org/jdk/pull/12508/files/3e1c05d0..e4ff04dc

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

  Stats: 9028 lines in 352 files changed: 6228 ins; 1738 del; 1062 mod
  Patch: https://git.openjdk.org/jdk/pull/12508.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12508/head:pull/12508

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

From duke at openjdk.org  Tue Mar  7 08:52:01 2023
From: duke at openjdk.org (Jan Kratochvil)
Date: Tue, 7 Mar 2023 08:52:01 GMT
Subject: RFR: 8302191: Performance degradation for float/double modulo on
 Linux [v10]
In-Reply-To: <gnj0nIACHh3hKqsVaMDIL5aziqG80_8pwjFYpulJ-mA=.57bcad08-cf2f-499f-9ba1-cdcd20dedc3b@github.com>
References: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
 <BZzGkFY8NqP3p7n2bpwgzx2d36xFsY2jDPHIw-g6qyg=.5a908fbb-047f-4145-9827-38aa10a0c30a@github.com>
 <gnj0nIACHh3hKqsVaMDIL5aziqG80_8pwjFYpulJ-mA=.57bcad08-cf2f-499f-9ba1-cdcd20dedc3b@github.com>
Message-ID: <DSJqDIe_GEzL-4DgjBNLMW8tvvPUWXOnJi-7F2LIj0o=.e61a4c4e-76a2-480d-883a-bde7f767ce0f@github.com>

On Tue, 7 Mar 2023 01:45:50 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix win32 broken build.
>
> src/hotspot/share/runtime/sharedRuntime.cpp line 238:
> 
>> 236: #endif
>> 237: 
>> 238: #if !defined(TARGET_COMPILER_gcc) || defined(_WIN64)
> 
> That is the wrong condition - it would activate for any non-Windows, non-gcc compiler. This code is only for _WIN64 is it not? regardless of the (theoretical) compiler used on win64?

For non-Windows non-gcc compiler it will use:
>   return ((jfloat)fmod((double)x,(double)y));

Which I find correct.

> src/hotspot/share/runtime/sharedRuntime.cpp line 272:
> 
>> 270: #endif
>> 271: JRT_END
>> 272: #endif // !X86 || _WIN64
> 
> !X86 ???

True, thanks for finding it.

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

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

From rehn at openjdk.org  Tue Mar  7 09:20:18 2023
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 7 Mar 2023 09:20:18 GMT
Subject: RFR: 8300926: Several startup regressions ~6-70% in 21-b6 all
 platforms [v6]
In-Reply-To: <u1RGrj1z-aWY4iTnvUHHv6ulbCHoYrlob9HaccSEW08=.20c28eba-06ac-4d41-a3be-1ebc8e2c9ab7@github.com>
References: <yAP6c7wzGguBfKuzvbjMZdnaqydAz4PFn0pgR1UGj9s=.ce872f5d-3f7a-4e24-99d5-da5e80855ea4@github.com>
 <nXKSskpVRVCjCKFaz5S00u1LZXlpsMzbxmCzFfyZFcY=.0d2f92c8-4afc-43eb-a818-86f0bc50e03a@github.com>
 <u1RGrj1z-aWY4iTnvUHHv6ulbCHoYrlob9HaccSEW08=.20c28eba-06ac-4d41-a3be-1ebc8e2c9ab7@github.com>
Message-ID: <8-cfqT24ZTPwdTUlHSKMueLwMz2g3y9Qc8rGMPPttvU=.5e6c3c63-75fe-42fd-ab72-1f2f766a1a4e@github.com>

On Mon, 27 Feb 2023 00:29:26 GMT, David Holmes <dholmes at openjdk.org> wrote:

> In `ciEnv::register_method` we take the `Compile_lock` to ensure `add_to_hierarchy` can't run:
> 
> ```
>     // Prevent SystemDictionary::add_to_hierarchy from running
>     // and invalidating our dependencies until we install this method.
>     // No safepoints are allowed. Otherwise, class redefinition can occur in between.
>     MutexLocker ml(Compile_lock);
>     NoSafepointVerifier nsv;
> ```
> 
> does moving the deopt outside of the `Compile_lock` affect that?

The class hierarchy is still handled inside the Compile_lock, so that comment is still true.
The deopt is still done inside _init_monitor during classloading, which means no-one can create such object until deopt is completed.

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

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

From rehn at openjdk.org  Tue Mar  7 09:26:36 2023
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 7 Mar 2023 09:26:36 GMT
Subject: RFR: 8300926: Several startup regressions ~6-70% in 21-b6 all
 platforms [v7]
In-Reply-To: <cJFnZXJ-hmObxgs9sB-wzy6RMJnqEoVuQjcR8gvsyc4=.61c5786a-c392-4c57-9b40-3e8a15241ade@github.com>
References: <yAP6c7wzGguBfKuzvbjMZdnaqydAz4PFn0pgR1UGj9s=.ce872f5d-3f7a-4e24-99d5-da5e80855ea4@github.com>
 <cJFnZXJ-hmObxgs9sB-wzy6RMJnqEoVuQjcR8gvsyc4=.61c5786a-c392-4c57-9b40-3e8a15241ade@github.com>
Message-ID: <sDREtDy1vLRhRNyKoH8-Rgp4EO8UIb26sGhGF4zQavc=.0444bcd0-0596-43ac-94b6-ab8371d22556@github.com>

On Tue, 7 Mar 2023 08:25:06 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi all, please consider.
>> 
>> The original issue was when thread 1 asked to deopt nmethod set X and thread 2 asked for the same or a subset of X.
>> All method will already be marked, but the actual deoptimizing, not entrant, patching PC on stacks and patching post call nops, was not done yet. Which meant thread 2 could 'pass' thread 1.
>> Most places did deopt under Compile_lock, thus this is not an issue, but WB and clearCallSiteContext do not.
>> 
>> Since a handshakes may take long before completion and Compile_lock is used for so much more than deopts.
>> The fix in https://bugs.openjdk.org/browse/JDK-8299074 instead always emitted a handshake even when everything was already marked. (instead of adding Compile_lock to all places)
>> 
>> This turnout to be problematic in the startup, for example the number of deopt handshakes in jetty dry run startup went from 5 to 39 handshakes.
>> 
>> This fix first adds a barrier for which you do not pass until the requested deopts have happened and it coalesces the handshakes.
>> Secondly it moves handshakes part out of the Compile_lock where it is possible.
>> 
>> Which means we fix the performance bug and we reduce the contention on Compile_lock, meaning higher throughput in compiler and things such as class-loading.
>> 
>> It passes t1-t7 with flying colours! t8 still not completed and I'm redoing some testing due to last minute simplifications.
>> 
>> Thanks, Robbin
>
> Robbin Ehn 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 'master' into 8300926
>  - Comment fixes
>  - Include/fwd fixes
>  - More review fixes
>  - Coleen fix
>  - Review fixes 2
>  - Review fixes
>  - Fixed WS
>  - Deopt scopes

`vmClasses::resolve_shared_class`
It's only an micro-optimization to remove lock, since we are single-threaded when this code runs.

The calls above:
`dictionary->add_klass`
`InstanceKlass::restore_unshareable_info`
can also grab locks.

Since we pass all tests and other paths may take locks I'm not concerned.

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

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

From kbarrett at openjdk.org  Tue Mar  7 09:46:09 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 7 Mar 2023 09:46:09 GMT
Subject: RFR: 8303621: BitMap::iterate should support lambdas and other
 function objects [v3]
In-Reply-To: <G6DDCDP5PMEOH43G8GNeamEnSMNO_4gMsqQ_zuTUZA8=.1608a894-0707-4d87-b022-e7ee318b69f6@github.com>
References: <G6DDCDP5PMEOH43G8GNeamEnSMNO_4gMsqQ_zuTUZA8=.1608a894-0707-4d87-b022-e7ee318b69f6@github.com>
Message-ID: <324vpJnVkjaUEzKkmC0NSy2PbjrOFfTkH5WhiKf9-b4=.0fb689d0-875b-4761-9743-db3dbf2f483f@github.com>

> Please review this enhancement of BitMap::iterate to support lambdas and other
> function objects as the operation being applied to the set bit indices. Some
> for-loops using BitMap::get_next_one_offset have been changed to use
> BitMap::iterate with a lambda.
> 
> (One reason for changing the for-loops is that I'm considering a change to the
> get_next_one_offset API, and reducing the number of direct uses will simplify
> that.)
> 
> For convenience, the function can either return void (always iterate over the
> whole range) or bool (stop iteration if returns false).  Iteration using
> closure objects invoked via a do_bit member function are now implemented by
> being wrapped in a lambda, so get the same convenience.  (Though, of course,
> if the closure is derived from BitMapClosure then do_bit returns bool.)
> 
> The unit tests are written as "early" tests, not requiring an initialized VM.
> They also avoid any C heap allocation (even though C heap allocation has very
> early support). This is done to minimize the requirements for running the
> tests, since BitMap is used in a lot of places. This attempts to run these
> tests before uses. (Yes, I know about JDK-8257226; maybe that will be fixed
> someday.) (Some existing BitMap gtests should be modified to do similarly; see
> JDK-8303636.)
> 
> Testing:
> mach5 tier1-7

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 five additional commits since the last revision:

 - stefank review
 - Merge branch 'master' into lambda-iterate
 - improve description of iterate
 - use iterate with lambda
 - bitmap iteration supports lambda

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12876/files
  - new: https://git.openjdk.org/jdk/pull/12876/files/a1befdf3..4c03ae1b

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

  Stats: 6931 lines in 112 files changed: 4764 ins; 1389 del; 778 mod
  Patch: https://git.openjdk.org/jdk/pull/12876.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12876/head:pull/12876

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

From tschatzl at openjdk.org  Tue Mar  7 09:57:19 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 7 Mar 2023 09:57:19 GMT
Subject: RFR: 8191565: Last-ditch Full GC should also move humongous
 objects [v2]
In-Reply-To: <zBpBWEG2BUS8-FIZ1V-JRiq1x8yifAGRQL11KSZSilo=.eaa8371b-a3cf-4acc-a7d6-28e9d8945444@github.com>
References: <58l059EvQI6HNQyjUYSGYEWt6x-c1yvtmfX1QWfinH8=.87517ba1-ec81-4b9f-a41b-b05c8d33cf3d@github.com>
 <zBpBWEG2BUS8-FIZ1V-JRiq1x8yifAGRQL11KSZSilo=.eaa8371b-a3cf-4acc-a7d6-28e9d8945444@github.com>
Message-ID: <YaSiAK4WinF0FNK0RQWfu3GBKVdwimwnb-fvCOOyMlM=.ca69b33b-a307-4147-9dea-af9d6b03e69d@github.com>

On Mon, 6 Mar 2023 10:22:27 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi All,
>> 
>> Please review this change to move humongous regions during the Last-Ditch full gc ( on `do_maximal_compaction`). This change will enable G1 to avoid encountering Out-Of-Memory errors that may occur due to the fragmentation of memory regions caused by the allocation of large memory blocks.
>> 
>> Here's how it works: At the end of `phase2_prepare_compaction`, G1 performs a serial compaction process for regular objects, which results in the heap being divided into two parts. The first part is a densely populated prefix that contains all the regular objects that have been moved. The second part consists of the remaining heap space, which may contain free regions, uncommitted regions, and regions that are not compacting. By moving/compacting the humongous objects in the second part of the heap closer to the dense prefix, G1 reduces the region fragmentation and avoids running into OOM errors.
>> 
>> We have enabled for G1 the Jtreg test that was previously used only for Shenandoah to test such workload. 
>> 
>> Testing: Tier 1-3
>
> Ivan Walulya has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Refactor resetting humongous metadata
>  - Thomas review

Looks good.

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

Marked as reviewed by tschatzl (Reviewer).

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

From kbarrett at openjdk.org  Tue Mar  7 09:57:48 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 7 Mar 2023 09:57:48 GMT
Subject: RFR: 8303621: BitMap::iterate should support lambdas and other
 function objects [v4]
In-Reply-To: <G6DDCDP5PMEOH43G8GNeamEnSMNO_4gMsqQ_zuTUZA8=.1608a894-0707-4d87-b022-e7ee318b69f6@github.com>
References: <G6DDCDP5PMEOH43G8GNeamEnSMNO_4gMsqQ_zuTUZA8=.1608a894-0707-4d87-b022-e7ee318b69f6@github.com>
Message-ID: <Bzi9qOLrAGaOqSctAgzSxJeBjhnft4NKNp5tsFl1sy4=.1bb49c44-abdf-4b8a-8c87-a76178688449@github.com>

> Please review this enhancement of BitMap::iterate to support lambdas and other
> function objects as the operation being applied to the set bit indices. Some
> for-loops using BitMap::get_next_one_offset have been changed to use
> BitMap::iterate with a lambda.
> 
> (One reason for changing the for-loops is that I'm considering a change to the
> get_next_one_offset API, and reducing the number of direct uses will simplify
> that.)
> 
> For convenience, the function can either return void (always iterate over the
> whole range) or bool (stop iteration if returns false).  Iteration using
> closure objects invoked via a do_bit member function are now implemented by
> being wrapped in a lambda, so get the same convenience.  (Though, of course,
> if the closure is derived from BitMapClosure then do_bit returns bool.)
> 
> The unit tests are written as "early" tests, not requiring an initialized VM.
> They also avoid any C heap allocation (even though C heap allocation has very
> early support). This is done to minimize the requirements for running the
> tests, since BitMap is used in a lot of places. This attempts to run these
> tests before uses. (Yes, I know about JDK-8257226; maybe that will be fixed
> someday.) (Some existing BitMap gtests should be modified to do similarly; see
> JDK-8303636.)
> 
> Testing:
> mach5 tier1-7

Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:

  convert to bool rather than calling RT::operator!

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12876/files
  - new: https://git.openjdk.org/jdk/pull/12876/files/4c03ae1b..83de109a

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

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

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

From kbarrett at openjdk.org  Tue Mar  7 10:01:47 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 7 Mar 2023 10:01:47 GMT
Subject: RFR: 8303621: BitMap::iterate should support lambdas and other
 function objects [v2]
In-Reply-To: <UJgT7R2E2pWBIHrSfknknUjpRe6lxxSkdjbvNcHMuGc=.d7cd49ee-c438-4ca5-92aa-07785f888ec4@github.com>
References: <G6DDCDP5PMEOH43G8GNeamEnSMNO_4gMsqQ_zuTUZA8=.1608a894-0707-4d87-b022-e7ee318b69f6@github.com>
 <CmS2TJp8CqKBnTMA0NAPRTR3InnCUUWsf3ykV-VQWZI=.6af78463-cdc3-4142-b81b-379e43a4ac1f@github.com>
 <UJgT7R2E2pWBIHrSfknknUjpRe6lxxSkdjbvNcHMuGc=.d7cd49ee-c438-4ca5-92aa-07785f888ec4@github.com>
Message-ID: <SM6NXyyjWaZvd8cvhkZGPZz_tEffotTE_Vv4mNWcEzo=.58b170a3-02b9-492c-ad21-8e59d30e3c72@github.com>

On Tue, 7 Mar 2023 07:39:50 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   improve description of iterate
>
> src/hotspot/share/utilities/bitMap.inline.hpp line 273:
> 
>> 271:     }
>> 272:   }
>> 273: }
> 
> IMHO, this is an eyesore that I prefer if it could be hidden away a bit. Could we create an `invoke` function that that calls this, and change the code to:
> 
> template <typename Function>
> inline bool BitMap::iterate(Function function, idx_t beg, idx_t end) const {
>   for (idx_t index = beg; true; ++index) {
>     index = get_next_one_offset(index, end);
>     if (index >= end) {
>       return true;
>     } else if (!invoke(function, index)) {
>       return false;
>     }
>   }
> }
> 
> 
> And also add a comment why we need IterateInvoker?

I added a local function object so that template clutter wasn't all right in the middle of the function.
Making it a member function instead seemed to just push around the deck chairs.
Added comment, and also fixed a lurking, probably never to be hit, bug that we were stopping early if
ReturnType::operator! returned true, rather than if the converted to bool result was false.

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

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

From ihse at openjdk.org  Tue Mar  7 11:19:08 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 7 Mar 2023 11:19:08 GMT
Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments
 [v2]
In-Reply-To: <cwRZFQxyddrtPWS__nVK0l1Lu-dL3lnlR3rODiLfncA=.2f5b214e-9ae7-492a-b09a-81ef4077a26e@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
 <cwRZFQxyddrtPWS__nVK0l1Lu-dL3lnlR3rODiLfncA=.2f5b214e-9ae7-492a-b09a-81ef4077a26e@github.com>
Message-ID: <jtMAFBGGsxnmsPk8rzwnle3YNCoW9AMBfy69IAW5jT0=.2980eb41-64af-4b4b-8826-86f5a6ea6477@github.com>

On Mon, 6 Mar 2023 20:22:48 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
>> 
>> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
>> 
>> 
>>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>>     @@ -17084,7 +17084,7 @@
>>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>>      <div class="block"><code>readObject</code> is called to restore the state of the
>>     - (@code BasicPermission} from a stream.</div>
>>     + <code>BasicPermission</code> from a stream.</div>
>>      <dl class="notes">
>>      <dt>Parameters:</dt>
>>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
>> 
>> Notes
>> -----
>> 
>> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
>> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
>> * I will update copyright years after (and if) the fix had been approved, as required.
>
> Pavel Rappo 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 8303480
>  - Initial commit

Marked as reviewed by ihse (Reviewer).

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

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

From kbarrett at openjdk.org  Tue Mar  7 12:08:36 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 7 Mar 2023 12:08:36 GMT
Subject: RFR: 8303621: BitMap::iterate should support lambdas and other
 function objects [v2]
In-Reply-To: <SM6NXyyjWaZvd8cvhkZGPZz_tEffotTE_Vv4mNWcEzo=.58b170a3-02b9-492c-ad21-8e59d30e3c72@github.com>
References: <G6DDCDP5PMEOH43G8GNeamEnSMNO_4gMsqQ_zuTUZA8=.1608a894-0707-4d87-b022-e7ee318b69f6@github.com>
 <CmS2TJp8CqKBnTMA0NAPRTR3InnCUUWsf3ykV-VQWZI=.6af78463-cdc3-4142-b81b-379e43a4ac1f@github.com>
 <UJgT7R2E2pWBIHrSfknknUjpRe6lxxSkdjbvNcHMuGc=.d7cd49ee-c438-4ca5-92aa-07785f888ec4@github.com>
 <SM6NXyyjWaZvd8cvhkZGPZz_tEffotTE_Vv4mNWcEzo=.58b170a3-02b9-492c-ad21-8e59d30e3c72@github.com>
Message-ID: <M27zu2xmgsZBQwgOjBzRXfqWbSVBLY3FldICKmGIKCw=.07b9779b-5f59-4079-b18d-ec95b73dae5b@github.com>

On Tue, 7 Mar 2023 09:58:24 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> src/hotspot/share/utilities/bitMap.inline.hpp line 273:
>> 
>>> 271:     }
>>> 272:   }
>>> 273: }
>> 
>> IMHO, this is an eyesore that I prefer if it could be hidden away a bit. Could we create an `invoke` function that that calls this, and change the code to:
>> 
>> template <typename Function>
>> inline bool BitMap::iterate(Function function, idx_t beg, idx_t end) const {
>>   for (idx_t index = beg; true; ++index) {
>>     index = get_next_one_offset(index, end);
>>     if (index >= end) {
>>       return true;
>>     } else if (!invoke(function, index)) {
>>       return false;
>>     }
>>   }
>> }
>> 
>> 
>> And also add a comment why we need IterateInvoker?
>
> I added a local function object so that template clutter wasn't all right in the middle of the function.
> Making it a member function instead seemed to just push around the deck chairs.
> Added comment, and also fixed a lurking, probably never to be hit, bug that we were stopping early if
> ReturnType::operator! returned true, rather than if the converted to bool result was false.

Here's an alternative, using member function templates instead of the
partially specialized `IterateInvoker` function object. This doesn't seem
obviously better to me. Other ideas I looked at involved messy SFINAE, some
with trailing return types (a not yet approved for HotSpot C++11 feature).


template<typename Function, typename Dispatch>
static bool iterate_invoke_aux(Function function, idx_t index, Dispatch*) {
  return function(index);
}

template<typename Function>
static bool iterate_invoke_aux(Function function, idx_t index, void*) {
  function(index);
  return true;
}

template<typename Function>
static bool iterate_invoke(Function function, idx_t index) {
  using ReturnType = decltype(function(index));
  return iterate_invoke_aux(function, index, static_cast<ReturnType*>(nullptr));
}

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

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

From dholmes at openjdk.org  Tue Mar  7 12:18:06 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 7 Mar 2023 12:18:06 GMT
Subject: RFR: 8302191: Performance degradation for float/double modulo on
 Linux [v10]
In-Reply-To: <DSJqDIe_GEzL-4DgjBNLMW8tvvPUWXOnJi-7F2LIj0o=.e61a4c4e-76a2-480d-883a-bde7f767ce0f@github.com>
References: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
 <BZzGkFY8NqP3p7n2bpwgzx2d36xFsY2jDPHIw-g6qyg=.5a908fbb-047f-4145-9827-38aa10a0c30a@github.com>
 <gnj0nIACHh3hKqsVaMDIL5aziqG80_8pwjFYpulJ-mA=.57bcad08-cf2f-499f-9ba1-cdcd20dedc3b@github.com>
 <DSJqDIe_GEzL-4DgjBNLMW8tvvPUWXOnJi-7F2LIj0o=.e61a4c4e-76a2-480d-883a-bde7f767ce0f@github.com>
Message-ID: <xB4lba5hPDrZG_aAxO-rQK4_v20wZdywM-UejKkikjY=.c2cc1f9f-a2fb-4fd9-8eda-e87d5a45de81@github.com>

On Tue, 7 Mar 2023 08:47:21 GMT, Jan Kratochvil <duke at openjdk.org> wrote:

>> src/hotspot/share/runtime/sharedRuntime.cpp line 238:
>> 
>>> 236: #endif
>>> 237: 
>>> 238: #if !defined(TARGET_COMPILER_gcc) || defined(_WIN64)
>> 
>> That is the wrong condition - it would activate for any non-Windows, non-gcc compiler. This code is only for _WIN64 is it not? regardless of the (theoretical) compiler used on win64?
>
> For non-Windows non-gcc compiler it will use:
>>   return ((jfloat)fmod((double)x,(double)y));
> 
> Which I find correct.

Sorry my mistake.

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

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

From stefank at openjdk.org  Tue Mar  7 12:25:51 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 7 Mar 2023 12:25:51 GMT
Subject: RFR: 8303621: BitMap::iterate should support lambdas and other
 function objects [v4]
In-Reply-To: <Bzi9qOLrAGaOqSctAgzSxJeBjhnft4NKNp5tsFl1sy4=.1bb49c44-abdf-4b8a-8c87-a76178688449@github.com>
References: <G6DDCDP5PMEOH43G8GNeamEnSMNO_4gMsqQ_zuTUZA8=.1608a894-0707-4d87-b022-e7ee318b69f6@github.com>
 <Bzi9qOLrAGaOqSctAgzSxJeBjhnft4NKNp5tsFl1sy4=.1bb49c44-abdf-4b8a-8c87-a76178688449@github.com>
Message-ID: <Cy7FJLYR_qAu0oci-WMsVtHnDcE2Wxn0j8myS8G47sc=.264eb941-a46e-4181-9a22-dccdb3721a01@github.com>

On Tue, 7 Mar 2023 09:57:48 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this enhancement of BitMap::iterate to support lambdas and other
>> function objects as the operation being applied to the set bit indices. Some
>> for-loops using BitMap::get_next_one_offset have been changed to use
>> BitMap::iterate with a lambda.
>> 
>> (One reason for changing the for-loops is that I'm considering a change to the
>> get_next_one_offset API, and reducing the number of direct uses will simplify
>> that.)
>> 
>> For convenience, the function can either return void (always iterate over the
>> whole range) or bool (stop iteration if returns false).  Iteration using
>> closure objects invoked via a do_bit member function are now implemented by
>> being wrapped in a lambda, so get the same convenience.  (Though, of course,
>> if the closure is derived from BitMapClosure then do_bit returns bool.)
>> 
>> The unit tests are written as "early" tests, not requiring an initialized VM.
>> They also avoid any C heap allocation (even though C heap allocation has very
>> early support). This is done to minimize the requirements for running the
>> tests, since BitMap is used in a lot of places. This attempts to run these
>> tests before uses. (Yes, I know about JDK-8257226; maybe that will be fixed
>> someday.) (Some existing BitMap gtests should be modified to do similarly; see
>> JDK-8303636.)
>> 
>> Testing:
>> mach5 tier1-7
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   convert to bool rather than calling RT::operator!

Thanks. That's a bit easier to read, for me at least.

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

Marked as reviewed by stefank (Reviewer).

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

From kbarrett at openjdk.org  Tue Mar  7 13:04:04 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 7 Mar 2023 13:04:04 GMT
Subject: RFR: 8303621: BitMap::iterate should support lambdas and other
 function objects [v2]
In-Reply-To: <xjwpw0XlA4OcU03etXEEaSL34nNwKh87R66yFThYLq4=.6c3bcb29-e200-45ba-a85c-28ba903df731@github.com>
References: <G6DDCDP5PMEOH43G8GNeamEnSMNO_4gMsqQ_zuTUZA8=.1608a894-0707-4d87-b022-e7ee318b69f6@github.com>
 <CmS2TJp8CqKBnTMA0NAPRTR3InnCUUWsf3ykV-VQWZI=.6af78463-cdc3-4142-b81b-379e43a4ac1f@github.com>
 <xjwpw0XlA4OcU03etXEEaSL34nNwKh87R66yFThYLq4=.6c3bcb29-e200-45ba-a85c-28ba903df731@github.com>
Message-ID: <GZZXLhjqqOxIhGtOGJ4yWwJ_mcDzpHfRK6c8Q3Ib-2Y=.bf04559c-bb81-4060-ad7a-b1841a5a537c@github.com>

On Mon, 6 Mar 2023 10:59:42 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   improve description of iterate
>
> Marked as reviewed by aboldtch (Committer).

Thanks for reviews @xmas92 , @tschatzl , and @stefank .

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

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

From kbarrett at openjdk.org  Tue Mar  7 13:04:07 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 7 Mar 2023 13:04:07 GMT
Subject: Integrated: 8303621: BitMap::iterate should support lambdas and other
 function objects
In-Reply-To: <G6DDCDP5PMEOH43G8GNeamEnSMNO_4gMsqQ_zuTUZA8=.1608a894-0707-4d87-b022-e7ee318b69f6@github.com>
References: <G6DDCDP5PMEOH43G8GNeamEnSMNO_4gMsqQ_zuTUZA8=.1608a894-0707-4d87-b022-e7ee318b69f6@github.com>
Message-ID: <VYNVEnkc4hkMw4CRPHvgIy13ExPdt_cYJMaTDyCsNTU=.3f85d837-7373-4e31-b5c0-de49730d898b@github.com>

On Mon, 6 Mar 2023 07:27:23 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this enhancement of BitMap::iterate to support lambdas and other
> function objects as the operation being applied to the set bit indices. Some
> for-loops using BitMap::get_next_one_offset have been changed to use
> BitMap::iterate with a lambda.
> 
> (One reason for changing the for-loops is that I'm considering a change to the
> get_next_one_offset API, and reducing the number of direct uses will simplify
> that.)
> 
> For convenience, the function can either return void (always iterate over the
> whole range) or bool (stop iteration if returns false).  Iteration using
> closure objects invoked via a do_bit member function are now implemented by
> being wrapped in a lambda, so get the same convenience.  (Though, of course,
> if the closure is derived from BitMapClosure then do_bit returns bool.)
> 
> The unit tests are written as "early" tests, not requiring an initialized VM.
> They also avoid any C heap allocation (even though C heap allocation has very
> early support). This is done to minimize the requirements for running the
> tests, since BitMap is used in a lot of places. This attempts to run these
> tests before uses. (Yes, I know about JDK-8257226; maybe that will be fixed
> someday.) (Some existing BitMap gtests should be modified to do similarly; see
> JDK-8303636.)
> 
> Testing:
> mach5 tier1-7

This pull request has now been integrated.

Changeset: 008c5eb4
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/008c5eb4dd40f93e9c7849bfc681d615ab29baad
Stats:     310 lines in 5 files changed: 268 ins; 8 del; 34 mod

8303621: BitMap::iterate should support lambdas and other function objects

Reviewed-by: aboldtch, tschatzl, stefank

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

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

From kbarrett at openjdk.org  Tue Mar  7 13:04:03 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 7 Mar 2023 13:04:03 GMT
Subject: RFR: 8303621: BitMap::iterate should support lambdas and other
 function objects [v5]
In-Reply-To: <G6DDCDP5PMEOH43G8GNeamEnSMNO_4gMsqQ_zuTUZA8=.1608a894-0707-4d87-b022-e7ee318b69f6@github.com>
References: <G6DDCDP5PMEOH43G8GNeamEnSMNO_4gMsqQ_zuTUZA8=.1608a894-0707-4d87-b022-e7ee318b69f6@github.com>
Message-ID: <T0C0V-SOk4vcNzAoUOaHovnyu-DSiV3SNY6o4TXYiXc=.9cb37556-69b3-471e-afa6-185687ea7d23@github.com>

> Please review this enhancement of BitMap::iterate to support lambdas and other
> function objects as the operation being applied to the set bit indices. Some
> for-loops using BitMap::get_next_one_offset have been changed to use
> BitMap::iterate with a lambda.
> 
> (One reason for changing the for-loops is that I'm considering a change to the
> get_next_one_offset API, and reducing the number of direct uses will simplify
> that.)
> 
> For convenience, the function can either return void (always iterate over the
> whole range) or bool (stop iteration if returns false).  Iteration using
> closure objects invoked via a do_bit member function are now implemented by
> being wrapped in a lambda, so get the same convenience.  (Though, of course,
> if the closure is derived from BitMapClosure then do_bit returns bool.)
> 
> The unit tests are written as "early" tests, not requiring an initialized VM.
> They also avoid any C heap allocation (even though C heap allocation has very
> early support). This is done to minimize the requirements for running the
> tests, since BitMap is used in a lot of places. This attempts to run these
> tests before uses. (Yes, I know about JDK-8257226; maybe that will be fixed
> someday.) (Some existing BitMap gtests should be modified to do similarly; see
> JDK-8303636.)
> 
> Testing:
> mach5 tier1-7

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 seven additional commits since the last revision:

 - Merge branch 'master' into lambda-iterate
 - convert to bool rather than calling RT::operator!
 - stefank review
 - Merge branch 'master' into lambda-iterate
 - improve description of iterate
 - use iterate with lambda
 - bitmap iteration supports lambda

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12876/files
  - new: https://git.openjdk.org/jdk/pull/12876/files/83de109a..83f8c567

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

  Stats: 85 lines in 3 files changed: 83 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12876.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12876/head:pull/12876

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

From coleenp at openjdk.org  Tue Mar  7 13:15:26 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 7 Mar 2023 13:15:26 GMT
Subject: RFR: 8302189: Mark assertion failures noreturn [v2]
In-Reply-To: <BMN3OJv9QTo0bNa_BvIMuldsCZDRD1-YjiN826iXbG0=.44fd41e9-ea55-437a-9c0a-294d5daaea71@github.com>
References: <4gLeUT6_5s6WpG-b-0146d490ZRgBq_JON1-5P3Wgtk=.e0bc3fd3-fce0-47b8-9478-1de796128731@github.com>
 <BMN3OJv9QTo0bNa_BvIMuldsCZDRD1-YjiN826iXbG0=.44fd41e9-ea55-437a-9c0a-294d5daaea71@github.com>
Message-ID: <wp2Iv20ECTSdPiRt4yokZQFWeeITLe4LNmJtlubWy20=.5c7bc3c5-2428-47c2-a5b4-c168bc3b515e@github.com>

On Sat, 4 Mar 2023 11:23:58 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Also 8302799: Refactor Debugging variable usage for noreturn crash reporting
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make Debugging::_enabled a nesting counter

Seems fine.  I'll test drive with the debug commands next time I need to use them but this is similar to to the changes I have in my private repos.  Thanks for keeping this functionality.

src/hotspot/share/utilities/debug.hpp line 108:

> 106: // because we need a fallback when we don't have any mechanism for detecting
> 107: // constant evaluation.
> 108: #if defined(TARGET_COMPILER_gcc) || defined(TARGET_COMPILER_xlc)

All this seems like it should go in COMPILER_HEADER(globalDefinitions.hpp) but since globalDefinitions.hpp includes debug.hpp, you can't do this.  Can we file an RFE to clean this up (if possible)?

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

Marked as reviewed by coleenp (Reviewer).

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

From rehn at openjdk.org  Tue Mar  7 13:47:55 2023
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 7 Mar 2023 13:47:55 GMT
Subject: RFR: 8300926: Several startup regressions ~6-70% in 21-b6 all
 platforms [v8]
In-Reply-To: <yAP6c7wzGguBfKuzvbjMZdnaqydAz4PFn0pgR1UGj9s=.ce872f5d-3f7a-4e24-99d5-da5e80855ea4@github.com>
References: <yAP6c7wzGguBfKuzvbjMZdnaqydAz4PFn0pgR1UGj9s=.ce872f5d-3f7a-4e24-99d5-da5e80855ea4@github.com>
Message-ID: <z7_2sNpjnL2JYEhq-L6S6VvxwrCEZlHX7EDZx4do_Dw=.783bbdcb-bc62-46f0-83a4-70e6785b9fe0@github.com>

> Hi all, please consider.
> 
> The original issue was when thread 1 asked to deopt nmethod set X and thread 2 asked for the same or a subset of X.
> All method will already be marked, but the actual deoptimizing, not entrant, patching PC on stacks and patching post call nops, was not done yet. Which meant thread 2 could 'pass' thread 1.
> Most places did deopt under Compile_lock, thus this is not an issue, but WB and clearCallSiteContext do not.
> 
> Since a handshakes may take long before completion and Compile_lock is used for so much more than deopts.
> The fix in https://bugs.openjdk.org/browse/JDK-8299074 instead always emitted a handshake even when everything was already marked. (instead of adding Compile_lock to all places)
> 
> This turnout to be problematic in the startup, for example the number of deopt handshakes in jetty dry run startup went from 5 to 39 handshakes.
> 
> This fix first adds a barrier for which you do not pass until the requested deopts have happened and it coalesces the handshakes.
> Secondly it moves handshakes part out of the Compile_lock where it is possible.
> 
> Which means we fix the performance bug and we reduce the contention on Compile_lock, meaning higher throughput in compiler and things such as class-loading.
> 
> It passes t1-t7 with flying colours! t8 still not completed and I'm redoing some testing due to last minute simplifications.
> 
> Thanks, Robbin

Robbin Ehn has updated the pull request incrementally with two additional commits since the last revision:

 - Grab lock so code() is stable
 - Non CHA based vtables fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12585/files
  - new: https://git.openjdk.org/jdk/pull/12585/files/16732f1d..be2d3b5e

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

  Stats: 19 lines in 2 files changed: 16 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12585.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12585/head:pull/12585

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

From rehn at openjdk.org  Tue Mar  7 13:47:58 2023
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 7 Mar 2023 13:47:58 GMT
Subject: RFR: 8300926: Several startup regressions ~6-70% in 21-b6 all
 platforms [v6]
In-Reply-To: <kKCcL0NUamcwIPSn698FOlgWzt_t9ZS-S_vL40m_oBQ=.3576009b-018b-453b-9094-1a14d4dd7578@github.com>
References: <yAP6c7wzGguBfKuzvbjMZdnaqydAz4PFn0pgR1UGj9s=.ce872f5d-3f7a-4e24-99d5-da5e80855ea4@github.com>
 <nXKSskpVRVCjCKFaz5S00u1LZXlpsMzbxmCzFfyZFcY=.0d2f92c8-4afc-43eb-a818-86f0bc50e03a@github.com>
 <kKCcL0NUamcwIPSn698FOlgWzt_t9ZS-S_vL40m_oBQ=.3576009b-018b-453b-9094-1a14d4dd7578@github.com>
Message-ID: <cOQK_PHlwAmLK6ZvZrrOVKgEPhN0O3YVQ_IPXndQv08=.69e9a65f-6219-4949-9904-c1f1ed4bf217@github.com>

On Mon, 6 Mar 2023 07:05:00 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Comment fixes
>>  - Include/fwd fixes
>
> src/hotspot/share/prims/whitebox.cpp line 798:
> 
>> 796:       result += mh->method_holder()->mark_osr_nmethods(&deopt_scope, mh());
>> 797:     } else if (mh->code() != nullptr) {
>> 798:       deopt_scope.mark(mh->code());
> 
> I was working on a patch based on top of this one and had a crash here.
> 
> The second call to `mh->code()` returned a `nullptr`. It looks racy to me and seems like the only thing protecting `CompileMethod::code()` is the `CompiledMethod_lock` which is not held here. 
> 
> Regardless `mh->code()` should probably only be loaded once. (Or at least not re-loaded after the nullptr check)

Fixed, thanks!

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

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

From coleenp at openjdk.org  Tue Mar  7 14:14:39 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 7 Mar 2023 14:14:39 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry
In-Reply-To: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
Message-ID: <LQTG-IYnef9srlK41aw_InVGTvihfRW2ez8deMPILoY=.efc03d45-0f5c-4d81-8c23-310c54969c07@github.com>

On Mon, 27 Feb 2023 21:37:34 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
> 
> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
> 
> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
> 
> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
> 
> This change supports the following platforms: x86, aarch64, PPC, and RISCV

This looks really good.  I noted a few changes and questions.

src/hotspot/cpu/ppc/templateTable_ppc_64.cpp line 53:

> 51: 
> 52: #undef __
> 53: #define __ Disassembler::hook<InterpreterMacroAssembler>(__FILE__, __LINE__, _masm)->

What is this?  Is this something useful for debugging the template interpreter?  Probably doesn't belong with this change but might be nice to have (?) @reinrich

src/hotspot/cpu/x86/templateTable_x86.cpp line 2801:

> 2799:                                                bool is_invokevirtual,
> 2800:                                                bool is_invokevfinal, /*unused*/
> 2801:                                                bool is_invokedynamic /*unused*/) {

I assume you have to keep this parameter for the platform that doesn't still have this change (s390)?

src/hotspot/share/cds/classListParser.cpp line 590:

> 588:           // resolve it
> 589:           Handle recv;
> 590:           LinkResolver::resolve_invoke(info, recv, pool, ConstantPool::encode_invokedynamic_index(indy_index), Bytecodes::_invokedynamic, CHECK);

nit: can you reformat so the line isn't so long?

src/hotspot/share/ci/ciReplay.cpp line 419:

> 417:       be used to avoid multiple blocks of similar code. When CPCE is obsoleted
> 418:       these can be removed
> 419:       */

I don't know if you really need this comment.  If so, use // style instead.

src/hotspot/share/ci/ciReplay.cpp line 453:

> 451:         if (!parse_terminator()) {
> 452:           report_error("no dynamic invoke found");
> 453:           return NULL;

nullptr not NULL.

src/hotspot/share/interpreter/rewriter.hpp line 143:

> 141:     assert(ref_index >= _resolved_reference_limit, "");
> 142:     if (_pool->tag_at(cp_index).value() != JVM_CONSTANT_InvokeDynamic) {
> 143:       _invokedynamic_references_map.at_put_grow(ref_index, cache_index, -1);

I think you might need to rename _invokedynamic_references_map variable name to _invokehandle_references_map with this change also.  This will be confusng.

src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 639:

> 637:   int indy_index = -1;
> 638:   for (int i = 0; i < cp->resolved_indy_entries_length(); i++) {
> 639:     tty->print_cr("Index: %d", cp->resolved_indy_entry_at(i)->constant_pool_index());

Looks like some debugging left in.

src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 1529:

> 1527:   if (cp_cache_entry->is_resolved(Bytecodes::_invokedynamic)) {
> 1528:     return Bytecodes::_invokedynamic;
> 1529:   }

This seems like it should be removed?

src/hotspot/share/oops/cpCache.cpp line 727:

> 725:   set_reference_map(nullptr);
> 726: #if INCLUDE_CDS
> 727:   if (_initial_entries != nullptr) {

@iklam with moving invokedynamic entries out, do you still need to save initialized entries ?  Does invokehandle need this? (Should have separate RFE if more cleanup is possible)

src/hotspot/share/oops/resolvedIndyEntry.hpp line 26:

> 24: 
> 25: #ifndef SHARE_OOPS_ResolvedIndyEntry_HPP
> 26: #define SHARE_OOPS_ResolvedIndyEntry_HPP

Make this all capital letters

src/hotspot/share/oops/resolvedIndyEntry.hpp line 71:

> 69: 
> 70:   // Bit shift to get flags
> 71:   // Note: Only one flag exists at the moment but more could be added

Actually two flags - resolution_failed too.

src/hotspot/share/oops/resolvedIndyEntry.hpp line 87:

> 85:   bool is_vfinal()               const { return false;                                            }
> 86:   bool is_final()                const { return false;                                            }
> 87:   bool has_local_signature()     const { return true;                                             }

The closed } don't need to be aligned.

src/hotspot/share/oops/resolvedIndyEntry.hpp line 111:

> 109:     _return_type = return_type;
> 110:     set_flags(has_appendix);
> 111:     Atomic::release_store(&_method, m);

Add a comment like // set this last.  The method is read lock free from the entry and if set, indicates the rest of the resolution information is valid.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ResolvedIndyArray.java line 35:

> 33: import sun.jvm.hotspot.types.WrongTypeException;
> 34: import sun.jvm.hotspot.utilities.GenericArray;
> 35: import sun.jvm.hotspot.utilities.Observable;

Do you need all of these imports ?

src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotConstantPool.java line 935:

> 933:                 /*if (isInvokedynamicIndex(cpi)) {
> 934:                     compilerToVM().resolveInvokeDynamicInPool(this, cpi);
> 935:                 }*/

Is there something to fix here?

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

Changes requested by coleenp (Reviewer).

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

From mbaesken at openjdk.org  Tue Mar  7 14:29:47 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 7 Mar 2023 14:29:47 GMT
Subject: RFR: JDK-8302989: Add missing INCLUDE_CDS checks [v4]
In-Reply-To: <dkwL4nBOs2Sh6R-tiu0xVFTioOXKZDXInHk6GW3BpWE=.c5d327fc-9e63-4c9d-b223-ea7aa8753b80@github.com>
References: <kBV8fNo_CWJL2MoXgAckFhuAFgQ3RGZjFKAKnl8xfV8=.233bb652-8508-4065-92ea-7873b1c765f3@github.com>
 <dkwL4nBOs2Sh6R-tiu0xVFTioOXKZDXInHk6GW3BpWE=.c5d327fc-9e63-4c9d-b223-ea7aa8753b80@github.com>
Message-ID: <deBUxZbZ8FI9ENyfv-xwSrdfWhJVe-kT2VBxokj-_wA=.f7f83ce4-34cd-42d8-a30e-bad77676d802@github.com>

On Fri, 3 Mar 2023 08:55:07 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The cds only coding in hotspot is usually guarded with the INCLUDE_CDS macro so that it can be removed at compile time in case the correct configure flags are set.
>> However at some places INCLUDE_CDS is missing and should be added.
>> 
>> One question - should (additionally to the UseSharedSpaces code section)  the DumpSharedSpaces code sections be guarded as well with INCLUDE_CDS macros ?
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust arguments handling

Unfortunately with the latest revision of the patch, quite a few tests fail when the build is configured with `--disable-cds`  .
Seems those tests set various -Xshare options for some reason, especially  `-Xshare:off`  .

Failing tests (there might be a few more where the reason is not fully clear from the log)
jdk/jfr/event/runtime/TestMetaspaceAllocationFailure.java
Unrecognized option: -Xshare:off

sun/security/provider/X509Factory/BigCRL.java
Unrecognized option: -Xshare:off

java/lang/module/ModuleDescriptorHashCodeTest.java
Unrecognized option: -Xshare:off

java/math/BigInteger/largeMemory/DivisionOverflow.java
Unrecognized option: -Xshare:off

java/math/BigInteger/largeMemory/StringConstructorOverflow.java
Unrecognized option: -Xshare:off

runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java#id7
stderr content[Unrecognized option: -Xshare:dump

runtime/7158988/FieldMonitor.java
JavaTest Message: Test threw exception: java.lang.Error: Target VM failed to initialize: VM initialization failed for:

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

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

From mdoerr at openjdk.org  Tue Mar  7 14:33:22 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 7 Mar 2023 14:33:22 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v10]
In-Reply-To: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
Message-ID: <p_ABoD6hIcW7h2wMIFt8g-2eV3R2C1MRFXfyzwTHHRY=.85f79a58-723c-4175-a0b7-564ddaa06b18@github.com>

> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
> 
> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
> 
> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
> 
> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Will get addressed separately: [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
> 
> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
> 
> I had to make changes to shared code and code for other platforms:
> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit.

Martin Doerr 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 remote-tracking branch 'origin' into PPC64_Panama
 - Handle HFA corner cases with overlapping registers in Java.
 - Fix merge bug.
 - Merge branch 'master' into PPC64_Panama
 - Add test for HFA corner cases.
 - Minor cleanup.
 - HFA: Add support for nested structures. See JDK-8300294.
 - Remove size restriction for structs. Add TODO for Big Endian.
 - Clean fix for NativeMemorySegmentImpl issue with byteSize 0.
 - Initial Panama implementation.

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

Changes: https://git.openjdk.org/jdk/pull/12708/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=09
  Stats: 2287 lines in 59 files changed: 2157 ins; 16 del; 114 mod
  Patch: https://git.openjdk.org/jdk/pull/12708.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12708/head:pull/12708

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

From lucy at openjdk.org  Tue Mar  7 14:49:31 2023
From: lucy at openjdk.org (Lutz Schmidt)
Date: Tue, 7 Mar 2023 14:49:31 GMT
Subject: RFR: JDK-8303575: adjust Xen handling on Linux aarch64
In-Reply-To: <Pudap47AEtkkc8vtRirSNBUb4jdEHFIhhGd8IPEw0dg=.dc2f524d-7ade-49ff-b603-620adc3bcaf8@github.com>
References: <Pudap47AEtkkc8vtRirSNBUb4jdEHFIhhGd8IPEw0dg=.dc2f524d-7ade-49ff-b603-620adc3bcaf8@github.com>
Message-ID: <7Xly8bGJIWby8mvweZ_Qk8GE3LDpFZp2MwROEsDR6Yk=.119cdb2f-38bb-4782-957b-2d649f97a194@github.com>

On Fri, 3 Mar 2023 12:56:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> After [JDK-8301050](https://bugs.openjdk.org/browse/JDK-8301050) the Xen handling on aarch64 should be slightly adjusted.
> The output in VM_Version::print_platform_virtualization_info was missed and needs to be added for Xen.
> Additionally a new XenPVHVM virtualization type could be introduced because this describes the Xen on aarch64 better.
> See also https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/virtualization-on-arm-with-xen where the naming is used.

Looks good to me.

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

Marked as reviewed by lucy (Reviewer).

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

From rrich at openjdk.org  Tue Mar  7 15:08:12 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Tue, 7 Mar 2023 15:08:12 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry
In-Reply-To: <LQTG-IYnef9srlK41aw_InVGTvihfRW2ez8deMPILoY=.efc03d45-0f5c-4d81-8c23-310c54969c07@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <LQTG-IYnef9srlK41aw_InVGTvihfRW2ez8deMPILoY=.efc03d45-0f5c-4d81-8c23-310c54969c07@github.com>
Message-ID: <A_IUIYIKAh5BxaCSeoW_3afjPBsfh641ahYI-HfSwJ4=.ed14415f-4bcd-4d62-8cf6-e1d254839397@github.com>

On Tue, 7 Mar 2023 13:30:50 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
>> 
>> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
>> 
>> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
>> 
>> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
>> 
>> This change supports the following platforms: x86, aarch64, PPC, and RISCV
>
> src/hotspot/cpu/ppc/templateTable_ppc_64.cpp line 53:
> 
>> 51: 
>> 52: #undef __
>> 53: #define __ Disassembler::hook<InterpreterMacroAssembler>(__FILE__, __LINE__, _masm)->
> 
> What is this?  Is this something useful for debugging the template interpreter?  Probably doesn't belong with this change but might be nice to have (?) @reinrich

Yes this is really useful when debugging the template interpreter. It annotates the disassembly with the generator source code. It helped tracking down a bug in the ppc part oft this pr. Other platforms have it too.

Example:

invokedynamic  186 invokedynamic  [0x00003fff80075a00, 0x00003fff80075dc8]  968 bytes

--------------------------------------------------------------------------------
  0x00003fff80075a00:   std     r17,0(r15)                  ;;@FILE: src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp
                                                            ;; 2185:   aep = __ pc();  __ push_ptr();  __ b(L);
  0x00003fff80075a04:   addi    r15,r15,-8
  0x00003fff80075a08:   b       0x00003fff80075a40          ;; 2185:   aep = __ pc();  __ push_ptr();  __ b(L);
  0x00003fff80075a0c:   stfs    f15,0(r15)                  ;; 2186:   fep = __ pc();  __ push_f();    __ b(L);
  0x00003fff80075a10:   addi    r15,r15,-8
  0x00003fff80075a14:   b       0x00003fff80075a40          ;; 2186:   fep = __ pc();  __ push_f();    __ b(L);
  0x00003fff80075a18:   stfd    f15,-8(r15)                 ;; 2187:   dep = __ pc();  __ push_d();    __ b(L);
  0x00003fff80075a1c:   addi    r15,r15,-16
  0x00003fff80075a20:   b       0x00003fff80075a40          ;; 2187:   dep = __ pc();  __ push_d();    __ b(L);
  0x00003fff80075a24:   li      r0,0                        ;; 2188:   lep = __ pc();  __ push_l();    __ b(L);
  0x00003fff80075a28:   std     r0,0(r15)
  0x00003fff80075a2c:   std     r17,-8(r15)
  0x00003fff80075a30:   addi    r15,r15,-16
  0x00003fff80075a34:   b       0x00003fff80075a40          ;; 2188:   lep = __ pc();  __ push_l();    __ b(L);
  0x00003fff80075a38:   stw     r17,0(r15)                  ;; 2189:   __ align(32, 12, 24); // align L
                                                            ;; 2191:   iep = __ pc();  __ push_i();
  0x00003fff80075a3c:   addi    r15,r15,-8
  0x00003fff80075a40:   li      r21,1                       ;; 2192:   vep = __ pc();
                                                            ;; 2193:   __ bind(L);
                                                            ;;@FILE: src/hotspot/share/interpreter/templateInterpreterGenerator.cpp
                                                            ;;  366:   __ verify_FPU(1, t->tos_in());
                                                            ;;@FILE: src/hotspot/cpu/ppc/templateTable_ppc_64.cpp
                                                            ;; 2293:   __ load_resolved_indy_entry(cache, index);
  0x00003fff80075a44:   lwax    r21,r14,r21
  0x00003fff80075a48:   nand    r21,r21,r21
  0x00003fff80075a4c:   ld      r31,40(r27)
  0x00003fff80075a50:   rldicr  r21,r21,4,59
  0x00003fff80075a54:   addi    r21,r21,8
  0x00003fff80075a58:   add     r31,r31,r21
  0x00003fff80075a5c:   ld      r22,0(r31)                  ;; 2294:   __ ld_ptr(method, in_bytes(ResolvedIndyEntry::method_offset()), cache);
  0x00003fff80075a60:   cmpdi   r22,0                       ;; 2297:   __ cmpdi(CCR0, method, 0);
  0x00003fff80075a64:   bne-    0x00003fff80075b94          ;; 2298:   __ bne(CCR0, resolved);,bo=0b00100[no_hint]
  0x00003fff80075a68:   li      r4,186                      ;; 2304:   __ li(R4_ARG2, code);
  0x00003fff80075a6c:   ld      r11,0(r1)                   ;; 2305:   __ call_VM(noreg, entry, R4_ARG2, true);

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

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

From prappo at openjdk.org  Tue Mar  7 15:35:51 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 7 Mar 2023 15:35:51 GMT
Subject: Integrated: 8303480: Miscellaneous fixes to mostly invisible doc
 comments
In-Reply-To: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
Message-ID: <bX8VasBimwapkC8a4jdbxSSzCrgVWVZmukOp-odUBTs=.afe4dd0d-9ed0-4cd8-8b8d-92285c7d58bc@github.com>

On Thu, 2 Mar 2023 12:03:44 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
> 
> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
> 
> 
>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>     @@ -17084,7 +17084,7 @@
>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>      <div class="block"><code>readObject</code> is called to restore the state of the
>     - (@code BasicPermission} from a stream.</div>
>     + <code>BasicPermission</code> from a stream.</div>
>      <dl class="notes">
>      <dt>Parameters:</dt>
>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
> 
> Notes
> -----
> 
> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
> * I will update copyright years after (and if) the fix had been approved, as required.

This pull request has now been integrated.

Changeset: 45a616a8
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/45a616a891e4a4b0e77b1f2fa040522f4a99d172
Stats:     75 lines in 39 files changed: 0 ins; 0 del; 75 mod

8303480: Miscellaneous fixes to mostly invisible doc comments

Reviewed-by: mullan, prr, cjplummer, aivanov, jjg, lancea, rriggs, ihse

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

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

From rehn at openjdk.org  Tue Mar  7 16:42:47 2023
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 7 Mar 2023 16:42:47 GMT
Subject: RFR: 8300926: Several startup regressions ~6-70% in 21-b6 all
 platforms [v8]
In-Reply-To: <z7_2sNpjnL2JYEhq-L6S6VvxwrCEZlHX7EDZx4do_Dw=.783bbdcb-bc62-46f0-83a4-70e6785b9fe0@github.com>
References: <yAP6c7wzGguBfKuzvbjMZdnaqydAz4PFn0pgR1UGj9s=.ce872f5d-3f7a-4e24-99d5-da5e80855ea4@github.com>
 <z7_2sNpjnL2JYEhq-L6S6VvxwrCEZlHX7EDZx4do_Dw=.783bbdcb-bc62-46f0-83a4-70e6785b9fe0@github.com>
Message-ID: <YK_f2JtH6iU0WWr-PlGP9IRLPKgv7QsLtvYsHvx2atQ=.57bc24e7-fa81-41b9-8657-9fb657b2ae5e@github.com>

On Tue, 7 Mar 2023 13:47:55 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi all, please consider.
>> 
>> The original issue was when thread 1 asked to deopt nmethod set X and thread 2 asked for the same or a subset of X.
>> All method will already be marked, but the actual deoptimizing, not entrant, patching PC on stacks and patching post call nops, was not done yet. Which meant thread 2 could 'pass' thread 1.
>> Most places did deopt under Compile_lock, thus this is not an issue, but WB and clearCallSiteContext do not.
>> 
>> Since a handshakes may take long before completion and Compile_lock is used for so much more than deopts.
>> The fix in https://bugs.openjdk.org/browse/JDK-8299074 instead always emitted a handshake even when everything was already marked. (instead of adding Compile_lock to all places)
>> 
>> This turnout to be problematic in the startup, for example the number of deopt handshakes in jetty dry run startup went from 5 to 39 handshakes.
>> 
>> This fix first adds a barrier for which you do not pass until the requested deopts have happened and it coalesces the handshakes.
>> Secondly it moves handshakes part out of the Compile_lock where it is possible.
>> 
>> Which means we fix the performance bug and we reduce the contention on Compile_lock, meaning higher throughput in compiler and things such as class-loading.
>> 
>> It passes t1-t7 with flying colours! t8 still not completed and I'm redoing some testing due to last minute simplifications.
>> 
>> Thanks, Robbin
>
> Robbin Ehn has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Grab lock so code() is stable
>  - Non CHA based vtables fix

Running t1-t7, green so far.

I think I have address everything?

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

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

From prappo at openjdk.org  Tue Mar  7 15:35:51 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 7 Mar 2023 15:35:51 GMT
Subject: Integrated: 8303480: Miscellaneous fixes to mostly invisible doc
 comments
In-Reply-To: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
Message-ID: <bX8VasBimwapkC8a4jdbxSSzCrgVWVZmukOp-odUBTs=.afe4dd0d-9ed0-4cd8-8b8d-92285c7d58bc@github.com>

On Thu, 2 Mar 2023 12:03:44 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
> 
> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
> 
> 
>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>     @@ -17084,7 +17084,7 @@
>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>      <div class="block"><code>readObject</code> is called to restore the state of the
>     - (@code BasicPermission} from a stream.</div>
>     + <code>BasicPermission</code> from a stream.</div>
>      <dl class="notes">
>      <dt>Parameters:</dt>
>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
> 
> Notes
> -----
> 
> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
> * I will update copyright years after (and if) the fix had been approved, as required.

This pull request has now been integrated.

Changeset: 45a616a8
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/45a616a891e4a4b0e77b1f2fa040522f4a99d172
Stats:     75 lines in 39 files changed: 0 ins; 0 del; 75 mod

8303480: Miscellaneous fixes to mostly invisible doc comments

Reviewed-by: mullan, prr, cjplummer, aivanov, jjg, lancea, rriggs, ihse

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

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

From never at openjdk.org  Tue Mar  7 17:32:13 2023
From: never at openjdk.org (Tom Rodriguez)
Date: Tue, 7 Mar 2023 17:32:13 GMT
Subject: RFR: 8302452: [JVMCI] Export _poly1305_processBlocks,
 JfrThreadLocal fields to JVMCI compiler.
In-Reply-To: <ZaVZomCJPArZStkQXu7EMWCWeWHGyeuBEQPfSA4svmo=.0a0d5637-331d-4b01-aae4-352802975226@github.com>
References: <ZaVZomCJPArZStkQXu7EMWCWeWHGyeuBEQPfSA4svmo=.0a0d5637-331d-4b01-aae4-352802975226@github.com>
Message-ID: <KowkC48szdafmd_IF-i4-53YHXGjjJQuFZ4DEX7s26o=.3930a5eb-1682-4384-8266-a2e505fc9a25@github.com>

On Tue, 14 Feb 2023 15:13:05 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

> This PR allows JVMCI compiler intrinsics to reuse the _poly1305_processBlocks stub and to update JfrThreadLocal fields on `Thread.setCurrentThread` events.

Marked as reviewed by never (Reviewer).

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

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

From qamai at openjdk.org  Tue Mar  7 18:34:01 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 7 Mar 2023 18:34:01 GMT
Subject: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice
Message-ID: <uChb9T7MpJCsrPVNUDMpyd3g1nGaEAOlc36gCFVmEQI=.2a9264de-b228-4d6f-a565-554520b43da4@github.com>

`Vector::slice` is a method at the top-level class of the Vector API that concatenates the 2 inputs into an intermediate composite and extracts a window equal to the size of the inputs into the result. It is used in vector conversion methods where the part number is not 0 to slice the parts to the correct positions. Slicing is also used in text processing such as utf8 and utf16 validation. x86 starting from SSSE3 has `palignr` which does vector slicing very efficiently. As a result, I think it is beneficial to add a C2 node for this operation as well as intrinsify `Vector::slice` method.

A slice is currently implemented as `v2.rearrange(iota).blend(v1.rearrange(iota), blendMask)` which requires preparation of the index vector and the blending mask. Even with the preparations being hoisted out of the loops, microbenchmarks show improvement using the slice instrinsics. Some have tremendous increases in throughput due to the limitation that a mask of length 2 cannot currently be intrinsified, leading to falling back to the Java implementations.

Please take a look and have some reviews. Thank you very much.

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

Commit messages:
 - sse2, increase warmup
 - aesthetic
 - optimise 64B
 - add jmh
 - vector slice intrinsics

Changes: https://git.openjdk.org/jdk/pull/12909/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12909&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303762
  Stats: 1699 lines in 58 files changed: 1376 ins; 257 del; 66 mod
  Patch: https://git.openjdk.org/jdk/pull/12909.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12909/head:pull/12909

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

From qamai at openjdk.org  Tue Mar  7 18:34:01 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 7 Mar 2023 18:34:01 GMT
Subject: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice
In-Reply-To: <uChb9T7MpJCsrPVNUDMpyd3g1nGaEAOlc36gCFVmEQI=.2a9264de-b228-4d6f-a565-554520b43da4@github.com>
References: <uChb9T7MpJCsrPVNUDMpyd3g1nGaEAOlc36gCFVmEQI=.2a9264de-b228-4d6f-a565-554520b43da4@github.com>
Message-ID: <XZMVZkMPoXXUmQ0c0B5jORZlFeSiHNB3xIRvD_N6foA=.4de3fe05-67df-4f23-bffe-b7bbd2d3a7f9@github.com>

On Tue, 7 Mar 2023 18:23:42 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> `Vector::slice` is a method at the top-level class of the Vector API that concatenates the 2 inputs into an intermediate composite and extracts a window equal to the size of the inputs into the result. It is used in vector conversion methods where the part number is not 0 to slice the parts to the correct positions. Slicing is also used in text processing such as utf8 and utf16 validation. x86 starting from SSSE3 has `palignr` which does vector slicing very efficiently. As a result, I think it is beneficial to add a C2 node for this operation as well as intrinsify `Vector::slice` method.
> 
> A slice is currently implemented as `v2.rearrange(iota).blend(v1.rearrange(iota), blendMask)` which requires preparation of the index vector and the blending mask. Even with the preparations being hoisted out of the loops, microbenchmarks show improvement using the slice instrinsics. Some have tremendous increases in throughput due to the limitation that a mask of length 2 cannot currently be intrinsified, leading to falling back to the Java implementations.
> 
> Please take a look and have some reviews. Thank you very much.

Benchmark results:

                                                                   Before                After
    Benchmark                            (size)   Mode  Cnt     Score      Error     Score     Error   Units    Change
    Byte128Vector.sliceBinaryConstant      1024  thrpt    5  5058.760 ? 2214.115  8315.263 ? 102.169  ops/ms   +64.37%
    Byte256Vector.sliceBinaryConstant      1024  thrpt    5  6986.299 ? 1028.257  8440.387 ?  30.163  ops/ms   +20.81%
    Byte64Vector.sliceBinaryConstant       1024  thrpt    5  2944.869 ?  849.548  5926.054 ? 493.146  ops/ms  +101.23%
    ByteMaxVector.sliceBinaryConstant      1024  thrpt    5  7269.226 ?  366.246  8201.184 ? 309.539  ops/ms   +12.82%
    Double128Vector.sliceBinaryConstant    1024  thrpt    5    10.204 ?    0.508   979.287 ?  19.991  ops/ms    x95.97
    Double256Vector.sliceBinaryConstant    1024  thrpt    5   868.085 ?   26.378   967.799 ?  10.224  ops/ms   +11.49%
    DoubleMaxVector.sliceBinaryConstant    1024  thrpt    5   813.646 ?   74.468   978.150 ?  14.316  ops/ms   +20.22%
    Float128Vector.sliceBinaryConstant     1024  thrpt    5  1297.281 ?   23.650  1850.995 ?  29.741  ops/ms   +42.68%
    Float256Vector.sliceBinaryConstant     1024  thrpt    5  1796.121 ?   26.662  2011.362 ?  38.418  ops/ms   +11.98%
    Float64Vector.sliceBinaryConstant      1024  thrpt    5    10.381 ?    0.194  1628.510 ?   8.752  ops/ms   x156.87
    FloatMaxVector.sliceBinaryConstant     1024  thrpt    5  1820.161 ?   26.802  1988.085 ?  41.835  ops/ms    +9.23%
    Int128Vector.sliceBinaryConstant       1024  thrpt    5  1394.911 ?   40.815  1864.818 ?  33.792  ops/ms   +33.69%
    Int256Vector.sliceBinaryConstant       1024  thrpt    5  1874.496 ?   60.541  1864.818 ?  33.792  ops/ms    -0.52%
    Int64Vector.sliceBinaryConstant        1024  thrpt    5    10.942 ?    0.377  1621.849 ?  56.538  ops/ms   x148.22
    IntMaxVector.sliceBinaryConstant       1024  thrpt    5  1870.746 ?   40.665  2027.041 ?  25.880  ops/ms    +8.35%
    Long128Vector.sliceBinaryConstant      1024  thrpt    5    10.595 ?    0.306   991.969 ?  15.033  ops/ms    x93.63
    Long256Vector.sliceBinaryConstant      1024  thrpt    5   815.689 ?   12.243   989.365 ?  25.969  ops/ms   +21.29%
    LongMaxVector.sliceBinaryConstant      1024  thrpt    5   822.060 ?   12.337   977.061 ?  31.968  ops/ms   +18.86%
    Short128Vector.sliceBinaryConstant     1024  thrpt    5  3062.676 ?  124.796  3890.796 ? 326.767  ops/ms   +27.04%
    Short256Vector.sliceBinaryConstant     1024  thrpt    5  3747.778 ?  119.356  4125.463 ?  33.602  ops/ms   +10.08%
    Short64Vector.sliceBinaryConstant      1024  thrpt    5  1879.203 ?   69.160  2899.515 ?  57.870  ops/ms   +54.29%
    ShortMaxVector.sliceBinaryConstant     1024  thrpt    5  3717.217 ?   48.876  4035.455 ? 102.725  ops/ms    +8.56%

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

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

From matsaave at openjdk.org  Tue Mar  7 18:46:43 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 7 Mar 2023 18:46:43 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry
In-Reply-To: <LQTG-IYnef9srlK41aw_InVGTvihfRW2ez8deMPILoY=.efc03d45-0f5c-4d81-8c23-310c54969c07@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <LQTG-IYnef9srlK41aw_InVGTvihfRW2ez8deMPILoY=.efc03d45-0f5c-4d81-8c23-310c54969c07@github.com>
Message-ID: <6-fIr9UsLHUJXqqwQNVvQrL-Q6MP_UoZAL0W7ZLDHb8=.da0c0246-cd98-4309-9247-b792212f6021@github.com>

On Tue, 7 Mar 2023 14:10:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
>> 
>> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
>> 
>> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
>> 
>> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
>> 
>> This change supports the following platforms: x86, aarch64, PPC, and RISCV
>
> src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotConstantPool.java line 935:
> 
>> 933:                 /*if (isInvokedynamicIndex(cpi)) {
>> 934:                     compilerToVM().resolveInvokeDynamicInPool(this, cpi);
>> 935:                 }*/
> 
> Is there something to fix here?

That's a vestige of old code that I don't believe is necessary anymore. Invokedynamic is resolved further up so that can be removed. I think it makes sense to leave the invokedynamic case for completeness, but it will be left blank.

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

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

From yzheng at openjdk.org  Tue Mar  7 18:47:56 2023
From: yzheng at openjdk.org (Yudi Zheng)
Date: Tue, 7 Mar 2023 18:47:56 GMT
Subject: Integrated: 8302452: [JVMCI] Export _poly1305_processBlocks,
 JfrThreadLocal fields to JVMCI compiler.
In-Reply-To: <ZaVZomCJPArZStkQXu7EMWCWeWHGyeuBEQPfSA4svmo=.0a0d5637-331d-4b01-aae4-352802975226@github.com>
References: <ZaVZomCJPArZStkQXu7EMWCWeWHGyeuBEQPfSA4svmo=.0a0d5637-331d-4b01-aae4-352802975226@github.com>
Message-ID: <ahY8qboCwiC6aeHEQaJdEMKLyf1yrMjtvfLg1ahdW4U=.10873770-9788-436d-beb6-d91e7b1fd1f7@github.com>

On Tue, 14 Feb 2023 15:13:05 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

> This PR allows JVMCI compiler intrinsics to reuse the _poly1305_processBlocks stub and to update JfrThreadLocal fields on `Thread.setCurrentThread` events.

This pull request has now been integrated.

Changeset: 4d4eadea
Author:    Yudi Zheng <yzheng at openjdk.org>
Committer: Doug Simon <dnsimon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4d4eadeae320722191feaf8022a04461232ae95b
Stats:     12 lines in 3 files changed: 12 ins; 0 del; 0 mod

8302452: [JVMCI] Export _poly1305_processBlocks, JfrThreadLocal fields to JVMCI compiler.

Reviewed-by: dnsimon, never

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

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

From matsaave at openjdk.org  Tue Mar  7 19:16:35 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 7 Mar 2023 19:16:35 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry
In-Reply-To: <LQTG-IYnef9srlK41aw_InVGTvihfRW2ez8deMPILoY=.efc03d45-0f5c-4d81-8c23-310c54969c07@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <LQTG-IYnef9srlK41aw_InVGTvihfRW2ez8deMPILoY=.efc03d45-0f5c-4d81-8c23-310c54969c07@github.com>
Message-ID: <gYpLPZqKc3GOVzc0TKecY5QgmSGz2NwQnqk0F4t-1UM=.79bfd7ab-c803-4fbd-8ee3-afb42d18aadb@github.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
On Tue, 7 Mar 2023 13:35:18 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
>> 
>> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
>> 
>> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
>> 
>> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
>> 
>> This change supports the following platforms: x86, aarch64, PPC, and RISCV
>
> src/hotspot/cpu/x86/templateTable_x86.cpp line 2801:
> 
>> 2799:                                                bool is_invokevirtual,
>> 2800:                                                bool is_invokevfinal, /*unused*/
>> 2801:                                                bool is_invokedynamic /*unused*/) {
> 
> I assume you have to keep this parameter for the platform that doesn't still have this change (s390)?

That's correct, this method is declared inside the hpp used by all platforms, so the parameters can't be changed until all the ports are complete.

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

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

From matsaave at openjdk.org  Tue Mar  7 19:21:23 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 7 Mar 2023 19:21:23 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry
In-Reply-To: <LQTG-IYnef9srlK41aw_InVGTvihfRW2ez8deMPILoY=.efc03d45-0f5c-4d81-8c23-310c54969c07@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <LQTG-IYnef9srlK41aw_InVGTvihfRW2ez8deMPILoY=.efc03d45-0f5c-4d81-8c23-310c54969c07@github.com>
Message-ID: <p9jPqfAS2ZiP7AK6BL29milCtoDczFujDAvlD-_LdQ4=.2192db1f-f77d-41a3-ae2b-bf89fce2ca58@github.com>

On Tue, 7 Mar 2023 13:39:50 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
>> 
>> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
>> 
>> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
>> 
>> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
>> 
>> This change supports the following platforms: x86, aarch64, PPC, and RISCV
>
> src/hotspot/share/ci/ciReplay.cpp line 419:
> 
>> 417:       be used to avoid multiple blocks of similar code. When CPCE is obsoleted
>> 418:       these can be removed
>> 419:       */
> 
> I don't know if you really need this comment.  If so, use // style instead.

I think it's worth keeping around as a reminder for cleanup down the line since it's easy to overlook. I will change it to // style.

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

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

From matsaave at openjdk.org  Tue Mar  7 19:29:01 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 7 Mar 2023 19:29:01 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry
In-Reply-To: <LQTG-IYnef9srlK41aw_InVGTvihfRW2ez8deMPILoY=.efc03d45-0f5c-4d81-8c23-310c54969c07@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <LQTG-IYnef9srlK41aw_InVGTvihfRW2ez8deMPILoY=.efc03d45-0f5c-4d81-8c23-310c54969c07@github.com>
Message-ID: <CFZ6QoFPg2ShDr5Yh7CvmGnsHaqhsdZszT-Th0k9Dhc=.c127ecf8-f096-44f4-8d72-041a31f4a789@github.com>

On Tue, 7 Mar 2023 14:00:19 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
>> 
>> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
>> 
>> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
>> 
>> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
>> 
>> This change supports the following platforms: x86, aarch64, PPC, and RISCV
>
> src/hotspot/share/oops/cpCache.cpp line 727:
> 
>> 725:   set_reference_map(nullptr);
>> 726: #if INCLUDE_CDS
>> 727:   if (_initial_entries != nullptr) {
> 
> @iklam with moving invokedynamic entries out, do you still need to save initialized entries ?  Does invokehandle need this? (Should have separate RFE if more cleanup is possible)

This along with the previous comment about `_invokedynamic_references_map` would probably be better suited for their own RFE. I think the scope of this PR should be limited to the indy structure and its implementation, so any changes related to invokehandle can be traced more easily.

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

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

From rkennke at openjdk.org  Tue Mar  7 20:34:57 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 7 Mar 2023 20:34:57 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v13]
In-Reply-To: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
Message-ID: <WW4GjPXRw1dC9CfgHAnAhleVL09jZUej6UnpKpEe1Z4=.5eb8aa16-c29b-4db8-afbf-320d7b347433@github.com>

> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
> 
> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p
 rotocols.
> 
> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
> 
> 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
> 
> 
> Testing:
>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
> 
> ### Performance
> 
> #### Simple Microbenchmark
> 
> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
> 
> |  | x86_64 | aarch64 |
> | -- | -- | -- |
> | -UseFastLocking | 20.651 | 20.764 |
> | +UseFastLocking | 18.896 | 18.908 |
> 
> 
> #### Renaissance
> 
> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
> -- | -- | -- | -- | -- | -- | -- | --
> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Fix interpreter asymmetric fast-locking

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10907/files
  - new: https://git.openjdk.org/jdk/pull/10907/files/ed611b0b..9d4ca05f

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

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

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

From dnsimon at openjdk.org  Tue Mar  7 20:52:16 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 7 Mar 2023 20:52:16 GMT
Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v3]
In-Reply-To: <S01OqjUpY3g_c60VORZQ2UOT7LiyJtdCucB2kjHOhV4=.0c7d83a5-323a-4f92-be2d-c04518088c8e@github.com>
References: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>
 <S01OqjUpY3g_c60VORZQ2UOT7LiyJtdCucB2kjHOhV4=.0c7d83a5-323a-4f92-be2d-c04518088c8e@github.com>
Message-ID: <gVNA3K7EPyLjRfyXEyrm2FMBBmg_wdx_3EeW4-Ghp1U=.58a4304d-55a7-4a32-9a8e-fb685aa8427f@github.com>

On Sun, 5 Mar 2023 22:37:38 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for accessing annotations. The main differences from `java.lang.reflect.AnnotatedElement` are:
>> * Each `Annotated` method explicitly specifies the annotation type(s) for which it wants annotation data. That is, there is no direct equivalent of `AnnotatedElement.getAnnotations()`.
>> * Annotation data is returned in a map-like object (of type `jdk.vm.ci.meta.AnnotationData`) instead of in an `Annotation` object. This works better for libgraal as it avoids the need for annotation types to be loaded and included in libgraal.
>>  
>> To demonstrate the new API, here's an example in terms `java.lang.reflect.AnnotatedElement` (which `ResolvedJavaType` implements):
>> 
>>     ResolvedJavaMethod method = ...;
>>     ExplodeLoop a = method.getAnnotation(ExplodeLoop.class);
>>     return switch (a.kind()) {
>>         case FULL_UNROLL -> LoopExplosionKind.FULL_UNROLL;
>>         case FULL_UNROLL_UNTIL_RETURN -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>>         ...
>>     }
>> 
>> 
>> The same code using the new API:
>> 
>> 
>>     ResolvedJavaMethod method = ...;
>>     ResolvedJavaType explodeLoopType = ...;
>>     AnnotationData a = method.getAnnotationDataFor(explodeLoopType);
>>     return switch (a.getEnum("kind").getName()) {
>>         case "FULL_UNROLL" -> LoopExplosionKind.FULL_UNROLL;
>>         case "FULL_UNROLL_UNTIL_RETURN" -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>>         ...
>>     }
>> 
>> 
>> The implementation relies on new methods in `jdk.internal.vm.VMSupport` for parsing annotations and serializing/deserializing to/from a byte array. This allows the annotation data to be passed from the HotSpot heap to the libgraal heap.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed whitespace

This PR still needs work. I'll re-open it when ready.

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

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

From dnsimon at openjdk.org  Tue Mar  7 20:52:17 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 7 Mar 2023 20:52:17 GMT
Subject: Withdrawn: 8303431: [JVMCI] libgraal annotation API
In-Reply-To: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>
References: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>
Message-ID: <ITey-TcwraeJWhFUW_0wk9UToPkKjeZ70zqSkAgantI=.fd7fc5bc-672a-4487-a494-90f7d9b6e135@github.com>

On Wed, 1 Mar 2023 18:07:34 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for accessing annotations. The main differences from `java.lang.reflect.AnnotatedElement` are:
> * Each `Annotated` method explicitly specifies the annotation type(s) for which it wants annotation data. That is, there is no direct equivalent of `AnnotatedElement.getAnnotations()`.
> * Annotation data is returned in a map-like object (of type `jdk.vm.ci.meta.AnnotationData`) instead of in an `Annotation` object. This works better for libgraal as it avoids the need for annotation types to be loaded and included in libgraal.
>  
> To demonstrate the new API, here's an example in terms `java.lang.reflect.AnnotatedElement` (which `ResolvedJavaType` implements):
> 
>     ResolvedJavaMethod method = ...;
>     ExplodeLoop a = method.getAnnotation(ExplodeLoop.class);
>     return switch (a.kind()) {
>         case FULL_UNROLL -> LoopExplosionKind.FULL_UNROLL;
>         case FULL_UNROLL_UNTIL_RETURN -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>         ...
>     }
> 
> 
> The same code using the new API:
> 
> 
>     ResolvedJavaMethod method = ...;
>     ResolvedJavaType explodeLoopType = ...;
>     AnnotationData a = method.getAnnotationDataFor(explodeLoopType);
>     return switch (a.getEnum("kind").getName()) {
>         case "FULL_UNROLL" -> LoopExplosionKind.FULL_UNROLL;
>         case "FULL_UNROLL_UNTIL_RETURN" -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>         ...
>     }
> 
> 
> The implementation relies on new methods in `jdk.internal.vm.VMSupport` for parsing annotations and serializing/deserializing to/from a byte array. This allows the annotation data to be passed from the HotSpot heap to the libgraal heap.

This pull request has been closed without being integrated.

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

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

From pchilanomate at openjdk.org  Tue Mar  7 22:31:11 2023
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 7 Mar 2023 22:31:11 GMT
Subject: RFR: 8302779: HelidonAppTest.java fails with
 "assert(_cb == CodeCache::find_blob(pc())) failed: Must be the same" or
 SIGSEGV
Message-ID: <ZsPtiMn1PiOTGUiSC7GXZ196v4a7YFL5LRioo2ZCFdU=.148f395d-f892-4829-8f08-69ce7134b865@github.com>

Please review the following fix. The Method instance representing Continuation.enterSpecial() is replaced by a new Method during redefinition of the Continuation class. The already existing nmethod for it is not used, but a new one will be generated the first time enterSpecial() is resolved after redefinition. This means we could have more than one nmethod representing enterSpecial(), in particular, one generated before redefinition took place, and one after it. Now, when walking the stack, if we found a return barrier pc (as in Continuation::is_return_barrier_entry()) and we want to keep walking the physical stack then we know the sender will be the enterSpecial frame so we create it by calling ContinuationEntry::to_frame(). This method assumes there can only be one nmethod associated with enterSpecial() so we hit an assert later on. See the bug for more details of the crash.

As I mentioned in the bug we don't need to rely on this assumption since we can re-read the updated value from _enter_special. But reading both _enter_special and _return_pc means we would need some kind of synchronization since to_frame() could be called concurrently with set_enter_code(). To avoid that we could just read _return_pc and calculate the blob from it each time, but I'm also assuming that overhead is undesired and that's why the static variable was introduced. Alternatively _enter_special could be read and _return_pc could be derived from it (by adding an extra field in the nmethod class). But if we go this route I think we would need to do a small fix on thaw too. After redefinition and before a new call to resolve enterSpecial(), the last thaw call for some virtual thread would create an entry frame with an old _return_pc (see ThawBase::new_entry_frame() and ThawBase::patch_return()). I'm not sure about the lifecycle of the old CodeBlob but it seems it could have been 
 already removed if enterSpecial was not found while traversing everybody's stack. Maybe there are more issues.

The simple solution implemented here is just to disallow redefinition of the Continuation class altogether. Another less restrictive option would be to keep the already generated enterSpecial nmethod, if there is one. I can also investigate one of the routes mentioned previously if desired.

I tested the fix with the simple reproducer I added to the bug and also with the previously crashing HelidonAppTest.java test.

Thanks,
Patricio

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

Commit messages:
 - v1

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

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

From darcy at openjdk.org  Tue Mar  7 22:31:42 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 7 Mar 2023 22:31:42 GMT
Subject: Integrated: JDK-8302801: Remove fdlibm C sources
In-Reply-To: <fFJoo_g2Rqg062mR5ftOMCF6y9JrrlpW6wO1Vz0OeMI=.3a124adf-6ddf-4ab2-90d9-d26a400d09c7@github.com>
References: <fFJoo_g2Rqg062mR5ftOMCF6y9JrrlpW6wO1Vz0OeMI=.3a124adf-6ddf-4ab2-90d9-d26a400d09c7@github.com>
Message-ID: <OunBy7AVIgiJJUvWHPhdorzV0r1UGD8ZHO-xBazTXJ8=.a093abc4-fde8-440f-9952-f86b9e9f7f19@github.com>

On Thu, 2 Mar 2023 05:54:52 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> While the review of https://github.com/openjdk/jdk/pull/12800 finishes up, I thought I'd get out for the review the next phase of the FDLIBM port: removing the FDLIBM C sources from the repo.
> 
> A repo with the changes for JDK-8302027 and this PR successful build on the default set of platform and successfully run tier 1 tests, which includes tests of the math library.
> 
> There are a few remaining references to the case-independent string "fdlibm" in the make directory and HotSpot sources. HotSpot contains a partial fork for FDLIBM (a tine of FDLIBM?) to use for intrinsics. The remaining make machinery contains logic to determine what set of gcc options can be used for the compile.
> 
> The intention of this change is to remove use of FDLIBM for the core libraries.

This pull request has now been integrated.

Changeset: b5b5cba7
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b5b5cba7feb0e7ef957fd6bef1e591fdb6fdaa9f
Stats:     6643 lines in 65 files changed: 20 ins; 6613 del; 10 mod

8302801: Remove fdlibm C sources

Reviewed-by: bpb, dholmes, alanb, kvn

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

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

From dholmes at openjdk.org  Tue Mar  7 23:00:25 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 7 Mar 2023 23:00:25 GMT
Subject: Integrated: 8286781: Replace the deprecated/obsolete gethostbyname and
 inet_addr calls
In-Reply-To: <hTpw51fgF4gk1I60vdXDpEWpZlISh4v_eNfoOQw2hds=.9a07f8c1-0af4-454b-8a9e-37d83403f7c0@github.com>
References: <hTpw51fgF4gk1I60vdXDpEWpZlISh4v_eNfoOQw2hds=.9a07f8c1-0af4-454b-8a9e-37d83403f7c0@github.com>
Message-ID: <qaU3YCWf79YY9N5x2P8jU1VzuKyK-tXQAh-XMV_Em2I=.2bf65e62-92d8-4b57-99ad-4bfe7efb6258@github.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
On Thu, 2 Mar 2023 22:35:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

> We can replace `gethostbyname`, which is deprecated on Windows and Linux, with `getaddrinfo`. This API is available on all supported platforms and so can be placed in shared code. @djelinski pointed out that `getaddrinfo` can resolve both IP addresses and host names so the two step approach used in `networkStream::connect` is not necessary and we can do away with `os::get_host_by_name()` completely.
> 
> The build is updated to enable winsock deprecation warnings, and now we need to use `ws2_32.lib` we can drop `wsock32.lib` (as it is basically a subset - again thanks @djelinski ).
> 
> Testing
>     - all Oracle builds in tiers 1-5
>     - All GHA builds
> 
> The actual code change has to be manually tested because the code is only used by Ideal Graph Printing to connect to the Ideal Graph Visualizer. I've manually tested on Windows and Linux and @tobiasholenstein tested macOS.
> 
> Thanks.

This pull request has now been integrated.

Changeset: d7298245
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d7298245d6759f62e253b5cf0df975db17fdbf82
Stats:     41 lines in 6 files changed: 13 ins; 17 del; 11 mod

8286781: Replace the deprecated/obsolete gethostbyname and inet_addr calls

Co-authored-by: Daniel Jeli?ski <djelinski at openjdk.org>
Reviewed-by: kbarrett, djelinski

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

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

From inakonechnyy at openjdk.org  Tue Mar  7 23:54:07 2023
From: inakonechnyy at openjdk.org (Ilarion Nakonechnyy)
Date: Tue, 7 Mar 2023 23:54:07 GMT
Subject: RFR: 8302491: NoClassDefFoundError omits the original cause of an
 error [v6]
In-Reply-To: <L-pfBfK4TKl5KUWpPEcbs-IkhwimgJZ-SOrbSG3exeA=.5e883f22-de9b-4eec-9e98-8ee954a7996b@github.com>
References: <L-pfBfK4TKl5KUWpPEcbs-IkhwimgJZ-SOrbSG3exeA=.5e883f22-de9b-4eec-9e98-8ee954a7996b@github.com>
Message-ID: <nuns0Jl04F1OXvk_fevlbZTjWQjVohDcyXEPPd3R0YE=.e4d281c2-5a50-4d41-8dca-dfaca8ff1cbd@github.com>

> The proposed approach added a new function for getting the cause of an exception -`java_lang_Throwable::get_cause_simple `, that gets called within `InstanceKlass::add_initialization_error`  if an old one `java_lang_Throwable::get_cause_with_stack_trace` didn't succeed because of an exception during the VM call. The simple function doesn't call the VM for getting a stack trace but fills in any other information about an exception.
> 
> Besides that, the discovering information about an exception was added to `ConstantPoolCacheEntry::save_and_throw_indy_exc` function. 
> 
> Jtreg for reproducing the issue also was added to the commit. 
> The commit was tested with tier1 tests.

Ilarion Nakonechnyy has updated the pull request incrementally with one additional commit since the last revision:

  Address a review notes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12566/files
  - new: https://git.openjdk.org/jdk/pull/12566/files/adf139fa..bd4df11d

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

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

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

From inakonechnyy at openjdk.org  Tue Mar  7 23:54:08 2023
From: inakonechnyy at openjdk.org (Ilarion Nakonechnyy)
Date: Tue, 7 Mar 2023 23:54:08 GMT
Subject: RFR: 8302491: NoClassDefFoundError omits the original cause of an
 error [v5]
In-Reply-To: <0UEtpYm8TvljAdj3FQI5LYfjHxXPBWBfFD0lDsLojJA=.d259d5df-24b8-4b93-8fb3-feafc696deab@github.com>
References: <L-pfBfK4TKl5KUWpPEcbs-IkhwimgJZ-SOrbSG3exeA=.5e883f22-de9b-4eec-9e98-8ee954a7996b@github.com>
 <0UEtpYm8TvljAdj3FQI5LYfjHxXPBWBfFD0lDsLojJA=.d259d5df-24b8-4b93-8fb3-feafc696deab@github.com>
Message-ID: <u61C5ReCAmEDmgG5PaxZXZnj45ZOVSM6a4yW-dgZcdI=.8f86e84d-75de-4851-a89c-f61bcb310e14@github.com>

On Mon, 6 Mar 2023 20:28:40 GMT, Ilarion Nakonechnyy <inakonechnyy at openjdk.org> wrote:

>> The proposed approach added a new function for getting the cause of an exception -`java_lang_Throwable::get_cause_simple `, that gets called within `InstanceKlass::add_initialization_error`  if an old one `java_lang_Throwable::get_cause_with_stack_trace` didn't succeed because of an exception during the VM call. The simple function doesn't call the VM for getting a stack trace but fills in any other information about an exception.
>> 
>> Besides that, the discovering information about an exception was added to `ConstantPoolCacheEntry::save_and_throw_indy_exc` function. 
>> 
>> Jtreg for reproducing the issue also was added to the commit. 
>> The commit was tested with tier1 tests.
>
> Ilarion Nakonechnyy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   1/ create_initialization_error(): return empty exception, if
>   EIIE creation failed.
>   2/ remove testcase

Thank you for the review.

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

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

From inakonechnyy at openjdk.org  Tue Mar  7 23:54:13 2023
From: inakonechnyy at openjdk.org (Ilarion Nakonechnyy)
Date: Tue, 7 Mar 2023 23:54:13 GMT
Subject: RFR: 8302491: NoClassDefFoundError omits the original cause of an
 error [v4]
In-Reply-To: <aPvk5CskmkYH1DWQjsc2HAZG3FVDRYF79BF87ZmWN34=.aa85d351-ea6c-48f4-a6e8-2053985ca390@github.com>
References: <L-pfBfK4TKl5KUWpPEcbs-IkhwimgJZ-SOrbSG3exeA=.5e883f22-de9b-4eec-9e98-8ee954a7996b@github.com>
 <0UEtpYm8TvljAdj3FQI5LYfjHxXPBWBfFD0lDsLojJA=.d259d5df-24b8-4b93-8fb3-feafc696deab@github.com>
 <aPvk5CskmkYH1DWQjsc2HAZG3FVDRYF79BF87ZmWN34=.aa85d351-ea6c-48f4-a6e8-2053985ca390@github.com>
Message-ID: <QfajGZmUqSD3yA3M0DuMczfq7usDcwgUzLy-4HN3Cmo=.6bf636f1-fd53-47ee-94ef-6aadd2f39284@github.com>

On Tue, 7 Mar 2023 02:03:54 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Ilarion Nakonechnyy has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - reverting changes in cpCache.cpp
>>  - Redesigned get_cause as create_initialization_error.
>>    Corrected naming in testcase
>>  - jcheck corrections
>>  - Removed VM.compMode from test
>
> src/hotspot/share/oops/instanceKlass.cpp line 987:
> 
>> 985:   MutexLocker ml(THREAD, ClassInitError_lock);
>> 986:   OopHandle elem = OopHandle(Universe::vm_global(), cause());
>> 987:   bool created;
> 
> We still need to return if we got null.

Thanks, I was mistaken  about my corrections in calling `JavaCalls::call_virtual(`, and thought that create_initialization_error always return a non-null handle()

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

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

From psandoz at openjdk.org  Wed Mar  8 00:32:17 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 8 Mar 2023 00:32:17 GMT
Subject: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice
In-Reply-To: <uChb9T7MpJCsrPVNUDMpyd3g1nGaEAOlc36gCFVmEQI=.2a9264de-b228-4d6f-a565-554520b43da4@github.com>
References: <uChb9T7MpJCsrPVNUDMpyd3g1nGaEAOlc36gCFVmEQI=.2a9264de-b228-4d6f-a565-554520b43da4@github.com>
Message-ID: <_PA9oL9dVd3Yrg0sXw3m0uwfGjP6TuqXGBm5M090GHM=.a09a8733-e59e-4b6d-a6a6-e518a8518450@github.com>

On Tue, 7 Mar 2023 18:23:42 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> `Vector::slice` is a method at the top-level class of the Vector API that concatenates the 2 inputs into an intermediate composite and extracts a window equal to the size of the inputs into the result. It is used in vector conversion methods where the part number is not 0 to slice the parts to the correct positions. Slicing is also used in text processing such as utf8 and utf16 validation. x86 starting from SSSE3 has `palignr` which does vector slicing very efficiently. As a result, I think it is beneficial to add a C2 node for this operation as well as intrinsify `Vector::slice` method.
> 
> A slice is currently implemented as `v2.rearrange(iota).blend(v1.rearrange(iota), blendMask)` which requires preparation of the index vector and the blending mask. Even with the preparations being hoisted out of the loops, microbenchmarks show improvement using the slice instrinsics. Some have tremendous increases in throughput due to the limitation that a mask of length 2 cannot currently be intrinsified, leading to falling back to the Java implementations.
> 
> Please take a look and have some reviews. Thank you very much.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java line 2289:

> 2287:             getClass(), byte.class, length(),
> 2288:             this, that, origin,
> 2289:             new VectorSliceOp<ByteVector>() {

Change from inner class to lambda expression?

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

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

From psandoz at openjdk.org  Wed Mar  8 00:49:16 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 8 Mar 2023 00:49:16 GMT
Subject: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice
In-Reply-To: <uChb9T7MpJCsrPVNUDMpyd3g1nGaEAOlc36gCFVmEQI=.2a9264de-b228-4d6f-a565-554520b43da4@github.com>
References: <uChb9T7MpJCsrPVNUDMpyd3g1nGaEAOlc36gCFVmEQI=.2a9264de-b228-4d6f-a565-554520b43da4@github.com>
Message-ID: <_btCmeotboVIVWcIbHksJAaRcJO5aFl0CPVRnqpkuj0=.e3405352-fa81-4707-babe-25061abd99c5@github.com>

On Tue, 7 Mar 2023 18:23:42 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> `Vector::slice` is a method at the top-level class of the Vector API that concatenates the 2 inputs into an intermediate composite and extracts a window equal to the size of the inputs into the result. It is used in vector conversion methods where the part number is not 0 to slice the parts to the correct positions. Slicing is also used in text processing such as utf8 and utf16 validation. x86 starting from SSSE3 has `palignr` which does vector slicing very efficiently. As a result, I think it is beneficial to add a C2 node for this operation as well as intrinsify `Vector::slice` method.
> 
> A slice is currently implemented as `v2.rearrange(iota).blend(v1.rearrange(iota), blendMask)` which requires preparation of the index vector and the blending mask. Even with the preparations being hoisted out of the loops, microbenchmarks show improvement using the slice instrinsics. Some have tremendous increases in throughput due to the limitation that a mask of length 2 cannot currently be intrinsified, leading to falling back to the Java implementations.
> 
> Please take a look and have some reviews. Thank you very much.

test/hotspot/jtreg/compiler/vectorapi/TestVectorSlice.java line 65:

> 63:                 Asserts.assertEquals(expected, dst[i][j]);
> 64:             }
> 65:         }

It should be possible to factor out this code into something like this:

  assertOffsets(length, (expected, i, j) -> Assert.assertEquals((byte)expected, dst[i][j])

test/hotspot/jtreg/compiler/vectorapi/TestVectorSlice.java line 68:

> 66: 
> 67:         length = 16;
> 68:         testB128(dst, src1, src2);

Should `dst` be zeroed before the next call? or maybe easier to just reallocate.

test/jdk/jdk/incubator/vector/templates/Kernel-Slice-bop-const.template line 1:

> 1:         $type$[] a = fa.apply(SPECIES.length());

Forgot to commit the updated unit tests?

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

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

From david.holmes at oracle.com  Wed Mar  8 00:56:31 2023
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 8 Mar 2023 10:56:31 +1000
Subject: Integrated: JDK-8302801: Remove fdlibm C sources
In-Reply-To: <OunBy7AVIgiJJUvWHPhdorzV0r1UGD8ZHO-xBazTXJ8=.a093abc4-fde8-440f-9952-f86b9e9f7f19@github.com>
References: <fFJoo_g2Rqg062mR5ftOMCF6y9JrrlpW6wO1Vz0OeMI=.3a124adf-6ddf-4ab2-90d9-d26a400d09c7@github.com>
 <OunBy7AVIgiJJUvWHPhdorzV0r1UGD8ZHO-xBazTXJ8=.a093abc4-fde8-440f-9952-f86b9e9f7f19@github.com>
Message-ID: <c6c49faf-120b-cc60-8f08-deef667b998f@oracle.com>

Please note this fix has a problem with a missing definition for 
IEEEremainder that is causing UnsatisfiedLinkError. You can expect some 
significant noise in testing above tier 1 until this is fixed - which 
will hopefully be in the next 30 minutes or so. Otherwise a Backout will 
be performed.

David

On 8/03/2023 8:31 am, Joe Darcy wrote:
> On Thu, 2 Mar 2023 05:54:52 GMT, Joe Darcy <darcy at openjdk.org> wrote:
> 
>> While the review of https://github.com/openjdk/jdk/pull/12800 finishes up, I thought I'd get out for the review the next phase of the FDLIBM port: removing the FDLIBM C sources from the repo.
>>
>> A repo with the changes for JDK-8302027 and this PR successful build on the default set of platform and successfully run tier 1 tests, which includes tests of the math library.
>>
>> There are a few remaining references to the case-independent string "fdlibm" in the make directory and HotSpot sources. HotSpot contains a partial fork for FDLIBM (a tine of FDLIBM?) to use for intrinsics. The remaining make machinery contains logic to determine what set of gcc options can be used for the compile.
>>
>> The intention of this change is to remove use of FDLIBM for the core libraries.
> 
> This pull request has now been integrated.
> 
> Changeset: b5b5cba7
> Author:    Joe Darcy <darcy at openjdk.org>
> URL:       https://git.openjdk.org/jdk/commit/b5b5cba7feb0e7ef957fd6bef1e591fdb6fdaa9f
> Stats:     6643 lines in 65 files changed: 20 ins; 6613 del; 10 mod
> 
> 8302801: Remove fdlibm C sources
> 
> Reviewed-by: bpb, dholmes, alanb, kvn
> 
> -------------
> 
> PR: https://git.openjdk.org/jdk/pull/12821

From kbarrett at openjdk.org  Wed Mar  8 02:16:14 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 8 Mar 2023 02:16:14 GMT
Subject: RFR: 8302189: Mark assertion failures noreturn [v2]
In-Reply-To: <wp2Iv20ECTSdPiRt4yokZQFWeeITLe4LNmJtlubWy20=.5c7bc3c5-2428-47c2-a5b4-c168bc3b515e@github.com>
References: <4gLeUT6_5s6WpG-b-0146d490ZRgBq_JON1-5P3Wgtk=.e0bc3fd3-fce0-47b8-9478-1de796128731@github.com>
 <BMN3OJv9QTo0bNa_BvIMuldsCZDRD1-YjiN826iXbG0=.44fd41e9-ea55-437a-9c0a-294d5daaea71@github.com>
 <wp2Iv20ECTSdPiRt4yokZQFWeeITLe4LNmJtlubWy20=.5c7bc3c5-2428-47c2-a5b4-c168bc3b515e@github.com>
Message-ID: <izLQR0zhHanTwUCQdukba2NPAmXBl7Ei7EYmAp7Gf6c=.c3fdcd64-2b52-41c1-8aa7-2e70349c85b1@github.com>

On Tue, 7 Mar 2023 13:08:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   make Debugging::_enabled a nesting counter
>
> src/hotspot/share/utilities/debug.hpp line 108:
> 
>> 106: // because we need a fallback when we don't have any mechanism for detecting
>> 107: // constant evaluation.
>> 108: #if defined(TARGET_COMPILER_gcc) || defined(TARGET_COMPILER_xlc)
> 
> All this seems like it should go in COMPILER_HEADER(globalDefinitions.hpp) but since globalDefinitions.hpp includes debug.hpp, you can't do this.  Can we file an RFE to clean this up (if possible)?

I considered that, and had two reasons for rejecting it.

The include ordering problem was one. There are uses of assert and the like in
globalDefinitions. Some of those might someday be moved elsewhere, but for now
the order is a problem.

The other is that this is really not "general purpose", but rather very
specifically tailored to the use here.  And it can't be general purpose,
because there isn't a general fallback for testing for constexpr evaluation.

I could have added `HAS_IS_CONSTANT_EVALUATED` and `::is_constant_evaluated()`,
with all uses of the latter requiring protection by the former. But I couldn't
think of any places where I would want to use that. Using it in, for example,
count_trailing_zeros to allow it to be (sometimes) constexpr would make the
question of whether it's constexpr be platform-dependent, which means it can't
be used in shared required constexpr contexts. And it's even worse since the
platform dependency is also currently compiler version dependent. I think that
path leads nowhere good.

However, I've filed this cleanup RFE:
https://bugs.openjdk.org/browse/JDK-8303797

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

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

From kbarrett at openjdk.org  Wed Mar  8 02:37:36 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 8 Mar 2023 02:37:36 GMT
Subject: RFR: 8302189: Mark assertion failures noreturn [v3]
In-Reply-To: <4gLeUT6_5s6WpG-b-0146d490ZRgBq_JON1-5P3Wgtk=.e0bc3fd3-fce0-47b8-9478-1de796128731@github.com>
References: <4gLeUT6_5s6WpG-b-0146d490ZRgBq_JON1-5P3Wgtk=.e0bc3fd3-fce0-47b8-9478-1de796128731@github.com>
Message-ID: <D8259hANgavk7r0DOfxACNDBuGIetzN5hIMNh34MsKg=.bea24cf8-b037-4b13-aef2-07e09a0697cd@github.com>

> Also 8302799: Refactor Debugging variable usage for noreturn crash reporting

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 four additional commits since the last revision:

 - Merge branch 'master' into noreturn2
 - make Debugging::_enabled a nesting counter
 - new implementation of Debugging
 - noreturn attributes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12845/files
  - new: https://git.openjdk.org/jdk/pull/12845/files/f296ab62..59295614

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

  Stats: 18174 lines in 538 files changed: 7268 ins; 8749 del; 2157 mod
  Patch: https://git.openjdk.org/jdk/pull/12845.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12845/head:pull/12845

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

From kbarrett at openjdk.org  Wed Mar  8 02:37:36 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 8 Mar 2023 02:37:36 GMT
Subject: RFR: 8302189: Mark assertion failures noreturn [v2]
In-Reply-To: <T17qJbSmSkh9QDSoeq7C739FMZa_hweq5Fi_eoTsUSw=.8e735a5a-7812-412d-9163-3481961a8b67@github.com>
References: <4gLeUT6_5s6WpG-b-0146d490ZRgBq_JON1-5P3Wgtk=.e0bc3fd3-fce0-47b8-9478-1de796128731@github.com>
 <BMN3OJv9QTo0bNa_BvIMuldsCZDRD1-YjiN826iXbG0=.44fd41e9-ea55-437a-9c0a-294d5daaea71@github.com>
 <T17qJbSmSkh9QDSoeq7C739FMZa_hweq5Fi_eoTsUSw=.8e735a5a-7812-412d-9163-3481961a8b67@github.com>
Message-ID: <qAITijwf4g-WzGyznaOpGP-E_QZQeCXKfcaLwzgPmZU=.d8e63fa6-2a01-4aea-953a-bd432bbc63c4@github.com>

On Tue, 7 Mar 2023 01:36:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   make Debugging::_enabled a nesting counter
>
> Okay other than the one outstanding minor syntax query, I have nothing further to add.
> 
> Thanks.

Thanks for reviews @dholmes-ora and @coleenp

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

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

From dholmes at openjdk.org  Wed Mar  8 02:39:32 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 8 Mar 2023 02:39:32 GMT
Subject: RFR: 8303799: [BACKOUT] JDK-8302801 Remove fdlibm C sources
Message-ID: <YJoOelXilRZCCJYZdY-RsFUa9AjI-GWBbiZmKgVFilE=.39a5c918-3afd-4810-b4da-560fb786f125@github.com>

This reverts commit b5b5cba7feb0e7ef957fd6bef1e591fdb6fdaa9f.

Thanks.

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

Commit messages:
 - Revert "8302801: Remove fdlibm C sources"

Changes: https://git.openjdk.org/jdk/pull/12916/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12916&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303799
  Stats: 6643 lines in 65 files changed: 6613 ins; 20 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/12916.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12916/head:pull/12916

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

From darcy at openjdk.org  Wed Mar  8 02:39:32 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 8 Mar 2023 02:39:32 GMT
Subject: RFR: 8303799: [BACKOUT] JDK-8302801 Remove fdlibm C sources
In-Reply-To: <YJoOelXilRZCCJYZdY-RsFUa9AjI-GWBbiZmKgVFilE=.39a5c918-3afd-4810-b4da-560fb786f125@github.com>
References: <YJoOelXilRZCCJYZdY-RsFUa9AjI-GWBbiZmKgVFilE=.39a5c918-3afd-4810-b4da-560fb786f125@github.com>
Message-ID: <5FoTd9vTbjbqt5elKqfE5JL8rN_HDV_2t1BzMGRGiCE=.4b7253e9-647e-43b9-8853-bfe2f66f0c4e@github.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
On Wed, 8 Mar 2023 02:27:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This reverts commit b5b5cba7feb0e7ef957fd6bef1e591fdb6fdaa9f.
> 
> Thanks.

Sorry for the noise (and missing IEEERemainer)! Thanks @dholmes-ora .

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

Marked as reviewed by darcy (Reviewer).

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

From bpb at openjdk.org  Wed Mar  8 02:39:32 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 8 Mar 2023 02:39:32 GMT
Subject: RFR: 8303799: [BACKOUT] JDK-8302801 Remove fdlibm C sources
In-Reply-To: <YJoOelXilRZCCJYZdY-RsFUa9AjI-GWBbiZmKgVFilE=.39a5c918-3afd-4810-b4da-560fb786f125@github.com>
References: <YJoOelXilRZCCJYZdY-RsFUa9AjI-GWBbiZmKgVFilE=.39a5c918-3afd-4810-b4da-560fb786f125@github.com>
Message-ID: <4oeA0sOeKyTZtgAkE6avxboBskYMbaOE-oaV3fRNtHE=.2d5eda40-4689-46d1-90ed-022ce53f69fe@github.com>

On Wed, 8 Mar 2023 02:27:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This reverts commit b5b5cba7feb0e7ef957fd6bef1e591fdb6fdaa9f.
> 
> Thanks.

Marked as reviewed by bpb (Reviewer).

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

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

From kbarrett at openjdk.org  Wed Mar  8 02:40:30 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 8 Mar 2023 02:40:30 GMT
Subject: Integrated: 8302189: Mark assertion failures noreturn
In-Reply-To: <4gLeUT6_5s6WpG-b-0146d490ZRgBq_JON1-5P3Wgtk=.e0bc3fd3-fce0-47b8-9478-1de796128731@github.com>
References: <4gLeUT6_5s6WpG-b-0146d490ZRgBq_JON1-5P3Wgtk=.e0bc3fd3-fce0-47b8-9478-1de796128731@github.com>
Message-ID: <AZyCPgicXNKMgqaDAbirD-0B_bedrPNvVYwW3gXFYyw=.21a0cde2-768b-498b-9417-fc73b13a5a19@github.com>

On Fri, 3 Mar 2023 04:04:25 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Also 8302799: Refactor Debugging variable usage for noreturn crash reporting

This pull request has now been integrated.

Changeset: 5fa9bd45
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5fa9bd458232a0b5f31b1e7e5a4a2b1f4047da35
Stats:     165 lines in 8 files changed: 125 ins; 19 del; 21 mod

8302189: Mark assertion failures noreturn
8302799: Refactor Debugging variable usage for noreturn crash reporting

Reviewed-by: dholmes, coleenp

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

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

From dholmes at openjdk.org  Wed Mar  8 02:40:04 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 8 Mar 2023 02:40:04 GMT
Subject: RFR: 8303799: [BACKOUT] JDK-8302801 Remove fdlibm C sources
In-Reply-To: <5FoTd9vTbjbqt5elKqfE5JL8rN_HDV_2t1BzMGRGiCE=.4b7253e9-647e-43b9-8853-bfe2f66f0c4e@github.com>
References: <YJoOelXilRZCCJYZdY-RsFUa9AjI-GWBbiZmKgVFilE=.39a5c918-3afd-4810-b4da-560fb786f125@github.com>
 <5FoTd9vTbjbqt5elKqfE5JL8rN_HDV_2t1BzMGRGiCE=.4b7253e9-647e-43b9-8853-bfe2f66f0c4e@github.com>
Message-ID: <JMCQ8NP96d3kVqNqfKIzvvduSrGMEaEsKXWbjsbKIVw=.2ec104a3-a1f6-4d4e-b200-bba0147e4944@github.com>

On Wed, 8 Mar 2023 02:31:09 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> This reverts commit b5b5cba7feb0e7ef957fd6bef1e591fdb6fdaa9f.
>> 
>> Thanks.
>
> Sorry for the noise (and missing IEEERemainer)! Thanks @dholmes-ora .

Thanks for the reviews @jddarcy  and @bplb !

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

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

From dholmes at openjdk.org  Wed Mar  8 02:42:18 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 8 Mar 2023 02:42:18 GMT
Subject: Integrated: 8303799: [BACKOUT] JDK-8302801 Remove fdlibm C sources
In-Reply-To: <YJoOelXilRZCCJYZdY-RsFUa9AjI-GWBbiZmKgVFilE=.39a5c918-3afd-4810-b4da-560fb786f125@github.com>
References: <YJoOelXilRZCCJYZdY-RsFUa9AjI-GWBbiZmKgVFilE=.39a5c918-3afd-4810-b4da-560fb786f125@github.com>
Message-ID: <KBd-rfdTILm7q4o8XHshc6oBPrAmXVMKC4X6xDJ-H1I=.9cd1e70f-21b3-4b4f-be6e-5c1e6724f7bd@github.com>

On Wed, 8 Mar 2023 02:27:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This reverts commit b5b5cba7feb0e7ef957fd6bef1e591fdb6fdaa9f.
> 
> Thanks.

This pull request has now been integrated.

Changeset: 21a6ab1e
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/21a6ab1e3ea5228a31955d58fe75e5ae66d1c6cd
Stats:     6643 lines in 65 files changed: 6613 ins; 20 del; 10 mod

8303799: [BACKOUT] JDK-8302801 Remove fdlibm C sources

Reviewed-by: darcy, bpb

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

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

From iklam at openjdk.org  Wed Mar  8 04:14:17 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 8 Mar 2023 04:14:17 GMT
Subject: RFR: JDK-8302989: Add missing INCLUDE_CDS checks [v4]
In-Reply-To: <dkwL4nBOs2Sh6R-tiu0xVFTioOXKZDXInHk6GW3BpWE=.c5d327fc-9e63-4c9d-b223-ea7aa8753b80@github.com>
References: <kBV8fNo_CWJL2MoXgAckFhuAFgQ3RGZjFKAKnl8xfV8=.233bb652-8508-4065-92ea-7873b1c765f3@github.com>
 <dkwL4nBOs2Sh6R-tiu0xVFTioOXKZDXInHk6GW3BpWE=.c5d327fc-9e63-4c9d-b223-ea7aa8753b80@github.com>
Message-ID: <w2LAXW7zZNuJ71BFeIcjtXNDNAPeSTm_yr_e3ElvzUI=.a034b2d1-3b61-40a7-9574-b69738cd84cc@github.com>

On Fri, 3 Mar 2023 08:55:07 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The cds only coding in hotspot is usually guarded with the INCLUDE_CDS macro so that it can be removed at compile time in case the correct configure flags are set.
>> However at some places INCLUDE_CDS is missing and should be added.
>> 
>> One question - should (additionally to the UseSharedSpaces code section)  the DumpSharedSpaces code sections be guarded as well with INCLUDE_CDS macros ?
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust arguments handling

Maybe we can keep the -Xshare flags and make their behavior consistent with builds that have CDS enabled:

-Xshare:off  - do nothing 
-Xshare:auto - do nothing (CDS cannot be used so it?s ?automatically? disabled)
-Xshare:on - fail and report that CDS archive cannot be loaded.

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

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

From dholmes at openjdk.org  Wed Mar  8 09:30:25 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 8 Mar 2023 09:30:25 GMT
Subject: RFR: JDK-8302989: Add missing INCLUDE_CDS checks [v4]
In-Reply-To: <deBUxZbZ8FI9ENyfv-xwSrdfWhJVe-kT2VBxokj-_wA=.f7f83ce4-34cd-42d8-a30e-bad77676d802@github.com>
References: <kBV8fNo_CWJL2MoXgAckFhuAFgQ3RGZjFKAKnl8xfV8=.233bb652-8508-4065-92ea-7873b1c765f3@github.com>
 <dkwL4nBOs2Sh6R-tiu0xVFTioOXKZDXInHk6GW3BpWE=.c5d327fc-9e63-4c9d-b223-ea7aa8753b80@github.com>
 <deBUxZbZ8FI9ENyfv-xwSrdfWhJVe-kT2VBxokj-_wA=.f7f83ce4-34cd-42d8-a30e-bad77676d802@github.com>
Message-ID: <fGTeq_iVGjFe3aiVJQORv7tkkD_SFG40BZsTnJ4Pf_E=.fbb8ba70-fa69-4b4a-a744-02f249d418bb@github.com>

On Tue, 7 Mar 2023 14:26:49 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Unfortunately with the latest revision of the patch, quite a few tests fail when the build is configured with --disable-cds .

Yes that is to be expected. The tests have not be written to allow them to be run for arbitrary selection of the INCLUDE_XXX features. You will also have to exclude running all the CDS tests on such a build. Arguably any tests that set the -Xshare flag depend on CDS (positvely or negatively) and so should use appropriate @requires or runtime checks before using the flag.

> Maybe we can keep the -Xshare flags and make their behavior consistent with builds that have CDS enabled

This might help the tests but semantically this just seems wrong to me. It would be like accepting G1 flags when you only have SerialGC available.

I think we are just demonstrating that fully conditionalizing CDS code requires some higher-level semantic issues to be dealt with and that it is probably not worth trying to do that. So that brings us back to whether it is worth even trying to make a small step from where we are towards more complete conditionalization? Seems an arbitrary line to set to me when the benefit is minimal. But if you want to revert to an earlier version of the patch that "works" then I won't object further.

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

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

From mdoerr at openjdk.org  Wed Mar  8 10:57:14 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 8 Mar 2023 10:57:14 GMT
Subject: RFR: JDK-8303575: adjust Xen handling on Linux aarch64
In-Reply-To: <Pudap47AEtkkc8vtRirSNBUb4jdEHFIhhGd8IPEw0dg=.dc2f524d-7ade-49ff-b603-620adc3bcaf8@github.com>
References: <Pudap47AEtkkc8vtRirSNBUb4jdEHFIhhGd8IPEw0dg=.dc2f524d-7ade-49ff-b603-620adc3bcaf8@github.com>
Message-ID: <yoMJFbo8kX1ysv7byFKEDcC9fdL7F-n4paRVkiqmZYY=.516b9409-d060-438b-9bdf-b4fad6670be6@github.com>

On Fri, 3 Mar 2023 12:56:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> After [JDK-8301050](https://bugs.openjdk.org/browse/JDK-8301050) the Xen handling on aarch64 should be slightly adjusted.
> The output in VM_Version::print_platform_virtualization_info was missed and needs to be added for Xen.
> Additionally a new XenPVHVM virtualization type could be introduced because this describes the Xen on aarch64 better.
> See also https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/virtualization-on-arm-with-xen where the naming is used.

LGTM.

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

Marked as reviewed by mdoerr (Reviewer).

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

From rkennke at openjdk.org  Wed Mar  8 11:24:14 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 8 Mar 2023 11:24:14 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v14]
In-Reply-To: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
Message-ID: <dZWMGpNrRJuUuFndUXIFhjbQ-SdrEj14aIb51bLgp6k=.c0b55039-5f97-47aa-8789-ea85b97b1bcf@github.com>

> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
> 
> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p
 rotocols.
> 
> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
> 
> 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
> 
> 
> Testing:
>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
> 
> ### Performance
> 
> #### Simple Microbenchmark
> 
> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
> 
> |  | x86_64 | aarch64 |
> | -- | -- | -- |
> | -UseFastLocking | 20.651 | 20.764 |
> | +UseFastLocking | 18.896 | 18.908 |
> 
> 
> #### Renaissance
> 
> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
> -- | -- | -- | -- | -- | -- | -- | --
> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Use realloc instead of malloc+copy when growing the lock-stack

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10907/files
  - new: https://git.openjdk.org/jdk/pull/10907/files/9d4ca05f..12c2b8c3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=12-13

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

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

From stuefe at openjdk.org  Wed Mar  8 11:40:01 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 8 Mar 2023 11:40:01 GMT
Subject: RFR: JDK-8303817: Add constexpr for natural malloc alignment
Message-ID: <aWWx5bYpLxs3YLXaQCpyFay9k0USruBs6W2_qDUGCNE=.228b1fc3-9546-4ff8-b9af-94b9146b88d8@github.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
I miss having an easy way to get the alignment the libc guarantees for malloc. Let's add this, and we can use this right away with NMT's MallocHeader.

Tests: manually built and tested x64 linux (clang + GCC) and x86 linux.

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

Commit messages:
 - JDK-8303817-constexpr-for-natural-malloc-alignment

Changes: https://git.openjdk.org/jdk/pull/12921/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12921&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303817
  Stats: 19 lines in 3 files changed: 17 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12921.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12921/head:pull/12921

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

From mbaesken at openjdk.org  Wed Mar  8 11:42:17 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 8 Mar 2023 11:42:17 GMT
Subject: RFR: JDK-8303575: adjust Xen handling on Linux aarch64
In-Reply-To: <Pudap47AEtkkc8vtRirSNBUb4jdEHFIhhGd8IPEw0dg=.dc2f524d-7ade-49ff-b603-620adc3bcaf8@github.com>
References: <Pudap47AEtkkc8vtRirSNBUb4jdEHFIhhGd8IPEw0dg=.dc2f524d-7ade-49ff-b603-620adc3bcaf8@github.com>
Message-ID: <CZzbtWpv3PsUrOGS2JKU-FAhTMWPkxT6HY9lfA4au78=.013cf480-a1dc-4a8e-b08c-ca5fb2561b0f@github.com>

On Fri, 3 Mar 2023 12:56:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> After [JDK-8301050](https://bugs.openjdk.org/browse/JDK-8301050) the Xen handling on aarch64 should be slightly adjusted.
> The output in VM_Version::print_platform_virtualization_info was missed and needs to be added for Xen.
> Additionally a new XenPVHVM virtualization type could be introduced because this describes the Xen on aarch64 better.
> See also https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/virtualization-on-arm-with-xen where the naming is used.

Hi Martin and Lutz, thanks for the reviews !

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

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

From mbaesken at openjdk.org  Wed Mar  8 11:42:19 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 8 Mar 2023 11:42:19 GMT
Subject: Integrated: JDK-8303575: adjust Xen handling on Linux aarch64
In-Reply-To: <Pudap47AEtkkc8vtRirSNBUb4jdEHFIhhGd8IPEw0dg=.dc2f524d-7ade-49ff-b603-620adc3bcaf8@github.com>
References: <Pudap47AEtkkc8vtRirSNBUb4jdEHFIhhGd8IPEw0dg=.dc2f524d-7ade-49ff-b603-620adc3bcaf8@github.com>
Message-ID: <UKaMnpfHXpZ7SvHgrgPZxnrQA3LZRjY-2xSlOmMIOu8=.785dbfe2-b324-44e7-97b5-3c9616e992ad@github.com>

On Fri, 3 Mar 2023 12:56:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> After [JDK-8301050](https://bugs.openjdk.org/browse/JDK-8301050) the Xen handling on aarch64 should be slightly adjusted.
> The output in VM_Version::print_platform_virtualization_info was missed and needs to be added for Xen.
> Additionally a new XenPVHVM virtualization type could be introduced because this describes the Xen on aarch64 better.
> See also https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/virtualization-on-arm-with-xen where the naming is used.

This pull request has now been integrated.

Changeset: 8eaf84f0
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8eaf84f09476b08ed421efe74d7554e2b29bc5a7
Stats:     13 lines in 3 files changed: 5 ins; 0 del; 8 mod

8303575: adjust Xen handling on Linux aarch64

Reviewed-by: lucy, mdoerr

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

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

From mgronlun at openjdk.org  Wed Mar  8 12:54:13 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 8 Mar 2023 12:54:13 GMT
Subject: RFR: 8257967: JFR: Event for loaded agents
Message-ID: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>

Greetings,

We are adding support to let JFR report on Agents.

#### Design

An Agent is a library that uses any instrumentation or profiling APIs. Most agents are started and initialized on the command line, but agents can also be loaded dynamically during runtime. Because command line agents initialize during the VM startup sequence, they add to the overall startup time latency in getting the VM ready. The events will report on the time the agent took to initialize.

A JavaAgent is an agent written in the Java programming language, using the APIs in the package [[ava.lang.instrument](https://docs.oracle.com/en/java/javase/19/docs/api/java.instrument/java/lang/instrument/package-summary.html)

A JavaAgent is sometimes called a JPLIS agent, where the acronym JPLIS stands for Java Programming Language Instrumentation Services.

To report on JavaAgents, JFR will add the new event type jdk.JavaAgent and events will look similar to these two examples:

// Command line
jdk.JavaAgent {
  startTime = 12:31:19.789 (2023-03-08)
  name = "JavaAgent.jar"
  options = "foo=bar"
  initialization = 12:31:15.574 (2023-03-08)
  initializationTime = 172 ms
  initializationMethod = "premain"
}
// Dynamic load
jdk.JavaAgent {
  startTime = 12:31:31.158 (2023-03-08)
  name = "JavaAgent.jar"
  options = "bar=baz"
  initialization = 12:31:31.037 (2023-03-08)
  initializationTime = 64,1 ms
  initializationMethod = "agentmain"
}

The jdk.JavaAgent event type is a JFR periodic event that iterates over running Java agents.

For a JavaAgent event, the agent's name will be the specific .jar file containing the instrumentation code. The options will be the specific options passed to the .jar file as part of launching the agent, for example, on the command line: -javaagent: JavaAgent.jar=foo=bar

The event will also detail which initialization method was invoked by the JVM, "premain" for command line agents, and "agentmain" for agents loaded dynamically.

"initialization" is the timestamp the JVM invoked the initialization method, and "initializationTime" is the duration of executing the initialization method.

"startTime" represents the time the JFR framework issued the periodic event; hence "initialization" will be earlier than "startTime".

An agent can also be written in a native programming language, using either the JVM Tools Interface (JVMTI) or JVM Profiling Interface (JVMPI). This kind of agent, sometimes called a native agent, is a platform-specific binary, sometimes referred to as a library, but here it means a .so or .dll file.

JVMTI standard spec:ification is [here](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html)

JVMPI is an older interface, not a standard and is considered superseded by JVMTI, but the support is still in the JVM for agents started on the command line:  -XRunMyAgent.jar

To report on native agents, JFR will add the new event type jdk.NativeAgent and events will look similar to this example:

jdk.NativeAgent {
  startTime = 12:31:40.398 (2023-03-08)
  name = "jdwp"
  options = "transport=dt_socket,server=y,address=any,onjcmd=y"
  path = "c:\ade\github\openjdk\jdk\build\windows-x86_64-server-slowdebug\jdk\bin\jdwp.dll"
  dynamic = false
  initialization = 12:31:36.142 (2023-03-08)
  initializationTime = 0,00184 ms
}

The layout of the event type is very similar to the jdk.JavaAgent event, but here the path to the native library is reported, and there is also a denotation if the agent was loaded via the command line (dynamic = false) or dynamically (dynamic = true).

The initialization of a native agent is performed by invoking an agent-specified callback routine which is not detailed in the event (for now). The "initialization" is the time the JVM sent or would have sent the JVMTI VMInit event to a specified callback. "initializationTime" is the duration to execute that specific callback. If no callback is specified for the JVMTI VMInit event, the "initializationTime" will be 0.

#### Implementation

There has not existed a reification of a JavaAgent directly in the JVM, as these are built on top of the JDK native library, "instrument", using a many-to-one mapping. At the level of the JVM, the only representation of agents after startup is through JvmtiEnv's, which agents request from the JVM during startup and initialization ? as such, mapping which JvmtiEnv belongs to what JavaAgent was not possible before.

Using implementation details of how the JDK native library "instrument" interacts with the JVM, we can build this mapping and use it to track what JvmtiEnv's "belong" to what JavaAgent. This mapping now lets us report the Java-relevant context (name, options) and measure the time it takes for the JavaAgent to initialize.

In order to implement this capability, it was necessary to refactor the code used to represent agents, called AgentLibrary. The previous implementation was located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp.

The refactoring isolates the relevant logic into two new modules, prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their older places will help reduce the sizes of oversized arguments.cpp and threads.cpp.

The previous lists used to maintain the agents (JVMTI) and libraries (JVMPI) is not thread-safe for concurrent iterations. A single list that allows for concurrent iterations is therefore introduced.

Testing: jdk_jfr, tier 1 - 6

Thanks
Markus

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

Commit messages:
 - event_names
 - adjustment
 - 8257967

Changes: https://git.openjdk.org/jdk/pull/12923/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12923&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8257967
  Stats: 1862 lines in 22 files changed: 1353 ins; 485 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/12923.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12923/head:pull/12923

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

From mdoerr at openjdk.org  Wed Mar  8 13:22:50 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 8 Mar 2023 13:22:50 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v11]
In-Reply-To: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
Message-ID: <qsLD17uPIcS_HKuFNH1d9t6J4gOw1LIGgFKKWs0_ORE=.6841512c-6760-48bb-b3e1-6fac7f0d7a75@github.com>

> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
> 
> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
> 
> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
> 
> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Will get addressed separately: [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
> 
> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
> 
> I had to make changes to shared code and code for other platforms:
> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit.

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  Remove STRUCT_REFERENCE which was incorrectly taken from aarch64. Pass size to bufferLoad/Store. Enable TestNested.java.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12708/files
  - new: https://git.openjdk.org/jdk/pull/12708/files/3a541d00..f75a240d

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

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

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

From qamai at openjdk.org  Wed Mar  8 13:46:03 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 8 Mar 2023 13:46:03 GMT
Subject: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice [v2]
In-Reply-To: <uChb9T7MpJCsrPVNUDMpyd3g1nGaEAOlc36gCFVmEQI=.2a9264de-b228-4d6f-a565-554520b43da4@github.com>
References: <uChb9T7MpJCsrPVNUDMpyd3g1nGaEAOlc36gCFVmEQI=.2a9264de-b228-4d6f-a565-554520b43da4@github.com>
Message-ID: <zl9Z45hS-RdsVbGaLTk-5mg0vuoJKdGdIqw-mouFUF4=.39131710-2e7d-46b3-b343-5dfbd27a40d3@github.com>

> `Vector::slice` is a method at the top-level class of the Vector API that concatenates the 2 inputs into an intermediate composite and extracts a window equal to the size of the inputs into the result. It is used in vector conversion methods where the part number is not 0 to slice the parts to the correct positions. Slicing is also used in text processing such as utf8 and utf16 validation. x86 starting from SSSE3 has `palignr` which does vector slicing very efficiently. As a result, I think it is beneficial to add a C2 node for this operation as well as intrinsify `Vector::slice` method.
> 
> A slice is currently implemented as `v2.rearrange(iota).blend(v1.rearrange(iota), blendMask)` which requires preparation of the index vector and the blending mask. Even with the preparations being hoisted out of the loops, microbenchmarks show improvement using the slice instrinsics. Some have tremendous increases in throughput due to the limitation that a mask of length 2 cannot currently be intrinsified, leading to falling back to the Java implementations.
> 
> Please take a look and have some reviews. Thank you very much.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  address reviews

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12909/files
  - new: https://git.openjdk.org/jdk/pull/12909/files/e992d4c6..65409f13

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

  Stats: 333 lines in 2 files changed: 61 ins; 182 del; 90 mod
  Patch: https://git.openjdk.org/jdk/pull/12909.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12909/head:pull/12909

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

From qamai at openjdk.org  Wed Mar  8 13:52:18 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 8 Mar 2023 13:52:18 GMT
Subject: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice [v2]
In-Reply-To: <_PA9oL9dVd3Yrg0sXw3m0uwfGjP6TuqXGBm5M090GHM=.a09a8733-e59e-4b6d-a6a6-e518a8518450@github.com>
References: <uChb9T7MpJCsrPVNUDMpyd3g1nGaEAOlc36gCFVmEQI=.2a9264de-b228-4d6f-a565-554520b43da4@github.com>
 <_PA9oL9dVd3Yrg0sXw3m0uwfGjP6TuqXGBm5M090GHM=.a09a8733-e59e-4b6d-a6a6-e518a8518450@github.com>
Message-ID: <PrgIm1ADbZzIvqRX8q7J76f5hyERyHD9-_upyl_Cjjs=.0df644c2-ae3b-4b1a-9302-99503e01d72e@github.com>

On Wed, 8 Mar 2023 00:29:05 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address reviews
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java line 2289:
> 
>> 2287:             getClass(), byte.class, length(),
>> 2288:             this, that, origin,
>> 2289:             new VectorSliceOp<ByteVector>() {
> 
> Change from inner class to lambda expression?

We still need this method to be inlined and I don't know if there is a way to annotate the lambda function.

> test/hotspot/jtreg/compiler/vectorapi/TestVectorSlice.java line 65:
> 
>> 63:                 Asserts.assertEquals(expected, dst[i][j]);
>> 64:             }
>> 65:         }
> 
> It should be possible to factor out this code into something like this:
> 
>   assertOffsets(length, (expected, i, j) -> Assert.assertEquals((byte)expected, dst[i][j])

Fixed.

> test/hotspot/jtreg/compiler/vectorapi/TestVectorSlice.java line 68:
> 
>> 66: 
>> 67:         length = 16;
>> 68:         testB128(dst, src1, src2);
> 
> Should `dst` be zeroed before the next call? or maybe easier to just reallocate.

Fixed, I just allocate another array.

> test/jdk/jdk/incubator/vector/templates/Kernel-Slice-bop-const.template line 1:
> 
>> 1:         $type$[] a = fa.apply(SPECIES.length());
> 
> Forgot to commit the updated unit tests?

This is for the microbenchmarks generated in the panama-vector repo only.
Thanks a lot.

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

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

From duke at openjdk.org  Wed Mar  8 14:14:34 2023
From: duke at openjdk.org (Alexey Pavlyutkin)
Date: Wed, 8 Mar 2023 14:14:34 GMT
Subject: RFR: 8302073: Specifying OnError handler prevents WatcherThread to
 break a deadlock in report_and_die()
Message-ID: <nTD9cu_uj-X-ML_g-kbPrccPTlk5NGX9iV5TLXxOpbA=.2cea728c-6dbe-41a5-b379-a75c4ebc85e0@github.com>

The patch fixes error reporting to check timeout in the case when a user specifies OnError hander. Before VMError:check_timeout() ignored timeout in this case, and so didn't break malloc() deadlock.

Verification (amd64/20.04LTS):


16:52:17 at alex@alex-VirtualBox>( echo "
public class C {
  public static void main(String[] args) throws Throwable {
>     while (true) Thread.sleep(1000);
>   }
> }
> " >> C.java )
16:57:35 at alex@alex-VirtualBox>./build/linux-x86_64-server-release/images/jdk/bin/java -XX:OnError='sleep 1;sleep 10;sleep 60' ./C.java &
[2] 179574
17:00:19 at alex@alex-VirtualBox>kill -s SIGSEGV 179574
17:00:27 at alex@alex-VirtualBox>#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f7b1701ecd5 (sent by kill), pid=179574, tid=179574
#
# JRE version: OpenJDK Runtime Environment (21.0) (build 21-internal-adhoc.alex.jdk)
# Java VM: OpenJDK 64-Bit Server VM (21-internal-adhoc.alex.jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# C  [libpthread.so.0+0x9cd5]  __pthread_clockjoin_ex+0x255
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P %E" (or dumping to /home/alex/jdk/core.179574)
#
# An error report file with more information is saved as:
# /home/alex/jdk/hs_err_pid179574.log
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#
#
# -XX:OnError="sleep 1;sleep 10;sleep 60"
#   Executing /bin/sh -c "sleep 1" ...
#   Executing /bin/sh -c "sleep 10" ...
#   Executing /bin/sh -c "sleep 60" ...

[2]+  Aborted                 (core dumped) ./build/linux-x86_64-server-release/images/jdk/bin/java -XX:OnError='sleep 1;sleep 10;sleep 60' ./C.java
17:02:03 at alex@alex-VirtualBox>./build/linux-x86_64-server-release/images/jdk/bin/java -XX:ErrorLogTimeout=5 -XX:OnError='sleep 1;sleep 10;sleep 60' ./C.java &
[2] 179602
17:02:32 at alex@alex-VirtualBox>kill -s SIGSEGV 179602
17:02:41 at alex@alex-VirtualBox>#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f9d71b18cd5 (sent by kill), pid=179602, tid=179602
#
# JRE version: OpenJDK Runtime Environment (21.0) (build 21-internal-adhoc.alex.jdk)
# Java VM: OpenJDK 64-Bit Server VM (21-internal-adhoc.alex.jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# C  [libpthread.so.0+0x9cd5]  __pthread_clockjoin_ex+0x255
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P %E" (or dumping to /home/alex/jdk/core.179602)
#
# An error report file with more information is saved as:
# /home/alex/jdk/hs_err_pid179602.log
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#
#
# -XX:OnError="sleep 1;sleep 10;sleep 60"
#   Executing /bin/sh -c "sleep 1" ...
#   Executing /bin/sh -c "sleep 10" ...

------ Timeout during error reporting after 11 s. ------

17:02:54 at alex@alex-VirtualBox>


Regression (amd64/20.04LTS): `test/hotspot/jtreg/runtime/ErrorHandling` with different combinations of `-vmoption:-XX:ErrorLogTimeout=10` and `-vmoption:-XX:OnError='sleep 10'`

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

Commit messages:
 - report_and_die() should check timeout not under ForkAndExecCheckPoint
 - 8302073: reporting routine shall check timeout expiration after each call of fork_and_exec()
 - 8302073: Specifying OnError handler prevents WatcherThread to break a deadlock in report_and_die()

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

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

From qamai at openjdk.org  Wed Mar  8 14:21:54 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 8 Mar 2023 14:21:54 GMT
Subject: RFR: JDK-8303817: Add constexpr for natural malloc alignment
In-Reply-To: <aWWx5bYpLxs3YLXaQCpyFay9k0USruBs6W2_qDUGCNE=.228b1fc3-9546-4ff8-b9af-94b9146b88d8@github.com>
References: <aWWx5bYpLxs3YLXaQCpyFay9k0USruBs6W2_qDUGCNE=.228b1fc3-9546-4ff8-b9af-94b9146b88d8@github.com>
Message-ID: <9coR7ybmW69cjuVW4gPVNLYq9DPteSGZmcmyJm0E-OE=.618159df-f840-4428-b818-d054e119ee3e@github.com>

On Wed, 8 Mar 2023 11:23:53 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> I miss having an easy way to get the alignment the libc guarantees for malloc. Let's add this, and we can use this right away with NMT's MallocHeader.
> 
> Tests: manually built and tested x64 linux (clang + GCC) and x86 linux.

Can we use `alignof(std::max_align_t)` instead? Thanks.

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

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

From mbaesken at openjdk.org  Wed Mar  8 14:59:25 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 8 Mar 2023 14:59:25 GMT
Subject: RFR: JDK-8302989: Add missing INCLUDE_CDS checks [v4]
In-Reply-To: <dkwL4nBOs2Sh6R-tiu0xVFTioOXKZDXInHk6GW3BpWE=.c5d327fc-9e63-4c9d-b223-ea7aa8753b80@github.com>
References: <kBV8fNo_CWJL2MoXgAckFhuAFgQ3RGZjFKAKnl8xfV8=.233bb652-8508-4065-92ea-7873b1c765f3@github.com>
 <dkwL4nBOs2Sh6R-tiu0xVFTioOXKZDXInHk6GW3BpWE=.c5d327fc-9e63-4c9d-b223-ea7aa8753b80@github.com>
Message-ID: <iyBOuVMS7xnElAvv2XGhWmoxUHmTVgSOyCt-5Endk4g=.b20cca93-1e67-46df-8e87-c938951fc080@github.com>

On Fri, 3 Mar 2023 08:55:07 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The cds only coding in hotspot is usually guarded with the INCLUDE_CDS macro so that it can be removed at compile time in case the correct configure flags are set.
>> However at some places INCLUDE_CDS is missing and should be added.
>> 
>> One question - should (additionally to the UseSharedSpaces code section)  the DumpSharedSpaces code sections be guarded as well with INCLUDE_CDS macros ?
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust arguments handling

The disabling/enabling of jvm  features is briefly mentioned in the build doc  ( https://openjdk.org/groups/build/doc/building.html )  so I thought this is something that is supported and should work (maybe not perfect because of limited testing)  . If it is really not so interesting to others to adjust tests with `@requires vm.cds`   where needed and to remove not needed code when the feature is disabled , then we can leave it as it is.

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

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

From mgronlun at openjdk.org  Wed Mar  8 15:16:28 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 8 Mar 2023 15:16:28 GMT
Subject: RFR: 8257967: JFR: Events for loaded agents [v2]
In-Reply-To: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
References: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
Message-ID: <oM-QqpAfrCFle1LLhn8BZMHIsqdZkpFS0_C1Neuda1M=.8f7bdcc2-009d-4f6a-9d23-095116e3b8c0@github.com>

> Greetings,
> 
> We are adding support to let JFR report on Agents.
> 
> #### Design
> 
> An Agent is a library that uses any instrumentation or profiling APIs. Most agents are started and initialized on the command line, but agents can also be loaded dynamically during runtime. Because command line agents initialize during the VM startup sequence, they add to the overall startup time latency in getting the VM ready. The events will report on the time the agent took to initialize.
> 
> A JavaAgent is an agent written in the Java programming language, using the APIs in the package [[ava.lang.instrument](https://docs.oracle.com/en/java/javase/19/docs/api/java.instrument/java/lang/instrument/package-summary.html)
> 
> A JavaAgent is sometimes called a JPLIS agent, where the acronym JPLIS stands for Java Programming Language Instrumentation Services.
> 
> To report on JavaAgents, JFR will add the new event type jdk.JavaAgent and events will look similar to these two examples:
> 
> // Command line
> jdk.JavaAgent {
>   startTime = 12:31:19.789 (2023-03-08)
>   name = "JavaAgent.jar"
>   options = "foo=bar"
>   initialization = 12:31:15.574 (2023-03-08)
>   initializationTime = 172 ms
>   initializationMethod = "premain"
> }
> // Dynamic load
> jdk.JavaAgent {
>   startTime = 12:31:31.158 (2023-03-08)
>   name = "JavaAgent.jar"
>   options = "bar=baz"
>   initialization = 12:31:31.037 (2023-03-08)
>   initializationTime = 64,1 ms
>   initializationMethod = "agentmain"
> }
> 
> The jdk.JavaAgent event type is a JFR periodic event that iterates over running Java agents.
> 
> For a JavaAgent event, the agent's name will be the specific .jar file containing the instrumentation code. The options will be the specific options passed to the .jar file as part of launching the agent, for example, on the command line: -javaagent: JavaAgent.jar=foo=bar
> 
> The event will also detail which initialization method was invoked by the JVM, "premain" for command line agents, and "agentmain" for agents loaded dynamically.
> 
> "initialization" is the timestamp the JVM invoked the initialization method, and "initializationTime" is the duration of executing the initialization method.
> 
> "startTime" represents the time the JFR framework issued the periodic event; hence "initialization" will be earlier than "startTime".
> 
> An agent can also be written in a native programming language, using either the JVM Tools Interface (JVMTI) or JVM Profiling Interface (JVMPI). This kind of agent, sometimes called a native agent, is a platform-specific binary, sometimes referred to as a library, but here it means a .so or .dll file.
> 
> JVMTI standard spec:ification is [here](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html)
> 
> JVMPI is an older interface, not a standard and is considered superseded by JVMTI, but the support is still in the JVM for agents started on the command line:  -XRunMyAgent.jar
> 
> To report on native agents, JFR will add the new event type jdk.NativeAgent and events will look similar to this example:
> 
> jdk.NativeAgent {
>   startTime = 12:31:40.398 (2023-03-08)
>   name = "jdwp"
>   options = "transport=dt_socket,server=y,address=any,onjcmd=y"
>   path = "c:\ade\github\openjdk\jdk\build\windows-x86_64-server-slowdebug\jdk\bin\jdwp.dll"
>   dynamic = false
>   initialization = 12:31:36.142 (2023-03-08)
>   initializationTime = 0,00184 ms
> }
> 
> The layout of the event type is very similar to the jdk.JavaAgent event, but here the path to the native library is reported, and there is also a denotation if the agent was loaded via the command line (dynamic = false) or dynamically (dynamic = true).
> 
> The initialization of a native agent is performed by invoking an agent-specified callback routine which is not detailed in the event (for now). The "initialization" is the time the JVM sent or would have sent the JVMTI VMInit event to a specified callback. "initializationTime" is the duration to execute that specific callback. If no callback is specified for the JVMTI VMInit event, the "initializationTime" will be 0.
> 
> #### Implementation
> 
> There has not existed a reification of a JavaAgent directly in the JVM, as these are built on top of the JDK native library, "instrument", using a many-to-one mapping. At the level of the JVM, the only representation of agents after startup is through JvmtiEnv's, which agents request from the JVM during startup and initialization ? as such, mapping which JvmtiEnv belongs to what JavaAgent was not possible before.
> 
> Using implementation details of how the JDK native library "instrument" interacts with the JVM, we can build this mapping to track what JvmtiEnv's "belong" to what JavaAgent. This mapping now lets us report the Java-relevant context (name, options) and measure the time it takes for the JavaAgent to initialize.
> 
> To implement this capability, it was necessary to refactor the code used to represent agents, called AgentLibrary. The previous implementation was located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp.
> 
> The refactoring isolates the relevant logic into two new modules, prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their older places will help reduce the sizes of oversized arguments.cpp and threads.cpp.
> 
> The previous lists that maintain the agents (JVMTI) and libraries (JVMPI) are not thread-safe for concurrent iterations. A single list that allows for concurrent iterations is therefore introduced.
> 
> Testing: jdk_jfr, tier 1 - 6
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  razor

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12923/files
  - new: https://git.openjdk.org/jdk/pull/12923/files/c50cca53..ed1ea797

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

  Stats: 114 lines in 3 files changed: 33 ins; 74 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/12923.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12923/head:pull/12923

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

From coleenp at openjdk.org  Wed Mar  8 15:40:33 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 8 Mar 2023 15:40:33 GMT
Subject: RFR: 8302779: HelidonAppTest.java fails with
 "assert(_cb == CodeCache::find_blob(pc())) failed: Must be the same" or
 SIGSEGV
In-Reply-To: <ZsPtiMn1PiOTGUiSC7GXZ196v4a7YFL5LRioo2ZCFdU=.148f395d-f892-4829-8f08-69ce7134b865@github.com>
References: <ZsPtiMn1PiOTGUiSC7GXZ196v4a7YFL5LRioo2ZCFdU=.148f395d-f892-4829-8f08-69ce7134b865@github.com>
Message-ID: <w1BvR-TnE9TcAxKBuKhjxf9vFKm29FZmXOBAaPqesgk=.17982c5b-1989-4f5d-b67f-c5c7e8968e4e@github.com>

On Tue, 7 Mar 2023 22:14:39 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review the following fix. The Method instance representing Continuation.enterSpecial() is replaced by a new Method during redefinition of the Continuation class. The already existing nmethod for it is not used, but a new one will be generated the first time enterSpecial() is resolved after redefinition. This means we could have more than one nmethod representing enterSpecial(), in particular, one generated before redefinition took place, and one after it. Now, when walking the stack, if we found a return barrier pc (as in Continuation::is_return_barrier_entry()) and we want to keep walking the physical stack then we know the sender will be the enterSpecial frame so we create it by calling ContinuationEntry::to_frame(). This method assumes there can only be one nmethod associated with enterSpecial() so we hit an assert later on. See the bug for more details of the crash.
> 
> As I mentioned in the bug we don't need to rely on this assumption since we can re-read the updated value from _enter_special. But reading both _enter_special and _return_pc means we would need some kind of synchronization since to_frame() could be called concurrently with set_enter_code(). To avoid that we could just read _return_pc and calculate the blob from it each time, but I'm also assuming that overhead is undesired and that's why the static variable was introduced. Alternatively _enter_special could be read and _return_pc could be derived from it (by adding an extra field in the nmethod class). But if we go this route I think we would need to do a small fix on thaw too. After redefinition and before a new call to resolve enterSpecial(), the last thaw call for some virtual thread would create an entry frame with an old _return_pc (see ThawBase::new_entry_frame() and ThawBase::patch_return()). I'm not sure about the lifecycle of the old CodeBlob but it seems it could have bee
 n already removed if enterSpecial was not found while traversing everybody's stack. Maybe there are more issues.
> 
> The simple solution implemented here is just to disallow redefinition of the Continuation class altogether. Another less restrictive option would be to keep the already generated enterSpecial nmethod, if there is one. I can also investigate one of the routes mentioned previously if desired.
> 
> I tested the fix with the simple reproducer I added to the bug and also with the previously crashing HelidonAppTest.java test.
> 
> Thanks,
> Patricio

That's a good fix and a good place for it.  Thank you for figuring this out.

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

Marked as reviewed by coleenp (Reviewer).

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

From jcking at openjdk.org  Wed Mar  8 15:42:49 2023
From: jcking at openjdk.org (Justin King)
Date: Wed, 8 Mar 2023 15:42:49 GMT
Subject: RFR: JDK-8303817: Add constexpr for natural malloc alignment
In-Reply-To: <9coR7ybmW69cjuVW4gPVNLYq9DPteSGZmcmyJm0E-OE=.618159df-f840-4428-b818-d054e119ee3e@github.com>
References: <aWWx5bYpLxs3YLXaQCpyFay9k0USruBs6W2_qDUGCNE=.228b1fc3-9546-4ff8-b9af-94b9146b88d8@github.com>
 <9coR7ybmW69cjuVW4gPVNLYq9DPteSGZmcmyJm0E-OE=.618159df-f840-4428-b818-d054e119ee3e@github.com>
Message-ID: <Z7BraEt0Y66B80GanCehv3zbxV9ixb1yGGxfeSpyxA8=.468266fe-cb30-40fb-b41f-7566132855aa@github.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
On Wed, 8 Mar 2023 14:19:12 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Can we use `alignof(std::max_align_t)` instead? Thanks.

Same request.

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

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

From psandoz at openjdk.org  Wed Mar  8 16:22:13 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 8 Mar 2023 16:22:13 GMT
Subject: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice [v2]
In-Reply-To: <PrgIm1ADbZzIvqRX8q7J76f5hyERyHD9-_upyl_Cjjs=.0df644c2-ae3b-4b1a-9302-99503e01d72e@github.com>
References: <uChb9T7MpJCsrPVNUDMpyd3g1nGaEAOlc36gCFVmEQI=.2a9264de-b228-4d6f-a565-554520b43da4@github.com>
 <_PA9oL9dVd3Yrg0sXw3m0uwfGjP6TuqXGBm5M090GHM=.a09a8733-e59e-4b6d-a6a6-e518a8518450@github.com>
 <PrgIm1ADbZzIvqRX8q7J76f5hyERyHD9-_upyl_Cjjs=.0df644c2-ae3b-4b1a-9302-99503e01d72e@github.com>
Message-ID: <wVNZBpY7sXbxrjpM9TVO2JM7uzGday1_6VShF6oc0VI=.32440f6c-8612-4eba-b9c2-9c30e4911381@github.com>

On Wed, 8 Mar 2023 13:48:16 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java line 2289:
>> 
>>> 2287:             getClass(), byte.class, length(),
>>> 2288:             this, that, origin,
>>> 2289:             new VectorSliceOp<ByteVector>() {
>> 
>> Change from inner class to lambda expression?
>
> We still need this method to be inlined and I don't know if there is a way to annotate the lambda function.

Yes, i wondered about the inline and how important it might be. You want the fallback to inline so as not to perturb platforms without the intrinsic. Can you add a comment on the anon class?

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

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

From psandoz at openjdk.org  Wed Mar  8 16:26:05 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 8 Mar 2023 16:26:05 GMT
Subject: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice [v2]
In-Reply-To: <zl9Z45hS-RdsVbGaLTk-5mg0vuoJKdGdIqw-mouFUF4=.39131710-2e7d-46b3-b343-5dfbd27a40d3@github.com>
References: <uChb9T7MpJCsrPVNUDMpyd3g1nGaEAOlc36gCFVmEQI=.2a9264de-b228-4d6f-a565-554520b43da4@github.com>
 <zl9Z45hS-RdsVbGaLTk-5mg0vuoJKdGdIqw-mouFUF4=.39131710-2e7d-46b3-b343-5dfbd27a40d3@github.com>
Message-ID: <ViduD2N5x51q_1AVqeNsmCCm1DeGrk8g44Fm5dcIxyc=.a3f64564-7d8f-43bb-b071-7c594c477303@github.com>

On Wed, 8 Mar 2023 13:46:03 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> `Vector::slice` is a method at the top-level class of the Vector API that concatenates the 2 inputs into an intermediate composite and extracts a window equal to the size of the inputs into the result. It is used in vector conversion methods where the part number is not 0 to slice the parts to the correct positions. Slicing is also used in text processing such as utf8 and utf16 validation. x86 starting from SSSE3 has `palignr` which does vector slicing very efficiently. As a result, I think it is beneficial to add a C2 node for this operation as well as intrinsify `Vector::slice` method.
>> 
>> A slice is currently implemented as `v2.rearrange(iota).blend(v1.rearrange(iota), blendMask)` which requires preparation of the index vector and the blending mask. Even with the preparations being hoisted out of the loops, microbenchmarks show improvement using the slice instrinsics. Some have tremendous increases in throughput due to the limitation that a mask of length 2 cannot currently be intrinsified, leading to falling back to the Java implementations.
>> 
>> Please take a look and have some reviews. Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address reviews

Java changes look good. The HotSpot code looks well structured but i will let others comment on the specifics.

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

Marked as reviewed by psandoz (Reviewer).

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

From coleenp at openjdk.org  Wed Mar  8 16:37:23 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 8 Mar 2023 16:37:23 GMT
Subject: RFR: 8292818: replace 96-bit representation for field metadata
 with variable-sized streams
In-Reply-To: <vdiacOO3JUyy4sWGkDXNBMUT7cG3XYe79mOvYru9uMM=.9c556675-7ffd-4c09-a428-6d64dffef209@github.com>
References: <vdiacOO3JUyy4sWGkDXNBMUT7cG3XYe79mOvYru9uMM=.9c556675-7ffd-4c09-a428-6d64dffef209@github.com>
Message-ID: <duJxLMpZeS9KBS839JUNLQPb7u7cBzbFxk4CcmZGdoc=.4704e44a-2680-44e3-93c0-33bb575e9f28@github.com>

On Fri, 3 Mar 2023 14:50:34 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review this change re-implementing the FieldInfo data structure.
> 
> The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency.
> 
> The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information).
> 
> More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818
> 
> Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM.
> 
> The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format.
> 
> Tested with mach5, tier 1 to 7.
> 
> Thank you.

I was able to do a first pass through the vm code except for jvmci.  I didn't look at tests or SA in this pass.

src/hotspot/share/ci/ciFlags.hpp line 47:

> 45: 
> 46:   ciFlags()                  { _flags = 0; _stable = false; _intialized_final_update = false; }
> 47:   ciFlags(AccessFlags flags, bool is_stable= false, bool is_initialized_final_update = false) {

This should use constructor initializer syntax.

src/hotspot/share/classfile/classFileParser.cpp line 1491:

> 1489:   _temp_field_info = new GrowableArray<FieldInfo>(total_fields);
> 1490: 
> 1491:   ResourceMark rm(THREAD);

Is the ResourceMark ok here or should it go before allocating _temp_field_info ?

src/hotspot/share/classfile/classFileParser.cpp line 1608:

> 1606:       fflags.update_injected(true);
> 1607:       AccessFlags aflags;
> 1608:       FieldInfo fi(aflags, (u2)(injected[n].name_index), (u2)(injected[n].signature_index), 0, fflags);

I don't know why there's a cast here until I read more.  If the FieldInfo name_index and signature_index fields are only u2 sized, could you pass this as an int and then in the constructor assert that the value doesn't overflow u2 instead?

src/hotspot/share/classfile/classFileParser.cpp line 1634:

> 1632:       for(int i = 0; i < _temp_field_info->length(); i++) {
> 1633:         name = _temp_field_info->adr_at(i)->name(_cp);
> 1634:         sig = _temp_field_info->adr_at(i)->signature(_cp);

This checking for duplicates looks like a good candidate for a separate function because parse_fields is so long.  I'm adding this comment to remember to file an RFE to look into making this function shorter and factor out this code.

src/hotspot/share/classfile/classFileParser.cpp line 6024:

> 6022:   int injected_fields_count = _temp_field_info->length() - _java_fields_count;
> 6023:   _fieldinfo_stream = FieldInfoStream::create_FieldInfoStream(_temp_field_info, _java_fields_count, injected_fields_count, loader_data(), CHECK);
> 6024:   _fields_status = MetadataFactory::new_array<FieldStatus>(_loader_data, _temp_field_info->length(), FieldStatus(0), CHECK);

These lines seem long, could you reformat?

src/hotspot/share/classfile/fieldLayoutBuilder.cpp line 554:

> 552:     FieldInfo ctrl = _field_info->at(0);
> 553:     FieldGroup* group = nullptr;
> 554:     FieldInfo tfi = *it;

What's the 't' in tfi?  Maybe a longer variable name would be helpful here.

src/hotspot/share/classfile/javaClasses.cpp line 871:

> 869:       // a new UNSIGNED5 stream, and substitute it to the old FieldInfo stream.
> 870: 
> 871:       int java_fields;

Can you put InstanceKlass* ik = InstanceKlass::cast(k); here and use that so there's only one cast?

src/hotspot/share/classfile/javaClasses.cpp line 873:

> 871:       int java_fields;
> 872:       int injected_fields;
> 873:       GrowableArray<FieldInfo>* fields = FieldInfoStream::create_FieldInfoArray(InstanceKlass::cast(k)->fieldinfo_stream(), &java_fields, &injected_fields);

This line looks too long too.

src/hotspot/share/oops/fieldInfo.hpp line 31:

> 29: #include "memory/metadataFactory.hpp"
> 30: #include "oops/constantPool.hpp"
> 31: #include "oops/symbol.hpp"

Since you added an inline.hpp function can you move the functions that rely on including constantPool.hpp, symbol.hpp and metadataFactory.hpp into the inline.hpp file?

src/hotspot/share/oops/fieldInfo.hpp line 180:

> 178:   u2 generic_signature_index() const { return _generic_signature_index; }
> 179:   void set_generic_signature_index(u2 index) { _generic_signature_index = index; }
> 180:   u2 contention_group() const { return _contention_group; }

Can you align the { in these one line functions?

src/hotspot/share/oops/fieldStreams.hpp line 28:

> 26: #define SHARE_OOPS_FIELDSTREAMS_HPP
> 27: 
> 28: #include "oops/instanceKlass.inline.hpp"

including .inline.hpp from .hpp is against the guidelines.  You should move things and include instanceKlass.inline.hpp in fieldStreams.inline.hpp instead.

src/hotspot/share/oops/fieldStreams.hpp line 104:

> 102:     AccessFlags flags;
> 103:     flags.set_flags(field()->access_flags());
> 104:     return flags;

Did this used to do this for a reason?

src/hotspot/share/oops/fieldStreams.inline.hpp line 28:

> 26: #define SHARE_OOPS_FIELDSTREAMS_INLINE_HPP
> 27: 
> 28: #include "oops/fieldInfo.inline.hpp"

I don't know if you have to include oops/fieldInfo.inline.hpp but the include line for fieldStreams.hpp should be by itself and then this new include should be below with runtime/javaThread.hpp

src/hotspot/share/oops/instanceKlass.hpp line 275:

> 273:   // Fields information is stored in an UNSIGNED5 encoded stream (see fieldInfo.hpp)
> 274:   Array<u1>* _fieldinfo_stream;
> 275:   Array<FieldStatus>* _fields_status;

Can you align these two field identifiers?

src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 3582:

> 3580:   }
> 3581:   if (update_required) {
> 3582:     Array<u1>* old_stream = InstanceKlass::cast(scratch_class)->fieldinfo_stream();

scratch_class should already be an InstanceKlass, ie cast not required here or below.

src/hotspot/share/runtime/reflectionUtils.hpp line 29:

> 27: 
> 28: #include "memory/allStatic.hpp"
> 29: #include "oops/instanceKlass.inline.hpp"

Also here cannot include .inline.hpp in .hpp file.

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

Changes requested by coleenp (Reviewer).

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

From stuefe at openjdk.org  Wed Mar  8 17:10:43 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 8 Mar 2023 17:10:43 GMT
Subject: RFR: 8302073: Specifying OnError handler prevents WatcherThread to
 break a deadlock in report_and_die()
In-Reply-To: <nTD9cu_uj-X-ML_g-kbPrccPTlk5NGX9iV5TLXxOpbA=.2cea728c-6dbe-41a5-b379-a75c4ebc85e0@github.com>
References: <nTD9cu_uj-X-ML_g-kbPrccPTlk5NGX9iV5TLXxOpbA=.2cea728c-6dbe-41a5-b379-a75c4ebc85e0@github.com>
Message-ID: <CUn5N-yi_dXCDLx3GFWiD6Zv4-1JnuEA7wMLs6YzNyw=.ebef2bc6-d511-4f8c-a7a0-e9b4eadb5568@github.com>

On Wed, 8 Mar 2023 14:05:44 GMT, Alexey Pavlyutkin <duke at openjdk.org> wrote:

> The patch fixes error reporting to check timeout in the case when a user specifies OnError hander. Before VMError:check_timeout() ignored timeout in this case, and so didn't break malloc() deadlock.
> 
> Verification (amd64/20.04LTS): the idea of the test is to crash JVM running with error hander of 3 successive `sleep` commands for 1s, 10s, and 60s with and without specified timeout
> 
> 
> 16:52:17 at alex@alex-VirtualBox>( echo "
> public class C {
>   public static void main(String[] args) throws Throwable {
>>     while (true) Thread.sleep(1000);
>>   }
>> }
>> " >> C.java )
> 16:57:35 at alex@alex-VirtualBox>./build/linux-x86_64-server-release/images/jdk/bin/java -XX:OnError='sleep 1;sleep 10;sleep 60' ./C.java &
> [2] 179574
> 17:00:19 at alex@alex-VirtualBox>kill -s SIGSEGV 179574
> 17:00:27 at alex@alex-VirtualBox>#
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGSEGV (0xb) at pc=0x00007f7b1701ecd5 (sent by kill), pid=179574, tid=179574
> #
> # JRE version: OpenJDK Runtime Environment (21.0) (build 21-internal-adhoc.alex.jdk)
> # Java VM: OpenJDK 64-Bit Server VM (21-internal-adhoc.alex.jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
> # Problematic frame:
> # C  [libpthread.so.0+0x9cd5]  __pthread_clockjoin_ex+0x255
> #
> # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P %E" (or dumping to /home/alex/jdk/core.179574)
> #
> # An error report file with more information is saved as:
> # /home/alex/jdk/hs_err_pid179574.log
> #
> # If you would like to submit a bug report, please visit:
> #   https://bugreport.java.com/bugreport/crash.jsp
> #
> #
> # -XX:OnError="sleep 1;sleep 10;sleep 60"
> #   Executing /bin/sh -c "sleep 1" ...
> #   Executing /bin/sh -c "sleep 10" ...
> #   Executing /bin/sh -c "sleep 60" ...
> 
> [2]+  Aborted                 (core dumped) ./build/linux-x86_64-server-release/images/jdk/bin/java -XX:OnError='sleep 1;sleep 10;sleep 60' ./C.java
> 17:02:03 at alex@alex-VirtualBox>./build/linux-x86_64-server-release/images/jdk/bin/java -XX:ErrorLogTimeout=5 -XX:OnError='sleep 1;sleep 10;sleep 60' ./C.java &
> [2] 179602
> 17:02:32 at alex@alex-VirtualBox>kill -s SIGSEGV 179602
> 17:02:41 at alex@alex-VirtualBox>#
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGSEGV (0xb) at pc=0x00007f9d71b18cd5 (sent by kill), pid=179602, tid=179602
> #
> # JRE version: OpenJDK Runtime Environment (21.0) (build 21-internal-adhoc.alex.jdk)
> # Java VM: OpenJDK 64-Bit Server VM (21-internal-adhoc.alex.jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
> # Problematic frame:
> # C  [libpthread.so.0+0x9cd5]  __pthread_clockjoin_ex+0x255
> #
> # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P %E" (or dumping to /home/alex/jdk/core.179602)
> #
> # An error report file with more information is saved as:
> # /home/alex/jdk/hs_err_pid179602.log
> #
> # If you would like to submit a bug report, please visit:
> #   https://bugreport.java.com/bugreport/crash.jsp
> #
> #
> # -XX:OnError="sleep 1;sleep 10;sleep 60"
> #   Executing /bin/sh -c "sleep 1" ...
> #   Executing /bin/sh -c "sleep 10" ...
> 
> ------ Timeout during error reporting after 11 s. ------
> 
> 17:02:54 at alex@alex-VirtualBox>
> 
> 
> Regression (amd64/20.04LTS): `test/hotspot/jtreg/runtime/ErrorHandling` with different combinations of `-vmoption:-XX:ErrorLogTimeout=10` and `-vmoption:-XX:OnError='sleep 10'`

Thinking this through some more, I'm starting to doubt we do the right thing here. It is certainly convoluted: we *are* the reporting thread here, so what happens is that:
- after fork_and_exec, we call check_timeout
- check_timeout will signal ourself
- we receive the signal
- we enter the secondary signal handler recursively
- we then re-enter VMError::report_and_die
- we then note that this is a timeout and print an error message and call os::die.

That is too complicated for my taste, and I don't know if there are any hidden issues with VM::check_timeout(). Since now, we call it from two threads, possibly, the reporting thread and the watcher thread. That function was not intended for concurrent usage.

And before thinking about the correct behavior, we need to clarify if the protection we grant an OnError invocation extends to the whole chain of error scripts. Right now we say OnError scripts should not be interrupted. Okay, but what about the next OnError script? If the user specifies several OnError scripts, should they all get a chance to run to finish? 

Because denying the follow-up error scripts a chance to run feels weirdly arbitrary. Either those scripts are essential, or they aren't. If they are, all should run. If they are not, it should be okay to kill the JVM *while it is waiting for the child process to finish* - this would make the patch simpler, and people argue that this would be the correct behavior anyway.

Personally, I think that killing the JVM while it is in waitpid waiting for the child is probably benign. Child would be reparented, possibly zombified on badly set up systems, but that's it. It would probably run to completion.

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

> 1358: 
> 1359: namespace {
> 1360:   class ForkAndExecCheckPoint : public StackObj {

Nit: checkpoint sounds quite specific, and here is nothing checked. Also, this just guards only OnError usages of fork_and_exec, not possible other usages, so maybe "OnErrorInProgress" or something?

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

> 1360:   class ForkAndExecCheckPoint : public StackObj {
> 1361:     NONCOPYABLE( ForkAndExecCheckPoint );
> 1362:     static int _in_progress;

Must be volatile, I think.

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

> 1364:     ForkAndExecCheckPoint() {
> 1365:       assert(Atomic::load(&_in_progress) == 0, "fork_and_exec() is already in progress");
> 1366:       Atomic::store(&_in_progress, 1);

I'd do a CAS.

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

> 1690:       {
> 1691:         // suspend timeout detection and run the command
> 1692:         ForkAndExecCheckPoint chechpoint;

typo

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

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

From stuefe at openjdk.org  Wed Mar  8 17:21:18 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 8 Mar 2023 17:21:18 GMT
Subject: RFR: 8302073: Specifying OnError handler prevents WatcherThread to
 break a deadlock in report_and_die()
In-Reply-To: <nTD9cu_uj-X-ML_g-kbPrccPTlk5NGX9iV5TLXxOpbA=.2cea728c-6dbe-41a5-b379-a75c4ebc85e0@github.com>
References: <nTD9cu_uj-X-ML_g-kbPrccPTlk5NGX9iV5TLXxOpbA=.2cea728c-6dbe-41a5-b379-a75c4ebc85e0@github.com>
Message-ID: <k9wKuvOyzPUxNzE_aHGg_Abr5gckbriofiHDuMmhfps=.51b99d4a-8f1f-4134-8121-3738f2b13e41@github.com>

On Wed, 8 Mar 2023 14:05:44 GMT, Alexey Pavlyutkin <duke at openjdk.org> wrote:

> The patch fixes error reporting to check timeout in the case when a user specifies OnError hander. Before VMError:check_timeout() ignored timeout in this case, and so didn't break malloc() deadlock.
> 
> Verification (amd64/20.04LTS): the idea of the test is to crash JVM running with error hander of 3 successive `sleep` commands for 1s, 10s, and 60s with and without specified timeout
> 
> 
> 16:52:17 at alex@alex-VirtualBox>( echo "
> public class C {
>   public static void main(String[] args) throws Throwable {
>>     while (true) Thread.sleep(1000);
>>   }
>> }
>> " >> C.java )
> 16:57:35 at alex@alex-VirtualBox>./build/linux-x86_64-server-release/images/jdk/bin/java -XX:OnError='sleep 1;sleep 10;sleep 60' ./C.java &
> [2] 179574
> 17:00:19 at alex@alex-VirtualBox>kill -s SIGSEGV 179574
> 17:00:27 at alex@alex-VirtualBox>#
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGSEGV (0xb) at pc=0x00007f7b1701ecd5 (sent by kill), pid=179574, tid=179574
> #
> # JRE version: OpenJDK Runtime Environment (21.0) (build 21-internal-adhoc.alex.jdk)
> # Java VM: OpenJDK 64-Bit Server VM (21-internal-adhoc.alex.jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
> # Problematic frame:
> # C  [libpthread.so.0+0x9cd5]  __pthread_clockjoin_ex+0x255
> #
> # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P %E" (or dumping to /home/alex/jdk/core.179574)
> #
> # An error report file with more information is saved as:
> # /home/alex/jdk/hs_err_pid179574.log
> #
> # If you would like to submit a bug report, please visit:
> #   https://bugreport.java.com/bugreport/crash.jsp
> #
> #
> # -XX:OnError="sleep 1;sleep 10;sleep 60"
> #   Executing /bin/sh -c "sleep 1" ...
> #   Executing /bin/sh -c "sleep 10" ...
> #   Executing /bin/sh -c "sleep 60" ...
> 
> [2]+  Aborted                 (core dumped) ./build/linux-x86_64-server-release/images/jdk/bin/java -XX:OnError='sleep 1;sleep 10;sleep 60' ./C.java
> 17:02:03 at alex@alex-VirtualBox>./build/linux-x86_64-server-release/images/jdk/bin/java -XX:ErrorLogTimeout=5 -XX:OnError='sleep 1;sleep 10;sleep 60' ./C.java &
> [2] 179602
> 17:02:32 at alex@alex-VirtualBox>kill -s SIGSEGV 179602
> 17:02:41 at alex@alex-VirtualBox>#
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGSEGV (0xb) at pc=0x00007f9d71b18cd5 (sent by kill), pid=179602, tid=179602
> #
> # JRE version: OpenJDK Runtime Environment (21.0) (build 21-internal-adhoc.alex.jdk)
> # Java VM: OpenJDK 64-Bit Server VM (21-internal-adhoc.alex.jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
> # Problematic frame:
> # C  [libpthread.so.0+0x9cd5]  __pthread_clockjoin_ex+0x255
> #
> # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P %E" (or dumping to /home/alex/jdk/core.179602)
> #
> # An error report file with more information is saved as:
> # /home/alex/jdk/hs_err_pid179602.log
> #
> # If you would like to submit a bug report, please visit:
> #   https://bugreport.java.com/bugreport/crash.jsp
> #
> #
> # -XX:OnError="sleep 1;sleep 10;sleep 60"
> #   Executing /bin/sh -c "sleep 1" ...
> #   Executing /bin/sh -c "sleep 10" ...
> 
> ------ Timeout during error reporting after 11 s. ------
> 
> 17:02:54 at alex@alex-VirtualBox>
> 
> 
> Regression (amd64/20.04LTS): `test/hotspot/jtreg/runtime/ErrorHandling` with different combinations of `-vmoption:-XX:ErrorLogTimeout=10` and `-vmoption:-XX:OnError='sleep 10'`

Pinging @dholmes-ora for input and opinion

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

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

From qamai at openjdk.org  Wed Mar  8 17:24:50 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 8 Mar 2023 17:24:50 GMT
Subject: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice [v3]
In-Reply-To: <uChb9T7MpJCsrPVNUDMpyd3g1nGaEAOlc36gCFVmEQI=.2a9264de-b228-4d6f-a565-554520b43da4@github.com>
References: <uChb9T7MpJCsrPVNUDMpyd3g1nGaEAOlc36gCFVmEQI=.2a9264de-b228-4d6f-a565-554520b43da4@github.com>
Message-ID: <Vv8GXg6Y_iqSAT1icz67rdnEWGF2xV9xxWJXrqdBXB4=.351daf31-2fe3-41dc-bb7a-cdadb8accc1b@github.com>

> `Vector::slice` is a method at the top-level class of the Vector API that concatenates the 2 inputs into an intermediate composite and extracts a window equal to the size of the inputs into the result. It is used in vector conversion methods where the part number is not 0 to slice the parts to the correct positions. Slicing is also used in text processing such as utf8 and utf16 validation. x86 starting from SSSE3 has `palignr` which does vector slicing very efficiently. As a result, I think it is beneficial to add a C2 node for this operation as well as intrinsify `Vector::slice` method.
> 
> A slice is currently implemented as `v2.rearrange(iota).blend(v1.rearrange(iota), blendMask)` which requires preparation of the index vector and the blending mask. Even with the preparations being hoisted out of the loops, microbenchmarks show improvement using the slice instrinsics. Some have tremendous increases in throughput due to the limitation that a mask of length 2 cannot currently be intrinsified, leading to falling back to the Java implementations.
> 
> Please take a look and have some reviews. Thank you very much.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  add comments explaining anonymous classes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12909/files
  - new: https://git.openjdk.org/jdk/pull/12909/files/65409f13..c31fdfe8

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

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

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

From qamai at openjdk.org  Wed Mar  8 17:24:55 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 8 Mar 2023 17:24:55 GMT
Subject: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice [v2]
In-Reply-To: <ViduD2N5x51q_1AVqeNsmCCm1DeGrk8g44Fm5dcIxyc=.a3f64564-7d8f-43bb-b071-7c594c477303@github.com>
References: <uChb9T7MpJCsrPVNUDMpyd3g1nGaEAOlc36gCFVmEQI=.2a9264de-b228-4d6f-a565-554520b43da4@github.com>
 <zl9Z45hS-RdsVbGaLTk-5mg0vuoJKdGdIqw-mouFUF4=.39131710-2e7d-46b3-b343-5dfbd27a40d3@github.com>
 <ViduD2N5x51q_1AVqeNsmCCm1DeGrk8g44Fm5dcIxyc=.a3f64564-7d8f-43bb-b071-7c594c477303@github.com>
Message-ID: <vTg3rbJUvQsMC2P9K-7yYf4L2Azfpq_uPPq0k1ilGcg=.78c07a6f-1ef8-4182-bd9e-9ec4e5d3557d@github.com>

On Wed, 8 Mar 2023 16:23:16 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address reviews
>
> Java changes look good. The HotSpot code looks well structured but i will let others comment on the specifics.

@PaulSandoz Thanks for your review, I have added a comment explaining the rationales behind the anonymous class usage.

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

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

From duke at openjdk.org  Wed Mar  8 18:03:20 2023
From: duke at openjdk.org (Alexey Pavlyutkin)
Date: Wed, 8 Mar 2023 18:03:20 GMT
Subject: RFR: 8302073: Specifying OnError handler prevents WatcherThread to
 break a deadlock in report_and_die()
In-Reply-To: <CUn5N-yi_dXCDLx3GFWiD6Zv4-1JnuEA7wMLs6YzNyw=.ebef2bc6-d511-4f8c-a7a0-e9b4eadb5568@github.com>
References: <nTD9cu_uj-X-ML_g-kbPrccPTlk5NGX9iV5TLXxOpbA=.2cea728c-6dbe-41a5-b379-a75c4ebc85e0@github.com>
 <CUn5N-yi_dXCDLx3GFWiD6Zv4-1JnuEA7wMLs6YzNyw=.ebef2bc6-d511-4f8c-a7a0-e9b4eadb5568@github.com>
Message-ID: <f74PNsGGjMKBG_ZZXbjtuieT6Nl3XrLzIRm2ZVpLxPY=.b4623052-804b-44ff-b043-b0f7b691daa3@github.com>

On Wed, 8 Mar 2023 15:49:06 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> The patch fixes error reporting to check timeout in the case when a user specifies OnError hander. Before VMError:check_timeout() ignored timeout in this case, and so didn't break malloc() deadlock.
>> 
>> Verification (amd64/20.04LTS): the idea of the test is to crash JVM running with error hander of 3 successive `sleep` commands for 1s, 10s, and 60s with and without specified timeout
>> 
>> 
>> 16:52:17 at alex@alex-VirtualBox>( echo "
>> public class C {
>>   public static void main(String[] args) throws Throwable {
>>>     while (true) Thread.sleep(1000);
>>>   }
>>> }
>>> " >> C.java )
>> 16:57:35 at alex@alex-VirtualBox>./build/linux-x86_64-server-release/images/jdk/bin/java -XX:OnError='sleep 1;sleep 10;sleep 60' ./C.java &
>> [2] 179574
>> 17:00:19 at alex@alex-VirtualBox>kill -s SIGSEGV 179574
>> 17:00:27 at alex@alex-VirtualBox>#
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  SIGSEGV (0xb) at pc=0x00007f7b1701ecd5 (sent by kill), pid=179574, tid=179574
>> #
>> # JRE version: OpenJDK Runtime Environment (21.0) (build 21-internal-adhoc.alex.jdk)
>> # Java VM: OpenJDK 64-Bit Server VM (21-internal-adhoc.alex.jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
>> # Problematic frame:
>> # C  [libpthread.so.0+0x9cd5]  __pthread_clockjoin_ex+0x255
>> #
>> # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P %E" (or dumping to /home/alex/jdk/core.179574)
>> #
>> # An error report file with more information is saved as:
>> # /home/alex/jdk/hs_err_pid179574.log
>> #
>> # If you would like to submit a bug report, please visit:
>> #   https://bugreport.java.com/bugreport/crash.jsp
>> #
>> #
>> # -XX:OnError="sleep 1;sleep 10;sleep 60"
>> #   Executing /bin/sh -c "sleep 1" ...
>> #   Executing /bin/sh -c "sleep 10" ...
>> #   Executing /bin/sh -c "sleep 60" ...
>> 
>> [2]+  Aborted                 (core dumped) ./build/linux-x86_64-server-release/images/jdk/bin/java -XX:OnError='sleep 1;sleep 10;sleep 60' ./C.java
>> 17:02:03 at alex@alex-VirtualBox>./build/linux-x86_64-server-release/images/jdk/bin/java -XX:ErrorLogTimeout=5 -XX:OnError='sleep 1;sleep 10;sleep 60' ./C.java &
>> [2] 179602
>> 17:02:32 at alex@alex-VirtualBox>kill -s SIGSEGV 179602
>> 17:02:41 at alex@alex-VirtualBox>#
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  SIGSEGV (0xb) at pc=0x00007f9d71b18cd5 (sent by kill), pid=179602, tid=179602
>> #
>> # JRE version: OpenJDK Runtime Environment (21.0) (build 21-internal-adhoc.alex.jdk)
>> # Java VM: OpenJDK 64-Bit Server VM (21-internal-adhoc.alex.jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
>> # Problematic frame:
>> # C  [libpthread.so.0+0x9cd5]  __pthread_clockjoin_ex+0x255
>> #
>> # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P %E" (or dumping to /home/alex/jdk/core.179602)
>> #
>> # An error report file with more information is saved as:
>> # /home/alex/jdk/hs_err_pid179602.log
>> #
>> # If you would like to submit a bug report, please visit:
>> #   https://bugreport.java.com/bugreport/crash.jsp
>> #
>> #
>> # -XX:OnError="sleep 1;sleep 10;sleep 60"
>> #   Executing /bin/sh -c "sleep 1" ...
>> #   Executing /bin/sh -c "sleep 10" ...
>> 
>> ------ Timeout during error reporting after 11 s. ------
>> 
>> 17:02:54 at alex@alex-VirtualBox>
>> 
>> 
>> Regression (amd64/20.04LTS): `test/hotspot/jtreg/runtime/ErrorHandling` with different combinations of `-vmoption:-XX:ErrorLogTimeout=10` and `-vmoption:-XX:OnError='sleep 10'`
>
> src/hotspot/share/utilities/vmError.cpp line 1360:
> 
>> 1358: 
>> 1359: namespace {
>> 1360:   class ForkAndExecCheckPoint : public StackObj {
> 
> Nit: checkpoint sounds quite specific, and here is nothing checked. Also, this just guards only OnError usages of fork_and_exec, not possible other usages, so maybe "OnErrorInProgress" or something?

ok

> src/hotspot/share/utilities/vmError.cpp line 1362:
> 
>> 1360:   class ForkAndExecCheckPoint : public StackObj {
>> 1361:     NONCOPYABLE( ForkAndExecCheckPoint );
>> 1362:     static int _in_progress;
> 
> Must be volatile, I think.

sure

> src/hotspot/share/utilities/vmError.cpp line 1366:
> 
>> 1364:     ForkAndExecCheckPoint() {
>> 1365:       assert(Atomic::load(&_in_progress) == 0, "fork_and_exec() is already in progress");
>> 1366:       Atomic::store(&_in_progress, 1);
> 
> I'd do a CAS.

Initially I used exactly xchg(), but it causes full memory fence. On other hand report_and_die() seems the last place to care about performance

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

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

From duke at openjdk.org  Wed Mar  8 18:14:07 2023
From: duke at openjdk.org (Alexey Pavlyutkin)
Date: Wed, 8 Mar 2023 18:14:07 GMT
Subject: RFR: 8302073: Specifying OnError handler prevents WatcherThread to
 break a deadlock in report_and_die()
In-Reply-To: <nTD9cu_uj-X-ML_g-kbPrccPTlk5NGX9iV5TLXxOpbA=.2cea728c-6dbe-41a5-b379-a75c4ebc85e0@github.com>
References: <nTD9cu_uj-X-ML_g-kbPrccPTlk5NGX9iV5TLXxOpbA=.2cea728c-6dbe-41a5-b379-a75c4ebc85e0@github.com>
Message-ID: <kFNbqSJr4ot5jWH0hZtYqgtmg_rqNH9H_9hZfUfB06c=.e6587a3e-b23e-401e-8cd3-76e80b46d9c5@github.com>

On Wed, 8 Mar 2023 14:05:44 GMT, Alexey Pavlyutkin <duke at openjdk.org> wrote:

> The patch fixes error reporting to check timeout in the case when a user specifies OnError hander. Before VMError:check_timeout() ignored timeout in this case, and so didn't break malloc() deadlock.
> 
> Verification (amd64/20.04LTS): the idea of the test is to crash JVM running with error hander of 3 successive `sleep` commands for 1s, 10s, and 60s with and without specified timeout
> 
> 
> 16:52:17 at alex@alex-VirtualBox>( echo "
> public class C {
>   public static void main(String[] args) throws Throwable {
>>     while (true) Thread.sleep(1000);
>>   }
>> }
>> " >> C.java )
> 16:57:35 at alex@alex-VirtualBox>./build/linux-x86_64-server-release/images/jdk/bin/java -XX:OnError='sleep 1;sleep 10;sleep 60' ./C.java &
> [2] 179574
> 17:00:19 at alex@alex-VirtualBox>kill -s SIGSEGV 179574
> 17:00:27 at alex@alex-VirtualBox>#
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGSEGV (0xb) at pc=0x00007f7b1701ecd5 (sent by kill), pid=179574, tid=179574
> #
> # JRE version: OpenJDK Runtime Environment (21.0) (build 21-internal-adhoc.alex.jdk)
> # Java VM: OpenJDK 64-Bit Server VM (21-internal-adhoc.alex.jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
> # Problematic frame:
> # C  [libpthread.so.0+0x9cd5]  __pthread_clockjoin_ex+0x255
> #
> # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P %E" (or dumping to /home/alex/jdk/core.179574)
> #
> # An error report file with more information is saved as:
> # /home/alex/jdk/hs_err_pid179574.log
> #
> # If you would like to submit a bug report, please visit:
> #   https://bugreport.java.com/bugreport/crash.jsp
> #
> #
> # -XX:OnError="sleep 1;sleep 10;sleep 60"
> #   Executing /bin/sh -c "sleep 1" ...
> #   Executing /bin/sh -c "sleep 10" ...
> #   Executing /bin/sh -c "sleep 60" ...
> 
> [2]+  Aborted                 (core dumped) ./build/linux-x86_64-server-release/images/jdk/bin/java -XX:OnError='sleep 1;sleep 10;sleep 60' ./C.java
> 17:02:03 at alex@alex-VirtualBox>./build/linux-x86_64-server-release/images/jdk/bin/java -XX:ErrorLogTimeout=5 -XX:OnError='sleep 1;sleep 10;sleep 60' ./C.java &
> [2] 179602
> 17:02:32 at alex@alex-VirtualBox>kill -s SIGSEGV 179602
> 17:02:41 at alex@alex-VirtualBox>#
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGSEGV (0xb) at pc=0x00007f9d71b18cd5 (sent by kill), pid=179602, tid=179602
> #
> # JRE version: OpenJDK Runtime Environment (21.0) (build 21-internal-adhoc.alex.jdk)
> # Java VM: OpenJDK 64-Bit Server VM (21-internal-adhoc.alex.jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
> # Problematic frame:
> # C  [libpthread.so.0+0x9cd5]  __pthread_clockjoin_ex+0x255
> #
> # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P %E" (or dumping to /home/alex/jdk/core.179602)
> #
> # An error report file with more information is saved as:
> # /home/alex/jdk/hs_err_pid179602.log
> #
> # If you would like to submit a bug report, please visit:
> #   https://bugreport.java.com/bugreport/crash.jsp
> #
> #
> # -XX:OnError="sleep 1;sleep 10;sleep 60"
> #   Executing /bin/sh -c "sleep 1" ...
> #   Executing /bin/sh -c "sleep 10" ...
> 
> ------ Timeout during error reporting after 11 s. ------
> 
> 17:02:54 at alex@alex-VirtualBox>
> 
> 
> Regression (amd64/20.04LTS): `test/hotspot/jtreg/runtime/ErrorHandling` with different combinations of `-vmoption:-XX:ErrorLogTimeout=10` and `-vmoption:-XX:OnError='sleep 10'`

> Thinking this through some more, I'm starting to doubt we do the right thing here. It is certainly convoluted: we _are_ the reporting thread here, so what happens is that:
> 
> * after fork_and_exec, we call check_timeout
> * check_timeout will signal ourself
> * we receive the signal
> * we enter the secondary signal handler recursively
> * we then re-enter VMError::report_and_die
> * we then note that this is a timeout and print an error message and call os::die.
> 
> That is too complicated for my taste, and I don't know if there are any hidden issues with VM::check_timeout(). Since now, we call it from two threads, possibly, the reporting thread and the watcher thread. That function was not intended for concurrent usage.
> 
> And before thinking about the correct behavior, we need to clarify if the protection we grant an OnError invocation extends to the whole chain of error scripts. Right now we say OnError scripts should not be interrupted. Okay, but what about the next OnError script? If the user specifies several OnError scripts, should they all get a chance to run to finish?
> 
> Because denying the follow-up error scripts a chance to run feels weirdly arbitrary. Either those scripts are essential, or they aren't. If they are, all should run. If they are not, it should be okay to kill the JVM _while it is waiting for the child process to finish_ - this would make the patch simpler, and people argue that this would be the correct behavior anyway.
> 
> Personally, I think that killing the JVM while it is in waitpid waiting for the child is probably benign. Child would be reparented, possibly zombified on badly set up systems, but that's it. It would probably run to completion.

ok, let's replace check_timeout() with something like

jlong expiration = get_reporting_start_time() + ( jlong )ErrorLogTimeout * TIMESTAMP_TO_SECONDS_FACTOR;
if ( get_current_timestamp() > expiration ) break;

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

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

From rkennke at openjdk.org  Wed Mar  8 18:25:15 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 8 Mar 2023 18:25:15 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v15]
In-Reply-To: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
Message-ID: <YeXYnGbHymtoOe9eQToM1djB-pJtLWgMoCLxzAyT4vs=.cf42449e-aa0d-4f41-91c1-6066905eee43@github.com>

> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
> 
> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p
 rotocols.
> 
> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
> 
> 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
> 
> 
> Testing:
>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
> 
> ### Performance
> 
> #### Simple Microbenchmark
> 
> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
> 
> |  | x86_64 | aarch64 |
> | -- | -- | -- |
> | -UseFastLocking | 20.651 | 20.764 |
> | +UseFastLocking | 18.896 | 18.908 |
> 
> 
> #### Renaissance
> 
> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
> -- | -- | -- | -- | -- | -- | -- | --
> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%

Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:

 - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
 - Inline initial LockStack stack

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10907/files
  - new: https://git.openjdk.org/jdk/pull/10907/files/12c2b8c3..3c9d0d82

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=13-14

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

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

From pchilanomate at openjdk.org  Wed Mar  8 18:48:17 2023
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 8 Mar 2023 18:48:17 GMT
Subject: RFR: 8302779: HelidonAppTest.java fails with
 "assert(_cb == CodeCache::find_blob(pc())) failed: Must be the same" or
 SIGSEGV
In-Reply-To: <w1BvR-TnE9TcAxKBuKhjxf9vFKm29FZmXOBAaPqesgk=.17982c5b-1989-4f5d-b67f-c5c7e8968e4e@github.com>
References: <ZsPtiMn1PiOTGUiSC7GXZ196v4a7YFL5LRioo2ZCFdU=.148f395d-f892-4829-8f08-69ce7134b865@github.com>
 <w1BvR-TnE9TcAxKBuKhjxf9vFKm29FZmXOBAaPqesgk=.17982c5b-1989-4f5d-b67f-c5c7e8968e4e@github.com>
Message-ID: <9TIDrqZx-KDQ0tWE7BGiGYMSS5Ftb9y3B8OLcdPvrUs=.5cb94158-ab8b-47ea-96ba-a4e073a124d6@github.com>

On Wed, 8 Mar 2023 15:37:12 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> That's a good fix and a good place for it. Thank you for figuring this out.
>
Thanks for the review Coleen!

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

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

From mgronlun at openjdk.org  Wed Mar  8 18:50:18 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 8 Mar 2023 18:50:18 GMT
Subject: RFR: 8257967: JFR: Events for loaded agents [v3]
In-Reply-To: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
References: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
Message-ID: <s0vcoF-3AoY_7KPVvrS4c0fodfOQuLFLDskpROWsHZI=.0916ddf7-0fcf-4104-8a64-0943c924885a@github.com>

> Greetings,
> 
> We are adding support to let JFR report on Agents.
> 
> #### Design
> 
> An Agent is a library that uses any instrumentation or profiling APIs. Most agents are started and initialized on the command line, but agents can also be loaded dynamically during runtime. Because command line agents initialize during the VM startup sequence, they add to the overall startup time latency in getting the VM ready. The events will report on the time the agent took to initialize.
> 
> A JavaAgent is an agent written in the Java programming language, using the APIs in the package [java.lang.instrument](https://docs.oracle.com/en/java/javase/19/docs/api/java.instrument/java/lang/instrument/package-summary.html)
> 
> A JavaAgent is sometimes called a JPLIS agent, where the acronym JPLIS stands for Java Programming Language Instrumentation Services.
> 
> To report on JavaAgents, JFR will add the new event type jdk.JavaAgent and events will look similar to these two examples:
> 
> // Command line
> jdk.JavaAgent {
>   startTime = 12:31:19.789 (2023-03-08)
>   name = "JavaAgent.jar"
>   options = "foo=bar"
>   initialization = 12:31:15.574 (2023-03-08)
>   initializationTime = 172 ms
>   initializationMethod = "premain"
> }
> // Dynamic load
> jdk.JavaAgent {
>   startTime = 12:31:31.158 (2023-03-08)
>   name = "JavaAgent.jar"
>   options = "bar=baz"
>   initialization = 12:31:31.037 (2023-03-08)
>   initializationTime = 64,1 ms
>   initializationMethod = "agentmain"
> }
> 
> The jdk.JavaAgent event type is a JFR periodic event that iterates over running Java agents.
> 
> For a JavaAgent event, the agent's name will be the specific .jar file containing the instrumentation code. The options will be the specific options passed to the .jar file as part of launching the agent, for example, on the command line: -javaagent: JavaAgent.jar=foo=bar
> 
> The event will also detail which initialization method was invoked by the JVM, "premain" for command line agents, and "agentmain" for agents loaded dynamically.
> 
> "initialization" is the timestamp the JVM invoked the initialization method, and "initializationTime" is the duration of executing the initialization method.
> 
> "startTime" represents the time the JFR framework issued the periodic event; hence "initialization" will be earlier than "startTime".
> 
> An agent can also be written in a native programming language, using the [JVM Tools Interface (JVMTI)](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html). This kind of agent, sometimes called a native agent, is a platform-specific binary, sometimes referred to as a library, but here it means a .so or .dll file.
> 
> To report on native agents, JFR will add the new event type jdk.NativeAgent and events will look similar to this example:
> 
> jdk.NativeAgent {
>   startTime = 12:31:40.398 (2023-03-08)
>   name = "jdwp"
>   options = "transport=dt_socket,server=y,address=any,onjcmd=y"
>   path = "c:\ade\github\openjdk\jdk\build\windows-x86_64-server-slowdebug\jdk\bin\jdwp.dll"
>   dynamic = false
>   initialization = 12:31:36.142 (2023-03-08)
>   initializationTime = 0,00184 ms
> }
> 
> The layout of the event type is very similar to the jdk.JavaAgent event, but here the path to the native library is reported, and there is also a denotation if the agent was loaded via the command line (dynamic = false) or dynamically (dynamic = true).
> 
> The initialization of a native agent is performed by invoking an agent-specified callback routine which is not detailed in the event (for now). The "initialization" is the time the JVM sent or would have sent the JVMTI VMInit event to a specified callback. "initializationTime" is the duration to execute that specific callback. If no callback is specified for the JVMTI VMInit event, the "initializationTime" will be 0.
> 
> #### Implementation
> 
> There has not existed a reification of a JavaAgent directly in the JVM, as these are built on top of the JDK native library, "instrument", using a many-to-one mapping. At the level of the JVM, the only representation of agents after startup is through JvmtiEnv's, which agents request from the JVM during startup and initialization ? as such, mapping which JvmtiEnv belongs to what JavaAgent was not possible before.
> 
> Using implementation details of how the JDK native library "instrument" interacts with the JVM, we can build this mapping to track what JvmtiEnv's "belong" to what JavaAgent. This mapping now lets us report the Java-relevant context (name, options) and measure the time it takes for the JavaAgent to initialize.
> 
> To implement this capability, it was necessary to refactor the code used to represent agents, called AgentLibrary. The previous implementation was located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp.
> 
> The refactoring isolates the relevant logic into two new modules, prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their older places will help reduce the sizes of oversized arguments.cpp and threads.cpp.
> 
> The previous lists that maintain the agents (JVMTI) and libraries (JVMPI) are not thread-safe for concurrent iterations. A single list that allows for concurrent iterations is therefore introduced.
> 
> Testing: jdk_jfr, tier 1 - 6
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12923/files
  - new: https://git.openjdk.org/jdk/pull/12923/files/ed1ea797..26172f0e

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

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

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

From mgronlun at openjdk.org  Wed Mar  8 18:56:55 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 8 Mar 2023 18:56:55 GMT
Subject: RFR: 8257967: JFR: Events for loaded agents [v4]
In-Reply-To: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
References: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
Message-ID: <ifc_GVpqqnc0TVYHD1E1TnlG0jyGYcqtyNljfY3AuDY=.9dc9baf4-0331-4e6a-8745-bbdd01c62943@github.com>

> Greetings,
> 
> We are adding support to let JFR report on Agents.
> 
> #### Design
> 
> An Agent is a library that uses any instrumentation or profiling APIs. Most agents are started and initialized on the command line, but agents can also be loaded dynamically during runtime. Because command line agents initialize during the VM startup sequence, they add to the overall startup time latency in getting the VM ready. The events will report on the time the agent took to initialize.
> 
> A JavaAgent is an agent written in the Java programming language, using the APIs in the package [java.lang.instrument](https://docs.oracle.com/en/java/javase/19/docs/api/java.instrument/java/lang/instrument/package-summary.html)
> 
> A JavaAgent is sometimes called a JPLIS agent, where the acronym JPLIS stands for Java Programming Language Instrumentation Services.
> 
> To report on JavaAgents, JFR will add the new event type jdk.JavaAgent and events will look similar to these two examples:
> 
> // Command line
> jdk.JavaAgent {
>   startTime = 12:31:19.789 (2023-03-08)
>   name = "JavaAgent.jar"
>   options = "foo=bar"
>   initialization = 12:31:15.574 (2023-03-08)
>   initializationTime = 172 ms
>   initializationMethod = "premain"
> }
> // Dynamic load
> jdk.JavaAgent {
>   startTime = 12:31:31.158 (2023-03-08)
>   name = "JavaAgent.jar"
>   options = "bar=baz"
>   initialization = 12:31:31.037 (2023-03-08)
>   initializationTime = 64,1 ms
>   initializationMethod = "agentmain"
> }
> 
> The jdk.JavaAgent event type is a JFR periodic event that iterates over running Java agents.
> 
> For a JavaAgent event, the agent's name will be the specific .jar file containing the instrumentation code. The options will be the specific options passed to the .jar file as part of launching the agent, for example, on the command line: -javaagent: JavaAgent.jar=foo=bar
> 
> The event will also detail which initialization method was invoked by the JVM, "premain" for command line agents, and "agentmain" for agents loaded dynamically.
> 
> "initialization" is the timestamp the JVM invoked the initialization method, and "initializationTime" is the duration of executing the initialization method.
> 
> "startTime" represents the time the JFR framework issued the periodic event; hence "initialization" will be earlier than "startTime".
> 
> An agent can also be written in a native programming language, using the [JVM Tools Interface (JVMTI)](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html). This kind of agent, sometimes called a native agent, is a platform-specific binary, sometimes referred to as a library, but here it means a .so or .dll file.
> 
> To report on native agents, JFR will add the new event type jdk.NativeAgent and events will look similar to this example:
> 
> jdk.NativeAgent {
>   startTime = 12:31:40.398 (2023-03-08)
>   name = "jdwp"
>   options = "transport=dt_socket,server=y,address=any,onjcmd=y"
>   path = "c:\ade\github\openjdk\jdk\build\windows-x86_64-server-slowdebug\jdk\bin\jdwp.dll"
>   dynamic = false
>   initialization = 12:31:36.142 (2023-03-08)
>   initializationTime = 0,00184 ms
> }
> 
> The layout of the event type is very similar to the jdk.JavaAgent event, but here the path to the native library is reported, and there is also a denotation if the agent was loaded via the command line (dynamic = false) or dynamically (dynamic = true).
> 
> The initialization of a native agent is performed by invoking an agent-specified callback routine which is not detailed in the event (for now). The "initialization" is the time the JVM sent or would have sent the JVMTI VMInit event to a specified callback. "initializationTime" is the duration to execute that specific callback. If no callback is specified for the JVMTI VMInit event, the "initializationTime" will be 0.
> 
> #### Implementation
> 
> There has not existed a reification of a JavaAgent directly in the JVM, as these are built on top of the JDK native library, "instrument", using a many-to-one mapping. At the level of the JVM, the only representation of agents after startup is through JvmtiEnv's, which agents request from the JVM during startup and initialization ? as such, mapping which JvmtiEnv belongs to what JavaAgent was not possible before.
> 
> Using implementation details of how the JDK native library "instrument" interacts with the JVM, we can build this mapping to track what JvmtiEnv's "belong" to what JavaAgent. This mapping now lets us report the Java-relevant context (name, options) and measure the time it takes for the JavaAgent to initialize.
> 
> To implement this capability, it was necessary to refactor the code used to represent agents, called AgentLibrary. The previous implementation was located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp.
> 
> The refactoring isolates the relevant logic into two new modules, prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their older places will help reduce the sizes of oversized arguments.cpp and threads.cpp.
> 
> The previous lists that maintain the agents (JVMTI) and libraries (JVMPI) are not thread-safe for concurrent iterations. A single list that allows for concurrent iterations is therefore introduced.
> 
> Testing: jdk_jfr, tier 1 - 6
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with two additional commits since the last revision:

 - remove JVMPI
 - cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12923/files
  - new: https://git.openjdk.org/jdk/pull/12923/files/26172f0e..355d307c

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

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

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

From dnsimon at openjdk.org  Wed Mar  8 19:59:02 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 8 Mar 2023 19:59:02 GMT
Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v4]
In-Reply-To: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>
References: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>
Message-ID: <g6khATmT9PeCnbS48nLg6K2OFcDGyJYWO_qUcNRYlvs=.dbac1c27-3059-4478-bb01-64446dfafec8@github.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
> This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for accessing annotations. The main differences from `java.lang.reflect.AnnotatedElement` are:
> * Each `Annotated` method explicitly specifies the annotation type(s) for which it wants annotation data. That is, there is no direct equivalent of `AnnotatedElement.getAnnotations()`.
> * Annotation data is returned in a map-like object (of type `jdk.vm.ci.meta.AnnotationData`) instead of in an `Annotation` object. This works better for libgraal as it avoids the need for annotation types to be loaded and included in libgraal.
>  
> To demonstrate the new API, here's an example in terms `java.lang.reflect.AnnotatedElement` (which `ResolvedJavaType` implements):
> 
>     ResolvedJavaMethod method = ...;
>     ExplodeLoop a = method.getAnnotation(ExplodeLoop.class);
>     return switch (a.kind()) {
>         case FULL_UNROLL -> LoopExplosionKind.FULL_UNROLL;
>         case FULL_UNROLL_UNTIL_RETURN -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>         ...
>     }
> 
> 
> The same code using the new API:
> 
> 
>     ResolvedJavaMethod method = ...;
>     ResolvedJavaType explodeLoopType = ...;
>     AnnotationData a = method.getAnnotationDataFor(explodeLoopType);
>     return switch (a.getEnum("kind").getName()) {
>         case "FULL_UNROLL" -> LoopExplosionKind.FULL_UNROLL;
>         case "FULL_UNROLL_UNTIL_RETURN" -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>         ...
>     }
> 
> 
> The implementation relies on new methods in `jdk.internal.vm.VMSupport` for parsing annotations and serializing/deserializing to/from a byte array. This allows the annotation data to be passed from the HotSpot heap to the libgraal heap.

Doug Simon has updated the pull request incrementally with one additional commit since the last revision:

  switched to use of lists and maps instead of arrays

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12810/files
  - new: https://git.openjdk.org/jdk/pull/12810/files/3dd5ef9c..948d3aa3

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

  Stats: 1241 lines in 15 files changed: 292 ins; 718 del; 231 mod
  Patch: https://git.openjdk.org/jdk/pull/12810.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12810/head:pull/12810

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

From duke at openjdk.org  Wed Mar  8 21:10:16 2023
From: duke at openjdk.org (jsolomon8080)
Date: Wed, 8 Mar 2023 21:10:16 GMT
Subject: RFR: 8302073: Specifying OnError handler prevents WatcherThread to
 break a deadlock in report_and_die()
In-Reply-To: <nTD9cu_uj-X-ML_g-kbPrccPTlk5NGX9iV5TLXxOpbA=.2cea728c-6dbe-41a5-b379-a75c4ebc85e0@github.com>
References: <nTD9cu_uj-X-ML_g-kbPrccPTlk5NGX9iV5TLXxOpbA=.2cea728c-6dbe-41a5-b379-a75c4ebc85e0@github.com>
Message-ID: <3ZipShQ_gHqbJaO1aIg8yk-OcPwKg2D6eFJghlad5DM=.29bb804e-42a7-4d2c-b99c-31c21f663f24@github.com>

On Wed, 8 Mar 2023 14:05:44 GMT, Alexey Pavlyutkin <duke at openjdk.org> wrote:

> The patch fixes error reporting to check timeout in the case when a user specifies OnError hander. Before VMError:check_timeout() ignored timeout in this case, and so didn't break malloc() deadlock.
> 
> Verification (amd64/20.04LTS): the idea of the test is to crash JVM running with error hander of 3 successive `sleep` commands for 1s, 10s, and 60s with and without specified timeout
> 
> 
> 16:52:17 at alex@alex-VirtualBox>( echo "
> public class C {
>   public static void main(String[] args) throws Throwable {
>>     while (true) Thread.sleep(1000);
>>   }
>> }
>> " >> C.java )
> 16:57:35 at alex@alex-VirtualBox>./build/linux-x86_64-server-release/images/jdk/bin/java -XX:OnError='sleep 1;sleep 10;sleep 60' ./C.java &
> [2] 179574
> 17:00:19 at alex@alex-VirtualBox>kill -s SIGSEGV 179574
> 17:00:27 at alex@alex-VirtualBox>#
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGSEGV (0xb) at pc=0x00007f7b1701ecd5 (sent by kill), pid=179574, tid=179574
> #
> # JRE version: OpenJDK Runtime Environment (21.0) (build 21-internal-adhoc.alex.jdk)
> # Java VM: OpenJDK 64-Bit Server VM (21-internal-adhoc.alex.jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
> # Problematic frame:
> # C  [libpthread.so.0+0x9cd5]  __pthread_clockjoin_ex+0x255
> #
> # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P %E" (or dumping to /home/alex/jdk/core.179574)
> #
> # An error report file with more information is saved as:
> # /home/alex/jdk/hs_err_pid179574.log
> #
> # If you would like to submit a bug report, please visit:
> #   https://bugreport.java.com/bugreport/crash.jsp
> #
> #
> # -XX:OnError="sleep 1;sleep 10;sleep 60"
> #   Executing /bin/sh -c "sleep 1" ...
> #   Executing /bin/sh -c "sleep 10" ...
> #   Executing /bin/sh -c "sleep 60" ...
> 
> [2]+  Aborted                 (core dumped) ./build/linux-x86_64-server-release/images/jdk/bin/java -XX:OnError='sleep 1;sleep 10;sleep 60' ./C.java
> 17:02:03 at alex@alex-VirtualBox>./build/linux-x86_64-server-release/images/jdk/bin/java -XX:ErrorLogTimeout=5 -XX:OnError='sleep 1;sleep 10;sleep 60' ./C.java &
> [2] 179602
> 17:02:32 at alex@alex-VirtualBox>kill -s SIGSEGV 179602
> 17:02:41 at alex@alex-VirtualBox>#
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGSEGV (0xb) at pc=0x00007f9d71b18cd5 (sent by kill), pid=179602, tid=179602
> #
> # JRE version: OpenJDK Runtime Environment (21.0) (build 21-internal-adhoc.alex.jdk)
> # Java VM: OpenJDK 64-Bit Server VM (21-internal-adhoc.alex.jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
> # Problematic frame:
> # C  [libpthread.so.0+0x9cd5]  __pthread_clockjoin_ex+0x255
> #
> # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P %E" (or dumping to /home/alex/jdk/core.179602)
> #
> # An error report file with more information is saved as:
> # /home/alex/jdk/hs_err_pid179602.log
> #
> # If you would like to submit a bug report, please visit:
> #   https://bugreport.java.com/bugreport/crash.jsp
> #
> #
> # -XX:OnError="sleep 1;sleep 10;sleep 60"
> #   Executing /bin/sh -c "sleep 1" ...
> #   Executing /bin/sh -c "sleep 10" ...
> 
> ------ Timeout during error reporting after 11 s. ------
> 
> 17:02:54 at alex@alex-VirtualBox>
> 
> 
> Regression (amd64/20.04LTS): `test/hotspot/jtreg/runtime/ErrorHandling` with different combinations of `-vmoption:-XX:ErrorLogTimeout=10` and `-vmoption:-XX:OnError='sleep 10'`

Hi - I'm the originator of this bug report. I'm glad this is getting fixed and I will ultimately defer to the java experts since I have never contributed code to this code base, but if it were me, I'd do the simplest thing possible. The solution presented here seems overly complex. I don't understand why an OnError script or an abort_hook is so special. I think it's up to the user to ensure that neither takes longer than ErrorLogTimeout, which defaults to 2 minutes. That's an eternity. Do java users really expect to wait 2 minutes for their processes to exit?

If this were my code, I would remove any guarantee about OnError and make it responsibility of the user to set ErrorLogTimeout appropriately.

I understand that there may be many users who have counted on this guarantee and you can't break them now. I also understand that I'm not aware of all the ways that OnError is used. I'm sure we will get to some solution that will fix the real problem, which is what I care about the most. Thank you.

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

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

From dholmes at openjdk.org  Wed Mar  8 21:34:07 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 8 Mar 2023 21:34:07 GMT
Subject: RFR: 8302073: Specifying OnError handler prevents WatcherThread to
 break a deadlock in report_and_die()
In-Reply-To: <k9wKuvOyzPUxNzE_aHGg_Abr5gckbriofiHDuMmhfps=.51b99d4a-8f1f-4134-8121-3738f2b13e41@github.com>
References: <nTD9cu_uj-X-ML_g-kbPrccPTlk5NGX9iV5TLXxOpbA=.2cea728c-6dbe-41a5-b379-a75c4ebc85e0@github.com>
 <k9wKuvOyzPUxNzE_aHGg_Abr5gckbriofiHDuMmhfps=.51b99d4a-8f1f-4134-8121-3738f2b13e41@github.com>
Message-ID: <G-ReJaBrJTUBgWUmcE4eoqXQrtHCLPMSL7nQyom4QIM=.77438a77-60c9-4dc1-b811-7a71249d4358@github.com>

On Wed, 8 Mar 2023 17:18:30 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> The patch fixes error reporting to check timeout in the case when a user specifies OnError hander. Before VMError:check_timeout() ignored timeout in this case, and so didn't break malloc() deadlock.
>> 
>> Verification (amd64/20.04LTS): the idea of the test is to crash JVM running with error hander of 3 successive `sleep` commands for 1s, 10s, and 60s with and without specified timeout
>> 
>> 
>> 16:52:17 at alex@alex-VirtualBox>( echo "
>> public class C {
>>   public static void main(String[] args) throws Throwable {
>>>     while (true) Thread.sleep(1000);
>>>   }
>>> }
>>> " >> C.java )
>> 16:57:35 at alex@alex-VirtualBox>./build/linux-x86_64-server-release/images/jdk/bin/java -XX:OnError='sleep 1;sleep 10;sleep 60' ./C.java &
>> [2] 179574
>> 17:00:19 at alex@alex-VirtualBox>kill -s SIGSEGV 179574
>> 17:00:27 at alex@alex-VirtualBox>#
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  SIGSEGV (0xb) at pc=0x00007f7b1701ecd5 (sent by kill), pid=179574, tid=179574
>> #
>> # JRE version: OpenJDK Runtime Environment (21.0) (build 21-internal-adhoc.alex.jdk)
>> # Java VM: OpenJDK 64-Bit Server VM (21-internal-adhoc.alex.jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
>> # Problematic frame:
>> # C  [libpthread.so.0+0x9cd5]  __pthread_clockjoin_ex+0x255
>> #
>> # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P %E" (or dumping to /home/alex/jdk/core.179574)
>> #
>> # An error report file with more information is saved as:
>> # /home/alex/jdk/hs_err_pid179574.log
>> #
>> # If you would like to submit a bug report, please visit:
>> #   https://bugreport.java.com/bugreport/crash.jsp
>> #
>> #
>> # -XX:OnError="sleep 1;sleep 10;sleep 60"
>> #   Executing /bin/sh -c "sleep 1" ...
>> #   Executing /bin/sh -c "sleep 10" ...
>> #   Executing /bin/sh -c "sleep 60" ...
>> 
>> [2]+  Aborted                 (core dumped) ./build/linux-x86_64-server-release/images/jdk/bin/java -XX:OnError='sleep 1;sleep 10;sleep 60' ./C.java
>> 17:02:03 at alex@alex-VirtualBox>./build/linux-x86_64-server-release/images/jdk/bin/java -XX:ErrorLogTimeout=5 -XX:OnError='sleep 1;sleep 10;sleep 60' ./C.java &
>> [2] 179602
>> 17:02:32 at alex@alex-VirtualBox>kill -s SIGSEGV 179602
>> 17:02:41 at alex@alex-VirtualBox>#
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  SIGSEGV (0xb) at pc=0x00007f9d71b18cd5 (sent by kill), pid=179602, tid=179602
>> #
>> # JRE version: OpenJDK Runtime Environment (21.0) (build 21-internal-adhoc.alex.jdk)
>> # Java VM: OpenJDK 64-Bit Server VM (21-internal-adhoc.alex.jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
>> # Problematic frame:
>> # C  [libpthread.so.0+0x9cd5]  __pthread_clockjoin_ex+0x255
>> #
>> # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P %E" (or dumping to /home/alex/jdk/core.179602)
>> #
>> # An error report file with more information is saved as:
>> # /home/alex/jdk/hs_err_pid179602.log
>> #
>> # If you would like to submit a bug report, please visit:
>> #   https://bugreport.java.com/bugreport/crash.jsp
>> #
>> #
>> # -XX:OnError="sleep 1;sleep 10;sleep 60"
>> #   Executing /bin/sh -c "sleep 1" ...
>> #   Executing /bin/sh -c "sleep 10" ...
>> 
>> ------ Timeout during error reporting after 11 s. ------
>> 
>> 17:02:54 at alex@alex-VirtualBox>
>> 
>> 
>> Regression (amd64/20.04LTS): `test/hotspot/jtreg/runtime/ErrorHandling` with different combinations of `-vmoption:-XX:ErrorLogTimeout=10` and `-vmoption:-XX:OnError='sleep 10'`
>
> Pinging @dholmes-ora for input and opinion

I thought we were still discussing options in JBS so this PR seems premature to me. I agree with @tstuefe initial comment this seems way too complex and I'm not even sure I can figure out the control flow here.

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

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

From dcubed at openjdk.org  Wed Mar  8 22:25:25 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 8 Mar 2023 22:25:25 GMT
Subject: RFR: 8300926: Several startup regressions ~6-70% in 21-b6 all
 platforms [v8]
In-Reply-To: <z7_2sNpjnL2JYEhq-L6S6VvxwrCEZlHX7EDZx4do_Dw=.783bbdcb-bc62-46f0-83a4-70e6785b9fe0@github.com>
References: <yAP6c7wzGguBfKuzvbjMZdnaqydAz4PFn0pgR1UGj9s=.ce872f5d-3f7a-4e24-99d5-da5e80855ea4@github.com>
 <z7_2sNpjnL2JYEhq-L6S6VvxwrCEZlHX7EDZx4do_Dw=.783bbdcb-bc62-46f0-83a4-70e6785b9fe0@github.com>
Message-ID: <N7nXAkBhgQAQzYqUxhSA6H1Ytiwf4mLw3g4CmfB8p6s=.ed56ed80-0083-46f5-b00b-81843d3e0aa7@github.com>

On Tue, 7 Mar 2023 13:47:55 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi all, please consider.
>> 
>> The original issue was when thread 1 asked to deopt nmethod set X and thread 2 asked for the same or a subset of X.
>> All method will already be marked, but the actual deoptimizing, not entrant, patching PC on stacks and patching post call nops, was not done yet. Which meant thread 2 could 'pass' thread 1.
>> Most places did deopt under Compile_lock, thus this is not an issue, but WB and clearCallSiteContext do not.
>> 
>> Since a handshakes may take long before completion and Compile_lock is used for so much more than deopts.
>> The fix in https://bugs.openjdk.org/browse/JDK-8299074 instead always emitted a handshake even when everything was already marked. (instead of adding Compile_lock to all places)
>> 
>> This turnout to be problematic in the startup, for example the number of deopt handshakes in jetty dry run startup went from 5 to 39 handshakes.
>> 
>> This fix first adds a barrier for which you do not pass until the requested deopts have happened and it coalesces the handshakes.
>> Secondly it moves handshakes part out of the Compile_lock where it is possible.
>> 
>> Which means we fix the performance bug and we reduce the contention on Compile_lock, meaning higher throughput in compiler and things such as class-loading.
>> 
>> It passes t1-t7 with flying colours! t8 still not completed and I'm redoing some testing due to last minute simplifications.
>> 
>> Thanks, Robbin
>
> Robbin Ehn has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Grab lock so code() is stable
>  - Non CHA based vtables fix

Re-reviewed v06 (main merge) and v07. Still thumbs up.

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

Marked as reviewed by dcubed (Reviewer).

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

From dnsimon at openjdk.org  Wed Mar  8 22:59:23 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 8 Mar 2023 22:59:23 GMT
Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v5]
In-Reply-To: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>
References: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>
Message-ID: <gYzscs7Y8uz2l_5FIsqAuKebVsMnJpSwbIH6C_uzdv4=.f33d8432-c1fc-45a3-80f7-1159cdb87480@github.com>

> This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for accessing annotations. The main differences from `java.lang.reflect.AnnotatedElement` are:
> * Each `Annotated` method explicitly specifies the annotation type(s) for which it wants annotation data. That is, there is no direct equivalent of `AnnotatedElement.getAnnotations()`.
> * Annotation data is returned in a map-like object (of type `jdk.vm.ci.meta.AnnotationData`) instead of in an `Annotation` object. This works better for libgraal as it avoids the need for annotation types to be loaded and included in libgraal.
>  
> To demonstrate the new API, here's an example in terms `java.lang.reflect.AnnotatedElement` (which `ResolvedJavaType` implements):
> 
>     ResolvedJavaMethod method = ...;
>     ExplodeLoop a = method.getAnnotation(ExplodeLoop.class);
>     return switch (a.kind()) {
>         case FULL_UNROLL -> LoopExplosionKind.FULL_UNROLL;
>         case FULL_UNROLL_UNTIL_RETURN -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>         ...
>     }
> 
> 
> The same code using the new API:
> 
> 
>     ResolvedJavaMethod method = ...;
>     ResolvedJavaType explodeLoopType = ...;
>     AnnotationData a = method.getAnnotationDataFor(explodeLoopType);
>     return switch (a.getEnum("kind").getName()) {
>         case "FULL_UNROLL" -> LoopExplosionKind.FULL_UNROLL;
>         case "FULL_UNROLL_UNTIL_RETURN" -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>         ...
>     }
> 
> 
> The implementation relies on new methods in `jdk.internal.vm.VMSupport` for parsing annotations and serializing/deserializing to/from a byte array. This allows the annotation data to be passed from the HotSpot heap to the libgraal heap.

Doug Simon 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 remote-tracking branch 'openjdk-jdk/master' into JDK-8303431
 - switched to use of lists and maps instead of arrays
 - fixed whitespace
 - added support for inherited annotations
 - Merge branch 'master' into JDK-8303431
 - made AnnotationDataDecoder package-private
 - add annotation API to JVMCI

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

Changes: https://git.openjdk.org/jdk/pull/12810/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12810&range=04
  Stats: 2326 lines in 34 files changed: 2273 ins; 23 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/12810.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12810/head:pull/12810

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

From dholmes at openjdk.org  Wed Mar  8 23:02:17 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 8 Mar 2023 23:02:17 GMT
Subject: RFR: 8257967: JFR: Events for loaded agents [v4]
In-Reply-To: <ifc_GVpqqnc0TVYHD1E1TnlG0jyGYcqtyNljfY3AuDY=.9dc9baf4-0331-4e6a-8745-bbdd01c62943@github.com>
References: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
 <ifc_GVpqqnc0TVYHD1E1TnlG0jyGYcqtyNljfY3AuDY=.9dc9baf4-0331-4e6a-8745-bbdd01c62943@github.com>
Message-ID: <MEaC0tZz0wRYqjruWeE1-1ig25xS8f0w_wkO8k6ZJzk=.33473403-7f73-421c-84c0-24f2fdf2a3e3@github.com>

On Wed, 8 Mar 2023 18:56:55 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> We are adding support to let JFR report on Agents.
>> 
>> #### Design
>> 
>> An Agent is a library that uses any instrumentation or profiling APIs. Most agents are started and initialized on the command line, but agents can also be loaded dynamically during runtime. Because command line agents initialize during the VM startup sequence, they add to the overall startup time latency in getting the VM ready. The events will report on the time the agent took to initialize.
>> 
>> A JavaAgent is an agent written in the Java programming language, using the APIs in the package [java.lang.instrument](https://docs.oracle.com/en/java/javase/19/docs/api/java.instrument/java/lang/instrument/package-summary.html)
>> 
>> A JavaAgent is sometimes called a JPLIS agent, where the acronym JPLIS stands for Java Programming Language Instrumentation Services.
>> 
>> To report on JavaAgents, JFR will add the new event type jdk.JavaAgent and events will look similar to these two examples:
>> 
>> // Command line
>> jdk.JavaAgent {
>>   startTime = 12:31:19.789 (2023-03-08)
>>   name = "JavaAgent.jar"
>>   options = "foo=bar"
>>   initialization = 12:31:15.574 (2023-03-08)
>>   initializationTime = 172 ms
>>   initializationMethod = "premain"
>> }
>> // Dynamic load
>> jdk.JavaAgent {
>>   startTime = 12:31:31.158 (2023-03-08)
>>   name = "JavaAgent.jar"
>>   options = "bar=baz"
>>   initialization = 12:31:31.037 (2023-03-08)
>>   initializationTime = 64,1 ms
>>   initializationMethod = "agentmain"
>> }
>> 
>> The jdk.JavaAgent event type is a JFR periodic event that iterates over running Java agents.
>> 
>> For a JavaAgent event, the agent's name will be the specific .jar file containing the instrumentation code. The options will be the specific options passed to the .jar file as part of launching the agent, for example, on the command line: -javaagent: JavaAgent.jar=foo=bar
>> 
>> The event will also detail which initialization method was invoked by the JVM, "premain" for command line agents, and "agentmain" for agents loaded dynamically.
>> 
>> "initialization" is the timestamp the JVM invoked the initialization method, and "initializationTime" is the duration of executing the initialization method.
>> 
>> "startTime" represents the time the JFR framework issued the periodic event; hence "initialization" will be earlier than "startTime".
>> 
>> An agent can also be written in a native programming language, using the [JVM Tools Interface (JVMTI)](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html). This kind of agent, sometimes called a native agent, is a platform-specific binary, sometimes referred to as a library, but here it means a .so or .dll file.
>> 
>> To report on native agents, JFR will add the new event type jdk.NativeAgent and events will look similar to this example:
>> 
>> jdk.NativeAgent {
>>   startTime = 12:31:40.398 (2023-03-08)
>>   name = "jdwp"
>>   options = "transport=dt_socket,server=y,address=any,onjcmd=y"
>>   path = "c:\ade\github\openjdk\jdk\build\windows-x86_64-server-slowdebug\jdk\bin\jdwp.dll"
>>   dynamic = false
>>   initialization = 12:31:36.142 (2023-03-08)
>>   initializationTime = 0,00184 ms
>> }
>> 
>> The layout of the event type is very similar to the jdk.JavaAgent event, but here the path to the native library is reported, and there is also a denotation if the agent was loaded via the command line (dynamic = false) or dynamically (dynamic = true).
>> 
>> The initialization of a native agent is performed by invoking an agent-specified callback routine which is not detailed in the event (for now). The "initialization" is the time the JVM sent or would have sent the JVMTI VMInit event to a specified callback. "initializationTime" is the duration to execute that specific callback. If no callback is specified for the JVMTI VMInit event, the "initializationTime" will be 0.
>> 
>> #### Implementation
>> 
>> There has not existed a reification of a JavaAgent directly in the JVM, as these are built on top of the JDK native library, "instrument", using a many-to-one mapping. At the level of the JVM, the only representation of agents after startup is through JvmtiEnv's, which agents request from the JVM during startup and initialization ? as such, mapping which JvmtiEnv belongs to what JavaAgent was not possible before.
>> 
>> Using implementation details of how the JDK native library "instrument" interacts with the JVM, we can build this mapping to track what JvmtiEnv's "belong" to what JavaAgent. This mapping now lets us report the Java-relevant context (name, options) and measure the time it takes for the JavaAgent to initialize.
>> 
>> To implement this capability, it was necessary to refactor the code used to represent agents, called AgentLibrary. The previous implementation was located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp.
>> 
>> The refactoring isolates the relevant logic into two new modules, prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their older places will help reduce the sizes of oversized arguments.cpp and threads.cpp.
>> 
>> The previous lists that maintain the agents (JVMTI) and libraries (JVMPI) are not thread-safe for concurrent iterations. A single list that allows for concurrent iterations is therefore introduced.
>> 
>> Testing: jdk_jfr, tier 1 - 6
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove JVMPI
>  - cleanup

This seems a very large and intrusive change just to give some data about agents (sorry if that sounds flippant). IIUC you are generating events for stuff that (used to?) happens very early in the initialization process and for which you now need to load a whole heap of JFR classes - which could themselves be subject to the actions of the agent. The impact of this on the overall initialization process is very hard to gauge.

src/hotspot/share/runtime/threads.cpp line 338:

> 336:   if (EagerXrunInit && Arguments::init_libraries_at_startup()) {
> 337:     create_vm_init_libraries();
> 338:   }

Not obvious where this went. Changes to the initialization order can be very problematic.

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

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

From mgronlun at openjdk.org  Wed Mar  8 23:32:08 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 8 Mar 2023 23:32:08 GMT
Subject: RFR: 8257967: JFR: Events for loaded agents [v4]
In-Reply-To: <ifc_GVpqqnc0TVYHD1E1TnlG0jyGYcqtyNljfY3AuDY=.9dc9baf4-0331-4e6a-8745-bbdd01c62943@github.com>
References: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
 <ifc_GVpqqnc0TVYHD1E1TnlG0jyGYcqtyNljfY3AuDY=.9dc9baf4-0331-4e6a-8745-bbdd01c62943@github.com>
Message-ID: <Slg-7Di6QQyKyhrAabrFPZoJ8bkje0PYTDBlveo3eP4=.bc36b4a9-a7fa-4bc1-bbea-39938c5a453e@github.com>

On Wed, 8 Mar 2023 18:56:55 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> We are adding support to let JFR report on Agents.
>> 
>> #### Design
>> 
>> An Agent is a library that uses any instrumentation or profiling APIs. Most agents are started and initialized on the command line, but agents can also be loaded dynamically during runtime. Because command line agents initialize during the VM startup sequence, they add to the overall startup time latency in getting the VM ready. The events will report on the time the agent took to initialize.
>> 
>> A JavaAgent is an agent written in the Java programming language, using the APIs in the package [java.lang.instrument](https://docs.oracle.com/en/java/javase/19/docs/api/java.instrument/java/lang/instrument/package-summary.html)
>> 
>> A JavaAgent is sometimes called a JPLIS agent, where the acronym JPLIS stands for Java Programming Language Instrumentation Services.
>> 
>> To report on JavaAgents, JFR will add the new event type jdk.JavaAgent and events will look similar to these two examples:
>> 
>> // Command line
>> jdk.JavaAgent {
>>   startTime = 12:31:19.789 (2023-03-08)
>>   name = "JavaAgent.jar"
>>   options = "foo=bar"
>>   initialization = 12:31:15.574 (2023-03-08)
>>   initializationTime = 172 ms
>>   initializationMethod = "premain"
>> }
>> // Dynamic load
>> jdk.JavaAgent {
>>   startTime = 12:31:31.158 (2023-03-08)
>>   name = "JavaAgent.jar"
>>   options = "bar=baz"
>>   initialization = 12:31:31.037 (2023-03-08)
>>   initializationTime = 64,1 ms
>>   initializationMethod = "agentmain"
>> }
>> 
>> The jdk.JavaAgent event type is a JFR periodic event that iterates over running Java agents.
>> 
>> For a JavaAgent event, the agent's name will be the specific .jar file containing the instrumentation code. The options will be the specific options passed to the .jar file as part of launching the agent, for example, on the command line: -javaagent: JavaAgent.jar=foo=bar
>> 
>> The event will also detail which initialization method was invoked by the JVM, "premain" for command line agents, and "agentmain" for agents loaded dynamically.
>> 
>> "initialization" is the timestamp the JVM invoked the initialization method, and "initializationTime" is the duration of executing the initialization method.
>> 
>> "startTime" represents the time the JFR framework issued the periodic event; hence "initialization" will be earlier than "startTime".
>> 
>> An agent can also be written in a native programming language, using the [JVM Tools Interface (JVMTI)](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html). This kind of agent, sometimes called a native agent, is a platform-specific binary, sometimes referred to as a library, but here it means a .so or .dll file.
>> 
>> To report on native agents, JFR will add the new event type jdk.NativeAgent and events will look similar to this example:
>> 
>> jdk.NativeAgent {
>>   startTime = 12:31:40.398 (2023-03-08)
>>   name = "jdwp"
>>   options = "transport=dt_socket,server=y,address=any,onjcmd=y"
>>   path = "c:\ade\github\openjdk\jdk\build\windows-x86_64-server-slowdebug\jdk\bin\jdwp.dll"
>>   dynamic = false
>>   initialization = 12:31:36.142 (2023-03-08)
>>   initializationTime = 0,00184 ms
>> }
>> 
>> The layout of the event type is very similar to the jdk.JavaAgent event, but here the path to the native library is reported, and there is also a denotation if the agent was loaded via the command line (dynamic = false) or dynamically (dynamic = true).
>> 
>> The initialization of a native agent is performed by invoking an agent-specified callback routine which is not detailed in the event (for now). The "initialization" is the time the JVM sent or would have sent the JVMTI VMInit event to a specified callback. "initializationTime" is the duration to execute that specific callback. If no callback is specified for the JVMTI VMInit event, the "initializationTime" will be 0.
>> 
>> #### Implementation
>> 
>> There has not existed a reification of a JavaAgent directly in the JVM, as these are built on top of the JDK native library, "instrument", using a many-to-one mapping. At the level of the JVM, the only representation of agents after startup is through JvmtiEnv's, which agents request from the JVM during startup and initialization ? as such, mapping which JvmtiEnv belongs to what JavaAgent was not possible before.
>> 
>> Using implementation details of how the JDK native library "instrument" interacts with the JVM, we can build this mapping to track what JvmtiEnv's "belong" to what JavaAgent. This mapping now lets us report the Java-relevant context (name, options) and measure the time it takes for the JavaAgent to initialize.
>> 
>> To implement this capability, it was necessary to refactor the code used to represent agents, called AgentLibrary. The previous implementation was located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp.
>> 
>> The refactoring isolates the relevant logic into two new modules, prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their older places will help reduce the sizes of oversized arguments.cpp and threads.cpp.
>> 
>> The previous lists that maintain the agents (JVMTI) and libraries (JVMPI) are not thread-safe for concurrent iterations. A single list that allows for concurrent iterations is therefore introduced.
>> 
>> Testing: jdk_jfr, tier 1 - 6
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove JVMPI
>  - cleanup

No need to load any JFR classes. No change to startup logic.

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

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

From dchuyko at openjdk.org  Thu Mar  9 00:18:05 2023
From: dchuyko at openjdk.org (Dmitry Chuyko)
Date: Thu, 9 Mar 2023 00:18:05 GMT
Subject: RFR: 8300669: AArch64: Table based tails processing and wider
 stores for Arrays.fill() intrinsic [v7]
In-Reply-To: <P9Uyonc1ySikxhznLvs9HT6kXvh6IRFYMqH-BLU1nuM=.5fbbe0ed-f32e-4653-97a2-9a8a4b6e5e0d@github.com>
References: <P9Uyonc1ySikxhznLvs9HT6kXvh6IRFYMqH-BLU1nuM=.5fbbe0ed-f32e-4653-97a2-9a8a4b6e5e0d@github.com>
Message-ID: <0HhfPpk5EIXfhlmdTaT-ik1EQWgYXSKkK7f4fuLKGh0=.9e690153-fc70-49a0-aada-2829747da8cf@github.com>

> This is a new AArch64 implementation of existing (1-4-byte element) stubs that are called in C2-compiled code for array fill patterns and Arrays.fill().
> 
> Main variant of existing algorithm:
> 
> 
> [Short arrays (< 8 bytes): fill by element and exit];
> // ...
> [align base to 8 bytes];
> // ...
> // fill_words
> head_len = (cnt & 14) / 2;
> switch (head_len) {
>     do {
>       cnt -= 16;
>         stp;
>        case 7:
>         stp;
>        case 6:
>         stp;
>         // ...
>       case 1:
>          stp;
>        case 0:
>          base += 8*16;
>      } while (cnt);
>    }
> [(over)write a tail < 8 bytes];
> 
> 
> Even in good case, only 16-byte GPR (STP) stores are used, and there is a jump for every 8 stores. There is always extra work to be done for misaligned targets, which especially affects small to medium lengths.
> 
> The new implementation generates fill implementation for every length up to a certain threshold (160-byte length). These implementations form a table where you jump when the remaining target length is suitable.
> 
> For each table entry (target length), we can have no branches and use the most number of widest possible stores that best fit the detected CPU model. Currently it is SIMD STPQ for Neoverse N2 and GPR STP for the rest. The choice is made after benchmarking and is controlled by the new UseSIMDForArrayFill flag in AArch64.
> 
> Main variant of the new algorithm (see mode detailed description in comments):
> 
> 
> [align data at 16 bytes];
> while(cnt_bytes > 128) {
>    [store 128 bytes];
>    cnt_bytes -= 128;
> }
> [store tail of 0..127 bytes];
> 
> 
> 
> Both existing and proposed implementations specifically handle zero fill case (see comments about ZVA). New implementation contains a path for very small arrays that can be cut to further improve more generic case (added to avoid regressions).
> 
> The check added in https://bugs.openjdk.org/browse/JDK-8298720 in StubGenerator is removed as it is a stub code being generated. For the selected threshold, the increase in code size is within 8 KB.
> 
> New test TestArraysFill is added to intrinsics jtreg tests. It calls optimized versions of 2-arg and 4-arg Arrays.fill() for different data types, lengths and patterns. The target data is checked to be filled with the required value, the surrounding data is checked to be intact.
> 
> Existing test/micro/org/openjdk/bench/java/util/ArraysFill.java benchmark was used only initially. There are many cases and data lengths to cover. A modified version of the benchmark is attached [1] to the RFE, but not included in the change as it takes too long to complete all valuable variants.
> 
> Resulting performance data are listed in the spreadsheet [2] attache to the RFE. Target processors were Graviton 3, Graviton 2, TaiShan, A72 and A53. Latest data from Altra is not included but the picture there was similar to Graviton 2 in all experiments. There is a range of target lengths with various enhancement numbers. Interesting lengths are within table implementation threshold and close to them (stepped), small lengths (all) and long lengths (1 point, they look similar). Over this voluntary selection:
> 
> - No major regressions were found.
> - Geomean improvement: 11-33%
> - Median improvement: 10-48%
> 
> Testing: tier1, tier2 and the new test on fastdebug aarch64 and x86.
> 
> [1] https://bugs.openjdk.org/secure/attachment/102426/ArraysFill.java
> [2] https://bugs.openjdk.org/secure/attachment/102427/arrays-fill.ods

Dmitry Chuyko 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 JDK-8300669
 - Var in test
 - Merge branch 'openjdk:master' into JDK-8300669
 - Wording about alignment
 - Fixed compilation on win/mac
 - Merge branch 'openjdk:master' into JDK-8300669
 - Table based arrays_fill stub implementation for aarch64

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12222/files
  - new: https://git.openjdk.org/jdk/pull/12222/files/6e5ff006..c6c85567

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

  Stats: 115119 lines in 3209 files changed: 55358 ins; 26985 del; 32776 mod
  Patch: https://git.openjdk.org/jdk/pull/12222.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12222/head:pull/12222

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

From dholmes at openjdk.org  Thu Mar  9 00:26:06 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 9 Mar 2023 00:26:06 GMT
Subject: RFR: 8257967: JFR: Events for loaded agents [v4]
In-Reply-To: <Slg-7Di6QQyKyhrAabrFPZoJ8bkje0PYTDBlveo3eP4=.bc36b4a9-a7fa-4bc1-bbea-39938c5a453e@github.com>
References: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
 <ifc_GVpqqnc0TVYHD1E1TnlG0jyGYcqtyNljfY3AuDY=.9dc9baf4-0331-4e6a-8745-bbdd01c62943@github.com>
 <Slg-7Di6QQyKyhrAabrFPZoJ8bkje0PYTDBlveo3eP4=.bc36b4a9-a7fa-4bc1-bbea-39938c5a453e@github.com>
Message-ID: <mZtwwpU3zveOADqTXyFEGlv1DDyxxs3Y8hgNImrYXpk=.7bca8abe-339a-4e99-abaf-a4e71c1f3ed4@github.com>

On Wed, 8 Mar 2023 23:28:52 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> No need to load any JFR classes. 

I thought JFR was all Java-based these days. But if no Java involved then that is good.

> No change to startup logic.

I flagged a change in my comment above.

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

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

From dholmes at openjdk.org  Thu Mar  9 04:55:24 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 9 Mar 2023 04:55:24 GMT
Subject: RFR: 8302491: NoClassDefFoundError omits the original cause of an
 error [v6]
In-Reply-To: <nuns0Jl04F1OXvk_fevlbZTjWQjVohDcyXEPPd3R0YE=.e4d281c2-5a50-4d41-8dca-dfaca8ff1cbd@github.com>
References: <L-pfBfK4TKl5KUWpPEcbs-IkhwimgJZ-SOrbSG3exeA=.5e883f22-de9b-4eec-9e98-8ee954a7996b@github.com>
 <nuns0Jl04F1OXvk_fevlbZTjWQjVohDcyXEPPd3R0YE=.e4d281c2-5a50-4d41-8dca-dfaca8ff1cbd@github.com>
Message-ID: <T0jqWQwoc9OYieKqqSOOk61lxPyw7WbTCkvsAyL9g5U=.7bb9c0be-fdb6-4092-84a4-75c0f4ef6dd9@github.com>

On Tue, 7 Mar 2023 23:54:07 GMT, Ilarion Nakonechnyy <inakonechnyy at openjdk.org> wrote:

>> The proposed approach added a new function for getting the cause of an exception -`java_lang_Throwable::get_cause_simple `, that gets called within `InstanceKlass::add_initialization_error`  if an old one `java_lang_Throwable::get_cause_with_stack_trace` didn't succeed because of an exception during the VM call. The simple function doesn't call the VM for getting a stack trace but fills in any other information about an exception.
>> 
>> Besides that, the discovering information about an exception was added to `ConstantPoolCacheEntry::save_and_throw_indy_exc` function. 
>> 
>> Jtreg for reproducing the issue also was added to the commit. 
>> The commit was tested with tier1 tests.
>
> Ilarion Nakonechnyy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address a review notes

Two small adjustments needed and a couple of nits.

Thanks

src/hotspot/share/classfile/javaClasses.cpp line 2742:

> 2740:   // not keep classes alive in the stack trace.
> 2741:   // call this:  public StackTraceElement[] getStackTrace()
> 2742:   assert(throwable.not_null(), "shouldn't be");

You moved this assert but it needs to be before the first use of throwable()

src/hotspot/share/classfile/javaClasses.cpp line 2744:

> 2742:   // symbolic stacktrace of 'throwable'.
> 2743: 
> 2744:   // Now create the message with the original exception and thread name.

Existing: s/with/from/

src/hotspot/share/classfile/javaClasses.cpp line 2759:

> 2757:   Handle h_eiie = Exceptions::new_exception(current, exception_name, st.as_string());
> 2758:   // If new_exception returns a different exception while creating the exception,
> 2759:   // abandon the attempts to save the initialization error and return null.

Nit: s/attempts/attempt/

src/hotspot/share/oops/instanceKlass.cpp line 985:

> 983:   Handle init_error = java_lang_Throwable::create_initialization_error(current, exception);
> 984: 
> 985:   if ( init_error.is_null()) {

Nit: extra space after (

src/hotspot/share/oops/instanceKlass.cpp line 986:

> 984: 
> 985:   if ( init_error.is_null()) {
> 986:     log_trace(class, init)("Initialization error is null for class %s", external_name());

You need to move the ResourceMark from line 995 to line 984 to cover this new logging statement.

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

Changes requested by dholmes (Reviewer).

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

From stuefe at openjdk.org  Thu Mar  9 06:23:12 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 9 Mar 2023 06:23:12 GMT
Subject: RFR: JDK-8303861: Error handling step timeouts should never be blocked
 by OnError and others
Message-ID: <MsoamxpcF7RfrdiX5BXcHcluFN6HqcIZwwLedCUSQck=.8f187897-f3b4-46b8-9811-faba5d2e0b7b@github.com>

Fatal error handling is subject to several timeouts:
- a global timeout (controlled via ErrorLogTimeout)
- local error reporting step timeouts.

The latter aims to "give the JVM a kick" if it gets stuck in one particular place during error reporting. This prevents one error reporting step from hogging all the time allotted to error reporting under ErrorLogTimeout.

There are three situations where atm we suppress the global error timeout:
- if the JVM is embedded and the launcher has its abort hook installed. Obviously, that must be allowed to run.
- if the user specified one or more OnError commands to run, and these did not yet run. These must have a chance to run unmolested.
- if the user (typically developer) specified ShowMessageBoxOnError, and the error box has not yet been shown

There is a bug though, that also prevents the step timeout from firing if either condition is true. That is plain wrong.

In addition to that, the test interval WatcherThread uses to check for timeouts should be decreased. It sits at 1 second, which is too coarse-grained. 

--------

Patch:
- reworks `VMError::check_timeout()` to never block step timeouts
- adds clarifying comments
- quadruples timeout check frequency by watcher thread
- adds regression test for timeout handling with OnError

Tested locally on Linux x64.

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

Commit messages:
 - JDK-8303861-Error-handling-step-timeouts-should-never-be-blocked-by-OnError-and-others

Changes: https://git.openjdk.org/jdk/pull/12936/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12936&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303861
  Stats: 88 lines in 3 files changed: 55 ins; 1 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/12936.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12936/head:pull/12936

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

From stuefe at openjdk.org  Thu Mar  9 06:30:18 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 9 Mar 2023 06:30:18 GMT
Subject: RFR: 8302073: Specifying OnError handler prevents WatcherThread to
 break a deadlock in report_and_die()
In-Reply-To: <G-ReJaBrJTUBgWUmcE4eoqXQrtHCLPMSL7nQyom4QIM=.77438a77-60c9-4dc1-b811-7a71249d4358@github.com>
References: <nTD9cu_uj-X-ML_g-kbPrccPTlk5NGX9iV5TLXxOpbA=.2cea728c-6dbe-41a5-b379-a75c4ebc85e0@github.com>
 <k9wKuvOyzPUxNzE_aHGg_Abr5gckbriofiHDuMmhfps=.51b99d4a-8f1f-4134-8121-3738f2b13e41@github.com>
 <G-ReJaBrJTUBgWUmcE4eoqXQrtHCLPMSL7nQyom4QIM=.77438a77-60c9-4dc1-b811-7a71249d4358@github.com>
Message-ID: <0jlQWouDE0tJ-ysn7WFYArqrJwHFQ-hhsZKKRGdVhmU=.95c4ceb0-9b8e-4c9b-9029-473626fb5a6b@github.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
On Wed, 8 Mar 2023 21:31:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Pinging @dholmes-ora for input and opinion
>
> I thought we were still discussing options in JBS so this PR seems premature to me. I agree with @tstuefe initial comment this seems way too complex and I'm not even sure I can figure out the control flow here.

@dholmes-ora My proposal would be to be pragmatic and continue the discussion here. This has been going on too long. Switching channels again would be more confusing. 

I would prefer JBS or ML discussion as well, but not everyone (eg. @jsolomon8080) has write access to JBS.

----

I thought this over some more.

A big part of this problem is a plain bug in VMError::check_timeout(): it should never block *step timeouts*. We added step timeouts back in 2016 to deal with these kinds of problems: if the JVM hangs in error reporting, give it a kick to get it going again. Do so repeatedly. This is related to the global timeout, but works also independently from it (and therefore from the question of when to honor the global timeout).

I opened https://bugs.openjdk.org/browse/JDK-8303861 to deal with this, see PR: https://github.com/openjdk/jdk/pull/12936

This may already be a big help for cases like these. In fact, it may already be enough, and we could maybe close this issue.

However, if we have a recursive malloc situation, we may hang repeatedly. JVM will kick itself alive every time (with my patch) but this is still annoying. The root problem here is that we should not use malloc during error handling. Cannot always be avoided, but at least we should minimize malloc use. 

Decoder, in particular, should not use malloc. Therefore I also opened https://bugs.openjdk.org/browse/JDK-8303862 to track that. I won't have time to work on that. I have the hope that maybe @chhagedorn can :-) ? Otherwise Azul may also chip in some bug fixing.

----

All these are unrelated to the question of whether OnError should be blocked or not. I realize now that if we decide to (continue to) protect OnError from timeouts, we must never act on the global timeout until all OnError steps ran. Since these run right before VM exit, the original implementation that just blocked the global timeout altogether was actually right.

So, there's that. Maybe JDK-8303861 is already enough for cases like this. At least JDK-8303861 does not introduce any backward compatibility issues.

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

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

From kvn at openjdk.org  Thu Mar  9 06:32:30 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 9 Mar 2023 06:32:30 GMT
Subject: RFR: JDK-8300783: Consolidate byteswap implementations [v14]
In-Reply-To: <-b783DPmWbWFeigKf7F7SFYddDKwErM4AdFcfRx01eM=.5794fa08-a0d7-4761-a449-8ebfd639e30d@github.com>
References: <MLBMwI7xt4IKgpb3AHXJ_J11Ibhijp_q2RFtLJOwHpA=.b7da6b6b-69b8-426d-8eab-c7c3aaa0847e@github.com>
 <-b783DPmWbWFeigKf7F7SFYddDKwErM4AdFcfRx01eM=.5794fa08-a0d7-4761-a449-8ebfd639e30d@github.com>
Message-ID: <MKhv04xEzo5r8VvoaOoGdruThV5ks4hfH7YvOoV1GCI=.13da8957-a92a-4ad8-a5c3-3e2bea44a535@github.com>

On Wed, 15 Feb 2023 15:39:14 GMT, Justin King <jcking at openjdk.org> wrote:

>> Deduplicate byte swapping implementations by consolidating them into `utilities/byteswap.hpp`, following `std::byteswap` introduced in C++23. Further simplification of `Bytes` will follow in https://github.com/openjdk/jdk/pull/12078.
>
> Justin King 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:
> 
>  - Merge remote-tracking branch 'upstream/master' into byteswap
>  - Update based on review
>    
>    Signed-off-by: Justin King <jcking at google.com>
>  - Fix copyright
>    
>    Signed-off-by: Justin King <jcking at google.com>
>  - Update copyright
>    
>    Signed-off-by: Justin King <jcking at google.com>
>  - Add missing include
>    
>    Signed-off-by: Justin King <jcking at google.com>
>  - Remove unused include
>    
>    Signed-off-by: Justin King <jcking at google.com>
>  - Reorganize tests
>    
>    Signed-off-by: Justin King <jcking at google.com>
>  - Fix test
>    
>    Signed-off-by: Justin King <jcking at google.com>
>  - Merge remote-tracking branch 'upstream/master' into byteswap
>  - Be restrict on requiring 1, 2, 4, or 8 byte integers
>    
>    Signed-off-by: Justin King <jcking at google.com>
>  - ... and 14 more: https://git.openjdk.org/jdk/compare/fa0103ad...223d733b

This looks good to me. I will run testing for latest version before approval.

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

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

From rehn at openjdk.org  Thu Mar  9 07:16:28 2023
From: rehn at openjdk.org (Robbin Ehn)
Date: Thu, 9 Mar 2023 07:16:28 GMT
Subject: RFR: 8300926: Several startup regressions ~6-70% in 21-b6 all
 platforms [v8]
In-Reply-To: <N7nXAkBhgQAQzYqUxhSA6H1Ytiwf4mLw3g4CmfB8p6s=.ed56ed80-0083-46f5-b00b-81843d3e0aa7@github.com>
References: <yAP6c7wzGguBfKuzvbjMZdnaqydAz4PFn0pgR1UGj9s=.ce872f5d-3f7a-4e24-99d5-da5e80855ea4@github.com>
 <z7_2sNpjnL2JYEhq-L6S6VvxwrCEZlHX7EDZx4do_Dw=.783bbdcb-bc62-46f0-83a4-70e6785b9fe0@github.com>
 <N7nXAkBhgQAQzYqUxhSA6H1Ytiwf4mLw3g4CmfB8p6s=.ed56ed80-0083-46f5-b00b-81843d3e0aa7@github.com>
Message-ID: <PfRKpX1HueV3NBxVIB8aMxa11H79e1qOia0Y0KONTQ8=.37484fea-aaa4-4f8d-a757-a81d9b96555d@github.com>

On Wed, 8 Mar 2023 22:21:57 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Re-reviewed v06 (main merge) and v07. Still thumbs up.

Thank you!

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

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

From stuefe at openjdk.org  Thu Mar  9 08:34:13 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 9 Mar 2023 08:34:13 GMT
Subject: RFR: 8302073: Specifying OnError handler prevents WatcherThread to
 break a deadlock in report_and_die()
In-Reply-To: <3ZipShQ_gHqbJaO1aIg8yk-OcPwKg2D6eFJghlad5DM=.29bb804e-42a7-4d2c-b99c-31c21f663f24@github.com>
References: <nTD9cu_uj-X-ML_g-kbPrccPTlk5NGX9iV5TLXxOpbA=.2cea728c-6dbe-41a5-b379-a75c4ebc85e0@github.com>
 <3ZipShQ_gHqbJaO1aIg8yk-OcPwKg2D6eFJghlad5DM=.29bb804e-42a7-4d2c-b99c-31c21f663f24@github.com>
Message-ID: <fOTVIcAuUpMY56GDyDYYY4X1CiNORL0F1Wpj4B3vYVo=.400c0b8a-6356-482d-b2bd-f04a161c004d@github.com>

On Wed, 8 Mar 2023 20:09:38 GMT, jsolomon8080 <duke at openjdk.org> wrote:

> Hi - I'm the originator of this bug report. I'm glad this is getting fixed and I will ultimately defer to the java experts since I have never contributed code to this code base, but if it were me, I'd do the simplest thing possible. The solution presented here seems overly complex. I don't understand why an OnError script or an abort_hook is so special. I think it's up to the user to ensure that neither takes longer than ErrorLogTimeout, which defaults to 2 minutes. That's an eternity. Do java users really expect to wait 2 minutes for their processes to exit?

Some do, some don't, there are cases for both. But that is not the point. We must guarantee that all OnError commands are run and that the abort hook is called. Since these things happen after error reporting, we cannot interrupt error reporting.

This is a backward compatibility question. There are arguments for ErrorLogTimeout having precedence, and there are arguments for the current behavior. Both sides have good arguments, but OpenJDK tries to err on the side of compatibility here.

> If this were my code, I would remove any guarantee about OnError and make it responsibility of the user to set ErrorLogTimeout appropriately.

Nothing is stopping Azul from changing this behavior downstream in their VM, but upstream we need to find a consensus with all interested parties.

> 
> I understand that there may be many users who have counted on this guarantee and you can't break them now. I also understand that I'm not aware of all the ways that OnError is used. I'm sure we will get to some solution that will fix the real problem, which I care about the most. Thank you.

Let's see if this issue is moot once the fix for JDK-8303861 is out.

Cheers, Thomas

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

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

From adinn at openjdk.org  Thu Mar  9 09:18:08 2023
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 9 Mar 2023 09:18:08 GMT
Subject: RFR: 8257967: JFR: Events for loaded agents [v4]
In-Reply-To: <Slg-7Di6QQyKyhrAabrFPZoJ8bkje0PYTDBlveo3eP4=.bc36b4a9-a7fa-4bc1-bbea-39938c5a453e@github.com>
References: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
 <ifc_GVpqqnc0TVYHD1E1TnlG0jyGYcqtyNljfY3AuDY=.9dc9baf4-0331-4e6a-8745-bbdd01c62943@github.com>
 <Slg-7Di6QQyKyhrAabrFPZoJ8bkje0PYTDBlveo3eP4=.bc36b4a9-a7fa-4bc1-bbea-39938c5a453e@github.com>
Message-ID: <NZrp1GKAW9JMrHsklUhNsl4BKKoVcMur0x5VSvW19KI=.1c802f3c-b05e-4e12-8450-423bfd2d664e@github.com>

On Wed, 8 Mar 2023 23:28:52 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Markus Gr?nlund has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - remove JVMPI
>>  - cleanup
>
> No need to load any JFR classes. No change to startup logic.

@mgronlun Why mark Java agents as command-line or dynamic using `initializationMethod = "premain"/"agentMain"` and mark native agents using `dynamic = true/false`? Why not use `dynamic` for both?

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

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

From mgronlun at openjdk.org  Thu Mar  9 09:24:16 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 9 Mar 2023 09:24:16 GMT
Subject: RFR: 8257967: JFR: Events for loaded agents [v4]
In-Reply-To: <Slg-7Di6QQyKyhrAabrFPZoJ8bkje0PYTDBlveo3eP4=.bc36b4a9-a7fa-4bc1-bbea-39938c5a453e@github.com>
References: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
 <ifc_GVpqqnc0TVYHD1E1TnlG0jyGYcqtyNljfY3AuDY=.9dc9baf4-0331-4e6a-8745-bbdd01c62943@github.com>
 <Slg-7Di6QQyKyhrAabrFPZoJ8bkje0PYTDBlveo3eP4=.bc36b4a9-a7fa-4bc1-bbea-39938c5a453e@github.com>
Message-ID: <tCSo8QpEptKpyZ1AA8pb8eDRDYOwIZsGIbIF2juYBB8=.8004d5b6-4301-44a8-ad5a-381494062294@github.com>

On Wed, 8 Mar 2023 23:28:52 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Markus Gr?nlund has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - remove JVMPI
>>  - cleanup
>
> No need to load any JFR classes. No change to startup logic.

> @mgronlun Why mark Java agents as command-line or dynamic using `initializationMethod = "premain"/"agentMain"` and mark native agents using `dynamic = true/false`? Why not use `dynamic` for both?

Hi Andrew, that's a good question. I thought it could be derived in the JavaAgent case, because there are only two entry points, "premain" implies static and "agentmain" implies dynamic.

For the native case, there is no information about the callback (I had it, but it depends on symbols), so the dynamic field is made explicit.

It can also be added to the JavaAgent if that makes it clearer.

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

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

From mgronlun at openjdk.org  Thu Mar  9 09:32:19 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 9 Mar 2023 09:32:19 GMT
Subject: RFR: 8257967: JFR: Events for loaded agents [v4]
In-Reply-To: <MEaC0tZz0wRYqjruWeE1-1ig25xS8f0w_wkO8k6ZJzk=.33473403-7f73-421c-84c0-24f2fdf2a3e3@github.com>
References: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
 <ifc_GVpqqnc0TVYHD1E1TnlG0jyGYcqtyNljfY3AuDY=.9dc9baf4-0331-4e6a-8745-bbdd01c62943@github.com>
 <MEaC0tZz0wRYqjruWeE1-1ig25xS8f0w_wkO8k6ZJzk=.33473403-7f73-421c-84c0-24f2fdf2a3e3@github.com>
Message-ID: <5bzaYlM6HXfUNJITjTSIaGgcJ_51OQf6XWr07w__wUw=.d0a9ac8b-a9a1-4122-9d2f-880de717d071@github.com>

On Wed, 8 Mar 2023 22:56:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Markus Gr?nlund has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - remove JVMPI
>>  - cleanup
>
> src/hotspot/share/runtime/threads.cpp line 338:
> 
>> 336:   if (EagerXrunInit && Arguments::init_libraries_at_startup()) {
>> 337:     create_vm_init_libraries();
>> 338:   }
> 
> Not obvious where this went. Changes to the initialization order can be very problematic.

Thanks, David. Two calls to launch XRun agents are invoked during startup, and they depend on the EagerXrunInit option. The !EagerXrunInit case is already located in create_vm(), but the EagerXrunInit was located as the first entry in initialize_java_lang_classes(), which I thought was tucked away a bit unnecessarily.

I hoisted the EagerXrunInit from initialize_java_lang_classes() into to create_vm(). It's now the call just before initialize_java_lang_classes().

This made it clearer, i.e. to have both calls located directly in create_vm().

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

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

From mgronlun at openjdk.org  Thu Mar  9 09:35:17 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 9 Mar 2023 09:35:17 GMT
Subject: RFR: 8257967: JFR: Events for loaded agents [v4]
In-Reply-To: <mZtwwpU3zveOADqTXyFEGlv1DDyxxs3Y8hgNImrYXpk=.7bca8abe-339a-4e99-abaf-a4e71c1f3ed4@github.com>
References: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
 <ifc_GVpqqnc0TVYHD1E1TnlG0jyGYcqtyNljfY3AuDY=.9dc9baf4-0331-4e6a-8745-bbdd01c62943@github.com>
 <Slg-7Di6QQyKyhrAabrFPZoJ8bkje0PYTDBlveo3eP4=.bc36b4a9-a7fa-4bc1-bbea-39938c5a453e@github.com>
 <mZtwwpU3zveOADqTXyFEGlv1DDyxxs3Y8hgNImrYXpk=.7bca8abe-339a-4e99-abaf-a4e71c1f3ed4@github.com>
Message-ID: <X4RxJhy87czBkumXX-4x2y-1yXs0GRjZyIRRC08WFEc=.94b1cc30-38ba-446b-bf96-ff8df9a4ccda@github.com>

On Thu, 9 Mar 2023 00:23:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > No need to load any JFR classes.
> 
> I thought JFR was all Java-based these days. But if no Java involved then that is good.

Ehh, no. Far from it.

> > No change to startup logic.
> 
> I flagged a change in my comment above.

Thanks, pls see my reply.

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

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

From adinn at openjdk.org  Thu Mar  9 09:39:16 2023
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 9 Mar 2023 09:39:16 GMT
Subject: RFR: 8257967: JFR: Events for loaded agents [v4]
In-Reply-To: <ifc_GVpqqnc0TVYHD1E1TnlG0jyGYcqtyNljfY3AuDY=.9dc9baf4-0331-4e6a-8745-bbdd01c62943@github.com>
References: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
 <ifc_GVpqqnc0TVYHD1E1TnlG0jyGYcqtyNljfY3AuDY=.9dc9baf4-0331-4e6a-8745-bbdd01c62943@github.com>
Message-ID: <6lvLldbtBOQUw1f_3lz6yJ8G33tpzQolD95cBHHvhNY=.0b6f4c9d-01b3-4bd4-9638-68b2e28a7a65@github.com>

On Wed, 8 Mar 2023 18:56:55 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> We are adding support to let JFR report on Agents.
>> 
>> #### Design
>> 
>> An Agent is a library that uses any instrumentation or profiling APIs. Most agents are started and initialized on the command line, but agents can also be loaded dynamically during runtime. Because command line agents initialize during the VM startup sequence, they add to the overall startup time latency in getting the VM ready. The events will report on the time the agent took to initialize.
>> 
>> A JavaAgent is an agent written in the Java programming language, using the APIs in the package [java.lang.instrument](https://docs.oracle.com/en/java/javase/19/docs/api/java.instrument/java/lang/instrument/package-summary.html)
>> 
>> A JavaAgent is sometimes called a JPLIS agent, where the acronym JPLIS stands for Java Programming Language Instrumentation Services.
>> 
>> To report on JavaAgents, JFR will add the new event type jdk.JavaAgent and events will look similar to these two examples:
>> 
>> // Command line
>> jdk.JavaAgent {
>>   startTime = 12:31:19.789 (2023-03-08)
>>   name = "JavaAgent.jar"
>>   options = "foo=bar"
>>   initialization = 12:31:15.574 (2023-03-08)
>>   initializationTime = 172 ms
>>   initializationMethod = "premain"
>> }
>> // Dynamic load
>> jdk.JavaAgent {
>>   startTime = 12:31:31.158 (2023-03-08)
>>   name = "JavaAgent.jar"
>>   options = "bar=baz"
>>   initialization = 12:31:31.037 (2023-03-08)
>>   initializationTime = 64,1 ms
>>   initializationMethod = "agentmain"
>> }
>> 
>> The jdk.JavaAgent event type is a JFR periodic event that iterates over running Java agents.
>> 
>> For a JavaAgent event, the agent's name will be the specific .jar file containing the instrumentation code. The options will be the specific options passed to the .jar file as part of launching the agent, for example, on the command line: -javaagent: JavaAgent.jar=foo=bar
>> 
>> The event will also detail which initialization method was invoked by the JVM, "premain" for command line agents, and "agentmain" for agents loaded dynamically.
>> 
>> "initialization" is the timestamp the JVM invoked the initialization method, and "initializationTime" is the duration of executing the initialization method.
>> 
>> "startTime" represents the time the JFR framework issued the periodic event; hence "initialization" will be earlier than "startTime".
>> 
>> An agent can also be written in a native programming language using the [JVM Tools Interface (JVMTI)](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html). This kind of agent, sometimes called a native agent, is a platform-specific binary, sometimes referred to as a library, but here it means a .so or .dll file.
>> 
>> To report on native agents, JFR will add the new event type jdk.NativeAgent and events will look similar to this example:
>> 
>> jdk.NativeAgent {
>>   startTime = 12:31:40.398 (2023-03-08)
>>   name = "jdwp"
>>   options = "transport=dt_socket,server=y,address=any,onjcmd=y"
>>   path = "c:\ade\github\openjdk\jdk\build\windows-x86_64-server-slowdebug\jdk\bin\jdwp.dll"
>>   dynamic = false
>>   initialization = 12:31:36.142 (2023-03-08)
>>   initializationTime = 0,00184 ms
>> }
>> 
>> The layout of the event type is very similar to the jdk.JavaAgent event, but here the path to the native library is reported, and there is also a denotation if the agent was loaded via the command line (dynamic = false) or dynamically (dynamic = true).
>> 
>> The initialization of a native agent is performed by invoking an agent-specified callback routine which is not detailed in the event (for now). The "initialization" is when the JVM sent or would have sent the JVMTI VMInit event to a specified callback. "initializationTime" is the duration to execute that specific callback. If no callback is specified for the JVMTI VMInit event, the "initializationTime" will be 0.
>> 
>> #### Implementation
>> 
>> There has not existed a reification of a JavaAgent directly in the JVM, as these are built on top of the JDK native library, "instrument", using a many-to-one mapping. At the level of the JVM, the only representation of agents after startup is through JvmtiEnv's, which agents request from the JVM during startup and initialization ? as such, mapping which JvmtiEnv belongs to what JavaAgent was not possible before.
>> 
>> Using implementation details of how the JDK native library "instrument" interacts with the JVM, we can build this mapping to track what JvmtiEnv's "belong" to what JavaAgent. This mapping now lets us report the Java-relevant context (name, options) and measure the time it takes for the JavaAgent to initialize.
>> 
>> When implementing this capability, it was necessary to refactor the code used to represent agents, AgentLibrary. The previous implementation was located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp.
>> 
>> The refactoring isolates the relevant logic into two new modules, prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their older places will help reduce the sizes of oversized arguments.cpp and threads.cpp.
>> 
>> The previous two lists that maintained "agents" (JVMTI) and "libraries" (Xrun) were not thread-safe for concurrent iterations. A single list that allows for concurrent iterations is therefore introduced.
>> 
>> Testing: jdk_jfr, tier 1 - 6
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove JVMPI
>  - cleanup

Yes, I appreciate that `dynamic` can be derived from `initializationMethod` -- and vice versa. However, I was approaching this semantically from the opposite end. To me the primary characteristic that the user would be interested in is whether the agent was loaded dynamically or on the command line (whatever the type of agent). The corresponding fact, for a Java agent, that it is entered, respectively, via method agentMain or preMain is a derived (implementation) detail. Is there a reason to mention that detail?

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

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

From mgronlun at openjdk.org  Thu Mar  9 09:47:16 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 9 Mar 2023 09:47:16 GMT
Subject: RFR: 8257967: JFR: Events for loaded agents [v4]
In-Reply-To: <6lvLldbtBOQUw1f_3lz6yJ8G33tpzQolD95cBHHvhNY=.0b6f4c9d-01b3-4bd4-9638-68b2e28a7a65@github.com>
References: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
 <ifc_GVpqqnc0TVYHD1E1TnlG0jyGYcqtyNljfY3AuDY=.9dc9baf4-0331-4e6a-8745-bbdd01c62943@github.com>
 <6lvLldbtBOQUw1f_3lz6yJ8G33tpzQolD95cBHHvhNY=.0b6f4c9d-01b3-4bd4-9638-68b2e28a7a65@github.com>
Message-ID: <1vaEi8bGZ5D5woUEmxe_zYIOR138w4N9Mwcv_Hk6-Z0=.ee6c0d43-a9bc-46d6-8c7f-7a7cf71fb704@github.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
On Thu, 9 Mar 2023 09:36:28 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> Yes, I appreciate that `dynamic` can be derived from `initializationMethod` -- and vice versa. However, I was approaching this semantically from the opposite end. To me the primary characteristic that the user would be interested in is whether the agent was loaded dynamically or on the command line (whatever the type of agent). The corresponding fact, for a Java agent, that it is entered, respectively, via method agentMain or preMain is a derived (implementation) detail. Is there a reason to mention that detail?

That's a good point. The overall intent was to map what method was measured during initialization. That included native agent callbacks as well. It may be an unnecessary implementation detail and may restrict the possibility of growth.  It is probably a better design abstraction to leave out the specific method. I dropped the callback function for the native agent, but we should also do the same for JavaAgents.

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

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

From stuefe at openjdk.org  Thu Mar  9 10:09:28 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 9 Mar 2023 10:09:28 GMT
Subject: RFR: JDK-8303861: Error handling step timeouts should never be
 blocked by OnError and others [v2]
In-Reply-To: <MsoamxpcF7RfrdiX5BXcHcluFN6HqcIZwwLedCUSQck=.8f187897-f3b4-46b8-9811-faba5d2e0b7b@github.com>
References: <MsoamxpcF7RfrdiX5BXcHcluFN6HqcIZwwLedCUSQck=.8f187897-f3b4-46b8-9811-faba5d2e0b7b@github.com>
Message-ID: <FVO8BPbYbbOlrFQhTESwAOM4TifV2UQeF2nk6A2NCx4=.de3bf2b9-59a9-4df8-af8a-7550451a85db@github.com>

> Fatal error handling is subject to several timeouts:
> - a global timeout (controlled via ErrorLogTimeout)
> - local error reporting step timeouts.
> 
> The latter aims to "give the JVM a kick" if it gets stuck in one particular place during error reporting. This prevents one error reporting step from hogging all the time allotted to error reporting under ErrorLogTimeout.
> 
> There are three situations where atm we suppress the global error timeout:
> - if the JVM is embedded and the launcher has its abort hook installed. Obviously, that must be allowed to run.
> - if the user specified one or more OnError commands to run, and these did not yet run. These must have a chance to run unmolested.
> - if the user (typically developer) specified ShowMessageBoxOnError, and the error box has not yet been shown
> 
> There is a bug though, that also prevents the step timeout from firing if either condition is true. That is plain wrong.
> 
> In addition to that, the test interval WatcherThread uses to check for timeouts should be decreased. It sits at 1 second, which is too coarse-grained. 
> 
> --------
> 
> Patch:
> - reworks `VMError::check_timeout()` to never block step timeouts
> - adds clarifying comments
> - quadruples timeout check frequency by watcher thread
> - adds regression test for timeout handling with OnError
> - additionally limits timeout per individual error reporting step to 5 seconds. 5 seconds is usually enough to distinguish a slow error reporting step from one that is endlessly hanging. 
> 
> Tested locally on Linux x64.

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

  limit step timeout to 5 seconds max

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12936/files
  - new: https://git.openjdk.org/jdk/pull/12936/files/0a188617..70b9add7

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

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

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

From duke at openjdk.org  Thu Mar  9 10:36:36 2023
From: duke at openjdk.org (Afshin Zafari)
Date: Thu, 9 Mar 2023 10:36:36 GMT
Subject: RFR: 8292059: Do not inline InstanceKlass::allocate_instance()
 [v3]
In-Reply-To: <ZSJBTzuC4wVuKdqSLLTgw4Pds2oX5wah0Ub6rFux_tc=.c4e2ae89-cadb-4ccd-9eee-034583cf7200@github.com>
References: <ZSJBTzuC4wVuKdqSLLTgw4Pds2oX5wah0Ub6rFux_tc=.c4e2ae89-cadb-4ccd-9eee-034583cf7200@github.com>
Message-ID: <7Aide4lBzCPDqqanrD8I9SsT6LXneQ8CKSU4os4lH-Q=.38f1186f-01b0-4975-ad16-fcfd4eb6c031@github.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
> The inline and not-inline versions of the method is stress tested to compare the performance difference. The statistics are drawn in the following charts. The vertical axis is in milliseconds.
> 
> ![chart (2)](https://user-images.githubusercontent.com/4697012/221848555-2884313e-9d26-41c9-a265-3f1ce295b17b.png)
> 
> ![chart (3)](https://user-images.githubusercontent.com/4697012/221863810-94118677-b4af-468f-90c6-5ea365ae3588.png)

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  8292059: Do not inline InstanceKlass::allocate_instance()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12782/files
  - new: https://git.openjdk.org/jdk/pull/12782/files/30a5734c..6cdd8357

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

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

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

From duke at openjdk.org  Thu Mar  9 10:36:39 2023
From: duke at openjdk.org (Afshin Zafari)
Date: Thu, 9 Mar 2023 10:36:39 GMT
Subject: RFR: 8292059: Do not inline InstanceKlass::allocate_instance()
 [v2]
In-Reply-To: <M6-FTQ7djx8MoflW6USJYQt-p7rEuzMgBIB1AKHlFZY=.98bf79d7-4c02-4a8d-9deb-144fc72e98a5@github.com>
References: <ZSJBTzuC4wVuKdqSLLTgw4Pds2oX5wah0Ub6rFux_tc=.c4e2ae89-cadb-4ccd-9eee-034583cf7200@github.com>
 <8koli6nAbt8Rx4Je8MRic0dPloLTb9IiUyw25BvUI0s=.07267dc7-d2a1-4426-8876-1e41b1a248ac@github.com>
 <M6-FTQ7djx8MoflW6USJYQt-p7rEuzMgBIB1AKHlFZY=.98bf79d7-4c02-4a8d-9deb-144fc72e98a5@github.com>
Message-ID: <MDZ5fEDF2yNPUNE6TadAgItEy4qgpn5qPDE7ycaQeSE=.195ee470-b89e-4481-90fb-b2d9bd205839@github.com>

On Mon, 6 Mar 2023 13:36:00 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> What is the motivation to change the parameter from `oop java_class` to `InstanceKlass*`? The call sites are now much noisier and harder to read.

This is changed to gain performance when this function is called many times.

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

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

From mgronlun at openjdk.org  Thu Mar  9 10:57:27 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 9 Mar 2023 10:57:27 GMT
Subject: RFR: 8257967: JFR: Events for loaded agents [v5]
In-Reply-To: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
References: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
Message-ID: <Ntr8tL0OZ3_KAMKDxdRbiXbg2OI_2NkU44YUgwiVCQw=.37c4a1b4-49b8-4e8f-af53-fdbfb2a05c8b@github.com>

> Greetings,
> 
> We are adding support to let JFR report on Agents.
> 
> #### Design
> 
> An Agent is a library that uses any instrumentation or profiling APIs. Most agents are started and initialized on the command line, but agents can also be loaded dynamically during runtime. Because command line agents initialize during the VM startup sequence, they add to the overall startup time latency in getting the VM ready. The events will report on the time the agent took to initialize.
> 
> A JavaAgent is an agent written in the Java programming language, using the APIs in the package [java.lang.instrument](https://docs.oracle.com/en/java/javase/19/docs/api/java.instrument/java/lang/instrument/package-summary.html)
> 
> A JavaAgent is sometimes called a JPLIS agent, where the acronym JPLIS stands for Java Programming Language Instrumentation Services.
> 
> To report on JavaAgents, JFR will add the new event type jdk.JavaAgent and events will look similar to these two examples:
> 
> // Command line
> jdk.JavaAgent {
>   startTime = 12:31:19.789 (2023-03-08)
>   name = "JavaAgent.jar"
>   options = "foo=bar"
>   dynamic = false
>   initialization = 12:31:15.574 (2023-03-08)
>   initializationTime = 172 ms
> }
> 
> // Dynamic load
> jdk.JavaAgent {
>   startTime = 12:31:31.158 (2023-03-08)
>   name = "JavaAgent.jar"
>   options = "bar=baz"
>   dynamic = true
>   initialization = 12:31:31.037 (2023-03-08)
>   initializationTime = 64,1 ms
> }
> 
> The jdk.JavaAgent event type is a JFR periodic event that iterates over running Java agents.
> 
> For a JavaAgent event, the agent's name will be the specific .jar file containing the instrumentation code. The options will be the specific options passed to the .jar file as part of launching the agent, for example, on the command line: -javaagent: JavaAgent.jar=foo=bar.
> 
> The "dynamic" field denotes if the agent was loaded via the command line (dynamic = false) or dynamically (dynamic = true)
> 
> "initialization" is the timestamp the JVM invoked the initialization method, and "initializationTime" is the duration of executing the initialization method.
> 
> "startTime" represents the time the JFR framework issued the periodic event; hence "initialization" will be earlier than "startTime".
> 
> An agent can also be written in a native programming language using the [JVM Tools Interface (JVMTI)](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html). This kind of agent, sometimes called a native agent, is a platform-specific binary, sometimes referred to as a library, but here it means a .so or .dll file.
> 
> To report on native agents, JFR will add the new event type jdk.NativeAgent and events will look similar to this example:
> 
> jdk.NativeAgent {
>   startTime = 12:31:40.398 (2023-03-08)
>   name = "jdwp"
>   options = "transport=dt_socket,server=y,address=any,onjcmd=y"
>   dynamic = false
>   initialization = 12:31:36.142 (2023-03-08)
>   initializationTime = 0,00184 ms
>   path = "c:\ade\github\openjdk\jdk\build\windows-x86_64-server-slowdebug\jdk\bin\jdwp.dll"
> }
> 
> The layout of the event type is very similar to the jdk.JavaAgent event, but here the path to the native library is reported.
> 
> The initialization of a native agent is performed by invoking an agent-specified callback routine. The "initialization" is when the JVM sent or would have sent the JVMTI VMInit event to a specified callback. "initializationTime" is the duration to execute that specific callback. If no callback is specified for the JVMTI VMInit event, the "initializationTime" will be 0.
> 
> #### Implementation
> 
> There has not existed a reification of a JavaAgent directly in the JVM, as these are built on top of the JDK native library, "instrument", using a many-to-one mapping. At the level of the JVM, the only representation of agents after startup is through JvmtiEnv's, which agents request from the JVM during startup and initialization ? as such, mapping which JvmtiEnv belongs to what JavaAgent was not possible before.
> 
> Using implementation details of how the JDK native library "instrument" interacts with the JVM, we can build this mapping to track what JvmtiEnv's "belong" to what JavaAgent. This mapping now lets us report the Java-relevant context (name, options) and measure the time it takes for the JavaAgent to initialize.
> 
> When implementing this capability, it was necessary to refactor the code used to represent agents, AgentLibrary. The previous implementation was located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp.
> 
> The refactoring isolates the relevant logic into two new modules, prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their older places will help reduce the sizes of oversized arguments.cpp and threads.cpp.
> 
> The previous two lists that maintained "agents" (JVMTI) and "libraries" (Xrun) were not thread-safe for concurrent iterations. A single list that allows for concurrent iterations is therefore introduced.
> 
> Testing: jdk_jfr, tier 1 - 6
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  remove implementation details

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12923/files
  - new: https://git.openjdk.org/jdk/pull/12923/files/355d307c..f0c04055

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

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

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

From redestad at openjdk.org  Thu Mar  9 11:11:24 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 9 Mar 2023 11:11:24 GMT
Subject: RFR: 8292059: Do not inline InstanceKlass::allocate_instance()
 [v3]
In-Reply-To: <7Aide4lBzCPDqqanrD8I9SsT6LXneQ8CKSU4os4lH-Q=.38f1186f-01b0-4975-ad16-fcfd4eb6c031@github.com>
References: <ZSJBTzuC4wVuKdqSLLTgw4Pds2oX5wah0Ub6rFux_tc=.c4e2ae89-cadb-4ccd-9eee-034583cf7200@github.com>
 <7Aide4lBzCPDqqanrD8I9SsT6LXneQ8CKSU4os4lH-Q=.38f1186f-01b0-4975-ad16-fcfd4eb6c031@github.com>
Message-ID: <hKZWJ3Wbt9Hysdx-TuLnVue3Az4HVw_z-nQUaNe7llM=.af93fff3-842a-48eb-873e-f716676427ad@github.com>

On Thu, 9 Mar 2023 10:36:36 GMT, Afshin Zafari <duke at openjdk.org> wrote:

>> The inline and not-inline versions of the method is stress tested to compare the performance difference. 
>> The `oop java_class` input parameter is changed to `InstanceKlass *` to gain more performance.
>> The statistics are drawn in the following charts. The vertical axis is in milliseconds.
>> 
>> ![chart (2)](https://user-images.githubusercontent.com/4697012/221848555-2884313e-9d26-41c9-a265-3f1ce295b17b.png)
>> 
>> ![chart (3)](https://user-images.githubusercontent.com/4697012/221863810-94118677-b4af-468f-90c6-5ea365ae3588.png)
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8292059: Do not inline InstanceKlass::allocate_instance()

src/hotspot/share/prims/jni.cpp line 967:

> 965: 
> 966:   instanceOop i = InstanceKlass::allocate_instance(
> 967:                     InstanceKlass::cast(java_lang_Class::as_Klass(JNIHandles::resolve_non_null(clazz))),

Perhaps it would be nice with a utility method to reduce some of the clutter. Just folding the `as_Klass` into a new method `instanceKlass::cast_from_oop(..)` (or just `from_oop`) would cut away a fair chunk and could be used to similar effect elsewhere (counting 21 cases where this would be applicable).

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

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

From mgronlun at openjdk.org  Thu Mar  9 11:33:18 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 9 Mar 2023 11:33:18 GMT
Subject: RFR: 8257967: JFR: Events for loaded agents [v6]
In-Reply-To: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
References: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
Message-ID: <qz3onWw3gJHhkpNA2qVJv0SWqVLfBK1SC7LT830CG90=.cccf5ed4-726c-48fc-867e-3f44fd87253b@github.com>

> Greetings,
> 
> We are adding support to let JFR report on Agents.
> 
> #### Design
> 
> An Agent is a library that uses any instrumentation or profiling APIs. Most agents are started and initialized on the command line, but agents can also be loaded dynamically during runtime. Because command line agents initialize during the VM startup sequence, they add to the overall startup time latency in getting the VM ready. The events will report on the time the agent took to initialize.
> 
> A JavaAgent is an agent written in the Java programming language, using the APIs in the package [java.lang.instrument](https://docs.oracle.com/en/java/javase/19/docs/api/java.instrument/java/lang/instrument/package-summary.html)
> 
> A JavaAgent is sometimes called a JPLIS agent, where the acronym JPLIS stands for Java Programming Language Instrumentation Services.
> 
> To report on JavaAgents, JFR will add the new event type jdk.JavaAgent and events will look similar to these two examples:
> 
> // Command line
> jdk.JavaAgent {
>   startTime = 12:31:19.789 (2023-03-08)
>   name = "JavaAgent.jar"
>   options = "foo=bar"
>   dynamic = false
>   initialization = 12:31:15.574 (2023-03-08)
>   initializationTime = 172 ms
> }
> 
> // Dynamic load
> jdk.JavaAgent {
>   startTime = 12:31:31.158 (2023-03-08)
>   name = "JavaAgent.jar"
>   options = "bar=baz"
>   dynamic = true
>   initialization = 12:31:31.037 (2023-03-08)
>   initializationTime = 64,1 ms
> }
> 
> The jdk.JavaAgent event type is a JFR periodic event that iterates over running Java agents.
> 
> For a JavaAgent event, the agent's name will be the specific .jar file containing the instrumentation code. The options will be the specific options passed to the .jar file as part of launching the agent, for example, on the command line: -javaagent: JavaAgent.jar=foo=bar.
> 
> The "dynamic" field denotes if the agent was loaded via the command line (dynamic = false) or dynamically (dynamic = true)
> 
> "initialization" is the timestamp the JVM invoked the initialization method, and "initializationTime" is the duration of executing the initialization method.
> 
> "startTime" represents the time the JFR framework issued the periodic event; hence "initialization" will be earlier than "startTime".
> 
> An agent can also be written in a native programming language using the [JVM Tools Interface (JVMTI)](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html). This kind of agent, sometimes called a native agent, is a platform-specific binary, sometimes referred to as a library, but here it means a .so or .dll file.
> 
> To report on native agents, JFR will add the new event type jdk.NativeAgent and events will look similar to this example:
> 
> jdk.NativeAgent {
>   startTime = 12:31:40.398 (2023-03-08)
>   name = "jdwp"
>   options = "transport=dt_socket,server=y,address=any,onjcmd=y"
>   dynamic = false
>   initialization = 12:31:36.142 (2023-03-08)
>   initializationTime = 0,00184 ms
>   path = "c:\ade\github\openjdk\jdk\build\windows-x86_64-server-slowdebug\jdk\bin\jdwp.dll"
> }
> 
> The layout of the event type is very similar to the jdk.JavaAgent event, but here the path to the native library is reported.
> 
> The initialization of a native agent is performed by invoking an agent-specified callback routine. The "initialization" is when the JVM sent or would have sent the JVMTI VMInit event to a specified callback. "initializationTime" is the duration to execute that specific callback. If no callback is specified for the JVMTI VMInit event, the "initializationTime" will be 0.
> 
> #### Implementation
> 
> There has not existed a reification of a JavaAgent directly in the JVM, as these are built on top of the JDK native library, "instrument", using a many-to-one mapping. At the level of the JVM, the only representation of agents after startup is through JvmtiEnv's, which agents request from the JVM during startup and initialization ? as such, mapping which JvmtiEnv belongs to what JavaAgent was not possible before.
> 
> Using implementation details of how the JDK native library "instrument" interacts with the JVM, we can build this mapping to track what JvmtiEnv's "belong" to what JavaAgent. This mapping now lets us report the Java-relevant context (name, options) and measure the time it takes for the JavaAgent to initialize.
> 
> When implementing this capability, it was necessary to refactor the code used to represent agents, AgentLibrary. The previous implementation was located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp.
> 
> The refactoring isolates the relevant logic into two new modules, prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their older places will help reduce the sizes of oversized arguments.cpp and threads.cpp.
> 
> The previous two lists that maintained "agents" (JVMTI) and "libraries" (Xrun) were not thread-safe for concurrent iterations. A single list that allows for concurrent iterations is therefore introduced.
> 
> Testing: jdk_jfr, tier 1 - 6
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  fixes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12923/files
  - new: https://git.openjdk.org/jdk/pull/12923/files/f0c04055..80f22257

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

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

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

From mgronlun at openjdk.org  Thu Mar  9 11:48:23 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 9 Mar 2023 11:48:23 GMT
Subject: RFR: 8257967: JFR: Events for loaded agents [v7]
In-Reply-To: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
References: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
Message-ID: <3giPMTlZQoURo1LkJ6Bq5TAxt0WsrXqj_LFopPBon7U=.daf0ce0c-e4dd-4df6-b8f2-2f4408954a64@github.com>

> Greetings,
> 
> We are adding support to let JFR report on Agents.
> 
> #### Design
> 
> An Agent is a library that uses any instrumentation or profiling APIs. Most agents are started and initialized on the command line, but agents can also be loaded dynamically during runtime. Because command line agents initialize during the VM startup sequence, they add to the overall startup time latency in getting the VM ready. The events will report on the time the agent took to initialize.
> 
> A JavaAgent is an agent written in the Java programming language, using the APIs in the package [java.lang.instrument](https://docs.oracle.com/en/java/javase/19/docs/api/java.instrument/java/lang/instrument/package-summary.html)
> 
> A JavaAgent is sometimes called a JPLIS agent, where the acronym JPLIS stands for Java Programming Language Instrumentation Services.
> 
> To report on JavaAgents, JFR will add the new event type jdk.JavaAgent and events will look similar to these two examples:
> 
> // Command line
> jdk.JavaAgent {
>   startTime = 12:31:19.789 (2023-03-08)
>   name = "JavaAgent.jar"
>   options = "foo=bar"
>   dynamic = false
>   initialization = 12:31:15.574 (2023-03-08)
>   initializationTime = 172 ms
> }
> 
> // Dynamic load
> jdk.JavaAgent {
>   startTime = 12:31:31.158 (2023-03-08)
>   name = "JavaAgent.jar"
>   options = "bar=baz"
>   dynamic = true
>   initialization = 12:31:31.037 (2023-03-08)
>   initializationTime = 64,1 ms
> }
> 
> The jdk.JavaAgent event type is a JFR periodic event that iterates over running Java agents.
> 
> For a JavaAgent event, the agent's name will be the specific .jar file containing the instrumentation code. The options will be the specific options passed to the .jar file as part of launching the agent, for example, on the command line: -javaagent: JavaAgent.jar=foo=bar.
> 
> The "dynamic" field denotes if the agent was loaded via the command line (dynamic = false) or dynamically (dynamic = true)
> 
> "initialization" is the timestamp the JVM invoked the initialization method, and "initializationTime" is the duration of executing the initialization method.
> 
> "startTime" represents the time the JFR framework issued the periodic event; hence "initialization" will be earlier than "startTime".
> 
> An agent can also be written in a native programming language using the [JVM Tools Interface (JVMTI)](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html). This kind of agent, sometimes called a native agent, is a platform-specific binary, sometimes referred to as a library, but here it means a .so or .dll file.
> 
> To report on native agents, JFR will add the new event type jdk.NativeAgent and events will look similar to this example:
> 
> jdk.NativeAgent {
>   startTime = 12:31:40.398 (2023-03-08)
>   name = "jdwp"
>   options = "transport=dt_socket,server=y,address=any,onjcmd=y"
>   dynamic = false
>   initialization = 12:31:36.142 (2023-03-08)
>   initializationTime = 0,00184 ms
>   path = "c:\ade\github\openjdk\jdk\build\windows-x86_64-server-slowdebug\jdk\bin\jdwp.dll"
> }
> 
> The layout of the event type is very similar to the jdk.JavaAgent event, but here the path to the native library is reported.
> 
> The initialization of a native agent is performed by invoking an agent-specified callback routine. The "initialization" is when the JVM sent or would have sent the JVMTI VMInit event to a specified callback. "initializationTime" is the duration to execute that specific callback. If no callback is specified for the JVMTI VMInit event, the "initializationTime" will be 0.
> 
> #### Implementation
> 
> There has not existed a reification of a JavaAgent directly in the JVM, as these are built on top of the JDK native library, "instrument", using a many-to-one mapping. At the level of the JVM, the only representation of agents after startup is through JvmtiEnv's, which agents request from the JVM during startup and initialization ? as such, mapping which JvmtiEnv belongs to what JavaAgent was not possible before.
> 
> Using implementation details of how the JDK native library "instrument" interacts with the JVM, we can build this mapping to track what JvmtiEnv's "belong" to what JavaAgent. This mapping now lets us report the Java-relevant context (name, options) and measure the time it takes for the JavaAgent to initialize.
> 
> When implementing this capability, it was necessary to refactor the code used to represent agents, AgentLibrary. The previous implementation was located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp.
> 
> The refactoring isolates the relevant logic into two new modules, prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their older places will help reduce the sizes of oversized arguments.cpp and threads.cpp.
> 
> The previous two lists that maintained "agents" (JVMTI) and "libraries" (Xrun) were not thread-safe for concurrent iterations. A single list that allows for concurrent iterations is therefore introduced.
> 
> Testing: jdk_jfr, tier 1 - 6
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12923/files
  - new: https://git.openjdk.org/jdk/pull/12923/files/80f22257..d0609bfb

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

  Stats: 15 lines in 3 files changed: 1 ins; 3 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/12923.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12923/head:pull/12923

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

From mgronlun at openjdk.org  Thu Mar  9 11:56:10 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 9 Mar 2023 11:56:10 GMT
Subject: RFR: 8257967: JFR: Events for loaded agents [v8]
In-Reply-To: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
References: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
Message-ID: <ReCjkQkRFLzi7QA-3nHOk3p5d8Ys2L1v5ezbdY8v9cI=.a5f41ff4-f699-4556-a921-c0ed381ac3ab@github.com>

> Greetings,
> 
> We are adding support to let JFR report on Agents.
> 
> #### Design
> 
> An Agent is a library that uses any instrumentation or profiling APIs. Most agents are started and initialized on the command line, but agents can also be loaded dynamically during runtime. Because command line agents initialize during the VM startup sequence, they add to the overall startup time latency in getting the VM ready. The events will report on the time the agent took to initialize.
> 
> A JavaAgent is an agent written in the Java programming language, using the APIs in the package [java.lang.instrument](https://docs.oracle.com/en/java/javase/19/docs/api/java.instrument/java/lang/instrument/package-summary.html)
> 
> A JavaAgent is sometimes called a JPLIS agent, where the acronym JPLIS stands for Java Programming Language Instrumentation Services.
> 
> To report on JavaAgents, JFR will add the new event type jdk.JavaAgent and events will look similar to these two examples:
> 
> // Command line
> jdk.JavaAgent {
>   startTime = 12:31:19.789 (2023-03-08)
>   name = "JavaAgent.jar"
>   options = "foo=bar"
>   dynamic = false
>   initialization = 12:31:15.574 (2023-03-08)
>   initializationTime = 172 ms
> }
> 
> // Dynamic load
> jdk.JavaAgent {
>   startTime = 12:31:31.158 (2023-03-08)
>   name = "JavaAgent.jar"
>   options = "bar=baz"
>   dynamic = true
>   initialization = 12:31:31.037 (2023-03-08)
>   initializationTime = 64,1 ms
> }
> 
> The jdk.JavaAgent event type is a JFR periodic event that iterates over running Java agents.
> 
> For a JavaAgent event, the agent's name will be the specific .jar file containing the instrumentation code. The options will be the specific options passed to the .jar file as part of launching the agent, for example, on the command line: -javaagent: JavaAgent.jar=foo=bar.
> 
> The "dynamic" field denotes if the agent was loaded via the command line (dynamic = false) or dynamically (dynamic = true)
> 
> "initialization" is the timestamp the JVM invoked the initialization method, and "initializationTime" is the duration of executing the initialization method.
> 
> "startTime" represents the time the JFR framework issued the periodic event; hence "initialization" will be earlier than "startTime".
> 
> An agent can also be written in a native programming language using the [JVM Tools Interface (JVMTI)](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html). This kind of agent, sometimes called a native agent, is a platform-specific binary, sometimes referred to as a library, but here it means a .so or .dll file.
> 
> To report on native agents, JFR will add the new event type jdk.NativeAgent and events will look similar to this example:
> 
> jdk.NativeAgent {
>   startTime = 12:31:40.398 (2023-03-08)
>   name = "jdwp"
>   options = "transport=dt_socket,server=y,address=any,onjcmd=y"
>   dynamic = false
>   initialization = 12:31:36.142 (2023-03-08)
>   initializationTime = 0,00184 ms
>   path = "c:\ade\github\openjdk\jdk\build\windows-x86_64-server-slowdebug\jdk\bin\jdwp.dll"
> }
> 
> The layout of the event type is very similar to the jdk.JavaAgent event, but here the path to the native library is reported.
> 
> The initialization of a native agent is performed by invoking an agent-specified callback routine. The "initialization" is when the JVM sent or would have sent the JVMTI VMInit event to a specified callback. "initializationTime" is the duration to execute that specific callback. If no callback is specified for the JVMTI VMInit event, the "initializationTime" will be 0.
> 
> #### Implementation
> 
> There has not existed a reification of a JavaAgent directly in the JVM, as these are built on top of the JDK native library, "instrument", using a many-to-one mapping. At the level of the JVM, the only representation of agents after startup is through JvmtiEnv's, which agents request from the JVM during startup and initialization ? as such, mapping which JvmtiEnv belongs to what JavaAgent was not possible before.
> 
> Using implementation details of how the JDK native library "instrument" interacts with the JVM, we can build this mapping to track what JvmtiEnv's "belong" to what JavaAgent. This mapping now lets us report the Java-relevant context (name, options) and measure the time it takes for the JavaAgent to initialize.
> 
> When implementing this capability, it was necessary to refactor the code used to represent agents, AgentLibrary. The previous implementation was located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp.
> 
> The refactoring isolates the relevant logic into two new modules, prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their older places will help reduce the sizes of oversized arguments.cpp and threads.cpp.
> 
> The previous two lists that maintained "agents" (JVMTI) and "libraries" (Xrun) were not thread-safe for concurrent iterations. A single list that allows for concurrent iterations is therefore introduced.
> 
> Testing: jdk_jfr, tier 1 - 6
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  more cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12923/files
  - new: https://git.openjdk.org/jdk/pull/12923/files/d0609bfb..db48fe8d

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

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

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

From stefank at openjdk.org  Thu Mar  9 13:40:24 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 9 Mar 2023 13:40:24 GMT
Subject: RFR: 8292059: Do not inline InstanceKlass::allocate_instance()
 [v2]
In-Reply-To: <MDZ5fEDF2yNPUNE6TadAgItEy4qgpn5qPDE7ycaQeSE=.195ee470-b89e-4481-90fb-b2d9bd205839@github.com>
References: <ZSJBTzuC4wVuKdqSLLTgw4Pds2oX5wah0Ub6rFux_tc=.c4e2ae89-cadb-4ccd-9eee-034583cf7200@github.com>
 <8koli6nAbt8Rx4Je8MRic0dPloLTb9IiUyw25BvUI0s=.07267dc7-d2a1-4426-8876-1e41b1a248ac@github.com>
 <M6-FTQ7djx8MoflW6USJYQt-p7rEuzMgBIB1AKHlFZY=.98bf79d7-4c02-4a8d-9deb-144fc72e98a5@github.com>
 <MDZ5fEDF2yNPUNE6TadAgItEy4qgpn5qPDE7ycaQeSE=.195ee470-b89e-4481-90fb-b2d9bd205839@github.com>
Message-ID: <RJA_2Hc7bdlfjSbt10tUHaL-G0Ku1bmMWpWo94WV8XQ=.342c09f9-d9eb-49fb-927b-7c0e082660c9@github.com>

On Thu, 9 Mar 2023 10:31:58 GMT, Afshin Zafari <duke at openjdk.org> wrote:

> > What is the motivation to change the parameter from `oop java_class` to `InstanceKlass*`? The call sites are now much noisier and harder to read.
> 
> This is changed to gain performance when this function is called many times.

Could you explain how that helps the performance?

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

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

From coleenp at openjdk.org  Thu Mar  9 13:55:49 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 9 Mar 2023 13:55:49 GMT
Subject: RFR: 8300926: Several startup regressions ~6-70% in 21-b6 all
 platforms [v8]
In-Reply-To: <z7_2sNpjnL2JYEhq-L6S6VvxwrCEZlHX7EDZx4do_Dw=.783bbdcb-bc62-46f0-83a4-70e6785b9fe0@github.com>
References: <yAP6c7wzGguBfKuzvbjMZdnaqydAz4PFn0pgR1UGj9s=.ce872f5d-3f7a-4e24-99d5-da5e80855ea4@github.com>
 <z7_2sNpjnL2JYEhq-L6S6VvxwrCEZlHX7EDZx4do_Dw=.783bbdcb-bc62-46f0-83a4-70e6785b9fe0@github.com>
Message-ID: <82_ePE_6SI4ZWzv5OZ0Ygs5BrQEQ6fKGrp_ZRsLuPAM=.a4f3e612-30b3-4988-a777-979d3ef0e8ae@github.com>

On Tue, 7 Mar 2023 13:47:55 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi all, please consider.
>> 
>> The original issue was when thread 1 asked to deopt nmethod set X and thread 2 asked for the same or a subset of X.
>> All method will already be marked, but the actual deoptimizing, not entrant, patching PC on stacks and patching post call nops, was not done yet. Which meant thread 2 could 'pass' thread 1.
>> Most places did deopt under Compile_lock, thus this is not an issue, but WB and clearCallSiteContext do not.
>> 
>> Since a handshakes may take long before completion and Compile_lock is used for so much more than deopts.
>> The fix in https://bugs.openjdk.org/browse/JDK-8299074 instead always emitted a handshake even when everything was already marked. (instead of adding Compile_lock to all places)
>> 
>> This turnout to be problematic in the startup, for example the number of deopt handshakes in jetty dry run startup went from 5 to 39 handshakes.
>> 
>> This fix first adds a barrier for which you do not pass until the requested deopts have happened and it coalesces the handshakes.
>> Secondly it moves handshakes part out of the Compile_lock where it is possible.
>> 
>> Which means we fix the performance bug and we reduce the contention on Compile_lock, meaning higher throughput in compiler and things such as class-loading.
>> 
>> It passes t1-t7 with flying colours! t8 still not completed and I'm redoing some testing due to last minute simplifications.
>> 
>> Thanks, Robbin
>
> Robbin Ehn has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Grab lock so code() is stable
>  - Non CHA based vtables fix

Thank you for the comment.

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

Marked as reviewed by coleenp (Reviewer).

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

From mdoerr at openjdk.org  Thu Mar  9 14:02:35 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 9 Mar 2023 14:02:35 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v12]
In-Reply-To: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
Message-ID: <XqOZaB4ecx03X-q1M0zdylSTB8L6Pgeudorge8kxM0E=.cb410f34-6472-4bac-8996-2c69234d6c8c@github.com>

> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
> 
> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
> 
> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
> 
> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Will get addressed separately: [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
> 
> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
> 
> I had to make changes to shared code and code for other platforms:
> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit.

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  The merge change has messed up some includes in the tests. Revert.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12708/files
  - new: https://git.openjdk.org/jdk/pull/12708/files/f75a240d..a2eed058

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

  Stats: 44 lines in 6 files changed: 15 ins; 21 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/12708.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12708/head:pull/12708

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

From eosterlund at openjdk.org  Thu Mar  9 14:10:36 2023
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 9 Mar 2023 14:10:36 GMT
Subject: RFR: 8300926: Several startup regressions ~6-70% in 21-b6 all
 platforms [v8]
In-Reply-To: <z7_2sNpjnL2JYEhq-L6S6VvxwrCEZlHX7EDZx4do_Dw=.783bbdcb-bc62-46f0-83a4-70e6785b9fe0@github.com>
References: <yAP6c7wzGguBfKuzvbjMZdnaqydAz4PFn0pgR1UGj9s=.ce872f5d-3f7a-4e24-99d5-da5e80855ea4@github.com>
 <z7_2sNpjnL2JYEhq-L6S6VvxwrCEZlHX7EDZx4do_Dw=.783bbdcb-bc62-46f0-83a4-70e6785b9fe0@github.com>
Message-ID: <yB5LMYyclyJBI6aou9wVL8_Ca6dhEBjcStMlEwLBoQI=.b6fc8429-f454-4e55-bb4b-28c718ec6dad@github.com>

On Tue, 7 Mar 2023 13:47:55 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi all, please consider.
>> 
>> The original issue was when thread 1 asked to deopt nmethod set X and thread 2 asked for the same or a subset of X.
>> All method will already be marked, but the actual deoptimizing, not entrant, patching PC on stacks and patching post call nops, was not done yet. Which meant thread 2 could 'pass' thread 1.
>> Most places did deopt under Compile_lock, thus this is not an issue, but WB and clearCallSiteContext do not.
>> 
>> Since a handshakes may take long before completion and Compile_lock is used for so much more than deopts.
>> The fix in https://bugs.openjdk.org/browse/JDK-8299074 instead always emitted a handshake even when everything was already marked. (instead of adding Compile_lock to all places)
>> 
>> This turnout to be problematic in the startup, for example the number of deopt handshakes in jetty dry run startup went from 5 to 39 handshakes.
>> 
>> This fix first adds a barrier for which you do not pass until the requested deopts have happened and it coalesces the handshakes.
>> Secondly it moves handshakes part out of the Compile_lock where it is possible.
>> 
>> Which means we fix the performance bug and we reduce the contention on Compile_lock, meaning higher throughput in compiler and things such as class-loading.
>> 
>> It passes t1-t7 with flying colours! t8 still not completed and I'm redoing some testing due to last minute simplifications.
>> 
>> Thanks, Robbin
>
> Robbin Ehn has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Grab lock so code() is stable
>  - Non CHA based vtables fix

Looks good.

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

Marked as reviewed by eosterlund (Reviewer).

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

From rehn at openjdk.org  Thu Mar  9 14:48:42 2023
From: rehn at openjdk.org (Robbin Ehn)
Date: Thu, 9 Mar 2023 14:48:42 GMT
Subject: RFR: 8300926: Several startup regressions ~6-70% in 21-b6 all
 platforms [v8]
In-Reply-To: <82_ePE_6SI4ZWzv5OZ0Ygs5BrQEQ6fKGrp_ZRsLuPAM=.a4f3e612-30b3-4988-a777-979d3ef0e8ae@github.com>
References: <yAP6c7wzGguBfKuzvbjMZdnaqydAz4PFn0pgR1UGj9s=.ce872f5d-3f7a-4e24-99d5-da5e80855ea4@github.com>
 <z7_2sNpjnL2JYEhq-L6S6VvxwrCEZlHX7EDZx4do_Dw=.783bbdcb-bc62-46f0-83a4-70e6785b9fe0@github.com>
 <82_ePE_6SI4ZWzv5OZ0Ygs5BrQEQ6fKGrp_ZRsLuPAM=.a4f3e612-30b3-4988-a777-979d3ef0e8ae@github.com>
Message-ID: <EJKPthEbOFyCLCOPxiW6sxGN31-2EOF2LuW5KgdUdxo=.a013d697-442f-48af-b66c-04d86fdca3c2@github.com>

On Thu, 9 Mar 2023 13:52:25 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Thank you for the comment.

Thanks!

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

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

From rehn at openjdk.org  Thu Mar  9 14:48:45 2023
From: rehn at openjdk.org (Robbin Ehn)
Date: Thu, 9 Mar 2023 14:48:45 GMT
Subject: RFR: 8300926: Several startup regressions ~6-70% in 21-b6 all
 platforms [v8]
In-Reply-To: <yB5LMYyclyJBI6aou9wVL8_Ca6dhEBjcStMlEwLBoQI=.b6fc8429-f454-4e55-bb4b-28c718ec6dad@github.com>
References: <yAP6c7wzGguBfKuzvbjMZdnaqydAz4PFn0pgR1UGj9s=.ce872f5d-3f7a-4e24-99d5-da5e80855ea4@github.com>
 <z7_2sNpjnL2JYEhq-L6S6VvxwrCEZlHX7EDZx4do_Dw=.783bbdcb-bc62-46f0-83a4-70e6785b9fe0@github.com>
 <yB5LMYyclyJBI6aou9wVL8_Ca6dhEBjcStMlEwLBoQI=.b6fc8429-f454-4e55-bb4b-28c718ec6dad@github.com>
Message-ID: <3EeDW0z2xQyX9iDR_e3a8gUrx-u_LYYN0ykAcbDfx84=.6b07a31e-c717-474b-8756-6c10c0a7d3c6@github.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
On Thu, 9 Mar 2023 14:07:18 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> Looks good.

Thanks!

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

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

From rehn at openjdk.org  Thu Mar  9 14:48:48 2023
From: rehn at openjdk.org (Robbin Ehn)
Date: Thu, 9 Mar 2023 14:48:48 GMT
Subject: RFR: 8300926: Several startup regressions ~6-70% in 21-b6 all
 platforms [v8]
In-Reply-To: <z7_2sNpjnL2JYEhq-L6S6VvxwrCEZlHX7EDZx4do_Dw=.783bbdcb-bc62-46f0-83a4-70e6785b9fe0@github.com>
References: <yAP6c7wzGguBfKuzvbjMZdnaqydAz4PFn0pgR1UGj9s=.ce872f5d-3f7a-4e24-99d5-da5e80855ea4@github.com>
 <z7_2sNpjnL2JYEhq-L6S6VvxwrCEZlHX7EDZx4do_Dw=.783bbdcb-bc62-46f0-83a4-70e6785b9fe0@github.com>
Message-ID: <QPFW8eFvlMD8bJnGpIs-2gxHP9jg8hTy9hr4VkkT0P4=.4a3d9bbd-8d08-45ac-9fd7-e882778b58c9@github.com>

On Tue, 7 Mar 2023 13:47:55 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi all, please consider.
>> 
>> The original issue was when thread 1 asked to deopt nmethod set X and thread 2 asked for the same or a subset of X.
>> All method will already be marked, but the actual deoptimizing, not entrant, patching PC on stacks and patching post call nops, was not done yet. Which meant thread 2 could 'pass' thread 1.
>> Most places did deopt under Compile_lock, thus this is not an issue, but WB and clearCallSiteContext do not.
>> 
>> Since a handshakes may take long before completion and Compile_lock is used for so much more than deopts.
>> The fix in https://bugs.openjdk.org/browse/JDK-8299074 instead always emitted a handshake even when everything was already marked. (instead of adding Compile_lock to all places)
>> 
>> This turnout to be problematic in the startup, for example the number of deopt handshakes in jetty dry run startup went from 5 to 39 handshakes.
>> 
>> This fix first adds a barrier for which you do not pass until the requested deopts have happened and it coalesces the handshakes.
>> Secondly it moves handshakes part out of the Compile_lock where it is possible.
>> 
>> Which means we fix the performance bug and we reduce the contention on Compile_lock, meaning higher throughput in compiler and things such as class-loading.
>> 
>> It passes t1-t7 with flying colours! t8 still not completed and I'm redoing some testing due to last minute simplifications.
>> 
>> Thanks, Robbin
>
> Robbin Ehn has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Grab lock so code() is stable
>  - Non CHA based vtables fix

Now passed t1-t7.

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

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

From kbarrett at openjdk.org  Thu Mar  9 15:43:06 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 9 Mar 2023 15:43:06 GMT
Subject: RFR: 8303900: Rename BitMap search functions
Message-ID: <g09LwD0eFfQb6kIVSi0KAez9RTpnhO91I3QZvpM_Rpc=.bfa7b6fb-c552-4a9d-8e28-c41251e4f2e7@github.com>

Please review this renaming of the following functions in BitMap:

get_next_one_offset => find_first_set_bit
get_next_zero_offset => find_first_clear_bit
get_next_one_offset_aligned_right => find_first_set_bit_aligned_right

Note that ShenandoahMarkBitMap::get_next_one_offset is not being renamed.  For
some reason that class contains a copy of a sizable chunk of the code from
some version of BitMap.  (Not sure why it doesn't use an internal BitMapView
rather than code copying.)

Testing:
mach5 tier1-5

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

Commit messages:
 - update gtests
 - update shenandoah uses
 - update zgc uses
 - update gc/shared uses
 - update Parallel uses
 - update G1 uses
 - rename functions

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

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

From mdoerr at openjdk.org  Thu Mar  9 15:51:56 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 9 Mar 2023 15:51:56 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v13]
In-Reply-To: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
Message-ID: <SdZsu2_4Hr1nuvWNRscMLARBg3Dfg1v7HgUiKT_BVwo=.b4388c52-679d-4449-a2a9-00f23b2f7b5c@github.com>

> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
> 
> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
> 
> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
> 
> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Will get addressed separately: [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
> 
> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
> 
> I had to make changes to shared code and code for other platforms:
> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit.

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  Remove LinuxPPC64CallArranger.java because it doesn't contain anything.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12708/files
  - new: https://git.openjdk.org/jdk/pull/12708/files/a2eed058..fb87284c

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

  Stats: 44 lines in 3 files changed: 0 ins; 38 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/12708.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12708/head:pull/12708

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

From coleenp at openjdk.org  Thu Mar  9 15:52:29 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 9 Mar 2023 15:52:29 GMT
Subject: RFR: 8292059: Do not inline InstanceKlass::allocate_instance()
 [v3]
In-Reply-To: <7Aide4lBzCPDqqanrD8I9SsT6LXneQ8CKSU4os4lH-Q=.38f1186f-01b0-4975-ad16-fcfd4eb6c031@github.com>
References: <ZSJBTzuC4wVuKdqSLLTgw4Pds2oX5wah0Ub6rFux_tc=.c4e2ae89-cadb-4ccd-9eee-034583cf7200@github.com>
 <7Aide4lBzCPDqqanrD8I9SsT6LXneQ8CKSU4os4lH-Q=.38f1186f-01b0-4975-ad16-fcfd4eb6c031@github.com>
Message-ID: <_mI_uKQkRL0ORBaxslEozgsHhICHMymcOtsxQFfMKqI=.cae696ed-3dc8-4011-84fb-c638b10a4c3f@github.com>

On Thu, 9 Mar 2023 10:36:36 GMT, Afshin Zafari <duke at openjdk.org> wrote:

>> The inline and not-inline versions of the method is stress tested to compare the performance difference. 
>> The `oop java_class` input parameter is changed to `InstanceKlass *` to gain more performance.
>> The statistics are drawn in the following charts. The vertical axis is in milliseconds.
>> 
>> ![chart (2)](https://user-images.githubusercontent.com/4697012/221848555-2884313e-9d26-41c9-a265-3f1ce295b17b.png)
>> 
>> ![chart (3)](https://user-images.githubusercontent.com/4697012/221863810-94118677-b4af-468f-90c6-5ea365ae3588.png)
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8292059: Do not inline InstanceKlass::allocate_instance()

There was a small performance difference (loss) with making the static InstanceKlass::allocate_instance function not inlined.  The experiment to effectively inline the conversion from oop  java_class to InstanceKlass regained this performance in Afshin's testing.  I agree the parameter change is messy and with Claes that we should have a utility function - in instanceKlass.inline.hpp.  Maybe call it from_class like:

InstanceKlass* InstanceKlass::from_class(oop java_class) { ... }

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

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

From coleenp at openjdk.org  Thu Mar  9 15:56:12 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 9 Mar 2023 15:56:12 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry
In-Reply-To: <CFZ6QoFPg2ShDr5Yh7CvmGnsHaqhsdZszT-Th0k9Dhc=.c127ecf8-f096-44f4-8d72-041a31f4a789@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <LQTG-IYnef9srlK41aw_InVGTvihfRW2ez8deMPILoY=.efc03d45-0f5c-4d81-8c23-310c54969c07@github.com>
 <CFZ6QoFPg2ShDr5Yh7CvmGnsHaqhsdZszT-Th0k9Dhc=.c127ecf8-f096-44f4-8d72-041a31f4a789@github.com>
Message-ID: <q72KJ-HCChvjw1pbxhkPra20OwSB5m_dWVY7KPCfw40=.2cbd4700-863d-432f-9458-1bef50d3c4df@github.com>

On Tue, 7 Mar 2023 19:25:58 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> src/hotspot/share/oops/cpCache.cpp line 727:
>> 
>>> 725:   set_reference_map(nullptr);
>>> 726: #if INCLUDE_CDS
>>> 727:   if (_initial_entries != nullptr) {
>> 
>> @iklam with moving invokedynamic entries out, do you still need to save initialized entries ?  Does invokehandle need this? (Should have separate RFE if more cleanup is possible)
>
> This along with the previous comment about `_invokedynamic_references_map` would probably be better suited for their own RFE. I think the scope of this PR should be limited to the indy structure and its implementation, so any changes related to invokehandle can be traced more easily.

ok, that's fine.

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

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

From mdoerr at openjdk.org  Thu Mar  9 15:56:19 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 9 Mar 2023 15:56:19 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v3]
In-Reply-To: <mo8rpizKpaAts6jpIZaQjgBZkCZE7uZaxaBW2j6mNxw=.4834669e-db31-4989-85d1-8bf94aabf651@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com>
 <ubsdQFbNzTtdhNeZwCJyA5BRc2mR4AmQwk6hgJOlBy0=.6974c426-eeb2-4212-8038-9a8e00a0e7de@github.com>
 <mo8rpizKpaAts6jpIZaQjgBZkCZE7uZaxaBW2j6mNxw=.4834669e-db31-4989-85d1-8bf94aabf651@github.com>
Message-ID: <sA4uhHOpgE8NM3tNtd6WlIz_kReFN4nyj8qgYTxGRYM=.59dd243f-a0c2-4aab-b85e-aa921dbb60c8@github.com>

On Wed, 1 Mar 2023 06:27:19 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/CallArranger.java line 68:
>> 
>>> 66: public abstract class CallArranger {
>>> 67:     // Linux PPC64 Little Endian uses ABI v2.
>>> 68:     private static final boolean useABIv2 = ByteOrder.nativeOrder() == ByteOrder.LITTLE_ENDIAN;
>> 
>> Now that I'm here. This could be a potentially interesting case for having 2 subclasses of CallArranger: one for `useABIv2 == true` and one for `false`.
>
> Yeah, let's wait until we know what changes we need for AIX (and Big Endian linux).

I think having a ABIV1CallArranger (for Big Endian linux and AIX) and a ABIV2CallArranger (linux ppc64le) will make sense. That's why I have removed the LinuxPPC64CallArranger.java with
https://github.com/openjdk/jdk/pull/12708/commits/fb87284c1d3df946db378d196d7f48cd3acbab01. I guess a good time for such cleanup will be after the code for all variants is available (not part of this PR).

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

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

From coleenp at openjdk.org  Thu Mar  9 16:03:53 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 9 Mar 2023 16:03:53 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry
In-Reply-To: <A_IUIYIKAh5BxaCSeoW_3afjPBsfh641ahYI-HfSwJ4=.ed14415f-4bcd-4d62-8cf6-e1d254839397@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <LQTG-IYnef9srlK41aw_InVGTvihfRW2ez8deMPILoY=.efc03d45-0f5c-4d81-8c23-310c54969c07@github.com>
 <A_IUIYIKAh5BxaCSeoW_3afjPBsfh641ahYI-HfSwJ4=.ed14415f-4bcd-4d62-8cf6-e1d254839397@github.com>
Message-ID: <XcgkoKgIiEG7ZF0_EH-8mD1MR-6j4xTTRFIFDSH7gg0=.6af759b8-223d-4fa2-a425-967857687a1e@github.com>

On Tue, 7 Mar 2023 15:04:29 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> src/hotspot/cpu/ppc/templateTable_ppc_64.cpp line 53:
>> 
>>> 51: 
>>> 52: #undef __
>>> 53: #define __ Disassembler::hook<InterpreterMacroAssembler>(__FILE__, __LINE__, _masm)->
>> 
>> What is this?  Is this something useful for debugging the template interpreter?  Probably doesn't belong with this change but might be nice to have (?) @reinrich
>
> Yes this is really useful when debugging the template interpreter. It annotates the disassembly with the generator source code. It helped tracking down a bug in the ppc part oft this pr. Other platforms have it too.
> 
> Example:
> 
> invokedynamic  186 invokedynamic  [0x00003fff80075a00, 0x00003fff80075dc8]  968 bytes
> 
> --------------------------------------------------------------------------------
>   0x00003fff80075a00:   std     r17,0(r15)                  ;;@FILE: src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp
>                                                             ;; 2185:   aep = __ pc();  __ push_ptr();  __ b(L);
>   0x00003fff80075a04:   addi    r15,r15,-8
>   0x00003fff80075a08:   b       0x00003fff80075a40          ;; 2185:   aep = __ pc();  __ push_ptr();  __ b(L);
>   0x00003fff80075a0c:   stfs    f15,0(r15)                  ;; 2186:   fep = __ pc();  __ push_f();    __ b(L);
>   0x00003fff80075a10:   addi    r15,r15,-8
>   0x00003fff80075a14:   b       0x00003fff80075a40          ;; 2186:   fep = __ pc();  __ push_f();    __ b(L);
>   0x00003fff80075a18:   stfd    f15,-8(r15)                 ;; 2187:   dep = __ pc();  __ push_d();    __ b(L);
>   0x00003fff80075a1c:   addi    r15,r15,-16
>   0x00003fff80075a20:   b       0x00003fff80075a40          ;; 2187:   dep = __ pc();  __ push_d();    __ b(L);
>   0x00003fff80075a24:   li      r0,0                        ;; 2188:   lep = __ pc();  __ push_l();    __ b(L);
>   0x00003fff80075a28:   std     r0,0(r15)
>   0x00003fff80075a2c:   std     r17,-8(r15)
>   0x00003fff80075a30:   addi    r15,r15,-16
>   0x00003fff80075a34:   b       0x00003fff80075a40          ;; 2188:   lep = __ pc();  __ push_l();    __ b(L);
>   0x00003fff80075a38:   stw     r17,0(r15)                  ;; 2189:   __ align(32, 12, 24); // align L
>                                                             ;; 2191:   iep = __ pc();  __ push_i();
>   0x00003fff80075a3c:   addi    r15,r15,-8
>   0x00003fff80075a40:   li      r21,1                       ;; 2192:   vep = __ pc();
>                                                             ;; 2193:   __ bind(L);
>                                                             ;;@FILE: src/hotspot/share/interpreter/templateInterpreterGenerator.cpp
>                                                             ;;  366:   __ verify_FPU(1, t->tos_in());
>                                                             ;;@FILE: src/hotspot/cpu/ppc/templateTable_ppc_64.cpp
>                                                             ;; 2293:   __ load_resolved_indy_entry(cache, index);
>   0x00003fff80075a44:   lwax    r21,r14,r21
>   0x00003fff80075a48:   nand    r21,r21,r21
>   0x00003fff80075a4c:   ld      r31,40(r27)
>   0x00003fff80075a50:   rldicr  r21,r21,4,59
>   0x00003fff80075a54:   addi    r21,r21,8
>   0x00003fff80075a58:   add     r31,r31,r21
>   0x00003fff80075a5c:   ld      r22,0(r31)                  ;; 2294:   __ ld_ptr(method, in_bytes(ResolvedIndyEntry::method_offset()), cache);
>   0x00003fff80075a60:   cmpdi   r22,0                       ;; 2297:   __ cmpdi(CCR0, method, 0);
>   0x00003fff80075a64:   bne-    0x00003fff80075b94          ;; 2298:   __ bne(CCR0, resolved);,bo=0b00100[no_hint]
>   0x00003fff80075a68:   li      r4,186                      ;; 2304:   __ li(R4_ARG2, code);
>   0x00003fff80075a6c:   ld      r11,0(r1)                   ;; 2305:   __ call_VM(noreg, entry, R4_ARG2, true);

This change should be in a further RFE though (and you can explain it there so we can maybe use it in the other platforms too).  Does it affect performance when generating the template interpreter?  Do you need to have hsdis in the LD_LIBRARY_PATH environment variable to use this?  I see it's already used by default in one place.

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

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

From coleenp at openjdk.org  Thu Mar  9 16:03:54 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 9 Mar 2023 16:03:54 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry
In-Reply-To: <XcgkoKgIiEG7ZF0_EH-8mD1MR-6j4xTTRFIFDSH7gg0=.6af759b8-223d-4fa2-a425-967857687a1e@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <LQTG-IYnef9srlK41aw_InVGTvihfRW2ez8deMPILoY=.efc03d45-0f5c-4d81-8c23-310c54969c07@github.com>
 <A_IUIYIKAh5BxaCSeoW_3afjPBsfh641ahYI-HfSwJ4=.ed14415f-4bcd-4d62-8cf6-e1d254839397@github.com>
 <XcgkoKgIiEG7ZF0_EH-8mD1MR-6j4xTTRFIFDSH7gg0=.6af759b8-223d-4fa2-a425-967857687a1e@github.com>
Message-ID: <0TIZDGiEpwyU6vRDvWCTiQBoyekNHwa5QoJr4ViPh0U=.7a45b939-ce28-4936-871b-dfc4c0b3a5ec@github.com>

On Thu, 9 Mar 2023 16:00:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Yes this is really useful when debugging the template interpreter. It annotates the disassembly with the generator source code. It helped tracking down a bug in the ppc part oft this pr. Other platforms have it too.
>> 
>> Example:
>> 
>> invokedynamic  186 invokedynamic  [0x00003fff80075a00, 0x00003fff80075dc8]  968 bytes
>> 
>> --------------------------------------------------------------------------------
>>   0x00003fff80075a00:   std     r17,0(r15)                  ;;@FILE: src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp
>>                                                             ;; 2185:   aep = __ pc();  __ push_ptr();  __ b(L);
>>   0x00003fff80075a04:   addi    r15,r15,-8
>>   0x00003fff80075a08:   b       0x00003fff80075a40          ;; 2185:   aep = __ pc();  __ push_ptr();  __ b(L);
>>   0x00003fff80075a0c:   stfs    f15,0(r15)                  ;; 2186:   fep = __ pc();  __ push_f();    __ b(L);
>>   0x00003fff80075a10:   addi    r15,r15,-8
>>   0x00003fff80075a14:   b       0x00003fff80075a40          ;; 2186:   fep = __ pc();  __ push_f();    __ b(L);
>>   0x00003fff80075a18:   stfd    f15,-8(r15)                 ;; 2187:   dep = __ pc();  __ push_d();    __ b(L);
>>   0x00003fff80075a1c:   addi    r15,r15,-16
>>   0x00003fff80075a20:   b       0x00003fff80075a40          ;; 2187:   dep = __ pc();  __ push_d();    __ b(L);
>>   0x00003fff80075a24:   li      r0,0                        ;; 2188:   lep = __ pc();  __ push_l();    __ b(L);
>>   0x00003fff80075a28:   std     r0,0(r15)
>>   0x00003fff80075a2c:   std     r17,-8(r15)
>>   0x00003fff80075a30:   addi    r15,r15,-16
>>   0x00003fff80075a34:   b       0x00003fff80075a40          ;; 2188:   lep = __ pc();  __ push_l();    __ b(L);
>>   0x00003fff80075a38:   stw     r17,0(r15)                  ;; 2189:   __ align(32, 12, 24); // align L
>>                                                             ;; 2191:   iep = __ pc();  __ push_i();
>>   0x00003fff80075a3c:   addi    r15,r15,-8
>>   0x00003fff80075a40:   li      r21,1                       ;; 2192:   vep = __ pc();
>>                                                             ;; 2193:   __ bind(L);
>>                                                             ;;@FILE: src/hotspot/share/interpreter/templateInterpreterGenerator.cpp
>>                                                             ;;  366:   __ verify_FPU(1, t->tos_in());
>>                                                             ;;@FILE: src/hotspot/cpu/ppc/templateTable_ppc_64.cpp
>>                                                             ;; 2293:   __ load_resolved_indy_entry(cache, index);
>>   0x00003fff80075a44:   lwax    r21,r14,r21
>>   0x00003fff80075a48:   nand    r21,r21,r21
>>   0x00003fff80075a4c:   ld      r31,40(r27)
>>   0x00003fff80075a50:   rldicr  r21,r21,4,59
>>   0x00003fff80075a54:   addi    r21,r21,8
>>   0x00003fff80075a58:   add     r31,r31,r21
>>   0x00003fff80075a5c:   ld      r22,0(r31)                  ;; 2294:   __ ld_ptr(method, in_bytes(ResolvedIndyEntry::method_offset()), cache);
>>   0x00003fff80075a60:   cmpdi   r22,0                       ;; 2297:   __ cmpdi(CCR0, method, 0);
>>   0x00003fff80075a64:   bne-    0x00003fff80075b94          ;; 2298:   __ bne(CCR0, resolved);,bo=0b00100[no_hint]
>>   0x00003fff80075a68:   li      r4,186                      ;; 2304:   __ li(R4_ARG2, code);
>>   0x00003fff80075a6c:   ld      r11,0(r1)                   ;; 2305:   __ call_VM(noreg, entry, R4_ARG2, true);
>
> This change should be in a further RFE though (and you can explain it there so we can maybe use it in the other platforms too).  Does it affect performance when generating the template interpreter?  Do you need to have hsdis in the LD_LIBRARY_PATH environment variable to use this?  I see it's already used by default in one place.

This looks cool.

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

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

From rrich at openjdk.org  Thu Mar  9 16:47:09 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Thu, 9 Mar 2023 16:47:09 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry
In-Reply-To: <0TIZDGiEpwyU6vRDvWCTiQBoyekNHwa5QoJr4ViPh0U=.7a45b939-ce28-4936-871b-dfc4c0b3a5ec@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <LQTG-IYnef9srlK41aw_InVGTvihfRW2ez8deMPILoY=.efc03d45-0f5c-4d81-8c23-310c54969c07@github.com>
 <A_IUIYIKAh5BxaCSeoW_3afjPBsfh641ahYI-HfSwJ4=.ed14415f-4bcd-4d62-8cf6-e1d254839397@github.com>
 <XcgkoKgIiEG7ZF0_EH-8mD1MR-6j4xTTRFIFDSH7gg0=.6af759b8-223d-4fa2-a425-967857687a1e@github.com>
 <0TIZDGiEpwyU6vRDvWCTiQBoyekNHwa5QoJr4ViPh0U=.7a45b939-ce28-4936-871b-dfc4c0b3a5ec@github.com>
Message-ID: <t28c8qyAbO9uZ4Q2be18QY6mmuWkf5MnNdtz_2Vlggw=.6115ce3b-f5c9-4d86-8130-33e6b606bf56@github.com>

On Thu, 9 Mar 2023 16:01:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change should be in a further RFE though (and you can explain it there so we can maybe use it in the other platforms too).  Does it affect performance when generating the template interpreter?  Do you need to have hsdis in the LD_LIBRARY_PATH environment variable to use this?  I see it's already used by default in one place.
>
> This looks cool.

> This change should be in a further RFE though (and you can explain it there so we can maybe use it in the other platforms too).

Ok.

> Does it affect performance when generating the template interpreter?

I didn't think it would affect performance if the interpreter is not printed. I have not measured it though.

> Do you need to have hsdis in the LD_LIBRARY_PATH environment variable to use this? I see it's already used by default in one place.

Yes you do. It is not working with the AbstractDisassembler which produces a hex dump of the machine code.

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

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

From mgronlun at openjdk.org  Thu Mar  9 16:58:42 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 9 Mar 2023 16:58:42 GMT
Subject: RFR: 8257967: JFR: Events for loaded agents [v9]
In-Reply-To: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
References: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
Message-ID: <HgrCtIIibi1v0BdGh1myrOFfq1z8CrlDf2aFHFzP_mo=.fd09126d-2bcf-4e7f-8d9f-3933ed676566@github.com>

> Greetings,
> 
> We are adding support to let JFR report on Agents.
> 
> #### Design
> 
> An Agent is a library that uses any instrumentation or profiling APIs. Most agents are started and initialized on the command line, but agents can also be loaded dynamically during runtime. Because command line agents initialize during the VM startup sequence, they add to the overall startup time latency in getting the VM ready. The events will report on the time the agent took to initialize.
> 
> A JavaAgent is an agent written in the Java programming language, using the APIs in the package [java.lang.instrument](https://docs.oracle.com/en/java/javase/19/docs/api/java.instrument/java/lang/instrument/package-summary.html)
> 
> A JavaAgent is sometimes called a JPLIS agent, where the acronym JPLIS stands for Java Programming Language Instrumentation Services.
> 
> To report on JavaAgents, JFR will add the new event type jdk.JavaAgent and events will look similar to these two examples:
> 
> // Command line
> jdk.JavaAgent {
>   startTime = 12:31:19.789 (2023-03-08)
>   name = "JavaAgent.jar"
>   options = "foo=bar"
>   dynamic = false
>   initialization = 12:31:15.574 (2023-03-08)
>   initializationTime = 172 ms
> }
> 
> // Dynamic load
> jdk.JavaAgent {
>   startTime = 12:31:31.158 (2023-03-08)
>   name = "JavaAgent.jar"
>   options = "bar=baz"
>   dynamic = true
>   initialization = 12:31:31.037 (2023-03-08)
>   initializationTime = 64,1 ms
> }
> 
> The jdk.JavaAgent event type is a JFR periodic event that iterates over running Java agents.
> 
> For a JavaAgent event, the agent's name will be the specific .jar file containing the instrumentation code. The options will be the specific options passed to the .jar file as part of launching the agent, for example, on the command line: -javaagent: JavaAgent.jar=foo=bar.
> 
> The "dynamic" field denotes if the agent was loaded via the command line (dynamic = false) or dynamically (dynamic = true)
> 
> "initialization" is the timestamp the JVM invoked the initialization method, and "initializationTime" is the duration of executing the initialization method.
> 
> "startTime" represents the time the JFR framework issued the periodic event; hence "initialization" will be earlier than "startTime".
> 
> An agent can also be written in a native programming language using the [JVM Tools Interface (JVMTI)](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html). This kind of agent, sometimes called a native agent, is a platform-specific binary, sometimes referred to as a library, but here it means a .so or .dll file.
> 
> To report on native agents, JFR will add the new event type jdk.NativeAgent and events will look similar to this example:
> 
> jdk.NativeAgent {
>   startTime = 12:31:40.398 (2023-03-08)
>   name = "jdwp"
>   options = "transport=dt_socket,server=y,address=any,onjcmd=y"
>   dynamic = false
>   initialization = 12:31:36.142 (2023-03-08)
>   initializationTime = 0,00184 ms
>   path = "c:\ade\github\openjdk\jdk\build\windows-x86_64-server-slowdebug\jdk\bin\jdwp.dll"
> }
> 
> The layout of the event type is very similar to the jdk.JavaAgent event, but here the path to the native library is reported.
> 
> The initialization of a native agent is performed by invoking an agent-specified callback routine. The "initialization" is when the JVM sent or would have sent the JVMTI VMInit event to a specified callback. "initializationTime" is the duration to execute that specific callback. If no callback is specified for the JVMTI VMInit event, the "initializationTime" will be 0.
> 
> #### Implementation
> 
> There has not existed a reification of a JavaAgent directly in the JVM, as these are built on top of the JDK native library, "instrument", using a many-to-one mapping. At the level of the JVM, the only representation of agents after startup is through JvmtiEnv's, which agents request from the JVM during startup and initialization ? as such, mapping which JvmtiEnv belongs to what JavaAgent was not possible before.
> 
> Using implementation details of how the JDK native library "instrument" interacts with the JVM, we can build this mapping to track what JvmtiEnv's "belong" to what JavaAgent. This mapping now lets us report the Java-relevant context (name, options) and measure the time it takes for the JavaAgent to initialize.
> 
> When implementing this capability, it was necessary to refactor the code used to represent agents, AgentLibrary. The previous implementation was located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp.
> 
> The refactoring isolates the relevant logic into two new modules, prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their older places will help reduce the sizes of oversized arguments.cpp and threads.cpp.
> 
> The previous two lists that maintained "agents" (JVMTI) and "libraries" (Xrun) were not thread-safe for concurrent iterations. A single list that allows for concurrent iterations is therefore introduced.
> 
> Testing: jdk_jfr, tier 1 - 6
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  handle multiple envs with same VMInit callback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12923/files
  - new: https://git.openjdk.org/jdk/pull/12923/files/db48fe8d..abeaa324

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

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

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

From kvn at openjdk.org  Thu Mar  9 17:26:30 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 9 Mar 2023 17:26:30 GMT
Subject: RFR: JDK-8300783: Consolidate byteswap implementations [v14]
In-Reply-To: <-b783DPmWbWFeigKf7F7SFYddDKwErM4AdFcfRx01eM=.5794fa08-a0d7-4761-a449-8ebfd639e30d@github.com>
References: <MLBMwI7xt4IKgpb3AHXJ_J11Ibhijp_q2RFtLJOwHpA=.b7da6b6b-69b8-426d-8eab-c7c3aaa0847e@github.com>
 <-b783DPmWbWFeigKf7F7SFYddDKwErM4AdFcfRx01eM=.5794fa08-a0d7-4761-a449-8ebfd639e30d@github.com>
Message-ID: <MWj3P8IOHchp_Nke-Mx32YMzDitUTAloHn9gJlo-Noo=.21901b77-39ab-4432-af6e-6dbd683f4e9f@github.com>

On Wed, 15 Feb 2023 15:39:14 GMT, Justin King <jcking at openjdk.org> wrote:

>> Deduplicate byte swapping implementations by consolidating them into `utilities/byteswap.hpp`, following `std::byteswap` introduced in C++23. Further simplification of `Bytes` will follow in https://github.com/openjdk/jdk/pull/12078.
>
> Justin King 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:
> 
>  - Merge remote-tracking branch 'upstream/master' into byteswap
>  - Update based on review
>    
>    Signed-off-by: Justin King <jcking at google.com>
>  - Fix copyright
>    
>    Signed-off-by: Justin King <jcking at google.com>
>  - Update copyright
>    
>    Signed-off-by: Justin King <jcking at google.com>
>  - Add missing include
>    
>    Signed-off-by: Justin King <jcking at google.com>
>  - Remove unused include
>    
>    Signed-off-by: Justin King <jcking at google.com>
>  - Reorganize tests
>    
>    Signed-off-by: Justin King <jcking at google.com>
>  - Fix test
>    
>    Signed-off-by: Justin King <jcking at google.com>
>  - Merge remote-tracking branch 'upstream/master' into byteswap
>  - Be restrict on requiring 1, 2, 4, or 8 byte integers
>    
>    Signed-off-by: Justin King <jcking at google.com>
>  - ... and 14 more: https://git.openjdk.org/jdk/compare/044b3f10...223d733b

Tier1-5 testing passed clean. Good.

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

Marked as reviewed by kvn (Reviewer).

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

From mdoerr at openjdk.org  Thu Mar  9 17:29:37 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 9 Mar 2023 17:29:37 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v14]
In-Reply-To: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
Message-ID: <IwJ-UTPgCC3n5uLzRADxzt1Q8rIIcHwXetuG4hhhqMc=.a6835dde-3c2f-4cc8-bdaf-25507334066b@github.com>

> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
> 
> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
> 
> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
> 
> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Will get addressed separately: [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
> 
> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
> 
> I had to make changes to shared code and code for other platforms:
> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit.

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  Introduce ABIv2CallArranger for linux ppc64le.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12708/files
  - new: https://git.openjdk.org/jdk/pull/12708/files/fb87284c..2e4e269e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=12-13

  Stats: 178 lines in 8 files changed: 99 ins; 58 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/12708.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12708/head:pull/12708

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

From stefank at openjdk.org  Thu Mar  9 17:37:04 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 9 Mar 2023 17:37:04 GMT
Subject: RFR: 8292059: Do not inline InstanceKlass::allocate_instance()
 [v3]
In-Reply-To: <7Aide4lBzCPDqqanrD8I9SsT6LXneQ8CKSU4os4lH-Q=.38f1186f-01b0-4975-ad16-fcfd4eb6c031@github.com>
References: <ZSJBTzuC4wVuKdqSLLTgw4Pds2oX5wah0Ub6rFux_tc=.c4e2ae89-cadb-4ccd-9eee-034583cf7200@github.com>
 <7Aide4lBzCPDqqanrD8I9SsT6LXneQ8CKSU4os4lH-Q=.38f1186f-01b0-4975-ad16-fcfd4eb6c031@github.com>
Message-ID: <AoO4NoxXkd0A7BaeS9USCnCIzoBEuQXtQ6IzoZk0Vho=.ec64e661-66cb-4d5b-8a24-8cffede72eae@github.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
On Thu, 9 Mar 2023 10:36:36 GMT, Afshin Zafari <duke at openjdk.org> wrote:

>> The inline and not-inline versions of the method is stress tested to compare the performance difference. 
>> The `oop java_class` input parameter is changed to `InstanceKlass *` to gain more performance.
>> The statistics are drawn in the following charts. The vertical axis is in milliseconds.
>> 
>> ![chart (2)](https://user-images.githubusercontent.com/4697012/221848555-2884313e-9d26-41c9-a265-3f1ce295b17b.png)
>> 
>> ![chart (3)](https://user-images.githubusercontent.com/4697012/221863810-94118677-b4af-468f-90c6-5ea365ae3588.png)
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8292059: Do not inline InstanceKlass::allocate_instance()

That's really surprising. I also don't see how any of the proposed changes could affect the GC so much. This makes me suspicious of the performance claims.

Could you redo the benchmarking and give us more information about:
1) What benchmarks were run
2) What was the benchmarks scores and GC metrics
3) What was the run-to-run variance in the scores and metrics

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

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

From mdoerr at openjdk.org  Thu Mar  9 17:42:50 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 9 Mar 2023 17:42:50 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v3]
In-Reply-To: <hJkc1ozy4f7BIvXZ_xQ3HRttVsBs0ceUIMmq4cDWrzQ=.bc3223f5-cb33-46c7-9708-ab40ba5943b0@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com>
 <HT8kQfjS98dYHeAMcNL5latokRiw3YK8npxl5yCD4hw=.28b19bac-cbfa-4461-a1db-c899c55b7485@github.com>
 <wBVqRDFM23KM8fjjPtUFNdW56FYsSpvOAVvHmpdjbzo=.7c429606-ac19-4f36-8e25-459534983924@github.com>
 <QMh_faUf_LLUf68WrZiFxmPHiFcHDBfKDg3g-oekBeg=.096acd06-65c4-4357-ad4a-4089b5478fff@github.com>
 <hJkc1ozy4f7BIvXZ_xQ3HRttVsBs0ceUIMmq4cDWrzQ=.bc3223f5-cb33-46c7-9708-ab40ba5943b0@github.com>
Message-ID: <mknfp22D3MdgwuitW4rYeIdz2S43a8wQdSmLerF2yO0=.94e5cf61-b2b8-41f3-b44e-0bde47b33bfc@github.com>

On Mon, 6 Mar 2023 16:38:37 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> @JornVernee: Thanks a lot for your detailed review! I have quite a few TODOs which include:
>> - Include my tests for the HFA corner cases.
>> - Try to improve handling of the overlapping registers as you suggested.
>> - Check nesting of HFA.
>> 
>> There will surely be more when looking into Big Endian support after merging with your recent work on https://github.com/openjdk/panama-foreign/compare/foreign-memaccess+abi...JornVernee:panama-foreign:OOB
>> We should get rid of oversized accesses on PPC64, too.
>> Thanks for sharing your plans to intrisify `linkToNative` in C2 later. I guess we should do more preparation work on all platforms when that gets addressed.
>
> @TheRealMDoerr I've moved the support for structs/unions that are not a power of 2 in size to this repo, so you should be able to merge the master branch to get it now.

@JornVernee: Thanks! I've merged in your changes. TestArrayStructs is not yet completely working. I will need to investigate. I think I've done most other things you had requested. You may want to take a look at my recent commits.

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From stefank at openjdk.org  Thu Mar  9 18:04:40 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 9 Mar 2023 18:04:40 GMT
Subject: RFR: 8303900: Rename BitMap search functions
In-Reply-To: <g09LwD0eFfQb6kIVSi0KAez9RTpnhO91I3QZvpM_Rpc=.bfa7b6fb-c552-4a9d-8e28-c41251e4f2e7@github.com>
References: <g09LwD0eFfQb6kIVSi0KAez9RTpnhO91I3QZvpM_Rpc=.bfa7b6fb-c552-4a9d-8e28-c41251e4f2e7@github.com>
Message-ID: <4GIB9OwfDN2SPR-vA9cUIN2eNhWjqxV47tBLlsoEWuM=.278dc6e2-93f6-438d-8938-8bf0f35c5599@github.com>

On Thu, 9 Mar 2023 15:34:05 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this renaming of the following functions in BitMap:
> 
> get_next_one_offset => find_first_set_bit
> get_next_zero_offset => find_first_clear_bit
> get_next_one_offset_aligned_right => find_first_set_bit_aligned_right
> 
> Note that ShenandoahMarkBitMap::get_next_one_offset is not being renamed.  For
> some reason that class contains a copy of a sizable chunk of the code from
> some version of BitMap.  (Not sure why it doesn't use an internal BitMapView
> rather than code copying.)
> 
> Testing:
> mach5 tier1-5

Looks good.

-------------

Marked as reviewed by stefank (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12951

From kvn at openjdk.org  Thu Mar  9 18:09:08 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 9 Mar 2023 18:09:08 GMT
Subject: RFR: JDK-8300783: Consolidate byteswap implementations [v8]
In-Reply-To: <XN9WbwkPShg_FCuesZ5vg4qkI-4J0tJA80Iz753HtWo=.e3c8cc91-6329-4aba-b038-d5d7b81c8661@github.com>
References: <MLBMwI7xt4IKgpb3AHXJ_J11Ibhijp_q2RFtLJOwHpA=.b7da6b6b-69b8-426d-8eab-c7c3aaa0847e@github.com>
 <v9HNX5mxr8cyTkf-Go6M62giQnF2ltlOnX36VwxfAn4=.3e2b489f-0dbb-4f7b-a685-9a32748847b2@github.com>
 <4T6ba7HVAkPmaau2WD3FRRyOlmEz7MDX5nz2UM-rfms=.58f59fc2-6030-4d9f-914f-5f37df4fb95e@github.com>
 <XN9WbwkPShg_FCuesZ5vg4qkI-4J0tJA80Iz753HtWo=.e3c8cc91-6329-4aba-b038-d5d7b81c8661@github.com>
Message-ID: <hm0Yfpt-M5nluHD-3Wq3Wlrpl1_yeL55cDrkbME9Vb4=.3ead1a07-5361-4695-957f-32a99f22fa7a@github.com>

On Mon, 6 Mar 2023 16:27:26 GMT, Justin King <jcking at openjdk.org> wrote:

>> CI run was fine wrt these changes.
>
> @dholmes-ora Poke. :)

@jcking, as Committer, you can integrate it now.

-------------

PR: https://git.openjdk.org/jdk/pull/12114

From dcubed at openjdk.org  Thu Mar  9 18:54:49 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 9 Mar 2023 18:54:49 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v5]
In-Reply-To: <-ImSJ7DFBeTtKn-R9IJcFE8wreHtVHYxWBv743xPa8s=.6ced1034-d7e1-4e23-a53d-81cbda44361a@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <yD60Z70ZlWrGez5qoqG6x7UXpuMkZgQfSQ1vwBxf2ag=.6c24675e-a3cc-423c-9864-b27f25e83a3c@github.com>
 <l-eqEujWmz1VulpaN1wdmja5Bx_9GtzGeDLvPTG5yd0=.1a1243bf-d69b-440c-acb2-f37cf04c923b@github.com>
 <-ImSJ7DFBeTtKn-R9IJcFE8wreHtVHYxWBv743xPa8s=.6ced1034-d7e1-4e23-a53d-81cbda44361a@github.com>
Message-ID: <YBG7enrhr8fXq7eyMTnWVSm8YnJpokzuVbB4BBHc1pE=.9579b9aa-164a-44e2-9bc8-533c49d42110@github.com>

On Mon, 30 Jan 2023 14:30:41 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> src/hotspot/share/runtime/synchronizer.cpp line 1336:
>> 
>>> 1334:         // Success! Return inflated monitor.
>>> 1335:         if (own) {
>>> 1336:           assert(current->is_Java_thread(), "must be: checked in is_lock_owned()");
>> 
>> `is_lock_owned()` currently does this:
>> 
>> 
>> static bool is_lock_owned(Thread* thread, oop obj) {
>>   assert(UseFastLocking, "only call this with fast-locking enabled");
>>   return thread->is_Java_thread() ? reinterpret_cast<JavaThread*>(thread)->lock_stack().contains(obj) : false;
>> }
>> 
>> 
>> so I would not say "checked in is_locked_owned()" since `is_locked_owned()` does
>> not enforce that the caller is a JavaThread.
>
> If it's not a Java thread, `is_lock_owned()` returns `false`, and we wouldn't end up in the `if (own)` branch.

Okay, I get it. `is_lock_owned()` only return `true` when called by a
JavaThread and if that JavaThread owns the monitor.

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From sviswanathan at openjdk.org  Thu Mar  9 18:55:57 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 9 Mar 2023 18:55:57 GMT
Subject: RFR: 8302191: Performance degradation for float/double modulo on
 Linux [v11]
In-Reply-To: <l8C8ei0a9cA9Z8q8Eppac-akguhejxvLI4F5C5ellUQ=.6fc61dd7-c5b4-486b-a4d1-6b06d87485c5@github.com>
References: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
 <l8C8ei0a9cA9Z8q8Eppac-akguhejxvLI4F5C5ellUQ=.6fc61dd7-c5b4-486b-a4d1-6b06d87485c5@github.com>
Message-ID: <C6Xad152PsrKXqWRCqx4LjF_DsIrEtDlqykV_6HTwZ8=.d9e7b906-aebe-401c-84c7-bb2f286db890@github.com>

On Tue, 7 Mar 2023 08:51:53 GMT, Jan Kratochvil <duke at openjdk.org> wrote:

>> I have OCA already processed/approved. I am not Author but my Author request is being processed these days (sent to Rob McKenna).
>> I did regression test x86_64 OpenJDK-8. I will leave other regression testing on GHA.
>> The patch (and former GCC performance regression) affects only x86_64+i686.
>
> Jan Kratochvil 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 11 additional commits since the last revision:
> 
>  - Fix #endif comment - found by dholmes-ora.
>  - Merge branch 'master' into modulo
>  - Fix win32 broken build.
>  - Merge remote-tracking branch 'origin/master' into modulo
>  - Always include the _WIN64 workaround - a review by dholmes-ora.
>  - Remove comments to be moved to JBS (Bug System) - a review by jddarcy.
>  - Uppercase L - a review by turbanoff.
>  - Fix copyright author.
>  - Fix WIN32 vs. WIN64.
>  - Update according to the upstream review by David Holmes.
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/285b0bd1...e4ff04dc

src/hotspot/share/runtime/sharedRuntime.cpp line 238:

> 236: #endif
> 237: 
> 238: #if !defined(TARGET_COMPILER_gcc) || defined(_WIN64)

The aarch64 and other builds are now broken with missing SharedRuntime::frem and SharedRuntime::drem.

-------------

PR: https://git.openjdk.org/jdk/pull/12508

From dcubed at openjdk.org  Thu Mar  9 19:00:56 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 9 Mar 2023 19:00:56 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v15]
In-Reply-To: <YeXYnGbHymtoOe9eQToM1djB-pJtLWgMoCLxzAyT4vs=.cf42449e-aa0d-4f41-91c1-6066905eee43@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <YeXYnGbHymtoOe9eQToM1djB-pJtLWgMoCLxzAyT4vs=.cf42449e-aa0d-4f41-91c1-6066905eee43@github.com>
Message-ID: <RJP3Y3TovbhA0_PrNxT_qRYGwor4PUpeLxNTjzzI9SE=.5747dbb1-6139-4811-bd42-301f14d88eae@github.com>

On Wed, 8 Mar 2023 18:25:15 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>  - Inline initial LockStack stack

This project is still currently baselined on jdk-21+10-761.

I was expecting this merge:
[Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2](https://github.com/openjdk/jdk/pull/10907/commits/3c9d0d822fc15a196c4b8920b89ad6d3d0547101)
to sync in the latest main baseline bits, but apparently not.

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From pchilanomate at openjdk.org  Thu Mar  9 19:19:24 2023
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 9 Mar 2023 19:19:24 GMT
Subject: RFR: 8303908: Add missing check in VTMS_transition_disable_for_all()
 for suspend mode
Message-ID: <MW-CIeSI8D3Opes0-cjiBHbvBuuUfKxhrZoEpRPylCg=.19babd2e-b3c6-48f7-a6ab-7d38f3211507@github.com>

Please review this small fix. A suspender is a JvmtiVTMSTransitionDisabler monopolist, meaning VTMS_transition_disable_for_all() should not return while there is any active jvmtiVTMSTransitionDisabler. The code though is checking for active "all-disablers" but it's missing the check for active "single disablers".
I attached a simple reproducer to the bug which I used to test the patch. Not sure if it was worth adding a test so the patch contains just the fix.

Thanks,
Patricio

-------------

Commit messages:
 - v1

Changes: https://git.openjdk.org/jdk/pull/12956/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12956&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303908
  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12956.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12956/head:pull/12956

PR: https://git.openjdk.org/jdk/pull/12956

From fparain at openjdk.org  Thu Mar  9 19:27:32 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 9 Mar 2023 19:27:32 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry
In-Reply-To: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
Message-ID: <89PNDhKGJttxXQg3Izv3dvSM33KewEekz4kmwVUjQXo=.d7fc365c-9783-4e5a-ac04-ba770a51c43c@github.com>

On Mon, 27 Feb 2023 21:37:34 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
> 
> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
> 
> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
> 
> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
> 
> This change supports the following platforms: x86, aarch64, PPC, and RISCV

src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1844:

> 1842:   // Scale the index to be the entry index * sizeof(ResolvedInvokeDynamicInfo)
> 1843:   mov(tmp, sizeof(ResolvedIndyEntry));
> 1844:   mul(index, index, tmp);

On 64bits platform, sizeof(ResolvedIndyEntry) is 16, a power of two, so shift instruction could be used instead of a multiply instructions (with an assert in case the size of ResolvedIndyEntry is changed).

src/hotspot/cpu/x86/interp_masm_x86.cpp line 2075:

> 2073:   movptr(cache, Address(rbp, frame::interpreter_frame_cache_offset * wordSize));
> 2074:   movptr(cache, Address(cache, in_bytes(ConstantPoolCache::invokedynamic_entries_offset())));
> 2075:   imull(index, index, sizeof(ResolvedIndyEntry)); // Scale the index to be the entry index * sizeof(ResolvedInvokeDynamicInfo)

A shift instruction could be used when sizeof(ResolvedIndyEntry) is a power of two. It is on x86_64 platforms but not on x86_32 platforms (both are using this file).
Suggested change:
  if (is_power_of_2(sizeof(ResolvedIndyEntry))) {
    shll(index, log2i(sizeof(ResolvedIndyEntry)));
  } else {
    imull(index, index, sizeof(ResolvedIndyEntry)); // Scale the index to be the entry index * sizeof(ResolvedInvokeDynamicInfo)
  }

src/hotspot/cpu/x86/templateTable_x86.cpp line 2747:

> 2745:   address entry = CAST_FROM_FN_PTR(address, InterpreterRuntime::resolve_from_cache);
> 2746:   __ movl(method, code); // this is essentially Bytecodes::_invokedynamic
> 2747:   __ call_VM(noreg, entry, method); // Example uses temp = rbx. In this case rbx is method

The comment is confusing and seems to need an update. The register 'method' is used, but its content is not the method anymore, it is the bytecode.

src/hotspot/cpu/x86/templateTable_x86.cpp line 2770:

> 2768:   // since the parameter_size includes it.
> 2769:   __ push(rbx);
> 2770:   __ mov(rbx, index);

Why is the index (rdx) copied to rbx instead of using the index (rdx) register directly to call load_resolved_reference_at_index() ? The method doesn't modify the content of the register.

src/hotspot/share/interpreter/bootstrapInfo.cpp line 67:

> 65:   assert(_indy_index != -1, "");
> 66:   // Check if method is not null
> 67:   if ( _pool->resolved_indy_entry_at(_indy_index)->method() != nullptr) {

_pool->resolved_reference_from_indy(_indy_index) is repeated 5 times. Using a local variable would make the code easier to read.

-------------

PR: https://git.openjdk.org/jdk/pull/12778

From jcking at openjdk.org  Thu Mar  9 19:42:37 2023
From: jcking at openjdk.org (Justin King)
Date: Thu, 9 Mar 2023 19:42:37 GMT
Subject: Integrated: JDK-8300783: Consolidate byteswap implementations
In-Reply-To: <MLBMwI7xt4IKgpb3AHXJ_J11Ibhijp_q2RFtLJOwHpA=.b7da6b6b-69b8-426d-8eab-c7c3aaa0847e@github.com>
References: <MLBMwI7xt4IKgpb3AHXJ_J11Ibhijp_q2RFtLJOwHpA=.b7da6b6b-69b8-426d-8eab-c7c3aaa0847e@github.com>
Message-ID: <24UOZ9Bl9l7k6FwS4HXol82TdrCcf2XkGTSnPKy3Q0Q=.301ce9ec-3f43-4356-a8e2-621a60422b76@github.com>

On Fri, 20 Jan 2023 14:55:40 GMT, Justin King <jcking at openjdk.org> wrote:

> Deduplicate byte swapping implementations by consolidating them into `utilities/byteswap.hpp`, following `std::byteswap` introduced in C++23. Further simplification of `Bytes` will follow in https://github.com/openjdk/jdk/pull/12078.

This pull request has now been integrated.

Changeset: a9dba565
Author:    Justin King <jcking at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a9dba565688a29bef8626488c47519008dcadbe8
Stats:     1561 lines in 31 files changed: 507 ins; 1023 del; 31 mod

8300783: Consolidate byteswap implementations

Reviewed-by: kbarrett, kvn

-------------

PR: https://git.openjdk.org/jdk/pull/12114

From kbarrett at openjdk.org  Thu Mar  9 20:17:20 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 9 Mar 2023 20:17:20 GMT
Subject: RFR: 8303810: Restore attribute positions after JDK-8303839 to
 match JDK-8302124 [v3]
In-Reply-To: <iii6piYafXSVnOrWTyqY6HivGhSd4Mvtg5SKcpC5icQ=.153e1f72-8986-42f9-8af5-025cfd40b76d@github.com>
References: <J6UWvKQHQtTqoqh5udTU6RNg7XkhSrC6D73O61sgW5M=.9bed1df4-c1be-47ac-81b0-e2c0ba3f3e58@github.com>
 <iii6piYafXSVnOrWTyqY6HivGhSd4Mvtg5SKcpC5icQ=.153e1f72-8986-42f9-8af5-025cfd40b76d@github.com>
Message-ID: <8Ohq_fYWdoYmD7bvYKKFgIbc8L0SkFE5U22q9t2ylmE=.948ef550-ba01-4eb7-8b3d-3cd8a45cf4ae@github.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
On Thu, 9 Mar 2023 11:54:44 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> [JDK-8303839](https://bugs.openjdk.org/browse/JDK-8303839)'s revert of [[noreturn]] attributes also moved their already existing attributes back to behind their corresponding methods, they should be restored to where [JDK-8302124](https://bugs.openjdk.org/browse/JDK-8302124) requires them to be. Also fixes attribute from [JDK-8292269](https://bugs.openjdk.org/browse/JDK-8292269)
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   debug.hpp

Please don't do this.  This change will just make the redo harder by introducing merge conflicts.

-------------

PR: https://git.openjdk.org/jdk/pull/12918

From kbarrett at openjdk.org  Thu Mar  9 20:24:16 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 9 Mar 2023 20:24:16 GMT
Subject: RFR: 8274400: HotSpot Style Guide should permit use of alignof
 [v7]
In-Reply-To: <VVJXCkqPxaRJdnYzpQnA-8e3xbhTaVY31JGeEAvPEnU=.5d7c0cbe-23a5-4278-b7bf-71185bdce610@github.com>
References: <3IdeZGaGcFB1-DbVugn0P9v8vRQMLURzHFRSpAm46NA=.09bf4dd8-b652-49c3-b9a5-ad3f58dfbcc3@github.com>
 <ftmYL9ARvHkRRD0hHspM75ttcSUm7jSBhzTJ4D0SRF0=.6f071ce4-30f4-4ad3-987a-ecfe0c242226@github.com>
 <xkZdJ9JhuDi3rL5k3-eTbI58ALs3Srzgzz6E5wJUkJY=.cec251e2-06dc-4e42-ae6c-68d18081ba68@github.com>
 <VVJXCkqPxaRJdnYzpQnA-8e3xbhTaVY31JGeEAvPEnU=.5d7c0cbe-23a5-4278-b7bf-71185bdce610@github.com>
Message-ID: <MLS7e4TbsXZl7RhPNDovTRzpP0BEJ0mPs2hpN0yhXlM=.2842d370-0fbc-49a6-a44b-ecfe868ea182@github.com>

On Mon, 27 Feb 2023 13:02:02 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> This has been open and stable for a while.  Anyone else?
>
>> This has been open and stable for a while. Anyone else?
> 
> Also if there is anyone else coming to review this, consider looking at https://github.com/openjdk/jdk/pull/11431 as well, it's also been collecting dust for quite a while too ;-;

@TheShermanTanker - this is ready to be integrated, as it has been approved by @vnkozlov (HotSpot lead).

-------------

PR: https://git.openjdk.org/jdk/pull/11761

From kbarrett at openjdk.org  Thu Mar  9 20:27:42 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 9 Mar 2023 20:27:42 GMT
Subject: RFR: JDK-8303817: Add constexpr for natural malloc alignment
In-Reply-To: <aWWx5bYpLxs3YLXaQCpyFay9k0USruBs6W2_qDUGCNE=.228b1fc3-9546-4ff8-b9af-94b9146b88d8@github.com>
References: <aWWx5bYpLxs3YLXaQCpyFay9k0USruBs6W2_qDUGCNE=.228b1fc3-9546-4ff8-b9af-94b9146b88d8@github.com>
Message-ID: <Mx0cxK-RGu5I0i4fBO-KA-iUNSWeUMEIP5jSqo-A4ag=.9a3eaec5-41d9-47f2-8677-72b28af24919@github.com>

On Wed, 8 Mar 2023 11:23:53 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> I miss having an easy way to get the alignment the libc guarantees for malloc. Let's add this, and we can use this right away with NMT's MallocHeader.
> 
> Tests: manually built and tested x64 linux (clang + GCC) and x86 linux.

src/hotspot/share/utilities/globalDefinitions.hpp line 1313:

> 1311:   long double d;
> 1312: };
> 1313: constexpr int minimum_malloc_alignment = alignof(AllTheBigTypes);

How is this different from `alignof(std::max_align_t)`?  (Which we can use - JDK-8274400 (approved, just noticed author hasn't integrated yet) and JDK-8297912.)

-------------

PR: https://git.openjdk.org/jdk/pull/12921

From coleenp at openjdk.org  Thu Mar  9 20:43:09 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 9 Mar 2023 20:43:09 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry
In-Reply-To: <t28c8qyAbO9uZ4Q2be18QY6mmuWkf5MnNdtz_2Vlggw=.6115ce3b-f5c9-4d86-8130-33e6b606bf56@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <LQTG-IYnef9srlK41aw_InVGTvihfRW2ez8deMPILoY=.efc03d45-0f5c-4d81-8c23-310c54969c07@github.com>
 <A_IUIYIKAh5BxaCSeoW_3afjPBsfh641ahYI-HfSwJ4=.ed14415f-4bcd-4d62-8cf6-e1d254839397@github.com>
 <XcgkoKgIiEG7ZF0_EH-8mD1MR-6j4xTTRFIFDSH7gg0=.6af759b8-223d-4fa2-a425-967857687a1e@github.com>
 <0TIZDGiEpwyU6vRDvWCTiQBoyekNHwa5QoJr4ViPh0U=.7a45b939-ce28-4936-871b-dfc4c0b3a5ec@github.com>
 <t28c8qyAbO9uZ4Q2be18QY6mmuWkf5MnNdtz_2Vlggw=.6115ce3b-f5c9-4d86-8130-33e6b606bf56@github.com>
Message-ID: <xCa1TXetNDC-RdfhsXtL_O8yCxvye05IanzQBbe2NnQ=.727428b2-e73a-4ad8-8f3c-047c127aa8f6@github.com>

On Thu, 9 Mar 2023 16:44:21 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> This looks cool.
>
>> This change should be in a further RFE though (and you can explain it there so we can maybe use it in the other platforms too).
> 
> Ok.
> 
>> Does it affect performance when generating the template interpreter?
> 
> I didn't think it would affect performance if the interpreter is not printed. I have not measured it though.
> 
>> Do you need to have hsdis in the LD_LIBRARY_PATH environment variable to use this? I see it's already used by default in one place.
> 
> Yes you do. It is not working with the AbstractDisassembler which produces a hex dump of the machine code.

I was searching in the wrong directory, which is why I didn't find this and apparently I reviewed this change in 2018.  We can leave this change here.  Sorry for the noise.

-------------

PR: https://git.openjdk.org/jdk/pull/12778

From fparain at openjdk.org  Thu Mar  9 20:51:38 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 9 Mar 2023 20:51:38 GMT
Subject: RFR: 8292818: replace 96-bit representation for field metadata
 with variable-sized streams
In-Reply-To: <duJxLMpZeS9KBS839JUNLQPb7u7cBzbFxk4CcmZGdoc=.4704e44a-2680-44e3-93c0-33bb575e9f28@github.com>
References: <vdiacOO3JUyy4sWGkDXNBMUT7cG3XYe79mOvYru9uMM=.9c556675-7ffd-4c09-a428-6d64dffef209@github.com>
 <duJxLMpZeS9KBS839JUNLQPb7u7cBzbFxk4CcmZGdoc=.4704e44a-2680-44e3-93c0-33bb575e9f28@github.com>
Message-ID: <ADBnYiuSVseJNe6EeCnBwJQksyGM5Clvs5TV3BfNm78=.a15ee148-2fc4-4ab6-8766-17bc4e782222@github.com>

On Wed, 8 Mar 2023 15:46:12 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change re-implementing the FieldInfo data structure.
>> 
>> The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency.
>> 
>> The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information).
>> 
>> More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818
>> 
>> Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM.
>> 
>> The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format.
>> 
>> Tested with mach5, tier 1 to 7.
>> 
>> Thank you.
>
> src/hotspot/share/classfile/classFileParser.cpp line 1491:
> 
>> 1489:   _temp_field_info = new GrowableArray<FieldInfo>(total_fields);
>> 1490: 
>> 1491:   ResourceMark rm(THREAD);
> 
> Is the ResourceMark ok here or should it go before allocating _temp_field_info ?

_temp_field_info must survive after ClassFileParser::parse_fields() has returned, so definitively after the allocation of _temp_field_info. That being said, I don't see any reason to have a ResourceMark here, probably a remain of some debugging/tracing code. I'll remove it.

-------------

PR: https://git.openjdk.org/jdk/pull/12855

From stuefe at openjdk.org  Thu Mar  9 20:52:29 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 9 Mar 2023 20:52:29 GMT
Subject: RFR: JDK-8303817: Add constexpr for natural malloc alignment
In-Reply-To: <aWWx5bYpLxs3YLXaQCpyFay9k0USruBs6W2_qDUGCNE=.228b1fc3-9546-4ff8-b9af-94b9146b88d8@github.com>
References: <aWWx5bYpLxs3YLXaQCpyFay9k0USruBs6W2_qDUGCNE=.228b1fc3-9546-4ff8-b9af-94b9146b88d8@github.com>
Message-ID: <3487w225FRkI0CtznUs0ihccA9XUZgjZoURy8y3DA0M=.a947cc34-066c-49ca-bfa5-a5819c0c5100@github.com>

On Wed, 8 Mar 2023 11:23:53 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> I miss having an easy way to get the alignment the libc guarantees for malloc. Let's add this, and we can use this right away with NMT's MallocHeader.
> 
> Tests: manually built and tested x64 linux (clang + GCC) and x86 linux.

Did not realize that std::max_align_t was an option. Sure, I do that.

-------------

PR: https://git.openjdk.org/jdk/pull/12921

From stuefe at openjdk.org  Thu Mar  9 20:52:31 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 9 Mar 2023 20:52:31 GMT
Subject: Withdrawn: JDK-8303817: Add constexpr for natural malloc alignment
In-Reply-To: <aWWx5bYpLxs3YLXaQCpyFay9k0USruBs6W2_qDUGCNE=.228b1fc3-9546-4ff8-b9af-94b9146b88d8@github.com>
References: <aWWx5bYpLxs3YLXaQCpyFay9k0USruBs6W2_qDUGCNE=.228b1fc3-9546-4ff8-b9af-94b9146b88d8@github.com>
Message-ID: <GQVsiPtAGkMFVSMnsuHcqCTlX30cb7fW6_TuxKCD_E4=.4464bc39-926f-4223-bdf6-c68ddb2e49b1@github.com>

On Wed, 8 Mar 2023 11:23:53 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> I miss having an easy way to get the alignment the libc guarantees for malloc. Let's add this, and we can use this right away with NMT's MallocHeader.
> 
> Tests: manually built and tested x64 linux (clang + GCC) and x86 linux.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/12921

From fparain at openjdk.org  Thu Mar  9 21:02:05 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 9 Mar 2023 21:02:05 GMT
Subject: RFR: 8292818: replace 96-bit representation for field metadata
 with variable-sized streams
In-Reply-To: <duJxLMpZeS9KBS839JUNLQPb7u7cBzbFxk4CcmZGdoc=.4704e44a-2680-44e3-93c0-33bb575e9f28@github.com>
References: <vdiacOO3JUyy4sWGkDXNBMUT7cG3XYe79mOvYru9uMM=.9c556675-7ffd-4c09-a428-6d64dffef209@github.com>
 <duJxLMpZeS9KBS839JUNLQPb7u7cBzbFxk4CcmZGdoc=.4704e44a-2680-44e3-93c0-33bb575e9f28@github.com>
Message-ID: <wNCJrFhuZKTPQhjUawsZ9Cw_wIa7a7j1HXb9M1ldNT8=.7093c2d1-2686-4ef8-a769-5a95526f44b1@github.com>

On Wed, 8 Mar 2023 15:50:05 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change re-implementing the FieldInfo data structure.
>> 
>> The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency.
>> 
>> The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information).
>> 
>> More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818
>> 
>> Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM.
>> 
>> The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format.
>> 
>> Tested with mach5, tier 1 to 7.
>> 
>> Thank you.
>
> src/hotspot/share/classfile/classFileParser.cpp line 1608:
> 
>> 1606:       fflags.update_injected(true);
>> 1607:       AccessFlags aflags;
>> 1608:       FieldInfo fi(aflags, (u2)(injected[n].name_index), (u2)(injected[n].signature_index), 0, fflags);
> 
> I don't know why there's a cast here until I read more.  If the FieldInfo name_index and signature_index fields are only u2 sized, could you pass this as an int and then in the constructor assert that the value doesn't overflow u2 instead?

The type of name_index and signature_index is const vmSymbolID, because they names and signatures of injected fields do not come from a constant pool, but from the vmSymbol array.

-------------

PR: https://git.openjdk.org/jdk/pull/12855

From rkennke at openjdk.org  Thu Mar  9 21:08:16 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 9 Mar 2023 21:08:16 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v16]
In-Reply-To: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
Message-ID: <yTDSrIOevRirBhSbxLUMw22pA0sBhTqrCJpx8_EhCwg=.884bd21b-2a13-4522-88ea-a24054346c7a@github.com>

> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
> 
> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p
 rotocols.
> 
> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
> 
> 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
> 
> 
> Testing:
>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
> 
> ### Performance
> 
> #### Simple Microbenchmark
> 
> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
> 
> |  | x86_64 | aarch64 |
> | -- | -- | -- |
> | -UseFastLocking | 20.651 | 20.764 |
> | +UseFastLocking | 18.896 | 18.908 |
> 
> 
> #### Renaissance
> 
> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
> -- | -- | -- | -- | -- | -- | -- | --
> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%

Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 99 commits:

 - Merge branch 'master' into JDK-8291555-v2
 - Various small fixes and improvements
 - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
 - Use realloc instead of malloc+copy when growing the lock-stack
 - Inline initial LockStack stack
 - Fix interpreter asymmetric fast-locking
 - Fix merge error (move done label into correct places)
 - Merge branch 'master' into JDK-8291555-v2
 - Small fixes
 - Fix anon owner in fast-path, avoid runtime call (aarch64)
 - ... and 89 more: https://git.openjdk.org/jdk/compare/5726d31e...f9f93b36

-------------

Changes: https://git.openjdk.org/jdk/pull/10907/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=15
  Stats: 2090 lines in 74 files changed: 1327 ins; 94 del; 669 mod
  Patch: https://git.openjdk.org/jdk/pull/10907.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10907/head:pull/10907

PR: https://git.openjdk.org/jdk/pull/10907

From fparain at openjdk.org  Thu Mar  9 21:12:11 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 9 Mar 2023 21:12:11 GMT
Subject: RFR: 8292818: replace 96-bit representation for field metadata
 with variable-sized streams
In-Reply-To: <duJxLMpZeS9KBS839JUNLQPb7u7cBzbFxk4CcmZGdoc=.4704e44a-2680-44e3-93c0-33bb575e9f28@github.com>
References: <vdiacOO3JUyy4sWGkDXNBMUT7cG3XYe79mOvYru9uMM=.9c556675-7ffd-4c09-a428-6d64dffef209@github.com>
 <duJxLMpZeS9KBS839JUNLQPb7u7cBzbFxk4CcmZGdoc=.4704e44a-2680-44e3-93c0-33bb575e9f28@github.com>
Message-ID: <0Ayok_tvKtFDl6deMwvAIUcT8MFkA8fIXSCHqwXKYts=.2cf55fae-34ae-4ce3-b733-b32df0acaf45@github.com>

On Wed, 8 Mar 2023 16:05:57 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change re-implementing the FieldInfo data structure.
>> 
>> The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency.
>> 
>> The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information).
>> 
>> More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818
>> 
>> Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM.
>> 
>> The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format.
>> 
>> Tested with mach5, tier 1 to 7.
>> 
>> Thank you.
>
> src/hotspot/share/classfile/fieldLayoutBuilder.cpp line 554:
> 
>> 552:     FieldInfo ctrl = _field_info->at(0);
>> 553:     FieldGroup* group = nullptr;
>> 554:     FieldInfo tfi = *it;
> 
> What's the 't' in tfi?  Maybe a longer variable name would be helpful here.

At some point there was a TempFieldInfo type, hence the name.
Renamed to fieldinfo.

> src/hotspot/share/classfile/javaClasses.cpp line 871:
> 
>> 869:       // a new UNSIGNED5 stream, and substitute it to the old FieldInfo stream.
>> 870: 
>> 871:       int java_fields;
> 
> Can you put InstanceKlass* ik = InstanceKlass::cast(k); here and use that so there's only one cast?

Sure, done.

-------------

PR: https://git.openjdk.org/jdk/pull/12855

From matsaave at openjdk.org  Thu Mar  9 21:18:19 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 9 Mar 2023 21:18:19 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v2]
In-Reply-To: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
Message-ID: <-Kj1YJ_nRa4nJtaxg3UR8uWhde6vIG1Jl-FFakGnHy4=.a41c6149-912b-4a66-8b1e-634bd27cdebb@github.com>

> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
> 
> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
> 
> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
> 
> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
> 
> This change supports the following platforms: x86, aarch64, PPC, and RISCV

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  Interpreter optimization and comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12778/files
  - new: https://git.openjdk.org/jdk/pull/12778/files/829517d6..c2d87e59

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12778&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12778&range=00-01

  Stats: 47 lines in 10 files changed: 11 ins; 13 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/12778.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12778/head:pull/12778

PR: https://git.openjdk.org/jdk/pull/12778

From dcubed at openjdk.org  Thu Mar  9 21:45:12 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 9 Mar 2023 21:45:12 GMT
Subject: RFR: 8274400: HotSpot Style Guide should permit use of alignof
 [v7]
In-Reply-To: <ftmYL9ARvHkRRD0hHspM75ttcSUm7jSBhzTJ4D0SRF0=.6f071ce4-30f4-4ad3-987a-ecfe0c242226@github.com>
References: <3IdeZGaGcFB1-DbVugn0P9v8vRQMLURzHFRSpAm46NA=.09bf4dd8-b652-49c3-b9a5-ad3f58dfbcc3@github.com>
 <ftmYL9ARvHkRRD0hHspM75ttcSUm7jSBhzTJ4D0SRF0=.6f071ce4-30f4-4ad3-987a-ecfe0c242226@github.com>
Message-ID: <PUJTyVurhs7I1_MLcP5s4hUl0xGlcIBKuFT7iBb_qWs=.d646bcf8-700d-41a6-924f-11f0b8fa74bb@github.com>

On Tue, 24 Jan 2023 09:21:37 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 incrementally with one additional commit since the last revision:
> 
>   Oof

Marked as reviewed by dcubed (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11761

From dcubed at openjdk.org  Thu Mar  9 22:02:41 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 9 Mar 2023 22:02:41 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v16]
In-Reply-To: <yTDSrIOevRirBhSbxLUMw22pA0sBhTqrCJpx8_EhCwg=.884bd21b-2a13-4522-88ea-a24054346c7a@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <yTDSrIOevRirBhSbxLUMw22pA0sBhTqrCJpx8_EhCwg=.884bd21b-2a13-4522-88ea-a24054346c7a@github.com>
Message-ID: <R0zRFlFepxjzr58RJ0SeIZa1lKUNIxQZ6mdTkcqjqEQ=.9a8b9495-e133-4d5f-942d-483725c94f81@github.com>

On Thu, 9 Mar 2023 21:08:16 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 99 commits:
> 
>  - Merge branch 'master' into JDK-8291555-v2
>  - Various small fixes and improvements
>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>  - Use realloc instead of malloc+copy when growing the lock-stack
>  - Inline initial LockStack stack
>  - Fix interpreter asymmetric fast-locking
>  - Fix merge error (move done label into correct places)
>  - Merge branch 'master' into JDK-8291555-v2
>  - Small fixes
>  - Fix anon owner in fast-path, avoid runtime call (aarch64)
>  - ... and 89 more: https://git.openjdk.org/jdk/compare/5726d31e...f9f93b36

This project is currently based on jdk-21+14-1079.

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From sspitsyn at openjdk.org  Thu Mar  9 22:27:11 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 9 Mar 2023 22:27:11 GMT
Subject: RFR: 8302779: HelidonAppTest.java fails with
 "assert(_cb == CodeCache::find_blob(pc())) failed: Must be the same" or
 SIGSEGV
In-Reply-To: <ZsPtiMn1PiOTGUiSC7GXZ196v4a7YFL5LRioo2ZCFdU=.148f395d-f892-4829-8f08-69ce7134b865@github.com>
References: <ZsPtiMn1PiOTGUiSC7GXZ196v4a7YFL5LRioo2ZCFdU=.148f395d-f892-4829-8f08-69ce7134b865@github.com>
Message-ID: <9TvBQ8ScbPmz7uMFo8fWYly239z03-tYBsNWV1N0s4A=.344c11c7-c375-4e75-a4b2-7ed1592971bc@github.com>

On Tue, 7 Mar 2023 22:14:39 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review the following fix. The Method instance representing Continuation.enterSpecial() is replaced by a new Method during redefinition of the Continuation class. The already existing nmethod for it is not used, but a new one will be generated the first time enterSpecial() is resolved after redefinition. This means we could have more than one nmethod representing enterSpecial(), in particular, one generated before redefinition took place, and one after it. Now, when walking the stack, if we found a return barrier pc (as in Continuation::is_return_barrier_entry()) and we want to keep walking the physical stack then we know the sender will be the enterSpecial frame so we create it by calling ContinuationEntry::to_frame(). This method assumes there can only be one nmethod associated with enterSpecial() so we hit an assert later on. See the bug for more details of the crash.
> 
> As I mentioned in the bug we don't need to rely on this assumption since we can re-read the updated value from _enter_special. But reading both _enter_special and _return_pc means we would need some kind of synchronization since to_frame() could be called concurrently with set_enter_code(). To avoid that we could just read _return_pc and calculate the blob from it each time, but I'm also assuming that overhead is undesired and that's why the static variable was introduced. Alternatively _enter_special could be read and _return_pc could be derived from it (by adding an extra field in the nmethod class). But if we go this route I think we would need to do a small fix on thaw too. After redefinition and before a new call to resolve enterSpecial(), the last thaw call for some virtual thread would create an entry frame with an old _return_pc (see ThawBase::new_entry_frame() and ThawBase::patch_return()). I'm not sure about the lifecycle of the old CodeBlob but it seems it could have bee
 n already removed if enterSpecial was not found while traversing everybody's stack. Maybe there are more issues.
> 
> The simple solution implemented here is just to disallow redefinition of the Continuation class altogether. Another less restrictive option would be to keep the already generated enterSpecial nmethod, if there is one. I can also investigate one of the routes mentioned previously if desired.
> 
> I tested the fix with the simple reproducer I added to the bug and also with the previously crashing HelidonAppTest.java test.
> 
> Thanks,
> Patricio

Looks good.
Thank you for taking care about it!
Serguei,
Thanks

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12911

From pchilanomate at openjdk.org  Thu Mar  9 22:38:10 2023
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 9 Mar 2023 22:38:10 GMT
Subject: RFR: 8302779: HelidonAppTest.java fails with
 "assert(_cb == CodeCache::find_blob(pc())) failed: Must be the same" or
 SIGSEGV
In-Reply-To: <9TvBQ8ScbPmz7uMFo8fWYly239z03-tYBsNWV1N0s4A=.344c11c7-c375-4e75-a4b2-7ed1592971bc@github.com>
References: <ZsPtiMn1PiOTGUiSC7GXZ196v4a7YFL5LRioo2ZCFdU=.148f395d-f892-4829-8f08-69ce7134b865@github.com>
 <9TvBQ8ScbPmz7uMFo8fWYly239z03-tYBsNWV1N0s4A=.344c11c7-c375-4e75-a4b2-7ed1592971bc@github.com>
Message-ID: <vmjemYqsccCgW3cy5juBvuriJnrnZqxTXcDKmipYTRQ=.25225717-781c-4048-bf27-f79fdcecda97@github.com>

On Thu, 9 Mar 2023 22:24:00 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Looks good. Thank you for taking care about it! Serguei, Thanks
>
Thanks for the review Serguei!

-------------

PR: https://git.openjdk.org/jdk/pull/12911

From pchilanomate at openjdk.org  Thu Mar  9 22:57:22 2023
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 9 Mar 2023 22:57:22 GMT
Subject: Integrated: 8302779: HelidonAppTest.java fails with
 "assert(_cb == CodeCache::find_blob(pc())) failed: Must be the same" or
 SIGSEGV
In-Reply-To: <ZsPtiMn1PiOTGUiSC7GXZ196v4a7YFL5LRioo2ZCFdU=.148f395d-f892-4829-8f08-69ce7134b865@github.com>
References: <ZsPtiMn1PiOTGUiSC7GXZ196v4a7YFL5LRioo2ZCFdU=.148f395d-f892-4829-8f08-69ce7134b865@github.com>
Message-ID: <GPDj1whbZBMhB--e56IecjuiLzcT4KroXRLk799Ueho=.6c568f5e-587e-4966-80ee-802f38ef0332@github.com>

On Tue, 7 Mar 2023 22:14:39 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review the following fix. The Method instance representing Continuation.enterSpecial() is replaced by a new Method during redefinition of the Continuation class. The already existing nmethod for it is not used, but a new one will be generated the first time enterSpecial() is resolved after redefinition. This means we could have more than one nmethod representing enterSpecial(), in particular, one generated before redefinition took place, and one after it. Now, when walking the stack, if we found a return barrier pc (as in Continuation::is_return_barrier_entry()) and we want to keep walking the physical stack then we know the sender will be the enterSpecial frame so we create it by calling ContinuationEntry::to_frame(). This method assumes there can only be one nmethod associated with enterSpecial() so we hit an assert later on. See the bug for more details of the crash.
> 
> As I mentioned in the bug we don't need to rely on this assumption since we can re-read the updated value from _enter_special. But reading both _enter_special and _return_pc means we would need some kind of synchronization since to_frame() could be called concurrently with set_enter_code(). To avoid that we could just read _return_pc and calculate the blob from it each time, but I'm also assuming that overhead is undesired and that's why the static variable was introduced. Alternatively _enter_special could be read and _return_pc could be derived from it (by adding an extra field in the nmethod class). But if we go this route I think we would need to do a small fix on thaw too. After redefinition and before a new call to resolve enterSpecial(), the last thaw call for some virtual thread would create an entry frame with an old _return_pc (see ThawBase::new_entry_frame() and ThawBase::patch_return()). I'm not sure about the lifecycle of the old CodeBlob but it seems it could have bee
 n already removed if enterSpecial was not found while traversing everybody's stack. Maybe there are more issues.
> 
> The simple solution implemented here is just to disallow redefinition of the Continuation class altogether. Another less restrictive option would be to keep the already generated enterSpecial nmethod, if there is one. I can also investigate one of the routes mentioned previously if desired.
> 
> I tested the fix with the simple reproducer I added to the bug and also with the previously crashing HelidonAppTest.java test.
> 
> Thanks,
> Patricio

This pull request has now been integrated.

Changeset: 8b740b46
Author:    Patricio Chilano Mateo <pchilanomate at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8b740b46091c853c7cb66c361deda6dfbb2cedc8
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8302779: HelidonAppTest.java fails with "assert(_cb == CodeCache::find_blob(pc())) failed: Must be the same" or SIGSEGV

Reviewed-by: coleenp, sspitsyn

-------------

PR: https://git.openjdk.org/jdk/pull/12911

From inakonechnyy at openjdk.org  Thu Mar  9 23:12:00 2023
From: inakonechnyy at openjdk.org (Ilarion Nakonechnyy)
Date: Thu, 9 Mar 2023 23:12:00 GMT
Subject: RFR: 8302491: NoClassDefFoundError omits the original cause of an
 error [v7]
In-Reply-To: <L-pfBfK4TKl5KUWpPEcbs-IkhwimgJZ-SOrbSG3exeA=.5e883f22-de9b-4eec-9e98-8ee954a7996b@github.com>
References: <L-pfBfK4TKl5KUWpPEcbs-IkhwimgJZ-SOrbSG3exeA=.5e883f22-de9b-4eec-9e98-8ee954a7996b@github.com>
Message-ID: <MXlHYT8RkJEakZpD6aFFSFyOhK9-aSbCMRoycp9db14=.553419d4-f880-48bf-ae8b-e13e5aff6456@github.com>

> The proposed approach added a new function for getting the cause of an exception -`java_lang_Throwable::get_cause_simple `, that gets called within `InstanceKlass::add_initialization_error`  if an old one `java_lang_Throwable::get_cause_with_stack_trace` didn't succeed because of an exception during the VM call. The simple function doesn't call the VM for getting a stack trace but fills in any other information about an exception.
> 
> Besides that, the discovering information about an exception was added to `ConstantPoolCacheEntry::save_and_throw_indy_exc` function. 
> 
> Jtreg for reproducing the issue also was added to the commit. 
> The commit was tested with tier1 tests.

Ilarion Nakonechnyy has updated the pull request incrementally with one additional commit since the last revision:

  Some corrections

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12566/files
  - new: https://git.openjdk.org/jdk/pull/12566/files/bd4df11d..5e575962

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12566&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12566&range=05-06

  Stats: 7 lines in 2 files changed: 1 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12566.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12566/head:pull/12566

PR: https://git.openjdk.org/jdk/pull/12566

From dcubed at openjdk.org  Thu Mar  9 23:23:26 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 9 Mar 2023 23:23:26 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v16]
In-Reply-To: <yTDSrIOevRirBhSbxLUMw22pA0sBhTqrCJpx8_EhCwg=.884bd21b-2a13-4522-88ea-a24054346c7a@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <yTDSrIOevRirBhSbxLUMw22pA0sBhTqrCJpx8_EhCwg=.884bd21b-2a13-4522-88ea-a24054346c7a@github.com>
Message-ID: <vyETQzjqNYypGaZoxGT02WuzSreJyH7mMRLJyUFjPLA=.a210dec5-2a7f-4814-8014-021a9dcba4a5@github.com>

On Thu, 9 Mar 2023 21:08:16 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 99 commits:
> 
>  - Merge branch 'master' into JDK-8291555-v2
>  - Various small fixes and improvements
>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>  - Use realloc instead of malloc+copy when growing the lock-stack
>  - Inline initial LockStack stack
>  - Fix interpreter asymmetric fast-locking
>  - Fix merge error (move done label into correct places)
>  - Merge branch 'master' into JDK-8291555-v2
>  - Small fixes
>  - Fix anon owner in fast-path, avoid runtime call (aarch64)
>  - ... and 89 more: https://git.openjdk.org/jdk/compare/5726d31e...f9f93b36

Another chunk of partial review. This time I did the src/hotspot/cpu/aarch64
and src/hotspot/cpu/arm files:

src/hotspot/cpu/aarch64/aarch64.ad
src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp
src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp
src/hotspot/cpu/aarch64/c2_CodeStubs_aarch64.cpp
src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp
src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp
src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp
src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp
src/hotspot/cpu/aarch64/stubRoutines_aarch64.cpp
src/hotspot/cpu/aarch64/stubRoutines_aarch64.hpp

src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp
src/hotspot/cpu/arm/c1_MacroAssembler_arm.cpp

src/hotspot/cpu/aarch64/aarch64.ad line 3856:

> 3854:         // Indicate success at cont.
> 3855:         __ cmp(oop, oop);
> 3856:         __ b(count);

This code does `b(count)` and the `count` label is after the `cont`
label so the comment on L3912 doesn't quite make sense. Perhaps:

`// Indicate success on completion.`

src/hotspot/cpu/aarch64/c2_CodeStubs_aarch64.cpp line 68:

> 66: 
> 67: int C2CheckLockStackStub::max_size() const {
> 68:   return 20;

nit - a comment explaining this choice of literal value ('20') would be useful

src/hotspot/cpu/aarch64/c2_CodeStubs_aarch64.cpp line 79:

> 77: 
> 78: int C2HandleAnonOMOwnerStub::max_size() const {
> 79:   return 20;

nit - a comment explaining this choice of literal value ('20') would be useful

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5491:

> 5489: 
> 5490: 
> 5491:     __ pop_call_clobbered_registers();

nit - double blank lines here for a reason?

src/hotspot/cpu/arm/c1_MacroAssembler_arm.cpp line 56:

> 54: }
> 55: 
> 56: void C1_MacroAssembler::build_frame(int frame_size_in_bytes, int bang_size_in_bytes, int max_monitors) {

So the `max_monitors` param is added, but not use of it.
Is someone else doing the 32-bit ARM port?

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From dcubed at openjdk.org  Thu Mar  9 23:23:30 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 9 Mar 2023 23:23:30 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v15]
In-Reply-To: <YeXYnGbHymtoOe9eQToM1djB-pJtLWgMoCLxzAyT4vs=.cf42449e-aa0d-4f41-91c1-6066905eee43@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <YeXYnGbHymtoOe9eQToM1djB-pJtLWgMoCLxzAyT4vs=.cf42449e-aa0d-4f41-91c1-6066905eee43@github.com>
Message-ID: <6OKumxjpgT6L0uYvNnYr4tZO3VjvC_ixqFoaRo7bBHs=.8bad7e67-e663-4371-aab8-830df61bbf0e@github.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
On Wed, 8 Mar 2023 18:25:15 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>  - Inline initial LockStack stack

src/hotspot/cpu/aarch64/aarch64.ad line 3914:

> 3912:         // Indicate success at cont.
> 3913:         __ cmp(oop, oop);
> 3914:         __ b(count);

This code does `b(count)` and the `count` label is after the `cont`
label so the comment on L3912 doesn't quite make sense. Perhaps:

`// Indicate success on completion.`

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From dcubed at openjdk.org  Fri Mar 10 01:06:31 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 10 Mar 2023 01:06:31 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v16]
In-Reply-To: <yTDSrIOevRirBhSbxLUMw22pA0sBhTqrCJpx8_EhCwg=.884bd21b-2a13-4522-88ea-a24054346c7a@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <yTDSrIOevRirBhSbxLUMw22pA0sBhTqrCJpx8_EhCwg=.884bd21b-2a13-4522-88ea-a24054346c7a@github.com>
Message-ID: <wTRWCTAo6OQeON42K4JqB_WkPHdjHtkYdfWapVYSRHE=.c142946f-a6b0-41b2-a4e5-fa72071972a4@github.com>

On Thu, 9 Mar 2023 21:08:16 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 99 commits:
> 
>  - Merge branch 'master' into JDK-8291555-v2
>  - Various small fixes and improvements
>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>  - Use realloc instead of malloc+copy when growing the lock-stack
>  - Inline initial LockStack stack
>  - Fix interpreter asymmetric fast-locking
>  - Fix merge error (move done label into correct places)
>  - Merge branch 'master' into JDK-8291555-v2
>  - Small fixes
>  - Fix anon owner in fast-path, avoid runtime call (aarch64)
>  - ... and 89 more: https://git.openjdk.org/jdk/compare/5726d31e...f9f93b36

Another chunk of partial review. This time I did the src/hotspot/cpu/x86 files:

src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp
src/hotspot/cpu/x86/c1_LIRGenerator_x86.cpp
src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp
src/hotspot/cpu/x86/c1_MacroAssembler_x86.hpp
src/hotspot/cpu/x86/c2_CodeStubs_x86.cpp
src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp
src/hotspot/cpu/x86/c2_MacroAssembler_x86.hpp
src/hotspot/cpu/x86/interp_masm_x86.cpp
src/hotspot/cpu/x86/macroAssembler_x86.cpp
src/hotspot/cpu/x86/macroAssembler_x86.hpp
src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp
src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp
src/hotspot/cpu/x86/stubGenerator_x86_64.cpp
src/hotspot/cpu/x86/stubGenerator_x86_64.hpp
src/hotspot/cpu/x86/stubRoutines_x86.cpp
src/hotspot/cpu/x86/stubRoutines_x86.hpp
src/hotspot/cpu/x86/x86_32.ad
src/hotspot/cpu/x86/x86_64.ad

src/hotspot/cpu/x86/c2_CodeStubs_x86.cpp line 77:

> 75: 
> 76: int C2CheckLockStackStub::max_size() const {
> 77:   return 10;

nit - a comment explaining this choice of literal value ('10') would be useful

src/hotspot/cpu/x86/c2_CodeStubs_x86.cpp line 89:

> 87: #ifdef _LP64
> 88: int C2HandleAnonOMOwnerStub::max_size() const {
> 89:   return 17;

nit - a comment explaining this choice of literal value ('17') would be useful

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 624:

> 622:       jmp(COUNT);
> 623: #else
> 624:       // We can not emit the lock-stack-check in verified_entry() because we don't have enough

nit typo: s/can not/cannot/

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 632:

> 630:       jmp(COUNT);
> 631:       bind(slow);
> 632:       testptr(objReg, objReg); // ZF=0 to indicate failure

nit perhaps: // force ZF=0 to indicate failure

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 694:

> 692:   // Invariant: tmpReg == 0.  tmpReg is EAX which is the implicit cmpxchg comparand.
> 693:   lock();
> 694:   cmpxchgptr(thread, Address(boxReg, OM_OFFSET_NO_MONITOR_VALUE_TAG(owner)));

Now that `fast_lock` is being passed in a `thread` register, you've switched
from using `scrReg` to using `thread`. Of course, this means that the comment
from L685 -> L691 needs to be revisited/rewritten. Unfortunately, the GitHub UI
doesn't let me highlight from L685 -> L690 as part of this comment.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 815:

> 813:     jccb(Assembler::zero, Stacked);
> 814:     if (UseFastLocking) {
> 815:       // If the owner is ANONYMOUS, we need to fix it -  in an outline stube.

nit typo: s/outline stube/outline stub/

src/hotspot/cpu/x86/interp_masm_x86.cpp line 1357:

> 1355:       cmpptr(obj_reg, Address(tmp, -oopSize));
> 1356:       jcc(Assembler::notEqual, slow_case);
> 1357:       // Try to swing header from locked to unlock.

nit typo: s/locked to unlock./locked to unlocked./

src/hotspot/cpu/x86/macroAssembler_x86.cpp line 9733:

> 9731: #else
> 9732:   const Register thread = rax;
> 9733:   get_thread(rax);

Other places that use this idiom do it like this:

  const Register thread = rax;
  get_thread(thread);

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From dcubed at openjdk.org  Fri Mar 10 01:16:28 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 10 Mar 2023 01:16:28 GMT
Subject: RFR: 8300926: Several startup regressions ~6-70% in 21-b6 all
 platforms [v6]
In-Reply-To: <u1RGrj1z-aWY4iTnvUHHv6ulbCHoYrlob9HaccSEW08=.20c28eba-06ac-4d41-a3be-1ebc8e2c9ab7@github.com>
References: <yAP6c7wzGguBfKuzvbjMZdnaqydAz4PFn0pgR1UGj9s=.ce872f5d-3f7a-4e24-99d5-da5e80855ea4@github.com>
 <nXKSskpVRVCjCKFaz5S00u1LZXlpsMzbxmCzFfyZFcY=.0d2f92c8-4afc-43eb-a818-86f0bc50e03a@github.com>
 <u1RGrj1z-aWY4iTnvUHHv6ulbCHoYrlob9HaccSEW08=.20c28eba-06ac-4d41-a3be-1ebc8e2c9ab7@github.com>
Message-ID: <FZwBD_DgmMNrPk0nNx_3n9PnmzQFwJo2dj4nA6iHH04=.d9dbf7f1-a7f3-49c8-999b-d270af297f65@github.com>

On Mon, 27 Feb 2023 00:29:26 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Comment fixes
>>  - Include/fwd fixes
>
> In `ciEnv::register_method` we take the `Compile_lock` to ensure `add_to_hierarchy` can't run:
> 
>     // Prevent SystemDictionary::add_to_hierarchy from running
>     // and invalidating our dependencies until we install this method.
>     // No safepoints are allowed. Otherwise, class redefinition can occur in between.
>     MutexLocker ml(Compile_lock);
>     NoSafepointVerifier nsv;
> 
> does moving the deopt outside of the `Compile_lock` affect that?

I've just tried to figure out whether @dholmes-ora's concerns have
been addressed. The last mesgs that I see from David are from
2023.02.26 so about 2 weeks ago, but I can't tell for sure whether
@robehn has addressed those remaining comments or not.

Sorry, but the GitHub UI is really messing me up here.

-------------

PR: https://git.openjdk.org/jdk/pull/12585

From dholmes at openjdk.org  Fri Mar 10 02:14:20 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 10 Mar 2023 02:14:20 GMT
Subject: RFR: 8300926: Several startup regressions ~6-70% in 21-b6 all
 platforms [v8]
In-Reply-To: <z7_2sNpjnL2JYEhq-L6S6VvxwrCEZlHX7EDZx4do_Dw=.783bbdcb-bc62-46f0-83a4-70e6785b9fe0@github.com>
References: <yAP6c7wzGguBfKuzvbjMZdnaqydAz4PFn0pgR1UGj9s=.ce872f5d-3f7a-4e24-99d5-da5e80855ea4@github.com>
 <z7_2sNpjnL2JYEhq-L6S6VvxwrCEZlHX7EDZx4do_Dw=.783bbdcb-bc62-46f0-83a4-70e6785b9fe0@github.com>
Message-ID: <il4Db51FS52QsOrISiWJ3_viOLdnZiLJ46Kk7minyyg=.5b29da27-534f-43e1-b5b3-9099745b858d@github.com>

On Tue, 7 Mar 2023 13:47:55 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi all, please consider.
>> 
>> The original issue was when thread 1 asked to deopt nmethod set X and thread 2 asked for the same or a subset of X.
>> All method will already be marked, but the actual deoptimizing, not entrant, patching PC on stacks and patching post call nops, was not done yet. Which meant thread 2 could 'pass' thread 1.
>> Most places did deopt under Compile_lock, thus this is not an issue, but WB and clearCallSiteContext do not.
>> 
>> Since a handshakes may take long before completion and Compile_lock is used for so much more than deopts.
>> The fix in https://bugs.openjdk.org/browse/JDK-8299074 instead always emitted a handshake even when everything was already marked. (instead of adding Compile_lock to all places)
>> 
>> This turnout to be problematic in the startup, for example the number of deopt handshakes in jetty dry run startup went from 5 to 39 handshakes.
>> 
>> This fix first adds a barrier for which you do not pass until the requested deopts have happened and it coalesces the handshakes.
>> Secondly it moves handshakes part out of the Compile_lock where it is possible.
>> 
>> Which means we fix the performance bug and we reduce the contention on Compile_lock, meaning higher throughput in compiler and things such as class-loading.
>> 
>> It passes t1-t7 with flying colours! t8 still not completed and I'm redoing some testing due to last minute simplifications.
>> 
>> Thanks, Robbin
>
> Robbin Ehn has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Grab lock so code() is stable
>  - Non CHA based vtables fix

I think my previous comments have been addressed.

Thanks

src/hotspot/share/classfile/systemDictionary.cpp line 1618:

> 1616: 
> 1617:   // In case we are not using CHA based vtables we need to make sure the loaded
> 1618:   // deopt is completed before anyone link this class.

nit s/link/links/

src/hotspot/share/classfile/systemDictionary.cpp line 1623:

> 1621:   if (!UseVtableBasedCHA) {
> 1622:     k->init_monitor()->lock();
> 1623:   }

You could use a `MutexLocker` to manage this too.

-------------

PR: https://git.openjdk.org/jdk/pull/12585

From dholmes at openjdk.org  Fri Mar 10 02:27:13 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 10 Mar 2023 02:27:13 GMT
Subject: RFR: 8302491: NoClassDefFoundError omits the original cause of an
 error [v7]
In-Reply-To: <MXlHYT8RkJEakZpD6aFFSFyOhK9-aSbCMRoycp9db14=.553419d4-f880-48bf-ae8b-e13e5aff6456@github.com>
References: <L-pfBfK4TKl5KUWpPEcbs-IkhwimgJZ-SOrbSG3exeA=.5e883f22-de9b-4eec-9e98-8ee954a7996b@github.com>
 <MXlHYT8RkJEakZpD6aFFSFyOhK9-aSbCMRoycp9db14=.553419d4-f880-48bf-ae8b-e13e5aff6456@github.com>
Message-ID: <EgDBSUKocgvzDKy_NDX_D2hpT4EmPcLrXpQI-_Q5Cxw=.e6ecfd72-1a96-43be-b625-93da536f5455@github.com>

On Thu, 9 Mar 2023 23:12:00 GMT, Ilarion Nakonechnyy <inakonechnyy at openjdk.org> wrote:

>> The proposed approach added a new function for getting the cause of an exception -`java_lang_Throwable::get_cause_simple `, that gets called within `InstanceKlass::add_initialization_error`  if an old one `java_lang_Throwable::get_cause_with_stack_trace` didn't succeed because of an exception during the VM call. The simple function doesn't call the VM for getting a stack trace but fills in any other information about an exception.
>> 
>> Besides that, the discovering information about an exception was added to `ConstantPoolCacheEntry::save_and_throw_indy_exc` function. 
>> 
>> Jtreg for reproducing the issue also was added to the commit. 
>> The commit was tested with tier1 tests.
>
> Ilarion Nakonechnyy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Some corrections

Looks good. Thanks.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12566

From dholmes at openjdk.org  Fri Mar 10 03:24:06 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 10 Mar 2023 03:24:06 GMT
Subject: RFR: 8303810: Restore attribute positions after JDK-8303839 to
 match JDK-8302124 [v3]
In-Reply-To: <iii6piYafXSVnOrWTyqY6HivGhSd4Mvtg5SKcpC5icQ=.153e1f72-8986-42f9-8af5-025cfd40b76d@github.com>
References: <J6UWvKQHQtTqoqh5udTU6RNg7XkhSrC6D73O61sgW5M=.9bed1df4-c1be-47ac-81b0-e2c0ba3f3e58@github.com>
 <iii6piYafXSVnOrWTyqY6HivGhSd4Mvtg5SKcpC5icQ=.153e1f72-8986-42f9-8af5-025cfd40b76d@github.com>
Message-ID: <UzSLm0wxfCLa24ySRvFtKs_swsoDhg5SqoW5opWriwg=.2cf25c7c-044c-45f4-9295-34783e170f71@github.com>

On Thu, 9 Mar 2023 11:54:44 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> [JDK-8303839](https://bugs.openjdk.org/browse/JDK-8303839)'s revert of [[noreturn]] attributes also moved their already existing attributes back to behind their corresponding methods, they should be restored to where [JDK-8302124](https://bugs.openjdk.org/browse/JDK-8302124) requires them to be. Also fixes attribute from [JDK-8292269](https://bugs.openjdk.org/browse/JDK-8292269)
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   debug.hpp

I agree with Kim. Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/12918

From sspitsyn at openjdk.org  Fri Mar 10 03:54:01 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 10 Mar 2023 03:54:01 GMT
Subject: RFR: 8303908: Add missing check in
 VTMS_transition_disable_for_all() for suspend mode
In-Reply-To: <MW-CIeSI8D3Opes0-cjiBHbvBuuUfKxhrZoEpRPylCg=.19babd2e-b3c6-48f7-a6ab-7d38f3211507@github.com>
References: <MW-CIeSI8D3Opes0-cjiBHbvBuuUfKxhrZoEpRPylCg=.19babd2e-b3c6-48f7-a6ab-7d38f3211507@github.com>
Message-ID: <LeCHhxcupMmV7WPYkhf8J-23p-w_bo4vp1gJxIFVuTg=.02bf31d6-8413-4b0f-923a-08036797b5c9@github.com>

On Thu, 9 Mar 2023 18:55:06 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review this small fix. A suspender is a JvmtiVTMSTransitionDisabler monopolist, meaning VTMS_transition_disable_for_all() should not return while there is any active jvmtiVTMSTransitionDisabler. The code though is checking for active "all-disablers" but it's missing the check for active "single disablers".
> I attached a simple reproducer to the bug which I used to test the patch. Not sure if it was worth adding a test so the patch contains just the fix.
> 
> Thanks,
> Patricio

This looks good.
Thank you for catching and taking care about it!
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12956

From dholmes at openjdk.org  Fri Mar 10 04:40:13 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 10 Mar 2023 04:40:13 GMT
Subject: RFR: 8303908: Add missing check in
 VTMS_transition_disable_for_all() for suspend mode
In-Reply-To: <MW-CIeSI8D3Opes0-cjiBHbvBuuUfKxhrZoEpRPylCg=.19babd2e-b3c6-48f7-a6ab-7d38f3211507@github.com>
References: <MW-CIeSI8D3Opes0-cjiBHbvBuuUfKxhrZoEpRPylCg=.19babd2e-b3c6-48f7-a6ab-7d38f3211507@github.com>
Message-ID: <fY6ySkv20W_RnUGpkuiUMoQvWUm0f4-Hle_jIkGigs8=.16dfee6f-7dd9-41e0-8c10-a161b6671d1b@github.com>

On Thu, 9 Mar 2023 18:55:06 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review this small fix. A suspender is a JvmtiVTMSTransitionDisabler monopolist, meaning VTMS_transition_disable_for_all() should not return while there is any active jvmtiVTMSTransitionDisabler. The code though is checking for active "all-disablers" but it's missing the check for active "single disablers".
> I attached a simple reproducer to the bug which I used to test the patch. Not sure if it was worth adding a test so the patch contains just the fix.
> 
> Thanks,
> Patricio

src/hotspot/share/prims/jvmtiThreadState.cpp line 372:

> 370:   java_lang_Thread::dec_VTMS_transition_disable_count(vth());
> 371:   Atomic::dec(&_VTMS_transition_disable_for_one_count);
> 372:   if (_VTMS_transition_disable_for_one_count == 0 || _is_SR) {

Sorry I don't understand why this `_is_SR` check was removed.  I admit I can't really figure out what this field means anyway, but there is nothing in the issue description that suggests this also needs changing - and it is now different to `VTMS_transition_enable_for_all`.

-------------

PR: https://git.openjdk.org/jdk/pull/12956

From dholmes at openjdk.org  Fri Mar 10 05:27:18 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 10 Mar 2023 05:27:18 GMT
Subject: RFR: 8300926: Several startup regressions ~6-70% in 21-b6 all
 platforms [v8]
In-Reply-To: <il4Db51FS52QsOrISiWJ3_viOLdnZiLJ46Kk7minyyg=.5b29da27-534f-43e1-b5b3-9099745b858d@github.com>
References: <yAP6c7wzGguBfKuzvbjMZdnaqydAz4PFn0pgR1UGj9s=.ce872f5d-3f7a-4e24-99d5-da5e80855ea4@github.com>
 <z7_2sNpjnL2JYEhq-L6S6VvxwrCEZlHX7EDZx4do_Dw=.783bbdcb-bc62-46f0-83a4-70e6785b9fe0@github.com>
 <il4Db51FS52QsOrISiWJ3_viOLdnZiLJ46Kk7minyyg=.5b29da27-534f-43e1-b5b3-9099745b858d@github.com>
Message-ID: <13XU6KtsVFH4NbZMqa0OcTAMEleA-Ia1Oy_34b5IV-I=.ee32fceb-ec0e-40ad-8c64-fdd57dc99941@github.com>

On Fri, 10 Mar 2023 02:09:54 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Grab lock so code() is stable
>>  - Non CHA based vtables fix
>
> src/hotspot/share/classfile/systemDictionary.cpp line 1623:
> 
>> 1621:   if (!UseVtableBasedCHA) {
>> 1622:     k->init_monitor()->lock();
>> 1623:   }
> 
> You could use a `MutexLocker` to manage this too.

Doh! No you can't this is a monitor not a mutex.

-------------

PR: https://git.openjdk.org/jdk/pull/12585

From dholmes at openjdk.org  Fri Mar 10 06:40:05 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 10 Mar 2023 06:40:05 GMT
Subject: RFR: JDK-8303861: Error handling step timeouts should never be
 blocked by OnError and others [v2]
In-Reply-To: <FVO8BPbYbbOlrFQhTESwAOM4TifV2UQeF2nk6A2NCx4=.de3bf2b9-59a9-4df8-af8a-7550451a85db@github.com>
References: <MsoamxpcF7RfrdiX5BXcHcluFN6HqcIZwwLedCUSQck=.8f187897-f3b4-46b8-9811-faba5d2e0b7b@github.com>
 <FVO8BPbYbbOlrFQhTESwAOM4TifV2UQeF2nk6A2NCx4=.de3bf2b9-59a9-4df8-af8a-7550451a85db@github.com>
Message-ID: <J-V1jdlY5xlDWYXaVG8-Nr-V_OLlXts-r_tKz8h6QQw=.dbe58f50-4a08-4165-ba32-fdd129163073@github.com>

On Thu, 9 Mar 2023 10:09:28 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Fatal error handling is subject to several timeouts:
>> - a global timeout (controlled via ErrorLogTimeout)
>> - local error reporting step timeouts.
>> 
>> The latter aims to "give the JVM a kick" if it gets stuck in one particular place during error reporting. This prevents one error reporting step from hogging all the time allotted to error reporting under ErrorLogTimeout.
>> 
>> There are three situations where atm we suppress the global error timeout:
>> - if the JVM is embedded and the launcher has its abort hook installed. Obviously, that must be allowed to run.
>> - if the user specified one or more OnError commands to run, and these did not yet run. These must have a chance to run unmolested.
>> - if the user (typically developer) specified ShowMessageBoxOnError, and the error box has not yet been shown
>> 
>> There is a bug though, that also prevents the step timeout from firing if either condition is true. That is plain wrong.
>> 
>> In addition to that, the test interval WatcherThread uses to check for timeouts should be decreased. It sits at 1 second, which is too coarse-grained. 
>> 
>> --------
>> 
>> Patch:
>> - reworks `VMError::check_timeout()` to never block step timeouts
>> - adds clarifying comments
>> - quadruples timeout check frequency by watcher thread
>> - adds regression test for timeout handling with OnError
>> - additionally limits timeout per individual error reporting step to 5 seconds. 5 seconds is usually enough to distinguish a slow error reporting step from one that is endlessly hanging. 
>> 
>> Tested locally on Linux x64.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   limit step timeout to 5 seconds max

Changes seem fine. Thanks for the clear explanation.

src/hotspot/share/runtime/nonJavaThread.cpp line 274:

> 272: 
> 273:         // Wait a second, then recheck for timeout.
> 274:         os::naked_short_sleep(999);

Harmless change but I don't see why we need sub-second resolution when the ErrorLogTimeout is in seconds. ??

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12936

From stuefe at openjdk.org  Fri Mar 10 07:23:15 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 10 Mar 2023 07:23:15 GMT
Subject: RFR: JDK-8303861: Error handling step timeouts should never be
 blocked by OnError and others [v2]
In-Reply-To: <J-V1jdlY5xlDWYXaVG8-Nr-V_OLlXts-r_tKz8h6QQw=.dbe58f50-4a08-4165-ba32-fdd129163073@github.com>
References: <MsoamxpcF7RfrdiX5BXcHcluFN6HqcIZwwLedCUSQck=.8f187897-f3b4-46b8-9811-faba5d2e0b7b@github.com>
 <FVO8BPbYbbOlrFQhTESwAOM4TifV2UQeF2nk6A2NCx4=.de3bf2b9-59a9-4df8-af8a-7550451a85db@github.com>
 <J-V1jdlY5xlDWYXaVG8-Nr-V_OLlXts-r_tKz8h6QQw=.dbe58f50-4a08-4165-ba32-fdd129163073@github.com>
Message-ID: <74f_tU9_sqUx333OTutJ1T_b1HLSssABZfHSNAhcuvU=.f8eb353d-863f-4a4a-9270-09d906eae2d0@github.com>

On Fri, 10 Mar 2023 06:27:28 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   limit step timeout to 5 seconds max
>
> src/hotspot/share/runtime/nonJavaThread.cpp line 274:
> 
>> 272: 
>> 273:         // Wait a second, then recheck for timeout.
>> 274:         os::naked_short_sleep(999);
> 
> Harmless change but I don't see why we need sub-second resolution when the ErrorLogTimeout is in seconds. ??

This matters because it also applies to each step timeout too. If we check only once per second, we overshoot each timeout by up to one second. This overshooting happens for every step timeout. If we are in a situation like here where we ignore the global step timeout, and we keep running into deadlocks e.g. in malloc, we will encounter a lot of step timeouts; these would add up.

-------------

PR: https://git.openjdk.org/jdk/pull/12936

From stuefe at openjdk.org  Fri Mar 10 07:36:17 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 10 Mar 2023 07:36:17 GMT
Subject: RFR: JDK-8303861: Error handling step timeouts should never be
 blocked by OnError and others [v2]
In-Reply-To: <74f_tU9_sqUx333OTutJ1T_b1HLSssABZfHSNAhcuvU=.f8eb353d-863f-4a4a-9270-09d906eae2d0@github.com>
References: <MsoamxpcF7RfrdiX5BXcHcluFN6HqcIZwwLedCUSQck=.8f187897-f3b4-46b8-9811-faba5d2e0b7b@github.com>
 <FVO8BPbYbbOlrFQhTESwAOM4TifV2UQeF2nk6A2NCx4=.de3bf2b9-59a9-4df8-af8a-7550451a85db@github.com>
 <J-V1jdlY5xlDWYXaVG8-Nr-V_OLlXts-r_tKz8h6QQw=.dbe58f50-4a08-4165-ba32-fdd129163073@github.com>
 <74f_tU9_sqUx333OTutJ1T_b1HLSssABZfHSNAhcuvU=.f8eb353d-863f-4a4a-9270-09d906eae2d0@github.com>
Message-ID: <Cp6tsOb8-G60du1S1lqsP0cXeay7QMkHQOzm_HUHJnA=.3cad3671-0468-469d-ad02-67acf5c70353@github.com>

On Fri, 10 Mar 2023 07:20:00 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/share/runtime/nonJavaThread.cpp line 274:
>> 
>>> 272: 
>>> 273:         // Wait a second, then recheck for timeout.
>>> 274:         os::naked_short_sleep(999);
>> 
>> Harmless change but I don't see why we need sub-second resolution when the ErrorLogTimeout is in seconds. ??
>
> This matters because it also applies to each step timeout too. If we check only once per second, we overshoot each timeout by up to one second. This overshooting happens for every step timeout. If we are in a situation like here where we ignore the global step timeout, and we keep running into deadlocks e.g. in malloc, we will encounter a lot of step timeouts; these would add up.

Note that this matters even more in the context of https://github.com/openjdk/jdk/pull/11017, since that will increase the granularity for each error reporting step, potentially exposing us to a lot more individual timeouts.

-------------

PR: https://git.openjdk.org/jdk/pull/12936

From rkennke at openjdk.org  Fri Mar 10 09:41:10 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 10 Mar 2023 09:41:10 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v17]
In-Reply-To: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
Message-ID: <VvizU_6h-iIjsyxib9ey4afVSRXzmSf61eJoFZfY3PQ=.c9b5e91f-349d-4e94-a3eb-558014fb17f1@github.com>

> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
> 
> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p
 rotocols.
> 
> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
> 
> 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
> 
> 
> Testing:
>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
> 
> ### Performance
> 
> #### Simple Microbenchmark
> 
> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
> 
> |  | x86_64 | aarch64 |
> | -- | -- | -- |
> | -UseFastLocking | 20.651 | 20.764 |
> | +UseFastLocking | 18.896 | 18.908 |
> 
> 
> #### Renaissance
> 
> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
> -- | -- | -- | -- | -- | -- | -- | --
> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Fixes in response to Daniel's review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10907/files
  - new: https://git.openjdk.org/jdk/pull/10907/files/f9f93b36..51a00e91

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=15-16

  Stats: 9 lines in 3 files changed: 6 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10907.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10907/head:pull/10907

PR: https://git.openjdk.org/jdk/pull/10907

From rkennke at openjdk.org  Fri Mar 10 09:41:27 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 10 Mar 2023 09:41:27 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v16]
In-Reply-To: <vyETQzjqNYypGaZoxGT02WuzSreJyH7mMRLJyUFjPLA=.a210dec5-2a7f-4814-8014-021a9dcba4a5@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <yTDSrIOevRirBhSbxLUMw22pA0sBhTqrCJpx8_EhCwg=.884bd21b-2a13-4522-88ea-a24054346c7a@github.com>
 <vyETQzjqNYypGaZoxGT02WuzSreJyH7mMRLJyUFjPLA=.a210dec5-2a7f-4814-8014-021a9dcba4a5@github.com>
Message-ID: <pIwU3AfOdt0PR1klpn_eWD1ikv78tQ6kBrfagVTczcc=.aeecd18b-6c92-4be8-babc-12e25729e2f2@github.com>

On Thu, 9 Mar 2023 23:17:39 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 99 commits:
>> 
>>  - Merge branch 'master' into JDK-8291555-v2
>>  - Various small fixes and improvements
>>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>>  - Use realloc instead of malloc+copy when growing the lock-stack
>>  - Inline initial LockStack stack
>>  - Fix interpreter asymmetric fast-locking
>>  - Fix merge error (move done label into correct places)
>>  - Merge branch 'master' into JDK-8291555-v2
>>  - Small fixes
>>  - Fix anon owner in fast-path, avoid runtime call (aarch64)
>>  - ... and 89 more: https://git.openjdk.org/jdk/compare/5726d31e...f9f93b36
>
> src/hotspot/cpu/arm/c1_MacroAssembler_arm.cpp line 56:
> 
>> 54: }
>> 55: 
>> 56: void C1_MacroAssembler::build_frame(int frame_size_in_bytes, int bang_size_in_bytes, int max_monitors) {
> 
> So the `max_monitors` param is added, but not use of it.
> Is someone else doing the 32-bit ARM port?

Hopefully :-) I currently can't do it, though. With fast-locking (and the rest of Lilliput) behind an experimental flag, this is probably ok for now?

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From rkennke at openjdk.org  Fri Mar 10 09:55:03 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 10 Mar 2023 09:55:03 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v18]
In-Reply-To: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
Message-ID: <oHxvD3hlq7rIroAMxZnpFex7AYDbwUyowWlI5hF-WG0=.264251e0-553a-40c6-a089-cf7a4e7dd77e@github.com>

> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
> 
> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p
 rotocols.
> 
> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
> 
> 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
> 
> 
> Testing:
>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
> 
> ### Performance
> 
> #### Simple Microbenchmark
> 
> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
> 
> |  | x86_64 | aarch64 |
> | -- | -- | -- |
> | -UseFastLocking | 20.651 | 20.764 |
> | +UseFastLocking | 18.896 | 18.908 |
> 
> 
> #### Renaissance
> 
> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
> -- | -- | -- | -- | -- | -- | -- | --
> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Fixes in response to Daniel's review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10907/files
  - new: https://git.openjdk.org/jdk/pull/10907/files/51a00e91..8ba676a0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=16-17

  Stats: 20 lines in 4 files changed: 6 ins; 7 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/10907.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10907/head:pull/10907

PR: https://git.openjdk.org/jdk/pull/10907

From mgronlun at openjdk.org  Fri Mar 10 10:43:23 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 10 Mar 2023 10:43:23 GMT
Subject: RFR: 8257967: JFR: Events for loaded agents [v10]
In-Reply-To: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
References: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
Message-ID: <ZsaBMVK-eeLfmxgg15qPJHm6C-ed5PyIE4lGr-Gnr2s=.2f4044c4-e7ed-48f3-8877-feeb2753be18@github.com>

> Greetings,
> 
> We are adding support to let JFR report on Agents.
> 
> #### Design
> 
> An Agent is a library that uses any instrumentation or profiling APIs. Most agents are started and initialized on the command line, but agents can also be loaded dynamically during runtime. Because command line agents initialize during the VM startup sequence, they add to the overall startup time latency in getting the VM ready. The events will report on the time the agent took to initialize.
> 
> A JavaAgent is an agent written in the Java programming language, using the APIs in the package [java.lang.instrument](https://docs.oracle.com/en/java/javase/19/docs/api/java.instrument/java/lang/instrument/package-summary.html)
> 
> A JavaAgent is sometimes called a JPLIS agent, where the acronym JPLIS stands for Java Programming Language Instrumentation Services.
> 
> To report on JavaAgents, JFR will add the new event type jdk.JavaAgent and events will look similar to these two examples:
> 
> // Command line
> jdk.JavaAgent {
>   startTime = 12:31:19.789 (2023-03-08)
>   name = "JavaAgent.jar"
>   options = "foo=bar"
>   dynamic = false
>   initialization = 12:31:15.574 (2023-03-08)
>   initializationTime = 172 ms
> }
> 
> // Dynamic load
> jdk.JavaAgent {
>   startTime = 12:31:31.158 (2023-03-08)
>   name = "JavaAgent.jar"
>   options = "bar=baz"
>   dynamic = true
>   initialization = 12:31:31.037 (2023-03-08)
>   initializationTime = 64,1 ms
> }
> 
> The jdk.JavaAgent event type is a JFR periodic event that iterates over running Java agents.
> 
> For a JavaAgent event, the agent's name will be the specific .jar file containing the instrumentation code. The options will be the specific options passed to the .jar file as part of launching the agent, for example, on the command line: -javaagent: JavaAgent.jar=foo=bar.
> 
> The "dynamic" field denotes if the agent was loaded via the command line (dynamic = false) or dynamically (dynamic = true)
> 
> "initialization" is the timestamp the JVM invoked the initialization method, and "initializationTime" is the duration of executing the initialization method.
> 
> "startTime" represents the time the JFR framework issued the periodic event; hence "initialization" will be earlier than "startTime".
> 
> An agent can also be written in a native programming language using the [JVM Tools Interface (JVMTI)](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html). This kind of agent, sometimes called a native agent, is a platform-specific binary, sometimes referred to as a library, but here it means a .so or .dll file.
> 
> To report on native agents, JFR will add the new event type jdk.NativeAgent and events will look similar to this example:
> 
> jdk.NativeAgent {
>   startTime = 12:31:40.398 (2023-03-08)
>   name = "jdwp"
>   options = "transport=dt_socket,server=y,address=any,onjcmd=y"
>   dynamic = false
>   initialization = 12:31:36.142 (2023-03-08)
>   initializationTime = 0,00184 ms
>   path = "c:\ade\github\openjdk\jdk\build\windows-x86_64-server-slowdebug\jdk\bin\jdwp.dll"
> }
> 
> The layout of the event type is very similar to the jdk.JavaAgent event, but here the path to the native library is reported.
> 
> The initialization of a native agent is performed by invoking an agent-specified callback routine. The "initialization" is when the JVM sent or would have sent the JVMTI VMInit event to a specified callback. "initializationTime" is the duration to execute that specific callback. If no callback is specified for the JVMTI VMInit event, the "initializationTime" will be 0.
> 
> #### Implementation
> 
> There has not existed a reification of a JavaAgent directly in the JVM, as these are built on top of the JDK native library, "instrument", using a many-to-one mapping. At the level of the JVM, the only representation of agents after startup is through JvmtiEnv's, which agents request from the JVM during startup and initialization ? as such, mapping which JvmtiEnv belongs to what JavaAgent was not possible before.
> 
> Using implementation details of how the JDK native library "instrument" interacts with the JVM, we can build this mapping to track what JvmtiEnv's "belong" to what JavaAgent. This mapping now lets us report the Java-relevant context (name, options) and measure the time it takes for the JavaAgent to initialize.
> 
> When implementing this capability, it was necessary to refactor the code used to represent agents, AgentLibrary. The previous implementation was located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp.
> 
> The refactoring isolates the relevant logic into two new modules, prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their older places will help reduce the sizes of oversized arguments.cpp and threads.cpp.
> 
> The previous two lists that maintained "agents" (JVMTI) and "libraries" (Xrun) were not thread-safe for concurrent iterations. A single list that allows for concurrent iterations is therefore introduced.
> 
> Testing: jdk_jfr, tier 1 - 6
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  more cleanup

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12923/files
  - new: https://git.openjdk.org/jdk/pull/12923/files/abeaa324..741b8686

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12923&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12923&range=08-09

  Stats: 12 lines in 3 files changed: 1 ins; 10 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12923.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12923/head:pull/12923

PR: https://git.openjdk.org/jdk/pull/12923

From redestad at openjdk.org  Fri Mar 10 12:05:18 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 10 Mar 2023 12:05:18 GMT
Subject: RFR: 8292059: Do not inline InstanceKlass::allocate_instance()
 [v3]
In-Reply-To: <AoO4NoxXkd0A7BaeS9USCnCIzoBEuQXtQ6IzoZk0Vho=.ec64e661-66cb-4d5b-8a24-8cffede72eae@github.com>
References: <ZSJBTzuC4wVuKdqSLLTgw4Pds2oX5wah0Ub6rFux_tc=.c4e2ae89-cadb-4ccd-9eee-034583cf7200@github.com>
 <7Aide4lBzCPDqqanrD8I9SsT6LXneQ8CKSU4os4lH-Q=.38f1186f-01b0-4975-ad16-fcfd4eb6c031@github.com>
 <AoO4NoxXkd0A7BaeS9USCnCIzoBEuQXtQ6IzoZk0Vho=.ec64e661-66cb-4d5b-8a24-8cffede72eae@github.com>
Message-ID: <2UIY6-oXHq0ZoyH15FivSR88Zcn6jhoM2HNCGiEeReE=.9f69d990-7884-4f7b-bdb9-03dc9e958518@github.com>

On Thu, 9 Mar 2023 17:33:29 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> That's really surprising. I also don't see how any of the proposed changes could affect the GC so much. This makes me suspicious of the performance claims.
> 
> Could you redo the benchmarking and give us more information about:
> 
> 1. What benchmarks were run
> 2. What was the benchmarks scores and GC metrics
> 3. What was the run-to-run variance in the scores and metrics

FWIW we had a discussion about this earlier and I'm as skeptical as you about the results listed in this PRs description. I also pointed to the microbenchmark - `./test/micro/org/openjdk/bench/vm/lambda/capture/Capture0.java` - which I used originally to motivate the move of `allocate_instance(oop, TRAPS)` to inline.hpp, ran the numbers and saw that there's no longer any discernible effect from moving it back to .cpp:


Benchmark           Mode  Cnt   Score   Error  Units
Capture0.lambda_01  avgt   12  65,492 ? 1,675  ns/op # master
Capture0.lambda_01  avgt   12  65,022 ? 1,241  ns/op # pr/12782


This was before the `oop -> InstanceKlass*` change. @afshin-zafari then ran that experiment and saw a small win on that microbenchmark from doing parameter change. While the win is probably too small to matter I didn't find it objectionable since it seems reasonable to move oop conversions earlier.

-------------

PR: https://git.openjdk.org/jdk/pull/12782

From dholmes at openjdk.org  Fri Mar 10 12:12:15 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 10 Mar 2023 12:12:15 GMT
Subject: RFR: JDK-8303861: Error handling step timeouts should never be
 blocked by OnError and others [v2]
In-Reply-To: <Cp6tsOb8-G60du1S1lqsP0cXeay7QMkHQOzm_HUHJnA=.3cad3671-0468-469d-ad02-67acf5c70353@github.com>
References: <MsoamxpcF7RfrdiX5BXcHcluFN6HqcIZwwLedCUSQck=.8f187897-f3b4-46b8-9811-faba5d2e0b7b@github.com>
 <FVO8BPbYbbOlrFQhTESwAOM4TifV2UQeF2nk6A2NCx4=.de3bf2b9-59a9-4df8-af8a-7550451a85db@github.com>
 <J-V1jdlY5xlDWYXaVG8-Nr-V_OLlXts-r_tKz8h6QQw=.dbe58f50-4a08-4165-ba32-fdd129163073@github.com>
 <74f_tU9_sqUx333OTutJ1T_b1HLSssABZfHSNAhcuvU=.f8eb353d-863f-4a4a-9270-09d906eae2d0@github.com>
 <Cp6tsOb8-G60du1S1lqsP0cXeay7QMkHQOzm_HUHJnA=.3cad3671-0468-469d-ad02-67acf5c70353@github.com>
Message-ID: <oa17C447rUZrFDU6OB3KHYx9kw3bdnMdvCdqRC8JUrA=.2f158a4a-b6b6-4c2e-a392-3c04a1bb5b58@github.com>

On Fri, 10 Mar 2023 07:33:30 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> This matters because it also applies to each step timeout too. If we check only once per second, we overshoot each timeout by up to one second. This overshooting happens for every step timeout. If we are in a situation like here where we ignore the global step timeout, and we keep running into deadlocks e.g. in malloc, we will encounter a lot of step timeouts; these would add up.
>
> Note that this matters even more in the context of https://github.com/openjdk/jdk/pull/11017, since that will increase the granularity for each error reporting step, potentially exposing us to a lot more individual timeouts.

I thought there was a limit of three step timeouts before we gave up? And the step timeout is a quarter of the global so still many seconds.

-------------

PR: https://git.openjdk.org/jdk/pull/12936

From rkennke at openjdk.org  Fri Mar 10 12:25:09 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 10 Mar 2023 12:25:09 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v19]
In-Reply-To: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
Message-ID: <rsI2XB6LFoX2SUZIaJTTiy2LnnKUyMEQeNAqSBnDn0U=.d26dccf7-788d-4c6b-b50a-692851c8a1d0@github.com>

> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
> 
> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p
 rotocols.
> 
> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
> 
> 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
> 
> 
> Testing:
>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
> 
> ### Performance
> 
> #### Simple Microbenchmark
> 
> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
> 
> |  | x86_64 | aarch64 |
> | -- | -- | -- |
> | -UseFastLocking | 20.651 | 20.764 |
> | +UseFastLocking | 18.896 | 18.908 |
> 
> 
> #### Renaissance
> 
> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
> -- | -- | -- | -- | -- | -- | -- | --
> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Use nullptr instead of NULL in touched code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10907/files
  - new: https://git.openjdk.org/jdk/pull/10907/files/8ba676a0..8aad280a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=17-18

  Stats: 10 lines in 6 files changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/10907.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10907/head:pull/10907

PR: https://git.openjdk.org/jdk/pull/10907

From rkennke at openjdk.org  Fri Mar 10 12:36:28 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 10 Mar 2023 12:36:28 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v20]
In-Reply-To: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
Message-ID: <QodjWqFd66UcXwvaUSupfv2ruPTOjZIQpiZ9U7RNrTk=.25e231b0-7ae7-4a75-81d3-07cda4e20d14@github.com>

> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
> 
> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p
 rotocols.
> 
> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
> 
> 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
> 
> 
> Testing:
>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
> 
> ### Performance
> 
> #### Simple Microbenchmark
> 
> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
> 
> |  | x86_64 | aarch64 |
> | -- | -- | -- |
> | -UseFastLocking | 20.651 | 20.764 |
> | +UseFastLocking | 18.896 | 18.908 |
> 
> 
> #### Renaissance
> 
> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
> -- | -- | -- | -- | -- | -- | -- | --
> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%

Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:

 - Use nullptr instead of NULL in touched code (x86)
 - Use nullptr instead of NULL in touched code (riscv)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10907/files
  - new: https://git.openjdk.org/jdk/pull/10907/files/8aad280a..27a4b107

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=18-19

  Stats: 17 lines in 8 files changed: 0 ins; 0 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/10907.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10907/head:pull/10907

PR: https://git.openjdk.org/jdk/pull/10907

From aboldtch at openjdk.org  Fri Mar 10 12:39:03 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 10 Mar 2023 12:39:03 GMT
Subject: RFR: 8303900: Rename BitMap search functions
In-Reply-To: <g09LwD0eFfQb6kIVSi0KAez9RTpnhO91I3QZvpM_Rpc=.bfa7b6fb-c552-4a9d-8e28-c41251e4f2e7@github.com>
References: <g09LwD0eFfQb6kIVSi0KAez9RTpnhO91I3QZvpM_Rpc=.bfa7b6fb-c552-4a9d-8e28-c41251e4f2e7@github.com>
Message-ID: <1EhzQNYr_PTQylNyTm4u4VPII9VuSt26QJmm7pORNFs=.02f76a7f-7cd4-45d5-8602-ac8613fe8c81@github.com>

On Thu, 9 Mar 2023 15:34:05 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this renaming of the following functions in BitMap:
> 
> get_next_one_offset => find_first_set_bit
> get_next_zero_offset => find_first_clear_bit
> get_next_one_offset_aligned_right => find_first_set_bit_aligned_right
> 
> Note that ShenandoahMarkBitMap::get_next_one_offset is not being renamed.  For
> some reason that class contains a copy of a sizable chunk of the code from
> some version of BitMap.  (Not sure why it doesn't use an internal BitMapView
> rather than code copying.)
> 
> Testing:
> mach5 tier1-5

lgtm

-------------

Marked as reviewed by aboldtch (Committer).

PR: https://git.openjdk.org/jdk/pull/12951

From rkennke at openjdk.org  Fri Mar 10 12:45:12 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 10 Mar 2023 12:45:12 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v21]
In-Reply-To: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
Message-ID: <hR80_9dU9pp0SnN8q-qZ7aG-_YWFST6O6EXQZ_pNjPk=.0f0cbf74-2890-4bd5-88ba-fbe4be92764a@github.com>

> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
> 
> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p
 rotocols.
> 
> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
> 
> 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
> 
> 
> Testing:
>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
> 
> ### Performance
> 
> #### Simple Microbenchmark
> 
> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
> 
> |  | x86_64 | aarch64 |
> | -- | -- | -- |
> | -UseFastLocking | 20.651 | 20.764 |
> | +UseFastLocking | 18.896 | 18.908 |
> 
> 
> #### Renaissance
> 
> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
> -- | -- | -- | -- | -- | -- | -- | --
> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%

Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:

 - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
 - Use nullptr instead of NULL in touched code (shared)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10907/files
  - new: https://git.openjdk.org/jdk/pull/10907/files/27a4b107..5fe2afcf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=19-20

  Stats: 8 lines in 6 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/10907.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10907/head:pull/10907

PR: https://git.openjdk.org/jdk/pull/10907

From stuefe at openjdk.org  Fri Mar 10 13:14:25 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 10 Mar 2023 13:14:25 GMT
Subject: RFR: JDK-8303861: Error handling step timeouts should never be
 blocked by OnError and others [v2]
In-Reply-To: <oa17C447rUZrFDU6OB3KHYx9kw3bdnMdvCdqRC8JUrA=.2f158a4a-b6b6-4c2e-a392-3c04a1bb5b58@github.com>
References: <MsoamxpcF7RfrdiX5BXcHcluFN6HqcIZwwLedCUSQck=.8f187897-f3b4-46b8-9811-faba5d2e0b7b@github.com>
 <FVO8BPbYbbOlrFQhTESwAOM4TifV2UQeF2nk6A2NCx4=.de3bf2b9-59a9-4df8-af8a-7550451a85db@github.com>
 <J-V1jdlY5xlDWYXaVG8-Nr-V_OLlXts-r_tKz8h6QQw=.dbe58f50-4a08-4165-ba32-fdd129163073@github.com>
 <74f_tU9_sqUx333OTutJ1T_b1HLSssABZfHSNAhcuvU=.f8eb353d-863f-4a4a-9270-09d906eae2d0@github.com>
 <Cp6tsOb8-G60du1S1lqsP0cXeay7QMkHQOzm_HUHJnA=.3cad3671-0468-469d-ad02-67acf5c70353@github.com>
 <oa17C447rUZrFDU6OB3KHYx9kw3bdnMdvCdqRC8JUrA=.2f158a4a-b6b6-4c2e-a392-3c04a1bb5b58@github.com>
Message-ID: <3tSPj-Axlj3cUMcIHVqcolQHo3Kj9XtPFDUjT285wrQ=.5b5e1098-c89f-4403-9b4f-ca438f6dc899@github.com>

On Fri, 10 Mar 2023 12:09:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Note that this matters even more in the context of https://github.com/openjdk/jdk/pull/11017, since that will increase the granularity for each error reporting step, potentially exposing us to a lot more individual timeouts.
>
> I thought there was a limit of three step timeouts before we gave up? And the step timeout is a quarter of the global so still many seconds.

There is no such limit. There is an implicit limit of 4 step timeouts since step timeout time was 1/4th of ErrorLogTimeout. But 
- that does not apply if we ignore ErrorLogTimeout
- in this patch, I curtailed the maximum step timeout time to 5 seconds (see https://github.com/openjdk/jdk/blob/70b9add7685b3424ac3fee55597d470aa76c8b1b/src/hotspot/share/utilities/vmError.cpp#L1807-L1809), exactly to prevent it from growing very large for very large ErrorLogTimeouts.

So, with my patch: Each step timeout is either ErrorLogTimeout/4 or 5 seconds, whatever is shorter. While writing this, I noted that this also holds true if we then go and ignore ErrorLogTimeout. Should I then just use 5 seconds? Not sure.

-------------

PR: https://git.openjdk.org/jdk/pull/12936

From coleenp at openjdk.org  Fri Mar 10 13:19:15 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 10 Mar 2023 13:19:15 GMT
Subject: RFR: 8302491: NoClassDefFoundError omits the original cause of an
 error [v7]
In-Reply-To: <MXlHYT8RkJEakZpD6aFFSFyOhK9-aSbCMRoycp9db14=.553419d4-f880-48bf-ae8b-e13e5aff6456@github.com>
References: <L-pfBfK4TKl5KUWpPEcbs-IkhwimgJZ-SOrbSG3exeA=.5e883f22-de9b-4eec-9e98-8ee954a7996b@github.com>
 <MXlHYT8RkJEakZpD6aFFSFyOhK9-aSbCMRoycp9db14=.553419d4-f880-48bf-ae8b-e13e5aff6456@github.com>
Message-ID: <5OMkVd6g1moN3jUlReWecYiWbF7USb30A4Y1UpxAifM=.0afc8558-eaa5-4375-8a77-a1e7dd826a87@github.com>

On Thu, 9 Mar 2023 23:12:00 GMT, Ilarion Nakonechnyy <inakonechnyy at openjdk.org> wrote:

>> The proposed approach added a new function for getting the cause of an exception -`java_lang_Throwable::get_cause_simple `, that gets called within `InstanceKlass::add_initialization_error`  if an old one `java_lang_Throwable::get_cause_with_stack_trace` didn't succeed because of an exception during the VM call. The simple function doesn't call the VM for getting a stack trace but fills in any other information about an exception.
>> 
>> Besides that, the discovering information about an exception was added to `ConstantPoolCacheEntry::save_and_throw_indy_exc` function. 
>> 
>> Jtreg for reproducing the issue also was added to the commit. 
>> The commit was tested with tier1 tests.
>
> Ilarion Nakonechnyy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Some corrections

This looks really good except the name I don't like.  Thanks for cleaning this up.

src/hotspot/share/classfile/javaClasses.cpp line 2758:

> 2756: 
> 2757:   Symbol* exception_name = vmSymbols::java_lang_ExceptionInInitializerError();
> 2758:   Handle h_eiie = Exceptions::new_exception(current, exception_name, st.as_string());

I don't like the h_eiie name.  I keep trying to pronounce it in English.  How about "initialization_error" ?  or "init_error"

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12566

From tschatzl at openjdk.org  Fri Mar 10 14:06:16 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 10 Mar 2023 14:06:16 GMT
Subject: RFR: 8303963: Replace various encodings of UINT/SIZE_MAX in gc code
Message-ID: <Fmc4hyR2uLTnJTKeGnpRHqMyNefCPO5POSmjdvaKFzQ=.df9059fb-10ed-48e7-ad23-5bf2f5409023@github.com>

Hi all,

  please review this refactoring that replaces various casts in GC more-or-less related to get all bits set in an uint/size_t with the available constants from cstdint.
The ones in ZGC files were skipped on request.

Testing: local compilation, gha

Thanks,
  Thomas

-------------

Commit messages:
 - Initial version

Changes: https://git.openjdk.org/jdk/pull/12973/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12973&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303963
  Stats: 15 lines in 13 files changed: 0 ins; 2 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/12973.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12973/head:pull/12973

PR: https://git.openjdk.org/jdk/pull/12973

From jcking at openjdk.org  Fri Mar 10 14:10:11 2023
From: jcking at openjdk.org (Justin King)
Date: Fri, 10 Mar 2023 14:10:11 GMT
Subject: RFR: JDK-8300582: Introduce interface for unaligned memory
 accesses [v11]
In-Reply-To: <kpwsfJ3y5HnduUvQvObVDLnRTYGrfsh_OOd9IUz-En0=.a75c7c96-da80-4410-b016-0ef527ddd962@github.com>
References: <kpwsfJ3y5HnduUvQvObVDLnRTYGrfsh_OOd9IUz-En0=.a75c7c96-da80-4410-b016-0ef527ddd962@github.com>
Message-ID: <vT1wKGU7ef-2v00paPseKKpGwRqDs-RvOBsubDmdt74=.fcc7e191-754f-431e-9143-ce0a15a716fc@github.com>

> Introduce interface for unaligned memory accesses `UnalignedAccess`, consolidate the byte swapping implementation to `byteswap`, and switch to a generic implementation of `Bytes`.

Justin King has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  Propose unaligned access interface
  
  Signed-off-by: Justin King <jcking at google.com>

-------------

Changes: https://git.openjdk.org/jdk/pull/12078/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12078&range=10
  Stats: 319 lines in 2 files changed: 319 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12078.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12078/head:pull/12078

PR: https://git.openjdk.org/jdk/pull/12078

From ayang at openjdk.org  Fri Mar 10 14:24:07 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 10 Mar 2023 14:24:07 GMT
Subject: RFR: 8303963: Replace various encodings of UINT/SIZE_MAX in gc
 code
In-Reply-To: <Fmc4hyR2uLTnJTKeGnpRHqMyNefCPO5POSmjdvaKFzQ=.df9059fb-10ed-48e7-ad23-5bf2f5409023@github.com>
References: <Fmc4hyR2uLTnJTKeGnpRHqMyNefCPO5POSmjdvaKFzQ=.df9059fb-10ed-48e7-ad23-5bf2f5409023@github.com>
Message-ID: <w0VqKkqwbwseO8gbXoVrK3jjjFY73ghLtDnbRtGwqcQ=.7b7fdcfc-00e4-49c3-8293-721016e03a04@github.com>

On Fri, 10 Mar 2023 12:58:42 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this refactoring that replaces various casts in GC more-or-less related to get all bits set in an uint/size_t with the available constants from cstdint.
> The ones in ZGC files were skipped on request.
> 
> Testing: local compilation, gha
> 
> Thanks,
>   Thomas

Marked as reviewed by ayang (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12973

From rkennke at openjdk.org  Fri Mar 10 15:01:18 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 10 Mar 2023 15:01:18 GMT
Subject: RFR: JDK-8303861: Error handling step timeouts should never be
 blocked by OnError and others [v2]
In-Reply-To: <FVO8BPbYbbOlrFQhTESwAOM4TifV2UQeF2nk6A2NCx4=.de3bf2b9-59a9-4df8-af8a-7550451a85db@github.com>
References: <MsoamxpcF7RfrdiX5BXcHcluFN6HqcIZwwLedCUSQck=.8f187897-f3b4-46b8-9811-faba5d2e0b7b@github.com>
 <FVO8BPbYbbOlrFQhTESwAOM4TifV2UQeF2nk6A2NCx4=.de3bf2b9-59a9-4df8-af8a-7550451a85db@github.com>
Message-ID: <yPypi4QYuc9hQwXnQTZEV67UFUq8JC9VwYqc-IPjqC4=.b51df4fc-3100-483c-b819-a9f1aa0731ed@github.com>

On Thu, 9 Mar 2023 10:09:28 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Fatal error handling is subject to several timeouts:
>> - a global timeout (controlled via ErrorLogTimeout)
>> - local error reporting step timeouts.
>> 
>> The latter aims to "give the JVM a kick" if it gets stuck in one particular place during error reporting. This prevents one error reporting step from hogging all the time allotted to error reporting under ErrorLogTimeout.
>> 
>> There are three situations where atm we suppress the global error timeout:
>> - if the JVM is embedded and the launcher has its abort hook installed. Obviously, that must be allowed to run.
>> - if the user specified one or more OnError commands to run, and these did not yet run. These must have a chance to run unmolested.
>> - if the user (typically developer) specified ShowMessageBoxOnError, and the error box has not yet been shown
>> 
>> There is a bug though, that also prevents the step timeout from firing if either condition is true. That is plain wrong.
>> 
>> In addition to that, the test interval WatcherThread uses to check for timeouts should be decreased. It sits at 1 second, which is too coarse-grained. 
>> 
>> --------
>> 
>> Patch:
>> - reworks `VMError::check_timeout()` to never block step timeouts
>> - adds clarifying comments
>> - quadruples timeout check frequency by watcher thread
>> - adds regression test for timeout handling with OnError
>> - additionally limits timeout per individual error reporting step to 5 seconds. 5 seconds is usually enough to distinguish a slow error reporting step from one that is endlessly hanging. 
>> 
>> Tested locally on Linux x64.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   limit step timeout to 5 seconds max

Looks good to me. I only have 2 comments. If you change this, I don't need another review.
Thank you!
Roman

src/hotspot/share/utilities/vmError.cpp line 1787:

> 1785:   // Global timeout hit?
> 1786:   if (!ignore_global_timeout) {
> 1787:     const jlong reporting_start_time_l = get_reporting_start_time();

What is the meaning of _l here? Is it to indicate the type of the variable? If so, I would suggest to remove it. (I know it is pre-existing. I leave this up to you.)

test/hotspot/jtreg/runtime/ErrorHandling/TimeoutInErrorHandlingTest.java line 40:

> 38: 
> 39: /*
> 40:  * @test TimeoutInErrorHandlingTest-default

Isn't the better way to name this just '@test TimeoutInErrorHandlingTest' and then '@id=default' and '@id=with-on-error' ?

-------------

Marked as reviewed by rkennke (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12936

From fparain at openjdk.org  Fri Mar 10 15:31:16 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 10 Mar 2023 15:31:16 GMT
Subject: RFR: 8292818: replace 96-bit representation for field metadata
 with variable-sized streams
In-Reply-To: <duJxLMpZeS9KBS839JUNLQPb7u7cBzbFxk4CcmZGdoc=.4704e44a-2680-44e3-93c0-33bb575e9f28@github.com>
References: <vdiacOO3JUyy4sWGkDXNBMUT7cG3XYe79mOvYru9uMM=.9c556675-7ffd-4c09-a428-6d64dffef209@github.com>
 <duJxLMpZeS9KBS839JUNLQPb7u7cBzbFxk4CcmZGdoc=.4704e44a-2680-44e3-93c0-33bb575e9f28@github.com>
Message-ID: <K1BMJOGhZ9F9UGqUkZeL2vgCafXLxr02uBGkfv58mRs=.016891fc-0c3c-446f-8c11-fb2cc09ff7e2@github.com>

On Wed, 8 Mar 2023 16:25:07 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change re-implementing the FieldInfo data structure.
>> 
>> The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency.
>> 
>> The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information).
>> 
>> More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818
>> 
>> Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM.
>> 
>> The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format.
>> 
>> Tested with mach5, tier 1 to 7.
>> 
>> Thank you.
>
> src/hotspot/share/oops/fieldStreams.hpp line 104:
> 
>> 102:     AccessFlags flags;
>> 103:     flags.set_flags(field()->access_flags());
>> 104:     return flags;
> 
> Did this used to do this for a reason?

Using the setter rather than the constructor filters out the VM defined flags and keeps only the flags from the class file.

-------------

PR: https://git.openjdk.org/jdk/pull/12855

From rehn at openjdk.org  Fri Mar 10 15:36:07 2023
From: rehn at openjdk.org (Robbin Ehn)
Date: Fri, 10 Mar 2023 15:36:07 GMT
Subject: RFR: 8300926: Several startup regressions ~6-70% in 21-b6 all
 platforms [v9]
In-Reply-To: <yAP6c7wzGguBfKuzvbjMZdnaqydAz4PFn0pgR1UGj9s=.ce872f5d-3f7a-4e24-99d5-da5e80855ea4@github.com>
References: <yAP6c7wzGguBfKuzvbjMZdnaqydAz4PFn0pgR1UGj9s=.ce872f5d-3f7a-4e24-99d5-da5e80855ea4@github.com>
Message-ID: <4USx1viY-9Jbm_bqdXyiQOVEBXzqb-tQbbTTZxzBNM4=.c46edf13-8beb-456f-b43f-5678de1edf15@github.com>

> Hi all, please consider.
> 
> The original issue was when thread 1 asked to deopt nmethod set X and thread 2 asked for the same or a subset of X.
> All method will already be marked, but the actual deoptimizing, not entrant, patching PC on stacks and patching post call nops, was not done yet. Which meant thread 2 could 'pass' thread 1.
> Most places did deopt under Compile_lock, thus this is not an issue, but WB and clearCallSiteContext do not.
> 
> Since a handshakes may take long before completion and Compile_lock is used for so much more than deopts.
> The fix in https://bugs.openjdk.org/browse/JDK-8299074 instead always emitted a handshake even when everything was already marked. (instead of adding Compile_lock to all places)
> 
> This turnout to be problematic in the startup, for example the number of deopt handshakes in jetty dry run startup went from 5 to 39 handshakes.
> 
> This fix first adds a barrier for which you do not pass until the requested deopts have happened and it coalesces the handshakes.
> Secondly it moves handshakes part out of the Compile_lock where it is possible.
> 
> Which means we fix the performance bug and we reduce the contention on Compile_lock, meaning higher throughput in compiler and things such as class-loading.
> 
> It passes t1-t7 with flying colours! t8 still not completed and I'm redoing some testing due to last minute simplifications.
> 
> Thanks, Robbin

Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:

  Nit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12585/files
  - new: https://git.openjdk.org/jdk/pull/12585/files/be2d3b5e..c39ff2c4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12585&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12585&range=07-08

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12585.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12585/head:pull/12585

PR: https://git.openjdk.org/jdk/pull/12585

From rehn at openjdk.org  Fri Mar 10 15:39:33 2023
From: rehn at openjdk.org (Robbin Ehn)
Date: Fri, 10 Mar 2023 15:39:33 GMT
Subject: RFR: 8300926: Several startup regressions ~6-70% in 21-b6 all
 platforms [v8]
In-Reply-To: <il4Db51FS52QsOrISiWJ3_viOLdnZiLJ46Kk7minyyg=.5b29da27-534f-43e1-b5b3-9099745b858d@github.com>
References: <yAP6c7wzGguBfKuzvbjMZdnaqydAz4PFn0pgR1UGj9s=.ce872f5d-3f7a-4e24-99d5-da5e80855ea4@github.com>
 <z7_2sNpjnL2JYEhq-L6S6VvxwrCEZlHX7EDZx4do_Dw=.783bbdcb-bc62-46f0-83a4-70e6785b9fe0@github.com>
 <il4Db51FS52QsOrISiWJ3_viOLdnZiLJ46Kk7minyyg=.5b29da27-534f-43e1-b5b3-9099745b858d@github.com>
Message-ID: <eumzosuF7xJccgDb8c68haf634tzPWe1y4hzwa4Ou5w=.6e2bbb57-0426-4667-b16a-e06021d0b2bd@github.com>

On Fri, 10 Mar 2023 02:01:12 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Grab lock so code() is stable
>>  - Non CHA based vtables fix
>
> src/hotspot/share/classfile/systemDictionary.cpp line 1618:
> 
>> 1616: 
>> 1617:   // In case we are not using CHA based vtables we need to make sure the loaded
>> 1618:   // deopt is completed before anyone link this class.
> 
> nit s/link/links/

Fixed, thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/12585

From pchilanomate at openjdk.org  Fri Mar 10 17:03:16 2023
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 10 Mar 2023 17:03:16 GMT
Subject: RFR: 8303908: Add missing check in
 VTMS_transition_disable_for_all() for suspend mode
In-Reply-To: <LeCHhxcupMmV7WPYkhf8J-23p-w_bo4vp1gJxIFVuTg=.02bf31d6-8413-4b0f-923a-08036797b5c9@github.com>
References: <MW-CIeSI8D3Opes0-cjiBHbvBuuUfKxhrZoEpRPylCg=.19babd2e-b3c6-48f7-a6ab-7d38f3211507@github.com>
 <LeCHhxcupMmV7WPYkhf8J-23p-w_bo4vp1gJxIFVuTg=.02bf31d6-8413-4b0f-923a-08036797b5c9@github.com>
Message-ID: <q7GxlyWMUe3d2khz4ETpocBYvoRN3kb4d-VYnS0j9fU=.62749505-18dd-4dd0-b9b1-5bd74c244248@github.com>

On Fri, 10 Mar 2023 03:51:05 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This looks good. Thank you for catching and taking care about it! Serguei
>
Thanks for the review Serguei!

-------------

PR: https://git.openjdk.org/jdk/pull/12956

From pchilanomate at openjdk.org  Fri Mar 10 17:11:18 2023
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 10 Mar 2023 17:11:18 GMT
Subject: RFR: 8303908: Add missing check in
 VTMS_transition_disable_for_all() for suspend mode
In-Reply-To: <fY6ySkv20W_RnUGpkuiUMoQvWUm0f4-Hle_jIkGigs8=.16dfee6f-7dd9-41e0-8c10-a161b6671d1b@github.com>
References: <MW-CIeSI8D3Opes0-cjiBHbvBuuUfKxhrZoEpRPylCg=.19babd2e-b3c6-48f7-a6ab-7d38f3211507@github.com>
 <fY6ySkv20W_RnUGpkuiUMoQvWUm0f4-Hle_jIkGigs8=.16dfee6f-7dd9-41e0-8c10-a161b6671d1b@github.com>
Message-ID: <cigXARkToGc1ci1aRfGlu4PDFr7bfUi2CW3lDcKfnFs=.aba492f9-895c-4712-8ac1-877d252096af@github.com>

On Fri, 10 Mar 2023 04:34:13 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review this small fix. A suspender is a JvmtiVTMSTransitionDisabler monopolist, meaning VTMS_transition_disable_for_all() should not return while there is any active jvmtiVTMSTransitionDisabler. The code though is checking for active "all-disablers" but it's missing the check for active "single disablers".
>> I attached a simple reproducer to the bug which I used to test the patch. Not sure if it was worth adding a test so the patch contains just the fix.
>> 
>> Thanks,
>> Patricio
>
> src/hotspot/share/prims/jvmtiThreadState.cpp line 372:
> 
>> 370:   java_lang_Thread::dec_VTMS_transition_disable_count(vth());
>> 371:   Atomic::dec(&_VTMS_transition_disable_for_one_count);
>> 372:   if (_VTMS_transition_disable_for_one_count == 0 || _is_SR) {
> 
> Sorry I don't understand why this `_is_SR` check was removed.  I admit I can't really figure out what this field means anyway, but there is nothing in the issue description that suggests this also needs changing - and it is now different to `VTMS_transition_enable_for_all`.

A JvmtiVTMSTransitionDisabler instance that is a "single disabler" only blocks other virtual threads trying to transition or JvmtiVTMSTransitionDisabler monopolists. Both of them will check for _VTMS_transition_disable_for_one_count (the JvmtiVTMSTransitionDisabler monopolist was missing that check) so just checking when that counter is zero is enough. In fact, for a "single disabler" _is_SR is always false so that check wasn't doing anything. Yes, this is not actually needed for the fix, but when looking at which condition we use to wait and which one to notify I caught this, sorry for not explaining that part.

And looking closer at VTMS_transition_enable_for_all() now I see the check for _is_SR is not doing anything too, because if _VTMS_transition_disable_for_all_count was not zero after the decrement then this can't be a JvmtiVTMSTransitionDisabler monopolist, i.e _is_SR will be false. When a monopolist is running all other "disable all" JvmtiVTMSTransitionDisabler instances if any will be waiting in the first "while (_SR_mode)" loop in VTMS_transition_disable_for_all(), so _VTMS_transition_disable_for_all_count will be one through the monopolist run. So this should be an assert after the decrement: assert(!_is_SR || _VTMS_transition_disable_for_all_count == 0, "").

-------------

PR: https://git.openjdk.org/jdk/pull/12956

From duke at openjdk.org  Fri Mar 10 17:15:48 2023
From: duke at openjdk.org (Afshin Zafari)
Date: Fri, 10 Mar 2023 17:15:48 GMT
Subject: RFR: 8292059: Do not inline InstanceKlass::allocate_instance()
 [v4]
In-Reply-To: <ZSJBTzuC4wVuKdqSLLTgw4Pds2oX5wah0Ub6rFux_tc=.c4e2ae89-cadb-4ccd-9eee-034583cf7200@github.com>
References: <ZSJBTzuC4wVuKdqSLLTgw4Pds2oX5wah0Ub6rFux_tc=.c4e2ae89-cadb-4ccd-9eee-034583cf7200@github.com>
Message-ID: <7FX3eaP7l70pTU91DWMpuQVeDjpcekd3WUo0VFbMwow=.eb5e9998-b17d-40b7-b95e-0c28afd84f16@github.com>

> The inline and not-inline versions of the method is tested to compare the performance difference. 
> ### Test
> `make test TEST=micro:Capture0.lambda_01 MICRO="VM_OPTIONS=-XX:TieredStopAtLevel=1" `

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  8292059: Do not inline InstanceKlass::allocate_instance()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12782/files
  - new: https://git.openjdk.org/jdk/pull/12782/files/6cdd8357..fe3de0b5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12782&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12782&range=02-03

  Stats: 21 lines in 4 files changed: 2 ins; 10 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/12782.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12782/head:pull/12782

PR: https://git.openjdk.org/jdk/pull/12782

From duke at openjdk.org  Fri Mar 10 17:15:54 2023
From: duke at openjdk.org (Afshin Zafari)
Date: Fri, 10 Mar 2023 17:15:54 GMT
Subject: RFR: 8292059: Do not inline InstanceKlass::allocate_instance()
 [v3]
In-Reply-To: <hKZWJ3Wbt9Hysdx-TuLnVue3Az4HVw_z-nQUaNe7llM=.af93fff3-842a-48eb-873e-f716676427ad@github.com>
References: <ZSJBTzuC4wVuKdqSLLTgw4Pds2oX5wah0Ub6rFux_tc=.c4e2ae89-cadb-4ccd-9eee-034583cf7200@github.com>
 <7Aide4lBzCPDqqanrD8I9SsT6LXneQ8CKSU4os4lH-Q=.38f1186f-01b0-4975-ad16-fcfd4eb6c031@github.com>
 <hKZWJ3Wbt9Hysdx-TuLnVue3Az4HVw_z-nQUaNe7llM=.af93fff3-842a-48eb-873e-f716676427ad@github.com>
Message-ID: <_0vSxDffz2IQ3MAftdfuqQ5qTeV8d1yjrnS0TT2peOM=.9fdd060b-1ee9-492d-8756-bdfd7588d8ac@github.com>

On Thu, 9 Mar 2023 11:07:57 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8292059: Do not inline InstanceKlass::allocate_instance()
>
> src/hotspot/share/prims/jni.cpp line 967:
> 
>> 965: 
>> 966:   instanceOop i = InstanceKlass::allocate_instance(
>> 967:                     InstanceKlass::cast(java_lang_Class::as_Klass(JNIHandles::resolve_non_null(clazz))),
> 
> Perhaps it would be nice with a utility method to reduce some of the clutter. Just folding the `as_Klass` into a new method `instanceKlass::cast_from_oop(..)` (or just `from_oop`) would cut away a fair chunk and could be used to similar effect elsewhere (counting 21 cases where this would be applicable).

An specific RFE is created for this parameter change. The change is reverted and not in this PR anymore.

-------------

PR: https://git.openjdk.org/jdk/pull/12782

From coleenp at openjdk.org  Fri Mar 10 17:35:27 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 10 Mar 2023 17:35:27 GMT
Subject: RFR: 8292059: Do not inline InstanceKlass::allocate_instance()
 [v4]
In-Reply-To: <7FX3eaP7l70pTU91DWMpuQVeDjpcekd3WUo0VFbMwow=.eb5e9998-b17d-40b7-b95e-0c28afd84f16@github.com>
References: <ZSJBTzuC4wVuKdqSLLTgw4Pds2oX5wah0Ub6rFux_tc=.c4e2ae89-cadb-4ccd-9eee-034583cf7200@github.com>
 <7FX3eaP7l70pTU91DWMpuQVeDjpcekd3WUo0VFbMwow=.eb5e9998-b17d-40b7-b95e-0c28afd84f16@github.com>
Message-ID: <2jx5pf1wpCPJErB50jnyF7nMAPr75prYVjnYw6vpErs=.3461994b-c424-4732-aa73-3c3326bbb32d@github.com>

On Fri, 10 Mar 2023 17:15:48 GMT, Afshin Zafari <duke at openjdk.org> wrote:

>> The inline and not-inline versions of the method is tested to compare the performance difference. 
>> ### Test
>> `make test TEST=micro:Capture0.lambda_01 MICRO="VM_OPTIONS=-XX:TieredStopAtLevel=1" `
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8292059: Do not inline InstanceKlass::allocate_instance()

You need to revert the changes in jni.cpp and instanceKlass.hpp.

-------------

Changes requested by coleenp (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12782

From kbarrett at openjdk.org  Fri Mar 10 20:36:58 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 10 Mar 2023 20:36:58 GMT
Subject: RFR: 8303963: Replace various encodings of UINT/SIZE_MAX in gc
 code
In-Reply-To: <Fmc4hyR2uLTnJTKeGnpRHqMyNefCPO5POSmjdvaKFzQ=.df9059fb-10ed-48e7-ad23-5bf2f5409023@github.com>
References: <Fmc4hyR2uLTnJTKeGnpRHqMyNefCPO5POSmjdvaKFzQ=.df9059fb-10ed-48e7-ad23-5bf2f5409023@github.com>
Message-ID: <supkkzAUbuqiflzlQ717XC-Lr4QpP4AvkSIhexVkjf0=.b6028e33-2c02-4df3-9f30-5e8dc684b595@github.com>

On Fri, 10 Mar 2023 12:58:42 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this refactoring that replaces various casts in GC and more-or-less related to get all bits set in an uint/size_t with the available constants from cstdint.
> The ones in ZGC files were skipped on request.
> 
> Testing: local compilation, gha
> 
> Thanks,
>   Thomas

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12973

From kbarrett at openjdk.org  Fri Mar 10 21:10:30 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 10 Mar 2023 21:10:30 GMT
Subject: RFR: 8303900: Rename BitMap search functions [v2]
In-Reply-To: <g09LwD0eFfQb6kIVSi0KAez9RTpnhO91I3QZvpM_Rpc=.bfa7b6fb-c552-4a9d-8e28-c41251e4f2e7@github.com>
References: <g09LwD0eFfQb6kIVSi0KAez9RTpnhO91I3QZvpM_Rpc=.bfa7b6fb-c552-4a9d-8e28-c41251e4f2e7@github.com>
Message-ID: <v2JrnbRdhcYZXMkfo8H3h1rtLMA_CMYSg2hwz02OgpQ=.216d4913-36e5-408f-ab0e-8e3ca22dc306@github.com>

> Please review this renaming of the following functions in BitMap:
> 
> get_next_one_offset => find_first_set_bit
> get_next_zero_offset => find_first_clear_bit
> get_next_one_offset_aligned_right => find_first_set_bit_aligned_right
> 
> Note that ShenandoahMarkBitMap::get_next_one_offset is not being renamed.  For
> some reason that class contains a copy of a sizable chunk of the code from
> some version of BitMap.  (Not sure why it doesn't use an internal BitMapView
> rather than code copying.)
> 
> Testing:
> mach5 tier1-5

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 eight additional commits since the last revision:

 - Merge branch 'master' into find-rename
 - update gtests
 - update shenandoah uses
 - update zgc uses
 - update gc/shared uses
 - update Parallel uses
 - update G1 uses
 - rename functions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12951/files
  - new: https://git.openjdk.org/jdk/pull/12951/files/94fa65a5..c503e584

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12951&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12951&range=00-01

  Stats: 63148 lines in 577 files changed: 54630 ins; 2410 del; 6108 mod
  Patch: https://git.openjdk.org/jdk/pull/12951.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12951/head:pull/12951

PR: https://git.openjdk.org/jdk/pull/12951

From kbarrett at openjdk.org  Fri Mar 10 21:10:33 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 10 Mar 2023 21:10:33 GMT
Subject: RFR: 8303900: Rename BitMap search functions [v2]
In-Reply-To: <4GIB9OwfDN2SPR-vA9cUIN2eNhWjqxV47tBLlsoEWuM=.278dc6e2-93f6-438d-8938-8bf0f35c5599@github.com>
References: <g09LwD0eFfQb6kIVSi0KAez9RTpnhO91I3QZvpM_Rpc=.bfa7b6fb-c552-4a9d-8e28-c41251e4f2e7@github.com>
 <4GIB9OwfDN2SPR-vA9cUIN2eNhWjqxV47tBLlsoEWuM=.278dc6e2-93f6-438d-8938-8bf0f35c5599@github.com>
Message-ID: <eUIy1H8S7c6Uos7JVvzeOnh-sR2eIKIZpSLJRTid45w=.b88fee8c-f56f-4d3c-bbcd-fef0ca1f2105@github.com>

On Thu, 9 Mar 2023 18:01:57 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> 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 eight additional commits since the last revision:
>> 
>>  - Merge branch 'master' into find-rename
>>  - update gtests
>>  - update shenandoah uses
>>  - update zgc uses
>>  - update gc/shared uses
>>  - update Parallel uses
>>  - update G1 uses
>>  - rename functions
>
> Looks good.

Thanks for reviews @stefank and @xmas92

-------------

PR: https://git.openjdk.org/jdk/pull/12951

From kbarrett at openjdk.org  Fri Mar 10 21:20:56 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 10 Mar 2023 21:20:56 GMT
Subject: Integrated: 8303900: Rename BitMap search functions
In-Reply-To: <g09LwD0eFfQb6kIVSi0KAez9RTpnhO91I3QZvpM_Rpc=.bfa7b6fb-c552-4a9d-8e28-c41251e4f2e7@github.com>
References: <g09LwD0eFfQb6kIVSi0KAez9RTpnhO91I3QZvpM_Rpc=.bfa7b6fb-c552-4a9d-8e28-c41251e4f2e7@github.com>
Message-ID: <q9vQxdxYIS0Wktw3yQhXlne6GIMemhH-fLvf2x5TUu4=.b9b3e159-af6e-4f36-83eb-46c03e157ff4@github.com>

On Thu, 9 Mar 2023 15:34:05 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this renaming of the following functions in BitMap:
> 
> get_next_one_offset => find_first_set_bit
> get_next_zero_offset => find_first_clear_bit
> get_next_one_offset_aligned_right => find_first_set_bit_aligned_right
> 
> Note that ShenandoahMarkBitMap::get_next_one_offset is not being renamed.  For
> some reason that class contains a copy of a sizable chunk of the code from
> some version of BitMap.  (Not sure why it doesn't use an internal BitMapView
> rather than code copying.)
> 
> Testing:
> mach5 tier1-5

This pull request has now been integrated.

Changeset: 21169285
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2116928528c0554b2ba0171bd7968ab693972804
Stats:     75 lines in 12 files changed: 0 ins; 0 del; 75 mod

8303900: Rename BitMap search functions

Reviewed-by: stefank, aboldtch

-------------

PR: https://git.openjdk.org/jdk/pull/12951

From jvernee at openjdk.org  Sat Mar 11 02:23:24 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Sat, 11 Mar 2023 02:23:24 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v3]
In-Reply-To: <mknfp22D3MdgwuitW4rYeIdz2S43a8wQdSmLerF2yO0=.94e5cf61-b2b8-41f3-b44e-0bde47b33bfc@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com>
 <HT8kQfjS98dYHeAMcNL5latokRiw3YK8npxl5yCD4hw=.28b19bac-cbfa-4461-a1db-c899c55b7485@github.com>
 <wBVqRDFM23KM8fjjPtUFNdW56FYsSpvOAVvHmpdjbzo=.7c429606-ac19-4f36-8e25-459534983924@github.com>
 <QMh_faUf_LLUf68WrZiFxmPHiFcHDBfKDg3g-oekBeg=.096acd06-65c4-4357-ad4a-4089b5478fff@github.com>
 <hJkc1ozy4f7BIvXZ_xQ3HRttVsBs0ceUIMmq4cDWrzQ=.bc3223f5-cb33-46c7-9708-ab40ba5943b0@github.com>
 <mknfp22D3MdgwuitW4rYeIdz2S43a8wQdSmLerF2yO0=.94e5cf61-b2b8-41f3-b44e-0bde47b33bfc@github.com>
Message-ID: <AOvm3Axl3yZLOa-A0ikaRQY7el-CsXTm0TJyNx-gkQk=.9d4cf018-f0a3-49d3-ad0d-d3018725fccf@github.com>

On Thu, 9 Mar 2023 17:40:02 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> @TheRealMDoerr I've moved the support for structs/unions that are not a power of 2 in size to this repo, so you should be able to merge the master branch to get it now.
>
> @JornVernee: Thanks! I've merged in your changes. TestArrayStructs is not yet completely working. I will need to investigate. I think I've done most other things you had requested. You may want to take a look at my recent commits.

@TheRealMDoerr I've been keeping up with the changes you're making. I just have to look at the new test for HFA's you've added you added (next week).

Besides fixing the TestArrayStructs test, do you have anything else you still want to add to this PR?

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From jvernee at openjdk.org  Sat Mar 11 02:23:25 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Sat, 11 Mar 2023 02:23:25 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v3]
In-Reply-To: <YkhWKXHt2GFUUiP-ausNrlugie2UlaDAfs2k4vlrjWY=.16c04132-6156-4069-9160-1703d8d2c3cf@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com>
 <ubsdQFbNzTtdhNeZwCJyA5BRc2mR4AmQwk6hgJOlBy0=.6974c426-eeb2-4212-8038-9a8e00a0e7de@github.com>
 <mo8rpizKpaAts6jpIZaQjgBZkCZE7uZaxaBW2j6mNxw=.4834669e-db31-4989-85d1-8bf94aabf651@github.com>
 <YkhWKXHt2GFUUiP-ausNrlugie2UlaDAfs2k4vlrjWY=.16c04132-6156-4069-9160-1703d8d2c3cf@github.com>
Message-ID: <0RrqDfVTh0EmUK3xCInQa1gXbZwdLpd_jY-3TYgdqwo=.e1ca03f4-8e66-4d3d-97f2-59f5bbd7287b@github.com>

On Fri, 3 Mar 2023 10:59:32 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Thanks! I need to find extra time for this. Sounds like a good idea and I may be able to get rid of some nasty code.
>
> Done by https://github.com/openjdk/jdk/pull/12708/commits/98e242c24c07ea977b7709b9f8d0c10ce87e84c0 (using a record instead of a `VMStorage[][]` because I think this is better readable). Note that it's a bit more complicated. I couldn't use your `dup` trick, because I need to put the value into a GP reg and one half of it to a FP reg. The Panama code doesn't support that (IllegalArgumentException: Invalid operand type: interface java.lang.foreign.MemorySegment. float expected).

Thanks, your solution looks good.

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From iklam at openjdk.org  Sat Mar 11 02:34:22 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 11 Mar 2023 02:34:22 GMT
Subject: RFR: 8301136: Improve unlink() and unlink_all() of
 ResourceHashtableBase [v5]
In-Reply-To: <9GAFUt_y36yObC0oOhzxNC05Y8Ja_fkUPxvhZCuFSPY=.255df6aa-d417-4277-9799-a9208e758158@github.com>
References: <Tqq1KY1B3iGRAVtESg4dEOP6cVZWkLVU6Rc_pHh9Uwo=.d2581151-724d-4e38-a24d-a78b94332356@github.com>
 <Jx-iXszYbBusmtlnUjn7Hq6kg5ppQooErA80Oq4A0Hk=.63d3eea6-c154-48a3-ab7b-a269cd02ba27@github.com>
 <9GAFUt_y36yObC0oOhzxNC05Y8Ja_fkUPxvhZCuFSPY=.255df6aa-d417-4277-9799-a9208e758158@github.com>
Message-ID: <teLkahf1KOEkLZCD4buDdywUaLV8HeDEFw1odDBWlA4=.757b5c40-bcbb-497d-a5f8-452848b5b4c6@github.com>

On Sun, 29 Jan 2023 06:41:10 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add lambda API unlink(Function f) per reviewers' request.
>
> I updated [JDK-8301296](https://bugs.openjdk.org/browse/JDK-8301296) to clarify the problems with the current ResourceHashtable design and my proposal for fixing them.
> 
> I think the above proposed fixes shouldn't block the progress of this PR, which is just an optimization that maintains the current behavior. So let's continue the discussions here.
> 
> There are two parts of this PR:
> 
> [1] For the optimization (counting the number of entries and exit the loop early), do you have any performance data that shows this is beneficial?
> 
> For this optimization to be beneficial, we must have two conditions -- (a) the table is too large so it's likely to have many unused entries, and (b) the hash function is bad so most of the unused entries are at the end of the table.
> 
> For (a), maybe it's better to change the table to ResizeableResourceHashtable?
> For (b), maybe you can also print out the occupancy of the table in your traces like this one (in your earlier PR https://github.com/openjdk/jdk/pull/12016)
> 
> 
> [12.824s][debug][hashtables] table_size = 109, break at 68
> 
> 
> If we have many entries (e.g., 40) but they all pack to the front end of the table, that means we have a bad hash function.
> 
> [2] As I suggested earlier, we should consolidate the code to use a single unlink loop, so you can apply this counting optimization in a single place. 
> 
> I am not quite sure why you would need the following in your "wrapper" functions:
> 
> 
> if (clean) {
>   *ptr = node->_next;
> } else {
>   ptr = &(node->_next);
> }
> 
> 
> and
> 
> 
> if (node->_next == nullptr) {
>   // nullify the bucket when reach the end of linked list.
>   *ptr = nullptr;
> }
> 
> 
> I wrote a version of the consolidated loop that's much simpler. It also aligns with the old code so the diff is more readable:
> 
> https://github.com/openjdk/jdk/compare/master...iklam:jdk:8301136-resource-hash-unlink-all-suggestion
> 
> Note that I have both `unlink_all()` and `unlink_all(Function function)`, that's because the current API allows the user function to do two things (a) check if the entry should be freed, (b) perform special clean up on the entry. So if you want to free all entries but need to perform special clean up, you'd call  `unlink_all(Function function)`.

> @iklam
> 
> Like you said, I mixed up 2 things. My real intention is to introduce a new api `unlink_all()` because I used it in my project.
> 
> I understand that you want me to refactor unlink(Iterator) using lambda. In order to have an efficient unlink_all() and dtor, I have to factor out unlink_impl(). It's private and acts as the algorithmic template.
> 
> What should I do now? Should I split this JBS issue into 2? One is for the optimization and the other one for "unlink_all()"? that would make thing easier to review.
> 
> thanks, --lx

I think it?s best to split this PR into two. We can first address the unlink_all issue and do the refactoring in a subsequent PR. Thanks

-------------

PR: https://git.openjdk.org/jdk/pull/12213

From stuefe at openjdk.org  Sat Mar 11 14:35:35 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 11 Mar 2023 14:35:35 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v21]
In-Reply-To: <hR80_9dU9pp0SnN8q-qZ7aG-_YWFST6O6EXQZ_pNjPk=.0f0cbf74-2890-4bd5-88ba-fbe4be92764a@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <hR80_9dU9pp0SnN8q-qZ7aG-_YWFST6O6EXQZ_pNjPk=.0f0cbf74-2890-4bd5-88ba-fbe4be92764a@github.com>
Message-ID: <0Ui89e1xMwZGBUG7hiyTfpr7FD9lJ5sXJJZg846XG54=.2f7843f0-f62b-43d1-8f4a-f21db7cc3666@github.com>

On Fri, 10 Mar 2023 12:45:12 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>  - Use nullptr instead of NULL in touched code (shared)

I'm looking into the arm32 port.

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From jwaters at openjdk.org  Sat Mar 11 14:36:26 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 11 Mar 2023 14:36:26 GMT
Subject: RFR: 8274400: HotSpot Style Guide should permit use of alignof
 [v7]
In-Reply-To: <MLS7e4TbsXZl7RhPNDovTRzpP0BEJ0mPs2hpN0yhXlM=.2842d370-0fbc-49a6-a44b-ecfe868ea182@github.com>
References: <3IdeZGaGcFB1-DbVugn0P9v8vRQMLURzHFRSpAm46NA=.09bf4dd8-b652-49c3-b9a5-ad3f58dfbcc3@github.com>
 <ftmYL9ARvHkRRD0hHspM75ttcSUm7jSBhzTJ4D0SRF0=.6f071ce4-30f4-4ad3-987a-ecfe0c242226@github.com>
 <xkZdJ9JhuDi3rL5k3-eTbI58ALs3Srzgzz6E5wJUkJY=.cec251e2-06dc-4e42-ae6c-68d18081ba68@github.com>
 <VVJXCkqPxaRJdnYzpQnA-8e3xbhTaVY31JGeEAvPEnU=.5d7c0cbe-23a5-4278-b7bf-71185bdce610@github.com>
 <MLS7e4TbsXZl7RhPNDovTRzpP0BEJ0mPs2hpN0yhXlM=.2842d370-0fbc-49a6-a44b-ecfe868ea182@github.com>
Message-ID: <ET1SlZEL1Vj57XKoKgKBqRDO2ADWp5J0kGBsJksUPSQ=.77ff1b0c-180e-4e9a-aa8f-13a5de42dbc8@github.com>

On Thu, 9 Mar 2023 20:21:33 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>>> This has been open and stable for a while. Anyone else?
>> 
>> Also if there is anyone else coming to review this, consider looking at https://github.com/openjdk/jdk/pull/11431 as well, it's also been collecting dust for quite a while too ;-;
>
> @TheShermanTanker - this is ready to be integrated, as it has been approved by @vnkozlov (HotSpot lead).

@kimbarrett Oh, my mistake, will push in a moment. In the meantime, is it ok if I ask how to progress with [8250269: Replace ATTRIBUTE_ALIGNED with alignas](https://github.com/openjdk/jdk/pull/11431)?

-------------

PR: https://git.openjdk.org/jdk/pull/11761

From jwaters at openjdk.org  Sat Mar 11 14:40:31 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 11 Mar 2023 14:40:31 GMT
Subject: RFR: 8303810: Restore attribute positions after JDK-8303839 to
 match JDK-8302124 [v3]
In-Reply-To: <iii6piYafXSVnOrWTyqY6HivGhSd4Mvtg5SKcpC5icQ=.153e1f72-8986-42f9-8af5-025cfd40b76d@github.com>
References: <J6UWvKQHQtTqoqh5udTU6RNg7XkhSrC6D73O61sgW5M=.9bed1df4-c1be-47ac-81b0-e2c0ba3f3e58@github.com>
 <iii6piYafXSVnOrWTyqY6HivGhSd4Mvtg5SKcpC5icQ=.153e1f72-8986-42f9-8af5-025cfd40b76d@github.com>
Message-ID: <X7FdHmGmIJFGKyePrE_f4r6t85-Tb4Gn9haFwtjqlOE=.6d7f229e-fabd-4c70-ac8d-05e74b3f4b4b@github.com>

On Thu, 9 Mar 2023 11:54:44 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> [JDK-8303839](https://bugs.openjdk.org/browse/JDK-8303839)'s revert of [[noreturn]] attributes also moved their already existing attributes back to behind their corresponding methods, they should be restored to where [JDK-8302124](https://bugs.openjdk.org/browse/JDK-8302124) requires them to be. Also fixes attribute from [JDK-8292269](https://bugs.openjdk.org/browse/JDK-8292269)
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   debug.hpp

Alright

-------------

PR: https://git.openjdk.org/jdk/pull/12918

From jwaters at openjdk.org  Sat Mar 11 14:40:34 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 11 Mar 2023 14:40:34 GMT
Subject: Integrated: 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: <q0J63ceOm1eC2eB_vsLABofM5fMD2LXZpEIVVb1md_4=.ab16efae-7705-4205-9519-074a65d29a05@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.

This pull request has now been integrated.

Changeset: a06426a5
Author:    Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a06426a52f16c08c95b1c0270a5fc40721921022
Stats:     18 lines in 2 files changed: 16 ins; 0 del; 2 mod

8274400: HotSpot Style Guide should permit use of alignof

Reviewed-by: kbarrett, kvn, dholmes, dcubed

-------------

PR: https://git.openjdk.org/jdk/pull/11761

From jwaters at openjdk.org  Sat Mar 11 14:40:33 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 11 Mar 2023 14:40:33 GMT
Subject: Withdrawn: 8303810: Restore attribute positions after JDK-8303839 to
 match JDK-8302124
In-Reply-To: <J6UWvKQHQtTqoqh5udTU6RNg7XkhSrC6D73O61sgW5M=.9bed1df4-c1be-47ac-81b0-e2c0ba3f3e58@github.com>
References: <J6UWvKQHQtTqoqh5udTU6RNg7XkhSrC6D73O61sgW5M=.9bed1df4-c1be-47ac-81b0-e2c0ba3f3e58@github.com>
Message-ID: <6nQIo08AWqpAXCLVOr30cO8O5FtizMZc7sp8fu94TRY=.c85be9a6-ba66-49d5-ad89-77e7d60cc936@github.com>

On Wed, 8 Mar 2023 08:39:08 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> [JDK-8303839](https://bugs.openjdk.org/browse/JDK-8303839)'s revert of [[noreturn]] attributes also moved their already existing attributes back to behind their corresponding methods, they should be restored to where [JDK-8302124](https://bugs.openjdk.org/browse/JDK-8302124) requires them to be. Also fixes attribute from [JDK-8292269](https://bugs.openjdk.org/browse/JDK-8292269)

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/12918

From jwaters at openjdk.org  Sat Mar 11 14:55:56 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 11 Mar 2023 14:55:56 GMT
Subject: RFR: 8301244: Tidy up compiler specific warnings files [v9]
In-Reply-To: <CU3GjASmLJw11Olusd1w5qnl-zb_d1hjVewzVEn3BS0=.277f1a89-0731-41ee-bad8-e15a57a826a4@github.com>
References: <CU3GjASmLJw11Olusd1w5qnl-zb_d1hjVewzVEn3BS0=.277f1a89-0731-41ee-bad8-e15a57a826a4@github.com>
Message-ID: <ckk939lMwKOHnWoaCjaQpxHH4TxBUYuHJr35Bu2bnmA=.aa60e22b-f5f7-43bd-8791-685a0e9353cd@github.com>

> Cleans up some code in compilerWarnings_*.hpp files to be slightly neater

Julian Waters has updated the pull request incrementally with four additional commits since the last revision:

 - compilerWarnings_visCPP.hpp
 - Spelling
 - compilerWarnings_gcc.hpp
 - macros.hpp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12255/files
  - new: https://git.openjdk.org/jdk/pull/12255/files/8ba0ff35..30561ee1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12255&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12255&range=07-08

  Stats: 9 lines in 3 files changed: 0 ins; 3 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/12255.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12255/head:pull/12255

PR: https://git.openjdk.org/jdk/pull/12255

From jwaters at openjdk.org  Sat Mar 11 15:12:22 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 11 Mar 2023 15:12:22 GMT
Subject: RFR: 8301244: Tidy up compiler specific warnings files [v9]
In-Reply-To: <ckk939lMwKOHnWoaCjaQpxHH4TxBUYuHJr35Bu2bnmA=.aa60e22b-f5f7-43bd-8791-685a0e9353cd@github.com>
References: <CU3GjASmLJw11Olusd1w5qnl-zb_d1hjVewzVEn3BS0=.277f1a89-0731-41ee-bad8-e15a57a826a4@github.com>
 <ckk939lMwKOHnWoaCjaQpxHH4TxBUYuHJr35Bu2bnmA=.aa60e22b-f5f7-43bd-8791-685a0e9353cd@github.com>
Message-ID: <L2h1X9anWmVVYHxPyDnW816lo4OkRBLmfH9tREYBiz8=.3a23f135-75ba-4070-8908-187dd8392e2c@github.com>

On Sat, 11 Mar 2023 14:55:56 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Cleans up some code in compilerWarnings_*.hpp files to be slightly neater
>
> Julian Waters has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - compilerWarnings_visCPP.hpp
>  - Spelling
>  - compilerWarnings_gcc.hpp
>  - macros.hpp

Alright, in that case I'll simply ditch the PRAGMA utility and simply have this as a tidying up for both compilerWarnings.hpp files

-------------

PR: https://git.openjdk.org/jdk/pull/12255

From stuefe at openjdk.org  Sat Mar 11 15:17:30 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 11 Mar 2023 15:17:30 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v21]
In-Reply-To: <hR80_9dU9pp0SnN8q-qZ7aG-_YWFST6O6EXQZ_pNjPk=.0f0cbf74-2890-4bd5-88ba-fbe4be92764a@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <hR80_9dU9pp0SnN8q-qZ7aG-_YWFST6O6EXQZ_pNjPk=.0f0cbf74-2890-4bd5-88ba-fbe4be92764a@github.com>
Message-ID: <9Z5c4yco0VZ_8emD3C43P3LYtJfItTHkRyj9MCsKcNg=.b4342519-99bb-45d0-8d4b-169624e3ff2d@github.com>

On Fri, 10 Mar 2023 12:45:12 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>  - Use nullptr instead of NULL in touched code (shared)

Proposal for omitting the lockstack size check (at least in 75% of all times):

- We know that Thread as well as grown lockstack backing buffers start at malloc-aligned boundaries. Practically this is 16 (64-bit), 4-8 (32-bit). So at the very least 4.

- Make the initial lockstack this size. Define it so that initial slot stack starts at offset 0.

- Load the current slot pointer as you do now. Check the lowest 2 bits. If all are zero, go the slower path (load the current limit and compare against limit, ...).

- If bit 0 or 1 are set, you can omit this check. You are done since you have not yet reached the limit.

- You can expand this proposal to any alignment you like. You need to declare the lockstack slots with `alignof(X)`, and the compiler will take care that the *initial* slot stack is always well aligned. As for larger slot stacks, we will have to allocate them in an aligned fashion using posix_memalign (we need this as NMT-wrapped version, but thats trivial)

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From rkennke at openjdk.org  Sat Mar 11 16:00:33 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Sat, 11 Mar 2023 16:00:33 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v21]
In-Reply-To: <hR80_9dU9pp0SnN8q-qZ7aG-_YWFST6O6EXQZ_pNjPk=.0f0cbf74-2890-4bd5-88ba-fbe4be92764a@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <hR80_9dU9pp0SnN8q-qZ7aG-_YWFST6O6EXQZ_pNjPk=.0f0cbf74-2890-4bd5-88ba-fbe4be92764a@github.com>
Message-ID: <w0SwXcFUdJ_7kmspME8BhYJ6cUGvt5wA9VTGrvt5n5U=.cc2cef43-bfd2-4a85-ad41-9078917f4577@github.com>

On Fri, 10 Mar 2023 12:45:12 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>  - Use nullptr instead of NULL in touched code (shared)

> Proposal for omitting the lockstack size check (at least in 75% of all times):
> 
> * We know that Thread as well as grown lockstack backing buffers start at malloc-aligned boundaries. Practically this is 16 (64-bit), 4-8 (32-bit). So at the very least 4.
> * Make the initial lockstack this size. Define it so that initial slot stack starts at offset 0.
> * Load the current slot pointer as you do now. Check the lowest 2 bits. If all are zero, go the slower path (load the current limit and compare against limit, ...).
> * If bit 0 or 1 are set, you can omit this check. You are done since you have not yet reached the limit.
> * You can expand this proposal to any alignment you like. You need to declare the lockstack slots with `alignof(X)`, and the compiler will take care that the _initial_ slot stack is always well aligned. As for larger slot stacks, we will have to allocate them in an aligned fashion using posix_memalign (we need this as NMT-wrapped version, but thats trivial)

This would only work when pushing a single slot, right? Have you seen what we're doing in the compiled (C1 and C2) paths (in x86_64 and aarch64)? There we're doing a (conservative) estimate how many lock-slots are needed in the method, and check for enough slots upon method entry once, and then elide the check altogether in the lock-enter implementation.

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From stuefe at openjdk.org  Sat Mar 11 16:14:30 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 11 Mar 2023 16:14:30 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v21]
In-Reply-To: <w0SwXcFUdJ_7kmspME8BhYJ6cUGvt5wA9VTGrvt5n5U=.cc2cef43-bfd2-4a85-ad41-9078917f4577@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <hR80_9dU9pp0SnN8q-qZ7aG-_YWFST6O6EXQZ_pNjPk=.0f0cbf74-2890-4bd5-88ba-fbe4be92764a@github.com>
 <w0SwXcFUdJ_7kmspME8BhYJ6cUGvt5wA9VTGrvt5n5U=.cc2cef43-bfd2-4a85-ad41-9078917f4577@github.com>
Message-ID: <6JDIBigQkgXxOQDE0UEeZhX8ountKQAliKpynUVzcbY=.abf3a7f5-6744-437c-aee0-86a197248a62@github.com>

On Sat, 11 Mar 2023 15:57:53 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> > Proposal for omitting the lockstack size check (at least in 75% of all times):
> > 
> > * We know that Thread as well as grown lockstack backing buffers start at malloc-aligned boundaries. Practically this is 16 (64-bit), 4-8 (32-bit). So at the very least 4.
> > * Make the initial lockstack this size. Define it so that initial slot stack starts at offset 0.
> > * Load the current slot pointer as you do now. Check the lowest 2 bits. If all are zero, go the slower path (load the current limit and compare against limit, ...).
> > * If bit 0 or 1 are set, you can omit this check. You are done since you have not yet reached the limit.
> > * You can expand this proposal to any alignment you like. You need to declare the lockstack slots with `alignof(X)`, and the compiler will take care that the _initial_ slot stack is always well aligned. As for larger slot stacks, we will have to allocate them in an aligned fashion using posix_memalign (we need this as NMT-wrapped version, but thats trivial)
> 
> This would only work when pushing a single slot, right? Have you seen what we're doing in the compiled (C1 and C2) paths (in x86_64 and aarch64)? There we're doing a (conservative) estimate how many lock-slots are needed in the method, and check for enough slots upon method entry once, and then elide the check altogether in the lock-enter implementation.

Yeah, I just realized this myself. I started working on the template interpreter first, where we push single stack slots. There it may still make sense.

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From stuefe at openjdk.org  Sat Mar 11 16:30:38 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 11 Mar 2023 16:30:38 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v21]
In-Reply-To: <hR80_9dU9pp0SnN8q-qZ7aG-_YWFST6O6EXQZ_pNjPk=.0f0cbf74-2890-4bd5-88ba-fbe4be92764a@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <hR80_9dU9pp0SnN8q-qZ7aG-_YWFST6O6EXQZ_pNjPk=.0f0cbf74-2890-4bd5-88ba-fbe4be92764a@github.com>
Message-ID: <7265U-aASDjFX1CMrbxDZZCPHrYJkufD1QDFBuB1WSA=.623488a7-9ede-4ec2-b840-1e5601a9b97a@github.com>

On Fri, 10 Mar 2023 12:45:12 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>  - Use nullptr instead of NULL in touched code (shared)

Not a full review, just stuff I stumbled over while looking into the arm port.

General notes:

I dislike the "Fast" moniker for UseFastLocking. Old thin locks were not particularly slow either. Also, I believe I have seen places where "fast locking/unlocking" were used before to describe stackbased locking. 

Can we name this something like "NewStyleThinLocks" or similar?

src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 821:

> 819:     call_VM(noreg,
> 820:             CAST_FROM_FN_PTR(address, InterpreterRuntime::monitorenter),
> 821:             UseFastLocking ? obj_reg : lock_reg);

The first call to InterpreterRuntime::monitorenter, under UseHeavyMonitors: Please add assert for !UseFastLocking.

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 6234:

> 6232: 
> 6233:   // Load (object->mark() | 1) into hdr
> 6234:   orr(hdr, hdr, markWord::unlocked_value);

I wondered why this is needed. Should we not have the header of an unloaded object in hdr? Or is this a safeguard against a misuse of this function (called with the header of an already locked object)?

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 6246:

> 6244:   str(obj, Address(t1, 0));
> 6245:   add(t1, t1, oopSize);
> 6246:   str(t1, Address(rthread, JavaThread::lock_stack_current_offset()));

This, and its counterpart pop, may be worth factoring out

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 6267:

> 6265:   ldr(t1, Address(rthread, JavaThread::lock_stack_current_offset()));
> 6266:   sub(t1, t1, oopSize);
> 6267:   str(t1, Address(rthread, JavaThread::lock_stack_current_offset()));

good comments, helpful

src/hotspot/share/opto/c2_CodeStubs.hpp line 89:

> 87: };
> 88: 
> 89: class C2CheckLockStackStub : public C2CodeStub {

Badly named, please reconsider. This does not check the lock stack, it grows it. "Check" sounds like a non-modifying state verification.

Proposal: C2EnsureLockStackSizeStub

src/hotspot/share/runtime/globals.hpp line 1983:

> 1981:                                                                             \
> 1982:   product(bool, UseFastLocking, false, EXPERIMENTAL,                        \
> 1983:                 "Use fast-locking instead of stack-locking")                \

Please ergo-disable this for UseHeavyMonitors. One less thing to think about.

src/hotspot/share/runtime/lockStack.hpp line 46:

> 44:   void grow(size_t min_capacity);
> 45: 
> 46:   void validate(const char* msg) const PRODUCT_RETURN;

nit: these functions seem normally to be called "verify"

src/hotspot/share/runtime/lockStack.hpp line 52:

> 50:   static ByteSize limit_offset()      { return byte_offset_of(LockStack, _limit); }
> 51: 
> 52:   static void ensure_lock_stack_size(oop* _required_limit);

I would split this, do the comparison inline, only the actual growth in the cpp file.

src/hotspot/share/runtime/lockStack.hpp line 64:

> 62: 
> 63:   // GC support
> 64:   inline void oops_do(OopClosure* cl);

Does this need to be nonconst?

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From duke at openjdk.org  Sat Mar 11 16:31:06 2023
From: duke at openjdk.org (Afshin Zafari)
Date: Sat, 11 Mar 2023 16:31:06 GMT
Subject: RFR: 8292059: Do not inline InstanceKlass::allocate_instance()
 [v5]
In-Reply-To: <ZSJBTzuC4wVuKdqSLLTgw4Pds2oX5wah0Ub6rFux_tc=.c4e2ae89-cadb-4ccd-9eee-034583cf7200@github.com>
References: <ZSJBTzuC4wVuKdqSLLTgw4Pds2oX5wah0Ub6rFux_tc=.c4e2ae89-cadb-4ccd-9eee-034583cf7200@github.com>
Message-ID: <0mRQdiYkOqYL4mvfGOiUrsFGDUgTq_FMbBrV9DmBZWo=.1630b1b8-31e9-4f76-9b1e-e202711c8714@github.com>

> The inline and not-inline versions of the method is tested to compare the performance difference. 
> ### Test
> `make test TEST=micro:Capture0.lambda_01 MICRO="VM_OPTIONS=-XX:TieredStopAtLevel=1" `

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  8292059: Do not inline InstanceKlass::allocate_instance()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12782/files
  - new: https://git.openjdk.org/jdk/pull/12782/files/fe3de0b5..0ef3159a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12782&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12782&range=03-04

  Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12782.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12782/head:pull/12782

PR: https://git.openjdk.org/jdk/pull/12782

From duke at openjdk.org  Sat Mar 11 16:32:23 2023
From: duke at openjdk.org (Afshin Zafari)
Date: Sat, 11 Mar 2023 16:32:23 GMT
Subject: RFR: 8292059: Do not inline InstanceKlass::allocate_instance()
 [v4]
In-Reply-To: <2jx5pf1wpCPJErB50jnyF7nMAPr75prYVjnYw6vpErs=.3461994b-c424-4732-aa73-3c3326bbb32d@github.com>
References: <ZSJBTzuC4wVuKdqSLLTgw4Pds2oX5wah0Ub6rFux_tc=.c4e2ae89-cadb-4ccd-9eee-034583cf7200@github.com>
 <7FX3eaP7l70pTU91DWMpuQVeDjpcekd3WUo0VFbMwow=.eb5e9998-b17d-40b7-b95e-0c28afd84f16@github.com>
 <2jx5pf1wpCPJErB50jnyF7nMAPr75prYVjnYw6vpErs=.3461994b-c424-4732-aa73-3c3326bbb32d@github.com>
Message-ID: <8uKidgmfe4DIvzbGilcwcCp4gvxWclNOosj_pQa5bpc=.33aefbc3-5328-493e-917c-d984e55d5f18@github.com>

On Fri, 10 Mar 2023 17:31:58 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> You need to revert the changes in jni.cpp and instanceKlass.hpp.

They are reverted.

-------------

PR: https://git.openjdk.org/jdk/pull/12782

From stuefe at openjdk.org  Sat Mar 11 16:37:24 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 11 Mar 2023 16:37:24 GMT
Subject: RFR: JDK-8303861: Error handling step timeouts should never be
 blocked by OnError and others [v2]
In-Reply-To: <yPypi4QYuc9hQwXnQTZEV67UFUq8JC9VwYqc-IPjqC4=.b51df4fc-3100-483c-b819-a9f1aa0731ed@github.com>
References: <MsoamxpcF7RfrdiX5BXcHcluFN6HqcIZwwLedCUSQck=.8f187897-f3b4-46b8-9811-faba5d2e0b7b@github.com>
 <FVO8BPbYbbOlrFQhTESwAOM4TifV2UQeF2nk6A2NCx4=.de3bf2b9-59a9-4df8-af8a-7550451a85db@github.com>
 <yPypi4QYuc9hQwXnQTZEV67UFUq8JC9VwYqc-IPjqC4=.b51df4fc-3100-483c-b819-a9f1aa0731ed@github.com>
Message-ID: <1lMEsynz434ly8ccXRxooqKSnAoo-fLV7V3XYCubq5w=.45f5a9a8-6034-4c84-8b20-bb8d93194d86@github.com>

On Fri, 10 Mar 2023 14:54:20 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   limit step timeout to 5 seconds max
>
> src/hotspot/share/utilities/vmError.cpp line 1787:
> 
>> 1785:   // Global timeout hit?
>> 1786:   if (!ignore_global_timeout) {
>> 1787:     const jlong reporting_start_time_l = get_reporting_start_time();
> 
> What is the meaning of _l here? Is it to indicate the type of the variable? If so, I would suggest to remove it. (I know it is pre-existing. I leave this up to you.)

This is a remnant of the old implementation. I'll change it.

-------------

PR: https://git.openjdk.org/jdk/pull/12936

From stuefe at openjdk.org  Sat Mar 11 16:44:05 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 11 Mar 2023 16:44:05 GMT
Subject: RFR: JDK-8303861: Error handling step timeouts should never be
 blocked by OnError and others [v3]
In-Reply-To: <MsoamxpcF7RfrdiX5BXcHcluFN6HqcIZwwLedCUSQck=.8f187897-f3b4-46b8-9811-faba5d2e0b7b@github.com>
References: <MsoamxpcF7RfrdiX5BXcHcluFN6HqcIZwwLedCUSQck=.8f187897-f3b4-46b8-9811-faba5d2e0b7b@github.com>
Message-ID: <bA8hVz2krBgarFLwu8d6e6Vj0b4gke9f1DObN2XQVks=.9b968b7f-e7c3-4f47-bb6f-e6c586356264@github.com>

> Fatal error handling is subject to several timeouts:
> - a global timeout (controlled via ErrorLogTimeout)
> - local error reporting step timeouts.
> 
> The latter aims to "give the JVM a kick" if it gets stuck in one particular place during error reporting. This prevents one error reporting step from hogging all the time allotted to error reporting under ErrorLogTimeout.
> 
> There are three situations where atm we suppress the global error timeout:
> - if the JVM is embedded and the launcher has its abort hook installed. Obviously, that must be allowed to run.
> - if the user specified one or more OnError commands to run, and these did not yet run. These must have a chance to run unmolested.
> - if the user (typically developer) specified ShowMessageBoxOnError, and the error box has not yet been shown
> 
> There is a bug though, that also prevents the step timeout from firing if either condition is true. That is plain wrong.
> 
> In addition to that, the test interval WatcherThread uses to check for timeouts should be decreased. It sits at 1 second, which is too coarse-grained. 
> 
> --------
> 
> Patch:
> - reworks `VMError::check_timeout()` to never block step timeouts
> - adds clarifying comments
> - quadruples timeout check frequency by watcher thread
> - adds regression test for timeout handling with OnError
> - additionally limits timeout per individual error reporting step to 5 seconds. 5 seconds is usually enough to distinguish a slow error reporting step from one that is endlessly hanging. 
> 
> Tested locally on Linux x64.

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  feedback roman

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12936/files
  - new: https://git.openjdk.org/jdk/pull/12936/files/70b9add7..2c21ac35

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12936&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12936&range=01-02

  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/12936.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12936/head:pull/12936

PR: https://git.openjdk.org/jdk/pull/12936

From stuefe at openjdk.org  Sat Mar 11 16:44:09 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 11 Mar 2023 16:44:09 GMT
Subject: RFR: JDK-8303861: Error handling step timeouts should never be
 blocked by OnError and others [v2]
In-Reply-To: <yPypi4QYuc9hQwXnQTZEV67UFUq8JC9VwYqc-IPjqC4=.b51df4fc-3100-483c-b819-a9f1aa0731ed@github.com>
References: <MsoamxpcF7RfrdiX5BXcHcluFN6HqcIZwwLedCUSQck=.8f187897-f3b4-46b8-9811-faba5d2e0b7b@github.com>
 <FVO8BPbYbbOlrFQhTESwAOM4TifV2UQeF2nk6A2NCx4=.de3bf2b9-59a9-4df8-af8a-7550451a85db@github.com>
 <yPypi4QYuc9hQwXnQTZEV67UFUq8JC9VwYqc-IPjqC4=.b51df4fc-3100-483c-b819-a9f1aa0731ed@github.com>
Message-ID: <BfG5ZOD4J0O-CwiWYk4dICLSbPYCwEevQWoYS9mRKjs=.a5873663-8ee1-4538-b01b-442f9273dabd@github.com>

On Fri, 10 Mar 2023 14:56:43 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   limit step timeout to 5 seconds max
>
> test/hotspot/jtreg/runtime/ErrorHandling/TimeoutInErrorHandlingTest.java line 40:
> 
>> 38: 
>> 39: /*
>> 40:  * @test TimeoutInErrorHandlingTest-default
> 
> Isn't the better way to name this just '@test TimeoutInErrorHandlingTest' and then '@id=default' and '@id=with-on-error' ?

Not sure what you mean? There is no @id jtreg tag. https://openjdk.org/jtreg/tag-spec.html

-------------

PR: https://git.openjdk.org/jdk/pull/12936

From kbarrett at openjdk.org  Sat Mar 11 16:54:15 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 11 Mar 2023 16:54:15 GMT
Subject: RFR: 8304016: Add BitMap find_last suite of functions
Message-ID: <uacSVrnq4wrWciqgVSQSnNp05EvZzBTfCrM08ih-KUU=.dd763e87-c71a-4e08-aa96-848420915ead@github.com>

Please review this change that adds functions to BitMap for finding the last
set/clear bit in a range.

Testing:
mach5 tier1, including new gtesting for the new functions.

-------------

Commit messages:
 - find_last_set/clear_bit

Changes: https://git.openjdk.org/jdk/pull/12988/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12988&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304016
  Stats: 216 lines in 3 files changed: 160 ins; 24 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/12988.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12988/head:pull/12988

PR: https://git.openjdk.org/jdk/pull/12988

From rkennke at openjdk.org  Sat Mar 11 16:57:27 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Sat, 11 Mar 2023 16:57:27 GMT
Subject: RFR: JDK-8303861: Error handling step timeouts should never be
 blocked by OnError and others [v2]
In-Reply-To: <BfG5ZOD4J0O-CwiWYk4dICLSbPYCwEevQWoYS9mRKjs=.a5873663-8ee1-4538-b01b-442f9273dabd@github.com>
References: <MsoamxpcF7RfrdiX5BXcHcluFN6HqcIZwwLedCUSQck=.8f187897-f3b4-46b8-9811-faba5d2e0b7b@github.com>
 <FVO8BPbYbbOlrFQhTESwAOM4TifV2UQeF2nk6A2NCx4=.de3bf2b9-59a9-4df8-af8a-7550451a85db@github.com>
 <yPypi4QYuc9hQwXnQTZEV67UFUq8JC9VwYqc-IPjqC4=.b51df4fc-3100-483c-b819-a9f1aa0731ed@github.com>
 <BfG5ZOD4J0O-CwiWYk4dICLSbPYCwEevQWoYS9mRKjs=.a5873663-8ee1-4538-b01b-442f9273dabd@github.com>
Message-ID: <ZieQiCz3hdiowTb2Du04KLBQCVy4MModXqSvw1_qKBI=.23138820-d0c5-4bdb-8e30-824b711ad6b8@github.com>

On Sat, 11 Mar 2023 16:37:21 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Not sure what you mean? There is no @id jtreg tag. https://openjdk.org/jtreg/tag-spec.html

Sorry, I got this wrong. The way to do it is @test id=$somestring. See for example:

https://github.com/openjdk/jdk/blob/a06426a52f16c08c95b1c0270a5fc40721921022/test/hotspot/jtreg/gc/stress/gcold/TestGCOldWithShenandoah.java#L27

-------------

PR: https://git.openjdk.org/jdk/pull/12936

From jwaters at openjdk.org  Sat Mar 11 17:17:06 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 11 Mar 2023 17:17:06 GMT
Subject: RFR: 8301244: Tidy up compiler specific warnings files [v10]
In-Reply-To: <CU3GjASmLJw11Olusd1w5qnl-zb_d1hjVewzVEn3BS0=.277f1a89-0731-41ee-bad8-e15a57a826a4@github.com>
References: <CU3GjASmLJw11Olusd1w5qnl-zb_d1hjVewzVEn3BS0=.277f1a89-0731-41ee-bad8-e15a57a826a4@github.com>
Message-ID: <U9c8wDcpjHF9tjYY6aUQnmZ-ATomE0BGbjFz7q0j028=.9bb506da-7e5c-4f26-8364-b8c9dda64717@github.com>

> Cleans up some code in compilerWarnings_*.hpp files to be slightly neater

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Revert to initial name

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12255/files
  - new: https://git.openjdk.org/jdk/pull/12255/files/30561ee1..a3185f7c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12255&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12255&range=08-09

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12255.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12255/head:pull/12255

PR: https://git.openjdk.org/jdk/pull/12255

From kbarrett at openjdk.org  Sat Mar 11 17:17:11 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 11 Mar 2023 17:17:11 GMT
Subject: RFR: 8301244: Tidy up compiler specific warnings files [v9]
In-Reply-To: <ckk939lMwKOHnWoaCjaQpxHH4TxBUYuHJr35Bu2bnmA=.aa60e22b-f5f7-43bd-8791-685a0e9353cd@github.com>
References: <CU3GjASmLJw11Olusd1w5qnl-zb_d1hjVewzVEn3BS0=.277f1a89-0731-41ee-bad8-e15a57a826a4@github.com>
 <ckk939lMwKOHnWoaCjaQpxHH4TxBUYuHJr35Bu2bnmA=.aa60e22b-f5f7-43bd-8791-685a0e9353cd@github.com>
Message-ID: <1_2C-gE39fNXfVNmm4mvB7Y4ACOd5icaB-1Q7-eTVJo=.12608e78-be5d-4153-9f5c-9c2c2213c6cb@github.com>

On Sat, 11 Mar 2023 14:55:56 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Cleans up some code in compilerWarnings_*.hpp files to be slightly neater
>
> Julian Waters has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - compilerWarnings_visCPP.hpp
>  - Spelling
>  - compilerWarnings_gcc.hpp
>  - macros.hpp

Changes requested by kbarrett (Reviewer).

src/hotspot/share/utilities/compilerWarnings_gcc.hpp line 37:

> 35: #endif
> 36: 
> 37: #define PRAGMA_DISABLE_GCC_WARNING(option) _Pragma(STR(GCC diagnostic ignored option))

s/option/option_string/ as before, to make it a little more obvious that the argument is a string literal.

-------------

PR: https://git.openjdk.org/jdk/pull/12255

From jwaters at openjdk.org  Sat Mar 11 17:17:12 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 11 Mar 2023 17:17:12 GMT
Subject: RFR: 8301244: Tidy up compiler specific warnings files [v9]
In-Reply-To: <1_2C-gE39fNXfVNmm4mvB7Y4ACOd5icaB-1Q7-eTVJo=.12608e78-be5d-4153-9f5c-9c2c2213c6cb@github.com>
References: <CU3GjASmLJw11Olusd1w5qnl-zb_d1hjVewzVEn3BS0=.277f1a89-0731-41ee-bad8-e15a57a826a4@github.com>
 <ckk939lMwKOHnWoaCjaQpxHH4TxBUYuHJr35Bu2bnmA=.aa60e22b-f5f7-43bd-8791-685a0e9353cd@github.com>
 <1_2C-gE39fNXfVNmm4mvB7Y4ACOd5icaB-1Q7-eTVJo=.12608e78-be5d-4153-9f5c-9c2c2213c6cb@github.com>
Message-ID: <ekRSXMeGOspXHZ6d9FpSR5md2i8DoDxUEYaH7orhykY=.7eb71465-c48a-4be4-85c8-a3f067643109@github.com>

On Sat, 11 Mar 2023 17:01:00 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - compilerWarnings_visCPP.hpp
>>  - Spelling
>>  - compilerWarnings_gcc.hpp
>>  - macros.hpp
>
> src/hotspot/share/utilities/compilerWarnings_gcc.hpp line 37:
> 
>> 35: #endif
>> 36: 
>> 37: #define PRAGMA_DISABLE_GCC_WARNING(option) _Pragma(STR(GCC diagnostic ignored option))
> 
> s/option/option_string/ as before, to make it a little more obvious that the argument is a string literal.

Alright

-------------

PR: https://git.openjdk.org/jdk/pull/12255

From dcubed at openjdk.org  Sat Mar 11 18:17:34 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Sat, 11 Mar 2023 18:17:34 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v18]
In-Reply-To: <oHxvD3hlq7rIroAMxZnpFex7AYDbwUyowWlI5hF-WG0=.264251e0-553a-40c6-a089-cf7a4e7dd77e@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <oHxvD3hlq7rIroAMxZnpFex7AYDbwUyowWlI5hF-WG0=.264251e0-553a-40c6-a089-cf7a4e7dd77e@github.com>
Message-ID: <Lv6uyhaz9CBWVOOjdBxqSYgTU8Cl3W6jKPHjoE74pvo=.4c4665ef-3c6a-4f1b-8fbc-de541ac31e4b@github.com>

On Fri, 10 Mar 2023 09:55:03 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixes in response to Daniel's review

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 684:

> 682:   xorptr(tmpReg, tmpReg);
> 683: 
> 684:   // Appears unlocked - try to swing _owner from null to curren thread.

nit typo: s/curren thread/current thread/

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From dcubed at openjdk.org  Sat Mar 11 18:45:35 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Sat, 11 Mar 2023 18:45:35 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v21]
In-Reply-To: <hR80_9dU9pp0SnN8q-qZ7aG-_YWFST6O6EXQZ_pNjPk=.0f0cbf74-2890-4bd5-88ba-fbe4be92764a@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <hR80_9dU9pp0SnN8q-qZ7aG-_YWFST6O6EXQZ_pNjPk=.0f0cbf74-2890-4bd5-88ba-fbe4be92764a@github.com>
Message-ID: <4Wi21QdftsyLGcwMc0P4ho3ZS6VZP4gP0MxWkok_gtM=.8c93b6b3-1f48-4979-833e-275278de9d98@github.com>

On Fri, 10 Mar 2023 12:45:12 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>  - Use nullptr instead of NULL in touched code (shared)

Another partial review. This time I reviewed these files:
src/hotspot/share/c1/c1_Compilation.cpp
src/hotspot/share/c1/c1_Compilation.hpp
src/hotspot/share/c1/c1_GraphBuilder.cpp
src/hotspot/share/c1/c1_LIRAssembler.cpp
src/hotspot/share/c1/c1_MacroAssembler.hpp
src/hotspot/share/c1/c1_Runtime1.cpp
src/hotspot/share/interpreter/interpreterRuntime.cpp
src/hotspot/share/opto/c2_CodeStubs.hpp
src/hotspot/share/opto/compile.cpp
src/hotspot/share/opto/compile.hpp
src/hotspot/share/opto/locknode.cpp
src/hotspot/share/opto/parse1.cpp

src/hotspot/share/opto/compile.hpp line 637:

> 635:   void          push_monitor() { _max_monitors++; }
> 636:   void          reset_max_monitors() { _max_monitors = 0; }
> 637:   uint          max_monitors() { return _max_monitors; }

The prevailing style in this file appears to have some indenting after the ')'
and before the '{'. It's somewhat inconsistent as to how much, but mostly
more than a single space.

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From dcubed at openjdk.org  Sat Mar 11 18:52:31 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Sat, 11 Mar 2023 18:52:31 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v21]
In-Reply-To: <hR80_9dU9pp0SnN8q-qZ7aG-_YWFST6O6EXQZ_pNjPk=.0f0cbf74-2890-4bd5-88ba-fbe4be92764a@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <hR80_9dU9pp0SnN8q-qZ7aG-_YWFST6O6EXQZ_pNjPk=.0f0cbf74-2890-4bd5-88ba-fbe4be92764a@github.com>
Message-ID: <ePMEDxrDJzwbsJcjY8IgAl-CK1BtokCRzxx1qLfN3Zc=.2e040424-95c3-426c-90f4-d2640b332c59@github.com>

On Fri, 10 Mar 2023 12:45:12 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>  - Use nullptr instead of NULL in touched code (shared)

I was pleasantly surprised at how few C1 and C2 changes were needed. Nice!

At this point, I have not reviewed the 'ppc', 'riscv' or s390 files so I've done a first
pass review of 63 of the 74 files. I'll have to double check that I didn't miss anything
that I need to review and I'll have to do another crawl thru review pass after letting
the code percolate in my brain for a few days without looking at it.

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From kbarrett at openjdk.org  Sun Mar 12 10:22:21 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 12 Mar 2023 10:22:21 GMT
Subject: RFR: 8301244: Tidy up compiler specific warnings files [v10]
In-Reply-To: <U9c8wDcpjHF9tjYY6aUQnmZ-ATomE0BGbjFz7q0j028=.9bb506da-7e5c-4f26-8364-b8c9dda64717@github.com>
References: <CU3GjASmLJw11Olusd1w5qnl-zb_d1hjVewzVEn3BS0=.277f1a89-0731-41ee-bad8-e15a57a826a4@github.com>
 <U9c8wDcpjHF9tjYY6aUQnmZ-ATomE0BGbjFz7q0j028=.9bb506da-7e5c-4f26-8364-b8c9dda64717@github.com>
Message-ID: <5WVBbaPCyTGUNbEr9drvxyofnDZdjPR8zVFX-sBcxuY=.05410d48-b8ae-4e0d-980b-9d8779ad15e1@github.com>

On Sat, 11 Mar 2023 17:17:06 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Cleans up some code in compilerWarnings_*.hpp files to be slightly neater
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert to initial name

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12255

From duke at openjdk.org  Sun Mar 12 13:21:18 2023
From: duke at openjdk.org (Jan Kratochvil)
Date: Sun, 12 Mar 2023 13:21:18 GMT
Subject: RFR: 8302191: Performance degradation for float/double modulo on
 Linux [v12]
In-Reply-To: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
References: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
Message-ID: <RId-BddGF5Px37EdS6jN7fen2y-UTKlPXrF88KJizq0=.e2ffd401-3d9c-4af6-baa9-7e42da817372@github.com>

> I have OCA already processed/approved. I am not Author but my Author request is being processed these days (sent to Rob McKenna).
> I did regression test x86_64 OpenJDK-8. I will leave other regression testing on GHA.
> The patch (and former GCC performance regression) affects only x86_64+i686.

Jan Kratochvil 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 13 additional commits since the last revision:

 - Fix missing SharedRuntime::frem and SharedRuntime::drem on aarch64.
    - bugreported by sviswa7.
 - Merge branch 'master' into modulo
 - Fix #endif comment - found by dholmes-ora.
 - Merge branch 'master' into modulo
 - Fix win32 broken build.
 - Merge remote-tracking branch 'origin/master' into modulo
 - Always include the _WIN64 workaround - a review by dholmes-ora.
 - Remove comments to be moved to JBS (Bug System) - a review by jddarcy.
 - Uppercase L - a review by turbanoff.
 - Fix copyright author.
 - ... and 3 more: https://git.openjdk.org/jdk/compare/9f63957b...f03d4cdf

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12508/files
  - new: https://git.openjdk.org/jdk/pull/12508/files/e4ff04dc..f03d4cdf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12508&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12508&range=10-11

  Stats: 1676 lines in 129 files changed: 670 ins; 408 del; 598 mod
  Patch: https://git.openjdk.org/jdk/pull/12508.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12508/head:pull/12508

PR: https://git.openjdk.org/jdk/pull/12508

From duke at openjdk.org  Sun Mar 12 13:21:21 2023
From: duke at openjdk.org (Jan Kratochvil)
Date: Sun, 12 Mar 2023 13:21:21 GMT
Subject: RFR: 8302191: Performance degradation for float/double modulo on
 Linux [v11]
In-Reply-To: <C6Xad152PsrKXqWRCqx4LjF_DsIrEtDlqykV_6HTwZ8=.d9e7b906-aebe-401c-84c7-bb2f286db890@github.com>
References: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
 <l8C8ei0a9cA9Z8q8Eppac-akguhejxvLI4F5C5ellUQ=.6fc61dd7-c5b4-486b-a4d1-6b06d87485c5@github.com>
 <C6Xad152PsrKXqWRCqx4LjF_DsIrEtDlqykV_6HTwZ8=.d9e7b906-aebe-401c-84c7-bb2f286db890@github.com>
Message-ID: <yXXtLjjQnZcyCXMRpjDipQq1MRkt9Rs0peASdvf70p4=.8a2979c8-1faf-456c-b921-a7c32b849aa0@github.com>

On Thu, 9 Mar 2023 18:53:13 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Jan Kratochvil 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 11 additional commits since the last revision:
>> 
>>  - Fix #endif comment - found by dholmes-ora.
>>  - Merge branch 'master' into modulo
>>  - Fix win32 broken build.
>>  - Merge remote-tracking branch 'origin/master' into modulo
>>  - Always include the _WIN64 workaround - a review by dholmes-ora.
>>  - Remove comments to be moved to JBS (Bug System) - a review by jddarcy.
>>  - Uppercase L - a review by turbanoff.
>>  - Fix copyright author.
>>  - Fix WIN32 vs. WIN64.
>>  - Update according to the upstream review by David Holmes.
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/f101d786...e4ff04dc
>
> src/hotspot/share/runtime/sharedRuntime.cpp line 238:
> 
>> 236: #endif
>> 237: 
>> 238: #if !defined(TARGET_COMPILER_gcc) || defined(_WIN64)
> 
> The aarch64 and other builds are now broken with missing SharedRuntime::frem and SharedRuntime::drem.

True, thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/12508

From dholmes at openjdk.org  Mon Mar 13 01:27:22 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 13 Mar 2023 01:27:22 GMT
Subject: RFR: 8303150: DCmd framework unnecessarily creates a DCmd instance on
 registration
Message-ID: <TNyX996lKlRcmTijRTN0VUZBcNBt2DXeMPhDBjaa0NQ=.160293b7-4570-43a5-af9e-d9cb02022820@github.com>

When DCmd factories are registered, the factory is passed the number of arguments taken by the DCmd - using a template method `get_num_arguments`. For DCmds that don't extend DCmdWithParser there has to be a static `num_arguments()` method in that class. For DCmds that do extend DCmdWithParser the logic instantiates an instance of the DCmd, extracts its parser and calls its `num_arguments` method which dynamically counts the number of defined arguments.

Creating an instance of each DCmd and dynamically counting arguments is inefficient and unnecessary, the number of arguments is statically known and easily expressed (in fact many of the JFR DCmds already statically define this). So we add the static `num_arguments()` method to each class that needs it and return the statically counted number of arguments. To ensure the static number and actual number don't get out-of-sync, we keep the original dynamic logic for use in debug builds to assert that the static and dynamic counts are the same. The assert will trigger during a debug build if something does get out of sync, for example if a new DCmd (extending DCmdWithParser) were added but didn't define the static `num_arguments()` method.

A number of DCmd classes were unnecessarily defining their own dynamic version of `num_arguments` and these are now removed.

In the template method I use `ENABLE_IF(std::is_convertible<T, DCmd>::value)` to check we only call this on DCmd classes. This may be unnecessary but it seemed consistent with the other template methods. Note that `std::is_base_of` only works for immediate super types.

Testing: tiers 1-4

Performance: in theory we should see some improvement in startup; in practice it is barely noticeable.

Thanks.

-------------

Commit messages:
 - 8303150: DCmd framework unnecessarily creates a DCmd instance on registration

Changes: https://git.openjdk.org/jdk/pull/12994/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12994&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303150
  Stats: 99 lines in 12 files changed: 34 ins; 57 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/12994.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12994/head:pull/12994

PR: https://git.openjdk.org/jdk/pull/12994

From dholmes at openjdk.org  Mon Mar 13 05:37:25 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 13 Mar 2023 05:37:25 GMT
Subject: RFR: 8303908: Add missing check in
 VTMS_transition_disable_for_all() for suspend mode
In-Reply-To: <MW-CIeSI8D3Opes0-cjiBHbvBuuUfKxhrZoEpRPylCg=.19babd2e-b3c6-48f7-a6ab-7d38f3211507@github.com>
References: <MW-CIeSI8D3Opes0-cjiBHbvBuuUfKxhrZoEpRPylCg=.19babd2e-b3c6-48f7-a6ab-7d38f3211507@github.com>
Message-ID: <KB3Ekm8dk7cxVH2y53EM2CSygYYtjw6mxzLOj6cYgH4=.4dd36bc4-26c4-4e6c-b238-ff6d19bc2c38@github.com>

On Thu, 9 Mar 2023 18:55:06 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review this small fix. A suspender is a JvmtiVTMSTransitionDisabler monopolist, meaning VTMS_transition_disable_for_all() should not return while there is any active jvmtiVTMSTransitionDisabler. The code though is checking for active "all-disablers" but it's missing the check for active "single disablers".
> I attached a simple reproducer to the bug which I used to test the patch. Not sure if it was worth adding a test so the patch contains just the fix.
> 
> Thanks,
> Patricio

Looks good. Thanks.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12956

From dholmes at openjdk.org  Mon Mar 13 05:37:28 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 13 Mar 2023 05:37:28 GMT
Subject: RFR: 8303908: Add missing check in
 VTMS_transition_disable_for_all() for suspend mode
In-Reply-To: <cigXARkToGc1ci1aRfGlu4PDFr7bfUi2CW3lDcKfnFs=.aba492f9-895c-4712-8ac1-877d252096af@github.com>
References: <MW-CIeSI8D3Opes0-cjiBHbvBuuUfKxhrZoEpRPylCg=.19babd2e-b3c6-48f7-a6ab-7d38f3211507@github.com>
 <fY6ySkv20W_RnUGpkuiUMoQvWUm0f4-Hle_jIkGigs8=.16dfee6f-7dd9-41e0-8c10-a161b6671d1b@github.com>
 <cigXARkToGc1ci1aRfGlu4PDFr7bfUi2CW3lDcKfnFs=.aba492f9-895c-4712-8ac1-877d252096af@github.com>
Message-ID: <pM3RXBbefq7QXEs3Lo69uE-NIrKK6OCgYoaVHBWYTtc=.4e761392-126e-48f5-a420-319ac14849bc@github.com>

On Fri, 10 Mar 2023 17:06:58 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiThreadState.cpp line 372:
>> 
>>> 370:   java_lang_Thread::dec_VTMS_transition_disable_count(vth());
>>> 371:   Atomic::dec(&_VTMS_transition_disable_for_one_count);
>>> 372:   if (_VTMS_transition_disable_for_one_count == 0 || _is_SR) {
>> 
>> Sorry I don't understand why this `_is_SR` check was removed.  I admit I can't really figure out what this field means anyway, but there is nothing in the issue description that suggests this also needs changing - and it is now different to `VTMS_transition_enable_for_all`.
>
> A JvmtiVTMSTransitionDisabler instance that is a "single disabler" only blocks other virtual threads trying to transition or JvmtiVTMSTransitionDisabler monopolists. Both of them will check for _VTMS_transition_disable_for_one_count (the JvmtiVTMSTransitionDisabler monopolist was missing that check) so just checking when that counter is zero is enough. In fact, for a "single disabler" _is_SR is always false so that check wasn't doing anything. Yes, this is not actually needed for the fix, but when looking at which condition we use to wait and which one to notify I caught this, sorry for not explaining that part.
> 
> And looking closer at VTMS_transition_enable_for_all() now I see the check for _is_SR is not doing anything too, because if _VTMS_transition_disable_for_all_count was not zero after the decrement then this can't be a JvmtiVTMSTransitionDisabler monopolist, i.e _is_SR will be false. When a monopolist is running all other "disable all" JvmtiVTMSTransitionDisabler instances if any will be waiting in the first "while (_SR_mode)" loop in VTMS_transition_disable_for_all(), so _VTMS_transition_disable_for_all_count will be one through the monopolist run. So this should be an assert after the decrement: assert(!_is_SR || _VTMS_transition_disable_for_all_count == 0, "").

Thanks for clarifying - I was puzzled by the way `is_SR` was being used.

-------------

PR: https://git.openjdk.org/jdk/pull/12956

From stuefe at openjdk.org  Mon Mar 13 05:50:24 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 13 Mar 2023 05:50:24 GMT
Subject: RFR: JDK-8303861: Error handling step timeouts should never be
 blocked by OnError and others [v2]
In-Reply-To: <ZieQiCz3hdiowTb2Du04KLBQCVy4MModXqSvw1_qKBI=.23138820-d0c5-4bdb-8e30-824b711ad6b8@github.com>
References: <MsoamxpcF7RfrdiX5BXcHcluFN6HqcIZwwLedCUSQck=.8f187897-f3b4-46b8-9811-faba5d2e0b7b@github.com>
 <FVO8BPbYbbOlrFQhTESwAOM4TifV2UQeF2nk6A2NCx4=.de3bf2b9-59a9-4df8-af8a-7550451a85db@github.com>
 <yPypi4QYuc9hQwXnQTZEV67UFUq8JC9VwYqc-IPjqC4=.b51df4fc-3100-483c-b819-a9f1aa0731ed@github.com>
 <BfG5ZOD4J0O-CwiWYk4dICLSbPYCwEevQWoYS9mRKjs=.a5873663-8ee1-4538-b01b-442f9273dabd@github.com>
 <ZieQiCz3hdiowTb2Du04KLBQCVy4MModXqSvw1_qKBI=.23138820-d0c5-4bdb-8e30-824b711ad6b8@github.com>
Message-ID: <aPRZod6d0c1UOuVUZf5kw_mse-6vZKLF6_9g8aE7Lqo=.94eec25a-454e-42e3-9b9b-6cae76b4e351@github.com>

On Sat, 11 Mar 2023 16:54:47 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Not sure what you mean? There is no @id jtreg tag. https://openjdk.org/jtreg/tag-spec.html
>
>> Not sure what you mean? There is no @id jtreg tag. https://openjdk.org/jtreg/tag-spec.html
> 
> Sorry, I got this wrong. The way to do it is @test id=$somestring. See for example:
> 
> https://github.com/openjdk/jdk/blob/a06426a52f16c08c95b1c0270a5fc40721921022/test/hotspot/jtreg/gc/stress/gcold/TestGCOldWithShenandoah.java#L27

Oh, you are right. Its also plain wrong, that specifier does nothing and gets ignored. I'll switch to "id"

-------------

PR: https://git.openjdk.org/jdk/pull/12936

From stuefe at openjdk.org  Mon Mar 13 05:57:01 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 13 Mar 2023 05:57:01 GMT
Subject: RFR: JDK-8303861: Error handling step timeouts should never be
 blocked by OnError and others [v4]
In-Reply-To: <MsoamxpcF7RfrdiX5BXcHcluFN6HqcIZwwLedCUSQck=.8f187897-f3b4-46b8-9811-faba5d2e0b7b@github.com>
References: <MsoamxpcF7RfrdiX5BXcHcluFN6HqcIZwwLedCUSQck=.8f187897-f3b4-46b8-9811-faba5d2e0b7b@github.com>
Message-ID: <BTAX33Owdb0SUDlIx1GELsUKxKqjDHogR_kl3R-zH9s=.6f5a9233-32c8-473d-a5cc-1a3cb085dbb4@github.com>

> Fatal error handling is subject to several timeouts:
> - a global timeout (controlled via ErrorLogTimeout)
> - local error reporting step timeouts.
> 
> The latter aims to "give the JVM a kick" if it gets stuck in one particular place during error reporting. This prevents one error reporting step from hogging all the time allotted to error reporting under ErrorLogTimeout.
> 
> There are three situations where atm we suppress the global error timeout:
> - if the JVM is embedded and the launcher has its abort hook installed. Obviously, that must be allowed to run.
> - if the user specified one or more OnError commands to run, and these did not yet run. These must have a chance to run unmolested.
> - if the user (typically developer) specified ShowMessageBoxOnError, and the error box has not yet been shown
> 
> There is a bug though, that also prevents the step timeout from firing if either condition is true. That is plain wrong.
> 
> In addition to that, the test interval WatcherThread uses to check for timeouts should be decreased. It sits at 1 second, which is too coarse-grained. 
> 
> --------
> 
> Patch:
> - reworks `VMError::check_timeout()` to never block step timeouts
> - adds clarifying comments
> - quadruples timeout check frequency by watcher thread
> - adds regression test for timeout handling with OnError
> - additionally limits timeout per individual error reporting step to 5 seconds. 5 seconds is usually enough to distinguish a slow error reporting step from one that is endlessly hanging. 
> 
> Tested locally on Linux x64.

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  correct test names

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12936/files
  - new: https://git.openjdk.org/jdk/pull/12936/files/2c21ac35..52f382db

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12936&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12936&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12936.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12936/head:pull/12936

PR: https://git.openjdk.org/jdk/pull/12936

From dholmes at openjdk.org  Mon Mar 13 06:02:33 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 13 Mar 2023 06:02:33 GMT
Subject: RFR: JDK-8303861: Error handling step timeouts should never be
 blocked by OnError and others [v4]
In-Reply-To: <BTAX33Owdb0SUDlIx1GELsUKxKqjDHogR_kl3R-zH9s=.6f5a9233-32c8-473d-a5cc-1a3cb085dbb4@github.com>
References: <MsoamxpcF7RfrdiX5BXcHcluFN6HqcIZwwLedCUSQck=.8f187897-f3b4-46b8-9811-faba5d2e0b7b@github.com>
 <BTAX33Owdb0SUDlIx1GELsUKxKqjDHogR_kl3R-zH9s=.6f5a9233-32c8-473d-a5cc-1a3cb085dbb4@github.com>
Message-ID: <yij4gt709BwYfcXw4Thal44mvwEw9AO99CSYaFFo7dI=.6d1784fd-411e-49a8-a7ac-2706ab398a0f@github.com>

On Mon, 13 Mar 2023 05:57:01 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Fatal error handling is subject to several timeouts:
>> - a global timeout (controlled via ErrorLogTimeout)
>> - local error reporting step timeouts.
>> 
>> The latter aims to "give the JVM a kick" if it gets stuck in one particular place during error reporting. This prevents one error reporting step from hogging all the time allotted to error reporting under ErrorLogTimeout.
>> 
>> There are three situations where atm we suppress the global error timeout:
>> - if the JVM is embedded and the launcher has its abort hook installed. Obviously, that must be allowed to run.
>> - if the user specified one or more OnError commands to run, and these did not yet run. These must have a chance to run unmolested.
>> - if the user (typically developer) specified ShowMessageBoxOnError, and the error box has not yet been shown
>> 
>> There is a bug though, that also prevents the step timeout from firing if either condition is true. That is plain wrong.
>> 
>> In addition to that, the test interval WatcherThread uses to check for timeouts should be decreased. It sits at 1 second, which is too coarse-grained. 
>> 
>> --------
>> 
>> Patch:
>> - reworks `VMError::check_timeout()` to never block step timeouts
>> - adds clarifying comments
>> - quadruples timeout check frequency by watcher thread
>> - adds regression test for timeout handling with OnError
>> - additionally limits timeout per individual error reporting step to 5 seconds. 5 seconds is usually enough to distinguish a slow error reporting step from one that is endlessly hanging. 
>> 
>> Tested locally on Linux x64.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   correct test names

test/hotspot/jtreg/runtime/ErrorHandling/TimeoutInErrorHandlingTest.java line 51:

> 49: 
> 50: /*
> 51:  * @test id=@with-on-error

Do you really want the `@` in the name?

-------------

PR: https://git.openjdk.org/jdk/pull/12936

From stefank at openjdk.org  Mon Mar 13 06:38:29 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 13 Mar 2023 06:38:29 GMT
Subject: RFR: 8292059: Do not inline InstanceKlass::allocate_instance()
 [v5]
In-Reply-To: <0mRQdiYkOqYL4mvfGOiUrsFGDUgTq_FMbBrV9DmBZWo=.1630b1b8-31e9-4f76-9b1e-e202711c8714@github.com>
References: <ZSJBTzuC4wVuKdqSLLTgw4Pds2oX5wah0Ub6rFux_tc=.c4e2ae89-cadb-4ccd-9eee-034583cf7200@github.com>
 <0mRQdiYkOqYL4mvfGOiUrsFGDUgTq_FMbBrV9DmBZWo=.1630b1b8-31e9-4f76-9b1e-e202711c8714@github.com>
Message-ID: <rO-e066f-jRFkTSbYsa9HNykPBe3raSuXsi0PN58tqc=.20b1b2f2-0d38-429f-90c7-b2c8fa28556d@github.com>

On Sat, 11 Mar 2023 16:31:06 GMT, Afshin Zafari <duke at openjdk.org> wrote:

>> The inline and not-inline versions of the method is tested to compare the performance difference. 
>> ### Test
>> `make test TEST=micro:Capture0.lambda_01 MICRO="VM_OPTIONS=-XX:TieredStopAtLevel=1" `
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8292059: Do not inline InstanceKlass::allocate_instance()

Changes requested by stefank (Reviewer).

src/hotspot/share/oops/oop.inline.hpp line 37:

> 35: #include "oops/compressedOops.inline.hpp"
> 36: #include "oops/instanceKlass.hpp"
> 37: #include "oops/klass.inline.hpp"

I don't see anything in oop.inline.hpp that needs klass.inline.hpp.

src/hotspot/share/prims/jni.cpp line 61:

> 59: #include "oops/instanceKlass.inline.hpp"
> 60: #include "oops/instanceOop.hpp"
> 61: #include "oops/klass.inline.hpp"

jni.cpp uses klass.inline.hpp, so this line needs to stay.

-------------

PR: https://git.openjdk.org/jdk/pull/12782

From stefank at openjdk.org  Mon Mar 13 06:38:31 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 13 Mar 2023 06:38:31 GMT
Subject: RFR: 8292059: Do not inline InstanceKlass::allocate_instance()
 [v5]
In-Reply-To: <Q0otxbSu4G0hCzOvBHsIZ4J9kiMyLzdaGHaJwju9054=.1afaae94-15e6-40d6-b244-262420b73633@github.com>
References: <ZSJBTzuC4wVuKdqSLLTgw4Pds2oX5wah0Ub6rFux_tc=.c4e2ae89-cadb-4ccd-9eee-034583cf7200@github.com>
 <8koli6nAbt8Rx4Je8MRic0dPloLTb9IiUyw25BvUI0s=.07267dc7-d2a1-4426-8876-1e41b1a248ac@github.com>
 <Q0otxbSu4G0hCzOvBHsIZ4J9kiMyLzdaGHaJwju9054=.1afaae94-15e6-40d6-b244-262420b73633@github.com>
Message-ID: <dxMEZlSiQDw4jWWAacopMGBoJaY5tFxgRpKpMfZw3qQ=.75a84076-387f-4f50-a824-f46c345e04ab@github.com>

On Mon, 6 Mar 2023 13:30:31 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8292059: Do not inline InstanceKlass::allocate_instance()
>
> src/hotspot/share/oops/instanceKlass.inline.hpp line 28:
> 
>> 26: #define SHARE_OOPS_INSTANCEKLASS_INLINE_HPP
>> 27: 
>> 28: #include "oops/instanceKlass.hpp"
> 
> All these includes should *not* be removed.

This file should still doesn't *explicitly* include everything it uses. It also should keep on including "oops/instanceKlass.hpp" (with the blank line after it, as per our style guide).

-------------

PR: https://git.openjdk.org/jdk/pull/12782

From dholmes at openjdk.org  Mon Mar 13 06:51:33 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 13 Mar 2023 06:51:33 GMT
Subject: RFR: 8257967: JFR: Events for loaded agents [v10]
In-Reply-To: <ZsaBMVK-eeLfmxgg15qPJHm6C-ed5PyIE4lGr-Gnr2s=.2f4044c4-e7ed-48f3-8877-feeb2753be18@github.com>
References: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
 <ZsaBMVK-eeLfmxgg15qPJHm6C-ed5PyIE4lGr-Gnr2s=.2f4044c4-e7ed-48f3-8877-feeb2753be18@github.com>
Message-ID: <M86HnsWFDyZ0UNtNsefyHOG-wSDPBIkETS76BtkhCBc=.c65616e6-b644-4db9-b64b-d1319a87b915@github.com>

On Fri, 10 Mar 2023 10:43:23 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> We are adding support to let JFR report on Agents.
>> 
>> #### Design
>> 
>> An Agent is a library that uses any instrumentation or profiling APIs. Most agents are started and initialized on the command line, but agents can also be loaded dynamically during runtime. Because command line agents initialize during the VM startup sequence, they add to the overall startup time latency in getting the VM ready. The events will report on the time the agent took to initialize.
>> 
>> A JavaAgent is an agent written in the Java programming language, using the APIs in the package [java.lang.instrument](https://docs.oracle.com/en/java/javase/19/docs/api/java.instrument/java/lang/instrument/package-summary.html)
>> 
>> A JavaAgent is sometimes called a JPLIS agent, where the acronym JPLIS stands for Java Programming Language Instrumentation Services.
>> 
>> To report on JavaAgents, JFR will add the new event type jdk.JavaAgent and events will look similar to these two examples:
>> 
>> // Command line
>> jdk.JavaAgent {
>>   startTime = 12:31:19.789 (2023-03-08)
>>   name = "JavaAgent.jar"
>>   options = "foo=bar"
>>   dynamic = false
>>   initialization = 12:31:15.574 (2023-03-08)
>>   initializationTime = 172 ms
>> }
>> 
>> // Dynamic load
>> jdk.JavaAgent {
>>   startTime = 12:31:31.158 (2023-03-08)
>>   name = "JavaAgent.jar"
>>   options = "bar=baz"
>>   dynamic = true
>>   initialization = 12:31:31.037 (2023-03-08)
>>   initializationTime = 64,1 ms
>> }
>> 
>> The jdk.JavaAgent event type is a JFR periodic event that iterates over running Java agents.
>> 
>> For a JavaAgent event, the agent's name will be the specific .jar file containing the instrumentation code. The options will be the specific options passed to the .jar file as part of launching the agent, for example, on the command line: -javaagent: JavaAgent.jar=foo=bar.
>> 
>> The "dynamic" field denotes if the agent was loaded via the command line (dynamic = false) or dynamically (dynamic = true)
>> 
>> "initialization" is the timestamp the JVM invoked the initialization method, and "initializationTime" is the duration of executing the initialization method.
>> 
>> "startTime" represents the time the JFR framework issued the periodic event; hence "initialization" will be earlier than "startTime".
>> 
>> An agent can also be written in a native programming language using the [JVM Tools Interface (JVMTI)](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html). This kind of agent, sometimes called a native agent, is a platform-specific binary, sometimes referred to as a library, but here it means a .so or .dll file.
>> 
>> To report on native agents, JFR will add the new event type jdk.NativeAgent and events will look similar to this example:
>> 
>> jdk.NativeAgent {
>>   startTime = 12:31:40.398 (2023-03-08)
>>   name = "jdwp"
>>   options = "transport=dt_socket,server=y,address=any,onjcmd=y"
>>   dynamic = false
>>   initialization = 12:31:36.142 (2023-03-08)
>>   initializationTime = 0,00184 ms
>>   path = "c:\ade\github\openjdk\jdk\build\windows-x86_64-server-slowdebug\jdk\bin\jdwp.dll"
>> }
>> 
>> The layout of the event type is very similar to the jdk.JavaAgent event, but here the path to the native library is reported.
>> 
>> The initialization of a native agent is performed by invoking an agent-specified callback routine. The "initialization" is when the JVM sent or would have sent the JVMTI VMInit event to a specified callback. "initializationTime" is the duration to execute that specific callback. If no callback is specified for the JVMTI VMInit event, the "initializationTime" will be 0.
>> 
>> #### Implementation
>> 
>> There has not existed a reification of a JavaAgent directly in the JVM, as these are built on top of the JDK native library, "instrument", using a many-to-one mapping. At the level of the JVM, the only representation of agents after startup is through JvmtiEnv's, which agents request from the JVM during startup and initialization ? as such, mapping which JvmtiEnv belongs to what JavaAgent was not possible before.
>> 
>> Using implementation details of how the JDK native library "instrument" interacts with the JVM, we can build this mapping to track what JvmtiEnv's "belong" to what JavaAgent. This mapping now lets us report the Java-relevant context (name, options) and measure the time it takes for the JavaAgent to initialize.
>> 
>> When implementing this capability, it was necessary to refactor the code used to represent agents, AgentLibrary. The previous implementation was located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp.
>> 
>> The refactoring isolates the relevant logic into two new modules, prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their older places will help reduce the sizes of oversized arguments.cpp and threads.cpp.
>> 
>> The previous two lists that maintained "agents" (JVMTI) and "libraries" (Xrun) were not thread-safe for concurrent iterations. A single list that allows for concurrent iterations is therefore introduced.
>> 
>> Testing: jdk_jfr, tier 1 - 6
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more cleanup

Still working through this. A few minor comments below.

src/hotspot/share/prims/agent.cpp line 34:

> 32: }
> 33: 
> 34: static const char* allocate_copy(const char* str) {

Why not just use `os::strdup`?

src/hotspot/share/prims/agentList.cpp line 64:

> 62: void AgentList::add_xrun(const char* name, char* options, bool absolute_path) {
> 63:   Agent* agent = new Agent(name, options, absolute_path);
> 64:   agent->_is_xrun = true;

Why direct access of private field instead of having a setter like other parts of the Agent API?

src/hotspot/share/prims/agentList.cpp line 227:

> 225:  * store data in their JvmtiEnv local storage.
> 226:  *
> 227:  * Please see JPLISAgent.c in module java.instrument, see JPLISAgent.h and JPLISAgent.c.

No need to mention the .c file twice.

src/hotspot/share/prims/agentList.cpp line 419:

> 417:     const jint err = (*on_load_entry)(&main_vm, const_cast<char*>(agent->options()), NULL);
> 418:     if (err != JNI_OK) {
> 419:       vm_exit_during_initialization("-Xrun library failed to init", agent->name());

Do you need to be back in `_thread_in_vm` before exiting?

src/hotspot/share/prims/agentList.cpp line 542:

> 540: 
> 541:   // Invoke the Agent_OnAttach function
> 542:   JavaThread* THREAD = JavaThread::current(); // For exception macros.

Nit: just use `current` rather than `THREAD` and don't use the exception macros.

-------------

PR: https://git.openjdk.org/jdk/pull/12923

From dholmes at openjdk.org  Mon Mar 13 06:51:37 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 13 Mar 2023 06:51:37 GMT
Subject: RFR: 8257967: JFR: Events for loaded agents [v9]
In-Reply-To: <HgrCtIIibi1v0BdGh1myrOFfq1z8CrlDf2aFHFzP_mo=.fd09126d-2bcf-4e7f-8d9f-3933ed676566@github.com>
References: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
 <HgrCtIIibi1v0BdGh1myrOFfq1z8CrlDf2aFHFzP_mo=.fd09126d-2bcf-4e7f-8d9f-3933ed676566@github.com>
Message-ID: <qafwYGs-uxNmucUXY-qWxhxwNpNBAb3N95hATo1HOLw=.15a10a71-d029-4c50-a249-dcb6a18b6902@github.com>

On Thu, 9 Mar 2023 16:58:42 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> We are adding support to let JFR report on Agents.
>> 
>> #### Design
>> 
>> An Agent is a library that uses any instrumentation or profiling APIs. Most agents are started and initialized on the command line, but agents can also be loaded dynamically during runtime. Because command line agents initialize during the VM startup sequence, they add to the overall startup time latency in getting the VM ready. The events will report on the time the agent took to initialize.
>> 
>> A JavaAgent is an agent written in the Java programming language, using the APIs in the package [java.lang.instrument](https://docs.oracle.com/en/java/javase/19/docs/api/java.instrument/java/lang/instrument/package-summary.html)
>> 
>> A JavaAgent is sometimes called a JPLIS agent, where the acronym JPLIS stands for Java Programming Language Instrumentation Services.
>> 
>> To report on JavaAgents, JFR will add the new event type jdk.JavaAgent and events will look similar to these two examples:
>> 
>> // Command line
>> jdk.JavaAgent {
>>   startTime = 12:31:19.789 (2023-03-08)
>>   name = "JavaAgent.jar"
>>   options = "foo=bar"
>>   dynamic = false
>>   initialization = 12:31:15.574 (2023-03-08)
>>   initializationTime = 172 ms
>> }
>> 
>> // Dynamic load
>> jdk.JavaAgent {
>>   startTime = 12:31:31.158 (2023-03-08)
>>   name = "JavaAgent.jar"
>>   options = "bar=baz"
>>   dynamic = true
>>   initialization = 12:31:31.037 (2023-03-08)
>>   initializationTime = 64,1 ms
>> }
>> 
>> The jdk.JavaAgent event type is a JFR periodic event that iterates over running Java agents.
>> 
>> For a JavaAgent event, the agent's name will be the specific .jar file containing the instrumentation code. The options will be the specific options passed to the .jar file as part of launching the agent, for example, on the command line: -javaagent: JavaAgent.jar=foo=bar.
>> 
>> The "dynamic" field denotes if the agent was loaded via the command line (dynamic = false) or dynamically (dynamic = true)
>> 
>> "initialization" is the timestamp the JVM invoked the initialization method, and "initializationTime" is the duration of executing the initialization method.
>> 
>> "startTime" represents the time the JFR framework issued the periodic event; hence "initialization" will be earlier than "startTime".
>> 
>> An agent can also be written in a native programming language using the [JVM Tools Interface (JVMTI)](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html). This kind of agent, sometimes called a native agent, is a platform-specific binary, sometimes referred to as a library, but here it means a .so or .dll file.
>> 
>> To report on native agents, JFR will add the new event type jdk.NativeAgent and events will look similar to this example:
>> 
>> jdk.NativeAgent {
>>   startTime = 12:31:40.398 (2023-03-08)
>>   name = "jdwp"
>>   options = "transport=dt_socket,server=y,address=any,onjcmd=y"
>>   dynamic = false
>>   initialization = 12:31:36.142 (2023-03-08)
>>   initializationTime = 0,00184 ms
>>   path = "c:\ade\github\openjdk\jdk\build\windows-x86_64-server-slowdebug\jdk\bin\jdwp.dll"
>> }
>> 
>> The layout of the event type is very similar to the jdk.JavaAgent event, but here the path to the native library is reported.
>> 
>> The initialization of a native agent is performed by invoking an agent-specified callback routine. The "initialization" is when the JVM sent or would have sent the JVMTI VMInit event to a specified callback. "initializationTime" is the duration to execute that specific callback. If no callback is specified for the JVMTI VMInit event, the "initializationTime" will be 0.
>> 
>> #### Implementation
>> 
>> There has not existed a reification of a JavaAgent directly in the JVM, as these are built on top of the JDK native library, "instrument", using a many-to-one mapping. At the level of the JVM, the only representation of agents after startup is through JvmtiEnv's, which agents request from the JVM during startup and initialization ? as such, mapping which JvmtiEnv belongs to what JavaAgent was not possible before.
>> 
>> Using implementation details of how the JDK native library "instrument" interacts with the JVM, we can build this mapping to track what JvmtiEnv's "belong" to what JavaAgent. This mapping now lets us report the Java-relevant context (name, options) and measure the time it takes for the JavaAgent to initialize.
>> 
>> When implementing this capability, it was necessary to refactor the code used to represent agents, AgentLibrary. The previous implementation was located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp.
>> 
>> The refactoring isolates the relevant logic into two new modules, prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their older places will help reduce the sizes of oversized arguments.cpp and threads.cpp.
>> 
>> The previous two lists that maintained "agents" (JVMTI) and "libraries" (Xrun) were not thread-safe for concurrent iterations. A single list that allows for concurrent iterations is therefore introduced.
>> 
>> Testing: jdk_jfr, tier 1 - 6
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   handle multiple envs with same VMInit callback

src/hotspot/share/prims/agent.cpp line 41:

> 39:   char* copy = AllocateHeap(length + 1, mtInternal);
> 40:   strncpy(copy, str, length + 1);
> 41:   assert(strncmp(copy, str, length + 1) == 0, "invariant");

Unclear what you are checking here. Don't you trust strncpy?

-------------

PR: https://git.openjdk.org/jdk/pull/12923

From stuefe at openjdk.org  Mon Mar 13 06:53:27 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 13 Mar 2023 06:53:27 GMT
Subject: RFR: JDK-8303861: Error handling step timeouts should never be
 blocked by OnError and others [v4]
In-Reply-To: <yij4gt709BwYfcXw4Thal44mvwEw9AO99CSYaFFo7dI=.6d1784fd-411e-49a8-a7ac-2706ab398a0f@github.com>
References: <MsoamxpcF7RfrdiX5BXcHcluFN6HqcIZwwLedCUSQck=.8f187897-f3b4-46b8-9811-faba5d2e0b7b@github.com>
 <BTAX33Owdb0SUDlIx1GELsUKxKqjDHogR_kl3R-zH9s=.6f5a9233-32c8-473d-a5cc-1a3cb085dbb4@github.com>
 <yij4gt709BwYfcXw4Thal44mvwEw9AO99CSYaFFo7dI=.6d1784fd-411e-49a8-a7ac-2706ab398a0f@github.com>
Message-ID: <RmF3GlO1U5GgMrIdcfY7o9RAST6GKOwdZ5oL1m2hd-U=.4d35477b-bc38-4d71-a485-4a3feb787786@github.com>

On Mon, 13 Mar 2023 05:59:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   correct test names
>
> test/hotspot/jtreg/runtime/ErrorHandling/TimeoutInErrorHandlingTest.java line 51:
> 
>> 49: 
>> 50: /*
>> 51:  * @test id=@with-on-error
> 
> Do you really want the `@` in the name?

Argh. Typo, sorry. New keyboard.

-------------

PR: https://git.openjdk.org/jdk/pull/12936

From rehn at openjdk.org  Mon Mar 13 09:38:13 2023
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 13 Mar 2023 09:38:13 GMT
Subject: Integrated: 8300926: Several startup regressions ~6-70% in 21-b6 all
 platforms
In-Reply-To: <yAP6c7wzGguBfKuzvbjMZdnaqydAz4PFn0pgR1UGj9s=.ce872f5d-3f7a-4e24-99d5-da5e80855ea4@github.com>
References: <yAP6c7wzGguBfKuzvbjMZdnaqydAz4PFn0pgR1UGj9s=.ce872f5d-3f7a-4e24-99d5-da5e80855ea4@github.com>
Message-ID: <sTcHCkqG66NoNvSyF9A6xUKDjC5ZhT5aAQDcrUl6h5E=.a7124a6c-6217-4caf-8b9e-5824f46a463e@github.com>

On Thu, 16 Feb 2023 08:38:42 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Hi all, please consider.
> 
> The original issue was when thread 1 asked to deopt nmethod set X and thread 2 asked for the same or a subset of X.
> All method will already be marked, but the actual deoptimizing, not entrant, patching PC on stacks and patching post call nops, was not done yet. Which meant thread 2 could 'pass' thread 1.
> Most places did deopt under Compile_lock, thus this is not an issue, but WB and clearCallSiteContext do not.
> 
> Since a handshakes may take long before completion and Compile_lock is used for so much more than deopts.
> The fix in https://bugs.openjdk.org/browse/JDK-8299074 instead always emitted a handshake even when everything was already marked. (instead of adding Compile_lock to all places)
> 
> This turnout to be problematic in the startup, for example the number of deopt handshakes in jetty dry run startup went from 5 to 39 handshakes.
> 
> This fix first adds a barrier for which you do not pass until the requested deopts have happened and it coalesces the handshakes.
> Secondly it moves handshakes part out of the Compile_lock where it is possible.
> 
> Which means we fix the performance bug and we reduce the contention on Compile_lock, meaning higher throughput in compiler and things such as class-loading.
> 
> It passes t1-t7 with flying colours! t8 still not completed and I'm redoing some testing due to last minute simplifications.
> 
> Thanks, Robbin

This pull request has now been integrated.

Changeset: c183fce9
Author:    Robbin Ehn <rehn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c183fce9543ca15f5db632babecdb7797d0745e4
Stats:     449 lines in 24 files changed: 215 ins; 109 del; 125 mod

8300926: Several startup regressions ~6-70% in 21-b6 all platforms

Reviewed-by: eosterlund, dcubed, coleenp

-------------

PR: https://git.openjdk.org/jdk/pull/12585

From adinn at openjdk.org  Mon Mar 13 09:48:43 2023
From: adinn at openjdk.org (Andrew Dinn)
Date: Mon, 13 Mar 2023 09:48:43 GMT
Subject: RFR: 8257967: JFR: Events for loaded agents [v10]
In-Reply-To: <ZsaBMVK-eeLfmxgg15qPJHm6C-ed5PyIE4lGr-Gnr2s=.2f4044c4-e7ed-48f3-8877-feeb2753be18@github.com>
References: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
 <ZsaBMVK-eeLfmxgg15qPJHm6C-ed5PyIE4lGr-Gnr2s=.2f4044c4-e7ed-48f3-8877-feeb2753be18@github.com>
Message-ID: <nDqJr3UvnHKKXqOblbPcpU_N3sNNN3XpfsaY9XIZ6jQ=.78392ad6-2a97-4758-a267-94e797dab7f1@github.com>

On Fri, 10 Mar 2023 10:43:23 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> We are adding support to let JFR report on Agents.
>> 
>> #### Design
>> 
>> An Agent is a library that uses any instrumentation or profiling APIs. Most agents are started and initialized on the command line, but agents can also be loaded dynamically during runtime. Because command line agents initialize during the VM startup sequence, they add to the overall startup time latency in getting the VM ready. The events will report on the time the agent took to initialize.
>> 
>> A JavaAgent is an agent written in the Java programming language, using the APIs in the package [java.lang.instrument](https://docs.oracle.com/en/java/javase/19/docs/api/java.instrument/java/lang/instrument/package-summary.html)
>> 
>> A JavaAgent is sometimes called a JPLIS agent, where the acronym JPLIS stands for Java Programming Language Instrumentation Services.
>> 
>> To report on JavaAgents, JFR will add the new event type jdk.JavaAgent and events will look similar to these two examples:
>> 
>> // Command line
>> jdk.JavaAgent {
>>   startTime = 12:31:19.789 (2023-03-08)
>>   name = "JavaAgent.jar"
>>   options = "foo=bar"
>>   dynamic = false
>>   initialization = 12:31:15.574 (2023-03-08)
>>   initializationTime = 172 ms
>> }
>> 
>> // Dynamic load
>> jdk.JavaAgent {
>>   startTime = 12:31:31.158 (2023-03-08)
>>   name = "JavaAgent.jar"
>>   options = "bar=baz"
>>   dynamic = true
>>   initialization = 12:31:31.037 (2023-03-08)
>>   initializationTime = 64,1 ms
>> }
>> 
>> The jdk.JavaAgent event type is a JFR periodic event that iterates over running Java agents.
>> 
>> For a JavaAgent event, the agent's name will be the specific .jar file containing the instrumentation code. The options will be the specific options passed to the .jar file as part of launching the agent, for example, on the command line: -javaagent: JavaAgent.jar=foo=bar.
>> 
>> The "dynamic" field denotes if the agent was loaded via the command line (dynamic = false) or dynamically (dynamic = true)
>> 
>> "initialization" is the timestamp the JVM invoked the initialization method, and "initializationTime" is the duration of executing the initialization method.
>> 
>> "startTime" represents the time the JFR framework issued the periodic event; hence "initialization" will be earlier than "startTime".
>> 
>> An agent can also be written in a native programming language using the [JVM Tools Interface (JVMTI)](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html). This kind of agent, sometimes called a native agent, is a platform-specific binary, sometimes referred to as a library, but here it means a .so or .dll file.
>> 
>> To report on native agents, JFR will add the new event type jdk.NativeAgent and events will look similar to this example:
>> 
>> jdk.NativeAgent {
>>   startTime = 12:31:40.398 (2023-03-08)
>>   name = "jdwp"
>>   options = "transport=dt_socket,server=y,address=any,onjcmd=y"
>>   dynamic = false
>>   initialization = 12:31:36.142 (2023-03-08)
>>   initializationTime = 0,00184 ms
>>   path = "c:\ade\github\openjdk\jdk\build\windows-x86_64-server-slowdebug\jdk\bin\jdwp.dll"
>> }
>> 
>> The layout of the event type is very similar to the jdk.JavaAgent event, but here the path to the native library is reported.
>> 
>> The initialization of a native agent is performed by invoking an agent-specified callback routine. The "initialization" is when the JVM sent or would have sent the JVMTI VMInit event to a specified callback. "initializationTime" is the duration to execute that specific callback. If no callback is specified for the JVMTI VMInit event, the "initializationTime" will be 0.
>> 
>> #### Implementation
>> 
>> There has not existed a reification of a JavaAgent directly in the JVM, as these are built on top of the JDK native library, "instrument", using a many-to-one mapping. At the level of the JVM, the only representation of agents after startup is through JvmtiEnv's, which agents request from the JVM during startup and initialization ? as such, mapping which JvmtiEnv belongs to what JavaAgent was not possible before.
>> 
>> Using implementation details of how the JDK native library "instrument" interacts with the JVM, we can build this mapping to track what JvmtiEnv's "belong" to what JavaAgent. This mapping now lets us report the Java-relevant context (name, options) and measure the time it takes for the JavaAgent to initialize.
>> 
>> When implementing this capability, it was necessary to refactor the code used to represent agents, AgentLibrary. The previous implementation was located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp.
>> 
>> The refactoring isolates the relevant logic into two new modules, prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their older places will help reduce the sizes of oversized arguments.cpp and threads.cpp.
>> 
>> The previous two lists that maintained "agents" (JVMTI) and "libraries" (Xrun) were not thread-safe for concurrent iterations. A single list that allows for concurrent iterations is therefore introduced.
>> 
>> Testing: jdk_jfr, tier 1 - 6
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more cleanup

src/hotspot/share/jfr/metadata/metadata.xml line 1182:

> 1180:     <Field type="Ticks" name="initialization" label="Initialization" description="The time the JVM initialized the agent" />
> 1181:     <Field type="Tickspan" name="initializationTime" label="Initialization Time" description="The duration of executing the initialization method exported by the agent" />
> 1182:   </Event>

@mgronlun A somewhat drive-by comment. It might be clearer if you renamed these event fields and accessors, plus also the corresponding fields and accessors in class Agent, as `initializationTime` and `initializationDuration`.

-------------

PR: https://git.openjdk.org/jdk/pull/12923

From adinn at openjdk.org  Mon Mar 13 09:52:38 2023
From: adinn at openjdk.org (Andrew Dinn)
Date: Mon, 13 Mar 2023 09:52:38 GMT
Subject: RFR: 8257967: JFR: Events for loaded agents [v10]
In-Reply-To: <M86HnsWFDyZ0UNtNsefyHOG-wSDPBIkETS76BtkhCBc=.c65616e6-b644-4db9-b64b-d1319a87b915@github.com>
References: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
 <ZsaBMVK-eeLfmxgg15qPJHm6C-ed5PyIE4lGr-Gnr2s=.2f4044c4-e7ed-48f3-8877-feeb2753be18@github.com>
 <M86HnsWFDyZ0UNtNsefyHOG-wSDPBIkETS76BtkhCBc=.c65616e6-b644-4db9-b64b-d1319a87b915@github.com>
Message-ID: <Zwh7j7Mek5EyfIJBgNYom2kZy71QLxSHyI5BmHe1gqY=.0b9da360-0979-4394-ae9c-adac9cadbfee@github.com>

On Mon, 13 Mar 2023 06:29:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more cleanup
>
> src/hotspot/share/prims/agentList.cpp line 64:
> 
>> 62: void AgentList::add_xrun(const char* name, char* options, bool absolute_path) {
>> 63:   Agent* agent = new Agent(name, options, absolute_path);
>> 64:   agent->_is_xrun = true;
> 
> Why direct access of private field instead of having a setter like other parts of the Agent API?

n.b. that also applies for accesses/updates to field _next.

-------------

PR: https://git.openjdk.org/jdk/pull/12923

From tschatzl at openjdk.org  Mon Mar 13 09:59:40 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 13 Mar 2023 09:59:40 GMT
Subject: RFR: 8303963: Replace various encodings of UINT/SIZE_MAX in gc
 code
In-Reply-To: <w0VqKkqwbwseO8gbXoVrK3jjjFY73ghLtDnbRtGwqcQ=.7b7fdcfc-00e4-49c3-8293-721016e03a04@github.com>
References: <Fmc4hyR2uLTnJTKeGnpRHqMyNefCPO5POSmjdvaKFzQ=.df9059fb-10ed-48e7-ad23-5bf2f5409023@github.com>
 <w0VqKkqwbwseO8gbXoVrK3jjjFY73ghLtDnbRtGwqcQ=.7b7fdcfc-00e4-49c3-8293-721016e03a04@github.com>
Message-ID: <YOlH1FYY-wrVx50z3j5tl64VtGxmLThsl6rIhpfSzfM=.44184f8e-db69-42dc-b555-a465dea17b6c@github.com>

On Fri, 10 Mar 2023 14:20:54 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this refactoring that replaces various casts in GC and more-or-less related to get all bits set in an uint/size_t with the available constants from cstdint.
>> The ones in ZGC files were skipped on request.
>> 
>> Testing: local compilation, gha
>> 
>> Thanks,
>>   Thomas
>
> Marked as reviewed by ayang (Reviewer).

Thanks @albertnetymk @kimbarrett for your reviews

-------------

PR: https://git.openjdk.org/jdk/pull/12973

From tschatzl at openjdk.org  Mon Mar 13 09:59:42 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 13 Mar 2023 09:59:42 GMT
Subject: Integrated: 8303963: Replace various encodings of UINT/SIZE_MAX in gc
 code
In-Reply-To: <Fmc4hyR2uLTnJTKeGnpRHqMyNefCPO5POSmjdvaKFzQ=.df9059fb-10ed-48e7-ad23-5bf2f5409023@github.com>
References: <Fmc4hyR2uLTnJTKeGnpRHqMyNefCPO5POSmjdvaKFzQ=.df9059fb-10ed-48e7-ad23-5bf2f5409023@github.com>
Message-ID: <TMCeIg7FBih4mhaQmp5ilihaSpnkhVKJm4kQlVdEGgk=.50aaab4a-1503-461b-a50e-90ef7b7a1ca0@github.com>

On Fri, 10 Mar 2023 12:58:42 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this refactoring that replaces various casts in GC and more-or-less related to get all bits set in an uint/size_t with the available constants from cstdint.
> The ones in ZGC files were skipped on request.
> 
> Testing: local compilation, gha
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: b575e54b
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b575e54bc96c8fc413893dbbe91d0b5ce0192179
Stats:     15 lines in 13 files changed: 0 ins; 2 del; 13 mod

8303963: Replace various encodings of UINT/SIZE_MAX in gc code

Reviewed-by: ayang, kbarrett

-------------

PR: https://git.openjdk.org/jdk/pull/12973

From stuefe at openjdk.org  Mon Mar 13 10:15:37 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 13 Mar 2023 10:15:37 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v21]
In-Reply-To: <hR80_9dU9pp0SnN8q-qZ7aG-_YWFST6O6EXQZ_pNjPk=.0f0cbf74-2890-4bd5-88ba-fbe4be92764a@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <hR80_9dU9pp0SnN8q-qZ7aG-_YWFST6O6EXQZ_pNjPk=.0f0cbf74-2890-4bd5-88ba-fbe4be92764a@github.com>
Message-ID: <Zih5DF9-gx0_sSCC7E-elgBrXZHRoJQg8uV0kjWncBQ=.e6992a2f-f698-48e9-b542-65f8b9bdf610@github.com>

On Fri, 10 Mar 2023 12:45:12 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>  - Use nullptr instead of NULL in touched code (shared)

More comments

src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 884:

> 882:       fast_unlock(obj_reg, header_reg, swap_reg, rscratch1, slow_case);
> 883:       b(count);
> 884:       bind(slow_case);

small nit, move the bind to where the slow case actually is?

src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 892:

> 890:       // Test for recursion
> 891:       cbz(header_reg, count);
> 892: 

Not your patch, but I found interesting that arm does actually zero out the object slot in the BasicLock on the stack. I assume that is not needed, right?

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 6220:

> 6218: //  - obj: the object to be locked
> 6219: //  - hdr: the header, already loaded from obj, will be destroyed
> 6220: //  - t1, t2, t3: temporary registers, will be destroyed

Adapt comment: we don't use t3

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 6249:

> 6247: }
> 6248: 
> 6249: void MacroAssembler::fast_unlock(Register obj, Register hdr, Register t1, Register t2, Label& slow) {

Could you add a comment here too as you did for lock?

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From stuefe at openjdk.org  Mon Mar 13 10:15:40 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 13 Mar 2023 10:15:40 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v21]
In-Reply-To: <7265U-aASDjFX1CMrbxDZZCPHrYJkufD1QDFBuB1WSA=.623488a7-9ede-4ec2-b840-1e5601a9b97a@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <hR80_9dU9pp0SnN8q-qZ7aG-_YWFST6O6EXQZ_pNjPk=.0f0cbf74-2890-4bd5-88ba-fbe4be92764a@github.com>
 <7265U-aASDjFX1CMrbxDZZCPHrYJkufD1QDFBuB1WSA=.623488a7-9ede-4ec2-b840-1e5601a9b97a@github.com>
Message-ID: <58K_81BGoa-o4Pq1LtVhV_fOyYvSIxV1e66syvpefro=.9496823a-207e-467b-917d-f0f8852cda5c@github.com>

On Sat, 11 Mar 2023 14:53:29 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>>  - Use nullptr instead of NULL in touched code (shared)
>
> src/hotspot/share/runtime/lockStack.hpp line 52:
> 
>> 50:   static ByteSize limit_offset()      { return byte_offset_of(LockStack, _limit); }
>> 51: 
>> 52:   static void ensure_lock_stack_size(oop* _required_limit);
> 
> I would split this, do the comparison inline, only the actual growth in the cpp file.

Just realized that this interface is actually a bit odd: since we pass a wish pointer that has nothing to do with either current state nor final result. In fact, the pointer could at the moment point into the lock stack of a different thread.

So this is "the pointer that would designate the end of the LockStack if the lockstack were enlarged *in-place*". Maybe add a comment like that.

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From stuefe at openjdk.org  Mon Mar 13 10:24:39 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 13 Mar 2023 10:24:39 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v21]
In-Reply-To: <hR80_9dU9pp0SnN8q-qZ7aG-_YWFST6O6EXQZ_pNjPk=.0f0cbf74-2890-4bd5-88ba-fbe4be92764a@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <hR80_9dU9pp0SnN8q-qZ7aG-_YWFST6O6EXQZ_pNjPk=.0f0cbf74-2890-4bd5-88ba-fbe4be92764a@github.com>
Message-ID: <6jWzeHbL7AH2PDn3-k_3B8jWKfVs3VEG9up7pw265n0=.3ce51a4e-4148-433f-991f-606802d79d50@github.com>

On Fri, 10 Mar 2023 12:45:12 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>  - Use nullptr instead of NULL in touched code (shared)

Lockstack::grow: 

I would add a mode (either tied to ASSERT or as a stand-alone switch, I prefer the latter) to give us just as many slots as needed and no more. With NMT on, this will give us trailing canaries so we have overwriter alerts on the next grow.

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From fparain at openjdk.org  Mon Mar 13 12:09:10 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 13 Mar 2023 12:09:10 GMT
Subject: RFR: 8292818: replace 96-bit representation for field metadata
 with variable-sized streams [v2]
In-Reply-To: <vdiacOO3JUyy4sWGkDXNBMUT7cG3XYe79mOvYru9uMM=.9c556675-7ffd-4c09-a428-6d64dffef209@github.com>
References: <vdiacOO3JUyy4sWGkDXNBMUT7cG3XYe79mOvYru9uMM=.9c556675-7ffd-4c09-a428-6d64dffef209@github.com>
Message-ID: <xswczVe6aAErYpqh8pSOgH3LNAwJ35MEcv0PO7-dUiQ=.e7c45723-afea-44b2-84ef-7290bba906af@github.com>

> Please review this change re-implementing the FieldInfo data structure.
> 
> The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency.
> 
> The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information).
> 
> More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818
> 
> Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM.
> 
> The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format.
> 
> Tested with mach5, tier 1 to 7.
> 
> Thank you.

Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:

  Addressing comments from first reviews

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12855/files
  - new: https://git.openjdk.org/jdk/pull/12855/files/42a4d6a0..ce1180ef

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12855&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12855&range=00-01

  Stats: 111 lines in 13 files changed: 40 ins; 22 del; 49 mod
  Patch: https://git.openjdk.org/jdk/pull/12855.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12855/head:pull/12855

PR: https://git.openjdk.org/jdk/pull/12855

From inakonechnyy at openjdk.org  Mon Mar 13 12:45:34 2023
From: inakonechnyy at openjdk.org (Ilarion Nakonechnyy)
Date: Mon, 13 Mar 2023 12:45:34 GMT
Subject: RFR: 8302491: NoClassDefFoundError omits the original cause of an
 error [v7]
In-Reply-To: <MXlHYT8RkJEakZpD6aFFSFyOhK9-aSbCMRoycp9db14=.553419d4-f880-48bf-ae8b-e13e5aff6456@github.com>
References: <L-pfBfK4TKl5KUWpPEcbs-IkhwimgJZ-SOrbSG3exeA=.5e883f22-de9b-4eec-9e98-8ee954a7996b@github.com>
 <MXlHYT8RkJEakZpD6aFFSFyOhK9-aSbCMRoycp9db14=.553419d4-f880-48bf-ae8b-e13e5aff6456@github.com>
Message-ID: <6rT55JPqgHHPzlDCiUb_SHK1YtQ0rDQlpZ7X3z73uow=.b6ae4f58-bb8f-4a40-9539-4b51f3b0c049@github.com>

On Thu, 9 Mar 2023 23:12:00 GMT, Ilarion Nakonechnyy <inakonechnyy at openjdk.org> wrote:

>> The proposed approach added a new function for getting the cause of an exception -`java_lang_Throwable::get_cause_simple `, that gets called within `InstanceKlass::add_initialization_error`  if an old one `java_lang_Throwable::get_cause_with_stack_trace` didn't succeed because of an exception during the VM call. The simple function doesn't call the VM for getting a stack trace but fills in any other information about an exception.
>> 
>> Besides that, the discovering information about an exception was added to `ConstantPoolCacheEntry::save_and_throw_indy_exc` function. 
>> 
>> Jtreg for reproducing the issue also was added to the commit. 
>> The commit was tested with tier1 tests.
>
> Ilarion Nakonechnyy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Some corrections

Thank you for the review, thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/12566

From inakonechnyy at openjdk.org  Mon Mar 13 13:48:05 2023
From: inakonechnyy at openjdk.org (Ilarion Nakonechnyy)
Date: Mon, 13 Mar 2023 13:48:05 GMT
Subject: RFR: 8302491: NoClassDefFoundError omits the original cause of an
 error [v8]
In-Reply-To: <L-pfBfK4TKl5KUWpPEcbs-IkhwimgJZ-SOrbSG3exeA=.5e883f22-de9b-4eec-9e98-8ee954a7996b@github.com>
References: <L-pfBfK4TKl5KUWpPEcbs-IkhwimgJZ-SOrbSG3exeA=.5e883f22-de9b-4eec-9e98-8ee954a7996b@github.com>
Message-ID: <BIH6zVFZ1QMv5XYgxMF6VXVSN5TVVTBKSB09CDugRFk=.1104732f-d90f-4c06-9a87-ba412e6816dc@github.com>

> The proposed approach added a new function for getting the cause of an exception -`java_lang_Throwable::get_cause_simple `, that gets called within `InstanceKlass::add_initialization_error`  if an old one `java_lang_Throwable::get_cause_with_stack_trace` didn't succeed because of an exception during the VM call. The simple function doesn't call the VM for getting a stack trace but fills in any other information about an exception.
> 
> Besides that, the discovering information about an exception was added to `ConstantPoolCacheEntry::save_and_throw_indy_exc` function. 
> 
> Jtreg for reproducing the issue also was added to the commit. 
> The commit was tested with tier1 tests.

Ilarion Nakonechnyy has updated the pull request incrementally with one additional commit since the last revision:

  minor correction

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12566/files
  - new: https://git.openjdk.org/jdk/pull/12566/files/5e575962..e55cb339

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12566&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12566&range=06-07

  Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/12566.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12566/head:pull/12566

PR: https://git.openjdk.org/jdk/pull/12566

From jwaters at openjdk.org  Mon Mar 13 14:30:41 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 13 Mar 2023 14:30:41 GMT
Subject: RFR: 8301244: Tidy up compiler specific warnings files [v8]
In-Reply-To: <Y7_BhQXteoHes4WqxfbxjjsGwrKEqQSVxQXoLq4vD0U=.1b881ab6-e032-4cdf-855e-e05684f705bc@github.com>
References: <CU3GjASmLJw11Olusd1w5qnl-zb_d1hjVewzVEn3BS0=.277f1a89-0731-41ee-bad8-e15a57a826a4@github.com>
 <c682NeMJDnt4ZMFgHThoQx74i8qIsTTsMkq7YA3xusU=.edb8142b-e0ed-4183-a068-4174547b6cd2@github.com>
 <Y7_BhQXteoHes4WqxfbxjjsGwrKEqQSVxQXoLq4vD0U=.1b881ab6-e032-4cdf-855e-e05684f705bc@github.com>
Message-ID: <dcKfZ3wV4nAWnmoUm-I61TLZnGtt5ZQdnfuyrQl0kqU=.d6adfa47-b821-4623-b6d4-b56d6d4adc3e@github.com>

On Wed, 1 Feb 2023 07:46:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - gcc
>>  - VISCPP
>>  - Comment
>>  - Re-add PRAGMA
>
> So can I assume you have some uses for this in the pipeline?

Thanks Kim, waiting for a second reviewer (@dholmes-ora perhaps?)

-------------

PR: https://git.openjdk.org/jdk/pull/12255

From pchilanomate at openjdk.org  Mon Mar 13 15:49:24 2023
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 13 Mar 2023 15:49:24 GMT
Subject: RFR: 8303908: Add missing check in
 VTMS_transition_disable_for_all() for suspend mode
In-Reply-To: <KB3Ekm8dk7cxVH2y53EM2CSygYYtjw6mxzLOj6cYgH4=.4dd36bc4-26c4-4e6c-b238-ff6d19bc2c38@github.com>
References: <MW-CIeSI8D3Opes0-cjiBHbvBuuUfKxhrZoEpRPylCg=.19babd2e-b3c6-48f7-a6ab-7d38f3211507@github.com>
 <KB3Ekm8dk7cxVH2y53EM2CSygYYtjw6mxzLOj6cYgH4=.4dd36bc4-26c4-4e6c-b238-ff6d19bc2c38@github.com>
Message-ID: <icsRbx6BhzyF8-LJTKICNhyn_PeBwTRi62g-oxhNO4M=.55589628-b245-4342-b48a-30cea7b2bc7e@github.com>

On Mon, 13 Mar 2023 05:34:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Looks good. Thanks.
>
Thanks for the review David!

-------------

PR: https://git.openjdk.org/jdk/pull/12956

From sviswanathan at openjdk.org  Mon Mar 13 16:14:30 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Mon, 13 Mar 2023 16:14:30 GMT
Subject: RFR: 8302191: Performance degradation for float/double modulo on
 Linux [v12]
In-Reply-To: <RId-BddGF5Px37EdS6jN7fen2y-UTKlPXrF88KJizq0=.e2ffd401-3d9c-4af6-baa9-7e42da817372@github.com>
References: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
 <RId-BddGF5Px37EdS6jN7fen2y-UTKlPXrF88KJizq0=.e2ffd401-3d9c-4af6-baa9-7e42da817372@github.com>
Message-ID: <zlA-drG2tCot3jlSe5Ksk2ztEFlBC4D6oc5BhDLpVis=.04577e3a-47b2-4571-9dc8-5a301a5854e1@github.com>

On Sun, 12 Mar 2023 13:21:18 GMT, Jan Kratochvil <duke at openjdk.org> wrote:

>> I have OCA already processed/approved. I am not Author but my Author request is being processed these days (sent to Rob McKenna).
>> I did regression test x86_64 OpenJDK-8. I will leave other regression testing on GHA.
>> The patch (and former GCC performance regression) affects only x86_64+i686.
>
> Jan Kratochvil 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 13 additional commits since the last revision:
> 
>  - Fix missing SharedRuntime::frem and SharedRuntime::drem on aarch64.
>     - bugreported by sviswa7.
>  - Merge branch 'master' into modulo
>  - Fix #endif comment - found by dholmes-ora.
>  - Merge branch 'master' into modulo
>  - Fix win32 broken build.
>  - Merge remote-tracking branch 'origin/master' into modulo
>  - Always include the _WIN64 workaround - a review by dholmes-ora.
>  - Remove comments to be moved to JBS (Bug System) - a review by jddarcy.
>  - Uppercase L - a review by turbanoff.
>  - Fix copyright author.
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/37d28306...f03d4cdf

Looks good to me.

-------------

Marked as reviewed by sviswanathan (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12508

From sviswanathan at openjdk.org  Mon Mar 13 16:14:32 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Mon, 13 Mar 2023 16:14:32 GMT
Subject: RFR: 8302191: Performance degradation for float/double modulo on
 Linux [v9]
In-Reply-To: <_z7GiZvqh8NpSWzxLMKrcQB_0g_xz8lneN9LOI6DedI=.6453aa68-1f70-4662-897c-04537214cd8a@github.com>
References: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
 <cE1Rx7P-qflRs1y7BrpsD5amJDRjCRku5DT_scRArfY=.fc54c292-0090-4fb0-ac5b-c2fd6dc06039@github.com>
 <_z7GiZvqh8NpSWzxLMKrcQB_0g_xz8lneN9LOI6DedI=.6453aa68-1f70-4662-897c-04537214cd8a@github.com>
Message-ID: <4kBiCRBRZjc1gAPnVYcQnqherkdMyzBbyLVZGLcf_nc=.1bcd7bdd-35c2-480d-ab81-4c38a7c7a35c@github.com>

On Sat, 4 Mar 2023 01:11:33 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> Very nice performance increase. The only concern I have is that the x87 fpu control (using fldcw instruction) is not set in 64 bit builds by the JVM anymore explicitly. It is only set in the 32bit builds. Maybe @iwanowww or @shipilev have some thoughts on this.

The default value of x87 fpu control word (0x37F) works for this case so it should be ok.

-------------

PR: https://git.openjdk.org/jdk/pull/12508

From mdoerr at openjdk.org  Mon Mar 13 16:23:21 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 13 Mar 2023 16:23:21 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v3]
In-Reply-To: <AOvm3Axl3yZLOa-A0ikaRQY7el-CsXTm0TJyNx-gkQk=.9d4cf018-f0a3-49d3-ad0d-d3018725fccf@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com>
 <HT8kQfjS98dYHeAMcNL5latokRiw3YK8npxl5yCD4hw=.28b19bac-cbfa-4461-a1db-c899c55b7485@github.com>
 <wBVqRDFM23KM8fjjPtUFNdW56FYsSpvOAVvHmpdjbzo=.7c429606-ac19-4f36-8e25-459534983924@github.com>
 <QMh_faUf_LLUf68WrZiFxmPHiFcHDBfKDg3g-oekBeg=.096acd06-65c4-4357-ad4a-4089b5478fff@github.com>
 <hJkc1ozy4f7BIvXZ_xQ3HRttVsBs0ceUIMmq4cDWrzQ=.bc3223f5-cb33-46c7-9708-ab40ba5943b0@github.com>
 <mknfp22D3MdgwuitW4rYeIdz2S43a8wQdSmLerF2yO0=.94e5cf61-b2b8-41f3-b44e-0bde47b33bfc@github.com>
 <AOvm3Axl3yZLOa-A0ikaRQY7el-CsXTm0TJyNx-gkQk=.9d4cf018-f0a3-49d3-ad0d-d3018725fccf@github.com>
Message-ID: <z1ogtf4v8v1oXW77do4v590wnNnczFYQsERCTXW3qeI=.a0511aba-5e5e-4074-ba43-373f3d0708f8@github.com>

On Sat, 11 Mar 2023 02:20:31 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> @JornVernee: Thanks! I've merged in your changes. TestArrayStructs is not yet completely working. I will need to investigate. I think I've done most other things you had requested. You may want to take a look at my recent commits.
>
> @TheRealMDoerr I've been keeping up with the changes you're making. I just have to look at the new test for HFA's you've added you added (next week).
> 
> Besides fixing the TestArrayStructs test, do you have anything else you still want to add to this PR?

@JornVernee: I guess I should add a couple of Upcalls to my new test. Otherwise, I have only planned to fix `TestArrayStructs`. Further changes (and maybe new tests) can still get done when working on Big Endian / AIX or when there is a demand.

I'm currently wondering about the `TestArrayStructs` failures. Passing arrays with up to 7 elements seems to work fine. When I pass 8 elements, the last element of `capturedArgs` gets observed as 0. When I pass more than 8 elements, element 5 and 6 of `capturedArgs` get observed as 0.
`DowncallLinker.invokeInterpBindings` has the correct `args`, but `UpcallLinker.invokeInterpBindings` doesn't receive the correct values as `lowLevelArgs`. They contain the wrong zeros. The remaining elements look correct.
Do you have an idea what could be going wrong? Otherwise, I'll have to continue debugging.

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From fparain at openjdk.org  Mon Mar 13 16:26:06 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 13 Mar 2023 16:26:06 GMT
Subject: RFR: 8292818: replace 96-bit representation for field metadata
 with variable-sized streams [v3]
In-Reply-To: <vdiacOO3JUyy4sWGkDXNBMUT7cG3XYe79mOvYru9uMM=.9c556675-7ffd-4c09-a428-6d64dffef209@github.com>
References: <vdiacOO3JUyy4sWGkDXNBMUT7cG3XYe79mOvYru9uMM=.9c556675-7ffd-4c09-a428-6d64dffef209@github.com>
Message-ID: <fBYw2BQ75TAbqosMBM-_LOnkatqy6uOwpDfOpa7yN30=.441cba80-1f96-4e0b-bbc8-f43e1818113e@github.com>

> Please review this change re-implementing the FieldInfo data structure.
> 
> The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency.
> 
> The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information).
> 
> More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818
> 
> Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM.
> 
> The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format.
> 
> Tested with mach5, tier 1 to 7.
> 
> Thank you.

Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:

  SA additional caching from Chris Plummer

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12855/files
  - new: https://git.openjdk.org/jdk/pull/12855/files/ce1180ef..322b626d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12855&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12855&range=01-02

  Stats: 78 lines in 2 files changed: 35 ins; 34 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/12855.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12855/head:pull/12855

PR: https://git.openjdk.org/jdk/pull/12855

From jvernee at openjdk.org  Mon Mar 13 16:40:18 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 13 Mar 2023 16:40:18 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v3]
In-Reply-To: <z1ogtf4v8v1oXW77do4v590wnNnczFYQsERCTXW3qeI=.a0511aba-5e5e-4074-ba43-373f3d0708f8@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com>
 <HT8kQfjS98dYHeAMcNL5latokRiw3YK8npxl5yCD4hw=.28b19bac-cbfa-4461-a1db-c899c55b7485@github.com>
 <wBVqRDFM23KM8fjjPtUFNdW56FYsSpvOAVvHmpdjbzo=.7c429606-ac19-4f36-8e25-459534983924@github.com>
 <QMh_faUf_LLUf68WrZiFxmPHiFcHDBfKDg3g-oekBeg=.096acd06-65c4-4357-ad4a-4089b5478fff@github.com>
 <hJkc1ozy4f7BIvXZ_xQ3HRttVsBs0ceUIMmq4cDWrzQ=.bc3223f5-cb33-46c7-9708-ab40ba5943b0@github.com>
 <mknfp22D3MdgwuitW4rYeIdz2S43a8wQdSmLerF2yO0=.94e5cf61-b2b8-41f3-b44e-0bde47b33bfc@github.com>
 <AOvm3Axl3yZLOa-A0ikaRQY7el-CsXTm0TJyNx-gkQk=.9d4cf018-f0a3-49d3-ad0d-d3018725fccf@github.com>
 <z1ogtf4v8v1oXW77do4v590wnNnczFYQsERCTXW3qeI=.a0511aba-5e5e-4074-ba43-373f3d0708f8@github.com>
Message-ID: <1OXigMWnfCHCkxCI3D29NpgIpgG36Ltlnry1eytOPow=.5f423637-0a12-454e-a31c-57b2fc11123f@github.com>

On Mon, 13 Mar 2023 16:20:22 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> I guess I should add a couple of Upcalls to my new test. Otherwise, I have only planned to fix TestArrayStructs. Further changes (and maybe new tests) can still get done when working on Big Endian / AIX or when there is a demand.

Okay. The reason I ask is because we are looking to get started with the JEP PR, but it might be nice to wrap up this PR first, to avoid any merge conflicts. I also have https://github.com/openjdk/jdk/pull/12883 which would need changes to the PPC call arranger/linker as well (though, it's a pretty simple refactor). I'm trying to figure out what the best order to do things in is.

> I'm currently wondering about the TestArrayStructs failures. Passing arrays with up to 7 elements seems to work fine. When I pass 8 elements, the last element of capturedArgs gets observed as 0. When I pass more than 8 elements, element 5 and 6 of capturedArgs get observed as 0.
DowncallLinker.invokeInterpBindings has the correct args, but UpcallLinker.invokeInterpBindings doesn't receive the correct values as lowLevelArgs. They contain the wrong zeros. The remaining elements look correct.
Do you have an idea what could be going wrong? Otherwise, I'll have to continue debugging.

This sounds like there might be a mismatch between the Java and native side. I suggest looking at the assembly generated for the native function for the failing case, and seeing if it matches what is generated by CallArranger. Here is also where adding a CallArranger test can be useful (in test/jdk/java/foreign/callarranger), to test whether the resulting bindings match your expectation for that function descriptor.

Also, you might want to check the layout the native compiler uses for the particular struct, and verify that it matches the Java side. (i.e. there's no weird padding or something, it's just a struct of 8 bytes).

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From jcking at openjdk.org  Mon Mar 13 16:47:32 2023
From: jcking at openjdk.org (Justin King)
Date: Mon, 13 Mar 2023 16:47:32 GMT
Subject: RFR: JDK-8303184: ZGC incompatible with ASan
Message-ID: <Z-3N8esxFJdyUw2tYv1Kk1S-j8wnrB-cXI9Bwg0ASqM=.70504f49-3530-4952-8180-b78a5e224ca8@github.com>

Update ZGC to work with ASan and fix missing LSan root region registration for ZGC.

Currently all ZGC tests will fail on x86 with ASan enabled, as it is unable to reserve the address regions necessary due to overlap with ASan. x86 does not appear to have the address layout detection logic of the other architectures. Other alternatives are port the address layout detection logic to x86 (I was not comfortable doing this) or just disable ZGC when building Hotspot with ASan.

-------------

Commit messages:
 - Merge remote-tracking branch 'upstream/master' into asan-zgc
 - Register MmapArrayAllocator allocations with LSan
 - Force ZGC to layout 3 with ASan

Changes: https://git.openjdk.org/jdk/pull/13000/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13000&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303184
  Stats: 18 lines in 2 files changed: 16 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13000.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/13000/head:pull/13000

PR: https://git.openjdk.org/jdk/pull/13000

From coleenp at openjdk.org  Mon Mar 13 16:51:20 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 13 Mar 2023 16:51:20 GMT
Subject: RFR: 8292818: replace 96-bit representation for field metadata
 with variable-sized streams [v3]
In-Reply-To: <fBYw2BQ75TAbqosMBM-_LOnkatqy6uOwpDfOpa7yN30=.441cba80-1f96-4e0b-bbc8-f43e1818113e@github.com>
References: <vdiacOO3JUyy4sWGkDXNBMUT7cG3XYe79mOvYru9uMM=.9c556675-7ffd-4c09-a428-6d64dffef209@github.com>
 <fBYw2BQ75TAbqosMBM-_LOnkatqy6uOwpDfOpa7yN30=.441cba80-1f96-4e0b-bbc8-f43e1818113e@github.com>
Message-ID: <pHOWhdOOeyYl4TR-ycmfb_udJErWPQKsYHh_7kP9NCo=.511d0c43-0020-403d-8777-fa2b61c22e97@github.com>

On Mon, 13 Mar 2023 16:26:06 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Please review this change re-implementing the FieldInfo data structure.
>> 
>> The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency.
>> 
>> The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information).
>> 
>> More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818
>> 
>> Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM.
>> 
>> The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format.
>> 
>> Tested with mach5, tier 1 to 7.
>> 
>> Thank you.
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   SA additional caching from Chris Plummer

Most minor comments but one .inline.hpp still in an hpp file.

I should point out that I only skimmed the SA and JVMCI changes.

src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 2653:

> 2651:   }
> 2652:   InstanceKlass* iklass = InstanceKlass::cast(klass);
> 2653:   if (index < 0 ||index > iklass->total_fields_count()) {

nit: need space after ||

src/hotspot/share/oops/fieldInfo.cpp line 45:

> 43: }
> 44: 
> 45: void FieldInfo::print_from_growable_array(GrowableArray<FieldInfo>* array, outputStream* os, ConstantPool* cp) {

For consistency, can you make the outputStream parameter first?

src/hotspot/share/oops/instanceKlass.hpp line 32:

> 30: #include "oops/constMethod.hpp"
> 31: #include "oops/constantPool.hpp"
> 32: #include "oops/fieldInfo.inline.hpp"

This shouldn't have an inline.hpp inclusion.

src/hotspot/share/runtime/vmStructs.cpp line 2304:

> 2302:   declare_constant(FieldInfo::FieldFlags::_ff_generic)                    \
> 2303:   declare_constant(FieldInfo::FieldFlags::_ff_stable)                     \
> 2304:   declare_constant(FieldInfo::FieldFlags::_ff_contended)                  \

If there are flags that SA doesn't use, like contended, I don't think they should be included in the information that we pass to SA.

-------------

Changes requested by coleenp (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12855

From coleenp at openjdk.org  Mon Mar 13 16:51:25 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 13 Mar 2023 16:51:25 GMT
Subject: RFR: 8292818: replace 96-bit representation for field metadata
 with variable-sized streams [v3]
In-Reply-To: <ADBnYiuSVseJNe6EeCnBwJQksyGM5Clvs5TV3BfNm78=.a15ee148-2fc4-4ab6-8766-17bc4e782222@github.com>
References: <vdiacOO3JUyy4sWGkDXNBMUT7cG3XYe79mOvYru9uMM=.9c556675-7ffd-4c09-a428-6d64dffef209@github.com>
 <duJxLMpZeS9KBS839JUNLQPb7u7cBzbFxk4CcmZGdoc=.4704e44a-2680-44e3-93c0-33bb575e9f28@github.com>
 <ADBnYiuSVseJNe6EeCnBwJQksyGM5Clvs5TV3BfNm78=.a15ee148-2fc4-4ab6-8766-17bc4e782222@github.com>
Message-ID: <ZpiVj9x2h6HN5IKkhvmUUTJ_aCiZFAdEusFK912JMXA=.850087e0-27bd-4c0f-8a77-debdd848ec7a@github.com>

On Thu, 9 Mar 2023 20:49:04 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> src/hotspot/share/classfile/classFileParser.cpp line 1491:
>> 
>>> 1489:   _temp_field_info = new GrowableArray<FieldInfo>(total_fields);
>>> 1490: 
>>> 1491:   ResourceMark rm(THREAD);
>> 
>> Is the ResourceMark ok here or should it go before allocating _temp_field_info ?
>
> _temp_field_info must survive after ClassFileParser::parse_fields() has returned, so definitively after the allocation of _temp_field_info. That being said, I don't see any reason to have a ResourceMark here, probably a remain of some debugging/tracing code. I'll remove it.

ok, good.  The ResourceMark might be a problem with the GrowableArray if it grows.

>> src/hotspot/share/classfile/classFileParser.cpp line 1608:
>> 
>>> 1606:       fflags.update_injected(true);
>>> 1607:       AccessFlags aflags;
>>> 1608:       FieldInfo fi(aflags, (u2)(injected[n].name_index), (u2)(injected[n].signature_index), 0, fflags);
>> 
>> I don't know why there's a cast here until I read more.  If the FieldInfo name_index and signature_index fields are only u2 sized, could you pass this as an int and then in the constructor assert that the value doesn't overflow u2 instead?
>
> The type of name_index and signature_index is const vmSymbolID, because they names and signatures of injected fields do not come from a constant pool, but from the vmSymbol array.

ok the cast is fine here.

>> src/hotspot/share/oops/fieldStreams.hpp line 104:
>> 
>>> 102:     AccessFlags flags;
>>> 103:     flags.set_flags(field()->access_flags());
>>> 104:     return flags;
>> 
>> Did this used to do this for a reason?
>
> Using the setter rather than the constructor filters out the VM defined flags and keeps only the flags from the class file.

I see, thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/12855

From coleenp at openjdk.org  Mon Mar 13 16:51:29 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 13 Mar 2023 16:51:29 GMT
Subject: RFR: 8292818: replace 96-bit representation for field metadata
 with variable-sized streams [v3]
In-Reply-To: <duJxLMpZeS9KBS839JUNLQPb7u7cBzbFxk4CcmZGdoc=.4704e44a-2680-44e3-93c0-33bb575e9f28@github.com>
References: <vdiacOO3JUyy4sWGkDXNBMUT7cG3XYe79mOvYru9uMM=.9c556675-7ffd-4c09-a428-6d64dffef209@github.com>
 <duJxLMpZeS9KBS839JUNLQPb7u7cBzbFxk4CcmZGdoc=.4704e44a-2680-44e3-93c0-33bb575e9f28@github.com>
Message-ID: <vm4nBuY8MKcoOQk0P41hoSSQ60OyjYgJh-1_pPVVJEI=.96abb40b-b676-49a9-b411-68d034f10440@github.com>

On Wed, 8 Mar 2023 15:53:03 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   SA additional caching from Chris Plummer
>
> src/hotspot/share/classfile/classFileParser.cpp line 1634:
> 
>> 1632:       for(int i = 0; i < _temp_field_info->length(); i++) {
>> 1633:         name = _temp_field_info->adr_at(i)->name(_cp);
>> 1634:         sig = _temp_field_info->adr_at(i)->signature(_cp);
> 
> This checking for duplicates looks like a good candidate for a separate function because parse_fields is so long.  I'm adding this comment to remember to file an RFE to look into making this function shorter and factor out this code.

Filed a cleanup RFE https://bugs.openjdk.org/browse/JDK-8304069

-------------

PR: https://git.openjdk.org/jdk/pull/12855

From jvernee at openjdk.org  Mon Mar 13 16:57:43 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 13 Mar 2023 16:57:43 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v14]
In-Reply-To: <IwJ-UTPgCC3n5uLzRADxzt1Q8rIIcHwXetuG4hhhqMc=.a6835dde-3c2f-4cc8-bdaf-25507334066b@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <IwJ-UTPgCC3n5uLzRADxzt1Q8rIIcHwXetuG4hhhqMc=.a6835dde-3c2f-4cc8-bdaf-25507334066b@github.com>
Message-ID: <nsHLsGIVjZkm2Mu_JiTSVC3XBb7mWG342rao7moO7kY=.2ccd9fa3-fe88-4583-9219-52fdf38a49e4@github.com>

On Thu, 9 Mar 2023 17:29:37 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
>> 
>> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
>> 
>> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
>> 
>> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Will get addressed separately: [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
>> 
>> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
>> 
>> I had to make changes to shared code and code for other platforms:
>> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
>> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
>> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
>> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
>> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Introduce ABIv2CallArranger for linux ppc64le.

test/jdk/java/foreign/TestHFA.java line 32:

> 30:  * @enablePreview
> 31:  * @requires ((os.arch == "amd64" | os.arch == "x86_64") & sun.arch.data.model == "64") | os.arch == "aarch64" | os.arch == "ppc64le" | os.arch == "riscv64"
> 32:  * @requires !vm.musl

Not sure if this test should be disabled on musl?

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From inakonechnyy at openjdk.org  Mon Mar 13 17:29:44 2023
From: inakonechnyy at openjdk.org (Ilarion Nakonechnyy)
Date: Mon, 13 Mar 2023 17:29:44 GMT
Subject: Integrated: 8302491: NoClassDefFoundError omits the original cause of
 an error
In-Reply-To: <L-pfBfK4TKl5KUWpPEcbs-IkhwimgJZ-SOrbSG3exeA=.5e883f22-de9b-4eec-9e98-8ee954a7996b@github.com>
References: <L-pfBfK4TKl5KUWpPEcbs-IkhwimgJZ-SOrbSG3exeA=.5e883f22-de9b-4eec-9e98-8ee954a7996b@github.com>
Message-ID: <1TzQu3SHM08hktYVu5nfIDA9IvklKfOBdl_PvZ5iX_c=.77c1323c-a476-4037-a7ef-b36fb4eb248a@github.com>

On Tue, 14 Feb 2023 21:58:01 GMT, Ilarion Nakonechnyy <inakonechnyy at openjdk.org> wrote:

> The proposed approach added a new function for getting the cause of an exception -`java_lang_Throwable::get_cause_simple `, that gets called within `InstanceKlass::add_initialization_error`  if an old one `java_lang_Throwable::get_cause_with_stack_trace` didn't succeed because of an exception during the VM call. The simple function doesn't call the VM for getting a stack trace but fills in any other information about an exception.
> 
> Besides that, the discovering information about an exception was added to `ConstantPoolCacheEntry::save_and_throw_indy_exc` function. 
> 
> Jtreg for reproducing the issue also was added to the commit. 
> The commit was tested with tier1 tests.

This pull request has now been integrated.

Changeset: 56851075
Author:    Ilarion Nakonechnyy <inakonechnyy at openjdk.org>
Committer: Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5685107579f0f00b5eae881311315cec34c1ddcb
Stats:     57 lines in 3 files changed: 21 ins; 13 del; 23 mod

8302491: NoClassDefFoundError omits the original cause of an error

Reviewed-by: coleenp, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/12566

From fparain at openjdk.org  Mon Mar 13 17:32:35 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 13 Mar 2023 17:32:35 GMT
Subject: RFR: 8292818: replace 96-bit representation for field metadata
 with variable-sized streams [v3]
In-Reply-To: <pHOWhdOOeyYl4TR-ycmfb_udJErWPQKsYHh_7kP9NCo=.511d0c43-0020-403d-8777-fa2b61c22e97@github.com>
References: <vdiacOO3JUyy4sWGkDXNBMUT7cG3XYe79mOvYru9uMM=.9c556675-7ffd-4c09-a428-6d64dffef209@github.com>
 <fBYw2BQ75TAbqosMBM-_LOnkatqy6uOwpDfOpa7yN30=.441cba80-1f96-4e0b-bbc8-f43e1818113e@github.com>
 <pHOWhdOOeyYl4TR-ycmfb_udJErWPQKsYHh_7kP9NCo=.511d0c43-0020-403d-8777-fa2b61c22e97@github.com>
Message-ID: <-zydTVMcZURxcBOz8Rj5Gi0DUtqkANHuYnSUStzY0dY=.2c84dc16-4d7a-44fc-a27c-0ffb9f56bec8@github.com>

On Mon, 13 Mar 2023 16:41:05 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   SA additional caching from Chris Plummer
>
> src/hotspot/share/runtime/vmStructs.cpp line 2304:
> 
>> 2302:   declare_constant(FieldInfo::FieldFlags::_ff_generic)                    \
>> 2303:   declare_constant(FieldInfo::FieldFlags::_ff_stable)                     \
>> 2304:   declare_constant(FieldInfo::FieldFlags::_ff_contended)                  \
> 
> If there are flags that SA doesn't use, like contended, I don't think they should be included in the information that we pass to SA.

The contended flag is required to be able to decode the compressed stream, because it signals the presence of an optional part of a field description. The only flags that was not required for the decoding of the stream and was not used by the SA was Stable, and I'll remove it in the next commit.

-------------

PR: https://git.openjdk.org/jdk/pull/12855

From xliu at openjdk.org  Mon Mar 13 17:32:39 2023
From: xliu at openjdk.org (Xin Liu)
Date: Mon, 13 Mar 2023 17:32:39 GMT
Subject: Withdrawn: 8301136: Improve unlink() and unlink_all() of
 ResourceHashtableBase
In-Reply-To: <Tqq1KY1B3iGRAVtESg4dEOP6cVZWkLVU6Rc_pHh9Uwo=.d2581151-724d-4e38-a24d-a78b94332356@github.com>
References: <Tqq1KY1B3iGRAVtESg4dEOP6cVZWkLVU6Rc_pHh9Uwo=.d2581151-724d-4e38-a24d-a78b94332356@github.com>
Message-ID: <Ex6blZrtKZHV0O6bcxVJIOanTc_04tXohrTZdaz-p_I=.64df655c-8ab8-4ea3-bef0-b88ad572f553@github.com>

On Thu, 26 Jan 2023 08:15:37 GMT, Xin Liu <xliu at openjdk.org> wrote:

> 1. Apply the same idea of JDK-8300184 to unlink().
> 2. Because ResourceHashtableBase doesn't support copy assignment, client of it has to purge all elements first when it needs to assign it. We would like provide a specialized version called 'unlink_all()'.  We don't need to update each node's _next in this case. We only nullify all buckets. 
> 3. This patch also provides a specialized version of unlink_all() for destructor. We don't even update buckets. it's dead anyway.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/12213

From fparain at openjdk.org  Mon Mar 13 17:45:17 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 13 Mar 2023 17:45:17 GMT
Subject: RFR: 8303150: DCmd framework unnecessarily creates a DCmd instance
 on registration
In-Reply-To: <TNyX996lKlRcmTijRTN0VUZBcNBt2DXeMPhDBjaa0NQ=.160293b7-4570-43a5-af9e-d9cb02022820@github.com>
References: <TNyX996lKlRcmTijRTN0VUZBcNBt2DXeMPhDBjaa0NQ=.160293b7-4570-43a5-af9e-d9cb02022820@github.com>
Message-ID: <Un86BcZr_2byTMFavkCIj84REkYMBs-A9EqDWRVj0p8=.5caf7a1a-c98b-485e-b6b9-f38c78bc99f6@github.com>

On Mon, 13 Mar 2023 01:19:50 GMT, David Holmes <dholmes at openjdk.org> wrote:

> When DCmd factories are registered, the factory is passed the number of arguments taken by the DCmd - using a template method `get_num_arguments`. For DCmds that don't extend DCmdWithParser there has to be a static `num_arguments()` method in that class. For DCmds that do extend DCmdWithParser the logic instantiates an instance of the DCmd, extracts its parser and calls its `num_arguments` method which dynamically counts the number of defined arguments.
> 
> Creating an instance of each DCmd and dynamically counting arguments is inefficient and unnecessary, the number of arguments is statically known and easily expressed (in fact many of the JFR DCmds already statically define this). So we add the static `num_arguments()` method to each class that needs it and return the statically counted number of arguments. To ensure the static number and actual number don't get out-of-sync, we keep the original dynamic logic for use in debug builds to assert that the static and dynamic counts are the same. The assert will trigger during a debug build if something does get out of sync, for example if a new DCmd (extending DCmdWithParser) were added but didn't define the static `num_arguments()` method.
> 
> A number of DCmd classes were unnecessarily defining their own dynamic version of `num_arguments` and these are now removed.
> 
> In the template method I use `ENABLE_IF(std::is_convertible<T, DCmd>::value)` to check we only call this on DCmd classes. This may be unnecessary but it seemed consistent with the other template methods. Note that `std::is_base_of` only works for immediate super types.
> 
> Testing: tiers 1-4
> 
> Performance: in theory we should see some improvement in startup; in practice it is barely noticeable.
> 
> Thanks.

The concern during the initial implementation was that the value returned by num_arguments() and the real number of arguments could become out of sync, but your solution to check that they are consistent only on debug builds addresses this concern.
Thank you for fixing this!

-------------

Marked as reviewed by fparain (Committer).

PR: https://git.openjdk.org/jdk/pull/12994

From cjplummer at openjdk.org  Mon Mar 13 18:02:28 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 13 Mar 2023 18:02:28 GMT
Subject: RFR: 8292818: replace 96-bit representation for field metadata
 with variable-sized streams [v3]
In-Reply-To: <-zydTVMcZURxcBOz8Rj5Gi0DUtqkANHuYnSUStzY0dY=.2c84dc16-4d7a-44fc-a27c-0ffb9f56bec8@github.com>
References: <vdiacOO3JUyy4sWGkDXNBMUT7cG3XYe79mOvYru9uMM=.9c556675-7ffd-4c09-a428-6d64dffef209@github.com>
 <fBYw2BQ75TAbqosMBM-_LOnkatqy6uOwpDfOpa7yN30=.441cba80-1f96-4e0b-bbc8-f43e1818113e@github.com>
 <pHOWhdOOeyYl4TR-ycmfb_udJErWPQKsYHh_7kP9NCo=.511d0c43-0020-403d-8777-fa2b61c22e97@github.com>
 <-zydTVMcZURxcBOz8Rj5Gi0DUtqkANHuYnSUStzY0dY=.2c84dc16-4d7a-44fc-a27c-0ffb9f56bec8@github.com>
Message-ID: <yGZXy4F0CGBIJA1T9CV_dGVENgyBK3k5FRGHVlTZa3g=.0fb8f75e-44ee-4569-8065-aa6d59cdaed8@github.com>

On Mon, 13 Mar 2023 17:29:28 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> src/hotspot/share/runtime/vmStructs.cpp line 2304:
>> 
>>> 2302:   declare_constant(FieldInfo::FieldFlags::_ff_generic)                    \
>>> 2303:   declare_constant(FieldInfo::FieldFlags::_ff_stable)                     \
>>> 2304:   declare_constant(FieldInfo::FieldFlags::_ff_contended)                  \
>> 
>> If there are flags that SA doesn't use, like contended, I don't think they should be included in the information that we pass to SA.
>
> The contended flag is required to be able to decode the compressed stream, because it signals the presence of an optional part of a field description. The only flag that was not required for the decoding of the stream and was not used by the SA was Stable, and I'll remove it in the next commit.

Leaving it in allows the field to be displayed if an SA user ever dumps a FieldFlags object. Generally speaking it is good to keep these structs complete, or at least complete with any info that might be useful when debugging with SA.

-------------

PR: https://git.openjdk.org/jdk/pull/12855

From rkennke at openjdk.org  Mon Mar 13 18:43:41 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 13 Mar 2023 18:43:41 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v22]
In-Reply-To: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
Message-ID: <KxISxLED5fT6GGQrHtV2lODiK_t7vrGm7wqP7mbD0jg=.88da59f8-cb52-4a8c-8686-b06799c72822@github.com>

> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
> 
> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p
 rotocols.
> 
> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
> 
> 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
> 
> 
> Testing:
>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
> 
> ### Performance
> 
> #### Simple Microbenchmark
> 
> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
> 
> |  | x86_64 | aarch64 |
> | -- | -- | -- |
> | -UseFastLocking | 20.651 | 20.764 |
> | +UseFastLocking | 18.896 | 18.908 |
> 
> 
> #### Renaissance
> 
> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
> -- | -- | -- | -- | -- | -- | -- | --
> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Re-design LockStack for faster lock-stack depth-check

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10907/files
  - new: https://git.openjdk.org/jdk/pull/10907/files/5fe2afcf..0b7be891

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=20-21

  Stats: 251 lines in 34 files changed: 28 ins; 144 del; 79 mod
  Patch: https://git.openjdk.org/jdk/pull/10907.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10907/head:pull/10907

PR: https://git.openjdk.org/jdk/pull/10907

From eosterlund at openjdk.org  Mon Mar 13 18:43:55 2023
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 13 Mar 2023 18:43:55 GMT
Subject: RFR: JDK-8303184: ZGC incompatible with ASan
In-Reply-To: <Z-3N8esxFJdyUw2tYv1Kk1S-j8wnrB-cXI9Bwg0ASqM=.70504f49-3530-4952-8180-b78a5e224ca8@github.com>
References: <Z-3N8esxFJdyUw2tYv1Kk1S-j8wnrB-cXI9Bwg0ASqM=.70504f49-3530-4952-8180-b78a5e224ca8@github.com>
Message-ID: <usuPCg68KdxipokW14Aoyo88WgRoVxhhVtDKE0QTXDA=.5439bb9a-8014-43c1-8bf2-192cb33121ab@github.com>

On Mon, 13 Mar 2023 16:37:41 GMT, Justin King <jcking at openjdk.org> wrote:

> Update ZGC to work with ASan and fix missing LSan root region registration for ZGC.
> 
> Currently all ZGC tests will fail on x86 with ASan enabled, as it is unable to reserve the address regions necessary due to overlap with ASan. x86 does not appear to have the address layout detection logic of the other architectures. Other alternatives are port the address layout detection logic to x86 (I was not comfortable doing this) or just disable ZGC when building Hotspot with ASan.

Have you tried if this a problem with generational ZGC? (zgc_generational branch in the zgc repo)

-------------

PR: https://git.openjdk.org/jdk/pull/13000

From fparain at openjdk.org  Mon Mar 13 18:51:17 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 13 Mar 2023 18:51:17 GMT
Subject: RFR: 8292818: replace 96-bit representation for field metadata
 with variable-sized streams [v4]
In-Reply-To: <vdiacOO3JUyy4sWGkDXNBMUT7cG3XYe79mOvYru9uMM=.9c556675-7ffd-4c09-a428-6d64dffef209@github.com>
References: <vdiacOO3JUyy4sWGkDXNBMUT7cG3XYe79mOvYru9uMM=.9c556675-7ffd-4c09-a428-6d64dffef209@github.com>
Message-ID: <hAGW4he3pjU6G9IuyygughaiDUL9vKNHzKcURWD4tSI=.b67e5661-9978-4d9d-850e-0a6399de5a64@github.com>

> Please review this change re-implementing the FieldInfo data structure.
> 
> The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency.
> 
> The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information).
> 
> More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818
> 
> Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM.
> 
> The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format.
> 
> Tested with mach5, tier 1 to 7.
> 
> Thank you.

Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:

  Fixes includes and style

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12855/files
  - new: https://git.openjdk.org/jdk/pull/12855/files/322b626d..12b4f1b4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12855&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12855&range=02-03

  Stats: 9 lines in 5 files changed: 3 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/12855.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12855/head:pull/12855

PR: https://git.openjdk.org/jdk/pull/12855

From fparain at openjdk.org  Mon Mar 13 18:51:20 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 13 Mar 2023 18:51:20 GMT
Subject: RFR: 8292818: replace 96-bit representation for field metadata
 with variable-sized streams [v3]
In-Reply-To: <yGZXy4F0CGBIJA1T9CV_dGVENgyBK3k5FRGHVlTZa3g=.0fb8f75e-44ee-4569-8065-aa6d59cdaed8@github.com>
References: <vdiacOO3JUyy4sWGkDXNBMUT7cG3XYe79mOvYru9uMM=.9c556675-7ffd-4c09-a428-6d64dffef209@github.com>
 <fBYw2BQ75TAbqosMBM-_LOnkatqy6uOwpDfOpa7yN30=.441cba80-1f96-4e0b-bbc8-f43e1818113e@github.com>
 <pHOWhdOOeyYl4TR-ycmfb_udJErWPQKsYHh_7kP9NCo=.511d0c43-0020-403d-8777-fa2b61c22e97@github.com>
 <-zydTVMcZURxcBOz8Rj5Gi0DUtqkANHuYnSUStzY0dY=.2c84dc16-4d7a-44fc-a27c-0ffb9f56bec8@github.com>
 <yGZXy4F0CGBIJA1T9CV_dGVENgyBK3k5FRGHVlTZa3g=.0fb8f75e-44ee-4569-8065-aa6d59cdaed8@github.com>
Message-ID: <wfBHaLHqWov0clHZympuYcy1n-tkftoumy5c4FMz9Bk=.4154cc5f-00c5-4088-9402-5bc3c760db43@github.com>

On Mon, 13 Mar 2023 17:59:03 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> The contended flag is required to be able to decode the compressed stream, because it signals the presence of an optional part of a field description. The only flag that was not required for the decoding of the stream and was not used by the SA was Stable, and I'll remove it in the next commit.
>
> Leaving it in allows the field to be displayed if an SA user ever dumps a FieldFlags object. Generally speaking it is good to keep these structs complete, or at least complete with any info that might be useful when debugging with SA.

The "stable" flag and the related methods have been preserved in the last commit.

-------------

PR: https://git.openjdk.org/jdk/pull/12855

From jcking at openjdk.org  Mon Mar 13 19:04:53 2023
From: jcking at openjdk.org (Justin King)
Date: Mon, 13 Mar 2023 19:04:53 GMT
Subject: RFR: JDK-8303184: ZGC incompatible with ASan
In-Reply-To: <usuPCg68KdxipokW14Aoyo88WgRoVxhhVtDKE0QTXDA=.5439bb9a-8014-43c1-8bf2-192cb33121ab@github.com>
References: <Z-3N8esxFJdyUw2tYv1Kk1S-j8wnrB-cXI9Bwg0ASqM=.70504f49-3530-4952-8180-b78a5e224ca8@github.com>
 <usuPCg68KdxipokW14Aoyo88WgRoVxhhVtDKE0QTXDA=.5439bb9a-8014-43c1-8bf2-192cb33121ab@github.com>
Message-ID: <6j54xRLZM57ODtKz4cAqdDkG2xVwr1fUImlvp35W-4A=.9969f3da-2403-4b44-8f11-2a8da4734fcc@github.com>

On Mon, 13 Mar 2023 18:41:27 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> Have you tried if this a problem with generational ZGC? (zgc_generational branch in the zgc repo)

I looked at generational ZGC code, it looks to be afflicted by the same thing. https://github.com/openjdk/zgc/blob/zgc_generational/src/hotspot/cpu/x86/gc/z/zAddress_x86.cpp

-------------

PR: https://git.openjdk.org/jdk/pull/13000

From kvn at openjdk.org  Mon Mar 13 19:26:08 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 13 Mar 2023 19:26:08 GMT
Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v5]
In-Reply-To: <gYzscs7Y8uz2l_5FIsqAuKebVsMnJpSwbIH6C_uzdv4=.f33d8432-c1fc-45a3-80f7-1159cdb87480@github.com>
References: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>
 <gYzscs7Y8uz2l_5FIsqAuKebVsMnJpSwbIH6C_uzdv4=.f33d8432-c1fc-45a3-80f7-1159cdb87480@github.com>
Message-ID: <94K1Ap5beXB44rCRuHL4PZfbSFizd93ZrFlyG9sTXj4=.e89d2ec7-f8ff-4be7-8f19-dbc2034f1934@github.com>

On Wed, 8 Mar 2023 22:59:23 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for accessing annotations. The main differences from `java.lang.reflect.AnnotatedElement` are:
>> * Each `Annotated` method explicitly specifies the annotation type(s) for which it wants annotation data. That is, there is no direct equivalent of `AnnotatedElement.getAnnotations()`.
>> * Annotation data is returned in a map-like object (of type `jdk.vm.ci.meta.AnnotationData`) instead of in an `Annotation` object. This works better for libgraal as it avoids the need for annotation types to be loaded and included in libgraal.
>>  
>> To demonstrate the new API, here's an example in terms `java.lang.reflect.AnnotatedElement` (which `ResolvedJavaType` implements):
>> 
>>     ResolvedJavaMethod method = ...;
>>     ExplodeLoop a = method.getAnnotation(ExplodeLoop.class);
>>     return switch (a.kind()) {
>>         case FULL_UNROLL -> LoopExplosionKind.FULL_UNROLL;
>>         case FULL_UNROLL_UNTIL_RETURN -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>>         ...
>>     }
>> 
>> 
>> The same code using the new API:
>> 
>> 
>>     ResolvedJavaMethod method = ...;
>>     ResolvedJavaType explodeLoopType = ...;
>>     AnnotationData a = method.getAnnotationDataFor(explodeLoopType);
>>     return switch (a.getEnum("kind").getName()) {
>>         case "FULL_UNROLL" -> LoopExplosionKind.FULL_UNROLL;
>>         case "FULL_UNROLL_UNTIL_RETURN" -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>>         ...
>>     }
>> 
>> 
>> The implementation relies on new methods in `jdk.internal.vm.VMSupport` for parsing annotations and serializing/deserializing to/from a byte array. This allows the annotation data to be passed from the HotSpot heap to the libgraal heap.
>
> Doug Simon 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 remote-tracking branch 'openjdk-jdk/master' into JDK-8303431
>  - switched to use of lists and maps instead of arrays
>  - fixed whitespace
>  - added support for inherited annotations
>  - Merge branch 'master' into JDK-8303431
>  - made AnnotationDataDecoder package-private
>  - add annotation API to JVMCI

test/jdk/jdk/internal/vm/TestTranslatedException.java line 61:

> 59:         encodeDecode(throwable);
> 60:     }
> 61: 

Why this was removed?

-------------

PR: https://git.openjdk.org/jdk/pull/12810

From kvn at openjdk.org  Mon Mar 13 19:31:20 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 13 Mar 2023 19:31:20 GMT
Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v5]
In-Reply-To: <gYzscs7Y8uz2l_5FIsqAuKebVsMnJpSwbIH6C_uzdv4=.f33d8432-c1fc-45a3-80f7-1159cdb87480@github.com>
References: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>
 <gYzscs7Y8uz2l_5FIsqAuKebVsMnJpSwbIH6C_uzdv4=.f33d8432-c1fc-45a3-80f7-1159cdb87480@github.com>
Message-ID: <4aRnY_K2BIlWr4MII9PaMop0Qi2gqcvSSn7Heqlxuvw=.063e4544-5fcd-4fab-9b2c-3bcaeffcd381@github.com>

On Wed, 8 Mar 2023 22:59:23 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for accessing annotations. The main differences from `java.lang.reflect.AnnotatedElement` are:
>> * Each `Annotated` method explicitly specifies the annotation type(s) for which it wants annotation data. That is, there is no direct equivalent of `AnnotatedElement.getAnnotations()`.
>> * Annotation data is returned in a map-like object (of type `jdk.vm.ci.meta.AnnotationData`) instead of in an `Annotation` object. This works better for libgraal as it avoids the need for annotation types to be loaded and included in libgraal.
>>  
>> To demonstrate the new API, here's an example in terms `java.lang.reflect.AnnotatedElement` (which `ResolvedJavaType` implements):
>> 
>>     ResolvedJavaMethod method = ...;
>>     ExplodeLoop a = method.getAnnotation(ExplodeLoop.class);
>>     return switch (a.kind()) {
>>         case FULL_UNROLL -> LoopExplosionKind.FULL_UNROLL;
>>         case FULL_UNROLL_UNTIL_RETURN -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>>         ...
>>     }
>> 
>> 
>> The same code using the new API:
>> 
>> 
>>     ResolvedJavaMethod method = ...;
>>     ResolvedJavaType explodeLoopType = ...;
>>     AnnotationData a = method.getAnnotationDataFor(explodeLoopType);
>>     return switch (a.getEnum("kind").getName()) {
>>         case "FULL_UNROLL" -> LoopExplosionKind.FULL_UNROLL;
>>         case "FULL_UNROLL_UNTIL_RETURN" -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>>         ...
>>     }
>> 
>> 
>> The implementation relies on new methods in `jdk.internal.vm.VMSupport` for parsing annotations and serializing/deserializing to/from a byte array. This allows the annotation data to be passed from the HotSpot heap to the libgraal heap.
>
> Doug Simon 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 remote-tracking branch 'openjdk-jdk/master' into JDK-8303431
>  - switched to use of lists and maps instead of arrays
>  - fixed whitespace
>  - added support for inherited annotations
>  - Merge branch 'master' into JDK-8303431
>  - made AnnotationDataDecoder package-private
>  - add annotation API to JVMCI

I looked on Hotspot, JVMCI and VMSupport.java changes. But you need  to ask Tom to look on JVMCI changes in details. And someone from core-libs who familiar with Annotations have to comment on your implementation in general because I am not expert.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12810

From rkennke at openjdk.org  Mon Mar 13 20:02:45 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 13 Mar 2023 20:02:45 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v23]
In-Reply-To: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
Message-ID: <P-iheLBjdOGikiJhK78k2BYcz-xhvu2n2i7WM4W4AXc=.453a4d91-bca3-429b-bbcc-d2a58fccb853@github.com>

> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
> 
> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p
 rotocols.
> 
> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
> 
> 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
> 
> 
> Testing:
>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
> 
> ### Performance
> 
> #### Simple Microbenchmark
> 
> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
> 
> |  | x86_64 | aarch64 |
> | -- | -- | -- |
> | -UseFastLocking | 20.651 | 20.764 |
> | +UseFastLocking | 18.896 | 18.908 |
> 
> 
> #### Renaissance
> 
> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
> -- | -- | -- | -- | -- | -- | -- | --
> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  X86 parts

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10907/files
  - new: https://git.openjdk.org/jdk/pull/10907/files/0b7be891..75db4f0a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=21-22

  Stats: 143 lines in 14 files changed: 0 ins; 124 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/10907.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10907/head:pull/10907

PR: https://git.openjdk.org/jdk/pull/10907

From pchilanomate at openjdk.org  Mon Mar 13 20:18:03 2023
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 13 Mar 2023 20:18:03 GMT
Subject: Integrated: 8303908: Add missing check in
 VTMS_transition_disable_for_all() for suspend mode
In-Reply-To: <MW-CIeSI8D3Opes0-cjiBHbvBuuUfKxhrZoEpRPylCg=.19babd2e-b3c6-48f7-a6ab-7d38f3211507@github.com>
References: <MW-CIeSI8D3Opes0-cjiBHbvBuuUfKxhrZoEpRPylCg=.19babd2e-b3c6-48f7-a6ab-7d38f3211507@github.com>
Message-ID: <fBo5IErZgUJ-lMA_1YsQsfbdXyUPbT793c_KvWvcbrQ=.85a0d83d-7383-46ce-95a6-790236da8453@github.com>

On Thu, 9 Mar 2023 18:55:06 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review this small fix. A suspender is a JvmtiVTMSTransitionDisabler monopolist, meaning VTMS_transition_disable_for_all() should not return while there is any active jvmtiVTMSTransitionDisabler. The code though is checking for active "all-disablers" but it's missing the check for active "single disablers".
> I attached a simple reproducer to the bug which I used to test the patch. Not sure if it was worth adding a test so the patch contains just the fix.
> 
> Thanks,
> Patricio

This pull request has now been integrated.

Changeset: a8f662ec
Author:    Patricio Chilano Mateo <pchilanomate at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a8f662ecb2cf13ba7fa499b9a9150da4318306a8
Stats:     3 lines in 1 file changed: 1 ins; 0 del; 2 mod

8303908: Add missing check in VTMS_transition_disable_for_all() for suspend mode

Reviewed-by: sspitsyn, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/12956

From dnsimon at openjdk.org  Mon Mar 13 20:27:09 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 13 Mar 2023 20:27:09 GMT
Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v5]
In-Reply-To: <94K1Ap5beXB44rCRuHL4PZfbSFizd93ZrFlyG9sTXj4=.e89d2ec7-f8ff-4be7-8f19-dbc2034f1934@github.com>
References: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>
 <gYzscs7Y8uz2l_5FIsqAuKebVsMnJpSwbIH6C_uzdv4=.f33d8432-c1fc-45a3-80f7-1159cdb87480@github.com>
 <94K1Ap5beXB44rCRuHL4PZfbSFizd93ZrFlyG9sTXj4=.e89d2ec7-f8ff-4be7-8f19-dbc2034f1934@github.com>
Message-ID: <fwDsQeAz3vY83ez7kR6mhPQZyt8G2_79CvH0zNdO7xw=.73efe51a-c021-4496-9e7a-7f6c3ac9c212@github.com>

On Mon, 13 Mar 2023 19:23:39 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Doug Simon 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 remote-tracking branch 'openjdk-jdk/master' into JDK-8303431
>>  - switched to use of lists and maps instead of arrays
>>  - fixed whitespace
>>  - added support for inherited annotations
>>  - Merge branch 'master' into JDK-8303431
>>  - made AnnotationDataDecoder package-private
>>  - add annotation API to JVMCI
>
> test/jdk/jdk/internal/vm/TestTranslatedException.java line 61:
> 
>> 59:         encodeDecode(throwable);
>> 60:     }
>> 61: 
> 
> Why this was removed?

Because it does exactly the same thing as `encodeDecodeTest`. It should have been cleaned up in the original PR that introduced this test.

-------------

PR: https://git.openjdk.org/jdk/pull/12810

From coleenp at openjdk.org  Mon Mar 13 20:42:29 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 13 Mar 2023 20:42:29 GMT
Subject: RFR: 8292818: replace 96-bit representation for field metadata
 with variable-sized streams [v4]
In-Reply-To: <hAGW4he3pjU6G9IuyygughaiDUL9vKNHzKcURWD4tSI=.b67e5661-9978-4d9d-850e-0a6399de5a64@github.com>
References: <vdiacOO3JUyy4sWGkDXNBMUT7cG3XYe79mOvYru9uMM=.9c556675-7ffd-4c09-a428-6d64dffef209@github.com>
 <hAGW4he3pjU6G9IuyygughaiDUL9vKNHzKcURWD4tSI=.b67e5661-9978-4d9d-850e-0a6399de5a64@github.com>
Message-ID: <3YhDOFYnbJ4QsrXUQbUQfFbXHb75eK1Mowuv9yYaXqE=.62fc2fd0-5384-440d-919a-1c59e9b2f3fb@github.com>

On Mon, 13 Mar 2023 18:51:17 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Please review this change re-implementing the FieldInfo data structure.
>> 
>> The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency.
>> 
>> The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information).
>> 
>> More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818
>> 
>> Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM.
>> 
>> The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format.
>> 
>> Tested with mach5, tier 1 to 7.
>> 
>> Thank you.
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixes includes and style

All my comments are addressed. Thank you! This is significant work.

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12855

From mdoerr at openjdk.org  Mon Mar 13 21:00:31 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 13 Mar 2023 21:00:31 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v3]
In-Reply-To: <1OXigMWnfCHCkxCI3D29NpgIpgG36Ltlnry1eytOPow=.5f423637-0a12-454e-a31c-57b2fc11123f@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com>
 <HT8kQfjS98dYHeAMcNL5latokRiw3YK8npxl5yCD4hw=.28b19bac-cbfa-4461-a1db-c899c55b7485@github.com>
 <wBVqRDFM23KM8fjjPtUFNdW56FYsSpvOAVvHmpdjbzo=.7c429606-ac19-4f36-8e25-459534983924@github.com>
 <QMh_faUf_LLUf68WrZiFxmPHiFcHDBfKDg3g-oekBeg=.096acd06-65c4-4357-ad4a-4089b5478fff@github.com>
 <hJkc1ozy4f7BIvXZ_xQ3HRttVsBs0ceUIMmq4cDWrzQ=.bc3223f5-cb33-46c7-9708-ab40ba5943b0@github.com>
 <mknfp22D3MdgwuitW4rYeIdz2S43a8wQdSmLerF2yO0=.94e5cf61-b2b8-41f3-b44e-0bde47b33bfc@github.com>
 <AOvm3Axl3yZLOa-A0ikaRQY7el-CsXTm0TJyNx-gkQk=.9d4cf018-f0a3-49d3-ad0d-d3018725fccf@github.com>
 <z1ogtf4v8v1oXW77do4v590wnNnczFYQsERCTXW3qeI=.a0511aba-5e5e-4074-ba43-373f3d0708f8@github.com>
 <1OXigMWnfCHCkxCI3D29NpgIpgG36Ltlnry1eytOPow=.5f423637-0a12-454e-a31c-57b2fc11123f@github.com>
Message-ID: <8I_sDu55v8ThrFyF4mMWbKOOKeGkfYvqo66JLNnULUY=.830fe48d-b65f-437c-82fa-9e7dac76c7ab@github.com>

On Mon, 13 Mar 2023 16:37:18 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> > I'm currently wondering about the TestArrayStructs failures. Passing arrays with up to 7 elements seems to work fine. When I pass 8 elements, the last element of capturedArgs gets observed as 0. When I pass more than 8 elements, element 5 and 6 of capturedArgs get observed as 0.
> > DowncallLinker.invokeInterpBindings has the correct args, but UpcallLinker.invokeInterpBindings doesn't receive the correct values as lowLevelArgs. They contain the wrong zeros. The remaining elements look correct.
> > Do you have an idea what could be going wrong? Otherwise, I'll have to continue debugging.
> 
> This sounds like there might be a mismatch between the Java and native side. I suggest looking at the assembly generated for the native function for the failing case, and seeing if it matches what is generated by CallArranger. Here is also where adding a CallArranger test can be useful (in test/jdk/java/foreign/callarranger), to test whether the resulting bindings match your expectation for that function descriptor.
> 
> Also, you might want to check the layout the native compiler uses for the particular struct, and verify that it matches the Java side. (i.e. there's no weird padding or something, it's just a struct of 8 bytes).

Note that argument and return value passing works. I'm getting all values back. So, the native side seems to be ok. Only (one or two) values in `returnBox` are broken.

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From coleenp at openjdk.org  Mon Mar 13 21:07:10 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 13 Mar 2023 21:07:10 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v2]
In-Reply-To: <-Kj1YJ_nRa4nJtaxg3UR8uWhde6vIG1Jl-FFakGnHy4=.a41c6149-912b-4a66-8b1e-634bd27cdebb@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <-Kj1YJ_nRa4nJtaxg3UR8uWhde6vIG1Jl-FFakGnHy4=.a41c6149-912b-4a66-8b1e-634bd27cdebb@github.com>
Message-ID: <33uTpOt8ALbYOl5axezzxriVn4V1h860H3YWEbJ-PDY=.429dbaaa-e75e-47fb-88aa-3bd451ee4662@github.com>

On Thu, 9 Mar 2023 21:18:19 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
>> 
>> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
>> 
>> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
>> 
>> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
>> 
>> This change supports the following platforms: x86, aarch64, PPC, and RISCV
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Interpreter optimization and comments

src/hotspot/cpu/x86/interp_masm_x86.cpp line 2075:

> 2073:   movptr(cache, Address(rbp, frame::interpreter_frame_cache_offset * wordSize));
> 2074:   movptr(cache, Address(cache, in_bytes(ConstantPoolCache::invokedynamic_entries_offset())));
> 2075:   if (is_power_of_2(sizeof(ResolvedIndyEntry))) {

This was a good suggestion but I wonder if we should assert ResolvedIndyEntry is a power of 2 so we know if we change the size and make it go the slower path?  Or is 32 bit not a power of two and we need this?

-------------

PR: https://git.openjdk.org/jdk/pull/12778

From coleenp at openjdk.org  Mon Mar 13 21:17:06 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 13 Mar 2023 21:17:06 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v2]
In-Reply-To: <-Kj1YJ_nRa4nJtaxg3UR8uWhde6vIG1Jl-FFakGnHy4=.a41c6149-912b-4a66-8b1e-634bd27cdebb@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <-Kj1YJ_nRa4nJtaxg3UR8uWhde6vIG1Jl-FFakGnHy4=.a41c6149-912b-4a66-8b1e-634bd27cdebb@github.com>
Message-ID: <3QfQXArLyZzTcdg4r9bSGJKmnoG_YY8OFOJ0eLz2rYY=.e83d9ff2-8c7e-471c-b250-97a92e7db1e5@github.com>

On Thu, 9 Mar 2023 21:18:19 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
>> 
>> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
>> 
>> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
>> 
>> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
>> 
>> This change supports the following platforms: x86, aarch64, PPC, and RISCV
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Interpreter optimization and comments

I have a couple of very minor comments.  This change is great.  Thank you!

src/hotspot/cpu/x86/templateTable_x86.cpp line 2798:

> 2796:                                                bool is_invokevirtual,
> 2797:                                                bool is_invokevfinal, /*unused*/
> 2798:                                                bool is_invokedynamic /*unused*/) {

Can you remove the parameter since the s390 port is here?

src/hotspot/share/oops/resolvedIndyEntry.hpp line 112:

> 110:     set_flags(has_appendix);
> 111:     // Set the method last since it is read lock free.
> 112:     // Resolution is indicated by whether or not he method is set.

typo: he -> the

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12778

From matsaave at openjdk.org  Mon Mar 13 21:26:06 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Mon, 13 Mar 2023 21:26:06 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v2]
In-Reply-To: <33uTpOt8ALbYOl5axezzxriVn4V1h860H3YWEbJ-PDY=.429dbaaa-e75e-47fb-88aa-3bd451ee4662@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <-Kj1YJ_nRa4nJtaxg3UR8uWhde6vIG1Jl-FFakGnHy4=.a41c6149-912b-4a66-8b1e-634bd27cdebb@github.com>
 <33uTpOt8ALbYOl5axezzxriVn4V1h860H3YWEbJ-PDY=.429dbaaa-e75e-47fb-88aa-3bd451ee4662@github.com>
Message-ID: <IP6yRhGuarCyIHpdWhQGPZagykdMF0FagOhJ_4ZvbJw=.bbd93097-51a5-4ac4-a76d-ae351669ae69@github.com>

On Mon, 13 Mar 2023 21:04:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Interpreter optimization and comments
>
> src/hotspot/cpu/x86/interp_masm_x86.cpp line 2075:
> 
>> 2073:   movptr(cache, Address(rbp, frame::interpreter_frame_cache_offset * wordSize));
>> 2074:   movptr(cache, Address(cache, in_bytes(ConstantPoolCache::invokedynamic_entries_offset())));
>> 2075:   if (is_power_of_2(sizeof(ResolvedIndyEntry))) {
> 
> This was a good suggestion but I wonder if we should assert ResolvedIndyEntry is a power of 2 so we know if we change the size and make it go the slower path?  Or is 32 bit not a power of two and we need this?

Currently the structure is a power of two on 64 bits but this is not the case on 32 bit systems.

-------------

PR: https://git.openjdk.org/jdk/pull/12778

From dnsimon at openjdk.org  Mon Mar 13 21:57:43 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 13 Mar 2023 21:57:43 GMT
Subject: RFR: 8292818: replace 96-bit representation for field metadata
 with variable-sized streams [v4]
In-Reply-To: <hAGW4he3pjU6G9IuyygughaiDUL9vKNHzKcURWD4tSI=.b67e5661-9978-4d9d-850e-0a6399de5a64@github.com>
References: <vdiacOO3JUyy4sWGkDXNBMUT7cG3XYe79mOvYru9uMM=.9c556675-7ffd-4c09-a428-6d64dffef209@github.com>
 <hAGW4he3pjU6G9IuyygughaiDUL9vKNHzKcURWD4tSI=.b67e5661-9978-4d9d-850e-0a6399de5a64@github.com>
Message-ID: <5apLgAhjSwiK-sv6Xrl9yZctZTAe_GahWGyk8rUYgvk=.1af11917-7547-48ba-b958-01c6ef6f9f18@github.com>

On Mon, 13 Mar 2023 18:51:17 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Please review this change re-implementing the FieldInfo data structure.
>> 
>> The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency.
>> 
>> The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information).
>> 
>> More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818
>> 
>> Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM.
>> 
>> The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format.
>> 
>> Tested with mach5, tier 1 to 7.
>> 
>> Thank you.
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixes includes and style

src/hotspot/share/jvmci/jvmciEnv.cpp line 1439:

> 1437:     JNIAccessMark jni(this, THREAD);
> 1438:     jobject result = jni()->NewObject(JNIJVMCI::FieldInfo::clazz(),
> 1439:                                       JNIJVMCI::VMFlag::constructor(),

`JNIJVMCI::VMFlag::constructor()` is the wrong constructor.

src/hotspot/share/jvmci/jvmciEnv.hpp line 149:

> 147: };
> 148: 
> 149: extern JNIEXPORT jobjectArray c2v_getDeclaredFieldsInfo(JNIEnv* env, jobject, jobject, jlong);

What's the purpose of this declaration? I don't think you need it or the `friend` declaration below since `new_FieldInfo(FieldInfo* fieldinfo, JVMCI_TRAPS)` is public.

src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 416:

> 414:   declare_constant(FieldInfo::FieldFlags::_ff_injected)                   \
> 415:   declare_constant(FieldInfo::FieldFlags::_ff_stable)                     \
> 416:   declare_constant(FieldInfo::FieldFlags::_ff_generic)                    \

I don't think `_ff_generic` is used in the JVMCI Java code so this entry can be deleted. Please double check the other entries.

src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotConstantPool.java line 814:

> 812:             HotSpotResolvedObjectTypeImpl resolvedHolder;
> 813:             try {
> 814:                 resolvedHolder = compilerToVM().resolveFieldInPool(this, index, (HotSpotResolvedJavaMethodImpl) method, (byte) opcode, info);

Please update the javadoc for `CompilerToVM.resolveFieldInPool` to reflect the expanded definition of `info`.

src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotResolvedObjectTypeImpl.java line 88:

> 86: 
> 87:     /**
> 88:      * Lazily initialized cache for FieldInfo

nit: missing `.` at end of sentence

src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/meta/ResolvedJavaField.java line 48:

> 46:      * Returns VM internal flags associated with this field
> 47:      */
> 48:     int getInternalModifiers();

We've never exposed the internal modifiers before in public JVMCI API and we should refrain from doing so until there's a good reason to do so. Please remove this method.

test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaField.java line 97:

> 95: 
> 96:     @Test
> 97:     public void getInternalModifiersTest() {

No need for this test since the `getInternalModifiers` method should be removed.

-------------

PR: https://git.openjdk.org/jdk/pull/12855

From dnsimon at openjdk.org  Mon Mar 13 22:06:46 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 13 Mar 2023 22:06:46 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v2]
In-Reply-To: <-Kj1YJ_nRa4nJtaxg3UR8uWhde6vIG1Jl-FFakGnHy4=.a41c6149-912b-4a66-8b1e-634bd27cdebb@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <-Kj1YJ_nRa4nJtaxg3UR8uWhde6vIG1Jl-FFakGnHy4=.a41c6149-912b-4a66-8b1e-634bd27cdebb@github.com>
Message-ID: <ETVMNfZh1UZwMsVmYjhKg_locWefIxiVpEEtUSxYxB8=.7126de5e-103b-4f0c-8bbd-0023277fdf50@github.com>

On Thu, 9 Mar 2023 21:18:19 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
>> 
>> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
>> 
>> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
>> 
>> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
>> 
>> This change supports the following platforms: x86, aarch64, PPC, and RISCV
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Interpreter optimization and comments

As communicated to Matias earlier via email, the JVMCI changes in this PR look fine.

-------------

Marked as reviewed by dnsimon (Committer).

PR: https://git.openjdk.org/jdk/pull/12778

From coleenp at openjdk.org  Mon Mar 13 22:06:47 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 13 Mar 2023 22:06:47 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v2]
In-Reply-To: <-Kj1YJ_nRa4nJtaxg3UR8uWhde6vIG1Jl-FFakGnHy4=.a41c6149-912b-4a66-8b1e-634bd27cdebb@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <-Kj1YJ_nRa4nJtaxg3UR8uWhde6vIG1Jl-FFakGnHy4=.a41c6149-912b-4a66-8b1e-634bd27cdebb@github.com>
Message-ID: <IyDn0wnC5AfUg00clcQN3n7RyjXA31qJZchek_4nxqk=.10f43e89-2ea1-44c0-8b6c-ccbab0b95484@github.com>

On Thu, 9 Mar 2023 21:18:19 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
>> 
>> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
>> 
>> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
>> 
>> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
>> 
>> This change supports the following platforms: x86, aarch64, PPC, and RISCV
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Interpreter optimization and comments

@dougxc Can you have a look at the jvmci changes in this PR also?

-------------

PR: https://git.openjdk.org/jdk/pull/12778

From dcubed at openjdk.org  Mon Mar 13 23:01:17 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 13 Mar 2023 23:01:17 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v22]
In-Reply-To: <KxISxLED5fT6GGQrHtV2lODiK_t7vrGm7wqP7mbD0jg=.88da59f8-cb52-4a8c-8686-b06799c72822@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <KxISxLED5fT6GGQrHtV2lODiK_t7vrGm7wqP7mbD0jg=.88da59f8-cb52-4a8c-8686-b06799c72822@github.com>
Message-ID: <yVIoMdCP0rYc7R6x6H6jICNfe79Czy2mVyT5oFmHMIM=.d4535f51-d0e6-4c09-b69c-3dd765967fc3@github.com>

On Mon, 13 Mar 2023 18:43:41 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Re-design LockStack for faster lock-stack depth-check

src/hotspot/share/runtime/lockStack.cpp line 35:

> 33: int LockStack::end_offset() {
> 34:   return in_bytes(JavaThread::lock_stack_base_offset()) + CAPACITY * oopSize;
> 35: }

It's a little odd to have function `end_offset()` be defined
before the `LockStack::LockStack()` constructor.

src/hotspot/share/runtime/lockStack.hpp line 51:

> 49: public:
> 50:   static ByteSize offset_offset()    { return byte_offset_of(LockStack, _offset); }
> 51:   static ByteSize base_offset()    { return byte_offset_of(LockStack, _base); }

nit - you might want to align these '{' indents.

src/hotspot/share/runtime/lockStack.inline.hpp line 84:

> 82:     if (_base[i] == o) {
> 83:       validate("post-contains");
> 84:       validate("post-contains");

Two `validate()` calls in a row. Probably a cut-n-paste error.

src/hotspot/share/runtime/synchronizer.cpp line 514:

> 512:         }
> 513:       }
> 514:     } else {

Consider adding a comment after L513 and before L514:
`      // No room on the lock_stack so fall-through to inflate-enter.`

src/hotspot/share/runtime/vmStructs.cpp line 704:

> 702:   nonstatic_field(JavaThread,                  _lock_stack,                                   LockStack)                             \
> 703:   nonstatic_field(LockStack,                   _offset,                                       int)                                   \
> 704:   nonstatic_field(LockStack,                   _base[0],                                      oop)                                 \

It surprises me that you can specify `_base[0]` here.

nit: the indent before the backslash is off.

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From dcubed at openjdk.org  Mon Mar 13 23:01:08 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 13 Mar 2023 23:01:08 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v23]
In-Reply-To: <P-iheLBjdOGikiJhK78k2BYcz-xhvu2n2i7WM4W4AXc=.453a4d91-bca3-429b-bbcc-d2a58fccb853@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <P-iheLBjdOGikiJhK78k2BYcz-xhvu2n2i7WM4W4AXc=.453a4d91-bca3-429b-bbcc-d2a58fccb853@github.com>
Message-ID: <oCxYEMxhugYY9gID3lon3-oq07mt85sqcMb2fyBWSf8=.61663521-4cef-47fa-b65f-a26e70a8fa1b@github.com>

On Mon, 13 Mar 2023 20:02:45 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   X86 parts

Reviewed v21 changes except for riscv.

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From dcubed at openjdk.org  Mon Mar 13 23:13:56 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 13 Mar 2023 23:13:56 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v23]
In-Reply-To: <P-iheLBjdOGikiJhK78k2BYcz-xhvu2n2i7WM4W4AXc=.453a4d91-bca3-429b-bbcc-d2a58fccb853@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <P-iheLBjdOGikiJhK78k2BYcz-xhvu2n2i7WM4W4AXc=.453a4d91-bca3-429b-bbcc-d2a58fccb853@github.com>
Message-ID: <j5gvXTX4G9WasPhkPPrqcbQyUQsjrK8embNf7R-femY=.882e34ab-e496-4c32-85d3-a89ae32701fb@github.com>

On Mon, 13 Mar 2023 20:02:45 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   X86 parts

Also reviewed v22 changes; no comments on those.

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From fparain at openjdk.org  Mon Mar 13 23:28:41 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 13 Mar 2023 23:28:41 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v2]
In-Reply-To: <-Kj1YJ_nRa4nJtaxg3UR8uWhde6vIG1Jl-FFakGnHy4=.a41c6149-912b-4a66-8b1e-634bd27cdebb@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <-Kj1YJ_nRa4nJtaxg3UR8uWhde6vIG1Jl-FFakGnHy4=.a41c6149-912b-4a66-8b1e-634bd27cdebb@github.com>
Message-ID: <N150ccbtV0uwhOSKYUHXGioJx3YJ7GWzHhgoj8gQvzc=.5401872a-edd8-4e2c-8621-3c9f4dd9ca46@github.com>

On Thu, 9 Mar 2023 21:18:19 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
>> 
>> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
>> 
>> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
>> 
>> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
>> 
>> This change supports the following platforms: x86, aarch64, PPC, and RISCV
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Interpreter optimization and comments

Marked as reviewed by fparain (Committer).

-------------

PR: https://git.openjdk.org/jdk/pull/12778

From cjplummer at openjdk.org  Tue Mar 14 01:28:57 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 14 Mar 2023 01:28:57 GMT
Subject: RFR: 8292818: replace 96-bit representation for field metadata
 with variable-sized streams [v4]
In-Reply-To: <hAGW4he3pjU6G9IuyygughaiDUL9vKNHzKcURWD4tSI=.b67e5661-9978-4d9d-850e-0a6399de5a64@github.com>
References: <vdiacOO3JUyy4sWGkDXNBMUT7cG3XYe79mOvYru9uMM=.9c556675-7ffd-4c09-a428-6d64dffef209@github.com>
 <hAGW4he3pjU6G9IuyygughaiDUL9vKNHzKcURWD4tSI=.b67e5661-9978-4d9d-850e-0a6399de5a64@github.com>
Message-ID: <ixB_BHQBP1DbXZf71LHAYfwAI0hoCQ9TdnlsOdD3sFw=.30eb2928-111d-44c9-bf53-61288e450fe4@github.com>

On Mon, 13 Mar 2023 18:51:17 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Please review this change re-implementing the FieldInfo data structure.
>> 
>> The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency.
>> 
>> The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information).
>> 
>> More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818
>> 
>> Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM.
>> 
>> The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format.
>> 
>> Tested with mach5, tier 1 to 7.
>> 
>> Thank you.
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixes includes and style

Changes requested by cjplummer (Reviewer).

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Field.java line 75:

> 73:     int initialValueIndex;
> 74:     int genericSignatureIndex;
> 75:     int contendedGroup;

It seems that these should all be shorts. All the getter methods are casting them to short.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Field.java line 99:

> 97:     if (fieldIsInitialized(fieldInfoValues.fieldFlags)) fieldInfoValues.initialValueIndex = crs.readInt(); // read initial value index
> 98:     if (fieldIsGeneric(fieldInfoValues.fieldFlags))     fieldInfoValues.genericSignatureIndex = crs.readInt(); // read generic signature index
> 99:     if (fieldIsContended(fieldInfoValues.fieldFlags))   fieldInfoValues.contendedGroup = crs.readInt(); // read contended group

Column with is too wide. These lines would be easier to read if you made each one multiple lines with curly braces.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Field.java line 107:

> 105:     int javafieldsCount = crs.readInt(); // read num_java_fields
> 106:     int VMFieldsCount = crs.readInt(); // read num_injected_fields;
> 107:     int numFields = javafieldsCount + VMFieldsCount;

VMFieldsCount -> vmFieldsCount, or maybe just use num_java_fields and num_injected_fields

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java line 285:

> 283:   public short getFieldNameIndex(int index) {
> 284:     if (index >= getJavaFieldsCount()) throw new IndexOutOfBoundsException("not a Java field;");
> 285:     return (short)getField(index).getNameIndex();

Cast to short not needed

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java line 303:

> 301:   public short getFieldSignatureIndex(int index) {
> 302:     if (index >= getJavaFieldsCount()) throw new IndexOutOfBoundsException("not a Java field;");
> 303:     return (short)getField(index).getGenericSignatureIndex();

Cast to short is not needed

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java line 321:

> 319:   public short getFieldInitialValueIndex(int index) {
> 320:     if (index >= getJavaFieldsCount()) throw new IndexOutOfBoundsException("not a Java field;");
> 321:     return (short)getField(index).getInitialValueIndex();

cast to short is not needed

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java line 325:

> 323: 
> 324:   public int getFieldOffset(int index) {
> 325:     return (int)getField(index).getOffset();

Cast to int is not needed

-------------

PR: https://git.openjdk.org/jdk/pull/12855

From fyang at openjdk.org  Tue Mar 14 01:44:03 2023
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 14 Mar 2023 01:44:03 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v22]
In-Reply-To: <KxISxLED5fT6GGQrHtV2lODiK_t7vrGm7wqP7mbD0jg=.88da59f8-cb52-4a8c-8686-b06799c72822@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <KxISxLED5fT6GGQrHtV2lODiK_t7vrGm7wqP7mbD0jg=.88da59f8-cb52-4a8c-8686-b06799c72822@github.com>
Message-ID: <ctMJefR0FtF6JUffQMHXsz96WUsgrQQ4EC1vG4lXPKg=.7012ee72-2046-4ad4-98ba-3877b0c11cf2@github.com>

On Mon, 13 Mar 2023 18:43:41 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Re-design LockStack for faster lock-stack depth-check

src/hotspot/cpu/aarch64/c2_CodeStubs_aarch64.cpp line 87:

> 85:   __ sub(t, t, oopSize);
> 86:   __ str(t, Address(rthread, JavaThread::lock_stack_offset_offset()));
> 87: 

It looks to me that the '_offset' of LockStack should be updated with ldrw, subw and strw instructions here.

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From cjplummer at openjdk.org  Tue Mar 14 02:03:32 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 14 Mar 2023 02:03:32 GMT
Subject: RFR: 8292818: replace 96-bit representation for field metadata
 with variable-sized streams [v4]
In-Reply-To: <hAGW4he3pjU6G9IuyygughaiDUL9vKNHzKcURWD4tSI=.b67e5661-9978-4d9d-850e-0a6399de5a64@github.com>
References: <vdiacOO3JUyy4sWGkDXNBMUT7cG3XYe79mOvYru9uMM=.9c556675-7ffd-4c09-a428-6d64dffef209@github.com>
 <hAGW4he3pjU6G9IuyygughaiDUL9vKNHzKcURWD4tSI=.b67e5661-9978-4d9d-850e-0a6399de5a64@github.com>
Message-ID: <WayroZeX3wOovrrFaIOghOdQW_fD1u9uFyEPUEYbKPg=.0dd95c0e-6081-4362-afa6-df0dd2a395c9@github.com>

On Mon, 13 Mar 2023 18:51:17 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Please review this change re-implementing the FieldInfo data structure.
>> 
>> The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency.
>> 
>> The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information).
>> 
>> More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818
>> 
>> Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM.
>> 
>> The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format.
>> 
>> Tested with mach5, tier 1 to 7.
>> 
>> Thank you.
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixes includes and style

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java line 108:

> 106:     CLASS_STATE_INITIALIZATION_ERROR = db.lookupIntConstant("InstanceKlass::initialization_error").intValue();
> 107:     // We need a new fieldsCache each time we attach.
> 108:     fieldsCache = new HashMap<Address, Field[]>();

This should probably be a WeakHashMap. I tried it and it seems to work (or at least didn't cause any problems). However, when doing a heap dump I didn't notice the table being any smaller on exit when it was made weak, even though there were numerous GC's while dumping the heap.

The <key> is the Address of the hotspot InstanceKlass instance, and this Address is referenced by the SA InstanceKlass mirror. So theoretically when the reference to the mirror goes way, then the cache entry can be cleared.

-------------

PR: https://git.openjdk.org/jdk/pull/12855

From jvernee at openjdk.org  Tue Mar 14 03:05:41 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 14 Mar 2023 03:05:41 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v3]
In-Reply-To: <8I_sDu55v8ThrFyF4mMWbKOOKeGkfYvqo66JLNnULUY=.830fe48d-b65f-437c-82fa-9e7dac76c7ab@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <8b3vVrV22RuhdRoRYacXV0ZeghFGgKkC8S_z-iMrzAQ=.dd84b743-8b51-4281-8f5f-f9eff6207bc7@github.com>
 <HT8kQfjS98dYHeAMcNL5latokRiw3YK8npxl5yCD4hw=.28b19bac-cbfa-4461-a1db-c899c55b7485@github.com>
 <wBVqRDFM23KM8fjjPtUFNdW56FYsSpvOAVvHmpdjbzo=.7c429606-ac19-4f36-8e25-459534983924@github.com>
 <QMh_faUf_LLUf68WrZiFxmPHiFcHDBfKDg3g-oekBeg=.096acd06-65c4-4357-ad4a-4089b5478fff@github.com>
 <hJkc1ozy4f7BIvXZ_xQ3HRttVsBs0ceUIMmq4cDWrzQ=.bc3223f5-cb33-46c7-9708-ab40ba5943b0@github.com>
 <mknfp22D3MdgwuitW4rYeIdz2S43a8wQdSmLerF2yO0=.94e5cf61-b2b8-41f3-b44e-0bde47b33bfc@github.com>
 <AOvm3Axl3yZLOa-A0ikaRQY7el-CsXTm0TJyNx-gkQk=.9d4cf018-f0a3-49d3-ad0d-d3018725fccf@github.com>
 <z1ogtf4v8v1oXW77do4v590wnNnczFYQsERCTXW3qeI=.a0511aba-5e5e-4074-ba43-373f3d0708f8@github.com>
 <1OXigMWnfCHCkxCI3D29NpgIpgG36Ltlnry1eytOPow=.5f423637-0a12-454e-a31c-57b2fc11123f@github.com>
 <8I_sDu55v8ThrFyF4mMWbKOOKeGkfYvqo66
 JLNnULUY=.830fe48d-b65f-437c-82fa-9e7dac76c7ab@github.com>
Message-ID: <w8sEDP5foTEs39uCIuVZjBnIkc3FxwHyruuSZ4Lpeo0=.11bb953d-2746-4d0d-8776-e75827d5de1b@github.com>

On Mon, 13 Mar 2023 20:57:22 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Note that argument and return value passing works. I'm getting all values back. So, the native side seems to be ok. Only (one or two) values in `returnBox` are broken.

You mean you tested by returning each element of the array one by one?

If so, that rules out an issue with the downcall, or the struct not being in the right format (in the register), I think.

I suggest checking the bindings generated for the upcall, and seeing if they match what the native code does. This could be done in `jshell` for instance:


$ .\build\windows-fastdebug\images\jdk\bin\jshell.exe --enable-preview '--add-exports=java.base/jdk.internal.foreign.abi.x64.windows=ALL-UNNAMED' '--add-exports=java.base/jdk.internal.foreign.abi=ALL-UNNAMED'

jshell> import java.lang.foreign.*
jshell> import java.lang.invoke.*
jshell> import static java.lang.foreign.ValueLayout.*
jshell> import jdk.internal.foreign.abi.x64.windows.CallArranger
jshell> MemoryLayout.structLayout(MemoryLayout.sequenceLayout(8, JAVA_BYTE))
$5 ==> [[8:b8]]
jshell> FunctionDescriptor.of($5, $5, JAVA_BYTE, JAVA_BYTE, JAVA_BYTE, JAVA_BYTE, JAVA_BYTE, JAVA_BYTE, JAVA_BYTE, JAVA_BYTE)
$6 ==> ([[8:b8]]b8b8b8b8b8b8b8b8)[[8:b8]]
jshell> CallArranger.getBindings($6.toMethodType(), $6, true)
$7 ==> Bindings[callingSequence=jdk.internal.foreign.abi.CallingSequence at 396e2f39, isInMemoryReturn=false]
jshell> System.out.println($7.callingSequence().asString())
CallingSequence: {
  callerMethodType: (long,int,int,int,int,int,int,int,int)long
  calleeMethodType: (MemorySegment,byte,byte,byte,byte,byte,byte,byte,byte)MemorySegment
  FunctionDescriptor: ([[8:b8]]b8b8b8b8b8b8b8b8)[[8:b8]]  
  Argument Bindings:
    0: [Allocate[size=8, alignment=1], Dup[], VMLoad[storage=VMStorage[type=0, segmentMaskOrSize=15, indexOrOffset=1, debugName=rcx], type=long], BufferStore[offset=0, type=long, byteWidth=8]]
    1: [VMLoad[storage=VMStorage[type=0, segmentMaskOrSize=15, indexOrOffset=2, debugName=rdx], type=int], INT_TO_BYTE]
    2: [VMLoad[storage=VMStorage[type=0, segmentMaskOrSize=15, indexOrOffset=8, debugName=r8], type=int], INT_TO_BYTE]
    3: [VMLoad[storage=VMStorage[type=0, segmentMaskOrSize=15, indexOrOffset=9, debugName=r9], type=int], INT_TO_BYTE]
    4: [VMLoad[storage=VMStorage[type=3, segmentMaskOrSize=8, indexOrOffset=0, debugName=Stack at 0], type=int], INT_TO_BYTE]
    5: [VMLoad[storage=VMStorage[type=3, segmentMaskOrSize=8, indexOrOffset=8, debugName=Stack at 8], type=int], INT_TO_BYTE]
    6: [VMLoad[storage=VMStorage[type=3, segmentMaskOrSize=8, indexOrOffset=16, debugName=Stack at 16], type=int], INT_TO_BYTE]
    7: [VMLoad[storage=VMStorage[type=3, segmentMaskOrSize=8, indexOrOffset=24, debugName=Stack at 24], type=int], INT_TO_BYTE]
    8: [VMLoad[storage=VMStorage[type=3, segmentMaskOrSize=8, indexOrOffset=32, debugName=Stack at 32], type=int], INT_TO_BYTE]
  Return bindings:
    [BufferLoad[offset=0, type=long, byteWidth=8], VMStore[storage=VMStorage[type=0, segmentMaskOrSize=15, indexOrOffset=0, debugName=rax], type=long]]
}

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From dholmes at openjdk.org  Tue Mar 14 04:50:27 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 14 Mar 2023 04:50:27 GMT
Subject: RFR: 8301244: Tidy up compiler specific warnings files [v10]
In-Reply-To: <U9c8wDcpjHF9tjYY6aUQnmZ-ATomE0BGbjFz7q0j028=.9bb506da-7e5c-4f26-8364-b8c9dda64717@github.com>
References: <CU3GjASmLJw11Olusd1w5qnl-zb_d1hjVewzVEn3BS0=.277f1a89-0731-41ee-bad8-e15a57a826a4@github.com>
 <U9c8wDcpjHF9tjYY6aUQnmZ-ATomE0BGbjFz7q0j028=.9bb506da-7e5c-4f26-8364-b8c9dda64717@github.com>
Message-ID: <FB7NWcYJHnj6XhoWscksLDk5-6vl2MmaFivoYvdjANc=.35932115-3f12-48cb-be18-68fdd96f00d0@github.com>

On Sat, 11 Mar 2023 17:17:06 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Cleans up some code in compilerWarnings_*.hpp files to be slightly neater
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert to initial name

Seems okay.

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12255

From dholmes at openjdk.org  Tue Mar 14 04:56:27 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 14 Mar 2023 04:56:27 GMT
Subject: RFR: 8302191: Performance degradation for float/double modulo on
 Linux [v12]
In-Reply-To: <RId-BddGF5Px37EdS6jN7fen2y-UTKlPXrF88KJizq0=.e2ffd401-3d9c-4af6-baa9-7e42da817372@github.com>
References: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
 <RId-BddGF5Px37EdS6jN7fen2y-UTKlPXrF88KJizq0=.e2ffd401-3d9c-4af6-baa9-7e42da817372@github.com>
Message-ID: <J75GI1Qk9sbUa51Yo3xhjA4MhkK9p-cqpwYrrrCNmuk=.5a67738d-ae8e-435d-b479-3f61ae9b6f31@github.com>

On Sun, 12 Mar 2023 13:21:18 GMT, Jan Kratochvil <duke at openjdk.org> wrote:

>> I have OCA already processed/approved. I am not Author but my Author request is being processed these days (sent to Rob McKenna).
>> I did regression test x86_64 OpenJDK-8. I will leave other regression testing on GHA.
>> The patch (and former GCC performance regression) affects only x86_64+i686.
>
> Jan Kratochvil 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 13 additional commits since the last revision:
> 
>  - Fix missing SharedRuntime::frem and SharedRuntime::drem on aarch64.
>     - bugreported by sviswa7.
>  - Merge branch 'master' into modulo
>  - Fix #endif comment - found by dholmes-ora.
>  - Merge branch 'master' into modulo
>  - Fix win32 broken build.
>  - Merge remote-tracking branch 'origin/master' into modulo
>  - Always include the _WIN64 workaround - a review by dholmes-ora.
>  - Remove comments to be moved to JBS (Bug System) - a review by jddarcy.
>  - Uppercase L - a review by turbanoff.
>  - Fix copyright author.
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/9f5d42ca...f03d4cdf

These changes seem good to go now, but I'd like to run them through our CI testing first. Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/12508

From dholmes at openjdk.org  Tue Mar 14 05:12:21 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 14 Mar 2023 05:12:21 GMT
Subject: RFR: 8303150: DCmd framework unnecessarily creates a DCmd instance
 on registration
In-Reply-To: <Un86BcZr_2byTMFavkCIj84REkYMBs-A9EqDWRVj0p8=.5caf7a1a-c98b-485e-b6b9-f38c78bc99f6@github.com>
References: <TNyX996lKlRcmTijRTN0VUZBcNBt2DXeMPhDBjaa0NQ=.160293b7-4570-43a5-af9e-d9cb02022820@github.com>
 <Un86BcZr_2byTMFavkCIj84REkYMBs-A9EqDWRVj0p8=.5caf7a1a-c98b-485e-b6b9-f38c78bc99f6@github.com>
Message-ID: <CVbmeWfM_F84YM3ERb1fOAqV0VA7QFqCml3-4qU0rhg=.1873cea0-5a2b-48f0-a2f4-063d60ecb641@github.com>

On Mon, 13 Mar 2023 17:42:34 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> When DCmd factories are registered, the factory is passed the number of arguments taken by the DCmd - using a template method `get_num_arguments`. For DCmds that don't extend DCmdWithParser there has to be a static `num_arguments()` method in that class. For DCmds that do extend DCmdWithParser the logic instantiates an instance of the DCmd, extracts its parser and calls its `num_arguments` method which dynamically counts the number of defined arguments.
>> 
>> Creating an instance of each DCmd and dynamically counting arguments is inefficient and unnecessary, the number of arguments is statically known and easily expressed (in fact many of the JFR DCmds already statically define this). So we add the static `num_arguments()` method to each class that needs it and return the statically counted number of arguments. To ensure the static number and actual number don't get out-of-sync, we keep the original dynamic logic for use in debug builds to assert that the static and dynamic counts are the same. The assert will trigger during a debug build if something does get out of sync, for example if a new DCmd (extending DCmdWithParser) were added but didn't define the static `num_arguments()` method.
>> 
>> A number of DCmd classes were unnecessarily defining their own dynamic version of `num_arguments` and these are now removed.
>> 
>> In the template method I use `ENABLE_IF(std::is_convertible<T, DCmd>::value)` to check we only call this on DCmd classes. This may be unnecessary but it seemed consistent with the other template methods. Note that `std::is_base_of` only works for immediate super types.
>> 
>> Testing: tiers 1-4
>> 
>> Performance: in theory we should see some improvement in startup; in practice it is barely noticeable.
>> 
>> Thanks.
>
> The concern during the initial implementation was that the value returned by num_arguments() and the real number of arguments could become out of sync, but your solution to check that they are consistent only on debug builds addresses this concern.
> Thank you for fixing this!

Thanks for the review @fparain !

-------------

PR: https://git.openjdk.org/jdk/pull/12994

From dholmes at openjdk.org  Tue Mar 14 05:29:23 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 14 Mar 2023 05:29:23 GMT
Subject: RFR: 8302191: Performance degradation for float/double modulo on
 Linux [v5]
In-Reply-To: <z6yn-ke23WZj0ik9w7g9u530jWDXdo5hUQ7SK819ao4=.d4908bff-c1eb-4c14-bd3b-9373db90ce63@github.com>
References: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
 <o8gBuzq9Pfc4aYnmo3cPGXwVo4cbouH0delXsoz4kEI=.7a6c9412-f7c4-4c07-91ea-8cb5c0b9da6a@github.com>
 <OoYoMXL5HyAVVvSpbj-lqGeOb9xNPKSVdQHDlYVr9Wo=.36a530a9-1921-4e92-8bb7-be8a48f02448@github.com>
 <z6yn-ke23WZj0ik9w7g9u530jWDXdo5hUQ7SK819ao4=.d4908bff-c1eb-4c14-bd3b-9373db90ce63@github.com>
Message-ID: <_TLQFyghr0kX0qSFHw11hfIw9FQu4lsajzyHvfWVRHs=.60b65b6a-7b46-4334-a9c0-f69e3065f854@github.com>

On Thu, 2 Mar 2023 13:13:56 GMT, Jan Kratochvil <duke at openjdk.org> wrote:

>> You can't move the _WIN64 workaround to the sharedRuntime_x86.cpp file as that code is also used by Windows-Aarch64. Whether it needs the workaround or not is another matter, but unless proven otherwise we have to assume it does.
>
>> You can't move the _WIN64 workaround to the sharedRuntime_x86.cpp file as that code is also used by Windows-Aarch64. Whether it needs the workaround or not is another matter, but unless proven otherwise we have to assume it does.
> 
> I hope/believe the bug affects only amd64 and not aarch64. I want to verify it but I have some difficulty getting remote access to such Windows boxes, I am working on the verification.

@jankratochvil can you update your master branch to latest and re-merge please. Unfortunately the current set of changes has a bug ([JDK-8302189](https://bugs.openjdk.org/browse/JDK-8302189)) that prevents building on macOS.

-------------

PR: https://git.openjdk.org/jdk/pull/12508

From dholmes at openjdk.org  Tue Mar 14 05:53:28 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 14 Mar 2023 05:53:28 GMT
Subject: RFR: 8257967: JFR: Events for loaded agents [v10]
In-Reply-To: <5bzaYlM6HXfUNJITjTSIaGgcJ_51OQf6XWr07w__wUw=.d0a9ac8b-a9a1-4122-9d2f-880de717d071@github.com>
References: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
 <ifc_GVpqqnc0TVYHD1E1TnlG0jyGYcqtyNljfY3AuDY=.9dc9baf4-0331-4e6a-8745-bbdd01c62943@github.com>
 <MEaC0tZz0wRYqjruWeE1-1ig25xS8f0w_wkO8k6ZJzk=.33473403-7f73-421c-84c0-24f2fdf2a3e3@github.com>
 <5bzaYlM6HXfUNJITjTSIaGgcJ_51OQf6XWr07w__wUw=.d0a9ac8b-a9a1-4122-9d2f-880de717d071@github.com>
Message-ID: <9WvL-zpi-ekddOKD2iqHtRAmqFJwwtL1gwKxnsLtA7A=.60564e75-e261-4ed0-a89f-8179c7ffdaa5@github.com>

On Thu, 9 Mar 2023 09:29:41 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> src/hotspot/share/runtime/threads.cpp line 338:
>> 
>>> 336:   if (EagerXrunInit && Arguments::init_libraries_at_startup()) {
>>> 337:     create_vm_init_libraries();
>>> 338:   }
>> 
>> Not obvious where this went. Changes to the initialization order can be very problematic.
>
> Thanks, David. Two calls to launch XRun agents are invoked during startup, and they depend on the EagerXrunInit option. The !EagerXrunInit case is already located in create_vm(), but the EagerXrunInit was located as the first entry in initialize_java_lang_classes(), which I thought was tucked away a bit unnecessarily.
> 
> I hoisted the EagerXrunInit case from initialize_java_lang_classes() up to create_vm(). It's now the call just before initialize_java_lang_classes().
> 
> This made it clearer, i.e. to have both calls located directly in create_vm().

Thanks for clarifying. That makes sense.

-------------

PR: https://git.openjdk.org/jdk/pull/12923

From dholmes at openjdk.org  Tue Mar 14 06:03:37 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 14 Mar 2023 06:03:37 GMT
Subject: RFR: 8257967: JFR: Events for loaded agents [v10]
In-Reply-To: <ZsaBMVK-eeLfmxgg15qPJHm6C-ed5PyIE4lGr-Gnr2s=.2f4044c4-e7ed-48f3-8877-feeb2753be18@github.com>
References: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
 <ZsaBMVK-eeLfmxgg15qPJHm6C-ed5PyIE4lGr-Gnr2s=.2f4044c4-e7ed-48f3-8877-feeb2753be18@github.com>
Message-ID: <sKa6RRVpBw1kQ0DoQHMclspRNTBJZlKicmXBOUSWDBk=.0b538fa3-7db0-4863-a2aa-b3cd0f692959@github.com>

On Fri, 10 Mar 2023 10:43:23 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> We are adding support to let JFR report on Agents.
>> 
>> #### Design
>> 
>> An Agent is a library that uses any instrumentation or profiling APIs. Most agents are started and initialized on the command line, but agents can also be loaded dynamically during runtime. Because command line agents initialize during the VM startup sequence, they add to the overall startup time latency in getting the VM ready. The events will report on the time the agent took to initialize.
>> 
>> A JavaAgent is an agent written in the Java programming language, using the APIs in the package [java.lang.instrument](https://docs.oracle.com/en/java/javase/19/docs/api/java.instrument/java/lang/instrument/package-summary.html)
>> 
>> A JavaAgent is sometimes called a JPLIS agent, where the acronym JPLIS stands for Java Programming Language Instrumentation Services.
>> 
>> To report on JavaAgents, JFR will add the new event type jdk.JavaAgent and events will look similar to these two examples:
>> 
>> // Command line
>> jdk.JavaAgent {
>>   startTime = 12:31:19.789 (2023-03-08)
>>   name = "JavaAgent.jar"
>>   options = "foo=bar"
>>   dynamic = false
>>   initialization = 12:31:15.574 (2023-03-08)
>>   initializationTime = 172 ms
>> }
>> 
>> // Dynamic load
>> jdk.JavaAgent {
>>   startTime = 12:31:31.158 (2023-03-08)
>>   name = "JavaAgent.jar"
>>   options = "bar=baz"
>>   dynamic = true
>>   initialization = 12:31:31.037 (2023-03-08)
>>   initializationTime = 64,1 ms
>> }
>> 
>> The jdk.JavaAgent event type is a JFR periodic event that iterates over running Java agents.
>> 
>> For a JavaAgent event, the agent's name will be the specific .jar file containing the instrumentation code. The options will be the specific options passed to the .jar file as part of launching the agent, for example, on the command line: -javaagent: JavaAgent.jar=foo=bar.
>> 
>> The "dynamic" field denotes if the agent was loaded via the command line (dynamic = false) or dynamically (dynamic = true)
>> 
>> "initialization" is the timestamp the JVM invoked the initialization method, and "initializationTime" is the duration of executing the initialization method.
>> 
>> "startTime" represents the time the JFR framework issued the periodic event; hence "initialization" will be earlier than "startTime".
>> 
>> An agent can also be written in a native programming language using the [JVM Tools Interface (JVMTI)](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html). This kind of agent, sometimes called a native agent, is a platform-specific binary, sometimes referred to as a library, but here it means a .so or .dll file.
>> 
>> To report on native agents, JFR will add the new event type jdk.NativeAgent and events will look similar to this example:
>> 
>> jdk.NativeAgent {
>>   startTime = 12:31:40.398 (2023-03-08)
>>   name = "jdwp"
>>   options = "transport=dt_socket,server=y,address=any,onjcmd=y"
>>   dynamic = false
>>   initialization = 12:31:36.142 (2023-03-08)
>>   initializationTime = 0,00184 ms
>>   path = "c:\ade\github\openjdk\jdk\build\windows-x86_64-server-slowdebug\jdk\bin\jdwp.dll"
>> }
>> 
>> The layout of the event type is very similar to the jdk.JavaAgent event, but here the path to the native library is reported.
>> 
>> The initialization of a native agent is performed by invoking an agent-specified callback routine. The "initialization" is when the JVM sent or would have sent the JVMTI VMInit event to a specified callback. "initializationTime" is the duration to execute that specific callback. If no callback is specified for the JVMTI VMInit event, the "initializationTime" will be 0.
>> 
>> #### Implementation
>> 
>> There has not existed a reification of a JavaAgent directly in the JVM, as these are built on top of the JDK native library, "instrument", using a many-to-one mapping. At the level of the JVM, the only representation of agents after startup is through JvmtiEnv's, which agents request from the JVM during startup and initialization ? as such, mapping which JvmtiEnv belongs to what JavaAgent was not possible before.
>> 
>> Using implementation details of how the JDK native library "instrument" interacts with the JVM, we can build this mapping to track what JvmtiEnv's "belong" to what JavaAgent. This mapping now lets us report the Java-relevant context (name, options) and measure the time it takes for the JavaAgent to initialize.
>> 
>> When implementing this capability, it was necessary to refactor the code used to represent agents, AgentLibrary. The previous implementation was located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp.
>> 
>> The refactoring isolates the relevant logic into two new modules, prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their older places will help reduce the sizes of oversized arguments.cpp and threads.cpp.
>> 
>> The previous two lists that maintained "agents" (JVMTI) and "libraries" (Xrun) were not thread-safe for concurrent iterations. A single list that allows for concurrent iterations is therefore introduced.
>> 
>> Testing: jdk_jfr, tier 1 - 6
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more cleanup

I've had a good look through now and have a better sense of the refactoring. Seems good.

I'll wait for any tweaks before hitting the approve button though.

Thanks

-------------

PR: https://git.openjdk.org/jdk/pull/12923

From never at openjdk.org  Tue Mar 14 07:12:18 2023
From: never at openjdk.org (Tom Rodriguez)
Date: Tue, 14 Mar 2023 07:12:18 GMT
Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v5]
In-Reply-To: <gYzscs7Y8uz2l_5FIsqAuKebVsMnJpSwbIH6C_uzdv4=.f33d8432-c1fc-45a3-80f7-1159cdb87480@github.com>
References: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>
 <gYzscs7Y8uz2l_5FIsqAuKebVsMnJpSwbIH6C_uzdv4=.f33d8432-c1fc-45a3-80f7-1159cdb87480@github.com>
Message-ID: <sjJAoXEkQVbslDwhdwvIRIKGstWxA-YgFlhE6wLCys8=.001438da-8f86-40d3-9011-86c4933b2184@github.com>

On Wed, 8 Mar 2023 22:59:23 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for accessing annotations. The main differences from `java.lang.reflect.AnnotatedElement` are:
>> * Each `Annotated` method explicitly specifies the annotation type(s) for which it wants annotation data. That is, there is no direct equivalent of `AnnotatedElement.getAnnotations()`.
>> * Annotation data is returned in a map-like object (of type `jdk.vm.ci.meta.AnnotationData`) instead of in an `Annotation` object. This works better for libgraal as it avoids the need for annotation types to be loaded and included in libgraal.
>>  
>> To demonstrate the new API, here's an example in terms `java.lang.reflect.AnnotatedElement` (which `ResolvedJavaType` implements):
>> 
>>     ResolvedJavaMethod method = ...;
>>     ExplodeLoop a = method.getAnnotation(ExplodeLoop.class);
>>     return switch (a.kind()) {
>>         case FULL_UNROLL -> LoopExplosionKind.FULL_UNROLL;
>>         case FULL_UNROLL_UNTIL_RETURN -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>>         ...
>>     }
>> 
>> 
>> The same code using the new API:
>> 
>> 
>>     ResolvedJavaMethod method = ...;
>>     ResolvedJavaType explodeLoopType = ...;
>>     AnnotationData a = method.getAnnotationDataFor(explodeLoopType);
>>     return switch (a.getEnum("kind").getName()) {
>>         case "FULL_UNROLL" -> LoopExplosionKind.FULL_UNROLL;
>>         case "FULL_UNROLL_UNTIL_RETURN" -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>>         ...
>>     }
>> 
>> 
>> The implementation relies on new methods in `jdk.internal.vm.VMSupport` for parsing annotations and serializing/deserializing to/from a byte array. This allows the annotation data to be passed from the HotSpot heap to the libgraal heap.
>
> Doug Simon 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 remote-tracking branch 'openjdk-jdk/master' into JDK-8303431
>  - switched to use of lists and maps instead of arrays
>  - fixed whitespace
>  - added support for inherited annotations
>  - Merge branch 'master' into JDK-8303431
>  - made AnnotationDataDecoder package-private
>  - add annotation API to JVMCI

The JVMCI changes look ok to me.

src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 2699:

> 2697:   typeArrayOop ba = typeArrayOop(res);
> 2698:   int ba_len = ba->length();
> 2699:   if (ba_len <= 256) {

Is this really necessary?  Resource allocation is very cheap.

src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/meta/Annotated.java line 40:

> 38:      * annotations of this element.
> 39:      *
> 40:      * If this element is a class, then {@link Inherited} annotations are included in set of

in the set

-------------

Marked as reviewed by never (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12810

From jwaters at openjdk.org  Tue Mar 14 07:29:11 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 14 Mar 2023 07:29:11 GMT
Subject: RFR: 8301244: Tidy up compiler specific warnings files [v11]
In-Reply-To: <CU3GjASmLJw11Olusd1w5qnl-zb_d1hjVewzVEn3BS0=.277f1a89-0731-41ee-bad8-e15a57a826a4@github.com>
References: <CU3GjASmLJw11Olusd1w5qnl-zb_d1hjVewzVEn3BS0=.277f1a89-0731-41ee-bad8-e15a57a826a4@github.com>
Message-ID: <WqYVDnocX1mrVjeLU5BltYDUKZvpYtmCJAqIPT5XYyo=.b82cfcca-b7f0-4880-9dcc-2df21a6f13a0@github.com>

> Cleans up some code in compilerWarnings_*.hpp files to be slightly neater

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  PRAGMA_NONNULL_IGNORED should match other pragma formats

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12255/files
  - new: https://git.openjdk.org/jdk/pull/12255/files/a3185f7c..99f8c3a9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12255&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12255&range=09-10

  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12255.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12255/head:pull/12255

PR: https://git.openjdk.org/jdk/pull/12255

From jwaters at openjdk.org  Tue Mar 14 07:29:14 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 14 Mar 2023 07:29:14 GMT
Subject: Integrated: 8301244: Tidy up compiler specific warnings files
In-Reply-To: <CU3GjASmLJw11Olusd1w5qnl-zb_d1hjVewzVEn3BS0=.277f1a89-0731-41ee-bad8-e15a57a826a4@github.com>
References: <CU3GjASmLJw11Olusd1w5qnl-zb_d1hjVewzVEn3BS0=.277f1a89-0731-41ee-bad8-e15a57a826a4@github.com>
Message-ID: <7s9pbp-4g87b3XFtZ-w0BkA2WA_znDAak3IdWutjgs0=.62a0fa99-e28d-433c-b626-7f6076224d70@github.com>

On Fri, 27 Jan 2023 13:40:20 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Cleans up some code in compilerWarnings_*.hpp files to be slightly neater

This pull request has now been integrated.

Changeset: 2bb990ed
Author:    Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2bb990edde5c8a08b9a9b209aa1fcdc3c38c3cb8
Stats:     9 lines in 2 files changed: 1 ins; 4 del; 4 mod

8301244: Tidy up compiler specific warnings files

Reviewed-by: kbarrett, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/12255

From chagedorn at openjdk.org  Tue Mar 14 09:08:12 2023
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 14 Mar 2023 09:08:12 GMT
Subject: RFR: 8302073: Specifying OnError handler prevents WatcherThread to
 break a deadlock in report_and_die()
In-Reply-To: <0jlQWouDE0tJ-ysn7WFYArqrJwHFQ-hhsZKKRGdVhmU=.95c4ceb0-9b8e-4c9b-9029-473626fb5a6b@github.com>
References: <nTD9cu_uj-X-ML_g-kbPrccPTlk5NGX9iV5TLXxOpbA=.2cea728c-6dbe-41a5-b379-a75c4ebc85e0@github.com>
 <k9wKuvOyzPUxNzE_aHGg_Abr5gckbriofiHDuMmhfps=.51b99d4a-8f1f-4134-8121-3738f2b13e41@github.com>
 <G-ReJaBrJTUBgWUmcE4eoqXQrtHCLPMSL7nQyom4QIM=.77438a77-60c9-4dc1-b811-7a71249d4358@github.com>
 <0jlQWouDE0tJ-ysn7WFYArqrJwHFQ-hhsZKKRGdVhmU=.95c4ceb0-9b8e-4c9b-9029-473626fb5a6b@github.com>
Message-ID: <ENv94gS1Al_g-WlkPImshjot7HVPKvid7g7ft8gxQNk=.1e5aa0f3-6bfc-4f9a-8df3-7f2c7f094c20@github.com>

On Thu, 9 Mar 2023 06:26:56 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Decoder, in particular, should not use malloc. Therefore I also opened https://bugs.openjdk.org/browse/JDK-8303862 to track that. I won't have time to work on that. I have the hope that maybe @chhagedorn can :-) ?

Does any of our current allocation strategies allow the usage of a custom scratch buffer (i.e. the error reporting scratch buffer) as memory location? If not, it could get more complicated. I could still try to tackle that but I'm not sure if I have the necessary knowledge in that area.

-------------

PR: https://git.openjdk.org/jdk/pull/12925

From rrich at openjdk.org  Tue Mar 14 09:24:08 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Tue, 14 Mar 2023 09:24:08 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v2]
In-Reply-To: <-Kj1YJ_nRa4nJtaxg3UR8uWhde6vIG1Jl-FFakGnHy4=.a41c6149-912b-4a66-8b1e-634bd27cdebb@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <-Kj1YJ_nRa4nJtaxg3UR8uWhde6vIG1Jl-FFakGnHy4=.a41c6149-912b-4a66-8b1e-634bd27cdebb@github.com>
Message-ID: <VQ34HqjCPRfc1b8v9BW1nm5V-qQaWN11vctJw3c10ck=.57c1c735-b453-42c2-a7c1-cc1049957af7@github.com>

On Thu, 9 Mar 2023 21:18:19 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
>> 
>> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
>> 
>> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
>> 
>> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
>> 
>> This change supports the following platforms: x86, aarch64, PPC, and RISCV
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Interpreter optimization and comments

@matias9927 can I ask you to merge master? There seem to be conflicts (at least I see a message "This branch has conflicts that must be resolved").
I'd like to give the change a spin in our CI testing. This requires that it can be applied on master.

-------------

PR: https://git.openjdk.org/jdk/pull/12778

From mbaesken at openjdk.org  Tue Mar 14 09:27:39 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 14 Mar 2023 09:27:39 GMT
Subject: RFR: JDK-8302989: Add missing INCLUDE_CDS checks [v4]
In-Reply-To: <dkwL4nBOs2Sh6R-tiu0xVFTioOXKZDXInHk6GW3BpWE=.c5d327fc-9e63-4c9d-b223-ea7aa8753b80@github.com>
References: <kBV8fNo_CWJL2MoXgAckFhuAFgQ3RGZjFKAKnl8xfV8=.233bb652-8508-4065-92ea-7873b1c765f3@github.com>
 <dkwL4nBOs2Sh6R-tiu0xVFTioOXKZDXInHk6GW3BpWE=.c5d327fc-9e63-4c9d-b223-ea7aa8753b80@github.com>
Message-ID: <iRYejvKu7eAwRb5gat1CqRL30-WKWIemspNcVgWVOP8=.8bef8e0a-0510-4c71-933d-43e386b164a8@github.com>

On Fri, 3 Mar 2023 08:55:07 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The cds only coding in hotspot is usually guarded with the INCLUDE_CDS macro so that it can be removed at compile time in case the correct configure flags are set.
>> However at some places INCLUDE_CDS is missing and should be added.
>> 
>> One question - should (additionally to the UseSharedSpaces code section)  the DumpSharedSpaces code sections be guarded as well with INCLUDE_CDS macros ?
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust arguments handling

I noticed that  the  Xshare-handling IS already an issue on AIX - there cds is not supported and `-Xshare:off`  does not work.
So tests like the ones I mentioned in my list above e.g.

java/math/BigInteger/largeMemory/DivisionOverflow.java

all fail on AIX  (like on other platforms without cds).

-------------

PR: https://git.openjdk.org/jdk/pull/12691

From kevinw at openjdk.org  Tue Mar 14 09:49:54 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 14 Mar 2023 09:49:54 GMT
Subject: RFR: 8303150: DCmd framework unnecessarily creates a DCmd instance
 on registration
In-Reply-To: <TNyX996lKlRcmTijRTN0VUZBcNBt2DXeMPhDBjaa0NQ=.160293b7-4570-43a5-af9e-d9cb02022820@github.com>
References: <TNyX996lKlRcmTijRTN0VUZBcNBt2DXeMPhDBjaa0NQ=.160293b7-4570-43a5-af9e-d9cb02022820@github.com>
Message-ID: <X5Q2C2EZpTXFzEVwH1vO0_W4VSa3OA8w3YORZ-ucbyQ=.f5cdc97d-d97d-40d4-a9ea-7e432483d8a6@github.com>

On Mon, 13 Mar 2023 01:19:50 GMT, David Holmes <dholmes at openjdk.org> wrote:

> When DCmd factories are registered, the factory is passed the number of arguments taken by the DCmd - using a template method `get_num_arguments`. For DCmds that don't extend DCmdWithParser there has to be a static `num_arguments()` method in that class. For DCmds that do extend DCmdWithParser the logic instantiates an instance of the DCmd, extracts its parser and calls its `num_arguments` method which dynamically counts the number of defined arguments.
> 
> Creating an instance of each DCmd and dynamically counting arguments is inefficient and unnecessary, the number of arguments is statically known and easily expressed (in fact many of the JFR DCmds already statically define this). So we add the static `num_arguments()` method to each class that needs it and return the statically counted number of arguments. To ensure the static number and actual number don't get out-of-sync, we keep the original dynamic logic for use in debug builds to assert that the static and dynamic counts are the same. The assert will trigger during a debug build if something does get out of sync, for example if a new DCmd (extending DCmdWithParser) were added but didn't define the static `num_arguments()` method.
> 
> A number of DCmd classes were unnecessarily defining their own dynamic version of `num_arguments` and these are now removed.
> 
> In the template method I use `ENABLE_IF(std::is_convertible<T, DCmd>::value)` to check we only call this on DCmd classes. This may be unnecessary but it seemed consistent with the other template methods. Note that `std::is_base_of` only works for immediate super types.
> 
> Testing: tiers 1-4
> 
> Performance: in theory we should see some improvement in startup; in practice it is barely noticeable.
> 
> Thanks.

src/hotspot/share/services/diagnosticFramework.hpp line 1:

> 1: /*

Should we update this comment:
279   // - For subclasses of DCmdWithParser, it's calculated by DCmdParser::num_arguments().

-------------

PR: https://git.openjdk.org/jdk/pull/12994

From duke at openjdk.org  Tue Mar 14 09:50:17 2023
From: duke at openjdk.org (Afshin Zafari)
Date: Tue, 14 Mar 2023 09:50:17 GMT
Subject: RFR: 8292059: Do not inline InstanceKlass::allocate_instance()
 [v6]
In-Reply-To: <ZSJBTzuC4wVuKdqSLLTgw4Pds2oX5wah0Ub6rFux_tc=.c4e2ae89-cadb-4ccd-9eee-034583cf7200@github.com>
References: <ZSJBTzuC4wVuKdqSLLTgw4Pds2oX5wah0Ub6rFux_tc=.c4e2ae89-cadb-4ccd-9eee-034583cf7200@github.com>
Message-ID: <QHPRRNYQPAcZ8QEeb_uz9cBq4Y1fDpcQqvutYIbZiiU=.017aeac3-5d24-4f40-aefb-045bdf7d4a84@github.com>

> The inline and not-inline versions of the method is tested to compare the performance difference. 
> ### Test
> `make test TEST=micro:Capture0.lambda_01 MICRO="VM_OPTIONS=-XX:TieredStopAtLevel=1" `

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  8292059: Do not inline InstanceKlass::allocate_instance()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12782/files
  - new: https://git.openjdk.org/jdk/pull/12782/files/0ef3159a..4165cab8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12782&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12782&range=04-05

  Stats: 9 lines in 3 files changed: 8 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12782.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12782/head:pull/12782

PR: https://git.openjdk.org/jdk/pull/12782

From rkennke at openjdk.org  Tue Mar 14 10:19:30 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 14 Mar 2023 10:19:30 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v23]
In-Reply-To: <P-iheLBjdOGikiJhK78k2BYcz-xhvu2n2i7WM4W4AXc=.453a4d91-bca3-429b-bbcc-d2a58fccb853@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <P-iheLBjdOGikiJhK78k2BYcz-xhvu2n2i7WM4W4AXc=.453a4d91-bca3-429b-bbcc-d2a58fccb853@github.com>
Message-ID: <BYJ21grR-QWTsjtp7ZJwLVvJOkuQGFcGYr0Rygz__Ls=.eeab04bf-40d0-454a-8a42-064d9671254c@github.com>

On Mon, 13 Mar 2023 20:02:45 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   X86 parts

Thank you all for your review comments! I will address them today.
Yesterday I pushed a rather significant change that probably warrants some explanation. Previously, the lock-stack could be grown when its capacity is no longer sufficient. However, that means that we needed to maintain 3 pointers: the stack base, the current stack-pointer and the limit. Also, checking for room on the lock-stack involved loading 2 of these two pointers (current and limit) and comparing them. This used to be tricky because it requires two registers on some platforms. The insight that leads to the improved implementation is that the lock-stack is very commonly very shallow: I did an experiment with several workloads yesterday and it never exceeded a depth of 5. I now made the lock-stack size 8 elements and fixed-size. When the lock-stack ever is full, then we have to bite the bullet and inflate the monitor, but this should be very very rare. On the upside, the check for lock stack is now much simpler: we only need to load the current stack offset and compare it to the 
 end offset - which is a constant and can be encoded as immediate. Also, the current 'pointer' is now an offset relative to the beginning of the JavaThread structure, this way the lock-stack can be addressed using indirect addressing on rthread.
Additionally, I eliminated the code that checks for enough lock-stack upon method entry. This has not been very useful and often lead to excessive lock-stack-growth.
@RealFYang You may want to update the RISCV code to reflect those latest changes, otherwise it would now be broken.
I will now address your comments and also change the implementation of SA.

Thanks,
Roman

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From rkennke at openjdk.org  Tue Mar 14 10:49:30 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 14 Mar 2023 10:49:30 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v24]
In-Reply-To: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
Message-ID: <ae6CUi2kNWx_-33-5MAvCEQcubDliCL3_jSk2sgH2Ek=.e4480df2-b92b-4fcd-a551-b1de7f1a6cfc@github.com>

> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
> 
> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p
 rotocols.
> 
> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
> 
> 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
> 
> 
> Testing:
>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
> 
> ### Performance
> 
> #### Simple Microbenchmark
> 
> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
> 
> |  | x86_64 | aarch64 |
> | -- | -- | -- |
> | -UseFastLocking | 20.651 | 20.764 |
> | +UseFastLocking | 18.896 | 18.908 |
> 
> 
> #### Renaissance
> 
> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
> -- | -- | -- | -- | -- | -- | -- | --
> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Use -w instructions in new locking code stubs (aarch64)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10907/files
  - new: https://git.openjdk.org/jdk/pull/10907/files/75db4f0a..87b95bf7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=22-23

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10907.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10907/head:pull/10907

PR: https://git.openjdk.org/jdk/pull/10907

From mgronlun at openjdk.org  Tue Mar 14 12:25:54 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 14 Mar 2023 12:25:54 GMT
Subject: RFR: 8257967: JFR: Events for loaded agents [v10]
In-Reply-To: <M86HnsWFDyZ0UNtNsefyHOG-wSDPBIkETS76BtkhCBc=.c65616e6-b644-4db9-b64b-d1319a87b915@github.com>
References: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
 <ZsaBMVK-eeLfmxgg15qPJHm6C-ed5PyIE4lGr-Gnr2s=.2f4044c4-e7ed-48f3-8877-feeb2753be18@github.com>
 <M86HnsWFDyZ0UNtNsefyHOG-wSDPBIkETS76BtkhCBc=.c65616e6-b644-4db9-b64b-d1319a87b915@github.com>
Message-ID: <5uEVRUEr0vSBiTHqKpKVwG1k-v5UrFr9RVAip3K8NSg=.a7bf35b5-b372-4ba6-b217-642c6ad4e2a8@github.com>

On Mon, 13 Mar 2023 06:22:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more cleanup
>
> src/hotspot/share/prims/agent.cpp line 34:
> 
>> 32: }
>> 33: 
>> 34: static const char* allocate_copy(const char* str) {
> 
> Why not just use `os::strdup`?

Better alternative, thanks David.

> src/hotspot/share/prims/agentList.cpp line 227:
> 
>> 225:  * store data in their JvmtiEnv local storage.
>> 226:  *
>> 227:  * Please see JPLISAgent.c in module java.instrument, see JPLISAgent.h and JPLISAgent.c.
> 
> No need to mention the .c file twice.

Good point.

> src/hotspot/share/prims/agentList.cpp line 419:
> 
>> 417:     const jint err = (*on_load_entry)(&main_vm, const_cast<char*>(agent->options()), NULL);
>> 418:     if (err != JNI_OK) {
>> 419:       vm_exit_during_initialization("-Xrun library failed to init", agent->name());
> 
> Do you need to be back in `_thread_in_vm` before exiting?

Hmm. This was ported as is. I will double-check.

> src/hotspot/share/prims/agentList.cpp line 542:
> 
>> 540: 
>> 541:   // Invoke the Agent_OnAttach function
>> 542:   JavaThread* THREAD = JavaThread::current(); // For exception macros.
> 
> Nit: just use `current` rather than `THREAD` and don't use the exception macros.

Ported as is but good point, will update.

-------------

PR: https://git.openjdk.org/jdk/pull/12923

From mgronlun at openjdk.org  Tue Mar 14 12:26:00 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 14 Mar 2023 12:26:00 GMT
Subject: RFR: 8257967: JFR: Events for loaded agents [v9]
In-Reply-To: <qafwYGs-uxNmucUXY-qWxhxwNpNBAb3N95hATo1HOLw=.15a10a71-d029-4c50-a249-dcb6a18b6902@github.com>
References: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
 <HgrCtIIibi1v0BdGh1myrOFfq1z8CrlDf2aFHFzP_mo=.fd09126d-2bcf-4e7f-8d9f-3933ed676566@github.com>
 <qafwYGs-uxNmucUXY-qWxhxwNpNBAb3N95hATo1HOLw=.15a10a71-d029-4c50-a249-dcb6a18b6902@github.com>
Message-ID: <HVkwIXbQOjjIYSXadLiOFrkLaG5OgUG5MONfK4c0pvE=.cf4b0311-56cb-4b62-9c70-cadbfa725da1@github.com>

On Fri, 10 Mar 2023 06:57:46 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   handle multiple envs with same VMInit callback
>
> src/hotspot/share/prims/agent.cpp line 41:
> 
>> 39:   char* copy = AllocateHeap(length + 1, mtInternal);
>> 40:   strncpy(copy, str, length + 1);
>> 41:   assert(strncmp(copy, str, length + 1) == 0, "invariant");
> 
> Unclear what you are checking here. Don't you trust strncpy?

Maybe a bit paranoid, yes. I can clean up.

-------------

PR: https://git.openjdk.org/jdk/pull/12923

From mgronlun at openjdk.org  Tue Mar 14 12:26:03 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 14 Mar 2023 12:26:03 GMT
Subject: RFR: 8257967: JFR: Events for loaded agents [v10]
In-Reply-To: <Zwh7j7Mek5EyfIJBgNYom2kZy71QLxSHyI5BmHe1gqY=.0b9da360-0979-4394-ae9c-adac9cadbfee@github.com>
References: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
 <ZsaBMVK-eeLfmxgg15qPJHm6C-ed5PyIE4lGr-Gnr2s=.2f4044c4-e7ed-48f3-8877-feeb2753be18@github.com>
 <M86HnsWFDyZ0UNtNsefyHOG-wSDPBIkETS76BtkhCBc=.c65616e6-b644-4db9-b64b-d1319a87b915@github.com>
 <Zwh7j7Mek5EyfIJBgNYom2kZy71QLxSHyI5BmHe1gqY=.0b9da360-0979-4394-ae9c-adac9cadbfee@github.com>
Message-ID: <-OvxuwPKbYU514MyCXdcC5-0Nt1ftlipuUFueCe3DGc=.3b0140b3-ef41-4ad6-9515-ec6e9ef40250@github.com>

On Mon, 13 Mar 2023 09:49:39 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> src/hotspot/share/prims/agentList.cpp line 64:
>> 
>>> 62: void AgentList::add_xrun(const char* name, char* options, bool absolute_path) {
>>> 63:   Agent* agent = new Agent(name, options, absolute_path);
>>> 64:   agent->_is_xrun = true;
>> 
>> Why direct access of private field instead of having a setter like other parts of the Agent API?
>
> n.b. that also applies for accesses/updates to field _next.

I wanted all accesses to use the iterator. The only access is given to the iterator and AgentList by way of being friends. No need to expose more.

-------------

PR: https://git.openjdk.org/jdk/pull/12923

From mgronlun at openjdk.org  Tue Mar 14 12:29:10 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 14 Mar 2023 12:29:10 GMT
Subject: RFR: 8257967: JFR: Events for loaded agents [v10]
In-Reply-To: <sKa6RRVpBw1kQ0DoQHMclspRNTBJZlKicmXBOUSWDBk=.0b538fa3-7db0-4863-a2aa-b3cd0f692959@github.com>
References: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
 <ZsaBMVK-eeLfmxgg15qPJHm6C-ed5PyIE4lGr-Gnr2s=.2f4044c4-e7ed-48f3-8877-feeb2753be18@github.com>
 <sKa6RRVpBw1kQ0DoQHMclspRNTBJZlKicmXBOUSWDBk=.0b538fa3-7db0-4863-a2aa-b3cd0f692959@github.com>
Message-ID: <iEqkEPSOYqIpc0uneK7i3LiKMP2WY_joe2Que3feIeM=.82be29bb-cfc7-4573-be7e-a363b7bf5989@github.com>

On Tue, 14 Mar 2023 06:01:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I've had a good look through now and have a better sense of the refactoring. Seems good.
> 
> 
> 
> I'll wait for any tweaks before hitting the approve button though.
> 
> 
> 
> Thanks

Thanks so much for taking a look. I realized that implementation details of loading should probably reside in agent.cpp, not agentList.cpp.

I am currently off on vacation and will update when back. Thanks also to Andrew Dinn for comments.

-------------

PR: https://git.openjdk.org/jdk/pull/12923

From mgronlun at openjdk.org  Tue Mar 14 12:29:14 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 14 Mar 2023 12:29:14 GMT
Subject: RFR: 8257967: JFR: Events for loaded agents [v10]
In-Reply-To: <nDqJr3UvnHKKXqOblbPcpU_N3sNNN3XpfsaY9XIZ6jQ=.78392ad6-2a97-4758-a267-94e797dab7f1@github.com>
References: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
 <ZsaBMVK-eeLfmxgg15qPJHm6C-ed5PyIE4lGr-Gnr2s=.2f4044c4-e7ed-48f3-8877-feeb2753be18@github.com>
 <nDqJr3UvnHKKXqOblbPcpU_N3sNNN3XpfsaY9XIZ6jQ=.78392ad6-2a97-4758-a267-94e797dab7f1@github.com>
Message-ID: <z85l94-AWW7ST7u5CFEMiqYTHvNu9bu3kxygLcMRX-8=.bfe3f898-8b5a-4e31-80e0-5d3ba4e57d7d@github.com>

On Mon, 13 Mar 2023 09:46:04 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more cleanup
>
> src/hotspot/share/jfr/metadata/metadata.xml line 1182:
> 
>> 1180:     <Field type="Ticks" name="initialization" label="Initialization" description="The time the JVM initialized the agent" />
>> 1181:     <Field type="Tickspan" name="initializationTime" label="Initialization Time" description="The duration of executing the initialization method exported by the agent" />
>> 1182:   </Event>
> 
> @mgronlun A somewhat drive-by comment. It might be clearer if you renamed these event fields and accessors, plus also the corresponding fields and accessors in class Agent, as `initializationTime` and `initializationDuration`.

Makes sense.

-------------

PR: https://git.openjdk.org/jdk/pull/12923

From duke at openjdk.org  Tue Mar 14 12:45:42 2023
From: duke at openjdk.org (Jan Kratochvil)
Date: Tue, 14 Mar 2023 12:45:42 GMT
Subject: RFR: 8302191: Performance degradation for float/double modulo on
 Linux [v13]
In-Reply-To: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
References: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
Message-ID: <CkbXLZNrBGwQzsb88Gx3NnEPfvtcVQcTM9BiObmLMwg=.4fb98a6e-3839-48d5-9b83-c1b857b30e60@github.com>

> I have OCA already processed/approved. I am not Author but my Author request is being processed these days (sent to Rob McKenna).
> I did regression test x86_64 OpenJDK-8. I will leave other regression testing on GHA.
> The patch (and former GCC performance regression) affects only x86_64+i686.

Jan Kratochvil 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 branch 'master' into modulo
 - Fix missing SharedRuntime::frem and SharedRuntime::drem on aarch64.
    - bugreported by sviswa7.
 - Merge branch 'master' into modulo
 - Fix #endif comment - found by dholmes-ora.
 - Merge branch 'master' into modulo
 - Fix win32 broken build.
 - Merge remote-tracking branch 'origin/master' into modulo
 - Always include the _WIN64 workaround - a review by dholmes-ora.
 - Remove comments to be moved to JBS (Bug System) - a review by jddarcy.
 - Uppercase L - a review by turbanoff.
 - ... and 4 more: https://git.openjdk.org/jdk/compare/e171ac47...65af58da

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12508/files
  - new: https://git.openjdk.org/jdk/pull/12508/files/f03d4cdf..65af58da

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12508&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12508&range=11-12

  Stats: 71276 lines in 811 files changed: 58833 ins; 4868 del; 7575 mod
  Patch: https://git.openjdk.org/jdk/pull/12508.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12508/head:pull/12508

PR: https://git.openjdk.org/jdk/pull/12508

From fparain at openjdk.org  Tue Mar 14 13:15:54 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 14 Mar 2023 13:15:54 GMT
Subject: RFR: 8292818: replace 96-bit representation for field metadata
 with variable-sized streams [v4]
In-Reply-To: <5apLgAhjSwiK-sv6Xrl9yZctZTAe_GahWGyk8rUYgvk=.1af11917-7547-48ba-b958-01c6ef6f9f18@github.com>
References: <vdiacOO3JUyy4sWGkDXNBMUT7cG3XYe79mOvYru9uMM=.9c556675-7ffd-4c09-a428-6d64dffef209@github.com>
 <hAGW4he3pjU6G9IuyygughaiDUL9vKNHzKcURWD4tSI=.b67e5661-9978-4d9d-850e-0a6399de5a64@github.com>
 <5apLgAhjSwiK-sv6Xrl9yZctZTAe_GahWGyk8rUYgvk=.1af11917-7547-48ba-b958-01c6ef6f9f18@github.com>
Message-ID: <PiqbuEn7pifvUms-qjhA9u0VhFRRTw3WVfQvBd1WJfQ=.e5fd2aa4-88b3-4d9b-a6f2-47ec465ab479@github.com>

On Mon, 13 Mar 2023 21:53:37 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixes includes and style
>
> src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/meta/ResolvedJavaField.java line 48:
> 
>> 46:      * Returns VM internal flags associated with this field
>> 47:      */
>> 48:     int getInternalModifiers();
> 
> We've never exposed the internal modifiers before in public JVMCI API and we should refrain from doing so until there's a good reason to do so. Please remove this method.

Access to internal modifiers is needed in `HotSpotResolvedJavaFieldTest.testEquivalenceForInternalFields()`. I moved the declaration of the method to `HotSpotResolvedJavaField`. Does this change work for you?

-------------

PR: https://git.openjdk.org/jdk/pull/12855

From fparain at openjdk.org  Tue Mar 14 13:19:37 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 14 Mar 2023 13:19:37 GMT
Subject: RFR: 8292818: replace 96-bit representation for field metadata
 with variable-sized streams [v4]
In-Reply-To: <5apLgAhjSwiK-sv6Xrl9yZctZTAe_GahWGyk8rUYgvk=.1af11917-7547-48ba-b958-01c6ef6f9f18@github.com>
References: <vdiacOO3JUyy4sWGkDXNBMUT7cG3XYe79mOvYru9uMM=.9c556675-7ffd-4c09-a428-6d64dffef209@github.com>
 <hAGW4he3pjU6G9IuyygughaiDUL9vKNHzKcURWD4tSI=.b67e5661-9978-4d9d-850e-0a6399de5a64@github.com>
 <5apLgAhjSwiK-sv6Xrl9yZctZTAe_GahWGyk8rUYgvk=.1af11917-7547-48ba-b958-01c6ef6f9f18@github.com>
Message-ID: <kuYwnoKAwMpZ_scnRvC_EvRGae8UXWTffQQwM-M5gso=.ce8fa006-e2ae-447f-a236-f416ca6dd4c7@github.com>

On Mon, 13 Mar 2023 21:44:59 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixes includes and style
>
> src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 416:
> 
>> 414:   declare_constant(FieldInfo::FieldFlags::_ff_injected)                   \
>> 415:   declare_constant(FieldInfo::FieldFlags::_ff_stable)                     \
>> 416:   declare_constant(FieldInfo::FieldFlags::_ff_generic)                    \
> 
> I don't think `_ff_generic` is used in the JVMCI Java code so this entry can be deleted. Please double check the other entries.

_ff_generic removed.
_ff_stable is used in `HotSpotResolvedJavaFieldImpl.isStable()`.
_ff_injected is used in `HotSpotResolvedJavaFieldImpl.isInternal()`

-------------

PR: https://git.openjdk.org/jdk/pull/12855

From coleenp at openjdk.org  Tue Mar 14 13:21:55 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 14 Mar 2023 13:21:55 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v2]
In-Reply-To: <3QfQXArLyZzTcdg4r9bSGJKmnoG_YY8OFOJ0eLz2rYY=.e83d9ff2-8c7e-471c-b250-97a92e7db1e5@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <-Kj1YJ_nRa4nJtaxg3UR8uWhde6vIG1Jl-FFakGnHy4=.a41c6149-912b-4a66-8b1e-634bd27cdebb@github.com>
 <3QfQXArLyZzTcdg4r9bSGJKmnoG_YY8OFOJ0eLz2rYY=.e83d9ff2-8c7e-471c-b250-97a92e7db1e5@github.com>
Message-ID: <z6hnwd-SRmxQk1Uyjg9TjjWMzBqbYv7Kt6QOqu2CeMY=.5df4133c-0648-4508-8796-f447b6939aca@github.com>

On Mon, 13 Mar 2023 21:05:11 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Interpreter optimization and comments
>
> src/hotspot/cpu/x86/templateTable_x86.cpp line 2798:
> 
>> 2796:                                                bool is_invokevirtual,
>> 2797:                                                bool is_invokevfinal, /*unused*/
>> 2798:                                                bool is_invokedynamic /*unused*/) {
> 
> Can you remove the parameter since the s390 port is here?

Ok, never mind, I saw s390 port but it doesn't seem to be in these changes (?)

-------------

PR: https://git.openjdk.org/jdk/pull/12778

From coleenp at openjdk.org  Tue Mar 14 13:28:29 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 14 Mar 2023 13:28:29 GMT
Subject: RFR: 8304089: Convert TraceDependencies to UL
Message-ID: <0aGc1NdAjpvksCWmXb1gZOPp9MV0n6xWvG8EaEp2ZLg=.b79cf218-9a23-420d-bec5-7509b7f8f1c1@github.com>

This change converts TraceDependencies to UL and removes the develop option. I think this provides further flexibility to add tags to only trace certain things in dependency analysis, as I did when trying to understand a PR for a deoptimization change.  For now, the messages are the same and the option is -Xlog:dependencies=debug.
Tested with tier1-4

-------------

Commit messages:
 - Logging

Changes: https://git.openjdk.org/jdk/pull/13007/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13007&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304089
  Stats: 78 lines in 14 files changed: 23 ins; 3 del; 52 mod
  Patch: https://git.openjdk.org/jdk/pull/13007.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/13007/head:pull/13007

PR: https://git.openjdk.org/jdk/pull/13007

From coleenp at openjdk.org  Tue Mar 14 13:38:10 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 14 Mar 2023 13:38:10 GMT
Subject: RFR: 8304089: Convert TraceDependencies to UL [v2]
In-Reply-To: <0aGc1NdAjpvksCWmXb1gZOPp9MV0n6xWvG8EaEp2ZLg=.b79cf218-9a23-420d-bec5-7509b7f8f1c1@github.com>
References: <0aGc1NdAjpvksCWmXb1gZOPp9MV0n6xWvG8EaEp2ZLg=.b79cf218-9a23-420d-bec5-7509b7f8f1c1@github.com>
Message-ID: <mIc2GYU8rI6snhb73R8QcZHIURy7mXJrP8gksJjWBvo=.f966654d-d0df-46d2-80d6-aa8f0be07cb5@github.com>

> This change converts TraceDependencies to UL and removes the develop option. I think this provides further flexibility to add tags to only trace certain things in dependency analysis, as I did when trying to understand a PR for a deoptimization change.  For now, the messages are the same and the option is -Xlog:dependencies=debug.
> Tested with tier1-4

Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge branch 'master' into trace-dependencies-logging
 - Logging

-------------

Changes: https://git.openjdk.org/jdk/pull/13007/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13007&range=01
  Stats: 79 lines in 14 files changed: 23 ins; 3 del; 53 mod
  Patch: https://git.openjdk.org/jdk/pull/13007.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/13007/head:pull/13007

PR: https://git.openjdk.org/jdk/pull/13007

From fparain at openjdk.org  Tue Mar 14 13:40:55 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 14 Mar 2023 13:40:55 GMT
Subject: RFR: 8292818: replace 96-bit representation for field metadata
 with variable-sized streams [v4]
In-Reply-To: <5apLgAhjSwiK-sv6Xrl9yZctZTAe_GahWGyk8rUYgvk=.1af11917-7547-48ba-b958-01c6ef6f9f18@github.com>
References: <vdiacOO3JUyy4sWGkDXNBMUT7cG3XYe79mOvYru9uMM=.9c556675-7ffd-4c09-a428-6d64dffef209@github.com>
 <hAGW4he3pjU6G9IuyygughaiDUL9vKNHzKcURWD4tSI=.b67e5661-9978-4d9d-850e-0a6399de5a64@github.com>
 <5apLgAhjSwiK-sv6Xrl9yZctZTAe_GahWGyk8rUYgvk=.1af11917-7547-48ba-b958-01c6ef6f9f18@github.com>
Message-ID: <WkhAOfNqsAbDlIOsGSC-mrSj2uhBc3IBIQKBbrQjMpw=.066f182d-4ff2-445b-bee7-39c8f2dc8ba2@github.com>

On Mon, 13 Mar 2023 21:35:17 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixes includes and style
>
> src/hotspot/share/jvmci/jvmciEnv.hpp line 149:
> 
>> 147: };
>> 148: 
>> 149: extern JNIEXPORT jobjectArray c2v_getDeclaredFieldsInfo(JNIEnv* env, jobject, jobject, jlong);
> 
> What's the purpose of this declaration? I don't think you need it or the `friend` declaration below since `new_FieldInfo(FieldInfo* fieldinfo, JVMCI_TRAPS)` is public.

Without this declaration, builds fail on Windows with this error:
`error C2375: 'c2v_getDeclaredFieldsInfo': redefinition; different linkage`

-------------

PR: https://git.openjdk.org/jdk/pull/12855

From matsaave at openjdk.org  Tue Mar 14 13:59:48 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 14 Mar 2023 13:59:48 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v3]
In-Reply-To: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
Message-ID: <vR9DLx3Oi7S-M_8Qu-d0k6DfZTqfamB4AYt-JLeErvk=.0cf5358f-71fe-4956-8683-1ceae15de148@github.com>

> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
> 
> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
> 
> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
> 
> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
> 
> This change supports the following platforms: x86, aarch64, PPC, and RISCV

Matias Saavedra Silva 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:

 - Typo in comment
 - Merge branch 'master' into resolvedIndyEntry_8301995
 - Interpreter optimization and comments
 - PPC and RISCV port
 - 8301995: Move invokedynamic resolution information out of the cpCache

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12778/files
  - new: https://git.openjdk.org/jdk/pull/12778/files/c2d87e59..a3e7ca02

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12778&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12778&range=01-02

  Stats: 92608 lines in 1481 files changed: 72908 ins; 8825 del; 10875 mod
  Patch: https://git.openjdk.org/jdk/pull/12778.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12778/head:pull/12778

PR: https://git.openjdk.org/jdk/pull/12778

From stuefe at openjdk.org  Tue Mar 14 14:05:14 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 14 Mar 2023 14:05:14 GMT
Subject: RFR: 8302073: Specifying OnError handler prevents WatcherThread to
 break a deadlock in report_and_die()
In-Reply-To: <ENv94gS1Al_g-WlkPImshjot7HVPKvid7g7ft8gxQNk=.1e5aa0f3-6bfc-4f9a-8df3-7f2c7f094c20@github.com>
References: <nTD9cu_uj-X-ML_g-kbPrccPTlk5NGX9iV5TLXxOpbA=.2cea728c-6dbe-41a5-b379-a75c4ebc85e0@github.com>
 <k9wKuvOyzPUxNzE_aHGg_Abr5gckbriofiHDuMmhfps=.51b99d4a-8f1f-4134-8121-3738f2b13e41@github.com>
 <G-ReJaBrJTUBgWUmcE4eoqXQrtHCLPMSL7nQyom4QIM=.77438a77-60c9-4dc1-b811-7a71249d4358@github.com>
 <0jlQWouDE0tJ-ysn7WFYArqrJwHFQ-hhsZKKRGdVhmU=.95c4ceb0-9b8e-4c9b-9029-473626fb5a6b@github.com>
 <ENv94gS1Al_g-WlkPImshjot7HVPKvid7g7ft8gxQNk=.1e5aa0f3-6bfc-4f9a-8df3-7f2c7f094c20@github.com>
Message-ID: <1c5aw52eXF3IwxfP7pk4ZlfMer3eI02C41XyDuZruik=.cd19d3a0-51be-451c-9a0a-bf386b3114b6@github.com>

On Tue, 14 Mar 2023 09:04:51 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> > Decoder, in particular, should not use malloc. Therefore I also opened https://bugs.openjdk.org/browse/JDK-8303862 to track that. I won't have time to work on that. I have the hope that maybe @chhagedorn can :-) ?
> 
> Does any of our current allocation strategies allow the usage of a custom scratch buffer (i.e. the error reporting scratch buffer) as memory location? If not, it could get more complicated. I could still try to tackle that but I'm not sure if I have the necessary knowledge in that area.

What we usually do for these kind of problems is to pass the scratch buffer via argument to the processing functions. And make that use either it or, if NULL was passes, allocate its own thing.

Another way to do this would be to add a scratch buffer pointer to Thread.

A third way to do this (I had been experimenting with it) would be to pre-allocate a scratch buffer, and once error handling began, to use that inside os::malloc. That is the most involved solution, though, and I'm not particularly fond of it. I know many reviewers would hate it, too :-)

-------------

PR: https://git.openjdk.org/jdk/pull/12925

From stuefe at openjdk.org  Tue Mar 14 14:22:28 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 14 Mar 2023 14:22:28 GMT
Subject: RFR: JDK-8303861: Error handling step timeouts should never be
 blocked by OnError and others [v5]
In-Reply-To: <MsoamxpcF7RfrdiX5BXcHcluFN6HqcIZwwLedCUSQck=.8f187897-f3b4-46b8-9811-faba5d2e0b7b@github.com>
References: <MsoamxpcF7RfrdiX5BXcHcluFN6HqcIZwwLedCUSQck=.8f187897-f3b4-46b8-9811-faba5d2e0b7b@github.com>
Message-ID: <rWhNUsS269pugRwKX_EOmOMV5TXqFDtRhKNQts8soJo=.2d6c9e3a-92ca-47b3-9587-b416d7fca427@github.com>

> Fatal error handling is subject to several timeouts:
> - a global timeout (controlled via ErrorLogTimeout)
> - local error reporting step timeouts.
> 
> The latter aims to "give the JVM a kick" if it gets stuck in one particular place during error reporting. This prevents one error reporting step from hogging all the time allotted to error reporting under ErrorLogTimeout.
> 
> There are three situations where atm we suppress the global error timeout:
> - if the JVM is embedded and the launcher has its abort hook installed. Obviously, that must be allowed to run.
> - if the user specified one or more OnError commands to run, and these did not yet run. These must have a chance to run unmolested.
> - if the user (typically developer) specified ShowMessageBoxOnError, and the error box has not yet been shown
> 
> There is a bug though, that also prevents the step timeout from firing if either condition is true. That is plain wrong.
> 
> In addition to that, the test interval WatcherThread uses to check for timeouts should be decreased. It sits at 1 second, which is too coarse-grained. 
> 
> --------
> 
> Patch:
> - reworks `VMError::check_timeout()` to never block step timeouts
> - adds clarifying comments
> - quadruples timeout check frequency by watcher thread
> - adds regression test for timeout handling with OnError
> - additionally limits timeout per individual error reporting step to 5 seconds. 5 seconds is usually enough to distinguish a slow error reporting step from one that is endlessly hanging. 
> 
> Tested locally on Linux x64.

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  remove-stray-at-sign

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12936/files
  - new: https://git.openjdk.org/jdk/pull/12936/files/52f382db..fcbb198a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12936&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12936&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12936.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12936/head:pull/12936

PR: https://git.openjdk.org/jdk/pull/12936

From rrich at openjdk.org  Tue Mar 14 14:54:06 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Tue, 14 Mar 2023 14:54:06 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v2]
In-Reply-To: <z6hnwd-SRmxQk1Uyjg9TjjWMzBqbYv7Kt6QOqu2CeMY=.5df4133c-0648-4508-8796-f447b6939aca@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <-Kj1YJ_nRa4nJtaxg3UR8uWhde6vIG1Jl-FFakGnHy4=.a41c6149-912b-4a66-8b1e-634bd27cdebb@github.com>
 <3QfQXArLyZzTcdg4r9bSGJKmnoG_YY8OFOJ0eLz2rYY=.e83d9ff2-8c7e-471c-b250-97a92e7db1e5@github.com>
 <z6hnwd-SRmxQk1Uyjg9TjjWMzBqbYv7Kt6QOqu2CeMY=.5df4133c-0648-4508-8796-f447b6939aca@github.com>
Message-ID: <6ungKcriyVh3xBdyFAA7AwOHgNMAO8E1fWeGi1Ap3gA=.fc8c1ee2-66a4-4324-be69-f186360efb5a@github.com>

On Tue, 14 Mar 2023 13:18:40 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Ok, never mind, I saw s390 port but it doesn't seem to be in these changes (?)

It is not in these changes.
@offamitkumar is working on s390x. It is not yet finished though.
(I wasn't aware that putting the URL of this PR into a comment somewhere else adds a comment to this PR)

-------------

PR: https://git.openjdk.org/jdk/pull/12778

From dnsimon at openjdk.org  Tue Mar 14 15:13:00 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 14 Mar 2023 15:13:00 GMT
Subject: RFR: 8292818: replace 96-bit representation for field metadata
 with variable-sized streams [v4]
In-Reply-To: <PiqbuEn7pifvUms-qjhA9u0VhFRRTw3WVfQvBd1WJfQ=.e5fd2aa4-88b3-4d9b-a6f2-47ec465ab479@github.com>
References: <vdiacOO3JUyy4sWGkDXNBMUT7cG3XYe79mOvYru9uMM=.9c556675-7ffd-4c09-a428-6d64dffef209@github.com>
 <hAGW4he3pjU6G9IuyygughaiDUL9vKNHzKcURWD4tSI=.b67e5661-9978-4d9d-850e-0a6399de5a64@github.com>
 <5apLgAhjSwiK-sv6Xrl9yZctZTAe_GahWGyk8rUYgvk=.1af11917-7547-48ba-b958-01c6ef6f9f18@github.com>
 <PiqbuEn7pifvUms-qjhA9u0VhFRRTw3WVfQvBd1WJfQ=.e5fd2aa4-88b3-4d9b-a6f2-47ec465ab479@github.com>
Message-ID: <23n-dTVRiGuVl7imPvKph7q43FuB1k7Hak6-mGNDKeM=.40ca325c-e53f-4950-bece-99b7e4f4d367@github.com>

On Tue, 14 Mar 2023 13:12:31 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/meta/ResolvedJavaField.java line 48:
>> 
>>> 46:      * Returns VM internal flags associated with this field
>>> 47:      */
>>> 48:     int getInternalModifiers();
>> 
>> We've never exposed the internal modifiers before in public JVMCI API and we should refrain from doing so until there's a good reason to do so. Please remove this method.
>
> Access to internal modifiers is needed in `HotSpotResolvedJavaFieldTest.testEquivalenceForInternalFields()`. I moved the declaration of the method to `HotSpotResolvedJavaField`. Does this change work for you?

Just use reflection to read the internal flags (like this test already does for the `index` field).

I've attached [review.patch](https://github.com/openjdk/jdk/files/10970245/review.patch) with this change and a few other changes I think should be made for better naming (plus one test cleanup).

-------------

PR: https://git.openjdk.org/jdk/pull/12855

From coleenp at openjdk.org  Tue Mar 14 15:40:53 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 14 Mar 2023 15:40:53 GMT
Subject: RFR: 8304089: Convert TraceDependencies to UL [v3]
In-Reply-To: <0aGc1NdAjpvksCWmXb1gZOPp9MV0n6xWvG8EaEp2ZLg=.b79cf218-9a23-420d-bec5-7509b7f8f1c1@github.com>
References: <0aGc1NdAjpvksCWmXb1gZOPp9MV0n6xWvG8EaEp2ZLg=.b79cf218-9a23-420d-bec5-7509b7f8f1c1@github.com>
Message-ID: <BQzDwBUOHbm1v3Ex5uAT56pIQJtoT8ON4ZmFhi3TvR0=.ce86f07b-4136-4870-93f0-c9723c80795b@github.com>

> This change converts TraceDependencies to UL and removes the develop option. I think this provides further flexibility to add tags to only trace certain things in dependency analysis, as I did when trying to understand a PR for a deoptimization change.  For now, the messages are the same and the option is -Xlog:dependencies=debug.
> Tested with tier1-4

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix merge conflict.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13007/files
  - new: https://git.openjdk.org/jdk/pull/13007/files/8c0bc890..e5851202

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13007&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13007&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13007.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/13007/head:pull/13007

PR: https://git.openjdk.org/jdk/pull/13007

From rkennke at openjdk.org  Tue Mar 14 15:47:29 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 14 Mar 2023 15:47:29 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v25]
In-Reply-To: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
Message-ID: <_3eNnc8JNcoPdK8IZHTUGkSMqnERJmfab9ry323jVKI=.1faf478c-af7f-4d82-a35b-0252b2d068cc@github.com>

> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
> 
> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p
 rotocols.
> 
> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
> 
> 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
> 
> 
> Testing:
>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
> 
> ### Performance
> 
> #### Simple Microbenchmark
> 
> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
> 
> |  | x86_64 | aarch64 |
> | -- | -- | -- |
> | -UseFastLocking | 20.651 | 20.764 |
> | +UseFastLocking | 18.896 | 18.908 |
> 
> 
> #### Renaissance
> 
> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
> -- | -- | -- | -- | -- | -- | -- | --
> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  SA fixes related to latest changes in LockStack

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10907/files
  - new: https://git.openjdk.org/jdk/pull/10907/files/87b95bf7..2f572097

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=23-24

  Stats: 15 lines in 1 file changed: 4 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/10907.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10907/head:pull/10907

PR: https://git.openjdk.org/jdk/pull/10907

From stuefe at openjdk.org  Tue Mar 14 15:54:44 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 14 Mar 2023 15:54:44 GMT
Subject: RFR: JDK-8303861: Error handling step timeouts should never be
 blocked by OnError and others [v2]
In-Reply-To: <J-V1jdlY5xlDWYXaVG8-Nr-V_OLlXts-r_tKz8h6QQw=.dbe58f50-4a08-4165-ba32-fdd129163073@github.com>
References: <MsoamxpcF7RfrdiX5BXcHcluFN6HqcIZwwLedCUSQck=.8f187897-f3b4-46b8-9811-faba5d2e0b7b@github.com>
 <FVO8BPbYbbOlrFQhTESwAOM4TifV2UQeF2nk6A2NCx4=.de3bf2b9-59a9-4df8-af8a-7550451a85db@github.com>
 <J-V1jdlY5xlDWYXaVG8-Nr-V_OLlXts-r_tKz8h6QQw=.dbe58f50-4a08-4165-ba32-fdd129163073@github.com>
Message-ID: <3cSfYO5FRvkmAJHe-jC75wWtNoCVPMV9Lu85pYCsHUg=.9bbd6c43-3a2a-4f65-971f-6df64218d0a9@github.com>

On Fri, 10 Mar 2023 06:37:28 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   limit step timeout to 5 seconds max
>
> Changes seem fine. Thanks for the clear explanation.

okay this has been cooking long enough I think. Thanks @dholmes-ora and @rkennke !

-------------

PR: https://git.openjdk.org/jdk/pull/12936

From stuefe at openjdk.org  Tue Mar 14 15:54:46 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 14 Mar 2023 15:54:46 GMT
Subject: Integrated: JDK-8303861: Error handling step timeouts should never be
 blocked by OnError and others
In-Reply-To: <MsoamxpcF7RfrdiX5BXcHcluFN6HqcIZwwLedCUSQck=.8f187897-f3b4-46b8-9811-faba5d2e0b7b@github.com>
References: <MsoamxpcF7RfrdiX5BXcHcluFN6HqcIZwwLedCUSQck=.8f187897-f3b4-46b8-9811-faba5d2e0b7b@github.com>
Message-ID: <j865MUbGITCCDjHDK_IGxFk-tjlVHo9UwJjvry-4N7I=.1fb80e1a-e5de-4adb-b22d-7a095fe5ec99@github.com>

On Thu, 9 Mar 2023 06:12:02 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Fatal error handling is subject to several timeouts:
> - a global timeout (controlled via ErrorLogTimeout)
> - local error reporting step timeouts.
> 
> The latter aims to "give the JVM a kick" if it gets stuck in one particular place during error reporting. This prevents one error reporting step from hogging all the time allotted to error reporting under ErrorLogTimeout.
> 
> There are three situations where atm we suppress the global error timeout:
> - if the JVM is embedded and the launcher has its abort hook installed. Obviously, that must be allowed to run.
> - if the user specified one or more OnError commands to run, and these did not yet run. These must have a chance to run unmolested.
> - if the user (typically developer) specified ShowMessageBoxOnError, and the error box has not yet been shown
> 
> There is a bug though, that also prevents the step timeout from firing if either condition is true. That is plain wrong.
> 
> In addition to that, the test interval WatcherThread uses to check for timeouts should be decreased. It sits at 1 second, which is too coarse-grained. 
> 
> --------
> 
> Patch:
> - reworks `VMError::check_timeout()` to never block step timeouts
> - adds clarifying comments
> - quadruples timeout check frequency by watcher thread
> - adds regression test for timeout handling with OnError
> - additionally limits timeout per individual error reporting step to 5 seconds. 5 seconds is usually enough to distinguish a slow error reporting step from one that is endlessly hanging. 
> 
> Tested locally on Linux x64.

This pull request has now been integrated.

Changeset: a00f5d24
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a00f5d24d3824e3ab84208401a967efe0e7bf88e
Stats:     93 lines in 3 files changed: 57 ins; 1 del; 35 mod

8303861: Error handling step timeouts should never be blocked by OnError and others

Reviewed-by: dholmes, rkennke

-------------

PR: https://git.openjdk.org/jdk/pull/12936

From dnsimon at openjdk.org  Tue Mar 14 15:56:48 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 14 Mar 2023 15:56:48 GMT
Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v5]
In-Reply-To: <sjJAoXEkQVbslDwhdwvIRIKGstWxA-YgFlhE6wLCys8=.001438da-8f86-40d3-9011-86c4933b2184@github.com>
References: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>
 <gYzscs7Y8uz2l_5FIsqAuKebVsMnJpSwbIH6C_uzdv4=.f33d8432-c1fc-45a3-80f7-1159cdb87480@github.com>
 <sjJAoXEkQVbslDwhdwvIRIKGstWxA-YgFlhE6wLCys8=.001438da-8f86-40d3-9011-86c4933b2184@github.com>
Message-ID: <ZNuiw91ar-tB63YFh20T-8g3Yk0U6sG4f2rVuC4YQr4=.c4b7685b-802d-4628-a8e6-e127a614cd03@github.com>

On Tue, 14 Mar 2023 06:28:20 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> Doug Simon 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 remote-tracking branch 'openjdk-jdk/master' into JDK-8303431
>>  - switched to use of lists and maps instead of arrays
>>  - fixed whitespace
>>  - added support for inherited annotations
>>  - Merge branch 'master' into JDK-8303431
>>  - made AnnotationDataDecoder package-private
>>  - add annotation API to JVMCI
>
> src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 2699:
> 
>> 2697:   typeArrayOop ba = typeArrayOop(res);
>> 2698:   int ba_len = ba->length();
>> 2699:   if (ba_len <= 256) {
> 
> Is this really necessary?  Resource allocation is very cheap.

Ok, good point. I'll remove the optimization.

-------------

PR: https://git.openjdk.org/jdk/pull/12810

From dnsimon at openjdk.org  Tue Mar 14 16:06:06 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 14 Mar 2023 16:06:06 GMT
Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v6]
In-Reply-To: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>
References: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>
Message-ID: <0hYs21V1ZWB8o92CfvkEW3i0dZKkeW8kYGQu0p6xvtM=.e76da2cd-dbe5-4da2-a6cb-775f081b9a6a@github.com>

> This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for accessing annotations. The main differences from `java.lang.reflect.AnnotatedElement` are:
> * Each `Annotated` method explicitly specifies the annotation type(s) for which it wants annotation data. That is, there is no direct equivalent of `AnnotatedElement.getAnnotations()`.
> * Annotation data is returned in a map-like object (of type `jdk.vm.ci.meta.AnnotationData`) instead of in an `Annotation` object. This works better for libgraal as it avoids the need for annotation types to be loaded and included in libgraal.
>  
> To demonstrate the new API, here's an example in terms `java.lang.reflect.AnnotatedElement` (which `ResolvedJavaType` implements):
> 
>     ResolvedJavaMethod method = ...;
>     ExplodeLoop a = method.getAnnotation(ExplodeLoop.class);
>     return switch (a.kind()) {
>         case FULL_UNROLL -> LoopExplosionKind.FULL_UNROLL;
>         case FULL_UNROLL_UNTIL_RETURN -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>         ...
>     }
> 
> 
> The same code using the new API:
> 
> 
>     ResolvedJavaMethod method = ...;
>     ResolvedJavaType explodeLoopType = ...;
>     AnnotationData a = method.getAnnotationDataFor(explodeLoopType);
>     return switch (a.getEnum("kind").getName()) {
>         case "FULL_UNROLL" -> LoopExplosionKind.FULL_UNROLL;
>         case "FULL_UNROLL_UNTIL_RETURN" -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>         ...
>     }
> 
> 
> The implementation relies on new methods in `jdk.internal.vm.VMSupport` for parsing annotations and serializing/deserializing to/from a byte array. This allows the annotation data to be passed from the HotSpot heap to the libgraal heap.

Doug Simon has updated the pull request incrementally with one additional commit since the last revision:

  addressed review feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12810/files
  - new: https://git.openjdk.org/jdk/pull/12810/files/a85fa13a..abaf2375

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12810&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12810&range=04-05

  Stats: 10 lines in 2 files changed: 0 ins; 9 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12810.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12810/head:pull/12810

PR: https://git.openjdk.org/jdk/pull/12810

From gcao at openjdk.org  Tue Mar 14 16:18:21 2023
From: gcao at openjdk.org (Gui Cao)
Date: Tue, 14 Mar 2023 16:18:21 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v3]
In-Reply-To: <vR9DLx3Oi7S-M_8Qu-d0k6DfZTqfamB4AYt-JLeErvk=.0cf5358f-71fe-4956-8683-1ceae15de148@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <vR9DLx3Oi7S-M_8Qu-d0k6DfZTqfamB4AYt-JLeErvk=.0cf5358f-71fe-4956-8683-1ceae15de148@github.com>
Message-ID: <J7ctDDtx02TqbHuExxS0nnY_QHqfuBUKOoNiyh1_VyU=.0953088b-2d9d-4a2f-9c01-5fa4228bcf68@github.com>

On Tue, 14 Mar 2023 13:59:48 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
>> 
>> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
>> 
>> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
>> 
>> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
>> 
>> This change supports the following platforms: x86, aarch64, PPC, and RISCV
>
> Matias Saavedra Silva 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:
> 
>  - Typo in comment
>  - Merge branch 'master' into resolvedIndyEntry_8301995
>  - Interpreter optimization and comments
>  - PPC and RISCV port
>  - 8301995: Move invokedynamic resolution information out of the cpCache

Hi, 
I have updated the riscv related code by referring to the latest aarch64 related changes, please help me to update it.
https://github.com/zifeihan/jdk/commit/ca9f110ca4eb066f828442265f43ed0d9311a9cc
(on this branch: https://github.com/zifeihan/jdk/commits/follow_12778)

@RealFYang @DingliZhang Please help review the RISCV port code.

-------------

PR: https://git.openjdk.org/jdk/pull/12778

From stuefe at openjdk.org  Tue Mar 14 16:45:48 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 14 Mar 2023 16:45:48 GMT
Subject: RFR: 8302073: Specifying OnError handler prevents WatcherThread to
 break a deadlock in report_and_die()
In-Reply-To: <kFNbqSJr4ot5jWH0hZtYqgtmg_rqNH9H_9hZfUfB06c=.e6587a3e-b23e-401e-8cd3-76e80b46d9c5@github.com>
References: <nTD9cu_uj-X-ML_g-kbPrccPTlk5NGX9iV5TLXxOpbA=.2cea728c-6dbe-41a5-b379-a75c4ebc85e0@github.com>
 <kFNbqSJr4ot5jWH0hZtYqgtmg_rqNH9H_9hZfUfB06c=.e6587a3e-b23e-401e-8cd3-76e80b46d9c5@github.com>
Message-ID: <oi5KIlwMV9wNJjnag8zAq9fghL7z6VeysJvNe7YzavE=.f2d5fb80-3d12-4357-9d8f-946e0c070add@github.com>

On Wed, 8 Mar 2023 18:11:09 GMT, Alexey Pavlyutkin <duke at openjdk.org> wrote:

>> The patch fixes error reporting to check timeout in the case when a user specifies OnError hander. Before VMError:check_timeout() ignored timeout in this case, and so didn't break malloc() deadlock.
>> 
>> Verification (amd64/20.04LTS): the idea of the test is to crash JVM running with error hander of 3 successive `sleep` commands for 1s, 10s, and 60s with and without specified timeout
>> 
>> 
>> 16:52:17 at alex@alex-VirtualBox>( echo "
>> public class C {
>>   public static void main(String[] args) throws Throwable {
>>>     while (true) Thread.sleep(1000);
>>>   }
>>> }
>>> " >> C.java )
>> 16:57:35 at alex@alex-VirtualBox>./build/linux-x86_64-server-release/images/jdk/bin/java -XX:OnError='sleep 1;sleep 10;sleep 60' ./C.java &
>> [2] 179574
>> 17:00:19 at alex@alex-VirtualBox>kill -s SIGSEGV 179574
>> 17:00:27 at alex@alex-VirtualBox>#
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  SIGSEGV (0xb) at pc=0x00007f7b1701ecd5 (sent by kill), pid=179574, tid=179574
>> #
>> # JRE version: OpenJDK Runtime Environment (21.0) (build 21-internal-adhoc.alex.jdk)
>> # Java VM: OpenJDK 64-Bit Server VM (21-internal-adhoc.alex.jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
>> # Problematic frame:
>> # C  [libpthread.so.0+0x9cd5]  __pthread_clockjoin_ex+0x255
>> #
>> # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P %E" (or dumping to /home/alex/jdk/core.179574)
>> #
>> # An error report file with more information is saved as:
>> # /home/alex/jdk/hs_err_pid179574.log
>> #
>> # If you would like to submit a bug report, please visit:
>> #   https://bugreport.java.com/bugreport/crash.jsp
>> #
>> #
>> # -XX:OnError="sleep 1;sleep 10;sleep 60"
>> #   Executing /bin/sh -c "sleep 1" ...
>> #   Executing /bin/sh -c "sleep 10" ...
>> #   Executing /bin/sh -c "sleep 60" ...
>> 
>> [2]+  Aborted                 (core dumped) ./build/linux-x86_64-server-release/images/jdk/bin/java -XX:OnError='sleep 1;sleep 10;sleep 60' ./C.java
>> 17:02:03 at alex@alex-VirtualBox>./build/linux-x86_64-server-release/images/jdk/bin/java -XX:ErrorLogTimeout=5 -XX:OnError='sleep 1;sleep 10;sleep 60' ./C.java &
>> [2] 179602
>> 17:02:32 at alex@alex-VirtualBox>kill -s SIGSEGV 179602
>> 17:02:41 at alex@alex-VirtualBox>#
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  SIGSEGV (0xb) at pc=0x00007f9d71b18cd5 (sent by kill), pid=179602, tid=179602
>> #
>> # JRE version: OpenJDK Runtime Environment (21.0) (build 21-internal-adhoc.alex.jdk)
>> # Java VM: OpenJDK 64-Bit Server VM (21-internal-adhoc.alex.jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
>> # Problematic frame:
>> # C  [libpthread.so.0+0x9cd5]  __pthread_clockjoin_ex+0x255
>> #
>> # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P %E" (or dumping to /home/alex/jdk/core.179602)
>> #
>> # An error report file with more information is saved as:
>> # /home/alex/jdk/hs_err_pid179602.log
>> #
>> # If you would like to submit a bug report, please visit:
>> #   https://bugreport.java.com/bugreport/crash.jsp
>> #
>> #
>> # -XX:OnError="sleep 1;sleep 10;sleep 60"
>> #   Executing /bin/sh -c "sleep 1" ...
>> #   Executing /bin/sh -c "sleep 10" ...
>> 
>> ------ Timeout during error reporting after 11 s. ------
>> 
>> 17:02:54 at alex@alex-VirtualBox>
>> 
>> 
>> Regression (amd64/20.04LTS): `test/hotspot/jtreg/runtime/ErrorHandling` with different combinations of `-vmoption:-XX:ErrorLogTimeout=10` and `-vmoption:-XX:OnError='sleep 10'`
>
>> Thinking this through some more, I'm starting to doubt we do the right thing here. It is certainly convoluted: we _are_ the reporting thread here, so what happens is that:
>> 
>> * after fork_and_exec, we call check_timeout
>> * check_timeout will signal ourself
>> * we receive the signal
>> * we enter the secondary signal handler recursively
>> * we then re-enter VMError::report_and_die
>> * we then note that this is a timeout and print an error message and call os::die.
>> 
>> That is too complicated for my taste, and I don't know if there are any hidden issues with VM::check_timeout(). Since now, we call it from two threads, possibly, the reporting thread and the watcher thread. That function was not intended for concurrent usage.
>> 
>> And before thinking about the correct behavior, we need to clarify if the protection we grant an OnError invocation extends to the whole chain of error scripts. Right now we say OnError scripts should not be interrupted. Okay, but what about the next OnError script? If the user specifies several OnError scripts, should they all get a chance to run to finish?
>> 
>> Because denying the follow-up error scripts a chance to run feels weirdly arbitrary. Either those scripts are essential, or they aren't. If they are, all should run. If they are not, it should be okay to kill the JVM _while it is waiting for the child process to finish_ - this would make the patch simpler, and people argue that this would be the correct behavior anyway.
>> 
>> Personally, I think that killing the JVM while it is in waitpid waiting for the child is probably benign. Child would be reparented, possibly zombified on badly set up systems, but that's it. It would probably run to completion.
> 
> ok, let's replace check_timeout() with something like
> 
> jlong expiration = get_reporting_start_time() + ( jlong )ErrorLogTimeout * TIMESTAMP_TO_SECONDS_FACTOR;
> if ( get_current_timestamp() > expiration ) break;

@apavlyutkin @jsolomon8080 https://bugs.openjdk.org/browse/JDK-8303861 is in. Would be interesting to see if this already helps the customer.

-------------

PR: https://git.openjdk.org/jdk/pull/12925

From matsaave at openjdk.org  Tue Mar 14 17:04:48 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 14 Mar 2023 17:04:48 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v2]
In-Reply-To: <VQ34HqjCPRfc1b8v9BW1nm5V-qQaWN11vctJw3c10ck=.57c1c735-b453-42c2-a7c1-cc1049957af7@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <-Kj1YJ_nRa4nJtaxg3UR8uWhde6vIG1Jl-FFakGnHy4=.a41c6149-912b-4a66-8b1e-634bd27cdebb@github.com>
 <VQ34HqjCPRfc1b8v9BW1nm5V-qQaWN11vctJw3c10ck=.57c1c735-b453-42c2-a7c1-cc1049957af7@github.com>
Message-ID: <pkUIkI7pd0hiYzrop0bDcwdHCZrerzopRh0d7n3-Jpw=.3e18cbdc-6eae-4e30-8442-b3f0d10d5b80@github.com>

On Tue, 14 Mar 2023 09:20:54 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> @matias9927 can I ask you to merge master? There seem to be conflicts (at least I see a message "This branch has conflicts that must be resolved"). I'd like to give the change a spin in our CI testing. This requires that it can be applied on master.

I saw that merge error but nothing came up when I tried to merge locally. The branch is updated nonetheless, so you should be able to test it now @reinrich !

-------------

PR: https://git.openjdk.org/jdk/pull/12778

From jwaters at openjdk.org  Tue Mar 14 18:00:30 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 14 Mar 2023 18:00:30 GMT
Subject: RFR: 8301308: Remove version conditionalization for gcc/clang
 PRAGMA_DIAG_PUSH/POP
Message-ID: <9BP1enfxaU7HVyJEL27oCu9kMC45tWMkeUcqg1Xr6zE=.4a774982-1c1a-44ed-8862-2c300e79f458@github.com>

As of now we at minimum require clang 3.5 and gcc 6 to compile the Java Platform, the version checks for gcc/clang here are for whether clang is either version 4 and above, or has a minor version higher than 3.1, and for gcc either a major version higher than 4 or minor version above 4.6. Now these will always pass, so they can be removed. Also changes the macro definition location to match Visual C++ and look neater

-------------

Commit messages:
 - Remove version conditionalization for gcc/clang PRAGMA_DIAG_PUSH/POP

Changes: https://git.openjdk.org/jdk/pull/13025/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13025&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301308
  Stats: 13 lines in 1 file changed: 3 ins; 10 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13025.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/13025/head:pull/13025

PR: https://git.openjdk.org/jdk/pull/13025

From duke at openjdk.org  Tue Mar 14 18:01:57 2023
From: duke at openjdk.org (Alexey Pavlyutkin)
Date: Tue, 14 Mar 2023 18:01:57 GMT
Subject: RFR: 8302073: Specifying OnError handler prevents WatcherThread to
 break a deadlock in report_and_die()
In-Reply-To: <kFNbqSJr4ot5jWH0hZtYqgtmg_rqNH9H_9hZfUfB06c=.e6587a3e-b23e-401e-8cd3-76e80b46d9c5@github.com>
References: <nTD9cu_uj-X-ML_g-kbPrccPTlk5NGX9iV5TLXxOpbA=.2cea728c-6dbe-41a5-b379-a75c4ebc85e0@github.com>
 <kFNbqSJr4ot5jWH0hZtYqgtmg_rqNH9H_9hZfUfB06c=.e6587a3e-b23e-401e-8cd3-76e80b46d9c5@github.com>
Message-ID: <WItq61jXmFYZB9atgZ4IwN7WNh5-of2MQFyXg-0I-5Y=.24f996db-150e-42fb-9dbd-0914e98960aa@github.com>

On Wed, 8 Mar 2023 18:11:09 GMT, Alexey Pavlyutkin <duke at openjdk.org> wrote:

>> The patch fixes error reporting to check timeout in the case when a user specifies OnError hander. Before VMError:check_timeout() ignored timeout in this case, and so didn't break malloc() deadlock.
>> 
>> Verification (amd64/20.04LTS): the idea of the test is to crash JVM running with error hander of 3 successive `sleep` commands for 1s, 10s, and 60s with and without specified timeout
>> 
>> 
>> 16:52:17 at alex@alex-VirtualBox>( echo "
>> public class C {
>>   public static void main(String[] args) throws Throwable {
>>>     while (true) Thread.sleep(1000);
>>>   }
>>> }
>>> " >> C.java )
>> 16:57:35 at alex@alex-VirtualBox>./build/linux-x86_64-server-release/images/jdk/bin/java -XX:OnError='sleep 1;sleep 10;sleep 60' ./C.java &
>> [2] 179574
>> 17:00:19 at alex@alex-VirtualBox>kill -s SIGSEGV 179574
>> 17:00:27 at alex@alex-VirtualBox>#
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  SIGSEGV (0xb) at pc=0x00007f7b1701ecd5 (sent by kill), pid=179574, tid=179574
>> #
>> # JRE version: OpenJDK Runtime Environment (21.0) (build 21-internal-adhoc.alex.jdk)
>> # Java VM: OpenJDK 64-Bit Server VM (21-internal-adhoc.alex.jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
>> # Problematic frame:
>> # C  [libpthread.so.0+0x9cd5]  __pthread_clockjoin_ex+0x255
>> #
>> # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P %E" (or dumping to /home/alex/jdk/core.179574)
>> #
>> # An error report file with more information is saved as:
>> # /home/alex/jdk/hs_err_pid179574.log
>> #
>> # If you would like to submit a bug report, please visit:
>> #   https://bugreport.java.com/bugreport/crash.jsp
>> #
>> #
>> # -XX:OnError="sleep 1;sleep 10;sleep 60"
>> #   Executing /bin/sh -c "sleep 1" ...
>> #   Executing /bin/sh -c "sleep 10" ...
>> #   Executing /bin/sh -c "sleep 60" ...
>> 
>> [2]+  Aborted                 (core dumped) ./build/linux-x86_64-server-release/images/jdk/bin/java -XX:OnError='sleep 1;sleep 10;sleep 60' ./C.java
>> 17:02:03 at alex@alex-VirtualBox>./build/linux-x86_64-server-release/images/jdk/bin/java -XX:ErrorLogTimeout=5 -XX:OnError='sleep 1;sleep 10;sleep 60' ./C.java &
>> [2] 179602
>> 17:02:32 at alex@alex-VirtualBox>kill -s SIGSEGV 179602
>> 17:02:41 at alex@alex-VirtualBox>#
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  SIGSEGV (0xb) at pc=0x00007f9d71b18cd5 (sent by kill), pid=179602, tid=179602
>> #
>> # JRE version: OpenJDK Runtime Environment (21.0) (build 21-internal-adhoc.alex.jdk)
>> # Java VM: OpenJDK 64-Bit Server VM (21-internal-adhoc.alex.jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
>> # Problematic frame:
>> # C  [libpthread.so.0+0x9cd5]  __pthread_clockjoin_ex+0x255
>> #
>> # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P %E" (or dumping to /home/alex/jdk/core.179602)
>> #
>> # An error report file with more information is saved as:
>> # /home/alex/jdk/hs_err_pid179602.log
>> #
>> # If you would like to submit a bug report, please visit:
>> #   https://bugreport.java.com/bugreport/crash.jsp
>> #
>> #
>> # -XX:OnError="sleep 1;sleep 10;sleep 60"
>> #   Executing /bin/sh -c "sleep 1" ...
>> #   Executing /bin/sh -c "sleep 10" ...
>> 
>> ------ Timeout during error reporting after 11 s. ------
>> 
>> 17:02:54 at alex@alex-VirtualBox>
>> 
>> 
>> Regression (amd64/20.04LTS): `test/hotspot/jtreg/runtime/ErrorHandling` with different combinations of `-vmoption:-XX:ErrorLogTimeout=10` and `-vmoption:-XX:OnError='sleep 10'`
>
>> Thinking this through some more, I'm starting to doubt we do the right thing here. It is certainly convoluted: we _are_ the reporting thread here, so what happens is that:
>> 
>> * after fork_and_exec, we call check_timeout
>> * check_timeout will signal ourself
>> * we receive the signal
>> * we enter the secondary signal handler recursively
>> * we then re-enter VMError::report_and_die
>> * we then note that this is a timeout and print an error message and call os::die.
>> 
>> That is too complicated for my taste, and I don't know if there are any hidden issues with VM::check_timeout(). Since now, we call it from two threads, possibly, the reporting thread and the watcher thread. That function was not intended for concurrent usage.
>> 
>> And before thinking about the correct behavior, we need to clarify if the protection we grant an OnError invocation extends to the whole chain of error scripts. Right now we say OnError scripts should not be interrupted. Okay, but what about the next OnError script? If the user specifies several OnError scripts, should they all get a chance to run to finish?
>> 
>> Because denying the follow-up error scripts a chance to run feels weirdly arbitrary. Either those scripts are essential, or they aren't. If they are, all should run. If they are not, it should be okay to kill the JVM _while it is waiting for the child process to finish_ - this would make the patch simpler, and people argue that this would be the correct behavior anyway.
>> 
>> Personally, I think that killing the JVM while it is in waitpid waiting for the child is probably benign. Child would be reparented, possibly zombified on badly set up systems, but that's it. It would probably run to completion.
> 
> ok, let's replace check_timeout() with something like
> 
> jlong expiration = get_reporting_start_time() + ( jlong )ErrorLogTimeout * TIMESTAMP_TO_SECONDS_FACTOR;
> if ( get_current_timestamp() > expiration ) break;

> @apavlyutkin @jsolomon8080 https://bugs.openjdk.org/browse/JDK-8303861 is in. Would be interesting to see if this already helps the customer.

Sure, I'll try to backport the changes to zulu11. Thanks a lot

-------------

PR: https://git.openjdk.org/jdk/pull/12925

From vlivanov at openjdk.org  Tue Mar 14 18:08:46 2023
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 14 Mar 2023 18:08:46 GMT
Subject: RFR: 8304089: Convert TraceDependencies to UL [v3]
In-Reply-To: <BQzDwBUOHbm1v3Ex5uAT56pIQJtoT8ON4ZmFhi3TvR0=.ce86f07b-4136-4870-93f0-c9723c80795b@github.com>
References: <0aGc1NdAjpvksCWmXb1gZOPp9MV0n6xWvG8EaEp2ZLg=.b79cf218-9a23-420d-bec5-7509b7f8f1c1@github.com>
 <BQzDwBUOHbm1v3Ex5uAT56pIQJtoT8ON4ZmFhi3TvR0=.ce86f07b-4136-4870-93f0-c9723c80795b@github.com>
Message-ID: <mlOLRgK0QgZutusm2pjZ5pc9bWNFSs0Eacj7bUTFOO4=.b225e28c-da50-44e2-a877-812666de4c2f@github.com>

On Tue, 14 Mar 2023 15:40:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change converts TraceDependencies to UL and removes the develop option. I think this provides further flexibility to add tags to only trace certain things in dependency analysis, as I did when trying to understand a PR for a deoptimization change.  For now, the messages are the same and the option is -Xlog:dependencies=debug.
>> Tested with tier1-4
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix merge conflict.

Looks good.

-------------

Marked as reviewed by vlivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/13007

From chagedorn at openjdk.org  Tue Mar 14 18:18:37 2023
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 14 Mar 2023 18:18:37 GMT
Subject: RFR: 8302073: Specifying OnError handler prevents WatcherThread to
 break a deadlock in report_and_die()
In-Reply-To: <ENv94gS1Al_g-WlkPImshjot7HVPKvid7g7ft8gxQNk=.1e5aa0f3-6bfc-4f9a-8df3-7f2c7f094c20@github.com>
References: <nTD9cu_uj-X-ML_g-kbPrccPTlk5NGX9iV5TLXxOpbA=.2cea728c-6dbe-41a5-b379-a75c4ebc85e0@github.com>
 <k9wKuvOyzPUxNzE_aHGg_Abr5gckbriofiHDuMmhfps=.51b99d4a-8f1f-4134-8121-3738f2b13e41@github.com>
 <G-ReJaBrJTUBgWUmcE4eoqXQrtHCLPMSL7nQyom4QIM=.77438a77-60c9-4dc1-b811-7a71249d4358@github.com>
 <0jlQWouDE0tJ-ysn7WFYArqrJwHFQ-hhsZKKRGdVhmU=.95c4ceb0-9b8e-4c9b-9029-473626fb5a6b@github.com>
 <ENv94gS1Al_g-WlkPImshjot7HVPKvid7g7ft8gxQNk=.1e5aa0f3-6bfc-4f9a-8df3-7f2c7f094c20@github.com>
Message-ID: <rpWZDbFeVeiHDelrT7jAqzs_ngRx92GTGyGLsask2Vk=.bf26d4e4-73e8-4b14-8cd9-d44f40c4790e@github.com>

On Tue, 14 Mar 2023 09:04:51 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> @dholmes-ora My proposal would be to be pragmatic and continue the discussion here. This has been going on too long. Switching channels again would be more confusing. 
>> 
>> I would prefer JBS or ML discussion as well, but not everyone (eg. @jsolomon8080) has write access to JBS.
>> 
>> ----
>> 
>> I thought this over some more.
>> 
>> A big part of this problem is a plain bug in VMError::check_timeout(): it should never block *step timeouts*. We added step timeouts back in 2016 to deal with these kinds of problems: if the JVM hangs in error reporting, give it a kick to get it going again. Do so repeatedly. This is related to the global timeout, but works also independently from it (and therefore from the question of when to honor the global timeout).
>> 
>> I opened https://bugs.openjdk.org/browse/JDK-8303861 to deal with this, see PR: https://github.com/openjdk/jdk/pull/12936
>> 
>> This may already be a big help for cases like these. In fact, it may already be enough, and we could maybe close this issue.
>> 
>> However, if we have a recursive malloc situation, we may hang repeatedly. JVM will kick itself alive every time (with my patch) but this is still annoying. The root problem here is that we should not use malloc during error handling. Cannot always be avoided, but at least we should minimize malloc use. 
>> 
>> Decoder, in particular, should not use malloc. Therefore I also opened https://bugs.openjdk.org/browse/JDK-8303862 to track that. I won't have time to work on that. I have the hope that maybe @chhagedorn can :-) ? Otherwise Azul may also chip in some bug fixing.
>> 
>> ----
>> 
>> All these are unrelated to the question of whether OnError should be blocked or not. I realize now that if we decide to (continue to) protect OnError from timeouts, we must never act on the global timeout until all OnError steps ran. Since these run right before VM exit, the original implementation that just blocked the global timeout altogether was actually right.
>> 
>> So, there's that. Maybe JDK-8303861 is already enough for cases like this. At least JDK-8303861 does not introduce any backward compatibility issues.
>
>> Decoder, in particular, should not use malloc. Therefore I also opened https://bugs.openjdk.org/browse/JDK-8303862 to track that. I won't have time to work on that. I have the hope that maybe @chhagedorn can :-) ?
> 
> Does any of our current allocation strategies allow the usage of a custom scratch buffer (i.e. the error reporting scratch buffer) as memory location? If not, it could get more complicated. I could still try to tackle that but I'm not sure if I have the necessary knowledge in that area.

> > > Decoder, in particular, should not use malloc. Therefore I also opened https://bugs.openjdk.org/browse/JDK-8303862 to track that. I won't have time to work on that. I have the hope that maybe @chhagedorn can :-) ?
> > 
> > 
> > Does any of our current allocation strategies allow the usage of a custom scratch buffer (i.e. the error reporting scratch buffer) as memory location? If not, it could get more complicated. I could still try to tackle that but I'm not sure if I have the necessary knowledge in that area.
> 
> What we usually do for these kind of problems is to pass the scratch buffer via argument to the processing functions. And make that use either it or, if NULL was passes, allocate its own thing.
> 
> Another way to do this would be to add a scratch buffer pointer to Thread.
> 
> A third way to do this (I had been experimenting with it) would be to pre-allocate a scratch buffer, and once error handling began, to use that inside os::malloc. That is the most involved solution, though, and I'm not particularly fond of it. I know many reviewers would hate it, too :-)

Thanks for the summary. Could we also use "placement new" to use the scratch buffer to allocate and create objects to? For example, when creating a decoder, to use something like

decoder = new(scratch_buffer) ElfDecoder();

here:
https://github.com/openjdk/jdk/blob/4e631fa43fd821846c12ae2177360c44cf770766/src/hotspot/share/utilities/decoder.cpp#L62-L70
Then we can still utilize polymorphism. But then `AbstractDecoder` needs to be something else than `CHeapObj`. And of course, this approach also needs careful checking that a new object actually fits into the provided scratch buffer. On top of that, it gets more complicated when we want to keep multiple objects alive in the same scratch buffer. So, I'm not sure if this approach is feasible, though.

-------------

PR: https://git.openjdk.org/jdk/pull/12925

From dcubed at openjdk.org  Tue Mar 14 18:22:28 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 14 Mar 2023 18:22:28 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v25]
In-Reply-To: <_3eNnc8JNcoPdK8IZHTUGkSMqnERJmfab9ry323jVKI=.1faf478c-af7f-4d82-a35b-0252b2d068cc@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_3eNnc8JNcoPdK8IZHTUGkSMqnERJmfab9ry323jVKI=.1faf478c-af7f-4d82-a35b-0252b2d068cc@github.com>
Message-ID: <Yj6IOf8RY4q-xiyuH-FuqfV23o3Hm5W8Egu1CEeDaUM=.fa646aae-fc2c-4632-a715-85d8fca5094e@github.com>

On Tue, 14 Mar 2023 15:47:29 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   SA fixes related to latest changes in LockStack

I kicked off a round of Mach5 Tier1 testing last night. I got 133 SA test failures
that are probably fixed by v24. runtime/logging/MonitorInflationTest.java also
failed on all 5 configs tested in Tier1:


java.lang.RuntimeException: 'inflate(has_locker):' missing from stdout/stderr
	at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:221)
	at MonitorInflationTest.analyzeOutputOn(MonitorInflationTest.java:41)
	at MonitorInflationTest.main(MonitorInflationTest.java:56)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
	at java.base/java.lang.Thread.run(Thread.java:1623)


I suspect that the failing condition is one that I added to the test a long time ago
so I'll be taking a look.

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From rkennke at openjdk.org  Tue Mar 14 18:22:30 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 14 Mar 2023 18:22:30 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v25]
In-Reply-To: <Yj6IOf8RY4q-xiyuH-FuqfV23o3Hm5W8Egu1CEeDaUM=.fa646aae-fc2c-4632-a715-85d8fca5094e@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_3eNnc8JNcoPdK8IZHTUGkSMqnERJmfab9ry323jVKI=.1faf478c-af7f-4d82-a35b-0252b2d068cc@github.com>
 <Yj6IOf8RY4q-xiyuH-FuqfV23o3Hm5W8Egu1CEeDaUM=.fa646aae-fc2c-4632-a715-85d8fca5094e@github.com>
Message-ID: <SkQKoHkZrGOtndBud4p2O8dpTA0SEHwgvb8HCEBR7k0=.bd24b021-2744-4647-b26c-41b733b7dff1@github.com>

On Tue, 14 Mar 2023 18:16:36 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> I kicked off a round of Mach5 Tier1 testing last night. I got 133 SA test failures that are probably fixed by v24. runtime/logging/MonitorInflationTest.java also failed on all 5 configs tested in Tier1:
> 
> ```
> java.lang.RuntimeException: 'inflate(has_locker):' missing from stdout/stderr
> 	at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:221)
> 	at MonitorInflationTest.analyzeOutputOn(MonitorInflationTest.java:41)
> 	at MonitorInflationTest.main(MonitorInflationTest.java:56)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
> 	at java.base/java.lang.Thread.run(Thread.java:1623)
> ```
> 
> I suspect that the failing condition is one that I added to the test a long time ago so I'll be taking a look.

Aww, that is bad timing. I pushed a change yesterday that broke SA, and I only pushed a fix 2 hours ago. It should be good now, in case you want to try it again.

Thank you for your effort to review and test this change!

Roman

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From dcubed at openjdk.org  Tue Mar 14 18:44:56 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 14 Mar 2023 18:44:56 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v25]
In-Reply-To: <_3eNnc8JNcoPdK8IZHTUGkSMqnERJmfab9ry323jVKI=.1faf478c-af7f-4d82-a35b-0252b2d068cc@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_3eNnc8JNcoPdK8IZHTUGkSMqnERJmfab9ry323jVKI=.1faf478c-af7f-4d82-a35b-0252b2d068cc@github.com>
Message-ID: <UCm8xY8WPnV8Hb6B-dY64ReoP-lLx2A4O4J4n5HjLhY=.990423c0-19fc-44d2-91b2-bfe20006b5a4@github.com>

On Tue, 14 Mar 2023 15:47:29 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   SA fixes related to latest changes in LockStack

I've reviewed the changes in v23 and v24. Trying another
Mach5 Tier1 job set.

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From rkennke at openjdk.org  Tue Mar 14 18:52:39 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 14 Mar 2023 18:52:39 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v26]
In-Reply-To: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
Message-ID: <kmN_C8IN6Tj01P86gjrctndLD7Wrxw8m51f4msPK-Ak=.eccc9b74-4c3b-49ab-bded-d39aa4d15518@github.com>

> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
> 
> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p
 rotocols.
> 
> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
> 
> 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
> 
> 
> Testing:
>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
> 
> ### Performance
> 
> #### Simple Microbenchmark
> 
> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
> 
> |  | x86_64 | aarch64 |
> | -- | -- | -- |
> | -UseFastLocking | 20.651 | 20.764 |
> | +UseFastLocking | 18.896 | 18.908 |
> 
> 
> #### Renaissance
> 
> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
> -- | -- | -- | -- | -- | -- | -- | --
> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Change log message when inflating fast-locked object

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10907/files
  - new: https://git.openjdk.org/jdk/pull/10907/files/2f572097..b834f0ca

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=24-25

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10907.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10907/head:pull/10907

PR: https://git.openjdk.org/jdk/pull/10907

From rkennke at openjdk.org  Tue Mar 14 18:52:42 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 14 Mar 2023 18:52:42 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v25]
In-Reply-To: <UCm8xY8WPnV8Hb6B-dY64ReoP-lLx2A4O4J4n5HjLhY=.990423c0-19fc-44d2-91b2-bfe20006b5a4@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_3eNnc8JNcoPdK8IZHTUGkSMqnERJmfab9ry323jVKI=.1faf478c-af7f-4d82-a35b-0252b2d068cc@github.com>
 <UCm8xY8WPnV8Hb6B-dY64ReoP-lLx2A4O4J4n5HjLhY=.990423c0-19fc-44d2-91b2-bfe20006b5a4@github.com>
Message-ID: <nqMDUKWpahko_el6kbagZCwW_omLUbUmqa7CHPThKI4=.b32b4cf5-14bf-4e26-b0bb-47daee24b81e@github.com>

On Tue, 14 Mar 2023 18:41:59 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> I've reviewed the changes in v23 and v24. Trying another Mach5 Tier1 job set.

I just now pushed a simple change that changes the log message 'inflate(fast-locked)' to 'inflate(has_locker)' to make those tests happy.

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From dcubed at openjdk.org  Tue Mar 14 18:52:45 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 14 Mar 2023 18:52:45 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v25]
In-Reply-To: <_3eNnc8JNcoPdK8IZHTUGkSMqnERJmfab9ry323jVKI=.1faf478c-af7f-4d82-a35b-0252b2d068cc@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_3eNnc8JNcoPdK8IZHTUGkSMqnERJmfab9ry323jVKI=.1faf478c-af7f-4d82-a35b-0252b2d068cc@github.com>
Message-ID: <liwYrPR-QVtGDaPRVAqzyN7s3H3pFxqtE5qnQac8fc4=.9a60347e-1d78-4482-a063-946cd76309fa@github.com>

On Tue, 14 Mar 2023 15:47:29 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   SA fixes related to latest changes in LockStack

And it looks like you just pushed a fix for: runtime/logging/MonitorInflationTest.java.
I killed my Mach5 Tier1 and I'll resync again...

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From kbarrett at openjdk.org  Tue Mar 14 18:55:36 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 14 Mar 2023 18:55:36 GMT
Subject: RFR: 8301308: Remove version conditionalization for gcc/clang
 PRAGMA_DIAG_PUSH/POP
In-Reply-To: <9BP1enfxaU7HVyJEL27oCu9kMC45tWMkeUcqg1Xr6zE=.4a774982-1c1a-44ed-8862-2c300e79f458@github.com>
References: <9BP1enfxaU7HVyJEL27oCu9kMC45tWMkeUcqg1Xr6zE=.4a774982-1c1a-44ed-8862-2c300e79f458@github.com>
Message-ID: <o5ugQgLquEmEi4kicuB-SpGjXR6Hf2mOmtwbzEsSEWA=.03d0ceb1-10b0-4397-892a-064349d0314c@github.com>

On Tue, 14 Mar 2023 17:51:12 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> As of now we at minimum require clang 3.5 and gcc 6 to compile the Java Platform, the version checks for gcc/clang here are for whether clang is either version 4 and above, or has a minor version higher than 3.1, and for gcc either a major version higher than 4 or minor version above 4.6. Now these will always pass, so they can be removed. Also changes the macro definition location to match Visual C++ and look neater

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.org/jdk/pull/13025

From coleenp at openjdk.org  Tue Mar 14 19:34:55 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 14 Mar 2023 19:34:55 GMT
Subject: RFR: 8304089: Convert TraceDependencies to UL [v3]
In-Reply-To: <BQzDwBUOHbm1v3Ex5uAT56pIQJtoT8ON4ZmFhi3TvR0=.ce86f07b-4136-4870-93f0-c9723c80795b@github.com>
References: <0aGc1NdAjpvksCWmXb1gZOPp9MV0n6xWvG8EaEp2ZLg=.b79cf218-9a23-420d-bec5-7509b7f8f1c1@github.com>
 <BQzDwBUOHbm1v3Ex5uAT56pIQJtoT8ON4ZmFhi3TvR0=.ce86f07b-4136-4870-93f0-c9723c80795b@github.com>
Message-ID: <73p3Jef69fNhq6evZtlnN7a-Aoy0hxJzXDpMBIzsz0c=.1f599ec1-577c-4dbe-926c-03b61bc71138@github.com>

On Tue, 14 Mar 2023 15:40:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change converts TraceDependencies to UL and removes the develop option. I think this provides further flexibility to add tags to only trace certain things in dependency analysis, as I did when trying to understand a PR for a deoptimization change.  For now, the messages are the same and the option is -Xlog:dependencies=debug.
>> Tested with tier1-4
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix merge conflict.

Thank you Vladimir.

-------------

PR: https://git.openjdk.org/jdk/pull/13007

From dnsimon at openjdk.org  Tue Mar 14 19:49:48 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 14 Mar 2023 19:49:48 GMT
Subject: RFR: 8292818: replace 96-bit representation for field metadata
 with variable-sized streams [v4]
In-Reply-To: <WkhAOfNqsAbDlIOsGSC-mrSj2uhBc3IBIQKBbrQjMpw=.066f182d-4ff2-445b-bee7-39c8f2dc8ba2@github.com>
References: <vdiacOO3JUyy4sWGkDXNBMUT7cG3XYe79mOvYru9uMM=.9c556675-7ffd-4c09-a428-6d64dffef209@github.com>
 <hAGW4he3pjU6G9IuyygughaiDUL9vKNHzKcURWD4tSI=.b67e5661-9978-4d9d-850e-0a6399de5a64@github.com>
 <5apLgAhjSwiK-sv6Xrl9yZctZTAe_GahWGyk8rUYgvk=.1af11917-7547-48ba-b958-01c6ef6f9f18@github.com>
 <WkhAOfNqsAbDlIOsGSC-mrSj2uhBc3IBIQKBbrQjMpw=.066f182d-4ff2-445b-bee7-39c8f2dc8ba2@github.com>
Message-ID: <Vioh1PQrzhgPNvS9Yy_t3f012EdDHSQ9h4YvNpFLpeA=.eb963111-d800-42de-a67b-fdfe86242b19@github.com>

On Tue, 14 Mar 2023 13:37:23 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> src/hotspot/share/jvmci/jvmciEnv.hpp line 149:
>> 
>>> 147: };
>>> 148: 
>>> 149: extern JNIEXPORT jobjectArray c2v_getDeclaredFieldsInfo(JNIEnv* env, jobject, jobject, jlong);
>> 
>> What's the purpose of this declaration? I don't think you need it or the `friend` declaration below since `new_FieldInfo(FieldInfo* fieldinfo, JVMCI_TRAPS)` is public.
>
> Without this declaration, builds fail on Windows with this error:
> `error C2375: 'c2v_getDeclaredFieldsInfo': redefinition; different linkage`

Strange - thats not needed for other `JVMCIEnv` methods called from `jvmciCompilerToVM.cpp`. There must be some way to avoid this.

-------------

PR: https://git.openjdk.org/jdk/pull/12855

From fparain at openjdk.org  Tue Mar 14 19:49:49 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 14 Mar 2023 19:49:49 GMT
Subject: RFR: 8292818: replace 96-bit representation for field metadata
 with variable-sized streams [v4]
In-Reply-To: <Vioh1PQrzhgPNvS9Yy_t3f012EdDHSQ9h4YvNpFLpeA=.eb963111-d800-42de-a67b-fdfe86242b19@github.com>
References: <vdiacOO3JUyy4sWGkDXNBMUT7cG3XYe79mOvYru9uMM=.9c556675-7ffd-4c09-a428-6d64dffef209@github.com>
 <hAGW4he3pjU6G9IuyygughaiDUL9vKNHzKcURWD4tSI=.b67e5661-9978-4d9d-850e-0a6399de5a64@github.com>
 <5apLgAhjSwiK-sv6Xrl9yZctZTAe_GahWGyk8rUYgvk=.1af11917-7547-48ba-b958-01c6ef6f9f18@github.com>
 <WkhAOfNqsAbDlIOsGSC-mrSj2uhBc3IBIQKBbrQjMpw=.066f182d-4ff2-445b-bee7-39c8f2dc8ba2@github.com>
 <Vioh1PQrzhgPNvS9Yy_t3f012EdDHSQ9h4YvNpFLpeA=.eb963111-d800-42de-a67b-fdfe86242b19@github.com>
Message-ID: <0SZEwskweBz1Ri6krqHq9rGWvmwiQ9fkgfRcUEKtTuo=.67dbf4d3-4432-4187-a39d-f16ef76cc2ce@github.com>

On Tue, 14 Mar 2023 15:11:36 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Without this declaration, builds fail on Windows with this error:
>> `error C2375: 'c2v_getDeclaredFieldsInfo': redefinition; different linkage`
>
> Strange - thats not needed for other `JVMCIEnv` methods called from `jvmciCompilerToVM.cpp`. There must be some way to avoid this.

The issue was caused by the `friend` declaration below (I cannot remember why I added in the first place), which seems to add an implicit declaration of the method that was conflicting with the original declaration of the method. Once the `friend` declaration is removed, builds on Windows don't need the `extern` declaration anymore.

-------------

PR: https://git.openjdk.org/jdk/pull/12855

From matsaave at openjdk.org  Tue Mar 14 20:20:41 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 14 Mar 2023 20:20:41 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v4]
In-Reply-To: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
Message-ID: <NAlT40fGcwSR_s4NrUvvFgwZC4JnCrISl2K5uoFt7YQ=.20613218-a79b-4b64-83ba-ea22b54f8d6e@github.com>

> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
> 
> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
> 
> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
> 
> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
> 
> This change supports the following platforms: x86, aarch64, PPC, and RISCV

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  RISCV port update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12778/files
  - new: https://git.openjdk.org/jdk/pull/12778/files/a3e7ca02..db892223

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12778&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12778&range=02-03

  Stats: 23 lines in 2 files changed: 5 ins; 12 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/12778.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12778/head:pull/12778

PR: https://git.openjdk.org/jdk/pull/12778

From fparain at openjdk.org  Tue Mar 14 20:32:53 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 14 Mar 2023 20:32:53 GMT
Subject: RFR: 8292818: replace 96-bit representation for field metadata
 with variable-sized streams [v4]
In-Reply-To: <23n-dTVRiGuVl7imPvKph7q43FuB1k7Hak6-mGNDKeM=.40ca325c-e53f-4950-bece-99b7e4f4d367@github.com>
References: <vdiacOO3JUyy4sWGkDXNBMUT7cG3XYe79mOvYru9uMM=.9c556675-7ffd-4c09-a428-6d64dffef209@github.com>
 <hAGW4he3pjU6G9IuyygughaiDUL9vKNHzKcURWD4tSI=.b67e5661-9978-4d9d-850e-0a6399de5a64@github.com>
 <5apLgAhjSwiK-sv6Xrl9yZctZTAe_GahWGyk8rUYgvk=.1af11917-7547-48ba-b958-01c6ef6f9f18@github.com>
 <PiqbuEn7pifvUms-qjhA9u0VhFRRTw3WVfQvBd1WJfQ=.e5fd2aa4-88b3-4d9b-a6f2-47ec465ab479@github.com>
 <23n-dTVRiGuVl7imPvKph7q43FuB1k7Hak6-mGNDKeM=.40ca325c-e53f-4950-bece-99b7e4f4d367@github.com>
Message-ID: <gCFLpvB-OElevxMBqD4OBB6cQSfh4QiSZiw4SMKj40Q=.26fa0be8-e629-4b3c-86db-8d733b4a8411@github.com>

On Tue, 14 Mar 2023 15:10:04 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Access to internal modifiers is needed in `HotSpotResolvedJavaFieldTest.testEquivalenceForInternalFields()`. I moved the declaration of the method to `HotSpotResolvedJavaField`. Does this change work for you?
>
> Just use reflection to read the internal flags (like this test already does for the `index` field).
> 
> I've attached [review.patch](https://github.com/openjdk/jdk/files/10970245/review.patch) with this change and a few other changes I think should be made for better naming (plus one test cleanup).

Thank you for the patch, it will be included in the next commit.

-------------

PR: https://git.openjdk.org/jdk/pull/12855

From mdoerr at openjdk.org  Tue Mar 14 20:33:34 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 14 Mar 2023 20:33:34 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v15]
In-Reply-To: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
Message-ID: <cWBS522xry4Ov79KZGHlNtGj-tv6rNkhtuMh5wZoKC8=.18139685-252f-4a71-aba1-18958d6880f5@github.com>

> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
> 
> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
> 
> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
> 
> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Will get addressed separately: [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
> 
> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
> 
> I had to make changes to shared code and code for other platforms:
> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit.

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  Allow TestHFA to run on musl. Add Upcalls.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12708/files
  - new: https://git.openjdk.org/jdk/pull/12708/files/2e4e269e..364a84ed

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=13-14

  Stats: 208 lines in 2 files changed: 204 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12708.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12708/head:pull/12708

PR: https://git.openjdk.org/jdk/pull/12708

From mdoerr at openjdk.org  Tue Mar 14 20:33:40 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 14 Mar 2023 20:33:40 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v14]
In-Reply-To: <nsHLsGIVjZkm2Mu_JiTSVC3XBb7mWG342rao7moO7kY=.2ccd9fa3-fe88-4583-9219-52fdf38a49e4@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <IwJ-UTPgCC3n5uLzRADxzt1Q8rIIcHwXetuG4hhhqMc=.a6835dde-3c2f-4cc8-bdaf-25507334066b@github.com>
 <nsHLsGIVjZkm2Mu_JiTSVC3XBb7mWG342rao7moO7kY=.2ccd9fa3-fe88-4583-9219-52fdf38a49e4@github.com>
Message-ID: <LIltOuDe8zhtq7sbJP93OPqlKJ1Sk7hq5sLg2L_NsF8=.ed65a5ae-0ea6-46c3-8dcf-2ca6b460085c@github.com>

On Mon, 13 Mar 2023 14:31:19 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Introduce ABIv2CallArranger for linux ppc64le.
>
> test/jdk/java/foreign/TestHFA.java line 32:
> 
>> 30:  * @enablePreview
>> 31:  * @requires ((os.arch == "amd64" | os.arch == "x86_64") & sun.arch.data.model == "64") | os.arch == "aarch64" | os.arch == "ppc64le" | os.arch == "riscv64"
>> 32:  * @requires !vm.musl
> 
> Not sure if this test should be disabled on musl?

Changed with https://github.com/openjdk/jdk/pull/12708/commits/364a84edc416abd5f1318f78057c92720fe96990. Plus added Upcalls.

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From mdoerr at openjdk.org  Tue Mar 14 22:30:22 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 14 Mar 2023 22:30:22 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v16]
In-Reply-To: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
Message-ID: <c5UYe1zFGgndb5SQZ71TgGXsizWiNnhiosHWm5xiVpU=.032bb845-05ad-4393-83cd-2a111dc55c85@github.com>

> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
> 
> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
> 
> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
> 
> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Will get addressed separately: [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
> 
> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
> 
> I had to make changes to shared code and code for other platforms:
> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit.

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  Fix storing 32 bit integers into Java frames. Enable TestArrayStructs.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12708/files
  - new: https://git.openjdk.org/jdk/pull/12708/files/364a84ed..9173af20

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=14-15

  Stats: 14 lines in 2 files changed: 5 ins; 3 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/12708.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12708/head:pull/12708

PR: https://git.openjdk.org/jdk/pull/12708

From duke at openjdk.org  Tue Mar 14 22:33:52 2023
From: duke at openjdk.org (jsolomon8080)
Date: Tue, 14 Mar 2023 22:33:52 GMT
Subject: RFR: 8302073: Specifying OnError handler prevents WatcherThread to
 break a deadlock in report_and_die()
In-Reply-To: <WItq61jXmFYZB9atgZ4IwN7WNh5-of2MQFyXg-0I-5Y=.24f996db-150e-42fb-9dbd-0914e98960aa@github.com>
References: <nTD9cu_uj-X-ML_g-kbPrccPTlk5NGX9iV5TLXxOpbA=.2cea728c-6dbe-41a5-b379-a75c4ebc85e0@github.com>
 <kFNbqSJr4ot5jWH0hZtYqgtmg_rqNH9H_9hZfUfB06c=.e6587a3e-b23e-401e-8cd3-76e80b46d9c5@github.com>
 <WItq61jXmFYZB9atgZ4IwN7WNh5-of2MQFyXg-0I-5Y=.24f996db-150e-42fb-9dbd-0914e98960aa@github.com>
Message-ID: <bxZmuoqLDgy8TsOmwejR1_l8vfd-sKIPeTsJcTUAGms=.9b0c50e5-2608-4c8c-99f0-6bb860b82ce0@github.com>

On Tue, 14 Mar 2023 17:58:28 GMT, Alexey Pavlyutkin <duke at openjdk.org> wrote:

> > @apavlyutkin @jsolomon8080 https://bugs.openjdk.org/browse/JDK-8303861 is in. Would be interesting to see if this already helps the customer.
> 
> Sure, I'll try to backport the changes to zulu11. Thanks a lot

I look forward to receiving a version of zulu11 with this change and testing it out!

-------------

PR: https://git.openjdk.org/jdk/pull/12925

From mdoerr at openjdk.org  Tue Mar 14 22:34:47 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 14 Mar 2023 22:34:47 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v16]
In-Reply-To: <c5UYe1zFGgndb5SQZ71TgGXsizWiNnhiosHWm5xiVpU=.032bb845-05ad-4393-83cd-2a111dc55c85@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <c5UYe1zFGgndb5SQZ71TgGXsizWiNnhiosHWm5xiVpU=.032bb845-05ad-4393-83cd-2a111dc55c85@github.com>
Message-ID: <HsLw9z_ayNXwZhAVnf8xLKnotdHu4cCITQeXTfD_8cM=.411e76c4-5b76-4407-beb1-e10349c1cba1@github.com>

On Tue, 14 Mar 2023 22:30:22 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
>> 
>> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
>> 
>> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
>> 
>> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Will get addressed separately: [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
>> 
>> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
>> 
>> I had to make changes to shared code and code for other platforms:
>> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
>> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
>> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
>> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
>> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix storing 32 bit integers into Java frames. Enable TestArrayStructs.

Thanks for the hint. Using `jshell` is a good idea.

{
  callerMethodType: (long,int,int,int,int,int,int,int,int)long  calleeMethodType: (MemorySegment,byte,byte,byte,byte,byte,byte,byte,byte)MemorySegment  FunctionDescriptor: ([[8:b8]]b8b8b8b8b8b8b8b8)[[8:b8]]  Argument Bindings:
    0: [Allocate[size=8, alignment=1], Dup[], VMLoad[storage=VMStorage[type=0, segmentMaskOrSize=3, indexOrOffset=3, debugName=r3], type=long], BufferStore[offset=0, type=long, byteWidth=8]]
    1: [VMLoad[storage=VMStorage[type=0, segmentMaskOrSize=3, indexOrOffset=4, debugName=r4], type=int], INT_TO_BYTE]
    2: [VMLoad[storage=VMStorage[type=0, segmentMaskOrSize=3, indexOrOffset=5, debugName=r5], type=int], INT_TO_BYTE]
    3: [VMLoad[storage=VMStorage[type=0, segmentMaskOrSize=3, indexOrOffset=6, debugName=r6], type=int], INT_TO_BYTE]
    4: [VMLoad[storage=VMStorage[type=0, segmentMaskOrSize=3, indexOrOffset=7, debugName=r7], type=int], INT_TO_BYTE]
    5: [VMLoad[storage=VMStorage[type=0, segmentMaskOrSize=3, indexOrOffset=8, debugName=r8], type=int], INT_TO_BYTE]
    6: [VMLoad[storage=VMStorage[type=0, segmentMaskOrSize=3, indexOrOffset=9, debugName=r9], type=int], INT_TO_BYTE]
    7: [VMLoad[storage=VMStorage[type=0, segmentMaskOrSize=3, indexOrOffset=10, debugName=r10], type=int], INT_TO_BYTE]
    8: [VMLoad[storage=VMStorage[type=2, segmentMaskOrSize=8, indexOrOffset=64, debugName=Stack at 64], type=int], INT_TO_BYTE]
    Return: [BufferLoad[offset=0, type=long, byteWidth=8], VMStore[storage=VMStorage[type=0, segmentMaskOrSize=3, indexOrOffset=3, debugName=r3], type=long]]
}

I have fixed the issue and enabled the test. My code still contained an old assumption which doesn't hold for the cases I had implemented more recently. So, this PR is probably complete. I'll rerun tests and wait for 2 reviews.

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From mdoerr at openjdk.org  Tue Mar 14 22:55:51 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 14 Mar 2023 22:55:51 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v16]
In-Reply-To: <c5UYe1zFGgndb5SQZ71TgGXsizWiNnhiosHWm5xiVpU=.032bb845-05ad-4393-83cd-2a111dc55c85@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <c5UYe1zFGgndb5SQZ71TgGXsizWiNnhiosHWm5xiVpU=.032bb845-05ad-4393-83cd-2a111dc55c85@github.com>
Message-ID: <CqQTng1GkfdB1wANeu6Sj3NSnOrv_T3yCz72OIHWPAY=.0191a653-287e-4753-8270-fcb3f6e7d13b@github.com>

On Tue, 14 Mar 2023 22:30:22 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
>> 
>> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
>> 
>> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
>> 
>> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Will get addressed separately: [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
>> 
>> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
>> 
>> I had to make changes to shared code and code for other platforms:
>> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
>> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
>> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
>> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
>> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix storing 32 bit integers into Java frames. Enable TestArrayStructs.

Btw. the new cases in which we use int and short accesses when byteWidth is not a power of 2 are never unaligned AFAICS. I guess _UNALIGNED is unnecessary in the JAVA_INT_UNALIGNED and JAVA_SHORT_UNALIGNED. They are always aligned wrt. to their size.

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From ccheung at openjdk.org  Tue Mar 14 23:37:46 2023
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 14 Mar 2023 23:37:46 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v4]
In-Reply-To: <NAlT40fGcwSR_s4NrUvvFgwZC4JnCrISl2K5uoFt7YQ=.20613218-a79b-4b64-83ba-ea22b54f8d6e@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <NAlT40fGcwSR_s4NrUvvFgwZC4JnCrISl2K5uoFt7YQ=.20613218-a79b-4b64-83ba-ea22b54f8d6e@github.com>
Message-ID: <uEs7S3I5zuveQ-eXk6Lr4ik6h51i_UxSfonDyj_x0Rg=.b1a01133-dc85-444a-a3d7-33788689542c@github.com>

On Tue, 14 Mar 2023 20:20:41 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
>> 
>> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
>> 
>> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
>> 
>> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
>> 
>> This change supports the following platforms: x86, aarch64, PPC, and RISCV
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   RISCV port update

Looks good. Just a few minor comments.

src/hotspot/share/interpreter/bootstrapInfo.cpp line 218:

> 216:                                                           _indy_index,
> 217:                                                           pool()->tag_at(_bss_index),
> 218:                                                           CHECK_false);

Please indent lines 216-218 like before.

src/hotspot/share/interpreter/bootstrapInfo.cpp line 234:

> 232:   if (_indy_index > -1) {
> 233:     os::snprintf_checked(what, sizeof(what), "indy#%d", _indy_index);
> 234:   }

Since the `else` case doesn?t have braces, maybe omit the braces for this case as well?

src/hotspot/share/oops/cpCache.cpp line 618:

> 616:                  indy_resolution_failed(), parameter_size());
> 617:     if ((bytecode_1() == Bytecodes::_invokehandle)) {
> 618:       constantPoolHandle cph(Thread::current(), cache->constant_pool());

There is another `cph` defined at line 601. Could that one be used?

src/hotspot/share/oops/cpCache.cpp line 652:

> 650:   int size = ConstantPoolCache::size(length);
> 651: 
> 652:   // Initialize resolvedinvokedynamicinfo array with available data

Maybe breakup the long word `resolvedinvokedynamicinfo`?

src/hotspot/share/oops/cpCache.cpp line 653:

> 651: 
> 652:   // Initialize resolvedinvokedynamicinfo array with available data
> 653:   Array<ResolvedIndyEntry>* array;

Suggestion: rename `array` to `resolved_indy_entries`.

src/hotspot/share/oops/cpCache.cpp line 664:

> 662: 
> 663:   return new (loader_data, size, MetaspaceObj::ConstantPoolCacheType, THREAD)
> 664:     ConstantPoolCache(length, index_map, invokedynamic_map, array);

I think it reads better if this line is indented to right after the open parenthesis.

src/hotspot/share/prims/methodComparator.cpp line 119:

> 117:     if ((old_cp->name_ref_at(index_old) != new_cp->name_ref_at(index_new)) ||
> 118:           (old_cp->signature_ref_at(index_old) != new_cp->signature_ref_at(index_new)))
> 119:         return false;

Please adjust the indentations of lines 118 and 119 to be the same as lines 124 and 125.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/interpreter/BytecodeWithCPIndex.java line 61:

> 59:      } else {
> 60:       return cpCache.getEntryAt((int) (0xFFFF & cpCacheIndex)).getConstantPoolIndex();
> 61:      }

Maybe align all `return` statements with line 56?

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ResolvedIndyArray.java line 38:

> 36: public class ResolvedIndyArray extends GenericArray {
> 37:   static {
> 38:     VM.registerVMInitializedObserver(new Observer() {

Indentation for java code should be 4 spaces.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ResolvedIndyEntry.java line 38:

> 36:   private static long          size;
> 37:   private static long          baseOffset;
> 38:   private static CIntegerField cpIndex;

Indentation for java code should be 4 spaces.

-------------

PR: https://git.openjdk.org/jdk/pull/12778

From dcubed at openjdk.org  Wed Mar 15 01:28:32 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 15 Mar 2023 01:28:32 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v26]
In-Reply-To: <kmN_C8IN6Tj01P86gjrctndLD7Wrxw8m51f4msPK-Ak=.eccc9b74-4c3b-49ab-bded-d39aa4d15518@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <kmN_C8IN6Tj01P86gjrctndLD7Wrxw8m51f4msPK-Ak=.eccc9b74-4c3b-49ab-bded-d39aa4d15518@github.com>
Message-ID: <sfWbIK24VrWl9RqsDBQh4I3T2xmp8KHDVMiQPWbk694=.b2a9ab0d-fa72-4aa9-8bfd-a68732144868@github.com>

On Tue, 14 Mar 2023 18:52:39 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change log message when inflating fast-locked object

I did Mach5 Tier{1,2,3} on v25. Please see the bug report for the gory details:

Tier1 - 1 known, unrelated failure
Tier2 - 4 closed, unknown, related test failures
Tier3 - 8 closed, unknown, related test failures; 2 open, known, unrelated test failures;
            16 open, unknown, related test failures

I'm pausing my Mach5 testing at this point.

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From dholmes at openjdk.org  Wed Mar 15 01:54:30 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 15 Mar 2023 01:54:30 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v25]
In-Reply-To: <nqMDUKWpahko_el6kbagZCwW_omLUbUmqa7CHPThKI4=.b32b4cf5-14bf-4e26-b0bb-47daee24b81e@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_3eNnc8JNcoPdK8IZHTUGkSMqnERJmfab9ry323jVKI=.1faf478c-af7f-4d82-a35b-0252b2d068cc@github.com>
 <UCm8xY8WPnV8Hb6B-dY64ReoP-lLx2A4O4J4n5HjLhY=.990423c0-19fc-44d2-91b2-bfe20006b5a4@github.com>
 <nqMDUKWpahko_el6kbagZCwW_omLUbUmqa7CHPThKI4=.b32b4cf5-14bf-4e26-b0bb-47daee24b81e@github.com>
Message-ID: <SkUSC3XI6siC3FpCFYWCDijvtrHQ-ccFiXHMo7xEZYI=.386bad81-30a9-4f49-b7ee-148610258736@github.com>

On Tue, 14 Mar 2023 18:46:47 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> I've reviewed the changes in v23 and v24. Trying another
>> Mach5 Tier1 job set.
>
>> I've reviewed the changes in v23 and v24. Trying another Mach5 Tier1 job set.
> 
> I just now pushed a simple change that changes the log message 'inflate(fast-locked)' to 'inflate(has_locker)' to make those tests happy.

@rkennke this still seems to be very much a work-in-progress rather than actual PR review at this stage. Perhaps it should move back to draft until you actually have something you think is ready for integration?

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From gcao at openjdk.org  Wed Mar 15 02:07:25 2023
From: gcao at openjdk.org (Gui Cao)
Date: Wed, 15 Mar 2023 02:07:25 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v4]
In-Reply-To: <NAlT40fGcwSR_s4NrUvvFgwZC4JnCrISl2K5uoFt7YQ=.20613218-a79b-4b64-83ba-ea22b54f8d6e@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <NAlT40fGcwSR_s4NrUvvFgwZC4JnCrISl2K5uoFt7YQ=.20613218-a79b-4b64-83ba-ea22b54f8d6e@github.com>
Message-ID: <ZnzpjxrZfm8VFrBpmFF13Dygh8WLHAhzZxMnPh3Pj-g=.aa2aa0a7-4171-484e-b6d0-ea3a07e4e70a@github.com>

On Tue, 14 Mar 2023 20:20:41 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
>> 
>> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
>> 
>> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
>> 
>> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
>> 
>> This change supports the following platforms: x86, aarch64, PPC, and RISCV
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   RISCV port update

Changes requested by gcao (Author).

-------------

PR: https://git.openjdk.org/jdk/pull/12778

From gcao at openjdk.org  Wed Mar 15 02:07:29 2023
From: gcao at openjdk.org (Gui Cao)
Date: Wed, 15 Mar 2023 02:07:29 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v3]
In-Reply-To: <vR9DLx3Oi7S-M_8Qu-d0k6DfZTqfamB4AYt-JLeErvk=.0cf5358f-71fe-4956-8683-1ceae15de148@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <vR9DLx3Oi7S-M_8Qu-d0k6DfZTqfamB4AYt-JLeErvk=.0cf5358f-71fe-4956-8683-1ceae15de148@github.com>
Message-ID: <C0Ps3NkEurVkM1bRDTlkCiZ58qvo0bP7pF79PKbZi0c=.a75791eb-1987-4c22-b0e5-040d0240fd4a@github.com>

On Tue, 14 Mar 2023 13:59:48 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
>> 
>> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
>> 
>> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
>> 
>> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
>> 
>> This change supports the following platforms: x86, aarch64, PPC, and RISCV
>
> Matias Saavedra Silva 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:
> 
>  - Typo in comment
>  - Merge branch 'master' into resolvedIndyEntry_8301995
>  - Interpreter optimization and comments
>  - PPC and RISCV port
>  - 8301995: Move invokedynamic resolution information out of the cpCache

src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1843:

> 1841:   ldr(cache, Address(rcpool, in_bytes(ConstantPoolCache::invokedynamic_entries_offset())));
> 1842:   // Scale the index to be the entry index * sizeof(ResolvedInvokeDynamicInfo)
> 1843:   mov(tmp, sizeof(ResolvedIndyEntry));

The tmp register is not used here, is it redundant?

-------------

PR: https://git.openjdk.org/jdk/pull/12778

From dholmes at openjdk.org  Wed Mar 15 02:08:20 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 15 Mar 2023 02:08:20 GMT
Subject: RFR: 8301308: Remove version conditionalization for gcc/clang
 PRAGMA_DIAG_PUSH/POP
In-Reply-To: <9BP1enfxaU7HVyJEL27oCu9kMC45tWMkeUcqg1Xr6zE=.4a774982-1c1a-44ed-8862-2c300e79f458@github.com>
References: <9BP1enfxaU7HVyJEL27oCu9kMC45tWMkeUcqg1Xr6zE=.4a774982-1c1a-44ed-8862-2c300e79f458@github.com>
Message-ID: <BKwXox3dyshgs7F_fjGdIs_jvjY0xi6FjnzGp2uCTmw=.8027eb78-9185-4818-aeb5-333042d6464e@github.com>

On Tue, 14 Mar 2023 17:51:12 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> As of now we at minimum require clang 3.5 and gcc 6 to compile the Java Platform, the version checks for gcc/clang here are for whether clang is either version 4 and above, or has a minor version higher than 3.1, and for gcc either a major version higher than 4 or minor version above 4.6. Now these will always pass, so they can be removed. Also changes the macro definition location to match Visual C++ and look neater

LGTM.

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/13025

From dholmes at openjdk.org  Wed Mar 15 02:36:06 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 15 Mar 2023 02:36:06 GMT
Subject: RFR: 8303150: DCmd framework unnecessarily creates a DCmd instance
 on registration [v2]
In-Reply-To: <X5Q2C2EZpTXFzEVwH1vO0_W4VSa3OA8w3YORZ-ucbyQ=.f5cdc97d-d97d-40d4-a9ea-7e432483d8a6@github.com>
References: <TNyX996lKlRcmTijRTN0VUZBcNBt2DXeMPhDBjaa0NQ=.160293b7-4570-43a5-af9e-d9cb02022820@github.com>
 <X5Q2C2EZpTXFzEVwH1vO0_W4VSa3OA8w3YORZ-ucbyQ=.f5cdc97d-d97d-40d4-a9ea-7e432483d8a6@github.com>
Message-ID: <nUdFV1w9euYBNNOMY-fQaLHb8etH6-qZkKoZosxsWbw=.5e484f50-e359-44e2-bda2-dfd3e86d28c6@github.com>

On Tue, 14 Mar 2023 09:46:12 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Comment update - Kevin's feedback
>
> src/hotspot/share/services/diagnosticFramework.hpp line 1:
> 
>> 1: /*
> 
> Should we update this comment:
> 279   // - For subclasses of DCmdWithParser, it's calculated by DCmdParser::num_arguments().

Fixed - thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/12994

From dholmes at openjdk.org  Wed Mar 15 02:36:03 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 15 Mar 2023 02:36:03 GMT
Subject: RFR: 8303150: DCmd framework unnecessarily creates a DCmd instance
 on registration [v2]
In-Reply-To: <TNyX996lKlRcmTijRTN0VUZBcNBt2DXeMPhDBjaa0NQ=.160293b7-4570-43a5-af9e-d9cb02022820@github.com>
References: <TNyX996lKlRcmTijRTN0VUZBcNBt2DXeMPhDBjaa0NQ=.160293b7-4570-43a5-af9e-d9cb02022820@github.com>
Message-ID: <auaUrWdPp0Xj7krEXqpcN6Yh9of8w3ljR0JvfJZstqA=.57f64cd0-6b58-44b2-b18d-e6481dcaaf9b@github.com>

> When DCmd factories are registered, the factory is passed the number of arguments taken by the DCmd - using a template method `get_num_arguments`. For DCmds that don't extend DCmdWithParser there has to be a static `num_arguments()` method in that class. For DCmds that do extend DCmdWithParser the logic instantiates an instance of the DCmd, extracts its parser and calls its `num_arguments` method which dynamically counts the number of defined arguments.
> 
> Creating an instance of each DCmd and dynamically counting arguments is inefficient and unnecessary, the number of arguments is statically known and easily expressed (in fact many of the JFR DCmds already statically define this). So we add the static `num_arguments()` method to each class that needs it and return the statically counted number of arguments. To ensure the static number and actual number don't get out-of-sync, we keep the original dynamic logic for use in debug builds to assert that the static and dynamic counts are the same. The assert will trigger during a debug build if something does get out of sync, for example if a new DCmd (extending DCmdWithParser) were added but didn't define the static `num_arguments()` method.
> 
> A number of DCmd classes were unnecessarily defining their own dynamic version of `num_arguments` and these are now removed.
> 
> In the template method I use `ENABLE_IF(std::is_convertible<T, DCmd>::value)` to check we only call this on DCmd classes. This may be unnecessary but it seemed consistent with the other template methods. Note that `std::is_base_of` only works for immediate super types.
> 
> Testing: tiers 1-4
> 
> Performance: in theory we should see some improvement in startup; in practice it is barely noticeable.
> 
> Thanks.

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Comment update - Kevin's feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12994/files
  - new: https://git.openjdk.org/jdk/pull/12994/files/5ef9724d..cfe345d8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12994&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12994&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12994.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12994/head:pull/12994

PR: https://git.openjdk.org/jdk/pull/12994

From dholmes at openjdk.org  Wed Mar 15 02:57:20 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 15 Mar 2023 02:57:20 GMT
Subject: RFR: 8304089: Convert TraceDependencies to UL [v3]
In-Reply-To: <BQzDwBUOHbm1v3Ex5uAT56pIQJtoT8ON4ZmFhi3TvR0=.ce86f07b-4136-4870-93f0-c9723c80795b@github.com>
References: <0aGc1NdAjpvksCWmXb1gZOPp9MV0n6xWvG8EaEp2ZLg=.b79cf218-9a23-420d-bec5-7509b7f8f1c1@github.com>
 <BQzDwBUOHbm1v3Ex5uAT56pIQJtoT8ON4ZmFhi3TvR0=.ce86f07b-4136-4870-93f0-c9723c80795b@github.com>
Message-ID: <13yGfFhRFEsjHA-ox_6GxPiyU8w_hpQtgjHbsw6Glq0=.c2330c3f-0316-4f4c-aade-b6ad6c8543ee@github.com>

On Tue, 14 Mar 2023 15:40:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change converts TraceDependencies to UL and removes the develop option. I think this provides further flexibility to add tags to only trace certain things in dependency analysis, as I did when trying to understand a PR for a deoptimization change.  For now, the messages are the same and the option is -Xlog:dependencies=debug.
>> Tested with tier1-4
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix merge conflict.

Overall looks good. Just a couple of small tweaks needed.

Thanks.

src/hotspot/share/runtime/arguments.cpp line 3589:

> 3587:       PrintCompilation || PrintInlining || PrintDependencies || PrintNativeNMethods ||
> 3588:       PrintDebugInfo || PrintRelocations || PrintNMethods || PrintExceptionHandlers ||
> 3589:       PrintAssembly || TraceDeoptimization || log_is_enabled(Debug, dependencies) ||

Now TraceDependencies is converted to UL I think it should just be deleted from this function. We don't need to enable LogVMOutput in that case.

src/hotspot/share/runtime/arguments.cpp line 4004:

> 4002:   bool trace_dependencies = log_is_enabled(Debug, dependencies);
> 4003:   if (trace_dependencies && VerifyDependencies) {
> 4004:     if (trace_dependencies) {

This inner if is not needed.

-------------

Changes requested by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/13007

From dholmes at openjdk.org  Wed Mar 15 04:59:33 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 15 Mar 2023 04:59:33 GMT
Subject: RFR: 8302191: Performance degradation for float/double modulo on
 Linux [v13]
In-Reply-To: <CkbXLZNrBGwQzsb88Gx3NnEPfvtcVQcTM9BiObmLMwg=.4fb98a6e-3839-48d5-9b83-c1b857b30e60@github.com>
References: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
 <CkbXLZNrBGwQzsb88Gx3NnEPfvtcVQcTM9BiObmLMwg=.4fb98a6e-3839-48d5-9b83-c1b857b30e60@github.com>
Message-ID: <zyZmB20qdtF9JepETeVJVvVRW-UTPwo6UYi5Jwea6yE=.988f2a96-77bd-483d-a1fa-df4ab920f719@github.com>

On Tue, 14 Mar 2023 12:45:42 GMT, Jan Kratochvil <duke at openjdk.org> wrote:

>> I have OCA already processed/approved. I am not Author but my Author request is being processed these days (sent to Rob McKenna).
>> I did regression test x86_64 OpenJDK-8. I will leave other regression testing on GHA.
>> The patch (and former GCC performance regression) affects only x86_64+i686.
>
> Jan Kratochvil 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 branch 'master' into modulo
>  - Fix missing SharedRuntime::frem and SharedRuntime::drem on aarch64.
>     - bugreported by sviswa7.
>  - Merge branch 'master' into modulo
>  - Fix #endif comment - found by dholmes-ora.
>  - Merge branch 'master' into modulo
>  - Fix win32 broken build.
>  - Merge remote-tracking branch 'origin/master' into modulo
>  - Always include the _WIN64 workaround - a review by dholmes-ora.
>  - Remove comments to be moved to JBS (Bug System) - a review by jddarcy.
>  - Uppercase L - a review by turbanoff.
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/e315d7df...65af58da

Functional CI testing in tiers 1-4 is good.

I'm also running some benchmarks on Linux-x64

-------------

PR: https://git.openjdk.org/jdk/pull/12508

From stuefe at openjdk.org  Wed Mar 15 06:03:22 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 15 Mar 2023 06:03:22 GMT
Subject: RFR: 8302073: Specifying OnError handler prevents WatcherThread to
 break a deadlock in report_and_die()
In-Reply-To: <rpWZDbFeVeiHDelrT7jAqzs_ngRx92GTGyGLsask2Vk=.bf26d4e4-73e8-4b14-8cd9-d44f40c4790e@github.com>
References: <nTD9cu_uj-X-ML_g-kbPrccPTlk5NGX9iV5TLXxOpbA=.2cea728c-6dbe-41a5-b379-a75c4ebc85e0@github.com>
 <k9wKuvOyzPUxNzE_aHGg_Abr5gckbriofiHDuMmhfps=.51b99d4a-8f1f-4134-8121-3738f2b13e41@github.com>
 <G-ReJaBrJTUBgWUmcE4eoqXQrtHCLPMSL7nQyom4QIM=.77438a77-60c9-4dc1-b811-7a71249d4358@github.com>
 <0jlQWouDE0tJ-ysn7WFYArqrJwHFQ-hhsZKKRGdVhmU=.95c4ceb0-9b8e-4c9b-9029-473626fb5a6b@github.com>
 <ENv94gS1Al_g-WlkPImshjot7HVPKvid7g7ft8gxQNk=.1e5aa0f3-6bfc-4f9a-8df3-7f2c7f094c20@github.com>
 <rpWZDbFeVeiHDelrT7jAqzs_ngRx92GTGyGLsask2Vk=.bf26d4e4-73e8-4b14-8cd9-d44f40c4790e@github.com>
Message-ID: <o4vwkgGkSIZhSibVC1YAIp1ee8eUblRZvsg6zKQF2ys=.1d90e61b-8d00-4758-891c-c1d03b1e7342@github.com>

On Tue, 14 Mar 2023 18:13:11 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> > > > Decoder, in particular, should not use malloc. Therefore I also opened https://bugs.openjdk.org/browse/JDK-8303862 to track that. I won't have time to work on that. I have the hope that maybe @chhagedorn can :-) ?
> > > 
> > > 
> > > Does any of our current allocation strategies allow the usage of a custom scratch buffer (i.e. the error reporting scratch buffer) as memory location? If not, it could get more complicated. I could still try to tackle that but I'm not sure if I have the necessary knowledge in that area.
> > 
> > 
> > What we usually do for these kind of problems is to pass the scratch buffer via argument to the processing functions. And make that use either it or, if NULL was passes, allocate its own thing.
> > Another way to do this would be to add a scratch buffer pointer to Thread.
> > A third way to do this (I had been experimenting with it) would be to pre-allocate a scratch buffer, and once error handling began, to use that inside os::malloc. That is the most involved solution, though, and I'm not particularly fond of it. I know many reviewers would hate it, too :-)
> 
> Thanks for the summary. Could we also use "placement new" to use the scratch buffer to allocate and create objects to? For example, when creating a decoder, to use something like
> 
> ```
> decoder = new(scratch_buffer) ElfDecoder();
> ```
> 
> here:
> 
> https://github.com/openjdk/jdk/blob/4e631fa43fd821846c12ae2177360c44cf770766/src/hotspot/share/utilities/decoder.cpp#L62-L70
> 
> Then we can still utilize polymorphism. But then `AbstractDecoder` needs to be something else than `CHeapObj`. And of course, this approach also needs careful checking that a new object actually fits into the provided scratch buffer. On top of that, it gets more complicated when we want to keep multiple objects alive in the same scratch buffer. So, I'm not sure if this approach is feasible, though.

Its possible to use placement new, and also to place several objects like this; but I realize now the scratch buffer might be too small. 

I need to think this through a bit. Maybe providing a pre-allocated buffer for os::malloc would be the right thing to do.

-------------

PR: https://git.openjdk.org/jdk/pull/12925

From fyang at openjdk.org  Wed Mar 15 07:43:32 2023
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 15 Mar 2023 07:43:32 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v25]
In-Reply-To: <nqMDUKWpahko_el6kbagZCwW_omLUbUmqa7CHPThKI4=.b32b4cf5-14bf-4e26-b0bb-47daee24b81e@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_3eNnc8JNcoPdK8IZHTUGkSMqnERJmfab9ry323jVKI=.1faf478c-af7f-4d82-a35b-0252b2d068cc@github.com>
 <UCm8xY8WPnV8Hb6B-dY64ReoP-lLx2A4O4J4n5HjLhY=.990423c0-19fc-44d2-91b2-bfe20006b5a4@github.com>
 <nqMDUKWpahko_el6kbagZCwW_omLUbUmqa7CHPThKI4=.b32b4cf5-14bf-4e26-b0bb-47daee24b81e@github.com>
Message-ID: <zzyKog7p1eE32qkiCoF4yZEtCHR-8Qhp4jtbrfEJD-k=.ee019361-5b8a-4b48-b822-839e4234189f@github.com>

On Tue, 14 Mar 2023 18:46:47 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> I've reviewed the changes in v23 and v24. Trying another
>> Mach5 Tier1 job set.
>
>> I've reviewed the changes in v23 and v24. Trying another Mach5 Tier1 job set.
> 
> I just now pushed a simple change that changes the log message 'inflate(fast-locked)' to 'inflate(has_locker)' to make those tests happy.

@rkennke : Hi, I have prepared some extra changes for RISC-V to make it work. See attachment. 

BTW: You might also want to use -w instructions in MacroAssembler::fast_unlock for aarch64.

[more-riscv-changes.txt](https://github.com/openjdk/jdk/files/10977109/more-riscv-changes.txt)

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From aboldtch at openjdk.org  Wed Mar 15 08:15:20 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 15 Mar 2023 08:15:20 GMT
Subject: RFR: 8304149: Avoid walking the CodeCache in
 DeoptimizationScope::deoptimize_marked
Message-ID: <SeBPsBnX-fEmJ07uqnI-yaT_jDzuwsqQkMTDDBprBb4=.2cef2f4d-8c87-4a42-8b98-60851f6bc645@github.com>

Change DeoptimizationScope to keep track of the marked CompiledMethods in a list to avoid having to walk the CodeCache to find them again when deoptimizing.

This adds a linked list to DeoptimizationScope which tracks the marked CompiledMethods for the active deoptimization generation. Then when deoptimize_marked is called the committing caller claims the list and uses it to deoptimize the linked (and marked) CompileMethods instead of iterating over the CodeCache to find them again.

Testing: Oracle platforms tier 1-7

-------------

Commit messages:
 - 8304149: Avoid walking the CodeCache in DeoptimizationScope::deoptimize_marked

Changes: https://git.openjdk.org/jdk/pull/13036/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13036&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304149
  Stats: 139 lines in 6 files changed: 94 ins; 40 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/13036.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/13036/head:pull/13036

PR: https://git.openjdk.org/jdk/pull/13036

From stuefe at openjdk.org  Wed Mar 15 08:49:24 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 15 Mar 2023 08:49:24 GMT
Subject: RFR: 8303150: DCmd framework unnecessarily creates a DCmd instance
 on registration [v2]
In-Reply-To: <auaUrWdPp0Xj7krEXqpcN6Yh9of8w3ljR0JvfJZstqA=.57f64cd0-6b58-44b2-b18d-e6481dcaaf9b@github.com>
References: <TNyX996lKlRcmTijRTN0VUZBcNBt2DXeMPhDBjaa0NQ=.160293b7-4570-43a5-af9e-d9cb02022820@github.com>
 <auaUrWdPp0Xj7krEXqpcN6Yh9of8w3ljR0JvfJZstqA=.57f64cd0-6b58-44b2-b18d-e6481dcaaf9b@github.com>
Message-ID: <wPMyz2KdaRA5jvEB-iF2xCXKWAQe16S5qz9d4y4bYoA=.d1c242d1-a232-45b0-9299-40024bf8e8ec@github.com>

On Wed, 15 Mar 2023 02:36:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> When DCmd factories are registered, the factory is passed the number of arguments taken by the DCmd - using a template method `get_num_arguments`. For DCmds that don't extend DCmdWithParser there has to be a static `num_arguments()` method in that class. For DCmds that do extend DCmdWithParser the logic instantiates an instance of the DCmd, extracts its parser and calls its `num_arguments` method which dynamically counts the number of defined arguments.
>> 
>> Creating an instance of each DCmd and dynamically counting arguments is inefficient and unnecessary, the number of arguments is statically known and easily expressed (in fact many of the JFR DCmds already statically define this). So we add the static `num_arguments()` method to each class that needs it and return the statically counted number of arguments. To ensure the static number and actual number don't get out-of-sync, we keep the original dynamic logic for use in debug builds to assert that the static and dynamic counts are the same. The assert will trigger during a debug build if something does get out of sync, for example if a new DCmd (extending DCmdWithParser) were added but didn't define the static `num_arguments()` method.
>> 
>> A number of DCmd classes were unnecessarily defining their own dynamic version of `num_arguments` and these are now removed.
>> 
>> In the template method I use `ENABLE_IF(std::is_convertible<T, DCmd>::value)` to check we only call this on DCmd classes. This may be unnecessary but it seemed consistent with the other template methods. Note that `std::is_base_of` only works for immediate super types.
>> 
>> Testing: tiers 1-4
>> 
>> Performance: in theory we should see some improvement in startup; in practice it is barely noticeable.
>> 
>> Thanks.
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment update - Kevin's feedback

Thanks a lot for removing that blemish, David! That has bugged me (and others) repeatedly.

Question inline, but looks good all in all.

src/hotspot/share/services/diagnosticFramework.hpp line 446:

> 444: 
> 445:   template <typename T, ENABLE_IF(std::is_base_of<DCmdWithParser, T>::value)>
> 446:   static int get_parsed_num_arguments() {

I don't understand why we need the dynamic allocation here. Should we not be able to call your new static versions of num_arguments for DCmdWithParser children, like we do for DCmd children above? And if so, could we then not unify those two functions?

-------------

PR: https://git.openjdk.org/jdk/pull/12994

From stefank at openjdk.org  Wed Mar 15 08:53:29 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 15 Mar 2023 08:53:29 GMT
Subject: RFR: 8292059: Do not inline InstanceKlass::allocate_instance()
 [v6]
In-Reply-To: <QHPRRNYQPAcZ8QEeb_uz9cBq4Y1fDpcQqvutYIbZiiU=.017aeac3-5d24-4f40-aefb-045bdf7d4a84@github.com>
References: <ZSJBTzuC4wVuKdqSLLTgw4Pds2oX5wah0Ub6rFux_tc=.c4e2ae89-cadb-4ccd-9eee-034583cf7200@github.com>
 <QHPRRNYQPAcZ8QEeb_uz9cBq4Y1fDpcQqvutYIbZiiU=.017aeac3-5d24-4f40-aefb-045bdf7d4a84@github.com>
Message-ID: <us1jJrysVTl-Re4JuzaOazTyIf3npJJEFmcmlKiNWo0=.1117428b-e281-437b-8993-3d851f1f94bd@github.com>

On Tue, 14 Mar 2023 09:50:17 GMT, Afshin Zafari <duke at openjdk.org> wrote:

>> The inline and not-inline versions of the method is tested to compare the performance difference. 
>> ### Test
>> `make test TEST=micro:Capture0.lambda_01 MICRO="VM_OPTIONS=-XX:TieredStopAtLevel=1" `
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8292059: Do not inline InstanceKlass::allocate_instance()

I don't oppose this change.

-------------

Marked as reviewed by stefank (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12782

From rkennke at openjdk.org  Wed Mar 15 09:41:30 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 15 Mar 2023 09:41:30 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v27]
In-Reply-To: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
Message-ID: <AmDOQhS1AzZxHd0kV_jhUWSGVdt8NZbfMVydFpHnQjs=.eff82b60-de1c-45e8-b54b-183b174b63d9@github.com>

> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
> 
> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p
 rotocols.
> 
> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
> 
> 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
> 
> 
> Testing:
>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
> 
> ### Performance
> 
> #### Simple Microbenchmark
> 
> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
> 
> |  | x86_64 | aarch64 |
> | -- | -- | -- |
> | -UseFastLocking | 20.651 | 20.764 |
> | +UseFastLocking | 18.896 | 18.908 |
> 
> 
> #### Renaissance
> 
> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
> -- | -- | -- | -- | -- | -- | -- | --
> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%

Roman Kennke has updated the pull request incrementally with three additional commits since the last revision:

 - More RISCV changes (by Fei Yang)
 - Use -w instructions in fast_unlock()
 - Increase stub size of C2HandleAnonOwnerStub to 18

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10907/files
  - new: https://git.openjdk.org/jdk/pull/10907/files/b834f0ca..0ad01c1d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=26
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=25-26

  Stats: 136 lines in 7 files changed: 62 ins; 28 del; 46 mod
  Patch: https://git.openjdk.org/jdk/pull/10907.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10907/head:pull/10907

PR: https://git.openjdk.org/jdk/pull/10907

From rkennke at openjdk.org  Wed Mar 15 09:41:30 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 15 Mar 2023 09:41:30 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v26]
In-Reply-To: <sfWbIK24VrWl9RqsDBQh4I3T2xmp8KHDVMiQPWbk694=.b2a9ab0d-fa72-4aa9-8bfd-a68732144868@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <kmN_C8IN6Tj01P86gjrctndLD7Wrxw8m51f4msPK-Ak=.eccc9b74-4c3b-49ab-bded-d39aa4d15518@github.com>
 <sfWbIK24VrWl9RqsDBQh4I3T2xmp8KHDVMiQPWbk694=.b2a9ab0d-fa72-4aa9-8bfd-a68732144868@github.com>
Message-ID: <LqDlCifR-tcEv3WR4_50xOOPw6XipCD9QYrLazD7LuY=.e87dc186-3d7c-4ae8-b13a-d6e7830581fb@github.com>

On Wed, 15 Mar 2023 01:25:33 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> I did Mach5 Tier{1,2,3} on v25. Please see the bug report for the gory details:
> 
> Tier1 - 1 known, unrelated failure Tier2 - 4 closed, unknown, related test failures Tier3 - 8 closed, unknown, related test failures; 2 open, known, unrelated test failures; 16 open, unknown, related test failures
> 
> I'm pausing my Mach5 testing at this point.

Hi Daniel,

I could not reproduce any of the test failures, neither on x86_64 nor on aarch64. I have blindly fixed the code stub size issue, it seems rather trivial. Would it be possible to open/send me the failing test that triggers vframeArray assert or extract a reproducer that you could publish? I looked at it but could not figure out what could be going on there.

Thanks,
Roman

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From kevinw at openjdk.org  Wed Mar 15 10:39:20 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 15 Mar 2023 10:39:20 GMT
Subject: RFR: 8303150: DCmd framework unnecessarily creates a DCmd instance
 on registration [v2]
In-Reply-To: <auaUrWdPp0Xj7krEXqpcN6Yh9of8w3ljR0JvfJZstqA=.57f64cd0-6b58-44b2-b18d-e6481dcaaf9b@github.com>
References: <TNyX996lKlRcmTijRTN0VUZBcNBt2DXeMPhDBjaa0NQ=.160293b7-4570-43a5-af9e-d9cb02022820@github.com>
 <auaUrWdPp0Xj7krEXqpcN6Yh9of8w3ljR0JvfJZstqA=.57f64cd0-6b58-44b2-b18d-e6481dcaaf9b@github.com>
Message-ID: <lEiO0Aajy9-YhY-rk3pmA2oDTzE7RrHUCRia8sE6czc=.0a7872d4-eb79-4b6e-8ba6-74486be67179@github.com>

On Wed, 15 Mar 2023 02:36:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> When DCmd factories are registered, the factory is passed the number of arguments taken by the DCmd - using a template method `get_num_arguments`. For DCmds that don't extend DCmdWithParser there has to be a static `num_arguments()` method in that class. For DCmds that do extend DCmdWithParser the logic instantiates an instance of the DCmd, extracts its parser and calls its `num_arguments` method which dynamically counts the number of defined arguments.
>> 
>> Creating an instance of each DCmd and dynamically counting arguments is inefficient and unnecessary, the number of arguments is statically known and easily expressed (in fact many of the JFR DCmds already statically define this). So we add the static `num_arguments()` method to each class that needs it and return the statically counted number of arguments. To ensure the static number and actual number don't get out-of-sync, we keep the original dynamic logic for use in debug builds to assert that the static and dynamic counts are the same. The assert will trigger during a debug build if something does get out of sync, for example if a new DCmd (extending DCmdWithParser) were added but didn't define the static `num_arguments()` method.
>> 
>> A number of DCmd classes were unnecessarily defining their own dynamic version of `num_arguments` and these are now removed.
>> 
>> In the template method I use `ENABLE_IF(std::is_convertible<T, DCmd>::value)` to check we only call this on DCmd classes. This may be unnecessary but it seemed consistent with the other template methods. Note that `std::is_base_of` only works for immediate super types.
>> 
>> Testing: tiers 1-4
>> 
>> Performance: in theory we should see some improvement in startup; in practice it is barely noticeable.
>> 
>> Thanks.
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment update - Kevin's feedback

Marked as reviewed by kevinw (Committer).

Took me a bit of time, as I was thinking if we compare a hard-coded value with a parsed argument count, how does that cope with optional arguments?  Maybe "get_parsed_num_arguments()" suggested to me it was a live command being parsed, but DCmdParser's _arguments_list is a list of known possible arguments. Should have read your "number of arguments taken by the DCmd" at the top more carefully.

-------------

PR: https://git.openjdk.org/jdk/pull/12994

From mdoerr at openjdk.org  Wed Mar 15 10:51:20 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 15 Mar 2023 10:51:20 GMT
Subject: RFR: 8296440: Remove Method* handling from
 cleanup_inline_caches_impl
In-Reply-To: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
References: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
Message-ID: <gRv9sYskW0fD2m_7j1gt39Fl0XLv9vha7Mdw_X78WsU=.a8fa6c8f-a5fa-447a-a430-a659fc41b8bb@github.com>

On Wed, 1 Mar 2023 11:07:36 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> This PR replaces cleaning of static stubs in CompiledMethod::cleanup_inline_caches_impl() with a guarantee that it is actually not needed because the holder of the embedded target Method* is alive if the caller nmethod is not unloading.
> 
> The holder of the target Method* has to be alive because it is reachable from the caller nmethod's oop pool. This is checked by `check_path_to_callee()` when a statically bound call gets resolved.
> 
> C2i entry barriers can be removed for the same reason.
> 
> Testing:
> 
> Many rounds in our CI testing which includes most JCK and JTREG tests, Renaissance benchmark and SAP specific tests with fastdebug and release builds on the standard platforms plus PPC64.
> 
> I've also done tier1 and tier2 tests with -XX:-Inline and tier1 tests with ZGC.
> 
> I've started hotspot and jdk tier1 tests with -Xcomp. They were not finished when I stopped them after 24h.

Impressive that we can get rid of so much complicated code! Looks correct to me. Is the check fast enough to do it on every resolution?

-------------

Marked as reviewed by mdoerr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12802

From jsjolen at openjdk.org  Wed Mar 15 11:09:25 2023
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 15 Mar 2023 11:09:25 GMT
Subject: RFR: JDK-8301498: Replace NULL with nullptr in cpu/x86 [v3]
In-Reply-To: <AB1094dam2aXNm_hav09Ium0jqJUCJE0hmJ4GfljA5M=.4e8e0845-20d5-45bf-bf2e-1d23ed8ef9f0@github.com>
References: <AB1094dam2aXNm_hav09Ium0jqJUCJE0hmJ4GfljA5M=.4e8e0845-20d5-45bf-bf2e-1d23ed8ef9f0@github.com>
Message-ID: <Dt5DVW6D3E3khwTaDNTy3kcrxJmv_fEK37iXonS06C8=.ab98f698-1dc3-4d64-b57a-cb69493a38a0@github.com>

> Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory cpu/x86. Unfortunately the script that does the change isn't perfect, and so we
> need to comb through these manually to make sure nothing has gone wrong. I also review these changes but things slip past my eyes sometimes.
> 
> Here are some typical things to look out for:
> 
> 1. No changes but copyright header changed (probably because I reverted some changes but forgot the copyright).
> 2. Macros having their NULL changed to nullptr, these are added to the script when I find them. They should be NULL.
> 3. nullptr in comments and logs. We try to use lower case "null" in these cases as it reads better. An exception is made when code expressions are in a comment.
> 
> An example of this:
> 
> ```c++
> // This function returns null
> void* ret_null();
> // This function returns true if *x == nullptr
> bool is_nullptr(void** x);
> 
> 
> Note how `nullptr` participates in a code expression here, we really are talking about the specific value `nullptr`.
> 
> Thanks!

Johan Sj?len has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Fix vnkozlov's suggestions
 - Merge remote-tracking branch 'origin/master' into JDK-8301498
 - Some more fixes
 - Fixes
 -  Replace NULL with nullptr in cpu/x86

-------------

Changes: https://git.openjdk.org/jdk/pull/12326/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12326&range=02
  Stats: 665 lines in 54 files changed: 0 ins; 0 del; 665 mod
  Patch: https://git.openjdk.org/jdk/pull/12326.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12326/head:pull/12326

PR: https://git.openjdk.org/jdk/pull/12326

From jsjolen at openjdk.org  Wed Mar 15 11:09:27 2023
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 15 Mar 2023 11:09:27 GMT
Subject: RFR: JDK-8301498: Replace NULL with nullptr in cpu/x86 [v2]
In-Reply-To: <A7NM736-m41tNY5Yxq-lZR50Gudf1zgBf9JD5tsv_7U=.8f279462-fb29-450a-bee6-164586e8c655@github.com>
References: <AB1094dam2aXNm_hav09Ium0jqJUCJE0hmJ4GfljA5M=.4e8e0845-20d5-45bf-bf2e-1d23ed8ef9f0@github.com>
 <A7NM736-m41tNY5Yxq-lZR50Gudf1zgBf9JD5tsv_7U=.8f279462-fb29-450a-bee6-164586e8c655@github.com>
Message-ID: <nh5GrelR9Bw1qncrnVAvxn0LRe6UwR8WHLlg25z61ZA=.1343eeb6-4788-419d-b39b-b915a0b5458c@github.com>

On Mon, 13 Feb 2023 09:26:07 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory cpu/x86. Unfortunately the script that does the change isn't perfect, and so we
>> need to comb through these manually to make sure nothing has gone wrong. I also review these changes but things slip past my eyes sometimes.
>> 
>> Here are some typical things to look out for:
>> 
>> 1. No changes but copyright header changed (probably because I reverted some changes but forgot the copyright).
>> 2. Macros having their NULL changed to nullptr, these are added to the script when I find them. They should be NULL.
>> 3. nullptr in comments and logs. We try to use lower case "null" in these cases as it reads better. An exception is made when code expressions are in a comment.
>> 
>> An example of this:
>> 
>> ```c++
>> // This function returns null
>> void* ret_null();
>> // This function returns true if *x == nullptr
>> bool is_nullptr(void** x);
>> 
>> 
>> Note how `nullptr` participates in a code expression here, we really are talking about the specific value `nullptr`.
>> 
>> Thanks!
>
> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Some more fixes

Hi Vladimir!

I applied your changes, thanks for the review.

-------------

PR: https://git.openjdk.org/jdk/pull/12326

From dholmes at openjdk.org  Wed Mar 15 12:30:24 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 15 Mar 2023 12:30:24 GMT
Subject: RFR: 8303150: DCmd framework unnecessarily creates a DCmd instance
 on registration [v2]
In-Reply-To: <wPMyz2KdaRA5jvEB-iF2xCXKWAQe16S5qz9d4y4bYoA=.d1c242d1-a232-45b0-9299-40024bf8e8ec@github.com>
References: <TNyX996lKlRcmTijRTN0VUZBcNBt2DXeMPhDBjaa0NQ=.160293b7-4570-43a5-af9e-d9cb02022820@github.com>
 <auaUrWdPp0Xj7krEXqpcN6Yh9of8w3ljR0JvfJZstqA=.57f64cd0-6b58-44b2-b18d-e6481dcaaf9b@github.com>
 <wPMyz2KdaRA5jvEB-iF2xCXKWAQe16S5qz9d4y4bYoA=.d1c242d1-a232-45b0-9299-40024bf8e8ec@github.com>
Message-ID: <h-HOnvmpOcEw2GyGE6sUAw5yss_7c4XgWwnBTfMstio=.46b9c4e5-3dab-42bb-b094-2ed93254ff06@github.com>

On Wed, 15 Mar 2023 08:45:17 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Comment update - Kevin's feedback
>
> src/hotspot/share/services/diagnosticFramework.hpp line 446:
> 
>> 444: 
>> 445:   template <typename T, ENABLE_IF(std::is_base_of<DCmdWithParser, T>::value)>
>> 446:   static int get_parsed_num_arguments() {
> 
> I don't understand why we need the dynamic allocation here. Should we not be able to call your new static versions of num_arguments for DCmdWithParser children, like we do for DCmd children above? And if so, could we then not unify those two functions?

Thanks for looking at this @tstuefe. The whole point of the parsed version is to ensure the static version doesn't get forgotten or out-of-date.

Just realised the `get_parsed_num_arguments` should also be `ifdef ASSERT`.

-------------

PR: https://git.openjdk.org/jdk/pull/12994

From dholmes at openjdk.org  Wed Mar 15 12:30:22 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 15 Mar 2023 12:30:22 GMT
Subject: RFR: 8303150: DCmd framework unnecessarily creates a DCmd instance
 on registration [v2]
In-Reply-To: <lEiO0Aajy9-YhY-rk3pmA2oDTzE7RrHUCRia8sE6czc=.0a7872d4-eb79-4b6e-8ba6-74486be67179@github.com>
References: <TNyX996lKlRcmTijRTN0VUZBcNBt2DXeMPhDBjaa0NQ=.160293b7-4570-43a5-af9e-d9cb02022820@github.com>
 <auaUrWdPp0Xj7krEXqpcN6Yh9of8w3ljR0JvfJZstqA=.57f64cd0-6b58-44b2-b18d-e6481dcaaf9b@github.com>
 <lEiO0Aajy9-YhY-rk3pmA2oDTzE7RrHUCRia8sE6czc=.0a7872d4-eb79-4b6e-8ba6-74486be67179@github.com>
Message-ID: <RQEfAVIRYcrErIZIru5JipLKxibJ-rRlD55HJ5e1lyw=.735015e6-0a3a-4ca2-abf3-6a3eb6be8547@github.com>

On Wed, 15 Mar 2023 10:36:14 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Comment update - Kevin's feedback
>
> Took me a bit of time, as I was thinking if we compare a hard-coded value with a parsed argument count, how does that cope with optional arguments?  Maybe "get_parsed_num_arguments()" suggested to me it was a live command being parsed, but DCmdParser's _arguments_list is a list of known possible arguments. Should have read your "number of arguments taken by the DCmd" at the top more carefully.

Thanks for the review @kevinjwalls .

-------------

PR: https://git.openjdk.org/jdk/pull/12994

From coleenp at openjdk.org  Wed Mar 15 12:54:30 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 15 Mar 2023 12:54:30 GMT
Subject: RFR: 8292059: Do not inline InstanceKlass::allocate_instance()
 [v6]
In-Reply-To: <AIPEEiYAZJ3EE7PAqbRFSx4EMFCYm5bQAMmhWtYICrk=.abcfd832-11b6-4cdb-8d51-46c7987ca13c@github.com>
References: <ZSJBTzuC4wVuKdqSLLTgw4Pds2oX5wah0Ub6rFux_tc=.c4e2ae89-cadb-4ccd-9eee-034583cf7200@github.com>
 <9ZXi9uNa5ETIhldKLCDAYojtXTGEg-5EexLwHNE2zhI=.026815b3-3117-4184-be4c-5fdf42c2655f@github.com>
 <1W22QvJKaoJVRI5Wrx6DZEizGOxHsiSAEoLkHsCauQY=.6e934949-d854-49f8-9e1e-5786c0d04c8f@github.com>
 <AIPEEiYAZJ3EE7PAqbRFSx4EMFCYm5bQAMmhWtYICrk=.abcfd832-11b6-4cdb-8d51-46c7987ca13c@github.com>
Message-ID: <ncRMdKbOHmpBs5xlk2bFSQZWG4xClw6BRJbHcMvfQgo=.3dbab624-82e5-434a-9fb3-289b84d98957@github.com>

On Fri, 3 Mar 2023 16:51:32 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> All the #include headers are removed except the `utilities/devirtualizer.inline.hpp`. The .cpp files that need it should include it before `oops/instanceKlass.inline.hpp` which violates the _sorted header filename_ in the coding style rules.
>
> Good.  I think devirtualizer.inline.hpp is used by the GC inlined functions so should remain here.

Sorry for being confusing before.  My comment was that you should remove #includes that aren't directly referenced by this .inline.hpp file.  I see that you've done this now, but do you need classfile/vmSymbols.hpp here?  I don't see it.

-------------

PR: https://git.openjdk.org/jdk/pull/12782

From coleenp at openjdk.org  Wed Mar 15 13:09:05 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 15 Mar 2023 13:09:05 GMT
Subject: RFR: 8304089: Convert TraceDependencies to UL [v4]
In-Reply-To: <0aGc1NdAjpvksCWmXb1gZOPp9MV0n6xWvG8EaEp2ZLg=.b79cf218-9a23-420d-bec5-7509b7f8f1c1@github.com>
References: <0aGc1NdAjpvksCWmXb1gZOPp9MV0n6xWvG8EaEp2ZLg=.b79cf218-9a23-420d-bec5-7509b7f8f1c1@github.com>
Message-ID: <RGFR0w6FSXoaGxpHvFB6s1Eh5-c6vnf76yFpX2_QcTk=.756580b4-28fa-45d6-9128-05a2353e4a73@github.com>

> This change converts TraceDependencies to UL and removes the develop option. I think this provides further flexibility to add tags to only trace certain things in dependency analysis, as I did when trying to understand a PR for a deoptimization change.  For now, the messages are the same and the option is -Xlog:dependencies=debug.
> Tested with tier1-4

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix redundant 'if'

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13007/files
  - new: https://git.openjdk.org/jdk/pull/13007/files/e5851202..421b4ee3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13007&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13007&range=02-03

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13007.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/13007/head:pull/13007

PR: https://git.openjdk.org/jdk/pull/13007

From coleenp at openjdk.org  Wed Mar 15 13:09:14 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 15 Mar 2023 13:09:14 GMT
Subject: RFR: 8304089: Convert TraceDependencies to UL [v3]
In-Reply-To: <13yGfFhRFEsjHA-ox_6GxPiyU8w_hpQtgjHbsw6Glq0=.c2330c3f-0316-4f4c-aade-b6ad6c8543ee@github.com>
References: <0aGc1NdAjpvksCWmXb1gZOPp9MV0n6xWvG8EaEp2ZLg=.b79cf218-9a23-420d-bec5-7509b7f8f1c1@github.com>
 <BQzDwBUOHbm1v3Ex5uAT56pIQJtoT8ON4ZmFhi3TvR0=.ce86f07b-4136-4870-93f0-c9723c80795b@github.com>
 <13yGfFhRFEsjHA-ox_6GxPiyU8w_hpQtgjHbsw6Glq0=.c2330c3f-0316-4f4c-aade-b6ad6c8543ee@github.com>
Message-ID: <tLhX6beNey8aikbBH30RbCu7lfXZ9AWG2KYqKWVvnkw=.a41fbeb0-6c04-4b6a-824a-fc9fdf734fd2@github.com>

On Wed, 15 Mar 2023 02:49:54 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix merge conflict.
>
> src/hotspot/share/runtime/arguments.cpp line 3589:
> 
>> 3587:       PrintCompilation || PrintInlining || PrintDependencies || PrintNativeNMethods ||
>> 3588:       PrintDebugInfo || PrintRelocations || PrintNMethods || PrintExceptionHandlers ||
>> 3589:       PrintAssembly || TraceDeoptimization || log_is_enabled(Debug, dependencies) ||
> 
> Now TraceDependencies is converted to UL I think it should just be deleted from this function. We don't need to enable LogVMOutput in that case.

No, this is the right thing to do.  If -Xlog:dependency - the compiler group also expects the dependency printed to the compiler log file.  The logging is a separate mechanism, but should be enabled with -Xlog:dependency.

> src/hotspot/share/runtime/arguments.cpp line 4004:
> 
>> 4002:   bool trace_dependencies = log_is_enabled(Debug, dependencies);
>> 4003:   if (trace_dependencies && VerifyDependencies) {
>> 4004:     if (trace_dependencies) {
> 
> This inner if is not needed.

fixed, thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/13007

From jsjolen at openjdk.org  Wed Mar 15 13:13:23 2023
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 15 Mar 2023 13:13:23 GMT
Subject: RFR: JDK-8301495: Replace NULL with nullptr in cpu/ppc
Message-ID: <Yc6Xbezt6HII7jc13iRF2WcWhNFtnvJGAhTiWfmV868=.b7a4d190-70d0-4983-a400-c7e6e69f17d1@github.com>

Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory cpu/ppc. Unfortunately the script that does the change isn't perfect, and so we
need to comb through these manually to make sure nothing has gone wrong. I also review these changes but things slip past my eyes sometimes.

Here are some typical things to look out for:

1. No changes but copyright header changed (probably because I reverted some changes but forgot the copyright).
2. Macros having their NULL changed to nullptr, these are added to the script when I find them. They should be NULL.
3. nullptr in comments and logs. We try to use lower case "null" in these cases as it reads better. An exception is made when code expressions are in a comment.

An example of this:

```c++
// This function returns null
void* ret_null();
// This function returns true if *x == nullptr
bool is_nullptr(void** x);


Note how `nullptr` participates in a code expression here, we really are talking about the specific value `nullptr`.

Thanks!

-------------

Commit messages:
 - Merge remote-tracking branch 'origin/master' into JDK-8301495
 - Revert change in file
 - Fixes
 - Merge remote-tracking branch 'origin/master' into JDK-8301495
 - reinrich suggestions
 -  Replace NULL with nullptr in cpu/ppc

Changes: https://git.openjdk.org/jdk/pull/12323/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12323&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301495
  Stats: 384 lines in 51 files changed: 0 ins; 0 del; 384 mod
  Patch: https://git.openjdk.org/jdk/pull/12323.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12323/head:pull/12323

PR: https://git.openjdk.org/jdk/pull/12323

From rrich at openjdk.org  Wed Mar 15 13:13:37 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 15 Mar 2023 13:13:37 GMT
Subject: RFR: JDK-8301495: Replace NULL with nullptr in cpu/ppc
In-Reply-To: <Yc6Xbezt6HII7jc13iRF2WcWhNFtnvJGAhTiWfmV868=.b7a4d190-70d0-4983-a400-c7e6e69f17d1@github.com>
References: <Yc6Xbezt6HII7jc13iRF2WcWhNFtnvJGAhTiWfmV868=.b7a4d190-70d0-4983-a400-c7e6e69f17d1@github.com>
Message-ID: <o7O82QfrmITaLVIrNcBwHjxucvbbuLlgWfNkOGv5Gl0=.f21181cb-41c8-41ec-a951-a55041275e53@github.com>

On Tue, 31 Jan 2023 11:39:48 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory cpu/ppc. Unfortunately the script that does the change isn't perfect, and so we
> need to comb through these manually to make sure nothing has gone wrong. I also review these changes but things slip past my eyes sometimes.
> 
> Here are some typical things to look out for:
> 
> 1. No changes but copyright header changed (probably because I reverted some changes but forgot the copyright).
> 2. Macros having their NULL changed to nullptr, these are added to the script when I find them. They should be NULL.
> 3. nullptr in comments and logs. We try to use lower case "null" in these cases as it reads better. An exception is made when code expressions are in a comment.
> 
> An example of this:
> 
> ```c++
> // This function returns null
> void* ret_null();
> // This function returns true if *x == nullptr
> bool is_nullptr(void** x);
> 
> 
> Note how `nullptr` participates in a code expression here, we really are talking about the specific value `nullptr`.
> 
> Thanks!

Looks good, just a few changes I'd like to suggest.

Thanks, Richard.

src/hotspot/cpu/ppc/abstractInterpreter_ppc.cpp line 97:

> 95: // Parameters:
> 96: //
> 97: // interpreter_frame != null:

Suggestion:

// interpreter_frame != nullptr:

src/hotspot/cpu/ppc/frame_ppc.cpp line 114:

> 112: 
> 113:     // At this point, there still is a chance that fp_safe is false.
> 114:     // In particular, (fp == null) might be true. So let's check and

Suggestion:

    // In particular, (fp == nullptr) might be true. So let's check and

src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp line 920:

> 918:     // } else if (THREAD->is_lock_owned((address)displaced_header))
> 919:     //   // Simple recursive case.
> 920:     //   monitor->lock()->set_displaced_header(null);

Suggestion:

    //   monitor->lock()->set_displaced_header(nullptr);

src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp line 981:

> 979:     // } else if (THREAD->is_lock_owned((address)displaced_header))
> 980:     //   // Simple recursive case.
> 981:     //   monitor->lock()->set_displaced_header(null);

Suggestion:

    //   monitor->lock()->set_displaced_header(nullptr);

src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp line 1031:

> 1029:     // template code:
> 1030:     //
> 1031:     // if ((displaced_header = monitor->displaced_header()) == null) {

Suggestion:

    // if ((displaced_header = monitor->displaced_header()) == nullptr) {

src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp line 1033:

> 1031:     // if ((displaced_header = monitor->displaced_header()) == null) {
> 1032:     //   // Recursive unlock. Mark the monitor unlocked by setting the object field to null.
> 1033:     //   monitor->set_obj(null);

Suggestion:

    //   monitor->set_obj(nullptr);

src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp line 1036:

> 1034:     // } else if (Atomic::cmpxchg(obj->mark_addr(), monitor, displaced_header) == monitor) {
> 1035:     //   // We swapped the unlocked mark in displaced_header into the object's mark word.
> 1036:     //   monitor->set_obj(null);

Suggestion:

    //   monitor->set_obj(nullptr);

src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp line 1062:

> 1060:     // } else if (Atomic::cmpxchg(obj->mark_addr(), monitor, displaced_header) == monitor) {
> 1061:     //   // We swapped the unlocked mark in displaced_header into the object's mark word.
> 1062:     //   monitor->set_obj(null);

Suggestion:

    //   monitor->set_obj(nullptr);

src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp line 1097:

> 1095:     b(done); // Monitor register may be overwritten! Runtime has already freed the slot.
> 1096: 
> 1097:     // Exchange worked, do monitor->set_obj(null);

Suggestion:

    // Exchange worked, do monitor->set_obj(nullptr);

src/hotspot/cpu/ppc/interpreterRT_ppc.cpp line 102:

> 100: 
> 101:   // The handle for a receiver will never be null.
> 102:   bool do_nullptr_check = offset() != 0 || is_static();

Suggestion:

  bool do_null_check = offset() != 0 || is_static();

src/hotspot/cpu/ppc/interpreterRT_ppc.cpp line 105:

> 103: 
> 104:   Label do_null;
> 105:   if (do_nullptr_check) {

Suggestion:

  if (do_null_check) {

src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 2421:

> 2419:     BLOCK_COMMENT("arraycopy initial argument checks");
> 2420: 
> 2421:     __ cmpdi(CCR1, src, 0);      // if (src == null) return -1;

Suggestion:

    __ cmpdi(CCR1, src, 0);      // if (src == nullptr) return -1;

src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 2423:

> 2421:     __ cmpdi(CCR1, src, 0);      // if (src == null) return -1;
> 2422:     __ extsw_(src_pos, src_pos); // if (src_pos < 0) return -1;
> 2423:     __ cmpdi(CCR5, dst, 0);      // if (dst == null) return -1;

Suggestion:

    __ cmpdi(CCR5, dst, 0);      // if (dst == nullptr) return -1;

src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp line 525:

> 523:   __ ld(R3_RET, Interpreter::stackElementSize, R15_esp); // get receiver
> 524: 
> 525:   // Check if receiver == null and go the slow path.

Suggestion:

  // Check if receiver == nullptr and go the slow path.

-------------

Changes requested by rrich (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12323

From jsjolen at openjdk.org  Wed Mar 15 13:13:42 2023
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 15 Mar 2023 13:13:42 GMT
Subject: RFR: JDK-8301495: Replace NULL with nullptr in cpu/ppc
In-Reply-To: <Yc6Xbezt6HII7jc13iRF2WcWhNFtnvJGAhTiWfmV868=.b7a4d190-70d0-4983-a400-c7e6e69f17d1@github.com>
References: <Yc6Xbezt6HII7jc13iRF2WcWhNFtnvJGAhTiWfmV868=.b7a4d190-70d0-4983-a400-c7e6e69f17d1@github.com>
Message-ID: <hBxWmd7cYIDAr1K6mnvJMUCI2IQh3_PNrYCOcS7SMEg=.7e00efd4-10da-43ea-964c-71082cfc5e22@github.com>

On Tue, 31 Jan 2023 11:39:48 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory cpu/ppc. Unfortunately the script that does the change isn't perfect, and so we
> need to comb through these manually to make sure nothing has gone wrong. I also review these changes but things slip past my eyes sometimes.
> 
> Here are some typical things to look out for:
> 
> 1. No changes but copyright header changed (probably because I reverted some changes but forgot the copyright).
> 2. Macros having their NULL changed to nullptr, these are added to the script when I find them. They should be NULL.
> 3. nullptr in comments and logs. We try to use lower case "null" in these cases as it reads better. An exception is made when code expressions are in a comment.
> 
> An example of this:
> 
> ```c++
> // This function returns null
> void* ret_null();
> // This function returns true if *x == nullptr
> bool is_nullptr(void** x);
> 
> 
> Note how `nullptr` participates in a code expression here, we really are talking about the specific value `nullptr`.
> 
> Thanks!

Found a few minor issues.

src/hotspot/cpu/ppc/frame_ppc.cpp line 114:

> 112: 
> 113:     // At this point, there still is a chance that fp_safe is false.
> 114:     // In particular, (fp == nullptr) might be true. So let's check and

"fp might be null"

src/hotspot/cpu/ppc/macroAssembler_ppc.cpp line 1819:

> 1817:   }
> 1818: 
> 1819:   // for (scan = klass->itable(); scan->interface() != null; scan += scan_step) {

nullptr

src/hotspot/cpu/ppc/macroAssembler_ppc.cpp line 2710:

> 2708:   // Handle existing monitor.
> 2709:   bind(object_has_monitor);
> 2710:   // The object's monitor m is unlocked iff m->owner == null,

is null

src/hotspot/os/posix/os_posix.cpp line 293:

> 291:         ((MemTracker ::tracking_level() == NMT_detail)
> 292:              ? NativeCallStack(1)
> 293:              : NativeCallStack(NativeCallStack ::FakeMarker ::its_fake)));

Accidentally committed this, will revert to original.

-------------

PR: https://git.openjdk.org/jdk/pull/12323

From jsjolen at openjdk.org  Wed Mar 15 13:13:43 2023
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 15 Mar 2023 13:13:43 GMT
Subject: RFR: JDK-8301495: Replace NULL with nullptr in cpu/ppc
In-Reply-To: <o7O82QfrmITaLVIrNcBwHjxucvbbuLlgWfNkOGv5Gl0=.f21181cb-41c8-41ec-a951-a55041275e53@github.com>
References: <Yc6Xbezt6HII7jc13iRF2WcWhNFtnvJGAhTiWfmV868=.b7a4d190-70d0-4983-a400-c7e6e69f17d1@github.com>
 <o7O82QfrmITaLVIrNcBwHjxucvbbuLlgWfNkOGv5Gl0=.f21181cb-41c8-41ec-a951-a55041275e53@github.com>
Message-ID: <PODMofOOq_SCkZcj8FHIyO6mJRjMZeseA_615eQUWzs=.24bd452e-7d04-4d66-80ed-383d16ebcd1c@github.com>

On Wed, 1 Feb 2023 08:37:33 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory cpu/ppc. Unfortunately the script that does the change isn't perfect, and so we
>> need to comb through these manually to make sure nothing has gone wrong. I also review these changes but things slip past my eyes sometimes.
>> 
>> Here are some typical things to look out for:
>> 
>> 1. No changes but copyright header changed (probably because I reverted some changes but forgot the copyright).
>> 2. Macros having their NULL changed to nullptr, these are added to the script when I find them. They should be NULL.
>> 3. nullptr in comments and logs. We try to use lower case "null" in these cases as it reads better. An exception is made when code expressions are in a comment.
>> 
>> An example of this:
>> 
>> ```c++
>> // This function returns null
>> void* ret_null();
>> // This function returns true if *x == nullptr
>> bool is_nullptr(void** x);
>> 
>> 
>> Note how `nullptr` participates in a code expression here, we really are talking about the specific value `nullptr`.
>> 
>> Thanks!
>
> Looks good, just a few changes I'd like to suggest.
> 
> Thanks, Richard.

Thanks @reinrich for your review. I've fixed the issues you found and fixed some that I found also, we will see what GHA says about this commit.

-------------

PR: https://git.openjdk.org/jdk/pull/12323

From sjohanss at openjdk.org  Wed Mar 15 13:23:25 2023
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Wed, 15 Mar 2023 13:23:25 GMT
Subject: RFR: 8191565: Last-ditch Full GC should also move humongous
 objects [v2]
In-Reply-To: <zBpBWEG2BUS8-FIZ1V-JRiq1x8yifAGRQL11KSZSilo=.eaa8371b-a3cf-4acc-a7d6-28e9d8945444@github.com>
References: <58l059EvQI6HNQyjUYSGYEWt6x-c1yvtmfX1QWfinH8=.87517ba1-ec81-4b9f-a41b-b05c8d33cf3d@github.com>
 <zBpBWEG2BUS8-FIZ1V-JRiq1x8yifAGRQL11KSZSilo=.eaa8371b-a3cf-4acc-a7d6-28e9d8945444@github.com>
Message-ID: <W7lAVhYnvm947AxZKkV2YFm7Yet32LACIXupJOToTqM=.c0c84d86-d3c4-416d-939b-24867a257922@github.com>

On Mon, 6 Mar 2023 10:22:27 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi All,
>> 
>> Please review this change to move humongous regions during the Last-Ditch full gc ( on `do_maximal_compaction`). This change will enable G1 to avoid encountering Out-Of-Memory errors that may occur due to the fragmentation of memory regions caused by the allocation of large memory blocks.
>> 
>> Here's how it works: At the end of `phase2_prepare_compaction`, G1 performs a serial compaction process for regular objects, which results in the heap being divided into two parts. The first part is a densely populated prefix that contains all the regular objects that have been moved. The second part consists of the remaining heap space, which may contain free regions, uncommitted regions, and regions that are not compacting. By moving/compacting the humongous objects in the second part of the heap closer to the dense prefix, G1 reduces the region fragmentation and avoids running into OOM errors.
>> 
>> We have enabled for G1 the Jtreg test that was previously used only for Shenandoah to test such workload. 
>> 
>> Testing: Tier 1-3
>
> Ivan Walulya has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Refactor resetting humongous metadata
>  - Thomas review

Overall it looks good, just a couple of small comments below. 

Many thanks for taking on this change.

src/hotspot/share/gc/g1/g1CollectedHeap.hpp line 609:

> 607:   inline void register_humongous_candidate_region_with_region_attr(uint index);
> 608: 
> 609:   void reset_humongous_metadata(HeapRegion* first_hr,

I would go with just `set_humongous_metadata(...)`

src/hotspot/share/gc/g1/g1FullGCCompactionPoint.hpp line 47:

> 45:   void switch_region();
> 46:   HeapRegion* next_region();
> 47:   Pair<uint, uint> find_contiguous_before(HeapRegion* hr, uint num_regions);

I think we can skip returning a `Pair` here. The second value is only used to check if we found any range and instead we could use something like `UINT_MAX` or the max number of regions to mark that.

-------------

Changes requested by sjohanss (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12830

From jwaters at openjdk.org  Wed Mar 15 13:38:45 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 15 Mar 2023 13:38:45 GMT
Subject: Integrated: 8301308: Remove version conditionalization for gcc/clang
 PRAGMA_DIAG_PUSH/POP
In-Reply-To: <9BP1enfxaU7HVyJEL27oCu9kMC45tWMkeUcqg1Xr6zE=.4a774982-1c1a-44ed-8862-2c300e79f458@github.com>
References: <9BP1enfxaU7HVyJEL27oCu9kMC45tWMkeUcqg1Xr6zE=.4a774982-1c1a-44ed-8862-2c300e79f458@github.com>
Message-ID: <2ypkTuVbu1byxtgFpO2Yb8xmYMn_aHcgKnYD_XBdyN0=.ff452911-03b1-4396-adfd-51ac5e5e8f62@github.com>

On Tue, 14 Mar 2023 17:51:12 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> As of now we at minimum require clang 3.5 and gcc 6 to compile the Java Platform, the version checks for gcc/clang here are for whether clang is either version 4 and above, or has a minor version higher than 3.1, and for gcc either a major version higher than 4 or minor version above 4.6. Now these will always pass, so they can be removed. Also changes the macro definition location to match Visual C++ and look neater

This pull request has now been integrated.

Changeset: 3d77e217
Author:    Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3d77e217b2b97d2c290c50c4dc55987ecc13eb79
Stats:     13 lines in 1 file changed: 3 ins; 10 del; 0 mod

8301308: Remove version conditionalization for gcc/clang PRAGMA_DIAG_PUSH/POP

Reviewed-by: kbarrett, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/13025

From duke at openjdk.org  Wed Mar 15 13:39:10 2023
From: duke at openjdk.org (Afshin Zafari)
Date: Wed, 15 Mar 2023 13:39:10 GMT
Subject: RFR: 8292059: Do not inline InstanceKlass::allocate_instance()
 [v7]
In-Reply-To: <ZSJBTzuC4wVuKdqSLLTgw4Pds2oX5wah0Ub6rFux_tc=.c4e2ae89-cadb-4ccd-9eee-034583cf7200@github.com>
References: <ZSJBTzuC4wVuKdqSLLTgw4Pds2oX5wah0Ub6rFux_tc=.c4e2ae89-cadb-4ccd-9eee-034583cf7200@github.com>
Message-ID: <CsNJOC_Q5cgJq-a-dqqWo-E9ObvSRmXO61XOUFdya7k=.e0004a11-6642-44ff-96a5-ada39c1259a6@github.com>

> The inline and not-inline versions of the method is tested to compare the performance difference. 
> ### Test
> `make test TEST=micro:Capture0.lambda_01 MICRO="VM_OPTIONS=-XX:TieredStopAtLevel=1" `

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  8292059: Do not inline InstanceKlass::allocate_instance()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12782/files
  - new: https://git.openjdk.org/jdk/pull/12782/files/4165cab8..da1a1331

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12782&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12782&range=05-06

  Stats: 2 lines in 2 files changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12782.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12782/head:pull/12782

PR: https://git.openjdk.org/jdk/pull/12782

From fparain at openjdk.org  Wed Mar 15 13:45:46 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 15 Mar 2023 13:45:46 GMT
Subject: RFR: 8292818: replace 96-bit representation for field metadata
 with variable-sized streams [v4]
In-Reply-To: <ixB_BHQBP1DbXZf71LHAYfwAI0hoCQ9TdnlsOdD3sFw=.30eb2928-111d-44c9-bf53-61288e450fe4@github.com>
References: <vdiacOO3JUyy4sWGkDXNBMUT7cG3XYe79mOvYru9uMM=.9c556675-7ffd-4c09-a428-6d64dffef209@github.com>
 <hAGW4he3pjU6G9IuyygughaiDUL9vKNHzKcURWD4tSI=.b67e5661-9978-4d9d-850e-0a6399de5a64@github.com>
 <ixB_BHQBP1DbXZf71LHAYfwAI0hoCQ9TdnlsOdD3sFw=.30eb2928-111d-44c9-bf53-61288e450fe4@github.com>
Message-ID: <t4e3nUFKyUnnCpw-MZHIXMcgu8OlLyIDoslG-DqcZQI=.0fb2d38b-6e76-4c3c-af8c-52a0ab7e9275@github.com>

On Tue, 14 Mar 2023 01:25:01 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixes includes and style
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Field.java line 75:
> 
>> 73:     int initialValueIndex;
>> 74:     int genericSignatureIndex;
>> 75:     int contendedGroup;
> 
> It seems that these should all be shorts. All the getter methods are casting them to short.

Indexes in the constant pool are unsigned shorts, but Java shorts are signed, using ints is the simplest way to store those indexes.

> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java line 108:
> 
>> 106:     CLASS_STATE_INITIALIZATION_ERROR = db.lookupIntConstant("InstanceKlass::initialization_error").intValue();
>> 107:     // We need a new fieldsCache each time we attach.
>> 108:     fieldsCache = new HashMap<Address, Field[]>();
> 
> This should probably be a WeakHashMap. I tried it and it seems to work (or at least didn't cause any problems). However, when doing a heap dump I didn't notice the table being any smaller on exit when it was made weak, even though there were numerous GC's while dumping the heap.
> 
> The `<key>` is the Address of the hotspot InstanceKlass instance, and this Address is referenced by the SA InstanceKlass mirror. So theoretically when the reference to the mirror goes way, then the cache entry can be cleared.

I've changed the map to a WeakHashMap and didn't see any issue during testing. But I didn't measure footprint.

> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java line 325:
> 
>> 323: 
>> 324:   public int getFieldOffset(int index) {
>> 325:     return (int)getField(index).getOffset();
> 
> Cast to int is not needed

Other APIs (like MetadaField) are using longs to pass offsets, doing a cast here is less disruptive than changing all the other APIs.

-------------

PR: https://git.openjdk.org/jdk/pull/12855

From duke at openjdk.org  Wed Mar 15 13:46:42 2023
From: duke at openjdk.org (Afshin Zafari)
Date: Wed, 15 Mar 2023 13:46:42 GMT
Subject: RFR: 8292059: Do not inline InstanceKlass::allocate_instance()
 [v7]
In-Reply-To: <ncRMdKbOHmpBs5xlk2bFSQZWG4xClw6BRJbHcMvfQgo=.3dbab624-82e5-434a-9fb3-289b84d98957@github.com>
References: <ZSJBTzuC4wVuKdqSLLTgw4Pds2oX5wah0Ub6rFux_tc=.c4e2ae89-cadb-4ccd-9eee-034583cf7200@github.com>
 <9ZXi9uNa5ETIhldKLCDAYojtXTGEg-5EexLwHNE2zhI=.026815b3-3117-4184-be4c-5fdf42c2655f@github.com>
 <1W22QvJKaoJVRI5Wrx6DZEizGOxHsiSAEoLkHsCauQY=.6e934949-d854-49f8-9e1e-5786c0d04c8f@github.com>
 <AIPEEiYAZJ3EE7PAqbRFSx4EMFCYm5bQAMmhWtYICrk=.abcfd832-11b6-4cdb-8d51-46c7987ca13c@github.com>
 <ncRMdKbOHmpBs5xlk2bFSQZWG4xClw6BRJbHcMvfQgo=.3dbab624-82e5-434a-9fb3-289b84d98957@github.com>
Message-ID: <czHI71zv5FCOg5vUxYKKxXmAB6iFk51yK2YlD44kFp8=.d1b0aa9d-dd76-493d-95b9-60e60f71375d@github.com>

On Wed, 15 Mar 2023 12:51:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Good.  I think devirtualizer.inline.hpp is used by the GC inlined functions so should remain here.
>
> Sorry for being confusing before.  My comment was that you should remove #includes that aren't directly referenced by this .inline.hpp file.  I see that you've done this now, but do you need classfile/vmSymbols.hpp here?  I don't see it.

I mis-interpreted the required changes.
It is not needed here, and moved to `jvmtiEnvBase.cpp`.

-------------

PR: https://git.openjdk.org/jdk/pull/12782

From kvn at openjdk.org  Wed Mar 15 13:51:30 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 15 Mar 2023 13:51:30 GMT
Subject: RFR: JDK-8301498: Replace NULL with nullptr in cpu/x86 [v3]
In-Reply-To: <Dt5DVW6D3E3khwTaDNTy3kcrxJmv_fEK37iXonS06C8=.ab98f698-1dc3-4d64-b57a-cb69493a38a0@github.com>
References: <AB1094dam2aXNm_hav09Ium0jqJUCJE0hmJ4GfljA5M=.4e8e0845-20d5-45bf-bf2e-1d23ed8ef9f0@github.com>
 <Dt5DVW6D3E3khwTaDNTy3kcrxJmv_fEK37iXonS06C8=.ab98f698-1dc3-4d64-b57a-cb69493a38a0@github.com>
Message-ID: <DIelpys9YM_CU-qndcwEeud_WQFr9PetdXwXqmok_3E=.7eab0d37-793e-4e71-ab20-870641e3903e@github.com>

On Wed, 15 Mar 2023 11:09:25 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory cpu/x86. Unfortunately the script that does the change isn't perfect, and so we
>> need to comb through these manually to make sure nothing has gone wrong. I also review these changes but things slip past my eyes sometimes.
>> 
>> Here are some typical things to look out for:
>> 
>> 1. No changes but copyright header changed (probably because I reverted some changes but forgot the copyright).
>> 2. Macros having their NULL changed to nullptr, these are added to the script when I find them. They should be NULL.
>> 3. nullptr in comments and logs. We try to use lower case "null" in these cases as it reads better. An exception is made when code expressions are in a comment.
>> 
>> An example of this:
>> 
>> ```c++
>> // This function returns null
>> void* ret_null();
>> // This function returns true if *x == nullptr
>> bool is_nullptr(void** x);
>> 
>> 
>> Note how `nullptr` participates in a code expression here, we really are talking about the specific value `nullptr`.
>> 
>> Thanks!
>
> Johan Sj?len has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Fix vnkozlov's suggestions
>  - Merge remote-tracking branch 'origin/master' into JDK-8301498
>  - Some more fixes
>  - Fixes
>  -  Replace NULL with nullptr in cpu/x86

Looks good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12326

From coleenp at openjdk.org  Wed Mar 15 14:12:32 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 15 Mar 2023 14:12:32 GMT
Subject: RFR: 8292059: Do not inline InstanceKlass::allocate_instance()
 [v7]
In-Reply-To: <CsNJOC_Q5cgJq-a-dqqWo-E9ObvSRmXO61XOUFdya7k=.e0004a11-6642-44ff-96a5-ada39c1259a6@github.com>
References: <ZSJBTzuC4wVuKdqSLLTgw4Pds2oX5wah0Ub6rFux_tc=.c4e2ae89-cadb-4ccd-9eee-034583cf7200@github.com>
 <CsNJOC_Q5cgJq-a-dqqWo-E9ObvSRmXO61XOUFdya7k=.e0004a11-6642-44ff-96a5-ada39c1259a6@github.com>
Message-ID: <4R7Gp-JUViFk-Pu3b7DwQ_hAhZavttNs1cBt1CnGYsQ=.62a967e0-1626-4083-b6b0-73e61e0eade1@github.com>

On Wed, 15 Mar 2023 13:39:10 GMT, Afshin Zafari <duke at openjdk.org> wrote:

>> The inline and not-inline versions of the method is tested to compare the performance difference. 
>> ### Test
>> `make test TEST=micro:Capture0.lambda_01 MICRO="VM_OPTIONS=-XX:TieredStopAtLevel=1" `
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8292059: Do not inline InstanceKlass::allocate_instance()

Great.  This looks good.  We'll wait for GHA and integrate.

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12782

From rrich at openjdk.org  Wed Mar 15 14:15:20 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 15 Mar 2023 14:15:20 GMT
Subject: RFR: 8296440: Remove Method* handling from
 cleanup_inline_caches_impl
In-Reply-To: <gRv9sYskW0fD2m_7j1gt39Fl0XLv9vha7Mdw_X78WsU=.a8fa6c8f-a5fa-447a-a430-a659fc41b8bb@github.com>
References: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
 <gRv9sYskW0fD2m_7j1gt39Fl0XLv9vha7Mdw_X78WsU=.a8fa6c8f-a5fa-447a-a430-a659fc41b8bb@github.com>
Message-ID: <iKisWt3m7U4L53PrPds-BAmtrxLRUawkWPBgZt_3WxM=.7e4a4e32-b1ad-42e1-84a3-3fbb02d8b393@github.com>

On Wed, 15 Mar 2023 10:48:58 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Impressive that we can get rid of so much complicated code! Looks correct to me. 

Thanks for reviewing, Martin.

> Is the check fast enough to do it on every resolution?

I though so. The easy cases where the callee is from a permanent loader or where caller and callee have the same holder oop should be common.
I'm not sure how to quantify the performance effect though.
I wouldn't object to turn it into an assertion if requested.

-------------

PR: https://git.openjdk.org/jdk/pull/12802

From mdoerr at openjdk.org  Wed Mar 15 15:23:42 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 15 Mar 2023 15:23:42 GMT
Subject: RFR: 8296440: Remove Method* handling from
 cleanup_inline_caches_impl
In-Reply-To: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
References: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
Message-ID: <-3WO0jPxKC1CTVEB1ioqIgLFt5MRFE7zPf4pJw5Erls=.0d4c243c-eefc-4450-9df2-64a927e509eb@github.com>

On Wed, 1 Mar 2023 11:07:36 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> This PR replaces cleaning of static stubs in CompiledMethod::cleanup_inline_caches_impl() with a guarantee that it is actually not needed because the holder of the embedded target Method* is alive if the caller nmethod is not unloading.
> 
> The holder of the target Method* has to be alive because it is reachable from the caller nmethod's oop pool. This is checked by `check_path_to_callee()` when a statically bound call gets resolved.
> 
> C2i entry barriers can be removed for the same reason.
> 
> Testing:
> 
> Many rounds in our CI testing which includes most JCK and JTREG tests, Renaissance benchmark and SAP specific tests with fastdebug and release builds on the standard platforms plus PPC64.
> 
> I've also done tier1 and tier2 tests with -XX:-Inline and tier1 tests with ZGC.
> 
> I've started hotspot and jdk tier1 tests with -Xcomp. They were not finished when I stopped them after 24h.

I guess that the benchmarks don't show any impact. If so, I'm ok with your version. If there are concerns, it would be possible to make it switchable by a diagnostic flag. But I'd still keep it enabled by default to get maximum test coverage.

-------------

PR: https://git.openjdk.org/jdk/pull/12802

From kvn at openjdk.org  Wed Mar 15 15:38:00 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 15 Mar 2023 15:38:00 GMT
Subject: RFR: 8296440: Remove Method* handling from
 cleanup_inline_caches_impl
In-Reply-To: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
References: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
Message-ID: <pPSvNOeAenW50K5j62cqlxOZN8V5AfZvwu_tO4GlR9A=.6500aa0d-b6ca-4f2b-a4fb-fa5b20860072@github.com>

On Wed, 1 Mar 2023 11:07:36 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> This PR replaces cleaning of static stubs in CompiledMethod::cleanup_inline_caches_impl() with a guarantee that it is actually not needed because the holder of the embedded target Method* is alive if the caller nmethod is not unloading.
> 
> The holder of the target Method* has to be alive because it is reachable from the caller nmethod's oop pool. This is checked by `check_path_to_callee()` when a statically bound call gets resolved.
> 
> C2i entry barriers can be removed for the same reason.
> 
> Testing:
> 
> Many rounds in our CI testing which includes most JCK and JTREG tests, Renaissance benchmark and SAP specific tests with fastdebug and release builds on the standard platforms plus PPC64.
> 
> I've also done tier1 and tier2 tests with -XX:-Inline and tier1 tests with ZGC.
> 
> I've started hotspot and jdk tier1 tests with -Xcomp. They were not finished when I stopped them after 24h.

Let me test it.

I think `check_path_to_callee` should be done only in debug VM. It is verification code.
But for **pre-integration** testing it is fine to have it as guarantee.

-------------

PR: https://git.openjdk.org/jdk/pull/12802

From matsaave at openjdk.org  Wed Mar 15 15:38:10 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 15 Mar 2023 15:38:10 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v4]
In-Reply-To: <uEs7S3I5zuveQ-eXk6Lr4ik6h51i_UxSfonDyj_x0Rg=.b1a01133-dc85-444a-a3d7-33788689542c@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <NAlT40fGcwSR_s4NrUvvFgwZC4JnCrISl2K5uoFt7YQ=.20613218-a79b-4b64-83ba-ea22b54f8d6e@github.com>
 <uEs7S3I5zuveQ-eXk6Lr4ik6h51i_UxSfonDyj_x0Rg=.b1a01133-dc85-444a-a3d7-33788689542c@github.com>
Message-ID: <ppRwXXfV2UrJue0kB24LifGYpmINJW-X1qTsfwSsBZk=.4ebc104f-4e7e-4a51-8f48-434d73748f48@github.com>

On Tue, 14 Mar 2023 23:29:17 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   RISCV port update
>
> src/hotspot/share/interpreter/bootstrapInfo.cpp line 234:
> 
>> 232:   if (_indy_index > -1) {
>> 233:     os::snprintf_checked(what, sizeof(what), "indy#%d", _indy_index);
>> 234:   }
> 
> Since the `else` case doesn?t have braces, maybe omit the braces for this case as well?

The if statements below use braces so I think it would be better to add braces to the else case.

-------------

PR: https://git.openjdk.org/jdk/pull/12778

From rrich at openjdk.org  Wed Mar 15 15:41:13 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 15 Mar 2023 15:41:13 GMT
Subject: RFR: 8296440: Remove Method* handling from
 cleanup_inline_caches_impl
In-Reply-To: <pPSvNOeAenW50K5j62cqlxOZN8V5AfZvwu_tO4GlR9A=.6500aa0d-b6ca-4f2b-a4fb-fa5b20860072@github.com>
References: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
 <pPSvNOeAenW50K5j62cqlxOZN8V5AfZvwu_tO4GlR9A=.6500aa0d-b6ca-4f2b-a4fb-fa5b20860072@github.com>
Message-ID: <Eh4zv4TTY69nHQRrCjKBWvV-vdDwi4Ur1xvr4FGOP1s=.66a9540a-e356-45cd-811d-3ebe2eea762c@github.com>

On Wed, 15 Mar 2023 15:34:48 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Let me test it.
> 
> I think `check_path_to_callee` should be done only in debug VM. It is verification code. But for **pre-integration** testing it is fine to have it as guarantee.

Thanks for testing! I'll make the test dependent on ASSERT afterwards.

-------------

PR: https://git.openjdk.org/jdk/pull/12802

From fparain at openjdk.org  Wed Mar 15 15:41:17 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 15 Mar 2023 15:41:17 GMT
Subject: RFR: 8292818: replace 96-bit representation for field metadata
 with variable-sized streams [v5]
In-Reply-To: <vdiacOO3JUyy4sWGkDXNBMUT7cG3XYe79mOvYru9uMM=.9c556675-7ffd-4c09-a428-6d64dffef209@github.com>
References: <vdiacOO3JUyy4sWGkDXNBMUT7cG3XYe79mOvYru9uMM=.9c556675-7ffd-4c09-a428-6d64dffef209@github.com>
Message-ID: <bZJIThP0PV4ic1UBs4eXRqgBLhpNER813xmY8iiOqgY=.7a83c2d2-24e5-472b-87af-26ca6d8b90bf@github.com>

> Please review this change re-implementing the FieldInfo data structure.
> 
> The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency.
> 
> The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information).
> 
> More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818
> 
> Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM.
> 
> The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format.
> 
> Tested with mach5, tier 1 to 7.
> 
> Thank you.

Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:

  SA and JVMCI fixes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12855/files
  - new: https://git.openjdk.org/jdk/pull/12855/files/12b4f1b4..f81337f7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12855&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12855&range=03-04

  Stats: 130 lines in 13 files changed: 14 ins; 46 del; 70 mod
  Patch: https://git.openjdk.org/jdk/pull/12855.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12855/head:pull/12855

PR: https://git.openjdk.org/jdk/pull/12855

From matsaave at openjdk.org  Wed Mar 15 16:08:21 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 15 Mar 2023 16:08:21 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v3]
In-Reply-To: <C0Ps3NkEurVkM1bRDTlkCiZ58qvo0bP7pF79PKbZi0c=.a75791eb-1987-4c22-b0e5-040d0240fd4a@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <vR9DLx3Oi7S-M_8Qu-d0k6DfZTqfamB4AYt-JLeErvk=.0cf5358f-71fe-4956-8683-1ceae15de148@github.com>
 <C0Ps3NkEurVkM1bRDTlkCiZ58qvo0bP7pF79PKbZi0c=.a75791eb-1987-4c22-b0e5-040d0240fd4a@github.com>
Message-ID: <M_tK0nXVBMNdVc5r2M5oPboGePNwyA5MPmx71J5LnT4=.8fa18963-20f0-4966-8575-0b4be09d599d@github.com>

On Tue, 14 Mar 2023 15:39:39 GMT, Gui Cao <gcao at openjdk.org> wrote:

>> Matias Saavedra Silva 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:
>> 
>>  - Typo in comment
>>  - Merge branch 'master' into resolvedIndyEntry_8301995
>>  - Interpreter optimization and comments
>>  - PPC and RISCV port
>>  - 8301995: Move invokedynamic resolution information out of the cpCache
>
> src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1843:
> 
>> 1841:   ldr(cache, Address(rcpool, in_bytes(ConstantPoolCache::invokedynamic_entries_offset())));
>> 1842:   // Scale the index to be the entry index * sizeof(ResolvedInvokeDynamicInfo)
>> 1843:   mov(tmp, sizeof(ResolvedIndyEntry));
> 
> The tmp register is not used here, is it redundant?

Right, the tmp register is not needed anymore thanks to the mul to shift optimization. Note that shifting will not be possible on 32-bit systems due to the size of ResolvedIndyEntry not being a power of two. This optimization only works on 64 bit builds.

-------------

PR: https://git.openjdk.org/jdk/pull/12778

From matsaave at openjdk.org  Wed Mar 15 16:35:22 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 15 Mar 2023 16:35:22 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v5]
In-Reply-To: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
Message-ID: <rGzWioPaPqwx6OUC1aRZAgcv-p_ZAKL_bj2KSV9bDZ8=.46efa355-e722-4489-8d02-6ebed7af692e@github.com>

> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
> 
> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
> 
> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
> 
> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
> 
> This change supports the following platforms: x86, aarch64, PPC, and RISCV

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  Fixed indentation and other comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12778/files
  - new: https://git.openjdk.org/jdk/pull/12778/files/db892223..415e7116

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12778&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12778&range=03-04

  Stats: 71 lines in 9 files changed: 1 ins; 3 del; 67 mod
  Patch: https://git.openjdk.org/jdk/pull/12778.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12778/head:pull/12778

PR: https://git.openjdk.org/jdk/pull/12778

From cjplummer at openjdk.org  Wed Mar 15 16:41:16 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 15 Mar 2023 16:41:16 GMT
Subject: RFR: 8292818: replace 96-bit representation for field metadata
 with variable-sized streams [v5]
In-Reply-To: <bZJIThP0PV4ic1UBs4eXRqgBLhpNER813xmY8iiOqgY=.7a83c2d2-24e5-472b-87af-26ca6d8b90bf@github.com>
References: <vdiacOO3JUyy4sWGkDXNBMUT7cG3XYe79mOvYru9uMM=.9c556675-7ffd-4c09-a428-6d64dffef209@github.com>
 <bZJIThP0PV4ic1UBs4eXRqgBLhpNER813xmY8iiOqgY=.7a83c2d2-24e5-472b-87af-26ca6d8b90bf@github.com>
Message-ID: <_thEXXKYB00W5Mmg8hGRKMLqo6vog84sjtp2Mqf2wqk=.8f5a76a6-30c5-4a05-ae7a-753e1d70ddee@github.com>

On Wed, 15 Mar 2023 15:41:17 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Please review this change re-implementing the FieldInfo data structure.
>> 
>> The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency.
>> 
>> The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information).
>> 
>> More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818
>> 
>> Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM.
>> 
>> The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format.
>> 
>> Tested with mach5, tier 1 to 7.
>> 
>> Thank you.
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   SA and JVMCI fixes

SA changes looks good. Thanks for taking care of this!

-------------

Marked as reviewed by cjplummer (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12855

From chagedorn at openjdk.org  Wed Mar 15 16:47:06 2023
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 15 Mar 2023 16:47:06 GMT
Subject: RFR: 8302073: Specifying OnError handler prevents WatcherThread to
 break a deadlock in report_and_die()
In-Reply-To: <rpWZDbFeVeiHDelrT7jAqzs_ngRx92GTGyGLsask2Vk=.bf26d4e4-73e8-4b14-8cd9-d44f40c4790e@github.com>
References: <nTD9cu_uj-X-ML_g-kbPrccPTlk5NGX9iV5TLXxOpbA=.2cea728c-6dbe-41a5-b379-a75c4ebc85e0@github.com>
 <k9wKuvOyzPUxNzE_aHGg_Abr5gckbriofiHDuMmhfps=.51b99d4a-8f1f-4134-8121-3738f2b13e41@github.com>
 <G-ReJaBrJTUBgWUmcE4eoqXQrtHCLPMSL7nQyom4QIM=.77438a77-60c9-4dc1-b811-7a71249d4358@github.com>
 <0jlQWouDE0tJ-ysn7WFYArqrJwHFQ-hhsZKKRGdVhmU=.95c4ceb0-9b8e-4c9b-9029-473626fb5a6b@github.com>
 <ENv94gS1Al_g-WlkPImshjot7HVPKvid7g7ft8gxQNk=.1e5aa0f3-6bfc-4f9a-8df3-7f2c7f094c20@github.com>
 <rpWZDbFeVeiHDelrT7jAqzs_ngRx92GTGyGLsask2Vk=.bf26d4e4-73e8-4b14-8cd9-d44f40c4790e@github.com>
Message-ID: <9a2KV9P9iP8EOEDuqpxePREsXK-02Rw6p_QHmfm86bg=.5ac9b48f-e3c6-461c-b66c-437b21f34a16@github.com>

On Tue, 14 Mar 2023 18:13:11 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>>> Decoder, in particular, should not use malloc. Therefore I also opened https://bugs.openjdk.org/browse/JDK-8303862 to track that. I won't have time to work on that. I have the hope that maybe @chhagedorn can :-) ?
>> 
>> Does any of our current allocation strategies allow the usage of a custom scratch buffer (i.e. the error reporting scratch buffer) as memory location? If not, it could get more complicated. I could still try to tackle that but I'm not sure if I have the necessary knowledge in that area.
>
>> > > Decoder, in particular, should not use malloc. Therefore I also opened https://bugs.openjdk.org/browse/JDK-8303862 to track that. I won't have time to work on that. I have the hope that maybe @chhagedorn can :-) ?
>> > 
>> > 
>> > Does any of our current allocation strategies allow the usage of a custom scratch buffer (i.e. the error reporting scratch buffer) as memory location? If not, it could get more complicated. I could still try to tackle that but I'm not sure if I have the necessary knowledge in that area.
>> 
>> What we usually do for these kind of problems is to pass the scratch buffer via argument to the processing functions. And make that use either it or, if NULL was passes, allocate its own thing.
>> 
>> Another way to do this would be to add a scratch buffer pointer to Thread.
>> 
>> A third way to do this (I had been experimenting with it) would be to pre-allocate a scratch buffer, and once error handling began, to use that inside os::malloc. That is the most involved solution, though, and I'm not particularly fond of it. I know many reviewers would hate it, too :-)
> 
> Thanks for the summary. Could we also use "placement new" to use the scratch buffer to allocate and create objects to? For example, when creating a decoder, to use something like
> 
> decoder = new(scratch_buffer) ElfDecoder();
> 
> here:
> https://github.com/openjdk/jdk/blob/4e631fa43fd821846c12ae2177360c44cf770766/src/hotspot/share/utilities/decoder.cpp#L62-L70
> Then we can still utilize polymorphism. But then `AbstractDecoder` needs to be something else than `CHeapObj`. And of course, this approach also needs careful checking that a new object actually fits into the provided scratch buffer. On top of that, it gets more complicated when we want to keep multiple objects alive in the same scratch buffer. So, I'm not sure if this approach is feasible, though.

> > > > > Decoder, in particular, should not use malloc. Therefore I also opened https://bugs.openjdk.org/browse/JDK-8303862 to track that. I won't have time to work on that. I have the hope that maybe @chhagedorn can :-) ?
> > > > 
> > > > 
> > > > Does any of our current allocation strategies allow the usage of a custom scratch buffer (i.e. the error reporting scratch buffer) as memory location? If not, it could get more complicated. I could still try to tackle that but I'm not sure if I have the necessary knowledge in that area.
> > > 
> > > 
> > > What we usually do for these kind of problems is to pass the scratch buffer via argument to the processing functions. And make that use either it or, if NULL was passes, allocate its own thing.
> > > Another way to do this would be to add a scratch buffer pointer to Thread.
> > > A third way to do this (I had been experimenting with it) would be to pre-allocate a scratch buffer, and once error handling began, to use that inside os::malloc. That is the most involved solution, though, and I'm not particularly fond of it. I know many reviewers would hate it, too :-)
> > 
> > 
> > Thanks for the summary. Could we also use "placement new" to use the scratch buffer to allocate and create objects to? For example, when creating a decoder, to use something like
> > ```
> > decoder = new(scratch_buffer) ElfDecoder();
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > here:
> > https://github.com/openjdk/jdk/blob/4e631fa43fd821846c12ae2177360c44cf770766/src/hotspot/share/utilities/decoder.cpp#L62-L70
> > 
> > Then we can still utilize polymorphism. But then `AbstractDecoder` needs to be something else than `CHeapObj`. And of course, this approach also needs careful checking that a new object actually fits into the provided scratch buffer. On top of that, it gets more complicated when we want to keep multiple objects alive in the same scratch buffer. So, I'm not sure if this approach is feasible, though.
> 
> Its possible to use placement new, and also to place several objects like this; but I realize now the scratch buffer might be too small.

Yes, that might be the case.

> 
> I need to think this through a bit. Maybe providing a pre-allocated buffer for os::malloc would be the right thing to do.

That might be better and it sounds easier to do instead of going with a separate allocation strategy with placement new using the scratch buffer.

-------------

PR: https://git.openjdk.org/jdk/pull/12925

From rrich at openjdk.org  Wed Mar 15 16:53:40 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 15 Mar 2023 16:53:40 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v2]
In-Reply-To: <pkUIkI7pd0hiYzrop0bDcwdHCZrerzopRh0d7n3-Jpw=.3e18cbdc-6eae-4e30-8442-b3f0d10d5b80@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <-Kj1YJ_nRa4nJtaxg3UR8uWhde6vIG1Jl-FFakGnHy4=.a41c6149-912b-4a66-8b1e-634bd27cdebb@github.com>
 <VQ34HqjCPRfc1b8v9BW1nm5V-qQaWN11vctJw3c10ck=.57c1c735-b453-42c2-a7c1-cc1049957af7@github.com>
 <pkUIkI7pd0hiYzrop0bDcwdHCZrerzopRh0d7n3-Jpw=.3e18cbdc-6eae-4e30-8442-b3f0d10d5b80@github.com>
Message-ID: <YVYskVUMDbAEEeYA6xexYZLv6AIOq--twRzNXkcPYf4=.badd6756-bb64-41ff-b8d9-76b2323b26b7@github.com>

On Tue, 14 Mar 2023 17:01:20 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> > @matias9927 can I ask you to merge master? There seem to be conflicts (at least I see a message "This branch has conflicts that must be resolved"). I'd like to give the change a spin in our CI testing. This requires that it can be applied on master.
> 
> I saw that merge error but nothing came up when I tried to merge locally. The branch is updated nonetheless, so you should be able to test it now @reinrich !

Thanks. The testing didn't reveal anything.

-------------

PR: https://git.openjdk.org/jdk/pull/12778

From iwalulya at openjdk.org  Wed Mar 15 17:00:38 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Wed, 15 Mar 2023 17:00:38 GMT
Subject: RFR: 8191565: Last-ditch Full GC should also move humongous
 objects [v3]
In-Reply-To: <58l059EvQI6HNQyjUYSGYEWt6x-c1yvtmfX1QWfinH8=.87517ba1-ec81-4b9f-a41b-b05c8d33cf3d@github.com>
References: <58l059EvQI6HNQyjUYSGYEWt6x-c1yvtmfX1QWfinH8=.87517ba1-ec81-4b9f-a41b-b05c8d33cf3d@github.com>
Message-ID: <oyYJpAchjojCr_V6EwjhNcTAdjGzjWPFw-SegZofqZs=.bba1fc78-6fcc-4869-ae50-1beb83c16370@github.com>

> Hi All,
> 
> Please review this change to move humongous regions during the Last-Ditch full gc ( on `do_maximal_compaction`). This change will enable G1 to avoid encountering Out-Of-Memory errors that may occur due to the fragmentation of memory regions caused by the allocation of large memory blocks.
> 
> Here's how it works: At the end of `phase2_prepare_compaction`, G1 performs a serial compaction process for regular objects, which results in the heap being divided into two parts. The first part is a densely populated prefix that contains all the regular objects that have been moved. The second part consists of the remaining heap space, which may contain free regions, uncommitted regions, and regions that are not compacting. By moving/compacting the humongous objects in the second part of the heap closer to the dense prefix, G1 reduces the region fragmentation and avoids running into OOM errors.
> 
> We have enabled for G1 the Jtreg test that was previously used only for Shenandoah to test such workload. 
> 
> Testing: Tier 1-3

Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:

  StefanJ review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12830/files
  - new: https://git.openjdk.org/jdk/pull/12830/files/6f8dd514..ac6bb065

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12830&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12830&range=01-02

  Stats: 23 lines in 5 files changed: 0 ins; 2 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/12830.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12830/head:pull/12830

PR: https://git.openjdk.org/jdk/pull/12830

From jvernee at openjdk.org  Wed Mar 15 17:17:51 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 15 Mar 2023 17:17:51 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v16]
In-Reply-To: <c5UYe1zFGgndb5SQZ71TgGXsizWiNnhiosHWm5xiVpU=.032bb845-05ad-4393-83cd-2a111dc55c85@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <c5UYe1zFGgndb5SQZ71TgGXsizWiNnhiosHWm5xiVpU=.032bb845-05ad-4393-83cd-2a111dc55c85@github.com>
Message-ID: <XyTtc5ZwtYwQE-jpGKyxS2NKIg7UI8ZMD3XAVlTh4s8=.0764f593-b76b-48df-928b-baffd42b51ca@github.com>

On Tue, 14 Mar 2023 22:30:22 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
>> 
>> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
>> 
>> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
>> 
>> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Will get addressed separately: [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
>> 
>> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
>> 
>> I had to make changes to shared code and code for other platforms:
>> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
>> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
>> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
>> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
>> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix storing 32 bit integers into Java frames. Enable TestArrayStructs.

src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/TypeClass.java line 2:

> 1: /*
> 2:  * Copyright (c) 2022, 2023 Oracle and/or its affiliates. All rights reserved.

The copyright header here is missing a comma after the second year:
Suggestion:

 * Copyright (c) 2022, 2023, Oracle and/or its affiliates. All rights reserved.

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From cslucas at openjdk.org  Wed Mar 15 17:20:47 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 15 Mar 2023 17:20:47 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v2]
In-Reply-To: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
Message-ID: <8d3LAUIIFVAJIXyrV2YafqAtAe6yiSPUS5THd2VynTk=.006e4cf8-90fe-43ea-8bb3-bbda4d3244f9@github.com>

> Can I please get reviews for this PR to add support for the rematerialization of scalar-replaced objects that participate in allocation merges?
> 
> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested.
> 
> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N:
> 
> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png)
> 
> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1:
> 
> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png)
> 
> This PR adds support scalar replacing allocations participating in merges that are used *only* as debug information in SafePointNode and its subclasses. Although there is a performance benefit in doing scalar replacement in this scenario only, the goal of this PR is mainly to add infrastructure to support the rematerialization of SR objects participating in merges. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP, Load+AddP, primarily) subsequently.
> 
> The approach I used is pretty straightforward. It consists basically in: 1) Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a new Class to support rematerialization of SR objects part of merges; 3) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 4) Patch C2 to generate unique types for SR objects participating in allocation merges used only as debug information.
> 
> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression that might be related. I also tested with several applications and didn't see any failure.

Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge master
 - Add support for rematerializing scalar replaced objects participating in allocation merges

-------------

Changes: https://git.openjdk.org/jdk/pull/12897/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=01
  Stats: 1803 lines in 18 files changed: 1653 ins; 9 del; 141 mod
  Patch: https://git.openjdk.org/jdk/pull/12897.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12897/head:pull/12897

PR: https://git.openjdk.org/jdk/pull/12897

From jvernee at openjdk.org  Wed Mar 15 17:27:32 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 15 Mar 2023 17:27:32 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v16]
In-Reply-To: <CqQTng1GkfdB1wANeu6Sj3NSnOrv_T3yCz72OIHWPAY=.0191a653-287e-4753-8270-fcb3f6e7d13b@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <c5UYe1zFGgndb5SQZ71TgGXsizWiNnhiosHWm5xiVpU=.032bb845-05ad-4393-83cd-2a111dc55c85@github.com>
 <CqQTng1GkfdB1wANeu6Sj3NSnOrv_T3yCz72OIHWPAY=.0191a653-287e-4753-8270-fcb3f6e7d13b@github.com>
Message-ID: <nsPnAW1VNnwLtFO47O5gLiQhOdXho3AHW8ZRexVOqAE=.082e0447-bdd2-40f0-a3ca-151eb16f7df3@github.com>

On Tue, 14 Mar 2023 22:52:44 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Btw. the new cases in which we use int and short accesses when byteWidth is not a power of 2 are never unaligned AFAICS. I guess _UNALIGNED is unnecessary in the JAVA_INT_UNALIGNED and JAVA_SHORT_UNALIGNED. They are always aligned wrt. to their size.

They are not necessarily aligned, for instance of the struct we are given is not aligned itself (at least in the reading case). Though we currently reject that case in AbstractLinker, it is something we might want to allow, and we have been looking at that as of late, for instance to pass packed structs to native code.

FWIW, using the unaligned variant effectively just turns off the alignment checks we do. So we have less safety, in theory. There should be no performance difference though just from using the _UNALIGNED layout.

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From dnsimon at openjdk.org  Wed Mar 15 18:03:33 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 15 Mar 2023 18:03:33 GMT
Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v6]
In-Reply-To: <0hYs21V1ZWB8o92CfvkEW3i0dZKkeW8kYGQu0p6xvtM=.e76da2cd-dbe5-4da2-a6cb-775f081b9a6a@github.com>
References: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>
 <0hYs21V1ZWB8o92CfvkEW3i0dZKkeW8kYGQu0p6xvtM=.e76da2cd-dbe5-4da2-a6cb-775f081b9a6a@github.com>
Message-ID: <pcrSId88XhJIirtfwHGNG-PG3pW4QFGkrziKk0OzC_A=.b5bb9a31-c4b1-4c6b-ad98-890ff0b655e5@github.com>

On Tue, 14 Mar 2023 16:06:06 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for accessing annotations. The main differences from `java.lang.reflect.AnnotatedElement` are:
>> * All methods in the `Annotated` interface explicitly specify requested annotation type(s). That is, there is no equivalent of `AnnotatedElement.getAnnotations()`.
>> * Annotation data is returned in a map-like object (of type `jdk.vm.ci.meta.AnnotationData`) instead of in an `Annotation` object. This works better for libgraal as it avoids the need for annotation types to be loaded and included in libgraal.
>>  
>> To demonstrate the new API, here's an example in terms `java.lang.reflect.AnnotatedElement` (which `ResolvedJavaType` implements):
>> 
>>     ResolvedJavaMethod method = ...;
>>     ExplodeLoop a = method.getAnnotation(ExplodeLoop.class);
>>     return switch (a.kind()) {
>>         case FULL_UNROLL -> LoopExplosionKind.FULL_UNROLL;
>>         case FULL_UNROLL_UNTIL_RETURN -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>>         ...
>>     }
>> 
>> 
>> The same code using the new API:
>> 
>> 
>>     ResolvedJavaMethod method = ...;
>>     ResolvedJavaType explodeLoopType = ...;
>>     AnnotationData a = method.getAnnotationDataFor(explodeLoopType);
>>     return switch (a.getEnum("kind").getName()) {
>>         case "FULL_UNROLL" -> LoopExplosionKind.FULL_UNROLL;
>>         case "FULL_UNROLL_UNTIL_RETURN" -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>>         ...
>>     }
>> 
>> 
>> The implementation relies on new methods in `jdk.internal.vm.VMSupport` for parsing annotations and serializing/deserializing to/from a byte array. This allows the annotation data to be passed from the HotSpot heap to the libgraal heap.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressed review feedback

@jddarcy would you be able to help review this PR? Based on git log, you are knowledgeable in `sun.reflect.annotation`. If not, please suggest who else I can reach out to for a review.

-------------

PR: https://git.openjdk.org/jdk/pull/12810

From cslucas at openjdk.org  Wed Mar 15 18:06:58 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 15 Mar 2023 18:06:58 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v3]
In-Reply-To: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
Message-ID: <yuu55rxPYLO4QMsl23TdWsgL_y-rT31uTCbgrlYOlys=.a2e3aec8-63cb-40fc-9fb1-fcc251c20907@github.com>

> Can I please get reviews for this PR to add support for the rematerialization of scalar-replaced objects that participate in allocation merges?
> 
> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested.
> 
> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N:
> 
> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png)
> 
> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1:
> 
> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png)
> 
> This PR adds support scalar replacing allocations participating in merges that are used *only* as debug information in SafePointNode and its subclasses. Although there is a performance benefit in doing scalar replacement in this scenario only, the goal of this PR is mainly to add infrastructure to support the rematerialization of SR objects participating in merges. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP, Load+AddP, primarily) subsequently.
> 
> The approach I used is pretty straightforward. It consists basically in: 1) Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a new Class to support rematerialization of SR objects part of merges; 3) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 4) Patch C2 to generate unique types for SR objects participating in allocation merges used only as debug information.
> 
> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression that might be related. I also tested with several applications and didn't see any failure.

Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:

  Fix some typos and do some small refactorings.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12897/files
  - new: https://git.openjdk.org/jdk/pull/12897/files/ea67a304..3b492d2e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=01-02

  Stats: 72 lines in 8 files changed: 1 ins; 7 del; 64 mod
  Patch: https://git.openjdk.org/jdk/pull/12897.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12897/head:pull/12897

PR: https://git.openjdk.org/jdk/pull/12897

From matsaave at openjdk.org  Wed Mar 15 18:45:00 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 15 Mar 2023 18:45:00 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v6]
In-Reply-To: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
Message-ID: <ivPzEqZ4W-BVPaEyXQ82ppnb-SO-VsgOixcQoHxp6V0=.2abc12b7-76a0-4052-a675-ffb510f9f35a@github.com>

> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
> 
> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
> 
> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
> 
> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
> 
> This change supports the following platforms: x86, aarch64, PPC, and RISCV

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  Fixed aarch64 interpreter mistake

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12778/files
  - new: https://git.openjdk.org/jdk/pull/12778/files/415e7116..9a3a63ae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12778&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12778&range=04-05

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12778.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12778/head:pull/12778

PR: https://git.openjdk.org/jdk/pull/12778

From mdoerr at openjdk.org  Wed Mar 15 18:53:08 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 15 Mar 2023 18:53:08 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v17]
In-Reply-To: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
Message-ID: <OeAM2KDLiqCc1fAdmFL5HK6BdUS2i-P42AaunS00UEw=.0f0c2e19-b59a-46e5-965e-a81b665a8e81@github.com>

> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
> 
> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
> 
> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
> 
> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Will get addressed separately: [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
> 
> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
> 
> I had to make changes to shared code and code for other platforms:
> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit.

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  Fix Copyright format.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12708/files
  - new: https://git.openjdk.org/jdk/pull/12708/files/9173af20..5320f895

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=15-16

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12708.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12708/head:pull/12708

PR: https://git.openjdk.org/jdk/pull/12708

From dcubed at openjdk.org  Wed Mar 15 18:56:35 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 15 Mar 2023 18:56:35 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v27]
In-Reply-To: <AmDOQhS1AzZxHd0kV_jhUWSGVdt8NZbfMVydFpHnQjs=.eff82b60-de1c-45e8-b54b-183b174b63d9@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <AmDOQhS1AzZxHd0kV_jhUWSGVdt8NZbfMVydFpHnQjs=.eff82b60-de1c-45e8-b54b-183b174b63d9@github.com>
Message-ID: <3lU8tL9eqZfwn3qgslK3WcjAInuVFsuY2X1vpukzbJI=.53255494-3359-46fb-a311-30cd59091b7b@github.com>

On Wed, 15 Mar 2023 09:41:30 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - More RISCV changes (by Fei Yang)
>  - Use -w instructions in fast_unlock()
>  - Increase stub size of C2HandleAnonOwnerStub to 18

Reviewed the v26 changes except for the riscv files.

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From mdoerr at openjdk.org  Wed Mar 15 19:07:34 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 15 Mar 2023 19:07:34 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v6]
In-Reply-To: <ivPzEqZ4W-BVPaEyXQ82ppnb-SO-VsgOixcQoHxp6V0=.2abc12b7-76a0-4052-a675-ffb510f9f35a@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <ivPzEqZ4W-BVPaEyXQ82ppnb-SO-VsgOixcQoHxp6V0=.2abc12b7-76a0-4052-a675-ffb510f9f35a@github.com>
Message-ID: <W4zsKKZyY_iyQNPjzB846ElfRLpq2qjZOGxlAClIylo=.dc9c343b-9ca6-41ae-b282-c53dd5b44ecf@github.com>

On Wed, 15 Mar 2023 18:45:00 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
>> 
>> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
>> 
>> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
>> 
>> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
>> 
>> This change supports the following platforms: x86, aarch64, PPC, and RISCV
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed aarch64 interpreter mistake

src/hotspot/cpu/ppc/templateTable_ppc_64.cpp line 3398:

> 3396:   const Bytecodes::Code code = bytecode();
> 3397:   const bool is_invokeinterface  = code == Bytecodes::_invokeinterface;
> 3398:   const bool is_invokedynamic    = code == false; // should not reach here with invokedynamic

This looks strange! I guess you wanted to delete more?

-------------

PR: https://git.openjdk.org/jdk/pull/12778

From jvernee at openjdk.org  Wed Mar 15 19:12:27 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 15 Mar 2023 19:12:27 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v17]
In-Reply-To: <OeAM2KDLiqCc1fAdmFL5HK6BdUS2i-P42AaunS00UEw=.0f0c2e19-b59a-46e5-965e-a81b665a8e81@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <OeAM2KDLiqCc1fAdmFL5HK6BdUS2i-P42AaunS00UEw=.0f0c2e19-b59a-46e5-965e-a81b665a8e81@github.com>
Message-ID: <Nvg7koBJCmq2l0CtfuGUY3LsVrKsjXofolGVN_KeNz4=.0ca20cdd-2f48-434b-bea2-41cd785f194f@github.com>

On Wed, 15 Mar 2023 18:53:08 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
>> 
>> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
>> 
>> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
>> 
>> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Will get addressed separately: [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
>> 
>> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
>> 
>> I had to make changes to shared code and code for other platforms:
>> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
>> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
>> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
>> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
>> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix Copyright format.

Marked as reviewed by jvernee (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From dcubed at openjdk.org  Wed Mar 15 19:17:38 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 15 Mar 2023 19:17:38 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v26]
In-Reply-To: <LqDlCifR-tcEv3WR4_50xOOPw6XipCD9QYrLazD7LuY=.e87dc186-3d7c-4ae8-b13a-d6e7830581fb@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <kmN_C8IN6Tj01P86gjrctndLD7Wrxw8m51f4msPK-Ak=.eccc9b74-4c3b-49ab-bded-d39aa4d15518@github.com>
 <sfWbIK24VrWl9RqsDBQh4I3T2xmp8KHDVMiQPWbk694=.b2a9ab0d-fa72-4aa9-8bfd-a68732144868@github.com>
 <LqDlCifR-tcEv3WR4_50xOOPw6XipCD9QYrLazD7LuY=.e87dc186-3d7c-4ae8-b13a-d6e7830581fb@github.com>
Message-ID: <yKKfoChVqMXXdz4or0EdJRubfoO-HKa4vA1UeHpsmRk=.656ab4fe-4f99-4731-9dc7-1849c86d1df6@github.com>

On Wed, 15 Mar 2023 09:36:25 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Would it be possible to open/send me the failing test that triggers vframeArray assert
> or extract a reproducer that you could publish?

I have started an internal discussion at Oracle to see what it would take
to move that test from closed to open. Will keep you posted.

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From darcy at openjdk.org  Wed Mar 15 19:26:21 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 15 Mar 2023 19:26:21 GMT
Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v6]
In-Reply-To: <pcrSId88XhJIirtfwHGNG-PG3pW4QFGkrziKk0OzC_A=.b5bb9a31-c4b1-4c6b-ad98-890ff0b655e5@github.com>
References: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>
 <0hYs21V1ZWB8o92CfvkEW3i0dZKkeW8kYGQu0p6xvtM=.e76da2cd-dbe5-4da2-a6cb-775f081b9a6a@github.com>
 <pcrSId88XhJIirtfwHGNG-PG3pW4QFGkrziKk0OzC_A=.b5bb9a31-c4b1-4c6b-ad98-890ff0b655e5@github.com>
Message-ID: <Dgm6w6HlBOkKOgVQq06VBspBQzA5HAqFDOYfj3JOKWo=.78f9d04b-2d28-4609-a785-c824e05284bf@github.com>

On Wed, 15 Mar 2023 18:00:49 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> @jddarcy would you be able to help review this PR? Based on git log, you are knowledgeable in `sun.reflect.annotation`. If not, please suggest who else I can reach out to for a review.

I can take a look at this, but it will be at least a few days before I can swap it in. I've also worked on the annotation-reading API in javax.lang.model.

I assume https://bugs.openjdk.org/browse/JDK-8303431 recounts the motivation behind this change?

-------------

PR: https://git.openjdk.org/jdk/pull/12810

From sspitsyn at openjdk.org  Wed Mar 15 19:35:25 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 15 Mar 2023 19:35:25 GMT
Subject: RFR: 8257967: JFR: Events for loaded agents [v10]
In-Reply-To: <iEqkEPSOYqIpc0uneK7i3LiKMP2WY_joe2Que3feIeM=.82be29bb-cfc7-4573-be7e-a363b7bf5989@github.com>
References: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
 <ZsaBMVK-eeLfmxgg15qPJHm6C-ed5PyIE4lGr-Gnr2s=.2f4044c4-e7ed-48f3-8877-feeb2753be18@github.com>
 <sKa6RRVpBw1kQ0DoQHMclspRNTBJZlKicmXBOUSWDBk=.0b538fa3-7db0-4863-a2aa-b3cd0f692959@github.com>
 <iEqkEPSOYqIpc0uneK7i3LiKMP2WY_joe2Que3feIeM=.82be29bb-cfc7-4573-be7e-a363b7bf5989@github.com>
Message-ID: <Q8__Hr5nfSDqGR-5aByEpT5nMEtFApnsFj4QLFchj8A=.aaa533a9-6395-4eb7-a758-1103d1a0e6b1@github.com>

On Tue, 14 Mar 2023 12:26:16 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> I've had a good look through now and have a better sense of the refactoring. Seems good.
>> 
>> I'll wait for any tweaks before hitting the approve button though.
>> 
>> Thanks
>
>> I've had a good look through now and have a better sense of the refactoring. Seems good.
>> 
>> 
>> 
>> I'll wait for any tweaks before hitting the approve button though.
>> 
>> 
>> 
>> Thanks
> 
> Thanks so much for taking a look. I realized that implementation details of loading should probably reside in agent.cpp, not agentList.cpp.
> 
> I am currently off on vacation and will update when back. Thanks also to Andrew Dinn for comments.

@mgronlun I'm looking at the fixes but it will take some time.

-------------

PR: https://git.openjdk.org/jdk/pull/12923

From rkennke at openjdk.org  Wed Mar 15 19:43:34 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 15 Mar 2023 19:43:34 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v26]
In-Reply-To: <yKKfoChVqMXXdz4or0EdJRubfoO-HKa4vA1UeHpsmRk=.656ab4fe-4f99-4731-9dc7-1849c86d1df6@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <kmN_C8IN6Tj01P86gjrctndLD7Wrxw8m51f4msPK-Ak=.eccc9b74-4c3b-49ab-bded-d39aa4d15518@github.com>
 <sfWbIK24VrWl9RqsDBQh4I3T2xmp8KHDVMiQPWbk694=.b2a9ab0d-fa72-4aa9-8bfd-a68732144868@github.com>
 <LqDlCifR-tcEv3WR4_50xOOPw6XipCD9QYrLazD7LuY=.e87dc186-3d7c-4ae8-b13a-d6e7830581fb@github.com>
 <yKKfoChVqMXXdz4or0EdJRubfoO-HKa4vA1UeHpsmRk=.656ab4fe-4f99-4731-9dc7-1849c86d1df6@github.com>
Message-ID: <jsmz2mhexRS1UJfJqwDQrxuBW2VTTQmwiTFczT5IPUY=.35e362c4-843d-4ec3-a67c-05425c08fd37@github.com>

On Wed, 15 Mar 2023 19:14:09 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> > Would it be possible to open/send me the failing test that triggers vframeArray assert
> > or extract a reproducer that you could publish?
> 
> I have started an internal discussion at Oracle to see what it would take to move that test from closed to open. Will keep you posted.

Thank you!

Regarding moving this PR back to draft, I am not sure. I can do that, yes. But really the fundamental algorithm and implementation is basically fixed since half a year already. I have re-worked it into a fresh PR based on the request to put it behind a flag. The recent change to a fixed-size lock-stack has probably invalidated part of your previous reviews, and I am sorry for that. On the upside, it removed a lot of complexity in the JIT compilers and assembly code generators.

What else do I expect to happen?

Thomas is working on an ARM(32) port, but this is quite separate and could even land after this PR is done.

I still don't quite like the naming. Fast-locking doesn't really say anything and it's not (meant to be) faster than the previous stack-locking. It is an alternative (and less racy, on the object header) way to implement a thin-locking layer before inflating monitors, that is all. So maybe -XX:+UseNewThinLocking? It is somewhat temporary anyway. At least my hope is that when we eventually switch to Lilliput turned on by default, we would entirely remove stack-locking.

I would also add some code in arguments.cpp to keep this new thin locking turned off on platforms that don't yet support it.

Besides that, from my POV, it is pretty much done.

What do you think?

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From dnsimon at openjdk.org  Wed Mar 15 20:37:22 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 15 Mar 2023 20:37:22 GMT
Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v6]
In-Reply-To: <Dgm6w6HlBOkKOgVQq06VBspBQzA5HAqFDOYfj3JOKWo=.78f9d04b-2d28-4609-a785-c824e05284bf@github.com>
References: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>
 <0hYs21V1ZWB8o92CfvkEW3i0dZKkeW8kYGQu0p6xvtM=.e76da2cd-dbe5-4da2-a6cb-775f081b9a6a@github.com>
 <pcrSId88XhJIirtfwHGNG-PG3pW4QFGkrziKk0OzC_A=.b5bb9a31-c4b1-4c6b-ad98-890ff0b655e5@github.com>
 <Dgm6w6HlBOkKOgVQq06VBspBQzA5HAqFDOYfj3JOKWo=.78f9d04b-2d28-4609-a785-c824e05284bf@github.com>
Message-ID: <NbRWhOJLxuQ9qZf5PW4ww9hf-6hnW5OCgAsR1XAK41I=.5f5ac773-ed44-46bf-9f1c-ab87c3e266c8@github.com>

On Wed, 15 Mar 2023 19:23:52 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> I assume https://bugs.openjdk.org/browse/JDK-8303431 recounts the motivation behind this change?

Yes, it does. Thanks in advance.

-------------

PR: https://git.openjdk.org/jdk/pull/12810

From jvernee at openjdk.org  Wed Mar 15 20:55:31 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 15 Mar 2023 20:55:31 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v16]
In-Reply-To: <CqQTng1GkfdB1wANeu6Sj3NSnOrv_T3yCz72OIHWPAY=.0191a653-287e-4753-8270-fcb3f6e7d13b@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <c5UYe1zFGgndb5SQZ71TgGXsizWiNnhiosHWm5xiVpU=.032bb845-05ad-4393-83cd-2a111dc55c85@github.com>
 <CqQTng1GkfdB1wANeu6Sj3NSnOrv_T3yCz72OIHWPAY=.0191a653-287e-4753-8270-fcb3f6e7d13b@github.com>
Message-ID: <kOGNH9hYNNVr80eVwT4xhrVy3PqiJ_lgD-Oc4bilxhM=.8f7c4bc3-ad88-48eb-a594-ef4ea398ee6a@github.com>

On Tue, 14 Mar 2023 22:52:44 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix storing 32 bit integers into Java frames. Enable TestArrayStructs.
>
> Btw. the new cases in which we use int and short accesses when byteWidth is not a power of 2 are never unaligned AFAICS. I guess _UNALIGNED is unnecessary in the JAVA_INT_UNALIGNED and JAVA_SHORT_UNALIGNED. They are always aligned wrt. to their size.

@TheRealMDoerr I've approved the PR. I suggest for a second reviewer to try and get someone who knows the PPC port.

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From dcubed at openjdk.org  Wed Mar 15 20:58:38 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 15 Mar 2023 20:58:38 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v27]
In-Reply-To: <AmDOQhS1AzZxHd0kV_jhUWSGVdt8NZbfMVydFpHnQjs=.eff82b60-de1c-45e8-b54b-183b174b63d9@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <AmDOQhS1AzZxHd0kV_jhUWSGVdt8NZbfMVydFpHnQjs=.eff82b60-de1c-45e8-b54b-183b174b63d9@github.com>
Message-ID: <14eqGd_d9yW5aXDqAYrCnohm4cB7tACgAKc_qDsTJGA=.33c510e9-63f0-4a5f-aebe-bc77f0ffbefc@github.com>

On Wed, 15 Mar 2023 09:41:30 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - More RISCV changes (by Fei Yang)
>  - Use -w instructions in fast_unlock()
>  - Increase stub size of C2HandleAnonOwnerStub to 18

Personally, I'm fine with leaving this PR in the non-draft/ready-to-review state.
However, that's because I'm very much in sync (no pun intended) with where this
code is at currently. I catch up on the latest changes everyday and I've started
doing Mach5 test cycles everyday. When I return to Orlando, I will start doing
stress testing runs in my lab.

For other folks that started reviewing earlier than I did, they may have a different
POV. I do see the change to a fixed-size lock-stack as a wonderful improvement
because it got rid of so many changes. I think the project went from 74 changed
and new files down to 51 changed and new files.

As for naming, I don't have any suggestions at the moment. I believe @dholmes-ora
has commented in other reviews that "Naming is hard..."

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From stuefe at openjdk.org  Wed Mar 15 21:32:36 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 15 Mar 2023 21:32:36 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v27]
In-Reply-To: <AmDOQhS1AzZxHd0kV_jhUWSGVdt8NZbfMVydFpHnQjs=.eff82b60-de1c-45e8-b54b-183b174b63d9@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <AmDOQhS1AzZxHd0kV_jhUWSGVdt8NZbfMVydFpHnQjs=.eff82b60-de1c-45e8-b54b-183b174b63d9@github.com>
Message-ID: <KJnRsL_pfp7RoByyl22S6NGSWpd1rOcf9NuRf7EE1is=.24724192-633b-42f6-8dab-51a546a9b12e@github.com>

On Wed, 15 Mar 2023 09:41:30 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - More RISCV changes (by Fei Yang)
>  - Use -w instructions in fast_unlock()
>  - Increase stub size of C2HandleAnonOwnerStub to 18

I proposed NewStyleThinLocks or ThinLocks2. Anything really thats easy to grep for and to distinguish from old stack based locks. I can live with RomanStyleLocks :) 

If things work out this is a transient state anyway. I also think Roman should just decide and name it.

Getting rid pf the growing part of LockStack is a relief.

The missing ports are no showstoppers, we can do them later (I'll work on arm but I'm swamped atm so this may take a week or so).

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From kvn at openjdk.org  Thu Mar 16 00:20:20 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 16 Mar 2023 00:20:20 GMT
Subject: RFR: 8296440: Remove Method* handling from
 cleanup_inline_caches_impl
In-Reply-To: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
References: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
Message-ID: <8C06DfuEkBnOaaP1WFv7Y6TRftP9XMitffS3UbOaf8c=.abb8c6e3-7a3b-4412-89b3-8819bd93900e@github.com>

On Wed, 1 Mar 2023 11:07:36 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> This PR replaces cleaning of static stubs in CompiledMethod::cleanup_inline_caches_impl() with a guarantee that it is actually not needed because the holder of the embedded target Method* is alive if the caller nmethod is not unloading.
> 
> The holder of the target Method* has to be alive because it is reachable from the caller nmethod's oop pool. This is checked by `check_path_to_callee()` when a statically bound call gets resolved.
> 
> C2i entry barriers can be removed for the same reason.
> 
> Testing:
> 
> Many rounds in our CI testing which includes most JCK and JTREG tests, Renaissance benchmark and SAP specific tests with fastdebug and release builds on the standard platforms plus PPC64.
> 
> I've also done tier1 and tier2 tests with -XX:-Inline and tier1 tests with ZGC.
> 
> I've started hotspot and jdk tier1 tests with -Xcomp. They were not finished when I stopped them after 24h.

I hit guarantee in tier7 running our closed tests with JRuby and `-Xcomp -ea -esa -XX:CompileThreshold=100` flags:

#  Internal Error (/workspace/open/src/hotspot/share/runtime/sharedRuntime.cpp:1411), pid=1150904, tid=1150907
#  guarantee(false) failed: Missing dependency resolving optimized virtual (invokeinterface) call to  jnr.enxio.channels.Native$LibC$jnr$ffi$2::read

Unfortunately I can't share tests.

-------------

PR: https://git.openjdk.org/jdk/pull/12802

From kvn at openjdk.org  Thu Mar 16 00:28:20 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 16 Mar 2023 00:28:20 GMT
Subject: RFR: 8296440: Remove Method* handling from
 cleanup_inline_caches_impl
In-Reply-To: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
References: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
Message-ID: <SQ4ISu_YTNoETuCb-EUQq0-7fFo6bFQ8js4EtIhzOV4=.dbd15cb0-975b-4412-8813-2c1cb33e20cc@github.com>

On Wed, 1 Mar 2023 11:07:36 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> This PR replaces cleaning of static stubs in CompiledMethod::cleanup_inline_caches_impl() with a guarantee that it is actually not needed because the holder of the embedded target Method* is alive if the caller nmethod is not unloading.
> 
> The holder of the target Method* has to be alive because it is reachable from the caller nmethod's oop pool. This is checked by `check_path_to_callee()` when a statically bound call gets resolved.
> 
> C2i entry barriers can be removed for the same reason.
> 
> Testing:
> 
> Many rounds in our CI testing which includes most JCK and JTREG tests, Renaissance benchmark and SAP specific tests with fastdebug and release builds on the standard platforms plus PPC64.
> 
> I've also done tier1 and tier2 tests with -XX:-Inline and tier1 tests with ZGC.
> 
> I've started hotspot and jdk tier1 tests with -Xcomp. They were not finished when I stopped them after 24h.

It was linux-x64-debug VM:

# JRE version: Java(TM) SE Runtime Environment (21.0) (fastdebug build 21-internal-LTS-2023-03-15-1549029.vladimir.kozlov.jdkgit2)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 21-internal-LTS-2023-03-15-1549029.vladimir.kozlov.jdkgit2, compiled mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x18cca1f]  SharedRuntime::resolve_sub_helper(bool, bool, JavaThread*)+0x96f

-------------

PR: https://git.openjdk.org/jdk/pull/12802

From fjiang at openjdk.org  Thu Mar 16 03:53:16 2023
From: fjiang at openjdk.org (Feilong Jiang)
Date: Thu, 16 Mar 2023 03:53:16 GMT
Subject: RFR: 8304293: RISC-V: JDK-8276799 missed atomic intrinsic support for
 C1
Message-ID: <9U2safmMfGsfIIlyBZW3E3dbm68mKcBAzemr5yqoPEw=.c261f575-2cbc-402e-b742-7a6bdc8c2450@github.com>

The following intrinsics in C1 are controlled by supports_atomic_xxx, but they are not set properly on RISC-V:
- _getAndAddInt
- _getAndAddLong
- _getAndSetInt
- _getAndSetLong
- _getAndSetReference

RISC-V provides a set of atomic instructions [1], these intrinsics could be enabled by default.

Here is the HIR output of C1:

before:


B18 (V) [189, 196] -> B20 pred: B8 B17 
empty stack
inlining depth 0
__bci__use__tid____instr____________________________________
  0    0    a251   <instance 0x00000040a802fb98 klass=jdk/internal/misc/Unsafe>
  3    0    a252   null   
  4    0    l254   274954985816L
  7    0    l255   1L
. 8    0    l256   a251.invokespecial(a252, l254, l255)
                   jdk/internal/misc/Unsafe.getAndAddLong(Ljava/lang/Object;JJ)J
. 193  0    l258   a42._24 := l256 (J) tid
. 196  0     259   goto B20


after:


B18 (V) [189, 196] -> B20 pred: B8 B17 
empty stack
inlining depth 0
__bci__use__tid____instr____________________________________
  0    0    a251   <instance 0x00000040a802fb98 klass=jdk/internal/misc/Unsafe>
  3    0    a252   null   
  4    0    l254   274954985816L
  7    0    l255   1L
. 8    0    l256   UnsafeGetAndSet (add)(a252, l254, value l255)
. 193  0    l258   a42._24 := l256 (J) tid
. 196  0     259   goto B20


1. https://github.com/riscv/riscv-isa-manual/blob/8b9047d8d20ef548f7996efee1550760d7bc1279/src/a.tex#L416-L422

Testing:

- [ ] tier1 on Unmatched board (release build)

-------------

Commit messages:
 - missed atomic intrinsic support for c1

Changes: https://git.openjdk.org/jdk/pull/13053/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13053&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304293
  Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13053.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/13053/head:pull/13053

PR: https://git.openjdk.org/jdk/pull/13053

From kvn at openjdk.org  Thu Mar 16 04:10:18 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 16 Mar 2023 04:10:18 GMT
Subject: RFR: 8296440: Remove Method* handling from
 cleanup_inline_caches_impl
In-Reply-To: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
References: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
Message-ID: <Jpp_2b4WQRgEfM1ZIq7JpoJ_vxt4debh3rVQ2obGFjk=.72738e46-9007-4e02-b711-3d3604a9920e@github.com>

On Wed, 1 Mar 2023 11:07:36 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> This PR replaces cleaning of static stubs in CompiledMethod::cleanup_inline_caches_impl() with a guarantee that it is actually not needed because the holder of the embedded target Method* is alive if the caller nmethod is not unloading.
> 
> The holder of the target Method* has to be alive because it is reachable from the caller nmethod's oop pool. This is checked by `check_path_to_callee()` when a statically bound call gets resolved.
> 
> C2i entry barriers can be removed for the same reason.
> 
> Testing:
> 
> Many rounds in our CI testing which includes most JCK and JTREG tests, Renaissance benchmark and SAP specific tests with fastdebug and release builds on the standard platforms plus PPC64.
> 
> I've also done tier1 and tier2 tests with -XX:-Inline and tier1 tests with ZGC.
> 
> I've started hotspot and jdk tier1 tests with -Xcomp. They were not finished when I stopped them after 24h.

Finally got hs_err file. The top of call stack look like this:

V  [libjvm.so+0x18cca1f]  SharedRuntime::resolve_sub_helper(bool, bool, JavaThread*)+0x96f  (sharedRuntime.cpp:1411)
V  [libjvm.so+0x18ccdb9]  SharedRuntime::resolve_helper(bool, bool, JavaThread*)+0x39  (sharedRuntime.cpp:1246)
V  [libjvm.so+0x18cdaee]  SharedRuntime::resolve_opt_virtual_call_C(JavaThread*)+0x15e  (sharedRuntime.cpp:1690)
v  ~RuntimeStub::resolve_opt_virtual_call 0x00007fdab0ddb89b
J 17706 c2 jnr.enxio.channels.Native.read(ILjava/nio/ByteBuffer;)I org.jruby.dist (80 bytes) @ 0x00007fdab1317d9c [0x00007fdab1317d20+0x000000000000007c]
J 17705 c2 jnr.enxio.channels.NativeDeviceChannel.read(Ljava/nio/ByteBuffer;)I org.jruby.dist (91 bytes) @ 0x00007fdab2037704 [0x00007fdab20376c0+0x0000000000000044]
J 17384 c2 org.jruby.util.io.PosixShim.read(Lorg/jruby/util/io/ChannelFD;[BIIZ)I org.jruby.dist (192 bytes) @ 0x00007fdab190984c [0x00007fdab1909720+0x000000000000012c]
J 17379 c2 org.jruby.util.io.OpenFile$2.run(Lorg/jruby/runtime/ThreadContext;Lorg/jruby/util/io/OpenFile;[BII)I org.jruby.dist (82 bytes) @ 0x00007fdab1fff4e8 [0x00007fdab1fff400+0x00000000000000e8]

-------------

PR: https://git.openjdk.org/jdk/pull/12802

From dchuyko at openjdk.org  Thu Mar 16 04:55:25 2023
From: dchuyko at openjdk.org (Dmitry Chuyko)
Date: Thu, 16 Mar 2023 04:55:25 GMT
Subject: RFR: 8300669: AArch64: Table based tails processing and wider
 stores for Arrays.fill() intrinsic [v7]
In-Reply-To: <0HhfPpk5EIXfhlmdTaT-ik1EQWgYXSKkK7f4fuLKGh0=.9e690153-fc70-49a0-aada-2829747da8cf@github.com>
References: <P9Uyonc1ySikxhznLvs9HT6kXvh6IRFYMqH-BLU1nuM=.5fbbe0ed-f32e-4653-97a2-9a8a4b6e5e0d@github.com>
 <0HhfPpk5EIXfhlmdTaT-ik1EQWgYXSKkK7f4fuLKGh0=.9e690153-fc70-49a0-aada-2829747da8cf@github.com>
Message-ID: <5JHSnU7J6tzmoU1yKRYGOA1T8WDi2NHeXWPfQCOYKhU=.7f8023de-9f58-49a3-8c9b-a8e46c7430e9@github.com>

On Thu, 9 Mar 2023 00:18:05 GMT, Dmitry Chuyko <dchuyko at openjdk.org> wrote:

>> This is a new AArch64 implementation of existing (1-4-byte element) stubs that are called in C2-compiled code for array fill patterns and Arrays.fill().
>> 
>> Main variant of existing algorithm:
>> 
>> 
>> [Short arrays (< 8 bytes): fill by element and exit];
>> // ...
>> [align base to 8 bytes];
>> // ...
>> // fill_words
>> head_len = (cnt & 14) / 2;
>> switch (head_len) {
>>     do {
>>       cnt -= 16;
>>         stp;
>>        case 7:
>>         stp;
>>        case 6:
>>         stp;
>>         // ...
>>       case 1:
>>          stp;
>>        case 0:
>>          base += 8*16;
>>      } while (cnt);
>>    }
>> [(over)write a tail < 8 bytes];
>> 
>> 
>> Even in good case, only 16-byte GPR (STP) stores are used, and there is a jump for every 8 stores. There is always extra work to be done for misaligned targets, which especially affects small to medium lengths.
>> 
>> The new implementation generates fill implementation for every length up to a certain threshold (160-byte length). These implementations form a table where you jump when the remaining target length is suitable.
>> 
>> For each table entry (target length), we can have no branches and use the most number of widest possible stores that best fit the detected CPU model. Currently it is SIMD STPQ for Neoverse N2 and GPR STP for the rest. The choice is made after benchmarking and is controlled by the new UseSIMDForArrayFill flag in AArch64.
>> 
>> Main variant of the new algorithm (see mode detailed description in comments):
>> 
>> 
>> [align data at 16 bytes];
>> while(cnt_bytes > 128) {
>>    [store 128 bytes];
>>    cnt_bytes -= 128;
>> }
>> [store tail of 0..127 bytes];
>> 
>> 
>> 
>> Both existing and proposed implementations specifically handle zero fill case (see comments about ZVA). New implementation contains a path for very small arrays that can be cut to further improve more generic case (added to avoid regressions).
>> 
>> The check added in https://bugs.openjdk.org/browse/JDK-8298720 in StubGenerator is removed as it is a stub code being generated. For the selected threshold, the increase in code size is within 8 KB.
>> 
>> New test TestArraysFill is added to intrinsics jtreg tests. It calls optimized versions of 2-arg and 4-arg Arrays.fill() for different data types, lengths and patterns. The target data is checked to be filled with the required value, the surrounding data is checked to be intact.
>> 
>> Existing test/micro/org/openjdk/bench/java/util/ArraysFill.java benchmark was used only initially. There are many cases and data lengths to cover. A modified version of the benchmark is attached [1] to the RFE, but not included in the change as it takes too long to complete all valuable variants.
>> 
>> Resulting performance data are listed in the spreadsheet [2] attache to the RFE. Target processors were Graviton 3, Graviton 2, TaiShan, A72 and A53. Latest data from Altra is not included but the picture there was similar to Graviton 2 in all experiments. There is a range of target lengths with various enhancement numbers. Interesting lengths are within table implementation threshold and close to them (stepped), small lengths (all) and long lengths (1 point, they look similar). Over this voluntary selection:
>> 
>> - No major regressions were found.
>> - Geomean improvement: 11-33%
>> - Median improvement: 10-48%
>> 
>> Testing: tier1, tier2 and the new test on fastdebug aarch64 and x86.
>> 
>> [1] https://bugs.openjdk.org/secure/attachment/102426/ArraysFill.java
>> [2] https://bugs.openjdk.org/secure/attachment/102427/arrays-fill.ods
>
> Dmitry Chuyko 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 JDK-8300669
>  - Var in test
>  - Merge branch 'openjdk:master' into JDK-8300669
>  - Wording about alignment
>  - Fixed compilation on win/mac
>  - Merge branch 'openjdk:master' into JDK-8300669
>  - Table based arrays_fill stub implementation for aarch64

Th? functionality in question applies to Arrays.fill() and to fill loops as well. First one is easier to study: get (start, fill length, array length), and get the call weight in profiles.

As an example consider parameters distribution in OpenJDK jtreg tests.
![02-jtreg-lengths](https://user-images.githubusercontent.com/31855791/225517679-1df9db71-03cd-4ed6-9b79-be19c229d73c.png)
Here most fills start with 0 and fill length is below 512 elements.

-------------

PR: https://git.openjdk.org/jdk/pull/12222

From dchuyko at openjdk.org  Thu Mar 16 05:07:21 2023
From: dchuyko at openjdk.org (Dmitry Chuyko)
Date: Thu, 16 Mar 2023 05:07:21 GMT
Subject: RFR: 8300669: AArch64: Table based tails processing and wider
 stores for Arrays.fill() intrinsic [v7]
In-Reply-To: <0HhfPpk5EIXfhlmdTaT-ik1EQWgYXSKkK7f4fuLKGh0=.9e690153-fc70-49a0-aada-2829747da8cf@github.com>
References: <P9Uyonc1ySikxhznLvs9HT6kXvh6IRFYMqH-BLU1nuM=.5fbbe0ed-f32e-4653-97a2-9a8a4b6e5e0d@github.com>
 <0HhfPpk5EIXfhlmdTaT-ik1EQWgYXSKkK7f4fuLKGh0=.9e690153-fc70-49a0-aada-2829747da8cf@github.com>
Message-ID: <PjZ6whGsJNGRwruwxWf6ZguSCNUnfFN8hwQv7E3UBNc=.4a33fb39-dcf4-48ad-af78-71ec19b99214@github.com>

On Thu, 9 Mar 2023 00:18:05 GMT, Dmitry Chuyko <dchuyko at openjdk.org> wrote:

>> This is a new AArch64 implementation of existing (1-4-byte element) stubs that are called in C2-compiled code for array fill patterns and Arrays.fill().
>> 
>> Main variant of existing algorithm:
>> 
>> 
>> [Short arrays (< 8 bytes): fill by element and exit];
>> // ...
>> [align base to 8 bytes];
>> // ...
>> // fill_words
>> head_len = (cnt & 14) / 2;
>> switch (head_len) {
>>     do {
>>       cnt -= 16;
>>         stp;
>>        case 7:
>>         stp;
>>        case 6:
>>         stp;
>>         // ...
>>       case 1:
>>          stp;
>>        case 0:
>>          base += 8*16;
>>      } while (cnt);
>>    }
>> [(over)write a tail < 8 bytes];
>> 
>> 
>> Even in good case, only 16-byte GPR (STP) stores are used, and there is a jump for every 8 stores. There is always extra work to be done for misaligned targets, which especially affects small to medium lengths.
>> 
>> The new implementation generates fill implementation for every length up to a certain threshold (160-byte length). These implementations form a table where you jump when the remaining target length is suitable.
>> 
>> For each table entry (target length), we can have no branches and use the most number of widest possible stores that best fit the detected CPU model. Currently it is SIMD STPQ for Neoverse N2 and GPR STP for the rest. The choice is made after benchmarking and is controlled by the new UseSIMDForArrayFill flag in AArch64.
>> 
>> Main variant of the new algorithm (see mode detailed description in comments):
>> 
>> 
>> [align data at 16 bytes];
>> while(cnt_bytes > 128) {
>>    [store 128 bytes];
>>    cnt_bytes -= 128;
>> }
>> [store tail of 0..127 bytes];
>> 
>> 
>> 
>> Both existing and proposed implementations specifically handle zero fill case (see comments about ZVA). New implementation contains a path for very small arrays that can be cut to further improve more generic case (added to avoid regressions).
>> 
>> The check added in https://bugs.openjdk.org/browse/JDK-8298720 in StubGenerator is removed as it is a stub code being generated. For the selected threshold, the increase in code size is within 8 KB.
>> 
>> New test TestArraysFill is added to intrinsics jtreg tests. It calls optimized versions of 2-arg and 4-arg Arrays.fill() for different data types, lengths and patterns. The target data is checked to be filled with the required value, the surrounding data is checked to be intact.
>> 
>> Existing test/micro/org/openjdk/bench/java/util/ArraysFill.java benchmark was used only initially. There are many cases and data lengths to cover. A modified version of the benchmark is attached [1] to the RFE, but not included in the change as it takes too long to complete all valuable variants.
>> 
>> Resulting performance data are listed in the spreadsheet [2] attache to the RFE. Target processors were Graviton 3, Graviton 2, TaiShan, A72 and A53. Latest data from Altra is not included but the picture there was similar to Graviton 2 in all experiments. There is a range of target lengths with various enhancement numbers. Interesting lengths are within table implementation threshold and close to them (stepped), small lengths (all) and long lengths (1 point, they look similar). Over this voluntary selection:
>> 
>> - No major regressions were found.
>> - Geomean improvement: 11-33%
>> - Median improvement: 10-48%
>> 
>> Testing: tier1, tier2 and the new test on fastdebug aarch64 and x86.
>> 
>> [1] https://bugs.openjdk.org/secure/attachment/102426/ArraysFill.java
>> [2] https://bugs.openjdk.org/secure/attachment/102427/arrays-fill.ods
>
> Dmitry Chuyko 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 JDK-8300669
>  - Var in test
>  - Merge branch 'openjdk:master' into JDK-8300669
>  - Wording about alignment
>  - Fixed compilation on win/mac
>  - Merge branch 'openjdk:master' into JDK-8300669
>  - Table based arrays_fill stub implementation for aarch64

In micro-benchmarks we can compare proposed implementation ("patch"), existing one ("clean") and also a variant when stubs are not called ("off"). For instance here is a plot for aligned int fills on Graviton 3.
![03-fill-512-3](https://user-images.githubusercontent.com/31855791/225518139-11da0cb8-277c-4405-bc63-a5f459f038ce.png)
Existing stub is slower than no-stub variant on many lengths and shows leaping results for neighbor lengths. Patched version is the same 30% to current version as that is to no-stub version for <90 elements. Patched version is same or better than no-stub version for longer lengths and it "leaps" much less.

-------------

PR: https://git.openjdk.org/jdk/pull/12222

From dchuyko at openjdk.org  Thu Mar 16 05:17:22 2023
From: dchuyko at openjdk.org (Dmitry Chuyko)
Date: Thu, 16 Mar 2023 05:17:22 GMT
Subject: RFR: 8300669: AArch64: Table based tails processing and wider
 stores for Arrays.fill() intrinsic [v7]
In-Reply-To: <0HhfPpk5EIXfhlmdTaT-ik1EQWgYXSKkK7f4fuLKGh0=.9e690153-fc70-49a0-aada-2829747da8cf@github.com>
References: <P9Uyonc1ySikxhznLvs9HT6kXvh6IRFYMqH-BLU1nuM=.5fbbe0ed-f32e-4653-97a2-9a8a4b6e5e0d@github.com>
 <0HhfPpk5EIXfhlmdTaT-ik1EQWgYXSKkK7f4fuLKGh0=.9e690153-fc70-49a0-aada-2829747da8cf@github.com>
Message-ID: <W9XZKlUx0il8IsqnGk_za7wWXZDHXggRnJ31Q_0xsP8=.20fb2bbd-2f6c-4ed7-be3b-1604270c4954@github.com>

On Thu, 9 Mar 2023 00:18:05 GMT, Dmitry Chuyko <dchuyko at openjdk.org> wrote:

>> This is a new AArch64 implementation of existing (1-4-byte element) stubs that are called in C2-compiled code for array fill patterns and Arrays.fill().
>> 
>> Main variant of existing algorithm:
>> 
>> 
>> [Short arrays (< 8 bytes): fill by element and exit];
>> // ...
>> [align base to 8 bytes];
>> // ...
>> // fill_words
>> head_len = (cnt & 14) / 2;
>> switch (head_len) {
>>     do {
>>       cnt -= 16;
>>         stp;
>>        case 7:
>>         stp;
>>        case 6:
>>         stp;
>>         // ...
>>       case 1:
>>          stp;
>>        case 0:
>>          base += 8*16;
>>      } while (cnt);
>>    }
>> [(over)write a tail < 8 bytes];
>> 
>> 
>> Even in good case, only 16-byte GPR (STP) stores are used, and there is a jump for every 8 stores. There is always extra work to be done for misaligned targets, which especially affects small to medium lengths.
>> 
>> The new implementation generates fill implementation for every length up to a certain threshold (160-byte length). These implementations form a table where you jump when the remaining target length is suitable.
>> 
>> For each table entry (target length), we can have no branches and use the most number of widest possible stores that best fit the detected CPU model. Currently it is SIMD STPQ for Neoverse N2 and GPR STP for the rest. The choice is made after benchmarking and is controlled by the new UseSIMDForArrayFill flag in AArch64.
>> 
>> Main variant of the new algorithm (see mode detailed description in comments):
>> 
>> 
>> [align data at 16 bytes];
>> while(cnt_bytes > 128) {
>>    [store 128 bytes];
>>    cnt_bytes -= 128;
>> }
>> [store tail of 0..127 bytes];
>> 
>> 
>> 
>> Both existing and proposed implementations specifically handle zero fill case (see comments about ZVA). New implementation contains a path for very small arrays that can be cut to further improve more generic case (added to avoid regressions).
>> 
>> The check added in https://bugs.openjdk.org/browse/JDK-8298720 in StubGenerator is removed as it is a stub code being generated. For the selected threshold, the increase in code size is within 8 KB.
>> 
>> New test TestArraysFill is added to intrinsics jtreg tests. It calls optimized versions of 2-arg and 4-arg Arrays.fill() for different data types, lengths and patterns. The target data is checked to be filled with the required value, the surrounding data is checked to be intact.
>> 
>> Existing test/micro/org/openjdk/bench/java/util/ArraysFill.java benchmark was used only initially. There are many cases and data lengths to cover. A modified version of the benchmark is attached [1] to the RFE, but not included in the change as it takes too long to complete all valuable variants.
>> 
>> Resulting performance data are listed in the spreadsheet [2] attache to the RFE. Target processors were Graviton 3, Graviton 2, TaiShan, A72 and A53. Latest data from Altra is not included but the picture there was similar to Graviton 2 in all experiments. There is a range of target lengths with various enhancement numbers. Interesting lengths are within table implementation threshold and close to them (stepped), small lengths (all) and long lengths (1 point, they look similar). Over this voluntary selection:
>> 
>> - No major regressions were found.
>> - Geomean improvement: 11-33%
>> - Median improvement: 10-48%
>> 
>> Testing: tier1, tier2 and the new test on fastdebug aarch64 and x86.
>> 
>> [1] https://bugs.openjdk.org/secure/attachment/102426/ArraysFill.java
>> [2] https://bugs.openjdk.org/secure/attachment/102427/arrays-fill.ods
>
> Dmitry Chuyko 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 JDK-8300669
>  - Var in test
>  - Merge branch 'openjdk:master' into JDK-8300669
>  - Wording about alignment
>  - Fixed compilation on win/mac
>  - Merge branch 'openjdk:master' into JDK-8300669
>  - Table based arrays_fill stub implementation for aarch64

In non-dedicated benchmarks there is some improvement in message digest operations for small lengths where cleaning operation has noticeable weight. E.g. SHA-224 for size 16 is 4.7% faster (MD5, SHA-256, SHA3-256 show 1-4%). SpecJVM serial is 0.14% faster (fill() weight there is ~0.28%).

-------------

PR: https://git.openjdk.org/jdk/pull/12222

From dchuyko at openjdk.org  Thu Mar 16 05:21:21 2023
From: dchuyko at openjdk.org (Dmitry Chuyko)
Date: Thu, 16 Mar 2023 05:21:21 GMT
Subject: RFR: 8300669: AArch64: Table based tails processing and wider
 stores for Arrays.fill() intrinsic [v7]
In-Reply-To: <0HhfPpk5EIXfhlmdTaT-ik1EQWgYXSKkK7f4fuLKGh0=.9e690153-fc70-49a0-aada-2829747da8cf@github.com>
References: <P9Uyonc1ySikxhznLvs9HT6kXvh6IRFYMqH-BLU1nuM=.5fbbe0ed-f32e-4653-97a2-9a8a4b6e5e0d@github.com>
 <0HhfPpk5EIXfhlmdTaT-ik1EQWgYXSKkK7f4fuLKGh0=.9e690153-fc70-49a0-aada-2829747da8cf@github.com>
Message-ID: <HjnW0mR4RqcLMBMyfa1ArNFc4vNgq_KLCbJMgeyeUzM=.0e6b1ff5-b15c-46c0-890f-dcf386d5e549@github.com>

On Thu, 9 Mar 2023 00:18:05 GMT, Dmitry Chuyko <dchuyko at openjdk.org> wrote:

>> This is a new AArch64 implementation of existing (1-4-byte element) stubs that are called in C2-compiled code for array fill patterns and Arrays.fill().
>> 
>> Main variant of existing algorithm:
>> 
>> 
>> [Short arrays (< 8 bytes): fill by element and exit];
>> // ...
>> [align base to 8 bytes];
>> // ...
>> // fill_words
>> head_len = (cnt & 14) / 2;
>> switch (head_len) {
>>     do {
>>       cnt -= 16;
>>         stp;
>>        case 7:
>>         stp;
>>        case 6:
>>         stp;
>>         // ...
>>       case 1:
>>          stp;
>>        case 0:
>>          base += 8*16;
>>      } while (cnt);
>>    }
>> [(over)write a tail < 8 bytes];
>> 
>> 
>> Even in good case, only 16-byte GPR (STP) stores are used, and there is a jump for every 8 stores. There is always extra work to be done for misaligned targets, which especially affects small to medium lengths.
>> 
>> The new implementation generates fill implementation for every length up to a certain threshold (160-byte length). These implementations form a table where you jump when the remaining target length is suitable.
>> 
>> For each table entry (target length), we can have no branches and use the most number of widest possible stores that best fit the detected CPU model. Currently it is SIMD STPQ for Neoverse N2 and GPR STP for the rest. The choice is made after benchmarking and is controlled by the new UseSIMDForArrayFill flag in AArch64.
>> 
>> Main variant of the new algorithm (see mode detailed description in comments):
>> 
>> 
>> [align data at 16 bytes];
>> while(cnt_bytes > 128) {
>>    [store 128 bytes];
>>    cnt_bytes -= 128;
>> }
>> [store tail of 0..127 bytes];
>> 
>> 
>> 
>> Both existing and proposed implementations specifically handle zero fill case (see comments about ZVA). New implementation contains a path for very small arrays that can be cut to further improve more generic case (added to avoid regressions).
>> 
>> The check added in https://bugs.openjdk.org/browse/JDK-8298720 in StubGenerator is removed as it is a stub code being generated. For the selected threshold, the increase in code size is within 8 KB.
>> 
>> New test TestArraysFill is added to intrinsics jtreg tests. It calls optimized versions of 2-arg and 4-arg Arrays.fill() for different data types, lengths and patterns. The target data is checked to be filled with the required value, the surrounding data is checked to be intact.
>> 
>> Existing test/micro/org/openjdk/bench/java/util/ArraysFill.java benchmark was used only initially. There are many cases and data lengths to cover. A modified version of the benchmark is attached [1] to the RFE, but not included in the change as it takes too long to complete all valuable variants.
>> 
>> Resulting performance data are listed in the spreadsheet [2] attache to the RFE. Target processors were Graviton 3, Graviton 2, TaiShan, A72 and A53. Latest data from Altra is not included but the picture there was similar to Graviton 2 in all experiments. There is a range of target lengths with various enhancement numbers. Interesting lengths are within table implementation threshold and close to them (stepped), small lengths (all) and long lengths (1 point, they look similar). Over this voluntary selection:
>> 
>> - No major regressions were found.
>> - Geomean improvement: 11-33%
>> - Median improvement: 10-48%
>> 
>> Testing: tier1, tier2 and the new test on fastdebug aarch64 and x86.
>> 
>> [1] https://bugs.openjdk.org/secure/attachment/102426/ArraysFill.java
>> [2] https://bugs.openjdk.org/secure/attachment/102427/arrays-fill.ods
>
> Dmitry Chuyko 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 JDK-8300669
>  - Var in test
>  - Merge branch 'openjdk:master' into JDK-8300669
>  - Wording about alignment
>  - Fixed compilation on win/mac
>  - Merge branch 'openjdk:master' into JDK-8300669
>  - Table based arrays_fill stub implementation for aarch64

It is not so easy to see icache pressure in benchmarks but all branching penalties show up quickly. Current patch allows tuning of the table size. It actually can be a mask to allow certain lengths. So for any known application where icache pressure is significant it is possible to try different table volumes.

-------------

PR: https://git.openjdk.org/jdk/pull/12222

From sspitsyn at openjdk.org  Thu Mar 16 05:24:59 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 16 Mar 2023 05:24:59 GMT
Subject: RFR: 8304303: implement VirtualThread class notifyJvmti methods as C2
 intrinsics
Message-ID: <-Pt3zLSu1Y2GYeM8XEivglUyDVXlAqMIA42-_zEnHlo=.7dd40f19-160a-4f11-8702-99c69a9b9923@github.com>

This is needed for performance improvements in support of virtual threads.
The update includes the following:

1. Refactored the `VirtualThread` native methods:
    `notifyJvmtiMountBegin`     and `notifyJvmtiMountEnd`      => `notifyJvmtiMount`
    `notifyJvmtiUnmountBegin` and `notifyJvmtiUnmountEnd` => `notifyJvmtiUnmount`
2. Still useful implementation of old native methods is moved from `jvm.cpp` to `jvmtiThreadState.cpp`:
     `JVM_VirtualThreadMountStart`       => `VTMS_mount_begin`
     `JVM_VirtualThreadMountEnd`         => `VTMS_mount_end`
     `JVM_VirtualThreadUnmountStart`  = > `VTMS_unmount_begin`
     `JVM_VirtualThreadUnmountEnd`    => `VTMS_mount_end`
3. Intrinsified the `VirtualThread` native methods: `notifyJvmtiMount`, `notifyJvmtiUnmount`, `notifyJvmtiHideFrames`.
4. Removed the`VirtualThread` static boolean state variable `notifyJvmtiEvents` and its support in `javaClasses`.
5. Added static boolean state variable `_VTMS_notify_jvmti_events` to the jvmtiVTMSTransitionDisabler class as a replacement of the `VirtualThread` `notifyJvmtiEvents` variable.

Implementing the same methods as C1 intrinsics can be needed in the future but is a low priority for now.  

Testing:
 - Ran mach5 tiers 1-6. No regressions were found.

-------------

Commit messages:
 - fix traling spaces in a couple of files
 - minor update for VTMS_notify_jvmti_events variable
 - 8304303: implement VirtualThread class notifyJvmti methods as C2 intrinsics

Changes: https://git.openjdk.org/jdk/pull/13054/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13054&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304303
  Stats: 438 lines in 20 files changed: 265 ins; 125 del; 48 mod
  Patch: https://git.openjdk.org/jdk/pull/13054.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/13054/head:pull/13054

PR: https://git.openjdk.org/jdk/pull/13054

From dholmes at openjdk.org  Thu Mar 16 05:48:31 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 16 Mar 2023 05:48:31 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v26]
In-Reply-To: <jsmz2mhexRS1UJfJqwDQrxuBW2VTTQmwiTFczT5IPUY=.35e362c4-843d-4ec3-a67c-05425c08fd37@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <kmN_C8IN6Tj01P86gjrctndLD7Wrxw8m51f4msPK-Ak=.eccc9b74-4c3b-49ab-bded-d39aa4d15518@github.com>
 <sfWbIK24VrWl9RqsDBQh4I3T2xmp8KHDVMiQPWbk694=.b2a9ab0d-fa72-4aa9-8bfd-a68732144868@github.com>
 <LqDlCifR-tcEv3WR4_50xOOPw6XipCD9QYrLazD7LuY=.e87dc186-3d7c-4ae8-b13a-d6e7830581fb@github.com>
 <yKKfoChVqMXXdz4or0EdJRubfoO-HKa4vA1UeHpsmRk=.656ab4fe-4f99-4731-9dc7-1849c86d1df6@github.com>
 <jsmz2mhexRS1UJfJqwDQrxuBW2VTTQmwiTFczT5IPUY=.35e362c4-843d-4ec3-a67c-05425c08fd37@github.com>
Message-ID: <OEFo8krJgrHQOk8hZ69lkMK41b6wITrw-hnVpgFDjus=.f1097bdf-dbaa-4644-be63-d61a1346fdb7@github.com>

On Wed, 15 Mar 2023 19:40:33 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>>> Would it be possible to open/send me the failing test that triggers vframeArray assert
>>> or extract a reproducer that you could publish?
>> 
>> I have started an internal discussion at Oracle to see what it would take
>> to move that test from closed to open. Will keep you posted.
>
>> > Would it be possible to open/send me the failing test that triggers vframeArray assert
>> > or extract a reproducer that you could publish?
>> 
>> I have started an internal discussion at Oracle to see what it would take to move that test from closed to open. Will keep you posted.
> 
> Thank you!
> 
> Regarding moving this PR back to draft, I am not sure. I can do that, yes. But really the fundamental algorithm and implementation is basically fixed since half a year already. I have re-worked it into a fresh PR based on the request to put it behind a flag. The recent change to a fixed-size lock-stack has probably invalidated part of your previous reviews, and I am sorry for that. On the upside, it removed a lot of complexity in the JIT compilers and assembly code generators.
> 
> What else do I expect to happen?
> 
> Thomas is working on an ARM(32) port, but this is quite separate and could even land after this PR is done.
> 
> I still don't quite like the naming. Fast-locking doesn't really say anything and it's not (meant to be) faster than the previous stack-locking. It is an alternative (and less racy, on the object header) way to implement a thin-locking layer before inflating monitors, that is all. So maybe -XX:+UseNewThinLocking? It is somewhat temporary anyway. At least my hope is that when we eventually switch to Lilliput turned on by default, we would entirely remove stack-locking.
> 
> I would also add some code in arguments.cpp to keep this new thin locking turned off on platforms that don't yet support it.
> 
> Besides that, from my POV, it is pretty much done.
> 
> What do you think?

@rkennke The changed to fixed-size lock stack was a significant change as you note and that suggested to me that the design was still in flux. So I have to wonder whether everything is in fact now stable? (or as stable as one should expect for an experimental new feature)

> Fast-locking doesn't really say anything and it's not (meant to be) faster than the previous stack-locking.

Agreed. But I don't think "Thin locks" is an option as that was specifically an IBM locking implementation. Historically Hotspot's locking mechanism has internally been referred to as stack-locks, so I would suggest UseNewStackLocks

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From stuefe at openjdk.org  Thu Mar 16 06:08:34 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 16 Mar 2023 06:08:34 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v26]
In-Reply-To: <OEFo8krJgrHQOk8hZ69lkMK41b6wITrw-hnVpgFDjus=.f1097bdf-dbaa-4644-be63-d61a1346fdb7@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <kmN_C8IN6Tj01P86gjrctndLD7Wrxw8m51f4msPK-Ak=.eccc9b74-4c3b-49ab-bded-d39aa4d15518@github.com>
 <sfWbIK24VrWl9RqsDBQh4I3T2xmp8KHDVMiQPWbk694=.b2a9ab0d-fa72-4aa9-8bfd-a68732144868@github.com>
 <LqDlCifR-tcEv3WR4_50xOOPw6XipCD9QYrLazD7LuY=.e87dc186-3d7c-4ae8-b13a-d6e7830581fb@github.com>
 <yKKfoChVqMXXdz4or0EdJRubfoO-HKa4vA1UeHpsmRk=.656ab4fe-4f99-4731-9dc7-1849c86d1df6@github.com>
 <jsmz2mhexRS1UJfJqwDQrxuBW2VTTQmwiTFczT5IPUY=.35e362c4-843d-4ec3-a67c-05425c08fd37@github.com>
 <OEFo8krJgrHQOk8hZ69lkMK41b6wITrw-hnVpgFDjus=.f1097bdf-dbaa-4644-be63-d61a1346fdb7@github.com>
Message-ID: <4ID9G5P6KGhzXLzlOEc2_lcAlMUo2GppzSA_gazLT2Q=.f3299b50-20f6-4666-9a60-4145edf3c5ee@github.com>

On Thu, 16 Mar 2023 05:45:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Agreed. But I don't think "Thin locks" is an option as that was specifically an IBM locking implementation. Historically Hotspot's locking mechanism has internally been referred to as stack-locks, so I would suggest UseNewStackLocks

They don't use the stack anymore; would this not be us using a wrong name just for history's sake?

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From dholmes at openjdk.org  Thu Mar 16 06:26:59 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 16 Mar 2023 06:26:59 GMT
Subject: RFR: 8303150: DCmd framework unnecessarily creates a DCmd instance
 on registration [v3]
In-Reply-To: <TNyX996lKlRcmTijRTN0VUZBcNBt2DXeMPhDBjaa0NQ=.160293b7-4570-43a5-af9e-d9cb02022820@github.com>
References: <TNyX996lKlRcmTijRTN0VUZBcNBt2DXeMPhDBjaa0NQ=.160293b7-4570-43a5-af9e-d9cb02022820@github.com>
Message-ID: <VN7u25apI6m6C4-zqOZRiVW_c_2EjM58qAryREhhj1c=.68671c58-49f4-4827-889c-045f6ea422ba@github.com>

> When DCmd factories are registered, the factory is passed the number of arguments taken by the DCmd - using a template method `get_num_arguments`. For DCmds that don't extend DCmdWithParser there has to be a static `num_arguments()` method in that class. For DCmds that do extend DCmdWithParser the logic instantiates an instance of the DCmd, extracts its parser and calls its `num_arguments` method which dynamically counts the number of defined arguments.
> 
> Creating an instance of each DCmd and dynamically counting arguments is inefficient and unnecessary, the number of arguments is statically known and easily expressed (in fact many of the JFR DCmds already statically define this). So we add the static `num_arguments()` method to each class that needs it and return the statically counted number of arguments. To ensure the static number and actual number don't get out-of-sync, we keep the original dynamic logic for use in debug builds to assert that the static and dynamic counts are the same. The assert will trigger during a debug build if something does get out of sync, for example if a new DCmd (extending DCmdWithParser) were added but didn't define the static `num_arguments()` method.
> 
> A number of DCmd classes were unnecessarily defining their own dynamic version of `num_arguments` and these are now removed.
> 
> In the template method I use `ENABLE_IF(std::is_convertible<T, DCmd>::value)` to check we only call this on DCmd classes. This may be unnecessary but it seemed consistent with the other template methods. Note that `std::is_base_of` only works for immediate super types.
> 
> Testing: tiers 1-4
> 
> Performance: in theory we should see some improvement in startup; in practice it is barely noticeable.
> 
> Thanks.

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Make get_parsed_num_arguments() ASSERT only code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12994/files
  - new: https://git.openjdk.org/jdk/pull/12994/files/cfe345d8..fc46d253

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12994&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12994&range=01-02

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12994.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12994/head:pull/12994

PR: https://git.openjdk.org/jdk/pull/12994

From stuefe at openjdk.org  Thu Mar 16 06:26:59 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 16 Mar 2023 06:26:59 GMT
Subject: RFR: 8303150: DCmd framework unnecessarily creates a DCmd instance
 on registration [v3]
In-Reply-To: <VN7u25apI6m6C4-zqOZRiVW_c_2EjM58qAryREhhj1c=.68671c58-49f4-4827-889c-045f6ea422ba@github.com>
References: <TNyX996lKlRcmTijRTN0VUZBcNBt2DXeMPhDBjaa0NQ=.160293b7-4570-43a5-af9e-d9cb02022820@github.com>
 <VN7u25apI6m6C4-zqOZRiVW_c_2EjM58qAryREhhj1c=.68671c58-49f4-4827-889c-045f6ea422ba@github.com>
Message-ID: <24zSArtcqklQwi5GcF6x0D3j948ZShoGaOq4eXhGQ2g=.5a045f65-8ef4-43df-8e60-11456450deb7@github.com>

On Thu, 16 Mar 2023 06:22:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> When DCmd factories are registered, the factory is passed the number of arguments taken by the DCmd - using a template method `get_num_arguments`. For DCmds that don't extend DCmdWithParser there has to be a static `num_arguments()` method in that class. For DCmds that do extend DCmdWithParser the logic instantiates an instance of the DCmd, extracts its parser and calls its `num_arguments` method which dynamically counts the number of defined arguments.
>> 
>> Creating an instance of each DCmd and dynamically counting arguments is inefficient and unnecessary, the number of arguments is statically known and easily expressed (in fact many of the JFR DCmds already statically define this). So we add the static `num_arguments()` method to each class that needs it and return the statically counted number of arguments. To ensure the static number and actual number don't get out-of-sync, we keep the original dynamic logic for use in debug builds to assert that the static and dynamic counts are the same. The assert will trigger during a debug build if something does get out of sync, for example if a new DCmd (extending DCmdWithParser) were added but didn't define the static `num_arguments()` method.
>> 
>> A number of DCmd classes were unnecessarily defining their own dynamic version of `num_arguments` and these are now removed.
>> 
>> In the template method I use `ENABLE_IF(std::is_convertible<T, DCmd>::value)` to check we only call this on DCmd classes. This may be unnecessary but it seemed consistent with the other template methods. Note that `std::is_base_of` only works for immediate super types.
>> 
>> Testing: tiers 1-4
>> 
>> Performance: in theory we should see some improvement in startup; in practice it is barely noticeable.
>> 
>> Thanks.
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make get_parsed_num_arguments() ASSERT only code

@dholmes-ora thanks for the explanation and the added ASSERT. LGTM

-------------

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12994

From rkennke at openjdk.org  Thu Mar 16 06:34:35 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 16 Mar 2023 06:34:35 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v26]
In-Reply-To: <jsmz2mhexRS1UJfJqwDQrxuBW2VTTQmwiTFczT5IPUY=.35e362c4-843d-4ec3-a67c-05425c08fd37@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <kmN_C8IN6Tj01P86gjrctndLD7Wrxw8m51f4msPK-Ak=.eccc9b74-4c3b-49ab-bded-d39aa4d15518@github.com>
 <sfWbIK24VrWl9RqsDBQh4I3T2xmp8KHDVMiQPWbk694=.b2a9ab0d-fa72-4aa9-8bfd-a68732144868@github.com>
 <LqDlCifR-tcEv3WR4_50xOOPw6XipCD9QYrLazD7LuY=.e87dc186-3d7c-4ae8-b13a-d6e7830581fb@github.com>
 <yKKfoChVqMXXdz4or0EdJRubfoO-HKa4vA1UeHpsmRk=.656ab4fe-4f99-4731-9dc7-1849c86d1df6@github.com>
 <jsmz2mhexRS1UJfJqwDQrxuBW2VTTQmwiTFczT5IPUY=.35e362c4-843d-4ec3-a67c-05425c08fd37@github.com>
Message-ID: <aoB13mNY0HkGEHjp7nTlsS99d5kao0TUjFSSLOhZGK0=.cd3eaad3-ff0c-46b6-b511-6e0bc3d2871f@github.com>

On Wed, 15 Mar 2023 19:40:33 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>>> Would it be possible to open/send me the failing test that triggers vframeArray assert
>>> or extract a reproducer that you could publish?
>> 
>> I have started an internal discussion at Oracle to see what it would take
>> to move that test from closed to open. Will keep you posted.
>
>> > Would it be possible to open/send me the failing test that triggers vframeArray assert
>> > or extract a reproducer that you could publish?
>> 
>> I have started an internal discussion at Oracle to see what it would take to move that test from closed to open. Will keep you posted.
> 
> Thank you!
> 
> Regarding moving this PR back to draft, I am not sure. I can do that, yes. But really the fundamental algorithm and implementation is basically fixed since half a year already. I have re-worked it into a fresh PR based on the request to put it behind a flag. The recent change to a fixed-size lock-stack has probably invalidated part of your previous reviews, and I am sorry for that. On the upside, it removed a lot of complexity in the JIT compilers and assembly code generators.
> 
> What else do I expect to happen?
> 
> Thomas is working on an ARM(32) port, but this is quite separate and could even land after this PR is done.
> 
> I still don't quite like the naming. Fast-locking doesn't really say anything and it's not (meant to be) faster than the previous stack-locking. It is an alternative (and less racy, on the object header) way to implement a thin-locking layer before inflating monitors, that is all. So maybe -XX:+UseNewThinLocking? It is somewhat temporary anyway. At least my hope is that when we eventually switch to Lilliput turned on by default, we would entirely remove stack-locking.
> 
> I would also add some code in arguments.cpp to keep this new thin locking turned off on platforms that don't yet support it.
> 
> Besides that, from my POV, it is pretty much done.
> 
> What do you think?

> @rkennke The changed to fixed-size lock stack was a significant change as you note and that suggested to me that the design was still in flux. So I have to wonder whether everything is in fact now stable? (or as stable as one should expect for an experimental new feature)

I think it is, except for the few points that I mentioned earlier, and anything that comes up in reviews, I don't expect any major design changes. In fact, I would actively hold them back if anything comes up, to move this PR across the line at this point. I can't think of any bad spots where I thunk 'oh this is ugly - this needs a better approach' though.


> > Fast-locking doesn't really say anything and it's not (meant to be) faster than the previous stack-locking.
> 
> 
> 
> Agreed. But I don't think "Thin locks" is an option as that was specifically an IBM locking implementation. Historically Hotspot's locking mechanism has internally been referred to as stack-locks, so I would suggest UseNewStackLocks

That's fine by me.

Thank you,
Roman

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From rkennke at openjdk.org  Thu Mar 16 06:34:36 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 16 Mar 2023 06:34:36 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v26]
In-Reply-To: <4ID9G5P6KGhzXLzlOEc2_lcAlMUo2GppzSA_gazLT2Q=.f3299b50-20f6-4666-9a60-4145edf3c5ee@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <kmN_C8IN6Tj01P86gjrctndLD7Wrxw8m51f4msPK-Ak=.eccc9b74-4c3b-49ab-bded-d39aa4d15518@github.com>
 <sfWbIK24VrWl9RqsDBQh4I3T2xmp8KHDVMiQPWbk694=.b2a9ab0d-fa72-4aa9-8bfd-a68732144868@github.com>
 <LqDlCifR-tcEv3WR4_50xOOPw6XipCD9QYrLazD7LuY=.e87dc186-3d7c-4ae8-b13a-d6e7830581fb@github.com>
 <yKKfoChVqMXXdz4or0EdJRubfoO-HKa4vA1UeHpsmRk=.656ab4fe-4f99-4731-9dc7-1849c86d1df6@github.com>
 <jsmz2mhexRS1UJfJqwDQrxuBW2VTTQmwiTFczT5IPUY=.35e362c4-843d-4ec3-a67c-05425c08fd37@github.com>
 <OEFo8krJgrHQOk8hZ69lkMK41b6wITrw-hnVpgFDjus=.f1097bdf-dbaa-4644-be63-d61a1346fdb7@github.com>
 <4ID9G5P6KGhzXLzlOEc2_lcAlMUo2GppzSA_gazLT2Q=.f3299b50-20f6-4666-9a60-4145edf3c5ee@github.com>
Message-ID: <j8XI8la6DG03xPDg6tABxovTzB6h8G6GmTx5FaHtrwU=.4d971db1-7fca-4d5c-aa44-c12968cf8241@github.com>

On Thu, 16 Mar 2023 06:05:38 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> 
> 
> > Agreed. But I don't think "Thin locks" is an option as that was specifically an IBM locking implementation. Historically Hotspot's locking mechanism has internally been referred to as stack-locks, so I would suggest UseNewStackLocks
> 
> 
> 
> They don't use the stack anymore; would this not be us using a wrong name just for history's sake?

Well, it's still got the lock-stacks. :-D

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From dholmes at openjdk.org  Thu Mar 16 06:35:22 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 16 Mar 2023 06:35:22 GMT
Subject: RFR: 8303150: DCmd framework unnecessarily creates a DCmd instance
 on registration [v3]
In-Reply-To: <24zSArtcqklQwi5GcF6x0D3j948ZShoGaOq4eXhGQ2g=.5a045f65-8ef4-43df-8e60-11456450deb7@github.com>
References: <TNyX996lKlRcmTijRTN0VUZBcNBt2DXeMPhDBjaa0NQ=.160293b7-4570-43a5-af9e-d9cb02022820@github.com>
 <VN7u25apI6m6C4-zqOZRiVW_c_2EjM58qAryREhhj1c=.68671c58-49f4-4827-889c-045f6ea422ba@github.com>
 <24zSArtcqklQwi5GcF6x0D3j948ZShoGaOq4eXhGQ2g=.5a045f65-8ef4-43df-8e60-11456450deb7@github.com>
Message-ID: <FfNcjqzxYFB_LEnAWCgMujjH3IIHkVbyfDuvGJcw0zE=.b85e87c5-fe42-4fc8-b5a4-bf3c650d6722@github.com>

On Thu, 16 Mar 2023 06:21:48 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make get_parsed_num_arguments() ASSERT only code
>
> @dholmes-ora thanks for the explanation and the added ASSERT. LGTM

Thanks for the review @tstuefe . I will wait for some final build checks and then integrate.

-------------

PR: https://git.openjdk.org/jdk/pull/12994

From stuefe at openjdk.org  Thu Mar 16 06:42:32 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 16 Mar 2023 06:42:32 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v26]
In-Reply-To: <j8XI8la6DG03xPDg6tABxovTzB6h8G6GmTx5FaHtrwU=.4d971db1-7fca-4d5c-aa44-c12968cf8241@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <kmN_C8IN6Tj01P86gjrctndLD7Wrxw8m51f4msPK-Ak=.eccc9b74-4c3b-49ab-bded-d39aa4d15518@github.com>
 <sfWbIK24VrWl9RqsDBQh4I3T2xmp8KHDVMiQPWbk694=.b2a9ab0d-fa72-4aa9-8bfd-a68732144868@github.com>
 <LqDlCifR-tcEv3WR4_50xOOPw6XipCD9QYrLazD7LuY=.e87dc186-3d7c-4ae8-b13a-d6e7830581fb@github.com>
 <yKKfoChVqMXXdz4or0EdJRubfoO-HKa4vA1UeHpsmRk=.656ab4fe-4f99-4731-9dc7-1849c86d1df6@github.com>
 <jsmz2mhexRS1UJfJqwDQrxuBW2VTTQmwiTFczT5IPUY=.35e362c4-843d-4ec3-a67c-05425c08fd37@github.com>
 <OEFo8krJgrHQOk8hZ69lkMK41b6wITrw-hnVpgFDjus=.f1097bdf-dbaa-4644-be63-d61a1346fdb7@github.com>
 <4ID9G5P6KGhzXLzlOEc2_lcAlMUo2GppzSA_gazLT2Q=.f3299b50-20f6-4666-9a60-4145edf3c5ee@github.com>
 <j8XI8la6DG03xPDg6tABxovTzB6h8G6GmTx5FaHtrwU=.4d971db1-7fca-4d5c-aa44-c12968cf8241@github.com>
Message-ID: <dAoPPU5vvfCr8tD4FDwYlHtZwCxw0Oj5WxMB8ZENrBQ=.f2edb84b-00fe-4e89-b555-1244756338e9@github.com>

On Thu, 16 Mar 2023 06:31:42 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> > > Agreed. But I don't think "Thin locks" is an option as that was specifically an IBM locking implementation. Historically Hotspot's locking mechanism has internally been referred to as stack-locks, so I would suggest UseNewStackLocks
> > 
> > 
> > They don't use the stack anymore; would this not be us using a wrong name just for history's sake?
> 
> Well, it's still got the lock-stacks. :-D

Yes, but we have variables like "is_stack_locked" etc, without an "old" qualifier. Idk, up to you. Better than UseFastLocking I guess.

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From sspitsyn at openjdk.org  Thu Mar 16 07:11:00 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 16 Mar 2023 07:11:00 GMT
Subject: RFR: 8304303: implement VirtualThread class notifyJvmti methods as
 C2 intrinsics [v2]
In-Reply-To: <-Pt3zLSu1Y2GYeM8XEivglUyDVXlAqMIA42-_zEnHlo=.7dd40f19-160a-4f11-8702-99c69a9b9923@github.com>
References: <-Pt3zLSu1Y2GYeM8XEivglUyDVXlAqMIA42-_zEnHlo=.7dd40f19-160a-4f11-8702-99c69a9b9923@github.com>
Message-ID: <Adn9EZmhQ6TiCj3HfvqaAT3KXny2LzFL4E8K8J0YLzQ=.b089bd9c-0521-47a9-a6f1-bc425bf02f10@github.com>

> This is needed for performance improvements in support of virtual threads.
> The update includes the following:
> 
> 1. Refactored the `VirtualThread` native methods:
>     `notifyJvmtiMountBegin`     and `notifyJvmtiMountEnd`      => `notifyJvmtiMount`
>     `notifyJvmtiUnmountBegin` and `notifyJvmtiUnmountEnd` => `notifyJvmtiUnmount`
> 2. Still useful implementation of old native methods is moved from `jvm.cpp` to `jvmtiThreadState.cpp`:
>      `JVM_VirtualThreadMountStart`       => `VTMS_mount_begin`
>      `JVM_VirtualThreadMountEnd`         => `VTMS_mount_end`
>      `JVM_VirtualThreadUnmountStart`  = > `VTMS_unmount_begin`
>      `JVM_VirtualThreadUnmountEnd`    => `VTMS_mount_end`
> 3. Intrinsified the `VirtualThread` native methods: `notifyJvmtiMount`, `notifyJvmtiUnmount`, `notifyJvmtiHideFrames`.
> 4. Removed the`VirtualThread` static boolean state variable `notifyJvmtiEvents` and its support in `javaClasses`.
> 5. Added static boolean state variable `_VTMS_notify_jvmti_events` to the jvmtiVTMSTransitionDisabler class as a replacement of the `VirtualThread` `notifyJvmtiEvents` variable.
> 
> Implementing the same methods as C1 intrinsics can be needed in the future but is a low priority for now.  
> 
> Testing:
>  - Ran mach5 tiers 1-6. No regressions were found.

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  include jniHandles.hpp into sharedRuntime.cpp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13054/files
  - new: https://git.openjdk.org/jdk/pull/13054/files/8a379320..397b6337

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13054&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13054&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13054.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/13054/head:pull/13054

PR: https://git.openjdk.org/jdk/pull/13054

From dholmes at openjdk.org  Thu Mar 16 07:16:20 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 16 Mar 2023 07:16:20 GMT
Subject: RFR: 8304089: Convert TraceDependencies to UL [v3]
In-Reply-To: <tLhX6beNey8aikbBH30RbCu7lfXZ9AWG2KYqKWVvnkw=.a41fbeb0-6c04-4b6a-824a-fc9fdf734fd2@github.com>
References: <0aGc1NdAjpvksCWmXb1gZOPp9MV0n6xWvG8EaEp2ZLg=.b79cf218-9a23-420d-bec5-7509b7f8f1c1@github.com>
 <BQzDwBUOHbm1v3Ex5uAT56pIQJtoT8ON4ZmFhi3TvR0=.ce86f07b-4136-4870-93f0-c9723c80795b@github.com>
 <13yGfFhRFEsjHA-ox_6GxPiyU8w_hpQtgjHbsw6Glq0=.c2330c3f-0316-4f4c-aade-b6ad6c8543ee@github.com>
 <tLhX6beNey8aikbBH30RbCu7lfXZ9AWG2KYqKWVvnkw=.a41fbeb0-6c04-4b6a-824a-fc9fdf734fd2@github.com>
Message-ID: <2IKS8cYMhoU1JRBEalwF1ZeV4Vih78eXffu_GXZ4JkQ=.27d433ac-1f04-47ce-a177-c791a42bc6fe@github.com>

On Wed, 15 Mar 2023 12:55:31 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/runtime/arguments.cpp line 3589:
>> 
>>> 3587:       PrintCompilation || PrintInlining || PrintDependencies || PrintNativeNMethods ||
>>> 3588:       PrintDebugInfo || PrintRelocations || PrintNMethods || PrintExceptionHandlers ||
>>> 3589:       PrintAssembly || TraceDeoptimization || log_is_enabled(Debug, dependencies) ||
>> 
>> Now TraceDependencies is converted to UL I think it should just be deleted from this function. We don't need to enable LogVMOutput in that case.
>
> No, this is the right thing to do.  If -Xlog:dependency - the compiler group also expects the dependency printed to the compiler log file.  The logging is a separate mechanism, but should be enabled with -Xlog:dependency.

Sorry I don't follow that. `use_vm_log()` only affects non-product builds and forces `LogVMOutput` to true. That in turn will cause `defaultStream::init_log()` to execute which initializes the log file etc. But I don't see how that would cause UL logging for "dependencies" to also get written to the log file???

-------------

PR: https://git.openjdk.org/jdk/pull/13007

From dholmes at openjdk.org  Thu Mar 16 07:26:27 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 16 Mar 2023 07:26:27 GMT
Subject: RFR: JDK-8301498: Replace NULL with nullptr in cpu/x86 [v3]
In-Reply-To: <Dt5DVW6D3E3khwTaDNTy3kcrxJmv_fEK37iXonS06C8=.ab98f698-1dc3-4d64-b57a-cb69493a38a0@github.com>
References: <AB1094dam2aXNm_hav09Ium0jqJUCJE0hmJ4GfljA5M=.4e8e0845-20d5-45bf-bf2e-1d23ed8ef9f0@github.com>
 <Dt5DVW6D3E3khwTaDNTy3kcrxJmv_fEK37iXonS06C8=.ab98f698-1dc3-4d64-b57a-cb69493a38a0@github.com>
Message-ID: <WvhEKGTKdo6s6aAVpb1BsOSEtjmY2sbQsYVyrSgPljc=.5a3d5b0d-4008-42b8-a8b2-4c82596991c0@github.com>

On Wed, 15 Mar 2023 11:09:25 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory cpu/x86. Unfortunately the script that does the change isn't perfect, and so we
>> need to comb through these manually to make sure nothing has gone wrong. I also review these changes but things slip past my eyes sometimes.
>> 
>> Here are some typical things to look out for:
>> 
>> 1. No changes but copyright header changed (probably because I reverted some changes but forgot the copyright).
>> 2. Macros having their NULL changed to nullptr, these are added to the script when I find them. They should be NULL.
>> 3. nullptr in comments and logs. We try to use lower case "null" in these cases as it reads better. An exception is made when code expressions are in a comment.
>> 
>> An example of this:
>> 
>> ```c++
>> // This function returns null
>> void* ret_null();
>> // This function returns true if *x == nullptr
>> bool is_nullptr(void** x);
>> 
>> 
>> Note how `nullptr` participates in a code expression here, we really are talking about the specific value `nullptr`.
>> 
>> Thanks!
>
> Johan Sj?len has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Fix vnkozlov's suggestions
>  - Merge remote-tracking branch 'origin/master' into JDK-8301498
>  - Some more fixes
>  - Fixes
>  -  Replace NULL with nullptr in cpu/x86

Still good. Thanks.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12326

From dholmes at openjdk.org  Thu Mar 16 07:34:36 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 16 Mar 2023 07:34:36 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v27]
In-Reply-To: <AmDOQhS1AzZxHd0kV_jhUWSGVdt8NZbfMVydFpHnQjs=.eff82b60-de1c-45e8-b54b-183b174b63d9@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <AmDOQhS1AzZxHd0kV_jhUWSGVdt8NZbfMVydFpHnQjs=.eff82b60-de1c-45e8-b54b-183b174b63d9@github.com>
Message-ID: <wlMLp4mW5UPwDJvPQfa2uNL3mnz1EGLw0XhJLQdgm4g=.64bacb3d-1a74-4777-a74d-5035d1bc7083@github.com>

On Wed, 15 Mar 2023 09:41:30 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - More RISCV changes (by Fei Yang)
>  - Use -w instructions in fast_unlock()
>  - Increase stub size of C2HandleAnonOwnerStub to 18

I agree "stack lock" is not ideal even though we do still have lock-stacks. :) But "thin locks" is definitely out, and "fast lock" seems generally agreed to be meaningless.

How about just UseNewLocks ? Or UseNewMarkWordLocks?

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From stuefe at openjdk.org  Thu Mar 16 08:03:38 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 16 Mar 2023 08:03:38 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v27]
In-Reply-To: <AmDOQhS1AzZxHd0kV_jhUWSGVdt8NZbfMVydFpHnQjs=.eff82b60-de1c-45e8-b54b-183b174b63d9@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <AmDOQhS1AzZxHd0kV_jhUWSGVdt8NZbfMVydFpHnQjs=.eff82b60-de1c-45e8-b54b-183b174b63d9@github.com>
Message-ID: <fJPZlXXfC4R6uF5y1eNH1VZQvbfsQJRV0AanNhOMTg0=.035e4a11-c6e3-4b3b-9539-77129c2b9120@github.com>

On Wed, 15 Mar 2023 09:41:30 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - More RISCV changes (by Fei Yang)
>  - Use -w instructions in fast_unlock()
>  - Increase stub size of C2HandleAnonOwnerStub to 18

I like UseNewLocks but fear that this may conflict with Oracles plan (?) to move OMs into heap, which would be another revamp of locking - fat locks in this case - and may come with yet another switch. Other than that, UseNewLocks sounds good and succinct.

Another proposal: UseThreadLockStack or UseLockStack

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From rehn at openjdk.org  Thu Mar 16 08:15:38 2023
From: rehn at openjdk.org (Robbin Ehn)
Date: Thu, 16 Mar 2023 08:15:38 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v27]
In-Reply-To: <fJPZlXXfC4R6uF5y1eNH1VZQvbfsQJRV0AanNhOMTg0=.035e4a11-c6e3-4b3b-9539-77129c2b9120@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <AmDOQhS1AzZxHd0kV_jhUWSGVdt8NZbfMVydFpHnQjs=.eff82b60-de1c-45e8-b54b-183b174b63d9@github.com>
 <fJPZlXXfC4R6uF5y1eNH1VZQvbfsQJRV0AanNhOMTg0=.035e4a11-c6e3-4b3b-9539-77129c2b9120@github.com>
Message-ID: <QB5HAJs3E1f5R_7eiSRVbC5ilf2rJ7q5Wxpt6BKivWI=.d7f33734-ba24-4aac-84f2-f9c6f2a8a581@github.com>

On Thu, 16 Mar 2023 08:00:38 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> I like UseNewLocks but fear that this may conflict with Oracles plan (?) to move OMs into heap, which would be another revamp of locking - fat locks in this case - and may come with yet another switch. Other than that, UseNewLocks sounds good and succinct.
> 
> Another proposal: UseThreadLockStack or UseLockStack

Just a FYI, at the moment we have:

  product(ccstr, ObjectSynchronizerMode, "fast",                            \
          "ObjectSynchronizer modes: "                                      \
          "legacy: legacy native system; "                                  \
          "native: java entry with native monitors; "                       \
          "heavy: java entry with always inflated Java monitors; "          \
          "fast: java entry with fast-locks and"                            \
          "      inflate-on-demand Java monitors; ")                        \



At least personally I prefer one option than using many.
A cmd line with e.g.
`-XX:-UseLockStack -XX:+UseHeavyMonitors`
It's harder, for me ?, to figure out what is selected and what was intended to be selected.

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From mdoerr at openjdk.org  Thu Mar 16 08:30:24 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 16 Mar 2023 08:30:24 GMT
Subject: RFR: 8296440: Remove Method* handling from
 cleanup_inline_caches_impl
In-Reply-To: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
References: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
Message-ID: <Pf0b1gAjDzw5iEU8_qnNUJH_wWIxPVG2hqUpRO4DJOg=.8395389d-36cb-4801-af4b-202ec873cc57@github.com>

On Wed, 1 Mar 2023 11:07:36 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> This PR replaces cleaning of static stubs in CompiledMethod::cleanup_inline_caches_impl() with a guarantee that it is actually not needed because the holder of the embedded target Method* is alive if the caller nmethod is not unloading.
> 
> The holder of the target Method* has to be alive because it is reachable from the caller nmethod's oop pool. This is checked by `check_path_to_callee()` when a statically bound call gets resolved.
> 
> C2i entry barriers can be removed for the same reason.
> 
> Testing:
> 
> Many rounds in our CI testing which includes most JCK and JTREG tests, Renaissance benchmark and SAP specific tests with fastdebug and release builds on the standard platforms plus PPC64.
> 
> I've also done tier1 and tier2 tests with -XX:-Inline and tier1 tests with ZGC.
> 
> I've started hotspot and jdk tier1 tests with -Xcomp. They were not finished when I stopped them after 24h.

Thanks a lot for testing!
Can it happen that the `to_holder` is referenced from the instruction stream, but not from the oop constant section on x86 (or any platform with `relocInfo::mustIterateImmediateOopsInCode()`)?

-------------

PR: https://git.openjdk.org/jdk/pull/12802

From mdoerr at openjdk.org  Thu Mar 16 08:36:39 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 16 Mar 2023 08:36:39 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v16]
In-Reply-To: <CqQTng1GkfdB1wANeu6Sj3NSnOrv_T3yCz72OIHWPAY=.0191a653-287e-4753-8270-fcb3f6e7d13b@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <c5UYe1zFGgndb5SQZ71TgGXsizWiNnhiosHWm5xiVpU=.032bb845-05ad-4393-83cd-2a111dc55c85@github.com>
 <CqQTng1GkfdB1wANeu6Sj3NSnOrv_T3yCz72OIHWPAY=.0191a653-287e-4753-8270-fcb3f6e7d13b@github.com>
Message-ID: <oMRRIL3blxk6EZ0nCnBr6rksDwyASzwHF1C5ZhUMixo=.33d49733-904b-40ad-afe4-3705b2acb2c5@github.com>

On Tue, 14 Mar 2023 22:52:44 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix storing 32 bit integers into Java frames. Enable TestArrayStructs.
>
> Btw. the new cases in which we use int and short accesses when byteWidth is not a power of 2 are never unaligned AFAICS. I guess _UNALIGNED is unnecessary in the JAVA_INT_UNALIGNED and JAVA_SHORT_UNALIGNED. They are always aligned wrt. to their size.

> @TheRealMDoerr I've approved the PR. I suggest for a second reviewer to try and get someone who knows the PPC port.

Thanks for the review! I guess I should also wait for your 2 PRs to be integrated, so I can merge and adapt.

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From rkennke at openjdk.org  Thu Mar 16 08:39:39 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 16 Mar 2023 08:39:39 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v27]
In-Reply-To: <AmDOQhS1AzZxHd0kV_jhUWSGVdt8NZbfMVydFpHnQjs=.eff82b60-de1c-45e8-b54b-183b174b63d9@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <AmDOQhS1AzZxHd0kV_jhUWSGVdt8NZbfMVydFpHnQjs=.eff82b60-de1c-45e8-b54b-183b174b63d9@github.com>
Message-ID: <sSvJUuSCIClY4q7Jna2_zNvYXlvrMGnJwWxf1aN5RT4=.41df8341-3474-4e10-90ef-2ccd58b14deb@github.com>

On Wed, 15 Mar 2023 09:41:30 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - More RISCV changes (by Fei Yang)
>  - Use -w instructions in fast_unlock()
>  - Increase stub size of C2HandleAnonOwnerStub to 18

I like -XX:+UseNewLocks, too. I wouldn't overcomplicate things: this flag is meant to be transitional, it is not meant to be used by end-users (except the bravest nerds) at all. When it lands, the Lilliput flag (e.g. +UseCompactObjectHeaders) will also control the locking flag. Eventually (e.g. release+1) both flags would become on by default and afterwards (e.g. release+2) would go away entirely, at which point the whole original stack-locking would disappear.

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From stuefe at openjdk.org  Thu Mar 16 08:52:37 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 16 Mar 2023 08:52:37 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v27]
In-Reply-To: <sSvJUuSCIClY4q7Jna2_zNvYXlvrMGnJwWxf1aN5RT4=.41df8341-3474-4e10-90ef-2ccd58b14deb@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <AmDOQhS1AzZxHd0kV_jhUWSGVdt8NZbfMVydFpHnQjs=.eff82b60-de1c-45e8-b54b-183b174b63d9@github.com>
 <sSvJUuSCIClY4q7Jna2_zNvYXlvrMGnJwWxf1aN5RT4=.41df8341-3474-4e10-90ef-2ccd58b14deb@github.com>
Message-ID: <dVVJ0xiMkZDZtTEPhbnAXRmKKXWr21d8LAPAOt89xbs=.2e22b842-b6ed-4182-9049-cc05261d8fb6@github.com>

On Thu, 16 Mar 2023 08:36:45 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - More RISCV changes (by Fei Yang)
>>  - Use -w instructions in fast_unlock()
>>  - Increase stub size of C2HandleAnonOwnerStub to 18
>
> I like -XX:+UseNewLocks, too. I wouldn't overcomplicate things: this flag is meant to be transitional, it is not meant to be used by end-users (except the bravest nerds) at all. When it lands, the Lilliput flag (e.g. +UseCompactObjectHeaders) will also control the locking flag. Eventually (e.g. release+1) both flags would become on by default and afterwards (e.g. release+2) would go away entirely, at which point the whole original stack-locking would disappear.

@rkennke I must be missing something. In aarch64, why do we handle the non-symmetric-unlock case in interpreter, but not in C1/C2? There, we just seem to pop whatever is on top.

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From rkennke at openjdk.org  Thu Mar 16 09:05:39 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 16 Mar 2023 09:05:39 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v27]
In-Reply-To: <sSvJUuSCIClY4q7Jna2_zNvYXlvrMGnJwWxf1aN5RT4=.41df8341-3474-4e10-90ef-2ccd58b14deb@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <AmDOQhS1AzZxHd0kV_jhUWSGVdt8NZbfMVydFpHnQjs=.eff82b60-de1c-45e8-b54b-183b174b63d9@github.com>
 <sSvJUuSCIClY4q7Jna2_zNvYXlvrMGnJwWxf1aN5RT4=.41df8341-3474-4e10-90ef-2ccd58b14deb@github.com>
Message-ID: <1cMqmQSAilNe5gNdJj0HBvo5OJqz8wvsetLHTZgF9s4=.79f9c9f2-aac9-4cd1-9d41-3201f89c52b3@github.com>

On Thu, 16 Mar 2023 08:36:45 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - More RISCV changes (by Fei Yang)
>>  - Use -w instructions in fast_unlock()
>>  - Increase stub size of C2HandleAnonOwnerStub to 18
>
> I like -XX:+UseNewLocks, too. I wouldn't overcomplicate things: this flag is meant to be transitional, it is not meant to be used by end-users (except the bravest nerds) at all. When it lands, the Lilliput flag (e.g. +UseCompactObjectHeaders) will also control the locking flag. Eventually (e.g. release+1) both flags would become on by default and afterwards (e.g. release+2) would go away entirely, at which point the whole original stack-locking would disappear.

> @rkennke I must be missing something. In aarch64, why do we handle the non-symmetric-unlock case in interpreter, but not in C1/C2? There, we just seem to pop whatever is on top.

C1 and C2 don't allow assymmetric locking. If that ever happens, they would refuse to compile the method. We should probably check that this assumption holds true when popping the top entry in an #ASSERT block.

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From stuefe at openjdk.org  Thu Mar 16 09:09:48 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 16 Mar 2023 09:09:48 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v27]
In-Reply-To: <1cMqmQSAilNe5gNdJj0HBvo5OJqz8wvsetLHTZgF9s4=.79f9c9f2-aac9-4cd1-9d41-3201f89c52b3@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <AmDOQhS1AzZxHd0kV_jhUWSGVdt8NZbfMVydFpHnQjs=.eff82b60-de1c-45e8-b54b-183b174b63d9@github.com>
 <sSvJUuSCIClY4q7Jna2_zNvYXlvrMGnJwWxf1aN5RT4=.41df8341-3474-4e10-90ef-2ccd58b14deb@github.com>
 <1cMqmQSAilNe5gNdJj0HBvo5OJqz8wvsetLHTZgF9s4=.79f9c9f2-aac9-4cd1-9d41-3201f89c52b3@github.com>
Message-ID: <WKId5Cea6Sqas4yT4DSPSVoGLQHCLFPkQP45z1myOEg=.0157a04d-c2bd-4ce0-a3b1-7b5684141c7e@github.com>

On Thu, 16 Mar 2023 09:02:19 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> 
> > @rkennke I must be missing something. In aarch64, why do we handle the non-symmetric-unlock case in interpreter, but not in C1/C2? There, we just seem to pop whatever is on top.
> 
> C1 and C2 don't allow assymmetric locking. If that ever happens, they would refuse to compile the method. We should probably check that this assumption holds true when popping the top entry in an #ASSERT block.

Thanks for clarifying. Yes, asserting that would make sense.

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From rrich at openjdk.org  Thu Mar 16 09:10:39 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Thu, 16 Mar 2023 09:10:39 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v6]
In-Reply-To: <W4zsKKZyY_iyQNPjzB846ElfRLpq2qjZOGxlAClIylo=.dc9c343b-9ca6-41ae-b282-c53dd5b44ecf@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <ivPzEqZ4W-BVPaEyXQ82ppnb-SO-VsgOixcQoHxp6V0=.2abc12b7-76a0-4052-a675-ffb510f9f35a@github.com>
 <W4zsKKZyY_iyQNPjzB846ElfRLpq2qjZOGxlAClIylo=.dc9c343b-9ca6-41ae-b282-c53dd5b44ecf@github.com>
Message-ID: <sJd93wqNnTnSUSBMk1kcfRRZcW-dKggXRanKVSL-GYY=.7fb24d86-530a-43f4-89e8-5daa78d364d8@github.com>

On Wed, 15 Mar 2023 19:04:41 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed aarch64 interpreter mistake
>
> src/hotspot/cpu/ppc/templateTable_ppc_64.cpp line 3398:
> 
>> 3396:   const Bytecodes::Code code = bytecode();
>> 3397:   const bool is_invokeinterface  = code == Bytecodes::_invokeinterface;
>> 3398:   const bool is_invokedynamic    = code == false; // should not reach here with invokedynamic
> 
> This looks strange! I guess you wanted to delete more?

Basically I kept the local variable as a name for the (now) constant value passed in the call at L3409.

The parameter cannot be eliminated since `load_invoke_cp_cache_entry()` is declared in a shared header.

I could replace the variable reference in the call with `false /* is_invokedynamic */` if you like that better. Personally I'd prefer the current version.

-------------

PR: https://git.openjdk.org/jdk/pull/12778

From mdoerr at openjdk.org  Thu Mar 16 09:29:26 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 16 Mar 2023 09:29:26 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v6]
In-Reply-To: <sJd93wqNnTnSUSBMk1kcfRRZcW-dKggXRanKVSL-GYY=.7fb24d86-530a-43f4-89e8-5daa78d364d8@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <ivPzEqZ4W-BVPaEyXQ82ppnb-SO-VsgOixcQoHxp6V0=.2abc12b7-76a0-4052-a675-ffb510f9f35a@github.com>
 <W4zsKKZyY_iyQNPjzB846ElfRLpq2qjZOGxlAClIylo=.dc9c343b-9ca6-41ae-b282-c53dd5b44ecf@github.com>
 <sJd93wqNnTnSUSBMk1kcfRRZcW-dKggXRanKVSL-GYY=.7fb24d86-530a-43f4-89e8-5daa78d364d8@github.com>
Message-ID: <XlNLI2NCU3V0iCGb6WqO62LqoJwg9SbDecHuGyzLus8=.6d312aff-8922-4af4-8b58-fc99429749d5@github.com>

On Thu, 16 Mar 2023 09:07:27 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> src/hotspot/cpu/ppc/templateTable_ppc_64.cpp line 3398:
>> 
>>> 3396:   const Bytecodes::Code code = bytecode();
>>> 3397:   const bool is_invokeinterface  = code == Bytecodes::_invokeinterface;
>>> 3398:   const bool is_invokedynamic    = code == false; // should not reach here with invokedynamic
>> 
>> This looks strange! I guess you wanted to delete more?
>
> Basically I kept the local variable as a name for the (now) constant value passed in the call at L3409.
> 
> The parameter cannot be eliminated since `load_invoke_cp_cache_entry()` is declared in a shared header.
> 
> I could replace the variable reference in the call with `false /* is_invokedynamic */` if you like that better. Personally I'd prefer the current version.

I meant `code == false`. That was probably not intended.

-------------

PR: https://git.openjdk.org/jdk/pull/12778

From rrich at openjdk.org  Thu Mar 16 09:29:27 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Thu, 16 Mar 2023 09:29:27 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v6]
In-Reply-To: <XlNLI2NCU3V0iCGb6WqO62LqoJwg9SbDecHuGyzLus8=.6d312aff-8922-4af4-8b58-fc99429749d5@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <ivPzEqZ4W-BVPaEyXQ82ppnb-SO-VsgOixcQoHxp6V0=.2abc12b7-76a0-4052-a675-ffb510f9f35a@github.com>
 <W4zsKKZyY_iyQNPjzB846ElfRLpq2qjZOGxlAClIylo=.dc9c343b-9ca6-41ae-b282-c53dd5b44ecf@github.com>
 <sJd93wqNnTnSUSBMk1kcfRRZcW-dKggXRanKVSL-GYY=.7fb24d86-530a-43f4-89e8-5daa78d364d8@github.com>
 <XlNLI2NCU3V0iCGb6WqO62LqoJwg9SbDecHuGyzLus8=.6d312aff-8922-4af4-8b58-fc99429749d5@github.com>
Message-ID: <Fc2HIMQbXzhqymzhedoHqGHfmN1YNyTljAqw49OaK-0=.7092e59e-adf7-4b73-a1b6-0d1ea93628d7@github.com>

On Thu, 16 Mar 2023 09:21:26 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Basically I kept the local variable as a name for the (now) constant value passed in the call at L3409.
>> 
>> The parameter cannot be eliminated since `load_invoke_cp_cache_entry()` is declared in a shared header.
>> 
>> I could replace the variable reference in the call with `false /* is_invokedynamic */` if you like that better. Personally I'd prefer the current version.
>
> I meant `code == false`. That was probably not intended.

Oh my ... Your are right of course.

-------------

PR: https://git.openjdk.org/jdk/pull/12778

From rrich at openjdk.org  Thu Mar 16 09:29:30 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Thu, 16 Mar 2023 09:29:30 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v6]
In-Reply-To: <ivPzEqZ4W-BVPaEyXQ82ppnb-SO-VsgOixcQoHxp6V0=.2abc12b7-76a0-4052-a675-ffb510f9f35a@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <ivPzEqZ4W-BVPaEyXQ82ppnb-SO-VsgOixcQoHxp6V0=.2abc12b7-76a0-4052-a675-ffb510f9f35a@github.com>
Message-ID: <4xv3uef5CQ0pArU0jbJjWms_qd3akl8ZdbRs18CW31w=.51b759d7-d479-4174-92da-d4bda0500597@github.com>

On Wed, 15 Mar 2023 18:45:00 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
>> 
>> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
>> 
>> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
>> 
>> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
>> 
>> This change supports the following platforms: x86, aarch64, PPC, and RISCV
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed aarch64 interpreter mistake

src/hotspot/cpu/ppc/templateTable_ppc_64.cpp line 3398:

> 3396:   const Bytecodes::Code code = bytecode();
> 3397:   const bool is_invokeinterface  = code == Bytecodes::_invokeinterface;
> 3398:   const bool is_invokedynamic    = code == false; // should not reach here with invokedynamic

This is what I meant.

Suggestion:

  const bool is_invokedynamic    = false; // should not reach here with invokedynamic


Thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/12778

From aph at openjdk.org  Thu Mar 16 09:35:20 2023
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 16 Mar 2023 09:35:20 GMT
Subject: RFR: 8300669: AArch64: Table based tails processing and wider
 stores for Arrays.fill() intrinsic [v7]
In-Reply-To: <5JHSnU7J6tzmoU1yKRYGOA1T8WDi2NHeXWPfQCOYKhU=.7f8023de-9f58-49a3-8c9b-a8e46c7430e9@github.com>
References: <P9Uyonc1ySikxhznLvs9HT6kXvh6IRFYMqH-BLU1nuM=.5fbbe0ed-f32e-4653-97a2-9a8a4b6e5e0d@github.com>
 <0HhfPpk5EIXfhlmdTaT-ik1EQWgYXSKkK7f4fuLKGh0=.9e690153-fc70-49a0-aada-2829747da8cf@github.com>
 <5JHSnU7J6tzmoU1yKRYGOA1T8WDi2NHeXWPfQCOYKhU=.7f8023de-9f58-49a3-8c9b-a8e46c7430e9@github.com>
Message-ID: <V5RBNSjNzlFbkkCAMhGa5g4hrd3qVawOyk_7uN4NZlI=.e451580b-e779-483a-9692-dfe905b99867@github.com>

On Thu, 16 Mar 2023 04:52:57 GMT, Dmitry Chuyko <dchuyko at openjdk.org> wrote:

> As an example consider parameters distribution in OpenJDK jtreg tests. ![02-jtreg-lengths](https://user-images.githubusercontent.com/31855791/225517679-1df9db71-03cd-4ed6-9b79-be19c229d73c.png) Here most fills start with 0 and fill length is below 512 elements.

Can you please explain what this means? Are these all non-zero fills?

-------------

PR: https://git.openjdk.org/jdk/pull/12222

From fyang at openjdk.org  Thu Mar 16 09:38:18 2023
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 16 Mar 2023 09:38:18 GMT
Subject: RFR: 8304293: RISC-V: JDK-8276799 missed atomic intrinsic support
 for C1
In-Reply-To: <9U2safmMfGsfIIlyBZW3E3dbm68mKcBAzemr5yqoPEw=.c261f575-2cbc-402e-b742-7a6bdc8c2450@github.com>
References: <9U2safmMfGsfIIlyBZW3E3dbm68mKcBAzemr5yqoPEw=.c261f575-2cbc-402e-b742-7a6bdc8c2450@github.com>
Message-ID: <6HOmP1tPgq26gezEvauaAs0UYxGKQrXg3iOA7bNC1TQ=.857c8220-ad7b-49f7-bddc-c7c9a807664b@github.com>

On Thu, 16 Mar 2023 03:37:10 GMT, Feilong Jiang <fjiang at openjdk.org> wrote:

> The following intrinsics in C1 are controlled by supports_atomic_xxx, but they are not set properly on RISC-V:
> - _getAndAddInt
> - _getAndAddLong
> - _getAndSetInt
> - _getAndSetLong
> - _getAndSetReference
> 
> RISC-V provides a set of atomic instructions [1], these intrinsics could be enabled by default.
> 
> Here is the HIR output of C1:
> 
> before:
> 
> 
> B18 (V) [189, 196] -> B20 pred: B8 B17 
> empty stack
> inlining depth 0
> __bci__use__tid____instr____________________________________
>   0    0    a251   <instance 0x00000040a802fb98 klass=jdk/internal/misc/Unsafe>
>   3    0    a252   null   
>   4    0    l254   274954985816L
>   7    0    l255   1L
> . 8    0    l256   a251.invokespecial(a252, l254, l255)
>                    jdk/internal/misc/Unsafe.getAndAddLong(Ljava/lang/Object;JJ)J
> . 193  0    l258   a42._24 := l256 (J) tid
> . 196  0     259   goto B20
> 
> 
> after:
> 
> 
> B18 (V) [189, 196] -> B20 pred: B8 B17 
> empty stack
> inlining depth 0
> __bci__use__tid____instr____________________________________
>   0    0    a251   <instance 0x00000040a802fb98 klass=jdk/internal/misc/Unsafe>
>   3    0    a252   null   
>   4    0    l254   274954985816L
>   7    0    l255   1L
> . 8    0    l256   UnsafeGetAndSet (add)(a252, l254, value l255)
> . 193  0    l258   a42._24 := l256 (J) tid
> . 196  0     259   goto B20
> 
> 
> 1. https://github.com/riscv/riscv-isa-manual/blob/8b9047d8d20ef548f7996efee1550760d7bc1279/src/a.tex#L416-L422
> 
> Testing:
> 
> - [ ] tier1 on Unmatched board (release build)

Looks good. Thanks for finding this.

-------------

Marked as reviewed by fyang (Reviewer).

PR: https://git.openjdk.org/jdk/pull/13053

From rehn at openjdk.org  Thu Mar 16 10:23:41 2023
From: rehn at openjdk.org (Robbin Ehn)
Date: Thu, 16 Mar 2023 10:23:41 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v27]
In-Reply-To: <1cMqmQSAilNe5gNdJj0HBvo5OJqz8wvsetLHTZgF9s4=.79f9c9f2-aac9-4cd1-9d41-3201f89c52b3@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <AmDOQhS1AzZxHd0kV_jhUWSGVdt8NZbfMVydFpHnQjs=.eff82b60-de1c-45e8-b54b-183b174b63d9@github.com>
 <sSvJUuSCIClY4q7Jna2_zNvYXlvrMGnJwWxf1aN5RT4=.41df8341-3474-4e10-90ef-2ccd58b14deb@github.com>
 <1cMqmQSAilNe5gNdJj0HBvo5OJqz8wvsetLHTZgF9s4=.79f9c9f2-aac9-4cd1-9d41-3201f89c52b3@github.com>
Message-ID: <FFSJ8XUChtp3trU4_MwQ_455uWc-68dKd-iDSymudOM=.e7c81144-142a-4057-a24a-135c12aa4bec@github.com>

On Thu, 16 Mar 2023 09:02:19 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> I like -XX:+UseNewLocks, too. I wouldn't overcomplicate things: this flag is meant to be transitional, it is not meant to be used by end-users (except the bravest nerds) at all. When it lands, the Lilliput flag (e.g. +UseCompactObjectHeaders) will also control the locking flag. Eventually (e.g. release+1) both flags would become on by default and afterwards (e.g. release+2) would go away entirely, at which point the whole original stack-locking would disappear.
>
>> @rkennke I must be missing something. In aarch64, why do we handle the non-symmetric-unlock case in interpreter, but not in C1/C2? There, we just seem to pop whatever is on top.
> 
> C1 and C2 don't allow assymmetric locking. If that ever happens, they would refuse to compile the method. We should probably check that this assumption holds true when popping the top entry in an #ASSERT block.

> > > @rkennke I must be missing something. In aarch64, why do we handle the non-symmetric-unlock case in interpreter, but not in C1/C2? There, we just seem to pop whatever is on top.
> > 
> > 
> > C1 and C2 don't allow assymmetric locking. If that ever happens, they would refuse to compile the method. We should probably check that this assumption holds true when popping the top entry in an #ASSERT block.
> 
> Thanks for clarifying. Yes, asserting that would make sense.

FYI:
I'm trying to convince folks that JVMS should be allowed to enforce asymmetric locking.
We think most people don't know they will be stuck in interpreter, unintended.
What was discussed latest was to diagnose and warn about this behavior as a first step.

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From stuefe at openjdk.org  Thu Mar 16 10:29:31 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 16 Mar 2023 10:29:31 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v27]
In-Reply-To: <FFSJ8XUChtp3trU4_MwQ_455uWc-68dKd-iDSymudOM=.e7c81144-142a-4057-a24a-135c12aa4bec@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <AmDOQhS1AzZxHd0kV_jhUWSGVdt8NZbfMVydFpHnQjs=.eff82b60-de1c-45e8-b54b-183b174b63d9@github.com>
 <sSvJUuSCIClY4q7Jna2_zNvYXlvrMGnJwWxf1aN5RT4=.41df8341-3474-4e10-90ef-2ccd58b14deb@github.com>
 <1cMqmQSAilNe5gNdJj0HBvo5OJqz8wvsetLHTZgF9s4=.79f9c9f2-aac9-4cd1-9d41-3201f89c52b3@github.com>
 <FFSJ8XUChtp3trU4_MwQ_455uWc-68dKd-iDSymudOM=.e7c81144-142a-4057-a24a-135c12aa4bec@github.com>
Message-ID: <Ea7WNhokl7AUCFeSxx3W7B2-upSGeIfgjQy80xJrHns=.98491f27-3488-448a-8713-054866c139f9@github.com>

On Thu, 16 Mar 2023 10:20:21 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> 



> > > > @rkennke I must be missing something. In aarch64, why do we handle the non-symmetric-unlock case in interpreter, but not in C1/C2? There, we just seem to pop whatever is on top.
> > > 
> > > 
> > > C1 and C2 don't allow assymmetric locking. If that ever happens, they would refuse to compile the method. We should probably check that this assumption holds true when popping the top entry in an #ASSERT block.
> > 
> > 
> > Thanks for clarifying. Yes, asserting that would make sense.
> 
> FYI: I'm trying to convince folks that JVMS should be allowed to enforce asymmetric locking. We think most people don't know they will be stuck in interpreter, unintended. What was discussed latest was to diagnose and warn about this behavior as a first step.

Sounds good. Just to be clear, you mean enforce symmetric locking? resp. forbid asymmetric locking?

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From rehn at openjdk.org  Thu Mar 16 11:00:35 2023
From: rehn at openjdk.org (Robbin Ehn)
Date: Thu, 16 Mar 2023 11:00:35 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v27]
In-Reply-To: <Ea7WNhokl7AUCFeSxx3W7B2-upSGeIfgjQy80xJrHns=.98491f27-3488-448a-8713-054866c139f9@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <AmDOQhS1AzZxHd0kV_jhUWSGVdt8NZbfMVydFpHnQjs=.eff82b60-de1c-45e8-b54b-183b174b63d9@github.com>
 <sSvJUuSCIClY4q7Jna2_zNvYXlvrMGnJwWxf1aN5RT4=.41df8341-3474-4e10-90ef-2ccd58b14deb@github.com>
 <1cMqmQSAilNe5gNdJj0HBvo5OJqz8wvsetLHTZgF9s4=.79f9c9f2-aac9-4cd1-9d41-3201f89c52b3@github.com>
 <FFSJ8XUChtp3trU4_MwQ_455uWc-68dKd-iDSymudOM=.e7c81144-142a-4057-a24a-135c12aa4bec@github.com>
 <Ea7WNhokl7AUCFeSxx3W7B2-upSGeIfgjQy80xJrHns=.98491f27-3488-448a-8713-054866c139f9@github.com>
Message-ID: <uRhupwQAEnz-zmyDg6kRFwTMHZ-viEYCQqU6xCWMpxk=.442536a5-e2ed-4522-9833-cddb5c9e6b76@github.com>

On Thu, 16 Mar 2023 10:26:26 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Sounds good. Just to be clear, you mean enforce symmetric locking? resp. forbid asymmetric locking?

Yes, sorry, thanks for correcting! :)

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From rrich at openjdk.org  Thu Mar 16 11:20:19 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Thu, 16 Mar 2023 11:20:19 GMT
Subject: RFR: 8296440: Remove Method* handling from
 cleanup_inline_caches_impl
In-Reply-To: <8C06DfuEkBnOaaP1WFv7Y6TRftP9XMitffS3UbOaf8c=.abb8c6e3-7a3b-4412-89b3-8819bd93900e@github.com>
References: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
 <8C06DfuEkBnOaaP1WFv7Y6TRftP9XMitffS3UbOaf8c=.abb8c6e3-7a3b-4412-89b3-8819bd93900e@github.com>
Message-ID: <-kGuL7H1z4fuW2g7GcmikUOSsGUla7zthnDC-Jc6fxI=.e83dcb81-040a-4fb1-b1be-d70b4626f165@github.com>

On Thu, 16 Mar 2023 00:17:27 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> ```
> #  Internal Error (/workspace/open/src/hotspot/share/runtime/sharedRuntime.cpp:1411), pid=1150904, tid=1150907
> #  guarantee(false) failed: Missing dependency resolving optimized virtual (invokeinterface) call to  jnr.enxio.channels.Native$LibC$jnr$ffi$2::read
> ```

Very interesting indeed :). Thanks again for the testing!

Have you seen this also on aarch64?

-------------

PR: https://git.openjdk.org/jdk/pull/12802

From rkennke at openjdk.org  Thu Mar 16 12:24:35 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 16 Mar 2023 12:24:35 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v21]
In-Reply-To: <7265U-aASDjFX1CMrbxDZZCPHrYJkufD1QDFBuB1WSA=.623488a7-9ede-4ec2-b840-1e5601a9b97a@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <hR80_9dU9pp0SnN8q-qZ7aG-_YWFST6O6EXQZ_pNjPk=.0f0cbf74-2890-4bd5-88ba-fbe4be92764a@github.com>
 <7265U-aASDjFX1CMrbxDZZCPHrYJkufD1QDFBuB1WSA=.623488a7-9ede-4ec2-b840-1e5601a9b97a@github.com>
Message-ID: <cIes2NCoD1zZKZaLs1E3Q_CizaccafPGGLHi9ZvYnIs=.2bed7c56-4908-4a03-b049-1c732121c88c@github.com>

On Sat, 11 Mar 2023 14:57:19 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>>  - Use nullptr instead of NULL in touched code (shared)
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 6234:
> 
>> 6232: 
>> 6233:   // Load (object->mark() | 1) into hdr
>> 6234:   orr(hdr, hdr, markWord::unlocked_value);
> 
> I wondered why this is needed. Should we not have the header of an unloaded object in hdr? Or is this a safeguard against a misuse of this function (called with the header of an already locked object)?

It could be a monitor-locked header. In C2 this is not possible and we *could* save an instruction here, I guess. Not sure if it is worth it, though.

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From rkennke at openjdk.org  Thu Mar 16 12:32:39 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 16 Mar 2023 12:32:39 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v21]
In-Reply-To: <7265U-aASDjFX1CMrbxDZZCPHrYJkufD1QDFBuB1WSA=.623488a7-9ede-4ec2-b840-1e5601a9b97a@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <hR80_9dU9pp0SnN8q-qZ7aG-_YWFST6O6EXQZ_pNjPk=.0f0cbf74-2890-4bd5-88ba-fbe4be92764a@github.com>
 <7265U-aASDjFX1CMrbxDZZCPHrYJkufD1QDFBuB1WSA=.623488a7-9ede-4ec2-b840-1e5601a9b97a@github.com>
Message-ID: <euh94hP0zGHfhJaDTKEWkFl6EnDtpWIanvh9dpSAXVU=.52402527-3c3b-492c-a169-8e54d4098d0b@github.com>

On Sat, 11 Mar 2023 14:52:54 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>>  - Use nullptr instead of NULL in touched code (shared)
>
> src/hotspot/share/runtime/lockStack.hpp line 64:
> 
>> 62: 
>> 63:   // GC support
>> 64:   inline void oops_do(OopClosure* cl);
> 
> Does this need to be nonconst?

Yes, because the OopClosures can (and will) update the inline array elements.

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From jvernee at openjdk.org  Thu Mar 16 12:37:28 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 16 Mar 2023 12:37:28 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v17]
In-Reply-To: <OeAM2KDLiqCc1fAdmFL5HK6BdUS2i-P42AaunS00UEw=.0f0c2e19-b59a-46e5-965e-a81b665a8e81@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <OeAM2KDLiqCc1fAdmFL5HK6BdUS2i-P42AaunS00UEw=.0f0c2e19-b59a-46e5-965e-a81b665a8e81@github.com>
Message-ID: <ysrqQkFInh9CIQbYrhyR2IORNyOnSCuRvYaEz3e1IyU=.dc288974-7860-4e9e-8a62-c6b1fb4ebee7@github.com>

On Wed, 15 Mar 2023 18:53:08 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
>> 
>> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
>> 
>> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
>> 
>> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Will get addressed separately: [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
>> 
>> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
>> 
>> I had to make changes to shared code and code for other platforms:
>> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
>> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
>> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
>> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
>> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix Copyright format.

Ok, I've gone ahead and integrated: https://github.com/openjdk/jdk/pull/12883 & https://github.com/openjdk/jdk/pull/12908

That's all I had at the moment. I think the rest will come with the JEP PR.

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From rkennke at openjdk.org  Thu Mar 16 12:51:10 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 16 Mar 2023 12:51:10 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v28]
In-Reply-To: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
Message-ID: <m-NmDBuUrTUL-lXQbeBG1wBpJHHe4A_we2--SnhdtzA=.3bee0803-04ec-4714-a551-e242f0ee3c06@github.com>

> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
> 
> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p
 rotocols.
> 
> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
> 
> 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
> 
> 
> Testing:
>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
> 
> ### Performance
> 
> #### Simple Microbenchmark
> 
> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
> 
> |  | x86_64 | aarch64 |
> | -- | -- | -- |
> | -UseFastLocking | 20.651 | 20.764 |
> | +UseFastLocking | 18.896 | 18.908 |
> 
> 
> #### Renaissance
> 
> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
> -- | -- | -- | -- | -- | -- | -- | --
> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Several changes (mostly cosmetic) in response to reviews

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10907/files
  - new: https://git.openjdk.org/jdk/pull/10907/files/0ad01c1d..2445a19d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=27
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=26-27

  Stats: 21 lines in 11 files changed: 7 ins; 5 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/10907.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10907/head:pull/10907

PR: https://git.openjdk.org/jdk/pull/10907

From mdoerr at openjdk.org  Thu Mar 16 13:15:18 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 16 Mar 2023 13:15:18 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v18]
In-Reply-To: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
Message-ID: <K2tKvw9f-lnPiqlk894LBq0bb_hUnKbJGog4nfJiuGs=.d001aacb-1211-4815-a6b7-7ab9dc3d1835@github.com>

> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
> 
> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
> 
> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
> 
> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Will get addressed separately: [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
> 
> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
> 
> I had to make changes to shared code and code for other platforms:
> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit.

Martin Doerr has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:

 - Merge branch 'master' into PPC64_Panama
 - Fix Copyright format.
 - Fix storing 32 bit integers into Java frames. Enable TestArrayStructs.
 - Allow TestHFA to run on musl. Add Upcalls.
 - Introduce ABIv2CallArranger for linux ppc64le.
 - Remove LinuxPPC64CallArranger.java because it doesn't contain anything.
 - The merge change has messed up some includes in the tests. Revert.
 - Remove STRUCT_REFERENCE which was incorrectly taken from aarch64. Pass size to bufferLoad/Store. Enable TestNested.java.
 - Merge remote-tracking branch 'origin' into PPC64_Panama
 - Handle HFA corner cases with overlapping registers in Java.
 - ... and 8 more: https://git.openjdk.org/jdk/compare/7dbab81d...944742b5

-------------

Changes: https://git.openjdk.org/jdk/pull/12708/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=17
  Stats: 2434 lines in 61 files changed: 2324 ins; 1 del; 109 mod
  Patch: https://git.openjdk.org/jdk/pull/12708.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12708/head:pull/12708

PR: https://git.openjdk.org/jdk/pull/12708

From coleenp at openjdk.org  Thu Mar 16 13:19:21 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 16 Mar 2023 13:19:21 GMT
Subject: RFR: 8304089: Convert TraceDependencies to UL [v3]
In-Reply-To: <2IKS8cYMhoU1JRBEalwF1ZeV4Vih78eXffu_GXZ4JkQ=.27d433ac-1f04-47ce-a177-c791a42bc6fe@github.com>
References: <0aGc1NdAjpvksCWmXb1gZOPp9MV0n6xWvG8EaEp2ZLg=.b79cf218-9a23-420d-bec5-7509b7f8f1c1@github.com>
 <BQzDwBUOHbm1v3Ex5uAT56pIQJtoT8ON4ZmFhi3TvR0=.ce86f07b-4136-4870-93f0-c9723c80795b@github.com>
 <13yGfFhRFEsjHA-ox_6GxPiyU8w_hpQtgjHbsw6Glq0=.c2330c3f-0316-4f4c-aade-b6ad6c8543ee@github.com>
 <tLhX6beNey8aikbBH30RbCu7lfXZ9AWG2KYqKWVvnkw=.a41fbeb0-6c04-4b6a-824a-fc9fdf734fd2@github.com>
 <2IKS8cYMhoU1JRBEalwF1ZeV4Vih78eXffu_GXZ4JkQ=.27d433ac-1f04-47ce-a177-c791a42bc6fe@github.com>
Message-ID: <SR0H3srVA5CiCcbxL5dHeK2HIJFYvOqZKf0avpuncGU=.dbf27ec1-5455-40b3-aeb2-46d3cb5fbb19@github.com>

On Thu, 16 Mar 2023 07:13:16 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> No, this is the right thing to do.  If -Xlog:dependency - the compiler group also expects the dependency printed to the compiler log file.  The logging is a separate mechanism, but should be enabled with -Xlog:dependency.
>
> Sorry I don't follow that. `use_vm_log()` only affects non-product builds and forces `LogVMOutput` to true. That in turn will cause `defaultStream::init_log()` to execute which initializes the log file etc. But I don't see how that would cause UL logging for "dependencies" to also get written to the log file???

See the function log_dependency()

https://github.com/openjdk/jdk/blob/421b4ee33c652cc7c444fbbf298bbc23d052c2fe/src/hotspot/share/code/dependencies.cpp#L845

called from here (as one place).

https://github.com/openjdk/jdk/blob/421b4ee33c652cc7c444fbbf298bbc23d052c2fe/src/hotspot/share/code/dependencies.cpp#L2071

When TraceDependencies was true, the log file would be non-null and log_dependency would write to it.  Keeping this with -Xlog:dependencies=debug retains what TraceDependencies did.

-------------

PR: https://git.openjdk.org/jdk/pull/13007

From mdoerr at openjdk.org  Thu Mar 16 13:26:20 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 16 Mar 2023 13:26:20 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v19]
In-Reply-To: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
Message-ID: <obH367h_43VTTHQ3zPJ2qewHQzFKzP1CJTcPe-ONsUc=.c23ec4a7-c772-40c9-ae2e-66c2bb9f3e86@github.com>

> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
> 
> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
> 
> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
> 
> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Will get addressed separately: [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
> 
> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
> 
> I had to make changes to shared code and code for other platforms:
> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit.

Martin Doerr has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:

 - Merge branch 'openjdk:master' into PPC64_Panama
 - Merge branch 'master' into PPC64_Panama
 - Fix Copyright format.
 - Fix storing 32 bit integers into Java frames. Enable TestArrayStructs.
 - Allow TestHFA to run on musl. Add Upcalls.
 - Introduce ABIv2CallArranger for linux ppc64le.
 - Remove LinuxPPC64CallArranger.java because it doesn't contain anything.
 - The merge change has messed up some includes in the tests. Revert.
 - Remove STRUCT_REFERENCE which was incorrectly taken from aarch64. Pass size to bufferLoad/Store. Enable TestNested.java.
 - Merge remote-tracking branch 'origin' into PPC64_Panama
 - ... and 9 more: https://git.openjdk.org/jdk/compare/f6291520...2f2f41be

-------------

Changes: https://git.openjdk.org/jdk/pull/12708/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=18
  Stats: 2434 lines in 61 files changed: 2324 ins; 1 del; 109 mod
  Patch: https://git.openjdk.org/jdk/pull/12708.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12708/head:pull/12708

PR: https://git.openjdk.org/jdk/pull/12708

From sjohanss at openjdk.org  Thu Mar 16 13:37:21 2023
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Thu, 16 Mar 2023 13:37:21 GMT
Subject: RFR: 8191565: Last-ditch Full GC should also move humongous
 objects [v3]
In-Reply-To: <oyYJpAchjojCr_V6EwjhNcTAdjGzjWPFw-SegZofqZs=.bba1fc78-6fcc-4869-ae50-1beb83c16370@github.com>
References: <58l059EvQI6HNQyjUYSGYEWt6x-c1yvtmfX1QWfinH8=.87517ba1-ec81-4b9f-a41b-b05c8d33cf3d@github.com>
 <oyYJpAchjojCr_V6EwjhNcTAdjGzjWPFw-SegZofqZs=.bba1fc78-6fcc-4869-ae50-1beb83c16370@github.com>
Message-ID: <W04QmwAhPsK-dXOMlDA5l_YEdGa6qEJVrc_FUpPduWM=.1828b6f0-d350-4473-a042-1571a6a90e38@github.com>

On Wed, 15 Mar 2023 17:00:38 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi All,
>> 
>> Please review this change to move humongous regions during the Last-Ditch full gc ( on `do_maximal_compaction`). This change will enable G1 to avoid encountering Out-Of-Memory errors that may occur due to the fragmentation of memory regions caused by the allocation of large memory blocks.
>> 
>> Here's how it works: At the end of `phase2_prepare_compaction`, G1 performs a serial compaction process for regular objects, which results in the heap being divided into two parts. The first part is a densely populated prefix that contains all the regular objects that have been moved. The second part consists of the remaining heap space, which may contain free regions, uncommitted regions, and regions that are not compacting. By moving/compacting the humongous objects in the second part of the heap closer to the dense prefix, G1 reduces the region fragmentation and avoids running into OOM errors.
>> 
>> We have enabled for G1 the Jtreg test that was previously used only for Shenandoah to test such workload. 
>> 
>> Testing: Tier 1-3
>
> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   StefanJ review

Looks good!

-------------

Marked as reviewed by sjohanss (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12830

From kvn at openjdk.org  Thu Mar 16 14:02:19 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 16 Mar 2023 14:02:19 GMT
Subject: RFR: 8296440: Remove Method* handling from
 cleanup_inline_caches_impl
In-Reply-To: <-kGuL7H1z4fuW2g7GcmikUOSsGUla7zthnDC-Jc6fxI=.e83dcb81-040a-4fb1-b1be-d70b4626f165@github.com>
References: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
 <8C06DfuEkBnOaaP1WFv7Y6TRftP9XMitffS3UbOaf8c=.abb8c6e3-7a3b-4412-89b3-8819bd93900e@github.com>
 <-kGuL7H1z4fuW2g7GcmikUOSsGUla7zthnDC-Jc6fxI=.e83dcb81-040a-4fb1-b1be-d70b4626f165@github.com>
Message-ID: <zV82E0KpvYP6PU-RLMgs6X1WgojK4wPprWGLE4Pi1fA=.44c1c6f4-ea90-4027-89e6-4a2ccad6f866@github.com>

On Thu, 16 Mar 2023 11:17:33 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> Have you seen this also on aarch64?

I just ran it on linux-aarch64 (Ampere) with the same flags and got the same failure with almost same call stack (without `jnr.enxio`):

V  [libjvm.so+0x16c57cc]  SharedRuntime::resolve_sub_helper(bool, bool, JavaThread*)+0x9b8  (sharedRuntime.cpp:1411)
V  [libjvm.so+0x16c595c]  SharedRuntime::resolve_helper(bool, bool, JavaThread*)+0x3c  (sharedRuntime.cpp:1246)
V  [libjvm.so+0x16c6644]  SharedRuntime::resolve_opt_virtual_call_C(JavaThread*)+0x174  (sharedRuntime.cpp:1690)
v  ~RuntimeStub::resolve_opt_virtual_call 0x0000ffff742a37d0
J 32008 c2 org.jruby.util.io.OpenFile$2.run(Lorg/jruby/runtime/ThreadContext;Ljava/lang/Object;[BII)I org.jruby.dist (15 bytes) @ 0x0000ffff769502f8 [0x0000ffff76950280+0x0000000000000078]

-------------

PR: https://git.openjdk.org/jdk/pull/12802

From kvn at openjdk.org  Thu Mar 16 14:06:19 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 16 Mar 2023 14:06:19 GMT
Subject: RFR: 8296440: Remove Method* handling from
 cleanup_inline_caches_impl
In-Reply-To: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
References: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
Message-ID: <etwBeX1y-MiLPXvUg3ymaINcWUAGxQEoXbvsHkObM1Y=.1c3f93a0-2bfc-4554-b210-8b6e132d84ff@github.com>

On Wed, 1 Mar 2023 11:07:36 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> This PR replaces cleaning of static stubs in CompiledMethod::cleanup_inline_caches_impl() with a guarantee that it is actually not needed because the holder of the embedded target Method* is alive if the caller nmethod is not unloading.
> 
> The holder of the target Method* has to be alive because it is reachable from the caller nmethod's oop pool. This is checked by `check_path_to_callee()` when a statically bound call gets resolved.
> 
> C2i entry barriers can be removed for the same reason.
> 
> Testing:
> 
> Many rounds in our CI testing which includes most JCK and JTREG tests, Renaissance benchmark and SAP specific tests with fastdebug and release builds on the standard platforms plus PPC64.
> 
> I've also done tier1 and tier2 tests with -XX:-Inline and tier1 tests with ZGC.
> 
> I've started hotspot and jdk tier1 tests with -Xcomp. They were not finished when I stopped them after 24h.

On aarch64 `guarantee` line is the same. I assume `jnr.enxio.channels.Native` methods were inlined that is why they not on call stack:

  guarantee(false) failed: Missing dependency resolving optimized virtual (invokeinterface) call to  jnr.enxio.channels.Native$LibC$jnr$ffi$2::read

-------------

PR: https://git.openjdk.org/jdk/pull/12802

From rrich at openjdk.org  Thu Mar 16 14:15:25 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Thu, 16 Mar 2023 14:15:25 GMT
Subject: RFR: 8296440: Remove Method* handling from
 cleanup_inline_caches_impl
In-Reply-To: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
References: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
Message-ID: <fCiqwBrxuMN_DuDhasoOXjnG8lIOi1iOSXs1WyKJ1R0=.6a5c3ba3-9911-4f4c-8edc-705df995c2d5@github.com>

On Wed, 1 Mar 2023 11:07:36 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> This PR replaces cleaning of static stubs in CompiledMethod::cleanup_inline_caches_impl() with a guarantee that it is actually not needed because the holder of the embedded target Method* is alive if the caller nmethod is not unloading.
> 
> The holder of the target Method* has to be alive because it is reachable from the caller nmethod's oop pool. This is checked by `check_path_to_callee()` when a statically bound call gets resolved.
> 
> C2i entry barriers can be removed for the same reason.
> 
> Testing:
> 
> Many rounds in our CI testing which includes most JCK and JTREG tests, Renaissance benchmark and SAP specific tests with fastdebug and release builds on the standard platforms plus PPC64.
> 
> I've also done tier1 and tier2 tests with -XX:-Inline and tier1 tests with ZGC.
> 
> I've started hotspot and jdk tier1 tests with -Xcomp. They were not finished when I stopped them after 24h.

Seems to be independen of `relocInfo::mustIterateImmediateOopsInCode()` then because on aarch64 it is false. Still this is a good point. The verification code should better use `nmethod::oops_do()`.

-------------

PR: https://git.openjdk.org/jdk/pull/12802

From mdoerr at openjdk.org  Thu Mar 16 14:17:12 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 16 Mar 2023 14:17:12 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v20]
In-Reply-To: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
Message-ID: <6zPly5eBW4Y9v5qD0VKBSigBod2OJeqKoymR_TEogO4=.88f854ce-6a35-4022-a363-1e617bbbd823@github.com>

> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
> 
> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
> 
> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
> 
> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Will get addressed separately: [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
> 
> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
> 
> I had to make changes to shared code and code for other platforms:
> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit.

Martin Doerr has updated the pull request incrementally with two additional commits since the last revision:

 - Adaptation for JDK-8303022.
 - Adaptation for JDK-8303684.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12708/files
  - new: https://git.openjdk.org/jdk/pull/12708/files/2f2f41be..a21f6cfb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=18-19

  Stats: 23 lines in 5 files changed: 9 ins; 3 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/12708.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12708/head:pull/12708

PR: https://git.openjdk.org/jdk/pull/12708

From iwalulya at openjdk.org  Thu Mar 16 14:19:36 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Thu, 16 Mar 2023 14:19:36 GMT
Subject: RFR: 8191565: Last-ditch Full GC should also move humongous
 objects [v3]
In-Reply-To: <W04QmwAhPsK-dXOMlDA5l_YEdGa6qEJVrc_FUpPduWM=.1828b6f0-d350-4473-a042-1571a6a90e38@github.com>
References: <58l059EvQI6HNQyjUYSGYEWt6x-c1yvtmfX1QWfinH8=.87517ba1-ec81-4b9f-a41b-b05c8d33cf3d@github.com>
 <oyYJpAchjojCr_V6EwjhNcTAdjGzjWPFw-SegZofqZs=.bba1fc78-6fcc-4869-ae50-1beb83c16370@github.com>
 <W04QmwAhPsK-dXOMlDA5l_YEdGa6qEJVrc_FUpPduWM=.1828b6f0-d350-4473-a042-1571a6a90e38@github.com>
Message-ID: <Q2OoJkpNZPi9kh1FUluryeDEPfwaJ0ae3sZbtQxkunI=.5d826cbb-9d66-4dce-8a09-6cc1a8b297dd@github.com>

On Thu, 16 Mar 2023 13:34:55 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   StefanJ review
>
> Looks good!

Thanks @kstefanj and @tschatzl for the reviews!

-------------

PR: https://git.openjdk.org/jdk/pull/12830

From iwalulya at openjdk.org  Thu Mar 16 14:19:38 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Thu, 16 Mar 2023 14:19:38 GMT
Subject: Integrated: 8191565: Last-ditch Full GC should also move humongous
 objects
In-Reply-To: <58l059EvQI6HNQyjUYSGYEWt6x-c1yvtmfX1QWfinH8=.87517ba1-ec81-4b9f-a41b-b05c8d33cf3d@github.com>
References: <58l059EvQI6HNQyjUYSGYEWt6x-c1yvtmfX1QWfinH8=.87517ba1-ec81-4b9f-a41b-b05c8d33cf3d@github.com>
Message-ID: <EcVDJh5vhd-TiUJsXdJjVh-HKz-Xekp_GLpUpLixXOA=.afd3612e-1dac-47f7-b14b-eccb711e90cd@github.com>

On Thu, 2 Mar 2023 13:48:10 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi All,
> 
> Please review this change to move humongous regions during the Last-Ditch full gc ( on `do_maximal_compaction`). This change will enable G1 to avoid encountering Out-Of-Memory errors that may occur due to the fragmentation of memory regions caused by the allocation of large memory blocks.
> 
> Here's how it works: At the end of `phase2_prepare_compaction`, G1 performs a serial compaction process for regular objects, which results in the heap being divided into two parts. The first part is a densely populated prefix that contains all the regular objects that have been moved. The second part consists of the remaining heap space, which may contain free regions, uncommitted regions, and regions that are not compacting. By moving/compacting the humongous objects in the second part of the heap closer to the dense prefix, G1 reduces the region fragmentation and avoids running into OOM errors.
> 
> We have enabled for G1 the Jtreg test that was previously used only for Shenandoah to test such workload. 
> 
> Testing: Tier 1-3

This pull request has now been integrated.

Changeset: 96889bf3
Author:    Ivan Walulya <iwalulya at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/96889bf3e4f36fa7f9e9b9989a1bc3ac4719bfeb
Stats:     401 lines in 15 files changed: 322 ins; 47 del; 32 mod

8191565: Last-ditch Full GC should also move humongous objects

Reviewed-by: tschatzl, sjohanss

-------------

PR: https://git.openjdk.org/jdk/pull/12830

From mdoerr at openjdk.org  Thu Mar 16 14:42:10 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 16 Mar 2023 14:42:10 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v21]
In-Reply-To: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
Message-ID: <RCI233Y726or2PZQLlhyuv7YmZSchb5JNUalXqKpavQ=.b96ef488-eff9-4077-afb9-d94b55f07bfb@github.com>

> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
> 
> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
> 
> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
> 
> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Will get addressed separately: [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
> 
> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
> 
> I had to make changes to shared code and code for other platforms:
> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit.

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  Move ABIv2CallArranger out of linux subdirectory. ABIv1/2 does match the AIX/linux separation.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12708/files
  - new: https://git.openjdk.org/jdk/pull/12708/files/a21f6cfb..4666aa22

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=19-20

  Stats: 81 lines in 3 files changed: 40 ins; 40 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12708.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12708/head:pull/12708

PR: https://git.openjdk.org/jdk/pull/12708

From mdoerr at openjdk.org  Thu Mar 16 14:42:12 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 16 Mar 2023 14:42:12 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v20]
In-Reply-To: <6zPly5eBW4Y9v5qD0VKBSigBod2OJeqKoymR_TEogO4=.88f854ce-6a35-4022-a363-1e617bbbd823@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <6zPly5eBW4Y9v5qD0VKBSigBod2OJeqKoymR_TEogO4=.88f854ce-6a35-4022-a363-1e617bbbd823@github.com>
Message-ID: <2ly6-8MdohRIteqaZsBXJd5R6FxhhmsAv4pwdIaZPW4=.77a93182-17bc-4149-99fb-2c6064c297eb@github.com>

On Thu, 16 Mar 2023 14:17:12 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
>> 
>> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
>> 
>> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
>> 
>> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Will get addressed separately: [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
>> 
>> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
>> 
>> I had to make changes to shared code and code for other platforms:
>> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
>> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
>> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
>> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
>> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit.
>
> Martin Doerr has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Adaptation for JDK-8303022.
>  - Adaptation for JDK-8303684.

Rebasing + minor cleanup done. Tests are passing.

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From dnsimon at openjdk.org  Thu Mar 16 15:13:32 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 16 Mar 2023 15:13:32 GMT
Subject: RFR: 8292818: replace 96-bit representation for field metadata
 with variable-sized streams [v5]
In-Reply-To: <bZJIThP0PV4ic1UBs4eXRqgBLhpNER813xmY8iiOqgY=.7a83c2d2-24e5-472b-87af-26ca6d8b90bf@github.com>
References: <vdiacOO3JUyy4sWGkDXNBMUT7cG3XYe79mOvYru9uMM=.9c556675-7ffd-4c09-a428-6d64dffef209@github.com>
 <bZJIThP0PV4ic1UBs4eXRqgBLhpNER813xmY8iiOqgY=.7a83c2d2-24e5-472b-87af-26ca6d8b90bf@github.com>
Message-ID: <G4r6Xqx2DQFjEyZSbgrwJ2q1DiSGCwcwlMbYI-qh4bg=.0863fe00-377e-41f0-93ef-6b6b8715e8ce@github.com>

On Wed, 15 Mar 2023 15:41:17 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Please review this change re-implementing the FieldInfo data structure.
>> 
>> The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency.
>> 
>> The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information).
>> 
>> More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818
>> 
>> Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM.
>> 
>> The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format.
>> 
>> Tested with mach5, tier 1 to 7.
>> 
>> Thank you.
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   SA and JVMCI fixes

Marked as reviewed by dnsimon (Committer).

-------------

PR: https://git.openjdk.org/jdk/pull/12855

From rrich at openjdk.org  Thu Mar 16 16:15:10 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Thu, 16 Mar 2023 16:15:10 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v6]
In-Reply-To: <ivPzEqZ4W-BVPaEyXQ82ppnb-SO-VsgOixcQoHxp6V0=.2abc12b7-76a0-4052-a675-ffb510f9f35a@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <ivPzEqZ4W-BVPaEyXQ82ppnb-SO-VsgOixcQoHxp6V0=.2abc12b7-76a0-4052-a675-ffb510f9f35a@github.com>
Message-ID: <CexTEliH6BjXpUM3YxmiFteZfQEs8qTdC1Z7eFfA2jk=.dc8476eb-1894-48d2-a8e8-873decdd9ebf@github.com>

On Wed, 15 Mar 2023 18:45:00 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
>> 
>> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
>> 
>> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
>> 
>> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
>> 
>> This change supports the following platforms: x86, aarch64, PPC, and RISCV
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed aarch64 interpreter mistake

src/hotspot/cpu/aarch64/templateTable_aarch64.cpp line 2335:

> 2333: 
> 2334:   __ load_resolved_indy_entry(cache, index);
> 2335:   __ ldr(method, Address(cache, in_bytes(ResolvedIndyEntry::method_offset())));

Should this load have acquire semantics?
Like [here in template interpreter](https://github.com/openjdk/jdk/blob/2f23c80e0de44815d26a7d541701e16c9c1d32bc/src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp#L239) and [here for the zero interpreter](https://github.com/openjdk/jdk/blob/2f23c80e0de44815d26a7d541701e16c9c1d32bc/src/hotspot/share/oops/cpCache.inline.hpp#L33)?

Call stack for zero interpreter is

ConstantPoolCacheEntry::indices_ord()
ConstantPoolCacheEntry::bytecode_1()
ConstantPoolCacheEntry::is_resolved(enum Bytecodes::Code)
BytecodeInterpreter::run(interpreterState)

-------------

PR: https://git.openjdk.org/jdk/pull/12778

From dcubed at openjdk.org  Thu Mar 16 19:51:10 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 16 Mar 2023 19:51:10 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v28]
In-Reply-To: <m-NmDBuUrTUL-lXQbeBG1wBpJHHe4A_we2--SnhdtzA=.3bee0803-04ec-4714-a551-e242f0ee3c06@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <m-NmDBuUrTUL-lXQbeBG1wBpJHHe4A_we2--SnhdtzA=.3bee0803-04ec-4714-a551-e242f0ee3c06@github.com>
Message-ID: <3B1OYwu_wroqQecRIZNNk7Yrrs_X_nk4hrjiC9IeGvk=.d3a9c5ac-7578-4d08-95a6-35b046d2cf26@github.com>

On Thu, 16 Mar 2023 12:51:10 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Several changes (mostly cosmetic) in response to reviews

I did a round of Mach5 Tier[1-4] testing on v26. Please see the bug report for the
gory details. There are 12 tests in Tier4 that fail when -Xcheck:jni is used.

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From dcubed at openjdk.org  Thu Mar 16 19:55:18 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 16 Mar 2023 19:55:18 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v28]
In-Reply-To: <m-NmDBuUrTUL-lXQbeBG1wBpJHHe4A_we2--SnhdtzA=.3bee0803-04ec-4714-a551-e242f0ee3c06@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <m-NmDBuUrTUL-lXQbeBG1wBpJHHe4A_we2--SnhdtzA=.3bee0803-04ec-4714-a551-e242f0ee3c06@github.com>
Message-ID: <Nq-pQAbU91HvGGtV8hljI49rttZQ50cr_J01TCSVYtE=.0994d94f-f274-460b-9bce-4ade1a3d26e5@github.com>

On Thu, 16 Mar 2023 12:51:10 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Several changes (mostly cosmetic) in response to reviews

Another way to look at the option name question is to invert the sense of
the option. The old stack-locking code would be enabled by this new
`UseStackLocking` option (which would be on by default for now) and the
newer locking code that uses a lock-stack that is embedded in the JavaThread
would be the "else" case of the temporary `UseStackLocking` option.

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From rkennke at openjdk.org  Thu Mar 16 20:56:15 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 16 Mar 2023 20:56:15 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
Message-ID: <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>

> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
> 
> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p
 rotocols.
> 
> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
> 
> 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
> 
> 
> Testing:
>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
> 
> ### Performance
> 
> #### Simple Microbenchmark
> 
> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
> 
> |  | x86_64 | aarch64 |
> | -- | -- | -- |
> | -UseFastLocking | 20.651 | 20.764 |
> | +UseFastLocking | 18.896 | 18.908 |
> 
> 
> #### Renaissance
> 
> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
> -- | -- | -- | -- | -- | -- | -- | --
> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%

Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:

 - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
 - Set condition flags correctly after fast-lock call on aarch64

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10907/files
  - new: https://git.openjdk.org/jdk/pull/10907/files/2445a19d..37f061b0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=28
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=27-28

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10907.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10907/head:pull/10907

PR: https://git.openjdk.org/jdk/pull/10907

From rkennke at openjdk.org  Thu Mar 16 20:56:19 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 16 Mar 2023 20:56:19 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v28]
In-Reply-To: <m-NmDBuUrTUL-lXQbeBG1wBpJHHe4A_we2--SnhdtzA=.3bee0803-04ec-4714-a551-e242f0ee3c06@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <m-NmDBuUrTUL-lXQbeBG1wBpJHHe4A_we2--SnhdtzA=.3bee0803-04ec-4714-a551-e242f0ee3c06@github.com>
Message-ID: <vU0BKEkad-O5kYdt4yAlTGshX91zvQG2ItbkOGx972U=.ff514804-25f6-4bef-aa99-35cdee7353de@github.com>

On Thu, 16 Mar 2023 12:51:10 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Several changes (mostly cosmetic) in response to reviews

In my last changes I made a stupid mistake and don't set the condition flags correctly to force the slow-path, on aarch64. This is only relevant when we exceed the lock-stack capacity, that is why it's failing so rarely. I don't see a similar problem on x86_64 - have we observed any failures on x86_64? I pushed a fix for aarch64.

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From dcubed at openjdk.org  Thu Mar 16 20:56:22 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 16 Mar 2023 20:56:22 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v28]
In-Reply-To: <m-NmDBuUrTUL-lXQbeBG1wBpJHHe4A_we2--SnhdtzA=.3bee0803-04ec-4714-a551-e242f0ee3c06@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <m-NmDBuUrTUL-lXQbeBG1wBpJHHe4A_we2--SnhdtzA=.3bee0803-04ec-4714-a551-e242f0ee3c06@github.com>
Message-ID: <nuwHfMCpKBKdZqsSFsuel1S82Mm7UuG0-_PsluysuEE=.276867b3-2183-40f8-942f-457cf8b13e94@github.com>

On Thu, 16 Mar 2023 12:51:10 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Several changes (mostly cosmetic) in response to reviews

src/hotspot/cpu/x86/x86_32.ad line 617:

> 615:   int bangsize = C->output()->bang_size_in_bytes();
> 616: 
> 617:   __ verified_entry(framesize, C->output()->need_stack_bang(bangsize)?bangsize:0, C->in_24_bit_fp_mode(), C->stub_function() != NULL);

Why did this change from `nullptr` -> `NULL`?

src/hotspot/cpu/x86/x86_64.ad line 925:

> 923:   }
> 924: 
> 925:   __ verified_entry(framesize, C->output()->need_stack_bang(bangsize)?bangsize:0, false, C->stub_function() != NULL);

Why did this change from `nullptr` -> `NULL`?

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From rkennke at openjdk.org  Thu Mar 16 21:00:37 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 16 Mar 2023 21:00:37 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v28]
In-Reply-To: <nuwHfMCpKBKdZqsSFsuel1S82Mm7UuG0-_PsluysuEE=.276867b3-2183-40f8-942f-457cf8b13e94@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <m-NmDBuUrTUL-lXQbeBG1wBpJHHe4A_we2--SnhdtzA=.3bee0803-04ec-4714-a551-e242f0ee3c06@github.com>
 <nuwHfMCpKBKdZqsSFsuel1S82Mm7UuG0-_PsluysuEE=.276867b3-2183-40f8-942f-457cf8b13e94@github.com>
Message-ID: <eLQu9p5aeW0sB5q76gnEF10O18Yco97ood4YhIOGPUs=.d79583f8-8f38-43ae-b0e4-51396f4a17eb@github.com>

On Thu, 16 Mar 2023 20:50:12 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Several changes (mostly cosmetic) in response to reviews
>
> src/hotspot/cpu/x86/x86_32.ad line 617:
> 
>> 615:   int bangsize = C->output()->bang_size_in_bytes();
>> 616: 
>> 617:   __ verified_entry(framesize, C->output()->need_stack_bang(bangsize)?bangsize:0, C->in_24_bit_fp_mode(), C->stub_function() != NULL);
> 
> Why did this change from `nullptr` -> `NULL`?

I reverted that part back to upstream state (at least what is in JDK-21+13).

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From dholmes at openjdk.org  Thu Mar 16 21:04:17 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 16 Mar 2023 21:04:17 GMT
Subject: Integrated: 8303150: DCmd framework unnecessarily creates a DCmd
 instance on registration
In-Reply-To: <TNyX996lKlRcmTijRTN0VUZBcNBt2DXeMPhDBjaa0NQ=.160293b7-4570-43a5-af9e-d9cb02022820@github.com>
References: <TNyX996lKlRcmTijRTN0VUZBcNBt2DXeMPhDBjaa0NQ=.160293b7-4570-43a5-af9e-d9cb02022820@github.com>
Message-ID: <3HkwSgvBIzeNYJLuTC5-IMKvZPmiBKyZ2WtI25U5dcA=.5df6c36c-fce6-4629-b74f-10b6e49d23d4@github.com>

On Mon, 13 Mar 2023 01:19:50 GMT, David Holmes <dholmes at openjdk.org> wrote:

> When DCmd factories are registered, the factory is passed the number of arguments taken by the DCmd - using a template method `get_num_arguments`. For DCmds that don't extend DCmdWithParser there has to be a static `num_arguments()` method in that class. For DCmds that do extend DCmdWithParser the logic instantiates an instance of the DCmd, extracts its parser and calls its `num_arguments` method which dynamically counts the number of defined arguments.
> 
> Creating an instance of each DCmd and dynamically counting arguments is inefficient and unnecessary, the number of arguments is statically known and easily expressed (in fact many of the JFR DCmds already statically define this). So we add the static `num_arguments()` method to each class that needs it and return the statically counted number of arguments. To ensure the static number and actual number don't get out-of-sync, we keep the original dynamic logic for use in debug builds to assert that the static and dynamic counts are the same. The assert will trigger during a debug build if something does get out of sync, for example if a new DCmd (extending DCmdWithParser) were added but didn't define the static `num_arguments()` method.
> 
> A number of DCmd classes were unnecessarily defining their own dynamic version of `num_arguments` and these are now removed.
> 
> In the template method I use `ENABLE_IF(std::is_convertible<T, DCmd>::value)` to check we only call this on DCmd classes. This may be unnecessary but it seemed consistent with the other template methods. Note that `std::is_base_of` only works for immediate super types.
> 
> Testing: tiers 1-4
> 
> Performance: in theory we should see some improvement in startup; in practice it is barely noticeable.
> 
> Thanks.

This pull request has now been integrated.

Changeset: a487a270
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a487a270dcd6d6a6b5ea49dece515334a0e48efc
Stats:     104 lines in 12 files changed: 36 ins; 59 del; 9 mod

8303150: DCmd framework unnecessarily creates a DCmd instance on registration

Reviewed-by: fparain, stuefe, kevinw

-------------

PR: https://git.openjdk.org/jdk/pull/12994

From dcubed at openjdk.org  Thu Mar 16 21:09:18 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 16 Mar 2023 21:09:18 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v28]
In-Reply-To: <vU0BKEkad-O5kYdt4yAlTGshX91zvQG2ItbkOGx972U=.ff514804-25f6-4bef-aa99-35cdee7353de@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <m-NmDBuUrTUL-lXQbeBG1wBpJHHe4A_we2--SnhdtzA=.3bee0803-04ec-4714-a551-e242f0ee3c06@github.com>
 <vU0BKEkad-O5kYdt4yAlTGshX91zvQG2ItbkOGx972U=.ff514804-25f6-4bef-aa99-35cdee7353de@github.com>
Message-ID: <f8mFF3AtjNW29TNFDSFcdxccvakIXpDNPRYen9d0kXU=.b67e9822-fb51-43bd-bfb9-215d11f8db70@github.com>

On Thu, 16 Mar 2023 20:47:59 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> I pushed a fix for aarch64.

Do you think this is the cause for the -Xcheck:jni failures that I ran into
in my Tier4 testing?

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From dcubed at openjdk.org  Thu Mar 16 21:09:20 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 16 Mar 2023 21:09:20 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v28]
In-Reply-To: <eLQu9p5aeW0sB5q76gnEF10O18Yco97ood4YhIOGPUs=.d79583f8-8f38-43ae-b0e4-51396f4a17eb@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <m-NmDBuUrTUL-lXQbeBG1wBpJHHe4A_we2--SnhdtzA=.3bee0803-04ec-4714-a551-e242f0ee3c06@github.com>
 <nuwHfMCpKBKdZqsSFsuel1S82Mm7UuG0-_PsluysuEE=.276867b3-2183-40f8-942f-457cf8b13e94@github.com>
 <eLQu9p5aeW0sB5q76gnEF10O18Yco97ood4YhIOGPUs=.d79583f8-8f38-43ae-b0e4-51396f4a17eb@github.com>
Message-ID: <lSGRh36Kk91D7P1h2xApXzQVg6qRziTjeTNCdLL6WPg=.0a710833-b4a4-4cdd-a495-3056914e8a1e@github.com>

On Thu, 16 Mar 2023 20:57:31 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> src/hotspot/cpu/x86/x86_32.ad line 617:
>> 
>>> 615:   int bangsize = C->output()->bang_size_in_bytes();
>>> 616: 
>>> 617:   __ verified_entry(framesize, C->output()->need_stack_bang(bangsize)?bangsize:0, C->in_24_bit_fp_mode(), C->stub_function() != NULL);
>> 
>> Why did this change from `nullptr` -> `NULL`?
>
> I reverted that part back to upstream state (at least what is in JDK-21+13).

Okay.

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From rkennke at openjdk.org  Thu Mar 16 21:19:29 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 16 Mar 2023 21:19:29 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v28]
In-Reply-To: <f8mFF3AtjNW29TNFDSFcdxccvakIXpDNPRYen9d0kXU=.b67e9822-fb51-43bd-bfb9-215d11f8db70@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <m-NmDBuUrTUL-lXQbeBG1wBpJHHe4A_we2--SnhdtzA=.3bee0803-04ec-4714-a551-e242f0ee3c06@github.com>
 <vU0BKEkad-O5kYdt4yAlTGshX91zvQG2ItbkOGx972U=.ff514804-25f6-4bef-aa99-35cdee7353de@github.com>
 <f8mFF3AtjNW29TNFDSFcdxccvakIXpDNPRYen9d0kXU=.b67e9822-fb51-43bd-bfb9-215d11f8db70@github.com>
Message-ID: <i1dakUfh_NQpsfwXX1Gns_FYkhQSDbTDUYYlFQ3-AeQ=.dec86648-4336-45ce-a134-8874c52f83d2@github.com>

On Thu, 16 Mar 2023 21:05:54 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> > I pushed a fix for aarch64.
> 
> 
> 
> Do you think this is the cause for the -Xcheck:jni failures that I ran into
> 
> in my Tier4 testing?

Yes, and with high probability also for some/all of the other failures. It leads to the situation that when the lock-stack is full, it should take the slow-path, but doesn't (because the flags are not set correctly) and thus leave the object unlocked.

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From dcubed at openjdk.org  Thu Mar 16 21:33:32 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 16 Mar 2023 21:33:32 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
Message-ID: <-aGsX_dmmSBQPrgTVaCsZVU3gFQg1gs9gqS8RFzkRC4=.21ec8ca5-18c5-4f8a-a286-f0c1a32bdeee@github.com>

On Thu, 16 Mar 2023 20:56:15 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>  - Set condition flags correctly after fast-lock call on aarch64

I've reviewed the v27 and v28 changes and kicked off yet another round of
Mach5 testing.

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From matsaave at openjdk.org  Thu Mar 16 21:39:57 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 16 Mar 2023 21:39:57 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v6]
In-Reply-To: <CexTEliH6BjXpUM3YxmiFteZfQEs8qTdC1Z7eFfA2jk=.dc8476eb-1894-48d2-a8e8-873decdd9ebf@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <ivPzEqZ4W-BVPaEyXQ82ppnb-SO-VsgOixcQoHxp6V0=.2abc12b7-76a0-4052-a675-ffb510f9f35a@github.com>
 <CexTEliH6BjXpUM3YxmiFteZfQEs8qTdC1Z7eFfA2jk=.dc8476eb-1894-48d2-a8e8-873decdd9ebf@github.com>
Message-ID: <Zbg9KHbW0DTcu-wKwr_PQ94heoxmvFB-NUH7RVP_ih0=.95a6c6f7-5510-4759-8b6f-4e6d22ae7a99@github.com>

On Thu, 16 Mar 2023 16:11:57 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed aarch64 interpreter mistake
>
> src/hotspot/cpu/aarch64/templateTable_aarch64.cpp line 2335:
> 
>> 2333: 
>> 2334:   __ load_resolved_indy_entry(cache, index);
>> 2335:   __ ldr(method, Address(cache, in_bytes(ResolvedIndyEntry::method_offset())));
> 
> Should this load have acquire semantics?
> Like [here in template interpreter](https://github.com/openjdk/jdk/blob/2f23c80e0de44815d26a7d541701e16c9c1d32bc/src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp#L239) and [here for the zero interpreter](https://github.com/openjdk/jdk/blob/2f23c80e0de44815d26a7d541701e16c9c1d32bc/src/hotspot/share/oops/cpCache.inline.hpp#L33)?
> 
> Call stack for zero interpreter is
> 
> ConstantPoolCacheEntry::indices_ord()
> ConstantPoolCacheEntry::bytecode_1()
> ConstantPoolCacheEntry::is_resolved(enum Bytecodes::Code)
> BytecodeInterpreter::run(interpreterState)

Yes, acquire semantics should be used here. Thank you for pointing this out!

-------------

PR: https://git.openjdk.org/jdk/pull/12778

From rrich at openjdk.org  Thu Mar 16 22:23:24 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Thu, 16 Mar 2023 22:23:24 GMT
Subject: RFR: 8296440: Remove Method* handling from
 cleanup_inline_caches_impl
In-Reply-To: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
References: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
Message-ID: <KHCYbh1w0gtfrG8xNzIryd66wP5Y7tWfBYGNzKg-VGQ=.57d7aa7a-0fcb-4fa1-8d15-1fe4cb03955f@github.com>

On Wed, 1 Mar 2023 11:07:36 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> This PR replaces cleaning of static stubs in CompiledMethod::cleanup_inline_caches_impl() with a guarantee that it is actually not needed because the holder of the embedded target Method* is alive if the caller nmethod is not unloading.
> 
> The holder of the target Method* has to be alive because it is reachable from the caller nmethod's oop pool. This is checked by `check_path_to_callee()` when a statically bound call gets resolved.
> 
> C2i entry barriers can be removed for the same reason.
> 
> Testing:
> 
> Many rounds in our CI testing which includes most JCK and JTREG tests, Renaissance benchmark and SAP specific tests with fastdebug and release builds on the standard platforms plus PPC64.
> 
> I've also done tier1 and tier2 tests with -XX:-Inline and tier1 tests with ZGC.
> 
> I've started hotspot and jdk tier1 tests with -Xcomp. They were not finished when I stopped them after 24h.

Reproducer: `./bin/jruby -J-Xcomp -J-ea -J-esa -J-XX:CompileThreshold=100 -S rake spec:ruby:fast
`

-------------

PR: https://git.openjdk.org/jdk/pull/12802

From dholmes at openjdk.org  Thu Mar 16 22:38:39 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 16 Mar 2023 22:38:39 GMT
Subject: RFR: 8292818: replace 96-bit representation for field metadata
 with variable-sized streams [v5]
In-Reply-To: <bZJIThP0PV4ic1UBs4eXRqgBLhpNER813xmY8iiOqgY=.7a83c2d2-24e5-472b-87af-26ca6d8b90bf@github.com>
References: <vdiacOO3JUyy4sWGkDXNBMUT7cG3XYe79mOvYru9uMM=.9c556675-7ffd-4c09-a428-6d64dffef209@github.com>
 <bZJIThP0PV4ic1UBs4eXRqgBLhpNER813xmY8iiOqgY=.7a83c2d2-24e5-472b-87af-26ca6d8b90bf@github.com>
Message-ID: <ldpy9QzrD20oWF8KgulFT3Jf_i7qIRKy9qaZRkJX9kk=.ce7e7766-4413-4942-86c2-79269bc3838b@github.com>

On Wed, 15 Mar 2023 15:41:17 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Please review this change re-implementing the FieldInfo data structure.
>> 
>> The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency.
>> 
>> The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information).
>> 
>> More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818
>> 
>> Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM.
>> 
>> The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format.
>> 
>> Tested with mach5, tier 1 to 7.
>> 
>> Thank you.
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   SA and JVMCI fixes

Nice piece of work Fred - I won't pretend to follow every detail.

A few nits on unnecessary alignment (which may match pre-existing style not evident in the diff).

Thanks.

src/hotspot/share/oops/fieldInfo.inline.hpp line 170:

> 168:     new_flags = old_flags & ~mask;
> 169:     witness = Atomic::cmpxchg(&flags, old_flags, new_flags);
> 170:   } while(witness != old_flags);

Just to prove I did read this :) space needed after `while`

src/hotspot/share/oops/fieldInfo.inline.hpp line 174:

> 172: 
> 173: inline void FieldStatus::update_flag(FieldStatusBitPosition pos, bool z) {
> 174:   if (z)    atomic_set_bits(  _flags, flag_mask(pos));

Nit: extra space before `_flags`

src/hotspot/share/oops/fieldInfo.inline.hpp line 175:

> 173: inline void FieldStatus::update_flag(FieldStatusBitPosition pos, bool z) {
> 174:   if (z)    atomic_set_bits(  _flags, flag_mask(pos));
> 175:   else      atomic_clear_bits(_flags, flag_mask(pos));

Nit: no need for the extra spaces. If you really want these to align just place them on ne wlines.

src/hotspot/share/oops/instanceKlass.inline.hpp line 50:

> 48: 
> 49: inline Symbol* InstanceKlass::field_name        (int index) const { return field(index).name(constants()); }
> 50: inline Symbol* InstanceKlass::field_signature   (int index) const { return field(index).signature(constants()); }

There should not be spaces between a method name and the opening `(`. I'm really not a fine of this kind of alignment.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12855

From jvernee at openjdk.org  Fri Mar 17 00:10:31 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 17 Mar 2023 00:10:31 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v21]
In-Reply-To: <RCI233Y726or2PZQLlhyuv7YmZSchb5JNUalXqKpavQ=.b96ef488-eff9-4077-afb9-d94b55f07bfb@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <RCI233Y726or2PZQLlhyuv7YmZSchb5JNUalXqKpavQ=.b96ef488-eff9-4077-afb9-d94b55f07bfb@github.com>
Message-ID: <4-GOVkzGTUqypflffoXoeF9zAlBleE_1zxV3LfcVHow=.afc0426b-2b97-4b02-9ecc-e2d11a1f8a7e@github.com>

On Thu, 16 Mar 2023 14:42:10 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
>> 
>> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
>> 
>> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
>> 
>> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Will get addressed separately: [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
>> 
>> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
>> 
>> I had to make changes to shared code and code for other platforms:
>> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
>> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
>> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
>> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
>> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move ABIv2CallArranger out of linux subdirectory. ABIv1/2 does match the AIX/linux separation.

Marked as reviewed by jvernee (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From sspitsyn at openjdk.org  Fri Mar 17 01:36:47 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 17 Mar 2023 01:36:47 GMT
Subject: RFR: 8304303: implement VirtualThread class notifyJvmti methods as
 C2 intrinsics [v3]
In-Reply-To: <-Pt3zLSu1Y2GYeM8XEivglUyDVXlAqMIA42-_zEnHlo=.7dd40f19-160a-4f11-8702-99c69a9b9923@github.com>
References: <-Pt3zLSu1Y2GYeM8XEivglUyDVXlAqMIA42-_zEnHlo=.7dd40f19-160a-4f11-8702-99c69a9b9923@github.com>
Message-ID: <rXifeBLo2KBfOIWLpS03UcFsgygCDnNLjVu1C1ywAdY=.2e51a780-d9f8-4dbc-96b6-42647d01d6ce@github.com>

> This is needed for performance improvements in support of virtual threads.
> The update includes the following:
> 
> 1. Refactored the `VirtualThread` native methods:
>     `notifyJvmtiMountBegin`     and `notifyJvmtiMountEnd`      => `notifyJvmtiMount`
>     `notifyJvmtiUnmountBegin` and `notifyJvmtiUnmountEnd` => `notifyJvmtiUnmount`
> 2. Still useful implementation of old native methods is moved from `jvm.cpp` to `jvmtiThreadState.cpp`:
>      `JVM_VirtualThreadMountStart`       => `VTMS_mount_begin`
>      `JVM_VirtualThreadMountEnd`         => `VTMS_mount_end`
>      `JVM_VirtualThreadUnmountStart`  = > `VTMS_unmount_begin`
>      `JVM_VirtualThreadUnmountEnd`    => `VTMS_mount_end`
> 3. Intrinsified the `VirtualThread` native methods: `notifyJvmtiMount`, `notifyJvmtiUnmount`, `notifyJvmtiHideFrames`.
> 4. Removed the`VirtualThread` static boolean state variable `notifyJvmtiEvents` and its support in `javaClasses`.
> 5. Added static boolean state variable `_VTMS_notify_jvmti_events` to the jvmtiVTMSTransitionDisabler class as a replacement of the `VirtualThread` `notifyJvmtiEvents` variable.
> 
> Implementing the same methods as C1 intrinsics can be needed in the future but is a low priority for now.  
> 
> Testing:
>  - Ran mach5 tiers 1-6. No regressions were found.

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  address pre-review comments from Leonid

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13054/files
  - new: https://git.openjdk.org/jdk/pull/13054/files/397b6337..f3692263

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13054&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13054&range=01-02

  Stats: 22 lines in 2 files changed: 14 ins; 4 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/13054.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/13054/head:pull/13054

PR: https://git.openjdk.org/jdk/pull/13054

From dholmes at openjdk.org  Fri Mar 17 04:56:22 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 17 Mar 2023 04:56:22 GMT
Subject: RFR: 8304089: Convert TraceDependencies to UL [v3]
In-Reply-To: <SR0H3srVA5CiCcbxL5dHeK2HIJFYvOqZKf0avpuncGU=.dbf27ec1-5455-40b3-aeb2-46d3cb5fbb19@github.com>
References: <0aGc1NdAjpvksCWmXb1gZOPp9MV0n6xWvG8EaEp2ZLg=.b79cf218-9a23-420d-bec5-7509b7f8f1c1@github.com>
 <BQzDwBUOHbm1v3Ex5uAT56pIQJtoT8ON4ZmFhi3TvR0=.ce86f07b-4136-4870-93f0-c9723c80795b@github.com>
 <13yGfFhRFEsjHA-ox_6GxPiyU8w_hpQtgjHbsw6Glq0=.c2330c3f-0316-4f4c-aade-b6ad6c8543ee@github.com>
 <tLhX6beNey8aikbBH30RbCu7lfXZ9AWG2KYqKWVvnkw=.a41fbeb0-6c04-4b6a-824a-fc9fdf734fd2@github.com>
 <2IKS8cYMhoU1JRBEalwF1ZeV4Vih78eXffu_GXZ4JkQ=.27d433ac-1f04-47ce-a177-c791a42bc6fe@github.com>
 <SR0H3srVA5CiCcbxL5dHeK2HIJFYvOqZKf0avpuncGU=.dbf27ec1-5455-40b3-aeb2-46d3cb5fbb19@github.com>
Message-ID: <twz6ptVD0WsinSvvMzp6GGMOjwTotBb0RX9SiGtMnIo=.61a1c3c2-b5ab-4187-b400-2a2da23da7dc@github.com>

On Thu, 16 Mar 2023 13:16:42 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Sorry I don't follow that. `use_vm_log()` only affects non-product builds and forces `LogVMOutput` to true. That in turn will cause `defaultStream::init_log()` to execute which initializes the log file etc. But I don't see how that would cause UL logging for "dependencies" to also get written to the log file???
>
> See the function log_dependency()
> 
> https://github.com/openjdk/jdk/blob/421b4ee33c652cc7c444fbbf298bbc23d052c2fe/src/hotspot/share/code/dependencies.cpp#L845
> 
> called from here (as one place).
> 
> https://github.com/openjdk/jdk/blob/421b4ee33c652cc7c444fbbf298bbc23d052c2fe/src/hotspot/share/code/dependencies.cpp#L2071
> 
> When TraceDependencies was true, the log file would be non-null and log_dependency would write to it.  Keeping this with -Xlog:dependencies=debug retains what TraceDependencies did.

Hmmm this seems broken to me then. We output the general dependency logging to one place based on UL configuration, but then we output `log_dependency` to the log file. If these are meant to be related and always reported together then we have lost that. If they are actually unrelated then this may still need the TraceDependencies flag to control it.

@iwanowww can you comment on this please?

-------------

PR: https://git.openjdk.org/jdk/pull/13007

From stuefe at openjdk.org  Fri Mar 17 06:18:40 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 17 Mar 2023 06:18:40 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v28]
In-Reply-To: <vU0BKEkad-O5kYdt4yAlTGshX91zvQG2ItbkOGx972U=.ff514804-25f6-4bef-aa99-35cdee7353de@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <m-NmDBuUrTUL-lXQbeBG1wBpJHHe4A_we2--SnhdtzA=.3bee0803-04ec-4714-a551-e242f0ee3c06@github.com>
 <vU0BKEkad-O5kYdt4yAlTGshX91zvQG2ItbkOGx972U=.ff514804-25f6-4bef-aa99-35cdee7353de@github.com>
Message-ID: <tDjdKMw2ypISywDGyiizRyU_diwITQkVMWS4OkRxX-Y=.4276eedd-d2cd-4c1a-99fb-ffe75f51f801@github.com>

On Thu, 16 Mar 2023 20:47:59 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> In my last changes I made a stupid mistake and don't set the condition flags correctly to force the slow-path, on aarch64. This is only relevant when we exceed the lock-stack capacity, that is why it's failing so rarely. I don't see a similar problem on x86_64 - have we observed any failures on x86_64? I pushed a fix for aarch64.

I noticed this too for arm; I used cmp to clear EQ but using tst seems better. I also do it inside fast_lock, to give it a defined exit state wrt EQ|NE, since it saves me from having to think about this on every call site. But at least the fail case may be fiddly without conditional execution.

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From rkennke at openjdk.org  Fri Mar 17 06:36:37 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 17 Mar 2023 06:36:37 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v28]
In-Reply-To: <tDjdKMw2ypISywDGyiizRyU_diwITQkVMWS4OkRxX-Y=.4276eedd-d2cd-4c1a-99fb-ffe75f51f801@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <m-NmDBuUrTUL-lXQbeBG1wBpJHHe4A_we2--SnhdtzA=.3bee0803-04ec-4714-a551-e242f0ee3c06@github.com>
 <vU0BKEkad-O5kYdt4yAlTGshX91zvQG2ItbkOGx972U=.ff514804-25f6-4bef-aa99-35cdee7353de@github.com>
 <tDjdKMw2ypISywDGyiizRyU_diwITQkVMWS4OkRxX-Y=.4276eedd-d2cd-4c1a-99fb-ffe75f51f801@github.com>
Message-ID: <_ZdPTSdrR4kfE69GsWFm3Y_WqA_g0aa-m1o3J-TJH6I=.ad2bb926-994c-4f3c-9e74-cebb1456c55e@github.com>

On Fri, 17 Mar 2023 06:15:28 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > In my last changes I made a stupid mistake and don't set the condition flags correctly to force the slow-path, on aarch64. This is only relevant when we exceed the lock-stack capacity, that is why it's failing so rarely. I don't see a similar problem on x86_64 - have we observed any failures on x86_64? I pushed a fix for aarch64.
> 
> 
> 
> I noticed this too for arm; I used cmp to clear EQ but using tst seems better. I also do it inside fast_lock, to give it a defined exit state wrt EQ|NE, since it saves me from having to think about this on every call site. But at least the fail case may be fiddly without conditional execution.

Cmp(r,r) would not clear EQ, but set it. Unless you do cmp(r,0) on a non-null register. Tst is better at least on x86 because it encodes smaller. *shrugs*

You can do it in the shared fast_lock() but it's really only needed in C2, that's why I'm doing it there. Maybe I'm too perfectionist when it comes to assembly code?

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From stuefe at openjdk.org  Fri Mar 17 06:44:37 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 17 Mar 2023 06:44:37 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v28]
In-Reply-To: <_ZdPTSdrR4kfE69GsWFm3Y_WqA_g0aa-m1o3J-TJH6I=.ad2bb926-994c-4f3c-9e74-cebb1456c55e@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <m-NmDBuUrTUL-lXQbeBG1wBpJHHe4A_we2--SnhdtzA=.3bee0803-04ec-4714-a551-e242f0ee3c06@github.com>
 <vU0BKEkad-O5kYdt4yAlTGshX91zvQG2ItbkOGx972U=.ff514804-25f6-4bef-aa99-35cdee7353de@github.com>
 <tDjdKMw2ypISywDGyiizRyU_diwITQkVMWS4OkRxX-Y=.4276eedd-d2cd-4c1a-99fb-ffe75f51f801@github.com>
 <_ZdPTSdrR4kfE69GsWFm3Y_WqA_g0aa-m1o3J-TJH6I=.ad2bb926-994c-4f3c-9e74-cebb1456c55e@github.com>
Message-ID: <K_WO-ZBTCXmFRb9Pp3RZ0Pl3Nj8R4IZY6liMV3xNNzU=.2d399c03-0c0c-4df2-8632-27094b6e0011@github.com>

On Fri, 17 Mar 2023 06:33:43 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> 



> > > In my last changes I made a stupid mistake and don't set the condition flags correctly to force the slow-path, on aarch64. This is only relevant when we exceed the lock-stack capacity, that is why it's failing so rarely. I don't see a similar problem on x86_64 - have we observed any failures on x86_64? I pushed a fix for aarch64.
> > 
> > 
> > I noticed this too for arm; I used cmp to clear EQ but using tst seems better. I also do it inside fast_lock, to give it a defined exit state wrt EQ|NE, since it saves me from having to think about this on every call site. But at least the fail case may be fiddly without conditional execution.
> 
> Cmp(r,r) would not clear EQ, but set it. Unless you do cmp(r,0) on a non-null register.

Sure. I used cmp with an immediate that I knew was not the value. Clunky, I know. As I wrote, tst seems better.

> Tst is better at least on x86 because it encodes smaller. _shrugs_
> 
> You can do it in the shared fast_lock() but it's really only needed in C2, that's why I'm doing it there. Maybe I'm too perfectionist when it comes to assembly code?

I felt just better having it there, at least for the start. I may still move it outside to C2. Lets see.

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From amitkumar at openjdk.org  Fri Mar 17 08:13:09 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Fri, 17 Mar 2023 08:13:09 GMT
Subject: RFR: 8302328: [s390x] Simplify asm_assert definition
In-Reply-To: <51VAVmniXPGE4sgcdw2AnU1hqZn2fVJRyDEbrt3AyyU=.b70f59dc-8397-4da4-b36b-266766434b19@github.com>
References: <51VAVmniXPGE4sgcdw2AnU1hqZn2fVJRyDEbrt3AyyU=.b70f59dc-8397-4da4-b36b-266766434b19@github.com>
Message-ID: <Jp8K4cHUR3R26KCE60vrP8UxB3Rlqghjo7bgD8Z4tkg=.9ff57230-4357-4e4e-a073-c253f75e11a0@github.com>

On Thu, 2 Mar 2023 07:49:05 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> This PR cleanups some assert statements and specifies branch condition at calling site itself. Remaining asm_assert methods are inlined as well.

A gentle reminder for reviewing this PR.

-------------

PR: https://git.openjdk.org/jdk/pull/12822

From duke at openjdk.org  Fri Mar 17 08:51:53 2023
From: duke at openjdk.org (Afshin Zafari)
Date: Fri, 17 Mar 2023 08:51:53 GMT
Subject: RFR: 8292059: Do not inline InstanceKlass::allocate_instance()
 [v7]
In-Reply-To: <CsNJOC_Q5cgJq-a-dqqWo-E9ObvSRmXO61XOUFdya7k=.e0004a11-6642-44ff-96a5-ada39c1259a6@github.com>
References: <ZSJBTzuC4wVuKdqSLLTgw4Pds2oX5wah0Ub6rFux_tc=.c4e2ae89-cadb-4ccd-9eee-034583cf7200@github.com>
 <CsNJOC_Q5cgJq-a-dqqWo-E9ObvSRmXO61XOUFdya7k=.e0004a11-6642-44ff-96a5-ada39c1259a6@github.com>
Message-ID: <b8HZ_AbWmvUtxWFpPBTL9GM8YWpOGSWXncdeTt0LeVg=.d154b846-450f-4847-b253-72f74858d6e4@github.com>

On Wed, 15 Mar 2023 13:39:10 GMT, Afshin Zafari <duke at openjdk.org> wrote:

>> The inline and not-inline versions of the method is tested to compare the performance difference. 
>> ### Test
>> `make test TEST=micro:Capture0.lambda_01 MICRO="VM_OPTIONS=-XX:TieredStopAtLevel=1" `
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8292059: Do not inline InstanceKlass::allocate_instance()

Thank you all reviewers for your comments on this PR.

-------------

PR: https://git.openjdk.org/jdk/pull/12782

From stuefe at openjdk.org  Fri Mar 17 09:04:24 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 17 Mar 2023 09:04:24 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v28]
In-Reply-To: <_ZdPTSdrR4kfE69GsWFm3Y_WqA_g0aa-m1o3J-TJH6I=.ad2bb926-994c-4f3c-9e74-cebb1456c55e@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <m-NmDBuUrTUL-lXQbeBG1wBpJHHe4A_we2--SnhdtzA=.3bee0803-04ec-4714-a551-e242f0ee3c06@github.com>
 <vU0BKEkad-O5kYdt4yAlTGshX91zvQG2ItbkOGx972U=.ff514804-25f6-4bef-aa99-35cdee7353de@github.com>
 <tDjdKMw2ypISywDGyiizRyU_diwITQkVMWS4OkRxX-Y=.4276eedd-d2cd-4c1a-99fb-ffe75f51f801@github.com>
 <_ZdPTSdrR4kfE69GsWFm3Y_WqA_g0aa-m1o3J-TJH6I=.ad2bb926-994c-4f3c-9e74-cebb1456c55e@github.com>
Message-ID: <aYeFmMoRANRFWNt0nJCtiApNSFuwS_yHN7dZtYZ8geg=.2980be2a-6a49-48de-a9f4-3c78919a42f0@github.com>

On Fri, 17 Mar 2023 06:33:43 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>>> In my last changes I made a stupid mistake and don't set the condition flags correctly to force the slow-path, on aarch64. This is only relevant when we exceed the lock-stack capacity, that is why it's failing so rarely. I don't see a similar problem on x86_64 - have we observed any failures on x86_64? I pushed a fix for aarch64.
>> 
>> I noticed this too for arm; I used cmp to clear EQ but using tst seems better. I also do it inside fast_lock, to give it a defined exit state wrt EQ|NE, since it saves me from having to think about this on every call site. But at least the fail case may be fiddly without conditional execution.
>
>> > In my last changes I made a stupid mistake and don't set the condition flags correctly to force the slow-path, on aarch64. This is only relevant when we exceed the lock-stack capacity, that is why it's failing so rarely. I don't see a similar problem on x86_64 - have we observed any failures on x86_64? I pushed a fix for aarch64.
>> 
>> 
>> 
>> I noticed this too for arm; I used cmp to clear EQ but using tst seems better. I also do it inside fast_lock, to give it a defined exit state wrt EQ|NE, since it saves me from having to think about this on every call site. But at least the fail case may be fiddly without conditional execution.
> 
> Cmp(r,r) would not clear EQ, but set it. Unless you do cmp(r,0) on a non-null register. Tst is better at least on x86 because it encodes smaller. *shrugs*
> 
> You can do it in the shared fast_lock() but it's really only needed in C2, that's why I'm doing it there. Maybe I'm too perfectionist when it comes to assembly code?

@rkennke I was not able to directly use 'JavaThread::lock_stack_offset_offset()' in cmp since it was not encodable as immediate. You did not hit the same problem on aarch64, right? IIUC that was more out of accident, since you should have similar or the same (not sure) restrictions for encoding immediates. But your Thread layout is probably different and the offset may just happened to be encodable. If so, that would make you vulnerable against changes in Thread that change the offset of the LockStack.

Anyway, for now I solved this by using the second scratch register as intermediate. One more instruction though. 

I am now experimenting with my original idea of placing the Lockstack slots at a known aligned offset and then testing the alignment of the current index/pointer. This should be possible with a simple TST. Lets see how this goes.

-------------

PR: https://git.openjdk.org/jdk/pull/10907

From mdoerr at openjdk.org  Fri Mar 17 09:31:17 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 17 Mar 2023 09:31:17 GMT
Subject: RFR: 8302328: [s390x] Simplify asm_assert definition
In-Reply-To: <51VAVmniXPGE4sgcdw2AnU1hqZn2fVJRyDEbrt3AyyU=.b70f59dc-8397-4da4-b36b-266766434b19@github.com>
References: <51VAVmniXPGE4sgcdw2AnU1hqZn2fVJRyDEbrt3AyyU=.b70f59dc-8397-4da4-b36b-266766434b19@github.com>
Message-ID: <AAZOTVETrlZwxmjq7B9Kz3i5d2ldbOIxPUAH6_GIbgk=.503743d8-3c4d-4e85-93f5-b5aea1e45614@github.com>

On Thu, 2 Mar 2023 07:49:05 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> This PR cleanups some assert statements and specifies branch condition at calling site itself. Remaining asm_assert methods are inlined as well.

Note that PPC64 still has `asm_assert_eq` and `asm_assert_ne`. But I'm ok with replacing it. Let's hear what other people think.
Including `.inline.hpp` files from `.hpp` files is not acceptable. You need to find a different solution.

-------------

PR: https://git.openjdk.org/jdk/pull/12822

From amitkumar at openjdk.org  Fri Mar 17 10:24:41 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Fri, 17 Mar 2023 10:24:41 GMT
Subject: RFR: 8302328: [s390x] Simplify asm_assert definition
In-Reply-To: <51VAVmniXPGE4sgcdw2AnU1hqZn2fVJRyDEbrt3AyyU=.b70f59dc-8397-4da4-b36b-266766434b19@github.com>
References: <51VAVmniXPGE4sgcdw2AnU1hqZn2fVJRyDEbrt3AyyU=.b70f59dc-8397-4da4-b36b-266766434b19@github.com>
Message-ID: <Wdyqc3YC4e3bMPyfi5Id83o3-u3DSaLkayOJ1MOyre8=.60c0daa2-7b77-4be1-845d-a74bb978ef42@github.com>

On Thu, 2 Mar 2023 07:49:05 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> This PR cleanups some assert statements and specifies branch condition at calling site itself. Remaining asm_assert methods are inlined as well.

So does that make sense to not define them inlined at all ? Because if I do not include `.inline.hpp` then it's doesn't build.

-------------

PR: https://git.openjdk.org/jdk/pull/12822

From sspitsyn at openjdk.org  Fri Mar 17 10:31:46 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 17 Mar 2023 10:31:46 GMT
Subject: RFR: 8304303: implement VirtualThread class notifyJvmti methods as
 C2 intrinsics [v4]
In-Reply-To: <-Pt3zLSu1Y2GYeM8XEivglUyDVXlAqMIA42-_zEnHlo=.7dd40f19-160a-4f11-8702-99c69a9b9923@github.com>
References: <-Pt3zLSu1Y2GYeM8XEivglUyDVXlAqMIA42-_zEnHlo=.7dd40f19-160a-4f11-8702-99c69a9b9923@github.com>
Message-ID: <-kZ3wf7zOt0zABMfgibzmuT5VHuROnTA92lkqbhitbE=.fd934229-b4a6-469a-9c4b-ac9f26efd80f@github.com>

> This is needed for performance improvements in support of virtual threads.
> The update includes the following:
> 
> 1. Refactored the `VirtualThread` native methods:
>     `notifyJvmtiMountBegin`     and `notifyJvmtiMountEnd`      => `notifyJvmtiMount`
>     `notifyJvmtiUnmountBegin` and `notifyJvmtiUnmountEnd` => `notifyJvmtiUnmount`
> 2. Still useful implementation of old native methods is moved from `jvm.cpp` to `jvmtiThreadState.cpp`:
>      `JVM_VirtualThreadMountStart`       => `VTMS_mount_begin`
>      `JVM_VirtualThreadMountEnd`         => `VTMS_mount_end`
>      `JVM_VirtualThreadUnmountStart`  = > `VTMS_unmount_begin`
>      `JVM_VirtualThreadUnmountEnd`    => `VTMS_mount_end`
> 3. Intrinsified the `VirtualThread` native methods: `notifyJvmtiMount`, `notifyJvmtiUnmount`, `notifyJvmtiHideFrames`.
> 4. Removed the`VirtualThread` static boolean state variable `notifyJvmtiEvents` and its support in `javaClasses`.
> 5. Added static boolean state variable `_VTMS_notify_jvmti_events` to the jvmtiVTMSTransitionDisabler class as a replacement of the `VirtualThread` `notifyJvmtiEvents` variable.
> 
> Implementing the same methods as C1 intrinsics can be needed in the future but is a low priority for now.  
> 
> Testing:
>  - Ran mach5 tiers 1-6. No regressions were found.

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  minor tweaks in intrisics implementation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13054/files
  - new: https://git.openjdk.org/jdk/pull/13054/files/f3692263..8233f0ab

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13054&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13054&range=02-03

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13054.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/13054/head:pull/13054

PR: https://git.openjdk.org/jdk/pull/13054

From lucy at openjdk.org  Fri Mar 17 11:05:10 2023
From: lucy at openjdk.org (Lutz Schmidt)
Date: Fri, 17 Mar 2023 11:05:10 GMT
Subject: RFR: 8302328: [s390x] Simplify asm_assert definition
In-Reply-To: <Wdyqc3YC4e3bMPyfi5Id83o3-u3DSaLkayOJ1MOyre8=.60c0daa2-7b77-4be1-845d-a74bb978ef42@github.com>
References: <51VAVmniXPGE4sgcdw2AnU1hqZn2fVJRyDEbrt3AyyU=.b70f59dc-8397-4da4-b36b-266766434b19@github.com>
 <Wdyqc3YC4e3bMPyfi5Id83o3-u3DSaLkayOJ1MOyre8=.60c0daa2-7b77-4be1-845d-a74bb978ef42@github.com>
Message-ID: <w0O6G9xWW9S_L3kBQMfGJcvqKJjENGVGVdpEE9oRH9Q=.957b6f9c-d9f6-4232-bc08-c15689c92a6e@github.com>

On Fri, 17 Mar 2023 10:21:07 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> So does that make sense to not define them inlined at all ? Because if I do not include `.inline.hpp` then it's doesn't build.

I was going to ask you anyway why you decided to convert the asm_assert stuff to inline methods. In general, you do that for performance reasons. Sometimes, it even helps with code size. Think of simple getter and setter methods, where the call overhead is much larger than the "useful" code.

The following rules can guide you with "optimization" decisions:

- Optimize for the release build case (execution time and footprint).
- Optimize for the hottest code path.
- Optimize for the "OK" case.
- The path taken if an error occurred does not need to be as efficient as possible.
- If an assertion fails, it's the end of the JVM. There is no need to rush. 

With the inclusion of macroAssembler.inline.hpp in interp_masm.hpp you are out of luck. As Martin stated, this is not acceptable. *.inline.hpp files are only to be included in *.cpp files. There are 63 *.cpp files including interp_masm.hpp. Any of these may require the definitions from macroAssembler.inline.hpp. How to find out which ones? Trial and error.

-------------

PR: https://git.openjdk.org/jdk/pull/12822

From lucy at openjdk.org  Fri Mar 17 11:08:24 2023
From: lucy at openjdk.org (Lutz Schmidt)
Date: Fri, 17 Mar 2023 11:08:24 GMT
Subject: RFR: 8302328: [s390x] Simplify asm_assert definition
In-Reply-To: <51VAVmniXPGE4sgcdw2AnU1hqZn2fVJRyDEbrt3AyyU=.b70f59dc-8397-4da4-b36b-266766434b19@github.com>
References: <51VAVmniXPGE4sgcdw2AnU1hqZn2fVJRyDEbrt3AyyU=.b70f59dc-8397-4da4-b36b-266766434b19@github.com>
Message-ID: <zdj8oUdL3jqpeYY4rmGy5pxfTFVmQJLPuPvcsgEx87A=.4050a967-103d-4982-b4c9-a33d0e72c03f@github.com>

On Thu, 2 Mar 2023 07:49:05 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> This PR cleanups some assert statements and specifies branch condition at calling site itself. Remaining asm_assert methods are inlined as well.

Overall, I like this change. There are some locations you have to revisit, though. Wrt inlining the as_assert* stuff see my separate comment.

src/hotspot/cpu/s390/c1_LIRAssembler_s390.cpp line 2985:

> 2983:     }
> 2984:   } else {
> 2985:     __ asm_assert(Assembler::bcondNotEqual, "unexpected null obj", __LINE__);

Condition code is from "load and test" instruction. Semantically, that is a comparison against zero. Therefore, please use the semantically correct mask bcondNotZero. Helps others to understand the code.

src/hotspot/cpu/s390/gc/g1/g1BarrierSetAssembler_s390.cpp line 180:

> 178: #ifdef ASSERT
> 179:     __ z_ltgr(Rpre_val, Rpre_val);
> 180:     __ asm_assert(Assembler::bcondNotEqual, "null oop not allowed (G1 pre)", 0x321); // Checked by caller.

Please use bcondNotZero. For reasoning, see above.

src/hotspot/cpu/s390/gc/g1/g1BarrierSetAssembler_s390.cpp line 292:

> 290: #ifdef ASSERT
> 291:     __ z_ltgr(Rnew_val, Rnew_val);
> 292:     __ asm_assert(Assembler::bcondNotEqual, "null oop not allowed (G1 post)", 0x322); // Checked by caller.

Please use bcondNotZero. For reasoning, see above.

src/hotspot/cpu/s390/macroAssembler_s390.inline.hpp line 352:

> 350:   } else {
> 351:     if (tmp != expected_size) {
> 352:       z_lgr(tmp, expected_size);

You could use lgr_if_needed() here.

src/hotspot/cpu/s390/macroAssembler_s390.inline.hpp line 353:

> 351:     if (tmp != expected_size) {
> 352:       z_lgr(tmp, expected_size);
> 353:     }

Shouldn't the else block close here? As coded, the method will have no effect for (tmp == noreg).

src/hotspot/cpu/s390/runtime_s390.cpp line 122:

> 120: #ifdef ASSERT
> 121:   __ z_ltgr(handle_exception, handle_exception);
> 122:   __ asm_assert(Assembler::bcondNotEqual, "handler must not be NULL", 0x852);

Please use bcondNotZero. For reasoning, see above.

src/hotspot/cpu/s390/sharedRuntime_s390.cpp line 2479:

> 2477:   // Make sure that there is at least one entry in the array.
> 2478:   DEBUG_ONLY(__ z_ltgr(number_of_frames_reg, number_of_frames_reg));
> 2479:   __ asm_assert(Assembler::bcondNotEqual, "array_size must be > 0", 0x205);

Please use bcondNotZero. For reasoning, see above.

src/hotspot/cpu/s390/stubGenerator_s390.cpp line 738:

> 736: #ifdef ASSERT
> 737:     __ z_srag(Z_R0, count, 31);  // Just leave the sign (must be zero) in Z_R0.
> 738:     __ asm_assert(Assembler::bcondEqual, "missing zero extend", 0xAFFE);

Please use bcondZero. The CC from srag is equivalent to comparing the result against zero.

src/hotspot/cpu/s390/stubRoutines_s390.cpp line 58:

> 56:     __ z_cgr(table, Z_R0);  // safety net
> 57:     __ z_bre(L);
> 58:     __ z_illtrap();

You should move z_illtrap() after asm_assert(). Not your fault!

src/hotspot/cpu/s390/stubRoutines_s390.cpp line 68:

> 66:     __ z_bre(L);
> 67:     __ z_l(Z_R0, Address(table, 4));   // Load data from memory, we know the constant we compared against.
> 68:     __ z_illtrap();

You should move z_illtrap() after asm_assert(). Not your fault!

src/hotspot/cpu/s390/stubRoutines_s390.cpp line 103:

> 101:       __ z_cgr(table, Z_R0);  // safety net
> 102:       __ z_bre(L);
> 103:       __ z_illtrap();

You should move z_illtrap() after asm_assert(). Not your fault!

src/hotspot/cpu/s390/stubRoutines_s390.cpp line 113:

> 111:       __ z_bre(L);
> 112:       __ z_lg(Z_R0, Address(table, 8));   // Load data from memory, we know the constant we compared against.
> 113:       __ z_illtrap();

You should move z_illtrap() after asm_assert(). Not your fault!

src/hotspot/share/interpreter/interp_masm.hpp line 28:

> 26: #define SHARE_INTERPRETER_INTERP_MASM_HPP
> 27: 
> 28: #include "asm/macroAssembler.inline.hpp"

All the CPU_HEADER(interp_masm) files include "asm/macroAssembler.hpp" as well. That is redundant. You could fix it, but probably with a separate PR.

-------------

Changes requested by lucy (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12822

From duke at openjdk.org  Fri Mar 17 13:26:33 2023
From: duke at openjdk.org (Afshin Zafari)
Date: Fri, 17 Mar 2023 13:26:33 GMT
Subject: Integrated: 8292059: Do not inline InstanceKlass::allocate_instance()
In-Reply-To: <ZSJBTzuC4wVuKdqSLLTgw4Pds2oX5wah0Ub6rFux_tc=.c4e2ae89-cadb-4ccd-9eee-034583cf7200@github.com>
References: <ZSJBTzuC4wVuKdqSLLTgw4Pds2oX5wah0Ub6rFux_tc=.c4e2ae89-cadb-4ccd-9eee-034583cf7200@github.com>
Message-ID: <4F-EPimrITYjasIFSTTwZHBSC2wg0RjxUA_v5RLFvv0=.2e84d720-33d8-4ace-94e7-6a83bf21938d@github.com>

On Tue, 28 Feb 2023 11:11:54 GMT, Afshin Zafari <duke at openjdk.org> wrote:

> The inline and not-inline versions of the method is tested to compare the performance difference. 
> ### Test
> `make test TEST=micro:Capture0.lambda_01 MICRO="VM_OPTIONS=-XX:TieredStopAtLevel=1" `

This pull request has now been integrated.

Changeset: cb4ae192
Author:    Afshin Zafari <Afshin.zafari at oracle.com>
Committer: Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cb4ae1922db7fe3645fd50f301b4a1be965bc79b
Stats:     30 lines in 3 files changed: 13 ins; 16 del; 1 mod

8292059: Do not inline InstanceKlass::allocate_instance()

Reviewed-by: coleenp, stefank

-------------

PR: https://git.openjdk.org/jdk/pull/12782

From fparain at openjdk.org  Fri Mar 17 13:51:05 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 17 Mar 2023 13:51:05 GMT
Subject: RFR: 8292818: replace 96-bit representation for field metadata
 with variable-sized streams [v6]
In-Reply-To: <vdiacOO3JUyy4sWGkDXNBMUT7cG3XYe79mOvYru9uMM=.9c556675-7ffd-4c09-a428-6d64dffef209@github.com>
References: <vdiacOO3JUyy4sWGkDXNBMUT7cG3XYe79mOvYru9uMM=.9c556675-7ffd-4c09-a428-6d64dffef209@github.com>
Message-ID: <nIKAAq4Hcp4Jf6K0WoLU6F_7T03V3yyIz6Dzw3wem_w=.ab45d2a3-ffc7-4eb7-8bcd-6db931a9eeab@github.com>

> Please review this change re-implementing the FieldInfo data structure.
> 
> The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency.
> 
> The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information).
> 
> More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818
> 
> Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM.
> 
> The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format.
> 
> Tested with mach5, tier 1 to 7.
> 
> Thank you.

Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:

  Style fixes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12855/files
  - new: https://git.openjdk.org/jdk/pull/12855/files/f81337f7..ab57b03a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12855&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12855&range=04-05

  Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/12855.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12855/head:pull/12855

PR: https://git.openjdk.org/jdk/pull/12855

From lucy at openjdk.org  Fri Mar 17 14:30:54 2023
From: lucy at openjdk.org (Lutz Schmidt)
Date: Fri, 17 Mar 2023 14:30:54 GMT
Subject: RFR: 8302328: [s390x] Simplify asm_assert definition
In-Reply-To: <51VAVmniXPGE4sgcdw2AnU1hqZn2fVJRyDEbrt3AyyU=.b70f59dc-8397-4da4-b36b-266766434b19@github.com>
References: <51VAVmniXPGE4sgcdw2AnU1hqZn2fVJRyDEbrt3AyyU=.b70f59dc-8397-4da4-b36b-266766434b19@github.com>
Message-ID: <yRDaOC7pI25UGWRzKAnhrat7E7eT4Yofmn9c1SfWBe0=.d15642df-8c90-42b1-8b82-8ab1a38d50df@github.com>

On Thu, 2 Mar 2023 07:49:05 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> This PR cleanups some assert statements and specifies branch condition at calling site itself. Remaining asm_assert methods are inlined as well.

Changes requested by lucy (Reviewer).

src/hotspot/cpu/s390/macroAssembler_s390.hpp line 870:

> 868: 
> 869:   // Assert if CC indicates "not equal" (check_equal==true) or "equal" (check_equal==false).
> 870:   inline void asm_assert(bool check_equal, const char* msg, int id) {

This will not work. Implementation of called method is not visible here. Need to move implementation to macroAssembler_s390.inline.hpp

-------------

PR: https://git.openjdk.org/jdk/pull/12822

From aturbanov at openjdk.org  Fri Mar 17 14:54:30 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 17 Mar 2023 14:54:30 GMT
Subject: RFR: 8292818: replace 96-bit representation for field metadata
 with variable-sized streams [v6]
In-Reply-To: <nIKAAq4Hcp4Jf6K0WoLU6F_7T03V3yyIz6Dzw3wem_w=.ab45d2a3-ffc7-4eb7-8bcd-6db931a9eeab@github.com>
References: <vdiacOO3JUyy4sWGkDXNBMUT7cG3XYe79mOvYru9uMM=.9c556675-7ffd-4c09-a428-6d64dffef209@github.com>
 <nIKAAq4Hcp4Jf6K0WoLU6F_7T03V3yyIz6Dzw3wem_w=.ab45d2a3-ffc7-4eb7-8bcd-6db931a9eeab@github.com>
Message-ID: <EZ_sG0yi-mFse5cF7sqQx-VY2vRmZeVtSD2ZMOrgAZA=.8527d098-c410-408e-a881-95b40f3e0de3@github.com>

On Fri, 17 Mar 2023 13:51:05 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Please review this change re-implementing the FieldInfo data structure.
>> 
>> The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency.
>> 
>> The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information).
>> 
>> More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818
>> 
>> Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM.
>> 
>> The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format.
>> 
>> Tested with mach5, tier 1 to 7.
>> 
>> Thank you.
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Style fixes

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java line 268:

> 266: 
> 267:   Field getField(int index) {
> 268:     synchronized(this) {

nit
Suggestion:

    synchronized (this) {

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java line 380:

> 378:             dos.writeShort(accessFlags & (short) JVM_RECOGNIZED_FIELD_MODIFIERS);
> 379: 
> 380:             int nameIndex    = klass.getFieldNameIndex(index);

nit:
Suggestion:

            int nameIndex = klass.getFieldNameIndex(index);

-------------

PR: https://git.openjdk.org/jdk/pull/12855

From aturbanov at openjdk.org  Fri Mar 17 14:57:44 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 17 Mar 2023 14:57:44 GMT
Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v6]
In-Reply-To: <0hYs21V1ZWB8o92CfvkEW3i0dZKkeW8kYGQu0p6xvtM=.e76da2cd-dbe5-4da2-a6cb-775f081b9a6a@github.com>
References: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>
 <0hYs21V1ZWB8o92CfvkEW3i0dZKkeW8kYGQu0p6xvtM=.e76da2cd-dbe5-4da2-a6cb-775f081b9a6a@github.com>
Message-ID: <NXD8v9kLGnZwtdsUyMCcbWPTbrb75eMUGI0AHCEBsio=.7bad9631-c780-40ea-a473-81e3b1eb7e0d@github.com>

On Tue, 14 Mar 2023 16:06:06 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for accessing annotations. The main differences from `java.lang.reflect.AnnotatedElement` are:
>> * All methods in the `Annotated` interface explicitly specify requested annotation type(s). That is, there is no equivalent of `AnnotatedElement.getAnnotations()`.
>> * Annotation data is returned in a map-like object (of type `jdk.vm.ci.meta.AnnotationData`) instead of in an `Annotation` object. This works better for libgraal as it avoids the need for annotation types to be loaded and included in libgraal.
>>  
>> To demonstrate the new API, here's an example in terms `java.lang.reflect.AnnotatedElement` (which `ResolvedJavaType` implements):
>> 
>>     ResolvedJavaMethod method = ...;
>>     ExplodeLoop a = method.getAnnotation(ExplodeLoop.class);
>>     return switch (a.kind()) {
>>         case FULL_UNROLL -> LoopExplosionKind.FULL_UNROLL;
>>         case FULL_UNROLL_UNTIL_RETURN -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>>         ...
>>     }
>> 
>> 
>> The same code using the new API:
>> 
>> 
>>     ResolvedJavaMethod method = ...;
>>     ResolvedJavaType explodeLoopType = ...;
>>     AnnotationData a = method.getAnnotationDataFor(explodeLoopType);
>>     return switch (a.getEnum("kind").getName()) {
>>         case "FULL_UNROLL" -> LoopExplosionKind.FULL_UNROLL;
>>         case "FULL_UNROLL_UNTIL_RETURN" -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>>         ...
>>     }
>> 
>> 
>> The implementation relies on new methods in `jdk.internal.vm.VMSupport` for parsing annotations and serializing/deserializing to/from a byte array. This allows the annotation data to be passed from the HotSpot heap to the libgraal heap.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressed review feedback

src/java.base/share/classes/jdk/internal/vm/VMSupport.java line 237:

> 235:         try {
> 236:             ByteArrayOutputStream baos = new ByteArrayOutputStream(128);
> 237:             try(DataOutputStream dos = new DataOutputStream(baos)) {

nit
Suggestion:

            try (DataOutputStream dos = new DataOutputStream(baos)) {

src/java.base/share/classes/jdk/internal/vm/VMSupport.java line 564:

> 562:         } else if (length <= 127) {
> 563:             dos.writeByte((byte) (0x80 | length));
> 564:         } else  {

nit
Suggestion:

        } else {

-------------

PR: https://git.openjdk.org/jdk/pull/12810

From aturbanov at openjdk.org  Fri Mar 17 14:59:43 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 17 Mar 2023 14:59:43 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v6]
In-Reply-To: <ivPzEqZ4W-BVPaEyXQ82ppnb-SO-VsgOixcQoHxp6V0=.2abc12b7-76a0-4052-a675-ffb510f9f35a@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <ivPzEqZ4W-BVPaEyXQ82ppnb-SO-VsgOixcQoHxp6V0=.2abc12b7-76a0-4052-a675-ffb510f9f35a@github.com>
Message-ID: <Ni0Z4aGSoL8zUXP-w4S-uwRuWRQlhKWSWjd-JgHGbA0=.47c08a06-777b-4e91-b0b2-a3ccd1d65979@github.com>

On Wed, 15 Mar 2023 18:45:00 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
>> 
>> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
>> 
>> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
>> 
>> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
>> 
>> This change supports the following platforms: x86, aarch64, PPC, and RISCV
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed aarch64 interpreter mistake

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ResolvedIndyEntry.java line 49:

> 47: 
> 48:     private static synchronized void initialize(TypeDataBase db) throws WrongTypeException {
> 49:         Type type            = db.lookupType("ResolvedIndyEntry");

Suggestion:

        Type type = db.lookupType("ResolvedIndyEntry");

-------------

PR: https://git.openjdk.org/jdk/pull/12778

From dnsimon at openjdk.org  Fri Mar 17 15:38:49 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 17 Mar 2023 15:38:49 GMT
Subject: RFR: 8303431: [JVMCI] libgraal annotation API [v7]
In-Reply-To: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>
References: <tPrO32fQApXrW_JX9o3hQIgn4FHmNmLldbaA3F28Ue0=.a8704c44-6560-4ce9-9664-5ba92c6e0d4d@github.com>
Message-ID: <CqTCN7O5wscyBxSYusDCwz_1nI_dNpFLvFVvFWHZRG4=.d4627c4c-a0a5-4232-b1fb-7412097419f7@github.com>

> This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for accessing annotations. The main differences from `java.lang.reflect.AnnotatedElement` are:
> * All methods in the `Annotated` interface explicitly specify requested annotation type(s). That is, there is no equivalent of `AnnotatedElement.getAnnotations()`.
> * Annotation data is returned in a map-like object (of type `jdk.vm.ci.meta.AnnotationData`) instead of in an `Annotation` object. This works better for libgraal as it avoids the need for annotation types to be loaded and included in libgraal.
>  
> To demonstrate the new API, here's an example in terms `java.lang.reflect.AnnotatedElement` (which `ResolvedJavaType` implements):
> 
>     ResolvedJavaMethod method = ...;
>     ExplodeLoop a = method.getAnnotation(ExplodeLoop.class);
>     return switch (a.kind()) {
>         case FULL_UNROLL -> LoopExplosionKind.FULL_UNROLL;
>         case FULL_UNROLL_UNTIL_RETURN -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>         ...
>     }
> 
> 
> The same code using the new API:
> 
> 
>     ResolvedJavaMethod method = ...;
>     ResolvedJavaType explodeLoopType = ...;
>     AnnotationData a = method.getAnnotationDataFor(explodeLoopType);
>     return switch (a.getEnum("kind").getName()) {
>         case "FULL_UNROLL" -> LoopExplosionKind.FULL_UNROLL;
>         case "FULL_UNROLL_UNTIL_RETURN" -> LoopExplosionKind.FULL_UNROLL_UNTIL_RETURN;
>         ...
>     }
> 
> 
> The implementation relies on new methods in `jdk.internal.vm.VMSupport` for parsing annotations and serializing/deserializing to/from a byte array. This allows the annotation data to be passed from the HotSpot heap to the libgraal heap.

Doug Simon has updated the pull request incrementally with one additional commit since the last revision:

  [skip ci] formatting fixes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12810/files
  - new: https://git.openjdk.org/jdk/pull/12810/files/abaf2375..32131796

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12810&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12810&range=05-06

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12810.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12810/head:pull/12810

PR: https://git.openjdk.org/jdk/pull/12810

From fparain at openjdk.org  Fri Mar 17 15:58:35 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 17 Mar 2023 15:58:35 GMT
Subject: RFR: 8292818: replace 96-bit representation for field metadata
 with variable-sized streams [v7]
In-Reply-To: <vdiacOO3JUyy4sWGkDXNBMUT7cG3XYe79mOvYru9uMM=.9c556675-7ffd-4c09-a428-6d64dffef209@github.com>
References: <vdiacOO3JUyy4sWGkDXNBMUT7cG3XYe79mOvYru9uMM=.9c556675-7ffd-4c09-a428-6d64dffef209@github.com>
Message-ID: <JJQ9A1Lgs71qGaGkFL62kqbBjcO1LemtX_beYV2ztn0=.aa06a3ab-5ee4-4b6e-95be-2049e0f4817b@github.com>

> Please review this change re-implementing the FieldInfo data structure.
> 
> The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency.
> 
> The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information).
> 
> More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818
> 
> Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM.
> 
> The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format.
> 
> Tested with mach5, tier 1 to 7.
> 
> Thank you.

Frederic Parain has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - Style fixes
 - Merge remote-tracking branch 'upstream/master' into fieldinfo_unsigned5
 - Style fixes
 - SA and JVMCI fixes
 - Fixes includes and style
 - SA additional caching from Chris Plummer
 - Addressing comments from first reviews
 - Merge remote-tracking branch 'upstream/master' into fieldinfo_unsigned5
 - Reimplementation of FieldInfo as an unsigned5 stream

-------------

Changes: https://git.openjdk.org/jdk/pull/12855/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12855&range=06
  Stats: 1790 lines in 54 files changed: 927 ins; 483 del; 380 mod
  Patch: https://git.openjdk.org/jdk/pull/12855.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12855/head:pull/12855

PR: https://git.openjdk.org/jdk/pull/12855

From vlivanov at openjdk.org  Fri Mar 17 17:36:09 2023
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 17 Mar 2023 17:36:09 GMT
Subject: RFR: 8304303: implement VirtualThread class notifyJvmti methods as
 C2 intrinsics [v4]
In-Reply-To: <-kZ3wf7zOt0zABMfgibzmuT5VHuROnTA92lkqbhitbE=.fd934229-b4a6-469a-9c4b-ac9f26efd80f@github.com>
References: <-Pt3zLSu1Y2GYeM8XEivglUyDVXlAqMIA42-_zEnHlo=.7dd40f19-160a-4f11-8702-99c69a9b9923@github.com>
 <-kZ3wf7zOt0zABMfgibzmuT5VHuROnTA92lkqbhitbE=.fd934229-b4a6-469a-9c4b-ac9f26efd80f@github.com>
Message-ID: <Kt81XkNZAJniM7JndArJ8tlMAwX6gbsZAwuZkB29GsY=.2f2fb6e0-c683-4543-8a9c-9baf045ea2fa@github.com>

On Fri, 17 Mar 2023 10:31:46 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is needed for performance improvements in support of virtual threads.
>> The update includes the following:
>> 
>> 1. Refactored the `VirtualThread` native methods:
>>     `notifyJvmtiMountBegin`     and `notifyJvmtiMountEnd`      => `notifyJvmtiMount`
>>     `notifyJvmtiUnmountBegin` and `notifyJvmtiUnmountEnd` => `notifyJvmtiUnmount`
>> 2. Still useful implementation of old native methods is moved from `jvm.cpp` to `jvmtiThreadState.cpp`:
>>      `JVM_VirtualThreadMountStart`       => `VTMS_mount_begin`
>>      `JVM_VirtualThreadMountEnd`         => `VTMS_mount_end`
>>      `JVM_VirtualThreadUnmountStart`  = > `VTMS_unmount_begin`
>>      `JVM_VirtualThreadUnmountEnd`    => `VTMS_mount_end`
>> 3. Intrinsified the `VirtualThread` native methods: `notifyJvmtiMount`, `notifyJvmtiUnmount`, `notifyJvmtiHideFrames`.
>> 4. Removed the`VirtualThread` static boolean state variable `notifyJvmtiEvents` and its support in `javaClasses`.
>> 5. Added static boolean state variable `_VTMS_notify_jvmti_events` to the jvmtiVTMSTransitionDisabler class as a replacement of the `VirtualThread` `notifyJvmtiEvents` variable.
>> 
>> Implementing the same methods as C1 intrinsics can be needed in the future but is a low priority for now.  
>> 
>> Testing:
>>  - Ran mach5 tiers 1-6. No regressions were found.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor tweaks in intrisics implementation

Overall, compiler changes look good. 

Any performance numbers to justify the intrinsification?

-------------

Marked as reviewed by vlivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/13054

From sspitsyn at openjdk.org  Fri Mar 17 18:36:18 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 17 Mar 2023 18:36:18 GMT
Subject: RFR: 8304303: implement VirtualThread class notifyJvmti methods as
 C2 intrinsics [v4]
In-Reply-To: <Kt81XkNZAJniM7JndArJ8tlMAwX6gbsZAwuZkB29GsY=.2f2fb6e0-c683-4543-8a9c-9baf045ea2fa@github.com>
References: <-Pt3zLSu1Y2GYeM8XEivglUyDVXlAqMIA42-_zEnHlo=.7dd40f19-160a-4f11-8702-99c69a9b9923@github.com>
 <-kZ3wf7zOt0zABMfgibzmuT5VHuROnTA92lkqbhitbE=.fd934229-b4a6-469a-9c4b-ac9f26efd80f@github.com>
 <Kt81XkNZAJniM7JndArJ8tlMAwX6gbsZAwuZkB29GsY=.2f2fb6e0-c683-4543-8a9c-9baf045ea2fa@github.com>
Message-ID: <JJYO-nvC5DObn6lbMsHm-TZv1wccNeTlNvVODZ1EP7o=.35842e76-8410-450b-8d25-4344f6976b0e@github.com>

On Fri, 17 Mar 2023 17:33:46 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Overall, compiler changes look good.
> Any performance numbers to justify the intrinsification?

Thank you for review and your guidance and help with C2 intrinsification!
My goal was to move the notifyJvmtiEvents checks from Java to VM side without a performance penalty.
I do not observe any performance degradation with customized Skynet benchmark executing 5 million virtual threads.
Used `time` utility to measure total execution time (in milliseconds) of 10 runs on Oracle Linux server:
- without intrinsics: 6083, 5405, 5270, 5700, 5004, 5402, 5536, 5031, 4902, 5124
- with intrinsics:       5904, 5287, 5470, 5672, 5298, 5053, 6154, 4992, 6237, 5155

-------------

PR: https://git.openjdk.org/jdk/pull/13054

From matsaave at openjdk.org  Fri Mar 17 19:53:28 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Fri, 17 Mar 2023 19:53:28 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v7]
In-Reply-To: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
Message-ID: <kDKBRZTLQhco_jBDfFDQgWeaiuXw3SqbjiB19RYd95o=.61322253-cefd-49e4-ba66-618faadd1ba2@github.com>

> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
> 
> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
> 
> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
> 
> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
> 
> This change supports the following platforms: x86, aarch64, PPC, and RISCV

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  Acquire semantics

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12778/files
  - new: https://git.openjdk.org/jdk/pull/12778/files/9a3a63ae..3dc112b2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12778&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12778&range=05-06

  Stats: 10 lines in 4 files changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/12778.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12778/head:pull/12778

PR: https://git.openjdk.org/jdk/pull/12778

From fparain at openjdk.org  Fri Mar 17 20:19:39 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 17 Mar 2023 20:19:39 GMT
Subject: RFR: 8292818: replace 96-bit representation for field metadata
 with variable-sized streams [v7]
In-Reply-To: <JJQ9A1Lgs71qGaGkFL62kqbBjcO1LemtX_beYV2ztn0=.aa06a3ab-5ee4-4b6e-95be-2049e0f4817b@github.com>
References: <vdiacOO3JUyy4sWGkDXNBMUT7cG3XYe79mOvYru9uMM=.9c556675-7ffd-4c09-a428-6d64dffef209@github.com>
 <JJQ9A1Lgs71qGaGkFL62kqbBjcO1LemtX_beYV2ztn0=.aa06a3ab-5ee4-4b6e-95be-2049e0f4817b@github.com>
Message-ID: <Q0Nv_TtYwf5tE1BKyRkPuAZulNWPHDQ2uXNxtBcXXkE=.e12bb3cb-cbfc-4796-b572-9d3f372378c3@github.com>

On Fri, 17 Mar 2023 15:58:35 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Please review this change re-implementing the FieldInfo data structure.
>> 
>> The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency.
>> 
>> The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information).
>> 
>> More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818
>> 
>> Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM.
>> 
>> The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format.
>> 
>> Tested with mach5, tier 1 to 7.
>> 
>> Thank you.
>
> Frederic Parain has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Style fixes
>  - Merge remote-tracking branch 'upstream/master' into fieldinfo_unsigned5
>  - Style fixes
>  - SA and JVMCI fixes
>  - Fixes includes and style
>  - SA additional caching from Chris Plummer
>  - Addressing comments from first reviews
>  - Merge remote-tracking branch 'upstream/master' into fieldinfo_unsigned5
>  - Reimplementation of FieldInfo as an unsigned5 stream

Chris, Doug, thank you for your reviews and your help.
Coleen, David, Andrey, thank you for your reviews.

-------------

PR: https://git.openjdk.org/jdk/pull/12855

From fparain at openjdk.org  Fri Mar 17 20:22:48 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 17 Mar 2023 20:22:48 GMT
Subject: Integrated: 8292818: replace 96-bit representation for field metadata
 with variable-sized streams
In-Reply-To: <vdiacOO3JUyy4sWGkDXNBMUT7cG3XYe79mOvYru9uMM=.9c556675-7ffd-4c09-a428-6d64dffef209@github.com>
References: <vdiacOO3JUyy4sWGkDXNBMUT7cG3XYe79mOvYru9uMM=.9c556675-7ffd-4c09-a428-6d64dffef209@github.com>
Message-ID: <1g-MNikg2bzX02U4IDcsKO4nGqPUWZI-77gTMrmQtlA=.5a102edd-69f2-4cd8-9738-fe5075f02f2c@github.com>

On Fri, 3 Mar 2023 14:50:34 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review this change re-implementing the FieldInfo data structure.
> 
> The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency.
> 
> The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information).
> 
> More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818
> 
> Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM.
> 
> The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format.
> 
> Tested with mach5, tier 1 to 7.
> 
> Thank you.

This pull request has now been integrated.

Changeset: bfb812a8
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bfb812a8ff8bca70aed7695c73f019ae66ac6f33
Stats:     1790 lines in 54 files changed: 927 ins; 483 del; 380 mod

8292818: replace 96-bit representation for field metadata with variable-sized streams

Co-authored-by: John R Rose <jrose at openjdk.org>
Co-authored-by: Chris Plummer <cjplummer at openjdk.org>
Reviewed-by: dholmes, coleenp, cjplummer, dnsimon

-------------

PR: https://git.openjdk.org/jdk/pull/12855

From matsaave at openjdk.org  Fri Mar 17 22:08:23 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Fri, 17 Mar 2023 22:08:23 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v8]
In-Reply-To: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
Message-ID: <dSUd7lBCuKfxz3maz2KiyDcBqFVp7eWabnnSmKrU3sQ=.272798ee-0d66-4249-a9d6-a1f9d815ba71@github.com>

> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
> 
> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
> 
> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
> 
> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
> 
> This change supports the following platforms: x86, aarch64, PPC, and RISCV

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  Fixed aarch64 and added load-acquire for resolution check

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12778/files
  - new: https://git.openjdk.org/jdk/pull/12778/files/3dc112b2..6600e6dc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12778&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12778&range=06-07

  Stats: 7 lines in 2 files changed: 4 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12778.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12778/head:pull/12778

PR: https://git.openjdk.org/jdk/pull/12778

From stuefe at openjdk.org  Sat Mar 18 06:34:22 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 18 Mar 2023 06:34:22 GMT
Subject: RFR: JDK-8294266: Add a way to pre-touch java thread stacks [v4]
In-Reply-To: <LuMQx6RZTOp5_Yl_v6gFaQw4lMzhdTv7neo45cZX1Pk=.d1968e1b-3384-414a-8573-745e1e41faba@github.com>
References: <pbqYDWsnkM5XdmZE6QK7wV7dNuQOCjdyPzw5OlQkSxo=.4ea19fb5-d031-42f7-850c-ae42399e0e80@github.com>
 <LuMQx6RZTOp5_Yl_v6gFaQw4lMzhdTv7neo45cZX1Pk=.d1968e1b-3384-414a-8573-745e1e41faba@github.com>
Message-ID: <zYS5Qu2JJklGFyiP82LHgE3ZTMJ2hKBLfEgO4qCBL8s=.4d52c565-69f1-435a-b0a4-af58a4a6d498@github.com>

On Mon, 14 Nov 2022 10:16:58 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> When doing performance- and footprint analysis, `AlwaysPreTouch` option is very handy for reducing noise. It would be good to have a similar option for pre-touching thread stacks. In addition to reducing noise, it can serve as worst-case test for thread costs, as well as a test for NMT regressions.
>> 
>> Patch adds a new diagnostic switch, `AlwaysPreTouchStacks`, as a companion switch to `AlwaysPreTouch`. Touching is super-simple using `alloca()`. Also, regression test.
>> 
>> Examples:
>> 
>> NMT, thread stacks, 10000 Threads, default:
>> 
>> 
>> -                    Thread (reserved=10332400KB, committed=331828KB)                                       
>>                             (thread #10021)                                                                 
>>                             (stack: reserved=10301560KB, committed=300988KB)                                
>>                             (malloc=19101KB #60755)                                                         
>>                             (arena=11739KB #20037)                                                          
>> 
>> 
>> NMT, thread stacks, 10000 Threads, +AlwaysPreTouchStacks:
>> 
>> 
>> -                    Thread (reserved=10332400KB, committed=10284360KB)                        
>>                             (thread #10021)                                                    
>>                             (stack: reserved=10301560KB, committed=10253520KB)                 
>>                             (malloc=19101KB #60755)                                            
>>                             (arena=11739KB #20037)
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test changes, comment change

not yet bot

-------------

PR: https://git.openjdk.org/jdk/pull/10403

From yzhu at openjdk.org  Sat Mar 18 08:50:18 2023
From: yzhu at openjdk.org (Yanhong Zhu)
Date: Sat, 18 Mar 2023 08:50:18 GMT
Subject: RFR: 8304293: RISC-V: JDK-8276799 missed atomic intrinsic support
 for C1
In-Reply-To: <9U2safmMfGsfIIlyBZW3E3dbm68mKcBAzemr5yqoPEw=.c261f575-2cbc-402e-b742-7a6bdc8c2450@github.com>
References: <9U2safmMfGsfIIlyBZW3E3dbm68mKcBAzemr5yqoPEw=.c261f575-2cbc-402e-b742-7a6bdc8c2450@github.com>
Message-ID: <s_MNCjbc_iCZgF9xGWyRcBmgJ0MznhPxZK11JwQAf8E=.78767fb6-4e7d-4c1b-8ee2-15c01f9b8f44@github.com>

On Thu, 16 Mar 2023 03:37:10 GMT, Feilong Jiang <fjiang at openjdk.org> wrote:

> The following intrinsics in C1 are controlled by supports_atomic_xxx, but they are not set properly on RISC-V:
> - _getAndAddInt
> - _getAndAddLong
> - _getAndSetInt
> - _getAndSetLong
> - _getAndSetReference
> 
> RISC-V provides a set of atomic instructions [1], these intrinsics could be enabled by default.
> 
> Here is the HIR output of C1:
> 
> before:
> 
> 
> B18 (V) [189, 196] -> B20 pred: B8 B17 
> empty stack
> inlining depth 0
> __bci__use__tid____instr____________________________________
>   0    0    a251   <instance 0x00000040a802fb98 klass=jdk/internal/misc/Unsafe>
>   3    0    a252   null   
>   4    0    l254   274954985816L
>   7    0    l255   1L
> . 8    0    l256   a251.invokespecial(a252, l254, l255)
>                    jdk/internal/misc/Unsafe.getAndAddLong(Ljava/lang/Object;JJ)J
> . 193  0    l258   a42._24 := l256 (J) tid
> . 196  0     259   goto B20
> 
> 
> after:
> 
> 
> B18 (V) [189, 196] -> B20 pred: B8 B17 
> empty stack
> inlining depth 0
> __bci__use__tid____instr____________________________________
>   0    0    a251   <instance 0x00000040a802fb98 klass=jdk/internal/misc/Unsafe>
>   3    0    a252   null   
>   4    0    l254   274954985816L
>   7    0    l255   1L
> . 8    0    l256   UnsafeGetAndSet (add)(a252, l254, value l255)
> . 193  0    l258   a42._24 := l256 (J) tid
> . 196  0     259   goto B20
> 
> 
> 1. https://github.com/riscv/riscv-isa-manual/blob/8b9047d8d20ef548f7996efee1550760d7bc1279/src/a.tex#L416-L422
> 
> Testing:
> 
> - [x] `hotspot_tier1` & `jdk_tier1` on Unmatched board (release build)

Looks good to me.

-------------

Marked as reviewed by yzhu (Author).

PR: https://git.openjdk.org/jdk/pull/13053

From alanb at openjdk.org  Sat Mar 18 11:27:20 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 18 Mar 2023 11:27:20 GMT
Subject: RFR: 8304303: implement VirtualThread class notifyJvmti methods as
 C2 intrinsics [v4]
In-Reply-To: <-kZ3wf7zOt0zABMfgibzmuT5VHuROnTA92lkqbhitbE=.fd934229-b4a6-469a-9c4b-ac9f26efd80f@github.com>
References: <-Pt3zLSu1Y2GYeM8XEivglUyDVXlAqMIA42-_zEnHlo=.7dd40f19-160a-4f11-8702-99c69a9b9923@github.com>
 <-kZ3wf7zOt0zABMfgibzmuT5VHuROnTA92lkqbhitbE=.fd934229-b4a6-469a-9c4b-ac9f26efd80f@github.com>
Message-ID: <-OJbhkKU3EtSS8E31eEd62h3-x5Szpl_Hk0apm1a6aQ=.687c660f-bc13-41cd-bc63-c59ca60300f0@github.com>

On Fri, 17 Mar 2023 10:31:46 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is needed for future performance/scalability improvements in JVMTI support of virtual threads.
>> The update includes the following:
>> 
>> 1. Refactored the `VirtualThread` native methods:
>>     `notifyJvmtiMountBegin`     and `notifyJvmtiMountEnd`      => `notifyJvmtiMount`
>>     `notifyJvmtiUnmountBegin` and `notifyJvmtiUnmountEnd` => `notifyJvmtiUnmount`
>> 2. Still useful implementation of old native methods is moved from `jvm.cpp` to `jvmtiThreadState.cpp`:
>>      `JVM_VirtualThreadMountStart`       => `VTMS_mount_begin`
>>      `JVM_VirtualThreadMountEnd`         => `VTMS_mount_end`
>>      `JVM_VirtualThreadUnmountStart`  = > `VTMS_unmount_begin`
>>      `JVM_VirtualThreadUnmountEnd`    => `VTMS_mount_end`
>> 3. Intrinsified the `VirtualThread` native methods: `notifyJvmtiMount`, `notifyJvmtiUnmount`, `notifyJvmtiHideFrames`.
>> 4. Removed the`VirtualThread` static boolean state variable `notifyJvmtiEvents` and its support in `javaClasses`.
>> 5. Added static boolean state variable `_VTMS_notify_jvmti_events` to the jvmtiVTMSTransitionDisabler class as a replacement of the `VirtualThread` `notifyJvmtiEvents` variable.
>> 
>> Implementing the same methods as C1 intrinsics can be needed in the future but is a low priority for now.  
>> 
>> Testing:
>>  - Ran mach5 tiers 1-6. No regressions were found.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor tweaks in intrisics implementation

The most important case is when there is no JVMTI env. If I read the changes correctly, the overhead for park/continue changes from one volatile-read (notifyJvmtiEvents) to two plain-writes (JavaThread::_is_in_VTMS_transition).

If a JVMTI env has been created then there is no benefit for the moment as there is still a call into the runtime to interact with JvmtiVTMSTransitionDisabler. So I think you are saying that is for follow-on PRs.

-------------

PR: https://git.openjdk.org/jdk/pull/13054

From qamai at openjdk.org  Sun Mar 19 13:10:09 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Sun, 19 Mar 2023 13:10:09 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
Message-ID: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>

Hi,

This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, VectorShuffle is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:

1. Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
2. Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
3. Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
4. Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.

Upon these changes, a `rearrange` can emit more efficient code:

    var species = IntVector.SPECIES_128;
    var v1 = IntVector.fromArray(species, SRC1, 0);
    var v2 = IntVector.fromArray(species, SRC2, 0);
    v1.rearrange(v2.toShuffle()).intoArray(DST, 0);

    Before:
    movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
    vmovdqu 0x10(%r10),%xmm2
    movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
    vmovdqu 0x10(%r10),%xmm1
    movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
    vmovdqu 0x10(%r10),%xmm0
    vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
                                                            ;   {external_word}
    vpackusdw %xmm0,%xmm0,%xmm0
    vpackuswb %xmm0,%xmm0,%xmm0
    vpmovsxbd %xmm0,%xmm3
    vpcmpgtd %xmm3,%xmm1,%xmm3
    vtestps %xmm3,%xmm3
    jne    0x00007fc2acb4e0d8
    vpmovzxbd %xmm0,%xmm0
    vpermd %ymm2,%ymm0,%ymm0
    movabs $0x751588f98,%r10            ;   {oop([I{0x0000000751588f98})}
    vmovdqu %xmm0,0x10(%r10)

    After:
    movabs $0x751589c78,%r10            ;   {oop([I{0x0000000751589c78})}
    vmovdqu 0x10(%r10),%xmm1
    movabs $0x75158ac88,%r10            ;   {oop([I{0x000000075158ac88})}
    vmovdqu 0x10(%r10),%xmm2
    vpxor  %xmm0,%xmm0,%xmm0
    vpcmpgtd %xmm2,%xmm0,%xmm3
    vtestps %xmm3,%xmm3
    jne    0x00007fa818b27cb1
    vpermd %ymm1,%ymm2,%ymm0
    movabs $0x751588c68,%r10            ;   {oop([I{0x0000000751588c68})}
    vmovdqu %xmm0,0x10(%r10)
    
Please take a look and leave reviews. Thanks a lot.

-------------

Commit messages:
 - fix internal types, clean up
 - optimise laneIsValid
 - Merge branch 'master' into shufflerefactor
 - small beautifications
 - other architecture
 - fix mismatched fp vector payload types
 - draft

Changes: https://git.openjdk.org/jdk/pull/13093/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13093&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304450
  Stats: 4440 lines in 62 files changed: 2567 ins; 651 del; 1222 mod
  Patch: https://git.openjdk.org/jdk/pull/13093.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/13093/head:pull/13093

PR: https://git.openjdk.org/jdk/pull/13093

From lmesnik at openjdk.org  Sun Mar 19 16:52:20 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sun, 19 Mar 2023 16:52:20 GMT
Subject: RFR: 8304303: implement VirtualThread class notifyJvmti methods as
 C2 intrinsics [v4]
In-Reply-To: <-kZ3wf7zOt0zABMfgibzmuT5VHuROnTA92lkqbhitbE=.fd934229-b4a6-469a-9c4b-ac9f26efd80f@github.com>
References: <-Pt3zLSu1Y2GYeM8XEivglUyDVXlAqMIA42-_zEnHlo=.7dd40f19-160a-4f11-8702-99c69a9b9923@github.com>
 <-kZ3wf7zOt0zABMfgibzmuT5VHuROnTA92lkqbhitbE=.fd934229-b4a6-469a-9c4b-ac9f26efd80f@github.com>
Message-ID: <VY4ePUhcCb4J_3Qk-rTb4fjxM3swiV5U2kiXaQob4G4=.0ee731fc-5285-4ea2-bcc3-d2c460ae7217@github.com>

On Fri, 17 Mar 2023 10:31:46 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is needed for future performance/scalability improvements in JVMTI support of virtual threads.
>> The update includes the following:
>> 
>> 1. Refactored the `VirtualThread` native methods:
>>     `notifyJvmtiMountBegin`     and `notifyJvmtiMountEnd`      => `notifyJvmtiMount`
>>     `notifyJvmtiUnmountBegin` and `notifyJvmtiUnmountEnd` => `notifyJvmtiUnmount`
>> 2. Still useful implementation of old native methods is moved from `jvm.cpp` to `jvmtiThreadState.cpp`:
>>      `JVM_VirtualThreadMountStart`       => `VTMS_mount_begin`
>>      `JVM_VirtualThreadMountEnd`         => `VTMS_mount_end`
>>      `JVM_VirtualThreadUnmountStart`  = > `VTMS_unmount_begin`
>>      `JVM_VirtualThreadUnmountEnd`    => `VTMS_mount_end`
>> 3. Intrinsified the `VirtualThread` native methods: `notifyJvmtiMount`, `notifyJvmtiUnmount`, `notifyJvmtiHideFrames`.
>> 4. Removed the`VirtualThread` static boolean state variable `notifyJvmtiEvents` and its support in `javaClasses`.
>> 5. Added static boolean state variable `_VTMS_notify_jvmti_events` to the jvmtiVTMSTransitionDisabler class as a replacement of the `VirtualThread` `notifyJvmtiEvents` variable.
>> 
>> Implementing the same methods as C1 intrinsics can be needed in the future but is a low priority for now.  
>> 
>> Testing:
>>  - Ran mach5 tiers 1-6. No regressions were found.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor tweaks in intrisics implementation

I haven't reviewed C2 changes, all other changes look good to me.

-------------

Marked as reviewed by lmesnik (Reviewer).

PR: https://git.openjdk.org/jdk/pull/13054

From qamai at openjdk.org  Sun Mar 19 19:38:04 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Sun, 19 Mar 2023 19:38:04 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v2]
In-Reply-To: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
Message-ID: <lmW05NgITkLuyzWlWENcX_wEhObY5BRk6L-JyK4LfVg=.817c80e5-92ac-4b9b-9001-1ff1d97a38a4@github.com>

> Hi,
> 
> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, VectorShuffle is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
> 
> 1. Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
> 2. Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
> 3. Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
> 4. Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
> 
> Upon these changes, a `rearrange` can emit more efficient code:
> 
>     var species = IntVector.SPECIES_128;
>     var v1 = IntVector.fromArray(species, SRC1, 0);
>     var v2 = IntVector.fromArray(species, SRC2, 0);
>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
> 
>     Before:
>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>     vmovdqu 0x10(%r10),%xmm2
>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>     vmovdqu 0x10(%r10),%xmm1
>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>     vmovdqu 0x10(%r10),%xmm0
>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>                                                             ;   {external_word}
>     vpackusdw %xmm0,%xmm0,%xmm0
>     vpackuswb %xmm0,%xmm0,%xmm0
>     vpmovsxbd %xmm0,%xmm3
>     vpcmpgtd %xmm3,%xmm1,%xmm3
>     vtestps %xmm3,%xmm3
>     jne    0x00007fc2acb4e0d8
>     vpmovzxbd %xmm0,%xmm0
>     vpermd %ymm2,%ymm0,%ymm0
>     movabs $0x751588f98,%r10            ;   {oop([I{0x0000000751588f98})}
>     vmovdqu %xmm0,0x10(%r10)
> 
>     After:
>     movabs $0x751589c78,%r10            ;   {oop([I{0x0000000751589c78})}
>     vmovdqu 0x10(%r10),%xmm1
>     movabs $0x75158ac88,%r10            ;   {oop([I{0x000000075158ac88})}
>     vmovdqu 0x10(%r10),%xmm2
>     vpxor  %xmm0,%xmm0,%xmm0
>     vpcmpgtd %xmm2,%xmm0,%xmm3
>     vtestps %xmm3,%xmm3
>     jne    0x00007fa818b27cb1
>     vpermd %ymm1,%ymm2,%ymm0
>     movabs $0x751588c68,%r10            ;   {oop([I{0x0000000751588c68})}
>     vmovdqu %xmm0,0x10(%r10)
>     
> Please take a look and leave reviews. Thanks a lot.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  fix Matcher::vector_needs_load_shuffle

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13093/files
  - new: https://git.openjdk.org/jdk/pull/13093/files/7acf928d..060554a9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13093&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13093&range=00-01

  Stats: 9 lines in 1 file changed: 4 ins; 3 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13093.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/13093/head:pull/13093

PR: https://git.openjdk.org/jdk/pull/13093

From kbarrett at openjdk.org  Sun Mar 19 22:06:53 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 19 Mar 2023 22:06:53 GMT
Subject: RFR: 8304016: Add BitMap find_last suite of functions [v2]
In-Reply-To: <uacSVrnq4wrWciqgVSQSnNp05EvZzBTfCrM08ih-KUU=.dd763e87-c71a-4e08-aa96-848420915ead@github.com>
References: <uacSVrnq4wrWciqgVSQSnNp05EvZzBTfCrM08ih-KUU=.dd763e87-c71a-4e08-aa96-848420915ead@github.com>
Message-ID: <WQxGV4Lj1USZici4EhxodhqnAXp2geiZRjADg-GNp2g=.f20ed644-5ce1-4755-9112-b83ac3f909e7@github.com>

> Please review this change that adds functions to BitMap for finding the last
> set/clear bit in a range.
> 
> Testing:
> mach5 tier1, including new gtesting for the new functions.

Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:

 - shrink find_first_bit_impl
 - improve find_last_bit_impl

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12988/files
  - new: https://git.openjdk.org/jdk/pull/12988/files/c3a75dd1..b3d2aed1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12988&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12988&range=00-01

  Stats: 49 lines in 1 file changed: 16 ins; 12 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/12988.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12988/head:pull/12988

PR: https://git.openjdk.org/jdk/pull/12988

From kbarrett at openjdk.org  Sun Mar 19 22:09:18 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 19 Mar 2023 22:09:18 GMT
Subject: RFR: 8304016: Add BitMap find_last suite of functions
In-Reply-To: <uacSVrnq4wrWciqgVSQSnNp05EvZzBTfCrM08ih-KUU=.dd763e87-c71a-4e08-aa96-848420915ead@github.com>
References: <uacSVrnq4wrWciqgVSQSnNp05EvZzBTfCrM08ih-KUU=.dd763e87-c71a-4e08-aa96-848420915ead@github.com>
Message-ID: <aaQ2djtVNLgAVjMuPbAahQx1__-lFc6mhQ40EOe8XtI=.362bf7a4-ac14-4e12-ba15-51456ab86518@github.com>

On Sat, 11 Mar 2023 16:46:44 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that adds functions to BitMap for finding the last
> set/clear bit in a range.
> 
> Testing:
> mach5 tier1, including new gtesting for the new functions.

I've improved find_first/last_bit_impl since the original PR commit.

(1) In find_last_bit_impl, testing the last bit and the last word has been
improved, shaving off an instruction or two (depending on platform). The
previous version incorrectly expected shifts to set condition codes.

(2) The previous version of find_last_bit_impl expected the compiler to CSE
merge the nearly (and now actually, because of the change above) identical
code for handling found bits in cword. But gcc (at least) doen't seem to do
that, so we do it manually. This doesn't have any performance cost, just saves
20-30% of the (inline) code size.

(3) Applied to find_first_bit_impl a similar technique to (2).

The manual tail merging is a little bit indirect.  It might be that it would
be easier to understand by being explicit and using a goto.

-------------

PR: https://git.openjdk.org/jdk/pull/12988

From fjiang at openjdk.org  Mon Mar 20 00:52:29 2023
From: fjiang at openjdk.org (Feilong Jiang)
Date: Mon, 20 Mar 2023 00:52:29 GMT
Subject: RFR: 8304293: RISC-V: JDK-8276799 missed atomic intrinsic support
 for C1
In-Reply-To: <6HOmP1tPgq26gezEvauaAs0UYxGKQrXg3iOA7bNC1TQ=.857c8220-ad7b-49f7-bddc-c7c9a807664b@github.com>
References: <9U2safmMfGsfIIlyBZW3E3dbm68mKcBAzemr5yqoPEw=.c261f575-2cbc-402e-b742-7a6bdc8c2450@github.com>
 <6HOmP1tPgq26gezEvauaAs0UYxGKQrXg3iOA7bNC1TQ=.857c8220-ad7b-49f7-bddc-c7c9a807664b@github.com>
Message-ID: <rKujgmaC43yg9rPBhMwZPFPEI6nPyj386RXQUnU1jjQ=.89212552-3d26-4263-b610-2cdb80b21450@github.com>

On Thu, 16 Mar 2023 09:35:10 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> The following intrinsics in C1 are controlled by supports_atomic_xxx, but they are not set properly on RISC-V:
>> - _getAndAddInt
>> - _getAndAddLong
>> - _getAndSetInt
>> - _getAndSetLong
>> - _getAndSetReference
>> 
>> RISC-V provides a set of atomic instructions [1], these intrinsics could be enabled by default.
>> 
>> Here is the HIR output of C1:
>> 
>> before:
>> 
>> 
>> B18 (V) [189, 196] -> B20 pred: B8 B17 
>> empty stack
>> inlining depth 0
>> __bci__use__tid____instr____________________________________
>>   0    0    a251   <instance 0x00000040a802fb98 klass=jdk/internal/misc/Unsafe>
>>   3    0    a252   null   
>>   4    0    l254   274954985816L
>>   7    0    l255   1L
>> . 8    0    l256   a251.invokespecial(a252, l254, l255)
>>                    jdk/internal/misc/Unsafe.getAndAddLong(Ljava/lang/Object;JJ)J
>> . 193  0    l258   a42._24 := l256 (J) tid
>> . 196  0     259   goto B20
>> 
>> 
>> after:
>> 
>> 
>> B18 (V) [189, 196] -> B20 pred: B8 B17 
>> empty stack
>> inlining depth 0
>> __bci__use__tid____instr____________________________________
>>   0    0    a251   <instance 0x00000040a802fb98 klass=jdk/internal/misc/Unsafe>
>>   3    0    a252   null   
>>   4    0    l254   274954985816L
>>   7    0    l255   1L
>> . 8    0    l256   UnsafeGetAndSet (add)(a252, l254, value l255)
>> . 193  0    l258   a42._24 := l256 (J) tid
>> . 196  0     259   goto B20
>> 
>> 
>> 1. https://github.com/riscv/riscv-isa-manual/blob/8b9047d8d20ef548f7996efee1550760d7bc1279/src/a.tex#L416-L422
>> 
>> Testing:
>> 
>> - [x] `hotspot_tier1` & `jdk_tier1` on Unmatched board (release build)
>
> Looks good. Thanks for finding this.

@RealFYang @yhzhu20 -- Thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/13053

From fjiang at openjdk.org  Mon Mar 20 00:57:27 2023
From: fjiang at openjdk.org (Feilong Jiang)
Date: Mon, 20 Mar 2023 00:57:27 GMT
Subject: Integrated: 8304293: RISC-V: JDK-8276799 missed atomic intrinsic
 support for C1
In-Reply-To: <9U2safmMfGsfIIlyBZW3E3dbm68mKcBAzemr5yqoPEw=.c261f575-2cbc-402e-b742-7a6bdc8c2450@github.com>
References: <9U2safmMfGsfIIlyBZW3E3dbm68mKcBAzemr5yqoPEw=.c261f575-2cbc-402e-b742-7a6bdc8c2450@github.com>
Message-ID: <rdLz1UfrdETZhjsdDAusq04qYVbSrCk7hOTtCM5tcqY=.1bb0a136-8acc-41f5-b0ff-848868ca1410@github.com>

On Thu, 16 Mar 2023 03:37:10 GMT, Feilong Jiang <fjiang at openjdk.org> wrote:

> The following intrinsics in C1 are controlled by supports_atomic_xxx, but they are not set properly on RISC-V:
> - _getAndAddInt
> - _getAndAddLong
> - _getAndSetInt
> - _getAndSetLong
> - _getAndSetReference
> 
> RISC-V provides a set of atomic instructions [1], these intrinsics could be enabled by default.
> 
> Here is the HIR output of C1:
> 
> before:
> 
> 
> B18 (V) [189, 196] -> B20 pred: B8 B17 
> empty stack
> inlining depth 0
> __bci__use__tid____instr____________________________________
>   0    0    a251   <instance 0x00000040a802fb98 klass=jdk/internal/misc/Unsafe>
>   3    0    a252   null   
>   4    0    l254   274954985816L
>   7    0    l255   1L
> . 8    0    l256   a251.invokespecial(a252, l254, l255)
>                    jdk/internal/misc/Unsafe.getAndAddLong(Ljava/lang/Object;JJ)J
> . 193  0    l258   a42._24 := l256 (J) tid
> . 196  0     259   goto B20
> 
> 
> after:
> 
> 
> B18 (V) [189, 196] -> B20 pred: B8 B17 
> empty stack
> inlining depth 0
> __bci__use__tid____instr____________________________________
>   0    0    a251   <instance 0x00000040a802fb98 klass=jdk/internal/misc/Unsafe>
>   3    0    a252   null   
>   4    0    l254   274954985816L
>   7    0    l255   1L
> . 8    0    l256   UnsafeGetAndSet (add)(a252, l254, value l255)
> . 193  0    l258   a42._24 := l256 (J) tid
> . 196  0     259   goto B20
> 
> 
> 1. https://github.com/riscv/riscv-isa-manual/blob/8b9047d8d20ef548f7996efee1550760d7bc1279/src/a.tex#L416-L422
> 
> Testing:
> 
> - [x] `hotspot_tier1` & `jdk_tier1` on Unmatched board (release build)

This pull request has now been integrated.

Changeset: c09f83ec
Author:    Feilong Jiang <fjiang at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c09f83ec25749af349fb5609e3641b5bb6d34072
Stats:     6 lines in 1 file changed: 6 ins; 0 del; 0 mod

8304293: RISC-V: JDK-8276799 missed atomic intrinsic support for C1

Reviewed-by: fyang, yzhu

-------------

PR: https://git.openjdk.org/jdk/pull/13053

From gcao at openjdk.org  Mon Mar 20 01:47:34 2023
From: gcao at openjdk.org (Gui Cao)
Date: Mon, 20 Mar 2023 01:47:34 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v8]
In-Reply-To: <dSUd7lBCuKfxz3maz2KiyDcBqFVp7eWabnnSmKrU3sQ=.272798ee-0d66-4249-a9d6-a1f9d815ba71@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <dSUd7lBCuKfxz3maz2KiyDcBqFVp7eWabnnSmKrU3sQ=.272798ee-0d66-4249-a9d6-a1f9d815ba71@github.com>
Message-ID: <XKniM-lObXl3RDuvpJd1hLqPjK8sTM100C7NLPMQEx8=.318b86cb-8b7e-4752-a605-57a89fb09947@github.com>

On Fri, 17 Mar 2023 22:08:23 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
>> 
>> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
>> 
>> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
>> 
>> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
>> 
>> This change supports the following platforms: x86, aarch64, PPC, and RISCV
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed aarch64 and added load-acquire for resolution check

Hi,
I have updated the riscv related code by referring to the latest aarch64 related changes, please help me to update it. and i tested hotsport , jdk's tier1 and no new errors were introduced
https://github.com/zifeihan/jdk/commit/9c17c5b4953eebdebc6eb84b90a2ff9ca97c78c5
(on this branch: https://github.com/zifeihan/jdk/commits/12778_riscv_port)

-------------

PR: https://git.openjdk.org/jdk/pull/12778

From sspitsyn at openjdk.org  Mon Mar 20 07:18:24 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 20 Mar 2023 07:18:24 GMT
Subject: RFR: 8304303: implement VirtualThread class notifyJvmti methods as
 C2 intrinsics [v4]
In-Reply-To: <-OJbhkKU3EtSS8E31eEd62h3-x5Szpl_Hk0apm1a6aQ=.687c660f-bc13-41cd-bc63-c59ca60300f0@github.com>
References: <-Pt3zLSu1Y2GYeM8XEivglUyDVXlAqMIA42-_zEnHlo=.7dd40f19-160a-4f11-8702-99c69a9b9923@github.com>
 <-kZ3wf7zOt0zABMfgibzmuT5VHuROnTA92lkqbhitbE=.fd934229-b4a6-469a-9c4b-ac9f26efd80f@github.com>
 <-OJbhkKU3EtSS8E31eEd62h3-x5Szpl_Hk0apm1a6aQ=.687c660f-bc13-41cd-bc63-c59ca60300f0@github.com>
Message-ID: <CAdDGg_bSOom6kX8lfwLHfsMdZsgUHp3ieXquES6sWQ=.a32c928d-2e2c-4f9e-9bb9-0d182259786b@github.com>

On Sat, 18 Mar 2023 11:24:47 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The most important case is when there is no JVMTI env. If I read the changes correctly, the overhead for park/continue changes from one volatile-read (notifyJvmtiEvents) to two plain-writes (JavaThread::_is_in_VTMS_transition).
> 
> If a JVMTI env has been created then there is no benefit for the moment as there is still a call into the runtime to interact with JvmtiVTMSTransitionDisabler. So I think you are saying that is for follow-on PRs.
@AlanBateman Yes, your conclusion is correct.

-------------

PR: https://git.openjdk.org/jdk/pull/13054

From sspitsyn at openjdk.org  Mon Mar 20 07:18:27 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 20 Mar 2023 07:18:27 GMT
Subject: RFR: 8304303: implement VirtualThread class notifyJvmti methods as
 C2 intrinsics [v4]
In-Reply-To: <-kZ3wf7zOt0zABMfgibzmuT5VHuROnTA92lkqbhitbE=.fd934229-b4a6-469a-9c4b-ac9f26efd80f@github.com>
References: <-Pt3zLSu1Y2GYeM8XEivglUyDVXlAqMIA42-_zEnHlo=.7dd40f19-160a-4f11-8702-99c69a9b9923@github.com>
 <-kZ3wf7zOt0zABMfgibzmuT5VHuROnTA92lkqbhitbE=.fd934229-b4a6-469a-9c4b-ac9f26efd80f@github.com>
Message-ID: <OzsFIFM056FqPoX71_moTwEM48OMWm_ZrWX9l3yW0dk=.16eea761-b667-4d91-b475-d42273bf7e69@github.com>

On Fri, 17 Mar 2023 10:31:46 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is needed for future performance/scalability improvements in JVMTI support of virtual threads.
>> The update includes the following:
>> 
>> 1. Refactored the `VirtualThread` native methods:
>>     `notifyJvmtiMountBegin`     and `notifyJvmtiMountEnd`      => `notifyJvmtiMount`
>>     `notifyJvmtiUnmountBegin` and `notifyJvmtiUnmountEnd` => `notifyJvmtiUnmount`
>> 2. Still useful implementation of old native methods is moved from `jvm.cpp` to `jvmtiThreadState.cpp`:
>>      `JVM_VirtualThreadMountStart`       => `VTMS_mount_begin`
>>      `JVM_VirtualThreadMountEnd`         => `VTMS_mount_end`
>>      `JVM_VirtualThreadUnmountStart`  = > `VTMS_unmount_begin`
>>      `JVM_VirtualThreadUnmountEnd`    => `VTMS_mount_end`
>> 3. Intrinsified the `VirtualThread` native methods: `notifyJvmtiMount`, `notifyJvmtiUnmount`, `notifyJvmtiHideFrames`.
>> 4. Removed the`VirtualThread` static boolean state variable `notifyJvmtiEvents` and its support in `javaClasses`.
>> 5. Added static boolean state variable `_VTMS_notify_jvmti_events` to the jvmtiVTMSTransitionDisabler class as a replacement of the `VirtualThread` `notifyJvmtiEvents` variable.
>> 
>> Implementing the same methods as C1 intrinsics can be needed in the future but is a low priority for now.  
>> 
>> Testing:
>>  - Ran mach5 tiers 1-6. No regressions were found.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor tweaks in intrisics implementation

Thank you for review, Leonid!

-------------

PR: https://git.openjdk.org/jdk/pull/13054

From stefank at openjdk.org  Mon Mar 20 09:14:24 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 20 Mar 2023 09:14:24 GMT
Subject: RFR: 8304016: Add BitMap find_last suite of functions [v2]
In-Reply-To: <WQxGV4Lj1USZici4EhxodhqnAXp2geiZRjADg-GNp2g=.f20ed644-5ce1-4755-9112-b83ac3f909e7@github.com>
References: <uacSVrnq4wrWciqgVSQSnNp05EvZzBTfCrM08ih-KUU=.dd763e87-c71a-4e08-aa96-848420915ead@github.com>
 <WQxGV4Lj1USZici4EhxodhqnAXp2geiZRjADg-GNp2g=.f20ed644-5ce1-4755-9112-b83ac3f909e7@github.com>
Message-ID: <f8yHtz70aUlAj8LIugSKOL9cQuh0XzcEzHhh92ZJKZU=.ee47acaf-ec0d-4d7b-82be-08b55a1c2330@github.com>

On Sun, 19 Mar 2023 22:06:53 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change that adds functions to BitMap for finding the last
>> set/clear bit in a range.
>> 
>> Testing:
>> mach5 tier1, including new gtesting for the new functions.
>
> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - shrink find_first_bit_impl
>  - improve find_last_bit_impl

Thanks for creating this PR. As we have discussed offline, this is not my preferred code style for these functions, but I'm happy to see this functionality being upstreamed, so consider this reviewed.

-------------

Marked as reviewed by stefank (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12988

From aboldtch at openjdk.org  Mon Mar 20 09:35:28 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 20 Mar 2023 09:35:28 GMT
Subject: RFR: 8304016: Add BitMap find_last suite of functions [v2]
In-Reply-To: <WQxGV4Lj1USZici4EhxodhqnAXp2geiZRjADg-GNp2g=.f20ed644-5ce1-4755-9112-b83ac3f909e7@github.com>
References: <uacSVrnq4wrWciqgVSQSnNp05EvZzBTfCrM08ih-KUU=.dd763e87-c71a-4e08-aa96-848420915ead@github.com>
 <WQxGV4Lj1USZici4EhxodhqnAXp2geiZRjADg-GNp2g=.f20ed644-5ce1-4755-9112-b83ac3f909e7@github.com>
Message-ID: <RSOWPK7sj94lEuQO2VNUQHYYSHrptWcaNhcnCoiOW7w=.9993ec0f-7473-4d00-b50e-22403a392780@github.com>

On Sun, 19 Mar 2023 22:06:53 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change that adds functions to BitMap for finding the last
>> set/clear bit in a range.
>> 
>> Testing:
>> mach5 tier1, including new gtesting for the new functions.
>
> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - shrink find_first_bit_impl
>  - improve find_last_bit_impl

The rewrite made the algorithm more readable, imo.

At some point I would like to type up the `beg` and `end` so it is clear that it is a range with `[beg, end)`

-------------

Marked as reviewed by aboldtch (Committer).

PR: https://git.openjdk.org/jdk/pull/12988

From matsaave at openjdk.org  Mon Mar 20 14:29:35 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Mon, 20 Mar 2023 14:29:35 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v9]
In-Reply-To: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
Message-ID: <W69abHEQZctZeg7QaoW9DFPWPhSNAL3PHMZABD3xLWU=.9e63f600-be6d-4258-991e-4b609be33f0a@github.com>

> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
> 
> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
> 
> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
> 
> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
> 
> This change supports the following platforms: x86, aarch64, PPC, and RISCV

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  Fix riscv interpreter mistake and acquire semantics

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12778/files
  - new: https://git.openjdk.org/jdk/pull/12778/files/6600e6dc..8607f62a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12778&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12778&range=07-08

  Stats: 18 lines in 4 files changed: 4 ins; 7 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/12778.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12778/head:pull/12778

PR: https://git.openjdk.org/jdk/pull/12778

From kvn at openjdk.org  Mon Mar 20 15:46:11 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 20 Mar 2023 15:46:11 GMT
Subject: RFR: 8231349: Move intrinsic stubs generation to compiler runtime
 initialization code
Message-ID: <dtc9rdiBGUpqQUB9AzWBroeF3ziVODfk0FuPFDgOHqE=.096e99b2-2957-46c7-8c74-ae1d737f220d@github.com>

Based on performance data (see graph in RFE) I propose to implement @cl4es suggestion to move intrinsics stubs generation to C2 (and JVMCI) runtime initialization code.

It has <1% difference from not generated these stubs at all and we will not win on 1 core VMs but it is simpler and safer solution, I think. It also automatically (no need for new code) do not generate these stubs if C2 is not used (-Xint or low TieredStopAt Level.

On demand stubs generation requires synchronization between threads during application run which may introduce some instability and may be other issues. But it could be beneficial for Interpreter and C1 if we want more intrinsics stubs to be used by C1 and Interpreter (they use CRC32 only now).  I filed separate RFE  [8304422](https://bugs.openjdk.org/browse/JDK-8304422).

Changes:
 - Added new platform specific diagnostic flag `-XX:+MoveIntrinsicStubsGen`. It is ON by default if VM is built with C2 or JVMCI compilers except Zero and 32-bit Arm VMs which have no or few intrinsics.
 - Split `StubGenerator::generate_all()` method into two: `generate_final_stubs()` and `generate_compiler_stubs()`. Moved only C2 (and JVMCI) intrinsic stubs generation to new method.
 - I renamed methods and stubs buffer sizes according to new code. Now we have 4 separate **named** stubs buffers and corresponding methods: _Initial, Continuation, Compiler, Final_.
 - I added new UL printing to find new sizes for buffers and adjusted them on `aarch64` and `x86`. On other platforms I used the same as before value for `compiler_stubs` and `final_stubs`:

> java -Xlog:stubs -XX:+UseCompressedOops -XX:+CheckCompressedOops -XX:+VerifyOops -XX:-VerifyStackAtCalls -version
[0.006s][info][stubs] StubRoutines (initial stubs)	 [0x00007f94900fcc00, 0x00007f9490101b60] used: 16152, free: 4168
[0.026s][info][stubs] StubRoutines (continuation stubs)	 [0x00007f9490102580, 0x00007f9490102e90] used: 741, free: 1579
[0.051s][info][stubs] StubRoutines (final stubs)	 [0x00007f9490155600, 0x00007f949015cc70] used: 26484, free: 3836
[0.090s][info][stubs] StubRoutines (compiler stubs)	 [0x00007f94904ccc00, 0x00007f94904d9bd0] used: 46988, free: 6212
java version "21-internal" 2023-09-19 LTS

-Xlog:stubs=debug will print size information for each stub:
[0.005s][debug][stubs] ICache::flush_icache_stub [0x00007fb2d3828080, 0x00007fb2d382809d] (29 bytes)
[0.005s][debug][stubs] VM_Version::get_cpu_info_stub [0x00007fb2d3828380, 0x00007fb2d3828714] (916 bytes)
[0.005s][debug][stubs] VM_Version::detect_virt_stub [0x00007fb2d3828714, 0x00007fb2d382872e] (26 bytes)
[0.005s][debug][stubs] StubRoutines::forward exception [0x00007fb2d3828c00, 0x00007fb2d3828c92] (146 bytes)


Testing: tier1-7, Xcomp, stress on x64 and aarch64.

I have changes for all platforms. Please test it on platforms you support.

-------------

Commit messages:
 - remove trailing white space
 - Copyright year update. Small corrections.
 - 8231349: Move intrinsic stubs generation to compiler runtime initialization code

Changes: https://git.openjdk.org/jdk/pull/13096/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13096&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8231349
  Stats: 738 lines in 38 files changed: 386 ins; 125 del; 227 mod
  Patch: https://git.openjdk.org/jdk/pull/13096.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/13096/head:pull/13096

PR: https://git.openjdk.org/jdk/pull/13096

From redestad at openjdk.org  Mon Mar 20 15:46:16 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 20 Mar 2023 15:46:16 GMT
Subject: RFR: 8231349: Move intrinsic stubs generation to compiler runtime
 initialization code
In-Reply-To: <dtc9rdiBGUpqQUB9AzWBroeF3ziVODfk0FuPFDgOHqE=.096e99b2-2957-46c7-8c74-ae1d737f220d@github.com>
References: <dtc9rdiBGUpqQUB9AzWBroeF3ziVODfk0FuPFDgOHqE=.096e99b2-2957-46c7-8c74-ae1d737f220d@github.com>
Message-ID: <IuTeu69iV-nA3uGVQuZzHtc4jax7AnYZDt7TQdj53a0=.7e69132b-3cb8-4b3a-a7b7-ab8962f16ed9@github.com>

On Mon, 20 Mar 2023 07:05:23 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Based on performance data (see graph in RFE) I propose to implement @cl4es suggestion to move intrinsics stubs generation to C2 (and JVMCI) runtime initialization code.
> 
> It has <1% difference from not generated these stubs at all and we will not win on 1 core VMs but it is simpler and safer solution, I think. It also automatically (no need for new code) do not generate these stubs if C2 is not used (-Xint or low TieredStopAt Level.
> 
> On demand stubs generation requires synchronization between threads during application run which may introduce some instability and may be other issues. But it could be beneficial for Interpreter and C1 if we want more intrinsics stubs to be used by C1 and Interpreter (they use CRC32 only now).  I filed separate RFE  [8304422](https://bugs.openjdk.org/browse/JDK-8304422).
> 
> Changes:
>  - Added new platform specific diagnostic flag `-XX:+MoveIntrinsicStubsGen`. It is ON by default if VM is built with C2 or JVMCI compilers except Zero and 32-bit Arm VMs which have no or few intrinsics.
>  - Split `StubGenerator::generate_all()` method into two: `generate_final_stubs()` and `generate_compiler_stubs()`. Moved only C2 (and JVMCI) intrinsic stubs generation to new method.
>  - I renamed methods and stubs buffer sizes according to new code. Now we have 4 separate **named** stubs buffers and corresponding methods: _Initial, Continuation, Compiler, Final_.
>  - I added new UL printing to find new sizes for buffers and adjusted them on `aarch64` and `x86`. On other platforms I used the same as before value for `compiler_stubs` and `final_stubs`:
> 
>> java -Xlog:stubs -XX:+UseCompressedOops -XX:+CheckCompressedOops -XX:+VerifyOops -XX:-VerifyStackAtCalls -version
> [0.006s][info][stubs] StubRoutines (initial stubs)	 [0x00007f94900fcc00, 0x00007f9490101b60] used: 16152, free: 4168
> [0.026s][info][stubs] StubRoutines (continuation stubs)	 [0x00007f9490102580, 0x00007f9490102e90] used: 741, free: 1579
> [0.051s][info][stubs] StubRoutines (final stubs)	 [0x00007f9490155600, 0x00007f949015cc70] used: 26484, free: 3836
> [0.090s][info][stubs] StubRoutines (compiler stubs)	 [0x00007f94904ccc00, 0x00007f94904d9bd0] used: 46988, free: 6212
> java version "21-internal" 2023-09-19 LTS
> 
> -Xlog:stubs=debug will print size information for each stub:
> [0.005s][debug][stubs] ICache::flush_icache_stub [0x00007fb2d3828080, 0x00007fb2d382809d] (29 bytes)
> [0.005s][debug][stubs] VM_Version::get_cpu_info_stub [0x00007fb2d3828380, 0x00007fb2d3828714] (916 bytes)
> [0.005s][debug][stubs] VM_Version::detect_virt_stub [0x00007fb2d3828714, 0x00007fb2d382872e] (26 bytes)
> [0.005s][debug][stubs] StubRoutines::forward exception [0x00007fb2d3828c00, 0x00007fb2d3828c92] (146 bytes)
> 
> 
> Testing: tier1-7, Xcomp, stress on x64 and aarch64.
> 
> I have changes for all platforms. Please test it on platforms you support.

FWIW this looks good to me!

Perhaps there's some improvements that can be made (see inline comments regarding the `count_positives` stub), but it might be prudent not to spend more time than necessary on this too much if anyone will be looking at https://bugs.openjdk.org/browse/JDK-8304422 soon enough.

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 8093:

> 8091: 
> 8092:     // countPositives stub for large arrays.
> 8093:     StubRoutines::aarch64::_count_positives = generate_count_positives(StubRoutines::aarch64::_count_positives_long);

A small detail but I am pretty certain this stub is only used by C2 and could be moved to `generate_compiler_stubs`. But it opens a question if there are more stubs that look like they are shared but are really only used by C2.

For historical reasons this intrinsic was implemented with a macro+stub on aarch64 but x64 et al. When doing so the macro was defined in MacroAssembler and not C2_MacroAssembler, but it is effectively only used from aarch64.ad.

It might be interesting to make C1 (and possibly interpreter) use this stub when available, but if/when that happens moving it back to `generate_final_stubs` is relatively straightforward.

src/hotspot/cpu/aarch64/stubRoutines_aarch64.hpp line 42:

> 40:   _continuation_stubs_code_size =  2000,
> 41:   _compiler_stubs_code_size     = 30000,
> 42:   _final_stubs_code_size        = 20000

The tricky part when updating these is knowing which set of CPU features and VM flags will generate the largest possible stubs, but it looks like you've added ample of free space with these estimates.

src/hotspot/share/runtime/stubRoutines.cpp line 413:

> 411: void compiler_stubs_init(bool in_compiler_thread) {
> 412:   if (in_compiler_thread && MoveIntrinsicStubsGen) {
> 413:     // Temporare revert state of stubs generation because

"Temporarily"

-------------

Marked as reviewed by redestad (Reviewer).

PR: https://git.openjdk.org/jdk/pull/13096

From jcking at openjdk.org  Mon Mar 20 16:29:40 2023
From: jcking at openjdk.org (Justin King)
Date: Mon, 20 Mar 2023 16:29:40 GMT
Subject: RFR: JDK-8304539: Cleanup
 utilities/{count_leading_zeros,count_trailing_zeros,population_count}.hpp
Message-ID: <Ly_ZIg1wqoqnEy0N-YFdQaEpGg7Er8Vtj8phZQhgAw0=.4d9b54db-517e-491e-a376-623139808b7e@github.com>

As the title says, cleanup the mentioned headers. This is similar to `byteswap.hpp` and removes the extraneous `#ifdef` for XLC since it is really just Clang now.

-------------

Commit messages:
 - Merge remote-tracking branch 'upstream/master' into popcount
 - Update copyright
 - Cleanup based on byteswap.hpp
 - Refactor count_leading_zeros, count_trailing_zeros, and population_count

Changes: https://git.openjdk.org/jdk/pull/13103/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13103&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304539
  Stats: 413 lines in 3 files changed: 184 ins; 155 del; 74 mod
  Patch: https://git.openjdk.org/jdk/pull/13103.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/13103/head:pull/13103

PR: https://git.openjdk.org/jdk/pull/13103

From kvn at openjdk.org  Mon Mar 20 17:04:48 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 20 Mar 2023 17:04:48 GMT
Subject: RFR: 8231349: Move intrinsic stubs generation to compiler runtime
 initialization code
In-Reply-To: <IuTeu69iV-nA3uGVQuZzHtc4jax7AnYZDt7TQdj53a0=.7e69132b-3cb8-4b3a-a7b7-ab8962f16ed9@github.com>
References: <dtc9rdiBGUpqQUB9AzWBroeF3ziVODfk0FuPFDgOHqE=.096e99b2-2957-46c7-8c74-ae1d737f220d@github.com>
 <IuTeu69iV-nA3uGVQuZzHtc4jax7AnYZDt7TQdj53a0=.7e69132b-3cb8-4b3a-a7b7-ab8962f16ed9@github.com>
Message-ID: <GEWx82iBRHElBMVvQ7-yT0NMs2slsMa7L7okcOxyW4g=.aa0739a7-10bd-46c0-8eb7-22198ccb1fa1@github.com>

On Mon, 20 Mar 2023 14:42:02 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Based on performance data (see graph in RFE) I propose to implement @cl4es suggestion to move intrinsics stubs generation to C2 (and JVMCI) runtime initialization code.
>> 
>> It has <1% difference from not generated these stubs at all and we will not win on 1 core VMs but it is simpler and safer solution, I think. It also automatically (no need for new code) do not generate these stubs if C2 is not used (-Xint or low TieredStopAt Level.
>> 
>> On demand stubs generation requires synchronization between threads during application run which may introduce some instability and may be other issues. But it could be beneficial for Interpreter and C1 if we want more intrinsics stubs to be used by C1 and Interpreter (they use CRC32 only now).  I filed separate RFE  [8304422](https://bugs.openjdk.org/browse/JDK-8304422).
>> 
>> Changes:
>>  - Added new platform specific diagnostic flag `-XX:+MoveIntrinsicStubsGen`. It is ON by default if VM is built with C2 or JVMCI compilers except Zero and 32-bit Arm VMs which have no or few intrinsics.
>>  - Split `StubGenerator::generate_all()` method into two: `generate_final_stubs()` and `generate_compiler_stubs()`. Moved only C2 (and JVMCI) intrinsic stubs generation to new method.
>>  - I renamed methods and stubs buffer sizes according to new code. Now we have 4 separate **named** stubs buffers and corresponding methods: _Initial, Continuation, Compiler, Final_.
>>  - I added new UL printing to find new sizes for buffers and adjusted them on `aarch64` and `x86`. On other platforms I used the same as before value for `compiler_stubs` and `final_stubs`:
>> 
>>> java -Xlog:stubs -XX:+UseCompressedOops -XX:+CheckCompressedOops -XX:+VerifyOops -XX:-VerifyStackAtCalls -version
>> [0.006s][info][stubs] StubRoutines (initial stubs)	 [0x00007f94900fcc00, 0x00007f9490101b60] used: 16152, free: 4168
>> [0.026s][info][stubs] StubRoutines (continuation stubs)	 [0x00007f9490102580, 0x00007f9490102e90] used: 741, free: 1579
>> [0.051s][info][stubs] StubRoutines (final stubs)	 [0x00007f9490155600, 0x00007f949015cc70] used: 26484, free: 3836
>> [0.090s][info][stubs] StubRoutines (compiler stubs)	 [0x00007f94904ccc00, 0x00007f94904d9bd0] used: 46988, free: 6212
>> java version "21-internal" 2023-09-19 LTS
>> 
>> -Xlog:stubs=debug will print size information for each stub:
>> [0.005s][debug][stubs] ICache::flush_icache_stub [0x00007fb2d3828080, 0x00007fb2d382809d] (29 bytes)
>> [0.005s][debug][stubs] VM_Version::get_cpu_info_stub [0x00007fb2d3828380, 0x00007fb2d3828714] (916 bytes)
>> [0.005s][debug][stubs] VM_Version::detect_virt_stub [0x00007fb2d3828714, 0x00007fb2d382872e] (26 bytes)
>> [0.005s][debug][stubs] StubRoutines::forward exception [0x00007fb2d3828c00, 0x00007fb2d3828c92] (146 bytes)
>> 
>> 
>> Testing: tier1-7, Xcomp, stress on x64 and aarch64.
>> 
>> I have changes for all platforms. Please test it on platforms you support.
>
> src/hotspot/cpu/aarch64/stubRoutines_aarch64.hpp line 42:
> 
>> 40:   _continuation_stubs_code_size =  2000,
>> 41:   _compiler_stubs_code_size     = 30000,
>> 42:   _final_stubs_code_size        = 20000
> 
> The tricky part when updating these is knowing which set of CPU features and VM flags will generate the largest possible stubs, but it looks like you've added ample of free space with these estimates.

Yes, that is why I ran with `-XX:+UseCompressedOops -XX:+CheckCompressedOops -XX:+VerifyOops -XX:-VerifyStackAtCalls` flags which increase generated code size.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13096#discussion_r1142437121

From kvn at openjdk.org  Mon Mar 20 17:17:13 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 20 Mar 2023 17:17:13 GMT
Subject: RFR: 8231349: Move intrinsic stubs generation to compiler runtime
 initialization code [v2]
In-Reply-To: <dtc9rdiBGUpqQUB9AzWBroeF3ziVODfk0FuPFDgOHqE=.096e99b2-2957-46c7-8c74-ae1d737f220d@github.com>
References: <dtc9rdiBGUpqQUB9AzWBroeF3ziVODfk0FuPFDgOHqE=.096e99b2-2957-46c7-8c74-ae1d737f220d@github.com>
Message-ID: <mps4Bze-krj-aWVdtS6CcpRmOf9_gs-lmDI3iH7AvIQ=.8671e010-995c-4d1c-8282-afbb5ae6f2bf@github.com>

> Based on performance data (see graph in RFE) I propose to implement @cl4es suggestion to move intrinsics stubs generation to C2 (and JVMCI) runtime initialization code.
> 
> It has <1% difference from not generated these stubs at all and we will not win on 1 core VMs but it is simpler and safer solution, I think. It also automatically (no need for new code) do not generate these stubs if C2 is not used (-Xint or low TieredStopAt Level.
> 
> On demand stubs generation requires synchronization between threads during application run which may introduce some instability and may be other issues. But it could be beneficial for Interpreter and C1 if we want more intrinsics stubs to be used by C1 and Interpreter (they use CRC32 only now).  I filed separate RFE  [8304422](https://bugs.openjdk.org/browse/JDK-8304422).
> 
> Changes:
>  - Added new platform specific diagnostic flag `-XX:+MoveIntrinsicStubsGen`. It is ON by default if VM is built with C2 or JVMCI compilers except Zero and 32-bit Arm VMs which have no or few intrinsics.
>  - Split `StubGenerator::generate_all()` method into two: `generate_final_stubs()` and `generate_compiler_stubs()`. Moved only C2 (and JVMCI) intrinsic stubs generation to new method.
>  - I renamed methods and stubs buffer sizes according to new code. Now we have 4 separate **named** stubs buffers and corresponding methods: _Initial, Continuation, Compiler, Final_.
>  - I added new UL printing to find new sizes for buffers and adjusted them on `aarch64` and `x86`. On other platforms I used the same as before value for `compiler_stubs` and `final_stubs`:
> 
>> java -Xlog:stubs -XX:+UseCompressedOops -XX:+CheckCompressedOops -XX:+VerifyOops -XX:-VerifyStackAtCalls -version
> [0.006s][info][stubs] StubRoutines (initial stubs)	 [0x00007f94900fcc00, 0x00007f9490101b60] used: 16152, free: 4168
> [0.026s][info][stubs] StubRoutines (continuation stubs)	 [0x00007f9490102580, 0x00007f9490102e90] used: 741, free: 1579
> [0.051s][info][stubs] StubRoutines (final stubs)	 [0x00007f9490155600, 0x00007f949015cc70] used: 26484, free: 3836
> [0.090s][info][stubs] StubRoutines (compiler stubs)	 [0x00007f94904ccc00, 0x00007f94904d9bd0] used: 46988, free: 6212
> java version "21-internal" 2023-09-19 LTS
> 
> -Xlog:stubs=debug will print size information for each stub:
> [0.005s][debug][stubs] ICache::flush_icache_stub [0x00007fb2d3828080, 0x00007fb2d382809d] (29 bytes)
> [0.005s][debug][stubs] VM_Version::get_cpu_info_stub [0x00007fb2d3828380, 0x00007fb2d3828714] (916 bytes)
> [0.005s][debug][stubs] VM_Version::detect_virt_stub [0x00007fb2d3828714, 0x00007fb2d382872e] (26 bytes)
> [0.005s][debug][stubs] StubRoutines::forward exception [0x00007fb2d3828c00, 0x00007fb2d3828c92] (146 bytes)
> 
> 
> Testing: tier1-7, Xcomp, stress on x64 and aarch64.
> 
> I have changes for all platforms. Please test it on platforms you support.

Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:

  Address Claes comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13096/files
  - new: https://git.openjdk.org/jdk/pull/13096/files/ccbc8b56..fe04169d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13096&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13096&range=00-01

  Stats: 7 lines in 2 files changed: 3 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13096.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13096/head:pull/13096

PR: https://git.openjdk.org/jdk/pull/13096

From stuart.monteith at arm.com  Mon Mar 20 17:32:50 2023
From: stuart.monteith at arm.com (Stuart Monteith)
Date: Mon, 20 Mar 2023 17:32:50 +0000
Subject: ASAN and slowdebug
Message-ID: <a1bcc12a-2a93-93a0-3885-48fc5fca7f90@arm.com>

Hello,
   While looking at ASAN to try to reproduce another issue with ASAN, I tried building OpenJDK configured with:
       --enable-asan --with-debug-level=slowdebug

However, there is a compilation problem that persists up to and include GCC 12.2.0:
	https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80959

As slowdebug builds are built with -O0, this results in code to be inserted by the macros LEAVE() and CHECK_NH+CHECK_ 
macros to be not optimised away. This causes the following two warnings/errors:

  * For target hotspot_variant-server_libjvm_objs_memoryService.o:
jdk/src/hotspot/share/services/memoryService.cpp: In static member function 'static Handle 
MemoryService::create_MemoryUsage_obj(MemoryUsage, JavaThread*)':
jdk/src/hotspot/share/services/memoryService.cpp:219:1: error: control reaches end of non-void function 
[-Werror=return-type]

  * For target support_native_java.base_libjli_java.o:
jdk/src/java.base/share/native/libjli/java.c: In function 'JavaMain':
jdk/src/java.base/share/native/libjli/java.c:556:1: error: control reaches end of non-void function [-Werror=return-type]
   556 | }
       | ^


There are a couple of ways of working around this. One is to  change create_MemoryUsage_obj and libjli/java.c to place a 
return statement at the end of the function block, after the macros. The changes are straightforward, but we're 
obviously not guaranteed to not reintroduce the problem elsewhere.

Another is to pass:  "--disable-warnings-as-errors" or more specifically "--with-extra-cflags=-Wno-return-type 
--with-extra-cxxflags=-Wno-return-type" to configure. This would be a manual process, unless the make files were changed 
to handle this, however this does remove the return type checks.


Part of the reason for sending this is to at least document the issue publicly. Are there any opinions on what should to 
be done next?


Stuart


From bkilambi at openjdk.org  Mon Mar 20 17:37:59 2023
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Mon, 20 Mar 2023 17:37:59 GMT
Subject: RFR: 8301012: [vectorapi]: Intrinsify CompressBitsV/ExpandBitsV
 and add the AArch64 SVE backend implementation [v2]
In-Reply-To: <RaPIEa3D1wT6isue-1l_ILYJ6FCWSeNJ-T8QXtoxnUk=.05a804b5-9b2f-4486-aad4-53f00a3a6ab3@github.com>
References: <RaPIEa3D1wT6isue-1l_ILYJ6FCWSeNJ-T8QXtoxnUk=.05a804b5-9b2f-4486-aad4-53f00a3a6ab3@github.com>
Message-ID: <WepLX4oA_2sxHK2IzxZPuCSw126ydVMIkLrQFlwBxhI=.1c20c2fe-62c7-4576-a7f5-bdbfa1055214@github.com>

> This patch adds mid-end compiler vector IR nodes for the scalar CompressBits and ExpandBits nodes - CompressBitsV and ExpandBitsV and also adds aarch64 backend support for these nodes using SVE2 instructions (included in the svebitperm feature). As there are direct instructions in SVE2 that map to these operations, a huge speed up in performance can be observed and it might significantly benefit all those workloads that extensively run these operations on an SVE2(with svebitperm feature) supporting machine.
> 
> All the JTREG tests under "test/jdk/jdk/incubator/vector" pass successfully with this patch on an SVE2 machine.
> The JMH tests - COMPRESS_BITS and EXPAND_BITS from [1] and [2] were run on a 128-bit vector length, SVE2 and svebitperm supporting aarch64 machine. Following are the gains observed with this patch -
> 
> 
> Benchmark                       (length)  Mode    Cnt   Gain
> IntMaxVector.COMPRESS_BITS      1024      thrpt   15    81.68x
> IntMaxVector.EXPAND_BITS        1024      thrpt   15    85.65x
> LongMaxVector.COMPRESS_BITS     1024      thrpt   15    70.78x
> LongMaxVector.EXPAND_BITS       1024      thrpt   15    76.31x
> 
> 
> The "Gain" column is the ratio between the throughput of benchmark runs with this patch and that of benchmark runs without this patch. This patch does not change the performance of these operations for all other machines that do not support these instructions or when run on a different architecture.
> With this patch, vectorization of CompressBits and ExpandBits operations happens only through vectorapi for aarch64. Autovectorization does not take place as the current JDK source does not contain aarch64 backend implementation for scalar CompressBits and ExpandBits. However, this PR - https://github.com/openjdk/jdk/pull/10537 adds aarch64 backend implementaton for CompressBits and ExpandBits and may lead to autovectorization of these nodes as well eventually but this PR is a standalone one and not dependent on the scalar implementation.
> 
> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/IntMaxVector.java 
> [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/LongMaxVector.java

Bhavana Kilambi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge master and fix conflicts
 - 8301012: [vectorapi]: Intrinsify CompressBitsV/ExpandBitsV and add the AArch64 SVE backend implementation
   
   This patch adds mid-end compiler vector IR nodes for the scalar
   CompressBits and ExpandBits nodes - CompressBitsV and ExpandBitsV and
   also adds aarch64 backend support for these nodes using SVE2
   instructions (included in the svebitperm feature).
   As there are direct instructions in SVE2 that map to these operations,
   a huge speed up in performance can be observed and it might significantly
   benefit all those workloads that extensively run these operations on an
   SVE2(with svebitperm feature) supporting machine.
   
   All the JTREG tests under "test/jdk/jdk/incubator/vector" pass
   successfully with this patch on an SVE2 machine.
   The JMH tests - COMPRESS_BITS and EXPAND_BITS from [1] and [2]
   were run on a 128-bit vector length, SVE2 and svebitperm supporting
   aarch64 machine. Following are the gains observed with this patch -
   
   Benchmark                       (length)  Mode    Cnt   Gain
   IntMaxVector.COMPRESS_BITS      1024      thrpt   15    81.68x
   IntMaxVector.EXPAND_BITS        1024      thrpt   15    85.65x
   LongMaxVector.COMPRESS_BITS     1024      thrpt   15    70.78x
   LongMaxVector.EXPAND_BITS       1024      thrpt   15    76.31x
   
   The "Gain" column is the ratio between the throughput of benchmark runs
   with this patch and that of benchmark runs without this patch. This patch
   does not change the performance of these operations for all other
   machines that do not support these instructions or when run on a
   different architecture.
   With this patch, vectorization of CompressBits and ExpandBits operations
   happens only through vectorapi for aarch64. Autovectorization does not
   take place as the current JDK source does not contain aarch64 backend
   implementation for scalar CompressBits and ExpandBits. However, this PR -
   https://github.com/openjdk/jdk/pull/10537 adds aarch64 backend
   implementaton for CompressBits and ExpandBits and may lead to
   autovectorization of these nodes as well eventually but this PR is a
   standalone one and not dependent on the scalar implementation.
   
   [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/IntMaxVector.java
   [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/LongMaxVector.java

-------------

Changes: https://git.openjdk.org/jdk/pull/12446/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12446&range=01
  Stats: 259 lines in 9 files changed: 254 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12446.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12446/head:pull/12446

PR: https://git.openjdk.org/jdk/pull/12446

From jcking at google.com  Mon Mar 20 17:45:40 2023
From: jcking at google.com (Justin King)
Date: Mon, 20 Mar 2023 10:45:40 -0700
Subject: ASAN and slowdebug
In-Reply-To: <a1bcc12a-2a93-93a0-3885-48fc5fca7f90@arm.com>
References: <a1bcc12a-2a93-93a0-3885-48fc5fca7f90@arm.com>
Message-ID: <CAEdz=WVEQ9=2g5fV2Rw8FJ2c1=koA7+84+p8d+yr7wE8VRqgbg@mail.gmail.com>

Ew. So for `MemoryService::create_MemoryUsage_obj` it's effectively adding
stuff after the return statement, causing the compiler to complain. I think
for `MemoryService::create_MemoryUsage_obj` that last CHECK should probably
be changed to THREAD since it's not useful and the code added after the
return is unreachable. And LEAVE should probably be changed to not have the
return statement wrapped in an arbitrary if statement with JNI_TRUE as the
expression, unless there is a reason for that.

On Mon, Mar 20, 2023 at 10:34?AM Stuart Monteith <stuart.monteith at arm.com>
wrote:

> Hello,
>    While looking at ASAN to try to reproduce another issue with ASAN, I
> tried building OpenJDK configured with:
>        --enable-asan --with-debug-level=slowdebug
>
> However, there is a compilation problem that persists up to and include
> GCC 12.2.0:
>         https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80959
>
> As slowdebug builds are built with -O0, this results in code to be
> inserted by the macros LEAVE() and CHECK_NH+CHECK_
> macros to be not optimised away. This causes the following two
> warnings/errors:
>
>   * For target hotspot_variant-server_libjvm_objs_memoryService.o:
> jdk/src/hotspot/share/services/memoryService.cpp: In static member
> function 'static Handle
> MemoryService::create_MemoryUsage_obj(MemoryUsage, JavaThread*)':
> jdk/src/hotspot/share/services/memoryService.cpp:219:1: error: control
> reaches end of non-void function
> [-Werror=return-type]
>
>   * For target support_native_java.base_libjli_java.o:
> jdk/src/java.base/share/native/libjli/java.c: In function 'JavaMain':
> jdk/src/java.base/share/native/libjli/java.c:556:1: error: control reaches
> end of non-void function [-Werror=return-type]
>    556 | }
>        | ^
>
>
> There are a couple of ways of working around this. One is to  change
> create_MemoryUsage_obj and libjli/java.c to place a
> return statement at the end of the function block, after the macros. The
> changes are straightforward, but we're
> obviously not guaranteed to not reintroduce the problem elsewhere.
>
> Another is to pass:  "--disable-warnings-as-errors" or more specifically
> "--with-extra-cflags=-Wno-return-type
> --with-extra-cxxflags=-Wno-return-type" to configure. This would be a
> manual process, unless the make files were changed
> to handle this, however this does remove the return type checks.
>
>
> Part of the reason for sending this is to at least document the issue
> publicly. Are there any opinions on what should to
> be done next?
>
>
> Stuart
>
>

-- 

[image: Google Logo]
Justin King
Software Engineer
jcking at google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20230320/dea90f2c/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3999 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20230320/dea90f2c/smime-0001.p7s>

From rrich at openjdk.org  Mon Mar 20 17:47:49 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 20 Mar 2023 17:47:49 GMT
Subject: RFR: 8296440: Remove Method* handling from
 cleanup_inline_caches_impl [v2]
In-Reply-To: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
References: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
Message-ID: <BQbYsHfh5ZsQ_E1uIUnc9MLg3EgQ_BvW8RZfjMvgaLU=.556e1591-02d1-4073-8924-778fe1866bad@github.com>

> This PR replaces cleaning of static stubs in CompiledMethod::cleanup_inline_caches_impl() with a guarantee that it is actually not needed because the holder of the embedded target Method* is alive if the caller nmethod is not unloading.
> 
> The holder of the target Method* has to be alive because it is reachable from the caller nmethod's oop pool. This is checked by `check_path_to_callee()` when a statically bound call gets resolved.
> 
> C2i entry barriers can be removed for the same reason.
> 
> Testing:
> 
> Many rounds in our CI testing which includes most JCK and JTREG tests, Renaissance benchmark and SAP specific tests with fastdebug and release builds on the standard platforms plus PPC64.
> 
> I've also done tier1 and tier2 tests with -XX:-Inline and tier1 tests with ZGC.
> 
> I've started hotspot and jdk tier1 tests with -Xcomp. They were not finished when I stopped them after 24h.

Richard Reingruber 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:

 - Adding TestStaticallyBoundTargetIsReachable.java
 - Path to target exists also if the receiver is a constant of the caller
 - Use nmethod::oops_do() to search for to_holder in from_nm
 - Merge branch 'master'
 - Remove MacroAssembler::resolve_weak_handle()
 - Remove keep_alive_offset() and holder_offset() from CLD
 - Remove MacroAssembler::load_method_holder_cld()
 - Remove c2i entry barrier
 - Check dependency for statically bound call

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12802/files
  - new: https://git.openjdk.org/jdk/pull/12802/files/8f27bd37..876e55dc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12802&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12802&range=00-01

  Stats: 166452 lines in 2166 files changed: 119994 ins; 27292 del; 19166 mod
  Patch: https://git.openjdk.org/jdk/pull/12802.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12802/head:pull/12802

PR: https://git.openjdk.org/jdk/pull/12802

From duke at openjdk.org  Mon Mar 20 18:12:45 2023
From: duke at openjdk.org (ExE Boss)
Date: Mon, 20 Mar 2023 18:12:45 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview)
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <aX3XPMUafkH6uFyRGKikJIbDHFHwAsGxIk0c8q8zHTw=.73a977b6-373b-48a6-982d-1d6ae5e303b3@github.com>

On Fri, 17 Mar 2023 15:42:56 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

src/java.base/share/classes/java/lang/foreign/AddressLayout.java line 59:

> 57:  */
> 58: @PreviewFeature(feature = PreviewFeature.Feature.FOREIGN)
> 59: sealed public interface AddressLayout extends ValueLayout permits ValueLayouts.OfAddressImpl {

This should?match other sealed?interfaces:
Suggestion:

public sealed interface AddressLayout extends ValueLayout permits ValueLayouts.OfAddressImpl {

src/java.base/share/classes/java/lang/foreign/Linker.java line 578:

> 576:          * Execution state is captured by a downcall method handle on invocation, by writing it
> 577:          * to a native segment provided by the user to the downcall method handle.
> 578:          * For this purpose, a downcall method handle linked with the this

Suggestion:

         * For this purpose, a downcall method handle linked with this

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1140677384
PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1140679387

From pminborg at openjdk.org  Mon Mar 20 18:12:39 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 20 Mar 2023 18:12:39 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API (Third
 Preview)
Message-ID: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>

API changes for the FFM API (third preview)

Specdiff:
https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html

Javadoc:
https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

-------------

Commit messages:
 - Update after first round of comments
 - Remove extra line
 - Remove Panama-specific content
 - Generate delta

Changes: https://git.openjdk.org/jdk/pull/13079/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304265
  Stats: 13601 lines in 269 files changed: 5644 ins; 5999 del; 1958 mod
  Patch: https://git.openjdk.org/jdk/pull/13079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13079/head:pull/13079

PR: https://git.openjdk.org/jdk/pull/13079

From mcimadamore at openjdk.org  Mon Mar 20 18:12:41 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 20 Mar 2023 18:12:41 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview)
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <fVcrQYA7PJgeLbO_obZu4dnNiExgkWnNEcV-sVBP7I8=.276d4112-d943-4952-8ae0-6cee419cec3f@github.com>

On Fri, 17 Mar 2023 15:42:56 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

Here are the main API changes introduced in this round:

* `SegmentScope` has been simplified into a pure lifetime abstraction and moved into a nested class `MemorySegment.Scope`. All segments have a scope (e.g. the segment lifetime), which is usually the scope of some `Arena`. All the factory methods in `SegmentScope` to create non-closeable lifetimes have been moved to `Arena` (e.g. `Arena.ofAuto` and `Arena.global`). This leads to a simplified API, which still allows to build custom arenas via simple delegation, but, at the same time, allows clients to use arenas with minimal indirections (e.g. `arena.scope()` is no longer needed in many places). Some factory names in `Arena` were also updated (e.g. from `openConfined` to `ofConfined`).
* `ValueLayout::OfAddress` has been moved to a toplevel class `AddressLayout`. Also, the method to obtain an address layout of unbounded size (`OfAddress::asUnbounded`) has been changed, so that it now takes the layout of the target region of memory pointed to by the address (`AddressLayout::withTargetLayout`).
* A new *layout path* is provided to dereference an address layout. This allows memory segment var handle to deal with complex dereference expressions like `*(a[10].x).y`.
* A new linker implementation, namely the *fallback linker* has been added. This linker is based on `libffi` and provides a very easy way to add support for `Linker` API, even in platforms that have limited functionalities (such as [zero](https://openjdk.org/projects/zero/)).
* The `VaList` interface has been dropped. Unfortunately, the behavior of `va_list` is hopelessly platform specific, and we could also never make full use of it in the `jextract` tool, given that parsing support `va_list` is very limited in `libclang`.
* The API for unsafely attaching spatial/temporal bounds to an unsafe memory segment has been improved and streamlined. The `MemorySegment::ofAddress` method is now a single, unrestricted method which turns a long address into a native memory segment whose base address is the provided address. The returned segment has a scope that is always alive, and has zero-length. To resize, or add new temporal bounds to an existing segments, clients can use the new `MemorySegment::reinterpret` methods. The logic for attaching a cleanup action to a memory segment has also been updated: now the cleanup action will take as input a shallow copy of the memory segment, in a scope that is always alive, so that clients can pass that copy to other functions in order to perform custom cleanup.
* We have made some changes and simplfications to the way in which runtime values such as `errno` are preserved, The `CapturedCallState` interface has been removed. Instead, there is a way to obtain a group layout of all the values that can be saved, given the platform in which the linker runs. Clients can query the layout, e.g. obtaining names for the values to be saved, and then create a linker option which lists all the name of the values to be saved.
* We have added support for *trivial* (or *leaf*) calls - that is native calls whose execution completes very quickly. This option might be useful when calling functions whose total execution time is comparable to that of the overhead of the change of the thread state from Java to native (in JNI, such calls are handled using *critical JNI*).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13079#issuecomment-1476648707

From jcking at openjdk.org  Mon Mar 20 18:17:12 2023
From: jcking at openjdk.org (Justin King)
Date: Mon, 20 Mar 2023 18:17:12 GMT
Subject: RFR: JDK-8304539: Cleanup
 utilities/{count_leading_zeros, count_trailing_zeros,
 population_count}.hpp [v2]
In-Reply-To: <Ly_ZIg1wqoqnEy0N-YFdQaEpGg7Er8Vtj8phZQhgAw0=.4d9b54db-517e-491e-a376-623139808b7e@github.com>
References: <Ly_ZIg1wqoqnEy0N-YFdQaEpGg7Er8Vtj8phZQhgAw0=.4d9b54db-517e-491e-a376-623139808b7e@github.com>
Message-ID: <kBHu4u0cm0jJnnIS0RCqCr-63pIs4Ue1dF-jtpKRXKs=.3e84bdbd-2ba9-4608-ac1d-7c4846abd506@github.com>

> As the title says, cleanup the mentioned headers. This is similar to `byteswap.hpp` and removes the extraneous `#ifdef` for XLC since it is really just Clang now.

Justin King has updated the pull request incrementally with one additional commit since the last revision:

  Fix ambiguous call
  
  Signed-off-by: Justin King <jcking at google.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13103/files
  - new: https://git.openjdk.org/jdk/pull/13103/files/52859de3..729b0c7a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13103&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13103&range=00-01

  Stats: 26 lines in 3 files changed: 12 ins; 6 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/13103.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13103/head:pull/13103

PR: https://git.openjdk.org/jdk/pull/13103

From rrich at openjdk.org  Mon Mar 20 18:20:03 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 20 Mar 2023 18:20:03 GMT
Subject: RFR: 8296440: Remove Method* handling from
 cleanup_inline_caches_impl
In-Reply-To: <8C06DfuEkBnOaaP1WFv7Y6TRftP9XMitffS3UbOaf8c=.abb8c6e3-7a3b-4412-89b3-8819bd93900e@github.com>
References: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
 <8C06DfuEkBnOaaP1WFv7Y6TRftP9XMitffS3UbOaf8c=.abb8c6e3-7a3b-4412-89b3-8819bd93900e@github.com>
Message-ID: <GKeBT13ydypaBDfYQiXRQ-_DczlazcXAzY7p9oE6Qys=.bfb957ac-1e4f-42a0-a963-cb6f2d2b8e16@github.com>

On Thu, 16 Mar 2023 00:17:27 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> I hit guarantee in tier7 running our closed tests with JRuby and `-Xcomp -ea -esa -XX:CompileThreshold=100` flags:
> 
> ```
> #  Internal Error (/workspace/open/src/hotspot/share/runtime/sharedRuntime.cpp:1411), pid=1150904, tid=1150907
> #  guarantee(false) failed: Missing dependency resolving optimized virtual (invokeinterface) call to  jnr.enxio.channels.Native$LibC$jnr$ffi$2::read
> ```
> 
> Unfortunately I can't share tests.

Thanks again for the testing.

The guarantee fails for the read call at https://github.com/jnr/jnr-enxio/blob/4e21f3a341c2cb7e8007b7bebfb964182d36318d/src/main/java/jnr/enxio/channels/Native.java#L120. It is an invokeinterface with a [constant receiver](https://github.com/jnr/jnr-enxio/blob/4e21f3a341c2cb7e8007b7bebfb964182d36318d/src/main/java/jnr/enxio/channels/Native.java#L67).

I've implemented and added a test. The guarantee fails when CHA based optimization is not possible. Then no dependencies are emitted but the call is still optimized based on the constness of the receiver. Btw wouldn't it be better to skip the CHA attempt in order to avoid emitting dependencies? It might be even possible that the caller gets deoptimized because of them.

I've adapted the verification code. If the receiver is found among the constants then we know a permanent path to the target exists even if the receiver is not constant as the target does not depend on the receiver.

My reproducer `./bin/jruby -J-Xcomp -J-ea -J-esa -J-XX:CompileThreshold=100 -S rake spec:ruby:fast` does not hit the guarantee with the changes anymore.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12802#issuecomment-1476722228

From jcking at openjdk.org  Mon Mar 20 18:26:00 2023
From: jcking at openjdk.org (Justin King)
Date: Mon, 20 Mar 2023 18:26:00 GMT
Subject: RFR: JDK-8304539: Cleanup
 utilities/{count_leading_zeros, count_trailing_zeros,
 population_count}.hpp [v3]
In-Reply-To: <Ly_ZIg1wqoqnEy0N-YFdQaEpGg7Er8Vtj8phZQhgAw0=.4d9b54db-517e-491e-a376-623139808b7e@github.com>
References: <Ly_ZIg1wqoqnEy0N-YFdQaEpGg7Er8Vtj8phZQhgAw0=.4d9b54db-517e-491e-a376-623139808b7e@github.com>
Message-ID: <DScSiwpYmUMx5GoNoSnZrHizmUlxp0lbA4txCALHO2E=.7cd55fd3-e27b-4bb0-85c7-b4dfa91fe433@github.com>

> As the title says, cleanup the mentioned headers. This is similar to `byteswap.hpp` and removes the extraneous `#ifdef` for XLC since it is really just Clang now.

Justin King has updated the pull request incrementally with one additional commit since the last revision:

  Remove unnecessary templating from count_trailing_zeros
  
  Signed-off-by: Justin King <jcking at google.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13103/files
  - new: https://git.openjdk.org/jdk/pull/13103/files/729b0c7a..e494027f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13103&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13103&range=01-02

  Stats: 11 lines in 1 file changed: 0 ins; 3 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/13103.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13103/head:pull/13103

PR: https://git.openjdk.org/jdk/pull/13103

From jcking at openjdk.org  Mon Mar 20 18:33:42 2023
From: jcking at openjdk.org (Justin King)
Date: Mon, 20 Mar 2023 18:33:42 GMT
Subject: RFR: JDK-8304539: Cleanup
 utilities/{count_leading_zeros, count_trailing_zeros,
 population_count}.hpp [v4]
In-Reply-To: <Ly_ZIg1wqoqnEy0N-YFdQaEpGg7Er8Vtj8phZQhgAw0=.4d9b54db-517e-491e-a376-623139808b7e@github.com>
References: <Ly_ZIg1wqoqnEy0N-YFdQaEpGg7Er8Vtj8phZQhgAw0=.4d9b54db-517e-491e-a376-623139808b7e@github.com>
Message-ID: <G3xqmOTsc04rGs_8ZN3b0I3qDPyc9ZxUMrYDZ1vZFU8=.3aceef29-684b-4708-bd65-f12ebb95bacf@github.com>

> As the title says, cleanup the mentioned headers. This is similar to `byteswap.hpp` and removes the extraneous `#ifdef` for XLC since it is really just Clang now.

Justin King has updated the pull request incrementally with one additional commit since the last revision:

  Redo non-templated approach
  
  Signed-off-by: Justin King <jcking at google.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13103/files
  - new: https://git.openjdk.org/jdk/pull/13103/files/e494027f..c1f4bd9a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13103&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13103&range=02-03

  Stats: 46 lines in 1 file changed: 6 ins; 6 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/13103.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13103/head:pull/13103

PR: https://git.openjdk.org/jdk/pull/13103

From coleenp at openjdk.org  Mon Mar 20 19:04:18 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 20 Mar 2023 19:04:18 GMT
Subject: RFR: 8296440: Remove Method* handling from
 cleanup_inline_caches_impl [v2]
In-Reply-To: <BQbYsHfh5ZsQ_E1uIUnc9MLg3EgQ_BvW8RZfjMvgaLU=.556e1591-02d1-4073-8924-778fe1866bad@github.com>
References: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
 <BQbYsHfh5ZsQ_E1uIUnc9MLg3EgQ_BvW8RZfjMvgaLU=.556e1591-02d1-4073-8924-778fe1866bad@github.com>
Message-ID: <Sc3IEKtrtDeddp3JO32ToY-vjVLzQKRptszRDyP1EHI=.68fd28b3-a714-46d4-bf78-c39ffb8aa073@github.com>

On Mon, 20 Mar 2023 17:47:49 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> This PR replaces cleaning of static stubs in CompiledMethod::cleanup_inline_caches_impl() with a guarantee that it is actually not needed because the holder of the embedded target Method* is alive if the caller nmethod is not unloading.
>> 
>> The holder of the target Method* has to be alive because it is reachable from the caller nmethod's oop pool. This is checked by `check_path_to_callee()` when a statically bound call gets resolved.
>> 
>> C2i entry barriers can be removed for the same reason.
>> 
>> Testing:
>> 
>> Many rounds in our CI testing which includes most JCK and JTREG tests, Renaissance benchmark and SAP specific tests with fastdebug and release builds on the standard platforms plus PPC64.
>> 
>> I've also done tier1 and tier2 tests with -XX:-Inline and tier1 tests with ZGC.
>> 
>> I've started hotspot and jdk tier1 tests with -Xcomp. They were not finished when I stopped them after 24h.
>
> Richard Reingruber 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:
> 
>  - Adding TestStaticallyBoundTargetIsReachable.java
>  - Path to target exists also if the receiver is a constant of the caller
>  - Use nmethod::oops_do() to search for to_holder in from_nm
>  - Merge branch 'master'
>  - Remove MacroAssembler::resolve_weak_handle()
>  - Remove keep_alive_offset() and holder_offset() from CLD
>  - Remove MacroAssembler::load_method_holder_cld()
>  - Remove c2i entry barrier
>  - Check dependency for statically bound call

I don't really know if this is right but some comments anyway.

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 4308:

> 4306: void MacroAssembler::load_method_holder_cld(Register rresult, Register rmethod) {
> 4307:   load_method_holder(rresult, rmethod);
> 4308:   ldr(rresult, Address(rresult, InstanceKlass::class_loader_data_offset()));

Can you remove InstanceKlass::klass_loader_data_offset() also?

src/hotspot/share/classfile/classLoaderData.cpp line 791:

> 789: 
> 790: bool ClassLoaderData::handles_contain(oop obj) {
> 791:   return _handles.contains(obj);

This might need to be protected by a metaspace_lock.

src/hotspot/share/runtime/sharedRuntime.cpp line 1354:

> 1352: }
> 1353: 
> 1354: class Search2OopsClosure : public OopClosure {

Should this all be under #ifdef ASSERT?

src/hotspot/share/runtime/sharedRuntime.cpp line 1418:

> 1416:         return; // `to` is reachable by iterating parents of `from`
> 1417:       }
> 1418:     }

I'd be happier if this part was a function in ClassLoaderData or refactored from record_dependency (along with the constains function).  Since it's similar code.

-------------

PR Review: https://git.openjdk.org/jdk/pull/12802#pullrequestreview-1349193798
PR Review Comment: https://git.openjdk.org/jdk/pull/12802#discussion_r1142542383
PR Review Comment: https://git.openjdk.org/jdk/pull/12802#discussion_r1142553804
PR Review Comment: https://git.openjdk.org/jdk/pull/12802#discussion_r1142560411
PR Review Comment: https://git.openjdk.org/jdk/pull/12802#discussion_r1142563560

From jcking at openjdk.org  Mon Mar 20 19:05:59 2023
From: jcking at openjdk.org (Justin King)
Date: Mon, 20 Mar 2023 19:05:59 GMT
Subject: RFR: JDK-8304539: Cleanup
 utilities/{count_leading_zeros, count_trailing_zeros,
 population_count}.hpp [v5]
In-Reply-To: <Ly_ZIg1wqoqnEy0N-YFdQaEpGg7Er8Vtj8phZQhgAw0=.4d9b54db-517e-491e-a376-623139808b7e@github.com>
References: <Ly_ZIg1wqoqnEy0N-YFdQaEpGg7Er8Vtj8phZQhgAw0=.4d9b54db-517e-491e-a376-623139808b7e@github.com>
Message-ID: <fk2VHVl21J63WjrZnvy2weJeNaLd3rSK9BA_6juAdqk=.2f33fc84-fa0e-46d8-b718-c88f01c43b7f@github.com>

> As the title says, cleanup the mentioned headers. This is similar to `byteswap.hpp` and removes the extraneous `#ifdef` for XLC since it is really just Clang now.

Justin King has updated the pull request incrementally with one additional commit since the last revision:

  Remove intrinsic specifier for CountOneBits
  
  Signed-off-by: Justin King <jcking at google.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13103/files
  - new: https://git.openjdk.org/jdk/pull/13103/files/c1f4bd9a..024a6ef7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13103&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13103&range=03-04

  Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13103.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13103/head:pull/13103

PR: https://git.openjdk.org/jdk/pull/13103

From jcking at openjdk.org  Mon Mar 20 19:15:46 2023
From: jcking at openjdk.org (Justin King)
Date: Mon, 20 Mar 2023 19:15:46 GMT
Subject: RFR: JDK-8304539: Cleanup
 utilities/{count_leading_zeros, count_trailing_zeros,
 population_count}.hpp [v6]
In-Reply-To: <Ly_ZIg1wqoqnEy0N-YFdQaEpGg7Er8Vtj8phZQhgAw0=.4d9b54db-517e-491e-a376-623139808b7e@github.com>
References: <Ly_ZIg1wqoqnEy0N-YFdQaEpGg7Er8Vtj8phZQhgAw0=.4d9b54db-517e-491e-a376-623139808b7e@github.com>
Message-ID: <iFL2RYwG4hTEf24qfRs2VCBQvROobE5LyEpCkh3Zl6A=.deced8a7-10f0-4b38-a86d-c1e5a91f9af4@github.com>

> As the title says, cleanup the mentioned headers. This is similar to `byteswap.hpp` and removes the extraneous `#ifdef` for XLC since it is really just Clang now.

Justin King has updated the pull request incrementally with one additional commit since the last revision:

  Go back to templating for count_trailing_zeros for consistency
  
  Signed-off-by: Justin King <jcking at google.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13103/files
  - new: https://git.openjdk.org/jdk/pull/13103/files/024a6ef7..1ee4120a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13103&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13103&range=04-05

  Stats: 71 lines in 1 file changed: 29 ins; 15 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/13103.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13103/head:pull/13103

PR: https://git.openjdk.org/jdk/pull/13103

From cslucas at openjdk.org  Mon Mar 20 19:23:34 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Mon, 20 Mar 2023 19:23:34 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v4]
In-Reply-To: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
Message-ID: <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com>

> Can I please get reviews for this PR? 
> 
> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested.
> 
> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N:
> 
> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png)
> 
> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1:
> 
> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png)
> 
> This PR adds support scalar replacing allocations participating in merges that are used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently.
> 
> The approach I used for _rematerialization_ is pretty straightforward. It consists basically in: 1) Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a new Class to support rematerialization of SR objects part of merges; 3) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 4) Patch C2 to generate unique types for SR objects participating in some allocation merges.
> 
> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straight forward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless.
> 
> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also tested with several applications and didn't see any failure. I also run tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures.

Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:

  Add support for SR'ing some inputs of merges used for field loads

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12897/files
  - new: https://git.openjdk.org/jdk/pull/12897/files/3b492d2e..a158ae66

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=02-03

  Stats: 481 lines in 9 files changed: 292 ins; 117 del; 72 mod
  Patch: https://git.openjdk.org/jdk/pull/12897.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12897/head:pull/12897

PR: https://git.openjdk.org/jdk/pull/12897

From kbarrett at openjdk.org  Mon Mar 20 19:28:34 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 20 Mar 2023 19:28:34 GMT
Subject: RFR: 8304016: Add BitMap find_last suite of functions [v3]
In-Reply-To: <uacSVrnq4wrWciqgVSQSnNp05EvZzBTfCrM08ih-KUU=.dd763e87-c71a-4e08-aa96-848420915ead@github.com>
References: <uacSVrnq4wrWciqgVSQSnNp05EvZzBTfCrM08ih-KUU=.dd763e87-c71a-4e08-aa96-848420915ead@github.com>
Message-ID: <gaW_yuGDuz6ihvwCY8whqKhWF6GSZcxuPxJAsdJHEds=.50406119-2587-413a-a610-51b4d75b9f87@github.com>

> Please review this change that adds functions to BitMap for finding the last
> set/clear bit in a range.
> 
> Testing:
> mach5 tier1, including new gtesting for the new functions.

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 four additional commits since the last revision:

 - Merge branch 'master' into find-last
 - shrink find_first_bit_impl
 - improve find_last_bit_impl
 - find_last_set/clear_bit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12988/files
  - new: https://git.openjdk.org/jdk/pull/12988/files/b3d2aed1..fcfebb2a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12988&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12988&range=01-02

  Stats: 78648 lines in 898 files changed: 48978 ins; 20413 del; 9257 mod
  Patch: https://git.openjdk.org/jdk/pull/12988.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12988/head:pull/12988

PR: https://git.openjdk.org/jdk/pull/12988

From kbarrett at openjdk.org  Mon Mar 20 19:28:36 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 20 Mar 2023 19:28:36 GMT
Subject: RFR: 8304016: Add BitMap find_last suite of functions [v2]
In-Reply-To: <f8yHtz70aUlAj8LIugSKOL9cQuh0XzcEzHhh92ZJKZU=.ee47acaf-ec0d-4d7b-82be-08b55a1c2330@github.com>
References: <uacSVrnq4wrWciqgVSQSnNp05EvZzBTfCrM08ih-KUU=.dd763e87-c71a-4e08-aa96-848420915ead@github.com>
 <WQxGV4Lj1USZici4EhxodhqnAXp2geiZRjADg-GNp2g=.f20ed644-5ce1-4755-9112-b83ac3f909e7@github.com>
 <f8yHtz70aUlAj8LIugSKOL9cQuh0XzcEzHhh92ZJKZU=.ee47acaf-ec0d-4d7b-82be-08b55a1c2330@github.com>
Message-ID: <hReladHYoq4Sa13Jy9TZo8ca1NuUaozQZmoQPhmklX4=.86d3293f-c8a1-4190-ab09-8e7decc04278@github.com>

On Mon, 20 Mar 2023 09:11:57 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - shrink find_first_bit_impl
>>  - improve find_last_bit_impl
>
> Thanks for creating this PR. As we have discussed offline, this is not my preferred code style for these functions, but I'm happy to see this functionality being upstreamed, so consider this reviewed.

Thanks for reviews @stefank and @xmas92

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12988#issuecomment-1476810717

From kbarrett at openjdk.org  Mon Mar 20 19:28:37 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 20 Mar 2023 19:28:37 GMT
Subject: Integrated: 8304016: Add BitMap find_last suite of functions
In-Reply-To: <uacSVrnq4wrWciqgVSQSnNp05EvZzBTfCrM08ih-KUU=.dd763e87-c71a-4e08-aa96-848420915ead@github.com>
References: <uacSVrnq4wrWciqgVSQSnNp05EvZzBTfCrM08ih-KUU=.dd763e87-c71a-4e08-aa96-848420915ead@github.com>
Message-ID: <L_ccK3IpPaLb_-p0oV29LaLFIMwQb06YiZAZQiAPjVQ=.e26375f6-c128-4432-b066-9032fc4beb81@github.com>

On Sat, 11 Mar 2023 16:46:44 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that adds functions to BitMap for finding the last
> set/clear bit in a range.
> 
> Testing:
> mach5 tier1, including new gtesting for the new functions.

This pull request has now been integrated.

Changeset: 2d0d057d
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2d0d057d6691d4abe4ca1ef44b29f03043323b67
Stats:     232 lines in 3 files changed: 168 ins; 28 del; 36 mod

8304016: Add BitMap find_last suite of functions

Reviewed-by: stefank, aboldtch

-------------

PR: https://git.openjdk.org/jdk/pull/12988

From erikj at openjdk.org  Mon Mar 20 19:32:31 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 20 Mar 2023 19:32:31 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview)
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <t3FglkH9K_-puYnWMuRn84ohm2p3ewd-y31I9sSDHOI=.63c8f24b-7dc4-42f4-bea4-8ab078c99828@github.com>

On Fri, 17 Mar 2023 15:42:56 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

Build changes look ok.

-------------

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13079#pullrequestreview-1349265135

From jcking at openjdk.org  Mon Mar 20 19:40:23 2023
From: jcking at openjdk.org (Justin King)
Date: Mon, 20 Mar 2023 19:40:23 GMT
Subject: RFR: JDK-8304539: Cleanup
 utilities/{count_leading_zeros, count_trailing_zeros,
 population_count}.hpp [v7]
In-Reply-To: <Ly_ZIg1wqoqnEy0N-YFdQaEpGg7Er8Vtj8phZQhgAw0=.4d9b54db-517e-491e-a376-623139808b7e@github.com>
References: <Ly_ZIg1wqoqnEy0N-YFdQaEpGg7Er8Vtj8phZQhgAw0=.4d9b54db-517e-491e-a376-623139808b7e@github.com>
Message-ID: <UlTlhPyjZ3pvnI8gr_f4EaOvgoI3OYpYEpo2qi-UlvE=.b34e8d9f-5cb2-473d-8ac1-80e1cc299027@github.com>

> As the title says, cleanup the mentioned headers. This is similar to `byteswap.hpp` and removes the extraneous `#ifdef` for XLC since it is really just Clang now.

Justin King has updated the pull request incrementally with one additional commit since the last revision:

  Add missing #endif
  
  Signed-off-by: Justin King <jcking at google.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13103/files
  - new: https://git.openjdk.org/jdk/pull/13103/files/1ee4120a..8b36d016

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13103&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13103&range=05-06

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13103.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13103/head:pull/13103

PR: https://git.openjdk.org/jdk/pull/13103

From sspitsyn at openjdk.org  Mon Mar 20 19:58:51 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 20 Mar 2023 19:58:51 GMT
Subject: Integrated: 8304303: implement VirtualThread class notifyJvmti methods
 as C2 intrinsics
In-Reply-To: <-Pt3zLSu1Y2GYeM8XEivglUyDVXlAqMIA42-_zEnHlo=.7dd40f19-160a-4f11-8702-99c69a9b9923@github.com>
References: <-Pt3zLSu1Y2GYeM8XEivglUyDVXlAqMIA42-_zEnHlo=.7dd40f19-160a-4f11-8702-99c69a9b9923@github.com>
Message-ID: <2QSQ5C7cdI-KgoFNa3aLqdYQQbLMY7P3qrKvVMsN86I=.503493f9-d9d0-4bff-b8a0-f95f82d412bb@github.com>

On Thu, 16 Mar 2023 05:03:51 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This is needed for future performance/scalability improvements in JVMTI support of virtual threads.
> The update includes the following:
> 
> 1. Refactored the `VirtualThread` native methods:
>     `notifyJvmtiMountBegin`     and `notifyJvmtiMountEnd`      => `notifyJvmtiMount`
>     `notifyJvmtiUnmountBegin` and `notifyJvmtiUnmountEnd` => `notifyJvmtiUnmount`
> 2. Still useful implementation of old native methods is moved from `jvm.cpp` to `jvmtiThreadState.cpp`:
>      `JVM_VirtualThreadMountStart`       => `VTMS_mount_begin`
>      `JVM_VirtualThreadMountEnd`         => `VTMS_mount_end`
>      `JVM_VirtualThreadUnmountStart`  = > `VTMS_unmount_begin`
>      `JVM_VirtualThreadUnmountEnd`    => `VTMS_mount_end`
> 3. Intrinsified the `VirtualThread` native methods: `notifyJvmtiMount`, `notifyJvmtiUnmount`, `notifyJvmtiHideFrames`.
> 4. Removed the`VirtualThread` static boolean state variable `notifyJvmtiEvents` and its support in `javaClasses`.
> 5. Added static boolean state variable `_VTMS_notify_jvmti_events` to the jvmtiVTMSTransitionDisabler class as a replacement of the `VirtualThread` `notifyJvmtiEvents` variable.
> 
> Implementing the same methods as C1 intrinsics can be needed in the future but is a low priority for now.  
> 
> Testing:
>  - Ran mach5 tiers 1-6. No regressions were found.

This pull request has now been integrated.

Changeset: bc0ed730
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bc0ed730f2c9dad55d0046b4fe8c9cd623b6dbf8
Stats:     449 lines in 20 files changed: 276 ins; 125 del; 48 mod

8304303: implement VirtualThread class notifyJvmti methods as C2 intrinsics

Reviewed-by: vlivanov, lmesnik

-------------

PR: https://git.openjdk.org/jdk/pull/13054

From jcking at openjdk.org  Mon Mar 20 20:55:21 2023
From: jcking at openjdk.org (Justin King)
Date: Mon, 20 Mar 2023 20:55:21 GMT
Subject: RFR: JDK-8304539: Cleanup
 utilities/{count_leading_zeros, count_trailing_zeros,
 population_count}.hpp [v8]
In-Reply-To: <Ly_ZIg1wqoqnEy0N-YFdQaEpGg7Er8Vtj8phZQhgAw0=.4d9b54db-517e-491e-a376-623139808b7e@github.com>
References: <Ly_ZIg1wqoqnEy0N-YFdQaEpGg7Er8Vtj8phZQhgAw0=.4d9b54db-517e-491e-a376-623139808b7e@github.com>
Message-ID: <cBtxz_2jafcL_vIzxQ3gcJizf4h-McuXfCA_gA8oS6M=.2105bea5-f72f-437c-a168-4be118e412cd@github.com>

> As the title says, cleanup the mentioned headers. This is similar to `byteswap.hpp` and removes the extraneous `#ifdef` for XLC since it is really just Clang now.

Justin King has updated the pull request incrementally with one additional commit since the last revision:

  Add default template implementation
  
  Signed-off-by: Justin King <jcking at google.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13103/files
  - new: https://git.openjdk.org/jdk/pull/13103/files/8b36d016..01ffca24

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13103&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13103&range=06-07

  Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13103.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13103/head:pull/13103

PR: https://git.openjdk.org/jdk/pull/13103

From jcking at openjdk.org  Mon Mar 20 21:01:30 2023
From: jcking at openjdk.org (Justin King)
Date: Mon, 20 Mar 2023 21:01:30 GMT
Subject: RFR: JDK-8304539: Cleanup
 utilities/{count_leading_zeros, count_trailing_zeros,
 population_count}.hpp [v9]
In-Reply-To: <Ly_ZIg1wqoqnEy0N-YFdQaEpGg7Er8Vtj8phZQhgAw0=.4d9b54db-517e-491e-a376-623139808b7e@github.com>
References: <Ly_ZIg1wqoqnEy0N-YFdQaEpGg7Er8Vtj8phZQhgAw0=.4d9b54db-517e-491e-a376-623139808b7e@github.com>
Message-ID: <FG5welVj7GkN06Q7er3PteNq2zzVnoApkq__lDpTk9A=.0fddb701-82f7-4237-9d22-4a9cf38084ae@github.com>

> As the title says, cleanup the mentioned headers. This is similar to `byteswap.hpp` and removes the extraneous `#ifdef` for XLC since it is really just Clang now.

Justin King has updated the pull request incrementally with one additional commit since the last revision:

  Move template declaration
  
  Signed-off-by: Justin King <jcking at google.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13103/files
  - new: https://git.openjdk.org/jdk/pull/13103/files/01ffca24..fc392637

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13103&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13103&range=07-08

  Stats: 30 lines in 1 file changed: 15 ins; 15 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13103.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13103/head:pull/13103

PR: https://git.openjdk.org/jdk/pull/13103

From psandoz at openjdk.org  Mon Mar 20 23:33:41 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 20 Mar 2023 23:33:41 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview)
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <ug6HcErmTSjZeFYe6EoeGyuSJ2dLVxNV95G65Pb-FC8=.62fb7b7d-d1f2-4b29-b713-d132824f7532@github.com>

On Fri, 17 Mar 2023 15:42:56 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

src/java.base/share/classes/java/lang/foreign/AddressLayout.java line 93:

> 91:      * @apiNote
> 92:      * This method can also be used to create an address layout which, when used, creates native memory
> 93:      * segments with maximal size (e.g. {@linkplain Long#MAX_VALUE}. This can be done by using a target sequence

Suggestion:

     * segments with maximal size (e.g. {@linkplain Long#MAX_VALUE}). This can be done by using a target sequence

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1142769618

From psandoz at openjdk.org  Tue Mar 21 00:38:49 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 21 Mar 2023 00:38:49 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview)
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <CCPgjTt6bNAY1NW-HJ0yGb1POVkZZED5ifgZNhSWZfQ=.871126a2-d21f-4a91-a271-eaf9cb729a13@github.com>

On Fri, 17 Mar 2023 15:42:56 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

src/java.base/share/classes/java/lang/foreign/Linker.java line 479:

> 477:      *     Otherwise, the invocation throws {@link WrongThreadException}; and</li>
> 478:      *     <li>{@code A} is kept alive during the invocation. For instance, if {@code A} has been obtained using a
> 479:      *     {@linkplain Arena#ofConfined() confined arena}, any attempt to {@linkplain Arena#close() close}

Is that correct? Do you mean a shared arena?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1142798464

From sspitsyn at openjdk.org  Tue Mar 21 00:56:51 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 21 Mar 2023 00:56:51 GMT
Subject: RFR: 8257967: JFR: Events for loaded agents [v10]
In-Reply-To: <ZsaBMVK-eeLfmxgg15qPJHm6C-ed5PyIE4lGr-Gnr2s=.2f4044c4-e7ed-48f3-8877-feeb2753be18@github.com>
References: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
 <ZsaBMVK-eeLfmxgg15qPJHm6C-ed5PyIE4lGr-Gnr2s=.2f4044c4-e7ed-48f3-8877-feeb2753be18@github.com>
Message-ID: <zgOuJcuqMY3Ku0NXGiZCbsSMslc3ap0EjeLJ5umUjx0=.0d0a259f-d39b-4c9a-9b00-c2c405fa05b8@github.com>

On Fri, 10 Mar 2023 10:43:23 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> We are adding support to let JFR report on Agents.
>> 
>> #### Design
>> 
>> An Agent is a library that uses any instrumentation or profiling APIs. Most agents are started and initialized on the command line, but agents can also be loaded dynamically during runtime. Because command line agents initialize during the VM startup sequence, they add to the overall startup time latency in getting the VM ready. The events will report on the time the agent took to initialize.
>> 
>> A JavaAgent is an agent written in the Java programming language, using the APIs in the package [java.lang.instrument](https://docs.oracle.com/en/java/javase/19/docs/api/java.instrument/java/lang/instrument/package-summary.html)
>> 
>> A JavaAgent is sometimes called a JPLIS agent, where the acronym JPLIS stands for Java Programming Language Instrumentation Services.
>> 
>> To report on JavaAgents, JFR will add the new event type jdk.JavaAgent and events will look similar to these two examples:
>> 
>> // Command line
>> jdk.JavaAgent {
>>   startTime = 12:31:19.789 (2023-03-08)
>>   name = "JavaAgent.jar"
>>   options = "foo=bar"
>>   dynamic = false
>>   initialization = 12:31:15.574 (2023-03-08)
>>   initializationTime = 172 ms
>> }
>> 
>> // Dynamic load
>> jdk.JavaAgent {
>>   startTime = 12:31:31.158 (2023-03-08)
>>   name = "JavaAgent.jar"
>>   options = "bar=baz"
>>   dynamic = true
>>   initialization = 12:31:31.037 (2023-03-08)
>>   initializationTime = 64,1 ms
>> }
>> 
>> The jdk.JavaAgent event type is a JFR periodic event that iterates over running Java agents.
>> 
>> For a JavaAgent event, the agent's name will be the specific .jar file containing the instrumentation code. The options will be the specific options passed to the .jar file as part of launching the agent, for example, on the command line: -javaagent: JavaAgent.jar=foo=bar.
>> 
>> The "dynamic" field denotes if the agent was loaded via the command line (dynamic = false) or dynamically (dynamic = true)
>> 
>> "initialization" is the timestamp the JVM invoked the initialization method, and "initializationTime" is the duration of executing the initialization method.
>> 
>> "startTime" represents the time the JFR framework issued the periodic event; hence "initialization" will be earlier than "startTime".
>> 
>> An agent can also be written in a native programming language using the [JVM Tools Interface (JVMTI)](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html). This kind of agent, sometimes called a native agent, is a platform-specific binary, sometimes referred to as a library, but here it means a .so or .dll file.
>> 
>> To report on native agents, JFR will add the new event type jdk.NativeAgent and events will look similar to this example:
>> 
>> jdk.NativeAgent {
>>   startTime = 12:31:40.398 (2023-03-08)
>>   name = "jdwp"
>>   options = "transport=dt_socket,server=y,address=any,onjcmd=y"
>>   dynamic = false
>>   initialization = 12:31:36.142 (2023-03-08)
>>   initializationTime = 0,00184 ms
>>   path = "c:\ade\github\openjdk\jdk\build\windows-x86_64-server-slowdebug\jdk\bin\jdwp.dll"
>> }
>> 
>> The layout of the event type is very similar to the jdk.JavaAgent event, but here the path to the native library is reported.
>> 
>> The initialization of a native agent is performed by invoking an agent-specified callback routine. The "initialization" is when the JVM sent or would have sent the JVMTI VMInit event to a specified callback. "initializationTime" is the duration to execute that specific callback. If no callback is specified for the JVMTI VMInit event, the "initializationTime" will be 0.
>> 
>> #### Implementation
>> 
>> There has not existed a reification of a JavaAgent directly in the JVM, as these are built on top of the JDK native library, "instrument", using a many-to-one mapping. At the level of the JVM, the only representation of agents after startup is through JvmtiEnv's, which agents request from the JVM during startup and initialization ? as such, mapping which JvmtiEnv belongs to what JavaAgent was not possible before.
>> 
>> Using implementation details of how the JDK native library "instrument" interacts with the JVM, we can build this mapping to track what JvmtiEnv's "belong" to what JavaAgent. This mapping now lets us report the Java-relevant context (name, options) and measure the time it takes for the JavaAgent to initialize.
>> 
>> When implementing this capability, it was necessary to refactor the code used to represent agents, AgentLibrary. The previous implementation was located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp.
>> 
>> The refactoring isolates the relevant logic into two new modules, prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their older places will help reduce the sizes of oversized arguments.cpp and threads.cpp.
>> 
>> The previous two lists that maintained "agents" (JVMTI) and "libraries" (Xrun) were not thread-safe for concurrent iterations. A single list that allows for concurrent iterations is therefore introduced.
>> 
>> Testing: jdk_jfr, tier 1 - 6
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more cleanup

src/hotspot/share/prims/jvmtiEnvBase.hpp line 166:

> 164: 
> 165:   const void* get_env_local_storage() { return _env_local_storage; }
> 166: 

Why was this change/move necessary? Do I miss anything?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12923#discussion_r1142804605

From psandoz at openjdk.org  Tue Mar 21 00:57:17 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 21 Mar 2023 00:57:17 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview)
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <ewzYWsxSa9yHV7LwF7JOOD2PMOx1FeCNCRwgGDnTFd0=.42c628eb-3cdf-4f45-a4fe-da481850d834@github.com>

On Fri, 17 Mar 2023 15:42:56 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

src/java.base/share/classes/java/lang/foreign/Linker.java line 609:

> 607:          * @see #captureStateLayout()
> 608:          */
> 609:         static Option captureCallState(String... capturedState) {

What if a name is not recognized? Throw IAE?

src/java.base/share/classes/java/lang/foreign/Linker.java line 621:

> 619:          *          to a downcall handle linked with {@link #captureCallState(String...)}}
> 620:          *
> 621:          * @see #captureCallState(String...)

How does a caller know what the structure may contain? Should we document the platform specific structures?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1142804110
PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1142804836

From david.holmes at oracle.com  Tue Mar 21 01:03:18 2023
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 21 Mar 2023 11:03:18 +1000
Subject: ASAN and slowdebug
In-Reply-To: <CAEdz=WVEQ9=2g5fV2Rw8FJ2c1=koA7+84+p8d+yr7wE8VRqgbg@mail.gmail.com>
References: <a1bcc12a-2a93-93a0-3885-48fc5fca7f90@arm.com>
 <CAEdz=WVEQ9=2g5fV2Rw8FJ2c1=koA7+84+p8d+yr7wE8VRqgbg@mail.gmail.com>
Message-ID: <89076570-14fd-4d98-d68f-a2125c2a1390@oracle.com>

On 21/03/2023 3:45 am, Justin King wrote:
> Ew. So for `MemoryService::create_MemoryUsage_obj` it's effectively 
> adding stuff after the return statement, causing the compiler to 
> complain. I think for `MemoryService::create_MemoryUsage_obj` that last 
> CHECK should probably be changed to THREAD since it's not useful.

Yep. We have been cleaning these up as we discover them, but no easy way 
to find them.

David

  and the
> code added after the return is unreachable. And LEAVE should probably be 
> changed to not have the return statement wrapped in an arbitrary?if 
> statement with JNI_TRUE as the expression, unless there is a reason for 
> that.
> 
> On Mon, Mar 20, 2023 at 10:34?AM Stuart Monteith 
> <stuart.monteith at arm.com <mailto:stuart.monteith at arm.com>> wrote:
> 
>     Hello,
>      ? ?While looking at ASAN to try to reproduce another issue with
>     ASAN, I tried building OpenJDK configured with:
>      ? ? ? ?--enable-asan --with-debug-level=slowdebug
> 
>     However, there is a compilation problem that persists up to and
>     include GCC 12.2.0:
>     https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80959
>     <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80959>
> 
>     As slowdebug builds are built with -O0, this results in code to be
>     inserted by the macros LEAVE() and CHECK_NH+CHECK_
>     macros to be not optimised away. This causes the following two
>     warnings/errors:
> 
>      ? * For target hotspot_variant-server_libjvm_objs_memoryService.o:
>     jdk/src/hotspot/share/services/memoryService.cpp: In static member
>     function 'static Handle
>     MemoryService::create_MemoryUsage_obj(MemoryUsage, JavaThread*)':
>     jdk/src/hotspot/share/services/memoryService.cpp:219:1: error:
>     control reaches end of non-void function
>     [-Werror=return-type]
> 
>      ? * For target support_native_java.base_libjli_java.o:
>     jdk/src/java.base/share/native/libjli/java.c: In function 'JavaMain':
>     jdk/src/java.base/share/native/libjli/java.c:556:1: error: control
>     reaches end of non-void function [-Werror=return-type]
>      ? ?556 | }
>      ? ? ? ?| ^
> 
> 
>     There are a couple of ways of working around this. One is to? change
>     create_MemoryUsage_obj and libjli/java.c to place a
>     return statement at the end of the function block, after the macros.
>     The changes are straightforward, but we're
>     obviously not guaranteed to not reintroduce the problem elsewhere.
> 
>     Another is to pass:? "--disable-warnings-as-errors" or more
>     specifically "--with-extra-cflags=-Wno-return-type
>     --with-extra-cxxflags=-Wno-return-type" to configure. This would be
>     a manual process, unless the make files were changed
>     to handle this, however this does remove the return type checks.
> 
> 
>     Part of the reason for sending this is to at least document the
>     issue publicly. Are there any opinions on what should to
>     be done next?
> 
> 
>     Stuart
> 
> 
> 
> -- 
> 
> Google Logo	
> Justin King
> Software Engineer
> jcking at google.com <mailto:jcking at google.com>
> 
> 	
> 

From psandoz at openjdk.org  Tue Mar 21 01:17:42 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 21 Mar 2023 01:17:42 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview)
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <gCw0GLdbWhEDntbtJ2vbG05KDkdF0PJFr0ujRDwE1E0=.e75212f0-b15d-4f7b-813e-2d2831a02d57@github.com>

On Fri, 17 Mar 2023 15:42:56 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 56:

> 54:  *     <li>It can be passed to an existing {@linkplain Linker#downcallHandle(FunctionDescriptor, Linker.Option...) downcall method handle}, as an argument to the underlying foreign function.</li>
> 55:  *     <li>It can be {@linkplain MemorySegment#set(AddressLayout, long, MemorySegment) stored} inside another memory segment.</li>
> 56:  *     <li>It can be used to access the region of memory backing a global variable (this might require

Suggestion:

 *     <li>It can be used to access the region of memory backing a global variable (this requires

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1142812300

From fgao at openjdk.org  Tue Mar 21 02:33:41 2023
From: fgao at openjdk.org (Fei Gao)
Date: Tue, 21 Mar 2023 02:33:41 GMT
Subject: RFR: 8304301: Remove the global option SuperWordMaxVectorSize
Message-ID: <2XQwCCx_ficJ1bn2WX0Ud9m-QmuGkkZAH8N6yLugXqQ=.90a136da-db9a-49b4-a4c4-d6c644cf7d5a@github.com>

https://github.com/openjdk/jdk/pull/8877 introduced the global option `SuperWordMaxVectorSize` as a temporary solution to fix the performance regression on some x86 machines.

Currently, `SuperWordMaxVectorSize` behaves differently between x86 and other platforms [1]. For example, if the current machine only supports `MaxVectorSize <= 32`, but we set `SuperWordMaxVectorSize = 64`, then `SuperWordMaxVectorSize` will be kept at 64 on other platforms while x86 machine would change `SuperWordMaxVectorSize` to `MaxVectorSize`. Other platforms except x86 miss similar implementations like [2].

Also, `SuperWordMaxVectorSize` limits the max vector size of auto-vectorization as `64`, which is fine for current aarch64 hardware, but SVE architecture supports larger than 512 bits.

The patch is to drop the global option and use an architecture-dependent interface to consult the max vector size for auto-vectorization, fixing the performance issue on x86 and reducing side effects for other platforms. After the patch, auto-vectorization is still limited to 32-byte vectors by default on Cascade Lake and users can override this by either setting
`-XX:UseAVX=3` or `-XX:MaxVectorSize=64` on JVM command line.

So my question is:

Before the patch, we could have a smaller max vector size for auto-vectorization than `MaxVectorSize` on x86. For example, users could have `MaxVectorSize=64` and `SuperWordMaxVectorSize=32`. But after the change, if we set
`-XX:MaxVectorSize=64` explicitly, then the max vector size for auto-vectorization would be `MaxVectorSize`, i.e. 64 bytes, which I believe is more reasonable. @sviswa7 @jatin-bhateja, are you happy about the change?

[1] https://github.com/openjdk/jdk/pull/12350#discussion_r1126106213
[2] https://github.com/openjdk/jdk/blob/33bec207103acd520eb99afb093cfafa44aecfda/src/hotspot/cpu/x86/vm_version_x86.cpp#L1314-L1333

-------------

Commit messages:
 - 8304301: Remove the global option SuperWordMaxVectorSize

Changes: https://git.openjdk.org/jdk/pull/13112/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13112&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304301
  Stats: 104 lines in 14 files changed: 50 ins; 38 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/13112.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13112/head:pull/13112

PR: https://git.openjdk.org/jdk/pull/13112

From sviswanathan at openjdk.org  Tue Mar 21 04:19:44 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 21 Mar 2023 04:19:44 GMT
Subject: RFR: 8304301: Remove the global option SuperWordMaxVectorSize
In-Reply-To: <2XQwCCx_ficJ1bn2WX0Ud9m-QmuGkkZAH8N6yLugXqQ=.90a136da-db9a-49b4-a4c4-d6c644cf7d5a@github.com>
References: <2XQwCCx_ficJ1bn2WX0Ud9m-QmuGkkZAH8N6yLugXqQ=.90a136da-db9a-49b4-a4c4-d6c644cf7d5a@github.com>
Message-ID: <x_FnktZAXmUd_uw0x9246aHueRxxt9AlXabM5TIwO90=.35996788-e648-4a61-848f-9183bde7936d@github.com>

On Tue, 21 Mar 2023 02:26:55 GMT, Fei Gao <fgao at openjdk.org> wrote:

> https://github.com/openjdk/jdk/pull/8877 introduced the global option `SuperWordMaxVectorSize` as a temporary solution to fix the performance regression on some x86 machines.
> 
> Currently, `SuperWordMaxVectorSize` behaves differently between x86 and other platforms [1]. For example, if the current machine only supports `MaxVectorSize <= 32`, but we set `SuperWordMaxVectorSize = 64`, then `SuperWordMaxVectorSize` will be kept at 64 on other platforms while x86 machine would change `SuperWordMaxVectorSize` to `MaxVectorSize`. Other platforms except x86 miss similar implementations like [2].
> 
> Also, `SuperWordMaxVectorSize` limits the max vector size of auto-vectorization as `64`, which is fine for current aarch64 hardware, but SVE architecture supports larger than 512 bits.
> 
> The patch is to drop the global option and use an architecture-dependent interface to consult the max vector size for auto-vectorization, fixing the performance issue on x86 and reducing side effects for other platforms. After the patch, auto-vectorization is still limited to 32-byte vectors by default on Cascade Lake and users can override this by either setting
> `-XX:UseAVX=3` or `-XX:MaxVectorSize=64` on JVM command line.
> 
> So my question is:
> 
> Before the patch, we could have a smaller max vector size for auto-vectorization than `MaxVectorSize` on x86. For example, users could have `MaxVectorSize=64` and `SuperWordMaxVectorSize=32`. But after the change, if we set
> `-XX:MaxVectorSize=64` explicitly, then the max vector size for auto-vectorization would be `MaxVectorSize`, i.e. 64 bytes, which I believe is more reasonable. @sviswa7 @jatin-bhateja, are you happy about the change?
> 
> [1] https://github.com/openjdk/jdk/pull/12350#discussion_r1126106213
> [2] https://github.com/openjdk/jdk/blob/33bec207103acd520eb99afb093cfafa44aecfda/src/hotspot/cpu/x86/vm_version_x86.cpp#L1314-L1333

@fg1417  SuperWordMaxVectorSize defines the maximum vector size generated by the auto vectorization.
                 MaxVectorSize defines the  vector width supported by the underlying platform. 
                 For CascadeLake we are setting SuperWordMaxVectorSize=32 and MaxVectorSize=64 by default.
                 This allows the usage of larger 64 byte width vector instructions in places like Java Vector API and intrinsics. 
                 We would like to keep this behavior for x86.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13112#issuecomment-1477259831

From fgao at openjdk.org  Tue Mar 21 06:45:50 2023
From: fgao at openjdk.org (Fei Gao)
Date: Tue, 21 Mar 2023 06:45:50 GMT
Subject: RFR: 8304301: Remove the global option SuperWordMaxVectorSize
In-Reply-To: <x_FnktZAXmUd_uw0x9246aHueRxxt9AlXabM5TIwO90=.35996788-e648-4a61-848f-9183bde7936d@github.com>
References: <2XQwCCx_ficJ1bn2WX0Ud9m-QmuGkkZAH8N6yLugXqQ=.90a136da-db9a-49b4-a4c4-d6c644cf7d5a@github.com>
 <x_FnktZAXmUd_uw0x9246aHueRxxt9AlXabM5TIwO90=.35996788-e648-4a61-848f-9183bde7936d@github.com>
Message-ID: <fYbDcXTbdGDYS4wD85Rzt_MdVmZAJTP1qa8fowBal6w=.24126776-a409-4e6f-8b8c-19a0e0c5d768@github.com>

On Tue, 21 Mar 2023 04:16:26 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> @fg1417 SuperWordMaxVectorSize defines the maximum vector size generated by the auto vectorization. MaxVectorSize defines the vector width supported by the underlying platform. For CascadeLake we are setting SuperWordMaxVectorSize=32 and MaxVectorSize=64 by default. This allows the usage of larger 64 byte width vector instructions in places like Java Vector API and intrinsics. We would like to keep this behavior for x86.

Hi @sviswa7, thanks for your quick response! Yes, the patch keeps the special handling for auto-vectorization on Cascade Lake. For Cascade Lake, even after the patch, we still have 32 bytes for auto-vectorization and larger 64 bytes for Java Vector API and intrinsics. Can it cover your needs?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13112#issuecomment-1477349803

From pminborg at openjdk.org  Tue Mar 21 07:50:22 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 21 Mar 2023 07:50:22 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v2]
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <szmGqTNbFntO4asM1v1fdufExyMO2FY89WU5j5NrpeM=.1b6055f9-87e4-4c4f-a95a-7abe306a7c50@github.com>

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

Per Minborg has updated the pull request incrementally with two additional commits since the last revision:

 - Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java
   
   Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>
 - Update src/java.base/share/classes/java/lang/foreign/AddressLayout.java
   
   Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/bb2f4438..7a78948a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13079/head:pull/13079

PR: https://git.openjdk.org/jdk/pull/13079

From pminborg at openjdk.org  Tue Mar 21 08:04:25 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 21 Mar 2023 08:04:25 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v3]
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <FGRSvA90xZez_v3fRQzgn7YqqYgHBK-0aiJr9UqWRJo=.40e2226e-3ee7-4981-a468-c71f25adf6ff@github.com>

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Remove MemoryInspection classes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/7a78948a..a71518c4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=01-02

  Stats: 684 lines in 3 files changed: 0 ins; 684 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13079/head:pull/13079

PR: https://git.openjdk.org/jdk/pull/13079

From pminborg at openjdk.org  Tue Mar 21 08:33:29 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 21 Mar 2023 08:33:29 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v4]
In-Reply-To: <ewzYWsxSa9yHV7LwF7JOOD2PMOx1FeCNCRwgGDnTFd0=.42c628eb-3cdf-4f45-a4fe-da481850d834@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <ewzYWsxSa9yHV7LwF7JOOD2PMOx1FeCNCRwgGDnTFd0=.42c628eb-3cdf-4f45-a4fe-da481850d834@github.com>
Message-ID: <TbBkOj-wFsuDfnzM3HnB-BMxD87f5DXaf0mFmcUqCB0=.23850e94-11ae-430b-962a-2c308fc08aa9@github.com>

On Tue, 21 Mar 2023 00:52:01 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve Linker javadocs
>
> src/java.base/share/classes/java/lang/foreign/Linker.java line 609:
> 
>> 607:          * @see #captureStateLayout()
>> 608:          */
>> 609:         static Option captureCallState(String... capturedState) {
> 
> What if a name is not recognized? Throw IAE?

Added

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1143024389

From pminborg at openjdk.org  Tue Mar 21 08:33:26 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 21 Mar 2023 08:33:26 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v4]
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <_HwSyb1bsHNIJpGKdznMZR_HfWIU9VeAl1etn4miKGQ=.8397676f-1e24-4a2e-bcfa-ed44fb8a515b@github.com>

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Improve Linker javadocs

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/a71518c4..4626a54e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=02-03

  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13079/head:pull/13079

PR: https://git.openjdk.org/jdk/pull/13079

From pminborg at openjdk.org  Tue Mar 21 09:02:29 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 21 Mar 2023 09:02:29 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v5]
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <MtnTWtmtdQkU0RqBSp7DuSnQz0OO8Bk3HzJi7NHZDoU=.bc0c0f9f-454a-484d-9613-95b00f5af7ca@github.com>

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Add example for Option::captureStateLayout

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/4626a54e..21ef0607

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=03-04

  Stats: 12 lines in 1 file changed: 12 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13079/head:pull/13079

PR: https://git.openjdk.org/jdk/pull/13079

From pminborg at openjdk.org  Tue Mar 21 09:02:33 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 21 Mar 2023 09:02:33 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v5]
In-Reply-To: <ewzYWsxSa9yHV7LwF7JOOD2PMOx1FeCNCRwgGDnTFd0=.42c628eb-3cdf-4f45-a4fe-da481850d834@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <ewzYWsxSa9yHV7LwF7JOOD2PMOx1FeCNCRwgGDnTFd0=.42c628eb-3cdf-4f45-a4fe-da481850d834@github.com>
Message-ID: <lphoedvalFnqUzhydGb-ggq1yG1UpsZMZvaswVJTiYc=.4a1d0cac-a88b-4600-8531-643b7a2b25fb@github.com>

On Tue, 21 Mar 2023 00:54:10 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add example for Option::captureStateLayout
>
> src/java.base/share/classes/java/lang/foreign/Linker.java line 621:
> 
>> 619:          *          to a downcall handle linked with {@link #captureCallState(String...)}}
>> 620:          *
>> 621:          * @see #captureCallState(String...)
> 
> How does a caller know what the structure may contain? Should we document the platform specific structures?

I've added an example of how to print the platform-dependent structure. Should we document anyhow?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1143055969

From mcimadamore at openjdk.org  Tue Mar 21 09:52:54 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 21 Mar 2023 09:52:54 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v5]
In-Reply-To: <CCPgjTt6bNAY1NW-HJ0yGb1POVkZZED5ifgZNhSWZfQ=.871126a2-d21f-4a91-a271-eaf9cb729a13@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <CCPgjTt6bNAY1NW-HJ0yGb1POVkZZED5ifgZNhSWZfQ=.871126a2-d21f-4a91-a271-eaf9cb729a13@github.com>
Message-ID: <Flvw3B4SJ83X49JboIaHlB2Qr20_16FfdgadeAB7cRM=.2a0fd783-08ee-475c-84a4-1a58a100c7f1@github.com>

On Tue, 21 Mar 2023 00:35:40 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add example for Option::captureStateLayout
>
> src/java.base/share/classes/java/lang/foreign/Linker.java line 479:
> 
>> 477:      *     Otherwise, the invocation throws {@link WrongThreadException}; and</li>
>> 478:      *     <li>{@code A} is kept alive during the invocation. For instance, if {@code A} has been obtained using a
>> 479:      *     {@linkplain Arena#ofConfined() confined arena}, any attempt to {@linkplain Arena#close() close}
> 
> Is that correct? Do you mean a shared arena?

The text is correct (you can still close a confined arena from inside an upcall), but I agree that perhaps using a shared arena might be a bit more intuitive.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1143118512

From mcimadamore at openjdk.org  Tue Mar 21 09:56:53 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 21 Mar 2023 09:56:53 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v5]
In-Reply-To: <lphoedvalFnqUzhydGb-ggq1yG1UpsZMZvaswVJTiYc=.4a1d0cac-a88b-4600-8531-643b7a2b25fb@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <ewzYWsxSa9yHV7LwF7JOOD2PMOx1FeCNCRwgGDnTFd0=.42c628eb-3cdf-4f45-a4fe-da481850d834@github.com>
 <lphoedvalFnqUzhydGb-ggq1yG1UpsZMZvaswVJTiYc=.4a1d0cac-a88b-4600-8531-643b7a2b25fb@github.com>
Message-ID: <JKtIE6vgQ3nHpk2pHQsYYkLNO0QtGNJY5c-rSgRrQLw=.a22c8183-fd95-4f07-bdcc-dddf706e733e@github.com>

On Tue, 21 Mar 2023 08:57:42 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/foreign/Linker.java line 621:
>> 
>>> 619:          *          to a downcall handle linked with {@link #captureCallState(String...)}}
>>> 620:          *
>>> 621:          * @see #captureCallState(String...)
>> 
>> How does a caller know what the structure may contain? Should we document the platform specific structures?
>
> I've added an example of how to print the platform-dependent structure. Should we document anyhow?

I'm not sure about this. Honestly, the example probably doesn't help much if somebody didn't get the idea of what the layout might be. I think it might be better to say something like, `on Windows/x64 the returned layout might be as follows...` and then you write the code to create the layout instance corresponding to the returned layout. But we have to be careful to make the text non-normative (as the set of values might change).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1143125997

From jsjolen at openjdk.org  Tue Mar 21 09:56:53 2023
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 21 Mar 2023 09:56:53 GMT
Subject: RFR: JDK-8301493: Replace NULL with nullptr in cpu/aarch64
In-Reply-To: <w-lD1p2l43LSAIW8aEkX7VPahixuz0pe7vuzBnOre70=.1fd9d59f-1b9f-4c45-ab04-f1e1638c350c@github.com>
References: <w-lD1p2l43LSAIW8aEkX7VPahixuz0pe7vuzBnOre70=.1fd9d59f-1b9f-4c45-ab04-f1e1638c350c@github.com>
Message-ID: <N9gEOjyHhwrXlJ6pUrwyxnNOQHfL6DGiU9Wvgk898c8=.ef315692-d9db-4e6d-835c-b70aa2660551@github.com>

On Tue, 31 Jan 2023 11:39:27 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory cpu/aarch64. Unfortunately the script that does the change isn't perfect, and so we
> need to comb through these manually to make sure nothing has gone wrong. I also review these changes but things slip past my eyes sometimes.
> 
> Here are some typical things to look out for:
> 
> 1. No changes but copyright header changed (probably because I reverted some changes but forgot the copyright).
> 2. Macros having their NULL changed to nullptr, these are added to the script when I find them. They should be NULL.
> 3. nullptr in comments and logs. We try to use lower case "null" in these cases as it reads better. An exception is made when code expressions are in a comment.
> 
> An example of this:
> 
> ```c++
> // This function returns null
> void* ret_null();
> // This function returns true if *x == nullptr
> bool is_nullptr(void** x);
> 
> 
> Note how `nullptr` participates in a code expression here, we really are talking about the specific value `nullptr`.
> 
> Thanks!

Not yet.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12321#issuecomment-1477546797

From mcimadamore at openjdk.org  Tue Mar 21 10:01:53 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 21 Mar 2023 10:01:53 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v5]
In-Reply-To: <MtnTWtmtdQkU0RqBSp7DuSnQz0OO8Bk3HzJi7NHZDoU=.bc0c0f9f-454a-484d-9613-95b00f5af7ca@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <MtnTWtmtdQkU0RqBSp7DuSnQz0OO8Bk3HzJi7NHZDoU=.bc0c0f9f-454a-484d-9613-95b00f5af7ca@github.com>
Message-ID: <YyfJ-JhtaJyXrw2pTqzppzYtwYlCF3CcTx-gQ-kceMw=.6af67667-35a5-41e7-ae27-9538c43bb443@github.com>

On Tue, 21 Mar 2023 09:02:29 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> API changes for the FFM API (third preview)
>> 
>> Specdiff:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
>> 
>> Javadoc:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add example for Option::captureStateLayout

src/java.base/share/classes/java/lang/foreign/Linker.java line 480:

> 478:      *     Otherwise, the invocation throws {@link WrongThreadException}; and</li>
> 479:      *     <li>{@code A} is kept alive during the invocation. For instance, if {@code A} has been obtained using a
> 480:      *     {@linkplain Arena#ofShared()} confined arena}, any attempt to {@linkplain Arena#close() close}

the description of the link still says "confined"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1143131392

From jsjolen at openjdk.org  Tue Mar 21 10:04:04 2023
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 21 Mar 2023 10:04:04 GMT
Subject: RFR: JDK-8301498: Replace NULL with nullptr in cpu/x86 [v4]
In-Reply-To: <AB1094dam2aXNm_hav09Ium0jqJUCJE0hmJ4GfljA5M=.4e8e0845-20d5-45bf-bf2e-1d23ed8ef9f0@github.com>
References: <AB1094dam2aXNm_hav09Ium0jqJUCJE0hmJ4GfljA5M=.4e8e0845-20d5-45bf-bf2e-1d23ed8ef9f0@github.com>
Message-ID: <K21IuPJG7Tk7Kjvsp1MFiE67n5iDJlezp369mHL1mdE=.6f1d309e-3ac8-4758-b38d-5bc21ce232e9@github.com>

> Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory cpu/x86. Unfortunately the script that does the change isn't perfect, and so we
> need to comb through these manually to make sure nothing has gone wrong. I also review these changes but things slip past my eyes sometimes.
> 
> Here are some typical things to look out for:
> 
> 1. No changes but copyright header changed (probably because I reverted some changes but forgot the copyright).
> 2. Macros having their NULL changed to nullptr, these are added to the script when I find them. They should be NULL.
> 3. nullptr in comments and logs. We try to use lower case "null" in these cases as it reads better. An exception is made when code expressions are in a comment.
> 
> An example of this:
> 
> ```c++
> // This function returns null
> void* ret_null();
> // This function returns true if *x == nullptr
> bool is_nullptr(void** x);
> 
> 
> Note how `nullptr` participates in a code expression here, we really are talking about the specific value `nullptr`.
> 
> Thanks!

Johan Sj?len has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Merge remote-tracking branch 'origin/master' into JDK-8301498
 - Fix vnkozlov's suggestions
 - Merge remote-tracking branch 'origin/master' into JDK-8301498
 - Some more fixes
 - Fixes
 -  Replace NULL with nullptr in cpu/x86

-------------

Changes: https://git.openjdk.org/jdk/pull/12326/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12326&range=03
  Stats: 657 lines in 54 files changed: 0 ins; 0 del; 657 mod
  Patch: https://git.openjdk.org/jdk/pull/12326.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12326/head:pull/12326

PR: https://git.openjdk.org/jdk/pull/12326

From aph at openjdk.org  Tue Mar 21 10:53:53 2023
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 21 Mar 2023 10:53:53 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v9]
In-Reply-To: <W69abHEQZctZeg7QaoW9DFPWPhSNAL3PHMZABD3xLWU=.9e63f600-be6d-4258-991e-4b609be33f0a@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <W69abHEQZctZeg7QaoW9DFPWPhSNAL3PHMZABD3xLWU=.9e63f600-be6d-4258-991e-4b609be33f0a@github.com>
Message-ID: <D2-FZhAAt_mlmHeq6yf1weJku-AF7D01R1nihd7_pXo=.49229406-5e0e-4ba6-ae52-f9c80a6038db@github.com>

On Mon, 20 Mar 2023 14:29:35 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
>> 
>> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
>> 
>> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
>> 
>> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
>> 
>> This change supports the following platforms: x86, aarch64, PPC, and RISCV
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix riscv interpreter mistake and acquire semantics

src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp line 491:

> 489:   } else {
> 490:     // Pop N words from the stack
> 491:     __ get_cache_and_index_at_bcp(r1, r2, 1, index_size);

This aliasing of `r1` and `cache` is very confusing. Please decide whether to use the name `cache` or `r1` and do so consistently.

src/hotspot/cpu/aarch64/templateTable_aarch64.cpp line 2337:

> 2335:   // Load-acquire the adapter method
> 2336:   __ lea(method, Address(cache, in_bytes(ResolvedIndyEntry::method_offset())));
> 2337:   __ ldar(method, method);

What reordering are we trying to prevent here?

src/hotspot/cpu/aarch64/templateTable_aarch64.cpp line 2399:

> 2397:                                                bool is_invokevirtual,
> 2398:                                                bool is_invokevfinal, /*unused*/
> 2399:                                                bool is_invokedynamic /*unused*/) {

Suggestion:

                                               bool /*is_invokedynamic*/) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12778#discussion_r1143191698
PR Review Comment: https://git.openjdk.org/jdk/pull/12778#discussion_r1143193859
PR Review Comment: https://git.openjdk.org/jdk/pull/12778#discussion_r1143195547

From pminborg at openjdk.org  Tue Mar 21 12:02:44 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 21 Mar 2023 12:02:44 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v5]
In-Reply-To: <JKtIE6vgQ3nHpk2pHQsYYkLNO0QtGNJY5c-rSgRrQLw=.a22c8183-fd95-4f07-bdcc-dddf706e733e@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <ewzYWsxSa9yHV7LwF7JOOD2PMOx1FeCNCRwgGDnTFd0=.42c628eb-3cdf-4f45-a4fe-da481850d834@github.com>
 <lphoedvalFnqUzhydGb-ggq1yG1UpsZMZvaswVJTiYc=.4a1d0cac-a88b-4600-8531-643b7a2b25fb@github.com>
 <JKtIE6vgQ3nHpk2pHQsYYkLNO0QtGNJY5c-rSgRrQLw=.a22c8183-fd95-4f07-bdcc-dddf706e733e@github.com>
Message-ID: <fOJiFar9A4DhcguZVcFM61Zx4ZwX5BN4Zv8jHRxbn1M=.2b74ea12-4c90-4d37-acba-93a90de9f2ff@github.com>

On Tue, 21 Mar 2023 09:54:16 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I've added an example of how to print the platform-dependent structure. Should we document anyhow?
>
> I'm not sure about this. Honestly, the example probably doesn't help much if somebody didn't get the idea of what the layout might be. I think it might be better to say something like, `on Windows/x64 the returned layout might be as follows...` and then you write the code to create the layout instance corresponding to the returned layout. But we have to be careful to make the text non-normative (as the set of values might change).

What about adding something like this?


Here is a list of valid names for some platforms:
    Linux:
        "errno"
    macOS:
        "errno"
    Windows:
        "GetLastError", "WSAGetLastError" and "errno"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1143265595

From mcimadamore at openjdk.org  Tue Mar 21 12:08:45 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 21 Mar 2023 12:08:45 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v5]
In-Reply-To: <fOJiFar9A4DhcguZVcFM61Zx4ZwX5BN4Zv8jHRxbn1M=.2b74ea12-4c90-4d37-acba-93a90de9f2ff@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <ewzYWsxSa9yHV7LwF7JOOD2PMOx1FeCNCRwgGDnTFd0=.42c628eb-3cdf-4f45-a4fe-da481850d834@github.com>
 <lphoedvalFnqUzhydGb-ggq1yG1UpsZMZvaswVJTiYc=.4a1d0cac-a88b-4600-8531-643b7a2b25fb@github.com>
 <JKtIE6vgQ3nHpk2pHQsYYkLNO0QtGNJY5c-rSgRrQLw=.a22c8183-fd95-4f07-bdcc-dddf706e733e@github.com>
 <fOJiFar9A4DhcguZVcFM61Zx4ZwX5BN4Zv8jHRxbn1M=.2b74ea12-4c90-4d37-acba-93a90de9f2ff@github.com>
Message-ID: <5VeF6VvOJ94JGz-slAqtwU-mtnhdV4qSk2KsbqVy-x4=.47d9a1f7-b86b-4d07-8ab1-f9abbaf3e5ed@github.com>

On Tue, 21 Mar 2023 11:58:28 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> I'm not sure about this. Honestly, the example probably doesn't help much if somebody didn't get the idea of what the layout might be. I think it might be better to say something like, `on Windows/x64 the returned layout might be as follows...` and then you write the code to create the layout instance corresponding to the returned layout. But we have to be careful to make the text non-normative (as the set of values might change).
>
> What about adding something like this?
> 
> 
> Here is a list of valid names for some platforms:
>     Linux:
>         "errno"
>     macOS:
>         "errno"
>     Windows:
>         "GetLastError", "WSAGetLastError" and "errno"

I'd prefer something more informal: "Examples of valid names are "errno" on Linux/x64, or "GetLastError" on Windows/x64". And maybe add that "The precise set of platform-dependent supported names can be queried using the returned group layout".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1143272764

From mcimadamore at openjdk.org  Tue Mar 21 12:17:43 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 21 Mar 2023 12:17:43 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v5]
In-Reply-To: <ewzYWsxSa9yHV7LwF7JOOD2PMOx1FeCNCRwgGDnTFd0=.42c628eb-3cdf-4f45-a4fe-da481850d834@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <ewzYWsxSa9yHV7LwF7JOOD2PMOx1FeCNCRwgGDnTFd0=.42c628eb-3cdf-4f45-a4fe-da481850d834@github.com>
Message-ID: <pYRtChaFVMs_cb5b2yJOF5-sgqyjzFpO3k_fkNH8Ezo=.3acc93cd-65b4-4722-8761-7f4e725fe68c@github.com>

On Tue, 21 Mar 2023 00:54:10 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add example for Option::captureStateLayout
>
> src/java.base/share/classes/java/lang/foreign/Linker.java line 621:
> 
>> 619:          *          to a downcall handle linked with {@link #captureCallState(String...)}}
>> 620:          *
>> 621:          * @see #captureCallState(String...)
> 
> How does a caller know what the structure may contain? Should we document the platform specific structures?

Back to @PaulSandoz  question - "how does the caller know what the structure contains?". The caller typically doesn't care too much about what the returned struct is. But it might care about which "values" can be captured. That said, the set of such interesting values, is not too surprising. As demonstrated in the example in the `Linker.capturedCallState` method, once the client knows the name (and "errno" is likely to be 90% case), everything else follows from there - as the layout can be used to obtain var handles for the required values.

But, perhaps, now that I write this, I realize that what @PaulSandoz might _really_ be asking is: how do I know that e.g. the returned struct will not contain e.g. nested structs, sequences, or other non-sense. So we might specify (in a normative way) that the returned layout is a struct layout, whose member layouts are one or more value layouts (possibly with some added padding layouts). The names of the value layouts reflect the names of the values that can be captured.

And _then_ we show an example of the layout we return for Windows/x64 (as that's more interesting).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1143281164

From jwaters at openjdk.org  Tue Mar 21 13:03:58 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 21 Mar 2023 13:03:58 GMT
Subject: RFR: 8302798: Refactor -XX:+UseOSErrorReporting for noreturn crash
 reporting [v3]
In-Reply-To: <e2seVQWyK6KOjyo8gGmxeJfPbXBV0QibpBAm6jYAsJE=.27f3fdfc-7763-409e-be1c-3fe61e3905b7@github.com>
References: <elVA1mzItfJ7bnnfSpEUVprtbnnSx1zT_eoXnV2sviU=.13e2d4dc-74b0-4051-8852-04caf2c81196@github.com>
 <e2seVQWyK6KOjyo8gGmxeJfPbXBV0QibpBAm6jYAsJE=.27f3fdfc-7763-409e-be1c-3fe61e3905b7@github.com>
Message-ID: <bra4j8ERIDMpG5qENJfD8s1r1SJBDR_LORHvU_xDefY=.2f707a60-ebc0-4c98-81c3-1080d1279cf3@github.com>

On Wed, 1 Mar 2023 10:25:06 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to the implementation of the Windows-specific option
>> UseOSErrorReporting, toward allowing crash reporting functions to be declared
>> noreturn.  VMError::report_and_die no longer conditionally returns if the
>> Windows-only option UseOSErrorReporting is true.
>> 
>> The Windows-only sections of report_and_die now call RaiseFailFastException
>> (https://learn.microsoft.com/en-us/windows/win32/api/errhandlingapi/nf-errhandlingapi-raisefailfastexception),
>> which immediately invokes WER (Windows Error Reporting) if it is enabled,
>> without executing structured exception handler.  If WER is not enabled, it
>> just immediately terminates the program.  Thus, we no longer return to walk up
>> thestructured exception handler chain to pop out at the top as unhandled in
>> order to invoke WER.
>> 
>> This permits declaring report_and_die as [[noreturn]], once some functions
>> from the os class are also so declared.  Also adding that attribute as
>> appropriate to other functions in the os class.  This of course assumes
>> the use of [[noreturn]] in HotSpot code is approved (JDK-8302124).
>> 
>> There is a pre-existing bug that I'll be reporting separately.  If
>> UseOSErrorReporting and CreateCoredumpOnCrash are both true, we create an
>> empty .mdmp file.  We shouldn't create that file when UseOSErrorReporting.
>> 
>> Testing:
>> mach5 tier1-3
>> 
>> Manual testing with the following, to verify desired behavior.
>> 
>> -XX:ErrorHandlerTest=N
>> 1: assertion failure
>> 2: guarantee failure
>> 14: SIGSEGV
>> 15: divide by zero
>> path/to/bin/java \
>>   -XX:+UnlockDiagnosticVMOptions \
>>   -XX:+ErrorLogSecondaryErrorDetails \
>>   -XX:+UseOSErrorReporting \
>>   -XX:ErrorHandlerTest=1 \
>>   TestDebug.java
>> 
>> --- TestDebug.java ---
>> import java.lang.String;
>> public class TestDebug {
>>     static private volatile String dummy;
>>     public static void main(String[] args) throws Exception {
>>         while (true) {
>>             dummy = new String("foo bar");
>>         }
>>     }
>> }
>> --- end TestDebug.java ---
>> 
>> The state of WER can be examined and modified using Power Shell commands
>> {Get,Enable,Disable}-WindowsErrorReporting.
>> 
>> The state of reporting WER captured errors can be examined and modified using
>> Control Panel > Security and Maintenance > Maintenance : Report Problems [on,off]
>> 
>> With Report Problems off, reports are placed in
>> c:\ProgramData\Microsoft\Windows\WER\ReportArchive
>> 
>> I verified that executing the above test with WER enabled adds an entry in
>> that directory, but not when it's disabled.  Also nothing is added there when
>> the test is run with -XX:-UseOSErrorReporting.
>
> 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 three additional commits since the last revision:
> 
>  - Merge branch 'master' into failfast
>  - remove failfast cuttoff of secondary errors
>  - failfast

When compiling a Windows HotSpot with gcc (see [8288293](https://bugs.openjdk.org/browse/JDK-8288293?filter=-3)) newer gcc versions have a diagnostic that can catch when noreturn code returns in certain areas, and gcc catches several with this change:

src/hotspot/os/windows/os_windows.cpp: In static member function 'static void os::abort(bool, void*, const void*)':
src/hotspot/os/windows/os_windows.cpp:1249:1: error: 'noreturn' function does return [-Werror]
 1249 | }
      | ^
src/hotspot/os/windows/os_windows.cpp: In static member function 'static void os::die()':
src/hotspot/os/windows/os_windows.cpp:1254:1: error: 'noreturn' function does return [-Werror]
 1254 | }
      | ^
src/hotspot/os/windows/os_windows.cpp: In static member function 'static void os::exit(int)':
src/hotspot/os/windows/os_windows.cpp:4792:1: error: 'noreturn' function does return [-Werror]
 4792 | }
      | ^
src/hotspot/os/windows/os_windows.cpp: In static member function 'static void os::_exit(int)':
src/hotspot/os/windows/os_windows.cpp:4796:1: error: 'noreturn' function does return [-Werror]
 4796 | }


I don't know if this is something we should be worried about with our current setup and the regular build that we have for Windows, so I'm leaving this warning here for someone else to read through

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12759#issuecomment-1477797624

From coleenp at openjdk.org  Tue Mar 21 13:26:44 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 21 Mar 2023 13:26:44 GMT
Subject: RFR: 8304089: Convert TraceDependencies to UL [v3]
In-Reply-To: <twz6ptVD0WsinSvvMzp6GGMOjwTotBb0RX9SiGtMnIo=.61a1c3c2-b5ab-4187-b400-2a2da23da7dc@github.com>
References: <0aGc1NdAjpvksCWmXb1gZOPp9MV0n6xWvG8EaEp2ZLg=.b79cf218-9a23-420d-bec5-7509b7f8f1c1@github.com>
 <BQzDwBUOHbm1v3Ex5uAT56pIQJtoT8ON4ZmFhi3TvR0=.ce86f07b-4136-4870-93f0-c9723c80795b@github.com>
 <13yGfFhRFEsjHA-ox_6GxPiyU8w_hpQtgjHbsw6Glq0=.c2330c3f-0316-4f4c-aade-b6ad6c8543ee@github.com>
 <tLhX6beNey8aikbBH30RbCu7lfXZ9AWG2KYqKWVvnkw=.a41fbeb0-6c04-4b6a-824a-fc9fdf734fd2@github.com>
 <2IKS8cYMhoU1JRBEalwF1ZeV4Vih78eXffu_GXZ4JkQ=.27d433ac-1f04-47ce-a177-c791a42bc6fe@github.com>
 <SR0H3srVA5CiCcbxL5dHeK2HIJFYvOqZKf0avpuncGU=.dbf27ec1-5455-40b3-aeb2-46d3cb5fbb19@github.com>
 <twz6ptVD0WsinSvvMzp6GGMOjwTotBb0RX9SiGtMnIo=.61a1c3c2-b5ab-4187-b400-2a2da23da7dc@github.com>
Message-ID: <e4n4KngV0o9BKs35YN5VO00Qb17NbN0O5lXtA5E_VPo=.a5c8e3ab-2f12-4dfd-ab9d-1e850f935a73@github.com>

On Fri, 17 Mar 2023 04:53:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> See the function log_dependency()
>> 
>> https://github.com/openjdk/jdk/blob/421b4ee33c652cc7c444fbbf298bbc23d052c2fe/src/hotspot/share/code/dependencies.cpp#L845
>> 
>> called from here (as one place).
>> 
>> https://github.com/openjdk/jdk/blob/421b4ee33c652cc7c444fbbf298bbc23d052c2fe/src/hotspot/share/code/dependencies.cpp#L2071
>> 
>> When TraceDependencies was true, the log file would be non-null and log_dependency would write to it.  Keeping this with -Xlog:dependencies=debug retains what TraceDependencies did.
>
> Hmmm this seems broken to me then. We output the general dependency logging to one place based on UL configuration, but then we output `log_dependency` to the log file. If these are meant to be related and always reported together then we have lost that. If they are actually unrelated then this may still need the TraceDependencies flag to control it.
> 
> @iwanowww can you comment on this please?

Maybe we don't need this -Xlog test in this place, because this is also what PrintDependencies does.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13007#discussion_r1143368172

From smonteith at openjdk.org  Tue Mar 21 13:34:40 2023
From: smonteith at openjdk.org (Stuart Monteith)
Date: Tue, 21 Mar 2023 13:34:40 GMT
Subject: RFR: JDK-8301493: Replace NULL with nullptr in cpu/aarch64
In-Reply-To: <w-lD1p2l43LSAIW8aEkX7VPahixuz0pe7vuzBnOre70=.1fd9d59f-1b9f-4c45-ab04-f1e1638c350c@github.com>
References: <w-lD1p2l43LSAIW8aEkX7VPahixuz0pe7vuzBnOre70=.1fd9d59f-1b9f-4c45-ab04-f1e1638c350c@github.com>
Message-ID: <-ZV05tb2xNWIBcGc7Nj_TZ6qq3BGrsjlKCT48_GTmQU=.6480f4f9-f1a5-47fa-94d9-51d3968ff711@github.com>

On Tue, 31 Jan 2023 11:39:27 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory cpu/aarch64. Unfortunately the script that does the change isn't perfect, and so we
> need to comb through these manually to make sure nothing has gone wrong. I also review these changes but things slip past my eyes sometimes.
> 
> Here are some typical things to look out for:
> 
> 1. No changes but copyright header changed (probably because I reverted some changes but forgot the copyright).
> 2. Macros having their NULL changed to nullptr, these are added to the script when I find them. They should be NULL.
> 3. nullptr in comments and logs. We try to use lower case "null" in these cases as it reads better. An exception is made when code expressions are in a comment.
> 
> An example of this:
> 
> ```c++
> // This function returns null
> void* ret_null();
> // This function returns true if *x == nullptr
> bool is_nullptr(void** x);
> 
> 
> Note how `nullptr` participates in a code expression here, we really are talking about the specific value `nullptr`.
> 
> Thanks!

This looks OK so far. 
However, is it your intention to also do aarch64.ad?
aarch64_ad.m4 and aarch64_vector(.ad|_ad.m4) files look clean.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12321#issuecomment-1477844415

From pminborg at openjdk.org  Tue Mar 21 13:39:05 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 21 Mar 2023 13:39:05 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v5]
In-Reply-To: <MtnTWtmtdQkU0RqBSp7DuSnQz0OO8Bk3HzJi7NHZDoU=.bc0c0f9f-454a-484d-9613-95b00f5af7ca@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <MtnTWtmtdQkU0RqBSp7DuSnQz0OO8Bk3HzJi7NHZDoU=.bc0c0f9f-454a-484d-9613-95b00f5af7ca@github.com>
Message-ID: <hw0KAH255Qgpaf9TWe72S7DBFDPLju7BjAZo6Cnh7q0=.e4ce764d-37db-40c4-83bf-96705c0c80a1@github.com>

On Tue, 21 Mar 2023 09:02:29 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> API changes for the FFM API (third preview)
>> 
>> Specdiff:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
>> 
>> Javadoc:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add example for Option::captureStateLayout

A review of all the copyright years shall be made in this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13079#issuecomment-1477849414

From matsaave at openjdk.org  Tue Mar 21 14:49:54 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 21 Mar 2023 14:49:54 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v9]
In-Reply-To: <D2-FZhAAt_mlmHeq6yf1weJku-AF7D01R1nihd7_pXo=.49229406-5e0e-4ba6-ae52-f9c80a6038db@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <W69abHEQZctZeg7QaoW9DFPWPhSNAL3PHMZABD3xLWU=.9e63f600-be6d-4258-991e-4b609be33f0a@github.com>
 <D2-FZhAAt_mlmHeq6yf1weJku-AF7D01R1nihd7_pXo=.49229406-5e0e-4ba6-ae52-f9c80a6038db@github.com>
Message-ID: <wuwkmeeHjasmB0LFu4aGmQotqyr6LwIZGF46JjIN6ag=.df667bc7-1192-42b5-b2de-5866b93e8be1@github.com>

On Tue, 21 Mar 2023 10:51:08 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix riscv interpreter mistake and acquire semantics
>
> src/hotspot/cpu/aarch64/templateTable_aarch64.cpp line 2399:
> 
>> 2397:                                                bool is_invokevirtual,
>> 2398:                                                bool is_invokevfinal, /*unused*/
>> 2399:                                                bool is_invokedynamic /*unused*/) {
> 
> Suggestion:
> 
>                                                bool /*is_invokedynamic*/) {

This is a temporary bandaid in the same format we see for `is_invokefinal`, both of which should be cleaned up once all the ports are complete.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12778#discussion_r1143508140

From qamai at openjdk.org  Tue Mar 21 16:16:34 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 21 Mar 2023 16:16:34 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v2]
In-Reply-To: <lmW05NgITkLuyzWlWENcX_wEhObY5BRk6L-JyK4LfVg=.817c80e5-92ac-4b9b-9001-1ff1d97a38a4@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
 <lmW05NgITkLuyzWlWENcX_wEhObY5BRk6L-JyK4LfVg=.817c80e5-92ac-4b9b-9001-1ff1d97a38a4@github.com>
Message-ID: <zkYQ_5LR47PqQ8nV7TZefUlWENFR-ZHvQx5LWWDhc4E=.b3217ca6-695e-45b2-a748-aa855ac05904@github.com>

On Sun, 19 Mar 2023 19:38:04 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, VectorShuffle is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
>> 
>> 1. Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
>> 2. Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
>> 3. Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
>> 4. Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
>> 
>> Upon these changes, a `rearrange` can emit more efficient code:
>> 
>>     var species = IntVector.SPECIES_128;
>>     var v1 = IntVector.fromArray(species, SRC1, 0);
>>     var v2 = IntVector.fromArray(species, SRC2, 0);
>>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
>> 
>>     Before:
>>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>>     vmovdqu 0x10(%r10),%xmm0
>>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>>                                                             ;   {external_word}
>>     vpackusdw %xmm0,%xmm0,%xmm0
>>     vpackuswb %xmm0,%xmm0,%xmm0
>>     vpmovsxbd %xmm0,%xmm3
>>     vpcmpgtd %xmm3,%xmm1,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fc2acb4e0d8
>>     vpmovzxbd %xmm0,%xmm0
>>     vpermd %ymm2,%ymm0,%ymm0
>>     movabs $0x751588f98,%r10            ;   {oop([I{0x0000000751588f98})}
>>     vmovdqu %xmm0,0x10(%r10)
>> 
>>     After:
>>     movabs $0x751589c78,%r10            ;   {oop([I{0x0000000751589c78})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158ac88,%r10            ;   {oop([I{0x000000075158ac88})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     vpxor  %xmm0,%xmm0,%xmm0
>>     vpcmpgtd %xmm2,%xmm0,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fa818b27cb1
>>     vpermd %ymm1,%ymm2,%ymm0
>>     movabs $0x751588c68,%r10            ;   {oop([I{0x0000000751588c68})}
>>     vmovdqu %xmm0,0x10(%r10)
>>     
>> Please take a look and leave reviews. Thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix Matcher::vector_needs_load_shuffle

Yes I will try to polish the patch more after finding the cause of the failure in x86_32. The failure is strange, though, it does not occur on x86_64 for some reasons.

> One annoyance in the API which propagates down into the implementation is `VectorShuffle<E>` and `VectorMask<E>` have `E` that is the lane element type.

Yes I agree, a shuffle merely contains the lane indices while a mask is an array of boolean, it would be a good cleanup to remove `E` from the interface.

> However, i don't have a good sense of the implications this has to the current HotSpot implementation and whether it is feasible.

Note that generics are erased, so from the VM point of view, a `VectorMask<E>` and a `VectorMask` is indifferent. As a result, removing the type parameter should not have any impact on the VM. Some details may have to change though, as element types are removed, a mask or shuffle would only be validated in accordance to its length, and we need to insert a cast at use sites. The cast will be removed if it is actually the same species so there is little concern regarding the machine code emitted.

Thanks a lot.

I have moved most of the methods to `AbstractVector` and `AbstractShuffle`, I have to resort to raw types, though, since there seems to be no way to do the same with wild cards, and the generics mechanism is not powerful enough for things like `Vector<E.integral>`. The remaining failure seems to be related to [JDK-8304676](https://bugs.openjdk.org/projects/JDK/issues/JDK-8304676), so I think this patch is ready for review now.

> The mask implementation is specialized by the species of vectors it operates on, but does it have to be

Apart from the mask implementation, shuffle implementation definitely has to take into consideration the element type. However, this information does not have to be visible to the API, similar to how we currently handle the vector length, we can have `class AbstractMask<E> implements VectorMask`. As a result, the cast method would be useless and can be removed in the API, but our implementation details would still use it, for example

    Vector<E> blend(Vector<E> v, VectorMask w) {
        AbstractMask<?> aw = (AbstractMask<?>) w;
        AbstractMask<E> tw = aw.cast(vspecies());
        return VectorSupport.blend(...);
    }

    Vector<E> rearrange(VectorShuffle s) {
        AbstractShuffle<?> as = (AbstractShuffle<?>) s;
        AbstractShuffle<E> ts = s.cast(vspecies());
        return VectorSupport.rearrangeOp(...);
    }

What do you think?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13093#issuecomment-1477581887
PR Comment: https://git.openjdk.org/jdk/pull/13093#issuecomment-1478140557

From psandoz at openjdk.org  Tue Mar 21 16:16:35 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 21 Mar 2023 16:16:35 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v2]
In-Reply-To: <zkYQ_5LR47PqQ8nV7TZefUlWENFR-ZHvQx5LWWDhc4E=.b3217ca6-695e-45b2-a748-aa855ac05904@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
 <lmW05NgITkLuyzWlWENcX_wEhObY5BRk6L-JyK4LfVg=.817c80e5-92ac-4b9b-9001-1ff1d97a38a4@github.com>
 <zkYQ_5LR47PqQ8nV7TZefUlWENFR-ZHvQx5LWWDhc4E=.b3217ca6-695e-45b2-a748-aa855ac05904@github.com>
Message-ID: <5WEC6Qqt9dnLkrD7AlIXjAImDgYtcUgvQlR3acn1oi0=.96d3caf3-a2b9-4491-b2ba-a9d04f658772@github.com>

On Tue, 21 Mar 2023 10:18:19 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Note that generics are erased, so from the VM point of view, a `VectorMask<E>` and a `VectorMask` is indifferent.

Yes, that's the easy bit :-) The mask implementation is specialized by the species of vectors it operates on, but does it have to be and can we make it independent of the species and bind to the lane count? 

Then the user does not need to explicitly cast from and to species that have the same lane count, which means we can remove the VectorMask::cast method (since it already throws if the lane counts are not equal).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13093#issuecomment-1478069401

From qamai at openjdk.org  Tue Mar 21 16:16:31 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 21 Mar 2023 16:16:31 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v3]
In-Reply-To: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
Message-ID: <4Op0Z8whnyDXDC6zGyMbx4ugcZp5TEoAqW_myB5flxM=.1c7b59ba-efb2-4f68-90d7-2d6e33e39572@github.com>

> Hi,
> 
> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, VectorShuffle is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
> 
> 1. Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
> 2. Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
> 3. Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
> 4. Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
> 
> Upon these changes, a `rearrange` can emit more efficient code:
> 
>     var species = IntVector.SPECIES_128;
>     var v1 = IntVector.fromArray(species, SRC1, 0);
>     var v2 = IntVector.fromArray(species, SRC2, 0);
>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
> 
>     Before:
>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>     vmovdqu 0x10(%r10),%xmm2
>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>     vmovdqu 0x10(%r10),%xmm1
>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>     vmovdqu 0x10(%r10),%xmm0
>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>                                                             ;   {external_word}
>     vpackusdw %xmm0,%xmm0,%xmm0
>     vpackuswb %xmm0,%xmm0,%xmm0
>     vpmovsxbd %xmm0,%xmm3
>     vpcmpgtd %xmm3,%xmm1,%xmm3
>     vtestps %xmm3,%xmm3
>     jne    0x00007fc2acb4e0d8
>     vpmovzxbd %xmm0,%xmm0
>     vpermd %ymm2,%ymm0,%ymm0
>     movabs $0x751588f98,%r10            ;   {oop([I{0x0000000751588f98})}
>     vmovdqu %xmm0,0x10(%r10)
> 
>     After:
>     movabs $0x751589c78,%r10            ;   {oop([I{0x0000000751589c78})}
>     vmovdqu 0x10(%r10),%xmm1
>     movabs $0x75158ac88,%r10            ;   {oop([I{0x000000075158ac88})}
>     vmovdqu 0x10(%r10),%xmm2
>     vpxor  %xmm0,%xmm0,%xmm0
>     vpcmpgtd %xmm2,%xmm0,%xmm3
>     vtestps %xmm3,%xmm3
>     jne    0x00007fa818b27cb1
>     vpermd %ymm1,%ymm2,%ymm0
>     movabs $0x751588c68,%r10            ;   {oop([I{0x0000000751588c68})}
>     vmovdqu %xmm0,0x10(%r10)
>     
> Please take a look and leave reviews. Thanks a lot.

Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision:

 - missing casts
 - clean up

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13093/files
  - new: https://git.openjdk.org/jdk/pull/13093/files/060554a9..4caa9d10

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13093&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13093&range=01-02

  Stats: 1396 lines in 36 files changed: 44 ins; 1339 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/13093.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13093/head:pull/13093

PR: https://git.openjdk.org/jdk/pull/13093

From psandoz at openjdk.org  Tue Mar 21 16:16:33 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 21 Mar 2023 16:16:33 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v2]
In-Reply-To: <lmW05NgITkLuyzWlWENcX_wEhObY5BRk6L-JyK4LfVg=.817c80e5-92ac-4b9b-9001-1ff1d97a38a4@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
 <lmW05NgITkLuyzWlWENcX_wEhObY5BRk6L-JyK4LfVg=.817c80e5-92ac-4b9b-9001-1ff1d97a38a4@github.com>
Message-ID: <34zcCpLdmLg_1qtY5maOBw5ozxupQlkKPOf3Kzljybc=.d995b7c1-6ad0-4af4-9bc3-bf6cda45d274@github.com>

On Sun, 19 Mar 2023 19:38:04 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, VectorShuffle is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
>> 
>> 1. Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
>> 2. Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
>> 3. Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
>> 4. Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
>> 
>> Upon these changes, a `rearrange` can emit more efficient code:
>> 
>>     var species = IntVector.SPECIES_128;
>>     var v1 = IntVector.fromArray(species, SRC1, 0);
>>     var v2 = IntVector.fromArray(species, SRC2, 0);
>>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
>> 
>>     Before:
>>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>>     vmovdqu 0x10(%r10),%xmm0
>>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>>                                                             ;   {external_word}
>>     vpackusdw %xmm0,%xmm0,%xmm0
>>     vpackuswb %xmm0,%xmm0,%xmm0
>>     vpmovsxbd %xmm0,%xmm3
>>     vpcmpgtd %xmm3,%xmm1,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fc2acb4e0d8
>>     vpmovzxbd %xmm0,%xmm0
>>     vpermd %ymm2,%ymm0,%ymm0
>>     movabs $0x751588f98,%r10            ;   {oop([I{0x0000000751588f98})}
>>     vmovdqu %xmm0,0x10(%r10)
>> 
>>     After:
>>     movabs $0x751589c78,%r10            ;   {oop([I{0x0000000751589c78})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158ac88,%r10            ;   {oop([I{0x000000075158ac88})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     vpxor  %xmm0,%xmm0,%xmm0
>>     vpcmpgtd %xmm2,%xmm0,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fa818b27cb1
>>     vpermd %ymm1,%ymm2,%ymm0
>>     movabs $0x751588c68,%r10            ;   {oop([I{0x0000000751588c68})}
>>     vmovdqu %xmm0,0x10(%r10)
>>     
>> Please take a look and leave reviews. Thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix Matcher::vector_needs_load_shuffle

That looks like a very good simplification and performance enhancement, and removing a limitation, the byte[] representation. This should likely also help with Valhalla integration.

IIUC it has the same upper bound limitation for vector lengths greater than the maximum index size that can be represented as a lane element (although in practice there may not be any hardware where this can occur). Which is fine, i am not suggesting we try and fix this.

Perhaps it may be possible to move some methods on the concrete implementations to the abstract implementations as helper methods or template methods, thereby reducing the amount of generated code? It seems so in some cases, but i did not look very closely. It may require the introduction of an an element type specific abstract shuffle, and if that's the case it may not be worth it.

--

Relatedly, i would be interested in your opinion on the following. One annoyance in the API which propagates down into the implementation is `VectorShuffle<E>` and `VectorMask<E>` have `E` that is the lane element type. But, in theory they should not need E, and any shuffle or mask with the same lanes as the vector being operated on should be compatible, and it's an implementation detail of the shuffle/mask how its state represented as a hardware register. However, i don't have a good sense of the implications this has to the current HotSpot implementation and whether it is feasible.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13093#pullrequestreview-1349108003

From psandoz at openjdk.org  Tue Mar 21 16:17:07 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 21 Mar 2023 16:17:07 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v2]
In-Reply-To: <zkYQ_5LR47PqQ8nV7TZefUlWENFR-ZHvQx5LWWDhc4E=.b3217ca6-695e-45b2-a748-aa855ac05904@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
 <lmW05NgITkLuyzWlWENcX_wEhObY5BRk6L-JyK4LfVg=.817c80e5-92ac-4b9b-9001-1ff1d97a38a4@github.com>
 <zkYQ_5LR47PqQ8nV7TZefUlWENFR-ZHvQx5LWWDhc4E=.b3217ca6-695e-45b2-a748-aa855ac05904@github.com>
Message-ID: <RhlqpD3wr9sgVM1jc8hA8BUhARZYFpTJi2IPOEYsZKg=.bfeb66ce-de5a-4605-bbeb-9ca61de56e71@github.com>

On Tue, 21 Mar 2023 16:11:50 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> I have moved most of the methods to `AbstractVector` and `AbstractShuffle`, I have to resort to raw types, though, since there seems to be no way to do the same with wild cards, and the generics mechanism is not powerful enough for things like `Vector<E.integral>`. The remaining failure seems to be related to [JDK-8304676](https://bugs.openjdk.org/projects/JDK/issues/JDK-8304676), so I think this patch is ready for review now.

The Java changes look good to me. I need to have another look, but will not be able to do so until next week.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13093#issuecomment-1478148846

From psandoz at openjdk.org  Tue Mar 21 16:32:44 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 21 Mar 2023 16:32:44 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v2]
In-Reply-To: <zkYQ_5LR47PqQ8nV7TZefUlWENFR-ZHvQx5LWWDhc4E=.b3217ca6-695e-45b2-a748-aa855ac05904@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
 <lmW05NgITkLuyzWlWENcX_wEhObY5BRk6L-JyK4LfVg=.817c80e5-92ac-4b9b-9001-1ff1d97a38a4@github.com>
 <zkYQ_5LR47PqQ8nV7TZefUlWENFR-ZHvQx5LWWDhc4E=.b3217ca6-695e-45b2-a748-aa855ac05904@github.com>
Message-ID: <DAnlsKJ-3aNZZWnvP2j_J59dpX_wzor1IM6dY0bie1Q=.ddf68a3d-59bf-4108-959f-8dc50c095e45@github.com>

On Tue, 21 Mar 2023 16:11:50 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Apart from the mask implementation, shuffle implementation definitely has to take into consideration the element type.

Yes, the way you have implemented shuffle is tightly connected, that looks ok.

I am wondering if we can make the mask implementation more loosely coupled and modified such that it does not have to take into consideration the element type (or species) of the vector it operates on, and instead compatibility is based solely on the lane count.

Ideally it would be good to change the `VectorMask::check` method to just compare the lanes counts and not require a cast in the implementation, which i presume requires some deeper changes in C2?

What you propose seems a possible a interim step towards a more preferable API, if the performance is good.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13093#issuecomment-1478175761

From sviswanathan at openjdk.org  Tue Mar 21 16:53:49 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 21 Mar 2023 16:53:49 GMT
Subject: RFR: 8304301: Remove the global option SuperWordMaxVectorSize
In-Reply-To: <2XQwCCx_ficJ1bn2WX0Ud9m-QmuGkkZAH8N6yLugXqQ=.90a136da-db9a-49b4-a4c4-d6c644cf7d5a@github.com>
References: <2XQwCCx_ficJ1bn2WX0Ud9m-QmuGkkZAH8N6yLugXqQ=.90a136da-db9a-49b4-a4c4-d6c644cf7d5a@github.com>
Message-ID: <00uMDu5j39--5DfRMljtqUgU0DeBNdkBXDhTPgaEGI8=.866f24f0-b871-4fea-b5a7-62a376006054@github.com>

On Tue, 21 Mar 2023 02:26:55 GMT, Fei Gao <fgao at openjdk.org> wrote:

> https://github.com/openjdk/jdk/pull/8877 introduced the global option `SuperWordMaxVectorSize` as a temporary solution to fix the performance regression on some x86 machines.
> 
> Currently, `SuperWordMaxVectorSize` behaves differently between x86 and other platforms [1]. For example, if the current machine only supports `MaxVectorSize <= 32`, but we set `SuperWordMaxVectorSize = 64`, then `SuperWordMaxVectorSize` will be kept at 64 on other platforms while x86 machine would change `SuperWordMaxVectorSize` to `MaxVectorSize`. Other platforms except x86 miss similar implementations like [2].
> 
> Also, `SuperWordMaxVectorSize` limits the max vector size of auto-vectorization as `64`, which is fine for current aarch64 hardware, but SVE architecture supports larger than 512 bits.
> 
> The patch is to drop the global option and use an architecture-dependent interface to consult the max vector size for auto-vectorization, fixing the performance issue on x86 and reducing side effects for other platforms. After the patch, auto-vectorization is still limited to 32-byte vectors by default on Cascade Lake and users can override this by either setting
> `-XX:UseAVX=3` or `-XX:MaxVectorSize=64` on JVM command line.
> 
> So my question is:
> 
> Before the patch, we could have a smaller max vector size for auto-vectorization than `MaxVectorSize` on x86. For example, users could have `MaxVectorSize=64` and `SuperWordMaxVectorSize=32`. But after the change, if we set
> `-XX:MaxVectorSize=64` explicitly, then the max vector size for auto-vectorization would be `MaxVectorSize`, i.e. 64 bytes, which I believe is more reasonable. @sviswa7 @jatin-bhateja, are you happy about the change?
> 
> [1] https://github.com/openjdk/jdk/pull/12350#discussion_r1126106213
> [2] https://github.com/openjdk/jdk/blob/33bec207103acd520eb99afb093cfafa44aecfda/src/hotspot/cpu/x86/vm_version_x86.cpp#L1314-L1333

Looks good to me.

-------------

Marked as reviewed by sviswanathan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13112#pullrequestreview-1350975796

From jcking at openjdk.org  Tue Mar 21 16:54:37 2023
From: jcking at openjdk.org (Justin King)
Date: Tue, 21 Mar 2023 16:54:37 GMT
Subject: RFR: JDK-8304683: Memory leak in WB_IsMethodCompatible
Message-ID: <4V-_5ZAkbj0Kw1UsgBnat-JrwffKM_mHRNmWZwB3ox8=.94ce5e0d-9552-4a96-9bb1-8a3f26c2dd7f@github.com>

Add missing call to `DirectivesStack::release`.

-------------

Commit messages:
 - Fix memory leak in WB_IsMethodCompatible

Changes: https://git.openjdk.org/jdk/pull/13124/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13124&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304683
  Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13124.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13124/head:pull/13124

PR: https://git.openjdk.org/jdk/pull/13124

From rrich at openjdk.org  Tue Mar 21 17:04:56 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Tue, 21 Mar 2023 17:04:56 GMT
Subject: RFR: 8296440: Remove Method* handling from
 cleanup_inline_caches_impl [v3]
In-Reply-To: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
References: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
Message-ID: <Jl4636WaRF28mQZl6gK1Q4a44CyRJLX-2X3N5RPeKd0=.e4d9606d-c027-419a-b977-ce60e4487a79@github.com>

> This PR replaces cleaning of static stubs in CompiledMethod::cleanup_inline_caches_impl() with a guarantee that it is actually not needed because the holder of the embedded target Method* is alive if the caller nmethod is not unloading.
> 
> The holder of the target Method* has to be alive because it is reachable from the caller nmethod's oop pool. This is checked by `check_path_to_callee()` when a statically bound call gets resolved.
> 
> C2i entry barriers can be removed for the same reason.
> 
> Testing:
> 
> Many rounds in our CI testing which includes most JCK and JTREG tests, Renaissance benchmark and SAP specific tests with fastdebug and release builds on the standard platforms plus PPC64.
> 
> I've also done tier1 and tier2 tests with -XX:-Inline and tier1 tests with ZGC.
> 
> I've started hotspot and jdk tier1 tests with -Xcomp. They were not finished when I stopped them after 24h.

Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision:

  Feedback Coleene

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12802/files
  - new: https://git.openjdk.org/jdk/pull/12802/files/876e55dc..2c2e49b5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12802&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12802&range=01-02

  Stats: 60 lines in 4 files changed: 10 ins; 31 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/12802.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12802/head:pull/12802

PR: https://git.openjdk.org/jdk/pull/12802

From rrich at openjdk.org  Tue Mar 21 17:09:14 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Tue, 21 Mar 2023 17:09:14 GMT
Subject: RFR: 8296440: Remove Method* handling from
 cleanup_inline_caches_impl [v3]
In-Reply-To: <Sc3IEKtrtDeddp3JO32ToY-vjVLzQKRptszRDyP1EHI=.68fd28b3-a714-46d4-bf78-c39ffb8aa073@github.com>
References: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
 <BQbYsHfh5ZsQ_E1uIUnc9MLg3EgQ_BvW8RZfjMvgaLU=.556e1591-02d1-4073-8924-778fe1866bad@github.com>
 <Sc3IEKtrtDeddp3JO32ToY-vjVLzQKRptszRDyP1EHI=.68fd28b3-a714-46d4-bf78-c39ffb8aa073@github.com>
Message-ID: <6ohmVBWgkqo_3T0rc-5WMxp8eTdGAULDUT6kCCr773I=.877fe53a-7eec-48d7-89a8-17974fd2a335@github.com>

On Mon, 20 Mar 2023 18:38:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Feedback Coleene
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 4308:
> 
>> 4306: void MacroAssembler::load_method_holder_cld(Register rresult, Register rmethod) {
>> 4307:   load_method_holder(rresult, rmethod);
>> 4308:   ldr(rresult, Address(rresult, InstanceKlass::class_loader_data_offset()));
> 
> Can you remove InstanceKlass::klass_loader_data_offset() also?

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12802#discussion_r1143732838

From rrich at openjdk.org  Tue Mar 21 17:09:21 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Tue, 21 Mar 2023 17:09:21 GMT
Subject: RFR: 8296440: Remove Method* handling from
 cleanup_inline_caches_impl [v2]
In-Reply-To: <Sc3IEKtrtDeddp3JO32ToY-vjVLzQKRptszRDyP1EHI=.68fd28b3-a714-46d4-bf78-c39ffb8aa073@github.com>
References: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
 <BQbYsHfh5ZsQ_E1uIUnc9MLg3EgQ_BvW8RZfjMvgaLU=.556e1591-02d1-4073-8924-778fe1866bad@github.com>
 <Sc3IEKtrtDeddp3JO32ToY-vjVLzQKRptszRDyP1EHI=.68fd28b3-a714-46d4-bf78-c39ffb8aa073@github.com>
Message-ID: <ftJC97iUsj7eWpmjPhGJumXiXJECj_DySuuIuqIjDoY=.19a1f33b-547a-440d-8c92-98842f34a8a0@github.com>

On Mon, 20 Mar 2023 18:57:25 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Richard Reingruber 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:
>> 
>>  - Adding TestStaticallyBoundTargetIsReachable.java
>>  - Path to target exists also if the receiver is a constant of the caller
>>  - Use nmethod::oops_do() to search for to_holder in from_nm
>>  - Merge branch 'master'
>>  - Remove MacroAssembler::resolve_weak_handle()
>>  - Remove keep_alive_offset() and holder_offset() from CLD
>>  - Remove MacroAssembler::load_method_holder_cld()
>>  - Remove c2i entry barrier
>>  - Check dependency for statically bound call
>
> src/hotspot/share/runtime/sharedRuntime.cpp line 1354:
> 
>> 1352: }
>> 1353: 
>> 1354: class Search2OopsClosure : public OopClosure {
> 
> Should this all be under #ifdef ASSERT?

Yes. I'll do that before the pr gets integrated.
I want to make sure all dependencies are present also in the release build.
(E.g. before JDK-8299155 was fixed the debug vm produced more dependencies)

> src/hotspot/share/runtime/sharedRuntime.cpp line 1418:
> 
>> 1416:         return; // `to` is reachable by iterating parents of `from`
>> 1417:       }
>> 1418:     }
> 
> I'd be happier if this part was a function in ClassLoaderData or refactored from record_dependency (along with the constains function).  Since it's similar code.

You are right. I've done the refactoring. Please let me know what you think.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12802#discussion_r1143738349
PR Review Comment: https://git.openjdk.org/jdk/pull/12802#discussion_r1143739466

From coleenp at openjdk.org  Tue Mar 21 17:12:00 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 21 Mar 2023 17:12:00 GMT
Subject: RFR: 8304089: Convert TraceDependencies to UL [v5]
In-Reply-To: <0aGc1NdAjpvksCWmXb1gZOPp9MV0n6xWvG8EaEp2ZLg=.b79cf218-9a23-420d-bec5-7509b7f8f1c1@github.com>
References: <0aGc1NdAjpvksCWmXb1gZOPp9MV0n6xWvG8EaEp2ZLg=.b79cf218-9a23-420d-bec5-7509b7f8f1c1@github.com>
Message-ID: <iy21P3-_eQnuA6cuPbMkGhFpZoeHJf4vuSrCQ-ScRdU=.c9246e41-996d-472e-9b92-5569835e4c7d@github.com>

> This change converts TraceDependencies to UL and removes the develop option. I think this provides further flexibility to add tags to only trace certain things in dependency analysis, as I did when trying to understand a PR for a deoptimization change.  For now, the messages are the same and the option is -Xlog:dependencies=debug.
> Tested with tier1-4

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Drop UL check for log file output (still have PrintDependencies).

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13007/files
  - new: https://git.openjdk.org/jdk/pull/13007/files/421b4ee3..c078451b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13007&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13007&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13007.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13007/head:pull/13007

PR: https://git.openjdk.org/jdk/pull/13007

From vlivanov at openjdk.org  Tue Mar 21 17:12:03 2023
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 21 Mar 2023 17:12:03 GMT
Subject: RFR: 8304089: Convert TraceDependencies to UL [v3]
In-Reply-To: <e4n4KngV0o9BKs35YN5VO00Qb17NbN0O5lXtA5E_VPo=.a5c8e3ab-2f12-4dfd-ab9d-1e850f935a73@github.com>
References: <0aGc1NdAjpvksCWmXb1gZOPp9MV0n6xWvG8EaEp2ZLg=.b79cf218-9a23-420d-bec5-7509b7f8f1c1@github.com>
 <BQzDwBUOHbm1v3Ex5uAT56pIQJtoT8ON4ZmFhi3TvR0=.ce86f07b-4136-4870-93f0-c9723c80795b@github.com>
 <13yGfFhRFEsjHA-ox_6GxPiyU8w_hpQtgjHbsw6Glq0=.c2330c3f-0316-4f4c-aade-b6ad6c8543ee@github.com>
 <tLhX6beNey8aikbBH30RbCu7lfXZ9AWG2KYqKWVvnkw=.a41fbeb0-6c04-4b6a-824a-fc9fdf734fd2@github.com>
 <2IKS8cYMhoU1JRBEalwF1ZeV4Vih78eXffu_GXZ4JkQ=.27d433ac-1f04-47ce-a177-c791a42bc6fe@github.com>
 <SR0H3srVA5CiCcbxL5dHeK2HIJFYvOqZKf0avpuncGU=.dbf27ec1-5455-40b3-aeb2-46d3cb5fbb19@github.com>
 <twz6ptVD0WsinSvvMzp6GGMOjwTotBb0RX9SiGtMnIo=.61a1c3c2-b5ab-4187-b400-2a2da23da7dc@github.com>
 <e4n4KngV0o9BKs35YN5VO00Qb17NbN0O5lXtA5E_VPo=.a5c8e3ab-2f12-4dfd-ab9d-1e850f935a73@github.com>
Message-ID: <ETOGG2mpBq4B3Coqz2qkUcxotsa65klRYWp7fj6tczo=.9f12cd5f-a93b-4e22-869c-5cb43d4a0ba7@github.com>

On Tue, 21 Mar 2023 13:24:03 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Hmmm this seems broken to me then. We output the general dependency logging to one place based on UL configuration, but then we output `log_dependency` to the log file. If these are meant to be related and always reported together then we have lost that. If they are actually unrelated then this may still need the TraceDependencies flag to control it.
>> 
>> @iwanowww can you comment on this please?
>
> Maybe we don't need this -Xlog test in this place, because this is also what PrintDependencies does.

Yes, UL check doesn't help here. Irrespective of the check, UL output isn't automatically placed in VM log.
It's convenient for LogCompilation to have VM output along with other VM events present in the log. 
Having said that, I'm fine with dropping TraceDependencies check here and improve the interaction between UL and LogVMOutput separately.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13007#discussion_r1143727768

From coleenp at openjdk.org  Tue Mar 21 17:12:04 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 21 Mar 2023 17:12:04 GMT
Subject: RFR: 8304089: Convert TraceDependencies to UL [v3]
In-Reply-To: <ETOGG2mpBq4B3Coqz2qkUcxotsa65klRYWp7fj6tczo=.9f12cd5f-a93b-4e22-869c-5cb43d4a0ba7@github.com>
References: <0aGc1NdAjpvksCWmXb1gZOPp9MV0n6xWvG8EaEp2ZLg=.b79cf218-9a23-420d-bec5-7509b7f8f1c1@github.com>
 <BQzDwBUOHbm1v3Ex5uAT56pIQJtoT8ON4ZmFhi3TvR0=.ce86f07b-4136-4870-93f0-c9723c80795b@github.com>
 <13yGfFhRFEsjHA-ox_6GxPiyU8w_hpQtgjHbsw6Glq0=.c2330c3f-0316-4f4c-aade-b6ad6c8543ee@github.com>
 <tLhX6beNey8aikbBH30RbCu7lfXZ9AWG2KYqKWVvnkw=.a41fbeb0-6c04-4b6a-824a-fc9fdf734fd2@github.com>
 <2IKS8cYMhoU1JRBEalwF1ZeV4Vih78eXffu_GXZ4JkQ=.27d433ac-1f04-47ce-a177-c791a42bc6fe@github.com>
 <SR0H3srVA5CiCcbxL5dHeK2HIJFYvOqZKf0avpuncGU=.dbf27ec1-5455-40b3-aeb2-46d3cb5fbb19@github.com>
 <twz6ptVD0WsinSvvMzp6GGMOjwTotBb0RX9SiGtMnIo=.61a1c3c2-b5ab-4187-b400-2a2da23da7dc@github.com>
 <e4n4KngV0o9BKs35YN5VO00Qb17NbN0O5lXtA5E_VPo=.a5c8e3ab-2f12-4dfd-ab9d-1e850f935a73@github.com>
 <ETOGG2mpBq4B3Coqz2qkUcxotsa65klRYWp7fj6tczo=.9f12cd5f-a93b-4e22-869c-5cb43d4a0ba7@github.com>
Message-ID: <LZaPlS8eS08dRij8ZPjw2qxZ17FmKHB18FlSMVc5gj0=.a02fc417-e409-4974-8e84-444166a697c0@github.com>

On Tue, 21 Mar 2023 17:01:21 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Maybe we don't need this -Xlog test in this place, because this is also what PrintDependencies does.
>
> Yes, UL check doesn't help here. Irrespective of the check, UL output isn't automatically placed in VM log.
> It's convenient for LogCompilation to have VM output along with other VM events present in the log. 
> Having said that, I'm fine with dropping TraceDependencies check here and improve the interaction between UL and LogVMOutput separately.

Okay thank you.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13007#discussion_r1143734101

From rrich at openjdk.org  Tue Mar 21 17:16:38 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Tue, 21 Mar 2023 17:16:38 GMT
Subject: RFR: 8296440: Remove Method* handling from
 cleanup_inline_caches_impl [v2]
In-Reply-To: <Sc3IEKtrtDeddp3JO32ToY-vjVLzQKRptszRDyP1EHI=.68fd28b3-a714-46d4-bf78-c39ffb8aa073@github.com>
References: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
 <BQbYsHfh5ZsQ_E1uIUnc9MLg3EgQ_BvW8RZfjMvgaLU=.556e1591-02d1-4073-8924-778fe1866bad@github.com>
 <Sc3IEKtrtDeddp3JO32ToY-vjVLzQKRptszRDyP1EHI=.68fd28b3-a714-46d4-bf78-c39ffb8aa073@github.com>
Message-ID: <yqkoY50q5Kc99kMBQmRu0TtIT6hTjzkUil3KSCJ4xsE=.39bb66e7-3c92-4890-9bad-50a2ec56ffc5@github.com>

On Mon, 20 Mar 2023 19:01:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I don't really know if this is right but some comments anyway.

Thanks for looking at this and for giving feedback.

> src/hotspot/share/classfile/classLoaderData.cpp line 791:
> 
>> 789: 
>> 790: bool ClassLoaderData::handles_contain(oop obj) {
>> 791:   return _handles.contains(obj);
> 
> This might need to be protected by a metaspace_lock.

I though it was not needed.
Looks like `ChunkedHandleList` supports unsynchronized reading. We might not see all the handles recently added without locking but we are guaranteed to see the handles that were added by resolving the call we are checking.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12802#issuecomment-1478287839
PR Review Comment: https://git.openjdk.org/jdk/pull/12802#discussion_r1143745849

From vlivanov at openjdk.org  Tue Mar 21 17:24:50 2023
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 21 Mar 2023 17:24:50 GMT
Subject: RFR: 8304089: Convert TraceDependencies to UL [v5]
In-Reply-To: <iy21P3-_eQnuA6cuPbMkGhFpZoeHJf4vuSrCQ-ScRdU=.c9246e41-996d-472e-9b92-5569835e4c7d@github.com>
References: <0aGc1NdAjpvksCWmXb1gZOPp9MV0n6xWvG8EaEp2ZLg=.b79cf218-9a23-420d-bec5-7509b7f8f1c1@github.com>
 <iy21P3-_eQnuA6cuPbMkGhFpZoeHJf4vuSrCQ-ScRdU=.c9246e41-996d-472e-9b92-5569835e4c7d@github.com>
Message-ID: <jqMyv0dircjlFT4NACAvPYj0SoB60tP0qxdVVHWYeAY=.74c702f2-a293-4167-97eb-82e372def969@github.com>

On Tue, 21 Mar 2023 17:12:00 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change converts TraceDependencies to UL and removes the develop option. I think this provides further flexibility to add tags to only trace certain things in dependency analysis, as I did when trying to understand a PR for a deoptimization change.  For now, the messages are the same and the option is -Xlog:dependencies=debug.
>> Tested with tier1-4
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Drop UL check for log file output (still have PrintDependencies).

Marked as reviewed by vlivanov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13007#pullrequestreview-1351042944

From rrich at openjdk.org  Tue Mar 21 17:43:57 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Tue, 21 Mar 2023 17:43:57 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v9]
In-Reply-To: <D2-FZhAAt_mlmHeq6yf1weJku-AF7D01R1nihd7_pXo=.49229406-5e0e-4ba6-ae52-f9c80a6038db@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <W69abHEQZctZeg7QaoW9DFPWPhSNAL3PHMZABD3xLWU=.9e63f600-be6d-4258-991e-4b609be33f0a@github.com>
 <D2-FZhAAt_mlmHeq6yf1weJku-AF7D01R1nihd7_pXo=.49229406-5e0e-4ba6-ae52-f9c80a6038db@github.com>
Message-ID: <n6PYFvRxzvZ6l989wGMKEeQO15Ko2-hfku7f-obDnhE=.800e90dc-3e2c-4acb-a26a-84ccf9429253@github.com>

On Tue, 21 Mar 2023 10:49:32 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix riscv interpreter mistake and acquire semantics
>
> src/hotspot/cpu/aarch64/templateTable_aarch64.cpp line 2337:
> 
>> 2335:   // Load-acquire the adapter method
>> 2336:   __ lea(method, Address(cache, in_bytes(ResolvedIndyEntry::method_offset())));
>> 2337:   __ ldar(method, method);
> 
> What reordering are we trying to prevent here?

The loads of the data stored in `ResolvedIndyEntry::fill_in()` must not be reordered with loading  `ResolvedIndyEntry::_method`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12778#discussion_r1143781928

From qamai at openjdk.org  Tue Mar 21 18:15:44 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 21 Mar 2023 18:15:44 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v2]
In-Reply-To: <DAnlsKJ-3aNZZWnvP2j_J59dpX_wzor1IM6dY0bie1Q=.ddf68a3d-59bf-4108-959f-8dc50c095e45@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
 <lmW05NgITkLuyzWlWENcX_wEhObY5BRk6L-JyK4LfVg=.817c80e5-92ac-4b9b-9001-1ff1d97a38a4@github.com>
 <zkYQ_5LR47PqQ8nV7TZefUlWENFR-ZHvQx5LWWDhc4E=.b3217ca6-695e-45b2-a748-aa855ac05904@github.com>
 <DAnlsKJ-3aNZZWnvP2j_J59dpX_wzor1IM6dY0bie1Q=.ddf68a3d-59bf-4108-959f-8dc50c095e45@github.com>
Message-ID: <E113TLsukfe4hhiPvGG6yGUZDXru_LjqwS2lZS7CCTE=.a550504b-9da3-4fa5-84bd-95b916fe4ad0@github.com>

On Tue, 21 Mar 2023 16:29:44 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> I have moved most of the methods to `AbstractVector` and `AbstractShuffle`, I have to resort to raw types, though, since there seems to be no way to do the same with wild cards, and the generics mechanism is not powerful enough for things like `Vector<E.integral>`. The remaining failure seems to be related to [JDK-8304676](https://bugs.openjdk.org/projects/JDK/issues/JDK-8304676), so I think this patch is ready for review now.
>> 
>>> The mask implementation is specialized by the species of vectors it operates on, but does it have to be
>> 
>> Apart from the mask implementation, shuffle implementation definitely has to take into consideration the element type. However, this information does not have to be visible to the API, similar to how we currently handle the vector length, we can have `class AbstractMask<E> implements VectorMask`. As a result, the cast method would be useless and can be removed in the API, but our implementation details would still use it, for example
>> 
>>     Vector<E> blend(Vector<E> v, VectorMask w) {
>>         AbstractMask<?> aw = (AbstractMask<?>) w;
>>         AbstractMask<E> tw = aw.cast(vspecies());
>>         return VectorSupport.blend(...);
>>     }
>> 
>>     Vector<E> rearrange(VectorShuffle s) {
>>         AbstractShuffle<?> as = (AbstractShuffle<?>) s;
>>         AbstractShuffle<E> ts = s.cast(vspecies());
>>         return VectorSupport.rearrangeOp(...);
>>     }
>> 
>> What do you think?
>
>> Apart from the mask implementation, shuffle implementation definitely has to take into consideration the element type.
> 
> Yes, the way you have implemented shuffle is tightly connected, that looks ok.
> 
> I am wondering if we can make the mask implementation more loosely coupled and modified such that it does not have to take into consideration the element type (or species) of the vector it operates on, and instead compatibility is based solely on the lane count.
> 
> Ideally it would be good to change the `VectorMask::check` method to just compare the lanes counts and not require a cast in the implementation, which i presume requires some deeper changes in C2?
> 
> What you propose seems a possible a interim step towards a more preferable API, if the performance is good.

@PaulSandoz As some hardware does differentiate masks based on element type, at some point we have to differentiate between them. From a design point of view, they are both implementation details so there might be no consideration regarding the API. On the other hand, having more in the Java side seems to be more desirable, as it does illustrate the operations more intuitively compared to the graph management in C2. Another important point I can think of is that having a constant shape for a Java class would help us in implementing the vector calling convention, as we can rely on the class information instead of some side channels. As a result, I think I do prefer the current class hierarchy.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13093#issuecomment-1478374992

From matsaave at openjdk.org  Tue Mar 21 20:01:44 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 21 Mar 2023 20:01:44 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v10]
In-Reply-To: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
Message-ID: <sdwxYCKZZL6YqzUZ2KE_ap4ss5Rtb-1Nuyg53bDy-T0=.2293ce4a-b8db-4d1b-8cd8-9951be0a5fb8@github.com>

> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
> 
> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
> 
> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
> 
> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
> 
> This change supports the following platforms: x86, aarch64, PPC, and RISCV

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  Consistent register naming for aarch64

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12778/files
  - new: https://git.openjdk.org/jdk/pull/12778/files/8607f62a..cbe4fdcb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12778&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12778&range=08-09

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12778.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12778/head:pull/12778

PR: https://git.openjdk.org/jdk/pull/12778

From smonteith at openjdk.org  Tue Mar 21 20:47:43 2023
From: smonteith at openjdk.org (Stuart Monteith)
Date: Tue, 21 Mar 2023 20:47:43 GMT
Subject: RFR: JDK-8301493: Replace NULL with nullptr in cpu/aarch64
In-Reply-To: <w-lD1p2l43LSAIW8aEkX7VPahixuz0pe7vuzBnOre70=.1fd9d59f-1b9f-4c45-ab04-f1e1638c350c@github.com>
References: <w-lD1p2l43LSAIW8aEkX7VPahixuz0pe7vuzBnOre70=.1fd9d59f-1b9f-4c45-ab04-f1e1638c350c@github.com>
Message-ID: <M-bUtAatVdAbZ9wGhgh_-8MSIJPj5SO2F3MVWQE0nRA=.fccef8b6-0120-4d8f-9eb0-c8e29315a784@github.com>

On Tue, 31 Jan 2023 11:39:27 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory cpu/aarch64. Unfortunately the script that does the change isn't perfect, and so we
> need to comb through these manually to make sure nothing has gone wrong. I also review these changes but things slip past my eyes sometimes.
> 
> Here are some typical things to look out for:
> 
> 1. No changes but copyright header changed (probably because I reverted some changes but forgot the copyright).
> 2. Macros having their NULL changed to nullptr, these are added to the script when I find them. They should be NULL.
> 3. nullptr in comments and logs. We try to use lower case "null" in these cases as it reads better. An exception is made when code expressions are in a comment.
> 
> An example of this:
> 
> ```c++
> // This function returns null
> void* ret_null();
> // This function returns true if *x == nullptr
> bool is_nullptr(void** x);
> 
> 
> Note how `nullptr` participates in a code expression here, we really are talking about the specific value `nullptr`.
> 
> Thanks!

src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 270:

> 268:   virtual void pass_object() {
> 269:     intptr_t* addr = single_slot_addr();
> 270:     intptr_t value = *addr == 0 ? nullptr : (intptr_t)addr;

This doesn't compile - perhaps replace nullptr with zero? Unless casting it is more appropriate.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12321#discussion_r1143970163

From coleenp at openjdk.org  Tue Mar 21 21:43:34 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 21 Mar 2023 21:43:34 GMT
Subject: RFR: 8304687: Move add_to_hierarchy
Message-ID: <8lZkIOj_sW-s5fenIUyqOflXokTscrf8v6Zi6VOic4o=.847bbf8a-430b-46f5-a4c2-335d3355c320@github.com>

Moved SystemDictionary::add_to_hierarchy to InstanceKlass::add_to_hierarchy where it more logically belongs and next to other functions that also care about dependencies.
Tested with tier1-4, and tier1 on linux,windows,macos to check header file changes.

-------------

Commit messages:
 - 8304687: Move add_to_hierarchy

Changes: https://git.openjdk.org/jdk/pull/13129/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13129&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304687
  Stats: 98 lines in 7 files changed: 44 ins; 49 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/13129.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13129/head:pull/13129

PR: https://git.openjdk.org/jdk/pull/13129

From aph at openjdk.org  Tue Mar 21 22:24:51 2023
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 21 Mar 2023 22:24:51 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v9]
In-Reply-To: <n6PYFvRxzvZ6l989wGMKEeQO15Ko2-hfku7f-obDnhE=.800e90dc-3e2c-4acb-a26a-84ccf9429253@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <W69abHEQZctZeg7QaoW9DFPWPhSNAL3PHMZABD3xLWU=.9e63f600-be6d-4258-991e-4b609be33f0a@github.com>
 <D2-FZhAAt_mlmHeq6yf1weJku-AF7D01R1nihd7_pXo=.49229406-5e0e-4ba6-ae52-f9c80a6038db@github.com>
 <n6PYFvRxzvZ6l989wGMKEeQO15Ko2-hfku7f-obDnhE=.800e90dc-3e2c-4acb-a26a-84ccf9429253@github.com>
Message-ID: <eqQpa8JckmYlnURT1fwn9vB2cke2fZBayhn-hBoWla8=.11e75aeb-332b-4388-ad27-e1bb12bacb5b@github.com>

On Tue, 21 Mar 2023 17:40:46 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/templateTable_aarch64.cpp line 2337:
>> 
>>> 2335:   // Load-acquire the adapter method
>>> 2336:   __ lea(method, Address(cache, in_bytes(ResolvedIndyEntry::method_offset())));
>>> 2337:   __ ldar(method, method);
>> 
>> What reordering are we trying to prevent here?
>
> The loads of the data stored in `ResolvedIndyEntry::fill_in()` must not be reordered with loading  `ResolvedIndyEntry::_method`.

Ah, I see. This acquiring load matches the releasing store in `fill_in()`. Please add a comment here to that effect.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12778#discussion_r1144047014

From sviswanathan at openjdk.org  Tue Mar 21 23:35:48 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 21 Mar 2023 23:35:48 GMT
Subject: RFR: 8302191: Performance degradation for float/double modulo on
 Linux [v13]
In-Reply-To: <zyZmB20qdtF9JepETeVJVvVRW-UTPwo6UYi5Jwea6yE=.988f2a96-77bd-483d-a1fa-df4ab920f719@github.com>
References: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
 <CkbXLZNrBGwQzsb88Gx3NnEPfvtcVQcTM9BiObmLMwg=.4fb98a6e-3839-48d5-9b83-c1b857b30e60@github.com>
 <zyZmB20qdtF9JepETeVJVvVRW-UTPwo6UYi5Jwea6yE=.988f2a96-77bd-483d-a1fa-df4ab920f719@github.com>
Message-ID: <88lAXNroRn3vodO7xcBefm3MumrW5grX4s8yCsV0W5s=.f7c1a32f-0ba3-4b56-b38c-2cd0dba932b1@github.com>

On Wed, 15 Mar 2023 04:57:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Jan Kratochvil 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 branch 'master' into modulo
>>  - Fix missing SharedRuntime::frem and SharedRuntime::drem on aarch64.
>>     - bugreported by sviswa7.
>>  - Merge branch 'master' into modulo
>>  - Fix #endif comment - found by dholmes-ora.
>>  - Merge branch 'master' into modulo
>>  - Fix win32 broken build.
>>  - Merge remote-tracking branch 'origin/master' into modulo
>>  - Always include the _WIN64 workaround - a review by dholmes-ora.
>>  - Remove comments to be moved to JBS (Bug System) - a review by jddarcy.
>>  - Uppercase L - a review by turbanoff.
>>  - ... and 4 more: https://git.openjdk.org/jdk/compare/eb5e17b6...65af58da
>
> Functional CI testing in tiers 1-4 is good.
> 
> I'm also running some benchmarks on Linux-x64

@dholmes-ora Were the benchmark runs for float/double modulo ok?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12508#issuecomment-1478726088

From kvn at openjdk.org  Wed Mar 22 01:19:03 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 22 Mar 2023 01:19:03 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
Message-ID: <ztiqECTkWnt6s0n8q0KXw4MzN2MBVqdJ1Jy0kd6JuQE=.c0872ea4-e696-43a0-b356-d5149af1cbd1@github.com>

On Thu, 16 Mar 2023 20:56:15 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>  - Set condition flags correctly after fast-lock call on aarch64

First, thank you for putting new code under flag. I looked only on x86 code. It seems fine except few places where I added comment.

I wish locking code for Aarch64 and Risc-v was moved to c2_MacroAssembler as on x86 but for this review it is better to keep it where it is.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 602:

> 600:   movptr(tmpReg, Address(objReg, oopDesc::mark_offset_in_bytes()));          // [FETCH]
> 601:   testptr(tmpReg, markWord::monitor_value); // inflated vs stack-locked|neutral
> 602:   jccb(Assembler::notZero, IsInflated);

May be use `jcc` long branch here to be safe.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 670:

> 668:   get_thread (scrReg);                    // beware: clobbers ICCs
> 669:   movptr(Address(boxReg, OM_OFFSET_NO_MONITOR_VALUE_TAG(owner)), scrReg);
> 670:   xorptr(boxReg, boxReg);                 // set icc.ZFlag = 1 to indicate success

Should this be under `if (UseFastLocking)`?

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 791:

> 789:       Compile::current()->output()->add_stub(stub);
> 790:       jcc(Assembler::notEqual, stub->entry());
> 791:       bind(stub->continuation());

Why use stub here and not inline the code? Because the branch mostly not taken?

-------------

PR Review: https://git.openjdk.org/jdk/pull/10907#pullrequestreview-1351551552
PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1144107482
PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1144111315
PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1144119776

From sspitsyn at openjdk.org  Wed Mar 22 02:20:40 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 22 Mar 2023 02:20:40 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
Message-ID: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>

The fix is to enable support for late binding JVMTI agents.
The fix includes:
- New function `JvmtiEnvBase::enable_virtual_threads_notify_jvmti()` which does enabling JVMTI VTMS transition notifications in case of agent loaded into running VM. This function executes a VM operation counting VTMS transition bits in all `JavaThread`'s to correctly set the static counter `_VTMS_transition_count` needed for VTMS transition protocol.
- New function `JvmtiEnvBase::disable_virtual_threads_notify_jvmti()` which is needed for testing. It is used by the `WhiteBox` API.
- New WhiteBox function `WB_SetVirtualThreadsNotifyJvmtiMode(JNIEnv* env, jobject wb, jboolean enable)` needed for testing of this update.
- New regression test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`

Testing:
- New test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
- The originally failed tests are expected to pass now:
  `runtime/vthread/RedefineClass.java`
  `runtime/vthread/TestObjectAllocationSampleEvent.java` 
- In progress: Run the tiers 1-6 to make sure there are no regression.

-------------

Commit messages:
 - cleanup in vmOperation.hpp
 - restored one incorrectly removed function
 - removed temporary debugging changes
 - 8297286: runtime/vthread tests crashing after JDK-8296324

Changes: https://git.openjdk.org/jdk/pull/13133/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13133&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297286
  Stats: 380 lines in 9 files changed: 377 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13133.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13133/head:pull/13133

PR: https://git.openjdk.org/jdk/pull/13133

From sspitsyn at openjdk.org  Wed Mar 22 03:03:18 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 22 Mar 2023 03:03:18 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v2]
In-Reply-To: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
Message-ID: <cpWO1mcPDAlyaVRlnt3YDprQMOx5NlvLYla3-YaZmlA=.27e8b142-0d09-43cf-acf2-21e385391c19@github.com>

> The fix is to enable support for late binding JVMTI agents.
> The fix includes:
> - New function `JvmtiEnvBase::enable_virtual_threads_notify_jvmti()` which does enabling JVMTI VTMS transition notifications in case of agent loaded into running VM. This function executes a VM operation counting VTMS transition bits in all `JavaThread`'s to correctly set the static counter `_VTMS_transition_count` needed for VTMS transition protocol.
> - New function `JvmtiEnvBase::disable_virtual_threads_notify_jvmti()` which is needed for testing. It is used by the `WhiteBox` API.
> - New WhiteBox function `WB_SetVirtualThreadsNotifyJvmtiMode(JNIEnv* env, jobject wb, jboolean enable)` needed for testing of this update.
> - New regression test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
> 
> Testing:
> - New test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
> - The originally failed tests are expected to pass 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:

  update for missed part in jvmtiExport.cpp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13133/files
  - new: https://git.openjdk.org/jdk/pull/13133/files/6e27ee6f..ddac01c3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13133&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13133&range=00-01

  Stats: 10 lines in 2 files changed: 8 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13133.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13133/head:pull/13133

PR: https://git.openjdk.org/jdk/pull/13133

From rrich at openjdk.org  Wed Mar 22 05:39:42 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 22 Mar 2023 05:39:42 GMT
Subject: RFR: 8296440: Remove Method* handling from
 cleanup_inline_caches_impl [v3]
In-Reply-To: <Jl4636WaRF28mQZl6gK1Q4a44CyRJLX-2X3N5RPeKd0=.e4d9606d-c027-419a-b977-ce60e4487a79@github.com>
References: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
 <Jl4636WaRF28mQZl6gK1Q4a44CyRJLX-2X3N5RPeKd0=.e4d9606d-c027-419a-b977-ce60e4487a79@github.com>
Message-ID: <vrfpAZoGQMF3rR-Hehb59L56XdZap3c-wsblyuln2Cg=.cf786933-b9ef-45a9-bda7-3f0c9619a97b@github.com>

On Tue, 21 Mar 2023 17:04:56 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> This PR replaces cleaning of static stubs in CompiledMethod::cleanup_inline_caches_impl() with a guarantee that it is actually not needed because the holder of the embedded target Method* is alive if the caller nmethod is not unloading.
>> 
>> The holder of the target Method* has to be alive because it is reachable from the caller nmethod's oop pool. This is checked by `check_path_to_callee()` when a statically bound call gets resolved.
>> 
>> C2i entry barriers can be removed for the same reason.
>> 
>> Testing:
>> 
>> Many rounds in our CI testing which includes most JCK and JTREG tests, Renaissance benchmark and SAP specific tests with fastdebug and release builds on the standard platforms plus PPC64.
>> 
>> I've also done tier1 and tier2 tests with -XX:-Inline and tier1 tests with ZGC.
>> 
>> I've started hotspot and jdk tier1 tests with -Xcomp. They were not finished when I stopped them after 24h.
>
> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback Coleene

Going back to draft while analyzing test errors. Sorry for the noise.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12802#issuecomment-1478942316

From fgao at openjdk.org  Wed Mar 22 05:57:40 2023
From: fgao at openjdk.org (Fei Gao)
Date: Wed, 22 Mar 2023 05:57:40 GMT
Subject: RFR: 8304301: Remove the global option SuperWordMaxVectorSize
In-Reply-To: <x_FnktZAXmUd_uw0x9246aHueRxxt9AlXabM5TIwO90=.35996788-e648-4a61-848f-9183bde7936d@github.com>
References: <2XQwCCx_ficJ1bn2WX0Ud9m-QmuGkkZAH8N6yLugXqQ=.90a136da-db9a-49b4-a4c4-d6c644cf7d5a@github.com>
 <x_FnktZAXmUd_uw0x9246aHueRxxt9AlXabM5TIwO90=.35996788-e648-4a61-848f-9183bde7936d@github.com>
Message-ID: <vKEZTXN1IjBwqpYu2bgji3_3-cvyNl_UPt-h5V2wZzc=.1ba1e222-d626-4f85-9e15-2e92aa47e279@github.com>

On Tue, 21 Mar 2023 04:16:26 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> https://github.com/openjdk/jdk/pull/8877 introduced the global option `SuperWordMaxVectorSize` as a temporary solution to fix the performance regression on some x86 machines.
>> 
>> Currently, `SuperWordMaxVectorSize` behaves differently between x86 and other platforms [1]. For example, if the current machine only supports `MaxVectorSize <= 32`, but we set `SuperWordMaxVectorSize = 64`, then `SuperWordMaxVectorSize` will be kept at 64 on other platforms while x86 machine would change `SuperWordMaxVectorSize` to `MaxVectorSize`. Other platforms except x86 miss similar implementations like [2].
>> 
>> Also, `SuperWordMaxVectorSize` limits the max vector size of auto-vectorization as `64`, which is fine for current aarch64 hardware, but SVE architecture supports larger than 512 bits.
>> 
>> The patch is to drop the global option and use an architecture-dependent interface to consult the max vector size for auto-vectorization, fixing the performance issue on x86 and reducing side effects for other platforms. After the patch, auto-vectorization is still limited to 32-byte vectors by default on Cascade Lake and users can override this by either setting
>> `-XX:UseAVX=3` or `-XX:MaxVectorSize=64` on JVM command line.
>> 
>> So my question is:
>> 
>> Before the patch, we could have a smaller max vector size for auto-vectorization than `MaxVectorSize` on x86. For example, users could have `MaxVectorSize=64` and `SuperWordMaxVectorSize=32`. But after the change, if we set
>> `-XX:MaxVectorSize=64` explicitly, then the max vector size for auto-vectorization would be `MaxVectorSize`, i.e. 64 bytes, which I believe is more reasonable. @sviswa7 @jatin-bhateja, are you happy about the change?
>> 
>> [1] https://github.com/openjdk/jdk/pull/12350#discussion_r1126106213
>> [2] https://github.com/openjdk/jdk/blob/33bec207103acd520eb99afb093cfafa44aecfda/src/hotspot/cpu/x86/vm_version_x86.cpp#L1314-L1333
>
> @fg1417  SuperWordMaxVectorSize defines the maximum vector size generated by the auto vectorization.
>                  MaxVectorSize defines the  vector width supported by the underlying platform. 
>                  For CascadeLake we are setting SuperWordMaxVectorSize=32 and MaxVectorSize=64 by default.
>                  This allows the usage of larger 64 byte width vector instructions in places like Java Vector API and intrinsics. 
>                  We would like to keep this behavior for x86.

@sviswa7 thanks for your kind review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13112#issuecomment-1478962379

From sspitsyn at openjdk.org  Wed Mar 22 06:06:25 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 22 Mar 2023 06:06:25 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v3]
In-Reply-To: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
Message-ID: <ELZo4w28M7MIm9R3gyngCPCDfEmjU8LAJygzsajyg80=.751fa317-8985-4d3a-a7de-8d93c037a3c5@github.com>

> The fix is to enable support for late binding JVMTI agents.
> The fix includes:
> - New function `JvmtiEnvBase::enable_virtual_threads_notify_jvmti()` which does enabling JVMTI VTMS transition notifications in case of agent loaded into running VM. This function executes a VM operation counting VTMS transition bits in all `JavaThread`'s to correctly set the static counter `_VTMS_transition_count` needed for VTMS transition protocol.
> - New function `JvmtiEnvBase::disable_virtual_threads_notify_jvmti()` which is needed for testing. It is used by the `WhiteBox` API.
> - New WhiteBox function `WB_SetVirtualThreadsNotifyJvmtiMode(JNIEnv* env, jobject wb, jboolean enable)` needed for testing of this update.
> - New regression test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
> 
> Testing:
> - New test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
> - The originally failed tests are expected to pass 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:

  add necessary tweak in jvmtiExport.cpp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13133/files
  - new: https://git.openjdk.org/jdk/pull/13133/files/ddac01c3..51c3f7d5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13133&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13133&range=01-02

  Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13133.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13133/head:pull/13133

PR: https://git.openjdk.org/jdk/pull/13133

From fgao at openjdk.org  Wed Mar 22 06:11:54 2023
From: fgao at openjdk.org (Fei Gao)
Date: Wed, 22 Mar 2023 06:11:54 GMT
Subject: RFR: 8304301: Remove the global option SuperWordMaxVectorSize
In-Reply-To: <2XQwCCx_ficJ1bn2WX0Ud9m-QmuGkkZAH8N6yLugXqQ=.90a136da-db9a-49b4-a4c4-d6c644cf7d5a@github.com>
References: <2XQwCCx_ficJ1bn2WX0Ud9m-QmuGkkZAH8N6yLugXqQ=.90a136da-db9a-49b4-a4c4-d6c644cf7d5a@github.com>
Message-ID: <pEEDR4bp70ywspQivw4MN97ADJ3mqtvyHoP7-g8uLwg=.bb9c3ca7-2fef-47d3-b4d5-d83faca59b9d@github.com>

On Tue, 21 Mar 2023 02:26:55 GMT, Fei Gao <fgao at openjdk.org> wrote:

> https://github.com/openjdk/jdk/pull/8877 introduced the global option `SuperWordMaxVectorSize` as a temporary solution to fix the performance regression on some x86 machines.
> 
> Currently, `SuperWordMaxVectorSize` behaves differently between x86 and other platforms [1]. For example, if the current machine only supports `MaxVectorSize <= 32`, but we set `SuperWordMaxVectorSize = 64`, then `SuperWordMaxVectorSize` will be kept at 64 on other platforms while x86 machine would change `SuperWordMaxVectorSize` to `MaxVectorSize`. Other platforms except x86 miss similar implementations like [2].
> 
> Also, `SuperWordMaxVectorSize` limits the max vector size of auto-vectorization as `64`, which is fine for current aarch64 hardware, but SVE architecture supports larger than 512 bits.
> 
> The patch is to drop the global option and use an architecture-dependent interface to consult the max vector size for auto-vectorization, fixing the performance issue on x86 and reducing side effects for other platforms. After the patch, auto-vectorization is still limited to 32-byte vectors by default on Cascade Lake and users can override this by either setting
> `-XX:UseAVX=3` or `-XX:MaxVectorSize=64` on JVM command line.
> 
> So my question is:
> 
> Before the patch, we could have a smaller max vector size for auto-vectorization than `MaxVectorSize` on x86. For example, users could have `MaxVectorSize=64` and `SuperWordMaxVectorSize=32`. But after the change, if we set
> `-XX:MaxVectorSize=64` explicitly, then the max vector size for auto-vectorization would be `MaxVectorSize`, i.e. 64 bytes, which I believe is more reasonable. @sviswa7 @jatin-bhateja, are you happy about the change?
> 
> [1] https://github.com/openjdk/jdk/pull/12350#discussion_r1126106213
> [2] https://github.com/openjdk/jdk/blob/33bec207103acd520eb99afb093cfafa44aecfda/src/hotspot/cpu/x86/vm_version_x86.cpp#L1314-L1333

Hi @vnkozlov @TobiHartmann, could you please help review the patch?

Since I don't have sufficient x86 systems, I would appreciate it if you could help verify that the patch will not introduce any performance regression on x86, especially on Cascade Lake. 

Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13112#issuecomment-1478971819

From thartmann at openjdk.org  Wed Mar 22 06:21:42 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 22 Mar 2023 06:21:42 GMT
Subject: RFR: JDK-8304683: Memory leak in WB_IsMethodCompatible
In-Reply-To: <4V-_5ZAkbj0Kw1UsgBnat-JrwffKM_mHRNmWZwB3ox8=.94ce5e0d-9552-4a96-9bb1-8a3f26c2dd7f@github.com>
References: <4V-_5ZAkbj0Kw1UsgBnat-JrwffKM_mHRNmWZwB3ox8=.94ce5e0d-9552-4a96-9bb1-8a3f26c2dd7f@github.com>
Message-ID: <CzZzud8xS2hn4aG0fp2mHTiyH_38Qk6UzaACcsrj0vc=.3e1a2b9e-036d-4c39-a4b6-d6a94551f16c@github.com>

On Tue, 21 Mar 2023 16:45:30 GMT, Justin King <jcking at openjdk.org> wrote:

> Add missing call to `DirectivesStack::release`.

Looks good and trivial.

-------------

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13124#pullrequestreview-1351792326

From kvn at openjdk.org  Wed Mar 22 06:35:41 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 22 Mar 2023 06:35:41 GMT
Subject: RFR: 8304301: Remove the global option SuperWordMaxVectorSize
In-Reply-To: <2XQwCCx_ficJ1bn2WX0Ud9m-QmuGkkZAH8N6yLugXqQ=.90a136da-db9a-49b4-a4c4-d6c644cf7d5a@github.com>
References: <2XQwCCx_ficJ1bn2WX0Ud9m-QmuGkkZAH8N6yLugXqQ=.90a136da-db9a-49b4-a4c4-d6c644cf7d5a@github.com>
Message-ID: <50dOJmvInI6foWz9kH7iVPz6TfYH5Crbc4kyXxN4HNY=.f7cc3709-f0a4-49dc-85b8-0fc9f5ce1afa@github.com>

On Tue, 21 Mar 2023 02:26:55 GMT, Fei Gao <fgao at openjdk.org> wrote:

> https://github.com/openjdk/jdk/pull/8877 introduced the global option `SuperWordMaxVectorSize` as a temporary solution to fix the performance regression on some x86 machines.
> 
> Currently, `SuperWordMaxVectorSize` behaves differently between x86 and other platforms [1]. For example, if the current machine only supports `MaxVectorSize <= 32`, but we set `SuperWordMaxVectorSize = 64`, then `SuperWordMaxVectorSize` will be kept at 64 on other platforms while x86 machine would change `SuperWordMaxVectorSize` to `MaxVectorSize`. Other platforms except x86 miss similar implementations like [2].
> 
> Also, `SuperWordMaxVectorSize` limits the max vector size of auto-vectorization as `64`, which is fine for current aarch64 hardware, but SVE architecture supports larger than 512 bits.
> 
> The patch is to drop the global option and use an architecture-dependent interface to consult the max vector size for auto-vectorization, fixing the performance issue on x86 and reducing side effects for other platforms. After the patch, auto-vectorization is still limited to 32-byte vectors by default on Cascade Lake and users can override this by either setting
> `-XX:UseAVX=3` or `-XX:MaxVectorSize=64` on JVM command line.
> 
> So my question is:
> 
> Before the patch, we could have a smaller max vector size for auto-vectorization than `MaxVectorSize` on x86. For example, users could have `MaxVectorSize=64` and `SuperWordMaxVectorSize=32`. But after the change, if we set
> `-XX:MaxVectorSize=64` explicitly, then the max vector size for auto-vectorization would be `MaxVectorSize`, i.e. 64 bytes, which I believe is more reasonable. @sviswa7 @jatin-bhateja, are you happy about the change?
> 
> [1] https://github.com/openjdk/jdk/pull/12350#discussion_r1126106213
> [2] https://github.com/openjdk/jdk/blob/33bec207103acd520eb99afb093cfafa44aecfda/src/hotspot/cpu/x86/vm_version_x86.cpp#L1314-L1333

I will test it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13112#issuecomment-1478986856

From dholmes at openjdk.org  Wed Mar 22 06:54:43 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 22 Mar 2023 06:54:43 GMT
Subject: RFR: 8302191: Performance degradation for float/double modulo on
 Linux [v13]
In-Reply-To: <CkbXLZNrBGwQzsb88Gx3NnEPfvtcVQcTM9BiObmLMwg=.4fb98a6e-3839-48d5-9b83-c1b857b30e60@github.com>
References: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
 <CkbXLZNrBGwQzsb88Gx3NnEPfvtcVQcTM9BiObmLMwg=.4fb98a6e-3839-48d5-9b83-c1b857b30e60@github.com>
Message-ID: <CHP2MWmnOdphN1XcHa_EOXkNuO4IniBAJHChSUrZ8o8=.25fe33fa-5daa-46df-b59b-a97bb3ca644d@github.com>

On Tue, 14 Mar 2023 12:45:42 GMT, Jan Kratochvil <duke at openjdk.org> wrote:

>> I have OCA already processed/approved. I am not Author but my Author request is being processed these days (sent to Rob McKenna).
>> I did regression test x86_64 OpenJDK-8. I will leave other regression testing on GHA.
>> The patch (and former GCC performance regression) affects only x86_64+i686.
>
> Jan Kratochvil 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 branch 'master' into modulo
>  - Fix missing SharedRuntime::frem and SharedRuntime::drem on aarch64.
>     - bugreported by sviswa7.
>  - Merge branch 'master' into modulo
>  - Fix #endif comment - found by dholmes-ora.
>  - Merge branch 'master' into modulo
>  - Fix win32 broken build.
>  - Merge remote-tracking branch 'origin/master' into modulo
>  - Always include the _WIN64 workaround - a review by dholmes-ora.
>  - Remove comments to be moved to JBS (Bug System) - a review by jddarcy.
>  - Uppercase L - a review by turbanoff.
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/539f86a7...65af58da

Nothing further from me. Thanks for your patience here.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12508#pullrequestreview-1351821663

From dholmes at openjdk.org  Wed Mar 22 06:54:45 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 22 Mar 2023 06:54:45 GMT
Subject: RFR: 8302191: Performance degradation for float/double modulo on
 Linux [v13]
In-Reply-To: <88lAXNroRn3vodO7xcBefm3MumrW5grX4s8yCsV0W5s=.f7c1a32f-0ba3-4b56-b38c-2cd0dba932b1@github.com>
References: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
 <CkbXLZNrBGwQzsb88Gx3NnEPfvtcVQcTM9BiObmLMwg=.4fb98a6e-3839-48d5-9b83-c1b857b30e60@github.com>
 <zyZmB20qdtF9JepETeVJVvVRW-UTPwo6UYi5Jwea6yE=.988f2a96-77bd-483d-a1fa-df4ab920f719@github.com>
 <88lAXNroRn3vodO7xcBefm3MumrW5grX4s8yCsV0W5s=.f7c1a32f-0ba3-4b56-b38c-2cd0dba932b1@github.com>
Message-ID: <GXKOwM1_z-DzPwNImK8V1XqAtIcFwurRtkWUrYVmkeU=.9d49b395-8564-4b6f-872e-f65a8f6c282d@github.com>

On Tue, 21 Mar 2023 23:32:28 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Functional CI testing in tiers 1-4 is good.
>> 
>> I'm also running some benchmarks on Linux-x64
>
> @dholmes-ora Were the benchmark runs for float/double modulo ok?

@sviswa7 the general benchmarks I ran showed some small losses, some small wins and a few larger wins. So no reason for this not to go in based on that.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12508#issuecomment-1479003124

From dholmes at openjdk.org  Wed Mar 22 07:02:45 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 22 Mar 2023 07:02:45 GMT
Subject: RFR: 8304089: Convert TraceDependencies to UL [v5]
In-Reply-To: <iy21P3-_eQnuA6cuPbMkGhFpZoeHJf4vuSrCQ-ScRdU=.c9246e41-996d-472e-9b92-5569835e4c7d@github.com>
References: <0aGc1NdAjpvksCWmXb1gZOPp9MV0n6xWvG8EaEp2ZLg=.b79cf218-9a23-420d-bec5-7509b7f8f1c1@github.com>
 <iy21P3-_eQnuA6cuPbMkGhFpZoeHJf4vuSrCQ-ScRdU=.c9246e41-996d-472e-9b92-5569835e4c7d@github.com>
Message-ID: <ddJgqotgl6lrAKEYpLrpW2j9AJhjzatpSn2ofOwgNOw=.0056b553-faed-4c45-b4af-f18d26e8495f@github.com>

On Tue, 21 Mar 2023 17:12:00 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change converts TraceDependencies to UL and removes the develop option. I think this provides further flexibility to add tags to only trace certain things in dependency analysis, as I did when trying to understand a PR for a deoptimization change.  For now, the messages are the same and the option is -Xlog:dependencies=debug.
>> Tested with tier1-4
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Drop UL check for log file output (still have PrintDependencies).

Nothing further from me - update is good. Thanks.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13007#pullrequestreview-1351837055

From dholmes at openjdk.org  Wed Mar 22 07:17:40 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 22 Mar 2023 07:17:40 GMT
Subject: RFR: 8304687: Move add_to_hierarchy
In-Reply-To: <8lZkIOj_sW-s5fenIUyqOflXokTscrf8v6Zi6VOic4o=.847bbf8a-430b-46f5-a4c2-335d3355c320@github.com>
References: <8lZkIOj_sW-s5fenIUyqOflXokTscrf8v6Zi6VOic4o=.847bbf8a-430b-46f5-a4c2-335d3355c320@github.com>
Message-ID: <8GQkulzonIlR8El5Ql1MVrQg8X9Ka7mXjoa6fjsNgt8=.15551bb3-12e9-40b1-b6e6-13d504d9e18b@github.com>

On Tue, 21 Mar 2023 21:36:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Moved SystemDictionary::add_to_hierarchy to InstanceKlass::add_to_hierarchy where it more logically belongs and next to other functions that also care about dependencies.
> Tested with tier1-4, and tier1 on linux,windows,macos to check header file changes.

Refactoring looks fine.

Thanks.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13129#pullrequestreview-1351852298

From dholmes at openjdk.org  Wed Mar 22 07:33:43 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 22 Mar 2023 07:33:43 GMT
Subject: RFR: JDK-8301498: Replace NULL with nullptr in cpu/x86 [v4]
In-Reply-To: <K21IuPJG7Tk7Kjvsp1MFiE67n5iDJlezp369mHL1mdE=.6f1d309e-3ac8-4758-b38d-5bc21ce232e9@github.com>
References: <AB1094dam2aXNm_hav09Ium0jqJUCJE0hmJ4GfljA5M=.4e8e0845-20d5-45bf-bf2e-1d23ed8ef9f0@github.com>
 <K21IuPJG7Tk7Kjvsp1MFiE67n5iDJlezp369mHL1mdE=.6f1d309e-3ac8-4758-b38d-5bc21ce232e9@github.com>
Message-ID: <uKETRtyTRyoh63YclMF8HhaN25Sfn6IWYKlFWQ5XBFs=.fa275fdd-289a-4e23-b7c5-e18a34b6559e@github.com>

On Tue, 21 Mar 2023 10:04:04 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory cpu/x86. Unfortunately the script that does the change isn't perfect, and so we
>> need to comb through these manually to make sure nothing has gone wrong. I also review these changes but things slip past my eyes sometimes.
>> 
>> Here are some typical things to look out for:
>> 
>> 1. No changes but copyright header changed (probably because I reverted some changes but forgot the copyright).
>> 2. Macros having their NULL changed to nullptr, these are added to the script when I find them. They should be NULL.
>> 3. nullptr in comments and logs. We try to use lower case "null" in these cases as it reads better. An exception is made when code expressions are in a comment.
>> 
>> An example of this:
>> 
>> ```c++
>> // This function returns null
>> void* ret_null();
>> // This function returns true if *x == nullptr
>> bool is_nullptr(void** x);
>> 
>> 
>> Note how `nullptr` participates in a code expression here, we really are talking about the specific value `nullptr`.
>> 
>> Thanks!
>
> Johan Sj?len has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge remote-tracking branch 'origin/master' into JDK-8301498
>  - Fix vnkozlov's suggestions
>  - Merge remote-tracking branch 'origin/master' into JDK-8301498
>  - Some more fixes
>  - Fixes
>  -  Replace NULL with nullptr in cpu/x86

Still good. Thanks.

(incremental change looked weird but end result seems fine)

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12326#pullrequestreview-1351869217

From xgong at openjdk.org  Wed Mar 22 08:08:46 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 22 Mar 2023 08:08:46 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v3]
In-Reply-To: <4Op0Z8whnyDXDC6zGyMbx4ugcZp5TEoAqW_myB5flxM=.1c7b59ba-efb2-4f68-90d7-2d6e33e39572@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
 <4Op0Z8whnyDXDC6zGyMbx4ugcZp5TEoAqW_myB5flxM=.1c7b59ba-efb2-4f68-90d7-2d6e33e39572@github.com>
Message-ID: <yPyZ7su4OnRDd5LyQPvU0Hk6n5AI5CO2lR12qO9efCg=.51a05574-aee6-416b-863c-76d38a6766c3@github.com>

On Tue, 21 Mar 2023 16:16:31 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, VectorShuffle is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
>> 
>> 1. Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
>> 2. Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
>> 3. Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
>> 4. Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
>> 
>> Upon these changes, a `rearrange` can emit more efficient code:
>> 
>>     var species = IntVector.SPECIES_128;
>>     var v1 = IntVector.fromArray(species, SRC1, 0);
>>     var v2 = IntVector.fromArray(species, SRC2, 0);
>>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
>> 
>>     Before:
>>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>>     vmovdqu 0x10(%r10),%xmm0
>>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>>                                                             ;   {external_word}
>>     vpackusdw %xmm0,%xmm0,%xmm0
>>     vpackuswb %xmm0,%xmm0,%xmm0
>>     vpmovsxbd %xmm0,%xmm3
>>     vpcmpgtd %xmm3,%xmm1,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fc2acb4e0d8
>>     vpmovzxbd %xmm0,%xmm0
>>     vpermd %ymm2,%ymm0,%ymm0
>>     movabs $0x751588f98,%r10            ;   {oop([I{0x0000000751588f98})}
>>     vmovdqu %xmm0,0x10(%r10)
>> 
>>     After:
>>     movabs $0x751589c78,%r10            ;   {oop([I{0x0000000751589c78})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158ac88,%r10            ;   {oop([I{0x000000075158ac88})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     vpxor  %xmm0,%xmm0,%xmm0
>>     vpcmpgtd %xmm2,%xmm0,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fa818b27cb1
>>     vpermd %ymm1,%ymm2,%ymm0
>>     movabs $0x751588c68,%r10            ;   {oop([I{0x0000000751588c68})}
>>     vmovdqu %xmm0,0x10(%r10)
>>     
>> Please take a look and leave reviews. Thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - missing casts
>  - clean up

src/hotspot/cpu/aarch64/aarch64_vector.ad line 6082:

> 6080: //   to implement rearrange.
> 6081: 
> 6082: // Maybe move the shuffle preparation to VectorLoadShuffle

Agree that moving the shuffle computation code to `VectorLoadShuffle`. Thanks!

src/hotspot/share/opto/vectorIntrinsics.cpp line 2059:

> 2057:   if (need_load_shuffle) {
> 2058:     shuffle = gvn().transform(new VectorLoadShuffleNode(shuffle, vt));
> 2059:   }

How about generating `VectorLoadShuffleNode` for all platforms that support Vector API, and remove the helper method `vector_needs_load_shuffle()` ? For those platforms that do not need this shuffle preparation, we can emit nothing  in codegen.

src/hotspot/share/opto/vectorIntrinsics.cpp line 2426:

> 2424:   if (is_vector_shuffle(vbox_klass_from)) {
> 2425:     return false; // vector shuffles aren't supported
> 2426:   }

Is it better to change this as an "assertion" or print the log details?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1144366812
PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1144360349
PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1144363416

From xgong at openjdk.org  Wed Mar 22 08:11:43 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 22 Mar 2023 08:11:43 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v3]
In-Reply-To: <4Op0Z8whnyDXDC6zGyMbx4ugcZp5TEoAqW_myB5flxM=.1c7b59ba-efb2-4f68-90d7-2d6e33e39572@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
 <4Op0Z8whnyDXDC6zGyMbx4ugcZp5TEoAqW_myB5flxM=.1c7b59ba-efb2-4f68-90d7-2d6e33e39572@github.com>
Message-ID: <LBxWDJJAhoJ_U8PCWEhrQ27bXZqOx2vpnl4FGIgb7mk=.a7f55998-3191-432a-92e0-c1749078028e@github.com>

On Tue, 21 Mar 2023 16:16:31 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, VectorShuffle is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
>> 
>> 1. Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
>> 2. Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
>> 3. Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
>> 4. Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
>> 
>> Upon these changes, a `rearrange` can emit more efficient code:
>> 
>>     var species = IntVector.SPECIES_128;
>>     var v1 = IntVector.fromArray(species, SRC1, 0);
>>     var v2 = IntVector.fromArray(species, SRC2, 0);
>>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
>> 
>>     Before:
>>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>>     vmovdqu 0x10(%r10),%xmm0
>>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>>                                                             ;   {external_word}
>>     vpackusdw %xmm0,%xmm0,%xmm0
>>     vpackuswb %xmm0,%xmm0,%xmm0
>>     vpmovsxbd %xmm0,%xmm3
>>     vpcmpgtd %xmm3,%xmm1,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fc2acb4e0d8
>>     vpmovzxbd %xmm0,%xmm0
>>     vpermd %ymm2,%ymm0,%ymm0
>>     movabs $0x751588f98,%r10            ;   {oop([I{0x0000000751588f98})}
>>     vmovdqu %xmm0,0x10(%r10)
>> 
>>     After:
>>     movabs $0x751589c78,%r10            ;   {oop([I{0x0000000751589c78})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158ac88,%r10            ;   {oop([I{0x000000075158ac88})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     vpxor  %xmm0,%xmm0,%xmm0
>>     vpcmpgtd %xmm2,%xmm0,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fa818b27cb1
>>     vpermd %ymm1,%ymm2,%ymm0
>>     movabs $0x751588c68,%r10            ;   {oop([I{0x0000000751588c68})}
>>     vmovdqu %xmm0,0x10(%r10)
>>     
>> Please take a look and leave reviews. Thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - missing casts
>  - clean up

Please also update the copyright to 2023 for some touched files like `vectorSupport.hpp` and other java files like `AbstractShuffle.java`, `AbstractVector.java`, `VectorShape.java`, and `VectorShuffle.java`. Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13093#issuecomment-1479076010

From fjiang at openjdk.org  Wed Mar 22 08:18:42 2023
From: fjiang at openjdk.org (Feilong Jiang)
Date: Wed, 22 Mar 2023 08:18:42 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v5]
In-Reply-To: <hw0KAH255Qgpaf9TWe72S7DBFDPLju7BjAZo6Cnh7q0=.e4ce764d-37db-40c4-83bf-96705c0c80a1@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <MtnTWtmtdQkU0RqBSp7DuSnQz0OO8Bk3HzJi7NHZDoU=.bc0c0f9f-454a-484d-9613-95b00f5af7ca@github.com>
 <hw0KAH255Qgpaf9TWe72S7DBFDPLju7BjAZo6Cnh7q0=.e4ce764d-37db-40c4-83bf-96705c0c80a1@github.com>
Message-ID: <2VN0jPv3cwJuzneVkIBwHReDI-2zj0qBknbc_AeFy1k=.d306ef5f-c104-496b-b6fd-f404ffc33d39@github.com>

On Tue, 21 Mar 2023 13:35:25 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add example for Option::captureStateLayout
>
> A review of all the copyright years shall be made in this PR.

Hi @minborg, looks like some changes were missed on riscv port. I've added these changes and submitted tests on linux-riscv. `jdk_foreign` still passed with release & fatdebug build.
Could you please add these extra changes for riscv? Thanks.
 Here is the patch: [foreign_riscv_port_patch.txt](https://github.com/openjdk/jdk/files/11037700/foreign_riscv_port_patch.txt)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13079#issuecomment-1479083052

From xgong at openjdk.org  Wed Mar 22 08:33:47 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 22 Mar 2023 08:33:47 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v3]
In-Reply-To: <4Op0Z8whnyDXDC6zGyMbx4ugcZp5TEoAqW_myB5flxM=.1c7b59ba-efb2-4f68-90d7-2d6e33e39572@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
 <4Op0Z8whnyDXDC6zGyMbx4ugcZp5TEoAqW_myB5flxM=.1c7b59ba-efb2-4f68-90d7-2d6e33e39572@github.com>
Message-ID: <hdjkeGJ2nlqeLYhs_P_nJxOqiRdoo3rHkcYiGKX8_EI=.9d881d4b-5c6a-466a-bc08-c1b1f8cf8688@github.com>

On Tue, 21 Mar 2023 16:16:31 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, VectorShuffle is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
>> 
>> 1. Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
>> 2. Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
>> 3. Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
>> 4. Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
>> 
>> Upon these changes, a `rearrange` can emit more efficient code:
>> 
>>     var species = IntVector.SPECIES_128;
>>     var v1 = IntVector.fromArray(species, SRC1, 0);
>>     var v2 = IntVector.fromArray(species, SRC2, 0);
>>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
>> 
>>     Before:
>>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>>     vmovdqu 0x10(%r10),%xmm0
>>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>>                                                             ;   {external_word}
>>     vpackusdw %xmm0,%xmm0,%xmm0
>>     vpackuswb %xmm0,%xmm0,%xmm0
>>     vpmovsxbd %xmm0,%xmm3
>>     vpcmpgtd %xmm3,%xmm1,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fc2acb4e0d8
>>     vpmovzxbd %xmm0,%xmm0
>>     vpermd %ymm2,%ymm0,%ymm0
>>     movabs $0x751588f98,%r10            ;   {oop([I{0x0000000751588f98})}
>>     vmovdqu %xmm0,0x10(%r10)
>> 
>>     After:
>>     movabs $0x751589c78,%r10            ;   {oop([I{0x0000000751589c78})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158ac88,%r10            ;   {oop([I{0x000000075158ac88})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     vpxor  %xmm0,%xmm0,%xmm0
>>     vpcmpgtd %xmm2,%xmm0,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fa818b27cb1
>>     vpermd %ymm1,%ymm2,%ymm0
>>     movabs $0x751588c68,%r10            ;   {oop([I{0x0000000751588c68})}
>>     vmovdqu %xmm0,0x10(%r10)
>>     
>> Please take a look and leave reviews. Thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - missing casts
>  - clean up

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractShuffle.java line 118:

> 116:         return (VectorShuffle<E>) v.rearrange(shuffle.cast(vspecies().asIntegral()))
> 117:                 .toShuffle()
> 118:                 .cast(vspecies());

Style issue. Suggest to change to:

return (VectorShuffle<E>) v.rearrange(shuffle.cast(vspecies().asIntegral()))
                           .toShuffle()
                           .cast(vspecies());

I also noticed that the similar shuffle cast code is used more frequently. Could we wrap such code `toShuffle().cast(vspecies())` to a separate method?

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractShuffle.java line 130:

> 128:         } else {
> 129:             v = v.blend(v.lanewise(VectorOperators.ADD, length()),
> 130:                     v.compare(VectorOperators.LT, 0));

Style issue. Suggest to change to:

v = v.blend(v.lanewise(VectorOperators.ADD, length()),
            v.compare(VectorOperators.LT, 0));

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractVector.java line 198:

> 196:         if ((length() & (length() - 1)) != 0) {
> 197:             return wrap ? shuffleFromOp(i -> (VectorIntrinsics.wrapToRange(i * step + start, length())))
> 198:                     : shuffleFromOp(i -> i * step + start);

Code style issue. Suggest to:

return wrap ? shuffleFromOp(i -> (VectorIntrinsics.wrapToRange(i * step + start, length())))
            : shuffleFromOp(i -> i * step + start);

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractVector.java line 204:

> 202:         Vector iota = species.iota();
> 203:         iota = iota.lanewise(VectorOperators.MUL, step)
> 204:                 .lanewise(VectorOperators.ADD, start);

Style issue. Same as above.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1144384585
PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1144389023
PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1144390218
PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1144390692

From aturbanov at openjdk.org  Wed Mar 22 09:18:50 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 22 Mar 2023 09:18:50 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v5]
In-Reply-To: <MtnTWtmtdQkU0RqBSp7DuSnQz0OO8Bk3HzJi7NHZDoU=.bc0c0f9f-454a-484d-9613-95b00f5af7ca@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <MtnTWtmtdQkU0RqBSp7DuSnQz0OO8Bk3HzJi7NHZDoU=.bc0c0f9f-454a-484d-9613-95b00f5af7ca@github.com>
Message-ID: <gzhf1XGVQ5tRQEVfr8tYaMuzjiPKtwShUwfNsxnovQQ=.4863cbee-19c8-4eb3-8c36-a8cd069c23cd@github.com>

On Tue, 21 Mar 2023 09:02:29 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> API changes for the FFM API (third preview)
>> 
>> Specdiff:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
>> 
>> Javadoc:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add example for Option::captureStateLayout

src/java.base/share/classes/java/lang/foreign/Arena.java line 224:

> 222:     static Arena global() {
> 223:         class Holder {
> 224:             final static Arena GLOBAL = MemorySessionImpl.GLOBAL.asArena();

Nit: use blessed modifiers order
Suggestion:

            static final Arena GLOBAL = MemorySessionImpl.GLOBAL.asArena();

src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/windows/WindowsAArch64Linker.java line 58:

> 56:     @Override
> 57:     protected UpcallStubFactory arrangeUpcall(MethodType targetType, FunctionDescriptor function, LinkerOptions options) {
> 58:         return  CallArranger.WINDOWS.arrangeUpcall(targetType, function, options);

Suggestion:

        return CallArranger.WINDOWS.arrangeUpcall(targetType, function, options);

src/java.base/share/classes/jdk/internal/foreign/abi/fallback/LibFallback.java line 159:

> 157:      */
> 158:     static void getStructOffsets(MemorySegment structType, MemorySegment offsetsOut, FFIABI abi)
> 159:             throws IllegalStateException  {

Suggestion:

            throws IllegalStateException {

test/jdk/java/foreign/trivial/TestTrivial.java line 74:

> 72:         VarHandle vhX = bigLayout.varHandle(MemoryLayout.PathElement.groupElement("x"));
> 73:         VarHandle vhY = bigLayout.varHandle(MemoryLayout.PathElement.groupElement("y"));
> 74:         try (Arena arena  = Arena.ofConfined()) {

nit:
Suggestion:

        try (Arena arena = Arena.ofConfined()) {

test/jdk/java/foreign/trivial/TestTrivial.java line 89:

> 87:         StructLayout capturedStateLayout = Linker.Option.captureStateLayout();
> 88:         VarHandle errnoHandle = capturedStateLayout.varHandle(MemoryLayout.PathElement.groupElement("errno"));
> 89:         try (Arena arena  = Arena.ofConfined()) {

nit
Suggestion:

        try (Arena arena = Arena.ofConfined()) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1144450371
PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1144453152
PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1144452221
PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1144451413
PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1144451634

From dholmes at openjdk.org  Wed Mar 22 09:22:00 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 22 Mar 2023 09:22:00 GMT
Subject: RFR: 8257967: JFR: Events for loaded agents [v10]
In-Reply-To: <zgOuJcuqMY3Ku0NXGiZCbsSMslc3ap0EjeLJ5umUjx0=.0d0a259f-d39b-4c9a-9b00-c2c405fa05b8@github.com>
References: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
 <ZsaBMVK-eeLfmxgg15qPJHm6C-ed5PyIE4lGr-Gnr2s=.2f4044c4-e7ed-48f3-8877-feeb2753be18@github.com>
 <zgOuJcuqMY3Ku0NXGiZCbsSMslc3ap0EjeLJ5umUjx0=.0d0a259f-d39b-4c9a-9b00-c2c405fa05b8@github.com>
Message-ID: <C3lIOuLspoBJrcA1MUpgjAmArZqAPa3ElfeXVoUGhNY=.82625f5f-aeba-4812-8769-0764a05cb4f5@github.com>

On Tue, 21 Mar 2023 00:53:31 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more cleanup
>
> src/hotspot/share/prims/jvmtiEnvBase.hpp line 166:
> 
>> 164: 
>> 165:   const void* get_env_local_storage() { return _env_local_storage; }
>> 166: 
> 
> Why was this change/move necessary? Do I miss anything?

It is now public, not protected.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12923#discussion_r1144458026

From rkennke at openjdk.org  Wed Mar 22 09:51:08 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 22 Mar 2023 09:51:08 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <ztiqECTkWnt6s0n8q0KXw4MzN2MBVqdJ1Jy0kd6JuQE=.c0872ea4-e696-43a0-b356-d5149af1cbd1@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
 <ztiqECTkWnt6s0n8q0KXw4MzN2MBVqdJ1Jy0kd6JuQE=.c0872ea4-e696-43a0-b356-d5149af1cbd1@github.com>
Message-ID: <aR4w0EwXiNzm5zpAI0H0t9v6jQAmeA-BcwVChTYVlrM=.55178ce1-0277-4c52-a3b8-cda16aed712e@github.com>

On Wed, 22 Mar 2023 00:25:43 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>>  - Set condition flags correctly after fast-lock call on aarch64
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 670:
> 
>> 668:   get_thread (scrReg);                    // beware: clobbers ICCs
>> 669:   movptr(Address(boxReg, OM_OFFSET_NO_MONITOR_VALUE_TAG(owner)), scrReg);
>> 670:   xorptr(boxReg, boxReg);                 // set icc.ZFlag = 1 to indicate success
> 
> Should this be under `if (UseFastLocking)`?

I don't think so, unless we also want to change all the stuff in x86_32.ad to not fetch the thread before calling into fast_unlock(). However, I think it is a nice and useful change. I could break it out of this PR and get it reviewed separately, it is a side-effect of the new locking impl insofar as we always require a thread register, and allocate&fetch it before going into fast_lock().

> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 791:
> 
>> 789:       Compile::current()->output()->add_stub(stub);
>> 790:       jcc(Assembler::notEqual, stub->entry());
>> 791:       bind(stub->continuation());
> 
> Why use stub here and not inline the code? Because the branch mostly not taken?

Yes, the branch is mostly not taken. If we inline the code, then we would have to take a forward branch on the very common path to skip over the (rare) part that handles ANON monitor owner. This would throw off static branch prediction and is discouraged by the Intel optimization guide.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1144501909
PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1144504528

From mcimadamore at openjdk.org  Wed Mar 22 11:57:46 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 22 Mar 2023 11:57:46 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v5]
In-Reply-To: <MtnTWtmtdQkU0RqBSp7DuSnQz0OO8Bk3HzJi7NHZDoU=.bc0c0f9f-454a-484d-9613-95b00f5af7ca@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <MtnTWtmtdQkU0RqBSp7DuSnQz0OO8Bk3HzJi7NHZDoU=.bc0c0f9f-454a-484d-9613-95b00f5af7ca@github.com>
Message-ID: <SJH6UHgJox37XpsedV_d9PZvTUfrycOKt_diWtoYO5c=.d7a45b10-42d3-492f-aff5-b5886245ff13@github.com>

On Tue, 21 Mar 2023 09:02:29 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> API changes for the FFM API (third preview)
>> 
>> Specdiff:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
>> 
>> Javadoc:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add example for Option::captureStateLayout

src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 694:

> 692:      * @param bitSize the padding size in bits.
> 693:      * @return the new selector layout.
> 694:      * @throws IllegalArgumentException if {@code bitSize < 0} or {@code bitSize % 8 != 0}

I'm not sure if this change in the `@throws` was deliberate - e.g. the new API seems to allow creation of padding layouts of zero size (which I did not realize). This can hide issues for code generators (e.g. I stumbled upon this when working on jextract, which was silently emitting zero-length paddings in some struct layouts). Perhaps better to revert to old semantics?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1144680066

From pminborg at openjdk.org  Wed Mar 22 12:10:46 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 22 Mar 2023 12:10:46 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v5]
In-Reply-To: <SJH6UHgJox37XpsedV_d9PZvTUfrycOKt_diWtoYO5c=.d7a45b10-42d3-492f-aff5-b5886245ff13@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <MtnTWtmtdQkU0RqBSp7DuSnQz0OO8Bk3HzJi7NHZDoU=.bc0c0f9f-454a-484d-9613-95b00f5af7ca@github.com>
 <SJH6UHgJox37XpsedV_d9PZvTUfrycOKt_diWtoYO5c=.d7a45b10-42d3-492f-aff5-b5886245ff13@github.com>
Message-ID: <aS49h7SJaduLKRjSabqCs4yQxKGuYDOcfejU2s0cHkQ=.189a240a-f460-42f3-8334-7873296929fd@github.com>

On Wed, 22 Mar 2023 11:55:09 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add example for Option::captureStateLayout
>
> src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 694:
> 
>> 692:      * @param bitSize the padding size in bits.
>> 693:      * @return the new selector layout.
>> 694:      * @throws IllegalArgumentException if {@code bitSize < 0} or {@code bitSize % 8 != 0}
> 
> I'm not sure if this change in the `@throws` was deliberate - e.g. the new API seems to allow creation of padding layouts of zero size (which I did not realize). This can hide issues for code generators (e.g. I stumbled upon this when working on jextract, which was silently emitting zero-length paddings in some struct layouts). Perhaps better to revert to old semantics?

Agreed. Having zero-length padding does not make much sense.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1144707890

From pminborg at openjdk.org  Wed Mar 22 12:28:14 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 22 Mar 2023 12:28:14 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v6]
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <MHpaK7KKdxcC8zsUlJZTznmqHfwSDeYB9pNYi9TxNy4=.6c70426b-fd02-408b-8d65-7e7ec82a6ec2@github.com>

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

Per Minborg has updated the pull request incrementally with two additional commits since the last revision:

 - Fix formating and modifier order
 - Fix typo -> shared arena

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/21ef0607..192050d6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=04-05

  Stats: 6 lines in 5 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/13079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13079/head:pull/13079

PR: https://git.openjdk.org/jdk/pull/13079

From coleenp at openjdk.org  Wed Mar 22 12:36:54 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 22 Mar 2023 12:36:54 GMT
Subject: RFR: 8304089: Convert TraceDependencies to UL [v5]
In-Reply-To: <iy21P3-_eQnuA6cuPbMkGhFpZoeHJf4vuSrCQ-ScRdU=.c9246e41-996d-472e-9b92-5569835e4c7d@github.com>
References: <0aGc1NdAjpvksCWmXb1gZOPp9MV0n6xWvG8EaEp2ZLg=.b79cf218-9a23-420d-bec5-7509b7f8f1c1@github.com>
 <iy21P3-_eQnuA6cuPbMkGhFpZoeHJf4vuSrCQ-ScRdU=.c9246e41-996d-472e-9b92-5569835e4c7d@github.com>
Message-ID: <8MoLfNrpMWxIi4YI8BzYzYa0i59kTkfCvI3I1QP2QL0=.64d3f6e9-4f02-4637-984a-f2c251cb0080@github.com>

On Tue, 21 Mar 2023 17:12:00 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change converts TraceDependencies to UL and removes the develop option. I think this provides further flexibility to add tags to only trace certain things in dependency analysis, as I did when trying to understand a PR for a deoptimization change.  For now, the messages are the same and the option is -Xlog:dependencies=debug.
>> Tested with tier1-4
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Drop UL check for log file output (still have PrintDependencies).

Thank you Vladimir and David.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13007#issuecomment-1479491476

From coleenp at openjdk.org  Wed Mar 22 12:36:57 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 22 Mar 2023 12:36:57 GMT
Subject: Integrated: 8304089: Convert TraceDependencies to UL
In-Reply-To: <0aGc1NdAjpvksCWmXb1gZOPp9MV0n6xWvG8EaEp2ZLg=.b79cf218-9a23-420d-bec5-7509b7f8f1c1@github.com>
References: <0aGc1NdAjpvksCWmXb1gZOPp9MV0n6xWvG8EaEp2ZLg=.b79cf218-9a23-420d-bec5-7509b7f8f1c1@github.com>
Message-ID: <j7WXcChWpRfcLkaU2OP8I2NFzTqt7oWRVL99WSBnGeg=.3a53da0c-82b2-49bc-a187-176b1d914003@github.com>

On Mon, 13 Mar 2023 21:32:14 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change converts TraceDependencies to UL and removes the develop option. I think this provides further flexibility to add tags to only trace certain things in dependency analysis, as I did when trying to understand a PR for a deoptimization change.  For now, the messages are the same and the option is -Xlog:dependencies=debug.
> Tested with tier1-4

This pull request has now been integrated.

Changeset: ddf1e34c
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ddf1e34c1a0815e8677212f1a7860ca7cf9fc2c9
Stats:     78 lines in 14 files changed: 22 ins; 4 del; 52 mod

8304089: Convert TraceDependencies to UL

Reviewed-by: vlivanov, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/13007

From coleenp at openjdk.org  Wed Mar 22 12:43:25 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 22 Mar 2023 12:43:25 GMT
Subject: RFR: 8304687: Move add_to_hierarchy [v2]
In-Reply-To: <8lZkIOj_sW-s5fenIUyqOflXokTscrf8v6Zi6VOic4o=.847bbf8a-430b-46f5-a4c2-335d3355c320@github.com>
References: <8lZkIOj_sW-s5fenIUyqOflXokTscrf8v6Zi6VOic4o=.847bbf8a-430b-46f5-a4c2-335d3355c320@github.com>
Message-ID: <88wO6xUBgdQseupIPo93t7gKRlhKgME3O98C-dKwmbI=.e21b9600-a2f4-43cf-9e7d-9241f704d20a@github.com>

> Moved SystemDictionary::add_to_hierarchy to InstanceKlass::add_to_hierarchy where it more logically belongs and next to other functions that also care about dependencies.
> Tested with tier1-4, and tier1 on linux,windows,macos to check header file changes.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Add back method.inline.hpp include

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13129/files
  - new: https://git.openjdk.org/jdk/pull/13129/files/cd8c564a..b86abf50

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13129&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13129&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13129.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13129/head:pull/13129

PR: https://git.openjdk.org/jdk/pull/13129

From qamai at openjdk.org  Wed Mar 22 12:46:33 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 22 Mar 2023 12:46:33 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v4]
In-Reply-To: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
Message-ID: <laGpMIPjIolDVaoKarrUxW0DciC7zHgpkGCgAc_bnO4=.c4c8252f-ff6a-4a79-9706-c120e2f96f94@github.com>

> Hi,
> 
> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, VectorShuffle is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
> 
> 1. Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
> 2. Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
> 3. Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
> 4. Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
> 
> Upon these changes, a `rearrange` can emit more efficient code:
> 
>     var species = IntVector.SPECIES_128;
>     var v1 = IntVector.fromArray(species, SRC1, 0);
>     var v2 = IntVector.fromArray(species, SRC2, 0);
>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
> 
>     Before:
>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>     vmovdqu 0x10(%r10),%xmm2
>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>     vmovdqu 0x10(%r10),%xmm1
>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>     vmovdqu 0x10(%r10),%xmm0
>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>                                                             ;   {external_word}
>     vpackusdw %xmm0,%xmm0,%xmm0
>     vpackuswb %xmm0,%xmm0,%xmm0
>     vpmovsxbd %xmm0,%xmm3
>     vpcmpgtd %xmm3,%xmm1,%xmm3
>     vtestps %xmm3,%xmm3
>     jne    0x00007fc2acb4e0d8
>     vpmovzxbd %xmm0,%xmm0
>     vpermd %ymm2,%ymm0,%ymm0
>     movabs $0x751588f98,%r10            ;   {oop([I{0x0000000751588f98})}
>     vmovdqu %xmm0,0x10(%r10)
> 
>     After:
>     movabs $0x751589c78,%r10            ;   {oop([I{0x0000000751589c78})}
>     vmovdqu 0x10(%r10),%xmm1
>     movabs $0x75158ac88,%r10            ;   {oop([I{0x000000075158ac88})}
>     vmovdqu 0x10(%r10),%xmm2
>     vpxor  %xmm0,%xmm0,%xmm0
>     vpcmpgtd %xmm2,%xmm0,%xmm3
>     vtestps %xmm3,%xmm3
>     jne    0x00007fa818b27cb1
>     vpermd %ymm1,%ymm2,%ymm0
>     movabs $0x751588c68,%r10            ;   {oop([I{0x0000000751588c68})}
>     vmovdqu %xmm0,0x10(%r10)
>     
> Please take a look and leave reviews. Thanks a lot.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  reviews

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13093/files
  - new: https://git.openjdk.org/jdk/pull/13093/files/4caa9d10..e0b9ee88

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13093&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13093&range=02-03

  Stats: 17 lines in 5 files changed: 0 ins; 0 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/13093.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13093/head:pull/13093

PR: https://git.openjdk.org/jdk/pull/13093

From qamai at openjdk.org  Wed Mar 22 12:46:36 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 22 Mar 2023 12:46:36 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v3]
In-Reply-To: <LBxWDJJAhoJ_U8PCWEhrQ27bXZqOx2vpnl4FGIgb7mk=.a7f55998-3191-432a-92e0-c1749078028e@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
 <4Op0Z8whnyDXDC6zGyMbx4ugcZp5TEoAqW_myB5flxM=.1c7b59ba-efb2-4f68-90d7-2d6e33e39572@github.com>
 <LBxWDJJAhoJ_U8PCWEhrQ27bXZqOx2vpnl4FGIgb7mk=.a7f55998-3191-432a-92e0-c1749078028e@github.com>
Message-ID: <sk46E93x2K3ATiE0P3-MwyRr6wqLatHOmT31gQcLryo=.f151f956-0234-4b5d-9e51-a3cdba36aa76@github.com>

On Wed, 22 Mar 2023 08:09:03 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - missing casts
>>  - clean up
>
> Please also update the copyright to 2023 for some touched files like `vectorSupport.hpp` and other java files like `AbstractShuffle.java`, `AbstractVector.java`, `VectorShape.java`, and `VectorShuffle.java`. Thanks!

@XiaohongGong Thanks, I have updated the copyright year and the code styles as you suggested

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13093#issuecomment-1479500096

From qamai at openjdk.org  Wed Mar 22 12:46:39 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 22 Mar 2023 12:46:39 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v4]
In-Reply-To: <yPyZ7su4OnRDd5LyQPvU0Hk6n5AI5CO2lR12qO9efCg=.51a05574-aee6-416b-863c-76d38a6766c3@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
 <4Op0Z8whnyDXDC6zGyMbx4ugcZp5TEoAqW_myB5flxM=.1c7b59ba-efb2-4f68-90d7-2d6e33e39572@github.com>
 <yPyZ7su4OnRDd5LyQPvU0Hk6n5AI5CO2lR12qO9efCg=.51a05574-aee6-416b-863c-76d38a6766c3@github.com>
Message-ID: <U-1I398elh4CJBPi5J2fEF14qp9ZgoYFhXxMD70L1wI=.2cecacd5-4fb6-4194-a5e4-c1801e0b7691@github.com>

On Wed, 22 Mar 2023 07:59:40 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reviews
>
> src/hotspot/share/opto/vectorIntrinsics.cpp line 2059:
> 
>> 2057:   if (need_load_shuffle) {
>> 2058:     shuffle = gvn().transform(new VectorLoadShuffleNode(shuffle, vt));
>> 2059:   }
> 
> How about generating `VectorLoadShuffleNode` for all platforms that support Vector API, and remove the helper method `vector_needs_load_shuffle()` ? For those platforms that do not need this shuffle preparation, we can emit nothing  in codegen.

I think not emitting `VectorLoadShuffleNode` is more common so it is better to emit them only when needed, as it will simplify the graph and may allow better inspections of the indices in the future. Additionally, a do-nothing node does not alias with its input and therefore kills the input, which leads to an additional spill if they both need to live.

> src/hotspot/share/opto/vectorIntrinsics.cpp line 2426:
> 
>> 2424:   if (is_vector_shuffle(vbox_klass_from)) {
>> 2425:     return false; // vector shuffles aren't supported
>> 2426:   }
> 
> Is it better to change this as an "assertion" or print the log details?

The change indifferentiates a vector shuffle from a normal vector in C2, so this should be removed, as vector shuffles are converted to/from normal vector using this routine

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1144748489
PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1144744663

From coleenp at openjdk.org  Wed Mar 22 13:03:27 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 22 Mar 2023 13:03:27 GMT
Subject: RFR: 8304687: Move add_to_hierarchy [v3]
In-Reply-To: <8lZkIOj_sW-s5fenIUyqOflXokTscrf8v6Zi6VOic4o=.847bbf8a-430b-46f5-a4c2-335d3355c320@github.com>
References: <8lZkIOj_sW-s5fenIUyqOflXokTscrf8v6Zi6VOic4o=.847bbf8a-430b-46f5-a4c2-335d3355c320@github.com>
Message-ID: <uvX0ErUTjbuJJA0ltRxjsN91f1PkRgGi4lB1_MqRtBY=.bef41eef-e154-469b-85a6-ff886029aa78@github.com>

> Moved SystemDictionary::add_to_hierarchy to InstanceKlass::add_to_hierarchy where it more logically belongs and next to other functions that also care about dependencies.
> Tested with tier1-4, and tier1 on linux,windows,macos to check header file changes.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Correct comments referring to SystemDictionary::add_to_hierarchy

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13129/files
  - new: https://git.openjdk.org/jdk/pull/13129/files/b86abf50..31c5a9c7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13129&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13129&range=01-02

  Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/13129.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13129/head:pull/13129

PR: https://git.openjdk.org/jdk/pull/13129

From pminborg at openjdk.org  Wed Mar 22 13:58:35 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 22 Mar 2023 13:58:35 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v7]
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <uTRqJUGYsaK9AMwCr7AxGMYjG3wXpoeC5QWiuyl3Jnc=.ec51f592-d340-4177-9a33-2d7df2da5f99@github.com>

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Disalow padding layouts of size zero

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/192050d6..45febe9d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=05-06

  Stats: 10 lines in 2 files changed: 3 ins; 5 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13079/head:pull/13079

PR: https://git.openjdk.org/jdk/pull/13079

From jbechberger at openjdk.org  Wed Mar 22 14:08:55 2023
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 22 Mar 2023 14:08:55 GMT
Subject: Withdrawn: 8303444: AsyncGetCallTrace obtains too few frames with
 instrumentation agent
In-Reply-To: <rAvZDo493q-tR1yf02t2ObLyUzt5DVpd90g1GogCNW8=.19d9c95f-38b0-4acc-8411-8494ced5079f@github.com>
References: <rAvZDo493q-tR1yf02t2ObLyUzt5DVpd90g1GogCNW8=.19d9c95f-38b0-4acc-8411-8494ced5079f@github.com>
Message-ID: <oH814ur7YFD9PKbcCaQz4kj37_MIiYW0HMAzCmDzPDM=.5659cdd2-0dcc-46d7-b44f-4d104402b5e0@github.com>

On Wed, 1 Mar 2023 12:32:19 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> This fixes the bug by removing the faulty completeness check for runtime blobs.
> 
> I tested it using the [trace_validation](https://github.com/parttimenerd/trace_validation) tool successfully as described in the issue. I furthermore ran the [jdk-profiling-tester](https://github.com/parttimenerd/jdk-profiling-tester) to ensure that this fix did not introduce any stability issues and ran the serviceability JTREG tests successfully.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/12804

From pminborg at openjdk.org  Wed Mar 22 14:09:07 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 22 Mar 2023 14:09:07 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Improve javadocs for Linker::captureStateLayout

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/45febe9d..6df28a78

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=06-07

  Stats: 11 lines in 1 file changed: 0 ins; 1 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/13079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13079/head:pull/13079

PR: https://git.openjdk.org/jdk/pull/13079

From pminborg at openjdk.org  Wed Mar 22 14:09:56 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 22 Mar 2023 14:09:56 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: <pYRtChaFVMs_cb5b2yJOF5-sgqyjzFpO3k_fkNH8Ezo=.3acc93cd-65b4-4722-8761-7f4e725fe68c@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <ewzYWsxSa9yHV7LwF7JOOD2PMOx1FeCNCRwgGDnTFd0=.42c628eb-3cdf-4f45-a4fe-da481850d834@github.com>
 <pYRtChaFVMs_cb5b2yJOF5-sgqyjzFpO3k_fkNH8Ezo=.3acc93cd-65b4-4722-8761-7f4e725fe68c@github.com>
Message-ID: <jPVaoTe4yDNcopVbNL3HV2reRvc7C_wLR1uRdhfkgNM=.bd715322-36b4-4bfb-bee7-b25fa61fc73e@github.com>

On Tue, 21 Mar 2023 12:12:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/foreign/Linker.java line 621:
>> 
>>> 619:          *          to a downcall handle linked with {@link #captureCallState(String...)}}
>>> 620:          *
>>> 621:          * @see #captureCallState(String...)
>> 
>> How does a caller know what the structure may contain? Should we document the platform specific structures?
>
> Back to @PaulSandoz  question - "how does the caller know what the structure contains?". The caller typically doesn't care too much about what the returned struct is. But it might care about which "values" can be captured. That said, the set of such interesting values, is not too surprising. As demonstrated in the example in the `Linker.capturedCallState` method, once the client knows the name (and "errno" is likely to be 90% case), everything else follows from there - as the layout can be used to obtain var handles for the required values.
> 
> But, perhaps, now that I write this, I realize that what @PaulSandoz might _really_ be asking is: how do I know that e.g. the returned struct will not contain e.g. nested structs, sequences, or other non-sense. So we might specify (in a normative way) that the returned layout is a struct layout, whose member layouts are one or more value layouts (possibly with some added padding layouts). The names of the value layouts reflect the names of the values that can be captured.
> 
> And _then_ we show an example of the layout we return for Windows/x64 (as that's more interesting).

I've updated the specs as per how I interpret the comments above. Let me know your thoughts on this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1144872865

From jsjolen at openjdk.org  Wed Mar 22 14:22:01 2023
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 22 Mar 2023 14:22:01 GMT
Subject: RFR: JDK-8301498: Replace NULL with nullptr in cpu/x86 [v4]
In-Reply-To: <K21IuPJG7Tk7Kjvsp1MFiE67n5iDJlezp369mHL1mdE=.6f1d309e-3ac8-4758-b38d-5bc21ce232e9@github.com>
References: <AB1094dam2aXNm_hav09Ium0jqJUCJE0hmJ4GfljA5M=.4e8e0845-20d5-45bf-bf2e-1d23ed8ef9f0@github.com>
 <K21IuPJG7Tk7Kjvsp1MFiE67n5iDJlezp369mHL1mdE=.6f1d309e-3ac8-4758-b38d-5bc21ce232e9@github.com>
Message-ID: <0A-D-P6RuP8u8dtlXBf5ox_2-15SnHi_ixwC5MZW5OM=.0971e7bf-5380-42ce-a496-eedd8cf2fff8@github.com>

On Tue, 21 Mar 2023 10:04:04 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory cpu/x86. Unfortunately the script that does the change isn't perfect, and so we
>> need to comb through these manually to make sure nothing has gone wrong. I also review these changes but things slip past my eyes sometimes.
>> 
>> Here are some typical things to look out for:
>> 
>> 1. No changes but copyright header changed (probably because I reverted some changes but forgot the copyright).
>> 2. Macros having their NULL changed to nullptr, these are added to the script when I find them. They should be NULL.
>> 3. nullptr in comments and logs. We try to use lower case "null" in these cases as it reads better. An exception is made when code expressions are in a comment.
>> 
>> An example of this:
>> 
>> ```c++
>> // This function returns null
>> void* ret_null();
>> // This function returns true if *x == nullptr
>> bool is_nullptr(void** x);
>> 
>> 
>> Note how `nullptr` participates in a code expression here, we really are talking about the specific value `nullptr`.
>> 
>> Thanks!
>
> Johan Sj?len has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge remote-tracking branch 'origin/master' into JDK-8301498
>  - Fix vnkozlov's suggestions
>  - Merge remote-tracking branch 'origin/master' into JDK-8301498
>  - Some more fixes
>  - Fixes
>  -  Replace NULL with nullptr in cpu/x86

Thanks. All of tier1 and tier2 is passing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12326#issuecomment-1479646756

From jsjolen at openjdk.org  Wed Mar 22 14:22:02 2023
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 22 Mar 2023 14:22:02 GMT
Subject: Integrated: JDK-8301498: Replace NULL with nullptr in cpu/x86
In-Reply-To: <AB1094dam2aXNm_hav09Ium0jqJUCJE0hmJ4GfljA5M=.4e8e0845-20d5-45bf-bf2e-1d23ed8ef9f0@github.com>
References: <AB1094dam2aXNm_hav09Ium0jqJUCJE0hmJ4GfljA5M=.4e8e0845-20d5-45bf-bf2e-1d23ed8ef9f0@github.com>
Message-ID: <oYs3hdtfHh2F7iDCefcOXwOBh5Jrn_lBgzjP26tLKaE=.0970b78a-7e65-48dc-963d-3dc9a35a7e00@github.com>

On Tue, 31 Jan 2023 11:40:19 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory cpu/x86. Unfortunately the script that does the change isn't perfect, and so we
> need to comb through these manually to make sure nothing has gone wrong. I also review these changes but things slip past my eyes sometimes.
> 
> Here are some typical things to look out for:
> 
> 1. No changes but copyright header changed (probably because I reverted some changes but forgot the copyright).
> 2. Macros having their NULL changed to nullptr, these are added to the script when I find them. They should be NULL.
> 3. nullptr in comments and logs. We try to use lower case "null" in these cases as it reads better. An exception is made when code expressions are in a comment.
> 
> An example of this:
> 
> ```c++
> // This function returns null
> void* ret_null();
> // This function returns true if *x == nullptr
> bool is_nullptr(void** x);
> 
> 
> Note how `nullptr` participates in a code expression here, we really are talking about the specific value `nullptr`.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 4154a980
Author:    Johan Sj?len <jsjolen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4154a980ca28c1ae56db26e3dce64c07c225de12
Stats:     656 lines in 54 files changed: 0 ins; 0 del; 656 mod

8301498: Replace NULL with nullptr in cpu/x86

Reviewed-by: dholmes, kvn

-------------

PR: https://git.openjdk.org/jdk/pull/12326

From mcimadamore at openjdk.org  Wed Mar 22 14:38:30 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 22 Mar 2023 14:38:30 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
Message-ID: <Iu1RS7_q9ZObK7zlXpfAlipAD1qeMyGBxa_QQS5Qx8E=.e24807ba-abb5-4189-9870-6d3830c6d7a6@github.com>

On Wed, 22 Mar 2023 14:09:07 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> API changes for the FFM API (third preview)
>> 
>> Specdiff:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
>> 
>> Javadoc:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve javadocs for Linker::captureStateLayout

src/java.base/share/classes/java/lang/foreign/Linker.java line 628:

> 626:          * and possibly {@linkplain PaddingLayout padding layouts}.
> 627:          * As an example, on Windows, the returned layout might contain three value layouts named:
> 628:          * <ul>

Almost there - instead of listing the names, just put a code snippet with the struct layout! That will make it crystal clear.

src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 697:

> 695:      */
> 696:     static PaddingLayout paddingLayout(long bitSize) {
> 697:         if (bitSize <= 0) {

While this does the right thing, I wonder if we can do better, as it seems we're checking size twice - perhaps we need to customize the `requireBitSizeValid` function?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1144915578
PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1144917200

From coleenp at openjdk.org  Wed Mar 22 15:31:21 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 22 Mar 2023 15:31:21 GMT
Subject: RFR: 8304687: Move add_to_hierarchy [v4]
In-Reply-To: <8lZkIOj_sW-s5fenIUyqOflXokTscrf8v6Zi6VOic4o=.847bbf8a-430b-46f5-a4c2-335d3355c320@github.com>
References: <8lZkIOj_sW-s5fenIUyqOflXokTscrf8v6Zi6VOic4o=.847bbf8a-430b-46f5-a4c2-335d3355c320@github.com>
Message-ID: <3T0hPcnNGHYDFq8bQUFyppY2hGNbeRBoKMJ2EDaqh-c=.6205cb5e-97e8-4d7e-a619-82646abb19f6@github.com>

> Moved SystemDictionary::add_to_hierarchy to InstanceKlass::add_to_hierarchy where it more logically belongs and next to other functions that also care about dependencies.
> Tested with tier1-4, and tier1 on linux,windows,macos to check header file changes.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Revert another include file deletion

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13129/files
  - new: https://git.openjdk.org/jdk/pull/13129/files/31c5a9c7..35ee5111

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13129&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13129&range=02-03

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13129.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13129/head:pull/13129

PR: https://git.openjdk.org/jdk/pull/13129

From jcking at openjdk.org  Wed Mar 22 15:31:33 2023
From: jcking at openjdk.org (Justin King)
Date: Wed, 22 Mar 2023 15:31:33 GMT
Subject: RFR: JDK-8304723: Statically allocate global mutexes
Message-ID: <GnX35HIFItX1KV3Zsg5l-zwZVkhP_4Hq5o5ZhtiO57w=.94a86c58-3910-4b52-8c2f-3d6aaf713a06@github.com>

Switch to statically allocate storage for all of Hotspot's global mutexes and monitors. This avoids needing to allocate each one dynamically at startup. These also live for the lifetime of the program, so this reduces any potential memory fragmention in the C heap.

-------------

Commit messages:
 - Avoid dynamically allocating statically defined mutexes and monitors

Changes: https://git.openjdk.org/jdk/pull/13143/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13143&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304723
  Stats: 410 lines in 13 files changed: 69 ins; 11 del; 330 mod
  Patch: https://git.openjdk.org/jdk/pull/13143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13143/head:pull/13143

PR: https://git.openjdk.org/jdk/pull/13143

From jcking at openjdk.org  Wed Mar 22 15:31:53 2023
From: jcking at openjdk.org (Justin King)
Date: Wed, 22 Mar 2023 15:31:53 GMT
Subject: Integrated: JDK-8304683: Memory leak in WB_IsMethodCompatible
In-Reply-To: <4V-_5ZAkbj0Kw1UsgBnat-JrwffKM_mHRNmWZwB3ox8=.94ce5e0d-9552-4a96-9bb1-8a3f26c2dd7f@github.com>
References: <4V-_5ZAkbj0Kw1UsgBnat-JrwffKM_mHRNmWZwB3ox8=.94ce5e0d-9552-4a96-9bb1-8a3f26c2dd7f@github.com>
Message-ID: <VQJ2kf3091jn-YEvVVUL8qPopBFQaJbz2y7lmQbXivI=.45efe9b9-5828-452a-ab0c-32342f241dc7@github.com>

On Tue, 21 Mar 2023 16:45:30 GMT, Justin King <jcking at openjdk.org> wrote:

> Add missing call to `DirectivesStack::release`.

This pull request has now been integrated.

Changeset: 760c0128
Author:    Justin King <jcking at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/760c0128a4ef787c8c8addb26894c072ba8b2eb1
Stats:     4 lines in 1 file changed: 0 ins; 1 del; 3 mod

8304683: Memory leak in WB_IsMethodCompatible

Reviewed-by: thartmann

-------------

PR: https://git.openjdk.org/jdk/pull/13124

From coleenp at openjdk.org  Wed Mar 22 15:53:43 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 22 Mar 2023 15:53:43 GMT
Subject: RFR: JDK-8304723: Statically allocate global mutexes
In-Reply-To: <GnX35HIFItX1KV3Zsg5l-zwZVkhP_4Hq5o5ZhtiO57w=.94a86c58-3910-4b52-8c2f-3d6aaf713a06@github.com>
References: <GnX35HIFItX1KV3Zsg5l-zwZVkhP_4Hq5o5ZhtiO57w=.94a86c58-3910-4b52-8c2f-3d6aaf713a06@github.com>
Message-ID: <W5c2m-vvTaYgkE_XIgyfQ3aYag2YstbMPv7LGhtFvm8=.319fa30e-f399-4780-a135-e4e8838d2385@github.com>

On Wed, 22 Mar 2023 15:23:59 GMT, Justin King <jcking at openjdk.org> wrote:

> Switch to statically allocate storage for all of Hotspot's global mutexes and monitors. This avoids needing to allocate each one dynamically at startup. These also live for the lifetime of the program, so this reduces any potential memory fragmention in the C heap.

I have to say that I don't like this change.  I don't want to see the noisy .get() everywhere.  Can you do this without .get()?

-------------

Changes requested by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13143#pullrequestreview-1352952348

From duke at openjdk.org  Wed Mar 22 15:59:29 2023
From: duke at openjdk.org (Jan Kratochvil)
Date: Wed, 22 Mar 2023 15:59:29 GMT
Subject: Integrated: 8302191: Performance degradation for float/double modulo
 on Linux
In-Reply-To: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
References: <S1b4Ve9K2XCIgYvvciDhsdbGRsGB5MTIzuAZia_R5Ro=.a2e9fe08-99b2-4a05-8e91-22a06b44d66d@github.com>
Message-ID: <ZCIOCK85zpSaqphoKdS2y6yZHqqZljTBNUFMC9YulCA=.bceac9da-7d6b-4076-98cc-9973da915b7f@github.com>

On Fri, 10 Feb 2023 09:06:56 GMT, Jan Kratochvil <duke at openjdk.org> wrote:

> I have OCA already processed/approved. I am not Author but my Author request is being processed these days (sent to Rob McKenna).
> I did regression test x86_64 OpenJDK-8. I will leave other regression testing on GHA.
> The patch (and former GCC performance regression) affects only x86_64+i686.

This pull request has now been integrated.

Changeset: 37774556
Author:    Jan Kratochvil <jkratochvil at azul.com>
Committer: Sandhya Viswanathan <sviswanathan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/37774556da8a5aacf55884133ae936ed5a28eab2
Stats:     267 lines in 3 files changed: 265 ins; 1 del; 1 mod

8302191: Performance degradation for float/double modulo on Linux

Reviewed-by: dholmes, sviswanathan

-------------

PR: https://git.openjdk.org/jdk/pull/12508

From pminborg at openjdk.org  Wed Mar 22 16:18:47 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 22 Mar 2023 16:18:47 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: <Iu1RS7_q9ZObK7zlXpfAlipAD1qeMyGBxa_QQS5Qx8E=.e24807ba-abb5-4189-9870-6d3830c6d7a6@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
 <Iu1RS7_q9ZObK7zlXpfAlipAD1qeMyGBxa_QQS5Qx8E=.e24807ba-abb5-4189-9870-6d3830c6d7a6@github.com>
Message-ID: <L3Iof3hrKFzHZV7zw8jTKT-tzCkaV2sBMZE8tszHC30=.be7d7dbd-1aa0-4b7e-a224-e07db7f21d16@github.com>

On Wed, 22 Mar 2023 14:35:42 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve javadocs for Linker::captureStateLayout
>
> src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 697:
> 
>> 695:      */
>> 696:     static PaddingLayout paddingLayout(long bitSize) {
>> 697:         if (bitSize <= 0) {
> 
> While this does the right thing, I wonder if we can do better, as it seems we're checking size twice - perhaps we need to customize the `requireBitSizeValid` function?

I tried that but it turned out it can be zero in other contexts. Maybe we should add back the good 'ole "allowZero" flag?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1145052056

From jbechberger at openjdk.org  Wed Mar 22 16:20:57 2023
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 22 Mar 2023 16:20:57 GMT
Subject: RFR: 8304725: AsyncGetCallTrace can cause SIGBUS on M1
Message-ID: <XtBvYsLSljF-NTYtEuYvx35NrdX3-VSu_MmirMCLfKc=.3b4e81e3-d53e-445e-85e4-0fb5e6ded7be@github.com>

Fixes the issue by transitioning the thread into the WXWrite mode while walking the stack in AsyncGetCallTrace.

Tested on my M1 mac.

-------------

Commit messages:
 - Fix 8304725

Changes: https://git.openjdk.org/jdk/pull/13144/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13144&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304725
  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13144.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13144/head:pull/13144

PR: https://git.openjdk.org/jdk/pull/13144

From jcking at openjdk.org  Wed Mar 22 16:26:51 2023
From: jcking at openjdk.org (Justin King)
Date: Wed, 22 Mar 2023 16:26:51 GMT
Subject: RFR: JDK-8304723: Statically allocate global mutexes
In-Reply-To: <GnX35HIFItX1KV3Zsg5l-zwZVkhP_4Hq5o5ZhtiO57w=.94a86c58-3910-4b52-8c2f-3d6aaf713a06@github.com>
References: <GnX35HIFItX1KV3Zsg5l-zwZVkhP_4Hq5o5ZhtiO57w=.94a86c58-3910-4b52-8c2f-3d6aaf713a06@github.com>
Message-ID: <hVs7UJC0_vjwZGy7RCkcbmoAiW58kz6AhTdpWdnDSKY=.b404953c-59a6-4d68-8e70-ff5d9d338151@github.com>

On Wed, 22 Mar 2023 15:23:59 GMT, Justin King <jcking at openjdk.org> wrote:

> Switch to statically allocate storage for all of Hotspot's global mutexes and monitors. This avoids needing to allocate each one dynamically at startup. These also live for the lifetime of the program, so this reduces any potential memory fragmention in the C heap.

Or something like `ReentrantMutexLocker`, since its technically making sure not to re-lock a mutex the calling thread already owners.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13143#issuecomment-1479885723

From jcking at openjdk.org  Wed Mar 22 16:26:49 2023
From: jcking at openjdk.org (Justin King)
Date: Wed, 22 Mar 2023 16:26:49 GMT
Subject: RFR: JDK-8304723: Statically allocate global mutexes
In-Reply-To: <W5c2m-vvTaYgkE_XIgyfQ3aYag2YstbMPv7LGhtFvm8=.319fa30e-f399-4780-a135-e4e8838d2385@github.com>
References: <GnX35HIFItX1KV3Zsg5l-zwZVkhP_4Hq5o5ZhtiO57w=.94a86c58-3910-4b52-8c2f-3d6aaf713a06@github.com>
 <W5c2m-vvTaYgkE_XIgyfQ3aYag2YstbMPv7LGhtFvm8=.319fa30e-f399-4780-a135-e4e8838d2385@github.com>
Message-ID: <dTcc7RWXgVpjtmrjSjvli__L1qV7kzliQQw6aPQef1U=.ac53314a-68e7-411a-9633-15cb907632a9@github.com>

On Wed, 22 Mar 2023 15:51:12 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I have to say that I don't like this change. I don't want to see the noisy .get() everywhere. Can you do this without .get()?

It's possible, but would require a little more work. The compilers don't like a ternary where one of the branches is `nullptr`. One option would be to come up with something where the mutex or lock returned itself if it is not owned by the calling thread otherwise nullptr. Or introduce something like `MutexLockerIf` which takes a bool as its first constructor argument and makes the mutex `nullptr` if the condition is not true. Opinions?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13143#issuecomment-1479882138

From mcimadamore at openjdk.org  Wed Mar 22 16:53:45 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 22 Mar 2023 16:53:45 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: <L3Iof3hrKFzHZV7zw8jTKT-tzCkaV2sBMZE8tszHC30=.be7d7dbd-1aa0-4b7e-a224-e07db7f21d16@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
 <Iu1RS7_q9ZObK7zlXpfAlipAD1qeMyGBxa_QQS5Qx8E=.e24807ba-abb5-4189-9870-6d3830c6d7a6@github.com>
 <L3Iof3hrKFzHZV7zw8jTKT-tzCkaV2sBMZE8tszHC30=.be7d7dbd-1aa0-4b7e-a224-e07db7f21d16@github.com>
Message-ID: <7ShkwGh4K35ZoSJ13mwrlp-VDg0NCIDeiNGoV8lYwJE=.39fe2eaf-d253-4853-9438-bd9de7a1864b@github.com>

On Wed, 22 Mar 2023 15:57:16 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 697:
>> 
>>> 695:      */
>>> 696:     static PaddingLayout paddingLayout(long bitSize) {
>>> 697:         if (bitSize <= 0) {
>> 
>> While this does the right thing, I wonder if we can do better, as it seems we're checking size twice - perhaps we need to customize the `requireBitSizeValid` function?
>
> I tried that but it turned out it can be zero in other contexts. Maybe we should add back the good 'ole "allowZero" flag?

yeah , a boolean seems good enough

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1145136161

From jcking at openjdk.org  Wed Mar 22 17:24:28 2023
From: jcking at openjdk.org (Justin King)
Date: Wed, 22 Mar 2023 17:24:28 GMT
Subject: RFR: JDK-8304723: Statically allocate global mutexes [v2]
In-Reply-To: <GnX35HIFItX1KV3Zsg5l-zwZVkhP_4Hq5o5ZhtiO57w=.94a86c58-3910-4b52-8c2f-3d6aaf713a06@github.com>
References: <GnX35HIFItX1KV3Zsg5l-zwZVkhP_4Hq5o5ZhtiO57w=.94a86c58-3910-4b52-8c2f-3d6aaf713a06@github.com>
Message-ID: <qfME5gCVpGeIyyPDHR68gO5ZAb1xprwIV7smWrvmHXk=.f97b2e36-599b-49d6-b2a1-731d8b011188@github.com>

> Switch to statically allocate storage for all of Hotspot's global mutexes and monitors. This avoids needing to allocate each one dynamically at startup. These also live for the lifetime of the program, so this reduces any potential memory fragmention in the C heap.

Justin King has updated the pull request incrementally with one additional commit since the last revision:

  Fix lock being initialized twice and lock never initialized
  
  Signed-off-by: Justin King <jcking at google.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13143/files
  - new: https://git.openjdk.org/jdk/pull/13143/files/b356520d..54263bd1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13143&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13143&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13143/head:pull/13143

PR: https://git.openjdk.org/jdk/pull/13143

From jcking at openjdk.org  Wed Mar 22 17:24:29 2023
From: jcking at openjdk.org (Justin King)
Date: Wed, 22 Mar 2023 17:24:29 GMT
Subject: RFR: JDK-8304723: Statically allocate global mutexes
In-Reply-To: <GnX35HIFItX1KV3Zsg5l-zwZVkhP_4Hq5o5ZhtiO57w=.94a86c58-3910-4b52-8c2f-3d6aaf713a06@github.com>
References: <GnX35HIFItX1KV3Zsg5l-zwZVkhP_4Hq5o5ZhtiO57w=.94a86c58-3910-4b52-8c2f-3d6aaf713a06@github.com>
Message-ID: <E2k8AEpB6oyawWurmdA4rYuDrht945Jr94rUf-yKkyw=.1fe0f5da-e702-4f52-ad3a-bc858d1bf846@github.com>

On Wed, 22 Mar 2023 15:23:59 GMT, Justin King <jcking at openjdk.org> wrote:

> Switch to statically allocate storage for all of Hotspot's global mutexes and monitors. This avoids needing to allocate each one dynamically at startup. These also live for the lifetime of the program, so this reduces any potential memory fragmention in the C heap.

This has also surfaced two existing bugs:  `UnregisteredClassesTable_lock` is never created and always `nullptr` and `Heap_lock` is created twice.

@dholmes-ora I assume I should fix those two issues in a separate PR. Should `UnregisteredClassesTable_lock` be `nosafepoint`?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13143#issuecomment-1479965043

From stuefe at openjdk.org  Wed Mar 22 17:24:31 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 22 Mar 2023 17:24:31 GMT
Subject: RFR: JDK-8304723: Statically allocate global mutexes
In-Reply-To: <GnX35HIFItX1KV3Zsg5l-zwZVkhP_4Hq5o5ZhtiO57w=.94a86c58-3910-4b52-8c2f-3d6aaf713a06@github.com>
References: <GnX35HIFItX1KV3Zsg5l-zwZVkhP_4Hq5o5ZhtiO57w=.94a86c58-3910-4b52-8c2f-3d6aaf713a06@github.com>
Message-ID: <dqrnvRS2FRMd9WlY0Y1lkE9OsBv5xlLTxZQOTKYnmxk=.c6f842c3-adb9-4a6f-a786-317b1398ecba@github.com>

On Wed, 22 Mar 2023 15:23:59 GMT, Justin King <jcking at openjdk.org> wrote:

> Switch to statically allocate storage for all of Hotspot's global mutexes and monitors. This avoids needing to allocate each one dynamically at startup. These also live for the lifetime of the program, so this reduces any potential memory fragmention in the C heap.

Makes sense, but I think you can do a large part of what you want with a fraction of the changes.

- we can probably switch from dyn. allocating the mutex name to keeping it inline as a static buffer. Cuts allocations down by half already. The name lengths are not that surprising, and even if we truncate (we shouldn't) it's probably fine.
- On posix, switch from pthread_cond_init to static initialization if possible.

Other than that, moving initialization to static now runs the initializers at dll load time, not at VM initialization time. Should be fine, but it's a semantic change to be aware of. I'm especially not keen on calling into the pthread lib at dll load time. But if you change it to static initialization it should be fine (PTHREAD_COND_INITIALIZER).

Like Coleen I don't like the invasiveness of this patch, esp. considering what it is doing. Pls try to simplify. You could probably keep the outside semantics, and do without templates. Eg define the mutexes in a compilation unit and export pointers to them to the outside?

e.g. 
x.cpp
static whatever-mutex-type Currentname_obj;
extern whatever-mutex-type* Currentname = &Currentname_obj;

and the hpp file accordingly.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13143#issuecomment-1479967039

From jcking at openjdk.org  Wed Mar 22 17:26:20 2023
From: jcking at openjdk.org (Justin King)
Date: Wed, 22 Mar 2023 17:26:20 GMT
Subject: RFR: JDK-8304723: Statically allocate global mutexes
In-Reply-To: <dqrnvRS2FRMd9WlY0Y1lkE9OsBv5xlLTxZQOTKYnmxk=.c6f842c3-adb9-4a6f-a786-317b1398ecba@github.com>
References: <GnX35HIFItX1KV3Zsg5l-zwZVkhP_4Hq5o5ZhtiO57w=.94a86c58-3910-4b52-8c2f-3d6aaf713a06@github.com>
 <dqrnvRS2FRMd9WlY0Y1lkE9OsBv5xlLTxZQOTKYnmxk=.c6f842c3-adb9-4a6f-a786-317b1398ecba@github.com>
Message-ID: <X1q39q7nRyvuAzV1IU3Th62VOhWQxL8idL70VizmgTc=.7e28da85-d158-4de8-b742-58ec18461945@github.com>

On Wed, 22 Mar 2023 17:17:57 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Other than that, moving initialization to static now runs the initializers at dll load time, not at VM initialization time. 

They do not run at DLL load time. They are initialized at VM init time. StaticLock has a trivially constructor, it is initialized later.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13143#issuecomment-1479974971

From jcking at openjdk.org  Wed Mar 22 17:31:24 2023
From: jcking at openjdk.org (Justin King)
Date: Wed, 22 Mar 2023 17:31:24 GMT
Subject: RFR: JDK-8304723: Statically allocate global mutexes
In-Reply-To: <dqrnvRS2FRMd9WlY0Y1lkE9OsBv5xlLTxZQOTKYnmxk=.c6f842c3-adb9-4a6f-a786-317b1398ecba@github.com>
References: <GnX35HIFItX1KV3Zsg5l-zwZVkhP_4Hq5o5ZhtiO57w=.94a86c58-3910-4b52-8c2f-3d6aaf713a06@github.com>
 <dqrnvRS2FRMd9WlY0Y1lkE9OsBv5xlLTxZQOTKYnmxk=.c6f842c3-adb9-4a6f-a786-317b1398ecba@github.com>
Message-ID: <5W2kMnwyT2Mh9YMBjMY0-Co77K1E6BFstcCWpXw95-g=.59a70f53-ae66-4f70-9f38-1c4beaab62e6@github.com>

On Wed, 22 Mar 2023 17:17:57 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Like Coleen I don't like the invasiveness of this patch, esp. considering what it is doing. Pls try to simplify. You could probably keep the outside semantics, and do without templates. Eg define the mutexes in a compilation unit and export pointers to them to the outside?

I did that initially, but it still has the unnecessary indirection potentially causing more cache misses. Additionally as I mentioned above, this has now caught two existing bugs where just raw pointers would not have caught them, since a nullptr is perfectly valid for `MutexLocker`. It doesn't catch the fact that the lock was never created. `StaticLock` asserts that the lock has been initialized when its accessed and can never return `nullptr`.  It also ensures it is never initialized twice, which `Heap_lock` was.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13143#issuecomment-1479980274

From jcking at openjdk.org  Wed Mar 22 17:34:03 2023
From: jcking at openjdk.org (Justin King)
Date: Wed, 22 Mar 2023 17:34:03 GMT
Subject: RFR: JDK-8304723: Statically allocate global mutexes
In-Reply-To: <dqrnvRS2FRMd9WlY0Y1lkE9OsBv5xlLTxZQOTKYnmxk=.c6f842c3-adb9-4a6f-a786-317b1398ecba@github.com>
References: <GnX35HIFItX1KV3Zsg5l-zwZVkhP_4Hq5o5ZhtiO57w=.94a86c58-3910-4b52-8c2f-3d6aaf713a06@github.com>
 <dqrnvRS2FRMd9WlY0Y1lkE9OsBv5xlLTxZQOTKYnmxk=.c6f842c3-adb9-4a6f-a786-317b1398ecba@github.com>
Message-ID: <ITGp6nOcrq2hcnPNgpOUHkMOwhDu9NMdEwPgwKm-EyI=.c14951e3-0333-408f-bbf8-8f058c2a0009@github.com>

On Wed, 22 Mar 2023 17:17:57 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> * we can probably switch from dyn. allocating the mutex name to keeping it inline as a static buffer. Cuts allocations down by half already. The name lengths are not that surprising, and even if we truncate (we shouldn't) it's probably fine.

This is even more invasive and should be done separately, I already noticed it. There are places where mutex/monitor are not statically allocated and we have to ensure those are also compatible with that change.

> * On posix, switch from pthread_cond_init to static initialization if possible.

The pthread_cond_init static initialization is not useful here, we are not initializing during library loading. Everything is still done during VM initialization. Trying to use pthread_cond_init static initialization would be more complex as we would then have to introduce a tag type to select which one, as one is not normally supposed to destroy statically initialized condition variables.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13143#issuecomment-1479986388

From jcking at openjdk.org  Wed Mar 22 17:37:56 2023
From: jcking at openjdk.org (Justin King)
Date: Wed, 22 Mar 2023 17:37:56 GMT
Subject: RFR: JDK-8304723: Statically allocate global mutexes [v2]
In-Reply-To: <qfME5gCVpGeIyyPDHR68gO5ZAb1xprwIV7smWrvmHXk=.f97b2e36-599b-49d6-b2a1-731d8b011188@github.com>
References: <GnX35HIFItX1KV3Zsg5l-zwZVkhP_4Hq5o5ZhtiO57w=.94a86c58-3910-4b52-8c2f-3d6aaf713a06@github.com>
 <qfME5gCVpGeIyyPDHR68gO5ZAb1xprwIV7smWrvmHXk=.f97b2e36-599b-49d6-b2a1-731d8b011188@github.com>
Message-ID: <34kj0Sk2tzDUvVYxlg4FpfUyG6p7EooRYhygGSaHylQ=.8dc979b0-db6a-4b8f-8038-5a4a3e965b8f@github.com>

On Wed, 22 Mar 2023 17:24:28 GMT, Justin King <jcking at openjdk.org> wrote:

>> Switch to statically allocate storage for all of Hotspot's global mutexes and monitors. This avoids needing to allocate each one dynamically at startup. These also live for the lifetime of the program, so this reduces any potential memory fragmention in the C heap.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix lock being initialized twice and lock never initialized
>   
>   Signed-off-by: Justin King <jcking at google.com>

Created [JDK-8304736](https://bugs.openjdk.org/browse/JDK-8304736) and [JDK-8304738](https://bugs.openjdk.org/browse/JDK-8304738).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13143#issuecomment-1479991910

From matsaave at openjdk.org  Wed Mar 22 17:42:35 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 22 Mar 2023 17:42:35 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v11]
In-Reply-To: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
Message-ID: <HhhXq9Z8u_XlrOHqmG2U6vfS_2BJtR_1z6fxQOIEsH0=.092626f2-f07f-45cf-9133-de7053853630@github.com>

> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
> 
> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
> 
> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
> 
> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
> 
> This change supports the following platforms: x86, aarch64, PPC, and RISCV

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  Improved comment for load-acquire aarch64

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12778/files
  - new: https://git.openjdk.org/jdk/pull/12778/files/cbe4fdcb..a4714f54

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12778&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12778&range=09-10

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12778.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12778/head:pull/12778

PR: https://git.openjdk.org/jdk/pull/12778

From kvn at openjdk.org  Wed Mar 22 17:50:19 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 22 Mar 2023 17:50:19 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <aR4w0EwXiNzm5zpAI0H0t9v6jQAmeA-BcwVChTYVlrM=.55178ce1-0277-4c52-a3b8-cda16aed712e@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
 <ztiqECTkWnt6s0n8q0KXw4MzN2MBVqdJ1Jy0kd6JuQE=.c0872ea4-e696-43a0-b356-d5149af1cbd1@github.com>
 <aR4w0EwXiNzm5zpAI0H0t9v6jQAmeA-BcwVChTYVlrM=.55178ce1-0277-4c52-a3b8-cda16aed712e@github.com>
Message-ID: <GQCKfFFrPEahfw9-TWmF4iyK85m87c_fUPQeAXHVWe0=.32d0251f-279a-4b69-8e68-4f93094c8e71@github.com>

On Wed, 22 Mar 2023 09:47:47 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 791:
>> 
>>> 789:       Compile::current()->output()->add_stub(stub);
>>> 790:       jcc(Assembler::notEqual, stub->entry());
>>> 791:       bind(stub->continuation());
>> 
>> Why use stub here and not inline the code? Because the branch mostly not taken?
>
> Yes, the branch is mostly not taken. If we inline the code, then we would have to take a forward branch on the very common path to skip over the (rare) part that handles ANON monitor owner. This would throw off static branch prediction and is discouraged by the Intel optimization guide.

okay

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1145202521

From kvn at openjdk.org  Wed Mar 22 18:08:52 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 22 Mar 2023 18:08:52 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <aR4w0EwXiNzm5zpAI0H0t9v6jQAmeA-BcwVChTYVlrM=.55178ce1-0277-4c52-a3b8-cda16aed712e@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
 <ztiqECTkWnt6s0n8q0KXw4MzN2MBVqdJ1Jy0kd6JuQE=.c0872ea4-e696-43a0-b356-d5149af1cbd1@github.com>
 <aR4w0EwXiNzm5zpAI0H0t9v6jQAmeA-BcwVChTYVlrM=.55178ce1-0277-4c52-a3b8-cda16aed712e@github.com>
Message-ID: <mQ8uS7e-UKjBHYsOYxiBblo_-mpLh-hPqmhDiPvATMM=.925bad9b-63e9-4571-818f-5f12ead9eb90@github.com>

On Wed, 22 Mar 2023 09:46:04 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 670:
>> 
>>> 668:   get_thread (scrReg);                    // beware: clobbers ICCs
>>> 669:   movptr(Address(boxReg, OM_OFFSET_NO_MONITOR_VALUE_TAG(owner)), scrReg);
>>> 670:   xorptr(boxReg, boxReg);                 // set icc.ZFlag = 1 to indicate success
>> 
>> Should this be under `if (UseFastLocking)`?
>
> I don't think so, unless we also want to change all the stuff in x86_32.ad to not fetch the thread before calling into fast_unlock(). However, I think it is a nice and useful change. I could break it out of this PR and get it reviewed separately, it is a side-effect of the new locking impl insofar as we always require a thread register, and allocate&fetch it before going into fast_lock().

I missed that it is under #ifndef LP64. Yes, it make since since you are now passing `thread` in register.
And why we need to `get_thread()` at line 708 if we already have it?

It is still hard to follow this 32-bit code. What each register is holding, what is value `3` and why we don't have checks similar to LP64 code after CAS?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1145223128

From jvernee at openjdk.org  Wed Mar 22 18:47:59 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 22 Mar 2023 18:47:59 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v5]
In-Reply-To: <MtnTWtmtdQkU0RqBSp7DuSnQz0OO8Bk3HzJi7NHZDoU=.bc0c0f9f-454a-484d-9613-95b00f5af7ca@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <MtnTWtmtdQkU0RqBSp7DuSnQz0OO8Bk3HzJi7NHZDoU=.bc0c0f9f-454a-484d-9613-95b00f5af7ca@github.com>
Message-ID: <gtAJNliiAynBqS9eqqm_KHudLRsvufMr_7FjxOliObI=.a95210da-075c-47a9-a38a-dadb793e3362@github.com>

On Tue, 21 Mar 2023 09:02:29 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> API changes for the FFM API (third preview)
>> 
>> Specdiff:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
>> 
>> Javadoc:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add example for Option::captureStateLayout

src/java.base/share/classes/java/lang/foreign/Arena.java line 59:

> 57:  * which features a <em>bounded lifetime</em> that is managed, automatically, by the garbage collector. As such, the regions
> 58:  * of memory backing memory segments allocated with the automatic arena are deallocated at some unspecified time
> 59:  * <em>after</em> the automatic allocator (and all the segments allocated by it) become

Suggestion:

 * <em>after</em> the automatic arena (and all the segments allocated by it) become

src/java.base/share/classes/java/lang/foreign/Arena.java line 89:

> 87:  * Memory segments allocated with a {@linkplain #ofConfined() confined arena} can only be accessed (and closed) by the
> 88:  * thread that created the arena. If access to a memory segment from multiple threads is required, clients can allocate
> 89:  * segment in a {@linkplain #ofShared() shared arena} instead.

Suggestion:

 * segments in a {@linkplain #ofShared() shared arena} instead.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1143734059
PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1143738342

From jvernee at openjdk.org  Wed Mar 22 18:48:07 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 22 Mar 2023 18:48:07 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
Message-ID: <oy4LL8ML2Y3MpKfF0hBwGOKLIaLDfPmpKEWf-v0Mizg=.c7f72545-ce7b-450d-a96a-f9021dc3b9e4@github.com>

On Wed, 22 Mar 2023 14:09:07 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> API changes for the FFM API (third preview)
>> 
>> Specdiff:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
>> 
>> Javadoc:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve javadocs for Linker::captureStateLayout

src/java.base/share/classes/java/lang/foreign/Linker.java line 492:

> 490:      * Finally, the returned method handle will throw an {@link IllegalArgumentException} if the {@link MemorySegment}
> 491:      * parameter passed to it is associated with the {@link MemorySegment#NULL} address, or a {@link NullPointerException}
> 492:      * if that parameter is {@code null}.

I think this isn't quite correct, as it only applies to the target address parameter. Also, we don't have to mention the NPE, as that's already mentioned in the package doc
Suggestion:

     * Finally, the returned method handle will throw an {@link IllegalArgumentException} if the {@link MemorySegment}
     * representing the target address of the foreign function is the {@link MemorySegment#NULL} address.

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 2315:

> 2313:          * @return {@code true}, if the provided object is also a scope, which models the same lifetime as that
> 2314:          * modelled by this scope.
> 2315:          */

A `@return` tag could be used here
Suggestion:

        /**
         * {@return {@code true}, if the provided object is also a scope, which models the same lifetime as that
         * modelled by this scope.} In that case, it is always the case that
         * {@code this.isAlive() == ((Scope)that).isAlive()}.
         * @param that the object to be tested.
         */

src/java.base/share/classes/jdk/internal/foreign/abi/fallback/FFIType.java line 116:

> 114:             }
> 115:             assert grpl instanceof UnionLayout;
> 116:             throw new IllegalArgumentException("Fallback linker does not support by-value unions: " + grpl);

For posterity, I suggest adding a comment here with the the bug number.
Suggestion:

            // JDK-8301800
            throw new IllegalArgumentException("Fallback linker does not support by-value unions: " + grpl);

src/java.base/share/native/libfallbackLinker/fallbackLinker.c line 82:

> 80:     value_ptr++;
> 81:   }
> 82: #endif

This looks incorrect. Look at the changes to `downcallLinker.cpp`, the `value_ptr++` should be moved outside of the if statements. (it only matters on Windows though, which we can't test at the moment for the fallback linker, but let's keep the 2 impls in sync for now)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1145188849
PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1145221286
PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1145245662
PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1145258121

From mcimadamore at openjdk.org  Wed Mar 22 19:05:49 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 22 Mar 2023 19:05:49 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: <oy4LL8ML2Y3MpKfF0hBwGOKLIaLDfPmpKEWf-v0Mizg=.c7f72545-ce7b-450d-a96a-f9021dc3b9e4@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
 <oy4LL8ML2Y3MpKfF0hBwGOKLIaLDfPmpKEWf-v0Mizg=.c7f72545-ce7b-450d-a96a-f9021dc3b9e4@github.com>
Message-ID: <69SHPBocr-b_789_vAvfpV67J_7ZrNal8SSnAFxugyw=.a971481e-9707-4022-88bd-b80906996cc7@github.com>

On Wed, 22 Mar 2023 17:34:36 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve javadocs for Linker::captureStateLayout
>
> src/java.base/share/classes/java/lang/foreign/Linker.java line 492:
> 
>> 490:      * Finally, the returned method handle will throw an {@link IllegalArgumentException} if the {@link MemorySegment}
>> 491:      * parameter passed to it is associated with the {@link MemorySegment#NULL} address, or a {@link NullPointerException}
>> 492:      * if that parameter is {@code null}.
> 
> I think this isn't quite correct, as it only applies to the target address parameter. Also, we don't have to mention the NPE, as that's already mentioned in the package doc
> Suggestion:
> 
>      * Finally, the returned method handle will throw an {@link IllegalArgumentException} if the {@link MemorySegment}
>      * representing the target address of the foreign function is the {@link MemorySegment#NULL} address.

Note: this text was just copied/adapted from toplevel javadoc and moved here. I think we have to say something about `null` as the text refers to `null` being passed as parameter to the returned MH, which is NOT covered by the package javadoc.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1145281749

From sspitsyn at openjdk.org  Wed Mar 22 19:06:34 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 22 Mar 2023 19:06:34 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v4]
In-Reply-To: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
Message-ID: <zoKIGUF4f5eii5i29H9y-uT-OhAGch6Q2Eez6ApqOpI=.91e05f5b-9bf4-45f1-955e-71a983982a4d@github.com>

> The fix is to enable support for late binding JVMTI agents.
> The fix includes:
> - New function `JvmtiEnvBase::enable_virtual_threads_notify_jvmti()` which does enabling JVMTI VTMS transition notifications in case of agent loaded into running VM. This function executes a VM operation counting VTMS transition bits in all `JavaThread`'s to correctly set the static counter `_VTMS_transition_count` needed for VTMS transition protocol.
> - New function `JvmtiEnvBase::disable_virtual_threads_notify_jvmti()` which is needed for testing. It is used by the `WhiteBox` API.
> - New WhiteBox function `WB_SetVirtualThreadsNotifyJvmtiMode(JNIEnv* env, jobject wb, jboolean enable)` needed for testing of this update.
> - New regression test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
> 
> Testing:
> - New test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
> - The originally failed tests are expected to pass 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:

  minor cleanup in enable_virtual_threads_notify_jvmti()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13133/files
  - new: https://git.openjdk.org/jdk/pull/13133/files/51c3f7d5..52ef33b6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13133&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13133&range=02-03

  Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13133.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13133/head:pull/13133

PR: https://git.openjdk.org/jdk/pull/13133

From mcimadamore at openjdk.org  Wed Mar 22 19:09:27 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 22 Mar 2023 19:09:27 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: <oy4LL8ML2Y3MpKfF0hBwGOKLIaLDfPmpKEWf-v0Mizg=.c7f72545-ce7b-450d-a96a-f9021dc3b9e4@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
 <oy4LL8ML2Y3MpKfF0hBwGOKLIaLDfPmpKEWf-v0Mizg=.c7f72545-ce7b-450d-a96a-f9021dc3b9e4@github.com>
Message-ID: <Tj3Ufw1gbQtPg_3o3SZ0AA_8cyAEMaAomuDJvKPZgaM=.1c629dec-fce5-485c-aa27-cad5b4c41d44@github.com>

On Wed, 22 Mar 2023 18:04:15 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve javadocs for Linker::captureStateLayout
>
> src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 2315:
> 
>> 2313:          * @return {@code true}, if the provided object is also a scope, which models the same lifetime as that
>> 2314:          * modelled by this scope.
>> 2315:          */
> 
> A `@return` tag could be used here
> Suggestion:
> 
>         /**
>          * {@return {@code true}, if the provided object is also a scope, which models the same lifetime as that
>          * modelled by this scope.} In that case, it is always the case that
>          * {@code this.isAlive() == ((Scope)that).isAlive()}.
>          * @param that the object to be tested.
>          */

Oh - I didn't know you could use return tag plus other text...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1145284853

From jvernee at openjdk.org  Wed Mar 22 19:27:47 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 22 Mar 2023 19:27:47 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: <69SHPBocr-b_789_vAvfpV67J_7ZrNal8SSnAFxugyw=.a971481e-9707-4022-88bd-b80906996cc7@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
 <oy4LL8ML2Y3MpKfF0hBwGOKLIaLDfPmpKEWf-v0Mizg=.c7f72545-ce7b-450d-a96a-f9021dc3b9e4@github.com>
 <69SHPBocr-b_789_vAvfpV67J_7ZrNal8SSnAFxugyw=.a971481e-9707-4022-88bd-b80906996cc7@github.com>
Message-ID: <vFO8K64fvvkg9jyeNelszMVal-uJTW-NYetwQ0oS3cM=.37effa35-d084-41bc-aee3-4ec2d8cf5b60@github.com>

On Wed, 22 Mar 2023 19:02:52 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/foreign/Linker.java line 492:
>> 
>>> 490:      * Finally, the returned method handle will throw an {@link IllegalArgumentException} if the {@link MemorySegment}
>>> 491:      * parameter passed to it is associated with the {@link MemorySegment#NULL} address, or a {@link NullPointerException}
>>> 492:      * if that parameter is {@code null}.
>> 
>> I think this isn't quite correct, as it only applies to the target address parameter. Also, we don't have to mention the NPE, as that's already mentioned in the package doc
>> Suggestion:
>> 
>>      * Finally, the returned method handle will throw an {@link IllegalArgumentException} if the {@link MemorySegment}
>>      * representing the target address of the foreign function is the {@link MemorySegment#NULL} address.
>
> Note: this text was just copied/adapted from toplevel javadoc and moved here. I think we have to say something about `null` as the text refers to `null` being passed as parameter to the returned MH, which is NOT covered by the package javadoc.

Ah. True. This is true about all the MS parameters as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1145303573

From mcimadamore at openjdk.org  Wed Mar 22 20:09:46 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 22 Mar 2023 20:09:46 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: <vFO8K64fvvkg9jyeNelszMVal-uJTW-NYetwQ0oS3cM=.37effa35-d084-41bc-aee3-4ec2d8cf5b60@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
 <oy4LL8ML2Y3MpKfF0hBwGOKLIaLDfPmpKEWf-v0Mizg=.c7f72545-ce7b-450d-a96a-f9021dc3b9e4@github.com>
 <69SHPBocr-b_789_vAvfpV67J_7ZrNal8SSnAFxugyw=.a971481e-9707-4022-88bd-b80906996cc7@github.com>
 <vFO8K64fvvkg9jyeNelszMVal-uJTW-NYetwQ0oS3cM=.37effa35-d084-41bc-aee3-4ec2d8cf5b60@github.com>
Message-ID: <yWgrZFrwKiPd5c9G1JUMJfv3xjtl8fYJ-GFr5sPsdwk=.d660f1f6-0d7c-42ce-8fca-9c3309c2a160@github.com>

On Wed, 22 Mar 2023 19:25:05 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Note: this text was just copied/adapted from toplevel javadoc and moved here. I think we have to say something about `null` as the text refers to `null` being passed as parameter to the returned MH, which is NOT covered by the package javadoc.
>
> Ah. True. This is true about all the MS parameters as well.

Yes - although there is a distinction between passed by value and by ref. I wouldn't be surprised if we just threw NPE for by-value.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1145352294

From cjplummer at openjdk.org  Wed Mar 22 21:14:46 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 22 Mar 2023 21:14:46 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v4]
In-Reply-To: <zoKIGUF4f5eii5i29H9y-uT-OhAGch6Q2Eez6ApqOpI=.91e05f5b-9bf4-45f1-955e-71a983982a4d@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <zoKIGUF4f5eii5i29H9y-uT-OhAGch6Q2Eez6ApqOpI=.91e05f5b-9bf4-45f1-955e-71a983982a4d@github.com>
Message-ID: <-sHjr_T15KCztTKCCOiaqfURgQzQ4v3FMSQXgSwpo8s=.e9a49ce0-cbf8-496c-99db-db7bd3f74445@github.com>

On Wed, 22 Mar 2023 19:06:34 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The fix is to enable support for late binding JVMTI agents.
>> The fix includes:
>> - New function `JvmtiEnvBase::enable_virtual_threads_notify_jvmti()` which does enabling JVMTI VTMS transition notifications in case of agent loaded into running VM. This function executes a VM operation counting VTMS transition bits in all `JavaThread`'s to correctly set the static counter `_VTMS_transition_count` needed for VTMS transition protocol.
>> - New function `JvmtiEnvBase::disable_virtual_threads_notify_jvmti()` which is needed for testing. It is used by the `WhiteBox` API.
>> - New WhiteBox function `WB_SetVirtualThreadsNotifyJvmtiMode(JNIEnv* env, jobject wb, jboolean enable)` needed for testing of this update.
>> - New regression test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
>> 
>> Testing:
>> - New test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
>> - The originally failed tests are expected to pass 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:
> 
>   minor cleanup in enable_virtual_threads_notify_jvmti()

> The fix is to enable support for late binding JVMTI agents.

Just to be clear, the last binding support was already there, but wasn't working properly with virtual threads. Correct?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13133#issuecomment-1480265452

From kvn at openjdk.org  Wed Mar 22 21:34:44 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 22 Mar 2023 21:34:44 GMT
Subject: RFR: 8304301: Remove the global option SuperWordMaxVectorSize
In-Reply-To: <2XQwCCx_ficJ1bn2WX0Ud9m-QmuGkkZAH8N6yLugXqQ=.90a136da-db9a-49b4-a4c4-d6c644cf7d5a@github.com>
References: <2XQwCCx_ficJ1bn2WX0Ud9m-QmuGkkZAH8N6yLugXqQ=.90a136da-db9a-49b4-a4c4-d6c644cf7d5a@github.com>
Message-ID: <XFBtY2varjMuciy0cd_WYAVVhWYSEUgOZnUzKJOgeow=.5f25a96d-e1ea-43e7-ab87-ce63be9cfefd@github.com>

On Tue, 21 Mar 2023 02:26:55 GMT, Fei Gao <fgao at openjdk.org> wrote:

> After the patch, auto-vectorization is still limited to 32-byte vectors by default on Cascade Lake and users can override this by either setting `-XX:UseAVX=3` or `-XX:MaxVectorSize=64` on JVM command line.

Correction: only `-XX:MaxVectorSize=64` will affect it. `-XX:UseAVX=3` does not affect superword vector size on CL because the condition for CL already includes `UseAVX > 2`.  And with `-XX:UseAVX=2` all vectors are limited to 32 bytes on all platforms.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13112#issuecomment-1480289084

From cjplummer at openjdk.org  Wed Mar 22 21:39:44 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 22 Mar 2023 21:39:44 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v4]
In-Reply-To: <zoKIGUF4f5eii5i29H9y-uT-OhAGch6Q2Eez6ApqOpI=.91e05f5b-9bf4-45f1-955e-71a983982a4d@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <zoKIGUF4f5eii5i29H9y-uT-OhAGch6Q2Eez6ApqOpI=.91e05f5b-9bf4-45f1-955e-71a983982a4d@github.com>
Message-ID: <GQ9oW7bDjmBDWI9GnQtQs_KsISi-Z9T7XDH4g_xbJwU=.c4f675f2-90d5-4c15-a5e0-f045290c9358@github.com>

On Wed, 22 Mar 2023 19:06:34 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The fix is to enable support for late binding JVMTI agents.
>> The fix includes:
>> - New function `JvmtiEnvBase::enable_virtual_threads_notify_jvmti()` which does enabling JVMTI VTMS transition notifications in case of agent loaded into running VM. This function executes a VM operation counting VTMS transition bits in all `JavaThread`'s to correctly set the static counter `_VTMS_transition_count` needed for VTMS transition protocol.
>> - New function `JvmtiEnvBase::disable_virtual_threads_notify_jvmti()` which is needed for testing. It is used by the `WhiteBox` API.
>> - New WhiteBox function `WB_SetVirtualThreadsNotifyJvmtiMode(JNIEnv* env, jobject wb, jboolean enable)` needed for testing of this update.
>> - New regression test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
>> 
>> Testing:
>> - New test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
>> - The originally failed tests are expected to pass 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:
> 
>   minor cleanup in enable_virtual_threads_notify_jvmti()

src/hotspot/share/prims/jvmtiExport.cpp line 389:

> 387:     } else {
> 388:       JvmtiVTMSTransitionDisabler::set_VTMS_notify_jvmti_events(true);
> 389:     }

One thing that is a little bit confusing about the changes here is that this is where the fix for [JDK-8296324](https://bugs.openjdk.org/browse/JDK-8296324) went, but for some reason the fix for [JDK-8304303](https://bugs.openjdk.org/browse/JDK-8304303), which was pushed a couple of days ago, removed the [JDK-8296324](https://bugs.openjdk.org/browse/JDK-8296324) changes even though these two bugs don't seem related. The code added by [JDK-8296324](https://bugs.openjdk.org/browse/JDK-8296324) was:

```   if (Continuations::enabled()) {
     // Virtual threads support. There is a performance impact when VTMS transitions are enabled.
     java_lang_VirtualThread::set_notify_jvmti_events(true);
+    if (JvmtiEnv::get_phase() == JVMTI_PHASE_LIVE) {
+      ThreadInVMfromNative __tiv(JavaThread::current());
+      java_lang_VirtualThread::init_static_notify_jvmti_events();
+    }
   }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1145434016

From sspitsyn at openjdk.org  Wed Mar 22 21:50:43 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 22 Mar 2023 21:50:43 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v4]
In-Reply-To: <-sHjr_T15KCztTKCCOiaqfURgQzQ4v3FMSQXgSwpo8s=.e9a49ce0-cbf8-496c-99db-db7bd3f74445@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <zoKIGUF4f5eii5i29H9y-uT-OhAGch6Q2Eez6ApqOpI=.91e05f5b-9bf4-45f1-955e-71a983982a4d@github.com>
 <-sHjr_T15KCztTKCCOiaqfURgQzQ4v3FMSQXgSwpo8s=.e9a49ce0-cbf8-496c-99db-db7bd3f74445@github.com>
Message-ID: <qW0K-SR_fTdVAlHp2WZ1yfIuYtFMyo14nN-Ob5Nif9Q=.792a5135-6010-4230-a445-f3a8af87aa66@github.com>

On Wed, 22 Mar 2023 21:11:45 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> > The fix is to enable support for late binding JVMTI agents.
> Just to be clear, the late binding support was already there, but wasn't working properly with virtual threads. Correct?
Nice catch. Right, it is virtual threads support. Fixed description now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13133#issuecomment-1480303929

From vlivanov at openjdk.org  Wed Mar 22 21:50:47 2023
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 22 Mar 2023 21:50:47 GMT
Subject: RFR: 8231349: Move intrinsic stubs generation to compiler runtime
 initialization code [v2]
In-Reply-To: <mps4Bze-krj-aWVdtS6CcpRmOf9_gs-lmDI3iH7AvIQ=.8671e010-995c-4d1c-8282-afbb5ae6f2bf@github.com>
References: <dtc9rdiBGUpqQUB9AzWBroeF3ziVODfk0FuPFDgOHqE=.096e99b2-2957-46c7-8c74-ae1d737f220d@github.com>
 <mps4Bze-krj-aWVdtS6CcpRmOf9_gs-lmDI3iH7AvIQ=.8671e010-995c-4d1c-8282-afbb5ae6f2bf@github.com>
Message-ID: <vB7no26f3a2dttFkoxMEo8ho1Hl6boLPPP2K5JeMca0=.0568f984-3c00-43f0-8ccd-1ce7717ff9a3@github.com>

On Mon, 20 Mar 2023 17:17:13 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Based on performance data (see graph in RFE) I propose to implement @cl4es suggestion to move intrinsics stubs generation to C2 (and JVMCI) runtime initialization code.
>> 
>> It has <1% difference from not generated these stubs at all and we will not win on 1 core VMs but it is simpler and safer solution, I think. It also automatically (no need for new code) do not generate these stubs if C2 is not used (-Xint or low TieredStopAt Level.
>> 
>> On demand stubs generation requires synchronization between threads during application run which may introduce some instability and may be other issues. But it could be beneficial for Interpreter and C1 if we want more intrinsics stubs to be used by C1 and Interpreter (they use CRC32 only now).  I filed separate RFE  [8304422](https://bugs.openjdk.org/browse/JDK-8304422).
>> 
>> Changes:
>>  - Added new platform specific diagnostic flag `-XX:+MoveIntrinsicStubsGen`. It is ON by default if VM is built with C2 or JVMCI compilers except Zero and 32-bit Arm VMs which have no or few intrinsics.
>>  - Split `StubGenerator::generate_all()` method into two: `generate_final_stubs()` and `generate_compiler_stubs()`. Moved only C2 (and JVMCI) intrinsic stubs generation to new method.
>>  - I renamed methods and stubs buffer sizes according to new code. Now we have 4 separate **named** stubs buffers and corresponding methods: _Initial, Continuation, Compiler, Final_.
>>  - I added new UL printing to find new sizes for buffers and adjusted them on `aarch64` and `x86`. On other platforms I used the same as before value for `compiler_stubs` and `final_stubs`:
>> 
>>> java -Xlog:stubs -XX:+UseCompressedOops -XX:+CheckCompressedOops -XX:+VerifyOops -XX:+VerifyStackAtCalls -version
>> [0.006s][info][stubs] StubRoutines (initial stubs)	 [0x00007f94900fcc00, 0x00007f9490101b60] used: 16152, free: 4168
>> [0.026s][info][stubs] StubRoutines (continuation stubs)	 [0x00007f9490102580, 0x00007f9490102e90] used: 741, free: 1579
>> [0.051s][info][stubs] StubRoutines (final stubs)	 [0x00007f9490155600, 0x00007f949015cc70] used: 26484, free: 3836
>> [0.090s][info][stubs] StubRoutines (compiler stubs)	 [0x00007f94904ccc00, 0x00007f94904d9bd0] used: 46988, free: 6212
>> java version "21-internal" 2023-09-19 LTS
>> 
>> -Xlog:stubs=debug will print size information for each stub:
>> [0.005s][debug][stubs] ICache::flush_icache_stub [0x00007fb2d3828080, 0x00007fb2d382809d] (29 bytes)
>> [0.005s][debug][stubs] VM_Version::get_cpu_info_stub [0x00007fb2d3828380, 0x00007fb2d3828714] (916 bytes)
>> [0.005s][debug][stubs] VM_Version::detect_virt_stub [0x00007fb2d3828714, 0x00007fb2d382872e] (26 bytes)
>> [0.005s][debug][stubs] StubRoutines::forward exception [0x00007fb2d3828c00, 0x00007fb2d3828c92] (146 bytes)
>> 
>> 
>> Testing: tier1-7, Xcomp, stress on x64 and aarch64.
>> 
>> I have changes for all platforms. Please test it on platforms you support.
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address Claes comments

Overall, looks good.

Just minor comments about code style.

src/hotspot/cpu/aarch64/globals_aarch64.hpp line 39:

> 37: define_pd_global(bool, UncommonNullCast,         true);  // Uncommon-trap NULLs past to check cast
> 38: 
> 39: #if COMPILER2_OR_JVMCI

I find it easier to read when only the default value is guarded. In that respect, `COMPILER2_OR_JVMCI` code diverges from the rest of the code base.

src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 4778:

> 4776: 
> 4777:  public:
> 4778:   StubGenerator(CodeBuffer* code, StubsKind kind) : StubCodeGenerator(code) {

The code is repeated on multiple platforms. It makes sense to lift it to `StubCodeGenerator`.

src/hotspot/share/runtime/globals.hpp line 369:

> 367:           "Enables intrinsification of Math.signum")                        \
> 368:                                                                             \
> 369:   product_pd(bool, MoveIntrinsicStubsGen, DIAGNOSTIC,                       \

The flag name looks confusing. What about `LazyCompilerStubGeneration` or even `LazyStubGeneration`?

-------------

Marked as reviewed by vlivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13096#pullrequestreview-1353508986
PR Review Comment: https://git.openjdk.org/jdk/pull/13096#discussion_r1145441707
PR Review Comment: https://git.openjdk.org/jdk/pull/13096#discussion_r1145436835
PR Review Comment: https://git.openjdk.org/jdk/pull/13096#discussion_r1145431118

From sspitsyn at openjdk.org  Wed Mar 22 21:58:43 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 22 Mar 2023 21:58:43 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v4]
In-Reply-To: <GQ9oW7bDjmBDWI9GnQtQs_KsISi-Z9T7XDH4g_xbJwU=.c4f675f2-90d5-4c15-a5e0-f045290c9358@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <zoKIGUF4f5eii5i29H9y-uT-OhAGch6Q2Eez6ApqOpI=.91e05f5b-9bf4-45f1-955e-71a983982a4d@github.com>
 <GQ9oW7bDjmBDWI9GnQtQs_KsISi-Z9T7XDH4g_xbJwU=.c4f675f2-90d5-4c15-a5e0-f045290c9358@github.com>
Message-ID: <GPwsQFuoV3LiJ1NxJ7H5nj9NcopMOdRQjvKaNd4byEI=.27fe27d1-8a5f-468b-8ddc-07fd720b9868@github.com>

On Wed, 22 Mar 2023 21:36:57 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor cleanup in enable_virtual_threads_notify_jvmti()
>
> src/hotspot/share/prims/jvmtiExport.cpp line 389:
> 
>> 387:     } else {
>> 388:       JvmtiVTMSTransitionDisabler::set_VTMS_notify_jvmti_events(true);
>> 389:     }
> 
> One thing that is a little bit confusing about the changes here is that this is where the fix for [JDK-8296324](https://bugs.openjdk.org/browse/JDK-8296324) went, but for some reason the fix for [JDK-8304303](https://bugs.openjdk.org/browse/JDK-8304303), which was pushed a couple of days ago, removed the [JDK-8296324](https://bugs.openjdk.org/browse/JDK-8296324) changes even though these two bugs don't seem related. The code added by [JDK-8296324](https://bugs.openjdk.org/browse/JDK-8296324) was:
> 
> ```   if (Continuations::enabled()) {
>      // Virtual threads support. There is a performance impact when VTMS transitions are enabled.
>      java_lang_VirtualThread::set_notify_jvmti_events(true);
> +    if (JvmtiEnv::get_phase() == JVMTI_PHASE_LIVE) {
> +      ThreadInVMfromNative __tiv(JavaThread::current());
> +      java_lang_VirtualThread::init_static_notify_jvmti_events();
> +    }
>    }

I agree, it is confusing.
This fragment was removed by JDK-8304303 because the function `java_lang_VirtualThread::init_static_notify_jvmti_events()` was being removed. It did not work correctly in the first place. It is why the JDK-8297286 was filed. Also, it was on my plan to fix JDK-8297286 soon.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1145449155

From kvn at openjdk.org  Wed Mar 22 22:00:42 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 22 Mar 2023 22:00:42 GMT
Subject: RFR: 8304301: Remove the global option SuperWordMaxVectorSize
In-Reply-To: <2XQwCCx_ficJ1bn2WX0Ud9m-QmuGkkZAH8N6yLugXqQ=.90a136da-db9a-49b4-a4c4-d6c644cf7d5a@github.com>
References: <2XQwCCx_ficJ1bn2WX0Ud9m-QmuGkkZAH8N6yLugXqQ=.90a136da-db9a-49b4-a4c4-d6c644cf7d5a@github.com>
Message-ID: <duXNWlMrAPmK3G4XdmtGaWtHM7zZO-ZIiJkaoEpGEVs=.809396d8-8b48-4c42-af59-8f0fab6a55f5@github.com>

On Tue, 21 Mar 2023 02:26:55 GMT, Fei Gao <fgao at openjdk.org> wrote:

> https://github.com/openjdk/jdk/pull/8877 introduced the global option `SuperWordMaxVectorSize` as a temporary solution to fix the performance regression on some x86 machines.
> 
> Currently, `SuperWordMaxVectorSize` behaves differently between x86 and other platforms [1]. For example, if the current machine only supports `MaxVectorSize <= 32`, but we set `SuperWordMaxVectorSize = 64`, then `SuperWordMaxVectorSize` will be kept at 64 on other platforms while x86 machine would change `SuperWordMaxVectorSize` to `MaxVectorSize`. Other platforms except x86 miss similar implementations like [2].
> 
> Also, `SuperWordMaxVectorSize` limits the max vector size of auto-vectorization as `64`, which is fine for current aarch64 hardware, but SVE architecture supports larger than 512 bits.
> 
> The patch is to drop the global option and use an architecture-dependent interface to consult the max vector size for auto-vectorization, fixing the performance issue on x86 and reducing side effects for other platforms. After the patch, auto-vectorization is still limited to 32-byte vectors by default on Cascade Lake and users can override this by either setting
> `-XX:UseAVX=3` or `-XX:MaxVectorSize=64` on JVM command line.
> 
> So my question is:
> 
> Before the patch, we could have a smaller max vector size for auto-vectorization than `MaxVectorSize` on x86. For example, users could have `MaxVectorSize=64` and `SuperWordMaxVectorSize=32`. But after the change, if we set
> `-XX:MaxVectorSize=64` explicitly, then the max vector size for auto-vectorization would be `MaxVectorSize`, i.e. 64 bytes, which I believe is more reasonable. @sviswa7 @jatin-bhateja, are you happy about the change?
> 
> [1] https://github.com/openjdk/jdk/pull/12350#discussion_r1126106213
> [2] https://github.com/openjdk/jdk/blob/33bec207103acd520eb99afb093cfafa44aecfda/src/hotspot/cpu/x86/vm_version_x86.cpp#L1314-L1333

I am not sure about this effect of UseAVX setting on command line.
We use UseAVX setting on command line to emulate runs on different platforms. Some our machines are Cascade Lake. Before, even if we use `-XX:UseAVX=3` on command line we still limit superword vector size for CL. With this patch we will not do that. It will not match what happens in production with default setting and we miss testing coverage for CL.

Why you added `FLAG_IS_DEFAULT(UseAVX)` check?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13112#issuecomment-1480312729

From kvn at openjdk.org  Wed Mar 22 22:07:47 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 22 Mar 2023 22:07:47 GMT
Subject: RFR: 8231349: Move intrinsic stubs generation to compiler runtime
 initialization code [v2]
In-Reply-To: <vB7no26f3a2dttFkoxMEo8ho1Hl6boLPPP2K5JeMca0=.0568f984-3c00-43f0-8ccd-1ce7717ff9a3@github.com>
References: <dtc9rdiBGUpqQUB9AzWBroeF3ziVODfk0FuPFDgOHqE=.096e99b2-2957-46c7-8c74-ae1d737f220d@github.com>
 <mps4Bze-krj-aWVdtS6CcpRmOf9_gs-lmDI3iH7AvIQ=.8671e010-995c-4d1c-8282-afbb5ae6f2bf@github.com>
 <vB7no26f3a2dttFkoxMEo8ho1Hl6boLPPP2K5JeMca0=.0568f984-3c00-43f0-8ccd-1ce7717ff9a3@github.com>
Message-ID: <ZKhiaU2HfhZOcUNVyGCHAZs--haEqLIl2tAUgIX9lVQ=.75c2e7df-b0ac-4784-8261-9b3f71df2a66@github.com>

On Wed, 22 Mar 2023 21:32:59 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address Claes comments
>
> src/hotspot/share/runtime/globals.hpp line 369:
> 
>> 367:           "Enables intrinsification of Math.signum")                        \
>> 368:                                                                             \
>> 369:   product_pd(bool, MoveIntrinsicStubsGen, DIAGNOSTIC,                       \
> 
> The flag name looks confusing. What about `LazyCompilerStubGeneration` or even `LazyStubGeneration`?

I know, I am struggling with this name too. But I can't find better one.
`LazyStubGeneration` is reserved for an other RFE: [JDK-8304422](https://bugs.openjdk.org/browse/JDK-8304422).
And it is not lazy. Compiler stubs generation is **delayed** until Compiler runtime initialization but they all still generated during initialization phase.
How about `DelayCompilerStubsGeneration` ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13096#discussion_r1145455466

From kvn at openjdk.org  Wed Mar 22 22:21:41 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 22 Mar 2023 22:21:41 GMT
Subject: RFR: 8231349: Move intrinsic stubs generation to compiler runtime
 initialization code [v2]
In-Reply-To: <vB7no26f3a2dttFkoxMEo8ho1Hl6boLPPP2K5JeMca0=.0568f984-3c00-43f0-8ccd-1ce7717ff9a3@github.com>
References: <dtc9rdiBGUpqQUB9AzWBroeF3ziVODfk0FuPFDgOHqE=.096e99b2-2957-46c7-8c74-ae1d737f220d@github.com>
 <mps4Bze-krj-aWVdtS6CcpRmOf9_gs-lmDI3iH7AvIQ=.8671e010-995c-4d1c-8282-afbb5ae6f2bf@github.com>
 <vB7no26f3a2dttFkoxMEo8ho1Hl6boLPPP2K5JeMca0=.0568f984-3c00-43f0-8ccd-1ce7717ff9a3@github.com>
Message-ID: <D04AqC0u5A45zHPTfYR50Jr3Mv_5Ar3QERLmCMQmi10=.803c5999-8855-4725-9550-8f875a3d9df6@github.com>

On Wed, 22 Mar 2023 21:40:25 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address Claes comments
>
> src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 4778:
> 
>> 4776: 
>> 4777:  public:
>> 4778:   StubGenerator(CodeBuffer* code, StubsKind kind) : StubCodeGenerator(code) {
> 
> The code is repeated on multiple platforms. It makes sense to lift it to `StubCodeGenerator`.

It is because `StubGenerator` is declared and defined separately on each platform. Doing that here will add more complexity for already not small changes.  Filed new RFE: [JDK-8304750](https://bugs.openjdk.org/browse/JDK-8304750)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13096#discussion_r1145465531

From dholmes at openjdk.org  Wed Mar 22 22:35:42 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 22 Mar 2023 22:35:42 GMT
Subject: RFR: JDK-8304723: Statically allocate global mutexes
In-Reply-To: <ITGp6nOcrq2hcnPNgpOUHkMOwhDu9NMdEwPgwKm-EyI=.c14951e3-0333-408f-bbf8-8f058c2a0009@github.com>
References: <GnX35HIFItX1KV3Zsg5l-zwZVkhP_4Hq5o5ZhtiO57w=.94a86c58-3910-4b52-8c2f-3d6aaf713a06@github.com>
 <dqrnvRS2FRMd9WlY0Y1lkE9OsBv5xlLTxZQOTKYnmxk=.c6f842c3-adb9-4a6f-a786-317b1398ecba@github.com>
 <ITGp6nOcrq2hcnPNgpOUHkMOwhDu9NMdEwPgwKm-EyI=.c14951e3-0333-408f-bbf8-8f058c2a0009@github.com>
Message-ID: <skYwSC4jAzrCin2w81NxHTghEskLccvCiuOBytcaNjc=.06749e56-835c-4899-9dad-b652474ef318@github.com>

On Wed, 22 Mar 2023 17:31:19 GMT, Justin King <jcking at openjdk.org> wrote:

> On posix, switch from pthread_cond_init to static initialization if possible.

Some platforms have the "wrong" default which is why we don't attempt to use the pthread static initializers. But in general statically initializing our Mutex/Monitor would be very fragile IMO - as discussed in the past.

Doing the allocation statically is a different matter. But what does this gain? Is the startup improvement noticeable?

> Created [JDK-8304736](https://bugs.openjdk.org/browse/JDK-8304736) and [JDK-8304738](https://bugs.openjdk.org/browse/JDK-8304738).

Thanks for that.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13143#issuecomment-1480342887

From kvn at openjdk.org  Wed Mar 22 22:37:41 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 22 Mar 2023 22:37:41 GMT
Subject: RFR: 8231349: Move intrinsic stubs generation to compiler runtime
 initialization code [v2]
In-Reply-To: <vB7no26f3a2dttFkoxMEo8ho1Hl6boLPPP2K5JeMca0=.0568f984-3c00-43f0-8ccd-1ce7717ff9a3@github.com>
References: <dtc9rdiBGUpqQUB9AzWBroeF3ziVODfk0FuPFDgOHqE=.096e99b2-2957-46c7-8c74-ae1d737f220d@github.com>
 <mps4Bze-krj-aWVdtS6CcpRmOf9_gs-lmDI3iH7AvIQ=.8671e010-995c-4d1c-8282-afbb5ae6f2bf@github.com>
 <vB7no26f3a2dttFkoxMEo8ho1Hl6boLPPP2K5JeMca0=.0568f984-3c00-43f0-8ccd-1ce7717ff9a3@github.com>
Message-ID: <BdXwJX75cCrFzKmUrr4tcF_eewBA6TmwRXNx0iZ8VAI=.d49e8d18-ee90-480a-87be-2aa3a6d63c34@github.com>

On Wed, 22 Mar 2023 21:47:01 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address Claes comments
>
> src/hotspot/cpu/aarch64/globals_aarch64.hpp line 39:
> 
>> 37: define_pd_global(bool, UncommonNullCast,         true);  // Uncommon-trap NULLs past to check cast
>> 38: 
>> 39: #if COMPILER2_OR_JVMCI
> 
> I find it easier to read when only the default value is guarded. In that respect, `COMPILER2_OR_JVMCI` code diverges from the rest of the code base.

So you want something similar to `COMPILER1_AND_COMPILER2_PRESENT()` used for `CodeCacheSegmentSize` in following line?
Yes, we have similar macro for JVMCI and C2. How about this:

define_pd_global(bool, MoveIntrinsicStubsGen,   false COMPILER2_OR_JVMCI_PRESENT( || true));

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13096#discussion_r1145475473

From kbarrett at openjdk.org  Wed Mar 22 22:58:30 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 22 Mar 2023 22:58:30 GMT
Subject: RFR: 8298725: Add BitMap support for reverse iteration
Message-ID: <5usc17TaIE2tQRj8IE58fBtVpXCNSxIp-nPQBzJlrmg=.a0620419-86c9-4a56-9ac7-9d317f07ea5e@github.com>

Please review this addition of BitMap::reverse_iterate, which is like
BitMap::iterate but visits the set bits in a range from high index to low.

Testing:
mach5 tier1, which includes running the updated gtests on all Oracle-supported
platform

-------------

Commit messages:
 - add reverse_iterate

Changes: https://git.openjdk.org/jdk/pull/13151/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13151&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298725
  Stats: 140 lines in 3 files changed: 116 ins; 13 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/13151.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13151/head:pull/13151

PR: https://git.openjdk.org/jdk/pull/13151

From redestad at openjdk.org  Wed Mar 22 22:53:42 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 22 Mar 2023 22:53:42 GMT
Subject: RFR: 8231349: Move intrinsic stubs generation to compiler runtime
 initialization code [v2]
In-Reply-To: <ZKhiaU2HfhZOcUNVyGCHAZs--haEqLIl2tAUgIX9lVQ=.75c2e7df-b0ac-4784-8261-9b3f71df2a66@github.com>
References: <dtc9rdiBGUpqQUB9AzWBroeF3ziVODfk0FuPFDgOHqE=.096e99b2-2957-46c7-8c74-ae1d737f220d@github.com>
 <mps4Bze-krj-aWVdtS6CcpRmOf9_gs-lmDI3iH7AvIQ=.8671e010-995c-4d1c-8282-afbb5ae6f2bf@github.com>
 <vB7no26f3a2dttFkoxMEo8ho1Hl6boLPPP2K5JeMca0=.0568f984-3c00-43f0-8ccd-1ce7717ff9a3@github.com>
 <ZKhiaU2HfhZOcUNVyGCHAZs--haEqLIl2tAUgIX9lVQ=.75c2e7df-b0ac-4784-8261-9b3f71df2a66@github.com>
Message-ID: <1wFRQwc4HH0GQUk-nxtfFhDKWcmwtcxhrDa1LlyHq08=.3fd5d967-153e-48d8-bed9-c2d5bd79daae@github.com>

On Wed, 22 Mar 2023 22:04:32 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> src/hotspot/share/runtime/globals.hpp line 369:
>> 
>>> 367:           "Enables intrinsification of Math.signum")                        \
>>> 368:                                                                             \
>>> 369:   product_pd(bool, MoveIntrinsicStubsGen, DIAGNOSTIC,                       \
>> 
>> The flag name looks confusing. What about `LazyCompilerStubGeneration` or even `LazyStubGeneration`?
>
> I know, I am struggling with this name too. But I can't find better one.
> `LazyStubGeneration` is reserved for an other RFE: [JDK-8304422](https://bugs.openjdk.org/browse/JDK-8304422).
> And it is not lazy. Compiler stubs generation is **delayed** until Compiler runtime initialization but they all still generated during initialization phase.
> How about `DelayCompilerStubsGeneration` ?

I think `DelayCompilerStubsGeneration` sounds OK

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13096#discussion_r1145484700

From vlivanov at openjdk.org  Wed Mar 22 23:01:40 2023
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 22 Mar 2023 23:01:40 GMT
Subject: RFR: 8231349: Move intrinsic stubs generation to compiler runtime
 initialization code [v2]
In-Reply-To: <1wFRQwc4HH0GQUk-nxtfFhDKWcmwtcxhrDa1LlyHq08=.3fd5d967-153e-48d8-bed9-c2d5bd79daae@github.com>
References: <dtc9rdiBGUpqQUB9AzWBroeF3ziVODfk0FuPFDgOHqE=.096e99b2-2957-46c7-8c74-ae1d737f220d@github.com>
 <mps4Bze-krj-aWVdtS6CcpRmOf9_gs-lmDI3iH7AvIQ=.8671e010-995c-4d1c-8282-afbb5ae6f2bf@github.com>
 <vB7no26f3a2dttFkoxMEo8ho1Hl6boLPPP2K5JeMca0=.0568f984-3c00-43f0-8ccd-1ce7717ff9a3@github.com>
 <ZKhiaU2HfhZOcUNVyGCHAZs--haEqLIl2tAUgIX9lVQ=.75c2e7df-b0ac-4784-8261-9b3f71df2a66@github.com>
 <1wFRQwc4HH0GQUk-nxtfFhDKWcmwtcxhrDa1LlyHq08=.3fd5d967-153e-48d8-bed9-c2d5bd79daae@github.com>
Message-ID: <xHQlz_ZA8-ibK2CaXTgXQJ8Z-D7kTorJRiSg0ehhM3c=.24790995-4344-48d4-8fdf-4dffa8995289@github.com>

On Wed, 22 Mar 2023 22:50:34 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> I know, I am struggling with this name too. But I can't find better one.
>> `LazyStubGeneration` is reserved for an other RFE: [JDK-8304422](https://bugs.openjdk.org/browse/JDK-8304422).
>> And it is not lazy. Compiler stubs generation is **delayed** until Compiler runtime initialization but they all still generated during initialization phase.
>> How about `DelayCompilerStubsGeneration` ?
>
> I think `DelayCompilerStubsGeneration` sounds OK

`DelayCompilerStubsGeneration` sounds good.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13096#discussion_r1145489390

From vlivanov at openjdk.org  Wed Mar 22 23:07:42 2023
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 22 Mar 2023 23:07:42 GMT
Subject: RFR: 8231349: Move intrinsic stubs generation to compiler runtime
 initialization code [v2]
In-Reply-To: <BdXwJX75cCrFzKmUrr4tcF_eewBA6TmwRXNx0iZ8VAI=.d49e8d18-ee90-480a-87be-2aa3a6d63c34@github.com>
References: <dtc9rdiBGUpqQUB9AzWBroeF3ziVODfk0FuPFDgOHqE=.096e99b2-2957-46c7-8c74-ae1d737f220d@github.com>
 <mps4Bze-krj-aWVdtS6CcpRmOf9_gs-lmDI3iH7AvIQ=.8671e010-995c-4d1c-8282-afbb5ae6f2bf@github.com>
 <vB7no26f3a2dttFkoxMEo8ho1Hl6boLPPP2K5JeMca0=.0568f984-3c00-43f0-8ccd-1ce7717ff9a3@github.com>
 <BdXwJX75cCrFzKmUrr4tcF_eewBA6TmwRXNx0iZ8VAI=.d49e8d18-ee90-480a-87be-2aa3a6d63c34@github.com>
Message-ID: <pd3GNz9zQ1xextDdHbnQUzqylgbehDikwI0icnLXvpo=.ac48f66f-951f-48e6-b36d-e9b04f1ca21d@github.com>

On Wed, 22 Mar 2023 22:35:00 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/globals_aarch64.hpp line 39:
>> 
>>> 37: define_pd_global(bool, UncommonNullCast,         true);  // Uncommon-trap NULLs past to check cast
>>> 38: 
>>> 39: #if COMPILER2_OR_JVMCI
>> 
>> I find it easier to read when only the default value is guarded. In that respect, `COMPILER2_OR_JVMCI` code diverges from the rest of the code base.
>
> So you want something similar to `COMPILER1_AND_COMPILER2_PRESENT()` used for `CodeCacheSegmentSize` in following line?
> Yes, we have similar macro for JVMCI and C2. How about this:
> 
> define_pd_global(bool, MoveIntrinsicStubsGen,   false COMPILER2_OR_JVMCI_PRESENT( || true));

What about the following?

define_pd_global(bool, MoveIntrinsicStubsGen,  NOT_COMPILER2_OR_JVMCI(false) COMPILER2_OR_JVMCI_PRESENT(true));

Are you concerned it is too long?

Or even `NOT_COMPILER2_OR_JVMCI` maybe?

define_pd_global(bool, MoveIntrinsicStubsGen, COMPILER2_OR_JVMCI);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13096#discussion_r1145494445

From kvn at openjdk.org  Thu Mar 23 00:37:47 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 23 Mar 2023 00:37:47 GMT
Subject: RFR: 8231349: Move intrinsic stubs generation to compiler runtime
 initialization code [v2]
In-Reply-To: <pd3GNz9zQ1xextDdHbnQUzqylgbehDikwI0icnLXvpo=.ac48f66f-951f-48e6-b36d-e9b04f1ca21d@github.com>
References: <dtc9rdiBGUpqQUB9AzWBroeF3ziVODfk0FuPFDgOHqE=.096e99b2-2957-46c7-8c74-ae1d737f220d@github.com>
 <mps4Bze-krj-aWVdtS6CcpRmOf9_gs-lmDI3iH7AvIQ=.8671e010-995c-4d1c-8282-afbb5ae6f2bf@github.com>
 <vB7no26f3a2dttFkoxMEo8ho1Hl6boLPPP2K5JeMca0=.0568f984-3c00-43f0-8ccd-1ce7717ff9a3@github.com>
 <BdXwJX75cCrFzKmUrr4tcF_eewBA6TmwRXNx0iZ8VAI=.d49e8d18-ee90-480a-87be-2aa3a6d63c34@github.com>
 <pd3GNz9zQ1xextDdHbnQUzqylgbehDikwI0icnLXvpo=.ac48f66f-951f-48e6-b36d-e9b04f1ca21d@github.com>
Message-ID: <p3y0x3vaAAxfgdBqnqiHv4V40hrRnOUgXmllsUwxSkA=.83d46229-dd75-4a09-bec1-04930a2721d0@github.com>

On Wed, 22 Mar 2023 23:05:04 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> So you want something similar to `COMPILER1_AND_COMPILER2_PRESENT()` used for `CodeCacheSegmentSize` in following line?
>> Yes, we have similar macro for JVMCI and C2. How about this:
>> 
>> define_pd_global(bool, MoveIntrinsicStubsGen,   false COMPILER2_OR_JVMCI_PRESENT( || true));
>
> What about the following?
> 
> define_pd_global(bool, MoveIntrinsicStubsGen,  NOT_COMPILER2_OR_JVMCI(false) COMPILER2_OR_JVMCI_PRESENT(true));
> 
> Are you concerned it is too long?
> 
> Or even `COMPILER2_OR_JVMCI` maybe?
> 
> define_pd_global(bool, MoveIntrinsicStubsGen, COMPILER2_OR_JVMCI);

Yes, I don't want long line. I will try the last suggestion. I was able to build locally with it on linux.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13096#discussion_r1145551383

From kvn at openjdk.org  Thu Mar 23 00:37:48 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 23 Mar 2023 00:37:48 GMT
Subject: RFR: 8231349: Move intrinsic stubs generation to compiler runtime
 initialization code [v2]
In-Reply-To: <xHQlz_ZA8-ibK2CaXTgXQJ8Z-D7kTorJRiSg0ehhM3c=.24790995-4344-48d4-8fdf-4dffa8995289@github.com>
References: <dtc9rdiBGUpqQUB9AzWBroeF3ziVODfk0FuPFDgOHqE=.096e99b2-2957-46c7-8c74-ae1d737f220d@github.com>
 <mps4Bze-krj-aWVdtS6CcpRmOf9_gs-lmDI3iH7AvIQ=.8671e010-995c-4d1c-8282-afbb5ae6f2bf@github.com>
 <vB7no26f3a2dttFkoxMEo8ho1Hl6boLPPP2K5JeMca0=.0568f984-3c00-43f0-8ccd-1ce7717ff9a3@github.com>
 <ZKhiaU2HfhZOcUNVyGCHAZs--haEqLIl2tAUgIX9lVQ=.75c2e7df-b0ac-4784-8261-9b3f71df2a66@github.com>
 <1wFRQwc4HH0GQUk-nxtfFhDKWcmwtcxhrDa1LlyHq08=.3fd5d967-153e-48d8-bed9-c2d5bd79daae@github.com>
 <xHQlz_ZA8-ibK2CaXTgXQJ8Z-D7kTorJRiSg0ehhM3c=.24790995-4344-48d4-8fdf-4dffa8995289@github.com>
Message-ID: <r21fFJ-CJuviWS7LSj4MWxDbJfLIUryK33kJIkpcIFA=.ef95607a-7211-42e6-bf27-180b3d9093a0@github.com>

On Wed, 22 Mar 2023 22:58:50 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> I think `DelayCompilerStubsGeneration` sounds OK
>
> `DelayCompilerStubsGeneration` sounds good.

Okay.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13096#discussion_r1145551508

From xgong at openjdk.org  Thu Mar 23 01:45:20 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 23 Mar 2023 01:45:20 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v4]
In-Reply-To: <U-1I398elh4CJBPi5J2fEF14qp9ZgoYFhXxMD70L1wI=.2cecacd5-4fb6-4194-a5e4-c1801e0b7691@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
 <4Op0Z8whnyDXDC6zGyMbx4ugcZp5TEoAqW_myB5flxM=.1c7b59ba-efb2-4f68-90d7-2d6e33e39572@github.com>
 <yPyZ7su4OnRDd5LyQPvU0Hk6n5AI5CO2lR12qO9efCg=.51a05574-aee6-416b-863c-76d38a6766c3@github.com>
 <U-1I398elh4CJBPi5J2fEF14qp9ZgoYFhXxMD70L1wI=.2cecacd5-4fb6-4194-a5e4-c1801e0b7691@github.com>
Message-ID: <n0TjxYsIrsdio49Zo2wFeiVmd7XNHnRTpx1Qiwh2NgY=.96da71e5-5c57-460e-91e9-58f710ed2899@github.com>

On Wed, 22 Mar 2023 12:39:27 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> src/hotspot/share/opto/vectorIntrinsics.cpp line 2426:
>> 
>>> 2424:   if (is_vector_shuffle(vbox_klass_from)) {
>>> 2425:     return false; // vector shuffles aren't supported
>>> 2426:   }
>> 
>> Is it better to change this as an "assertion" or print the log details?
>
> The change indifferentiates a vector shuffle from a normal vector in C2, so this should be removed, as vector shuffles are converted to/from normal vector using this routine

Oh, I'm sorry that I didn't notice it is a removing change. And, yes, you're right. So please ignore my previous comment. Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1145580975

From dholmes at openjdk.org  Thu Mar 23 01:59:31 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 23 Mar 2023 01:59:31 GMT
Subject: RFR: 8304687: Move add_to_hierarchy [v4]
In-Reply-To: <3T0hPcnNGHYDFq8bQUFyppY2hGNbeRBoKMJ2EDaqh-c=.6205cb5e-97e8-4d7e-a619-82646abb19f6@github.com>
References: <8lZkIOj_sW-s5fenIUyqOflXokTscrf8v6Zi6VOic4o=.847bbf8a-430b-46f5-a4c2-335d3355c320@github.com>
 <3T0hPcnNGHYDFq8bQUFyppY2hGNbeRBoKMJ2EDaqh-c=.6205cb5e-97e8-4d7e-a619-82646abb19f6@github.com>
Message-ID: <THBWeY8Hsem8hQzrqgjV2rMIHmcz2tn7mi8u_zLtS_w=.5d5e5a0c-d04f-4632-9331-bce8d35d191d@github.com>

On Wed, 22 Mar 2023 15:31:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Moved SystemDictionary::add_to_hierarchy to InstanceKlass::add_to_hierarchy where it more logically belongs and next to other functions that also care about dependencies.
>> Tested with tier1-4, and tier1 on linux,windows,macos to check header file changes.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert another include file deletion

Still good.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13129#pullrequestreview-1353719868

From fgao at openjdk.org  Thu Mar 23 02:03:32 2023
From: fgao at openjdk.org (Fei Gao)
Date: Thu, 23 Mar 2023 02:03:32 GMT
Subject: RFR: 8304301: Remove the global option SuperWordMaxVectorSize
In-Reply-To: <duXNWlMrAPmK3G4XdmtGaWtHM7zZO-ZIiJkaoEpGEVs=.809396d8-8b48-4c42-af59-8f0fab6a55f5@github.com>
References: <2XQwCCx_ficJ1bn2WX0Ud9m-QmuGkkZAH8N6yLugXqQ=.90a136da-db9a-49b4-a4c4-d6c644cf7d5a@github.com>
 <duXNWlMrAPmK3G4XdmtGaWtHM7zZO-ZIiJkaoEpGEVs=.809396d8-8b48-4c42-af59-8f0fab6a55f5@github.com>
Message-ID: <UpWUCosBwcbNV7RFzR6XUWRDUYEms5GQ-mPIO3fLJuU=.dcdc631b-10d2-45b6-bf0d-6d5985815afc@github.com>

On Wed, 22 Mar 2023 21:58:09 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> I am not sure about this effect of UseAVX setting on command line. We use UseAVX setting on command line to emulate runs on different platforms. Some our machines are Cascade Lake. Before, even if we use `-XX:UseAVX=3` on command line we still limit superword vector size for CL. With this patch we will not do that. It will not match what happens in production with default setting and we miss testing coverage for CL.
> 
> Why you added `FLAG_IS_DEFAULT(UseAVX)` check?

Hi @vnkozlov, thanks for your review!

I added the `FLAG_IS_DEFAULT(UseAVX)` check to follow its original logic, see https://github.com/openjdk/jdk/blob/91f407d6fe285c44bcc25c1acdf5dc0c43be0172/src/hotspot/cpu/x86/vm_version_x86.cpp#L1317. Before the patch, using `UseAVX=3` alone would change superword vector size for CL to be `MaxVectorSize`, but we could still explicitly use `-XX:SuperWordMaxVectorSize=32` to limit superword vector size for CL.

Certainly, removing `FLAG_IS_DEFAULT(UseAVX)` check here is also reasonable to me. Then only `-XX:MaxVectorSize=64` will affect it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13112#issuecomment-1480477134

From cjplummer at openjdk.org  Thu Mar 23 02:05:06 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 23 Mar 2023 02:05:06 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v4]
In-Reply-To: <zoKIGUF4f5eii5i29H9y-uT-OhAGch6Q2Eez6ApqOpI=.91e05f5b-9bf4-45f1-955e-71a983982a4d@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <zoKIGUF4f5eii5i29H9y-uT-OhAGch6Q2Eez6ApqOpI=.91e05f5b-9bf4-45f1-955e-71a983982a4d@github.com>
Message-ID: <MvpNRiR8xVqGPSzxyo_Qq_Nk07LS60KVyKUpjVOt3Ug=.241061a2-6bb7-4919-b799-0912d658ed4c@github.com>

On Wed, 22 Mar 2023 19:06:34 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The fix is to enable virtual threads support for late binding JVMTI agents.
>> The fix includes:
>> - New function `JvmtiEnvBase::enable_virtual_threads_notify_jvmti()` which does enabling JVMTI VTMS transition notifications in case of agent loaded into running VM. This function executes a VM operation counting VTMS transition bits in all `JavaThread`'s to correctly set the static counter `_VTMS_transition_count` needed for VTMS transition protocol.
>> - New function `JvmtiEnvBase::disable_virtual_threads_notify_jvmti()` which is needed for testing. It is used by the `WhiteBox` API.
>> - New WhiteBox function `WB_SetVirtualThreadsNotifyJvmtiMode(JNIEnv* env, jobject wb, jboolean enable)` needed for testing of this update.
>> - New regression test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
>> 
>> Testing:
>> - New test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
>> - The originally failed tests are expected to pass 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:
> 
>   minor cleanup in enable_virtual_threads_notify_jvmti()

src/hotspot/share/prims/jvmtiEnvBase.hpp line 87:

> 85: 
> 86:   static bool enable_virtual_threads_notify_jvmti();
> 87:   static bool disable_virtual_threads_notify_jvmti();

"disable" only seems to be used by the WB API. Is that expected?

src/hotspot/share/prims/jvmtiThreadState.hpp line 102:

> 100: 
> 101:   static int  VTMS_transition_count()                { return _VTMS_transition_count; }
> 102:   static void set_VTMS_transition_count(bool val)    { _VTMS_transition_count = val; }

Although there is a call to `set_VTMS_transition_count()`, I don't see any calls to `VTMS_transition_count()`. Are these really needed?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1145589024
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1145589515

From dholmes at openjdk.org  Thu Mar 23 02:20:40 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 23 Mar 2023 02:20:40 GMT
Subject: RFR: 8304725: AsyncGetCallTrace can cause SIGBUS on M1
In-Reply-To: <XtBvYsLSljF-NTYtEuYvx35NrdX3-VSu_MmirMCLfKc=.3b4e81e3-d53e-445e-85e4-0fb5e6ded7be@github.com>
References: <XtBvYsLSljF-NTYtEuYvx35NrdX3-VSu_MmirMCLfKc=.3b4e81e3-d53e-445e-85e4-0fb5e6ded7be@github.com>
Message-ID: <h7VwbEMAQoxnRW4AfsAzrNyONSOkjitz659CGrbjgKg=.c1452653-6f4b-4080-bd64-65e59dda9658@github.com>

On Wed, 22 Mar 2023 15:57:40 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Fixes the issue by transitioning the thread into the WXWrite mode while walking the stack in AsyncGetCallTrace.
> 
> Tested on my M1 mac.

Seems okay. But I am really over this game of whack-a-mole with ThreadWXEnable.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13144#pullrequestreview-1353732847

From xgong at openjdk.org  Thu Mar 23 02:25:44 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 23 Mar 2023 02:25:44 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v4]
In-Reply-To: <U-1I398elh4CJBPi5J2fEF14qp9ZgoYFhXxMD70L1wI=.2cecacd5-4fb6-4194-a5e4-c1801e0b7691@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
 <4Op0Z8whnyDXDC6zGyMbx4ugcZp5TEoAqW_myB5flxM=.1c7b59ba-efb2-4f68-90d7-2d6e33e39572@github.com>
 <yPyZ7su4OnRDd5LyQPvU0Hk6n5AI5CO2lR12qO9efCg=.51a05574-aee6-416b-863c-76d38a6766c3@github.com>
 <U-1I398elh4CJBPi5J2fEF14qp9ZgoYFhXxMD70L1wI=.2cecacd5-4fb6-4194-a5e4-c1801e0b7691@github.com>
Message-ID: <mHU3vRZX4H2iQsCCdwfJzsn8F4ZnmOKhSyv8uD-z9Js=.0d81453a-c349-4da7-b1f2-08b0b70c7761@github.com>

On Wed, 22 Mar 2023 12:42:15 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> src/hotspot/share/opto/vectorIntrinsics.cpp line 2059:
>> 
>>> 2057:   if (need_load_shuffle) {
>>> 2058:     shuffle = gvn().transform(new VectorLoadShuffleNode(shuffle, vt));
>>> 2059:   }
>> 
>> How about generating `VectorLoadShuffleNode` for all platforms that support Vector API, and remove the helper method `vector_needs_load_shuffle()` ? For those platforms that do not need this shuffle preparation, we can emit nothing  in codegen.
>
> I think not emitting `VectorLoadShuffleNode` is more common so it is better to emit them only when needed, as it will simplify the graph and may allow better inspections of the indices in the future. Additionally, a do-nothing node does not alias with its input and therefore kills the input, which leads to an additional spill if they both need to live.

Yeah, I agree that saving a node have some benefits like what you said. My concern is there are more and more methods added into `Matcher::` and each platform has to do the different implementation. There is not too much meaning for those platforms that do not implement Vector API like` arm/ppc/...` for me. This makes code not so easy to maintain.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1145598639

From xgong at openjdk.org  Thu Mar 23 02:31:46 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 23 Mar 2023 02:31:46 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v3]
In-Reply-To: <LBxWDJJAhoJ_U8PCWEhrQ27bXZqOx2vpnl4FGIgb7mk=.a7f55998-3191-432a-92e0-c1749078028e@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
 <4Op0Z8whnyDXDC6zGyMbx4ugcZp5TEoAqW_myB5flxM=.1c7b59ba-efb2-4f68-90d7-2d6e33e39572@github.com>
 <LBxWDJJAhoJ_U8PCWEhrQ27bXZqOx2vpnl4FGIgb7mk=.a7f55998-3191-432a-92e0-c1749078028e@github.com>
Message-ID: <_oZaqVXsCPRK3Poj6yp7Vi4S4cCuRygQv9pGhPvTAPk=.d7139597-8b20-4170-80cc-94ec7f88b2e4@github.com>

On Wed, 22 Mar 2023 08:09:03 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - missing casts
>>  - clean up
>
> Please also update the copyright to 2023 for some touched files like `vectorSupport.hpp` and other java files like `AbstractShuffle.java`, `AbstractVector.java`, `VectorShape.java`, and `VectorShuffle.java`. Thanks!

> @XiaohongGong Thanks, I have updated the copyright year and the code styles as you suggested

Thanks for your update! 

> I also noticed that the similar shuffle cast code is used more frequently. Could we wrap such code `toShuffle().cast(vspecies())` to a separate method?

And for this, is it possible to wrap such code in a single method?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13093#issuecomment-1480494762

From kvn at openjdk.org  Thu Mar 23 03:10:42 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 23 Mar 2023 03:10:42 GMT
Subject: RFR: 8304301: Remove the global option SuperWordMaxVectorSize
In-Reply-To: <UpWUCosBwcbNV7RFzR6XUWRDUYEms5GQ-mPIO3fLJuU=.dcdc631b-10d2-45b6-bf0d-6d5985815afc@github.com>
References: <2XQwCCx_ficJ1bn2WX0Ud9m-QmuGkkZAH8N6yLugXqQ=.90a136da-db9a-49b4-a4c4-d6c644cf7d5a@github.com>
 <duXNWlMrAPmK3G4XdmtGaWtHM7zZO-ZIiJkaoEpGEVs=.809396d8-8b48-4c42-af59-8f0fab6a55f5@github.com>
 <UpWUCosBwcbNV7RFzR6XUWRDUYEms5GQ-mPIO3fLJuU=.dcdc631b-10d2-45b6-bf0d-6d5985815afc@github.com>
Message-ID: <5XBZD2ChE3nmkvDfK8kUy4Pj4iHv1Ts7UB3AK7mJ0eg=.ca5ee7ba-f6e3-4560-b9c2-bc7f26cfe6ed@github.com>

On Thu, 23 Mar 2023 02:01:09 GMT, Fei Gao <fgao at openjdk.org> wrote:

> I added the FLAG_IS_DEFAULT(UseAVX) check to follow its original logic, see

I should have looked on existing code. Yes, it also checks  `FLAG_IS_DEFAULT(UseAVX)` and you did not change behavior. Good.

I don't have anymore questions. I am currently running specjvm2008 on Cascade Lake with default settings with and without your changes to make sure performance stays the same (I don't know why it would change based on your changes but to be safe). I will let you know results.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13112#issuecomment-1480540496

From kvn at openjdk.org  Thu Mar 23 03:36:57 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 23 Mar 2023 03:36:57 GMT
Subject: RFR: 8231349: Move intrinsic stubs generation to compiler runtime
 initialization code [v3]
In-Reply-To: <dtc9rdiBGUpqQUB9AzWBroeF3ziVODfk0FuPFDgOHqE=.096e99b2-2957-46c7-8c74-ae1d737f220d@github.com>
References: <dtc9rdiBGUpqQUB9AzWBroeF3ziVODfk0FuPFDgOHqE=.096e99b2-2957-46c7-8c74-ae1d737f220d@github.com>
Message-ID: <6_SaRBtPKCs9DnzzOvJZNuah57ufDhlsPoOAlbLuKeY=.9fe93ace-0b4c-44ce-aae1-8a3b5fe1d964@github.com>

> Based on performance data (see graph in RFE) I propose to implement @cl4es suggestion to move intrinsics stubs generation to C2 (and JVMCI) runtime initialization code.
> 
> It has <1% difference from not generated these stubs at all and we will not win on 1 core VMs but it is simpler and safer solution, I think. It also automatically (no need for new code) do not generate these stubs if C2 is not used (-Xint or low TieredStopAt Level.
> 
> On demand stubs generation requires synchronization between threads during application run which may introduce some instability and may be other issues. But it could be beneficial for Interpreter and C1 if we want more intrinsics stubs to be used by C1 and Interpreter (they use CRC32 only now).  I filed separate RFE  [8304422](https://bugs.openjdk.org/browse/JDK-8304422).
> 
> Changes:
>  - Added new platform specific diagnostic flag `-XX:+MoveIntrinsicStubsGen`. It is ON by default if VM is built with C2 or JVMCI compilers except Zero and 32-bit Arm VMs which have no or few intrinsics.
>  - Split `StubGenerator::generate_all()` method into two: `generate_final_stubs()` and `generate_compiler_stubs()`. Moved only C2 (and JVMCI) intrinsic stubs generation to new method.
>  - I renamed methods and stubs buffer sizes according to new code. Now we have 4 separate **named** stubs buffers and corresponding methods: _Initial, Continuation, Compiler, Final_.
>  - I added new UL printing to find new sizes for buffers and adjusted them on `aarch64` and `x86`. On other platforms I used the same as before value for `compiler_stubs` and `final_stubs`:
> 
>> java -Xlog:stubs -XX:+UseCompressedOops -XX:+CheckCompressedOops -XX:+VerifyOops -XX:+VerifyStackAtCalls -version
> [0.006s][info][stubs] StubRoutines (initial stubs)	 [0x00007f94900fcc00, 0x00007f9490101b60] used: 16152, free: 4168
> [0.026s][info][stubs] StubRoutines (continuation stubs)	 [0x00007f9490102580, 0x00007f9490102e90] used: 741, free: 1579
> [0.051s][info][stubs] StubRoutines (final stubs)	 [0x00007f9490155600, 0x00007f949015cc70] used: 26484, free: 3836
> [0.090s][info][stubs] StubRoutines (compiler stubs)	 [0x00007f94904ccc00, 0x00007f94904d9bd0] used: 46988, free: 6212
> java version "21-internal" 2023-09-19 LTS
> 
> -Xlog:stubs=debug will print size information for each stub:
> [0.005s][debug][stubs] ICache::flush_icache_stub [0x00007fb2d3828080, 0x00007fb2d382809d] (29 bytes)
> [0.005s][debug][stubs] VM_Version::get_cpu_info_stub [0x00007fb2d3828380, 0x00007fb2d3828714] (916 bytes)
> [0.005s][debug][stubs] VM_Version::detect_virt_stub [0x00007fb2d3828714, 0x00007fb2d382872e] (26 bytes)
> [0.005s][debug][stubs] StubRoutines::forward exception [0x00007fb2d3828c00, 0x00007fb2d3828c92] (146 bytes)
> 
> 
> Testing: tier1-7, Xcomp, stress on x64 and aarch64.
> 
> I have changes for all platforms. Please test it on platforms you support.

Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:

  Rename flag

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13096/files
  - new: https://git.openjdk.org/jdk/pull/13096/files/fe04169d..56d9b7f2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13096&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13096&range=01-02

  Stats: 34 lines in 10 files changed: 2 ins; 20 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/13096.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13096/head:pull/13096

PR: https://git.openjdk.org/jdk/pull/13096

From kvn at openjdk.org  Thu Mar 23 03:37:00 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 23 Mar 2023 03:37:00 GMT
Subject: RFR: 8231349: Move intrinsic stubs generation to compiler runtime
 initialization code [v2]
In-Reply-To: <mps4Bze-krj-aWVdtS6CcpRmOf9_gs-lmDI3iH7AvIQ=.8671e010-995c-4d1c-8282-afbb5ae6f2bf@github.com>
References: <dtc9rdiBGUpqQUB9AzWBroeF3ziVODfk0FuPFDgOHqE=.096e99b2-2957-46c7-8c74-ae1d737f220d@github.com>
 <mps4Bze-krj-aWVdtS6CcpRmOf9_gs-lmDI3iH7AvIQ=.8671e010-995c-4d1c-8282-afbb5ae6f2bf@github.com>
Message-ID: <YX72intbDBNCoz_lL71NtHiBhzClh4KbEldmnViz2Tc=.d193dd7b-d364-47c2-be40-178cb4d25c1c@github.com>

On Mon, 20 Mar 2023 17:17:13 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Based on performance data (see graph in RFE) I propose to implement @cl4es suggestion to move intrinsics stubs generation to C2 (and JVMCI) runtime initialization code.
>> 
>> It has <1% difference from not generated these stubs at all and we will not win on 1 core VMs but it is simpler and safer solution, I think. It also automatically (no need for new code) do not generate these stubs if C2 is not used (-Xint or low TieredStopAt Level.
>> 
>> On demand stubs generation requires synchronization between threads during application run which may introduce some instability and may be other issues. But it could be beneficial for Interpreter and C1 if we want more intrinsics stubs to be used by C1 and Interpreter (they use CRC32 only now).  I filed separate RFE  [8304422](https://bugs.openjdk.org/browse/JDK-8304422).
>> 
>> Changes:
>>  - Added new platform specific diagnostic flag `-XX:+MoveIntrinsicStubsGen`. It is ON by default if VM is built with C2 or JVMCI compilers except Zero and 32-bit Arm VMs which have no or few intrinsics.
>>  - Split `StubGenerator::generate_all()` method into two: `generate_final_stubs()` and `generate_compiler_stubs()`. Moved only C2 (and JVMCI) intrinsic stubs generation to new method.
>>  - I renamed methods and stubs buffer sizes according to new code. Now we have 4 separate **named** stubs buffers and corresponding methods: _Initial, Continuation, Compiler, Final_.
>>  - I added new UL printing to find new sizes for buffers and adjusted them on `aarch64` and `x86`. On other platforms I used the same as before value for `compiler_stubs` and `final_stubs`:
>> 
>>> java -Xlog:stubs -XX:+UseCompressedOops -XX:+CheckCompressedOops -XX:+VerifyOops -XX:+VerifyStackAtCalls -version
>> [0.006s][info][stubs] StubRoutines (initial stubs)	 [0x00007f94900fcc00, 0x00007f9490101b60] used: 16152, free: 4168
>> [0.026s][info][stubs] StubRoutines (continuation stubs)	 [0x00007f9490102580, 0x00007f9490102e90] used: 741, free: 1579
>> [0.051s][info][stubs] StubRoutines (final stubs)	 [0x00007f9490155600, 0x00007f949015cc70] used: 26484, free: 3836
>> [0.090s][info][stubs] StubRoutines (compiler stubs)	 [0x00007f94904ccc00, 0x00007f94904d9bd0] used: 46988, free: 6212
>> java version "21-internal" 2023-09-19 LTS
>> 
>> -Xlog:stubs=debug will print size information for each stub:
>> [0.005s][debug][stubs] ICache::flush_icache_stub [0x00007fb2d3828080, 0x00007fb2d382809d] (29 bytes)
>> [0.005s][debug][stubs] VM_Version::get_cpu_info_stub [0x00007fb2d3828380, 0x00007fb2d3828714] (916 bytes)
>> [0.005s][debug][stubs] VM_Version::detect_virt_stub [0x00007fb2d3828714, 0x00007fb2d382872e] (26 bytes)
>> [0.005s][debug][stubs] StubRoutines::forward exception [0x00007fb2d3828c00, 0x00007fb2d3828c92] (146 bytes)
>> 
>> 
>> Testing: tier1-7, Xcomp, stress on x64 and aarch64.
>> 
>> I have changes for all platforms. Please test it on platforms you support.
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address Claes comments

I renamed flag and used `COMPILER2_OR_JVMCI` as default value (based on Vladimir last suggestion).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13096#issuecomment-1480553323

From sspitsyn at openjdk.org  Thu Mar 23 05:46:42 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 23 Mar 2023 05:46:42 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v4]
In-Reply-To: <MvpNRiR8xVqGPSzxyo_Qq_Nk07LS60KVyKUpjVOt3Ug=.241061a2-6bb7-4919-b799-0912d658ed4c@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <zoKIGUF4f5eii5i29H9y-uT-OhAGch6Q2Eez6ApqOpI=.91e05f5b-9bf4-45f1-955e-71a983982a4d@github.com>
 <MvpNRiR8xVqGPSzxyo_Qq_Nk07LS60KVyKUpjVOt3Ug=.241061a2-6bb7-4919-b799-0912d658ed4c@github.com>
Message-ID: <94iP0mDhHYO_Ri-oeGEfd7rdzuSKrdaPg_PzzTyPRfs=.f36050a9-1e54-4b57-9d75-94d03b73c71a@github.com>

On Thu, 23 Mar 2023 02:00:56 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor cleanup in enable_virtual_threads_notify_jvmti()
>
> src/hotspot/share/prims/jvmtiEnvBase.hpp line 87:
> 
>> 85: 
>> 86:   static bool enable_virtual_threads_notify_jvmti();
>> 87:   static bool disable_virtual_threads_notify_jvmti();
> 
> "disable" only seems to be used by the WB API. Is that expected?

Yes, this is from the PR description:
> New function JvmtiEnvBase::disable_virtual_threads_notify_jvmti() which is needed for testing.
> It is used by the WhiteBox API.

Do you think a comment is needed?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1145702749

From sspitsyn at openjdk.org  Thu Mar 23 05:54:29 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 23 Mar 2023 05:54:29 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v5]
In-Reply-To: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
Message-ID: <27JLa60WeywSMcJj-6KfaQD8RBnwBbAvcc0gecc-3h4=.a2a25b70-9e90-4551-af90-35aed3d57b59@github.com>

> The fix is to enable virtual threads support for late binding JVMTI agents.
> The fix includes:
> - New function `JvmtiEnvBase::enable_virtual_threads_notify_jvmti()` which does enabling JVMTI VTMS transition notifications in case of agent loaded into running VM. This function executes a VM operation counting VTMS transition bits in all `JavaThread`'s to correctly set the static counter `_VTMS_transition_count` needed for VTMS transition protocol.
> - New function `JvmtiEnvBase::disable_virtual_threads_notify_jvmti()` which is needed for testing. It is used by the `WhiteBox` API.
> - New WhiteBox function `WB_SetVirtualThreadsNotifyJvmtiMode(JNIEnv* env, jobject wb, jboolean enable)` needed for testing of this update.
> - New regression test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
> 
> Testing:
> - New test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
> - The originally failed tests are expected to pass 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:

  address review comment: remove unneeded function

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13133/files
  - new: https://git.openjdk.org/jdk/pull/13133/files/52ef33b6..89b659d7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13133&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13133&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13133.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13133/head:pull/13133

PR: https://git.openjdk.org/jdk/pull/13133

From sspitsyn at openjdk.org  Thu Mar 23 05:54:33 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 23 Mar 2023 05:54:33 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v4]
In-Reply-To: <MvpNRiR8xVqGPSzxyo_Qq_Nk07LS60KVyKUpjVOt3Ug=.241061a2-6bb7-4919-b799-0912d658ed4c@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <zoKIGUF4f5eii5i29H9y-uT-OhAGch6Q2Eez6ApqOpI=.91e05f5b-9bf4-45f1-955e-71a983982a4d@github.com>
 <MvpNRiR8xVqGPSzxyo_Qq_Nk07LS60KVyKUpjVOt3Ug=.241061a2-6bb7-4919-b799-0912d658ed4c@github.com>
Message-ID: <zRoE-sQkogiARGRaSE57CQIjo8X0xEZHcgUaNRoHEI4=.9bab92df-7469-4f44-9e61-f30b21593f67@github.com>

On Thu, 23 Mar 2023 02:02:01 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor cleanup in enable_virtual_threads_notify_jvmti()
>
> src/hotspot/share/prims/jvmtiThreadState.hpp line 102:
> 
>> 100: 
>> 101:   static int  VTMS_transition_count()                { return _VTMS_transition_count; }
>> 102:   static void set_VTMS_transition_count(bool val)    { _VTMS_transition_count = val; }
> 
> Although there is a call to `set_VTMS_transition_count()`, I don't see any calls to `VTMS_transition_count()`. Are these really needed?

Thanks.
It was used in an assert that I recently removed as not important. Will remove it as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1145704755

From jbechberger at openjdk.org  Thu Mar 23 06:08:40 2023
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 23 Mar 2023 06:08:40 GMT
Subject: RFR: 8304725: AsyncGetCallTrace can cause SIGBUS on M1
In-Reply-To: <h7VwbEMAQoxnRW4AfsAzrNyONSOkjitz659CGrbjgKg=.c1452653-6f4b-4080-bd64-65e59dda9658@github.com>
References: <XtBvYsLSljF-NTYtEuYvx35NrdX3-VSu_MmirMCLfKc=.3b4e81e3-d53e-445e-85e4-0fb5e6ded7be@github.com>
 <h7VwbEMAQoxnRW4AfsAzrNyONSOkjitz659CGrbjgKg=.c1452653-6f4b-4080-bd64-65e59dda9658@github.com>
Message-ID: <ig7VuwWKgdiKyzLLeypZ1Iq33LLd3mWuiJ9gLZxSUfw=.77e9e061-4fc7-4362-a079-e1efdc79fbb3@github.com>

On Thu, 23 Mar 2023 02:17:44 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Seems okay. But I am really over this game of whack-a-mole with ThreadWXEnable.

You're not the only one. 

Andrei Pangin added a workaround to async-profiler, so nobody noticed the problem before.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13144#issuecomment-1480648254

From cjplummer at openjdk.org  Thu Mar 23 06:12:42 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 23 Mar 2023 06:12:42 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v4]
In-Reply-To: <94iP0mDhHYO_Ri-oeGEfd7rdzuSKrdaPg_PzzTyPRfs=.f36050a9-1e54-4b57-9d75-94d03b73c71a@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <zoKIGUF4f5eii5i29H9y-uT-OhAGch6Q2Eez6ApqOpI=.91e05f5b-9bf4-45f1-955e-71a983982a4d@github.com>
 <MvpNRiR8xVqGPSzxyo_Qq_Nk07LS60KVyKUpjVOt3Ug=.241061a2-6bb7-4919-b799-0912d658ed4c@github.com>
 <94iP0mDhHYO_Ri-oeGEfd7rdzuSKrdaPg_PzzTyPRfs=.f36050a9-1e54-4b57-9d75-94d03b73c71a@github.com>
Message-ID: <VZFqnaXA-ETThcZgzF3Z5yX6rePPFDlq3K5-7xTPULk=.b49eae92-4f81-4e89-93dd-156c6518df22@github.com>

On Thu, 23 Mar 2023 05:43:35 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiEnvBase.hpp line 87:
>> 
>>> 85: 
>>> 86:   static bool enable_virtual_threads_notify_jvmti();
>>> 87:   static bool disable_virtual_threads_notify_jvmti();
>> 
>> "disable" only seems to be used by the WB API. Is that expected?
>
> Yes, this is from the PR description:
>> New function JvmtiEnvBase::disable_virtual_threads_notify_jvmti() which is needed for testing.
>> It is used by the WhiteBox API.
> 
> Do you think a comment is needed?

I was wondering why we would be testing something that can't ever be triggered by a regular java program.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1145716490

From gcao at openjdk.org  Thu Mar 23 06:21:55 2023
From: gcao at openjdk.org (Gui Cao)
Date: Thu, 23 Mar 2023 06:21:55 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v11]
In-Reply-To: <HhhXq9Z8u_XlrOHqmG2U6vfS_2BJtR_1z6fxQOIEsH0=.092626f2-f07f-45cf-9133-de7053853630@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <HhhXq9Z8u_XlrOHqmG2U6vfS_2BJtR_1z6fxQOIEsH0=.092626f2-f07f-45cf-9133-de7053853630@github.com>
Message-ID: <H2RiTqOEzmED2eKLKxZL6WVyT1twRzK0g2RnuPw8evs=.8531b55d-e49c-46f3-b69b-c12f48e7096d@github.com>

On Wed, 22 Mar 2023 17:42:35 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
>> 
>> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
>> 
>> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
>> 
>> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
>> 
>> This change supports the following platforms: x86, aarch64, PPC, and RISCV
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improved comment for load-acquire aarch64

Looks good for me. tier1, no new errors introduced, please wait for me to finish the tier2 and tier3 tests.

-------------

PR Review: https://git.openjdk.org/jdk/pull/12778#pullrequestreview-1353916818

From stuefe at openjdk.org  Thu Mar 23 06:37:41 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 23 Mar 2023 06:37:41 GMT
Subject: RFR: JDK-8304723: Statically allocate global mutexes
In-Reply-To: <skYwSC4jAzrCin2w81NxHTghEskLccvCiuOBytcaNjc=.06749e56-835c-4899-9dad-b652474ef318@github.com>
References: <GnX35HIFItX1KV3Zsg5l-zwZVkhP_4Hq5o5ZhtiO57w=.94a86c58-3910-4b52-8c2f-3d6aaf713a06@github.com>
 <dqrnvRS2FRMd9WlY0Y1lkE9OsBv5xlLTxZQOTKYnmxk=.c6f842c3-adb9-4a6f-a786-317b1398ecba@github.com>
 <ITGp6nOcrq2hcnPNgpOUHkMOwhDu9NMdEwPgwKm-EyI=.c14951e3-0333-408f-bbf8-8f058c2a0009@github.com>
 <skYwSC4jAzrCin2w81NxHTghEskLccvCiuOBytcaNjc=.06749e56-835c-4899-9dad-b652474ef318@github.com>
Message-ID: <gJ1F_hnAxb_ihQhvsUYmW-L78LZPGl-yHDTJ-vpCaf8=.a192c7bf-c167-48e9-a9c0-42e939dad0a2@github.com>

On Wed, 22 Mar 2023 22:32:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > On posix, switch from pthread_cond_init to static initialization if possible.
> 
> Some platforms have the "wrong" default which is why we don't attempt to use the pthread static initializers. But in general statically initializing our Mutex/Monitor would be very fragile IMO - as discussed in the past.

Oh, right, there was that. Wonder if that still holds true today. Wasn't that Solaris?

> 
> Doing the allocation statically is a different matter. But what does this gain? Is the startup improvement noticeable?
> 

I'd be very happy if startup would be fast enough for ~150 fewer mallocs to matter. 

A blank hello world with no args to speak of calls into malloc >10k times. ~150(?) mallocs less are a step in the right direction.

My major gripe with this change is that I don't like the SimpleLock solution and suspect this could be simplified. I don't like the changes to the call sites either. 

A simple change to keep the mutex name in-line instead of mallocing it separately would already half the number of mallocs, and that would be a really trivial patch. One step further, one could allocate the mutexes in an array, or inside a single holder object. There are probably more ways to do this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13143#issuecomment-1480668404

From stuefe at openjdk.org  Thu Mar 23 06:47:42 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 23 Mar 2023 06:47:42 GMT
Subject: RFR: JDK-8304723: Statically allocate global mutexes [v2]
In-Reply-To: <qfME5gCVpGeIyyPDHR68gO5ZAb1xprwIV7smWrvmHXk=.f97b2e36-599b-49d6-b2a1-731d8b011188@github.com>
References: <GnX35HIFItX1KV3Zsg5l-zwZVkhP_4Hq5o5ZhtiO57w=.94a86c58-3910-4b52-8c2f-3d6aaf713a06@github.com>
 <qfME5gCVpGeIyyPDHR68gO5ZAb1xprwIV7smWrvmHXk=.f97b2e36-599b-49d6-b2a1-731d8b011188@github.com>
Message-ID: <yUYIEO3FCrjPRyPQZ40g0AsvgcRI2BNhoBsmACQWtSQ=.d5b2de47-d048-44cb-8178-df2b3dd744ac@github.com>

On Wed, 22 Mar 2023 17:24:28 GMT, Justin King <jcking at openjdk.org> wrote:

>> Switch to statically allocate storage for all of Hotspot's global mutexes and monitors. This avoids needing to allocate each one dynamically at startup. These also live for the lifetime of the program, so this reduces any potential memory fragmention in the C heap.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix lock being initialized twice and lock never initialized
>   
>   Signed-off-by: Justin King <jcking at google.com>

In case I was not clear: I like the intention of this patch and would prefer static allocation for Mutexes too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13143#issuecomment-1480677324

From stefank at openjdk.org  Thu Mar 23 07:02:39 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 23 Mar 2023 07:02:39 GMT
Subject: RFR: 8298725: Add BitMap support for reverse iteration
In-Reply-To: <5usc17TaIE2tQRj8IE58fBtVpXCNSxIp-nPQBzJlrmg=.a0620419-86c9-4a56-9ac7-9d317f07ea5e@github.com>
References: <5usc17TaIE2tQRj8IE58fBtVpXCNSxIp-nPQBzJlrmg=.a0620419-86c9-4a56-9ac7-9d317f07ea5e@github.com>
Message-ID: <MSma2xS4j2hdUslfA7JYrkBqykhD9dRewQXoMG7A8EU=.70429b02-140f-4446-8585-25d7ac124553@github.com>

On Wed, 22 Mar 2023 22:51:05 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this addition of BitMap::reverse_iterate, which is like
> BitMap::iterate but visits the set bits in a range from high index to low.
> 
> Testing:
> mach5 tier1, which includes running the updated gtests on all Oracle-supported
> platform

Looks good.

-------------

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13151#pullrequestreview-1353957741

From stuefe at openjdk.org  Thu Mar 23 07:06:43 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 23 Mar 2023 07:06:43 GMT
Subject: RFR: 8304725: AsyncGetCallTrace can cause SIGBUS on M1
In-Reply-To: <XtBvYsLSljF-NTYtEuYvx35NrdX3-VSu_MmirMCLfKc=.3b4e81e3-d53e-445e-85e4-0fb5e6ded7be@github.com>
References: <XtBvYsLSljF-NTYtEuYvx35NrdX3-VSu_MmirMCLfKc=.3b4e81e3-d53e-445e-85e4-0fb5e6ded7be@github.com>
Message-ID: <tl1eElZ_BU5p2rjsDXWyTWMoTPXmi8nqiDvvM1QQ_oo=.6852373b-e6c3-44b0-9abf-0ede61243b65@github.com>

On Wed, 22 Mar 2023 15:57:40 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Fixes the issue by transitioning the thread into the WXWrite mode while walking the stack in AsyncGetCallTrace.
> 
> Tested on my M1 mac.

Okay. Though the prospect of async profiler modifying the code cache by walking the stack seems scary.

-------------

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13144#pullrequestreview-1353962184

From stuefe at openjdk.org  Thu Mar 23 07:06:44 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 23 Mar 2023 07:06:44 GMT
Subject: RFR: 8304725: AsyncGetCallTrace can cause SIGBUS on M1
In-Reply-To: <ig7VuwWKgdiKyzLLeypZ1Iq33LLd3mWuiJ9gLZxSUfw=.77e9e061-4fc7-4362-a079-e1efdc79fbb3@github.com>
References: <XtBvYsLSljF-NTYtEuYvx35NrdX3-VSu_MmirMCLfKc=.3b4e81e3-d53e-445e-85e4-0fb5e6ded7be@github.com>
 <h7VwbEMAQoxnRW4AfsAzrNyONSOkjitz659CGrbjgKg=.c1452653-6f4b-4080-bd64-65e59dda9658@github.com>
 <ig7VuwWKgdiKyzLLeypZ1Iq33LLd3mWuiJ9gLZxSUfw=.77e9e061-4fc7-4362-a079-e1efdc79fbb3@github.com>
Message-ID: <3yjtW4MgHDAZQEQPcPOTFQdQm5rJ6QHQnDMLmXavVUo=.628eb73e-89d3-4926-ace7-35f57773fed1@github.com>

On Thu, 23 Mar 2023 06:05:33 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Seems okay. But I am really over this game of whack-a-mole with ThreadWXEnable.
>
>> Seems okay. But I am really over this game of whack-a-mole with ThreadWXEnable.
> 
> You're not the only one. 
> 
> Andrei Pangin added a workaround to async-profiler, so nobody noticed the problem before.

@parttimenerd I think you need two reviews in hotspot for integration.

You now effectively disable execution of generated code for the whole extend of AGCT? So we cannot call stub routines anymore. Won't hurt safefetch since it uses static assembly now, but something to keep in mind if you ever want to downport this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13144#issuecomment-1480693731

From eosterlund at openjdk.org  Thu Mar 23 07:09:40 2023
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 23 Mar 2023 07:09:40 GMT
Subject: RFR: 8304725: AsyncGetCallTrace can cause SIGBUS on M1
In-Reply-To: <XtBvYsLSljF-NTYtEuYvx35NrdX3-VSu_MmirMCLfKc=.3b4e81e3-d53e-445e-85e4-0fb5e6ded7be@github.com>
References: <XtBvYsLSljF-NTYtEuYvx35NrdX3-VSu_MmirMCLfKc=.3b4e81e3-d53e-445e-85e4-0fb5e6ded7be@github.com>
Message-ID: <HvZ0cwkKCtOWn6CUbjU0iU4I1q-uJV8udcjDp-EBgxA=.46fe91cc-0f5c-4919-b3e5-aebb7f5885b8@github.com>

On Wed, 22 Mar 2023 15:57:40 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Fixes the issue by transitioning the thread into the WXWrite mode while walking the stack in AsyncGetCallTrace.
> 
> Tested on my M1 mac.

Drive by comment: how async safe is WX enabler? If a thread is in the middle of it and we shoot a signal and enable, what will happen?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13144#issuecomment-1480697013

From jbechberger at openjdk.org  Thu Mar 23 07:29:45 2023
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 23 Mar 2023 07:29:45 GMT
Subject: RFR: 8304725: AsyncGetCallTrace can cause SIGBUS on M1
In-Reply-To: <3yjtW4MgHDAZQEQPcPOTFQdQm5rJ6QHQnDMLmXavVUo=.628eb73e-89d3-4926-ace7-35f57773fed1@github.com>
References: <XtBvYsLSljF-NTYtEuYvx35NrdX3-VSu_MmirMCLfKc=.3b4e81e3-d53e-445e-85e4-0fb5e6ded7be@github.com>
 <h7VwbEMAQoxnRW4AfsAzrNyONSOkjitz659CGrbjgKg=.c1452653-6f4b-4080-bd64-65e59dda9658@github.com>
 <ig7VuwWKgdiKyzLLeypZ1Iq33LLd3mWuiJ9gLZxSUfw=.77e9e061-4fc7-4362-a079-e1efdc79fbb3@github.com>
 <3yjtW4MgHDAZQEQPcPOTFQdQm5rJ6QHQnDMLmXavVUo=.628eb73e-89d3-4926-ace7-35f57773fed1@github.com>
Message-ID: <T9XiCtRoz5oeWC2m859OBtNSWtRpcRQPwu7fXxuEIpg=.99f92e35-b9a9-43b8-909c-079575c194fe@github.com>

On Thu, 23 Mar 2023 07:03:04 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> You now effectively disable execution of generated code for the whole extend of AGCT?

That's exactly what async-profiler does already https://github.com/async-profiler/async-profiler/blob/c8de91df6b090af82e91a066deb81a3afb505331/src/profiler.cpp#L383, I wonder why we don't have problems there with SafeFetch on older JVMs.

> Okay. Though the prospect of async profiler modifying the code cache by walking the stack seems scary.

We discussed it before. It's probably safe, but yes, my initial reaction was also "why not just remove this", but it should have a performance impact.

> Drive by comment: how async safe is WX enabler? If a thread is in the middle of it and we shoot a signal and enable, what will happen?

This is a really good point. I think that making the field that stores this information `volatile` could alleviate the problem (?). This would ensure that no reordering takes place in:


 _wx_state = WXWrite;
  os::current_thread_enable_wx(_wx_state);

(https://github.com/openjdk/jdk/blob/77cd917a97b184871ab2d3325ceb6c53afeca28b/src/hotspot/share/runtime/thread.inline.hpp#L78)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13144#issuecomment-1480713645

From xgong at openjdk.org  Thu Mar 23 07:34:49 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 23 Mar 2023 07:34:49 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v4]
In-Reply-To: <laGpMIPjIolDVaoKarrUxW0DciC7zHgpkGCgAc_bnO4=.c4c8252f-ff6a-4a79-9706-c120e2f96f94@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
 <laGpMIPjIolDVaoKarrUxW0DciC7zHgpkGCgAc_bnO4=.c4c8252f-ff6a-4a79-9706-c120e2f96f94@github.com>
Message-ID: <PzF1vuUr_snbzT3UpXC8l94aXuVuKJJVfddkw3RYRDs=.084e2476-8966-42d9-bdc3-0f2ca80938db@github.com>

On Wed, 22 Mar 2023 12:46:33 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, VectorShuffle is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
>> 
>> 1. Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
>> 2. Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
>> 3. Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
>> 4. Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
>> 
>> Upon these changes, a `rearrange` can emit more efficient code:
>> 
>>     var species = IntVector.SPECIES_128;
>>     var v1 = IntVector.fromArray(species, SRC1, 0);
>>     var v2 = IntVector.fromArray(species, SRC2, 0);
>>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
>> 
>>     Before:
>>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>>     vmovdqu 0x10(%r10),%xmm0
>>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>>                                                             ;   {external_word}
>>     vpackusdw %xmm0,%xmm0,%xmm0
>>     vpackuswb %xmm0,%xmm0,%xmm0
>>     vpmovsxbd %xmm0,%xmm3
>>     vpcmpgtd %xmm3,%xmm1,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fc2acb4e0d8
>>     vpmovzxbd %xmm0,%xmm0
>>     vpermd %ymm2,%ymm0,%ymm0
>>     movabs $0x751588f98,%r10            ;   {oop([I{0x0000000751588f98})}
>>     vmovdqu %xmm0,0x10(%r10)
>> 
>>     After:
>>     movabs $0x751589c78,%r10            ;   {oop([I{0x0000000751589c78})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158ac88,%r10            ;   {oop([I{0x000000075158ac88})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     vpxor  %xmm0,%xmm0,%xmm0
>>     vpcmpgtd %xmm2,%xmm0,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fa818b27cb1
>>     vpermd %ymm1,%ymm2,%ymm0
>>     movabs $0x751588c68,%r10            ;   {oop([I{0x0000000751588c68})}
>>     vmovdqu %xmm0,0x10(%r10)
>>     
>> Please take a look and leave reviews. Thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reviews

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java line 868:

> 866:             return (Byte128Vector) Byte128Vector.VSPECIES.dummyVector()
> 867:                     .vectorFactory(s.indices());
> 868:         }

Move the implementation details to the super class?

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteMaxVector.java line 862:

> 860:             v.convertShape(VectorOperators.B2I, species, 3)
> 861:                     .reinterpretAsInts()
> 862:                     .intoArray(a, offset + species.length() * 3);

Can we add a method like `intoIntArray()` in `ByteVector` and move these common code there? The same to other vector types.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteMaxVector.java line 919:

> 917:                     }
> 918:                     return false;
> 919:                 }

Same as `intoArray()`. Any possible that moving this function to `ByteVector` and rename it to something like `shuffleIndicesInRange` ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1145769798
PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1145781044
PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1145782910

From jbechberger at openjdk.org  Thu Mar 23 07:52:24 2023
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 23 Mar 2023 07:52:24 GMT
Subject: RFR: 8304725: AsyncGetCallTrace can cause SIGBUS on M1 [v2]
In-Reply-To: <XtBvYsLSljF-NTYtEuYvx35NrdX3-VSu_MmirMCLfKc=.3b4e81e3-d53e-445e-85e4-0fb5e6ded7be@github.com>
References: <XtBvYsLSljF-NTYtEuYvx35NrdX3-VSu_MmirMCLfKc=.3b4e81e3-d53e-445e-85e4-0fb5e6ded7be@github.com>
Message-ID: <fzHZvjNeyiwsnQ5v3otuVwDl3sjvEmg28nyyXmmC8I0=.f847a722-5bb6-44f5-b22d-5e59514a8a5e@github.com>

> Fixes the issue by transitioning the thread into the WXWrite mode while walking the stack in AsyncGetCallTrace.
> 
> Tested on my M1 mac.

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Make _wx_state volatile

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13144/files
  - new: https://git.openjdk.org/jdk/pull/13144/files/468d71e3..8af25ec0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13144&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13144&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13144.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13144/head:pull/13144

PR: https://git.openjdk.org/jdk/pull/13144

From aboldtch at openjdk.org  Thu Mar 23 08:10:42 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 23 Mar 2023 08:10:42 GMT
Subject: RFR: 8298725: Add BitMap support for reverse iteration
In-Reply-To: <5usc17TaIE2tQRj8IE58fBtVpXCNSxIp-nPQBzJlrmg=.a0620419-86c9-4a56-9ac7-9d317f07ea5e@github.com>
References: <5usc17TaIE2tQRj8IE58fBtVpXCNSxIp-nPQBzJlrmg=.a0620419-86c9-4a56-9ac7-9d317f07ea5e@github.com>
Message-ID: <kOl2lglc-BsZ_-kToAplzPsdxLnqed0YmehMbrd0pVk=.8e545e7c-aa92-4615-9a48-a80a3e64bb94@github.com>

On Wed, 22 Mar 2023 22:51:05 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this addition of BitMap::reverse_iterate, which is like
> BitMap::iterate but visits the set bits in a range from high index to low.
> 
> Testing:
> mach5 tier1, which includes running the updated gtests on all Oracle-supported
> platform

lgtm.

-------------

Marked as reviewed by aboldtch (Committer).

PR Review: https://git.openjdk.org/jdk/pull/13151#pullrequestreview-1354038812

From jbechberger at openjdk.org  Thu Mar 23 08:20:18 2023
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 23 Mar 2023 08:20:18 GMT
Subject: RFR: 8304725: AsyncGetCallTrace can cause SIGBUS on M1 [v3]
In-Reply-To: <XtBvYsLSljF-NTYtEuYvx35NrdX3-VSu_MmirMCLfKc=.3b4e81e3-d53e-445e-85e4-0fb5e6ded7be@github.com>
References: <XtBvYsLSljF-NTYtEuYvx35NrdX3-VSu_MmirMCLfKc=.3b4e81e3-d53e-445e-85e4-0fb5e6ded7be@github.com>
Message-ID: <DGciGzZDDGl15JBc93HuQEtwN-KxIPQquyLNJwQS5vM=.a30760eb-2239-4338-8425-33f8938ba514@github.com>

> Fixes the issue by transitioning the thread into the WXWrite mode while walking the stack in AsyncGetCallTrace.
> 
> Tested on my M1 mac.

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Use raw_thread instead of Thread::current()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13144/files
  - new: https://git.openjdk.org/jdk/pull/13144/files/8af25ec0..22b661dd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13144&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13144&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13144.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13144/head:pull/13144

PR: https://git.openjdk.org/jdk/pull/13144

From eosterlund at openjdk.org  Thu Mar 23 08:26:42 2023
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 23 Mar 2023 08:26:42 GMT
Subject: RFR: 8304725: AsyncGetCallTrace can cause SIGBUS on M1 [v3]
In-Reply-To: <T9XiCtRoz5oeWC2m859OBtNSWtRpcRQPwu7fXxuEIpg=.99f92e35-b9a9-43b8-909c-079575c194fe@github.com>
References: <XtBvYsLSljF-NTYtEuYvx35NrdX3-VSu_MmirMCLfKc=.3b4e81e3-d53e-445e-85e4-0fb5e6ded7be@github.com>
 <h7VwbEMAQoxnRW4AfsAzrNyONSOkjitz659CGrbjgKg=.c1452653-6f4b-4080-bd64-65e59dda9658@github.com>
 <ig7VuwWKgdiKyzLLeypZ1Iq33LLd3mWuiJ9gLZxSUfw=.77e9e061-4fc7-4362-a079-e1efdc79fbb3@github.com>
 <3yjtW4MgHDAZQEQPcPOTFQdQm5rJ6QHQnDMLmXavVUo=.628eb73e-89d3-4926-ace7-35f57773fed1@github.com>
 <T9XiCtRoz5oeWC2m859OBtNSWtRpcRQPwu7fXxuEIpg=.99f92e35-b9a9-43b8-909c-079575c194fe@github.com>
Message-ID: <8ygk_PGSqYUnmW9gxt5bg83dQJo1E1IPaw-TcMQPOio=.1ae61a0f-2d9b-4ba1-999a-7751b49bc578@github.com>

On Thu, 23 Mar 2023 07:27:14 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> > You now effectively disable execution of generated code for the whole extend of AGCT?
> 
> 
> 
> That's exactly what async-profiler does already https://github.com/async-profiler/async-profiler/blob/c8de91df6b090af82e91a066deb81a3afb505331/src/profiler.cpp#L383, I wonder why we don't have problems there with SafeFetch on older JVMs.
> 
> 
> 
> > Okay. Though the prospect of async profiler modifying the code cache by walking the stack seems scary.
> 
> 
> 
> We discussed it before. It's probably safe, but yes, my initial reaction was also "why not just remove this", but it should have a performance impact.
> 
> 
> 
> > Drive by comment: how async safe is WX enabler? If a thread is in the middle of it and we shoot a signal and enable, what will happen?
> 
> 
> 
> This is a really good point. I think that making the field that stores this information `volatile` could alleviate the problem (?). This would ensure that no reordering takes place in:
> 
> 
> 
> ```
> 
>  _wx_state = WXWrite;
> 
>   os::current_thread_enable_wx(_wx_state);
> 
> ```
> 
> (https://github.com/openjdk/jdk/blob/77cd917a97b184871ab2d3325ceb6c53afeca28b/src/hotspot/share/runtime/thread.inline.hpp#L78)

If you look at the enable_wx function, there is a lack of atomicity of the operation. It checks the current state and only conditionally decides to change the state. And when it does there is a write of the new state and a call to actually flip the mode. Seems to me that there could be many problematic interleavings where the signal hits in this code, which could mess things up. This code was not designed to be async safe, and I'm not convinced that sprinkling in volatile really solves that problem.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13144#issuecomment-1480769232

From jbechberger at openjdk.org  Thu Mar 23 08:29:44 2023
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 23 Mar 2023 08:29:44 GMT
Subject: RFR: 8304725: AsyncGetCallTrace can cause SIGBUS on M1 [v3]
In-Reply-To: <DGciGzZDDGl15JBc93HuQEtwN-KxIPQquyLNJwQS5vM=.a30760eb-2239-4338-8425-33f8938ba514@github.com>
References: <XtBvYsLSljF-NTYtEuYvx35NrdX3-VSu_MmirMCLfKc=.3b4e81e3-d53e-445e-85e4-0fb5e6ded7be@github.com>
 <DGciGzZDDGl15JBc93HuQEtwN-KxIPQquyLNJwQS5vM=.a30760eb-2239-4338-8425-33f8938ba514@github.com>
Message-ID: <OgU0w04HqaCKlfmq7r_Wkx4kqG1ZU_OdtFHZGigXDuA=.e4518216-9281-4382-b6e7-ae9ae2cf3ebc@github.com>

On Thu, 23 Mar 2023 08:20:18 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Fixes the issue by transitioning the thread into the WXWrite mode while walking the stack in AsyncGetCallTrace.
>> 
>> Tested on my M1 mac.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use raw_thread instead of Thread::current()

The best alternative to me is to take the perf hit and disable the caching when we're in forte (possibly only on Mac).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13144#issuecomment-1480772888

From sspitsyn at openjdk.org  Thu Mar 23 08:35:40 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 23 Mar 2023 08:35:40 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v4]
In-Reply-To: <VZFqnaXA-ETThcZgzF3Z5yX6rePPFDlq3K5-7xTPULk=.b49eae92-4f81-4e89-93dd-156c6518df22@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <zoKIGUF4f5eii5i29H9y-uT-OhAGch6Q2Eez6ApqOpI=.91e05f5b-9bf4-45f1-955e-71a983982a4d@github.com>
 <MvpNRiR8xVqGPSzxyo_Qq_Nk07LS60KVyKUpjVOt3Ug=.241061a2-6bb7-4919-b799-0912d658ed4c@github.com>
 <94iP0mDhHYO_Ri-oeGEfd7rdzuSKrdaPg_PzzTyPRfs=.f36050a9-1e54-4b57-9d75-94d03b73c71a@github.com>
 <VZFqnaXA-ETThcZgzF3Z5yX6rePPFDlq3K5-7xTPULk=.b49eae92-4f81-4e89-93dd-156c6518df22@github.com>
Message-ID: <2vKOdfA_ANscVsmo8hYjnooncmAQjPc81Y7UXrsl_eo=.f919cd8d-667c-4ae2-bdaa-3964bfcfd5f0@github.com>

On Thu, 23 Mar 2023 06:09:42 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Yes, this is from the PR description:
>>> New function JvmtiEnvBase::disable_virtual_threads_notify_jvmti() which is needed for testing.
>>> It is used by the WhiteBox API.
>> 
>> Do you think a comment is needed?
>
> I was wondering why we would be testing something that can't ever be triggered by a regular java program.

The function `JvmtiEnvBase::disable_virtual_threads_notify_jvmti()` is needed to test the `JvmtiEnvBase::enable_virtual_threads_notify_jvmti()`. To better test enabling we need to run it multiple times, so disabling is needed as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1145839021

From eosterlund at openjdk.org  Thu Mar 23 08:39:44 2023
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 23 Mar 2023 08:39:44 GMT
Subject: RFR: 8304725: AsyncGetCallTrace can cause SIGBUS on M1 [v3]
In-Reply-To: <OgU0w04HqaCKlfmq7r_Wkx4kqG1ZU_OdtFHZGigXDuA=.e4518216-9281-4382-b6e7-ae9ae2cf3ebc@github.com>
References: <XtBvYsLSljF-NTYtEuYvx35NrdX3-VSu_MmirMCLfKc=.3b4e81e3-d53e-445e-85e4-0fb5e6ded7be@github.com>
 <DGciGzZDDGl15JBc93HuQEtwN-KxIPQquyLNJwQS5vM=.a30760eb-2239-4338-8425-33f8938ba514@github.com>
 <OgU0w04HqaCKlfmq7r_Wkx4kqG1ZU_OdtFHZGigXDuA=.e4518216-9281-4382-b6e7-ae9ae2cf3ebc@github.com>
Message-ID: <CeRblzP5ogONxw_wnM0SylHEHGQmki58mS93h6640yc=.6b915a4b-afe2-46b9-af65-790ccc44a384@github.com>

On Thu, 23 Mar 2023 08:27:23 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> The best alternative to me is to take the perf hit and disable the caching when we're in forte (possibly only on Mac).

Sounds like a plan.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13144#issuecomment-1480784139

From jbechberger at openjdk.org  Thu Mar 23 08:44:42 2023
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 23 Mar 2023 08:44:42 GMT
Subject: RFR: 8304725: AsyncGetCallTrace can cause SIGBUS on M1 [v3]
In-Reply-To: <DGciGzZDDGl15JBc93HuQEtwN-KxIPQquyLNJwQS5vM=.a30760eb-2239-4338-8425-33f8938ba514@github.com>
References: <XtBvYsLSljF-NTYtEuYvx35NrdX3-VSu_MmirMCLfKc=.3b4e81e3-d53e-445e-85e4-0fb5e6ded7be@github.com>
 <DGciGzZDDGl15JBc93HuQEtwN-KxIPQquyLNJwQS5vM=.a30760eb-2239-4338-8425-33f8938ba514@github.com>
Message-ID: <z9S3O5qxd-BPhnclf0LOc7dm3JTkj0OBMS2Xl27PEVo=.daa7c58a-e817-4bfa-8a7a-a0ef1f01253a@github.com>

On Thu, 23 Mar 2023 08:20:18 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Fixes the issue by transitioning the thread into the WXWrite mode while walking the stack in AsyncGetCallTrace.
>> 
>> Tested on my M1 mac.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use raw_thread instead of Thread::current()

Or even better: We could disable the caching if we're not in the write-enabled mode. This way we don't need to change any other code.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13144#issuecomment-1480789489

From jbechberger at openjdk.org  Thu Mar 23 08:50:45 2023
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 23 Mar 2023 08:50:45 GMT
Subject: RFR: 8304725: AsyncGetCallTrace can cause SIGBUS on M1 [v3]
In-Reply-To: <DGciGzZDDGl15JBc93HuQEtwN-KxIPQquyLNJwQS5vM=.a30760eb-2239-4338-8425-33f8938ba514@github.com>
References: <XtBvYsLSljF-NTYtEuYvx35NrdX3-VSu_MmirMCLfKc=.3b4e81e3-d53e-445e-85e4-0fb5e6ded7be@github.com>
 <DGciGzZDDGl15JBc93HuQEtwN-KxIPQquyLNJwQS5vM=.a30760eb-2239-4338-8425-33f8938ba514@github.com>
Message-ID: <IWv1r7C--KlIcGs4nc3kLbUhBNyHAtCg8Fres6e7-CQ=.68516aee-be5f-48b3-8b3a-3dbed2d290b7@github.com>

On Thu, 23 Mar 2023 08:20:18 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Fixes the issue by transitioning the thread into the WXWrite mode while walking the stack in AsyncGetCallTrace.
>> 
>> Tested on my M1 mac.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use raw_thread instead of Thread::current()

We could just add a method `is_writable()` at https://github.com/openjdk/jdk/blob/8af25ec09d47900998b8fb58e2e7d486420df03d/src/hotspot/share/runtime/thread.hpp#L629 and call it in PcDesc code.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13144#issuecomment-1480797638

From fyang at openjdk.org  Thu Mar 23 09:11:54 2023
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 23 Mar 2023 09:11:54 GMT
Subject: RFR: 8294086: RISC-V: Cleanup InstructionMark usages in the
 backend
In-Reply-To: <0vL9HTzSH6i7KOSLmhCGPASAQjDzjnuCz3I7SsRrReA=.7a12d4ad-9f35-41ad-b4b3-a974b1dd9b61@github.com>
References: <0vL9HTzSH6i7KOSLmhCGPASAQjDzjnuCz3I7SsRrReA=.7a12d4ad-9f35-41ad-b4b3-a974b1dd9b61@github.com>
Message-ID: <OSAFXFiUpvRmZTPSQ6nkEDpRmjWLCZmodoQ5m-Cgrjo=.314d30bb-f9a7-4780-9b42-802d1cd92eeb@github.com>

On Wed, 21 Sep 2022 03:50:22 GMT, Xiaolin Zheng <xlinzheng at openjdk.org> wrote:

> This is a trivial cleanup of dummy `InstructionMark` usages in the RISC-V backend. There are no more `InstructionMark` usages in the backend now.
> 
> Tested hotspot tier1 and tier2 on Qemu.

Looks good.

-------------

PR Review: https://git.openjdk.org/jdk/pull/10369#pullrequestreview-1354142440

From jbechberger at openjdk.org  Thu Mar 23 09:36:43 2023
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 23 Mar 2023 09:36:43 GMT
Subject: RFR: 8304725: AsyncGetCallTrace can cause SIGBUS on M1 [v3]
In-Reply-To: <CeRblzP5ogONxw_wnM0SylHEHGQmki58mS93h6640yc=.6b915a4b-afe2-46b9-af65-790ccc44a384@github.com>
References: <XtBvYsLSljF-NTYtEuYvx35NrdX3-VSu_MmirMCLfKc=.3b4e81e3-d53e-445e-85e4-0fb5e6ded7be@github.com>
 <DGciGzZDDGl15JBc93HuQEtwN-KxIPQquyLNJwQS5vM=.a30760eb-2239-4338-8425-33f8938ba514@github.com>
 <OgU0w04HqaCKlfmq7r_Wkx4kqG1ZU_OdtFHZGigXDuA=.e4518216-9281-4382-b6e7-ae9ae2cf3ebc@github.com>
 <CeRblzP5ogONxw_wnM0SylHEHGQmki58mS93h6640yc=.6b915a4b-afe2-46b9-af65-790ccc44a384@github.com>
Message-ID: <RnlU8iuGFUMMj4TPwRcufniTBZwWpeW1Wb3b8FZ7oeY=.9944a33c-1e21-4954-bd0d-6e3a5991656d@github.com>

On Thu, 23 Mar 2023 08:36:59 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> > The best alternative to me is to take the perf hit and disable the caching when we're in forte (possibly only on Mac).
> 
> Sounds like a plan.

I'm going to write some code to check the performance impact of disabling it, on Mac and Linux. So we could maybe disable the cache modification on all platforms, which reduces the potential of bugs. This should be in the spirit of @tstuefe's comment.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13144#issuecomment-1480867620

From stuefe at openjdk.org  Thu Mar 23 09:44:43 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 23 Mar 2023 09:44:43 GMT
Subject: RFR: 8304725: AsyncGetCallTrace can cause SIGBUS on M1 [v3]
In-Reply-To: <CeRblzP5ogONxw_wnM0SylHEHGQmki58mS93h6640yc=.6b915a4b-afe2-46b9-af65-790ccc44a384@github.com>
References: <XtBvYsLSljF-NTYtEuYvx35NrdX3-VSu_MmirMCLfKc=.3b4e81e3-d53e-445e-85e4-0fb5e6ded7be@github.com>
 <DGciGzZDDGl15JBc93HuQEtwN-KxIPQquyLNJwQS5vM=.a30760eb-2239-4338-8425-33f8938ba514@github.com>
 <OgU0w04HqaCKlfmq7r_Wkx4kqG1ZU_OdtFHZGigXDuA=.e4518216-9281-4382-b6e7-ae9ae2cf3ebc@github.com>
 <CeRblzP5ogONxw_wnM0SylHEHGQmki58mS93h6640yc=.6b915a4b-afe2-46b9-af65-790ccc44a384@github.com>
Message-ID: <njq234A_d3A_KfD3vZNBdQKg75JAs5RTZv-cVEnbi2s=.d9c848c5-b460-4da4-abc0-43e18e60a38a@github.com>

On Thu, 23 Mar 2023 08:36:59 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> The best alternative to me is to take the perf hit and disable the caching when we're in forte (possibly only on Mac).
>
>> The best alternative to me is to take the perf hit and disable the caching when we're in forte (possibly only on Mac).
> 
> Sounds like a plan.

Reading @fisk excellent catch the async safety of stacking the wx raii mechanics, I retract my approval. This looks like a recipe for hard-to-find bugs :-/

Incidentally, do we see in the hs_err file whether async profiler is attached? We should maybe make that prominently visible.

> > The best alternative to me is to take the perf hit and disable the caching when we're in forte (possibly only on Mac).
> 
> Sounds like a plan.

I feel there are information missing :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13144#issuecomment-1480878975

From bkilambi at openjdk.org  Thu Mar 23 09:50:48 2023
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Thu, 23 Mar 2023 09:50:48 GMT
Subject: RFR: 8301012: [vectorapi]: Intrinsify CompressBitsV/ExpandBitsV
 and add the AArch64 SVE backend implementation [v2]
In-Reply-To: <WepLX4oA_2sxHK2IzxZPuCSw126ydVMIkLrQFlwBxhI=.1c20c2fe-62c7-4576-a7f5-bdbfa1055214@github.com>
References: <RaPIEa3D1wT6isue-1l_ILYJ6FCWSeNJ-T8QXtoxnUk=.05a804b5-9b2f-4486-aad4-53f00a3a6ab3@github.com>
 <WepLX4oA_2sxHK2IzxZPuCSw126ydVMIkLrQFlwBxhI=.1c20c2fe-62c7-4576-a7f5-bdbfa1055214@github.com>
Message-ID: <o24e3h3XNi7QgNOmCIQQQKl6cQOZsMYPfbGFmzm5V9k=.c0e53b97-fd74-4ca8-b91d-9baaee5f0006@github.com>

On Mon, 20 Mar 2023 17:37:59 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

>> This patch adds mid-end compiler vector IR nodes for the scalar CompressBits and ExpandBits nodes - CompressBitsV and ExpandBitsV and also adds aarch64 backend support for these nodes using SVE2 instructions (included in the svebitperm feature). As there are direct instructions in SVE2 that map to these operations, a huge speed up in performance can be observed and it might significantly benefit all those workloads that extensively run these operations on an SVE2(with svebitperm feature) supporting machine.
>> 
>> All the JTREG tests under "test/jdk/jdk/incubator/vector" pass successfully with this patch on an SVE2 machine.
>> The JMH tests - COMPRESS_BITS and EXPAND_BITS from [1] and [2] were run on a 128-bit vector length, SVE2 and svebitperm supporting aarch64 machine. Following are the gains observed with this patch -
>> 
>> 
>> Benchmark                       (length)  Mode    Cnt   Gain
>> IntMaxVector.COMPRESS_BITS      1024      thrpt   15    81.68x
>> IntMaxVector.EXPAND_BITS        1024      thrpt   15    85.65x
>> LongMaxVector.COMPRESS_BITS     1024      thrpt   15    70.78x
>> LongMaxVector.EXPAND_BITS       1024      thrpt   15    76.31x
>> 
>> 
>> The "Gain" column is the ratio between the throughput of benchmark runs with this patch and that of benchmark runs without this patch. This patch does not change the performance of these operations for all other machines that do not support these instructions or when run on a different architecture.
>> 
>> This patch enables the generation of optimized SVE2 instructions for CompressBits and ExpandBits operations through vectorapi but at the same time with the addition of scalar implementation of CompressBits andExpandBits in the aarch64 backend with this commit - https://github.com/openjdk/jdk/commit/bbd8ae78200e4128d4eddf8694835956b5c5f142, it also enabes auto-vectorization of these nodes on aarch64 SVE2 supporting machines.
>> 
>> Measured the performance of the following benchmarks with the master branch (auto-vectorization not enabled) with this patch
>> (auto-vectorization enabled) -
>>     
>> 
>>         @Benchmark
>>         public void testCompInt() {
>>             for (int i = 0; i < length; i++) {
>>                 ir[i] = Integer.compress(ia[i], ib[i]);
>>             }
>>         }
>>     
>>         @Benchmark
>>         public void testExpInt() {
>>             for (int i = 0; i < length; i++) {
>>                 ir[i] = Integer.expand(ia[i], ib[i]);
>>             }
>>         }
>>     
>>         @Benchmark
>>         public void testCompLong() {
>>             for (int i = 0; i < length; i++) {
>>                 lr[i] = Long.compress(la[i], lb[i]);
>>             }
>>         }
>>     
>>         @Benchmark
>>         public void testExpLong() {
>>             for (int i = 0; i < length; i++) {
>>                 lr[i] = Long.expand(la[i], lb[i]);
>>             }
>>         }
>>     
>>     Benchmark                               (length)  Mode     Cnt   Gain
>>     VectorCompressExpand.testCompInt        2048      thrpt    15    9.97x
>>     VectorCompressExpand.testCompLong       2048      thrpt    15    5.63x
>>     VectorCompressExpand.testExpInt         2048      thrpt    15    9.70x
>>     VectorCompressExpand.testExpLong        2048      thrpt    15    5.66x
>> 
>> ```    
>>     
>> Gain column is the ratio between the throughput of this patch and that of the master branch.
>> With vectorization enabled (either through Superword or Vectorapi), significant gains can be observed for CompressBits and ExpandBits.
>> 
>> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/IntMaxVector.java 
>> [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/LongMaxVector.java
>
> Bhavana Kilambi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge master and fix conflicts
>  - 8301012: [vectorapi]: Intrinsify CompressBitsV/ExpandBitsV and add the AArch64 SVE backend implementation
>    
>    This patch adds mid-end compiler vector IR nodes for the scalar
>    CompressBits and ExpandBits nodes - CompressBitsV and ExpandBitsV and
>    also adds aarch64 backend support for these nodes using SVE2
>    instructions (included in the svebitperm feature).
>    As there are direct instructions in SVE2 that map to these operations,
>    a huge speed up in performance can be observed and it might significantly
>    benefit all those workloads that extensively run these operations on an
>    SVE2(with svebitperm feature) supporting machine.
>    
>    All the JTREG tests under "test/jdk/jdk/incubator/vector" pass
>    successfully with this patch on an SVE2 machine.
>    The JMH tests - COMPRESS_BITS and EXPAND_BITS from [1] and [2]
>    were run on a 128-bit vector length, SVE2 and svebitperm supporting
>    aarch64 machine. Following are the gains observed with this patch -
>    
>    Benchmark                       (length)  Mode    Cnt   Gain
>    IntMaxVector.COMPRESS_BITS      1024      thrpt   15    81.68x
>    IntMaxVector.EXPAND_BITS        1024      thrpt   15    85.65x
>    LongMaxVector.COMPRESS_BITS     1024      thrpt   15    70.78x
>    LongMaxVector.EXPAND_BITS       1024      thrpt   15    76.31x
>    
>    The "Gain" column is the ratio between the throughput of benchmark runs
>    with this patch and that of benchmark runs without this patch. This patch
>    does not change the performance of these operations for all other
>    machines that do not support these instructions or when run on a
>    different architecture.
>    With this patch, vectorization of CompressBits and ExpandBits operations
>    happens only through vectorapi for aarch64. Autovectorization does not
>    take place as the current JDK source does not contain aarch64 backend
>    implementation for scalar CompressBits and ExpandBits. However, this PR -
>    https://github.com/openjdk/jdk/pull/10537 adds aarch64 backend
>    implementaton for CompressBits and ExpandBits and may lead to
>    autovectorization of these nodes as well eventually but this PR is a
>    standalone one and not dependent on the scalar implementation.
>    
>    [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/IntMaxVector.java
>    [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/LongMaxVector.java

Hi @TobiHartmann , could you please take a look at the C2 related changes in this PR please? Thank you ..

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12446#issuecomment-1480886881

From jbechberger at openjdk.org  Thu Mar 23 09:48:46 2023
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 23 Mar 2023 09:48:46 GMT
Subject: RFR: 8304725: AsyncGetCallTrace can cause SIGBUS on M1 [v3]
In-Reply-To: <CeRblzP5ogONxw_wnM0SylHEHGQmki58mS93h6640yc=.6b915a4b-afe2-46b9-af65-790ccc44a384@github.com>
References: <XtBvYsLSljF-NTYtEuYvx35NrdX3-VSu_MmirMCLfKc=.3b4e81e3-d53e-445e-85e4-0fb5e6ded7be@github.com>
 <DGciGzZDDGl15JBc93HuQEtwN-KxIPQquyLNJwQS5vM=.a30760eb-2239-4338-8425-33f8938ba514@github.com>
 <OgU0w04HqaCKlfmq7r_Wkx4kqG1ZU_OdtFHZGigXDuA=.e4518216-9281-4382-b6e7-ae9ae2cf3ebc@github.com>
 <CeRblzP5ogONxw_wnM0SylHEHGQmki58mS93h6640yc=.6b915a4b-afe2-46b9-af65-790ccc44a384@github.com>
Message-ID: <E8Kg87i_KRBRfDmV2oqB_WdqKZk0hMDVHDJfa3ZWdnw=.8fc6aceb-bb09-4c56-87eb-acf81f60d762@github.com>

On Thu, 23 Mar 2023 08:36:59 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> The best alternative to me is to take the perf hit and disable the caching when we're in forte (possibly only on Mac).
>
>> The best alternative to me is to take the perf hit and disable the caching when we're in forte (possibly only on Mac).
> 
> Sounds like a plan.

> Reading @fisk excellent catch the async safety of stacking the wx raii mechanics, I retract my approval. This looks like a recipe for hard-to-find bugs :-/

Yes, this is my current thought too.

> Incidentally, do we see in the hs_err file whether async profiler is attached? We should maybe make that prominently visible.

We see ASGCT in the stack trace, but what exactly do you mean.

> I feel there are information missing :)

But would you be okay with disabling the cache modification if the perf impact is low?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13144#issuecomment-1480883378

From mcimadamore at openjdk.org  Thu Mar 23 10:30:47 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 23 Mar 2023 10:30:47 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: <yWgrZFrwKiPd5c9G1JUMJfv3xjtl8fYJ-GFr5sPsdwk=.d660f1f6-0d7c-42ce-8fca-9c3309c2a160@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
 <oy4LL8ML2Y3MpKfF0hBwGOKLIaLDfPmpKEWf-v0Mizg=.c7f72545-ce7b-450d-a96a-f9021dc3b9e4@github.com>
 <69SHPBocr-b_789_vAvfpV67J_7ZrNal8SSnAFxugyw=.a971481e-9707-4022-88bd-b80906996cc7@github.com>
 <vFO8K64fvvkg9jyeNelszMVal-uJTW-NYetwQ0oS3cM=.37effa35-d084-41bc-aee3-4ec2d8cf5b60@github.com>
 <yWgrZFrwKiPd5c9G1JUMJfv3xjtl8fYJ-GFr5sPsdwk=.d660f1f6-0d7c-42ce-8fca-9c3309c2a160@github.com>
Message-ID: <Dnp-mfHydFBZL0PJJxMhG9nYnB4P9MFthqvSmv8IdLY=.4154cc1f-66ea-46c7-a6d3-a4add7e94844@github.com>

On Wed, 22 Mar 2023 20:07:01 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Ah. True. This is true about all the MS parameters as well.
>
> Yes - although there is a distinction between passed by value and by ref. I wouldn't be surprised if we just threw NPE for by-value.

Just did a test with jshell:


jshell> Linker linker = Linker.nativeLinker();

jshell> MethodHandle handleValue = linker.downcallHandle(FunctionDescriptor.ofVoid(MemoryLayout.structLayout(ValueLayout.JAVA_INT)));
handleValue ==> MethodHandle(MemorySegment,MemorySegment)void

jshell> handleValue.invoke(MemorySegment.ofAddress(1), null);
|  Exception java.lang.NullPointerException
|        at (#5:1)


So, yes, passing `null` for a "by-value" struct issues NPEs. I also get same exception when calling a method handle which passes a struct by reference:


jshell> MethodHandle handleRef = linker.downcallHandle(FunctionDescriptor.ofVoid(ValueLayout.ADDRESS));
handleRef ==> MethodHandle(MemorySegment,MemorySegment)void

jshell> handleRef.invoke(MemorySegment.ofAddress(1), null);
|  Exception java.lang.NullPointerException
|        at (#7:1)


Given what the impl does, to be fair I don't mind the NPE (it seems a good exception to throw if we're passing a raw `null`). But we should document it at such.

It also seems like the first parameter of the downcall has somewhat better checks (but still NPEs):


jshell> handleRef.invoke(null, MemorySegment.ofAddress(1));
|  Exception java.lang.NullPointerException
|        at Objects.requireNonNull (Objects.java:233)
|        at SharedUtils.checkSymbol (SharedUtils.java:351)
|        at (#8:1)


And:


jshell> handleRef.invoke(MemorySegment.NULL, MemorySegment.ofAddress(1));
|  Exception java.lang.IllegalArgumentException: Symbol is NULL: MemorySegment{ heapBase: Optional.empty address:0 limit: 0 }
|        at SharedUtils.checkSymbol (SharedUtils.java:353)
|        at (#9:1)


I think this last case is the _only_ one where IAE is warranted - as the role of the first parameter is special, and we can't tolerate a `MemorySegment::NULL` there. For all other reference parameters, the downcall handle should just check that they are non-null, and throw if so.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1145978702

From mcimadamore at openjdk.org  Thu Mar 23 10:34:50 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 23 Mar 2023 10:34:50 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: <Dnp-mfHydFBZL0PJJxMhG9nYnB4P9MFthqvSmv8IdLY=.4154cc1f-66ea-46c7-a6d3-a4add7e94844@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
 <oy4LL8ML2Y3MpKfF0hBwGOKLIaLDfPmpKEWf-v0Mizg=.c7f72545-ce7b-450d-a96a-f9021dc3b9e4@github.com>
 <69SHPBocr-b_789_vAvfpV67J_7ZrNal8SSnAFxugyw=.a971481e-9707-4022-88bd-b80906996cc7@github.com>
 <vFO8K64fvvkg9jyeNelszMVal-uJTW-NYetwQ0oS3cM=.37effa35-d084-41bc-aee3-4ec2d8cf5b60@github.com>
 <yWgrZFrwKiPd5c9G1JUMJfv3xjtl8fYJ-GFr5sPsdwk=.d660f1f6-0d7c-42ce-8fca-9c3309c2a160@github.com>
 <Dnp-mfHydFBZL0PJJxMhG9nYnB4P9MFthqvSmv8IdLY=.4154cc1f-66ea-46c7-a6d3-a4add7e94844@github.com>
Message-ID: <QzxKSr0yyGvC-V_dXbvxeywSxyy9sWgsl1mFeukWzIY=.35ba1839-8859-49bf-879c-638f9af58758@github.com>

On Thu, 23 Mar 2023 10:28:23 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Yes - although there is a distinction between passed by value and by ref. I wouldn't be surprised if we just threw NPE for by-value.
>
> Just did a test with jshell:
> 
> 
> jshell> Linker linker = Linker.nativeLinker();
> 
> jshell> MethodHandle handleValue = linker.downcallHandle(FunctionDescriptor.ofVoid(MemoryLayout.structLayout(ValueLayout.JAVA_INT)));
> handleValue ==> MethodHandle(MemorySegment,MemorySegment)void
> 
> jshell> handleValue.invoke(MemorySegment.ofAddress(1), null);
> |  Exception java.lang.NullPointerException
> |        at (#5:1)
> 
> 
> So, yes, passing `null` for a "by-value" struct issues NPEs. I also get same exception when calling a method handle which passes a struct by reference:
> 
> 
> jshell> MethodHandle handleRef = linker.downcallHandle(FunctionDescriptor.ofVoid(ValueLayout.ADDRESS));
> handleRef ==> MethodHandle(MemorySegment,MemorySegment)void
> 
> jshell> handleRef.invoke(MemorySegment.ofAddress(1), null);
> |  Exception java.lang.NullPointerException
> |        at (#7:1)
> 
> 
> Given what the impl does, to be fair I don't mind the NPE (it seems a good exception to throw if we're passing a raw `null`). But we should document it at such.
> 
> It also seems like the first parameter of the downcall has somewhat better checks (but still NPEs):
> 
> 
> jshell> handleRef.invoke(null, MemorySegment.ofAddress(1));
> |  Exception java.lang.NullPointerException
> |        at Objects.requireNonNull (Objects.java:233)
> |        at SharedUtils.checkSymbol (SharedUtils.java:351)
> |        at (#8:1)
> 
> 
> And:
> 
> 
> jshell> handleRef.invoke(MemorySegment.NULL, MemorySegment.ofAddress(1));
> |  Exception java.lang.IllegalArgumentException: Symbol is NULL: MemorySegment{ heapBase: Optional.empty address:0 limit: 0 }
> |        at SharedUtils.checkSymbol (SharedUtils.java:353)
> |        at (#9:1)
> 
> 
> I think this last case is the _only_ one where IAE is warranted - as the role of the first parameter is special, and we can't tolerate a `MemorySegment::NULL` there. For all other reference parameters, the downcall handle should just check that they are non-null, and throw if so.

The returned method handle will throw an {@link IllegalArgumentException} if the {@link MemorySegment}
representing the target address of the foreign function is the {@link MemorySegment#NULL} address.
The returned method handle will additionally throw {@link NullPointerException} if any parameter of type {@link MemorySegment} is {@code null}.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1145982159

From tschatzl at openjdk.org  Thu Mar 23 10:45:43 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 23 Mar 2023 10:45:43 GMT
Subject: RFR: 8304802: After JDK-8297639 the flag UsePreventiveGC needs to be
 added to the obsoletion table
Message-ID: <InH4JukIq7ToDARFz4yGGan43_mE6Vs0yyNBP9mPtok=.2b624755-d549-4e6e-b297-304480d401d9@github.com>

Hi all,

  please review this change that puts the `G1UsePreventiveGC` into the argument obsoletion table so that the appropriate warning is printed when starting the VM with that option. Functionality has already been removed, and CSR request approved with [JDK-8297639](https://bugs.openjdk.org/browse/JDK-8297639).

Testing: local compilation, manual testing that the obsoletion warning is printed on the command line.

Thanks,
  Thomas

-------------

Commit messages:
 - initial version

Changes: https://git.openjdk.org/jdk/pull/13156/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13156&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304802
  Stats: 9 lines in 2 files changed: 1 ins; 5 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13156.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13156/head:pull/13156

PR: https://git.openjdk.org/jdk/pull/13156

From aph at openjdk.org  Thu Mar 23 10:46:56 2023
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 23 Mar 2023 10:46:56 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v11]
In-Reply-To: <HhhXq9Z8u_XlrOHqmG2U6vfS_2BJtR_1z6fxQOIEsH0=.092626f2-f07f-45cf-9133-de7053853630@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <HhhXq9Z8u_XlrOHqmG2U6vfS_2BJtR_1z6fxQOIEsH0=.092626f2-f07f-45cf-9133-de7053853630@github.com>
Message-ID: <BTgtembsn78Yuhof2gGOwYKX4ir7jwfUHqhgE0QYUc8=.0f9a57e9-1d61-4488-879f-293a14bb6ebe@github.com>

On Wed, 22 Mar 2023 17:42:35 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
>> 
>> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
>> 
>> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
>> 
>> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
>> 
>> This change supports the following platforms: x86, aarch64, PPC, and RISCV
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improved comment for load-acquire aarch64

src/hotspot/cpu/aarch64/templateTable_aarch64.cpp line 2368:

> 2366:   __ tst(index, index);
> 2367:   __ br(Assembler::EQ, L_no_push);
> 2368: 

Maybe I don't understand what this should do?

Suggestion:

    __ tbz(index, ResolvedIndyEntry::has_appendix_shift, L_no_push);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12778#discussion_r1145995182

From stuefe at openjdk.org  Thu Mar 23 11:49:48 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 23 Mar 2023 11:49:48 GMT
Subject: RFR: 8304725: AsyncGetCallTrace can cause SIGBUS on M1 [v3]
In-Reply-To: <CeRblzP5ogONxw_wnM0SylHEHGQmki58mS93h6640yc=.6b915a4b-afe2-46b9-af65-790ccc44a384@github.com>
References: <XtBvYsLSljF-NTYtEuYvx35NrdX3-VSu_MmirMCLfKc=.3b4e81e3-d53e-445e-85e4-0fb5e6ded7be@github.com>
 <DGciGzZDDGl15JBc93HuQEtwN-KxIPQquyLNJwQS5vM=.a30760eb-2239-4338-8425-33f8938ba514@github.com>
 <OgU0w04HqaCKlfmq7r_Wkx4kqG1ZU_OdtFHZGigXDuA=.e4518216-9281-4382-b6e7-ae9ae2cf3ebc@github.com>
 <CeRblzP5ogONxw_wnM0SylHEHGQmki58mS93h6640yc=.6b915a4b-afe2-46b9-af65-790ccc44a384@github.com>
Message-ID: <bvlqS4aFu_U_vk3bVzZBqFy68-NFSC1Ovt7WTwQji7I=.169c08b3-2e92-4d98-bcf6-059691a7e2d8@github.com>

On Thu, 23 Mar 2023 08:36:59 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> The best alternative to me is to take the perf hit and disable the caching when we're in forte (possibly only on Mac).
>
>> The best alternative to me is to take the perf hit and disable the caching when we're in forte (possibly only on Mac).
> 
> Sounds like a plan.

> > Reading @fisk excellent catch the async safety of stacking the wx raii mechanics, I retract my approval. This looks like a recipe for hard-to-find bugs :-/
> 
> Yes, this is my current thought too.
> 
> > Incidentally, do we see in the hs_err file whether async profiler is attached? We should maybe make that prominently visible.
> 
> We see ASGCT in the stack trace, but what exactly do you mean.
> 

For issues like this, you wouldn't necessarily have AGCT on the stack. Consider:
- Compiler gets invoked, write protects, compiles, then tries to restore write protection. Gets interrupted by AGCT after calling pthread_jit_write_protect_np but before updating Thread::_wx_state.
- Now AGCT runs. It disables write protection, does its thing, then reinstates the state *it thinks preceded it*. But that is the wrong state. In this case, the one used during compilation.
- we return from signal handling. Compiler now sets Thread::_wx_state and assumes write protection is restored, but it isnt.
- Later that day, the thread tries to call into compiled code. It will not be able to execute it, since the protection is wrong. 

There are variants of this play, but my point is the resulting crashes may happen after AGCT was invoked. 

So all we spy with our little eyes would be a segfault, I guess SEGV_ACCERR ?, and maybe the AGCT shared lib among the list of loaded libraries. 

In particular, we do not know if AGCT did interrupt the crashing thread recently. Or do we? This would be valuable information.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13144#issuecomment-1481044491

From jbechberger at openjdk.org  Thu Mar 23 12:03:06 2023
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 23 Mar 2023 12:03:06 GMT
Subject: RFR: 8304725: AsyncGetCallTrace can cause SIGBUS on M1 [v3]
In-Reply-To: <bvlqS4aFu_U_vk3bVzZBqFy68-NFSC1Ovt7WTwQji7I=.169c08b3-2e92-4d98-bcf6-059691a7e2d8@github.com>
References: <XtBvYsLSljF-NTYtEuYvx35NrdX3-VSu_MmirMCLfKc=.3b4e81e3-d53e-445e-85e4-0fb5e6ded7be@github.com>
 <DGciGzZDDGl15JBc93HuQEtwN-KxIPQquyLNJwQS5vM=.a30760eb-2239-4338-8425-33f8938ba514@github.com>
 <OgU0w04HqaCKlfmq7r_Wkx4kqG1ZU_OdtFHZGigXDuA=.e4518216-9281-4382-b6e7-ae9ae2cf3ebc@github.com>
 <CeRblzP5ogONxw_wnM0SylHEHGQmki58mS93h6640yc=.6b915a4b-afe2-46b9-af65-790ccc44a384@github.com>
 <bvlqS4aFu_U_vk3bVzZBqFy68-NFSC1Ovt7WTwQji7I=.169c08b3-2e92-4d98-bcf6-059691a7e2d8@github.com>
Message-ID: <IMcYKnGw3L0At9QhNBJrUc61HIsghUQeEY24rhXOhjQ=.a9a12084-329f-4619-ae05-b0af5c7d105f@github.com>

On Thu, 23 Mar 2023 11:46:12 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> There are variants of this play, but my point is the resulting crashes may happen after AGCT was invoked.

I see the problem. Thanks for adding some clarification. We can all agree that my intended fix is not really a fix.

>So all we spy with our little eyes would be a segfault, I guess SEGV_ACCERR ?, and maybe the AGCT shared lib among the list of loaded libraries.

Do you mean async-profiler? This would then hard-code the name of every relevant profiler in the OpenJDK.

> In particular, we do not know if AGCT did interrupt the crashing thread recently. Or do we? This would be valuable information.

Yes. But it could indeed be helpful information when debugging problems. Please don't forget that JFR has a very similar code, and it would be good to have the information on whether JFR sampled a thread recently too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13144#issuecomment-1481067359

From dholmes at openjdk.org  Thu Mar 23 12:35:57 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 23 Mar 2023 12:35:57 GMT
Subject: RFR: 8304725: AsyncGetCallTrace can cause SIGBUS on M1 [v3]
In-Reply-To: <DGciGzZDDGl15JBc93HuQEtwN-KxIPQquyLNJwQS5vM=.a30760eb-2239-4338-8425-33f8938ba514@github.com>
References: <XtBvYsLSljF-NTYtEuYvx35NrdX3-VSu_MmirMCLfKc=.3b4e81e3-d53e-445e-85e4-0fb5e6ded7be@github.com>
 <DGciGzZDDGl15JBc93HuQEtwN-KxIPQquyLNJwQS5vM=.a30760eb-2239-4338-8425-33f8938ba514@github.com>
Message-ID: <GmJojVJbm1OBMw59db69c1DWYOkV05LEvmi19YynwKw=.acf990da-6238-42e4-bf6f-58dd74dfa8f9@github.com>

On Thu, 23 Mar 2023 08:20:18 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Fixes the issue by transitioning the thread into the WXWrite mode while walking the stack in AsyncGetCallTrace.
>> 
>> Tested on my M1 mac.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use raw_thread instead of Thread::current()

AGCT uses signals - most of what it does is not safe.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13144#issuecomment-1481116274

From dholmes at openjdk.org  Thu Mar 23 12:39:44 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 23 Mar 2023 12:39:44 GMT
Subject: RFR: 8304725: AsyncGetCallTrace can cause SIGBUS on M1 [v3]
In-Reply-To: <DGciGzZDDGl15JBc93HuQEtwN-KxIPQquyLNJwQS5vM=.a30760eb-2239-4338-8425-33f8938ba514@github.com>
References: <XtBvYsLSljF-NTYtEuYvx35NrdX3-VSu_MmirMCLfKc=.3b4e81e3-d53e-445e-85e4-0fb5e6ded7be@github.com>
 <DGciGzZDDGl15JBc93HuQEtwN-KxIPQquyLNJwQS5vM=.a30760eb-2239-4338-8425-33f8938ba514@github.com>
Message-ID: <OHpvWIZHs3RLp9-HFSv3xieWkSY2qSQ6WfDGG1qNx0s=.a57299bb-80f1-4240-bb27-4bdb677d0653@github.com>

On Thu, 23 Mar 2023 08:20:18 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Fixes the issue by transitioning the thread into the WXWrite mode while walking the stack in AsyncGetCallTrace.
>> 
>> Tested on my M1 mac.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use raw_thread instead of Thread::current()

So AGCT already breaks in this scenario because WX is not enabled when needed. The code to enable WX is not async-signal_safe, so the "fix" is only a partial fix - it will sometimes fail too. So we go from broken to slightly less broken.

This is why AGCT is not supported.

Anyway retracting my review while discussion continues.

-------------

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13144#pullrequestreview-1354523473

From jbechberger at openjdk.org  Thu Mar 23 12:48:14 2023
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 23 Mar 2023 12:48:14 GMT
Subject: RFR: 8304725: AsyncGetCallTrace can cause SIGBUS on M1 [v3]
In-Reply-To: <GYzemBQG5TFFf_wUxFdersNkjuHumLMyM5hgQx0QE8Q=.b4c93261-0b0d-40d1-9419-2a5cdee3eeec@github.com>
References: <XtBvYsLSljF-NTYtEuYvx35NrdX3-VSu_MmirMCLfKc=.3b4e81e3-d53e-445e-85e4-0fb5e6ded7be@github.com>
 <DGciGzZDDGl15JBc93HuQEtwN-KxIPQquyLNJwQS5vM=.a30760eb-2239-4338-8425-33f8938ba514@github.com>
 <OgU0w04HqaCKlfmq7r_Wkx4kqG1ZU_OdtFHZGigXDuA=.e4518216-9281-4382-b6e7-ae9ae2cf3ebc@github.com>
 <CeRblzP5ogONxw_wnM0SylHEHGQmki58mS93h6640yc=.6b915a4b-afe2-46b9-af65-790ccc44a384@github.com>
 <bvlqS4aFu_U_vk3bVzZBqFy68-NFSC1Ovt7WTwQji7I=.169c08b3-2e92-4d98-bcf6-059691a7e2d8@github.com>
 <IMcYKnGw3L0At9QhNBJrUc61HIsghUQeEY24rhXOhjQ=.a9a12084-329f-4619-ae05-b0af5c7d105f@github.com>
 <GYzemBQG5TFFf_wUxFdersNkjuHumLMyM5hgQx0QE8Q=.b4c93261-0b0d-40d1-9419-2a5cdee3eeec@github.com>
Message-ID: <yiw1snTlUDEuhDu3JFTocZFXmeCvVUOmykBCyUdiG9Q=.8e83408a-7d4b-436b-abb4-aa05e667eb9b@github.com>

On Thu, 23 Mar 2023 12:43:38 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Yes, but while JFR interrupts threads too, its sampler runs in its own thread, so the async-safety of the interrupted code should not matter, or?

You're right.

> wrt info, just a little marker in the thread "AGCT was here", maybe with a timestamp, would be useful.

That sounds like a great idea.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13144#issuecomment-1481133216

From dholmes at openjdk.org  Thu Mar 23 12:48:11 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 23 Mar 2023 12:48:11 GMT
Subject: RFR: 8304725: AsyncGetCallTrace can cause SIGBUS on M1 [v3]
In-Reply-To: <DGciGzZDDGl15JBc93HuQEtwN-KxIPQquyLNJwQS5vM=.a30760eb-2239-4338-8425-33f8938ba514@github.com>
References: <XtBvYsLSljF-NTYtEuYvx35NrdX3-VSu_MmirMCLfKc=.3b4e81e3-d53e-445e-85e4-0fb5e6ded7be@github.com>
 <DGciGzZDDGl15JBc93HuQEtwN-KxIPQquyLNJwQS5vM=.a30760eb-2239-4338-8425-33f8938ba514@github.com>
Message-ID: <SOMfvU4fnrm_i2wlQrWK5iYjNqSeQo6ebXemr3p5Avc=.6e08be7b-39e1-48d0-bf04-037e04bce33a@github.com>

On Thu, 23 Mar 2023 08:20:18 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Fixes the issue by transitioning the thread into the WXWrite mode while walking the stack in AsyncGetCallTrace.
>> 
>> Tested on my M1 mac.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use raw_thread instead of Thread::current()

Correction: I missed some of the discussion above. I see now this AGCT "fix" can break other code, so this makes things much more broken.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13144#issuecomment-1481129143

From stuefe at openjdk.org  Thu Mar 23 12:48:12 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 23 Mar 2023 12:48:12 GMT
Subject: RFR: 8304725: AsyncGetCallTrace can cause SIGBUS on M1 [v3]
In-Reply-To: <IMcYKnGw3L0At9QhNBJrUc61HIsghUQeEY24rhXOhjQ=.a9a12084-329f-4619-ae05-b0af5c7d105f@github.com>
References: <XtBvYsLSljF-NTYtEuYvx35NrdX3-VSu_MmirMCLfKc=.3b4e81e3-d53e-445e-85e4-0fb5e6ded7be@github.com>
 <DGciGzZDDGl15JBc93HuQEtwN-KxIPQquyLNJwQS5vM=.a30760eb-2239-4338-8425-33f8938ba514@github.com>
 <OgU0w04HqaCKlfmq7r_Wkx4kqG1ZU_OdtFHZGigXDuA=.e4518216-9281-4382-b6e7-ae9ae2cf3ebc@github.com>
 <CeRblzP5ogONxw_wnM0SylHEHGQmki58mS93h6640yc=.6b915a4b-afe2-46b9-af65-790ccc44a384@github.com>
 <bvlqS4aFu_U_vk3bVzZBqFy68-NFSC1Ovt7WTwQji7I=.169c08b3-2e92-4d98-bcf6-059691a7e2d8@github.com>
 <IMcYKnGw3L0At9QhNBJrUc61HIsghUQeEY24rhXOhjQ=.a9a12084-329f-4619-ae05-b0af5c7d105f@github.com>
Message-ID: <GYzemBQG5TFFf_wUxFdersNkjuHumLMyM5hgQx0QE8Q=.b4c93261-0b0d-40d1-9419-2a5cdee3eeec@github.com>

On Thu, 23 Mar 2023 12:00:33 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> > In particular, we do not know if AGCT did interrupt the crashing thread recently. Or do we? This would be valuable information.
> 
> Yes. But it could indeed be helpful information when debugging problems. Please don't forget that JFR has a very similar code, and it would be good to have the information on whether JFR sampled a thread recently too.

Yes, but while JFR interrupts threads too, its sampler runs in its own thread, so the async-safety of the interrupted code should not matter, or?

wrt info, just a little marker in the thread "AGCT was here", maybe with a timestamp, would be useful.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13144#issuecomment-1481130844

From fparain at openjdk.org  Thu Mar 23 13:26:24 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 23 Mar 2023 13:26:24 GMT
Subject: RFR: 8304687: Move add_to_hierarchy [v4]
In-Reply-To: <3T0hPcnNGHYDFq8bQUFyppY2hGNbeRBoKMJ2EDaqh-c=.6205cb5e-97e8-4d7e-a619-82646abb19f6@github.com>
References: <8lZkIOj_sW-s5fenIUyqOflXokTscrf8v6Zi6VOic4o=.847bbf8a-430b-46f5-a4c2-335d3355c320@github.com>
 <3T0hPcnNGHYDFq8bQUFyppY2hGNbeRBoKMJ2EDaqh-c=.6205cb5e-97e8-4d7e-a619-82646abb19f6@github.com>
Message-ID: <x-MXZ4z550xDA_NfXKoqUHr7XpcPk3VkxszeTYhjbhA=.6b7305cf-758a-4b40-bd1c-e2c361e7dcbd@github.com>

On Wed, 22 Mar 2023 15:31:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Moved SystemDictionary::add_to_hierarchy to InstanceKlass::add_to_hierarchy where it more logically belongs and next to other functions that also care about dependencies.
>> Tested with tier1-4, and tier1 on linux,windows,macos to check header file changes.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert another include file deletion

LGTM

-------------

Marked as reviewed by fparain (Committer).

PR Review: https://git.openjdk.org/jdk/pull/13129#pullrequestreview-1354621996

From jwilhelm at openjdk.org  Thu Mar 23 13:29:04 2023
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Thu, 23 Mar 2023 13:29:04 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
Message-ID: <N76ViIxWln-6QCOGhYxeRrgQGzKsgqO6jVUZB4P5bZQ=.869d6079-8ea8-4dc3-a3b9-8fe0ae8db86d@github.com>

On Thu, 16 Mar 2023 20:56:15 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>  - Set condition flags correctly after fast-lock call on aarch64

UseNewLocks... Surely there must be a better name? For how long will these be the new locks? Do we rename the flag to UseOldLocks when the next locking scheme comes along?
There must be some property that differentiates these locks from the older locks other than being new. Why not name the flag after that property?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1481191815

From coleenp at openjdk.org  Thu Mar 23 13:50:20 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 23 Mar 2023 13:50:20 GMT
Subject: Integrated: 8304687: Move add_to_hierarchy
In-Reply-To: <8lZkIOj_sW-s5fenIUyqOflXokTscrf8v6Zi6VOic4o=.847bbf8a-430b-46f5-a4c2-335d3355c320@github.com>
References: <8lZkIOj_sW-s5fenIUyqOflXokTscrf8v6Zi6VOic4o=.847bbf8a-430b-46f5-a4c2-335d3355c320@github.com>
Message-ID: <R7VhlgqMAOlxQkSpnYBDI5TpkmqSyH0O9rYqqBx1lOc=.15c83378-5847-45bd-99ae-1aee923b5181@github.com>

On Tue, 21 Mar 2023 21:36:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Moved SystemDictionary::add_to_hierarchy to InstanceKlass::add_to_hierarchy where it more logically belongs and next to other functions that also care about dependencies.
> Tested with tier1-4, and tier1 on linux,windows,macos to check header file changes.

This pull request has now been integrated.

Changeset: bf917ba6
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bf917ba6af9a69859f469a1e8056fbd32396cae4
Stats:     100 lines in 9 files changed: 44 ins; 47 del; 9 mod

8304687: Move add_to_hierarchy

Reviewed-by: dholmes, fparain

-------------

PR: https://git.openjdk.org/jdk/pull/13129

From coleenp at openjdk.org  Thu Mar 23 13:50:17 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 23 Mar 2023 13:50:17 GMT
Subject: RFR: 8304687: Move add_to_hierarchy [v4]
In-Reply-To: <3T0hPcnNGHYDFq8bQUFyppY2hGNbeRBoKMJ2EDaqh-c=.6205cb5e-97e8-4d7e-a619-82646abb19f6@github.com>
References: <8lZkIOj_sW-s5fenIUyqOflXokTscrf8v6Zi6VOic4o=.847bbf8a-430b-46f5-a4c2-335d3355c320@github.com>
 <3T0hPcnNGHYDFq8bQUFyppY2hGNbeRBoKMJ2EDaqh-c=.6205cb5e-97e8-4d7e-a619-82646abb19f6@github.com>
Message-ID: <zRoi3e4h7UadXzzpfjGCj1tyhgCoZ8iukiXQ0tgfQwk=.1e497b60-7d39-4407-8521-118d74bd7350@github.com>

On Wed, 22 Mar 2023 15:31:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Moved SystemDictionary::add_to_hierarchy to InstanceKlass::add_to_hierarchy where it more logically belongs and next to other functions that also care about dependencies.
>> Tested with tier1-4, and tier1 on linux,windows,macos to check header file changes.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert another include file deletion

Thanks David and Fred.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13129#issuecomment-1481223599

From jvernee at openjdk.org  Thu Mar 23 14:16:03 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 23 Mar 2023 14:16:03 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: <QzxKSr0yyGvC-V_dXbvxeywSxyy9sWgsl1mFeukWzIY=.35ba1839-8859-49bf-879c-638f9af58758@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
 <oy4LL8ML2Y3MpKfF0hBwGOKLIaLDfPmpKEWf-v0Mizg=.c7f72545-ce7b-450d-a96a-f9021dc3b9e4@github.com>
 <69SHPBocr-b_789_vAvfpV67J_7ZrNal8SSnAFxugyw=.a971481e-9707-4022-88bd-b80906996cc7@github.com>
 <vFO8K64fvvkg9jyeNelszMVal-uJTW-NYetwQ0oS3cM=.37effa35-d084-41bc-aee3-4ec2d8cf5b60@github.com>
 <yWgrZFrwKiPd5c9G1JUMJfv3xjtl8fYJ-GFr5sPsdwk=.d660f1f6-0d7c-42ce-8fca-9c3309c2a160@github.com>
 <Dnp-mfHydFBZL0PJJxMhG9nYnB4P9MFthqvSmv8IdLY=.4154cc1f-66ea-46c7-a6d3-a4add7e94844@github.com>
 <QzxKSr0yyGvC-V_dXbvxeywSxyy9sWgsl1mFeukWzIY=.35ba1839-8859-49bf-879c-638f9af58758@github.com>
Message-ID: <fyVsvw-Pdq0GxPkP2AdaNkXUtzz0A2MiibYLeCV3pyQ=.d6142df1-4338-4d45-a206-ae4966d293a0@github.com>

On Thu, 23 Mar 2023 10:31:27 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Just did a test with jshell:
>> 
>> 
>> jshell> Linker linker = Linker.nativeLinker();
>> 
>> jshell> MethodHandle handleValue = linker.downcallHandle(FunctionDescriptor.ofVoid(MemoryLayout.structLayout(ValueLayout.JAVA_INT)));
>> handleValue ==> MethodHandle(MemorySegment,MemorySegment)void
>> 
>> jshell> handleValue.invoke(MemorySegment.ofAddress(1), null);
>> |  Exception java.lang.NullPointerException
>> |        at (#5:1)
>> 
>> 
>> So, yes, passing `null` for a "by-value" struct issues NPEs. I also get same exception when calling a method handle which passes a struct by reference:
>> 
>> 
>> jshell> MethodHandle handleRef = linker.downcallHandle(FunctionDescriptor.ofVoid(ValueLayout.ADDRESS));
>> handleRef ==> MethodHandle(MemorySegment,MemorySegment)void
>> 
>> jshell> handleRef.invoke(MemorySegment.ofAddress(1), null);
>> |  Exception java.lang.NullPointerException
>> |        at (#7:1)
>> 
>> 
>> Given what the impl does, to be fair I don't mind the NPE (it seems a good exception to throw if we're passing a raw `null`). But we should document it at such.
>> 
>> It also seems like the first parameter of the downcall has somewhat better checks (but still NPEs):
>> 
>> 
>> jshell> handleRef.invoke(null, MemorySegment.ofAddress(1));
>> |  Exception java.lang.NullPointerException
>> |        at Objects.requireNonNull (Objects.java:233)
>> |        at SharedUtils.checkSymbol (SharedUtils.java:351)
>> |        at (#8:1)
>> 
>> 
>> And:
>> 
>> 
>> jshell> handleRef.invoke(MemorySegment.NULL, MemorySegment.ofAddress(1));
>> |  Exception java.lang.IllegalArgumentException: Symbol is NULL: MemorySegment{ heapBase: Optional.empty address:0 limit: 0 }
>> |        at SharedUtils.checkSymbol (SharedUtils.java:353)
>> |        at (#9:1)
>> 
>> 
>> I think this last case is the _only_ one where IAE is warranted - as the role of the first parameter is special, and we can't tolerate a `MemorySegment::NULL` there. For all other reference parameters, the downcall handle should just check that they are non-null, and throw if so.
>
> The returned method handle will throw an {@link IllegalArgumentException} if the {@link MemorySegment}
> representing the target address of the foreign function is the {@link MemorySegment#NULL} address.
> The returned method handle will additionally throw {@link NullPointerException} if any parameter of type {@link MemorySegment} is {@code null}.

We should also NPE when the passed `SegmentAllocator` for struct returns is `null`, so for the last sentence I think this should say:


The returned method handle will additionally throw {@link NullPointerException} if any argument passed to it is {@code null}.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1146264320

From jcking at openjdk.org  Thu Mar 23 14:40:03 2023
From: jcking at openjdk.org (Justin King)
Date: Thu, 23 Mar 2023 14:40:03 GMT
Subject: RFR: JDK-8304723: Statically allocate global mutexes
In-Reply-To: <gJ1F_hnAxb_ihQhvsUYmW-L78LZPGl-yHDTJ-vpCaf8=.a192c7bf-c167-48e9-a9c0-42e939dad0a2@github.com>
References: <GnX35HIFItX1KV3Zsg5l-zwZVkhP_4Hq5o5ZhtiO57w=.94a86c58-3910-4b52-8c2f-3d6aaf713a06@github.com>
 <dqrnvRS2FRMd9WlY0Y1lkE9OsBv5xlLTxZQOTKYnmxk=.c6f842c3-adb9-4a6f-a786-317b1398ecba@github.com>
 <ITGp6nOcrq2hcnPNgpOUHkMOwhDu9NMdEwPgwKm-EyI=.c14951e3-0333-408f-bbf8-8f058c2a0009@github.com>
 <skYwSC4jAzrCin2w81NxHTghEskLccvCiuOBytcaNjc=.06749e56-835c-4899-9dad-b652474ef318@github.com>
 <gJ1F_hnAxb_ihQhvsUYmW-L78LZPGl-yHDTJ-vpCaf8=.a192c7bf-c167-48e9-a9c0-42e939dad0a2@github.com>
Message-ID: <BXcqDv7-NKFC9u_icoFpdjEjd_ivVeCZoTVbFjP1jSI=.0419de3f-dda3-4fec-ac72-563da12f705d@github.com>

On Thu, 23 Mar 2023 06:34:57 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> I'd be very happy if startup would be fast enough for ~150 fewer mallocs to matter.
> 
> A blank hello world with no args to speak of calls into malloc >10k times. ~150(?) mallocs less are a step in the right direction.

Baby steps. :)

As a compromise I'll shift to keeping the pointers and just use a static storage variable in the `def` macros, as suggested. It accomplishes the goal if not malloc'ing but is not as safe due to the two aforementioned bugs. I'll also add an assert to catch the "created twice" problem. But having the mutex pointer always be nullptr is a different story that cannot be caught with that approach.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13143#issuecomment-1481313074

From jcking at openjdk.org  Thu Mar 23 15:08:53 2023
From: jcking at openjdk.org (Justin King)
Date: Thu, 23 Mar 2023 15:08:53 GMT
Subject: RFR: JDK-8304723: Statically allocate global mutexes [v3]
In-Reply-To: <GnX35HIFItX1KV3Zsg5l-zwZVkhP_4Hq5o5ZhtiO57w=.94a86c58-3910-4b52-8c2f-3d6aaf713a06@github.com>
References: <GnX35HIFItX1KV3Zsg5l-zwZVkhP_4Hq5o5ZhtiO57w=.94a86c58-3910-4b52-8c2f-3d6aaf713a06@github.com>
Message-ID: <hNK8pxTMMBRoSwhBtKXST13OQxegx8wti5rs-LAI-U4=.32d33ba5-4e73-4dc2-90ba-6d2fa4bda6ec@github.com>

> Switch to statically allocate storage for all of Hotspot's global mutexes and monitors. This avoids needing to allocate each one dynamically at startup. These also live for the lifetime of the program, so this reduces any potential memory fragmention in the C heap.

Justin King 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 remote-tracking branch 'upstream/master' into mutexlocker-static
 - Revert back to previous approach
   
   Signed-off-by: Justin King <jcking at google.com>
 - Fix lock being initialized twice and lock never initialized
   
   Signed-off-by: Justin King <jcking at google.com>
 - Avoid dynamically allocating statically defined mutexes and monitors
   
   Signed-off-by: Justin King <jcking at google.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13143/files
  - new: https://git.openjdk.org/jdk/pull/13143/files/54263bd1..f4991df6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13143&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13143&range=01-02

  Stats: 3100 lines in 135 files changed: 1029 ins; 431 del; 1640 mod
  Patch: https://git.openjdk.org/jdk/pull/13143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13143/head:pull/13143

PR: https://git.openjdk.org/jdk/pull/13143

From matsaave at openjdk.org  Thu Mar 23 15:09:48 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 23 Mar 2023 15:09:48 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v11]
In-Reply-To: <HhhXq9Z8u_XlrOHqmG2U6vfS_2BJtR_1z6fxQOIEsH0=.092626f2-f07f-45cf-9133-de7053853630@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <HhhXq9Z8u_XlrOHqmG2U6vfS_2BJtR_1z6fxQOIEsH0=.092626f2-f07f-45cf-9133-de7053853630@github.com>
Message-ID: <Ll_VZUVKDL3mVA1zfKplY1CW0L9zwjcHZtYgr3tVX1A=.cd292b5a-b639-4783-a6a3-47b55d372f5b@github.com>

On Wed, 22 Mar 2023 17:42:35 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
>> 
>> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
>> 
>> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
>> 
>> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
>> 
>> This change supports the following platforms: x86, aarch64, PPC, and RISCV
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improved comment for load-acquire aarch64

src/hotspot/cpu/ppc/templateTable_ppc_64.cpp line 2294:

> 2292: 
> 2293:   __ load_resolved_indy_entry(cache, index);
> 2294:   __ ld_ptr(method, in_bytes(ResolvedIndyEntry::method_offset()), cache);

@reinrich this load needs acquire semantics.

src/hotspot/cpu/ppc/templateTable_ppc_64.cpp line 2308:

> 2306:   // Update registers with resolved info
> 2307:   __ load_resolved_indy_entry(cache, index);
> 2308:   __ ld_ptr(method, in_bytes(ResolvedIndyEntry::method_offset()), cache);

@reinrich same for this one.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12778#discussion_r1146343430
PR Review Comment: https://git.openjdk.org/jdk/pull/12778#discussion_r1146343487

From jcking at openjdk.org  Thu Mar 23 15:13:12 2023
From: jcking at openjdk.org (Justin King)
Date: Thu, 23 Mar 2023 15:13:12 GMT
Subject: RFR: JDK-8304723: Statically allocate global mutexes [v4]
In-Reply-To: <GnX35HIFItX1KV3Zsg5l-zwZVkhP_4Hq5o5ZhtiO57w=.94a86c58-3910-4b52-8c2f-3d6aaf713a06@github.com>
References: <GnX35HIFItX1KV3Zsg5l-zwZVkhP_4Hq5o5ZhtiO57w=.94a86c58-3910-4b52-8c2f-3d6aaf713a06@github.com>
Message-ID: <DYP7kpr72lViPrjfEJkDVtalp3nEY2H_WaDVvTCe5wg=.494d9baa-1ea2-4b18-b17a-1ea5fd9ca2fd@github.com>

> Switch to statically allocate storage for all of Hotspot's global mutexes and monitors. This avoids needing to allocate each one dynamically at startup. These also live for the lifetime of the program, so this reduces any potential memory fragmention in the C heap.

Justin King has updated the pull request incrementally with one additional commit since the last revision:

  Update indentation
  
  Signed-off-by: Justin King <jcking at google.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13143/files
  - new: https://git.openjdk.org/jdk/pull/13143/files/f4991df6..fbf541d7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13143&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13143&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13143/head:pull/13143

PR: https://git.openjdk.org/jdk/pull/13143

From mdoerr at openjdk.org  Thu Mar 23 15:16:33 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 23 Mar 2023 15:16:33 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v11]
In-Reply-To: <Ll_VZUVKDL3mVA1zfKplY1CW0L9zwjcHZtYgr3tVX1A=.cd292b5a-b639-4783-a6a3-47b55d372f5b@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <HhhXq9Z8u_XlrOHqmG2U6vfS_2BJtR_1z6fxQOIEsH0=.092626f2-f07f-45cf-9133-de7053853630@github.com>
 <Ll_VZUVKDL3mVA1zfKplY1CW0L9zwjcHZtYgr3tVX1A=.cd292b5a-b639-4783-a6a3-47b55d372f5b@github.com>
Message-ID: <9dzvGNE-OGaFIhBkLExkMBt8eHekU42iRM7DXKmNnyo=.2ad0584d-3366-4feb-a8ed-da5270712d5c@github.com>

On Thu, 23 Mar 2023 15:06:21 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improved comment for load-acquire aarch64
>
> src/hotspot/cpu/ppc/templateTable_ppc_64.cpp line 2294:
> 
>> 2292: 
>> 2293:   __ load_resolved_indy_entry(cache, index);
>> 2294:   __ ld_ptr(method, in_bytes(ResolvedIndyEntry::method_offset()), cache);
> 
> @reinrich this load needs acquire semantics.

We already have ordering by `isync(); // Order load wrt. succeeding loads.` below.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12778#discussion_r1146353107

From jcking at openjdk.org  Thu Mar 23 15:20:24 2023
From: jcking at openjdk.org (Justin King)
Date: Thu, 23 Mar 2023 15:20:24 GMT
Subject: RFR: JDK-8304723: Statically allocate global mutexes [v4]
In-Reply-To: <DYP7kpr72lViPrjfEJkDVtalp3nEY2H_WaDVvTCe5wg=.494d9baa-1ea2-4b18-b17a-1ea5fd9ca2fd@github.com>
References: <GnX35HIFItX1KV3Zsg5l-zwZVkhP_4Hq5o5ZhtiO57w=.94a86c58-3910-4b52-8c2f-3d6aaf713a06@github.com>
 <DYP7kpr72lViPrjfEJkDVtalp3nEY2H_WaDVvTCe5wg=.494d9baa-1ea2-4b18-b17a-1ea5fd9ca2fd@github.com>
Message-ID: <oFPFRBbOifDaYfFJTJ8dTCI-Lrx-Ndzc1vXkgre4uWU=.5b7d5640-9e81-427b-81ba-b3c147a5244a@github.com>

On Thu, 23 Mar 2023 15:13:12 GMT, Justin King <jcking at openjdk.org> wrote:

>> Switch to statically allocate storage for all of Hotspot's global mutexes and monitors. This avoids needing to allocate each one dynamically at startup. These also live for the lifetime of the program, so this reduces any potential memory fragmention in the C heap.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update indentation
>   
>   Signed-off-by: Justin King <jcking at google.com>

Okay, updated to do the minimally invasive approach. Storage for the mutex/monitors is in a static variable in mutexLocker.cpp. They now `assert` that they are not creating the same mutex/monitor twice, fixing the `Heap_lock` issue. I also consolidated the macro definitions and fixed some padding. Lastly I removed the dual declaration of `tty_lock`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13143#issuecomment-1481384319

From jcking at openjdk.org  Thu Mar 23 15:27:58 2023
From: jcking at openjdk.org (Justin King)
Date: Thu, 23 Mar 2023 15:27:58 GMT
Subject: RFR: JDK-8304723: Statically allocate global mutexes [v5]
In-Reply-To: <GnX35HIFItX1KV3Zsg5l-zwZVkhP_4Hq5o5ZhtiO57w=.94a86c58-3910-4b52-8c2f-3d6aaf713a06@github.com>
References: <GnX35HIFItX1KV3Zsg5l-zwZVkhP_4Hq5o5ZhtiO57w=.94a86c58-3910-4b52-8c2f-3d6aaf713a06@github.com>
Message-ID: <eyn9KksfxgQZ_uwh4rMrnxAP5ksyZcs4iMrmWxc8fyM=.1cfb45cc-97d9-49a2-9ad5-f2023f3d9b4a@github.com>

> Switch to statically allocate storage for all of Hotspot's global mutexes and monitors. This avoids needing to allocate each one dynamically at startup. These also live for the lifetime of the program, so this reduces any potential memory fragmention in the C heap.

Justin King has updated the pull request incrementally with one additional commit since the last revision:

  Move alignas before static
  
  Signed-off-by: Justin King <jcking at google.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13143/files
  - new: https://git.openjdk.org/jdk/pull/13143/files/fbf541d7..7491f771

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13143&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13143&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13143/head:pull/13143

PR: https://git.openjdk.org/jdk/pull/13143

From matsaave at openjdk.org  Thu Mar 23 15:37:27 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 23 Mar 2023 15:37:27 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v12]
In-Reply-To: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
Message-ID: <2STtfSR29CesdgF3zkeMQBqkHjZk32Yqss0NURZDHEI=.f3d8c313-a0f1-4282-b215-59f5a948b2e8@github.com>

> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
> 
> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
> 
> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
> 
> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
> 
> This change supports the following platforms: x86, aarch64, PPC, and RISCV

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  Andrew comments aarch64

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12778/files
  - new: https://git.openjdk.org/jdk/pull/12778/files/a4714f54..546291fc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12778&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12778&range=10-11

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12778.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12778/head:pull/12778

PR: https://git.openjdk.org/jdk/pull/12778

From stuefe at openjdk.org  Thu Mar 23 15:54:05 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 23 Mar 2023 15:54:05 GMT
Subject: RFR: JDK-8304723: Statically allocate global mutexes
In-Reply-To: <BXcqDv7-NKFC9u_icoFpdjEjd_ivVeCZoTVbFjP1jSI=.0419de3f-dda3-4fec-ac72-563da12f705d@github.com>
References: <GnX35HIFItX1KV3Zsg5l-zwZVkhP_4Hq5o5ZhtiO57w=.94a86c58-3910-4b52-8c2f-3d6aaf713a06@github.com>
 <dqrnvRS2FRMd9WlY0Y1lkE9OsBv5xlLTxZQOTKYnmxk=.c6f842c3-adb9-4a6f-a786-317b1398ecba@github.com>
 <ITGp6nOcrq2hcnPNgpOUHkMOwhDu9NMdEwPgwKm-EyI=.c14951e3-0333-408f-bbf8-8f058c2a0009@github.com>
 <skYwSC4jAzrCin2w81NxHTghEskLccvCiuOBytcaNjc=.06749e56-835c-4899-9dad-b652474ef318@github.com>
 <gJ1F_hnAxb_ihQhvsUYmW-L78LZPGl-yHDTJ-vpCaf8=.a192c7bf-c167-48e9-a9c0-42e939dad0a2@github.com>
 <BXcqDv7-NKFC9u_icoFpdjEjd_ivVeCZoTVbFjP1jSI=.0419de3f-dda3-4fec-ac72-563da12f705d@github.com>
Message-ID: <3qqS-qbU-BYZZykjGcvh0ULclW_Iyee5VMXm54SBDNM=.9ca532d1-36eb-4e35-9488-1184012db403@github.com>

On Thu, 23 Mar 2023 14:37:11 GMT, Justin King <jcking at openjdk.org> wrote:

> > I'd be very happy if startup would be fast enough for ~150 fewer mallocs to matter.
> > A blank hello world with no args to speak of calls into malloc >10k times. ~150(?) mallocs less are a step in the right direction.
> 
> Baby steps. :)
> 
> As a compromise I'll shift to keeping the pointers and just use a static storage variable in the `def` macros, as suggested. It accomplishes the goal if not malloc'ing but is not as safe due to the two aforementioned bugs. I'll also add an assert to catch the "created twice" problem. But having the mutex pointer always be nullptr is a different story that cannot be caught with that approach.

The create twice problem is admittedly evil. The nullptr problem not so much, since we will access it anyway and crash right there, or?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13143#issuecomment-1481440808

From jcking at openjdk.org  Thu Mar 23 16:01:05 2023
From: jcking at openjdk.org (Justin King)
Date: Thu, 23 Mar 2023 16:01:05 GMT
Subject: RFR: JDK-8304723: Statically allocate global mutexes
In-Reply-To: <3qqS-qbU-BYZZykjGcvh0ULclW_Iyee5VMXm54SBDNM=.9ca532d1-36eb-4e35-9488-1184012db403@github.com>
References: <GnX35HIFItX1KV3Zsg5l-zwZVkhP_4Hq5o5ZhtiO57w=.94a86c58-3910-4b52-8c2f-3d6aaf713a06@github.com>
 <dqrnvRS2FRMd9WlY0Y1lkE9OsBv5xlLTxZQOTKYnmxk=.c6f842c3-adb9-4a6f-a786-317b1398ecba@github.com>
 <ITGp6nOcrq2hcnPNgpOUHkMOwhDu9NMdEwPgwKm-EyI=.c14951e3-0333-408f-bbf8-8f058c2a0009@github.com>
 <skYwSC4jAzrCin2w81NxHTghEskLccvCiuOBytcaNjc=.06749e56-835c-4899-9dad-b652474ef318@github.com>
 <gJ1F_hnAxb_ihQhvsUYmW-L78LZPGl-yHDTJ-vpCaf8=.a192c7bf-c167-48e9-a9c0-42e939dad0a2@github.com>
 <BXcqDv7-NKFC9u_icoFpdjEjd_ivVeCZoTVbFjP1jSI=.0419de3f-dda3-4fec-ac72-563da12f705d@github.com>
 <3qqS-qbU-BYZZykjGcvh0ULclW_Iyee5VMXm54SBDNM=.9ca532d1-36eb-4e35-9488-1184012db403@github.com>
Message-ID: <VTSUkzOLYAHn721G6wdSrmaEv7gtDU-3aNjPrxA33_Y=.ff019217-1791-4299-ad28-f79147b93290@github.com>

On Thu, 23 Mar 2023 15:51:50 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > > I'd be very happy if startup would be fast enough for ~150 fewer mallocs to matter.
> > > A blank hello world with no args to speak of calls into malloc >10k times. ~150(?) mallocs less are a step in the right direction.
> > 
> > 
> > Baby steps. :)
> > As a compromise I'll shift to keeping the pointers and just use a static storage variable in the `def` macros, as suggested. It accomplishes the goal if not malloc'ing but is not as safe due to the two aforementioned bugs. I'll also add an assert to catch the "created twice" problem. But having the mutex pointer always be nullptr is a different story that cannot be caught with that approach.
> 
> The create twice problem is admittedly evil. The nullptr problem not so much, since we will access it anyway and crash right there, or?

Unfortunately not. It's used with MutexLocker which happily accepts `nullptr` and just doesn't do anything. That is a feature of it. So if you fail to create a mutex, you might not notice and the data being guarded by the mutex is no longer being accessed safely.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13143#issuecomment-1481453676

From rkennke at openjdk.org  Thu Mar 23 16:00:17 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 23 Mar 2023 16:00:17 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <N76ViIxWln-6QCOGhYxeRrgQGzKsgqO6jVUZB4P5bZQ=.869d6079-8ea8-4dc3-a3b9-8fe0ae8db86d@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
 <N76ViIxWln-6QCOGhYxeRrgQGzKsgqO6jVUZB4P5bZQ=.869d6079-8ea8-4dc3-a3b9-8fe0ae8db86d@github.com>
Message-ID: <WXDOfrodnv4Y3a440dFg5dtPZgptUl3w4Zb23NpvcMo=.4b17d9df-cfa2-44e2-ad7a-1e7d3565b8c5@github.com>

On Thu, 23 Mar 2023 13:25:52 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> UseNewLocks... Surely there must be a better name? For how long will these be the new locks? Do we rename the flag to UseOldLocks when the next locking scheme comes along? There must be some property that differentiates these locks from the older locks other than being new. Why not name the flag after that property?

The main difference is that this new approach doesn't overload the object header with a stack-pointer in a racy way. UseNonRacyLocking?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1481450601

From rkennke at openjdk.org  Thu Mar 23 16:10:05 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 23 Mar 2023 16:10:05 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
Message-ID: <Z2FOVpDkuGYCIADokTmXkPyP3dTxNlM8Q-T3Ys3_DvY=.a93d9af4-2112-479e-8c10-8d31965abe40@github.com>

On Thu, 16 Mar 2023 20:56:15 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>  - Set condition flags correctly after fast-lock call on aarch64

> I didn't see a reply to this comment from last week: [#10907 (comment)](https://github.com/openjdk/jdk/pull/10907#issuecomment-1472649263)
> 
> > Another way to look at the option name question is to invert the sense of
> > the option. The old stack-locking code would be enabled by this new
> > UseStackLocking option (which would be on by default for now) and the
> > newer locking code that uses a lock-stack that is embedded in the JavaThread
> > would be the "else" case of the temporary UseStackLocking option.

Right, that would be a possibility. It seems somewhat unnatural to put the old code under the true branch of an experimental option, but unless we come up with a better name, I'd be willing to accept this. It's all temporary anyway (hopefully) and not meant to be used by end-users, really.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1481467564

From dcubed at openjdk.org  Thu Mar 23 16:10:04 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 23 Mar 2023 16:10:04 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
Message-ID: <Q4TShoLKavhON4fNH7i_o5DxBypQaGwBS7eraXKPMn8=.c1ff5b53-38bf-4e3e-84de-33c0a25ac8bc@github.com>

On Thu, 16 Mar 2023 20:56:15 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>  - Set condition flags correctly after fast-lock call on aarch64

I didn't see a reply to this comment from last week:
https://github.com/openjdk/jdk/pull/10907#issuecomment-1472649263

> Another way to look at the option name question is to invert the sense of
> the option. The old stack-locking code would be enabled by this new
> UseStackLocking option (which would be on by default for now) and the
> newer locking code that uses a lock-stack that is embedded in the JavaThread
> would be the "else" case of the temporary UseStackLocking option.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1481462127

From dcubed at openjdk.org  Thu Mar 23 16:17:22 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 23 Mar 2023 16:17:22 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
Message-ID: <VA_2j3JzIQm0iRbXKz-QPGZYRqMWMJzD5NZjibQZkvI=.e777b109-8786-4bd9-b8a8-f39ca99446e5@github.com>

On Thu, 16 Mar 2023 20:56:15 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>  - Set condition flags correctly after fast-lock call on aarch64

Of course, we'll still have the problem that in the comments we talk about
"stack-locking" for the old scheme of using the BasicLock on the JavaThread's
stack and, with this project's comments, we talk about "fast-locking" for the
new scheme of using a stack-lock embedded in the JavaThread. We'll still
need a better name than "fast-locking" in the comments...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1481482032

From kim.barrett at oracle.com  Thu Mar 23 16:24:16 2023
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 23 Mar 2023 16:24:16 +0000
Subject: RFR: JDK-8304723: Statically allocate global mutexes
In-Reply-To: <gJ1F_hnAxb_ihQhvsUYmW-L78LZPGl-yHDTJ-vpCaf8=.a192c7bf-c167-48e9-a9c0-42e939dad0a2@github.com>
References: <GnX35HIFItX1KV3Zsg5l-zwZVkhP_4Hq5o5ZhtiO57w=.94a86c58-3910-4b52-8c2f-3d6aaf713a06@github.com>
 <dqrnvRS2FRMd9WlY0Y1lkE9OsBv5xlLTxZQOTKYnmxk=.c6f842c3-adb9-4a6f-a786-317b1398ecba@github.com>
 <ITGp6nOcrq2hcnPNgpOUHkMOwhDu9NMdEwPgwKm-EyI=.c14951e3-0333-408f-bbf8-8f058c2a0009@github.com>
 <skYwSC4jAzrCin2w81NxHTghEskLccvCiuOBytcaNjc=.06749e56-835c-4899-9dad-b652474ef318@github.com>
 <gJ1F_hnAxb_ihQhvsUYmW-L78LZPGl-yHDTJ-vpCaf8=.a192c7bf-c167-48e9-a9c0-42e939dad0a2@github.com>
Message-ID: <BB2FFFDC-A623-402A-AEB0-206CA4A3B825@oracle.com>

I?ve not looked at this change in any detail, so don?t consider this any kind of review, just a passing comment.

> On Mar 23, 2023, at 2:37 AM, Thomas Stuefe <stuefe at openjdk.org> wrote:
> 
> On Wed, 22 Mar 2023 22:32:59 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>>> On posix, switch from pthread_cond_init to static initialization if possible.
>> 
>> Some platforms have the "wrong" default which is why we don't attempt to use the pthread static initializers. But in general statically initializing our Mutex/Monitor would be very fragile IMO - as discussed in the past.
> 
> Oh, right, there was that. Wonder if that still holds true today. Wasn't that Solaris?
> 
>> 
>> Doing the allocation statically is a different matter. But what does this gain? Is the startup improvement noticeable?
>> 
> 
> I'd be very happy if startup would be fast enough for ~150 fewer mallocs to matter.
> 
> A blank hello world with no args to speak of calls into malloc >10k times. ~150(?) mallocs less are a step in the right direction.

I see no mallocs for the names.  The names come from macro stringizing the associated variable in defl(), so
are string literals.

The names used to be embedded in Mutex (providing some padding around the atomic parts I think), with
the string passed to the constructor strcpy?ed into that embedded buffer, but that was removed by JDK-8264146.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20230323/520b53be/signature.asc>

From kvn at openjdk.org  Thu Mar 23 16:27:33 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 23 Mar 2023 16:27:33 GMT
Subject: RFR: 8231349: Move intrinsic stubs generation to compiler runtime
 initialization code [v4]
In-Reply-To: <dtc9rdiBGUpqQUB9AzWBroeF3ziVODfk0FuPFDgOHqE=.096e99b2-2957-46c7-8c74-ae1d737f220d@github.com>
References: <dtc9rdiBGUpqQUB9AzWBroeF3ziVODfk0FuPFDgOHqE=.096e99b2-2957-46c7-8c74-ae1d737f220d@github.com>
Message-ID: <olXtNFV6P5bBN06Z8hXtCRBsXWnR2yEzdMLvVMpr1VA=.95993cf0-c31a-4b6c-8b59-29ca22b48072@github.com>

> Based on performance data (see graph in RFE) I propose to implement @cl4es suggestion to move intrinsics stubs generation to C2 (and JVMCI) runtime initialization code.
> 
> It has <1% difference from not generated these stubs at all and we will not win on 1 core VMs but it is simpler and safer solution, I think. It also automatically (no need for new code) do not generate these stubs if C2 is not used (-Xint or low TieredStopAt Level.
> 
> On demand stubs generation requires synchronization between threads during application run which may introduce some instability and may be other issues. But it could be beneficial for Interpreter and C1 if we want more intrinsics stubs to be used by C1 and Interpreter (they use CRC32 only now).  I filed separate RFE  [8304422](https://bugs.openjdk.org/browse/JDK-8304422).
> 
> Changes:
>  - Added new platform specific diagnostic flag `-XX:+MoveIntrinsicStubsGen`. It is ON by default if VM is built with C2 or JVMCI compilers except Zero and 32-bit Arm VMs which have no or few intrinsics.
>  - Split `StubGenerator::generate_all()` method into two: `generate_final_stubs()` and `generate_compiler_stubs()`. Moved only C2 (and JVMCI) intrinsic stubs generation to new method.
>  - I renamed methods and stubs buffer sizes according to new code. Now we have 4 separate **named** stubs buffers and corresponding methods: _Initial, Continuation, Compiler, Final_.
>  - I added new UL printing to find new sizes for buffers and adjusted them on `aarch64` and `x86`. On other platforms I used the same as before value for `compiler_stubs` and `final_stubs`:
> 
>> java -Xlog:stubs -XX:+UseCompressedOops -XX:+CheckCompressedOops -XX:+VerifyOops -XX:+VerifyStackAtCalls -version
> [0.006s][info][stubs] StubRoutines (initial stubs)	 [0x00007f94900fcc00, 0x00007f9490101b60] used: 16152, free: 4168
> [0.026s][info][stubs] StubRoutines (continuation stubs)	 [0x00007f9490102580, 0x00007f9490102e90] used: 741, free: 1579
> [0.051s][info][stubs] StubRoutines (final stubs)	 [0x00007f9490155600, 0x00007f949015cc70] used: 26484, free: 3836
> [0.090s][info][stubs] StubRoutines (compiler stubs)	 [0x00007f94904ccc00, 0x00007f94904d9bd0] used: 46988, free: 6212
> java version "21-internal" 2023-09-19 LTS
> 
> -Xlog:stubs=debug will print size information for each stub:
> [0.005s][debug][stubs] ICache::flush_icache_stub [0x00007fb2d3828080, 0x00007fb2d382809d] (29 bytes)
> [0.005s][debug][stubs] VM_Version::get_cpu_info_stub [0x00007fb2d3828380, 0x00007fb2d3828714] (916 bytes)
> [0.005s][debug][stubs] VM_Version::detect_virt_stub [0x00007fb2d3828714, 0x00007fb2d382872e] (26 bytes)
> [0.005s][debug][stubs] StubRoutines::forward exception [0x00007fb2d3828c00, 0x00007fb2d3828c92] (146 bytes)
> 
> 
> Testing: tier1-7, Xcomp, stress on x64 and aarch64.
> 
> I have changes for all platforms. Please test it on platforms you support.

Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Merge master
 - Rename flag
 - Address Claes comments
 - remove trailing white space
 - Copyright year update. Small corrections.
 - 8231349: Move intrinsic stubs generation to compiler runtime initialization code

-------------

Changes: https://git.openjdk.org/jdk/pull/13096/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13096&range=03
  Stats: 720 lines in 38 files changed: 368 ins; 125 del; 227 mod
  Patch: https://git.openjdk.org/jdk/pull/13096.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13096/head:pull/13096

PR: https://git.openjdk.org/jdk/pull/13096

From rkennke at openjdk.org  Thu Mar 23 16:48:30 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 23 Mar 2023 16:48:30 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
Message-ID: <S3HAUfb2-rymMhcE0b5Uwycc6LpZHCnHRVHXL0141IU=.20c872ab-a4c1-4d40-b33b-a83f9f388cd1@github.com>

On Thu, 16 Mar 2023 20:56:15 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>  - Set condition flags correctly after fast-lock call on aarch64

Is anybody familiar with the academic literature on this topic? I am sure I am not the first person which has come up with this form of locking. Maybe we could use a name that refers to some academic paper?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1481512899

From stuefe at openjdk.org  Thu Mar 23 17:18:49 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 23 Mar 2023 17:18:49 GMT
Subject: RFR: JDK-8304815: Use NMT for more precise hs_err location printing
Message-ID: <DPqsrXUm5sJjcxDGZW6QSvdpu83LBhwXreIJU7LXqjI=.dfe3de5e-919a-494d-a8dd-0622d1ee0c65@github.com>

(This is a byproduct of work on the arm port for https://github.com/openjdk/jdk/pull/10907. I needed better debugging information in the hs-err file and in gdb.)

Back in 2022 @zhengyu123 had the very nice idea of using NMT mapping info for smartening up pp in gdb: [JDK-8280289](https://bugs.openjdk.org/browse/JDK-8280289).

The same idea can be applied to hs_err file location printing. NMT has information about all its mappings and can tell us where it thinks a given unknown pointer points into.

This could be even more useful if the "find malloc block" part of that functionality would be smarter. As it is now, it only works if the pointer in question points to the start of a user-allocated area. Would be nice if the code could (carefully) search for the next valid-looking malloc header instead.

--------------

This patch does this: we introduce a new API, MemTracker::print_containing_region(void*), that tries to make sense of a given unknown pointer.

It will search its mmap regions and print those if found. For malloc'ed pointers, it will carefully sniff out the immediate surroundings of the block, trying to find what looks like a valid malloc header. It uses SafeFetch to not trip over unmapped or protected pages. Note that, of course, we may get false recognition positives if it finds something that looks like a valid header. But even that could be useful (e.g. a remnant dead header may indicate we access memory after free).

Looks like this (its arm, so 32-bit pointers):


Register to memory mapping:

->  r0  = 0x728a6ae0 into life malloced block starting at 0x728a6ae0, size 104, tag mtSynchronizer
->  r1  = 0x75b02010 into life malloced block starting at 0x75b02010, size 184, tag mtObjectMonitor
->  r2  = 0x728a6ae0 into life malloced block starting at 0x728a6ae0, size 104, tag mtSynchronizer
    r3  = 0x0 is nullptr
->  r4  = 0x728a6ae0 into life malloced block starting at 0x728a6ae0, size 104, tag mtSynchronizer
    r5  = 0xb6d3bbc8: <offset 0x018f6bc8> in /shared/projects/openjdk/jdk-jdk/output-fastdebug-arm/images/jdk/lib/server/libjvm.so at 0xb5445000
    r6  = 0xffffffff is an unknown value
    r7  = 0x0 is nullptr
    r8  = 0x0000000a is an unknown value
    r9  = 0x728a4308 is a thread
    r10 = 0x0000000b is an unknown value
->  fp  = 0x753fe8cc in mmap'd memory region [0x75380000 - 0x75400000] by Thread Stack
    r12 = 0x0 is nullptr
->  sp  = 0x753fe8b0 in mmap'd memory region [0x75380000 - 0x75400000] by Thread Stack
    lr  = 0xb69bc1d0: <offset 0x015771d0> in /shared/projects/openjdk/jdk-jdk/output-fastdebug-arm/images/jdk/lib/server/libjvm.so at 0xb5445000
    pc  = 0xb69c8670: <offset 0x01583670> in /shared/projects/openjdk/jdk-jdk/output-fastdebug-arm/images/jdk/lib/server/libjvm.so at 0xb5445000



The small caveat here is that NMT reporting needs ThreadCritical, and thus using it for location printing may block error reporting if it crashed inside a ThreadCritical section. We face the same issue today when printing the NMT report as part of the hs-err file. 

I think the usefulness of these printouts justify this risk. However I opened https://bugs.openjdk.org/browse/JDK-8304824 to investigate a better locking strategy for NMT.

-------------

Commit messages:
 - JDK-8304815-Use-NMT-for-more-precise-hs_err-location-printing

Changes: https://git.openjdk.org/jdk/pull/13162/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13162&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304815
  Stats: 198 lines in 11 files changed: 169 ins; 8 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/13162.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13162/head:pull/13162

PR: https://git.openjdk.org/jdk/pull/13162

From jcking at openjdk.org  Thu Mar 23 17:40:00 2023
From: jcking at openjdk.org (Justin King)
Date: Thu, 23 Mar 2023 17:40:00 GMT
Subject: RFR: JDK-8304828: Lots of constant static data not declared static
 const in cpu/x86
Message-ID: <7KzH7QPu53lViaVf5yIBoJ7hxpvBIK9iZP-L5EVH8U4=.0935258a-29ba-43b5-a845-1201be6dface@github.com>

Simple refactor that updates declarations and definitions for data that is effectively static and constant to be `static` and/or `const`. Helps make sure we do not break the one definition rule and helps the compiler/linker to place the data in read-only sections of the executable.

-------------

Commit messages:
 - Make static const data static const

Changes: https://git.openjdk.org/jdk/pull/13163/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13163&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304828
  Stats: 166 lines in 27 files changed: 0 ins; 0 del; 166 mod
  Patch: https://git.openjdk.org/jdk/pull/13163.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13163/head:pull/13163

PR: https://git.openjdk.org/jdk/pull/13163

From kvn at openjdk.org  Thu Mar 23 18:07:20 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 23 Mar 2023 18:07:20 GMT
Subject: RFR: 8304301: Remove the global option SuperWordMaxVectorSize
In-Reply-To: <2XQwCCx_ficJ1bn2WX0Ud9m-QmuGkkZAH8N6yLugXqQ=.90a136da-db9a-49b4-a4c4-d6c644cf7d5a@github.com>
References: <2XQwCCx_ficJ1bn2WX0Ud9m-QmuGkkZAH8N6yLugXqQ=.90a136da-db9a-49b4-a4c4-d6c644cf7d5a@github.com>
Message-ID: <RJRDRqX1tbsKsursGpzq4NrwgLJlSzThipsu36hzbgE=.0d4a4832-f6b3-4d9c-b70e-1b221a99cee0@github.com>

On Tue, 21 Mar 2023 02:26:55 GMT, Fei Gao <fgao at openjdk.org> wrote:

> https://github.com/openjdk/jdk/pull/8877 introduced the global option `SuperWordMaxVectorSize` as a temporary solution to fix the performance regression on some x86 machines.
> 
> Currently, `SuperWordMaxVectorSize` behaves differently between x86 and other platforms [1]. For example, if the current machine only supports `MaxVectorSize <= 32`, but we set `SuperWordMaxVectorSize = 64`, then `SuperWordMaxVectorSize` will be kept at 64 on other platforms while x86 machine would change `SuperWordMaxVectorSize` to `MaxVectorSize`. Other platforms except x86 miss similar implementations like [2].
> 
> Also, `SuperWordMaxVectorSize` limits the max vector size of auto-vectorization as `64`, which is fine for current aarch64 hardware, but SVE architecture supports larger than 512 bits.
> 
> The patch is to drop the global option and use an architecture-dependent interface to consult the max vector size for auto-vectorization, fixing the performance issue on x86 and reducing side effects for other platforms. After the patch, auto-vectorization is still limited to 32-byte vectors by default on Cascade Lake and users can override this by either setting
> `-XX:UseAVX=3` or `-XX:MaxVectorSize=64` on JVM command line.
> 
> So my question is:
> 
> Before the patch, we could have a smaller max vector size for auto-vectorization than `MaxVectorSize` on x86. For example, users could have `MaxVectorSize=64` and `SuperWordMaxVectorSize=32`. But after the change, if we set
> `-XX:MaxVectorSize=64` explicitly, then the max vector size for auto-vectorization would be `MaxVectorSize`, i.e. 64 bytes, which I believe is more reasonable. @sviswa7 @jatin-bhateja, are you happy about the change?
> 
> [1] https://github.com/openjdk/jdk/pull/12350#discussion_r1126106213
> [2] https://github.com/openjdk/jdk/blob/33bec207103acd520eb99afb093cfafa44aecfda/src/hotspot/cpu/x86/vm_version_x86.cpp#L1314-L1333

I finished running specjvm2008 on Cascade Lake. I was first surprise that I got better scores on few sub-benchmarks but after rerunning they were matching. Some kind of instability (TurboBust?, memory channel?). I did use `numactl -m 1 -N 1` on dual socket system I have. Anyway, I would say results are matching as expecting.

@TobiHartmann regression testing passed too.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13112#pullrequestreview-1355258061

From cjplummer at openjdk.org  Thu Mar 23 18:21:28 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 23 Mar 2023 18:21:28 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v5]
In-Reply-To: <27JLa60WeywSMcJj-6KfaQD8RBnwBbAvcc0gecc-3h4=.a2a25b70-9e90-4551-af90-35aed3d57b59@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <27JLa60WeywSMcJj-6KfaQD8RBnwBbAvcc0gecc-3h4=.a2a25b70-9e90-4551-af90-35aed3d57b59@github.com>
Message-ID: <qVfNBfPP6pizIr16-aXD851jbQ8ZNOV7BvH_Yt-jrbo=.d22c7807-c952-4337-ae69-60a8070ad852@github.com>

On Thu, 23 Mar 2023 05:54:29 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The fix is to enable virtual threads support for late binding JVMTI agents.
>> The fix includes:
>> - New function `JvmtiEnvBase::enable_virtual_threads_notify_jvmti()` which does enabling JVMTI VTMS transition notifications in case of agent loaded into running VM. This function executes a VM operation counting VTMS transition bits in all `JavaThread`'s to correctly set the static counter `_VTMS_transition_count` needed for VTMS transition protocol.
>> - New function `JvmtiEnvBase::disable_virtual_threads_notify_jvmti()` which is needed for testing. It is used by the `WhiteBox` API.
>> - New WhiteBox function `WB_SetVirtualThreadsNotifyJvmtiMode(JNIEnv* env, jobject wb, jboolean enable)` needed for testing of this update.
>> - New regression test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
>> 
>> Testing:
>> - New test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
>> - The originally failed tests are expected to pass 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:
> 
>   address review comment: remove unneeded function

src/hotspot/share/prims/jvmtiThreadState.hpp line 101:

> 99:   static void set_VTMS_notify_jvmti_events(bool val) { _VTMS_notify_jvmti_events = val; }
> 100: 
> 101:   static void set_VTMS_transition_count(bool val)    { _VTMS_transition_count = val; }

Why set the count if it is never going to be used?

test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest.java line 38:

> 36:  */
> 37: 
> 38: //import compiler.whitebox.CompilerWhiteBoxTest;

Remove

test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest.java line 68:

> 66:             if (n <= 0) {
> 67:                 n = 1000;
> 68:                 ToggleNotifyJvmtiTest.sleep(1);

It looks like you do this short sleep 1 out of every 1,000,000 iterations. Can you explain why?

test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest.java line 72:

> 70:             if (i > n) {
> 71:                 i = 0;
> 72:                 n = n - 1;

n--

test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest.java line 74:

> 72:                 n = n - 1;
> 73:             }
> 74:             i = i + 1;

i++

test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest.java line 148:

> 146: 
> 147:     static private void setVirtualThreadsNotifyJvmtiMode(int iter, boolean enable) {
> 148:         sleep(5);

Why is this needed?

test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest.java line 157:

> 155: 
> 156:         if (args.length > 0 && args[0].equals("attach")) { // agent loaded into running VM case
> 157:             String arg = args.length == 2 ? args[1] : "";

I don't see any args being passed in other than "attach"? What might `arg` be set to?

test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest.java line 161:

> 159:             vm.loadAgentLibrary(AGENT_LIB, arg);
> 160:         } else {
> 161:             System.loadLibrary(AGENT_LIB);

Why is this needed? Isn't the library already loaded due to it being specified by `-agentlib`?

test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest.java line 171:

> 169:         sleep(20);
> 170: 
> 171:         for (int iter = 0; VirtualThreadStartedCount() < VTHREADS_CNT; iter++) {

The test seems to exit once all the threads are started. I would think you would want it to run for a while after all the threads are started.

test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/libToggleNotifyJvmtiTest.cpp line 32:

> 30: 
> 31: static jvmtiEnv *jvmti;
> 32: static int vthread_started_cnt = 0;

Needs to be volatile?

test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/libToggleNotifyJvmtiTest.cpp line 34:

> 32: static int vthread_started_cnt = 0;
> 33: static jrawMonitorID agent_lock = NULL;
> 34: static bool can_support_vt_enabled = false;

This variable doesn't seem to be needed. You set it `true` later on, but never reference it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1146578471
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1146594032
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1146608558
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1146598256
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1146598429
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1146625993
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1146620881
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1146624531
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1146629460
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1146630461
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1146633746

From dcubed at openjdk.org  Thu Mar 23 18:36:28 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 23 Mar 2023 18:36:28 GMT
Subject: RFR: JDK-8304815: Use NMT for more precise hs_err location
 printing
In-Reply-To: <DPqsrXUm5sJjcxDGZW6QSvdpu83LBhwXreIJU7LXqjI=.dfe3de5e-919a-494d-a8dd-0622d1ee0c65@github.com>
References: <DPqsrXUm5sJjcxDGZW6QSvdpu83LBhwXreIJU7LXqjI=.dfe3de5e-919a-494d-a8dd-0622d1ee0c65@github.com>
Message-ID: <CrodIMIrO9cjrv91xYv42Z0MyKMS70ceMr5R1AlJgrs=.e42f92e5-0663-4f29-a399-b3cb47b8b1a8@github.com>

On Thu, 23 Mar 2023 16:51:52 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> (This is a byproduct of work on the arm port for https://github.com/openjdk/jdk/pull/10907. I needed better debugging information in the hs-err file and in gdb.)
> 
> Back in 2022 @zhengyu123 had the very nice idea of using NMT mapping info for smartening up pp in gdb: [JDK-8280289](https://bugs.openjdk.org/browse/JDK-8280289).
> 
> The same idea can be applied to hs_err file location printing. NMT has information about all its mappings and can tell us where it thinks a given unknown pointer points into.
> 
> This could be even more useful if the "find malloc block" part of that functionality would be smarter. As it is now, it only works if the pointer in question points to the start of a user-allocated area. Would be nice if the code could (carefully) search for the next valid-looking malloc header instead.
> 
> --------------
> 
> This patch does this: we introduce a new API, MemTracker::print_containing_region(void*), that tries to make sense of a given unknown pointer.
> 
> It will search its mmap regions and print those if found. For malloc'ed pointers, it will carefully sniff out the immediate surroundings of the block, trying to find what looks like a valid malloc header. It uses SafeFetch to not trip over unmapped or protected pages. Note that, of course, we may get false recognition positives if it finds something that looks like a valid header. But even that could be useful (e.g. a remnant dead header may indicate we access memory after free).
> 
> Looks like this (its arm, so 32-bit pointers):
> 
> 
> Register to memory mapping:
> 
> ->  r0  = 0x728a6ae0 into life malloced block starting at 0x728a6ae0, size 104, tag mtSynchronizer
> ->  r1  = 0x75b02010 into life malloced block starting at 0x75b02010, size 184, tag mtObjectMonitor
> ->  r2  = 0x728a6ae0 into life malloced block starting at 0x728a6ae0, size 104, tag mtSynchronizer
>     r3  = 0x0 is nullptr
> ->  r4  = 0x728a6ae0 into life malloced block starting at 0x728a6ae0, size 104, tag mtSynchronizer
>     r5  = 0xb6d3bbc8: <offset 0x018f6bc8> in /shared/projects/openjdk/jdk-jdk/output-fastdebug-arm/images/jdk/lib/server/libjvm.so at 0xb5445000
>     r6  = 0xffffffff is an unknown value
>     r7  = 0x0 is nullptr
>     r8  = 0x0000000a is an unknown value
>     r9  = 0x728a4308 is a thread
>     r10 = 0x0000000b is an unknown value
> ->  fp  = 0x753fe8cc in mmap'd memory region [0x75380000 - 0x75400000] by Thread Stack
>     r12 = 0x0 is nullptr
> ->  sp  = 0x753fe8b0 in mmap'd memory region [0x75380000 - 0x75400000] by Thread Stack
>     lr  = 0xb69bc1d0: <offset 0x015771d0> in /shared/projects/openjdk/jdk-jdk/output-fastdebug-arm/images/jdk/lib/server/libjvm.so at 0xb5445000
>     pc  = 0xb69c8670: <offset 0x01583670> in /shared/projects/openjdk/jdk-jdk/output-fastdebug-arm/images/jdk/lib/server/libjvm.so at 0xb5445000
> 
> 
> 
> The small caveat here is that NMT reporting needs ThreadCritical, and thus using it for location printing may block error reporting if it crashed inside a ThreadCritical section. We face the same issue today when printing the NMT report as part of the hs-err file. 
> 
> I think the usefulness of these printouts justify this risk. However I opened https://bugs.openjdk.org/browse/JDK-8304824 to investigate a better locking strategy for NMT.

Should that output be "live malloced block" instead of "life malloced block"?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13162#issuecomment-1481706447

From kvn at openjdk.org  Thu Mar 23 19:19:47 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 23 Mar 2023 19:19:47 GMT
Subject: Integrated: 8231349: Move intrinsic stubs generation to compiler
 runtime initialization code
In-Reply-To: <dtc9rdiBGUpqQUB9AzWBroeF3ziVODfk0FuPFDgOHqE=.096e99b2-2957-46c7-8c74-ae1d737f220d@github.com>
References: <dtc9rdiBGUpqQUB9AzWBroeF3ziVODfk0FuPFDgOHqE=.096e99b2-2957-46c7-8c74-ae1d737f220d@github.com>
Message-ID: <OsjidI3l3LyU1uWN3qqBMvwYdUcZOzB5yIxGrNmOEq8=.0692a477-fc5c-4d51-b147-634a86b44385@github.com>

On Mon, 20 Mar 2023 07:05:23 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Based on performance data (see graph in RFE) I propose to implement @cl4es suggestion to move intrinsics stubs generation to C2 (and JVMCI) runtime initialization code.
> 
> It has <1% difference from not generated these stubs at all and we will not win on 1 core VMs but it is simpler and safer solution, I think. It also automatically (no need for new code) do not generate these stubs if C2 is not used (-Xint or low TieredStopAt Level.
> 
> On demand stubs generation requires synchronization between threads during application run which may introduce some instability and may be other issues. But it could be beneficial for Interpreter and C1 if we want more intrinsics stubs to be used by C1 and Interpreter (they use CRC32 only now).  I filed separate RFE  [8304422](https://bugs.openjdk.org/browse/JDK-8304422).
> 
> Changes:
>  - Added new platform specific diagnostic flag `-XX:+MoveIntrinsicStubsGen`. It is ON by default if VM is built with C2 or JVMCI compilers except Zero and 32-bit Arm VMs which have no or few intrinsics.
>  - Split `StubGenerator::generate_all()` method into two: `generate_final_stubs()` and `generate_compiler_stubs()`. Moved only C2 (and JVMCI) intrinsic stubs generation to new method.
>  - I renamed methods and stubs buffer sizes according to new code. Now we have 4 separate **named** stubs buffers and corresponding methods: _Initial, Continuation, Compiler, Final_.
>  - I added new UL printing to find new sizes for buffers and adjusted them on `aarch64` and `x86`. On other platforms I used the same as before value for `compiler_stubs` and `final_stubs`:
> 
>> java -Xlog:stubs -XX:+UseCompressedOops -XX:+CheckCompressedOops -XX:+VerifyOops -XX:+VerifyStackAtCalls -version
> [0.006s][info][stubs] StubRoutines (initial stubs)	 [0x00007f94900fcc00, 0x00007f9490101b60] used: 16152, free: 4168
> [0.026s][info][stubs] StubRoutines (continuation stubs)	 [0x00007f9490102580, 0x00007f9490102e90] used: 741, free: 1579
> [0.051s][info][stubs] StubRoutines (final stubs)	 [0x00007f9490155600, 0x00007f949015cc70] used: 26484, free: 3836
> [0.090s][info][stubs] StubRoutines (compiler stubs)	 [0x00007f94904ccc00, 0x00007f94904d9bd0] used: 46988, free: 6212
> java version "21-internal" 2023-09-19 LTS
> 
> -Xlog:stubs=debug will print size information for each stub:
> [0.005s][debug][stubs] ICache::flush_icache_stub [0x00007fb2d3828080, 0x00007fb2d382809d] (29 bytes)
> [0.005s][debug][stubs] VM_Version::get_cpu_info_stub [0x00007fb2d3828380, 0x00007fb2d3828714] (916 bytes)
> [0.005s][debug][stubs] VM_Version::detect_virt_stub [0x00007fb2d3828714, 0x00007fb2d382872e] (26 bytes)
> [0.005s][debug][stubs] StubRoutines::forward exception [0x00007fb2d3828c00, 0x00007fb2d3828c92] (146 bytes)
> 
> 
> Testing: tier1-7, Xcomp, stress on x64 and aarch64.
> 
> I have changes for all platforms. Please test it on platforms you support.

This pull request has now been integrated.

Changeset: 3859faf1
Author:    Vladimir Kozlov <kvn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3859faf183c241f124879d6a7264b43a6b42b418
Stats:     720 lines in 38 files changed: 368 ins; 125 del; 227 mod

8231349: Move intrinsic stubs generation to compiler runtime initialization code

Reviewed-by: redestad, vlivanov

-------------

PR: https://git.openjdk.org/jdk/pull/13096

From coleenp at openjdk.org  Thu Mar 23 21:53:33 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 23 Mar 2023 21:53:33 GMT
Subject: RFR: JDK-8304723: Statically allocate global mutexes [v5]
In-Reply-To: <eyn9KksfxgQZ_uwh4rMrnxAP5ksyZcs4iMrmWxc8fyM=.1cfb45cc-97d9-49a2-9ad5-f2023f3d9b4a@github.com>
References: <GnX35HIFItX1KV3Zsg5l-zwZVkhP_4Hq5o5ZhtiO57w=.94a86c58-3910-4b52-8c2f-3d6aaf713a06@github.com>
 <eyn9KksfxgQZ_uwh4rMrnxAP5ksyZcs4iMrmWxc8fyM=.1cfb45cc-97d9-49a2-9ad5-f2023f3d9b4a@github.com>
Message-ID: <nRdCUytQH9Mx-swgauCRexW9oYvXekX5tZFzg3Kq0wE=.42ae3254-d14a-4681-9ee4-6f42ff7a8ef7@github.com>

On Thu, 23 Mar 2023 15:27:58 GMT, Justin King <jcking at openjdk.org> wrote:

>> Switch to statically allocate storage for all of Hotspot's global mutexes and monitors. This avoids needing to allocate each one dynamically at startup. These also live for the lifetime of the program, so this reduces any potential memory fragmention in the C heap.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move alignas before static
>   
>   Signed-off-by: Justin King <jcking at google.com>

Ok, this is tricky but better than the more invasive change before.

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13143#pullrequestreview-1355711977

From ayang at openjdk.org  Thu Mar 23 22:08:57 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 23 Mar 2023 22:08:57 GMT
Subject: RFR: 8304802: After JDK-8297639 the flag G1UsePreventiveGC needs
 to be added to the obsoletion table
In-Reply-To: <InH4JukIq7ToDARFz4yGGan43_mE6Vs0yyNBP9mPtok=.2b624755-d549-4e6e-b297-304480d401d9@github.com>
References: <InH4JukIq7ToDARFz4yGGan43_mE6Vs0yyNBP9mPtok=.2b624755-d549-4e6e-b297-304480d401d9@github.com>
Message-ID: <71zI5ygUdNG2nzysPKlTimFQx2vVij3LJR47i3WAKb8=.34a5f9ab-f4ff-43a7-95d3-d77e93020cbe@github.com>

On Thu, 23 Mar 2023 10:38:04 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change that puts the `G1UsePreventiveGC` into the argument obsoletion table so that the appropriate warning is printed when starting the VM with that option. Functionality has already been removed, and CSR request approved with [JDK-8297639](https://bugs.openjdk.org/browse/JDK-8297639).
> 
> Testing: local compilation, manual testing that the obsoletion warning is printed on the command line.
> 
> Thanks,
>   Thomas

Marked as reviewed by ayang (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13156#pullrequestreview-1355733902

From lmesnik at openjdk.org  Thu Mar 23 22:29:51 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 23 Mar 2023 22:29:51 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v5]
In-Reply-To: <27JLa60WeywSMcJj-6KfaQD8RBnwBbAvcc0gecc-3h4=.a2a25b70-9e90-4551-af90-35aed3d57b59@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <27JLa60WeywSMcJj-6KfaQD8RBnwBbAvcc0gecc-3h4=.a2a25b70-9e90-4551-af90-35aed3d57b59@github.com>
Message-ID: <cidKu3X9LJvpVXA03joOke4E8_k5w9QYrUWkcIZg_ec=.ded16bd1-9d08-49af-86b5-a6758f7c4b47@github.com>

On Thu, 23 Mar 2023 05:54:29 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The fix is to enable virtual threads support for late binding JVMTI agents.
>> The fix includes:
>> - New function `JvmtiEnvBase::enable_virtual_threads_notify_jvmti()` which does enabling JVMTI VTMS transition notifications in case of agent loaded into running VM. This function executes a VM operation counting VTMS transition bits in all `JavaThread`'s to correctly set the static counter `_VTMS_transition_count` needed for VTMS transition protocol.
>> - New function `JvmtiEnvBase::disable_virtual_threads_notify_jvmti()` which is needed for testing. It is used by the `WhiteBox` API.
>> - New WhiteBox function `WB_SetVirtualThreadsNotifyJvmtiMode(JNIEnv* env, jobject wb, jboolean enable)` needed for testing of this update.
>> - New regression test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
>> 
>> Testing:
>> - New test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
>> - The originally failed tests are expected to pass 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:
> 
>   address review comment: remove unneeded function

There are few comments in the code.
Also, I think it would be nice to have a high-level comment about sync of VTMTDisable and lately attached agent. What is set and why VMOp is needed.
BTW why VMOp and not handshake is used?

src/hotspot/share/prims/jvmtiEnvBase.cpp line 1581:

> 1579:     return false;
> 1580:   }
> 1581:   if (JvmtiVTMSTransitionDisabler::VTMS_notify_jvmti_events()) {

shouldn't be
 if (!JvmtiVTMSTransitionDisabler::VTMS_notify_jvmti_events()) {
here?

src/hotspot/share/prims/whitebox.cpp line 2537:

> 2535:   }
> 2536: #endif
> 2537:   return result;

The test never check results, so it might be better to generate fatal error and fail here/throw exception to catch bug earlier?

test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest.java line 82:

> 80:         try {
> 81:             while (!threadReady) {
> 82:                 sleep(1);

Use ToggleNotifyJvmtiTest.sleep(1);?

test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/libToggleNotifyJvmtiTest.cpp line 77:

> 75: 
> 76:     err = jvmti->AddCapabilities(&caps);
> 77:     if (err != JVMTI_ERROR_NONE) {

Can you use check_jvmti_status to ensure that result is not error?

test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/libToggleNotifyJvmtiTest.cpp line 82:

> 80:     }
> 81:     err = jvmti->SetEventNotificationMode(JVMTI_ENABLE, JVMTI_EVENT_VIRTUAL_THREAD_START, NULL);
> 82:     if (err != JVMTI_ERROR_NONE) {

2nd Can you use check_jvmti_status to ensure that result is not error?

test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/libToggleNotifyJvmtiTest.cpp line 89:

> 87:   LOG("Agent init: can_support_virtual_threads capability: %d\n",  caps.can_support_virtual_threads);
> 88: 
> 89:   err = jvmti->SetEventCallbacks(&callbacks, (jint)sizeof(callbacks));

3rd Can you use check_jvmti_status to ensure that result is not error?

-------------

Changes requested by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13133#pullrequestreview-1355740399
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1146929861
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1146934499
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1146936003
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1146938334
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1146938504
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1146938603

From vitaly.provodin at jetbrains.com  Thu Mar 23 23:18:50 2023
From: vitaly.provodin at jetbrains.com (Vitaly Provodin)
Date: Fri, 24 Mar 2023 06:18:50 +0700
Subject: crash logs without stack trace
Message-ID: <14C16303-1377-4968-93C8-B5347ACF806F@jetbrains.com>

Hi all,


We (at JetBrains) became getting crash reports whose logs have no stack trace info except for Problematic frame. But in those reports there are details accessed via registries about some objects.
See the attached example of such crash logs.
It looks like such reports appeared not so long time ago.

Actually we are stuck on reading such crash logs in order to find out crash causes and would appreciate for any clues related to these issues.

Could somebody please shad some light on this?

Thanks in advance
Vitaly

-------------- next part --------------
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000024d4078232a, pid=16392, tid=16156
#
# JRE version: OpenJDK Runtime Environment JBR-17.0.6+1-653.34-jcef (17.0.6+1) (build 17.0.6+1-b653.34)
# Java VM: OpenJDK 64-Bit Server VM JBR-17.0.6+1-653.34-jcef (17.0.6+1-b653.34, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64)
# Problematic frame:
# J 75653 c1 com.intellij.diff.util.DiffRangeUtil.getLines(Ljava/lang/CharSequence;Lcom/intellij/diff/tools/util/text/LineOffsets;II)Ljava/util/List; (150 bytes) @ 0x0000024d4078232a [0x0000024d40781a80+0x00000000000008aa]
#
# No core dump will be written. Minidumps are not enabled by default on client versions of Windows
#
# If you would like to submit a bug report, please visit:
#   https://youtrack.jetbrains.com/issues/JBR
#

---------------  S U M M A R Y ------------

Command Line: exit -Xms128m -Xmx750m -XX:ReservedCodeCacheSize=512m -XX:+UseG1GC -XX:SoftRefLRUPolicyMSPerMB=50 -XX:CICompilerCount=2 -XX:+HeapDumpOnOutOfMemoryError -XX:-OmitStackTraceInFastThrow -XX:+IgnoreUnrecognizedVMOptions -XX:CompileCommand=exclude,com/intellij/openapi/vfs/impl/FilePartNodeRoot,trieDescend -ea -Dsun.io.useCanonCaches=false -Dsun.java2d.metal=true -Djbr.catch.SIGABRT=true -Djdk.http.auth.tunneling.disabledSchemes="" -Djdk.attach.allowAttachSelf=true -Djdk.module.illegalAccess.silent=true -Dkotlinx.coroutines.debug=off -Xmx2048m -Djb.vmOptionsFile=[USER_DIR]\AppData\Roaming\\JetBrains\\WebStorm2022.3\webstorm64.exe.vmoptions -Djava.system.class.loader=com.intellij.util.lang.PathClassLoader -Didea.vendor.name=JetBrains -Didea.paths.selector=WebStorm2022.3 -Djna.boot.library.path=C:\Program Files\JetBrains\WebStorm 2022.3.3/lib/jna/amd64 -Dpty4j.preferred.native.folder=C:\Program Files\JetBrains\WebStorm 2022.3.3/lib/pty4j -Djna.nosys=true -Djna.noclasspath=true -Didea.platform.prefix=WebStorm -Dsplash=true --add-opens=java.base/java.io=ALL-UNNAMED --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.lang.ref=ALL-UNNAMED --add-opens=java.base/java.lang.reflect=ALL-UNNAMED --add-opens=java.base/java.net=ALL-UNNAMED --add-opens=java.base/java.nio=ALL-UNNAMED --add-opens=java.base/java.nio.charset=ALL-UNNAMED --add-opens=java.base/java.text=ALL-UNNAMED --add-opens=java.base/java.time=ALL-UNNAMED --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.util.concurrent=ALL-UNNAMED --add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED --add-opens=java.base/jdk.internal.vm=ALL-UNNAMED --add-opens=java.base/sun.nio.ch=ALL-UNNAMED --add-opens=java.base/sun.nio.fs=ALL-UNNAMED --add-opens=java.base/sun.security.ssl=ALL-UNNAMED --add-opens=java.base/sun.security.util=ALL-UNNAMED --add-opens=java.desktop/java.awt=ALL-UNNAMED --add-opens=java.desktop/java.awt.dnd.peer=ALL-UNNAMED --add-opens=java.desktop/java.awt.event=ALL-UNNAMED --add-opens=java.desktop/java.awt.image=ALL-UNNAMED --add-opens=java.desktop/java.awt.peer=ALL-UNNAMED --add-opens=java.desktop/java.awt.font=ALL-UNNAMED --add-opens=java.desktop/javax.swing=ALL-UNNAMED --add-opens=java.desktop/javax.swing.plaf.basic=ALL-UNNAMED --add-opens=java.desktop/javax.swing.text.html=ALL-UNNAMED --add-opens=java.desktop/sun.awt.datatransfer=ALL-UNNAMED --add-opens=java.desktop/sun.awt.image=ALL-UNNAMED --add-opens=java.desktop/sun.awt.windows=ALL-UNNAMED --add-opens=java.desktop/sun.awt=ALL-UNNAMED --add-opens=java.desktop/sun.font=ALL-UNNAMED --add-opens=java.desktop/sun.java2d=ALL-UNNAMED --add-opens=java.desktop/sun.swing=ALL-UNNAMED --add-opens=jdk.attach/sun.tools.attach=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED --add-opens=jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED --add-opens=jdk.jdi/com.sun.tools.jdi=ALL-UNNAMED -Dide.native.launcher=true -XX:ErrorFile=[USER_DIR]\java_error_in_webstorm64_%p.log -XX:HeapDumpPath=[USER_DIR]\\java_error_in_webstorm64.hprof

Host: Intel(R) Core(TM) i5-9400F CPU @ 2.90GHz, 6 cores, 15G,  Windows 10 , 64 bit Build 19041 (10.0.19041.2546)
Time: Mon Mar 20 11:27:53 2023 Jerusalem Standard Time elapsed time: 1368.283815 seconds (0d 0h 22m 48s)

---------------  T H R E A D  ---------------

Current thread (0x0000024d6dbc0f10):  JavaThread "AWT-EventQueue-0" [_thread_in_Java, id=16156, stack(0x000000f05ec00000,0x000000f05ed00000)]

Stack: [0x000000f05ec00000,0x000000f05ed00000],  sp=0x000000f05ecfc9e0,  free space=1010k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  0x0000024d4078232a


siginfo: EXCEPTION_ACCESS_VIOLATION (0xc0000005), writing address 0x00000000000006e4


Register to memory mapping:

RIP=0x0000024d4078232a is at entry_point+2218 in (nmethod*)0x0000024d40781690
RAX=0x00000000000006e4 is an unknown value
RBX={method} {0x0000024d62211618} 'incrementAndGet' '()I' in 'java/util/concurrent/atomic/AtomicInteger'
RCX=0x00000000d5a35468 is an oop: com.intellij.testFramework.LightVirtualFile 
{0x00000000d5a35468} - klass: 'com/intellij/testFramework/LightVirtualFile'
 - ---- fields (total size 7 words):
 - private volatile 'value' 'Ljava/lang/Object;' @12  a 'com/intellij/util/keyFMap/EmptyFMap'{0x0000000082709328} (82709328)
 - private 'myModStamp' 'J' @16  0 (0 0)
 - private 'myIsWritable' 'Z' @24  false
 - private 'myValid' 'Z' @25  false
 - private 'myFileType' 'Lcom/intellij/openapi/fileTypes/FileType;' @28  NULL (0)
 - private 'myName' 'Ljava/lang/String;' @32  NULL (0)
 - private 'myOriginalFile' 'Lcom/intellij/openapi/vfs/VirtualFile;' @36  NULL (0)
 - private 'myCachedLength' 'J' @40  0 (0 0)
 - private 'myContent' 'Ljava/lang/CharSequence;' @48  NULL (0)
 - private 'myLanguage' 'Lcom/intellij/lang/Language;' @52  NULL (0)
RDX=0x0000000082709328 is an oop: com.intellij.util.keyFMap.EmptyFMap 
{0x0000000082709328} - klass: 'com/intellij/util/keyFMap/EmptyFMap'
 - ---- fields (total size 2 words):
RSP=0x000000f05ecfc9e0 is pointing into the stack for thread: 0x0000024d6dbc0f10
RBP=0x000000f05ecfcb60 is pointing into the stack for thread: 0x0000024d6dbc0f10
RSI=0x00000000d5a35468 is an oop: com.intellij.testFramework.LightVirtualFile 
{0x00000000d5a35468} - klass: 'com/intellij/testFramework/LightVirtualFile'
 - ---- fields (total size 7 words):
 - private volatile 'value' 'Ljava/lang/Object;' @12  a 'com/intellij/util/keyFMap/EmptyFMap'{0x0000000082709328} (82709328)
 - private 'myModStamp' 'J' @16  0 (0 0)
 - private 'myIsWritable' 'Z' @24  false
 - private 'myValid' 'Z' @25  false
 - private 'myFileType' 'Lcom/intellij/openapi/fileTypes/FileType;' @28  NULL (0)
 - private 'myName' 'Ljava/lang/String;' @32  NULL (0)
 - private 'myOriginalFile' 'Lcom/intellij/openapi/vfs/VirtualFile;' @36  NULL (0)
 - private 'myCachedLength' 'J' @40  0 (0 0)
 - private 'myContent' 'Ljava/lang/CharSequence;' @48  NULL (0)
 - private 'myLanguage' 'Lcom/intellij/lang/Language;' @52  NULL (0)
RDI=0x000000000000057d is an unknown value
R8 =0x00000000833d1740 is an oop: java.lang.String 
{0x00000000833d1740} - klass: 'java/lang/String'
 - string: "dummy.sql"
R9 =0x0000000081906868 is an oop: com.intellij.sql.dialects.postgres.PgDialect 
{0x0000000081906868} - klass: 'com/intellij/sql/dialects/postgres/PgDialect'
 - ---- fields (total size 8 words):
 - private volatile 'value' 'Ljava/lang/Object;' @12  a 'com/intellij/util/keyFMap/MapBackedFMap'{0x00000000819068a8} (819068a8)
 - private final 'myBaseLanguage' 'Lcom/intellij/lang/Language;' @16  a 'com/intellij/sql/psi/SqlLanguage'{0x00000000815831b0} (815831b0)
 - private final 'myID' 'Ljava/lang/String;' @20  "PostgreSQL"{0x000000008158a858} (8158a858)
 - private final 'myMimeTypes' '[Ljava/lang/String;' @24  a 'java/lang/String'[0] {0x000000008272d038} (8272d038)
 - private final 'myDialects' 'Ljava/util/List;' @28  a 'com/intellij/util/containers/LockFreeCopyOnWriteArrayList'{0x0000000081906d10} (81906d10)
 - protected final 'myDualEntity' 'Lcom/intellij/sql/dialects/ReservedEntity;' @32  a 'com/intellij/sql/dialects/ReservedEntity'{0x0000000081906d20} (81906d20)
 - private final 'myLock' 'Ljava/lang/Object;' @36  a 'java/lang/Object'{0x0000000081906d40} (81906d40)
 - private final 'myNextValEntity' 'Lcom/intellij/sql/dialects/ReservedEntity;' @40  a 'com/intellij/sql/dialects/ReservedEntity'{0x0000000081906d50} (81906d50)
 - private final 'myCurrValEntity' 'Lcom/intellij/sql/dialects/ReservedEntity;' @44  a 'com/intellij/sql/dialects/ReservedEntity'{0x0000000081906d70} (81906d70)
 - private volatile 'myTypes' 'Ljava/util/Map;' @48  a 'java/util/HashMap'{0x0000000081906d90} (81906d90)
 - private volatile 'myTypeSystem' 'Lcom/intellij/sql/dialects/SqlTypeSystemBase;' @52  a 'com/intellij/sql/dialects/postgres/Pg83TypeSystem'{0x00000000981ec740} (981ec740)
 - private final 'myInstanceData' 'Lcom/intellij/openapi/util/NotNullLazyValue;' @56  a 'com/intellij/openapi/util/NotNullLazyValue$2'{0x0000000081908a90} (81908a90)
 - private final 'myInstanceData' 'Lcom/intellij/openapi/util/NotNullLazyValue;' @60  a 'com/intellij/openapi/util/NotNullLazyValue$2'{0x0000000081909208} (81909208)
R10=0x0000000082709328 is an oop: com.intellij.util.keyFMap.EmptyFMap 
{0x0000000082709328} - klass: 'com/intellij/util/keyFMap/EmptyFMap'
 - ---- fields (total size 2 words):
R11=0x0000024d40881fa0 is at entry_point+32 in (nmethod*)0x0000024d40881d10
R12=0x0 is NULL
R13=0x000000f05ecfcae0 is pointing into the stack for thread: 0x0000024d6dbc0f10
R14=0x000000f05ecfcba0 is pointing into the stack for thread: 0x0000024d6dbc0f10
R15=0x0000024d6dbc0f10 is a thread


Registers:
RAX=0x00000000000006e4, RBX=0x0000024d62211610, RCX=0x00000000d5a35468, RDX=0x0000000082709328
RSP=0x000000f05ecfc9e0, RBP=0x000000f05ecfcb60, RSI=0x00000000d5a35468, RDI=0x000000000000057d
R8 =0x00000000833d1740, R9 =0x0000000081906868, R10=0x0000000082709328, R11=0x0000024d40881fa0
R12=0x0000000000000000, R13=0x000000f05ecfcae0, R14=0x000000f05ecfcba0, R15=0x0000024d6dbc0f10
RIP=0x0000024d4078232a, EFLAGS=0x0000000000010246

Top of Stack: (sp=0x000000f05ecfc9e0)
0x000000f05ecfc9e0:   00000000d5a35468 00000000d5a353a8
0x000000f05ecfc9f0:   00000000d5a35388 00000000d5a353a8
0x000000f05ecfca00:   0000000000000001 00000000d5a35370
0x000000f05ecfca10:   0000000091e9e718 00000000d5a35388
0x000000f05ecfca20:   00000000929da610 00000000d871d2c8
0x000000f05ecfca30:   0000000091e9e718 00007ffc74f6deaf
0x000000f05ecfca40:   00000000d5a352a0 00007ffcd5a35250
0x000000f05ecfca50:   000000f05ecfcc60 0000024d6dbc0f10
0x000000f05ecfca60:   00000000837aec58 0000000090fdd3e8
0x000000f05ecfca70:   000000f05ecfcb30 000000f08bb9b630
0x000000f05ecfca80:   0000000081906868 00000000803d4fe8
0x000000f05ecfca90:   00000000d5a35468 00000000833d1740
0x000000f05ecfcaa0:   000000f05ecfcb60 0000024d3a8fc5ac
0x000000f05ecfcab0:   0000000000000000 0000024da2a70000
0x000000f05ecfcac0:   000000f05ecfcb60 0000024d49d294ec
0x000000f05ecfcad0:   0000000000000058 0000024d49d294ec 

Instructions: (pc=0x0000024d4078232a)
0x0000024d4078222a:   10 01 00 00 01 48 ba a0 a2 2c 62 4d 02 00 00 8b
0x0000024d4078223a:   b2 cc 00 00 00 83 c6 02 89 b2 cc 00 00 00 81 e6
0x0000024d4078224a:   fe ff 1f 00 83 fe 00 0f 84 26 14 00 00 44 89 58
0x0000024d4078225a:   0c e9 1d 00 00 00 49 8b fb 81 c7 80 00 00 00 48
0x0000024d4078226a:   ba f8 de 39 80 00 00 00 00 48 63 ff 8b 54 ba 10
0x0000024d4078227a:   48 8b c2 4c 8b 84 24 b0 00 00 00 48 83 f8 00 75
0x0000024d4078228a:   16 48 bf 00 cb 4d be 4d 02 00 00 80 8f 29 02 00
0x0000024d4078229a:   00 01 e9 e4 00 00 00 8b 53 08 48 c1 e2 03 8b 78
0x0000024d407822aa:   08 48 c1 e7 03 48 8b 92 08 01 00 00 48 3b fa 0f
0x0000024d407822ba:   84 28 00 00 00 8b 4a 14 48 3b 14 0f 0f 84 1b 00
0x0000024d407822ca:   00 00 83 f9 20 0f 85 99 00 00 00 57 52 e8 a4 50
0x0000024d407822da:   69 09 5f 5a 83 fa 00 0f 84 87 00 00 00 48 bf 00
0x0000024d407822ea:   cb 4d be 4d 02 00 00 8b 50 08 48 c1 e2 03 48 3b
0x0000024d407822fa:   97 40 02 00 00 75 0d 48 83 87 48 02 00 00 01 e9
0x0000024d4078230a:   77 00 00 00 48 3b 97 50 02 00 00 75 0d 48 83 87
0x0000024d4078231a:   58 02 00 00 01 e9 61 00 00 00 48 81 bf 40 02 00
0x0000024d4078232a:   00 00 00 00 00 75 17 48 89 97 40 02 00 00 48 c7
0x0000024d4078233a:   87 48 02 00 00 01 00 00 00 e9 3d 00 00 00 48 81
0x0000024d4078234a:   bf 50 02 00 00 00 00 00 00 75 17 48 89 97 50 02
0x0000024d4078235a:   00 00 48 c7 87 58 02 00 00 01 00 00 00 e9 19 00
0x0000024d4078236a:   00 00 eb 17 48 bf 00 cb 4d be 4d 02 00 00 48 83
0x0000024d4078237a:   af 30 02 00 00 01 e9 23 13 00 00 48 8d 53 14 41
0x0000024d4078238a:   0f be 7f 38 83 ff 00 0f 85 1a 13 00 00 4c 8b d0
0x0000024d4078239a:   44 89 12 48 8b fa 48 33 f8 48 c1 ef 14 48 83 ff
0x0000024d407823aa:   00 0f 85 1a 13 00 00 49 3b 00 49 8b d0 48 bf 00
0x0000024d407823ba:   cb 4d be 4d 02 00 00 8b 52 08 48 c1 e2 03 48 3b
0x0000024d407823ca:   97 78 02 00 00 75 0d 48 83 87 80 02 00 00 01 e9
0x0000024d407823da:   66 00 00 00 48 3b 97 88 02 00 00 75 0d 48 83 87
0x0000024d407823ea:   90 02 00 00 01 e9 50 00 00 00 48 81 bf 78 02 00
0x0000024d407823fa:   00 00 00 00 00 75 17 48 89 97 78 02 00 00 48 c7
0x0000024d4078240a:   87 80 02 00 00 01 00 00 00 e9 2c 00 00 00 48 81
0x0000024d4078241a:   bf 88 02 00 00 00 00 00 00 75 17 48 89 97 88 02 


Stack slot to memory mapping:
stack at sp + 0 slots: 0x00000000d5a35468 is an oop: com.intellij.testFramework.LightVirtualFile 
{0x00000000d5a35468} - klass: 'com/intellij/testFramework/LightVirtualFile'
 - ---- fields (total size 7 words):
 - private volatile 'value' 'Ljava/lang/Object;' @12  a 'com/intellij/util/keyFMap/EmptyFMap'{0x0000000082709328} (82709328)
 - private 'myModStamp' 'J' @16  0 (0 0)
 - private 'myIsWritable' 'Z' @24  false
 - private 'myValid' 'Z' @25  false
 - private 'myFileType' 'Lcom/intellij/openapi/fileTypes/FileType;' @28  NULL (0)
 - private 'myName' 'Ljava/lang/String;' @32  NULL (0)
 - private 'myOriginalFile' 'Lcom/intellij/openapi/vfs/VirtualFile;' @36  NULL (0)
 - private 'myCachedLength' 'J' @40  0 (0 0)
 - private 'myContent' 'Ljava/lang/CharSequence;' @48  NULL (0)
 - private 'myLanguage' 'Lcom/intellij/lang/Language;' @52  NULL (0)
stack at sp + 1 slots: 0x00000000d5a353a8 is an oop: com.intellij.util.containers.ConcurrentWeakKeySoftValueHashMap$WeakKey 
{0x00000000d5a353a8} - klass: 'com/intellij/util/containers/ConcurrentWeakKeySoftValueHashMap$WeakKey'
 - ---- fields (total size 5 words):
 - private 'referent' 'Ljava/lang/Object;' @12  a 'com/intellij/database/util/ObjectPath'{0x00000000d5a35370} (d5a35370)
 - volatile 'queue' 'Ljava/lang/ref/ReferenceQueue;' @16  a 'java/lang/ref/ReferenceQueue'{0x0000000091ea9ac8} (91ea9ac8)
 - volatile 'next' 'Ljava/lang/ref/Reference;' @20  NULL (0)
 - private transient 'discovered' 'Ljava/lang/ref/Reference;' @24  NULL (0)
 - private final 'myHash' 'I' @28  -1872135680 (90697a00)
 - private final 'myStrategy' 'Lcom/intellij/util/containers/HashingStrategy;' @32  a 'com/intellij/database/util/ObjectPath$1'{0x0000000091ea5130} (91ea5130)
 - private final 'myValueReference' 'Lcom/intellij/util/containers/ConcurrentWeakKeySoftValueHashMap$ValueReference;' @36  a 'com/intellij/util/containers/ConcurrentWeakKeyWeakValueHashMap$WeakValue'{0x00000000d5a35388} (d5a35388)
stack at sp + 2 slots: 0x00000000d5a35388 is an oop: com.intellij.util.containers.ConcurrentWeakKeyWeakValueHashMap$WeakValue 
{0x00000000d5a35388} - klass: 'com/intellij/util/containers/ConcurrentWeakKeyWeakValueHashMap$WeakValue'
 - ---- fields (total size 4 words):
 - private 'referent' 'Ljava/lang/Object;' @12  a 'com/intellij/database/util/ObjectPath'{0x00000000d5a35370} (d5a35370)
 - volatile 'queue' 'Ljava/lang/ref/ReferenceQueue;' @16  a 'java/lang/ref/ReferenceQueue'{0x0000000091ea9b18} (91ea9b18)
 - volatile 'next' 'Ljava/lang/ref/Reference;' @20  NULL (0)
 - private transient 'discovered' 'Ljava/lang/ref/Reference;' @24  NULL (0)
 - private volatile 'myKeyReference' 'Lcom/intellij/util/containers/ConcurrentWeakKeySoftValueHashMap$KeyReference;' @28  a 'com/intellij/util/containers/ConcurrentWeakKeySoftValueHashMap$WeakKey'{0x00000000d5a353a8} (d5a353a8)
stack at sp + 3 slots: 0x00000000d5a353a8 is an oop: com.intellij.util.containers.ConcurrentWeakKeySoftValueHashMap$WeakKey 
{0x00000000d5a353a8} - klass: 'com/intellij/util/containers/ConcurrentWeakKeySoftValueHashMap$WeakKey'
 - ---- fields (total size 5 words):
 - private 'referent' 'Ljava/lang/Object;' @12  a 'com/intellij/database/util/ObjectPath'{0x00000000d5a35370} (d5a35370)
 - volatile 'queue' 'Ljava/lang/ref/ReferenceQueue;' @16  a 'java/lang/ref/ReferenceQueue'{0x0000000091ea9ac8} (91ea9ac8)
 - volatile 'next' 'Ljava/lang/ref/Reference;' @20  NULL (0)
 - private transient 'discovered' 'Ljava/lang/ref/Reference;' @24  NULL (0)
 - private final 'myHash' 'I' @28  -1872135680 (90697a00)
 - private final 'myStrategy' 'Lcom/intellij/util/containers/HashingStrategy;' @32  a 'com/intellij/database/util/ObjectPath$1'{0x0000000091ea5130} (91ea5130)
 - private final 'myValueReference' 'Lcom/intellij/util/containers/ConcurrentWeakKeySoftValueHashMap$ValueReference;' @36  a 'com/intellij/util/containers/ConcurrentWeakKeyWeakValueHashMap$WeakValue'{0x00000000d5a35388} (d5a35388)
stack at sp + 4 slots: 0x0000000000000001 is an unknown value
stack at sp + 5 slots: 0x00000000d5a35370 is an oop: com.intellij.database.util.ObjectPath 
{0x00000000d5a35370} - klass: 'com/intellij/database/util/ObjectPath'
 - ---- fields (total size 3 words):
 - public final 'name' 'Ljava/lang/String;' @12  "public"{0x00000000929da610} (929da610)
 - public final 'kind' 'Lcom/intellij/database/model/ObjectKind;' @16  a 'com/intellij/database/model/ObjectKind'{0x00000000815812e0} (815812e0)
 - public final 'parent' 'Lcom/intellij/database/util/ObjectPath;' @20  a 'com/intellij/database/util/ObjectPath'{0x000000009297b820} (9297b820)
stack at sp + 6 slots: 0x0000000091e9e718 is an oop: com.intellij.util.containers.ConcurrentWeakKeyWeakValueHashMap 
{0x0000000091e9e718} - klass: 'com/intellij/util/containers/ConcurrentWeakKeyWeakValueHashMap'
 - ---- fields (total size 4 words):
 - private final 'myMap' 'Ljava/util/concurrent/ConcurrentMap;' @12  a 'java/util/concurrent/ConcurrentHashMap'{0x0000000091e9e738} (91e9e738)
 - final 'myKeyQueue' 'Ljava/lang/ref/ReferenceQueue;' @16  a 'java/lang/ref/ReferenceQueue'{0x0000000091ea9ac8} (91ea9ac8)
 - final 'myValueQueue' 'Ljava/lang/ref/ReferenceQueue;' @20  a 'java/lang/ref/ReferenceQueue'{0x0000000091ea9b18} (91ea9b18)
 - final 'myHashingStrategy' 'Lcom/intellij/util/containers/HashingStrategy;' @24  a 'com/intellij/database/util/ObjectPath$1'{0x0000000091ea5130} (91ea5130)
stack at sp + 7 slots: 0x00000000d5a35388 is an oop: com.intellij.util.containers.ConcurrentWeakKeyWeakValueHashMap$WeakValue 
{0x00000000d5a35388} - klass: 'com/intellij/util/containers/ConcurrentWeakKeyWeakValueHashMap$WeakValue'
 - ---- fields (total size 4 words):
 - private 'referent' 'Ljava/lang/Object;' @12  a 'com/intellij/database/util/ObjectPath'{0x00000000d5a35370} (d5a35370)
 - volatile 'queue' 'Ljava/lang/ref/ReferenceQueue;' @16  a 'java/lang/ref/ReferenceQueue'{0x0000000091ea9b18} (91ea9b18)
 - volatile 'next' 'Ljava/lang/ref/Reference;' @20  NULL (0)
 - private transient 'discovered' 'Ljava/lang/ref/Reference;' @24  NULL (0)
 - private volatile 'myKeyReference' 'Lcom/intellij/util/containers/ConcurrentWeakKeySoftValueHashMap$KeyReference;' @28  a 'com/intellij/util/containers/ConcurrentWeakKeySoftValueHashMap$WeakKey'{0x00000000d5a353a8} (d5a353a8)

--------------------------------------------------------------------------------
[Constant Pool (empty)]

--------------------------------------------------------------------------------

[MachCode]
  0x0000024d40781a80: 8984 2400 | 90ff ff55 | 4881 ec20 | 0100 0048 | 8994 24b8 | 0000 004c | 8984 24b0 | 0000 0044 
  0x0000024d40781aa0: 898c 24a8 | 0000 0089 | bc24 ac00 | 0000 48be | 00cb 4dbe | 4d02 0000 | 8b9e cc00 | 0000 83c3 
  0x0000024d40781ac0: 0289 9ecc | 0000 0081 | e3fe 0700 | 0083 fb00 | 0f84 0b1a | 0000 4883 | fa00 48be | 00cb 4dbe 
  0x0000024d40781ae0: 4d02 0000 | 48bb 1001 | 0000 0000 | 0000 0f85 | 0a00 0000 | 48bb 2001 | 0000 0000 | 0000 488b 
  0x0000024d40781b00: 041e 488d | 4001 4889 | 041e 0f85 | 2400 0000 | 48be 00cb | 4dbe 4d02 | 0000 4883 | 8630 0100 
  0x0000024d40781b20: 0001 ba07 | 0000 00e8 | 54fe 5e09 | 448b 8c24 | a800 0000 | 4183 f900 | 48ba 00cb | 4dbe 4d02 
  0x0000024d40781b40: 0000 48be | 5001 0000 | 0000 0000 | 0f8d 0a00 | 0000 48be | 4001 0000 | 0000 0000 | 488b 3c32 
  0x0000024d40781b60: 488d 7f01 | 4889 3c32 | 0f8d 0c00 | 0000 8bbc | 24ac 0000 | 00e9 4101 | 0000 443b | 8c24 ac00 
  0x0000024d40781b80: 0000 48ba | 00cb 4dbe | 4d02 0000 | 48be 7001 | 0000 0000 | 0000 0f8e | 0a00 0000 | 48be 6001 
  0x0000024d40781ba0: 0000 0000 | 0000 488b | 3c32 488d | 7f01 4889 | 3c32 0f8e | 0c00 0000 | 8bbc 24ac | 0000 00e9 
  0x0000024d40781bc0: f700 0000 | 4c8b 8424 | b000 0000 | 493b 0049 | 8bd0 48be | 00cb 4dbe | 4d02 0000 | 8b52 0848 
  0x0000024d40781be0: c1e2 0348 | 3b96 9001 | 0000 750d | 4883 8698 | 0100 0001 | e966 0000 | 0048 3b96 | a001 0000 
  0x0000024d40781c00: 750d 4883 | 86a8 0100 | 0001 e950 | 0000 0048 | 81be 9001 | 0000 0000 | 0000 7517 | 4889 9690 
  0x0000024d40781c20: 0100 0048 | c786 9801 | 0000 0100 | 0000 e92c | 0000 0048 | 81be a001 | 0000 0000 | 0000 7517 
  0x0000024d40781c40: 4889 96a0 | 0100 0048 | c786 a801 | 0000 0100 | 0000 e908 | 0000 0048 | 8386 8001 | 0000 0149 
  0x0000024d40781c60: 8bd0 6666 | 9048 b8a8 | 35b9 0201 | 0000 00e8 | ec4f 0000 | 8bbc 24ac | 0000 003b | f848 ba00 
  0x0000024d40781c80: cb4d be4d | 0200 0048 | beb8 0100 | 0000 0000 | 000f 8e0a | 0000 0048 | bec8 0100 | 0000 0000 
  0x0000024d40781ca0: 0048 8b04 | 3248 8d40 | 0148 8904 | 320f 8e36 | 0f00 0044 | 8b8c 24a8 | 0000 000f | 1f44 0000 
  0x0000024d40781cc0: e951 1800 | 0000 0000 | 0000 4c8b | df49 8b87 | 0801 0000 | 488d 7828 | 493b bf18 | 0100 000f 
  0x0000024d40781ce0: 873b 1800 | 0049 89bf | 0801 0000 | 48c7 0001 | 0000 0048 | 8bca 48c1 | e903 8948 | 0848 33c9 
  0x0000024d40781d00: 8948 0c48 | 33c9 4889 | 4810 4889 | 4818 4889 | 4820 4889 | 8424 c800 | 0000 bb03 | 0000 0048 
  0x0000024d40781d20: baa0 9505 | 0001 0000 | 0048 63db | 488b fb48 | 81fb ffff | ff00 0f87 | f117 0000 | 48be 1700 
  0x0000024d40781d40: 0000 0000 | 0000 488d | 349e 4883 | e6f8 498b | 8708 0100 | 0048 8d34 | 3049 3bb7 | 1801 0000 
  0x0000024d40781d60: 0f87 c717 | 0000 4989 | b708 0100 | 0048 2bf0 | 48c7 0001 | 0000 0048 | 8bca 48c1 | e903 8948 
  0x0000024d40781d80: 0889 580c | 4883 ee10 | 0f84 1a00 | 0000 4885 | f60f 8411 | 0000 0048 | 33db 48c1 | ee03 4889 
  0x0000024d40781da0: 5cf0 0848 | ffce 75f6 | 4889 8424 | c000 0000 | 48ba 00cb | 4dbe 4d02 | 0000 4883 | 82d8 0100 
  0x0000024d40781dc0: 0001 48ba | a8e4 ff6d | 4d02 0000 | 8bb2 cc00 | 0000 83c6 | 0289 b2cc | 0000 0081 | e6fe ff1f 
  0x0000024d40781de0: 0083 fe00 | 0f84 4d17 | 0000 4183 | f980 48ba | a8e4 ff6d | 4d02 0000 | 48be 1001 | 0000 0000 
  0x0000024d40781e00: 0000 0f8c | 0a00 0000 | 48be 2001 | 0000 0000 | 0000 488b | 3c32 488d | 7f01 4889 | 3c32 0f8c 
  0x0000024d40781e20: 3a00 0000 | 4183 f97f | 48ba a8e4 | ff6d 4d02 | 0000 48be | 4001 0000 | 0000 0000 | 0f8e 0a00 
  0x0000024d40781e40: 0000 48be | 3001 0000 | 0000 0000 | 488b 3c32 | 488d 7f01 | 4889 3c32 | 0f8e 0601 | 0000 48ba 
  0x0000024d40781e60: c080 0500 | 0100 0000 | 488b d849 | 8b87 0801 | 0000 488d | 7810 493b | bf18 0100 | 000f 87d5 
  0x0000024d40781e80: 1600 0049 | 89bf 0801 | 0000 48c7 | 0001 0000 | 0048 8bca | 48c1 e903 | 8948 0848 | 33c9 8948 
  0x0000024d40781ea0: 0c48 33c9 | 488b d048 | bea8 e4ff | 6d4d 0200 | 0048 8386 | 5001 0000 | 0148 ba38 | e6ff 6d4d 
  0x0000024d40781ec0: 0200 008b | b2cc 0000 | 0083 c602 | 89b2 cc00 | 0000 81e6 | feff 1f00 | 83fe 000f | 8484 1600 
  0x0000024d40781ee0: 0048 8bd0 | 48be 38e6 | ff6d 4d02 | 0000 4883 | 8610 0100 | 0001 48ba | 7060 376d | 4d02 0000 
  0x0000024d40781f00: 8bb2 cc00 | 0000 83c6 | 0289 b2cc | 0000 0081 | e6fe ff1f | 0083 fe00 | 0f84 6816 | 0000 488b 
  0x0000024d40781f20: d048 be70 | 6037 6d4d | 0200 0048 | 8386 1001 | 0000 0148 | baa0 a22c | 624d 0200 | 008b b2cc 
  0x0000024d40781f40: 0000 0083 | c602 89b2 | cc00 0000 | 81e6 feff | 1f00 83fe | 000f 844c | 1600 0044 | 8948 0ce9 
  0x0000024d40781f60: 1f00 0000 | 488b d841 | 81c1 8000 | 0000 48ba | f8de 3980 | 0000 0000 | 4d63 c942 | 8b54 8a10 
  0x0000024d40781f80: 488b c248 | 83f8 0075 | 1648 be00 | cb4d be4d | 0200 0080 | 8ee1 0100 | 0001 e9e4 | 0000 008b 
  0x0000024d40781fa0: 5308 48c1 | e203 8b70 | 0848 c1e6 | 0348 8b92 | 0801 0000 | 483b f20f | 8428 0000 | 008b 7a14 
  0x0000024d40781fc0: 483b 143e | 0f84 1b00 | 0000 83ff | 200f 8599 | 0000 0056 | 52e8 a653 | 6909 5e5a | 83fa 000f 
  0x0000024d40781fe0: 8487 0000 | 0048 be00 | cb4d be4d | 0200 008b | 5008 48c1 | e203 483b | 96f8 0100 | 0075 0d48 
  0x0000024d40782000: 8386 0002 | 0000 01e9 | 7700 0000 | 483b 9608 | 0200 0075 | 0d48 8386 | 1002 0000 | 01e9 6100 
  0x0000024d40782020: 0000 4881 | bef8 0100 | 0000 0000 | 0075 1748 | 8996 f801 | 0000 48c7 | 8600 0200 | 0001 0000 
  0x0000024d40782040: 00e9 3d00 | 0000 4881 | be08 0200 | 0000 0000 | 0075 1748 | 8996 0802 | 0000 48c7 | 8610 0200 
  0x0000024d40782060: 0001 0000 | 00e9 1900 | 0000 eb17 | 48be 00cb | 4dbe 4d02 | 0000 4883 | aee8 0100 | 0001 e94f 
  0x0000024d40782080: 1500 0048 | 8d53 1041 | 0fbe 7738 | 83fe 000f | 8546 1500 | 004c 8bd0 | 4489 1248 | 8bf2 4833 
  0x0000024d407820a0: f048 c1ee | 1448 83fe | 000f 8546 | 1500 0048 | ba00 cb4d | be4d 0200 | 0048 8382 | 2002 0000 
  0x0000024d407820c0: 0148 baa8 | e4ff 6d4d | 0200 008b | b2cc 0000 | 0083 c602 | 89b2 cc00 | 0000 81e6 | feff 1f00 
  0x0000024d407820e0: 83fe 000f | 8424 1500 | 0041 83fb | 8048 baa8 | e4ff 6d4d | 0200 0048 | be10 0100 | 0000 0000 
  0x0000024d40782100: 000f 8c0a | 0000 0048 | be20 0100 | 0000 0000 | 0048 8b3c | 3248 8d7f | 0148 893c | 320f 8c3a 
  0x0000024d40782120: 0000 0041 | 83fb 7f48 | baa8 e4ff | 6d4d 0200 | 0048 be40 | 0100 0000 | 0000 000f | 8e0a 0000 
  0x0000024d40782140: 0048 be30 | 0100 0000 | 0000 0048 | 8b3c 3248 | 8d7f 0148 | 893c 320f | 8e03 0100 | 0048 bac0 
  0x0000024d40782160: 8005 0001 | 0000 0049 | 8b87 0801 | 0000 488d | 7810 493b | bf18 0100 | 000f 87af | 1400 0049 
  0x0000024d40782180: 89bf 0801 | 0000 48c7 | 0001 0000 | 0048 8bca | 48c1 e903 | 8948 0848 | 33c9 8948 | 0c48 33c9 
  0x0000024d407821a0: 488b d048 | bea8 e4ff | 6d4d 0200 | 0048 8386 | 5001 0000 | 0148 ba38 | e6ff 6d4d | 0200 008b 
  0x0000024d407821c0: b2cc 0000 | 0083 c602 | 89b2 cc00 | 0000 81e6 | feff 1f00 | 83fe 000f | 845e 1400 | 0048 8bd0 
  0x0000024d407821e0: 48be 38e6 | ff6d 4d02 | 0000 4883 | 8610 0100 | 0001 48ba | 7060 376d | 4d02 0000 | 8bb2 cc00 
  0x0000024d40782200: 0000 83c6 | 0289 b2cc | 0000 0081 | e6fe ff1f | 0083 fe00 | 0f84 4214 | 0000 488b | d048 be70 
  0x0000024d40782220: 6037 6d4d | 0200 0048 | 8386 1001 | 0000 0148 | baa0 a22c | 624d 0200 | 008b b2cc | 0000 0083 
  0x0000024d40782240: c602 89b2 | cc00 0000 | 81e6 feff | 1f00 83fe | 000f 8426 | 1400 0044 | 8958 0ce9 | 1d00 0000 
  0x0000024d40782260: 498b fb81 | c780 0000 | 0048 baf8 | de39 8000 | 0000 0048 | 63ff 8b54 | ba10 488b | c24c 8b84 
  0x0000024d40782280: 24b0 0000 | 0048 83f8 | 0075 1648 | bf00 cb4d | be4d 0200 | 0080 8f29 | 0200 0001 | e9e4 0000 
  0x0000024d407822a0: 008b 5308 | 48c1 e203 | 8b78 0848 | c1e7 0348 | 8b92 0801 | 0000 483b | fa0f 8428 | 0000 008b 
  0x0000024d407822c0: 4a14 483b | 140f 0f84 | 1b00 0000 | 83f9 200f | 8599 0000 | 0057 52e8 | a450 6909 | 5f5a 83fa 
  0x0000024d407822e0: 000f 8487 | 0000 0048 | bf00 cb4d | be4d 0200 | 008b 5008 | 48c1 e203 | 483b 9740 | 0200 0075 
  0x0000024d40782300: 0d48 8387 | 4802 0000 | 01e9 7700 | 0000 483b | 9750 0200 | 0075 0d48 | 8387 5802 | 0000 01e9 
  0x0000024d40782320: 6100 0000 | 4881 bf40 | 0200 0000 | 0000 0075 | 1748 8997 | 4002 0000 | 48c7 8748 | 0200 0001 
  0x0000024d40782340: 0000 00e9 | 3d00 0000 | 4881 bf50 | 0200 0000 | 0000 0075 | 1748 8997 | 5002 0000 | 48c7 8758 
  0x0000024d40782360: 0200 0001 | 0000 00e9 | 1900 0000 | eb17 48bf | 00cb 4dbe | 4d02 0000 | 4883 af30 | 0200 0001 
  0x0000024d40782380: e923 1300 | 0048 8d53 | 1441 0fbe | 7f38 83ff | 000f 851a | 1300 004c | 8bd0 4489 | 1248 8bfa 
  0x0000024d407823a0: 4833 f848 | c1ef 1448 | 83ff 000f | 851a 1300 | 0049 3b00 | 498b d048 | bf00 cb4d | be4d 0200 
  0x0000024d407823c0: 008b 5208 | 48c1 e203 | 483b 9778 | 0200 0075 | 0d48 8387 | 8002 0000 | 01e9 6600 | 0000 483b 
  0x0000024d407823e0: 9788 0200 | 0075 0d48 | 8387 9002 | 0000 01e9 | 5000 0000 | 4881 bf78 | 0200 0000 | 0000 0075 
  0x0000024d40782400: 1748 8997 | 7802 0000 | 48c7 8780 | 0200 0001 | 0000 00e9 | 2c00 0000 | 4881 bf88 | 0200 0000 
  0x0000024d40782420: 0000 0075 | 1748 8997 | 8802 0000 | 48c7 8790 | 0200 0001 | 0000 00e9 | 0800 0000 | 4883 8768 
  0x0000024d40782440: 0200 0001 | 498b d066 | 0f1f 4400 | 0048 b8ff | ffff ffff | ffff ffe8 | 24f2 5e09 | 488b d848 
  0x0000024d40782460: ba00 cb4d | be4d 0200 | 0048 8382 | a002 0000 | 0148 baa8 | e4ff 6d4d | 0200 008b | b2cc 0000 
  0x0000024d40782480: 0083 c602 | 89b2 cc00 | 0000 81e6 | feff 1f00 | 83fe 000f | 844f 1200 | 0083 fb80 | 48ba a8e4 
  0x0000024d407824a0: ff6d 4d02 | 0000 48be | 1001 0000 | 0000 0000 | 0f8c 0a00 | 0000 48be | 2001 0000 | 0000 0000 
  0x0000024d407824c0: 488b 3c32 | 488d 7f01 | 4889 3c32 | 0f8c 3900 | 0000 83fb | 7f48 baa8 | e4ff 6d4d | 0200 0048 
  0x0000024d407824e0: be40 0100 | 0000 0000 | 000f 8e0a | 0000 0048 | be30 0100 | 0000 0000 | 0048 8b3c | 3248 8d7f 
  0x0000024d40782500: 0148 893c | 320f 8e02 | 0100 0048 | bac0 8005 | 0001 0000 | 0049 8b87 | 0801 0000 | 488d 7810 
  0x0000024d40782520: 493b bf18 | 0100 000f | 87dc 1100 | 0049 89bf | 0801 0000 | 48c7 0001 | 0000 0048 | 8bca 48c1 
  0x0000024d40782540: e903 8948 | 0848 33c9 | 8948 0c48 | 33c9 488b | d048 bea8 | e4ff 6d4d | 0200 0048 | 8386 5001 
  0x0000024d40782560: 0000 0148 | ba38 e6ff | 6d4d 0200 | 008b b2cc | 0000 0083 | c602 89b2 | cc00 0000 | 81e6 feff 
  0x0000024d40782580: 1f00 83fe | 000f 848b | 1100 0048 | 8bd0 48be | 38e6 ff6d | 4d02 0000 | 4883 8610 | 0100 0001 
  0x0000024d407825a0: 48ba 7060 | 376d 4d02 | 0000 8bb2 | cc00 0000 | 83c6 0289 | b2cc 0000 | 0081 e6fe | ff1f 0083 
  0x0000024d407825c0: fe00 0f84 | 6f11 0000 | 488b d048 | be70 6037 | 6d4d 0200 | 0048 8386 | 1001 0000 | 0148 baa0 
  0x0000024d407825e0: a22c 624d | 0200 008b | b2cc 0000 | 0083 c602 | 89b2 cc00 | 0000 81e6 | feff 1f00 | 83fe 000f 
  0x0000024d40782600: 8453 1100 | 0089 580c | e91a 0000 | 0081 c380 | 0000 0048 | baf8 de39 | 8000 0000 | 0048 63db 
  0x0000024d40782620: 8b54 9a10 | 488b c248 | 8b9c 24c0 | 0000 0048 | 83f8 0075 | 1648 be00 | cb4d be4d | 0200 0080 
  0x0000024d40782640: 8ea9 0200 | 0001 e9e4 | 0000 008b | 5308 48c1 | e203 8b70 | 0848 c1e6 | 0348 8b92 | 0801 0000 
  0x0000024d40782660: 483b f20f | 8428 0000 | 008b 7a14 | 483b 143e | 0f84 1b00 | 0000 83ff | 200f 8599 | 0000 0056 
  0x0000024d40782680: 52e8 fa4c | 6909 5e5a | 83fa 000f | 8487 0000 | 0048 be00 | cb4d be4d | 0200 008b | 5008 48c1 
  0x0000024d407826a0: e203 483b | 96c0 0200 | 0075 0d48 | 8386 c802 | 0000 01e9 | 7700 0000 | 483b 96d0 | 0200 0075 
  0x0000024d407826c0: 0d48 8386 | d802 0000 | 01e9 6100 | 0000 4881 | bec0 0200 | 0000 0000 | 0075 1748 | 8996 c002 
  0x0000024d407826e0: 0000 48c7 | 86c8 0200 | 0001 0000 | 00e9 3d00 | 0000 4881 | bed0 0200 | 0000 0000 | 0075 1748 
  0x0000024d40782700: 8996 d002 | 0000 48c7 | 86d8 0200 | 0001 0000 | 00e9 1900 | 0000 eb17 | 48be 00cb | 4dbe 4d02 
  0x0000024d40782720: 0000 4883 | aeb0 0200 | 0001 e954 | 1000 0048 | 8d53 1841 | 0fbe 7738 | 83fe 000f | 854b 1000 
  0x0000024d40782740: 004c 8bd0 | 4489 1248 | 8bf2 4833 | f048 c1ee | 1448 83fe | 000f 854b | 1000 0048 | ba00 cb4d 
  0x0000024d40782760: be4d 0200 | 0048 8382 | e802 0000 | 0148 bad0 | fa3c 324d | 0200 008b | b2cc 0000 | 0083 c602 
  0x0000024d40782780: 89b2 cc00 | 0000 81e6 | feff 1f00 | 83fe 000f | 8429 1000 | 0048 bac0 | b127 0001 | 0000 0049 
  0x0000024d407827a0: 8b87 0801 | 0000 488d | 7820 493b | bf18 0100 | 000f 8728 | 1000 0049 | 89bf 0801 | 0000 48c7 
  0x0000024d407827c0: 0001 0000 | 0048 8bca | 48c1 e903 | 8948 0848 | 33c9 8948 | 0c48 33c9 | 4889 4810 | 4889 4818 
  0x0000024d407827e0: 488b d048 | bed0 fa3c | 324d 0200 | 0048 8386 | 1001 0000 | 0148 baa8 | fc3c 324d | 0200 008b 
  0x0000024d40782800: b2cc 0000 | 0083 c602 | 89b2 cc00 | 0000 81e6 | feff 1f00 | 83fe 000f | 84cf 0f00 | 0048 baa8 
  0x0000024d40782820: fc3c 324d | 0200 0048 | 8382 1001 | 0000 0148 | ba20 b033 | 8000 0000 | 0048 8984 | 24d0 0000 
  0x0000024d40782840: 0066 0f1f | 4400 00e8 | 34f1 5e09 | 48ba 680f | 0500 0100 | 0000 4889 | 8424 e000 | 0000 498b 
  0x0000024d40782860: 8708 0100 | 0048 8d78 | 1849 3bbf | 1801 0000 | 0f87 970f | 0000 4989 | bf08 0100 | 0048 c700 
  0x0000024d40782880: 0100 0000 | 488b ca48 | c1e9 0389 | 4808 4833 | c989 480c | 4833 c948 | 8948 104c | 8bc0 48ba 
  0x0000024d407828a0: a8fc 3c32 | 4d02 0000 | 4883 8220 | 0100 0001 | 49b8 204c | 4962 4d02 | 0000 418b | 90cc 0000 
  0x0000024d407828c0: 0083 c202 | 4189 90cc | 0000 0081 | e2fe ff1f | 0083 fa00 | 0f84 400f | 0000 4c8b | c048 ba20 
  0x0000024d407828e0: 4c49 624d | 0200 0048 | 8382 1001 | 0000 0141 | b810 0000 | 0048 8bd0 | 4889 8424 | d800 0000 
  0x0000024d40782900: 0f1f 8000 | 0000 00e8 | 74ea 5e09 | 488b 8424 | d000 0000 | 49b8 a8fc | 3c32 4d02 | 0000 4983 
  0x0000024d40782920: 8030 0100 | 0001 49b8 | 5800 3d32 | 4d02 0000 | 458b 88cc | 0000 0041 | 83c1 0245 | 8988 cc00 
  0x0000024d40782940: 0000 4181 | e1fe ff1f | 0041 83f9 | 000f 84e8 | 0e00 0048 | 8b84 24d0 | 0000 0049 | b858 003d 
  0x0000024d40782960: 324d 0200 | 0049 8380 | 1001 0000 | 0149 b8a0 | a22c 624d | 0200 0045 | 8b88 cc00 | 0000 4183 
  0x0000024d40782980: c102 4589 | 88cc 0000 | 0041 81e1 | feff 1f00 | 4183 f900 | 0f84 c20e | 0000 41b8 | feff 0000 
  0x0000024d407829a0: 488b 8424 | d000 0000 | 6644 8940 | 0c45 0fbe | 4738 4183 | f800 0f85 | c10e 0000 | 4c8b 8424 
  0x0000024d407829c0: d800 0000 | 4d8b d044 | 8950 104c | 8bc8 4d33 | c849 c1e9 | 1449 83f9 | 000f 85ba | 0e00 0045 
  0x0000024d407829e0: 0fbe 4738 | 4183 f800 | 0f85 c30e | 0000 4c8b | 8424 e000 | 0000 4d8b | d044 8950 | 144c 8bc8 
  0x0000024d40782a00: 4d33 c849 | c1e9 1449 | 83f9 000f | 85bc 0e00 | 004c 8bc8 | 48bf d0fa | 3c32 4d02 | 0000 4883 
  0x0000024d40782a20: 8720 0100 | 0001 49b9 | b801 3d32 | 4d02 0000 | 418b b9cc | 0000 0083 | c702 4189 | b9cc 0000 
  0x0000024d40782a40: 0081 e7fe | ff1f 0083 | ff00 0f84 | 950e 0000 | 4c8b c848 | bfb8 013d | 324d 0200 | 0048 8387 
  0x0000024d40782a60: 1001 0000 | 0149 b9d0 | 4aee 8b00 | 0000 0048 | 8bbc 24c0 | 0000 0048 | 8bd0 0f1f | 4400 00e8 
  0x0000024d40782a80: fce8 5e09 | 483b 0048 | 8bd0 48be | d0fa 3c32 | 4d02 0000 | 4883 8658 | 0100 0001 | 48ba 300a 
  0x0000024d40782aa0: 3d32 4d02 | 0000 8bb2 | cc00 0000 | 83c6 0289 | b2cc 0000 | 0081 e6fe | ff1f 0083 | fe00 0f84 
  0x0000024d40782ac0: 470e 0000 | 488b d048 | be30 0a3d | 324d 0200 | 0048 8386 | 1001 0000 | 0148 baf0 | 0b3d 324d 
  0x0000024d40782ae0: 0200 008b | b2cc 0000 | 0083 c602 | 89b2 cc00 | 0000 81e6 | feff 1f00 | 83fe 000f | 842b 0e00 
  0x0000024d40782b00: 008b 5010 | 4883 fa00 | 48be f00b | 3d32 4d02 | 0000 48bf | 2001 0000 | 0000 0000 | 0f84 0a00 
  0x0000024d40782b20: 0000 48bf | 1001 0000 | 0000 0000 | 488b 1c3e | 488d 5b01 | 4889 1c3e | 0f84 5309 | 0000 483b 
  0x0000024d40782b40: 0248 8bf2 | 48bf 300a | 3d32 4d02 | 0000 8b76 | 0848 c1e6 | 0348 3bb7 | 5801 0000 | 750d 4883 
  0x0000024d40782b60: 8760 0100 | 0001 e966 | 0000 0048 | 3bb7 6801 | 0000 750d | 4883 8770 | 0100 0001 | e950 0000 
  0x0000024d40782b80: 0048 81bf | 5801 0000 | 0000 0000 | 7517 4889 | b758 0100 | 0048 c787 | 6001 0000 | 0100 0000 
  0x0000024d40782ba0: e92c 0000 | 0048 81bf | 6801 0000 | 0000 0000 | 7517 4889 | b768 0100 | 0048 c787 | 7001 0000 
  0x0000024d40782bc0: 0100 0000 | e908 0000 | 0048 8387 | 4801 0000 | 010f 1f40 | 0048 b8ff | ffff ffff | ffff ffe8 
  0x0000024d40782be0: 9cea 5e09 | e96d 0800 | 004c 8bdf | 448b 8c24 | a800 0000 | 4c8b 8424 | b000 0000 | 48ba 1054 
  0x0000024d40782c00: 0500 0100 | 0000 498b | 8708 0100 | 0048 8d78 | 1849 3bbf | 1801 0000 | 0f87 340d | 0000 4989 
  0x0000024d40782c20: bf08 0100 | 0048 c700 | 0100 0000 | 488b ca48 | c1e9 0389 | 4808 4833 | c989 480c | 4833 c948 
  0x0000024d40782c40: 8948 1048 | 8984 24f0 | 0000 0048 | 8bd0 48be | 00cb 4dbe | 4d02 0000 | 4883 8608 | 0300 0001 
  0x0000024d40782c60: 48ba 2033 | 7862 4d02 | 0000 8bb2 | cc00 0000 | 83c6 0289 | b2cc 0000 | 0081 e6fe | ff1f 0083 
  0x0000024d40782c80: fe00 0f84 | d70c 0000 | 488b d048 | be20 3378 | 624d 0200 | 0048 8386 | 1001 0000 | 0148 ba70 
  0x0000024d40782ca0: 3478 624d | 0200 008b | b2cc 0000 | 0083 c602 | 89b2 cc00 | 0000 81e6 | feff 1f00 | 83fe 000f 
  0x0000024d40782cc0: 84bb 0c00 | 0048 8bd0 | 48be 7034 | 7862 4d02 | 0000 4883 | 8610 0100 | 0001 48ba | 285a 2d62 
  0x0000024d40782ce0: 4d02 0000 | 8bb2 cc00 | 0000 83c6 | 0289 b2cc | 0000 0081 | e6fe ff1f | 0083 fe00 | 0f84 9f0c 
  0x0000024d40782d00: 0000 488b | d048 be28 | 5a2d 624d | 0200 0048 | 8386 1001 | 0000 0148 | baa0 a22c | 624d 0200 
  0x0000024d40782d20: 008b b2cc | 0000 0083 | c602 89b2 | cc00 0000 | 81e6 feff | 1f00 83fe | 000f 8483 | 0c00 0041 
  0x0000024d40782d40: 0fbe 5738 | 83fa 000f | 8596 0c00 | 0049 baa0 | 7f4b 8000 | 0000 0044 | 8950 1448 | baa0 7f4b 
  0x0000024d40782d60: 8000 0000 | 0048 8bf0 | 4833 f248 | c1ee 1448 | 83fe 000f | 8585 0c00 | 000f 1f80 | 0000 0000 
  0x0000024d40782d80: 453b cb48 | be00 cb4d | be4d 0200 | 0048 bf18 | 0300 0000 | 0000 000f | 8d0a 0000 | 0048 bf28 
  0x0000024d40782da0: 0300 0000 | 0000 0048 | 8b1c 3e48 | 8d5b 0148 | 891c 3e0f | 8d6c 0600 | 0049 8bf0 | 48bb 00cb 
  0x0000024d40782dc0: 4dbe 4d02 | 0000 8b76 | 0848 c1e6 | 0348 3bb3 | 4803 0000 | 750d 4883 | 8350 0300 | 0001 e966 
  0x0000024d40782de0: 0000 0048 | 3bb3 5803 | 0000 750d | 4883 8360 | 0300 0001 | e950 0000 | 0048 81bb | 4803 0000 
  0x0000024d40782e00: 0000 0000 | 7517 4889 | b348 0300 | 0048 c783 | 5003 0000 | 0100 0000 | e92c 0000 | 0048 81bb 
  0x0000024d40782e20: 5803 0000 | 0000 0000 | 7517 4889 | b358 0300 | 0048 c783 | 6003 0000 | 0100 0000 | e908 0000 
  0x0000024d40782e40: 0048 8383 | 3803 0000 | 0149 8bf0 | 4d8b c148 | 8bd6 4489 | 8c24 e800 | 0000 6666 | 9048 b8a8 
  0x0000024d40782e60: 35b9 0201 | 0000 00e8 | 546e 21ff | 4c8b 8424 | b000 0000 | 48ba 00cb | 4dbe 4d02 | 0000 458b 
  0x0000024d40782e80: 4008 49c1 | e003 4c3b | 8280 0300 | 0075 0d48 | 8382 8803 | 0000 01e9 | 6600 0000 | 4c3b 8290 
  0x0000024d40782ea0: 0300 0075 | 0d48 8382 | 9803 0000 | 01e9 5000 | 0000 4881 | ba80 0300 | 0000 0000 | 0075 174c 
  0x0000024d40782ec0: 8982 8003 | 0000 48c7 | 8288 0300 | 0001 0000 | 00e9 2c00 | 0000 4881 | ba90 0300 | 0000 0000 
  0x0000024d40782ee0: 0075 174c | 8982 9003 | 0000 48c7 | 8298 0300 | 0001 0000 | 00e9 0800 | 0000 4883 | 8270 0300 
  0x0000024d40782f00: 0001 448b | 8424 e800 | 0000 488b | 9424 b000 | 0000 8984 | 24ec 0000 | 000f 1f40 | 0048 b8a8 
  0x0000024d40782f20: 35b9 0201 | 0000 00e8 | 1476 5bfe | 488b 9424 | b800 0000 | 483b 024c | 8bc2 49b9 | 00cb 4dbe 
  0x0000024d40782f40: 4d02 0000 | 458b 4008 | 49c1 e003 | 4d3b 81b8 | 0300 0075 | 0d49 8381 | c003 0000 | 01e9 6600 
  0x0000024d40782f60: 0000 4d3b | 81c8 0300 | 0075 0d49 | 8381 d003 | 0000 01e9 | 5000 0000 | 4981 b9b8 | 0300 0000 
  0x0000024d40782f80: 0000 0075 | 174d 8981 | b803 0000 | 49c7 81c0 | 0300 0001 | 0000 00e9 | 2c00 0000 | 4981 b9c8 
  0x0000024d40782fa0: 0300 0000 | 0000 0075 | 174d 8981 | c803 0000 | 49c7 81d0 | 0300 0001 | 0000 00e9 | 0800 0000 
  0x0000024d40782fc0: 4983 81a8 | 0300 0001 | 448b 8424 | ec00 0000 | 4c8b c848 | 8bf2 488b | d60f 1f40 | 0048 b850 
  0x0000024d40782fe0: 60cc 0001 | 0000 00e8 | 34df 880b | 483b 0048 | 8bd0 48be | 00cb 4dbe | 4d02 0000 | 8b52 0848 
  0x0000024d40783000: c1e2 0348 | 3b96 f003 | 0000 750d | 4883 86f8 | 0300 0001 | e966 0000 | 0048 3b96 | 0004 0000 
  0x0000024d40783020: 750d 4883 | 8608 0400 | 0001 e950 | 0000 0048 | 81be f003 | 0000 0000 | 0000 7517 | 4889 96f0 
  0x0000024d40783040: 0300 0048 | c786 f803 | 0000 0100 | 0000 e92c | 0000 0048 | 81be 0004 | 0000 0000 | 0000 7517 
  0x0000024d40783060: 4889 9600 | 0400 0048 | c786 0804 | 0000 0100 | 0000 e908 | 0000 0048 | 8386 e003 | 0000 0148 
  0x0000024d40783080: 8bd0 6666 | 9048 b830 | 6d29 0101 | 0000 00e8 | 6c06 f50b | 4c8b 8424 | f000 0000 | 48ba 00cb 
  0x0000024d407830a0: 4dbe 4d02 | 0000 458b | 4008 49c1 | e003 4c3b | 8228 0400 | 0075 0d48 | 8382 3004 | 0000 01e9 
  0x0000024d407830c0: 6600 0000 | 4c3b 8238 | 0400 0075 | 0d48 8382 | 4004 0000 | 01e9 5000 | 0000 4881 | ba28 0400 
  0x0000024d407830e0: 0000 0000 | 0075 174c | 8982 2804 | 0000 48c7 | 8230 0400 | 0001 0000 | 00e9 2c00 | 0000 4881 
  0x0000024d40783100: ba38 0400 | 0000 0000 | 0075 174c | 8982 3804 | 0000 48c7 | 8240 0400 | 0001 0000 | 00e9 0800 
  0x0000024d40783120: 0000 4883 | 8218 0400 | 0001 49b8 | 8076 5e62 | 4d02 0000 | 418b 90cc | 0000 0083 | c202 4189 
  0x0000024d40783140: 90cc 0000 | 0081 e2fe | ff1f 0083 | fa00 0f84 | cc08 0000 | 488b b424 | f000 0000 | 448b 460c 
  0x0000024d40783160: 41ff c044 | 8946 0c44 | 8b46 148b | 7e10 488b | d648 bb80 | 765e 624d | 0200 0048 | 8383 1001 
  0x0000024d40783180: 0000 0148 | ba10 785e | 624d 0200 | 008b 9acc | 0000 0083 | c302 899a | cc00 0000 | 81e3 feff 
  0x0000024d407831a0: 1f00 83fb | 000f 8496 | 0800 0041 | 8b50 0c3b | fa48 ba10 | 785e 624d | 0200 0048 | bb20 0100 
  0x0000024d407831c0: 0000 0000 | 000f 840a | 0000 0048 | bb10 0100 | 0000 0000 | 0048 8b0c | 1a48 8d49 | 0148 890c 
  0x0000024d407831e0: 1a0f 8408 | 0000 0048 | 8bd6 e98f | 0000 0048 | 8984 2400 | 0100 004c | 8bc6 48ba | 1078 5e62 
  0x0000024d40783200: 4d02 0000 | 4883 8230 | 0100 0001 | 49b8 087a | 5e62 4d02 | 0000 418b | 90cc 0000 | 0083 c202 
  0x0000024d40783220: 4189 90cc | 0000 0081 | e2fe ff1f | 0083 fa00 | 0f84 3108 | 0000 4c8b | c648 ba08 | 7a5e 624d 
  0x0000024d40783240: 0200 0048 | 8382 1001 | 0000 014c | 8bc7 41ff | c048 8bd6 | 89bc 24f8 | 0000 000f | 1f40 00e8 
  0x0000024d40783260: 5c64 1d0a | 4c8b c08b | bc24 f800 | 0000 488b | 8424 0001 | 0000 488b | 9424 f000 | 0000 413b 
  0x0000024d40783280: 780c 0f83 | 0a08 0000 | 4883 f800 | 7516 48bb | 1078 5e62 | 4d02 0000 | 808b 6101 | 0000 01e9 
  0x0000024d407832a0: e500 0000 | 418b 7008 | 48c1 e603 | 8b58 0848 | c1e3 0348 | 8bb6 0801 | 0000 483b | de0f 8428 
  0x0000024d407832c0: 0000 008b | 4e14 483b | 340b 0f84 | 1b00 0000 | 83f9 200f | 8599 0000 | 0053 56e8 | a040 6909 
  0x0000024d407832e0: 5b5e 83fe | 000f 8487 | 0000 0048 | bb10 785e | 624d 0200 | 008b 7008 | 48c1 e603 | 483b b378 
  0x0000024d40783300: 0100 0075 | 0d48 8383 | 8001 0000 | 01e9 7700 | 0000 483b | b388 0100 | 0075 0d48 | 8383 9001 
  0x0000024d40783320: 0000 01e9 | 6100 0000 | 4881 bb78 | 0100 0000 | 0000 0075 | 1748 89b3 | 7801 0000 | 48c7 8380 
  0x0000024d40783340: 0100 0001 | 0000 00e9 | 3d00 0000 | 4881 bb88 | 0100 0000 | 0000 0075 | 1748 89b3 | 8801 0000 
  0x0000024d40783360: 48c7 8390 | 0100 0001 | 0000 00e9 | 1900 0000 | eb17 48bb | 1078 5e62 | 4d02 0000 | 4883 ab68 
  0x0000024d40783380: 0100 0001 | e91c 0700 | 0048 63f7 | 4d8d 44b0 | 1041 0fbe | 7738 83fe | 000f 850f | 0700 004c 
  0x0000024d407833a0: 8bd0 4589 | 1049 8bf0 | 4833 f048 | c1ee 1448 | 83fe 000f | 8510 0700 | 00ff c789 | 7a10 448b 
  0x0000024d407833c0: 8c24 e800 | 0000 41ff | c148 b800 | cb4d be4d | 0200 0044 | 8b80 d000 | 0000 4183 | c002 4489 
  0x0000024d407833e0: 80d0 0000 | 0041 81e0 | fe3f 0000 | 4183 f800 | 0f84 eb06 | 0000 4d8b | 9748 0300 | 0041 8502 
  0x0000024d40783400: 48b8 00cb | 4dbe 4d02 | 0000 ff80 | 5004 0000 | 448b 9c24 | ac00 0000 | 4c8b 8424 | b000 0000 
  0x0000024d40783420: e95b f9ff | ff48 8b94 | 24f0 0000 | 0048 b800 | cb4d be4d | 0200 00ff | 8068 0400 | 0048 8bc2 
  0x0000024d40783440: 4881 c420 | 0100 005d | 493b a740 | 0300 000f | 87ad 0600 | 00c3 4c8b | 8424 c800 | 0000 48ba 
  0x0000024d40783460: 00cb 4dbe | 4d02 0000 | 4883 82f8 | 0200 0001 | 4c8b c048 | 8b94 24c8 | 0000 000f | 1f40 00e8 
  0x0000024d40783480: fcde 5e09 | 488b 8424 | c800 0000 | e9cc 0600 | 0048 8984 | 2410 0100 | 000f 1f80 | 0000 0000 
  0x0000024d407834a0: e982 0600 | 0000 0000 | 0000 e982 | 0600 0048 | 8bd0 48bb | f00b 3d32 | 4d02 0000 | 4883 8330 
  0x0000024d407834c0: 0100 0001 | 488b d048 | 8984 2408 | 0100 00e8 | acde 5e09 | 488b 8424 | 0801 0000 | e97c 0600 
  0x0000024d407834e0: 0049 ba58 | 34ef bc4d | 0200 004c | 8954 2408 | 48c7 0424 | ffff ffff | e883 7169 | 09e9 d4e5 
  0x0000024d40783500: ffff e899 | 1469 0948 | ba00 0000 | 0000 0000 | 00b8 000f | 050a e8e5 | 6069 09e9 | a0e7 ffff 
  0x0000024d40783520: 488b d2e8 | 581d 6909 | e9e5 e7ff | ffe8 4e26 | 6909 e971 | e8ff ff49 | bab8 1613 | 624d 0200 
  0x0000024d40783540: 004c 8954 | 2408 48c7 | 0424 ffff | ffff e82d | 7169 09e9 | 92e8 ffff | 488b d2e8 | 201d 6909 
  0x0000024d40783560: e93f e9ff | ff49 ba98 | 1713 624d | 0200 004c | 8954 2408 | 48c7 0424 | ffff ffff | e8ff 7069 
  0x0000024d40783580: 09e9 5be9 | ffff 49ba | 387d 1262 | 4d02 0000 | 4c89 5424 | 0848 c704 | 24ff ffff | ffe8 de70 
  0x0000024d407835a0: 6909 e977 | e9ff ff49 | ba10 0500 | 624d 0200 | 004c 8954 | 2408 48c7 | 0424 ffff | ffff e8bd 
  0x0000024d407835c0: 7069 09e9 | 93e9 ffff | e8d3 1369 | 09e8 ce13 | 6909 4889 | 0424 e8c5 | 3469 098b | 3248 83fe 
  0x0000024d407835e0: 000f 84ae | eaff ff48 | 8934 24e8 | 9076 6909 | e9a0 eaff | ff48 83f8 | 000f 84b0 | eaff ff48 
  0x0000024d40783600: 8914 24e8 | 7879 6909 | e9a2 eaff | ff49 bab8 | 1613 624d | 0200 004c | 8954 2408 | 48c7 0424 
  0x0000024d40783620: ffff ffff | e857 7069 | 09e9 bbea | ffff 488b | d2e8 4a1c | 6909 e965 | ebff ff49 | ba98 1713 
  0x0000024d40783640: 624d 0200 | 004c 8954 | 2408 48c7 | 0424 ffff | ffff e829 | 7069 09e9 | 81eb ffff | 49ba 387d 
  0x0000024d40783660: 1262 4d02 | 0000 4c89 | 5424 0848 | c704 24ff | ffff ffe8 | 0870 6909 | e99d ebff | ff49 ba10 
  0x0000024d40783680: 0500 624d | 0200 004c | 8954 2408 | 48c7 0424 | ffff ffff | e8e7 6f69 | 09e9 b9eb | ffff e8fd 
  0x0000024d407836a0: 1269 09e8 | f812 6909 | 4889 0424 | e8ef 3369 | 098b 3a48 | 83ff 000f | 84da ecff | ff48 893c 
  0x0000024d407836c0: 24e8 ba75 | 6909 e9cc | ecff ff48 | 83f8 000f | 84dc ecff | ff48 8914 | 24e8 a278 | 6909 e9ce 
  0x0000024d407836e0: ecff ffe8 | b812 6909 | 49ba b816 | 1362 4d02 | 0000 4c89 | 5424 0848 | c704 24ff | ffff ffe8 
  0x0000024d40783700: 7c6f 6909 | e990 edff | ff48 8bd2 | e86f 1b69 | 09e9 38ee | ffff 49ba | 9817 1362 | 4d02 0000 
  0x0000024d40783720: 4c89 5424 | 0848 c704 | 24ff ffff | ffe8 4e6f | 6909 e954 | eeff ff49 | ba38 7d12 | 624d 0200 
  0x0000024d40783740: 004c 8954 | 2408 48c7 | 0424 ffff | ffff e82d | 6f69 09e9 | 70ee ffff | 49ba 1005 | 0062 4d02 
  0x0000024d40783760: 0000 4c89 | 5424 0848 | c704 24ff | ffff ffe8 | 0c6f 6909 | e98c eeff | ffe8 2212 | 6909 e81d 
  0x0000024d40783780: 1269 0948 | 8904 24e8 | 1433 6909 | 8b32 4883 | fe00 0f84 | a9ef ffff | 4889 3424 | e8df 7469 
  0x0000024d407837a0: 09e9 9bef | ffff 4883 | f800 0f84 | abef ffff | 4889 1424 | e8c7 7769 | 09e9 9def | ffff 49ba 
  0x0000024d407837c0: c0e8 0062 | 4d02 0000 | 4c89 5424 | 0848 c704 | 24ff ffff | ffe8 a66e | 6909 e9b6 | efff ff48 
  0x0000024d407837e0: 8bd2 e899 | 1a69 09e9 | f4ef ffff | 49ba 2048 | 3a6e 4d02 | 0000 4c89 | 5424 0848 | c704 24ff 
  0x0000024d40783800: ffff ffe8 | 786e 6909 | e910 f0ff | ff48 8bd2 | e86b 1a69 | 09e9 81f0 | ffff 49ba | 28ed 0b62 
  0x0000024d40783820: 4d02 0000 | 4c89 5424 | 0848 c704 | 24ff ffff | ffe8 4a6e | 6909 e99f | f0ff ff49 | ba68 463a 
  0x0000024d40783840: 6e4d 0200 | 004c 8954 | 2408 48c7 | 0424 ffff | ffff e829 | 6e69 09e9 | f7f0 ffff | 49ba 1005 
  0x0000024d40783860: 0062 4d02 | 0000 4c89 | 5424 0848 | c704 24ff | ffff ffe8 | 086e 6909 | e91d f1ff | ff44 8b40 
  0x0000024d40783880: 1049 83f8 | 000f 8431 | f1ff ff4c | 8904 24e8 | ec73 6909 | e923 f1ff | ff49 83f8 | 000f 843c 
  0x0000024d407838a0: f1ff ff48 | 8904 24e8 | d476 6909 | e92e f1ff | ff44 8b40 | 1449 83f8 | 000f 842f | f1ff ff4c 
  0x0000024d407838c0: 8904 24e8 | b873 6909 | e921 f1ff | ff49 83f8 | 000f 843a | f1ff ff48 | 8904 24e8 | a076 6909 
  0x0000024d407838e0: e92c f1ff | ff49 ba70 | 5d3a 6e4d | 0200 004c | 8954 2408 | 48c7 0424 | ffff ffff | e87f 6d69 
  0x0000024d40783900: 09e9 4af1 | ffff e895 | 1069 0949 | ba20 593a | 6e4d 0200 | 004c 8954 | 2408 48c7 | 0424 ffff 
  0x0000024d40783920: ffff e859 | 6d69 09e9 | 98f1 ffff | 49ba f05b | 3a6e 4d02 | 0000 4c89 | 5424 0848 | c704 24ff 
  0x0000024d40783940: ffff ffe8 | 386d 6909 | e9b4 f1ff | ffe8 4e10 | 6909 488b | d2e8 2619 | 6909 e9e4 | f2ff ff49 
  0x0000024d40783960: ba50 a510 | 624d 0200 | 004c 8954 | 2408 48c7 | 0424 ffff | ffff e805 | 6d69 09e9 | 08f3 ffff 
  0x0000024d40783980: 49ba d8ea | 1062 4d02 | 0000 4c89 | 5424 0848 | c704 24ff | ffff ffe8 | e46c 6909 | e924 f3ff 
  0x0000024d407839a0: ff49 ba48 | 0411 624d | 0200 004c | 8954 2408 | 48c7 0424 | ffff ffff | e8c3 6c69 | 09e9 40f3 
  0x0000024d407839c0: ffff 49ba | 1005 0062 | 4d02 0000 | 4c89 5424 | 0848 c704 | 24ff ffff | ffe8 a26c | 6909 e95c 
  0x0000024d407839e0: f3ff ff8b | 5014 4883 | fa00 0f84 | 5df3 ffff | 4889 1424 | e887 7269 | 09e9 4ff3 | ffff 4883 
  0x0000024d40783a00: fa00 0f84 | 71f3 ffff | 4889 0424 | e86f 7569 | 09e9 63f3 | ffff e885 | 0f69 09e8 | 800f 6909 
  0x0000024d40783a20: 49ba 08b8 | 1062 4d02 | 0000 4c89 | 5424 0848 | c704 24ff | ffff ffe8 | 446c 6909 | e913 f7ff 
  0x0000024d40783a40: ff49 ba30 | b710 624d | 0200 004c | 8954 2408 | 48c7 0424 | ffff ffff | e823 6c69 | 09e9 49f7 
  0x0000024d40783a60: ffff e839 | 0f69 0949 | baf8 a910 | 624d 0200 | 004c 8954 | 2408 48c7 | 0424 ffff | ffff e8fd 
  0x0000024d40783a80: 6b69 09e9 | aef7 ffff | e813 0f69 | 09e8 0e0f | 6909 4889 | 3c24 4c89 | 4424 08e8 | 0006 6909 
  0x0000024d40783aa0: e8fb 0e69 | 0948 8904 | 24e8 f22f | 6909 418b | 3048 83fe | 000f 84e4 | f8ff ff48 | 8934 24e8 
  0x0000024d40783ac0: bc71 6909 | e9d6 f8ff | ff48 83f8 | 000f 84e6 | f8ff ff4c | 8904 24e8 | a474 6909 | e9d8 f8ff 
  0x0000024d40783ae0: ff49 ba58 | 34ef bc4d | 0200 004c | 8954 2408 | 48c7 0424 | 8700 0000 | e883 6b69 | 09e9 f4f8 
  0x0000024d40783b00: ffff 49ba | 4834 7840 | 4d02 0000 | 4d89 9758 | 0300 00e9 | e83e 5f09 | 48ba 0000 | 0000 0000 
  0x0000024d40783b20: 0000 b800 | 0f05 0ae8 | d45a 6909 | e96f f9ff | ff48 8bd2 | e847 1469 | 09e9 71f9 | ffff 9090 
  0x0000024d40783b40: 498b 87d0 | 0300 0049 | c787 d003 | 0000 0000 | 0000 49c7 | 87d8 0300 | 0000 0000 | 0048 81c4 
  0x0000024d40783b60: 2001 0000 | 5de9 962e | 6009 f4f4 | f4f4 f4f4 | f4f4 f4f4 | f4f4 f4f4 | f4f4 f4f4 | f4f4 f4f4 
  0x0000024d40783b80: 0f1f 4400 | 0048 bb00 | 0000 0000 | 0000 00e9 | fbff ffff | 9048 bb00 | 0000 0000 | 0000 00e9 
  0x0000024d40783ba0: fbff ffff | 9048 bb00 | 0000 0000 | 0000 00e9 | fbff ffff | 9048 bb00 | 0000 0000 | 0000 00e9 
  0x0000024d40783bc0: fbff ffff | 9048 bb00 | 0000 0000 | 0000 00e9 | fbff ffff | 9048 bb00 | 0000 0000 | 0000 00e9 
  0x0000024d40783be0: fbff ffff | 9048 bb00 | 0000 0000 | 0000 00e9 | fbff ffff | 9048 bb00 | 0000 0000 | 0000 00e9 
  0x0000024d40783c00: fbff ffff | 9048 bb00 | 0000 0000 | 0000 00e9 | fbff ffff | 9048 bb00 | 0000 0000 | 0000 00e9 
  0x0000024d40783c20: fbff ffff | 9048 bb00 | 0000 0000 | 0000 00e9 | fbff ffff | 9048 bb00 | 0000 0000 | 0000 00e9 
  0x0000024d40783c40: fbff ffff | 9048 bb00 | 0000 0000 | 0000 00e9 | fbff ffff | 9048 bb00 | 0000 0000 | 0000 00e9 
  0x0000024d40783c60: fbff ffff | e817 2b69 | 0948 b908 | 7a5d 75fc | 7f00 0048 | 83e4 f049 | ba10 7c25 | 75fc 7f00 
  0x0000024d40783c80: 0041 ffd2 | f449 ba85 | 3c78 404d | 0200 0041 | 52e9 0a30 | 5f09 f4f4 
[/MachCode]
--------------------------------------------------------------------------------


---------------  P R O C E S S  ---------------

Threads class SMR info:
_java_thread_list=0x0000024d9ffce100, length=91, elements={
0x0000024d367efb20, 0x0000024d61f36010, 0x0000024d61f00830, 0x0000024d62836400,
0x0000024d62836e20, 0x0000024d6282a7e0, 0x0000024d6282b930, 0x0000024d62830360,
0x0000024d628315a0, 0x0000024d6283d170, 0x0000024d629b4260, 0x0000024d629e3760,
0x0000024d629e4240, 0x0000024d6d4df000, 0x0000024d62b16d50, 0x0000024d6d5bf480,
0x0000024d6dad6200, 0x0000024d6dad4520, 0x0000024d6dad7070, 0x0000024d6dbc4da0,
0x0000024d6dbc5270, 0x0000024d6dbc5740, 0x0000024d6dbc65b0, 0x0000024d6dbc0f10,
0x0000024d6dbc4400, 0x0000024d6dbc2720, 0x0000024d6dbc48d0, 0x0000024d8605abd0,
0x0000024d86056870, 0x0000024d8605b570, 0x0000024d860563a0, 0x0000024d86059d60,
0x0000024d8fb3e3f0, 0x0000024d8fb3d580, 0x0000024d8fb3c240, 0x0000024d8fb3df20,
0x0000024d8fb3b8a0, 0x0000024d9be880c0, 0x0000024d6dad8880, 0x0000024d6dad7540,
0x0000024d6dad6ba0, 0x0000024d9be8c420, 0x0000024d9be8b0e0, 0x0000024d9be898d0,
0x0000024d9be8a270, 0x0000024d9be85570, 0x0000024d62b176f0, 0x0000024d62b16880,
0x0000024d62b17bc0, 0x0000024d62b18090, 0x0000024d62b18560, 0x0000024d6d5b9440,
0x0000024d6d5bbf90, 0x0000024d6d5bc460, 0x0000024d6dbbed60, 0x0000024d6dbc2bf0,
0x0000024d86058550, 0x0000024d9be8bf50, 0x0000024d6dbc3a60, 0x0000024d9c6080f0,
0x0000024d9c6085c0, 0x0000024d6d5bfe20, 0x0000024d6dada560, 0x0000024dacade080,
0x0000024dacae28b0, 0x0000024db3963550, 0x0000024db3963ef0, 0x0000024db3965230,
0x0000024db39613a0, 0x0000024db3965700, 0x0000024db3966570, 0x0000024db3961870,
0x0000024db3965bd0, 0x0000024db39660a0, 0x0000024db3968bf0, 0x0000024db39690c0,
0x0000024db3969590, 0x0000024db3961d40, 0x0000024db396d8f0, 0x0000024db396a8d0,
0x0000024db396ca80, 0x0000024db396d420, 0x0000024db396ddc0, 0x0000024db39673e0,
0x0000024db396a400, 0x0000024dacadf3c0, 0x0000024dacae0700, 0x0000024dacae0230,
0x0000024dacae23e0, 0x0000024db39626e0, 0x0000024d6dbc3590
}

Java Threads: ( => current thread )
  0x0000024d367efb20 JavaThread "main" [_thread_blocked, id=13128, stack(0x000000f057c90000,0x000000f057d90000)]
  0x0000024d61f36010 JavaThread "Reference Handler" daemon [_thread_blocked, id=13740, stack(0x000000f058900000,0x000000f058a00000)]
  0x0000024d61f00830 JavaThread "Finalizer" daemon [_thread_blocked, id=11700, stack(0x000000f058a00000,0x000000f058b00000)]
  0x0000024d62836400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=6480, stack(0x000000f058b00000,0x000000f058c00000)]
  0x0000024d62836e20 JavaThread "Attach Listener" daemon [_thread_blocked, id=13916, stack(0x000000f058c00000,0x000000f058d00000)]
  0x0000024d6282a7e0 JavaThread "Service Thread" daemon [_thread_blocked, id=16216, stack(0x000000f058d00000,0x000000f058e00000)]
  0x0000024d6282b930 JavaThread "Monitor Deflation Thread" daemon [_thread_blocked, id=17924, stack(0x000000f058e00000,0x000000f058f00000)]
  0x0000024d62830360 JavaThread "C2 CompilerThread0" daemon [_thread_blocked, id=17928, stack(0x000000f058f00000,0x000000f059000000)]
  0x0000024d628315a0 JavaThread "C1 CompilerThread0" daemon [_thread_blocked, id=16892, stack(0x000000f059000000,0x000000f059100000)]
  0x0000024d6283d170 JavaThread "Sweeper thread" daemon [_thread_blocked, id=17320, stack(0x000000f059100000,0x000000f059200000)]
  0x0000024d629b4260 JavaThread "Common-Cleaner" daemon [_thread_blocked, id=17068, stack(0x000000f059200000,0x000000f059300000)]
  0x0000024d629e3760 JavaThread "Notification Thread" daemon [_thread_blocked, id=10016, stack(0x000000f059300000,0x000000f059400000)]
  0x0000024d629e4240 JavaThread "WinLauncher external command processing thread" [_thread_in_native, id=16004, stack(0x000000f059500000,0x000000f059600000)]
  0x0000024d6d4df000 JavaThread "DefaultDispatcher-worker-6" daemon [_thread_blocked, id=17964, stack(0x000000f059b00000,0x000000f059c00000)]
  0x0000024d62b16d50 JavaThread "Coroutines Debugger Cleaner" daemon [_thread_blocked, id=1840, stack(0x000000f05a400000,0x000000f05a500000)]
  0x0000024d6d5bf480 JavaThread "DefaultDispatcher-worker-3" daemon [_thread_blocked, id=3504, stack(0x000000f05ac00000,0x000000f05ad00000)]
  0x0000024d6dad6200 JavaThread "DefaultDispatcher-worker-5" daemon [_thread_blocked, id=5988, stack(0x000000f05cd00000,0x000000f05ce00000)]
  0x0000024d6dad4520 JavaThread "DefaultDispatcher-worker-2" daemon [_thread_blocked, id=18076, stack(0x000000f05ce00000,0x000000f05cf00000)]
  0x0000024d6dad7070 JavaThread "Java2D Disposer" daemon [_thread_blocked, id=15740, stack(0x000000f05e300000,0x000000f05e400000)]
  0x0000024d6dbc4da0 JavaThread "AWT-Shutdown" [_thread_blocked, id=15804, stack(0x000000f05e400000,0x000000f05e500000)]
  0x0000024d6dbc5270 JavaThread "AWT-Windows" daemon [_thread_blocked, id=15744, stack(0x000000f05e500000,0x000000f05e600000)]
  0x0000024d6dbc5740 JavaThread "Periodic tasks thread" daemon [_thread_blocked, id=16204, stack(0x000000f05e900000,0x000000f05ea00000)]
  0x0000024d6dbc65b0 JavaThread "JNA Cleaner" daemon [_thread_blocked, id=16128, stack(0x000000f05eb00000,0x000000f05ec00000)]
=>0x0000024d6dbc0f10 JavaThread "AWT-EventQueue-0" [_thread_in_Java, id=16156, stack(0x000000f05ec00000,0x000000f05ed00000)]
  0x0000024d6dbc4400 JavaThread "Netty Builtin Server 1" daemon [_thread_in_native, id=15544, stack(0x000000f05ed00000,0x000000f05ee00000)]
  0x0000024d6dbc2720 JavaThread "Netty Builtin Server 2" daemon [_thread_in_native, id=15668, stack(0x000000f05f100000,0x000000f05f200000)]
  0x0000024d6dbc48d0 JavaThread "kotlinx.coroutines.DefaultExecutor" daemon [_thread_blocked, id=16324, stack(0x000000f05f200000,0x000000f05f300000)]
  0x0000024d8605abd0 JavaThread "TimerQueue" daemon [_thread_blocked, id=15796, stack(0x000000f05f600000,0x000000f05f700000)]
  0x0000024d86056870 JavaThread "fsnotifier.exe" [_thread_in_native, id=17900, stack(0x000000f05f700000,0x000000f05f800000)]
  0x0000024d8605b570 JavaThread "BaseDataReader: output stream of fsnotifier.exe" [_thread_in_native, id=6776, stack(0x000000f05f800000,0x000000f05f900000)]
  0x0000024d860563a0 JavaThread "BaseDataReader: error stream of fsnotifier.exe" [_thread_in_native, id=15780, stack(0x000000f05f900000,0x000000f05fa00000)]
  0x0000024d86059d60 JavaThread "JobScheduler FJ pool 3/5" daemon [_thread_blocked, id=9896, stack(0x000000f060000000,0x000000f060100000)]
  0x0000024d8fb3e3f0 JavaThread "WinConPtyProcess WaitFor powershell.exe" daemon [_thread_in_native, id=18376, stack(0x000000f060c00000,0x000000f060d00000)]
  0x0000024d8fb3d580 JavaThread "pool-4-thread-1" [_thread_blocked, id=3620, stack(0x000000f060d00000,0x000000f060e00000)]
  0x0000024d8fb3c240 JavaThread "Connector-Local" [_thread_in_native, id=18252, stack(0x000000f060e00000,0x000000f060f00000)]
  0x0000024d8fb3df20 JavaThread "Windows Shell integration" daemon [_thread_blocked, id=13964, stack(0x000000f060f00000,0x000000f061000000)]
  0x0000024d8fb3b8a0 JavaThread "HttpClient-1-SelectorManager" daemon [_thread_in_native, id=7556, stack(0x000000f061c00000,0x000000f061d00000)]
  0x0000024d9be880c0 JavaThread "pool-3-thread-1" [_thread_blocked, id=17780, stack(0x000000f062a00000,0x000000f062b00000)]
  0x0000024d6dad8880 JavaThread "MVStore Serialization" daemon [_thread_blocked, id=16012, stack(0x000000f059900000,0x000000f059a00000)]
  0x0000024d6dad7540 JavaThread "Netty Builtin Server 3" daemon [_thread_in_native, id=1104, stack(0x000000f059c00000,0x000000f059d00000)]
  0x0000024d6dad6ba0 JavaThread "Thread-74" daemon [_thread_in_native, id=4648, stack(0x000000f059800000,0x000000f059900000)]
  0x0000024d9be8c420 JavaThread "ApplicationImpl pooled thread 16" [_thread_blocked, id=15968, stack(0x000000f059a00000,0x000000f059b00000)]
  0x0000024d9be8b0e0 JavaThread "ApplicationImpl pooled thread 17" [_thread_blocked, id=3676, stack(0x000000f059d00000,0x000000f059e00000)]
  0x0000024d9be898d0 JavaThread "java" [_thread_in_native, id=15096, stack(0x000000f05a300000,0x000000f05a400000)]
  0x0000024d9be8a270 JavaThread "BaseDataReader: output stream of java" [_thread_in_native, id=15268, stack(0x000000f05a500000,0x000000f05a600000)]
  0x0000024d9be85570 JavaThread "BaseDataReader: error stream of java" [_thread_in_native, id=1180, stack(0x000000f05a600000,0x000000f05a700000)]
  0x0000024d62b176f0 JavaThread "RMI Scheduler(0)" daemon [_thread_blocked, id=13284, stack(0x000000f05ad00000,0x000000f05ae00000)]
  0x0000024d62b16880 JavaThread "RMI RenewClean-[127.0.0.1:56366]" daemon [_thread_blocked, id=13028, stack(0x000000f05ae00000,0x000000f05af00000)]
  0x0000024d62b17bc0 JavaThread "RMI GC Daemon" daemon [_thread_blocked, id=16316, stack(0x000000f05af00000,0x000000f05b000000)]
  0x0000024d62b18090 JavaThread "RMI TCP Accept-0" daemon [_thread_in_native, id=4816, stack(0x000000f05b000000,0x000000f05b100000)]
  0x0000024d62b18560 JavaThread "RMI Reaper" [_thread_blocked, id=3820, stack(0x000000f05b100000,0x000000f05b200000)]
  0x0000024d6d5b9440 JavaThread "WinConPtyProcess WaitFor C:\Program Files\Git\bin\bash.exe" daemon [_thread_in_native, id=12680, stack(0x000000f05bd00000,0x000000f05be00000)]
  0x0000024d6d5bbf90 JavaThread "pool-7-thread-1" [_thread_blocked, id=4428, stack(0x000000f05be00000,0x000000f05bf00000)]
  0x0000024d6d5bc460 JavaThread "Connector-Local" [_thread_in_native, id=12744, stack(0x000000f05bf00000,0x000000f05c000000)]
  0x0000024d6dbbed60 JavaThread "JobScheduler FJ pool 2/5" daemon [_thread_blocked, id=1480, stack(0x000000f059e00000,0x000000f059f00000)]
  0x0000024d6dbc2bf0 JavaThread "BaseDataReader: output stream of node.exe" [_thread_in_native, id=8952, stack(0x000000f05a000000,0x000000f05a100000)]
  0x0000024d86058550 JavaThread "node.exe" [_thread_in_native, id=17368, stack(0x000000f05a700000,0x000000f05a800000)]
  0x0000024d9be8bf50 JavaThread "BaseDataReader: error stream of node.exe" [_thread_in_native, id=13928, stack(0x000000f05a900000,0x000000f05aa00000)]
  0x0000024d6dbc3a60 JavaThread "DefaultDispatcher-worker-4" daemon [_thread_blocked, id=14600, stack(0x000000f05c100000,0x000000f05c200000)]
  0x0000024d9c6080f0 JavaThread "WinConPtyProcess WaitFor powershell.exe" daemon [_thread_in_native, id=9756, stack(0x000000f058000000,0x000000f058100000)]
  0x0000024d9c6085c0 JavaThread "pool-8-thread-1" [_thread_blocked, id=852, stack(0x000000f058100000,0x000000f058200000)]
  0x0000024d6d5bfe20 JavaThread "Connector-Local" [_thread_in_native, id=11000, stack(0x000000f058200000,0x000000f058300000)]
  0x0000024d6dada560 JavaThread "DefaultDispatcher-worker-1" daemon [_thread_blocked, id=6692, stack(0x000000f05c500000,0x000000f05c600000)]
  0x0000024dacade080 JavaThread "rd throttler" daemon [_thread_blocked, id=12684, stack(0x000000f05cb00000,0x000000f05cc00000)]
  0x0000024dacae28b0 JavaThread "JS external service TypeScriptServerServiceImpl" daemon [_thread_blocked, id=7932, stack(0x000000f05dd00000,0x000000f05de00000)]
  0x0000024db3963550 JavaThread "ApplicationImpl pooled thread 40" [_thread_blocked, id=16920, stack(0x000000f059600000,0x000000f059700000)]
  0x0000024db3963ef0 JavaThread "JobScheduler FJ pool 0/5" daemon [_thread_blocked, id=13260, stack(0x000000f05b200000,0x000000f05b300000)]
  0x0000024db3965230 JavaThread "JobScheduler FJ pool 1/5" daemon [_thread_blocked, id=9448, stack(0x000000f05b900000,0x000000f05ba00000)]
  0x0000024db39613a0 JavaThread "JobScheduler FJ pool 4/5" daemon [_thread_blocked, id=14280, stack(0x000000f05ba00000,0x000000f05bb00000)]
  0x0000024db3965700 JavaThread "ApplicationImpl pooled thread 42" [_thread_blocked, id=9236, stack(0x000000f05bb00000,0x000000f05bc00000)]
  0x0000024db3966570 JavaThread "JobScheduler FJ pool 5/5" daemon [_thread_blocked, id=10308, stack(0x000000f05bc00000,0x000000f05bd00000)]
  0x0000024db3961870 JavaThread "JobScheduler FJ pool 6/5" daemon [_thread_blocked, id=17480, stack(0x000000f05c000000,0x000000f05c100000)]
  0x0000024db3965bd0 JavaThread "ApplicationImpl pooled thread 43" [_thread_blocked, id=16380, stack(0x000000f05c200000,0x000000f05c300000)]
  0x0000024db39660a0 JavaThread "I/O pool 42" [_thread_blocked, id=6120, stack(0x000000f05c300000,0x000000f05c400000)]
  0x0000024db3968bf0 JavaThread "JobScheduler FJ pool 7/5" daemon [_thread_blocked, id=10008, stack(0x000000f05c800000,0x000000f05c900000)]
  0x0000024db39690c0 JavaThread "JobScheduler FJ pool 8/5" daemon [_thread_blocked, id=14588, stack(0x000000f05c900000,0x000000f05ca00000)]
  0x0000024db3969590 JavaThread "JobScheduler FJ pool 9/5" daemon [_thread_blocked, id=17576, stack(0x000000f05ca00000,0x000000f05cb00000)]
  0x0000024db3961d40 JavaThread "JobScheduler FJ pool 10/5" daemon [_thread_blocked, id=7596, stack(0x000000f05cc00000,0x000000f05cd00000)]
  0x0000024db396d8f0 JavaThread "JobScheduler FJ pool 11/5" daemon [_thread_blocked, id=16080, stack(0x000000f05cf00000,0x000000f05d000000)]
  0x0000024db396a8d0 JavaThread "JobScheduler FJ pool 12/5" daemon [_thread_blocked, id=12848, stack(0x000000f05d200000,0x000000f05d300000)]
  0x0000024db396ca80 JavaThread "JobScheduler FJ pool 13/5" daemon [_thread_blocked, id=6248, stack(0x000000f05d300000,0x000000f05d400000)]
  0x0000024db396d420 JavaThread "JobScheduler FJ pool 14/5" daemon [_thread_blocked, id=17632, stack(0x000000f05d400000,0x000000f05d500000)]
  0x0000024db396ddc0 JavaThread "JobScheduler FJ pool 15/5" daemon [_thread_blocked, id=10804, stack(0x000000f05d500000,0x000000f05d600000)]
  0x0000024db39673e0 JavaThread "JobScheduler FJ pool 16/5" daemon [_thread_blocked, id=6784, stack(0x000000f05d600000,0x000000f05d700000)]
  0x0000024db396a400 JavaThread "JobScheduler FJ pool 17/5" daemon [_thread_blocked, id=17220, stack(0x000000f05d700000,0x000000f05d800000)]
  0x0000024dacadf3c0 JavaThread "JobScheduler FJ pool 18/5" daemon [_thread_blocked, id=9288, stack(0x000000f05d800000,0x000000f05d900000)]
  0x0000024dacae0700 JavaThread "I/O pool 45" [_thread_blocked, id=5452, stack(0x000000f05a100000,0x000000f05a200000)]
  0x0000024dacae0230 JavaThread "I/O pool 46" [_thread_blocked, id=18364, stack(0x000000f05a800000,0x000000f05a900000)]
  0x0000024dacae23e0 JavaThread "ApplicationImpl pooled thread 45" [_thread_blocked, id=13348, stack(0x000000f05aa00000,0x000000f05ab00000)]
  0x0000024db39626e0 JavaThread "ApplicationImpl pooled thread 46" [_thread_blocked, id=7544, stack(0x000000f05c400000,0x000000f05c500000)]
  0x0000024d6dbc3590 JavaThread "RMI TCP Connection(idle)" daemon [_thread_blocked, id=7372, stack(0x000000f059f00000,0x000000f05a000000)]

Other Threads:
  0x0000024d61eb2220 VMThread "VM Thread" [stack: 0x000000f058800000,0x000000f058900000] [id=16068] _threads_hazard_ptr=0x0000024d9ffce100
  0x0000024d367f29e0 WatcherThread [stack: 0x000000f059400000,0x000000f059500000] [id=16116]
  0x0000024d36850690 GCTaskThread "GC Thread#0" [stack: 0x000000f058300000,0x000000f058400000] [id=6004]
  0x0000024d6d5ffad0 GCTaskThread "GC Thread#1" [stack: 0x000000f05b300000,0x000000f05b400000] [id=14440]
  0x0000024d6d5ff820 GCTaskThread "GC Thread#2" [stack: 0x000000f05b400000,0x000000f05b500000] [id=15116]
  0x0000024d6d5ff570 GCTaskThread "GC Thread#3" [stack: 0x000000f05b500000,0x000000f05b600000] [id=3180]
  0x0000024d6d5ffd80 GCTaskThread "GC Thread#4" [stack: 0x000000f05b600000,0x000000f05b700000] [id=5404]
  0x0000024d6d600590 GCTaskThread "GC Thread#5" [stack: 0x000000f05b700000,0x000000f05b800000] [id=812]
  0x0000024d368614d0 ConcurrentGCThread "G1 Main Marker" [stack: 0x000000f058400000,0x000000f058500000] [id=9912]
  0x0000024d36863590 ConcurrentGCThread "G1 Conc#0" [stack: 0x000000f058500000,0x000000f058600000] [id=5416]
  0x0000024d6d5ff2c0 ConcurrentGCThread "G1 Conc#1" [stack: 0x000000f05e600000,0x000000f05e700000] [id=16228]
  0x0000024d368bd3d0 ConcurrentGCThread "G1 Refine#0" [stack: 0x000000f058600000,0x000000f058700000] [id=17500]
  0x0000024d6d9b0840 ConcurrentGCThread "G1 Refine#1" [stack: 0x000000f05b800000,0x000000f05b900000] [id=14848]
  0x0000024d2e2a1d60 ConcurrentGCThread "G1 Refine#2" [stack: 0x000000f05e700000,0x000000f05e800000] [id=15448]
  0x0000024d6dbcc0e0 ConcurrentGCThread "G1 Refine#3" [stack: 0x000000f05e800000,0x000000f05e900000] [id=15660]
  0x0000024d85c6ff40 ConcurrentGCThread "G1 Refine#4" [stack: 0x000000f05fa00000,0x000000f05fb00000] [id=14060]
  0x0000024d61d640c0 ConcurrentGCThread "G1 Service" [stack: 0x000000f058700000,0x000000f058800000] [id=15548]

Threads with active compile tasks:

VM state: synchronizing (normal execution)

VM Mutex/Monitor currently owned by a thread:  ([mutex/lock_event])
[0x0000024d367eace0] Threads_lock - owner thread: 0x0000024d61eb2220

Heap address: 0x0000000080000000, size: 2048 MB, Compressed Oops mode: 32-bit

CDS archive(s) not mapped
Compressed class space mapped at: 0x0000000100000000-0x0000000140000000, reserved size: 1073741824
Narrow klass base: 0x0000000000000000, Narrow klass shift: 3, Narrow klass range: 0x140000000

GC Precious Log:
 CPUs: 6 total, 6 available
 Memory: 16326M
 Large Page Support: Disabled
 NUMA Support: Disabled
 Compressed Oops: Enabled (32-bit)
 Heap Region Size: 1M
 Heap Min Capacity: 128M
 Heap Initial Capacity: 128M
 Heap Max Capacity: 2G
 Pre-touch: Disabled
 Parallel Workers: 6
 Concurrent Workers: 2
 Concurrent Refinement Workers: 6
 Periodic GC: Disabled

Heap:
 garbage-first heap   total 1446912K, used 422713K [0x0000000080000000, 0x0000000100000000)
  region size 1024K, 48 young (49152K), 2 survivors (2048K)
 Metaspace       used 389565K, committed 392384K, reserved 1392640K
  class space    used 49464K, committed 50816K, reserved 1048576K

Heap Regions: E=young(eden), S=young(survivor), O=old, HS=humongous(starts), HC=humongous(continues), CS=collection set, F=free, OA=open archive, CA=closed archive, TAMS=top-at-mark-start (previous, next)
|   0|0x0000000080000000, 0x0000000080100000, 0x0000000080100000|100%|HS|  |TAMS 0x0000000080100000, 0x0000000080000000| Complete 
|   1|0x0000000080100000, 0x0000000080200000, 0x0000000080200000|100%|HS|  |TAMS 0x0000000080200000, 0x0000000080100000| Complete 
|   2|0x0000000080200000, 0x0000000080300000, 0x0000000080300000|100%| O|  |TAMS 0x0000000080300000, 0x0000000080200000| Untracked 
|   3|0x0000000080300000, 0x0000000080400000, 0x0000000080400000|100%| O|  |TAMS 0x0000000080400000, 0x0000000080300000| Untracked 
|   4|0x0000000080400000, 0x0000000080500000, 0x0000000080500000|100%| O|  |TAMS 0x0000000080500000, 0x0000000080400000| Untracked 
|   5|0x0000000080500000, 0x0000000080600000, 0x0000000080600000|100%| O|  |TAMS 0x0000000080600000, 0x0000000080500000| Untracked 
|   6|0x0000000080600000, 0x0000000080700000, 0x0000000080700000|100%| O|  |TAMS 0x0000000080700000, 0x0000000080600000| Untracked 
|   7|0x0000000080700000, 0x0000000080800000, 0x0000000080800000|100%| O|  |TAMS 0x0000000080800000, 0x0000000080700000| Untracked 
|   8|0x0000000080800000, 0x0000000080900000, 0x0000000080900000|100%| O|  |TAMS 0x0000000080900000, 0x0000000080800000| Untracked 
|   9|0x0000000080900000, 0x0000000080a00000, 0x0000000080a00000|100%| O|  |TAMS 0x0000000080a00000, 0x0000000080900000| Untracked 
|  10|0x0000000080a00000, 0x0000000080b00000, 0x0000000080b00000|100%| O|  |TAMS 0x0000000080b00000, 0x0000000080a00000| Untracked 
|  11|0x0000000080b00000, 0x0000000080c00000, 0x0000000080c00000|100%| O|  |TAMS 0x0000000080c00000, 0x0000000080b00000| Untracked 
|  12|0x0000000080c00000, 0x0000000080d00000, 0x0000000080d00000|100%| O|  |TAMS 0x0000000080d00000, 0x0000000080c00000| Untracked 
|  13|0x0000000080d00000, 0x0000000080e00000, 0x0000000080e00000|100%| O|  |TAMS 0x0000000080e00000, 0x0000000080d00000| Untracked 
|  14|0x0000000080e00000, 0x0000000080f00000, 0x0000000080f00000|100%| O|  |TAMS 0x0000000080f00000, 0x0000000080e00000| Untracked 
|  15|0x0000000080f00000, 0x0000000081000000, 0x0000000081000000|100%| O|  |TAMS 0x0000000081000000, 0x0000000080f00000| Untracked 
|  16|0x0000000081000000, 0x0000000081100000, 0x0000000081100000|100%| O|  |TAMS 0x0000000081100000, 0x0000000081000000| Untracked 
|  17|0x0000000081100000, 0x0000000081200000, 0x0000000081200000|100%|HS|  |TAMS 0x0000000081200000, 0x0000000081100000| Complete 
|  18|0x0000000081200000, 0x0000000081300000, 0x0000000081300000|100%| O|  |TAMS 0x0000000081300000, 0x0000000081200000| Untracked 
|  19|0x0000000081300000, 0x0000000081400000, 0x0000000081400000|100%| O|  |TAMS 0x0000000081400000, 0x0000000081300000| Untracked 
|  20|0x0000000081400000, 0x0000000081500000, 0x0000000081500000|100%| O|  |TAMS 0x0000000081500000, 0x0000000081400000| Untracked 
|  21|0x0000000081500000, 0x0000000081600000, 0x0000000081600000|100%| O|  |TAMS 0x0000000081600000, 0x0000000081500000| Untracked 
|  22|0x0000000081600000, 0x0000000081700000, 0x0000000081700000|100%| O|  |TAMS 0x0000000081700000, 0x0000000081600000| Untracked 
|  23|0x0000000081700000, 0x0000000081800000, 0x0000000081800000|100%| O|  |TAMS 0x0000000081700000, 0x0000000081700000| Untracked 
|  24|0x0000000081800000, 0x0000000081900000, 0x0000000081900000|100%| O|  |TAMS 0x0000000081900000, 0x0000000081800000| Untracked 
|  25|0x0000000081900000, 0x0000000081a00000, 0x0000000081a00000|100%| O|  |TAMS 0x0000000081a00000, 0x0000000081900000| Untracked 
|  26|0x0000000081a00000, 0x0000000081b00000, 0x0000000081b00000|100%| O|  |TAMS 0x0000000081b00000, 0x0000000081a00000| Untracked 
|  27|0x0000000081b00000, 0x0000000081c00000, 0x0000000081c00000|100%| O|  |TAMS 0x0000000081c00000, 0x0000000081b00000| Untracked 
|  28|0x0000000081c00000, 0x0000000081d00000, 0x0000000081d00000|100%| O|  |TAMS 0x0000000081d00000, 0x0000000081c00000| Untracked 
|  29|0x0000000081d00000, 0x0000000081e00000, 0x0000000081e00000|100%| O|  |TAMS 0x0000000081e00000, 0x0000000081d00000| Untracked 
|  30|0x0000000081e00000, 0x0000000081f00000, 0x0000000081f00000|100%|HS|  |TAMS 0x0000000081f00000, 0x0000000081e00000| Complete 
|  31|0x0000000081f00000, 0x0000000082000000, 0x0000000082000000|100%| O|  |TAMS 0x0000000082000000, 0x0000000081f00000| Untracked 
|  32|0x0000000082000000, 0x0000000082100000, 0x0000000082100000|100%| O|  |TAMS 0x0000000082100000, 0x0000000082000000| Untracked 
|  33|0x0000000082100000, 0x0000000082200000, 0x0000000082200000|100%| O|  |TAMS 0x0000000082200000, 0x0000000082100000| Untracked 
|  34|0x0000000082200000, 0x0000000082300000, 0x0000000082300000|100%| O|  |TAMS 0x0000000082300000, 0x0000000082200000| Untracked 
|  35|0x0000000082300000, 0x0000000082400000, 0x0000000082400000|100%| O|  |TAMS 0x0000000082400000, 0x0000000082300000| Untracked 
|  36|0x0000000082400000, 0x0000000082500000, 0x0000000082500000|100%| O|  |TAMS 0x0000000082500000, 0x0000000082400000| Untracked 
|  37|0x0000000082500000, 0x0000000082600000, 0x0000000082600000|100%| O|  |TAMS 0x0000000082600000, 0x0000000082500000| Untracked 
|  38|0x0000000082600000, 0x0000000082700000, 0x0000000082700000|100%| O|  |TAMS 0x0000000082700000, 0x0000000082600000| Untracked 
|  39|0x0000000082700000, 0x0000000082800000, 0x0000000082800000|100%| O|  |TAMS 0x0000000082800000, 0x0000000082700000| Untracked 
|  40|0x0000000082800000, 0x0000000082900000, 0x0000000082900000|100%| O|  |TAMS 0x0000000082900000, 0x0000000082800000| Untracked 
|  41|0x0000000082900000, 0x0000000082a00000, 0x0000000082a00000|100%| O|  |TAMS 0x0000000082a00000, 0x0000000082900000| Untracked 
|  42|0x0000000082a00000, 0x0000000082b00000, 0x0000000082b00000|100%| O|  |TAMS 0x0000000082b00000, 0x0000000082a00000| Untracked 
|  43|0x0000000082b00000, 0x0000000082b00000, 0x0000000082c00000|  0%| F|  |TAMS 0x0000000082b00000, 0x0000000082b00000| Untracked 
|  44|0x0000000082c00000, 0x0000000082d00000, 0x0000000082d00000|100%| O|  |TAMS 0x0000000082d00000, 0x0000000082c00000| Untracked 
|  45|0x0000000082d00000, 0x0000000082e00000, 0x0000000082e00000|100%| O|  |TAMS 0x0000000082e00000, 0x0000000082d00000| Untracked 
|  46|0x0000000082e00000, 0x0000000082f00000, 0x0000000082f00000|100%| O|  |TAMS 0x0000000082f00000, 0x0000000082e00000| Untracked 
|  47|0x0000000082f00000, 0x0000000083000000, 0x0000000083000000|100%| O|  |TAMS 0x0000000083000000, 0x0000000082f00000| Untracked 
|  48|0x0000000083000000, 0x0000000083100000, 0x0000000083100000|100%| O|  |TAMS 0x0000000083100000, 0x0000000083000000| Untracked 
|  49|0x0000000083100000, 0x0000000083200000, 0x0000000083200000|100%| O|  |TAMS 0x0000000083200000, 0x0000000083100000| Untracked 
|  50|0x0000000083200000, 0x0000000083200000, 0x0000000083300000|  0%| F|  |TAMS 0x0000000083200000, 0x0000000083200000| Untracked 
|  51|0x0000000083300000, 0x0000000083400000, 0x0000000083400000|100%| O|  |TAMS 0x0000000083400000, 0x0000000083300000| Untracked 
|  52|0x0000000083400000, 0x0000000083400000, 0x0000000083500000|  0%| F|  |TAMS 0x0000000083400000, 0x0000000083400000| Untracked 
|  53|0x0000000083500000, 0x0000000083500000, 0x0000000083600000|  0%| F|  |TAMS 0x0000000083500000, 0x0000000083500000| Untracked 
|  54|0x0000000083600000, 0x0000000083700000, 0x0000000083700000|100%| O|  |TAMS 0x0000000083700000, 0x0000000083600000| Untracked 
|  55|0x0000000083700000, 0x0000000083800000, 0x0000000083800000|100%| O|  |TAMS 0x0000000083800000, 0x0000000083700000| Untracked 
|  56|0x0000000083800000, 0x0000000083900000, 0x0000000083900000|100%| O|  |TAMS 0x0000000083900000, 0x0000000083800000| Untracked 
|  57|0x0000000083900000, 0x0000000083a00000, 0x0000000083a00000|100%| O|  |TAMS 0x0000000083a00000, 0x0000000083900000| Untracked 
|  58|0x0000000083a00000, 0x0000000083b00000, 0x0000000083b00000|100%| O|  |TAMS 0x0000000083b00000, 0x0000000083a00000| Untracked 
|  59|0x0000000083b00000, 0x0000000083c00000, 0x0000000083c00000|100%|HS|  |TAMS 0x0000000083c00000, 0x0000000083b00000| Complete 
|  60|0x0000000083c00000, 0x0000000083d00000, 0x0000000083d00000|100%| O|  |TAMS 0x0000000083d00000, 0x0000000083c00000| Untracked 
|  61|0x0000000083d00000, 0x0000000083e00000, 0x0000000083e00000|100%| O|  |TAMS 0x0000000083e00000, 0x0000000083d00000| Untracked 
|  62|0x0000000083e00000, 0x0000000083f00000, 0x0000000083f00000|100%| O|  |TAMS 0x0000000083f00000, 0x0000000083e00000| Untracked 
|  63|0x0000000083f00000, 0x0000000084000000, 0x0000000084000000|100%| O|  |TAMS 0x0000000084000000, 0x0000000083f00000| Untracked 
|  64|0x0000000084000000, 0x0000000084100000, 0x0000000084100000|100%| O|  |TAMS 0x0000000084100000, 0x0000000084000000| Untracked 
|  65|0x0000000084100000, 0x0000000084200000, 0x0000000084200000|100%| O|  |TAMS 0x0000000084200000, 0x0000000084100000| Untracked 
|  66|0x0000000084200000, 0x0000000084300000, 0x0000000084300000|100%| O|  |TAMS 0x0000000084300000, 0x0000000084200000| Untracked 
|  67|0x0000000084300000, 0x0000000084400000, 0x0000000084400000|100%| O|  |TAMS 0x0000000084400000, 0x0000000084300000| Untracked 
|  68|0x0000000084400000, 0x0000000084400000, 0x0000000084500000|  0%| F|  |TAMS 0x0000000084400000, 0x0000000084400000| Untracked 
|  69|0x0000000084500000, 0x0000000084600000, 0x0000000084600000|100%| O|  |TAMS 0x0000000084600000, 0x0000000084500000| Untracked 
|  70|0x0000000084600000, 0x0000000084700000, 0x0000000084700000|100%| O|  |TAMS 0x0000000084700000, 0x0000000084600000| Untracked 
|  71|0x0000000084700000, 0x0000000084800000, 0x0000000084800000|100%| O|  |TAMS 0x0000000084800000, 0x0000000084700000| Untracked 
|  72|0x0000000084800000, 0x0000000084900000, 0x0000000084900000|100%| O|  |TAMS 0x0000000084900000, 0x0000000084800000| Untracked 
|  73|0x0000000084900000, 0x0000000084a00000, 0x0000000084a00000|100%| O|  |TAMS 0x0000000084a00000, 0x0000000084900000| Untracked 
|  74|0x0000000084a00000, 0x0000000084b00000, 0x0000000084b00000|100%| O|  |TAMS 0x0000000084b00000, 0x0000000084a00000| Untracked 
|  75|0x0000000084b00000, 0x0000000084c00000, 0x0000000084c00000|100%| O|  |TAMS 0x0000000084c00000, 0x0000000084b00000| Untracked 
|  76|0x0000000084c00000, 0x0000000084d00000, 0x0000000084d00000|100%| O|  |TAMS 0x0000000084d00000, 0x0000000084c00000| Untracked 
|  77|0x0000000084d00000, 0x0000000084e00000, 0x0000000084e00000|100%| O|  |TAMS 0x0000000084e00000, 0x0000000084d00000| Untracked 
|  78|0x0000000084e00000, 0x0000000084f00000, 0x0000000084f00000|100%| O|  |TAMS 0x0000000084f00000, 0x0000000084e00000| Untracked 
|  79|0x0000000084f00000, 0x0000000085000000, 0x0000000085000000|100%| O|  |TAMS 0x0000000085000000, 0x0000000084f00000| Untracked 
|  80|0x0000000085000000, 0x0000000085100000, 0x0000000085100000|100%| O|  |TAMS 0x0000000085100000, 0x0000000085000000| Untracked 
|  81|0x0000000085100000, 0x0000000085200000, 0x0000000085200000|100%| O|  |TAMS 0x0000000085200000, 0x0000000085100000| Untracked 
|  82|0x0000000085200000, 0x0000000085200000, 0x0000000085300000|  0%| F|  |TAMS 0x0000000085200000, 0x0000000085200000| Untracked 
|  83|0x0000000085300000, 0x0000000085400000, 0x0000000085400000|100%| O|  |TAMS 0x0000000085400000, 0x0000000085300000| Untracked 
|  84|0x0000000085400000, 0x0000000085500000, 0x0000000085500000|100%| O|  |TAMS 0x0000000085500000, 0x0000000085400000| Untracked 
|  85|0x0000000085500000, 0x0000000085600000, 0x0000000085600000|100%| O|  |TAMS 0x0000000085500000, 0x0000000085500000| Untracked 
|  86|0x0000000085600000, 0x0000000085700000, 0x0000000085700000|100%| O|  |TAMS 0x0000000085600000, 0x0000000085600000| Untracked 
|  87|0x0000000085700000, 0x0000000085700000, 0x0000000085800000|  0%| F|  |TAMS 0x0000000085700000, 0x0000000085700000| Untracked 
|  88|0x0000000085800000, 0x0000000085900000, 0x0000000085900000|100%| O|  |TAMS 0x0000000085900000, 0x0000000085800000| Untracked 
|  89|0x0000000085900000, 0x0000000085a00000, 0x0000000085a00000|100%| O|  |TAMS 0x0000000085a00000, 0x0000000085900000| Untracked 
|  90|0x0000000085a00000, 0x0000000085a00000, 0x0000000085b00000|  0%| F|  |TAMS 0x0000000085a00000, 0x0000000085a00000| Untracked 
|  91|0x0000000085b00000, 0x0000000085c00000, 0x0000000085c00000|100%| O|  |TAMS 0x0000000085c00000, 0x0000000085b00000| Untracked 
|  92|0x0000000085c00000, 0x0000000085d00000, 0x0000000085d00000|100%| O|  |TAMS 0x0000000085d00000, 0x0000000085c00000| Untracked 
|  93|0x0000000085d00000, 0x0000000085e00000, 0x0000000085e00000|100%| O|  |TAMS 0x0000000085e00000, 0x0000000085d00000| Untracked 
|  94|0x0000000085e00000, 0x0000000085f00000, 0x0000000085f00000|100%| O|  |TAMS 0x0000000085f00000, 0x0000000085e00000| Untracked 
|  95|0x0000000085f00000, 0x0000000086000000, 0x0000000086000000|100%| O|  |TAMS 0x0000000086000000, 0x0000000085f00000| Untracked 
|  96|0x0000000086000000, 0x0000000086100000, 0x0000000086100000|100%| O|  |TAMS 0x0000000086100000, 0x0000000086000000| Untracked 
|  97|0x0000000086100000, 0x0000000086200000, 0x0000000086200000|100%| O|  |TAMS 0x0000000086200000, 0x0000000086100000| Untracked 
|  98|0x0000000086200000, 0x0000000086300000, 0x0000000086300000|100%| O|  |TAMS 0x0000000086300000, 0x0000000086200000| Untracked 
|  99|0x0000000086300000, 0x0000000086400000, 0x0000000086400000|100%| O|  |TAMS 0x0000000086400000, 0x0000000086300000| Untracked 
| 100|0x0000000086400000, 0x0000000086500000, 0x0000000086500000|100%| O|  |TAMS 0x0000000086500000, 0x0000000086400000| Untracked 
| 101|0x0000000086500000, 0x0000000086600000, 0x0000000086600000|100%| O|  |TAMS 0x0000000086600000, 0x0000000086500000| Untracked 
| 102|0x0000000086600000, 0x0000000086700000, 0x0000000086700000|100%| O|  |TAMS 0x0000000086700000, 0x0000000086600000| Untracked 
| 103|0x0000000086700000, 0x0000000086800000, 0x0000000086800000|100%|HS|  |TAMS 0x0000000086800000, 0x0000000086700000| Complete 
| 104|0x0000000086800000, 0x0000000086900000, 0x0000000086900000|100%|HC|  |TAMS 0x0000000086900000, 0x0000000086800000| Complete 
| 105|0x0000000086900000, 0x0000000086a00000, 0x0000000086a00000|100%|HC|  |TAMS 0x0000000086a00000, 0x0000000086900000| Complete 
| 106|0x0000000086a00000, 0x0000000086b00000, 0x0000000086b00000|100%|HC|  |TAMS 0x0000000086b00000, 0x0000000086a00000| Complete 
| 107|0x0000000086b00000, 0x0000000086c00000, 0x0000000086c00000|100%|HC|  |TAMS 0x0000000086c00000, 0x0000000086b00000| Complete 
| 108|0x0000000086c00000, 0x0000000086d00000, 0x0000000086d00000|100%|HC|  |TAMS 0x0000000086d00000, 0x0000000086c00000| Complete 
| 109|0x0000000086d00000, 0x0000000086e00000, 0x0000000086e00000|100%|HC|  |TAMS 0x0000000086e00000, 0x0000000086d00000| Complete 
| 110|0x0000000086e00000, 0x0000000086f00000, 0x0000000086f00000|100%|HC|  |TAMS 0x0000000086f00000, 0x0000000086e00000| Complete 
| 111|0x0000000086f00000, 0x0000000087000000, 0x0000000087000000|100%| O|  |TAMS 0x0000000087000000, 0x0000000086f00000| Untracked 
| 112|0x0000000087000000, 0x0000000087100000, 0x0000000087100000|100%| O|  |TAMS 0x0000000087100000, 0x0000000087000000| Untracked 
| 113|0x0000000087100000, 0x0000000087200000, 0x0000000087200000|100%| O|  |TAMS 0x0000000087200000, 0x0000000087100000| Untracked 
| 114|0x0000000087200000, 0x0000000087300000, 0x0000000087300000|100%| O|  |TAMS 0x0000000087300000, 0x0000000087200000| Untracked 
| 115|0x0000000087300000, 0x0000000087400000, 0x0000000087400000|100%| O|  |TAMS 0x0000000087400000, 0x0000000087300000| Untracked 
| 116|0x0000000087400000, 0x0000000087500000, 0x0000000087500000|100%| O|  |TAMS 0x0000000087500000, 0x0000000087400000| Untracked 
| 117|0x0000000087500000, 0x0000000087600000, 0x0000000087600000|100%| O|  |TAMS 0x0000000087600000, 0x0000000087500000| Untracked 
| 118|0x0000000087600000, 0x0000000087600000, 0x0000000087700000|  0%| F|  |TAMS 0x0000000087600000, 0x0000000087600000| Untracked 
| 119|0x0000000087700000, 0x0000000087800000, 0x0000000087800000|100%| O|  |TAMS 0x0000000087800000, 0x0000000087700000| Untracked 
| 120|0x0000000087800000, 0x0000000087900000, 0x0000000087900000|100%| O|  |TAMS 0x0000000087900000, 0x0000000087800000| Untracked 
| 121|0x0000000087900000, 0x0000000087a00000, 0x0000000087a00000|100%| O|  |TAMS 0x0000000087a00000, 0x0000000087900000| Untracked 
| 122|0x0000000087a00000, 0x0000000087b00000, 0x0000000087b00000|100%| O|  |TAMS 0x0000000087b00000, 0x0000000087a00000| Untracked 
| 123|0x0000000087b00000, 0x0000000087c00000, 0x0000000087c00000|100%| O|  |TAMS 0x0000000087c00000, 0x0000000087b00000| Untracked 
| 124|0x0000000087c00000, 0x0000000087d00000, 0x0000000087d00000|100%| O|  |TAMS 0x0000000087d00000, 0x0000000087c00000| Untracked 
| 125|0x0000000087d00000, 0x0000000087e00000, 0x0000000087e00000|100%| O|  |TAMS 0x0000000087e00000, 0x0000000087d00000| Untracked 
| 126|0x0000000087e00000, 0x0000000087f00000, 0x0000000087f00000|100%| O|  |TAMS 0x0000000087f00000, 0x0000000087e00000| Untracked 
| 127|0x0000000087f00000, 0x0000000088000000, 0x0000000088000000|100%| O|  |TAMS 0x0000000088000000, 0x0000000087f00000| Untracked 
| 128|0x0000000088000000, 0x0000000088100000, 0x0000000088100000|100%| O|  |TAMS 0x0000000088100000, 0x0000000088000000| Untracked 
| 129|0x0000000088100000, 0x0000000088200000, 0x0000000088200000|100%|HS|  |TAMS 0x0000000088200000, 0x0000000088100000| Complete 
| 130|0x0000000088200000, 0x0000000088300000, 0x0000000088300000|100%| O|  |TAMS 0x0000000088300000, 0x0000000088200000| Untracked 
| 131|0x0000000088300000, 0x0000000088400000, 0x0000000088400000|100%| O|  |TAMS 0x0000000088400000, 0x0000000088300000| Untracked 
| 132|0x0000000088400000, 0x0000000088500000, 0x0000000088500000|100%| O|  |TAMS 0x0000000088500000, 0x0000000088400000| Untracked 
| 133|0x0000000088500000, 0x0000000088600000, 0x0000000088600000|100%| O|  |TAMS 0x0000000088600000, 0x0000000088500000| Untracked 
| 134|0x0000000088600000, 0x0000000088700000, 0x0000000088700000|100%| O|  |TAMS 0x0000000088700000, 0x0000000088600000| Untracked 
| 135|0x0000000088700000, 0x0000000088800000, 0x0000000088800000|100%| O|  |TAMS 0x0000000088800000, 0x0000000088700000| Untracked 
| 136|0x0000000088800000, 0x0000000088900000, 0x0000000088900000|100%| O|  |TAMS 0x0000000088900000, 0x0000000088800000| Untracked 
| 137|0x0000000088900000, 0x0000000088a00000, 0x0000000088a00000|100%| O|  |TAMS 0x0000000088a00000, 0x0000000088900000| Untracked 
| 138|0x0000000088a00000, 0x0000000088b00000, 0x0000000088b00000|100%| O|  |TAMS 0x0000000088b00000, 0x0000000088a00000| Untracked 
| 139|0x0000000088b00000, 0x0000000088c00000, 0x0000000088c00000|100%| O|  |TAMS 0x0000000088c00000, 0x0000000088b00000| Untracked 
| 140|0x0000000088c00000, 0x0000000088d00000, 0x0000000088d00000|100%| O|  |TAMS 0x0000000088d00000, 0x0000000088c00000| Untracked 
| 141|0x0000000088d00000, 0x0000000088e00000, 0x0000000088e00000|100%| O|  |TAMS 0x0000000088e00000, 0x0000000088d00000| Untracked 
| 142|0x0000000088e00000, 0x0000000088f00000, 0x0000000088f00000|100%| O|  |TAMS 0x0000000088f00000, 0x0000000088e00000| Untracked 
| 143|0x0000000088f00000, 0x0000000089000000, 0x0000000089000000|100%| O|  |TAMS 0x0000000089000000, 0x0000000088f00000| Untracked 
| 144|0x0000000089000000, 0x0000000089100000, 0x0000000089100000|100%| O|  |TAMS 0x0000000089100000, 0x0000000089000000| Untracked 
| 145|0x0000000089100000, 0x0000000089200000, 0x0000000089200000|100%| O|  |TAMS 0x0000000089200000, 0x0000000089100000| Untracked 
| 146|0x0000000089200000, 0x0000000089300000, 0x0000000089300000|100%| O|  |TAMS 0x0000000089300000, 0x0000000089200000| Untracked 
| 147|0x0000000089300000, 0x0000000089400000, 0x0000000089400000|100%| O|  |TAMS 0x0000000089400000, 0x0000000089300000| Untracked 
| 148|0x0000000089400000, 0x0000000089500000, 0x0000000089500000|100%| O|  |TAMS 0x0000000089500000, 0x0000000089400000| Untracked 
| 149|0x0000000089500000, 0x0000000089600000, 0x0000000089600000|100%| O|  |TAMS 0x0000000089600000, 0x0000000089500000| Untracked 
| 150|0x0000000089600000, 0x0000000089700000, 0x0000000089700000|100%| O|  |TAMS 0x0000000089700000, 0x0000000089600000| Untracked 
| 151|0x0000000089700000, 0x0000000089800000, 0x0000000089800000|100%| O|  |TAMS 0x0000000089800000, 0x0000000089700000| Untracked 
| 152|0x0000000089800000, 0x0000000089900000, 0x0000000089900000|100%| O|  |TAMS 0x0000000089900000, 0x0000000089800000| Untracked 
| 153|0x0000000089900000, 0x0000000089a00000, 0x0000000089a00000|100%| O|  |TAMS 0x0000000089a00000, 0x0000000089900000| Untracked 
| 154|0x0000000089a00000, 0x0000000089b00000, 0x0000000089b00000|100%| O|  |TAMS 0x0000000089b00000, 0x0000000089a00000| Untracked 
| 155|0x0000000089b00000, 0x0000000089c00000, 0x0000000089c00000|100%| O|  |TAMS 0x0000000089c00000, 0x0000000089b00000| Untracked 
| 156|0x0000000089c00000, 0x0000000089d00000, 0x0000000089d00000|100%| O|  |TAMS 0x0000000089d00000, 0x0000000089c00000| Untracked 
| 157|0x0000000089d00000, 0x0000000089e00000, 0x0000000089e00000|100%| O|  |TAMS 0x0000000089e00000, 0x0000000089d00000| Untracked 
| 158|0x0000000089e00000, 0x0000000089f00000, 0x0000000089f00000|100%| O|  |TAMS 0x0000000089f00000, 0x0000000089e00000| Untracked 
| 159|0x0000000089f00000, 0x000000008a000000, 0x000000008a000000|100%| O|  |TAMS 0x000000008a000000, 0x0000000089f00000| Untracked 
| 160|0x000000008a000000, 0x000000008a100000, 0x000000008a100000|100%| O|  |TAMS 0x000000008a100000, 0x000000008a000000| Untracked 
| 161|0x000000008a100000, 0x000000008a200000, 0x000000008a200000|100%| O|  |TAMS 0x000000008a200000, 0x000000008a100000| Untracked 
| 162|0x000000008a200000, 0x000000008a300000, 0x000000008a300000|100%| O|  |TAMS 0x000000008a300000, 0x000000008a200000| Untracked 
| 163|0x000000008a300000, 0x000000008a400000, 0x000000008a400000|100%| O|  |TAMS 0x000000008a400000, 0x000000008a300000| Untracked 
| 164|0x000000008a400000, 0x000000008a500000, 0x000000008a500000|100%| O|  |TAMS 0x000000008a500000, 0x000000008a400000| Untracked 
| 165|0x000000008a500000, 0x000000008a600000, 0x000000008a600000|100%| O|  |TAMS 0x000000008a600000, 0x000000008a500000| Untracked 
| 166|0x000000008a600000, 0x000000008a700000, 0x000000008a700000|100%| O|  |TAMS 0x000000008a700000, 0x000000008a600000| Untracked 
| 167|0x000000008a700000, 0x000000008a800000, 0x000000008a800000|100%| O|  |TAMS 0x000000008a800000, 0x000000008a700000| Untracked 
| 168|0x000000008a800000, 0x000000008a900000, 0x000000008a900000|100%| O|  |TAMS 0x000000008a900000, 0x000000008a800000| Untracked 
| 169|0x000000008a900000, 0x000000008aa00000, 0x000000008aa00000|100%| O|  |TAMS 0x000000008aa00000, 0x000000008a900000| Untracked 
| 170|0x000000008aa00000, 0x000000008ab00000, 0x000000008ab00000|100%| O|  |TAMS 0x000000008ab00000, 0x000000008aa00000| Untracked 
| 171|0x000000008ab00000, 0x000000008ac00000, 0x000000008ac00000|100%| O|  |TAMS 0x000000008ac00000, 0x000000008ab00000| Untracked 
| 172|0x000000008ac00000, 0x000000008ad00000, 0x000000008ad00000|100%| O|  |TAMS 0x000000008ad00000, 0x000000008ac00000| Untracked 
| 173|0x000000008ad00000, 0x000000008ae00000, 0x000000008ae00000|100%| O|  |TAMS 0x000000008ae00000, 0x000000008ad00000| Untracked 
| 174|0x000000008ae00000, 0x000000008af00000, 0x000000008af00000|100%| O|  |TAMS 0x000000008af00000, 0x000000008ae00000| Untracked 
| 175|0x000000008af00000, 0x000000008b000000, 0x000000008b000000|100%| O|  |TAMS 0x000000008b000000, 0x000000008af00000| Untracked 
| 176|0x000000008b000000, 0x000000008b100000, 0x000000008b100000|100%| O|  |TAMS 0x000000008b100000, 0x000000008b000000| Untracked 
| 177|0x000000008b100000, 0x000000008b200000, 0x000000008b200000|100%| O|  |TAMS 0x000000008b200000, 0x000000008b100000| Untracked 
| 178|0x000000008b200000, 0x000000008b300000, 0x000000008b300000|100%| O|  |TAMS 0x000000008b300000, 0x000000008b200000| Untracked 
| 179|0x000000008b300000, 0x000000008b400000, 0x000000008b400000|100%| O|  |TAMS 0x000000008b400000, 0x000000008b300000| Untracked 
| 180|0x000000008b400000, 0x000000008b500000, 0x000000008b500000|100%| O|  |TAMS 0x000000008b500000, 0x000000008b400000| Untracked 
| 181|0x000000008b500000, 0x000000008b600000, 0x000000008b600000|100%|HS|  |TAMS 0x000000008b600000, 0x000000008b500000| Complete 
| 182|0x000000008b600000, 0x000000008b700000, 0x000000008b700000|100%| O|  |TAMS 0x000000008b700000, 0x000000008b600000| Untracked 
| 183|0x000000008b700000, 0x000000008b800000, 0x000000008b800000|100%| O|  |TAMS 0x000000008b800000, 0x000000008b700000| Untracked 
| 184|0x000000008b800000, 0x000000008b900000, 0x000000008b900000|100%| O|  |TAMS 0x000000008b900000, 0x000000008b800000| Untracked 
| 185|0x000000008b900000, 0x000000008ba00000, 0x000000008ba00000|100%| O|  |TAMS 0x000000008ba00000, 0x000000008b900000| Untracked 
| 186|0x000000008ba00000, 0x000000008bb00000, 0x000000008bb00000|100%| O|  |TAMS 0x000000008bb00000, 0x000000008ba00000| Untracked 
| 187|0x000000008bb00000, 0x000000008bc00000, 0x000000008bc00000|100%| O|  |TAMS 0x000000008bc00000, 0x000000008bb00000| Untracked 
| 188|0x000000008bc00000, 0x000000008bd00000, 0x000000008bd00000|100%| O|  |TAMS 0x000000008bd00000, 0x000000008bc00000| Untracked 
| 189|0x000000008bd00000, 0x000000008be00000, 0x000000008be00000|100%| O|  |TAMS 0x000000008be00000, 0x000000008bd00000| Untracked 
| 190|0x000000008be00000, 0x000000008bf00000, 0x000000008bf00000|100%| O|  |TAMS 0x000000008be00000, 0x000000008be00000| Untracked 
| 191|0x000000008bf00000, 0x000000008c000000, 0x000000008c000000|100%| O|  |TAMS 0x000000008c000000, 0x000000008bf00000| Untracked 
| 192|0x000000008c000000, 0x000000008c100000, 0x000000008c100000|100%| O|  |TAMS 0x000000008c100000, 0x000000008c000000| Untracked 
| 193|0x000000008c100000, 0x000000008c200000, 0x000000008c200000|100%| O|  |TAMS 0x000000008c100000, 0x000000008c100000| Untracked 
| 194|0x000000008c200000, 0x000000008c300000, 0x000000008c300000|100%| O|  |TAMS 0x000000008c300000, 0x000000008c200000| Untracked 
| 195|0x000000008c300000, 0x000000008c300000, 0x000000008c400000|  0%| F|  |TAMS 0x000000008c300000, 0x000000008c300000| Untracked 
| 196|0x000000008c400000, 0x000000008c500000, 0x000000008c500000|100%| O|  |TAMS 0x000000008c500000, 0x000000008c400000| Untracked 
| 197|0x000000008c500000, 0x000000008c600000, 0x000000008c600000|100%| O|  |TAMS 0x000000008c600000, 0x000000008c500000| Untracked 
| 198|0x000000008c600000, 0x000000008c700000, 0x000000008c700000|100%| O|  |TAMS 0x000000008c700000, 0x000000008c600000| Untracked 
| 199|0x000000008c700000, 0x000000008c800000, 0x000000008c800000|100%| O|  |TAMS 0x000000008c800000, 0x000000008c700000| Untracked 
| 200|0x000000008c800000, 0x000000008c900000, 0x000000008c900000|100%| O|  |TAMS 0x000000008c900000, 0x000000008c800000| Untracked 
| 201|0x000000008c900000, 0x000000008ca00000, 0x000000008ca00000|100%| O|  |TAMS 0x000000008ca00000, 0x000000008c900000| Untracked 
| 202|0x000000008ca00000, 0x000000008cb00000, 0x000000008cb00000|100%| O|  |TAMS 0x000000008cb00000, 0x000000008ca00000| Untracked 
| 203|0x000000008cb00000, 0x000000008cc00000, 0x000000008cc00000|100%| O|  |TAMS 0x000000008cc00000, 0x000000008cb00000| Untracked 
| 204|0x000000008cc00000, 0x000000008cd00000, 0x000000008cd00000|100%| O|  |TAMS 0x000000008cd00000, 0x000000008cc00000| Untracked 
| 205|0x000000008cd00000, 0x000000008ce00000, 0x000000008ce00000|100%| O|  |TAMS 0x000000008ce00000, 0x000000008cd00000| Untracked 
| 206|0x000000008ce00000, 0x000000008cf00000, 0x000000008cf00000|100%| O|  |TAMS 0x000000008cf00000, 0x000000008ce00000| Untracked 
| 207|0x000000008cf00000, 0x000000008d000000, 0x000000008d000000|100%| O|  |TAMS 0x000000008d000000, 0x000000008cf00000| Untracked 
| 208|0x000000008d000000, 0x000000008d100000, 0x000000008d100000|100%| O|  |TAMS 0x000000008d100000, 0x000000008d000000| Untracked 
| 209|0x000000008d100000, 0x000000008d200000, 0x000000008d200000|100%| O|  |TAMS 0x000000008d200000, 0x000000008d100000| Untracked 
| 210|0x000000008d200000, 0x000000008d300000, 0x000000008d300000|100%| O|  |TAMS 0x000000008d300000, 0x000000008d200000| Untracked 
| 211|0x000000008d300000, 0x000000008d400000, 0x000000008d400000|100%| O|  |TAMS 0x000000008d400000, 0x000000008d300000| Untracked 
| 212|0x000000008d400000, 0x000000008d500000, 0x000000008d500000|100%| O|  |TAMS 0x000000008d500000, 0x000000008d400000| Untracked 
| 213|0x000000008d500000, 0x000000008d600000, 0x000000008d600000|100%| O|  |TAMS 0x000000008d600000, 0x000000008d500000| Untracked 
| 214|0x000000008d600000, 0x000000008d700000, 0x000000008d700000|100%| O|  |TAMS 0x000000008d700000, 0x000000008d600000| Untracked 
| 215|0x000000008d700000, 0x000000008d800000, 0x000000008d800000|100%| O|  |TAMS 0x000000008d800000, 0x000000008d700000| Untracked 
| 216|0x000000008d800000, 0x000000008d900000, 0x000000008d900000|100%| O|  |TAMS 0x000000008d900000, 0x000000008d800000| Untracked 
| 217|0x000000008d900000, 0x000000008d900000, 0x000000008da00000|  0%| F|  |TAMS 0x000000008d900000, 0x000000008d900000| Untracked 
| 218|0x000000008da00000, 0x000000008db00000, 0x000000008db00000|100%| O|  |TAMS 0x000000008db00000, 0x000000008da00000| Untracked 
| 219|0x000000008db00000, 0x000000008dc00000, 0x000000008dc00000|100%| O|  |TAMS 0x000000008db00000, 0x000000008db00000| Untracked 
| 220|0x000000008dc00000, 0x000000008dc00000, 0x000000008dd00000|  0%| F|  |TAMS 0x000000008dc00000, 0x000000008dc00000| Untracked 
| 221|0x000000008dd00000, 0x000000008de00000, 0x000000008de00000|100%| O|  |TAMS 0x000000008de00000, 0x000000008dd00000| Untracked 
| 222|0x000000008de00000, 0x000000008df00000, 0x000000008df00000|100%| O|  |TAMS 0x000000008df00000, 0x000000008de00000| Untracked 
| 223|0x000000008df00000, 0x000000008e000000, 0x000000008e000000|100%| O|  |TAMS 0x000000008e000000, 0x000000008df00000| Untracked 
| 224|0x000000008e000000, 0x000000008e100000, 0x000000008e100000|100%| O|  |TAMS 0x000000008e100000, 0x000000008e000000| Untracked 
| 225|0x000000008e100000, 0x000000008e200000, 0x000000008e200000|100%| O|  |TAMS 0x000000008e200000, 0x000000008e100000| Untracked 
| 226|0x000000008e200000, 0x000000008e300000, 0x000000008e300000|100%| O|  |TAMS 0x000000008e200000, 0x000000008e200000| Untracked 
| 227|0x000000008e300000, 0x000000008e400000, 0x000000008e400000|100%| O|  |TAMS 0x000000008e400000, 0x000000008e300000| Untracked 
| 228|0x000000008e400000, 0x000000008e500000, 0x000000008e500000|100%| O|  |TAMS 0x000000008e500000, 0x000000008e400000| Untracked 
| 229|0x000000008e500000, 0x000000008e600000, 0x000000008e600000|100%| O|  |TAMS 0x000000008e600000, 0x000000008e500000| Untracked 
| 230|0x000000008e600000, 0x000000008e700000, 0x000000008e700000|100%| O|  |TAMS 0x000000008e600000, 0x000000008e600000| Untracked 
| 231|0x000000008e700000, 0x000000008e800000, 0x000000008e800000|100%| O|  |TAMS 0x000000008e800000, 0x000000008e700000| Untracked 
| 232|0x000000008e800000, 0x000000008e900000, 0x000000008e900000|100%| O|  |TAMS 0x000000008e800000, 0x000000008e800000| Untracked 
| 233|0x000000008e900000, 0x000000008ea00000, 0x000000008ea00000|100%| O|  |TAMS 0x000000008ea00000, 0x000000008e900000| Untracked 
| 234|0x000000008ea00000, 0x000000008eb00000, 0x000000008eb00000|100%| O|  |TAMS 0x000000008eb00000, 0x000000008ea00000| Untracked 
| 235|0x000000008eb00000, 0x000000008eb00000, 0x000000008ec00000|  0%| F|  |TAMS 0x000000008eb00000, 0x000000008eb00000| Untracked 
| 236|0x000000008ec00000, 0x000000008ec00000, 0x000000008ed00000|  0%| F|  |TAMS 0x000000008ec00000, 0x000000008ec00000| Untracked 
| 237|0x000000008ed00000, 0x000000008ee00000, 0x000000008ee00000|100%| O|  |TAMS 0x000000008ed00000, 0x000000008ed00000| Untracked 
| 238|0x000000008ee00000, 0x000000008eef9a00, 0x000000008ef00000| 97%| O|  |TAMS 0x000000008ee00000, 0x000000008ee00000| Untracked 
| 239|0x000000008ef00000, 0x000000008f000000, 0x000000008f000000|100%| O|  |TAMS 0x000000008f000000, 0x000000008ef00000| Untracked 
| 240|0x000000008f000000, 0x000000008f000000, 0x000000008f100000|  0%| F|  |TAMS 0x000000008f000000, 0x000000008f000000| Untracked 
| 241|0x000000008f100000, 0x000000008f200000, 0x000000008f200000|100%| O|  |TAMS 0x000000008f200000, 0x000000008f100000| Untracked 
| 242|0x000000008f200000, 0x000000008f300000, 0x000000008f300000|100%| O|  |TAMS 0x000000008f300000, 0x000000008f200000| Untracked 
| 243|0x000000008f300000, 0x000000008f400000, 0x000000008f400000|100%| O|  |TAMS 0x000000008f400000, 0x000000008f300000| Untracked 
| 244|0x000000008f400000, 0x000000008f500000, 0x000000008f500000|100%| O|  |TAMS 0x000000008f500000, 0x000000008f400000| Untracked 
| 245|0x000000008f500000, 0x000000008f600000, 0x000000008f600000|100%| O|  |TAMS 0x000000008f600000, 0x000000008f500000| Untracked 
| 246|0x000000008f600000, 0x000000008f700000, 0x000000008f700000|100%| O|  |TAMS 0x000000008f700000, 0x000000008f600000| Untracked 
| 247|0x000000008f700000, 0x000000008f700000, 0x000000008f800000|  0%| F|  |TAMS 0x000000008f700000, 0x000000008f700000| Untracked 
| 248|0x000000008f800000, 0x000000008f800000, 0x000000008f900000|  0%| F|  |TAMS 0x000000008f800000, 0x000000008f800000| Untracked 
| 249|0x000000008f900000, 0x000000008f900000, 0x000000008fa00000|  0%| F|  |TAMS 0x000000008f900000, 0x000000008f900000| Untracked 
| 250|0x000000008fa00000, 0x000000008fb00000, 0x000000008fb00000|100%| O|  |TAMS 0x000000008fb00000, 0x000000008fa00000| Untracked 
| 251|0x000000008fb00000, 0x000000008fc00000, 0x000000008fc00000|100%| O|  |TAMS 0x000000008fc00000, 0x000000008fb00000| Untracked 
| 252|0x000000008fc00000, 0x000000008fd00000, 0x000000008fd00000|100%| O|  |TAMS 0x000000008fd00000, 0x000000008fc00000| Untracked 
| 253|0x000000008fd00000, 0x000000008fe00000, 0x000000008fe00000|100%| O|  |TAMS 0x000000008fe00000, 0x000000008fd00000| Untracked 
| 254|0x000000008fe00000, 0x000000008ff00000, 0x000000008ff00000|100%| O|  |TAMS 0x000000008ff00000, 0x000000008fe00000| Untracked 
| 255|0x000000008ff00000, 0x0000000090000000, 0x0000000090000000|100%| O|  |TAMS 0x0000000090000000, 0x000000008ff00000| Untracked 
| 256|0x0000000090000000, 0x0000000090100000, 0x0000000090100000|100%| O|  |TAMS 0x0000000090100000, 0x0000000090000000| Untracked 
| 257|0x0000000090100000, 0x0000000090200000, 0x0000000090200000|100%| O|  |TAMS 0x0000000090200000, 0x0000000090100000| Untracked 
| 258|0x0000000090200000, 0x0000000090300000, 0x0000000090300000|100%| O|  |TAMS 0x0000000090300000, 0x0000000090200000| Untracked 
| 259|0x0000000090300000, 0x0000000090400000, 0x0000000090400000|100%| O|  |TAMS 0x0000000090400000, 0x0000000090300000| Untracked 
| 260|0x0000000090400000, 0x0000000090500000, 0x0000000090500000|100%| O|  |TAMS 0x0000000090500000, 0x0000000090400000| Untracked 
| 261|0x0000000090500000, 0x0000000090600000, 0x0000000090600000|100%| O|  |TAMS 0x0000000090600000, 0x0000000090500000| Untracked 
| 262|0x0000000090600000, 0x0000000090700000, 0x0000000090700000|100%| O|  |TAMS 0x0000000090700000, 0x0000000090600000| Untracked 
| 263|0x0000000090700000, 0x0000000090800000, 0x0000000090800000|100%| O|  |TAMS 0x0000000090800000, 0x0000000090700000| Untracked 
| 264|0x0000000090800000, 0x0000000090900000, 0x0000000090900000|100%| O|  |TAMS 0x0000000090900000, 0x0000000090800000| Untracked 
| 265|0x0000000090900000, 0x0000000090a00000, 0x0000000090a00000|100%| O|  |TAMS 0x0000000090a00000, 0x0000000090900000| Untracked 
| 266|0x0000000090a00000, 0x0000000090b00000, 0x0000000090b00000|100%| O|  |TAMS 0x0000000090b00000, 0x0000000090a00000| Untracked 
| 267|0x0000000090b00000, 0x0000000090b00000, 0x0000000090c00000|  0%| F|  |TAMS 0x0000000090b00000, 0x0000000090b00000| Untracked 
| 268|0x0000000090c00000, 0x0000000090d00000, 0x0000000090d00000|100%| O|  |TAMS 0x0000000090d00000, 0x0000000090c00000| Untracked 
| 269|0x0000000090d00000, 0x0000000090e00000, 0x0000000090e00000|100%| O|  |TAMS 0x0000000090e00000, 0x0000000090d00000| Untracked 
| 270|0x0000000090e00000, 0x0000000090e00000, 0x0000000090f00000|  0%| F|  |TAMS 0x0000000090e00000, 0x0000000090e00000| Untracked 
| 271|0x0000000090f00000, 0x0000000091000000, 0x0000000091000000|100%| O|  |TAMS 0x0000000091000000, 0x0000000090f00000| Untracked 
| 272|0x0000000091000000, 0x0000000091100000, 0x0000000091100000|100%| O|  |TAMS 0x0000000091100000, 0x0000000091000000| Untracked 
| 273|0x0000000091100000, 0x0000000091200000, 0x0000000091200000|100%| O|  |TAMS 0x0000000091200000, 0x0000000091100000| Untracked 
| 274|0x0000000091200000, 0x0000000091300000, 0x0000000091300000|100%| O|  |TAMS 0x0000000091300000, 0x0000000091200000| Untracked 
| 275|0x0000000091300000, 0x0000000091400000, 0x0000000091400000|100%| O|  |TAMS 0x0000000091400000, 0x0000000091300000| Untracked 
| 276|0x0000000091400000, 0x0000000091400000, 0x0000000091500000|  0%| F|  |TAMS 0x0000000091400000, 0x0000000091400000| Untracked 
| 277|0x0000000091500000, 0x0000000091500000, 0x0000000091600000|  0%| F|  |TAMS 0x0000000091500000, 0x0000000091500000| Untracked 
| 278|0x0000000091600000, 0x0000000091700000, 0x0000000091700000|100%| O|  |TAMS 0x0000000091700000, 0x0000000091600000| Untracked 
| 279|0x0000000091700000, 0x0000000091800000, 0x0000000091800000|100%| O|  |TAMS 0x0000000091800000, 0x0000000091700000| Untracked 
| 280|0x0000000091800000, 0x0000000091900000, 0x0000000091900000|100%| O|  |TAMS 0x0000000091900000, 0x0000000091800000| Untracked 
| 281|0x0000000091900000, 0x0000000091a00000, 0x0000000091a00000|100%| O|  |TAMS 0x0000000091a00000, 0x0000000091900000| Untracked 
| 282|0x0000000091a00000, 0x0000000091b00000, 0x0000000091b00000|100%| O|  |TAMS 0x0000000091b00000, 0x0000000091a00000| Untracked 
| 283|0x0000000091b00000, 0x0000000091c00000, 0x0000000091c00000|100%| O|  |TAMS 0x0000000091c00000, 0x0000000091b00000| Untracked 
| 284|0x0000000091c00000, 0x0000000091d00000, 0x0000000091d00000|100%| O|  |TAMS 0x0000000091d00000, 0x0000000091c00000| Untracked 
| 285|0x0000000091d00000, 0x0000000091e00000, 0x0000000091e00000|100%| O|  |TAMS 0x0000000091e00000, 0x0000000091d00000| Untracked 
| 286|0x0000000091e00000, 0x0000000091f00000, 0x0000000091f00000|100%| O|  |TAMS 0x0000000091f00000, 0x0000000091e00000| Untracked 
| 287|0x0000000091f00000, 0x0000000092000000, 0x0000000092000000|100%| O|  |TAMS 0x0000000092000000, 0x0000000091f00000| Untracked 
| 288|0x0000000092000000, 0x0000000092000000, 0x0000000092100000|  0%| F|  |TAMS 0x0000000092000000, 0x0000000092000000| Untracked 
| 289|0x0000000092100000, 0x0000000092200000, 0x0000000092200000|100%| O|  |TAMS 0x0000000092200000, 0x0000000092100000| Untracked 
| 290|0x0000000092200000, 0x0000000092300000, 0x0000000092300000|100%| O|  |TAMS 0x0000000092300000, 0x0000000092200000| Untracked 
| 291|0x0000000092300000, 0x0000000092400000, 0x0000000092400000|100%| O|  |TAMS 0x0000000092400000, 0x0000000092300000| Untracked 
| 292|0x0000000092400000, 0x0000000092500000, 0x0000000092500000|100%| O|  |TAMS 0x0000000092500000, 0x0000000092400000| Untracked 
| 293|0x0000000092500000, 0x0000000092600000, 0x0000000092600000|100%| O|  |TAMS 0x0000000092600000, 0x0000000092500000| Untracked 
| 294|0x0000000092600000, 0x0000000092700000, 0x0000000092700000|100%| O|  |TAMS 0x0000000092700000, 0x0000000092600000| Untracked 
| 295|0x0000000092700000, 0x0000000092700000, 0x0000000092800000|  0%| F|  |TAMS 0x0000000092700000, 0x0000000092700000| Untracked 
| 296|0x0000000092800000, 0x0000000092800000, 0x0000000092900000|  0%| F|  |TAMS 0x0000000092800000, 0x0000000092800000| Untracked 
| 297|0x0000000092900000, 0x0000000092a00000, 0x0000000092a00000|100%| O|  |TAMS 0x0000000092a00000, 0x0000000092900000| Untracked 
| 298|0x0000000092a00000, 0x0000000092b00000, 0x0000000092b00000|100%| O|  |TAMS 0x0000000092b00000, 0x0000000092a00000| Untracked 
| 299|0x0000000092b00000, 0x0000000092c00000, 0x0000000092c00000|100%| O|  |TAMS 0x0000000092c00000, 0x0000000092b00000| Untracked 
| 300|0x0000000092c00000, 0x0000000092d00000, 0x0000000092d00000|100%| O|  |TAMS 0x0000000092d00000, 0x0000000092c00000| Untracked 
| 301|0x0000000092d00000, 0x0000000092e00000, 0x0000000092e00000|100%| O|  |TAMS 0x0000000092e00000, 0x0000000092d00000| Untracked 
| 302|0x0000000092e00000, 0x0000000092f00000, 0x0000000092f00000|100%| O|  |TAMS 0x0000000092f00000, 0x0000000092e00000| Untracked 
| 303|0x0000000092f00000, 0x0000000093000000, 0x0000000093000000|100%| O|  |TAMS 0x0000000093000000, 0x0000000092f00000| Untracked 
| 304|0x0000000093000000, 0x0000000093100000, 0x0000000093100000|100%| O|  |TAMS 0x0000000093100000, 0x0000000093000000| Untracked 
| 305|0x0000000093100000, 0x0000000093200000, 0x0000000093200000|100%| O|  |TAMS 0x0000000093200000, 0x0000000093100000| Untracked 
| 306|0x0000000093200000, 0x0000000093300000, 0x0000000093300000|100%| O|  |TAMS 0x0000000093300000, 0x0000000093200000| Untracked 
| 307|0x0000000093300000, 0x0000000093400000, 0x0000000093400000|100%| O|  |TAMS 0x0000000093400000, 0x0000000093300000| Untracked 
| 308|0x0000000093400000, 0x0000000093400000, 0x0000000093500000|  0%| F|  |TAMS 0x0000000093400000, 0x0000000093400000| Untracked 
| 309|0x0000000093500000, 0x0000000093500000, 0x0000000093600000|  0%| F|  |TAMS 0x0000000093500000, 0x0000000093500000| Untracked 
| 310|0x0000000093600000, 0x0000000093700000, 0x0000000093700000|100%| O|  |TAMS 0x0000000093700000, 0x0000000093600000| Untracked 
| 311|0x0000000093700000, 0x0000000093700000, 0x0000000093800000|  0%| F|  |TAMS 0x0000000093700000, 0x0000000093700000| Untracked 
| 312|0x0000000093800000, 0x0000000093900000, 0x0000000093900000|100%| O|  |TAMS 0x0000000093900000, 0x0000000093800000| Untracked 
| 313|0x0000000093900000, 0x0000000093a00000, 0x0000000093a00000|100%| O|  |TAMS 0x0000000093a00000, 0x0000000093900000| Untracked 
| 314|0x0000000093a00000, 0x0000000093b00000, 0x0000000093b00000|100%| O|  |TAMS 0x0000000093b00000, 0x0000000093a00000| Untracked 
| 315|0x0000000093b00000, 0x0000000093b00000, 0x0000000093c00000|  0%| F|  |TAMS 0x0000000093b00000, 0x0000000093b00000| Untracked 
| 316|0x0000000093c00000, 0x0000000093c00000, 0x0000000093d00000|  0%| F|  |TAMS 0x0000000093c00000, 0x0000000093c00000| Untracked 
| 317|0x0000000093d00000, 0x0000000093d00000, 0x0000000093e00000|  0%| F|  |TAMS 0x0000000093d00000, 0x0000000093d00000| Untracked 
| 318|0x0000000093e00000, 0x0000000093f00000, 0x0000000093f00000|100%| O|  |TAMS 0x0000000093f00000, 0x0000000093e00000| Untracked 
| 319|0x0000000093f00000, 0x0000000094000000, 0x0000000094000000|100%| O|  |TAMS 0x0000000094000000, 0x0000000093f00000| Untracked 
| 320|0x0000000094000000, 0x0000000094100000, 0x0000000094100000|100%| O|  |TAMS 0x0000000094100000, 0x0000000094000000| Untracked 
| 321|0x0000000094100000, 0x0000000094200000, 0x0000000094200000|100%| O|  |TAMS 0x0000000094200000, 0x0000000094100000| Untracked 
| 322|0x0000000094200000, 0x0000000094300000, 0x0000000094300000|100%| O|  |TAMS 0x0000000094300000, 0x0000000094200000| Untracked 
| 323|0x0000000094300000, 0x0000000094400000, 0x0000000094400000|100%| O|  |TAMS 0x0000000094400000, 0x0000000094300000| Untracked 
| 324|0x0000000094400000, 0x0000000094500000, 0x0000000094500000|100%| O|  |TAMS 0x0000000094500000, 0x0000000094400000| Untracked 
| 325|0x0000000094500000, 0x0000000094600000, 0x0000000094600000|100%| O|  |TAMS 0x0000000094600000, 0x0000000094500000| Untracked 
| 326|0x0000000094600000, 0x0000000094700000, 0x0000000094700000|100%| O|  |TAMS 0x0000000094700000, 0x0000000094600000| Untracked 
| 327|0x0000000094700000, 0x0000000094800000, 0x0000000094800000|100%| O|  |TAMS 0x0000000094800000, 0x0000000094700000| Untracked 
| 328|0x0000000094800000, 0x0000000094900000, 0x0000000094900000|100%| O|  |TAMS 0x0000000094900000, 0x0000000094800000| Untracked 
| 329|0x0000000094900000, 0x0000000094a00000, 0x0000000094a00000|100%| O|  |TAMS 0x0000000094a00000, 0x0000000094900000| Untracked 
| 330|0x0000000094a00000, 0x0000000094b00000, 0x0000000094b00000|100%| O|  |TAMS 0x0000000094b00000, 0x0000000094a00000| Untracked 
| 331|0x0000000094b00000, 0x0000000094c00000, 0x0000000094c00000|100%| O|  |TAMS 0x0000000094c00000, 0x0000000094b00000| Untracked 
| 332|0x0000000094c00000, 0x0000000094c00000, 0x0000000094d00000|  0%| F|  |TAMS 0x0000000094c00000, 0x0000000094c00000| Untracked 
| 333|0x0000000094d00000, 0x0000000094e00000, 0x0000000094e00000|100%|HS|  |TAMS 0x0000000094e00000, 0x0000000094d00000| Complete 
| 334|0x0000000094e00000, 0x0000000094f00000, 0x0000000094f00000|100%|HC|  |TAMS 0x0000000094f00000, 0x0000000094e00000| Complete 
| 335|0x0000000094f00000, 0x0000000095000000, 0x0000000095000000|100%| O|  |TAMS 0x0000000095000000, 0x0000000094f00000| Untracked 
| 336|0x0000000095000000, 0x0000000095100000, 0x0000000095100000|100%| O|  |TAMS 0x0000000095100000, 0x0000000095000000| Untracked 
| 337|0x0000000095100000, 0x0000000095200000, 0x0000000095200000|100%| O|  |TAMS 0x0000000095200000, 0x0000000095100000| Untracked 
| 338|0x0000000095200000, 0x0000000095300000, 0x0000000095300000|100%| O|  |TAMS 0x0000000095300000, 0x0000000095200000| Untracked 
| 339|0x0000000095300000, 0x0000000095400000, 0x0000000095400000|100%| O|  |TAMS 0x0000000095400000, 0x0000000095300000| Untracked 
| 340|0x0000000095400000, 0x0000000095500000, 0x0000000095500000|100%| O|  |TAMS 0x0000000095500000, 0x0000000095400000| Untracked 
| 341|0x0000000095500000, 0x0000000095600000, 0x0000000095600000|100%| O|  |TAMS 0x0000000095600000, 0x0000000095500000| Untracked 
| 342|0x0000000095600000, 0x0000000095700000, 0x0000000095700000|100%| O|  |TAMS 0x0000000095700000, 0x0000000095600000| Untracked 
| 343|0x0000000095700000, 0x0000000095800000, 0x0000000095800000|100%| O|  |TAMS 0x0000000095800000, 0x0000000095700000| Untracked 
| 344|0x0000000095800000, 0x0000000095900000, 0x0000000095900000|100%| O|  |TAMS 0x0000000095900000, 0x0000000095800000| Untracked 
| 345|0x0000000095900000, 0x0000000095a00000, 0x0000000095a00000|100%| O|  |TAMS 0x0000000095a00000, 0x0000000095900000| Untracked 
| 346|0x0000000095a00000, 0x0000000095b00000, 0x0000000095b00000|100%| O|  |TAMS 0x0000000095b00000, 0x0000000095a00000| Untracked 
| 347|0x0000000095b00000, 0x0000000095c00000, 0x0000000095c00000|100%| O|  |TAMS 0x0000000095c00000, 0x0000000095b00000| Untracked 
| 348|0x0000000095c00000, 0x0000000095d00000, 0x0000000095d00000|100%| O|  |TAMS 0x0000000095d00000, 0x0000000095c00000| Untracked 
| 349|0x0000000095d00000, 0x0000000095e00000, 0x0000000095e00000|100%| O|  |TAMS 0x0000000095e00000, 0x0000000095d00000| Untracked 
| 350|0x0000000095e00000, 0x0000000095f00000, 0x0000000095f00000|100%| O|  |TAMS 0x0000000095f00000, 0x0000000095e00000| Untracked 
| 351|0x0000000095f00000, 0x0000000095f00000, 0x0000000096000000|  0%| F|  |TAMS 0x0000000095f00000, 0x0000000095f00000| Untracked 
| 352|0x0000000096000000, 0x0000000096000000, 0x0000000096100000|  0%| F|  |TAMS 0x0000000096000000, 0x0000000096000000| Untracked 
| 353|0x0000000096100000, 0x0000000096100000, 0x0000000096200000|  0%| F|  |TAMS 0x0000000096100000, 0x0000000096100000| Untracked 
| 354|0x0000000096200000, 0x0000000096300000, 0x0000000096300000|100%| O|  |TAMS 0x0000000096300000, 0x0000000096200000| Untracked 
| 355|0x0000000096300000, 0x0000000096300000, 0x0000000096400000|  0%| F|  |TAMS 0x0000000096300000, 0x0000000096300000| Untracked 
| 356|0x0000000096400000, 0x0000000096500000, 0x0000000096500000|100%| O|  |TAMS 0x0000000096500000, 0x0000000096400000| Untracked 
| 357|0x0000000096500000, 0x0000000096600000, 0x0000000096600000|100%| O|  |TAMS 0x0000000096600000, 0x0000000096500000| Untracked 
| 358|0x0000000096600000, 0x0000000096700000, 0x0000000096700000|100%| O|  |TAMS 0x0000000096700000, 0x0000000096600000| Untracked 
| 359|0x0000000096700000, 0x0000000096800000, 0x0000000096800000|100%| O|  |TAMS 0x0000000096800000, 0x0000000096700000| Untracked 
| 360|0x0000000096800000, 0x0000000096900000, 0x0000000096900000|100%| O|  |TAMS 0x0000000096900000, 0x0000000096800000| Untracked 
| 361|0x0000000096900000, 0x0000000096a00000, 0x0000000096a00000|100%| O|  |TAMS 0x0000000096a00000, 0x0000000096900000| Untracked 
| 362|0x0000000096a00000, 0x0000000096b00000, 0x0000000096b00000|100%| O|  |TAMS 0x0000000096b00000, 0x0000000096a00000| Untracked 
| 363|0x0000000096b00000, 0x0000000096c00000, 0x0000000096c00000|100%| O|  |TAMS 0x0000000096c00000, 0x0000000096b00000| Untracked 
| 364|0x0000000096c00000, 0x0000000096d00000, 0x0000000096d00000|100%| O|  |TAMS 0x0000000096d00000, 0x0000000096c00000| Untracked 
| 365|0x0000000096d00000, 0x0000000096e00000, 0x0000000096e00000|100%|HS|  |TAMS 0x0000000096e00000, 0x0000000096d00000| Complete 
| 366|0x0000000096e00000, 0x0000000096f00000, 0x0000000096f00000|100%|HC|  |TAMS 0x0000000096f00000, 0x0000000096e00000| Complete 
| 367|0x0000000096f00000, 0x0000000097000000, 0x0000000097000000|100%|HC|  |TAMS 0x0000000097000000, 0x0000000096f00000| Complete 
| 368|0x0000000097000000, 0x0000000097100000, 0x0000000097100000|100%|HC|  |TAMS 0x0000000097100000, 0x0000000097000000| Complete 
| 369|0x0000000097100000, 0x0000000097200000, 0x0000000097200000|100%|HC|  |TAMS 0x0000000097200000, 0x0000000097100000| Complete 
| 370|0x0000000097200000, 0x0000000097300000, 0x0000000097300000|100%|HC|  |TAMS 0x0000000097300000, 0x0000000097200000| Complete 
| 371|0x0000000097300000, 0x0000000097400000, 0x0000000097400000|100%|HC|  |TAMS 0x0000000097400000, 0x0000000097300000| Complete 
| 372|0x0000000097400000, 0x0000000097500000, 0x0000000097500000|100%|HC|  |TAMS 0x0000000097500000, 0x0000000097400000| Complete 
| 373|0x0000000097500000, 0x0000000097600000, 0x0000000097600000|100%|HC|  |TAMS 0x0000000097600000, 0x0000000097500000| Complete 
| 374|0x0000000097600000, 0x0000000097700000, 0x0000000097700000|100%|HC|  |TAMS 0x0000000097700000, 0x0000000097600000| Complete 
| 375|0x0000000097700000, 0x0000000097800000, 0x0000000097800000|100%|HC|  |TAMS 0x0000000097800000, 0x0000000097700000| Complete 
| 376|0x0000000097800000, 0x0000000097900000, 0x0000000097900000|100%|HC|  |TAMS 0x0000000097900000, 0x0000000097800000| Complete 
| 377|0x0000000097900000, 0x0000000097a00000, 0x0000000097a00000|100%| O|  |TAMS 0x0000000097a00000, 0x0000000097900000| Untracked 
| 378|0x0000000097a00000, 0x0000000097a00000, 0x0000000097b00000|  0%| F|  |TAMS 0x0000000097a00000, 0x0000000097a00000| Untracked 
| 379|0x0000000097b00000, 0x0000000097b00000, 0x0000000097c00000|  0%| F|  |TAMS 0x0000000097b00000, 0x0000000097b00000| Untracked 
| 380|0x0000000097c00000, 0x0000000097c00000, 0x0000000097d00000|  0%| F|  |TAMS 0x0000000097c00000, 0x0000000097c00000| Untracked 
| 381|0x0000000097d00000, 0x0000000097d00000, 0x0000000097e00000|  0%| F|  |TAMS 0x0000000097d00000, 0x0000000097d00000| Untracked 
| 382|0x0000000097e00000, 0x0000000097e00000, 0x0000000097f00000|  0%| F|  |TAMS 0x0000000097e00000, 0x0000000097e00000| Untracked 
| 383|0x0000000097f00000, 0x0000000097f00000, 0x0000000098000000|  0%| F|  |TAMS 0x0000000097f00000, 0x0000000097f00000| Untracked 
| 384|0x0000000098000000, 0x0000000098100000, 0x0000000098100000|100%| O|  |TAMS 0x00000000980d9600, 0x0000000098000000| Untracked 
| 385|0x0000000098100000, 0x0000000098200000, 0x0000000098200000|100%| O|  |TAMS 0x0000000098200000, 0x0000000098100000| Untracked 
| 386|0x0000000098200000, 0x0000000098200000, 0x0000000098300000|  0%| F|  |TAMS 0x0000000098200000, 0x0000000098200000| Untracked 
| 387|0x0000000098300000, 0x0000000098300000, 0x0000000098400000|  0%| F|  |TAMS 0x0000000098300000, 0x0000000098300000| Untracked 
| 388|0x0000000098400000, 0x0000000098400000, 0x0000000098500000|  0%| F|  |TAMS 0x0000000098400000, 0x0000000098400000| Untracked 
| 389|0x0000000098500000, 0x0000000098500000, 0x0000000098600000|  0%| F|  |TAMS 0x0000000098500000, 0x0000000098500000| Untracked 
| 390|0x0000000098600000, 0x0000000098600000, 0x0000000098700000|  0%| F|  |TAMS 0x0000000098600000, 0x0000000098600000| Untracked 
| 391|0x0000000098700000, 0x0000000098700000, 0x0000000098800000|  0%| F|  |TAMS 0x0000000098700000, 0x0000000098700000| Untracked 
| 392|0x0000000098800000, 0x0000000098900000, 0x0000000098900000|100%| O|  |TAMS 0x0000000098900000, 0x0000000098800000| Untracked 
| 393|0x0000000098900000, 0x0000000098a00000, 0x0000000098a00000|100%| O|  |TAMS 0x0000000098a00000, 0x0000000098900000| Untracked 
| 394|0x0000000098a00000, 0x0000000098b00000, 0x0000000098b00000|100%| O|  |TAMS 0x0000000098b00000, 0x0000000098a00000| Untracked 
| 395|0x0000000098b00000, 0x0000000098c00000, 0x0000000098c00000|100%| O|  |TAMS 0x0000000098c00000, 0x0000000098b00000| Untracked 
| 396|0x0000000098c00000, 0x0000000098c00000, 0x0000000098d00000|  0%| F|  |TAMS 0x0000000098c00000, 0x0000000098c00000| Untracked 
| 397|0x0000000098d00000, 0x0000000098d00000, 0x0000000098e00000|  0%| F|  |TAMS 0x0000000098d00000, 0x0000000098d00000| Untracked 
| 398|0x0000000098e00000, 0x0000000098e00000, 0x0000000098f00000|  0%| F|  |TAMS 0x0000000098e00000, 0x0000000098e00000| Untracked 
| 399|0x0000000098f00000, 0x0000000098f00000, 0x0000000099000000|  0%| F|  |TAMS 0x0000000098f00000, 0x0000000098f00000| Untracked 
| 400|0x0000000099000000, 0x0000000099000000, 0x0000000099100000|  0%| F|  |TAMS 0x0000000099000000, 0x0000000099000000| Untracked 
| 401|0x0000000099100000, 0x0000000099100000, 0x0000000099200000|  0%| F|  |TAMS 0x0000000099100000, 0x0000000099100000| Untracked 
| 402|0x0000000099200000, 0x0000000099200000, 0x0000000099300000|  0%| F|  |TAMS 0x0000000099200000, 0x0000000099200000| Untracked 
| 403|0x0000000099300000, 0x0000000099300000, 0x0000000099400000|  0%| F|  |TAMS 0x0000000099300000, 0x0000000099300000| Untracked 
| 404|0x0000000099400000, 0x0000000099400000, 0x0000000099500000|  0%| F|  |TAMS 0x0000000099400000, 0x0000000099400000| Untracked 
| 405|0x0000000099500000, 0x0000000099600000, 0x0000000099600000|100%| O|  |TAMS 0x0000000099600000, 0x0000000099500000| Untracked 
| 406|0x0000000099600000, 0x0000000099600000, 0x0000000099700000|  0%| F|  |TAMS 0x0000000099600000, 0x0000000099600000| Untracked 
| 407|0x0000000099700000, 0x0000000099700000, 0x0000000099800000|  0%| F|  |TAMS 0x0000000099700000, 0x0000000099700000| Untracked 
| 408|0x0000000099800000, 0x0000000099800000, 0x0000000099900000|  0%| F|  |TAMS 0x0000000099800000, 0x0000000099800000| Untracked 
| 409|0x0000000099900000, 0x0000000099900000, 0x0000000099a00000|  0%| F|  |TAMS 0x0000000099900000, 0x0000000099900000| Untracked 
| 410|0x0000000099a00000, 0x0000000099a00000, 0x0000000099b00000|  0%| F|  |TAMS 0x0000000099a00000, 0x0000000099a00000| Untracked 
| 411|0x0000000099b00000, 0x0000000099b00000, 0x0000000099c00000|  0%| F|  |TAMS 0x0000000099b00000, 0x0000000099b00000| Untracked 
| 412|0x0000000099c00000, 0x0000000099c00000, 0x0000000099d00000|  0%| F|  |TAMS 0x0000000099c00000, 0x0000000099c00000| Untracked 
| 413|0x0000000099d00000, 0x0000000099d00000, 0x0000000099e00000|  0%| F|  |TAMS 0x0000000099d00000, 0x0000000099d00000| Untracked 
| 414|0x0000000099e00000, 0x0000000099e00000, 0x0000000099f00000|  0%| F|  |TAMS 0x0000000099e00000, 0x0000000099e00000| Untracked 
| 415|0x0000000099f00000, 0x0000000099f00000, 0x000000009a000000|  0%| F|  |TAMS 0x0000000099f00000, 0x0000000099f00000| Untracked 
| 416|0x000000009a000000, 0x000000009a000000, 0x000000009a100000|  0%| F|  |TAMS 0x000000009a000000, 0x000000009a000000| Untracked 
| 417|0x000000009a100000, 0x000000009a100000, 0x000000009a200000|  0%| F|  |TAMS 0x000000009a100000, 0x000000009a100000| Untracked 
| 418|0x000000009a200000, 0x000000009a200000, 0x000000009a300000|  0%| F|  |TAMS 0x000000009a200000, 0x000000009a200000| Untracked 
| 419|0x000000009a300000, 0x000000009a300000, 0x000000009a400000|  0%| F|  |TAMS 0x000000009a300000, 0x000000009a300000| Untracked 
| 420|0x000000009a400000, 0x000000009a400000, 0x000000009a500000|  0%| F|  |TAMS 0x000000009a400000, 0x000000009a400000| Untracked 
| 421|0x000000009a500000, 0x000000009a500000, 0x000000009a600000|  0%| F|  |TAMS 0x000000009a500000, 0x000000009a500000| Untracked 
| 422|0x000000009a600000, 0x000000009a600000, 0x000000009a700000|  0%| F|  |TAMS 0x000000009a600000, 0x000000009a600000| Untracked 
| 423|0x000000009a700000, 0x000000009a700000, 0x000000009a800000|  0%| F|  |TAMS 0x000000009a700000, 0x000000009a700000| Untracked 
| 424|0x000000009a800000, 0x000000009a800000, 0x000000009a900000|  0%| F|  |TAMS 0x000000009a800000, 0x000000009a800000| Untracked 
| 425|0x000000009a900000, 0x000000009a900000, 0x000000009aa00000|  0%| F|  |TAMS 0x000000009a900000, 0x000000009a900000| Untracked 
| 426|0x000000009aa00000, 0x000000009aa00000, 0x000000009ab00000|  0%| F|  |TAMS 0x000000009aa00000, 0x000000009aa00000| Untracked 
| 427|0x000000009ab00000, 0x000000009ab00000, 0x000000009ac00000|  0%| F|  |TAMS 0x000000009ab00000, 0x000000009ab00000| Untracked 
| 428|0x000000009ac00000, 0x000000009ac00000, 0x000000009ad00000|  0%| F|  |TAMS 0x000000009ac00000, 0x000000009ac00000| Untracked 
| 429|0x000000009ad00000, 0x000000009ad00000, 0x000000009ae00000|  0%| F|  |TAMS 0x000000009ad00000, 0x000000009ad00000| Untracked 
| 430|0x000000009ae00000, 0x000000009ae00000, 0x000000009af00000|  0%| F|  |TAMS 0x000000009ae00000, 0x000000009ae00000| Untracked 
| 431|0x000000009af00000, 0x000000009af00000, 0x000000009b000000|  0%| F|  |TAMS 0x000000009af00000, 0x000000009af00000| Untracked 
| 432|0x000000009b000000, 0x000000009b000000, 0x000000009b100000|  0%| F|  |TAMS 0x000000009b000000, 0x000000009b000000| Untracked 
| 433|0x000000009b100000, 0x000000009b100000, 0x000000009b200000|  0%| F|  |TAMS 0x000000009b100000, 0x000000009b100000| Untracked 
| 434|0x000000009b200000, 0x000000009b200000, 0x000000009b300000|  0%| F|  |TAMS 0x000000009b200000, 0x000000009b200000| Untracked 
| 435|0x000000009b300000, 0x000000009b300000, 0x000000009b400000|  0%| F|  |TAMS 0x000000009b300000, 0x000000009b300000| Untracked 
| 436|0x000000009b400000, 0x000000009b400000, 0x000000009b500000|  0%| F|  |TAMS 0x000000009b400000, 0x000000009b400000| Untracked 
| 437|0x000000009b500000, 0x000000009b500000, 0x000000009b600000|  0%| F|  |TAMS 0x000000009b500000, 0x000000009b500000| Untracked 
| 438|0x000000009b600000, 0x000000009b600000, 0x000000009b700000|  0%| F|  |TAMS 0x000000009b600000, 0x000000009b600000| Untracked 
| 439|0x000000009b700000, 0x000000009b700000, 0x000000009b800000|  0%| F|  |TAMS 0x000000009b700000, 0x000000009b700000| Untracked 
| 440|0x000000009b800000, 0x000000009b800000, 0x000000009b900000|  0%| F|  |TAMS 0x000000009b800000, 0x000000009b800000| Untracked 
| 441|0x000000009b900000, 0x000000009b900000, 0x000000009ba00000|  0%| F|  |TAMS 0x000000009b900000, 0x000000009b900000| Untracked 
| 442|0x000000009ba00000, 0x000000009ba00000, 0x000000009bb00000|  0%| F|  |TAMS 0x000000009ba00000, 0x000000009ba00000| Untracked 
| 443|0x000000009bb00000, 0x000000009bb00000, 0x000000009bc00000|  0%| F|  |TAMS 0x000000009bb00000, 0x000000009bb00000| Untracked 
| 444|0x000000009bc00000, 0x000000009bc00000, 0x000000009bd00000|  0%| F|  |TAMS 0x000000009bc00000, 0x000000009bc00000| Untracked 
| 445|0x000000009bd00000, 0x000000009bd00000, 0x000000009be00000|  0%| F|  |TAMS 0x000000009bd00000, 0x000000009bd00000| Untracked 
| 446|0x000000009be00000, 0x000000009be00000, 0x000000009bf00000|  0%| F|  |TAMS 0x000000009be00000, 0x000000009be00000| Untracked 
| 447|0x000000009bf00000, 0x000000009bf00000, 0x000000009c000000|  0%| F|  |TAMS 0x000000009bf00000, 0x000000009bf00000| Untracked 
| 448|0x000000009c000000, 0x000000009c000000, 0x000000009c100000|  0%| F|  |TAMS 0x000000009c000000, 0x000000009c000000| Untracked 
| 449|0x000000009c100000, 0x000000009c100000, 0x000000009c200000|  0%| F|  |TAMS 0x000000009c100000, 0x000000009c100000| Untracked 
| 450|0x000000009c200000, 0x000000009c200000, 0x000000009c300000|  0%| F|  |TAMS 0x000000009c200000, 0x000000009c200000| Untracked 
| 451|0x000000009c300000, 0x000000009c300000, 0x000000009c400000|  0%| F|  |TAMS 0x000000009c300000, 0x000000009c300000| Untracked 
| 452|0x000000009c400000, 0x000000009c400000, 0x000000009c500000|  0%| F|  |TAMS 0x000000009c400000, 0x000000009c400000| Untracked 
| 453|0x000000009c500000, 0x000000009c500000, 0x000000009c600000|  0%| F|  |TAMS 0x000000009c500000, 0x000000009c500000| Untracked 
| 454|0x000000009c600000, 0x000000009c600000, 0x000000009c700000|  0%| F|  |TAMS 0x000000009c600000, 0x000000009c600000| Untracked 
| 455|0x000000009c700000, 0x000000009c700000, 0x000000009c800000|  0%| F|  |TAMS 0x000000009c700000, 0x000000009c700000| Untracked 
| 456|0x000000009c800000, 0x000000009c800000, 0x000000009c900000|  0%| F|  |TAMS 0x000000009c800000, 0x000000009c800000| Untracked 
| 457|0x000000009c900000, 0x000000009c900000, 0x000000009ca00000|  0%| F|  |TAMS 0x000000009c900000, 0x000000009c900000| Untracked 
| 458|0x000000009ca00000, 0x000000009ca00000, 0x000000009cb00000|  0%| F|  |TAMS 0x000000009ca00000, 0x000000009ca00000| Untracked 
| 459|0x000000009cb00000, 0x000000009cc00000, 0x000000009cc00000|100%| O|  |TAMS 0x000000009cc00000, 0x000000009cb00000| Untracked 
| 460|0x000000009cc00000, 0x000000009cd00000, 0x000000009cd00000|100%| O|  |TAMS 0x000000009cd00000, 0x000000009cc00000| Untracked 
| 461|0x000000009cd00000, 0x000000009ce00000, 0x000000009ce00000|100%| O|  |TAMS 0x000000009ce00000, 0x000000009cd00000| Untracked 
| 462|0x000000009ce00000, 0x000000009cf00000, 0x000000009cf00000|100%| O|  |TAMS 0x000000009cf00000, 0x000000009ce00000| Untracked 
| 463|0x000000009cf00000, 0x000000009d000000, 0x000000009d000000|100%| O|  |TAMS 0x000000009d000000, 0x000000009cf00000| Untracked 
| 464|0x000000009d000000, 0x000000009d100000, 0x000000009d100000|100%| O|  |TAMS 0x000000009d100000, 0x000000009d000000| Untracked 
| 465|0x000000009d100000, 0x000000009d200000, 0x000000009d200000|100%| O|  |TAMS 0x000000009d200000, 0x000000009d100000| Untracked 
| 466|0x000000009d200000, 0x000000009d300000, 0x000000009d300000|100%| O|  |TAMS 0x000000009d300000, 0x000000009d200000| Untracked 
| 467|0x000000009d300000, 0x000000009d400000, 0x000000009d400000|100%| O|  |TAMS 0x000000009d400000, 0x000000009d300000| Untracked 
| 468|0x000000009d400000, 0x000000009d500000, 0x000000009d500000|100%| O|  |TAMS 0x000000009d500000, 0x000000009d400000| Untracked 
| 469|0x000000009d500000, 0x000000009d600000, 0x000000009d600000|100%| O|  |TAMS 0x000000009d600000, 0x000000009d500000| Untracked 
| 470|0x000000009d600000, 0x000000009d700000, 0x000000009d700000|100%| O|  |TAMS 0x000000009d700000, 0x000000009d600000| Untracked 
| 471|0x000000009d700000, 0x000000009d700000, 0x000000009d800000|  0%| F|  |TAMS 0x000000009d700000, 0x000000009d700000| Untracked 
| 472|0x000000009d800000, 0x000000009d800000, 0x000000009d900000|  0%| F|  |TAMS 0x000000009d800000, 0x000000009d800000| Untracked 
| 473|0x000000009d900000, 0x000000009d900000, 0x000000009da00000|  0%| F|  |TAMS 0x000000009d900000, 0x000000009d900000| Untracked 
| 474|0x000000009da00000, 0x000000009da00000, 0x000000009db00000|  0%| F|  |TAMS 0x000000009da00000, 0x000000009da00000| Untracked 
| 475|0x000000009db00000, 0x000000009db00000, 0x000000009dc00000|  0%| F|  |TAMS 0x000000009db00000, 0x000000009db00000| Untracked 
| 476|0x000000009dc00000, 0x000000009dc00000, 0x000000009dd00000|  0%| F|  |TAMS 0x000000009dc00000, 0x000000009dc00000| Untracked 
| 477|0x000000009dd00000, 0x000000009dd00000, 0x000000009de00000|  0%| F|  |TAMS 0x000000009dd00000, 0x000000009dd00000| Untracked 
| 478|0x000000009de00000, 0x000000009de00000, 0x000000009df00000|  0%| F|  |TAMS 0x000000009de00000, 0x000000009de00000| Untracked 
| 479|0x000000009df00000, 0x000000009df00000, 0x000000009e000000|  0%| F|  |TAMS 0x000000009df00000, 0x000000009df00000| Untracked 
| 480|0x000000009e000000, 0x000000009e000000, 0x000000009e100000|  0%| F|  |TAMS 0x000000009e000000, 0x000000009e000000| Untracked 
| 481|0x000000009e100000, 0x000000009e100000, 0x000000009e200000|  0%| F|  |TAMS 0x000000009e100000, 0x000000009e100000| Untracked 
| 482|0x000000009e200000, 0x000000009e200000, 0x000000009e300000|  0%| F|  |TAMS 0x000000009e200000, 0x000000009e200000| Untracked 
| 483|0x000000009e300000, 0x000000009e300000, 0x000000009e400000|  0%| F|  |TAMS 0x000000009e300000, 0x000000009e300000| Untracked 
| 484|0x000000009e400000, 0x000000009e400000, 0x000000009e500000|  0%| F|  |TAMS 0x000000009e400000, 0x000000009e400000| Untracked 
| 485|0x000000009e500000, 0x000000009e500000, 0x000000009e600000|  0%| F|  |TAMS 0x000000009e500000, 0x000000009e500000| Untracked 
| 486|0x000000009e600000, 0x000000009e600000, 0x000000009e700000|  0%| F|  |TAMS 0x000000009e600000, 0x000000009e600000| Untracked 
| 487|0x000000009e700000, 0x000000009e700000, 0x000000009e800000|  0%| F|  |TAMS 0x000000009e700000, 0x000000009e700000| Untracked 
| 488|0x000000009e800000, 0x000000009e800000, 0x000000009e900000|  0%| F|  |TAMS 0x000000009e800000, 0x000000009e800000| Untracked 
| 489|0x000000009e900000, 0x000000009ea00000, 0x000000009ea00000|100%|HS|  |TAMS 0x000000009ea00000, 0x000000009e900000| Complete 
| 490|0x000000009ea00000, 0x000000009eb00000, 0x000000009eb00000|100%|HC|  |TAMS 0x000000009eb00000, 0x000000009ea00000| Complete 
| 491|0x000000009eb00000, 0x000000009ec00000, 0x000000009ec00000|100%|HC|  |TAMS 0x000000009ec00000, 0x000000009eb00000| Complete 
| 492|0x000000009ec00000, 0x000000009ed00000, 0x000000009ed00000|100%|HC|  |TAMS 0x000000009ed00000, 0x000000009ec00000| Complete 
| 493|0x000000009ed00000, 0x000000009ee00000, 0x000000009ee00000|100%|HC|  |TAMS 0x000000009ee00000, 0x000000009ed00000| Complete 
| 494|0x000000009ee00000, 0x000000009ee00000, 0x000000009ef00000|  0%| F|  |TAMS 0x000000009ee00000, 0x000000009ee00000| Untracked 
| 495|0x000000009ef00000, 0x000000009ef00000, 0x000000009f000000|  0%| F|  |TAMS 0x000000009ef00000, 0x000000009ef00000| Untracked 
| 496|0x000000009f000000, 0x000000009f000000, 0x000000009f100000|  0%| F|  |TAMS 0x000000009f000000, 0x000000009f000000| Untracked 
| 497|0x000000009f100000, 0x000000009f100000, 0x000000009f200000|  0%| F|  |TAMS 0x000000009f100000, 0x000000009f100000| Untracked 
| 498|0x000000009f200000, 0x000000009f200000, 0x000000009f300000|  0%| F|  |TAMS 0x000000009f200000, 0x000000009f200000| Untracked 
| 499|0x000000009f300000, 0x000000009f300000, 0x000000009f400000|  0%| F|  |TAMS 0x000000009f300000, 0x000000009f300000| Untracked 
| 500|0x000000009f400000, 0x000000009f400000, 0x000000009f500000|  0%| F|  |TAMS 0x000000009f400000, 0x000000009f400000| Untracked 
| 501|0x000000009f500000, 0x000000009f500000, 0x000000009f600000|  0%| F|  |TAMS 0x000000009f500000, 0x000000009f500000| Untracked 
| 502|0x000000009f600000, 0x000000009f600000, 0x000000009f700000|  0%| F|  |TAMS 0x000000009f600000, 0x000000009f600000| Untracked 
| 503|0x000000009f700000, 0x000000009f700000, 0x000000009f800000|  0%| F|  |TAMS 0x000000009f700000, 0x000000009f700000| Untracked 
| 504|0x000000009f800000, 0x000000009f800000, 0x000000009f900000|  0%| F|  |TAMS 0x000000009f800000, 0x000000009f800000| Untracked 
| 505|0x000000009f900000, 0x000000009f900000, 0x000000009fa00000|  0%| F|  |TAMS 0x000000009f900000, 0x000000009f900000| Untracked 
| 506|0x000000009fa00000, 0x000000009fa00000, 0x000000009fb00000|  0%| F|  |TAMS 0x000000009fa00000, 0x000000009fa00000| Untracked 
| 507|0x000000009fb00000, 0x000000009fb00000, 0x000000009fc00000|  0%| F|  |TAMS 0x000000009fb00000, 0x000000009fb00000| Untracked 
| 508|0x000000009fc00000, 0x000000009fc00000, 0x000000009fd00000|  0%| F|  |TAMS 0x000000009fc00000, 0x000000009fc00000| Untracked 
| 509|0x000000009fd00000, 0x000000009fd00000, 0x000000009fe00000|  0%| F|  |TAMS 0x000000009fd00000, 0x000000009fd00000| Untracked 
| 510|0x000000009fe00000, 0x000000009fe00000, 0x000000009ff00000|  0%| F|  |TAMS 0x000000009fe00000, 0x000000009fe00000| Untracked 
| 511|0x000000009ff00000, 0x000000009ff00000, 0x00000000a0000000|  0%| F|  |TAMS 0x000000009ff00000, 0x000000009ff00000| Untracked 
| 512|0x00000000a0000000, 0x00000000a0000000, 0x00000000a0100000|  0%| F|  |TAMS 0x00000000a0000000, 0x00000000a0000000| Untracked 
| 513|0x00000000a0100000, 0x00000000a0100000, 0x00000000a0200000|  0%| F|  |TAMS 0x00000000a0100000, 0x00000000a0100000| Untracked 
| 514|0x00000000a0200000, 0x00000000a0200000, 0x00000000a0300000|  0%| F|  |TAMS 0x00000000a0200000, 0x00000000a0200000| Untracked 
| 515|0x00000000a0300000, 0x00000000a0300000, 0x00000000a0400000|  0%| F|  |TAMS 0x00000000a0300000, 0x00000000a0300000| Untracked 
| 516|0x00000000a0400000, 0x00000000a0400000, 0x00000000a0500000|  0%| F|  |TAMS 0x00000000a0400000, 0x00000000a0400000| Untracked 
| 517|0x00000000a0500000, 0x00000000a0500000, 0x00000000a0600000|  0%| F|  |TAMS 0x00000000a0500000, 0x00000000a0500000| Untracked 
| 518|0x00000000a0600000, 0x00000000a0600000, 0x00000000a0700000|  0%| F|  |TAMS 0x00000000a0600000, 0x00000000a0600000| Untracked 
| 519|0x00000000a0700000, 0x00000000a0700000, 0x00000000a0800000|  0%| F|  |TAMS 0x00000000a0700000, 0x00000000a0700000| Untracked 
| 520|0x00000000a0800000, 0x00000000a0800000, 0x00000000a0900000|  0%| F|  |TAMS 0x00000000a0800000, 0x00000000a0800000| Untracked 
| 521|0x00000000a0900000, 0x00000000a0900000, 0x00000000a0a00000|  0%| F|  |TAMS 0x00000000a0900000, 0x00000000a0900000| Untracked 
| 522|0x00000000a0a00000, 0x00000000a0a00000, 0x00000000a0b00000|  0%| F|  |TAMS 0x00000000a0a00000, 0x00000000a0a00000| Untracked 
| 523|0x00000000a0b00000, 0x00000000a0b00000, 0x00000000a0c00000|  0%| F|  |TAMS 0x00000000a0b00000, 0x00000000a0b00000| Untracked 
| 524|0x00000000a0c00000, 0x00000000a0c00000, 0x00000000a0d00000|  0%| F|  |TAMS 0x00000000a0c00000, 0x00000000a0c00000| Untracked 
| 525|0x00000000a0d00000, 0x00000000a0d00000, 0x00000000a0e00000|  0%| F|  |TAMS 0x00000000a0d00000, 0x00000000a0d00000| Untracked 
| 526|0x00000000a0e00000, 0x00000000a0e00000, 0x00000000a0f00000|  0%| F|  |TAMS 0x00000000a0e00000, 0x00000000a0e00000| Untracked 
| 527|0x00000000a0f00000, 0x00000000a0f00000, 0x00000000a1000000|  0%| F|  |TAMS 0x00000000a0f00000, 0x00000000a0f00000| Untracked 
| 528|0x00000000a1000000, 0x00000000a1000000, 0x00000000a1100000|  0%| F|  |TAMS 0x00000000a1000000, 0x00000000a1000000| Untracked 
| 529|0x00000000a1100000, 0x00000000a1100000, 0x00000000a1200000|  0%| F|  |TAMS 0x00000000a1100000, 0x00000000a1100000| Untracked 
| 530|0x00000000a1200000, 0x00000000a1200000, 0x00000000a1300000|  0%| F|  |TAMS 0x00000000a1200000, 0x00000000a1200000| Untracked 
| 531|0x00000000a1300000, 0x00000000a1300000, 0x00000000a1400000|  0%| F|  |TAMS 0x00000000a1300000, 0x00000000a1300000| Untracked 
| 532|0x00000000a1400000, 0x00000000a1400000, 0x00000000a1500000|  0%| F|  |TAMS 0x00000000a1400000, 0x00000000a1400000| Untracked 
| 533|0x00000000a1500000, 0x00000000a1500000, 0x00000000a1600000|  0%| F|  |TAMS 0x00000000a1500000, 0x00000000a1500000| Untracked 
| 534|0x00000000a1600000, 0x00000000a1600000, 0x00000000a1700000|  0%| F|  |TAMS 0x00000000a1600000, 0x00000000a1600000| Untracked 
| 535|0x00000000a1700000, 0x00000000a1700000, 0x00000000a1800000|  0%| F|  |TAMS 0x00000000a1700000, 0x00000000a1700000| Untracked 
| 536|0x00000000a1800000, 0x00000000a1800000, 0x00000000a1900000|  0%| F|  |TAMS 0x00000000a1800000, 0x00000000a1800000| Untracked 
| 537|0x00000000a1900000, 0x00000000a1900000, 0x00000000a1a00000|  0%| F|  |TAMS 0x00000000a1900000, 0x00000000a1900000| Untracked 
| 538|0x00000000a1a00000, 0x00000000a1a00000, 0x00000000a1b00000|  0%| F|  |TAMS 0x00000000a1a00000, 0x00000000a1a00000| Untracked 
| 539|0x00000000a1b00000, 0x00000000a1b00000, 0x00000000a1c00000|  0%| F|  |TAMS 0x00000000a1b00000, 0x00000000a1b00000| Untracked 
| 540|0x00000000a1c00000, 0x00000000a1c00000, 0x00000000a1d00000|  0%| F|  |TAMS 0x00000000a1c00000, 0x00000000a1c00000| Untracked 
| 541|0x00000000a1d00000, 0x00000000a1d00000, 0x00000000a1e00000|  0%| F|  |TAMS 0x00000000a1d00000, 0x00000000a1d00000| Untracked 
| 542|0x00000000a1e00000, 0x00000000a1e00000, 0x00000000a1f00000|  0%| F|  |TAMS 0x00000000a1e00000, 0x00000000a1e00000| Untracked 
| 543|0x00000000a1f00000, 0x00000000a1f00000, 0x00000000a2000000|  0%| F|  |TAMS 0x00000000a1f00000, 0x00000000a1f00000| Untracked 
| 544|0x00000000a2000000, 0x00000000a2000000, 0x00000000a2100000|  0%| F|  |TAMS 0x00000000a2000000, 0x00000000a2000000| Untracked 
| 545|0x00000000a2100000, 0x00000000a2100000, 0x00000000a2200000|  0%| F|  |TAMS 0x00000000a2100000, 0x00000000a2100000| Untracked 
| 546|0x00000000a2200000, 0x00000000a2200000, 0x00000000a2300000|  0%| F|  |TAMS 0x00000000a2200000, 0x00000000a2200000| Untracked 
| 547|0x00000000a2300000, 0x00000000a2300000, 0x00000000a2400000|  0%| F|  |TAMS 0x00000000a2300000, 0x00000000a2300000| Untracked 
| 548|0x00000000a2400000, 0x00000000a2400000, 0x00000000a2500000|  0%| F|  |TAMS 0x00000000a2400000, 0x00000000a2400000| Untracked 
| 549|0x00000000a2500000, 0x00000000a2500000, 0x00000000a2600000|  0%| F|  |TAMS 0x00000000a2500000, 0x00000000a2500000| Untracked 
| 550|0x00000000a2600000, 0x00000000a2600000, 0x00000000a2700000|  0%| F|  |TAMS 0x00000000a2600000, 0x00000000a2600000| Untracked 
| 551|0x00000000a2700000, 0x00000000a2700000, 0x00000000a2800000|  0%| F|  |TAMS 0x00000000a2700000, 0x00000000a2700000| Untracked 
| 552|0x00000000a2800000, 0x00000000a2800000, 0x00000000a2900000|  0%| F|  |TAMS 0x00000000a2800000, 0x00000000a2800000| Untracked 
| 553|0x00000000a2900000, 0x00000000a2900000, 0x00000000a2a00000|  0%| F|  |TAMS 0x00000000a2900000, 0x00000000a2900000| Untracked 
| 554|0x00000000a2a00000, 0x00000000a2a00000, 0x00000000a2b00000|  0%| F|  |TAMS 0x00000000a2a00000, 0x00000000a2a00000| Untracked 
| 555|0x00000000a2b00000, 0x00000000a2b00000, 0x00000000a2c00000|  0%| F|  |TAMS 0x00000000a2b00000, 0x00000000a2b00000| Untracked 
| 556|0x00000000a2c00000, 0x00000000a2c00000, 0x00000000a2d00000|  0%| F|  |TAMS 0x00000000a2c00000, 0x00000000a2c00000| Untracked 
| 557|0x00000000a2d00000, 0x00000000a2d00000, 0x00000000a2e00000|  0%| F|  |TAMS 0x00000000a2d00000, 0x00000000a2d00000| Untracked 
| 558|0x00000000a2e00000, 0x00000000a2e00000, 0x00000000a2f00000|  0%| F|  |TAMS 0x00000000a2e00000, 0x00000000a2e00000| Untracked 
| 559|0x00000000a2f00000, 0x00000000a2f00000, 0x00000000a3000000|  0%| F|  |TAMS 0x00000000a2f00000, 0x00000000a2f00000| Untracked 
| 560|0x00000000a3000000, 0x00000000a3000000, 0x00000000a3100000|  0%| F|  |TAMS 0x00000000a3000000, 0x00000000a3000000| Untracked 
| 561|0x00000000a3100000, 0x00000000a3100000, 0x00000000a3200000|  0%| F|  |TAMS 0x00000000a3100000, 0x00000000a3100000| Untracked 
| 562|0x00000000a3200000, 0x00000000a3200000, 0x00000000a3300000|  0%| F|  |TAMS 0x00000000a3200000, 0x00000000a3200000| Untracked 
| 563|0x00000000a3300000, 0x00000000a3300000, 0x00000000a3400000|  0%| F|  |TAMS 0x00000000a3300000, 0x00000000a3300000| Untracked 
| 564|0x00000000a3400000, 0x00000000a3400000, 0x00000000a3500000|  0%| F|  |TAMS 0x00000000a3400000, 0x00000000a3400000| Untracked 
| 565|0x00000000a3500000, 0x00000000a3500000, 0x00000000a3600000|  0%| F|  |TAMS 0x00000000a3500000, 0x00000000a3500000| Untracked 
| 566|0x00000000a3600000, 0x00000000a3600000, 0x00000000a3700000|  0%| F|  |TAMS 0x00000000a3600000, 0x00000000a3600000| Untracked 
| 567|0x00000000a3700000, 0x00000000a3700000, 0x00000000a3800000|  0%| F|  |TAMS 0x00000000a3700000, 0x00000000a3700000| Untracked 
| 568|0x00000000a3800000, 0x00000000a3800000, 0x00000000a3900000|  0%| F|  |TAMS 0x00000000a3800000, 0x00000000a3800000| Untracked 
| 569|0x00000000a3900000, 0x00000000a3900000, 0x00000000a3a00000|  0%| F|  |TAMS 0x00000000a3900000, 0x00000000a3900000| Untracked 
| 570|0x00000000a3a00000, 0x00000000a3a00000, 0x00000000a3b00000|  0%| F|  |TAMS 0x00000000a3a00000, 0x00000000a3a00000| Untracked 
| 571|0x00000000a3b00000, 0x00000000a3b00000, 0x00000000a3c00000|  0%| F|  |TAMS 0x00000000a3b00000, 0x00000000a3b00000| Untracked 
| 572|0x00000000a3c00000, 0x00000000a3c00000, 0x00000000a3d00000|  0%| F|  |TAMS 0x00000000a3c00000, 0x00000000a3c00000| Untracked 
| 573|0x00000000a3d00000, 0x00000000a3d00000, 0x00000000a3e00000|  0%| F|  |TAMS 0x00000000a3d00000, 0x00000000a3d00000| Untracked 
| 574|0x00000000a3e00000, 0x00000000a3e00000, 0x00000000a3f00000|  0%| F|  |TAMS 0x00000000a3e00000, 0x00000000a3e00000| Untracked 
| 575|0x00000000a3f00000, 0x00000000a3f00000, 0x00000000a4000000|  0%| F|  |TAMS 0x00000000a3f00000, 0x00000000a3f00000| Untracked 
| 576|0x00000000a4000000, 0x00000000a4000000, 0x00000000a4100000|  0%| F|  |TAMS 0x00000000a4000000, 0x00000000a4000000| Untracked 
| 577|0x00000000a4100000, 0x00000000a4100000, 0x00000000a4200000|  0%| F|  |TAMS 0x00000000a4100000, 0x00000000a4100000| Untracked 
| 578|0x00000000a4200000, 0x00000000a4200000, 0x00000000a4300000|  0%| F|  |TAMS 0x00000000a4200000, 0x00000000a4200000| Untracked 
| 579|0x00000000a4300000, 0x00000000a4300000, 0x00000000a4400000|  0%| F|  |TAMS 0x00000000a4300000, 0x00000000a4300000| Untracked 
| 580|0x00000000a4400000, 0x00000000a4400000, 0x00000000a4500000|  0%| F|  |TAMS 0x00000000a4400000, 0x00000000a4400000| Untracked 
| 581|0x00000000a4500000, 0x00000000a4500000, 0x00000000a4600000|  0%| F|  |TAMS 0x00000000a4500000, 0x00000000a4500000| Untracked 
| 582|0x00000000a4600000, 0x00000000a4600000, 0x00000000a4700000|  0%| F|  |TAMS 0x00000000a4600000, 0x00000000a4600000| Untracked 
| 583|0x00000000a4700000, 0x00000000a4700000, 0x00000000a4800000|  0%| F|  |TAMS 0x00000000a4700000, 0x00000000a4700000| Untracked 
| 584|0x00000000a4800000, 0x00000000a4800000, 0x00000000a4900000|  0%| F|  |TAMS 0x00000000a4800000, 0x00000000a4800000| Untracked 
| 585|0x00000000a4900000, 0x00000000a4900000, 0x00000000a4a00000|  0%| F|  |TAMS 0x00000000a4900000, 0x00000000a4900000| Untracked 
| 586|0x00000000a4a00000, 0x00000000a4a00000, 0x00000000a4b00000|  0%| F|  |TAMS 0x00000000a4a00000, 0x00000000a4a00000| Untracked 
| 587|0x00000000a4b00000, 0x00000000a4b00000, 0x00000000a4c00000|  0%| F|  |TAMS 0x00000000a4b00000, 0x00000000a4b00000| Untracked 
| 588|0x00000000a4c00000, 0x00000000a4c00000, 0x00000000a4d00000|  0%| F|  |TAMS 0x00000000a4c00000, 0x00000000a4c00000| Untracked 
| 589|0x00000000a4d00000, 0x00000000a4d00000, 0x00000000a4e00000|  0%| F|  |TAMS 0x00000000a4d00000, 0x00000000a4d00000| Untracked 
| 590|0x00000000a4e00000, 0x00000000a4e00000, 0x00000000a4f00000|  0%| F|  |TAMS 0x00000000a4e00000, 0x00000000a4e00000| Untracked 
| 591|0x00000000a4f00000, 0x00000000a4f00000, 0x00000000a5000000|  0%| F|  |TAMS 0x00000000a4f00000, 0x00000000a4f00000| Untracked 
| 592|0x00000000a5000000, 0x00000000a5000000, 0x00000000a5100000|  0%| F|  |TAMS 0x00000000a5000000, 0x00000000a5000000| Untracked 
| 593|0x00000000a5100000, 0x00000000a5100000, 0x00000000a5200000|  0%| F|  |TAMS 0x00000000a5100000, 0x00000000a5100000| Untracked 
| 594|0x00000000a5200000, 0x00000000a5200000, 0x00000000a5300000|  0%| F|  |TAMS 0x00000000a5200000, 0x00000000a5200000| Untracked 
| 595|0x00000000a5300000, 0x00000000a5300000, 0x00000000a5400000|  0%| F|  |TAMS 0x00000000a5300000, 0x00000000a5300000| Untracked 
| 596|0x00000000a5400000, 0x00000000a5400000, 0x00000000a5500000|  0%| F|  |TAMS 0x00000000a5400000, 0x00000000a5400000| Untracked 
| 597|0x00000000a5500000, 0x00000000a5500000, 0x00000000a5600000|  0%| F|  |TAMS 0x00000000a5500000, 0x00000000a5500000| Untracked 
| 598|0x00000000a5600000, 0x00000000a5600000, 0x00000000a5700000|  0%| F|  |TAMS 0x00000000a5600000, 0x00000000a5600000| Untracked 
| 599|0x00000000a5700000, 0x00000000a5700000, 0x00000000a5800000|  0%| F|  |TAMS 0x00000000a5700000, 0x00000000a5700000| Untracked 
| 600|0x00000000a5800000, 0x00000000a5800000, 0x00000000a5900000|  0%| F|  |TAMS 0x00000000a5800000, 0x00000000a5800000| Untracked 
| 601|0x00000000a5900000, 0x00000000a5900000, 0x00000000a5a00000|  0%| F|  |TAMS 0x00000000a5900000, 0x00000000a5900000| Untracked 
| 602|0x00000000a5a00000, 0x00000000a5a00000, 0x00000000a5b00000|  0%| F|  |TAMS 0x00000000a5a00000, 0x00000000a5a00000| Untracked 
| 603|0x00000000a5b00000, 0x00000000a5b00000, 0x00000000a5c00000|  0%| F|  |TAMS 0x00000000a5b00000, 0x00000000a5b00000| Untracked 
| 604|0x00000000a5c00000, 0x00000000a5c00000, 0x00000000a5d00000|  0%| F|  |TAMS 0x00000000a5c00000, 0x00000000a5c00000| Untracked 
| 605|0x00000000a5d00000, 0x00000000a5d00000, 0x00000000a5e00000|  0%| F|  |TAMS 0x00000000a5d00000, 0x00000000a5d00000| Untracked 
| 606|0x00000000a5e00000, 0x00000000a5e00000, 0x00000000a5f00000|  0%| F|  |TAMS 0x00000000a5e00000, 0x00000000a5e00000| Untracked 
| 607|0x00000000a5f00000, 0x00000000a5f00000, 0x00000000a6000000|  0%| F|  |TAMS 0x00000000a5f00000, 0x00000000a5f00000| Untracked 
| 608|0x00000000a6000000, 0x00000000a6000000, 0x00000000a6100000|  0%| F|  |TAMS 0x00000000a6000000, 0x00000000a6000000| Untracked 
| 609|0x00000000a6100000, 0x00000000a6100000, 0x00000000a6200000|  0%| F|  |TAMS 0x00000000a6100000, 0x00000000a6100000| Untracked 
| 610|0x00000000a6200000, 0x00000000a6200000, 0x00000000a6300000|  0%| F|  |TAMS 0x00000000a6200000, 0x00000000a6200000| Untracked 
| 611|0x00000000a6300000, 0x00000000a6300000, 0x00000000a6400000|  0%| F|  |TAMS 0x00000000a6300000, 0x00000000a6300000| Untracked 
| 612|0x00000000a6400000, 0x00000000a6400000, 0x00000000a6500000|  0%| F|  |TAMS 0x00000000a6400000, 0x00000000a6400000| Untracked 
| 613|0x00000000a6500000, 0x00000000a6500000, 0x00000000a6600000|  0%| F|  |TAMS 0x00000000a6500000, 0x00000000a6500000| Untracked 
| 614|0x00000000a6600000, 0x00000000a6600000, 0x00000000a6700000|  0%| F|  |TAMS 0x00000000a6600000, 0x00000000a6600000| Untracked 
| 615|0x00000000a6700000, 0x00000000a6700000, 0x00000000a6800000|  0%| F|  |TAMS 0x00000000a6700000, 0x00000000a6700000| Untracked 
| 616|0x00000000a6800000, 0x00000000a6800000, 0x00000000a6900000|  0%| F|  |TAMS 0x00000000a6800000, 0x00000000a6800000| Untracked 
| 617|0x00000000a6900000, 0x00000000a6900000, 0x00000000a6a00000|  0%| F|  |TAMS 0x00000000a6900000, 0x00000000a6900000| Untracked 
| 618|0x00000000a6a00000, 0x00000000a6a00000, 0x00000000a6b00000|  0%| F|  |TAMS 0x00000000a6a00000, 0x00000000a6a00000| Untracked 
| 619|0x00000000a6b00000, 0x00000000a6b00000, 0x00000000a6c00000|  0%| F|  |TAMS 0x00000000a6b00000, 0x00000000a6b00000| Untracked 
| 620|0x00000000a6c00000, 0x00000000a6c00000, 0x00000000a6d00000|  0%| F|  |TAMS 0x00000000a6c00000, 0x00000000a6c00000| Untracked 
| 621|0x00000000a6d00000, 0x00000000a6d00000, 0x00000000a6e00000|  0%| F|  |TAMS 0x00000000a6d00000, 0x00000000a6d00000| Untracked 
| 622|0x00000000a6e00000, 0x00000000a6e00000, 0x00000000a6f00000|  0%| F|  |TAMS 0x00000000a6e00000, 0x00000000a6e00000| Untracked 
| 623|0x00000000a6f00000, 0x00000000a6f00000, 0x00000000a7000000|  0%| F|  |TAMS 0x00000000a6f00000, 0x00000000a6f00000| Untracked 
| 624|0x00000000a7000000, 0x00000000a7000000, 0x00000000a7100000|  0%| F|  |TAMS 0x00000000a7000000, 0x00000000a7000000| Untracked 
| 625|0x00000000a7100000, 0x00000000a7100000, 0x00000000a7200000|  0%| F|  |TAMS 0x00000000a7100000, 0x00000000a7100000| Untracked 
| 626|0x00000000a7200000, 0x00000000a7200000, 0x00000000a7300000|  0%| F|  |TAMS 0x00000000a7200000, 0x00000000a7200000| Untracked 
| 627|0x00000000a7300000, 0x00000000a7300000, 0x00000000a7400000|  0%| F|  |TAMS 0x00000000a7300000, 0x00000000a7300000| Untracked 
| 628|0x00000000a7400000, 0x00000000a7400000, 0x00000000a7500000|  0%| F|  |TAMS 0x00000000a7400000, 0x00000000a7400000| Untracked 
| 629|0x00000000a7500000, 0x00000000a7500000, 0x00000000a7600000|  0%| F|  |TAMS 0x00000000a7500000, 0x00000000a7500000| Untracked 
| 630|0x00000000a7600000, 0x00000000a7600000, 0x00000000a7700000|  0%| F|  |TAMS 0x00000000a7600000, 0x00000000a7600000| Untracked 
| 631|0x00000000a7700000, 0x00000000a7700000, 0x00000000a7800000|  0%| F|  |TAMS 0x00000000a7700000, 0x00000000a7700000| Untracked 
| 632|0x00000000a7800000, 0x00000000a7800000, 0x00000000a7900000|  0%| F|  |TAMS 0x00000000a7800000, 0x00000000a7800000| Untracked 
| 633|0x00000000a7900000, 0x00000000a7900000, 0x00000000a7a00000|  0%| F|  |TAMS 0x00000000a7900000, 0x00000000a7900000| Untracked 
| 634|0x00000000a7a00000, 0x00000000a7a00000, 0x00000000a7b00000|  0%| F|  |TAMS 0x00000000a7a00000, 0x00000000a7a00000| Untracked 
| 635|0x00000000a7b00000, 0x00000000a7b00000, 0x00000000a7c00000|  0%| F|  |TAMS 0x00000000a7b00000, 0x00000000a7b00000| Untracked 
| 636|0x00000000a7c00000, 0x00000000a7c00000, 0x00000000a7d00000|  0%| F|  |TAMS 0x00000000a7c00000, 0x00000000a7c00000| Untracked 
| 637|0x00000000a7d00000, 0x00000000a7d00000, 0x00000000a7e00000|  0%| F|  |TAMS 0x00000000a7d00000, 0x00000000a7d00000| Untracked 
| 638|0x00000000a7e00000, 0x00000000a7e00000, 0x00000000a7f00000|  0%| F|  |TAMS 0x00000000a7e00000, 0x00000000a7e00000| Untracked 
| 639|0x00000000a7f00000, 0x00000000a7f00000, 0x00000000a8000000|  0%| F|  |TAMS 0x00000000a7f00000, 0x00000000a7f00000| Untracked 
| 640|0x00000000a8000000, 0x00000000a8000000, 0x00000000a8100000|  0%| F|  |TAMS 0x00000000a8000000, 0x00000000a8000000| Untracked 
| 641|0x00000000a8100000, 0x00000000a8100000, 0x00000000a8200000|  0%| F|  |TAMS 0x00000000a8100000, 0x00000000a8100000| Untracked 
| 642|0x00000000a8200000, 0x00000000a8200000, 0x00000000a8300000|  0%| F|  |TAMS 0x00000000a8200000, 0x00000000a8200000| Untracked 
| 643|0x00000000a8300000, 0x00000000a8300000, 0x00000000a8400000|  0%| F|  |TAMS 0x00000000a8300000, 0x00000000a8300000| Untracked 
| 644|0x00000000a8400000, 0x00000000a8400000, 0x00000000a8500000|  0%| F|  |TAMS 0x00000000a8400000, 0x00000000a8400000| Untracked 
| 645|0x00000000a8500000, 0x00000000a8500000, 0x00000000a8600000|  0%| F|  |TAMS 0x00000000a8500000, 0x00000000a8500000| Untracked 
| 646|0x00000000a8600000, 0x00000000a8600000, 0x00000000a8700000|  0%| F|  |TAMS 0x00000000a8600000, 0x00000000a8600000| Untracked 
| 647|0x00000000a8700000, 0x00000000a8700000, 0x00000000a8800000|  0%| F|  |TAMS 0x00000000a8700000, 0x00000000a8700000| Untracked 
| 648|0x00000000a8800000, 0x00000000a8800000, 0x00000000a8900000|  0%| F|  |TAMS 0x00000000a8800000, 0x00000000a8800000| Untracked 
| 649|0x00000000a8900000, 0x00000000a8900000, 0x00000000a8a00000|  0%| F|  |TAMS 0x00000000a8900000, 0x00000000a8900000| Untracked 
| 650|0x00000000a8a00000, 0x00000000a8a00000, 0x00000000a8b00000|  0%| F|  |TAMS 0x00000000a8a00000, 0x00000000a8a00000| Untracked 
| 651|0x00000000a8b00000, 0x00000000a8b00000, 0x00000000a8c00000|  0%| F|  |TAMS 0x00000000a8b00000, 0x00000000a8b00000| Untracked 
| 652|0x00000000a8c00000, 0x00000000a8c00000, 0x00000000a8d00000|  0%| F|  |TAMS 0x00000000a8c00000, 0x00000000a8c00000| Untracked 
| 653|0x00000000a8d00000, 0x00000000a8d00000, 0x00000000a8e00000|  0%| F|  |TAMS 0x00000000a8d00000, 0x00000000a8d00000| Untracked 
| 654|0x00000000a8e00000, 0x00000000a8e00000, 0x00000000a8f00000|  0%| F|  |TAMS 0x00000000a8e00000, 0x00000000a8e00000| Untracked 
| 655|0x00000000a8f00000, 0x00000000a8f00000, 0x00000000a9000000|  0%| F|  |TAMS 0x00000000a8f00000, 0x00000000a8f00000| Untracked 
| 656|0x00000000a9000000, 0x00000000a9000000, 0x00000000a9100000|  0%| F|  |TAMS 0x00000000a9000000, 0x00000000a9000000| Untracked 
| 657|0x00000000a9100000, 0x00000000a9100000, 0x00000000a9200000|  0%| F|  |TAMS 0x00000000a9100000, 0x00000000a9100000| Untracked 
| 658|0x00000000a9200000, 0x00000000a9200000, 0x00000000a9300000|  0%| F|  |TAMS 0x00000000a9200000, 0x00000000a9200000| Untracked 
| 659|0x00000000a9300000, 0x00000000a9300000, 0x00000000a9400000|  0%| F|  |TAMS 0x00000000a9300000, 0x00000000a9300000| Untracked 
| 660|0x00000000a9400000, 0x00000000a9400000, 0x00000000a9500000|  0%| F|  |TAMS 0x00000000a9400000, 0x00000000a9400000| Untracked 
| 661|0x00000000a9500000, 0x00000000a9500000, 0x00000000a9600000|  0%| F|  |TAMS 0x00000000a9500000, 0x00000000a9500000| Untracked 
| 662|0x00000000a9600000, 0x00000000a9600000, 0x00000000a9700000|  0%| F|  |TAMS 0x00000000a9600000, 0x00000000a9600000| Untracked 
| 663|0x00000000a9700000, 0x00000000a9700000, 0x00000000a9800000|  0%| F|  |TAMS 0x00000000a9700000, 0x00000000a9700000| Untracked 
| 664|0x00000000a9800000, 0x00000000a9800000, 0x00000000a9900000|  0%| F|  |TAMS 0x00000000a9800000, 0x00000000a9800000| Untracked 
| 665|0x00000000a9900000, 0x00000000a9900000, 0x00000000a9a00000|  0%| F|  |TAMS 0x00000000a9900000, 0x00000000a9900000| Untracked 
| 666|0x00000000a9a00000, 0x00000000a9a00000, 0x00000000a9b00000|  0%| F|  |TAMS 0x00000000a9a00000, 0x00000000a9a00000| Untracked 
| 667|0x00000000a9b00000, 0x00000000a9b00000, 0x00000000a9c00000|  0%| F|  |TAMS 0x00000000a9b00000, 0x00000000a9b00000| Untracked 
| 668|0x00000000a9c00000, 0x00000000a9c00000, 0x00000000a9d00000|  0%| F|  |TAMS 0x00000000a9c00000, 0x00000000a9c00000| Untracked 
| 669|0x00000000a9d00000, 0x00000000a9d00000, 0x00000000a9e00000|  0%| F|  |TAMS 0x00000000a9d00000, 0x00000000a9d00000| Untracked 
| 670|0x00000000a9e00000, 0x00000000a9e00000, 0x00000000a9f00000|  0%| F|  |TAMS 0x00000000a9e00000, 0x00000000a9e00000| Untracked 
| 671|0x00000000a9f00000, 0x00000000a9f00000, 0x00000000aa000000|  0%| F|  |TAMS 0x00000000a9f00000, 0x00000000a9f00000| Untracked 
| 672|0x00000000aa000000, 0x00000000aa000000, 0x00000000aa100000|  0%| F|  |TAMS 0x00000000aa000000, 0x00000000aa000000| Untracked 
| 673|0x00000000aa100000, 0x00000000aa100000, 0x00000000aa200000|  0%| F|  |TAMS 0x00000000aa100000, 0x00000000aa100000| Untracked 
| 674|0x00000000aa200000, 0x00000000aa200000, 0x00000000aa300000|  0%| F|  |TAMS 0x00000000aa200000, 0x00000000aa200000| Untracked 
| 675|0x00000000aa300000, 0x00000000aa300000, 0x00000000aa400000|  0%| F|  |TAMS 0x00000000aa300000, 0x00000000aa300000| Untracked 
| 676|0x00000000aa400000, 0x00000000aa400000, 0x00000000aa500000|  0%| F|  |TAMS 0x00000000aa400000, 0x00000000aa400000| Untracked 
| 677|0x00000000aa500000, 0x00000000aa500000, 0x00000000aa600000|  0%| F|  |TAMS 0x00000000aa500000, 0x00000000aa500000| Untracked 
| 678|0x00000000aa600000, 0x00000000aa600000, 0x00000000aa700000|  0%| F|  |TAMS 0x00000000aa600000, 0x00000000aa600000| Untracked 
| 679|0x00000000aa700000, 0x00000000aa700000, 0x00000000aa800000|  0%| F|  |TAMS 0x00000000aa700000, 0x00000000aa700000| Untracked 
| 680|0x00000000aa800000, 0x00000000aa800000, 0x00000000aa900000|  0%| F|  |TAMS 0x00000000aa800000, 0x00000000aa800000| Untracked 
| 681|0x00000000aa900000, 0x00000000aa900000, 0x00000000aaa00000|  0%| F|  |TAMS 0x00000000aa900000, 0x00000000aa900000| Untracked 
| 682|0x00000000aaa00000, 0x00000000aaa00000, 0x00000000aab00000|  0%| F|  |TAMS 0x00000000aaa00000, 0x00000000aaa00000| Untracked 
| 683|0x00000000aab00000, 0x00000000aab00000, 0x00000000aac00000|  0%| F|  |TAMS 0x00000000aab00000, 0x00000000aab00000| Untracked 
| 684|0x00000000aac00000, 0x00000000aac00000, 0x00000000aad00000|  0%| F|  |TAMS 0x00000000aac00000, 0x00000000aac00000| Untracked 
| 685|0x00000000aad00000, 0x00000000aad00000, 0x00000000aae00000|  0%| F|  |TAMS 0x00000000aad00000, 0x00000000aad00000| Untracked 
| 686|0x00000000aae00000, 0x00000000aae00000, 0x00000000aaf00000|  0%| F|  |TAMS 0x00000000aae00000, 0x00000000aae00000| Untracked 
| 687|0x00000000aaf00000, 0x00000000aaf00000, 0x00000000ab000000|  0%| F|  |TAMS 0x00000000aaf00000, 0x00000000aaf00000| Untracked 
| 688|0x00000000ab000000, 0x00000000ab000000, 0x00000000ab100000|  0%| F|  |TAMS 0x00000000ab000000, 0x00000000ab000000| Untracked 
| 689|0x00000000ab100000, 0x00000000ab100000, 0x00000000ab200000|  0%| F|  |TAMS 0x00000000ab100000, 0x00000000ab100000| Untracked 
| 690|0x00000000ab200000, 0x00000000ab200000, 0x00000000ab300000|  0%| F|  |TAMS 0x00000000ab200000, 0x00000000ab200000| Untracked 
| 691|0x00000000ab300000, 0x00000000ab300000, 0x00000000ab400000|  0%| F|  |TAMS 0x00000000ab300000, 0x00000000ab300000| Untracked 
| 692|0x00000000ab400000, 0x00000000ab400000, 0x00000000ab500000|  0%| F|  |TAMS 0x00000000ab400000, 0x00000000ab400000| Untracked 
| 693|0x00000000ab500000, 0x00000000ab500000, 0x00000000ab600000|  0%| F|  |TAMS 0x00000000ab500000, 0x00000000ab500000| Untracked 
| 694|0x00000000ab600000, 0x00000000ab600000, 0x00000000ab700000|  0%| F|  |TAMS 0x00000000ab600000, 0x00000000ab600000| Untracked 
| 695|0x00000000ab700000, 0x00000000ab700000, 0x00000000ab800000|  0%| F|  |TAMS 0x00000000ab700000, 0x00000000ab700000| Untracked 
| 696|0x00000000ab800000, 0x00000000ab800000, 0x00000000ab900000|  0%| F|  |TAMS 0x00000000ab800000, 0x00000000ab800000| Untracked 
| 697|0x00000000ab900000, 0x00000000ab900000, 0x00000000aba00000|  0%| F|  |TAMS 0x00000000ab900000, 0x00000000ab900000| Untracked 
| 698|0x00000000aba00000, 0x00000000aba00000, 0x00000000abb00000|  0%| F|  |TAMS 0x00000000aba00000, 0x00000000aba00000| Untracked 
| 699|0x00000000abb00000, 0x00000000abb00000, 0x00000000abc00000|  0%| F|  |TAMS 0x00000000abb00000, 0x00000000abb00000| Untracked 
| 700|0x00000000abc00000, 0x00000000abc00000, 0x00000000abd00000|  0%| F|  |TAMS 0x00000000abc00000, 0x00000000abc00000| Untracked 
| 701|0x00000000abd00000, 0x00000000abd00000, 0x00000000abe00000|  0%| F|  |TAMS 0x00000000abd00000, 0x00000000abd00000| Untracked 
| 702|0x00000000abe00000, 0x00000000abe00000, 0x00000000abf00000|  0%| F|  |TAMS 0x00000000abe00000, 0x00000000abe00000| Untracked 
| 703|0x00000000abf00000, 0x00000000abf00000, 0x00000000ac000000|  0%| F|  |TAMS 0x00000000abf00000, 0x00000000abf00000| Untracked 
| 704|0x00000000ac000000, 0x00000000ac000000, 0x00000000ac100000|  0%| F|  |TAMS 0x00000000ac000000, 0x00000000ac000000| Untracked 
| 705|0x00000000ac100000, 0x00000000ac100000, 0x00000000ac200000|  0%| F|  |TAMS 0x00000000ac100000, 0x00000000ac100000| Untracked 
| 706|0x00000000ac200000, 0x00000000ac200000, 0x00000000ac300000|  0%| F|  |TAMS 0x00000000ac200000, 0x00000000ac200000| Untracked 
| 707|0x00000000ac300000, 0x00000000ac300000, 0x00000000ac400000|  0%| F|  |TAMS 0x00000000ac300000, 0x00000000ac300000| Untracked 
| 708|0x00000000ac400000, 0x00000000ac400000, 0x00000000ac500000|  0%| F|  |TAMS 0x00000000ac400000, 0x00000000ac400000| Untracked 
| 709|0x00000000ac500000, 0x00000000ac500000, 0x00000000ac600000|  0%| F|  |TAMS 0x00000000ac500000, 0x00000000ac500000| Untracked 
| 710|0x00000000ac600000, 0x00000000ac600000, 0x00000000ac700000|  0%| F|  |TAMS 0x00000000ac600000, 0x00000000ac600000| Untracked 
| 711|0x00000000ac700000, 0x00000000ac700000, 0x00000000ac800000|  0%| F|  |TAMS 0x00000000ac700000, 0x00000000ac700000| Untracked 
| 712|0x00000000ac800000, 0x00000000ac800000, 0x00000000ac900000|  0%| F|  |TAMS 0x00000000ac800000, 0x00000000ac800000| Untracked 
| 713|0x00000000ac900000, 0x00000000ac900000, 0x00000000aca00000|  0%| F|  |TAMS 0x00000000ac900000, 0x00000000ac900000| Untracked 
| 714|0x00000000aca00000, 0x00000000aca00000, 0x00000000acb00000|  0%| F|  |TAMS 0x00000000aca00000, 0x00000000aca00000| Untracked 
| 715|0x00000000acb00000, 0x00000000acb00000, 0x00000000acc00000|  0%| F|  |TAMS 0x00000000acb00000, 0x00000000acb00000| Untracked 
| 716|0x00000000acc00000, 0x00000000acc00000, 0x00000000acd00000|  0%| F|  |TAMS 0x00000000acc00000, 0x00000000acc00000| Untracked 
| 717|0x00000000acd00000, 0x00000000acd00000, 0x00000000ace00000|  0%| F|  |TAMS 0x00000000acd00000, 0x00000000acd00000| Untracked 
| 718|0x00000000ace00000, 0x00000000ace00000, 0x00000000acf00000|  0%| F|  |TAMS 0x00000000ace00000, 0x00000000ace00000| Untracked 
| 719|0x00000000acf00000, 0x00000000acf00000, 0x00000000ad000000|  0%| F|  |TAMS 0x00000000acf00000, 0x00000000acf00000| Untracked 
| 720|0x00000000ad000000, 0x00000000ad000000, 0x00000000ad100000|  0%| F|  |TAMS 0x00000000ad000000, 0x00000000ad000000| Untracked 
| 721|0x00000000ad100000, 0x00000000ad100000, 0x00000000ad200000|  0%| F|  |TAMS 0x00000000ad100000, 0x00000000ad100000| Untracked 
| 722|0x00000000ad200000, 0x00000000ad200000, 0x00000000ad300000|  0%| F|  |TAMS 0x00000000ad200000, 0x00000000ad200000| Untracked 
| 723|0x00000000ad300000, 0x00000000ad300000, 0x00000000ad400000|  0%| F|  |TAMS 0x00000000ad300000, 0x00000000ad300000| Untracked 
| 724|0x00000000ad400000, 0x00000000ad400000, 0x00000000ad500000|  0%| F|  |TAMS 0x00000000ad400000, 0x00000000ad400000| Untracked 
| 725|0x00000000ad500000, 0x00000000ad500000, 0x00000000ad600000|  0%| F|  |TAMS 0x00000000ad500000, 0x00000000ad500000| Untracked 
| 726|0x00000000ad600000, 0x00000000ad600000, 0x00000000ad700000|  0%| F|  |TAMS 0x00000000ad600000, 0x00000000ad600000| Untracked 
| 727|0x00000000ad700000, 0x00000000ad700000, 0x00000000ad800000|  0%| F|  |TAMS 0x00000000ad700000, 0x00000000ad700000| Untracked 
| 728|0x00000000ad800000, 0x00000000ad800000, 0x00000000ad900000|  0%| F|  |TAMS 0x00000000ad800000, 0x00000000ad800000| Untracked 
| 729|0x00000000ad900000, 0x00000000ad900000, 0x00000000ada00000|  0%| F|  |TAMS 0x00000000ad900000, 0x00000000ad900000| Untracked 
| 730|0x00000000ada00000, 0x00000000ada00000, 0x00000000adb00000|  0%| F|  |TAMS 0x00000000ada00000, 0x00000000ada00000| Untracked 
| 731|0x00000000adb00000, 0x00000000adb00000, 0x00000000adc00000|  0%| F|  |TAMS 0x00000000adb00000, 0x00000000adb00000| Untracked 
| 732|0x00000000adc00000, 0x00000000adc00000, 0x00000000add00000|  0%| F|  |TAMS 0x00000000adc00000, 0x00000000adc00000| Untracked 
| 733|0x00000000add00000, 0x00000000add00000, 0x00000000ade00000|  0%| F|  |TAMS 0x00000000add00000, 0x00000000add00000| Untracked 
| 734|0x00000000ade00000, 0x00000000ade00000, 0x00000000adf00000|  0%| F|  |TAMS 0x00000000ade00000, 0x00000000ade00000| Untracked 
| 735|0x00000000adf00000, 0x00000000adf00000, 0x00000000ae000000|  0%| F|  |TAMS 0x00000000adf00000, 0x00000000adf00000| Untracked 
| 736|0x00000000ae000000, 0x00000000ae000000, 0x00000000ae100000|  0%| F|  |TAMS 0x00000000ae000000, 0x00000000ae000000| Untracked 
| 737|0x00000000ae100000, 0x00000000ae100000, 0x00000000ae200000|  0%| F|  |TAMS 0x00000000ae100000, 0x00000000ae100000| Untracked 
| 738|0x00000000ae200000, 0x00000000ae200000, 0x00000000ae300000|  0%| F|  |TAMS 0x00000000ae200000, 0x00000000ae200000| Untracked 
| 739|0x00000000ae300000, 0x00000000ae300000, 0x00000000ae400000|  0%| F|  |TAMS 0x00000000ae300000, 0x00000000ae300000| Untracked 
| 740|0x00000000ae400000, 0x00000000ae400000, 0x00000000ae500000|  0%| F|  |TAMS 0x00000000ae400000, 0x00000000ae400000| Untracked 
| 741|0x00000000ae500000, 0x00000000ae500000, 0x00000000ae600000|  0%| F|  |TAMS 0x00000000ae500000, 0x00000000ae500000| Untracked 
| 742|0x00000000ae600000, 0x00000000ae600000, 0x00000000ae700000|  0%| F|  |TAMS 0x00000000ae600000, 0x00000000ae600000| Untracked 
| 743|0x00000000ae700000, 0x00000000ae700000, 0x00000000ae800000|  0%| F|  |TAMS 0x00000000ae700000, 0x00000000ae700000| Untracked 
| 744|0x00000000ae800000, 0x00000000ae800000, 0x00000000ae900000|  0%| F|  |TAMS 0x00000000ae800000, 0x00000000ae800000| Untracked 
| 745|0x00000000ae900000, 0x00000000ae900000, 0x00000000aea00000|  0%| F|  |TAMS 0x00000000ae900000, 0x00000000ae900000| Untracked 
| 746|0x00000000aea00000, 0x00000000aea00000, 0x00000000aeb00000|  0%| F|  |TAMS 0x00000000aea00000, 0x00000000aea00000| Untracked 
| 747|0x00000000aeb00000, 0x00000000aeb00000, 0x00000000aec00000|  0%| F|  |TAMS 0x00000000aeb00000, 0x00000000aeb00000| Untracked 
| 748|0x00000000aec00000, 0x00000000aec00000, 0x00000000aed00000|  0%| F|  |TAMS 0x00000000aec00000, 0x00000000aec00000| Untracked 
| 749|0x00000000aed00000, 0x00000000aed00000, 0x00000000aee00000|  0%| F|  |TAMS 0x00000000aed00000, 0x00000000aed00000| Untracked 
| 750|0x00000000aee00000, 0x00000000aee00000, 0x00000000aef00000|  0%| F|  |TAMS 0x00000000aee00000, 0x00000000aee00000| Untracked 
| 751|0x00000000aef00000, 0x00000000aef00000, 0x00000000af000000|  0%| F|  |TAMS 0x00000000aef00000, 0x00000000aef00000| Untracked 
| 752|0x00000000af000000, 0x00000000af000000, 0x00000000af100000|  0%| F|  |TAMS 0x00000000af000000, 0x00000000af000000| Untracked 
| 753|0x00000000af100000, 0x00000000af100000, 0x00000000af200000|  0%| F|  |TAMS 0x00000000af100000, 0x00000000af100000| Untracked 
| 754|0x00000000af200000, 0x00000000af200000, 0x00000000af300000|  0%| F|  |TAMS 0x00000000af200000, 0x00000000af200000| Untracked 
| 755|0x00000000af300000, 0x00000000af300000, 0x00000000af400000|  0%| F|  |TAMS 0x00000000af300000, 0x00000000af300000| Untracked 
| 756|0x00000000af400000, 0x00000000af400000, 0x00000000af500000|  0%| F|  |TAMS 0x00000000af400000, 0x00000000af400000| Untracked 
| 757|0x00000000af500000, 0x00000000af500000, 0x00000000af600000|  0%| F|  |TAMS 0x00000000af500000, 0x00000000af500000| Untracked 
| 758|0x00000000af600000, 0x00000000af600000, 0x00000000af700000|  0%| F|  |TAMS 0x00000000af600000, 0x00000000af600000| Untracked 
| 759|0x00000000af700000, 0x00000000af700000, 0x00000000af800000|  0%| F|  |TAMS 0x00000000af700000, 0x00000000af700000| Untracked 
| 760|0x00000000af800000, 0x00000000af800000, 0x00000000af900000|  0%| F|  |TAMS 0x00000000af800000, 0x00000000af800000| Untracked 
| 761|0x00000000af900000, 0x00000000af900000, 0x00000000afa00000|  0%| F|  |TAMS 0x00000000af900000, 0x00000000af900000| Untracked 
| 762|0x00000000afa00000, 0x00000000afa00000, 0x00000000afb00000|  0%| F|  |TAMS 0x00000000afa00000, 0x00000000afa00000| Untracked 
| 763|0x00000000afb00000, 0x00000000afb00000, 0x00000000afc00000|  0%| F|  |TAMS 0x00000000afb00000, 0x00000000afb00000| Untracked 
| 764|0x00000000afc00000, 0x00000000afc00000, 0x00000000afd00000|  0%| F|  |TAMS 0x00000000afc00000, 0x00000000afc00000| Untracked 
| 765|0x00000000afd00000, 0x00000000afd00000, 0x00000000afe00000|  0%| F|  |TAMS 0x00000000afd00000, 0x00000000afd00000| Untracked 
| 766|0x00000000afe00000, 0x00000000afe00000, 0x00000000aff00000|  0%| F|  |TAMS 0x00000000afe00000, 0x00000000afe00000| Untracked 
| 767|0x00000000aff00000, 0x00000000aff00000, 0x00000000b0000000|  0%| F|  |TAMS 0x00000000aff00000, 0x00000000aff00000| Untracked 
| 768|0x00000000b0000000, 0x00000000b0000000, 0x00000000b0100000|  0%| F|  |TAMS 0x00000000b0000000, 0x00000000b0000000| Untracked 
| 769|0x00000000b0100000, 0x00000000b0100000, 0x00000000b0200000|  0%| F|  |TAMS 0x00000000b0100000, 0x00000000b0100000| Untracked 
| 770|0x00000000b0200000, 0x00000000b0200000, 0x00000000b0300000|  0%| F|  |TAMS 0x00000000b0200000, 0x00000000b0200000| Untracked 
| 771|0x00000000b0300000, 0x00000000b0300000, 0x00000000b0400000|  0%| F|  |TAMS 0x00000000b0300000, 0x00000000b0300000| Untracked 
| 772|0x00000000b0400000, 0x00000000b0400000, 0x00000000b0500000|  0%| F|  |TAMS 0x00000000b0400000, 0x00000000b0400000| Untracked 
| 773|0x00000000b0500000, 0x00000000b0500000, 0x00000000b0600000|  0%| F|  |TAMS 0x00000000b0500000, 0x00000000b0500000| Untracked 
| 774|0x00000000b0600000, 0x00000000b0600000, 0x00000000b0700000|  0%| F|  |TAMS 0x00000000b0600000, 0x00000000b0600000| Untracked 
| 775|0x00000000b0700000, 0x00000000b0700000, 0x00000000b0800000|  0%| F|  |TAMS 0x00000000b0700000, 0x00000000b0700000| Untracked 
| 776|0x00000000b0800000, 0x00000000b0800000, 0x00000000b0900000|  0%| F|  |TAMS 0x00000000b0800000, 0x00000000b0800000| Untracked 
| 777|0x00000000b0900000, 0x00000000b0900000, 0x00000000b0a00000|  0%| F|  |TAMS 0x00000000b0900000, 0x00000000b0900000| Untracked 
| 778|0x00000000b0a00000, 0x00000000b0a00000, 0x00000000b0b00000|  0%| F|  |TAMS 0x00000000b0a00000, 0x00000000b0a00000| Untracked 
| 779|0x00000000b0b00000, 0x00000000b0b00000, 0x00000000b0c00000|  0%| F|  |TAMS 0x00000000b0b00000, 0x00000000b0b00000| Untracked 
| 780|0x00000000b0c00000, 0x00000000b0c00000, 0x00000000b0d00000|  0%| F|  |TAMS 0x00000000b0c00000, 0x00000000b0c00000| Untracked 
| 781|0x00000000b0d00000, 0x00000000b0d00000, 0x00000000b0e00000|  0%| F|  |TAMS 0x00000000b0d00000, 0x00000000b0d00000| Untracked 
| 782|0x00000000b0e00000, 0x00000000b0e00000, 0x00000000b0f00000|  0%| F|  |TAMS 0x00000000b0e00000, 0x00000000b0e00000| Untracked 
| 783|0x00000000b0f00000, 0x00000000b0f00000, 0x00000000b1000000|  0%| F|  |TAMS 0x00000000b0f00000, 0x00000000b0f00000| Untracked 
| 784|0x00000000b1000000, 0x00000000b1000000, 0x00000000b1100000|  0%| F|  |TAMS 0x00000000b1000000, 0x00000000b1000000| Untracked 
| 785|0x00000000b1100000, 0x00000000b1100000, 0x00000000b1200000|  0%| F|  |TAMS 0x00000000b1100000, 0x00000000b1100000| Untracked 
| 786|0x00000000b1200000, 0x00000000b1200000, 0x00000000b1300000|  0%| F|  |TAMS 0x00000000b1200000, 0x00000000b1200000| Untracked 
| 787|0x00000000b1300000, 0x00000000b1300000, 0x00000000b1400000|  0%| F|  |TAMS 0x00000000b1300000, 0x00000000b1300000| Untracked 
| 788|0x00000000b1400000, 0x00000000b1400000, 0x00000000b1500000|  0%| F|  |TAMS 0x00000000b1400000, 0x00000000b1400000| Untracked 
| 789|0x00000000b1500000, 0x00000000b1500000, 0x00000000b1600000|  0%| F|  |TAMS 0x00000000b1500000, 0x00000000b1500000| Untracked 
| 790|0x00000000b1600000, 0x00000000b1600000, 0x00000000b1700000|  0%| F|  |TAMS 0x00000000b1600000, 0x00000000b1600000| Untracked 
| 791|0x00000000b1700000, 0x00000000b1700000, 0x00000000b1800000|  0%| F|  |TAMS 0x00000000b1700000, 0x00000000b1700000| Untracked 
| 792|0x00000000b1800000, 0x00000000b1800000, 0x00000000b1900000|  0%| F|  |TAMS 0x00000000b1800000, 0x00000000b1800000| Untracked 
| 793|0x00000000b1900000, 0x00000000b1900000, 0x00000000b1a00000|  0%| F|  |TAMS 0x00000000b1900000, 0x00000000b1900000| Untracked 
| 794|0x00000000b1a00000, 0x00000000b1a00000, 0x00000000b1b00000|  0%| F|  |TAMS 0x00000000b1a00000, 0x00000000b1a00000| Untracked 
| 795|0x00000000b1b00000, 0x00000000b1b00000, 0x00000000b1c00000|  0%| F|  |TAMS 0x00000000b1b00000, 0x00000000b1b00000| Untracked 
| 796|0x00000000b1c00000, 0x00000000b1c00000, 0x00000000b1d00000|  0%| F|  |TAMS 0x00000000b1c00000, 0x00000000b1c00000| Untracked 
| 797|0x00000000b1d00000, 0x00000000b1d00000, 0x00000000b1e00000|  0%| F|  |TAMS 0x00000000b1d00000, 0x00000000b1d00000| Untracked 
| 798|0x00000000b1e00000, 0x00000000b1e00000, 0x00000000b1f00000|  0%| F|  |TAMS 0x00000000b1e00000, 0x00000000b1e00000| Untracked 
| 799|0x00000000b1f00000, 0x00000000b1f00000, 0x00000000b2000000|  0%| F|  |TAMS 0x00000000b1f00000, 0x00000000b1f00000| Untracked 
| 800|0x00000000b2000000, 0x00000000b2000000, 0x00000000b2100000|  0%| F|  |TAMS 0x00000000b2000000, 0x00000000b2000000| Untracked 
| 801|0x00000000b2100000, 0x00000000b2100000, 0x00000000b2200000|  0%| F|  |TAMS 0x00000000b2100000, 0x00000000b2100000| Untracked 
| 802|0x00000000b2200000, 0x00000000b2200000, 0x00000000b2300000|  0%| F|  |TAMS 0x00000000b2200000, 0x00000000b2200000| Untracked 
| 803|0x00000000b2300000, 0x00000000b2300000, 0x00000000b2400000|  0%| F|  |TAMS 0x00000000b2300000, 0x00000000b2300000| Untracked 
| 804|0x00000000b2400000, 0x00000000b2400000, 0x00000000b2500000|  0%| F|  |TAMS 0x00000000b2400000, 0x00000000b2400000| Untracked 
| 805|0x00000000b2500000, 0x00000000b2500000, 0x00000000b2600000|  0%| F|  |TAMS 0x00000000b2500000, 0x00000000b2500000| Untracked 
| 806|0x00000000b2600000, 0x00000000b2600000, 0x00000000b2700000|  0%| F|  |TAMS 0x00000000b2600000, 0x00000000b2600000| Untracked 
| 807|0x00000000b2700000, 0x00000000b2700000, 0x00000000b2800000|  0%| F|  |TAMS 0x00000000b2700000, 0x00000000b2700000| Untracked 
| 808|0x00000000b2800000, 0x00000000b2800000, 0x00000000b2900000|  0%| F|  |TAMS 0x00000000b2800000, 0x00000000b2800000| Untracked 
| 809|0x00000000b2900000, 0x00000000b2900000, 0x00000000b2a00000|  0%| F|  |TAMS 0x00000000b2900000, 0x00000000b2900000| Untracked 
| 810|0x00000000b2a00000, 0x00000000b2a00000, 0x00000000b2b00000|  0%| F|  |TAMS 0x00000000b2a00000, 0x00000000b2a00000| Untracked 
| 811|0x00000000b2b00000, 0x00000000b2b00000, 0x00000000b2c00000|  0%| F|  |TAMS 0x00000000b2b00000, 0x00000000b2b00000| Untracked 
| 812|0x00000000b2c00000, 0x00000000b2c00000, 0x00000000b2d00000|  0%| F|  |TAMS 0x00000000b2c00000, 0x00000000b2c00000| Untracked 
| 813|0x00000000b2d00000, 0x00000000b2d00000, 0x00000000b2e00000|  0%| F|  |TAMS 0x00000000b2d00000, 0x00000000b2d00000| Untracked 
| 814|0x00000000b2e00000, 0x00000000b2e00000, 0x00000000b2f00000|  0%| F|  |TAMS 0x00000000b2e00000, 0x00000000b2e00000| Untracked 
| 815|0x00000000b2f00000, 0x00000000b2f00000, 0x00000000b3000000|  0%| F|  |TAMS 0x00000000b2f00000, 0x00000000b2f00000| Untracked 
| 816|0x00000000b3000000, 0x00000000b3000000, 0x00000000b3100000|  0%| F|  |TAMS 0x00000000b3000000, 0x00000000b3000000| Untracked 
| 817|0x00000000b3100000, 0x00000000b3100000, 0x00000000b3200000|  0%| F|  |TAMS 0x00000000b3100000, 0x00000000b3100000| Untracked 
| 818|0x00000000b3200000, 0x00000000b3200000, 0x00000000b3300000|  0%| F|  |TAMS 0x00000000b3200000, 0x00000000b3200000| Untracked 
| 819|0x00000000b3300000, 0x00000000b3300000, 0x00000000b3400000|  0%| F|  |TAMS 0x00000000b3300000, 0x00000000b3300000| Untracked 
| 820|0x00000000b3400000, 0x00000000b3400000, 0x00000000b3500000|  0%| F|  |TAMS 0x00000000b3400000, 0x00000000b3400000| Untracked 
| 821|0x00000000b3500000, 0x00000000b3500000, 0x00000000b3600000|  0%| F|  |TAMS 0x00000000b3500000, 0x00000000b3500000| Untracked 
| 822|0x00000000b3600000, 0x00000000b3600000, 0x00000000b3700000|  0%| F|  |TAMS 0x00000000b3600000, 0x00000000b3600000| Untracked 
| 823|0x00000000b3700000, 0x00000000b3700000, 0x00000000b3800000|  0%| F|  |TAMS 0x00000000b3700000, 0x00000000b3700000| Untracked 
| 824|0x00000000b3800000, 0x00000000b3800000, 0x00000000b3900000|  0%| F|  |TAMS 0x00000000b3800000, 0x00000000b3800000| Untracked 
| 825|0x00000000b3900000, 0x00000000b3900000, 0x00000000b3a00000|  0%| F|  |TAMS 0x00000000b3900000, 0x00000000b3900000| Untracked 
| 826|0x00000000b3a00000, 0x00000000b3a00000, 0x00000000b3b00000|  0%| F|  |TAMS 0x00000000b3a00000, 0x00000000b3a00000| Untracked 
| 827|0x00000000b3b00000, 0x00000000b3b00000, 0x00000000b3c00000|  0%| F|  |TAMS 0x00000000b3b00000, 0x00000000b3b00000| Untracked 
| 828|0x00000000b3c00000, 0x00000000b3c00000, 0x00000000b3d00000|  0%| F|  |TAMS 0x00000000b3c00000, 0x00000000b3c00000| Untracked 
| 829|0x00000000b3d00000, 0x00000000b3d00000, 0x00000000b3e00000|  0%| F|  |TAMS 0x00000000b3d00000, 0x00000000b3d00000| Untracked 
| 830|0x00000000b3e00000, 0x00000000b3e00000, 0x00000000b3f00000|  0%| F|  |TAMS 0x00000000b3e00000, 0x00000000b3e00000| Untracked 
| 831|0x00000000b3f00000, 0x00000000b3f00000, 0x00000000b4000000|  0%| F|  |TAMS 0x00000000b3f00000, 0x00000000b3f00000| Untracked 
| 832|0x00000000b4000000, 0x00000000b4000000, 0x00000000b4100000|  0%| F|  |TAMS 0x00000000b4000000, 0x00000000b4000000| Untracked 
| 833|0x00000000b4100000, 0x00000000b4100000, 0x00000000b4200000|  0%| F|  |TAMS 0x00000000b4100000, 0x00000000b4100000| Untracked 
| 834|0x00000000b4200000, 0x00000000b4200000, 0x00000000b4300000|  0%| F|  |TAMS 0x00000000b4200000, 0x00000000b4200000| Untracked 
| 835|0x00000000b4300000, 0x00000000b4300000, 0x00000000b4400000|  0%| F|  |TAMS 0x00000000b4300000, 0x00000000b4300000| Untracked 
| 836|0x00000000b4400000, 0x00000000b4400000, 0x00000000b4500000|  0%| F|  |TAMS 0x00000000b4400000, 0x00000000b4400000| Untracked 
| 837|0x00000000b4500000, 0x00000000b4500000, 0x00000000b4600000|  0%| F|  |TAMS 0x00000000b4500000, 0x00000000b4500000| Untracked 
| 838|0x00000000b4600000, 0x00000000b4600000, 0x00000000b4700000|  0%| F|  |TAMS 0x00000000b4600000, 0x00000000b4600000| Untracked 
| 839|0x00000000b4700000, 0x00000000b4700000, 0x00000000b4800000|  0%| F|  |TAMS 0x00000000b4700000, 0x00000000b4700000| Untracked 
| 840|0x00000000b4800000, 0x00000000b4800000, 0x00000000b4900000|  0%| F|  |TAMS 0x00000000b4800000, 0x00000000b4800000| Untracked 
| 841|0x00000000b4900000, 0x00000000b4900000, 0x00000000b4a00000|  0%| F|  |TAMS 0x00000000b4900000, 0x00000000b4900000| Untracked 
| 842|0x00000000b4a00000, 0x00000000b4a00000, 0x00000000b4b00000|  0%| F|  |TAMS 0x00000000b4a00000, 0x00000000b4a00000| Untracked 
| 843|0x00000000b4b00000, 0x00000000b4b00000, 0x00000000b4c00000|  0%| F|  |TAMS 0x00000000b4b00000, 0x00000000b4b00000| Untracked 
| 844|0x00000000b4c00000, 0x00000000b4c00000, 0x00000000b4d00000|  0%| F|  |TAMS 0x00000000b4c00000, 0x00000000b4c00000| Untracked 
| 845|0x00000000b4d00000, 0x00000000b4d00000, 0x00000000b4e00000|  0%| F|  |TAMS 0x00000000b4d00000, 0x00000000b4d00000| Untracked 
| 846|0x00000000b4e00000, 0x00000000b4e00000, 0x00000000b4f00000|  0%| F|  |TAMS 0x00000000b4e00000, 0x00000000b4e00000| Untracked 
| 847|0x00000000b4f00000, 0x00000000b4f00000, 0x00000000b5000000|  0%| F|  |TAMS 0x00000000b4f00000, 0x00000000b4f00000| Untracked 
| 848|0x00000000b5000000, 0x00000000b5000000, 0x00000000b5100000|  0%| F|  |TAMS 0x00000000b5000000, 0x00000000b5000000| Untracked 
| 849|0x00000000b5100000, 0x00000000b5100000, 0x00000000b5200000|  0%| F|  |TAMS 0x00000000b5100000, 0x00000000b5100000| Untracked 
| 850|0x00000000b5200000, 0x00000000b5200000, 0x00000000b5300000|  0%| F|  |TAMS 0x00000000b5200000, 0x00000000b5200000| Untracked 
| 851|0x00000000b5300000, 0x00000000b5300000, 0x00000000b5400000|  0%| F|  |TAMS 0x00000000b5300000, 0x00000000b5300000| Untracked 
| 852|0x00000000b5400000, 0x00000000b5400000, 0x00000000b5500000|  0%| F|  |TAMS 0x00000000b5400000, 0x00000000b5400000| Untracked 
| 853|0x00000000b5500000, 0x00000000b5500000, 0x00000000b5600000|  0%| F|  |TAMS 0x00000000b5500000, 0x00000000b5500000| Untracked 
| 854|0x00000000b5600000, 0x00000000b5600000, 0x00000000b5700000|  0%| F|  |TAMS 0x00000000b5600000, 0x00000000b5600000| Untracked 
| 855|0x00000000b5700000, 0x00000000b5700000, 0x00000000b5800000|  0%| F|  |TAMS 0x00000000b5700000, 0x00000000b5700000| Untracked 
| 856|0x00000000b5800000, 0x00000000b5800000, 0x00000000b5900000|  0%| F|  |TAMS 0x00000000b5800000, 0x00000000b5800000| Untracked 
| 857|0x00000000b5900000, 0x00000000b5900000, 0x00000000b5a00000|  0%| F|  |TAMS 0x00000000b5900000, 0x00000000b5900000| Untracked 
| 858|0x00000000b5a00000, 0x00000000b5a00000, 0x00000000b5b00000|  0%| F|  |TAMS 0x00000000b5a00000, 0x00000000b5a00000| Untracked 
| 859|0x00000000b5b00000, 0x00000000b5b00000, 0x00000000b5c00000|  0%| F|  |TAMS 0x00000000b5b00000, 0x00000000b5b00000| Untracked 
| 860|0x00000000b5c00000, 0x00000000b5c00000, 0x00000000b5d00000|  0%| F|  |TAMS 0x00000000b5c00000, 0x00000000b5c00000| Untracked 
| 861|0x00000000b5d00000, 0x00000000b5d00000, 0x00000000b5e00000|  0%| F|  |TAMS 0x00000000b5d00000, 0x00000000b5d00000| Untracked 
| 862|0x00000000b5e00000, 0x00000000b5e00000, 0x00000000b5f00000|  0%| F|  |TAMS 0x00000000b5e00000, 0x00000000b5e00000| Untracked 
| 863|0x00000000b5f00000, 0x00000000b5f00000, 0x00000000b6000000|  0%| F|  |TAMS 0x00000000b5f00000, 0x00000000b5f00000| Untracked 
| 864|0x00000000b6000000, 0x00000000b6000000, 0x00000000b6100000|  0%| F|  |TAMS 0x00000000b6000000, 0x00000000b6000000| Untracked 
| 865|0x00000000b6100000, 0x00000000b6100000, 0x00000000b6200000|  0%| F|  |TAMS 0x00000000b6100000, 0x00000000b6100000| Untracked 
| 866|0x00000000b6200000, 0x00000000b6200000, 0x00000000b6300000|  0%| F|  |TAMS 0x00000000b6200000, 0x00000000b6200000| Untracked 
| 867|0x00000000b6300000, 0x00000000b6300000, 0x00000000b6400000|  0%| F|  |TAMS 0x00000000b6300000, 0x00000000b6300000| Untracked 
| 868|0x00000000b6400000, 0x00000000b6400000, 0x00000000b6500000|  0%| F|  |TAMS 0x00000000b6400000, 0x00000000b6400000| Untracked 
| 869|0x00000000b6500000, 0x00000000b6500000, 0x00000000b6600000|  0%| F|  |TAMS 0x00000000b6500000, 0x00000000b6500000| Untracked 
| 870|0x00000000b6600000, 0x00000000b6600000, 0x00000000b6700000|  0%| F|  |TAMS 0x00000000b6600000, 0x00000000b6600000| Untracked 
| 871|0x00000000b6700000, 0x00000000b6700000, 0x00000000b6800000|  0%| F|  |TAMS 0x00000000b6700000, 0x00000000b6700000| Untracked 
| 872|0x00000000b6800000, 0x00000000b6800000, 0x00000000b6900000|  0%| F|  |TAMS 0x00000000b6800000, 0x00000000b6800000| Untracked 
| 873|0x00000000b6900000, 0x00000000b6900000, 0x00000000b6a00000|  0%| F|  |TAMS 0x00000000b6900000, 0x00000000b6900000| Untracked 
| 874|0x00000000b6a00000, 0x00000000b6a00000, 0x00000000b6b00000|  0%| F|  |TAMS 0x00000000b6a00000, 0x00000000b6a00000| Untracked 
| 875|0x00000000b6b00000, 0x00000000b6b00000, 0x00000000b6c00000|  0%| F|  |TAMS 0x00000000b6b00000, 0x00000000b6b00000| Untracked 
| 876|0x00000000b6c00000, 0x00000000b6c00000, 0x00000000b6d00000|  0%| F|  |TAMS 0x00000000b6c00000, 0x00000000b6c00000| Untracked 
| 877|0x00000000b6d00000, 0x00000000b6d00000, 0x00000000b6e00000|  0%| F|  |TAMS 0x00000000b6d00000, 0x00000000b6d00000| Untracked 
| 878|0x00000000b6e00000, 0x00000000b6e00000, 0x00000000b6f00000|  0%| F|  |TAMS 0x00000000b6e00000, 0x00000000b6e00000| Untracked 
| 879|0x00000000b6f00000, 0x00000000b6f00000, 0x00000000b7000000|  0%| F|  |TAMS 0x00000000b6f00000, 0x00000000b6f00000| Untracked 
| 880|0x00000000b7000000, 0x00000000b7000000, 0x00000000b7100000|  0%| F|  |TAMS 0x00000000b7000000, 0x00000000b7000000| Untracked 
| 881|0x00000000b7100000, 0x00000000b7100000, 0x00000000b7200000|  0%| F|  |TAMS 0x00000000b7100000, 0x00000000b7100000| Untracked 
| 882|0x00000000b7200000, 0x00000000b7200000, 0x00000000b7300000|  0%| F|  |TAMS 0x00000000b7200000, 0x00000000b7200000| Untracked 
| 883|0x00000000b7300000, 0x00000000b7300000, 0x00000000b7400000|  0%| F|  |TAMS 0x00000000b7300000, 0x00000000b7300000| Untracked 
| 884|0x00000000b7400000, 0x00000000b7400000, 0x00000000b7500000|  0%| F|  |TAMS 0x00000000b7400000, 0x00000000b7400000| Untracked 
| 885|0x00000000b7500000, 0x00000000b7500000, 0x00000000b7600000|  0%| F|  |TAMS 0x00000000b7500000, 0x00000000b7500000| Untracked 
| 886|0x00000000b7600000, 0x00000000b7600000, 0x00000000b7700000|  0%| F|  |TAMS 0x00000000b7600000, 0x00000000b7600000| Untracked 
| 887|0x00000000b7700000, 0x00000000b7700000, 0x00000000b7800000|  0%| F|  |TAMS 0x00000000b7700000, 0x00000000b7700000| Untracked 
| 888|0x00000000b7800000, 0x00000000b7800000, 0x00000000b7900000|  0%| F|  |TAMS 0x00000000b7800000, 0x00000000b7800000| Untracked 
| 889|0x00000000b7900000, 0x00000000b7900000, 0x00000000b7a00000|  0%| F|  |TAMS 0x00000000b7900000, 0x00000000b7900000| Untracked 
| 890|0x00000000b7a00000, 0x00000000b7a00000, 0x00000000b7b00000|  0%| F|  |TAMS 0x00000000b7a00000, 0x00000000b7a00000| Untracked 
| 891|0x00000000b7b00000, 0x00000000b7b00000, 0x00000000b7c00000|  0%| F|  |TAMS 0x00000000b7b00000, 0x00000000b7b00000| Untracked 
| 892|0x00000000b7c00000, 0x00000000b7c00000, 0x00000000b7d00000|  0%| F|  |TAMS 0x00000000b7c00000, 0x00000000b7c00000| Untracked 
| 893|0x00000000b7d00000, 0x00000000b7d00000, 0x00000000b7e00000|  0%| F|  |TAMS 0x00000000b7d00000, 0x00000000b7d00000| Untracked 
| 894|0x00000000b7e00000, 0x00000000b7e00000, 0x00000000b7f00000|  0%| F|  |TAMS 0x00000000b7e00000, 0x00000000b7e00000| Untracked 
| 895|0x00000000b7f00000, 0x00000000b7f00000, 0x00000000b8000000|  0%| F|  |TAMS 0x00000000b7f00000, 0x00000000b7f00000| Untracked 
| 896|0x00000000b8000000, 0x00000000b8000000, 0x00000000b8100000|  0%| F|  |TAMS 0x00000000b8000000, 0x00000000b8000000| Untracked 
| 897|0x00000000b8100000, 0x00000000b8100000, 0x00000000b8200000|  0%| F|  |TAMS 0x00000000b8100000, 0x00000000b8100000| Untracked 
| 898|0x00000000b8200000, 0x00000000b8200000, 0x00000000b8300000|  0%| F|  |TAMS 0x00000000b8200000, 0x00000000b8200000| Untracked 
| 899|0x00000000b8300000, 0x00000000b8300000, 0x00000000b8400000|  0%| F|  |TAMS 0x00000000b8300000, 0x00000000b8300000| Untracked 
| 900|0x00000000b8400000, 0x00000000b8400000, 0x00000000b8500000|  0%| F|  |TAMS 0x00000000b8400000, 0x00000000b8400000| Untracked 
| 901|0x00000000b8500000, 0x00000000b8500000, 0x00000000b8600000|  0%| F|  |TAMS 0x00000000b8500000, 0x00000000b8500000| Untracked 
| 902|0x00000000b8600000, 0x00000000b8600000, 0x00000000b8700000|  0%| F|  |TAMS 0x00000000b8600000, 0x00000000b8600000| Untracked 
| 903|0x00000000b8700000, 0x00000000b8700000, 0x00000000b8800000|  0%| F|  |TAMS 0x00000000b8700000, 0x00000000b8700000| Untracked 
| 904|0x00000000b8800000, 0x00000000b8800000, 0x00000000b8900000|  0%| F|  |TAMS 0x00000000b8800000, 0x00000000b8800000| Untracked 
| 905|0x00000000b8900000, 0x00000000b8900000, 0x00000000b8a00000|  0%| F|  |TAMS 0x00000000b8900000, 0x00000000b8900000| Untracked 
| 906|0x00000000b8a00000, 0x00000000b8a00000, 0x00000000b8b00000|  0%| F|  |TAMS 0x00000000b8a00000, 0x00000000b8a00000| Untracked 
| 907|0x00000000b8b00000, 0x00000000b8b00000, 0x00000000b8c00000|  0%| F|  |TAMS 0x00000000b8b00000, 0x00000000b8b00000| Untracked 
| 908|0x00000000b8c00000, 0x00000000b8c00000, 0x00000000b8d00000|  0%| F|  |TAMS 0x00000000b8c00000, 0x00000000b8c00000| Untracked 
| 909|0x00000000b8d00000, 0x00000000b8d00000, 0x00000000b8e00000|  0%| F|  |TAMS 0x00000000b8d00000, 0x00000000b8d00000| Untracked 
| 910|0x00000000b8e00000, 0x00000000b8e00000, 0x00000000b8f00000|  0%| F|  |TAMS 0x00000000b8e00000, 0x00000000b8e00000| Untracked 
| 911|0x00000000b8f00000, 0x00000000b8f00000, 0x00000000b9000000|  0%| F|  |TAMS 0x00000000b8f00000, 0x00000000b8f00000| Untracked 
| 912|0x00000000b9000000, 0x00000000b9000000, 0x00000000b9100000|  0%| F|  |TAMS 0x00000000b9000000, 0x00000000b9000000| Untracked 
| 913|0x00000000b9100000, 0x00000000b9100000, 0x00000000b9200000|  0%| F|  |TAMS 0x00000000b9100000, 0x00000000b9100000| Untracked 
| 914|0x00000000b9200000, 0x00000000b9200000, 0x00000000b9300000|  0%| F|  |TAMS 0x00000000b9200000, 0x00000000b9200000| Untracked 
| 915|0x00000000b9300000, 0x00000000b9300000, 0x00000000b9400000|  0%| F|  |TAMS 0x00000000b9300000, 0x00000000b9300000| Untracked 
| 916|0x00000000b9400000, 0x00000000b9400000, 0x00000000b9500000|  0%| F|  |TAMS 0x00000000b9400000, 0x00000000b9400000| Untracked 
| 917|0x00000000b9500000, 0x00000000b9500000, 0x00000000b9600000|  0%| F|  |TAMS 0x00000000b9500000, 0x00000000b9500000| Untracked 
| 918|0x00000000b9600000, 0x00000000b9600000, 0x00000000b9700000|  0%| F|  |TAMS 0x00000000b9600000, 0x00000000b9600000| Untracked 
| 919|0x00000000b9700000, 0x00000000b9700000, 0x00000000b9800000|  0%| F|  |TAMS 0x00000000b9700000, 0x00000000b9700000| Untracked 
| 920|0x00000000b9800000, 0x00000000b9800000, 0x00000000b9900000|  0%| F|  |TAMS 0x00000000b9800000, 0x00000000b9800000| Untracked 
| 921|0x00000000b9900000, 0x00000000b9900000, 0x00000000b9a00000|  0%| F|  |TAMS 0x00000000b9900000, 0x00000000b9900000| Untracked 
| 922|0x00000000b9a00000, 0x00000000b9a00000, 0x00000000b9b00000|  0%| F|  |TAMS 0x00000000b9a00000, 0x00000000b9a00000| Untracked 
| 923|0x00000000b9b00000, 0x00000000b9b00000, 0x00000000b9c00000|  0%| F|  |TAMS 0x00000000b9b00000, 0x00000000b9b00000| Untracked 
| 924|0x00000000b9c00000, 0x00000000b9c00000, 0x00000000b9d00000|  0%| F|  |TAMS 0x00000000b9c00000, 0x00000000b9c00000| Untracked 
| 925|0x00000000b9d00000, 0x00000000b9d00000, 0x00000000b9e00000|  0%| F|  |TAMS 0x00000000b9d00000, 0x00000000b9d00000| Untracked 
| 926|0x00000000b9e00000, 0x00000000b9e00000, 0x00000000b9f00000|  0%| F|  |TAMS 0x00000000b9e00000, 0x00000000b9e00000| Untracked 
| 927|0x00000000b9f00000, 0x00000000b9f00000, 0x00000000ba000000|  0%| F|  |TAMS 0x00000000b9f00000, 0x00000000b9f00000| Untracked 
| 928|0x00000000ba000000, 0x00000000ba000000, 0x00000000ba100000|  0%| F|  |TAMS 0x00000000ba000000, 0x00000000ba000000| Untracked 
| 929|0x00000000ba100000, 0x00000000ba100000, 0x00000000ba200000|  0%| F|  |TAMS 0x00000000ba100000, 0x00000000ba100000| Untracked 
| 930|0x00000000ba200000, 0x00000000ba200000, 0x00000000ba300000|  0%| F|  |TAMS 0x00000000ba200000, 0x00000000ba200000| Untracked 
| 931|0x00000000ba300000, 0x00000000ba300000, 0x00000000ba400000|  0%| F|  |TAMS 0x00000000ba300000, 0x00000000ba300000| Untracked 
| 932|0x00000000ba400000, 0x00000000ba400000, 0x00000000ba500000|  0%| F|  |TAMS 0x00000000ba400000, 0x00000000ba400000| Untracked 
| 933|0x00000000ba500000, 0x00000000ba500000, 0x00000000ba600000|  0%| F|  |TAMS 0x00000000ba500000, 0x00000000ba500000| Untracked 
| 934|0x00000000ba600000, 0x00000000ba600000, 0x00000000ba700000|  0%| F|  |TAMS 0x00000000ba600000, 0x00000000ba600000| Untracked 
| 935|0x00000000ba700000, 0x00000000ba700000, 0x00000000ba800000|  0%| F|  |TAMS 0x00000000ba700000, 0x00000000ba700000| Untracked 
| 936|0x00000000ba800000, 0x00000000ba800000, 0x00000000ba900000|  0%| F|  |TAMS 0x00000000ba800000, 0x00000000ba800000| Untracked 
| 937|0x00000000ba900000, 0x00000000ba900000, 0x00000000baa00000|  0%| F|  |TAMS 0x00000000ba900000, 0x00000000ba900000| Untracked 
| 938|0x00000000baa00000, 0x00000000baa00000, 0x00000000bab00000|  0%| F|  |TAMS 0x00000000baa00000, 0x00000000baa00000| Untracked 
| 939|0x00000000bab00000, 0x00000000bab00000, 0x00000000bac00000|  0%| F|  |TAMS 0x00000000bab00000, 0x00000000bab00000| Untracked 
| 940|0x00000000bac00000, 0x00000000bac00000, 0x00000000bad00000|  0%| F|  |TAMS 0x00000000bac00000, 0x00000000bac00000| Untracked 
| 941|0x00000000bad00000, 0x00000000bad00000, 0x00000000bae00000|  0%| F|  |TAMS 0x00000000bad00000, 0x00000000bad00000| Untracked 
| 942|0x00000000bae00000, 0x00000000bae00000, 0x00000000baf00000|  0%| F|  |TAMS 0x00000000bae00000, 0x00000000bae00000| Untracked 
| 943|0x00000000baf00000, 0x00000000baf00000, 0x00000000bb000000|  0%| F|  |TAMS 0x00000000baf00000, 0x00000000baf00000| Untracked 
| 944|0x00000000bb000000, 0x00000000bb000000, 0x00000000bb100000|  0%| F|  |TAMS 0x00000000bb000000, 0x00000000bb000000| Untracked 
| 945|0x00000000bb100000, 0x00000000bb100000, 0x00000000bb200000|  0%| F|  |TAMS 0x00000000bb100000, 0x00000000bb100000| Untracked 
| 946|0x00000000bb200000, 0x00000000bb200000, 0x00000000bb300000|  0%| F|  |TAMS 0x00000000bb200000, 0x00000000bb200000| Untracked 
| 947|0x00000000bb300000, 0x00000000bb300000, 0x00000000bb400000|  0%| F|  |TAMS 0x00000000bb300000, 0x00000000bb300000| Untracked 
| 948|0x00000000bb400000, 0x00000000bb400000, 0x00000000bb500000|  0%| F|  |TAMS 0x00000000bb400000, 0x00000000bb400000| Untracked 
| 949|0x00000000bb500000, 0x00000000bb500000, 0x00000000bb600000|  0%| F|  |TAMS 0x00000000bb500000, 0x00000000bb500000| Untracked 
| 950|0x00000000bb600000, 0x00000000bb600000, 0x00000000bb700000|  0%| F|  |TAMS 0x00000000bb600000, 0x00000000bb600000| Untracked 
| 951|0x00000000bb700000, 0x00000000bb700000, 0x00000000bb800000|  0%| F|  |TAMS 0x00000000bb700000, 0x00000000bb700000| Untracked 
| 952|0x00000000bb800000, 0x00000000bb800000, 0x00000000bb900000|  0%| F|  |TAMS 0x00000000bb800000, 0x00000000bb800000| Untracked 
| 953|0x00000000bb900000, 0x00000000bb900000, 0x00000000bba00000|  0%| F|  |TAMS 0x00000000bb900000, 0x00000000bb900000| Untracked 
| 954|0x00000000bba00000, 0x00000000bba00000, 0x00000000bbb00000|  0%| F|  |TAMS 0x00000000bba00000, 0x00000000bba00000| Untracked 
| 955|0x00000000bbb00000, 0x00000000bbb00000, 0x00000000bbc00000|  0%| F|  |TAMS 0x00000000bbb00000, 0x00000000bbb00000| Untracked 
| 956|0x00000000bbc00000, 0x00000000bbc00000, 0x00000000bbd00000|  0%| F|  |TAMS 0x00000000bbc00000, 0x00000000bbc00000| Untracked 
| 957|0x00000000bbd00000, 0x00000000bbd00000, 0x00000000bbe00000|  0%| F|  |TAMS 0x00000000bbd00000, 0x00000000bbd00000| Untracked 
| 958|0x00000000bbe00000, 0x00000000bbe00000, 0x00000000bbf00000|  0%| F|  |TAMS 0x00000000bbe00000, 0x00000000bbe00000| Untracked 
| 959|0x00000000bbf00000, 0x00000000bbf00000, 0x00000000bc000000|  0%| F|  |TAMS 0x00000000bbf00000, 0x00000000bbf00000| Untracked 
| 960|0x00000000bc000000, 0x00000000bc000000, 0x00000000bc100000|  0%| F|  |TAMS 0x00000000bc000000, 0x00000000bc000000| Untracked 
| 961|0x00000000bc100000, 0x00000000bc100000, 0x00000000bc200000|  0%| F|  |TAMS 0x00000000bc100000, 0x00000000bc100000| Untracked 
| 962|0x00000000bc200000, 0x00000000bc200000, 0x00000000bc300000|  0%| F|  |TAMS 0x00000000bc200000, 0x00000000bc200000| Untracked 
| 963|0x00000000bc300000, 0x00000000bc300000, 0x00000000bc400000|  0%| F|  |TAMS 0x00000000bc300000, 0x00000000bc300000| Untracked 
| 964|0x00000000bc400000, 0x00000000bc400000, 0x00000000bc500000|  0%| F|  |TAMS 0x00000000bc400000, 0x00000000bc400000| Untracked 
| 965|0x00000000bc500000, 0x00000000bc500000, 0x00000000bc600000|  0%| F|  |TAMS 0x00000000bc500000, 0x00000000bc500000| Untracked 
| 966|0x00000000bc600000, 0x00000000bc600000, 0x00000000bc700000|  0%| F|  |TAMS 0x00000000bc600000, 0x00000000bc600000| Untracked 
| 967|0x00000000bc700000, 0x00000000bc700000, 0x00000000bc800000|  0%| F|  |TAMS 0x00000000bc700000, 0x00000000bc700000| Untracked 
| 968|0x00000000bc800000, 0x00000000bc800000, 0x00000000bc900000|  0%| F|  |TAMS 0x00000000bc800000, 0x00000000bc800000| Untracked 
| 969|0x00000000bc900000, 0x00000000bc900000, 0x00000000bca00000|  0%| F|  |TAMS 0x00000000bc900000, 0x00000000bc900000| Untracked 
| 970|0x00000000bca00000, 0x00000000bca00000, 0x00000000bcb00000|  0%| F|  |TAMS 0x00000000bca00000, 0x00000000bca00000| Untracked 
| 971|0x00000000bcb00000, 0x00000000bcb00000, 0x00000000bcc00000|  0%| F|  |TAMS 0x00000000bcb00000, 0x00000000bcb00000| Untracked 
| 972|0x00000000bcc00000, 0x00000000bcc00000, 0x00000000bcd00000|  0%| F|  |TAMS 0x00000000bcc00000, 0x00000000bcc00000| Untracked 
| 973|0x00000000bcd00000, 0x00000000bcd00000, 0x00000000bce00000|  0%| F|  |TAMS 0x00000000bcd00000, 0x00000000bcd00000| Untracked 
| 974|0x00000000bce00000, 0x00000000bce00000, 0x00000000bcf00000|  0%| F|  |TAMS 0x00000000bce00000, 0x00000000bce00000| Untracked 
| 975|0x00000000bcf00000, 0x00000000bcf00000, 0x00000000bd000000|  0%| F|  |TAMS 0x00000000bcf00000, 0x00000000bcf00000| Untracked 
| 976|0x00000000bd000000, 0x00000000bd000000, 0x00000000bd100000|  0%| F|  |TAMS 0x00000000bd000000, 0x00000000bd000000| Untracked 
| 977|0x00000000bd100000, 0x00000000bd100000, 0x00000000bd200000|  0%| F|  |TAMS 0x00000000bd100000, 0x00000000bd100000| Untracked 
| 978|0x00000000bd200000, 0x00000000bd200000, 0x00000000bd300000|  0%| F|  |TAMS 0x00000000bd200000, 0x00000000bd200000| Untracked 
| 979|0x00000000bd300000, 0x00000000bd300000, 0x00000000bd400000|  0%| F|  |TAMS 0x00000000bd300000, 0x00000000bd300000| Untracked 
| 980|0x00000000bd400000, 0x00000000bd400000, 0x00000000bd500000|  0%| F|  |TAMS 0x00000000bd400000, 0x00000000bd400000| Untracked 
| 981|0x00000000bd500000, 0x00000000bd500000, 0x00000000bd600000|  0%| F|  |TAMS 0x00000000bd500000, 0x00000000bd500000| Untracked 
| 982|0x00000000bd600000, 0x00000000bd600000, 0x00000000bd700000|  0%| F|  |TAMS 0x00000000bd600000, 0x00000000bd600000| Untracked 
| 983|0x00000000bd700000, 0x00000000bd700000, 0x00000000bd800000|  0%| F|  |TAMS 0x00000000bd700000, 0x00000000bd700000| Untracked 
| 984|0x00000000bd800000, 0x00000000bd800000, 0x00000000bd900000|  0%| F|  |TAMS 0x00000000bd800000, 0x00000000bd800000| Untracked 
| 985|0x00000000bd900000, 0x00000000bd900000, 0x00000000bda00000|  0%| F|  |TAMS 0x00000000bd900000, 0x00000000bd900000| Untracked 
| 986|0x00000000bda00000, 0x00000000bda00000, 0x00000000bdb00000|  0%| F|  |TAMS 0x00000000bda00000, 0x00000000bda00000| Untracked 
| 987|0x00000000bdb00000, 0x00000000bdb00000, 0x00000000bdc00000|  0%| F|  |TAMS 0x00000000bdb00000, 0x00000000bdb00000| Untracked 
| 988|0x00000000bdc00000, 0x00000000bdc00000, 0x00000000bdd00000|  0%| F|  |TAMS 0x00000000bdc00000, 0x00000000bdc00000| Untracked 
| 989|0x00000000bdd00000, 0x00000000bdd00000, 0x00000000bde00000|  0%| F|  |TAMS 0x00000000bdd00000, 0x00000000bdd00000| Untracked 
| 990|0x00000000bde00000, 0x00000000bde00000, 0x00000000bdf00000|  0%| F|  |TAMS 0x00000000bde00000, 0x00000000bde00000| Untracked 
| 991|0x00000000bdf00000, 0x00000000bdf00000, 0x00000000be000000|  0%| F|  |TAMS 0x00000000bdf00000, 0x00000000bdf00000| Untracked 
| 992|0x00000000be000000, 0x00000000be000000, 0x00000000be100000|  0%| F|  |TAMS 0x00000000be000000, 0x00000000be000000| Untracked 
| 993|0x00000000be100000, 0x00000000be100000, 0x00000000be200000|  0%| F|  |TAMS 0x00000000be100000, 0x00000000be100000| Untracked 
| 994|0x00000000be200000, 0x00000000be200000, 0x00000000be300000|  0%| F|  |TAMS 0x00000000be200000, 0x00000000be200000| Untracked 
| 995|0x00000000be300000, 0x00000000be300000, 0x00000000be400000|  0%| F|  |TAMS 0x00000000be300000, 0x00000000be300000| Untracked 
| 996|0x00000000be400000, 0x00000000be400000, 0x00000000be500000|  0%| F|  |TAMS 0x00000000be400000, 0x00000000be400000| Untracked 
| 997|0x00000000be500000, 0x00000000be500000, 0x00000000be600000|  0%| F|  |TAMS 0x00000000be500000, 0x00000000be500000| Untracked 
| 998|0x00000000be600000, 0x00000000be600000, 0x00000000be700000|  0%| F|  |TAMS 0x00000000be600000, 0x00000000be600000| Untracked 
| 999|0x00000000be700000, 0x00000000be700000, 0x00000000be800000|  0%| F|  |TAMS 0x00000000be700000, 0x00000000be700000| Untracked 
|1000|0x00000000be800000, 0x00000000be800000, 0x00000000be900000|  0%| F|  |TAMS 0x00000000be800000, 0x00000000be800000| Untracked 
|1001|0x00000000be900000, 0x00000000be900000, 0x00000000bea00000|  0%| F|  |TAMS 0x00000000be900000, 0x00000000be900000| Untracked 
|1002|0x00000000bea00000, 0x00000000bea00000, 0x00000000beb00000|  0%| F|  |TAMS 0x00000000bea00000, 0x00000000bea00000| Untracked 
|1003|0x00000000beb00000, 0x00000000beb00000, 0x00000000bec00000|  0%| F|  |TAMS 0x00000000beb00000, 0x00000000beb00000| Untracked 
|1004|0x00000000bec00000, 0x00000000bec00000, 0x00000000bed00000|  0%| F|  |TAMS 0x00000000bec00000, 0x00000000bec00000| Untracked 
|1005|0x00000000bed00000, 0x00000000bed00000, 0x00000000bee00000|  0%| F|  |TAMS 0x00000000bed00000, 0x00000000bed00000| Untracked 
|1006|0x00000000bee00000, 0x00000000bee00000, 0x00000000bef00000|  0%| F|  |TAMS 0x00000000bee00000, 0x00000000bee00000| Untracked 
|1007|0x00000000bef00000, 0x00000000bef00000, 0x00000000bf000000|  0%| F|  |TAMS 0x00000000bef00000, 0x00000000bef00000| Untracked 
|1008|0x00000000bf000000, 0x00000000bf000000, 0x00000000bf100000|  0%| F|  |TAMS 0x00000000bf000000, 0x00000000bf000000| Untracked 
|1009|0x00000000bf100000, 0x00000000bf100000, 0x00000000bf200000|  0%| F|  |TAMS 0x00000000bf100000, 0x00000000bf100000| Untracked 
|1010|0x00000000bf200000, 0x00000000bf200000, 0x00000000bf300000|  0%| F|  |TAMS 0x00000000bf200000, 0x00000000bf200000| Untracked 
|1011|0x00000000bf300000, 0x00000000bf300000, 0x00000000bf400000|  0%| F|  |TAMS 0x00000000bf300000, 0x00000000bf300000| Untracked 
|1012|0x00000000bf400000, 0x00000000bf400000, 0x00000000bf500000|  0%| F|  |TAMS 0x00000000bf400000, 0x00000000bf400000| Untracked 
|1013|0x00000000bf500000, 0x00000000bf500000, 0x00000000bf600000|  0%| F|  |TAMS 0x00000000bf500000, 0x00000000bf500000| Untracked 
|1014|0x00000000bf600000, 0x00000000bf600000, 0x00000000bf700000|  0%| F|  |TAMS 0x00000000bf600000, 0x00000000bf600000| Untracked 
|1015|0x00000000bf700000, 0x00000000bf700000, 0x00000000bf800000|  0%| F|  |TAMS 0x00000000bf700000, 0x00000000bf700000| Untracked 
|1016|0x00000000bf800000, 0x00000000bf800000, 0x00000000bf900000|  0%| F|  |TAMS 0x00000000bf800000, 0x00000000bf800000| Untracked 
|1017|0x00000000bf900000, 0x00000000bf900000, 0x00000000bfa00000|  0%| F|  |TAMS 0x00000000bf900000, 0x00000000bf900000| Untracked 
|1018|0x00000000bfa00000, 0x00000000bfa00000, 0x00000000bfb00000|  0%| F|  |TAMS 0x00000000bfa00000, 0x00000000bfa00000| Untracked 
|1019|0x00000000bfb00000, 0x00000000bfb00000, 0x00000000bfc00000|  0%| F|  |TAMS 0x00000000bfb00000, 0x00000000bfb00000| Untracked 
|1020|0x00000000bfc00000, 0x00000000bfc00000, 0x00000000bfd00000|  0%| F|  |TAMS 0x00000000bfc00000, 0x00000000bfc00000| Untracked 
|1021|0x00000000bfd00000, 0x00000000bfd00000, 0x00000000bfe00000|  0%| F|  |TAMS 0x00000000bfd00000, 0x00000000bfd00000| Untracked 
|1022|0x00000000bfe00000, 0x00000000bfe00000, 0x00000000bff00000|  0%| F|  |TAMS 0x00000000bfe00000, 0x00000000bfe00000| Untracked 
|1023|0x00000000bff00000, 0x00000000bff00000, 0x00000000c0000000|  0%| F|  |TAMS 0x00000000bff00000, 0x00000000bff00000| Untracked 
|1024|0x00000000c0000000, 0x00000000c0000000, 0x00000000c0100000|  0%| F|  |TAMS 0x00000000c0000000, 0x00000000c0000000| Untracked 
|1025|0x00000000c0100000, 0x00000000c0100000, 0x00000000c0200000|  0%| F|  |TAMS 0x00000000c0100000, 0x00000000c0100000| Untracked 
|1026|0x00000000c0200000, 0x00000000c0200000, 0x00000000c0300000|  0%| F|  |TAMS 0x00000000c0200000, 0x00000000c0200000| Untracked 
|1027|0x00000000c0300000, 0x00000000c0300000, 0x00000000c0400000|  0%| F|  |TAMS 0x00000000c0300000, 0x00000000c0300000| Untracked 
|1028|0x00000000c0400000, 0x00000000c0400000, 0x00000000c0500000|  0%| F|  |TAMS 0x00000000c0400000, 0x00000000c0400000| Untracked 
|1029|0x00000000c0500000, 0x00000000c0500000, 0x00000000c0600000|  0%| F|  |TAMS 0x00000000c0500000, 0x00000000c0500000| Untracked 
|1030|0x00000000c0600000, 0x00000000c0600000, 0x00000000c0700000|  0%| F|  |TAMS 0x00000000c0600000, 0x00000000c0600000| Untracked 
|1031|0x00000000c0700000, 0x00000000c0700000, 0x00000000c0800000|  0%| F|  |TAMS 0x00000000c0700000, 0x00000000c0700000| Untracked 
|1032|0x00000000c0800000, 0x00000000c0800000, 0x00000000c0900000|  0%| F|  |TAMS 0x00000000c0800000, 0x00000000c0800000| Untracked 
|1033|0x00000000c0900000, 0x00000000c0900000, 0x00000000c0a00000|  0%| F|  |TAMS 0x00000000c0900000, 0x00000000c0900000| Untracked 
|1034|0x00000000c0a00000, 0x00000000c0a00000, 0x00000000c0b00000|  0%| F|  |TAMS 0x00000000c0a00000, 0x00000000c0a00000| Untracked 
|1035|0x00000000c0b00000, 0x00000000c0b00000, 0x00000000c0c00000|  0%| F|  |TAMS 0x00000000c0b00000, 0x00000000c0b00000| Untracked 
|1036|0x00000000c0c00000, 0x00000000c0c00000, 0x00000000c0d00000|  0%| F|  |TAMS 0x00000000c0c00000, 0x00000000c0c00000| Untracked 
|1037|0x00000000c0d00000, 0x00000000c0d00000, 0x00000000c0e00000|  0%| F|  |TAMS 0x00000000c0d00000, 0x00000000c0d00000| Untracked 
|1038|0x00000000c0e00000, 0x00000000c0e00000, 0x00000000c0f00000|  0%| F|  |TAMS 0x00000000c0e00000, 0x00000000c0e00000| Untracked 
|1039|0x00000000c0f00000, 0x00000000c0f00000, 0x00000000c1000000|  0%| F|  |TAMS 0x00000000c0f00000, 0x00000000c0f00000| Untracked 
|1040|0x00000000c1000000, 0x00000000c1000000, 0x00000000c1100000|  0%| F|  |TAMS 0x00000000c1000000, 0x00000000c1000000| Untracked 
|1041|0x00000000c1100000, 0x00000000c1100000, 0x00000000c1200000|  0%| F|  |TAMS 0x00000000c1100000, 0x00000000c1100000| Untracked 
|1042|0x00000000c1200000, 0x00000000c1200000, 0x00000000c1300000|  0%| F|  |TAMS 0x00000000c1200000, 0x00000000c1200000| Untracked 
|1043|0x00000000c1300000, 0x00000000c1300000, 0x00000000c1400000|  0%| F|  |TAMS 0x00000000c1300000, 0x00000000c1300000| Untracked 
|1044|0x00000000c1400000, 0x00000000c1400000, 0x00000000c1500000|  0%| F|  |TAMS 0x00000000c1400000, 0x00000000c1400000| Untracked 
|1045|0x00000000c1500000, 0x00000000c1500000, 0x00000000c1600000|  0%| F|  |TAMS 0x00000000c1500000, 0x00000000c1500000| Untracked 
|1046|0x00000000c1600000, 0x00000000c1600000, 0x00000000c1700000|  0%| F|  |TAMS 0x00000000c1600000, 0x00000000c1600000| Untracked 
|1047|0x00000000c1700000, 0x00000000c1700000, 0x00000000c1800000|  0%| F|  |TAMS 0x00000000c1700000, 0x00000000c1700000| Untracked 
|1048|0x00000000c1800000, 0x00000000c1800000, 0x00000000c1900000|  0%| F|  |TAMS 0x00000000c1800000, 0x00000000c1800000| Untracked 
|1049|0x00000000c1900000, 0x00000000c1900000, 0x00000000c1a00000|  0%| F|  |TAMS 0x00000000c1900000, 0x00000000c1900000| Untracked 
|1050|0x00000000c1a00000, 0x00000000c1a00000, 0x00000000c1b00000|  0%| F|  |TAMS 0x00000000c1a00000, 0x00000000c1a00000| Untracked 
|1051|0x00000000c1b00000, 0x00000000c1b00000, 0x00000000c1c00000|  0%| F|  |TAMS 0x00000000c1b00000, 0x00000000c1b00000| Untracked 
|1052|0x00000000c1c00000, 0x00000000c1c00000, 0x00000000c1d00000|  0%| F|  |TAMS 0x00000000c1c00000, 0x00000000c1c00000| Untracked 
|1053|0x00000000c1d00000, 0x00000000c1d00000, 0x00000000c1e00000|  0%| F|  |TAMS 0x00000000c1d00000, 0x00000000c1d00000| Untracked 
|1054|0x00000000c1e00000, 0x00000000c1e00000, 0x00000000c1f00000|  0%| F|  |TAMS 0x00000000c1e00000, 0x00000000c1e00000| Untracked 
|1055|0x00000000c1f00000, 0x00000000c1f00000, 0x00000000c2000000|  0%| F|  |TAMS 0x00000000c1f00000, 0x00000000c1f00000| Untracked 
|1056|0x00000000c2000000, 0x00000000c2000000, 0x00000000c2100000|  0%| F|  |TAMS 0x00000000c2000000, 0x00000000c2000000| Untracked 
|1057|0x00000000c2100000, 0x00000000c2100000, 0x00000000c2200000|  0%| F|  |TAMS 0x00000000c2100000, 0x00000000c2100000| Untracked 
|1058|0x00000000c2200000, 0x00000000c2200000, 0x00000000c2300000|  0%| F|  |TAMS 0x00000000c2200000, 0x00000000c2200000| Untracked 
|1059|0x00000000c2300000, 0x00000000c2300000, 0x00000000c2400000|  0%| F|  |TAMS 0x00000000c2300000, 0x00000000c2300000| Untracked 
|1060|0x00000000c2400000, 0x00000000c2400000, 0x00000000c2500000|  0%| F|  |TAMS 0x00000000c2400000, 0x00000000c2400000| Untracked 
|1061|0x00000000c2500000, 0x00000000c2500000, 0x00000000c2600000|  0%| F|  |TAMS 0x00000000c2500000, 0x00000000c2500000| Untracked 
|1062|0x00000000c2600000, 0x00000000c2600000, 0x00000000c2700000|  0%| F|  |TAMS 0x00000000c2600000, 0x00000000c2600000| Untracked 
|1063|0x00000000c2700000, 0x00000000c2700000, 0x00000000c2800000|  0%| F|  |TAMS 0x00000000c2700000, 0x00000000c2700000| Untracked 
|1064|0x00000000c2800000, 0x00000000c2800000, 0x00000000c2900000|  0%| F|  |TAMS 0x00000000c2800000, 0x00000000c2800000| Untracked 
|1065|0x00000000c2900000, 0x00000000c2900000, 0x00000000c2a00000|  0%| F|  |TAMS 0x00000000c2900000, 0x00000000c2900000| Untracked 
|1066|0x00000000c2a00000, 0x00000000c2a00000, 0x00000000c2b00000|  0%| F|  |TAMS 0x00000000c2a00000, 0x00000000c2a00000| Untracked 
|1067|0x00000000c2b00000, 0x00000000c2b00000, 0x00000000c2c00000|  0%| F|  |TAMS 0x00000000c2b00000, 0x00000000c2b00000| Untracked 
|1068|0x00000000c2c00000, 0x00000000c2c00000, 0x00000000c2d00000|  0%| F|  |TAMS 0x00000000c2c00000, 0x00000000c2c00000| Untracked 
|1069|0x00000000c2d00000, 0x00000000c2d00000, 0x00000000c2e00000|  0%| F|  |TAMS 0x00000000c2d00000, 0x00000000c2d00000| Untracked 
|1070|0x00000000c2e00000, 0x00000000c2e00000, 0x00000000c2f00000|  0%| F|  |TAMS 0x00000000c2e00000, 0x00000000c2e00000| Untracked 
|1071|0x00000000c2f00000, 0x00000000c2f00000, 0x00000000c3000000|  0%| F|  |TAMS 0x00000000c2f00000, 0x00000000c2f00000| Untracked 
|1072|0x00000000c3000000, 0x00000000c3000000, 0x00000000c3100000|  0%| F|  |TAMS 0x00000000c3000000, 0x00000000c3000000| Untracked 
|1073|0x00000000c3100000, 0x00000000c3100000, 0x00000000c3200000|  0%| F|  |TAMS 0x00000000c3100000, 0x00000000c3100000| Untracked 
|1074|0x00000000c3200000, 0x00000000c3200000, 0x00000000c3300000|  0%| F|  |TAMS 0x00000000c3200000, 0x00000000c3200000| Untracked 
|1075|0x00000000c3300000, 0x00000000c3300000, 0x00000000c3400000|  0%| F|  |TAMS 0x00000000c3300000, 0x00000000c3300000| Untracked 
|1076|0x00000000c3400000, 0x00000000c3400000, 0x00000000c3500000|  0%| F|  |TAMS 0x00000000c3400000, 0x00000000c3400000| Untracked 
|1077|0x00000000c3500000, 0x00000000c3500000, 0x00000000c3600000|  0%| F|  |TAMS 0x00000000c3500000, 0x00000000c3500000| Untracked 
|1078|0x00000000c3600000, 0x00000000c3600000, 0x00000000c3700000|  0%| F|  |TAMS 0x00000000c3600000, 0x00000000c3600000| Untracked 
|1079|0x00000000c3700000, 0x00000000c3700000, 0x00000000c3800000|  0%| F|  |TAMS 0x00000000c3700000, 0x00000000c3700000| Untracked 
|1080|0x00000000c3800000, 0x00000000c3800000, 0x00000000c3900000|  0%| F|  |TAMS 0x00000000c3800000, 0x00000000c3800000| Untracked 
|1081|0x00000000c3900000, 0x00000000c3900000, 0x00000000c3a00000|  0%| F|  |TAMS 0x00000000c3900000, 0x00000000c3900000| Untracked 
|1082|0x00000000c3a00000, 0x00000000c3a00000, 0x00000000c3b00000|  0%| F|  |TAMS 0x00000000c3a00000, 0x00000000c3a00000| Untracked 
|1083|0x00000000c3b00000, 0x00000000c3b00000, 0x00000000c3c00000|  0%| F|  |TAMS 0x00000000c3b00000, 0x00000000c3b00000| Untracked 
|1084|0x00000000c3c00000, 0x00000000c3c00000, 0x00000000c3d00000|  0%| F|  |TAMS 0x00000000c3c00000, 0x00000000c3c00000| Untracked 
|1085|0x00000000c3d00000, 0x00000000c3d00000, 0x00000000c3e00000|  0%| F|  |TAMS 0x00000000c3d00000, 0x00000000c3d00000| Untracked 
|1086|0x00000000c3e00000, 0x00000000c3e00000, 0x00000000c3f00000|  0%| F|  |TAMS 0x00000000c3e00000, 0x00000000c3e00000| Untracked 
|1087|0x00000000c3f00000, 0x00000000c3f00000, 0x00000000c4000000|  0%| F|  |TAMS 0x00000000c3f00000, 0x00000000c3f00000| Untracked 
|1088|0x00000000c4000000, 0x00000000c4000000, 0x00000000c4100000|  0%| F|  |TAMS 0x00000000c4000000, 0x00000000c4000000| Untracked 
|1089|0x00000000c4100000, 0x00000000c4100000, 0x00000000c4200000|  0%| F|  |TAMS 0x00000000c4100000, 0x00000000c4100000| Untracked 
|1090|0x00000000c4200000, 0x00000000c4200000, 0x00000000c4300000|  0%| F|  |TAMS 0x00000000c4200000, 0x00000000c4200000| Untracked 
|1091|0x00000000c4300000, 0x00000000c4300000, 0x00000000c4400000|  0%| F|  |TAMS 0x00000000c4300000, 0x00000000c4300000| Untracked 
|1092|0x00000000c4400000, 0x00000000c4400000, 0x00000000c4500000|  0%| F|  |TAMS 0x00000000c4400000, 0x00000000c4400000| Untracked 
|1093|0x00000000c4500000, 0x00000000c4500000, 0x00000000c4600000|  0%| F|  |TAMS 0x00000000c4500000, 0x00000000c4500000| Untracked 
|1094|0x00000000c4600000, 0x00000000c4600000, 0x00000000c4700000|  0%| F|  |TAMS 0x00000000c4600000, 0x00000000c4600000| Untracked 
|1095|0x00000000c4700000, 0x00000000c4700000, 0x00000000c4800000|  0%| F|  |TAMS 0x00000000c4700000, 0x00000000c4700000| Untracked 
|1096|0x00000000c4800000, 0x00000000c4800000, 0x00000000c4900000|  0%| F|  |TAMS 0x00000000c4800000, 0x00000000c4800000| Untracked 
|1097|0x00000000c4900000, 0x00000000c4900000, 0x00000000c4a00000|  0%| F|  |TAMS 0x00000000c4900000, 0x00000000c4900000| Untracked 
|1098|0x00000000c4a00000, 0x00000000c4a00000, 0x00000000c4b00000|  0%| F|  |TAMS 0x00000000c4a00000, 0x00000000c4a00000| Untracked 
|1099|0x00000000c4b00000, 0x00000000c4b00000, 0x00000000c4c00000|  0%| F|  |TAMS 0x00000000c4b00000, 0x00000000c4b00000| Untracked 
|1100|0x00000000c4c00000, 0x00000000c4c00000, 0x00000000c4d00000|  0%| F|  |TAMS 0x00000000c4c00000, 0x00000000c4c00000| Untracked 
|1101|0x00000000c4d00000, 0x00000000c4d00000, 0x00000000c4e00000|  0%| F|  |TAMS 0x00000000c4d00000, 0x00000000c4d00000| Untracked 
|1102|0x00000000c4e00000, 0x00000000c4e00000, 0x00000000c4f00000|  0%| F|  |TAMS 0x00000000c4e00000, 0x00000000c4e00000| Untracked 
|1103|0x00000000c4f00000, 0x00000000c4f00000, 0x00000000c5000000|  0%| F|  |TAMS 0x00000000c4f00000, 0x00000000c4f00000| Untracked 
|1104|0x00000000c5000000, 0x00000000c5000000, 0x00000000c5100000|  0%| F|  |TAMS 0x00000000c5000000, 0x00000000c5000000| Untracked 
|1105|0x00000000c5100000, 0x00000000c5100000, 0x00000000c5200000|  0%| F|  |TAMS 0x00000000c5100000, 0x00000000c5100000| Untracked 
|1106|0x00000000c5200000, 0x00000000c5200000, 0x00000000c5300000|  0%| F|  |TAMS 0x00000000c5200000, 0x00000000c5200000| Untracked 
|1107|0x00000000c5300000, 0x00000000c5300000, 0x00000000c5400000|  0%| F|  |TAMS 0x00000000c5300000, 0x00000000c5300000| Untracked 
|1108|0x00000000c5400000, 0x00000000c5400000, 0x00000000c5500000|  0%| F|  |TAMS 0x00000000c5400000, 0x00000000c5400000| Untracked 
|1109|0x00000000c5500000, 0x00000000c5500000, 0x00000000c5600000|  0%| F|  |TAMS 0x00000000c5500000, 0x00000000c5500000| Untracked 
|1110|0x00000000c5600000, 0x00000000c5600000, 0x00000000c5700000|  0%| F|  |TAMS 0x00000000c5600000, 0x00000000c5600000| Untracked 
|1111|0x00000000c5700000, 0x00000000c5700000, 0x00000000c5800000|  0%| F|  |TAMS 0x00000000c5700000, 0x00000000c5700000| Untracked 
|1112|0x00000000c5800000, 0x00000000c5800000, 0x00000000c5900000|  0%| F|  |TAMS 0x00000000c5800000, 0x00000000c5800000| Untracked 
|1113|0x00000000c5900000, 0x00000000c5900000, 0x00000000c5a00000|  0%| F|  |TAMS 0x00000000c5900000, 0x00000000c5900000| Untracked 
|1114|0x00000000c5a00000, 0x00000000c5a00000, 0x00000000c5b00000|  0%| F|  |TAMS 0x00000000c5a00000, 0x00000000c5a00000| Untracked 
|1115|0x00000000c5b00000, 0x00000000c5b00000, 0x00000000c5c00000|  0%| F|  |TAMS 0x00000000c5b00000, 0x00000000c5b00000| Untracked 
|1116|0x00000000c5c00000, 0x00000000c5c00000, 0x00000000c5d00000|  0%| F|  |TAMS 0x00000000c5c00000, 0x00000000c5c00000| Untracked 
|1117|0x00000000c5d00000, 0x00000000c5d00000, 0x00000000c5e00000|  0%| F|  |TAMS 0x00000000c5d00000, 0x00000000c5d00000| Untracked 
|1118|0x00000000c5e00000, 0x00000000c5e00000, 0x00000000c5f00000|  0%| F|  |TAMS 0x00000000c5e00000, 0x00000000c5e00000| Untracked 
|1122|0x00000000c6200000, 0x00000000c6200000, 0x00000000c6300000|  0%| F|  |TAMS 0x00000000c6200000, 0x00000000c6200000| Untracked 
|1123|0x00000000c6300000, 0x00000000c6300000, 0x00000000c6400000|  0%| F|  |TAMS 0x00000000c6300000, 0x00000000c6300000| Untracked 
|1124|0x00000000c6400000, 0x00000000c6400000, 0x00000000c6500000|  0%| F|  |TAMS 0x00000000c6400000, 0x00000000c6400000| Untracked 
|1125|0x00000000c6500000, 0x00000000c6500000, 0x00000000c6600000|  0%| F|  |TAMS 0x00000000c6500000, 0x00000000c6500000| Untracked 
|1126|0x00000000c6600000, 0x00000000c6600000, 0x00000000c6700000|  0%| F|  |TAMS 0x00000000c6600000, 0x00000000c6600000| Untracked 
|1127|0x00000000c6700000, 0x00000000c6700000, 0x00000000c6800000|  0%| F|  |TAMS 0x00000000c6700000, 0x00000000c6700000| Untracked 
|1128|0x00000000c6800000, 0x00000000c6800000, 0x00000000c6900000|  0%| F|  |TAMS 0x00000000c6800000, 0x00000000c6800000| Untracked 
|1129|0x00000000c6900000, 0x00000000c6900000, 0x00000000c6a00000|  0%| F|  |TAMS 0x00000000c6900000, 0x00000000c6900000| Untracked 
|1130|0x00000000c6a00000, 0x00000000c6a00000, 0x00000000c6b00000|  0%| F|  |TAMS 0x00000000c6a00000, 0x00000000c6a00000| Untracked 
|1131|0x00000000c6b00000, 0x00000000c6b00000, 0x00000000c6c00000|  0%| F|  |TAMS 0x00000000c6b00000, 0x00000000c6b00000| Untracked 
|1132|0x00000000c6c00000, 0x00000000c6c00000, 0x00000000c6d00000|  0%| F|  |TAMS 0x00000000c6c00000, 0x00000000c6c00000| Untracked 
|1133|0x00000000c6d00000, 0x00000000c6d00000, 0x00000000c6e00000|  0%| F|  |TAMS 0x00000000c6d00000, 0x00000000c6d00000| Untracked 
|1134|0x00000000c6e00000, 0x00000000c6e00000, 0x00000000c6f00000|  0%| F|  |TAMS 0x00000000c6e00000, 0x00000000c6e00000| Untracked 
|1135|0x00000000c6f00000, 0x00000000c6f00000, 0x00000000c7000000|  0%| F|  |TAMS 0x00000000c6f00000, 0x00000000c6f00000| Untracked 
|1136|0x00000000c7000000, 0x00000000c7000000, 0x00000000c7100000|  0%| F|  |TAMS 0x00000000c7000000, 0x00000000c7000000| Untracked 
|1137|0x00000000c7100000, 0x00000000c7100000, 0x00000000c7200000|  0%| F|  |TAMS 0x00000000c7100000, 0x00000000c7100000| Untracked 
|1138|0x00000000c7200000, 0x00000000c7200000, 0x00000000c7300000|  0%| F|  |TAMS 0x00000000c7200000, 0x00000000c7200000| Untracked 
|1139|0x00000000c7300000, 0x00000000c7300000, 0x00000000c7400000|  0%| F|  |TAMS 0x00000000c7300000, 0x00000000c7300000| Untracked 
|1140|0x00000000c7400000, 0x00000000c7400000, 0x00000000c7500000|  0%| F|  |TAMS 0x00000000c7400000, 0x00000000c7400000| Untracked 
|1141|0x00000000c7500000, 0x00000000c7500000, 0x00000000c7600000|  0%| F|  |TAMS 0x00000000c7500000, 0x00000000c7500000| Untracked 
|1142|0x00000000c7600000, 0x00000000c7600000, 0x00000000c7700000|  0%| F|  |TAMS 0x00000000c7600000, 0x00000000c7600000| Untracked 
|1143|0x00000000c7700000, 0x00000000c7700000, 0x00000000c7800000|  0%| F|  |TAMS 0x00000000c7700000, 0x00000000c7700000| Untracked 
|1144|0x00000000c7800000, 0x00000000c7800000, 0x00000000c7900000|  0%| F|  |TAMS 0x00000000c7800000, 0x00000000c7800000| Untracked 
|1145|0x00000000c7900000, 0x00000000c7900000, 0x00000000c7a00000|  0%| F|  |TAMS 0x00000000c7900000, 0x00000000c7900000| Untracked 
|1146|0x00000000c7a00000, 0x00000000c7a00000, 0x00000000c7b00000|  0%| F|  |TAMS 0x00000000c7a00000, 0x00000000c7a00000| Untracked 
|1147|0x00000000c7b00000, 0x00000000c7b00000, 0x00000000c7c00000|  0%| F|  |TAMS 0x00000000c7b00000, 0x00000000c7b00000| Untracked 
|1148|0x00000000c7c00000, 0x00000000c7c00000, 0x00000000c7d00000|  0%| F|  |TAMS 0x00000000c7c00000, 0x00000000c7c00000| Untracked 
|1149|0x00000000c7d00000, 0x00000000c7d00000, 0x00000000c7e00000|  0%| F|  |TAMS 0x00000000c7d00000, 0x00000000c7d00000| Untracked 
|1150|0x00000000c7e00000, 0x00000000c7e00000, 0x00000000c7f00000|  0%| F|  |TAMS 0x00000000c7e00000, 0x00000000c7e00000| Untracked 
|1151|0x00000000c7f00000, 0x00000000c7f00000, 0x00000000c8000000|  0%| F|  |TAMS 0x00000000c7f00000, 0x00000000c7f00000| Untracked 
|1152|0x00000000c8000000, 0x00000000c8000000, 0x00000000c8100000|  0%| F|  |TAMS 0x00000000c8000000, 0x00000000c8000000| Untracked 
|1153|0x00000000c8100000, 0x00000000c8100000, 0x00000000c8200000|  0%| F|  |TAMS 0x00000000c8100000, 0x00000000c8100000| Untracked 
|1154|0x00000000c8200000, 0x00000000c8200000, 0x00000000c8300000|  0%| F|  |TAMS 0x00000000c8200000, 0x00000000c8200000| Untracked 
|1155|0x00000000c8300000, 0x00000000c8300000, 0x00000000c8400000|  0%| F|  |TAMS 0x00000000c8300000, 0x00000000c8300000| Untracked 
|1156|0x00000000c8400000, 0x00000000c8400000, 0x00000000c8500000|  0%| F|  |TAMS 0x00000000c8400000, 0x00000000c8400000| Untracked 
|1157|0x00000000c8500000, 0x00000000c8500000, 0x00000000c8600000|  0%| F|  |TAMS 0x00000000c8500000, 0x00000000c8500000| Untracked 
|1158|0x00000000c8600000, 0x00000000c8600000, 0x00000000c8700000|  0%| F|  |TAMS 0x00000000c8600000, 0x00000000c8600000| Untracked 
|1159|0x00000000c8700000, 0x00000000c8700000, 0x00000000c8800000|  0%| F|  |TAMS 0x00000000c8700000, 0x00000000c8700000| Untracked 
|1160|0x00000000c8800000, 0x00000000c8800000, 0x00000000c8900000|  0%| F|  |TAMS 0x00000000c8800000, 0x00000000c8800000| Untracked 
|1161|0x00000000c8900000, 0x00000000c8900000, 0x00000000c8a00000|  0%| F|  |TAMS 0x00000000c8900000, 0x00000000c8900000| Untracked 
|1162|0x00000000c8a00000, 0x00000000c8a00000, 0x00000000c8b00000|  0%| F|  |TAMS 0x00000000c8a00000, 0x00000000c8a00000| Untracked 
|1163|0x00000000c8b00000, 0x00000000c8b00000, 0x00000000c8c00000|  0%| F|  |TAMS 0x00000000c8b00000, 0x00000000c8b00000| Untracked 
|1164|0x00000000c8c00000, 0x00000000c8c00000, 0x00000000c8d00000|  0%| F|  |TAMS 0x00000000c8c00000, 0x00000000c8c00000| Untracked 
|1165|0x00000000c8d00000, 0x00000000c8d00000, 0x00000000c8e00000|  0%| F|  |TAMS 0x00000000c8d00000, 0x00000000c8d00000| Untracked 
|1166|0x00000000c8e00000, 0x00000000c8e00000, 0x00000000c8f00000|  0%| F|  |TAMS 0x00000000c8e00000, 0x00000000c8e00000| Untracked 
|1167|0x00000000c8f00000, 0x00000000c8f00000, 0x00000000c9000000|  0%| F|  |TAMS 0x00000000c8f00000, 0x00000000c8f00000| Untracked 
|1168|0x00000000c9000000, 0x00000000c9000000, 0x00000000c9100000|  0%| F|  |TAMS 0x00000000c9000000, 0x00000000c9000000| Untracked 
|1169|0x00000000c9100000, 0x00000000c9100000, 0x00000000c9200000|  0%| F|  |TAMS 0x00000000c9100000, 0x00000000c9100000| Untracked 
|1170|0x00000000c9200000, 0x00000000c9200000, 0x00000000c9300000|  0%| F|  |TAMS 0x00000000c9200000, 0x00000000c9200000| Untracked 
|1171|0x00000000c9300000, 0x00000000c9300000, 0x00000000c9400000|  0%| F|  |TAMS 0x00000000c9300000, 0x00000000c9300000| Untracked 
|1172|0x00000000c9400000, 0x00000000c9400000, 0x00000000c9500000|  0%| F|  |TAMS 0x00000000c9400000, 0x00000000c9400000| Untracked 
|1173|0x00000000c9500000, 0x00000000c9500000, 0x00000000c9600000|  0%| F|  |TAMS 0x00000000c9500000, 0x00000000c9500000| Untracked 
|1174|0x00000000c9600000, 0x00000000c9600000, 0x00000000c9700000|  0%| F|  |TAMS 0x00000000c9600000, 0x00000000c9600000| Untracked 
|1175|0x00000000c9700000, 0x00000000c9700000, 0x00000000c9800000|  0%| F|  |TAMS 0x00000000c9700000, 0x00000000c9700000| Untracked 
|1176|0x00000000c9800000, 0x00000000c9800000, 0x00000000c9900000|  0%| F|  |TAMS 0x00000000c9800000, 0x00000000c9800000| Untracked 
|1177|0x00000000c9900000, 0x00000000c9900000, 0x00000000c9a00000|  0%| F|  |TAMS 0x00000000c9900000, 0x00000000c9900000| Untracked 
|1178|0x00000000c9a00000, 0x00000000c9a00000, 0x00000000c9b00000|  0%| F|  |TAMS 0x00000000c9a00000, 0x00000000c9a00000| Untracked 
|1179|0x00000000c9b00000, 0x00000000c9b00000, 0x00000000c9c00000|  0%| F|  |TAMS 0x00000000c9b00000, 0x00000000c9b00000| Untracked 
|1180|0x00000000c9c00000, 0x00000000c9c00000, 0x00000000c9d00000|  0%| F|  |TAMS 0x00000000c9c00000, 0x00000000c9c00000| Untracked 
|1181|0x00000000c9d00000, 0x00000000c9d00000, 0x00000000c9e00000|  0%| F|  |TAMS 0x00000000c9d00000, 0x00000000c9d00000| Untracked 
|1182|0x00000000c9e00000, 0x00000000c9e00000, 0x00000000c9f00000|  0%| F|  |TAMS 0x00000000c9e00000, 0x00000000c9e00000| Untracked 
|1183|0x00000000c9f00000, 0x00000000c9f00000, 0x00000000ca000000|  0%| F|  |TAMS 0x00000000c9f00000, 0x00000000c9f00000| Untracked 
|1184|0x00000000ca000000, 0x00000000ca000000, 0x00000000ca100000|  0%| F|  |TAMS 0x00000000ca000000, 0x00000000ca000000| Untracked 
|1185|0x00000000ca100000, 0x00000000ca100000, 0x00000000ca200000|  0%| F|  |TAMS 0x00000000ca100000, 0x00000000ca100000| Untracked 
|1186|0x00000000ca200000, 0x00000000ca200000, 0x00000000ca300000|  0%| F|  |TAMS 0x00000000ca200000, 0x00000000ca200000| Untracked 
|1187|0x00000000ca300000, 0x00000000ca300000, 0x00000000ca400000|  0%| F|  |TAMS 0x00000000ca300000, 0x00000000ca300000| Untracked 
|1188|0x00000000ca400000, 0x00000000ca400000, 0x00000000ca500000|  0%| F|  |TAMS 0x00000000ca400000, 0x00000000ca400000| Untracked 
|1189|0x00000000ca500000, 0x00000000ca500000, 0x00000000ca600000|  0%| F|  |TAMS 0x00000000ca500000, 0x00000000ca500000| Untracked 
|1190|0x00000000ca600000, 0x00000000ca600000, 0x00000000ca700000|  0%| F|  |TAMS 0x00000000ca600000, 0x00000000ca600000| Untracked 
|1191|0x00000000ca700000, 0x00000000ca700000, 0x00000000ca800000|  0%| F|  |TAMS 0x00000000ca700000, 0x00000000ca700000| Untracked 
|1192|0x00000000ca800000, 0x00000000ca800000, 0x00000000ca900000|  0%| F|  |TAMS 0x00000000ca800000, 0x00000000ca800000| Untracked 
|1193|0x00000000ca900000, 0x00000000ca900000, 0x00000000caa00000|  0%| F|  |TAMS 0x00000000ca900000, 0x00000000ca900000| Untracked 
|1194|0x00000000caa00000, 0x00000000caa00000, 0x00000000cab00000|  0%| F|  |TAMS 0x00000000caa00000, 0x00000000caa00000| Untracked 
|1195|0x00000000cab00000, 0x00000000cab00000, 0x00000000cac00000|  0%| F|  |TAMS 0x00000000cab00000, 0x00000000cab00000| Untracked 
|1196|0x00000000cac00000, 0x00000000cac00000, 0x00000000cad00000|  0%| F|  |TAMS 0x00000000cac00000, 0x00000000cac00000| Untracked 
|1197|0x00000000cad00000, 0x00000000cad00000, 0x00000000cae00000|  0%| F|  |TAMS 0x00000000cad00000, 0x00000000cad00000| Untracked 
|1198|0x00000000cae00000, 0x00000000cae00000, 0x00000000caf00000|  0%| F|  |TAMS 0x00000000cae00000, 0x00000000cae00000| Untracked 
|1199|0x00000000caf00000, 0x00000000caf00000, 0x00000000cb000000|  0%| F|  |TAMS 0x00000000caf00000, 0x00000000caf00000| Untracked 
|1200|0x00000000cb000000, 0x00000000cb000000, 0x00000000cb100000|  0%| F|  |TAMS 0x00000000cb000000, 0x00000000cb000000| Untracked 
|1201|0x00000000cb100000, 0x00000000cb100000, 0x00000000cb200000|  0%| F|  |TAMS 0x00000000cb100000, 0x00000000cb100000| Untracked 
|1202|0x00000000cb200000, 0x00000000cb200000, 0x00000000cb300000|  0%| F|  |TAMS 0x00000000cb200000, 0x00000000cb200000| Untracked 
|1203|0x00000000cb300000, 0x00000000cb300000, 0x00000000cb400000|  0%| F|  |TAMS 0x00000000cb300000, 0x00000000cb300000| Untracked 
|1204|0x00000000cb400000, 0x00000000cb400000, 0x00000000cb500000|  0%| F|  |TAMS 0x00000000cb400000, 0x00000000cb400000| Untracked 
|1205|0x00000000cb500000, 0x00000000cb500000, 0x00000000cb600000|  0%| F|  |TAMS 0x00000000cb500000, 0x00000000cb500000| Untracked 
|1206|0x00000000cb600000, 0x00000000cb600000, 0x00000000cb700000|  0%| F|  |TAMS 0x00000000cb600000, 0x00000000cb600000| Untracked 
|1207|0x00000000cb700000, 0x00000000cb700000, 0x00000000cb800000|  0%| F|  |TAMS 0x00000000cb700000, 0x00000000cb700000| Untracked 
|1208|0x00000000cb800000, 0x00000000cb800000, 0x00000000cb900000|  0%| F|  |TAMS 0x00000000cb800000, 0x00000000cb800000| Untracked 
|1209|0x00000000cb900000, 0x00000000cb900000, 0x00000000cba00000|  0%| F|  |TAMS 0x00000000cb900000, 0x00000000cb900000| Untracked 
|1210|0x00000000cba00000, 0x00000000cba00000, 0x00000000cbb00000|  0%| F|  |TAMS 0x00000000cba00000, 0x00000000cba00000| Untracked 
|1211|0x00000000cbb00000, 0x00000000cbb00000, 0x00000000cbc00000|  0%| F|  |TAMS 0x00000000cbb00000, 0x00000000cbb00000| Untracked 
|1212|0x00000000cbc00000, 0x00000000cbc00000, 0x00000000cbd00000|  0%| F|  |TAMS 0x00000000cbc00000, 0x00000000cbc00000| Untracked 
|1213|0x00000000cbd00000, 0x00000000cbd00000, 0x00000000cbe00000|  0%| F|  |TAMS 0x00000000cbd00000, 0x00000000cbd00000| Untracked 
|1214|0x00000000cbe00000, 0x00000000cbe00000, 0x00000000cbf00000|  0%| F|  |TAMS 0x00000000cbe00000, 0x00000000cbe00000| Untracked 
|1215|0x00000000cbf00000, 0x00000000cbf00000, 0x00000000cc000000|  0%| F|  |TAMS 0x00000000cbf00000, 0x00000000cbf00000| Untracked 
|1216|0x00000000cc000000, 0x00000000cc000000, 0x00000000cc100000|  0%| F|  |TAMS 0x00000000cc000000, 0x00000000cc000000| Untracked 
|1217|0x00000000cc100000, 0x00000000cc100000, 0x00000000cc200000|  0%| F|  |TAMS 0x00000000cc100000, 0x00000000cc100000| Untracked 
|1218|0x00000000cc200000, 0x00000000cc200000, 0x00000000cc300000|  0%| F|  |TAMS 0x00000000cc200000, 0x00000000cc200000| Untracked 
|1219|0x00000000cc300000, 0x00000000cc300000, 0x00000000cc400000|  0%| F|  |TAMS 0x00000000cc300000, 0x00000000cc300000| Untracked 
|1220|0x00000000cc400000, 0x00000000cc400000, 0x00000000cc500000|  0%| F|  |TAMS 0x00000000cc400000, 0x00000000cc400000| Untracked 
|1221|0x00000000cc500000, 0x00000000cc500000, 0x00000000cc600000|  0%| F|  |TAMS 0x00000000cc500000, 0x00000000cc500000| Untracked 
|1222|0x00000000cc600000, 0x00000000cc600000, 0x00000000cc700000|  0%| F|  |TAMS 0x00000000cc600000, 0x00000000cc600000| Untracked 
|1223|0x00000000cc700000, 0x00000000cc700000, 0x00000000cc800000|  0%| F|  |TAMS 0x00000000cc700000, 0x00000000cc700000| Untracked 
|1224|0x00000000cc800000, 0x00000000cc800000, 0x00000000cc900000|  0%| F|  |TAMS 0x00000000cc800000, 0x00000000cc800000| Untracked 
|1225|0x00000000cc900000, 0x00000000cc900000, 0x00000000cca00000|  0%| F|  |TAMS 0x00000000cc900000, 0x00000000cc900000| Untracked 
|1226|0x00000000cca00000, 0x00000000cca00000, 0x00000000ccb00000|  0%| F|  |TAMS 0x00000000cca00000, 0x00000000cca00000| Untracked 
|1227|0x00000000ccb00000, 0x00000000ccb00000, 0x00000000ccc00000|  0%| F|  |TAMS 0x00000000ccb00000, 0x00000000ccb00000| Untracked 
|1228|0x00000000ccc00000, 0x00000000ccc00000, 0x00000000ccd00000|  0%| F|  |TAMS 0x00000000ccc00000, 0x00000000ccc00000| Untracked 
|1229|0x00000000ccd00000, 0x00000000ccd00000, 0x00000000cce00000|  0%| F|  |TAMS 0x00000000ccd00000, 0x00000000ccd00000| Untracked 
|1230|0x00000000cce00000, 0x00000000cce00000, 0x00000000ccf00000|  0%| F|  |TAMS 0x00000000cce00000, 0x00000000cce00000| Untracked 
|1231|0x00000000ccf00000, 0x00000000ccf00000, 0x00000000cd000000|  0%| F|  |TAMS 0x00000000ccf00000, 0x00000000ccf00000| Untracked 
|1232|0x00000000cd000000, 0x00000000cd000000, 0x00000000cd100000|  0%| F|  |TAMS 0x00000000cd000000, 0x00000000cd000000| Untracked 
|1233|0x00000000cd100000, 0x00000000cd100000, 0x00000000cd200000|  0%| F|  |TAMS 0x00000000cd100000, 0x00000000cd100000| Untracked 
|1234|0x00000000cd200000, 0x00000000cd200000, 0x00000000cd300000|  0%| F|  |TAMS 0x00000000cd200000, 0x00000000cd200000| Untracked 
|1235|0x00000000cd300000, 0x00000000cd300000, 0x00000000cd400000|  0%| F|  |TAMS 0x00000000cd300000, 0x00000000cd300000| Untracked 
|1236|0x00000000cd400000, 0x00000000cd400000, 0x00000000cd500000|  0%| F|  |TAMS 0x00000000cd400000, 0x00000000cd400000| Untracked 
|1237|0x00000000cd500000, 0x00000000cd500000, 0x00000000cd600000|  0%| F|  |TAMS 0x00000000cd500000, 0x00000000cd500000| Untracked 
|1238|0x00000000cd600000, 0x00000000cd600000, 0x00000000cd700000|  0%| F|  |TAMS 0x00000000cd600000, 0x00000000cd600000| Untracked 
|1239|0x00000000cd700000, 0x00000000cd700000, 0x00000000cd800000|  0%| F|  |TAMS 0x00000000cd700000, 0x00000000cd700000| Untracked 
|1240|0x00000000cd800000, 0x00000000cd800000, 0x00000000cd900000|  0%| F|  |TAMS 0x00000000cd800000, 0x00000000cd800000| Untracked 
|1241|0x00000000cd900000, 0x00000000cd900000, 0x00000000cda00000|  0%| F|  |TAMS 0x00000000cd900000, 0x00000000cd900000| Untracked 
|1242|0x00000000cda00000, 0x00000000cda00000, 0x00000000cdb00000|  0%| F|  |TAMS 0x00000000cda00000, 0x00000000cda00000| Untracked 
|1243|0x00000000cdb00000, 0x00000000cdb00000, 0x00000000cdc00000|  0%| F|  |TAMS 0x00000000cdb00000, 0x00000000cdb00000| Untracked 
|1244|0x00000000cdc00000, 0x00000000cdc00000, 0x00000000cdd00000|  0%| F|  |TAMS 0x00000000cdc00000, 0x00000000cdc00000| Untracked 
|1245|0x00000000cdd00000, 0x00000000cdd00000, 0x00000000cde00000|  0%| F|  |TAMS 0x00000000cdd00000, 0x00000000cdd00000| Untracked 
|1246|0x00000000cde00000, 0x00000000cde00000, 0x00000000cdf00000|  0%| F|  |TAMS 0x00000000cde00000, 0x00000000cde00000| Untracked 
|1247|0x00000000cdf00000, 0x00000000cdf00000, 0x00000000ce000000|  0%| F|  |TAMS 0x00000000cdf00000, 0x00000000cdf00000| Untracked 
|1248|0x00000000ce000000, 0x00000000ce000000, 0x00000000ce100000|  0%| F|  |TAMS 0x00000000ce000000, 0x00000000ce000000| Untracked 
|1249|0x00000000ce100000, 0x00000000ce100000, 0x00000000ce200000|  0%| F|  |TAMS 0x00000000ce100000, 0x00000000ce100000| Untracked 
|1250|0x00000000ce200000, 0x00000000ce200000, 0x00000000ce300000|  0%| F|  |TAMS 0x00000000ce200000, 0x00000000ce200000| Untracked 
|1251|0x00000000ce300000, 0x00000000ce300000, 0x00000000ce400000|  0%| F|  |TAMS 0x00000000ce300000, 0x00000000ce300000| Untracked 
|1252|0x00000000ce400000, 0x00000000ce400000, 0x00000000ce500000|  0%| F|  |TAMS 0x00000000ce400000, 0x00000000ce400000| Untracked 
|1253|0x00000000ce500000, 0x00000000ce500000, 0x00000000ce600000|  0%| F|  |TAMS 0x00000000ce500000, 0x00000000ce500000| Untracked 
|1254|0x00000000ce600000, 0x00000000ce600000, 0x00000000ce700000|  0%| F|  |TAMS 0x00000000ce600000, 0x00000000ce600000| Untracked 
|1255|0x00000000ce700000, 0x00000000ce700000, 0x00000000ce800000|  0%| F|  |TAMS 0x00000000ce700000, 0x00000000ce700000| Untracked 
|1256|0x00000000ce800000, 0x00000000ce800000, 0x00000000ce900000|  0%| F|  |TAMS 0x00000000ce800000, 0x00000000ce800000| Untracked 
|1257|0x00000000ce900000, 0x00000000ce900000, 0x00000000cea00000|  0%| F|  |TAMS 0x00000000ce900000, 0x00000000ce900000| Untracked 
|1258|0x00000000cea00000, 0x00000000cea00000, 0x00000000ceb00000|  0%| F|  |TAMS 0x00000000cea00000, 0x00000000cea00000| Untracked 
|1259|0x00000000ceb00000, 0x00000000ceb00000, 0x00000000cec00000|  0%| F|  |TAMS 0x00000000ceb00000, 0x00000000ceb00000| Untracked 
|1260|0x00000000cec00000, 0x00000000cec00000, 0x00000000ced00000|  0%| F|  |TAMS 0x00000000cec00000, 0x00000000cec00000| Untracked 
|1261|0x00000000ced00000, 0x00000000ced00000, 0x00000000cee00000|  0%| F|  |TAMS 0x00000000ced00000, 0x00000000ced00000| Untracked 
|1262|0x00000000cee00000, 0x00000000cee00000, 0x00000000cef00000|  0%| F|  |TAMS 0x00000000cee00000, 0x00000000cee00000| Untracked 
|1263|0x00000000cef00000, 0x00000000cef00000, 0x00000000cf000000|  0%| F|  |TAMS 0x00000000cef00000, 0x00000000cef00000| Untracked 
|1264|0x00000000cf000000, 0x00000000cf000000, 0x00000000cf100000|  0%| F|  |TAMS 0x00000000cf000000, 0x00000000cf000000| Untracked 
|1265|0x00000000cf100000, 0x00000000cf100000, 0x00000000cf200000|  0%| F|  |TAMS 0x00000000cf100000, 0x00000000cf100000| Untracked 
|1266|0x00000000cf200000, 0x00000000cf200000, 0x00000000cf300000|  0%| F|  |TAMS 0x00000000cf200000, 0x00000000cf200000| Untracked 
|1267|0x00000000cf300000, 0x00000000cf300000, 0x00000000cf400000|  0%| F|  |TAMS 0x00000000cf300000, 0x00000000cf300000| Untracked 
|1268|0x00000000cf400000, 0x00000000cf400000, 0x00000000cf500000|  0%| F|  |TAMS 0x00000000cf400000, 0x00000000cf400000| Untracked 
|1269|0x00000000cf500000, 0x00000000cf500000, 0x00000000cf600000|  0%| F|  |TAMS 0x00000000cf500000, 0x00000000cf500000| Untracked 
|1270|0x00000000cf600000, 0x00000000cf600000, 0x00000000cf700000|  0%| F|  |TAMS 0x00000000cf600000, 0x00000000cf600000| Untracked 
|1271|0x00000000cf700000, 0x00000000cf700000, 0x00000000cf800000|  0%| F|  |TAMS 0x00000000cf700000, 0x00000000cf700000| Untracked 
|1272|0x00000000cf800000, 0x00000000cf800000, 0x00000000cf900000|  0%| F|  |TAMS 0x00000000cf800000, 0x00000000cf800000| Untracked 
|1273|0x00000000cf900000, 0x00000000cf900000, 0x00000000cfa00000|  0%| F|  |TAMS 0x00000000cf900000, 0x00000000cf900000| Untracked 
|1274|0x00000000cfa00000, 0x00000000cfa00000, 0x00000000cfb00000|  0%| F|  |TAMS 0x00000000cfa00000, 0x00000000cfa00000| Untracked 
|1275|0x00000000cfb00000, 0x00000000cfb00000, 0x00000000cfc00000|  0%| F|  |TAMS 0x00000000cfb00000, 0x00000000cfb00000| Untracked 
|1276|0x00000000cfc00000, 0x00000000cfc00000, 0x00000000cfd00000|  0%| F|  |TAMS 0x00000000cfc00000, 0x00000000cfc00000| Untracked 
|1277|0x00000000cfd00000, 0x00000000cfd00000, 0x00000000cfe00000|  0%| F|  |TAMS 0x00000000cfd00000, 0x00000000cfd00000| Untracked 
|1278|0x00000000cfe00000, 0x00000000cfe00000, 0x00000000cff00000|  0%| F|  |TAMS 0x00000000cfe00000, 0x00000000cfe00000| Untracked 
|1279|0x00000000cff00000, 0x00000000cff00000, 0x00000000d0000000|  0%| F|  |TAMS 0x00000000cff00000, 0x00000000cff00000| Untracked 
|1280|0x00000000d0000000, 0x00000000d0000000, 0x00000000d0100000|  0%| F|  |TAMS 0x00000000d0000000, 0x00000000d0000000| Untracked 
|1281|0x00000000d0100000, 0x00000000d0100000, 0x00000000d0200000|  0%| F|  |TAMS 0x00000000d0100000, 0x00000000d0100000| Untracked 
|1282|0x00000000d0200000, 0x00000000d0200000, 0x00000000d0300000|  0%| F|  |TAMS 0x00000000d0200000, 0x00000000d0200000| Untracked 
|1283|0x00000000d0300000, 0x00000000d0300000, 0x00000000d0400000|  0%| F|  |TAMS 0x00000000d0300000, 0x00000000d0300000| Untracked 
|1284|0x00000000d0400000, 0x00000000d0400000, 0x00000000d0500000|  0%| F|  |TAMS 0x00000000d0400000, 0x00000000d0400000| Untracked 
|1285|0x00000000d0500000, 0x00000000d0500000, 0x00000000d0600000|  0%| F|  |TAMS 0x00000000d0500000, 0x00000000d0500000| Untracked 
|1286|0x00000000d0600000, 0x00000000d0600000, 0x00000000d0700000|  0%| F|  |TAMS 0x00000000d0600000, 0x00000000d0600000| Untracked 
|1287|0x00000000d0700000, 0x00000000d0700000, 0x00000000d0800000|  0%| F|  |TAMS 0x00000000d0700000, 0x00000000d0700000| Untracked 
|1288|0x00000000d0800000, 0x00000000d0800000, 0x00000000d0900000|  0%| F|  |TAMS 0x00000000d0800000, 0x00000000d0800000| Untracked 
|1289|0x00000000d0900000, 0x00000000d0900000, 0x00000000d0a00000|  0%| F|  |TAMS 0x00000000d0900000, 0x00000000d0900000| Untracked 
|1290|0x00000000d0a00000, 0x00000000d0a00000, 0x00000000d0b00000|  0%| F|  |TAMS 0x00000000d0a00000, 0x00000000d0a00000| Untracked 
|1291|0x00000000d0b00000, 0x00000000d0b00000, 0x00000000d0c00000|  0%| F|  |TAMS 0x00000000d0b00000, 0x00000000d0b00000| Untracked 
|1292|0x00000000d0c00000, 0x00000000d0c00000, 0x00000000d0d00000|  0%| F|  |TAMS 0x00000000d0c00000, 0x00000000d0c00000| Untracked 
|1293|0x00000000d0d00000, 0x00000000d0d00000, 0x00000000d0e00000|  0%| F|  |TAMS 0x00000000d0d00000, 0x00000000d0d00000| Untracked 
|1294|0x00000000d0e00000, 0x00000000d0e00000, 0x00000000d0f00000|  0%| F|  |TAMS 0x00000000d0e00000, 0x00000000d0e00000| Untracked 
|1295|0x00000000d0f00000, 0x00000000d0f00000, 0x00000000d1000000|  0%| F|  |TAMS 0x00000000d0f00000, 0x00000000d0f00000| Untracked 
|1296|0x00000000d1000000, 0x00000000d1000000, 0x00000000d1100000|  0%| F|  |TAMS 0x00000000d1000000, 0x00000000d1000000| Untracked 
|1297|0x00000000d1100000, 0x00000000d1100000, 0x00000000d1200000|  0%| F|  |TAMS 0x00000000d1100000, 0x00000000d1100000| Untracked 
|1298|0x00000000d1200000, 0x00000000d1200000, 0x00000000d1300000|  0%| F|  |TAMS 0x00000000d1200000, 0x00000000d1200000| Untracked 
|1299|0x00000000d1300000, 0x00000000d1300000, 0x00000000d1400000|  0%| F|  |TAMS 0x00000000d1300000, 0x00000000d1300000| Untracked 
|1300|0x00000000d1400000, 0x00000000d1400000, 0x00000000d1500000|  0%| F|  |TAMS 0x00000000d1400000, 0x00000000d1400000| Untracked 
|1301|0x00000000d1500000, 0x00000000d1500000, 0x00000000d1600000|  0%| F|  |TAMS 0x00000000d1500000, 0x00000000d1500000| Untracked 
|1302|0x00000000d1600000, 0x00000000d1600000, 0x00000000d1700000|  0%| F|  |TAMS 0x00000000d1600000, 0x00000000d1600000| Untracked 
|1303|0x00000000d1700000, 0x00000000d1700000, 0x00000000d1800000|  0%| F|  |TAMS 0x00000000d1700000, 0x00000000d1700000| Untracked 
|1304|0x00000000d1800000, 0x00000000d1800000, 0x00000000d1900000|  0%| F|  |TAMS 0x00000000d1800000, 0x00000000d1800000| Untracked 
|1305|0x00000000d1900000, 0x00000000d1900000, 0x00000000d1a00000|  0%| F|  |TAMS 0x00000000d1900000, 0x00000000d1900000| Untracked 
|1306|0x00000000d1a00000, 0x00000000d1a00000, 0x00000000d1b00000|  0%| F|  |TAMS 0x00000000d1a00000, 0x00000000d1a00000| Untracked 
|1307|0x00000000d1b00000, 0x00000000d1b00000, 0x00000000d1c00000|  0%| F|  |TAMS 0x00000000d1b00000, 0x00000000d1b00000| Untracked 
|1308|0x00000000d1c00000, 0x00000000d1c00000, 0x00000000d1d00000|  0%| F|  |TAMS 0x00000000d1c00000, 0x00000000d1c00000| Untracked 
|1309|0x00000000d1d00000, 0x00000000d1d00000, 0x00000000d1e00000|  0%| F|  |TAMS 0x00000000d1d00000, 0x00000000d1d00000| Untracked 
|1310|0x00000000d1e00000, 0x00000000d1e00000, 0x00000000d1f00000|  0%| F|  |TAMS 0x00000000d1e00000, 0x00000000d1e00000| Untracked 
|1311|0x00000000d1f00000, 0x00000000d1f00000, 0x00000000d2000000|  0%| F|  |TAMS 0x00000000d1f00000, 0x00000000d1f00000| Untracked 
|1312|0x00000000d2000000, 0x00000000d2000000, 0x00000000d2100000|  0%| F|  |TAMS 0x00000000d2000000, 0x00000000d2000000| Untracked 
|1313|0x00000000d2100000, 0x00000000d2100000, 0x00000000d2200000|  0%| F|  |TAMS 0x00000000d2100000, 0x00000000d2100000| Untracked 
|1314|0x00000000d2200000, 0x00000000d2200000, 0x00000000d2300000|  0%| F|  |TAMS 0x00000000d2200000, 0x00000000d2200000| Untracked 
|1315|0x00000000d2300000, 0x00000000d2300000, 0x00000000d2400000|  0%| F|  |TAMS 0x00000000d2300000, 0x00000000d2300000| Untracked 
|1316|0x00000000d2400000, 0x00000000d2400000, 0x00000000d2500000|  0%| F|  |TAMS 0x00000000d2400000, 0x00000000d2400000| Untracked 
|1317|0x00000000d2500000, 0x00000000d2500000, 0x00000000d2600000|  0%| F|  |TAMS 0x00000000d2500000, 0x00000000d2500000| Untracked 
|1318|0x00000000d2600000, 0x00000000d2600000, 0x00000000d2700000|  0%| F|  |TAMS 0x00000000d2600000, 0x00000000d2600000| Untracked 
|1319|0x00000000d2700000, 0x00000000d2700000, 0x00000000d2800000|  0%| F|  |TAMS 0x00000000d2700000, 0x00000000d2700000| Untracked 
|1320|0x00000000d2800000, 0x00000000d2800000, 0x00000000d2900000|  0%| F|  |TAMS 0x00000000d2800000, 0x00000000d2800000| Untracked 
|1321|0x00000000d2900000, 0x00000000d2900000, 0x00000000d2a00000|  0%| F|  |TAMS 0x00000000d2900000, 0x00000000d2900000| Untracked 
|1322|0x00000000d2a00000, 0x00000000d2a00000, 0x00000000d2b00000|  0%| F|  |TAMS 0x00000000d2a00000, 0x00000000d2a00000| Untracked 
|1323|0x00000000d2b00000, 0x00000000d2b00000, 0x00000000d2c00000|  0%| F|  |TAMS 0x00000000d2b00000, 0x00000000d2b00000| Untracked 
|1324|0x00000000d2c00000, 0x00000000d2c00000, 0x00000000d2d00000|  0%| F|  |TAMS 0x00000000d2c00000, 0x00000000d2c00000| Untracked 
|1325|0x00000000d2d00000, 0x00000000d2d00000, 0x00000000d2e00000|  0%| F|  |TAMS 0x00000000d2d00000, 0x00000000d2d00000| Untracked 
|1326|0x00000000d2e00000, 0x00000000d2e00000, 0x00000000d2f00000|  0%| F|  |TAMS 0x00000000d2e00000, 0x00000000d2e00000| Untracked 
|1327|0x00000000d2f00000, 0x00000000d2f00000, 0x00000000d3000000|  0%| F|  |TAMS 0x00000000d2f00000, 0x00000000d2f00000| Untracked 
|1328|0x00000000d3000000, 0x00000000d3000000, 0x00000000d3100000|  0%| F|  |TAMS 0x00000000d3000000, 0x00000000d3000000| Untracked 
|1329|0x00000000d3100000, 0x00000000d3100000, 0x00000000d3200000|  0%| F|  |TAMS 0x00000000d3100000, 0x00000000d3100000| Untracked 
|1330|0x00000000d3200000, 0x00000000d3200000, 0x00000000d3300000|  0%| F|  |TAMS 0x00000000d3200000, 0x00000000d3200000| Untracked 
|1331|0x00000000d3300000, 0x00000000d3300000, 0x00000000d3400000|  0%| F|  |TAMS 0x00000000d3300000, 0x00000000d3300000| Untracked 
|1332|0x00000000d3400000, 0x00000000d3400000, 0x00000000d3500000|  0%| F|  |TAMS 0x00000000d3400000, 0x00000000d3400000| Untracked 
|1333|0x00000000d3500000, 0x00000000d3500000, 0x00000000d3600000|  0%| F|  |TAMS 0x00000000d3500000, 0x00000000d3500000| Untracked 
|1334|0x00000000d3600000, 0x00000000d3600000, 0x00000000d3700000|  0%| F|  |TAMS 0x00000000d3600000, 0x00000000d3600000| Untracked 
|1335|0x00000000d3700000, 0x00000000d3700000, 0x00000000d3800000|  0%| F|  |TAMS 0x00000000d3700000, 0x00000000d3700000| Untracked 
|1336|0x00000000d3800000, 0x00000000d3800000, 0x00000000d3900000|  0%| F|  |TAMS 0x00000000d3800000, 0x00000000d3800000| Untracked 
|1337|0x00000000d3900000, 0x00000000d3900000, 0x00000000d3a00000|  0%| F|  |TAMS 0x00000000d3900000, 0x00000000d3900000| Untracked 
|1338|0x00000000d3a00000, 0x00000000d3a00000, 0x00000000d3b00000|  0%| F|  |TAMS 0x00000000d3a00000, 0x00000000d3a00000| Untracked 
|1339|0x00000000d3b00000, 0x00000000d3b00000, 0x00000000d3c00000|  0%| F|  |TAMS 0x00000000d3b00000, 0x00000000d3b00000| Untracked 
|1340|0x00000000d3c00000, 0x00000000d3c00000, 0x00000000d3d00000|  0%| F|  |TAMS 0x00000000d3c00000, 0x00000000d3c00000| Untracked 
|1341|0x00000000d3d00000, 0x00000000d3d00000, 0x00000000d3e00000|  0%| F|  |TAMS 0x00000000d3d00000, 0x00000000d3d00000| Untracked 
|1342|0x00000000d3e00000, 0x00000000d3e00000, 0x00000000d3f00000|  0%| F|  |TAMS 0x00000000d3e00000, 0x00000000d3e00000| Untracked 
|1343|0x00000000d3f00000, 0x00000000d3f00000, 0x00000000d4000000|  0%| F|  |TAMS 0x00000000d3f00000, 0x00000000d3f00000| Untracked 
|1344|0x00000000d4000000, 0x00000000d4000000, 0x00000000d4100000|  0%| F|  |TAMS 0x00000000d4000000, 0x00000000d4000000| Untracked 
|1345|0x00000000d4100000, 0x00000000d4100000, 0x00000000d4200000|  0%| F|  |TAMS 0x00000000d4100000, 0x00000000d4100000| Untracked 
|1346|0x00000000d4200000, 0x00000000d42d4bc8, 0x00000000d4300000| 83%| S|CS|TAMS 0x00000000d4200000, 0x00000000d4200000| Complete 
|1347|0x00000000d4300000, 0x00000000d4400000, 0x00000000d4400000|100%| S|CS|TAMS 0x00000000d4300000, 0x00000000d4300000| Complete 
|1348|0x00000000d4400000, 0x00000000d4400000, 0x00000000d4500000|  0%| F|  |TAMS 0x00000000d4400000, 0x00000000d4400000| Untracked 
|1349|0x00000000d4500000, 0x00000000d4500000, 0x00000000d4600000|  0%| F|  |TAMS 0x00000000d4500000, 0x00000000d4500000| Untracked 
|1350|0x00000000d4600000, 0x00000000d4600000, 0x00000000d4700000|  0%| F|  |TAMS 0x00000000d4600000, 0x00000000d4600000| Untracked 
|1351|0x00000000d4700000, 0x00000000d4700000, 0x00000000d4800000|  0%| F|  |TAMS 0x00000000d4700000, 0x00000000d4700000| Untracked 
|1352|0x00000000d4800000, 0x00000000d4800000, 0x00000000d4900000|  0%| F|  |TAMS 0x00000000d4800000, 0x00000000d4800000| Untracked 
|1353|0x00000000d4900000, 0x00000000d4900000, 0x00000000d4a00000|  0%| F|  |TAMS 0x00000000d4900000, 0x00000000d4900000| Untracked 
|1354|0x00000000d4a00000, 0x00000000d4a00000, 0x00000000d4b00000|  0%| F|  |TAMS 0x00000000d4a00000, 0x00000000d4a00000| Untracked 
|1355|0x00000000d4b00000, 0x00000000d4b00000, 0x00000000d4c00000|  0%| F|  |TAMS 0x00000000d4b00000, 0x00000000d4b00000| Untracked 
|1356|0x00000000d4c00000, 0x00000000d4c00000, 0x00000000d4d00000|  0%| F|  |TAMS 0x00000000d4c00000, 0x00000000d4c00000| Untracked 
|1357|0x00000000d4d00000, 0x00000000d4d00000, 0x00000000d4e00000|  0%| F|  |TAMS 0x00000000d4d00000, 0x00000000d4d00000| Untracked 
|1358|0x00000000d4e00000, 0x00000000d4e00000, 0x00000000d4f00000|  0%| F|  |TAMS 0x00000000d4e00000, 0x00000000d4e00000| Untracked 
|1359|0x00000000d4f00000, 0x00000000d4f00000, 0x00000000d5000000|  0%| F|  |TAMS 0x00000000d4f00000, 0x00000000d4f00000| Untracked 
|1360|0x00000000d5000000, 0x00000000d5000000, 0x00000000d5100000|  0%| F|  |TAMS 0x00000000d5000000, 0x00000000d5000000| Untracked 
|1361|0x00000000d5100000, 0x00000000d5100000, 0x00000000d5200000|  0%| F|  |TAMS 0x00000000d5100000, 0x00000000d5100000| Untracked 
|1362|0x00000000d5200000, 0x00000000d5200000, 0x00000000d5300000|  0%| F|  |TAMS 0x00000000d5200000, 0x00000000d5200000| Untracked 
|1363|0x00000000d5300000, 0x00000000d5300000, 0x00000000d5400000|  0%| F|  |TAMS 0x00000000d5300000, 0x00000000d5300000| Untracked 
|1364|0x00000000d5400000, 0x00000000d5400000, 0x00000000d5500000|  0%| F|  |TAMS 0x00000000d5400000, 0x00000000d5400000| Untracked 
|1365|0x00000000d5500000, 0x00000000d5500000, 0x00000000d5600000|  0%| F|  |TAMS 0x00000000d5500000, 0x00000000d5500000| Untracked 
|1366|0x00000000d5600000, 0x00000000d5600000, 0x00000000d5700000|  0%| F|  |TAMS 0x00000000d5600000, 0x00000000d5600000| Untracked 
|1367|0x00000000d5700000, 0x00000000d5700000, 0x00000000d5800000|  0%| F|  |TAMS 0x00000000d5700000, 0x00000000d5700000| Untracked 
|1368|0x00000000d5800000, 0x00000000d5800000, 0x00000000d5900000|  0%| F|  |TAMS 0x00000000d5800000, 0x00000000d5800000| Untracked 
|1369|0x00000000d5900000, 0x00000000d5900000, 0x00000000d5a00000|  0%| F|  |TAMS 0x00000000d5900000, 0x00000000d5900000| Untracked 
|1370|0x00000000d5a00000, 0x00000000d5a81258, 0x00000000d5b00000| 50%| E|  |TAMS 0x00000000d5a00000, 0x00000000d5a00000| Complete 
|1371|0x00000000d5b00000, 0x00000000d5c00000, 0x00000000d5c00000|100%| E|CS|TAMS 0x00000000d5b00000, 0x00000000d5b00000| Complete 
|1372|0x00000000d5c00000, 0x00000000d5d00000, 0x00000000d5d00000|100%| E|CS|TAMS 0x00000000d5c00000, 0x00000000d5c00000| Complete 
|1373|0x00000000d5d00000, 0x00000000d5e00000, 0x00000000d5e00000|100%| E|CS|TAMS 0x00000000d5d00000, 0x00000000d5d00000| Complete 
|1374|0x00000000d5e00000, 0x00000000d5f00000, 0x00000000d5f00000|100%| E|CS|TAMS 0x00000000d5e00000, 0x00000000d5e00000| Complete 
|1375|0x00000000d5f00000, 0x00000000d6000000, 0x00000000d6000000|100%| E|CS|TAMS 0x00000000d5f00000, 0x00000000d5f00000| Complete 
|1376|0x00000000d6000000, 0x00000000d6100000, 0x00000000d6100000|100%| E|CS|TAMS 0x00000000d6000000, 0x00000000d6000000| Complete 
|1377|0x00000000d6100000, 0x00000000d6200000, 0x00000000d6200000|100%| E|CS|TAMS 0x00000000d6100000, 0x00000000d6100000| Complete 
|1378|0x00000000d6200000, 0x00000000d6300000, 0x00000000d6300000|100%| E|CS|TAMS 0x00000000d6200000, 0x00000000d6200000| Complete 
|1379|0x00000000d6300000, 0x00000000d6400000, 0x00000000d6400000|100%| E|CS|TAMS 0x00000000d6300000, 0x00000000d6300000| Complete 
|1380|0x00000000d6400000, 0x00000000d6500000, 0x00000000d6500000|100%| E|CS|TAMS 0x00000000d6400000, 0x00000000d6400000| Complete 
|1381|0x00000000d6500000, 0x00000000d6600000, 0x00000000d6600000|100%| E|CS|TAMS 0x00000000d6500000, 0x00000000d6500000| Complete 
|1382|0x00000000d6600000, 0x00000000d6700000, 0x00000000d6700000|100%| E|CS|TAMS 0x00000000d6600000, 0x00000000d6600000| Complete 
|1383|0x00000000d6700000, 0x00000000d6800000, 0x00000000d6800000|100%| E|CS|TAMS 0x00000000d6700000, 0x00000000d6700000| Complete 
|1384|0x00000000d6800000, 0x00000000d6900000, 0x00000000d6900000|100%| E|CS|TAMS 0x00000000d6800000, 0x00000000d6800000| Complete 
|1385|0x00000000d6900000, 0x00000000d6a00000, 0x00000000d6a00000|100%| E|CS|TAMS 0x00000000d6900000, 0x00000000d6900000| Complete 
|1386|0x00000000d6a00000, 0x00000000d6b00000, 0x00000000d6b00000|100%| E|CS|TAMS 0x00000000d6a00000, 0x00000000d6a00000| Complete 
|1387|0x00000000d6b00000, 0x00000000d6c00000, 0x00000000d6c00000|100%| E|CS|TAMS 0x00000000d6b00000, 0x00000000d6b00000| Complete 
|1388|0x00000000d6c00000, 0x00000000d6d00000, 0x00000000d6d00000|100%| E|CS|TAMS 0x00000000d6c00000, 0x00000000d6c00000| Complete 
|1389|0x00000000d6d00000, 0x00000000d6e00000, 0x00000000d6e00000|100%| E|CS|TAMS 0x00000000d6d00000, 0x00000000d6d00000| Complete 
|1390|0x00000000d6e00000, 0x00000000d6f00000, 0x00000000d6f00000|100%| E|CS|TAMS 0x00000000d6e00000, 0x00000000d6e00000| Complete 
|1391|0x00000000d6f00000, 0x00000000d7000000, 0x00000000d7000000|100%| E|CS|TAMS 0x00000000d6f00000, 0x00000000d6f00000| Complete 
|1392|0x00000000d7000000, 0x00000000d7100000, 0x00000000d7100000|100%| E|CS|TAMS 0x00000000d7000000, 0x00000000d7000000| Complete 
|1393|0x00000000d7100000, 0x00000000d7200000, 0x00000000d7200000|100%| E|CS|TAMS 0x00000000d7100000, 0x00000000d7100000| Complete 
|1394|0x00000000d7200000, 0x00000000d7300000, 0x00000000d7300000|100%| E|CS|TAMS 0x00000000d7200000, 0x00000000d7200000| Complete 
|1395|0x00000000d7300000, 0x00000000d7400000, 0x00000000d7400000|100%| E|CS|TAMS 0x00000000d7300000, 0x00000000d7300000| Complete 
|1396|0x00000000d7400000, 0x00000000d7500000, 0x00000000d7500000|100%| E|CS|TAMS 0x00000000d7400000, 0x00000000d7400000| Complete 
|1397|0x00000000d7500000, 0x00000000d7600000, 0x00000000d7600000|100%| E|CS|TAMS 0x00000000d7500000, 0x00000000d7500000| Complete 
|1398|0x00000000d7600000, 0x00000000d7700000, 0x00000000d7700000|100%| E|CS|TAMS 0x00000000d7600000, 0x00000000d7600000| Complete 
|1399|0x00000000d7700000, 0x00000000d7800000, 0x00000000d7800000|100%| E|CS|TAMS 0x00000000d7700000, 0x00000000d7700000| Complete 
|1400|0x00000000d7800000, 0x00000000d7900000, 0x00000000d7900000|100%| E|CS|TAMS 0x00000000d7800000, 0x00000000d7800000| Complete 
|1401|0x00000000d7900000, 0x00000000d7a00000, 0x00000000d7a00000|100%| E|CS|TAMS 0x00000000d7900000, 0x00000000d7900000| Complete 
|1402|0x00000000d7a00000, 0x00000000d7b00000, 0x00000000d7b00000|100%| E|CS|TAMS 0x00000000d7a00000, 0x00000000d7a00000| Complete 
|1403|0x00000000d7b00000, 0x00000000d7c00000, 0x00000000d7c00000|100%| E|CS|TAMS 0x00000000d7b00000, 0x00000000d7b00000| Complete 
|1404|0x00000000d7c00000, 0x00000000d7d00000, 0x00000000d7d00000|100%| E|CS|TAMS 0x00000000d7c00000, 0x00000000d7c00000| Complete 
|1405|0x00000000d7d00000, 0x00000000d7e00000, 0x00000000d7e00000|100%| E|CS|TAMS 0x00000000d7d00000, 0x00000000d7d00000| Complete 
|1406|0x00000000d7e00000, 0x00000000d7f00000, 0x00000000d7f00000|100%| E|CS|TAMS 0x00000000d7e00000, 0x00000000d7e00000| Complete 
|1407|0x00000000d7f00000, 0x00000000d8000000, 0x00000000d8000000|100%| E|CS|TAMS 0x00000000d7f00000, 0x00000000d7f00000| Complete 
|1408|0x00000000d8000000, 0x00000000d8100000, 0x00000000d8100000|100%| E|CS|TAMS 0x00000000d8000000, 0x00000000d8000000| Complete 
|1409|0x00000000d8100000, 0x00000000d8200000, 0x00000000d8200000|100%| E|CS|TAMS 0x00000000d8100000, 0x00000000d8100000| Complete 
|1410|0x00000000d8200000, 0x00000000d8300000, 0x00000000d8300000|100%| E|CS|TAMS 0x00000000d8200000, 0x00000000d8200000| Complete 
|1411|0x00000000d8300000, 0x00000000d8400000, 0x00000000d8400000|100%| E|CS|TAMS 0x00000000d8300000, 0x00000000d8300000| Complete 
|1412|0x00000000d8400000, 0x00000000d8500000, 0x00000000d8500000|100%| E|CS|TAMS 0x00000000d8400000, 0x00000000d8400000| Complete 
|1413|0x00000000d8500000, 0x00000000d8600000, 0x00000000d8600000|100%| E|CS|TAMS 0x00000000d8500000, 0x00000000d8500000| Complete 
|1414|0x00000000d8600000, 0x00000000d8700000, 0x00000000d8700000|100%| E|CS|TAMS 0x00000000d8600000, 0x00000000d8600000| Complete 
|1415|0x00000000d8700000, 0x00000000d8800000, 0x00000000d8800000|100%| E|CS|TAMS 0x00000000d8700000, 0x00000000d8700000| Complete 

Card table byte_map: [0x0000024d5ae50000,0x0000024d5b250000] _byte_map_base: 0x0000024d5aa50000

Marking Bits (Prev, Next): (CMBitMap*) 0x0000024d36850ba0, (CMBitMap*) 0x0000024d36850be0
 Prev Bits: [0x0000024d5b650000, 0x0000024d5d650000)
 Next Bits: [0x0000024d5d650000, 0x0000024d5f650000)

Polling page: 0x0000024d34e30000

Metaspace:

Usage:
  Non-class:    332.13 MB used.
      Class:     48.31 MB used.
       Both:    380.43 MB used.

Virtual space:
  Non-class space:      336.00 MB reserved,     333.56 MB (>99%) committed,  42 nodes.
      Class space:        1.00 GB reserved,      49.62 MB (  5%) committed,  1 nodes.
             Both:        1.33 GB reserved,     383.19 MB ( 28%) committed. 

Chunk freelists:
   Non-Class:  1.53 MB
       Class:  2.34 MB
        Both:  3.88 MB

MaxMetaspaceSize: unlimited
CompressedClassSpaceSize: 1.00 GB
Initial GC threshold: 21.00 MB
Current GC threshold: 638.38 MB
CDS: off
MetaspaceReclaimPolicy: balanced
 - commit_granule_bytes: 65536.
 - commit_granule_words: 8192.
 - virtual_space_node_default_size: 1048576.
 - enlarge_chunks_in_place: 1.
 - new_chunks_are_fully_committed: 0.
 - uncommit_free_chunks: 1.
 - use_allocation_guard: 0.
 - handle_deallocations: 1.


Internal statistics:

num_allocs_failed_limit: 23.
num_arena_births: 5610.
num_arena_deaths: 1920.
num_vsnodes_births: 43.
num_vsnodes_deaths: 0.
num_space_committed: 6124.
num_space_uncommitted: 0.
num_chunks_returned_to_freelist: 2287.
num_chunks_taken_from_freelist: 24661.
num_chunk_merges: 738.
num_chunk_splits: 14469.
num_chunks_enlarged: 8185.
num_purges: 30.
num_inconsistent_stats: 0.

CodeHeap 'non-profiled nmethods': size=259328Kb used=40583Kb max_used=40583Kb free=218744Kb
 bounds [0x0000024d4a2b0000, 0x0000024d4ca60000, 0x0000024d59ff0000]
CodeHeap 'profiled nmethods': size=259264Kb used=106887Kb max_used=106887Kb free=152376Kb
 bounds [0x0000024d39ff0000, 0x0000024d40890000, 0x0000024d49d20000]
CodeHeap 'non-nmethods': size=5696Kb used=2570Kb max_used=2682Kb free=3125Kb
 bounds [0x0000024d49d20000, 0x0000024d49ff0000, 0x0000024d4a2b0000]
 total_blobs=53687 nmethods=51799 adapters=1791
 compilation: enabled
              stopped_count=0, restarted_count=0
 full_count=0

Compilation events (20 events):
Event: 1368.273 Thread 0x0000024d62830360 76942       4       com.intellij.openapi.util.Disposer::register (26 bytes)
Event: 1368.273 Thread 0x0000024d628315a0 76957       3       com.intellij.openapi.fileEditor.FileEditorManagerListener::fileOpenedSync (25 bytes)
Event: 1368.273 Thread 0x0000024d628315a0 nmethod 76957 0x0000024d3f343e90 code [0x0000024d3f344060, 0x0000024d3f3442c8]
Event: 1368.273 Thread 0x0000024d62830360 nmethod 76942 0x0000024d4ca4f490 code [0x0000024d4ca4f620, 0x0000024d4ca4f6e8]
Event: 1368.273 Thread 0x0000024d628315a0 76958       3       com.intellij.database.vfs.DatabaseElementVirtualFileImpl::getParent (71 bytes)
Event: 1368.274 Thread 0x0000024d628315a0 nmethod 76958 0x0000024d40215990 code [0x0000024d40215bc0, 0x0000024d40216438]
Event: 1368.274 Thread 0x0000024d628315a0 76959       3       com.intellij.internal.statistic.eventLog.events.StringEventField$ValidatedByCustomValidationRule::equals (55 bytes)
Event: 1368.274 Thread 0x0000024d628315a0 nmethod 76959 0x0000024d3f530610 code [0x0000024d3f530820, 0x0000024d3f531088]
Event: 1368.274 Thread 0x0000024d62830360 76960       4       java.lang.Throwable::<init> (50 bytes)
Event: 1368.277 Thread 0x0000024d62830360 nmethod 76960 0x0000024d4ca4f810 code [0x0000024d4ca4f9a0, 0x0000024d4ca4fe98]
Event: 1368.278 Thread 0x0000024d628315a0 76961       1       com.intellij.testFramework.LightVirtualFileBase$MyVirtualFileSystem::getProtocol (3 bytes)
Event: 1368.278 Thread 0x0000024d628315a0 nmethod 76961 0x0000024d4ca4ff90 code [0x0000024d4ca50120, 0x0000024d4ca501f8]
Event: 1368.280 Thread 0x0000024d628315a0 76962       3       com.intellij.testFramework.LightVirtualFile::<init> (61 bytes)
Event: 1368.281 Thread 0x0000024d628315a0 nmethod 76962 0x0000024d40881d10 code [0x0000024d40881f80, 0x0000024d40882c98]
Event: 1368.281 Thread 0x0000024d628315a0 76963       3       com.intellij.testFramework.LightVirtualFile::setLanguage (40 bytes)
Event: 1368.281 Thread 0x0000024d62830360 76964       4       com.intellij.lang.parser.GeneratedParserUtilBase$ErrorState::clearVariants (73 bytes)
Event: 1368.281 Thread 0x0000024d628315a0 nmethod 76963 0x0000024d40883090 code [0x0000024d408832e0, 0x0000024d40883e08]
Event: 1368.281 Thread 0x0000024d628315a0 76967       3       com.intellij.lang.parser.GeneratedParserUtilBase::close_frame_impl_ (471 bytes)
Event: 1368.282 Thread 0x0000024d628315a0 nmethod 76967 0x0000024d40884110 code [0x0000024d40884560, 0x0000024d40886468]
Event: 1368.282 Thread 0x0000024d628315a0 76966       3       com.intellij.lang.parser.GeneratedParserUtilBase::consumeTokens (183 bytes)

GC Heap History (20 events):
Event: 1274.653 GC heap before
{Heap before GC invocations=141 (full 0):
 garbage-first heap   total 1246208K, used 540674K [0x0000000080000000, 0x0000000100000000)
  region size 1024K, 60 young (61440K), 14 survivors (14336K)
 Metaspace       used 387794K, committed 390656K, reserved 1392640K
  class space    used 49471K, committed 50816K, reserved 1048576K
}
Event: 1274.661 GC heap after
{Heap after GC invocations=142 (full 0):
 garbage-first heap   total 1246208K, used 399226K [0x0000000080000000, 0x0000000100000000)
  region size 1024K, 3 young (3072K), 3 survivors (3072K)
 Metaspace       used 387794K, committed 390656K, reserved 1392640K
  class space    used 49471K, committed 50816K, reserved 1048576K
}
Event: 1274.664 GC heap before
{Heap before GC invocations=142 (full 0):
 garbage-first heap   total 1246208K, used 400250K [0x0000000080000000, 0x0000000100000000)
  region size 1024K, 5 young (5120K), 3 survivors (3072K)
 Metaspace       used 387796K, committed 390656K, reserved 1392640K
  class space    used 49471K, committed 50816K, reserved 1048576K
}
Event: 1274.667 GC heap after
{Heap after GC invocations=143 (full 0):
 garbage-first heap   total 1246208K, used 388424K [0x0000000080000000, 0x0000000100000000)
  region size 1024K, 3 young (3072K), 3 survivors (3072K)
 Metaspace       used 387796K, committed 390656K, reserved 1392640K
  class space    used 49471K, committed 50816K, reserved 1048576K
}
Event: 1300.195 GC heap before
{Heap before GC invocations=144 (full 0):
 garbage-first heap   total 1379328K, used 1354056K [0x0000000080000000, 0x0000000100000000)
  region size 1024K, 389 young (398336K), 3 survivors (3072K)
 Metaspace       used 388577K, committed 391488K, reserved 1392640K
  class space    used 49477K, committed 50816K, reserved 1048576K
}
Event: 1300.205 GC heap after
{Heap after GC invocations=145 (full 0):
 garbage-first heap   total 1379328K, used 396378K [0x0000000080000000, 0x0000000100000000)
  region size 1024K, 12 young (12288K), 12 survivors (12288K)
 Metaspace       used 388577K, committed 391488K, reserved 1392640K
  class space    used 49477K, committed 50816K, reserved 1048576K
}
Event: 1305.502 GC heap before
{Heap before GC invocations=145 (full 0):
 garbage-first heap   total 1379328K, used 452698K [0x0000000080000000, 0x0000000100000000)
  region size 1024K, 67 young (68608K), 12 survivors (12288K)
 Metaspace       used 388643K, committed 391488K, reserved 1392640K
  class space    used 49477K, committed 50816K, reserved 1048576K
}
Event: 1305.515 GC heap after
{Heap after GC invocations=146 (full 0):
 garbage-first heap   total 1379328K, used 388927K [0x0000000080000000, 0x0000000100000000)
  region size 1024K, 2 young (2048K), 2 survivors (2048K)
 Metaspace       used 388643K, committed 391488K, reserved 1392640K
  class space    used 49477K, committed 50816K, reserved 1048576K
}
Event: 1306.653 GC heap before
{Heap before GC invocations=146 (full 0):
 garbage-first heap   total 1379328K, used 410431K [0x0000000080000000, 0x0000000100000000)
  region size 1024K, 24 young (24576K), 2 survivors (2048K)
 Metaspace       used 388664K, committed 391552K, reserved 1392640K
  class space    used 49477K, committed 50816K, reserved 1048576K
}
Event: 1306.655 GC heap after
{Heap after GC invocations=147 (full 0):
 garbage-first heap   total 1379328K, used 388004K [0x0000000080000000, 0x0000000100000000)
  region size 1024K, 1 young (1024K), 1 survivors (1024K)
 Metaspace       used 388664K, committed 391552K, reserved 1392640K
  class space    used 49477K, committed 50816K, reserved 1048576K
}
Event: 1329.754 GC heap before
{Heap before GC invocations=148 (full 0):
 garbage-first heap   total 1379328K, used 1359780K [0x0000000080000000, 0x0000000100000000)
  region size 1024K, 431 young (441344K), 1 survivors (1024K)
 Metaspace       used 389320K, committed 392128K, reserved 1392640K
  class space    used 49478K, committed 50816K, reserved 1048576K
}
Event: 1329.762 GC heap after
{Heap after GC invocations=149 (full 0):
 garbage-first heap   total 1379328K, used 398206K [0x0000000080000000, 0x0000000100000000)
  region size 1024K, 11 young (11264K), 11 survivors (11264K)
 Metaspace       used 389320K, committed 392128K, reserved 1392640K
  class space    used 49478K, committed 50816K, reserved 1048576K
}
Event: 1332.142 GC heap before
{Heap before GC invocations=149 (full 0):
 garbage-first heap   total 1379328K, used 455550K [0x0000000080000000, 0x0000000100000000)
  region size 1024K, 67 young (68608K), 11 survivors (11264K)
 Metaspace       used 389321K, committed 392128K, reserved 1392640K
  class space    used 49478K, committed 50816K, reserved 1048576K
}
Event: 1332.153 GC heap after
{Heap after GC invocations=150 (full 0):
 garbage-first heap   total 1379328K, used 388489K [0x0000000080000000, 0x0000000100000000)
  region size 1024K, 2 young (2048K), 2 survivors (2048K)
 Metaspace       used 389321K, committed 392128K, reserved 1392640K
  class space    used 49478K, committed 50816K, reserved 1048576K
}
Event: 1332.791 GC heap before
{Heap before GC invocations=150 (full 0):
 garbage-first heap   total 1379328K, used 408969K [0x0000000080000000, 0x0000000100000000)
  region size 1024K, 23 young (23552K), 2 survivors (2048K)
 Metaspace       used 389333K, committed 392192K, reserved 1392640K
  class space    used 49478K, committed 50816K, reserved 1048576K
}
Event: 1332.794 GC heap after
{Heap after GC invocations=151 (full 0):
 garbage-first heap   total 1379328K, used 387431K [0x0000000080000000, 0x0000000100000000)
  region size 1024K, 1 young (1024K), 1 survivors (1024K)
 Metaspace       used 389333K, committed 392192K, reserved 1392640K
  class space    used 49478K, committed 50816K, reserved 1048576K
}
Event: 1357.522 GC heap before
{Heap before GC invocations=152 (full 0):
 garbage-first heap   total 1446912K, used 1433959K [0x0000000080000000, 0x0000000100000000)
  region size 1024K, 245 young (250880K), 1 survivors (1024K)
 Metaspace       used 389448K, committed 392256K, reserved 1392640K
  class space    used 49463K, committed 50816K, reserved 1048576K
}
Event: 1357.526 GC heap after
{Heap after GC invocations=153 (full 0):
 garbage-first heap   total 1446912K, used 387418K [0x0000000080000000, 0x0000000100000000)
  region size 1024K, 2 young (2048K), 2 survivors (2048K)
 Metaspace       used 389448K, committed 392256K, reserved 1392640K
  class space    used 49463K, committed 50816K, reserved 1048576K
}
Event: 1365.357 GC heap before
{Heap before GC invocations=153 (full 0):
 garbage-first heap   total 1446912K, used 457050K [0x0000000080000000, 0x0000000100000000)
  region size 1024K, 70 young (71680K), 2 survivors (2048K)
 Metaspace       used 389514K, committed 392320K, reserved 1392640K
  class space    used 49463K, committed 50816K, reserved 1048576K
}
Event: 1365.365 GC heap after
{Heap after GC invocations=154 (full 0):
 garbage-first heap   total 1446912K, used 376633K [0x0000000080000000, 0x0000000100000000)
  region size 1024K, 2 young (2048K), 2 survivors (2048K)
 Metaspace       used 389514K, committed 392320K, reserved 1392640K
  class space    used 49463K, committed 50816K, reserved 1048576K
}

Dll operation events (4 events):
Event: 0.005 Loaded shared library C:\Program Files\JetBrains\WebStorm 2022.3.3\jbr\bin\java.dll
Event: 0.232 Loaded shared library C:\Program Files\JetBrains\WebStorm 2022.3.3\jbr\bin\verify.dll
Event: 0.831 Loaded shared library C:\Program Files\JetBrains\WebStorm 2022.3.3\jbr\bin\instrument.dll
Event: 0.832 Loaded shared library C:\Program Files\JetBrains\WebStorm 2022.3.3\jbr\bin\zip.dll

Deoptimization events (20 events):
Event: 1368.281 Thread 0x0000024d6dbc0f10 Uncommon trap: trap_request=0xffffffde fr.pc=0x0000024d4b4d45a0 relative=0x0000000000000540
Event: 1368.281 Thread 0x0000024d6dbc0f10 Uncommon trap: reason=class_check action=maybe_recompile pc=0x0000024d4b4d45a0 method=com.intellij.lang.impl.PsiBuilderImpl.getCurrentOffset()I @ 11 c2
Event: 1368.281 Thread 0x0000024d6dbc0f10 DEOPT PACKING pc=0x0000024d4b4d45a0 sp=0x000000f05ecfad40
Event: 1368.281 Thread 0x0000024d6dbc0f10 DEOPT UNPACKING pc=0x0000024d49d769a3 sp=0x000000f05ecfad28 mode 2
Event: 1368.281 Thread 0x0000024d6dbc0f10 Uncommon trap: trap_request=0xffffffde fr.pc=0x0000024d4b4d45a0 relative=0x0000000000000540
Event: 1368.281 Thread 0x0000024d6dbc0f10 Uncommon trap: reason=class_check action=maybe_recompile pc=0x0000024d4b4d45a0 method=com.intellij.lang.impl.PsiBuilderImpl.getCurrentOffset()I @ 11 c2
Event: 1368.281 Thread 0x0000024d6dbc0f10 DEOPT PACKING pc=0x0000024d4b4d45a0 sp=0x000000f05ecfacc0
Event: 1368.281 Thread 0x0000024d6dbc0f10 DEOPT UNPACKING pc=0x0000024d49d769a3 sp=0x000000f05ecfaca8 mode 2
Event: 1368.281 Thread 0x0000024d6dbc0f10 Uncommon trap: trap_request=0xffffffde fr.pc=0x0000024d4b4d45a0 relative=0x0000000000000540
Event: 1368.281 Thread 0x0000024d6dbc0f10 Uncommon trap: reason=class_check action=maybe_recompile pc=0x0000024d4b4d45a0 method=com.intellij.lang.impl.PsiBuilderImpl.getCurrentOffset()I @ 11 c2
Event: 1368.281 Thread 0x0000024d6dbc0f10 DEOPT PACKING pc=0x0000024d4b4d45a0 sp=0x000000f05ecfacc0
Event: 1368.281 Thread 0x0000024d6dbc0f10 DEOPT UNPACKING pc=0x0000024d49d769a3 sp=0x000000f05ecfaca8 mode 2
Event: 1368.281 Thread 0x0000024d6dbc0f10 Uncommon trap: trap_request=0xffffff45 fr.pc=0x0000024d4abcae78 relative=0x0000000000002098
Event: 1368.281 Thread 0x0000024d6dbc0f10 Uncommon trap: reason=unstable_if action=reinterpret pc=0x0000024d4abcae78 method=com.intellij.lang.impl.PsiBuilderImpl.getASTFactory()Lcom/intellij/lang/ASTFactory; @ 7 c2
Event: 1368.281 Thread 0x0000024d6dbc0f10 DEOPT PACKING pc=0x0000024d4abcae78 sp=0x000000f05ecfc0c0
Event: 1368.281 Thread 0x0000024d6dbc0f10 DEOPT UNPACKING pc=0x0000024d49d769a3 sp=0x000000f05ecfc068 mode 2
Event: 1368.282 Thread 0x0000024d6dbc0f10 Uncommon trap: trap_request=0xffffffc6 fr.pc=0x0000024d4bebac44 relative=0x00000000000003e4
Event: 1368.282 Thread 0x0000024d6dbc0f10 Uncommon trap: reason=bimorphic_or_optimized_type_check action=maybe_recompile pc=0x0000024d4bebac44 method=com.intellij.openapi.editor.ex.util.ValidatingLexerWrapper.getTokenType()Lcom/intellij/psi/tree/IElementType; @ 12 c2
Event: 1368.282 Thread 0x0000024d6dbc0f10 DEOPT PACKING pc=0x0000024d4bebac44 sp=0x000000f05ecfbf90
Event: 1368.282 Thread 0x0000024d6dbc0f10 DEOPT UNPACKING pc=0x0000024d49d769a3 sp=0x000000f05ecfbf48 mode 2

Classes unloaded (20 events):
Event: 1333.001 Thread 0x0000024d61eb2220 Unloading class 0x0000000103128400 'java/lang/invoke/LambdaForm$MH+0x0000000103128400'
Event: 1333.001 Thread 0x0000024d61eb2220 Unloading class 0x0000000102d9a800 'java/lang/invoke/LambdaForm$MH+0x0000000102d9a800'
Event: 1333.001 Thread 0x0000024d61eb2220 Unloading class 0x0000000102d9a400 'java/lang/invoke/LambdaForm$MH+0x0000000102d9a400'
Event: 1333.001 Thread 0x0000024d61eb2220 Unloading class 0x0000000102d9a000 'java/lang/invoke/LambdaForm$MH+0x0000000102d9a000'
Event: 1333.001 Thread 0x0000024d61eb2220 Unloading class 0x0000000102d99c00 'java/lang/invoke/LambdaForm$MH+0x0000000102d99c00'
Event: 1333.001 Thread 0x0000024d61eb2220 Unloading class 0x0000000102d99800 'java/lang/invoke/LambdaForm$MH+0x0000000102d99800'
Event: 1333.001 Thread 0x0000024d61eb2220 Unloading class 0x0000000102d99400 'java/lang/invoke/LambdaForm$MH+0x0000000102d99400'
Event: 1333.001 Thread 0x0000024d61eb2220 Unloading class 0x0000000102d99000 'java/lang/invoke/LambdaForm$MH+0x0000000102d99000'
Event: 1333.001 Thread 0x0000024d61eb2220 Unloading class 0x0000000102d98c00 'java/lang/invoke/LambdaForm$MH+0x0000000102d98c00'
Event: 1333.001 Thread 0x0000024d61eb2220 Unloading class 0x000000010275f000 'java/lang/invoke/LambdaForm$MH+0x000000010275f000'
Event: 1333.001 Thread 0x0000024d61eb2220 Unloading class 0x000000010292c400 'java/lang/invoke/LambdaForm$MH+0x000000010292c400'
Event: 1333.001 Thread 0x0000024d61eb2220 Unloading class 0x000000010292d000 'java/lang/invoke/LambdaForm$MH+0x000000010292d000'
Event: 1333.001 Thread 0x0000024d61eb2220 Unloading class 0x0000000102901c00 'java/lang/invoke/LambdaForm$MH+0x0000000102901c00'
Event: 1333.001 Thread 0x0000024d61eb2220 Unloading class 0x0000000102901800 'java/lang/invoke/LambdaForm$MH+0x0000000102901800'
Event: 1333.001 Thread 0x0000024d61eb2220 Unloading class 0x0000000102901400 'java/lang/invoke/LambdaForm$MH+0x0000000102901400'
Event: 1333.001 Thread 0x0000024d61eb2220 Unloading class 0x0000000102901000 'java/lang/invoke/LambdaForm$MH+0x0000000102901000'
Event: 1333.001 Thread 0x0000024d61eb2220 Unloading class 0x0000000102900c00 'java/lang/invoke/LambdaForm$MH+0x0000000102900c00'
Event: 1333.001 Thread 0x0000024d61eb2220 Unloading class 0x0000000102900800 'java/lang/invoke/LambdaForm$MH+0x0000000102900800'
Event: 1333.001 Thread 0x0000024d61eb2220 Unloading class 0x00000001028c1000 'java/lang/invoke/LambdaForm$MH+0x00000001028c1000'
Event: 1333.001 Thread 0x0000024d61eb2220 Unloading class 0x0000000102851c00 'java/lang/invoke/LambdaForm$MH+0x0000000102851c00'

Classes redefined (1 events):
Event: 1.172 Thread 0x0000024d61eb2220 redefined class name=kotlin.coroutines.jvm.internal.DebugProbesKt, count=1

Internal exceptions (20 events):
Event: 1352.105 Thread 0x0000024d6dbc0f10 Exception <a 'sun/nio/fs/WindowsException'{0x00000000ca36fb30}> (0x00000000ca36fb30) 
thrown [s\src\hotspot\share\prims\jni.cpp, line 517]
Event: 1352.899 Thread 0x0000024d6dbc0f10 Exception <a 'sun/nio/fs/WindowsException'{0x00000000c98b3448}> (0x00000000c98b3448) 
thrown [s\src\hotspot\share\prims\jni.cpp, line 517]
Event: 1353.001 Thread 0x0000024d6dbc0f10 Exception <a 'sun/nio/fs/WindowsException'{0x00000000c97cf370}> (0x00000000c97cf370) 
thrown [s\src\hotspot\share\prims\jni.cpp, line 517]
Event: 1353.244 Thread 0x0000024d6dbc0f10 Exception <a 'sun/nio/fs/WindowsException'{0x00000000c94c4bd0}> (0x00000000c94c4bd0) 
thrown [s\src\hotspot\share\prims\jni.cpp, line 517]
Event: 1355.108 Thread 0x0000024d6dbc0f10 Implicit null exception at 0x0000024d4be18d0f to 0x0000024d4be18d4b
Event: 1355.112 Thread 0x0000024d6dbc0f10 Exception <a 'sun/nio/fs/WindowsException'{0x00000000c716ef20}> (0x00000000c716ef20) 
thrown [s\src\hotspot\share\prims\jni.cpp, line 517]
Event: 1355.448 Thread 0x0000024d6dbc0f10 Exception <a 'sun/nio/fs/WindowsException'{0x00000000c6e90740}> (0x00000000c6e90740) 
thrown [s\src\hotspot\share\prims\jni.cpp, line 517]
Event: 1355.619 Thread 0x0000024d6dbc0f10 Exception <a 'sun/nio/fs/WindowsException'{0x00000000c6cd8f80}> (0x00000000c6cd8f80) 
thrown [s\src\hotspot\share\prims\jni.cpp, line 517]
Event: 1356.078 Thread 0x0000024d6dbc0f10 Exception <a 'sun/nio/fs/WindowsException'{0x000000009c9df3d8}> (0x000000009c9df3d8) 
thrown [s\src\hotspot\share\prims\jni.cpp, line 517]
Event: 1356.078 Thread 0x0000024d6dbc0f10 Exception <a 'sun/nio/fs/WindowsException'{0x000000009c9ea480}> (0x000000009c9ea480) 
thrown [s\src\hotspot\share\prims\jni.cpp, line 517]
Event: 1356.116 Thread 0x0000024d6dbc0f10 Implicit null exception at 0x0000024d4bdfc096 to 0x0000024d4bdfc9cc
Event: 1356.134 Thread 0x0000024db3965700 Exception <a 'sun/nio/fs/WindowsException'{0x0000000093d8e578}> (0x0000000093d8e578) 
thrown [s\src\hotspot\share\prims\jni.cpp, line 517]
Event: 1368.180 Thread 0x0000024d6dbc0f10 Implicit null exception at 0x0000024d4b3742f5 to 0x0000024d4b374540
Event: 1368.271 Thread 0x0000024d6dbc0f10 Exception <a 'sun/nio/fs/WindowsException'{0x00000000d5b5f6e8}> (0x00000000d5b5f6e8) 
thrown [s\src\hotspot\share\prims\jni.cpp, line 517]
Event: 1368.272 Thread 0x0000024d6dbc0f10 Exception <a 'sun/nio/fs/WindowsException'{0x00000000d5b6d5e8}> (0x00000000d5b6d5e8) 
thrown [s\src\hotspot\share\prims\jni.cpp, line 517]
Event: 1368.274 Thread 0x0000024d6dbc0f10 Exception <a 'sun/nio/fs/WindowsException'{0x00000000d5a09830}> (0x00000000d5a09830) 
thrown [s\src\hotspot\share\prims\jni.cpp, line 517]
Event: 1368.281 Thread 0x0000024d6dbc0f10 Implicit null exception at 0x0000024d4bcdd06e to 0x0000024d4bcdd1fc
Event: 1368.281 Thread 0x0000024d6dbc0f10 Implicit null exception at 0x0000024d4bcdc3e0 to 0x0000024d4bcdc550
Event: 1368.281 Thread 0x0000024d6dbc0f10 Implicit null exception at 0x0000024d4b4c7bd1 to 0x0000024d4b4c7dc0
Event: 1368.282 Thread 0x0000024d6dbc0f10 Implicit null exception at 0x0000024d4078232a to 0x0000000000000000

VM Operations (20 events):
Event: 1357.101 Executing VM operation: Cleanup
Event: 1357.101 Executing VM operation: Cleanup done
Event: 1357.522 Executing VM operation: G1CollectForAllocation
Event: 1357.527 Executing VM operation: G1CollectForAllocation done
Event: 1357.627 Executing VM operation: HandshakeAllThreads
Event: 1357.627 Executing VM operation: HandshakeAllThreads done
Event: 1358.626 Executing VM operation: Cleanup
Event: 1358.627 Executing VM operation: Cleanup done
Event: 1359.627 Executing VM operation: Cleanup
Event: 1359.627 Executing VM operation: Cleanup done
Event: 1361.628 Executing VM operation: Cleanup
Event: 1361.628 Executing VM operation: Cleanup done
Event: 1362.629 Executing VM operation: Cleanup
Event: 1362.629 Executing VM operation: Cleanup done
Event: 1364.630 Executing VM operation: Cleanup
Event: 1364.630 Executing VM operation: Cleanup done
Event: 1365.357 Executing VM operation: G1CollectForAllocation
Event: 1365.365 Executing VM operation: G1CollectForAllocation done
Event: 1367.365 Executing VM operation: Cleanup
Event: 1367.365 Executing VM operation: Cleanup done

Events (20 events):
Event: 1357.678 Thread 0x0000024d6283d170 flushing nmethod 0x0000024d3edcb790
Event: 1357.679 Thread 0x0000024d6283d170 flushing nmethod 0x0000024d3eee4590
Event: 1357.679 Thread 0x0000024d6283d170 flushing nmethod 0x0000024d3eee4990
Event: 1357.679 Thread 0x0000024d6283d170 flushing nmethod 0x0000024d3ef20990
Event: 1357.680 Thread 0x0000024d6283d170 flushing nmethod 0x0000024d3f19f110
Event: 1357.681 Thread 0x0000024d6283d170 flushing nmethod 0x0000024d3f2ae810
Event: 1357.682 Thread 0x0000024d6283d170 flushing nmethod 0x0000024d3f38f610
Event: 1357.682 Thread 0x0000024d6283d170 flushing nmethod 0x0000024d3f392790
Event: 1357.682 Thread 0x0000024d6283d170 flushing nmethod 0x0000024d3f4a8410
Event: 1357.683 Thread 0x0000024d6283d170 flushing nmethod 0x0000024d3f737d10
Event: 1357.683 Thread 0x0000024d6283d170 flushing nmethod 0x0000024d3f766210
Event: 1357.683 Thread 0x0000024d6283d170 flushing nmethod 0x0000024d3f769790
Event: 1357.684 Thread 0x0000024d6283d170 flushing nmethod 0x0000024d3f839f90
Event: 1357.684 Thread 0x0000024d6283d170 flushing nmethod 0x0000024d3f980910
Event: 1357.685 Thread 0x0000024d6283d170 flushing nmethod 0x0000024d3f9d4210
Event: 1357.686 Thread 0x0000024d6283d170 flushing nmethod 0x0000024d3fcbf610
Event: 1357.686 Thread 0x0000024d6283d170 flushing nmethod 0x0000024d3fd47f90
Event: 1357.687 Thread 0x0000024d6283d170 flushing nmethod 0x0000024d3fdcad90
Event: 1357.688 Thread 0x0000024d6283d170 flushing nmethod 0x0000024d40076910
Event: 1357.689 Thread 0x0000024d6283d170 flushing nmethod 0x0000024d4021b710


Dynamic libraries:
0x00007ff6622b0000 - 0x00007ff66234a000 	C:\Program Files\JetBrains\WebStorm 2022.3.3\bin\webstorm64.exe
0x00007ffcbafb0000 - 0x00007ffcbb1a8000 	C:\Windows\SYSTEM32\ntdll.dll
0x00007ffcb91b0000 - 0x00007ffcb926f000 	C:\Windows\System32\KERNEL32.DLL
0x00007ffcb8bd0000 - 0x00007ffcb8ea2000 	C:\Windows\System32\KERNELBASE.dll
0x00007ffcba640000 - 0x00007ffcba7e1000 	C:\Windows\System32\USER32.dll
0x00007ffcb87e0000 - 0x00007ffcb8802000 	C:\Windows\System32\win32u.dll
0x00007ffcbab90000 - 0x00007ffcbabbb000 	C:\Windows\System32\GDI32.dll
0x00007ffcb8a20000 - 0x00007ffcb8b2f000 	C:\Windows\System32\gdi32full.dll
0x00007ffcb8b30000 - 0x00007ffcb8bcd000 	C:\Windows\System32\msvcp_win.dll
0x00007ffcb86b0000 - 0x00007ffcb87b0000 	C:\Windows\System32\ucrtbase.dll
0x00007ffcb9ef0000 - 0x00007ffcba635000 	C:\Windows\System32\SHELL32.dll
0x00007ffcba9e0000 - 0x00007ffcbab0a000 	C:\Windows\System32\ole32.dll
0x00007ffcb9760000 - 0x00007ffcb9884000 	C:\Windows\System32\RPCRT4.dll
0x00007ffcb9380000 - 0x00007ffcb96d5000 	C:\Windows\System32\combase.dll
0x00007ffcbac90000 - 0x00007ffcbad3e000 	C:\Windows\System32\ADVAPI32.dll
0x00007ffcb9d00000 - 0x00007ffcb9d9e000 	C:\Windows\System32\msvcrt.dll
0x00007ffcbae60000 - 0x00007ffcbaefc000 	C:\Windows\System32\sechost.dll
0x00007ffcb9da0000 - 0x00007ffcb9dd0000 	C:\Windows\System32\IMM32.DLL
0x00007ffcba930000 - 0x00007ffcba9dd000 	C:\Windows\System32\shcore.dll
0x00007ffc74ca0000 - 0x00007ffc7590d000 	C:\Program Files\JetBrains\WebStorm 2022.3.3\jbr\bin\server\jvm.dll
0x00007ffcb2fa0000 - 0x00007ffcb2faa000 	C:\Windows\SYSTEM32\VERSION.dll
0x00007ffcb5ef0000 - 0x00007ffcb5ef9000 	C:\Windows\SYSTEM32\WSOCK32.dll
0x00007ffcb5d00000 - 0x00007ffcb5d27000 	C:\Windows\SYSTEM32\WINMM.dll
0x00007ffcb5e70000 - 0x00007ffcb5e89000 	C:\Windows\SYSTEM32\VCRUNTIME140.dll
0x00007ffcbaf00000 - 0x00007ffcbaf6b000 	C:\Windows\System32\WS2_32.dll
0x00007ffcb5e60000 - 0x00007ffcb5e6c000 	C:\Windows\SYSTEM32\VCRUNTIME140_1.dll
0x00007ffcb42d0000 - 0x00007ffcb42da000 	C:\Program Files\JetBrains\WebStorm 2022.3.3\jbr\bin\jimage.dll
0x00007ffca7530000 - 0x00007ffca7714000 	C:\Windows\SYSTEM32\DBGHELP.DLL
0x00007ffca55c0000 - 0x00007ffca55f5000 	C:\Windows\SYSTEM32\dbgcore.DLL
0x00007ffcb8f70000 - 0x00007ffcb8ff2000 	C:\Windows\System32\bcryptPrimitives.dll
0x00007ffcae3b0000 - 0x00007ffcae3d5000 	C:\Program Files\JetBrains\WebStorm 2022.3.3\jbr\bin\java.dll
0x00007ffcb6550000 - 0x00007ffcb6562000 	C:\Windows\SYSTEM32\kernel.appcore.dll
0x00007ffcb42b0000 - 0x00007ffcb42c8000 	C:\Program Files\JetBrains\WebStorm 2022.3.3\jbr\bin\zip.dll
0x00007ffcb6750000 - 0x00007ffcb6ee2000 	C:\Windows\SYSTEM32\windows.storage.dll
0x00007ffcb8030000 - 0x00007ffcb8060000 	C:\Windows\SYSTEM32\Wldp.dll
0x00007ffcba7f0000 - 0x00007ffcba845000 	C:\Windows\System32\shlwapi.dll
0x00007ffcb85f0000 - 0x00007ffcb860f000 	C:\Windows\SYSTEM32\profapi.dll
0x00007ffcadc20000 - 0x00007ffcadc39000 	C:\Program Files\JetBrains\WebStorm 2022.3.3\jbr\bin\net.dll
0x00007ffcb2110000 - 0x00007ffcb221a000 	C:\Windows\SYSTEM32\WINHTTP.dll
0x00007ffcb7e10000 - 0x00007ffcb7e7a000 	C:\Windows\system32\mswsock.dll
0x00007ffcadc00000 - 0x00007ffcadc16000 	C:\Program Files\JetBrains\WebStorm 2022.3.3\jbr\bin\nio.dll
0x00007ffcae210000 - 0x00007ffcae220000 	C:\Program Files\JetBrains\WebStorm 2022.3.3\jbr\bin\verify.dll
0x00007ffc95e60000 - 0x00007ffc95ff3000 	C:\Program Files\JetBrains\WebStorm 2022.3.3\jbr\bin\awt.dll
0x00007ffcbabc0000 - 0x00007ffcbac8d000 	C:\Windows\System32\OLEAUT32.dll
0x00007ffcb6260000 - 0x00007ffcb628f000 	C:\Windows\SYSTEM32\dwmapi.dll
0x00007ffc99db0000 - 0x00007ffc99e3d000 	C:\Program Files\JetBrains\WebStorm 2022.3.3\bin\MSVCP140.dll
0x00007ffcb5f60000 - 0x00007ffcb5ff0000 	C:\Windows\SYSTEM32\apphelp.dll
0x00007ffcadb50000 - 0x00007ffcadb5e000 	C:\Program Files\JetBrains\WebStorm 2022.3.3\jbr\bin\sunmscapi.dll
0x00007ffcb8810000 - 0x00007ffcb8966000 	C:\Windows\System32\CRYPT32.dll
0x00007ffcb80a0000 - 0x00007ffcb80c7000 	C:\Windows\SYSTEM32\ncrypt.dll
0x00007ffcb8060000 - 0x00007ffcb809b000 	C:\Windows\SYSTEM32\NTASN1.dll
0x00007ffcaba30000 - 0x00007ffcaba39000 	C:\Program Files\JetBrains\WebStorm 2022.3.3\jbr\bin\prefs.dll
0x00007ffcb8370000 - 0x00007ffcb8388000 	C:\Windows\SYSTEM32\CRYPTSP.dll
0x00007ffcb7670000 - 0x00007ffcb76a4000 	C:\Windows\system32\rsaenh.dll
0x00007ffcb87b0000 - 0x00007ffcb87d7000 	C:\Windows\System32\bcrypt.dll
0x00007ffcb85b0000 - 0x00007ffcb85de000 	C:\Windows\SYSTEM32\USERENV.dll
0x00007ffcb7fa0000 - 0x00007ffcb7fac000 	C:\Windows\SYSTEM32\CRYPTBASE.dll
0x00007ffcb7ab0000 - 0x00007ffcb7aeb000 	C:\Windows\SYSTEM32\IPHLPAPI.DLL
0x00007ffcbab80000 - 0x00007ffcbab88000 	C:\Windows\System32\NSI.dll
0x00007ffcb2f20000 - 0x00007ffcb2f37000 	C:\Windows\SYSTEM32\dhcpcsvc6.DLL
0x00007ffcb2cd0000 - 0x00007ffcb2ced000 	C:\Windows\SYSTEM32\dhcpcsvc.DLL
0x00007ffcb7af0000 - 0x00007ffcb7bbb000 	C:\Windows\SYSTEM32\DNSAPI.dll
0x00007ffca32a0000 - 0x00007ffca3350000 	C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_5.82.19041.1110_none_792d1c772443f647\COMCTL32.dll
0x00007ffcb6080000 - 0x00007ffcb611e000 	C:\Windows\system32\uxtheme.dll
0x00007ffcbad40000 - 0x00007ffcbae54000 	C:\Windows\System32\MSCTF.dll
0x00007ffcaac40000 - 0x00007ffcaac80000 	C:\Program Files\JetBrains\WebStorm 2022.3.3\lib\jna\amd64\jnidispatch.dll
0x00007ffcbab10000 - 0x00007ffcbab18000 	C:\Windows\System32\PSAPI.DLL
0x00007ffcaac30000 - 0x00007ffcaac39000 	C:\Program Files\JetBrains\WebStorm 2022.3.3\jbr\bin\management.dll
0x00007ffcaac20000 - 0x00007ffcaac2b000 	C:\Program Files\JetBrains\WebStorm 2022.3.3\jbr\bin\management_ext.dll
0x00007ffcaac10000 - 0x00007ffcaac1e000 	C:\Program Files\JetBrains\WebStorm 2022.3.3\jbr\bin\instrument.dll
0x00007ffcaa0f0000 - 0x00007ffcaa107000 	C:\Program Files\JetBrains\WebStorm 2022.3.3\jbr\bin\jli.dll
0x00007ffc7a7a0000 - 0x00007ffc7a8c5000 	C:\Windows\system32\opengl32.dll
0x00007ffca0030000 - 0x00007ffca005c000 	C:\Windows\SYSTEM32\GLU32.dll
0x00007ffcaa0e0000 - 0x00007ffcaa0e7000 	C:\Windows\system32\wshunix.dll
0x00007ffc95dd0000 - 0x00007ffc95e56000 	C:\Program Files\JetBrains\WebStorm 2022.3.3\jbr\bin\freetype.dll
0x00007ffc796a0000 - 0x00007ffc79769000 	C:\Program Files\JetBrains\WebStorm 2022.3.3\jbr\bin\fontmanager.dll
0x0000000066f40000 - 0x0000000066fc4000 	[USER_DIR]\AppData\Local\Temp\liblz4-java-3335992727958411050.so
0x00007ffcb8410000 - 0x00007ffcb8422000 	C:\Windows\SYSTEM32\MSASN1.dll
0x00007ffcae240000 - 0x00007ffcae339000 	C:\Windows\SYSTEM32\textinputframework.dll
0x00007ffcb5850000 - 0x00007ffcb5bae000 	C:\Windows\System32\CoreUIComponents.dll
0x00007ffcb5bb0000 - 0x00007ffcb5ca2000 	C:\Windows\System32\CoreMessaging.dll
0x00007ffcb7790000 - 0x00007ffcb77c3000 	C:\Windows\SYSTEM32\ntmarta.dll
0x00007ffcb5150000 - 0x00007ffcb52a4000 	C:\Windows\SYSTEM32\wintypes.dll
0x00007ffcb9270000 - 0x00007ffcb9319000 	C:\Windows\System32\clbcatq.dll
0x00007ffca47b0000 - 0x00007ffca4a4a000 	C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.19041.1110_none_60b5254171f9507e\comctl32.dll
0x00007ffcb1f50000 - 0x00007ffcb2104000 	C:\Windows\SYSTEM32\WindowsCodecs.dll
0x00007ffcaf0c0000 - 0x00007ffcaf0fe000 	C:\Windows\system32\dataexchange.dll
0x00007ffcb4370000 - 0x00007ffcb45d3000 	C:\Windows\system32\d3d11.dll
0x00007ffcb4e10000 - 0x00007ffcb4ff3000 	C:\Windows\system32\dcomp.dll
0x00007ffcb6f30000 - 0x00007ffcb7023000 	C:\Windows\system32\dxgi.dll
0x00007ffcb2790000 - 0x00007ffcb2990000 	C:\Windows\system32\twinapi.appcore.dll
0x00007ffca9db0000 - 0x00007ffca9de8000 	C:\Program Files\JetBrains\WebStorm 2022.3.3\bin\WinShellIntegrationBridge.dll
0x00007ffca34a0000 - 0x00007ffca3530000 	C:\Windows\System32\appresolver.dll
0x00007ffcb71b0000 - 0x00007ffcb71d9000 	C:\Windows\System32\SLC.dll
0x00007ffcaee90000 - 0x00007ffcaeeeb000 	C:\Windows\System32\Bcp47Langs.dll
0x00007ffcb7180000 - 0x00007ffcb71a5000 	C:\Windows\System32\sppc.dll
0x00007ffcb40a0000 - 0x00007ffcb4196000 	C:\Windows\SYSTEM32\PROPSYS.dll
0x00007ffcb96e0000 - 0x00007ffcb9759000 	C:\Windows\System32\coml2.dll
0x00007ffc9bc40000 - 0x00007ffc9bdbe000 	C:\Windows\System32\TaskFlowDataEngine.dll
0x00007ffc97b40000 - 0x00007ffc9800c000 	C:\Windows\System32\cdp.dll
0x00007ffcb8eb0000 - 0x00007ffcb8efe000 	C:\Windows\System32\cfgmgr32.dll
0x00007ffcb7bd0000 - 0x00007ffcb7be2000 	C:\Windows\System32\UMPDC.dll
0x00007ffcb5000000 - 0x00007ffcb514d000 	C:\Windows\System32\dsreg.dll
0x00007ffcb7700000 - 0x00007ffcb778a000 	C:\Windows\System32\msvcp110_win.dll
0x00007ffc9cd80000 - 0x00007ffc9cdff000 	C:\Windows\System32\OneCoreCommonProxyStub.dll
0x00007ffcb3930000 - 0x00007ffcb3947000 	C:\Windows\system32\NetworkExplorer.dll
0x00007ffc9b940000 - 0x00007ffc9b95d000 	C:\Windows\SYSTEM32\MPR.dll
0x00007ffcb3650000 - 0x00007ffcb3679000 	C:\Windows\System32\p9np.dll
0x00007ffcb3640000 - 0x00007ffcb364b000 	C:\Windows\System32\drprov.dll
0x00007ffcb79b0000 - 0x00007ffcb7a14000 	C:\Windows\System32\WINSTA.dll
0x00007ffcb3620000 - 0x00007ffcb363f000 	C:\Windows\System32\ntlanman.dll
0x00007ffcb3580000 - 0x00007ffcb359e000 	C:\Windows\System32\davclnt.dll
0x00007ffcb3570000 - 0x00007ffcb357d000 	C:\Windows\System32\DAVHLPR.dll
0x00007ffc949e0000 - 0x00007ffc949ed000 	C:\Windows\SYSTEM32\LINKINFO.dll
0x00007ffca8e90000 - 0x00007ffca8f0d000 	C:\Windows\SYSTEM32\ntshrui.dll
0x00007ffcb8570000 - 0x00007ffcb85a2000 	C:\Windows\SYSTEM32\SspiCli.dll
0x00007ffca59a0000 - 0x00007ffca59c8000 	C:\Windows\SYSTEM32\srvcli.dll
0x00007ffc98010000 - 0x00007ffc98022000 	C:\Windows\SYSTEM32\cscapi.dll
0x00007ffcb3430000 - 0x00007ffcb34d3000 	C:\Windows\SYSTEM32\policymanager.dll
0x00007ffcb14c0000 - 0x00007ffcb14ca000 	C:\Windows\System32\rasadhlp.dll
0x00007ffcb14d0000 - 0x00007ffcb1550000 	C:\Windows\System32\fwpuclnt.dll
0x00007ffcae3a0000 - 0x00007ffcae3ac000 	C:\Program Files\JetBrains\WebStorm 2022.3.3\lib\pty4j\win\x86-64\win-helper.dll
0x00007ffc9c060000 - 0x00007ffc9c280000 	C:\Windows\system32\explorerframe.dll
0x00007ffc94770000 - 0x00007ffc947b9000 	C:\Windows\SYSTEM32\pdh.dll
0x00007ffcb5e20000 - 0x00007ffcb5e2f000 	C:\Windows\System32\perfos.dll
0x00007ffc9a1d0000 - 0x00007ffc9a1e7000 	C:\Windows\system32\napinsp.dll
0x00007ffc9a1b0000 - 0x00007ffc9a1cb000 	C:\Windows\system32\pnrpnsp.dll
0x00007ffcb3bb0000 - 0x00007ffcb3bc5000 	C:\Windows\system32\wshbth.dll

dbghelp: loaded successfully - version: 4.0.5 - missing functions: none
symbol engine: initialized successfully - sym options: 0x614 - pdb path: .;C:\Program Files\JetBrains\WebStorm 2022.3.3\bin;C:\Windows\SYSTEM32;C:\Program Files\JetBrains\WebStorm 2022.3.3\jbr\bin\server;C:\Program Files\JetBrains\WebStorm 2022.3.3\jbr\bin;C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_5.82.19041.1110_none_792d1c772443f647;C:\Program Files\JetBrains\WebStorm 2022.3.3\lib\jna\amd64;[USER_DIR]\AppData\Local\Temp\jna-82353;[USER_DIR]\AppData\Local\Temp;C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.19041.1110_none_60b5254171f9507e;C:\Program Files\JetBrains\WebStorm 2022.3.3\lib\pty4j\win\x86-64;C:\ProgramData\Microsoft\Windows Defender\platform\4.18.2301.6-0

VM Arguments:
jvm_args: exit -Xms128m -Xmx750m -XX:ReservedCodeCacheSize=512m -XX:+UseG1GC -XX:SoftRefLRUPolicyMSPerMB=50 -XX:CICompilerCount=2 -XX:+HeapDumpOnOutOfMemoryError -XX:-OmitStackTraceInFastThrow -XX:+IgnoreUnrecognizedVMOptions -XX:CompileCommand=exclude,com/intellij/openapi/vfs/impl/FilePartNodeRoot,trieDescend -ea -Dsun.io.useCanonCaches=false -Dsun.java2d.metal=true -Djbr.catch.SIGABRT=true -Djdk.http.auth.tunneling.disabledSchemes="" -Djdk.attach.allowAttachSelf=true -Djdk.module.illegalAccess.silent=true -Dkotlinx.coroutines.debug=off -Xmx2048m -Djb.vmOptionsFile=[USER_DIR]\AppData\Roaming\\JetBrains\\WebStorm2022.3\webstorm64.exe.vmoptions -Djava.system.class.loader=com.intellij.util.lang.PathClassLoader -Didea.vendor.name=JetBrains -Didea.paths.selector=WebStorm2022.3 -Djna.boot.library.path=C:\Program Files\JetBrains\WebStorm 2022.3.3/lib/jna/amd64 -Dpty4j.preferred.native.folder=C:\Program Files\JetBrains\WebStorm 2022.3.3/lib/pty4j -Djna.nosys=true -Djna.noclasspath=true -Didea.platform.prefix=WebStorm -Dsplash=true --add-opens=java.base/java.io=ALL-UNNAMED --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.lang.ref=ALL-UNNAMED --add-opens=java.base/java.lang.reflect=ALL-UNNAMED --add-opens=java.base/java.net=ALL-UNNAMED --add-opens=java.base/java.nio=ALL-UNNAMED --add-opens=java.base/java.nio.charset=ALL-UNNAMED --add-opens=java.base/java.text=ALL-UNNAMED --add-opens=java.base/java.time=ALL-UNNAMED --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.util.concurrent=ALL-UNNAMED --add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED --add-opens=java.base/jdk.internal.vm=ALL-UNNAMED --add-opens=java.base/sun.nio.ch=ALL-UNNAMED --add-opens=java.base/sun.nio.fs=ALL-UNNAMED --add-opens=java.base/sun.security.ssl=ALL-UNNAMED --add-opens=java.base/sun.security.util=ALL-UNNAMED --add-opens=java.desktop/java.awt=ALL-UNNAMED --add-opens=java.desktop/java.awt.dnd.peer=ALL-UNNAMED --add-opens=java.desktop/java.awt.event=ALL-UNNAMED --add-opens=java.desktop/java.awt.image=ALL-UNNAMED --add-opens=java.desktop/java.awt.peer=ALL-UNNAMED --add-opens=java.desktop/java.awt.font=ALL-UNNAMED --add-opens=java.desktop/javax.swing=ALL-UNNAMED --add-opens=java.desktop/javax.swing.plaf.basic=ALL-UNNAMED --add-opens=java.desktop/javax.swing.text.html=ALL-UNNAMED --add-opens=java.desktop/sun.awt.datatransfer=ALL-UNNAMED --add-opens=java.desktop/sun.awt.image=ALL-UNNAMED --add-opens=java.desktop/sun.awt.windows=ALL-UNNAMED --add-opens=java.desktop/sun.awt=ALL-UNNAMED --add-opens=java.desktop/sun.font=ALL-UNNAMED --add-opens=java.desktop/sun.java2d=ALL-UNNAMED --add-opens=java.desktop/sun.swing=ALL-UNNAMED --add-opens=jdk.attach/sun.tools.attach=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED --add-opens=jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED --add-opens=jdk.jdi/com.sun.tools.jdi=ALL-UNNAMED -Dide.native.launcher=true -XX:ErrorFile=[USER_DIR]\java_error_in_webstorm64_%p.log -XX:HeapDumpPath=[USER_DIR]\java_error_in_webstorm64.hprof
java_command: <unknown>
java_class_path (initial): C:\Program Files\JetBrains\WebStorm 2022.3.3\lib\util.jar;C:\Program Files\JetBrains\WebStorm 2022.3.3\lib\app.jar;C:\Program Files\JetBrains\WebStorm 2022.3.3\lib\3rd-party-rt.jar;C:\Program Files\JetBrains\WebStorm 2022.3.3\lib\platform-statistics-devkit.jar;C:\Program Files\JetBrains\WebStorm 2022.3.3\lib\jps-model.jar;C:\Program Files\JetBrains\WebStorm 2022.3.3\lib\stats.jar;C:\Program Files\JetBrains\WebStorm 2022.3.3\lib\protobuf.jar;C:\Program Files\JetBrains\WebStorm 2022.3.3\lib\external-system-rt.jar;C:\Program Files\JetBrains\WebStorm 2022.3.3\lib\forms_rt.jar;C:\Program Files\JetBrains\WebStorm 2022.3.3\lib\intellij-test-discovery.jar;C:\Program Files\JetBrains\WebStorm 2022.3.3\lib\groovy.jar;C:\Program Files\JetBrains\WebStorm 2022.3.3\lib\3rd-party-native.jar;C:\Program Files\JetBrains\WebStorm 2022.3.3\lib\annotations-java5.jar;C:\Program Files\JetBrains\WebStorm 2022.3.3\lib\async-profiler-windows.jar;C:\Program Files\JetBrains\WebStorm 2022.3.3\lib\async-profiler.jar;C:\Program Files\JetBrains\WebStorm 2022.3.3\lib\branding.jar;C:\Program Files\JetBrains\WebStorm 2022.3.3\lib\byte-buddy-agent.jar;C:\Program Files\JetBrains\WebStorm 2022.3.3\lib\error-prone-annotations.jar;C:\Program Files\JetBrains\WebStorm 2022.3.3\lib\externalProcess-rt.jar;C:\Program Files\JetBrains\WebStorm 2022.3.3\lib\intellij-coverage-agent-1.0.682.jar;C:\Program Files\JetBrains\WebStorm 2022.3.3\lib\jetbrains-annotations.jar;C:\Program Files\JetBrains\WebStorm 2022.3.3\lib\jsch-agent.jar;C:\Program Files\JetBrains\WebStorm 2022.3.3\lib\platform-objectSerializer-annotations.jar;C:\Program Files\JetBrains\WebStorm 2022.3.3\lib\rd.jar;C:\Program Files\JetBrains\WebStorm 2022.3.3\lib\util_rt.jar
Launcher Type: generic

[Global flags]
     intx CICompilerCount                          = 2                                         {product} {command line}
ccstrlist CompileCommand                           = exclude,com/intellij/openapi/vfs/impl/FilePartNodeRoot,trieDescend            {product} {command line}
     uint ConcGCThreads                            = 2                                         {product} {ergonomic}
    ccstr ErrorFile                                = [USER_DIR]\java_error_in_webstorm64_%p.log            {product} {command line}
     uint G1ConcRefinementThreads                  = 6                                         {product} {ergonomic}
   size_t G1HeapRegionSize                         = 1048576                                   {product} {ergonomic}
    uintx GCDrainStackTargetSize                   = 64                                        {product} {ergonomic}
     bool HeapDumpOnOutOfMemoryError               = true                                   {manageable} {command line}
    ccstr HeapDumpPath                             = [USER_DIR]\java_error_in_webstorm64.hprof         {manageable} {command line}
     bool IgnoreUnrecognizedVMOptions              = true                                      {product} {command line}
   size_t InitialHeapSize                          = 134217728                                 {product} {command line}
   size_t MarkStackSize                            = 4194304                                   {product} {ergonomic}
   size_t MaxHeapSize                              = 2147483648                                {product} {command line}
   size_t MaxNewSize                               = 1287651328                                {product} {ergonomic}
   size_t MinHeapDeltaBytes                        = 1048576                                   {product} {ergonomic}
   size_t MinHeapSize                              = 134217728                                 {product} {command line}
    uintx NonNMethodCodeHeapSize                   = 5826188                                {pd product} {ergonomic}
    uintx NonProfiledCodeHeapSize                  = 265522362                              {pd product} {ergonomic}
     bool OmitStackTraceInFastThrow                = false                                     {product} {command line}
    uintx ProfiledCodeHeapSize                     = 265522362                              {pd product} {ergonomic}
    uintx ReservedCodeCacheSize                    = 536870912                              {pd product} {command line}
     bool SegmentedCodeCache                       = true                                      {product} {ergonomic}
   size_t SoftMaxHeapSize                          = 2147483648                             {manageable} {ergonomic}
     intx SoftRefLRUPolicyMSPerMB                  = 50                                        {product} {command line}
   double SweeperThreshold                         = 0.234375                                  {product} {ergonomic}
     bool UseCompressedClassPointers               = true                           {product lp64_product} {ergonomic}
     bool UseCompressedOops                        = true                           {product lp64_product} {ergonomic}
     bool UseG1GC                                  = true                                      {product} {command line}
     bool UseLargePagesIndividualAllocation        = false                                  {pd product} {ergonomic}

Logging:
Log output configuration:
 #0: stdout all=warning uptime,level,tags
 #1: stderr all=off uptime,level,tags

Environment Variables:
PATH=C:\Program Files (x86)\Common Files\Oracle\Java\javapath;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files\Docker\Docker\resources\bin;C:\Program Files\Git\cmd;%NVM_HOME%;%NVM_SYMLINK%;[USER_DIR]\AppData\Local\Programs\Python\Python311\Scripts\;[USER_DIR]\AppData\Local\Programs\Python\Python311\;[USER_DIR]\AppData\Local\Microsoft\WindowsApps;[USER_DIR]\AppData\Local\GitHubDesktop\bin;C:\Program Files\JetBrains\WebStorm 2022.3.3\bin;;D:\Ron\GitHub\NVM;C:\Program Files\nodejs
USERNAME=Ron
OS=Windows_NT
PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 158 Stepping 10, GenuineIntel
TMP=[USER_DIR]\AppData\Local\Temp
TEMP=[USER_DIR]\AppData\Local\Temp



---------------  S Y S T E M  ---------------

OS:
 Windows 10 , 64 bit Build 19041 (10.0.19041.2546)
OS uptime: 1 days 2:38 hours
Hyper-V role detected

CPU: total 6 (initial active 6) (6 cores per cpu, 1 threads per core) family 6 model 158 stepping 10 microcode 0xb4, cx8, cmov, fxsr, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, bmi1, bmi2, adx, fma, vzeroupper, clflush, clflushopt, hv

Memory: 4k page, system-wide physical 16326M (3391M free)
TotalPageFile size 22429M (AvailPageFile size 3268M)
current process WorkingSet (physical memory assigned to process): 2543M, peak: 2579M
current process commit charge ("private bytes"): 2728M, peak: 2734M

vm_info: OpenJDK 64-Bit Server VM (17.0.6+1-b653.34) for windows-amd64 JRE (17.0.6+1-b653.34), built on 2023-02-24 by "builduser" with MS VC++ 16.10 / 16.11 (VS2019)

END.

From sspitsyn at openjdk.org  Fri Mar 24 00:19:32 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 24 Mar 2023 00:19:32 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v5]
In-Reply-To: <qVfNBfPP6pizIr16-aXD851jbQ8ZNOV7BvH_Yt-jrbo=.d22c7807-c952-4337-ae69-60a8070ad852@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <27JLa60WeywSMcJj-6KfaQD8RBnwBbAvcc0gecc-3h4=.a2a25b70-9e90-4551-af90-35aed3d57b59@github.com>
 <qVfNBfPP6pizIr16-aXD851jbQ8ZNOV7BvH_Yt-jrbo=.d22c7807-c952-4337-ae69-60a8070ad852@github.com>
Message-ID: <zdheJpqe6UvleE3K8wf5-DIaE9OVa-KfAnQDMbKw8T4=.59194b6d-4a9b-48a3-a485-02b2a17ab96e@github.com>

On Thu, 23 Mar 2023 17:49:31 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address review comment: remove unneeded function
>
> src/hotspot/share/prims/jvmtiThreadState.hpp line 101:
> 
>> 99:   static void set_VTMS_notify_jvmti_events(bool val) { _VTMS_notify_jvmti_events = val; }
>> 100: 
>> 101:   static void set_VTMS_transition_count(bool val)    { _VTMS_transition_count = val; }
> 
> Why set the count if it is never going to be used?

The counter `_VTMS_transition_count` is directly used by the `jvmtiVTMSTransitionDisabler`.

> test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest.java line 38:
> 
>> 36:  */
>> 37: 
>> 38: //import compiler.whitebox.CompilerWhiteBoxTest;
> 
> Remove

Thanks. Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1146994030
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1146994886

From sspitsyn at openjdk.org  Fri Mar 24 00:26:33 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 24 Mar 2023 00:26:33 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v5]
In-Reply-To: <qVfNBfPP6pizIr16-aXD851jbQ8ZNOV7BvH_Yt-jrbo=.d22c7807-c952-4337-ae69-60a8070ad852@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <27JLa60WeywSMcJj-6KfaQD8RBnwBbAvcc0gecc-3h4=.a2a25b70-9e90-4551-af90-35aed3d57b59@github.com>
 <qVfNBfPP6pizIr16-aXD851jbQ8ZNOV7BvH_Yt-jrbo=.d22c7807-c952-4337-ae69-60a8070ad852@github.com>
Message-ID: <0J5IbRtwgK7aOiXWfWBSVLo0RniWf6rRfvqmqA59j5A=.a7cf4ca2-a750-4281-9c78-285ca58e21da@github.com>

On Thu, 23 Mar 2023 18:02:29 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address review comment: remove unneeded function
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest.java line 68:
> 
>> 66:             if (n <= 0) {
>> 67:                 n = 1000;
>> 68:                 ToggleNotifyJvmtiTest.sleep(1);
> 
> It looks like you do this short sleep 1 out of every 1,000,000 iterations. Can you explain why?

It is for yielding. Do you think we need this with a bigger frequency?

> test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest.java line 72:
> 
>> 70:             if (i > n) {
>> 71:                 i = 0;
>> 72:                 n = n - 1;
> 
> n--

This code was copied originally from the vmTestbase to SuspendThread* tests and some other tests.
I can do all suggested simplifications but not sure if it is really necessary.
It does not matter what exactly the method does because it just simulates some thread activity.
Would it better to keep copy/pasted methods the same?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1146998399
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1146997072

From sspitsyn at openjdk.org  Fri Mar 24 00:43:34 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 24 Mar 2023 00:43:34 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v5]
In-Reply-To: <qVfNBfPP6pizIr16-aXD851jbQ8ZNOV7BvH_Yt-jrbo=.d22c7807-c952-4337-ae69-60a8070ad852@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <27JLa60WeywSMcJj-6KfaQD8RBnwBbAvcc0gecc-3h4=.a2a25b70-9e90-4551-af90-35aed3d57b59@github.com>
 <qVfNBfPP6pizIr16-aXD851jbQ8ZNOV7BvH_Yt-jrbo=.d22c7807-c952-4337-ae69-60a8070ad852@github.com>
Message-ID: <ROmojp6BetYwleUNEhEvlW-CLd2JFY-1hRRqlrsFix4=.9f4e6bb5-b0a9-4b2b-a042-e8eb713f71ad@github.com>

On Thu, 23 Mar 2023 18:07:23 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address review comment: remove unneeded function
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest.java line 161:
> 
>> 159:             vm.loadAgentLibrary(AGENT_LIB, arg);
>> 160:         } else {
>> 161:             System.loadLibrary(AGENT_LIB);
> 
> Why is this needed? Isn't the library already loaded due to it being specified by `-agentlib`?

Good question. We almost always do it in the JVMTI tests including `serviceability/jvmti/vthread` and `vmTestbase/nsk/jvmti` tests. Examples are 22 `serviceability/jvmti/vthread` tests.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1147009306

From sspitsyn at openjdk.org  Fri Mar 24 01:00:33 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 24 Mar 2023 01:00:33 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v5]
In-Reply-To: <qVfNBfPP6pizIr16-aXD851jbQ8ZNOV7BvH_Yt-jrbo=.d22c7807-c952-4337-ae69-60a8070ad852@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <27JLa60WeywSMcJj-6KfaQD8RBnwBbAvcc0gecc-3h4=.a2a25b70-9e90-4551-af90-35aed3d57b59@github.com>
 <qVfNBfPP6pizIr16-aXD851jbQ8ZNOV7BvH_Yt-jrbo=.d22c7807-c952-4337-ae69-60a8070ad852@github.com>
Message-ID: <5KI1mSSGb__Xsp4mKAlOmEYu2Sq7QpeNWat3G1_cYjM=.42488df5-28dd-4e84-9c89-83a045642326@github.com>

On Thu, 23 Mar 2023 18:08:47 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address review comment: remove unneeded function
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest.java line 148:
> 
>> 146: 
>> 147:     static private void setVirtualThreadsNotifyJvmtiMode(int iter, boolean enable) {
>> 148:         sleep(5);
> 
> Why is this needed?

It is needed to balance enabling/disabling notifyJvmti mode with the ThreadStart/VirtualThreadStart events.
Otherwise, many mode switches can be observed without any events which is not interesting.
We need to allow virtual threads to execute a little bit after a mode switch.

> test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest.java line 171:
> 
>> 169:         sleep(20);
>> 170: 
>> 171:         for (int iter = 0; VirtualThreadStartedCount() < VTHREADS_CNT; iter++) {
> 
> The test seems to exit once all the threads are started. I would think you would want it to run for a while after all the threads are started.

I'm not sure if it is really needed. 60 virtual threads are started.
Some of them are executed long enough before shutdown.
We can just increase the number of threads if necessary.

> test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/libToggleNotifyJvmtiTest.cpp line 32:
> 
>> 30: 
>> 31: static jvmtiEnv *jvmti;
>> 32: static int vthread_started_cnt = 0;
> 
> Needs to be volatile?

Thanks. We use a RawMonitor for sync. But anyway I made it volatile now.

> test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/libToggleNotifyJvmtiTest.cpp line 34:
> 
>> 32: static int vthread_started_cnt = 0;
>> 33: static jrawMonitorID agent_lock = NULL;
>> 34: static bool can_support_vt_enabled = false;
> 
> This variable doesn't seem to be needed. You set it `true` later on, but never reference it.

Good catch. Removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1147011556
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1147013785
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1147014957
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1147016373

From fgao at openjdk.org  Fri Mar 24 01:37:38 2023
From: fgao at openjdk.org (Fei Gao)
Date: Fri, 24 Mar 2023 01:37:38 GMT
Subject: RFR: 8304301: Remove the global option SuperWordMaxVectorSize
In-Reply-To: <x_FnktZAXmUd_uw0x9246aHueRxxt9AlXabM5TIwO90=.35996788-e648-4a61-848f-9183bde7936d@github.com>
References: <2XQwCCx_ficJ1bn2WX0Ud9m-QmuGkkZAH8N6yLugXqQ=.90a136da-db9a-49b4-a4c4-d6c644cf7d5a@github.com>
 <x_FnktZAXmUd_uw0x9246aHueRxxt9AlXabM5TIwO90=.35996788-e648-4a61-848f-9183bde7936d@github.com>
Message-ID: <9Eh4jYDkNog_R5GfwdhJL1X9OvST8q6y8abCnXgtVR4=.d838c9e1-159a-42ef-b395-032ec2ccc911@github.com>

On Tue, 21 Mar 2023 04:16:26 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> https://github.com/openjdk/jdk/pull/8877 introduced the global option `SuperWordMaxVectorSize` as a temporary solution to fix the performance regression on some x86 machines.
>> 
>> Currently, `SuperWordMaxVectorSize` behaves differently between x86 and other platforms [1]. For example, if the current machine only supports `MaxVectorSize <= 32`, but we set `SuperWordMaxVectorSize = 64`, then `SuperWordMaxVectorSize` will be kept at 64 on other platforms while x86 machine would change `SuperWordMaxVectorSize` to `MaxVectorSize`. Other platforms except x86 miss similar implementations like [2].
>> 
>> Also, `SuperWordMaxVectorSize` limits the max vector size of auto-vectorization as `64`, which is fine for current aarch64 hardware, but SVE architecture supports larger than 512 bits.
>> 
>> The patch is to drop the global option and use an architecture-dependent interface to consult the max vector size for auto-vectorization, fixing the performance issue on x86 and reducing side effects for other platforms. After the patch, auto-vectorization is still limited to 32-byte vectors by default on Cascade Lake and users can override this by either setting
>> `-XX:UseAVX=3` or `-XX:MaxVectorSize=64` on JVM command line.
>> 
>> So my question is:
>> 
>> Before the patch, we could have a smaller max vector size for auto-vectorization than `MaxVectorSize` on x86. For example, users could have `MaxVectorSize=64` and `SuperWordMaxVectorSize=32`. But after the change, if we set
>> `-XX:MaxVectorSize=64` explicitly, then the max vector size for auto-vectorization would be `MaxVectorSize`, i.e. 64 bytes, which I believe is more reasonable. @sviswa7 @jatin-bhateja, are you happy about the change?
>> 
>> [1] https://github.com/openjdk/jdk/pull/12350#discussion_r1126106213
>> [2] https://github.com/openjdk/jdk/blob/33bec207103acd520eb99afb093cfafa44aecfda/src/hotspot/cpu/x86/vm_version_x86.cpp#L1314-L1333
>
> @fg1417  SuperWordMaxVectorSize defines the maximum vector size generated by the auto vectorization.
>                  MaxVectorSize defines the  vector width supported by the underlying platform. 
>                  For CascadeLake we are setting SuperWordMaxVectorSize=32 and MaxVectorSize=64 by default.
>                  This allows the usage of larger 64 byte width vector instructions in places like Java Vector API and intrinsics. 
>                  We would like to keep this behavior for x86.

Thanks for all your review and testing, @sviswa7 @vnkozlov @TobiHartmann.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13112#issuecomment-1482130995

From sspitsyn at openjdk.org  Fri Mar 24 01:51:43 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 24 Mar 2023 01:51:43 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v5]
In-Reply-To: <qVfNBfPP6pizIr16-aXD851jbQ8ZNOV7BvH_Yt-jrbo=.d22c7807-c952-4337-ae69-60a8070ad852@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <27JLa60WeywSMcJj-6KfaQD8RBnwBbAvcc0gecc-3h4=.a2a25b70-9e90-4551-af90-35aed3d57b59@github.com>
 <qVfNBfPP6pizIr16-aXD851jbQ8ZNOV7BvH_Yt-jrbo=.d22c7807-c952-4337-ae69-60a8070ad852@github.com>
Message-ID: <5QPEmF5uNmAKzzpmEAeuis02ozKFfSaothwqLe2iSF4=.c4d56cf5-83a5-45d8-b616-25c0a965726b@github.com>

On Thu, 23 Mar 2023 17:59:52 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address review comment: remove unneeded function
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest.java line 74:
> 
>> 72:                 n = n - 1;
>> 73:             }
>> 74:             i = i + 1;
> 
> i++

See above.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1147039026

From sspitsyn at openjdk.org  Fri Mar 24 01:55:37 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 24 Mar 2023 01:55:37 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v5]
In-Reply-To: <cidKu3X9LJvpVXA03joOke4E8_k5w9QYrUWkcIZg_ec=.ded16bd1-9d08-49af-86b5-a6758f7c4b47@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <27JLa60WeywSMcJj-6KfaQD8RBnwBbAvcc0gecc-3h4=.a2a25b70-9e90-4551-af90-35aed3d57b59@github.com>
 <cidKu3X9LJvpVXA03joOke4E8_k5w9QYrUWkcIZg_ec=.ded16bd1-9d08-49af-86b5-a6758f7c4b47@github.com>
Message-ID: <_2AVe6wwMuSFdUmNRIf1JgXmJ6HFNJzBpkHT2HUqGiE=.51782910-04c7-46ad-b7be-331aa411f52b@github.com>

On Thu, 23 Mar 2023 22:27:07 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> There are few comments in the code.
> Also, I think it would be nice to have a high-level comment about sync of VTMTDisable and lately attached agent.
> What is set and why VMOp is needed.
> BTW why VMOp and not handshake is used?

Good suggestion, thanks!
I kept thinking where to add these types of comments.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13133#issuecomment-1482140356

From sspitsyn at openjdk.org  Fri Mar 24 02:03:33 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 24 Mar 2023 02:03:33 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v5]
In-Reply-To: <cidKu3X9LJvpVXA03joOke4E8_k5w9QYrUWkcIZg_ec=.ded16bd1-9d08-49af-86b5-a6758f7c4b47@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <27JLa60WeywSMcJj-6KfaQD8RBnwBbAvcc0gecc-3h4=.a2a25b70-9e90-4551-af90-35aed3d57b59@github.com>
 <cidKu3X9LJvpVXA03joOke4E8_k5w9QYrUWkcIZg_ec=.ded16bd1-9d08-49af-86b5-a6758f7c4b47@github.com>
Message-ID: <KZBKVM6-D0Rx1vmgEQPBAfr08_YJlvELF8kNkurYKBI=.654850bf-514f-4c82-ba47-0f9cc8712ed7@github.com>

On Thu, 23 Mar 2023 22:11:58 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address review comment: remove unneeded function
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1581:
> 
>> 1579:     return false;
>> 1580:   }
>> 1581:   if (JvmtiVTMSTransitionDisabler::VTMS_notify_jvmti_events()) {
> 
> shouldn't be
>  if (!JvmtiVTMSTransitionDisabler::VTMS_notify_jvmti_events()) {
> here?

This is nice catch, thanks!

> test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest.java line 82:
> 
>> 80:         try {
>> 81:             while (!threadReady) {
>> 82:                 sleep(1);
> 
> Use ToggleNotifyJvmtiTest.sleep(1);?

Good idea, thanks. Simplified.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1147044376
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1147043984

From david.holmes at oracle.com  Fri Mar 24 02:31:27 2023
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 24 Mar 2023 12:31:27 +1000
Subject: crash logs without stack trace
In-Reply-To: <14C16303-1377-4968-93C8-B5347ACF806F@jetbrains.com>
References: <14C16303-1377-4968-93C8-B5347ACF806F@jetbrains.com>
Message-ID: <f0199df0-ff30-eefb-218a-a7f64007914e@oracle.com>

On 24/03/2023 9:18 am, Vitaly Provodin wrote:
> Hi all,
> 
> 
> We (at JetBrains) became getting crash reports whose logs have no stack trace info except for Problematic frame. But in those reports there are details accessed via registries about some objects.
> See the attached example of such crash logs.
> It looks like such reports appeared not so long time ago.
> 
> Actually we are stuck on reading such crash logs in order to find out crash causes and would appreciate for any clues related to these issues.
> 
> Could somebody please shad some light on this?

Not much ...

The crashing thread is the AWT-event-thread
The crashing frame is compiled Java code
The stack appears to not be walkable - hence the lack of stack trace.
The VMThread is trying to bring the VM to a safepoint (state is 
synchronizing).

David

> Thanks in advance
> Vitaly
> 

From dholmes at openjdk.org  Fri Mar 24 02:51:51 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 24 Mar 2023 02:51:51 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <S3HAUfb2-rymMhcE0b5Uwycc6LpZHCnHRVHXL0141IU=.20c872ab-a4c1-4d40-b33b-a83f9f388cd1@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
 <S3HAUfb2-rymMhcE0b5Uwycc6LpZHCnHRVHXL0141IU=.20c872ab-a4c1-4d40-b33b-a83f9f388cd1@github.com>
Message-ID: <yoOQnZWXsuiKuJ3RNms0XMGS4m5kDh9aiUyQ0hht8rE=.81a7b56a-23eb-454d-ad0c-e62cc7614035@github.com>

On Thu, 23 Mar 2023 16:32:57 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Is anybody familiar with the academic literature on this topic? I am sure I am not the first person which has come up with this form of locking. Maybe we could use a name that refers to some academic paper?

Well not to diminish this in any way but all you are doing is moving the lock-record from the stack frame (indexed from the markword) to a heap allocated side-table (indexed via the thread itself). The "fast-locking" is still the bit that use the markword to indicate the locked state, and that hasn't changed. Encoding lock state in an object header has  a number of names in the literature, depending on whose scheme it was: IBM had ThinLocks; the Sun Research VM (EVM) had meta-locks; etc. Hotspot doesn't really have a name for its variation. And as I said you aren't changing that aspect but modifying what data structure is used to access the lock-records.

So the property Jesper was looking for, IMO, may be something like `UseHeapLockRecords` - though that can unfortunately be parsed as using records for the HeapLock. :(

I think it was mentioned somewhere above that in the Java Object Monitor prototyping work we avoided using these kinds of boolean flags by defining a single "policy" flag that could take on different values for different implementation schemes. These are simply numbered, so for example:
- policy 0: use existing/legacy locking with stack-based lock records
- policy 1: use heavyweight locks (ie UseHeavyMonitors)
- policy 2 use the new approach with heap-allocated lock-records

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1482176363

From sspitsyn at openjdk.org  Fri Mar 24 03:01:41 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 24 Mar 2023 03:01:41 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v5]
In-Reply-To: <cidKu3X9LJvpVXA03joOke4E8_k5w9QYrUWkcIZg_ec=.ded16bd1-9d08-49af-86b5-a6758f7c4b47@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <27JLa60WeywSMcJj-6KfaQD8RBnwBbAvcc0gecc-3h4=.a2a25b70-9e90-4551-af90-35aed3d57b59@github.com>
 <cidKu3X9LJvpVXA03joOke4E8_k5w9QYrUWkcIZg_ec=.ded16bd1-9d08-49af-86b5-a6758f7c4b47@github.com>
Message-ID: <ZCfsYpNQeqJzlakZFMmWL0HtiCpsIZ49G54S_VMNcaY=.95cb5a3f-2048-4905-aa99-46cbd1ae44be@github.com>

On Thu, 23 Mar 2023 22:24:45 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address review comment: remove unneeded function
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/libToggleNotifyJvmtiTest.cpp line 77:
> 
>> 75: 
>> 76:     err = jvmti->AddCapabilities(&caps);
>> 77:     if (err != JVMTI_ERROR_NONE) {
> 
> Can you use check_jvmti_status to ensure that result is not error?

No, the `check_jvmti_status` needs a `JNIEnv*` which is not available in the context of `Agent_OnLoad`.

> test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/libToggleNotifyJvmtiTest.cpp line 82:
> 
>> 80:     }
>> 81:     err = jvmti->SetEventNotificationMode(JVMTI_ENABLE, JVMTI_EVENT_VIRTUAL_THREAD_START, NULL);
>> 82:     if (err != JVMTI_ERROR_NONE) {
> 
> 2nd Can you use check_jvmti_status to ensure that result is not error?

Please, see above.

> test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/libToggleNotifyJvmtiTest.cpp line 89:
> 
>> 87:   LOG("Agent init: can_support_virtual_threads capability: %d\n",  caps.can_support_virtual_threads);
>> 88: 
>> 89:   err = jvmti->SetEventCallbacks(&callbacks, (jint)sizeof(callbacks));
> 
> 3rd Can you use check_jvmti_status to ensure that result is not error?

Please, see above.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1147069349
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1147069479
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1147069520

From sspitsyn at openjdk.org  Fri Mar 24 03:14:32 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 24 Mar 2023 03:14:32 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v5]
In-Reply-To: <cidKu3X9LJvpVXA03joOke4E8_k5w9QYrUWkcIZg_ec=.ded16bd1-9d08-49af-86b5-a6758f7c4b47@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <27JLa60WeywSMcJj-6KfaQD8RBnwBbAvcc0gecc-3h4=.a2a25b70-9e90-4551-af90-35aed3d57b59@github.com>
 <cidKu3X9LJvpVXA03joOke4E8_k5w9QYrUWkcIZg_ec=.ded16bd1-9d08-49af-86b5-a6758f7c4b47@github.com>
Message-ID: <Uo6seKXrIlZS-_VDiPmAsqt682EPHOLBOEBvm4ZaWaU=.b578dcb4-d767-4783-93f4-b60cd12c5f08@github.com>

On Thu, 23 Mar 2023 22:18:51 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address review comment: remove unneeded function
>
> src/hotspot/share/prims/whitebox.cpp line 2537:
> 
>> 2535:   }
>> 2536: #endif
>> 2537:   return result;
> 
> The test never check results, so it might be better to generate fatal error and fail here/throw exception to catch bug earlier?

Thank you for the comment.
I think, the decision to throw exception has to be in the test.
Modified the test as below:

<<<        WB.setVirtualThreadsNotifyJvmtiMode(enable);
 ---
>>>        boolean status = WB.setVirtualThreadsNotifyJvmtiMode(enable);
>>>        if (!status) {
>>>            throw new RuntimeException("Java: failed to set VirtualThreadsNotifyJvmtiMode: " + enable);
>>>        }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1147075146

From dholmes at openjdk.org  Fri Mar 24 03:17:28 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 24 Mar 2023 03:17:28 GMT
Subject: RFR: 8304802: After JDK-8297639 the flag G1UsePreventiveGC needs
 to be added to the obsoletion table
In-Reply-To: <InH4JukIq7ToDARFz4yGGan43_mE6Vs0yyNBP9mPtok=.2b624755-d549-4e6e-b297-304480d401d9@github.com>
References: <InH4JukIq7ToDARFz4yGGan43_mE6Vs0yyNBP9mPtok=.2b624755-d549-4e6e-b297-304480d401d9@github.com>
Message-ID: <7M70MpWeareVKMTT4FaA01gfEOzoF-8tVagfIkMELdA=.8d752ec7-ab9e-4b22-abf1-1be2921e73db@github.com>

On Thu, 23 Mar 2023 10:38:04 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change that puts the `G1UsePreventiveGC` into the argument obsoletion table so that the appropriate warning is printed when starting the VM with that option. Functionality has already been removed, and CSR request approved with [JDK-8297639](https://bugs.openjdk.org/browse/JDK-8297639).
> 
> Testing: local compilation, manual testing that the obsoletion warning is printed on the command line.
> 
> Thanks,
>   Thomas

This set of bugs is very confusing, but I'm not seeing the CSR request you mentioned that allowed these flags to be deprecated, then obsoleted. ??

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13156#issuecomment-1482191898

From dholmes at openjdk.org  Fri Mar 24 04:09:30 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 24 Mar 2023 04:09:30 GMT
Subject: RFR: 8304802: After JDK-8297639 the flag G1UsePreventiveGC needs
 to be added to the obsoletion table
In-Reply-To: <InH4JukIq7ToDARFz4yGGan43_mE6Vs0yyNBP9mPtok=.2b624755-d549-4e6e-b297-304480d401d9@github.com>
References: <InH4JukIq7ToDARFz4yGGan43_mE6Vs0yyNBP9mPtok=.2b624755-d549-4e6e-b297-304480d401d9@github.com>
Message-ID: <5Qflm3FZw-cQIVrjBBMgsK_JdVgu8tdpGumSt1_kTXM=.62c8fda1-e0a4-4a64-9e6f-be8eb53dade5@github.com>

On Thu, 23 Mar 2023 10:38:04 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change that puts the `G1UsePreventiveGC` into the argument obsoletion table so that the appropriate warning is printed when starting the VM with that option. Functionality has already been removed, and CSR request approved with [JDK-8297639](https://bugs.openjdk.org/browse/JDK-8297639).
> 
> Testing: local compilation, manual testing that the obsoletion warning is printed on the command line.
> 
> Thanks,
>   Thomas

Ah never mind - it is a diagnostic flag so no CSR needed anyway.

Looks good. Thanks

src/hotspot/share/gc/g1/g1_globals.hpp line 116:

> 114:           range(1, max_intx)                                                \
> 115:                                                                             \
> 116:   product(uint, G1ConfidencePercent, 50,                                    \

Seems unrelated

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13156#pullrequestreview-1355971765
PR Review Comment: https://git.openjdk.org/jdk/pull/13156#discussion_r1147097118

From dholmes at openjdk.org  Fri Mar 24 04:58:31 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 24 Mar 2023 04:58:31 GMT
Subject: RFR: JDK-8304723: Statically allocate global mutexes [v5]
In-Reply-To: <eyn9KksfxgQZ_uwh4rMrnxAP5ksyZcs4iMrmWxc8fyM=.1cfb45cc-97d9-49a2-9ad5-f2023f3d9b4a@github.com>
References: <GnX35HIFItX1KV3Zsg5l-zwZVkhP_4Hq5o5ZhtiO57w=.94a86c58-3910-4b52-8c2f-3d6aaf713a06@github.com>
 <eyn9KksfxgQZ_uwh4rMrnxAP5ksyZcs4iMrmWxc8fyM=.1cfb45cc-97d9-49a2-9ad5-f2023f3d9b4a@github.com>
Message-ID: <BRCnWtIcRVn5ImM0DHq0-TJbY-RoshiQxvgJjjHuN14=.f364d06b-a0ce-472b-a9ea-8c79cd403ad0@github.com>

On Thu, 23 Mar 2023 15:27:58 GMT, Justin King <jcking at openjdk.org> wrote:

>> Switch to statically allocate storage for all of Hotspot's global mutexes and monitors. This avoids needing to allocate each one dynamically at startup. These also live for the lifetime of the program, so this reduces any potential memory fragmention in the C heap.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move alignas before static
>   
>   Signed-off-by: Justin King <jcking at google.com>

This version seems fine.

One query below.

Thanks.

src/hotspot/share/runtime/mutexLocker.cpp line 210:

> 208: // Specify relative ranked lock
> 209: #ifdef ASSERT
> 210: #define MUTEX_DEFL(name, type, held_lock, ...) MUTEX_DEF(name, type, (held_lock)->rank()-1, ##__VA_ARGS__)

Pre-existing but what does the 'L' suffix mean here? We now have _DEF _DEFN and _DEFL and I'm not clear what the N and L signify. ??

Nit while you are here `rank()-1` -> `rank() - 1`

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13143#pullrequestreview-1355999010
PR Review Comment: https://git.openjdk.org/jdk/pull/13143#discussion_r1147116770

From dholmes at openjdk.org  Fri Mar 24 05:07:28 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 24 Mar 2023 05:07:28 GMT
Subject: RFR: JDK-8304828: Lots of constant static data not declared static
 const in cpu/x86
In-Reply-To: <7KzH7QPu53lViaVf5yIBoJ7hxpvBIK9iZP-L5EVH8U4=.0935258a-29ba-43b5-a845-1201be6dface@github.com>
References: <7KzH7QPu53lViaVf5yIBoJ7hxpvBIK9iZP-L5EVH8U4=.0935258a-29ba-43b5-a845-1201be6dface@github.com>
Message-ID: <1pMR_xh7ZJB-e7vGSQpTgcsysW2hFpatJ67dY--FCyE=.c32c7dc3-5c06-45c3-a681-60681dc37baf@github.com>

On Thu, 23 Mar 2023 17:31:26 GMT, Justin King <jcking at openjdk.org> wrote:

> Simple refactor that updates declarations and definitions for data that is effectively static and constant to be `static` and/or `const`. Helps make sure we do not break the one definition rule and helps the compiler/linker to place the data in read-only sections of the executable.

Seems okay. I don;t know how disruptive this may be for backports.

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13163#pullrequestreview-1356005681

From kvn at openjdk.org  Fri Mar 24 05:17:36 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 24 Mar 2023 05:17:36 GMT
Subject: RFR: JDK-8304828: Lots of constant static data not declared static
 const in cpu/x86
In-Reply-To: <7KzH7QPu53lViaVf5yIBoJ7hxpvBIK9iZP-L5EVH8U4=.0935258a-29ba-43b5-a845-1201be6dface@github.com>
References: <7KzH7QPu53lViaVf5yIBoJ7hxpvBIK9iZP-L5EVH8U4=.0935258a-29ba-43b5-a845-1201be6dface@github.com>
Message-ID: <jtx150S4_ISXzdfhezK_UCXYVF1NF6lenLGyoy8pyYs=.973ccb52-c992-460f-9057-3e6b3ae681d9@github.com>

On Thu, 23 Mar 2023 17:31:26 GMT, Justin King <jcking at openjdk.org> wrote:

> Simple refactor that updates declarations and definitions for data that is effectively static and constant to be `static` and/or `const`. Helps make sure we do not break the one definition rule and helps the compiler/linker to place the data in read-only sections of the executable.

Changes looks good. But please restart GHA testing. Something went wrong there.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13163#pullrequestreview-1356012592

From dholmes at openjdk.org  Fri Mar 24 06:13:57 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 24 Mar 2023 06:13:57 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
Message-ID: <c-7smld8IgJ4LZVq6-hGlF78ZONKD8dNxP8GOSPgOGY=.376cfe51-d289-4e7c-8648-d306a87c034c@github.com>

On Thu, 16 Mar 2023 20:56:15 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>  - Set condition flags correctly after fast-lock call on aarch64

src/hotspot/share/interpreter/interpreterRuntime.cpp line 741:

> 739:     // This is a hack to get around the limitation of registers in x86_32. We really
> 740:     // send an oopDesc* instead of a BasicObjectLock*.
> 741:     Handle h_obj(current, oop((reinterpret_cast<oopDesc*>(elem))));

Wouldn't it be cleaner to retype elem as a void* and cast to the correct type.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1147156418

From dholmes at openjdk.org  Fri Mar 24 06:19:53 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 24 Mar 2023 06:19:53 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
Message-ID: <49yCA-Vx9caLf1KSVYnST3QsQ_kJZhny4KKt6kQnapQ=.66c7d6dd-a076-40d1-9dad-ebecf6805674@github.com>

On Thu, 16 Mar 2023 20:56:15 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>  - Set condition flags correctly after fast-lock call on aarch64

src/hotspot/share/oops/oop.cpp line 126:

> 124:   // Outside of a safepoint, the header could be changing (for example,
> 125:   // another thread could be inflating a lock on this object).
> 126:   if (ignore_mark_word || UseFastLocking) {

Not clear why UseFastLocking appears here instead of in the return expression - especially given the comment above.

src/hotspot/share/runtime/arguments.cpp line 1997:

> 1995:   }
> 1996:   if (UseHeavyMonitors) {
> 1997:     FLAG_SET_DEFAULT(UseFastLocking, false);

Probably should be an error if both are set on the command-line.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1147159067
PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1147159460

From dholmes at openjdk.org  Fri Mar 24 06:42:58 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 24 Mar 2023 06:42:58 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
Message-ID: <7E8dbbZfswhEgM9yghtrXzUklVrZSCX2N15lhm7nQ_Q=.3a4a029c-bc04-4d0b-a501-a67775c1591b@github.com>

On Thu, 16 Mar 2023 20:56:15 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>  - Set condition flags correctly after fast-lock call on aarch64

src/hotspot/share/runtime/synchronizer.cpp line 500:

> 498:             // Try to swing into 'fast-locked' state without inflating.
> 499:             markWord locked_header = header.set_fast_locked();
> 500:             markWord witness = obj()->cas_set_mark(locked_header, header);

Nit: really dislike the name witness - it is just the old header value.

src/hotspot/share/runtime/synchronizer.cpp line 516:

> 514:       // No room on the lock_stack so fall-through to inflate-enter.
> 515:     } else {
> 516:       markWord mark = obj->mark();

why is it `mark` here but `header` above?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1147173480
PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1147174724

From stuefe at openjdk.org  Fri Mar 24 06:47:20 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 24 Mar 2023 06:47:20 GMT
Subject: RFR: JDK-8304815: Use NMT for more precise hs_err location
 printing [v2]
In-Reply-To: <DPqsrXUm5sJjcxDGZW6QSvdpu83LBhwXreIJU7LXqjI=.dfe3de5e-919a-494d-a8dd-0622d1ee0c65@github.com>
References: <DPqsrXUm5sJjcxDGZW6QSvdpu83LBhwXreIJU7LXqjI=.dfe3de5e-919a-494d-a8dd-0622d1ee0c65@github.com>
Message-ID: <tNrRobA_ElV3CHZ4-YrqjRSESJTJLnvjy0u3GBBhzxw=.cd31949c-7049-4584-89ea-5afac07e48e6@github.com>

> (This is a byproduct of work on the arm port for https://github.com/openjdk/jdk/pull/10907. I needed better debugging information in the hs-err file and in gdb.)
> 
> Back in 2022 @zhengyu123 had the very nice idea of using NMT mapping info for smartening up pp in gdb: [JDK-8280289](https://bugs.openjdk.org/browse/JDK-8280289).
> 
> The same idea can be applied to hs_err file location printing. NMT has information about all its mappings and can tell us where it thinks a given unknown pointer points into.
> 
> This could be even more useful if the "find malloc block" part of that functionality would be smarter. As it is now, it only works if the pointer in question points to the start of a user-allocated area. Would be nice if the code could (carefully) search for the next valid-looking malloc header instead.
> 
> --------------
> 
> This patch does this: we introduce a new API, MemTracker::print_containing_region(void*), that tries to make sense of a given unknown pointer.
> 
> It will search its mmap regions and print those if found. For malloc'ed pointers, it will carefully sniff out the immediate surroundings of the block, trying to find what looks like a valid malloc header. It uses SafeFetch to not trip over unmapped or protected pages. Note that, of course, we may get false recognition positives if it finds something that looks like a valid header. But even that could be useful (e.g. a remnant dead header may indicate we access memory after free).
> 
> Looks like this (its arm, so 32-bit pointers):
> 
> 
> Register to memory mapping:
> 
> ->  r0  = 0x728a6ae0 into life malloced block starting at 0x728a6ae0, size 104, tag mtSynchronizer
> ->  r1  = 0x75b02010 into life malloced block starting at 0x75b02010, size 184, tag mtObjectMonitor
> ->  r2  = 0x728a6ae0 into life malloced block starting at 0x728a6ae0, size 104, tag mtSynchronizer
>     r3  = 0x0 is nullptr
> ->  r4  = 0x728a6ae0 into life malloced block starting at 0x728a6ae0, size 104, tag mtSynchronizer
>     r5  = 0xb6d3bbc8: <offset 0x018f6bc8> in /shared/projects/openjdk/jdk-jdk/output-fastdebug-arm/images/jdk/lib/server/libjvm.so at 0xb5445000
>     r6  = 0xffffffff is an unknown value
>     r7  = 0x0 is nullptr
>     r8  = 0x0000000a is an unknown value
>     r9  = 0x728a4308 is a thread
>     r10 = 0x0000000b is an unknown value
> ->  fp  = 0x753fe8cc in mmap'd memory region [0x75380000 - 0x75400000] by Thread Stack
>     r12 = 0x0 is nullptr
> ->  sp  = 0x753fe8b0 in mmap'd memory region [0x75380000 - 0x75400000] by Thread Stack
>     lr  = 0xb69bc1d0: <offset 0x015771d0> in /shared/projects/openjdk/jdk-jdk/output-fastdebug-arm/images/jdk/lib/server/libjvm.so at 0xb5445000
>     pc  = 0xb69c8670: <offset 0x01583670> in /shared/projects/openjdk/jdk-jdk/output-fastdebug-arm/images/jdk/lib/server/libjvm.so at 0xb5445000
> 
> 
> 
> The small caveat here is that NMT reporting needs ThreadCritical, and thus using it for location printing may block error reporting if it crashed inside a ThreadCritical section. We face the same issue today when printing the NMT report as part of the hs-err file. 
> 
> I think the usefulness of these printouts justify this risk. However I opened https://bugs.openjdk.org/browse/JDK-8304824 to investigate a better locking strategy for NMT.

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  life->live

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13162/files
  - new: https://git.openjdk.org/jdk/pull/13162/files/670e77f6..11b2cc83

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13162&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13162&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13162.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13162/head:pull/13162

PR: https://git.openjdk.org/jdk/pull/13162

From stuefe at openjdk.org  Fri Mar 24 06:47:22 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 24 Mar 2023 06:47:22 GMT
Subject: RFR: JDK-8304815: Use NMT for more precise hs_err location
 printing
In-Reply-To: <CrodIMIrO9cjrv91xYv42Z0MyKMS70ceMr5R1AlJgrs=.e42f92e5-0663-4f29-a399-b3cb47b8b1a8@github.com>
References: <DPqsrXUm5sJjcxDGZW6QSvdpu83LBhwXreIJU7LXqjI=.dfe3de5e-919a-494d-a8dd-0622d1ee0c65@github.com>
 <CrodIMIrO9cjrv91xYv42Z0MyKMS70ceMr5R1AlJgrs=.e42f92e5-0663-4f29-a399-b3cb47b8b1a8@github.com>
Message-ID: <6OeoRsysugv1tNrgg56yChMRH7LDF9lmLyc766UISZY=.49fde0ba-d6e0-4f9d-91b8-6a93a04c9f58@github.com>

On Thu, 23 Mar 2023 18:33:29 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Should that output be "live malloced block" instead of "life malloced block"?

You are right. Not sure why I always get this one wrong.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13162#issuecomment-1482328972

From dholmes at openjdk.org  Fri Mar 24 06:54:52 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 24 Mar 2023 06:54:52 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
Message-ID: <_zupTz0CFtTIcMh1qjWTXj2ro3DQIeT3iWDuKLbI2Yg=.494a5726-857a-4ac4-83d4-c8d0112b514d@github.com>

On Thu, 16 Mar 2023 20:56:15 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>  - Set condition flags correctly after fast-lock call on aarch64

src/hotspot/share/runtime/synchronizer.cpp line 761:

> 759:   markWord mark = obj->mark();
> 760:   if ((mark.is_fast_locked() && current->lock_stack().contains(obj())) ||
> 761:       (mark.has_locker() && current->is_lock_owned((address)mark.locker()))) {

I'd prefer to see this conditionalized on UseFastlocking so that it is more obvious where the fast-locking changes are. Ditto for other places.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1147182098

From dholmes at openjdk.org  Fri Mar 24 06:58:53 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 24 Mar 2023 06:58:53 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
Message-ID: <z1u-Lf3nAHoI5NyO71NmJDC49m10j3galYAyQg-2ru4=.503c3430-7965-4f53-b4f4-e7677dfe333f@github.com>

On Thu, 16 Mar 2023 20:56:15 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>  - Set condition flags correctly after fast-lock call on aarch64

src/hotspot/share/runtime/threads.cpp line 1422:

> 1420: }
> 1421: 
> 1422: JavaThread* Threads::owning_thread_from_object(ThreadsList * t_list, oop obj) {

Is this thread-safe?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1147184493

From dholmes at openjdk.org  Fri Mar 24 07:03:55 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 24 Mar 2023 07:03:55 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
Message-ID: <nBr83R-0Y5yOf78x8AwzT82prp5oiZwR_cDMmo4Mi24=.255abec1-9cfa-472c-9499-b1170abb067b@github.com>

On Thu, 16 Mar 2023 20:56:15 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>  - Set condition flags correctly after fast-lock call on aarch64

> The lock-stack is grown when needed.

Could you update the description of the PR with the latest approach please - others are unlikely to read all the comments to realize this has changed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1482342876

From stuefe at openjdk.org  Fri Mar 24 07:08:24 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 24 Mar 2023 07:08:24 GMT
Subject: RFR: JDK-8304815: Use NMT for more precise hs_err location
 printing [v2]
In-Reply-To: <tNrRobA_ElV3CHZ4-YrqjRSESJTJLnvjy0u3GBBhzxw=.cd31949c-7049-4584-89ea-5afac07e48e6@github.com>
References: <DPqsrXUm5sJjcxDGZW6QSvdpu83LBhwXreIJU7LXqjI=.dfe3de5e-919a-494d-a8dd-0622d1ee0c65@github.com>
 <tNrRobA_ElV3CHZ4-YrqjRSESJTJLnvjy0u3GBBhzxw=.cd31949c-7049-4584-89ea-5afac07e48e6@github.com>
Message-ID: <WNeoG1gVZMTCVGVbq1x3eYf1EEDUB4oonLrndRBo4mA=.8108267b-7199-4c15-89cb-0625882c2f8c@github.com>

On Fri, 24 Mar 2023 06:47:20 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> (This is a byproduct of work on the arm port for https://github.com/openjdk/jdk/pull/10907. I needed better debugging information in the hs-err file and in gdb.)
>> 
>> Back in 2022 @zhengyu123 had the very nice idea of using NMT mapping info for smartening up pp in gdb: [JDK-8280289](https://bugs.openjdk.org/browse/JDK-8280289).
>> 
>> The same idea can be applied to hs_err file location printing. NMT has information about all its mappings and can tell us where it thinks a given unknown pointer points into.
>> 
>> This could be even more useful if the "find malloc block" part of that functionality would be smarter. As it is now, it only works if the pointer in question points to the start of a user-allocated area. Would be nice if the code could (carefully) search for the next valid-looking malloc header instead.
>> 
>> --------------
>> 
>> This patch does this: we introduce a new API, MemTracker::print_containing_region(void*), that tries to make sense of a given unknown pointer.
>> 
>> It will search its mmap regions and print those if found. For malloc'ed pointers, it will carefully sniff out the immediate surroundings of the block, trying to find what looks like a valid malloc header. It uses SafeFetch to not trip over unmapped or protected pages. Note that, of course, we may get false recognition positives if it finds something that looks like a valid header. But even that could be useful (e.g. a remnant dead header may indicate we access memory after free).
>> 
>> Looks like this (its arm, so 32-bit pointers):
>> 
>> 
>> Register to memory mapping:
>> 
>> ->  r0  = 0x728a6ae0 into life malloced block starting at 0x728a6ae0, size 104, tag mtSynchronizer
>> ->  r1  = 0x75b02010 into life malloced block starting at 0x75b02010, size 184, tag mtObjectMonitor
>> ->  r2  = 0x728a6ae0 into life malloced block starting at 0x728a6ae0, size 104, tag mtSynchronizer
>>     r3  = 0x0 is nullptr
>> ->  r4  = 0x728a6ae0 into life malloced block starting at 0x728a6ae0, size 104, tag mtSynchronizer
>>     r5  = 0xb6d3bbc8: <offset 0x018f6bc8> in /shared/projects/openjdk/jdk-jdk/output-fastdebug-arm/images/jdk/lib/server/libjvm.so at 0xb5445000
>>     r6  = 0xffffffff is an unknown value
>>     r7  = 0x0 is nullptr
>>     r8  = 0x0000000a is an unknown value
>>     r9  = 0x728a4308 is a thread
>>     r10 = 0x0000000b is an unknown value
>> ->  fp  = 0x753fe8cc in mmap'd memory region [0x75380000 - 0x75400000] by Thread Stack
>>     r12 = 0x0 is nullptr
>> ->  sp  = 0x753fe8b0 in mmap'd memory region [0x75380000 - 0x75400000] by Thread Stack
>>     lr  = 0xb69bc1d0: <offset 0x015771d0> in /shared/projects/openjdk/jdk-jdk/output-fastdebug-arm/images/jdk/lib/server/libjvm.so at 0xb5445000
>>     pc  = 0xb69c8670: <offset 0x01583670> in /shared/projects/openjdk/jdk-jdk/output-fastdebug-arm/images/jdk/lib/server/libjvm.so at 0xb5445000
>> 
>> 
>> 
>> The small caveat here is that NMT reporting needs ThreadCritical, and thus using it for location printing may block error reporting if it crashed inside a ThreadCritical section. We face the same issue today when printing the NMT report as part of the hs-err file. 
>> 
>> I think the usefulness of these printouts justify this risk. However I opened https://bugs.openjdk.org/browse/JDK-8304824 to investigate a better locking strategy for NMT.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   life->live

Pinging @jdksjolen.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13162#issuecomment-1482345970

From stuefe at openjdk.org  Fri Mar 24 07:08:21 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 24 Mar 2023 07:08:21 GMT
Subject: RFR: JDK-8304815: Use NMT for more precise hs_err location
 printing [v3]
In-Reply-To: <DPqsrXUm5sJjcxDGZW6QSvdpu83LBhwXreIJU7LXqjI=.dfe3de5e-919a-494d-a8dd-0622d1ee0c65@github.com>
References: <DPqsrXUm5sJjcxDGZW6QSvdpu83LBhwXreIJU7LXqjI=.dfe3de5e-919a-494d-a8dd-0622d1ee0c65@github.com>
Message-ID: <v1SrG0I05AA-oZWpoxIfSrYUousmqDtBpgJbZdth-as=.83d2e22c-0527-4a99-99b8-a7187a31d5bd@github.com>

> (This is a byproduct of work on the arm port for https://github.com/openjdk/jdk/pull/10907. I needed better debugging information in the hs-err file and in gdb.)
> 
> Back in 2022 @zhengyu123 had the very nice idea of using NMT mapping info for smartening up pp in gdb: [JDK-8280289](https://bugs.openjdk.org/browse/JDK-8280289).
> 
> The same idea can be applied to hs_err file location printing. NMT has information about all its mappings and can tell us where it thinks a given unknown pointer points into.
> 
> This could be even more useful if the "find malloc block" part of that functionality would be smarter. As it is now, it only works if the pointer in question points to the start of a user-allocated area. Would be nice if the code could (carefully) search for the next valid-looking malloc header instead.
> 
> --------------
> 
> This patch does this: we introduce a new API, MemTracker::print_containing_region(void*), that tries to make sense of a given unknown pointer.
> 
> It will search its mmap regions and print those if found. For malloc'ed pointers, it will carefully sniff out the immediate surroundings of the block, trying to find what looks like a valid malloc header. It uses SafeFetch to not trip over unmapped or protected pages. Note that, of course, we may get false recognition positives if it finds something that looks like a valid header. But even that could be useful (e.g. a remnant dead header may indicate we access memory after free).
> 
> Looks like this (its arm, so 32-bit pointers):
> 
> 
> Register to memory mapping:
> 
> ->  r0  = 0x728a6ae0 into life malloced block starting at 0x728a6ae0, size 104, tag mtSynchronizer
> ->  r1  = 0x75b02010 into life malloced block starting at 0x75b02010, size 184, tag mtObjectMonitor
> ->  r2  = 0x728a6ae0 into life malloced block starting at 0x728a6ae0, size 104, tag mtSynchronizer
>     r3  = 0x0 is nullptr
> ->  r4  = 0x728a6ae0 into life malloced block starting at 0x728a6ae0, size 104, tag mtSynchronizer
>     r5  = 0xb6d3bbc8: <offset 0x018f6bc8> in /shared/projects/openjdk/jdk-jdk/output-fastdebug-arm/images/jdk/lib/server/libjvm.so at 0xb5445000
>     r6  = 0xffffffff is an unknown value
>     r7  = 0x0 is nullptr
>     r8  = 0x0000000a is an unknown value
>     r9  = 0x728a4308 is a thread
>     r10 = 0x0000000b is an unknown value
> ->  fp  = 0x753fe8cc in mmap'd memory region [0x75380000 - 0x75400000] by Thread Stack
>     r12 = 0x0 is nullptr
> ->  sp  = 0x753fe8b0 in mmap'd memory region [0x75380000 - 0x75400000] by Thread Stack
>     lr  = 0xb69bc1d0: <offset 0x015771d0> in /shared/projects/openjdk/jdk-jdk/output-fastdebug-arm/images/jdk/lib/server/libjvm.so at 0xb5445000
>     pc  = 0xb69c8670: <offset 0x01583670> in /shared/projects/openjdk/jdk-jdk/output-fastdebug-arm/images/jdk/lib/server/libjvm.so at 0xb5445000
> 
> 
> 
> The small caveat here is that NMT reporting needs ThreadCritical, and thus using it for location printing may block error reporting if it crashed inside a ThreadCritical section. We face the same issue today when printing the NMT report as part of the hs-err file. 
> 
> I think the usefulness of these printouts justify this risk. However I opened https://bugs.openjdk.org/browse/JDK-8304824 to investigate a better locking strategy for NMT.

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  Small fixes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13162/files
  - new: https://git.openjdk.org/jdk/pull/13162/files/11b2cc83..600a2c6e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13162&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13162&range=01-02

  Stats: 16 lines in 5 files changed: 0 ins; 10 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/13162.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13162/head:pull/13162

PR: https://git.openjdk.org/jdk/pull/13162

From stuefe at openjdk.org  Fri Mar 24 07:13:23 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 24 Mar 2023 07:13:23 GMT
Subject: RFR: JDK-8304815: Use NMT for more precise hs_err location
 printing [v4]
In-Reply-To: <DPqsrXUm5sJjcxDGZW6QSvdpu83LBhwXreIJU7LXqjI=.dfe3de5e-919a-494d-a8dd-0622d1ee0c65@github.com>
References: <DPqsrXUm5sJjcxDGZW6QSvdpu83LBhwXreIJU7LXqjI=.dfe3de5e-919a-494d-a8dd-0622d1ee0c65@github.com>
Message-ID: <I6toqtDMVqNOMeN42fjnOeCUEGkx27GPsdbr_fWM4sg=.95aa5d1f-f117-4f4b-90da-2093bb205ea3@github.com>

> (This is a byproduct of work on the arm port for https://github.com/openjdk/jdk/pull/10907. I needed better debugging information in the hs-err file and in gdb.)
> 
> Back in 2022 @zhengyu123 had the very nice idea of using NMT mapping info for smartening up pp in gdb: [JDK-8280289](https://bugs.openjdk.org/browse/JDK-8280289).
> 
> The same idea can be applied to hs_err file location printing. NMT has information about all its mappings and can tell us where it thinks a given unknown pointer points into.
> 
> This could be even more useful if the "find malloc block" part of that functionality would be smarter. As it is now, it only works if the pointer in question points to the start of a user-allocated area. Would be nice if the code could (carefully) search for the next valid-looking malloc header instead.
> 
> --------------
> 
> This patch does this: we introduce a new API, MemTracker::print_containing_region(void*), that tries to make sense of a given unknown pointer.
> 
> It will search its mmap regions and print those if found. For malloc'ed pointers, it will carefully sniff out the immediate surroundings of the block, trying to find what looks like a valid malloc header. It uses SafeFetch to not trip over unmapped or protected pages. Note that, of course, we may get false recognition positives if it finds something that looks like a valid header. But even that could be useful (e.g. a remnant dead header may indicate we access memory after free).
> 
> Looks like this (its arm, so 32-bit pointers):
> 
> 
> Register to memory mapping:
> 
> ->  r0  = 0x728a6ae0 into life malloced block starting at 0x728a6ae0, size 104, tag mtSynchronizer
> ->  r1  = 0x75b02010 into life malloced block starting at 0x75b02010, size 184, tag mtObjectMonitor
> ->  r2  = 0x728a6ae0 into life malloced block starting at 0x728a6ae0, size 104, tag mtSynchronizer
>     r3  = 0x0 is nullptr
> ->  r4  = 0x728a6ae0 into life malloced block starting at 0x728a6ae0, size 104, tag mtSynchronizer
>     r5  = 0xb6d3bbc8: <offset 0x018f6bc8> in /shared/projects/openjdk/jdk-jdk/output-fastdebug-arm/images/jdk/lib/server/libjvm.so at 0xb5445000
>     r6  = 0xffffffff is an unknown value
>     r7  = 0x0 is nullptr
>     r8  = 0x0000000a is an unknown value
>     r9  = 0x728a4308 is a thread
>     r10 = 0x0000000b is an unknown value
> ->  fp  = 0x753fe8cc in mmap'd memory region [0x75380000 - 0x75400000] by Thread Stack
>     r12 = 0x0 is nullptr
> ->  sp  = 0x753fe8b0 in mmap'd memory region [0x75380000 - 0x75400000] by Thread Stack
>     lr  = 0xb69bc1d0: <offset 0x015771d0> in /shared/projects/openjdk/jdk-jdk/output-fastdebug-arm/images/jdk/lib/server/libjvm.so at 0xb5445000
>     pc  = 0xb69c8670: <offset 0x01583670> in /shared/projects/openjdk/jdk-jdk/output-fastdebug-arm/images/jdk/lib/server/libjvm.so at 0xb5445000
> 
> 
> 
> The small caveat here is that NMT reporting needs ThreadCritical, and thus using it for location printing may block error reporting if it crashed inside a ThreadCritical section. We face the same issue today when printing the NMT report as part of the hs-err file. 
> 
> I think the usefulness of these printouts justify this risk. However I opened https://bugs.openjdk.org/browse/JDK-8304824 to investigate a better locking strategy for NMT.

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  More small fixes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13162/files
  - new: https://git.openjdk.org/jdk/pull/13162/files/600a2c6e..be8c1142

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13162&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13162&range=02-03

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13162.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13162/head:pull/13162

PR: https://git.openjdk.org/jdk/pull/13162

From jbachorik at openjdk.org  Fri Mar 24 07:31:32 2023
From: jbachorik at openjdk.org (Jaroslav Bachorik)
Date: Fri, 24 Mar 2023 07:31:32 GMT
Subject: RFR: 8304725: AsyncGetCallTrace can cause SIGBUS on M1 [v3]
In-Reply-To: <yiw1snTlUDEuhDu3JFTocZFXmeCvVUOmykBCyUdiG9Q=.8e83408a-7d4b-436b-abb4-aa05e667eb9b@github.com>
References: <XtBvYsLSljF-NTYtEuYvx35NrdX3-VSu_MmirMCLfKc=.3b4e81e3-d53e-445e-85e4-0fb5e6ded7be@github.com>
 <DGciGzZDDGl15JBc93HuQEtwN-KxIPQquyLNJwQS5vM=.a30760eb-2239-4338-8425-33f8938ba514@github.com>
 <OgU0w04HqaCKlfmq7r_Wkx4kqG1ZU_OdtFHZGigXDuA=.e4518216-9281-4382-b6e7-ae9ae2cf3ebc@github.com>
 <CeRblzP5ogONxw_wnM0SylHEHGQmki58mS93h6640yc=.6b915a4b-afe2-46b9-af65-790ccc44a384@github.com>
 <bvlqS4aFu_U_vk3bVzZBqFy68-NFSC1Ovt7WTwQji7I=.169c08b3-2e92-4d98-bcf6-059691a7e2d8@github.com>
 <IMcYKnGw3L0At9QhNBJrUc61HIsghUQeEY24rhXOhjQ=.a9a12084-329f-4619-ae05-b0af5c7d105f@github.com>
 <GYzemBQG5TFFf_wUxFdersNkjuHumLMyM5hgQx0QE8Q=.b4c93261-0b0d-40d1-9419-2a5cdee3eeec@github.com>
 <yiw1snTlUDEuhDu3JFTocZFXmeCvVUOmykBCyUdiG9Q=.8e83408a-7d4b-436b-abb4-aa05e667eb9b@github.com>
Message-ID: <jUEJfvRSwhcsDTknnuJMfXg1_a6KNhZry19DPpphpAU=.8e96a6f0-67f8-48d5-ba1a-d7f77267bb54@github.com>

On Thu, 23 Mar 2023 12:45:27 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Yes, but while JFR interrupts threads too, its sampler runs in its own thread, so the async-safety of the interrupted code should not matter, or?

And this sampling approach is quite subpar when compared with the signal based profiling - both in terms of bias and precision. Meaning that if/when JFR would implement a state-of-the-art CPU profiler it will have to deal with the same issues we are seeing here.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13144#issuecomment-1482370219

From stuefe at openjdk.org  Fri Mar 24 07:38:32 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 24 Mar 2023 07:38:32 GMT
Subject: RFR: JDK-8304723: Statically allocate global mutexes [v5]
In-Reply-To: <eyn9KksfxgQZ_uwh4rMrnxAP5ksyZcs4iMrmWxc8fyM=.1cfb45cc-97d9-49a2-9ad5-f2023f3d9b4a@github.com>
References: <GnX35HIFItX1KV3Zsg5l-zwZVkhP_4Hq5o5ZhtiO57w=.94a86c58-3910-4b52-8c2f-3d6aaf713a06@github.com>
 <eyn9KksfxgQZ_uwh4rMrnxAP5ksyZcs4iMrmWxc8fyM=.1cfb45cc-97d9-49a2-9ad5-f2023f3d9b4a@github.com>
Message-ID: <RVWpIaW9_HYSE25Ycsz4i5w5t5ZUSJ6zmdA_XpwHC-o=.cc7b516f-aa0a-4971-aacc-dbd3c98a4f14@github.com>

On Thu, 23 Mar 2023 15:27:58 GMT, Justin King <jcking at openjdk.org> wrote:

>> Switch to statically allocate storage for all of Hotspot's global mutexes and monitors. This avoids needing to allocate each one dynamically at startup. These also live for the lifetime of the program, so this reduces any potential memory fragmention in the C heap.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move alignas before static
>   
>   Signed-off-by: Justin King <jcking at google.com>

@kimbarrett

> 
> I see no mallocs for the names. The names come from macro stringizing the associated variable in defl(), so are string literals.
> 
> The names used to be embedded in Mutex (providing some padding around the atomic parts I think), with the string passed to the constructor strcpy?ed into that embedded buffer, but that was removed by JDK-8264146.
> 

Names are strduped since https://bugs.openjdk.org/browse/JDK-8265682.
https://github.com/openjdk/jdk/blob/7491f771fac0dca094bac0e5e53afdcf6a4da798/src/hotspot/share/runtime/mutex.cpp#L277

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13143#issuecomment-1482376182

From gcao at openjdk.org  Fri Mar 24 07:48:51 2023
From: gcao at openjdk.org (Gui Cao)
Date: Fri, 24 Mar 2023 07:48:51 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v12]
In-Reply-To: <2STtfSR29CesdgF3zkeMQBqkHjZk32Yqss0NURZDHEI=.f3d8c313-a0f1-4282-b215-59f5a948b2e8@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <2STtfSR29CesdgF3zkeMQBqkHjZk32Yqss0NURZDHEI=.f3d8c313-a0f1-4282-b215-59f5a948b2e8@github.com>
Message-ID: <mfYFJ3m-dfS8nb0yiakHsPEXbOu2nZYdIoJsalyAtds=.30d37287-3144-46d2-8a5c-a21a672b1f95@github.com>

On Thu, 23 Mar 2023 15:37:27 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
>> 
>> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
>> 
>> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
>> 
>> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
>> 
>> This change supports the following platforms: x86, aarch64, PPC, and RISCV
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Andrew comments aarch64

Thanks, the riscv port passed the tier1-3 tests on unmatched board with no new errors introduced.

-------------

Marked as reviewed by gcao (Author).

PR Review: https://git.openjdk.org/jdk/pull/12778#pullrequestreview-1356148354

From fgao at openjdk.org  Fri Mar 24 07:50:51 2023
From: fgao at openjdk.org (Fei Gao)
Date: Fri, 24 Mar 2023 07:50:51 GMT
Subject: Integrated: 8304301: Remove the global option SuperWordMaxVectorSize
In-Reply-To: <2XQwCCx_ficJ1bn2WX0Ud9m-QmuGkkZAH8N6yLugXqQ=.90a136da-db9a-49b4-a4c4-d6c644cf7d5a@github.com>
References: <2XQwCCx_ficJ1bn2WX0Ud9m-QmuGkkZAH8N6yLugXqQ=.90a136da-db9a-49b4-a4c4-d6c644cf7d5a@github.com>
Message-ID: <J3a-RE24MQqbXquWgqRBFkfJo5RbBeMBi6RSJWdeTvo=.c69d30e1-5797-427f-b326-42d80225c385@github.com>

On Tue, 21 Mar 2023 02:26:55 GMT, Fei Gao <fgao at openjdk.org> wrote:

> https://github.com/openjdk/jdk/pull/8877 introduced the global option `SuperWordMaxVectorSize` as a temporary solution to fix the performance regression on some x86 machines.
> 
> Currently, `SuperWordMaxVectorSize` behaves differently between x86 and other platforms [1]. For example, if the current machine only supports `MaxVectorSize <= 32`, but we set `SuperWordMaxVectorSize = 64`, then `SuperWordMaxVectorSize` will be kept at 64 on other platforms while x86 machine would change `SuperWordMaxVectorSize` to `MaxVectorSize`. Other platforms except x86 miss similar implementations like [2].
> 
> Also, `SuperWordMaxVectorSize` limits the max vector size of auto-vectorization as `64`, which is fine for current aarch64 hardware, but SVE architecture supports larger than 512 bits.
> 
> The patch is to drop the global option and use an architecture-dependent interface to consult the max vector size for auto-vectorization, fixing the performance issue on x86 and reducing side effects for other platforms. After the patch, auto-vectorization is still limited to 32-byte vectors by default on Cascade Lake and users can override this by either setting
> `-XX:UseAVX=3` or `-XX:MaxVectorSize=64` on JVM command line.
> 
> So my question is:
> 
> Before the patch, we could have a smaller max vector size for auto-vectorization than `MaxVectorSize` on x86. For example, users could have `MaxVectorSize=64` and `SuperWordMaxVectorSize=32`. But after the change, if we set
> `-XX:MaxVectorSize=64` explicitly, then the max vector size for auto-vectorization would be `MaxVectorSize`, i.e. 64 bytes, which I believe is more reasonable. @sviswa7 @jatin-bhateja, are you happy about the change?
> 
> [1] https://github.com/openjdk/jdk/pull/12350#discussion_r1126106213
> [2] https://github.com/openjdk/jdk/blob/33bec207103acd520eb99afb093cfafa44aecfda/src/hotspot/cpu/x86/vm_version_x86.cpp#L1314-L1333

This pull request has now been integrated.

Changeset: 941a7ac7
Author:    Fei Gao <fgao at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/941a7ac7dab243c6033a78880fd31faa803e62ab
Stats:     104 lines in 14 files changed: 50 ins; 38 del; 16 mod

8304301: Remove the global option SuperWordMaxVectorSize

Reviewed-by: sviswanathan, kvn

-------------

PR: https://git.openjdk.org/jdk/pull/13112

From stuefe at openjdk.org  Fri Mar 24 07:51:00 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 24 Mar 2023 07:51:00 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <nBr83R-0Y5yOf78x8AwzT82prp5oiZwR_cDMmo4Mi24=.255abec1-9cfa-472c-9499-b1170abb067b@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
 <nBr83R-0Y5yOf78x8AwzT82prp5oiZwR_cDMmo4Mi24=.255abec1-9cfa-472c-9499-b1170abb067b@github.com>
Message-ID: <w_VmXJf3PjbgVExM62BMV1BTcXZM9qXKdwWtDFUUkAI=.36b1ae7e-3f0c-44d0-b0bc-9ba021dfda43@github.com>

On Fri, 24 Mar 2023 07:00:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>>  - Set condition flags correctly after fast-lock call on aarch64
>
>> The lock-stack is grown when needed.
> 
> Could you update the description of the PR with the latest approach please - others are unlikely to read all the comments to realize this has changed.

@dholmes-ora 
> Is this thread-safe?

I don't think so, but would the stacklock variant owning_thread_from_monitor_owner not suffer from the same problem?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1482386684

From stuefe at openjdk.org  Fri Mar 24 07:57:32 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 24 Mar 2023 07:57:32 GMT
Subject: RFR: 8304725: AsyncGetCallTrace can cause SIGBUS on M1 [v3]
In-Reply-To: <jUEJfvRSwhcsDTknnuJMfXg1_a6KNhZry19DPpphpAU=.8e96a6f0-67f8-48d5-ba1a-d7f77267bb54@github.com>
References: <XtBvYsLSljF-NTYtEuYvx35NrdX3-VSu_MmirMCLfKc=.3b4e81e3-d53e-445e-85e4-0fb5e6ded7be@github.com>
 <DGciGzZDDGl15JBc93HuQEtwN-KxIPQquyLNJwQS5vM=.a30760eb-2239-4338-8425-33f8938ba514@github.com>
 <OgU0w04HqaCKlfmq7r_Wkx4kqG1ZU_OdtFHZGigXDuA=.e4518216-9281-4382-b6e7-ae9ae2cf3ebc@github.com>
 <CeRblzP5ogONxw_wnM0SylHEHGQmki58mS93h6640yc=.6b915a4b-afe2-46b9-af65-790ccc44a384@github.com>
 <bvlqS4aFu_U_vk3bVzZBqFy68-NFSC1Ovt7WTwQji7I=.169c08b3-2e92-4d98-bcf6-059691a7e2d8@github.com>
 <IMcYKnGw3L0At9QhNBJrUc61HIsghUQeEY24rhXOhjQ=.a9a12084-329f-4619-ae05-b0af5c7d105f@github.com>
 <GYzemBQG5TFFf_wUxFdersNkjuHumLMyM5hgQx0QE8Q=.b4c93261-0b0d-40d1-9419-2a5cdee3eeec@github.com>
 <yiw1snTlUDEuhDu3JFTocZFXmeCvVUOmykBCyUdiG9Q=.8e83408a-7d4b-436b-abb4-aa05e667eb9b@github.com>
 <jUEJfvRSwhcsDTknnuJMfXg1_a6KNhZry19DPpphpAU=.8e96a6f0-67f8-48d5-ba1a-d7f77267bb54@github.com>
Message-ID: <XBr0KL3k6OxLrfXHMJpYbn8GQ0mtf6zEdgcdZLb7ln4=.1fed817b-e100-40e4-a099-6e82444c0607@github.com>

On Fri, 24 Mar 2023 07:28:27 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

> > Yes, but while JFR interrupts threads too, its sampler runs in its own thread, so the async-safety of the interrupted code should not matter, or?
> 
> And this sampling approach is quite subpar when compared with the signal based profiling - both in terms of bias and precision. Meaning that if/when JFR would implement a state-of-the-art CPU profiler it will have to deal with the same issues we are seeing here.

Not if they run the walker outside the sampled thread. Which would be much safer in a lot of ways.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13144#issuecomment-1482392946

From duke at openjdk.org  Fri Mar 24 08:46:36 2023
From: duke at openjdk.org (ExE Boss)
Date: Fri, 24 Mar 2023 08:46:36 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
Message-ID: <VSummI7PkJWPb8R-Ee_GQ5e69_mXIvFaeRPf1lVkGac=.011bc0a0-de39-4bdc-bd96-3e02b301a825@github.com>

On Wed, 22 Mar 2023 14:09:07 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> API changes for the FFM API (third preview)
>> 
>> Specdiff:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
>> 
>> Javadoc:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve javadocs for Linker::captureStateLayout

src/java.base/share/classes/jdk/internal/foreign/abi/SharedUtils.java line 297:

> 295:         MethodType mtype = mh.type();
> 296:         int[] perms = new int[mtype.parameterCount()];
> 297:         MethodType swappedType = MethodType.methodType(mtype.returnType());

Instead?of `MethodType::appendParameterTypes(?)` (which?performs an?expensive?lookup of?a?new?cached `MethodType` value per?call), this?method should?instead use?a?`Class<?>[]` for?the?arguments, which?avoids that?overhead inside?a?loop:

	public static MethodHandle swapArguments(MethodHandle mh, int firstArg, int secondArg) {
		MethodType mtype = mh.type();
		int[] perms = new int[mtype.parameterCount()];
		Class<?>[] ptypes = new Class<?>[perms.length];
		for (int i = 0 ; i < perms.length ; i++) {
			int dst = i;
			if (i == firstArg) dst = secondArg;
			else if (i == secondArg) dst = firstArg;
			perms[i] = dst;
			ptypes[i] = mtype.parameterType(dst);
		}
		// This should use `JavaLangInvokeAccess` to invoke the internal
		// `MethodType.methodType(Class<?> rtype, Class<?>[] ptypes, boolean trusted)`
		// method with a `trusted` value of `true`:
		MethodType swappedType = MethodType.methodType(mtype.returnType(), ptypes);
		return permuteArguments(mh, swappedType, perms);
	}

src/java.base/share/classes/jdk/internal/foreign/abi/fallback/LibFallback.java line 61:

> 59:     static final MemorySegment VOID_TYPE = MemorySegment.ofAddress(ffi_type_void());
> 60:     static final short STRUCT_TAG = ffi_type_struct();
> 61:     private static final long SIZEOF_CIF = sizeofCif();

Won?t?calling `ffi_default_abi()` (and?the?other `ffi_*()`?methods) throw?`UnsatisfiedLinkError` if?`SUPPORTED`?is?`false`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1147259998
PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1147267292

From tschatzl at openjdk.org  Fri Mar 24 08:55:20 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 24 Mar 2023 08:55:20 GMT
Subject: RFR: 8304802: After JDK-8297639 the flag G1UsePreventiveGC needs
 to be added to the obsoletion table [v2]
In-Reply-To: <InH4JukIq7ToDARFz4yGGan43_mE6Vs0yyNBP9mPtok=.2b624755-d549-4e6e-b297-304480d401d9@github.com>
References: <InH4JukIq7ToDARFz4yGGan43_mE6Vs0yyNBP9mPtok=.2b624755-d549-4e6e-b297-304480d401d9@github.com>
Message-ID: <zbTZsiFT_D8YA___AeOApBlXYXd-saEelcxe-TOMrPs=.9af47949-f422-4d13-b821-a7c58ae966d1@github.com>

> Hi all,
> 
>   please review this change that puts the `G1UsePreventiveGC` into the argument obsoletion table so that the appropriate warning is printed when starting the VM with that option. Functionality has already been removed ~, and CSR request approved~ with [JDK-8297639](https://bugs.openjdk.org/browse/JDK-8297639).
> 
> (Edit: no CSR request required because this was a diagnostic flag)
> 
> Testing: local compilation, manual testing that the obsoletion warning is printed on the command line.
> 
> Thanks,
>   Thomas

Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:

  dholems review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13156/files
  - new: https://git.openjdk.org/jdk/pull/13156/files/32410e72..017f2e8c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13156&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13156&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13156.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13156/head:pull/13156

PR: https://git.openjdk.org/jdk/pull/13156

From tschatzl at openjdk.org  Fri Mar 24 09:01:36 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 24 Mar 2023 09:01:36 GMT
Subject: RFR: JDK-8304723: Statically allocate global mutexes [v5]
In-Reply-To: <eyn9KksfxgQZ_uwh4rMrnxAP5ksyZcs4iMrmWxc8fyM=.1cfb45cc-97d9-49a2-9ad5-f2023f3d9b4a@github.com>
References: <GnX35HIFItX1KV3Zsg5l-zwZVkhP_4Hq5o5ZhtiO57w=.94a86c58-3910-4b52-8c2f-3d6aaf713a06@github.com>
 <eyn9KksfxgQZ_uwh4rMrnxAP5ksyZcs4iMrmWxc8fyM=.1cfb45cc-97d9-49a2-9ad5-f2023f3d9b4a@github.com>
Message-ID: <ggOi2lbADmvnBcrysYNtqAxh6WtbcJ8mIm2wlfUtfKQ=.f2f2b928-3e8a-40ad-a3cc-a03e4813241d@github.com>

On Thu, 23 Mar 2023 15:27:58 GMT, Justin King <jcking at openjdk.org> wrote:

>> Switch to statically allocate storage for all of Hotspot's global mutexes and monitors. This avoids needing to allocate each one dynamically at startup. These also live for the lifetime of the program, so this reduces any potential memory fragmention in the C heap.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move alignas before static
>   
>   Signed-off-by: Justin King <jcking at google.com>

Lgtm.

Please close https://bugs.openjdk.org/browse/JDK-8304736 again now that this issue has been fixed, or probably better use `/issue add JDK-8304736`

-------------

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13143#pullrequestreview-1356250411

From tschatzl at openjdk.org  Fri Mar 24 09:03:31 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 24 Mar 2023 09:03:31 GMT
Subject: RFR: 8298725: Add BitMap support for reverse iteration
In-Reply-To: <5usc17TaIE2tQRj8IE58fBtVpXCNSxIp-nPQBzJlrmg=.a0620419-86c9-4a56-9ac7-9d317f07ea5e@github.com>
References: <5usc17TaIE2tQRj8IE58fBtVpXCNSxIp-nPQBzJlrmg=.a0620419-86c9-4a56-9ac7-9d317f07ea5e@github.com>
Message-ID: <T6IVuL6bSd8ywnBhPrh0oed-FXBp65fIUvAqc6B2clI=.0d1367fb-aa5d-4ae7-9ef4-5085cfacf6e0@github.com>

On Wed, 22 Mar 2023 22:51:05 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this addition of BitMap::reverse_iterate, which is like
> BitMap::iterate but visits the set bits in a range from high index to low.
> 
> Testing:
> mach5 tier1, which includes running the updated gtests on all Oracle-supported
> platform

Marked as reviewed by tschatzl (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13151#pullrequestreview-1356253388

From jbechberger at openjdk.org  Fri Mar 24 09:49:32 2023
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Fri, 24 Mar 2023 09:49:32 GMT
Subject: RFR: 8304725: AsyncGetCallTrace can cause SIGBUS on M1 [v3]
In-Reply-To: <XBr0KL3k6OxLrfXHMJpYbn8GQ0mtf6zEdgcdZLb7ln4=.1fed817b-e100-40e4-a099-6e82444c0607@github.com>
References: <XtBvYsLSljF-NTYtEuYvx35NrdX3-VSu_MmirMCLfKc=.3b4e81e3-d53e-445e-85e4-0fb5e6ded7be@github.com>
 <DGciGzZDDGl15JBc93HuQEtwN-KxIPQquyLNJwQS5vM=.a30760eb-2239-4338-8425-33f8938ba514@github.com>
 <OgU0w04HqaCKlfmq7r_Wkx4kqG1ZU_OdtFHZGigXDuA=.e4518216-9281-4382-b6e7-ae9ae2cf3ebc@github.com>
 <CeRblzP5ogONxw_wnM0SylHEHGQmki58mS93h6640yc=.6b915a4b-afe2-46b9-af65-790ccc44a384@github.com>
 <bvlqS4aFu_U_vk3bVzZBqFy68-NFSC1Ovt7WTwQji7I=.169c08b3-2e92-4d98-bcf6-059691a7e2d8@github.com>
 <IMcYKnGw3L0At9QhNBJrUc61HIsghUQeEY24rhXOhjQ=.a9a12084-329f-4619-ae05-b0af5c7d105f@github.com>
 <GYzemBQG5TFFf_wUxFdersNkjuHumLMyM5hgQx0QE8Q=.b4c93261-0b0d-40d1-9419-2a5cdee3eeec@github.com>
 <yiw1snTlUDEuhDu3JFTocZFXmeCvVUOmykBCyUdiG9Q=.8e83408a-7d4b-436b-abb4-aa05e667eb9b@github.com>
 <jUEJfvRSwhcsDTknnuJMfXg1_a6KNhZry19DPpphpAU=.8e96a6f0-67f8-48d5-ba1a-d7f77267bb54@github.com>
 <XBr0KL3k6OxLrfXHMJpYbn8GQ0mtf6zEdgcdZLb7ln4=.1fed817b-e100-40e4-a099-6e82444c0607@github.com>
Message-ID: <mPnKXiIHCSzpjHDnQRTJ9SGQphs_EaFMstbUbEl6U10=.0b38c518-a5fc-4279-bb0f-2bc2ecb9d0ea@github.com>

On Fri, 24 Mar 2023 07:54:56 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Not if they run the walker outside the sampled thread. Which would be much safer in a lot of ways.

Yes, it would, but it is not currently possible with ASGCT, albeit changing it would be quite simple (not changing existing use cases or the API, but would require more tests). I would rather add this to the new JEP.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13144#issuecomment-1482523335

From jbechberger at openjdk.org  Fri Mar 24 10:24:36 2023
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Fri, 24 Mar 2023 10:24:36 GMT
Subject: RFR: 8304725: AsyncGetCallTrace can cause SIGBUS on M1 [v3]
In-Reply-To: <DGciGzZDDGl15JBc93HuQEtwN-KxIPQquyLNJwQS5vM=.a30760eb-2239-4338-8425-33f8938ba514@github.com>
References: <XtBvYsLSljF-NTYtEuYvx35NrdX3-VSu_MmirMCLfKc=.3b4e81e3-d53e-445e-85e4-0fb5e6ded7be@github.com>
 <DGciGzZDDGl15JBc93HuQEtwN-KxIPQquyLNJwQS5vM=.a30760eb-2239-4338-8425-33f8938ba514@github.com>
Message-ID: <-sKa3prVSdWYycIfDQo9I1cikLcAx03Du9ScH3g8k-M=.f6a68864-d5f5-4522-be7b-b62f2d666668@github.com>

On Thu, 23 Mar 2023 08:20:18 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Fixes the issue by transitioning the thread into the WXWrite mode while walking the stack in AsyncGetCallTrace.
>> 
>> Tested on my M1 mac.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use raw_thread instead of Thread::current()

I tested the execution time of individual ASGCT calls on the renaissance benchmark using [asgct_perf_test](https://github.com/parttimenerd/asgct_perf_test) which I created for this purpose.

TLDR: No relevant performance difference when disabling cache modification for ASGCT via a field in `Thread`.

On Linux (64 core machine), all timings are in microseconds. With the disabled caches we get:

bucket         %       count      min     mean      max      std std/mean   median     90th     99th
overall      100    81265409     0.04     4.07 59334.88    32.23     7.93     2.62     7.14    23.20

vs with current head OpenJDK:

overall      100    81607301     0.03     3.96 83194.84    30.49     7.69     2.57     7.00    22.27

The difference of the averages just 110ns which should be undetectable in real life.

With the disabled caches on Mac M1 we get:

overall      100    39281484     0.00     1.39 94833.66    36.48    26.21     0.92     2.08     9.46

vs with the current JDK and [the fix adapted from async-profiler](https://github.com/async-profiler/async-profiler/blob/e3b7bfca227ae5c916f00abfacf0e61291df3a67/src/profiler.cpp#L383) which sets the WX mode:

overall      100    37725188     0.00     1.40110634.45    29.39    20.92     0.92     2.17    10.21

Which doesn't alter the performance characteristics.

I'm therefore pushing my new change to this PR, which prevents ASGCT from modifying any PcDesc cache.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13144#issuecomment-1482570550

From jbechberger at openjdk.org  Fri Mar 24 10:35:36 2023
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Fri, 24 Mar 2023 10:35:36 GMT
Subject: RFR: 8304725: AsyncGetCallTrace can cause SIGBUS on M1 [v4]
In-Reply-To: <XtBvYsLSljF-NTYtEuYvx35NrdX3-VSu_MmirMCLfKc=.3b4e81e3-d53e-445e-85e4-0fb5e6ded7be@github.com>
References: <XtBvYsLSljF-NTYtEuYvx35NrdX3-VSu_MmirMCLfKc=.3b4e81e3-d53e-445e-85e4-0fb5e6ded7be@github.com>
Message-ID: <EQIl485VD7pz67UoYHG57Pv8FA-KkLVOb_J7ynNfyi0=.81b07902-2af9-42cf-bc6a-147107143075@github.com>

> Fixes the issue by transitioning the thread into the WXWrite mode while walking the stack in AsyncGetCallTrace.
> 
> Tested on my M1 mac.

Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:

 - Remove misc lines
 - Disable caching in ASGCT

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13144/files
  - new: https://git.openjdk.org/jdk/pull/13144/files/22b661dd..1973e005

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13144&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13144&range=02-03

  Stats: 33 lines in 3 files changed: 27 ins; 3 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13144.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13144/head:pull/13144

PR: https://git.openjdk.org/jdk/pull/13144

From aph at openjdk.org  Fri Mar 24 10:40:45 2023
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 24 Mar 2023 10:40:45 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v12]
In-Reply-To: <2STtfSR29CesdgF3zkeMQBqkHjZk32Yqss0NURZDHEI=.f3d8c313-a0f1-4282-b215-59f5a948b2e8@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <2STtfSR29CesdgF3zkeMQBqkHjZk32Yqss0NURZDHEI=.f3d8c313-a0f1-4282-b215-59f5a948b2e8@github.com>
Message-ID: <vEsOYdpVO8VWIjUOtRCa54zXf62GHVroYrujLjcTdYs=.6a29c613-2626-4aed-a031-7e249542e13e@github.com>

On Thu, 23 Mar 2023 15:37:27 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
>> 
>> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
>> 
>> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
>> 
>> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
>> 
>> This change supports the following platforms: x86, aarch64, PPC, and RISCV
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Andrew comments aarch64

src/hotspot/cpu/aarch64/templateTable_aarch64.cpp line 2348:

> 2346:   address entry = CAST_FROM_FN_PTR(address, InterpreterRuntime::resolve_from_cache);
> 2347:   __ mov(method, code); // this is essentially Bytecodes::_invokedynamic
> 2348:   __ call_VM(noreg, entry, method); // Example uses temp = rbx. In this case rbx is method

What is `rbx` ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12778#discussion_r1147401509

From aph at openjdk.org  Fri Mar 24 10:48:49 2023
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 24 Mar 2023 10:48:49 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v12]
In-Reply-To: <2STtfSR29CesdgF3zkeMQBqkHjZk32Yqss0NURZDHEI=.f3d8c313-a0f1-4282-b215-59f5a948b2e8@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <2STtfSR29CesdgF3zkeMQBqkHjZk32Yqss0NURZDHEI=.f3d8c313-a0f1-4282-b215-59f5a948b2e8@github.com>
Message-ID: <H-tRMOj4qZyIGwGlsp4S46xgkCtrVX8zkRdrg1BpI3U=.2c8e1cd0-f69b-469a-836d-8102e0e8389d@github.com>

On Thu, 23 Mar 2023 15:37:27 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
>> 
>> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
>> 
>> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
>> 
>> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
>> 
>> This change supports the following platforms: x86, aarch64, PPC, and RISCV
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Andrew comments aarch64

src/hotspot/cpu/aarch64/templateTable_aarch64.cpp line 2322:

> 2320:   }
> 2321: }
> 2322: 

We need a comment here: incoming args, result (what?) in LR.

Also say what regs are clobbered. I guess because there's a `call_vm()` that's all call-clobbered regs. But saves `bcp`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12778#discussion_r1147407483

From jsjolen at openjdk.org  Fri Mar 24 11:47:35 2023
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 24 Mar 2023 11:47:35 GMT
Subject: RFR: JDK-8304815: Use NMT for more precise hs_err location
 printing [v4]
In-Reply-To: <I6toqtDMVqNOMeN42fjnOeCUEGkx27GPsdbr_fWM4sg=.95aa5d1f-f117-4f4b-90da-2093bb205ea3@github.com>
References: <DPqsrXUm5sJjcxDGZW6QSvdpu83LBhwXreIJU7LXqjI=.dfe3de5e-919a-494d-a8dd-0622d1ee0c65@github.com>
 <I6toqtDMVqNOMeN42fjnOeCUEGkx27GPsdbr_fWM4sg=.95aa5d1f-f117-4f4b-90da-2093bb205ea3@github.com>
Message-ID: <B-4Nf5R_pq0iXq-qk_SgL3Lb0nEYlZMSIbIrQ9PNUpc=.7075ac44-4517-4b04-b4bc-01c205195c21@github.com>

On Fri, 24 Mar 2023 07:13:23 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> (This is a byproduct of work on the arm port for https://github.com/openjdk/jdk/pull/10907. I needed better debugging information in the hs-err file and in gdb.)
>> 
>> Back in 2022 @zhengyu123 had the very nice idea of using NMT mapping info for smartening up pp in gdb: [JDK-8280289](https://bugs.openjdk.org/browse/JDK-8280289).
>> 
>> The same idea can be applied to hs_err file location printing. NMT has information about all its mappings and can tell us where it thinks a given unknown pointer points into.
>> 
>> This could be even more useful if the "find malloc block" part of that functionality would be smarter. As it is now, it only works if the pointer in question points to the start of a user-allocated area. Would be nice if the code could (carefully) search for the next valid-looking malloc header instead.
>> 
>> --------------
>> 
>> This patch does this: we introduce a new API, MemTracker::print_containing_region(void*), that tries to make sense of a given unknown pointer.
>> 
>> It will search its mmap regions and print those if found. For malloc'ed pointers, it will carefully sniff out the immediate surroundings of the block, trying to find what looks like a valid malloc header. It uses SafeFetch to not trip over unmapped or protected pages. Note that, of course, we may get false recognition positives if it finds something that looks like a valid header. But even that could be useful (e.g. a remnant dead header may indicate we access memory after free).
>> 
>> Looks like this (its arm, so 32-bit pointers):
>> 
>> 
>> Register to memory mapping:
>> 
>> ->  r0  = 0x728a6ae0 into life malloced block starting at 0x728a6ae0, size 104, tag mtSynchronizer
>> ->  r1  = 0x75b02010 into life malloced block starting at 0x75b02010, size 184, tag mtObjectMonitor
>> ->  r2  = 0x728a6ae0 into life malloced block starting at 0x728a6ae0, size 104, tag mtSynchronizer
>>     r3  = 0x0 is nullptr
>> ->  r4  = 0x728a6ae0 into life malloced block starting at 0x728a6ae0, size 104, tag mtSynchronizer
>>     r5  = 0xb6d3bbc8: <offset 0x018f6bc8> in /shared/projects/openjdk/jdk-jdk/output-fastdebug-arm/images/jdk/lib/server/libjvm.so at 0xb5445000
>>     r6  = 0xffffffff is an unknown value
>>     r7  = 0x0 is nullptr
>>     r8  = 0x0000000a is an unknown value
>>     r9  = 0x728a4308 is a thread
>>     r10 = 0x0000000b is an unknown value
>> ->  fp  = 0x753fe8cc in mmap'd memory region [0x75380000 - 0x75400000] by Thread Stack
>>     r12 = 0x0 is nullptr
>> ->  sp  = 0x753fe8b0 in mmap'd memory region [0x75380000 - 0x75400000] by Thread Stack
>>     lr  = 0xb69bc1d0: <offset 0x015771d0> in /shared/projects/openjdk/jdk-jdk/output-fastdebug-arm/images/jdk/lib/server/libjvm.so at 0xb5445000
>>     pc  = 0xb69c8670: <offset 0x01583670> in /shared/projects/openjdk/jdk-jdk/output-fastdebug-arm/images/jdk/lib/server/libjvm.so at 0xb5445000
>> 
>> 
>> 
>> The small caveat here is that NMT reporting needs ThreadCritical, and thus using it for location printing may block error reporting if it crashed inside a ThreadCritical section. We face the same issue today when printing the NMT report as part of the hs-err file. 
>> 
>> I think the usefulness of these printouts justify this risk. However I opened https://bugs.openjdk.org/browse/JDK-8304824 to investigate a better locking strategy for NMT.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More small fixes

Thanks!

I've got some requested changes, but I like it as a whole.

src/hotspot/share/services/mallocHeader.inline.hpp line 122:

> 120: // Used for debugging purposes only. Check header if it could constitute a valid (life or dead) header.
> 121: inline bool MallocHeader::looks_valid() const {
> 122:   // Note: we define these restrictions lose enough to also catch moderately corrupted blocks.

lose -> loose

src/hotspot/share/services/mallocTracker.cpp line 201:

> 199:   if (!MemTracker::enabled()) {
> 200:     return false;
> 201:   }

I'll paraphrase you: "Your robbing MemTracker of its purpose in life!" :). This should be an `assert` and the corresponding `MemTracker` function should check whether it's enabled or not (which it does).

src/hotspot/share/services/mallocTracker.cpp line 253:

> 251:       }
> 252:     }
> 253:     candidate --;

I rewrote the loop, trying to do as many up front checks as possible and add more comments. It works exactly the same, but I thought this was a bit easier for a first reader to go through. If you like some or all of it, please apply it!

```c++
for (; candidate >= last_candidate; candidate--) {
  if (!os::is_readable_pointer(candidate)) {
    // Probably OOB, give up
    return false;
  }
  if (!candidate->looks_valid()) {
    // This is definitely not a header, go on to the next candidate.
    continue;
  }

  // fudge factor:
  // We don't report blocks for which p is clearly outside of. That would cause us to return true and possibly prevent
  // subsequent tests of p, see os::print_location(). But if p is just outside of the found block, this may be a
  // narrow oob error and we'd like to know that.
  const int fudge = 8;
  const address start_block = (address)candidate;
  const address start_payload = (address)(candidate + 1);
  const address end_payload = start_payload + candidate->size();
  const address end_payload_plus_fudge = end_payload + fudge;
  if (!(addr >= start_block && addr < end_payload_plus_fudge)) {
    // The address of the pointer is not within what the header recorded.
    if (candidate->is_live()) {
      // The candidate is live, meaning we found a header
      // of some allocation that is not part of this pointer.
      // Then we can give up, we're clearly reading into some other payload.
      return false;
    } else {
      // The candidate is dead, so this may be a remnant of an older freed block.
      // We continue searching.
      continue;
    }
  }

  // We've found a reasonable candidate. Print the info.
  const char* where = nullptr;
  if (addr < start_payload) {
    where = "into header of";
  } else if (addr < end_payload) {
    where = "into";
  } else {
    where = "just outside of";
  }
  st->print_cr(PTR_FORMAT " %s %s malloced block starting at " PTR_FORMAT ", size " SIZE_FORMAT ", tag %s",
               p2i(p), where,
               (candidate->is_dead() ? "dead" : "live"),
               p2i(candidate + 1), // lets print the payload start, not the header
               candidate->size(), NMTUtil::flag_to_enum_name(candidate->flags()));
  if (MemTracker::tracking_level() == NMT_detail) {
    NativeCallStack ncs;
    if (candidate->get_stack(ncs)) {
      ncs.print_on(st);
      st->cr();
    }
  }
  return true;
}

test/hotspot/gtest/nmt/test_nmt_locationprinting.cpp line 31:

> 29: #include "unittest.hpp"
> 30: 
> 31: //#define LOG_PLEASE

Outdated?

-------------

Changes requested by jsjolen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/13162#pullrequestreview-1356413633
PR Review Comment: https://git.openjdk.org/jdk/pull/13162#discussion_r1147397935
PR Review Comment: https://git.openjdk.org/jdk/pull/13162#discussion_r1147405406
PR Review Comment: https://git.openjdk.org/jdk/pull/13162#discussion_r1147469057
PR Review Comment: https://git.openjdk.org/jdk/pull/13162#discussion_r1147471544

From jsjolen at openjdk.org  Fri Mar 24 11:47:37 2023
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 24 Mar 2023 11:47:37 GMT
Subject: RFR: JDK-8304815: Use NMT for more precise hs_err location
 printing [v4]
In-Reply-To: <B-4Nf5R_pq0iXq-qk_SgL3Lb0nEYlZMSIbIrQ9PNUpc=.7075ac44-4517-4b04-b4bc-01c205195c21@github.com>
References: <DPqsrXUm5sJjcxDGZW6QSvdpu83LBhwXreIJU7LXqjI=.dfe3de5e-919a-494d-a8dd-0622d1ee0c65@github.com>
 <I6toqtDMVqNOMeN42fjnOeCUEGkx27GPsdbr_fWM4sg=.95aa5d1f-f117-4f4b-90da-2093bb205ea3@github.com>
 <B-4Nf5R_pq0iXq-qk_SgL3Lb0nEYlZMSIbIrQ9PNUpc=.7075ac44-4517-4b04-b4bc-01c205195c21@github.com>
Message-ID: <wxRXupVDA2HI6L-N1LYkRO4mbOI7yCYqHu5UbnahLg4=.7bd100d2-9a27-446b-b176-8ad926f6974e@github.com>

On Fri, 24 Mar 2023 11:40:45 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More small fixes
>
> src/hotspot/share/services/mallocTracker.cpp line 253:
> 
>> 251:       }
>> 252:     }
>> 253:     candidate --;
> 
> I rewrote the loop, trying to do as many up front checks as possible and add more comments. It works exactly the same, but I thought this was a bit easier for a first reader to go through. If you like some or all of it, please apply it!
> 
> ```c++
> for (; candidate >= last_candidate; candidate--) {
>   if (!os::is_readable_pointer(candidate)) {
>     // Probably OOB, give up
>     return false;
>   }
>   if (!candidate->looks_valid()) {
>     // This is definitely not a header, go on to the next candidate.
>     continue;
>   }
> 
>   // fudge factor:
>   // We don't report blocks for which p is clearly outside of. That would cause us to return true and possibly prevent
>   // subsequent tests of p, see os::print_location(). But if p is just outside of the found block, this may be a
>   // narrow oob error and we'd like to know that.
>   const int fudge = 8;
>   const address start_block = (address)candidate;
>   const address start_payload = (address)(candidate + 1);
>   const address end_payload = start_payload + candidate->size();
>   const address end_payload_plus_fudge = end_payload + fudge;
>   if (!(addr >= start_block && addr < end_payload_plus_fudge)) {
>     // The address of the pointer is not within what the header recorded.
>     if (candidate->is_live()) {
>       // The candidate is live, meaning we found a header
>       // of some allocation that is not part of this pointer.
>       // Then we can give up, we're clearly reading into some other payload.
>       return false;
>     } else {
>       // The candidate is dead, so this may be a remnant of an older freed block.
>       // We continue searching.
>       continue;
>     }
>   }
> 
>   // We've found a reasonable candidate. Print the info.
>   const char* where = nullptr;
>   if (addr < start_payload) {
>     where = "into header of";
>   } else if (addr < end_payload) {
>     where = "into";
>   } else {
>     where = "just outside of";
>   }
>   st->print_cr(PTR_FORMAT " %s %s malloced block starting at " PTR_FORMAT ", size " SIZE_FORMAT ", tag %s",
>                p2i(p), where,
>                (candidate->is_dead() ? "dead" : "live"),
>                p2i(candidate + 1), // lets print the payload start, not the header
>                candidate->size(), NMTUtil::flag_to_enum_name(candidate->flags()));
>   if (MemTracker::tracking_level() == NMT_detail) {
>     NativeCallStack ncs;
>     if (candidate->get_stack(ncs)) {
>       ncs.print_on(st);
>       st->cr();
>     }
>   }
>   return true;
> }

PS. I haven't compiled it :).

> test/hotspot/gtest/nmt/test_nmt_locationprinting.cpp line 31:
> 
>> 29: #include "unittest.hpp"
>> 30: 
>> 31: //#define LOG_PLEASE
> 
> Outdated?

Or meant as a hint?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13162#discussion_r1147469499
PR Review Comment: https://git.openjdk.org/jdk/pull/13162#discussion_r1147472097

From shade at openjdk.org  Fri Mar 24 11:54:09 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 24 Mar 2023 11:54:09 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
Message-ID: <nRCVukhWG7mplVCtzhcrXxWb9fu3vPVmRfXno0Rk7iE=.3b04aaa0-d3c5-48e4-8514-3fb5d25f9662@github.com>

On Thu, 16 Mar 2023 20:56:15 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>  - Set condition flags correctly after fast-lock call on aarch64

Cursory review follows.

src/hotspot/cpu/aarch64/aarch64.ad line 3848:

> 3846:         __ bind(slow);
> 3847:         __ tst(oop, oop); // Force ZF=0 to indicate failure and take slow-path. We know that oop != null.
> 3848:         __ b(no_count);

Is this a micro-optimization? I think we can simplify the code by just setting the flags here and then jumping into the usual `__ b(cont)`. This would make the move of `__ b(cont)` unnecessary below.

src/hotspot/cpu/aarch64/aarch64.ad line 3954:

> 3952:         // Indicate success on completion.
> 3953:         __ cmp(oop, oop);
> 3954:         __ b(count);

`aarch64_enc_fast_lock` explicitly sets NE on failure path. But this code just jumps to `no_count` without setting the flag. Does the code outside this encoding block rely on flags?

src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp line 90:

> 88:     Label done;
> 89:     // and mark it as unlocked
> 90:      orr(hdr, hdr, markWord::unlocked_value);

Indentation:

Suggestion:

    orr(hdr, hdr, markWord::unlocked_value);

src/hotspot/cpu/x86/c1_LIRGenerator_x86.cpp line 322:

> 320:   // object is already locked (xhandlers expect object to be unlocked)
> 321:   CodeEmitInfo* info = state_for(x, x->state(), true);
> 322:   LIR_Opr tmp = UseFastLocking ? new_register(T_INT) : LIR_OprFact::illegalOpr;

Is it really `T_INT`, not `T_ADDRESS`? I guess it follows the definition of `LIR_Opr lock` above, but maybe that one is accidentally working because lock addresses fit in 32 bit? I wonder what that `tmp` would be used for, maybe 64-bit math would break with it? (I separately notice that `syncTempOpr()` is just `rax`, so )

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 611:

> 609:       bind(slow);
> 610:       testptr(objReg, objReg); // force ZF=0 to indicate failure
> 611:       jmp(NO_COUNT);

We set a flag on failure (`NO_COUNT`) path. Should we set the flag on success (`COUNT`) path as well?

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 926:

> 924:       mov(boxReg, tmpReg);
> 925:       fast_unlock_impl(objReg, boxReg, tmpReg, NO_COUNT);
> 926:       jmp(COUNT);

Do we need to care about returning proper flags here?

src/hotspot/cpu/x86/macroAssembler_x86.cpp line 9700:

> 9698:   // If successful, push object to lock-stack.
> 9699:   movl(tmp, Address(thread, JavaThread::lock_stack_offset_offset()));
> 9700:   movptr(Address(thread, tmp, Address::times_1), obj);

Minor: I think `Address::times_1` is unnecessary in cases like this. (You might want to grep for other instances of this).

src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp line 1714:

> 1712:         // Save the test result, for recursive case, the result is zero
> 1713:         __ movptr(Address(lock_reg, mark_word_offset), swap_reg);
> 1714:        __ jcc(Assembler::notEqual, slow_path_lock);

Indenting:

Suggestion:

        __ jcc(Assembler::notEqual, slow_path_lock);

src/hotspot/share/runtime/lockStack.cpp line 42:

> 40: 
> 41: #ifndef PRODUCT
> 42: void LockStack::validate(const char* msg) const {

Would you also like to check there are no `nullptr` elements on stack here?

src/hotspot/share/runtime/lockStack.hpp line 42:

> 40:   // We do this instead of a simple index into the array because this allows for
> 41:   // efficient addressing in generated code.
> 42:   int _offset;

This field is accessed from compiled code, we better use a strict-width datatype like `uint32_t`, or maybe even `uint16_t` here?

src/hotspot/share/runtime/lockStack.inline.hpp line 54:

> 52:   assert(to_index(_offset) > 0, "underflow, probably unbalanced push/pop");
> 53:   _offset -= oopSize;
> 54:   oop o = _base[to_index(_offset)];

I think `pop` and `remove` might benefit from zapping the removed elements in the stack, just to make sure we don't accidentally read them? `validate` can check that everything beoynd `end` is zapped, and there are no zapped elements on stack?

src/hotspot/share/runtime/synchronizer.cpp line 315:

> 313:   const markWord mark = obj->mark();
> 314: 
> 315:   if ((mark.is_fast_locked() && current->lock_stack().contains(oop(obj))) ||

`cast_to_oop(obj)` instead of `oop(obj)`?

src/hotspot/share/runtime/synchronizer.cpp line 923:

> 921: static bool is_lock_owned(Thread* thread, oop obj) {
> 922:   assert(UseFastLocking, "only call this with fast-locking enabled");
> 923:   return thread->is_Java_thread() ? reinterpret_cast<JavaThread*>(thread)->lock_stack().contains(obj) : false;

Here and later, should use `JavaThread::cast(thread)` instead of `reinterpret_cast<JavaThread*>`? It also sometimes subsumes the asserts, as `JT::cast` checks the type.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ObjectMonitor.java line 83:

> 81: 
> 82:   public boolean isOwnedAnonymous() {
> 83:     return addr.getAddressAt(ownerFieldOffset).asLongValue() == 1;

This `1` should be `ANONYMOUS_OWNER` constant, I think. So that textual search would hit both `oop.hpp` and this file.

-------------

PR Review: https://git.openjdk.org/jdk/pull/10907#pullrequestreview-1356303825
PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1147415098
PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1147411462
PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1147416146
PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1147433422
PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1147441662
PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1147444139
PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1147452034
PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1147452841
PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1147463354
PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1147319821
PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1147469524
PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1147478054
PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1147374433
PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1147479959

From tschatzl at openjdk.org  Fri Mar 24 12:07:45 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 24 Mar 2023 12:07:45 GMT
Subject: RFR: 8304802: After JDK-8297639 the flag G1UsePreventiveGC needs
 to be added to the obsoletion table
In-Reply-To: <7M70MpWeareVKMTT4FaA01gfEOzoF-8tVagfIkMELdA=.8d752ec7-ab9e-4b22-abf1-1be2921e73db@github.com>
References: <InH4JukIq7ToDARFz4yGGan43_mE6Vs0yyNBP9mPtok=.2b624755-d549-4e6e-b297-304480d401d9@github.com>
 <7M70MpWeareVKMTT4FaA01gfEOzoF-8tVagfIkMELdA=.8d752ec7-ab9e-4b22-abf1-1be2921e73db@github.com>
Message-ID: <A_dnDF2b_JsDHVxjFNhvlv3fhMopYW98Uez2DjWjGN0=.f30cca55-ded5-45ac-819f-e8aeff57b3c7@github.com>

On Fri, 24 Mar 2023 03:14:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change that puts the `G1UsePreventiveGC` into the argument obsoletion table so that the appropriate warning is printed when starting the VM with that option. Functionality has already been removed ~, and CSR request approved~ with [JDK-8297639](https://bugs.openjdk.org/browse/JDK-8297639).
>> 
>> (Edit: no CSR request required because this was a diagnostic flag)
>> 
>> Testing: local compilation, manual testing that the obsoletion warning is printed on the command line.
>> 
>> Thanks,
>>   Thomas
>
> This set of bugs is very confusing, but I'm not seeing the CSR request you mentioned that allowed these flags to be deprecated, then obsoleted. ??

Thanks @dholmes-ora @albertnetymk for your reviews

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13156#issuecomment-1482692524

From tschatzl at openjdk.org  Fri Mar 24 12:07:47 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 24 Mar 2023 12:07:47 GMT
Subject: Integrated: 8304802: After JDK-8297639 the flag G1UsePreventiveGC
 needs to be added to the obsoletion table
In-Reply-To: <InH4JukIq7ToDARFz4yGGan43_mE6Vs0yyNBP9mPtok=.2b624755-d549-4e6e-b297-304480d401d9@github.com>
References: <InH4JukIq7ToDARFz4yGGan43_mE6Vs0yyNBP9mPtok=.2b624755-d549-4e6e-b297-304480d401d9@github.com>
Message-ID: <sy87KIbWBuqQJ3r4e9zP0BMYWKt7V8VQ8NXqZj6tM08=.b18c9496-e716-4e65-b22a-c42a1d152385@github.com>

On Thu, 23 Mar 2023 10:38:04 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change that puts the `G1UsePreventiveGC` into the argument obsoletion table so that the appropriate warning is printed when starting the VM with that option. Functionality has already been removed ~, and CSR request approved~ with [JDK-8297639](https://bugs.openjdk.org/browse/JDK-8297639).
> 
> (Edit: no CSR request required because this was a diagnostic flag)
> 
> Testing: local compilation, manual testing that the obsoletion warning is printed on the command line.
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 13dd19aa
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/13dd19aac2f259c8c22dc79c615e3bdc546f1850
Stats:     8 lines in 2 files changed: 1 ins; 5 del; 2 mod

8304802: After JDK-8297639 the flag G1UsePreventiveGC needs to be added to the obsoletion table

Reviewed-by: ayang, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/13156

From dholmes at openjdk.org  Fri Mar 24 12:12:03 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 24 Mar 2023 12:12:03 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <nRCVukhWG7mplVCtzhcrXxWb9fu3vPVmRfXno0Rk7iE=.3b04aaa0-d3c5-48e4-8514-3fb5d25f9662@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
 <nRCVukhWG7mplVCtzhcrXxWb9fu3vPVmRfXno0Rk7iE=.3b04aaa0-d3c5-48e4-8514-3fb5d25f9662@github.com>
Message-ID: <n0TPB1-WiH51CBAE0uvcZ_j3JWEchgaQA1--4lahDko=.733ac525-e22b-4c7a-b5b2-8685b177c26a@github.com>

On Fri, 24 Mar 2023 10:10:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>>  - Set condition flags correctly after fast-lock call on aarch64
>
> src/hotspot/share/runtime/synchronizer.cpp line 923:
> 
>> 921: static bool is_lock_owned(Thread* thread, oop obj) {
>> 922:   assert(UseFastLocking, "only call this with fast-locking enabled");
>> 923:   return thread->is_Java_thread() ? reinterpret_cast<JavaThread*>(thread)->lock_stack().contains(obj) : false;
> 
> Here and later, should use `JavaThread::cast(thread)` instead of `reinterpret_cast<JavaThread*>`? It also sometimes subsumes the asserts, as `JT::cast` checks the type.

Only JavaThreads can own monitors so this function should take a JavaThread in the first place.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1147499577

From thartmann at openjdk.org  Fri Mar 24 12:13:45 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 24 Mar 2023 12:13:45 GMT
Subject: RFR: 8301012: [vectorapi]: Intrinsify CompressBitsV/ExpandBitsV
 and add the AArch64 SVE backend implementation [v2]
In-Reply-To: <WepLX4oA_2sxHK2IzxZPuCSw126ydVMIkLrQFlwBxhI=.1c20c2fe-62c7-4576-a7f5-bdbfa1055214@github.com>
References: <RaPIEa3D1wT6isue-1l_ILYJ6FCWSeNJ-T8QXtoxnUk=.05a804b5-9b2f-4486-aad4-53f00a3a6ab3@github.com>
 <WepLX4oA_2sxHK2IzxZPuCSw126ydVMIkLrQFlwBxhI=.1c20c2fe-62c7-4576-a7f5-bdbfa1055214@github.com>
Message-ID: <hGNqy06rxKagknty5mHqKfplZGqBBKoOfLdWQfml8Nc=.c2c399b7-2013-4156-94bf-96d70d0274b9@github.com>

On Mon, 20 Mar 2023 17:37:59 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

>> This patch adds mid-end compiler vector IR nodes for the scalar CompressBits and ExpandBits nodes - CompressBitsV and ExpandBitsV and also adds aarch64 backend support for these nodes using SVE2 instructions (included in the svebitperm feature). As there are direct instructions in SVE2 that map to these operations, a huge speed up in performance can be observed and it might significantly benefit all those workloads that extensively run these operations on an SVE2(with svebitperm feature) supporting machine.
>> 
>> All the JTREG tests under "test/jdk/jdk/incubator/vector" pass successfully with this patch on an SVE2 machine.
>> The JMH tests - COMPRESS_BITS and EXPAND_BITS from [1] and [2] were run on a 128-bit vector length, SVE2 and svebitperm supporting aarch64 machine. Following are the gains observed with this patch -
>> 
>> 
>> Benchmark                       (length)  Mode    Cnt   Gain
>> IntMaxVector.COMPRESS_BITS      1024      thrpt   15    81.68x
>> IntMaxVector.EXPAND_BITS        1024      thrpt   15    85.65x
>> LongMaxVector.COMPRESS_BITS     1024      thrpt   15    70.78x
>> LongMaxVector.EXPAND_BITS       1024      thrpt   15    76.31x
>> 
>> 
>> The "Gain" column is the ratio between the throughput of benchmark runs with this patch and that of benchmark runs without this patch. This patch does not change the performance of these operations for all other machines that do not support these instructions or when run on a different architecture.
>> 
>> This patch enables the generation of optimized SVE2 instructions for CompressBits and ExpandBits operations through vectorapi but at the same time with the addition of scalar implementation of CompressBits andExpandBits in the aarch64 backend with this commit - https://github.com/openjdk/jdk/commit/bbd8ae78200e4128d4eddf8694835956b5c5f142, it also enabes auto-vectorization of these nodes on aarch64 SVE2 supporting machines.
>> 
>> Measured the performance of the following benchmarks with the master branch (auto-vectorization not enabled) with this patch
>> (auto-vectorization enabled) -
>>     
>> 
>>         @Benchmark
>>         public void testCompInt() {
>>             for (int i = 0; i < length; i++) {
>>                 ir[i] = Integer.compress(ia[i], ib[i]);
>>             }
>>         }
>>     
>>         @Benchmark
>>         public void testExpInt() {
>>             for (int i = 0; i < length; i++) {
>>                 ir[i] = Integer.expand(ia[i], ib[i]);
>>             }
>>         }
>>     
>>         @Benchmark
>>         public void testCompLong() {
>>             for (int i = 0; i < length; i++) {
>>                 lr[i] = Long.compress(la[i], lb[i]);
>>             }
>>         }
>>     
>>         @Benchmark
>>         public void testExpLong() {
>>             for (int i = 0; i < length; i++) {
>>                 lr[i] = Long.expand(la[i], lb[i]);
>>             }
>>         }
>>     
>>     Benchmark                               (length)  Mode     Cnt   Gain
>>     VectorCompressExpand.testCompInt        2048      thrpt    15    9.97x
>>     VectorCompressExpand.testCompLong       2048      thrpt    15    5.63x
>>     VectorCompressExpand.testExpInt         2048      thrpt    15    9.70x
>>     VectorCompressExpand.testExpLong        2048      thrpt    15    5.66x
>> 
>> ```    
>>     
>> Gain column is the ratio between the throughput of this patch and that of the master branch.
>> With vectorization enabled (either through Superword or Vectorapi), significant gains can be observed for CompressBits and ExpandBits.
>> 
>> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/IntMaxVector.java 
>> [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/LongMaxVector.java
>
> Bhavana Kilambi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge master and fix conflicts
>  - 8301012: [vectorapi]: Intrinsify CompressBitsV/ExpandBitsV and add the AArch64 SVE backend implementation
>    
>    This patch adds mid-end compiler vector IR nodes for the scalar
>    CompressBits and ExpandBits nodes - CompressBitsV and ExpandBitsV and
>    also adds aarch64 backend support for these nodes using SVE2
>    instructions (included in the svebitperm feature).
>    As there are direct instructions in SVE2 that map to these operations,
>    a huge speed up in performance can be observed and it might significantly
>    benefit all those workloads that extensively run these operations on an
>    SVE2(with svebitperm feature) supporting machine.
>    
>    All the JTREG tests under "test/jdk/jdk/incubator/vector" pass
>    successfully with this patch on an SVE2 machine.
>    The JMH tests - COMPRESS_BITS and EXPAND_BITS from [1] and [2]
>    were run on a 128-bit vector length, SVE2 and svebitperm supporting
>    aarch64 machine. Following are the gains observed with this patch -
>    
>    Benchmark                       (length)  Mode    Cnt   Gain
>    IntMaxVector.COMPRESS_BITS      1024      thrpt   15    81.68x
>    IntMaxVector.EXPAND_BITS        1024      thrpt   15    85.65x
>    LongMaxVector.COMPRESS_BITS     1024      thrpt   15    70.78x
>    LongMaxVector.EXPAND_BITS       1024      thrpt   15    76.31x
>    
>    The "Gain" column is the ratio between the throughput of benchmark runs
>    with this patch and that of benchmark runs without this patch. This patch
>    does not change the performance of these operations for all other
>    machines that do not support these instructions or when run on a
>    different architecture.
>    With this patch, vectorization of CompressBits and ExpandBits operations
>    happens only through vectorapi for aarch64. Autovectorization does not
>    take place as the current JDK source does not contain aarch64 backend
>    implementation for scalar CompressBits and ExpandBits. However, this PR -
>    https://github.com/openjdk/jdk/pull/10537 adds aarch64 backend
>    implementaton for CompressBits and ExpandBits and may lead to
>    autovectorization of these nodes as well eventually but this PR is a
>    standalone one and not dependent on the scalar implementation.
>    
>    [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/IntMaxVector.java
>    [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/LongMaxVector.java

I'm not an expert in SVE and we don't have the corresponding hardware to test this. But the changes look reasonable to me and pass our testing.

-------------

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12446#pullrequestreview-1356575437

From dholmes at openjdk.org  Fri Mar 24 12:18:06 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 24 Mar 2023 12:18:06 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <nBr83R-0Y5yOf78x8AwzT82prp5oiZwR_cDMmo4Mi24=.255abec1-9cfa-472c-9499-b1170abb067b@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
 <nBr83R-0Y5yOf78x8AwzT82prp5oiZwR_cDMmo4Mi24=.255abec1-9cfa-472c-9499-b1170abb067b@github.com>
Message-ID: <OEyFTdBcevomodrcK1DFRTMNT3g6AkqqYJqjVn3dDYQ=.ddffc882-97f6-44e8-9617-d60ec2138553@github.com>

On Fri, 24 Mar 2023 07:00:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>>  - Set condition flags correctly after fast-lock call on aarch64
>
>> The lock-stack is grown when needed.
> 
> Could you update the description of the PR with the latest approach please - others are unlikely to read all the comments to realize this has changed.

> @dholmes-ora
> 
> > Is this thread-safe?
> 
> I don't think so, but would the stacklock variant owning_thread_from_monitor_owner not suffer from the same problem?

@tstuefe Yes but that code has already had its thread-safety properties determined (presumably) long ago. Checking whether an address is within a thread's stack is pretty thread-safe. The new code needs to ensure that iteration with `contains` is safe in the face of a concurrent push/pop/remove.

Or  it may be these functions are only called at a safepoint? If so there should be an assert in that case, so I presume that is not the case.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1482707476

From jsjolen at openjdk.org  Fri Mar 24 13:39:36 2023
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 24 Mar 2023 13:39:36 GMT
Subject: RFR: JDK-8294266: Add a way to pre-touch java thread stacks [v4]
In-Reply-To: <LuMQx6RZTOp5_Yl_v6gFaQw4lMzhdTv7neo45cZX1Pk=.d1968e1b-3384-414a-8573-745e1e41faba@github.com>
References: <pbqYDWsnkM5XdmZE6QK7wV7dNuQOCjdyPzw5OlQkSxo=.4ea19fb5-d031-42f7-850c-ae42399e0e80@github.com>
 <LuMQx6RZTOp5_Yl_v6gFaQw4lMzhdTv7neo45cZX1Pk=.d1968e1b-3384-414a-8573-745e1e41faba@github.com>
Message-ID: <DOut4eiqH9VrySJSxt4LyrAdHdkJ1caswSPzEcnZrPU=.7d40167e-9ed0-47db-9027-62997ba9008e@github.com>

On Mon, 14 Nov 2022 10:16:58 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> When doing performance- and footprint analysis, `AlwaysPreTouch` option is very handy for reducing noise. It would be good to have a similar option for pre-touching thread stacks. In addition to reducing noise, it can serve as worst-case test for thread costs, as well as a test for NMT regressions.
>> 
>> Patch adds a new diagnostic switch, `AlwaysPreTouchStacks`, as a companion switch to `AlwaysPreTouch`. Touching is super-simple using `alloca()`. Also, regression test.
>> 
>> Examples:
>> 
>> NMT, thread stacks, 10000 Threads, default:
>> 
>> 
>> -                    Thread (reserved=10332400KB, committed=331828KB)                                       
>>                             (thread #10021)                                                                 
>>                             (stack: reserved=10301560KB, committed=300988KB)                                
>>                             (malloc=19101KB #60755)                                                         
>>                             (arena=11739KB #20037)                                                          
>> 
>> 
>> NMT, thread stacks, 10000 Threads, +AlwaysPreTouchStacks:
>> 
>> 
>> -                    Thread (reserved=10332400KB, committed=10284360KB)                        
>>                             (thread #10021)                                                    
>>                             (stack: reserved=10301560KB, committed=10253520KB)                 
>>                             (malloc=19101KB #60755)                                            
>>                             (arena=11739KB #20037)
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test changes, comment change

To me `alloca()` seems like it should do the right thing. One question: Why is the global in `gc_globals.hpp` and not `globals.hpp`?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10403#issuecomment-1482809890

From matsaave at openjdk.org  Fri Mar 24 15:13:40 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Fri, 24 Mar 2023 15:13:40 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v13]
In-Reply-To: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
Message-ID: <k8l6dEqbMu9z7cTiJVwynq0oSXBVU7v2tcAvhfs6hUk=.fbf07c48-db3f-4fd0-a1cd-1c4773ee6f22@github.com>

> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
> 
> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
> 
> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
> 
> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
> 
> This change supports the following platforms: x86, aarch64, PPC, and RISCV

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  Improved interpreter comments aarch64

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12778/files
  - new: https://git.openjdk.org/jdk/pull/12778/files/546291fc..ff7f3503

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12778&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12778&range=11-12

  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12778.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12778/head:pull/12778

PR: https://git.openjdk.org/jdk/pull/12778

From gziemski at openjdk.org  Fri Mar 24 15:38:54 2023
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Fri, 24 Mar 2023 15:38:54 GMT
Subject: RFR: JDK-8294266: Add a way to pre-touch java thread stacks [v4]
In-Reply-To: <LuMQx6RZTOp5_Yl_v6gFaQw4lMzhdTv7neo45cZX1Pk=.d1968e1b-3384-414a-8573-745e1e41faba@github.com>
References: <pbqYDWsnkM5XdmZE6QK7wV7dNuQOCjdyPzw5OlQkSxo=.4ea19fb5-d031-42f7-850c-ae42399e0e80@github.com>
 <LuMQx6RZTOp5_Yl_v6gFaQw4lMzhdTv7neo45cZX1Pk=.d1968e1b-3384-414a-8573-745e1e41faba@github.com>
Message-ID: <aiKUYWf9IIRMcZwnKaOdnv8ko8EAydbvWMdM4VNu9Ps=.0a2db426-77c4-45ac-b8e3-61a363188b53@github.com>

On Mon, 14 Nov 2022 10:16:58 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> When doing performance- and footprint analysis, `AlwaysPreTouch` option is very handy for reducing noise. It would be good to have a similar option for pre-touching thread stacks. In addition to reducing noise, it can serve as worst-case test for thread costs, as well as a test for NMT regressions.
>> 
>> Patch adds a new diagnostic switch, `AlwaysPreTouchStacks`, as a companion switch to `AlwaysPreTouch`. Touching is super-simple using `alloca()`. Also, regression test.
>> 
>> Examples:
>> 
>> NMT, thread stacks, 10000 Threads, default:
>> 
>> 
>> -                    Thread (reserved=10332400KB, committed=331828KB)                                       
>>                             (thread #10021)                                                                 
>>                             (stack: reserved=10301560KB, committed=300988KB)                                
>>                             (malloc=19101KB #60755)                                                         
>>                             (arena=11739KB #20037)                                                          
>> 
>> 
>> NMT, thread stacks, 10000 Threads, +AlwaysPreTouchStacks:
>> 
>> 
>> -                    Thread (reserved=10332400KB, committed=10284360KB)                        
>>                             (thread #10021)                                                    
>>                             (stack: reserved=10301560KB, committed=10253520KB)                 
>>                             (malloc=19101KB #60755)                                            
>>                             (arena=11739KB #20037)
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test changes, comment change

Marked as reviewed by gziemski (Committer).

LGTM, just had a few questions...

src/hotspot/share/runtime/javaThread.cpp line 2085:

> 2083:   // from the current frame down to the start of the shadow zone.
> 2084:   const address end = _stack_overflow_state.shadow_zone_safe_limit();
> 2085:   if (is_in_full_stack(end)) {

Shouldn't we complain to the user here if false?

src/hotspot/share/runtime/javaThread.cpp line 2088:

> 2086:     char* p1 = (char*) alloca(1);
> 2087:     address here = (address) &p1;
> 2088:     if (is_in_full_stack(here) && here > end) {

Shouldn't we complain to the user here if false?

test/hotspot/jtreg/runtime/Thread/TestAlwaysPreTouchStacks.java line 54:

> 52: 
> 53:         int[] stackSizes = {
> 54:           1024 * 256, 1024 * 512, 1024 * 1024 * 3

I'm curious, how did you decide on these values?

-------------

PR Review: https://git.openjdk.org/jdk/pull/10403#pullrequestreview-1356952758
PR Comment: https://git.openjdk.org/jdk/pull/10403#issuecomment-1483006938
PR Review Comment: https://git.openjdk.org/jdk/pull/10403#discussion_r1147744801
PR Review Comment: https://git.openjdk.org/jdk/pull/10403#discussion_r1147744655
PR Review Comment: https://git.openjdk.org/jdk/pull/10403#discussion_r1147749637

From kvn at openjdk.org  Fri Mar 24 16:38:02 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 24 Mar 2023 16:38:02 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v4]
In-Reply-To: <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com>
Message-ID: <g6BlojUYZSiXJh61lESSO6I2IV7p6ujx7fnMLxeIeoA=.117d0bd6-4ac0-4702-a533-ebe2e6e01e4a@github.com>

On Mon, 20 Mar 2023 19:23:34 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> Can I please get reviews for this PR? 
>> 
>> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested.
>> 
>> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N:
>> 
>> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png)
>> 
>> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1:
>> 
>> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png)
>> 
>> This PR adds support scalar replacing allocations participating in merges that are used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently.
>> 
>> The approach I used for _rematerialization_ is pretty straightforward. It consists basically in: 1) Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a new Class to support rematerialization of SR objects part of merges; 3) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 4) Patch C2 to generate unique types for SR objects participating in some allocation merges.
>> 
>> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straight forward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless.
>> 
>> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also tested with several applications and didn't see any failure. I also run tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add support for SR'ing some inputs of merges used for field loads

Thank you, @JohnTortugo, for continue working on it. I will test it and do proper review late.
Of cause @iwanowww have to approve it too :)

-------------

PR Review: https://git.openjdk.org/jdk/pull/12897#pullrequestreview-1357067077

From jcking at openjdk.org  Fri Mar 24 16:41:50 2023
From: jcking at openjdk.org (Justin King)
Date: Fri, 24 Mar 2023 16:41:50 GMT
Subject: RFR: JDK-8304539: Cleanup
 utilities/{count_leading_zeros, count_trailing_zeros,
 population_count}.hpp [v10]
In-Reply-To: <Ly_ZIg1wqoqnEy0N-YFdQaEpGg7Er8Vtj8phZQhgAw0=.4d9b54db-517e-491e-a376-623139808b7e@github.com>
References: <Ly_ZIg1wqoqnEy0N-YFdQaEpGg7Er8Vtj8phZQhgAw0=.4d9b54db-517e-491e-a376-623139808b7e@github.com>
Message-ID: <jrLxp2S-QM63edDLqOPIP3zrOfdzgcP_ilyRVpUA_lM=.ffa34676-1c52-4b81-9734-34f32a16b838@github.com>

> As the title says, cleanup the mentioned headers. This is similar to `byteswap.hpp` and removes the extraneous `#ifdef` for XLC since it is really just Clang now.

Justin King has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - Update Visual Studio to be 17.1
   
   Signed-off-by: Justin King <jcking at google.com>
 - Merge remote-tracking branch 'upstream/master' into popcount
 - Move template declaration
   
   Signed-off-by: Justin King <jcking at google.com>
 - Add default template implementation
   
   Signed-off-by: Justin King <jcking at google.com>
 - Add missing #endif
   
   Signed-off-by: Justin King <jcking at google.com>
 - Go back to templating for count_trailing_zeros for consistency
   
   Signed-off-by: Justin King <jcking at google.com>
 - Remove intrinsic specifier for CountOneBits
   
   Signed-off-by: Justin King <jcking at google.com>
 - Redo non-templated approach
   
   Signed-off-by: Justin King <jcking at google.com>
 - Remove unnecessary templating from count_trailing_zeros
   
   Signed-off-by: Justin King <jcking at google.com>
 - Fix ambiguous call
   
   Signed-off-by: Justin King <jcking at google.com>
 - ... and 4 more: https://git.openjdk.org/jdk/compare/97649489...1bc46ffa

-------------

Changes: https://git.openjdk.org/jdk/pull/13103/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13103&range=09
  Stats: 434 lines in 4 files changed: 203 ins; 151 del; 80 mod
  Patch: https://git.openjdk.org/jdk/pull/13103.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13103/head:pull/13103

PR: https://git.openjdk.org/jdk/pull/13103

From kvn at openjdk.org  Fri Mar 24 16:43:13 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 24 Mar 2023 16:43:13 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v4]
In-Reply-To: <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com>
Message-ID: <xeGxSTB0GhzgnN1EwPutxShuPnGXh5bbBUs1w28_f64=.d1eadc8e-e78f-41d3-b8b3-823493f01ce6@github.com>

On Mon, 20 Mar 2023 19:23:34 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> Can I please get reviews for this PR? 
>> 
>> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested.
>> 
>> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N:
>> 
>> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png)
>> 
>> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1:
>> 
>> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png)
>> 
>> This PR adds support scalar replacing allocations participating in merges that are used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently.
>> 
>> The approach I used for _rematerialization_ is pretty straightforward. It consists basically in: 1) Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a new Class to support rematerialization of SR objects part of merges; 3) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 4) Patch C2 to generate unique types for SR objects participating in some allocation merges.
>> 
>> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straight forward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless.
>> 
>> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also tested with several applications and didn't see any failure. I also run tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add support for SR'ing some inputs of merges used for field loads

You new test failed in GHA testing with 32-bit VM: `Could not find VM flag "UseCompressedOops" in @IR rule 1 at int`.
You need to adjust next rule: `@IR(counts = { IRNode.ALLOC, "2" }, applyIf = { "UseCompressedOops", "false" })`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12897#issuecomment-1483098691

From jcking at openjdk.org  Fri Mar 24 16:46:47 2023
From: jcking at openjdk.org (Justin King)
Date: Fri, 24 Mar 2023 16:46:47 GMT
Subject: RFR: JDK-8304723: Statically allocate global mutexes [v6]
In-Reply-To: <GnX35HIFItX1KV3Zsg5l-zwZVkhP_4Hq5o5ZhtiO57w=.94a86c58-3910-4b52-8c2f-3d6aaf713a06@github.com>
References: <GnX35HIFItX1KV3Zsg5l-zwZVkhP_4Hq5o5ZhtiO57w=.94a86c58-3910-4b52-8c2f-3d6aaf713a06@github.com>
Message-ID: <YGVZbU3f0JVCx5Q49vgZZhCcjxtNoOy_tR5VrXntT-o=.be4bdcc9-dfcd-418c-bcbd-c5d53efa2fdf@github.com>

> Switch to statically allocate storage for all of Hotspot's global mutexes and monitors. This avoids needing to allocate each one dynamically at startup. These also live for the lifetime of the program, so this reduces any potential memory fragmention in the C heap.

Justin King has updated the pull request incrementally with one additional commit since the last revision:

  Fix spacing as requested
  
  Signed-off-by: Justin King <jcking at google.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13143/files
  - new: https://git.openjdk.org/jdk/pull/13143/files/7491f771..05ccd53f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13143&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13143&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13143/head:pull/13143

PR: https://git.openjdk.org/jdk/pull/13143

From jcking at openjdk.org  Fri Mar 24 16:46:53 2023
From: jcking at openjdk.org (Justin King)
Date: Fri, 24 Mar 2023 16:46:53 GMT
Subject: RFR: JDK-8304723: Statically allocate global mutexes [v5]
In-Reply-To: <BRCnWtIcRVn5ImM0DHq0-TJbY-RoshiQxvgJjjHuN14=.f364d06b-a0ce-472b-a9ea-8c79cd403ad0@github.com>
References: <GnX35HIFItX1KV3Zsg5l-zwZVkhP_4Hq5o5ZhtiO57w=.94a86c58-3910-4b52-8c2f-3d6aaf713a06@github.com>
 <eyn9KksfxgQZ_uwh4rMrnxAP5ksyZcs4iMrmWxc8fyM=.1cfb45cc-97d9-49a2-9ad5-f2023f3d9b4a@github.com>
 <BRCnWtIcRVn5ImM0DHq0-TJbY-RoshiQxvgJjjHuN14=.f364d06b-a0ce-472b-a9ea-8c79cd403ad0@github.com>
Message-ID: <pnD41hl0ToaFGzkYjLczfcDWzj42YcMTIup66GwdKBI=.e471f02c-cb52-42c0-becd-4ea91bc562c3@github.com>

On Fri, 24 Mar 2023 04:53:46 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Justin King has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move alignas before static
>>   
>>   Signed-off-by: Justin King <jcking at google.com>
>
> src/hotspot/share/runtime/mutexLocker.cpp line 210:
> 
>> 208: // Specify relative ranked lock
>> 209: #ifdef ASSERT
>> 210: #define MUTEX_DEFL(name, type, held_lock, ...) MUTEX_DEF(name, type, (held_lock)->rank()-1, ##__VA_ARGS__)
> 
> Pre-existing but what does the 'L' suffix mean here? We now have _DEF _DEFN and _DEFL and I'm not clear what the N and L signify. ??
> 
> Nit while you are here `rank()-1` -> `rank() - 1`

Fixed the spacing to be `rank() - 1`.

As far as `N` and `L` I don't think its anything special. I chose `_DEF` to be the shared macro implementation and `N` as a short for `DEFiNition`. `L` I assume means lock, as in define using another lock's rank. But that is a guess.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13143#discussion_r1147827417

From jcking at openjdk.org  Fri Mar 24 16:46:53 2023
From: jcking at openjdk.org (Justin King)
Date: Fri, 24 Mar 2023 16:46:53 GMT
Subject: RFR: JDK-8304723: Statically allocate global mutexes [v5]
In-Reply-To: <pnD41hl0ToaFGzkYjLczfcDWzj42YcMTIup66GwdKBI=.e471f02c-cb52-42c0-becd-4ea91bc562c3@github.com>
References: <GnX35HIFItX1KV3Zsg5l-zwZVkhP_4Hq5o5ZhtiO57w=.94a86c58-3910-4b52-8c2f-3d6aaf713a06@github.com>
 <eyn9KksfxgQZ_uwh4rMrnxAP5ksyZcs4iMrmWxc8fyM=.1cfb45cc-97d9-49a2-9ad5-f2023f3d9b4a@github.com>
 <BRCnWtIcRVn5ImM0DHq0-TJbY-RoshiQxvgJjjHuN14=.f364d06b-a0ce-472b-a9ea-8c79cd403ad0@github.com>
 <pnD41hl0ToaFGzkYjLczfcDWzj42YcMTIup66GwdKBI=.e471f02c-cb52-42c0-becd-4ea91bc562c3@github.com>
Message-ID: <knlo_nB3zkdj0FlSlRArIOKOrwrI865gCuIaapVGstM=.64b71b4a-f145-48ab-a153-3ae71158fe0f@github.com>

On Fri, 24 Mar 2023 16:41:52 GMT, Justin King <jcking at openjdk.org> wrote:

>> src/hotspot/share/runtime/mutexLocker.cpp line 210:
>> 
>>> 208: // Specify relative ranked lock
>>> 209: #ifdef ASSERT
>>> 210: #define MUTEX_DEFL(name, type, held_lock, ...) MUTEX_DEF(name, type, (held_lock)->rank()-1, ##__VA_ARGS__)
>> 
>> Pre-existing but what does the 'L' suffix mean here? We now have _DEF _DEFN and _DEFL and I'm not clear what the N and L signify. ??
>> 
>> Nit while you are here `rank()-1` -> `rank() - 1`
>
> Fixed the spacing to be `rank() - 1`.
> 
> As far as `N` and `L` I don't think its anything special. I chose `_DEF` to be the shared macro implementation and `N` as a short for `DEFiNition`. `L` I assume means lock, as in define using another lock's rank. But that is a guess.

Also helps that both `_DEFN` and `_DEFL` have the same length, so it helps align things nicely.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13143#discussion_r1147828000

From jcking at openjdk.org  Fri Mar 24 16:53:08 2023
From: jcking at openjdk.org (Justin King)
Date: Fri, 24 Mar 2023 16:53:08 GMT
Subject: RFR: JDK-8304828: Lots of constant static data not declared static
 const in cpu/x86
In-Reply-To: <jtx150S4_ISXzdfhezK_UCXYVF1NF6lenLGyoy8pyYs=.973ccb52-c992-460f-9057-3e6b3ae681d9@github.com>
References: <7KzH7QPu53lViaVf5yIBoJ7hxpvBIK9iZP-L5EVH8U4=.0935258a-29ba-43b5-a845-1201be6dface@github.com>
 <jtx150S4_ISXzdfhezK_UCXYVF1NF6lenLGyoy8pyYs=.973ccb52-c992-460f-9057-3e6b3ae681d9@github.com>
Message-ID: <GGhUG1R9XY-yZ_54Fu4QUSviQRr1maiADK54RWCcg7M=.d5129f5a-8881-4457-9907-d307f8a87230@github.com>

On Fri, 24 Mar 2023 05:14:53 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Changes looks good. But please restart GHA testing. Something went wrong there.

Yeah, something was odd with the run. `wget` failed randomly. Restarted.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13163#issuecomment-1483111575

From coleenp at openjdk.org  Fri Mar 24 16:58:05 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 24 Mar 2023 16:58:05 GMT
Subject: RFR: JDK-8304723: Statically allocate global mutexes [v5]
In-Reply-To: <knlo_nB3zkdj0FlSlRArIOKOrwrI865gCuIaapVGstM=.64b71b4a-f145-48ab-a153-3ae71158fe0f@github.com>
References: <GnX35HIFItX1KV3Zsg5l-zwZVkhP_4Hq5o5ZhtiO57w=.94a86c58-3910-4b52-8c2f-3d6aaf713a06@github.com>
 <eyn9KksfxgQZ_uwh4rMrnxAP5ksyZcs4iMrmWxc8fyM=.1cfb45cc-97d9-49a2-9ad5-f2023f3d9b4a@github.com>
 <BRCnWtIcRVn5ImM0DHq0-TJbY-RoshiQxvgJjjHuN14=.f364d06b-a0ce-472b-a9ea-8c79cd403ad0@github.com>
 <pnD41hl0ToaFGzkYjLczfcDWzj42YcMTIup66GwdKBI=.e471f02c-cb52-42c0-becd-4ea91bc562c3@github.com>
 <knlo_nB3zkdj0FlSlRArIOKOrwrI865gCuIaapVGstM=.64b71b4a-f145-48ab-a153-3ae71158fe0f@github.com>
Message-ID: <tGHTKqBc2_msXVXLTo2BRdfWH0SXAj5iiIn74Gq8otg=.48d30490-f2de-4d34-a330-6fa4c59d78e1@github.com>

On Fri, 24 Mar 2023 16:42:26 GMT, Justin King <jcking at openjdk.org> wrote:

>> Fixed the spacing to be `rank() - 1`.
>> 
>> As far as `N` and `L` I don't think its anything special. I chose `_DEF` to be the shared macro implementation and `N` as a short for `DEFiNition`. `L` I assume means lock, as in define using another lock's rank. But that is a guess.
>
> Also helps that both `_DEFN` and `_DEFL` have the same length, so it helps align things nicely.

Yes, the 'l' in defl was for "lock" originally.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13143#discussion_r1147839413

From stuefe at openjdk.org  Fri Mar 24 16:58:00 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 24 Mar 2023 16:58:00 GMT
Subject: RFR: JDK-8304723: Statically allocate global mutexes
In-Reply-To: <VTSUkzOLYAHn721G6wdSrmaEv7gtDU-3aNjPrxA33_Y=.ff019217-1791-4299-ad28-f79147b93290@github.com>
References: <GnX35HIFItX1KV3Zsg5l-zwZVkhP_4Hq5o5ZhtiO57w=.94a86c58-3910-4b52-8c2f-3d6aaf713a06@github.com>
 <dqrnvRS2FRMd9WlY0Y1lkE9OsBv5xlLTxZQOTKYnmxk=.c6f842c3-adb9-4a6f-a786-317b1398ecba@github.com>
 <ITGp6nOcrq2hcnPNgpOUHkMOwhDu9NMdEwPgwKm-EyI=.c14951e3-0333-408f-bbf8-8f058c2a0009@github.com>
 <skYwSC4jAzrCin2w81NxHTghEskLccvCiuOBytcaNjc=.06749e56-835c-4899-9dad-b652474ef318@github.com>
 <gJ1F_hnAxb_ihQhvsUYmW-L78LZPGl-yHDTJ-vpCaf8=.a192c7bf-c167-48e9-a9c0-42e939dad0a2@github.com>
 <BXcqDv7-NKFC9u_icoFpdjEjd_ivVeCZoTVbFjP1jSI=.0419de3f-dda3-4fec-ac72-563da12f705d@github.com>
 <3qqS-qbU-BYZZykjGcvh0ULclW_Iyee5VMXm54SBDNM=.9ca532d1-36eb-4e35-9488-1184012db403@github.com>
 <VTSUkzOLYAHn721G6wdSrmaEv7gtDU-3aNjPrxA33_Y=.ff019217-1791-4299-ad28-f79147b93290@github.com>
Message-ID: <WlzB9MH9HVLbdqnDQR373gvcqjCifkjUfppX3_L5Q8U=.d2a58285-7e65-49e4-9a63-9386bc0dbecd@github.com>

On Thu, 23 Mar 2023 15:58:27 GMT, Justin King <jcking at openjdk.org> wrote:

>>> > I'd be very happy if startup would be fast enough for ~150 fewer mallocs to matter.
>>> > A blank hello world with no args to speak of calls into malloc >10k times. ~150(?) mallocs less are a step in the right direction.
>>> 
>>> Baby steps. :)
>>> 
>>> As a compromise I'll shift to keeping the pointers and just use a static storage variable in the `def` macros, as suggested. It accomplishes the goal if not malloc'ing but is not as safe due to the two aforementioned bugs. I'll also add an assert to catch the "created twice" problem. But having the mutex pointer always be nullptr is a different story that cannot be caught with that approach.
>> 
>> The create twice problem is admittedly evil. The nullptr problem not so much, since we will access it anyway and crash right there, or?
>
>> > > I'd be very happy if startup would be fast enough for ~150 fewer mallocs to matter.
>> > > A blank hello world with no args to speak of calls into malloc >10k times. ~150(?) mallocs less are a step in the right direction.
>> > 
>> > 
>> > Baby steps. :)
>> > As a compromise I'll shift to keeping the pointers and just use a static storage variable in the `def` macros, as suggested. It accomplishes the goal if not malloc'ing but is not as safe due to the two aforementioned bugs. I'll also add an assert to catch the "created twice" problem. But having the mutex pointer always be nullptr is a different story that cannot be caught with that approach.
>> 
>> The create twice problem is admittedly evil. The nullptr problem not so much, since we will access it anyway and crash right there, or?
> 
> Unfortunately not. It's used with MutexLocker which happily accepts `nullptr` and just doesn't do anything. That is a feature of it. So if you fail to create a mutex, you might not notice and the data being guarded by the mutex is no longer being accessed safely.

@jcking looks a lot better, thank you!

You already have enough reviews. Gave it a cursory glance and it looks good to me.

Cheers, Thomas

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13143#issuecomment-1483112717

From stuefe at openjdk.org  Fri Mar 24 17:00:47 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 24 Mar 2023 17:00:47 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <nRCVukhWG7mplVCtzhcrXxWb9fu3vPVmRfXno0Rk7iE=.3b04aaa0-d3c5-48e4-8514-3fb5d25f9662@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
 <nRCVukhWG7mplVCtzhcrXxWb9fu3vPVmRfXno0Rk7iE=.3b04aaa0-d3c5-48e4-8514-3fb5d25f9662@github.com>
Message-ID: <CfaFMydhpKfCzkc8re16y_oQZvGvO_KLkEN672phdU8=.3dfecf58-9038-48ac-9eb9-f0a76d742d40@github.com>

On Fri, 24 Mar 2023 11:36:24 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>>  - Set condition flags correctly after fast-lock call on aarch64
>
> src/hotspot/share/runtime/lockStack.cpp line 42:
> 
>> 40: 
>> 41: #ifndef PRODUCT
>> 42: void LockStack::validate(const char* msg) const {
> 
> Would you also like to check there are no `nullptr` elements on stack here?

Please also verify against over- and underflow, and better than just null checks check that every oop really is an oop. I added this to my code:

  assert((_offset <=  end_offset()), "lockstack overflow: _offset %d end_offset %d", _offset, end_offset());
  assert((_offset >= start_offset()), "lockstack underflow: _offset %d end_offset %d", _offset, start_offset());
  int end = to_index(_offset);
  for (int i = 0; i < end; i++) {
    assert(oopDesc::is_oop(_base[i]), "index %i: not an oop (" PTR_FORMAT ")", i, p2i(_base[i]));
...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1147841666

From stuefe at openjdk.org  Fri Mar 24 17:15:07 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 24 Mar 2023 17:15:07 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
Message-ID: <m2x5qE_kdoZUNbm8umGkSQVj2TtERnma7f4VAKjCwmg=.0b02535a-7eed-48b5-bad2-09479bc2e2e1@github.com>

On Thu, 16 Mar 2023 20:56:15 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>  - Set condition flags correctly after fast-lock call on aarch64

I'm currently hitting a roadblock on the arm port, where 

> > @dholmes-ora
> > > Is this thread-safe?
> > 
> > 
> > I don't think so, but would the stacklock variant owning_thread_from_monitor_owner not suffer from the same problem?
> 
> @tstuefe Yes but that code has already had its thread-safety properties determined (presumably) long ago. Checking whether an address is within a thread's stack is pretty thread-safe. The new code needs to ensure that iteration with `contains` is safe in the face of a concurrent push/pop/remove.
> 
> Or it may be these functions are only called at a safepoint? If so there should be an assert in that case, so I presume that is not the case.

This is a good question. Its not bound to Safepoint, but it is used in two places atm:

- JVMTI GetObjectMonitorUsage
- Thread dump facility, monitor display

AFAIU, these places now could get outdated information from the contains function: either getting a false positive or a false negative when asking for a given object. But if I understand correctly, this had been the case before, too. Since the information about ownership may be outdated as soon as one read the BasicLock* address from the markwork. So these APIs do only report a state that once had been, but never the current state.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1483144364

From kvn at openjdk.org  Fri Mar 24 17:39:13 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 24 Mar 2023 17:39:13 GMT
Subject: RFR: JDK-8304828: Lots of constant static data not declared static
 const in cpu/x86
In-Reply-To: <7KzH7QPu53lViaVf5yIBoJ7hxpvBIK9iZP-L5EVH8U4=.0935258a-29ba-43b5-a845-1201be6dface@github.com>
References: <7KzH7QPu53lViaVf5yIBoJ7hxpvBIK9iZP-L5EVH8U4=.0935258a-29ba-43b5-a845-1201be6dface@github.com>
Message-ID: <pZ7gEttisEoOJtoa4zTfME8CsDqTPJJvBq3GUpsdr98=.4c4cd92c-dbd3-4c23-9b8d-797284d4b9e4@github.com>

On Thu, 23 Mar 2023 17:31:26 GMT, Justin King <jcking at openjdk.org> wrote:

> Simple refactor that updates declarations and definitions for data that is effectively static and constant to be `static` and/or `const`. Helps make sure we do not break the one definition rule and helps the compiler/linker to place the data in read-only sections of the executable.

Good. I submitted our testing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13163#issuecomment-1483176493

From stuefe at openjdk.org  Fri Mar 24 17:44:36 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 24 Mar 2023 17:44:36 GMT
Subject: RFR: JDK-8294266: Add a way to pre-touch java thread stacks [v4]
In-Reply-To: <aiKUYWf9IIRMcZwnKaOdnv8ko8EAydbvWMdM4VNu9Ps=.0a2db426-77c4-45ac-b8e3-61a363188b53@github.com>
References: <pbqYDWsnkM5XdmZE6QK7wV7dNuQOCjdyPzw5OlQkSxo=.4ea19fb5-d031-42f7-850c-ae42399e0e80@github.com>
 <LuMQx6RZTOp5_Yl_v6gFaQw4lMzhdTv7neo45cZX1Pk=.d1968e1b-3384-414a-8573-745e1e41faba@github.com>
 <aiKUYWf9IIRMcZwnKaOdnv8ko8EAydbvWMdM4VNu9Ps=.0a2db426-77c4-45ac-b8e3-61a363188b53@github.com>
Message-ID: <hSMXGYQf9KiawzEzjkQWIF3HRncfUKLcFuz4KnOl06s=.9272933b-a2e2-460a-b9e8-7b0ef47fe104@github.com>

On Fri, 24 Mar 2023 15:36:14 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   test changes, comment change
>
> LGTM, just had a few questions...

@gerard-ziemski , @jdksjolen 

Thanks guys, I had almost forgotten about this one :-)

@jdksjolen 

> To me alloca() seems like it should do the right thing. 

I think so too. 

> One question: Why is the global in gc_globals.hpp and not globals.hpp?

Its a companion switch to AlwaysPreTouch, which had been a GC switch for some reason. I think because its main intention was to pretouch heap.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10403#issuecomment-1483182291

From stuefe at openjdk.org  Fri Mar 24 17:47:34 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 24 Mar 2023 17:47:34 GMT
Subject: RFR: JDK-8294266: Add a way to pre-touch java thread stacks [v4]
In-Reply-To: <aiKUYWf9IIRMcZwnKaOdnv8ko8EAydbvWMdM4VNu9Ps=.0a2db426-77c4-45ac-b8e3-61a363188b53@github.com>
References: <pbqYDWsnkM5XdmZE6QK7wV7dNuQOCjdyPzw5OlQkSxo=.4ea19fb5-d031-42f7-850c-ae42399e0e80@github.com>
 <LuMQx6RZTOp5_Yl_v6gFaQw4lMzhdTv7neo45cZX1Pk=.d1968e1b-3384-414a-8573-745e1e41faba@github.com>
 <aiKUYWf9IIRMcZwnKaOdnv8ko8EAydbvWMdM4VNu9Ps=.0a2db426-77c4-45ac-b8e3-61a363188b53@github.com>
Message-ID: <E6WccE0W02mOV5hNY4LlSWsvogAlGk5PXZUleb9TCBY=.b8adf09f-b76e-4287-89e2-202898871b4a@github.com>

On Fri, 24 Mar 2023 15:29:27 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   test changes, comment change
>
> src/hotspot/share/runtime/javaThread.cpp line 2085:
> 
>> 2083:   // from the current frame down to the start of the shadow zone.
>> 2084:   const address end = _stack_overflow_state.shadow_zone_safe_limit();
>> 2085:   if (is_in_full_stack(end)) {
> 
> Shouldn't we complain to the user here if false?

Possibly, yes. Maybe even an assert.

> src/hotspot/share/runtime/javaThread.cpp line 2088:
> 
>> 2086:     char* p1 = (char*) alloca(1);
>> 2087:     address here = (address) &p1;
>> 2088:     if (is_in_full_stack(here) && here > end) {
> 
> Shouldn't we complain to the user here if false?

Same :-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10403#discussion_r1147893495
PR Review Comment: https://git.openjdk.org/jdk/pull/10403#discussion_r1147893791

From kbarrett at openjdk.org  Fri Mar 24 18:11:23 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 24 Mar 2023 18:11:23 GMT
Subject: RFR: 8298725: Add BitMap support for reverse iteration
In-Reply-To: <kOl2lglc-BsZ_-kToAplzPsdxLnqed0YmehMbrd0pVk=.8e545e7c-aa92-4615-9a48-a80a3e64bb94@github.com>
References: <5usc17TaIE2tQRj8IE58fBtVpXCNSxIp-nPQBzJlrmg=.a0620419-86c9-4a56-9ac7-9d317f07ea5e@github.com>
 <kOl2lglc-BsZ_-kToAplzPsdxLnqed0YmehMbrd0pVk=.8e545e7c-aa92-4615-9a48-a80a3e64bb94@github.com>
Message-ID: <-ZtjBDzwq0ovJAUb8wXOmzckAvYvitlaLAsk2BxOHOU=.eb7196d1-b24d-4de8-9e04-a1bbc291c1b2@github.com>

On Thu, 23 Mar 2023 08:07:36 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Please review this addition of BitMap::reverse_iterate, which is like
>> BitMap::iterate but visits the set bits in a range from high index to low.
>> 
>> Testing:
>> mach5 tier1, which includes running the updated gtests on all Oracle-supported
>> platform
>
> lgtm.

Thanks for reviews @xmas92 , @stefank , and @tschatzl .

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13151#issuecomment-1483216998

From kbarrett at openjdk.org  Fri Mar 24 18:22:29 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 24 Mar 2023 18:22:29 GMT
Subject: RFR: 8298725: Add BitMap support for reverse iteration [v2]
In-Reply-To: <5usc17TaIE2tQRj8IE58fBtVpXCNSxIp-nPQBzJlrmg=.a0620419-86c9-4a56-9ac7-9d317f07ea5e@github.com>
References: <5usc17TaIE2tQRj8IE58fBtVpXCNSxIp-nPQBzJlrmg=.a0620419-86c9-4a56-9ac7-9d317f07ea5e@github.com>
Message-ID: <8DHqDfBwgSu10HYkCiI8_J36ArCImkfYtCNn9jJTdw8=.f0a65f34-e8a2-49ca-b071-444df12d2fab@github.com>

> Please review this addition of BitMap::reverse_iterate, which is like
> BitMap::iterate but visits the set bits in a range from high index to low.
> 
> Testing:
> mach5 tier1, which includes running the updated gtests on all Oracle-supported
> platform

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 bitmap-rev-iterate
 - add reverse_iterate

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13151/files
  - new: https://git.openjdk.org/jdk/pull/13151/files/d52a34fb..30462f8b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13151&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13151&range=00-01

  Stats: 7411 lines in 158 files changed: 1758 ins; 5049 del; 604 mod
  Patch: https://git.openjdk.org/jdk/pull/13151.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13151/head:pull/13151

PR: https://git.openjdk.org/jdk/pull/13151

From kbarrett at openjdk.org  Fri Mar 24 18:22:31 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 24 Mar 2023 18:22:31 GMT
Subject: Integrated: 8298725: Add BitMap support for reverse iteration
In-Reply-To: <5usc17TaIE2tQRj8IE58fBtVpXCNSxIp-nPQBzJlrmg=.a0620419-86c9-4a56-9ac7-9d317f07ea5e@github.com>
References: <5usc17TaIE2tQRj8IE58fBtVpXCNSxIp-nPQBzJlrmg=.a0620419-86c9-4a56-9ac7-9d317f07ea5e@github.com>
Message-ID: <j29IzuG8rAqE8DZ2BZZE0qTnZ_t3WfxGcOkgVwyFWVM=.fad28de6-a93e-435a-bd93-034ace6c55d3@github.com>

On Wed, 22 Mar 2023 22:51:05 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this addition of BitMap::reverse_iterate, which is like
> BitMap::iterate but visits the set bits in a range from high index to low.
> 
> Testing:
> mach5 tier1, which includes running the updated gtests on all Oracle-supported
> platform

This pull request has now been integrated.

Changeset: 501b6068
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/501b606816e73e4e2356b3ac218720d8fbae9860
Stats:     140 lines in 3 files changed: 116 ins; 13 del; 11 mod

8298725: Add BitMap support for reverse iteration

Reviewed-by: stefank, aboldtch, tschatzl

-------------

PR: https://git.openjdk.org/jdk/pull/13151

From rrich at openjdk.org  Fri Mar 24 18:45:13 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Fri, 24 Mar 2023 18:45:13 GMT
Subject: RFR: 8296440: Remove Method* handling from
 cleanup_inline_caches_impl [v4]
In-Reply-To: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
References: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
Message-ID: <cRC5U64EXBeJ2dCAVsRgxVyhmrljJE0olhuFUOLsda8=.158645d2-79d5-477e-9f30-311662c85384@github.com>

> This PR replaces cleaning of static stubs in CompiledMethod::cleanup_inline_caches_impl() with a guarantee that it is actually not needed because the holder of the embedded target Method* is alive if the caller nmethod is not unloading.
> 
> The holder of the target Method* has to be alive because it is reachable from the caller nmethod's oop pool. This is checked by `check_path_to_callee()` when a statically bound call gets resolved.
> 
> C2i entry barriers can be removed for the same reason.
> 
> Testing:
> 
> Many rounds in our CI testing which includes most JCK and JTREG tests, Renaissance benchmark and SAP specific tests with fastdebug and release builds on the standard platforms plus PPC64.
> 
> I've also done tier1 and tier2 tests with -XX:-Inline and tier1 tests with ZGC.
> 
> I've started hotspot and jdk tier1 tests with -Xcomp. They were not finished when I stopped them after 24h.

Richard Reingruber has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Merge branch 'master'
 - Fix
 - Feedback Coleene
 - Adding TestStaticallyBoundTargetIsReachable.java
 - Path to target exists also if the receiver is a constant of the caller
 - Use nmethod::oops_do() to search for to_holder in from_nm
 - Merge branch 'master'
 - Remove MacroAssembler::resolve_weak_handle()
 - Remove keep_alive_offset() and holder_offset() from CLD
 - Remove MacroAssembler::load_method_holder_cld()
 - ... and 2 more: https://git.openjdk.org/jdk/compare/4154a980...31bcdb07

-------------

Changes: https://git.openjdk.org/jdk/pull/12802/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12802&range=03
  Stats: 740 lines in 30 files changed: 433 ins; 285 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/12802.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12802/head:pull/12802

PR: https://git.openjdk.org/jdk/pull/12802

From rrich at openjdk.org  Fri Mar 24 18:45:17 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Fri, 24 Mar 2023 18:45:17 GMT
Subject: RFR: 8296440: Remove Method* handling from
 cleanup_inline_caches_impl [v3]
In-Reply-To: <Jl4636WaRF28mQZl6gK1Q4a44CyRJLX-2X3N5RPeKd0=.e4d9606d-c027-419a-b977-ce60e4487a79@github.com>
References: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
 <Jl4636WaRF28mQZl6gK1Q4a44CyRJLX-2X3N5RPeKd0=.e4d9606d-c027-419a-b977-ce60e4487a79@github.com>
Message-ID: <-paL9NK7ir2WiwjEQXA097MYoGQagfrxyYL3Y5dgLLI=.23388838-8036-465c-b963-1b515141b75e@github.com>

On Tue, 21 Mar 2023 17:04:56 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> This PR replaces cleaning of static stubs in CompiledMethod::cleanup_inline_caches_impl() with a guarantee that it is actually not needed because the holder of the embedded target Method* is alive if the caller nmethod is not unloading.
>> 
>> The holder of the target Method* has to be alive because it is reachable from the caller nmethod's oop pool. This is checked by `check_path_to_callee()` when a statically bound call gets resolved.
>> 
>> C2i entry barriers can be removed for the same reason.
>> 
>> Testing:
>> 
>> Many rounds in our CI testing which includes most JCK and JTREG tests, Renaissance benchmark and SAP specific tests with fastdebug and release builds on the standard platforms plus PPC64.
>> 
>> I've also done tier1 and tier2 tests with -XX:-Inline and tier1 tests with ZGC.
>> 
>> I've started hotspot and jdk tier1 tests with -Xcomp. They were not finished when I stopped them after 24h.
>
> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback Coleene

The tests failed because `java_lang_ClassLoader::isAncestor()` must not be called for the boot loader. Protection against this got lost with the refactoring of the last change (https://github.com/openjdk/jdk/pull/12802/commits/2c2e49b5a01cd58d6f922ce105964c083ee18bfb)

So while the boot loader never needs an explicit dependency to the holder of an ordinary class (afaik) because it never delegates loading, it does have explicit dependencies to classes with class mirror holder (e.g. java.lang.invoke.LambdaForm$MH/0x0000000800082800). Therefore checking CLD dependencies cannot be skipped in `check_path_to_callee()` if `from_cld` should be the boot loader cld. Instead the `isAncestor()` call is only done if `from_cld` isn't the boot loader. `isAncestor()` could also be changed to return false if the first arg is the boot loader by simply converting the do-while-loop into a while-loop but then it wouldn't be a verbatim copy from ClassLoader.java anymore.

One test failed in GHA. This is hardly related to these changes:


TEST: jdk/internal/misc/ThreadFlock/ThreadFlockTest.java#platform
[...]
org.opentest4j.AssertionFailedError: Duration 5556ms, expected <= 4000ms ==> expected: <true> but was: <false>
	at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55)
	at org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:40)
	at org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:210)
	at ThreadFlockTest.checkDuration(ThreadFlockTest.java:1090)
	at ThreadFlockTest.testAwaitAllWithTimeout1(ThreadFlockTest.java:431)
[...]

Still in draft mode until local CI tests have finished.
(That'll take 24h. Last night the patch wasn't tested because of a conflict after NULL->nullptr conversion)

No issues in test.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12802#issuecomment-1479716413
PR Comment: https://git.openjdk.org/jdk/pull/12802#issuecomment-1480790983
PR Comment: https://git.openjdk.org/jdk/pull/12802#issuecomment-1480883996
PR Comment: https://git.openjdk.org/jdk/pull/12802#issuecomment-1483252788

From jcking at openjdk.org  Fri Mar 24 18:48:26 2023
From: jcking at openjdk.org (Justin King)
Date: Fri, 24 Mar 2023 18:48:26 GMT
Subject: RFR: JDK-8304539: Cleanup
 utilities/{count_leading_zeros, count_trailing_zeros,
 population_count}.hpp [v11]
In-Reply-To: <Ly_ZIg1wqoqnEy0N-YFdQaEpGg7Er8Vtj8phZQhgAw0=.4d9b54db-517e-491e-a376-623139808b7e@github.com>
References: <Ly_ZIg1wqoqnEy0N-YFdQaEpGg7Er8Vtj8phZQhgAw0=.4d9b54db-517e-491e-a376-623139808b7e@github.com>
Message-ID: <rUlH_-waKfBt8vGLNUoa8oK7D7k8pbXM7rhsMloHJT0=.0885e10e-fc69-4eb9-ac01-c91dfab59640@github.com>

> As the title says, cleanup the mentioned headers. This is similar to `byteswap.hpp` and removes the extraneous `#ifdef` for XLC since it is really just Clang now.

Justin King has updated the pull request incrementally with one additional commit since the last revision:

  Update Visual Studio
  
  Signed-off-by: Justin King <jcking at google.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13103/files
  - new: https://git.openjdk.org/jdk/pull/13103/files/1bc46ffa..167781b9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13103&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13103&range=09-10

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13103.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13103/head:pull/13103

PR: https://git.openjdk.org/jdk/pull/13103

From coleenp at openjdk.org  Fri Mar 24 18:57:41 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 24 Mar 2023 18:57:41 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v13]
In-Reply-To: <k8l6dEqbMu9z7cTiJVwynq0oSXBVU7v2tcAvhfs6hUk=.fbf07c48-db3f-4fd0-a1cd-1c4773ee6f22@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <k8l6dEqbMu9z7cTiJVwynq0oSXBVU7v2tcAvhfs6hUk=.fbf07c48-db3f-4fd0-a1cd-1c4773ee6f22@github.com>
Message-ID: <rrbsKbj0kvmaFTi480GwirAQPpqjWBO0CHZ5FfGZJBs=.d9dc0e72-45b7-44f8-90db-7410710359ef@github.com>

On Fri, 24 Mar 2023 15:13:40 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
>> 
>> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
>> 
>> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
>> 
>> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
>> 
>> This change supports the following platforms: x86, aarch64, PPC, and RISCV
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improved interpreter comments aarch64

Still looks good to me.

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12778#pullrequestreview-1357273317

From cjplummer at openjdk.org  Fri Mar 24 19:20:38 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 24 Mar 2023 19:20:38 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v5]
In-Reply-To: <0J5IbRtwgK7aOiXWfWBSVLo0RniWf6rRfvqmqA59j5A=.a7cf4ca2-a750-4281-9c78-285ca58e21da@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <27JLa60WeywSMcJj-6KfaQD8RBnwBbAvcc0gecc-3h4=.a2a25b70-9e90-4551-af90-35aed3d57b59@github.com>
 <qVfNBfPP6pizIr16-aXD851jbQ8ZNOV7BvH_Yt-jrbo=.d22c7807-c952-4337-ae69-60a8070ad852@github.com>
 <0J5IbRtwgK7aOiXWfWBSVLo0RniWf6rRfvqmqA59j5A=.a7cf4ca2-a750-4281-9c78-285ca58e21da@github.com>
Message-ID: <QFUF6VyM9-muaNFtSOi4txCaieDrNYmTejKGR5rk-Lw=.de2d5d71-60c1-4d7d-8c9a-1131415c9725@github.com>

On Fri, 24 Mar 2023 00:23:19 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest.java line 68:
>> 
>>> 66:             if (n <= 0) {
>>> 67:                 n = 1000;
>>> 68:                 ToggleNotifyJvmtiTest.sleep(1);
>> 
>> It looks like you do this short sleep 1 out of every 1,000,000 iterations. Can you explain why?
>
> It is for yielding. Do you think we need this with a bigger frequency?

I guess the question then is why the need to yield. It just seems a bit odd that I thought the main point of this loop was to keep busy calling `breakpointCheck()`, and I don't see how doing a yield 1 out of every 1,000,000 iterations relates to that.

>> test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest.java line 72:
>> 
>>> 70:             if (i > n) {
>>> 71:                 i = 0;
>>> 72:                 n = n - 1;
>> 
>> n--
>
> This code was copied originally from the vmTestbase to SuspendThread* tests and some other tests.
> I can do all suggested simplifications but not sure if it is really necessary.
> It does not matter what exactly the method does because it just simulates some thread activity.
> Would it better to keep copy/pasted methods the same?

ok

>> test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest.java line 148:
>> 
>>> 146: 
>>> 147:     static private void setVirtualThreadsNotifyJvmtiMode(int iter, boolean enable) {
>>> 148:         sleep(5);
>> 
>> Why is this needed?
>
> It is needed to balance enabling/disabling notifyJvmti mode with the ThreadStart/VirtualThreadStart events.
> Otherwise, many mode switches can be observed without any events which is not interesting.
> We need to allow virtual threads to execute a little bit after a mode switch.

Shouldn't that be the caller's responsibility? Including a comment would be helpful.

>> test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest.java line 161:
>> 
>>> 159:             vm.loadAgentLibrary(AGENT_LIB, arg);
>>> 160:         } else {
>>> 161:             System.loadLibrary(AGENT_LIB);
>> 
>> Why is this needed? Isn't the library already loaded due to it being specified by `-agentlib`?
>
> Good question. We almost always do it in the JVMTI tests including `serviceability/jvmti/vthread` and `vmTestbase/nsk/jvmti` tests. Examples are 22 `serviceability/jvmti/vthread` tests.

Are you saying it's not needed, but you included it to be consistent with other tests?

>> test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest.java line 171:
>> 
>>> 169:         sleep(20);
>>> 170: 
>>> 171:         for (int iter = 0; VirtualThreadStartedCount() < VTHREADS_CNT; iter++) {
>> 
>> The test seems to exit once all the threads are started. I would think you would want it to run for a while after all the threads are started.
>
> I'm not sure if it is really needed. 60 virtual threads are started.
> Some of them are executed long enough before shutdown.
> We can just increase the number of threads if necessary.

ok

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1147966083
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1147966677
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1147969519
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1147969967
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1147970566

From kvn at openjdk.org  Fri Mar 24 19:46:36 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 24 Mar 2023 19:46:36 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v4]
In-Reply-To: <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com>
Message-ID: <figDCuWUFwMCXvDoIxOtcmOaqb_3a7PLZUEQg75Jmws=.3f991293-94d1-4843-8da3-cf97d79c47be@github.com>

On Mon, 20 Mar 2023 19:23:34 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> Can I please get reviews for this PR? 
>> 
>> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested.
>> 
>> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N:
>> 
>> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png)
>> 
>> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1:
>> 
>> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png)
>> 
>> This PR adds support scalar replacing allocations participating in merges that are used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently.
>> 
>> The approach I used for _rematerialization_ is pretty straightforward. It consists basically in: 1) Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a new Class to support rematerialization of SR objects part of merges; 3) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 4) Patch C2 to generate unique types for SR objects participating in some allocation merges.
>> 
>> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straight forward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless.
>> 
>> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also tested with several applications and didn't see any failure. I also run tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add support for SR'ing some inputs of merges used for field loads

Initial review.

src/hotspot/share/code/debugInfo.hpp line 199:

> 197: // ObjectValue describing an object that was scalar replaced.
> 198: 
> 199: class ObjectMergeValue: public ScopeValue {

Why you did not make subclass of ObjectValue? You would need to check `sv->is_object_merge()` first before `sv->is_object()` in few places. But on other hand you don't need to duplicates ObjectValue`s fields and asserts.

src/hotspot/share/opto/callnode.cpp line 1479:

> 1477: #ifdef ASSERT
> 1478:   _alloc(alloc),
> 1479: #endif

May be we should always pass alloc, even in product VM. It is not related to your changes but it is pain to have.

src/hotspot/share/opto/callnode.hpp line 511:

> 509: // by a SafePoint; 2) A scalar replaced object is participating in an allocation
> 510: // merge (Phi) and the Phi is referenced by a SafePoint. The schematics of how
> 511: // 'spobj' is used in both scenarios are described below.

I am not comfortable with reusing SafePointScalarObjectNode for 2) since it describes totally different information.
I think it should be separate Node which points to array of  SFSO  id (in addition to Phis) similar how we do now if SFSO is referenced in other SFSO's field.   SFSO could be created before the merge. Consider:

  Point p = new Point();
  Point q = foo();
  if (cond) {
      q = p;
  }
  trap(p, q);

src/hotspot/share/opto/callnode.hpp line 519:

> 517: //   _nfields     : how many fields the SR object has.
> 518: //   _alloc       : pointer to the Allocate object that previously created the SR object.
> 519: //                  Only used for debug purposes.

May be useful in other cases too in a future not only in debug.

src/hotspot/share/opto/macro.hpp line 196:

> 194:                           Node* size_in_bytes);
> 195: 
> 196:   static Node* make_arraycopy_load(Compile* comp, PhaseIterGVN* igvn, ArrayCopyNode* ac, intptr_t offset, Node* ctl, Node* mem, BasicType ft, const Type *ftype, AllocateNode *alloc);

Why you need this change? It polluted diffs and hide important changes. Could be separate change from this one.

-------------

PR Review: https://git.openjdk.org/jdk/pull/12897#pullrequestreview-1357285068
PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1147961058
PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1147963487
PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1147991641
PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1147965112
PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1147973203

From kvn at openjdk.org  Fri Mar 24 19:47:30 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 24 Mar 2023 19:47:30 GMT
Subject: RFR: JDK-8304828: Lots of constant static data not declared static
 const in cpu/x86
In-Reply-To: <7KzH7QPu53lViaVf5yIBoJ7hxpvBIK9iZP-L5EVH8U4=.0935258a-29ba-43b5-a845-1201be6dface@github.com>
References: <7KzH7QPu53lViaVf5yIBoJ7hxpvBIK9iZP-L5EVH8U4=.0935258a-29ba-43b5-a845-1201be6dface@github.com>
Message-ID: <IhV9yhRFxEMoGpH79dfhTjm7u7cfV9Dhg9X3qrcseSE=.723331c6-af29-4ae1-a6a2-a5ab7ba286db@github.com>

On Thu, 23 Mar 2023 17:31:26 GMT, Justin King <jcking at openjdk.org> wrote:

> Simple refactor that updates declarations and definitions for data that is effectively static and constant to be `static` and/or `const`. Helps make sure we do not break the one definition rule and helps the compiler/linker to place the data in read-only sections of the executable.

My testing passed.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13163#pullrequestreview-1357332846

From xliu at openjdk.org  Fri Mar 24 19:56:32 2023
From: xliu at openjdk.org (Xin Liu)
Date: Fri, 24 Mar 2023 19:56:32 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v4]
In-Reply-To: <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com>
Message-ID: <OlB0qzAQmWd4mmE2RymaDf7VJ8fjTthhVMFcTC4SFAU=.95b0e982-db39-4fee-afe2-3a845eb38f7c@github.com>

On Mon, 20 Mar 2023 19:23:34 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> Can I please get reviews for this PR? 
>> 
>> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested.
>> 
>> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N:
>> 
>> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png)
>> 
>> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1:
>> 
>> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png)
>> 
>> This PR adds support scalar replacing allocations participating in merges that are used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently.
>> 
>> The approach I used for _rematerialization_ is pretty straightforward. It consists basically in: 1) Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a new Class to support rematerialization of SR objects part of merges; 3) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 4) Patch C2 to generate unique types for SR objects participating in some allocation merges.
>> 
>> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straight forward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless.
>> 
>> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also tested with several applications and didn't see any failure. I also run tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add support for SR'ing some inputs of merges used for field loads

src/hotspot/share/opto/callnode.hpp line 614:

> 612:   int merge_pointer_idx(JVMState* jvms) const {
> 613:     assert(jvms != nullptr, "JVMS reference is null.");
> 614:     return jvms->scloff() + _merge_pointer_idx;

how about we also assert is_from_merge() here? 

Your comment above says that _merge_point_idx is a zero-based index of sfpt's input array. 
here we use scloff-based. I think either is okay, but we need consistency.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1148000014

From mdoerr at openjdk.org  Fri Mar 24 22:21:38 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 24 Mar 2023 22:21:38 GMT
Subject: RFR: 8296440: Remove Method* handling from
 cleanup_inline_caches_impl [v4]
In-Reply-To: <cRC5U64EXBeJ2dCAVsRgxVyhmrljJE0olhuFUOLsda8=.158645d2-79d5-477e-9f30-311662c85384@github.com>
References: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
 <cRC5U64EXBeJ2dCAVsRgxVyhmrljJE0olhuFUOLsda8=.158645d2-79d5-477e-9f30-311662c85384@github.com>
Message-ID: <UxvqomocqvORKJec5QOn8MLutk4H6h0TW0tdUzYzCWk=.961d2c75-485f-415a-abf4-b970dac1a22b@github.com>

On Fri, 24 Mar 2023 18:45:13 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> This PR replaces cleaning of static stubs in CompiledMethod::cleanup_inline_caches_impl() with a guarantee that it is actually not needed because the holder of the embedded target Method* is alive if the caller nmethod is not unloading.
>> 
>> The holder of the target Method* has to be alive because it is reachable from the caller nmethod's oop pool. This is checked by `check_path_to_callee()` when a statically bound call gets resolved.
>> 
>> C2i entry barriers can be removed for the same reason.
>> 
>> Testing:
>> 
>> Many rounds in our CI testing which includes most JCK and JTREG tests, Renaissance benchmark and SAP specific tests with fastdebug and release builds on the standard platforms plus PPC64.
>> 
>> I've also done tier1 and tier2 tests with -XX:-Inline and tier1 tests with ZGC.
>> 
>> I've started hotspot and jdk tier1 tests with -Xcomp. They were not finished when I stopped them after 24h.
>
> Richard Reingruber has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Merge branch 'master'
>  - Fix
>  - Feedback Coleene
>  - Adding TestStaticallyBoundTargetIsReachable.java
>  - Path to target exists also if the receiver is a constant of the caller
>  - Use nmethod::oops_do() to search for to_holder in from_nm
>  - Merge branch 'master'
>  - Remove MacroAssembler::resolve_weak_handle()
>  - Remove keep_alive_offset() and holder_offset() from CLD
>  - Remove MacroAssembler::load_method_holder_cld()
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/4154a980...31bcdb07

Thanks for the updates! I think it's good for another spin.

-------------

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12802#pullrequestreview-1357519048

From aph at openjdk.org  Fri Mar 24 22:31:40 2023
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 24 Mar 2023 22:31:40 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v13]
In-Reply-To: <k8l6dEqbMu9z7cTiJVwynq0oSXBVU7v2tcAvhfs6hUk=.fbf07c48-db3f-4fd0-a1cd-1c4773ee6f22@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <k8l6dEqbMu9z7cTiJVwynq0oSXBVU7v2tcAvhfs6hUk=.fbf07c48-db3f-4fd0-a1cd-1c4773ee6f22@github.com>
Message-ID: <XWLQOK2Bj9FAMA04vyFfxZ-GykAeqQNlCFMhYCbpPwg=.4f1c8608-b46c-4afd-972e-a0d479f2f10d@github.com>

On Fri, 24 Mar 2023 15:13:40 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
>> 
>> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
>> 
>> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
>> 
>> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
>> 
>> This change supports the following platforms: x86, aarch64, PPC, and RISCV
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improved interpreter comments aarch64

AArch64 looks good. Thank you.

-------------

Marked as reviewed by aph (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12778#pullrequestreview-1357525728

From jcking at openjdk.org  Fri Mar 24 23:10:09 2023
From: jcking at openjdk.org (Justin King)
Date: Fri, 24 Mar 2023 23:10:09 GMT
Subject: RFR: JDK-8304539: Cleanup
 utilities/{count_leading_zeros, count_trailing_zeros,
 population_count}.hpp [v12]
In-Reply-To: <Ly_ZIg1wqoqnEy0N-YFdQaEpGg7Er8Vtj8phZQhgAw0=.4d9b54db-517e-491e-a376-623139808b7e@github.com>
References: <Ly_ZIg1wqoqnEy0N-YFdQaEpGg7Er8Vtj8phZQhgAw0=.4d9b54db-517e-491e-a376-623139808b7e@github.com>
Message-ID: <evxHHCbfTbu6Tw1YSeoYvIOzCaN4c2TsFrBmIgS1sPw=.b775b28b-eee5-4422-9256-bf716ca78f09@github.com>

> As the title says, cleanup the mentioned headers. This is similar to `byteswap.hpp` and removes the extraneous `#ifdef` for XLC since it is really just Clang now.

Justin King has updated the pull request incrementally with one additional commit since the last revision:

  _CountOneBits is broken on Visual Studio before 2022
  
  Signed-off-by: Justin King <jcking at google.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13103/files
  - new: https://git.openjdk.org/jdk/pull/13103/files/167781b9..668fb06e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13103&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13103&range=10-11

  Stats: 24 lines in 2 files changed: 0 ins; 20 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/13103.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13103/head:pull/13103

PR: https://git.openjdk.org/jdk/pull/13103

From kvn at openjdk.org  Fri Mar 24 23:21:34 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 24 Mar 2023 23:21:34 GMT
Subject: RFR: 8296440: Remove Method* handling from
 cleanup_inline_caches_impl [v4]
In-Reply-To: <cRC5U64EXBeJ2dCAVsRgxVyhmrljJE0olhuFUOLsda8=.158645d2-79d5-477e-9f30-311662c85384@github.com>
References: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
 <cRC5U64EXBeJ2dCAVsRgxVyhmrljJE0olhuFUOLsda8=.158645d2-79d5-477e-9f30-311662c85384@github.com>
Message-ID: <SJ78GTQ4oW7pTuSJXBtmWwwWPGu0RsX_8PGLJUNYNY8=.a5779789-7abd-443a-9bf4-763739d77b10@github.com>

On Fri, 24 Mar 2023 18:45:13 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> This PR replaces cleaning of static stubs in CompiledMethod::cleanup_inline_caches_impl() with a guarantee that it is actually not needed because the holder of the embedded target Method* is alive if the caller nmethod is not unloading.
>> 
>> The holder of the target Method* has to be alive because it is reachable from the caller nmethod's oop pool. This is checked by `check_path_to_callee()` when a statically bound call gets resolved.
>> 
>> C2i entry barriers can be removed for the same reason.
>> 
>> Testing:
>> 
>> Many rounds in our CI testing which includes most JCK and JTREG tests, Renaissance benchmark and SAP specific tests with fastdebug and release builds on the standard platforms plus PPC64.
>> 
>> I've also done tier1 and tier2 tests with -XX:-Inline and tier1 tests with ZGC.
>> 
>> I've started hotspot and jdk tier1 tests with -Xcomp. They were not finished when I stopped them after 24h.
>
> Richard Reingruber has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Merge branch 'master'
>  - Fix
>  - Feedback Coleene
>  - Adding TestStaticallyBoundTargetIsReachable.java
>  - Path to target exists also if the receiver is a constant of the caller
>  - Use nmethod::oops_do() to search for to_holder in from_nm
>  - Merge branch 'master'
>  - Remove MacroAssembler::resolve_weak_handle()
>  - Remove keep_alive_offset() and holder_offset() from CLD
>  - Remove MacroAssembler::load_method_holder_cld()
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/4154a980...31bcdb07

Started new testing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12802#issuecomment-1483568662

From cslucas at openjdk.org  Fri Mar 24 23:29:29 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Fri, 24 Mar 2023 23:29:29 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v4]
In-Reply-To: <figDCuWUFwMCXvDoIxOtcmOaqb_3a7PLZUEQg75Jmws=.3f991293-94d1-4843-8da3-cf97d79c47be@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com>
 <figDCuWUFwMCXvDoIxOtcmOaqb_3a7PLZUEQg75Jmws=.3f991293-94d1-4843-8da3-cf97d79c47be@github.com>
Message-ID: <0UbMqMHtVIayPdJMmfDF6YTadWe4YTlSW6mZc5P3IU8=.c4b1a292-e434-4c57-a5cd-015edca2ec95@github.com>

On Fri, 24 Mar 2023 19:06:18 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add support for SR'ing some inputs of merges used for field loads
>
> src/hotspot/share/opto/callnode.cpp line 1479:
> 
>> 1477: #ifdef ASSERT
>> 1478:   _alloc(alloc),
>> 1479: #endif
> 
> May be we should always pass alloc, even in product VM. It is not related to your changes but it is pain to have.

I can make that change.

> src/hotspot/share/opto/macro.hpp line 196:
> 
>> 194:                           Node* size_in_bytes);
>> 195: 
>> 196:   static Node* make_arraycopy_load(Compile* comp, PhaseIterGVN* igvn, ArrayCopyNode* ac, intptr_t offset, Node* ctl, Node* mem, BasicType ft, const Type *ftype, AllocateNode *alloc);
> 
> Why you need this change? It polluted diffs and hide important changes. Could be separate change from this one.

I had to make this method static because it uses `value_from_mem` - which I also made static. I had to make `value_from_mem` static so that I can use it outside PhaseMacroExpand.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1148141099
PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1148140607

From kvn at openjdk.org  Fri Mar 24 23:40:31 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 24 Mar 2023 23:40:31 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v4]
In-Reply-To: <0UbMqMHtVIayPdJMmfDF6YTadWe4YTlSW6mZc5P3IU8=.c4b1a292-e434-4c57-a5cd-015edca2ec95@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com>
 <figDCuWUFwMCXvDoIxOtcmOaqb_3a7PLZUEQg75Jmws=.3f991293-94d1-4843-8da3-cf97d79c47be@github.com>
 <0UbMqMHtVIayPdJMmfDF6YTadWe4YTlSW6mZc5P3IU8=.c4b1a292-e434-4c57-a5cd-015edca2ec95@github.com>
Message-ID: <o6msC4bnqaYIl0YQPjv-IPXsHRUbtleyEvcirt5dyog=.56d57ae0-f3bc-4942-942e-066e8fd95856@github.com>

On Fri, 24 Mar 2023 23:24:47 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> src/hotspot/share/opto/macro.hpp line 196:
>> 
>>> 194:                           Node* size_in_bytes);
>>> 195: 
>>> 196:   static Node* make_arraycopy_load(Compile* comp, PhaseIterGVN* igvn, ArrayCopyNode* ac, intptr_t offset, Node* ctl, Node* mem, BasicType ft, const Type *ftype, AllocateNode *alloc);
>> 
>> Why you need this change? It polluted diffs and hide important changes. Could be separate change from this one.
>
> I had to make this method static because it uses `value_from_mem` - which I also made static. I had to make `value_from_mem` static so that I can use it outside PhaseMacroExpand.

I see, you use it in escape.cpp. Okay. I need to review changes there too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1148144963

From cslucas at openjdk.org  Fri Mar 24 23:49:31 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Fri, 24 Mar 2023 23:49:31 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v4]
In-Reply-To: <OlB0qzAQmWd4mmE2RymaDf7VJ8fjTthhVMFcTC4SFAU=.95b0e982-db39-4fee-afe2-3a845eb38f7c@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com>
 <OlB0qzAQmWd4mmE2RymaDf7VJ8fjTthhVMFcTC4SFAU=.95b0e982-db39-4fee-afe2-3a845eb38f7c@github.com>
Message-ID: <9n3UqJDruE0pvA51cFuUGal2gvluNX5LoseLuhvXlIg=.ab6692bd-3aba-4d42-a925-a15ff906677d@github.com>

On Fri, 24 Mar 2023 19:53:52 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add support for SR'ing some inputs of merges used for field loads
>
> src/hotspot/share/opto/callnode.hpp line 614:
> 
>> 612:   int merge_pointer_idx(JVMState* jvms) const {
>> 613:     assert(jvms != nullptr, "JVMS reference is null.");
>> 614:     return jvms->scloff() + _merge_pointer_idx;
> 
> how about we also assert is_from_merge() here? 
> 
> Your comment above says that _merge_point_idx is a zero-based index of sfpt's input array. 
> here we use scloff-based. I think either is okay, but we need consistency.

I think adding assert is a good idea. I'll fix the comment. Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1148148247

From cslucas at openjdk.org  Fri Mar 24 23:59:30 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Fri, 24 Mar 2023 23:59:30 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v4]
In-Reply-To: <figDCuWUFwMCXvDoIxOtcmOaqb_3a7PLZUEQg75Jmws=.3f991293-94d1-4843-8da3-cf97d79c47be@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com>
 <figDCuWUFwMCXvDoIxOtcmOaqb_3a7PLZUEQg75Jmws=.3f991293-94d1-4843-8da3-cf97d79c47be@github.com>
Message-ID: <7xRwVRVapKbqiVQMDMZUh3ILhfaYub_brXWVopFhJ8M=.28289c04-0ff0-4f19-b764-03af4d3155d6@github.com>

On Fri, 24 Mar 2023 19:02:57 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add support for SR'ing some inputs of merges used for field loads
>
> src/hotspot/share/code/debugInfo.hpp line 199:
> 
>> 197: // ObjectValue describing an object that was scalar replaced.
>> 198: 
>> 199: class ObjectMergeValue: public ScopeValue {
> 
> Why you did not make subclass of ObjectValue? You would need to check `sv->is_object_merge()` first before `sv->is_object()` in few places. But on other hand you don't need to duplicates ObjectValue`s fields and asserts.

Let me try that and see how it looks.

> src/hotspot/share/opto/callnode.hpp line 511:
> 
>> 509: // by a SafePoint; 2) A scalar replaced object is participating in an allocation
>> 510: // merge (Phi) and the Phi is referenced by a SafePoint. The schematics of how
>> 511: // 'spobj' is used in both scenarios are described below.
> 
> I am not comfortable with reusing SafePointScalarObjectNode for 2) since it describes totally different information.
> I think it should be separate Node which points to array of  SFSO  id (in addition to Phis) similar how we do now if SFSO is referenced in other SFSO's field.   SFSO could be created before the merge. Consider:
> 
>   Point p = new Point();
>   Point q = foo();
>   if (cond) {
>       q = p;
>   }
>   trap(p, q);

I had considered that but decided not to do it to prevent adding a new IR node. I'll give that a shot and update this thread with how it goes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1148150933
PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1148151474

From kvn at openjdk.org  Sat Mar 25 00:11:31 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sat, 25 Mar 2023 00:11:31 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v4]
In-Reply-To: <7xRwVRVapKbqiVQMDMZUh3ILhfaYub_brXWVopFhJ8M=.28289c04-0ff0-4f19-b764-03af4d3155d6@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com>
 <figDCuWUFwMCXvDoIxOtcmOaqb_3a7PLZUEQg75Jmws=.3f991293-94d1-4843-8da3-cf97d79c47be@github.com>
 <7xRwVRVapKbqiVQMDMZUh3ILhfaYub_brXWVopFhJ8M=.28289c04-0ff0-4f19-b764-03af4d3155d6@github.com>
Message-ID: <gu_ZHFRO-SoFPxYgt-NDukPxS894AwlZQqDPjcRCwl4=.d0b5473e-83f8-42a9-ae38-bed52780fe58@github.com>

On Fri, 24 Mar 2023 23:57:07 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> src/hotspot/share/opto/callnode.hpp line 511:
>> 
>>> 509: // by a SafePoint; 2) A scalar replaced object is participating in an allocation
>>> 510: // merge (Phi) and the Phi is referenced by a SafePoint. The schematics of how
>>> 511: // 'spobj' is used in both scenarios are described below.
>> 
>> I am not comfortable with reusing SafePointScalarObjectNode for 2) since it describes totally different information.
>> I think it should be separate Node which points to array of  SFSO  id (in addition to Phis) similar how we do now if SFSO is referenced in other SFSO's field.   SFSO could be created before the merge. Consider:
>> 
>>   Point p = new Point();
>>   Point q = foo();
>>   if (cond) {
>>       q = p;
>>   }
>>   trap(p, q);
>
> I had considered that but decided not to do it to prevent adding a new IR node. I'll give that a shot and update this thread with how it goes.

It **will** complicate your DebugInfo code (packing/unpacking) information. But I think it is right thing to do to avoid duplicated re-allocations during deoptimization - you should have only one new object.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1148154060

From cslucas at openjdk.org  Sat Mar 25 00:11:34 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Sat, 25 Mar 2023 00:11:34 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v4]
In-Reply-To: <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com>
Message-ID: <UwoDrrNM4KFSPdw6tbIxBAT9VV6fIRjWpOxPU-taB3I=.01986941-4e67-4a54-8235-31dbcb7c5a71@github.com>

On Mon, 20 Mar 2023 19:23:34 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> Can I please get reviews for this PR? 
>> 
>> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested.
>> 
>> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N:
>> 
>> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png)
>> 
>> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1:
>> 
>> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png)
>> 
>> This PR adds support scalar replacing allocations participating in merges that are used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently.
>> 
>> The approach I used for _rematerialization_ is pretty straightforward. It consists basically in: 1) Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a new Class to support rematerialization of SR objects part of merges; 3) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 4) Patch C2 to generate unique types for SR objects participating in some allocation merges.
>> 
>> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straight forward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless.
>> 
>> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also tested with several applications and didn't see any failure. I also run tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add support for SR'ing some inputs of merges used for field loads

src/hotspot/share/opto/escape.cpp line 3734:

> 3732:       if (reducible_merges.member(n)) {
> 3733:         // Split loads through phi
> 3734:         reduce_this_phi_on_field_access(n->as_Phi(), alloc_worklist);

I decided to do the split here so that Phase 1 of `split_unique_types` could assign a new instance type for the new loads created by `split_through_phi`. However, I'm considering doing the split at the end of `compute_escape` instead of here to keep all the code that does split close together.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1148153569

From fyang at openjdk.org  Sat Mar 25 05:14:45 2023
From: fyang at openjdk.org (Fei Yang)
Date: Sat, 25 Mar 2023 05:14:45 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v13]
In-Reply-To: <k8l6dEqbMu9z7cTiJVwynq0oSXBVU7v2tcAvhfs6hUk=.fbf07c48-db3f-4fd0-a1cd-1c4773ee6f22@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <k8l6dEqbMu9z7cTiJVwynq0oSXBVU7v2tcAvhfs6hUk=.fbf07c48-db3f-4fd0-a1cd-1c4773ee6f22@github.com>
Message-ID: <qQQW5bT_xzIYWWVKg98Y-nl2PPZjrke7UU8inhrg5j8=.9a3eefc6-b6ad-4d1c-a50f-72ceeb41c2b4@github.com>

On Fri, 24 Mar 2023 15:13:40 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
>> 
>> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
>> 
>> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
>> 
>> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
>> 
>> This change supports the following platforms: x86, aarch64, PPC, and RISCV
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improved interpreter comments aarch64

Changes requested by fyang (Reviewer).

src/hotspot/cpu/aarch64/templateTable_aarch64.cpp line 2344:

> 2342:   // Compare the method to zero
> 2343:   __ tst(method, method);
> 2344:   __ br(Assembler::NE, resolved);

Consider use 'cbnz' instruction here, like: __ cbnz(method, resolved)

src/hotspot/cpu/aarch64/templateTable_aarch64.cpp line 2360:

> 2358: #ifdef ASSERT
> 2359:   __ tst(method, method);
> 2360:   __ br(Assembler::NE, resolved);

Same here, like: __ cbnz(method, resolved);

src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp line 452:

> 450:   } else {
> 451:     // Pop N words from the stack
> 452:     __ get_cache_and_index_at_bcp(x11, x12, 1, index_size);

Better to use 'cache' and 'index' in this branch instead of 'x11' and 'x12'.

src/hotspot/cpu/riscv/templateTable_riscv.cpp line 2218:

> 2216: }
> 2217: 
> 2218: void TemplateTable::load_invokedynamic_entry(Register method) {

Please also add a comment for this function, like aarch64.

src/hotspot/cpu/riscv/templateTable_riscv.cpp line 2236:

> 2234:   // Compare the method to zero
> 2235:   __ andr(t0, method, method);
> 2236:   __ bnez(t0, resolved);

I think a more simpler "__ bnez(method, resolved)" will do.

src/hotspot/cpu/riscv/templateTable_riscv.cpp line 2243:

> 2241:   address entry = CAST_FROM_FN_PTR(address, InterpreterRuntime::resolve_from_cache);
> 2242:   __ mv(method, code); // this is essentially Bytecodes::_invokedynamic
> 2243:   __ call_VM(noreg, entry, method); // Example uses temp = rbx. In this case rbx is method

Remove the code comment here as we don't have rbx for riscv.

src/hotspot/cpu/riscv/templateTable_riscv.cpp line 2252:

> 2250: #ifdef ASSERT
> 2251:   __ andr(t0, method, method);
> 2252:   __ bnez(t0, resolved);

Consider "__ bnez(method, resolved)".

-------------

PR Review: https://git.openjdk.org/jdk/pull/12778#pullrequestreview-1357775328
PR Review Comment: https://git.openjdk.org/jdk/pull/12778#discussion_r1148305440
PR Review Comment: https://git.openjdk.org/jdk/pull/12778#discussion_r1148305543
PR Review Comment: https://git.openjdk.org/jdk/pull/12778#discussion_r1148305885
PR Review Comment: https://git.openjdk.org/jdk/pull/12778#discussion_r1148306138
PR Review Comment: https://git.openjdk.org/jdk/pull/12778#discussion_r1148306256
PR Review Comment: https://git.openjdk.org/jdk/pull/12778#discussion_r1148306282
PR Review Comment: https://git.openjdk.org/jdk/pull/12778#discussion_r1148306390

From stuefe at openjdk.org  Sat Mar 25 08:58:50 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 25 Mar 2023 08:58:50 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
Message-ID: <GQ69p_sHk_xFKzlHQ1e-r3hWOtedFkiKcPMDUgTdiZk=.f3d32fb3-f1a1-4d04-8ab6-940d7bf738fa@github.com>

On Thu, 16 Mar 2023 20:56:15 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>  - Set condition flags correctly after fast-lock call on aarch64

I have another question about the asymmetric unlocking code in `InterpreterMacroAssembler::unlock_object`.

We go through here for both fast-locked and fat OM locks, right? If so, shouldn't we do the asymmetric lock check only for the fast locked case? Otherwise Lockstack may be empty, so we compare the word preceding the first slot, which would cause us to always break into the slow case?

Sorry if I miss something here.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1483767964

From kbarrett at openjdk.org  Sat Mar 25 15:50:17 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 25 Mar 2023 15:50:17 GMT
Subject: RFR: 8304759: Add BitMap iterators
Message-ID: <4FHjg8u1ix7KodqaJkU5q-tnYRDAq3GhRV0z7ArpYGU=.7434363a-1bcb-467f-9225-0e97d4ade998@github.com>

Please review this change which adds iteration over the set bit positions of a
BitMap via an iterator object.  This is in addition to the existing iterate()
and reverse_iterate() functions that apply a function to the set bit positions.

There are two iterator classes: BitMap::Iterator and BitMap::ReverseIterator.
Iteration uses a single, self-contained iterator object, rather than a pair of
iterator objects as is done with standard library iterators.  This is because
the desired form of iteration over bitmaps doesn't lend itself well to the
begin/end pair style.  Typical usage is something like


for (BitMap::Iterator it{map, beg, end}; !it.is_empty(); it.step()) {
  ... use it.index()
}


However, as a syntactic convenience, these iterator classes provide begin()
and end() member functions returning objects supporting the requirements for
range-based for loops.  By constraining these objects to this usage we can
cope with the "iterator pair" requirements.  Usage is something like


for (BitMap::idx_t index : BitMap::Iterator{map, beg, end}) {
  ...
}


Testing:
mach5 tier1, which includes running the updated gtests on all Oracle-supported
platforms.

-------------

Commit messages:
 - bitmap iterators

Changes: https://git.openjdk.org/jdk/pull/13184/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13184&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304759
  Stats: 369 lines in 4 files changed: 369 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13184.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13184/head:pull/13184

PR: https://git.openjdk.org/jdk/pull/13184

From stuefe at openjdk.org  Sat Mar 25 16:33:51 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 25 Mar 2023 16:33:51 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <S3HAUfb2-rymMhcE0b5Uwycc6LpZHCnHRVHXL0141IU=.20c872ab-a4c1-4d40-b33b-a83f9f388cd1@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
 <S3HAUfb2-rymMhcE0b5Uwycc6LpZHCnHRVHXL0141IU=.20c872ab-a4c1-4d40-b33b-a83f9f388cd1@github.com>
Message-ID: <aWMiL51FVgdKbT_otV-s9tKx1wfdA5iVp7QN8wyeJS4=.a2271fe3-de20-4b8a-b022-3edb5b5e1878@github.com>

On Thu, 23 Mar 2023 16:32:57 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>>  - Set condition flags correctly after fast-lock call on aarch64
>
> Is anybody familiar with the academic literature on this topic? I am sure I am not the first person which has come up with this form of locking. Maybe we could use a name that refers to some academic paper?

@rkennke Would you mind integrating these changes to LockStack: https://github.com/tstuefe/jdk/tree/10907%2Blockstack-veris

Mainly lockstack wiping unused slots on pop, more verifications and better output.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1483864128

From eliu at openjdk.org  Sun Mar 26 15:38:37 2023
From: eliu at openjdk.org (Eric Liu)
Date: Sun, 26 Mar 2023 15:38:37 GMT
Subject: RFR: 8301012: [vectorapi]: Intrinsify CompressBitsV/ExpandBitsV
 and add the AArch64 SVE backend implementation [v2]
In-Reply-To: <hGNqy06rxKagknty5mHqKfplZGqBBKoOfLdWQfml8Nc=.c2c399b7-2013-4156-94bf-96d70d0274b9@github.com>
References: <RaPIEa3D1wT6isue-1l_ILYJ6FCWSeNJ-T8QXtoxnUk=.05a804b5-9b2f-4486-aad4-53f00a3a6ab3@github.com>
 <WepLX4oA_2sxHK2IzxZPuCSw126ydVMIkLrQFlwBxhI=.1c20c2fe-62c7-4576-a7f5-bdbfa1055214@github.com>
 <hGNqy06rxKagknty5mHqKfplZGqBBKoOfLdWQfml8Nc=.c2c399b7-2013-4156-94bf-96d70d0274b9@github.com>
Message-ID: <X4bQt2hguG51C1wwLjzDjulbILVwwXTs6Xuy9G_Qrac=.09983969-20d7-43af-8a0f-95fe22067d74@github.com>

On Fri, 24 Mar 2023 12:10:43 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> I'm not an expert in SVE and we don't have the corresponding hardware to test this. But the changes look reasonable to me and pass our testing.

A typical "team-working" review :P

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12446#issuecomment-1484133570

From alexandr.miloslavskiy at syntevo.com  Sun Mar 26 16:18:00 2023
From: alexandr.miloslavskiy at syntevo.com (Alexandr Miloslavskiy)
Date: Sun, 26 Mar 2023 19:18:00 +0300
Subject: crash logs without stack trace
In-Reply-To: <14C16303-1377-4968-93C8-B5347ACF806F@jetbrains.com>
References: <14C16303-1377-4968-93C8-B5347ACF806F@jetbrains.com>
Message-ID: <d09f8ffa-1a45-4b0a-c2e3-e17716e208ec@syntevo.com>

> Actually we are stuck on reading such crash logs in order to find out crash causes and would appreciate for any clues related to these issues.

I can see that "code" being executed is not even code but some data 
(it's enough to look at disasm and see a lot of zeroes, which is not 
typical for actual machine code).

Now how RIP register ended up pointing to wrong location is a mystery.
But this hints why Java got confused and wasn't able to unwind the stack.

It would be useful to capture more data about the crash:
1. Add -XX:+CreateCoredumpOnCrash option
2. Reproduce the crash, compress into 7-zip and share the dump
3. Note that the dump will contain all of the process's memory at the 
moment of crash, so for privacy reasons, reproduce it on something that 
can be shared without problems, with no passwords etc loaded into 
running program

From kvn at openjdk.org  Sun Mar 26 17:55:33 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sun, 26 Mar 2023 17:55:33 GMT
Subject: RFR: 8296440: Remove Method* handling from
 cleanup_inline_caches_impl [v4]
In-Reply-To: <cRC5U64EXBeJ2dCAVsRgxVyhmrljJE0olhuFUOLsda8=.158645d2-79d5-477e-9f30-311662c85384@github.com>
References: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
 <cRC5U64EXBeJ2dCAVsRgxVyhmrljJE0olhuFUOLsda8=.158645d2-79d5-477e-9f30-311662c85384@github.com>
Message-ID: <-RLv3wVSPQzSzrN4CVoXt5-xxQsflSazY-SO-pmZvF4=.e9c2efd5-6a96-4b6b-aa46-19003b75e8a3@github.com>

On Fri, 24 Mar 2023 18:45:13 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> This PR replaces cleaning of static stubs in CompiledMethod::cleanup_inline_caches_impl() with a guarantee that it is actually not needed because the holder of the embedded target Method* is alive if the caller nmethod is not unloading.
>> 
>> The holder of the target Method* has to be alive because it is reachable from the caller nmethod's oop pool. This is checked by `check_path_to_callee()` when a statically bound call gets resolved.
>> 
>> C2i entry barriers can be removed for the same reason.
>> 
>> Testing:
>> 
>> Many rounds in our CI testing which includes most JCK and JTREG tests, Renaissance benchmark and SAP specific tests with fastdebug and release builds on the standard platforms plus PPC64.
>> 
>> I've also done tier1 and tier2 tests with -XX:-Inline and tier1 tests with ZGC.
>> 
>> I've started hotspot and jdk tier1 tests with -Xcomp. They were not finished when I stopped them after 24h.
>
> Richard Reingruber has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Merge branch 'master'
>  - Fix
>  - Feedback Coleene
>  - Adding TestStaticallyBoundTargetIsReachable.java
>  - Path to target exists also if the receiver is a constant of the caller
>  - Use nmethod::oops_do() to search for to_holder in from_nm
>  - Merge branch 'master'
>  - Remove MacroAssembler::resolve_weak_handle()
>  - Remove keep_alive_offset() and holder_offset() from CLD
>  - Remove MacroAssembler::load_method_holder_cld()
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/4154a980...31bcdb07

No new failures. Tier7 is clean.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12802#pullrequestreview-1358074214

From dholmes at openjdk.org  Sun Mar 26 23:29:39 2023
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 26 Mar 2023 23:29:39 GMT
Subject: RFR: JDK-8304723: Statically allocate global mutexes [v6]
In-Reply-To: <YGVZbU3f0JVCx5Q49vgZZhCcjxtNoOy_tR5VrXntT-o=.be4bdcc9-dfcd-418c-bcbd-c5d53efa2fdf@github.com>
References: <GnX35HIFItX1KV3Zsg5l-zwZVkhP_4Hq5o5ZhtiO57w=.94a86c58-3910-4b52-8c2f-3d6aaf713a06@github.com>
 <YGVZbU3f0JVCx5Q49vgZZhCcjxtNoOy_tR5VrXntT-o=.be4bdcc9-dfcd-418c-bcbd-c5d53efa2fdf@github.com>
Message-ID: <5sVB3N10SpFPxeSjDgIDk8GKb6UNStePgggkzypP7LI=.38e7f265-1446-4a3b-bc2e-7547723272b1@github.com>

On Fri, 24 Mar 2023 16:46:47 GMT, Justin King <jcking at openjdk.org> wrote:

>> Switch to statically allocate storage for all of Hotspot's global mutexes and monitors. This avoids needing to allocate each one dynamically at startup. These also live for the lifetime of the program, so this reduces any potential memory fragmention in the C heap.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix spacing as requested
>   
>   Signed-off-by: Justin King <jcking at google.com>

Marked as reviewed by dholmes (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13143#pullrequestreview-1358155196

From kbarrett at openjdk.org  Mon Mar 27 00:54:47 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 27 Mar 2023 00:54:47 GMT
Subject: RFR: 8302798: Refactor -XX:+UseOSErrorReporting for noreturn crash
 reporting [v3]
In-Reply-To: <bra4j8ERIDMpG5qENJfD8s1r1SJBDR_LORHvU_xDefY=.2f707a60-ebc0-4c98-81c3-1080d1279cf3@github.com>
References: <elVA1mzItfJ7bnnfSpEUVprtbnnSx1zT_eoXnV2sviU=.13e2d4dc-74b0-4051-8852-04caf2c81196@github.com>
 <e2seVQWyK6KOjyo8gGmxeJfPbXBV0QibpBAm6jYAsJE=.27f3fdfc-7763-409e-be1c-3fe61e3905b7@github.com>
 <bra4j8ERIDMpG5qENJfD8s1r1SJBDR_LORHvU_xDefY=.2f707a60-ebc0-4c98-81c3-1080d1279cf3@github.com>
Message-ID: <IjZkR7nuKEWIrTC8Y7NffvE1wlctC0XIOmjdP-mDXUg=.17b7cb27-2219-4f03-b3fd-a7d6aae94aaa@github.com>

On Tue, 21 Mar 2023 13:01:00 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> When compiling a Windows HotSpot with gcc (see [8288293](https://bugs.openjdk.org/browse/JDK-8288293?filter=-3)) newer gcc versions have a diagnostic that can catch when noreturn code returns in certain areas, and gcc catches several with this change:
> 
> ```
> src/hotspot/os/windows/os_windows.cpp: In static member function 'static void os::abort(bool, void*, const void*)':
> src/hotspot/os/windows/os_windows.cpp:1249:1: error: 'noreturn' function does return [-Werror]
>  1249 | }
>       | ^
> src/hotspot/os/windows/os_windows.cpp: In static member function 'static void os::die()':
> src/hotspot/os/windows/os_windows.cpp:1254:1: error: 'noreturn' function does return [-Werror]
>  1254 | }
>       | ^
> src/hotspot/os/windows/os_windows.cpp: In static member function 'static void os::exit(int)':
> src/hotspot/os/windows/os_windows.cpp:4792:1: error: 'noreturn' function does return [-Werror]
>  4792 | }
>       | ^
> src/hotspot/os/windows/os_windows.cpp: In static member function 'static void os::_exit(int)':
> src/hotspot/os/windows/os_windows.cpp:4796:1: error: 'noreturn' function does return [-Werror]
>  4796 | }
> ```
> 
> I don't know if this is something we should be worried about with our current setup and the regular build that we have for Windows, so I'm leaving this warning here for someone else to read through

I think all of these warnings would go away if `os::win32::exit_process_or_thread` was noreturn.
It looks like it is effectively noreturn (but not marked), though it contains a final `return exit_code;`
that is commented as unreachable.  I filed https://bugs.openjdk.org/browse/JDK-8304939 for this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12759#issuecomment-1484311911

From dholmes at openjdk.org  Mon Mar 27 02:49:57 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 27 Mar 2023 02:49:57 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <m2x5qE_kdoZUNbm8umGkSQVj2TtERnma7f4VAKjCwmg=.0b02535a-7eed-48b5-bad2-09479bc2e2e1@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
 <m2x5qE_kdoZUNbm8umGkSQVj2TtERnma7f4VAKjCwmg=.0b02535a-7eed-48b5-bad2-09479bc2e2e1@github.com>
Message-ID: <Oanu6WDNAJ8UKlWGMc0xT-6c41p5MUp4taznkyhVw90=.229a6ba6-5af3-4acb-ab24-c5b9927108e6@github.com>

On Fri, 24 Mar 2023 17:11:46 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> AFAIU, these places now could get outdated information from the contains function: either getting a false positive or a false negative when asking for a given object. But if I understand correctly, this had been the case before, too. Since the information about ownership may be outdated as soon as one read the BasicLock* address from the markwork. So these APIs do only report a state that once had been, but never the current state.

Sure but my concern is not stale data, it is whether the lock-stack code may crash (or otherwise misbehave) if there are concurrent changes to it whilst it is being queried.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1484401692

From stuefe at openjdk.org  Mon Mar 27 06:39:53 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 27 Mar 2023 06:39:53 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <Oanu6WDNAJ8UKlWGMc0xT-6c41p5MUp4taznkyhVw90=.229a6ba6-5af3-4acb-ab24-c5b9927108e6@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
 <m2x5qE_kdoZUNbm8umGkSQVj2TtERnma7f4VAKjCwmg=.0b02535a-7eed-48b5-bad2-09479bc2e2e1@github.com>
 <Oanu6WDNAJ8UKlWGMc0xT-6c41p5MUp4taznkyhVw90=.229a6ba6-5af3-4acb-ab24-c5b9927108e6@github.com>
Message-ID: <Uf9xueNz1jEFdbA51S0GttlqFSaJkYnOL4yPA6xBfO0=.ab9fcdb1-e032-4373-9e87-4801a1025654@github.com>

On Mon, 27 Mar 2023 02:46:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > AFAIU, these places now could get outdated information from the contains function: either getting a false positive or a false negative when asking for a given object. But if I understand correctly, this had been the case before, too. Since the information about ownership may be outdated as soon as one read the BasicLock* address from the markwork. So these APIs do only report a state that once had been, but never the current state.
> 
> Sure but my concern is not stale data, it is whether the lock-stack code may crash (or otherwise misbehave) if there are concurrent changes to it whilst it is being queried.

Lockstack is a fixed sized array of oop with a ptr-sized member indicating the current offset. It is embedded into Thread. Modifying the LockStack (push, pop, remove) is non-atomic: write the element, then update the current offset. The contains function - the only function not only called from current thread (and we should assert that) - reads current offset, then iterates the whole array up to offset, comparing each oop with the given one. The only way I see this crashing is if we read the current offset in a half-written state. Not sure if any of our platforms read/write a pointer-sized field non-atomic. All other misreads - would "just" result in a time window where contains() gives the wrong answer.

So we should read the offset atomically. Alternatively, have a second contains(), e.g. `contains_full()`, just for the sake of concurrent iteration, and let that one iterate the whole stack incl. unused slots. Iteration limits would be hardcoded offsets from Thread*, no need to read offset. The obvious disadvantage would be that we'd need to mark/zero out popped slots in release builds.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1484583227

From duke at openjdk.org  Mon Mar 27 07:52:46 2023
From: duke at openjdk.org (Afshin Zafari)
Date: Mon, 27 Mar 2023 07:52:46 GMT
Subject: RFR: 8297539: Consolidate the uses of the int<->float union
 conversion trick [v2]
In-Reply-To: <HvR0vRb39zELw5VRb1MkYpSJIzfrYamRhRDilGS5b5c=.d3c913ad-8033-4a6d-94de-c70a174fe9b9@github.com>
References: <MxlPCja9xJ0_B09jyn_Xqb6HVrYclplkhCN0XhuM0-4=.f0dfba0b-3d2b-41ae-b94c-bf42699d7169@github.com>
 <HvR0vRb39zELw5VRb1MkYpSJIzfrYamRhRDilGS5b5c=.d3c913ad-8033-4a6d-94de-c70a174fe9b9@github.com>
Message-ID: <R9lwaE8qAVAXebw2j5k5GbZodNIWcIZZnkaInkjR-0o=.92930cff-a3d3-4473-b3ab-d4df5068d3b4@github.com>

On Mon, 6 Feb 2023 10:31:21 GMT, Afshin Zafari <duke at openjdk.org> wrote:

>> ### Discussion
>> 
>> There are different ways of casting/converting integral types to floating point types and vice versa in the code. 
>> These conversions are changed to invocation of a centralised `cast<To>(From)` method in `primitiveConversions.hpp`. To make this changes build and run, some new `cast` methods are introduced and header dependencies changed. 
>> 
>> ### Patch
>> 
>> - All instances of using `union` technique that are used for int<->float and long<->double type conversions are replaced by `PrimitiveConversions::cast<To>(From)` method.
>>   - Instances of, for example, converting `int`<->`intptr_t` are not changed.
>> - After this change, `JavaValue` also uses the `PrimitiveConversions::cast<To>(From)` templates. Therefore, all the `union` conversions for `int`<-> `float` and `long` <-> `double` in hotspot are now centralised in one location.
>> - Templates in `PrimitiveConversions` class are numbered from 1-9 and all lines of code that use `PrimitivEConversions::cast<To>(From)` have comments saying which templated `cast<To>(From)` matches. Issue number 8297539 is also in the comments to make the search/reviews more easier.
>> - The new 'cast<To>(From)' templates are numbered 6-9 for some instances where existing templates (1-5) did not match.
>> - `globalDefinitions.hpp` now includes `primitiveConversions.hpp`.
>> - `primitiveConversions.hpp` does NOT include `globalDefinitions.hpp` any more. Some typedef's are added to it to compensate the missing types.
>> - The followings are not changed:
>>   - `jni.hpp`
>>   - `ciConstant.hpp` is not changed, since uinon is not used for converting `int` <->`float` or `long` <-> `double`. There are some asserts that allow setter/getter used only for the same types.
>>   - `bytecodeInterpreter_zero.hpp` is not changed. Writing to and reading from the `VMJavaVal64` are always with the same type and no conversion is made.
>>   - union with bit fields are not changed.
>>   - `json.hpp` and `json.cpp` in src/hotspot/share/utilities.
>> 
>> ### Test
>> mach5 tiers 1-5 passed, tiers 6-8 in progress
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8297539: Consolidate the uses of the int<->float union conversion trick

I am going to do some more limited fixes for this RFE.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12384#issuecomment-1484665610

From duke at openjdk.org  Mon Mar 27 07:52:48 2023
From: duke at openjdk.org (Afshin Zafari)
Date: Mon, 27 Mar 2023 07:52:48 GMT
Subject: Withdrawn: 8297539: Consolidate the uses of the int<->float union
 conversion trick
In-Reply-To: <MxlPCja9xJ0_B09jyn_Xqb6HVrYclplkhCN0XhuM0-4=.f0dfba0b-3d2b-41ae-b94c-bf42699d7169@github.com>
References: <MxlPCja9xJ0_B09jyn_Xqb6HVrYclplkhCN0XhuM0-4=.f0dfba0b-3d2b-41ae-b94c-bf42699d7169@github.com>
Message-ID: <sXiVl7lgU4dahbIH-rXEtaF4kPOthE9wUfExU1QlujA=.7e1cec61-8657-4298-b9e8-a50de72b563f@github.com>

On Thu, 2 Feb 2023 10:17:21 GMT, Afshin Zafari <duke at openjdk.org> wrote:

> ### Discussion
> 
> There are different ways of casting/converting integral types to floating point types and vice versa in the code. 
> These conversions are changed to invocation of a centralised `cast<To>(From)` method in `primitiveConversions.hpp`. To make this changes build and run, some new `cast` methods are introduced and header dependencies changed. 
> 
> ### Patch
> 
> - All instances of using `union` technique that are used for int<->float and long<->double type conversions are replaced by `PrimitiveConversions::cast<To>(From)` method.
>   - Instances of, for example, converting `int`<->`intptr_t` are not changed.
> - After this change, `JavaValue` also uses the `PrimitiveConversions::cast<To>(From)` templates. Therefore, all the `union` conversions for `int`<-> `float` and `long` <-> `double` in hotspot are now centralised in one location.
> - Templates in `PrimitiveConversions` class are numbered from 1-9 and all lines of code that use `PrimitivEConversions::cast<To>(From)` have comments saying which templated `cast<To>(From)` matches. Issue number 8297539 is also in the comments to make the search/reviews more easier.
> - The new 'cast<To>(From)' templates are numbered 6-9 for some instances where existing templates (1-5) did not match.
> - `globalDefinitions.hpp` now includes `primitiveConversions.hpp`.
> - `primitiveConversions.hpp` does NOT include `globalDefinitions.hpp` any more. Some typedef's are added to it to compensate the missing types.
> - The followings are not changed:
>   - `jni.hpp`
>   - `ciConstant.hpp` is not changed, since uinon is not used for converting `int` <->`float` or `long` <-> `double`. There are some asserts that allow setter/getter used only for the same types.
>   - `bytecodeInterpreter_zero.hpp` is not changed. Writing to and reading from the `VMJavaVal64` are always with the same type and no conversion is made.
>   - union with bit fields are not changed.
>   - `json.hpp` and `json.cpp` in src/hotspot/share/utilities.
> 
> ### Test
> mach5 tiers 1-5 passed, tiers 6-8 in progress

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/12384

From bkilambi at openjdk.org  Mon Mar 27 08:44:38 2023
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Mon, 27 Mar 2023 08:44:38 GMT
Subject: RFR: 8301012: [vectorapi]: Intrinsify CompressBitsV/ExpandBitsV
 and add the AArch64 SVE backend implementation [v2]
In-Reply-To: <WepLX4oA_2sxHK2IzxZPuCSw126ydVMIkLrQFlwBxhI=.1c20c2fe-62c7-4576-a7f5-bdbfa1055214@github.com>
References: <RaPIEa3D1wT6isue-1l_ILYJ6FCWSeNJ-T8QXtoxnUk=.05a804b5-9b2f-4486-aad4-53f00a3a6ab3@github.com>
 <WepLX4oA_2sxHK2IzxZPuCSw126ydVMIkLrQFlwBxhI=.1c20c2fe-62c7-4576-a7f5-bdbfa1055214@github.com>
Message-ID: <NgfkPvaKe030h5kZ2j_rFHzy2s8vehNIBkIvToZ4hj8=.5d0af317-6463-433b-8e18-5897c46efae1@github.com>

On Mon, 20 Mar 2023 17:37:59 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

>> This patch adds mid-end compiler vector IR nodes for the scalar CompressBits and ExpandBits nodes - CompressBitsV and ExpandBitsV and also adds aarch64 backend support for these nodes using SVE2 instructions (included in the svebitperm feature). As there are direct instructions in SVE2 that map to these operations, a huge speed up in performance can be observed and it might significantly benefit all those workloads that extensively run these operations on an SVE2(with svebitperm feature) supporting machine.
>> 
>> All the JTREG tests under "test/jdk/jdk/incubator/vector" pass successfully with this patch on an SVE2 machine.
>> The JMH tests - COMPRESS_BITS and EXPAND_BITS from [1] and [2] were run on a 128-bit vector length, SVE2 and svebitperm supporting aarch64 machine. Following are the gains observed with this patch -
>> 
>> 
>> Benchmark                       (length)  Mode    Cnt   Gain
>> IntMaxVector.COMPRESS_BITS      1024      thrpt   15    81.68x
>> IntMaxVector.EXPAND_BITS        1024      thrpt   15    85.65x
>> LongMaxVector.COMPRESS_BITS     1024      thrpt   15    70.78x
>> LongMaxVector.EXPAND_BITS       1024      thrpt   15    76.31x
>> 
>> 
>> The "Gain" column is the ratio between the throughput of benchmark runs with this patch and that of benchmark runs without this patch. This patch does not change the performance of these operations for all other machines that do not support these instructions or when run on a different architecture.
>> 
>> This patch enables the generation of optimized SVE2 instructions for CompressBits and ExpandBits operations through vectorapi but at the same time with the addition of scalar implementation of CompressBits andExpandBits in the aarch64 backend with this commit - https://github.com/openjdk/jdk/commit/bbd8ae78200e4128d4eddf8694835956b5c5f142, it also enabes auto-vectorization of these nodes on aarch64 SVE2 supporting machines.
>> 
>> Measured the performance of the following benchmarks with the master branch (auto-vectorization not enabled) with this patch
>> (auto-vectorization enabled) -
>>     
>> 
>>         @Benchmark
>>         public void testCompInt() {
>>             for (int i = 0; i < length; i++) {
>>                 ir[i] = Integer.compress(ia[i], ib[i]);
>>             }
>>         }
>>     
>>         @Benchmark
>>         public void testExpInt() {
>>             for (int i = 0; i < length; i++) {
>>                 ir[i] = Integer.expand(ia[i], ib[i]);
>>             }
>>         }
>>     
>>         @Benchmark
>>         public void testCompLong() {
>>             for (int i = 0; i < length; i++) {
>>                 lr[i] = Long.compress(la[i], lb[i]);
>>             }
>>         }
>>     
>>         @Benchmark
>>         public void testExpLong() {
>>             for (int i = 0; i < length; i++) {
>>                 lr[i] = Long.expand(la[i], lb[i]);
>>             }
>>         }
>>     
>>     Benchmark                               (length)  Mode     Cnt   Gain
>>     VectorCompressExpand.testCompInt        2048      thrpt    15    9.97x
>>     VectorCompressExpand.testCompLong       2048      thrpt    15    5.63x
>>     VectorCompressExpand.testExpInt         2048      thrpt    15    9.70x
>>     VectorCompressExpand.testExpLong        2048      thrpt    15    5.66x
>> 
>> ```    
>>     
>> Gain column is the ratio between the throughput of this patch and that of the master branch.
>> With vectorization enabled (either through Superword or Vectorapi), significant gains can be observed for CompressBits and ExpandBits.
>> 
>> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/IntMaxVector.java 
>> [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/LongMaxVector.java
>
> Bhavana Kilambi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge master and fix conflicts
>  - 8301012: [vectorapi]: Intrinsify CompressBitsV/ExpandBitsV and add the AArch64 SVE backend implementation
>    
>    This patch adds mid-end compiler vector IR nodes for the scalar
>    CompressBits and ExpandBits nodes - CompressBitsV and ExpandBitsV and
>    also adds aarch64 backend support for these nodes using SVE2
>    instructions (included in the svebitperm feature).
>    As there are direct instructions in SVE2 that map to these operations,
>    a huge speed up in performance can be observed and it might significantly
>    benefit all those workloads that extensively run these operations on an
>    SVE2(with svebitperm feature) supporting machine.
>    
>    All the JTREG tests under "test/jdk/jdk/incubator/vector" pass
>    successfully with this patch on an SVE2 machine.
>    The JMH tests - COMPRESS_BITS and EXPAND_BITS from [1] and [2]
>    were run on a 128-bit vector length, SVE2 and svebitperm supporting
>    aarch64 machine. Following are the gains observed with this patch -
>    
>    Benchmark                       (length)  Mode    Cnt   Gain
>    IntMaxVector.COMPRESS_BITS      1024      thrpt   15    81.68x
>    IntMaxVector.EXPAND_BITS        1024      thrpt   15    85.65x
>    LongMaxVector.COMPRESS_BITS     1024      thrpt   15    70.78x
>    LongMaxVector.EXPAND_BITS       1024      thrpt   15    76.31x
>    
>    The "Gain" column is the ratio between the throughput of benchmark runs
>    with this patch and that of benchmark runs without this patch. This patch
>    does not change the performance of these operations for all other
>    machines that do not support these instructions or when run on a
>    different architecture.
>    With this patch, vectorization of CompressBits and ExpandBits operations
>    happens only through vectorapi for aarch64. Autovectorization does not
>    take place as the current JDK source does not contain aarch64 backend
>    implementation for scalar CompressBits and ExpandBits. However, this PR -
>    https://github.com/openjdk/jdk/pull/10537 adds aarch64 backend
>    implementaton for CompressBits and ExpandBits and may lead to
>    autovectorization of these nodes as well eventually but this PR is a
>    standalone one and not dependent on the scalar implementation.
>    
>    [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/IntMaxVector.java
>    [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/LongMaxVector.java

Thank you for reviewing ..

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12446#issuecomment-1484741149

From bkilambi at openjdk.org  Mon Mar 27 08:53:46 2023
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Mon, 27 Mar 2023 08:53:46 GMT
Subject: Integrated: 8301012: [vectorapi]: Intrinsify CompressBitsV/ExpandBitsV
 and add the AArch64 SVE backend implementation
In-Reply-To: <RaPIEa3D1wT6isue-1l_ILYJ6FCWSeNJ-T8QXtoxnUk=.05a804b5-9b2f-4486-aad4-53f00a3a6ab3@github.com>
References: <RaPIEa3D1wT6isue-1l_ILYJ6FCWSeNJ-T8QXtoxnUk=.05a804b5-9b2f-4486-aad4-53f00a3a6ab3@github.com>
Message-ID: <T4fOBt8t4T3wfe1cst9sKRj52wvV5giJZUhUIEiqwqM=.6b40433b-2a46-423e-ab1a-83a252dae9e0@github.com>

On Mon, 6 Feb 2023 17:23:20 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

> This patch adds mid-end compiler vector IR nodes for the scalar CompressBits and ExpandBits nodes - CompressBitsV and ExpandBitsV and also adds aarch64 backend support for these nodes using SVE2 instructions (included in the svebitperm feature). As there are direct instructions in SVE2 that map to these operations, a huge speed up in performance can be observed and it might significantly benefit all those workloads that extensively run these operations on an SVE2(with svebitperm feature) supporting machine.
> 
> All the JTREG tests under "test/jdk/jdk/incubator/vector" pass successfully with this patch on an SVE2 machine.
> The JMH tests - COMPRESS_BITS and EXPAND_BITS from [1] and [2] were run on a 128-bit vector length, SVE2 and svebitperm supporting aarch64 machine. Following are the gains observed with this patch -
> 
> 
> Benchmark                       (length)  Mode    Cnt   Gain
> IntMaxVector.COMPRESS_BITS      1024      thrpt   15    81.68x
> IntMaxVector.EXPAND_BITS        1024      thrpt   15    85.65x
> LongMaxVector.COMPRESS_BITS     1024      thrpt   15    70.78x
> LongMaxVector.EXPAND_BITS       1024      thrpt   15    76.31x
> 
> 
> The "Gain" column is the ratio between the throughput of benchmark runs with this patch and that of benchmark runs without this patch. This patch does not change the performance of these operations for all other machines that do not support these instructions or when run on a different architecture.
> 
> This patch enables the generation of optimized SVE2 instructions for CompressBits and ExpandBits operations through vectorapi but at the same time with the addition of scalar implementation of CompressBits andExpandBits in the aarch64 backend with this commit - https://github.com/openjdk/jdk/commit/bbd8ae78200e4128d4eddf8694835956b5c5f142, it also enabes auto-vectorization of these nodes on aarch64 SVE2 supporting machines.
> 
> Measured the performance of the following benchmarks with the master branch (auto-vectorization not enabled) with this patch
> (auto-vectorization enabled) -
>     
> 
>         @Benchmark
>         public void testCompInt() {
>             for (int i = 0; i < length; i++) {
>                 ir[i] = Integer.compress(ia[i], ib[i]);
>             }
>         }
>     
>         @Benchmark
>         public void testExpInt() {
>             for (int i = 0; i < length; i++) {
>                 ir[i] = Integer.expand(ia[i], ib[i]);
>             }
>         }
>     
>         @Benchmark
>         public void testCompLong() {
>             for (int i = 0; i < length; i++) {
>                 lr[i] = Long.compress(la[i], lb[i]);
>             }
>         }
>     
>         @Benchmark
>         public void testExpLong() {
>             for (int i = 0; i < length; i++) {
>                 lr[i] = Long.expand(la[i], lb[i]);
>             }
>         }
>     
>     Benchmark                               (length)  Mode     Cnt   Gain
>     VectorCompressExpand.testCompInt        2048      thrpt    15    9.97x
>     VectorCompressExpand.testCompLong       2048      thrpt    15    5.63x
>     VectorCompressExpand.testExpInt         2048      thrpt    15    9.70x
>     VectorCompressExpand.testExpLong        2048      thrpt    15    5.66x
> 
> ```    
>     
> Gain column is the ratio between the throughput of this patch and that of the master branch.
> With vectorization enabled (either through Superword or Vectorapi), significant gains can be observed for CompressBits and ExpandBits.
> 
> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/IntMaxVector.java 
> [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/LongMaxVector.java

This pull request has now been integrated.

Changeset: de1c12ed
Author:    Bhavana Kilambi <bkilambi at openjdk.org>
Committer: Xiaohong Gong <xgong at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/de1c12ed636a43cc74b81c48cc987332fe341d7a
Stats:     259 lines in 9 files changed: 254 ins; 2 del; 3 mod

8301012: [vectorapi]: Intrinsify CompressBitsV/ExpandBitsV and add the AArch64 SVE backend implementation

Co-authored-by: Xiaohong Gong <xgong at openjdk.org>
Co-authored-by: Jatin Bhateja <jbhateja at openjdk.org>
Reviewed-by: ngasson, eliu, thartmann

-------------

PR: https://git.openjdk.org/jdk/pull/12446

From gcao at openjdk.org  Mon Mar 27 10:20:44 2023
From: gcao at openjdk.org (Gui Cao)
Date: Mon, 27 Mar 2023 10:20:44 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v13]
In-Reply-To: <qQQW5bT_xzIYWWVKg98Y-nl2PPZjrke7UU8inhrg5j8=.9a3eefc6-b6ad-4d1c-a50f-72ceeb41c2b4@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <k8l6dEqbMu9z7cTiJVwynq0oSXBVU7v2tcAvhfs6hUk=.fbf07c48-db3f-4fd0-a1cd-1c4773ee6f22@github.com>
 <qQQW5bT_xzIYWWVKg98Y-nl2PPZjrke7UU8inhrg5j8=.9a3eefc6-b6ad-4d1c-a50f-72ceeb41c2b4@github.com>
Message-ID: <mJ3sDZ3JY_IovAGYXgO9mxgi-DgL010jA6u7GrxacKs=.6c2b30b6-c23b-46b7-966d-805a839bf6a5@github.com>

On Sat, 25 Mar 2023 05:11:16 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improved interpreter comments aarch64
>
> Changes requested by fyang (Reviewer).

More changes for RISC-V which resolve @RealFYang's review comments. @matias9927 Please help integrate this
https://github.com/zifeihan/jdk/commit/413dd02221598edba9e44ee7d9b20414bde76243
(on this branch: https://github.com/zifeihan/jdk/commits/12778_riscv_port_v4)
By the way, the riscv port passed the tier1-3 tests on unmatched board with no new errors introduced.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12778#issuecomment-1484884543

From duke at openjdk.org  Mon Mar 27 13:26:29 2023
From: duke at openjdk.org (Afshin Zafari)
Date: Mon, 27 Mar 2023 13:26:29 GMT
Subject: RFR: 8297539: Use PrimitiveConversions::cast for local uses of the
 int<->float union conversion trick
Message-ID: <Fc1LufRzwqeQjXSwyVm3FaJWzbaazUXyArTYPLlGrwM=.034cb09b-79d8-49a1-a68d-b5914a9cc214@github.com>

**Only** the instances of using `union` for converting `int` to `float` are replaced with call to `PrimitiveConversions::cast<To>(From)` method. Some few cases with conversion of `long` <->`double` are also replaced with `PrimitiveConversions::cast<To>(From)`. The other instances where the union contains other types of fields than `int` and `float` are left unchanged.

### Test
local hotspot:tier1
mach5 tiers 1-5

-------------

Commit messages:
 - 8297539: Use PrimitiveConversions::cast for local uses of the int<->float union conversion trick
 - some more conversions are replaced with PrimitiveConversions::Cast
 - 8297539: Use PrimitiveConversions::cast for local uses of the int<->float union conversion trick
 - 8297539: Use PrimitiveConversions::cast for local uses of the int<->float union conversion trick

Changes: https://git.openjdk.org/jdk/pull/13136/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13136&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297539
  Stats: 51 lines in 5 files changed: 5 ins; 19 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/13136.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13136/head:pull/13136

PR: https://git.openjdk.org/jdk/pull/13136

From jcking at openjdk.org  Mon Mar 27 14:07:58 2023
From: jcking at openjdk.org (Justin King)
Date: Mon, 27 Mar 2023 14:07:58 GMT
Subject: Integrated: JDK-8304828: Lots of constant static data not declared
 static const in cpu/x86
In-Reply-To: <7KzH7QPu53lViaVf5yIBoJ7hxpvBIK9iZP-L5EVH8U4=.0935258a-29ba-43b5-a845-1201be6dface@github.com>
References: <7KzH7QPu53lViaVf5yIBoJ7hxpvBIK9iZP-L5EVH8U4=.0935258a-29ba-43b5-a845-1201be6dface@github.com>
Message-ID: <CH_O734ZxIcEFhkfSkXoU-aJc8UeO7BjAt_aEpf4ZEU=.c76cc47a-32bf-4673-b5fd-c6b18a256402@github.com>

On Thu, 23 Mar 2023 17:31:26 GMT, Justin King <jcking at openjdk.org> wrote:

> Simple refactor that updates declarations and definitions for data that is effectively static and constant to be `static` and/or `const`. Helps make sure we do not break the one definition rule and helps the compiler/linker to place the data in read-only sections of the executable.

This pull request has now been integrated.

Changeset: 20830883
Author:    Justin King <jcking at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/20830883dff1fa096cf929d81360953e7f3cfc46
Stats:     166 lines in 27 files changed: 0 ins; 0 del; 166 mod

8304828: Lots of constant static data not declared static const in cpu/x86

Reviewed-by: dholmes, kvn

-------------

PR: https://git.openjdk.org/jdk/pull/13163

From jcking at openjdk.org  Mon Mar 27 14:17:21 2023
From: jcking at openjdk.org (Justin King)
Date: Mon, 27 Mar 2023 14:17:21 GMT
Subject: RFR: JDK-8304723: Statically allocate global mutexes [v6]
In-Reply-To: <YGVZbU3f0JVCx5Q49vgZZhCcjxtNoOy_tR5VrXntT-o=.be4bdcc9-dfcd-418c-bcbd-c5d53efa2fdf@github.com>
References: <GnX35HIFItX1KV3Zsg5l-zwZVkhP_4Hq5o5ZhtiO57w=.94a86c58-3910-4b52-8c2f-3d6aaf713a06@github.com>
 <YGVZbU3f0JVCx5Q49vgZZhCcjxtNoOy_tR5VrXntT-o=.be4bdcc9-dfcd-418c-bcbd-c5d53efa2fdf@github.com>
Message-ID: <d_qO02fALiHqrnGRFu06wjemhm18SiddtWQBRx6cMWM=.33a898a9-a88f-4f92-9f0a-e777e7b9ff15@github.com>

On Fri, 24 Mar 2023 16:46:47 GMT, Justin King <jcking at openjdk.org> wrote:

>> Switch to statically allocate storage for all of Hotspot's global mutexes and monitors. This avoids needing to allocate each one dynamically at startup. These also live for the lifetime of the program, so this reduces any potential memory fragmention in the C heap.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix spacing as requested
>   
>   Signed-off-by: Justin King <jcking at google.com>

GHA failure seems to be network issue on the underlying install dependencies step, so unrelated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13143#issuecomment-1485179314

From jcking at openjdk.org  Mon Mar 27 14:17:24 2023
From: jcking at openjdk.org (Justin King)
Date: Mon, 27 Mar 2023 14:17:24 GMT
Subject: Integrated: JDK-8304723: Statically allocate global mutexes
In-Reply-To: <GnX35HIFItX1KV3Zsg5l-zwZVkhP_4Hq5o5ZhtiO57w=.94a86c58-3910-4b52-8c2f-3d6aaf713a06@github.com>
References: <GnX35HIFItX1KV3Zsg5l-zwZVkhP_4Hq5o5ZhtiO57w=.94a86c58-3910-4b52-8c2f-3d6aaf713a06@github.com>
Message-ID: <rbXWMtO0moKONg_S6Jq_Q8a3-F9VEIBsDU4TRBT6EcA=.cdf6ef96-9478-49d2-890b-414488aef646@github.com>

On Wed, 22 Mar 2023 15:23:59 GMT, Justin King <jcking at openjdk.org> wrote:

> Switch to statically allocate storage for all of Hotspot's global mutexes and monitors. This avoids needing to allocate each one dynamically at startup. These also live for the lifetime of the program, so this reduces any potential memory fragmention in the C heap.

This pull request has now been integrated.

Changeset: 8d423f73
Author:    Justin King <jcking at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8d423f73051004bafdfa2961c57daf7761ce900c
Stats:     130 lines in 3 files changed: 12 ins; 14 del; 104 mod

8304723: Statically allocate global mutexes
8304736: Heap_lock is created twice

Reviewed-by: coleenp, dholmes, tschatzl

-------------

PR: https://git.openjdk.org/jdk/pull/13143

From coleenp at openjdk.org  Mon Mar 27 14:20:42 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 27 Mar 2023 14:20:42 GMT
Subject: RFR: 8297539: Use PrimitiveConversions::cast for local uses of the
 int<->float union conversion trick
In-Reply-To: <Fc1LufRzwqeQjXSwyVm3FaJWzbaazUXyArTYPLlGrwM=.034cb09b-79d8-49a1-a68d-b5914a9cc214@github.com>
References: <Fc1LufRzwqeQjXSwyVm3FaJWzbaazUXyArTYPLlGrwM=.034cb09b-79d8-49a1-a68d-b5914a9cc214@github.com>
Message-ID: <BNAXrocCzKdw_viqx4a7gfa-Q0V-47CS2J4QOhNhthU=.ce936fbf-b70f-46e4-aaae-273dd75cfe16@github.com>

On Wed, 22 Mar 2023 10:59:18 GMT, Afshin Zafari <duke at openjdk.org> wrote:

> **Only** the instances of using `union` for converting `int` to `float` are replaced with call to `PrimitiveConversions::cast<To>(From)` method. Some few cases with conversion of `long` <->`double` are also replaced with `PrimitiveConversions::cast<To>(From)`. The other instances where the union contains other types of fields than `int` and `float` are left unchanged.
> 
> ### Test
> local hotspot:tier1
> mach5 tiers 1-5

Looks good.  There are a couple of minor include file ordering things to fix.

src/hotspot/cpu/aarch64/assembler_aarch64.cpp line 30:

> 28: #include "asm/macroAssembler.hpp"
> 29: #include "compiler/disassembler.hpp"
> 30: #include "metaprogramming/primitiveConversions.hpp"

This needs to be after immediate_aarch64.hpp (alphabetical order).

src/hotspot/cpu/aarch64/immediate_aarch64.cpp line 30:

> 28: 
> 29: #include "precompiled.hpp"
> 30: #include "metaprogramming/primitiveConversions.hpp"

pre-existing, immediate_aarch64.hpp should be above this include.

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13136#pullrequestreview-1359155332
PR Review Comment: https://git.openjdk.org/jdk/pull/13136#discussion_r1149314837
PR Review Comment: https://git.openjdk.org/jdk/pull/13136#discussion_r1149315717

From duke at openjdk.org  Mon Mar 27 14:32:22 2023
From: duke at openjdk.org (Afshin Zafari)
Date: Mon, 27 Mar 2023 14:32:22 GMT
Subject: RFR: 8297539: Use PrimitiveConversions::cast for local uses of the
 int<->float union conversion trick [v2]
In-Reply-To: <Fc1LufRzwqeQjXSwyVm3FaJWzbaazUXyArTYPLlGrwM=.034cb09b-79d8-49a1-a68d-b5914a9cc214@github.com>
References: <Fc1LufRzwqeQjXSwyVm3FaJWzbaazUXyArTYPLlGrwM=.034cb09b-79d8-49a1-a68d-b5914a9cc214@github.com>
Message-ID: <BNvVp16bt2f79ztwX9fDwosj5widSV9ZnpUoyE6FTdg=.62382e84-40f4-495c-b10c-ba085d750015@github.com>

> **Only** the instances of using `union` for converting `int` to `float` are replaced with call to `PrimitiveConversions::cast<To>(From)` method. Some few cases with conversion of `long` <->`double` are also replaced with `PrimitiveConversions::cast<To>(From)`. The other instances where the union contains other types of fields than `int` and `float` are left unchanged.
> 
> ### Test
> local hotspot:tier1
> mach5 tiers 1-5

Afshin Zafari has updated the pull request incrementally with two additional commits since the last revision:

 - order of headers in includes.
 - order of headers corrected

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13136/files
  - new: https://git.openjdk.org/jdk/pull/13136/files/88e9a239..675997a7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13136&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13136&range=00-01

  Stats: 4 lines in 2 files changed: 2 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13136.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13136/head:pull/13136

PR: https://git.openjdk.org/jdk/pull/13136

From duke at openjdk.org  Mon Mar 27 14:32:27 2023
From: duke at openjdk.org (Afshin Zafari)
Date: Mon, 27 Mar 2023 14:32:27 GMT
Subject: RFR: 8297539: Use PrimitiveConversions::cast for local uses of the
 int<->float union conversion trick [v2]
In-Reply-To: <BNAXrocCzKdw_viqx4a7gfa-Q0V-47CS2J4QOhNhthU=.ce936fbf-b70f-46e4-aaae-273dd75cfe16@github.com>
References: <Fc1LufRzwqeQjXSwyVm3FaJWzbaazUXyArTYPLlGrwM=.034cb09b-79d8-49a1-a68d-b5914a9cc214@github.com>
 <BNAXrocCzKdw_viqx4a7gfa-Q0V-47CS2J4QOhNhthU=.ce936fbf-b70f-46e4-aaae-273dd75cfe16@github.com>
Message-ID: <Y2yOk2aCYtKIiusay7n8aVUojaSzPL4MwXDbVC9uimM=.30ae3cee-3d41-4cad-9d9f-45ac44b64bde@github.com>

On Mon, 27 Mar 2023 14:16:14 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - order of headers in includes.
>>  - order of headers corrected
>
> src/hotspot/cpu/aarch64/assembler_aarch64.cpp line 30:
> 
>> 28: #include "asm/macroAssembler.hpp"
>> 29: #include "compiler/disassembler.hpp"
>> 30: #include "metaprogramming/primitiveConversions.hpp"
> 
> This needs to be after immediate_aarch64.hpp (alphabetical order).

moved after `memory/..`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13136#discussion_r1149328233

From jcking at openjdk.org  Mon Mar 27 14:34:00 2023
From: jcking at openjdk.org (Justin King)
Date: Mon, 27 Mar 2023 14:34:00 GMT
Subject: RFR: JDK-8304539: Cleanup
 utilities/{count_leading_zeros, count_trailing_zeros,
 population_count}.hpp [v13]
In-Reply-To: <Ly_ZIg1wqoqnEy0N-YFdQaEpGg7Er8Vtj8phZQhgAw0=.4d9b54db-517e-491e-a376-623139808b7e@github.com>
References: <Ly_ZIg1wqoqnEy0N-YFdQaEpGg7Er8Vtj8phZQhgAw0=.4d9b54db-517e-491e-a376-623139808b7e@github.com>
Message-ID: <XjXG7R7YJOZBpzwPa13xKhc528XQSa0KXwG0lt4Ekbw=.8d22fad1-5e1e-4326-b579-77d3089378b5@github.com>

> As the title says, cleanup the mentioned headers. This is similar to `byteswap.hpp` and removes the extraneous `#ifdef` for XLC since it is really just Clang now.

Justin King has updated the pull request incrementally with one additional commit since the last revision:

  Update comment
  
  Signed-off-by: Justin King <jcking at google.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13103/files
  - new: https://git.openjdk.org/jdk/pull/13103/files/668fb06e..e52ce442

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13103&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13103&range=11-12

  Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/13103.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13103/head:pull/13103

PR: https://git.openjdk.org/jdk/pull/13103

From matsaave at openjdk.org  Mon Mar 27 14:43:04 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Mon, 27 Mar 2023 14:43:04 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v14]
In-Reply-To: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
Message-ID: <Fh6g8Qtdd0VS96WT8xUIrc4iiPfFICaFR5GG0IYpP8s=.fd3eca92-b604-4d3c-b31e-a731880e4efb@github.com>

> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
> 
> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
> 
> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
> 
> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
> 
> This change supports the following platforms: x86, aarch64, PPC, and RISCV

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  RISCV patch and aarch64 improvement

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12778/files
  - new: https://git.openjdk.org/jdk/pull/12778/files/ff7f3503..84ed272a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12778&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12778&range=12-13

  Stats: 21 lines in 3 files changed: 3 ins; 7 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/12778.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12778/head:pull/12778

PR: https://git.openjdk.org/jdk/pull/12778

From stuefe at openjdk.org  Mon Mar 27 15:12:50 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 27 Mar 2023 15:12:50 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <S3HAUfb2-rymMhcE0b5Uwycc6LpZHCnHRVHXL0141IU=.20c872ab-a4c1-4d40-b33b-a83f9f388cd1@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
 <S3HAUfb2-rymMhcE0b5Uwycc6LpZHCnHRVHXL0141IU=.20c872ab-a4c1-4d40-b33b-a83f9f388cd1@github.com>
Message-ID: <5y28pIWRTKPThWndmhdujCKNuvUMAbQwo2yXa3TUBv8=.3a1970ae-b732-4c6e-b96a-063b5c9d498e@github.com>

On Thu, 23 Mar 2023 16:32:57 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>>  - Set condition flags correctly after fast-lock call on aarch64
>
> Is anybody familiar with the academic literature on this topic? I am sure I am not the first person which has come up with this form of locking. Maybe we could use a name that refers to some academic paper?

@rkennke Question about ZGC and LockStack::contains(): how does this work with colored pointers? Don't we have to mask the color bits out somehow when comparing? E.g. using `ZAddress::offset()` ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1485293012

From rkennke at openjdk.org  Mon Mar 27 15:57:13 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 27 Mar 2023 15:57:13 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <S3HAUfb2-rymMhcE0b5Uwycc6LpZHCnHRVHXL0141IU=.20c872ab-a4c1-4d40-b33b-a83f9f388cd1@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
 <S3HAUfb2-rymMhcE0b5Uwycc6LpZHCnHRVHXL0141IU=.20c872ab-a4c1-4d40-b33b-a83f9f388cd1@github.com>
Message-ID: <oL3zqb1UAkGuligOc8rqHp2k7anmX7q0Fqx3iM_uihM=.d22b00d4-b913-47d9-8584-5ba7a6254916@github.com>

On Thu, 23 Mar 2023 16:32:57 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>>  - Set condition flags correctly after fast-lock call on aarch64
>
> Is anybody familiar with the academic literature on this topic? I am sure I am not the first person which has come up with this form of locking. Maybe we could use a name that refers to some academic paper?

> @rkennke Question about ZGC and LockStack::contains(): how does this work with colored pointers? Don't we have to mask the color bits out somehow when comparing? E.g. using `ZAddress::offset()` ?

That would be a question for @fisk and/or @stefank. AFAIK, the color bits should be masked by ZGC barriers *before* the oops enter the synchronization subsystem. But I kinda suspect that we are somehow triggering a ZGC bug here. Maybe we require barriers when reading oops from the lock-stack too?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1485390285

From rrich at openjdk.org  Mon Mar 27 16:41:25 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 27 Mar 2023 16:41:25 GMT
Subject: RFR: 8296440: Remove Method* handling from
 cleanup_inline_caches_impl [v4]
In-Reply-To: <-RLv3wVSPQzSzrN4CVoXt5-xxQsflSazY-SO-pmZvF4=.e9c2efd5-6a96-4b6b-aa46-19003b75e8a3@github.com>
References: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
 <cRC5U64EXBeJ2dCAVsRgxVyhmrljJE0olhuFUOLsda8=.158645d2-79d5-477e-9f30-311662c85384@github.com>
 <-RLv3wVSPQzSzrN4CVoXt5-xxQsflSazY-SO-pmZvF4=.e9c2efd5-6a96-4b6b-aa46-19003b75e8a3@github.com>
Message-ID: <RdcStp9_lacGHSKDrR1BA_znTY6UnhajmEFupvUn15w=.62d0b62e-7e55-4836-bd66-01631703fc9c@github.com>

On Sun, 26 Mar 2023 17:52:52 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> No new failures. Tier7 is clean.

Thanks! Are there tests still pending?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12802#issuecomment-1485464802

From kvn at openjdk.org  Mon Mar 27 17:14:10 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 27 Mar 2023 17:14:10 GMT
Subject: RFR: 8296440: Remove Method* handling from
 cleanup_inline_caches_impl [v4]
In-Reply-To: <RdcStp9_lacGHSKDrR1BA_znTY6UnhajmEFupvUn15w=.62d0b62e-7e55-4836-bd66-01631703fc9c@github.com>
References: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
 <cRC5U64EXBeJ2dCAVsRgxVyhmrljJE0olhuFUOLsda8=.158645d2-79d5-477e-9f30-311662c85384@github.com>
 <-RLv3wVSPQzSzrN4CVoXt5-xxQsflSazY-SO-pmZvF4=.e9c2efd5-6a96-4b6b-aa46-19003b75e8a3@github.com>
 <RdcStp9_lacGHSKDrR1BA_znTY6UnhajmEFupvUn15w=.62d0b62e-7e55-4836-bd66-01631703fc9c@github.com>
Message-ID: <934WT-8efOj7Y1qLzngCkbzexOf3D8GQft5IxxnVVMY=.1e0c5456-c45d-4442-b242-5cd2985bf388@github.com>

On Mon, 27 Mar 2023 16:38:31 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> > No new failures. Tier7 is clean.
> 
> Thanks! Are there tests still pending?

All tier1-7 finished. Also Xcomp and stress. That is why I approved changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12802#issuecomment-1485526565

From coleenp at openjdk.org  Mon Mar 27 17:22:57 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 27 Mar 2023 17:22:57 GMT
Subject: RFR: 8296440: Remove Method* handling from
 cleanup_inline_caches_impl [v4]
In-Reply-To: <cRC5U64EXBeJ2dCAVsRgxVyhmrljJE0olhuFUOLsda8=.158645d2-79d5-477e-9f30-311662c85384@github.com>
References: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
 <cRC5U64EXBeJ2dCAVsRgxVyhmrljJE0olhuFUOLsda8=.158645d2-79d5-477e-9f30-311662c85384@github.com>
Message-ID: <lJKJUle7AayRNMzUXGE9yGHKVlRvOe5YtAZGDnO7qUU=.859fa260-0b2f-4d0b-8030-303e5c856e99@github.com>

On Fri, 24 Mar 2023 18:45:13 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> This PR replaces cleaning of static stubs in CompiledMethod::cleanup_inline_caches_impl() with a guarantee that it is actually not needed because the holder of the embedded target Method* is alive if the caller nmethod is not unloading.
>> 
>> The holder of the target Method* has to be alive because it is reachable from the caller nmethod's oop pool. This is checked by `check_path_to_callee()` when a statically bound call gets resolved.
>> 
>> C2i entry barriers can be removed for the same reason.
>> 
>> Testing:
>> 
>> Many rounds in our CI testing which includes most JCK and JTREG tests, Renaissance benchmark and SAP specific tests with fastdebug and release builds on the standard platforms plus PPC64.
>> 
>> I've also done tier1 and tier2 tests with -XX:-Inline and tier1 tests with ZGC.
>> 
>> I've started hotspot and jdk tier1 tests with -Xcomp. They were not finished when I stopped them after 24h.
>
> Richard Reingruber has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Merge branch 'master'
>  - Fix
>  - Feedback Coleene
>  - Adding TestStaticallyBoundTargetIsReachable.java
>  - Path to target exists also if the receiver is a constant of the caller
>  - Use nmethod::oops_do() to search for to_holder in from_nm
>  - Merge branch 'master'
>  - Remove MacroAssembler::resolve_weak_handle()
>  - Remove keep_alive_offset() and holder_offset() from CLD
>  - Remove MacroAssembler::load_method_holder_cld()
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/4154a980...31bcdb07

The ClassLoaderData parts look good to me.

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12802#pullrequestreview-1359539788

From coleenp at openjdk.org  Mon Mar 27 17:23:03 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 27 Mar 2023 17:23:03 GMT
Subject: RFR: 8296440: Remove Method* handling from
 cleanup_inline_caches_impl [v2]
In-Reply-To: <yqkoY50q5Kc99kMBQmRu0TtIT6hTjzkUil3KSCJ4xsE=.39bb66e7-3c92-4890-9bad-50a2ec56ffc5@github.com>
References: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
 <BQbYsHfh5ZsQ_E1uIUnc9MLg3EgQ_BvW8RZfjMvgaLU=.556e1591-02d1-4073-8924-778fe1866bad@github.com>
 <Sc3IEKtrtDeddp3JO32ToY-vjVLzQKRptszRDyP1EHI=.68fd28b3-a714-46d4-bf78-c39ffb8aa073@github.com>
 <yqkoY50q5Kc99kMBQmRu0TtIT6hTjzkUil3KSCJ4xsE=.39bb66e7-3c92-4890-9bad-50a2ec56ffc5@github.com>
Message-ID: <n98zzSWwr_iBTBSBCnV3kIM52ZIC_aVVnqVunuloyMg=.b5fe29bc-3bb2-4df2-a165-41cb3555b637@github.com>

On Tue, 21 Mar 2023 17:11:30 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> src/hotspot/share/classfile/classLoaderData.cpp line 791:
>> 
>>> 789: 
>>> 790: bool ClassLoaderData::handles_contain(oop obj) {
>>> 791:   return _handles.contains(obj);
>> 
>> This might need to be protected by a metaspace_lock.
>
> I though it was not needed.
> Looks like `ChunkedHandleList` supports unsynchronized reading. We might not see all the handles recently added without locking but we are guaranteed to see the handles that were added by resolving the call we are checking.

I think you're right that it isn't needed.

>> src/hotspot/share/runtime/sharedRuntime.cpp line 1418:
>> 
>>> 1416:         return; // `to` is reachable by iterating parents of `from`
>>> 1417:       }
>>> 1418:     }
>> 
>> I'd be happier if this part was a function in ClassLoaderData or refactored from record_dependency (along with the constains function).  Since it's similar code.
>
> You are right. I've done the refactoring. Please let me know what you think.

I like the refactoring.  Thank you.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12802#discussion_r1149572982
PR Review Comment: https://git.openjdk.org/jdk/pull/12802#discussion_r1149569709

From eosterlund at openjdk.org  Mon Mar 27 17:33:19 2023
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 27 Mar 2023 17:33:19 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <oL3zqb1UAkGuligOc8rqHp2k7anmX7q0Fqx3iM_uihM=.d22b00d4-b913-47d9-8584-5ba7a6254916@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
 <S3HAUfb2-rymMhcE0b5Uwycc6LpZHCnHRVHXL0141IU=.20c872ab-a4c1-4d40-b33b-a83f9f388cd1@github.com>
 <oL3zqb1UAkGuligOc8rqHp2k7anmX7q0Fqx3iM_uihM=.d22b00d4-b913-47d9-8584-5ba7a6254916@github.com>
Message-ID: <RRZgt2qa_dIeMCorhRdKXatJqR3gwYPb_WVaVyG5rTk=.3d0962b2-e9d6-4325-bcd5-117c6361a5db@github.com>

On Mon, 27 Mar 2023 15:53:47 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> > @rkennke Question about ZGC and LockStack::contains(): how does this work with colored pointers? Don't we have to mask the color bits out somehow when comparing? E.g. using `ZAddress::offset()` ?
> 
> 
> 
> That would be a question for @fisk and/or @stefank. AFAIK, the color bits should be masked by ZGC barriers *before* the oops enter the synchronization subsystem. But I kinda suspect that we are somehow triggering a ZGC bug here. Maybe we require barriers when reading oops from the lock-stack too?

Oops that are processed in Thread::oops_do should not have load barriers. Other oops should have load barriers.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1485426029

From rkennke at openjdk.org  Mon Mar 27 17:33:20 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 27 Mar 2023 17:33:20 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <oL3zqb1UAkGuligOc8rqHp2k7anmX7q0Fqx3iM_uihM=.d22b00d4-b913-47d9-8584-5ba7a6254916@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
 <S3HAUfb2-rymMhcE0b5Uwycc6LpZHCnHRVHXL0141IU=.20c872ab-a4c1-4d40-b33b-a83f9f388cd1@github.com>
 <oL3zqb1UAkGuligOc8rqHp2k7anmX7q0Fqx3iM_uihM=.d22b00d4-b913-47d9-8584-5ba7a6254916@github.com>
Message-ID: <jOd8n1AgDt9_YXdEsTN3d1zQGaRrL0J5pgCpw9EYegs=.8b357917-aa83-4291-9c9c-9da292e69db0@github.com>

On Mon, 27 Mar 2023 15:53:47 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Is anybody familiar with the academic literature on this topic? I am sure I am not the first person which has come up with this form of locking. Maybe we could use a name that refers to some academic paper?
>
>> @rkennke Question about ZGC and LockStack::contains(): how does this work with colored pointers? Don't we have to mask the color bits out somehow when comparing? E.g. using `ZAddress::offset()` ?
> 
> That would be a question for @fisk and/or @stefank. AFAIK, the color bits should be masked by ZGC barriers *before* the oops enter the synchronization subsystem. But I kinda suspect that we are somehow triggering a ZGC bug here. Maybe we require barriers when reading oops from the lock-stack too?

> > > @rkennke Question about ZGC and LockStack::contains(): how does this work with colored pointers? Don't we have to mask the color bits out somehow when comparing? E.g. using `ZAddress::offset()` ?
> > 
> > 
> > That would be a question for @fisk and/or @stefank. AFAIK, the color bits should be masked by ZGC barriers _before_ the oops enter the synchronization subsystem. But I kinda suspect that we are somehow triggering a ZGC bug here. Maybe we require barriers when reading oops from the lock-stack too?
> 
> Oops that are processed in Thread::oops_do should not have load barriers. Other oops should have load barriers.

Ok, good. The lockstack is processed in JavaThread::oops_do_no_frames() which is called from Thread::oops_do(). But help me here: I believe ZGC processes this stuff concurrently, right? So there might be a window where the lock-stack oops would be unprocessed. The lock-stack would not go under the stack-watermark machinery. And if some code (like JVMTI deadlock detection pause) inspects the lockstack, it might see invalid oops? Is that a plausible scenario, or am I missing something?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1485550661

From eosterlund at openjdk.org  Mon Mar 27 18:05:47 2023
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 27 Mar 2023 18:05:47 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <jOd8n1AgDt9_YXdEsTN3d1zQGaRrL0J5pgCpw9EYegs=.8b357917-aa83-4291-9c9c-9da292e69db0@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
 <S3HAUfb2-rymMhcE0b5Uwycc6LpZHCnHRVHXL0141IU=.20c872ab-a4c1-4d40-b33b-a83f9f388cd1@github.com>
 <oL3zqb1UAkGuligOc8rqHp2k7anmX7q0Fqx3iM_uihM=.d22b00d4-b913-47d9-8584-5ba7a6254916@github.com>
 <jOd8n1AgDt9_YXdEsTN3d1zQGaRrL0J5pgCpw9EYegs=.8b357917-aa83-4291-9c9c-9da292e69db0@github.com>
Message-ID: <7M8ulxHKJ_fZ-YjePl0p8om1yeJBNugeDMJd7qyVvUE=.15044eff-0f8b-4094-9834-49cf96aac1d8@github.com>

On Mon, 27 Mar 2023 17:30:03 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> > > > @rkennke Question about ZGC and LockStack::contains(): how does this work with colored pointers? Don't we have to mask the color bits out somehow when comparing? E.g. using `ZAddress::offset()` ?
> 
> > > 
> 
> > > 
> 
> > > That would be a question for @fisk and/or @stefank. AFAIK, the color bits should be masked by ZGC barriers _before_ the oops enter the synchronization subsystem. But I kinda suspect that we are somehow triggering a ZGC bug here. Maybe we require barriers when reading oops from the lock-stack too?
> 
> > 
> 
> > Oops that are processed in Thread::oops_do should not have load barriers. Other oops should have load barriers.
> 
> 
> 
> Ok, good. The lockstack is processed in JavaThread::oops_do_no_frames() which is called from Thread::oops_do(). But help me here: I believe ZGC processes this stuff concurrently, right? So there might be a window where the lock-stack oops would be unprocessed. The lock-stack would not go under the stack-watermark machinery. And if some code (like JVMTI deadlock detection pause) inspects the lockstack, it might see invalid oops? Is that a plausible scenario, or am I missing something?

The JVMTI deadlock detection runs in a safepoint, doesn't it? Safepoints call start_processing on all threads in safepoint cleanup for non-GC safepoints. That means the lock stack oops should have been processed when the deadlock detection logic runs in a safepoint.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1485592271

From rkennke at openjdk.org  Mon Mar 27 18:14:36 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 27 Mar 2023 18:14:36 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <49yCA-Vx9caLf1KSVYnST3QsQ_kJZhny4KKt6kQnapQ=.66c7d6dd-a076-40d1-9dad-ebecf6805674@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
 <49yCA-Vx9caLf1KSVYnST3QsQ_kJZhny4KKt6kQnapQ=.66c7d6dd-a076-40d1-9dad-ebecf6805674@github.com>
Message-ID: <m3X6beuWnbj5OUgdmhaXtkPcD3RAaWHdlvrRxWHl9AY=.f1c8f4eb-55e5-4cc8-ab40-deb55f4d0f02@github.com>

On Fri, 24 Mar 2023 06:16:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>>  - Set condition flags correctly after fast-lock call on aarch64
>
> src/hotspot/share/runtime/arguments.cpp line 1997:
> 
>> 1995:   }
>> 1996:   if (UseHeavyMonitors) {
>> 1997:     FLAG_SET_DEFAULT(UseFastLocking, false);
> 
> Probably should be an error if both are set on the command-line.

I am not sure. UseFastLocking (or whatever we will call it in the near future) chooses between traditional and new stack-locking. We disable both by +UseHeavyMonitors. Also, +UseFastLocking is not really meant to be used by users, at least it is my intention to mainly turn it on programatically it when compact headers (Lilliput) is turned on. When also running with +UseHeavyMonitors, then it doesn't really matter which stack-locking impl is selected, neither would actually be used. I'd rather remove the explicit turning-off of UseFastMonitors under +UseHeavyMonitors.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1149623912

From rkennke at openjdk.org  Mon Mar 27 18:20:54 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 27 Mar 2023 18:20:54 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <7E8dbbZfswhEgM9yghtrXzUklVrZSCX2N15lhm7nQ_Q=.3a4a029c-bc04-4d0b-a501-a67775c1591b@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
 <7E8dbbZfswhEgM9yghtrXzUklVrZSCX2N15lhm7nQ_Q=.3a4a029c-bc04-4d0b-a501-a67775c1591b@github.com>
Message-ID: <ie_VUM367HIkqziAdyUIzNBzWKxY5IORqeBNCC4zfzM=.ee725901-b3a9-48f6-80f5-d1ef20dfff79@github.com>

On Fri, 24 Mar 2023 06:39:18 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>>  - Set condition flags correctly after fast-lock call on aarch64
>
> src/hotspot/share/runtime/synchronizer.cpp line 516:
> 
>> 514:       // No room on the lock_stack so fall-through to inflate-enter.
>> 515:     } else {
>> 516:       markWord mark = obj->mark();
> 
> why is it `mark` here but `header` above?

Oh I don't know. We are very inconsistent in our nomenclature here and use mark in some places and header in some others (e.g. OM::set_header() or the displaced_header() methods). The name mark is not really fitting and only still exists for historical reasons I believe (when one of the primary functions of the object header is to indicate GC marking?) However, the central data type is still called markWord so I changed my new code paths to use *mark as well. This probably warrants a round of codebase cleanup and consolidation later.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1149630607

From rkennke at openjdk.org  Mon Mar 27 18:51:03 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 27 Mar 2023 18:51:03 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <jOd8n1AgDt9_YXdEsTN3d1zQGaRrL0J5pgCpw9EYegs=.8b357917-aa83-4291-9c9c-9da292e69db0@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
 <S3HAUfb2-rymMhcE0b5Uwycc6LpZHCnHRVHXL0141IU=.20c872ab-a4c1-4d40-b33b-a83f9f388cd1@github.com>
 <oL3zqb1UAkGuligOc8rqHp2k7anmX7q0Fqx3iM_uihM=.d22b00d4-b913-47d9-8584-5ba7a6254916@github.com>
 <jOd8n1AgDt9_YXdEsTN3d1zQGaRrL0J5pgCpw9EYegs=.8b357917-aa83-4291-9c9c-9da292e69db0@github.com>
Message-ID: <wJVirnVGGmtOXDOxUviRWzoZ9mRiS9oBlypmjYay6UQ=.eb7cb183-1e9e-4cfb-b86f-d312214a4234@github.com>

On Mon, 27 Mar 2023 17:30:03 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>>> @rkennke Question about ZGC and LockStack::contains(): how does this work with colored pointers? Don't we have to mask the color bits out somehow when comparing? E.g. using `ZAddress::offset()` ?
>> 
>> That would be a question for @fisk and/or @stefank. AFAIK, the color bits should be masked by ZGC barriers *before* the oops enter the synchronization subsystem. But I kinda suspect that we are somehow triggering a ZGC bug here. Maybe we require barriers when reading oops from the lock-stack too?
>
>> > > @rkennke Question about ZGC and LockStack::contains(): how does this work with colored pointers? Don't we have to mask the color bits out somehow when comparing? E.g. using `ZAddress::offset()` ?
>> > 
>> > 
>> > That would be a question for @fisk and/or @stefank. AFAIK, the color bits should be masked by ZGC barriers _before_ the oops enter the synchronization subsystem. But I kinda suspect that we are somehow triggering a ZGC bug here. Maybe we require barriers when reading oops from the lock-stack too?
>> 
>> Oops that are processed in Thread::oops_do should not have load barriers. Other oops should have load barriers.
> 
> Ok, good. The lockstack is processed in JavaThread::oops_do_no_frames() which is called from Thread::oops_do(). But help me here: I believe ZGC processes this stuff concurrently, right? So there might be a window where the lock-stack oops would be unprocessed. The lock-stack would not go under the stack-watermark machinery. And if some code (like JVMTI deadlock detection pause) inspects the lockstack, it might see invalid oops? Is that a plausible scenario, or am I missing something?

> > > > > @rkennke Question about ZGC and LockStack::contains(): how does this work with colored pointers? Don't we have to mask the color bits out somehow when comparing? E.g. using `ZAddress::offset()` ?
> > 
> > 
> > > >
> > 
> > 
> > > >
> > 
> > 
> > > > That would be a question for @fisk and/or @stefank. AFAIK, the color bits should be masked by ZGC barriers _before_ the oops enter the synchronization subsystem. But I kinda suspect that we are somehow triggering a ZGC bug here. Maybe we require barriers when reading oops from the lock-stack too?
> > 
> > 
> > > 
> > 
> > 
> > > Oops that are processed in Thread::oops_do should not have load barriers. Other oops should have load barriers.
> > 
> > 
> > Ok, good. The lockstack is processed in JavaThread::oops_do_no_frames() which is called from Thread::oops_do(). But help me here: I believe ZGC processes this stuff concurrently, right? So there might be a window where the lock-stack oops would be unprocessed. The lock-stack would not go under the stack-watermark machinery. And if some code (like JVMTI deadlock detection pause) inspects the lockstack, it might see invalid oops? Is that a plausible scenario, or am I missing something?
> 
> The JVMTI deadlock detection runs in a safepoint, doesn't it? Safepoints call start_processing on all threads in safepoint cleanup for non-GC safepoints. That means the lock stack oops should have been processed when the deadlock detection logic runs in a safepoint.

There appears to be a single code-path that inspects the lock-stack (and also the usual stack under non-fast-locking) outside of safepoints:

V  [libjvm.so+0x180abd4]  Threads::owning_thread_from_monitor(ThreadsList*, ObjectMonitor*)+0x54  (threads.cpp:1433)
V  [libjvm.so+0x17a4bfc]  ObjectSynchronizer::get_lock_owner(ThreadsList*, Handle)+0x9c  (synchronizer.cpp:1109)
V  [libjvm.so+0x1802db0]  ThreadSnapshot::initialize(ThreadsList*, JavaThread*)+0x270  (threadService.cpp:942)
V  [libjvm.so+0x1803244]  ThreadDumpResult::add_thread_snapshot(JavaThread*)+0x5c  (threadService.cpp:567)
V  [libjvm.so+0x12a0f64]  jmm_GetThreadInfo+0x480  (management.cpp:1136)
j  sun.management.ThreadImpl.getThreadInfo1([JI[Ljava/lang/management/ThreadInfo;)V+0 java.management at 21-internal

Curiously, this seems to be in JMX code, which is also roughly where the failure happens. I came across this code a couple of times and couldn't really tell if it is safe to do that outside of a safepoint. In doubt I have to assume it is not, and maybe this is the source of the failure? WDYT?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1485692007

From eosterlund at openjdk.org  Mon Mar 27 19:37:09 2023
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 27 Mar 2023 19:37:09 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <wJVirnVGGmtOXDOxUviRWzoZ9mRiS9oBlypmjYay6UQ=.eb7cb183-1e9e-4cfb-b86f-d312214a4234@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
 <S3HAUfb2-rymMhcE0b5Uwycc6LpZHCnHRVHXL0141IU=.20c872ab-a4c1-4d40-b33b-a83f9f388cd1@github.com>
 <oL3zqb1UAkGuligOc8rqHp2k7anmX7q0Fqx3iM_uihM=.d22b00d4-b913-47d9-8584-5ba7a6254916@github.com>
 <jOd8n1AgDt9_YXdEsTN3d1zQGaRrL0J5pgCpw9EYegs=.8b357917-aa83-4291-9c9c-9da292e69db0@github.com>
 <wJVirnVGGmtOXDOxUviRWzoZ9mRiS9oBlypmjYay6UQ=.eb7cb183-1e9e-4cfb-b86f-d312214a4234@github.com>
Message-ID: <p6AUUxRzPB24g8p8WzsccW-eUpfkft0tZZYShM7krBo=.9d4718a8-f7cf-48c7-b99a-808265e3d57e@github.com>

On Mon, 27 Mar 2023 18:47:31 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> > > > > > @rkennke Question about ZGC and LockStack::contains(): how does this work with colored pointers? Don't we have to mask the color bits out somehow when comparing? E.g. using `ZAddress::offset()` ?
> 
> > > 
> 
> > > 
> 
> > > > >
> 
> > > 
> 
> > > 
> 
> > > > >
> 
> > > 
> 
> > > 
> 
> > > > > That would be a question for @fisk and/or @stefank. AFAIK, the color bits should be masked by ZGC barriers _before_ the oops enter the synchronization subsystem. But I kinda suspect that we are somehow triggering a ZGC bug here. Maybe we require barriers when reading oops from the lock-stack too?
> 
> > > 
> 
> > > 
> 
> > > > 
> 
> > > 
> 
> > > 
> 
> > > > Oops that are processed in Thread::oops_do should not have load barriers. Other oops should have load barriers.
> 
> > > 
> 
> > > 
> 
> > > Ok, good. The lockstack is processed in JavaThread::oops_do_no_frames() which is called from Thread::oops_do(). But help me here: I believe ZGC processes this stuff concurrently, right? So there might be a window where the lock-stack oops would be unprocessed. The lock-stack would not go under the stack-watermark machinery. And if some code (like JVMTI deadlock detection pause) inspects the lockstack, it might see invalid oops? Is that a plausible scenario, or am I missing something?
> 
> > 
> 
> > The JVMTI deadlock detection runs in a safepoint, doesn't it? Safepoints call start_processing on all threads in safepoint cleanup for non-GC safepoints. That means the lock stack oops should have been processed when the deadlock detection logic runs in a safepoint.
> 
> 
> 
> There appears to be a single code-path that inspects the lock-stack (and also the usual stack under non-fast-locking) outside of safepoints:
> 
> 
> 
> V  [libjvm.so+0x180abd4]  Threads::owning_thread_from_monitor(ThreadsList*, ObjectMonitor*)+0x54  (threads.cpp:1433)
> 
> V  [libjvm.so+0x17a4bfc]  ObjectSynchronizer::get_lock_owner(ThreadsList*, Handle)+0x9c  (synchronizer.cpp:1109)
> 
> V  [libjvm.so+0x1802db0]  ThreadSnapshot::initialize(ThreadsList*, JavaThread*)+0x270  (threadService.cpp:942)
> 
> V  [libjvm.so+0x1803244]  ThreadDumpResult::add_thread_snapshot(JavaThread*)+0x5c  (threadService.cpp:567)
> 
> V  [libjvm.so+0x12a0f64]  jmm_GetThreadInfo+0x480  (management.cpp:1136)
> 
> j  sun.management.ThreadImpl.getThreadInfo1([JI[Ljava/lang/management/ThreadInfo;)V+0 java.management at 21-internal
> 
> 
> 
> Curiously, this seems to be in JMX code, which is also roughly where the failure happens. I came across this code a couple of times and couldn't really tell if it is safe to do that outside of a safepoint. In doubt I have to assume it is not, and maybe this is the source of the failure? WDYT?

Could be. When not running a handshake or safepoint, you need to call start_processing manually on the target thread, which will ensure the oops are fixed until the next safepoint poll.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1485752396

From rrich at openjdk.org  Mon Mar 27 20:01:07 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 27 Mar 2023 20:01:07 GMT
Subject: RFR: 8296440: Remove Method* handling from
 cleanup_inline_caches_impl [v4]
In-Reply-To: <934WT-8efOj7Y1qLzngCkbzexOf3D8GQft5IxxnVVMY=.1e0c5456-c45d-4442-b242-5cd2985bf388@github.com>
References: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
 <cRC5U64EXBeJ2dCAVsRgxVyhmrljJE0olhuFUOLsda8=.158645d2-79d5-477e-9f30-311662c85384@github.com>
 <-RLv3wVSPQzSzrN4CVoXt5-xxQsflSazY-SO-pmZvF4=.e9c2efd5-6a96-4b6b-aa46-19003b75e8a3@github.com>
 <RdcStp9_lacGHSKDrR1BA_znTY6UnhajmEFupvUn15w=.62d0b62e-7e55-4836-bd66-01631703fc9c@github.com>
 <934WT-8efOj7Y1qLzngCkbzexOf3D8GQft5IxxnVVMY=.1e0c5456-c45d-4442-b242-5cd2985bf388@github.com>
Message-ID: <OmPgvrEn0UUt-WQcdl-sAPd0FzEkEWW57omc6rm5OU0=.87c75f9b-f5cb-42e7-80e3-9d1d8ad47668@github.com>

On Mon, 27 Mar 2023 17:10:41 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> All tier1-7 finished. Also Xcomp and stress. That is why I approved changes.

Good. Sorry, I've overlooked your approval.
Thanks, Richard.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12802#issuecomment-1485779172

From rrich at openjdk.org  Mon Mar 27 20:01:09 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 27 Mar 2023 20:01:09 GMT
Subject: RFR: 8296440: Remove Method* handling from
 cleanup_inline_caches_impl [v4]
In-Reply-To: <lJKJUle7AayRNMzUXGE9yGHKVlRvOe5YtAZGDnO7qUU=.859fa260-0b2f-4d0b-8030-303e5c856e99@github.com>
References: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
 <cRC5U64EXBeJ2dCAVsRgxVyhmrljJE0olhuFUOLsda8=.158645d2-79d5-477e-9f30-311662c85384@github.com>
 <lJKJUle7AayRNMzUXGE9yGHKVlRvOe5YtAZGDnO7qUU=.859fa260-0b2f-4d0b-8030-303e5c856e99@github.com>
Message-ID: <zah3JDP-tz_SNL88hwm6zyY1reaxbmFircdVaGAEVZc=.d630fe92-b27f-4793-9d09-ac92a51685bd@github.com>

On Mon, 27 Mar 2023 17:19:41 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The ClassLoaderData parts look good to me.

Thanks for reviewing it.
Richard.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12802#issuecomment-1485781021

From rkennke at openjdk.org  Mon Mar 27 20:24:14 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 27 Mar 2023 20:24:14 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v30]
In-Reply-To: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
Message-ID: <lzS3PlrHxm9JjbOyReXPNbqZJf5nb13kdMB6fFK52m0=.9262cfa5-dff5-4fcf-aaf0-5a4e993c5071@github.com>

> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
> 
> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p
 rotocols.
> 
> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
> 
> 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
> 
> 
> Testing:
>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
> 
> ### Performance
> 
> #### Simple Microbenchmark
> 
> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
> 
> |  | x86_64 | aarch64 |
> | -- | -- | -- |
> | -UseFastLocking | 20.651 | 20.764 |
> | +UseFastLocking | 18.896 | 18.908 |
> 
> 
> #### Renaissance
> 
> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
> -- | -- | -- | -- | -- | -- | -- | --
> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Ensure safepoint when processing lock-stack

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10907/files
  - new: https://git.openjdk.org/jdk/pull/10907/files/37f061b0..32fdda25

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=29
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=28-29

  Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10907.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10907/head:pull/10907

PR: https://git.openjdk.org/jdk/pull/10907

From kbarrett at openjdk.org  Mon Mar 27 21:46:01 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 27 Mar 2023 21:46:01 GMT
Subject: RFR: 8297539: Use PrimitiveConversions::cast for local uses of the
 int<->float union conversion trick [v2]
In-Reply-To: <BNvVp16bt2f79ztwX9fDwosj5widSV9ZnpUoyE6FTdg=.62382e84-40f4-495c-b10c-ba085d750015@github.com>
References: <Fc1LufRzwqeQjXSwyVm3FaJWzbaazUXyArTYPLlGrwM=.034cb09b-79d8-49a1-a68d-b5914a9cc214@github.com>
 <BNvVp16bt2f79ztwX9fDwosj5widSV9ZnpUoyE6FTdg=.62382e84-40f4-495c-b10c-ba085d750015@github.com>
Message-ID: <5_SWBrsfPmPQ_4RE2VMrgSLbNwLatySUENlLJ07Cu5w=.38ba07dc-5daa-4d98-a8b1-d566383ccdf7@github.com>

On Mon, 27 Mar 2023 14:32:22 GMT, Afshin Zafari <duke at openjdk.org> wrote:

>> **Only** the instances of using `union` for converting `int` to `float` are replaced with call to `PrimitiveConversions::cast<To>(From)` method. Some few cases with conversion of `long` <->`double` are also replaced with `PrimitiveConversions::cast<To>(From)`. The other instances where the union contains other types of fields than `int` and `float` are left unchanged.
>> 
>> ### Test
>> local hotspot:tier1
>> mach5 tiers 1-5
>
> Afshin Zafari has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - order of headers in includes.
>  - order of headers corrected

Overall this looks good.  Just a few minor nits and naming issues.

src/hotspot/cpu/aarch64/assembler_aarch64.cpp line 503:

> 501: 
> 502: static float unpack(unsigned value) {
> 503:   unsigned ival;

I'd like this to be initialized rather than assigned on the next line.

src/hotspot/cpu/arm/assembler_arm.hpp line 288:

> 286:     virtual bool f_lo_is_null() const { return (_num_bits & ((1 << 19) - 1)) == 0; }
> 287:     virtual int e() const { return ((_num_bits << 1) >> (23+1)) - 127; }
> 288:     virtual unsigned int s() const { return _num_bits >> 31; }

These should be override rather than virtual.  Similarly for double_num.

src/hotspot/cpu/arm/assembler_arm.hpp line 291:

> 289: 
> 290:    private:
> 291:     unsigned int _num_bits;

The name _num_bits is confusing; I spent a few moments trying to figure out what it was the number
of bits of.  I think just _bits or _raw_bits or something like that would be better.  Similarly in double_num.
I also think the class names would be better with "num" => "bits", but that likely has fannout, so maybe
later (if at all).

src/hotspot/cpu/arm/macroAssembler_arm.cpp line 677:

> 675: void MacroAssembler::mov_float(FloatRegister fd, jfloat c, AsmCondition cond) {
> 676:   Label skip_constant;
> 677:   jint accessor_i = PrimitiveConversions::cast<jint>(c);

I don't think the "accessor_" prefix has any meaning with this change, and just seems odd.
Just call the variable "bits" or "float_bits" or something like that?

src/hotspot/share/runtime/sharedRuntime.cpp line 242:

> 240:   // infinity operands.
> 241:   juint xbits_i = PrimitiveConversions::cast<juint>(x);
> 242:   juint ybits_i = PrimitiveConversions::cast<juint>(y);

The "_i" suffix here doesn't have any meaning anymore.  Just "xbits" and "ybits" would be better.
Similarly in below in "drem".

-------------

Changes requested by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13136#pullrequestreview-1359895552
PR Review Comment: https://git.openjdk.org/jdk/pull/13136#discussion_r1149807740
PR Review Comment: https://git.openjdk.org/jdk/pull/13136#discussion_r1149812015
PR Review Comment: https://git.openjdk.org/jdk/pull/13136#discussion_r1149813388
PR Review Comment: https://git.openjdk.org/jdk/pull/13136#discussion_r1149817150
PR Review Comment: https://git.openjdk.org/jdk/pull/13136#discussion_r1149818559

From kbarrett at openjdk.org  Tue Mar 28 00:06:23 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 28 Mar 2023 00:06:23 GMT
Subject: RFR: 8303805: [REDO] JDK-8302189 and JDK-8302799
Message-ID: <LrDLITpu9mfyyL30QCXITE8nFEG-NfcZi0DvqvDF7Pg=.5d3fb62e-b689-42f0-ac75-4efee44ba2af@github.com>

Please review this redo of the following changes:
8302189: Mark assertion failures noreturn
8302799: Refactor Debugging variable usage for noreturn crash reporting

The original change tripped over a bug the handling of noreturn and
__builtin_unreachable by Xcode12 (so probably generic clang12 and perhaps
earlier).  It seems to have been fixed in Xcode13 (and probably other uses of
clang13), but we're not yet ready to require that version.

As such, we've taken the original change and kludged around the problem for
now.  The kludge should be removed once we require clang13+.

As a reminder, the original change that was backed out did the following:
https://github.com/openjdk/jdk/pull/12845

(1) Changed how assertions were suppressed when running the various debugging
commands defined in debug.cpp.  The failure reporting functions used to just
return if the Debugging variable was set (by a debug command invocation).
Now, debug command invocation establishes a DebuggingContext object which
causes asserts to bypass the check entirely.

(2) Added [[noreturn]] attributes to error reporting functions declared in
debug.hpp.

This change consists of
(1) Reapply the change from PR#12845.
(2) A minor improvement to the DebuggingContext destructor.
(3) Replace uses of [[noreturn]] with new ATTRIBUTE_NORETURN macro (the kludge).

The ATTRIBUTE_NORETURN macro expands to `[[noreturn]]` unless the compiler is
clang and its version is less than 13, which it expands to nothing.

The replaced [[noreturn]] uses include both those added by JDK-8302189 and
those added by the earlier JDK-8302798.

This is problematic in the long run.  It prevents the removal of otherwise
obsolete and unreachable code following a call to a noreturn function.  We
have such code in various places because these functions were previously not
noreturn (and with this change still aren't for clang12 and prior).  It may
also require the inclusion of such code in future changes.  This may result in
change testing on Linux and/or Windows missing problems that will only show up
when testing on a clang-using platform.

We're really going to want to require a minimum of clang13 sooner rather than
later.  Unfortunately, we've run into other problems with Xcode13 and Xcode14,
and the aix-ppc maintainers have only just begun testing xlclang++ 17.1.  (The
version they have been using is based on clang3!)  Hence this kludge for now,
to permit use of gcc12 (JDK-8294031).

Testing:
mach5 tier1-7.

-------------

Commit messages:
 - attribute macro
 - tidy destructor
 - redo from PR12845

Changes: https://git.openjdk.org/jdk/pull/13199/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13199&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303805
  Stats: 232 lines in 12 files changed: 180 ins; 19 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/13199.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13199/head:pull/13199

PR: https://git.openjdk.org/jdk/pull/13199

From dlong at openjdk.org  Tue Mar 28 00:20:59 2023
From: dlong at openjdk.org (Dean Long)
Date: Tue, 28 Mar 2023 00:20:59 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v30]
In-Reply-To: <lzS3PlrHxm9JjbOyReXPNbqZJf5nb13kdMB6fFK52m0=.9262cfa5-dff5-4fcf-aaf0-5a4e993c5071@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <lzS3PlrHxm9JjbOyReXPNbqZJf5nb13kdMB6fFK52m0=.9262cfa5-dff5-4fcf-aaf0-5a4e993c5071@github.com>
Message-ID: <EzfZGy8hLDki3v4z21KTA7D4FAmDgHcSuGIKfN4Kms8=.c3a5c505-fe31-4f3c-ac75-2d156dadadae@github.com>

On Mon, 27 Mar 2023 20:24:14 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Ensure safepoint when processing lock-stack

src/hotspot/cpu/aarch64/aarch64.ad line 3844:

> 3842: 
> 3843:         // Indicate success on completion.
> 3844:         __ cmp(oop, oop); // Force ZF=1 to indicate success.

It looks like `fast_lock` already sets ZF=1 on success/fall-through.  Why not document this as part of the interface, then this `cmp` will be redundant?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1149902898

From dlong at openjdk.org  Tue Mar 28 00:34:00 2023
From: dlong at openjdk.org (Dean Long)
Date: Tue, 28 Mar 2023 00:34:00 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v30]
In-Reply-To: <lzS3PlrHxm9JjbOyReXPNbqZJf5nb13kdMB6fFK52m0=.9262cfa5-dff5-4fcf-aaf0-5a4e993c5071@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <lzS3PlrHxm9JjbOyReXPNbqZJf5nb13kdMB6fFK52m0=.9262cfa5-dff5-4fcf-aaf0-5a4e993c5071@github.com>
Message-ID: <xealsXw8bhJVPINuEVHGYsxxNOcYMtMtqq9BEiilgtg=.8ca086fc-dddc-4692-b628-40f026fbb9e0@github.com>

On Mon, 27 Mar 2023 20:24:14 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Ensure safepoint when processing lock-stack

src/hotspot/cpu/aarch64/aarch64.ad line 3953:

> 3951: 
> 3952:         // Indicate success on completion.
> 3953:         __ cmp(oop, oop);

Redundant, based on current implementation of `fast_unlock`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1149908732

From sspitsyn at openjdk.org  Tue Mar 28 02:37:31 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 28 Mar 2023 02:37:31 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v5]
In-Reply-To: <QFUF6VyM9-muaNFtSOi4txCaieDrNYmTejKGR5rk-Lw=.de2d5d71-60c1-4d7d-8c9a-1131415c9725@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <27JLa60WeywSMcJj-6KfaQD8RBnwBbAvcc0gecc-3h4=.a2a25b70-9e90-4551-af90-35aed3d57b59@github.com>
 <qVfNBfPP6pizIr16-aXD851jbQ8ZNOV7BvH_Yt-jrbo=.d22c7807-c952-4337-ae69-60a8070ad852@github.com>
 <0J5IbRtwgK7aOiXWfWBSVLo0RniWf6rRfvqmqA59j5A=.a7cf4ca2-a750-4281-9c78-285ca58e21da@github.com>
 <QFUF6VyM9-muaNFtSOi4txCaieDrNYmTejKGR5rk-Lw=.de2d5d71-60c1-4d7d-8c9a-1131415c9725@github.com>
Message-ID: <yOGn9_cU3rV9OKgVHvmbLIzu9TU4cZSGQkAFHG4AoXM=.b83a5ed2-98e8-4bde-a8d5-d7e6830c04f5@github.com>

On Fri, 24 Mar 2023 19:09:57 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> It is for yielding. Do you think we need this with a bigger frequency?
>
> I guess the question then is why the need to yield. It just seems a bit odd that I thought the main point of this loop was to keep busy calling `breakpointCheck()`, and I don't see how doing a yield 1 out of every 1,000,000 iterations relates to that.

Thank you for pointing to the `breakpointCheck()` as it is not needed at all, so I've removed it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1149962945

From dlong at openjdk.org  Tue Mar 28 02:47:59 2023
From: dlong at openjdk.org (Dean Long)
Date: Tue, 28 Mar 2023 02:47:59 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v30]
In-Reply-To: <lzS3PlrHxm9JjbOyReXPNbqZJf5nb13kdMB6fFK52m0=.9262cfa5-dff5-4fcf-aaf0-5a4e993c5071@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <lzS3PlrHxm9JjbOyReXPNbqZJf5nb13kdMB6fFK52m0=.9262cfa5-dff5-4fcf-aaf0-5a4e993c5071@github.com>
Message-ID: <fEgcjjAIbSeXWTjvUOTufaAjBHiO96-OeMBhFP9A9So=.e53c82ae-5285-439d-8259-5f348623f375@github.com>

On Mon, 27 Mar 2023 20:24:14 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Ensure safepoint when processing lock-stack

src/hotspot/share/interpreter/interpreterRuntime.cpp line 740:

> 738:   if (!UseHeavyMonitors && UseFastLocking) {
> 739:     // This is a hack to get around the limitation of registers in x86_32. We really
> 740:     // send an oopDesc* instead of a BasicObjectLock*.

I don't understand what this is referring to.  Trying to avoid passing an extra argument?

src/hotspot/share/interpreter/interpreterRuntime.cpp line 746:

> 744:     ObjectSynchronizer::enter(h_obj, nullptr, current);
> 745:     return;
> 746:   }

Why not put this code in a new function declared as InterpreterRuntime::monitorenter(JavaThread* current, oop obj) and have the caller decide which one to call?

src/hotspot/share/oops/oop.cpp line 123:

> 121:   // Header verification: the mark is typically non-zero. If we're
> 122:   // at a safepoint, it must not be zero. fast-locking does allow the
> 123:   // mark to be zero at a safepoint.

Suggestion:

  // at a safepoint, it must not be zero, except when UseFastLocking is turned on.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1149918325
PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1149918510
PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1149967043

From dlong at openjdk.org  Tue Mar 28 02:48:01 2023
From: dlong at openjdk.org (Dean Long)
Date: Tue, 28 Mar 2023 02:48:01 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <49yCA-Vx9caLf1KSVYnST3QsQ_kJZhny4KKt6kQnapQ=.66c7d6dd-a076-40d1-9dad-ebecf6805674@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
 <49yCA-Vx9caLf1KSVYnST3QsQ_kJZhny4KKt6kQnapQ=.66c7d6dd-a076-40d1-9dad-ebecf6805674@github.com>
Message-ID: <sHRO3vkFBg1k2HFCIpLFdw4X4NFH6HWgPhEhyk1yB_c=.2d3b723d-3660-4ae5-a83b-c3d4fd44b421@github.com>

On Fri, 24 Mar 2023 06:15:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>>  - Set condition flags correctly after fast-lock call on aarch64
>
> src/hotspot/share/oops/oop.cpp line 126:
> 
>> 124:   // Outside of a safepoint, the header could be changing (for example,
>> 125:   // another thread could be inflating a lock on this object).
>> 126:   if (ignore_mark_word || UseFastLocking) {
> 
> Not clear why UseFastLocking appears here instead of in the return expression - especially given the comment above.

I have the same question.  Based on the comment, I would expect
`return !SafepointSynchronize::is_at_safepoint() || UseFastLocking`;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1149966288

From sspitsyn at openjdk.org  Tue Mar 28 02:51:34 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 28 Mar 2023 02:51:34 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v5]
In-Reply-To: <QFUF6VyM9-muaNFtSOi4txCaieDrNYmTejKGR5rk-Lw=.de2d5d71-60c1-4d7d-8c9a-1131415c9725@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <27JLa60WeywSMcJj-6KfaQD8RBnwBbAvcc0gecc-3h4=.a2a25b70-9e90-4551-af90-35aed3d57b59@github.com>
 <qVfNBfPP6pizIr16-aXD851jbQ8ZNOV7BvH_Yt-jrbo=.d22c7807-c952-4337-ae69-60a8070ad852@github.com>
 <0J5IbRtwgK7aOiXWfWBSVLo0RniWf6rRfvqmqA59j5A=.a7cf4ca2-a750-4281-9c78-285ca58e21da@github.com>
 <QFUF6VyM9-muaNFtSOi4txCaieDrNYmTejKGR5rk-Lw=.de2d5d71-60c1-4d7d-8c9a-1131415c9725@github.com>
Message-ID: <xhHEoYgjCu8DKkxDdQpuouRPNVJ3TISxw2fuoB2y9JI=.99ee49ec-08d2-4a93-b3c1-4520474248c2@github.com>

On Fri, 24 Mar 2023 19:13:39 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> It is needed to balance enabling/disabling notifyJvmti mode with the ThreadStart/VirtualThreadStart events.
>> Otherwise, many mode switches can be observed without any events which is not interesting.
>> We need to allow virtual threads to execute a little bit after a mode switch.
>
> Shouldn't that be the caller's responsibility? Including a comment would be helpful.

Okay, moved to the caller. In fact, I've refactored the test even more for safety purposes. Will describe it separately.

>> Good question. We almost always do it in the JVMTI tests including `serviceability/jvmti/vthread` and `vmTestbase/nsk/jvmti` tests. Examples are 22 `serviceability/jvmti/vthread` tests.
>
> Are you saying it's not needed, but you included it to be consistent with other tests?

I remember it was really needed some time ago but do not remember why.
Removed it now. Then we have a technical debt to get rid of this in all JVMTI tests with the `-agentlib` option.

>> I'm not sure if it is really needed. 60 virtual threads are started.
>> Some of them are executed long enough before shutdown.
>> We can just increase the number of threads if necessary.
>
> ok

I've refactored the test, and it has impacted this fragment. Please, see my comment above.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1149968287
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1149967613
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1149969217

From dholmes at openjdk.org  Tue Mar 28 02:52:00 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 28 Mar 2023 02:52:00 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v30]
In-Reply-To: <lzS3PlrHxm9JjbOyReXPNbqZJf5nb13kdMB6fFK52m0=.9262cfa5-dff5-4fcf-aaf0-5a4e993c5071@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <lzS3PlrHxm9JjbOyReXPNbqZJf5nb13kdMB6fFK52m0=.9262cfa5-dff5-4fcf-aaf0-5a4e993c5071@github.com>
Message-ID: <2cIUWaQL9GilRFtckC9SpcJVet_0Rb8SmFS1tfe8AWE=.35713c3e-1f5d-45e5-8a3c-d732070d7b81@github.com>

On Mon, 27 Mar 2023 20:24:14 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Ensure safepoint when processing lock-stack

src/hotspot/share/runtime/threads.cpp line 1433:

> 1431: 
> 1432: JavaThread* Threads::owning_thread_from_monitor(ThreadsList* t_list, ObjectMonitor* monitor) {
> 1433:   assert(SafepointSynchronize::is_at_safepoint(), "not safe outside of safepoint");

Shouldn't this be gated on UseFastLocking?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1149969081

From dholmes at openjdk.org  Tue Mar 28 03:03:00 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 28 Mar 2023 03:03:00 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v30]
In-Reply-To: <lzS3PlrHxm9JjbOyReXPNbqZJf5nb13kdMB6fFK52m0=.9262cfa5-dff5-4fcf-aaf0-5a4e993c5071@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <lzS3PlrHxm9JjbOyReXPNbqZJf5nb13kdMB6fFK52m0=.9262cfa5-dff5-4fcf-aaf0-5a4e993c5071@github.com>
Message-ID: <_b88qICP5AK4NgLpW0fXKgoa8ObWoZM1GvXKpoNMxlU=.85187d4a-968e-4283-b46d-4290ee3cc402@github.com>

On Mon, 27 Mar 2023 20:24:14 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Ensure safepoint when processing lock-stack

src/hotspot/share/runtime/lockStack.hpp line 43:

> 41:   // efficient addressing in generated code.
> 42:   int _offset;
> 43:   oop _base[CAPACITY];

Should we be using `OopHandle` here rather than raw oops? Would that not avoid issues with scanning the lock-stack only during safepoints?

Another alternative for a STW safepoint would be to do a handshake with the target threads.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1149972911

From dlong at openjdk.org  Tue Mar 28 03:03:01 2023
From: dlong at openjdk.org (Dean Long)
Date: Tue, 28 Mar 2023 03:03:01 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v30]
In-Reply-To: <lzS3PlrHxm9JjbOyReXPNbqZJf5nb13kdMB6fFK52m0=.9262cfa5-dff5-4fcf-aaf0-5a4e993c5071@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <lzS3PlrHxm9JjbOyReXPNbqZJf5nb13kdMB6fFK52m0=.9262cfa5-dff5-4fcf-aaf0-5a4e993c5071@github.com>
Message-ID: <RA4xVGZEjGRTdzA6qIF2FBvv9RaigwS-LhdYhx02I1E=.b17634ab-1acc-4199-ae0e-cb33cc119a64@github.com>

On Mon, 27 Mar 2023 20:24:14 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Ensure safepoint when processing lock-stack

src/hotspot/share/runtime/objectMonitor.inline.hpp line 36:

> 34: #include "runtime/synchronizer.hpp"
> 35: 
> 36: inline intptr_t ObjectMonitor::is_entered(JavaThread* current) const {

Suggestion:

inline bool ObjectMonitor::is_entered(JavaThread* current) const {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1149974098

From sspitsyn at openjdk.org  Tue Mar 28 03:04:32 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 28 Mar 2023 03:04:32 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v5]
In-Reply-To: <KZBKVM6-D0Rx1vmgEQPBAfr08_YJlvELF8kNkurYKBI=.654850bf-514f-4c82-ba47-0f9cc8712ed7@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <27JLa60WeywSMcJj-6KfaQD8RBnwBbAvcc0gecc-3h4=.a2a25b70-9e90-4551-af90-35aed3d57b59@github.com>
 <cidKu3X9LJvpVXA03joOke4E8_k5w9QYrUWkcIZg_ec=.ded16bd1-9d08-49af-86b5-a6758f7c4b47@github.com>
 <KZBKVM6-D0Rx1vmgEQPBAfr08_YJlvELF8kNkurYKBI=.654850bf-514f-4c82-ba47-0f9cc8712ed7@github.com>
Message-ID: <2rgTBRBpumpvNwpss9mVY6nySwat95LU9fJ6y04hR-Y=.7f81090b-37fd-4fc2-9b9e-92d29a771481@github.com>

On Fri, 24 Mar 2023 02:00:57 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1581:
>> 
>>> 1579:     return false;
>>> 1580:   }
>>> 1581:   if (JvmtiVTMSTransitionDisabler::VTMS_notify_jvmti_events()) {
>> 
>> shouldn't be
>>  if (!JvmtiVTMSTransitionDisabler::VTMS_notify_jvmti_events()) {
>> here?
>
> This is nice catch, thanks!

Fixed it now and discovered some issues which have not seen before.
It occurred that disabling notifyJvmti events when virtual threads are executed is unsafe.
It is not easy to fix these issue and there is no real need to.
So that I've refactored the test to do multiple testing cycles.
Each testing cycle disables notifyJvmti events when there are no virtual threads executed then starts a number of threads, then enables notifyJvmti events and shuts down the virtual threads.
The test also extended to post more JVMTI events:  `VirtualThreadStart`, `VirtualThreadEnd`, `ThreadStart` and `ThreadEnd`.
Also, I saw some intermittent crashes with double-deallocation of JvmtiThreadState's which belongs to vthreads.
So that, I have extend the VM_InitNotifyJvmtiEventsMode to do more corrections.
Will push my fixes after my mach5 test runs are finished.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1149975274

From fyang at openjdk.org  Tue Mar 28 03:13:47 2023
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 28 Mar 2023 03:13:47 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v14]
In-Reply-To: <Fh6g8Qtdd0VS96WT8xUIrc4iiPfFICaFR5GG0IYpP8s=.fd3eca92-b604-4d3c-b31e-a731880e4efb@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <Fh6g8Qtdd0VS96WT8xUIrc4iiPfFICaFR5GG0IYpP8s=.fd3eca92-b604-4d3c-b31e-a731880e4efb@github.com>
Message-ID: <7-oX5-8j4W1x_mcyc4Hwcluqyb2_aBjNjSZLdJNT2DA=.71d06f76-e6c2-4f07-80d3-00ddc00101ab@github.com>

On Mon, 27 Mar 2023 14:43:04 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
>> 
>> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
>> 
>> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
>> 
>> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
>> 
>> This change supports the following platforms: x86, aarch64, PPC, and RISCV
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   RISCV patch and aarch64 improvement

Updated RISC-V part looks good.

-------------

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12778#pullrequestreview-1360137045

From dlong at openjdk.org  Tue Mar 28 03:14:02 2023
From: dlong at openjdk.org (Dean Long)
Date: Tue, 28 Mar 2023 03:14:02 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v30]
In-Reply-To: <lzS3PlrHxm9JjbOyReXPNbqZJf5nb13kdMB6fFK52m0=.9262cfa5-dff5-4fcf-aaf0-5a4e993c5071@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <lzS3PlrHxm9JjbOyReXPNbqZJf5nb13kdMB6fFK52m0=.9262cfa5-dff5-4fcf-aaf0-5a4e993c5071@github.com>
Message-ID: <J2WGsNtKgCSbRaFU-NE2TRmYCbYvVS6T7PkKUyHdO7E=.592c9096-e915-4c1b-ad9f-75c62feaee1f@github.com>

On Mon, 27 Mar 2023 20:24:14 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Ensure safepoint when processing lock-stack

src/hotspot/share/runtime/synchronizer.cpp line 506:

> 504:               return;
> 505:             }
> 506:             // Otherwise retry.

Why is retry important for the new code but not the old code?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1149978809

From dholmes at openjdk.org  Tue Mar 28 04:19:30 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 28 Mar 2023 04:19:30 GMT
Subject: RFR: 8303805: [REDO] JDK-8302189 and JDK-8302799
In-Reply-To: <LrDLITpu9mfyyL30QCXITE8nFEG-NfcZi0DvqvDF7Pg=.5d3fb62e-b689-42f0-ac75-4efee44ba2af@github.com>
References: <LrDLITpu9mfyyL30QCXITE8nFEG-NfcZi0DvqvDF7Pg=.5d3fb62e-b689-42f0-ac75-4efee44ba2af@github.com>
Message-ID: <CjjKkqGw9hV6L0CaAn5lUXQlG0hJ5qw6dW5IrBOBc8Y=.06325407-32c3-43b9-9019-b595a007cd99@github.com>

On Mon, 27 Mar 2023 23:57:45 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this redo of the following changes:
> 8302189: Mark assertion failures noreturn
> 8302799: Refactor Debugging variable usage for noreturn crash reporting
> 
> The original change tripped over a bug the handling of noreturn and
> __builtin_unreachable by Xcode12 (so probably generic clang12 and perhaps
> earlier).  It seems to have been fixed in Xcode13 (and probably other uses of
> clang13), but we're not yet ready to require that version.
> 
> As such, we've taken the original change and kludged around the problem for
> now.  The kludge should be removed once we require clang13+.
> 
> As a reminder, the original change that was backed out did the following:
> https://github.com/openjdk/jdk/pull/12845
> 
> (1) Changed how assertions were suppressed when running the various debugging
> commands defined in debug.cpp.  The failure reporting functions used to just
> return if the Debugging variable was set (by a debug command invocation).
> Now, debug command invocation establishes a DebuggingContext object which
> causes asserts to bypass the check entirely.
> 
> (2) Added [[noreturn]] attributes to error reporting functions declared in
> debug.hpp.
> 
> This change consists of
> (1) Reapply the change from PR#12845.
> (2) A minor improvement to the DebuggingContext destructor.
> (3) Replace uses of [[noreturn]] with new ATTRIBUTE_NORETURN macro (the kludge).
> 
> The ATTRIBUTE_NORETURN macro expands to `[[noreturn]]` unless the compiler is
> clang and its version is less than 13, which it expands to nothing.
> 
> The replaced [[noreturn]] uses include both those added by JDK-8302189 and
> those added by the earlier JDK-8302798.
> 
> This is problematic in the long run.  It prevents the removal of otherwise
> obsolete and unreachable code following a call to a noreturn function.  We
> have such code in various places because these functions were previously not
> noreturn (and with this change still aren't for clang12 and prior).  It may
> also require the inclusion of such code in future changes.  This may result in
> change testing on Linux and/or Windows missing problems that will only show up
> when testing on a clang-using platform.
> 
> We're really going to want to require a minimum of clang13 sooner rather than
> later.  Unfortunately, we've run into other problems with Xcode13 and Xcode14,
> and the aix-ppc maintainers have only just begun testing xlclang++ 17.1.  (The
> version they have been using is based on clang3!)  Hence this kludge for now,
> to permit use of gcc12 (JDK-8294031).
> 
> Testing:
> mach5 tier1-7.

Looks good. Thanks for the detailed explanation and the separate commits.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13199#pullrequestreview-1360177767

From dholmes at openjdk.org  Tue Mar 28 04:27:35 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 28 Mar 2023 04:27:35 GMT
Subject: RFR: 8304725: AsyncGetCallTrace can cause SIGBUS on M1 [v4]
In-Reply-To: <EQIl485VD7pz67UoYHG57Pv8FA-KkLVOb_J7ynNfyi0=.81b07902-2af9-42cf-bc6a-147107143075@github.com>
References: <XtBvYsLSljF-NTYtEuYvx35NrdX3-VSu_MmirMCLfKc=.3b4e81e3-d53e-445e-85e4-0fb5e6ded7be@github.com>
 <EQIl485VD7pz67UoYHG57Pv8FA-KkLVOb_J7ynNfyi0=.81b07902-2af9-42cf-bc6a-147107143075@github.com>
Message-ID: <vb_tJw87lxdss47u5gpDqse7T7egoknVVhfyyxoCsC8=.9ce0ab34-ea43-41e4-a451-9e87aa56fa98@github.com>

On Fri, 24 Mar 2023 10:35:36 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Fixes the issue by transitioning the thread into the WXWrite mode while walking the stack in AsyncGetCallTrace.
>> 
>> Tested on my M1 mac.
>
> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove misc lines
>  - Disable caching in ASGCT

Changes requested by dholmes (Reviewer).

src/hotspot/share/runtime/thread.hpp line 641:

> 639:   void set_in_asgct(bool value) { _in_asgct = value; }
> 640:   static bool current_in_asgct() {
> 641:     Thread *cur = Thread::current();

You need to use`current_or_null_safe` here as you may be in a signal handling context.

src/hotspot/share/runtime/thread.hpp line 651:

> 649:  public:
> 650:   ThreadInAsgct(Thread* thread) : _thread(thread) {
> 651:     assert(thread != NULL, "invariant");

s/NULL/nullptr/

-------------

PR Review: https://git.openjdk.org/jdk/pull/13144#pullrequestreview-1360181938
PR Review Comment: https://git.openjdk.org/jdk/pull/13144#discussion_r1150010290
PR Review Comment: https://git.openjdk.org/jdk/pull/13144#discussion_r1150010653

From dzhang at openjdk.org  Tue Mar 28 06:08:29 2023
From: dzhang at openjdk.org (Dingli Zhang)
Date: Tue, 28 Mar 2023 06:08:29 GMT
Subject: RFR: 8305008: RISC-V: Factor out immediate checking functions from
 assembler_riscv.inline.hpp
Message-ID: <zOPJRtrXmBK17ZgSm-THTp8qCXhh7tSNg6VRVFoLz9Y=.763009a8-a651-499d-a0e1-f114f3c842f0@github.com>

The call-point to 'is_imm_in_range', 'is_unsigned_imm_in_range' and 'is_offset_in_range' in assembler_riscv.inline.hpp could to be replaced with shared code function 'is_simm' and 'is_uimm'.

For 'is_imm_in_range', if align_bits = 0, then the call point can be changed to call 'is_simm'. If align_bits = 1, then an additional summation judgement is added to determine if it is a multiple of 2. For 'is_unsigned_imm_in_range', we can first determine if it is greater than 0, and then call 'is_uimm' further. 'is_offset_in_range' can be changed directly to call 'is_simm'. This patch also refactored for is_valid_riscv64_address and movptr.

This patch removed the original functions from assembler_riscv.inline.hpp and defined some fixed-width checking functions based on the number of immediate or offset bits in the spec[1]. At the same time, we also adjusted two includes to fix the compilation error after the modification.

This patch also renames the function 'operand_valid_for_add_immediate' to 'operand_valid_for_add_sub_immediate' to make it consistent with its usage.

Finally, this patch modified the return value in os::non_memory_address_word to avoid an imm64 value of -1 in MacroAssembler::movptr.

[1] https://github.com/riscv/riscv-isa-manual/releases/download/draft-20230131-c0b298a/riscv-spec.pdf

### Testing:

On Unmatched with release build:
- [x] Tier1 tests
- [ ] Tier2 tests
- [ ] Tier3 tests

-------------

Commit messages:
 - RISC-V: Factor out immediate checking functions from assembler_riscv.inline.hpp

Changes: https://git.openjdk.org/jdk/pull/13202/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13202&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305008
  Stats: 156 lines in 11 files changed: 29 ins; 10 del; 117 mod
  Patch: https://git.openjdk.org/jdk/pull/13202.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13202/head:pull/13202

PR: https://git.openjdk.org/jdk/pull/13202

From dzhang at openjdk.org  Tue Mar 28 06:10:29 2023
From: dzhang at openjdk.org (Dingli Zhang)
Date: Tue, 28 Mar 2023 06:10:29 GMT
Subject: RFR: 8305008: RISC-V: Factor out immediate checking functions from
 assembler_riscv.inline.hpp
In-Reply-To: <zOPJRtrXmBK17ZgSm-THTp8qCXhh7tSNg6VRVFoLz9Y=.763009a8-a651-499d-a0e1-f114f3c842f0@github.com>
References: <zOPJRtrXmBK17ZgSm-THTp8qCXhh7tSNg6VRVFoLz9Y=.763009a8-a651-499d-a0e1-f114f3c842f0@github.com>
Message-ID: <e5NuKyeESiNeAsFzb_1PbhCVx4N4tUEcFr-s8rqd-RA=.89caa00c-08d8-437e-9b56-b50a5d01fde2@github.com>

On Tue, 28 Mar 2023 05:59:49 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

> The call-point to 'is_imm_in_range', 'is_unsigned_imm_in_range' and 'is_offset_in_range' in assembler_riscv.inline.hpp could to be replaced with shared code function 'is_simm' and 'is_uimm'.
> 
> For 'is_imm_in_range', if align_bits = 0, then the call point can be changed to call 'is_simm'. If align_bits = 1, then an additional summation judgement is added to determine if it is a multiple of 2. For 'is_unsigned_imm_in_range', we can first determine if it is greater than 0, and then call 'is_uimm' further. 'is_offset_in_range' can be changed directly to call 'is_simm'. This patch also refactored for is_valid_riscv64_address and movptr.
> 
> This patch removed the original functions from assembler_riscv.inline.hpp and defined some fixed-width checking functions based on the number of immediate or offset bits in the spec[1]. At the same time, we also adjusted two includes to fix the compilation error after the modification.
> 
> This patch also renames the function 'operand_valid_for_add_immediate' to 'operand_valid_for_add_sub_immediate' to make it consistent with its usage.
> 
> Finally, this patch modified the return value in os::non_memory_address_word to avoid an imm64 value of -1 in MacroAssembler::movptr.
> 
> [1] https://github.com/riscv/riscv-isa-manual/releases/download/draft-20230131-c0b298a/riscv-spec.pdf
> 
> ### Testing:
> 
> On Unmatched with release build:
> - [x] Tier1 tests
> - [ ] Tier2 tests
> - [ ] Tier3 tests

The tier2-tier3 tests are in progress and I will update the test results later.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13202#issuecomment-1486269885

From fjiang at openjdk.org  Tue Mar 28 07:27:37 2023
From: fjiang at openjdk.org (Feilong Jiang)
Date: Tue, 28 Mar 2023 07:27:37 GMT
Subject: RFR: 8305008: RISC-V: Factor out immediate checking functions from
 assembler_riscv.inline.hpp
In-Reply-To: <zOPJRtrXmBK17ZgSm-THTp8qCXhh7tSNg6VRVFoLz9Y=.763009a8-a651-499d-a0e1-f114f3c842f0@github.com>
References: <zOPJRtrXmBK17ZgSm-THTp8qCXhh7tSNg6VRVFoLz9Y=.763009a8-a651-499d-a0e1-f114f3c842f0@github.com>
Message-ID: <VzjE2ECxwH0TUh0kfS4L7F3YLSsvj4VGWVEezRurkS4=.84d3d967-5f32-44c4-b71b-b56887c7d128@github.com>

On Tue, 28 Mar 2023 05:59:49 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

> The call-point to 'is_imm_in_range', 'is_unsigned_imm_in_range' and 'is_offset_in_range' in assembler_riscv.inline.hpp could to be replaced with shared code function 'is_simm' and 'is_uimm'.
> 
> For 'is_imm_in_range', if align_bits = 0, then the call point can be changed to call 'is_simm'. If align_bits = 1, then an additional summation judgement is added to determine if it is a multiple of 2. For 'is_unsigned_imm_in_range', we can first determine if it is greater than 0, and then call 'is_uimm' further. 'is_offset_in_range' can be changed directly to call 'is_simm'. This patch also refactored for is_valid_riscv64_address and movptr.
> 
> This patch removed the original functions from assembler_riscv.inline.hpp and defined some fixed-width checking functions based on the number of immediate or offset bits in the spec[1]. At the same time, we also adjusted two includes to fix the compilation error after the modification.
> 
> This patch also renames the function 'operand_valid_for_add_immediate' to 'operand_valid_for_add_sub_immediate' to make it consistent with its usage.
> 
> Finally, this patch modified the return value in os::non_memory_address_word to avoid an imm64 value of -1 in MacroAssembler::movptr.
> 
> [1] https://github.com/riscv/riscv-isa-manual/releases/download/draft-20230131-c0b298a/riscv-spec.pdf
> 
> ### Testing:
> 
> On Unmatched with release build:
> - [x] Tier1 tests
> - [ ] Tier2 tests
> - [ ] Tier3 tests

Thanks for the refactoring! I have some comments:

src/hotspot/cpu/riscv/assembler_riscv.hpp line 2159:

> 2157: #define INSN(NAME, funct3, op)                                                               \
> 2158:   void NAME(int32_t offset) {                                                                \
> 2159:     assert(is_simm12(offset) && ((offset % 2) == 0), "just checking");                       \

Could you please improve the assert message? like `invalid imm` or something more specific.

src/hotspot/cpu/riscv/assembler_riscv.hpp line 2685:

> 2683:           c_addi16sp(imm);                                                                   \
> 2684:           return;                                                                            \
> 2685:         } else if (Rd->is_compressed_valid() && (imm & 0b11) == 0x0 && (imm >= 0) && is_uimm10(imm)) { \

Is it necessary to check if `imm >= 0`? `imm` will be cast to unsigned value in `is_uimmx` eventually.

src/hotspot/cpu/riscv/assembler_riscv.hpp line 2832:

> 2830:   virtual void bang_stack_with_offset(int offset) { Unimplemented(); }
> 2831: 
> 2832:   static bool is_simm5(int64_t x);

I think it's better to check alignment inside of `is_immx`, rather than call site of `is_immx`, e.g.


int bool Assembler::is_simm5(int64_t x, int align = 0) {
    return (x & right_n_bits(align) == 0) && is_simm(x, 5 + align);
}


then we can drop some uncommon offset width checking like `is_simm13` and `is_simm21`.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13202#pullrequestreview-1360323052
PR Review Comment: https://git.openjdk.org/jdk/pull/13202#discussion_r1150125595
PR Review Comment: https://git.openjdk.org/jdk/pull/13202#discussion_r1150108861
PR Review Comment: https://git.openjdk.org/jdk/pull/13202#discussion_r1150105222

From amitkumar at openjdk.org  Tue Mar 28 08:16:55 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Tue, 28 Mar 2023 08:16:55 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v14]
In-Reply-To: <Fh6g8Qtdd0VS96WT8xUIrc4iiPfFICaFR5GG0IYpP8s=.fd3eca92-b604-4d3c-b31e-a731880e4efb@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <Fh6g8Qtdd0VS96WT8xUIrc4iiPfFICaFR5GG0IYpP8s=.fd3eca92-b604-4d3c-b31e-a731880e4efb@github.com>
Message-ID: <eSLTk8bq5FidaWkyef0kKWLoNMQd8LUX97kNDGdmJrA=.1cfdbb5d-98d5-4ae8-b3ec-b950a7215c00@github.com>

On Mon, 27 Mar 2023 14:43:04 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
>> 
>> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
>> 
>> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
>> 
>> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
>> 
>> This change supports the following platforms: x86, aarch64, PPC, and RISCV
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   RISCV patch and aarch64 improvement

Hi Matias,

s390x port is almost complete. All builds are successful & tier1 test for fast debug are complete. For other builds, tests are in progress. Please don't integrate, Wait for us ?

Thanks

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12778#issuecomment-1486414339

From dzhang at openjdk.org  Tue Mar 28 09:42:33 2023
From: dzhang at openjdk.org (Dingli Zhang)
Date: Tue, 28 Mar 2023 09:42:33 GMT
Subject: RFR: 8305008: RISC-V: Factor out immediate checking functions from
 assembler_riscv.inline.hpp
In-Reply-To: <VzjE2ECxwH0TUh0kfS4L7F3YLSsvj4VGWVEezRurkS4=.84d3d967-5f32-44c4-b71b-b56887c7d128@github.com>
References: <zOPJRtrXmBK17ZgSm-THTp8qCXhh7tSNg6VRVFoLz9Y=.763009a8-a651-499d-a0e1-f114f3c842f0@github.com>
 <VzjE2ECxwH0TUh0kfS4L7F3YLSsvj4VGWVEezRurkS4=.84d3d967-5f32-44c4-b71b-b56887c7d128@github.com>
Message-ID: <w0-DAdULxPR-qukLixpPq_rrA14xg0FW-Q9h2UdALSM=.31defeda-cd84-45d9-9ede-83567781a9a1@github.com>

On Tue, 28 Mar 2023 06:55:16 GMT, Feilong Jiang <fjiang at openjdk.org> wrote:

>> The call-point to 'is_imm_in_range', 'is_unsigned_imm_in_range' and 'is_offset_in_range' in assembler_riscv.inline.hpp could to be replaced with shared code function 'is_simm' and 'is_uimm'.
>> 
>> For 'is_imm_in_range', if align_bits = 0, then the call point can be changed to call 'is_simm'. If align_bits = 1, then an additional summation judgement is added to determine if it is a multiple of 2. For 'is_unsigned_imm_in_range', we can first determine if it is greater than 0, and then call 'is_uimm' further. 'is_offset_in_range' can be changed directly to call 'is_simm'. This patch also refactored for is_valid_riscv64_address and movptr.
>> 
>> This patch removed the original functions from assembler_riscv.inline.hpp and defined some fixed-width checking functions based on the number of immediate or offset bits in the spec[1]. At the same time, we also adjusted two includes to fix the compilation error after the modification.
>> 
>> This patch also renames the function 'operand_valid_for_add_immediate' to 'operand_valid_for_add_sub_immediate' to make it consistent with its usage.
>> 
>> Finally, this patch modified the return value in os::non_memory_address_word to avoid an imm64 value of -1 in MacroAssembler::movptr.
>> 
>> [1] https://github.com/riscv/riscv-isa-manual/releases/download/draft-20230131-c0b298a/riscv-spec.pdf
>> 
>> ### Testing:
>> 
>> On Unmatched with release build:
>> - [x] Tier1 tests
>> - [ ] Tier2 tests
>> - [ ] Tier3 tests
>
> src/hotspot/cpu/riscv/assembler_riscv.hpp line 2685:
> 
>> 2683:           c_addi16sp(imm);                                                                   \
>> 2684:           return;                                                                            \
>> 2685:         } else if (Rd->is_compressed_valid() && (imm & 0b11) == 0x0 && (imm >= 0) && is_uimm10(imm)) { \
> 
> Is it necessary to check if `imm >= 0`? `imm` will be cast to unsigned value in `is_uimmx` eventually.

Thank you for pointing this out!
I will also remove the `imm12 >= 0` that has the same case above.

> src/hotspot/cpu/riscv/assembler_riscv.hpp line 2832:
> 
>> 2830:   virtual void bang_stack_with_offset(int offset) { Unimplemented(); }
>> 2831: 
>> 2832:   static bool is_simm5(int64_t x);
> 
> I think it's better to check alignment inside of `is_immx`, rather than call site of `is_immx`, e.g.
> 
> 
> int bool Assembler::is_simm5(int64_t x, int align = 0) {
>     return (x & right_n_bits(align) == 0) && is_simm(x, 5 + align);
> }
> 
> 
> then we can drop some uncommon offset width checking like `is_simm13` and `is_simm21`.

Currently there are very few alignment checking cases in the intermediate checking functions and the only alignment checking is whether align is 1. Can we keep it outside for better readability?
Maybe we can keep `is_simm13` and `is_simm21` to make the format more uniform.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13202#discussion_r1150314447
PR Review Comment: https://git.openjdk.org/jdk/pull/13202#discussion_r1150311619

From mdoerr at openjdk.org  Tue Mar 28 09:45:10 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 28 Mar 2023 09:45:10 GMT
Subject: RFR: 8303210: [linux,
 Windows] Make UseSystemMemoryBarrier available as product flag [v5]
In-Reply-To: <9eZo1xYNGhjMSC9lDXKtkO1eyU_H-Veuh1AeP3CPKbg=.69b6c4ff-a3ef-439f-8468-21fec9de1825@github.com>
References: <9eZo1xYNGhjMSC9lDXKtkO1eyU_H-Veuh1AeP3CPKbg=.69b6c4ff-a3ef-439f-8468-21fec9de1825@github.com>
Message-ID: <w8QBaQtAtWepK1PRVY8uw8PO53iDnmtRt0P7o9jfDX8=.aa8c2e09-e9d6-4bff-8347-0033f0866774@github.com>

> I'd like to enable UseSystemMemoryBarrier by default on supported Operating Systems in order to improve performance of thread state transitions (I/O, JNI, foreign function calls, JIT compiler threads, etc.). See JBS issue for more details.
> Unfortunately, the feature was not yet implemented on all platforms. I added the code, but need the platform maintainers to check if it can be used reliably (and ideally if the performance improves). It's easy to switch it off again in case of problems.
> 
> Update: Startup performance and some benchmarks on some platforms are impacted (see below). So, this PR no longer switches it on by default.

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  Move flag configuration and initialization to os::init_2.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12753/files
  - new: https://git.openjdk.org/jdk/pull/12753/files/b7278798..5fc7dbd6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12753&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12753&range=03-04

  Stats: 48 lines in 5 files changed: 37 ins; 11 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12753/head:pull/12753

PR: https://git.openjdk.org/jdk/pull/12753

From dzhang at openjdk.org  Tue Mar 28 09:45:35 2023
From: dzhang at openjdk.org (Dingli Zhang)
Date: Tue, 28 Mar 2023 09:45:35 GMT
Subject: RFR: 8305008: RISC-V: Factor out immediate checking functions from
 assembler_riscv.inline.hpp
In-Reply-To: <VzjE2ECxwH0TUh0kfS4L7F3YLSsvj4VGWVEezRurkS4=.84d3d967-5f32-44c4-b71b-b56887c7d128@github.com>
References: <zOPJRtrXmBK17ZgSm-THTp8qCXhh7tSNg6VRVFoLz9Y=.763009a8-a651-499d-a0e1-f114f3c842f0@github.com>
 <VzjE2ECxwH0TUh0kfS4L7F3YLSsvj4VGWVEezRurkS4=.84d3d967-5f32-44c4-b71b-b56887c7d128@github.com>
Message-ID: <OhwDGh7gI7Ltvv4sW1NrMXx14zzKXwD9Mk_Vw7kv7os=.bcc8df65-0e59-4798-ba47-90d6cc7cfcb0@github.com>

On Tue, 28 Mar 2023 07:12:19 GMT, Feilong Jiang <fjiang at openjdk.org> wrote:

>> The call-point to 'is_imm_in_range', 'is_unsigned_imm_in_range' and 'is_offset_in_range' in assembler_riscv.inline.hpp could to be replaced with shared code function 'is_simm' and 'is_uimm'.
>> 
>> For 'is_imm_in_range', if align_bits = 0, then the call point can be changed to call 'is_simm'. If align_bits = 1, then an additional summation judgement is added to determine if it is a multiple of 2. For 'is_unsigned_imm_in_range', we can first determine if it is greater than 0, and then call 'is_uimm' further. 'is_offset_in_range' can be changed directly to call 'is_simm'. This patch also refactored for is_valid_riscv64_address and movptr.
>> 
>> This patch removed the original functions from assembler_riscv.inline.hpp and defined some fixed-width checking functions based on the number of immediate or offset bits in the spec[1]. At the same time, we also adjusted two includes to fix the compilation error after the modification.
>> 
>> This patch also renames the function 'operand_valid_for_add_immediate' to 'operand_valid_for_add_sub_immediate' to make it consistent with its usage.
>> 
>> Finally, this patch modified the return value in os::non_memory_address_word to avoid an imm64 value of -1 in MacroAssembler::movptr.
>> 
>> [1] https://github.com/riscv/riscv-isa-manual/releases/download/draft-20230131-c0b298a/riscv-spec.pdf
>> 
>> ### Testing:
>> 
>> On Unmatched with release build:
>> - [x] Tier1 tests
>> - [ ] Tier2 tests
>> - [ ] Tier3 tests
>
> src/hotspot/cpu/riscv/assembler_riscv.hpp line 2159:
> 
>> 2157: #define INSN(NAME, funct3, op)                                                               \
>> 2158:   void NAME(int32_t offset) {                                                                \
>> 2159:     assert(is_simm12(offset) && ((offset % 2) == 0), "just checking");                       \
> 
> Could you please improve the assertion error message? like `invalid imm` or something more specific.

Thanks! I will use `invalid encoding` instead.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13202#discussion_r1150317650

From pminborg at openjdk.org  Tue Mar 28 10:03:37 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 28 Mar 2023 10:03:37 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: <VSummI7PkJWPb8R-Ee_GQ5e69_mXIvFaeRPf1lVkGac=.011bc0a0-de39-4bdc-bd96-3e02b301a825@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
 <VSummI7PkJWPb8R-Ee_GQ5e69_mXIvFaeRPf1lVkGac=.011bc0a0-de39-4bdc-bd96-3e02b301a825@github.com>
Message-ID: <HjBAtHd8xcylCVfDPjKgabKcPG2LIy4egD5iUMLz5rg=.ae4edf98-987c-483a-8f6b-f8c0c0f594a0@github.com>

On Fri, 24 Mar 2023 08:35:06 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve javadocs for Linker::captureStateLayout
>
> src/java.base/share/classes/jdk/internal/foreign/abi/SharedUtils.java line 297:
> 
>> 295:         MethodType mtype = mh.type();
>> 296:         int[] perms = new int[mtype.parameterCount()];
>> 297:         MethodType swappedType = MethodType.methodType(mtype.returnType());
> 
> Instead?of `MethodType::appendParameterTypes(?)` (which?performs an?expensive?lookup of?a?new?cached `MethodType` value per?call), this?method should?instead use?a?`Class<?>[]` for?the?arguments, which?avoids that?overhead inside?a?loop:
> 
> 	public static MethodHandle swapArguments(MethodHandle mh, int firstArg, int secondArg) {
> 		MethodType mtype = mh.type();
> 		int[] perms = new int[mtype.parameterCount()];
> 		Class<?>[] ptypes = new Class<?>[perms.length];
> 		for (int i = 0 ; i < perms.length ; i++) {
> 			int dst = i;
> 			if (i == firstArg) dst = secondArg;
> 			else if (i == secondArg) dst = firstArg;
> 			perms[i] = dst;
> 			ptypes[i] = mtype.parameterType(dst);
> 		}
> 		// This should use `JavaLangInvokeAccess` to invoke the internal
> 		// `MethodType.methodType(Class<?> rtype, Class<?>[] ptypes, boolean trusted)`
> 		// method with a `trusted` value of `true`:
> 		MethodType swappedType = MethodType.methodType(mtype.returnType(), ptypes);
> 		return permuteArguments(mh, swappedType, perms);
> 	}

Thanks for this enhancement proposal. I hope you do not mind me asking if you could file a separate issue about this where you describe the above? We can then merge that proposal independent of this PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1150341545

From dzhang at openjdk.org  Tue Mar 28 10:08:15 2023
From: dzhang at openjdk.org (Dingli Zhang)
Date: Tue, 28 Mar 2023 10:08:15 GMT
Subject: RFR: 8305008: RISC-V: Factor out immediate checking functions from
 assembler_riscv.inline.hpp [v2]
In-Reply-To: <zOPJRtrXmBK17ZgSm-THTp8qCXhh7tSNg6VRVFoLz9Y=.763009a8-a651-499d-a0e1-f114f3c842f0@github.com>
References: <zOPJRtrXmBK17ZgSm-THTp8qCXhh7tSNg6VRVFoLz9Y=.763009a8-a651-499d-a0e1-f114f3c842f0@github.com>
Message-ID: <E-CIFmWm7kSmdB0j0UUCd9F2sbzryngHDCgbKoSd8vA=.8485fbbe-6476-43fa-90f1-5bba60378403@github.com>

> The call-point to 'is_imm_in_range', 'is_unsigned_imm_in_range' and 'is_offset_in_range' in assembler_riscv.inline.hpp could to be replaced with shared code function 'is_simm' and 'is_uimm'.
> 
> For 'is_imm_in_range', if align_bits = 0, then the call point can be changed to call 'is_simm'. If align_bits = 1, then an additional summation judgement is added to determine if it is a multiple of 2. For 'is_unsigned_imm_in_range', we can first determine if it is greater than 0, and then call 'is_uimm' further. 'is_offset_in_range' can be changed directly to call 'is_simm'. This patch also refactored for is_valid_riscv64_address and movptr.
> 
> This patch removed the original functions from assembler_riscv.inline.hpp and defined some fixed-width checking functions based on the number of immediate or offset bits in the spec[1]. At the same time, we also adjusted two includes to fix the compilation error after the modification.
> 
> This patch also renames the function 'operand_valid_for_add_immediate' to 'operand_valid_for_add_sub_immediate' to make it consistent with its usage.
> 
> Finally, this patch modified the return value in os::non_memory_address_word to avoid an imm64 value of -1 in MacroAssembler::movptr.
> 
> [1] https://github.com/riscv/riscv-isa-manual/releases/download/draft-20230131-c0b298a/riscv-spec.pdf
> 
> ### Testing:
> 
> On Unmatched with release build:
> - [x] Tier1 tests
> - [ ] Tier2 tests
> - [ ] Tier3 tests

Dingli Zhang has updated the pull request incrementally with two additional commits since the last revision:

 - Remove unecessary zero checking
 - Fix assert

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13202/files
  - new: https://git.openjdk.org/jdk/pull/13202/files/2fddfd04..73636dca

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13202&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13202&range=00-01

  Stats: 8 lines in 1 file changed: 0 ins; 3 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/13202.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13202/head:pull/13202

PR: https://git.openjdk.org/jdk/pull/13202

From pminborg at openjdk.org  Tue Mar 28 10:15:13 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 28 Mar 2023 10:15:13 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v9]
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <w6e1zS2kGsJZdVYxHoPxjvfP5fnvIaQdIuYgpCOBvbQ=.eb5241fe-0cc2-4bb1-bbab-278e6aec19b1@github.com>

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

Per Minborg has updated the pull request incrementally with eight additional commits since the last revision:

 - Make fallbacklinker.c consistent with downcallLinker.cpp
 - Add bug number
 - Use @return
 - Update Linker.downcallHandle() javadoc
 - Fix typos in Arena
 - Make checking method handle zero case
 - Add snippet to Linker.Option.captureStateLayout()
 - Apply RISCV port patch

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/6df28a78..3dab13da

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=07-08

  Stats: 125 lines in 13 files changed: 39 ins; 20 del; 66 mod
  Patch: https://git.openjdk.org/jdk/pull/13079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13079/head:pull/13079

PR: https://git.openjdk.org/jdk/pull/13079

From pminborg at openjdk.org  Tue Mar 28 10:15:19 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 28 Mar 2023 10:15:19 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: <VSummI7PkJWPb8R-Ee_GQ5e69_mXIvFaeRPf1lVkGac=.011bc0a0-de39-4bdc-bd96-3e02b301a825@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
 <VSummI7PkJWPb8R-Ee_GQ5e69_mXIvFaeRPf1lVkGac=.011bc0a0-de39-4bdc-bd96-3e02b301a825@github.com>
Message-ID: <82NY-GyOk1U9SLOqfPdRjwT_ypxKVEJx0JItDO0VXik=.5b5c7184-6d6d-4627-8803-03461a2297bc@github.com>

On Fri, 24 Mar 2023 08:42:37 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve javadocs for Linker::captureStateLayout
>
> src/java.base/share/classes/jdk/internal/foreign/abi/fallback/LibFallback.java line 61:
> 
>> 59:     static final MemorySegment VOID_TYPE = MemorySegment.ofAddress(ffi_type_void());
>> 60:     static final short STRUCT_TAG = ffi_type_struct();
>> 61:     private static final long SIZEOF_CIF = sizeofCif();
> 
> Won?t?calling `ffi_default_abi()` (and?the?other `ffi_*()`?methods) throw?`UnsatisfiedLinkError` if?`SUPPORTED`?is?`false`?

I think so too. How do we guard agains this @JornVernee ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1150350299

From rkennke at openjdk.org  Tue Mar 28 10:28:00 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 28 Mar 2023 10:28:00 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v31]
In-Reply-To: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
Message-ID: <jANr0SNUonjZl8Di_e0x6TvNP5DMvXFUgOZ72kHGhV4=.528b1344-9c75-4019-b9bb-84ae4c613e64@github.com>

> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
> 
> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p
 rotocols.
> 
> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
> 
> 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
> 
> 
> Testing:
>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
> 
> ### Performance
> 
> #### Simple Microbenchmark
> 
> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
> 
> |  | x86_64 | aarch64 |
> | -- | -- | -- |
> | -UseFastLocking | 20.651 | 20.764 |
> | +UseFastLocking | 18.896 | 18.908 |
> 
> 
> #### Renaissance
> 
> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
> -- | -- | -- | -- | -- | -- | -- | --
> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  (x86_32) Use existing thread register in fast_unlock() instead of fetching thread into a tmp register

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10907/files
  - new: https://git.openjdk.org/jdk/pull/10907/files/32fdda25..d4da05d9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=30
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=29-30

  Stats: 8 lines in 2 files changed: 2 ins; 5 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10907.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10907/head:pull/10907

PR: https://git.openjdk.org/jdk/pull/10907

From rehn at openjdk.org  Tue Mar 28 10:34:05 2023
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 28 Mar 2023 10:34:05 GMT
Subject: RFR: 8303210: [linux,
 Windows] Make UseSystemMemoryBarrier available as product flag [v5]
In-Reply-To: <w8QBaQtAtWepK1PRVY8uw8PO53iDnmtRt0P7o9jfDX8=.aa8c2e09-e9d6-4bff-8347-0033f0866774@github.com>
References: <9eZo1xYNGhjMSC9lDXKtkO1eyU_H-Veuh1AeP3CPKbg=.69b6c4ff-a3ef-439f-8468-21fec9de1825@github.com>
 <w8QBaQtAtWepK1PRVY8uw8PO53iDnmtRt0P7o9jfDX8=.aa8c2e09-e9d6-4bff-8347-0033f0866774@github.com>
Message-ID: <3EPcZXYbmo-cNBms1xoKN7hY6u1AAA7tE3MZ7PVt720=.a344288a-da23-4cd6-a09d-158d72ed8a93@github.com>

On Tue, 28 Mar 2023 09:45:10 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> I'd like to enable UseSystemMemoryBarrier by default on supported Operating Systems in order to improve performance of thread state transitions (I/O, JNI, foreign function calls, JIT compiler threads, etc.). See JBS issue for more details.
>> Unfortunately, the feature was not yet implemented on all platforms. I added the code, but need the platform maintainers to check if it can be used reliably (and ideally if the performance improves). It's easy to switch it off again in case of problems.
>> 
>> Update: Startup performance and some benchmarks on some platforms are impacted (see below). So, this PR no longer switches it on by default.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move flag configuration and initialization to os::init_2.

Marked as reviewed by rehn (Reviewer).

If there are performance regressions enabled it by default may not be the best thing for our users.

The issue in ContinuousCallSiteTargetChange.java is a bit worrying, since it concerns depots and transitions.

I don't mind this being a product flag.

-------------

PR Review: https://git.openjdk.org/jdk/pull/12753#pullrequestreview-1360730051
PR Comment: https://git.openjdk.org/jdk/pull/12753#issuecomment-1486609137

From rkennke at openjdk.org  Tue Mar 28 10:35:26 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 28 Mar 2023 10:35:26 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v32]
In-Reply-To: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
Message-ID: <cNrYLOARBnLhvCFRU_9Vwefbugeurnu1tdYI6vhgzTg=.df72fff9-b475-4bc8-8340-029efe966c93@github.com>

> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
> 
> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p
 rotocols.
> 
> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
> 
> 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
> 
> 
> Testing:
>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
> 
> ### Performance
> 
> #### Simple Microbenchmark
> 
> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
> 
> |  | x86_64 | aarch64 |
> | -- | -- | -- |
> | -UseFastLocking | 20.651 | 20.764 |
> | +UseFastLocking | 18.896 | 18.908 |
> 
> 
> #### Renaissance
> 
> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
> -- | -- | -- | -- | -- | -- | -- | --
> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Use long branches at start of fast_lock() and fast_unlock() unconditionally

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10907/files
  - new: https://git.openjdk.org/jdk/pull/10907/files/d4da05d9..7ccc4b63

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=31
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=30-31

  Stats: 7 lines in 1 file changed: 0 ins; 5 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10907.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10907/head:pull/10907

PR: https://git.openjdk.org/jdk/pull/10907

From rkennke at openjdk.org  Tue Mar 28 10:35:29 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 28 Mar 2023 10:35:29 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v32]
In-Reply-To: <mQ8uS7e-UKjBHYsOYxiBblo_-mpLh-hPqmhDiPvATMM=.925bad9b-63e9-4571-818f-5f12ead9eb90@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
 <ztiqECTkWnt6s0n8q0KXw4MzN2MBVqdJ1Jy0kd6JuQE=.c0872ea4-e696-43a0-b356-d5149af1cbd1@github.com>
 <aR4w0EwXiNzm5zpAI0H0t9v6jQAmeA-BcwVChTYVlrM=.55178ce1-0277-4c52-a3b8-cda16aed712e@github.com>
 <mQ8uS7e-UKjBHYsOYxiBblo_-mpLh-hPqmhDiPvATMM=.925bad9b-63e9-4571-818f-5f12ead9eb90@github.com>
Message-ID: <MTwrnwCZn_YU6HRL--2xT92wcCDpTsrZKmgZ7NPGOGo=.088c5930-857e-4097-bf7a-b1c408410a17@github.com>

On Wed, 22 Mar 2023 18:05:49 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> I don't think so, unless we also want to change all the stuff in x86_32.ad to not fetch the thread before calling into fast_unlock(). However, I think it is a nice and useful change. I could break it out of this PR and get it reviewed separately, it is a side-effect of the new locking impl insofar as we always require a thread register, and allocate&fetch it before going into fast_lock().
>
> I missed that it is under #ifndef LP64. Yes, it make since since you are now passing `thread` in register.
> And why we need to `get_thread()` at line 708 if we already have it?
> 
> It is still hard to follow this 32-bit code. What each register is holding, what is value `3` and why we don't have checks similar to LP64 code after CAS?

Good point about using the existing thread register.
I am not sure why we use '3' in x86_32 instead of the 1 (unlocked_value) that we are using elsewhere. It probably doesn't matter as long as it is not 0 which indicates recursive locking.
We don't do extra works after the CAS in x86_32 because x86_64 additionally optimizes the recursive case, while x86_32 drops into the slow-path there. It might be worth investigating if we could consolidate the two implementations and maybe even merge them into a single one. But perhaps not as part of the new locking effort?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1150373315

From jwaters at openjdk.org  Tue Mar 28 10:41:30 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 28 Mar 2023 10:41:30 GMT
Subject: RFR: 8302798: Refactor -XX:+UseOSErrorReporting for noreturn crash
 reporting [v3]
In-Reply-To: <IjZkR7nuKEWIrTC8Y7NffvE1wlctC0XIOmjdP-mDXUg=.17b7cb27-2219-4f03-b3fd-a7d6aae94aaa@github.com>
References: <elVA1mzItfJ7bnnfSpEUVprtbnnSx1zT_eoXnV2sviU=.13e2d4dc-74b0-4051-8852-04caf2c81196@github.com>
 <e2seVQWyK6KOjyo8gGmxeJfPbXBV0QibpBAm6jYAsJE=.27f3fdfc-7763-409e-be1c-3fe61e3905b7@github.com>
 <bra4j8ERIDMpG5qENJfD8s1r1SJBDR_LORHvU_xDefY=.2f707a60-ebc0-4c98-81c3-1080d1279cf3@github.com>
 <IjZkR7nuKEWIrTC8Y7NffvE1wlctC0XIOmjdP-mDXUg=.17b7cb27-2219-4f03-b3fd-a7d6aae94aaa@github.com>
Message-ID: <ogF9GrEI5V-wcatabzQ80j-iBh3WgjWVo9SxxZFJRP0=.e1af9a9f-66e6-41de-852c-11ce760552d3@github.com>

On Mon, 27 Mar 2023 00:52:05 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> > When compiling a Windows HotSpot with gcc (see [8288293](https://bugs.openjdk.org/browse/JDK-8288293?filter=-3)) newer gcc versions have a diagnostic that can catch when noreturn code returns in certain areas, and gcc catches several with this change:
> > ```
> > src/hotspot/os/windows/os_windows.cpp: In static member function 'static void os::abort(bool, void*, const void*)':
> > src/hotspot/os/windows/os_windows.cpp:1249:1: error: 'noreturn' function does return [-Werror]
> >  1249 | }
> >       | ^
> > src/hotspot/os/windows/os_windows.cpp: In static member function 'static void os::die()':
> > src/hotspot/os/windows/os_windows.cpp:1254:1: error: 'noreturn' function does return [-Werror]
> >  1254 | }
> >       | ^
> > src/hotspot/os/windows/os_windows.cpp: In static member function 'static void os::exit(int)':
> > src/hotspot/os/windows/os_windows.cpp:4792:1: error: 'noreturn' function does return [-Werror]
> >  4792 | }
> >       | ^
> > src/hotspot/os/windows/os_windows.cpp: In static member function 'static void os::_exit(int)':
> > src/hotspot/os/windows/os_windows.cpp:4796:1: error: 'noreturn' function does return [-Werror]
> >  4796 | }
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > I don't know if this is something we should be worried about with our current setup and the regular build that we have for Windows, so I'm leaving this warning here for someone else to read through
> 
> I think all of these warnings would go away if `os::win32::exit_process_or_thread` was noreturn. It looks like it is effectively noreturn (but not marked), though it contains a final `return exit_code;` that is commented as unreachable. I filed https://bugs.openjdk.org/browse/JDK-8304939 for this.

Alright, will pay attention to that issue. I'll also add an error from vmError_windows.cpp there as an addendum too, this also triggers together with the aforementioned os_windows.cpp warning but I forgot to include this to my previous message


src/hotspot/os/windows/vmError_windows.cpp: In static member function 'static void VMError::raise_fail_fast(void*, void*)':
d:/eclipse/workspace/jdk/src/hotspot/os/windows/vmError_windows.cpp:74:1: warning: 'noreturn' function does return
   74 | }
      | ^

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12759#issuecomment-1486617673

From jsjolen at openjdk.org  Tue Mar 28 10:41:36 2023
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 28 Mar 2023 10:41:36 GMT
Subject: RFR: JDK-8301496: Replace NULL with nullptr in cpu/riscv
Message-ID: <PNFHMzET147VzMQSySFk4koARUsEcb4lfNmh8JdScnk=.2dec4d00-90d6-4f5e-a89e-21d9aadb4d37@github.com>

Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory cpu/riscv. Unfortunately the script that does the change isn't perfect, and so we
need to comb through these manually to make sure nothing has gone wrong. I also review these changes but things slip past my eyes sometimes.

Here are some typical things to look out for:

1. No changes but copyright header changed (probably because I reverted some changes but forgot the copyright).
2. Macros having their NULL changed to nullptr, these are added to the script when I find them. They should be NULL.
3. nullptr in comments and logs. We try to use lower case "null" in these cases as it reads better. An exception is made when code expressions are in a comment.

An example of this:

```c++
// This function returns null
void* ret_null();
// This function returns true if *x == nullptr
bool is_nullptr(void** x);


Note how `nullptr` participates in a code expression here, we really are talking about the specific value `nullptr`.

Thanks!

-------------

Commit messages:
 - Merge remote-tracking branch 'origin/master' into JDK-8301496
 - Fixes
 - Merge remote-tracking branch 'origin/master' into JDK-8301496
 -  Replace NULL with nullptr in cpu/riscv

Changes: https://git.openjdk.org/jdk/pull/12324/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12324&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301496
  Stats: 573 lines in 45 files changed: 0 ins; 0 del; 573 mod
  Patch: https://git.openjdk.org/jdk/pull/12324.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12324/head:pull/12324

PR: https://git.openjdk.org/jdk/pull/12324

From jsjolen at openjdk.org  Tue Mar 28 10:41:54 2023
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 28 Mar 2023 10:41:54 GMT
Subject: RFR: JDK-8301496: Replace NULL with nullptr in cpu/riscv
In-Reply-To: <PNFHMzET147VzMQSySFk4koARUsEcb4lfNmh8JdScnk=.2dec4d00-90d6-4f5e-a89e-21d9aadb4d37@github.com>
References: <PNFHMzET147VzMQSySFk4koARUsEcb4lfNmh8JdScnk=.2dec4d00-90d6-4f5e-a89e-21d9aadb4d37@github.com>
Message-ID: <kwEwHboI3lw4AdxNa_sr1zgsFY2SrMJUOKs1nkfyCKM=.2f41ed62-2a11-4280-9fc4-9ab0638b3072@github.com>

On Tue, 31 Jan 2023 11:39:59 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory cpu/riscv. Unfortunately the script that does the change isn't perfect, and so we
> need to comb through these manually to make sure nothing has gone wrong. I also review these changes but things slip past my eyes sometimes.
> 
> Here are some typical things to look out for:
> 
> 1. No changes but copyright header changed (probably because I reverted some changes but forgot the copyright).
> 2. Macros having their NULL changed to nullptr, these are added to the script when I find them. They should be NULL.
> 3. nullptr in comments and logs. We try to use lower case "null" in these cases as it reads better. An exception is made when code expressions are in a comment.
> 
> An example of this:
> 
> ```c++
> // This function returns null
> void* ret_null();
> // This function returns true if *x == nullptr
> bool is_nullptr(void** x);
> 
> 
> Note how `nullptr` participates in a code expression here, we really are talking about the specific value `nullptr`.
> 
> Thanks!

Review of changes to be made.

Don't close yet.

src/hotspot/cpu/riscv/assembler_riscv.hpp line 2174:

> 2172:   }                                                                                          \
> 2173:   void NAME(address dest) {                                                                  \
> 2174:     assert_cond(dest != nullptr);                                                               \

align

src/hotspot/cpu/riscv/assembler_riscv.hpp line 2202:

> 2200:   }                                                                                          \
> 2201:   void NAME(Register Rs1, address dest) {                                                    \
> 2202:     assert_cond(dest != nullptr);                                                               \

align

src/hotspot/cpu/riscv/gc/shenandoah/shenandoahBarrierSetAssembler_riscv.cpp line 161:

> 159:   // Calling the runtime using the regular call_VM_leaf mechanism generates
> 160:   // code (generated by InterpreterMacroAssember::call_VM_leaf_base)
> 161:   // that checks that the *(rfp+frame::interpreter_frame_last_sp) == null.

is null

src/hotspot/cpu/riscv/interp_masm_riscv.cpp line 159:

> 157:     Label L;
> 158:     ld(t0, Address(xthread, JavaThread::jvmti_thread_state_offset()));
> 159:     beqz(t0, L);  // if [thread->jvmti_thread_state() == null] then exit

is

src/hotspot/cpu/riscv/interp_masm_riscv.cpp line 1335:

> 1333: //       ]
> 1334: //       if (row[2].rec != null) then [
> 1335: //         count.incr()

nullptr

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 836:

> 834: #define INSN(NAME, REGISTER)                                       \
> 835:   void MacroAssembler::NAME(const address dest, Register temp) {   \
> 836:     assert_cond(dest != nullptr);                                     \

align

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 880:

> 878: #define INSN(NAME)                                                                    \
> 879:   void MacroAssembler::NAME(Register Rd, const address dest, Register temp) {         \
> 880:     assert_cond(dest != nullptr);                                                        \

align

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 2025:

> 2023: void MacroAssembler::null_check(Register reg, int offset) {
> 2024:   if (needs_explicit_null_check(offset)) {
> 2025:     // provoke OS null exception if reg = null by

is

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 2031:

> 2029:   } else {
> 2030:     // nothing to do, (later) access of M[reg + offset]
> 2031:     // will provoke OS NULL exception if reg = NULL

is

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 2031:

> 2029:   } else {
> 2030:     // nothing to do, (later) access of M[reg + offset]
> 2031:     // will provoke OS null exception if reg = null

is

src/hotspot/cpu/riscv/macroAssembler_riscv.hpp line 593:

> 591: #define INSN(NAME)                                                                                       \
> 592:   void NAME(Register Rs1, Register Rs2, const address dest) {                                            \
> 593:     assert_cond(dest != nullptr);                                                                           \

align

src/hotspot/cpu/riscv/macroAssembler_riscv.hpp line 783:

> 781: #define INSN(NAME)                                                                                 \
> 782:   void NAME(Register Rd, address dest) {                                                           \
> 783:     assert_cond(dest != nullptr);                                                                     \

align

src/hotspot/cpu/riscv/macroAssembler_riscv.hpp line 840:

> 838: #define INSN(NAME)                                                                                 \
> 839:   void NAME(FloatRegister Rd, address dest, Register temp = t0) {                                  \
> 840:     assert_cond(dest != nullptr);                                                                     \

align

src/hotspot/cpu/riscv/macroAssembler_riscv.hpp line 900:

> 898: #define INSN(NAME)                                                                                 \
> 899:   void NAME(Register Rs, address dest, Register temp = t0) {                                       \
> 900:     assert_cond(dest != nullptr);                                                                     \

align

src/hotspot/cpu/riscv/macroAssembler_riscv.hpp line 946:

> 944: #define INSN(NAME)                                                                                 \
> 945:   void NAME(FloatRegister Rs, address dest, Register temp = t0) {                                  \
> 946:     assert_cond(dest != nullptr);                                                                     \

align

src/hotspot/cpu/riscv/relocInfo_riscv.cpp line 44:

> 42:     case relocInfo::oop_type: {
> 43:       oop_Relocation *reloc = (oop_Relocation *)this;
> 44:       // in movoop when BarrierSet::barrier_set()->barrier_set_nmethod() != null

isn't

src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 1774:

> 1772:     //
> 1773: 
> 1774:     // if [src == null] then return -1

is

src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 1782:

> 1780:     __ bnez(t0, L_failed);
> 1781: 
> 1782:     // if [dst == null] then return -1

is

src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp line 833:

> 831:   Label slow_path;
> 832:   const Register local_0 = c_rarg0;
> 833:   // Check if local 0 != null

isn't

src/hotspot/cpu/riscv/templateTable_riscv.cpp line 3605:

> 3603:   __ bind(done);
> 3604:   // x10 = 0: obj == NULL or  obj is not an instanceof the specified klass
> 3605:   // x10 = 1: obj != NULL and obj is     an instanceof the specified klass

is isn't

-------------

PR Review: https://git.openjdk.org/jdk/pull/12324#pullrequestreview-1360564245
PR Comment: https://git.openjdk.org/jdk/pull/12324#issuecomment-1477544237
PR Review Comment: https://git.openjdk.org/jdk/pull/12324#discussion_r1150268232
PR Review Comment: https://git.openjdk.org/jdk/pull/12324#discussion_r1150268320
PR Review Comment: https://git.openjdk.org/jdk/pull/12324#discussion_r1150271398
PR Review Comment: https://git.openjdk.org/jdk/pull/12324#discussion_r1150271778
PR Review Comment: https://git.openjdk.org/jdk/pull/12324#discussion_r1150272066
PR Review Comment: https://git.openjdk.org/jdk/pull/12324#discussion_r1150272555
PR Review Comment: https://git.openjdk.org/jdk/pull/12324#discussion_r1150272631
PR Review Comment: https://git.openjdk.org/jdk/pull/12324#discussion_r1150273041
PR Review Comment: https://git.openjdk.org/jdk/pull/12324#discussion_r1150272972
PR Review Comment: https://git.openjdk.org/jdk/pull/12324#discussion_r1150273240
PR Review Comment: https://git.openjdk.org/jdk/pull/12324#discussion_r1150273666
PR Review Comment: https://git.openjdk.org/jdk/pull/12324#discussion_r1150273722
PR Review Comment: https://git.openjdk.org/jdk/pull/12324#discussion_r1150273798
PR Review Comment: https://git.openjdk.org/jdk/pull/12324#discussion_r1150273929
PR Review Comment: https://git.openjdk.org/jdk/pull/12324#discussion_r1150274006
PR Review Comment: https://git.openjdk.org/jdk/pull/12324#discussion_r1150275666
PR Review Comment: https://git.openjdk.org/jdk/pull/12324#discussion_r1150276157
PR Review Comment: https://git.openjdk.org/jdk/pull/12324#discussion_r1150276275
PR Review Comment: https://git.openjdk.org/jdk/pull/12324#discussion_r1150276773
PR Review Comment: https://git.openjdk.org/jdk/pull/12324#discussion_r1150277254

From sspitsyn at openjdk.org  Tue Mar 28 10:45:33 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 28 Mar 2023 10:45:33 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v6]
In-Reply-To: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
Message-ID: <E3Hn-gKHcyfKivli3eExBskzkU1PFP2JsnqrwhlKgJQ=.36832c57-7397-4337-94cb-d70817a285d8@github.com>

> The fix is to enable virtual threads support for late binding JVMTI agents.
> The fix includes:
> - New function `JvmtiEnvBase::enable_virtual_threads_notify_jvmti()` which does enabling JVMTI VTMS transition notifications in case of agent loaded into running VM. This function executes a VM operation counting VTMS transition bits in all `JavaThread`'s to correctly set the static counter `_VTMS_transition_count` needed for VTMS transition protocol.
> - New function `JvmtiEnvBase::disable_virtual_threads_notify_jvmti()` which is needed for testing. It is used by the `WhiteBox` API.
> - New WhiteBox function `WB_SetVirtualThreadsNotifyJvmtiMode(JNIEnv* env, jobject wb, jboolean enable)` needed for testing of this update.
> - New regression test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
> 
> Testing:
> - New test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
> - The originally failed tests are expected to pass 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:

  addressed the rest of review comments chunk

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13133/files
  - new: https://git.openjdk.org/jdk/pull/13133/files/89b659d7..f8a7b18b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13133&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13133&range=04-05

  Stats: 215 lines in 7 files changed: 153 ins; 29 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/13133.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13133/head:pull/13133

PR: https://git.openjdk.org/jdk/pull/13133

From rkennke at openjdk.org  Tue Mar 28 10:55:16 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 28 Mar 2023 10:55:16 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <z1u-Lf3nAHoI5NyO71NmJDC49m10j3galYAyQg-2ru4=.503c3430-7965-4f53-b4f4-e7677dfe333f@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
 <z1u-Lf3nAHoI5NyO71NmJDC49m10j3galYAyQg-2ru4=.503c3430-7965-4f53-b4f4-e7677dfe333f@github.com>
Message-ID: <OXd2CO6DV__IRLKNikokd4x-t-9F3MhsrislEHUnUpg=.613d3342-6851-48c7-acf0-183b86c2febc@github.com>

On Fri, 24 Mar 2023 06:55:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>>  - Set condition flags correctly after fast-lock call on aarch64
>
> src/hotspot/share/runtime/threads.cpp line 1422:
> 
>> 1420: }
>> 1421: 
>> 1422: JavaThread* Threads::owning_thread_from_object(ThreadsList * t_list, oop obj) {
> 
> Is this thread-safe?

My last commit changed that code to only run during safepoints. It should be safe now, and I added an assert that verifies that it is only run at safepoint.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1150401225

From alanb at openjdk.org  Tue Mar 28 10:55:41 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Mar 2023 10:55:41 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads
Message-ID: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>

JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview.

There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently.

In addition, there are a small number of implementation changes to sync up from the loom fibers branch:

- A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where  end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly.
- The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes.
- A few robustness improvements for OOME and SOE. There is more to do here, for future PRs.
- New system property to print a trace dump when virtual thread sets its own value of a TL.
- ThreadPerTaskExecutor is changed to use FutureTask.

Testing: tier1-6.

-------------

Commit messages:
 - Merge
 - Initial sync from fibers branch

Changes: https://git.openjdk.org/jdk/pull/13203/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13203&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304919
  Stats: 1964 lines in 198 files changed: 698 ins; 760 del; 506 mod
  Patch: https://git.openjdk.org/jdk/pull/13203.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13203/head:pull/13203

PR: https://git.openjdk.org/jdk/pull/13203

From pminborg at openjdk.org  Tue Mar 28 10:56:07 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 28 Mar 2023 10:56:07 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v10]
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <_n0HMK1noQxNPICydcCIuSNqJfKIxLHO8S5_lAivyy4=.794689fc-f8e9-4582-8e24-82503ed1073b@github.com>

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:

 - Merge with master
 - Make fallbacklinker.c consistent with downcallLinker.cpp
 - Add bug number
 - Use @return
 - Update Linker.downcallHandle() javadoc
 - Fix typos in Arena
 - Make checking method handle zero case
 - Add snippet to Linker.Option.captureStateLayout()
 - Apply RISCV port patch
 - Improve javadocs for Linker::captureStateLayout
 - ... and 12 more: https://git.openjdk.org/jdk/compare/cddaf686...bc29c6fc

-------------

Changes: https://git.openjdk.org/jdk/pull/13079/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=09
  Stats: 13027 lines in 267 files changed: 5006 ins; 6015 del; 2006 mod
  Patch: https://git.openjdk.org/jdk/pull/13079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13079/head:pull/13079

PR: https://git.openjdk.org/jdk/pull/13079

From rkennke at openjdk.org  Tue Mar 28 11:03:35 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 28 Mar 2023 11:03:35 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v33]
In-Reply-To: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
Message-ID: <nEmn1fUOBU8sefvjh8xt8PQjMwAe3zlsMzmP5sXdQ_k=.b1ab412d-6e6a-48cd-b392-5c80d01156c0@github.com>

> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
> 
> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p
 rotocols.
> 
> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites.
> 
> 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
> 
> 
> Testing:
>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
> 
> ### Performance
> 
> #### Simple Microbenchmark
> 
> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
> 
> |  | x86_64 | aarch64 |
> | -- | -- | -- |
> | -UseFastLocking | 20.651 | 20.764 |
> | +UseFastLocking | 18.896 | 18.908 |
> 
> 
> #### Renaissance
> 
> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
> -- | -- | -- | -- | -- | -- | -- | --
> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Address some of @dholmes-ora' review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10907/files
  - new: https://git.openjdk.org/jdk/pull/10907/files/7ccc4b63..de45c08e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=32
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=31-32

  Stats: 54 lines in 5 files changed: 19 ins; 3 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/10907.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10907/head:pull/10907

PR: https://git.openjdk.org/jdk/pull/10907

From mcimadamore at openjdk.org  Tue Mar 28 11:03:39 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 28 Mar 2023 11:03:39 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v10]
In-Reply-To: <_n0HMK1noQxNPICydcCIuSNqJfKIxLHO8S5_lAivyy4=.794689fc-f8e9-4582-8e24-82503ed1073b@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <_n0HMK1noQxNPICydcCIuSNqJfKIxLHO8S5_lAivyy4=.794689fc-f8e9-4582-8e24-82503ed1073b@github.com>
Message-ID: <hNmTaUcPM2l705AlHp2tU9z2fFZzTpId0avwr7_U7pk=.2ccbffc3-f8ee-40ae-a5e9-45ce99b1b32a@github.com>

On Tue, 28 Mar 2023 10:56:07 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> API changes for the FFM API (third preview)
>> 
>> Specdiff:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
>> 
>> Javadoc:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
> 
>  - Merge with master
>  - Make fallbacklinker.c consistent with downcallLinker.cpp
>  - Add bug number
>  - Use @return
>  - Update Linker.downcallHandle() javadoc
>  - Fix typos in Arena
>  - Make checking method handle zero case
>  - Add snippet to Linker.Option.captureStateLayout()
>  - Apply RISCV port patch
>  - Improve javadocs for Linker::captureStateLayout
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/cddaf686...bc29c6fc

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 2310:

> 2308:         /**
> 2309:          * {@return {@code true}, if the provided object is also a scope, which models the same lifetime as that
> 2310:          * modelled by this scope}. In that case, it is always the case that

This brace (after `scope`) seems spurious?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1150408522

From sspitsyn at openjdk.org  Tue Mar 28 11:10:34 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 28 Mar 2023 11:10:34 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v7]
In-Reply-To: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
Message-ID: <s4MLevGXrgbobQlqLZ82tEeKxL4UkWX3b83h9xczgNM=.8a4f0f06-876c-4a53-8359-a87638c0289f@github.com>

> The fix is to enable virtual threads support for late binding JVMTI agents.
> The fix includes:
> - New function `JvmtiEnvBase::enable_virtual_threads_notify_jvmti()` which does enabling JVMTI VTMS transition notifications in case of agent loaded into running VM. This function executes a VM operation counting VTMS transition bits in all `JavaThread`'s to correctly set the static counter `_VTMS_transition_count` needed for VTMS transition protocol.
> - New function `JvmtiEnvBase::disable_virtual_threads_notify_jvmti()` which is needed for testing. It is used by the `WhiteBox` API.
> - New WhiteBox function `WB_SetVirtualThreadsNotifyJvmtiMode(JNIEnv* env, jobject wb, jboolean enable)` needed for testing of this update.
> - New regression test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
> 
> Testing:
> - New test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
> - The originally failed tests are expected to pass 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:

  minor comment correction

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13133/files
  - new: https://git.openjdk.org/jdk/pull/13133/files/f8a7b18b..526c2788

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13133&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13133&range=05-06

  Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13133.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13133/head:pull/13133

PR: https://git.openjdk.org/jdk/pull/13133

From rkennke at openjdk.org  Tue Mar 28 11:48:05 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 28 Mar 2023 11:48:05 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <yoOQnZWXsuiKuJ3RNms0XMGS4m5kDh9aiUyQ0hht8rE=.81a7b56a-23eb-454d-ad0c-e62cc7614035@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
 <S3HAUfb2-rymMhcE0b5Uwycc6LpZHCnHRVHXL0141IU=.20c872ab-a4c1-4d40-b33b-a83f9f388cd1@github.com>
 <yoOQnZWXsuiKuJ3RNms0XMGS4m5kDh9aiUyQ0hht8rE=.81a7b56a-23eb-454d-ad0c-e62cc7614035@github.com>
Message-ID: <BhXZmpuL3flTBe7a9YfJphmwpYuc0qOMDU6mxgw1a5w=.be9f6dc6-8905-44e9-a817-36284b433d7d@github.com>

On Fri, 24 Mar 2023 02:49:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > Is anybody familiar with the academic literature on this topic? I am sure I am not the first person which has come up with this form of locking. Maybe we could use a name that refers to some academic paper?
> 
> Well not to diminish this in any way but all you are doing is moving the lock-record from the stack frame (indexed from the markword) to a heap allocated side-table (indexed via the thread itself). The "fast-locking" is still the bit that use the markword to indicate the locked state, and that hasn't changed. Encoding lock state in an object header has a number of names in the literature, depending on whose scheme it was: IBM had ThinLocks; the Sun Research VM (EVM) had meta-locks; etc. Hotspot doesn't really have a name for its variation. And as I said you aren't changing that aspect but modifying what data structure is used to access the lock-records.
> 
> So the property Jesper was looking for, IMO, may be something like `UseHeapLockRecords` - though that can unfortunately be parsed as using records for the HeapLock. :(
> 
> I think it was mentioned somewhere above that in the Java Object Monitor prototyping work we avoided using these kinds of boolean flags by defining a single "policy" flag that could take on different values for different implementation schemes. These are simply numbered, so for example:
> 
> * policy 0: use existing/legacy locking with stack-based lock records
> * policy 1: use heavyweight locks (ie UseHeavyMonitors)
> * policy 2 use the new approach with heap-allocated lock-records

Well I would argue that the current implementation puts the lock record in the object header (in the form of a pointer into the stack, which is elsewhere used to identify which thread an object is locked by), and only displaces the object header onto the stack-frame, whereas the new implementation puts the lock record onto the lock-stack, which is still part of the JavaThread structure (and not heap-allocated ... although it used to be in an earlier incarnation). And it leaves the object header alone. So the correct name would be +UseStackLockRecord to turn on the new impl (where the old one would be called header lock record, or something like that). I like that name, but I suspect that it might be confusing because the old impl has traditionally been called 'stack-locking'.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1486716156

From mdoerr at openjdk.org  Tue Mar 28 11:49:34 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 28 Mar 2023 11:49:34 GMT
Subject: RFR: 8303210: [linux,
 Windows] Make UseSystemMemoryBarrier available as product flag [v5]
In-Reply-To: <w8QBaQtAtWepK1PRVY8uw8PO53iDnmtRt0P7o9jfDX8=.aa8c2e09-e9d6-4bff-8347-0033f0866774@github.com>
References: <9eZo1xYNGhjMSC9lDXKtkO1eyU_H-Veuh1AeP3CPKbg=.69b6c4ff-a3ef-439f-8468-21fec9de1825@github.com>
 <w8QBaQtAtWepK1PRVY8uw8PO53iDnmtRt0P7o9jfDX8=.aa8c2e09-e9d6-4bff-8347-0033f0866774@github.com>
Message-ID: <S42Bp1Nn5lPsmhr2JdEbs1L6UOlE_CPxU39KcgkPtDY=.16ecb014-5d1a-45ca-bb21-bb1e76ae85ec@github.com>

On Tue, 28 Mar 2023 09:45:10 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> I'd like to enable UseSystemMemoryBarrier by default on supported Operating Systems in order to improve performance of thread state transitions (I/O, JNI, foreign function calls, JIT compiler threads, etc.). See JBS issue for more details.
>> Unfortunately, the feature was not yet implemented on all platforms. I added the code, but need the platform maintainers to check if it can be used reliably (and ideally if the performance improves). It's easy to switch it off again in case of problems.
>> 
>> Update: Startup performance and some benchmarks on some platforms are impacted (see below). So, this PR no longer switches it on by default.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move flag configuration and initialization to os::init_2.

Thanks for the review! Also for the CSR review.
@dholmes-ora: I think I've done all changes you had requested. The CSR is proposed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12753#issuecomment-1486718616

From jvernee at openjdk.org  Tue Mar 28 12:39:41 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 28 Mar 2023 12:39:41 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v10]
In-Reply-To: <hNmTaUcPM2l705AlHp2tU9z2fFZzTpId0avwr7_U7pk=.2ccbffc3-f8ee-40ae-a5e9-45ce99b1b32a@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <_n0HMK1noQxNPICydcCIuSNqJfKIxLHO8S5_lAivyy4=.794689fc-f8e9-4582-8e24-82503ed1073b@github.com>
 <hNmTaUcPM2l705AlHp2tU9z2fFZzTpId0avwr7_U7pk=.2ccbffc3-f8ee-40ae-a5e9-45ce99b1b32a@github.com>
Message-ID: <X6m7dliUoUzaubf5bXkaCwEmCZaz-d0vomdgneJslsQ=.88804c90-b3dc-4f45-b740-55c41ee57d39@github.com>

On Tue, 28 Mar 2023 11:00:00 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
>> 
>>  - Merge with master
>>  - Make fallbacklinker.c consistent with downcallLinker.cpp
>>  - Add bug number
>>  - Use @return
>>  - Update Linker.downcallHandle() javadoc
>>  - Fix typos in Arena
>>  - Make checking method handle zero case
>>  - Add snippet to Linker.Option.captureStateLayout()
>>  - Apply RISCV port patch
>>  - Improve javadocs for Linker::captureStateLayout
>>  - ... and 12 more: https://git.openjdk.org/jdk/compare/cddaf686...bc29c6fc
>
> src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 2310:
> 
>> 2308:         /**
>> 2309:          * {@return {@code true}, if the provided object is also a scope, which models the same lifetime as that
>> 2310:          * modelled by this scope}. In that case, it is always the case that
> 
> This brace (after `scope`) seems spurious?

It's to close the text span for the `{@return`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1150540008

From pminborg at openjdk.org  Tue Mar 28 13:06:07 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 28 Mar 2023 13:06:07 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v11]
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <ESoZsip9RCCAhw-45qti9kL5IwXhzVzks-TRHfedUyI=.47a3b8d4-6276-45b1-b167-d9d0caffdaf3@github.com>

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright years

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/bc29c6fc..e7471d02

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=09-10

  Stats: 93 lines in 93 files changed: 0 ins; 0 del; 93 mod
  Patch: https://git.openjdk.org/jdk/pull/13079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13079/head:pull/13079

PR: https://git.openjdk.org/jdk/pull/13079

From rkennke at openjdk.org  Tue Mar 28 13:08:10 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 28 Mar 2023 13:08:10 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <nRCVukhWG7mplVCtzhcrXxWb9fu3vPVmRfXno0Rk7iE=.3b04aaa0-d3c5-48e4-8514-3fb5d25f9662@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
 <nRCVukhWG7mplVCtzhcrXxWb9fu3vPVmRfXno0Rk7iE=.3b04aaa0-d3c5-48e4-8514-3fb5d25f9662@github.com>
Message-ID: <BWMQf3KmpVfKULOnjmASTavsqNtXcLQexhzrvCEB_SM=.34a9b9b9-0443-4462-9db2-598033cb22ae@github.com>

On Fri, 24 Mar 2023 10:47:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>>  - Set condition flags correctly after fast-lock call on aarch64
>
> src/hotspot/cpu/aarch64/aarch64.ad line 3954:
> 
>> 3952:         // Indicate success on completion.
>> 3953:         __ cmp(oop, oop);
>> 3954:         __ b(count);
> 
> `aarch64_enc_fast_lock` explicitly sets NE on failure path. But this code just jumps to `no_count` without setting the flag. Does the code outside this encoding block rely on flags?

The code outside this encoding block relies on flags, yes. This is very ugly. fast_unlock() jumps to no_count when the CAS fails, where the NE flag is set, therefore we don't need to set it again.

> src/hotspot/share/runtime/synchronizer.cpp line 923:
> 
>> 921: static bool is_lock_owned(Thread* thread, oop obj) {
>> 922:   assert(UseFastLocking, "only call this with fast-locking enabled");
>> 923:   return thread->is_Java_thread() ? reinterpret_cast<JavaThread*>(thread)->lock_stack().contains(obj) : false;
> 
> Here and later, should use `JavaThread::cast(thread)` instead of `reinterpret_cast<JavaThread*>`? It also sometimes subsumes the asserts, as `JT::cast` checks the type.

The problem is that the places where that helper function is used receive a Thread* and not a JavaThread* (FastHashCode() and inflate()), and changing those to accept JavaThread* percolates into various areas that I don't want to touch right now (e.g. finalizerService.cpp). That is the reason why that function exists to begin with. I'll do the changes that @shipilev suggested for the time being. We may want to investigate restricting the incoming type in the future.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1150580134
PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1150576745

From rkennke at openjdk.org  Tue Mar 28 13:12:54 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 28 Mar 2023 13:12:54 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <nRCVukhWG7mplVCtzhcrXxWb9fu3vPVmRfXno0Rk7iE=.3b04aaa0-d3c5-48e4-8514-3fb5d25f9662@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
 <nRCVukhWG7mplVCtzhcrXxWb9fu3vPVmRfXno0Rk7iE=.3b04aaa0-d3c5-48e4-8514-3fb5d25f9662@github.com>
Message-ID: <siAcnk1ZdZ47cNO5V7byadG32gJXFWiGVqbKb8Hao2s=.19c87d27-b757-4145-82e9-9aad4e35a03f@github.com>

On Fri, 24 Mar 2023 10:50:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>>  - Set condition flags correctly after fast-lock call on aarch64
>
> src/hotspot/cpu/aarch64/aarch64.ad line 3848:
> 
>> 3846:         __ bind(slow);
>> 3847:         __ tst(oop, oop); // Force ZF=0 to indicate failure and take slow-path. We know that oop != null.
>> 3848:         __ b(no_count);
> 
> Is this a micro-optimization? I think we can simplify the code by just setting the flags here and then jumping into the usual `__ b(cont)`. This would make the move of `__ b(cont)` unnecessary below.

Well it avoids one conditional branch, so yeah I guess it's an optimization. If you don't like the b(cont) I can still move it back to where it was. It would be a dead instruction with fast-locking, though.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1150585671

From pminborg at openjdk.org  Tue Mar 28 13:14:09 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 28 Mar 2023 13:14:09 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v12]
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <ULiv3xz4T-tuemI4RMgY9p0l8qWFdk5pI_p3sj2AKbc=.82f3043a-6f58-468e-80be-403f49aa2e3c@github.com>

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Fix copyrigth year issues

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/e7471d02..24bea62e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=10-11

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13079/head:pull/13079

PR: https://git.openjdk.org/jdk/pull/13079

From pminborg at openjdk.org  Tue Mar 28 13:14:10 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 28 Mar 2023 13:14:10 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v10]
In-Reply-To: <X6m7dliUoUzaubf5bXkaCwEmCZaz-d0vomdgneJslsQ=.88804c90-b3dc-4f45-b740-55c41ee57d39@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <_n0HMK1noQxNPICydcCIuSNqJfKIxLHO8S5_lAivyy4=.794689fc-f8e9-4582-8e24-82503ed1073b@github.com>
 <hNmTaUcPM2l705AlHp2tU9z2fFZzTpId0avwr7_U7pk=.2ccbffc3-f8ee-40ae-a5e9-45ce99b1b32a@github.com>
 <X6m7dliUoUzaubf5bXkaCwEmCZaz-d0vomdgneJslsQ=.88804c90-b3dc-4f45-b740-55c41ee57d39@github.com>
Message-ID: <ZEd8fiQ4rlYXBX6S0CjRZNfP9L5CN2us10z_wAKzKgk=.9b27e5f5-33fe-4ab3-810c-62054002732d@github.com>

On Tue, 28 Mar 2023 12:36:28 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 2310:
>> 
>>> 2308:         /**
>>> 2309:          * {@return {@code true}, if the provided object is also a scope, which models the same lifetime as that
>>> 2310:          * modelled by this scope}. In that case, it is always the case that
>> 
>> This brace (after `scope`) seems spurious?
>
> It's to close the text span for the `{@return`

<img width="315" alt="image" src="https://user-images.githubusercontent.com/7457876/228246205-ff2730cb-610f-4673-aa30-d110845a34fc.png">

It belongs to the opening brace for `{@return`. Hard to see with other curls in between.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1150584776

From pminborg at openjdk.org  Tue Mar 28 13:14:10 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 28 Mar 2023 13:14:10 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v10]
In-Reply-To: <ZEd8fiQ4rlYXBX6S0CjRZNfP9L5CN2us10z_wAKzKgk=.9b27e5f5-33fe-4ab3-810c-62054002732d@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <_n0HMK1noQxNPICydcCIuSNqJfKIxLHO8S5_lAivyy4=.794689fc-f8e9-4582-8e24-82503ed1073b@github.com>
 <hNmTaUcPM2l705AlHp2tU9z2fFZzTpId0avwr7_U7pk=.2ccbffc3-f8ee-40ae-a5e9-45ce99b1b32a@github.com>
 <X6m7dliUoUzaubf5bXkaCwEmCZaz-d0vomdgneJslsQ=.88804c90-b3dc-4f45-b740-55c41ee57d39@github.com>
 <ZEd8fiQ4rlYXBX6S0CjRZNfP9L5CN2us10z_wAKzKgk=.9b27e5f5-33fe-4ab3-810c-62054002732d@github.com>
Message-ID: <moZMRwCK2LuGQxsA5p7iNalukw8fn_wf39P6qXiVd3U=.20b3f0ed-590a-4daf-bf80-651d96200b09@github.com>

On Tue, 28 Mar 2023 13:08:22 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> It's to close the text span for the `{@return`
>
> <img width="315" alt="image" src="https://user-images.githubusercontent.com/7457876/228246205-ff2730cb-610f-4673-aa30-d110845a34fc.png">
> 
> It belongs to the opening brace for `{@return`. Hard to see with other curls in between.

I would have written:


{@return if the provided object ...


`true` seams redundant to me but I know this style is used within the JDK.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1150586639

From rkennke at openjdk.org  Tue Mar 28 13:29:53 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 28 Mar 2023 13:29:53 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <nRCVukhWG7mplVCtzhcrXxWb9fu3vPVmRfXno0Rk7iE=.3b04aaa0-d3c5-48e4-8514-3fb5d25f9662@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
 <nRCVukhWG7mplVCtzhcrXxWb9fu3vPVmRfXno0Rk7iE=.3b04aaa0-d3c5-48e4-8514-3fb5d25f9662@github.com>
Message-ID: <8XwHgfW44r-rx3JcHxbjjuEe9ykIc3pxcUtT9HjyjU0=.69d97531-26ad-449a-a6de-e344b2a96540@github.com>

On Fri, 24 Mar 2023 11:17:05 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>>  - Set condition flags correctly after fast-lock call on aarch64
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 611:
> 
>> 609:       bind(slow);
>> 610:       testptr(objReg, objReg); // force ZF=0 to indicate failure
>> 611:       jmp(NO_COUNT);
> 
> We set a flag on failure (`NO_COUNT`) path. Should we set the flag on success (`COUNT`) path as well?

The path at COUNT already sets the ZF, there is no need to do it here. NO_COUNT doesn't clear ZF, and fast_lock_impl() may branch to slow with ZF set (on the overflow check) so we need to explicitly clear ZF. However, I just came up with a better way to check for overflow that readily clears the ZF: subtract 1 from the end-offset and make a greater-comparison instead of the greaterEquals that we currently do on the end-offset. That should simplify the code and avoid a branch.

> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 926:
> 
>> 924:       mov(boxReg, tmpReg);
>> 925:       fast_unlock_impl(objReg, boxReg, tmpReg, NO_COUNT);
>> 926:       jmp(COUNT);
> 
> Do we need to care about returning proper flags here?

Yes we do, but fast_unlock_impl() already does the right thing on the failure path, and COUNT does the right thing on the success path. Yes, it is all very ugly. *shrugs*

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1150609171
PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1150610895

From duke at openjdk.org  Tue Mar 28 13:34:53 2023
From: duke at openjdk.org (duke)
Date: Tue, 28 Mar 2023 13:34:53 GMT
Subject: Withdrawn: JDK-8299229: Allow UseZGC with JVMCI and enable nmethod
 entry barrier support
In-Reply-To: <iF4Rwfs3Y0nR6uDQQSlXlt_niQCduqssU4Bk64Qw8I8=.abf5fd1f-aea2-4d94-b7c8-87a5dc9dae06@github.com>
References: <iF4Rwfs3Y0nR6uDQQSlXlt_niQCduqssU4Bk64Qw8I8=.abf5fd1f-aea2-4d94-b7c8-87a5dc9dae06@github.com>
Message-ID: <PBg-6YPPcU8FP-oMnZijvdASFOn4tqDdgjjqdi0Gl9I=.34e6b827-59b9-407f-aa83-0855dff5f3ab@github.com>

On Fri, 13 Jan 2023 20:02:26 GMT, Tom Rodriguez <never at openjdk.org> wrote:

> This exposes the required ZGC values to JVMCI and adds support for nmethod entry barriers.  The ZGC support is straightforward but the nmethod entry barrier required some reworking to fit better into JVMCI usage.  I also removed the epoch based barrier since it was no longer used with simplified the assumptions on the JVMCI side.  There is also a minor loom related fix to support post call nops included.  I could move that into a separate PR if that would be preferred.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/11996

From jvernee at openjdk.org  Tue Mar 28 13:53:27 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 28 Mar 2023 13:53:27 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v8]
In-Reply-To: <82NY-GyOk1U9SLOqfPdRjwT_ypxKVEJx0JItDO0VXik=.5b5c7184-6d6d-4627-8803-03461a2297bc@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <4JIhKmX2VnDfArfFl-1YJfoUzGGBVA5Uvd3mdpatW-s=.5d86f29e-5475-4a4a-91df-d6418356e204@github.com>
 <VSummI7PkJWPb8R-Ee_GQ5e69_mXIvFaeRPf1lVkGac=.011bc0a0-de39-4bdc-bd96-3e02b301a825@github.com>
 <82NY-GyOk1U9SLOqfPdRjwT_ypxKVEJx0JItDO0VXik=.5b5c7184-6d6d-4627-8803-03461a2297bc@github.com>
Message-ID: <FCt-M6MolO72GDY7AP-MFnzmx_Mf1Bi5eDc_UvKafLY=.a784cea2-376a-49f9-9fb4-e090225cfa87@github.com>

On Tue, 28 Mar 2023 10:07:12 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/abi/fallback/LibFallback.java line 61:
>> 
>>> 59:     static final MemorySegment VOID_TYPE = MemorySegment.ofAddress(ffi_type_void());
>>> 60:     static final short STRUCT_TAG = ffi_type_struct();
>>> 61:     private static final long SIZEOF_CIF = sizeofCif();
>> 
>> Won?t?calling `ffi_default_abi()` (and?the?other `ffi_*()`?methods) throw?`UnsatisfiedLinkError` if?`SUPPORTED`?is?`false`?
>
> I think so too. How do we guard agains this @JornVernee ?

You're right. Fix here: https://github.com/minborg/jdk/pull/1

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1150645955

From jvernee at openjdk.org  Tue Mar 28 13:53:29 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 28 Mar 2023 13:53:29 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v12]
In-Reply-To: <ULiv3xz4T-tuemI4RMgY9p0l8qWFdk5pI_p3sj2AKbc=.82f3043a-6f58-468e-80be-403f49aa2e3c@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <ULiv3xz4T-tuemI4RMgY9p0l8qWFdk5pI_p3sj2AKbc=.82f3043a-6f58-468e-80be-403f49aa2e3c@github.com>
Message-ID: <W0dTKlyYvQfBD-Ybxvow74vzQMCw4XA9rZOpaZYRV9g=.8684d12e-776b-4ace-8c85-e303a43a68b7@github.com>

On Tue, 28 Mar 2023 13:14:09 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> API changes for the FFM API (third preview)
>> 
>> Specdiff:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
>> 
>> Javadoc:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyrigth year issues

src/java.base/share/classes/jdk/internal/vm/ForeignLinkerSupport.java line 52:

> 50:         }
> 51:     }
> 52: 

I also noticed that this method is not used and can be removed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1150647849

From rkennke at openjdk.org  Tue Mar 28 14:00:12 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 28 Mar 2023 14:00:12 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v34]
In-Reply-To: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
Message-ID: <um1xeKYtK5Oz0YDTHfxihW54WCrF9d7GvhPH-Y8tl4E=.33996344-c2dc-4ea3-8c01-da4054251a6f@github.com>

> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
> 
> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p
 rotocols.
> 
> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare.
> 
> 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
> 
> 
> Testing:
>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
> 
> ### Performance
> 
> #### Simple Microbenchmark
> 
> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
> 
> |  | x86_64 | aarch64 |
> | -- | -- | -- |
> | -UseFastLocking | 20.651 | 20.764 |
> | +UseFastLocking | 18.896 | 18.908 |
> 
> 
> #### Renaissance
> 
> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
> -- | -- | -- | -- | -- | -- | -- | --
> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Address @shipilev review comments (x86)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10907/files
  - new: https://git.openjdk.org/jdk/pull/10907/files/de45c08e..798615f9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=33
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=32-33

  Stats: 28 lines in 4 files changed: 18 ins; 4 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/10907.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10907/head:pull/10907

PR: https://git.openjdk.org/jdk/pull/10907

From mcimadamore at openjdk.org  Tue Mar 28 14:11:51 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 28 Mar 2023 14:11:51 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v10]
In-Reply-To: <moZMRwCK2LuGQxsA5p7iNalukw8fn_wf39P6qXiVd3U=.20b3f0ed-590a-4daf-bf80-651d96200b09@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <_n0HMK1noQxNPICydcCIuSNqJfKIxLHO8S5_lAivyy4=.794689fc-f8e9-4582-8e24-82503ed1073b@github.com>
 <hNmTaUcPM2l705AlHp2tU9z2fFZzTpId0avwr7_U7pk=.2ccbffc3-f8ee-40ae-a5e9-45ce99b1b32a@github.com>
 <X6m7dliUoUzaubf5bXkaCwEmCZaz-d0vomdgneJslsQ=.88804c90-b3dc-4f45-b740-55c41ee57d39@github.com>
 <ZEd8fiQ4rlYXBX6S0CjRZNfP9L5CN2us10z_wAKzKgk=.9b27e5f5-33fe-4ab3-810c-62054002732d@github.com>
 <moZMRwCK2LuGQxsA5p7iNalukw8fn_wf39P6qXiVd3U=.20b3f0ed-590a-4daf-bf80-651d96200b09@github.com>
Message-ID: <2k3-c9kKwEOuBAu-fO4a1xSmATAR3kGECTYUQafoSy4=.1ed80abc-a8ae-4151-bcfa-52cdd2855ead@github.com>

On Tue, 28 Mar 2023 13:09:45 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> <img width="315" alt="image" src="https://user-images.githubusercontent.com/7457876/228246205-ff2730cb-610f-4673-aa30-d110845a34fc.png">
>> 
>> It belongs to the opening brace for `{@return`. Hard to see with other curls in between.
>
> I would have written:
> 
> 
> {@return if the provided object ...
> 
> 
> `true` seams redundant to me but I know this style is used within the JDK.

Whoops - thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1150685611

From amitkumar at openjdk.org  Tue Mar 28 14:38:31 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Tue, 28 Mar 2023 14:38:31 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v14]
In-Reply-To: <Fh6g8Qtdd0VS96WT8xUIrc4iiPfFICaFR5GG0IYpP8s=.fd3eca92-b604-4d3c-b31e-a731880e4efb@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <Fh6g8Qtdd0VS96WT8xUIrc4iiPfFICaFR5GG0IYpP8s=.fd3eca92-b604-4d3c-b31e-a731880e4efb@github.com>
Message-ID: <NdMVbNsezXjW7duSt3Apc6RbNcAFbLOB72TS-bxBlRI=.ae01bc30-a98e-4866-8f9a-d6a78e0b8a64@github.com>

On Mon, 27 Mar 2023 14:43:04 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
>> 
>> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
>> 
>> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
>> 
>> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
>> 
>> This change supports the following platforms: x86, aarch64, PPC, and RISCV
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   RISCV patch and aarch64 improvement

`{tier1, tier2} X {fast debug, slow debug, release}` testing done for s390x. PR seems clean.
@matias9927 please include port for s390x from this commit: 
https://github.com/offamitkumar/jdk/commit/a582f32f97aefba33cebaf4ace540681dfc0eff5

Thanks

src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp line 652:

> 650:     // Scale the index to be the entry index * sizeof(ResolvedInvokeDynamicInfo)
> 651:     __ sldi(size, size, log2i_exact(sizeof(ResolvedIndyEntry)));
> 652:     __ add(cache, cache, size);

@reinrich Is there any specific reason, why you're not calling load_resolved_indy_entry() method here.  On s390x build/changes are stable even with calling that helper method.

-------------

Marked as reviewed by amitkumar (Author).

PR Review: https://git.openjdk.org/jdk/pull/12778#pullrequestreview-1361010070
PR Review Comment: https://git.openjdk.org/jdk/pull/12778#discussion_r1150566670

From duke at openjdk.org  Tue Mar 28 14:40:08 2023
From: duke at openjdk.org (Afshin Zafari)
Date: Tue, 28 Mar 2023 14:40:08 GMT
Subject: RFR: 8297539: Use PrimitiveConversions::cast for local uses of the
 int<->float union conversion trick [v3]
In-Reply-To: <Fc1LufRzwqeQjXSwyVm3FaJWzbaazUXyArTYPLlGrwM=.034cb09b-79d8-49a1-a68d-b5914a9cc214@github.com>
References: <Fc1LufRzwqeQjXSwyVm3FaJWzbaazUXyArTYPLlGrwM=.034cb09b-79d8-49a1-a68d-b5914a9cc214@github.com>
Message-ID: <NH7fN3_RxyiIv033c7qocb32V083AannceliXFwkFVo=.507eb435-2c6a-4591-a907-88c4c756b6ad@github.com>

> **Only** the instances of using `union` for converting `int` to `float` are replaced with call to `PrimitiveConversions::cast<To>(From)` method. Some few cases with conversion of `long` <->`double` are also replaced with `PrimitiveConversions::cast<To>(From)`. The other instances where the union contains other types of fields than `int` and `float` are left unchanged.
> 
> ### Test
> local hotspot:tier1
> mach5 tiers 1-5

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  8297539: Use PrimitiveConversions::cast for local uses of the int<->float union conversion trick

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13136/files
  - new: https://git.openjdk.org/jdk/pull/13136/files/675997a7..0c19a153

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13136&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13136&range=01-02

  Stats: 24 lines in 4 files changed: 0 ins; 1 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/13136.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13136/head:pull/13136

PR: https://git.openjdk.org/jdk/pull/13136

From matsaave at openjdk.org  Tue Mar 28 15:00:14 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 28 Mar 2023 15:00:14 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v15]
In-Reply-To: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
Message-ID: <ftEZn10a-vH_4ffZGzgF2MBzNObqr7c2q8prOQCijrY=.0b4ce59d-c426-442c-acb3-d6a4e37f78ad@github.com>

> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
> 
> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
> 
> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
> 
> The PPC was provided by @reinrich and the RISCV port was provided by @DingliZhang and @zifeihan.
> 
> This change supports the following platforms: x86, aarch64, PPC, and RISCV

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  s390 update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12778/files
  - new: https://git.openjdk.org/jdk/pull/12778/files/84ed272a..dad70dc5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12778&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12778&range=13-14

  Stats: 105 lines in 4 files changed: 83 ins; 1 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/12778.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12778/head:pull/12778

PR: https://git.openjdk.org/jdk/pull/12778

From kbarrett at openjdk.org  Tue Mar 28 15:31:00 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 28 Mar 2023 15:31:00 GMT
Subject: RFR: 8297539: Use PrimitiveConversions::cast for local uses of the
 int<->float union conversion trick [v3]
In-Reply-To: <NH7fN3_RxyiIv033c7qocb32V083AannceliXFwkFVo=.507eb435-2c6a-4591-a907-88c4c756b6ad@github.com>
References: <Fc1LufRzwqeQjXSwyVm3FaJWzbaazUXyArTYPLlGrwM=.034cb09b-79d8-49a1-a68d-b5914a9cc214@github.com>
 <NH7fN3_RxyiIv033c7qocb32V083AannceliXFwkFVo=.507eb435-2c6a-4591-a907-88c4c756b6ad@github.com>
Message-ID: <G-5LtgbfGtU9-nV-ZZabCKUweEyWnLZPIu8vWv644fQ=.a6c13bee-4eb6-4901-b1a2-d4a4fc93ebad@github.com>

On Tue, 28 Mar 2023 14:40:08 GMT, Afshin Zafari <duke at openjdk.org> wrote:

>> **Only** the instances of using `union` for converting `int` to `float` are replaced with call to `PrimitiveConversions::cast<To>(From)` method. Some few cases with conversion of `long` <->`double` are also replaced with `PrimitiveConversions::cast<To>(From)`. The other instances where the union contains other types of fields than `int` and `float` are left unchanged.
>> 
>> ### Test
>> local hotspot:tier1
>> mach5 tiers 1-5
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8297539: Use PrimitiveConversions::cast for local uses of the int<->float union conversion trick

Changes requested by kbarrett (Reviewer).

src/hotspot/cpu/arm/assembler_arm.hpp line 288:

> 286:     override bool f_lo_is_null() const { return (_bits & ((1 << 19) - 1)) == 0; }
> 287:     override int e() const { return ((_bits << 1) >> (23+1)) - 127; }
> 288:     override unsigned int s() const { return _bits >> 31; }

This shouldn't compile? I think `override` should be after the declarator, so between `const` and the
function body in all of these.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13136#pullrequestreview-1361380232
PR Review Comment: https://git.openjdk.org/jdk/pull/13136#discussion_r1150801503

From stuefe at openjdk.org  Tue Mar 28 16:04:40 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 28 Mar 2023 16:04:40 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <CfaFMydhpKfCzkc8re16y_oQZvGvO_KLkEN672phdU8=.3dfecf58-9038-48ac-9eb9-f0a76d742d40@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
 <nRCVukhWG7mplVCtzhcrXxWb9fu3vPVmRfXno0Rk7iE=.3b04aaa0-d3c5-48e4-8514-3fb5d25f9662@github.com>
 <CfaFMydhpKfCzkc8re16y_oQZvGvO_KLkEN672phdU8=.3dfecf58-9038-48ac-9eb9-f0a76d742d40@github.com>
Message-ID: <RqLUI4UYLYqW3wpKY9oKjEm6ocLVXdX2GKLC_SSGnwY=.7bc81122-cffa-4461-a55c-e77a17cc8ebc@github.com>

On Fri, 24 Mar 2023 16:54:59 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/share/runtime/lockStack.cpp line 42:
>> 
>>> 40: 
>>> 41: #ifndef PRODUCT
>>> 42: void LockStack::validate(const char* msg) const {
>> 
>> Would you also like to check there are no `nullptr` elements on stack here?
>
> Please also verify against over- and underflow, and better than just null checks check that every oop really is an oop. I added this to my code:
> 
>   assert((_offset <=  end_offset()), "lockstack overflow: _offset %d end_offset %d", _offset, end_offset());
>   assert((_offset >= start_offset()), "lockstack underflow: _offset %d end_offset %d", _offset, start_offset());
>   int end = to_index(_offset);
>   for (int i = 0; i < end; i++) {
>     assert(oopDesc::is_oop(_base[i]), "index %i: not an oop (" PTR_FORMAT ")", i, p2i(_base[i]));
> ...

Just realized that my proposal of oop-checking does not work since during GC oop can be moved and will temporarily be invalid.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1150847182

From mdoerr at openjdk.org  Tue Mar 28 16:36:10 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 28 Mar 2023 16:36:10 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v14]
In-Reply-To: <NdMVbNsezXjW7duSt3Apc6RbNcAFbLOB72TS-bxBlRI=.ae01bc30-a98e-4866-8f9a-d6a78e0b8a64@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <Fh6g8Qtdd0VS96WT8xUIrc4iiPfFICaFR5GG0IYpP8s=.fd3eca92-b604-4d3c-b31e-a731880e4efb@github.com>
 <NdMVbNsezXjW7duSt3Apc6RbNcAFbLOB72TS-bxBlRI=.ae01bc30-a98e-4866-8f9a-d6a78e0b8a64@github.com>
Message-ID: <7ntbBinhQ6xnrVi4hIs05Lqq9UVDL3Q1nKku2iaP5CA=.a9de7b8a-35cd-40f3-af3e-b3e31138d192@github.com>

On Tue, 28 Mar 2023 12:54:41 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   RISCV patch and aarch64 improvement
>
> src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp line 652:
> 
>> 650:     // Scale the index to be the entry index * sizeof(ResolvedInvokeDynamicInfo)
>> 651:     __ sldi(size, size, log2i_exact(sizeof(ResolvedIndyEntry)));
>> 652:     __ add(cache, cache, size);
> 
> @reinrich Is there any specific reason, why you're not calling load_resolved_indy_entry() method here.  On s390x build/changes are stable even with calling that helper method.

It should work if we move the addition of `Array<ResolvedIndyEntry>::base_offset_in_bytes()` into the other caller.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12778#discussion_r1150886679

From dlong at openjdk.org  Tue Mar 28 16:47:59 2023
From: dlong at openjdk.org (Dean Long)
Date: Tue, 28 Mar 2023 16:47:59 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <OXd2CO6DV__IRLKNikokd4x-t-9F3MhsrislEHUnUpg=.613d3342-6851-48c7-acf0-183b86c2febc@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
 <z1u-Lf3nAHoI5NyO71NmJDC49m10j3galYAyQg-2ru4=.503c3430-7965-4f53-b4f4-e7677dfe333f@github.com>
 <OXd2CO6DV__IRLKNikokd4x-t-9F3MhsrislEHUnUpg=.613d3342-6851-48c7-acf0-183b86c2febc@github.com>
Message-ID: <M4W-Gk4SInloCkH0Zn1lPEYouDazO6qgTOjbgTtGOis=.ec90901a-3dc5-4de2-bce8-9aa666f3593f@github.com>

On Tue, 28 Mar 2023 10:53:10 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> src/hotspot/share/runtime/threads.cpp line 1422:
>> 
>>> 1420: }
>>> 1421: 
>>> 1422: JavaThread* Threads::owning_thread_from_object(ThreadsList * t_list, oop obj) {
>> 
>> Is this thread-safe?
>
> My last commit changed that code to only run during safepoints. It should be safe now, and I added an assert that verifies that it is only run at safepoint.

I see the assert in `owning_thread_from_monitor` but not `owning_thread_from_object`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1150900864

From lucy at openjdk.org  Tue Mar 28 16:52:41 2023
From: lucy at openjdk.org (Lutz Schmidt)
Date: Tue, 28 Mar 2023 16:52:41 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v15]
In-Reply-To: <ftEZn10a-vH_4ffZGzgF2MBzNObqr7c2q8prOQCijrY=.0b4ce59d-c426-442c-acb3-d6a4e37f78ad@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <ftEZn10a-vH_4ffZGzgF2MBzNObqr7c2q8prOQCijrY=.0b4ce59d-c426-442c-acb3-d6a4e37f78ad@github.com>
Message-ID: <DiUbm9frghV8nPqbTSGqD0c6lug8M66ewg53k_RruwI=.e5850944-aa31-4695-979a-046294411f08@github.com>

On Tue, 28 Mar 2023 15:00:14 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
>> 
>> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
>> 
>> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
>> 
>> The PPC port was provided by @reinrich, RISCV was provided by @DingliZhang and @zifeihan, and S390x by @offamitkumar.
>> 
>> This change supports the following platforms: x86, aarch64, PPC, RISCV, and S390x
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   s390 update

s390 changes look good. 
Thank you, Amit, for working hard to get this done.

src/hotspot/cpu/s390/templateTable_s390.cpp line 2432:

> 2430: 
> 2431:   // The invokedynamic is unresolved iff method is NULL
> 2432:   __ z_clgij(method, 0, Assembler::bcondNotEqual, resolved); // method != 0, jump to resolved

In the light of the ongoing effort to substitute all occurrences of NULL (and (void*)0) with nullptr, you may want to substitute 0 with (unsigned long)nullptr here.

src/hotspot/cpu/s390/templateTable_s390.cpp line 2442:

> 2440:   __ z_lg(method, Address(cache, in_bytes(ResolvedIndyEntry::method_offset())));
> 2441: #ifdef ASSERT
> 2442:   __ z_clgij(method, 0, Assembler::bcondNotEqual, resolved); // method != 0, jump to resolved

Same as above.

-------------

Marked as reviewed by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12778#pullrequestreview-1361535849
PR Review Comment: https://git.openjdk.org/jdk/pull/12778#discussion_r1150904328
PR Review Comment: https://git.openjdk.org/jdk/pull/12778#discussion_r1150904861

From sspitsyn at openjdk.org  Tue Mar 28 18:57:23 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 28 Mar 2023 18:57:23 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v8]
In-Reply-To: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
Message-ID: <uZLGDh5UIBW0AYrgh4ndTUtnqNfp2zGgnx2zQm-kBaI=.f3d7e776-0e81-4272-bc31-2cdee9dc9d23@github.com>

> The fix is to enable virtual threads support for late binding JVMTI agents.
> The fix includes:
> - New function `JvmtiEnvBase::enable_virtual_threads_notify_jvmti()` which does enabling JVMTI VTMS transition notifications in case of agent loaded into running VM. This function executes a VM operation counting VTMS transition bits in all `JavaThread`'s to correctly set the static counter `_VTMS_transition_count` needed for VTMS transition protocol.
> - New function `JvmtiEnvBase::disable_virtual_threads_notify_jvmti()` which is needed for testing. It is used by the `WhiteBox` API.
> - New WhiteBox function `WB_SetVirtualThreadsNotifyJvmtiMode(JNIEnv* env, jobject wb, jboolean enable)` needed for testing of this update.
> - New regression test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
> 
> Testing:
> - New test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
> - The originally failed tests are expected to pass 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:

  fixed trailing spaces in two files

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13133/files
  - new: https://git.openjdk.org/jdk/pull/13133/files/526c2788..2c59c54b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13133&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13133&range=06-07

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/13133.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13133/head:pull/13133

PR: https://git.openjdk.org/jdk/pull/13133

From sspitsyn at openjdk.org  Tue Mar 28 19:27:37 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 28 Mar 2023 19:27:37 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v8]
In-Reply-To: <uZLGDh5UIBW0AYrgh4ndTUtnqNfp2zGgnx2zQm-kBaI=.f3d7e776-0e81-4272-bc31-2cdee9dc9d23@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <uZLGDh5UIBW0AYrgh4ndTUtnqNfp2zGgnx2zQm-kBaI=.f3d7e776-0e81-4272-bc31-2cdee9dc9d23@github.com>
Message-ID: <_b1VTI8uk98CeJkZ3_xJXKgienCA1N278sspOWuXgSY=.fcecc846-c7c4-43c4-ab60-435bd3923842@github.com>

On Tue, 28 Mar 2023 18:57:23 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The fix is to enable virtual threads support for late binding JVMTI agents.
>> The fix includes:
>> - New function `JvmtiEnvBase::enable_virtual_threads_notify_jvmti()` which does enabling JVMTI VTMS transition notifications in case of agent loaded into running VM. This function executes a VM operation counting VTMS transition bits in all `JavaThread`'s to correctly set the static counter `_VTMS_transition_count` needed for VTMS transition protocol.
>> - New function `JvmtiEnvBase::disable_virtual_threads_notify_jvmti()` which is needed for testing. It is used by the `WhiteBox` API.
>> - New WhiteBox function `WB_SetVirtualThreadsNotifyJvmtiMode(JNIEnv* env, jobject wb, jboolean enable)` needed for testing of this update.
>> - New regression test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
>> 
>> Testing:
>> - New test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
>> - The originally failed tests are expected to pass 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:
> 
>   fixed trailing spaces in two files

Pushed a couple of updates which include:
(1) Addressed review comments:
   - fixed minor issues in `libToggleNotifyJvmtiTest.cpp`: added volatile specifier and removed unneeded static variable
   - fixed the typo in `disable_virtual_threads_notify_jvmti`
   - added comments  for two new functions in `jvmtiEnvBase` (enabling and disabling notifyJvmti events)
   - added comments to `ToggleNotifyJvmtiTest.java`

(2) Refactored the `ToggleNotifyJvmtiTest.java` to run isolated sequential test cycles for the sake of `disable_virtual_threads_notify_jvmti` safety (no virtual threads are allowed to run when it is executed)

(3) Extended `libToggleNotifyJvmtiTest.cpp` to request more JVMTI events: `VirtualThreadEnd`, `ThreadStart` and `ThreadEnd`

(4) Other updates:
 - updated `JVM_VirtualThreadHideFrames` and `LibraryCallKit::inline_native_notify_jvmti_hide` to always (unconditionally) set the temporary VTMS transition bit to avoid asserts
 - renamed VMop: `InitNotifyJvmtiEventsMode` => `SetNotifyJvmtiEventsMode`
 - updated `VM_SetNotifyJvmtiEventsMode` to correct `jt->jvmti_thread_state()` and `jt->jvmti_vthread()` if necessary (needed to fix `JvmtiThreadState` double-deallocation issue)
 
 I hope that all review comments have been addressed now. Please, let me know if anything is missed.
 The mach5 tiers 1-6 tuns are good.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13133#issuecomment-1487477975

From alanb at openjdk.org  Tue Mar 28 19:36:18 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Mar 2023 19:36:18 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v2]
In-Reply-To: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
Message-ID: <9RJ4unb3FjazYLi0BbWs1NGN9h50Z1fvAz1ZNds5mO4=.cb02f148-66bd-4429-9c30-ea4a6dcbe4d7@github.com>

> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview.
> 
> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently.
> 
> In addition, there are a small number of implementation changes to sync up from the loom fibers branch:
> 
> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where  end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly.
> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes.
> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs.
> - New system property to print a stack trace when a virtual thread sets its own value of a TL.
> - ThreadPerTaskExecutor is changed to use FutureTask.
> 
> Testing: tier1-6.

Alan Bateman 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:

 - ThreadSleepEvent refactoring
 - Merge
 - Merge
 - Initial sync from fibers branch

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13203/files
  - new: https://git.openjdk.org/jdk/pull/13203/files/1c62dc8a..7906dbb4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13203&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13203&range=00-01

  Stats: 2112 lines in 47 files changed: 1050 ins; 822 del; 240 mod
  Patch: https://git.openjdk.org/jdk/pull/13203.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13203/head:pull/13203

PR: https://git.openjdk.org/jdk/pull/13203

From matsaave at openjdk.org  Tue Mar 28 19:50:36 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 28 Mar 2023 19:50:36 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v16]
In-Reply-To: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
Message-ID: <5YPjVZsQAVVL9PHaGu7Mc7kNE0WvPrsiCubKSGzKxvk=.78e8f8fb-1005-4bd7-9ad1-d1dd3aacbe04@github.com>

> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
> 
> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
> 
> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
> 
> The PPC port was provided by @reinrich, RISCV was provided by @DingliZhang and @zifeihan, and S390x by @offamitkumar.
> 
> This change supports the following platforms: x86, aarch64, PPC, RISCV, and S390x

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  s390x NULL to nullptr

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12778/files
  - new: https://git.openjdk.org/jdk/pull/12778/files/dad70dc5..72ef0475

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12778&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12778&range=14-15

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12778.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12778/head:pull/12778

PR: https://git.openjdk.org/jdk/pull/12778

From matsaave at openjdk.org  Tue Mar 28 19:51:08 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 28 Mar 2023 19:51:08 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v15]
In-Reply-To: <ftEZn10a-vH_4ffZGzgF2MBzNObqr7c2q8prOQCijrY=.0b4ce59d-c426-442c-acb3-d6a4e37f78ad@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <ftEZn10a-vH_4ffZGzgF2MBzNObqr7c2q8prOQCijrY=.0b4ce59d-c426-442c-acb3-d6a4e37f78ad@github.com>
Message-ID: <w9eeUJmIIBFcBuQFXbcZzse6L0ggVkplgQ21DqHWXZA=.ccb91d1a-ace5-4ecb-8b55-4ebccc050c30@github.com>

On Tue, 28 Mar 2023 15:00:14 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
>> 
>> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
>> 
>> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
>> 
>> The PPC port was provided by @reinrich, RISCV was provided by @DingliZhang and @zifeihan, and S390x by @offamitkumar.
>> 
>> This change supports the following platforms: x86, aarch64, PPC, RISCV, and S390x
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   s390 update

Thank you to all the reviewers for the detailed feedback, corrections, and improvements! 
@theRealAph @dougxc  @fparain @coleenp @RealFYang @RealLucy @turbanoff @TheRealMDoerr @calvinccheung

Also, thank you very much for completing the ports @reinrich, @DingliZhang, @zifeihan, and @offamitkumar!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12778#issuecomment-1487506191

From matsaave at openjdk.org  Tue Mar 28 19:53:59 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 28 Mar 2023 19:53:59 GMT
Subject: Integrated: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry
In-Reply-To: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
Message-ID: <ty_xxdUMY43nksG5XK_-iPPY5FXP_41AY88k4daGbRo=.33262821-4b01-44a0-8077-5d1762dbc238@github.com>

On Mon, 27 Feb 2023 21:37:34 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
> 
> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
> 
> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
> 
> The PPC port was provided by @reinrich, RISCV was provided by @DingliZhang and @zifeihan, and S390x by @offamitkumar.
> 
> This change supports the following platforms: x86, aarch64, PPC, RISCV, and S390x

This pull request has now been integrated.

Changeset: 3fbbfd17
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3fbbfd17491906d707f73fe6b0db2989363c303a
Stats:     1516 lines in 58 files changed: 1109 ins; 173 del; 234 mod

8301995: Move invokedynamic resolution information out of ConstantPoolCacheEntry

Co-authored-by: Richard Reingruber <rrich at openjdk.org>
Co-authored-by: Dingli Zhang <dzhang at openjdk.org>
Co-authored-by: Gui Cao <gcao at openjdk.org>
Co-authored-by: Amit Kumar <amitkumar at openjdk.org>
Reviewed-by: coleenp, dnsimon, fparain, gcao, aph, fyang, amitkumar, lucy

-------------

PR: https://git.openjdk.org/jdk/pull/12778

From psandoz at openjdk.org  Tue Mar 28 20:00:35 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 28 Mar 2023 20:00:35 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v2]
In-Reply-To: <9RJ4unb3FjazYLi0BbWs1NGN9h50Z1fvAz1ZNds5mO4=.cb02f148-66bd-4429-9c30-ea4a6dcbe4d7@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <9RJ4unb3FjazYLi0BbWs1NGN9h50Z1fvAz1ZNds5mO4=.cb02f148-66bd-4429-9c30-ea4a6dcbe4d7@github.com>
Message-ID: <lOtzWvlXE-b0tsrlbd7w7ENFWgjTy24npIDyfXVL9L4=.11c20ac5-7897-4576-bbcd-ed5544782d86@github.com>

On Tue, 28 Mar 2023 19:36:18 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview.
>> 
>> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently.
>> 
>> In addition, there are a small number of implementation changes to sync up from the loom fibers branch:
>> 
>> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where  end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly.
>> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes.
>> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs.
>> - New system property to print a stack trace when a virtual thread sets its own value of a TL.
>> - ThreadPerTaskExecutor is changed to use FutureTask.
>> 
>> Testing: tier1-6.
>
> Alan Bateman 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:
> 
>  - ThreadSleepEvent refactoring
>  - Merge
>  - Merge
>  - Initial sync from fibers branch

src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 72:

> 70:         RECORD_PATTERNS,
> 71:         // not used
> 72:         VIRTUAL_THREADS,

Can the enum constant also be removed?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1151091740

From dcubed at openjdk.org  Tue Mar 28 21:43:01 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 28 Mar 2023 21:43:01 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v30]
In-Reply-To: <2cIUWaQL9GilRFtckC9SpcJVet_0Rb8SmFS1tfe8AWE=.35713c3e-1f5d-45e5-8a3c-d732070d7b81@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <lzS3PlrHxm9JjbOyReXPNbqZJf5nb13kdMB6fFK52m0=.9262cfa5-dff5-4fcf-aaf0-5a4e993c5071@github.com>
 <2cIUWaQL9GilRFtckC9SpcJVet_0Rb8SmFS1tfe8AWE=.35713c3e-1f5d-45e5-8a3c-d732070d7b81@github.com>
Message-ID: <C5ix2Lh79hAiM4NkDdcZVcYSleC-RQ7uGcu3G0ymBGU=.8393c83a-a02d-4bd0-aace-5b8aeac9bed7@github.com>

On Tue, 28 Mar 2023 02:48:30 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Ensure safepoint when processing lock-stack
>
> src/hotspot/share/runtime/threads.cpp line 1433:
> 
>> 1431: 
>> 1432: JavaThread* Threads::owning_thread_from_monitor(ThreadsList* t_list, ObjectMonitor* monitor) {
>> 1433:   assert(SafepointSynchronize::is_at_safepoint(), "not safe outside of safepoint");
> 
> Shouldn't this be gated on UseFastLocking?

Hmmm.... `owning_thread_from_monitor()` is only called from
`ObjectSynchronizer::get_lock_owner()` when `get_lock_owner()`
knows that it has an ObjectMonitor in hand. I'm not at all sure that
we can assert that `ObjectSynchronizer::get_lock_owner()` is
only called from a safepoint.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1151177370

From mikael at openjdk.org  Tue Mar 28 21:43:37 2023
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Tue, 28 Mar 2023 21:43:37 GMT
Subject: RFR: JDK-8294266: Add a way to pre-touch java thread stacks [v4]
In-Reply-To: <LuMQx6RZTOp5_Yl_v6gFaQw4lMzhdTv7neo45cZX1Pk=.d1968e1b-3384-414a-8573-745e1e41faba@github.com>
References: <pbqYDWsnkM5XdmZE6QK7wV7dNuQOCjdyPzw5OlQkSxo=.4ea19fb5-d031-42f7-850c-ae42399e0e80@github.com>
 <LuMQx6RZTOp5_Yl_v6gFaQw4lMzhdTv7neo45cZX1Pk=.d1968e1b-3384-414a-8573-745e1e41faba@github.com>
Message-ID: <XmhiUKHhl2ilws7km_bfkavkdYfTbwAIkYN0gLnW1iA=.e2bee6b2-6038-44ab-ae0d-4ef91d76f782@github.com>

On Mon, 14 Nov 2022 10:16:58 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> When doing performance- and footprint analysis, `AlwaysPreTouch` option is very handy for reducing noise. It would be good to have a similar option for pre-touching thread stacks. In addition to reducing noise, it can serve as worst-case test for thread costs, as well as a test for NMT regressions.
>> 
>> Patch adds a new diagnostic switch, `AlwaysPreTouchStacks`, as a companion switch to `AlwaysPreTouch`. Touching is super-simple using `alloca()`. Also, regression test.
>> 
>> Examples:
>> 
>> NMT, thread stacks, 10000 Threads, default:
>> 
>> 
>> -                    Thread (reserved=10332400KB, committed=331828KB)                                       
>>                             (thread #10021)                                                                 
>>                             (stack: reserved=10301560KB, committed=300988KB)                                
>>                             (malloc=19101KB #60755)                                                         
>>                             (arena=11739KB #20037)                                                          
>> 
>> 
>> NMT, thread stacks, 10000 Threads, +AlwaysPreTouchStacks:
>> 
>> 
>> -                    Thread (reserved=10332400KB, committed=10284360KB)                        
>>                             (thread #10021)                                                    
>>                             (stack: reserved=10301560KB, committed=10253520KB)                 
>>                             (malloc=19101KB #60755)                                            
>>                             (arena=11739KB #20037)
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test changes, comment change

FYI: We're currently in the process of investigating adding support for doing almost the exact opposite of this in JDK-8303215. In particular, we're looking to effectively "undo" the effects of huge page(s) temporarily having been used for the stack. There's potentially room for sharing some of the implementation aspects.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10403#issuecomment-1487630387

From lmesnik at openjdk.org  Tue Mar 28 23:53:35 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 28 Mar 2023 23:53:35 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v2]
In-Reply-To: <9RJ4unb3FjazYLi0BbWs1NGN9h50Z1fvAz1ZNds5mO4=.cb02f148-66bd-4429-9c30-ea4a6dcbe4d7@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <9RJ4unb3FjazYLi0BbWs1NGN9h50Z1fvAz1ZNds5mO4=.cb02f148-66bd-4429-9c30-ea4a6dcbe4d7@github.com>
Message-ID: <OPz26p0QvEh0Cw-SHvuEi3cslPvNXpqnA5GBs8TXjUo=.996b3218-9cb1-4773-b96c-259eeb99d521@github.com>

On Tue, 28 Mar 2023 19:36:18 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview.
>> 
>> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently.
>> 
>> In addition, there are a small number of implementation changes to sync up from the loom fibers branch:
>> 
>> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where  end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly.
>> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes.
>> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs.
>> - New system property to print a stack trace when a virtual thread sets its own value of a TL.
>> - ThreadPerTaskExecutor is changed to use FutureTask.
>> 
>> Testing: tier1-6.
>
> Alan Bateman 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:
> 
>  - ThreadSleepEvent refactoring
>  - Merge
>  - Merge
>  - Initial sync from fibers branch

Changes requested by lmesnik (Reviewer).

src/java.base/share/classes/java/lang/System.java line 2566:

> 2564: 
> 2565:             public <V> V executeOnCarrierThread(Callable<V> task) throws Exception {
> 2566:                 if (Thread.currentThread() instanceof VirtualThread vthread) {

Any specific reason to don't use Thread.currentThread().isVirtual()?

test/hotspot/jtreg/runtime/vthread/JNIMonitor/JNIMonitor.java line 31:

> 29:  * @summary Tests that JNI monitors work correctly with virtual threads
> 30:  * @library /test/lib
> 31:  * @compile JNIMonitor.java

I think that test file is compiled implicitly. So this line could be just removed. 
The same is for all other similar tests.

test/jdk/com/sun/jdi/TestScaffold.java line 980:

> 978: 
> 979:         if (wrapper.equals("Virtual")) {
> 980:             threadFactory = Thread.ofVirtual().factory();

Should be line 
469: argInfo.targetVMArgs += "--enable-preview ";
removed also?

test/jdk/com/sun/management/ThreadMXBean/VirtualThreads.java line 143:

> 141:             long[] tids = new long[] { tid0, tid1 };
> 142:             long[] cpuTimes = bean.getThreadCpuTime(tids);
> 143:             if (Thread.currentThread().isVirtual()) {

How it worked before?

test/jdk/java/lang/Thread/virtual/GetStackTrace.java line 30:

> 28:  * @requires vm.continuations
> 29:  * @modules java.base/java.lang:+open
> 30:  * @run testng/othervm -XX:+UnlockDiagnosticVMOptions -XX:+ShowHiddenFrames GetStackTrace

shouldn't be main/othervm ?

test/jdk/java/lang/Thread/virtual/VirtualThreadPinnedEventThrows.java line 29:

> 27:  * @modules java.base/jdk.internal.event
> 28:  * @compile/module=java.base jdk/internal/event/VirtualThreadPinnedEvent.java
> 29:  * @run junit VirtualThreadPinnedEventThrows

Shouldn't be 'junit/othervm' used here to ensure that updated VirtualThreadPinnedEvent is used? I don't know these details of jtreg.

test/jdk/jdk/incubator/concurrent/StructuredTaskScope/PreviewFeaturesNotEnabled.java line 2:

> 1: /*
> 2:  * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved.

Not sure I understand what happens. The file is 
test/jdk/jdk/incubator/concurrent/StructuredTaskScope/PreviewFeaturesNotEnabled.java
while it contains is public class VirtualThreadPinnedEvent. Copied by mistake?

-------------

PR Review: https://git.openjdk.org/jdk/pull/13203#pullrequestreview-1361847681
PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1151259675
PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1151175072
PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1151168150
PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1151168861
PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1151112603
PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1151153758
PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1151119165

From dholmes at openjdk.org  Wed Mar 29 00:09:36 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 29 Mar 2023 00:09:36 GMT
Subject: RFR: 8303210: [linux,
 Windows] Make UseSystemMemoryBarrier available as product flag [v5]
In-Reply-To: <w8QBaQtAtWepK1PRVY8uw8PO53iDnmtRt0P7o9jfDX8=.aa8c2e09-e9d6-4bff-8347-0033f0866774@github.com>
References: <9eZo1xYNGhjMSC9lDXKtkO1eyU_H-Veuh1AeP3CPKbg=.69b6c4ff-a3ef-439f-8468-21fec9de1825@github.com>
 <w8QBaQtAtWepK1PRVY8uw8PO53iDnmtRt0P7o9jfDX8=.aa8c2e09-e9d6-4bff-8347-0033f0866774@github.com>
Message-ID: <NN0F3COXkgmmz3U9A29FNw6yDRGeZNNZctR0719VHsY=.5fad2479-bf04-425c-b471-0f1c462d112e@github.com>

On Tue, 28 Mar 2023 09:45:10 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> I'd like to enable UseSystemMemoryBarrier by default on supported Operating Systems in order to improve performance of thread state transitions (I/O, JNI, foreign function calls, JIT compiler threads, etc.). See JBS issue for more details.
>> Unfortunately, the feature was not yet implemented on all platforms. I added the code, but need the platform maintainers to check if it can be used reliably (and ideally if the performance improves). It's easy to switch it off again in case of problems.
>> 
>> Update: Startup performance and some benchmarks on some platforms are impacted (see below). So, this PR no longer switches it on by default.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move flag configuration and initialization to os::init_2.

Approval in principal, but the initialization code needs fixing up.

> Note: The feature requires at least Linux 4.14. The flag needs to be off for older versions. 

In that case we should do a version check when trying to initialize, and at least warn if the OS is too old.

Thanks

src/hotspot/os/aix/os_aix.cpp line 2228:

> 2226:   if (UseSystemMemoryBarrier) {
> 2227:     if (!SystemMemoryBarrier::initialize()) {
> 2228:       if (!FLAG_IS_DEFAULT(UseSystemMemoryBarrier)) {

Have we processed this flag by this stage?

src/hotspot/os/aix/os_aix.cpp line 2348:

> 2346:     }
> 2347:     FLAG_SET_ERGO(UseSystemMemoryBarrier, false);
> 2348:   }

This looks like a leftover ?? It shouldn't be here.

-------------

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12753#pullrequestreview-1362077036
PR Review Comment: https://git.openjdk.org/jdk/pull/12753#discussion_r1151266939
PR Review Comment: https://git.openjdk.org/jdk/pull/12753#discussion_r1151267317

From dholmes at openjdk.org  Wed Mar 29 00:09:38 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 29 Mar 2023 00:09:38 GMT
Subject: RFR: 8303210: [linux,
 Windows] Make UseSystemMemoryBarrier available as product flag [v5]
In-Reply-To: <NN0F3COXkgmmz3U9A29FNw6yDRGeZNNZctR0719VHsY=.5fad2479-bf04-425c-b471-0f1c462d112e@github.com>
References: <9eZo1xYNGhjMSC9lDXKtkO1eyU_H-Veuh1AeP3CPKbg=.69b6c4ff-a3ef-439f-8468-21fec9de1825@github.com>
 <w8QBaQtAtWepK1PRVY8uw8PO53iDnmtRt0P7o9jfDX8=.aa8c2e09-e9d6-4bff-8347-0033f0866774@github.com>
 <NN0F3COXkgmmz3U9A29FNw6yDRGeZNNZctR0719VHsY=.5fad2479-bf04-425c-b471-0f1c462d112e@github.com>
Message-ID: <cDZamfA5RSTBWdVrRKhnGabnb20lX8aojWSSaWVOqSo=.1a85d616-f028-4af8-9bde-43a06ffd138d@github.com>

On Wed, 29 Mar 2023 00:00:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move flag configuration and initialization to os::init_2.
>
> src/hotspot/os/aix/os_aix.cpp line 2228:
> 
>> 2226:   if (UseSystemMemoryBarrier) {
>> 2227:     if (!SystemMemoryBarrier::initialize()) {
>> 2228:       if (!FLAG_IS_DEFAULT(UseSystemMemoryBarrier)) {
> 
> Have we processed this flag by this stage?

This really should be done once in shared code, as well - somewhere in arguments.cpp

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12753#discussion_r1151268129

From prappo at openjdk.org  Wed Mar 29 00:11:36 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 29 Mar 2023 00:11:36 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v2]
In-Reply-To: <OPz26p0QvEh0Cw-SHvuEi3cslPvNXpqnA5GBs8TXjUo=.996b3218-9cb1-4773-b96c-259eeb99d521@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <9RJ4unb3FjazYLi0BbWs1NGN9h50Z1fvAz1ZNds5mO4=.cb02f148-66bd-4429-9c30-ea4a6dcbe4d7@github.com>
 <OPz26p0QvEh0Cw-SHvuEi3cslPvNXpqnA5GBs8TXjUo=.996b3218-9cb1-4773-b96c-259eeb99d521@github.com>
Message-ID: <nAYYfgaA9bduK7b1vG6ZtTeygdZXntRpj6DlzEeXG8k=.23d6bac1-1b04-48f9-ba5c-c5c976e7d59e@github.com>

On Tue, 28 Mar 2023 23:47:02 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Alan Bateman 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:
>> 
>>  - ThreadSleepEvent refactoring
>>  - Merge
>>  - Merge
>>  - Initial sync from fibers branch
>
> src/java.base/share/classes/java/lang/System.java line 2566:
> 
>> 2564: 
>> 2565:             public <V> V executeOnCarrierThread(Callable<V> task) throws Exception {
>> 2566:                 if (Thread.currentThread() instanceof VirtualThread vthread) {
> 
> Any specific reason to don't use Thread.currentThread().isVirtual()?

To use the pattern variable to call `executeOnCarrierThread` on it?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1151270089

From lmesnik at openjdk.org  Wed Mar 29 00:18:34 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 29 Mar 2023 00:18:34 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v2]
In-Reply-To: <nAYYfgaA9bduK7b1vG6ZtTeygdZXntRpj6DlzEeXG8k=.23d6bac1-1b04-48f9-ba5c-c5c976e7d59e@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <9RJ4unb3FjazYLi0BbWs1NGN9h50Z1fvAz1ZNds5mO4=.cb02f148-66bd-4429-9c30-ea4a6dcbe4d7@github.com>
 <OPz26p0QvEh0Cw-SHvuEi3cslPvNXpqnA5GBs8TXjUo=.996b3218-9cb1-4773-b96c-259eeb99d521@github.com>
 <nAYYfgaA9bduK7b1vG6ZtTeygdZXntRpj6DlzEeXG8k=.23d6bac1-1b04-48f9-ba5c-c5c976e7d59e@github.com>
Message-ID: <6cV6Ar01qN8gh-PiP5uhsR294ceiYKVv3k7CR5qllw4=.d428e6ad-4fb4-4d33-8705-672eef534f1d@github.com>

On Wed, 29 Mar 2023 00:08:21 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/System.java line 2566:
>> 
>>> 2564: 
>>> 2565:             public <V> V executeOnCarrierThread(Callable<V> task) throws Exception {
>>> 2566:                 if (Thread.currentThread() instanceof VirtualThread vthread) {
>> 
>> Any specific reason to don't use Thread.currentThread().isVirtual()?
>
> To use the pattern variable to call `executeOnCarrierThread` on it?

ough, missed the last words in the line, thanks

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1151273326

From fjiang at openjdk.org  Wed Mar 29 01:08:35 2023
From: fjiang at openjdk.org (Feilong Jiang)
Date: Wed, 29 Mar 2023 01:08:35 GMT
Subject: RFR: 8305008: RISC-V: Factor out immediate checking functions from
 assembler_riscv.inline.hpp [v2]
In-Reply-To: <E-CIFmWm7kSmdB0j0UUCd9F2sbzryngHDCgbKoSd8vA=.8485fbbe-6476-43fa-90f1-5bba60378403@github.com>
References: <zOPJRtrXmBK17ZgSm-THTp8qCXhh7tSNg6VRVFoLz9Y=.763009a8-a651-499d-a0e1-f114f3c842f0@github.com>
 <E-CIFmWm7kSmdB0j0UUCd9F2sbzryngHDCgbKoSd8vA=.8485fbbe-6476-43fa-90f1-5bba60378403@github.com>
Message-ID: <AzDnl09LzEXnBgoMSNifXvYxTeGdRypvAQRoqfQwynM=.4d6a766f-d2d1-4ff7-a0ed-9d2b3a30b572@github.com>

On Tue, 28 Mar 2023 10:08:15 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

>> The call-point to 'is_imm_in_range', 'is_unsigned_imm_in_range' and 'is_offset_in_range' in assembler_riscv.inline.hpp could to be replaced with shared code function 'is_simm' and 'is_uimm'.
>> 
>> For 'is_imm_in_range', if align_bits = 0, then the call point can be changed to call 'is_simm'. If align_bits = 1, then an additional summation judgement is added to determine if it is a multiple of 2. For 'is_unsigned_imm_in_range', we can first determine if it is greater than 0, and then call 'is_uimm' further. 'is_offset_in_range' can be changed directly to call 'is_simm'. This patch also refactored for is_valid_riscv64_address and movptr.
>> 
>> This patch removed the original functions from assembler_riscv.inline.hpp and defined some fixed-width checking functions based on the number of immediate or offset bits in the spec[1]. At the same time, we also adjusted two includes to fix the compilation error after the modification.
>> 
>> This patch also renames the function 'operand_valid_for_add_immediate' to 'operand_valid_for_add_sub_immediate' to make it consistent with its usage.
>> 
>> Finally, this patch modified the return value in os::non_memory_address_word to avoid an imm64 value of -1 in MacroAssembler::movptr.
>> 
>> [1] https://github.com/riscv/riscv-isa-manual/releases/download/draft-20230131-c0b298a/riscv-spec.pdf
>> 
>> ### Testing:
>> 
>> On Unmatched with release build:
>> - [x] Tier1 tests
>> - [ ] Tier2 tests
>> - [ ] Tier3 tests
>
> Dingli Zhang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove unecessary zero checking
>  - Fix assert

Okay then.

-------------

Marked as reviewed by fjiang (Author).

PR Review: https://git.openjdk.org/jdk/pull/13202#pullrequestreview-1362113992

From xlinzheng at openjdk.org  Wed Mar 29 02:30:29 2023
From: xlinzheng at openjdk.org (Xiaolin Zheng)
Date: Wed, 29 Mar 2023 02:30:29 GMT
Subject: RFR: 8305112: RISC-V: Typo fix for RVC description
Message-ID: <Ay1jx_4Hr3JTJ99C2rcVgOajy2QkV5L9fG_DSRkmA74=.a82236f9-5624-4ec5-84c7-6a2bcb5395bb@github.com>

Fix trivial typos in the RVC description that may cause confusion. Found in backporting process https://github.com/openjdk/riscv-port-jdk17u/pull/28.

Thanks,
Xiaolin

-------------

Commit messages:
 - Typo fix

Changes: https://git.openjdk.org/jdk/pull/13219/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13219&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305112
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13219.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13219/head:pull/13219

PR: https://git.openjdk.org/jdk/pull/13219

From dholmes at openjdk.org  Wed Mar 29 02:40:56 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 29 Mar 2023 02:40:56 GMT
Subject: RFR: JDK-8301496: Replace NULL with nullptr in cpu/riscv
In-Reply-To: <PNFHMzET147VzMQSySFk4koARUsEcb4lfNmh8JdScnk=.2dec4d00-90d6-4f5e-a89e-21d9aadb4d37@github.com>
References: <PNFHMzET147VzMQSySFk4koARUsEcb4lfNmh8JdScnk=.2dec4d00-90d6-4f5e-a89e-21d9aadb4d37@github.com>
Message-ID: <9daAIvq4DDVLuvsw9JjFK5Ap3KGkCkuoAEoYuVhbBto=.f8a06117-49e4-4a75-80aa-e07338388581@github.com>

On Tue, 31 Jan 2023 11:39:59 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory cpu/riscv. Unfortunately the script that does the change isn't perfect, and so we
> need to comb through these manually to make sure nothing has gone wrong. I also review these changes but things slip past my eyes sometimes.
> 
> Here are some typical things to look out for:
> 
> 1. No changes but copyright header changed (probably because I reverted some changes but forgot the copyright).
> 2. Macros having their NULL changed to nullptr, these are added to the script when I find them. They should be NULL.
> 3. nullptr in comments and logs. We try to use lower case "null" in these cases as it reads better. An exception is made when code expressions are in a comment.
> 
> An example of this:
> 
> ```c++
> // This function returns null
> void* ret_null();
> // This function returns true if *x == nullptr
> bool is_nullptr(void** x);
> 
> 
> Note how `nullptr` participates in a code expression here, we really are talking about the specific value `nullptr`.
> 
> Thanks!

LGTM!

One nit.

Thanks

src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 1836:

> 1834:     __ bne(t1, scratch_src_klass, L_failed);
> 1835: 
> 1836:     // if [src->is_Array() != null] then return -1

nullptr for code fragment

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12324#pullrequestreview-1362167012
PR Review Comment: https://git.openjdk.org/jdk/pull/12324#discussion_r1151332024

From lmesnik at openjdk.org  Wed Mar 29 02:43:40 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 29 Mar 2023 02:43:40 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v8]
In-Reply-To: <q2NaN5p_DlPfaATSFXFg7Rco87hpx5eH1lOh4j1WhqU=.844c4ce4-b850-4576-97d5-88cfd163aab6@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <uZLGDh5UIBW0AYrgh4ndTUtnqNfp2zGgnx2zQm-kBaI=.f3d7e776-0e81-4272-bc31-2cdee9dc9d23@github.com>
 <q2NaN5p_DlPfaATSFXFg7Rco87hpx5eH1lOh4j1WhqU=.844c4ce4-b850-4576-97d5-88cfd163aab6@github.com>
Message-ID: <CC55Zk0q1CPp8JaFing8PLNzVIiMzJimw-F-ONcWwwg=.ad2c08a7-b81c-4f81-9926-1f96b5665c51@github.com>

On Wed, 29 Mar 2023 01:16:55 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed trailing spaces in two files
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1547:
> 
>> 1545:       JvmtiThreadState* ct_state = java_lang_Thread::jvmti_thread_state(jt->threadObj());
>> 1546:       JvmtiThreadState* vt_state = vt_oop != nullptr ? java_lang_Thread::jvmti_thread_state(vt_oop) : nullptr;
>> 1547:       bool virt = vt_oop != nullptr && vt_oop != ct_oop;
> 
> You can move it inside if() in line 1554

Doesn't it makes a sense to use 
    bool virt = vt_oop != nullptr && java_lang_VirtualThread::is_instance(vt_oop);
it is used in a lot of places and looks more usual as vthread check. 
Might be later it would be possible to refactor this expression to some separate function.
Just a proposal, only if you agree with it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1151305059

From lmesnik at openjdk.org  Wed Mar 29 02:43:38 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 29 Mar 2023 02:43:38 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v8]
In-Reply-To: <uZLGDh5UIBW0AYrgh4ndTUtnqNfp2zGgnx2zQm-kBaI=.f3d7e776-0e81-4272-bc31-2cdee9dc9d23@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <uZLGDh5UIBW0AYrgh4ndTUtnqNfp2zGgnx2zQm-kBaI=.f3d7e776-0e81-4272-bc31-2cdee9dc9d23@github.com>
Message-ID: <q2NaN5p_DlPfaATSFXFg7Rco87hpx5eH1lOh4j1WhqU=.844c4ce4-b850-4576-97d5-88cfd163aab6@github.com>

On Tue, 28 Mar 2023 18:57:23 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The fix is to enable virtual threads support for late binding JVMTI agents.
>> The fix includes:
>> - New function `JvmtiEnvBase::enable_virtual_threads_notify_jvmti()` which does enabling JVMTI VTMS transition notifications in case of agent loaded into running VM. This function executes a VM operation counting VTMS transition bits in all `JavaThread`'s to correctly set the static counter `_VTMS_transition_count` needed for VTMS transition protocol.
>> - New function `JvmtiEnvBase::disable_virtual_threads_notify_jvmti()` which is needed for testing. It is used by the `WhiteBox` API.
>> - New WhiteBox function `WB_SetVirtualThreadsNotifyJvmtiMode(JNIEnv* env, jobject wb, jboolean enable)` needed for testing of this update.
>> - New regression test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
>> 
>> Testing:
>> - New test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
>> - The originally failed tests are expected to pass 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:
> 
>   fixed trailing spaces in two files

Changes requested by lmesnik (Reviewer).

src/hotspot/share/prims/jvmtiEnvBase.cpp line 1547:

> 1545:       JvmtiThreadState* ct_state = java_lang_Thread::jvmti_thread_state(jt->threadObj());
> 1546:       JvmtiThreadState* vt_state = vt_oop != nullptr ? java_lang_Thread::jvmti_thread_state(vt_oop) : nullptr;
> 1547:       bool virt = vt_oop != nullptr && vt_oop != ct_oop;

You can move it inside if() in line 1554

src/hotspot/share/prims/jvmtiEnvBase.cpp line 1554:

> 1552:       // Correct jt->jvmti_thread_state() and jt->jvmti_vthread() if necessary.
> 1553:       // It was not maintained while notifyJvmti was disabled.
> 1554:       if (jt_state != ct_state && jt_state != vt_state) {

Is it possible that jt_state == ct_state while the virtual thread is executed or vice versa? Just because jvmtt_state is outdated.
Shouldn't we always update (set to null) link/ jvmti_vthread if _enabled  == true?

test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/libToggleNotifyJvmtiTest.cpp line 46:

> 44:   RawMonitorLocker agent_locker(jvmti, jni, agent_lock);
> 45: 
> 46:   vthread_started_cnt++;

Wouldn't it be better to use std::atomic<int> instead RawMonitorLocker here to reduce sync time?

-------------

PR Review: https://git.openjdk.org/jdk/pull/13133#pullrequestreview-1362120493
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1151298663
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1151334153
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1151329179

From dholmes at openjdk.org  Wed Mar 29 02:46:30 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 29 Mar 2023 02:46:30 GMT
Subject: RFR: 8305112: RISC-V: Typo fix for RVC description
In-Reply-To: <Ay1jx_4Hr3JTJ99C2rcVgOajy2QkV5L9fG_DSRkmA74=.a82236f9-5624-4ec5-84c7-6a2bcb5395bb@github.com>
References: <Ay1jx_4Hr3JTJ99C2rcVgOajy2QkV5L9fG_DSRkmA74=.a82236f9-5624-4ec5-84c7-6a2bcb5395bb@github.com>
Message-ID: <OG1kDjm9CE9a6tvQyMaNkP7OklKVbCMHl2OP11oN7F8=.ac1f817e-10ec-4936-9108-13a09820499d@github.com>

On Wed, 29 Mar 2023 02:07:08 GMT, Xiaolin Zheng <xlinzheng at openjdk.org> wrote:

> Fix trivial typos in the RVC description that may cause confusion. Found in backporting process https://github.com/openjdk/riscv-port-jdk17u/pull/28.
> 
> Thanks,
> Xiaolin

Fine and trivial.

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13219#pullrequestreview-1362171921

From xlinzheng at openjdk.org  Wed Mar 29 02:50:29 2023
From: xlinzheng at openjdk.org (Xiaolin Zheng)
Date: Wed, 29 Mar 2023 02:50:29 GMT
Subject: RFR: 8305112: RISC-V: Typo fix for RVC description
In-Reply-To: <Ay1jx_4Hr3JTJ99C2rcVgOajy2QkV5L9fG_DSRkmA74=.a82236f9-5624-4ec5-84c7-6a2bcb5395bb@github.com>
References: <Ay1jx_4Hr3JTJ99C2rcVgOajy2QkV5L9fG_DSRkmA74=.a82236f9-5624-4ec5-84c7-6a2bcb5395bb@github.com>
Message-ID: <6g0Jabz-vHylnjd2wpGgPZcxTn8H1SSMEjCraBbYnLg=.f8c95e92-30fd-4c4d-a2a0-5f7e384cd3aa@github.com>

On Wed, 29 Mar 2023 02:07:08 GMT, Xiaolin Zheng <xlinzheng at openjdk.org> wrote:

> Fix trivial typos in the RVC description that may cause confusion. Found in backporting process https://github.com/openjdk/riscv-port-jdk17u/pull/28.
> 
> Thanks,
> Xiaolin

Thank you for the quick review, David!

An /integrate so it won't be blocked by myself.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13219#issuecomment-1487871437

From xlinzheng at openjdk.org  Wed Mar 29 02:57:41 2023
From: xlinzheng at openjdk.org (Xiaolin Zheng)
Date: Wed, 29 Mar 2023 02:57:41 GMT
Subject: Integrated: 8305112: RISC-V: Typo fix for RVC description
In-Reply-To: <Ay1jx_4Hr3JTJ99C2rcVgOajy2QkV5L9fG_DSRkmA74=.a82236f9-5624-4ec5-84c7-6a2bcb5395bb@github.com>
References: <Ay1jx_4Hr3JTJ99C2rcVgOajy2QkV5L9fG_DSRkmA74=.a82236f9-5624-4ec5-84c7-6a2bcb5395bb@github.com>
Message-ID: <cT4DnLWQ2VMqaX0wpopQhVVbmU_NX1YDWm_5LY9cH-Q=.2a954715-d7da-452d-8f93-57ad42d3ac24@github.com>

On Wed, 29 Mar 2023 02:07:08 GMT, Xiaolin Zheng <xlinzheng at openjdk.org> wrote:

> Fix trivial typos in the RVC description that may cause confusion. Found in backporting process https://github.com/openjdk/riscv-port-jdk17u/pull/28.
> 
> Thanks,
> Xiaolin

This pull request has now been integrated.

Changeset: 96fa2751
Author:    Xiaolin Zheng <xlinzheng at openjdk.org>
Committer: David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/96fa2751e8bbc05d6d064d80c07720cc9db05c54
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8305112: RISC-V: Typo fix for RVC description

Reviewed-by: dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/13219

From kbarrett at openjdk.org  Wed Mar 29 03:07:21 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 29 Mar 2023 03:07:21 GMT
Subject: RFR: 8304759: Add BitMap iterators [v2]
In-Reply-To: <4FHjg8u1ix7KodqaJkU5q-tnYRDAq3GhRV0z7ArpYGU=.7434363a-1bcb-467f-9225-0e97d4ade998@github.com>
References: <4FHjg8u1ix7KodqaJkU5q-tnYRDAq3GhRV0z7ArpYGU=.7434363a-1bcb-467f-9225-0e97d4ade998@github.com>
Message-ID: <UkXNPij1QwEq03FKIpzZd0ccz70L0mxYcQa18IzOVz4=.75123a32-63b4-4a31-80ad-f354edab3174@github.com>

> Please review this change which adds iteration over the set bit positions of a
> BitMap via an iterator object.  This is in addition to the existing iterate()
> and reverse_iterate() functions that apply a function to the set bit positions.
> 
> There are two iterator classes: BitMap::Iterator and BitMap::ReverseIterator.
> Iteration uses a single, self-contained iterator object, rather than a pair of
> iterator objects as is done with standard library iterators.  This is because
> the desired form of iteration over bitmaps doesn't lend itself well to the
> begin/end pair style.  Typical usage is something like
> 
> 
> for (BitMap::Iterator it{map, beg, end}; !it.is_empty(); it.step()) {
>   ... use it.index()
> }
> 
> 
> However, as a syntactic convenience, these iterator classes provide begin()
> and end() member functions returning objects supporting the requirements for
> range-based for loops.  By constraining these objects to this usage we can
> cope with the "iterator pair" requirements.  Usage is something like
> 
> 
> for (BitMap::idx_t index : BitMap::Iterator{map, beg, end}) {
>   ...
> }
> 
> 
> Testing:
> mach5 tier1, which includes running the updated gtests on all Oracle-supported
> platforms.

Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:

  better names for step functions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13184/files
  - new: https://git.openjdk.org/jdk/pull/13184/files/fb4e4020..379dfa82

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13184&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13184&range=00-01

  Stats: 8 lines in 2 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/13184.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13184/head:pull/13184

PR: https://git.openjdk.org/jdk/pull/13184

From sspitsyn at openjdk.org  Wed Mar 29 05:03:47 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 29 Mar 2023 05:03:47 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v8]
In-Reply-To: <CC55Zk0q1CPp8JaFing8PLNzVIiMzJimw-F-ONcWwwg=.ad2c08a7-b81c-4f81-9926-1f96b5665c51@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <uZLGDh5UIBW0AYrgh4ndTUtnqNfp2zGgnx2zQm-kBaI=.f3d7e776-0e81-4272-bc31-2cdee9dc9d23@github.com>
 <q2NaN5p_DlPfaATSFXFg7Rco87hpx5eH1lOh4j1WhqU=.844c4ce4-b850-4576-97d5-88cfd163aab6@github.com>
 <CC55Zk0q1CPp8JaFing8PLNzVIiMzJimw-F-ONcWwwg=.ad2c08a7-b81c-4f81-9926-1f96b5665c51@github.com>
Message-ID: <2ExJNB5LA7wGZA1HMaMSYrPwWQbLvGvVlxO7kRWRH5E=.ae9b1826-1527-4533-879f-fc12f796d775@github.com>

On Wed, 29 Mar 2023 01:32:41 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1547:
>> 
>>> 1545:       JvmtiThreadState* ct_state = java_lang_Thread::jvmti_thread_state(jt->threadObj());
>>> 1546:       JvmtiThreadState* vt_state = vt_oop != nullptr ? java_lang_Thread::jvmti_thread_state(vt_oop) : nullptr;
>>> 1547:       bool virt = vt_oop != nullptr && vt_oop != ct_oop;
>> 
>> You can move it inside if() in line 1554
>
> Doesn't it makes a sense to use 
>     bool virt = vt_oop != nullptr && java_lang_VirtualThread::is_instance(vt_oop);
> it is used in a lot of places and looks more usual as vthread check. 
> Might be later it would be possible to refactor this expression to some separate function.
> Just a proposal, only if you agree with it.

> You can move it inside if() in line 1554
> Doesn't it makes a sense to use
> bool virt = vt_oop != nullptr && java_lang_VirtualThread::is_instance(vt_oop);

The local `virt` is also used at line 1555.
Second suggestion is good, thanks. I had to use it in the first place.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1151395915

From sspitsyn at openjdk.org  Wed Mar 29 05:30:38 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 29 Mar 2023 05:30:38 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v8]
In-Reply-To: <q2NaN5p_DlPfaATSFXFg7Rco87hpx5eH1lOh4j1WhqU=.844c4ce4-b850-4576-97d5-88cfd163aab6@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <uZLGDh5UIBW0AYrgh4ndTUtnqNfp2zGgnx2zQm-kBaI=.f3d7e776-0e81-4272-bc31-2cdee9dc9d23@github.com>
 <q2NaN5p_DlPfaATSFXFg7Rco87hpx5eH1lOh4j1WhqU=.844c4ce4-b850-4576-97d5-88cfd163aab6@github.com>
Message-ID: <mwpz40n5KrvG0NWV_E-YUCZm2h-EQpg4FmCf4K1M20g=.01102f5f-1b86-43a1-ab64-b69b0b408a22@github.com>

On Wed, 29 Mar 2023 02:29:16 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed trailing spaces in two files
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/libToggleNotifyJvmtiTest.cpp line 46:
> 
>> 44:   RawMonitorLocker agent_locker(jvmti, jni, agent_lock);
>> 45: 
>> 46:   vthread_started_cnt++;
> 
> Wouldn't it be better to use std::atomic<int> instead RawMonitorLocker here to reduce sync time?

This RawMonitorLocker is not on a critical path.
It can be useful to sync print statements when tracing is needed.
I feel that in order to get a full advantage of it we need to do this for many tests in our test base.
I can convert it to std::atomic if you think it is important.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1151409885

From rrich at openjdk.org  Wed Mar 29 07:27:26 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 29 Mar 2023 07:27:26 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v14]
In-Reply-To: <7ntbBinhQ6xnrVi4hIs05Lqq9UVDL3Q1nKku2iaP5CA=.a9de7b8a-35cd-40f3-af3e-b3e31138d192@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <Fh6g8Qtdd0VS96WT8xUIrc4iiPfFICaFR5GG0IYpP8s=.fd3eca92-b604-4d3c-b31e-a731880e4efb@github.com>
 <NdMVbNsezXjW7duSt3Apc6RbNcAFbLOB72TS-bxBlRI=.ae01bc30-a98e-4866-8f9a-d6a78e0b8a64@github.com>
 <7ntbBinhQ6xnrVi4hIs05Lqq9UVDL3Q1nKku2iaP5CA=.a9de7b8a-35cd-40f3-af3e-b3e31138d192@github.com>
Message-ID: <ECKUZ_HbqdCIbcpxX7afoVlM_LW52ocm8wtlo68D554=.dbe6c40f-a6df-41a5-8e32-acf73f73ad24@github.com>

On Tue, 28 Mar 2023 16:33:09 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp line 652:
>> 
>>> 650:     // Scale the index to be the entry index * sizeof(ResolvedInvokeDynamicInfo)
>>> 651:     __ sldi(size, size, log2i_exact(sizeof(ResolvedIndyEntry)));
>>> 652:     __ add(cache, cache, size);
>> 
>> @reinrich Is there any specific reason, why you're not calling load_resolved_indy_entry() method here.  On s390x build/changes are stable even with calling that helper method.
>
> It should work if we move the addition of `Array<ResolvedIndyEntry>::base_offset_in_bytes()` into the other caller.

> @reinrich Is there any specific reason, why you're not calling load_resolved_indy_entry() method here. On s390x build/changes are stable even with calling that helper method.

Looks like this was changed on x86_64 after I ported it to ppc. Thanks for making me aware of it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12778#discussion_r1151498444

From alanb at openjdk.org  Wed Mar 29 07:37:09 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 29 Mar 2023 07:37:09 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v3]
In-Reply-To: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
Message-ID: <pIVMeVZiMytT2f1NfXL9NKW3pXvZdfj7LPM7eHiL5jM=.4a3cd572-3bc1-4fe5-9d89-29ff5194f2ee@github.com>

> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview.
> 
> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently.
> 
> In addition, there are a small number of implementation changes to sync up from the loom fibers branch:
> 
> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where  end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly.
> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes.
> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs.
> - New system property to print a stack trace when a virtual thread sets its own value of a TL.
> - ThreadPerTaskExecutor is changed to use FutureTask.
> 
> Testing: tier1-6.

Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:

  Test updates

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13203/files
  - new: https://git.openjdk.org/jdk/pull/13203/files/7906dbb4..8170e463

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13203&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13203&range=01-02

  Stats: 67 lines in 3 files changed: 0 ins; 64 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13203.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13203/head:pull/13203

PR: https://git.openjdk.org/jdk/pull/13203

From alanb at openjdk.org  Wed Mar 29 07:37:14 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 29 Mar 2023 07:37:14 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v2]
In-Reply-To: <lOtzWvlXE-b0tsrlbd7w7ENFWgjTy24npIDyfXVL9L4=.11c20ac5-7897-4576-bbcd-ed5544782d86@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <9RJ4unb3FjazYLi0BbWs1NGN9h50Z1fvAz1ZNds5mO4=.cb02f148-66bd-4429-9c30-ea4a6dcbe4d7@github.com>
 <lOtzWvlXE-b0tsrlbd7w7ENFWgjTy24npIDyfXVL9L4=.11c20ac5-7897-4576-bbcd-ed5544782d86@github.com>
Message-ID: <F9kf8_W8F6hUHV1TdZ-_MT21GnkLPkKfieTayAX1hHc=.b90696a5-6607-4d1c-9e12-235886da1808@github.com>

On Tue, 28 Mar 2023 19:57:12 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Alan Bateman 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:
>> 
>>  - ThreadSleepEvent refactoring
>>  - Merge
>>  - Merge
>>  - Initial sync from fibers branch
>
> src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 72:
> 
>> 70:         RECORD_PATTERNS,
>> 71:         // not used
>> 72:         VIRTUAL_THREADS,
> 
> Can the enum constant also be removed?

Unfortunately not due to the bootstrapping issues with the build. It was the same for sealed classes where the constant couldn't be removed until the end of the release.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1151497635

From alanb at openjdk.org  Wed Mar 29 07:37:21 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 29 Mar 2023 07:37:21 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v2]
In-Reply-To: <OPz26p0QvEh0Cw-SHvuEi3cslPvNXpqnA5GBs8TXjUo=.996b3218-9cb1-4773-b96c-259eeb99d521@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <9RJ4unb3FjazYLi0BbWs1NGN9h50Z1fvAz1ZNds5mO4=.cb02f148-66bd-4429-9c30-ea4a6dcbe4d7@github.com>
 <OPz26p0QvEh0Cw-SHvuEi3cslPvNXpqnA5GBs8TXjUo=.996b3218-9cb1-4773-b96c-259eeb99d521@github.com>
Message-ID: <D0vaoMIzK-5zkAWoZsuMO0PfbZMUyx-B5Gt15PjH98A=.143da029-3477-4031-bf41-d3a67888b276@github.com>

On Tue, 28 Mar 2023 21:36:04 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Alan Bateman 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:
>> 
>>  - ThreadSleepEvent refactoring
>>  - Merge
>>  - Merge
>>  - Initial sync from fibers branch
>
> test/hotspot/jtreg/runtime/vthread/JNIMonitor/JNIMonitor.java line 31:
> 
>> 29:  * @summary Tests that JNI monitors work correctly with virtual threads
>> 30:  * @library /test/lib
>> 31:  * @compile JNIMonitor.java
> 
> I think that test file is compiled implicitly. So this line could be just removed. 
> The same is for all other similar tests.

Most of the test changes were just a few sed commands remove lines with `@enablePreview`, remove  `--enable-preview -source ${jdk.version}` from `@compile` tags. We can remove the `@compile` tags that don't specify any other options as they aren't needed now, up to you.

> test/jdk/com/sun/management/ThreadMXBean/VirtualThreads.java line 143:
> 
>> 141:             long[] tids = new long[] { tid0, tid1 };
>> 142:             long[] cpuTimes = bean.getThreadCpuTime(tids);
>> 143:             if (Thread.currentThread().isVirtual()) {
> 
> How it worked before?

tid0 is the thread ID of a platform therad. tid1 is the threadID of a virtual thread. The only change here is allow this test run with the main wrapper plugin ([CODETOOLS-7903373](https://bugs.openjdk.org/browse/CODETOOLS-7903373)), it would otherwise have to be excluded for those runs.

> test/jdk/java/lang/Thread/virtual/GetStackTrace.java line 30:
> 
>> 28:  * @requires vm.continuations
>> 29:  * @modules java.base/java.lang:+open
>> 30:  * @run testng/othervm -XX:+UnlockDiagnosticVMOptions -XX:+ShowHiddenFrames GetStackTrace
> 
> shouldn't be main/othervm ?

You're right, this came over from the loom repo and I didn't know that it wasn't running (no @Test).  I think it would be better to run this test without ShowHiddenFrames, it's just need to known the expected bottom most frame.

> test/jdk/java/lang/Thread/virtual/VirtualThreadPinnedEventThrows.java line 29:
> 
>> 27:  * @modules java.base/jdk.internal.event
>> 28:  * @compile/module=java.base jdk/internal/event/VirtualThreadPinnedEvent.java
>> 29:  * @run junit VirtualThreadPinnedEventThrows
> 
> Shouldn't be 'junit/othervm' used here to ensure that updated VirtualThreadPinnedEvent is used? I don't know these details of jtreg.

This is using the jtreg support for patching system modules. jtreg runs the test in a new VM with --patch-module.

> test/jdk/jdk/incubator/concurrent/StructuredTaskScope/PreviewFeaturesNotEnabled.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved.
> 
> Not sure I understand what happens. The file is 
> test/jdk/jdk/incubator/concurrent/StructuredTaskScope/PreviewFeaturesNotEnabled.java
> while it contains is public class VirtualThreadPinnedEvent. Copied by mistake?

Thank, I'm not sure what happened there as this test is deleted.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1151507288
PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1151502964
PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1151500272
PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1151495733
PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1151496227

From aturbanov at openjdk.org  Wed Mar 29 07:37:21 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 29 Mar 2023 07:37:21 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v3]
In-Reply-To: <pIVMeVZiMytT2f1NfXL9NKW3pXvZdfj7LPM7eHiL5jM=.4a3cd572-3bc1-4fe5-9d89-29ff5194f2ee@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <pIVMeVZiMytT2f1NfXL9NKW3pXvZdfj7LPM7eHiL5jM=.4a3cd572-3bc1-4fe5-9d89-29ff5194f2ee@github.com>
Message-ID: <Feg0RlEZ9xx89K661yEan5jUmaqGaaDD9SVziQtrZF8=.0151b269-6109-4828-9eac-c992744f8f2d@github.com>

On Wed, 29 Mar 2023 07:31:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview.
>> 
>> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently.
>> 
>> In addition, there are a small number of implementation changes to sync up from the loom fibers branch:
>> 
>> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where  end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly.
>> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes.
>> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs.
>> - New system property to print a stack trace when a virtual thread sets its own value of a TL.
>> - ThreadPerTaskExecutor is changed to use FutureTask.
>> 
>> Testing: tier1-6.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test updates

test/hotspot/jtreg/serviceability/jvmti/vthread/premain/AgentWithVThreadTest.java line 40:

> 38:     public static void main(String[] args) throws Exception  {
> 39: 
> 40:         ProcessBuilder pb = ProcessTools.createTestJvm("-javaagent:agent.jar",  "-version");

Suggestion:

        ProcessBuilder pb = ProcessTools.createTestJvm("-javaagent:agent.jar", "-version");

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1151504517

From alanb at openjdk.org  Wed Mar 29 08:00:36 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 29 Mar 2023 08:00:36 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v4]
In-Reply-To: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
Message-ID: <GOOPg0-P0Vc1ocNUzWRIbItENekN1ralramscyuF1kQ=.44aded10-e14f-4378-9173-a8126d21da04@github.com>

> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview.
> 
> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently.
> 
> In addition, there are a small number of implementation changes to sync up from the loom fibers branch:
> 
> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where  end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly.
> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes.
> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs.
> - New system property to print a stack trace when a virtual thread sets its own value of a TL.
> - ThreadPerTaskExecutor is changed to use FutureTask.
> 
> Testing: tier1-6.

Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:

  Fix ThreadSleepEvent again

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13203/files
  - new: https://git.openjdk.org/jdk/pull/13203/files/8170e463..bfd2c816

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13203&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13203&range=02-03

  Stats: 8 lines in 1 file changed: 4 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13203.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13203/head:pull/13203

PR: https://git.openjdk.org/jdk/pull/13203

From alanb at openjdk.org  Wed Mar 29 08:05:59 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 29 Mar 2023 08:05:59 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v3]
In-Reply-To: <Feg0RlEZ9xx89K661yEan5jUmaqGaaDD9SVziQtrZF8=.0151b269-6109-4828-9eac-c992744f8f2d@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <pIVMeVZiMytT2f1NfXL9NKW3pXvZdfj7LPM7eHiL5jM=.4a3cd572-3bc1-4fe5-9d89-29ff5194f2ee@github.com>
 <Feg0RlEZ9xx89K661yEan5jUmaqGaaDD9SVziQtrZF8=.0151b269-6109-4828-9eac-c992744f8f2d@github.com>
Message-ID: <qNzSuPLwq_HbAyYf-O0NRYdWypgiUX9-gOwb6AzKQ6w=.b48a055f-9502-4dae-ab50-4d0c2e370032@github.com>

On Wed, 29 Mar 2023 07:29:06 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test updates
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/premain/AgentWithVThreadTest.java line 40:
> 
>> 38:     public static void main(String[] args) throws Exception  {
>> 39: 
>> 40:         ProcessBuilder pb = ProcessTools.createTestJvm("-javaagent:agent.jar",  "-version");
> 
> Suggestion:
> 
>         ProcessBuilder pb = ProcessTools.createTestJvm("-javaagent:agent.jar", "-version");

This is noise in the original test, the only change here is to drop the "--enable-preview" from the command.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1151542296

From pminborg at openjdk.org  Wed Mar 29 08:21:00 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 29 Mar 2023 08:21:00 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v13]
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <AimZBwprTTvzCtc5pZtCqEQluMT2X_C7X2Guf5dPsr8=.77d1c738-f62e-4f8d-930e-5c9bbce65d2b@github.com>

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Remove unused method and declare class final

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/24bea62e..54e49e0a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=11-12

  Stats: 11 lines in 1 file changed: 0 ins; 10 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13079/head:pull/13079

PR: https://git.openjdk.org/jdk/pull/13079

From pminborg at openjdk.org  Wed Mar 29 08:25:17 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 29 Mar 2023 08:25:17 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v14]
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <E3Su9nxPX8s8vIaqXwbcelol_otP2X5LhOgHbTJrLA8=.2ad7bc0f-0c30-443e-bb4e-e7ab7f7bc4a6@github.com>

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

Per Minborg has updated the pull request incrementally with two additional commits since the last revision:

 - Merge pull request #1 from JornVernee/Fix_ULE
   
   Fix ULE when intializing LibFallback
 - fix ULE when intializing LibFallback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/54e49e0a..846eaf30

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=12-13

  Stats: 48 lines in 4 files changed: 20 ins; 1 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/13079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13079/head:pull/13079

PR: https://git.openjdk.org/jdk/pull/13079

From pminborg at openjdk.org  Wed Mar 29 08:55:08 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 29 Mar 2023 08:55:08 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v15]
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <cVBIvlWcR-LFVl1oioaOFR-Xo2ZZnweP6uby_hxPYGU=.a61a7f36-9ebc-4051-9ca2-6f3bb5cd908c@github.com>

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Cleanup finality

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/846eaf30..c787a282

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=13-14

  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13079/head:pull/13079

PR: https://git.openjdk.org/jdk/pull/13079

From stefank at openjdk.org  Wed Mar 29 09:02:35 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 29 Mar 2023 09:02:35 GMT
Subject: RFR: 8304759: Add BitMap iterators [v2]
In-Reply-To: <UkXNPij1QwEq03FKIpzZd0ccz70L0mxYcQa18IzOVz4=.75123a32-63b4-4a31-80ad-f354edab3174@github.com>
References: <4FHjg8u1ix7KodqaJkU5q-tnYRDAq3GhRV0z7ArpYGU=.7434363a-1bcb-467f-9225-0e97d4ade998@github.com>
 <UkXNPij1QwEq03FKIpzZd0ccz70L0mxYcQa18IzOVz4=.75123a32-63b4-4a31-80ad-f354edab3174@github.com>
Message-ID: <GKBiI882ESQnub05D-tU3JK1_jau9HauRrMqsoa_Pjo=.b8fa2435-5373-44b9-9b88-eca10b008df3@github.com>

On Wed, 29 Mar 2023 03:07:21 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change which adds iteration over the set bit positions of a
>> BitMap via an iterator object.  This is in addition to the existing iterate()
>> and reverse_iterate() functions that apply a function to the set bit positions.
>> 
>> There are two iterator classes: BitMap::Iterator and BitMap::ReverseIterator.
>> Iteration uses a single, self-contained iterator object, rather than a pair of
>> iterator objects as is done with standard library iterators.  This is because
>> the desired form of iteration over bitmaps doesn't lend itself well to the
>> begin/end pair style.  Typical usage is something like
>> 
>> 
>> for (BitMap::Iterator it{map, beg, end}; !it.is_empty(); it.step()) {
>>   ... use it.index()
>> }
>> 
>> 
>> However, as a syntactic convenience, these iterator classes provide begin()
>> and end() member functions returning objects supporting the requirements for
>> range-based for loops.  By constraining these objects to this usage we can
>> cope with the "iterator pair" requirements.  Usage is something like
>> 
>> 
>> for (BitMap::idx_t index : BitMap::Iterator{map, beg, end}) {
>>   ...
>> }
>> 
>> 
>> Testing:
>> mach5 tier1, which includes running the updated gtests on all Oracle-supported
>> platforms.
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   better names for step functions

Marked as reviewed by stefank (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13184#pullrequestreview-1362581227

From aboldtch at openjdk.org  Wed Mar 29 09:26:13 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 29 Mar 2023 09:26:13 GMT
Subject: RFR: 8304759: Add BitMap iterators [v2]
In-Reply-To: <UkXNPij1QwEq03FKIpzZd0ccz70L0mxYcQa18IzOVz4=.75123a32-63b4-4a31-80ad-f354edab3174@github.com>
References: <4FHjg8u1ix7KodqaJkU5q-tnYRDAq3GhRV0z7ArpYGU=.7434363a-1bcb-467f-9225-0e97d4ade998@github.com>
 <UkXNPij1QwEq03FKIpzZd0ccz70L0mxYcQa18IzOVz4=.75123a32-63b4-4a31-80ad-f354edab3174@github.com>
Message-ID: <UXwh8z6fiLhub9aVtI7_PXADfbgy5LQlUVVVP_gmxLg=.b7865272-92df-4b74-88f1-cf50b6d8c4c3@github.com>

On Wed, 29 Mar 2023 03:07:21 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change which adds iteration over the set bit positions of a
>> BitMap via an iterator object.  This is in addition to the existing iterate()
>> and reverse_iterate() functions that apply a function to the set bit positions.
>> 
>> There are two iterator classes: BitMap::Iterator and BitMap::ReverseIterator.
>> Iteration uses a single, self-contained iterator object, rather than a pair of
>> iterator objects as is done with standard library iterators.  This is because
>> the desired form of iteration over bitmaps doesn't lend itself well to the
>> begin/end pair style.  Typical usage is something like
>> 
>> 
>> for (BitMap::Iterator it{map, beg, end}; !it.is_empty(); it.step()) {
>>   ... use it.index()
>> }
>> 
>> 
>> However, as a syntactic convenience, these iterator classes provide begin()
>> and end() member functions returning objects supporting the requirements for
>> range-based for loops.  By constraining these objects to this usage we can
>> cope with the "iterator pair" requirements.  Usage is something like
>> 
>> 
>> for (BitMap::idx_t index : BitMap::Iterator{map, beg, end}) {
>>   ...
>> }
>> 
>> 
>> Testing:
>> mach5 tier1, which includes running the updated gtests on all Oracle-supported
>> platforms.
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   better names for step functions

lgtm. 

Just a comment about the comments for `first()`/`last()`

src/hotspot/share/utilities/bitMap.hpp line 420:

> 418:   // Returns the index of the last set bit in the remaining iteration range.
> 419:   // precondition: !is_empty()
> 420:   idx_t last() const;

The comments for `first()` and `last()` are a little misleading. The invariant that the `first()`/`last()` is a set bit is only true for `first()` in the forward iterator and for `last()` in the reverse iterator. 

It seems more like a contract that if you use `first()` then you must have created `IteratorImpl(const BitMap* map, idx_t beg, idx_t end)` with `beg` being a set bit. And if you use `last()` then you must have created it with `end` being a set bit.

-------------

Marked as reviewed by aboldtch (Committer).

PR Review: https://git.openjdk.org/jdk/pull/13184#pullrequestreview-1362629245
PR Review Comment: https://git.openjdk.org/jdk/pull/13184#discussion_r1151641853

From aboldtch at openjdk.org  Wed Mar 29 09:34:22 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 29 Mar 2023 09:34:22 GMT
Subject: RFR: 8304759: Add BitMap iterators [v2]
In-Reply-To: <UXwh8z6fiLhub9aVtI7_PXADfbgy5LQlUVVVP_gmxLg=.b7865272-92df-4b74-88f1-cf50b6d8c4c3@github.com>
References: <4FHjg8u1ix7KodqaJkU5q-tnYRDAq3GhRV0z7ArpYGU=.7434363a-1bcb-467f-9225-0e97d4ade998@github.com>
 <UkXNPij1QwEq03FKIpzZd0ccz70L0mxYcQa18IzOVz4=.75123a32-63b4-4a31-80ad-f354edab3174@github.com>
 <UXwh8z6fiLhub9aVtI7_PXADfbgy5LQlUVVVP_gmxLg=.b7865272-92df-4b74-88f1-cf50b6d8c4c3@github.com>
Message-ID: <s5BdZLlhOcqtjLXhgfacnqoYFun36p1xWuZoGI8_pSw=.dbb16524-1203-43f6-9213-f801d8359ab9@github.com>

On Wed, 29 Mar 2023 09:22:33 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   better names for step functions
>
> src/hotspot/share/utilities/bitMap.hpp line 420:
> 
>> 418:   // Returns the index of the last set bit in the remaining iteration range.
>> 419:   // precondition: !is_empty()
>> 420:   idx_t last() const;
> 
> The comments for `first()` and `last()` are a little misleading. The invariant that the `first()`/`last()` is a set bit is only true for `first()` in the forward iterator and for `last()` in the reverse iterator. 
> 
> It seems more like a contract that if you use `first()` then you must have created `IteratorImpl(const BitMap* map, idx_t beg, idx_t end)` with `beg` being a set bit. And if you use `last()` then you must have created it with `end` being a set bit.

Or `beg == end`, that is an `is_empty()` Iterator

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13184#discussion_r1151653215

From sspitsyn at openjdk.org  Wed Mar 29 10:21:39 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 29 Mar 2023 10:21:39 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v8]
In-Reply-To: <q2NaN5p_DlPfaATSFXFg7Rco87hpx5eH1lOh4j1WhqU=.844c4ce4-b850-4576-97d5-88cfd163aab6@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <uZLGDh5UIBW0AYrgh4ndTUtnqNfp2zGgnx2zQm-kBaI=.f3d7e776-0e81-4272-bc31-2cdee9dc9d23@github.com>
 <q2NaN5p_DlPfaATSFXFg7Rco87hpx5eH1lOh4j1WhqU=.844c4ce4-b850-4576-97d5-88cfd163aab6@github.com>
Message-ID: <z8EAkfLzRQUB-cfi_dKR9O5VSXXjn01eOrG-GdPB0No=.f187c0f7-93c8-400e-a1d8-8af1cc27f159@github.com>

On Wed, 29 Mar 2023 02:40:09 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed trailing spaces in two files
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1554:
> 
>> 1552:       // Correct jt->jvmti_thread_state() and jt->jvmti_vthread() if necessary.
>> 1553:       // It was not maintained while notifyJvmti was disabled.
>> 1554:       if (jt_state != ct_state && jt_state != vt_state) {
> 
> Is it possible that jt_state == ct_state while the virtual thread is executed or vice versa? Just because jvmtt_state is outdated.
> Shouldn't we always update (set to null) link/ jvmti_vthread if _enabled  == true?

A1: Not sure, I understand your first question correctly. What does mean "vice versa" in this context?
When `notifyJvmti` events is disabled then a call to `rebind_to_jvmti_thread_state_of` is omitted in VTMS transitions. So, we need to correct it if necessary. It can be `jt_state == ct_state` while the virtual thread is executed in a mount/unmount transition. I keep thinking on how to make this fixup more precise.

A better approach would be something like this:

      if (virt) {
        if (jt_state != vt_state) {
          jt->set_jvmti_thread_state(vt_state); // restore jt->jvmti_thread_state()
          jt->set_jvmti_vthread(vt_oop);        // restore jt->jvmti_vthread()
          if (vt_state != nullptr) {
            vt_state->set_thread(jt);           // restore JavaThread link
          }
        }
      } else { // !virt
        if (jt_state != ct_state) {
          jt->set_jvmti_thread_state(ct_state); // restore jt->jvmti_thread_state()
          jt->set_jvmti_vthread(nullptr);       // reset jt->jvmti_vthread()
        }
      }

But it does not work correctly now. Some adjustment is needed to make it working.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1151712229

From mdoerr at openjdk.org  Wed Mar 29 10:36:50 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 29 Mar 2023 10:36:50 GMT
Subject: RFR: 8303210: [linux,
 Windows] Make UseSystemMemoryBarrier available as product flag [v6]
In-Reply-To: <9eZo1xYNGhjMSC9lDXKtkO1eyU_H-Veuh1AeP3CPKbg=.69b6c4ff-a3ef-439f-8468-21fec9de1825@github.com>
References: <9eZo1xYNGhjMSC9lDXKtkO1eyU_H-Veuh1AeP3CPKbg=.69b6c4ff-a3ef-439f-8468-21fec9de1825@github.com>
Message-ID: <4W40qd3bqnubOEUZZcDvuCtjsWn9VJeZnnS4eSxUm8s=.e408ce7b-8b02-4a97-b3c8-15836ce0e873@github.com>

> I'd like to enable UseSystemMemoryBarrier by default on supported Operating Systems in order to improve performance of thread state transitions (I/O, JNI, foreign function calls, JIT compiler threads, etc.). See JBS issue for more details.
> Unfortunately, the feature was not yet implemented on all platforms. I added the code, but need the platform maintainers to check if it can be used reliably (and ideally if the performance improves). It's easy to switch it off again in case of problems.
> 
> Update: Startup performance and some benchmarks on some platforms are impacted (see below). So, this PR no longer switches it on by default.

Martin Doerr has updated the pull request incrementally with two additional commits since the last revision:

 - Remove unintended newline from os_aix.cpp.
 - Remove leftover from os_aix.cpp.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12753/files
  - new: https://git.openjdk.org/jdk/pull/12753/files/5fc7dbd6..adcc0cd6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12753&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12753&range=04-05

  Stats: 9 lines in 1 file changed: 0 ins; 9 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12753/head:pull/12753

PR: https://git.openjdk.org/jdk/pull/12753

From mdoerr at openjdk.org  Wed Mar 29 10:36:56 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 29 Mar 2023 10:36:56 GMT
Subject: RFR: 8303210: [linux,
 Windows] Make UseSystemMemoryBarrier available as product flag [v5]
In-Reply-To: <NN0F3COXkgmmz3U9A29FNw6yDRGeZNNZctR0719VHsY=.5fad2479-bf04-425c-b471-0f1c462d112e@github.com>
References: <9eZo1xYNGhjMSC9lDXKtkO1eyU_H-Veuh1AeP3CPKbg=.69b6c4ff-a3ef-439f-8468-21fec9de1825@github.com>
 <w8QBaQtAtWepK1PRVY8uw8PO53iDnmtRt0P7o9jfDX8=.aa8c2e09-e9d6-4bff-8347-0033f0866774@github.com>
 <NN0F3COXkgmmz3U9A29FNw6yDRGeZNNZctR0719VHsY=.5fad2479-bf04-425c-b471-0f1c462d112e@github.com>
Message-ID: <EAoEclpM_K_dojawFhzYJKaRsDD1W1_JMPc2h45o8wc=.1909c4c5-460c-43f5-8a52-21c321f64797@github.com>

On Wed, 29 Mar 2023 00:01:33 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move flag configuration and initialization to os::init_2.
>
> src/hotspot/os/aix/os_aix.cpp line 2348:
> 
>> 2346:     }
>> 2347:     FLAG_SET_ERGO(UseSystemMemoryBarrier, false);
>> 2348:   }
> 
> This looks like a leftover ?? It shouldn't be here.

Thanks! The one is os::init was the leftover. The flags are initialized in `init_2`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12753#discussion_r1151727624

From mdoerr at openjdk.org  Wed Mar 29 10:42:18 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 29 Mar 2023 10:42:18 GMT
Subject: RFR: 8303210: [linux,
 Windows] Make UseSystemMemoryBarrier available as product flag [v5]
In-Reply-To: <cDZamfA5RSTBWdVrRKhnGabnb20lX8aojWSSaWVOqSo=.1a85d616-f028-4af8-9bde-43a06ffd138d@github.com>
References: <9eZo1xYNGhjMSC9lDXKtkO1eyU_H-Veuh1AeP3CPKbg=.69b6c4ff-a3ef-439f-8468-21fec9de1825@github.com>
 <w8QBaQtAtWepK1PRVY8uw8PO53iDnmtRt0P7o9jfDX8=.aa8c2e09-e9d6-4bff-8347-0033f0866774@github.com>
 <NN0F3COXkgmmz3U9A29FNw6yDRGeZNNZctR0719VHsY=.5fad2479-bf04-425c-b471-0f1c462d112e@github.com>
 <cDZamfA5RSTBWdVrRKhnGabnb20lX8aojWSSaWVOqSo=.1a85d616-f028-4af8-9bde-43a06ffd138d@github.com>
Message-ID: <yBnhjlTl5qD-DtWx7BQqoiuyFKDLPo2hOiGqEeDmG30=.b6839b0f-2a77-4a32-8558-be467ee72639@github.com>

On Wed, 29 Mar 2023 00:03:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/os/aix/os_aix.cpp line 2228:
>> 
>>> 2226:   if (UseSystemMemoryBarrier) {
>>> 2227:     if (!SystemMemoryBarrier::initialize()) {
>>> 2228:       if (!FLAG_IS_DEFAULT(UseSystemMemoryBarrier)) {
>> 
>> Have we processed this flag by this stage?
>
> This really should be done once in shared code, as well - somewhere in arguments.cpp

This is the leftover. See below.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12753#discussion_r1151737392

From mdoerr at openjdk.org  Wed Mar 29 10:46:12 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 29 Mar 2023 10:46:12 GMT
Subject: RFR: 8303210: [linux,
 Windows] Make UseSystemMemoryBarrier available as product flag [v6]
In-Reply-To: <4W40qd3bqnubOEUZZcDvuCtjsWn9VJeZnnS4eSxUm8s=.e408ce7b-8b02-4a97-b3c8-15836ce0e873@github.com>
References: <9eZo1xYNGhjMSC9lDXKtkO1eyU_H-Veuh1AeP3CPKbg=.69b6c4ff-a3ef-439f-8468-21fec9de1825@github.com>
 <4W40qd3bqnubOEUZZcDvuCtjsWn9VJeZnnS4eSxUm8s=.e408ce7b-8b02-4a97-b3c8-15836ce0e873@github.com>
Message-ID: <MTAr9TvUTRzfRWs3WlU_zq6-4m5_RaagR1UT_rmLfBA=.a1b0252d-5051-4bdd-9cf1-a815e5d5cb89@github.com>

On Wed, 29 Mar 2023 10:36:50 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> I'd like to enable UseSystemMemoryBarrier by default on supported Operating Systems in order to improve performance of thread state transitions (I/O, JNI, foreign function calls, JIT compiler threads, etc.). See JBS issue for more details.
>> Unfortunately, the feature was not yet implemented on all platforms. I added the code, but need the platform maintainers to check if it can be used reliably (and ideally if the performance improves). It's easy to switch it off again in case of problems.
>> 
>> Update: Startup performance and some benchmarks on some platforms are impacted (see below). So, this PR no longer switches it on by default.
>
> Martin Doerr has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove unintended newline from os_aix.cpp.
>  - Remove leftover from os_aix.cpp.

@dholmes: Thanks for reviewing! I had moved the flag initialization to `os_init2()` because of your comment "Actually I think this code belongs in os::init() regardless.", but `os::init()` is too early. I actually agree with that somewhere in arguments.cpp would be nice, but I couldn't find a good place for it there.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12753#issuecomment-1488362131

From mdoerr at openjdk.org  Wed Mar 29 10:50:20 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 29 Mar 2023 10:50:20 GMT
Subject: RFR: 8303210: [linux,
 Windows] Make UseSystemMemoryBarrier available as product flag [v5]
In-Reply-To: <NN0F3COXkgmmz3U9A29FNw6yDRGeZNNZctR0719VHsY=.5fad2479-bf04-425c-b471-0f1c462d112e@github.com>
References: <9eZo1xYNGhjMSC9lDXKtkO1eyU_H-Veuh1AeP3CPKbg=.69b6c4ff-a3ef-439f-8468-21fec9de1825@github.com>
 <w8QBaQtAtWepK1PRVY8uw8PO53iDnmtRt0P7o9jfDX8=.aa8c2e09-e9d6-4bff-8347-0033f0866774@github.com>
 <NN0F3COXkgmmz3U9A29FNw6yDRGeZNNZctR0719VHsY=.5fad2479-bf04-425c-b471-0f1c462d112e@github.com>
Message-ID: <JY1mNxFMaXyPJr33_UJeQxIV_alQrTfZIe3jQlHqeU8=.0699a676-6097-4b94-851d-4f3def943d3b@github.com>

On Wed, 29 Mar 2023 00:06:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > Note: The feature requires at least Linux 4.14. The flag needs to be off for older versions.
> 
> In that case we should do a version check when trying to initialize, and at least warn if the OS is too old.

We already warn if the linux version is too old:
https://github.com/openjdk/jdk/pull/12753/files#diff-aeec57d804d56002f26a85359fc4ac8b48cfc249d57c656a30a63fc6bf3457adR4496
Would you like the message to mention Linux 4.14?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12753#issuecomment-1488367479

From rkennke at openjdk.org  Wed Mar 29 11:10:59 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 29 Mar 2023 11:10:59 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v34]
In-Reply-To: <um1xeKYtK5Oz0YDTHfxihW54WCrF9d7GvhPH-Y8tl4E=.33996344-c2dc-4ea3-8c01-da4054251a6f@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <um1xeKYtK5Oz0YDTHfxihW54WCrF9d7GvhPH-Y8tl4E=.33996344-c2dc-4ea3-8c01-da4054251a6f@github.com>
Message-ID: <uqur-aADwIMJjK0q9h-T-gjWD0xf8nqSCT5LMnXG0Jc=.ae89aca5-3845-4d92-a4f3-9fa9e8f88d13@github.com>

On Tue, 28 Mar 2023 14:00:12 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address @shipilev review comments (x86)

How about we call it 'lightweight locking' ? Stack-locking is also lightweight, but we already call it 'stack-locking', and the new locking impl is perhaps a little more lightweight insofar that it doesn't touch the object header much, and is a bit simpler in the implementation (we could drop all of BasicLock and related code, for example).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1488394648

From dzhang at openjdk.org  Wed Mar 29 12:30:38 2023
From: dzhang at openjdk.org (Dingli Zhang)
Date: Wed, 29 Mar 2023 12:30:38 GMT
Subject: RFR: 8305008: RISC-V: Factor out immediate checking functions from
 assembler_riscv.inline.hpp
In-Reply-To: <e5NuKyeESiNeAsFzb_1PbhCVx4N4tUEcFr-s8rqd-RA=.89caa00c-08d8-437e-9b56-b50a5d01fde2@github.com>
References: <zOPJRtrXmBK17ZgSm-THTp8qCXhh7tSNg6VRVFoLz9Y=.763009a8-a651-499d-a0e1-f114f3c842f0@github.com>
 <e5NuKyeESiNeAsFzb_1PbhCVx4N4tUEcFr-s8rqd-RA=.89caa00c-08d8-437e-9b56-b50a5d01fde2@github.com>
Message-ID: <-R6JcH7Ep5ON_0Ya6JKzT2jKImTUiZR65hc-DfcoGwY=.a81ef098-2557-4fa2-a2ec-8feade6dc3d4@github.com>

On Tue, 28 Mar 2023 06:07:27 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

> The tier2-tier3 tests are in progress and I will update the test results later.

Tier2 and tier3 passed without new failure.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13202#issuecomment-1488509692

From rkennke at openjdk.org  Wed Mar 29 13:51:51 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 29 Mar 2023 13:51:51 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v35]
In-Reply-To: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
Message-ID: <NhMXsf7u09iGG1DS_E4zttNbHncJDp0OyAA6WBAPEOQ=.2446a8cc-8313-467b-963f-9c7c4c6bbca9@github.com>

> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
> 
> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p
 rotocols.
> 
> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare.
> 
> 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
> 
> 
> Testing:
>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
> 
> ### Performance
> 
> #### Simple Microbenchmark
> 
> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
> 
> |  | x86_64 | aarch64 |
> | -- | -- | -- |
> | -UseFastLocking | 20.651 | 20.764 |
> | +UseFastLocking | 18.896 | 18.908 |
> 
> 
> #### Renaissance
> 
> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
> -- | -- | -- | -- | -- | -- | -- | --
> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Process lock-stack oops before inspecting them, when in foreign thread and not at safepoint. Add verifications.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10907/files
  - new: https://git.openjdk.org/jdk/pull/10907/files/798615f9..aa24debd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=34
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=33-34

  Stats: 108 lines in 11 files changed: 57 ins; 9 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/10907.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10907/head:pull/10907

PR: https://git.openjdk.org/jdk/pull/10907

From dnsimon at openjdk.org  Wed Mar 29 13:53:48 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 29 Mar 2023 13:53:48 GMT
Subject: RFR: 8305066: [JVMCI] guarantee(ik->is_initialized()) failed:
 java/lang/Long$LongCache must be initialized
Message-ID: <4MoN5JJV_aGKkgXXYCX0sgHkNc4fXnyWgS7emWRi0xg=.cfdff0ab-9420-437b-a57f-cfa5ca9a8051@github.com>

Class initialization can fail for the boxing caches such as `Long$LongCache` due to things such as a `StackOverflowError`.
When rematerializing boxed values during deoptimization, a failed cache initialization must be handled. This PR handles it by throwing an OOME which is always semantically correct.

-------------

Commit messages:
 - handle box caching classes that had an error during initialization

Changes: https://git.openjdk.org/jdk/pull/13229/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13229&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305066
  Stats: 58 lines in 4 files changed: 26 ins; 9 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/13229.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13229/head:pull/13229

PR: https://git.openjdk.org/jdk/pull/13229

From dnsimon at openjdk.org  Wed Mar 29 13:53:50 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 29 Mar 2023 13:53:50 GMT
Subject: RFR: 8305066: [JVMCI] guarantee(ik->is_initialized()) failed:
 java/lang/Long$LongCache must be initialized
In-Reply-To: <4MoN5JJV_aGKkgXXYCX0sgHkNc4fXnyWgS7emWRi0xg=.cfdff0ab-9420-437b-a57f-cfa5ca9a8051@github.com>
References: <4MoN5JJV_aGKkgXXYCX0sgHkNc4fXnyWgS7emWRi0xg=.cfdff0ab-9420-437b-a57f-cfa5ca9a8051@github.com>
Message-ID: <OzHP1M0780tgtoj71MrAUua_7szkT6bdj6qP22CjrN8=.5cdffb6a-ab04-43b5-9bf0-c73c2ad0c698@github.com>

On Wed, 29 Mar 2023 13:44:24 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> Class initialization can fail for the boxing caches such as `Long$LongCache` due to things such as a `StackOverflowError`.
> When rematerializing boxed values during deoptimization, a failed cache initialization must be handled. This PR handles it by throwing an OOME which is always semantically correct.

src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotJVMCIRuntime.java line 195:

> 193:                     JVMCI.getRuntime();
> 194:                 }
> 195:                 // Make sure all the primitive box caches are populated (required to properly

This code has not been necessary ever since https://github.com/openjdk/jdk/blob/e56bcb04b11c6494e6afdf0bd9b9bc65a4769347/src/hotspot/share/jvmci/jvmciCodeInstaller.cpp#L985 was added.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13229#discussion_r1151970758

From rkennke at openjdk.org  Wed Mar 29 14:15:34 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 29 Mar 2023 14:15:34 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v36]
In-Reply-To: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
Message-ID: <t5damQPYGx2bBu9tGzXapBFT1_cm2TaD8mDQ7UYjsL0=.d7e0e527-de9f-4c73-9479-76d636068d53@github.com>

> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
> 
> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p
 rotocols.
> 
> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare.
> 
> 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
> 
> 
> Testing:
>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
> 
> ### Performance
> 
> #### Simple Microbenchmark
> 
> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
> 
> |  | x86_64 | aarch64 |
> | -- | -- | -- |
> | -UseFastLocking | 20.651 | 20.764 |
> | +UseFastLocking | 18.896 | 18.908 |
> 
> 
> #### Renaissance
> 
> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
> -- | -- | -- | -- | -- | -- | -- | --
> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Relax verification in oops_do(), put back UseFastLocking in management.cpp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10907/files
  - new: https://git.openjdk.org/jdk/pull/10907/files/aa24debd..885eb613

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=35
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=34-35

  Stats: 8 lines in 4 files changed: 5 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10907.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10907/head:pull/10907

PR: https://git.openjdk.org/jdk/pull/10907

From jvernee at openjdk.org  Wed Mar 29 14:45:11 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 29 Mar 2023 14:45:11 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v15]
In-Reply-To: <cVBIvlWcR-LFVl1oioaOFR-Xo2ZZnweP6uby_hxPYGU=.a61a7f36-9ebc-4051-9ca2-6f3bb5cd908c@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <cVBIvlWcR-LFVl1oioaOFR-Xo2ZZnweP6uby_hxPYGU=.a61a7f36-9ebc-4051-9ca2-6f3bb5cd908c@github.com>
Message-ID: <dSdHosd_vI2VCf93TrT2VcmmP_Yq9DyxPmwked_8aYg=.7802362d-5ecc-4f1d-a069-4cf6fff6fb49@github.com>

On Wed, 29 Mar 2023 08:55:08 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> API changes for the FFM API (third preview)
>> 
>> Specdiff:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
>> 
>> Javadoc:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup finality

Marked as reviewed by jvernee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13079#pullrequestreview-1363295684

From rkennke at openjdk.org  Wed Mar 29 15:06:02 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 29 Mar 2023 15:06:02 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <RqLUI4UYLYqW3wpKY9oKjEm6ocLVXdX2GKLC_SSGnwY=.7bc81122-cffa-4461-a55c-e77a17cc8ebc@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
 <nRCVukhWG7mplVCtzhcrXxWb9fu3vPVmRfXno0Rk7iE=.3b04aaa0-d3c5-48e4-8514-3fb5d25f9662@github.com>
 <CfaFMydhpKfCzkc8re16y_oQZvGvO_KLkEN672phdU8=.3dfecf58-9038-48ac-9eb9-f0a76d742d40@github.com>
 <RqLUI4UYLYqW3wpKY9oKjEm6ocLVXdX2GKLC_SSGnwY=.7bc81122-cffa-4461-a55c-e77a17cc8ebc@github.com>
Message-ID: <r5Fk_v5Ehf3vmbXpc6aIM3NEtX36iZ2CnlXJGhrt4-Y=.dafcee99-de96-4fcb-a01a-98a2299e88a5@github.com>

On Tue, 28 Mar 2023 16:00:34 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Please also verify against over- and underflow, and better than just null checks check that every oop really is an oop. I added this to my code:
>> 
>>   assert((_offset <=  end_offset()), "lockstack overflow: _offset %d end_offset %d", _offset, end_offset());
>>   assert((_offset >= start_offset()), "lockstack underflow: _offset %d end_offset %d", _offset, start_offset());
>>   int end = to_index(_offset);
>>   for (int i = 0; i < end; i++) {
>>     assert(oopDesc::is_oop(_base[i]), "index %i: not an oop (" PTR_FORMAT ")", i, p2i(_base[i]));
>> ...
>
> Just realized that my proposal of oop-checking does not work since during GC oop can be moved and will temporarily be invalid.

Checking for is_oop() may not work, because oops may be temporarily invalid, until the GC gets to fix them. This is especially (and probably only) true around oops_do().

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1152089622

From never at openjdk.org  Wed Mar 29 15:21:27 2023
From: never at openjdk.org (Tom Rodriguez)
Date: Wed, 29 Mar 2023 15:21:27 GMT
Subject: RFR: 8305066: [JVMCI] guarantee(ik->is_initialized()) failed:
 java/lang/Long$LongCache must be initialized
In-Reply-To: <OzHP1M0780tgtoj71MrAUua_7szkT6bdj6qP22CjrN8=.5cdffb6a-ab04-43b5-9bf0-c73c2ad0c698@github.com>
References: <4MoN5JJV_aGKkgXXYCX0sgHkNc4fXnyWgS7emWRi0xg=.cfdff0ab-9420-437b-a57f-cfa5ca9a8051@github.com>
 <OzHP1M0780tgtoj71MrAUua_7szkT6bdj6qP22CjrN8=.5cdffb6a-ab04-43b5-9bf0-c73c2ad0c698@github.com>
Message-ID: <FxMPKhyWYq-ukOxqWE56-I2jW_DKfEPavaqbwJZyMqs=.2d6e7e7f-fa6c-4462-8261-78493a14c6df@github.com>

On Wed, 29 Mar 2023 13:46:14 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Class initialization can fail for the boxing caches such as `Long$LongCache` due to things such as a `StackOverflowError`.
>> When rematerializing boxed values during deoptimization, a failed cache initialization must be handled. This PR handles it by throwing an OOME which is always semantically correct.
>
> src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotJVMCIRuntime.java line 195:
> 
>> 193:                     JVMCI.getRuntime();
>> 194:                 }
>> 195:                 // Make sure all the primitive box caches are populated (required to properly
> 
> This code has not been necessary ever since https://github.com/openjdk/jdk/blob/e56bcb04b11c6494e6afdf0bd9b9bc65a4769347/src/hotspot/share/jvmci/jvmciCodeInstaller.cpp#L985 was added.

How are the caches uninitialized if we have forced their initialization?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13229#discussion_r1152115164

From tschatzl at openjdk.org  Wed Mar 29 15:29:30 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 29 Mar 2023 15:29:30 GMT
Subject: RFR: 8304759: Add BitMap iterators [v2]
In-Reply-To: <UkXNPij1QwEq03FKIpzZd0ccz70L0mxYcQa18IzOVz4=.75123a32-63b4-4a31-80ad-f354edab3174@github.com>
References: <4FHjg8u1ix7KodqaJkU5q-tnYRDAq3GhRV0z7ArpYGU=.7434363a-1bcb-467f-9225-0e97d4ade998@github.com>
 <UkXNPij1QwEq03FKIpzZd0ccz70L0mxYcQa18IzOVz4=.75123a32-63b4-4a31-80ad-f354edab3174@github.com>
Message-ID: <OePHAkNtYuLJ2THFC3eABtSDiZ3fw2O26DhdRtG1ojU=.36b1747f-0117-4342-81f9-a80b9e32e557@github.com>

On Wed, 29 Mar 2023 03:07:21 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change which adds iteration over the set bit positions of a
>> BitMap via an iterator object.  This is in addition to the existing iterate()
>> and reverse_iterate() functions that apply a function to the set bit positions.
>> 
>> There are two iterator classes: BitMap::Iterator and BitMap::ReverseIterator.
>> Iteration uses a single, self-contained iterator object, rather than a pair of
>> iterator objects as is done with standard library iterators.  This is because
>> the desired form of iteration over bitmaps doesn't lend itself well to the
>> begin/end pair style.  Typical usage is something like
>> 
>> 
>> for (BitMap::Iterator it{map, beg, end}; !it.is_empty(); it.step()) {
>>   ... use it.index()
>> }
>> 
>> 
>> However, as a syntactic convenience, these iterator classes provide begin()
>> and end() member functions returning objects supporting the requirements for
>> range-based for loops.  By constraining these objects to this usage we can
>> cope with the "iterator pair" requirements.  Usage is something like
>> 
>> 
>> for (BitMap::idx_t index : BitMap::Iterator{map, beg, end}) {
>>   ...
>> }
>> 
>> 
>> Testing:
>> mach5 tier1, which includes running the updated gtests on all Oracle-supported
>> platforms.
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   better names for step functions

Marked as reviewed by tschatzl (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13184#pullrequestreview-1363398970

From rkennke at openjdk.org  Wed Mar 29 16:05:05 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 29 Mar 2023 16:05:05 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v37]
In-Reply-To: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
Message-ID: <Y7GnMCO0_ZCOlK7-0KrSaFrQY3EWb6mwtoZT8ZjmRBI=.cef3dbdb-7d55-45ee-b6f1-c3c614098513@github.com>

> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
> 
> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p
 rotocols.
> 
> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare.
> 
> 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
> 
> 
> Testing:
>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
> 
> ### Performance
> 
> #### Simple Microbenchmark
> 
> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
> 
> |  | x86_64 | aarch64 |
> | -- | -- | -- |
> | -UseFastLocking | 20.651 | 20.764 |
> | +UseFastLocking | 18.896 | 18.908 |
> 
> 
> #### Renaissance
> 
> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
> -- | -- | -- | -- | -- | -- | -- | --
> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Bounds check in lock-stack verification; only do watermark if we have one

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10907/files
  - new: https://git.openjdk.org/jdk/pull/10907/files/885eb613..62298e49

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=36
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=35-36

  Stats: 13 lines in 3 files changed: 12 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10907.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10907/head:pull/10907

PR: https://git.openjdk.org/jdk/pull/10907

From dnsimon at openjdk.org  Wed Mar 29 16:13:35 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 29 Mar 2023 16:13:35 GMT
Subject: RFR: 8305066: [JVMCI] guarantee(ik->is_initialized()) failed:
 java/lang/Long$LongCache must be initialized
In-Reply-To: <FxMPKhyWYq-ukOxqWE56-I2jW_DKfEPavaqbwJZyMqs=.2d6e7e7f-fa6c-4462-8261-78493a14c6df@github.com>
References: <4MoN5JJV_aGKkgXXYCX0sgHkNc4fXnyWgS7emWRi0xg=.cfdff0ab-9420-437b-a57f-cfa5ca9a8051@github.com>
 <OzHP1M0780tgtoj71MrAUua_7szkT6bdj6qP22CjrN8=.5cdffb6a-ab04-43b5-9bf0-c73c2ad0c698@github.com>
 <FxMPKhyWYq-ukOxqWE56-I2jW_DKfEPavaqbwJZyMqs=.2d6e7e7f-fa6c-4462-8261-78493a14c6df@github.com>
Message-ID: <HiYmlAxfu4WPaoNBG5WTIlX1JUkvlsEGVGdW7q80lrM=.f54bb9db-d872-47e9-8089-bda54e5b93e9@github.com>

On Wed, 29 Mar 2023 15:19:03 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotJVMCIRuntime.java line 195:
>> 
>>> 193:                     JVMCI.getRuntime();
>>> 194:                 }
>>> 195:                 // Make sure all the primitive box caches are populated (required to properly
>> 
>> This code has not been necessary ever since https://github.com/openjdk/jdk/blob/e56bcb04b11c6494e6afdf0bd9b9bc65a4769347/src/hotspot/share/jvmci/jvmciCodeInstaller.cpp#L985 was added.
>
> How are the caches uninitialized if we have forced their initialization?

A box cache initialization can fail due to `StackOverflowError`. In this case, we must not rematerialize a virtual object corresponding to a value that would be read from a box cache.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13229#discussion_r1152181352

From kbarrett at openjdk.org  Wed Mar 29 16:18:34 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 29 Mar 2023 16:18:34 GMT
Subject: RFR: 8304759: Add BitMap iterators [v2]
In-Reply-To: <s5BdZLlhOcqtjLXhgfacnqoYFun36p1xWuZoGI8_pSw=.dbb16524-1203-43f6-9213-f801d8359ab9@github.com>
References: <4FHjg8u1ix7KodqaJkU5q-tnYRDAq3GhRV0z7ArpYGU=.7434363a-1bcb-467f-9225-0e97d4ade998@github.com>
 <UkXNPij1QwEq03FKIpzZd0ccz70L0mxYcQa18IzOVz4=.75123a32-63b4-4a31-80ad-f354edab3174@github.com>
 <UXwh8z6fiLhub9aVtI7_PXADfbgy5LQlUVVVP_gmxLg=.b7865272-92df-4b74-88f1-cf50b6d8c4c3@github.com>
 <s5BdZLlhOcqtjLXhgfacnqoYFun36p1xWuZoGI8_pSw=.dbb16524-1203-43f6-9213-f801d8359ab9@github.com>
Message-ID: <hDWIB8Ruk7dSNQQFd8P3HSWVmNv9uAOXV96ZuIwj9TM=.55c86844-0af0-4ac2-aaf7-1c2c26206ead@github.com>

On Wed, 29 Mar 2023 09:31:40 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> src/hotspot/share/utilities/bitMap.hpp line 420:
>> 
>>> 418:   // Returns the index of the last set bit in the remaining iteration range.
>>> 419:   // precondition: !is_empty()
>>> 420:   idx_t last() const;
>> 
>> The comments for `first()` and `last()` are a little misleading. The invariant that the `first()`/`last()` is a set bit is only true for `first()` in the forward iterator and for `last()` in the reverse iterator. 
>> 
>> It seems more like a contract that if you use `first()` then you must have created `IteratorImpl(const BitMap* map, idx_t beg, idx_t end)` with `beg` being a set bit. And if you use `last()` then you must have created it with `end-1` being a set bit.
>
> Or `beg == end`, that is an `is_empty()` Iterator

Yes, you are correct.  Some of the comments for IteratorImpl didn't get properly updated.  I'll clean that up.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13184#discussion_r1152186946

From shade at openjdk.org  Wed Mar 29 16:44:34 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 29 Mar 2023 16:44:34 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity
Message-ID: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>

Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The documentation for that method clearly says the precision and accuracy are dependent on the underlying system behavior. However, it always rounds up `nanos` to 1ms when doing the actual sleep. This means users cannot do the micro-second precision sleeps, even when the underlying platform allows it. Sub-millisecond sleeps are useful to build interesting primitives, like the rate limiters that run with >1000 RPS.

When faced with this, some users reach for more awkward APIs like `java.util.concurrent.locks.LockSupport.parkNanos`. The use of that API for sleeps is not in line with its intent, and while it "seems to work", it might have interesting interactions with other uses of `LockSupport`. Additionally, these "sleeps" are no longer visible to monitoring tools as "normal sleeps", e.g. as `Thread.sleep` events. Therefore, it would be prudent to improve current `Thread.sleep(millis, nanos)` for sub-millisecond granularity. 

Fortunately, the underlying code is almost ready for this, at least on POSIX side. I skipped Windows paths, because its timers are still no good. Note that on both Linux and MacOS timers oversleep by about 50us. I have a few ideas how to improve the accuracy for them, which would be a topic for a separate PR.

Motivational improvements on new benchmark below:

m6g.9xlarge (Linux, Xeon, x86_64):


Benchmark                 (sleep)  Mode  Cnt           Score       Error  Units

# ========= no regressions for Thread.sleep(millis)

# Baseline
ThreadSleep.millis             0  avgt    5         463.606 ?     8.256  ns/op
ThreadSleep.millis             1  avgt    5         459.434 ?     0.453  ns/op
ThreadSleep.millis            10  avgt    5         462.828 ?     1.283  ns/op
ThreadSleep.millis           100  avgt    5         459.495 ?     3.244  ns/op
ThreadSleep.millis          1000  avgt    5         457.962 ?     5.769  ns/op
ThreadSleep.millis         10000  avgt    5         457.960 ?     1.195  ns/op
ThreadSleep.millis        100000  avgt    5         459.197 ?     3.054  ns/op
ThreadSleep.millis       1000000  avgt    5     1058342.873 ?   304.169  ns/op
ThreadSleep.millis      10000000  avgt    5    10059945.148 ?  1642.411  ns/op
ThreadSleep.millis     100000000  avgt    5   100062181.340 ?  1863.186  ns/op
ThreadSleep.millis    1000000000  avgt    5  1000070015.600 ? 11379.631  ns/op

# Patched
ThreadSleep.millis             0  avgt    5         461.295 ?     6.700  ns/op
ThreadSleep.millis             1  avgt    5         463.383 ?     3.065  ns/op
ThreadSleep.millis            10  avgt    5         468.109 ?     1.607  ns/op
ThreadSleep.millis           100  avgt    5         467.316 ?     0.270  ns/op
ThreadSleep.millis          1000  avgt    5         461.999 ?     2.341  ns/op
ThreadSleep.millis         10000  avgt    5         465.075 ?     0.324  ns/op
ThreadSleep.millis        100000  avgt    5         462.588 ?     5.321  ns/op
ThreadSleep.millis       1000000  avgt    5     1058285.440 ?   409.376  ns/op
ThreadSleep.millis      10000000  avgt    5    10060437.490 ?   177.754  ns/op
ThreadSleep.millis     100000000  avgt    5   100060665.980 ?  1167.514  ns/op
ThreadSleep.millis    1000000000  avgt    5  1000071917.300 ? 17438.906  ns/op

# ========= Significant improvements for Thread.sleep(millis, nanos)

# Baseline
ThreadSleep.millisNanos           0  avgt    5         462.831 ?     0.251  ns/op
ThreadSleep.millisNanos           1  avgt    5     1058708.668 ?   960.683  ns/op
ThreadSleep.millisNanos          10  avgt    5     1058364.414 ?   197.700  ns/op
ThreadSleep.millisNanos         100  avgt    5     1058451.889 ?   561.979  ns/op
ThreadSleep.millisNanos        1000  avgt    5     1058372.010 ?    96.867  ns/op
ThreadSleep.millisNanos       10000  avgt    5     1058354.100 ?   297.148  ns/op
ThreadSleep.millisNanos      100000  avgt    5     1058485.092 ?  1093.340  ns/op
ThreadSleep.millisNanos     1000000  avgt    5     1059004.036 ?  1899.950  ns/op
ThreadSleep.millisNanos    10000000  avgt    5    10059733.302 ?  1725.908  ns/op
ThreadSleep.millisNanos   100000000  avgt    5   100063327.840 ?  6244.805  ns/op
ThreadSleep.millisNanos  1000000000  avgt    5  1000074542.300 ? 17898.173  ns/op

# Patched
ThreadSleep.millisNanos           0  avgt    5         467.968 ?     9.202  ns/op
ThreadSleep.millisNanos           1  avgt    5         579.448 ?     1.363  ns/op
ThreadSleep.millisNanos          10  avgt    5         577.656 ?     0.278  ns/op
ThreadSleep.millisNanos         100  avgt    5       58092.815 ?  2410.401  ns/op
ThreadSleep.millisNanos        1000  avgt    5       58592.249 ?   189.232  ns/op
ThreadSleep.millisNanos       10000  avgt    5       67668.688 ?   591.365  ns/op
ThreadSleep.millisNanos      100000  avgt    5      158143.164 ?  2281.540  ns/op
ThreadSleep.millisNanos     1000000  avgt    5     1058508.682 ?   155.767  ns/op
ThreadSleep.millisNanos    10000000  avgt    5    10059979.272 ?  1095.207  ns/op
ThreadSleep.millisNanos   100000000  avgt    5   100066844.180 ?  4287.440  ns/op
ThreadSleep.millisNanos  1000000000  avgt    5  1000075313.100 ?  9665.656  ns/op


m6g.4xlarge (Linux, Graviton, AArch64):


# ========= no regressions for Thread.sleep(millis)

# Baseline
ThreadSleep.millis             0  avgt    5         429.403 ?    24.947  ns/op
ThreadSleep.millis             1  avgt    5         427.533 ?     7.969  ns/op
ThreadSleep.millis            10  avgt    5         438.464 ?    10.277  ns/op
ThreadSleep.millis           100  avgt    5         425.626 ?     3.371  ns/op
ThreadSleep.millis          1000  avgt    5         426.465 ?     4.501  ns/op
ThreadSleep.millis         10000  avgt    5         427.235 ?     6.916  ns/op
ThreadSleep.millis        100000  avgt    5         430.311 ?     4.073  ns/op
ThreadSleep.millis       1000000  avgt    5     1054808.881 ?   469.409  ns/op
ThreadSleep.millis      10000000  avgt    5    10055497.206 ?  2123.591  ns/op
ThreadSleep.millis     100000000  avgt    5   100059355.520 ? 11597.426  ns/op
ThreadSleep.millis    1000000000  avgt    5  1000073145.400 ?  7659.244  ns/op

# Patched
ThreadSleep.millis             0  avgt    5         429.535 ?     2.597  ns/op
ThreadSleep.millis             1  avgt    5         425.209 ?     3.620  ns/op
ThreadSleep.millis            10  avgt    5         432.416 ?     9.350  ns/op
ThreadSleep.millis           100  avgt    5         432.867 ?     3.978  ns/op
ThreadSleep.millis          1000  avgt    5         426.627 ?     1.064  ns/op
ThreadSleep.millis         10000  avgt    5         427.180 ?     4.691  ns/op
ThreadSleep.millis        100000  avgt    5         438.554 ?     4.271  ns/op
ThreadSleep.millis       1000000  avgt    5     1054693.226 ?   323.240  ns/op
ThreadSleep.millis      10000000  avgt    5    10056408.240 ?  1759.211  ns/op
ThreadSleep.millis     100000000  avgt    5   100062449.780 ? 15133.808  ns/op
ThreadSleep.millis    1000000000  avgt    5  1000066918.500 ? 15817.822  ns/op

# ========= Significant improvements for Thread.sleep(millis, nanos)

# Baseline
ThreadSleep.millisNanos           0  avgt    5         439.163 ?     5.559  ns/op
ThreadSleep.millisNanos           1  avgt    5     1054751.231 ?   431.842  ns/op
ThreadSleep.millisNanos          10  avgt    5     1054640.725 ?   525.901  ns/op
ThreadSleep.millisNanos         100  avgt    5     1054807.619 ?  1009.104  ns/op
ThreadSleep.millisNanos        1000  avgt    5     1054894.829 ?  1946.551  ns/op
ThreadSleep.millisNanos       10000  avgt    5     1054765.444 ?   701.873  ns/op
ThreadSleep.millisNanos      100000  avgt    5     1054707.758 ?   619.054  ns/op
ThreadSleep.millisNanos     1000000  avgt    5     1054802.230 ?  1294.035  ns/op
ThreadSleep.millisNanos    10000000  avgt    5    10055265.430 ?  1184.281  ns/op
ThreadSleep.millisNanos   100000000  avgt    5   100057484.300 ?  7960.939  ns/op
ThreadSleep.millisNanos  1000000000  avgt    5  1000062244.700 ? 20244.067  ns/op

# Patched
ThreadSleep.millisNanos           0  avgt    5         426.482 ?    10.284  ns/op
ThreadSleep.millisNanos           1  avgt    5         565.819 ?     1.098  ns/op
ThreadSleep.millisNanos          10  avgt    5         564.108 ?     3.493  ns/op
ThreadSleep.millisNanos         100  avgt    5       53698.839 ?   942.506  ns/op
ThreadSleep.millisNanos        1000  avgt    5       55205.929 ?   416.951  ns/op
ThreadSleep.millisNanos       10000  avgt    5       64206.709 ?   382.213  ns/op
ThreadSleep.millisNanos      100000  avgt    5      154477.045 ?   125.316  ns/op
ThreadSleep.millisNanos     1000000  avgt    5     1054889.472 ?  2152.765  ns/op
ThreadSleep.millisNanos    10000000  avgt    5    10055273.582 ?   691.628  ns/op
ThreadSleep.millisNanos   100000000  avgt    5   100058261.300 ?  5222.946  ns/op
ThreadSleep.millisNanos  1000000000  avgt    5  1000065434.000 ? 30213.137  ns/op


MacBook 2021 (MacOS X, M1, AArch64):


# ========= no regressions for Thread.sleep(millis)

# Baseline
Benchmark                 (sleep)  Mode  Cnt           Score          Error  Units
ThreadSleep.millis             0  avgt    5         555,871 ?      525,544  ns/op
ThreadSleep.millis             1  avgt    5         405,761 ?      153,981  ns/op
ThreadSleep.millis            10  avgt    5         403,906 ?      279,245  ns/op
ThreadSleep.millis           100  avgt    5         402,787 ?      223,658  ns/op
ThreadSleep.millis          1000  avgt    5         439,250 ?      374,150  ns/op
ThreadSleep.millis         10000  avgt    5         435,769 ?      352,067  ns/op
ThreadSleep.millis        100000  avgt    5        1853,664 ?     7254,716  ns/op
ThreadSleep.millis       1000000  avgt    5     1364788,214 ?    66446,869  ns/op
ThreadSleep.millis      10000000  avgt    5    11819681,019 ?   473810,685  ns/op
ThreadSleep.millis     100000000  avgt    5   103536901,660 ?  1423282,032  ns/op
ThreadSleep.millis    1000000000  avgt    5  1002995262,600 ?  6576388,880  ns/op

# Patched
ThreadSleep.millis             0  avgt    5         662,597 ?     459,888  ns/op
ThreadSleep.millis             1  avgt    5         433,561 ?     214,850  ns/op
ThreadSleep.millis            10  avgt    5         388,614 ?      65,199  ns/op
ThreadSleep.millis           100  avgt    5         436,823 ?     636,901  ns/op
ThreadSleep.millis          1000  avgt    5         337,046 ?     129,440  ns/op
ThreadSleep.millis         10000  avgt    5         366,557 ?     510,494  ns/op
ThreadSleep.millis        100000  avgt    5         278,339 ?     102,443  ns/op
ThreadSleep.millis       1000000  avgt    5     1520092,133 ?   26217,972  ns/op
ThreadSleep.millis      10000000  avgt    5    13116509,001 ?  855508,621  ns/op
ThreadSleep.millis     100000000  avgt    5   107010708,340 ? 1667080,292  ns/op
ThreadSleep.millis    1000000000  avgt    5  1005412095,700 ? 6141267,753  ns/op

# ========= Significant improvements for Thread.sleep(millis, nanos)

# Baseline
ThreadSleep.millisNanos           0  avgt    5         245,942 ?       44,338  ns/op
ThreadSleep.millisNanos           1  avgt    5     1313354,886 ?    71820,989  ns/op
ThreadSleep.millisNanos          10  avgt    5     1310358,568 ?    42731,583  ns/op
ThreadSleep.millisNanos         100  avgt    5     1335221,078 ?   122031,471  ns/op
ThreadSleep.millisNanos        1000  avgt    5     1313977,625 ?    30683,810  ns/op
ThreadSleep.millisNanos       10000  avgt    5     1553321,472 ?    75181,324  ns/op
ThreadSleep.millisNanos      100000  avgt    5     1553317,573 ?   132998,558  ns/op
ThreadSleep.millisNanos     1000000  avgt    5     1544944,015 ?    41587,129  ns/op
ThreadSleep.millisNanos    10000000  avgt    5    13228565,376 ?   902384,381  ns/op
ThreadSleep.millisNanos   100000000  avgt    5   106866740,840 ?  2518606,524  ns/op
ThreadSleep.millisNanos  1000000000  avgt    5  1006669020,800 ? 10961093,568  ns/op

# Patched
ThreadSleep.millisNanos           0  avgt    5         394,716 ?     310,886  ns/op
ThreadSleep.millisNanos           1  avgt    5        9945,543 ?     905,136  ns/op
ThreadSleep.millisNanos          10  avgt    5        9863,605 ?     557,909  ns/op
ThreadSleep.millisNanos         100  avgt    5        2454,862 ?     323,279  ns/op
ThreadSleep.millisNanos        1000  avgt    5        3834,507 ?    2427,033  ns/op
ThreadSleep.millisNanos       10000  avgt    5       16667,415 ?     508,814  ns/op
ThreadSleep.millisNanos      100000  avgt    5      154202,589 ?     258,406  ns/op
ThreadSleep.millisNanos     1000000  avgt    5     1557886,136 ?  192080,832  ns/op
ThreadSleep.millisNanos    10000000  avgt    5    13077385,237 ?  887650,194  ns/op
ThreadSleep.millisNanos   100000000  avgt    5   106225257,480 ? 3288589,410  ns/op
ThreadSleep.millisNanos  1000000000  avgt    5  1006589558,200 ? 3677828,811  ns/op


Additional testing:
  - [x] New regression test
  - [x] New benchmark
  - [x] Linux x86_64 `tier1`
  - [x] Linux AArch64 `tier1`

-------------

Commit messages:
 - More fixes
 - Fix Windows yet again
 - Helper method should be inline, not static
 - Work

Changes: https://git.openjdk.org/jdk/pull/13225/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13225&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305092
  Stats: 300 lines in 13 files changed: 247 ins; 36 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/13225.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13225/head:pull/13225

PR: https://git.openjdk.org/jdk/pull/13225

From amitkumar at openjdk.org  Wed Mar 29 16:50:32 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Wed, 29 Mar 2023 16:50:32 GMT
Subject: RFR: 8302328: [s390x] Simplify asm_assert definition [v2]
In-Reply-To: <51VAVmniXPGE4sgcdw2AnU1hqZn2fVJRyDEbrt3AyyU=.b70f59dc-8397-4da4-b36b-266766434b19@github.com>
References: <51VAVmniXPGE4sgcdw2AnU1hqZn2fVJRyDEbrt3AyyU=.b70f59dc-8397-4da4-b36b-266766434b19@github.com>
Message-ID: <Cwc2cqWiGcKQspZ1EwN4ZilNfre3wYA8WDP9kiHZjAw=.d03553b2-ea9b-4821-8576-9014ee12c22a@github.com>

> This PR cleanups some assert statements and specifies branch condition at calling site itself. Remaining asm_assert methods are inlined as well.

Amit Kumar has updated the pull request incrementally with five additional commits since the last revision:

 - added id to illtrap
 - address lutz comment & revert inlining
 - Revert "inline asm_assert"
 - Revert "inlined assert method"
 - Revert "added inline keyword before function implementation"

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12822/files
  - new: https://git.openjdk.org/jdk/pull/12822/files/72e6d990..5580cfc6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12822&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12822&range=00-01

  Stats: 132 lines in 13 files changed: 52 ins; 55 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/12822.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12822/head:pull/12822

PR: https://git.openjdk.org/jdk/pull/12822

From duke at openjdk.org  Wed Mar 29 16:51:51 2023
From: duke at openjdk.org (David M. Lloyd)
Date: Wed, 29 Mar 2023 16:51:51 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity
In-Reply-To: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
Message-ID: <SZnG5gsawcOMCcQD-rPAOZwfX-Bi2HERjXXoGqNnewA=.48e6e59e-51ec-4a2b-8236-2885a291706a@github.com>

On Wed, 29 Mar 2023 11:28:53 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The documentation for that method clearly says the precision and accuracy are dependent on the underlying system behavior. However, it always rounds up `nanos` to 1ms when doing the actual sleep. This means users cannot do the micro-second precision sleeps, even when the underlying platform allows it. Sub-millisecond sleeps are useful to build interesting primitives, like the rate limiters that run with >1000 RPS.
> 
> When faced with this, some users reach for more awkward APIs like `java.util.concurrent.locks.LockSupport.parkNanos`. The use of that API for sleeps is not in line with its intent, and while it "seems to work", it might have interesting interactions with other uses of `LockSupport`. Additionally, these "sleeps" are no longer visible to monitoring tools as "normal sleeps", e.g. as `Thread.sleep` events. Therefore, it would be prudent to improve current `Thread.sleep(millis, nanos)` for sub-millisecond granularity. 
> 
> Fortunately, the underlying code is almost ready for this, at least on POSIX side. I skipped Windows paths, because its timers are still no good. Note that on both Linux and MacOS timers oversleep by about 50us. I have a few ideas how to improve the accuracy for them, which would be a topic for a separate PR.
> 
> Motivational improvements on new benchmark below:
> 
> m6g.9xlarge (Linux, Xeon, x86_64):
> 
> 
> Benchmark                 (sleep)  Mode  Cnt           Score       Error  Units
> 
> # ========= no regressions for Thread.sleep(millis)
> 
> # Baseline
> ThreadSleep.millis             0  avgt    5         463.606 ?     8.256  ns/op
> ThreadSleep.millis             1  avgt    5         459.434 ?     0.453  ns/op
> ThreadSleep.millis            10  avgt    5         462.828 ?     1.283  ns/op
> ThreadSleep.millis           100  avgt    5         459.495 ?     3.244  ns/op
> ThreadSleep.millis          1000  avgt    5         457.962 ?     5.769  ns/op
> ThreadSleep.millis         10000  avgt    5         457.960 ?     1.195  ns/op
> ThreadSleep.millis        100000  avgt    5         459.197 ?     3.054  ns/op
> ThreadSleep.millis       1000000  avgt    5     1058342.873 ?   304.169  ns/op
> ThreadSleep.millis      10000000  avgt    5    10059945.148 ?  1642.411  ns/op
> ThreadSleep.millis     100000000  avgt    5   100062181.340 ?  1863.186  ns/op
> ThreadSleep.millis    1000000000  avgt    5  1000070015.600 ? 11379.631  ns/op
> 
> # Patched
> ThreadSleep.millis             0  avgt    5         461.295 ?     6.700  ns/op
> ThreadSleep.millis             1  avgt    5         463.383 ?     3.065  ns/op
> ThreadSleep.millis            10  avgt    5         468.109 ?     1.607  ns/op
> ThreadSleep.millis           100  avgt    5         467.316 ?     0.270  ns/op
> ThreadSleep.millis          1000  avgt    5         461.999 ?     2.341  ns/op
> ThreadSleep.millis         10000  avgt    5         465.075 ?     0.324  ns/op
> ThreadSleep.millis        100000  avgt    5         462.588 ?     5.321  ns/op
> ThreadSleep.millis       1000000  avgt    5     1058285.440 ?   409.376  ns/op
> ThreadSleep.millis      10000000  avgt    5    10060437.490 ?   177.754  ns/op
> ThreadSleep.millis     100000000  avgt    5   100060665.980 ?  1167.514  ns/op
> ThreadSleep.millis    1000000000  avgt    5  1000071917.300 ? 17438.906  ns/op
> 
> # ========= Significant improvements for Thread.sleep(millis, nanos)
> 
> # Baseline
> ThreadSleep.millisNanos           0  avgt    5         462.831 ?     0.251  ns/op
> ThreadSleep.millisNanos           1  avgt    5     1058708.668 ?   960.683  ns/op
> ThreadSleep.millisNanos          10  avgt    5     1058364.414 ?   197.700  ns/op
> ThreadSleep.millisNanos         100  avgt    5     1058451.889 ?   561.979  ns/op
> ThreadSleep.millisNanos        1000  avgt    5     1058372.010 ?    96.867  ns/op
> ThreadSleep.millisNanos       10000  avgt    5     1058354.100 ?   297.148  ns/op
> ThreadSleep.millisNanos      100000  avgt    5     1058485.092 ?  1093.340  ns/op
> ThreadSleep.millisNanos     1000000  avgt    5     1059004.036 ?  1899.950  ns/op
> ThreadSleep.millisNanos    10000000  avgt    5    10059733.302 ?  1725.908  ns/op
> ThreadSleep.millisNanos   100000000  avgt    5   100063327.840 ?  6244.805  ns/op
> ThreadSleep.millisNanos  1000000000  avgt    5  1000074542.300 ? 17898.173  ns/op
> 
> # Patched
> ThreadSleep.millisNanos           0  avgt    5         467.968 ?     9.202  ns/op
> ThreadSleep.millisNanos           1  avgt    5         579.448 ?     1.363  ns/op
> ThreadSleep.millisNanos          10  avgt    5         577.656 ?     0.278  ns/op
> ThreadSleep.millisNanos         100  avgt    5       58092.815 ?  2410.401  ns/op
> ThreadSleep.millisNanos        1000  avgt    5       58592.249 ?   189.232  ns/op
> ThreadSleep.millisNanos       10000  avgt    5       67668.688 ?   591.365  ns/op
> ThreadSleep.millisNanos      100000  avgt    5      158143.164 ?  2281.540  ns/op
> ThreadSleep.millisNanos     1000000  avgt    5     1058508.682 ?   155.767  ns/op
> ThreadSleep.millisNanos    10000000  avgt    5    10059979.272 ?  1095.207  ns/op
> ThreadSleep.millisNanos   100000000  avgt    5   100066844.180 ?  4287.440  ns/op
> ThreadSleep.millisNanos  1000000000  avgt    5  1000075313.100 ?  9665.656  ns/op
> 
> 
> m6g.4xlarge (Linux, Graviton, AArch64):
> 
> 
> # ========= no regressions for Thread.sleep(millis)
> 
> # Baseline
> ThreadSleep.millis             0  avgt    5         429.403 ?    24.947  ns/op
> ThreadSleep.millis             1  avgt    5         427.533 ?     7.969  ns/op
> ThreadSleep.millis            10  avgt    5         438.464 ?    10.277  ns/op
> ThreadSleep.millis           100  avgt    5         425.626 ?     3.371  ns/op
> ThreadSleep.millis          1000  avgt    5         426.465 ?     4.501  ns/op
> ThreadSleep.millis         10000  avgt    5         427.235 ?     6.916  ns/op
> ThreadSleep.millis        100000  avgt    5         430.311 ?     4.073  ns/op
> ThreadSleep.millis       1000000  avgt    5     1054808.881 ?   469.409  ns/op
> ThreadSleep.millis      10000000  avgt    5    10055497.206 ?  2123.591  ns/op
> ThreadSleep.millis     100000000  avgt    5   100059355.520 ? 11597.426  ns/op
> ThreadSleep.millis    1000000000  avgt    5  1000073145.400 ?  7659.244  ns/op
> 
> # Patched
> ThreadSleep.millis             0  avgt    5         429.535 ?     2.597  ns/op
> ThreadSleep.millis             1  avgt    5         425.209 ?     3.620  ns/op
> ThreadSleep.millis            10  avgt    5         432.416 ?     9.350  ns/op
> ThreadSleep.millis           100  avgt    5         432.867 ?     3.978  ns/op
> ThreadSleep.millis          1000  avgt    5         426.627 ?     1.064  ns/op
> ThreadSleep.millis         10000  avgt    5         427.180 ?     4.691  ns/op
> ThreadSleep.millis        100000  avgt    5         438.554 ?     4.271  ns/op
> ThreadSleep.millis       1000000  avgt    5     1054693.226 ?   323.240  ns/op
> ThreadSleep.millis      10000000  avgt    5    10056408.240 ?  1759.211  ns/op
> ThreadSleep.millis     100000000  avgt    5   100062449.780 ? 15133.808  ns/op
> ThreadSleep.millis    1000000000  avgt    5  1000066918.500 ? 15817.822  ns/op
> 
> # ========= Significant improvements for Thread.sleep(millis, nanos)
> 
> # Baseline
> ThreadSleep.millisNanos           0  avgt    5         439.163 ?     5.559  ns/op
> ThreadSleep.millisNanos           1  avgt    5     1054751.231 ?   431.842  ns/op
> ThreadSleep.millisNanos          10  avgt    5     1054640.725 ?   525.901  ns/op
> ThreadSleep.millisNanos         100  avgt    5     1054807.619 ?  1009.104  ns/op
> ThreadSleep.millisNanos        1000  avgt    5     1054894.829 ?  1946.551  ns/op
> ThreadSleep.millisNanos       10000  avgt    5     1054765.444 ?   701.873  ns/op
> ThreadSleep.millisNanos      100000  avgt    5     1054707.758 ?   619.054  ns/op
> ThreadSleep.millisNanos     1000000  avgt    5     1054802.230 ?  1294.035  ns/op
> ThreadSleep.millisNanos    10000000  avgt    5    10055265.430 ?  1184.281  ns/op
> ThreadSleep.millisNanos   100000000  avgt    5   100057484.300 ?  7960.939  ns/op
> ThreadSleep.millisNanos  1000000000  avgt    5  1000062244.700 ? 20244.067  ns/op
> 
> # Patched
> ThreadSleep.millisNanos           0  avgt    5         426.482 ?    10.284  ns/op
> ThreadSleep.millisNanos           1  avgt    5         565.819 ?     1.098  ns/op
> ThreadSleep.millisNanos          10  avgt    5         564.108 ?     3.493  ns/op
> ThreadSleep.millisNanos         100  avgt    5       53698.839 ?   942.506  ns/op
> ThreadSleep.millisNanos        1000  avgt    5       55205.929 ?   416.951  ns/op
> ThreadSleep.millisNanos       10000  avgt    5       64206.709 ?   382.213  ns/op
> ThreadSleep.millisNanos      100000  avgt    5      154477.045 ?   125.316  ns/op
> ThreadSleep.millisNanos     1000000  avgt    5     1054889.472 ?  2152.765  ns/op
> ThreadSleep.millisNanos    10000000  avgt    5    10055273.582 ?   691.628  ns/op
> ThreadSleep.millisNanos   100000000  avgt    5   100058261.300 ?  5222.946  ns/op
> ThreadSleep.millisNanos  1000000000  avgt    5  1000065434.000 ? 30213.137  ns/op
> 
> 
> MacBook 2021 (MacOS X, M1, AArch64):
> 
> 
> # ========= no regressions for Thread.sleep(millis)
> 
> # Baseline
> Benchmark                 (sleep)  Mode  Cnt           Score          Error  Units
> ThreadSleep.millis             0  avgt    5         555,871 ?      525,544  ns/op
> ThreadSleep.millis             1  avgt    5         405,761 ?      153,981  ns/op
> ThreadSleep.millis            10  avgt    5         403,906 ?      279,245  ns/op
> ThreadSleep.millis           100  avgt    5         402,787 ?      223,658  ns/op
> ThreadSleep.millis          1000  avgt    5         439,250 ?      374,150  ns/op
> ThreadSleep.millis         10000  avgt    5         435,769 ?      352,067  ns/op
> ThreadSleep.millis        100000  avgt    5        1853,664 ?     7254,716  ns/op
> ThreadSleep.millis       1000000  avgt    5     1364788,214 ?    66446,869  ns/op
> ThreadSleep.millis      10000000  avgt    5    11819681,019 ?   473810,685  ns/op
> ThreadSleep.millis     100000000  avgt    5   103536901,660 ?  1423282,032  ns/op
> ThreadSleep.millis    1000000000  avgt    5  1002995262,600 ?  6576388,880  ns/op
> 
> # Patched
> ThreadSleep.millis             0  avgt    5         662,597 ?     459,888  ns/op
> ThreadSleep.millis             1  avgt    5         433,561 ?     214,850  ns/op
> ThreadSleep.millis            10  avgt    5         388,614 ?      65,199  ns/op
> ThreadSleep.millis           100  avgt    5         436,823 ?     636,901  ns/op
> ThreadSleep.millis          1000  avgt    5         337,046 ?     129,440  ns/op
> ThreadSleep.millis         10000  avgt    5         366,557 ?     510,494  ns/op
> ThreadSleep.millis        100000  avgt    5         278,339 ?     102,443  ns/op
> ThreadSleep.millis       1000000  avgt    5     1520092,133 ?   26217,972  ns/op
> ThreadSleep.millis      10000000  avgt    5    13116509,001 ?  855508,621  ns/op
> ThreadSleep.millis     100000000  avgt    5   107010708,340 ? 1667080,292  ns/op
> ThreadSleep.millis    1000000000  avgt    5  1005412095,700 ? 6141267,753  ns/op
> 
> # ========= Significant improvements for Thread.sleep(millis, nanos)
> 
> # Baseline
> ThreadSleep.millisNanos           0  avgt    5         245,942 ?       44,338  ns/op
> ThreadSleep.millisNanos           1  avgt    5     1313354,886 ?    71820,989  ns/op
> ThreadSleep.millisNanos          10  avgt    5     1310358,568 ?    42731,583  ns/op
> ThreadSleep.millisNanos         100  avgt    5     1335221,078 ?   122031,471  ns/op
> ThreadSleep.millisNanos        1000  avgt    5     1313977,625 ?    30683,810  ns/op
> ThreadSleep.millisNanos       10000  avgt    5     1553321,472 ?    75181,324  ns/op
> ThreadSleep.millisNanos      100000  avgt    5     1553317,573 ?   132998,558  ns/op
> ThreadSleep.millisNanos     1000000  avgt    5     1544944,015 ?    41587,129  ns/op
> ThreadSleep.millisNanos    10000000  avgt    5    13228565,376 ?   902384,381  ns/op
> ThreadSleep.millisNanos   100000000  avgt    5   106866740,840 ?  2518606,524  ns/op
> ThreadSleep.millisNanos  1000000000  avgt    5  1006669020,800 ? 10961093,568  ns/op
> 
> # Patched
> ThreadSleep.millisNanos           0  avgt    5         394,716 ?     310,886  ns/op
> ThreadSleep.millisNanos           1  avgt    5        9945,543 ?     905,136  ns/op
> ThreadSleep.millisNanos          10  avgt    5        9863,605 ?     557,909  ns/op
> ThreadSleep.millisNanos         100  avgt    5        2454,862 ?     323,279  ns/op
> ThreadSleep.millisNanos        1000  avgt    5        3834,507 ?    2427,033  ns/op
> ThreadSleep.millisNanos       10000  avgt    5       16667,415 ?     508,814  ns/op
> ThreadSleep.millisNanos      100000  avgt    5      154202,589 ?     258,406  ns/op
> ThreadSleep.millisNanos     1000000  avgt    5     1557886,136 ?  192080,832  ns/op
> ThreadSleep.millisNanos    10000000  avgt    5    13077385,237 ?  887650,194  ns/op
> ThreadSleep.millisNanos   100000000  avgt    5   106225257,480 ? 3288589,410  ns/op
> ThreadSleep.millisNanos  1000000000  avgt    5  1006589558,200 ? 3677828,811  ns/op
> 
> 
> Additional testing:
>   - [x] New regression test
>   - [x] New benchmark
>   - [x] Linux x86_64 `tier1`
>   - [x] Linux AArch64 `tier1`

Are there specific factors which would make it unreasonable to implement `sleep` in terms of `parkNanos`?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13225#issuecomment-1488952226

From rriggs at openjdk.org  Wed Mar 29 16:57:48 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 29 Mar 2023 16:57:48 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity
In-Reply-To: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
Message-ID: <2hw99L82zHuf9I4l22-pcEDp5FqkIZW10uU3ql-F0No=.0886f77f-9dec-4e6d-bfc2-9887d023a875@github.com>

On Wed, 29 Mar 2023 11:28:53 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The documentation for that method clearly says the precision and accuracy are dependent on the underlying system behavior. However, it always rounds up `nanos` to 1ms when doing the actual sleep. This means users cannot do the micro-second precision sleeps, even when the underlying platform allows it. Sub-millisecond sleeps are useful to build interesting primitives, like the rate limiters that run with >1000 RPS.
> 
> When faced with this, some users reach for more awkward APIs like `java.util.concurrent.locks.LockSupport.parkNanos`. The use of that API for sleeps is not in line with its intent, and while it "seems to work", it might have interesting interactions with other uses of `LockSupport`. Additionally, these "sleeps" are no longer visible to monitoring tools as "normal sleeps", e.g. as `Thread.sleep` events. Therefore, it would be prudent to improve current `Thread.sleep(millis, nanos)` for sub-millisecond granularity. 
> 
> Fortunately, the underlying code is almost ready for this, at least on POSIX side. I skipped Windows paths, because its timers are still no good. Note that on both Linux and MacOS timers oversleep by about 50us. I have a few ideas how to improve the accuracy for them, which would be a topic for a separate PR.
> 
> Motivational improvements on new benchmark below:
> 
> m6g.9xlarge (Linux, Xeon, x86_64):
> 
> 
> Benchmark                 (sleep)  Mode  Cnt           Score       Error  Units
> 
> # ========= no regressions for Thread.sleep(millis)
> 
> # Baseline
> ThreadSleep.millis             0  avgt    5         463.606 ?     8.256  ns/op
> ThreadSleep.millis             1  avgt    5         459.434 ?     0.453  ns/op
> ThreadSleep.millis            10  avgt    5         462.828 ?     1.283  ns/op
> ThreadSleep.millis           100  avgt    5         459.495 ?     3.244  ns/op
> ThreadSleep.millis          1000  avgt    5         457.962 ?     5.769  ns/op
> ThreadSleep.millis         10000  avgt    5         457.960 ?     1.195  ns/op
> ThreadSleep.millis        100000  avgt    5         459.197 ?     3.054  ns/op
> ThreadSleep.millis       1000000  avgt    5     1058342.873 ?   304.169  ns/op
> ThreadSleep.millis      10000000  avgt    5    10059945.148 ?  1642.411  ns/op
> ThreadSleep.millis     100000000  avgt    5   100062181.340 ?  1863.186  ns/op
> ThreadSleep.millis    1000000000  avgt    5  1000070015.600 ? 11379.631  ns/op
> 
> # Patched
> ThreadSleep.millis             0  avgt    5         461.295 ?     6.700  ns/op
> ThreadSleep.millis             1  avgt    5         463.383 ?     3.065  ns/op
> ThreadSleep.millis            10  avgt    5         468.109 ?     1.607  ns/op
> ThreadSleep.millis           100  avgt    5         467.316 ?     0.270  ns/op
> ThreadSleep.millis          1000  avgt    5         461.999 ?     2.341  ns/op
> ThreadSleep.millis         10000  avgt    5         465.075 ?     0.324  ns/op
> ThreadSleep.millis        100000  avgt    5         462.588 ?     5.321  ns/op
> ThreadSleep.millis       1000000  avgt    5     1058285.440 ?   409.376  ns/op
> ThreadSleep.millis      10000000  avgt    5    10060437.490 ?   177.754  ns/op
> ThreadSleep.millis     100000000  avgt    5   100060665.980 ?  1167.514  ns/op
> ThreadSleep.millis    1000000000  avgt    5  1000071917.300 ? 17438.906  ns/op
> 
> # ========= Significant improvements for Thread.sleep(millis, nanos)
> 
> # Baseline
> ThreadSleep.millisNanos           0  avgt    5         462.831 ?     0.251  ns/op
> ThreadSleep.millisNanos           1  avgt    5     1058708.668 ?   960.683  ns/op
> ThreadSleep.millisNanos          10  avgt    5     1058364.414 ?   197.700  ns/op
> ThreadSleep.millisNanos         100  avgt    5     1058451.889 ?   561.979  ns/op
> ThreadSleep.millisNanos        1000  avgt    5     1058372.010 ?    96.867  ns/op
> ThreadSleep.millisNanos       10000  avgt    5     1058354.100 ?   297.148  ns/op
> ThreadSleep.millisNanos      100000  avgt    5     1058485.092 ?  1093.340  ns/op
> ThreadSleep.millisNanos     1000000  avgt    5     1059004.036 ?  1899.950  ns/op
> ThreadSleep.millisNanos    10000000  avgt    5    10059733.302 ?  1725.908  ns/op
> ThreadSleep.millisNanos   100000000  avgt    5   100063327.840 ?  6244.805  ns/op
> ThreadSleep.millisNanos  1000000000  avgt    5  1000074542.300 ? 17898.173  ns/op
> 
> # Patched
> ThreadSleep.millisNanos           0  avgt    5         467.968 ?     9.202  ns/op
> ThreadSleep.millisNanos           1  avgt    5         579.448 ?     1.363  ns/op
> ThreadSleep.millisNanos          10  avgt    5         577.656 ?     0.278  ns/op
> ThreadSleep.millisNanos         100  avgt    5       58092.815 ?  2410.401  ns/op
> ThreadSleep.millisNanos        1000  avgt    5       58592.249 ?   189.232  ns/op
> ThreadSleep.millisNanos       10000  avgt    5       67668.688 ?   591.365  ns/op
> ThreadSleep.millisNanos      100000  avgt    5      158143.164 ?  2281.540  ns/op
> ThreadSleep.millisNanos     1000000  avgt    5     1058508.682 ?   155.767  ns/op
> ThreadSleep.millisNanos    10000000  avgt    5    10059979.272 ?  1095.207  ns/op
> ThreadSleep.millisNanos   100000000  avgt    5   100066844.180 ?  4287.440  ns/op
> ThreadSleep.millisNanos  1000000000  avgt    5  1000075313.100 ?  9665.656  ns/op
> 
> 
> m6g.4xlarge (Linux, Graviton, AArch64):
> 
> 
> # ========= no regressions for Thread.sleep(millis)
> 
> # Baseline
> ThreadSleep.millis             0  avgt    5         429.403 ?    24.947  ns/op
> ThreadSleep.millis             1  avgt    5         427.533 ?     7.969  ns/op
> ThreadSleep.millis            10  avgt    5         438.464 ?    10.277  ns/op
> ThreadSleep.millis           100  avgt    5         425.626 ?     3.371  ns/op
> ThreadSleep.millis          1000  avgt    5         426.465 ?     4.501  ns/op
> ThreadSleep.millis         10000  avgt    5         427.235 ?     6.916  ns/op
> ThreadSleep.millis        100000  avgt    5         430.311 ?     4.073  ns/op
> ThreadSleep.millis       1000000  avgt    5     1054808.881 ?   469.409  ns/op
> ThreadSleep.millis      10000000  avgt    5    10055497.206 ?  2123.591  ns/op
> ThreadSleep.millis     100000000  avgt    5   100059355.520 ? 11597.426  ns/op
> ThreadSleep.millis    1000000000  avgt    5  1000073145.400 ?  7659.244  ns/op
> 
> # Patched
> ThreadSleep.millis             0  avgt    5         429.535 ?     2.597  ns/op
> ThreadSleep.millis             1  avgt    5         425.209 ?     3.620  ns/op
> ThreadSleep.millis            10  avgt    5         432.416 ?     9.350  ns/op
> ThreadSleep.millis           100  avgt    5         432.867 ?     3.978  ns/op
> ThreadSleep.millis          1000  avgt    5         426.627 ?     1.064  ns/op
> ThreadSleep.millis         10000  avgt    5         427.180 ?     4.691  ns/op
> ThreadSleep.millis        100000  avgt    5         438.554 ?     4.271  ns/op
> ThreadSleep.millis       1000000  avgt    5     1054693.226 ?   323.240  ns/op
> ThreadSleep.millis      10000000  avgt    5    10056408.240 ?  1759.211  ns/op
> ThreadSleep.millis     100000000  avgt    5   100062449.780 ? 15133.808  ns/op
> ThreadSleep.millis    1000000000  avgt    5  1000066918.500 ? 15817.822  ns/op
> 
> # ========= Significant improvements for Thread.sleep(millis, nanos)
> 
> # Baseline
> ThreadSleep.millisNanos           0  avgt    5         439.163 ?     5.559  ns/op
> ThreadSleep.millisNanos           1  avgt    5     1054751.231 ?   431.842  ns/op
> ThreadSleep.millisNanos          10  avgt    5     1054640.725 ?   525.901  ns/op
> ThreadSleep.millisNanos         100  avgt    5     1054807.619 ?  1009.104  ns/op
> ThreadSleep.millisNanos        1000  avgt    5     1054894.829 ?  1946.551  ns/op
> ThreadSleep.millisNanos       10000  avgt    5     1054765.444 ?   701.873  ns/op
> ThreadSleep.millisNanos      100000  avgt    5     1054707.758 ?   619.054  ns/op
> ThreadSleep.millisNanos     1000000  avgt    5     1054802.230 ?  1294.035  ns/op
> ThreadSleep.millisNanos    10000000  avgt    5    10055265.430 ?  1184.281  ns/op
> ThreadSleep.millisNanos   100000000  avgt    5   100057484.300 ?  7960.939  ns/op
> ThreadSleep.millisNanos  1000000000  avgt    5  1000062244.700 ? 20244.067  ns/op
> 
> # Patched
> ThreadSleep.millisNanos           0  avgt    5         426.482 ?    10.284  ns/op
> ThreadSleep.millisNanos           1  avgt    5         565.819 ?     1.098  ns/op
> ThreadSleep.millisNanos          10  avgt    5         564.108 ?     3.493  ns/op
> ThreadSleep.millisNanos         100  avgt    5       53698.839 ?   942.506  ns/op
> ThreadSleep.millisNanos        1000  avgt    5       55205.929 ?   416.951  ns/op
> ThreadSleep.millisNanos       10000  avgt    5       64206.709 ?   382.213  ns/op
> ThreadSleep.millisNanos      100000  avgt    5      154477.045 ?   125.316  ns/op
> ThreadSleep.millisNanos     1000000  avgt    5     1054889.472 ?  2152.765  ns/op
> ThreadSleep.millisNanos    10000000  avgt    5    10055273.582 ?   691.628  ns/op
> ThreadSleep.millisNanos   100000000  avgt    5   100058261.300 ?  5222.946  ns/op
> ThreadSleep.millisNanos  1000000000  avgt    5  1000065434.000 ? 30213.137  ns/op
> 
> 
> MacBook 2021 (MacOS X, M1, AArch64):
> 
> 
> # ========= no regressions for Thread.sleep(millis)
> 
> # Baseline
> Benchmark                 (sleep)  Mode  Cnt           Score          Error  Units
> ThreadSleep.millis             0  avgt    5         555,871 ?      525,544  ns/op
> ThreadSleep.millis             1  avgt    5         405,761 ?      153,981  ns/op
> ThreadSleep.millis            10  avgt    5         403,906 ?      279,245  ns/op
> ThreadSleep.millis           100  avgt    5         402,787 ?      223,658  ns/op
> ThreadSleep.millis          1000  avgt    5         439,250 ?      374,150  ns/op
> ThreadSleep.millis         10000  avgt    5         435,769 ?      352,067  ns/op
> ThreadSleep.millis        100000  avgt    5        1853,664 ?     7254,716  ns/op
> ThreadSleep.millis       1000000  avgt    5     1364788,214 ?    66446,869  ns/op
> ThreadSleep.millis      10000000  avgt    5    11819681,019 ?   473810,685  ns/op
> ThreadSleep.millis     100000000  avgt    5   103536901,660 ?  1423282,032  ns/op
> ThreadSleep.millis    1000000000  avgt    5  1002995262,600 ?  6576388,880  ns/op
> 
> # Patched
> ThreadSleep.millis             0  avgt    5         662,597 ?     459,888  ns/op
> ThreadSleep.millis             1  avgt    5         433,561 ?     214,850  ns/op
> ThreadSleep.millis            10  avgt    5         388,614 ?      65,199  ns/op
> ThreadSleep.millis           100  avgt    5         436,823 ?     636,901  ns/op
> ThreadSleep.millis          1000  avgt    5         337,046 ?     129,440  ns/op
> ThreadSleep.millis         10000  avgt    5         366,557 ?     510,494  ns/op
> ThreadSleep.millis        100000  avgt    5         278,339 ?     102,443  ns/op
> ThreadSleep.millis       1000000  avgt    5     1520092,133 ?   26217,972  ns/op
> ThreadSleep.millis      10000000  avgt    5    13116509,001 ?  855508,621  ns/op
> ThreadSleep.millis     100000000  avgt    5   107010708,340 ? 1667080,292  ns/op
> ThreadSleep.millis    1000000000  avgt    5  1005412095,700 ? 6141267,753  ns/op
> 
> # ========= Significant improvements for Thread.sleep(millis, nanos)
> 
> # Baseline
> ThreadSleep.millisNanos           0  avgt    5         245,942 ?       44,338  ns/op
> ThreadSleep.millisNanos           1  avgt    5     1313354,886 ?    71820,989  ns/op
> ThreadSleep.millisNanos          10  avgt    5     1310358,568 ?    42731,583  ns/op
> ThreadSleep.millisNanos         100  avgt    5     1335221,078 ?   122031,471  ns/op
> ThreadSleep.millisNanos        1000  avgt    5     1313977,625 ?    30683,810  ns/op
> ThreadSleep.millisNanos       10000  avgt    5     1553321,472 ?    75181,324  ns/op
> ThreadSleep.millisNanos      100000  avgt    5     1553317,573 ?   132998,558  ns/op
> ThreadSleep.millisNanos     1000000  avgt    5     1544944,015 ?    41587,129  ns/op
> ThreadSleep.millisNanos    10000000  avgt    5    13228565,376 ?   902384,381  ns/op
> ThreadSleep.millisNanos   100000000  avgt    5   106866740,840 ?  2518606,524  ns/op
> ThreadSleep.millisNanos  1000000000  avgt    5  1006669020,800 ? 10961093,568  ns/op
> 
> # Patched
> ThreadSleep.millisNanos           0  avgt    5         394,716 ?     310,886  ns/op
> ThreadSleep.millisNanos           1  avgt    5        9945,543 ?     905,136  ns/op
> ThreadSleep.millisNanos          10  avgt    5        9863,605 ?     557,909  ns/op
> ThreadSleep.millisNanos         100  avgt    5        2454,862 ?     323,279  ns/op
> ThreadSleep.millisNanos        1000  avgt    5        3834,507 ?    2427,033  ns/op
> ThreadSleep.millisNanos       10000  avgt    5       16667,415 ?     508,814  ns/op
> ThreadSleep.millisNanos      100000  avgt    5      154202,589 ?     258,406  ns/op
> ThreadSleep.millisNanos     1000000  avgt    5     1557886,136 ?  192080,832  ns/op
> ThreadSleep.millisNanos    10000000  avgt    5    13077385,237 ?  887650,194  ns/op
> ThreadSleep.millisNanos   100000000  avgt    5   106225257,480 ? 3288589,410  ns/op
> ThreadSleep.millisNanos  1000000000  avgt    5  1006589558,200 ? 3677828,811  ns/op
> 
> 
> Additional testing:
>   - [x] New regression test
>   - [x] New benchmark
>   - [x] Linux x86_64 `tier1`
>   - [x] Linux AArch64 `tier1`

@shipilev Given that Github includes the entire problem description in every email, can you move the benchmark stats to a comment and out of the description.  Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13225#issuecomment-1488962749

From mdoerr at openjdk.org  Wed Mar 29 16:59:44 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 29 Mar 2023 16:59:44 GMT
Subject: RFR: 8302328: [s390x] Simplify asm_assert definition [v2]
In-Reply-To: <Cwc2cqWiGcKQspZ1EwN4ZilNfre3wYA8WDP9kiHZjAw=.d03553b2-ea9b-4821-8576-9014ee12c22a@github.com>
References: <51VAVmniXPGE4sgcdw2AnU1hqZn2fVJRyDEbrt3AyyU=.b70f59dc-8397-4da4-b36b-266766434b19@github.com>
 <Cwc2cqWiGcKQspZ1EwN4ZilNfre3wYA8WDP9kiHZjAw=.d03553b2-ea9b-4821-8576-9014ee12c22a@github.com>
Message-ID: <lb15RRQ51cS8W6AvlZ6bHAQMTnns0nplGZlhffTutpU=.73b43052-a99b-4c7c-940d-a688ce5e7661@github.com>

On Wed, 29 Mar 2023 16:50:32 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> This PR cleanups some assert statements and specifies branch condition at calling site itself. Remaining asm_assert methods are inlined as well.
>
> Amit Kumar has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - added id to illtrap
>  - address lutz comment & revert inlining
>  - Revert "inline asm_assert"
>  - Revert "inlined assert method"
>  - Revert "added inline keyword before function implementation"

src/hotspot/cpu/s390/stubRoutines_s390.cpp line 58:

> 56:     __ z_cgr(table, Z_R0);  // safety net
> 57:     __ z_bre(L);
> 58:     __ asm_assert(Assembler::bcondEqual, "crc_table: external word relocation required for load_absolute_address", 0x33);

How should this `asm_assert` ever get hit? It's preceded by a `bre.`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12822#discussion_r1152235506

From amitkumar at openjdk.org  Wed Mar 29 16:59:45 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Wed, 29 Mar 2023 16:59:45 GMT
Subject: RFR: 8302328: [s390x] Simplify asm_assert definition [v2]
In-Reply-To: <lb15RRQ51cS8W6AvlZ6bHAQMTnns0nplGZlhffTutpU=.73b43052-a99b-4c7c-940d-a688ce5e7661@github.com>
References: <51VAVmniXPGE4sgcdw2AnU1hqZn2fVJRyDEbrt3AyyU=.b70f59dc-8397-4da4-b36b-266766434b19@github.com>
 <Cwc2cqWiGcKQspZ1EwN4ZilNfre3wYA8WDP9kiHZjAw=.d03553b2-ea9b-4821-8576-9014ee12c22a@github.com>
 <lb15RRQ51cS8W6AvlZ6bHAQMTnns0nplGZlhffTutpU=.73b43052-a99b-4c7c-940d-a688ce5e7661@github.com>
Message-ID: <OChqVIWB8CGX-49dJXTCPjGfccsWinhVzFZNPMaeM-A=.e14d731f-5920-4208-8478-ab817d367e43@github.com>

On Wed, 29 Mar 2023 16:53:39 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Amit Kumar has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - added id to illtrap
>>  - address lutz comment & revert inlining
>>  - Revert "inline asm_assert"
>>  - Revert "inlined assert method"
>>  - Revert "added inline keyword before function implementation"
>
> src/hotspot/cpu/s390/stubRoutines_s390.cpp line 58:
> 
>> 56:     __ z_cgr(table, Z_R0);  // safety net
>> 57:     __ z_bre(L);
>> 58:     __ asm_assert(Assembler::bcondEqual, "crc_table: external word relocation required for load_absolute_address", 0x33);
> 
> How should this `asm_assert` ever get hit? It's preceded by a `bre.`

This was requested change (initially it was not part of this PR).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12822#discussion_r1152238977

From amitkumar at openjdk.org  Wed Mar 29 16:59:47 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Wed, 29 Mar 2023 16:59:47 GMT
Subject: RFR: 8302328: [s390x] Simplify asm_assert definition [v2]
In-Reply-To: <zdj8oUdL3jqpeYY4rmGy5pxfTFVmQJLPuPvcsgEx87A=.4050a967-103d-4982-b4c9-a33d0e72c03f@github.com>
References: <51VAVmniXPGE4sgcdw2AnU1hqZn2fVJRyDEbrt3AyyU=.b70f59dc-8397-4da4-b36b-266766434b19@github.com>
 <zdj8oUdL3jqpeYY4rmGy5pxfTFVmQJLPuPvcsgEx87A=.4050a967-103d-4982-b4c9-a33d0e72c03f@github.com>
Message-ID: <AuqTo8l6_TVprsw6FDQh7Xv5H1Bmrd2NtQJs4OcGBTQ=.b2639fb4-95e0-43dc-ad62-35ec9e58cbbe@github.com>

On Fri, 17 Mar 2023 08:56:01 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> Amit Kumar has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - added id to illtrap
>>  - address lutz comment & revert inlining
>>  - Revert "inline asm_assert"
>>  - Revert "inlined assert method"
>>  - Revert "added inline keyword before function implementation"
>
> src/hotspot/cpu/s390/stubRoutines_s390.cpp line 58:
> 
>> 56:     __ z_cgr(table, Z_R0);  // safety net
>> 57:     __ z_bre(L);
>> 58:     __ z_illtrap();
> 
> You should move z_illtrap() after asm_assert(). Not your fault!

@TheRealMDoerr here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12822#discussion_r1152239779

From kbarrett at openjdk.org  Wed Mar 29 17:13:15 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 29 Mar 2023 17:13:15 GMT
Subject: RFR: 8304759: Add BitMap iterators [v3]
In-Reply-To: <4FHjg8u1ix7KodqaJkU5q-tnYRDAq3GhRV0z7ArpYGU=.7434363a-1bcb-467f-9225-0e97d4ade998@github.com>
References: <4FHjg8u1ix7KodqaJkU5q-tnYRDAq3GhRV0z7ArpYGU=.7434363a-1bcb-467f-9225-0e97d4ade998@github.com>
Message-ID: <fornNl5wtqVJ9j7MVP2Jv7-ngT3MXBxuenX4mSCX-E0=.7f821984-7bdf-4f7c-b925-cac7f10ffe14@github.com>

> Please review this change which adds iteration over the set bit positions of a
> BitMap via an iterator object.  This is in addition to the existing iterate()
> and reverse_iterate() functions that apply a function to the set bit positions.
> 
> There are two iterator classes: BitMap::Iterator and BitMap::ReverseIterator.
> Iteration uses a single, self-contained iterator object, rather than a pair of
> iterator objects as is done with standard library iterators.  This is because
> the desired form of iteration over bitmaps doesn't lend itself well to the
> begin/end pair style.  Typical usage is something like
> 
> 
> for (BitMap::Iterator it{map, beg, end}; !it.is_empty(); it.step()) {
>   ... use it.index()
> }
> 
> 
> However, as a syntactic convenience, these iterator classes provide begin()
> and end() member functions returning objects supporting the requirements for
> range-based for loops.  By constraining these objects to this usage we can
> cope with the "iterator pair" requirements.  Usage is something like
> 
> 
> for (BitMap::idx_t index : BitMap::Iterator{map, beg, end}) {
>   ...
> }
> 
> 
> Testing:
> mach5 tier1, which includes running the updated gtests on all Oracle-supported
> platforms.

Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:

  improve/correct comments for IteratorImpl

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13184/files
  - new: https://git.openjdk.org/jdk/pull/13184/files/379dfa82..2ea0b16b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13184&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13184&range=01-02

  Stats: 13 lines in 1 file changed: 12 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13184.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13184/head:pull/13184

PR: https://git.openjdk.org/jdk/pull/13184

From shade at openjdk.org  Wed Mar 29 17:13:28 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 29 Mar 2023 17:13:28 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity
In-Reply-To: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
Message-ID: <1pHVHcAs9DI3b3aAElZ2fduWNb7hVhxLtcDOwzQ7k-0=.c01caf59-b05e-4055-a529-b1be043deaab@github.com>

On Wed, 29 Mar 2023 11:28:53 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The documentation for that method clearly says the precision and accuracy are dependent on the underlying system behavior. However, it always rounds up `nanos` to 1ms when doing the actual sleep. This means users cannot do the micro-second precision sleeps, even when the underlying platform allows it. Sub-millisecond sleeps are useful to build interesting primitives, like the rate limiters that run with >1000 RPS.
> 
> When faced with this, some users reach for more awkward APIs like `java.util.concurrent.locks.LockSupport.parkNanos`. The use of that API for sleeps is not in line with its intent, and while it "seems to work", it might have interesting interactions with other uses of `LockSupport`. Additionally, these "sleeps" are no longer visible to monitoring tools as "normal sleeps", e.g. as `Thread.sleep` events. Therefore, it would be prudent to improve current `Thread.sleep(millis, nanos)` for sub-millisecond granularity. 
> 
> Fortunately, the underlying code is almost ready for this, at least on POSIX side. I skipped Windows paths, because its timers are still no good. Note that on both Linux and MacOS timers oversleep by about 50us. I have a few ideas how to improve the accuracy for them, which would be a topic for a separate PR.
> 
> Additional testing:
>   - [x] New regression test
>   - [x] New benchmark
>   - [x] Linux x86_64 `tier1`
>   - [x] Linux AArch64 `tier1`

Motivational improvements on new benchmark below:

m6g.9xlarge (Linux, Xeon, x86_64):


Benchmark                 (sleep)  Mode  Cnt           Score       Error  Units

# ========= no regressions for Thread.sleep(millis)

# Baseline
ThreadSleep.millis             0  avgt    5         463.606 ?     8.256  ns/op
ThreadSleep.millis             1  avgt    5         459.434 ?     0.453  ns/op
ThreadSleep.millis            10  avgt    5         462.828 ?     1.283  ns/op
ThreadSleep.millis           100  avgt    5         459.495 ?     3.244  ns/op
ThreadSleep.millis          1000  avgt    5         457.962 ?     5.769  ns/op
ThreadSleep.millis         10000  avgt    5         457.960 ?     1.195  ns/op
ThreadSleep.millis        100000  avgt    5         459.197 ?     3.054  ns/op
ThreadSleep.millis       1000000  avgt    5     1058342.873 ?   304.169  ns/op
ThreadSleep.millis      10000000  avgt    5    10059945.148 ?  1642.411  ns/op
ThreadSleep.millis     100000000  avgt    5   100062181.340 ?  1863.186  ns/op
ThreadSleep.millis    1000000000  avgt    5  1000070015.600 ? 11379.631  ns/op

# Patched
ThreadSleep.millis             0  avgt    5         461.295 ?     6.700  ns/op
ThreadSleep.millis             1  avgt    5         463.383 ?     3.065  ns/op
ThreadSleep.millis            10  avgt    5         468.109 ?     1.607  ns/op
ThreadSleep.millis           100  avgt    5         467.316 ?     0.270  ns/op
ThreadSleep.millis          1000  avgt    5         461.999 ?     2.341  ns/op
ThreadSleep.millis         10000  avgt    5         465.075 ?     0.324  ns/op
ThreadSleep.millis        100000  avgt    5         462.588 ?     5.321  ns/op
ThreadSleep.millis       1000000  avgt    5     1058285.440 ?   409.376  ns/op
ThreadSleep.millis      10000000  avgt    5    10060437.490 ?   177.754  ns/op
ThreadSleep.millis     100000000  avgt    5   100060665.980 ?  1167.514  ns/op
ThreadSleep.millis    1000000000  avgt    5  1000071917.300 ? 17438.906  ns/op

# ========= Significant improvements for Thread.sleep(millis, nanos)

# Baseline
ThreadSleep.millisNanos           0  avgt    5         462.831 ?     0.251  ns/op
ThreadSleep.millisNanos           1  avgt    5     1058708.668 ?   960.683  ns/op
ThreadSleep.millisNanos          10  avgt    5     1058364.414 ?   197.700  ns/op
ThreadSleep.millisNanos         100  avgt    5     1058451.889 ?   561.979  ns/op
ThreadSleep.millisNanos        1000  avgt    5     1058372.010 ?    96.867  ns/op
ThreadSleep.millisNanos       10000  avgt    5     1058354.100 ?   297.148  ns/op
ThreadSleep.millisNanos      100000  avgt    5     1058485.092 ?  1093.340  ns/op
ThreadSleep.millisNanos     1000000  avgt    5     1059004.036 ?  1899.950  ns/op
ThreadSleep.millisNanos    10000000  avgt    5    10059733.302 ?  1725.908  ns/op
ThreadSleep.millisNanos   100000000  avgt    5   100063327.840 ?  6244.805  ns/op
ThreadSleep.millisNanos  1000000000  avgt    5  1000074542.300 ? 17898.173  ns/op

# Patched
ThreadSleep.millisNanos           0  avgt    5         467.968 ?     9.202  ns/op
ThreadSleep.millisNanos           1  avgt    5         579.448 ?     1.363  ns/op
ThreadSleep.millisNanos          10  avgt    5         577.656 ?     0.278  ns/op
ThreadSleep.millisNanos         100  avgt    5       58092.815 ?  2410.401  ns/op
ThreadSleep.millisNanos        1000  avgt    5       58592.249 ?   189.232  ns/op
ThreadSleep.millisNanos       10000  avgt    5       67668.688 ?   591.365  ns/op
ThreadSleep.millisNanos      100000  avgt    5      158143.164 ?  2281.540  ns/op
ThreadSleep.millisNanos     1000000  avgt    5     1058508.682 ?   155.767  ns/op
ThreadSleep.millisNanos    10000000  avgt    5    10059979.272 ?  1095.207  ns/op
ThreadSleep.millisNanos   100000000  avgt    5   100066844.180 ?  4287.440  ns/op
ThreadSleep.millisNanos  1000000000  avgt    5  1000075313.100 ?  9665.656  ns/op


m6g.4xlarge (Linux, Graviton, AArch64):


# ========= no regressions for Thread.sleep(millis)

# Baseline
ThreadSleep.millis             0  avgt    5         429.403 ?    24.947  ns/op
ThreadSleep.millis             1  avgt    5         427.533 ?     7.969  ns/op
ThreadSleep.millis            10  avgt    5         438.464 ?    10.277  ns/op
ThreadSleep.millis           100  avgt    5         425.626 ?     3.371  ns/op
ThreadSleep.millis          1000  avgt    5         426.465 ?     4.501  ns/op
ThreadSleep.millis         10000  avgt    5         427.235 ?     6.916  ns/op
ThreadSleep.millis        100000  avgt    5         430.311 ?     4.073  ns/op
ThreadSleep.millis       1000000  avgt    5     1054808.881 ?   469.409  ns/op
ThreadSleep.millis      10000000  avgt    5    10055497.206 ?  2123.591  ns/op
ThreadSleep.millis     100000000  avgt    5   100059355.520 ? 11597.426  ns/op
ThreadSleep.millis    1000000000  avgt    5  1000073145.400 ?  7659.244  ns/op

# Patched
ThreadSleep.millis             0  avgt    5         429.535 ?     2.597  ns/op
ThreadSleep.millis             1  avgt    5         425.209 ?     3.620  ns/op
ThreadSleep.millis            10  avgt    5         432.416 ?     9.350  ns/op
ThreadSleep.millis           100  avgt    5         432.867 ?     3.978  ns/op
ThreadSleep.millis          1000  avgt    5         426.627 ?     1.064  ns/op
ThreadSleep.millis         10000  avgt    5         427.180 ?     4.691  ns/op
ThreadSleep.millis        100000  avgt    5         438.554 ?     4.271  ns/op
ThreadSleep.millis       1000000  avgt    5     1054693.226 ?   323.240  ns/op
ThreadSleep.millis      10000000  avgt    5    10056408.240 ?  1759.211  ns/op
ThreadSleep.millis     100000000  avgt    5   100062449.780 ? 15133.808  ns/op
ThreadSleep.millis    1000000000  avgt    5  1000066918.500 ? 15817.822  ns/op

# ========= Significant improvements for Thread.sleep(millis, nanos)

# Baseline
ThreadSleep.millisNanos           0  avgt    5         439.163 ?     5.559  ns/op
ThreadSleep.millisNanos           1  avgt    5     1054751.231 ?   431.842  ns/op
ThreadSleep.millisNanos          10  avgt    5     1054640.725 ?   525.901  ns/op
ThreadSleep.millisNanos         100  avgt    5     1054807.619 ?  1009.104  ns/op
ThreadSleep.millisNanos        1000  avgt    5     1054894.829 ?  1946.551  ns/op
ThreadSleep.millisNanos       10000  avgt    5     1054765.444 ?   701.873  ns/op
ThreadSleep.millisNanos      100000  avgt    5     1054707.758 ?   619.054  ns/op
ThreadSleep.millisNanos     1000000  avgt    5     1054802.230 ?  1294.035  ns/op
ThreadSleep.millisNanos    10000000  avgt    5    10055265.430 ?  1184.281  ns/op
ThreadSleep.millisNanos   100000000  avgt    5   100057484.300 ?  7960.939  ns/op
ThreadSleep.millisNanos  1000000000  avgt    5  1000062244.700 ? 20244.067  ns/op

# Patched
ThreadSleep.millisNanos           0  avgt    5         426.482 ?    10.284  ns/op
ThreadSleep.millisNanos           1  avgt    5         565.819 ?     1.098  ns/op
ThreadSleep.millisNanos          10  avgt    5         564.108 ?     3.493  ns/op
ThreadSleep.millisNanos         100  avgt    5       53698.839 ?   942.506  ns/op
ThreadSleep.millisNanos        1000  avgt    5       55205.929 ?   416.951  ns/op
ThreadSleep.millisNanos       10000  avgt    5       64206.709 ?   382.213  ns/op
ThreadSleep.millisNanos      100000  avgt    5      154477.045 ?   125.316  ns/op
ThreadSleep.millisNanos     1000000  avgt    5     1054889.472 ?  2152.765  ns/op
ThreadSleep.millisNanos    10000000  avgt    5    10055273.582 ?   691.628  ns/op
ThreadSleep.millisNanos   100000000  avgt    5   100058261.300 ?  5222.946  ns/op
ThreadSleep.millisNanos  1000000000  avgt    5  1000065434.000 ? 30213.137  ns/op


MacBook 2021 (MacOS X, M1, AArch64):


# ========= no regressions for Thread.sleep(millis)

# Baseline
Benchmark                 (sleep)  Mode  Cnt           Score          Error  Units
ThreadSleep.millis             0  avgt    5         555,871 ?      525,544  ns/op
ThreadSleep.millis             1  avgt    5         405,761 ?      153,981  ns/op
ThreadSleep.millis            10  avgt    5         403,906 ?      279,245  ns/op
ThreadSleep.millis           100  avgt    5         402,787 ?      223,658  ns/op
ThreadSleep.millis          1000  avgt    5         439,250 ?      374,150  ns/op
ThreadSleep.millis         10000  avgt    5         435,769 ?      352,067  ns/op
ThreadSleep.millis        100000  avgt    5        1853,664 ?     7254,716  ns/op
ThreadSleep.millis       1000000  avgt    5     1364788,214 ?    66446,869  ns/op
ThreadSleep.millis      10000000  avgt    5    11819681,019 ?   473810,685  ns/op
ThreadSleep.millis     100000000  avgt    5   103536901,660 ?  1423282,032  ns/op
ThreadSleep.millis    1000000000  avgt    5  1002995262,600 ?  6576388,880  ns/op

# Patched
ThreadSleep.millis             0  avgt    5         662,597 ?     459,888  ns/op
ThreadSleep.millis             1  avgt    5         433,561 ?     214,850  ns/op
ThreadSleep.millis            10  avgt    5         388,614 ?      65,199  ns/op
ThreadSleep.millis           100  avgt    5         436,823 ?     636,901  ns/op
ThreadSleep.millis          1000  avgt    5         337,046 ?     129,440  ns/op
ThreadSleep.millis         10000  avgt    5         366,557 ?     510,494  ns/op
ThreadSleep.millis        100000  avgt    5         278,339 ?     102,443  ns/op
ThreadSleep.millis       1000000  avgt    5     1520092,133 ?   26217,972  ns/op
ThreadSleep.millis      10000000  avgt    5    13116509,001 ?  855508,621  ns/op
ThreadSleep.millis     100000000  avgt    5   107010708,340 ? 1667080,292  ns/op
ThreadSleep.millis    1000000000  avgt    5  1005412095,700 ? 6141267,753  ns/op

# ========= Significant improvements for Thread.sleep(millis, nanos)

# Baseline
ThreadSleep.millisNanos           0  avgt    5         245,942 ?       44,338  ns/op
ThreadSleep.millisNanos           1  avgt    5     1313354,886 ?    71820,989  ns/op
ThreadSleep.millisNanos          10  avgt    5     1310358,568 ?    42731,583  ns/op
ThreadSleep.millisNanos         100  avgt    5     1335221,078 ?   122031,471  ns/op
ThreadSleep.millisNanos        1000  avgt    5     1313977,625 ?    30683,810  ns/op
ThreadSleep.millisNanos       10000  avgt    5     1553321,472 ?    75181,324  ns/op
ThreadSleep.millisNanos      100000  avgt    5     1553317,573 ?   132998,558  ns/op
ThreadSleep.millisNanos     1000000  avgt    5     1544944,015 ?    41587,129  ns/op
ThreadSleep.millisNanos    10000000  avgt    5    13228565,376 ?   902384,381  ns/op
ThreadSleep.millisNanos   100000000  avgt    5   106866740,840 ?  2518606,524  ns/op
ThreadSleep.millisNanos  1000000000  avgt    5  1006669020,800 ? 10961093,568  ns/op

# Patched
ThreadSleep.millisNanos           0  avgt    5         394,716 ?     310,886  ns/op
ThreadSleep.millisNanos           1  avgt    5        9945,543 ?     905,136  ns/op
ThreadSleep.millisNanos          10  avgt    5        9863,605 ?     557,909  ns/op
ThreadSleep.millisNanos         100  avgt    5        2454,862 ?     323,279  ns/op
ThreadSleep.millisNanos        1000  avgt    5        3834,507 ?    2427,033  ns/op
ThreadSleep.millisNanos       10000  avgt    5       16667,415 ?     508,814  ns/op
ThreadSleep.millisNanos      100000  avgt    5      154202,589 ?     258,406  ns/op
ThreadSleep.millisNanos     1000000  avgt    5     1557886,136 ?  192080,832  ns/op
ThreadSleep.millisNanos    10000000  avgt    5    13077385,237 ?  887650,194  ns/op
ThreadSleep.millisNanos   100000000  avgt    5   106225257,480 ? 3288589,410  ns/op
ThreadSleep.millisNanos  1000000000  avgt    5  1006589558,200 ? 3677828,811  ns/op

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13225#issuecomment-1488989224

From shade at openjdk.org  Wed Mar 29 17:20:32 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 29 Mar 2023 17:20:32 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity
In-Reply-To: <SZnG5gsawcOMCcQD-rPAOZwfX-Bi2HERjXXoGqNnewA=.48e6e59e-51ec-4a2b-8236-2885a291706a@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
 <SZnG5gsawcOMCcQD-rPAOZwfX-Bi2HERjXXoGqNnewA=.48e6e59e-51ec-4a2b-8236-2885a291706a@github.com>
Message-ID: <4pbTAzlahWgsX0rZFLkvHBspPsH3f5sywPAw_J910xc=.459db480-16d3-47d0-a455-5c4eec0c0639@github.com>

On Wed, 29 Mar 2023 16:48:41 GMT, David M. Lloyd <duke at openjdk.org> wrote:

> Are there specific factors which would make it unreasonable to implement `sleep` in terms of `parkNanos`?

After reading the Javadoc for `LockSupport`, I don't believe implementing `Thread.sleep` with `LockSupport.parkNanos` is a proper thing to do. `LockSupport` implicitly deals with permits, acting like a single-permit semaphore. So the behavior for `parkNanos` when there is a prior `LockSupport.unpark` (which adds the permit) is to consume the permit and return immediately.

In other words:


% cat LockSupportIsNotSleep.java 
import java.util.concurrent.locks.LockSupport;
import java.util.concurrent.TimeUnit;

public class LockSupportIsNotSleep {
   public static void main(String... args) {
      LockSupport.unpark(Thread.currentThread());

      long time1 = System.nanoTime();
      LockSupport.parkNanos(TimeUnit.SECONDS.toNanos(1000));
      long time2 = System.nanoTime();

      System.out.println("Slept for " + (time2 - time1) + " ns");
   }
}

% java LockSupportIsNotSleep.java                   
Slept for 6583 ns

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13225#issuecomment-1489000794

From kbarrett at openjdk.org  Wed Mar 29 17:22:34 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 29 Mar 2023 17:22:34 GMT
Subject: RFR: 8304759: Add BitMap iterators [v4]
In-Reply-To: <4FHjg8u1ix7KodqaJkU5q-tnYRDAq3GhRV0z7ArpYGU=.7434363a-1bcb-467f-9225-0e97d4ade998@github.com>
References: <4FHjg8u1ix7KodqaJkU5q-tnYRDAq3GhRV0z7ArpYGU=.7434363a-1bcb-467f-9225-0e97d4ade998@github.com>
Message-ID: <NTraNPlgu_8vuOyuKJqza5giwVlzS07EJ3MT9O1jIUQ=.df177f07-9abf-4421-90b5-2544df55bcc6@github.com>

> Please review this change which adds iteration over the set bit positions of a
> BitMap via an iterator object.  This is in addition to the existing iterate()
> and reverse_iterate() functions that apply a function to the set bit positions.
> 
> There are two iterator classes: BitMap::Iterator and BitMap::ReverseIterator.
> Iteration uses a single, self-contained iterator object, rather than a pair of
> iterator objects as is done with standard library iterators.  This is because
> the desired form of iteration over bitmaps doesn't lend itself well to the
> begin/end pair style.  Typical usage is something like
> 
> 
> for (BitMap::Iterator it{map, beg, end}; !it.is_empty(); it.step()) {
>   ... use it.index()
> }
> 
> 
> However, as a syntactic convenience, these iterator classes provide begin()
> and end() member functions returning objects supporting the requirements for
> range-based for loops.  By constraining these objects to this usage we can
> cope with the "iterator pair" requirements.  Usage is something like
> 
> 
> for (BitMap::idx_t index : BitMap::Iterator{map, beg, end}) {
>   ...
> }
> 
> 
> Testing:
> mach5 tier1, which includes running the updated gtests on all Oracle-supported
> platforms.

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 four additional commits since the last revision:

 - Merge branch 'master' into bm-iterators
 - improve/correct comments for IteratorImpl
 - better names for step functions
 - bitmap iterators

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13184/files
  - new: https://git.openjdk.org/jdk/pull/13184/files/2ea0b16b..6866fcf4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13184&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13184&range=02-03

  Stats: 7762 lines in 231 files changed: 5254 ins; 1358 del; 1150 mod
  Patch: https://git.openjdk.org/jdk/pull/13184.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13184/head:pull/13184

PR: https://git.openjdk.org/jdk/pull/13184

From kbarrett at openjdk.org  Wed Mar 29 17:22:37 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 29 Mar 2023 17:22:37 GMT
Subject: RFR: 8304759: Add BitMap iterators [v2]
In-Reply-To: <UXwh8z6fiLhub9aVtI7_PXADfbgy5LQlUVVVP_gmxLg=.b7865272-92df-4b74-88f1-cf50b6d8c4c3@github.com>
References: <4FHjg8u1ix7KodqaJkU5q-tnYRDAq3GhRV0z7ArpYGU=.7434363a-1bcb-467f-9225-0e97d4ade998@github.com>
 <UkXNPij1QwEq03FKIpzZd0ccz70L0mxYcQa18IzOVz4=.75123a32-63b4-4a31-80ad-f354edab3174@github.com>
 <UXwh8z6fiLhub9aVtI7_PXADfbgy5LQlUVVVP_gmxLg=.b7865272-92df-4b74-88f1-cf50b6d8c4c3@github.com>
Message-ID: <IFphuhFkwUHtZQRJAtJBf0J7IcNEBUK3a2EUWaEZMP8=.92fb844d-83cb-49d7-8c6f-f96ba67d6e6d@github.com>

On Wed, 29 Mar 2023 09:23:49 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   better names for step functions
>
> lgtm. 
> 
> Just a comment about the comments for `first()`/`last()`

Thanks @xmas92 , @stefank , and @tschatzl for reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13184#issuecomment-1488998065

From kbarrett at openjdk.org  Wed Mar 29 17:22:39 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 29 Mar 2023 17:22:39 GMT
Subject: Integrated: 8304759: Add BitMap iterators
In-Reply-To: <4FHjg8u1ix7KodqaJkU5q-tnYRDAq3GhRV0z7ArpYGU=.7434363a-1bcb-467f-9225-0e97d4ade998@github.com>
References: <4FHjg8u1ix7KodqaJkU5q-tnYRDAq3GhRV0z7ArpYGU=.7434363a-1bcb-467f-9225-0e97d4ade998@github.com>
Message-ID: <Zu-J9A8djUlhfgbQV0L0vrZWqtIrryc4SsSBCEmYzX8=.53cf5787-76eb-4c0f-be6a-69e7b0d5aff3@github.com>

On Sat, 25 Mar 2023 15:43:29 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change which adds iteration over the set bit positions of a
> BitMap via an iterator object.  This is in addition to the existing iterate()
> and reverse_iterate() functions that apply a function to the set bit positions.
> 
> There are two iterator classes: BitMap::Iterator and BitMap::ReverseIterator.
> Iteration uses a single, self-contained iterator object, rather than a pair of
> iterator objects as is done with standard library iterators.  This is because
> the desired form of iteration over bitmaps doesn't lend itself well to the
> begin/end pair style.  Typical usage is something like
> 
> 
> for (BitMap::Iterator it{map, beg, end}; !it.is_empty(); it.step()) {
>   ... use it.index()
> }
> 
> 
> However, as a syntactic convenience, these iterator classes provide begin()
> and end() member functions returning objects supporting the requirements for
> range-based for loops.  By constraining these objects to this usage we can
> cope with the "iterator pair" requirements.  Usage is something like
> 
> 
> for (BitMap::idx_t index : BitMap::Iterator{map, beg, end}) {
>   ...
> }
> 
> 
> Testing:
> mach5 tier1, which includes running the updated gtests on all Oracle-supported
> platforms.

This pull request has now been integrated.

Changeset: 34f4d7f4
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/34f4d7f4ad388d8264225c2aefe048ca9a42cfa2
Stats:     381 lines in 4 files changed: 381 ins; 0 del; 0 mod

8304759: Add BitMap iterators

Reviewed-by: stefank, aboldtch, tschatzl

-------------

PR: https://git.openjdk.org/jdk/pull/13184

From duke at openjdk.org  Wed Mar 29 17:28:29 2023
From: duke at openjdk.org (David M. Lloyd)
Date: Wed, 29 Mar 2023 17:28:29 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity
In-Reply-To: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
Message-ID: <uRZZEqy5Lq2HhiVIU-1BtWjKoqbC0ompP0-Km4tQf7o=.e839b5a8-c7bb-4120-a9b5-e022cfefed30@github.com>

On Wed, 29 Mar 2023 11:28:53 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The documentation for that method clearly says the precision and accuracy are dependent on the underlying system behavior. However, it always rounds up `nanos` to 1ms when doing the actual sleep. This means users cannot do the micro-second precision sleeps, even when the underlying platform allows it. Sub-millisecond sleeps are useful to build interesting primitives, like the rate limiters that run with >1000 RPS.
> 
> When faced with this, some users reach for more awkward APIs like `java.util.concurrent.locks.LockSupport.parkNanos`. The use of that API for sleeps is not in line with its intent, and while it "seems to work", it might have interesting interactions with other uses of `LockSupport`. Additionally, these "sleeps" are no longer visible to monitoring tools as "normal sleeps", e.g. as `Thread.sleep` events. Therefore, it would be prudent to improve current `Thread.sleep(millis, nanos)` for sub-millisecond granularity. 
> 
> Fortunately, the underlying code is almost ready for this, at least on POSIX side. I skipped Windows paths, because its timers are still no good. Note that on both Linux and MacOS timers oversleep by about 50us. I have a few ideas how to improve the accuracy for them, which would be a topic for a separate PR.
> 
> Additional testing:
>   - [x] New regression test
>   - [x] New benchmark
>   - [x] Linux x86_64 `tier1`
>   - [x] Linux AArch64 `tier1`

Right, I was assuming that such an implementation would be conformant to the existing specification of the `sleep` method, thus it would have to loop by consuming the unpark (if any), checking for interruption, parking for the remaining time, and reinstating the unpark at the end (if any was consumed). The main risk that I could see of such an approach is that if the sleep was interrupted, then the loop would necessarily unpark itself again (as interruption also interrupts park but this is indistinguishable from an explicit unpark), which might cause a spurious unpark down the line. But it should be pretty consistent with how it is used in interruptible locks AFAIK. I was mostly curious about other factors like JVMTI and thread status though.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13225#issuecomment-1489010885

From sspitsyn at openjdk.org  Wed Mar 29 18:02:38 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 29 Mar 2023 18:02:38 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v9]
In-Reply-To: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
Message-ID: <5SO5rUZwV3SQ2w7t7mOwmP1jXjUVgl4g7NiT7cKi9LU=.355314c8-03ec-4a1e-80d8-e70e98868ecc@github.com>

> The fix is to enable virtual threads support for late binding JVMTI agents.
> The fix includes:
> - New function `JvmtiEnvBase::enable_virtual_threads_notify_jvmti()` which does enabling JVMTI VTMS transition notifications in case of agent loaded into running VM. This function executes a VM operation counting VTMS transition bits in all `JavaThread`'s to correctly set the static counter `_VTMS_transition_count` needed for VTMS transition protocol.
> - New function `JvmtiEnvBase::disable_virtual_threads_notify_jvmti()` which is needed for testing. It is used by the `WhiteBox` API.
> - New WhiteBox function `WB_SetVirtualThreadsNotifyJvmtiMode(JNIEnv* env, jobject wb, jboolean enable)` needed for testing of this update.
> - New regression test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
> 
> Testing:
> - New test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
> - The originally failed tests are expected to pass 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:

  review: updated correction of jt->jvmti_thread_state() links in VM_SetNotifyJvmtiEventsMode

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13133/files
  - new: https://git.openjdk.org/jdk/pull/13133/files/2c59c54b..c5d8a015

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13133&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13133&range=07-08

  Stats: 14 lines in 1 file changed: 4 ins; 1 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/13133.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13133/head:pull/13133

PR: https://git.openjdk.org/jdk/pull/13133

From sspitsyn at openjdk.org  Wed Mar 29 18:02:42 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 29 Mar 2023 18:02:42 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v8]
In-Reply-To: <z8EAkfLzRQUB-cfi_dKR9O5VSXXjn01eOrG-GdPB0No=.f187c0f7-93c8-400e-a1d8-8af1cc27f159@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <uZLGDh5UIBW0AYrgh4ndTUtnqNfp2zGgnx2zQm-kBaI=.f3d7e776-0e81-4272-bc31-2cdee9dc9d23@github.com>
 <q2NaN5p_DlPfaATSFXFg7Rco87hpx5eH1lOh4j1WhqU=.844c4ce4-b850-4576-97d5-88cfd163aab6@github.com>
 <z8EAkfLzRQUB-cfi_dKR9O5VSXXjn01eOrG-GdPB0No=.f187c0f7-93c8-400e-a1d8-8af1cc27f159@github.com>
Message-ID: <AhDwNB9jZzFsakmywdDodoet75MnodH4LtHfoGFvH20=.0cdc205c-b5c7-42ba-9673-69f6d435d425@github.com>

On Wed, 29 Mar 2023 10:16:39 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1554:
>> 
>>> 1552:       // Correct jt->jvmti_thread_state() and jt->jvmti_vthread() if necessary.
>>> 1553:       // It was not maintained while notifyJvmti was disabled.
>>> 1554:       if (jt_state != ct_state && jt_state != vt_state) {
>> 
>> Is it possible that jt_state == ct_state while the virtual thread is executed or vice versa? Just because jvmtt_state is outdated.
>> Shouldn't we always update (set to null) link/ jvmti_vthread if _enabled  == true?
>
> A1: Not sure, I understand your first question correctly. What does mean "vice versa" in this context?
> When `notifyJvmti` events is disabled then a call to `rebind_to_jvmti_thread_state_of` is omitted in VTMS transitions. So, we need to correct it if necessary. It can be `jt_state == ct_state` while the virtual thread is executed in a mount/unmount transition. I keep thinking on how to make this fixup more precise.
> 
> A better approach would be something like this:
> 
>       if (virt) {
>         if (jt_state != vt_state) {
>           jt->set_jvmti_thread_state(vt_state); // restore jt->jvmti_thread_state()
>           jt->set_jvmti_vthread(vt_oop);        // restore jt->jvmti_vthread()
>           if (vt_state != nullptr) {
>             vt_state->set_thread(jt);           // restore JavaThread link
>           }
>         }
>       } else { // !virt
>         if (jt_state != ct_state) {
>           jt->set_jvmti_thread_state(ct_state); // restore jt->jvmti_thread_state()
>           jt->set_jvmti_vthread(nullptr);       // reset jt->jvmti_vthread()
>         }
>       }
> 
> But it does not work correctly now. Some adjustment is needed to make it working.
> 
>> Shouldn't we always update (set to null) link/ jvmti_vthread if _enabled == true?
> 
> A2: Ideally, all these corrections are only needed for the case: `_enable == true.` I'm testing this now.

I've updated this part. Please. let me know if you still have some questions.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1152304909

From coleenp at openjdk.org  Wed Mar 29 18:13:00 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 29 Mar 2023 18:13:00 GMT
Subject: RFR: 8303805: [REDO] JDK-8302189 and JDK-8302799
In-Reply-To: <LrDLITpu9mfyyL30QCXITE8nFEG-NfcZi0DvqvDF7Pg=.5d3fb62e-b689-42f0-ac75-4efee44ba2af@github.com>
References: <LrDLITpu9mfyyL30QCXITE8nFEG-NfcZi0DvqvDF7Pg=.5d3fb62e-b689-42f0-ac75-4efee44ba2af@github.com>
Message-ID: <t1Ya5xyRJjsFPM3uG8zmOzRt0QwsGpNNJ34GnNEoevg=.79af01f1-e11c-41f2-af89-636db1b33066@github.com>

On Mon, 27 Mar 2023 23:57:45 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this redo of the following changes:
> 8302189: Mark assertion failures noreturn
> 8302799: Refactor Debugging variable usage for noreturn crash reporting
> 
> The original change tripped over a bug the handling of noreturn and
> __builtin_unreachable by Xcode12 (so probably generic clang12 and perhaps
> earlier).  It seems to have been fixed in Xcode13 (and probably other uses of
> clang13), but we're not yet ready to require that version.
> 
> As such, we've taken the original change and kludged around the problem for
> now.  The kludge should be removed once we require clang13+.
> 
> As a reminder, the original change that was backed out did the following:
> https://github.com/openjdk/jdk/pull/12845
> 
> (1) Changed how assertions were suppressed when running the various debugging
> commands defined in debug.cpp.  The failure reporting functions used to just
> return if the Debugging variable was set (by a debug command invocation).
> Now, debug command invocation establishes a DebuggingContext object which
> causes asserts to bypass the check entirely.
> 
> (2) Added [[noreturn]] attributes to error reporting functions declared in
> debug.hpp.
> 
> This change consists of
> (1) Reapply the change from PR#12845.
> (2) A minor improvement to the DebuggingContext destructor.
> (3) Replace uses of [[noreturn]] with new ATTRIBUTE_NORETURN macro (the kludge).
> 
> The ATTRIBUTE_NORETURN macro expands to `[[noreturn]]` unless the compiler is
> clang and its version is less than 13, which it expands to nothing.
> 
> The replaced [[noreturn]] uses include both those added by JDK-8302189 and
> those added by the earlier JDK-8302798.
> 
> This is problematic in the long run.  It prevents the removal of otherwise
> obsolete and unreachable code following a call to a noreturn function.  We
> have such code in various places because these functions were previously not
> noreturn (and with this change still aren't for clang12 and prior).  It may
> also require the inclusion of such code in future changes.  This may result in
> change testing on Linux and/or Windows missing problems that will only show up
> when testing on a clang-using platform.
> 
> We're really going to want to require a minimum of clang13 sooner rather than
> later.  Unfortunately, we've run into other problems with Xcode13 and Xcode14,
> and the aix-ppc maintainers have only just begun testing xlclang++ 17.1.  (The
> version they have been using is based on clang3!)  Hence this kludge for now,
> to permit use of gcc12 (JDK-8294031).
> 
> Testing:
> mach5 tier1-7.

This seems fine to me.

src/hotspot/share/utilities/debug.cpp line 89:

> 87:     _enabled -= 1;              // Decrease nesting count.
> 88:   } else {
> 89:     fatal("Debugging nesting confusion");

Why did you make this change?  Isn't this an RAII object - how would this be a problem?

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13199#pullrequestreview-1363695920
PR Review Comment: https://git.openjdk.org/jdk/pull/13199#discussion_r1152317319

From alanb at openjdk.org  Wed Mar 29 18:13:00 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 29 Mar 2023 18:13:00 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity
In-Reply-To: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
Message-ID: <D3WmCB5j0L2scJaMYCC1dRnLabkbry2jeqolFwMxdEk=.d1ae02ef-8a09-44a4-bb4f-648106da3b9b@github.com>

On Wed, 29 Mar 2023 11:28:53 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The documentation for that method clearly says the precision and accuracy are dependent on the underlying system behavior. However, it always rounds up `nanos` to 1ms when doing the actual sleep. This means users cannot do the micro-second precision sleeps, even when the underlying platform allows it. Sub-millisecond sleeps are useful to build interesting primitives, like the rate limiters that run with >1000 RPS.
> 
> When faced with this, some users reach for more awkward APIs like `java.util.concurrent.locks.LockSupport.parkNanos`. The use of that API for sleeps is not in line with its intent, and while it "seems to work", it might have interesting interactions with other uses of `LockSupport`. Additionally, these "sleeps" are no longer visible to monitoring tools as "normal sleeps", e.g. as `Thread.sleep` events. Therefore, it would be prudent to improve current `Thread.sleep(millis, nanos)` for sub-millisecond granularity. 
> 
> Fortunately, the underlying code is almost ready for this, at least on POSIX side. I skipped Windows paths, because its timers are still no good. Note that on both Linux and MacOS timers oversleep by about 50us. I have a few ideas how to improve the accuracy for them, which would be a topic for a separate PR.
> 
> Additional testing:
>   - [x] New regression test
>   - [x] New benchmark
>   - [x] Linux x86_64 `tier1`
>   - [x] Linux AArch64 `tier1`

src/java.base/share/classes/java/lang/Thread.java line 509:

> 507:             ThreadSleepEvent event = new ThreadSleepEvent();
> 508:             try {
> 509:                 event.time = MILLISECONDS.toNanos(millis) + nanos;

This can overflow when millis is at or close to Long.MAX_VALUE.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1152318322

From stsypanov at openjdk.org  Wed Mar 29 18:21:06 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 29 Mar 2023 18:21:06 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity
In-Reply-To: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
Message-ID: <dov0t3SCSFwYAamyZdJpN2wmC2kseHTG8kZPBb_sxXc=.e7f92cdc-0fc2-4c06-80b5-9bdc8e1c9714@github.com>

On Wed, 29 Mar 2023 11:28:53 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The documentation for that method clearly says the precision and accuracy are dependent on the underlying system behavior. However, it always rounds up `nanos` to 1ms when doing the actual sleep. This means users cannot do the micro-second precision sleeps, even when the underlying platform allows it. Sub-millisecond sleeps are useful to build interesting primitives, like the rate limiters that run with >1000 RPS.
> 
> When faced with this, some users reach for more awkward APIs like `java.util.concurrent.locks.LockSupport.parkNanos`. The use of that API for sleeps is not in line with its intent, and while it "seems to work", it might have interesting interactions with other uses of `LockSupport`. Additionally, these "sleeps" are no longer visible to monitoring tools as "normal sleeps", e.g. as `Thread.sleep` events. Therefore, it would be prudent to improve current `Thread.sleep(millis, nanos)` for sub-millisecond granularity. 
> 
> Fortunately, the underlying code is almost ready for this, at least on POSIX side. I skipped Windows paths, because its timers are still no good. Note that on both Linux and MacOS timers oversleep by about 50us. I have a few ideas how to improve the accuracy for them, which would be a topic for a separate PR.
> 
> Additional testing:
>   - [x] New regression test
>   - [x] New benchmark
>   - [x] Linux x86_64 `tier1`
>   - [x] Linux AArch64 `tier1`

Should we manifest this change in JavaDoc somehow? Just to let people know that starting from the next Java release they can use sub-millisecond intervals in their code.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13225#issuecomment-1489084409

From shade at openjdk.org  Wed Mar 29 18:35:25 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 29 Mar 2023 18:35:25 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity
In-Reply-To: <D3WmCB5j0L2scJaMYCC1dRnLabkbry2jeqolFwMxdEk=.d1ae02ef-8a09-44a4-bb4f-648106da3b9b@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
 <D3WmCB5j0L2scJaMYCC1dRnLabkbry2jeqolFwMxdEk=.d1ae02ef-8a09-44a4-bb4f-648106da3b9b@github.com>
Message-ID: <ry1FPsIyROnWaoVmGxDppMYCuK7xQ9IBnDFBTeg-UMQ=.dbce9f3c-2f8a-49bd-abfa-7a07a4a3e628@github.com>

On Wed, 29 Mar 2023 18:10:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The documentation for that method clearly says the precision and accuracy are dependent on the underlying system behavior. However, it always rounds up `nanos` to 1ms when doing the actual sleep. This means users cannot do the micro-second precision sleeps, even when the underlying platform allows it. Sub-millisecond sleeps are useful to build interesting primitives, like the rate limiters that run with >1000 RPS.
>> 
>> When faced with this, some users reach for more awkward APIs like `java.util.concurrent.locks.LockSupport.parkNanos`. The use of that API for sleeps is not in line with its intent, and while it "seems to work", it might have interesting interactions with other uses of `LockSupport`. Additionally, these "sleeps" are no longer visible to monitoring tools as "normal sleeps", e.g. as `Thread.sleep` events. Therefore, it would be prudent to improve current `Thread.sleep(millis, nanos)` for sub-millisecond granularity. 
>> 
>> Fortunately, the underlying code is almost ready for this, at least on POSIX side. I skipped Windows paths, because its timers are still no good. Note that on both Linux and MacOS timers oversleep by about 50us. I have a few ideas how to improve the accuracy for them, which would be a topic for a separate PR.
>> 
>> Additional testing:
>>   - [x] New regression test
>>   - [x] New benchmark
>>   - [x] Linux x86_64 `tier1`
>>   - [x] Linux AArch64 `tier1`
>
> src/java.base/share/classes/java/lang/Thread.java line 509:
> 
>> 507:             ThreadSleepEvent event = new ThreadSleepEvent();
>> 508:             try {
>> 509:                 event.time = MILLISECONDS.toNanos(millis) + nanos;
> 
> This can overflow when millis is at or close to Long.MAX_VALUE.

Yes, let me fix that. `TimeUnit.toNanos` handles it well itself, it seems.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1152336826

From cjplummer at openjdk.org  Wed Mar 29 18:58:25 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 29 Mar 2023 18:58:25 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v4]
In-Reply-To: <GOOPg0-P0Vc1ocNUzWRIbItENekN1ralramscyuF1kQ=.44aded10-e14f-4378-9173-a8126d21da04@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <GOOPg0-P0Vc1ocNUzWRIbItENekN1ralramscyuF1kQ=.44aded10-e14f-4378-9173-a8126d21da04@github.com>
Message-ID: <LK67uauaC7fIrRBrSoVq8yTzmW4NaGhNTCEVxJU1jjM=.f02e3554-ef5d-479d-8de2-fee786cc6e67@github.com>

On Wed, 29 Mar 2023 08:00:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview.
>> 
>> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently.
>> 
>> In addition, there are a small number of implementation changes to sync up from the loom fibers branch:
>> 
>> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where  end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly.
>> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes.
>> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs.
>> - New system property to print a stack trace when a virtual thread sets its own value of a TL.
>> - ThreadPerTaskExecutor is changed to use FutureTask.
>> 
>> Testing: tier1-6.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix ThreadSleepEvent again

test/hotspot/jtreg/serviceability/jvmti/thread/GetFrameCount/framecnt01/framecnt01.java line 82:

> 80: 
> 81:         // this is too fragile, implementation can change at any time.
> 82:         checkFrames(vThread1, false, 14);

Is this due to the `@hidden` being added to `Continuation.enter()` and `enter0()`? If so, since both methods are now hidden, why are there not 2 fewer frames? Was there also an additional frame added somewhere?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1152337485

From cjplummer at openjdk.org  Wed Mar 29 18:58:29 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 29 Mar 2023 18:58:29 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v2]
In-Reply-To: <D0vaoMIzK-5zkAWoZsuMO0PfbZMUyx-B5Gt15PjH98A=.143da029-3477-4031-bf41-d3a67888b276@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <9RJ4unb3FjazYLi0BbWs1NGN9h50Z1fvAz1ZNds5mO4=.cb02f148-66bd-4429-9c30-ea4a6dcbe4d7@github.com>
 <OPz26p0QvEh0Cw-SHvuEi3cslPvNXpqnA5GBs8TXjUo=.996b3218-9cb1-4773-b96c-259eeb99d521@github.com>
 <D0vaoMIzK-5zkAWoZsuMO0PfbZMUyx-B5Gt15PjH98A=.143da029-3477-4031-bf41-d3a67888b276@github.com>
Message-ID: <AJnnfy-ut-WY4FlJPFpkjXB5hWDdUHf-lQhGh8JVXXI=.fa42eef0-455a-4049-ae7a-1c7dc59ba473@github.com>

On Wed, 29 Mar 2023 07:27:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> test/jdk/com/sun/management/ThreadMXBean/VirtualThreads.java line 143:
>> 
>>> 141:             long[] tids = new long[] { tid0, tid1 };
>>> 142:             long[] cpuTimes = bean.getThreadCpuTime(tids);
>>> 143:             if (Thread.currentThread().isVirtual()) {
>> 
>> How it worked before?
>
> tid0 is the thread ID of a platform therad. tid1 is the threadID of a virtual thread. The only change here is allow this test run with the main wrapper plugin ([CODETOOLS-7903373](https://bugs.openjdk.org/browse/CODETOOLS-7903373)), it would otherwise have to be excluded for those runs.

I don't see any problemlist changes. Was this test failing when using the wrapper because of the lack of problemlisting?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1152353646

From iklam at openjdk.org  Wed Mar 29 19:29:23 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 29 Mar 2023 19:29:23 GMT
Subject: RFR: JDK-8302989: Add missing INCLUDE_CDS checks [v4]
In-Reply-To: <fGTeq_iVGjFe3aiVJQORv7tkkD_SFG40BZsTnJ4Pf_E=.fbb8ba70-fa69-4b4a-a744-02f249d418bb@github.com>
References: <kBV8fNo_CWJL2MoXgAckFhuAFgQ3RGZjFKAKnl8xfV8=.233bb652-8508-4065-92ea-7873b1c765f3@github.com>
 <dkwL4nBOs2Sh6R-tiu0xVFTioOXKZDXInHk6GW3BpWE=.c5d327fc-9e63-4c9d-b223-ea7aa8753b80@github.com>
 <deBUxZbZ8FI9ENyfv-xwSrdfWhJVe-kT2VBxokj-_wA=.f7f83ce4-34cd-42d8-a30e-bad77676d802@github.com>
 <fGTeq_iVGjFe3aiVJQORv7tkkD_SFG40BZsTnJ4Pf_E=.fbb8ba70-fa69-4b4a-a744-02f249d418bb@github.com>
Message-ID: <QifVyKA9Ycm90uLg1yPGEatwivcawi6Y68nSrjue6y4=.b4114498-f436-47df-b8a1-5d494c7825b1@github.com>

On Wed, 8 Mar 2023 09:27:27 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > Maybe we can keep the -Xshare flags and make their behavior consistent with builds that have CDS enabled
> 
> This might help the tests but semantically this just seems wrong to me. It would be like accepting G1 flags when you only have SerialGC available.

The following is the current behavior when `-Xshare` is used when CDS is disabled. If we want to remove `-Xshare` completely, a CSR will be needed.


$ minimal/bin/java -Xshare:on -version
Shared spaces are not supported in this VM
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

$ minimal/bin/java -Xshare:auto -version
Java HotSpot(TM) 64-Bit Minimal VM warning: Shared spaces are not supported in this VM
java version "21-internal" 2023-09-19
Java(TM) SE Runtime Environment (fastdebug build 21-internal-adhoc.iklam.nep)
Java HotSpot(TM) 64-Bit Minimal VM (fastdebug build 21-internal-adhoc.iklam.nep, mixed mode, emulated-client)

$ minimal/bin/java -Xshare:off -version
java version "21-internal" 2023-09-19
Java(TM) SE Runtime Environment (fastdebug build 21-internal-adhoc.iklam.nep)
Java HotSpot(TM) 64-Bit Minimal VM (fastdebug build 21-internal-adhoc.iklam.nep, mixed mode, emulated-client)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12691#issuecomment-1489179866

From alanb at openjdk.org  Wed Mar 29 19:33:15 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 29 Mar 2023 19:33:15 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v2]
In-Reply-To: <AJnnfy-ut-WY4FlJPFpkjXB5hWDdUHf-lQhGh8JVXXI=.fa42eef0-455a-4049-ae7a-1c7dc59ba473@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <9RJ4unb3FjazYLi0BbWs1NGN9h50Z1fvAz1ZNds5mO4=.cb02f148-66bd-4429-9c30-ea4a6dcbe4d7@github.com>
 <OPz26p0QvEh0Cw-SHvuEi3cslPvNXpqnA5GBs8TXjUo=.996b3218-9cb1-4773-b96c-259eeb99d521@github.com>
 <D0vaoMIzK-5zkAWoZsuMO0PfbZMUyx-B5Gt15PjH98A=.143da029-3477-4031-bf41-d3a67888b276@github.com>
 <AJnnfy-ut-WY4FlJPFpkjXB5hWDdUHf-lQhGh8JVXXI=.fa42eef0-455a-4049-ae7a-1c7dc59ba473@github.com>
Message-ID: <1bIwzQpS67LQhRTy1ZlTEaASKmr0YAVxhMIKohuEydc=.d911ce7a-1f2e-4320-8c8c-66dc00174b9f@github.com>

On Wed, 29 Mar 2023 18:47:03 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> tid0 is the thread ID of a platform therad. tid1 is the threadID of a virtual thread. The only change here is allow this test run with the main wrapper plugin ([CODETOOLS-7903373](https://bugs.openjdk.org/browse/CODETOOLS-7903373)), it would otherwise have to be excluded for those runs.
>
> I don't see any problemlist changes. Was this test failing when using the wrapper because of the lack of problemlisting?

I added this test recently via JDK-8303242. It failed when we sync'ed up the loom repo as the test configuration there runs the tests with the jtreg main wrapper. It was trivial to fix and this avoid needing to exclude it via ProblemList-Virtual.txt. Once jtreg is promoted and there is config added to run the tests with the virtual ThreadFactory then this test will be able to run in this mode.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1152393905

From alanb at openjdk.org  Wed Mar 29 19:42:35 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 29 Mar 2023 19:42:35 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v4]
In-Reply-To: <LK67uauaC7fIrRBrSoVq8yTzmW4NaGhNTCEVxJU1jjM=.f02e3554-ef5d-479d-8de2-fee786cc6e67@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <GOOPg0-P0Vc1ocNUzWRIbItENekN1ralramscyuF1kQ=.44aded10-e14f-4378-9173-a8126d21da04@github.com>
 <LK67uauaC7fIrRBrSoVq8yTzmW4NaGhNTCEVxJU1jjM=.f02e3554-ef5d-479d-8de2-fee786cc6e67@github.com>
Message-ID: <4_Xz1S2uFPVW_ySuYjEtJFmmEKIWgw1DD9hLlTGyESs=.383d569f-1e08-48be-9af0-c39d4c5ee7c1@github.com>

On Wed, 29 Mar 2023 18:30:01 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix ThreadSleepEvent again
>
> test/hotspot/jtreg/serviceability/jvmti/thread/GetFrameCount/framecnt01/framecnt01.java line 82:
> 
>> 80: 
>> 81:         // this is too fragile, implementation can change at any time.
>> 82:         checkFrames(vThread1, false, 14);
> 
> Is this due to the `@hidden` being added to `Continuation.enter()` and `enter0()`? If so, since both methods are now hidden, why are there not 2 fewer frames? Was there also an additional frame added somewhere?

No, it's that a lambda expression is replaced in the implementation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1152402303

From rrich at openjdk.org  Wed Mar 29 19:54:50 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 29 Mar 2023 19:54:50 GMT
Subject: RFR: 8296440: Remove Method* handling from
 cleanup_inline_caches_impl [v5]
In-Reply-To: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
References: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
Message-ID: <sKZLs2RK8I6WtO2kco2VU4vg3QelVnE_jsyhHqZcSxI=.5caf4c6f-5534-44b5-b1af-e2c0c79b6c9e@github.com>

> This PR replaces cleaning of static stubs in CompiledMethod::cleanup_inline_caches_impl() with a guarantee that it is actually not needed because the holder of the embedded target Method* is alive if the caller nmethod is not unloading.
> 
> The holder of the target Method* has to be alive because it is reachable from the caller nmethod's oop pool. This is checked by `check_path_to_callee()` when a statically bound call gets resolved.
> 
> C2i entry barriers can be removed for the same reason.
> 
> Testing:
> 
> Many rounds in our CI testing which includes most JCK and JTREG tests, Renaissance benchmark and SAP specific tests with fastdebug and release builds on the standard platforms plus PPC64.
> 
> I've also done tier1 and tier2 tests with -XX:-Inline and tier1 tests with ZGC.
> 
> I've started hotspot and jdk tier1 tests with -Xcomp. They were not finished when I stopped them after 24h.

Richard Reingruber has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - Check only in debug vm
 - Merge branch 'master'
 - Merge branch 'master'
 - Fix
 - Feedback Coleene
 - Adding TestStaticallyBoundTargetIsReachable.java
 - Path to target exists also if the receiver is a constant of the caller
 - Use nmethod::oops_do() to search for to_holder in from_nm
 - Merge branch 'master'
 - Remove MacroAssembler::resolve_weak_handle()
 - ... and 4 more: https://git.openjdk.org/jdk/compare/ff368d50...7dd06446

-------------

Changes: https://git.openjdk.org/jdk/pull/12802/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12802&range=04
  Stats: 744 lines in 30 files changed: 437 ins; 285 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/12802.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12802/head:pull/12802

PR: https://git.openjdk.org/jdk/pull/12802

From alanb at openjdk.org  Wed Mar 29 20:01:09 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 29 Mar 2023 20:01:09 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity
In-Reply-To: <ry1FPsIyROnWaoVmGxDppMYCuK7xQ9IBnDFBTeg-UMQ=.dbce9f3c-2f8a-49bd-abfa-7a07a4a3e628@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
 <D3WmCB5j0L2scJaMYCC1dRnLabkbry2jeqolFwMxdEk=.d1ae02ef-8a09-44a4-bb4f-648106da3b9b@github.com>
 <ry1FPsIyROnWaoVmGxDppMYCuK7xQ9IBnDFBTeg-UMQ=.dbce9f3c-2f8a-49bd-abfa-7a07a4a3e628@github.com>
Message-ID: <a-0HBVWhYvxYpHicxDKAkUXF2CPKPqsBWyVUlmSCwpo=.6a8fef20-3fb2-48db-b6ea-8d0f6257ff77@github.com>

On Wed, 29 Mar 2023 18:29:18 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Yes, let me fix that. `TimeUnit.toNanos` handles it well itself, it seems.

This code is refactored in PR 13203 so we'll have to merge at some point.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1152419710

From cjplummer at openjdk.org  Wed Mar 29 20:37:37 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 29 Mar 2023 20:37:37 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v4]
In-Reply-To: <GOOPg0-P0Vc1ocNUzWRIbItENekN1ralramscyuF1kQ=.44aded10-e14f-4378-9173-a8126d21da04@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <GOOPg0-P0Vc1ocNUzWRIbItENekN1ralramscyuF1kQ=.44aded10-e14f-4378-9173-a8126d21da04@github.com>
Message-ID: <NrK4A-3ekpzc3BrTqSCZQdVTHp_krO5N19i-U7V250g=.25595f92-eff7-4fa9-9481-eff3d0eb93fe@github.com>

On Wed, 29 Mar 2023 08:00:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview.
>> 
>> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently.
>> 
>> In addition, there are a small number of implementation changes to sync up from the loom fibers branch:
>> 
>> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where  end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly.
>> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes.
>> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs.
>> - New system property to print a stack trace when a virtual thread sets its own value of a TL.
>> - ThreadPerTaskExecutor is changed to use FutureTask.
>> 
>> Testing: tier1-6.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix ThreadSleepEvent again

Serviceability changes look good.

-------------

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13203#pullrequestreview-1363917524

From lmesnik at openjdk.org  Wed Mar 29 21:49:21 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 29 Mar 2023 21:49:21 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v4]
In-Reply-To: <GOOPg0-P0Vc1ocNUzWRIbItENekN1ralramscyuF1kQ=.44aded10-e14f-4378-9173-a8126d21da04@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <GOOPg0-P0Vc1ocNUzWRIbItENekN1ralramscyuF1kQ=.44aded10-e14f-4378-9173-a8126d21da04@github.com>
Message-ID: <96yRAvTFAMp431o3TzORkDS73JONn6D4UwdLwSbUqv4=.1a128faa-78e5-427b-98f4-c5624295e396@github.com>

On Wed, 29 Mar 2023 08:00:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview.
>> 
>> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently.
>> 
>> In addition, there are a small number of implementation changes to sync up from the loom fibers branch:
>> 
>> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where  end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly.
>> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes.
>> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs.
>> - New system property to print a stack trace when a virtual thread sets its own value of a TL.
>> - ThreadPerTaskExecutor is changed to use FutureTask.
>> 
>> Testing: tier1-6.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix ThreadSleepEvent again

Test changes looks good.

-------------

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13203#pullrequestreview-1363976888

From psandoz at openjdk.org  Wed Mar 29 21:49:32 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 29 Mar 2023 21:49:32 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v4]
In-Reply-To: <GOOPg0-P0Vc1ocNUzWRIbItENekN1ralramscyuF1kQ=.44aded10-e14f-4378-9173-a8126d21da04@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <GOOPg0-P0Vc1ocNUzWRIbItENekN1ralramscyuF1kQ=.44aded10-e14f-4378-9173-a8126d21da04@github.com>
Message-ID: <VDNjN3puvhREiu0NRGipzN_vX9aCfdPIW-YcIx2pr5o=.2a28f04e-d9d6-4bd3-a9f0-9ab2e25a1013@github.com>

On Wed, 29 Mar 2023 08:00:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview.
>> 
>> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently.
>> 
>> In addition, there are a small number of implementation changes to sync up from the loom fibers branch:
>> 
>> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where  end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly.
>> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes.
>> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs.
>> - New system property to print a stack trace when a virtual thread sets its own value of a TL.
>> - ThreadPerTaskExecutor is changed to use FutureTask.
>> 
>> Testing: tier1-6.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix ThreadSleepEvent again

src/java.base/share/classes/java/lang/Thread.java line 1546:

> 1544:             // bind thread to container
> 1545:             if (this.container != null)
> 1546:                 throw new IllegalThreadStateException();

This check is not replicated in `VirtualThread::start`, i think the CAS protects against that. Maybe assert instead in the virtual thread implementation, thereby the comment in `setThreadContainer` can be changed to something like "`this.container` checked/asserted to be != null before call to Virtual/Thread::start(ThreadContainer)" ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1152514040

From dcubed at openjdk.org  Wed Mar 29 22:00:11 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 29 Mar 2023 22:00:11 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v35]
In-Reply-To: <NhMXsf7u09iGG1DS_E4zttNbHncJDp0OyAA6WBAPEOQ=.2446a8cc-8313-467b-963f-9c7c4c6bbca9@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <NhMXsf7u09iGG1DS_E4zttNbHncJDp0OyAA6WBAPEOQ=.2446a8cc-8313-467b-963f-9c7c4c6bbca9@github.com>
Message-ID: <P__u34D1QfjXJNUlF76aB9U0SkWf101xrnd6aweSwKo=.549bf5f2-bc8e-4d3f-9ca6-cd4d8b173f3b@github.com>

On Wed, 29 Mar 2023 13:51:51 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Process lock-stack oops before inspecting them, when in foreign thread and not at safepoint. Add verifications.

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 6242:

> 6240:   // After successful lock, push object on lock-stack
> 6241:   ldrw(t1, Address(rthread, JavaThread::lock_stack_offset_offset()));
> 6242:   // Strictly speaking we should emit an IN_NATIVE store. However, non

nit typo: s/non/none/

src/hotspot/share/runtime/lockStack.cpp line 56:

> 54: void LockStack::verify(const char* msg) const {
> 55:   assert(is_self() || SafepointSynchronize::is_at_safepoint() || _thread->is_handshake_safe_for(Thread::current()) || _thread->is_suspended() || _thread->is_obj_deopt_suspend() || is_stack_watermark_processing(_thread),
> 56:          "access only thread-local, or when target thread safely holds stil");

nit typo: s/holds stil/holds still/

src/hotspot/share/runtime/threads.cpp line 1423:

> 1421: 
> 1422: JavaThread* Threads::owning_thread_from_object(ThreadsList * t_list, oop obj) {
> 1423:   assert(SafepointSynchronize::is_at_safepoint(), "not safe outside of safepoint");

`ObjectSynchronizer::get_lock_owner()` calls `Threads::owning_thread_from_object()`
and I don't think you can assert that `ObjectSynchronizer::get_lock_owner()`  is only
called from a safepoint. In particular, `ThreadSnapshot::initialize()` calls
`ObjectSynchronizer::get_lock_owner()`  and I believe that `initialize()` function can
be called from non-safepoint places with M&M APIs...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1152505819
PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1152509017
PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1152522309

From dcubed at openjdk.org  Wed Mar 29 22:00:45 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 29 Mar 2023 22:00:45 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v31]
In-Reply-To: <jANr0SNUonjZl8Di_e0x6TvNP5DMvXFUgOZ72kHGhV4=.528b1344-9c75-4019-b9bb-84ae4c613e64@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <jANr0SNUonjZl8Di_e0x6TvNP5DMvXFUgOZ72kHGhV4=.528b1344-9c75-4019-b9bb-84ae4c613e64@github.com>
Message-ID: <slKfTRqdKEe85HdRhfLAhu0z-83AWIothG_0CH1SUtU=.327e2e68-4596-423d-ab04-7bcbd916cf08@github.com>

On Tue, 28 Mar 2023 10:28:00 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   (x86_32) Use existing thread register in fast_unlock() instead of fetching thread into a tmp register

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 702:

> 700:   bind(COUNT);
> 701:   // Count monitors in fast path
> 702:   increment(Address(thread, JavaThread::held_monitor_count_offset()));

Okay you updated this logic to use the `thread` register that's passed in, but
there are two other uses of `r15_thread` in `C2_MacroAssembler::fast_lock()`
on L679 and L686 that could also be switched to `thread`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1152491935

From psandoz at openjdk.org  Wed Mar 29 22:11:09 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 29 Mar 2023 22:11:09 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v4]
In-Reply-To: <GOOPg0-P0Vc1ocNUzWRIbItENekN1ralramscyuF1kQ=.44aded10-e14f-4378-9173-a8126d21da04@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <GOOPg0-P0Vc1ocNUzWRIbItENekN1ralramscyuF1kQ=.44aded10-e14f-4378-9173-a8126d21da04@github.com>
Message-ID: <yN4eNwXpvCdk9WZc3U5hYn43t2r9DFEySBbV3XHLepU=.b1d02a80-b1f9-4c39-802a-5c0814be359d@github.com>

On Wed, 29 Mar 2023 08:00:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview.
>> 
>> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently.
>> 
>> In addition, there are a small number of implementation changes to sync up from the loom fibers branch:
>> 
>> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where  end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly.
>> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes.
>> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs.
>> - New system property to print a stack trace when a virtual thread sets its own value of a TL.
>> - ThreadPerTaskExecutor is changed to use FutureTask.
>> 
>> Testing: tier1-6.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix ThreadSleepEvent again

Looks good.

test/jdk/java/lang/Thread/virtual/TraceVirtualThreadLocals.java line 65:

> 63: 
> 64:     /**
> 65:      * Runs a task in a virutal thread, returning a String with any output printed

Suggestion:

     * Runs a task in a virtual thread, returning a String with any output printed

-------------

Marked as reviewed by psandoz (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13203#pullrequestreview-1364039280
PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1152529524

From dcubed at openjdk.org  Wed Mar 29 22:16:59 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 29 Mar 2023 22:16:59 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v37]
In-Reply-To: <Y7GnMCO0_ZCOlK7-0KrSaFrQY3EWb6mwtoZT8ZjmRBI=.cef3dbdb-7d55-45ee-b6f1-c3c614098513@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <Y7GnMCO0_ZCOlK7-0KrSaFrQY3EWb6mwtoZT8ZjmRBI=.cef3dbdb-7d55-45ee-b6f1-c3c614098513@github.com>
Message-ID: <1ZtuIYVxUaqsHQSGuCJB0qDHqfXzVEyidpaEKcyoxIs=.e9a9b540-5e0c-474d-a89b-09e99ea27ddb@github.com>

On Wed, 29 Mar 2023 16:05:05 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Bounds check in lock-stack verification; only do watermark if we have one

At this point, I've reviewed the changes in v29 -> v36 and I've posted
comments for several things. I still need to update my repo to get in
sync with v36.

src/hotspot/share/runtime/lockStack.cpp line 69:

> 67:   assert(UseFastLocking && !UseHeavyMonitors, "never use lock-stack when fast-locking is disabled");
> 68:   assert((_offset <=  end_offset()), "lockstack overflow: _offset %d end_offset %d", _offset, end_offset());
> 69:   assert((_offset >= start_offset()), "lockstack underflow: _offset %d end_offset %d", _offset, start_offset());

You should save a local copy of `end_offset()` and a local copy of
`start_offset()` in an `#ifdef ASSERT ... #endif` code block and
then use those local copies in the `assert()` condition and mesg.
That will guard against parallel usage by the target thread versus
the verifying thread.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1489399633
PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1152532606

From dcubed at openjdk.org  Wed Mar 29 22:17:03 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 29 Mar 2023 22:17:03 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v35]
In-Reply-To: <P__u34D1QfjXJNUlF76aB9U0SkWf101xrnd6aweSwKo=.549bf5f2-bc8e-4d3f-9ca6-cd4d8b173f3b@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <NhMXsf7u09iGG1DS_E4zttNbHncJDp0OyAA6WBAPEOQ=.2446a8cc-8313-467b-963f-9c7c4c6bbca9@github.com>
 <P__u34D1QfjXJNUlF76aB9U0SkWf101xrnd6aweSwKo=.549bf5f2-bc8e-4d3f-9ca6-cd4d8b173f3b@github.com>
Message-ID: <-xn2Y5lZ-63av1QhbJNDx4saAzgmFT9hE394alHUFHI=.ae58b01f-d6ef-45f3-8e42-fc7b7a552b8e@github.com>

On Wed, 29 Mar 2023 21:55:35 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Process lock-stack oops before inspecting them, when in foreign thread and not at safepoint. Add verifications.
>
> src/hotspot/share/runtime/threads.cpp line 1423:
> 
>> 1421: 
>> 1422: JavaThread* Threads::owning_thread_from_object(ThreadsList * t_list, oop obj) {
>> 1423:   assert(SafepointSynchronize::is_at_safepoint(), "not safe outside of safepoint");
> 
> `ObjectSynchronizer::get_lock_owner()` calls `Threads::owning_thread_from_object()`
> and I don't think you can assert that `ObjectSynchronizer::get_lock_owner()`  is only
> called from a safepoint. In particular, `ThreadSnapshot::initialize()` calls
> `ObjectSynchronizer::get_lock_owner()`  and I believe that `initialize()` function can
> be called from non-safepoint places with M&M APIs...

Update: In v35 you put back the `!UseFastLocking` check in `jmm_GetThreadInfo()`
so now the `assert()` won't fire, but you've again changed the behavior of that API
and now it will be able to observe fewer thread state changes than it did before.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1152526559

From dcubed at openjdk.org  Wed Mar 29 22:17:05 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 29 Mar 2023 22:17:05 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v35]
In-Reply-To: <-xn2Y5lZ-63av1QhbJNDx4saAzgmFT9hE394alHUFHI=.ae58b01f-d6ef-45f3-8e42-fc7b7a552b8e@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <NhMXsf7u09iGG1DS_E4zttNbHncJDp0OyAA6WBAPEOQ=.2446a8cc-8313-467b-963f-9c7c4c6bbca9@github.com>
 <P__u34D1QfjXJNUlF76aB9U0SkWf101xrnd6aweSwKo=.549bf5f2-bc8e-4d3f-9ca6-cd4d8b173f3b@github.com>
 <-xn2Y5lZ-63av1QhbJNDx4saAzgmFT9hE394alHUFHI=.ae58b01f-d6ef-45f3-8e42-fc7b7a552b8e@github.com>
Message-ID: <PP9_W05rSRMhMR7j4eQ1SROy-M3m0ECHhHZesSDDpwY=.ea2ba66f-3068-41fe-9e07-91808e6a3f8c@github.com>

On Wed, 29 Mar 2023 22:02:02 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> src/hotspot/share/runtime/threads.cpp line 1423:
>> 
>>> 1421: 
>>> 1422: JavaThread* Threads::owning_thread_from_object(ThreadsList * t_list, oop obj) {
>>> 1423:   assert(SafepointSynchronize::is_at_safepoint(), "not safe outside of safepoint");
>> 
>> `ObjectSynchronizer::get_lock_owner()` calls `Threads::owning_thread_from_object()`
>> and I don't think you can assert that `ObjectSynchronizer::get_lock_owner()`  is only
>> called from a safepoint. In particular, `ThreadSnapshot::initialize()` calls
>> `ObjectSynchronizer::get_lock_owner()`  and I believe that `initialize()` function can
>> be called from non-safepoint places with M&M APIs...
>
> Update: In v35 you put back the `!UseFastLocking` check in `jmm_GetThreadInfo()`
> so now the `assert()` won't fire, but you've again changed the behavior of that API
> and now it will be able to observe fewer thread state changes than it did before.

Please explain why you think this is "not safe". Yes, you can observe state that is in
the process of changing, but do you think that we'll see a crash with allowing
`Threads::owning_thread_from_object()` to be called from a non-safepoint place?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1152536799

From pchilanomate at openjdk.org  Wed Mar 29 22:18:36 2023
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 29 Mar 2023 22:18:36 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v9]
In-Reply-To: <5SO5rUZwV3SQ2w7t7mOwmP1jXjUVgl4g7NiT7cKi9LU=.355314c8-03ec-4a1e-80d8-e70e98868ecc@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <5SO5rUZwV3SQ2w7t7mOwmP1jXjUVgl4g7NiT7cKi9LU=.355314c8-03ec-4a1e-80d8-e70e98868ecc@github.com>
Message-ID: <OuUlFEljlkU8Xt6vnaAyu7DFS5ymckFGQcjdncpRVbA=.19174f7d-5473-4586-ad96-56d646d38b75@github.com>

On Wed, 29 Mar 2023 18:02:38 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The fix is to enable virtual threads support for late binding JVMTI agents.
>> The fix includes:
>> - New function `JvmtiEnvBase::enable_virtual_threads_notify_jvmti()` which does enabling JVMTI VTMS transition notifications in case of agent loaded into running VM. This function executes a VM operation counting VTMS transition bits in all `JavaThread`'s to correctly set the static counter `_VTMS_transition_count` needed for VTMS transition protocol.
>> - New function `JvmtiEnvBase::disable_virtual_threads_notify_jvmti()` which is needed for testing. It is used by the `WhiteBox` API.
>> - New WhiteBox function `WB_SetVirtualThreadsNotifyJvmtiMode(JNIEnv* env, jobject wb, jboolean enable)` needed for testing of this update.
>> - New regression test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
>> 
>> Testing:
>> - New test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
>> - The originally failed tests are expected to pass 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:
> 
>   review: updated correction of jt->jvmti_thread_state() links in VM_SetNotifyJvmtiEventsMode

Hi Serguei,

I took a look at the patch and looks good to me. I have a couple of comments though.

Thanks,
Patricio

src/hotspot/share/prims/jvmtiEnvBase.cpp line 1554:

> 1552:       }
> 1553:       // Correct jt->jvmti_thread_state() and jt->jvmti_vthread() if necessary.
> 1554:       // It was not maintained while notifyJvmti was disabled.

While trying to understand which exact situation we are trying to guard against with this code, I run the test without the sleeps and without this restore code and I got a crash when deleting a JvmtiThreadState (null dereference of _thread in the ~()). Probably the same crash you mentioned you had. But when debugging the crash I see that the problem is that the assumption that disabling the flag is done when no virtual threads are running is not guaranteed (see my comment there). So I think we are trying to address a case that shouldn't happen in the first place. Also not sure if applying this restore in all cases will be correct, since we might be somewhere at a transition. For example, a thread could have blocked right in the return from notifyJvmtiUnmount() in yieldContinuation(). It will looked like virtual because unmount() was not executed yet, and the jvmti_thread_state should be that of the platform thread because we never changed it when mounting. We should leave the state a
 s is but in here we would change it to the virtual thread's jvmti state. The only case I think it makes sense to do this restore steps when enabling the flag is for those threads that are outside a transition with a mounted virtual thread, since we want to adjust the jvmti_thread_state so that it looks right on the next unmount.
But in any case this is also only needed when using the WhiteBox methods right? In the intended case (no WhiteBox method used), after we execute this operation to enable the events, we will create the JvmtiThreadStates later in JvmtiExport::get_jvmti_interface() and the correct jvmti_thread_state and jvmti_vthread will be already set for each JavaThread. In that case can we only execute this restore code when using the WhiteBox API?

test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest.java line 142:

> 140:                 TestedThread thread = threads[i];
> 141:                 if (thread == null) {
> 142:                     break;

Bailing out here means we could later disable the flag while there are virtual threads running. If I comment out the first two sleeps in the main thread I can see that issue happening. To avoid relying on timing I suggest using a semaphore to wait at the beginning of finishThreads(), and signal at the end of startThreads().

-------------

PR Review: https://git.openjdk.org/jdk/pull/13133#pullrequestreview-1362140557
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1152508618
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1152514856

From pchilanomate at openjdk.org  Wed Mar 29 22:18:39 2023
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 29 Mar 2023 22:18:39 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v8]
In-Reply-To: <uZLGDh5UIBW0AYrgh4ndTUtnqNfp2zGgnx2zQm-kBaI=.f3d7e776-0e81-4272-bc31-2cdee9dc9d23@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <uZLGDh5UIBW0AYrgh4ndTUtnqNfp2zGgnx2zQm-kBaI=.f3d7e776-0e81-4272-bc31-2cdee9dc9d23@github.com>
Message-ID: <e2yRT6_VCygbdYXbK7epZoKuABw6KjBt3CqOrTajh_4=.6441c156-5ae6-4f5e-8e86-a5c2d7c15645@github.com>

On Tue, 28 Mar 2023 18:57:23 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The fix is to enable virtual threads support for late binding JVMTI agents.
>> The fix includes:
>> - New function `JvmtiEnvBase::enable_virtual_threads_notify_jvmti()` which does enabling JVMTI VTMS transition notifications in case of agent loaded into running VM. This function executes a VM operation counting VTMS transition bits in all `JavaThread`'s to correctly set the static counter `_VTMS_transition_count` needed for VTMS transition protocol.
>> - New function `JvmtiEnvBase::disable_virtual_threads_notify_jvmti()` which is needed for testing. It is used by the `WhiteBox` API.
>> - New WhiteBox function `WB_SetVirtualThreadsNotifyJvmtiMode(JNIEnv* env, jobject wb, jboolean enable)` needed for testing of this update.
>> - New regression test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
>> 
>> Testing:
>> - New test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
>> - The originally failed tests are expected to pass 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:
> 
>   fixed trailing spaces in two files

src/hotspot/share/prims/jvmtiEnvBase.cpp line 1550:

> 1548: 
> 1549:       if (jt->is_in_VTMS_transition()) {
> 1550:         count++;

For those threads that are in a transition when we enable the events, shouldn't we also set the jvmti_is_in_VTMS_transition field for the corresponding vthread as we do in JvmtiVTMSTransitionDisabler::start_VTMS_transition()? It seems a JvmtiVTMSTransitionDisabler that targets that particular vthread could otherwise proceed after the safepoint while that vthread is still in the transition. The "all" JvmtiVTMSTransitionDisabler won't proceed because that one does check the _VTMS_transition_count counter. I see that in general we won't have access to the vthread oop though.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1151313147

From dcubed at openjdk.org  Wed Mar 29 22:29:46 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 29 Mar 2023 22:29:46 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v37]
In-Reply-To: <Y7GnMCO0_ZCOlK7-0KrSaFrQY3EWb6mwtoZT8ZjmRBI=.cef3dbdb-7d55-45ee-b6f1-c3c614098513@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <Y7GnMCO0_ZCOlK7-0KrSaFrQY3EWb6mwtoZT8ZjmRBI=.cef3dbdb-7d55-45ee-b6f1-c3c614098513@github.com>
Message-ID: <PiUMVvIIcMbxkjPgwz6a3wDppWbV-it9TOfo5kqaHL4=.fdd77e91-3413-48e9-bcb0-d23d71c0feca@github.com>

On Wed, 29 Mar 2023 16:05:05 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Bounds check in lock-stack verification; only do watermark if we have one

Hmm... the latest doesn't build on my MBP13:


In file included from /System/Volumes/Data/work/shared/bug_hunt/8291555_for_jdk21.git/open/src/hotspot/share/runtime/objectMonitor.inline.hpp:33:
/System/Volumes/Data/work/shared/bug_hunt/8291555_for_jdk21.git/open/src/hotspot/share/runtime/lockStack.inline.hpp:95:56: error: use of undeclared identifier '_thread'
    StackWatermark* watermark = StackWatermarkSet::get(_thread, StackWatermarkKind::gc);
                                                       ^
1 error generated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1489414909

From dcubed at openjdk.org  Wed Mar 29 22:32:09 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 29 Mar 2023 22:32:09 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v37]
In-Reply-To: <Y7GnMCO0_ZCOlK7-0KrSaFrQY3EWb6mwtoZT8ZjmRBI=.cef3dbdb-7d55-45ee-b6f1-c3c614098513@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <Y7GnMCO0_ZCOlK7-0KrSaFrQY3EWb6mwtoZT8ZjmRBI=.cef3dbdb-7d55-45ee-b6f1-c3c614098513@github.com>
Message-ID: <xRjxQtXLm3rJ-dZaKiXgxIBqbWb4GUTDmiHepJ_zVFE=.f252a4d1-c7d4-4e21-bfd2-9e6c896c9375@github.com>

On Wed, 29 Mar 2023 16:05:05 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Bounds check in lock-stack verification; only do watermark if we have one

Ahhh...

class LockStack {
<snip>
#ifdef ASSERT
  JavaThread* const _thread;
#endif

so the release build is not happy...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1489417124

From psandoz at openjdk.org  Wed Mar 29 22:35:31 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 29 Mar 2023 22:35:31 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v15]
In-Reply-To: <jPVaoTe4yDNcopVbNL3HV2reRvc7C_wLR1uRdhfkgNM=.bd715322-36b4-4bfb-bee7-b25fa61fc73e@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <ewzYWsxSa9yHV7LwF7JOOD2PMOx1FeCNCRwgGDnTFd0=.42c628eb-3cdf-4f45-a4fe-da481850d834@github.com>
 <pYRtChaFVMs_cb5b2yJOF5-sgqyjzFpO3k_fkNH8Ezo=.3acc93cd-65b4-4722-8761-7f4e725fe68c@github.com>
 <jPVaoTe4yDNcopVbNL3HV2reRvc7C_wLR1uRdhfkgNM=.bd715322-36b4-4bfb-bee7-b25fa61fc73e@github.com>
Message-ID: <NfZ230hgiA7ucz6TasqN1epq9NxH9iCxA9Waxwiw0Kw=.534b3fec-a059-4abf-9a67-d1e356ff8378@github.com>

On Wed, 22 Mar 2023 14:07:14 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Back to @PaulSandoz  question - "how does the caller know what the structure contains?". The caller typically doesn't care too much about what the returned struct is. But it might care about which "values" can be captured. That said, the set of such interesting values, is not too surprising. As demonstrated in the example in the `Linker.capturedCallState` method, once the client knows the name (and "errno" is likely to be 90% case), everything else follows from there - as the layout can be used to obtain var handles for the required values.
>> 
>> But, perhaps, now that I write this, I realize that what @PaulSandoz might _really_ be asking is: how do I know that e.g. the returned struct will not contain e.g. nested structs, sequences, or other non-sense. So we might specify (in a normative way) that the returned layout is a struct layout, whose member layouts are one or more value layouts (possibly with some added padding layouts). The names of the value layouts reflect the names of the values that can be captured.
>> 
>> And _then_ we show an example of the layout we return for Windows/x64 (as that's more interesting).
>
> I've updated the specs as per how I interpret the comments above. Let me know your thoughts on this.

This is much clearer. Are the names of the struct members guaranteed to be symbols that can be found up via the linker's default lookup? i.e. a small set of important global variables.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1152550849

From kbarrett at openjdk.org  Wed Mar 29 22:38:50 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 29 Mar 2023 22:38:50 GMT
Subject: RFR: 8303805: [REDO] JDK-8302189 and JDK-8302799
In-Reply-To: <t1Ya5xyRJjsFPM3uG8zmOzRt0QwsGpNNJ34GnNEoevg=.79af01f1-e11c-41f2-af89-636db1b33066@github.com>
References: <LrDLITpu9mfyyL30QCXITE8nFEG-NfcZi0DvqvDF7Pg=.5d3fb62e-b689-42f0-ac75-4efee44ba2af@github.com>
 <t1Ya5xyRJjsFPM3uG8zmOzRt0QwsGpNNJ34GnNEoevg=.79af01f1-e11c-41f2-af89-636db1b33066@github.com>
Message-ID: <8PETXCN1cvq4--B7YvBwR9kRCzgZ27Lu0B1qxFcUGdI=.8d97fe1f-afef-4ec9-a8c8-d733eff77f8d@github.com>

On Wed, 29 Mar 2023 18:09:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this redo of the following changes:
>> 8302189: Mark assertion failures noreturn
>> 8302799: Refactor Debugging variable usage for noreturn crash reporting
>> 
>> The original change tripped over a bug the handling of noreturn and
>> __builtin_unreachable by Xcode12 (so probably generic clang12 and perhaps
>> earlier).  It seems to have been fixed in Xcode13 (and probably other uses of
>> clang13), but we're not yet ready to require that version.
>> 
>> As such, we've taken the original change and kludged around the problem for
>> now.  The kludge should be removed once we require clang13+.
>> 
>> As a reminder, the original change that was backed out did the following:
>> https://github.com/openjdk/jdk/pull/12845
>> 
>> (1) Changed how assertions were suppressed when running the various debugging
>> commands defined in debug.cpp.  The failure reporting functions used to just
>> return if the Debugging variable was set (by a debug command invocation).
>> Now, debug command invocation establishes a DebuggingContext object which
>> causes asserts to bypass the check entirely.
>> 
>> (2) Added [[noreturn]] attributes to error reporting functions declared in
>> debug.hpp.
>> 
>> This change consists of
>> (1) Reapply the change from PR#12845.
>> (2) A minor improvement to the DebuggingContext destructor.
>> (3) Replace uses of [[noreturn]] with new ATTRIBUTE_NORETURN macro (the kludge).
>> 
>> The ATTRIBUTE_NORETURN macro expands to `[[noreturn]]` unless the compiler is
>> clang and its version is less than 13, which it expands to nothing.
>> 
>> The replaced [[noreturn]] uses include both those added by JDK-8302189 and
>> those added by the earlier JDK-8302798.
>> 
>> This is problematic in the long run.  It prevents the removal of otherwise
>> obsolete and unreachable code following a call to a noreturn function.  We
>> have such code in various places because these functions were previously not
>> noreturn (and with this change still aren't for clang12 and prior).  It may
>> also require the inclusion of such code in future changes.  This may result in
>> change testing on Linux and/or Windows missing problems that will only show up
>> when testing on a clang-using platform.
>> 
>> We're really going to want to require a minimum of clang13 sooner rather than
>> later.  Unfortunately, we've run into other problems with Xcode13 and Xcode14,
>> and the aix-ppc maintainers have only just begun testing xlclang++ 17.1.  (The
>> version they have been using is based on clang3!)  Hence this kludge for now,
>> to permit use of gcc12 (JDK-8294031).
>> 
>> Testing:
>> mach5 tier1-7.
>
> This seems fine to me.

Thanks for reviews @coleenp and @dholmes-ora .

> src/hotspot/share/utilities/debug.cpp line 89:
> 
>> 87:     _enabled -= 1;              // Decrease nesting count.
>> 88:   } else {
>> 89:     fatal("Debugging nesting confusion");
> 
> Why did you make this change?  Isn't this an RAII object - how would this be a problem?

The earlier version (from PR#12845) used `assert(is_enabled(), "...")`.
But that's vacuous, being equivalent to `assert(false, ...)`.  (Yeah, that's
obvious.)

Of course it should never fail, but that's true for a lot of these kinds of
things.   I also thought about just discarding the check entirely.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13199#issuecomment-1489425653
PR Review Comment: https://git.openjdk.org/jdk/pull/13199#discussion_r1152553080

From mchung at openjdk.org  Wed Mar 29 23:03:42 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 29 Mar 2023 23:03:42 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v4]
In-Reply-To: <GOOPg0-P0Vc1ocNUzWRIbItENekN1ralramscyuF1kQ=.44aded10-e14f-4378-9173-a8126d21da04@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <GOOPg0-P0Vc1ocNUzWRIbItENekN1ralramscyuF1kQ=.44aded10-e14f-4378-9173-a8126d21da04@github.com>
Message-ID: <TYjRhJMMBuNCmOUob-bJWGWZ1_GTyRPJnQFB_fBVQLQ=.f3562b21-b062-4af8-a899-c8e9f9326800@github.com>

On Wed, 29 Mar 2023 08:00:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview.
>> 
>> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently.
>> 
>> In addition, there are a small number of implementation changes to sync up from the loom fibers branch:
>> 
>> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where  end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly.
>> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes.
>> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs.
>> - New system property to print a stack trace when a virtual thread sets its own value of a TL.
>> - ThreadPerTaskExecutor is changed to use FutureTask.
>> 
>> Testing: tier1-6.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix ThreadSleepEvent again

The stack walker change looks good.  I also reviewed other changes which look fine to me.

-------------

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13203#pullrequestreview-1364091585

From kbarrett at openjdk.org  Wed Mar 29 23:50:06 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 29 Mar 2023 23:50:06 GMT
Subject: RFR: 8303805: [REDO] JDK-8302189 and JDK-8302799 [v2]
In-Reply-To: <LrDLITpu9mfyyL30QCXITE8nFEG-NfcZi0DvqvDF7Pg=.5d3fb62e-b689-42f0-ac75-4efee44ba2af@github.com>
References: <LrDLITpu9mfyyL30QCXITE8nFEG-NfcZi0DvqvDF7Pg=.5d3fb62e-b689-42f0-ac75-4efee44ba2af@github.com>
Message-ID: <G_Pnv0reTNdkXp7an7Bi_hNjj8sfC_lS6vNuW2uI9d0=.62652bec-7911-4aa8-afcd-ccfe23ee843c@github.com>

> Please review this redo of the following changes:
> 8302189: Mark assertion failures noreturn
> 8302799: Refactor Debugging variable usage for noreturn crash reporting
> 
> The original change tripped over a bug the handling of noreturn and
> __builtin_unreachable by Xcode12 (so probably generic clang12 and perhaps
> earlier).  It seems to have been fixed in Xcode13 (and probably other uses of
> clang13), but we're not yet ready to require that version.
> 
> As such, we've taken the original change and kludged around the problem for
> now.  The kludge should be removed once we require clang13+.
> 
> As a reminder, the original change that was backed out did the following:
> https://github.com/openjdk/jdk/pull/12845
> 
> (1) Changed how assertions were suppressed when running the various debugging
> commands defined in debug.cpp.  The failure reporting functions used to just
> return if the Debugging variable was set (by a debug command invocation).
> Now, debug command invocation establishes a DebuggingContext object which
> causes asserts to bypass the check entirely.
> 
> (2) Added [[noreturn]] attributes to error reporting functions declared in
> debug.hpp.
> 
> This change consists of
> (1) Reapply the change from PR#12845.
> (2) A minor improvement to the DebuggingContext destructor.
> (3) Replace uses of [[noreturn]] with new ATTRIBUTE_NORETURN macro (the kludge).
> 
> The ATTRIBUTE_NORETURN macro expands to `[[noreturn]]` unless the compiler is
> clang and its version is less than 13, which it expands to nothing.
> 
> The replaced [[noreturn]] uses include both those added by JDK-8302189 and
> those added by the earlier JDK-8302798.
> 
> This is problematic in the long run.  It prevents the removal of otherwise
> obsolete and unreachable code following a call to a noreturn function.  We
> have such code in various places because these functions were previously not
> noreturn (and with this change still aren't for clang12 and prior).  It may
> also require the inclusion of such code in future changes.  This may result in
> change testing on Linux and/or Windows missing problems that will only show up
> when testing on a clang-using platform.
> 
> We're really going to want to require a minimum of clang13 sooner rather than
> later.  Unfortunately, we've run into other problems with Xcode13 and Xcode14,
> and the aix-ppc maintainers have only just begun testing xlclang++ 17.1.  (The
> version they have been using is based on clang3!)  Hence this kludge for now,
> to permit use of gcc12 (JDK-8294031).
> 
> Testing:
> mach5 tier1-7.

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 four additional commits since the last revision:

 - Merge branch 'master' into redo-noreturn
 - attribute macro
 - tidy destructor
 - redo from PR12845

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13199/files
  - new: https://git.openjdk.org/jdk/pull/13199/files/4cb2fa14..e0f3d3a3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13199&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13199&range=00-01

  Stats: 8977 lines in 243 files changed: 5930 ins; 1903 del; 1144 mod
  Patch: https://git.openjdk.org/jdk/pull/13199.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13199/head:pull/13199

PR: https://git.openjdk.org/jdk/pull/13199

From kbarrett at openjdk.org  Wed Mar 29 23:50:09 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 29 Mar 2023 23:50:09 GMT
Subject: Integrated: 8303805: [REDO] JDK-8302189 and JDK-8302799
In-Reply-To: <LrDLITpu9mfyyL30QCXITE8nFEG-NfcZi0DvqvDF7Pg=.5d3fb62e-b689-42f0-ac75-4efee44ba2af@github.com>
References: <LrDLITpu9mfyyL30QCXITE8nFEG-NfcZi0DvqvDF7Pg=.5d3fb62e-b689-42f0-ac75-4efee44ba2af@github.com>
Message-ID: <OZhPK1_fTgdvliHjcoK7v2KVS-_uOvVdF9CVJ5cEtxk=.6f204ad9-7d67-4a43-b7a7-8b25b47243fc@github.com>

On Mon, 27 Mar 2023 23:57:45 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this redo of the following changes:
> 8302189: Mark assertion failures noreturn
> 8302799: Refactor Debugging variable usage for noreturn crash reporting
> 
> The original change tripped over a bug the handling of noreturn and
> __builtin_unreachable by Xcode12 (so probably generic clang12 and perhaps
> earlier).  It seems to have been fixed in Xcode13 (and probably other uses of
> clang13), but we're not yet ready to require that version.
> 
> As such, we've taken the original change and kludged around the problem for
> now.  The kludge should be removed once we require clang13+.
> 
> As a reminder, the original change that was backed out did the following:
> https://github.com/openjdk/jdk/pull/12845
> 
> (1) Changed how assertions were suppressed when running the various debugging
> commands defined in debug.cpp.  The failure reporting functions used to just
> return if the Debugging variable was set (by a debug command invocation).
> Now, debug command invocation establishes a DebuggingContext object which
> causes asserts to bypass the check entirely.
> 
> (2) Added [[noreturn]] attributes to error reporting functions declared in
> debug.hpp.
> 
> This change consists of
> (1) Reapply the change from PR#12845.
> (2) A minor improvement to the DebuggingContext destructor.
> (3) Replace uses of [[noreturn]] with new ATTRIBUTE_NORETURN macro (the kludge).
> 
> The ATTRIBUTE_NORETURN macro expands to `[[noreturn]]` unless the compiler is
> clang and its version is less than 13, which it expands to nothing.
> 
> The replaced [[noreturn]] uses include both those added by JDK-8302189 and
> those added by the earlier JDK-8302798.
> 
> This is problematic in the long run.  It prevents the removal of otherwise
> obsolete and unreachable code following a call to a noreturn function.  We
> have such code in various places because these functions were previously not
> noreturn (and with this change still aren't for clang12 and prior).  It may
> also require the inclusion of such code in future changes.  This may result in
> change testing on Linux and/or Windows missing problems that will only show up
> when testing on a clang-using platform.
> 
> We're really going to want to require a minimum of clang13 sooner rather than
> later.  Unfortunately, we've run into other problems with Xcode13 and Xcode14,
> and the aix-ppc maintainers have only just begun testing xlclang++ 17.1.  (The
> version they have been using is based on clang3!)  Hence this kludge for now,
> to permit use of gcc12 (JDK-8294031).
> 
> Testing:
> mach5 tier1-7.

This pull request has now been integrated.

Changeset: b3ff8d1c
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b3ff8d1c89b0f968b7b5ec2105502778524e4e4a
Stats:     232 lines in 12 files changed: 180 ins; 19 del; 33 mod

8303805: [REDO] JDK-8302189 and JDK-8302799

Reviewed-by: dholmes, coleenp

-------------

PR: https://git.openjdk.org/jdk/pull/13199

From mcimadamore at openjdk.org  Wed Mar 29 23:52:04 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 29 Mar 2023 23:52:04 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v15]
In-Reply-To: <cVBIvlWcR-LFVl1oioaOFR-Xo2ZZnweP6uby_hxPYGU=.a61a7f36-9ebc-4051-9ca2-6f3bb5cd908c@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <cVBIvlWcR-LFVl1oioaOFR-Xo2ZZnweP6uby_hxPYGU=.a61a7f36-9ebc-4051-9ca2-6f3bb5cd908c@github.com>
Message-ID: <bvH6gsZpTzxMaJ7qeuFdDd7_HPR7B_z5tNVr3TiH9ic=.071272e4-b133-4d14-a9ca-c932ddb921ff@github.com>

On Wed, 29 Mar 2023 08:55:08 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> API changes for the FFM API (third preview)
>> 
>> Specdiff:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
>> 
>> Javadoc:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup finality

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 410:

> 408:  * wrapping a native pointer. For instance, if such pointer points to a C struct, the client might prefer to resize the
> 409:  * segment unsafely, to match the size of the struct (so that out-of-bounds access will be detected by the API). If the
> 410:  * size is known statically, using an address layout with the correct target layout might be preferable.

Suggestion:

 * true size of the zero-length memory segment is known statically, using an address layout with the correct target layout might be preferable.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1152595828

From mcimadamore at openjdk.org  Wed Mar 29 23:58:24 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 29 Mar 2023 23:58:24 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v15]
In-Reply-To: <NfZ230hgiA7ucz6TasqN1epq9NxH9iCxA9Waxwiw0Kw=.534b3fec-a059-4abf-9a67-d1e356ff8378@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <ewzYWsxSa9yHV7LwF7JOOD2PMOx1FeCNCRwgGDnTFd0=.42c628eb-3cdf-4f45-a4fe-da481850d834@github.com>
 <pYRtChaFVMs_cb5b2yJOF5-sgqyjzFpO3k_fkNH8Ezo=.3acc93cd-65b4-4722-8761-7f4e725fe68c@github.com>
 <jPVaoTe4yDNcopVbNL3HV2reRvc7C_wLR1uRdhfkgNM=.bd715322-36b4-4bfb-bee7-b25fa61fc73e@github.com>
 <NfZ230hgiA7ucz6TasqN1epq9NxH9iCxA9Waxwiw0Kw=.534b3fec-a059-4abf-9a67-d1e356ff8378@github.com>
Message-ID: <Vflz_mf7Dn9Pw0djIiu5ZZMPPCKi8Kr1uys0tfxaSbc=.5b33a2a4-389a-4811-818d-1789760d3de1@github.com>

On Wed, 29 Mar 2023 22:32:20 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> I've updated the specs as per how I interpret the comments above. Let me know your thoughts on this.
>
> This is much clearer. Are the names of the struct members guaranteed to be symbols that can be found up via the linker's default lookup? i.e. a small set of important global variables.

While they might be defined as global variable, I wouldn't read too much into this. Even `errno` is not really a global variable, but some thread local value that the native compiler knows about (e.g. setting the global variable doesn't really do much). Quoting from Linux man page:


errno  is  defined  by  the ISO C standard to be a modifiable lvalue of
       type int, and must not be explicitly declared; errno may  be  a  macro.
       errno  is  thread-local;  setting  it in one thread does not affect its
       value in any other thread.


This seems to imply that errno might even be something else. Given how the story goes for errno, I don't think we'd want to restrict the spec to state that these names should be discoverable via the lookup.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1152598834

From mcimadamore at openjdk.org  Thu Mar 30 00:05:55 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 30 Mar 2023 00:05:55 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v15]
In-Reply-To: <cVBIvlWcR-LFVl1oioaOFR-Xo2ZZnweP6uby_hxPYGU=.a61a7f36-9ebc-4051-9ca2-6f3bb5cd908c@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <cVBIvlWcR-LFVl1oioaOFR-Xo2ZZnweP6uby_hxPYGU=.a61a7f36-9ebc-4051-9ca2-6f3bb5cd908c@github.com>
Message-ID: <QjLVFpYkPnC-7YF0iWtPRksI9-qmyvStS2Ylko6yQXo=.aec5c3ad-9c79-4ac7-b6f0-e226efdbda6e@github.com>

On Wed, 29 Mar 2023 08:55:08 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> API changes for the FFM API (third preview)
>> 
>> Specdiff:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
>> 
>> Javadoc:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup finality

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 396:

> 394:  *}
> 395:  *
> 396:  * Alternatively, if the size of the foreign segment is known statically, clients can associate a

Suggestion:

 * Alternatively, if the true size of the zero-length memory segment is known statically, clients can associate a

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13079#discussion_r1152602321

From dholmes at openjdk.org  Thu Mar 30 00:09:15 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 30 Mar 2023 00:09:15 GMT
Subject: RFR: 8303210: [linux,
 Windows] Make UseSystemMemoryBarrier available as product flag [v5]
In-Reply-To: <JY1mNxFMaXyPJr33_UJeQxIV_alQrTfZIe3jQlHqeU8=.0699a676-6097-4b94-851d-4f3def943d3b@github.com>
References: <9eZo1xYNGhjMSC9lDXKtkO1eyU_H-Veuh1AeP3CPKbg=.69b6c4ff-a3ef-439f-8468-21fec9de1825@github.com>
 <w8QBaQtAtWepK1PRVY8uw8PO53iDnmtRt0P7o9jfDX8=.aa8c2e09-e9d6-4bff-8347-0033f0866774@github.com>
 <NN0F3COXkgmmz3U9A29FNw6yDRGeZNNZctR0719VHsY=.5fad2479-bf04-425c-b471-0f1c462d112e@github.com>
 <JY1mNxFMaXyPJr33_UJeQxIV_alQrTfZIe3jQlHqeU8=.0699a676-6097-4b94-851d-4f3def943d3b@github.com>
Message-ID: <dftKidRAkBDBiG5q8t98Jf5OJLXpX2bAiZA34YHWZgc=.85bc703c-1fe7-46f0-b374-603cffd746c3@github.com>

On Wed, 29 Mar 2023 10:47:49 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> > > Note: The feature requires at least Linux 4.14. The flag needs to be off for older versions.
> > 
> > 
> > In that case we should do a version check when trying to initialize, and at least warn if the OS is too old.
> 
> We already warn if the linux version is too old: https://github.com/openjdk/jdk/pull/12753/files#diff-aeec57d804d56002f26a85359fc4ac8b48cfc249d57c656a30a63fc6bf3457adR4496 Would you like the message to mention Linux 4.14?

I think I may have misunderstood that comment in JBS. I read it is as "you can turn this on in versions earlier than 4.14 but you shouldn't". If trying to turn it on in earlier versions just fails, then that is fine.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12753#issuecomment-1489502479

From dholmes at openjdk.org  Thu Mar 30 00:40:20 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 30 Mar 2023 00:40:20 GMT
Subject: RFR: 8303210: [linux,
 Windows] Make UseSystemMemoryBarrier available as product flag [v6]
In-Reply-To: <MTAr9TvUTRzfRWs3WlU_zq6-4m5_RaagR1UT_rmLfBA=.a1b0252d-5051-4bdd-9cf1-a815e5d5cb89@github.com>
References: <9eZo1xYNGhjMSC9lDXKtkO1eyU_H-Veuh1AeP3CPKbg=.69b6c4ff-a3ef-439f-8468-21fec9de1825@github.com>
 <4W40qd3bqnubOEUZZcDvuCtjsWn9VJeZnnS4eSxUm8s=.e408ce7b-8b02-4a97-b3c8-15836ce0e873@github.com>
 <MTAr9TvUTRzfRWs3WlU_zq6-4m5_RaagR1UT_rmLfBA=.a1b0252d-5051-4bdd-9cf1-a815e5d5cb89@github.com>
Message-ID: <UVRdB1uv-vKMeJyk13XaCC8YCWq_wa2rkYSu3Imw9R4=.8c020999-2434-4b8e-b0e9-6e9412cecfad@github.com>

On Wed, 29 Mar 2023 10:43:33 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> @dholmes: Thanks for reviewing! I had moved the flag initialization to `os::init_2()` because of your comment "Actually I think this code belongs in os::init() regardless.", but `os::init()` is too early. I actually agree with that somewhere in arguments.cpp would be nice, but I couldn't find a good place for it there.

Yeah I think I mistakenly thought this would only affect Linux - sorry. Duplicating in ` os::init2` on all platforms is not good. As for placement in arguments.cpp ... I would suggest adding a little function and calling it after `os::init_container_support()`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12753#issuecomment-1489520985

From dholmes at openjdk.org  Thu Mar 30 00:40:22 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 30 Mar 2023 00:40:22 GMT
Subject: RFR: 8303210: [linux,
 Windows] Make UseSystemMemoryBarrier available as product flag [v5]
In-Reply-To: <EAoEclpM_K_dojawFhzYJKaRsDD1W1_JMPc2h45o8wc=.1909c4c5-460c-43f5-8a52-21c321f64797@github.com>
References: <9eZo1xYNGhjMSC9lDXKtkO1eyU_H-Veuh1AeP3CPKbg=.69b6c4ff-a3ef-439f-8468-21fec9de1825@github.com>
 <w8QBaQtAtWepK1PRVY8uw8PO53iDnmtRt0P7o9jfDX8=.aa8c2e09-e9d6-4bff-8347-0033f0866774@github.com>
 <NN0F3COXkgmmz3U9A29FNw6yDRGeZNNZctR0719VHsY=.5fad2479-bf04-425c-b471-0f1c462d112e@github.com>
 <EAoEclpM_K_dojawFhzYJKaRsDD1W1_JMPc2h45o8wc=.1909c4c5-460c-43f5-8a52-21c321f64797@github.com>
Message-ID: <nLyMia5Arbym8u_qXAjyT16P0SnOgjAQGc4fMP-TRBw=.d938250a-0679-4aac-92f0-27c437797e73@github.com>

On Wed, 29 Mar 2023 10:30:45 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> src/hotspot/os/aix/os_aix.cpp line 2348:
>> 
>>> 2346:     }
>>> 2347:     FLAG_SET_ERGO(UseSystemMemoryBarrier, false);
>>> 2348:   }
>> 
>> This looks like a leftover ?? It shouldn't be here.
>
> Thanks! The one above in os::init was the leftover. The flags are initialized in `init_2`.

But this code isn't callling `SystemMemoryBarrier::initialize` ??

Ah now I see - this is a hard-coded "flag not supported". But there is no need to do that as `SystemMemoryBarrier::initialize` tells you whether it is supported or not.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12753#discussion_r1152619465

From sspitsyn at openjdk.org  Thu Mar 30 00:59:25 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 30 Mar 2023 00:59:25 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v8]
In-Reply-To: <e2yRT6_VCygbdYXbK7epZoKuABw6KjBt3CqOrTajh_4=.6441c156-5ae6-4f5e-8e86-a5c2d7c15645@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <uZLGDh5UIBW0AYrgh4ndTUtnqNfp2zGgnx2zQm-kBaI=.f3d7e776-0e81-4272-bc31-2cdee9dc9d23@github.com>
 <e2yRT6_VCygbdYXbK7epZoKuABw6KjBt3CqOrTajh_4=.6441c156-5ae6-4f5e-8e86-a5c2d7c15645@github.com>
Message-ID: <LaZ06w_MJRJpvdqTFi26wjRyr5UNXdyn-Z5yZbz0Wek=.11e486d0-6f4e-4ee9-8483-6da223285eae@github.com>

On Wed, 29 Mar 2023 01:52:18 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:
>> 
>>   fixed trailing spaces in two files
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1550:
> 
>> 1548: 
>> 1549:       if (jt->is_in_VTMS_transition()) {
>> 1550:         count++;
> 
> For those threads that are in a transition when we enable the events, shouldn't we also set the jvmti_is_in_VTMS_transition field for the corresponding vthread as we do in JvmtiVTMSTransitionDisabler::start_VTMS_transition()? It seems a JvmtiVTMSTransitionDisabler that targets that particular vthread could otherwise proceed after the safepoint while that vthread is still in the transition. The "all" JvmtiVTMSTransitionDisabler won't proceed because that one does check the _VTMS_transition_count counter. I see that in general we won't have access to the vthread oop though.

Nice catch, thanks! Fixed now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1152627288

From sspitsyn at openjdk.org  Thu Mar 30 01:14:28 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 30 Mar 2023 01:14:28 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v10]
In-Reply-To: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
Message-ID: <1kg4aiIq4QllkMfVInev4q-FtSem-N_xjuVpliowQAA=.dfcc7878-c186-4d31-9a93-2e7a22c404ab@github.com>

> The fix is to enable virtual threads support for late binding JVMTI agents.
> The fix includes:
> - New function `JvmtiEnvBase::enable_virtual_threads_notify_jvmti()` which does enabling JVMTI VTMS transition notifications in case of agent loaded into running VM. This function executes a VM operation counting VTMS transition bits in all `JavaThread`'s to correctly set the static counter `_VTMS_transition_count` needed for VTMS transition protocol.
> - New function `JvmtiEnvBase::disable_virtual_threads_notify_jvmti()` which is needed for testing. It is used by the `WhiteBox` API.
> - New WhiteBox function `WB_SetVirtualThreadsNotifyJvmtiMode(JNIEnv* env, jobject wb, jboolean enable)` needed for testing of this update.
> - New regression test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
> 
> Testing:
> - New test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
> - The originally failed tests are expected to pass 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:

  refactored jt->jvmti_thread_state() corrections in VM_SetNotifyJvmtiEventsMode

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13133/files
  - new: https://git.openjdk.org/jdk/pull/13133/files/c5d8a015..d1d4c030

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13133&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13133&range=08-09

  Stats: 74 lines in 2 files changed: 51 ins; 22 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13133.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13133/head:pull/13133

PR: https://git.openjdk.org/jdk/pull/13133

From dholmes at openjdk.org  Thu Mar 30 01:26:18 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 30 Mar 2023 01:26:18 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity
In-Reply-To: <4pbTAzlahWgsX0rZFLkvHBspPsH3f5sywPAw_J910xc=.459db480-16d3-47d0-a455-5c4eec0c0639@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
 <SZnG5gsawcOMCcQD-rPAOZwfX-Bi2HERjXXoGqNnewA=.48e6e59e-51ec-4a2b-8236-2885a291706a@github.com>
 <4pbTAzlahWgsX0rZFLkvHBspPsH3f5sywPAw_J910xc=.459db480-16d3-47d0-a455-5c4eec0c0639@github.com>
Message-ID: <x1lHAIaalJ9pVKb06mHEDytL5C_9w1IMpthN6hUvY-o=.a56e5a84-bf82-4078-bcc9-83dcf8c7eb4c@github.com>

On Wed, 29 Mar 2023 17:17:29 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Are there specific factors which would make it unreasonable to implement `sleep` in terms of `parkNanos`?

You would need to reissue any unparks received whilst sleeping.

Sleeping and parking are distinct thread states so it would be a lot of work in the Java code and in the VM to make such a change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13225#issuecomment-1489551942

From dholmes at openjdk.org  Thu Mar 30 01:31:18 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 30 Mar 2023 01:31:18 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity
In-Reply-To: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
Message-ID: <aiC2OQ_-DUYUsdfgamJ_LRBVPWdU55V-KYQszbsSqpI=.151c93ea-f09d-4626-b708-7772e80dab2d@github.com>

On Wed, 29 Mar 2023 11:28:53 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The documentation for that method clearly says the precision and accuracy are dependent on the underlying system behavior. However, it always rounds up `nanos` to 1ms when doing the actual sleep. This means users cannot do the micro-second precision sleeps, even when the underlying platform allows it. Sub-millisecond sleeps are useful to build interesting primitives, like the rate limiters that run with >1000 RPS.
> 
> When faced with this, some users reach for more awkward APIs like `java.util.concurrent.locks.LockSupport.parkNanos`. The use of that API for sleeps is not in line with its intent, and while it "seems to work", it might have interesting interactions with other uses of `LockSupport`. Additionally, these "sleeps" are no longer visible to monitoring tools as "normal sleeps", e.g. as `Thread.sleep` events. Therefore, it would be prudent to improve current `Thread.sleep(millis, nanos)` for sub-millisecond granularity. 
> 
> Fortunately, the underlying code is almost ready for this, at least on POSIX side. I skipped Windows paths, because its timers are still no good. Note that on both Linux and MacOS timers oversleep by about 50us. I have a few ideas how to improve the accuracy for them, which would be a topic for a separate PR.
> 
> Additional testing:
>   - [x] New regression test
>   - [x] New benchmark
>   - [x] Linux x86_64 `tier1`
>   - [x] Linux AArch64 `tier1`

src/hotspot/share/runtime/javaThread.cpp line 1981:

> 1979: }
> 1980: 
> 1981: bool JavaThread::sleep(jlong millis, jint nanos) {

You don't need the overloads at this level - the incoming call should always have millis and nanos, even if nanos is zero.

src/hotspot/share/utilities/globalDefinitions.hpp line 351:

> 349:     millis = max_secs * MILLIUNITS;
> 350:   }
> 351:   return millis_to_nanos(millis) + nanos;

This can now exceed the max_secs bound though.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1152639527
PR Review Comment: https://git.openjdk.org/jdk/pull/13225#discussion_r1152640056

From sspitsyn at openjdk.org  Thu Mar 30 01:35:32 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 30 Mar 2023 01:35:32 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v9]
In-Reply-To: <OuUlFEljlkU8Xt6vnaAyu7DFS5ymckFGQcjdncpRVbA=.19174f7d-5473-4586-ad96-56d646d38b75@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <5SO5rUZwV3SQ2w7t7mOwmP1jXjUVgl4g7NiT7cKi9LU=.355314c8-03ec-4a1e-80d8-e70e98868ecc@github.com>
 <OuUlFEljlkU8Xt6vnaAyu7DFS5ymckFGQcjdncpRVbA=.19174f7d-5473-4586-ad96-56d646d38b75@github.com>
Message-ID: <h4LtLLHAlnhcXjk86aLW3Z0hWTu_QFVQqHLujXyM4sY=.d413da77-0a70-4436-8b6e-4ce3ed47bf94@github.com>

On Wed, 29 Mar 2023 21:36:04 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:
>> 
>>   review: updated correction of jt->jvmti_thread_state() links in VM_SetNotifyJvmtiEventsMode
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1554:
> 
>> 1552:       }
>> 1553:       // Correct jt->jvmti_thread_state() and jt->jvmti_vthread() if necessary.
>> 1554:       // It was not maintained while notifyJvmti was disabled.
> 
> While trying to understand which exact situation we are trying to guard against with this code, I run the test without the sleeps and without this restore code and I got a crash when deleting a JvmtiThreadState (null dereference of _thread in the ~()). Probably the same crash you mentioned you had. But when debugging the crash I see that the problem is that the assumption that disabling the flag is done when no virtual threads are running is not guaranteed (see my comment there). So I think we are trying to address a case that shouldn't happen in the first place. Also not sure if applying this restore in all cases will be correct, since we might be somewhere at a transition. For example, a thread could have blocked right in the return from notifyJvmtiUnmount() in yieldContinuation(). It will looked like virtual because unmount() was not executed yet, and the jvmti_thread_state should be that of the platform thread because we never changed it when mounting. We should leave the state
  as is but in here we would change it to the virtual thread's jvmti state. The only case I think it makes sense to do this restore steps when enabling the flag is for those threads that are outside a transition with a mounted virtual thread, since we want to adjust the jvmti_thread_state so that it looks right on the next unmount.
> But in any case this is also only needed when using the WhiteBox methods right? In the intended case (no WhiteBox method used), after we execute this operation to enable the events, we will create the JvmtiThreadStates later in JvmtiExport::get_jvmti_interface() and the correct jvmti_thread_state and jvmti_vthread will be already set for each JavaThread. In that case can we only execute this restore code when using the WhiteBox API?

I've just pushed my update with refactoring of these corrections in `VM_SetNotifyJvmtiEventsMode` after discussion of this code with Leonid. I hope it resolved at least part of your concerns.
This kind of problem exists only when we disable+enable notifyJvmti events multiple times for testing purposes.
This code with corrections of jt->jvmti_thread_state() is not needed when we enable notifyJvmti events just once.
Your are correct that the ability to disable notifyJvmti events is implemented with using WhiteBox API.
My last update has a comment explaining this.

> In that case can we only execute this restore code when using the WhiteBox API?

This is a good suggestion which we already discussed privately with Leonid.
I've got an idea how to implement this check.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1152641723

From sspitsyn at openjdk.org  Thu Mar 30 02:03:23 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 30 Mar 2023 02:03:23 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v9]
In-Reply-To: <OuUlFEljlkU8Xt6vnaAyu7DFS5ymckFGQcjdncpRVbA=.19174f7d-5473-4586-ad96-56d646d38b75@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <5SO5rUZwV3SQ2w7t7mOwmP1jXjUVgl4g7NiT7cKi9LU=.355314c8-03ec-4a1e-80d8-e70e98868ecc@github.com>
 <OuUlFEljlkU8Xt6vnaAyu7DFS5ymckFGQcjdncpRVbA=.19174f7d-5473-4586-ad96-56d646d38b75@github.com>
Message-ID: <6ID-wSr38DrHzn45CCdg3DBaGzIJSXplXOqIg83pXSY=.2f187a59-251b-418b-a5d4-ebd7f11355bd@github.com>

On Wed, 29 Mar 2023 22:15:35 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:
>> 
>>   review: updated correction of jt->jvmti_thread_state() links in VM_SetNotifyJvmtiEventsMode
>
> Hi Serguei,
> 
> I took a look at the patch and looks good to me. I have a couple of comments though.
> 
> Thanks,
> Patricio

@pchilano Thank you for looking at this!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13133#issuecomment-1489576601

From sspitsyn at openjdk.org  Thu Mar 30 02:09:24 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 30 Mar 2023 02:09:24 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v9]
In-Reply-To: <OuUlFEljlkU8Xt6vnaAyu7DFS5ymckFGQcjdncpRVbA=.19174f7d-5473-4586-ad96-56d646d38b75@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <5SO5rUZwV3SQ2w7t7mOwmP1jXjUVgl4g7NiT7cKi9LU=.355314c8-03ec-4a1e-80d8-e70e98868ecc@github.com>
 <OuUlFEljlkU8Xt6vnaAyu7DFS5ymckFGQcjdncpRVbA=.19174f7d-5473-4586-ad96-56d646d38b75@github.com>
Message-ID: <qlQKj738_MKQ7uX_mhDyrIzSL3lQEergY1h2nLvBjQc=.2634500b-464c-4fa0-87f4-2abdecbf859d@github.com>

On Wed, 29 Mar 2023 21:44:56 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:
>> 
>>   review: updated correction of jt->jvmti_thread_state() links in VM_SetNotifyJvmtiEventsMode
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest.java line 142:
> 
>> 140:                 TestedThread thread = threads[i];
>> 141:                 if (thread == null) {
>> 142:                     break;
> 
> Bailing out here means we could later disable the flag while there are virtual threads running. If I comment out the first two sleeps in the main thread I can see that issue happening. To avoid relying on timing I suggest using a semaphore to wait at the beginning of finishThreads(), and signal at the end of startThreads().

Good comment, thanks.
I made `startThreads()` method to be synchronized instead of `startThread()`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1152656758

From fyang at openjdk.org  Thu Mar 30 03:43:45 2023
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 30 Mar 2023 03:43:45 GMT
Subject: RFR: JDK-8301496: Replace NULL with nullptr in cpu/riscv
In-Reply-To: <PNFHMzET147VzMQSySFk4koARUsEcb4lfNmh8JdScnk=.2dec4d00-90d6-4f5e-a89e-21d9aadb4d37@github.com>
References: <PNFHMzET147VzMQSySFk4koARUsEcb4lfNmh8JdScnk=.2dec4d00-90d6-4f5e-a89e-21d9aadb4d37@github.com>
Message-ID: <bKU7-ZR_Wg1V-lDA1sIP4PAPKumRHIc5WFNB-ZQW_yI=.4c30f308-b8e7-4f3e-b34c-68f907192504@github.com>

On Tue, 31 Jan 2023 11:39:59 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory cpu/riscv. Unfortunately the script that does the change isn't perfect, and so we
> need to comb through these manually to make sure nothing has gone wrong. I also review these changes but things slip past my eyes sometimes.
> 
> Here are some typical things to look out for:
> 
> 1. No changes but copyright header changed (probably because I reverted some changes but forgot the copyright).
> 2. Macros having their NULL changed to nullptr, these are added to the script when I find them. They should be NULL.
> 3. nullptr in comments and logs. We try to use lower case "null" in these cases as it reads better. An exception is made when code expressions are in a comment.
> 
> An example of this:
> 
> ```c++
> // This function returns null
> void* ret_null();
> // This function returns true if *x == nullptr
> bool is_nullptr(void** x);
> 
> 
> Note how `nullptr` participates in a code expression here, we really are talking about the specific value `nullptr`.
> 
> Thanks!

LGTM. Two nits.

src/hotspot/cpu/riscv/interp_masm_riscv.cpp line 1616:

> 1614:    beqz(t0, L);
> 1615:    stop("InterpreterMacroAssembler::call_VM_leaf_base:"
> 1616:         " last_sp != null");

Maybe: " last_sp isn't null" ?

src/hotspot/cpu/riscv/interp_masm_riscv.cpp line 1643:

> 1641:     beqz(t0, L);
> 1642:     stop("InterpreterMacroAssembler::call_VM_base:"
> 1643:          " last_sp != null");

Similar here. Maybe: " last_sp isn't null" ?

-------------

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12324#pullrequestreview-1364274565
PR Review Comment: https://git.openjdk.org/jdk/pull/12324#discussion_r1152695397
PR Review Comment: https://git.openjdk.org/jdk/pull/12324#discussion_r1152695612

From sspitsyn at openjdk.org  Thu Mar 30 03:48:02 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 30 Mar 2023 03:48:02 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v11]
In-Reply-To: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
Message-ID: <LfvBlc24I6mFBlLpRIZEyg73PMUFzKdRduWvIDcPisg=.9239f85a-26b6-40bb-8bd8-540efe494876@github.com>

> The fix is to enable virtual threads support for late binding JVMTI agents.
> The fix includes:
> - New function `JvmtiEnvBase::enable_virtual_threads_notify_jvmti()` which does enabling JVMTI VTMS transition notifications in case of agent loaded into running VM. This function executes a VM operation counting VTMS transition bits in all `JavaThread`'s to correctly set the static counter `_VTMS_transition_count` needed for VTMS transition protocol.
> - New function `JvmtiEnvBase::disable_virtual_threads_notify_jvmti()` which is needed for testing. It is used by the `WhiteBox` API.
> - New WhiteBox function `WB_SetVirtualThreadsNotifyJvmtiMode(JNIEnv* env, jobject wb, jboolean enable)` needed for testing of this update.
> - New regression test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
> 
> Testing:
> - New test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
> - The originally failed tests are expected to pass 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:

  one more review round fixes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13133/files
  - new: https://git.openjdk.org/jdk/pull/13133/files/d1d4c030..d05ed921

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13133&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13133&range=09-10

  Stats: 20 lines in 2 files changed: 15 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/13133.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13133/head:pull/13133

PR: https://git.openjdk.org/jdk/pull/13133

From fyang at openjdk.org  Thu Mar 30 04:12:39 2023
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 30 Mar 2023 04:12:39 GMT
Subject: RFR: JDK-8301496: Replace NULL with nullptr in cpu/riscv
In-Reply-To: <PNFHMzET147VzMQSySFk4koARUsEcb4lfNmh8JdScnk=.2dec4d00-90d6-4f5e-a89e-21d9aadb4d37@github.com>
References: <PNFHMzET147VzMQSySFk4koARUsEcb4lfNmh8JdScnk=.2dec4d00-90d6-4f5e-a89e-21d9aadb4d37@github.com>
Message-ID: <DmpnXuZAVe94uVCMBxynspzazo0CCa6anDAiuEqobIY=.16ef721f-e472-4926-9219-7934e6480006@github.com>

On Tue, 31 Jan 2023 11:39:59 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory cpu/riscv. Unfortunately the script that does the change isn't perfect, and so we
> need to comb through these manually to make sure nothing has gone wrong. I also review these changes but things slip past my eyes sometimes.
> 
> Here are some typical things to look out for:
> 
> 1. No changes but copyright header changed (probably because I reverted some changes but forgot the copyright).
> 2. Macros having their NULL changed to nullptr, these are added to the script when I find them. They should be NULL.
> 3. nullptr in comments and logs. We try to use lower case "null" in these cases as it reads better. An exception is made when code expressions are in a comment.
> 
> An example of this:
> 
> ```c++
> // This function returns null
> void* ret_null();
> // This function returns true if *x == nullptr
> bool is_nullptr(void** x);
> 
> 
> Note how `nullptr` participates in a code expression here, we really are talking about the specific value `nullptr`.
> 
> Thanks!

Changes requested by fyang (Reviewer).

src/hotspot/cpu/riscv/interpreterRT_riscv.cpp line 230:

> 228:   virtual void pass_object() {
> 229:     intptr_t* addr = single_slot_addr();
> 230:     intptr_t value = *addr == 0 ? nullptr : (intptr_t)addr;

PS: I got compile errors when doing a native build with GCC-11.3.0:

474 /home/fyang/openjdk-jdk/src/hotspot/cpu/riscv/interpreterRT_riscv.cpp: In member function 'virtual void SlowSignatureHandler::pass_object()':
475 /home/fyang/openjdk-jdk/src/hotspot/cpu/riscv/interpreterRT_riscv.cpp:230:33: error: operands to '?:' have different types 'std::nullptr_t' and 'intptr_t' {aka 'long int'}
476   230 |     intptr_t value = *addr == 0 ? nullptr : (intptr_t)addr;
477       |                      ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~


I think we should change the "nullptr" here into "(intptr_t)nullptr".

-------------

PR Review: https://git.openjdk.org/jdk/pull/12324#pullrequestreview-1364292576
PR Review Comment: https://git.openjdk.org/jdk/pull/12324#discussion_r1152708517

From fyang at openjdk.org  Thu Mar 30 05:33:17 2023
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 30 Mar 2023 05:33:17 GMT
Subject: RFR: 8305008: RISC-V: Factor out immediate checking functions from
 assembler_riscv.inline.hpp [v2]
In-Reply-To: <E-CIFmWm7kSmdB0j0UUCd9F2sbzryngHDCgbKoSd8vA=.8485fbbe-6476-43fa-90f1-5bba60378403@github.com>
References: <zOPJRtrXmBK17ZgSm-THTp8qCXhh7tSNg6VRVFoLz9Y=.763009a8-a651-499d-a0e1-f114f3c842f0@github.com>
 <E-CIFmWm7kSmdB0j0UUCd9F2sbzryngHDCgbKoSd8vA=.8485fbbe-6476-43fa-90f1-5bba60378403@github.com>
Message-ID: <7qMov3WMJah0j4Jk6DJh9gW-DlqFgBqsjz9KAxJm-ag=.3a1ac25d-db38-4d30-838e-ff67a702093e@github.com>

On Tue, 28 Mar 2023 10:08:15 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

>> The call-point to 'is_imm_in_range', 'is_unsigned_imm_in_range' and 'is_offset_in_range' in assembler_riscv.inline.hpp could to be replaced with shared code function 'is_simm' and 'is_uimm'.
>> 
>> For 'is_imm_in_range', if align_bits = 0, then the call point can be changed to call 'is_simm'. If align_bits = 1, then an additional summation judgement is added to determine if it is a multiple of 2. For 'is_unsigned_imm_in_range', we can first determine if it is greater than 0, and then call 'is_uimm' further. 'is_offset_in_range' can be changed directly to call 'is_simm'. This patch also refactored for is_valid_riscv64_address and movptr.
>> 
>> This patch removed the original functions from assembler_riscv.inline.hpp and defined some fixed-width checking functions based on the number of immediate or offset bits in the spec[1]. At the same time, we also adjusted two includes to fix the compilation error after the modification.
>> 
>> This patch also renames the function 'operand_valid_for_add_immediate' to 'operand_valid_for_add_sub_immediate' to make it consistent with its usage.
>> 
>> Finally, this patch modified the return value in os::non_memory_address_word to avoid an imm64 value of -1 in MacroAssembler::movptr.
>> 
>> [1] https://github.com/riscv/riscv-isa-manual/releases/download/draft-20230131-c0b298a/riscv-spec.pdf
>> 
>> ### Testing:
>> 
>> On Unmatched with release build:
>> - [x] Tier1 tests
>> - [x] Tier2 tests
>> - [x] Tier3 tests
>
> Dingli Zhang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove unecessary zero checking
>  - Fix assert

Changes requested by fyang (Reviewer).

src/hotspot/cpu/riscv/riscv.ad line 1701:

> 1699:   if (Assembler::is_simm12(offset)) {
> 1700:     __ addi(as_Register(reg), sp, offset);
> 1701:   } else if (Assembler::is_simm32(offset)) {

I don't think this check is necessary since  type of 'offset' is int.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13202#pullrequestreview-1364356397
PR Review Comment: https://git.openjdk.org/jdk/pull/13202#discussion_r1152752600

From dzhang at openjdk.org  Thu Mar 30 05:52:03 2023
From: dzhang at openjdk.org (Dingli Zhang)
Date: Thu, 30 Mar 2023 05:52:03 GMT
Subject: RFR: 8305008: RISC-V: Factor out immediate checking functions from
 assembler_riscv.inline.hpp [v3]
In-Reply-To: <zOPJRtrXmBK17ZgSm-THTp8qCXhh7tSNg6VRVFoLz9Y=.763009a8-a651-499d-a0e1-f114f3c842f0@github.com>
References: <zOPJRtrXmBK17ZgSm-THTp8qCXhh7tSNg6VRVFoLz9Y=.763009a8-a651-499d-a0e1-f114f3c842f0@github.com>
Message-ID: <W7YgamnP5c4-zxjc1c9szzhuwkg6EGDVbqNFr1PyqBg=.683dd5f9-9b6e-4d53-9d4e-5f57b7b86725@github.com>

> The call-point to 'is_imm_in_range', 'is_unsigned_imm_in_range' and 'is_offset_in_range' in assembler_riscv.inline.hpp could to be replaced with shared code function 'is_simm' and 'is_uimm'.
> 
> For 'is_imm_in_range', if align_bits = 0, then the call point can be changed to call 'is_simm'. If align_bits = 1, then an additional summation judgement is added to determine if it is a multiple of 2. For 'is_unsigned_imm_in_range', we can first determine if it is greater than 0, and then call 'is_uimm' further. 'is_offset_in_range' can be changed directly to call 'is_simm'. This patch also refactored for is_valid_riscv64_address and movptr.
> 
> This patch removed the original functions from assembler_riscv.inline.hpp and defined some fixed-width checking functions based on the number of immediate or offset bits in the spec[1]. At the same time, we also adjusted two includes to fix the compilation error after the modification.
> 
> This patch also renames the function 'operand_valid_for_add_immediate' to 'operand_valid_for_add_sub_immediate' to make it consistent with its usage.
> 
> Finally, this patch modified the return value in os::non_memory_address_word to avoid an imm64 value of -1 in MacroAssembler::movptr.
> 
> [1] https://github.com/riscv/riscv-isa-manual/releases/download/draft-20230131-c0b298a/riscv-spec.pdf
> 
> ### Testing:
> 
> On Unmatched with release build:
> - [x] Tier1 tests
> - [x] Tier2 tests
> - [x] Tier3 tests

Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision:

  Remove unnecessary checking

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13202/files
  - new: https://git.openjdk.org/jdk/pull/13202/files/73636dca..2dfd4bc5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13202&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13202&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13202.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13202/head:pull/13202

PR: https://git.openjdk.org/jdk/pull/13202

From dzhang at openjdk.org  Thu Mar 30 05:52:07 2023
From: dzhang at openjdk.org (Dingli Zhang)
Date: Thu, 30 Mar 2023 05:52:07 GMT
Subject: RFR: 8305008: RISC-V: Factor out immediate checking functions from
 assembler_riscv.inline.hpp [v2]
In-Reply-To: <7qMov3WMJah0j4Jk6DJh9gW-DlqFgBqsjz9KAxJm-ag=.3a1ac25d-db38-4d30-838e-ff67a702093e@github.com>
References: <zOPJRtrXmBK17ZgSm-THTp8qCXhh7tSNg6VRVFoLz9Y=.763009a8-a651-499d-a0e1-f114f3c842f0@github.com>
 <E-CIFmWm7kSmdB0j0UUCd9F2sbzryngHDCgbKoSd8vA=.8485fbbe-6476-43fa-90f1-5bba60378403@github.com>
 <7qMov3WMJah0j4Jk6DJh9gW-DlqFgBqsjz9KAxJm-ag=.3a1ac25d-db38-4d30-838e-ff67a702093e@github.com>
Message-ID: <ZjV98PID4kVZSkFOyNPU6wEu--GWUk9hBJyQBhgiLDo=.0a32ccda-9f8d-475f-be86-49c885e17d14@github.com>

On Thu, 30 Mar 2023 05:30:07 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Dingli Zhang has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove unecessary zero checking
>>  - Fix assert
>
> src/hotspot/cpu/riscv/riscv.ad line 1701:
> 
>> 1699:   if (Assembler::is_simm12(offset)) {
>> 1700:     __ addi(as_Register(reg), sp, offset);
>> 1701:   } else if (Assembler::is_simm32(offset)) {
> 
> I don't think this check is necessary since  type of 'offset' is int.

Thanks! Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13202#discussion_r1152762180

From stuefe at openjdk.org  Thu Mar 30 06:17:08 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 30 Mar 2023 06:17:08 GMT
Subject: RFR: JDK-8304815: Use NMT for more precise hs_err location
 printing [v5]
In-Reply-To: <DPqsrXUm5sJjcxDGZW6QSvdpu83LBhwXreIJU7LXqjI=.dfe3de5e-919a-494d-a8dd-0622d1ee0c65@github.com>
References: <DPqsrXUm5sJjcxDGZW6QSvdpu83LBhwXreIJU7LXqjI=.dfe3de5e-919a-494d-a8dd-0622d1ee0c65@github.com>
Message-ID: <GoPHJDBSAx0Xu_QYr4cINm_zvcGciuoWucX84tkSktY=.d3b9fdae-01cf-4c3a-846a-51d785b6a255@github.com>

> (This is a byproduct of work on the arm port for https://github.com/openjdk/jdk/pull/10907. I needed better debugging information in the hs-err file and in gdb.)
> 
> Back in 2022 @zhengyu123 had the very nice idea of using NMT mapping info for smartening up pp in gdb: [JDK-8280289](https://bugs.openjdk.org/browse/JDK-8280289).
> 
> The same idea can be applied to hs_err file location printing. NMT has information about all its mappings and can tell us where it thinks a given unknown pointer points into.
> 
> This could be even more useful if the "find malloc block" part of that functionality would be smarter. As it is now, it only works if the pointer in question points to the start of a user-allocated area. Would be nice if the code could (carefully) search for the next valid-looking malloc header instead.
> 
> --------------
> 
> This patch does this: we introduce a new API, MemTracker::print_containing_region(void*), that tries to make sense of a given unknown pointer.
> 
> It will search its mmap regions and print those if found. For malloc'ed pointers, it will carefully sniff out the immediate surroundings of the block, trying to find what looks like a valid malloc header. It uses SafeFetch to not trip over unmapped or protected pages. Note that, of course, we may get false recognition positives if it finds something that looks like a valid header. But even that could be useful (e.g. a remnant dead header may indicate we access memory after free).
> 
> Looks like this (its arm, so 32-bit pointers):
> 
> 
> Register to memory mapping:
> 
> ->  r0  = 0x728a6ae0 into life malloced block starting at 0x728a6ae0, size 104, tag mtSynchronizer
> ->  r1  = 0x75b02010 into life malloced block starting at 0x75b02010, size 184, tag mtObjectMonitor
> ->  r2  = 0x728a6ae0 into life malloced block starting at 0x728a6ae0, size 104, tag mtSynchronizer
>     r3  = 0x0 is nullptr
> ->  r4  = 0x728a6ae0 into life malloced block starting at 0x728a6ae0, size 104, tag mtSynchronizer
>     r5  = 0xb6d3bbc8: <offset 0x018f6bc8> in /shared/projects/openjdk/jdk-jdk/output-fastdebug-arm/images/jdk/lib/server/libjvm.so at 0xb5445000
>     r6  = 0xffffffff is an unknown value
>     r7  = 0x0 is nullptr
>     r8  = 0x0000000a is an unknown value
>     r9  = 0x728a4308 is a thread
>     r10 = 0x0000000b is an unknown value
> ->  fp  = 0x753fe8cc in mmap'd memory region [0x75380000 - 0x75400000] by Thread Stack
>     r12 = 0x0 is nullptr
> ->  sp  = 0x753fe8b0 in mmap'd memory region [0x75380000 - 0x75400000] by Thread Stack
>     lr  = 0xb69bc1d0: <offset 0x015771d0> in /shared/projects/openjdk/jdk-jdk/output-fastdebug-arm/images/jdk/lib/server/libjvm.so at 0xb5445000
>     pc  = 0xb69c8670: <offset 0x01583670> in /shared/projects/openjdk/jdk-jdk/output-fastdebug-arm/images/jdk/lib/server/libjvm.so at 0xb5445000
> 
> 
> 
> The small caveat here is that NMT reporting needs ThreadCritical, and thus using it for location printing may block error reporting if it crashed inside a ThreadCritical section. We face the same issue today when printing the NMT report as part of the hs-err file. 
> 
> I think the usefulness of these printouts justify this risk. However I opened https://bugs.openjdk.org/browse/JDK-8304824 to investigate a better locking strategy for NMT.

Thomas Stuefe has updated the pull request incrementally with three additional commits since the last revision:

 - disable debug output
 - Feedback Johan; change loop for live blocks to have preference
 - Feedback Johan

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13162/files
  - new: https://git.openjdk.org/jdk/pull/13162/files/be8c1142..07d70fd9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13162&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13162&range=03-04

  Stats: 127 lines in 4 files changed: 80 ins; 22 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/13162.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13162/head:pull/13162

PR: https://git.openjdk.org/jdk/pull/13162

From stuefe at openjdk.org  Thu Mar 30 06:17:11 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 30 Mar 2023 06:17:11 GMT
Subject: RFR: JDK-8304815: Use NMT for more precise hs_err location
 printing [v4]
In-Reply-To: <B-4Nf5R_pq0iXq-qk_SgL3Lb0nEYlZMSIbIrQ9PNUpc=.7075ac44-4517-4b04-b4bc-01c205195c21@github.com>
References: <DPqsrXUm5sJjcxDGZW6QSvdpu83LBhwXreIJU7LXqjI=.dfe3de5e-919a-494d-a8dd-0622d1ee0c65@github.com>
 <I6toqtDMVqNOMeN42fjnOeCUEGkx27GPsdbr_fWM4sg=.95aa5d1f-f117-4f4b-90da-2093bb205ea3@github.com>
 <B-4Nf5R_pq0iXq-qk_SgL3Lb0nEYlZMSIbIrQ9PNUpc=.7075ac44-4517-4b04-b4bc-01c205195c21@github.com>
Message-ID: <ZMPEmCgCSVj731rDlp6yYeX6J8qfb9i71uReN3ZwziI=.97ef23ea-dba9-47c0-8685-a73c8f007b67@github.com>

On Fri, 24 Mar 2023 11:44:47 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More small fixes
>
> Thanks!
> 
> I've got some requested changes, but I like it as a whole.

@jdksjolen Thank you for your review!

I took your suggested loop changes, but then changed them again to change the logic:
- if we find a live block, that's it
- if we find a dead block, we print it only if we don't find a better live block down the address range.

I also added tests for the dead case.

Manually tested on x64 and x86.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13162#issuecomment-1489752801

From stuefe at openjdk.org  Thu Mar 30 06:17:14 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 30 Mar 2023 06:17:14 GMT
Subject: RFR: JDK-8304815: Use NMT for more precise hs_err location
 printing [v4]
In-Reply-To: <wxRXupVDA2HI6L-N1LYkRO4mbOI7yCYqHu5UbnahLg4=.7bd100d2-9a27-446b-b176-8ad926f6974e@github.com>
References: <DPqsrXUm5sJjcxDGZW6QSvdpu83LBhwXreIJU7LXqjI=.dfe3de5e-919a-494d-a8dd-0622d1ee0c65@github.com>
 <I6toqtDMVqNOMeN42fjnOeCUEGkx27GPsdbr_fWM4sg=.95aa5d1f-f117-4f4b-90da-2093bb205ea3@github.com>
 <B-4Nf5R_pq0iXq-qk_SgL3Lb0nEYlZMSIbIrQ9PNUpc=.7075ac44-4517-4b04-b4bc-01c205195c21@github.com>
 <wxRXupVDA2HI6L-N1LYkRO4mbOI7yCYqHu5UbnahLg4=.7bd100d2-9a27-446b-b176-8ad926f6974e@github.com>
Message-ID: <4_EWYqroOQbxIfoxxtUdyhzaWOBjveeseZ9S9S95Srk=.8c24510a-052c-4fa9-a5f0-ecf624a80800@github.com>

On Fri, 24 Mar 2023 11:43:08 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> test/hotspot/gtest/nmt/test_nmt_locationprinting.cpp line 31:
>> 
>>> 29: #include "unittest.hpp"
>>> 30: 
>>> 31: //#define LOG_PLEASE
>> 
>> Outdated?
>
> Or meant as a hint?

I added a comment; one can uncomment the LOG_PLEASE for more test output (its a pragmatic thing I do in other gtests too). The macro lives in testUtils.hpp.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13162#discussion_r1152776850

From stuefe at openjdk.org  Thu Mar 30 06:19:36 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 30 Mar 2023 06:19:36 GMT
Subject: RFR: JDK-8304815: Use NMT for more precise hs_err location
 printing [v6]
In-Reply-To: <DPqsrXUm5sJjcxDGZW6QSvdpu83LBhwXreIJU7LXqjI=.dfe3de5e-919a-494d-a8dd-0622d1ee0c65@github.com>
References: <DPqsrXUm5sJjcxDGZW6QSvdpu83LBhwXreIJU7LXqjI=.dfe3de5e-919a-494d-a8dd-0622d1ee0c65@github.com>
Message-ID: <Sx4MHQ-y1zWFB1ndVaWwmdFSF7PBxYrnukHSS_k12TQ=.42779cd0-b064-4638-9004-7683d4bd18ca@github.com>

> (This is a byproduct of work on the arm port for https://github.com/openjdk/jdk/pull/10907. I needed better debugging information in the hs-err file and in gdb.)
> 
> Back in 2022 @zhengyu123 had the very nice idea of using NMT mapping info for smartening up pp in gdb: [JDK-8280289](https://bugs.openjdk.org/browse/JDK-8280289).
> 
> The same idea can be applied to hs_err file location printing. NMT has information about all its mappings and can tell us where it thinks a given unknown pointer points into.
> 
> This could be even more useful if the "find malloc block" part of that functionality would be smarter. As it is now, it only works if the pointer in question points to the start of a user-allocated area. Would be nice if the code could (carefully) search for the next valid-looking malloc header instead.
> 
> --------------
> 
> This patch does this: we introduce a new API, MemTracker::print_containing_region(void*), that tries to make sense of a given unknown pointer.
> 
> It will search its mmap regions and print those if found. For malloc'ed pointers, it will carefully sniff out the immediate surroundings of the block, trying to find what looks like a valid malloc header. It uses SafeFetch to not trip over unmapped or protected pages. Note that, of course, we may get false recognition positives if it finds something that looks like a valid header. But even that could be useful (e.g. a remnant dead header may indicate we access memory after free).
> 
> Looks like this (its arm, so 32-bit pointers):
> 
> 
> Register to memory mapping:
> 
> ->  r0  = 0x728a6ae0 into life malloced block starting at 0x728a6ae0, size 104, tag mtSynchronizer
> ->  r1  = 0x75b02010 into life malloced block starting at 0x75b02010, size 184, tag mtObjectMonitor
> ->  r2  = 0x728a6ae0 into life malloced block starting at 0x728a6ae0, size 104, tag mtSynchronizer
>     r3  = 0x0 is nullptr
> ->  r4  = 0x728a6ae0 into life malloced block starting at 0x728a6ae0, size 104, tag mtSynchronizer
>     r5  = 0xb6d3bbc8: <offset 0x018f6bc8> in /shared/projects/openjdk/jdk-jdk/output-fastdebug-arm/images/jdk/lib/server/libjvm.so at 0xb5445000
>     r6  = 0xffffffff is an unknown value
>     r7  = 0x0 is nullptr
>     r8  = 0x0000000a is an unknown value
>     r9  = 0x728a4308 is a thread
>     r10 = 0x0000000b is an unknown value
> ->  fp  = 0x753fe8cc in mmap'd memory region [0x75380000 - 0x75400000] by Thread Stack
>     r12 = 0x0 is nullptr
> ->  sp  = 0x753fe8b0 in mmap'd memory region [0x75380000 - 0x75400000] by Thread Stack
>     lr  = 0xb69bc1d0: <offset 0x015771d0> in /shared/projects/openjdk/jdk-jdk/output-fastdebug-arm/images/jdk/lib/server/libjvm.so at 0xb5445000
>     pc  = 0xb69c8670: <offset 0x01583670> in /shared/projects/openjdk/jdk-jdk/output-fastdebug-arm/images/jdk/lib/server/libjvm.so at 0xb5445000
> 
> 
> 
> The small caveat here is that NMT reporting needs ThreadCritical, and thus using it for location printing may block error reporting if it crashed inside a ThreadCritical section. We face the same issue today when printing the NMT report as part of the hs-err file. 
> 
> I think the usefulness of these printouts justify this risk. However I opened https://bugs.openjdk.org/browse/JDK-8304824 to investigate a better locking strategy for NMT.

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  fix comment, update copyright

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13162/files
  - new: https://git.openjdk.org/jdk/pull/13162/files/07d70fd9..e5a4a9f1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13162&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13162&range=04-05

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13162.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13162/head:pull/13162

PR: https://git.openjdk.org/jdk/pull/13162

From fyang at openjdk.org  Thu Mar 30 07:46:19 2023
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 30 Mar 2023 07:46:19 GMT
Subject: RFR: 8305008: RISC-V: Factor out immediate checking functions from
 assembler_riscv.inline.hpp [v3]
In-Reply-To: <W7YgamnP5c4-zxjc1c9szzhuwkg6EGDVbqNFr1PyqBg=.683dd5f9-9b6e-4d53-9d4e-5f57b7b86725@github.com>
References: <zOPJRtrXmBK17ZgSm-THTp8qCXhh7tSNg6VRVFoLz9Y=.763009a8-a651-499d-a0e1-f114f3c842f0@github.com>
 <W7YgamnP5c4-zxjc1c9szzhuwkg6EGDVbqNFr1PyqBg=.683dd5f9-9b6e-4d53-9d4e-5f57b7b86725@github.com>
Message-ID: <oE6SdvdRs1cV4XKLLfk2R_I1K2eBoKidouNVXmoJ8Rc=.1416e03f-5f98-472c-a475-0125f69c204b@github.com>

On Thu, 30 Mar 2023 05:52:03 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

>> The call-point to 'is_imm_in_range', 'is_unsigned_imm_in_range' and 'is_offset_in_range' in assembler_riscv.inline.hpp could to be replaced with shared code function 'is_simm' and 'is_uimm'.
>> 
>> For 'is_imm_in_range', if align_bits = 0, then the call point can be changed to call 'is_simm'. If align_bits = 1, then an additional summation judgement is added to determine if it is a multiple of 2. For 'is_unsigned_imm_in_range', we can first determine if it is greater than 0, and then call 'is_uimm' further. 'is_offset_in_range' can be changed directly to call 'is_simm'. This patch also refactored for is_valid_riscv64_address and movptr.
>> 
>> This patch removed the original functions from assembler_riscv.inline.hpp and defined some fixed-width checking functions based on the number of immediate or offset bits in the spec[1]. At the same time, we also adjusted two includes to fix the compilation error after the modification.
>> 
>> This patch also renames the function 'operand_valid_for_add_immediate' to 'operand_valid_for_add_sub_immediate' to make it consistent with its usage.
>> 
>> Finally, this patch modified the return value in os::non_memory_address_word to avoid an imm64 value of -1 in MacroAssembler::movptr.
>> 
>> [1] https://github.com/riscv/riscv-isa-manual/releases/download/draft-20230131-c0b298a/riscv-spec.pdf
>> 
>> ### Testing:
>> 
>> On Unmatched with release build:
>> - [x] Tier1 tests
>> - [x] Tier2 tests
>> - [x] Tier3 tests
>
> Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unnecessary checking

src/hotspot/cpu/riscv/assembler_riscv.inline.hpp line 49:

> 47: inline bool Assembler::is_uimm10(uint64_t x) { return is_uimm(x, 10); }
> 48: 
> 49: inline bool Assembler::operand_valid_for_add_sub_immediate(int64_t imm) { return is_simm12(imm); }

Would you mind one more tweak? I think we can also factor out 'Assembler::operand_valid_for_add_sub_immediate' and use 'is_simm12' instead.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13202#discussion_r1152860092

From rrich at openjdk.org  Thu Mar 30 08:01:18 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Thu, 30 Mar 2023 08:01:18 GMT
Subject: RFR: 8305171: PPC: Should use IMA::load_resolved_indy_entry() in
 TIG::generate_return_entry_for()
Message-ID: <EJXNWoV4PGQntUD4YSxcUsuyBgUamxw8_9fJNpNbSeQ=.0d62db69-141e-4e44-90d4-737a54c0d55c@github.com>

This PR replaces a sequence of assembler instructions in the interpreter with an equivalent call of `InterpreterMacroAssembler::load_resolved_indy_entry()`.

Tested hotspot tier1.

-------------

Commit messages:
 - Eliminate extra addi for array base offset
 - Use load_resolved_indy_entry() in generate_return_entry_for()

Changes: https://git.openjdk.org/jdk/pull/13226/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13226&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305171
  Stats: 13 lines in 3 files changed: 1 ins; 6 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/13226.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13226/head:pull/13226

PR: https://git.openjdk.org/jdk/pull/13226

From dzhang at openjdk.org  Thu Mar 30 08:08:11 2023
From: dzhang at openjdk.org (Dingli Zhang)
Date: Thu, 30 Mar 2023 08:08:11 GMT
Subject: RFR: 8305008: RISC-V: Factor out immediate checking functions from
 assembler_riscv.inline.hpp [v4]
In-Reply-To: <zOPJRtrXmBK17ZgSm-THTp8qCXhh7tSNg6VRVFoLz9Y=.763009a8-a651-499d-a0e1-f114f3c842f0@github.com>
References: <zOPJRtrXmBK17ZgSm-THTp8qCXhh7tSNg6VRVFoLz9Y=.763009a8-a651-499d-a0e1-f114f3c842f0@github.com>
Message-ID: <UgucsFZgLqfNjc7v0DAJ1QmNztdEI0HOesIx1QyUSCg=.99db7706-e4d3-41f2-812a-2abdebe087d9@github.com>

> The call-point to 'is_imm_in_range', 'is_unsigned_imm_in_range' and 'is_offset_in_range' in assembler_riscv.inline.hpp could to be replaced with shared code function 'is_simm' and 'is_uimm'.
> 
> For 'is_imm_in_range', if align_bits = 0, then the call point can be changed to call 'is_simm'. If align_bits = 1, then an additional summation judgement is added to determine if it is a multiple of 2. For 'is_unsigned_imm_in_range', we can first determine if it is greater than 0, and then call 'is_uimm' further. 'is_offset_in_range' can be changed directly to call 'is_simm'. This patch also refactored for is_valid_riscv64_address and movptr.
> 
> This patch removed the original functions from assembler_riscv.inline.hpp and defined some fixed-width checking functions based on the number of immediate or offset bits in the spec[1]. At the same time, we also adjusted two includes to fix the compilation error after the modification.
> 
> This patch also renames the function 'operand_valid_for_add_immediate' to 'operand_valid_for_add_sub_immediate' to make it consistent with its usage.
> 
> Finally, this patch modified the return value in os::non_memory_address_word to avoid an imm64 value of -1 in MacroAssembler::movptr.
> 
> [1] https://github.com/riscv/riscv-isa-manual/releases/download/draft-20230131-c0b298a/riscv-spec.pdf
> 
> ### Testing:
> 
> On Unmatched with release build:
> - [x] Tier1 tests
> - [x] Tier2 tests
> - [x] Tier3 tests

Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision:

  Use is_simm12 instead

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13202/files
  - new: https://git.openjdk.org/jdk/pull/13202/files/2dfd4bc5..4470131c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13202&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13202&range=02-03

  Stats: 22 lines in 5 files changed: 0 ins; 7 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/13202.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13202/head:pull/13202

PR: https://git.openjdk.org/jdk/pull/13202

From fyang at openjdk.org  Thu Mar 30 08:16:20 2023
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 30 Mar 2023 08:16:20 GMT
Subject: RFR: 8305008: RISC-V: Factor out immediate checking functions from
 assembler_riscv.inline.hpp [v4]
In-Reply-To: <UgucsFZgLqfNjc7v0DAJ1QmNztdEI0HOesIx1QyUSCg=.99db7706-e4d3-41f2-812a-2abdebe087d9@github.com>
References: <zOPJRtrXmBK17ZgSm-THTp8qCXhh7tSNg6VRVFoLz9Y=.763009a8-a651-499d-a0e1-f114f3c842f0@github.com>
 <UgucsFZgLqfNjc7v0DAJ1QmNztdEI0HOesIx1QyUSCg=.99db7706-e4d3-41f2-812a-2abdebe087d9@github.com>
Message-ID: <lEx4-3mUsMfbmEThmKfFbaZOHGW7AUgaLjyevA9lrak=.bd507d20-104e-4395-a4f2-8d38b6880b08@github.com>

On Thu, 30 Mar 2023 08:08:11 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

>> The call-point to 'is_imm_in_range', 'is_unsigned_imm_in_range' and 'is_offset_in_range' in assembler_riscv.inline.hpp could to be replaced with shared code function 'is_simm' and 'is_uimm'.
>> 
>> For 'is_imm_in_range', if align_bits = 0, then the call point can be changed to call 'is_simm'. If align_bits = 1, then an additional summation judgement is added to determine if it is a multiple of 2. For 'is_unsigned_imm_in_range', we can first determine if it is greater than 0, and then call 'is_uimm' further. 'is_offset_in_range' can be changed directly to call 'is_simm'. This patch also refactored for is_valid_riscv64_address and movptr.
>> 
>> This patch removed the original functions from assembler_riscv.inline.hpp and defined some fixed-width checking functions based on the number of immediate or offset bits in the spec[1]. At the same time, we also adjusted two includes to fix the compilation error after the modification.
>> 
>> This patch also factor out 'Assembler::operand_valid_for_add_sub_immediate' and use 'is_simm12' instead.
>> 
>> Finally, this patch modified the return value in os::non_memory_address_word to avoid an imm64 value of -1 in MacroAssembler::movptr.
>> 
>> [1] https://github.com/riscv/riscv-isa-manual/releases/download/draft-20230131-c0b298a/riscv-spec.pdf
>> 
>> ### Testing:
>> 
>> On Unmatched with release build:
>> - [x] Tier1 tests
>> - [x] Tier2 tests
>> - [x] Tier3 tests
>
> Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use is_simm12 instead

Updated changes looks good. Thanks.

-------------

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13202#pullrequestreview-1364564299

From dzhang at openjdk.org  Thu Mar 30 08:16:22 2023
From: dzhang at openjdk.org (Dingli Zhang)
Date: Thu, 30 Mar 2023 08:16:22 GMT
Subject: RFR: 8305008: RISC-V: Factor out immediate checking functions from
 assembler_riscv.inline.hpp [v3]
In-Reply-To: <oE6SdvdRs1cV4XKLLfk2R_I1K2eBoKidouNVXmoJ8Rc=.1416e03f-5f98-472c-a475-0125f69c204b@github.com>
References: <zOPJRtrXmBK17ZgSm-THTp8qCXhh7tSNg6VRVFoLz9Y=.763009a8-a651-499d-a0e1-f114f3c842f0@github.com>
 <W7YgamnP5c4-zxjc1c9szzhuwkg6EGDVbqNFr1PyqBg=.683dd5f9-9b6e-4d53-9d4e-5f57b7b86725@github.com>
 <oE6SdvdRs1cV4XKLLfk2R_I1K2eBoKidouNVXmoJ8Rc=.1416e03f-5f98-472c-a475-0125f69c204b@github.com>
Message-ID: <D3c05Oa5zl4yWAUuz2qQmUXwyeHVFPUpP0KYSDwmofA=.bc3b0302-b4a8-4012-98c9-1f5a824ff2b2@github.com>

On Thu, 30 Mar 2023 07:43:54 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unnecessary checking
>
> src/hotspot/cpu/riscv/assembler_riscv.inline.hpp line 49:
> 
>> 47: inline bool Assembler::is_uimm10(uint64_t x) { return is_uimm(x, 10); }
>> 48: 
>> 49: inline bool Assembler::operand_valid_for_add_sub_immediate(int64_t imm) { return is_simm12(imm); }
> 
> Would you mind one more tweak? I think we can also factor out 'Assembler::operand_valid_for_add_sub_immediate' and use 'is_simm12' instead.

Sure! Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13202#discussion_r1152896549

From rkennke at openjdk.org  Thu Mar 30 08:38:02 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 30 Mar 2023 08:38:02 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v38]
In-Reply-To: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
Message-ID: <1bJhB0umcd38IHnN9Vm38nFnYp588pVrlsnG4maB-GY=.b03f2444-da85-4385-bd2f-d080be0fd940@github.com>

> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
> 
> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p
 rotocols.
> 
> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare.
> 
> 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
> 
> 
> Testing:
>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
> 
> ### Performance
> 
> #### Simple Microbenchmark
> 
> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
> 
> |  | x86_64 | aarch64 |
> | -- | -- | -- |
> | -UseFastLocking | 20.651 | 20.764 |
> | +UseFastLocking | 18.896 | 18.908 |
> 
> 
> #### Renaissance
> 
> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
> -- | -- | -- | -- | -- | -- | -- | --
> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  More verification through zapping unused entries; get rid of _thread field

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10907/files
  - new: https://git.openjdk.org/jdk/pull/10907/files/62298e49..e5afb43c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=37
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=36-37

  Stats: 58 lines in 6 files changed: 38 ins; 1 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/10907.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10907/head:pull/10907

PR: https://git.openjdk.org/jdk/pull/10907

From rkennke at openjdk.org  Thu Mar 30 08:50:57 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 30 Mar 2023 08:50:57 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v39]
In-Reply-To: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
Message-ID: <Uzltvae3QUwfEynGgsWPBrRRrS_nIKz_ZSOctKKLdgI=.f371b2d2-7563-4268-a292-44c10849ce6c@github.com>

> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
> 
> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p
 rotocols.
> 
> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare.
> 
> 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
> 
> 
> Testing:
>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
> 
> ### Performance
> 
> #### Simple Microbenchmark
> 
> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
> 
> |  | x86_64 | aarch64 |
> | -- | -- | -- |
> | -UseFastLocking | 20.651 | 20.764 |
> | +UseFastLocking | 18.896 | 18.908 |
> 
> 
> #### Renaissance
> 
> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
> -- | -- | -- | -- | -- | -- | -- | --
> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  More verification through zapping unused entries, x86 parts

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10907/files
  - new: https://git.openjdk.org/jdk/pull/10907/files/e5afb43c..db856dc1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=38
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=37-38

  Stats: 11 lines in 3 files changed: 9 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10907.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10907/head:pull/10907

PR: https://git.openjdk.org/jdk/pull/10907

From jsjolen at openjdk.org  Thu Mar 30 08:58:22 2023
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 30 Mar 2023 08:58:22 GMT
Subject: RFR: JDK-8304815: Use NMT for more precise hs_err location
 printing [v6]
In-Reply-To: <Sx4MHQ-y1zWFB1ndVaWwmdFSF7PBxYrnukHSS_k12TQ=.42779cd0-b064-4638-9004-7683d4bd18ca@github.com>
References: <DPqsrXUm5sJjcxDGZW6QSvdpu83LBhwXreIJU7LXqjI=.dfe3de5e-919a-494d-a8dd-0622d1ee0c65@github.com>
 <Sx4MHQ-y1zWFB1ndVaWwmdFSF7PBxYrnukHSS_k12TQ=.42779cd0-b064-4638-9004-7683d4bd18ca@github.com>
Message-ID: <5q4JbHP4JvEcQLJ9jCxFHse1oA4eOc9si60VprTYnvg=.0b8a04eb-2d24-48b1-84fd-3acc8ea9f6d0@github.com>

On Thu, 30 Mar 2023 06:19:36 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> (This is a byproduct of work on the arm port for https://github.com/openjdk/jdk/pull/10907. I needed better debugging information in the hs-err file and in gdb.)
>> 
>> Back in 2022 @zhengyu123 had the very nice idea of using NMT mapping info for smartening up pp in gdb: [JDK-8280289](https://bugs.openjdk.org/browse/JDK-8280289).
>> 
>> The same idea can be applied to hs_err file location printing. NMT has information about all its mappings and can tell us where it thinks a given unknown pointer points into.
>> 
>> This could be even more useful if the "find malloc block" part of that functionality would be smarter. As it is now, it only works if the pointer in question points to the start of a user-allocated area. Would be nice if the code could (carefully) search for the next valid-looking malloc header instead.
>> 
>> --------------
>> 
>> This patch does this: we introduce a new API, MemTracker::print_containing_region(void*), that tries to make sense of a given unknown pointer.
>> 
>> It will search its mmap regions and print those if found. For malloc'ed pointers, it will carefully sniff out the immediate surroundings of the block, trying to find what looks like a valid malloc header. It uses SafeFetch to not trip over unmapped or protected pages. Note that, of course, we may get false recognition positives if it finds something that looks like a valid header. But even that could be useful (e.g. a remnant dead header may indicate we access memory after free).
>> 
>> Looks like this (its arm, so 32-bit pointers):
>> 
>> 
>> Register to memory mapping:
>> 
>> ->  r0  = 0x728a6ae0 into life malloced block starting at 0x728a6ae0, size 104, tag mtSynchronizer
>> ->  r1  = 0x75b02010 into life malloced block starting at 0x75b02010, size 184, tag mtObjectMonitor
>> ->  r2  = 0x728a6ae0 into life malloced block starting at 0x728a6ae0, size 104, tag mtSynchronizer
>>     r3  = 0x0 is nullptr
>> ->  r4  = 0x728a6ae0 into life malloced block starting at 0x728a6ae0, size 104, tag mtSynchronizer
>>     r5  = 0xb6d3bbc8: <offset 0x018f6bc8> in /shared/projects/openjdk/jdk-jdk/output-fastdebug-arm/images/jdk/lib/server/libjvm.so at 0xb5445000
>>     r6  = 0xffffffff is an unknown value
>>     r7  = 0x0 is nullptr
>>     r8  = 0x0000000a is an unknown value
>>     r9  = 0x728a4308 is a thread
>>     r10 = 0x0000000b is an unknown value
>> ->  fp  = 0x753fe8cc in mmap'd memory region [0x75380000 - 0x75400000] by Thread Stack
>>     r12 = 0x0 is nullptr
>> ->  sp  = 0x753fe8b0 in mmap'd memory region [0x75380000 - 0x75400000] by Thread Stack
>>     lr  = 0xb69bc1d0: <offset 0x015771d0> in /shared/projects/openjdk/jdk-jdk/output-fastdebug-arm/images/jdk/lib/server/libjvm.so at 0xb5445000
>>     pc  = 0xb69c8670: <offset 0x01583670> in /shared/projects/openjdk/jdk-jdk/output-fastdebug-arm/images/jdk/lib/server/libjvm.so at 0xb5445000
>> 
>> 
>> 
>> The small caveat here is that NMT reporting needs ThreadCritical, and thus using it for location printing may block error reporting if it crashed inside a ThreadCritical section. We face the same issue today when printing the NMT report as part of the hs-err file. 
>> 
>> I think the usefulness of these printouts justify this risk. However I opened https://bugs.openjdk.org/browse/JDK-8304824 to investigate a better locking strategy for NMT.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix comment, update copyright

One comment on word choice, otherwise this looks good.

src/hotspot/share/services/mallocTracker.cpp line 210:

> 208:   // but the pointer points into remnants of a dead block, print that instead.
> 209:   const MallocHeader* likely_dead_block = nullptr;
> 210:   const MallocHeader* likely_life_block = nullptr;

Sorry, "life" -> "live" (or even "alive", but both work)

-------------

Marked as reviewed by jsjolen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/13162#pullrequestreview-1364644760
PR Review Comment: https://git.openjdk.org/jdk/pull/13162#discussion_r1152946662

From amitkumar at openjdk.org  Thu Mar 30 09:07:32 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Thu, 30 Mar 2023 09:07:32 GMT
Subject: RFR: 8231349: Move intrinsic stubs generation to compiler runtime
 initialization code [v2]
In-Reply-To: <YX72intbDBNCoz_lL71NtHiBhzClh4KbEldmnViz2Tc=.d193dd7b-d364-47c2-be40-178cb4d25c1c@github.com>
References: <dtc9rdiBGUpqQUB9AzWBroeF3ziVODfk0FuPFDgOHqE=.096e99b2-2957-46c7-8c74-ae1d737f220d@github.com>
 <mps4Bze-krj-aWVdtS6CcpRmOf9_gs-lmDI3iH7AvIQ=.8671e010-995c-4d1c-8282-afbb5ae6f2bf@github.com>
 <YX72intbDBNCoz_lL71NtHiBhzClh4KbEldmnViz2Tc=.d193dd7b-d364-47c2-be40-178cb4d25c1c@github.com>
Message-ID: <29CsTb21Kwy0gEb-nz3fhq0p4gbXx2RBzFJEid2uEgU=.378f44c5-cc1a-4916-b3b8-1ed61621cada@github.com>

On Thu, 23 Mar 2023 03:33:18 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address Claes comments
>
> I renamed flag and used `COMPILER2_OR_JVMCI` as default value (based on Vladimir last suggestion).

Hi @vnkozlov, 

these changes broke the build for s390x platform. I've opened [JDK-8305227](https://bugs.openjdk.org/browse/JDK-8305227) and put hs_err* log file there as well. 

It would be helpful if you could take a look and provide some suggestion. 

Thanks

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13096#issuecomment-1489953113

From mdoerr at openjdk.org  Thu Mar 30 10:39:15 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 30 Mar 2023 10:39:15 GMT
Subject: RFR: 8305171: PPC: Should use IMA::load_resolved_indy_entry() in
 TIG::generate_return_entry_for()
In-Reply-To: <EJXNWoV4PGQntUD4YSxcUsuyBgUamxw8_9fJNpNbSeQ=.0d62db69-141e-4e44-90d4-737a54c0d55c@github.com>
References: <EJXNWoV4PGQntUD4YSxcUsuyBgUamxw8_9fJNpNbSeQ=.0d62db69-141e-4e44-90d4-737a54c0d55c@github.com>
Message-ID: <Wv2j1iNaw2ZgpMdNrTR8CIGrLD4Gs519Z9sXCOd7nJM=.94258951-8e8d-40c7-966a-e86dde9814a0@github.com>

On Wed, 29 Mar 2023 12:36:44 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> This PR replaces a sequence of assembler instructions in the interpreter with an equivalent call of `InterpreterMacroAssembler::load_resolved_indy_entry()`.
> 
> Tested hotspot tier1.

LGTM. Thanks for cleaning this up!

-------------

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13226#pullrequestreview-1364821523

From pminborg at openjdk.org  Thu Mar 30 11:28:25 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 30 Mar 2023 11:28:25 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v16]
In-Reply-To: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
Message-ID: <p9ijGq25fS1pue7aXoUfsKjc76t-oHcssoKtXRE7c_s=.a5e3a921-ed1d-4d39-aebc-6a7b590b5bdc@github.com>

> API changes for the FFM API (third preview)
> 
> Specdiff:
> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
> 
> Javadoc:
> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html

Per Minborg has updated the pull request incrementally with two additional commits since the last revision:

 - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
   
   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
 - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
   
   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13079/files
  - new: https://git.openjdk.org/jdk/pull/13079/files/c787a282..928ad35e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13079&range=14-15

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13079/head:pull/13079

PR: https://git.openjdk.org/jdk/pull/13079

From rkennke at openjdk.org  Thu Mar 30 11:46:44 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 30 Mar 2023 11:46:44 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v40]
In-Reply-To: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
Message-ID: <0c1Yzyh4d0SRjKrfASJtuWOlc4ZVT5xwVepogKAdags=.fe4a8a57-a910-4a75-99dc-8e99bcc72e3c@github.com>

> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
> 
> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p
 rotocols.
> 
> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare.
> 
> 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
> 
> 
> Testing:
>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
> 
> ### Performance
> 
> #### Simple Microbenchmark
> 
> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
> 
> |  | x86_64 | aarch64 |
> | -- | -- | -- |
> | -UseFastLocking | 20.651 | 20.764 |
> | +UseFastLocking | 18.896 | 18.908 |
> 
> 
> #### Renaissance
> 
> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
> -- | -- | -- | -- | -- | -- | -- | --
> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Address more of @shipilev's review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10907/files
  - new: https://git.openjdk.org/jdk/pull/10907/files/db856dc1..57171883

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=39
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=38-39

  Stats: 11 lines in 3 files changed: 7 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/10907.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10907/head:pull/10907

PR: https://git.openjdk.org/jdk/pull/10907

From rkennke at openjdk.org  Thu Mar 30 11:48:46 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 30 Mar 2023 11:48:46 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <GQ69p_sHk_xFKzlHQ1e-r3hWOtedFkiKcPMDUgTdiZk=.f3d32fb3-f1a1-4d04-8ab6-940d7bf738fa@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
 <GQ69p_sHk_xFKzlHQ1e-r3hWOtedFkiKcPMDUgTdiZk=.f3d32fb3-f1a1-4d04-8ab6-940d7bf738fa@github.com>
Message-ID: <EylVQq50tGIeScaRLhpr4NWb0PxPjjYIObA5OTZOqD4=.00ed3a69-a2d0-4ac6-8e0f-22db8398eeef@github.com>

On Sat, 25 Mar 2023 08:55:25 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> I have another question about the asymmetric unlocking code in `InterpreterMacroAssembler::unlock_object`.
> 
> We go through here for both fast-locked and fat OM locks, right? If so, shouldn't we do the asymmetric lock check only for the fast locked case? Otherwise Lockstack may be empty, so we compare the word preceding the first slot, which would cause us to always break into the slow case?
> 
> Sorry if I miss something here.

Uh, yes, indeed. It works by accident, I suppose, because we don't segfault on the word preceding the lock-stack, and monitor-locking takes the slow-case in interpreter, anyway. But yeah, it's better to check for it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1490163377

From rrich at openjdk.org  Thu Mar 30 12:26:17 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Thu, 30 Mar 2023 12:26:17 GMT
Subject: RFR: 8305171: PPC: Should use IMA::load_resolved_indy_entry() in
 TIG::generate_return_entry_for()
In-Reply-To: <EJXNWoV4PGQntUD4YSxcUsuyBgUamxw8_9fJNpNbSeQ=.0d62db69-141e-4e44-90d4-737a54c0d55c@github.com>
References: <EJXNWoV4PGQntUD4YSxcUsuyBgUamxw8_9fJNpNbSeQ=.0d62db69-141e-4e44-90d4-737a54c0d55c@github.com>
Message-ID: <d4-zQO_kuq2ookVpbBgM2F2ZuxQFxzIdyElwHl-HOYI=.41353a85-25e3-4dac-9b13-1669891f4e26@github.com>

On Wed, 29 Mar 2023 12:36:44 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> This PR replaces a sequence of assembler instructions in the interpreter with an equivalent call of `InterpreterMacroAssembler::load_resolved_indy_entry()`.
> 
> Tested hotspot tier1.

Thanks Martin!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13226#issuecomment-1490210978

From mgronlun at openjdk.org  Thu Mar 30 13:13:45 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 30 Mar 2023 13:13:45 GMT
Subject: RFR: 8257967: JFR: Events for loaded agents [v10]
In-Reply-To: <5uEVRUEr0vSBiTHqKpKVwG1k-v5UrFr9RVAip3K8NSg=.a7bf35b5-b372-4ba6-b217-642c6ad4e2a8@github.com>
References: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
 <ZsaBMVK-eeLfmxgg15qPJHm6C-ed5PyIE4lGr-Gnr2s=.2f4044c4-e7ed-48f3-8877-feeb2753be18@github.com>
 <M86HnsWFDyZ0UNtNsefyHOG-wSDPBIkETS76BtkhCBc=.c65616e6-b644-4db9-b64b-d1319a87b915@github.com>
 <5uEVRUEr0vSBiTHqKpKVwG1k-v5UrFr9RVAip3K8NSg=.a7bf35b5-b372-4ba6-b217-642c6ad4e2a8@github.com>
Message-ID: <cOxpUqWMNn2ihKZE4l9QdgUdMExnh9CUJbithDYh2iI=.a76d94e5-5d11-44de-a2ad-f25d3135c198@github.com>

On Tue, 14 Mar 2023 12:23:08 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> src/hotspot/share/prims/agentList.cpp line 419:
>> 
>>> 417:     const jint err = (*on_load_entry)(&main_vm, const_cast<char*>(agent->options()), NULL);
>>> 418:     if (err != JNI_OK) {
>>> 419:       vm_exit_during_initialization("-Xrun library failed to init", agent->name());
>> 
>> Do you need to be back in `_thread_in_vm` before exiting?
>
> Hmm. This was ported as is. I will double-check.

Looks like there is no requirement to be in _thread_in_vm before invoking vm_exit_during_initialization().

vm_perform_shutdown_actions() will forcibly set the thread state to _thread_in_native (no transition).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12923#discussion_r1153243069

From rkennke at openjdk.org  Thu Mar 30 13:27:01 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 30 Mar 2023 13:27:01 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v41]
In-Reply-To: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
Message-ID: <lyHl3eBCkzTpQ84CIKqbaejBLXSNcsFZEG1fNt_rDK8=.4ecb963c-e86e-4fc4-8994-755fc5a1d579@github.com>

> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
> 
> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p
 rotocols.
> 
> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare.
> 
> 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
> 
> 
> Testing:
>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
> 
> ### Performance
> 
> #### Simple Microbenchmark
> 
> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
> 
> |  | x86_64 | aarch64 |
> | -- | -- | -- |
> | -UseFastLocking | 20.651 | 20.764 |
> | +UseFastLocking | 18.896 | 18.908 |
> 
> 
> #### Renaissance
> 
> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
> -- | -- | -- | -- | -- | -- | -- | --
> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Use ANONYMOUS_OWNER constant in SA

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10907/files
  - new: https://git.openjdk.org/jdk/pull/10907/files/57171883..a75de7e5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=40
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=39-40

  Stats: 17 lines in 7 files changed: 7 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/10907.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10907/head:pull/10907

PR: https://git.openjdk.org/jdk/pull/10907

From rkennke at openjdk.org  Thu Mar 30 13:29:12 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 30 Mar 2023 13:29:12 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v29]
In-Reply-To: <EylVQq50tGIeScaRLhpr4NWb0PxPjjYIObA5OTZOqD4=.00ed3a69-a2d0-4ac6-8e0f-22db8398eeef@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <_WvW_1rgaeDPAzM9DferkAgb6IhT-kZXPsINY8o_uA4=.bb1a0483-dc87-4e61-8272-f41618e27f53@github.com>
 <GQ69p_sHk_xFKzlHQ1e-r3hWOtedFkiKcPMDUgTdiZk=.f3d32fb3-f1a1-4d04-8ab6-940d7bf738fa@github.com>
 <EylVQq50tGIeScaRLhpr4NWb0PxPjjYIObA5OTZOqD4=.00ed3a69-a2d0-4ac6-8e0f-22db8398eeef@github.com>
Message-ID: <vKuJzKrzZDHtvPf8-Lcy-X3JO15FJqvuynVhbVdQra8=.6d0837a8-4cf9-4562-a342-7abbeb3812b4@github.com>

On Thu, 30 Mar 2023 11:45:54 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> I have another question about the asymmetric unlocking code in `InterpreterMacroAssembler::unlock_object`.
>> 
>> We go through here for both fast-locked and fat OM locks, right? If so, shouldn't we do the asymmetric lock check only for the fast locked case? Otherwise Lockstack may be empty, so we compare the word preceding the first slot, which would cause us to always break into the slow case?
>> 
>> Sorry if I miss something here.
>
>> I have another question about the asymmetric unlocking code in `InterpreterMacroAssembler::unlock_object`.
>> 
>> We go through here for both fast-locked and fat OM locks, right? If so, shouldn't we do the asymmetric lock check only for the fast locked case? Otherwise Lockstack may be empty, so we compare the word preceding the first slot, which would cause us to always break into the slow case?
>> 
>> Sorry if I miss something here.
> 
> Uh, yes, indeed. It works by accident, I suppose, because we don't segfault on the word preceding the lock-stack, and monitor-locking takes the slow-case in interpreter, anyway. But yeah, it's better to check for it.

> @rkennke Question about ZGC and LockStack::contains(): how does this work with colored pointers? Don't we have to mask the color bits out somehow when comparing? E.g. using `ZAddress::offset()` ?

We must ensure that the oops are in a valid state. I recently added code to ::contains() to call start_processing() when called from a foreign thread. When inspecting its own thread, we are always good, because stack-watermark is processed right after leaving a safepoint, before resuming normal operations.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1490302961

From rkennke at openjdk.org  Thu Mar 30 13:35:14 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 30 Mar 2023 13:35:14 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v30]
In-Reply-To: <EzfZGy8hLDki3v4z21KTA7D4FAmDgHcSuGIKfN4Kms8=.c3a5c505-fe31-4f3c-ac75-2d156dadadae@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <lzS3PlrHxm9JjbOyReXPNbqZJf5nb13kdMB6fFK52m0=.9262cfa5-dff5-4fcf-aaf0-5a4e993c5071@github.com>
 <EzfZGy8hLDki3v4z21KTA7D4FAmDgHcSuGIKfN4Kms8=.c3a5c505-fe31-4f3c-ac75-2d156dadadae@github.com>
Message-ID: <FqffjCSzL_TVrs3LbN__dQvSEEbXnZO81vj7JvCLpdA=.5b1a4aa8-52b5-414a-b037-1fe81eed41a7@github.com>

On Tue, 28 Mar 2023 00:17:21 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Ensure safepoint when processing lock-stack
>
> src/hotspot/cpu/aarch64/aarch64.ad line 3844:
> 
>> 3842: 
>> 3843:         // Indicate success on completion.
>> 3844:         __ cmp(oop, oop); // Force ZF=1 to indicate success.
> 
> It looks like `fast_lock` already sets ZF=1 on success/fall-through.  Why not document this as part of the interface, then this `cmp` will be redundant?

Indeed. I was assuming that the instructions that follow the CAS might be affecting the NZCV flags (like they do on x86), but apparently they don't. Very nice. I am removing the instruction here and following fast_unlock().

> src/hotspot/share/interpreter/interpreterRuntime.cpp line 740:
> 
>> 738:   if (!UseHeavyMonitors && UseFastLocking) {
>> 739:     // This is a hack to get around the limitation of registers in x86_32. We really
>> 740:     // send an oopDesc* instead of a BasicObjectLock*.
> 
> I don't understand what this is referring to.  Trying to avoid passing an extra argument?

I updated the comment in an earlier commit to say:
   // TODO: We accept elem as void* to workaround a limitation of registers in x86_32. Interpreter
    // code is really sending an oopDesc* here.
    // The problem is that we would need to preserve the register that holds the BasicObjectLock,
    // but we are using that register to hold the thread. We don't have enough registers to
    // also keep the BasicObjectLock, but we don't really need it anyway, we only need
    // the object. See also InterpreterMacroAssembler::lock_object().
    // As soon as traditional stack-locking goes away we can change elem to be oopDesc*
    // (also in monitorexit below).
I hope that is clearer.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1153268963
PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1153270625

From rkennke at openjdk.org  Thu Mar 30 13:58:45 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 30 Mar 2023 13:58:45 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v42]
In-Reply-To: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
Message-ID: <fVdmBQxhtvckl7Hd1EOCT6u3hufMncDnqmMb9-3Y1Ok=.eacbdcd1-0e45-4b21-8cd9-c81d2b044623@github.com>

> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
> 
> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p
 rotocols.
> 
> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare.
> 
> 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
> 
> 
> Testing:
>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
> 
> ### Performance
> 
> #### Simple Microbenchmark
> 
> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
> 
> |  | x86_64 | aarch64 |
> | -- | -- | -- |
> | -UseFastLocking | 20.651 | 20.764 |
> | +UseFastLocking | 18.896 | 18.908 |
> 
> 
> #### Renaissance
> 
> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
> -- | -- | -- | -- | -- | -- | -- | --
> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Splice entry points for InterpreterRuntime::monitorenter()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10907/files
  - new: https://git.openjdk.org/jdk/pull/10907/files/a75de7e5..b0ffd9af

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=41
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=40-41

  Stats: 59 lines in 5 files changed: 28 ins; 15 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/10907.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10907/head:pull/10907

PR: https://git.openjdk.org/jdk/pull/10907

From rkennke at openjdk.org  Thu Mar 30 13:58:50 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 30 Mar 2023 13:58:50 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v30]
In-Reply-To: <fEgcjjAIbSeXWTjvUOTufaAjBHiO96-OeMBhFP9A9So=.e53c82ae-5285-439d-8259-5f348623f375@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <lzS3PlrHxm9JjbOyReXPNbqZJf5nb13kdMB6fFK52m0=.9262cfa5-dff5-4fcf-aaf0-5a4e993c5071@github.com>
 <fEgcjjAIbSeXWTjvUOTufaAjBHiO96-OeMBhFP9A9So=.e53c82ae-5285-439d-8259-5f348623f375@github.com>
Message-ID: <6K4zNT0oaIZAJEfULur4xhnrOKdjtzyJaDwwt_kxtqc=.ed98c939-a6b7-4edf-bd7b-5488369e85df@github.com>

On Tue, 28 Mar 2023 00:53:57 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Ensure safepoint when processing lock-stack
>
> src/hotspot/share/interpreter/interpreterRuntime.cpp line 746:
> 
>> 744:     ObjectSynchronizer::enter(h_obj, nullptr, current);
>> 745:     return;
>> 746:   }
> 
> Why not put this code in a new function declared as InterpreterRuntime::monitorenter(JavaThread* current, oop obj) and have the caller decide which one to call?

That is a good suggestion, I did that change. Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1153300881

From rkennke at openjdk.org  Thu Mar 30 14:00:09 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 30 Mar 2023 14:00:09 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v30]
In-Reply-To: <C5ix2Lh79hAiM4NkDdcZVcYSleC-RQ7uGcu3G0ymBGU=.8393c83a-a02d-4bd0-aace-5b8aeac9bed7@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <lzS3PlrHxm9JjbOyReXPNbqZJf5nb13kdMB6fFK52m0=.9262cfa5-dff5-4fcf-aaf0-5a4e993c5071@github.com>
 <2cIUWaQL9GilRFtckC9SpcJVet_0Rb8SmFS1tfe8AWE=.35713c3e-1f5d-45e5-8a3c-d732070d7b81@github.com>
 <C5ix2Lh79hAiM4NkDdcZVcYSleC-RQ7uGcu3G0ymBGU=.8393c83a-a02d-4bd0-aace-5b8aeac9bed7@github.com>
Message-ID: <0Hci_F96En1EB9q2DfH40AREGZ13zPQaCmuUi_HUN2U=.7235f9f7-66a4-4125-8916-4ba320c0e2b2@github.com>

On Tue, 28 Mar 2023 21:39:21 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> src/hotspot/share/runtime/threads.cpp line 1433:
>> 
>>> 1431: 
>>> 1432: JavaThread* Threads::owning_thread_from_monitor(ThreadsList* t_list, ObjectMonitor* monitor) {
>>> 1433:   assert(SafepointSynchronize::is_at_safepoint(), "not safe outside of safepoint");
>> 
>> Shouldn't this be gated on UseFastLocking?
>
> Hmmm.... `owning_thread_from_monitor()` is only called from
> `ObjectSynchronizer::get_lock_owner()` when `get_lock_owner()`
> knows that it has an ObjectMonitor in hand. I'm not at all sure that
> we can assert that `ObjectSynchronizer::get_lock_owner()` is
> only called from a safepoint.

There has been a single call path from management.cpp that is not calling this code at a safepoint, and I changed that code to take the safepoint-taking variant code-path when using UseFastLocking. That path already existed and has been used when max_depth == 0.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1153307575

From sspitsyn at openjdk.org  Thu Mar 30 14:09:04 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 30 Mar 2023 14:09:04 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v4]
In-Reply-To: <GOOPg0-P0Vc1ocNUzWRIbItENekN1ralramscyuF1kQ=.44aded10-e14f-4378-9173-a8126d21da04@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <GOOPg0-P0Vc1ocNUzWRIbItENekN1ralramscyuF1kQ=.44aded10-e14f-4378-9173-a8126d21da04@github.com>
Message-ID: <c8W4zAY7O_itZpDDkivuuNNAyv0tJrCYIHLoiBFg6Js=.6f34e7a2-9375-459f-bc25-b1b0b321e890@github.com>

On Wed, 29 Mar 2023 08:00:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview.
>> 
>> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently.
>> 
>> In addition, there are a small number of implementation changes to sync up from the loom fibers branch:
>> 
>> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where  end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly.
>> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes.
>> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs.
>> - New system property to print a stack trace when a virtual thread sets its own value of a TL.
>> - ThreadPerTaskExecutor is changed to use FutureTask.
>> 
>> Testing: tier1-6.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix ThreadSleepEvent again

Just wanted to check if we want to bump `@since` version of `OpaqueFrameException` from 19 to 21.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13203#issuecomment-1490367599

From qamai at openjdk.org  Thu Mar 30 14:30:17 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 30 Mar 2023 14:30:17 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v5]
In-Reply-To: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
Message-ID: <oiRTNlsfJ4A5EbcwbqaFSv9DpYutUZv2rLfrOS0ti60=.1d3d4123-b04c-4e24-85cf-3ba8eb5933c8@github.com>

> Hi,
> 
> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, VectorShuffle is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
> 
> 1. Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
> 2. Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
> 3. Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
> 4. Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
> 
> Upon these changes, a `rearrange` can emit more efficient code:
> 
>     var species = IntVector.SPECIES_128;
>     var v1 = IntVector.fromArray(species, SRC1, 0);
>     var v2 = IntVector.fromArray(species, SRC2, 0);
>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
> 
>     Before:
>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>     vmovdqu 0x10(%r10),%xmm2
>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>     vmovdqu 0x10(%r10),%xmm1
>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>     vmovdqu 0x10(%r10),%xmm0
>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>                                                             ;   {external_word}
>     vpackusdw %xmm0,%xmm0,%xmm0
>     vpackuswb %xmm0,%xmm0,%xmm0
>     vpmovsxbd %xmm0,%xmm3
>     vpcmpgtd %xmm3,%xmm1,%xmm3
>     vtestps %xmm3,%xmm3
>     jne    0x00007fc2acb4e0d8
>     vpmovzxbd %xmm0,%xmm0
>     vpermd %ymm2,%ymm0,%ymm0
>     movabs $0x751588f98,%r10            ;   {oop([I{0x0000000751588f98})}
>     vmovdqu %xmm0,0x10(%r10)
> 
>     After:
>     movabs $0x751589c78,%r10            ;   {oop([I{0x0000000751589c78})}
>     vmovdqu 0x10(%r10),%xmm1
>     movabs $0x75158ac88,%r10            ;   {oop([I{0x000000075158ac88})}
>     vmovdqu 0x10(%r10),%xmm2
>     vpxor  %xmm0,%xmm0,%xmm0
>     vpcmpgtd %xmm2,%xmm0,%xmm3
>     vtestps %xmm3,%xmm3
>     jne    0x00007fa818b27cb1
>     vpermd %ymm1,%ymm2,%ymm0
>     movabs $0x751588c68,%r10            ;   {oop([I{0x0000000751588c68})}
>     vmovdqu %xmm0,0x10(%r10)
>     
> Please take a look and leave reviews. Thanks a lot.

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 14 commits:

 - move implementations up
 - Merge branch 'master' into shufflerefactor
 - Merge branch 'master' into shufflerefactor
 - reviews
 - missing casts
 - clean up
 - fix Matcher::vector_needs_load_shuffle
 - fix internal types, clean up
 - optimise laneIsValid
 - Merge branch 'master' into shufflerefactor
 - ... and 4 more: https://git.openjdk.org/jdk/compare/d063b896...a4835c00

-------------

Changes: https://git.openjdk.org/jdk/pull/13093/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13093&range=04
  Stats: 3683 lines in 64 files changed: 1610 ins; 1169 del; 904 mod
  Patch: https://git.openjdk.org/jdk/pull/13093.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13093/head:pull/13093

PR: https://git.openjdk.org/jdk/pull/13093

From rkennke at openjdk.org  Thu Mar 30 14:32:01 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 30 Mar 2023 14:32:01 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v43]
In-Reply-To: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
Message-ID: <txu_Bog6v1JytLUtF3eUs718UAZkin6oWu36k7P4ZLA=.5422020d-80d0-4619-831c-ca572cfa2978@github.com>

> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
> 
> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p
 rotocols.
> 
> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare.
> 
> 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
> 
> 
> Testing:
>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
> 
> ### Performance
> 
> #### Simple Microbenchmark
> 
> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
> 
> |  | x86_64 | aarch64 |
> | -- | -- | -- |
> | -UseFastLocking | 20.651 | 20.764 |
> | +UseFastLocking | 18.896 | 18.908 |
> 
> 
> #### Renaissance
> 
> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
> -- | -- | -- | -- | -- | -- | -- | --
> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Don't retry on inflate; use aarch64 ZF from fast_lock(); bunch of small changes based on reviews

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10907/files
  - new: https://git.openjdk.org/jdk/pull/10907/files/b0ffd9af..e0e019e9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=42
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=41-42

  Stats: 31 lines in 6 files changed: 0 ins; 10 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/10907.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10907/head:pull/10907

PR: https://git.openjdk.org/jdk/pull/10907

From rkennke at openjdk.org  Thu Mar 30 14:32:03 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 30 Mar 2023 14:32:03 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v30]
In-Reply-To: <_b88qICP5AK4NgLpW0fXKgoa8ObWoZM1GvXKpoNMxlU=.85187d4a-968e-4283-b46d-4290ee3cc402@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <lzS3PlrHxm9JjbOyReXPNbqZJf5nb13kdMB6fFK52m0=.9262cfa5-dff5-4fcf-aaf0-5a4e993c5071@github.com>
 <_b88qICP5AK4NgLpW0fXKgoa8ObWoZM1GvXKpoNMxlU=.85187d4a-968e-4283-b46d-4290ee3cc402@github.com>
Message-ID: <TmqnaI4_rbdYOytYe58mZfb8DcXVSB1cFvaYX1cSukE=.2d4ab3e3-4fa6-4f73-bf90-5c7355bbcac5@github.com>

On Tue, 28 Mar 2023 02:56:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Ensure safepoint when processing lock-stack
>
> src/hotspot/share/runtime/lockStack.hpp line 43:
> 
>> 41:   // efficient addressing in generated code.
>> 42:   int _offset;
>> 43:   oop _base[CAPACITY];
> 
> Should we be using `OopHandle` here rather than raw oops? Would that not avoid issues with scanning the lock-stack only during safepoints?
> 
> Another alternative for a STW safepoint would be to do a handshake with the target threads.

I added verification of sane thread states (self, safepointed, handshaked, watermark-processing, suspended) when scanning the lock-stack. OopHandle would impact performance a bit too much for my taste. (If performance is not a prime concern, I would be happy to ditch stack-locking altogether and use monitors-only instead.)

Yes it might be useful if management code could handshake threads one-by-one instead of safepointing, but that's not within the scope of this PR, I think.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1153312238

From rkennke at openjdk.org  Thu Mar 30 14:32:05 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 30 Mar 2023 14:32:05 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v30]
In-Reply-To: <RA4xVGZEjGRTdzA6qIF2FBvv9RaigwS-LhdYhx02I1E=.b17634ab-1acc-4199-ae0e-cb33cc119a64@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <lzS3PlrHxm9JjbOyReXPNbqZJf5nb13kdMB6fFK52m0=.9262cfa5-dff5-4fcf-aaf0-5a4e993c5071@github.com>
 <RA4xVGZEjGRTdzA6qIF2FBvv9RaigwS-LhdYhx02I1E=.b17634ab-1acc-4199-ae0e-cb33cc119a64@github.com>
Message-ID: <FoVz8FZ9mB-7zuhyBOW3BUBxwvgMyWfRtE7WsS9YLl8=.f9dd0d40-1a02-4f54-9637-8fb7ae17860f@github.com>

On Tue, 28 Mar 2023 02:59:31 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Ensure safepoint when processing lock-stack
>
> src/hotspot/share/runtime/objectMonitor.inline.hpp line 36:
> 
>> 34: #include "runtime/synchronizer.hpp"
>> 35: 
>> 36: inline intptr_t ObjectMonitor::is_entered(JavaThread* current) const {
> 
> Suggestion:
> 
> inline bool ObjectMonitor::is_entered(JavaThread* current) const {

Oh dear, where did that came from? I'm fixing it.

> src/hotspot/share/runtime/synchronizer.cpp line 506:
> 
>> 504:               return;
>> 505:             }
>> 506:             // Otherwise retry.
> 
> Why is retry important for the new code but not the old code?

It is not. There's the off-chance that another thread installs a hash-code (with the new locking this would be possible to do without causing inflation), but I guess that would be a very rare clash. I'm changing the code to not retry and directly dive into inflation instead.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1153318137
PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1153320332

From qamai at openjdk.org  Thu Mar 30 14:34:34 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 30 Mar 2023 14:34:34 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v5]
In-Reply-To: <PzF1vuUr_snbzT3UpXC8l94aXuVuKJJVfddkw3RYRDs=.084e2476-8966-42d9-bdc3-0f2ca80938db@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
 <laGpMIPjIolDVaoKarrUxW0DciC7zHgpkGCgAc_bnO4=.c4c8252f-ff6a-4a79-9706-c120e2f96f94@github.com>
 <PzF1vuUr_snbzT3UpXC8l94aXuVuKJJVfddkw3RYRDs=.084e2476-8966-42d9-bdc3-0f2ca80938db@github.com>
Message-ID: <H4WEeKfLl1ar4cZY5lwMMfqCliFhcn0RVOdW_-dTYxo=.3b2950ee-7add-415f-bf7d-3648442d923c@github.com>

On Thu, 23 Mar 2023 07:13:55 GMT, Xiaohong Gong <xgong 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 14 commits:
>> 
>>  - move implementations up
>>  - Merge branch 'master' into shufflerefactor
>>  - Merge branch 'master' into shufflerefactor
>>  - reviews
>>  - missing casts
>>  - clean up
>>  - fix Matcher::vector_needs_load_shuffle
>>  - fix internal types, clean up
>>  - optimise laneIsValid
>>  - Merge branch 'master' into shufflerefactor
>>  - ... and 4 more: https://git.openjdk.org/jdk/compare/d063b896...a4835c00
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java line 868:
> 
>> 866:             return (Byte128Vector) Byte128Vector.VSPECIES.dummyVector()
>> 867:                     .vectorFactory(s.indices());
>> 868:         }
> 
> Move the implementation details to the super class?

I have moved `toBitsVectorTemplate` to `AbstractShuffle`, also `toShuffle` has been refactored to be more versatile.

> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteMaxVector.java line 862:
> 
>> 860:             v.convertShape(VectorOperators.B2I, species, 3)
>> 861:                     .reinterpretAsInts()
>> 862:                     .intoArray(a, offset + species.length() * 3);
> 
> Can we add a method like `intoIntArray()` in `ByteVector` and move these common code there? The same to other vector types.

I don't think this and the below suggestion achieve much, reducing the generated code at the expense of moving the usage away from the definition does not seem worth it to me.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1153353267
PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1153354836

From rkennke at openjdk.org  Thu Mar 30 14:34:49 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 30 Mar 2023 14:34:49 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v37]
In-Reply-To: <1ZtuIYVxUaqsHQSGuCJB0qDHqfXzVEyidpaEKcyoxIs=.e9a9b540-5e0c-474d-a89b-09e99ea27ddb@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <Y7GnMCO0_ZCOlK7-0KrSaFrQY3EWb6mwtoZT8ZjmRBI=.cef3dbdb-7d55-45ee-b6f1-c3c614098513@github.com>
 <1ZtuIYVxUaqsHQSGuCJB0qDHqfXzVEyidpaEKcyoxIs=.e9a9b540-5e0c-474d-a89b-09e99ea27ddb@github.com>
Message-ID: <aEJ2JPX1oi2TO-ZAV8bJ3ALJuBSGnMFz_31nEM_AiI4=.18a3c072-3ea1-4240-b314-cb08fb088dad@github.com>

On Wed, 29 Mar 2023 22:09:02 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Bounds check in lock-stack verification; only do watermark if we have one
>
> src/hotspot/share/runtime/lockStack.cpp line 69:
> 
>> 67:   assert(UseFastLocking && !UseHeavyMonitors, "never use lock-stack when fast-locking is disabled");
>> 68:   assert((_offset <=  end_offset()), "lockstack overflow: _offset %d end_offset %d", _offset, end_offset());
>> 69:   assert((_offset >= start_offset()), "lockstack underflow: _offset %d end_offset %d", _offset, start_offset());
> 
> You should save a local copy of `end_offset()` and a local copy of
> `start_offset()` in an `#ifdef ASSERT ... #endif` code block and
> then use those local copies in the `assert()` condition and mesg.
> That will guard against parallel usage by the target thread versus
> the verifying thread.

Neither start-offset nor end-offset are changing ever. Those are the hard boundaries of the fixed-sized stack. Ideally both methods would be constexpr, but this is currently not easy because we can't use offsetof().

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1153358127

From rkennke at openjdk.org  Thu Mar 30 14:34:51 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 30 Mar 2023 14:34:51 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v35]
In-Reply-To: <PP9_W05rSRMhMR7j4eQ1SROy-M3m0ECHhHZesSDDpwY=.ea2ba66f-3068-41fe-9e07-91808e6a3f8c@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <NhMXsf7u09iGG1DS_E4zttNbHncJDp0OyAA6WBAPEOQ=.2446a8cc-8313-467b-963f-9c7c4c6bbca9@github.com>
 <P__u34D1QfjXJNUlF76aB9U0SkWf101xrnd6aweSwKo=.549bf5f2-bc8e-4d3f-9ca6-cd4d8b173f3b@github.com>
 <-xn2Y5lZ-63av1QhbJNDx4saAzgmFT9hE394alHUFHI=.ae58b01f-d6ef-45f3-8e42-fc7b7a552b8e@github.com>
 <PP9_W05rSRMhMR7j4eQ1SROy-M3m0ECHhHZesSDDpwY=.ea2ba66f-3068-41fe-9e07-91808e6a3f8c@github.com>
Message-ID: <pEBv_-2WfTYNg2fcgNKeameHmG83ayBBuQP6kKz6EBc=.f009a9a3-cf2e-473e-98b5-f1003cc7eef4@github.com>

On Wed, 29 Mar 2023 22:13:09 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Update: In v35 you put back the `!UseFastLocking` check in `jmm_GetThreadInfo()`
>> so now the `assert()` won't fire, but you've again changed the behavior of that API
>> and now it will be able to observe fewer thread state changes than it did before.
>
> Please explain why you think this is "not safe". Yes, you can observe state that is in
> the process of changing, but do you think that we'll see a crash with allowing
> `Threads::owning_thread_from_object()` to be called from a non-safepoint place?

I don't think we'd see a crash, but we might get false results when we are scanning the lock-stack of a foreign thread, when that thread does not hold still. I'm not even comfortable doing that cross-stack lock query with the old code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1153354742

From alanb at openjdk.org  Thu Mar 30 14:34:22 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 30 Mar 2023 14:34:22 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v4]
In-Reply-To: <c8W4zAY7O_itZpDDkivuuNNAyv0tJrCYIHLoiBFg6Js=.6f34e7a2-9375-459f-bc25-b1b0b321e890@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <GOOPg0-P0Vc1ocNUzWRIbItENekN1ralramscyuF1kQ=.44aded10-e14f-4378-9173-a8126d21da04@github.com>
 <c8W4zAY7O_itZpDDkivuuNNAyv0tJrCYIHLoiBFg6Js=.6f34e7a2-9375-459f-bc25-b1b0b321e890@github.com>
Message-ID: <FioaT83I8HC-0zmpUAPshN5_ncsbdV_xVtuenQMPhNw=.20e6f5a7-3e03-4dc7-9824-dde057c0f4f1@github.com>

On Thu, 30 Mar 2023 14:05:36 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Just wanted to check if we want to bump `@since` version of `OpaqueFrameException` from 19 to 21.

OpaqueFrameException was added as a permanent API in JDK 19 so it doesn't change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13203#issuecomment-1490410758

From qamai at openjdk.org  Thu Mar 30 14:44:36 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 30 Mar 2023 14:44:36 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v5]
In-Reply-To: <mHU3vRZX4H2iQsCCdwfJzsn8F4ZnmOKhSyv8uD-z9Js=.0d81453a-c349-4da7-b1f2-08b0b70c7761@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
 <4Op0Z8whnyDXDC6zGyMbx4ugcZp5TEoAqW_myB5flxM=.1c7b59ba-efb2-4f68-90d7-2d6e33e39572@github.com>
 <yPyZ7su4OnRDd5LyQPvU0Hk6n5AI5CO2lR12qO9efCg=.51a05574-aee6-416b-863c-76d38a6766c3@github.com>
 <U-1I398elh4CJBPi5J2fEF14qp9ZgoYFhXxMD70L1wI=.2cecacd5-4fb6-4194-a5e4-c1801e0b7691@github.com>
 <mHU3vRZX4H2iQsCCdwfJzsn8F4ZnmOKhSyv8uD-z9Js=.0d81453a-c349-4da7-b1f2-08b0b70c7761@github.com>
Message-ID: <ka5qi0tWKfBx-OBCoQLansVeBAUm3wIJrDv7hMCZ0YE=.890d4fd1-be35-44d7-9ae4-23feb041e25c@github.com>

On Thu, 23 Mar 2023 02:23:20 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> I think not emitting `VectorLoadShuffleNode` is more common so it is better to emit them only when needed, as it will simplify the graph and may allow better inspections of the indices in the future. Additionally, a do-nothing node does not alias with its input and therefore kills the input, which leads to an additional spill if they both need to live.
>
> Yeah, I agree that saving a node have some benefits like what you said. My concern is there are more and more methods added into `Matcher::` and each platform has to do the different implementation. There is not too much meaning for those platforms that do not implement Vector API like` arm/ppc/...` for me. This makes code not so easy to maintain.

I agree, I am thinking of (ab)using template to have a common query function like this

    template <VectorQuery N, class T, class... U>
    T vectorQuery(U... args) {
        return T();
    }

then each platform can have a specialisation that looks like this:

    template <>
    bool vectorQuery<VectorQuery::NEEDS_LOAD_SHUFFLE>(BasicType bt, int vlen) {
    }

Unimplemented platform will return `false` for this, what do you think?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1153370540

From rrich at openjdk.org  Thu Mar 30 14:45:35 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Thu, 30 Mar 2023 14:45:35 GMT
Subject: RFR: 8296440: Remove Method* handling from
 cleanup_inline_caches_impl [v5]
In-Reply-To: <sKZLs2RK8I6WtO2kco2VU4vg3QelVnE_jsyhHqZcSxI=.5caf4c6f-5534-44b5-b1af-e2c0c79b6c9e@github.com>
References: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
 <sKZLs2RK8I6WtO2kco2VU4vg3QelVnE_jsyhHqZcSxI=.5caf4c6f-5534-44b5-b1af-e2c0c79b6c9e@github.com>
Message-ID: <OyqQfTCCGsfbqPRSr5sG5yPB09GPjHm294IAL4Rk_H4=.f2653b16-ec96-471f-9d86-b31b9d89ef52@github.com>

On Wed, 29 Mar 2023 19:54:50 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> This PR replaces cleaning of static stubs in CompiledMethod::cleanup_inline_caches_impl() with a guarantee that it is actually not needed because the holder of the embedded target Method* is alive if the caller nmethod is not unloading.
>> 
>> The holder of the target Method* has to be alive because it is reachable from the caller nmethod's oop pool. This is checked by `check_path_to_callee()` when a statically bound call gets resolved.
>> 
>> C2i entry barriers can be removed for the same reason.
>> 
>> Testing:
>> 
>> Many rounds in our CI testing which includes most JCK and JTREG tests, Renaissance benchmark and SAP specific tests with fastdebug and release builds on the standard platforms plus PPC64.
>> 
>> I've also done tier1 and tier2 tests with -XX:-Inline and tier1 tests with ZGC.
>> 
>> I've started hotspot and jdk tier1 tests with -Xcomp. They were not finished when I stopped them after 24h.
>
> Richard Reingruber has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Check only in debug vm
>  - Merge branch 'master'
>  - Merge branch 'master'
>  - Fix
>  - Feedback Coleene
>  - Adding TestStaticallyBoundTargetIsReachable.java
>  - Path to target exists also if the receiver is a constant of the caller
>  - Use nmethod::oops_do() to search for to_holder in from_nm
>  - Merge branch 'master'
>  - Remove MacroAssembler::resolve_weak_handle()
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/ff368d50...7dd06446

So from my point of view this is ready for integration. Thanks for the help, feeback, and reviews!

Before I'd like to share some final thoughts. So the search in `check_path_to_callee()` is shallow. It might yield false positives. I hope for support by compiler folks adding dependencies at compile time, even if only needed to avoid false positives, and even more so, if no path exists.

To make this really robust, new dependencies could be added to the caller nmethod if no path to the holder of the call target is found. This is not possible atm but maybe the nmethod's oop pool could be changed to be a growable kind of (weak) OopStorage outside the code cache if needed.

An adhoc fix in the case of missing(?) path could be not to resolve the call if the callee should be interpreted. Instead the callee could be compiled in the background. Execution would continue without resolving the call.

@fisk may I ask if you are also ok with the general approach of this pr?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12802#issuecomment-1490429890

From sspitsyn at openjdk.org  Thu Mar 30 14:39:28 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 30 Mar 2023 14:39:28 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v12]
In-Reply-To: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
Message-ID: <t8G0BFqwiXjU2iznI6Aw3Pq5IDiZ_AMovDJf_vwX4co=.451c52c9-03ea-4303-843a-bb7a9e0d9666@github.com>

> The fix is to enable virtual threads support for late binding JVMTI agents.
> The fix includes:
> - New function `JvmtiEnvBase::enable_virtual_threads_notify_jvmti()` which does enabling JVMTI VTMS transition notifications in case of agent loaded into running VM. This function executes a VM operation counting VTMS transition bits in all `JavaThread`'s to correctly set the static counter `_VTMS_transition_count` needed for VTMS transition protocol.
> - New function `JvmtiEnvBase::disable_virtual_threads_notify_jvmti()` which is needed for testing. It is used by the `WhiteBox` API.
> - New WhiteBox function `WB_SetVirtualThreadsNotifyJvmtiMode(JNIEnv* env, jobject wb, jboolean enable)` needed for testing of this update.
> - New regression test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
> 
> Testing:
> - New test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
> - The originally failed tests are expected to pass 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:

  review: minor tweak in test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13133/files
  - new: https://git.openjdk.org/jdk/pull/13133/files/d05ed921..9969a6c3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13133&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13133&range=10-11

  Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13133.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13133/head:pull/13133

PR: https://git.openjdk.org/jdk/pull/13133

From rkennke at openjdk.org  Thu Mar 30 15:04:07 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 30 Mar 2023 15:04:07 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v44]
In-Reply-To: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
Message-ID: <ZfuE9wKC7jPOmWO294zzZ6RwgtkoDb8kDf5hY89EKRI=.f19aac37-a624-4676-bd4a-42990f2ae6b1@github.com>

> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
> 
> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p
 rotocols.
> 
> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare.
> 
> 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
> 
> 
> Testing:
>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
> 
> ### Performance
> 
> #### Simple Microbenchmark
> 
> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
> 
> |  | x86_64 | aarch64 |
> | -- | -- | -- |
> | -UseFastLocking | 20.651 | 20.764 |
> | +UseFastLocking | 18.896 | 18.908 |
> 
> 
> #### Renaissance
> 
> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
> -- | -- | -- | -- | -- | -- | -- | --
> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%

Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 133 commits:

 - Merge branch 'master' into JDK-8291555-v2
 - Several small changes based on reviews
 - Don't retry on inflate; use aarch64 ZF from fast_lock(); bunch of small changes based on reviews
 - Splice entry points for InterpreterRuntime::monitorenter()
 - Use ANONYMOUS_OWNER constant in SA
 - Address more of @shipilev's review comments
 - More verification through zapping unused entries, x86 parts
 - More verification through zapping unused entries; get rid of _thread field
 - Bounds check in lock-stack verification; only do watermark if we have one
 - Relax verification in oops_do(), put back UseFastLocking in management.cpp
 - ... and 123 more: https://git.openjdk.org/jdk/compare/9df20600...815a8209

-------------

Changes: https://git.openjdk.org/jdk/pull/10907/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=43
  Stats: 2068 lines in 54 files changed: 1279 ins; 88 del; 701 mod
  Patch: https://git.openjdk.org/jdk/pull/10907.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10907/head:pull/10907

PR: https://git.openjdk.org/jdk/pull/10907

From sspitsyn at openjdk.org  Thu Mar 30 15:32:16 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 30 Mar 2023 15:32:16 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v4]
In-Reply-To: <GOOPg0-P0Vc1ocNUzWRIbItENekN1ralramscyuF1kQ=.44aded10-e14f-4378-9173-a8126d21da04@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <GOOPg0-P0Vc1ocNUzWRIbItENekN1ralramscyuF1kQ=.44aded10-e14f-4378-9173-a8126d21da04@github.com>
Message-ID: <60eMtJqr0OixK0Yv1WCgN-dvX8nkDVZ0suA6GfwN8tQ=.02972477-1bf0-41a6-a243-bea51d6c7413@github.com>

On Wed, 29 Mar 2023 08:00:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview.
>> 
>> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently.
>> 
>> In addition, there are a small number of implementation changes to sync up from the loom fibers branch:
>> 
>> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where  end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly.
>> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes.
>> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs.
>> - New system property to print a stack trace when a virtual thread sets its own value of a TL.
>> - ThreadPerTaskExecutor is changed to use FutureTask.
>> 
>> Testing: tier1-6.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix ThreadSleepEvent again

This becomes obsolete:
`src/hotspot/share/prims/jvmtiTagMap.cpp:  // disabled if vritual threads are enabled with --enable-preview`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13203#issuecomment-1490507154

From eosterlund at openjdk.org  Thu Mar 30 15:36:22 2023
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 30 Mar 2023 15:36:22 GMT
Subject: RFR: 8296440: Remove Method* handling from
 cleanup_inline_caches_impl [v5]
In-Reply-To: <OyqQfTCCGsfbqPRSr5sG5yPB09GPjHm294IAL4Rk_H4=.f2653b16-ec96-471f-9d86-b31b9d89ef52@github.com>
References: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
 <sKZLs2RK8I6WtO2kco2VU4vg3QelVnE_jsyhHqZcSxI=.5caf4c6f-5534-44b5-b1af-e2c0c79b6c9e@github.com>
 <OyqQfTCCGsfbqPRSr5sG5yPB09GPjHm294IAL4Rk_H4=.f2653b16-ec96-471f-9d86-b31b9d89ef52@github.com>
Message-ID: <XO16zGJNQHrIkeUMk9jtFl0SJ76GT05PBJIJHajzpak=.ef90e88d-d6e1-479a-9d47-2f893dd6cd83@github.com>

On Thu, 30 Mar 2023 14:42:32 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> So from my point of view this is ready for integration. Thanks for the help, feeback, and reviews!
> 
> Before I'd like to share some final thoughts. So the search in `check_path_to_callee()` is shallow. It might yield false positives. I hope for support by compiler folks adding dependencies at compile time, even if only needed to avoid false positives, and even more so, if no path exists.
> 
> To make this really robust, new dependencies could be added to the caller nmethod if no path to the holder of the call target is found. This is not possible atm but maybe the nmethod's oop pool could be changed to be a growable kind of (weak) OopStorage outside the code cache if needed.
> 
> An adhoc fix in the case of missing(?) path could be not to resolve the call if the callee should be interpreted. Instead the callee could be compiled in the background. Execution would continue without resolving the call.
> 
> @fisk may I ask if you are also ok with the general approach of this pr?

I'm okay with the general approach. I'm a bit worried about it though. With this approach, correct unloading of statically bound callsites relies on the dependency data used for deopt due to class loading, also implicitly embed enough information to deal with the unloading. Is there always a match? In order to answer that question we have to either walking all combinations of paths in which our compilers can generate a monomorphic callsite and see that it's correct, hope it doesn't break over time, and hope that the assert catches when it does, or we will end up crashing very intermittently in very obscure ways.
I have spent a fair amount of time looking through the different paths in which you get to the decision point of generating a statically bound callsite, and I *think* that it is currently correct. But there are so many paths, I find it hard to follow them all.
I would have preferred separating implicit dependency on all the reasons why a callsite became statically bound, with how to deal with correct unloading, so that it's easier to reason about it with certainty. For example, making sure there is an oop slot for each statically bound callsite, and when resolving the callsite, just ensure the holder oop is in there and register_nmethod() to the GC. We already have support for calling register_nmethod multiple times due to C1 mirror patching that does a similar trick. Then we could algorithmically ensure that the logic works as expected, regardless of why the callsite became statically bound.
Having said that, I'm okay with this approach too. We will probably run into the assert if something fishy happens, eventually. So I'll leave it to you to decide, and I'm okay with integrating as is.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12802#issuecomment-1490512796

From sspitsyn at openjdk.org  Thu Mar 30 15:45:04 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 30 Mar 2023 15:45:04 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v4]
In-Reply-To: <GOOPg0-P0Vc1ocNUzWRIbItENekN1ralramscyuF1kQ=.44aded10-e14f-4378-9173-a8126d21da04@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <GOOPg0-P0Vc1ocNUzWRIbItENekN1ralramscyuF1kQ=.44aded10-e14f-4378-9173-a8126d21da04@github.com>
Message-ID: <PDCVTBSggRKGeuzA1a-qbl2qJH-ZsgTtMLc6oGreLeY=.bdad5c7c-61c3-464b-89ac-dbea23fbfb96@github.com>

On Wed, 29 Mar 2023 08:00:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview.
>> 
>> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently.
>> 
>> In addition, there are a small number of implementation changes to sync up from the loom fibers branch:
>> 
>> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where  end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly.
>> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes.
>> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs.
>> - New system property to print a stack trace when a virtual thread sets its own value of a TL.
>> - ThreadPerTaskExecutor is changed to use FutureTask.
>> 
>> Testing: tier1-6.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix ThreadSleepEvent again

Marked as reviewed by sspitsyn (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13203#pullrequestreview-1365421647

From rkennke at openjdk.org  Thu Mar 30 16:07:17 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 30 Mar 2023 16:07:17 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v45]
In-Reply-To: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
Message-ID: <QpPPV__KrLy61jRxC5Ye_kPEcwN7vOVw7ZP10BrtsfA=.514ada34-872e-4378-a013-25cafb5dac63@github.com>

> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
> 
> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p
 rotocols.
> 
> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare.
> 
> 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
> 
> 
> Testing:
>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
> 
> ### Performance
> 
> #### Simple Microbenchmark
> 
> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
> 
> |  | x86_64 | aarch64 |
> | -- | -- | -- |
> | -UseFastLocking | 20.651 | 20.764 |
> | +UseFastLocking | 18.896 | 18.908 |
> 
> 
> #### Renaissance
> 
> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
> -- | -- | -- | -- | -- | -- | -- | --
> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Allow old monitorenter entry point when using heavy monitors

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10907/files
  - new: https://git.openjdk.org/jdk/pull/10907/files/815a8209..6514f831

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=44
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=43-44

  Stats: 56 lines in 16 files changed: 0 ins; 0 del; 56 mod
  Patch: https://git.openjdk.org/jdk/pull/10907.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10907/head:pull/10907

PR: https://git.openjdk.org/jdk/pull/10907

From stuefe at openjdk.org  Thu Mar 30 16:08:55 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 30 Mar 2023 16:08:55 GMT
Subject: RFR: JDK-8304815: Use NMT for more precise hs_err location
 printing [v7]
In-Reply-To: <DPqsrXUm5sJjcxDGZW6QSvdpu83LBhwXreIJU7LXqjI=.dfe3de5e-919a-494d-a8dd-0622d1ee0c65@github.com>
References: <DPqsrXUm5sJjcxDGZW6QSvdpu83LBhwXreIJU7LXqjI=.dfe3de5e-919a-494d-a8dd-0622d1ee0c65@github.com>
Message-ID: <vqnP4aPirIfiVVmHN45Qht-FK1HeweJSywjO1YGb4So=.f54bfd01-8275-4a7d-a8c2-1af1db7e3d34@github.com>

> (This is a byproduct of work on the arm port for https://github.com/openjdk/jdk/pull/10907. I needed better debugging information in the hs-err file and in gdb.)
> 
> Back in 2022 @zhengyu123 had the very nice idea of using NMT mapping info for smartening up pp in gdb: [JDK-8280289](https://bugs.openjdk.org/browse/JDK-8280289).
> 
> The same idea can be applied to hs_err file location printing. NMT has information about all its mappings and can tell us where it thinks a given unknown pointer points into.
> 
> This could be even more useful if the "find malloc block" part of that functionality would be smarter. As it is now, it only works if the pointer in question points to the start of a user-allocated area. Would be nice if the code could (carefully) search for the next valid-looking malloc header instead.
> 
> --------------
> 
> This patch does this: we introduce a new API, MemTracker::print_containing_region(void*), that tries to make sense of a given unknown pointer.
> 
> It will search its mmap regions and print those if found. For malloc'ed pointers, it will carefully sniff out the immediate surroundings of the block, trying to find what looks like a valid malloc header. It uses SafeFetch to not trip over unmapped or protected pages. Note that, of course, we may get false recognition positives if it finds something that looks like a valid header. But even that could be useful (e.g. a remnant dead header may indicate we access memory after free).
> 
> Looks like this (its arm, so 32-bit pointers):
> 
> 
> Register to memory mapping:
> 
> ->  r0  = 0x728a6ae0 into life malloced block starting at 0x728a6ae0, size 104, tag mtSynchronizer
> ->  r1  = 0x75b02010 into life malloced block starting at 0x75b02010, size 184, tag mtObjectMonitor
> ->  r2  = 0x728a6ae0 into life malloced block starting at 0x728a6ae0, size 104, tag mtSynchronizer
>     r3  = 0x0 is nullptr
> ->  r4  = 0x728a6ae0 into life malloced block starting at 0x728a6ae0, size 104, tag mtSynchronizer
>     r5  = 0xb6d3bbc8: <offset 0x018f6bc8> in /shared/projects/openjdk/jdk-jdk/output-fastdebug-arm/images/jdk/lib/server/libjvm.so at 0xb5445000
>     r6  = 0xffffffff is an unknown value
>     r7  = 0x0 is nullptr
>     r8  = 0x0000000a is an unknown value
>     r9  = 0x728a4308 is a thread
>     r10 = 0x0000000b is an unknown value
> ->  fp  = 0x753fe8cc in mmap'd memory region [0x75380000 - 0x75400000] by Thread Stack
>     r12 = 0x0 is nullptr
> ->  sp  = 0x753fe8b0 in mmap'd memory region [0x75380000 - 0x75400000] by Thread Stack
>     lr  = 0xb69bc1d0: <offset 0x015771d0> in /shared/projects/openjdk/jdk-jdk/output-fastdebug-arm/images/jdk/lib/server/libjvm.so at 0xb5445000
>     pc  = 0xb69c8670: <offset 0x01583670> in /shared/projects/openjdk/jdk-jdk/output-fastdebug-arm/images/jdk/lib/server/libjvm.so at 0xb5445000
> 
> 
> 
> The small caveat here is that NMT reporting needs ThreadCritical, and thus using it for location printing may block error reporting if it crashed inside a ThreadCritical section. We face the same issue today when printing the NMT report as part of the hs-err file. 
> 
> I think the usefulness of these printouts justify this risk. However I opened https://bugs.openjdk.org/browse/JDK-8304824 to investigate a better locking strategy for NMT.

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  life->live

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13162/files
  - new: https://git.openjdk.org/jdk/pull/13162/files/e5a4a9f1..d19d06ca

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13162&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13162&range=05-06

  Stats: 22 lines in 3 files changed: 0 ins; 0 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/13162.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13162/head:pull/13162

PR: https://git.openjdk.org/jdk/pull/13162

From sspitsyn at openjdk.org  Thu Mar 30 16:36:33 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 30 Mar 2023 16:36:33 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v9]
In-Reply-To: <h4LtLLHAlnhcXjk86aLW3Z0hWTu_QFVQqHLujXyM4sY=.d413da77-0a70-4436-8b6e-4ce3ed47bf94@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <5SO5rUZwV3SQ2w7t7mOwmP1jXjUVgl4g7NiT7cKi9LU=.355314c8-03ec-4a1e-80d8-e70e98868ecc@github.com>
 <OuUlFEljlkU8Xt6vnaAyu7DFS5ymckFGQcjdncpRVbA=.19174f7d-5473-4586-ad96-56d646d38b75@github.com>
 <h4LtLLHAlnhcXjk86aLW3Z0hWTu_QFVQqHLujXyM4sY=.d413da77-0a70-4436-8b6e-4ce3ed47bf94@github.com>
Message-ID: <ixR1jOEsuVdJoUKBS1wWBWV1oj1jrSBf7IgK3x_5dkQ=.cdb01547-8ee2-49d6-8fb1-835af6d7dc9e@github.com>

On Thu, 30 Mar 2023 01:32:28 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1554:
>> 
>>> 1552:       }
>>> 1553:       // Correct jt->jvmti_thread_state() and jt->jvmti_vthread() if necessary.
>>> 1554:       // It was not maintained while notifyJvmti was disabled.
>> 
>> While trying to understand which exact situation we are trying to guard against with this code, I run the test without the sleeps and without this restore code and I got a crash when deleting a JvmtiThreadState (null dereference of _thread in the ~()). Probably the same crash you mentioned you had. But when debugging the crash I see that the problem is that the assumption that disabling the flag is done when no virtual threads are running is not guaranteed (see my comment there). So I think we are trying to address a case that shouldn't happen in the first place. Also not sure if applying this restore in all cases will be correct, since we might be somewhere at a transition. For example, a thread could have blocked right in the return from notifyJvmtiUnmount() in yieldContinuation(). It will looked like virtual because unmount() was not executed yet, and the jvmti_thread_state should be that of the platform thread because we never changed it when mounting. We should leave the stat
 e as is but in here we would change it to the virtual thread's jvmti state. The only case I think it makes sense to do this restore steps when enabling the flag is for those threads that are outside a transition with a mounted virtual thread, since we want to adjust the jvmti_thread_state so that it looks right on the next unmount.
>> But in any case this is also only needed when using the WhiteBox methods right? In the intended case (no WhiteBox method used), after we execute this operation to enable the events, we will create the JvmtiThreadStates later in JvmtiExport::get_jvmti_interface() and the correct jvmti_thread_state and jvmti_vthread will be already set for each JavaThread. In that case can we only execute this restore code when using the WhiteBox API?
>
> I've just pushed my update with refactoring of these corrections in `VM_SetNotifyJvmtiEventsMode` after discussion of this code with Leonid. I hope it resolved at least part of your concerns.
> This kind of problem exists only when we disable+enable notifyJvmti events multiple times for testing purposes.
> This code with corrections of jt->jvmti_thread_state() is not needed when we enable notifyJvmti events just once.
> Your are correct that the ability to disable notifyJvmti events is implemented with using WhiteBox API.
> My last update has a comment explaining this.
> 
>> In that case can we only execute this restore code when using the WhiteBox API?
> 
> This is a good suggestion which we already discussed privately with Leonid.
> I've got an idea how to implement this check.

> Also not sure if applying this restore in all cases will be correct, since we might be somewhere at a transition. For example, a thread could have blocked right in the return from notifyJvmtiUnmount() in yieldContinuation(). It will looked like virtual because unmount() was not executed yet, and the jvmti_thread_state should be that of the platform thread because we never changed it when mounting. We should leave the state as is but in here we would change it to the virtual thread's jvmti state. The only case I think it makes sense to do this restore steps when enabling the flag is for those threads that are outside a transition with a mounted virtual thread, since we want to adjust the jvmti_thread_state so that it looks right on the next unmount.

Agreed, thanks. In fact, I've already experimented with it.
As you noted, this correction is wrong for unmount transition. Also, we don't need to correct it for mount transition because it will be corrected by the `JvmtiVTMSTransitionDisabler::VTMS_mount_end()` as it makes a call `thread->rebind_to_jvmti_thread_state_of(vt)`.
The only thing that bothers me here is that we fight non-real problems as this code is needed only to support artificial disabling for testing purposes to be able to repeat enable again. :-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1153513204

From kvn at openjdk.org  Thu Mar 30 16:46:37 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 30 Mar 2023 16:46:37 GMT
Subject: RFR: 8231349: Move intrinsic stubs generation to compiler runtime
 initialization code [v2]
In-Reply-To: <29CsTb21Kwy0gEb-nz3fhq0p4gbXx2RBzFJEid2uEgU=.378f44c5-cc1a-4916-b3b8-1ed61621cada@github.com>
References: <dtc9rdiBGUpqQUB9AzWBroeF3ziVODfk0FuPFDgOHqE=.096e99b2-2957-46c7-8c74-ae1d737f220d@github.com>
 <mps4Bze-krj-aWVdtS6CcpRmOf9_gs-lmDI3iH7AvIQ=.8671e010-995c-4d1c-8282-afbb5ae6f2bf@github.com>
 <YX72intbDBNCoz_lL71NtHiBhzClh4KbEldmnViz2Tc=.d193dd7b-d364-47c2-be40-178cb4d25c1c@github.com>
 <29CsTb21Kwy0gEb-nz3fhq0p4gbXx2RBzFJEid2uEgU=.378f44c5-cc1a-4916-b3b8-1ed61621cada@github.com>
Message-ID: <U-yLDhg5ddQYvWSKG3CWO_-5MHtgQREs028JkKomLHg=.949f9a72-e05f-41b0-919f-41f9109f951d@github.com>

On Thu, 30 Mar 2023 09:04:47 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> I renamed flag and used `COMPILER2_OR_JVMCI` as default value (based on Vladimir last suggestion).
>
> Hi @vnkozlov, 
> 
> these changes broke the build for s390x platform. I've opened [JDK-8305227](https://bugs.openjdk.org/browse/JDK-8305227) and put hs_err* log file there as well. 
> 
> It would be helpful if you could take a look and provide some suggestion. 
> 
> Thanks

@offamitkumar I added comment to new bug. In short, you can try to disable this optimization for s390.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13096#issuecomment-1490610700

From mdoerr at openjdk.org  Thu Mar 30 16:53:18 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 30 Mar 2023 16:53:18 GMT
Subject: RFR: 8303210: [linux,
 Windows] Make UseSystemMemoryBarrier available as product flag [v7]
In-Reply-To: <9eZo1xYNGhjMSC9lDXKtkO1eyU_H-Veuh1AeP3CPKbg=.69b6c4ff-a3ef-439f-8468-21fec9de1825@github.com>
References: <9eZo1xYNGhjMSC9lDXKtkO1eyU_H-Veuh1AeP3CPKbg=.69b6c4ff-a3ef-439f-8468-21fec9de1825@github.com>
Message-ID: <s2PuR1n-7F7-Bql_JAjr3xwRA8WZtcFlmYKXcpKon58=.d07c16aa-4572-4b74-9289-89cbabaf91ab@github.com>

> I'd like to enable UseSystemMemoryBarrier by default on supported Operating Systems in order to improve performance of thread state transitions (I/O, JNI, foreign function calls, JIT compiler threads, etc.). See JBS issue for more details.
> Unfortunately, the feature was not yet implemented on all platforms. I added the code, but need the platform maintainers to check if it can be used reliably (and ideally if the performance improves). It's easy to switch it off again in case of problems.
> 
> Update: Startup performance and some benchmarks on some platforms are impacted (see below). So, this PR no longer switches it on by default.

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  Move flag configuration and initialization to SystemMemoryBarrier and call it from parse_vm_init_args.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12753/files
  - new: https://git.openjdk.org/jdk/pull/12753/files/adcc0cd6..55d9837a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12753&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12753&range=05-06

  Stats: 44 lines in 6 files changed: 14 ins; 28 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12753/head:pull/12753

PR: https://git.openjdk.org/jdk/pull/12753

From mdoerr at openjdk.org  Thu Mar 30 16:54:49 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 30 Mar 2023 16:54:49 GMT
Subject: RFR: 8303210: [linux,
 Windows] Make UseSystemMemoryBarrier available as product flag [v6]
In-Reply-To: <4W40qd3bqnubOEUZZcDvuCtjsWn9VJeZnnS4eSxUm8s=.e408ce7b-8b02-4a97-b3c8-15836ce0e873@github.com>
References: <9eZo1xYNGhjMSC9lDXKtkO1eyU_H-Veuh1AeP3CPKbg=.69b6c4ff-a3ef-439f-8468-21fec9de1825@github.com>
 <4W40qd3bqnubOEUZZcDvuCtjsWn9VJeZnnS4eSxUm8s=.e408ce7b-8b02-4a97-b3c8-15836ce0e873@github.com>
Message-ID: <BaDhZMOxA6GgedzI28Y3wgGerTklLBLSl51tQzoLHwM=.2a502e46-307e-4d58-a7b4-8144f97bf2e7@github.com>

On Wed, 29 Mar 2023 10:36:50 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> I'd like to enable UseSystemMemoryBarrier by default on supported Operating Systems in order to improve performance of thread state transitions (I/O, JNI, foreign function calls, JIT compiler threads, etc.). See JBS issue for more details.
>> Unfortunately, the feature was not yet implemented on all platforms. I added the code, but need the platform maintainers to check if it can be used reliably (and ideally if the performance improves). It's easy to switch it off again in case of problems.
>> 
>> Update: Startup performance and some benchmarks on some platforms are impacted (see below). So, this PR no longer switches it on by default.
>
> Martin Doerr has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove unintended newline from os_aix.cpp.
>  - Remove leftover from os_aix.cpp.

I already had a bad feeling replicating the code. I've put the flag configuration directly into systemMemoryBarrier.hpp (because there is no .cpp file). Is this ok?
The CSR is now provisional. Do we have to do anything or just wait?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12753#issuecomment-1490622972

From darcy at openjdk.org  Thu Mar 30 17:02:08 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 30 Mar 2023 17:02:08 GMT
Subject: RFR: 8303210: [linux,
 Windows] Make UseSystemMemoryBarrier available as product flag [v6]
In-Reply-To: <BaDhZMOxA6GgedzI28Y3wgGerTklLBLSl51tQzoLHwM=.2a502e46-307e-4d58-a7b4-8144f97bf2e7@github.com>
References: <9eZo1xYNGhjMSC9lDXKtkO1eyU_H-Veuh1AeP3CPKbg=.69b6c4ff-a3ef-439f-8468-21fec9de1825@github.com>
 <4W40qd3bqnubOEUZZcDvuCtjsWn9VJeZnnS4eSxUm8s=.e408ce7b-8b02-4a97-b3c8-15836ce0e873@github.com>
 <BaDhZMOxA6GgedzI28Y3wgGerTklLBLSl51tQzoLHwM=.2a502e46-307e-4d58-a7b4-8144f97bf2e7@github.com>
Message-ID: <Qi4hMyNUesBwotMIY4yYeajHuIYdowlug_X7MPUwLBw=.836459dd-c7eb-4ab2-be2f-4b540272ca42@github.com>

On Thu, 30 Mar 2023 16:52:23 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> I already had a bad feeling replicating the code. I've put the flag configuration directly into systemMemoryBarrier.hpp (because there is no .cpp file). Is this ok? The CSR is now provisional. Do we have to do anything or just wait?

"Possibly after additional refinement and additional reviewers, the proposal is Finalized by the assignee to request the second phase of CSR review."
https://wiki.openjdk.org/display/csr/Main

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12753#issuecomment-1490630827

From sspitsyn at openjdk.org  Thu Mar 30 17:10:16 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 30 Mar 2023 17:10:16 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v13]
In-Reply-To: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
Message-ID: <d7v-k44x3tTGLm1YHfd40bGgoBeaYDu2o_a1Rb7sT08=.607ecff9-d81e-470b-9671-70e1c24a500c@github.com>

> The fix is to enable virtual threads support for late binding JVMTI agents.
> The fix includes:
> - New function `JvmtiEnvBase::enable_virtual_threads_notify_jvmti()` which does enabling JVMTI VTMS transition notifications in case of agent loaded into running VM. This function executes a VM operation counting VTMS transition bits in all `JavaThread`'s to correctly set the static counter `_VTMS_transition_count` needed for VTMS transition protocol.
> - New function `JvmtiEnvBase::disable_virtual_threads_notify_jvmti()` which is needed for testing. It is used by the `WhiteBox` API.
> - New WhiteBox function `WB_SetVirtualThreadsNotifyJvmtiMode(JNIEnv* env, jobject wb, jboolean enable)` needed for testing of this update.
> - New regression test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
> 
> Testing:
> - New test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
> - The originally failed tests are expected to pass 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:

  review: tweak in count_transitions_and_correct_jvmti_thread_states

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13133/files
  - new: https://git.openjdk.org/jdk/pull/13133/files/9969a6c3..1bb250a7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13133&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13133&range=11-12

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13133.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13133/head:pull/13133

PR: https://git.openjdk.org/jdk/pull/13133

From sspitsyn at openjdk.org  Thu Mar 30 17:14:24 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 30 Mar 2023 17:14:24 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v5]
In-Reply-To: <qVfNBfPP6pizIr16-aXD851jbQ8ZNOV7BvH_Yt-jrbo=.d22c7807-c952-4337-ae69-60a8070ad852@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <27JLa60WeywSMcJj-6KfaQD8RBnwBbAvcc0gecc-3h4=.a2a25b70-9e90-4551-af90-35aed3d57b59@github.com>
 <qVfNBfPP6pizIr16-aXD851jbQ8ZNOV7BvH_Yt-jrbo=.d22c7807-c952-4337-ae69-60a8070ad852@github.com>
Message-ID: <wARLtBLaMIWaHC-J_AcQNEO6YW5RbI1tNzeOppxPtfU=.3ba7d410-7816-4e28-8ce6-387b64d11556@github.com>

On Thu, 23 Mar 2023 18:05:47 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address review comment: remove unneeded function
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest.java line 157:
> 
>> 155: 
>> 156:         if (args.length > 0 && args[0].equals("attach")) { // agent loaded into running VM case
>> 157:             String arg = args.length == 2 ? args[1] : "";
> 
> I don't see any args being passed in other than "attach"? What might `arg` be set to?

Only "attach" can be passed in args.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1153556293

From sspitsyn at openjdk.org  Thu Mar 30 18:08:18 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 30 Mar 2023 18:08:18 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v4]
In-Reply-To: <GOOPg0-P0Vc1ocNUzWRIbItENekN1ralramscyuF1kQ=.44aded10-e14f-4378-9173-a8126d21da04@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <GOOPg0-P0Vc1ocNUzWRIbItENekN1ralramscyuF1kQ=.44aded10-e14f-4378-9173-a8126d21da04@github.com>
Message-ID: <KJ63TVm2sc5rTGI8bmmoPqi0kKflfGcU2-MHAt-EsaA=.1001fc1b-d222-44c4-aa81-be0c4326d187@github.com>

On Wed, 29 Mar 2023 08:00:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview.
>> 
>> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently.
>> 
>> In addition, there are a small number of implementation changes to sync up from the loom fibers branch:
>> 
>> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where  end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly.
>> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes.
>> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs.
>> - New system property to print a stack trace when a virtual thread sets its own value of a TL.
>> - ThreadPerTaskExecutor is changed to use FutureTask.
>> 
>> Testing: tier1-6.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix ThreadSleepEvent again

I looked at Serviceability changes and related tests. They are good.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13203#issuecomment-1490713160

From lmesnik at openjdk.org  Thu Mar 30 18:38:24 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 30 Mar 2023 18:38:24 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v13]
In-Reply-To: <d7v-k44x3tTGLm1YHfd40bGgoBeaYDu2o_a1Rb7sT08=.607ecff9-d81e-470b-9671-70e1c24a500c@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <d7v-k44x3tTGLm1YHfd40bGgoBeaYDu2o_a1Rb7sT08=.607ecff9-d81e-470b-9671-70e1c24a500c@github.com>
Message-ID: <K5XXqmSxAGPGIQoWNglN-yzz7zaBPCJMvAGnSCRE318=.8eee4abd-456c-46aa-bef1-067b5390e7e2@github.com>

On Thu, 30 Mar 2023 17:10:16 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The fix is to enable virtual threads support for late binding JVMTI agents.
>> The fix includes:
>> - New function `JvmtiEnvBase::enable_virtual_threads_notify_jvmti()` which does enabling JVMTI VTMS transition notifications in case of agent loaded into running VM. This function executes a VM operation counting VTMS transition bits in all `JavaThread`'s to correctly set the static counter `_VTMS_transition_count` needed for VTMS transition protocol.
>> - New function `JvmtiEnvBase::disable_virtual_threads_notify_jvmti()` which is needed for testing. It is used by the `WhiteBox` API.
>> - New WhiteBox function `WB_SetVirtualThreadsNotifyJvmtiMode(JNIEnv* env, jobject wb, jboolean enable)` needed for testing of this update.
>> - New regression test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
>> 
>> Testing:
>> - New test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
>> - The originally failed tests are expected to pass 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:
> 
>   review: tweak in count_transitions_and_correct_jvmti_thread_states

Marked as reviewed by lmesnik (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13133#pullrequestreview-1365718520

From mgronlun at openjdk.org  Thu Mar 30 18:41:25 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 30 Mar 2023 18:41:25 GMT
Subject: RFR: 8257967: JFR: Events for loaded agents [v11]
In-Reply-To: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
References: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
Message-ID: <bdppfWY7N9UAdB8nlNbWpGYBdmB9NDoSU_Tpu4xUUvg=.feb88213-6d4d-4cfd-80cf-19a66dba6237@github.com>

> Greetings,
> 
> We are adding support to let JFR report on Agents.
> 
> #### Design
> 
> An Agent is a library that uses any instrumentation or profiling APIs. Most agents are started and initialized on the command line, but agents can also be loaded dynamically during runtime. Because command line agents initialize during the VM startup sequence, they add to the overall startup time latency in getting the VM ready. The events will report on the time the agent took to initialize.
> 
> A JavaAgent is an agent written in the Java programming language, using the APIs in the package [java.lang.instrument](https://docs.oracle.com/en/java/javase/19/docs/api/java.instrument/java/lang/instrument/package-summary.html)
> 
> A JavaAgent is sometimes called a JPLIS agent, where the acronym JPLIS stands for Java Programming Language Instrumentation Services.
> 
> To report on JavaAgents, JFR will add the new event type jdk.JavaAgent and events will look similar to these two examples:
> 
> // Command line
> jdk.JavaAgent {
>   startTime = 12:31:19.789 (2023-03-08)
>   name = "JavaAgent.jar"
>   options = "foo=bar"
>   dynamic = false
>   initialization = 12:31:15.574 (2023-03-08)
>   initializationTime = 172 ms
> }
> 
> // Dynamic load
> jdk.JavaAgent {
>   startTime = 12:31:31.158 (2023-03-08)
>   name = "JavaAgent.jar"
>   options = "bar=baz"
>   dynamic = true
>   initialization = 12:31:31.037 (2023-03-08)
>   initializationTime = 64,1 ms
> }
> 
> The jdk.JavaAgent event type is a JFR periodic event that iterates over running Java agents.
> 
> For a JavaAgent event, the agent's name will be the specific .jar file containing the instrumentation code. The options will be the specific options passed to the .jar file as part of launching the agent, for example, on the command line: -javaagent: JavaAgent.jar=foo=bar.
> 
> The "dynamic" field denotes if the agent was loaded via the command line (dynamic = false) or dynamically (dynamic = true)
> 
> "initialization" is the timestamp the JVM invoked the initialization method, and "initializationTime" is the duration of executing the initialization method.
> 
> "startTime" represents the time the JFR framework issued the periodic event; hence "initialization" will be earlier than "startTime".
> 
> An agent can also be written in a native programming language using the [JVM Tools Interface (JVMTI)](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html). This kind of agent, sometimes called a native agent, is a platform-specific binary, sometimes referred to as a library, but here it means a .so or .dll file.
> 
> To report on native agents, JFR will add the new event type jdk.NativeAgent and events will look similar to this example:
> 
> jdk.NativeAgent {
>   startTime = 12:31:40.398 (2023-03-08)
>   name = "jdwp"
>   options = "transport=dt_socket,server=y,address=any,onjcmd=y"
>   dynamic = false
>   initialization = 12:31:36.142 (2023-03-08)
>   initializationTime = 0,00184 ms
>   path = "c:\ade\github\openjdk\jdk\build\windows-x86_64-server-slowdebug\jdk\bin\jdwp.dll"
> }
> 
> The layout of the event type is very similar to the jdk.JavaAgent event, but here the path to the native library is reported.
> 
> The initialization of a native agent is performed by invoking an agent-specified callback routine. The "initialization" is when the JVM sent or would have sent the JVMTI VMInit event to a specified callback. "initializationTime" is the duration to execute that specific callback. If no callback is specified for the JVMTI VMInit event, the "initializationTime" will be 0.
> 
> #### Implementation
> 
> There has not existed a reification of a JavaAgent directly in the JVM, as these are built on top of the JDK native library, "instrument", using a many-to-one mapping. At the level of the JVM, the only representation of agents after startup is through JvmtiEnv's, which agents request from the JVM during startup and initialization ? as such, mapping which JvmtiEnv belongs to what JavaAgent was not possible before.
> 
> Using implementation details of how the JDK native library "instrument" interacts with the JVM, we can build this mapping to track what JvmtiEnv's "belong" to what JavaAgent. This mapping now lets us report the Java-relevant context (name, options) and measure the time it takes for the JavaAgent to initialize.
> 
> When implementing this capability, it was necessary to refactor the code used to represent agents, AgentLibrary. The previous implementation was located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp.
> 
> The refactoring isolates the relevant logic into two new modules, prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their older places will help reduce the sizes of oversized arguments.cpp and threads.cpp.
> 
> The previous two lists that maintained "agents" (JVMTI) and "libraries" (Xrun) were not thread-safe for concurrent iterations. A single list that allows for concurrent iterations is therefore introduced.
> 
> Testing: jdk_jfr, tier 1 - 6
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  reviewer feedback, loading to agent.cpp, bugfix loading statically linked agent

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12923/files
  - new: https://git.openjdk.org/jdk/pull/12923/files/741b8686..0b10773f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12923&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12923&range=09-10

  Stats: 1079 lines in 9 files changed: 481 ins; 426 del; 172 mod
  Patch: https://git.openjdk.org/jdk/pull/12923.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12923/head:pull/12923

PR: https://git.openjdk.org/jdk/pull/12923

From jcking at openjdk.org  Thu Mar 30 18:52:15 2023
From: jcking at openjdk.org (Justin King)
Date: Thu, 30 Mar 2023 18:52:15 GMT
Subject: RFR: JDK-8305320: DbgStrings and AsmRemarks are leaking
Message-ID: <YrI5v7ZTv4tMmuaqbDxpAb6T997fMtMf8Y-cSZYRzV8=.e97c56e5-bf73-4753-be18-162825966f83@github.com>

Fix two leaks related to `DbgStrings` and `AsmRemarks` in debug builds.

-------------

Commit messages:
 - Fix leaks related to AsmRemarks and DbgStrings
 - Revert "Fix leak related to DbgStrings"
 - Fix leak related to DbgStrings

Changes: https://git.openjdk.org/jdk/pull/13249/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13249&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305320
  Stats: 9 lines in 3 files changed: 9 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13249.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13249/head:pull/13249

PR: https://git.openjdk.org/jdk/pull/13249

From pchilanomate at openjdk.org  Thu Mar 30 18:59:25 2023
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 30 Mar 2023 18:59:25 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v8]
In-Reply-To: <LaZ06w_MJRJpvdqTFi26wjRyr5UNXdyn-Z5yZbz0Wek=.11e486d0-6f4e-4ee9-8483-6da223285eae@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <uZLGDh5UIBW0AYrgh4ndTUtnqNfp2zGgnx2zQm-kBaI=.f3d7e776-0e81-4272-bc31-2cdee9dc9d23@github.com>
 <e2yRT6_VCygbdYXbK7epZoKuABw6KjBt3CqOrTajh_4=.6441c156-5ae6-4f5e-8e86-a5c2d7c15645@github.com>
 <LaZ06w_MJRJpvdqTFi26wjRyr5UNXdyn-Z5yZbz0Wek=.11e486d0-6f4e-4ee9-8483-6da223285eae@github.com>
Message-ID: <QqBVDv9m5JYGlFy1N4PdqhLQfA7-0LGN0a9JB-XDsng=.2a2d1dfe-df60-45c2-86f1-b5e2aec0b036@github.com>

On Thu, 30 Mar 2023 00:55:59 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1550:
>> 
>>> 1548: 
>>> 1549:       if (jt->is_in_VTMS_transition()) {
>>> 1550:         count++;
>> 
>> For those threads that are in a transition when we enable the events, shouldn't we also set the jvmti_is_in_VTMS_transition field for the corresponding vthread as we do in JvmtiVTMSTransitionDisabler::start_VTMS_transition()? It seems a JvmtiVTMSTransitionDisabler that targets that particular vthread could otherwise proceed after the safepoint while that vthread is still in the transition. The "all" JvmtiVTMSTransitionDisabler won't proceed because that one does check the _VTMS_transition_count counter. I see that in general we won't have access to the vthread oop though.
>
> Nice catch, thanks!
> Fixed now, but will push it together with other potential updates related to your review comments.

The issue I see is that during a transition the vt_oop that we'll get will almost always be that of the carrier thread, because it's almost the first thing we change when unmounting, and the last we change when mounting.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1153672474

From pchilanomate at openjdk.org  Thu Mar 30 18:59:28 2023
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 30 Mar 2023 18:59:28 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v9]
In-Reply-To: <ixR1jOEsuVdJoUKBS1wWBWV1oj1jrSBf7IgK3x_5dkQ=.cdb01547-8ee2-49d6-8fb1-835af6d7dc9e@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <5SO5rUZwV3SQ2w7t7mOwmP1jXjUVgl4g7NiT7cKi9LU=.355314c8-03ec-4a1e-80d8-e70e98868ecc@github.com>
 <OuUlFEljlkU8Xt6vnaAyu7DFS5ymckFGQcjdncpRVbA=.19174f7d-5473-4586-ad96-56d646d38b75@github.com>
 <h4LtLLHAlnhcXjk86aLW3Z0hWTu_QFVQqHLujXyM4sY=.d413da77-0a70-4436-8b6e-4ce3ed47bf94@github.com>
 <ixR1jOEsuVdJoUKBS1wWBWV1oj1jrSBf7IgK3x_5dkQ=.cdb01547-8ee2-49d6-8fb1-835af6d7dc9e@github.com>
Message-ID: <9SIS30RyTgA-KjW_vQ1byD6b-SlVyJWoXD_IaOxk95I=.a5138742-c319-444e-bb3f-5d63d2106bbb@github.com>

On Thu, 30 Mar 2023 16:33:01 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> I've just pushed my update with refactoring of these corrections in `VM_SetNotifyJvmtiEventsMode` after discussion of this code with Leonid. I hope it resolved at least part of your concerns.
>> This kind of problem exists only when we disable+enable notifyJvmti events multiple times for testing purposes.
>> This code with corrections of jt->jvmti_thread_state() is not needed when we enable notifyJvmti events just once.
>> Your are correct that the ability to disable notifyJvmti events is implemented with using WhiteBox API.
>> My last update has a comment explaining this.
>> 
>>> In that case can we only execute this restore code when using the WhiteBox API?
>> 
>> This is a good suggestion which we already discussed privately with Leonid.
>> I've got an idea how to implement this check.
>
>> Also not sure if applying this restore in all cases will be correct, since we might be somewhere at a transition. For example, a thread could have blocked right in the return from notifyJvmtiUnmount() in yieldContinuation(). It will looked like virtual because unmount() was not executed yet, and the jvmti_thread_state should be that of the platform thread because we never changed it when mounting. We should leave the state as is but in here we would change it to the virtual thread's jvmti state. The only case I think it makes sense to do this restore steps when enabling the flag is for those threads that are outside a transition with a mounted virtual thread, since we want to adjust the jvmti_thread_state so that it looks right on the next unmount.
> 
> Agreed, thanks. In fact, I've already experimented with it.
> As you noted, this correction is wrong for unmount transition. Also, we don't need to correct it for mount transition because it will be corrected by the `JvmtiVTMSTransitionDisabler::VTMS_mount_end()` as it makes a call `thread->rebind_to_jvmti_thread_state_of(vt)`.
> The only thing that bothers me here is that we fight non-real problems as this code is needed only to support artificial disabling for testing purposes to be able to repeat enable again. :-)

The fix to only restore the state outside a transition looks good.
Yes, the added testing methods are making this harder :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1153670911

From mgronlun at openjdk.org  Thu Mar 30 18:59:30 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 30 Mar 2023 18:59:30 GMT
Subject: RFR: 8257967: JFR: Events for loaded agents [v12]
In-Reply-To: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
References: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
Message-ID: <RHxW8J0VDDZ88ljuAmNmb4D4eVj3avUr1Jj3AvqPPIA=.70a33d33-972e-437b-8814-7d251de615f7@github.com>

> Greetings,
> 
> We are adding support to let JFR report on Agents.
> 
> #### Design
> 
> An Agent is a library that uses any instrumentation or profiling APIs. Most agents are started and initialized on the command line, but agents can also be loaded dynamically during runtime. Because command line agents initialize during the VM startup sequence, they add to the overall startup time latency in getting the VM ready. The events will report on the time the agent took to initialize.
> 
> A JavaAgent is an agent written in the Java programming language, using the APIs in the package [java.lang.instrument](https://docs.oracle.com/en/java/javase/19/docs/api/java.instrument/java/lang/instrument/package-summary.html)
> 
> A JavaAgent is sometimes called a JPLIS agent, where the acronym JPLIS stands for Java Programming Language Instrumentation Services.
> 
> To report on JavaAgents, JFR will add the new event type jdk.JavaAgent and events will look similar to these two examples:
> 
> // Command line
> jdk.JavaAgent {
>   startTime = 12:31:19.789 (2023-03-08)
>   name = "JavaAgent.jar"
>   options = "foo=bar"
>   dynamic = false
>   initialization = 12:31:15.574 (2023-03-08)
>   initializationTime = 172 ms
> }
> 
> // Dynamic load
> jdk.JavaAgent {
>   startTime = 12:31:31.158 (2023-03-08)
>   name = "JavaAgent.jar"
>   options = "bar=baz"
>   dynamic = true
>   initialization = 12:31:31.037 (2023-03-08)
>   initializationTime = 64,1 ms
> }
> 
> The jdk.JavaAgent event type is a JFR periodic event that iterates over running Java agents.
> 
> For a JavaAgent event, the agent's name will be the specific .jar file containing the instrumentation code. The options will be the specific options passed to the .jar file as part of launching the agent, for example, on the command line: -javaagent: JavaAgent.jar=foo=bar.
> 
> The "dynamic" field denotes if the agent was loaded via the command line (dynamic = false) or dynamically (dynamic = true)
> 
> "initialization" is the timestamp the JVM invoked the initialization method, and "initializationTime" is the duration of executing the initialization method.
> 
> "startTime" represents the time the JFR framework issued the periodic event; hence "initialization" will be earlier than "startTime".
> 
> An agent can also be written in a native programming language using the [JVM Tools Interface (JVMTI)](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html). This kind of agent, sometimes called a native agent, is a platform-specific binary, sometimes referred to as a library, but here it means a .so or .dll file.
> 
> To report on native agents, JFR will add the new event type jdk.NativeAgent and events will look similar to this example:
> 
> jdk.NativeAgent {
>   startTime = 12:31:40.398 (2023-03-08)
>   name = "jdwp"
>   options = "transport=dt_socket,server=y,address=any,onjcmd=y"
>   dynamic = false
>   initialization = 12:31:36.142 (2023-03-08)
>   initializationTime = 0,00184 ms
>   path = "c:\ade\github\openjdk\jdk\build\windows-x86_64-server-slowdebug\jdk\bin\jdwp.dll"
> }
> 
> The layout of the event type is very similar to the jdk.JavaAgent event, but here the path to the native library is reported.
> 
> The initialization of a native agent is performed by invoking an agent-specified callback routine. The "initialization" is when the JVM sent or would have sent the JVMTI VMInit event to a specified callback. "initializationTime" is the duration to execute that specific callback. If no callback is specified for the JVMTI VMInit event, the "initializationTime" will be 0.
> 
> #### Implementation
> 
> There has not existed a reification of a JavaAgent directly in the JVM, as these are built on top of the JDK native library, "instrument", using a many-to-one mapping. At the level of the JVM, the only representation of agents after startup is through JvmtiEnv's, which agents request from the JVM during startup and initialization ? as such, mapping which JvmtiEnv belongs to what JavaAgent was not possible before.
> 
> Using implementation details of how the JDK native library "instrument" interacts with the JVM, we can build this mapping to track what JvmtiEnv's "belong" to what JavaAgent. This mapping now lets us report the Java-relevant context (name, options) and measure the time it takes for the JavaAgent to initialize.
> 
> When implementing this capability, it was necessary to refactor the code used to represent agents, AgentLibrary. The previous implementation was located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp.
> 
> The refactoring isolates the relevant logic into two new modules, prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their older places will help reduce the sizes of oversized arguments.cpp and threads.cpp.
> 
> The previous two lists that maintained "agents" (JVMTI) and "libraries" (Xrun) were not thread-safe for concurrent iterations. A single list that allows for concurrent iterations is therefore introduced.
> 
> Testing: jdk_jfr, tier 1 - 6
> 
> Thanks
> Markus

Markus Gr?nlund 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 branch 'master' into agents
 - reviewer feedback, loading to agent.cpp, bugfix loading statically linked agent
 - more cleanup
 - handle multiple envs with same VMInit callback
 - more cleanup
 - cleanup
 - fixes
 - remove implementation details
 - remove JVMPI
 - cleanup
 - ... and 5 more: https://git.openjdk.org/jdk/compare/83cf28f9...659e6f3d

-------------

Changes: https://git.openjdk.org/jdk/pull/12923/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12923&range=11
  Stats: 1889 lines in 22 files changed: 1368 ins; 490 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/12923.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12923/head:pull/12923

PR: https://git.openjdk.org/jdk/pull/12923

From pchilanomate at openjdk.org  Thu Mar 30 19:03:24 2023
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 30 Mar 2023 19:03:24 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v13]
In-Reply-To: <d7v-k44x3tTGLm1YHfd40bGgoBeaYDu2o_a1Rb7sT08=.607ecff9-d81e-470b-9671-70e1c24a500c@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <d7v-k44x3tTGLm1YHfd40bGgoBeaYDu2o_a1Rb7sT08=.607ecff9-d81e-470b-9671-70e1c24a500c@github.com>
Message-ID: <07UH4ks6EGmxIt5mZ3dNPi0YaC8u-xhBNF-Ao9iOAcA=.378b96b5-19e0-4d0a-95d8-83fd44f39024@github.com>

On Thu, 30 Mar 2023 17:10:16 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The fix is to enable virtual threads support for late binding JVMTI agents.
>> The fix includes:
>> - New function `JvmtiEnvBase::enable_virtual_threads_notify_jvmti()` which does enabling JVMTI VTMS transition notifications in case of agent loaded into running VM. This function executes a VM operation counting VTMS transition bits in all `JavaThread`'s to correctly set the static counter `_VTMS_transition_count` needed for VTMS transition protocol.
>> - New function `JvmtiEnvBase::disable_virtual_threads_notify_jvmti()` which is needed for testing. It is used by the `WhiteBox` API.
>> - New WhiteBox function `WB_SetVirtualThreadsNotifyJvmtiMode(JNIEnv* env, jobject wb, jboolean enable)` needed for testing of this update.
>> - New regression test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
>> 
>> Testing:
>> - New test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
>> - The originally failed tests are expected to pass 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:
> 
>   review: tweak in count_transitions_and_correct_jvmti_thread_states

test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest.java line 129:

> 127:     }
> 128: 
> 129:     static synchronized private void startThreads() {

So making this method synchronized instead of startThread() will make it less likely that we will face the previous issue, but it is still timing dependent, because the call to start the launcher can return before the launcher reaches here. It will be very unlikely given the sleeps but if we want to guard against any surprises we could have a variable set in startThreads() and in finishThreads() we check and wait until that variable is set.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1153676258

From mgronlun at openjdk.org  Thu Mar 30 19:15:23 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 30 Mar 2023 19:15:23 GMT
Subject: RFR: 8257967: JFR: Events for loaded agents [v13]
In-Reply-To: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
References: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
Message-ID: <OpOjIV8LzvKh5DiidcbTKFAPod21htAFI2DlxQaQu68=.2e04012f-f000-4759-8518-4ffa9ce44af5@github.com>

> Greetings,
> 
> We are adding support to let JFR report on Agents.
> 
> #### Design
> 
> An Agent is a library that uses any instrumentation or profiling APIs. Most agents are started and initialized on the command line, but agents can also be loaded dynamically during runtime. Because command line agents initialize during the VM startup sequence, they add to the overall startup time latency in getting the VM ready. The events will report on the time the agent took to initialize.
> 
> A JavaAgent is an agent written in the Java programming language, using the APIs in the package [java.lang.instrument](https://docs.oracle.com/en/java/javase/19/docs/api/java.instrument/java/lang/instrument/package-summary.html)
> 
> A JavaAgent is sometimes called a JPLIS agent, where the acronym JPLIS stands for Java Programming Language Instrumentation Services.
> 
> To report on JavaAgents, JFR will add the new event type jdk.JavaAgent and events will look similar to these two examples:
> 
> // Command line
> jdk.JavaAgent {
>   startTime = 12:31:19.789 (2023-03-08)
>   name = "JavaAgent.jar"
>   options = "foo=bar"
>   dynamic = false
>   initialization = 12:31:15.574 (2023-03-08)
>   initializationTime = 172 ms
> }
> 
> // Dynamic load
> jdk.JavaAgent {
>   startTime = 12:31:31.158 (2023-03-08)
>   name = "JavaAgent.jar"
>   options = "bar=baz"
>   dynamic = true
>   initialization = 12:31:31.037 (2023-03-08)
>   initializationTime = 64,1 ms
> }
> 
> The jdk.JavaAgent event type is a JFR periodic event that iterates over running Java agents.
> 
> For a JavaAgent event, the agent's name will be the specific .jar file containing the instrumentation code. The options will be the specific options passed to the .jar file as part of launching the agent, for example, on the command line: -javaagent: JavaAgent.jar=foo=bar.
> 
> The "dynamic" field denotes if the agent was loaded via the command line (dynamic = false) or dynamically (dynamic = true)
> 
> "initialization" is the timestamp the JVM invoked the initialization method, and "initializationTime" is the duration of executing the initialization method.
> 
> "startTime" represents the time the JFR framework issued the periodic event; hence "initialization" will be earlier than "startTime".
> 
> An agent can also be written in a native programming language using the [JVM Tools Interface (JVMTI)](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html). This kind of agent, sometimes called a native agent, is a platform-specific binary, sometimes referred to as a library, but here it means a .so or .dll file.
> 
> To report on native agents, JFR will add the new event type jdk.NativeAgent and events will look similar to this example:
> 
> jdk.NativeAgent {
>   startTime = 12:31:40.398 (2023-03-08)
>   name = "jdwp"
>   options = "transport=dt_socket,server=y,address=any,onjcmd=y"
>   dynamic = false
>   initialization = 12:31:36.142 (2023-03-08)
>   initializationTime = 0,00184 ms
>   path = "c:\ade\github\openjdk\jdk\build\windows-x86_64-server-slowdebug\jdk\bin\jdwp.dll"
> }
> 
> The layout of the event type is very similar to the jdk.JavaAgent event, but here the path to the native library is reported.
> 
> The initialization of a native agent is performed by invoking an agent-specified callback routine. The "initialization" is when the JVM sent or would have sent the JVMTI VMInit event to a specified callback. "initializationTime" is the duration to execute that specific callback. If no callback is specified for the JVMTI VMInit event, the "initializationTime" will be 0.
> 
> #### Implementation
> 
> There has not existed a reification of a JavaAgent directly in the JVM, as these are built on top of the JDK native library, "instrument", using a many-to-one mapping. At the level of the JVM, the only representation of agents after startup is through JvmtiEnv's, which agents request from the JVM during startup and initialization ? as such, mapping which JvmtiEnv belongs to what JavaAgent was not possible before.
> 
> Using implementation details of how the JDK native library "instrument" interacts with the JVM, we can build this mapping to track what JvmtiEnv's "belong" to what JavaAgent. This mapping now lets us report the Java-relevant context (name, options) and measure the time it takes for the JavaAgent to initialize.
> 
> When implementing this capability, it was necessary to refactor the code used to represent agents, AgentLibrary. The previous implementation was located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp.
> 
> The refactoring isolates the relevant logic into two new modules, prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their older places will help reduce the sizes of oversized arguments.cpp and threads.cpp.
> 
> The previous two lists that maintained "agents" (JVMTI) and "libraries" (Xrun) were not thread-safe for concurrent iterations. A single list that allows for concurrent iterations is therefore introduced.
> 
> Testing: jdk_jfr, tier 1 - 6
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  remove whitespace

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12923/files
  - new: https://git.openjdk.org/jdk/pull/12923/files/659e6f3d..c024fac5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12923&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12923&range=11-12

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12923.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12923/head:pull/12923

PR: https://git.openjdk.org/jdk/pull/12923

From mgronlun at openjdk.org  Thu Mar 30 19:20:11 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 30 Mar 2023 19:20:11 GMT
Subject: RFR: 8257967: JFR: Events for loaded agents [v14]
In-Reply-To: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
References: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
Message-ID: <kooNn-2wsfn3v-nibYXs3B73wolCj3OsqHBur3gjv_8=.3ebc9e98-f40d-4d07-9515-05d30829abdc@github.com>

> Greetings,
> 
> We are adding support to let JFR report on Agents.
> 
> #### Design
> 
> An Agent is a library that uses any instrumentation or profiling APIs. Most agents are started and initialized on the command line, but agents can also be loaded dynamically during runtime. Because command line agents initialize during the VM startup sequence, they add to the overall startup time latency in getting the VM ready. The events will report on the time the agent took to initialize.
> 
> A JavaAgent is an agent written in the Java programming language, using the APIs in the package [java.lang.instrument](https://docs.oracle.com/en/java/javase/19/docs/api/java.instrument/java/lang/instrument/package-summary.html)
> 
> A JavaAgent is sometimes called a JPLIS agent, where the acronym JPLIS stands for Java Programming Language Instrumentation Services.
> 
> To report on JavaAgents, JFR will add the new event type jdk.JavaAgent and events will look similar to these two examples:
> 
> // Command line
> jdk.JavaAgent {
>   startTime = 12:31:19.789 (2023-03-08)
>   name = "JavaAgent.jar"
>   options = "foo=bar"
>   dynamic = false
>   initialization = 12:31:15.574 (2023-03-08)
>   initializationTime = 172 ms
> }
> 
> // Dynamic load
> jdk.JavaAgent {
>   startTime = 12:31:31.158 (2023-03-08)
>   name = "JavaAgent.jar"
>   options = "bar=baz"
>   dynamic = true
>   initialization = 12:31:31.037 (2023-03-08)
>   initializationTime = 64,1 ms
> }
> 
> The jdk.JavaAgent event type is a JFR periodic event that iterates over running Java agents.
> 
> For a JavaAgent event, the agent's name will be the specific .jar file containing the instrumentation code. The options will be the specific options passed to the .jar file as part of launching the agent, for example, on the command line: -javaagent: JavaAgent.jar=foo=bar.
> 
> The "dynamic" field denotes if the agent was loaded via the command line (dynamic = false) or dynamically (dynamic = true)
> 
> "initialization" is the timestamp the JVM invoked the initialization method, and "initializationTime" is the duration of executing the initialization method.
> 
> "startTime" represents the time the JFR framework issued the periodic event; hence "initialization" will be earlier than "startTime".
> 
> An agent can also be written in a native programming language using the [JVM Tools Interface (JVMTI)](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html). This kind of agent, sometimes called a native agent, is a platform-specific binary, sometimes referred to as a library, but here it means a .so or .dll file.
> 
> To report on native agents, JFR will add the new event type jdk.NativeAgent and events will look similar to this example:
> 
> jdk.NativeAgent {
>   startTime = 12:31:40.398 (2023-03-08)
>   name = "jdwp"
>   options = "transport=dt_socket,server=y,address=any,onjcmd=y"
>   dynamic = false
>   initialization = 12:31:36.142 (2023-03-08)
>   initializationTime = 0,00184 ms
>   path = "c:\ade\github\openjdk\jdk\build\windows-x86_64-server-slowdebug\jdk\bin\jdwp.dll"
> }
> 
> The layout of the event type is very similar to the jdk.JavaAgent event, but here the path to the native library is reported.
> 
> The initialization of a native agent is performed by invoking an agent-specified callback routine. The "initialization" is when the JVM sent or would have sent the JVMTI VMInit event to a specified callback. "initializationTime" is the duration to execute that specific callback. If no callback is specified for the JVMTI VMInit event, the "initializationTime" will be 0.
> 
> #### Implementation
> 
> There has not existed a reification of a JavaAgent directly in the JVM, as these are built on top of the JDK native library, "instrument", using a many-to-one mapping. At the level of the JVM, the only representation of agents after startup is through JvmtiEnv's, which agents request from the JVM during startup and initialization ? as such, mapping which JvmtiEnv belongs to what JavaAgent was not possible before.
> 
> Using implementation details of how the JDK native library "instrument" interacts with the JVM, we can build this mapping to track what JvmtiEnv's "belong" to what JavaAgent. This mapping now lets us report the Java-relevant context (name, options) and measure the time it takes for the JavaAgent to initialize.
> 
> When implementing this capability, it was necessary to refactor the code used to represent agents, AgentLibrary. The previous implementation was located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp.
> 
> The refactoring isolates the relevant logic into two new modules, prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their older places will help reduce the sizes of oversized arguments.cpp and threads.cpp.
> 
> The previous two lists that maintained "agents" (JVMTI) and "libraries" (Xrun) were not thread-safe for concurrent iterations. A single list that allows for concurrent iterations is therefore introduced.
> 
> Testing: jdk_jfr, tier 1 - 6
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  restore misssing frees

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12923/files
  - new: https://git.openjdk.org/jdk/pull/12923/files/c024fac5..ab74621b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12923&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12923&range=12-13

  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12923.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12923/head:pull/12923

PR: https://git.openjdk.org/jdk/pull/12923

From duke at openjdk.org  Thu Mar 30 19:20:15 2023
From: duke at openjdk.org (Bernd)
Date: Thu, 30 Mar 2023 19:20:15 GMT
Subject: RFR: 8257967: JFR: Events for loaded agents [v12]
In-Reply-To: <RHxW8J0VDDZ88ljuAmNmb4D4eVj3avUr1Jj3AvqPPIA=.70a33d33-972e-437b-8814-7d251de615f7@github.com>
References: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
 <RHxW8J0VDDZ88ljuAmNmb4D4eVj3avUr1Jj3AvqPPIA=.70a33d33-972e-437b-8814-7d251de615f7@github.com>
Message-ID: <qTky0bokdVkDwzuDIhZg7rXh0fmRP3tFFXl05mz_QD0=.533e9a67-3d17-4582-81c6-71a73c73d8eb@github.com>

On Thu, 30 Mar 2023 18:59:30 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> We are adding support to let JFR report on Agents.
>> 
>> #### Design
>> 
>> An Agent is a library that uses any instrumentation or profiling APIs. Most agents are started and initialized on the command line, but agents can also be loaded dynamically during runtime. Because command line agents initialize during the VM startup sequence, they add to the overall startup time latency in getting the VM ready. The events will report on the time the agent took to initialize.
>> 
>> A JavaAgent is an agent written in the Java programming language, using the APIs in the package [java.lang.instrument](https://docs.oracle.com/en/java/javase/19/docs/api/java.instrument/java/lang/instrument/package-summary.html)
>> 
>> A JavaAgent is sometimes called a JPLIS agent, where the acronym JPLIS stands for Java Programming Language Instrumentation Services.
>> 
>> To report on JavaAgents, JFR will add the new event type jdk.JavaAgent and events will look similar to these two examples:
>> 
>> // Command line
>> jdk.JavaAgent {
>>   startTime = 12:31:19.789 (2023-03-08)
>>   name = "JavaAgent.jar"
>>   options = "foo=bar"
>>   dynamic = false
>>   initialization = 12:31:15.574 (2023-03-08)
>>   initializationTime = 172 ms
>> }
>> 
>> // Dynamic load
>> jdk.JavaAgent {
>>   startTime = 12:31:31.158 (2023-03-08)
>>   name = "JavaAgent.jar"
>>   options = "bar=baz"
>>   dynamic = true
>>   initialization = 12:31:31.037 (2023-03-08)
>>   initializationTime = 64,1 ms
>> }
>> 
>> The jdk.JavaAgent event type is a JFR periodic event that iterates over running Java agents.
>> 
>> For a JavaAgent event, the agent's name will be the specific .jar file containing the instrumentation code. The options will be the specific options passed to the .jar file as part of launching the agent, for example, on the command line: -javaagent: JavaAgent.jar=foo=bar.
>> 
>> The "dynamic" field denotes if the agent was loaded via the command line (dynamic = false) or dynamically (dynamic = true)
>> 
>> "initialization" is the timestamp the JVM invoked the initialization method, and "initializationTime" is the duration of executing the initialization method.
>> 
>> "startTime" represents the time the JFR framework issued the periodic event; hence "initialization" will be earlier than "startTime".
>> 
>> An agent can also be written in a native programming language using the [JVM Tools Interface (JVMTI)](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html). This kind of agent, sometimes called a native agent, is a platform-specific binary, sometimes referred to as a library, but here it means a .so or .dll file.
>> 
>> To report on native agents, JFR will add the new event type jdk.NativeAgent and events will look similar to this example:
>> 
>> jdk.NativeAgent {
>>   startTime = 12:31:40.398 (2023-03-08)
>>   name = "jdwp"
>>   options = "transport=dt_socket,server=y,address=any,onjcmd=y"
>>   dynamic = false
>>   initialization = 12:31:36.142 (2023-03-08)
>>   initializationTime = 0,00184 ms
>>   path = "c:\ade\github\openjdk\jdk\build\windows-x86_64-server-slowdebug\jdk\bin\jdwp.dll"
>> }
>> 
>> The layout of the event type is very similar to the jdk.JavaAgent event, but here the path to the native library is reported.
>> 
>> The initialization of a native agent is performed by invoking an agent-specified callback routine. The "initialization" is when the JVM sent or would have sent the JVMTI VMInit event to a specified callback. "initializationTime" is the duration to execute that specific callback. If no callback is specified for the JVMTI VMInit event, the "initializationTime" will be 0.
>> 
>> #### Implementation
>> 
>> There has not existed a reification of a JavaAgent directly in the JVM, as these are built on top of the JDK native library, "instrument", using a many-to-one mapping. At the level of the JVM, the only representation of agents after startup is through JvmtiEnv's, which agents request from the JVM during startup and initialization ? as such, mapping which JvmtiEnv belongs to what JavaAgent was not possible before.
>> 
>> Using implementation details of how the JDK native library "instrument" interacts with the JVM, we can build this mapping to track what JvmtiEnv's "belong" to what JavaAgent. This mapping now lets us report the Java-relevant context (name, options) and measure the time it takes for the JavaAgent to initialize.
>> 
>> When implementing this capability, it was necessary to refactor the code used to represent agents, AgentLibrary. The previous implementation was located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp.
>> 
>> The refactoring isolates the relevant logic into two new modules, prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their older places will help reduce the sizes of oversized arguments.cpp and threads.cpp.
>> 
>> The previous two lists that maintained "agents" (JVMTI) and "libraries" (Xrun) were not thread-safe for concurrent iterations. A single list that allows for concurrent iterations is therefore introduced.
>> 
>> Testing: jdk_jfr, tier 1 - 6
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund 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 branch 'master' into agents
>  - reviewer feedback, loading to agent.cpp, bugfix loading statically linked agent
>  - more cleanup
>  - handle multiple envs with same VMInit callback
>  - more cleanup
>  - cleanup
>  - fixes
>  - remove implementation details
>  - remove JVMPI
>  - cleanup
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/83cf28f9...659e6f3d

Hm, not sure how helpful the events are, but if you really want them to be informative, how about adding the path of the jar file or maybe the class names?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12923#issuecomment-1490802537

From mgronlun at openjdk.org  Thu Mar 30 19:23:20 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 30 Mar 2023 19:23:20 GMT
Subject: RFR: 8257967: JFR: Events for loaded agents [v14]
In-Reply-To: <kooNn-2wsfn3v-nibYXs3B73wolCj3OsqHBur3gjv_8=.3ebc9e98-f40d-4d07-9515-05d30829abdc@github.com>
References: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
 <kooNn-2wsfn3v-nibYXs3B73wolCj3OsqHBur3gjv_8=.3ebc9e98-f40d-4d07-9515-05d30829abdc@github.com>
Message-ID: <oWQmHqNkvNru6RdZ_shrHatNx-t9atAhZUxiGUY5Q4o=.c01b8b8f-d04f-46c9-80bb-eb5801af26d4@github.com>

On Thu, 30 Mar 2023 19:20:11 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> We are adding support to let JFR report on Agents.
>> 
>> #### Design
>> 
>> An Agent is a library that uses any instrumentation or profiling APIs. Most agents are started and initialized on the command line, but agents can also be loaded dynamically during runtime. Because command line agents initialize during the VM startup sequence, they add to the overall startup time latency in getting the VM ready. The events will report on the time the agent took to initialize.
>> 
>> A JavaAgent is an agent written in the Java programming language, using the APIs in the package [java.lang.instrument](https://docs.oracle.com/en/java/javase/19/docs/api/java.instrument/java/lang/instrument/package-summary.html)
>> 
>> A JavaAgent is sometimes called a JPLIS agent, where the acronym JPLIS stands for Java Programming Language Instrumentation Services.
>> 
>> To report on JavaAgents, JFR will add the new event type jdk.JavaAgent and events will look similar to these two examples:
>> 
>> // Command line
>> jdk.JavaAgent {
>>   startTime = 12:31:19.789 (2023-03-08)
>>   name = "JavaAgent.jar"
>>   options = "foo=bar"
>>   dynamic = false
>>   initialization = 12:31:15.574 (2023-03-08)
>>   initializationTime = 172 ms
>> }
>> 
>> // Dynamic load
>> jdk.JavaAgent {
>>   startTime = 12:31:31.158 (2023-03-08)
>>   name = "JavaAgent.jar"
>>   options = "bar=baz"
>>   dynamic = true
>>   initialization = 12:31:31.037 (2023-03-08)
>>   initializationTime = 64,1 ms
>> }
>> 
>> The jdk.JavaAgent event type is a JFR periodic event that iterates over running Java agents.
>> 
>> For a JavaAgent event, the agent's name will be the specific .jar file containing the instrumentation code. The options will be the specific options passed to the .jar file as part of launching the agent, for example, on the command line: -javaagent: JavaAgent.jar=foo=bar.
>> 
>> The "dynamic" field denotes if the agent was loaded via the command line (dynamic = false) or dynamically (dynamic = true)
>> 
>> "initialization" is the timestamp the JVM invoked the initialization method, and "initializationTime" is the duration of executing the initialization method.
>> 
>> "startTime" represents the time the JFR framework issued the periodic event; hence "initialization" will be earlier than "startTime".
>> 
>> An agent can also be written in a native programming language using the [JVM Tools Interface (JVMTI)](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html). This kind of agent, sometimes called a native agent, is a platform-specific binary, sometimes referred to as a library, but here it means a .so or .dll file.
>> 
>> To report on native agents, JFR will add the new event type jdk.NativeAgent and events will look similar to this example:
>> 
>> jdk.NativeAgent {
>>   startTime = 12:31:40.398 (2023-03-08)
>>   name = "jdwp"
>>   options = "transport=dt_socket,server=y,address=any,onjcmd=y"
>>   dynamic = false
>>   initialization = 12:31:36.142 (2023-03-08)
>>   initializationTime = 0,00184 ms
>>   path = "c:\ade\github\openjdk\jdk\build\windows-x86_64-server-slowdebug\jdk\bin\jdwp.dll"
>> }
>> 
>> The layout of the event type is very similar to the jdk.JavaAgent event, but here the path to the native library is reported.
>> 
>> The initialization of a native agent is performed by invoking an agent-specified callback routine. The "initialization" is when the JVM sent or would have sent the JVMTI VMInit event to a specified callback. "initializationTime" is the duration to execute that specific callback. If no callback is specified for the JVMTI VMInit event, the "initializationTime" will be 0.
>> 
>> #### Implementation
>> 
>> There has not existed a reification of a JavaAgent directly in the JVM, as these are built on top of the JDK native library, "instrument", using a many-to-one mapping. At the level of the JVM, the only representation of agents after startup is through JvmtiEnv's, which agents request from the JVM during startup and initialization ? as such, mapping which JvmtiEnv belongs to what JavaAgent was not possible before.
>> 
>> Using implementation details of how the JDK native library "instrument" interacts with the JVM, we can build this mapping to track what JvmtiEnv's "belong" to what JavaAgent. This mapping now lets us report the Java-relevant context (name, options) and measure the time it takes for the JavaAgent to initialize.
>> 
>> When implementing this capability, it was necessary to refactor the code used to represent agents, AgentLibrary. The previous implementation was located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp.
>> 
>> The refactoring isolates the relevant logic into two new modules, prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their older places will help reduce the sizes of oversized arguments.cpp and threads.cpp.
>> 
>> The previous two lists that maintained "agents" (JVMTI) and "libraries" (Xrun) were not thread-safe for concurrent iterations. A single list that allows for concurrent iterations is therefore introduced.
>> 
>> Testing: jdk_jfr, tier 1 - 6
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore misssing frees

> Hm, not sure how helpful the events are, but if you want them to be informative, how about adding the path of the jar file or maybe the class names?

It has been considered. The full path of the Java .jar might not be that interesting, and it adds much more complexity to resolve it, as most are relative to the classpath. ClassName will be whatever class exports the prremain or agentmain.

We discussed this internally and decided that if there is an actual demand for it, we can add a "path" field to the JavaAgent event type.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12923#issuecomment-1490811900

From mgronlun at openjdk.org  Thu Mar 30 19:34:22 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 30 Mar 2023 19:34:22 GMT
Subject: RFR: 8257967: JFR: Events for loaded agents [v10]
In-Reply-To: <iEqkEPSOYqIpc0uneK7i3LiKMP2WY_joe2Que3feIeM=.82be29bb-cfc7-4573-be7e-a363b7bf5989@github.com>
References: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
 <ZsaBMVK-eeLfmxgg15qPJHm6C-ed5PyIE4lGr-Gnr2s=.2f4044c4-e7ed-48f3-8877-feeb2753be18@github.com>
 <sKa6RRVpBw1kQ0DoQHMclspRNTBJZlKicmXBOUSWDBk=.0b538fa3-7db0-4863-a2aa-b3cd0f692959@github.com>
 <iEqkEPSOYqIpc0uneK7i3LiKMP2WY_joe2Que3feIeM=.82be29bb-cfc7-4573-be7e-a363b7bf5989@github.com>
Message-ID: <bfOu-0uJbnbXKh-Kek_Qb8C-lYlM-yBcdAgcJAPaqVU=.99a29dce-8f36-459f-968f-1a5384de5d90@github.com>

On Tue, 14 Mar 2023 12:26:16 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> I've had a good look through now and have a better sense of the refactoring. Seems good.
> 
> I'll wait for any tweaks before hitting the approve button though.
> 
> Thanks

Moving the loading logic to the agent.cpp module was a bit harder than I initially thought. It also exposed a bug in how statically linked libraries were loaded - now fixed. Sorry for the large update. Thanks again for having a look.

>> src/hotspot/share/prims/agentList.cpp line 542:
>> 
>>> 540: 
>>> 541:   // Invoke the Agent_OnAttach function
>>> 542:   JavaThread* THREAD = JavaThread::current(); // For exception macros.
>> 
>> Nit: just use `current` rather than `THREAD` and don't use the exception macros.
>
> Ported as is but good point, will update.

Updated - cheers.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12923#issuecomment-1490828465
PR Review Comment: https://git.openjdk.org/jdk/pull/12923#discussion_r1153703484

From mgronlun at openjdk.org  Thu Mar 30 19:34:26 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 30 Mar 2023 19:34:26 GMT
Subject: RFR: 8257967: JFR: Events for loaded agents [v9]
In-Reply-To: <HVkwIXbQOjjIYSXadLiOFrkLaG5OgUG5MONfK4c0pvE=.cf4b0311-56cb-4b62-9c70-cadbfa725da1@github.com>
References: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
 <HgrCtIIibi1v0BdGh1myrOFfq1z8CrlDf2aFHFzP_mo=.fd09126d-2bcf-4e7f-8d9f-3933ed676566@github.com>
 <qafwYGs-uxNmucUXY-qWxhxwNpNBAb3N95hATo1HOLw=.15a10a71-d029-4c50-a249-dcb6a18b6902@github.com>
 <HVkwIXbQOjjIYSXadLiOFrkLaG5OgUG5MONfK4c0pvE=.cf4b0311-56cb-4b62-9c70-cadbfa725da1@github.com>
Message-ID: <Qvkzw4QEQSTU7MASp2SshYTHAOkXnL9VpFC-9CmxcNY=.de9d2ca3-1a4b-4274-9ce9-3cf8ae3db8b3@github.com>

On Tue, 14 Mar 2023 12:19:50 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> src/hotspot/share/prims/agent.cpp line 41:
>> 
>>> 39:   char* copy = AllocateHeap(length + 1, mtInternal);
>>> 40:   strncpy(copy, str, length + 1);
>>> 41:   assert(strncmp(copy, str, length + 1) == 0, "invariant");
>> 
>> Unclear what you are checking here. Don't you trust strncpy?
>
> Maybe a bit paranoid, yes. I can clean up.

updated to use os:::strdup - cheers.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12923#discussion_r1153702643

From mgronlun at openjdk.org  Thu Mar 30 19:34:27 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 30 Mar 2023 19:34:27 GMT
Subject: RFR: 8257967: JFR: Events for loaded agents [v10]
In-Reply-To: <-OvxuwPKbYU514MyCXdcC5-0Nt1ftlipuUFueCe3DGc=.3b0140b3-ef41-4ad6-9515-ec6e9ef40250@github.com>
References: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
 <ZsaBMVK-eeLfmxgg15qPJHm6C-ed5PyIE4lGr-Gnr2s=.2f4044c4-e7ed-48f3-8877-feeb2753be18@github.com>
 <M86HnsWFDyZ0UNtNsefyHOG-wSDPBIkETS76BtkhCBc=.c65616e6-b644-4db9-b64b-d1319a87b915@github.com>
 <Zwh7j7Mek5EyfIJBgNYom2kZy71QLxSHyI5BmHe1gqY=.0b9da360-0979-4394-ae9c-adac9cadbfee@github.com>
 <-OvxuwPKbYU514MyCXdcC5-0Nt1ftlipuUFueCe3DGc=.3b0140b3-ef41-4ad6-9515-ec6e9ef40250@github.com>
Message-ID: <HvP2sjkkLOJlBGtkF7YMd6pjrWYJRF4BxBo5wLTDLaQ=.f7576123-c948-4586-be31-dde3fe0e94bf@github.com>

On Tue, 14 Mar 2023 12:22:16 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> n.b. that also applies for accesses/updates to field _next.
>
> I wanted all accesses to use the iterator. The only access is given to the iterator and AgentList by way of being friends. No need to expose more.

I updated all external access to use getters/setters.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12923#discussion_r1153703241

From alanb at openjdk.org  Thu Mar 30 19:53:19 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 30 Mar 2023 19:53:19 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v4]
In-Reply-To: <60eMtJqr0OixK0Yv1WCgN-dvX8nkDVZ0suA6GfwN8tQ=.02972477-1bf0-41a6-a243-bea51d6c7413@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <GOOPg0-P0Vc1ocNUzWRIbItENekN1ralramscyuF1kQ=.44aded10-e14f-4378-9173-a8126d21da04@github.com>
 <60eMtJqr0OixK0Yv1WCgN-dvX8nkDVZ0suA6GfwN8tQ=.02972477-1bf0-41a6-a243-bea51d6c7413@github.com>
Message-ID: <ubtxEOy9xlJltKed2zKvaSbaHmHjQh9pALi4q_lRx5c=.fe4f5b42-ddac-4e92-96f9-6f798a843fdc@github.com>

On Thu, 30 Mar 2023 15:29:43 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This becomes obsolete:
> `src/hotspot/share/prims/jvmtiTagMap.cpp: // disabled if vritual threads are enabled with --enable-preview`

A left-over from JDK-8285739, thanks, we can remove that comment.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13203#issuecomment-1490855154

From alanb at openjdk.org  Thu Mar 30 19:58:24 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 30 Mar 2023 19:58:24 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v4]
In-Reply-To: <VDNjN3puvhREiu0NRGipzN_vX9aCfdPIW-YcIx2pr5o=.2a28f04e-d9d6-4bd3-a9f0-9ab2e25a1013@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
 <GOOPg0-P0Vc1ocNUzWRIbItENekN1ralramscyuF1kQ=.44aded10-e14f-4378-9173-a8126d21da04@github.com>
 <VDNjN3puvhREiu0NRGipzN_vX9aCfdPIW-YcIx2pr5o=.2a28f04e-d9d6-4bd3-a9f0-9ab2e25a1013@github.com>
Message-ID: <1VSMgL-O6sBz4fZGONbHPF_lHILBy8R4bsRrJ0Rgtdg=.d0a651d9-03d1-4e71-9d4f-8778c26f86b1@github.com>

On Wed, 29 Mar 2023 21:43:38 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix ThreadSleepEvent again
>
> src/java.base/share/classes/java/lang/Thread.java line 1546:
> 
>> 1544:             // bind thread to container
>> 1545:             if (this.container != null)
>> 1546:                 throw new IllegalThreadStateException();
> 
> This check is not replicated in `VirtualThread::start`, i think the CAS protects against that. Maybe assert instead in the virtual thread implementation, thereby the comment in `setThreadContainer` can be changed to something like "`this.container` checked/asserted to be != null before call to Virtual/Thread::start(ThreadContainer)" ?

Yes, they are different. If adding platform thread to a container fails with OOME then it does so when its threadStatus is 0. This check just previous another attempt to start it. Virtual threads work differently but I can add an assert to make this clearer.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1153726790

From dcubed at openjdk.org  Thu Mar 30 19:59:54 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 30 Mar 2023 19:59:54 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v45]
In-Reply-To: <QpPPV__KrLy61jRxC5Ye_kPEcwN7vOVw7ZP10BrtsfA=.514ada34-872e-4378-a013-25cafb5dac63@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <QpPPV__KrLy61jRxC5Ye_kPEcwN7vOVw7ZP10BrtsfA=.514ada34-872e-4378-a013-25cafb5dac63@github.com>
Message-ID: <VRZmPzjn6CbU-zIwpF8NproDfgWwzhwKcEdd0CMXBkg=.3db348ea-72f6-4cfa-98eb-f22b2415b6e3@github.com>

On Thu, 30 Mar 2023 16:07:17 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Allow old monitorenter entry point when using heavy monitors

The project is now baselined on jdk-21+17-1334.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1490861748

From dcubed at openjdk.org  Thu Mar 30 20:06:54 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 30 Mar 2023 20:06:54 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v45]
In-Reply-To: <QpPPV__KrLy61jRxC5Ye_kPEcwN7vOVw7ZP10BrtsfA=.514ada34-872e-4378-a013-25cafb5dac63@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <QpPPV__KrLy61jRxC5Ye_kPEcwN7vOVw7ZP10BrtsfA=.514ada34-872e-4378-a013-25cafb5dac63@github.com>
Message-ID: <jVILtkl2JZiw9iCJQqEMongMjLaGPInIQhS4wTyHJ-o=.73903d76-ea66-49ec-a2fb-aaef0038dc83@github.com>

On Thu, 30 Mar 2023 16:07:17 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Allow old monitorenter entry point when using heavy monitors

I tried to build the latest again on my MBP13 and 'release' now fails to build in a
different way:


In file included from /System/Volumes/Data/work/shared/bug_hunt/8291555_for_jdk21.git/open/src/hotspot/cpu/x86/assembler_x86.cpp:33:
/System/Volumes/Data/work/shared/bug_hunt/8291555_for_jdk21.git/open/src/hotspot/share/runtime/objectMonitor.hpp:161:26: error: constexpr function never produces a constant expression [-Winvalid-constexpr]
  static constexpr void* anon_owner_ptr() { return reinterpret_cast<void*>(ANONYMOUS_OWNER); }
                         ^
/System/Volumes/Data/work/shared/bug_hunt/8291555_for_jdk21.git/open/src/hotspot/share/runtime/objectMonitor.hpp:161:52: note: reinterpret_cast is not allowed in a constant expression
  static constexpr void* anon_owner_ptr() { return reinterpret_cast<void*>(ANONYMOUS_OWNER); }
                                                   ^
1 error generated.


It looks like GHA is also unhappy. I'll hold off with doing anything with v44 for now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1490876294

From rkennke at openjdk.org  Thu Mar 30 20:27:55 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 30 Mar 2023 20:27:55 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v46]
In-Reply-To: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
Message-ID: <1d7cQrxIUiC86oRLdiq9O2XoZaVUJXK7FCD3MOv9lnQ=.7ed982a6-ece6-407a-9bb0-c5af50f468ee@github.com>

> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
> 
> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p
 rotocols.
> 
> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare.
> 
> 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
> 
> 
> Testing:
>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
> 
> ### Performance
> 
> #### Simple Microbenchmark
> 
> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
> 
> |  | x86_64 | aarch64 |
> | -- | -- | -- |
> | -UseFastLocking | 20.651 | 20.764 |
> | +UseFastLocking | 18.896 | 18.908 |
> 
> 
> #### Renaissance
> 
> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
> -- | -- | -- | -- | -- | -- | -- | --
> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%

Roman Kennke 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/10907/files
  - new: https://git.openjdk.org/jdk/pull/10907/files/6514f831..eaf2286f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=45
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=44-45

  Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10907.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10907/head:pull/10907

PR: https://git.openjdk.org/jdk/pull/10907

From sspitsyn at openjdk.org  Thu Mar 30 21:51:21 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 30 Mar 2023 21:51:21 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v13]
In-Reply-To: <07UH4ks6EGmxIt5mZ3dNPi0YaC8u-xhBNF-Ao9iOAcA=.378b96b5-19e0-4d0a-95d8-83fd44f39024@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <d7v-k44x3tTGLm1YHfd40bGgoBeaYDu2o_a1Rb7sT08=.607ecff9-d81e-470b-9671-70e1c24a500c@github.com>
 <07UH4ks6EGmxIt5mZ3dNPi0YaC8u-xhBNF-Ao9iOAcA=.378b96b5-19e0-4d0a-95d8-83fd44f39024@github.com>
Message-ID: <JCDrnSm9lzp97A1W6Lpws6AMYVsYy38xVAMIs9P7PSg=.b311d738-a317-4ade-a00c-395c2c223a51@github.com>

On Thu, 30 Mar 2023 19:00:03 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:
>> 
>>   review: tweak in count_transitions_and_correct_jvmti_thread_states
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest.java line 129:
> 
>> 127:     }
>> 128: 
>> 129:     static synchronized private void startThreads() {
> 
> So making this method synchronized instead of startThread() will make it less likely that we will face the previous issue, but it is still timing dependent, because the call to start the launcher can return before the launcher reaches here. It will be very unlikely given the sleeps but if we want to guard against any surprises we could have a variable set in startThreads() and in finishThreads() we check and wait until that variable is set.

Thank you for the concern.
The `startThread()` below which is called from `startThreads()` has the call to `thread.ensureReady()` which waits until the target tested thread really starts and sets the `threadReady` field. So, there is no race condition as the `startThreads()` and `finishThreads()` are synchronized methods.


    static private void startThread(int i) {
        String name = "TestedThread" + i;
        TestedThread thread = new TestedThread(name);
        vts[i] = Thread.ofVirtual().name(name).start(thread);
        thread.ensureReady();
        threads[i] = thread;
        log("# Java: started vthread: " + name);
    }

    static synchronized private void startThreads() {
        log("\n# Java: Starting vthreads");
        for (int i = 0; i < VTHREADS_CNT; i++) {
            sleep(1);
            startThread(i);
        }
    }

    static private synchronized void finishThreads() {
        try {
            for (int i = 0; i < VTHREADS_CNT; i++) {
                TestedThread thread = threads[i];
                thread.letFinish();
                vts[i].join();
            }
        } catch (InterruptedException e) {
            throw new RuntimeException(e);
        }
    }

Please, let me know if I'm missing anything.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1153820099

From dcubed at openjdk.org  Thu Mar 30 22:03:52 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 30 Mar 2023 22:03:52 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v46]
In-Reply-To: <1d7cQrxIUiC86oRLdiq9O2XoZaVUJXK7FCD3MOv9lnQ=.7ed982a6-ece6-407a-9bb0-c5af50f468ee@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <1d7cQrxIUiC86oRLdiq9O2XoZaVUJXK7FCD3MOv9lnQ=.7ed982a6-ece6-407a-9bb0-c5af50f468ee@github.com>
Message-ID: <xQeuOYw1ARXnYmBmBclW0mVqHL-s-yKyg0n8yC9vt-U=.0e5f5ee0-6a27-40da-a035-ebd05f87b09a@github.com>

On Thu, 30 Mar 2023 20:27:55 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix release build

I'm able to build release, fastdebug and slowdebug on my MBP13 with v45.
I submitted v45 to Mach5 and the windows-x64 build is failing:


[2023-03-30T21:53:52,394Z] c:\sb\prod\1680212926\workspace\open\src\hotspot\share\runtime/lockStack.inline.hpp(37): error C2220: the following warning is treated as an error
[2023-03-30T21:53:52,395Z] c:\sb\prod\1680212926\workspace\open\src\hotspot\share\runtime/lockStack.inline.hpp(37): warning C4267: 'return': conversion from 'size_t' to 'int', possible loss of data
[2023-03-30T21:53:52,397Z] lib/CompileJvm.gmk:145: recipe for target '/cygdrive/c/sb/prod/1680212926/workspace/build/windows-x64/hotspot/variant-server/libjvm/objs/deoptimization.obj' failed
[2023-03-30T21:53:52,397Z] make[3]: *** [/cygdrive/c/sb/prod/1680212926/workspace/build/windows-x64/hotspot/variant-server/libjvm/objs/deoptimization.obj] Error 1

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1491019033

From cjplummer at openjdk.org  Thu Mar 30 22:11:25 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 30 Mar 2023 22:11:25 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v5]
In-Reply-To: <wARLtBLaMIWaHC-J_AcQNEO6YW5RbI1tNzeOppxPtfU=.3ba7d410-7816-4e28-8ce6-387b64d11556@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <27JLa60WeywSMcJj-6KfaQD8RBnwBbAvcc0gecc-3h4=.a2a25b70-9e90-4551-af90-35aed3d57b59@github.com>
 <qVfNBfPP6pizIr16-aXD851jbQ8ZNOV7BvH_Yt-jrbo=.d22c7807-c952-4337-ae69-60a8070ad852@github.com>
 <wARLtBLaMIWaHC-J_AcQNEO6YW5RbI1tNzeOppxPtfU=.3ba7d410-7816-4e28-8ce6-387b64d11556@github.com>
Message-ID: <OtG91tFJJf1ed6xwPxONNBoh438L1i0hc8175sKcdnU=.664f1904-4ebf-4708-bdb2-c6682bb0e70e@github.com>

On Thu, 30 Mar 2023 17:11:33 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest.java line 157:
>> 
>>> 155: 
>>> 156:         if (args.length > 0 && args[0].equals("attach")) { // agent loaded into running VM case
>>> 157:             String arg = args.length == 2 ? args[1] : "";
>> 
>> I don't see any args being passed in other than "attach"? What might `arg` be set to?
>
> Only "attach" can be passed in args.

So if args[0] is "attach", then arg will always be set to "attach",  which means it could be passed in as a literal to loadAgentLibrary() below. But even that doesn't seem to be necessary since the agent doesn't seem to look at the args passed in.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1153836810

From cjplummer at openjdk.org  Thu Mar 30 22:20:23 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 30 Mar 2023 22:20:23 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v13]
In-Reply-To: <d7v-k44x3tTGLm1YHfd40bGgoBeaYDu2o_a1Rb7sT08=.607ecff9-d81e-470b-9671-70e1c24a500c@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <d7v-k44x3tTGLm1YHfd40bGgoBeaYDu2o_a1Rb7sT08=.607ecff9-d81e-470b-9671-70e1c24a500c@github.com>
Message-ID: <G4t2-jd_ff94Jv7iQ4Jd7v41KKPFa_ijP1Hc-p3nE14=.7c39733e-064d-438e-8844-8cb523267f3c@github.com>

On Thu, 30 Mar 2023 17:10:16 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The fix is to enable virtual threads support for late binding JVMTI agents.
>> The fix includes:
>> - New function `JvmtiEnvBase::enable_virtual_threads_notify_jvmti()` which does enabling JVMTI VTMS transition notifications in case of agent loaded into running VM. This function executes a VM operation counting VTMS transition bits in all `JavaThread`'s to correctly set the static counter `_VTMS_transition_count` needed for VTMS transition protocol.
>> - New function `JvmtiEnvBase::disable_virtual_threads_notify_jvmti()` which is needed for testing. It is used by the `WhiteBox` API.
>> - New WhiteBox function `WB_SetVirtualThreadsNotifyJvmtiMode(JNIEnv* env, jobject wb, jboolean enable)` needed for testing of this update.
>> - New regression test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
>> 
>> Testing:
>> - New test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
>> - The originally failed tests are expected to pass 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:
> 
>   review: tweak in count_transitions_and_correct_jvmti_thread_states

test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest.java line 90:

> 88:  *  - disable notifyJvmti events mode
> 89:  *  - start the platform launcher thread which starts N of virtual thread
> 90:  *  - enable notifyJvmti events mode after about hapf of virtual thread started

Suggestion:

 *  - enable notifyJvmti events mode after about half of the virtual threads have started

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1153843284

From cjplummer at openjdk.org  Thu Mar 30 22:34:28 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 30 Mar 2023 22:34:28 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v13]
In-Reply-To: <d7v-k44x3tTGLm1YHfd40bGgoBeaYDu2o_a1Rb7sT08=.607ecff9-d81e-470b-9671-70e1c24a500c@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <d7v-k44x3tTGLm1YHfd40bGgoBeaYDu2o_a1Rb7sT08=.607ecff9-d81e-470b-9671-70e1c24a500c@github.com>
Message-ID: <bblJkwdclwKPgCvQb93hL-8xXiC1v00yhk01imHfHpA=.3c0f87b9-68b9-435c-8cdc-5b6aa64fd960@github.com>

On Thu, 30 Mar 2023 17:10:16 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The fix is to enable virtual threads support for late binding JVMTI agents.
>> The fix includes:
>> - New function `JvmtiEnvBase::enable_virtual_threads_notify_jvmti()` which does enabling JVMTI VTMS transition notifications in case of agent loaded into running VM. This function executes a VM operation counting VTMS transition bits in all `JavaThread`'s to correctly set the static counter `_VTMS_transition_count` needed for VTMS transition protocol.
>> - New function `JvmtiEnvBase::disable_virtual_threads_notify_jvmti()` which is needed for testing. It is used by the `WhiteBox` API.
>> - New WhiteBox function `WB_SetVirtualThreadsNotifyJvmtiMode(JNIEnv* env, jobject wb, jboolean enable)` needed for testing of this update.
>> - New regression test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
>> 
>> Testing:
>> - New test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
>> - The originally failed tests are expected to pass 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:
> 
>   review: tweak in count_transitions_and_correct_jvmti_thread_states

test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest.java line 45:

> 43: // to have sleep() calls to provide yielding as some frequency of virtual
> 44: // thread mount state transitions is needed for this test scenario.
> 45: class TestedThread extends Thread {

Shouldn't this be a Runnable instead of a Thread? I would also suggest not using  the term "thread" here. Maybe "task"? Otherwise code like the following is misleading:


                TestedThread thread = threads[i];
                thread.letFinish();

There are no threads being referenced in this code, yet the term "thread" is used 4 times.

test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest.java line 170:

> 168:         // Disable notifyJvmti events mode at test cycle start.
> 169:         // It is unsafe to do so if any virtual threads are executed.
> 170:         setVirtualThreadsNotifyJvmtiMode(iter, false);

What happens if the main thread is a virtual thread because the virtual thread wrapper is being used? Is there any concern with disabling notifications in this case?

test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest.java line 172:

> 170:         setVirtualThreadsNotifyJvmtiMode(iter, false);
> 171: 
> 172:         Thread tt = Thread.ofPlatform().name("StartThreadsTest").start(ToggleNotifyJvmtiTest::startThreads);

Why does each test  cycle need to be run in a separate platform thread? Can't you just use the main test thread?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1153845337
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1153850702
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1153849125

From pchilanomate at openjdk.org  Thu Mar 30 23:14:24 2023
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 30 Mar 2023 23:14:24 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v13]
In-Reply-To: <JCDrnSm9lzp97A1W6Lpws6AMYVsYy38xVAMIs9P7PSg=.b311d738-a317-4ade-a00c-395c2c223a51@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <d7v-k44x3tTGLm1YHfd40bGgoBeaYDu2o_a1Rb7sT08=.607ecff9-d81e-470b-9671-70e1c24a500c@github.com>
 <07UH4ks6EGmxIt5mZ3dNPi0YaC8u-xhBNF-Ao9iOAcA=.378b96b5-19e0-4d0a-95d8-83fd44f39024@github.com>
 <JCDrnSm9lzp97A1W6Lpws6AMYVsYy38xVAMIs9P7PSg=.b311d738-a317-4ade-a00c-395c2c223a51@github.com>
Message-ID: <PjeXeo8_ptMN7DzyRGoQtW8dX1uaRLbGmeMm0AlKhu4=.e7767e91-3c01-4663-bdfc-8fe5517c8764@github.com>

On Thu, 30 Mar 2023 21:48:22 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest.java line 129:
>> 
>>> 127:     }
>>> 128: 
>>> 129:     static synchronized private void startThreads() {
>> 
>> So making this method synchronized instead of startThread() will make it less likely that we will face the previous issue, but it is still timing dependent, because the call to start the launcher can return before the launcher reaches here. It will be very unlikely given the sleeps but if we want to guard against any surprises we could have a variable set in startThreads() and in finishThreads() we check and wait until that variable is set.
>
> Thank you for the concern.
> The `startThread()` below which is called from `startThreads()` has the call to `thread.ensureReady()` which waits until the target tested thread really starts and sets the `threadReady` field. So, there is no race condition as the `startThreads()` and `finishThreads()` are synchronized methods.
> 
> 
>     static private void startThread(int i) {
>         String name = "TestedThread" + i;
>         TestedThread thread = new TestedThread(name);
>         vts[i] = Thread.ofVirtual().name(name).start(thread);
>         thread.ensureReady();
>         threads[i] = thread;
>         log("# Java: started vthread: " + name);
>     }
> 
>     static synchronized private void startThreads() {
>         log("\n# Java: Starting vthreads");
>         for (int i = 0; i < VTHREADS_CNT; i++) {
>             sleep(1);
>             startThread(i);
>         }
>     }
> 
>     static private synchronized void finishThreads() {
>         try {
>             for (int i = 0; i < VTHREADS_CNT; i++) {
>                 TestedThread thread = threads[i];
>                 thread.letFinish();
>                 vts[i].join();
>             }
>         } catch (InterruptedException e) {
>             throw new RuntimeException(e);
>         }
>     }
> 
> Please, let me know if I'm missing anything.

So the race I am talking about is between the main thread running finishThreads() and the launcher thread running startThreads(). The main thread could execute finishThreads() before the launcher executes startThreads(). If you comment out the two first sleeps in run_test_cycle() you can actually see the issue. Again, given that the sleeps are there it is an unlikely scheduling, but if we want to avoid depending on timing we can add that extra synchronization.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1153872917

From cslucas at openjdk.org  Thu Mar 30 23:36:20 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Thu, 30 Mar 2023 23:36:20 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v5]
In-Reply-To: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
Message-ID: <BkFhS_H--jWSoKWjzV794-R7c3Y4Vz5syDHg9Izenf8=.2f415d57-14a2-437e-af45-064f6de461d3@github.com>

> Can I please get reviews for this PR? 
> 
> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested.
> 
> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N:
> 
> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png)
> 
> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1:
> 
> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png)
> 
> This PR adds support scalar replacing allocations participating in merges that are used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently.
> 
> The approach I used for _rematerialization_ is pretty straightforward. It consists basically in: 1) Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a new Class to support rematerialization of SR objects part of merges; 3) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 4) Patch C2 to generate unique types for SR objects participating in some allocation merges.
> 
> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straight forward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless.
> 
> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also tested with several applications and didn't see any failure. I also ran tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures.

Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:

  Address PR feeedback 1: make ObjectMergeValue subclass of ObjectValue & create new IR class to represent scalarized merges.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12897/files
  - new: https://git.openjdk.org/jdk/pull/12897/files/a158ae66..5ef86371

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=03-04

  Stats: 552 lines in 18 files changed: 181 ins; 169 del; 202 mod
  Patch: https://git.openjdk.org/jdk/pull/12897.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12897/head:pull/12897

PR: https://git.openjdk.org/jdk/pull/12897

From psandoz at openjdk.org  Fri Mar 31 00:01:22 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 31 Mar 2023 00:01:22 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v5]
In-Reply-To: <oiRTNlsfJ4A5EbcwbqaFSv9DpYutUZv2rLfrOS0ti60=.1d3d4123-b04c-4e24-85cf-3ba8eb5933c8@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
 <oiRTNlsfJ4A5EbcwbqaFSv9DpYutUZv2rLfrOS0ti60=.1d3d4123-b04c-4e24-85cf-3ba8eb5933c8@github.com>
Message-ID: <f8HS136edhltcl6lELe3lfp8FGt7aw_0ugbfbEUFdYw=.d25240be-bb7e-4823-b617-75d035d20945@github.com>

On Thu, 30 Mar 2023 14:30:17 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, VectorShuffle is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
>> 
>> 1. Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
>> 2. Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
>> 3. Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
>> 4. Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
>> 
>> Upon these changes, a `rearrange` can emit more efficient code:
>> 
>>     var species = IntVector.SPECIES_128;
>>     var v1 = IntVector.fromArray(species, SRC1, 0);
>>     var v2 = IntVector.fromArray(species, SRC2, 0);
>>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
>> 
>>     Before:
>>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>>     vmovdqu 0x10(%r10),%xmm0
>>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>>                                                             ;   {external_word}
>>     vpackusdw %xmm0,%xmm0,%xmm0
>>     vpackuswb %xmm0,%xmm0,%xmm0
>>     vpmovsxbd %xmm0,%xmm3
>>     vpcmpgtd %xmm3,%xmm1,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fc2acb4e0d8
>>     vpmovzxbd %xmm0,%xmm0
>>     vpermd %ymm2,%ymm0,%ymm0
>>     movabs $0x751588f98,%r10            ;   {oop([I{0x0000000751588f98})}
>>     vmovdqu %xmm0,0x10(%r10)
>> 
>>     After:
>>     movabs $0x751589c78,%r10            ;   {oop([I{0x0000000751589c78})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158ac88,%r10            ;   {oop([I{0x000000075158ac88})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     vpxor  %xmm0,%xmm0,%xmm0
>>     vpcmpgtd %xmm2,%xmm0,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fa818b27cb1
>>     vpermd %ymm1,%ymm2,%ymm0
>>     movabs $0x751588c68,%r10            ;   {oop([I{0x0000000751588c68})}
>>     vmovdqu %xmm0,0x10(%r10)
>>     
>> Please take a look and leave reviews. Thanks a lot.
>
> 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 14 commits:
> 
>  - move implementations up
>  - Merge branch 'master' into shufflerefactor
>  - Merge branch 'master' into shufflerefactor
>  - reviews
>  - missing casts
>  - clean up
>  - fix Matcher::vector_needs_load_shuffle
>  - fix internal types, clean up
>  - optimise laneIsValid
>  - Merge branch 'master' into shufflerefactor
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/d063b896...a4835c00

src/hotspot/cpu/x86/x86.ad line 2174:

> 2172: }
> 2173: 
> 2174: // Do Vector::rearrange needs preparation of the shuffle argument

Suggestion:

// Returns true if Vector::rearrange needs preparation of the shuffle argument

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1153894269

From psandoz at openjdk.org  Fri Mar 31 00:10:29 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 31 Mar 2023 00:10:29 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v5]
In-Reply-To: <oiRTNlsfJ4A5EbcwbqaFSv9DpYutUZv2rLfrOS0ti60=.1d3d4123-b04c-4e24-85cf-3ba8eb5933c8@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
 <oiRTNlsfJ4A5EbcwbqaFSv9DpYutUZv2rLfrOS0ti60=.1d3d4123-b04c-4e24-85cf-3ba8eb5933c8@github.com>
Message-ID: <MzBBEhRfWnyLaEeyZWHRceKKzt21XZdwk-k_KzzzPD8=.bfd38d4a-9d21-4453-a543-a7cef1579d98@github.com>

On Thu, 30 Mar 2023 14:30:17 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, VectorShuffle is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
>> 
>> 1. Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
>> 2. Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
>> 3. Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
>> 4. Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
>> 
>> Upon these changes, a `rearrange` can emit more efficient code:
>> 
>>     var species = IntVector.SPECIES_128;
>>     var v1 = IntVector.fromArray(species, SRC1, 0);
>>     var v2 = IntVector.fromArray(species, SRC2, 0);
>>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
>> 
>>     Before:
>>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>>     vmovdqu 0x10(%r10),%xmm0
>>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>>                                                             ;   {external_word}
>>     vpackusdw %xmm0,%xmm0,%xmm0
>>     vpackuswb %xmm0,%xmm0,%xmm0
>>     vpmovsxbd %xmm0,%xmm3
>>     vpcmpgtd %xmm3,%xmm1,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fc2acb4e0d8
>>     vpmovzxbd %xmm0,%xmm0
>>     vpermd %ymm2,%ymm0,%ymm0
>>     movabs $0x751588f98,%r10            ;   {oop([I{0x0000000751588f98})}
>>     vmovdqu %xmm0,0x10(%r10)
>> 
>>     After:
>>     movabs $0x751589c78,%r10            ;   {oop([I{0x0000000751589c78})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158ac88,%r10            ;   {oop([I{0x000000075158ac88})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     vpxor  %xmm0,%xmm0,%xmm0
>>     vpcmpgtd %xmm2,%xmm0,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fa818b27cb1
>>     vpermd %ymm1,%ymm2,%ymm0
>>     movabs $0x751588c68,%r10            ;   {oop([I{0x0000000751588c68})}
>>     vmovdqu %xmm0,0x10(%r10)
>>     
>> Please take a look and leave reviews. Thanks a lot.
>
> 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 14 commits:
> 
>  - move implementations up
>  - Merge branch 'master' into shufflerefactor
>  - Merge branch 'master' into shufflerefactor
>  - reviews
>  - missing casts
>  - clean up
>  - fix Matcher::vector_needs_load_shuffle
>  - fix internal types, clean up
>  - optimise laneIsValid
>  - Merge branch 'master' into shufflerefactor
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/d063b896...a4835c00

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractVector.java line 204:

> 202:                                      dvtype, dtype, dlength,
> 203:                                   this, dsp,
> 204:                                      AbstractVector::toShuffle0);

Suggestion:

        return VectorSupport.convert(VectorSupport.VECTOR_OP_CAST,
                                     getClass(), etype, length(),
                                     dvtype, dtype, dlength,
                                     this, dsp,
                                     AbstractVector::toShuffle0);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1153897796

From psandoz at openjdk.org  Fri Mar 31 00:21:22 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 31 Mar 2023 00:21:22 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v5]
In-Reply-To: <oiRTNlsfJ4A5EbcwbqaFSv9DpYutUZv2rLfrOS0ti60=.1d3d4123-b04c-4e24-85cf-3ba8eb5933c8@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
 <oiRTNlsfJ4A5EbcwbqaFSv9DpYutUZv2rLfrOS0ti60=.1d3d4123-b04c-4e24-85cf-3ba8eb5933c8@github.com>
Message-ID: <MEr60_T2IVbV5WspV4SNDTmp4h38xjs1xi94alz3suw=.f45285a0-0c56-4e7a-b44b-9fca23caa145@github.com>

On Thu, 30 Mar 2023 14:30:17 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, VectorShuffle is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
>> 
>> 1. Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
>> 2. Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
>> 3. Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
>> 4. Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
>> 
>> Upon these changes, a `rearrange` can emit more efficient code:
>> 
>>     var species = IntVector.SPECIES_128;
>>     var v1 = IntVector.fromArray(species, SRC1, 0);
>>     var v2 = IntVector.fromArray(species, SRC2, 0);
>>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
>> 
>>     Before:
>>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>>     vmovdqu 0x10(%r10),%xmm0
>>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>>                                                             ;   {external_word}
>>     vpackusdw %xmm0,%xmm0,%xmm0
>>     vpackuswb %xmm0,%xmm0,%xmm0
>>     vpmovsxbd %xmm0,%xmm3
>>     vpcmpgtd %xmm3,%xmm1,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fc2acb4e0d8
>>     vpmovzxbd %xmm0,%xmm0
>>     vpermd %ymm2,%ymm0,%ymm0
>>     movabs $0x751588f98,%r10            ;   {oop([I{0x0000000751588f98})}
>>     vmovdqu %xmm0,0x10(%r10)
>> 
>>     After:
>>     movabs $0x751589c78,%r10            ;   {oop([I{0x0000000751589c78})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158ac88,%r10            ;   {oop([I{0x000000075158ac88})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     vpxor  %xmm0,%xmm0,%xmm0
>>     vpcmpgtd %xmm2,%xmm0,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fa818b27cb1
>>     vpermd %ymm1,%ymm2,%ymm0
>>     movabs $0x751588c68,%r10            ;   {oop([I{0x0000000751588c68})}
>>     vmovdqu %xmm0,0x10(%r10)
>>     
>> Please take a look and leave reviews. Thanks a lot.
>
> 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 14 commits:
> 
>  - move implementations up
>  - Merge branch 'master' into shufflerefactor
>  - Merge branch 'master' into shufflerefactor
>  - reviews
>  - missing casts
>  - clean up
>  - fix Matcher::vector_needs_load_shuffle
>  - fix internal types, clean up
>  - optimise laneIsValid
>  - Merge branch 'master' into shufflerefactor
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/d063b896...a4835c00

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-VectorBits.java.template line 1106:

> 1104:         @Override
> 1105:         @ForceInline
> 1106:         public int laneSource(int i) {

Can this method be moved to `AbstractShuffle`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1153902133

From psandoz at openjdk.org  Fri Mar 31 00:29:22 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 31 Mar 2023 00:29:22 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v5]
In-Reply-To: <oiRTNlsfJ4A5EbcwbqaFSv9DpYutUZv2rLfrOS0ti60=.1d3d4123-b04c-4e24-85cf-3ba8eb5933c8@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
 <oiRTNlsfJ4A5EbcwbqaFSv9DpYutUZv2rLfrOS0ti60=.1d3d4123-b04c-4e24-85cf-3ba8eb5933c8@github.com>
Message-ID: <euVrlRN2j5P2_JHpSgdtH6NhQUNEzELkbiMySBCqSxo=.7994b58e-113a-41e4-ac60-d586d0698d9f@github.com>

On Thu, 30 Mar 2023 14:30:17 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, VectorShuffle is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
>> 
>> 1. Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
>> 2. Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
>> 3. Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
>> 4. Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
>> 
>> Upon these changes, a `rearrange` can emit more efficient code:
>> 
>>     var species = IntVector.SPECIES_128;
>>     var v1 = IntVector.fromArray(species, SRC1, 0);
>>     var v2 = IntVector.fromArray(species, SRC2, 0);
>>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
>> 
>>     Before:
>>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>>     vmovdqu 0x10(%r10),%xmm0
>>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>>                                                             ;   {external_word}
>>     vpackusdw %xmm0,%xmm0,%xmm0
>>     vpackuswb %xmm0,%xmm0,%xmm0
>>     vpmovsxbd %xmm0,%xmm3
>>     vpcmpgtd %xmm3,%xmm1,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fc2acb4e0d8
>>     vpmovzxbd %xmm0,%xmm0
>>     vpermd %ymm2,%ymm0,%ymm0
>>     movabs $0x751588f98,%r10            ;   {oop([I{0x0000000751588f98})}
>>     vmovdqu %xmm0,0x10(%r10)
>> 
>>     After:
>>     movabs $0x751589c78,%r10            ;   {oop([I{0x0000000751589c78})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158ac88,%r10            ;   {oop([I{0x000000075158ac88})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     vpxor  %xmm0,%xmm0,%xmm0
>>     vpcmpgtd %xmm2,%xmm0,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fa818b27cb1
>>     vpermd %ymm1,%ymm2,%ymm0
>>     movabs $0x751588c68,%r10            ;   {oop([I{0x0000000751588c68})}
>>     vmovdqu %xmm0,0x10(%r10)
>>     
>> Please take a look and leave reviews. Thanks a lot.
>
> 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 14 commits:
> 
>  - move implementations up
>  - Merge branch 'master' into shufflerefactor
>  - Merge branch 'master' into shufflerefactor
>  - reviews
>  - missing casts
>  - clean up
>  - fix Matcher::vector_needs_load_shuffle
>  - fix internal types, clean up
>  - optimise laneIsValid
>  - Merge branch 'master' into shufflerefactor
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/d063b896...a4835c00

The changes look very good to me. It would be useful if @jatin-bhateja could also take a look.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-VectorBits.java.template line 1158:

> 1156:         }
> 1157: 
> 1158:         private static $bitstype$[] prepare(int[] indices, int offset) {

If we want to reduce code duplication further I suspect we could move these static methods to IntVector etc. Up to you.

-------------

Marked as reviewed by psandoz (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13093#pullrequestreview-1366098245
PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1153904271

From dzhang at openjdk.org  Fri Mar 31 01:06:19 2023
From: dzhang at openjdk.org (Dingli Zhang)
Date: Fri, 31 Mar 2023 01:06:19 GMT
Subject: RFR: 8305008: RISC-V: Factor out immediate checking functions from
 assembler_riscv.inline.hpp [v2]
In-Reply-To: <AzDnl09LzEXnBgoMSNifXvYxTeGdRypvAQRoqfQwynM=.4d6a766f-d2d1-4ff7-a0ed-9d2b3a30b572@github.com>
References: <zOPJRtrXmBK17ZgSm-THTp8qCXhh7tSNg6VRVFoLz9Y=.763009a8-a651-499d-a0e1-f114f3c842f0@github.com>
 <E-CIFmWm7kSmdB0j0UUCd9F2sbzryngHDCgbKoSd8vA=.8485fbbe-6476-43fa-90f1-5bba60378403@github.com>
 <AzDnl09LzEXnBgoMSNifXvYxTeGdRypvAQRoqfQwynM=.4d6a766f-d2d1-4ff7-a0ed-9d2b3a30b572@github.com>
Message-ID: <JkBNzH0QNEO4EagArKsgJyryNuADMeKehtBYbVTOujw=.37842422-f300-4459-9d5c-f93b09cd36aa@github.com>

On Wed, 29 Mar 2023 01:06:08 GMT, Feilong Jiang <fjiang at openjdk.org> wrote:

>> Dingli Zhang has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove unecessary zero checking
>>  - Fix assert
>
> Okay then.

@feilongjiang @RealFYang Thanks for the review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13202#issuecomment-1491150088

From never at openjdk.org  Fri Mar 31 01:22:23 2023
From: never at openjdk.org (Tom Rodriguez)
Date: Fri, 31 Mar 2023 01:22:23 GMT
Subject: RFR: 8305066: [JVMCI] guarantee(ik->is_initialized()) failed:
 java/lang/Long$LongCache must be initialized
In-Reply-To: <4MoN5JJV_aGKkgXXYCX0sgHkNc4fXnyWgS7emWRi0xg=.cfdff0ab-9420-437b-a57f-cfa5ca9a8051@github.com>
References: <4MoN5JJV_aGKkgXXYCX0sgHkNc4fXnyWgS7emWRi0xg=.cfdff0ab-9420-437b-a57f-cfa5ca9a8051@github.com>
Message-ID: <3KWOxQGtY_cdhcXVcx1fUanA2g3VGPN62gIsSdFYFbA=.5d332e35-0430-47de-a029-0deba30d19b8@github.com>

On Wed, 29 Mar 2023 13:44:24 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> Class initialization can fail for the boxing caches such as `Long$LongCache` due to things such as a `StackOverflowError`.
> When rematerializing boxed values during deoptimization, a failed cache initialization must be handled. This PR handles it by throwing an OOME which is always semantically correct.
> 
> Note that a VM with a broken boxing cache is going to be in a fairly miserable state (i.e. throwing `NoClassDefFoundError` on every call to `Long.valueOf`) so the OOME shouldn't cause any noticeable problem.

This looks good to me.  There's really no other way to handle it.

-------------

Marked as reviewed by never (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13229#pullrequestreview-1366126807

From dzhang at openjdk.org  Fri Mar 31 01:26:23 2023
From: dzhang at openjdk.org (Dingli Zhang)
Date: Fri, 31 Mar 2023 01:26:23 GMT
Subject: Integrated: 8305008: RISC-V: Factor out immediate checking functions
 from assembler_riscv.inline.hpp
In-Reply-To: <zOPJRtrXmBK17ZgSm-THTp8qCXhh7tSNg6VRVFoLz9Y=.763009a8-a651-499d-a0e1-f114f3c842f0@github.com>
References: <zOPJRtrXmBK17ZgSm-THTp8qCXhh7tSNg6VRVFoLz9Y=.763009a8-a651-499d-a0e1-f114f3c842f0@github.com>
Message-ID: <KaMsGQAWmfnfytubFagAZ0UYDD0FVMBkifGLgZCddxQ=.a4b0b19c-8668-4f8c-8239-71440e043a96@github.com>

On Tue, 28 Mar 2023 05:59:49 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

> The call-point to 'is_imm_in_range', 'is_unsigned_imm_in_range' and 'is_offset_in_range' in assembler_riscv.inline.hpp could to be replaced with shared code function 'is_simm' and 'is_uimm'.
> 
> For 'is_imm_in_range', if align_bits = 0, then the call point can be changed to call 'is_simm'. If align_bits = 1, then an additional summation judgement is added to determine if it is a multiple of 2. For 'is_unsigned_imm_in_range', we can first determine if it is greater than 0, and then call 'is_uimm' further. 'is_offset_in_range' can be changed directly to call 'is_simm'. This patch also refactored for is_valid_riscv64_address and movptr.
> 
> This patch removed the original functions from assembler_riscv.inline.hpp and defined some fixed-width checking functions based on the number of immediate or offset bits in the spec[1]. At the same time, we also adjusted two includes to fix the compilation error after the modification.
> 
> This patch also factor out 'Assembler::operand_valid_for_add_sub_immediate' and use 'is_simm12' instead.
> 
> Finally, this patch modified the return value in os::non_memory_address_word to avoid an imm64 value of -1 in MacroAssembler::movptr.
> 
> [1] https://github.com/riscv/riscv-isa-manual/releases/download/draft-20230131-c0b298a/riscv-spec.pdf
> 
> ### Testing:
> 
> On Unmatched with release build:
> - [x] Tier1 tests
> - [x] Tier2 tests
> - [x] Tier3 tests

This pull request has now been integrated.

Changeset: a144c713
Author:    Dingli Zhang <dzhang at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a144c713b7bd8d4345ab33974573062536fc25d6
Stats:     150 lines in 11 files changed: 20 ins; 13 del; 117 mod

8305008: RISC-V: Factor out immediate checking functions from assembler_riscv.inline.hpp

Reviewed-by: fjiang, fyang

-------------

PR: https://git.openjdk.org/jdk/pull/13202

From xgong at openjdk.org  Fri Mar 31 01:31:30 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 31 Mar 2023 01:31:30 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v5]
In-Reply-To: <ka5qi0tWKfBx-OBCoQLansVeBAUm3wIJrDv7hMCZ0YE=.890d4fd1-be35-44d7-9ae4-23feb041e25c@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
 <4Op0Z8whnyDXDC6zGyMbx4ugcZp5TEoAqW_myB5flxM=.1c7b59ba-efb2-4f68-90d7-2d6e33e39572@github.com>
 <yPyZ7su4OnRDd5LyQPvU0Hk6n5AI5CO2lR12qO9efCg=.51a05574-aee6-416b-863c-76d38a6766c3@github.com>
 <U-1I398elh4CJBPi5J2fEF14qp9ZgoYFhXxMD70L1wI=.2cecacd5-4fb6-4194-a5e4-c1801e0b7691@github.com>
 <mHU3vRZX4H2iQsCCdwfJzsn8F4ZnmOKhSyv8uD-z9Js=.0d81453a-c349-4da7-b1f2-08b0b70c7761@github.com>
 <ka5qi0tWKfBx-OBCoQLansVeBAUm3wIJrDv7hMCZ0YE=.890d4fd1-be35-44d7-9ae4-23feb041e25c@github.com>
Message-ID: <85ZXqzxAoKbsQrQdxENyOxLI_t5BXW5skPnWEHxcjd0=.7cb7e9f7-8049-4b23-938f-041c8e45b0ec@github.com>

On Thu, 30 Mar 2023 14:41:29 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Yeah, I agree that saving a node have some benefits like what you said. My concern is there are more and more methods added into `Matcher::` and each platform has to do the different implementation. There is not too much meaning for those platforms that do not implement Vector API like` arm/ppc/...` for me. This makes code not so easy to maintain.
>
> I agree, I am thinking of (ab)using template to have a common query function like this
> 
>     template <VectorQuery N, class T, class... U>
>     T vectorQuery(U... args) {
>         return T();
>     }
> 
> then each platform can have a specialisation that looks like this:
> 
>     template <>
>     bool vectorQuery<VectorQuery::NEEDS_LOAD_SHUFFLE>(BasicType bt, int vlen) {
>     }
> 
> Unimplemented platform will return `false` for this, what do you think?

Sounds good! Maybe we can have a folllowed patch to see what the final code looks like. Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1153928312

From sspitsyn at openjdk.org  Fri Mar 31 01:58:28 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 31 Mar 2023 01:58:28 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v13]
In-Reply-To: <G4t2-jd_ff94Jv7iQ4Jd7v41KKPFa_ijP1Hc-p3nE14=.7c39733e-064d-438e-8844-8cb523267f3c@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <d7v-k44x3tTGLm1YHfd40bGgoBeaYDu2o_a1Rb7sT08=.607ecff9-d81e-470b-9671-70e1c24a500c@github.com>
 <G4t2-jd_ff94Jv7iQ4Jd7v41KKPFa_ijP1Hc-p3nE14=.7c39733e-064d-438e-8844-8cb523267f3c@github.com>
Message-ID: <rFk461FY2w8qMK99zMKAVhZzAiPGr7f-tfj9Zo4QzIk=.318b8827-f30d-478e-8b1a-8f594223bae5@github.com>

On Thu, 30 Mar 2023 22:17:01 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: tweak in count_transitions_and_correct_jvmti_thread_states
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest.java line 90:
> 
>> 88:  *  - disable notifyJvmti events mode
>> 89:  *  - start the platform launcher thread which starts N of virtual thread
>> 90:  *  - enable notifyJvmti events mode after about hapf of virtual thread started
> 
> Suggestion:
> 
>  *  - enable notifyJvmti events mode after about half of the virtual threads have started

Fixed now, thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1153938774

From xgong at openjdk.org  Fri Mar 31 03:13:22 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 31 Mar 2023 03:13:22 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v5]
In-Reply-To: <oiRTNlsfJ4A5EbcwbqaFSv9DpYutUZv2rLfrOS0ti60=.1d3d4123-b04c-4e24-85cf-3ba8eb5933c8@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
 <oiRTNlsfJ4A5EbcwbqaFSv9DpYutUZv2rLfrOS0ti60=.1d3d4123-b04c-4e24-85cf-3ba8eb5933c8@github.com>
Message-ID: <jKqyImlDvtrxUvYMNwpSdUyFTWsl0WvJD_9IljoOtlw=.d3ce1290-e1bb-4a04-b542-f63ce4342505@github.com>

On Thu, 30 Mar 2023 14:30:17 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, VectorShuffle is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
>> 
>> 1. Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
>> 2. Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
>> 3. Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
>> 4. Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
>> 
>> Upon these changes, a `rearrange` can emit more efficient code:
>> 
>>     var species = IntVector.SPECIES_128;
>>     var v1 = IntVector.fromArray(species, SRC1, 0);
>>     var v2 = IntVector.fromArray(species, SRC2, 0);
>>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
>> 
>>     Before:
>>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>>     vmovdqu 0x10(%r10),%xmm0
>>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>>                                                             ;   {external_word}
>>     vpackusdw %xmm0,%xmm0,%xmm0
>>     vpackuswb %xmm0,%xmm0,%xmm0
>>     vpmovsxbd %xmm0,%xmm3
>>     vpcmpgtd %xmm3,%xmm1,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fc2acb4e0d8
>>     vpmovzxbd %xmm0,%xmm0
>>     vpermd %ymm2,%ymm0,%ymm0
>>     movabs $0x751588f98,%r10            ;   {oop([I{0x0000000751588f98})}
>>     vmovdqu %xmm0,0x10(%r10)
>> 
>>     After:
>>     movabs $0x751589c78,%r10            ;   {oop([I{0x0000000751589c78})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158ac88,%r10            ;   {oop([I{0x000000075158ac88})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     vpxor  %xmm0,%xmm0,%xmm0
>>     vpcmpgtd %xmm2,%xmm0,%xmm3
>>     vtestps %xmm3,%xmm3
>>     jne    0x00007fa818b27cb1
>>     vpermd %ymm1,%ymm2,%ymm0
>>     movabs $0x751588c68,%r10            ;   {oop([I{0x0000000751588c68})}
>>     vmovdqu %xmm0,0x10(%r10)
>>     
>> Please take a look and leave reviews. Thanks a lot.
>
> 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 14 commits:
> 
>  - move implementations up
>  - Merge branch 'master' into shufflerefactor
>  - Merge branch 'master' into shufflerefactor
>  - reviews
>  - missing casts
>  - clean up
>  - fix Matcher::vector_needs_load_shuffle
>  - fix internal types, clean up
>  - optimise laneIsValid
>  - Merge branch 'master' into shufflerefactor
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/d063b896...a4835c00

Vector API tests pass on AArch64 platforms (NEON & SVE). So looks good to me! Please do not forget to update the copyright for two additional touched files `AbstractSpecies.java` and `VectorSpecies.java`. Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13093#issuecomment-1491229216

From dholmes at openjdk.org  Fri Mar 31 04:56:22 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 31 Mar 2023 04:56:22 GMT
Subject: RFR: 8257967: JFR: Events for loaded agents [v14]
In-Reply-To: <kooNn-2wsfn3v-nibYXs3B73wolCj3OsqHBur3gjv_8=.3ebc9e98-f40d-4d07-9515-05d30829abdc@github.com>
References: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
 <kooNn-2wsfn3v-nibYXs3B73wolCj3OsqHBur3gjv_8=.3ebc9e98-f40d-4d07-9515-05d30829abdc@github.com>
Message-ID: <SlBgA47Ol9dsutVMPVrL8gPi2XvHYklQN-euhTxNxwM=.fffba227-5fa7-4b75-bd57-6343a1eea458@github.com>

On Thu, 30 Mar 2023 19:20:11 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> We are adding support to let JFR report on Agents.
>> 
>> #### Design
>> 
>> An Agent is a library that uses any instrumentation or profiling APIs. Most agents are started and initialized on the command line, but agents can also be loaded dynamically during runtime. Because command line agents initialize during the VM startup sequence, they add to the overall startup time latency in getting the VM ready. The events will report on the time the agent took to initialize.
>> 
>> A JavaAgent is an agent written in the Java programming language, using the APIs in the package [java.lang.instrument](https://docs.oracle.com/en/java/javase/19/docs/api/java.instrument/java/lang/instrument/package-summary.html)
>> 
>> A JavaAgent is sometimes called a JPLIS agent, where the acronym JPLIS stands for Java Programming Language Instrumentation Services.
>> 
>> To report on JavaAgents, JFR will add the new event type jdk.JavaAgent and events will look similar to these two examples:
>> 
>> // Command line
>> jdk.JavaAgent {
>>   startTime = 12:31:19.789 (2023-03-08)
>>   name = "JavaAgent.jar"
>>   options = "foo=bar"
>>   dynamic = false
>>   initializationTime = 12:31:15.574 (2023-03-08)
>>   initializationDuration = 172 ms
>> }
>> 
>> // Dynamic load
>> jdk.JavaAgent {
>>   startTime = 12:31:31.158 (2023-03-08)
>>   name = "JavaAgent.jar"
>>   options = "bar=baz"
>>   dynamic = true
>>   initializationTime = 12:31:31.037 (2023-03-08)
>>   initializationDuration = 64,1 ms
>> }
>> 
>> The jdk.JavaAgent event type is a JFR periodic event that iterates over running Java agents.
>> 
>> For a JavaAgent event, the agent's name will be the specific .jar file containing the instrumentation code. The options will be the specific options passed to the .jar file as part of launching the agent, for example, on the command line: -javaagent: JavaAgent.jar=foo=bar.
>> 
>> The "dynamic" field denotes if the agent was loaded via the command line (dynamic = false) or dynamically (dynamic = true)
>> 
>> "initializationTime" is the timestamp the JVM invoked the initialization method, and "initializationDuration" is the duration of executing the initialization method.
>> 
>> "startTime" represents the time the JFR framework issued the periodic event; hence "initializationTime" will be earlier than "startTime".
>> 
>> An agent can also be written in a native programming language using the [JVM Tools Interface (JVMTI)](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html). This kind of agent, sometimes called a native agent, is a platform-specific binary, sometimes referred to as a library, but here it means a .so or .dll file.
>> 
>> To report on native agents, JFR will add the new event type jdk.NativeAgent and events will look similar to this example:
>> 
>> jdk.NativeAgent {
>>   startTime = 12:31:40.398 (2023-03-08)
>>   name = "jdwp"
>>   options = "transport=dt_socket,server=y,address=any,onjcmd=y"
>>   dynamic = false
>>   initializationTime = 12:31:36.142 (2023-03-08)
>>   initializationDuration = 0,00184 ms
>>   path = "c:\ade\github\openjdk\jdk\build\windows-x86_64-server-slowdebug\jdk\bin\jdwp.dll"
>> }
>> 
>> The layout of the event type is very similar to the jdk.JavaAgent event, but here the path to the native library is reported.
>> 
>> The initialization of a native agent is performed by invoking an agent-specified callback routine. The "initializationTime" is when the JVM sent or would have sent the JVMTI VMInit event to a specified callback. "initializationDuration" is the duration to execute that specific callback. If no callback is specified for the JVMTI VMInit event, the "initializationDuration" will be 0. If the agent is loaded dynamically, "initializationDuration" is the time taken to execute the Agent_OnAttach callback.
>> 
>> #### Implementation
>> 
>> There has not existed a reification of a JavaAgent directly in the JVM, as these are built on top of the JDK native library, "instrument", using a many-to-one mapping. At the level of the JVM, the only representation of agents after startup is through JvmtiEnv's, which agents request from the JVM during startup and initialization ? as such, mapping which JvmtiEnv belongs to what JavaAgent was not possible before.
>> 
>> Using implementation details of how the JDK native library "instrument" interacts with the JVM, we can build this mapping to track what JvmtiEnv's "belong" to what JavaAgent. This mapping now lets us report the Java-relevant context (name, options) and measure the time it takes for the JavaAgent to initialize.
>> 
>> When implementing this capability, it was necessary to refactor the code used to represent agents, AgentLibrary. The previous implementation was located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp.
>> 
>> The refactoring isolates the relevant logic into two new modules, prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their older places will help reduce the sizes of oversized arguments.cpp and threads.cpp.
>> 
>> The previous two lists that maintained "agents" (JVMTI) and "libraries" (Xrun) were not thread-safe for concurrent iterations. A single list that allows for concurrent iterations is therefore introduced.
>> 
>> Testing: jdk_jfr, tier 1 - 6
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore misssing frees

src/hotspot/share/jfr/metadata/metadata.xml line 1190:

> 1188:     <Field type="boolean" name="dynamic" label="Dynamic" description="If the library attached to the JVM dynamically during runtime, i.e. not at startup" />
> 1189:     <Field type="Ticks" name="initializationTime" label="Initialization Time" description="The time the JVM initialized the agent" />
> 1190:     <Field type="Tickspan" name="initializationDuration" label="Initialization Duration" description="The duration of executing the JVMTI VMInit event callback. If no VMInit callback is specified, the duration is 0. For a dynamically loaded agent, the duration of executing the call to Agent_OnAttach." />

Nit: In the last sentence I suggest s/the duration/it is the duration/

src/hotspot/share/prims/agent.cpp line 533:

> 531:     if (thread->is_pending_jni_exception_check()) {
> 532:       thread->clear_pending_jni_exception_check();
> 533:     }

Unsure why we pretend the agent checked this - don't we want -Xcheck:jni to report a bug in the agent?

src/hotspot/share/prims/agent.cpp line 536:

> 534:   }
> 535: 
> 536:   // Agent_OnAttach may have used JNI

Copied from above?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12923#discussion_r1153965163
PR Review Comment: https://git.openjdk.org/jdk/pull/12923#discussion_r1153967066
PR Review Comment: https://git.openjdk.org/jdk/pull/12923#discussion_r1153966809

From dholmes at openjdk.org  Fri Mar 31 05:14:27 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 31 Mar 2023 05:14:27 GMT
Subject: RFR: 8297539: Use PrimitiveConversions::cast for local uses of the
 int<->float union conversion trick [v3]
In-Reply-To: <NH7fN3_RxyiIv033c7qocb32V083AannceliXFwkFVo=.507eb435-2c6a-4591-a907-88c4c756b6ad@github.com>
References: <Fc1LufRzwqeQjXSwyVm3FaJWzbaazUXyArTYPLlGrwM=.034cb09b-79d8-49a1-a68d-b5914a9cc214@github.com>
 <NH7fN3_RxyiIv033c7qocb32V083AannceliXFwkFVo=.507eb435-2c6a-4591-a907-88c4c756b6ad@github.com>
Message-ID: <8t2kZQIkk3QEnSYRQovjHfee0RPCExKfnUYGX4EvG34=.e65c8836-50dc-4298-9e1d-9a239ea9f330@github.com>

On Tue, 28 Mar 2023 14:40:08 GMT, Afshin Zafari <duke at openjdk.org> wrote:

>> **Only** the instances of using `union` for converting `int` to `float` are replaced with call to `PrimitiveConversions::cast<To>(From)` method. Some few cases with conversion of `long` <->`double` are also replaced with `PrimitiveConversions::cast<To>(From)`. The other instances where the union contains other types of fields than `int` and `float` are left unchanged.
>> 
>> ### Test
>> local hotspot:tier1
>> mach5 tiers 1-5
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8297539: Use PrimitiveConversions::cast for local uses of the int<->float union conversion trick

Seems okay other than the override issue.

Thanks.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13136#pullrequestreview-1366261266

From sspitsyn at openjdk.org  Fri Mar 31 05:20:21 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 31 Mar 2023 05:20:21 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v13]
In-Reply-To: <bblJkwdclwKPgCvQb93hL-8xXiC1v00yhk01imHfHpA=.3c0f87b9-68b9-435c-8cdc-5b6aa64fd960@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <d7v-k44x3tTGLm1YHfd40bGgoBeaYDu2o_a1Rb7sT08=.607ecff9-d81e-470b-9671-70e1c24a500c@github.com>
 <bblJkwdclwKPgCvQb93hL-8xXiC1v00yhk01imHfHpA=.3c0f87b9-68b9-435c-8cdc-5b6aa64fd960@github.com>
Message-ID: <jq_cCebFm5TexWIeYysDlTjtj1n-Jek2uVSoV7WZpbk=.d13bd8a4-154a-42fc-81fa-b2e103e6cb22@github.com>

On Thu, 30 Mar 2023 22:21:06 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: tweak in count_transitions_and_correct_jvmti_thread_states
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest.java line 45:
> 
>> 43: // to have sleep() calls to provide yielding as some frequency of virtual
>> 44: // thread mount state transitions is needed for this test scenario.
>> 45: class TestedThread extends Thread {
> 
> Shouldn't this be a Runnable instead of a Thread? I would also suggest not using  the term "thread" here. Maybe "task"? Otherwise code like the following is misleading:
> 
> 
>                 TestedThread thread = threads[i];
>                 thread.letFinish();
> 
> There are no threads being referenced in this code, yet the term "thread" is used 4 times.

Thank you for the suggestion. I've renamed/rearranged it now. Let me know if it is not what you expected.

> test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest.java line 172:
> 
>> 170:         setVirtualThreadsNotifyJvmtiMode(iter, false);
>> 171: 
>> 172:         Thread tt = Thread.ofPlatform().name("StartThreadsTest").start(ToggleNotifyJvmtiTest::startThreads);
> 
> Why does each test  cycle need to be run in a separate platform thread? Can't you just use the main test thread?

You are right, hanks. I've made the suggested change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1154022482
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1154023063

From sspitsyn at openjdk.org  Fri Mar 31 05:20:23 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 31 Mar 2023 05:20:23 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v13]
In-Reply-To: <PjeXeo8_ptMN7DzyRGoQtW8dX1uaRLbGmeMm0AlKhu4=.e7767e91-3c01-4663-bdfc-8fe5517c8764@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <d7v-k44x3tTGLm1YHfd40bGgoBeaYDu2o_a1Rb7sT08=.607ecff9-d81e-470b-9671-70e1c24a500c@github.com>
 <07UH4ks6EGmxIt5mZ3dNPi0YaC8u-xhBNF-Ao9iOAcA=.378b96b5-19e0-4d0a-95d8-83fd44f39024@github.com>
 <JCDrnSm9lzp97A1W6Lpws6AMYVsYy38xVAMIs9P7PSg=.b311d738-a317-4ade-a00c-395c2c223a51@github.com>
 <PjeXeo8_ptMN7DzyRGoQtW8dX1uaRLbGmeMm0AlKhu4=.e7767e91-3c01-4663-bdfc-8fe5517c8764@github.com>
Message-ID: <WaqanC-tpgcjlazp9hHgzkb-pl0IxvOJQ4cahMnq6HE=.4ae266f1-9cf5-432e-adeb-711c2f7ac9b0@github.com>

On Thu, 30 Mar 2023 23:11:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Thank you for the concern.
>> The `startThread()` below which is called from `startThreads()` has the call to `thread.ensureReady()` which waits until the target tested thread really starts and sets the `threadReady` field. So, there is no race condition as the `startThreads()` and `finishThreads()` are synchronized methods.
>> 
>> 
>>     static private void startThread(int i) {
>>         String name = "TestedThread" + i;
>>         TestedThread thread = new TestedThread(name);
>>         vts[i] = Thread.ofVirtual().name(name).start(thread);
>>         thread.ensureReady();
>>         threads[i] = thread;
>>         log("# Java: started vthread: " + name);
>>     }
>> 
>>     static synchronized private void startThreads() {
>>         log("\n# Java: Starting vthreads");
>>         for (int i = 0; i < VTHREADS_CNT; i++) {
>>             sleep(1);
>>             startThread(i);
>>         }
>>     }
>> 
>>     static private synchronized void finishThreads() {
>>         try {
>>             for (int i = 0; i < VTHREADS_CNT; i++) {
>>                 TestedThread thread = threads[i];
>>                 thread.letFinish();
>>                 vts[i].join();
>>             }
>>         } catch (InterruptedException e) {
>>             throw new RuntimeException(e);
>>         }
>>     }
>> 
>> Please, let me know if I'm missing anything.
>
> So the race I am talking about is between the main thread running finishThreads() and the launcher thread running startThreads(). The main thread could execute finishThreads() before the launcher executes startThreads(). If you comment out the two first sleeps in run_test_cycle() you can actually see the issue. Again, given that the sleeps are there it is an unlikely scheduling, but if we want to avoid depending on timing we can add that extra synchronization.

Sorry, I understood you incorrectly. You are right, there is this kind of race here.
I've rearranges this area a little bit, and hope, it is cleaner now.
Now, both `startVirtualThreads()` and `finishVirtualThreads()` are invoked on the main thread, so they do not need to be synchronized any more.  Also, the call to `ensureReady()` are moved to `finishVirtualThreads()` right before the call to `letFinish()`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1154021018

From sspitsyn at openjdk.org  Fri Mar 31 05:41:23 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 31 Mar 2023 05:41:23 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v13]
In-Reply-To: <bblJkwdclwKPgCvQb93hL-8xXiC1v00yhk01imHfHpA=.3c0f87b9-68b9-435c-8cdc-5b6aa64fd960@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <d7v-k44x3tTGLm1YHfd40bGgoBeaYDu2o_a1Rb7sT08=.607ecff9-d81e-470b-9671-70e1c24a500c@github.com>
 <bblJkwdclwKPgCvQb93hL-8xXiC1v00yhk01imHfHpA=.3c0f87b9-68b9-435c-8cdc-5b6aa64fd960@github.com>
Message-ID: <X3hDWf4xyvOPIAExcvWOIz1iboOTWczmMirlMl3bp5w=.2a31e76f-71ed-4d64-a664-864171510cdb@github.com>

On Thu, 30 Mar 2023 22:31:02 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: tweak in count_transitions_and_correct_jvmti_thread_states
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest.java line 170:
> 
>> 168:         // Disable notifyJvmti events mode at test cycle start.
>> 169:         // It is unsafe to do so if any virtual threads are executed.
>> 170:         setVirtualThreadsNotifyJvmtiMode(iter, false);
> 
> What happens if the main thread is a virtual thread because the virtual thread wrapper is being used? Is there any concern with disabling notifications in this case?

I've tested it and it is kind of working now.
But I'd like to minimize risk now and avoid testing something which is not really needed.
So, this is why the testing cycles are still there.
The `serviceability/jvmti/vthread` tests are not supposed to be run with the virtual thread wrapper.
It is why we have the special problem list `ProblemList-vthread.txt` in Loom repository.
I guess, we should replicate the same or alike approach in the main line when virtual thread wrapper is introduced.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1154034742

From dholmes at openjdk.org  Fri Mar 31 05:57:20 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 31 Mar 2023 05:57:20 GMT
Subject: RFR: 8303210: [linux,
 Windows] Make UseSystemMemoryBarrier available as product flag [v7]
In-Reply-To: <s2PuR1n-7F7-Bql_JAjr3xwRA8WZtcFlmYKXcpKon58=.d07c16aa-4572-4b74-9289-89cbabaf91ab@github.com>
References: <9eZo1xYNGhjMSC9lDXKtkO1eyU_H-Veuh1AeP3CPKbg=.69b6c4ff-a3ef-439f-8468-21fec9de1825@github.com>
 <s2PuR1n-7F7-Bql_JAjr3xwRA8WZtcFlmYKXcpKon58=.d07c16aa-4572-4b74-9289-89cbabaf91ab@github.com>
Message-ID: <8j2QGoWfPj8shn13rYGXBi8-OvEuuu19ii19Po-1Ky4=.efdbb5c1-5be3-4388-b8a9-77d10f9b38b8@github.com>

On Thu, 30 Mar 2023 16:53:18 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> I'd like to enable UseSystemMemoryBarrier by default on supported Operating Systems in order to improve performance of thread state transitions (I/O, JNI, foreign function calls, JIT compiler threads, etc.). See JBS issue for more details.
>> Unfortunately, the feature was not yet implemented on all platforms. I added the code, but need the platform maintainers to check if it can be used reliably (and ideally if the performance improves). It's easy to switch it off again in case of problems.
>> 
>> Update: Startup performance and some benchmarks on some platforms are impacted (see below). So, this PR no longer switches it on by default.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move flag configuration and initialization to SystemMemoryBarrier and call it from parse_vm_init_args.

Update looks good. Thanks.

The placement in a .hpp file is not ideal but lacking a cpp file ...

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12753#pullrequestreview-1366293545

From rkennke at openjdk.org  Fri Mar 31 06:06:47 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 31 Mar 2023 06:06:47 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v47]
In-Reply-To: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
Message-ID: <zL-d1b4dJXDtaQHN1vOqbuDlgWcYV4sLef5ejOYR7DM=.71e7e5b3-b360-4f8c-a8f8-b54eafec87b3@github.com>

> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
> 
> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p
 rotocols.
> 
> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare.
> 
> 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
> 
> 
> Testing:
>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
> 
> ### Performance
> 
> #### Simple Microbenchmark
> 
> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
> 
> |  | x86_64 | aarch64 |
> | -- | -- | -- |
> | -UseFastLocking | 20.651 | 20.764 |
> | +UseFastLocking | 18.896 | 18.908 |
> 
> 
> #### Renaissance
> 
> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
> -- | -- | -- | -- | -- | -- | -- | --
> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Use int instead of size_t for cached offsets, to match the uncached offset type and avoid build failures

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10907/files
  - new: https://git.openjdk.org/jdk/pull/10907/files/eaf2286f..adeccaae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=46
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=45-46

  Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/10907.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10907/head:pull/10907

PR: https://git.openjdk.org/jdk/pull/10907

From rkennke at openjdk.org  Fri Mar 31 06:17:19 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 31 Mar 2023 06:17:19 GMT
Subject: RFR: JDK-8304815: Use NMT for more precise hs_err location
 printing [v7]
In-Reply-To: <vqnP4aPirIfiVVmHN45Qht-FK1HeweJSywjO1YGb4So=.f54bfd01-8275-4a7d-a8c2-1af1db7e3d34@github.com>
References: <DPqsrXUm5sJjcxDGZW6QSvdpu83LBhwXreIJU7LXqjI=.dfe3de5e-919a-494d-a8dd-0622d1ee0c65@github.com>
 <vqnP4aPirIfiVVmHN45Qht-FK1HeweJSywjO1YGb4So=.f54bfd01-8275-4a7d-a8c2-1af1db7e3d34@github.com>
Message-ID: <dpOZaF1W5FfGiPl2Y3FMWBxB74wcE6i07e-vtElY_9Q=.c6729a07-e2cf-4257-99bd-403a63368137@github.com>

On Thu, 30 Mar 2023 16:08:55 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> (This is a byproduct of work on the arm port for https://github.com/openjdk/jdk/pull/10907. I needed better debugging information in the hs-err file and in gdb.)
>> 
>> Back in 2022 @zhengyu123 had the very nice idea of using NMT mapping info for smartening up pp in gdb: [JDK-8280289](https://bugs.openjdk.org/browse/JDK-8280289).
>> 
>> The same idea can be applied to hs_err file location printing. NMT has information about all its mappings and can tell us where it thinks a given unknown pointer points into.
>> 
>> This could be even more useful if the "find malloc block" part of that functionality would be smarter. As it is now, it only works if the pointer in question points to the start of a user-allocated area. Would be nice if the code could (carefully) search for the next valid-looking malloc header instead.
>> 
>> --------------
>> 
>> This patch does this: we introduce a new API, MemTracker::print_containing_region(void*), that tries to make sense of a given unknown pointer.
>> 
>> It will search its mmap regions and print those if found. For malloc'ed pointers, it will carefully sniff out the immediate surroundings of the block, trying to find what looks like a valid malloc header. It uses SafeFetch to not trip over unmapped or protected pages. Note that, of course, we may get false recognition positives if it finds something that looks like a valid header. But even that could be useful (e.g. a remnant dead header may indicate we access memory after free).
>> 
>> Looks like this (its arm, so 32-bit pointers):
>> 
>> 
>> Register to memory mapping:
>> 
>> ->  r0  = 0x728a6ae0 into life malloced block starting at 0x728a6ae0, size 104, tag mtSynchronizer
>> ->  r1  = 0x75b02010 into life malloced block starting at 0x75b02010, size 184, tag mtObjectMonitor
>> ->  r2  = 0x728a6ae0 into life malloced block starting at 0x728a6ae0, size 104, tag mtSynchronizer
>>     r3  = 0x0 is nullptr
>> ->  r4  = 0x728a6ae0 into life malloced block starting at 0x728a6ae0, size 104, tag mtSynchronizer
>>     r5  = 0xb6d3bbc8: <offset 0x018f6bc8> in /shared/projects/openjdk/jdk-jdk/output-fastdebug-arm/images/jdk/lib/server/libjvm.so at 0xb5445000
>>     r6  = 0xffffffff is an unknown value
>>     r7  = 0x0 is nullptr
>>     r8  = 0x0000000a is an unknown value
>>     r9  = 0x728a4308 is a thread
>>     r10 = 0x0000000b is an unknown value
>> ->  fp  = 0x753fe8cc in mmap'd memory region [0x75380000 - 0x75400000] by Thread Stack
>>     r12 = 0x0 is nullptr
>> ->  sp  = 0x753fe8b0 in mmap'd memory region [0x75380000 - 0x75400000] by Thread Stack
>>     lr  = 0xb69bc1d0: <offset 0x015771d0> in /shared/projects/openjdk/jdk-jdk/output-fastdebug-arm/images/jdk/lib/server/libjvm.so at 0xb5445000
>>     pc  = 0xb69c8670: <offset 0x01583670> in /shared/projects/openjdk/jdk-jdk/output-fastdebug-arm/images/jdk/lib/server/libjvm.so at 0xb5445000
>> 
>> 
>> 
>> The small caveat here is that NMT reporting needs ThreadCritical, and thus using it for location printing may block error reporting if it crashed inside a ThreadCritical section. We face the same issue today when printing the NMT report as part of the hs-err file. 
>> 
>> I think the usefulness of these printouts justify this risk. However I opened https://bugs.openjdk.org/browse/JDK-8304824 to investigate a better locking strategy for NMT.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   life->live

Looks good to me. Feel free to clarify/name the two literals that I mentioned.
Thanks,
Roman

src/hotspot/share/services/mallocTracker.cpp line 212:

> 210:   const MallocHeader* likely_live_block = nullptr;
> 211:   {
> 212:     const MallocHeader* candidate = (const MallocHeader*)(align_down(addr, 16));

What is that constant 16? Maybe name it?

src/hotspot/share/services/mallocTracker.cpp line 213:

> 211:   {
> 212:     const MallocHeader* candidate = (const MallocHeader*)(align_down(addr, 16));
> 213:     const MallocHeader* const end = candidate - 0x1001; // stop searching after 4k

Same here, what is 0x1001 and maybe name it?

-------------

Marked as reviewed by rkennke (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13162#pullrequestreview-1366306178
PR Review Comment: https://git.openjdk.org/jdk/pull/13162#discussion_r1154052850
PR Review Comment: https://git.openjdk.org/jdk/pull/13162#discussion_r1154053026

From sspitsyn at openjdk.org  Fri Mar 31 06:52:18 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 31 Mar 2023 06:52:18 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v14]
In-Reply-To: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
Message-ID: <eCKU_LwEwIaRdXGC_i3x5dacmsGVUja_K5oPwN1UngA=.beea9c5d-dc3a-49dd-bd22-e25b1ebaac4c@github.com>

> The fix is to enable virtual threads support for late binding JVMTI agents.
> The fix includes:
> - New function `JvmtiEnvBase::enable_virtual_threads_notify_jvmti()` which does enabling JVMTI VTMS transition notifications in case of agent loaded into running VM. This function executes a VM operation counting VTMS transition bits in all `JavaThread`'s to correctly set the static counter `_VTMS_transition_count` needed for VTMS transition protocol.
> - New function `JvmtiEnvBase::disable_virtual_threads_notify_jvmti()` which is needed for testing. It is used by the `WhiteBox` API.
> - New WhiteBox function `WB_SetVirtualThreadsNotifyJvmtiMode(JNIEnv* env, jobject wb, jboolean enable)` needed for testing of this update.
> - New regression test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
> 
> Testing:
> - New test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
> - The originally failed tests are expected to pass 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:

  review: addressed next round of review suggestions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13133/files
  - new: https://git.openjdk.org/jdk/pull/13133/files/1bb250a7..aef87273

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13133&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13133&range=12-13

  Stats: 34 lines in 1 file changed: 3 ins; 7 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/13133.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13133/head:pull/13133

PR: https://git.openjdk.org/jdk/pull/13133

From stuefe at openjdk.org  Fri Mar 31 07:28:49 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 31 Mar 2023 07:28:49 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v47]
In-Reply-To: <zL-d1b4dJXDtaQHN1vOqbuDlgWcYV4sLef5ejOYR7DM=.71e7e5b3-b360-4f8c-a8f8-b54eafec87b3@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <zL-d1b4dJXDtaQHN1vOqbuDlgWcYV4sLef5ejOYR7DM=.71e7e5b3-b360-4f8c-a8f8-b54eafec87b3@github.com>
Message-ID: <kbB5LIzZLjy_dGTTysVtZUrsHEhSVjLJwlwKX531GBE=.343f60c7-8a77-4ca5-9efb-7a2442db5185@github.com>

On Fri, 31 Mar 2023 06:06:47 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use int instead of size_t for cached offsets, to match the uncached offset type and avoid build failures

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 6234:

> 6232:   orr(hdr, hdr, markWord::unlocked_value);
> 6233:   // Clear lock-bits, into t2
> 6234:   eor(t2, hdr, markWord::unlocked_value);

In arm, I use a combination of bic and oor instead. That gives me, with just two instructions, added safety against someone handing in a "11" marked MW. I know, should never happen, but better safe.


  ldr(new_hdr, Address(obj, oopDesc::mark_offset_in_bytes()));
  bic(new_hdr, new_hdr, markWord::lock_mask_in_place);  // new header (00)
  orr(old_hdr, new_hdr, markWord::unlocked_value);      // old header (01)

(note that I moved MW loading down into MA::fast_lock for unrelated reasons).

Unfortunately, on aarch64 there seem to be no bic variants that accept immediates. So it would take one more instruction to get the same result:


-  // Load (object->mark() | 1) into hdr
-  orr(hdr, hdr, markWord::unlocked_value);
-  // Clear lock-bits, into t2
-  eor(t2, hdr, markWord::unlocked_value);
+  // Prepare new and old header
+  mov(t2, markWord::lock_mask_in_place);
+  bic(t2, hdr, t2);
+  orr(hdr, t2, markWord::unlocked_value);


But maybe there is a better way that does not need three instructions.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1154111182

From mdoerr at openjdk.org  Fri Mar 31 08:31:21 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 31 Mar 2023 08:31:21 GMT
Subject: RFR: 8303210: [linux,
 Windows] Make UseSystemMemoryBarrier available as product flag [v7]
In-Reply-To: <s2PuR1n-7F7-Bql_JAjr3xwRA8WZtcFlmYKXcpKon58=.d07c16aa-4572-4b74-9289-89cbabaf91ab@github.com>
References: <9eZo1xYNGhjMSC9lDXKtkO1eyU_H-Veuh1AeP3CPKbg=.69b6c4ff-a3ef-439f-8468-21fec9de1825@github.com>
 <s2PuR1n-7F7-Bql_JAjr3xwRA8WZtcFlmYKXcpKon58=.d07c16aa-4572-4b74-9289-89cbabaf91ab@github.com>
Message-ID: <KuBU2RLVqsQfbsIwhuHO63qYYfKkYQRKRFKYmOzbWBw=.812aba07-b728-4cd6-87c2-9d705be08e42@github.com>

On Thu, 30 Mar 2023 16:53:18 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> I'd like to enable UseSystemMemoryBarrier by default on supported Operating Systems in order to improve performance of thread state transitions (I/O, JNI, foreign function calls, JIT compiler threads, etc.). See JBS issue for more details.
>> Unfortunately, the feature was not yet implemented on all platforms. I added the code, but need the platform maintainers to check if it can be used reliably (and ideally if the performance improves). It's easy to switch it off again in case of problems.
>> 
>> Update: Startup performance and some benchmarks on some platforms are impacted (see below). So, this PR no longer switches it on by default.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move flag configuration and initialization to SystemMemoryBarrier and call it from parse_vm_init_args.

Thanks for the review and all your support!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12753#issuecomment-1491523661

From rrich at openjdk.org  Fri Mar 31 09:02:25 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Fri, 31 Mar 2023 09:02:25 GMT
Subject: Integrated: 8305171: PPC: Should use IMA::load_resolved_indy_entry()
 in TIG::generate_return_entry_for()
In-Reply-To: <EJXNWoV4PGQntUD4YSxcUsuyBgUamxw8_9fJNpNbSeQ=.0d62db69-141e-4e44-90d4-737a54c0d55c@github.com>
References: <EJXNWoV4PGQntUD4YSxcUsuyBgUamxw8_9fJNpNbSeQ=.0d62db69-141e-4e44-90d4-737a54c0d55c@github.com>
Message-ID: <WYUQQSvif7Zj218eK4UCqVWxFhoO5noGKvEuY1FmRok=.8869551a-5896-42db-876f-4703c2768ca3@github.com>

On Wed, 29 Mar 2023 12:36:44 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> This PR replaces a sequence of assembler instructions in the interpreter with an equivalent call of `InterpreterMacroAssembler::load_resolved_indy_entry()`.
> 
> Tested hotspot tier1.

This pull request has now been integrated.

Changeset: c8f3a97d
Author:    Richard Reingruber <rrich at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c8f3a97d465bc1ed4020df2786897f3ba786fe50
Stats:     13 lines in 3 files changed: 1 ins; 6 del; 6 mod

8305171: PPC: Should use IMA::load_resolved_indy_entry() in TIG::generate_return_entry_for()

Reviewed-by: mdoerr

-------------

PR: https://git.openjdk.org/jdk/pull/13226

From duke at openjdk.org  Fri Mar 31 09:24:52 2023
From: duke at openjdk.org (Afshin Zafari)
Date: Fri, 31 Mar 2023 09:24:52 GMT
Subject: RFR: 8297539: Use PrimitiveConversions::cast for local uses of the
 int<->float union conversion trick [v4]
In-Reply-To: <Fc1LufRzwqeQjXSwyVm3FaJWzbaazUXyArTYPLlGrwM=.034cb09b-79d8-49a1-a68d-b5914a9cc214@github.com>
References: <Fc1LufRzwqeQjXSwyVm3FaJWzbaazUXyArTYPLlGrwM=.034cb09b-79d8-49a1-a68d-b5914a9cc214@github.com>
Message-ID: <7NKaN1fkjZMSZIpCAP-q32n3PLpmzc8kbBAnNJ6CnR8=.65aa06fe-ead8-41c1-a52c-1b8c78fb6ded@github.com>

> **Only** the instances of using `union` for converting `int` to `float` are replaced with call to `PrimitiveConversions::cast<To>(From)` method. Some few cases with conversion of `long` <->`double` are also replaced with `PrimitiveConversions::cast<To>(From)`. The other instances where the union contains other types of fields than `int` and `float` are left unchanged.
> 
> ### Test
> local hotspot:tier1
> mach5 tiers 1-5

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  8297539: Use PrimitiveConversions::cast for local uses of the int<->float union conversion trick

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13136/files
  - new: https://git.openjdk.org/jdk/pull/13136/files/0c19a153..cc36b50c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13136&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13136&range=02-03

  Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/13136.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13136/head:pull/13136

PR: https://git.openjdk.org/jdk/pull/13136

From stuefe at openjdk.org  Fri Mar 31 09:34:09 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 31 Mar 2023 09:34:09 GMT
Subject: RFR: JDK-8304815: Use NMT for more precise hs_err location
 printing [v8]
In-Reply-To: <DPqsrXUm5sJjcxDGZW6QSvdpu83LBhwXreIJU7LXqjI=.dfe3de5e-919a-494d-a8dd-0622d1ee0c65@github.com>
References: <DPqsrXUm5sJjcxDGZW6QSvdpu83LBhwXreIJU7LXqjI=.dfe3de5e-919a-494d-a8dd-0622d1ee0c65@github.com>
Message-ID: <rDl3MmDOLeUm6jtV4iU1kL9Z2g8aBFjoOXHo1eq8S3A=.abd57beb-2556-4aad-913b-ef9ddc41de87@github.com>

> (This is a byproduct of work on the arm port for https://github.com/openjdk/jdk/pull/10907. I needed better debugging information in the hs-err file and in gdb.)
> 
> Back in 2022 @zhengyu123 had the very nice idea of using NMT mapping info for smartening up pp in gdb: [JDK-8280289](https://bugs.openjdk.org/browse/JDK-8280289).
> 
> The same idea can be applied to hs_err file location printing. NMT has information about all its mappings and can tell us where it thinks a given unknown pointer points into.
> 
> This could be even more useful if the "find malloc block" part of that functionality would be smarter. As it is now, it only works if the pointer in question points to the start of a user-allocated area. Would be nice if the code could (carefully) search for the next valid-looking malloc header instead.
> 
> --------------
> 
> This patch does this: we introduce a new API, MemTracker::print_containing_region(void*), that tries to make sense of a given unknown pointer.
> 
> It will search its mmap regions and print those if found. For malloc'ed pointers, it will carefully sniff out the immediate surroundings of the block, trying to find what looks like a valid malloc header. It uses SafeFetch to not trip over unmapped or protected pages. Note that, of course, we may get false recognition positives if it finds something that looks like a valid header. But even that could be useful (e.g. a remnant dead header may indicate we access memory after free).
> 
> Looks like this (its arm, so 32-bit pointers):
> 
> 
> Register to memory mapping:
> 
> ->  r0  = 0x728a6ae0 into life malloced block starting at 0x728a6ae0, size 104, tag mtSynchronizer
> ->  r1  = 0x75b02010 into life malloced block starting at 0x75b02010, size 184, tag mtObjectMonitor
> ->  r2  = 0x728a6ae0 into life malloced block starting at 0x728a6ae0, size 104, tag mtSynchronizer
>     r3  = 0x0 is nullptr
> ->  r4  = 0x728a6ae0 into life malloced block starting at 0x728a6ae0, size 104, tag mtSynchronizer
>     r5  = 0xb6d3bbc8: <offset 0x018f6bc8> in /shared/projects/openjdk/jdk-jdk/output-fastdebug-arm/images/jdk/lib/server/libjvm.so at 0xb5445000
>     r6  = 0xffffffff is an unknown value
>     r7  = 0x0 is nullptr
>     r8  = 0x0000000a is an unknown value
>     r9  = 0x728a4308 is a thread
>     r10 = 0x0000000b is an unknown value
> ->  fp  = 0x753fe8cc in mmap'd memory region [0x75380000 - 0x75400000] by Thread Stack
>     r12 = 0x0 is nullptr
> ->  sp  = 0x753fe8b0 in mmap'd memory region [0x75380000 - 0x75400000] by Thread Stack
>     lr  = 0xb69bc1d0: <offset 0x015771d0> in /shared/projects/openjdk/jdk-jdk/output-fastdebug-arm/images/jdk/lib/server/libjvm.so at 0xb5445000
>     pc  = 0xb69c8670: <offset 0x01583670> in /shared/projects/openjdk/jdk-jdk/output-fastdebug-arm/images/jdk/lib/server/libjvm.so at 0xb5445000
> 
> 
> 
> The small caveat here is that NMT reporting needs ThreadCritical, and thus using it for location printing may block error reporting if it crashed inside a ThreadCritical section. We face the same issue today when printing the NMT report as part of the hs-err file. 
> 
> I think the usefulness of these printouts justify this risk. However I opened https://bugs.openjdk.org/browse/JDK-8304824 to investigate a better locking strategy for NMT.

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  review feedback roman

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13162/files
  - new: https://git.openjdk.org/jdk/pull/13162/files/d19d06ca..dcc1e631

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13162&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13162&range=06-07

  Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/13162.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13162/head:pull/13162

PR: https://git.openjdk.org/jdk/pull/13162

From stuefe at openjdk.org  Fri Mar 31 09:34:11 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 31 Mar 2023 09:34:11 GMT
Subject: RFR: JDK-8304815: Use NMT for more precise hs_err location
 printing [v7]
In-Reply-To: <dpOZaF1W5FfGiPl2Y3FMWBxB74wcE6i07e-vtElY_9Q=.c6729a07-e2cf-4257-99bd-403a63368137@github.com>
References: <DPqsrXUm5sJjcxDGZW6QSvdpu83LBhwXreIJU7LXqjI=.dfe3de5e-919a-494d-a8dd-0622d1ee0c65@github.com>
 <vqnP4aPirIfiVVmHN45Qht-FK1HeweJSywjO1YGb4So=.f54bfd01-8275-4a7d-a8c2-1af1db7e3d34@github.com>
 <dpOZaF1W5FfGiPl2Y3FMWBxB74wcE6i07e-vtElY_9Q=.c6729a07-e2cf-4257-99bd-403a63368137@github.com>
Message-ID: <afuPb4bVrMp07v8gndKaWytZbkarXz-cihuiCO12H2c=.0953bcf9-b55a-4b90-8a76-480222395afa@github.com>

On Fri, 31 Mar 2023 06:14:09 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   life->live
>
> Looks good to me. Feel free to clarify/name the two literals that I mentioned.
> Thanks,
> Roman

Thanks @rkennke !

Your remarks pointed me to a small possible problem where I was stepping through the address range in sizeof(MallocHeader) steps, but that size may theoretically be double the smallest granularity of malloc alignment, so I adjusted that.

I'll wait for the tests to finish, then push.

Cheers, Thomas

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13162#issuecomment-1491624980

From rrich at openjdk.org  Fri Mar 31 10:21:20 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Fri, 31 Mar 2023 10:21:20 GMT
Subject: RFR: 8296440: Remove Method* handling from
 cleanup_inline_caches_impl [v5]
In-Reply-To: <XO16zGJNQHrIkeUMk9jtFl0SJ76GT05PBJIJHajzpak=.ef90e88d-d6e1-479a-9d47-2f893dd6cd83@github.com>
References: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
 <sKZLs2RK8I6WtO2kco2VU4vg3QelVnE_jsyhHqZcSxI=.5caf4c6f-5534-44b5-b1af-e2c0c79b6c9e@github.com>
 <OyqQfTCCGsfbqPRSr5sG5yPB09GPjHm294IAL4Rk_H4=.f2653b16-ec96-471f-9d86-b31b9d89ef52@github.com>
 <XO16zGJNQHrIkeUMk9jtFl0SJ76GT05PBJIJHajzpak=.ef90e88d-d6e1-479a-9d47-2f893dd6cd83@github.com>
Message-ID: <h_v9Gweo5oKMVBMQCSiiSM5MbiH5hzOftGBM3WdO0Ds=.644d4081-0059-4dc0-b101-e173dfefbefd@github.com>

On Thu, 30 Mar 2023 15:33:34 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> I'm okay with the general approach. I'm a bit worried about it though.

I'm also not perfectly comfortable with it. Now even more so.

> With this approach, correct unloading of statically bound callsites relies on the dependency data used for deopt due to class loading, also implicitly embed enough information to deal with the unloading. Is there always a match? In order to answer that question we have to either walking all combinations of paths in which our compilers can generate a monomorphic callsite and see that it's correct, hope it doesn't break over time, and hope that the assert catches when it does, or we will end up crashing very intermittently in very obscure ways.

We might crash intermittently but not in obscure ways. We would hit the guarantee I left in CompiledMethod::cleanup_inline_caches_impl(). It would be clear that the statically bound call lacks the dependency to the target holder. IMHO `check_path_to_callee()` would be cheap enough to have it in release builds at least when resolving an optimized call to an interpreted callee (I'd consider static calls to be always reachable through CLD handles). This would make the crashes less intermittent.
It would be obscure though why the dependency is missing. Probably you meant that.

I agree it's really hard to reason about the paths in the compilers when they emit optimized virtual calls. I don't want to do it. I though I could establish the requirement that the call target dependency must exist and that it is easy to discover. It would be the responsibility of compiler providers to meet the requirement. But I understand now that this is not robust enough.

> I have spent a fair amount of time looking through the different paths in which you get to the decision point of generating a statically bound callsite, and I think that it is currently correct. But there are so many paths, I find it hard to follow them all.
> I would have preferred separating implicit dependency on all the reasons why a callsite became statically bound, with how to deal with correct unloading, so that it's easier to reason about it with certainty. For example, making sure there is an oop slot for each statically bound callsite, and when resolving the callsite, just ensure the holder oop is in there and register_nmethod() to the GC.

Ok, so the relocation for optimized virtual calls should point to an oop slot, right?

> We already have support for calling register_nmethod multiple times due to C1 mirror patching that does a similar trick.

I see. This is needed if, e.g., the patched oop is in the young region.

> Then we could algorithmically ensure that the logic works as expected, regardless of why the callsite became statically bound.
> Having said that, I'm okay with this approach too. We will probably run into the assert if something fishy happens, eventually. So I'll leave it to you to decide, and I'm okay with integrating as is.

So right now I don't feel like integrating the pr as it is.
I thought the approach was ok. In tests the call target holder is always reachable. I assumed we could even add it to CLD::_handles for the sake of robustness if the path is not found. It might look like a hack but given that in reality it is never done it still appears acceptable to me.

Anyways, thanks a lot for bearing that long with me.
Probably you're right. Every optimized call should refer to an oop slot for referencing the target.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12802#issuecomment-1491687576

From alanb at openjdk.org  Fri Mar 31 10:31:31 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 31 Mar 2023 10:31:31 GMT
Subject: RFR: 8304919: Implementation of Virtual Threads [v5]
In-Reply-To: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com>
Message-ID: <mboJdi0bvbB2gWhM-Gg7kf1cBj65mIk0N7LWYW1rX_M=.12ccdeae-8e0e-4763-975a-8d8025b24721@github.com>

> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview.
> 
> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently.
> 
> In addition, there are a small number of implementation changes to sync up from the loom fibers branch:
> 
> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where  end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly.
> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes.
> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs.
> - New system property to print a stack trace when a virtual thread sets its own value of a TL.
> - ThreadPerTaskExecutor is changed to use FutureTask.
> 
> Testing: tier1-6.

Alan Bateman 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:

 - Expand tests for jdk.ThreadSleep event
 - Review feedback
 - Merge
 - Fix ThreadSleepEvent again
 - Test updates
 - ThreadSleepEvent refactoring
 - Merge
 - Merge
 - Initial sync from fibers branch

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13203/files
  - new: https://git.openjdk.org/jdk/pull/13203/files/bfd2c816..722d5afa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13203&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13203&range=03-04

  Stats: 4799 lines in 134 files changed: 3144 ins; 1060 del; 595 mod
  Patch: https://git.openjdk.org/jdk/pull/13203.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13203/head:pull/13203

PR: https://git.openjdk.org/jdk/pull/13203

From mgronlun at openjdk.org  Fri Mar 31 11:18:23 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 31 Mar 2023 11:18:23 GMT
Subject: RFR: 8257967: JFR: Events for loaded agents [v15]
In-Reply-To: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
References: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
Message-ID: <5cFyTNQZjfRp6VlzOqkgdwhoSGaX92KNL3EZlv-NrpY=.fae84f7f-f1d4-4354-a123-33ab97928dcf@github.com>

> Greetings,
> 
> We are adding support to let JFR report on Agents.
> 
> #### Design
> 
> An Agent is a library that uses any instrumentation or profiling APIs. Most agents are started and initialized on the command line, but agents can also be loaded dynamically during runtime. Because command line agents initialize during the VM startup sequence, they add to the overall startup time latency in getting the VM ready. The events will report on the time the agent took to initialize.
> 
> A JavaAgent is an agent written in the Java programming language, using the APIs in the package [java.lang.instrument](https://docs.oracle.com/en/java/javase/19/docs/api/java.instrument/java/lang/instrument/package-summary.html)
> 
> A JavaAgent is sometimes called a JPLIS agent, where the acronym JPLIS stands for Java Programming Language Instrumentation Services.
> 
> To report on JavaAgents, JFR will add the new event type jdk.JavaAgent and events will look similar to these two examples:
> 
> // Command line
> jdk.JavaAgent {
>   startTime = 12:31:19.789 (2023-03-08)
>   name = "JavaAgent.jar"
>   options = "foo=bar"
>   dynamic = false
>   initializationTime = 12:31:15.574 (2023-03-08)
>   initializationDuration = 172 ms
> }
> 
> // Dynamic load
> jdk.JavaAgent {
>   startTime = 12:31:31.158 (2023-03-08)
>   name = "JavaAgent.jar"
>   options = "bar=baz"
>   dynamic = true
>   initializationTime = 12:31:31.037 (2023-03-08)
>   initializationDuration = 64,1 ms
> }
> 
> The jdk.JavaAgent event type is a JFR periodic event that iterates over running Java agents.
> 
> For a JavaAgent event, the agent's name will be the specific .jar file containing the instrumentation code. The options will be the specific options passed to the .jar file as part of launching the agent, for example, on the command line: -javaagent: JavaAgent.jar=foo=bar.
> 
> The "dynamic" field denotes if the agent was loaded via the command line (dynamic = false) or dynamically (dynamic = true)
> 
> "initializationTime" is the timestamp the JVM invoked the initialization method, and "initializationDuration" is the duration of executing the initialization method.
> 
> "startTime" represents the time the JFR framework issued the periodic event; hence "initializationTime" will be earlier than "startTime".
> 
> An agent can also be written in a native programming language using the [JVM Tools Interface (JVMTI)](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html). This kind of agent, sometimes called a native agent, is a platform-specific binary, sometimes referred to as a library, but here it means a .so or .dll file.
> 
> To report on native agents, JFR will add the new event type jdk.NativeAgent and events will look similar to this example:
> 
> jdk.NativeAgent {
>   startTime = 12:31:40.398 (2023-03-08)
>   name = "jdwp"
>   options = "transport=dt_socket,server=y,address=any,onjcmd=y"
>   dynamic = false
>   initializationTime = 12:31:36.142 (2023-03-08)
>   initializationDuration = 0,00184 ms
>   path = "c:\ade\github\openjdk\jdk\build\windows-x86_64-server-slowdebug\jdk\bin\jdwp.dll"
> }
> 
> The layout of the event type is very similar to the jdk.JavaAgent event, but here the path to the native library is reported.
> 
> The initialization of a native agent is performed by invoking an agent-specified callback routine. The "initializationTime" is when the JVM sent or would have sent the JVMTI VMInit event to a specified callback. "initializationDuration" is the duration to execute that specific callback. If no callback is specified for the JVMTI VMInit event, the "initializationDuration" will be 0. If the agent is loaded dynamically, "initializationDuration" is the time taken to execute the Agent_OnAttach callback.
> 
> #### Implementation
> 
> There has not existed a reification of a JavaAgent directly in the JVM, as these are built on top of the JDK native library, "instrument", using a many-to-one mapping. At the level of the JVM, the only representation of agents after startup is through JvmtiEnv's, which agents request from the JVM during startup and initialization ? as such, mapping which JvmtiEnv belongs to what JavaAgent was not possible before.
> 
> Using implementation details of how the JDK native library "instrument" interacts with the JVM, we can build this mapping to track what JvmtiEnv's "belong" to what JavaAgent. This mapping now lets us report the Java-relevant context (name, options) and measure the time it takes for the JavaAgent to initialize.
> 
> When implementing this capability, it was necessary to refactor the code used to represent agents, AgentLibrary. The previous implementation was located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp.
> 
> The refactoring isolates the relevant logic into two new modules, prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their older places will help reduce the sizes of oversized arguments.cpp and threads.cpp.
> 
> The previous two lists that maintained "agents" (JVMTI) and "libraries" (Xrun) were not thread-safe for concurrent iterations. A single list that allows for concurrent iterations is therefore introduced.
> 
> Testing: jdk_jfr, tier 1 - 6
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  fixes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12923/files
  - new: https://git.openjdk.org/jdk/pull/12923/files/ab74621b..07407a82

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12923&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12923&range=13-14

  Stats: 5 lines in 2 files changed: 2 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12923.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12923/head:pull/12923

PR: https://git.openjdk.org/jdk/pull/12923

From mgronlun at openjdk.org  Fri Mar 31 11:18:25 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 31 Mar 2023 11:18:25 GMT
Subject: RFR: 8257967: JFR: Events for loaded agents [v14]
In-Reply-To: <SlBgA47Ol9dsutVMPVrL8gPi2XvHYklQN-euhTxNxwM=.fffba227-5fa7-4b75-bd57-6343a1eea458@github.com>
References: <vpWixqUNW2MCfeYwdQKFMuVyZuWthbRkaoPleduwg64=.6c9f0a1c-9b3e-4343-8299-26824b17700e@github.com>
 <kooNn-2wsfn3v-nibYXs3B73wolCj3OsqHBur3gjv_8=.3ebc9e98-f40d-4d07-9515-05d30829abdc@github.com>
 <SlBgA47Ol9dsutVMPVrL8gPi2XvHYklQN-euhTxNxwM=.fffba227-5fa7-4b75-bd57-6343a1eea458@github.com>
Message-ID: <KgpjBMFZWA9cWgJb1jTKAGvWfCf_kP_a4tcBvt9POAc=.e89b53bd-c5de-4e5b-9959-55dcb9502a4c@github.com>

On Fri, 31 Mar 2023 03:05:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   restore misssing frees
>
> src/hotspot/share/prims/agent.cpp line 533:
> 
>> 531:     if (thread->is_pending_jni_exception_check()) {
>> 532:       thread->clear_pending_jni_exception_check();
>> 533:     }
> 
> Unsure why we pretend the agent checked this - don't we want -Xcheck:jni to report a bug in the agent?

Good question - I don't know. For dynamically loaded agents, there seems to be quite a lot of handling to return a JNI_OK, even though the agent failed to load or returned failure from the Agent_OnAttach. e.g.

  // Agent_OnAttach executed so completion status is JNI_OK
  return JNI_OK;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12923#discussion_r1154346856

From mcimadamore at openjdk.org  Fri Mar 31 12:16:22 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 31 Mar 2023 12:16:22 GMT
Subject: RFR: 8304265: Implementation of Foreign Function and Memory API
 (Third Preview) [v16]
In-Reply-To: <p9ijGq25fS1pue7aXoUfsKjc76t-oHcssoKtXRE7c_s=.a5e3a921-ed1d-4d39-aebc-6a7b590b5bdc@github.com>
References: <w8Pki5Wc1cM_TtkfovSpisnMAPRv2CO0FCa5RgwNFDU=.33522cd6-c9e0-4c11-818f-9d559308fd91@github.com>
 <p9ijGq25fS1pue7aXoUfsKjc76t-oHcssoKtXRE7c_s=.a5e3a921-ed1d-4d39-aebc-6a7b590b5bdc@github.com>
Message-ID: <ICq8Db2xl1tEwKoDV2uhyNp2h6mmRIpInc4_9_gZzKg=.02fa2afa-4c53-41bb-84fe-50a6677a3894@github.com>

On Thu, 30 Mar 2023 11:28:25 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> API changes for the FFM API (third preview)
>> 
>> Specdiff:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html
>> 
>> Javadoc:
>> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.html
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
>    
>    Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
>  - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
>    
>    Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

The class `jdk/internal/javac/PreviewFeature.java` needs to be updated. It is currently referring JEP 434:


public enum Feature {
        @JEP(number=433, title="Pattern Matching for switch", status="Fourth Preview")
        SWITCH_PATTERN_MATCHING(),
        @JEP(number=432, title="Record Patterns", status="Second Preview")
        RECORD_PATTERNS,
        @JEP(number=436, title="Virtual Threads", status="Second Preview")
        VIRTUAL_THREADS,
        @JEP(number=434, title="Foreign Function & Memory API", status="Second Preview")
        FOREIGN, // <-----------------------------------
        ...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13079#issuecomment-1491836954

From qamai at openjdk.org  Fri Mar 31 12:25:16 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 31 Mar 2023 12:25:16 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v6]
In-Reply-To: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
Message-ID: <XaGFwLWuas69dM_Ndx_ei3ZEIX8Xur-1OwDhuoCkiKk=.73312b51-b9a2-4586-bdde-c4016b36b042@github.com>

> Hi,
> 
> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, VectorShuffle is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
> 
> 1. Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
> 2. Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
> 3. Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
> 4. Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
> 
> Upon these changes, a `rearrange` can emit more efficient code:
> 
>     var species = IntVector.SPECIES_128;
>     var v1 = IntVector.fromArray(species, SRC1, 0);
>     var v2 = IntVector.fromArray(species, SRC2, 0);
>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
> 
>     Before:
>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>     vmovdqu 0x10(%r10),%xmm2
>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>     vmovdqu 0x10(%r10),%xmm1
>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>     vmovdqu 0x10(%r10),%xmm0
>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>                                                             ;   {external_word}
>     vpackusdw %xmm0,%xmm0,%xmm0
>     vpackuswb %xmm0,%xmm0,%xmm0
>     vpmovsxbd %xmm0,%xmm3
>     vpcmpgtd %xmm3,%xmm1,%xmm3
>     vtestps %xmm3,%xmm3
>     jne    0x00007fc2acb4e0d8
>     vpmovzxbd %xmm0,%xmm0
>     vpermd %ymm2,%ymm0,%ymm0
>     movabs $0x751588f98,%r10            ;   {oop([I{0x0000000751588f98})}
>     vmovdqu %xmm0,0x10(%r10)
> 
>     After:
>     movabs $0x751589c78,%r10            ;   {oop([I{0x0000000751589c78})}
>     vmovdqu 0x10(%r10),%xmm1
>     movabs $0x75158ac88,%r10            ;   {oop([I{0x000000075158ac88})}
>     vmovdqu 0x10(%r10),%xmm2
>     vpxor  %xmm0,%xmm0,%xmm0
>     vpcmpgtd %xmm2,%xmm0,%xmm3
>     vtestps %xmm3,%xmm3
>     jne    0x00007fa818b27cb1
>     vpermd %ymm1,%ymm2,%ymm0
>     movabs $0x751588c68,%r10            ;   {oop([I{0x0000000751588c68})}
>     vmovdqu %xmm0,0x10(%r10)
>     
> Please take a look and leave reviews. Thanks a lot.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  small cosmetics

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13093/files
  - new: https://git.openjdk.org/jdk/pull/13093/files/a4835c00..97c8fabf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13093&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13093&range=04-05

  Stats: 6 lines in 4 files changed: 1 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/13093.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13093/head:pull/13093

PR: https://git.openjdk.org/jdk/pull/13093

From qamai at openjdk.org  Fri Mar 31 12:25:24 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 31 Mar 2023 12:25:24 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v5]
In-Reply-To: <MEr60_T2IVbV5WspV4SNDTmp4h38xjs1xi94alz3suw=.f45285a0-0c56-4e7a-b44b-9fca23caa145@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
 <oiRTNlsfJ4A5EbcwbqaFSv9DpYutUZv2rLfrOS0ti60=.1d3d4123-b04c-4e24-85cf-3ba8eb5933c8@github.com>
 <MEr60_T2IVbV5WspV4SNDTmp4h38xjs1xi94alz3suw=.f45285a0-0c56-4e7a-b44b-9fca23caa145@github.com>
Message-ID: <vA5WfADFdG_fLcR1vSr-nwP52482Sx0n223b8WQx2fY=.f9f12e65-8f01-4594-8430-20afe87c94db@github.com>

On Fri, 31 Mar 2023 00:18:21 GMT, Paul Sandoz <psandoz 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 14 commits:
>> 
>>  - move implementations up
>>  - Merge branch 'master' into shufflerefactor
>>  - Merge branch 'master' into shufflerefactor
>>  - reviews
>>  - missing casts
>>  - clean up
>>  - fix Matcher::vector_needs_load_shuffle
>>  - fix internal types, clean up
>>  - optimise laneIsValid
>>  - Merge branch 'master' into shufflerefactor
>>  - ... and 4 more: https://git.openjdk.org/jdk/compare/d063b896...a4835c00
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-VectorBits.java.template line 1106:
> 
>> 1104:         @Override
>> 1105:         @ForceInline
>> 1106:         public int laneSource(int i) {
> 
> Can this method be moved to `AbstractShuffle`?

No because `T lane(int)` is a method of the typed vector classes which is not available in `AbstractVector`

> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-VectorBits.java.template line 1158:
> 
>> 1156:         }
>> 1157: 
>> 1158:         private static $bitstype$[] prepare(int[] indices, int offset) {
> 
> If we want to reduce code duplication further I suspect we could move these static methods to IntVector etc. Up to you.

I think duplication of generated code is less of a concern so it may be more desirable to keep them in the shuffle classes and near their usages.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1154405710
PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1154407372

From qamai at openjdk.org  Fri Mar 31 12:25:18 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 31 Mar 2023 12:25:18 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v2]
In-Reply-To: <DAnlsKJ-3aNZZWnvP2j_J59dpX_wzor1IM6dY0bie1Q=.ddf68a3d-59bf-4108-959f-8dc50c095e45@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
 <lmW05NgITkLuyzWlWENcX_wEhObY5BRk6L-JyK4LfVg=.817c80e5-92ac-4b9b-9001-1ff1d97a38a4@github.com>
 <zkYQ_5LR47PqQ8nV7TZefUlWENFR-ZHvQx5LWWDhc4E=.b3217ca6-695e-45b2-a748-aa855ac05904@github.com>
 <DAnlsKJ-3aNZZWnvP2j_J59dpX_wzor1IM6dY0bie1Q=.ddf68a3d-59bf-4108-959f-8dc50c095e45@github.com>
Message-ID: <SJ43Df0YCNY9RPAkyZVL0mGqTACDJcOV3K1RRuiiSls=.d915cc38-c383-4c1b-832d-e5819b78d0d7@github.com>

On Tue, 21 Mar 2023 16:29:44 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> I have moved most of the methods to `AbstractVector` and `AbstractShuffle`, I have to resort to raw types, though, since there seems to be no way to do the same with wild cards, and the generics mechanism is not powerful enough for things like `Vector<E.integral>`. The remaining failure seems to be related to [JDK-8304676](https://bugs.openjdk.org/projects/JDK/issues/JDK-8304676), so I think this patch is ready for review now.
>> 
>>> The mask implementation is specialized by the species of vectors it operates on, but does it have to be
>> 
>> Apart from the mask implementation, shuffle implementation definitely has to take into consideration the element type. However, this information does not have to be visible to the API, similar to how we currently handle the vector length, we can have `class AbstractMask<E> implements VectorMask`. As a result, the cast method would be useless and can be removed in the API, but our implementation details would still use it, for example
>> 
>>     Vector<E> blend(Vector<E> v, VectorMask w) {
>>         AbstractMask<?> aw = (AbstractMask<?>) w;
>>         AbstractMask<E> tw = aw.cast(vspecies());
>>         return VectorSupport.blend(...);
>>     }
>> 
>>     Vector<E> rearrange(VectorShuffle s) {
>>         AbstractShuffle<?> as = (AbstractShuffle<?>) s;
>>         AbstractShuffle<E> ts = s.cast(vspecies());
>>         return VectorSupport.rearrangeOp(...);
>>     }
>> 
>> What do you think?
>
>> Apart from the mask implementation, shuffle implementation definitely has to take into consideration the element type.
> 
> Yes, the way you have implemented shuffle is tightly connected, that looks ok.
> 
> I am wondering if we can make the mask implementation more loosely coupled and modified such that it does not have to take into consideration the element type (or species) of the vector it operates on, and instead compatibility is based solely on the lane count.
> 
> Ideally it would be good to change the `VectorMask::check` method to just compare the lanes counts and not require a cast in the implementation, which i presume requires some deeper changes in C2?
> 
> What you propose seems a possible a interim step towards a more preferable API, if the performance is good.

Thanks @PaulSandoz and @XiaohongGong for the reviews and testings.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13093#issuecomment-1491844652

From duke at openjdk.org  Fri Mar 31 13:40:11 2023
From: duke at openjdk.org (Fredrik Bredberg)
Date: Fri, 31 Mar 2023 13:40:11 GMT
Subject: RFR: 8305247: On RISC-V generate_fixed_frame() sometimes generate a
 relativized locals value which is way too large.
Message-ID: <PhiQEMSwC9S4Yu8w5zKCCT5VPP8WqBOlle-n4gxOkCA=.eaec2422-6372-43a3-8241-0b8382a30384@github.com>

The relativized locals value is supposed to contain the distance between the frame pointer and the local variables in an interpreter frame, expressed in number of words. It typically contains the value "frame::sender_sp_offset + padding + max_locals - 1"

On most architectures sender_sp_offset is 2. This gives us the value "1 + padding + max_locals", which is always greater or equal to 1.

However on RISC-V the value of frame::sender_sp_offset is 0, which means that if we don't have any padding and no local variables we end up with a relativized_locals value of -1.

When generate_fixed_frame() calculates the relativized_locals value it subtracts the frame pointer from the xlocals and then logically shifts the result right by Interpreter::logStackElementSize (to convert it into a word index).

This works fine on all platforms (except RISC-V), because the subtraction will never become negative. But since the subtraction can end up negative on RISC-V, the shift instruction must be a arithmetic-shift-right (not a logical-shift-right) to preserve the sign and not end up with a very large positive index.

This is currently not a real problem since the relativized_locals value is not used if max_local is zero, which is the only case the value is wrong.

It is however a real problem when implementing JDK-8300197.

The bug was introduced in JDK-8299795 and is fixed by changing a "srli" instruction to a "srai" in generate_fixed_frame().

-------------

Commit messages:
 - 8305247: On RISC-V generate_fixed_frame() sometimes generate a relativized locals value which is way too large.

Changes: https://git.openjdk.org/jdk/pull/13245/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13245&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305247
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13245.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13245/head:pull/13245

PR: https://git.openjdk.org/jdk/pull/13245

From duke at openjdk.org  Fri Mar 31 13:42:16 2023
From: duke at openjdk.org (Fredrik Bredberg)
Date: Fri, 31 Mar 2023 13:42:16 GMT
Subject: RFR: 8305247: On RISC-V generate_fixed_frame() sometimes generate
 a relativized locals value which is way too large.
In-Reply-To: <PhiQEMSwC9S4Yu8w5zKCCT5VPP8WqBOlle-n4gxOkCA=.eaec2422-6372-43a3-8241-0b8382a30384@github.com>
References: <PhiQEMSwC9S4Yu8w5zKCCT5VPP8WqBOlle-n4gxOkCA=.eaec2422-6372-43a3-8241-0b8382a30384@github.com>
Message-ID: <t8wehTYfwdP2n2idxm4x65gzyEzZQHi0LqtaRztGkPc=.8bec93f4-8db8-414e-81ac-5d7fb32438de@github.com>

On Thu, 30 Mar 2023 12:57:23 GMT, Fredrik Bredberg <duke at openjdk.org> wrote:

> The relativized locals value is supposed to contain the distance between the frame pointer and the local variables in an interpreter frame, expressed in number of words. It typically contains the value "frame::sender_sp_offset + padding + max_locals - 1"
> 
> On most architectures sender_sp_offset is 2. This gives us the value "1 + padding + max_locals", which is always greater or equal to 1.
> 
> However on RISC-V the value of frame::sender_sp_offset is 0, which means that if we don't have any padding and no local variables we end up with a relativized_locals value of -1.
> 
> When generate_fixed_frame() calculates the relativized_locals value it subtracts the frame pointer from the xlocals and then logically shifts the result right by Interpreter::logStackElementSize (to convert it into a word index).
> 
> This works fine on all platforms (except RISC-V), because the subtraction will never become negative. But since the subtraction can end up negative on RISC-V, the shift instruction must be a arithmetic-shift-right (not a logical-shift-right) to preserve the sign and not end up with a very large positive index.
> 
> This is currently not a real problem since the relativized_locals value is not used if max_local is zero, which is the only case the value is wrong.
> 
> It is however a real problem when implementing JDK-8300197.
> 
> The bug was introduced in JDK-8299795 and is fixed by changing a "srli" instruction to a "srai" in generate_fixed_frame().

Hi @RealFYang can you verify that this PR works on RISC-V?
I've done sanity checking using Qemu, but nothing extensive.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13245#issuecomment-1491942226

From rkennke at openjdk.org  Fri Mar 31 13:54:47 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 31 Mar 2023 13:54:47 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v48]
In-Reply-To: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
Message-ID: <fbzWu2Ud-ct0lQwFm7X5tnBQe8uXHi837kN8D60sVGU=.b7420c51-5f13-43ac-baac-032362ec72a8@github.com>

> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
> 
> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p
 rotocols.
> 
> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare.
> 
> 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
> 
> 
> Testing:
>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
> 
> ### Performance
> 
> #### Simple Microbenchmark
> 
> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
> 
> |  | x86_64 | aarch64 |
> | -- | -- | -- |
> | -UseFastLocking | 20.651 | 20.764 |
> | +UseFastLocking | 18.896 | 18.908 |
> 
> 
> #### Renaissance
> 
> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
> -- | -- | -- | -- | -- | -- | -- | --
> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%

Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:

 - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
 - Check underflow, top-of-stack and mark-bits for sanity, in fast_unlock() (aarch64)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10907/files
  - new: https://git.openjdk.org/jdk/pull/10907/files/adeccaae..0e366206

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=47
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=46-47

  Stats: 39 lines in 4 files changed: 36 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10907.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10907/head:pull/10907

PR: https://git.openjdk.org/jdk/pull/10907

From stuefe at openjdk.org  Fri Mar 31 14:03:49 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 31 Mar 2023 14:03:49 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v16]
In-Reply-To: <5YPjVZsQAVVL9PHaGu7Mc7kNE0WvPrsiCubKSGzKxvk=.78e8f8fb-1005-4bd7-9ad1-d1dd3aacbe04@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <5YPjVZsQAVVL9PHaGu7Mc7kNE0WvPrsiCubKSGzKxvk=.78e8f8fb-1005-4bd7-9ad1-d1dd3aacbe04@github.com>
Message-ID: <jre0UkdGnI3-DJCOgTPcGi0vhuOF1eZZk1xKyMGJSoI=.38d1620d-6215-4046-91d1-c726031c1635@github.com>

On Tue, 28 Mar 2023 19:50:36 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
>> 
>> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
>> 
>> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
>> 
>> The PPC port was provided by @reinrich, RISCV was provided by @DingliZhang and @zifeihan, and S390x by @offamitkumar.
>> 
>> This change supports the following platforms: x86, aarch64, PPC, RISCV, and S390x
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   s390x NULL to nullptr

This obviously breaks arm, since its implementation is missing. I opened https://bugs.openjdk.org/browse/JDK-8305387 to track this. This is unfortunate since it holds work on arm in other areas, in my case for https://github.com/openjdk/jdk/pull/10907.

> This change supports the following platforms: x86, aarch64, PPC, RISCV, and S390x

I wonder about the explicit exclusion of arm. Every other CPU seems to be taken care of, even those Oracle does not maintain. Just curious, was there a special reason for excluding arm?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12778#issuecomment-1491971108

From duke at openjdk.org  Fri Mar 31 14:16:18 2023
From: duke at openjdk.org (Afshin Zafari)
Date: Fri, 31 Mar 2023 14:16:18 GMT
Subject: RFR: 8297539: Use PrimitiveConversions::cast for local uses of the
 int<->float union conversion trick [v3]
In-Reply-To: <G-5LtgbfGtU9-nV-ZZabCKUweEyWnLZPIu8vWv644fQ=.a6c13bee-4eb6-4901-b1a2-d4a4fc93ebad@github.com>
References: <Fc1LufRzwqeQjXSwyVm3FaJWzbaazUXyArTYPLlGrwM=.034cb09b-79d8-49a1-a68d-b5914a9cc214@github.com>
 <NH7fN3_RxyiIv033c7qocb32V083AannceliXFwkFVo=.507eb435-2c6a-4591-a907-88c4c756b6ad@github.com>
 <G-5LtgbfGtU9-nV-ZZabCKUweEyWnLZPIu8vWv644fQ=.a6c13bee-4eb6-4901-b1a2-d4a4fc93ebad@github.com>
Message-ID: <53W_Aa1VHo_JZ8tfTQyTjyRzF1YAJoAr1JxUpjD9RCA=.a7802057-3712-4aad-8baa-e6c19a8ae3f6@github.com>

On Tue, 28 Mar 2023 15:27:28 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8297539: Use PrimitiveConversions::cast for local uses of the int<->float union conversion trick
>
> src/hotspot/cpu/arm/assembler_arm.hpp line 288:
> 
>> 286:     override bool f_lo_is_null() const { return (_bits & ((1 << 19) - 1)) == 0; }
>> 287:     override int e() const { return ((_bits << 1) >> (23+1)) - 127; }
>> 288:     override unsigned int s() const { return _bits >> 31; }
> 
> This shouldn't compile? I think `override` should be after the declarator, so between `const` and the
> function body in all of these.

I fixed it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13136#discussion_r1154529947

From dnsimon at openjdk.org  Fri Mar 31 14:31:48 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 31 Mar 2023 14:31:48 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v16]
In-Reply-To: <5YPjVZsQAVVL9PHaGu7Mc7kNE0WvPrsiCubKSGzKxvk=.78e8f8fb-1005-4bd7-9ad1-d1dd3aacbe04@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <5YPjVZsQAVVL9PHaGu7Mc7kNE0WvPrsiCubKSGzKxvk=.78e8f8fb-1005-4bd7-9ad1-d1dd3aacbe04@github.com>
Message-ID: <eqVedJ87DGNnl4-_ycDW9_nF7olubhq8FskKkv-Vep4=.5e150364-4e84-462d-a537-9c6a41a144aa@github.com>

On Tue, 28 Mar 2023 19:50:36 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
>> 
>> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
>> 
>> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
>> 
>> The PPC port was provided by @reinrich, RISCV was provided by @DingliZhang and @zifeihan, and S390x by @offamitkumar.
>> 
>> This change supports the following platforms: x86, aarch64, PPC, RISCV, and S390x
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   s390x NULL to nullptr

It has also broken GraalVM Native Image. I'll open a JBS issue with a reproducer soon but here's hs-err from a slowdebug JDK build showing the problem:
[hs_err_pid30379.log](https://github.com/openjdk/jdk/files/11122818/hs_err_pid30379.log)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12778#issuecomment-1492011186

From stuefe at openjdk.org  Fri Mar 31 14:41:52 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 31 Mar 2023 14:41:52 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v48]
In-Reply-To: <fbzWu2Ud-ct0lQwFm7X5tnBQe8uXHi837kN8D60sVGU=.b7420c51-5f13-43ac-baac-032362ec72a8@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <fbzWu2Ud-ct0lQwFm7X5tnBQe8uXHi837kN8D60sVGU=.b7420c51-5f13-43ac-baac-032362ec72a8@github.com>
Message-ID: <mAqIC1kOnJBjc5Y512CdOJc3-SAifOyTLTqX6U3txJg=.6f18521f-51f3-41cc-8f2b-4a2f158c8c52@github.com>

On Fri, 31 Mar 2023 13:54:47 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>  - Check underflow, top-of-stack and mark-bits for sanity, in fast_unlock() (aarch64)

Here the ARM port. Applies cleanly atop of 0e3662066ead1bc8883fc0c32dce9f795ecd7c9d.

https://github.com/tstuefe/jdk/tree/ARM-port-8291555

https://github.com/openjdk/jdk/commit/4c6f5abec58d6a10d3f1eb010f10d00c3cabb43a

Differences to other ports:

- I don't have as many registers (only 15). Therefore I almost always need to push at least one. My variants of MA::fast_(un)lock take care of this - you pass in a save mask to tell it which temps to save, also handy for error analysis. Multi-pushes are not combined though, but I don't think there is no need to make this more elaborate).
- I moved the MW loads down into MA::fast_(un)lock. No need to do this at the caller site, nothing saved by that.
- In MA::fast_lock, I use a combination of `bic` and `orr` to prepare new and old headers. The advantage is that it gives me added safety against accidentally passing in "11" marked MWs, at no added cost.
- In MA::fast_unlock, I also use `bic`, since it allows denser opcode. I cannot express easily ~lockmask immediate.
- In MA::fast_(un)lock, I poison supposed temp regs in debug. I leave them alone in release.

Performance:

With C2, a lot better than the old solution - about 30%. The reason is a bug in the old solution that causes the JVM to enter the slow path for every monitorexit. Should fix this separately.

I tested the ARM port based on an older version of your patch; however, unfortunately ARM is broken due to an unrelated problem (https://github.com/openjdk/jdk/pull/12778), therefore I cannot test it against your new patch variant.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1492026658

From iveresov at openjdk.org  Fri Mar 31 14:57:15 2023
From: iveresov at openjdk.org (Igor Veresov)
Date: Fri, 31 Mar 2023 14:57:15 GMT
Subject: RFR: 8305066: [JVMCI] guarantee(ik->is_initialized()) failed:
 java/lang/Long$LongCache must be initialized
In-Reply-To: <4MoN5JJV_aGKkgXXYCX0sgHkNc4fXnyWgS7emWRi0xg=.cfdff0ab-9420-437b-a57f-cfa5ca9a8051@github.com>
References: <4MoN5JJV_aGKkgXXYCX0sgHkNc4fXnyWgS7emWRi0xg=.cfdff0ab-9420-437b-a57f-cfa5ca9a8051@github.com>
Message-ID: <CK7Dt4WBghTNgeLLsOq84OkfrbOVvw4AGslHUk7rv9k=.2ab484bc-8819-4ef4-aab4-e5850622705f@github.com>

On Wed, 29 Mar 2023 13:44:24 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> Class initialization can fail for the boxing caches such as `Long$LongCache` due to things such as a `StackOverflowError`.
> When rematerializing boxed values during deoptimization, a failed cache initialization must be handled. This PR handles it by throwing an OOME which is always semantically correct.
> 
> Note that a VM with a broken boxing cache is going to be in a fairly miserable state (i.e. throwing `NoClassDefFoundError` on every call to `Long.valueOf`) so the OOME shouldn't cause any noticeable problem.

Looks ok

-------------

Marked as reviewed by iveresov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13229#pullrequestreview-1367102761

From dnsimon at openjdk.org  Fri Mar 31 15:27:47 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 31 Mar 2023 15:27:47 GMT
Subject: RFR: 8305066: [JVMCI] guarantee(ik->is_initialized()) failed:
 java/lang/Long$LongCache must be initialized
In-Reply-To: <CK7Dt4WBghTNgeLLsOq84OkfrbOVvw4AGslHUk7rv9k=.2ab484bc-8819-4ef4-aab4-e5850622705f@github.com>
References: <4MoN5JJV_aGKkgXXYCX0sgHkNc4fXnyWgS7emWRi0xg=.cfdff0ab-9420-437b-a57f-cfa5ca9a8051@github.com>
 <CK7Dt4WBghTNgeLLsOq84OkfrbOVvw4AGslHUk7rv9k=.2ab484bc-8819-4ef4-aab4-e5850622705f@github.com>
Message-ID: <cEtXPCUNPDmu_Pm7J2HXncL0Q9X7VEya41ukteNaLEI=.895a31db-f609-4216-8d4f-59d92735a1b1@github.com>

On Fri, 31 Mar 2023 14:54:52 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> Class initialization can fail for the boxing caches such as `Long$LongCache` due to things such as a `StackOverflowError`.
>> When rematerializing boxed values during deoptimization, a failed cache initialization must be handled. This PR handles it by throwing an OOME which is always semantically correct.
>> 
>> Note that a VM with a broken boxing cache is going to be in a fairly miserable state (i.e. throwing `NoClassDefFoundError` on every call to `Long.valueOf`) so the OOME shouldn't cause any noticeable problem.
>
> Looks ok

Thanks @veresov and @tkrodriguez for reviewing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13229#issuecomment-1492115487

From dnsimon at openjdk.org  Fri Mar 31 15:27:50 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 31 Mar 2023 15:27:50 GMT
Subject: Integrated: 8305066: [JVMCI] guarantee(ik->is_initialized()) failed:
 java/lang/Long$LongCache must be initialized
In-Reply-To: <4MoN5JJV_aGKkgXXYCX0sgHkNc4fXnyWgS7emWRi0xg=.cfdff0ab-9420-437b-a57f-cfa5ca9a8051@github.com>
References: <4MoN5JJV_aGKkgXXYCX0sgHkNc4fXnyWgS7emWRi0xg=.cfdff0ab-9420-437b-a57f-cfa5ca9a8051@github.com>
Message-ID: <yVnLc3LoL8IO9P668jBRadEMOL_Drk2UFS7mIA6X3rM=.c0a830c3-91da-4f0e-a8eb-86145de3e743@github.com>

On Wed, 29 Mar 2023 13:44:24 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> Class initialization can fail for the boxing caches such as `Long$LongCache` due to things such as a `StackOverflowError`.
> When rematerializing boxed values during deoptimization, a failed cache initialization must be handled. This PR handles it by throwing an OOME which is always semantically correct.
> 
> Note that a VM with a broken boxing cache is going to be in a fairly miserable state (i.e. throwing `NoClassDefFoundError` on every call to `Long.valueOf`) so the OOME shouldn't cause any noticeable problem.

This pull request has now been integrated.

Changeset: e0126850
Author:    Doug Simon <dnsimon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e012685051cb8dbac1a6dd459a6e445c896e76ef
Stats:     58 lines in 4 files changed: 26 ins; 9 del; 23 mod

8305066: [JVMCI] guarantee(ik->is_initialized()) failed: java/lang/Long$LongCache must be initialized

Reviewed-by: never, iveresov

-------------

PR: https://git.openjdk.org/jdk/pull/13229

From matsaave at openjdk.org  Fri Mar 31 15:36:59 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Fri, 31 Mar 2023 15:36:59 GMT
Subject: RFR: 8301995: Move invokedynamic resolution information out of
 ConstantPoolCacheEntry [v16]
In-Reply-To: <5YPjVZsQAVVL9PHaGu7Mc7kNE0WvPrsiCubKSGzKxvk=.78e8f8fb-1005-4bd7-9ad1-d1dd3aacbe04@github.com>
References: <sq2lNF8Zc5Xy4EE-c-AfoQfCUWO7JjHEuPoMYqjIvAA=.ed919adb-fc80-4191-bfef-3f313788b0d3@github.com>
 <5YPjVZsQAVVL9PHaGu7Mc7kNE0WvPrsiCubKSGzKxvk=.78e8f8fb-1005-4bd7-9ad1-d1dd3aacbe04@github.com>
Message-ID: <PK0dGClZcMANUuw8bqVG7CvOhWTWYsytbJZSH7eI8t4=.e1274720-c236-4076-bae4-e074b80a4145@github.com>

On Tue, 28 Mar 2023 19:50:36 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. 
>> 
>> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend.  Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array.
>> 
>> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests.
>> 
>> The PPC port was provided by @reinrich, RISCV was provided by @DingliZhang and @zifeihan, and S390x by @offamitkumar.
>> 
>> This change supports the following platforms: x86, aarch64, PPC, RISCV, and S390x
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   s390x NULL to nullptr

> This obviously breaks arm, since its implementation is missing. I opened https://bugs.openjdk.org/browse/JDK-8305387 to track this. This is unfortunate since it holds work on arm in other areas, in my case for #10907.
> 
> > This change supports the following platforms: x86, aarch64, PPC, RISCV, and S390x
> 
> I wonder about the explicit exclusion of arm. Every other CPU seems to be taken care of, even those Oracle does not maintain. Just curious, was there a special reason for excluding arm?

There is no special reason ARM32 was excluded other than the fact no porter has picked it up yet. Fortunately I was able to get in contact with porters for the other platforms, but nobody took on the ARM port until now. Thank you for opening the issue!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12778#issuecomment-1492144686

From stuefe at openjdk.org  Fri Mar 31 16:01:01 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 31 Mar 2023 16:01:01 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v48]
In-Reply-To: <fbzWu2Ud-ct0lQwFm7X5tnBQe8uXHi837kN8D60sVGU=.b7420c51-5f13-43ac-baac-032362ec72a8@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <fbzWu2Ud-ct0lQwFm7X5tnBQe8uXHi837kN8D60sVGU=.b7420c51-5f13-43ac-baac-032362ec72a8@github.com>
Message-ID: <hw22plMwnZ_WRGZJs4XONEPrUM3V3bG62yIyJ5pSb08=.90c051ed-eee4-4957-9f4e-1834192ae273@github.com>

On Fri, 31 Mar 2023 13:54:47 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>  - Check underflow, top-of-stack and mark-bits for sanity, in fast_unlock() (aarch64)

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 6264:

> 6262:     ldrw(t1, Address(rthread, JavaThread::lock_stack_top_offset()));
> 6263:     cmpw(t1, (unsigned)LockStack::start_offset());
> 6264:     br(Assembler::GT, stack_ok);

I had to think hard about "GT" here. 

We could have entered with the thread holding just one inflated lock, then LockStack would be empty but the monitorexit would still be valid. You now do check in the callers for markWord::monitor_value. But the lock could have been inflated concurrently after the caller checks and before this point. 

But then the LockStack would not have changed, since it represents what the current thread *thinks* are thin locks, not what are actually thin locks? In other words, LockStack is only modified by its owning thread, never from the outside.

So this *should* be correct, but its certainly a brain teaser. Maybe add a comment? 

E.g. "These checks rely on the fact that LockStack is only ever modified by its owning stack, even if the lock got inflated concurrently; removal of LockStack entries after inflation will happen delayed in that case" or somesuch.

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 6274:

> 6272:     ldr(t1, Address(rthread, t1));
> 6273:     cmpoop(t1, obj);
> 6274:     br(Assembler::EQ, tos_ok);

STOP missing?

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 6280:

> 6278:     // Check that hdr is fast-locked.
> 6279:     Label hdr_ok;
> 6280:     ands(zr, hdr, markWord::lock_mask_in_place);

Confused about ANDS here. So ZR would receive the result of the AND, but I assume zr is immutable and the result is discarded?

If so, why not just use TST(hdr, markWord::lock_mask_in_place); ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1154611972
PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1154620174
PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1154647227

From stuefe at openjdk.org  Fri Mar 31 16:01:02 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 31 Mar 2023 16:01:02 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v48]
In-Reply-To: <hw22plMwnZ_WRGZJs4XONEPrUM3V3bG62yIyJ5pSb08=.90c051ed-eee4-4957-9f4e-1834192ae273@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <fbzWu2Ud-ct0lQwFm7X5tnBQe8uXHi837kN8D60sVGU=.b7420c51-5f13-43ac-baac-032362ec72a8@github.com>
 <hw22plMwnZ_WRGZJs4XONEPrUM3V3bG62yIyJ5pSb08=.90c051ed-eee4-4957-9f4e-1834192ae273@github.com>
Message-ID: <e8k7g88Yc-_ic2zwsX0Sa1oc5VQ9vw1sUwvKeU9eTXA=.202a2887-2083-4df2-ab47-31f465b78a6e@github.com>

On Fri, 31 Mar 2023 15:24:07 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2
>>  - Check underflow, top-of-stack and mark-bits for sanity, in fast_unlock() (aarch64)
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 6264:
> 
>> 6262:     ldrw(t1, Address(rthread, JavaThread::lock_stack_top_offset()));
>> 6263:     cmpw(t1, (unsigned)LockStack::start_offset());
>> 6264:     br(Assembler::GT, stack_ok);
> 
> I had to think hard about "GT" here. 
> 
> We could have entered with the thread holding just one inflated lock, then LockStack would be empty but the monitorexit would still be valid. You now do check in the callers for markWord::monitor_value. But the lock could have been inflated concurrently after the caller checks and before this point. 
> 
> But then the LockStack would not have changed, since it represents what the current thread *thinks* are thin locks, not what are actually thin locks? In other words, LockStack is only modified by its owning thread, never from the outside.
> 
> So this *should* be correct, but its certainly a brain teaser. Maybe add a comment? 
> 
> E.g. "These checks rely on the fact that LockStack is only ever modified by its owning stack, even if the lock got inflated concurrently; removal of LockStack entries after inflation will happen delayed in that case" or somesuch.

This also mandates that fast_lock can only ever entered if the current thread thinks that the lock in question is a thin lock. So the caller checks for markWord::monitor_value are mandatory now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1154619603

From kbarrett at openjdk.org  Fri Mar 31 16:24:23 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 31 Mar 2023 16:24:23 GMT
Subject: RFR: 8297539: Use PrimitiveConversions::cast for local uses of the
 int<->float union conversion trick [v4]
In-Reply-To: <7NKaN1fkjZMSZIpCAP-q32n3PLpmzc8kbBAnNJ6CnR8=.65aa06fe-ead8-41c1-a52c-1b8c78fb6ded@github.com>
References: <Fc1LufRzwqeQjXSwyVm3FaJWzbaazUXyArTYPLlGrwM=.034cb09b-79d8-49a1-a68d-b5914a9cc214@github.com>
 <7NKaN1fkjZMSZIpCAP-q32n3PLpmzc8kbBAnNJ6CnR8=.65aa06fe-ead8-41c1-a52c-1b8c78fb6ded@github.com>
Message-ID: <GhFT8HhycGSDfY10oBMasolljRea07o1Jgzz2PrXfBk=.aaf2c798-df39-4599-a522-a201ea5e9a0a@github.com>

On Fri, 31 Mar 2023 09:24:52 GMT, Afshin Zafari <duke at openjdk.org> wrote:

>> **Only** the instances of using `union` for converting `int` to `float` are replaced with call to `PrimitiveConversions::cast<To>(From)` method. Some few cases with conversion of `long` <->`double` are also replaced with `PrimitiveConversions::cast<To>(From)`. The other instances where the union contains other types of fields than `int` and `float` are left unchanged.
>> 
>> ### Test
>> local hotspot:tier1
>> mach5 tiers 1-5
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8297539: Use PrimitiveConversions::cast for local uses of the int<->float union conversion trick

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13136#pullrequestreview-1367242993

From psandoz at openjdk.org  Fri Mar 31 16:24:25 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 31 Mar 2023 16:24:25 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v5]
In-Reply-To: <vA5WfADFdG_fLcR1vSr-nwP52482Sx0n223b8WQx2fY=.f9f12e65-8f01-4594-8430-20afe87c94db@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
 <oiRTNlsfJ4A5EbcwbqaFSv9DpYutUZv2rLfrOS0ti60=.1d3d4123-b04c-4e24-85cf-3ba8eb5933c8@github.com>
 <MEr60_T2IVbV5WspV4SNDTmp4h38xjs1xi94alz3suw=.f45285a0-0c56-4e7a-b44b-9fca23caa145@github.com>
 <vA5WfADFdG_fLcR1vSr-nwP52482Sx0n223b8WQx2fY=.f9f12e65-8f01-4594-8430-20afe87c94db@github.com>
Message-ID: <oAbuxUcN-KI_YzY4_Ke45f8n25b-ktChKUSHDFN7AlY=.a2a3e12e-a5ce-4cc2-8c7a-e766639db728@github.com>

On Fri, 31 Mar 2023 12:17:49 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-VectorBits.java.template line 1106:
>> 
>>> 1104:         @Override
>>> 1105:         @ForceInline
>>> 1106:         public int laneSource(int i) {
>> 
>> Can this method be moved to `AbstractShuffle`?
>
> No because `T lane(int)` is a method of the typed vector classes which is not available in `AbstractVector`

Ah, doh!, yes of course, we would need to specialize the shuffle.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13093#discussion_r1154671839

From mgronlun at openjdk.org  Fri Mar 31 16:50:22 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 31 Mar 2023 16:50:22 GMT
Subject: RFR: 8304033: JFR: Missing thread
Message-ID: <oXAOxh0qlxXbjCFEBSyIlsLCwqkRao6MOLt6OfBiQOM=.371fff76-0ce8-4332-a1ad-d0c486b58c50@github.com>

Greetings,

please help review this small adjustment to fix the lack of thread information in certain situations, more specifically associated with JNI_AttachThread and JNI_DetachThread. The old site posting a thread start event is correct in getting the correct thread id, but the thread does not write its checkpoint at that location, which is required after JFR Event Streaming.

The fix is to let the sites in jni.cpp go through the "normal" thread start entry point.

Testing: jdk_jfr

Thanks
Markus

-------------

Commit messages:
 - 8304033

Changes: https://git.openjdk.org/jdk/pull/13272/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13272&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304033
  Stats: 25 lines in 1 file changed: 3 ins; 20 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13272.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13272/head:pull/13272

PR: https://git.openjdk.org/jdk/pull/13272

From psandoz at openjdk.org  Fri Mar 31 17:07:20 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 31 Mar 2023 17:07:20 GMT
Subject: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation
 [v2]
In-Reply-To: <DAnlsKJ-3aNZZWnvP2j_J59dpX_wzor1IM6dY0bie1Q=.ddf68a3d-59bf-4108-959f-8dc50c095e45@github.com>
References: <UUJ_FtbjQyBTAghppISmyUOjBuSg2RKIVi4oAdMhU5Y=.1f9e7320-0dd6-405b-926b-c1ed427ce29f@github.com>
 <lmW05NgITkLuyzWlWENcX_wEhObY5BRk6L-JyK4LfVg=.817c80e5-92ac-4b9b-9001-1ff1d97a38a4@github.com>
 <zkYQ_5LR47PqQ8nV7TZefUlWENFR-ZHvQx5LWWDhc4E=.b3217ca6-695e-45b2-a748-aa855ac05904@github.com>
 <DAnlsKJ-3aNZZWnvP2j_J59dpX_wzor1IM6dY0bie1Q=.ddf68a3d-59bf-4108-959f-8dc50c095e45@github.com>
Message-ID: <uidpcRNiJYMwcsafIzJIZ8Aaxu1WJLhMwtOUNya2sng=.419ece32-f9cd-4506-8114-4f4d223d5f36@github.com>

On Tue, 21 Mar 2023 16:29:44 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> I have moved most of the methods to `AbstractVector` and `AbstractShuffle`, I have to resort to raw types, though, since there seems to be no way to do the same with wild cards, and the generics mechanism is not powerful enough for things like `Vector<E.integral>`. The remaining failure seems to be related to [JDK-8304676](https://bugs.openjdk.org/projects/JDK/issues/JDK-8304676), so I think this patch is ready for review now.
>> 
>>> The mask implementation is specialized by the species of vectors it operates on, but does it have to be
>> 
>> Apart from the mask implementation, shuffle implementation definitely has to take into consideration the element type. However, this information does not have to be visible to the API, similar to how we currently handle the vector length, we can have `class AbstractMask<E> implements VectorMask`. As a result, the cast method would be useless and can be removed in the API, but our implementation details would still use it, for example
>> 
>>     Vector<E> blend(Vector<E> v, VectorMask w) {
>>         AbstractMask<?> aw = (AbstractMask<?>) w;
>>         AbstractMask<E> tw = aw.cast(vspecies());
>>         return VectorSupport.blend(...);
>>     }
>> 
>>     Vector<E> rearrange(VectorShuffle s) {
>>         AbstractShuffle<?> as = (AbstractShuffle<?>) s;
>>         AbstractShuffle<E> ts = s.cast(vspecies());
>>         return VectorSupport.rearrangeOp(...);
>>     }
>> 
>> What do you think?
>
>> Apart from the mask implementation, shuffle implementation definitely has to take into consideration the element type.
> 
> Yes, the way you have implemented shuffle is tightly connected, that looks ok.
> 
> I am wondering if we can make the mask implementation more loosely coupled and modified such that it does not have to take into consideration the element type (or species) of the vector it operates on, and instead compatibility is based solely on the lane count.
> 
> Ideally it would be good to change the `VectorMask::check` method to just compare the lanes counts and not require a cast in the implementation, which i presume requires some deeper changes in C2?
> 
> What you propose seems a possible a interim step towards a more preferable API, if the performance is good.

> Thanks @PaulSandoz and @XiaohongGong for the reviews and testings.

Running tier2/3 tests.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13093#issuecomment-1492274813

From xliu at openjdk.org  Fri Mar 31 17:53:20 2023
From: xliu at openjdk.org (Xin Liu)
Date: Fri, 31 Mar 2023 17:53:20 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v5]
In-Reply-To: <BkFhS_H--jWSoKWjzV794-R7c3Y4Vz5syDHg9Izenf8=.2f415d57-14a2-437e-af45-064f6de461d3@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <BkFhS_H--jWSoKWjzV794-R7c3Y4Vz5syDHg9Izenf8=.2f415d57-14a2-437e-af45-064f6de461d3@github.com>
Message-ID: <jHg4FYCdKnJq9wOPuKKXCl6_yEBw-OvHtEN-Pk0UxxM=.1d019bbe-581a-4f0e-b627-7b011e5809f2@github.com>

On Thu, 30 Mar 2023 23:36:20 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> Can I please get reviews for this PR? 
>> 
>> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested.
>> 
>> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N:
>> 
>> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png)
>> 
>> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1:
>> 
>> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png)
>> 
>> This PR adds support scalar replacing allocations participating in merges that are used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently.
>> 
>> The approach I used for _rematerialization_ is pretty straightforward. It consists basically in: 1) Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a new Class to support rematerialization of SR objects part of merges; 3) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 4) Patch C2 to generate unique types for SR objects participating in some allocation merges.
>> 
>> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straight forward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless.
>> 
>> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also tested with several applications and didn't see any failure. I also ran tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address PR feeedback 1: make ObjectMergeValue subclass of ObjectValue & create new IR class to represent scalarized merges.

src/hotspot/share/opto/escape.cpp line 588:

> 586: }
> 587: 
> 588: // This method will create a SafePointScalarObjectNode for each combination of

you have changed to SafePointScalarMergeNode in code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1154745690

From coleenp at openjdk.org  Fri Mar 31 17:54:29 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 31 Mar 2023 17:54:29 GMT
Subject: RFR: 8304743: Compile_lock and SystemDictionary updates
Message-ID: <bSbAtEyZ0vlouXmixDD0c6V0vfYiuLuUMNPcLLkmi58=.70600f11-a17a-43a6-ab61-25d531f54afa@github.com>

The SystemDictionary is updated and read under the Compile_lock but this is unnecessary because the table is a concurrent hashtable, and the lock doesn't really synchronize any other compilation state.  The lock may have protected other state that Dependencies used in the past but has been removed.   See discussion in CR for more information.
Tested with tier1-8.

-------------

Commit messages:
 - 8304743: Compile_lock and SystemDictionary updates

Changes: https://git.openjdk.org/jdk/pull/13270/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13270&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304743
  Stats: 36 lines in 3 files changed: 1 ins; 21 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/13270.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13270/head:pull/13270

PR: https://git.openjdk.org/jdk/pull/13270

From egahlin at openjdk.org  Fri Mar 31 17:57:17 2023
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 31 Mar 2023 17:57:17 GMT
Subject: RFR: 8304033: JFR: Missing thread
In-Reply-To: <oXAOxh0qlxXbjCFEBSyIlsLCwqkRao6MOLt6OfBiQOM=.371fff76-0ce8-4332-a1ad-d0c486b58c50@github.com>
References: <oXAOxh0qlxXbjCFEBSyIlsLCwqkRao6MOLt6OfBiQOM=.371fff76-0ce8-4332-a1ad-d0c486b58c50@github.com>
Message-ID: <A9eRiXDjTkNKTgAYTiewWZ3lKbWDHMb38jrxKY-JVBk=.2c6c2094-141f-4823-b0b3-5b00abaab2c2@github.com>

On Fri, 31 Mar 2023 16:42:55 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> please help review this small adjustment to fix the lack of thread information in certain situations, more specifically associated with JNI_AttachThread and JNI_DetachThread. The old site posting a thread start event is correct in getting the correct thread id, but the thread does not write its checkpoint at that location, which is required after JFR Event Streaming.
> 
> The fix is to let the sites in jni.cpp go through the "normal" thread start entry point.
> 
> Testing: jdk_jfr
> 
> Thanks
> Markus

Marked as reviewed by egahlin (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13272#pullrequestreview-1367360157

From xliu at openjdk.org  Fri Mar 31 18:24:18 2023
From: xliu at openjdk.org (Xin Liu)
Date: Fri, 31 Mar 2023 18:24:18 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v5]
In-Reply-To: <BkFhS_H--jWSoKWjzV794-R7c3Y4Vz5syDHg9Izenf8=.2f415d57-14a2-437e-af45-064f6de461d3@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <BkFhS_H--jWSoKWjzV794-R7c3Y4Vz5syDHg9Izenf8=.2f415d57-14a2-437e-af45-064f6de461d3@github.com>
Message-ID: <tWki9FSa5shsXyCMcUVJL5oPuM5lxjN_gMWDVkYvst4=.a1101c45-1b1a-425e-83b5-856d6fddaacc@github.com>

On Thu, 30 Mar 2023 23:36:20 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> Can I please get reviews for this PR? 
>> 
>> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested.
>> 
>> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N:
>> 
>> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png)
>> 
>> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1:
>> 
>> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png)
>> 
>> This PR adds support scalar replacing allocations participating in merges that are used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently.
>> 
>> The approach I used for _rematerialization_ is pretty straightforward. It consists basically in: 1) Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a new Class to support rematerialization of SR objects part of merges; 3) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 4) Patch C2 to generate unique types for SR objects participating in some allocation merges.
>> 
>> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straight forward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless.
>> 
>> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also tested with several applications and didn't see any failure. I also ran tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address PR feeedback 1: make ObjectMergeValue subclass of ObjectValue & create new IR class to represent scalarized merges.

src/hotspot/share/opto/macro.cpp line 632:

> 630:           safepoints->append_if_missing(sfpt);
> 631:         }
> 632:       } else if (ignore_merges && (use->is_Phi() || use->is_EncodeP() || use->Opcode() == Op_MemBarRelease)) {

I try to understand this part. now `can_eliminate_allocation` can pre-test whether SR can eliminate the alloc.  I see that you use it in EA. 

With ignore_merges, why we also skip EncodeP or MemBarRelease here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1154771471

From xliu at openjdk.org  Fri Mar 31 18:27:21 2023
From: xliu at openjdk.org (Xin Liu)
Date: Fri, 31 Mar 2023 18:27:21 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v5]
In-Reply-To: <tWki9FSa5shsXyCMcUVJL5oPuM5lxjN_gMWDVkYvst4=.a1101c45-1b1a-425e-83b5-856d6fddaacc@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <BkFhS_H--jWSoKWjzV794-R7c3Y4Vz5syDHg9Izenf8=.2f415d57-14a2-437e-af45-064f6de461d3@github.com>
 <tWki9FSa5shsXyCMcUVJL5oPuM5lxjN_gMWDVkYvst4=.a1101c45-1b1a-425e-83b5-856d6fddaacc@github.com>
Message-ID: <mxsldgW-AtEV3etyH7yZ2jx5MXXSyQFiKqzalVYPaYg=.fae3b88a-1f76-4b60-8644-6413a7d8accb@github.com>

On Fri, 31 Mar 2023 18:21:40 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address PR feeedback 1: make ObjectMergeValue subclass of ObjectValue & create new IR class to represent scalarized merges.
>
> src/hotspot/share/opto/macro.cpp line 632:
> 
>> 630:           safepoints->append_if_missing(sfpt);
>> 631:         }
>> 632:       } else if (ignore_merges && (use->is_Phi() || use->is_EncodeP() || use->Opcode() == Op_MemBarRelease)) {
> 
> I try to understand this part. now `can_eliminate_allocation` can pre-test whether SR can eliminate the alloc.  I see that you use it in EA. 
> 
> With ignore_merges, why we also skip EncodeP or MemBarRelease here?

Do you really need the boolean parameter ignore_merges here? 
It looks like we can use (safepoints == nullptr) instead?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1154773826

From xliu at openjdk.org  Fri Mar 31 18:33:19 2023
From: xliu at openjdk.org (Xin Liu)
Date: Fri, 31 Mar 2023 18:33:19 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v5]
In-Reply-To: <BkFhS_H--jWSoKWjzV794-R7c3Y4Vz5syDHg9Izenf8=.2f415d57-14a2-437e-af45-064f6de461d3@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <BkFhS_H--jWSoKWjzV794-R7c3Y4Vz5syDHg9Izenf8=.2f415d57-14a2-437e-af45-064f6de461d3@github.com>
Message-ID: <Fco8XVAwjuZJoOaK-fb7UzAu3y9utPQk17D6ncUAH6E=.f097a54d-8883-42f7-b81a-2a7b423511d5@github.com>

On Thu, 30 Mar 2023 23:36:20 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> Can I please get reviews for this PR? 
>> 
>> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested.
>> 
>> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N:
>> 
>> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png)
>> 
>> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1:
>> 
>> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png)
>> 
>> This PR adds support scalar replacing allocations participating in merges that are used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently.
>> 
>> The approach I used for _rematerialization_ is pretty straightforward. It consists basically in: 1) Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a new Class to support rematerialization of SR objects part of merges; 3) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 4) Patch C2 to generate unique types for SR objects participating in some allocation merges.
>> 
>> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straight forward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless.
>> 
>> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also tested with several applications and didn't see any failure. I also ran tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address PR feeedback 1: make ObjectMergeValue subclass of ObjectValue & create new IR class to represent scalarized merges.

src/hotspot/share/opto/escape.cpp line 457:

> 455:         found_sr_allocate = true;
> 456:       } else {
> 457:         ptn->set_scalar_replaceable(false);

This member function is const. Do we really need to change ptn's property here? 

My reading is ophi is profitable as long as we spot any input object which can be eliminated.  how about you just return at line 455?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1154778280

From xliu at openjdk.org  Fri Mar 31 18:41:23 2023
From: xliu at openjdk.org (Xin Liu)
Date: Fri, 31 Mar 2023 18:41:23 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v4]
In-Reply-To: <o6msC4bnqaYIl0YQPjv-IPXsHRUbtleyEvcirt5dyog=.56d57ae0-f3bc-4942-942e-066e8fd95856@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com>
 <figDCuWUFwMCXvDoIxOtcmOaqb_3a7PLZUEQg75Jmws=.3f991293-94d1-4843-8da3-cf97d79c47be@github.com>
 <0UbMqMHtVIayPdJMmfDF6YTadWe4YTlSW6mZc5P3IU8=.c4b1a292-e434-4c57-a5cd-015edca2ec95@github.com>
 <o6msC4bnqaYIl0YQPjv-IPXsHRUbtleyEvcirt5dyog=.56d57ae0-f3bc-4942-942e-066e8fd95856@github.com>
Message-ID: <FOUeJrVL0xYrKw3FzYZc8HCSocQ82_Iizd_HthI-W_8=.06b6b235-1412-4e5c-82ee-51893239c2f1@github.com>

On Fri, 24 Mar 2023 23:37:29 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> I had to make this method static because it uses `value_from_mem` - which I also made static. I had to make `value_from_mem` static so that I can use it outside PhaseMacroExpand.
>
> I see, you use it in escape.cpp. Okay. I need to review changes there too.

or you could construct a temporary PhaseMacroExpand object in EA. 

I see that you convert many member function to static so you can query in EA. the only blocker is _igvn.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1154785040

From duke at openjdk.org  Fri Mar 31 18:43:18 2023
From: duke at openjdk.org (Afshin Zafari)
Date: Fri, 31 Mar 2023 18:43:18 GMT
Subject: RFR: 8297539: Use PrimitiveConversions::cast for local uses of the
 int<->float union conversion trick [v4]
In-Reply-To: <7NKaN1fkjZMSZIpCAP-q32n3PLpmzc8kbBAnNJ6CnR8=.65aa06fe-ead8-41c1-a52c-1b8c78fb6ded@github.com>
References: <Fc1LufRzwqeQjXSwyVm3FaJWzbaazUXyArTYPLlGrwM=.034cb09b-79d8-49a1-a68d-b5914a9cc214@github.com>
 <7NKaN1fkjZMSZIpCAP-q32n3PLpmzc8kbBAnNJ6CnR8=.65aa06fe-ead8-41c1-a52c-1b8c78fb6ded@github.com>
Message-ID: <jdkzApvjOgg5vrBauuRkADhxS4uADrqFWXv2unGG74s=.2c8e1b67-182b-4051-ab2c-00c69840a8dc@github.com>

On Fri, 31 Mar 2023 09:24:52 GMT, Afshin Zafari <duke at openjdk.org> wrote:

>> **Only** the instances of using `union` for converting `int` to `float` are replaced with call to `PrimitiveConversions::cast<To>(From)` method. Some few cases with conversion of `long` <->`double` are also replaced with `PrimitiveConversions::cast<To>(From)`. The other instances where the union contains other types of fields than `int` and `float` are left unchanged.
>> 
>> ### Test
>> local hotspot:tier1
>> mach5 tiers 1-5
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8297539: Use PrimitiveConversions::cast for local uses of the int<->float union conversion trick

Thank you Coleen, Kim and David for your comments and reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13136#issuecomment-1492431924

From cjplummer at openjdk.org  Fri Mar 31 19:37:31 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 31 Mar 2023 19:37:31 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v14]
In-Reply-To: <eCKU_LwEwIaRdXGC_i3x5dacmsGVUja_K5oPwN1UngA=.beea9c5d-dc3a-49dd-bd22-e25b1ebaac4c@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <eCKU_LwEwIaRdXGC_i3x5dacmsGVUja_K5oPwN1UngA=.beea9c5d-dc3a-49dd-bd22-e25b1ebaac4c@github.com>
Message-ID: <BV-O5LngmlGQGSwoGPGQ9zQipnc41y3kS5yxZly4CP8=.4500e8fb-9986-48dd-bf32-18c97121a7fb@github.com>

On Fri, 31 Mar 2023 06:52:18 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The fix is to enable virtual threads support for late binding JVMTI agents.
>> The fix includes:
>> - New function `JvmtiEnvBase::enable_virtual_threads_notify_jvmti()` which does enabling JVMTI VTMS transition notifications in case of agent loaded into running VM. This function executes a VM operation counting VTMS transition bits in all `JavaThread`'s to correctly set the static counter `_VTMS_transition_count` needed for VTMS transition protocol.
>> - New function `JvmtiEnvBase::disable_virtual_threads_notify_jvmti()` which is needed for testing. It is used by the `WhiteBox` API.
>> - New WhiteBox function `WB_SetVirtualThreadsNotifyJvmtiMode(JNIEnv* env, jobject wb, jboolean enable)` needed for testing of this update.
>> - New regression test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
>> 
>> Testing:
>> - New test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
>> - The originally failed tests are expected to pass 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:
> 
>   review: addressed next round of review suggestions

Changes look good, but for the most part I just looked at the test related changes.

-------------

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13133#pullrequestreview-1367488100

From rkennke at openjdk.org  Fri Mar 31 19:39:03 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 31 Mar 2023 19:39:03 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v49]
In-Reply-To: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
Message-ID: <ycTvSGpceON_ggEeDldaDcMrg5Citr6Gh7h2FRQcaJY=.77d31d81-17a1-4df7-a44a-e4dc8f72c2f8@github.com>

> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
> 
> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p
 rotocols.
> 
> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare.
> 
> 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
> 
> 
> Testing:
>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
> 
> ### Performance
> 
> #### Simple Microbenchmark
> 
> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
> 
> |  | x86_64 | aarch64 |
> | -- | -- | -- |
> | -UseFastLocking | 20.651 | 20.764 |
> | +UseFastLocking | 18.896 | 18.908 |
> 
> 
> #### Renaissance
> 
> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
> -- | -- | -- | -- | -- | -- | -- | --
> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Thomas' comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10907/files
  - new: https://git.openjdk.org/jdk/pull/10907/files/0e366206..1ad95851

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=48
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=47-48

  Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10907.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10907/head:pull/10907

PR: https://git.openjdk.org/jdk/pull/10907

From dcubed at openjdk.org  Fri Mar 31 20:23:50 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 31 Mar 2023 20:23:50 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v49]
In-Reply-To: <ycTvSGpceON_ggEeDldaDcMrg5Citr6Gh7h2FRQcaJY=.77d31d81-17a1-4df7-a44a-e4dc8f72c2f8@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <ycTvSGpceON_ggEeDldaDcMrg5Citr6Gh7h2FRQcaJY=.77d31d81-17a1-4df7-a44a-e4dc8f72c2f8@github.com>
Message-ID: <5VKEOAqoXvtmTDHHUYT1CkVP36je-lt_O9i1vC2zNyg=.c57cb302-e730-422b-a8da-e224ad4bc010@github.com>

On Fri, 31 Mar 2023 19:39:03 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Thomas' comments

v47 passed Mach5 Tier1. I'll continue with additional Mach5 testing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1492567631

From sspitsyn at openjdk.org  Fri Mar 31 20:32:24 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 31 Mar 2023 20:32:24 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v14]
In-Reply-To: <eCKU_LwEwIaRdXGC_i3x5dacmsGVUja_K5oPwN1UngA=.beea9c5d-dc3a-49dd-bd22-e25b1ebaac4c@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
 <eCKU_LwEwIaRdXGC_i3x5dacmsGVUja_K5oPwN1UngA=.beea9c5d-dc3a-49dd-bd22-e25b1ebaac4c@github.com>
Message-ID: <k59WpjxMda01HL75678Gcw303ADcjzDaGkbosLl3nP4=.5b1a9f9e-ecc3-4a2c-9087-8f3df90246f8@github.com>

On Fri, 31 Mar 2023 06:52:18 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The fix is to enable virtual threads support for late binding JVMTI agents.
>> The fix includes:
>> - New function `JvmtiEnvBase::enable_virtual_threads_notify_jvmti()` which does enabling JVMTI VTMS transition notifications in case of agent loaded into running VM. This function executes a VM operation counting VTMS transition bits in all `JavaThread`'s to correctly set the static counter `_VTMS_transition_count` needed for VTMS transition protocol.
>> - New function `JvmtiEnvBase::disable_virtual_threads_notify_jvmti()` which is needed for testing. It is used by the `WhiteBox` API.
>> - New WhiteBox function `WB_SetVirtualThreadsNotifyJvmtiMode(JNIEnv* env, jobject wb, jboolean enable)` needed for testing of this update.
>> - New regression test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
>> 
>> Testing:
>> - New test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
>> - The originally failed tests are expected to pass 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:
> 
>   review: addressed next round of review suggestions

Leonid and Chris, thank you for review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13133#issuecomment-1492575146

From sspitsyn at openjdk.org  Fri Mar 31 20:39:17 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 31 Mar 2023 20:39:17 GMT
Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324
 [v15]
In-Reply-To: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
References: <QRC0Nzg4NIDqJs0YDUg0ZPmTHDdkjNzPKvIs0N1G8ik=.5a85c9c2-990c-4e03-ac85-029702476f9d@github.com>
Message-ID: <vxE4zwUGbpQSyiSyDD7lQU7ofMtpqB67A9zPngfpGg0=.e0e4535a-8717-4e63-8088-6e499b20eab3@github.com>

> The fix is to enable virtual threads support for late binding JVMTI agents.
> The fix includes:
> - New function `JvmtiEnvBase::enable_virtual_threads_notify_jvmti()` which does enabling JVMTI VTMS transition notifications in case of agent loaded into running VM. This function executes a VM operation counting VTMS transition bits in all `JavaThread`'s to correctly set the static counter `_VTMS_transition_count` needed for VTMS transition protocol.
> - New function `JvmtiEnvBase::disable_virtual_threads_notify_jvmti()` which is needed for testing. It is used by the `WhiteBox` API.
> - New WhiteBox function `WB_SetVirtualThreadsNotifyJvmtiMode(JNIEnv* env, jobject wb, jboolean enable)` needed for testing of this update.
> - New regression test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
> 
> Testing:
> - New test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
> - The originally failed tests are expected to pass 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:

  minor simplification in ToggleNotifyJvmtiTest.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13133/files
  - new: https://git.openjdk.org/jdk/pull/13133/files/aef87273..c55b6b38

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13133&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13133&range=13-14

  Stats: 13 lines in 1 file changed: 3 ins; 7 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13133.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13133/head:pull/13133

PR: https://git.openjdk.org/jdk/pull/13133

From dcubed at openjdk.org  Fri Mar 31 20:56:53 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 31 Mar 2023 20:56:53 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v49]
In-Reply-To: <ycTvSGpceON_ggEeDldaDcMrg5Citr6Gh7h2FRQcaJY=.77d31d81-17a1-4df7-a44a-e4dc8f72c2f8@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <ycTvSGpceON_ggEeDldaDcMrg5Citr6Gh7h2FRQcaJY=.77d31d81-17a1-4df7-a44a-e4dc8f72c2f8@github.com>
Message-ID: <qFFlZWOW1IDIFN0BPTR6-h9kFWknywhXgqMKFZ5FLxc=.1473cb71-e4ba-4d70-8005-ca031ad08cb9@github.com>

On Fri, 31 Mar 2023 19:39:03 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Thomas' comments

As expected, jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Deadlock/JavaDeadlock005/TestDescription.java
continues to pass in release, fastdebug and slowdebug bits on my MBP13.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1492595034

From vlivanov at openjdk.org  Fri Mar 31 21:28:17 2023
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 31 Mar 2023 21:28:17 GMT
Subject: RFR: 8304743: Compile_lock and SystemDictionary updates
In-Reply-To: <bSbAtEyZ0vlouXmixDD0c6V0vfYiuLuUMNPcLLkmi58=.70600f11-a17a-43a6-ab61-25d531f54afa@github.com>
References: <bSbAtEyZ0vlouXmixDD0c6V0vfYiuLuUMNPcLLkmi58=.70600f11-a17a-43a6-ab61-25d531f54afa@github.com>
Message-ID: <9BJjGpmSrwRXFXsj2EC8pewLrA1Z6PYJfn5pMbf3vnE=.9000e432-b2da-4047-b8ac-a045aceb53b8@github.com>

On Fri, 31 Mar 2023 13:23:31 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The SystemDictionary is updated and read under the Compile_lock but this is unnecessary because the table is a concurrent hashtable, and the lock doesn't really synchronize any other compilation state.  The lock may have protected other state that Dependencies used in the past but has been removed.   See discussion in CR for more information.
> Tested with tier1-8.

Looks good. Thanks for taking care of it, Coleen.

FTR there are other redundant usages of `Compile_lock` in CI code.

src/hotspot/share/ci/ciEnv.cpp line 519:

> 517: 
> 518:   Klass* found_klass;
> 519:   if (!require_local) {

Since JVMCI needs the very same code, does it make sense to put it into a wrapper method?

-------------

Marked as reviewed by vlivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13270#pullrequestreview-1367641286
PR Review Comment: https://git.openjdk.org/jdk/pull/13270#discussion_r1154920450

From dlong at openjdk.org  Fri Mar 31 21:33:16 2023
From: dlong at openjdk.org (Dean Long)
Date: Fri, 31 Mar 2023 21:33:16 GMT
Subject: RFR: 8304743: Compile_lock and SystemDictionary updates
In-Reply-To: <bSbAtEyZ0vlouXmixDD0c6V0vfYiuLuUMNPcLLkmi58=.70600f11-a17a-43a6-ab61-25d531f54afa@github.com>
References: <bSbAtEyZ0vlouXmixDD0c6V0vfYiuLuUMNPcLLkmi58=.70600f11-a17a-43a6-ab61-25d531f54afa@github.com>
Message-ID: <Zqvv2X7MZIqKgUe-vyuiU5BU2yh3jLDa1bMqgM2WLlE=.0880f883-aca1-486b-bc9a-1b7dd2729377@github.com>

On Fri, 31 Mar 2023 13:23:31 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The SystemDictionary is updated and read under the Compile_lock but this is unnecessary because the table is a concurrent hashtable, and the lock doesn't really synchronize any other compilation state.  The lock may have protected other state that Dependencies used in the past but has been removed.   See discussion in CR for more information.
> Tested with tier1-8.

Is there a guarantee that any klasses the compiler found in the hierarchy are actually in the dictionary by the time the compiled code gets to execute?  If not, then we could have something like this fail?
`Class.forName(this.getClass().getName());`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13270#issuecomment-1492632852

From dcubed at openjdk.org  Fri Mar 31 22:02:51 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 31 Mar 2023 22:02:51 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v49]
In-Reply-To: <ycTvSGpceON_ggEeDldaDcMrg5Citr6Gh7h2FRQcaJY=.77d31d81-17a1-4df7-a44a-e4dc8f72c2f8@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <ycTvSGpceON_ggEeDldaDcMrg5Citr6Gh7h2FRQcaJY=.77d31d81-17a1-4df7-a44a-e4dc8f72c2f8@github.com>
Message-ID: <OSvQJMgS8iNvVomVzkBlFCzmyz4VGA5Pynn3wHyzIUE=.80dacd63-f6dd-4765-a053-2a2078d6e962@github.com>

On Fri, 31 Mar 2023 19:39:03 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It 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 when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity).
>> 
>> 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 (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal 
 protocols.
>> 
>> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare.
>> 
>> 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
>> 
>> 
>> Testing:
>>  - [x] tier1 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x +UseFastLocking
>>  - [x] tier1 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier2 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier3 x86_64 x aarch64 x -UseFastLocking
>>  - [x] tier4 x86_64 x aarch64 x -UseFastLocking
>>  - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet
>> 
>> ### Performance
>> 
>> #### Simple Microbenchmark
>> 
>> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops.
>> 
>> |  | x86_64 | aarch64 |
>> | -- | -- | -- |
>> | -UseFastLocking | 20.651 | 20.764 |
>> | +UseFastLocking | 18.896 | 18.908 |
>> 
>> 
>> #### Renaissance
>> 
>> ? | x86_64 | ? | ? | ? | aarch64 | ? | ?
>> -- | -- | -- | -- | -- | -- | -- | --
>> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ?
>> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69%
>> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21%
>> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59%
>> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15%
>> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11%
>> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97%
>> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%%
>> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54%
>> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11%
>> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40%
>> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12%
>> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34%
>> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40%
>> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74%
>> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24%
>> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58%
>> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53%
>> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37%
>> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97%
>> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39%
>> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04%
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Thomas' comments

v47 is hitting an assertion failure in my Mach5 Tier2 and Tier3 testing:


# Internal Error (/opt/mach5/mesos/work_dir/slaves/741e9afd-8c02-45c3-b2e2-9db1450d0832-S30407/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/b94a7623-5f98-46f3-8e2c-08444e95afa4/runs/a5754c45-3d7a-46fa-ba4b-c52efcf6ca3b/workspace/open/src/hotspot/share/runtime/lockStack.cpp:78), pid=1731612, tid=1731617
# assert((_top < end_offset())) failed: lockstack overflow: _top 1704 end_offset 1704
#
# JRE version: Java(TM) SE Runtime Environment (21.0) (fastdebug build 21-internal-LTS-2023-03-31-1908037.daniel.daugherty.8291555forjdk21.git)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 21-internal-LTS-2023-03-31-1908037.daniel.daugherty.8291555forjdk21.git, mixed mode, tiered, compressed oops, compressed class ptrs, serial gc, linux-aarch64)
# Problematic frame:
# V [libjvm.so+0x10cfa0c] LockStack::verify_no_thread(char const*) const+0x288


Please see the bug for the latest details as I investigate.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1492658176

From dlong at openjdk.org  Fri Mar 31 22:41:56 2023
From: dlong at openjdk.org (Dean Long)
Date: Fri, 31 Mar 2023 22:41:56 GMT
Subject: RFR: 8291555: Implement alternative fast-locking scheme [v47]
In-Reply-To: <kbB5LIzZLjy_dGTTysVtZUrsHEhSVjLJwlwKX531GBE=.343f60c7-8a77-4ca5-9efb-7a2442db5185@github.com>
References: <woVwv-UEYxcS1Sdn5JmtK4h3MRTmSovFCQbQHaSu2Ik=.43d1e234-4503-45f5-b558-5bc847b53099@github.com>
 <zL-d1b4dJXDtaQHN1vOqbuDlgWcYV4sLef5ejOYR7DM=.71e7e5b3-b360-4f8c-a8f8-b54eafec87b3@github.com>
 <kbB5LIzZLjy_dGTTysVtZUrsHEhSVjLJwlwKX531GBE=.343f60c7-8a77-4ca5-9efb-7a2442db5185@github.com>
Message-ID: <eFKylrRhxzxD-uJVDa7spgeImzrULap7LvWpAkHCahI=.b7d92c9e-86e1-4dec-9e86-cedbc5057384@github.com>

On Fri, 31 Mar 2023 07:25:48 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use int instead of size_t for cached offsets, to match the uncached offset type and avoid build failures
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 6234:
> 
>> 6232:   orr(hdr, hdr, markWord::unlocked_value);
>> 6233:   // Clear lock-bits, into t2
>> 6234:   eor(t2, hdr, markWord::unlocked_value);
> 
> In arm, I use a combination of bic and orr instead. That gives me, with just two instructions, added safety against someone handing in a "11" marked MW. I know, should never happen, but better safe.
> 
> 
>   ldr(new_hdr, Address(obj, oopDesc::mark_offset_in_bytes()));
>   bic(new_hdr, new_hdr, markWord::lock_mask_in_place);  // new header (00)
>   orr(old_hdr, new_hdr, markWord::unlocked_value);      // old header (01)
> 
> (note that I moved MW loading down into MA::fast_lock for unrelated reasons).
> 
> Unfortunately, on aarch64 there seem to be no bic variants that accept immediates. So it would take one more instruction to get the same result:
> 
> 
> -  // Load (object->mark() | 1) into hdr
> -  orr(hdr, hdr, markWord::unlocked_value);
> -  // Clear lock-bits, into t2
> -  eor(t2, hdr, markWord::unlocked_value);
> +  // Prepare new and old header
> +  mov(t2, markWord::lock_mask_in_place);
> +  bic(t2, hdr, t2);
> +  orr(hdr, t2, markWord::unlocked_value);
> 
> 
> But maybe there is a better way that does not need three instructions.

There is a BFC (Bitfield Clear) pseudo-instruction that uses the BFM instruction.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1154955795

From dlong at openjdk.org  Fri Mar 31 23:13:26 2023
From: dlong at openjdk.org (Dean Long)
Date: Fri, 31 Mar 2023 23:13:26 GMT
Subject: RFR: 8296440: Remove Method* handling from
 cleanup_inline_caches_impl [v5]
In-Reply-To: <sKZLs2RK8I6WtO2kco2VU4vg3QelVnE_jsyhHqZcSxI=.5caf4c6f-5534-44b5-b1af-e2c0c79b6c9e@github.com>
References: <InvMNu2fupXpIdXMVSyxvzRPxaBzaRjNgyLtgmAw9Xg=.7a735894-2afd-4ab2-9d91-07e319a010b2@github.com>
 <sKZLs2RK8I6WtO2kco2VU4vg3QelVnE_jsyhHqZcSxI=.5caf4c6f-5534-44b5-b1af-e2c0c79b6c9e@github.com>
Message-ID: <h2qm2v3hUmZ55uHPdZ7Mi4qFVA2sEXYwkHIetmyHkPw=.0469d84b-8180-4994-bed8-24cfd1b83f48@github.com>

On Wed, 29 Mar 2023 19:54:50 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> This PR replaces cleaning of static stubs in CompiledMethod::cleanup_inline_caches_impl() with a guarantee that it is actually not needed because the holder of the embedded target Method* is alive if the caller nmethod is not unloading.
>> 
>> The holder of the target Method* has to be alive because it is reachable from the caller nmethod's oop pool. This is checked by `check_path_to_callee()` when a statically bound call gets resolved.
>> 
>> C2i entry barriers can be removed for the same reason.
>> 
>> Testing:
>> 
>> Many rounds in our CI testing which includes most JCK and JTREG tests, Renaissance benchmark and SAP specific tests with fastdebug and release builds on the standard platforms plus PPC64.
>> 
>> I've also done tier1 and tier2 tests with -XX:-Inline and tier1 tests with ZGC.
>> 
>> I've started hotspot and jdk tier1 tests with -Xcomp. They were not finished when I stopped them after 24h.
>
> Richard Reingruber has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Check only in debug vm
>  - Merge branch 'master'
>  - Merge branch 'master'
>  - Fix
>  - Feedback Coleene
>  - Adding TestStaticallyBoundTargetIsReachable.java
>  - Path to target exists also if the receiver is a constant of the caller
>  - Use nmethod::oops_do() to search for to_holder in from_nm
>  - Merge branch 'master'
>  - Remove MacroAssembler::resolve_weak_handle()
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/ff368d50...7dd06446

BTW, I experimented with a growable nmethod oops table in JDK-8294002, but ran into problems for reasons I can't remember.  I think reserving a slot per call site would be the safest approach.  However I saw a potential problem with platforms like Aarch64 that appear to store the metadata in two places, the move instruction sequence itself and the relocation metadata slot.  If those two places aren't kept consistent then there could be a situation where the call site oop protects one of the values but not the other.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12802#issuecomment-1492710760