From amitkumar at openjdk.org  Thu Feb  1 02:53:02 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Thu, 1 Feb 2024 02:53:02 GMT
Subject: RFR: 8315762: Update subtype check profile collection on s390x
 following 8308869 [v2]
In-Reply-To: <n8grhee3WqX7jcl4W2vBXtA4XS7rea7CY3zXdl2IP14=.6a4a1adc-1c94-47ff-a93a-75cca3bea65b@github.com>
References: <RhTHep7_5gj7u-skAq-BT1NmLc6cB7i7qq0Dj-ks-lc=.d73379ed-06f5-4294-9926-c54a88198312@github.com>
 <67cqHtFszZQRHZGhqR7LThot4PciYc1tznqzMTV348s=.1c6acb58-170d-44e8-a9ab-171be82f160a@github.com>
 <n8grhee3WqX7jcl4W2vBXtA4XS7rea7CY3zXdl2IP14=.6a4a1adc-1c94-47ff-a93a-75cca3bea65b@github.com>
Message-ID: <UoqWO9zMQcA96n3jsRSCcAZlhZB4RyN9s1S6HYNzdyc=.61de02a7-20a6-4928-b09c-d7b26b017e7e@github.com>

On Wed, 31 Jan 2024 05:54:53 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>So, if you have also run the jtreg test suite with normal settings, that should be ok.


I didn't get new test failure in jtreg, do let me know If anything else you want me to run test for. Otherwise I'll integrate it today.

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

PR Comment: https://git.openjdk.org/jdk/pull/17461#issuecomment-1920400953

From kvn at openjdk.org  Thu Feb  1 03:05:03 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 1 Feb 2024 03:05:03 GMT
Subject: RFR: 8324983: race in CompileBroker::possibly_add_compiler_threads
In-Reply-To: <qd8qOUxvTRbavq4rQT5kvA5ujZFdENBsJr_Ggie9hSM=.f88cdff5-4c45-434c-ad70-7faf7981d7f4@github.com>
References: <qd8qOUxvTRbavq4rQT5kvA5ujZFdENBsJr_Ggie9hSM=.f88cdff5-4c45-434c-ad70-7faf7981d7f4@github.com>
Message-ID: <ls_y-xW9K3FWopI3U1ScWfWAM5d4pdB66b9B48tf0IE=.634b0d48-c95a-4ed2-91e9-0b8f3fc79062@github.com>

On Wed, 31 Jan 2024 21:35:05 GMT, Tom Rodriguez <never at openjdk.org> wrote:

> The number of active compiler threads is decremented before the compiler thread has actually activated so possibly_add_compiler_thread might start a new thread on the existing JavaThread.  This adds a check that it's really exiting before proceeding and some new guarantees that ensure threads aren't started on top running threads.

Good.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17662#pullrequestreview-1855291021

From kvn at openjdk.org  Thu Feb  1 03:36:00 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 1 Feb 2024 03:36:00 GMT
Subject: RFR: 8324833: Signed integer overflows in ABS [v2]
In-Reply-To: <keBLe_kqh25x7IdMWimvIQshpubvKZrP0KPf4Lphoy4=.447c2d2e-3c08-4d85-a9c3-3bd356cfc8a4@github.com>
References: <ohwAn6GqM7FIgYTJNy40VBYSCVEBrrNSqBaz2akN54M=.f9660235-3047-47ee-aad0-ef598d6ebdcc@github.com>
 <keBLe_kqh25x7IdMWimvIQshpubvKZrP0KPf4Lphoy4=.447c2d2e-3c08-4d85-a9c3-3bd356cfc8a4@github.com>
Message-ID: <5uYK-vOT_sbeZXH7DU4k4SCb1do6OOJBt2A3nYd0Yjg=.83d1eadd-2cab-496d-aaab-40d0e4f96d90@github.com>

On Wed, 31 Jan 2024 15:55:25 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the details in the bug. I think current `ABS` implementation is beyond repair, and we should just switch to `uabs`.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug, `all` with `-ftrapv` (now fully passes!)
>>  - [x] Linux x86_64 fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Unnecessary comment

My testing passed.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17617#pullrequestreview-1855316674

From duke at openjdk.org  Thu Feb  1 04:05:40 2024
From: duke at openjdk.org (Lei Zaakjyu)
Date: Thu, 1 Feb 2024 04:05:40 GMT
Subject: RFR: 8325082: Rename headers named 'heapRegion*' of G1
Message-ID: <1MWMgluBwGY-FydUnpoksJ0q5sSvptrNMv6xwDszBQc=.a78cadad-1585-44d1-97d0-a7928fe34d67@github.com>

8325082: Rename headers named 'heapRegion*' of G1

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

Commit messages:
 - rename

Changes: https://git.openjdk.org/jdk/pull/17666/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17666&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8325082
  Stats: 267 lines in 105 files changed: 46 ins; 46 del; 175 mod
  Patch: https://git.openjdk.org/jdk/pull/17666.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17666/head:pull/17666

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

From mdoerr at openjdk.org  Thu Feb  1 04:16:05 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 1 Feb 2024 04:16:05 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v13]
In-Reply-To: <0VhSPW1LosTGWdDukEFCuBFPHfgij50f1xEcDUzERV0=.ca3ac1dc-42a4-498f-9da7-79ed678b85af@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <NhFxqbcwvsAtJJTLMrHRntKKl0EW4QqfHQ8rRyVtgCY=.7d7dd89c-dbd2-485e-b76c-dfe95eff10a2@github.com>
 <LD7xQjA92D2M6JElPhJcBIHxXrQ9GkGU07qmlh8RKNo=.0b1855c9-202a-40aa-9bc3-feb2ca32c70e@github.com>
 <0VhSPW1LosTGWdDukEFCuBFPHfgij50f1xEcDUzERV0=.ca3ac1dc-42a4-498f-9da7-79ed678b85af@github.com>
Message-ID: <BNIMFkvgV2SFuW1zBJi6ys6gmG9NWDC7X8cmiYYrJCk=.2058a638-7d89-4aa1-b6ac-980aebad4154@github.com>

On Wed, 31 Jan 2024 15:06:54 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> src/hotspot/os/aix/os_aix.cpp line 1176:
>> 
>>> 1174:   strncpy(file_path,filename, buffer_length + 1);
>>> 1175:   char* const pointer_to_dot = strrchr(file_path, '.');
>>> 1176:   assert(pointer_to_dot != nullptr, "Attempting to load a shared object without extension? %s", filename);
>> 
>> This should not only be an assertion. I think the check could be used instead of the strcmp below.
>
> I didn't follow that. You mean i need to keep a check if it is null and print it out ?

An assertion is only used for debug builds. Such an error should be handled in product builds as well. I think an attempt to load an invalid library should simply fail. You may add logging if needed.
@tstuefe: Do you agree or have another proposal to handle such errors?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1473772905

From mdoerr at openjdk.org  Thu Feb  1 04:20:05 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 1 Feb 2024 04:20:05 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v13]
In-Reply-To: <BNIMFkvgV2SFuW1zBJi6ys6gmG9NWDC7X8cmiYYrJCk=.2058a638-7d89-4aa1-b6ac-980aebad4154@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <NhFxqbcwvsAtJJTLMrHRntKKl0EW4QqfHQ8rRyVtgCY=.7d7dd89c-dbd2-485e-b76c-dfe95eff10a2@github.com>
 <LD7xQjA92D2M6JElPhJcBIHxXrQ9GkGU07qmlh8RKNo=.0b1855c9-202a-40aa-9bc3-feb2ca32c70e@github.com>
 <0VhSPW1LosTGWdDukEFCuBFPHfgij50f1xEcDUzERV0=.ca3ac1dc-42a4-498f-9da7-79ed678b85af@github.com>
 <BNIMFkvgV2SFuW1zBJi6ys6gmG9NWDC7X8cmiYYrJCk=.2058a638-7d89-4aa1-b6ac-980aebad4154@github.com>
Message-ID: <WGNQFBvUf_L1mySP_fECBFs6A-UhHoEW3KLF61U3jwg=.89036d1a-8006-4ab6-a151-fed8730a8395@github.com>

On Thu, 1 Feb 2024 04:13:52 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> I didn't follow that. You mean i need to keep a check if it is null and print it out ?
>
> An assertion is only used for debug builds. Such an error should be handled in product builds as well. I think an attempt to load an invalid library should simply fail. You may add logging if needed.
> @tstuefe: Do you agree or have another proposal to handle such errors?

In addition, the nullptr check is important to avoid undefined behavior when passing `pointer_to_dot` to any string function.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1473774551

From mdoerr at openjdk.org  Thu Feb  1 04:23:01 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 1 Feb 2024 04:23:01 GMT
Subject: RFR: 8315762: Update subtype check profile collection on s390x
 following 8308869 [v2]
In-Reply-To: <67cqHtFszZQRHZGhqR7LThot4PciYc1tznqzMTV348s=.1c6acb58-170d-44e8-a9ab-171be82f160a@github.com>
References: <RhTHep7_5gj7u-skAq-BT1NmLc6cB7i7qq0Dj-ks-lc=.d73379ed-06f5-4294-9926-c54a88198312@github.com>
 <67cqHtFszZQRHZGhqR7LThot4PciYc1tznqzMTV348s=.1c6acb58-170d-44e8-a9ab-171be82f160a@github.com>
Message-ID: <iQJcAERTJqDWJ9iTNb77G0pVjQM0mGKnJWgAj2tSLWA=.674f5ec1-fdf5-475c-bd6d-304c0a365bbd@github.com>

On Thu, 25 Jan 2024 15:20:59 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> s390x Implementation for https://github.com/openjdk/jdk/pull/14375
>> 
>> Benchmark Result with patch: 
>> 
>> Benchmark                                         (typePollution)  (typePollutionNotInternalType)   Mode  Cnt     Score    Error   Units
>> RequireNonNullCheckcastScalability.isDuplicated1            false                           false  thrpt   20  1155.409 ? 43.844  ops/us
>> RequireNonNullCheckcastScalability.isDuplicated1            false                            true  thrpt   20   726.923 ? 54.536  ops/us
>> RequireNonNullCheckcastScalability.isDuplicated1             true                           false  thrpt   20   676.462 ? 23.503  ops/us
>> RequireNonNullCheckcastScalability.isDuplicated1             true                            true  thrpt   20   118.650 ?  2.653  ops/us
>> 
>> 
>> Without Patch: 
>> 
>> Benchmark                                         (typePollution)  (typePollutionNotInternalType)   Mode  Cnt     Score     Error   Units
>> RequireNonNullCheckcastScalability.isDuplicated1            false                           false  thrpt   20  1101.248 ? 103.559  ops/us
>> RequireNonNullCheckcastScalability.isDuplicated1            false                            true  thrpt   20   109.690 ?   3.312  ops/us
>> RequireNonNullCheckcastScalability.isDuplicated1             true                           false  thrpt   20   110.790 ?   7.927  ops/us
>> RequireNonNullCheckcastScalability.isDuplicated1             true                            true  thrpt   20   112.244 ?   6.889  ops/us
>> 
>> 
>> Testing : Fastdebug build + tier1 tests
>
> Amit Kumar 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' of https://git.openjdk.org/jdk into subtype_v0
>  - s390 Port

It's up to you to test as much as you can.

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

PR Comment: https://git.openjdk.org/jdk/pull/17461#issuecomment-1920476855

From dholmes at openjdk.org  Thu Feb  1 05:25:05 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 1 Feb 2024 05:25:05 GMT
Subject: RFR: 8308745: ObjArrayKlass::allocate_objArray_klass may call into
 java while holding a lock
In-Reply-To: <zsgIr8-Xrh0jfgEEvfwhmlCViCSJuC5-NhUiSGgycgs=.c54cd0a0-11f4-4963-a976-8c63907cdae3@github.com>
References: <zsgIr8-Xrh0jfgEEvfwhmlCViCSJuC5-NhUiSGgycgs=.c54cd0a0-11f4-4963-a976-8c63907cdae3@github.com>
Message-ID: <HpX_QOzL2oYheoEgqM20D63b72-GXXYve75PNSyRRV0=.55ad9299-cc8e-494a-a03a-dbb36b68776f@github.com>

On Wed, 31 Jan 2024 18:57:23 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change uses a claim token to allocate multi dimensional arrays rather than holding MultiArray_lock around metaspace allocation.  We can't hold a mutex around metaspace allocation because it can create an OOM object and it can also call into JVMTI for a resource exhausted event.  Also, we were creating mirrors and more metadata arrays while holding this lock.   See the bug for more details and other ideas considered and rejected.
> 
> Tested with tier1-7.

Can't you just use a Monitor to implement the claim token, rather than this lock-free approach? (Similar to how class initialization is handled.)

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

PR Review: https://git.openjdk.org/jdk/pull/17660#pullrequestreview-1855472920

From dholmes at openjdk.org  Thu Feb  1 05:33:02 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 1 Feb 2024 05:33:02 GMT
Subject: RFR: 8314225: SIGSEGV in JavaThread::is_lock_owned [v2]
In-Reply-To: <Mz39mpaClE4xQWOsfmpgFy8LvLKwWZk1MklPVMFGMSw=.6875bef9-d07a-49ea-a45b-1523695e3bff@github.com>
References: <60li7VMNrwKitU5i3y7_dnQIpTHsJ594rt0f0d-VLiY=.ecb991be-e40d-4182-a82b-9eec718e2d09@github.com>
 <mauY_9I343qsnjVGQuO0a6XobQZWeLqygydaxh6_sPc=.c465c989-cc13-4e40-9216-bda231c3dd9f@github.com>
 <7p5HrBndOFNCb9jcKdZa9kCkzhPuQVXm-TsCRTRmBmM=.e250e2cd-0fa6-47d3-a3ec-4bd92792e16c@github.com>
 <y-2poalC2ncP83cAqjuXgbJ276GAq6KWUiiTQyQK-6w=.2f4a341d-55e3-4a4c-87eb-beafe16a41af@github.com>
 <ah66rcyYlGdgFw3rD7bvZLtlZ60Q1jeugrFu_CQ7YNA=.752cae6a-9fe0-4e44-b573-481190d6cff9@github.com>
 <Mz39mpaClE4xQWOsfmpgFy8LvLKwWZk1MklPVMFGMSw=.6875bef9-d07a-49ea-a45b-1523695e3bff@github.com>
Message-ID: <WNc2aZSu8Qflo_15wgRmnPtlZpOhr4DRRe3Z21uOSI0=.69bb6676-ad6d-4d4f-a665-d8368acb09c6@github.com>

On Wed, 31 Jan 2024 08:04:42 GMT, Dean Long <dlong at openjdk.org> wrote:

> > does "on the native stack" equate to being in a compiled vframe ?? I thought checking the native stack simply found if the BasicObjectLock addr was allocated on the thread's native stack.
> 
> @dholmes-ora Yes, the lock record could be on the native stack in either an interpreter frame or a compiled frame, but I don't know if that's what you mean by being in a compiled vframe. If you mean what is returned by `compiledVFrame::monitors`, that returns all the monitors locked by the compiled frame, both inflated and fast/stack locked.

As monitor chunks were described as temporary storage for moving a monitor from a compiled frame to an interpreter frame, my question is whether checking "on the native stack" will actually find those monitors in compiled frames (or interpreter frames for that matter)? If the answer is yes then I'm starting to see a picture here where we check for all the monitor that can be found in the stack (compiled frames or interpreted frames) then recognize that if deopt is in progress then we scan monitor_chunks for any monitors that might still be transitioning across and only reside in a monitor_chunk. (It is still racy of course).

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

PR Comment: https://git.openjdk.org/jdk/pull/17566#issuecomment-1920544883

From dholmes at openjdk.org  Thu Feb  1 06:11:02 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 1 Feb 2024 06:11:02 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v2]
In-Reply-To: <PHr9SibQP-MYYNF6TY_755mbXeLUGu0kwMP5vVTLzl4=.42a2d871-4fa8-48b1-98c0-0fc6deea87dd@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
 <_DZtn1YhgytowhfOkO-8sus8U759FOVXwWyPT6fMpLs=.c5c540c2-0633-4520-b27c-3fc1f85b927a@github.com>
 <PHr9SibQP-MYYNF6TY_755mbXeLUGu0kwMP5vVTLzl4=.42a2d871-4fa8-48b1-98c0-0fc6deea87dd@github.com>
Message-ID: <gHVLgHYfGkm4I9ng8oVIpUx5d2CJEXkkgCmnWWJMOtA=.9c5d3162-cc43-4584-92e3-0d665d2682c0@github.com>

On Wed, 31 Jan 2024 01:37:42 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add regression test
>
> Many thanks for picking this up @xmas92 . 
> 
> I'm very frustrated that this code got broken the way it has been. Given there are only two options here: actual current thread or else a JVMTI suspended thread we are processing on-behalf of, I'm very tempted to introduce a new API for the latter case to use e.g.: `inflate_for` and `ObjectMonitor::set_owner_to`. When dealing with the suspended thread only very limited situations are actually possible so we don't need all the possible cases to be checked in `inflate` or `enter` - it can just be asserted what state the object/monitor must be in. We can then revert inflate/enter to always and only, act on the current thread. I think the resulting code would be much simpler to understand overall.

> @dholmes-ora I've introduced the code and I am very offended about the way you express your feelings here and elsewhere about it. 

@reinrich  I am sorry if you are offended, that was not my intent, but the code was broken. Two methods clearly had a pre-requisite that they expected to be passed the current thread as "current" and we use that parameter name for clarity so anyone reading the code can safely assume that it is in fact the current thread. We did a lot of code cleanup in this area a few years ago to make it so. At the time I resisted requests to add assertions everywhere to verify that as I thought it unnecessary as the intent was clear, but if they had been present they would have caught this - so that omission is on me. It is perfectly fine that the code can be, and now is, passed a non-current thread, but that should have been made clear through a change to the parameter name - as is now happening - and corrected use of the ResourceMarks. Unfortunately this was also missed by the reviewers at the time, including my partial review (deopt is not my area so I did not look at the code in detail).

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

PR Comment: https://git.openjdk.org/jdk/pull/17626#issuecomment-1920579773

From fyang at openjdk.org  Thu Feb  1 06:12:03 2024
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 1 Feb 2024 06:12:03 GMT
Subject: RFR: 8322179: RISC-V: Implement SHA-1 intrinsic [v7]
In-Reply-To: <CqXCvvyDpYSvPwnKYtI1JKuPgTkK2TB5zCTwFNV0m6s=.cb21d0a6-0fb8-43e9-8a6d-1f8bdc8e4190@github.com>
References: <PyIXzENfiHysFS3IyZn3FDNQpV7Ua2L6OmjiXq9wRoU=.cf74a45e-c94b-4f7b-8768-d10d55e2ce1d@github.com>
 <CqXCvvyDpYSvPwnKYtI1JKuPgTkK2TB5zCTwFNV0m6s=.cb21d0a6-0fb8-43e9-8a6d-1f8bdc8e4190@github.com>
Message-ID: <KGt1PfxG0bZNcY5ea8GQb62sgBqYJpKcb6zyHAd-xsQ=.b2d79641-137e-4e2c-9131-1c21e36dc76a@github.com>

On Mon, 29 Jan 2024 12:23:02 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you review this patch to implement SHA-1 intrinsic for riscv?
>> Thanks!
>> 
>> 
>> ## Test
>> 
>> ### Functionality
>> 
>> tests under `test/hotspot/jtreg/compiler/intrinsics/sha`
>> tests found via `find test/jdk -iname "*SHA1*.java"`
>> 
>> ### Performance
>> 
>> tested on `T-HEAD Light Lichee Pi 4A`
>> 
>> JMH_PARAMS="-f 1 -wi 10 -i 20" // for every loop of jmh test
>> 
>> benchmark tests `MessageDigests.java GetMessageDigest.java MessageDigestBench.java MacBench.java` which are under `test/micro/org/openjdk/bench/`, more spcifically `TESTS="MessageDigests.digest MessageDigests.getAndDigest MessageDigestBench.digest"`
>> 
>> 
>> // After
>> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1        64     DEFAULT  avgt   20      1845.446 ?     27.052  ns/op
>> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    181455.350 ?    532.258  ns/op
>> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2447.674 ?     10.239  ns/op
>> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    182896.083 ?   1242.774  ns/op
>> o.o.b.javax.crypto.small.MessageDigestBench.digest         SHA1     1048576             N/A       N/A              avgt   20  11599227.792 ? 121442.390  ns/op
>> // Before
>> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2352.475 ?    11.198  ns/op
>> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    188495.684 ?  1467.942  ns/op
>> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2437.347 ?     6.398  ns/op
>> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    196086.570 ?  1140.998  ns/op
>> o.o.b.javax.crypto.small.MessageDigestBench.digest         SHA1     1048576             N/A       N/A              avgt   20  12362160.119 ? 38788.109  ns/op
>> 
>> 
>> **getAndDigest when size == 64**
>> The data is not stable for test getAndDigest when size == 64, which I think is introduced by  j.s.MessageDigest.getInstance itself, which we don't touch in this patch.
>> Check more details at [1](ht...
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert string change

src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 5047:

> 5045:       __ add(limit, limit, buf);
> 5046:       __ sub(src, buf, offset);
> 5047:     }

It seems quite tricky and not that readable to let `src` alias `offset`. Could this be simplified by making use of the `x9` register? This is a callee-saved register which I think is not used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17130#discussion_r1473836446

From dholmes at openjdk.org  Thu Feb  1 06:33:02 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 1 Feb 2024 06:33:02 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v3]
In-Reply-To: <-hvTIFa2tVtGb-aHxc_Yyt7vozgICxBRtP6WDN038CU=.66ba0001-5cbe-43b3-b42f-93bb7680498a@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
 <-hvTIFa2tVtGb-aHxc_Yyt7vozgICxBRtP6WDN038CU=.66ba0001-5cbe-43b3-b42f-93bb7680498a@github.com>
Message-ID: <Jrk3IZVblKMrG_TUsoK37rNGjc4ANI6WmOzL8yAiht8=.0ac27818-53cc-43c1-a961-dd7741200e59@github.com>

On Wed, 31 Jan 2024 09:04:09 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The `ObjectSynchronizer` has always assumed that the `current` parameters are both the current thread as well as the thread that is doing the locking. The only time that we are entering on behalf of another thread is when doing re-locking in deoptimization. This has worked because the deoptee thread is suspended. However ResourceMarks have been using the wrong thread when logging is enabled.
>> 
>> This change `ObjectSynchronizer` instruments the relevant methods with both a `JavaThread* locking_thread` as well as `[Java]Thread* current` to be able to use the correct thread for ResourceMarks. 
>> 
>> Having the `inflate` care about a `locking_thread` is a little unpleasant in my opinion. But it is required for LM_LIGHTWEIGHT. 
>> Would probably be cleaner if the inflate for LM_LIGHTWEIGHT was it's own thing, as it does not share the whole INFLATING protocol. But seems like a future RFE to refactor this code.
>> 
>> Can reproduce a crash by modifying `test/jdk/com/sun/jdi/EATests.java` and using `-XX:DiagnoseSyncOnValueBasedClasses=2` with LM_LEGACY or running `test/jdk/com/sun/jdi/EATests.java` with LM_LIGHTWEIGHT/LM_MONITOR and `-Xlog:monitorinflation=trace`. 
>> 
>> Could extend this test to capture this regression in the future (or creating a new test based on the same infrastructure). Will give it an attempt, so we have a regression test for this. But these tests get rather involved as the require a lot of jvmti setup.
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More restrictive API

src/hotspot/share/runtime/synchronizer.cpp line 449:

> 447: 
> 448: // Handle notifications when synchronizing on value based classes
> 449: void ObjectSynchronizer::handle_sync_on_value_based_class(Handle obj, JavaThread* locking_thread) {

Can we add a comment (or even repeat the assertion) that locking thread is either the current thread or a suspended thread, please. This method performs a  number of actions that are not safe to make on an arbitrary thread.

src/hotspot/share/runtime/synchronizer.cpp line 510:

> 508: // of this algorithm. Make sure to update that code if the following function is
> 509: // changed. The implementation is extremely sensitive to race condition. Be careful.
> 510: void ObjectSynchronizer::enter(Handle obj, BasicLock* lock, JavaThread* locking_thread) {

I suggested a new method here for the deopt thread, because I thought much of what is checked in this method is not applicable for the circumstances where we would be dealing with relocking during deopt - and thus the code would be much simpler if we had one method for the current thread, and a much simpler one for the deopt thread. Is that not the case?

src/hotspot/share/runtime/synchronizer.cpp line 1303:

> 1301:   if (LockingMode == LM_LIGHTWEIGHT && current->is_Java_thread()) {
> 1302:     return inflate_for(JavaThread::cast(current), obj, cause);
> 1303:   }

Not quite what I had in mind. I expected the deopt code to call `inflate_for` to make it clear it was a different kind of inflation request.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17626#discussion_r1473844172
PR Review Comment: https://git.openjdk.org/jdk/pull/17626#discussion_r1473849021
PR Review Comment: https://git.openjdk.org/jdk/pull/17626#discussion_r1473848932

From aboldtch at openjdk.org  Thu Feb  1 06:59:05 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 1 Feb 2024 06:59:05 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v3]
In-Reply-To: <-hvTIFa2tVtGb-aHxc_Yyt7vozgICxBRtP6WDN038CU=.66ba0001-5cbe-43b3-b42f-93bb7680498a@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
 <-hvTIFa2tVtGb-aHxc_Yyt7vozgICxBRtP6WDN038CU=.66ba0001-5cbe-43b3-b42f-93bb7680498a@github.com>
Message-ID: <kGkmgfBgCg23WCfpjn7u0GWKxxVLDk8IlKXYimcPe3M=.36ad6600-cdb5-4489-813d-f20b3b19eb1a@github.com>

On Wed, 31 Jan 2024 09:04:09 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The `ObjectSynchronizer` has always assumed that the `current` parameters are both the current thread as well as the thread that is doing the locking. The only time that we are entering on behalf of another thread is when doing re-locking in deoptimization. This has worked because the deoptee thread is suspended. However ResourceMarks have been using the wrong thread when logging is enabled.
>> 
>> This change `ObjectSynchronizer` instruments the relevant methods with both a `JavaThread* locking_thread` as well as `[Java]Thread* current` to be able to use the correct thread for ResourceMarks. 
>> 
>> Having the `inflate` care about a `locking_thread` is a little unpleasant in my opinion. But it is required for LM_LIGHTWEIGHT. 
>> Would probably be cleaner if the inflate for LM_LIGHTWEIGHT was it's own thing, as it does not share the whole INFLATING protocol. But seems like a future RFE to refactor this code.
>> 
>> Can reproduce a crash by modifying `test/jdk/com/sun/jdi/EATests.java` and using `-XX:DiagnoseSyncOnValueBasedClasses=2` with LM_LEGACY or running `test/jdk/com/sun/jdi/EATests.java` with LM_LIGHTWEIGHT/LM_MONITOR and `-Xlog:monitorinflation=trace`. 
>> 
>> Could extend this test to capture this regression in the future (or creating a new test based on the same infrastructure). Will give it an attempt, so we have a regression test for this. But these tests get rather involved as the require a lot of jvmti setup.
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More restrictive API

There is definitely an issue with `ObjectMonitor::enter`. The extended test I added is currently failing with LM_MONITOR. The issue is that the the call to `ObjectMonitor::enter` races with deflation (seems like the monitorinflation trace logging made this race much more likely to happen) . But `ObjectMonitor::enter` asserts that `assert(current->thread_state() != _thread_blocked, "invariant");` before checking for deflation . And because the thread is suspended it is obviously also blocked. (Also seeing a timeout on windows-x64-debug, have to investigate if it is the same cause, it is also with LM_MONITOR)

Given this I believe that it might be the only tenable solution that we restrict the normal `enter` to only the `current` thread and create a new `enter_for` exclusively used by the re-lock code for both ObjectSynchronizer and ObjectMonitor.

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

PR Comment: https://git.openjdk.org/jdk/pull/17626#issuecomment-1920629750

From aboldtch at openjdk.org  Thu Feb  1 07:03:04 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 1 Feb 2024 07:03:04 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v3]
In-Reply-To: <Jrk3IZVblKMrG_TUsoK37rNGjc4ANI6WmOzL8yAiht8=.0ac27818-53cc-43c1-a961-dd7741200e59@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
 <-hvTIFa2tVtGb-aHxc_Yyt7vozgICxBRtP6WDN038CU=.66ba0001-5cbe-43b3-b42f-93bb7680498a@github.com>
 <Jrk3IZVblKMrG_TUsoK37rNGjc4ANI6WmOzL8yAiht8=.0ac27818-53cc-43c1-a961-dd7741200e59@github.com>
Message-ID: <W7CAud-k7n6qYW8RiIVAg3vyHTYvgGNHWAdM56n9wOA=.dd4f266b-a9d8-41b7-97f8-a0d01cccc989@github.com>

On Thu, 1 Feb 2024 06:26:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More restrictive API
>
> src/hotspot/share/runtime/synchronizer.cpp line 1303:
> 
>> 1301:   if (LockingMode == LM_LIGHTWEIGHT && current->is_Java_thread()) {
>> 1302:     return inflate_for(JavaThread::cast(current), obj, cause);
>> 1303:   }
> 
> Not quite what I had in mind. I expected the deopt code to call `inflate_for` to make it clear it was a different kind of inflation request.

I think you are correct that it is more clear that way. Will combine this feedback with @coleenp feedback about have the inflate_impl just take the JavaThread* for LM_LIGHTWEIGHT.

Just need to figure out a parameter name. Might just call it `thread` and add a comment explaining it is something only used by the LM_LIGHTWEIGHT lockingmode.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17626#discussion_r1473882480

From dholmes at openjdk.org  Thu Feb  1 07:11:02 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 1 Feb 2024 07:11:02 GMT
Subject: RFR: 8324983: race in CompileBroker::possibly_add_compiler_threads
In-Reply-To: <qd8qOUxvTRbavq4rQT5kvA5ujZFdENBsJr_Ggie9hSM=.f88cdff5-4c45-434c-ad70-7faf7981d7f4@github.com>
References: <qd8qOUxvTRbavq4rQT5kvA5ujZFdENBsJr_Ggie9hSM=.f88cdff5-4c45-434c-ad70-7faf7981d7f4@github.com>
Message-ID: <xoMpIv8mywi3DseOrxlst3fbjJ0B4iU4dTS_o8lcLMk=.5abd5066-5f01-461a-9ed6-8bb5c9d52f0d@github.com>

On Wed, 31 Jan 2024 21:35:05 GMT, Tom Rodriguez <never at openjdk.org> wrote:

> The number of active compiler threads is decremented before the compiler thread has actually activated so possibly_add_compiler_thread might start a new thread on the existing JavaThread.  This adds a check that it's really exiting before proceeding and some new guarantees that ensure threads aren't started on top running threads.

Changes requested by dholmes (Reviewer).

src/hotspot/share/runtime/javaThread.cpp line 748:

> 746:   // to complete once we've done the notify_all below. Needs a release() to obey Java Memory Model
> 747:   // requirements.
> 748:   guarantee(java_lang_Thread::thread(threadObj()) == thread, "must be alive");

Please make this an assert rather than a guarantee. Only compiler threads can potentially violate this so we should not pay the price of the check for every thread .

src/hotspot/share/runtime/javaThread.cpp line 2160:

> 2158:   // JavaThread* is already visible to JVM/TI via the ThreadsList.
> 2159: 
> 2160:   guarantee(java_lang_Thread::thread(thread_oop()) == nullptr, "must not be alive");

Again please make this an assert.

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

PR Review: https://git.openjdk.org/jdk/pull/17662#pullrequestreview-1855688640
PR Review Comment: https://git.openjdk.org/jdk/pull/17662#discussion_r1473889733
PR Review Comment: https://git.openjdk.org/jdk/pull/17662#discussion_r1473890558

From dholmes at openjdk.org  Thu Feb  1 07:19:04 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 1 Feb 2024 07:19:04 GMT
Subject: RFR: 8325082: Rename headers named 'heapRegion*' of G1
In-Reply-To: <1MWMgluBwGY-FydUnpoksJ0q5sSvptrNMv6xwDszBQc=.a78cadad-1585-44d1-97d0-a7928fe34d67@github.com>
References: <1MWMgluBwGY-FydUnpoksJ0q5sSvptrNMv6xwDszBQc=.a78cadad-1585-44d1-97d0-a7928fe34d67@github.com>
Message-ID: <Ea6rMLVQPxNEux5SU4mKTcw_dSc2nFYaAC4r7Hh0UIA=.953fca0c-dd25-44d3-b735-58352e9b1dc3@github.com>

On Thu, 1 Feb 2024 03:57:48 GMT, Lei Zaakjyu <duke at openjdk.org> wrote:

> 8325082: Rename headers named 'heapRegion*' of G1

src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.cpp line 32:

> 30: #include "gc/g1/g1CardTable.hpp"
> 31: #include "gc/g1/g1ThreadLocalData.hpp"
> 32: #include "gc/g1/g1HeapRegion.hpp"

Drive by comment, but if you make this change you also have to move it to preserve the include order.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17666#discussion_r1473899160

From dholmes at openjdk.org  Thu Feb  1 08:09:03 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 1 Feb 2024 08:09:03 GMT
Subject: RFR: 8320302: compiler/arguments/TestC1Globals.java hits SIGSEGV
 in ContinuationEntry::set_enter_code
In-Reply-To: <1Cm1SGGaZsYxM-RfPNDeAvnGijQ-taVe438SS6bZ3YI=.d64abde2-f9a0-4589-ab40-eba7c3c02992@github.com>
References: <1Cm1SGGaZsYxM-RfPNDeAvnGijQ-taVe438SS6bZ3YI=.d64abde2-f9a0-4589-ab40-eba7c3c02992@github.com>
Message-ID: <rsC787zJZXqxpRt-8zRKUDysucFHUvklklhmD_YvE2U=.9ef04c16-99e1-4f19-8d87-7dbe897c5b74@github.com>

On Tue, 16 Jan 2024 23:33:58 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> When creating Continuation.enterSpecial/doYield special native nmethods we currently assume the call to nmethod::new_native_nmethod() always succeeds. If the CodeCache happens to be full though, creating the nmethod will fail and we'll hit a SIGSEGV when trying to dereference the return value. 
> 
> Since this happens the first time those methods are resolved, throwing an exception at that point implying that we cannot run virtual threads looks odd from a user perspective. So instead I added a step to initialize the Continuation class at startup so that failure to create those nmethods is treated early as a fatal error as we do with any other critical resource needed by the VM. I measured the added step to the startup sequence to be ~90us, or about 0.3% of the total?startup time.
> 
> I verified the fix by running the test mentioned in the bug plus I also run tiers1-5 in mach5.
> 
> Thanks,
> Patricio

Seems reasonable - though I dislike the `fatal` calls.

Will think on it.

Thanks.

src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 1394:

> 1392:                                               oop_maps,
> 1393:                                               exception_offset);
> 1394:     if (nm == nullptr) fatal("Initial size of CodeCache is too small");

It is a pity we can't just use a return of `nullptr` up the call chain to then have `create_vm` call `vm_exit_during_initialization` rather than using a `fatal` here.

I suppose we could use `vm_exit_during_initialization` here, but it is not obvious this code path can only be executed during the initialization process.

src/hotspot/share/runtime/threads.cpp line 416:

> 414: 
> 415:   initialize_class(vmSymbols::jdk_internal_vm_Continuation(), CHECK);
> 416: }

I don't think this needs to be part of the `Threads` API - just inline it where needed.

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

PR Review: https://git.openjdk.org/jdk/pull/17455#pullrequestreview-1855769037
PR Review Comment: https://git.openjdk.org/jdk/pull/17455#discussion_r1473953007
PR Review Comment: https://git.openjdk.org/jdk/pull/17455#discussion_r1473954439

From shade at openjdk.org  Thu Feb  1 08:28:01 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 1 Feb 2024 08:28:01 GMT
Subject: RFR: 8324833: Signed integer overflows in ABS [v2]
In-Reply-To: <keBLe_kqh25x7IdMWimvIQshpubvKZrP0KPf4Lphoy4=.447c2d2e-3c08-4d85-a9c3-3bd356cfc8a4@github.com>
References: <ohwAn6GqM7FIgYTJNy40VBYSCVEBrrNSqBaz2akN54M=.f9660235-3047-47ee-aad0-ef598d6ebdcc@github.com>
 <keBLe_kqh25x7IdMWimvIQshpubvKZrP0KPf4Lphoy4=.447c2d2e-3c08-4d85-a9c3-3bd356cfc8a4@github.com>
Message-ID: <UtFQwtB05wVoyvX25zDYyWEEFSQzsadB7dFR9JIO4LI=.4c4ab4ac-5de6-4fa6-920f-fc5138c042a2@github.com>

On Wed, 31 Jan 2024 15:55:25 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the details in the bug. I think current `ABS` implementation is beyond repair, and we should just switch to `uabs`.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug, `all` with `-ftrapv` (now fully passes!)
>>  - [x] Linux x86_64 fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Unnecessary comment

Thanks! Any other reviews? I am planning to integrate this today.

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

PR Comment: https://git.openjdk.org/jdk/pull/17617#issuecomment-1920757046

From rrich at openjdk.org  Thu Feb  1 09:22:02 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Thu, 1 Feb 2024 09:22:02 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v3]
In-Reply-To: <kGkmgfBgCg23WCfpjn7u0GWKxxVLDk8IlKXYimcPe3M=.36ad6600-cdb5-4489-813d-f20b3b19eb1a@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
 <-hvTIFa2tVtGb-aHxc_Yyt7vozgICxBRtP6WDN038CU=.66ba0001-5cbe-43b3-b42f-93bb7680498a@github.com>
 <kGkmgfBgCg23WCfpjn7u0GWKxxVLDk8IlKXYimcPe3M=.36ad6600-cdb5-4489-813d-f20b3b19eb1a@github.com>
Message-ID: <mjOgJiHMubsURbjuJT5GFoMnhEZRPzFGwptwN3sG6dE=.63d2ab9d-bdde-4c2e-8d3d-f77808f8007c@github.com>

On Thu, 1 Feb 2024 06:56:28 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> There is definitely an issue with `ObjectMonitor::enter`. The extended test I added is currently failing with LM_MONITOR. The issue is that the the call to `ObjectMonitor::enter` races with deflation (seems like the monitorinflation trace logging made this race much more likely to happen) . But `ObjectMonitor::enter` asserts that `assert(current->thread_state() != _thread_blocked, "invariant");` before checking for deflation . And because the thread is suspended it is obviously also blocked. (Also seeing a timeout on windows-x64-debug, have to investigate if it is the same cause, it is also with LM_MONITOR)

Good catch. I think that can really only happen with LM_MONITOR (things where different at the time of JDK-8227745).

> Given this I believe that it might be the only tenable solution that we restrict the normal `enter` to only the `current` thread and create a new `enter_for` exclusively used by the re-lock code for both ObjectSynchronizer and ObjectMonitor.

I think you could also return false in `ObjectMonitor::enter()` [about here](https://github.com/openjdk/jdk/blob/68206b533b09e07e4d556df794414ed4538889c0/src/hotspot/share/runtime/objectMonitor.cpp#L337) if the locking thread is not the current thread. The caller `ObjectSynchronizer::enter()` would then allocate a new monitor and retry.

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

PR Comment: https://git.openjdk.org/jdk/pull/17626#issuecomment-1920865433

From aboldtch at openjdk.org  Thu Feb  1 09:38:27 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 1 Feb 2024 09:38:27 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v4]
In-Reply-To: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
Message-ID: <v3omYG7AsGlssh7MwE1E_MJOZPyNfkd4tyIj0FWWtjA=.88c1d7ac-856d-47d4-ad40-1699613ae678@github.com>

> The `ObjectSynchronizer` has always assumed that the `current` parameters are both the current thread as well as the thread that is doing the locking. The only time that we are entering on behalf of another thread is when doing re-locking in deoptimization. This has worked because the deoptee thread is suspended. However ResourceMarks have been using the wrong thread when logging is enabled.
> 
> This change `ObjectSynchronizer` instruments the relevant methods with both a `JavaThread* locking_thread` as well as `[Java]Thread* current` to be able to use the correct thread for ResourceMarks. 
> 
> Having the `inflate` care about a `locking_thread` is a little unpleasant in my opinion. But it is required for LM_LIGHTWEIGHT. 
> Would probably be cleaner if the inflate for LM_LIGHTWEIGHT was it's own thing, as it does not share the whole INFLATING protocol. But seems like a future RFE to refactor this code.
> 
> Can reproduce a crash by modifying `test/jdk/com/sun/jdi/EATests.java` and using `-XX:DiagnoseSyncOnValueBasedClasses=2` with LM_LEGACY or running `test/jdk/com/sun/jdi/EATests.java` with LM_LIGHTWEIGHT/LM_MONITOR and `-Xlog:monitorinflation=trace`. 
> 
> Could extend this test to capture this regression in the future (or creating a new test based on the same infrastructure). Will give it an attempt, so we have a regression test for this. But these tests get rather involved as the require a lot of jvmti setup.

Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Introduce separate API for enter from a different thread
 - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8324881
 - More restrictive API
 - Add regression test
 - 8324881: ObjectSynchronizer::inflate(Thread* current...) is invoked for non-current thread

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17626/files
  - new: https://git.openjdk.org/jdk/pull/17626/files/2c266a5b..40e127cf

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

  Stats: 5348 lines in 130 files changed: 4246 ins; 687 del; 415 mod
  Patch: https://git.openjdk.org/jdk/pull/17626.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17626/head:pull/17626

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

From aboldtch at openjdk.org  Thu Feb  1 09:44:03 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 1 Feb 2024 09:44:03 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v3]
In-Reply-To: <mjOgJiHMubsURbjuJT5GFoMnhEZRPzFGwptwN3sG6dE=.63d2ab9d-bdde-4c2e-8d3d-f77808f8007c@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
 <-hvTIFa2tVtGb-aHxc_Yyt7vozgICxBRtP6WDN038CU=.66ba0001-5cbe-43b3-b42f-93bb7680498a@github.com>
 <kGkmgfBgCg23WCfpjn7u0GWKxxVLDk8IlKXYimcPe3M=.36ad6600-cdb5-4489-813d-f20b3b19eb1a@github.com>
 <mjOgJiHMubsURbjuJT5GFoMnhEZRPzFGwptwN3sG6dE=.63d2ab9d-bdde-4c2e-8d3d-f77808f8007c@github.com>
Message-ID: <lTha3F3TRlamoRNOWk6udK1U0OrLA4wAgTCwTmfhDTc=.b79a6fd1-4c76-4b97-8202-6a60196f0c8c@github.com>

On Thu, 1 Feb 2024 09:19:20 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> I think you could also return false in `ObjectMonitor::enter()` [about here](https://github.com/openjdk/jdk/blob/68206b533b09e07e4d556df794414ed4538889c0/src/hotspot/share/runtime/objectMonitor.cpp#L337) if the locking thread is not the current thread. The caller `ObjectSynchronizer::enter()` would then allocate a new monitor and retry.

That is an alternative. Let us see what others think. I prefer not changing `ObjectMonitor::enter`.

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

PR Comment: https://git.openjdk.org/jdk/pull/17626#issuecomment-1920905598

From aboldtch at openjdk.org  Thu Feb  1 09:44:04 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 1 Feb 2024 09:44:04 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v4]
In-Reply-To: <v3omYG7AsGlssh7MwE1E_MJOZPyNfkd4tyIj0FWWtjA=.88c1d7ac-856d-47d4-ad40-1699613ae678@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
 <v3omYG7AsGlssh7MwE1E_MJOZPyNfkd4tyIj0FWWtjA=.88c1d7ac-856d-47d4-ad40-1699613ae678@github.com>
Message-ID: <eTE3Yp-ov2ltp3ANleE3hSVRYHp7edmyIuej5iZe3yU=.fd0da877-f4b3-452a-9b93-18b8d3db946e@github.com>

On Thu, 1 Feb 2024 09:38:27 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The `ObjectSynchronizer` has always assumed that the `current` parameters are both the current thread as well as the thread that is doing the locking. The only time that we are entering on behalf of another thread is when doing re-locking in deoptimization. This has worked because the deoptee thread is suspended. However ResourceMarks have been using the wrong thread when logging is enabled.
>> 
>> This change `ObjectSynchronizer` instruments the relevant methods with both a `JavaThread* locking_thread` as well as `[Java]Thread* current` to be able to use the correct thread for ResourceMarks. 
>> 
>> Having the `inflate` care about a `locking_thread` is a little unpleasant in my opinion. But it is required for LM_LIGHTWEIGHT. 
>> Would probably be cleaner if the inflate for LM_LIGHTWEIGHT was it's own thing, as it does not share the whole INFLATING protocol. But seems like a future RFE to refactor this code.
>> 
>> Can reproduce a crash by modifying `test/jdk/com/sun/jdi/EATests.java` and using `-XX:DiagnoseSyncOnValueBasedClasses=2` with LM_LEGACY or running `test/jdk/com/sun/jdi/EATests.java` with LM_LIGHTWEIGHT/LM_MONITOR and `-Xlog:monitorinflation=trace`. 
>> 
>> Could extend this test to capture this regression in the future (or creating a new test based on the same infrastructure). Will give it an attempt, so we have a regression test for this. But these tests get rather involved as the require a lot of jvmti setup.
>
> Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Introduce separate API for enter from a different thread
>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8324881
>  - More restrictive API
>  - Add regression test
>  - 8324881: ObjectSynchronizer::inflate(Thread* current...) is invoked for non-current thread

Still seeing some timeouts after on windows debug. Might be that the monitorinflation trace logging + LM_MONITOR + debug makes this already slow test too slow for the default timeout window in our CI. Looking into it.

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

PR Comment: https://git.openjdk.org/jdk/pull/17626#issuecomment-1920909606

From sroy at openjdk.org  Thu Feb  1 09:45:05 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Thu, 1 Feb 2024 09:45:05 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v13]
In-Reply-To: <WGNQFBvUf_L1mySP_fECBFs6A-UhHoEW3KLF61U3jwg=.89036d1a-8006-4ab6-a151-fed8730a8395@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <NhFxqbcwvsAtJJTLMrHRntKKl0EW4QqfHQ8rRyVtgCY=.7d7dd89c-dbd2-485e-b76c-dfe95eff10a2@github.com>
 <LD7xQjA92D2M6JElPhJcBIHxXrQ9GkGU07qmlh8RKNo=.0b1855c9-202a-40aa-9bc3-feb2ca32c70e@github.com>
 <0VhSPW1LosTGWdDukEFCuBFPHfgij50f1xEcDUzERV0=.ca3ac1dc-42a4-498f-9da7-79ed678b85af@github.com>
 <BNIMFkvgV2SFuW1zBJi6ys6gmG9NWDC7X8cmiYYrJCk=.2058a638-7d89-4aa1-b6ac-980aebad4154@github.com>
 <WGNQFBvUf_L1mySP_fECBFs6A-UhHoEW3KLF61U3jwg=.89036d1a-8006-4ab6-a151-fed8730a8395@github.com>
Message-ID: <92pALpvWlzVEyfziqyJTxCjUH6hEKeKnPinn-8QBB88=.3512f869-674f-4e5a-a8f0-37c09545ef4a@github.com>

On Thu, 1 Feb 2024 04:17:41 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> An assertion is only used for debug builds. Such an error should be handled in product builds as well. I think an attempt to load an invalid library should simply fail. You may add logging if needed.
>> @tstuefe: Do you agree or have another proposal to handle such errors?
>
> In addition, the nullptr check is important to avoid undefined behavior when passing `pointer_to_dot` to any string function.

Ok. So then may be we can return a nullptr and do a   log_info(os) with the correct error report ? @tstuefe @TheRealMDoerr

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1474128334

From rrich at openjdk.org  Thu Feb  1 09:48:07 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Thu, 1 Feb 2024 09:48:07 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v4]
In-Reply-To: <eTE3Yp-ov2ltp3ANleE3hSVRYHp7edmyIuej5iZe3yU=.fd0da877-f4b3-452a-9b93-18b8d3db946e@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
 <v3omYG7AsGlssh7MwE1E_MJOZPyNfkd4tyIj0FWWtjA=.88c1d7ac-856d-47d4-ad40-1699613ae678@github.com>
 <eTE3Yp-ov2ltp3ANleE3hSVRYHp7edmyIuej5iZe3yU=.fd0da877-f4b3-452a-9b93-18b8d3db946e@github.com>
Message-ID: <6XZFmbgcUAljdvuMBv0QjDXnX2RTkmqHXQqviZ26BCU=.964ac924-2256-4a48-b53d-7406b8897ec0@github.com>

On Thu, 1 Feb 2024 09:41:29 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Still seeing some timeouts after on windows debug. Might be that the monitorinflation trace logging + LM_MONITOR + debug makes this already slow test too slow for the default timeout window in our CI. Looking into it.

If there's too much trace output before the debugger attaches you can get a deadlock if the oos pipe buffer fills up with trace output. I think there's a JBS item for that. I'll see if I can find it.

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

PR Comment: https://git.openjdk.org/jdk/pull/17626#issuecomment-1920917046

From rrich at openjdk.org  Thu Feb  1 10:19:03 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Thu, 1 Feb 2024 10:19:03 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v4]
In-Reply-To: <v3omYG7AsGlssh7MwE1E_MJOZPyNfkd4tyIj0FWWtjA=.88c1d7ac-856d-47d4-ad40-1699613ae678@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
 <v3omYG7AsGlssh7MwE1E_MJOZPyNfkd4tyIj0FWWtjA=.88c1d7ac-856d-47d4-ad40-1699613ae678@github.com>
Message-ID: <Y6pFdDojApfPAMCqxr5RWKhjahJN0dnqqIOKRkLoejY=.953b5371-d937-4d63-8766-8b9d95dd3740@github.com>

On Thu, 1 Feb 2024 09:38:27 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The `ObjectSynchronizer` has always assumed that the `current` parameters are both the current thread as well as the thread that is doing the locking. The only time that we are entering on behalf of another thread is when doing re-locking in deoptimization. This has worked because the deoptee thread is suspended. However ResourceMarks have been using the wrong thread when logging is enabled.
>> 
>> This change `ObjectSynchronizer` instruments the relevant methods with both a `JavaThread* locking_thread` as well as `[Java]Thread* current` to be able to use the correct thread for ResourceMarks. 
>> 
>> Having the `inflate` care about a `locking_thread` is a little unpleasant in my opinion. But it is required for LM_LIGHTWEIGHT. 
>> Would probably be cleaner if the inflate for LM_LIGHTWEIGHT was it's own thing, as it does not share the whole INFLATING protocol. But seems like a future RFE to refactor this code.
>> 
>> Can reproduce a crash by modifying `test/jdk/com/sun/jdi/EATests.java` and using `-XX:DiagnoseSyncOnValueBasedClasses=2` with LM_LEGACY or running `test/jdk/com/sun/jdi/EATests.java` with LM_LIGHTWEIGHT/LM_MONITOR and `-Xlog:monitorinflation=trace`. 
>> 
>> Could extend this test to capture this regression in the future (or creating a new test based on the same infrastructure). Will give it an attempt, so we have a regression test for this. But these tests get rather involved as the require a lot of jvmti setup.
>
> Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Introduce separate API for enter from a different thread
>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8324881
>  - More restrictive API
>  - Add regression test
>  - 8324881: ObjectSynchronizer::inflate(Thread* current...) is invoked for non-current thread

src/hotspot/share/runtime/objectMonitor.cpp line 330:

> 328:       assert(_recursions == 0, "invariant");
> 329:       success = true;
> 330:     } else if (prev_owner == locking_thread) {

I thought you would have to handle `LockingMode == LM_LEGACY && locking_thread->is_lock_owned((address)cur) == true`. Could this cause the timeouts?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17626#discussion_r1474183007

From stuefe at openjdk.org  Thu Feb  1 10:34:05 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 1 Feb 2024 10:34:05 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v13]
In-Reply-To: <NhFxqbcwvsAtJJTLMrHRntKKl0EW4QqfHQ8rRyVtgCY=.7d7dd89c-dbd2-485e-b76c-dfe95eff10a2@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <NhFxqbcwvsAtJJTLMrHRntKKl0EW4QqfHQ8rRyVtgCY=.7d7dd89c-dbd2-485e-b76c-dfe95eff10a2@github.com>
Message-ID: <8OXB2hSdtUljShW9BxphktBQGlsmjGATVODGUxeKlho=.7c7f3ee8-bdaf-4723-a8e7-f9829bf3ae41@github.com>

On Wed, 31 Jan 2024 13:17:21 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am.
>> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX.
>> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails.
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   spelling

I'm busy with FOSDEM this week and probably next. Will look at this end of next week or the week after.

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

PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1921004805

From aboldtch at openjdk.org  Thu Feb  1 11:02:07 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 1 Feb 2024 11:02:07 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v4]
In-Reply-To: <Y6pFdDojApfPAMCqxr5RWKhjahJN0dnqqIOKRkLoejY=.953b5371-d937-4d63-8766-8b9d95dd3740@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
 <v3omYG7AsGlssh7MwE1E_MJOZPyNfkd4tyIj0FWWtjA=.88c1d7ac-856d-47d4-ad40-1699613ae678@github.com>
 <Y6pFdDojApfPAMCqxr5RWKhjahJN0dnqqIOKRkLoejY=.953b5371-d937-4d63-8766-8b9d95dd3740@github.com>
Message-ID: <qv-Us4BNwC3tUBqV2DY4hph0E6vvh3viI8Xlx43Ei0A=.4ede78cb-2cb6-48e1-aff0-93fcf7e0d322@github.com>

On Thu, 1 Feb 2024 10:16:14 GMT, Richard Reingruber <rrich 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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Introduce separate API for enter from a different thread
>>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8324881
>>  - More restrictive API
>>  - Add regression test
>>  - 8324881: ObjectSynchronizer::inflate(Thread* current...) is invoked for non-current thread
>
> src/hotspot/share/runtime/objectMonitor.cpp line 330:
> 
>> 328:       assert(_recursions == 0, "invariant");
>> 329:       success = true;
>> 330:     } else if (prev_owner == locking_thread) {
> 
> I thought you would have to handle `LockingMode == LM_LEGACY && locking_thread->is_lock_owned((address)prev_owner) == true`. Could this cause the timeouts?
> 
> (EDIT: fixed copy/past mistake in expression)

It is the ` -XX:LockingMode=0 -Xlog:monitorinflation=trace ` that timeout. 
You are correct that this case should also be handled. 
No tests reach this point. But it should still be reachable. The re-lock code will never cause inflation, but it might relock a lock which was inflated by the current thread (due to hash code) and then relock calls `enter_for`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17626#discussion_r1474249824

From rrich at openjdk.org  Thu Feb  1 11:05:03 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Thu, 1 Feb 2024 11:05:03 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v4]
In-Reply-To: <v3omYG7AsGlssh7MwE1E_MJOZPyNfkd4tyIj0FWWtjA=.88c1d7ac-856d-47d4-ad40-1699613ae678@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
 <v3omYG7AsGlssh7MwE1E_MJOZPyNfkd4tyIj0FWWtjA=.88c1d7ac-856d-47d4-ad40-1699613ae678@github.com>
Message-ID: <GKCRGd5ZmLcSgh5LF7eAfgsuKT2x91KA-_UedrTlAxI=.c1cc2441-d004-4c3c-9923-f88cf4cf2c1d@github.com>

On Thu, 1 Feb 2024 09:38:27 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The `ObjectSynchronizer` has always assumed that the `current` parameters are both the current thread as well as the thread that is doing the locking. The only time that we are entering on behalf of another thread is when doing re-locking in deoptimization. This has worked because the deoptee thread is suspended. However ResourceMarks have been using the wrong thread when logging is enabled.
>> 
>> This change `ObjectSynchronizer` instruments the relevant methods with both a `JavaThread* locking_thread` as well as `[Java]Thread* current` to be able to use the correct thread for ResourceMarks. 
>> 
>> Having the `inflate` care about a `locking_thread` is a little unpleasant in my opinion. But it is required for LM_LIGHTWEIGHT. 
>> Would probably be cleaner if the inflate for LM_LIGHTWEIGHT was it's own thing, as it does not share the whole INFLATING protocol. But seems like a future RFE to refactor this code.
>> 
>> Can reproduce a crash by modifying `test/jdk/com/sun/jdi/EATests.java` and using `-XX:DiagnoseSyncOnValueBasedClasses=2` with LM_LEGACY or running `test/jdk/com/sun/jdi/EATests.java` with LM_LIGHTWEIGHT/LM_MONITOR and `-Xlog:monitorinflation=trace`. 
>> 
>> Could extend this test to capture this regression in the future (or creating a new test based on the same infrastructure). Will give it an attempt, so we have a regression test for this. But these tests get rather involved as the require a lot of jvmti setup.
>
> Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Introduce separate API for enter from a different thread
>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8324881
>  - More restrictive API
>  - Add regression test
>  - 8324881: ObjectSynchronizer::inflate(Thread* current...) is invoked for non-current thread

src/hotspot/share/runtime/objectMonitor.cpp line 345:

> 343:         // success will only be false if this races with something other than
> 344:         // deflation.
> 345:         success = try_set_owner_from(nullptr, locking_thread) == nullptr;

No other race than the race with deflation should be allowed because the current thread would be busy waiting. Better assert success?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17626#discussion_r1474254875

From bulasevich at openjdk.org  Thu Feb  1 11:35:07 2024
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Thu, 1 Feb 2024 11:35:07 GMT
Subject: RFR: 8311248: Refactor CodeCache::initialize_heaps to simplify
 adding new CodeCache segments [v2]
In-Reply-To: <ptdk_7gP95mLvtscrkvayosY0jXq6dxs5lv9p-2S5Aw=.a96fd2e1-4235-485c-a989-7b3cffbb8e1a@github.com>
References: <-V_dgQKhDrt1n0Zbk3qNa276jZBO822NlSvUv9AhpEA=.7a23c712-4b01-4aa7-acbe-8f5b5cca9002@github.com>
 <dAwLqBEQaCQiKFs9xd8GmUAI9yiKlnpKS-hiQVIeQ2k=.72a6733e-d9bf-44d0-8a00-e350c2e59ba8@github.com>
 <ptdk_7gP95mLvtscrkvayosY0jXq6dxs5lv9p-2S5Aw=.a96fd2e1-4235-485c-a989-7b3cffbb8e1a@github.com>
Message-ID: <RT9HOe62UPWoSL7Qf3axKJZfjwrOHgFxbEu5l6ZLURw=.452e2e99-7faf-45a8-86a1-fbebcf0dd31e@github.com>

On Tue, 16 Jan 2024 18:24:17 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> Boris Ulasevich has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   cleanup & test udpdate
>
> src/hotspot/share/code/codeCache.hpp line 120:
> 
>> 118:     return (cache_size > known_segments_size + min_size) ? (cache_size - known_segments_size) : min_size;
>> 119:   }
>> 120: 
> 
> Do we need them in `CodeCache` class and in the hpp file?
> Why not to have them as static functions in the cpp file? In such a case there will to expose the `CodeCacheSegment` struct.

OK

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17244#discussion_r1474300355

From bulasevich at openjdk.org  Thu Feb  1 12:00:10 2024
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Thu, 1 Feb 2024 12:00:10 GMT
Subject: RFR: 8311248: Refactor CodeCache::initialize_heaps to simplify
 adding new CodeCache segments [v4]
In-Reply-To: <C--DAes7ysIEFyGDJcsa1Iu1-xsVTRcWg5rcBUWcX-k=.730f6228-a50b-4d12-84f0-7f89946dbc77@github.com>
References: <-V_dgQKhDrt1n0Zbk3qNa276jZBO822NlSvUv9AhpEA=.7a23c712-4b01-4aa7-acbe-8f5b5cca9002@github.com>
 <_vL8VcUX5WtIwspeQ6xYZZb_Bwe1U9J9Agxk4kb6oaU=.9c6f2cd6-6964-4d82-83c3-1ca5a8039ea7@github.com>
 <7Hc2-ShW7e6KEQq2kXn7MdWF-6tr2-QIFKqSRxtcMzM=.af16d51a-49fa-40be-9eb0-de558470d915@github.com>
 <C--DAes7ysIEFyGDJcsa1Iu1-xsVTRcWg5rcBUWcX-k=.730f6228-a50b-4d12-84f0-7f89946dbc77@github.com>
Message-ID: <w6P58lxjFc6_GChmsoTKQkD5KgILKAQAmILE4i-DygY=.b0282192-c495-40e4-9fa4-38f8f10b9fcb@github.com>

On Mon, 22 Jan 2024 19:45:18 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> src/hotspot/share/code/codeCache.cpp line 196:
>> 
>>> 194: struct CodeHeapInfo {
>>> 195:   size_t size;
>>> 196:   bool set;
>> 
>> IMO, having `CodeBlobType type` member would be useful.
>
> IMO, having `size_t min_size` would be useful.

I am not sure. Let us add it once we really need it in code below

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17244#discussion_r1474337149

From bulasevich at openjdk.org  Thu Feb  1 12:00:13 2024
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Thu, 1 Feb 2024 12:00:13 GMT
Subject: RFR: 8311248: Refactor CodeCache::initialize_heaps to simplify
 adding new CodeCache segments [v4]
In-Reply-To: <hCYKgZeAJ8b60Sag2LDJtlTI7MDg4AN5XlpGZIklsdw=.0e72da4d-b16e-4cba-b44c-44f152853462@github.com>
References: <-V_dgQKhDrt1n0Zbk3qNa276jZBO822NlSvUv9AhpEA=.7a23c712-4b01-4aa7-acbe-8f5b5cca9002@github.com>
 <_vL8VcUX5WtIwspeQ6xYZZb_Bwe1U9J9Agxk4kb6oaU=.9c6f2cd6-6964-4d82-83c3-1ca5a8039ea7@github.com>
 <hCYKgZeAJ8b60Sag2LDJtlTI7MDg4AN5XlpGZIklsdw=.0e72da4d-b16e-4cba-b44c-44f152853462@github.com>
Message-ID: <RdHD6i5xaIVTXyj5ZDbXMRb10Iysm9td9IojboncSXY=.966401bb-3080-445e-adcc-3ccae337235f@github.com>

On Mon, 22 Jan 2024 19:26:47 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> Boris Ulasevich has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   apply suggestions
>
> src/hotspot/share/code/codeCache.cpp line 260:
> 
>> 258:     non_profiled.set = true;
>> 259:     non_profiled.enabled = false;
>> 260:   }
> 
> It can be rewritten to the shorter version:
> 
> // If either heap1 or heap2 is not available, its size is added to the size of the available heap.
> static void reuse_unavailable_heap_size(CodeHeapInfo *heap1, CodeHeapInfo *heap2) {
>    assert(CodeCache::heap_available(heap1->type) || CodeCache::heap_available(heap2->type), "At least one code heap must be available");
>    if (!CodeCache::heap_available(heap1->type)) {
>      swap(heap1, heap2);
>    } else if (CodeCache::heap_available(heap2->type)) {
>      // Both code heaps are available. Nothing needs to be done.
>      return;
>    }
>    heap1->size += heap2->size;
>    heap2->size = 0;
>    heap2->set = true;
>    heap2->enable = false;
> }
> 
> 
> Now we can replace those two IFs with:
> 
> // For compatibility we add the size of an unavailable code heap to the size of the available heap.
> reuse_unavailable_heap_size(&non_profiled, &profiled);

That sounds reasonable. But that is kind of the opposite of what we are doing with this change. We are moving to a plain, simple, readable code.

> src/hotspot/share/code/codeCache.cpp line 264:
> 
>> 262:   size_t compiler_buffer_size = 0;
>> 263:   COMPILER1_PRESENT(compiler_buffer_size += CompilationPolicy::c1_count() * Compiler::code_buffer_size());
>> 264:   COMPILER2_PRESENT(compiler_buffer_size += CompilationPolicy::c2_count() * C2Compiler::initial_code_buffer_size());
> 
> We can move the code inside the following IF.
> We can move ` size_t non_nmethod_min_size = min_cache_size` before the IF and adjust it in the IF.
> This could be simplified with `CodeHeapInfo::min_size`.

size_t compiler_buffer_size = 0;
  COMPILER1_PRESENT(compiler_buffer_size += CompilationPolicy::c1_count() * Compiler::code_buffer_size());
  COMPILER2_PRESENT(compiler_buffer_size += CompilationPolicy::c2_count() * C2Compiler::initial_code_buffer_size());

  if (!non_nmethod.set) {
    non_nmethod.size += compiler_buffer_size;
  }

  ...

  // Compatibility.
  // Override Non-NMethod default size if two other segments are set explicitly
  size_t non_nmethod_min_size = min_cache_size + compiler_buffer_size;
  if (!non_nmethod.set && profiled.set && non_profiled.set) {
    non_nmethod.size = subtract_size(cache_size, profiled.size + non_profiled.size, non_nmethod_min_size);
  }

  ...

  check_min_size("non-nmethod code heap", non_nmethod.size, non_nmethod_min_size)


I do not support idea to move compiler_buffer_size setup under if (!non_nmethod.set).

> src/hotspot/share/code/codeCache.cpp line 272:
> 
>> 270:   if (!profiled.set && !non_profiled.set) {
>> 271:     non_profiled.size = profiled.size = (cache_size > non_nmethod.size + 2 * min_size) ?
>> 272:                                         (cache_size - non_nmethod.size) / 2 : min_size;
> 
> The code calculating default sizes is not simple. Are you sure your code produces the same results?

Yes, I am sure the logic is the same as before

> src/hotspot/share/code/codeCache.cpp line 281:
> 
>> 279:   if (!profiled.set && non_profiled.set) {
>> 280:     profiled.size = subtract_size(cache_size, non_nmethod.size + non_profiled.size, min_size);
>> 281:   }
> 
> `subtract_size` can do subtracting or nothing by return `min_size`. This is not obvious from its name.
> What about a function:
> 
> // Precondition: either or both of heaps must be set.
> //
> // If either of heaps size is not set, its size is set to max(available_size - set_heap.size, min_size).
> static void set_size_of_unset_code_heap(CodeHeapInfo *heap1, CodeHeapInfo *heap2, size_t available_size, size_t min_size) {
>   assert(...); //check precondition
>   if (heap1->set && heap2->set)
>     return;
> 
>   if (!heap2->set)
>     swap(heap1, heap2);
> 
>   heap1->size = (available_size > heap2->size + min_size) ? (available_size - heap2->size) : min_size;
> }
> 
> 
> Now we can unite two IFs into `else` case of `if (!profiled.set && !non_profiled.set)`:
> 
> if (!profiled.set && !non_profiled.set) {
>  ...
> } else {
>   set_size_of_unset_code_heap(&profiled, &non_profiled, cache_size -  non_profiled.size, min_size)
> }

Again. The idea is to move to a plain, simple, readable code, if you don't mind

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17244#discussion_r1474337319
PR Review Comment: https://git.openjdk.org/jdk/pull/17244#discussion_r1474337569
PR Review Comment: https://git.openjdk.org/jdk/pull/17244#discussion_r1474337735
PR Review Comment: https://git.openjdk.org/jdk/pull/17244#discussion_r1474337998

From ihse at openjdk.org  Thu Feb  1 12:02:12 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 1 Feb 2024 12:02:12 GMT
Subject: RFR: 8325109: Sort method modifiers in canonical order
Message-ID: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>

This is a follow-up on [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the bin/blessed-modifier-order.sh on the entire code base, and manually checked the result. I have reverted all but these trivial and uncontroversial changes.

Almost all of these are about moving `static` to its proper position; a few do not involve `static` but instead puts `final` or `abstract` in the correct place.

I have deliberately stayed away from `default` in this PR, since they should probably get a more thorough treatment, see https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473.

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

Commit messages:
 - 8325109: Sort method modifiers in canonical order

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

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

From mli at openjdk.org  Thu Feb  1 12:23:31 2024
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 1 Feb 2024 12:23:31 GMT
Subject: RFR: 8322179: RISC-V: Implement SHA-1 intrinsic [v8]
In-Reply-To: <PyIXzENfiHysFS3IyZn3FDNQpV7Ua2L6OmjiXq9wRoU=.cf74a45e-c94b-4f7b-8768-d10d55e2ce1d@github.com>
References: <PyIXzENfiHysFS3IyZn3FDNQpV7Ua2L6OmjiXq9wRoU=.cf74a45e-c94b-4f7b-8768-d10d55e2ce1d@github.com>
Message-ID: <Wo72eRLr-epmBJmQ1AGdy8xQKcSh1dJVjCP14Shi5LU=.2bd881d5-57f9-4474-afa6-d13b0d00fed9@github.com>

> Hi,
> Can you review this patch to implement SHA-1 intrinsic for riscv?
> Thanks!
> 
> 
> ## Test
> 
> ### Functionality
> 
> tests under `test/hotspot/jtreg/compiler/intrinsics/sha`
> tests found via `find test/jdk -iname "*SHA1*.java"`
> 
> ### Performance
> 
> tested on `T-HEAD Light Lichee Pi 4A`
> 
> JMH_PARAMS="-f 1 -wi 10 -i 20" // for every loop of jmh test
> 
> benchmark tests `MessageDigests.java GetMessageDigest.java MessageDigestBench.java MacBench.java` which are under `test/micro/org/openjdk/bench/`, more spcifically `TESTS="MessageDigests.digest MessageDigests.getAndDigest MessageDigestBench.digest"`
> 
> 
> // After
> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1        64     DEFAULT  avgt   20      1845.446 ?     27.052  ns/op
> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    181455.350 ?    532.258  ns/op
> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2447.674 ?     10.239  ns/op
> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    182896.083 ?   1242.774  ns/op
> o.o.b.javax.crypto.small.MessageDigestBench.digest         SHA1     1048576             N/A       N/A              avgt   20  11599227.792 ? 121442.390  ns/op
> // Before
> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2352.475 ?    11.198  ns/op
> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    188495.684 ?  1467.942  ns/op
> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2437.347 ?     6.398  ns/op
> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    196086.570 ?  1140.998  ns/op
> o.o.b.javax.crypto.small.MessageDigestBench.digest         SHA1     1048576             N/A       N/A              avgt   20  12362160.119 ? 38788.109  ns/op
> 
> 
> **getAndDigest when size == 64**
> The data is not stable for test getAndDigest when size == 64, which I think is introduced by  j.s.MessageDigest.getInstance itself, which we don't touch in this patch.
> Check more details at [1](https://github.com/openjdk/jdk/pull/17130#issuecomment-1886805614)
> 
> 
> loop ... ...

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  use x9 as src

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17130/files
  - new: https://git.openjdk.org/jdk/pull/17130/files/7224b497..50b4e110

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

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

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

From mli at openjdk.org  Thu Feb  1 12:23:32 2024
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 1 Feb 2024 12:23:32 GMT
Subject: RFR: 8322179: RISC-V: Implement SHA-1 intrinsic [v7]
In-Reply-To: <KGt1PfxG0bZNcY5ea8GQb62sgBqYJpKcb6zyHAd-xsQ=.b2d79641-137e-4e2c-9131-1c21e36dc76a@github.com>
References: <PyIXzENfiHysFS3IyZn3FDNQpV7Ua2L6OmjiXq9wRoU=.cf74a45e-c94b-4f7b-8768-d10d55e2ce1d@github.com>
 <CqXCvvyDpYSvPwnKYtI1JKuPgTkK2TB5zCTwFNV0m6s=.cb21d0a6-0fb8-43e9-8a6d-1f8bdc8e4190@github.com>
 <KGt1PfxG0bZNcY5ea8GQb62sgBqYJpKcb6zyHAd-xsQ=.b2d79641-137e-4e2c-9131-1c21e36dc76a@github.com>
Message-ID: <gTBabZHQK-CV8c5iNOMPx1yTk_hvyjIgzolkWJMlh7o=.c37f390b-78fe-4ce0-9ef5-f13209015669@github.com>

On Thu, 1 Feb 2024 06:07:50 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert string change
>
> src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 5047:
> 
>> 5045:       __ add(limit, limit, buf);
>> 5046:       __ sub(src, buf, offset);
>> 5047:     }
> 
> It seems quite tricky and not that readable to let `src` alias `offset`. Could this be simplified by making use of the `x9` register? This is a callee-saved register which I think is not used.

Thanks, updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17130#discussion_r1474370800

From aboldtch at openjdk.org  Thu Feb  1 12:24:10 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 1 Feb 2024 12:24:10 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v4]
In-Reply-To: <GKCRGd5ZmLcSgh5LF7eAfgsuKT2x91KA-_UedrTlAxI=.c1cc2441-d004-4c3c-9923-f88cf4cf2c1d@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
 <v3omYG7AsGlssh7MwE1E_MJOZPyNfkd4tyIj0FWWtjA=.88c1d7ac-856d-47d4-ad40-1699613ae678@github.com>
 <GKCRGd5ZmLcSgh5LF7eAfgsuKT2x91KA-_UedrTlAxI=.c1cc2441-d004-4c3c-9923-f88cf4cf2c1d@github.com>
Message-ID: <v-wgNzz3QF_xO3NWu3iTf5wsOcWwKlJNVlAKy72vxvw=.8c9e980b-6301-4fbe-9bf3-4d3a4074d022@github.com>

On Thu, 1 Feb 2024 11:02:52 GMT, Richard Reingruber <rrich 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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Introduce separate API for enter from a different thread
>>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8324881
>>  - More restrictive API
>>  - Add regression test
>>  - 8324881: ObjectSynchronizer::inflate(Thread* current...) is invoked for non-current thread
>
> src/hotspot/share/runtime/objectMonitor.cpp line 345:
> 
>> 343:         // success will only be false if this races with something other than
>> 344:         // deflation.
>> 345:         success = try_set_owner_from(nullptr, locking_thread) == nullptr;
> 
> No other race than the race with deflation should be allowed because the current thread would be busy waiting. Better assert success?

I was unsure if the `ObjectMonitor::enter_for` should assert this or put it on the caller. 
`ObjectSynchronizer::enter_for` currently asserts `assert(monitor->is_being_async_deflated(), "must be");` when  `ObjectMonitor::enter_for` return false. (An equivalent property)

But I can move it into `ObjectMonitor::enter_for` and attach some more information to the assert such as the prev_owner. Sounds better to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17626#discussion_r1474372456

From aboldtch at openjdk.org  Thu Feb  1 12:40:26 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 1 Feb 2024 12:40:26 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v5]
In-Reply-To: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
Message-ID: <8ZG3rV3o0aWMghASjxkM0qLsha99DcXD-paj7UZXn6k=.b0ffccc4-bf8b-4908-9f88-8476153ebe7c@github.com>

> The `ObjectSynchronizer` has always assumed that the `current` parameters are both the current thread as well as the thread that is doing the locking. The only time that we are entering on behalf of another thread is when doing re-locking in deoptimization. This has worked because the deoptee thread is suspended. However ResourceMarks have been using the wrong thread when logging is enabled.
> 
> This change `ObjectSynchronizer` instruments the relevant methods with both a `JavaThread* locking_thread` as well as `[Java]Thread* current` to be able to use the correct thread for ResourceMarks. 
> 
> Having the `inflate` care about a `locking_thread` is a little unpleasant in my opinion. But it is required for LM_LIGHTWEIGHT. 
> Would probably be cleaner if the inflate for LM_LIGHTWEIGHT was it's own thing, as it does not share the whole INFLATING protocol. But seems like a future RFE to refactor this code.
> 
> Can reproduce a crash by modifying `test/jdk/com/sun/jdi/EATests.java` and using `-XX:DiagnoseSyncOnValueBasedClasses=2` with LM_LEGACY or running `test/jdk/com/sun/jdi/EATests.java` with LM_LIGHTWEIGHT/LM_MONITOR and `-Xlog:monitorinflation=trace`. 
> 
> Could extend this test to capture this regression in the future (or creating a new test based on the same infrastructure). Will give it an attempt, so we have a regression test for this. But these tests get rather involved as the require a lot of jvmti setup.

Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:

  Fix enter_for LockingMode == LM_LEGACY and strengthen assert

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17626/files
  - new: https://git.openjdk.org/jdk/pull/17626/files/40e127cf..080c7922

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

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

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

From rrich at openjdk.org  Thu Feb  1 12:40:26 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Thu, 1 Feb 2024 12:40:26 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v4]
In-Reply-To: <v-wgNzz3QF_xO3NWu3iTf5wsOcWwKlJNVlAKy72vxvw=.8c9e980b-6301-4fbe-9bf3-4d3a4074d022@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
 <v3omYG7AsGlssh7MwE1E_MJOZPyNfkd4tyIj0FWWtjA=.88c1d7ac-856d-47d4-ad40-1699613ae678@github.com>
 <GKCRGd5ZmLcSgh5LF7eAfgsuKT2x91KA-_UedrTlAxI=.c1cc2441-d004-4c3c-9923-f88cf4cf2c1d@github.com>
 <v-wgNzz3QF_xO3NWu3iTf5wsOcWwKlJNVlAKy72vxvw=.8c9e980b-6301-4fbe-9bf3-4d3a4074d022@github.com>
Message-ID: <pBj9trQLsx8EFqDCRqeiP5vyVNQaaBbhqGgISLgx6E8=.728e5986-800a-4f73-84da-8c62e13cda31@github.com>

On Thu, 1 Feb 2024 12:21:17 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> src/hotspot/share/runtime/objectMonitor.cpp line 345:
>> 
>>> 343:         // success will only be false if this races with something other than
>>> 344:         // deflation.
>>> 345:         success = try_set_owner_from(nullptr, locking_thread) == nullptr;
>> 
>> No other race than the race with deflation should be allowed because the current thread would be busy waiting. Better assert success?
>
> I was unsure if the `ObjectMonitor::enter_for` should assert this or put it on the caller. 
> `ObjectSynchronizer::enter_for` currently asserts `assert(monitor->is_being_async_deflated(), "must be");` when  `ObjectMonitor::enter_for` return false. (An equivalent property)
> 
> But I can move it into `ObjectMonitor::enter_for` and attach some more information to the assert such as the prev_owner. Sounds better to me.

Sorry, I overlooked the other assertion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17626#discussion_r1474393974

From lucy at openjdk.org  Thu Feb  1 12:48:02 2024
From: lucy at openjdk.org (Lutz Schmidt)
Date: Thu, 1 Feb 2024 12:48:02 GMT
Subject: RFR: JDK-8324287: Record total and free swap space in JFR [v7]
In-Reply-To: <HixEr_CewtK5kLeHB04M2F5pEI9opND5MvnR2X1Zs2E=.acbac143-812e-4b2d-8afa-391160f2d83d@github.com>
References: <sTxS_0YUXGzN4zUPAsAWukf4m_fYc91uYiun8UjVTII=.39be9e71-e1e5-43c7-b049-9716faea8f32@github.com>
 <HixEr_CewtK5kLeHB04M2F5pEI9opND5MvnR2X1Zs2E=.acbac143-812e-4b2d-8afa-391160f2d83d@github.com>
Message-ID: <TA-VOpGIcVXtopKHue7rYCDH8FgCXmAVwea7Fj9g0rc=.bc8923a3-3030-405e-bf29-53c903242026@github.com>

On Wed, 31 Jan 2024 11:48:05 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Total and free swap space should be recorded in JFR, because it is important to know e.g. in case of memory shortages.
>> 
>> Currently we only have a container related event (ContainerMemoryUsage) that provides some info but no general event.
>> PhysicalMemory could be enhanced or a new event added.
>> 
>> There is already some coding (see Java_com_sun_management_internal_OperatingSystemImpl_getTotalSwapSpaceSize0 and
>> Java_com_sun_management_internal_OperatingSystemImpl_getFreeSwapSpaceSize0) for the swap space info retrieval.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust test

Looks good now.

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

Marked as reviewed by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17581#pullrequestreview-1856404170

From rrich at openjdk.org  Thu Feb  1 12:52:04 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Thu, 1 Feb 2024 12:52:04 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v4]
In-Reply-To: <qv-Us4BNwC3tUBqV2DY4hph0E6vvh3viI8Xlx43Ei0A=.4ede78cb-2cb6-48e1-aff0-93fcf7e0d322@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
 <v3omYG7AsGlssh7MwE1E_MJOZPyNfkd4tyIj0FWWtjA=.88c1d7ac-856d-47d4-ad40-1699613ae678@github.com>
 <Y6pFdDojApfPAMCqxr5RWKhjahJN0dnqqIOKRkLoejY=.953b5371-d937-4d63-8766-8b9d95dd3740@github.com>
 <qv-Us4BNwC3tUBqV2DY4hph0E6vvh3viI8Xlx43Ei0A=.4ede78cb-2cb6-48e1-aff0-93fcf7e0d322@github.com>
Message-ID: <nqoyXYV6zzbgdHscKXlHI6doU378EaDd6Dk1d3Y70F8=.225b062d-e2e1-423e-9575-3e0c5d1d9713@github.com>

On Thu, 1 Feb 2024 10:59:19 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> src/hotspot/share/runtime/objectMonitor.cpp line 330:
>> 
>>> 328:       assert(_recursions == 0, "invariant");
>>> 329:       success = true;
>>> 330:     } else if (prev_owner == locking_thread) {
>> 
>> I thought you would have to handle `LockingMode == LM_LEGACY && locking_thread->is_lock_owned((address)prev_owner) == true`. Could this cause the timeouts?
>> 
>> (EDIT: fixed copy/past mistake in expression)
>
> It is the ` -XX:LockingMode=0 -Xlog:monitorinflation=trace ` that timeout. 
> You are correct that this case should also be handled. 
> No tests reach this point. But it should still be reachable. The re-lock code will never cause inflation, but it might relock a lock which was inflated by the current thread (due to hash code) and then relock calls `enter_for`

This test triggers the case where `prev_owner` is a stack lock with `LM_LEGACY` https://github.com/openjdk/jdk/compare/master...reinrich:jdk:tmp2.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17626#discussion_r1474412703

From mbaesken at openjdk.org  Thu Feb  1 12:53:09 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 1 Feb 2024 12:53:09 GMT
Subject: RFR: JDK-8324287: Record total and free swap space in JFR [v7]
In-Reply-To: <HixEr_CewtK5kLeHB04M2F5pEI9opND5MvnR2X1Zs2E=.acbac143-812e-4b2d-8afa-391160f2d83d@github.com>
References: <sTxS_0YUXGzN4zUPAsAWukf4m_fYc91uYiun8UjVTII=.39be9e71-e1e5-43c7-b049-9716faea8f32@github.com>
 <HixEr_CewtK5kLeHB04M2F5pEI9opND5MvnR2X1Zs2E=.acbac143-812e-4b2d-8afa-391160f2d83d@github.com>
Message-ID: <FGds8yB_5HJKjf7xaGUpUe7rsGI9x_kCHyqJHRAbvdE=.7adeaf49-f3fd-4ee8-95e4-30cc710030ed@github.com>

On Wed, 31 Jan 2024 11:48:05 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Total and free swap space should be recorded in JFR, because it is important to know e.g. in case of memory shortages.
>> 
>> Currently we only have a container related event (ContainerMemoryUsage) that provides some info but no general event.
>> PhysicalMemory could be enhanced or a new event added.
>> 
>> There is already some coding (see Java_com_sun_management_internal_OperatingSystemImpl_getTotalSwapSpaceSize0 and
>> Java_com_sun_management_internal_OperatingSystemImpl_getFreeSwapSpaceSize0) for the swap space info retrieval.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust test

Thanks for the reviews!
The container related free swap space could be addressed in a follow-up.

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

PR Comment: https://git.openjdk.org/jdk/pull/17581#issuecomment-1921256576

From mbaesken at openjdk.org  Thu Feb  1 12:53:10 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 1 Feb 2024 12:53:10 GMT
Subject: Integrated: JDK-8324287: Record total and free swap space in JFR
In-Reply-To: <sTxS_0YUXGzN4zUPAsAWukf4m_fYc91uYiun8UjVTII=.39be9e71-e1e5-43c7-b049-9716faea8f32@github.com>
References: <sTxS_0YUXGzN4zUPAsAWukf4m_fYc91uYiun8UjVTII=.39be9e71-e1e5-43c7-b049-9716faea8f32@github.com>
Message-ID: <CWOWdQohG7ztmc79AcC-30lAztHyRWCb8tj6RoKjaFo=.2bb0d4ed-8b73-416d-829d-c4b72a71bd49@github.com>

On Fri, 26 Jan 2024 07:54:22 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Total and free swap space should be recorded in JFR, because it is important to know e.g. in case of memory shortages.
> 
> Currently we only have a container related event (ContainerMemoryUsage) that provides some info but no general event.
> PhysicalMemory could be enhanced or a new event added.
> 
> There is already some coding (see Java_com_sun_management_internal_OperatingSystemImpl_getTotalSwapSpaceSize0 and
> Java_com_sun_management_internal_OperatingSystemImpl_getFreeSwapSpaceSize0) for the swap space info retrieval.

This pull request has now been integrated.

Changeset: cab74b07
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cab74b075e4572529a21bf8ac652ec2f1ab4fcaf
Stats:     178 lines in 11 files changed: 177 ins; 0 del; 1 mod

8324287: Record total and free swap space in JFR

Reviewed-by: jbechberger, lucy, egahlin

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

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

From mdoerr at openjdk.org  Thu Feb  1 13:17:06 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 1 Feb 2024 13:17:06 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v13]
In-Reply-To: <92pALpvWlzVEyfziqyJTxCjUH6hEKeKnPinn-8QBB88=.3512f869-674f-4e5a-a8f0-37c09545ef4a@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <NhFxqbcwvsAtJJTLMrHRntKKl0EW4QqfHQ8rRyVtgCY=.7d7dd89c-dbd2-485e-b76c-dfe95eff10a2@github.com>
 <LD7xQjA92D2M6JElPhJcBIHxXrQ9GkGU07qmlh8RKNo=.0b1855c9-202a-40aa-9bc3-feb2ca32c70e@github.com>
 <0VhSPW1LosTGWdDukEFCuBFPHfgij50f1xEcDUzERV0=.ca3ac1dc-42a4-498f-9da7-79ed678b85af@github.com>
 <BNIMFkvgV2SFuW1zBJi6ys6gmG9NWDC7X8cmiYYrJCk=.2058a638-7d89-4aa1-b6ac-980aebad4154@github.com>
 <WGNQFBvUf_L1mySP_fECBFs6A-UhHoEW3KLF61U3jwg=.89036d1a-8006-4ab6-a151-fed8730a8395@github.com>
 <92pALpvWlzVEyfziqyJTxCjUH6hEKeKnPinn-8QBB88=.3512f869-674f-4e5a-a8f0-37c09545ef4a@github.com>
Message-ID: <DDznuJCDhx2PYTTbQfGVGZghoi4EDySycXddx4Woftk=.95308c09-94fd-471c-94be-848ec11672db@github.com>

On Thu, 1 Feb 2024 09:42:00 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> In addition, the nullptr check is important to avoid undefined behavior when passing `pointer_to_dot` to any string function.
>
> Ok. So then may be we can return a nullptr and do a   log_info(os) with the correct error report ? @tstuefe @TheRealMDoerr

I'd probably use `log_info(library)`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1474449287

From dfuchs at openjdk.org  Thu Feb  1 13:43:00 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 1 Feb 2024 13:43:00 GMT
Subject: RFR: 8325109: Sort method modifiers in canonical order
In-Reply-To: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
References: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
Message-ID: <8VqjbOBjkNCr7PmXABZ1xmQqvF0jidmGyIMNUdKQDww=.8ffdc2ac-023f-4b79-ac5a-9ef541af68a7@github.com>

On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a follow-up on [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the bin/blessed-modifier-order.sh on the entire code base, and manually checked the result. I have reverted all but these trivial and uncontroversial changes.
> 
> Almost all of these are about moving `static` to its proper position; a few do not involve `static` but instead puts `final` or `abstract` in the correct place.
> 
> I have deliberately stayed away from `default` in this PR, since they should probably get a more thorough treatment, see https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473.

Changes to IPAdressUtil look fine. I eyeballed the rest and didn't spot any issue.

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

PR Review: https://git.openjdk.org/jdk/pull/17670#pullrequestreview-1856519410

From dcubed at openjdk.org  Thu Feb  1 14:12:03 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 1 Feb 2024 14:12:03 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v3]
In-Reply-To: <Jrk3IZVblKMrG_TUsoK37rNGjc4ANI6WmOzL8yAiht8=.0ac27818-53cc-43c1-a961-dd7741200e59@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
 <-hvTIFa2tVtGb-aHxc_Yyt7vozgICxBRtP6WDN038CU=.66ba0001-5cbe-43b3-b42f-93bb7680498a@github.com>
 <Jrk3IZVblKMrG_TUsoK37rNGjc4ANI6WmOzL8yAiht8=.0ac27818-53cc-43c1-a961-dd7741200e59@github.com>
Message-ID: <xCDNaUZdAkY1Y9WbMPC6u0JuSXjJXZ7JycmvkzrCR2E=.4a5bf91d-748a-4701-83d0-737e7ebb0555@github.com>

On Thu, 1 Feb 2024 06:19:46 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More restrictive API
>
> src/hotspot/share/runtime/synchronizer.cpp line 449:
> 
>> 447: 
>> 448: // Handle notifications when synchronizing on value based classes
>> 449: void ObjectSynchronizer::handle_sync_on_value_based_class(Handle obj, JavaThread* locking_thread) {
> 
> Can we add a comment (or even repeat the assertion) that locking thread is either the current thread or a suspended thread, please. This method performs a  number of actions that are not safe to make on an arbitrary thread.

I breezed right by this function... where did that come from?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17626#discussion_r1474537884

From dcubed at openjdk.org  Thu Feb  1 14:17:05 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 1 Feb 2024 14:17:05 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v4]
In-Reply-To: <6XZFmbgcUAljdvuMBv0QjDXnX2RTkmqHXQqviZ26BCU=.964ac924-2256-4a48-b53d-7406b8897ec0@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
 <v3omYG7AsGlssh7MwE1E_MJOZPyNfkd4tyIj0FWWtjA=.88c1d7ac-856d-47d4-ad40-1699613ae678@github.com>
 <eTE3Yp-ov2ltp3ANleE3hSVRYHp7edmyIuej5iZe3yU=.fd0da877-f4b3-452a-9b93-18b8d3db946e@github.com>
 <6XZFmbgcUAljdvuMBv0QjDXnX2RTkmqHXQqviZ26BCU=.964ac924-2256-4a48-b53d-7406b8897ec0@github.com>
Message-ID: <ZTwzGZxLiUqIBLxzLKafDgxN1WFOggGhc0WkOWIg1FQ=.bbff7ed4-dab7-4154-94e4-adb9b57119b9@github.com>

On Thu, 1 Feb 2024 09:45:10 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> If there's too much trace output before the debugger attaches you can get a deadlock if the os pipe buffer fills up with trace output.

What I do in my stress kit runs is redirect the logging output to `../monitorinflation.log`.
The logging doesn't seem to slow things down that much anymore. Probably because
there's no ttyLock usage that way. The reason for the "../" is so that the log is not cleaned
up when the test passes.

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

PR Comment: https://git.openjdk.org/jdk/pull/17626#issuecomment-1921433824

From dcubed at openjdk.org  Thu Feb  1 14:17:06 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 1 Feb 2024 14:17:06 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v3]
In-Reply-To: <xCDNaUZdAkY1Y9WbMPC6u0JuSXjJXZ7JycmvkzrCR2E=.4a5bf91d-748a-4701-83d0-737e7ebb0555@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
 <-hvTIFa2tVtGb-aHxc_Yyt7vozgICxBRtP6WDN038CU=.66ba0001-5cbe-43b3-b42f-93bb7680498a@github.com>
 <Jrk3IZVblKMrG_TUsoK37rNGjc4ANI6WmOzL8yAiht8=.0ac27818-53cc-43c1-a961-dd7741200e59@github.com>
 <xCDNaUZdAkY1Y9WbMPC6u0JuSXjJXZ7JycmvkzrCR2E=.4a5bf91d-748a-4701-83d0-737e7ebb0555@github.com>
Message-ID: <wF9tInxlLKpz0P7Uju4BKmF0z53LwE2E6BHarkwa8W8=.9756cc2a-20cb-4cc3-9871-cf0075d36747@github.com>

On Thu, 1 Feb 2024 14:09:04 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> src/hotspot/share/runtime/synchronizer.cpp line 449:
>> 
>>> 447: 
>>> 448: // Handle notifications when synchronizing on value based classes
>>> 449: void ObjectSynchronizer::handle_sync_on_value_based_class(Handle obj, JavaThread* locking_thread) {
>> 
>> Can we add a comment (or even repeat the assertion) that locking thread is either the current thread or a suspended thread, please. This method performs a  number of actions that are not safe to make on an arbitrary thread.
>
> I breezed right by this function... where did that come from?

Sorry, rhetorical question. I can figure out where it came from (and how I missed seeing it).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17626#discussion_r1474544439

From aivanov at openjdk.org  Thu Feb  1 14:44:02 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 1 Feb 2024 14:44:02 GMT
Subject: RFR: 8325109: Sort method modifiers in canonical order
In-Reply-To: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
References: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
Message-ID: <uj6X0EkJ7Id9yviBJdcfrEINU46lON8sZkDN2xF5OB4=.bd123c3f-d79e-46e8-8a5f-241b4a50390e@github.com>

On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a follow-up on [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the bin/blessed-modifier-order.sh on the entire code base, and manually checked the result. I have reverted all but these trivial and uncontroversial changes.
> 
> Almost all of these are about moving `static` to its proper position; a few do not involve `static` but instead puts `final` or `abstract` in the correct place.
> 
> I have deliberately stayed away from `default` in this PR, since they should probably get a more thorough treatment, see https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473.

Looks good to me.

I looked through all the changes.

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17670#pullrequestreview-1856683827

From eastigeevich at openjdk.org  Thu Feb  1 15:15:03 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Thu, 1 Feb 2024 15:15:03 GMT
Subject: RFR: 8311248: Refactor CodeCache::initialize_heaps to simplify
 adding new CodeCache segments [v4]
In-Reply-To: <RdHD6i5xaIVTXyj5ZDbXMRb10Iysm9td9IojboncSXY=.966401bb-3080-445e-adcc-3ccae337235f@github.com>
References: <-V_dgQKhDrt1n0Zbk3qNa276jZBO822NlSvUv9AhpEA=.7a23c712-4b01-4aa7-acbe-8f5b5cca9002@github.com>
 <_vL8VcUX5WtIwspeQ6xYZZb_Bwe1U9J9Agxk4kb6oaU=.9c6f2cd6-6964-4d82-83c3-1ca5a8039ea7@github.com>
 <hCYKgZeAJ8b60Sag2LDJtlTI7MDg4AN5XlpGZIklsdw=.0e72da4d-b16e-4cba-b44c-44f152853462@github.com>
 <RdHD6i5xaIVTXyj5ZDbXMRb10Iysm9td9IojboncSXY=.966401bb-3080-445e-adcc-3ccae337235f@github.com>
Message-ID: <_pCfQFt76UhuuS57Ok-SVsbbdwl7oCL7wKFcHi34aEY=.dee55198-96cf-4599-b180-2281201d0896@github.com>

On Thu, 1 Feb 2024 11:56:58 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

> Again. The idea is to move to a plain, simple, readable code, if you don't mind

I don't think `subtract_size` is a good name for the function.
Why does it have three parameters? Logically a subtract operation is `a - b`. A reader of the code will have to go to the definition of the function to understand its logic. This means you can save reader's time just putting the code of `subtract_size` in place or giving more meaningful name.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17244#discussion_r1474638850

From sgehwolf at openjdk.org  Thu Feb  1 15:45:09 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 1 Feb 2024 15:45:09 GMT
Subject: RFR: JDK-8324287: Record total and free swap space in JFR [v7]
In-Reply-To: <FGds8yB_5HJKjf7xaGUpUe7rsGI9x_kCHyqJHRAbvdE=.7adeaf49-f3fd-4ee8-95e4-30cc710030ed@github.com>
References: <sTxS_0YUXGzN4zUPAsAWukf4m_fYc91uYiun8UjVTII=.39be9e71-e1e5-43c7-b049-9716faea8f32@github.com>
 <HixEr_CewtK5kLeHB04M2F5pEI9opND5MvnR2X1Zs2E=.acbac143-812e-4b2d-8afa-391160f2d83d@github.com>
 <FGds8yB_5HJKjf7xaGUpUe7rsGI9x_kCHyqJHRAbvdE=.7adeaf49-f3fd-4ee8-95e4-30cc710030ed@github.com>
Message-ID: <cbmLubgy46UWJqEsBMPZ-z_5xhc1lLnbI5o8g6D0llE=.7ed33b51-cb98-4e6b-86c6-c589c7d4031a@github.com>

On Thu, 1 Feb 2024 12:49:32 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The container related free swap space could be addressed in a follow-up.

@MBaesken Please file a bug for this follow-up. Thank you!

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

PR Comment: https://git.openjdk.org/jdk/pull/17581#issuecomment-1921620063

From mbaesken at openjdk.org  Thu Feb  1 16:28:11 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 1 Feb 2024 16:28:11 GMT
Subject: RFR: JDK-8324287: Record total and free swap space in JFR [v7]
In-Reply-To: <cbmLubgy46UWJqEsBMPZ-z_5xhc1lLnbI5o8g6D0llE=.7ed33b51-cb98-4e6b-86c6-c589c7d4031a@github.com>
References: <sTxS_0YUXGzN4zUPAsAWukf4m_fYc91uYiun8UjVTII=.39be9e71-e1e5-43c7-b049-9716faea8f32@github.com>
 <HixEr_CewtK5kLeHB04M2F5pEI9opND5MvnR2X1Zs2E=.acbac143-812e-4b2d-8afa-391160f2d83d@github.com>
 <FGds8yB_5HJKjf7xaGUpUe7rsGI9x_kCHyqJHRAbvdE=.7adeaf49-f3fd-4ee8-95e4-30cc710030ed@github.com>
 <cbmLubgy46UWJqEsBMPZ-z_5xhc1lLnbI5o8g6D0llE=.7ed33b51-cb98-4e6b-86c6-c589c7d4031a@github.com>
Message-ID: <fDQwJPTp-bt-uErALenWCJ8HCRhHgm7-99-maE0G9bM=.301e66bc-72bf-41bc-a20d-0c497322ec87@github.com>

On Thu, 1 Feb 2024 15:42:10 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> > The container related free swap space could be addressed in a follow-up.
> 
> @MBaesken Please file a bug for this follow-up. Thank you!

Hi Severin I created 

https://bugs.openjdk.org/browse/JDK-8325139
JFR SwapSpace event - add free swap space information on Linux when running in a container environment 

please comment on the JBS issue if you have good info regarding the topic ...

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

PR Comment: https://git.openjdk.org/jdk/pull/17581#issuecomment-1921709712

From rriggs at openjdk.org  Thu Feb  1 17:02:01 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 1 Feb 2024 17:02:01 GMT
Subject: RFR: 8325109: Sort method modifiers in canonical order
In-Reply-To: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
References: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
Message-ID: <E28xCC3i0n7CBNbkZDdvbd8kDHlZdAfF0o_OrhT88ng=.79424bfe-ea1d-4015-a15b-de98635b7d05@github.com>

On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a follow-up on [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the bin/blessed-modifier-order.sh on the entire code base, and manually checked the result. I have reverted all but these trivial and uncontroversial changes.
> 
> Almost all of these are about moving `static` to its proper position; a few do not involve `static` but instead puts `final` or `abstract` in the correct place.
> 
> I have deliberately stayed away from `default` in this PR, since they should probably get a more thorough treatment, see https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473.

lgtm; all look good

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17670#pullrequestreview-1857031136

From darcy at openjdk.org  Thu Feb  1 17:24:01 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 1 Feb 2024 17:24:01 GMT
Subject: RFR: 8325109: Sort method modifiers in canonical order
In-Reply-To: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
References: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
Message-ID: <uY6CoY9NwuiOEmWivsV3k5OEdoBB4ETOCiK2fo0mDLU=.7ec4beb3-66b9-4076-8aa6-2caa221023bf@github.com>

On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a follow-up on [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the bin/blessed-modifier-order.sh on the entire code base, and manually checked the result. I have reverted all but these trivial and uncontroversial changes.
> 
> Almost all of these are about moving `static` to its proper position; a few do not involve `static` but instead puts `final` or `abstract` in the correct place.
> 
> I have deliberately stayed away from `default` in this PR, since they should probably get a more thorough treatment, see https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473.

Looks fine; I just suggest double-checking on the current maintenance procedures for the java.util.concurrent code.

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

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17670#pullrequestreview-1857088376

From never at openjdk.org  Thu Feb  1 17:37:28 2024
From: never at openjdk.org (Tom Rodriguez)
Date: Thu, 1 Feb 2024 17:37:28 GMT
Subject: RFR: 8324983: race in CompileBroker::possibly_add_compiler_threads
 [v2]
In-Reply-To: <qd8qOUxvTRbavq4rQT5kvA5ujZFdENBsJr_Ggie9hSM=.f88cdff5-4c45-434c-ad70-7faf7981d7f4@github.com>
References: <qd8qOUxvTRbavq4rQT5kvA5ujZFdENBsJr_Ggie9hSM=.f88cdff5-4c45-434c-ad70-7faf7981d7f4@github.com>
Message-ID: <H1Tdo8BVGgjadqg-WL5zE_9tftk7Nfsl5pffxHofLKk=.8b659942-1e54-4071-b9e9-4c932a07dc3e@github.com>

> The number of active compiler threads is decremented before the compiler thread has actually activated so possibly_add_compiler_thread might start a new thread on the existing JavaThread.  This adds a check that it's really exiting before proceeding and some new guarantees that ensure threads aren't started on top running threads.

Tom Rodriguez has updated the pull request incrementally with one additional commit since the last revision:

  Convert guarantee to assert

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17662/files
  - new: https://git.openjdk.org/jdk/pull/17662/files/93145119..7bc1ab8c

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

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

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

From never at openjdk.org  Thu Feb  1 17:37:28 2024
From: never at openjdk.org (Tom Rodriguez)
Date: Thu, 1 Feb 2024 17:37:28 GMT
Subject: RFR: 8324983: race in CompileBroker::possibly_add_compiler_threads
 [v2]
In-Reply-To: <xoMpIv8mywi3DseOrxlst3fbjJ0B4iU4dTS_o8lcLMk=.5abd5066-5f01-461a-9ed6-8bb5c9d52f0d@github.com>
References: <qd8qOUxvTRbavq4rQT5kvA5ujZFdENBsJr_Ggie9hSM=.f88cdff5-4c45-434c-ad70-7faf7981d7f4@github.com>
 <xoMpIv8mywi3DseOrxlst3fbjJ0B4iU4dTS_o8lcLMk=.5abd5066-5f01-461a-9ed6-8bb5c9d52f0d@github.com>
Message-ID: <O-rdDVrab2pCafA6e19aRXSysqp94ROAk4tR4P6kpIs=.801e7cc1-0a2a-4bb8-8792-d41a89623a5d@github.com>

On Thu, 1 Feb 2024 07:07:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Tom Rodriguez has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Convert guarantee to assert
>
> src/hotspot/share/runtime/javaThread.cpp line 748:
> 
>> 746:   // to complete once we've done the notify_all below. Needs a release() to obey Java Memory Model
>> 747:   // requirements.
>> 748:   guarantee(java_lang_Thread::thread(threadObj()) == thread, "must be alive");
> 
> Please make this an assert rather than a guarantee. Only compiler threads can potentially violate this so we should not pay the price of the check for every thread .

Ok.  It's not exactly an expensive test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17662#discussion_r1474848832

From dnsimon at openjdk.org  Thu Feb  1 18:16:01 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 1 Feb 2024 18:16:01 GMT
Subject: RFR: 8324983: race in CompileBroker::possibly_add_compiler_threads
 [v2]
In-Reply-To: <H1Tdo8BVGgjadqg-WL5zE_9tftk7Nfsl5pffxHofLKk=.8b659942-1e54-4071-b9e9-4c932a07dc3e@github.com>
References: <qd8qOUxvTRbavq4rQT5kvA5ujZFdENBsJr_Ggie9hSM=.f88cdff5-4c45-434c-ad70-7faf7981d7f4@github.com>
 <H1Tdo8BVGgjadqg-WL5zE_9tftk7Nfsl5pffxHofLKk=.8b659942-1e54-4071-b9e9-4c932a07dc3e@github.com>
Message-ID: <fruy57ns3U8piiXCl4rAdzSXH0CBfUMSX-daQ_dO-Pw=.ab8ceb56-7e68-414f-be21-d59534736847@github.com>

On Thu, 1 Feb 2024 17:37:28 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> The number of active compiler threads is decremented before the compiler thread has actually activated so possibly_add_compiler_thread might start a new thread on the existing JavaThread.  This adds a check that it's really exiting before proceeding and some new guarantees that ensure threads aren't started on top running threads.
>
> Tom Rodriguez has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Convert guarantee to assert

Marked as reviewed by dnsimon (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17662#pullrequestreview-1857207940

From dcubed at openjdk.org  Thu Feb  1 18:17:06 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 1 Feb 2024 18:17:06 GMT
Subject: RFR: 8319797: Recursive lightweight locking: Runtime
 implementation [v16]
In-Reply-To: <8QYhYxEf3TYCwrrN430BZuaY4zYhK0sd2x8BTCaAojI=.96c15000-b013-41e6-8a94-5e3e6f95172c@github.com>
References: <ZWyjRIBdi5FeGTDfaIEmT_lBfg1n9MDl3vxA5g-FKbc=.cb26afcc-555b-4a80-b4f2-319c5422646b@github.com>
 <8QYhYxEf3TYCwrrN430BZuaY4zYhK0sd2x8BTCaAojI=.96c15000-b013-41e6-8a94-5e3e6f95172c@github.com>
Message-ID: <m0yixjU0pqczTaC5Z65I6d1JXSqc1tcozIXQo8aBK04=.b99ec54a-26cf-4f81-b6e2-5866e0d43d6d@github.com>

On Mon, 29 Jan 2024 06:42:46 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Implements the runtime part of JDK-8319796.
>> The different CPU implementations are/will be created as dependent pull requests.
>> 
>> This enhancement proposes introducing the ability for LM_LIGHTWEIGHT to handle consecutive recursive monitor enter. Limiting the implementation to only consecutive monitor enters allows for more efficient emitted code which only needs to look at the two top most entires on the lock stack to determine what to do in a monitor exit.
>> 
>> A high level overview:
>>   * Locking is still performed on the mark word
>>     * Unlocked (0b01) <=> Locked (0b00)
>>   * Monitor enter on Obj with mark word Unlocked (0b01) is the same
>>     * Transition Obj's mark word Unlocked (0b01) => Locked (0b00)
>>     * Push Obj onto the lock stack
>>     * Success
>>   * Monitor enter on Obj with mark word Locked (0b00) will check the top entry on the lock stack
>>     * If top entry is Obj
>>       * Push Obj on the lock stack
>>       * Success
>>     * If top entry is not Obj
>>       * Inflate and call ObjectMonitor::enter
>>   * Monitor exit on Obj with mark word Locked (0b00) will check the two top entries on the lock stack
>>     * If just the top entry is Obj
>>       * Transition Obj's mark word Locked (0b00) => Unlocked (0b01)
>>       * Pop the entry
>>       * Success
>>     * If both entries are Obj
>>       * Pop the top entry
>>       * Success
>>     * Any other case only occurs for unstructured locking, then just inflate and call ObjectMonitor::exit
>>   * If the monitor has been inflated for object Obj which is owned by the current thread
>>     * All corresponding entries for Obj is removed from the lock stack
>>     * The monitor recursions is set to the number of removed entries - 1
>>     * The owner is changed from anonymous to the thread
>>     * The regular ObjectMonitor::action is called.
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix assert comment

Marked as reviewed by dcubed (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16606#pullrequestreview-1857210316

From dcubed at openjdk.org  Thu Feb  1 18:25:05 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 1 Feb 2024 18:25:05 GMT
Subject: RFR: 8319799: Recursive lightweight locking: x86 implementation
 [v15]
In-Reply-To: <qNdFN0uq2qvh5b98dNfMPBixItwZskTBwJUVrShMvUw=.6bbbf212-b587-44f8-a014-ca8c062fb8a7@github.com>
References: <ymgsUW7sq02C2r82WrLYof5Eb7BB5Lh8M-kGoHx_Zjg=.a5a76651-4931-489f-8ea1-158716614119@github.com>
 <qNdFN0uq2qvh5b98dNfMPBixItwZskTBwJUVrShMvUw=.6bbbf212-b587-44f8-a014-ca8c062fb8a7@github.com>
Message-ID: <seynTWLxC4KsDfAkntgMEbd7EJzboDiZFw-C16-iWFU=.d1ed7fd2-a3d8-4b61-a2fc-2a2ca44441b3@github.com>

On Mon, 29 Jan 2024 14:50:57 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Implements the x86 port of JDK-8319796.
>> 
>> There are two major parts for the port implementation. The C2 part, and the part shared by the interpreter, C1 and the native call wrapper.
>> 
>> The biggest change for both parts is that we check the lock stack first and if it is a recursive lightweight [un]lock and in that case simply pop/push and finish successfully.
>> 
>> Only if the recursive lightweight [un]lock fails does it look at the mark word. 
>> 
>> For the shared part if it is an unstructured exit, the monitor is inflated or the mark word transition fails it calls into the runtime.
>> 
>> The C2 operates under a few more assumptions, that the locking is structured and balanced. This means that some checks can be elided. 
>> 
>> First this means that in C2 unlock if the obj is not on the top of the lock stack, it must be inflated. And reversely if we reach the inflated C2 unlock the obj is not on the lock stack. This second property makes it possible to avoid reading the owner (and checking if it is anonymous). Instead it can either just do an un-contended unlock by writing null to the owner, or if contention happens, simply write the thread to the owner and jump to the runtime. 
>> 
>> The x86 C2 port also has some extra oddities. 
>> 
>> The mark word read is done early as it showed better scaling in hyper-threaded scenarios on certain intel hardware, and no noticeable downside on other tested x86 hardware. 
>> 
>> The fast path is written to avoid going through conditional branches. This in combination with keeping the ZF output correct, the code does some actions eagerly, decrementing the held monitor count, popping from the lock stack. And jumps to a code stub if a slow path is required which restores the thread local state to a correct state before jumping to the runtime.
>> 
>> The contended unlock was also moved to the code stub.
>
> Axel Boldt-Christmas has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update MacroAssembler::lightweight_unlock comments.
>  - Update comments and asserts

Marked as reviewed by dcubed (Reviewer).

src/hotspot/cpu/x86/interp_masm_x86.cpp line 1315:

> 1313: #else
> 1314:     // This relies on the implementation of lightweight_unlock being able to handle
> 1315:     // that the reg_rax and thread Register parameters may alias each other.

nit: I think the indent is off by 2 space here.

src/hotspot/cpu/x86/macroAssembler_x86.cpp line 9934:

> 9932: //
> 9933: // x86_32 Note: reg_rax and thread may alias each other due to limited register
> 9934: //              availiability.

I like it!

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

PR Review: https://git.openjdk.org/jdk/pull/16607#pullrequestreview-1857226821
PR Review Comment: https://git.openjdk.org/jdk/pull/16607#discussion_r1474915005
PR Review Comment: https://git.openjdk.org/jdk/pull/16607#discussion_r1474915403

From amenkov at openjdk.org  Thu Feb  1 18:59:02 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 1 Feb 2024 18:59:02 GMT
Subject: RFR: JDK-8318566: Heap walking functions should not use
 FilteredFieldStream
In-Reply-To: <EMTaDvCBQ2Ham6qJmwLvyc_mlHPvtzYbRA2eZXkZhBA=.bdc8e162-d2dc-4c29-a445-6ca4bb217342@github.com>
References: <OAXy0kdJSDJ3b4TPhYjHBHbemHVhd40WzY-1j32rSP8=.f9c73209-0667-4f3e-9f38-e4a20c271c29@github.com>
 <EMTaDvCBQ2Ham6qJmwLvyc_mlHPvtzYbRA2eZXkZhBA=.bdc8e162-d2dc-4c29-a445-6ca4bb217342@github.com>
Message-ID: <p-tIwGV8Uksna0JLzvluNMyfo9Ry4-CVM4CGjO5iy2k=.f7808779-58f3-4a9b-a7a1-3b3324a474e7@github.com>

On Wed, 31 Jan 2024 23:24:22 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> FilteredFieldStream used by heap walking functions to iterate through klass/superclasses/interfaces fields are known to have poor performance (see [JDK-8317692](https://bugs.openjdk.org/browse/JDK-8317692) for details).
>> Heap walking API implementation is the last user of the klasses.
>> The fix reworks iteration through klass/superclasses/interfaces fields and drops FilteredFieldStream-related code.
>> Additionally removed/updated includes of reflectionUtils.hpp.
>> 
>> Testing:
>>   - tier1..4;
>>   - test/hotspot/jtreg/vmTestbase/nsk/jvmti (contains tests for different heap walking functions);
>>   - new test from #17580 (now the test runs several times faster).
>
> src/hotspot/share/prims/jvmtiTagMap.cpp line 453:
> 
>> 451:   InstanceKlass* super_klass = ik->java_super();
>> 452:   if (super_klass != nullptr) {
>> 453:     start_index += add_instance_fields(super_klass, start_index);
> 
> Does hotspot have any rules against potentially very deep recursion that can overflow the stack?

I looked at hotspot code and don't see "implementation limits" for level of inheritance, so it looks like a valid concern.
Need to reimplement this without recursion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17661#discussion_r1474976858

From duke at openjdk.org  Thu Feb  1 19:17:09 2024
From: duke at openjdk.org (duke)
Date: Thu, 1 Feb 2024 19:17:09 GMT
Subject: Withdrawn: 8321468: Remove StringUTF16::equals
In-Reply-To: <CySSsfGkTiz_6q09rb7VCW_rGwin9V8NN-Ugh8Wltds=.9a4652c2-4b0a-4644-8a48-f9ee6dd5abc4@github.com>
References: <CySSsfGkTiz_6q09rb7VCW_rGwin9V8NN-Ugh8Wltds=.9a4652c2-4b0a-4644-8a48-f9ee6dd5abc4@github.com>
Message-ID: <-NcFNFFX-Avf9EiYqMntALToh_w6F_SIZ6caNzUD6qU=.ee1ca764-1ac2-4f89-8dd8-c3944be067d2@github.com>

On Wed, 6 Dec 2023 14:20:14 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8215017 removed the only use of `StringUTF16::equals`. At the time I did some performance verification focused on x86 showing that simplifying and only using `StringLatin1::equals` was either neutral or a win. 
> 
> I repeated this experiment recently, adding some focused tests on aarch64 where the code generation actually tries to take advantage and generate slightly more efficient code for `StringUTF16::equals`: 
> https://github.com/openjdk/jdk/pull/16933#discussion_r1414118658
> 
> The indication here is that disabling use of `StringUTF16::equals` was the right choice: any effect from the low-level optimization (one less branch at the tail end) was offset by the `isLatin1()` branch and added code generation (that all gets inlined).
> 
> In a `-XX:-CompactStrings` configuration the slightly improved code generation in `StringUTF16::equals` might help, since the `isLatin1()` test and subsequent call to `StringLatin1::equals` would be DCEd. To get the best of both worlds the code in `String::equals` _could_ be sharpened so that we statically pick the best implementation based on `CompactStrings` mode (see comment below). This shows a tiny win when testing with `-XX:-CompactStrings` on M1 (up to -0.2ns/op per `String::equals`; neutral on x86). But is all this complexity worth it for a gain that will get lost in the noise on anything realistic?
> 
> This PR instead proposes removing `StringUTF16::equals` and simplifying the mechanisms to support the `StringLatin1/UTF16::equals` pair of intrinsics in hotspot.

This pull request has been closed without being integrated.

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

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

From coleenp at openjdk.org  Thu Feb  1 19:41:02 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 1 Feb 2024 19:41:02 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v5]
In-Reply-To: <8ZG3rV3o0aWMghASjxkM0qLsha99DcXD-paj7UZXn6k=.b0ffccc4-bf8b-4908-9f88-8476153ebe7c@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
 <8ZG3rV3o0aWMghASjxkM0qLsha99DcXD-paj7UZXn6k=.b0ffccc4-bf8b-4908-9f88-8476153ebe7c@github.com>
Message-ID: <1irjr5lmhnioRWAwDUKro4hiH0yU4fOxwBMD0ewzRk4=.2f1d1736-e9c7-4279-8684-c6a63bd2077b@github.com>

On Thu, 1 Feb 2024 12:40:26 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The `ObjectSynchronizer` has always assumed that the `current` parameters are both the current thread as well as the thread that is doing the locking. The only time that we are entering on behalf of another thread is when doing re-locking in deoptimization. This has worked because the deoptee thread is suspended. However ResourceMarks have been using the wrong thread when logging is enabled.
>> 
>> This change `ObjectSynchronizer` instruments the relevant methods with both a `JavaThread* locking_thread` as well as `[Java]Thread* current` to be able to use the correct thread for ResourceMarks. 
>> 
>> Having the `inflate` care about a `locking_thread` is a little unpleasant in my opinion. But it is required for LM_LIGHTWEIGHT. 
>> Would probably be cleaner if the inflate for LM_LIGHTWEIGHT was it's own thing, as it does not share the whole INFLATING protocol. But seems like a future RFE to refactor this code.
>> 
>> Can reproduce a crash by modifying `test/jdk/com/sun/jdi/EATests.java` and using `-XX:DiagnoseSyncOnValueBasedClasses=2` with LM_LEGACY or running `test/jdk/com/sun/jdi/EATests.java` with LM_LIGHTWEIGHT/LM_MONITOR and `-Xlog:monitorinflation=trace`. 
>> 
>> Could extend this test to capture this regression in the future (or creating a new test based on the same infrastructure). Will give it an attempt, so we have a regression test for this. But these tests get rather involved as the require a lot of jvmti setup.
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix enter_for LockingMode == LM_LEGACY and strengthen assert

Ok, I lost this with the race with deflation in enter_for() but the new set of functions make more sense now.

I guess my request to change back to the simpler v1 is not possible with the race with deflation when called from deopt, so I'm changing this to 'approved'.

src/hotspot/share/runtime/synchronizer.cpp line 1339:

> 1337: }
> 1338: 
> 1339: ObjectMonitor* ObjectSynchronizer::inflate_impl(JavaThread* thread, oop object, const InflateCause cause) {

I did like the name locking_thread better than just thread.  I see the comment below but I can see also missing the comment and below (it's a long function) deciding that ResourceMark is more efficient when you pass the current thread.  I don't think we managed to rename all "thread" parameter "current" in our cleanups.  Having a longer name makes it more special, which it is.

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

PR Review: https://git.openjdk.org/jdk/pull/17626#pullrequestreview-1857392272
Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17626#pullrequestreview-1857450014
PR Review Comment: https://git.openjdk.org/jdk/pull/17626#discussion_r1475011676

From duke at openjdk.org  Thu Feb  1 20:04:08 2024
From: duke at openjdk.org (duke)
Date: Thu, 1 Feb 2024 20:04:08 GMT
Subject: Withdrawn: 8314258: checked_cast doesn't properly check some cases
In-Reply-To: <ef3VVw3ZBEzW0-pMYjB39H9TnQmjqF4I6NBHPvpdOk8=.2fe9cc8a-781f-4964-8d59-7d07879ee448@github.com>
References: <ef3VVw3ZBEzW0-pMYjB39H9TnQmjqF4I6NBHPvpdOk8=.2fe9cc8a-781f-4964-8d59-7d07879ee448@github.com>
Message-ID: <o7wD05XJcCN4omf6vl7Hr2N98FauE82Eq23cEPv6pxE=.649baf8c-98fd-4fbd-9783-d288d57d5819@github.com>

On Mon, 2 Oct 2023 03:10:29 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this improvement to the `checked_cast` utility.
> 
> checked_cast was added by JDK-8255544 to permit silencing of certain compiler
> warnings (such as from gcc's -Wconversion) for narrowing conversions when the
> value is "known" to be safely convertible.  It provides debug-only runtime
> verification that the conversion preserves the value while changing the type.
> 
> There has been a recent effort to apply checked_cast to eliminate -Wconversion
> warnings, with the eventual goal of turning on such warnings by default - see
> JDK-8135181.
> 
> The existing implementation checks that the value is unchanged by a round-trip
> conversion, and has no restrictions on the arguments.  There are several
> problems with this.
> 
> (1) There are some cases where conversion of an integral value to a different
> integral type may pass the check, even though the value isn't in the range of
> the destination type.
> 
> (2) Floating point to integral conversions are often intended to discard the
> fractional part.  But that won't pass the round-trip conversion test, making
> checked_cast mostly useless for such conversions.
> 
> (3) Integral to floating point conversions are often intended to be
> indifferent to loss of precision.  But again, that won't pass the round-trip
> conversion test, making checked_cast mostly useless for such conversions.
> 
> This change to checked_cast supports integral to integral conversions, but not
> conversions involving floating point types.  The intent is that we'll use
> "-Wconversion -Wno-float-conversion" instead of -Wconversion alone.  If/when
> we later want to enable -Wfloat-conversion, we can either extend checked_cast
> for that purpose, or probably better, add new functions tailored for the
> various use-cases.
> 
> It also supports enum to integral conversions, mostly for compatibility with
> old code that uses class-scoped enums instead of class-scoped static const
> integral members, to work around ancient broken compilers.  We still have a
> lot of such code.
> 
> This new checked_cast ensures (in debugging builds) that the value being
> converted is in the range of the destination type.  It does so while avoiding
> tautological comparisons, as some versions of some compilers may warn about
> such.  Note that this means it can also be used to suppress -Wsign-conversion
> warnings (which are not included in -Wconversion when compiling C++), which we
> might explore enabling in the future.
> 
> It also verifies a runtime check is needed, producing a compile-time error if
> not.  Unnecessary checked_cast...

This pull request has been closed without being integrated.

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

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

From dlong at openjdk.org  Thu Feb  1 20:28:03 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 1 Feb 2024 20:28:03 GMT
Subject: RFR: 8324833: Signed integer overflows in ABS [v2]
In-Reply-To: <keBLe_kqh25x7IdMWimvIQshpubvKZrP0KPf4Lphoy4=.447c2d2e-3c08-4d85-a9c3-3bd356cfc8a4@github.com>
References: <ohwAn6GqM7FIgYTJNy40VBYSCVEBrrNSqBaz2akN54M=.f9660235-3047-47ee-aad0-ef598d6ebdcc@github.com>
 <keBLe_kqh25x7IdMWimvIQshpubvKZrP0KPf4Lphoy4=.447c2d2e-3c08-4d85-a9c3-3bd356cfc8a4@github.com>
Message-ID: <r4Fyb__l1HBZZSIcLlGuRNA8ZDy7h67rOyCVkU23uZg=.b03dbedc-01bb-4e92-8f98-ebf40d51937d@github.com>

On Wed, 31 Jan 2024 15:55:25 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the details in the bug. I think current `ABS` implementation is beyond repair, and we should just switch to `uabs`.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug, `all` with `-ftrapv` (now fully passes!)
>>  - [x] Linux x86_64 fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Unnecessary comment

src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 1063:

> 1061:     int64_t off_low = (int64_t)target_addr - ((int64_t)CodeCache::low_bound() + sizeof(int));
> 1062:     int64_t off_high = (int64_t)target_addr - ((int64_t)CodeCache::high_bound() + sizeof(int));
> 1063:     return MAX2(ABS(off_low), ABS(off_high));

Wouldn't this trigger a warning with -Wsign-conversion enabled?

src/hotspot/share/opto/ifnode.cpp line 1978:

> 1976:           // "x - y" -> must add one to the difference for number of elements in [x,y]
> 1977:           const jlong diff = (jlong)MIN2(offset2, off_lo) - (jlong)MAX2(offset2, off_hi);
> 1978:           if (uabs(diff) < maximum_number_of_min_max_interval_indices) {

unsigned vs signed comparison.  Maybe the rhs should be unsigned as well?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17617#discussion_r1475100564
PR Review Comment: https://git.openjdk.org/jdk/pull/17617#discussion_r1475102253

From dlong at openjdk.org  Thu Feb  1 20:34:03 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 1 Feb 2024 20:34:03 GMT
Subject: RFR: 8324833: Signed integer overflows in ABS [v2]
In-Reply-To: <keBLe_kqh25x7IdMWimvIQshpubvKZrP0KPf4Lphoy4=.447c2d2e-3c08-4d85-a9c3-3bd356cfc8a4@github.com>
References: <ohwAn6GqM7FIgYTJNy40VBYSCVEBrrNSqBaz2akN54M=.f9660235-3047-47ee-aad0-ef598d6ebdcc@github.com>
 <keBLe_kqh25x7IdMWimvIQshpubvKZrP0KPf4Lphoy4=.447c2d2e-3c08-4d85-a9c3-3bd356cfc8a4@github.com>
Message-ID: <buWxvISYc1_8tMG4s2aU3KEe7OXnl-Pj71K4IKy-S0Y=.5b74dc69-1352-420d-8da8-8123e2e8356c@github.com>

On Wed, 31 Jan 2024 15:55:25 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the details in the bug. I think current `ABS` implementation is beyond repair, and we should just switch to `uabs`.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug, `all` with `-ftrapv` (now fully passes!)
>>  - [x] Linux x86_64 fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Unnecessary comment

This seems to introduce a lot of potential warnings if -Wsigned-conversion is ever enabled.  Use of checked_cast() could solve this, but I only see it used in one place.

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

PR Comment: https://git.openjdk.org/jdk/pull/17617#issuecomment-1922190550

From dcubed at openjdk.org  Thu Feb  1 20:57:09 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 1 Feb 2024 20:57:09 GMT
Subject: RFR: 8319801: Recursive lightweight locking: aarch64
 implementation [v11]
In-Reply-To: <dlIiRbmqg1A2DeuEQ8Tsw4iI_TT1QZlLkVuovksK0qo=.f70a5b9e-9a69-4160-baba-e25f8df80079@github.com>
References: <AE1nsnyRCUHR970jjg4feUm5f6E1GPJvea0ooC6dCgI=.73fff610-c0f6-422a-a45d-88187b37b9a2@github.com>
 <dlIiRbmqg1A2DeuEQ8Tsw4iI_TT1QZlLkVuovksK0qo=.f70a5b9e-9a69-4160-baba-e25f8df80079@github.com>
Message-ID: <9hp_syDpeeMu4tULaU0O4JPqhNn1J2TML8dLh6vOqZE=.97953dd8-00cd-4fd0-aae9-6413bdbd8f5f@github.com>

On Fri, 26 Jan 2024 09:24:00 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Implements the aarch64 port of JDK-8319796.
>> 
>> There are two major parts for the port implementation. The C2 part, and the part shared by the interpreter, C1 and the native call wrapper.
>> 
>> The biggest change for both parts is that we check the lock stack first and if it is a recursive lightweight [un]lock and in that case simply pop/push and finish successfully.
>> 
>> Only if the recursive lightweight [un]lock fails does it look at the mark word. 
>> 
>> For the shared part if it is an unstructured exit, the monitor is inflated or the mark word transition fails it calls into the runtime.
>> 
>> The C2 operates under a few more assumptions, that the locking is structured and balanced. This means that some checks can be elided. 
>> 
>> First this means that in C2 unlock if the obj is not on the top of the lock stack, it must be inflated. And reversely if we reach the inflated C2 unlock the obj is not on the lock stack. This second property makes it possible to avoid reading the owner (and checking if it is anonymous). Instead it can either just do an un-contended unlock by writing null to the owner, or if contention happens, simply write the thread to the owner and jump to the runtime. 
>> 
>> The aarch64 C2 port tries to avoid stronger memory semantics where ever possible. In C2 lock it first does a relaxed load of the mark word to check for inflation. Both lock and unlock uses a load/store exclusive register pair to transition the mark word.
>
> Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319801
>  - Drop memory order comments
>  - Preloads markWord unconditionally
>  - Revert "Add preload_mark to MacroAssembler::lightweight_lock"
>    
>    This reverts commit 8950f503aa5dba0e203613bd9737ea0d50388ca3.
>  - Add preload_mark to MacroAssembler::lightweight_lock
>  - Rename box to t1
>  - Remove third tmp from fast_lock
>  - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319801
>  - Switch to CAS over LXSX
>  - Fix missing $
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/7f5d8421...d0a02754

I've done a crawl thru review of the v10 webrev. I only have a couple of editorial comments.

src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 59:

> 57:   Label count, no_count;
> 58: 
> 59:   assert(LockingMode != LM_LIGHTWEIGHT, "uses fast_lock_lightweight");

Perhaps: "lightweight locking should use fast_lock_lightweight"

src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 158:

> 156:   Label count, no_count;
> 157: 
> 158:   assert(LockingMode != LM_LIGHTWEIGHT, "uses fast_unlock_lightweight");

Perhaps "lightweight locking should use fast_unlock_lightweight"

src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 234:

> 232:   // Handle inflated monitor.
> 233:   Label inflated;
> 234:   // Finish fast lock successfully. MUST reach to with flag == EQ

nit typo: s/reach to/branch to/

src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 250:

> 248:   { // Lightweight locking
> 249: 
> 250:     // Push lock to the lock stack and finish successfully. MUST reach to with flag == EQ

nit typo: s/reach to/branch to/

src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 341:

> 339:   // Handle inflated monitor.
> 340:   Label inflated, inflated_load_monitor;
> 341:   // Finish fast unlock successfully. MUST reach to with flag == EQ

nit typo: s/reach to/branch to/

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 6384:

> 6382: void MacroAssembler::lightweight_unlock(Register obj, Register t1, Register t2, Register t3, Label& slow) {
> 6383:   assert(LockingMode == LM_LIGHTWEIGHT, "only used with new lightweight locking");
> 6384:   assert_different_registers(obj, t1, t2, t3, rscratch1);

I'm not seeing `rscratch1` being used in this function.

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

Marked as reviewed by dcubed (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16608#pullrequestreview-1857258375
PR Review Comment: https://git.openjdk.org/jdk/pull/16608#discussion_r1474932331
PR Review Comment: https://git.openjdk.org/jdk/pull/16608#discussion_r1474933142
PR Review Comment: https://git.openjdk.org/jdk/pull/16608#discussion_r1474973301
PR Review Comment: https://git.openjdk.org/jdk/pull/16608#discussion_r1475094131
PR Review Comment: https://git.openjdk.org/jdk/pull/16608#discussion_r1475108159
PR Review Comment: https://git.openjdk.org/jdk/pull/16608#discussion_r1475130312

From pchilanomate at openjdk.org  Thu Feb  1 20:58:23 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 1 Feb 2024 20:58:23 GMT
Subject: RFR: 8320302: compiler/arguments/TestC1Globals.java hits SIGSEGV
 in ContinuationEntry::set_enter_code [v2]
In-Reply-To: <1Cm1SGGaZsYxM-RfPNDeAvnGijQ-taVe438SS6bZ3YI=.d64abde2-f9a0-4589-ab40-eba7c3c02992@github.com>
References: <1Cm1SGGaZsYxM-RfPNDeAvnGijQ-taVe438SS6bZ3YI=.d64abde2-f9a0-4589-ab40-eba7c3c02992@github.com>
Message-ID: <HG2w7Et8SEU0sRgfcQ47BmU-zwKo3LBktlqFAvNHETY=.b377172c-4e64-484e-8006-640de336561c@github.com>

> When creating Continuation.enterSpecial/doYield special native nmethods we currently assume the call to nmethod::new_native_nmethod() always succeeds. If the CodeCache happens to be full though, creating the nmethod will fail and we'll hit a SIGSEGV when trying to dereference the return value. 
> 
> Since this happens the first time those methods are resolved, throwing an exception at that point implying that we cannot run virtual threads looks odd from a user perspective. So instead I added a step to initialize the Continuation class at startup so that failure to create those nmethods is treated early as a fatal error as we do with any other critical resource needed by the VM. I measured the added step to the startup sequence to be ~90us, or about 0.3% of the total?startup time.
> 
> I verified the fix by running the test mentioned in the bug plus I also run tiers1-5 in mach5.
> 
> Thanks,
> Patricio

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  inline call to initialize cont class

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17455/files
  - new: https://git.openjdk.org/jdk/pull/17455/files/7e409d0c..be77c877

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

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

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

From pchilanomate at openjdk.org  Thu Feb  1 20:58:23 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 1 Feb 2024 20:58:23 GMT
Subject: RFR: 8320302: compiler/arguments/TestC1Globals.java hits SIGSEGV
 in ContinuationEntry::set_enter_code
In-Reply-To: <1Cm1SGGaZsYxM-RfPNDeAvnGijQ-taVe438SS6bZ3YI=.d64abde2-f9a0-4589-ab40-eba7c3c02992@github.com>
References: <1Cm1SGGaZsYxM-RfPNDeAvnGijQ-taVe438SS6bZ3YI=.d64abde2-f9a0-4589-ab40-eba7c3c02992@github.com>
Message-ID: <HO4JihmpYtHSgGBAB8a8IYkVsaA2AwfIJMbv4ITo6ms=.38cfd51d-57a8-455a-baab-fd937763ffce@github.com>

On Tue, 16 Jan 2024 23:33:58 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> When creating Continuation.enterSpecial/doYield special native nmethods we currently assume the call to nmethod::new_native_nmethod() always succeeds. If the CodeCache happens to be full though, creating the nmethod will fail and we'll hit a SIGSEGV when trying to dereference the return value. 
> 
> Since this happens the first time those methods are resolved, throwing an exception at that point implying that we cannot run virtual threads looks odd from a user perspective. So instead I added a step to initialize the Continuation class at startup so that failure to create those nmethods is treated early as a fatal error as we do with any other critical resource needed by the VM. I measured the added step to the startup sequence to be ~90us, or about 0.3% of the total?startup time.
> 
> I verified the fix by running the test mentioned in the bug plus I also run tiers1-5 in mach5.
> 
> Thanks,
> Patricio

Thanks for looking at this David.

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

PR Comment: https://git.openjdk.org/jdk/pull/17455#issuecomment-1922226443

From pchilanomate at openjdk.org  Thu Feb  1 20:58:24 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 1 Feb 2024 20:58:24 GMT
Subject: RFR: 8320302: compiler/arguments/TestC1Globals.java hits SIGSEGV
 in ContinuationEntry::set_enter_code [v2]
In-Reply-To: <rsC787zJZXqxpRt-8zRKUDysucFHUvklklhmD_YvE2U=.9ef04c16-99e1-4f19-8d87-7dbe897c5b74@github.com>
References: <1Cm1SGGaZsYxM-RfPNDeAvnGijQ-taVe438SS6bZ3YI=.d64abde2-f9a0-4589-ab40-eba7c3c02992@github.com>
 <rsC787zJZXqxpRt-8zRKUDysucFHUvklklhmD_YvE2U=.9ef04c16-99e1-4f19-8d87-7dbe897c5b74@github.com>
Message-ID: <ZOVtuk95Hi4niHlne8p1XUGV-s-sApR0M4zR1uGoiQ0=.57d6812f-c02f-4a45-bf92-ec92a60dec39@github.com>

On Thu, 1 Feb 2024 07:59:18 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   inline call to initialize cont class
>
> src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 1394:
> 
>> 1392:                                               oop_maps,
>> 1393:                                               exception_offset);
>> 1394:     if (nm == nullptr) fatal("Initial size of CodeCache is too small");
> 
> It is a pity we can't just use a return of `nullptr` up the call chain to then have `create_vm` call `vm_exit_during_initialization` rather than using a `fatal` here.
> 
> I suppose we could use `vm_exit_during_initialization` here, but it is not obvious this code path can only be executed during the initialization process.

It should be called during vm initialization time only. I can change it to use vm_exit_during_initialization() instead and add an assert in Method::link_method() where create_native_wrapper() is called for these methods to assert vm is initializing. What do you think?

> src/hotspot/share/runtime/threads.cpp line 416:
> 
>> 414: 
>> 415:   initialize_class(vmSymbols::jdk_internal_vm_Continuation(), CHECK);
>> 416: }
> 
> I don't think this needs to be part of the `Threads` API - just inline it where needed.

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17455#discussion_r1475135560
PR Review Comment: https://git.openjdk.org/jdk/pull/17455#discussion_r1475135197

From dcubed at openjdk.org  Thu Feb  1 21:17:05 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 1 Feb 2024 21:17:05 GMT
Subject: RFR: 8319801: Recursive lightweight locking: aarch64
 implementation [v11]
In-Reply-To: <dlIiRbmqg1A2DeuEQ8Tsw4iI_TT1QZlLkVuovksK0qo=.f70a5b9e-9a69-4160-baba-e25f8df80079@github.com>
References: <AE1nsnyRCUHR970jjg4feUm5f6E1GPJvea0ooC6dCgI=.73fff610-c0f6-422a-a45d-88187b37b9a2@github.com>
 <dlIiRbmqg1A2DeuEQ8Tsw4iI_TT1QZlLkVuovksK0qo=.f70a5b9e-9a69-4160-baba-e25f8df80079@github.com>
Message-ID: <3o3rR5tDF4uClcq76zoF-4EU0dqyLk1TcntHzr8mZOs=.a7f58f57-b199-46d4-af61-7766cd494f0c@github.com>

On Fri, 26 Jan 2024 09:24:00 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Implements the aarch64 port of JDK-8319796.
>> 
>> There are two major parts for the port implementation. The C2 part, and the part shared by the interpreter, C1 and the native call wrapper.
>> 
>> The biggest change for both parts is that we check the lock stack first and if it is a recursive lightweight [un]lock and in that case simply pop/push and finish successfully.
>> 
>> Only if the recursive lightweight [un]lock fails does it look at the mark word. 
>> 
>> For the shared part if it is an unstructured exit, the monitor is inflated or the mark word transition fails it calls into the runtime.
>> 
>> The C2 operates under a few more assumptions, that the locking is structured and balanced. This means that some checks can be elided. 
>> 
>> First this means that in C2 unlock if the obj is not on the top of the lock stack, it must be inflated. And reversely if we reach the inflated C2 unlock the obj is not on the lock stack. This second property makes it possible to avoid reading the owner (and checking if it is anonymous). Instead it can either just do an un-contended unlock by writing null to the owner, or if contention happens, simply write the thread to the owner and jump to the runtime. 
>> 
>> The aarch64 C2 port tries to avoid stronger memory semantics where ever possible. In C2 lock it first does a relaxed load of the mark word to check for inflation. Both lock and unlock uses a load/store exclusive register pair to transition the mark word.
>
> Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319801
>  - Drop memory order comments
>  - Preloads markWord unconditionally
>  - Revert "Add preload_mark to MacroAssembler::lightweight_lock"
>    
>    This reverts commit 8950f503aa5dba0e203613bd9737ea0d50388ca3.
>  - Add preload_mark to MacroAssembler::lightweight_lock
>  - Rename box to t1
>  - Remove third tmp from fast_lock
>  - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319801
>  - Switch to CAS over LXSX
>  - Fix missing $
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/b3048aec...d0a02754

Forgot to mention: don't forget to update the copyright years.

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

PR Comment: https://git.openjdk.org/jdk/pull/16608#issuecomment-1922255936

From dcubed at openjdk.org  Thu Feb  1 21:57:03 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 1 Feb 2024 21:57:03 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v5]
In-Reply-To: <8ZG3rV3o0aWMghASjxkM0qLsha99DcXD-paj7UZXn6k=.b0ffccc4-bf8b-4908-9f88-8476153ebe7c@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
 <8ZG3rV3o0aWMghASjxkM0qLsha99DcXD-paj7UZXn6k=.b0ffccc4-bf8b-4908-9f88-8476153ebe7c@github.com>
Message-ID: <yK6RH7sJ2sco-0TYICbzaW8xYHyM8kVy0Kptdg0yjQI=.2f1fc3c0-b3fe-42e1-a41d-67564f124dcc@github.com>

On Thu, 1 Feb 2024 12:40:26 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The `ObjectSynchronizer` has always assumed that the `current` parameters are both the current thread as well as the thread that is doing the locking. The only time that we are entering on behalf of another thread is when doing re-locking in deoptimization. This has worked because the deoptee thread is suspended. However ResourceMarks have been using the wrong thread when logging is enabled.
>> 
>> This change `ObjectSynchronizer` instruments the relevant methods with both a `JavaThread* locking_thread` as well as `[Java]Thread* current` to be able to use the correct thread for ResourceMarks. 
>> 
>> Having the `inflate` care about a `locking_thread` is a little unpleasant in my opinion. But it is required for LM_LIGHTWEIGHT. 
>> Would probably be cleaner if the inflate for LM_LIGHTWEIGHT was it's own thing, as it does not share the whole INFLATING protocol. But seems like a future RFE to refactor this code.
>> 
>> Can reproduce a crash by modifying `test/jdk/com/sun/jdi/EATests.java` and using `-XX:DiagnoseSyncOnValueBasedClasses=2` with LM_LEGACY or running `test/jdk/com/sun/jdi/EATests.java` with LM_LIGHTWEIGHT/LM_MONITOR and `-Xlog:monitorinflation=trace`. 
>> 
>> Could extend this test to capture this regression in the future (or creating a new test based on the same infrastructure). Will give it an attempt, so we have a regression test for this. But these tests get rather involved as the require a lot of jvmti setup.
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix enter_for LockingMode == LM_LEGACY and strengthen assert

Thumbs up modulo other reviews comments being resolved.

Please don't forget to update copyright years.

src/hotspot/share/runtime/objectMonitor.cpp line 318:

> 316: 
> 317: bool ObjectMonitor::enter_for(JavaThread* locking_thread) {
> 318:   // Used by ObjectSynchronizer::enter_for to enter for another thread

style bit: please end this sentence with a `;` and the lower case start of the next sentence will make sense.

src/hotspot/share/runtime/synchronizer.cpp line 510:

> 508: // The interpreter and compiler assembly code tries to lock using the fast path
> 509: // of this algorithm. Make sure to update that code if the following function is
> 510: // changed. The implementation is extremely sensitive to race condition. Be careful.

This comment belongs before `enter_fast_impl`.

src/hotspot/share/runtime/synchronizer.cpp line 1347:

> 1345:   // important for the correctness of the LM_LIGHTWEIGHT algorithm that the thread
> 1346:   // is set when called from ObjectSynchronizer::enter from the owning thread,
> 1347:   // ObjectSynchronizer::enter_for from any thread, or ObjectSynchronizer::exit

nit typo: please end this sentence with a `.`

src/hotspot/share/runtime/synchronizer.hpp line 105:

> 103: private:
> 104:   // Shared implementation for enter and enter_for. Preforms all but
> 105:   // inflated monitor enter

nit typo: s/Preforms/ Performs/
Please end the sentence with a `.`

src/hotspot/share/runtime/synchronizer.hpp line 124:

> 122:   // Inflate light weight monitor to heavy weight monitor
> 123:   static ObjectMonitor* inflate(Thread* current, oop obj, const InflateCause cause);
> 124:   // Used inflate a monitor as if it was done from the thread JavaThread.

nit typo: s/Used inflate/Used to inflate/

src/hotspot/share/runtime/synchronizer.hpp line 128:

> 126: 
> 127: private:
> 128:   // Shared implementation between the different LockingMode

nit typo: Please end the sentence with a .

test/jdk/com/sun/jdi/EATests.java line 148:

> 146:  *                 -XX:+DoEscapeAnalysis -XX:+EliminateAllocations -XX:+EliminateLocks -XX:+EliminateNestedLocks
> 147:  *                 -XX:LockingMode=0
> 148:  *                 -Xlog:monitorinflation=trace

You might want to try this:

-Xlog:monitorinflation=trace:file=monitorinflation.log

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

Marked as reviewed by dcubed (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17626#pullrequestreview-1857650292
PR Review Comment: https://git.openjdk.org/jdk/pull/17626#discussion_r1475160212
PR Review Comment: https://git.openjdk.org/jdk/pull/17626#discussion_r1475178393
PR Review Comment: https://git.openjdk.org/jdk/pull/17626#discussion_r1475183858
PR Review Comment: https://git.openjdk.org/jdk/pull/17626#discussion_r1475188239
PR Review Comment: https://git.openjdk.org/jdk/pull/17626#discussion_r1475188966
PR Review Comment: https://git.openjdk.org/jdk/pull/17626#discussion_r1475189723
PR Review Comment: https://git.openjdk.org/jdk/pull/17626#discussion_r1475194756

From dcubed at openjdk.org  Thu Feb  1 21:57:04 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 1 Feb 2024 21:57:04 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v5]
In-Reply-To: <1irjr5lmhnioRWAwDUKro4hiH0yU4fOxwBMD0ewzRk4=.2f1d1736-e9c7-4279-8684-c6a63bd2077b@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
 <8ZG3rV3o0aWMghASjxkM0qLsha99DcXD-paj7UZXn6k=.b0ffccc4-bf8b-4908-9f88-8476153ebe7c@github.com>
 <1irjr5lmhnioRWAwDUKro4hiH0yU4fOxwBMD0ewzRk4=.2f1d1736-e9c7-4279-8684-c6a63bd2077b@github.com>
Message-ID: <SfQOKE3h6qi5WUPtrYnONSyE4LkFj5GSAasbX-EL-pM=.74622686-7c65-49f5-8f76-e57d8d86c33f@github.com>

On Thu, 1 Feb 2024 19:18:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix enter_for LockingMode == LM_LEGACY and strengthen assert
>
> src/hotspot/share/runtime/synchronizer.cpp line 1339:
> 
>> 1337: }
>> 1338: 
>> 1339: ObjectMonitor* ObjectSynchronizer::inflate_impl(JavaThread* thread, oop object, const InflateCause cause) {
> 
> I did like the name locking_thread better than just thread.  I see the comment below but I can see also missing the comment and below (it's a long function) deciding that ResourceMark is more efficient when you pass the current thread.  I don't think we managed to rename all "thread" parameter "current" in our cleanups.  Having a longer name makes it more special, which it is.

I'm not fond of `thread` either, but I don't have a better name suggestion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17626#discussion_r1475200216

From dcubed at openjdk.org  Thu Feb  1 22:09:03 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 1 Feb 2024 22:09:03 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v4]
In-Reply-To: <nqoyXYV6zzbgdHscKXlHI6doU378EaDd6Dk1d3Y70F8=.225b062d-e2e1-423e-9575-3e0c5d1d9713@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
 <v3omYG7AsGlssh7MwE1E_MJOZPyNfkd4tyIj0FWWtjA=.88c1d7ac-856d-47d4-ad40-1699613ae678@github.com>
 <Y6pFdDojApfPAMCqxr5RWKhjahJN0dnqqIOKRkLoejY=.953b5371-d937-4d63-8766-8b9d95dd3740@github.com>
 <qv-Us4BNwC3tUBqV2DY4hph0E6vvh3viI8Xlx43Ei0A=.4ede78cb-2cb6-48e1-aff0-93fcf7e0d322@github.com>
 <nqoyXYV6zzbgdHscKXlHI6doU378EaDd6Dk1d3Y70F8=.225b062d-e2e1-423e-9575-3e0c5d1d9713@github.com>
Message-ID: <YIDwx2b78BJXqRw79SvpWU-_hZqacXsHCUz7RKpS6j4=.88e26782-a237-4c6f-9926-479a45482430@github.com>

On Thu, 1 Feb 2024 12:49:24 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> It is the ` -XX:LockingMode=0 -Xlog:monitorinflation=trace ` that timeout. 
>> You are correct that this case should also be handled. 
>> No tests reach this point. But it should still be reachable. The re-lock code will never cause inflation, but it might relock a lock which was inflated by the current thread (due to hash code) and then relock calls `enter_for`
>
> This test triggers the case where `prev_owner` is a stack lock with `LM_LEGACY` https://github.com/openjdk/jdk/compare/master...reinrich:jdk:tmp2.

I'm confused. The `LockingMode == LM_LEGACY && locking_thread->is_lock_owned((address)prev_owner) == true`
case is handled below on L350 -> L355. What am I missing?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17626#discussion_r1475213010

From rrich at openjdk.org  Thu Feb  1 22:42:04 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Thu, 1 Feb 2024 22:42:04 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v4]
In-Reply-To: <YIDwx2b78BJXqRw79SvpWU-_hZqacXsHCUz7RKpS6j4=.88e26782-a237-4c6f-9926-479a45482430@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
 <v3omYG7AsGlssh7MwE1E_MJOZPyNfkd4tyIj0FWWtjA=.88c1d7ac-856d-47d4-ad40-1699613ae678@github.com>
 <Y6pFdDojApfPAMCqxr5RWKhjahJN0dnqqIOKRkLoejY=.953b5371-d937-4d63-8766-8b9d95dd3740@github.com>
 <qv-Us4BNwC3tUBqV2DY4hph0E6vvh3viI8Xlx43Ei0A=.4ede78cb-2cb6-48e1-aff0-93fcf7e0d322@github.com>
 <nqoyXYV6zzbgdHscKXlHI6doU378EaDd6Dk1d3Y70F8=.225b062d-e2e1-423e-9575-3e0c5d1d9713@github.com>
 <YIDwx2b78BJXqRw79SvpWU-_hZqacXsHCUz7RKpS6j4=.88e26782-a237-4c6f-9926-479a45482430@github.com>
Message-ID: <zE4IIOmsCO2GbA1GiucCWLL5QUw8ZC-Ly0s63uvuEPs=.67613252-bdf3-42cb-9db3-ecbeaa760d5b@github.com>

On Thu, 1 Feb 2024 22:06:24 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> This test triggers the case where `prev_owner` is a stack lock with `LM_LEGACY` https://github.com/openjdk/jdk/compare/master...reinrich:jdk:tmp2.
>
> I'm confused. The `LockingMode == LM_LEGACY && locking_thread->is_lock_owned((address)prev_owner) == true`
> case is handled below on L350 -> L355. What am I missing?

With LM_LEGACY `ObjectMonitor::_owner` will either be the JavaThread* of the owner or the BasicLock* in the stack of the owner found in the mark word of the object when the lock gets inflated:
```c++
  void* volatile _owner;            // pointer to owning thread OR BasicLock

Here at L332 the JavaThread* case is handled. At L350 -> 355 the BasicLock* case is handled.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17626#discussion_r1475251768

From dcubed at openjdk.org  Thu Feb  1 22:55:01 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 1 Feb 2024 22:55:01 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v4]
In-Reply-To: <zE4IIOmsCO2GbA1GiucCWLL5QUw8ZC-Ly0s63uvuEPs=.67613252-bdf3-42cb-9db3-ecbeaa760d5b@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
 <v3omYG7AsGlssh7MwE1E_MJOZPyNfkd4tyIj0FWWtjA=.88c1d7ac-856d-47d4-ad40-1699613ae678@github.com>
 <Y6pFdDojApfPAMCqxr5RWKhjahJN0dnqqIOKRkLoejY=.953b5371-d937-4d63-8766-8b9d95dd3740@github.com>
 <qv-Us4BNwC3tUBqV2DY4hph0E6vvh3viI8Xlx43Ei0A=.4ede78cb-2cb6-48e1-aff0-93fcf7e0d322@github.com>
 <nqoyXYV6zzbgdHscKXlHI6doU378EaDd6Dk1d3Y70F8=.225b062d-e2e1-423e-9575-3e0c5d1d9713@github.com>
 <YIDwx2b78BJXqRw79SvpWU-_hZqacXsHCUz7RKpS6j4=.88e26782-a237-4c6f-9926-479a45482430@github.com>
 <zE4IIOmsCO2GbA1GiucCWLL5QUw8ZC-Ly0s63uvuEPs=.67613252-bdf3-42cb-9db3-ecbeaa760d5b@github.com>
Message-ID: <Pd1YajFHrxpt4ZCy-cwxq7HM76xoSbDCVqRr4lNYg_M=.4d1b755c-13c3-443a-86d9-646bd11c6398@github.com>

On Thu, 1 Feb 2024 22:39:02 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> I'm confused. The `LockingMode == LM_LEGACY && locking_thread->is_lock_owned((address)prev_owner) == true`
>> case is handled below on L350 -> L355. What am I missing?
>
> With LM_LEGACY `ObjectMonitor::_owner` will either be the JavaThread* of the owner or the BasicLock* in the stack of the owner found in the mark word of the object when the lock gets inflated:
> ```c++
>   void* volatile _owner;            // pointer to owning thread OR BasicLock
> 
> Here at L332 the JavaThread* case is handled. At L350 -> 355 the BasicLock* case is handled.

Ummm... Here's the comment line I'm talking about:
> I thought you would have to handle `LockingMode == LM_LEGACY && locking_thread->is_lock_owned((address)prev_owner) == true`. 

and the code that I referred to on L350 is exactly that line of code. Again, what am I missing?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17626#discussion_r1475272912

From prappo at openjdk.org  Thu Feb  1 23:07:08 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 1 Feb 2024 23:07:08 GMT
Subject: RFR: 8325109: Sort method modifiers in canonical order
In-Reply-To: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
References: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
Message-ID: <zBTvQPjpQKoxxj5CsUlaOfJkO0EyJy-lUfF8Zg6FQRQ=.132947bd-1b7a-4809-af69-e3d9ba962099@github.com>

On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a follow-up on [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the bin/blessed-modifier-order.sh on the entire code base, and manually checked the result. I have reverted all but these trivial and uncontroversial changes.
> 
> Almost all of these are about moving `static` to its proper position; a few do not involve `static` but instead puts `final` or `abstract` in the correct place.
> 
> I have deliberately stayed away from `default` in this PR, since they should probably get a more thorough treatment, see https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473.

Changes to jdk.javadoc look fine.

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

Marked as reviewed by prappo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17670#pullrequestreview-1857871131

From amenkov at openjdk.org  Thu Feb  1 23:07:11 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 1 Feb 2024 23:07:11 GMT
Subject: RFR: JDK-8318566: Heap walking functions should not use
 FilteredFieldStream [v2]
In-Reply-To: <OAXy0kdJSDJ3b4TPhYjHBHbemHVhd40WzY-1j32rSP8=.f9c73209-0667-4f3e-9f38-e4a20c271c29@github.com>
References: <OAXy0kdJSDJ3b4TPhYjHBHbemHVhd40WzY-1j32rSP8=.f9c73209-0667-4f3e-9f38-e4a20c271c29@github.com>
Message-ID: <-yVjuuKrSxMjLrnjK8eW36a17zXTu2AViPuge7-7De4=.9a5cae31-61bb-481f-9289-abf00b05fa8f@github.com>

> FilteredFieldStream used by heap walking functions to iterate through klass/superclasses/interfaces fields are known to have poor performance (see [JDK-8317692](https://bugs.openjdk.org/browse/JDK-8317692) for details).
> Heap walking API implementation is the last user of the klasses.
> The fix reworks iteration through klass/superclasses/interfaces fields and drops FilteredFieldStream-related code.
> Additionally removed/updated includes of reflectionUtils.hpp.
> 
> Testing:
>   - tier1..4;
>   - test/hotspot/jtreg/vmTestbase/nsk/jvmti (contains tests for different heap walking functions);
>   - new test from #17580 (now the test runs several times faster).

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  remove recursion

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17661/files
  - new: https://git.openjdk.org/jdk/pull/17661/files/5edae77e..c064abdf

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

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

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

From sspitsyn at openjdk.org  Fri Feb  2 00:50:16 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 2 Feb 2024 00:50:16 GMT
Subject: RFR: 8324677: Specification clarification needed for JVM TI
 GetObjectMonitorUsage
Message-ID: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>

The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
The function returns the following structure:

typedef struct {
    jthread owner;
    jint entry_count;
    jint waiter_count;
    jthread* waiters;
    jint notify_waiter_count;
    jthread* notify_waiters;
} jvmtiMonitorUsage;


The following four fields are defined this way:

waiter_count  [jint] The number of threads waiting to own this monitor
waiters  [jthread*] The waiter_count waiting threads
notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified

The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
This update makes it right.

The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.

The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:

  jvmti/GetObjectMonitorUsage/objmonusage001
  jvmti/GetObjectMonitorUsage/objmonusage003


The following JVMTI JCK tests have to be fixed to adopt to correct behavior:

vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html



A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository by a separate sub-task before integration of this update.

Also, please see and review the related CSR:
 [8324677](https://bugs.openjdk.org/browse/JDK-8324677) Specification clarification needed for JVM TI GetObjectMonitorUsage
 
Testing:
 - tested with mach5 tiers 1-6

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

Commit messages:
 - 8324677: Specification clarification needed for JVM TI GetObjectMonitorUsage

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

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

From dlong at openjdk.org  Fri Feb  2 02:13:01 2024
From: dlong at openjdk.org (Dean Long)
Date: Fri, 2 Feb 2024 02:13:01 GMT
Subject: RFR: 8314225: SIGSEGV in JavaThread::is_lock_owned [v2]
In-Reply-To: <WNc2aZSu8Qflo_15wgRmnPtlZpOhr4DRRe3Z21uOSI0=.69bb6676-ad6d-4d4f-a665-d8368acb09c6@github.com>
References: <60li7VMNrwKitU5i3y7_dnQIpTHsJ594rt0f0d-VLiY=.ecb991be-e40d-4182-a82b-9eec718e2d09@github.com>
 <mauY_9I343qsnjVGQuO0a6XobQZWeLqygydaxh6_sPc=.c465c989-cc13-4e40-9216-bda231c3dd9f@github.com>
 <7p5HrBndOFNCb9jcKdZa9kCkzhPuQVXm-TsCRTRmBmM=.e250e2cd-0fa6-47d3-a3ec-4bd92792e16c@github.com>
 <y-2poalC2ncP83cAqjuXgbJ276GAq6KWUiiTQyQK-6w=.2f4a341d-55e3-4a4c-87eb-beafe16a41af@github.com>
 <ah66rcyYlGdgFw3rD7bvZLtlZ60Q1jeugrFu_CQ7YNA=.752cae6a-9fe0-4e44-b573-481190d6cff9@github.com>
 <Mz39mpaClE4xQWOsfmpgFy8LvLKwWZk1MklPVMFGMSw=.6875bef9-d07a-49ea-a45b-1523695e3bff@github.com>
 <WNc2aZSu8Qflo_15wgRmnPtlZpOhr4DRRe3Z21uOSI0=.69bb6676-ad6d-4d4f-a665-d8368acb09c6@github.com>
Message-ID: <uYyLilmhPp98d_jNndQMyKn0mnCw303rdhN9MaXODjw=.5b80433b-ec40-4587-91fa-86f83928eaa0@github.com>

On Thu, 1 Feb 2024 05:30:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> does "on the native stack" equate to being in a compiled vframe ?? I thought checking the native stack simply found if the BasicObjectLock addr was allocated on the thread's native stack.
>> 
>> @dholmes-ora 
>> Yes, the lock record could be on the native stack in either an interpreter frame or a compiled frame, but I don't know if that's what you mean by being in a compiled vframe.  If you mean what is returned by `compiledVFrame::monitors`, that returns all the monitors locked by the compiled frame, both inflated and fast/stack locked.
>
>> > does "on the native stack" equate to being in a compiled vframe ?? I thought checking the native stack simply found if the BasicObjectLock addr was allocated on the thread's native stack.
>> 
>> @dholmes-ora Yes, the lock record could be on the native stack in either an interpreter frame or a compiled frame, but I don't know if that's what you mean by being in a compiled vframe. If you mean what is returned by `compiledVFrame::monitors`, that returns all the monitors locked by the compiled frame, both inflated and fast/stack locked.
> 
> As monitor chunks were described as temporary storage for moving a monitor from a compiled frame to an interpreter frame, my question is whether checking "on the native stack" will actually find those monitors in compiled frames (or interpreter frames for that matter)? If the answer is yes then I'm starting to see a picture here where we check for all the monitor that can be found in the stack (compiled frames or interpreted frames) then recognize that if deopt is in progress then we scan monitor_chunks for any monitors that might still be transitioning across and only reside in a monitor_chunk. (It is still racy of course).

@dholmes-ora, maybe in earlier versions of the code the mark word in the object was updated to point to the monitor chunk, which would result in a weird "monitor chunk stack-locked" object, if we considered the monitor chunks a logical extension of the native stack.  At least that appears to be what is_locked_owned is doing.  But as Patricio pointed out, stack-locked monitors get inflated, so we would only see the monitor lock record on the native stack in the compiled frame (before inflation), or not on the native stack at all (after inflation).

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

PR Comment: https://git.openjdk.org/jdk/pull/17566#issuecomment-1922662719

From dholmes at openjdk.org  Fri Feb  2 02:26:01 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 2 Feb 2024 02:26:01 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage
In-Reply-To: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
Message-ID: <Y9kuHAY_5xidLLP1P3cwT5MJBdhWMvQ-XZi5QBbthSs=.80273e1d-1c71-4bbf-be61-e7e6ff0ee96d@github.com>

On Fri, 2 Feb 2024 00:44:00 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
> The function returns the following structure:
> 
> 
> typedef struct {
>     jthread owner;
>     jint entry_count;
>     jint waiter_count;
>     jthread* waiters;
>     jint notify_waiter_count;
>     jthread* notify_waiters;
> } jvmtiMonitorUsage;
> 
> 
> The following four fields are defined this way:
> 
> waiter_count  [jint] The number of threads waiting to own this monitor
> waiters  [jthread*] The waiter_count waiting threads
> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
> 
> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
> This update makes it right.
> 
> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
> 
> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
> 
>   jvmti/GetObjectMonitorUsage/objmonusage001
>   jvmti/GetObjectMonitorUsage/objmonusage003
> 
> 
> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
> 
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
> 
> 
> 
> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository by a separate sub-task before integration of this update.
> 
> Also, please see and review the related CSR:
>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
>  
> Testing:
>  - tested with mach5 tiers 1-6

src/hotspot/share/prims/jvmtiEnvBase.cpp line 1553:

> 1551:             Handle th(current_thread, get_vthread_or_thread_oop(w));
> 1552:             if (java_lang_Thread::get_thread_status(w->threadObj()) ==
> 1553:                 JavaThreadStatus::BLOCKED_ON_MONITOR_ENTER) {

I don't think this is possible. `BLOCKED_ON_MONITOR_ENTER` is only set after the target has been removed from the wait-set and added to the cxq queue - see `ObjectMonitor::INotify`. As per the comment just above:

// If the thread was found on the ObjectWaiter list, then
// it has not been notified.

which means it can't be trying to acquire the monitor either.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1475436352

From amenkov at openjdk.org  Fri Feb  2 02:49:13 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 2 Feb 2024 02:49:13 GMT
Subject: RFR: JDK-8318566: Heap walking functions should not use
 FilteredFieldStream [v3]
In-Reply-To: <OAXy0kdJSDJ3b4TPhYjHBHbemHVhd40WzY-1j32rSP8=.f9c73209-0667-4f3e-9f38-e4a20c271c29@github.com>
References: <OAXy0kdJSDJ3b4TPhYjHBHbemHVhd40WzY-1j32rSP8=.f9c73209-0667-4f3e-9f38-e4a20c271c29@github.com>
Message-ID: <qWNgrR_H8lG6DxhpC04CQYO-4rY5mp0ljH4RnPgs3mU=.b2d49368-a7d0-4e0d-9ea3-b9711785aff6@github.com>

> FilteredFieldStream used by heap walking functions to iterate through klass/superclasses/interfaces fields are known to have poor performance (see [JDK-8317692](https://bugs.openjdk.org/browse/JDK-8317692) for details).
> Heap walking API implementation is the last user of the klasses.
> The fix reworks iteration through klass/superclasses/interfaces fields and drops FilteredFieldStream-related code.
> Additionally removed/updated includes of reflectionUtils.hpp.
> 
> Testing:
>   - tier1..4;
>   - test/hotspot/jtreg/vmTestbase/nsk/jvmti (contains tests for different heap walking functions);
>   - new test from #17580 (now the test runs several times faster).

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  jcheck

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17661/files
  - new: https://git.openjdk.org/jdk/pull/17661/files/c064abdf..d6ab43b4

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

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

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

From amenkov at openjdk.org  Fri Feb  2 02:49:13 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 2 Feb 2024 02:49:13 GMT
Subject: RFR: JDK-8318566: Heap walking functions should not use
 FilteredFieldStream [v3]
In-Reply-To: <p-tIwGV8Uksna0JLzvluNMyfo9Ry4-CVM4CGjO5iy2k=.f7808779-58f3-4a9b-a7a1-3b3324a474e7@github.com>
References: <OAXy0kdJSDJ3b4TPhYjHBHbemHVhd40WzY-1j32rSP8=.f9c73209-0667-4f3e-9f38-e4a20c271c29@github.com>
 <EMTaDvCBQ2Ham6qJmwLvyc_mlHPvtzYbRA2eZXkZhBA=.bdc8e162-d2dc-4c29-a445-6ca4bb217342@github.com>
 <p-tIwGV8Uksna0JLzvluNMyfo9Ry4-CVM4CGjO5iy2k=.f7808779-58f3-4a9b-a7a1-3b3324a474e7@github.com>
Message-ID: <TnYKoerdNdOimwm_7YhbhaRkEokvlrvHm1nWoQPbzMc=.d9ce51b9-101f-4863-bdf7-18da41cf1f33@github.com>

On Thu, 1 Feb 2024 18:56:37 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiTagMap.cpp line 453:
>> 
>>> 451:   InstanceKlass* super_klass = ik->java_super();
>>> 452:   if (super_klass != nullptr) {
>>> 453:     start_index += add_instance_fields(super_klass, start_index);
>> 
>> Does hotspot have any rules against potentially very deep recursion that can overflow the stack?
>
> I looked at hotspot code and don't see "implementation limits" for level of inheritance, so it looks like a valid concern.
> Need to reimplement this without recursion.

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17661#discussion_r1475451497

From cjplummer at openjdk.org  Fri Feb  2 03:04:02 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 2 Feb 2024 03:04:02 GMT
Subject: RFR: JDK-8318566: Heap walking functions should not use
 FilteredFieldStream [v3]
In-Reply-To: <qWNgrR_H8lG6DxhpC04CQYO-4rY5mp0ljH4RnPgs3mU=.b2d49368-a7d0-4e0d-9ea3-b9711785aff6@github.com>
References: <OAXy0kdJSDJ3b4TPhYjHBHbemHVhd40WzY-1j32rSP8=.f9c73209-0667-4f3e-9f38-e4a20c271c29@github.com>
 <qWNgrR_H8lG6DxhpC04CQYO-4rY5mp0ljH4RnPgs3mU=.b2d49368-a7d0-4e0d-9ea3-b9711785aff6@github.com>
Message-ID: <Dl-m2v-KnN39x6S3cqRZlTg3UfzOmpigel3IDPG-MwI=.5b8cfeaa-5c6f-4d5f-8f59-9523a13321e6@github.com>

On Fri, 2 Feb 2024 02:49:13 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> FilteredFieldStream used by heap walking functions to iterate through klass/superclasses/interfaces fields are known to have poor performance (see [JDK-8317692](https://bugs.openjdk.org/browse/JDK-8317692) for details).
>> Heap walking API implementation is the last user of the klasses.
>> The fix reworks iteration through klass/superclasses/interfaces fields and drops FilteredFieldStream-related code.
>> Additionally removed/updated includes of reflectionUtils.hpp.
>> 
>> Testing:
>>   - tier1..4;
>>   - test/hotspot/jtreg/vmTestbase/nsk/jvmti (contains tests for different heap walking functions);
>>   - new test from #17580 (now the test runs several times faster).
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   jcheck

Looks good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17661#pullrequestreview-1858174309

From mdoerr at openjdk.org  Fri Feb  2 03:55:04 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 2 Feb 2024 03:55:04 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v6]
In-Reply-To: <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
Message-ID: <hFpFmzWDdWxfypartYE2f5AwrEbxSwkFOJU6Y8UgAeA=.60a57599-de15-4e6c-8a86-1352ba2918c3@github.com>

On Tue, 30 Jan 2024 09:08:01 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> ICStubs solve an atomicity problem when setting both the destination and data of an inline cache. Unfortunately, it also leads to occasional safepoint carpets when multiple threads need to ICRefill the stubs at the same time, and spurious GuaranteedSafepointInterval "Cleanup" safepoints every second. This patch changes inline caches to not change the data part at all during the nmethod life cycle, hence removing the need for ICStubs.
>> 
>> The new scheme is less stateful. Instead of adding and removing callsite metadata back and forth when transitioning inline cache states, it installs all state any shape of call will ever need at resolution time in a struct that I call CompiledICData. This reduces inline cache state changes to simply changing the destination of the call, and it doesn't really matter what state transitions to what other state.
>> 
>> With this patch, we get rid of ICStub and ICBuffer classes and the related ICRefill and almost all Cleanup safepoints in practice. It also makes the inline cache code much simpler.
>> 
>> I have tested the changes from tier1-7, and run through full aurora performance tests.
>
> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ARM32 fixes

Thanks for the improvements! Tests are still passing on SAP supported platforms.

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

PR Comment: https://git.openjdk.org/jdk/pull/17495#issuecomment-1922760746

From dholmes at openjdk.org  Fri Feb  2 04:53:03 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 2 Feb 2024 04:53:03 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v5]
In-Reply-To: <8ZG3rV3o0aWMghASjxkM0qLsha99DcXD-paj7UZXn6k=.b0ffccc4-bf8b-4908-9f88-8476153ebe7c@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
 <8ZG3rV3o0aWMghASjxkM0qLsha99DcXD-paj7UZXn6k=.b0ffccc4-bf8b-4908-9f88-8476153ebe7c@github.com>
Message-ID: <6q3ZHJtx7qg9SFnAGa36P2hzECOXcbCq83lv6evq11A=.c9aa9e23-ddc8-4b45-a565-c68136e76b05@github.com>

On Thu, 1 Feb 2024 12:40:26 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The `ObjectSynchronizer` has always assumed that the `current` parameters are both the current thread as well as the thread that is doing the locking. The only time that we are entering on behalf of another thread is when doing re-locking in deoptimization. This has worked because the deoptee thread is suspended. However ResourceMarks have been using the wrong thread when logging is enabled.
>> 
>> This change `ObjectSynchronizer` instruments the relevant methods with both a `JavaThread* locking_thread` as well as `[Java]Thread* current` to be able to use the correct thread for ResourceMarks. 
>> 
>> Having the `inflate` care about a `locking_thread` is a little unpleasant in my opinion. But it is required for LM_LIGHTWEIGHT. 
>> Would probably be cleaner if the inflate for LM_LIGHTWEIGHT was it's own thing, as it does not share the whole INFLATING protocol. But seems like a future RFE to refactor this code.
>> 
>> Can reproduce a crash by modifying `test/jdk/com/sun/jdi/EATests.java` and using `-XX:DiagnoseSyncOnValueBasedClasses=2` with LM_LEGACY or running `test/jdk/com/sun/jdi/EATests.java` with LM_LIGHTWEIGHT/LM_MONITOR and `-Xlog:monitorinflation=trace`. 
>> 
>> Could extend this test to capture this regression in the future (or creating a new test based on the same infrastructure). Will give it an attempt, so we have a regression test for this. But these tests get rather involved as the require a lot of jvmti setup.
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix enter_for LockingMode == LM_LEGACY and strengthen assert

Thanks for that additional separation and refactoring. I still have a general query below.

src/hotspot/share/runtime/synchronizer.cpp line 1372:

> 1370:       if (LockingMode == LM_LIGHTWEIGHT && inf->is_owner_anonymous() &&
> 1371:           thread != nullptr && thread->lock_stack().contains(object)) {
> 1372:         inf->set_owner_from_anonymous(thread);

I thought one of the invariants of lightweight locking was that a transition from anonymously owned to actual owner, can only be performed by the actual owner?

That said, can we actually reach here if not with the current thread? If we are re-locking for deopt then, IIUC, the object has not yet escaped, and has to be unlocked and not with an inflated monitor. In such a case we can't be racing with hashcode inflation either. But perhaps there are other circumstances where re-locking is needed?

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

PR Review: https://git.openjdk.org/jdk/pull/17626#pullrequestreview-1858288427
PR Review Comment: https://git.openjdk.org/jdk/pull/17626#discussion_r1475529283

From shade at openjdk.org  Fri Feb  2 06:23:02 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 2 Feb 2024 06:23:02 GMT
Subject: RFR: 8324833: Signed integer overflows in ABS [v2]
In-Reply-To: <keBLe_kqh25x7IdMWimvIQshpubvKZrP0KPf4Lphoy4=.447c2d2e-3c08-4d85-a9c3-3bd356cfc8a4@github.com>
References: <ohwAn6GqM7FIgYTJNy40VBYSCVEBrrNSqBaz2akN54M=.f9660235-3047-47ee-aad0-ef598d6ebdcc@github.com>
 <keBLe_kqh25x7IdMWimvIQshpubvKZrP0KPf4Lphoy4=.447c2d2e-3c08-4d85-a9c3-3bd356cfc8a4@github.com>
Message-ID: <1c16YOU0xxYgPbXiw6kqIDK8GGVD8S3lUOctnQ9zw5o=.29353a1d-cdc8-4732-874d-b0da2ffd07b3@github.com>

On Wed, 31 Jan 2024 15:55:25 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the details in the bug. I think current `ABS` implementation is beyond repair, and we should just switch to `uabs`.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug, `all` with `-ftrapv` (now fully passes!)
>>  - [x] Linux x86_64 fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Unnecessary comment

Yes, I think we care. I would try a build with `Wsigned-conversion` and look where we should sprinkle more `checked_cast`-s.

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

PR Comment: https://git.openjdk.org/jdk/pull/17617#issuecomment-1922955956

From ihse at openjdk.org  Fri Feb  2 06:40:01 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Feb 2024 06:40:01 GMT
Subject: RFR: 8325109: Sort method modifiers in canonical order
In-Reply-To: <uY6CoY9NwuiOEmWivsV3k5OEdoBB4ETOCiK2fo0mDLU=.7ec4beb3-66b9-4076-8aa6-2caa221023bf@github.com>
References: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
 <uY6CoY9NwuiOEmWivsV3k5OEdoBB4ETOCiK2fo0mDLU=.7ec4beb3-66b9-4076-8aa6-2caa221023bf@github.com>
Message-ID: <c1A2_JMyhmgyx8N0-IvYuVxJ-uK43gJZ-qQRWUYtBbk=.aee9ccc3-254c-41e8-b839-e61c21ca7fae@github.com>

On Thu, 1 Feb 2024 17:21:23 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>  I just suggest double-checking on the current maintenance procedures for the java.util.concurrent code.

@jddarcy Any idea how to do that? I tried searching for JSR-166 and java.util.concurrent, but all I could find was talk about a now-deleted mailing list concurrency-interest, and a link to a [CVS repo for JDK8](http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/jsr166/src/jdk8/java/util/).

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

PR Comment: https://git.openjdk.org/jdk/pull/17670#issuecomment-1923018074

From dholmes at openjdk.org  Fri Feb  2 06:50:01 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 2 Feb 2024 06:50:01 GMT
Subject: RFR: 8314225: SIGSEGV in JavaThread::is_lock_owned [v2]
In-Reply-To: <mauY_9I343qsnjVGQuO0a6XobQZWeLqygydaxh6_sPc=.c465c989-cc13-4e40-9216-bda231c3dd9f@github.com>
References: <60li7VMNrwKitU5i3y7_dnQIpTHsJ594rt0f0d-VLiY=.ecb991be-e40d-4182-a82b-9eec718e2d09@github.com>
 <mauY_9I343qsnjVGQuO0a6XobQZWeLqygydaxh6_sPc=.c465c989-cc13-4e40-9216-bda231c3dd9f@github.com>
Message-ID: <XO-Z0uxR4bTACz_Sjrr35gtfXYW6KOaU35-di6kHhiU=.c3b25a23-ed2d-4532-a8b5-73729545d170@github.com>

On Fri, 26 Jan 2024 21:34:44 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> JavaThread's _monitor_chunks member is temporary storage used by deoptimization.
>> When other threads inspect it using JavaThread::monitor_chunks(), if it is non-null that means a deoptimization is in progress, and the value will be removed shortly.
>> 
>> There are a few places where we attempt to follow the MonitorChunk*, but that would only be valid if deopt is in progress, and only safe if we could know the deopt is not going to complete.  But that the deopt will complete, and will free the MonitorChunks and clear the value.  So this is rare but there is a race and a risk of following a MonitorChunk* as it gets freed, and crashing.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ThreadsListHandle required for Handshake

AFAICS the `BasicLock` code has been basically unchanged for many years (Java 5 at least) and the `markword` has never pointed to a `MonitorChunk`.

But it does concern me that we don't seem to be able to come up with the reason that `is_lock_owned` searches the monitor chunk list. It is effectively "day one" code (Oct 1997).

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

PR Comment: https://git.openjdk.org/jdk/pull/17566#issuecomment-1923045089

From aph at openjdk.org  Fri Feb  2 07:04:07 2024
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 2 Feb 2024 07:04:07 GMT
Subject: RFR: 8319801: Recursive lightweight locking: aarch64
 implementation [v11]
In-Reply-To: <dlIiRbmqg1A2DeuEQ8Tsw4iI_TT1QZlLkVuovksK0qo=.f70a5b9e-9a69-4160-baba-e25f8df80079@github.com>
References: <AE1nsnyRCUHR970jjg4feUm5f6E1GPJvea0ooC6dCgI=.73fff610-c0f6-422a-a45d-88187b37b9a2@github.com>
 <dlIiRbmqg1A2DeuEQ8Tsw4iI_TT1QZlLkVuovksK0qo=.f70a5b9e-9a69-4160-baba-e25f8df80079@github.com>
Message-ID: <PEnvrTHuu-1fckexFKviDrg6-XDl9UXW_YdmMKwsgeY=.ffb08409-8c5d-4e8e-8811-88a7b1bfb040@github.com>

On Fri, 26 Jan 2024 09:24:00 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Implements the aarch64 port of JDK-8319796.
>> 
>> There are two major parts for the port implementation. The C2 part, and the part shared by the interpreter, C1 and the native call wrapper.
>> 
>> The biggest change for both parts is that we check the lock stack first and if it is a recursive lightweight [un]lock and in that case simply pop/push and finish successfully.
>> 
>> Only if the recursive lightweight [un]lock fails does it look at the mark word. 
>> 
>> For the shared part if it is an unstructured exit, the monitor is inflated or the mark word transition fails it calls into the runtime.
>> 
>> The C2 operates under a few more assumptions, that the locking is structured and balanced. This means that some checks can be elided. 
>> 
>> First this means that in C2 unlock if the obj is not on the top of the lock stack, it must be inflated. And reversely if we reach the inflated C2 unlock the obj is not on the lock stack. This second property makes it possible to avoid reading the owner (and checking if it is anonymous). Instead it can either just do an un-contended unlock by writing null to the owner, or if contention happens, simply write the thread to the owner and jump to the runtime. 
>> 
>> The aarch64 C2 port tries to avoid stronger memory semantics where ever possible. In C2 lock it first does a relaxed load of the mark word to check for inflation. Both lock and unlock uses a load/store exclusive register pair to transition the mark word.
>
> Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319801
>  - Drop memory order comments
>  - Preloads markWord unconditionally
>  - Revert "Add preload_mark to MacroAssembler::lightweight_lock"
>    
>    This reverts commit 8950f503aa5dba0e203613bd9737ea0d50388ca3.
>  - Add preload_mark to MacroAssembler::lightweight_lock
>  - Rename box to t1
>  - Remove third tmp from fast_lock
>  - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319801
>  - Switch to CAS over LXSX
>  - Fix missing $
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/13b8bb6f...d0a02754

src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 449:

> 447:     orr(rscratch1, rscratch1, t);
> 448:     cmp(rscratch1, zr);
> 449:     br(Assembler::EQ, release);

Suggestion:

    cbz(rscratch1, release);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16608#discussion_r1475634612

From rrich at openjdk.org  Fri Feb  2 08:03:02 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Fri, 2 Feb 2024 08:03:02 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v4]
In-Reply-To: <Pd1YajFHrxpt4ZCy-cwxq7HM76xoSbDCVqRr4lNYg_M=.4d1b755c-13c3-443a-86d9-646bd11c6398@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
 <v3omYG7AsGlssh7MwE1E_MJOZPyNfkd4tyIj0FWWtjA=.88c1d7ac-856d-47d4-ad40-1699613ae678@github.com>
 <Y6pFdDojApfPAMCqxr5RWKhjahJN0dnqqIOKRkLoejY=.953b5371-d937-4d63-8766-8b9d95dd3740@github.com>
 <qv-Us4BNwC3tUBqV2DY4hph0E6vvh3viI8Xlx43Ei0A=.4ede78cb-2cb6-48e1-aff0-93fcf7e0d322@github.com>
 <nqoyXYV6zzbgdHscKXlHI6doU378EaDd6Dk1d3Y70F8=.225b062d-e2e1-423e-9575-3e0c5d1d9713@github.com>
 <YIDwx2b78BJXqRw79SvpWU-_hZqacXsHCUz7RKpS6j4=.88e26782-a237-4c6f-9926-479a45482430@github.com>
 <zE4IIOmsCO2GbA1GiucCWLL5QUw8ZC-Ly0s63uvuEPs=.67613252-bdf3-42cb-9db3-ecbeaa760d5b@github.com>
 <Pd1YajFHrxpt4ZCy-cwxq7HM76xoSbDCVqRr4lNYg_M=.4d1b755c-13c3-443a-86d9-646bd11c6398@github.com>
Message-ID: <8mDvJP40GSADPLCqFzc_WEOi9OJT7L795K4Q1PBPZg8=.7ffd90f2-8d28-4daa-8e06-183669bf1178@github.com>

On Thu, 1 Feb 2024 22:52:27 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> With LM_LEGACY `ObjectMonitor::_owner` will either be the JavaThread* of the owner or the BasicLock* in the stack of the owner found in the mark word of the object when the lock gets inflated:
>> ```c++
>>   void* volatile _owner;            // pointer to owning thread OR BasicLock
>> 
>> Here at L332 the JavaThread* case is handled. At L350 -> 355 the BasicLock* case is handled.
>
> Ummm... Here's the comment line I'm talking about:
>> I thought you would have to handle `LockingMode == LM_LEGACY && locking_thread->is_lock_owned((address)prev_owner) == true`. 
> 
> and the code that I referred to on L350 is exactly that line of code. Again, what am I missing?

Axel added that line after my comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17626#discussion_r1475695841

From sspitsyn at openjdk.org  Fri Feb  2 08:09:06 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 2 Feb 2024 08:09:06 GMT
Subject: RFR: JDK-8318566: Heap walking functions should not use
 FilteredFieldStream [v3]
In-Reply-To: <qWNgrR_H8lG6DxhpC04CQYO-4rY5mp0ljH4RnPgs3mU=.b2d49368-a7d0-4e0d-9ea3-b9711785aff6@github.com>
References: <OAXy0kdJSDJ3b4TPhYjHBHbemHVhd40WzY-1j32rSP8=.f9c73209-0667-4f3e-9f38-e4a20c271c29@github.com>
 <qWNgrR_H8lG6DxhpC04CQYO-4rY5mp0ljH4RnPgs3mU=.b2d49368-a7d0-4e0d-9ea3-b9711785aff6@github.com>
Message-ID: <bGUrfOmFxmdr9ELXZlMsSDLtufJwiaeDkj53F8cbfX4=.cec6abd8-6a05-416b-95c5-fdac912ea45c@github.com>

On Fri, 2 Feb 2024 02:49:13 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> FilteredFieldStream used by heap walking functions to iterate through klass/superclasses/interfaces fields are known to have poor performance (see [JDK-8317692](https://bugs.openjdk.org/browse/JDK-8317692) for details).
>> Heap walking API implementation is the last user of the klasses.
>> The fix reworks iteration through klass/superclasses/interfaces fields and drops FilteredFieldStream-related code.
>> Additionally removed/updated includes of reflectionUtils.hpp.
>> 
>> Testing:
>>   - tier1..4;
>>   - test/hotspot/jtreg/vmTestbase/nsk/jvmti (contains tests for different heap walking functions);
>>   - new test from #17580 (now the test runs several times faster).
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   jcheck

Looks good. There is one minor comment though.

src/hotspot/share/prims/jvmtiTagMap.cpp line 499:

> 497:     }
> 498:     // update total_field_number for superclass
> 499:     total_field_number = start_index;

Nit: The local variable name `total_field_number` is a little bit confusing because it is instantly decreased here (see also the line 490). I'm not sure what name to suggest though. Maybe the comment at line 498 needs an update to say this number is decreased here.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17661#pullrequestreview-1858613748
PR Review Comment: https://git.openjdk.org/jdk/pull/17661#discussion_r1475699883

From aboldtch at openjdk.org  Fri Feb  2 08:09:06 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 2 Feb 2024 08:09:06 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v5]
In-Reply-To: <SfQOKE3h6qi5WUPtrYnONSyE4LkFj5GSAasbX-EL-pM=.74622686-7c65-49f5-8f76-e57d8d86c33f@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
 <8ZG3rV3o0aWMghASjxkM0qLsha99DcXD-paj7UZXn6k=.b0ffccc4-bf8b-4908-9f88-8476153ebe7c@github.com>
 <1irjr5lmhnioRWAwDUKro4hiH0yU4fOxwBMD0ewzRk4=.2f1d1736-e9c7-4279-8684-c6a63bd2077b@github.com>
 <SfQOKE3h6qi5WUPtrYnONSyE4LkFj5GSAasbX-EL-pM=.74622686-7c65-49f5-8f76-e57d8d86c33f@github.com>
Message-ID: <FuCSpD1lpTv8tDyQuQJZwHGjJo6AzEH2C4_EMqR8iW0=.3751742c-638f-4074-adb1-cfee2212b9d8@github.com>

On Thu, 1 Feb 2024 21:52:59 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> src/hotspot/share/runtime/synchronizer.cpp line 1339:
>> 
>>> 1337: }
>>> 1338: 
>>> 1339: ObjectMonitor* ObjectSynchronizer::inflate_impl(JavaThread* thread, oop object, const InflateCause cause) {
>> 
>> I did like the name locking_thread better than just thread.  I see the comment below but I can see also missing the comment and below (it's a long function) deciding that ResourceMark is more efficient when you pass the current thread.  I don't think we managed to rename all "thread" parameter "current" in our cleanups.  Having a longer name makes it more special, which it is.
>
> I'm not fond of `thread` either, but I don't have a better name suggestion.

Given the legacy that of `thread` and `THREAD` being `JavaThread::current()` I will rename this to `inflating_thread` with a comment that this may not always be the `JavaThread::current()` in the case of `ObjectSynchronizer::inflate_for`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17626#discussion_r1475701601

From aboldtch at openjdk.org  Fri Feb  2 08:18:03 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 2 Feb 2024 08:18:03 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v5]
In-Reply-To: <6q3ZHJtx7qg9SFnAGa36P2hzECOXcbCq83lv6evq11A=.c9aa9e23-ddc8-4b45-a565-c68136e76b05@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
 <8ZG3rV3o0aWMghASjxkM0qLsha99DcXD-paj7UZXn6k=.b0ffccc4-bf8b-4908-9f88-8476153ebe7c@github.com>
 <6q3ZHJtx7qg9SFnAGa36P2hzECOXcbCq83lv6evq11A=.c9aa9e23-ddc8-4b45-a565-c68136e76b05@github.com>
Message-ID: <LVfnz9eaFOPWaq8n0R5_4bAwGErrWWJ1i4m9BDkfAeo=.255868e5-12b0-419b-ae43-0406ad8e15d6@github.com>

On Fri, 2 Feb 2024 04:40:16 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix enter_for LockingMode == LM_LEGACY and strengthen assert
>
> src/hotspot/share/runtime/synchronizer.cpp line 1372:
> 
>> 1370:       if (LockingMode == LM_LIGHTWEIGHT && inf->is_owner_anonymous() &&
>> 1371:           thread != nullptr && thread->lock_stack().contains(object)) {
>> 1372:         inf->set_owner_from_anonymous(thread);
> 
> I thought one of the invariants of lightweight locking was that a transition from anonymously owned to actual owner, can only be performed by the actual owner?
> 
> That said, can we actually reach here if not with the current thread? If we are re-locking for deopt then, IIUC, the object has not yet escaped, and has to be unlocked and not with an inflated monitor. In such a case we can't be racing with hashcode inflation either. But perhaps there are other circumstances where re-locking is needed?

Unsure if the `relock_objects` code only re-locks escaped and elided locks, or all elided locks. I believe it is the second. And if we re-lock nested elided locks then they can very well have escaped. (But the lock is guaranteed to be owned by the `deoptee_thread`)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17626#discussion_r1475709904

From rrich at openjdk.org  Fri Feb  2 08:22:02 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Fri, 2 Feb 2024 08:22:02 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v5]
In-Reply-To: <8ZG3rV3o0aWMghASjxkM0qLsha99DcXD-paj7UZXn6k=.b0ffccc4-bf8b-4908-9f88-8476153ebe7c@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
 <8ZG3rV3o0aWMghASjxkM0qLsha99DcXD-paj7UZXn6k=.b0ffccc4-bf8b-4908-9f88-8476153ebe7c@github.com>
Message-ID: <UR268z5Gsle4UWcLSqUJZ2obccH7Kdz2PIpby6w3iiA=.c55463d1-647e-4cdd-a4d5-fce75aef05e4@github.com>

On Thu, 1 Feb 2024 12:40:26 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The `ObjectSynchronizer` has always assumed that the `current` parameters are both the current thread as well as the thread that is doing the locking. The only time that we are entering on behalf of another thread is when doing re-locking in deoptimization. This has worked because the deoptee thread is suspended. However ResourceMarks have been using the wrong thread when logging is enabled.
>> 
>> This change `ObjectSynchronizer` instruments the relevant methods with both a `JavaThread* locking_thread` as well as `[Java]Thread* current` to be able to use the correct thread for ResourceMarks. 
>> 
>> Having the `inflate` care about a `locking_thread` is a little unpleasant in my opinion. But it is required for LM_LIGHTWEIGHT. 
>> Would probably be cleaner if the inflate for LM_LIGHTWEIGHT was it's own thing, as it does not share the whole INFLATING protocol. But seems like a future RFE to refactor this code.
>> 
>> Can reproduce a crash by modifying `test/jdk/com/sun/jdi/EATests.java` and using `-XX:DiagnoseSyncOnValueBasedClasses=2` with LM_LEGACY or running `test/jdk/com/sun/jdi/EATests.java` with LM_LIGHTWEIGHT/LM_MONITOR and `-Xlog:monitorinflation=trace`. 
>> 
>> Could extend this test to capture this regression in the future (or creating a new test based on the same infrastructure). Will give it an attempt, so we have a regression test for this. But these tests get rather involved as the require a lot of jvmti setup.
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix enter_for LockingMode == LM_LEGACY and strengthen assert

src/hotspot/share/runtime/objectMonitor.cpp line 319:

> 317: bool ObjectMonitor::enter_for(JavaThread* locking_thread) {
> 318:   // Used by ObjectSynchronizer::enter_for to enter for another thread
> 319:   // this code may only contend with deflation.

Suggestion:

  // Used by ObjectSynchronizer::enter_for to enter for another thread.
  // The monitor is private to locking_thread which must be suspended. So this code may only contend with deflation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17626#discussion_r1475713519

From aboldtch at openjdk.org  Fri Feb  2 08:32:02 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 2 Feb 2024 08:32:02 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v4]
In-Reply-To: <ZTwzGZxLiUqIBLxzLKafDgxN1WFOggGhc0WkOWIg1FQ=.bbff7ed4-dab7-4154-94e4-adb9b57119b9@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
 <v3omYG7AsGlssh7MwE1E_MJOZPyNfkd4tyIj0FWWtjA=.88c1d7ac-856d-47d4-ad40-1699613ae678@github.com>
 <eTE3Yp-ov2ltp3ANleE3hSVRYHp7edmyIuej5iZe3yU=.fd0da877-f4b3-452a-9b93-18b8d3db946e@github.com>
 <6XZFmbgcUAljdvuMBv0QjDXnX2RTkmqHXQqviZ26BCU=.964ac924-2256-4a48-b53d-7406b8897ec0@github.com>
 <ZTwzGZxLiUqIBLxzLKafDgxN1WFOggGhc0WkOWIg1FQ=.bbff7ed4-dab7-4154-94e4-adb9b57119b9@github.com>
Message-ID: <nQDxl0rZk4Pb61kj0vE-Z5lwkHGU7YlN3pHzAMrD_PQ=.4751cfff-8bc9-4fa4-b069-78cc0a23b636@github.com>

On Thu, 1 Feb 2024 14:14:51 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> What I do in my stress kit runs is redirect the logging output to `../monitorinflation.log`.

Was enough to run not have the tests timeout on a local windows machine, but in the CI some setups run at just around the default timeout limit, so it will intermittently timeout. The LM_LIGHTWEIGHT version with trace logging is enough to capture the regression with wrong the wrong ResourceMark. 

I will replace the LM_MONITOR test run with `GuaranteedAsyncDeflationInterval=1000` but with no logging. Hopefully this will catch any issues with deflation races, without timeout issues on slow debug platform configurations.

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

PR Comment: https://git.openjdk.org/jdk/pull/17626#issuecomment-1923317307

From jwaters at openjdk.org  Fri Feb  2 08:41:06 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 2 Feb 2024 08:41:06 GMT
Subject: RFR: 8316930: HotSpot should use noexcept instead of throw() [v4]
In-Reply-To: <VScr4niHiJs_5LG0Npi39l3fdOa47am0zftg3jO-IsQ=.0905fa3e-2b66-41a5-b015-2bbd9f7b3940@github.com>
References: <kc_cq_sBCqn-iAwHCEaTqgMVYrnT6tKsk3SZnD_qP-s=.1b5d24dd-a925-4f6d-aefb-67b4df6bddac@github.com>
 <VScr4niHiJs_5LG0Npi39l3fdOa47am0zftg3jO-IsQ=.0905fa3e-2b66-41a5-b015-2bbd9f7b3940@github.com>
Message-ID: <2sW1ZQ333qSkLQRk_e-f4g-sOwvW2bKshy8cszUoDrw=.bca141f1-d832-4f95-ad68-47c5fc3d068b@github.com>

On Sun, 21 Jan 2024 07:19:18 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> throw() has been deprecated since C++11 alongside dynamic exception specifications, we should replace all instances of it with noexcept to prepare HotSpot for later versions of C++
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Merge branch 'openjdk:master' into noexcept
>  - Typo in GensrcAdlc.gmk
>  - Merge branch 'openjdk:master' into noexcept
>  - Merge branch 'master' into noexcept
>  - ic in compiledIC.hpp
>  - Revert compiledIC.cpp
>  - Revert compiledIC.hpp
>  - Partially Revert parse.hpp
>  - Merge branch 'master' into noexcept
>  - Merge branch 'master' into noexcept
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/a474b372...0d2fe966

src/hotspot/share/c1/c1_Instruction.hpp line 337:

> 335: 
> 336:  public:
> 337:   void* operator new(size_t size) noexcept {

Should the noexcept specifiers on both operator new in this file be removed? They both call Amalloc with the default parameter of EXIT_OOM, which means they both crash instead of returning nullptr when failing to allocate memory

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15910#discussion_r1475733432

From aboldtch at openjdk.org  Fri Feb  2 08:43:28 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 2 Feb 2024 08:43:28 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v6]
In-Reply-To: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
Message-ID: <Xj9csKLaYy0YAstXeQDoOgX4qzhK6VHf5250FA9nHKw=.d039cb13-5de7-41ba-981c-014b51abf3ad@github.com>

> The `ObjectSynchronizer` has always assumed that the `current` parameters are both the current thread as well as the thread that is doing the locking. The only time that we are entering on behalf of another thread is when doing re-locking in deoptimization. This has worked because the deoptee thread is suspended. However ResourceMarks have been using the wrong thread when logging is enabled.
> 
> This change `ObjectSynchronizer` instruments the relevant methods with both a `JavaThread* locking_thread` as well as `[Java]Thread* current` to be able to use the correct thread for ResourceMarks. 
> 
> Having the `inflate` care about a `locking_thread` is a little unpleasant in my opinion. But it is required for LM_LIGHTWEIGHT. 
> Would probably be cleaner if the inflate for LM_LIGHTWEIGHT was it's own thing, as it does not share the whole INFLATING protocol. But seems like a future RFE to refactor this code.
> 
> Can reproduce a crash by modifying `test/jdk/com/sun/jdi/EATests.java` and using `-XX:DiagnoseSyncOnValueBasedClasses=2` with LM_LEGACY or running `test/jdk/com/sun/jdi/EATests.java` with LM_LIGHTWEIGHT/LM_MONITOR and `-Xlog:monitorinflation=trace`. 
> 
> Could extend this test to capture this regression in the future (or creating a new test based on the same infrastructure). Will give it an attempt, so we have a regression test for this. But these tests get rather involved as the require a lot of jvmti setup.

Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/share/runtime/objectMonitor.cpp
  
  Co-authored-by: Richard Reingruber <richard.reingruber at sap.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17626/files
  - new: https://git.openjdk.org/jdk/pull/17626/files/080c7922..f91e9b2a

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

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

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

From aboldtch at openjdk.org  Fri Feb  2 09:18:04 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 2 Feb 2024 09:18:04 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v5]
In-Reply-To: <LVfnz9eaFOPWaq8n0R5_4bAwGErrWWJ1i4m9BDkfAeo=.255868e5-12b0-419b-ae43-0406ad8e15d6@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
 <8ZG3rV3o0aWMghASjxkM0qLsha99DcXD-paj7UZXn6k=.b0ffccc4-bf8b-4908-9f88-8476153ebe7c@github.com>
 <6q3ZHJtx7qg9SFnAGa36P2hzECOXcbCq83lv6evq11A=.c9aa9e23-ddc8-4b45-a565-c68136e76b05@github.com>
 <LVfnz9eaFOPWaq8n0R5_4bAwGErrWWJ1i4m9BDkfAeo=.255868e5-12b0-419b-ae43-0406ad8e15d6@github.com>
Message-ID: <_q0C7Lvuh3iNoqEOn-uwqhTxkM7j8PAS4U1peSPbQ-s=.f2472ab9-b802-4286-8e59-aeb667d798be@github.com>

On Fri, 2 Feb 2024 08:15:32 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> src/hotspot/share/runtime/synchronizer.cpp line 1372:
>> 
>>> 1370:       if (LockingMode == LM_LIGHTWEIGHT && inf->is_owner_anonymous() &&
>>> 1371:           thread != nullptr && thread->lock_stack().contains(object)) {
>>> 1372:         inf->set_owner_from_anonymous(thread);
>> 
>> I thought one of the invariants of lightweight locking was that a transition from anonymously owned to actual owner, can only be performed by the actual owner?
>> 
>> That said, can we actually reach here if not with the current thread? If we are re-locking for deopt then, IIUC, the object has not yet escaped, and has to be unlocked and not with an inflated monitor. In such a case we can't be racing with hashcode inflation either. But perhaps there are other circumstances where re-locking is needed?
>
> Unsure if the `relock_objects` code only re-locks escaped and elided locks, or all elided locks. I believe it is the second. And if we re-lock nested elided locks then they can very well have escaped. (But the lock is guaranteed to be owned by the `deoptee_thread`)

Given the extra test that @reinrich provided that is exactly what occurs. A nested eliminated lock is re-locked. But the lock is already escaped and contended by another thread.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17626#discussion_r1475774066

From aboldtch at openjdk.org  Fri Feb  2 09:32:29 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 2 Feb 2024 09:32:29 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v7]
In-Reply-To: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
Message-ID: <xlv3iZVTiUabaiRGxfWiMVtqEqLsqmflFqKalAhjAdw=.e56bef54-6e30-44d1-bf9e-b90f405207c5@github.com>

> The `ObjectSynchronizer` has always assumed that the `current` parameters are both the current thread as well as the thread that is doing the locking. The only time that we are entering on behalf of another thread is when doing re-locking in deoptimization. This has worked because the deoptee thread is suspended. However ResourceMarks have been using the wrong thread when logging is enabled.
> 
> This change `ObjectSynchronizer` instruments the relevant methods with both a `JavaThread* locking_thread` as well as `[Java]Thread* current` to be able to use the correct thread for ResourceMarks. 
> 
> Having the `inflate` care about a `locking_thread` is a little unpleasant in my opinion. But it is required for LM_LIGHTWEIGHT. 
> Would probably be cleaner if the inflate for LM_LIGHTWEIGHT was it's own thing, as it does not share the whole INFLATING protocol. But seems like a future RFE to refactor this code.
> 
> Can reproduce a crash by modifying `test/jdk/com/sun/jdi/EATests.java` and using `-XX:DiagnoseSyncOnValueBasedClasses=2` with LM_LEGACY or running `test/jdk/com/sun/jdi/EATests.java` with LM_LIGHTWEIGHT/LM_MONITOR and `-Xlog:monitorinflation=trace`. 
> 
> Could extend this test to capture this regression in the future (or creating a new test based on the same infrastructure). Will give it an attempt, so we have a regression test for this. But these tests get rather involved as the require a lot of jvmti setup.

Axel Boldt-Christmas has updated the pull request incrementally with five additional commits since the last revision:

 - Update comments and nits.
 - Change thread to inflating_thread
 - Update copyright years
 - Monitor with stack lock as owner
 - Improve test configurations

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17626/files
  - new: https://git.openjdk.org/jdk/pull/17626/files/f91e9b2a..be717d5e

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

  Stats: 109 lines in 5 files changed: 77 ins; 2 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/17626.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17626/head:pull/17626

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

From bulasevich at openjdk.org  Fri Feb  2 09:33:31 2024
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Fri, 2 Feb 2024 09:33:31 GMT
Subject: RFR: 8311248: Refactor CodeCache::initialize_heaps to simplify
 adding new CodeCache segments [v6]
In-Reply-To: <-V_dgQKhDrt1n0Zbk3qNa276jZBO822NlSvUv9AhpEA=.7a23c712-4b01-4aa7-acbe-8f5b5cca9002@github.com>
References: <-V_dgQKhDrt1n0Zbk3qNa276jZBO822NlSvUv9AhpEA=.7a23c712-4b01-4aa7-acbe-8f5b5cca9002@github.com>
Message-ID: <qxAv0RZ-f98T5C_WY4wVLyTjEbDFAyFjMuUShnPstW8=.facce7d8-ec20-401d-b6d6-03da493822ed@github.com>

> These changes clean up the logic and the code of allocating codecache segments and add more testing of it, to open a door for further optimization of code cache segmentation.  The goal was to keep the behavior as close to the existing behavior as possible, even if it's not quite logical.
> 
> Also, these changes better account for alignment - PrintFlagsFinal shows the final aligned segment sizes, and the segments fill the ReservedCodeCacheSize without gaps caused by alignment.

Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision:

  set_size_of_unset_code_heap

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17244/files
  - new: https://git.openjdk.org/jdk/pull/17244/files/ea39f93d..b54bbd9a

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

  Stats: 12 lines in 1 file changed: 1 ins; 4 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/17244.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17244/head:pull/17244

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

From bulasevich at openjdk.org  Fri Feb  2 09:33:31 2024
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Fri, 2 Feb 2024 09:33:31 GMT
Subject: RFR: 8311248: Refactor CodeCache::initialize_heaps to simplify
 adding new CodeCache segments [v4]
In-Reply-To: <_pCfQFt76UhuuS57Ok-SVsbbdwl7oCL7wKFcHi34aEY=.dee55198-96cf-4599-b180-2281201d0896@github.com>
References: <-V_dgQKhDrt1n0Zbk3qNa276jZBO822NlSvUv9AhpEA=.7a23c712-4b01-4aa7-acbe-8f5b5cca9002@github.com>
 <_vL8VcUX5WtIwspeQ6xYZZb_Bwe1U9J9Agxk4kb6oaU=.9c6f2cd6-6964-4d82-83c3-1ca5a8039ea7@github.com>
 <hCYKgZeAJ8b60Sag2LDJtlTI7MDg4AN5XlpGZIklsdw=.0e72da4d-b16e-4cba-b44c-44f152853462@github.com>
 <RdHD6i5xaIVTXyj5ZDbXMRb10Iysm9td9IojboncSXY=.966401bb-3080-445e-adcc-3ccae337235f@github.com>
 <_pCfQFt76UhuuS57Ok-SVsbbdwl7oCL7wKFcHi34aEY=.dee55198-96cf-4599-b180-2281201d0896@github.com>
Message-ID: <OWeUhBdVuKjqdHTgwLUzOLdE77Vl6qB1e6Ontmy6Ghs=.f78027db-e710-4569-b11b-e4b12dd4149d@github.com>

On Thu, 1 Feb 2024 15:12:49 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> Again. The idea is to move to a plain, simple, readable code, if you don't mind
>
>> Again. The idea is to move to a plain, simple, readable code, if you don't mind
> 
> I don't think `subtract_size` is a good name for the function.
> Why does it have three parameters? Logically a subtract operation is `a - b`. A reader of the code will have to go to the definition of the function to understand its logic. This means you can save reader's time just putting the code of `subtract_size` in place or giving more meaningful name.

Right. set_size_of_unset_code_heap name is better. Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17244#discussion_r1475787806

From aboldtch at openjdk.org  Fri Feb  2 09:36:04 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 2 Feb 2024 09:36:04 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v7]
In-Reply-To: <xlv3iZVTiUabaiRGxfWiMVtqEqLsqmflFqKalAhjAdw=.e56bef54-6e30-44d1-bf9e-b90f405207c5@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
 <xlv3iZVTiUabaiRGxfWiMVtqEqLsqmflFqKalAhjAdw=.e56bef54-6e30-44d1-bf9e-b90f405207c5@github.com>
Message-ID: <7rn8ETNXJTLZS4E_aV1BPi4qqe6vHBRmV3XXatBT260=.4106dff3-c489-413a-a066-7965f838dd33@github.com>

On Fri, 2 Feb 2024 09:32:29 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The `ObjectSynchronizer` has always assumed that the `current` parameters are both the current thread as well as the thread that is doing the locking. The only time that we are entering on behalf of another thread is when doing re-locking in deoptimization. This has worked because the deoptee thread is suspended. However ResourceMarks have been using the wrong thread when logging is enabled.
>> 
>> This change `ObjectSynchronizer` instruments the relevant methods with both a `JavaThread* locking_thread` as well as `[Java]Thread* current` to be able to use the correct thread for ResourceMarks. 
>> 
>> Having the `inflate` care about a `locking_thread` is a little unpleasant in my opinion. But it is required for LM_LIGHTWEIGHT. 
>> Would probably be cleaner if the inflate for LM_LIGHTWEIGHT was it's own thing, as it does not share the whole INFLATING protocol. But seems like a future RFE to refactor this code.
>> 
>> Can reproduce a crash by modifying `test/jdk/com/sun/jdi/EATests.java` and using `-XX:DiagnoseSyncOnValueBasedClasses=2` with LM_LEGACY or running `test/jdk/com/sun/jdi/EATests.java` with LM_LIGHTWEIGHT/LM_MONITOR and `-Xlog:monitorinflation=trace`. 
>> 
>> Could extend this test to capture this regression in the future (or creating a new test based on the same infrastructure). Will give it an attempt, so we have a regression test for this. But these tests get rather involved as the require a lot of jvmti setup.
>
> Axel Boldt-Christmas has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - Update comments and nits.
>  - Change thread to inflating_thread
>  - Update copyright years
>  - Monitor with stack lock as owner
>  - Improve test configurations

I think all review comments have been addressed now. Will run a more thorough run through our CI over the weekend and integrate early next week sans any issues.

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

PR Comment: https://git.openjdk.org/jdk/pull/17626#issuecomment-1923419960

From shade at openjdk.org  Fri Feb  2 09:47:28 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 2 Feb 2024 09:47:28 GMT
Subject: RFR: 8324833: Signed integer overflows in ABS [v3]
In-Reply-To: <ohwAn6GqM7FIgYTJNy40VBYSCVEBrrNSqBaz2akN54M=.f9660235-3047-47ee-aad0-ef598d6ebdcc@github.com>
References: <ohwAn6GqM7FIgYTJNy40VBYSCVEBrrNSqBaz2akN54M=.f9660235-3047-47ee-aad0-ef598d6ebdcc@github.com>
Message-ID: <6kxKhJVXB2X7ni4SLMtL--Pt5O8bUOazcI9F3FJgG8o=.55b0e9bd-075c-4b76-bcc6-732951e8a512@github.com>

> See the details in the bug. I think current `ABS` implementation is beyond repair, and we should just switch to `uabs`.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, `all` with `-ftrapv` (now fully passes!)
>  - [x] Linux x86_64 fastdebug, `all`

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Touchups

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17617/files
  - new: https://git.openjdk.org/jdk/pull/17617/files/00d4d84b..96a1987c

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

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

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

From shade at openjdk.org  Fri Feb  2 09:47:28 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 2 Feb 2024 09:47:28 GMT
Subject: RFR: 8324833: Signed integer overflows in ABS [v3]
In-Reply-To: <r4Fyb__l1HBZZSIcLlGuRNA8ZDy7h67rOyCVkU23uZg=.b03dbedc-01bb-4e92-8f98-ebf40d51937d@github.com>
References: <ohwAn6GqM7FIgYTJNy40VBYSCVEBrrNSqBaz2akN54M=.f9660235-3047-47ee-aad0-ef598d6ebdcc@github.com>
 <keBLe_kqh25x7IdMWimvIQshpubvKZrP0KPf4Lphoy4=.447c2d2e-3c08-4d85-a9c3-3bd356cfc8a4@github.com>
 <r4Fyb__l1HBZZSIcLlGuRNA8ZDy7h67rOyCVkU23uZg=.b03dbedc-01bb-4e92-8f98-ebf40d51937d@github.com>
Message-ID: <nqH9XVyMCcY0GPMWrCVgWT47TcE9tYo57sbv9V_EX6Y=.859fc693-23fd-4a6e-abf9-ba1f6f4bb9b5@github.com>

On Thu, 1 Feb 2024 20:23:04 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Touchups
>
> src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 1063:
> 
>> 1061:     int64_t off_low = (int64_t)target_addr - ((int64_t)CodeCache::low_bound() + sizeof(int));
>> 1062:     int64_t off_high = (int64_t)target_addr - ((int64_t)CodeCache::high_bound() + sizeof(int));
>> 1063:     return MAX2(ABS(off_low), ABS(off_high));
> 
> Wouldn't this trigger a warning with -Wsign-conversion enabled?

Maybe? I added `checked_cast` in this place in new commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17617#discussion_r1475807979

From shade at openjdk.org  Fri Feb  2 09:47:29 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 2 Feb 2024 09:47:29 GMT
Subject: RFR: 8324833: Signed integer overflows in ABS [v2]
In-Reply-To: <r4Fyb__l1HBZZSIcLlGuRNA8ZDy7h67rOyCVkU23uZg=.b03dbedc-01bb-4e92-8f98-ebf40d51937d@github.com>
References: <ohwAn6GqM7FIgYTJNy40VBYSCVEBrrNSqBaz2akN54M=.f9660235-3047-47ee-aad0-ef598d6ebdcc@github.com>
 <keBLe_kqh25x7IdMWimvIQshpubvKZrP0KPf4Lphoy4=.447c2d2e-3c08-4d85-a9c3-3bd356cfc8a4@github.com>
 <r4Fyb__l1HBZZSIcLlGuRNA8ZDy7h67rOyCVkU23uZg=.b03dbedc-01bb-4e92-8f98-ebf40d51937d@github.com>
Message-ID: <Is3VoFi5UnTfUpAVSggMltszbQ5Nkc3KDZLcY2ZcuXM=.6e337f36-6904-4986-a58b-ca206e8a4ba6@github.com>

On Thu, 1 Feb 2024 20:24:55 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Unnecessary comment
>
> src/hotspot/share/opto/ifnode.cpp line 1978:
> 
>> 1976:           // "x - y" -> must add one to the difference for number of elements in [x,y]
>> 1977:           const jlong diff = (jlong)MIN2(offset2, off_lo) - (jlong)MAX2(offset2, off_hi);
>> 1978:           if (uabs(diff) < maximum_number_of_min_max_interval_indices) {
> 
> unsigned vs signed comparison.  Maybe the rhs should be unsigned as well?

Yes, fixed in new commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17617#discussion_r1475807552

From aboldtch at openjdk.org  Fri Feb  2 09:52:15 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 2 Feb 2024 09:52:15 GMT
Subject: RFR: 8319801: Recursive lightweight locking: aarch64
 implementation [v12]
In-Reply-To: <AE1nsnyRCUHR970jjg4feUm5f6E1GPJvea0ooC6dCgI=.73fff610-c0f6-422a-a45d-88187b37b9a2@github.com>
References: <AE1nsnyRCUHR970jjg4feUm5f6E1GPJvea0ooC6dCgI=.73fff610-c0f6-422a-a45d-88187b37b9a2@github.com>
Message-ID: <ruRJ7cikVJ3hDDyjE5esuD_bsXlnJJZ8vmWs7dXVHAM=.0b1ca4c5-dd41-4a58-99b4-46a81e0a7ac2@github.com>

> Implements the aarch64 port of JDK-8319796.
> 
> There are two major parts for the port implementation. The C2 part, and the part shared by the interpreter, C1 and the native call wrapper.
> 
> The biggest change for both parts is that we check the lock stack first and if it is a recursive lightweight [un]lock and in that case simply pop/push and finish successfully.
> 
> Only if the recursive lightweight [un]lock fails does it look at the mark word. 
> 
> For the shared part if it is an unstructured exit, the monitor is inflated or the mark word transition fails it calls into the runtime.
> 
> The C2 operates under a few more assumptions, that the locking is structured and balanced. This means that some checks can be elided. 
> 
> First this means that in C2 unlock if the obj is not on the top of the lock stack, it must be inflated. And reversely if we reach the inflated C2 unlock the obj is not on the lock stack. This second property makes it possible to avoid reading the owner (and checking if it is anonymous). Instead it can either just do an un-contended unlock by writing null to the owner, or if contention happens, simply write the thread to the owner and jump to the runtime. 
> 
> The aarch64 C2 port tries to avoid stronger memory semantics where ever possible. In C2 lock it first does a relaxed load of the mark word to check for inflation. Both lock and unlock uses a load/store exclusive register pair to transition the mark word.

Axel Boldt-Christmas has updated the pull request incrementally with four additional commits since the last revision:

 - Update src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp
   
   Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>
 - Clarify the rscratch1 assert
 - Comments and nits
 - Update copyright years

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16608/files
  - new: https://git.openjdk.org/jdk/pull/16608/files/d0a02754..130cf4b7

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

  Stats: 15 lines in 8 files changed: 1 ins; 1 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/16608.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16608/head:pull/16608

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

From aboldtch at openjdk.org  Fri Feb  2 09:59:20 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 2 Feb 2024 09:59:20 GMT
Subject: RFR: 8319797: Recursive lightweight locking: Runtime
 implementation [v17]
In-Reply-To: <ZWyjRIBdi5FeGTDfaIEmT_lBfg1n9MDl3vxA5g-FKbc=.cb26afcc-555b-4a80-b4f2-319c5422646b@github.com>
References: <ZWyjRIBdi5FeGTDfaIEmT_lBfg1n9MDl3vxA5g-FKbc=.cb26afcc-555b-4a80-b4f2-319c5422646b@github.com>
Message-ID: <MOjCD1To_M7TybJYg0eN9yOwS-VDxgo7VCKUgPFACLM=.bf03c8e1-c87c-49f0-a8fa-8f8b9a91e91c@github.com>

> Implements the runtime part of JDK-8319796.
> The different CPU implementations are/will be created as dependent pull requests.
> 
> This enhancement proposes introducing the ability for LM_LIGHTWEIGHT to handle consecutive recursive monitor enter. Limiting the implementation to only consecutive monitor enters allows for more efficient emitted code which only needs to look at the two top most entires on the lock stack to determine what to do in a monitor exit.
> 
> A high level overview:
>   * Locking is still performed on the mark word
>     * Unlocked (0b01) <=> Locked (0b00)
>   * Monitor enter on Obj with mark word Unlocked (0b01) is the same
>     * Transition Obj's mark word Unlocked (0b01) => Locked (0b00)
>     * Push Obj onto the lock stack
>     * Success
>   * Monitor enter on Obj with mark word Locked (0b00) will check the top entry on the lock stack
>     * If top entry is Obj
>       * Push Obj on the lock stack
>       * Success
>     * If top entry is not Obj
>       * Inflate and call ObjectMonitor::enter
>   * Monitor exit on Obj with mark word Locked (0b00) will check the two top entries on the lock stack
>     * If just the top entry is Obj
>       * Transition Obj's mark word Locked (0b00) => Unlocked (0b01)
>       * Pop the entry
>       * Success
>     * If both entries are Obj
>       * Pop the top entry
>       * Success
>     * Any other case only occurs for unstructured locking, then just inflate and call ObjectMonitor::exit
>   * If the monitor has been inflated for object Obj which is owned by the current thread
>     * All corresponding entries for Obj is removed from the lock stack
>     * The monitor recursions is set to the number of removed entries - 1
>     * The owner is changed from anonymous to the thread
>     * The regular ObjectMonitor::action is called.

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 52 commits:

 - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8319797
 - Fix assert comment
 - Update copyright
 - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8319797
 - Add verify calls
 - Assert valid lock stack offset
 - Typos, wording and whitespace
 - Fix miss in is_recursive improvement
 - Added comment about the rational behind full lock stack inflation. May need rewording
 - Add logging when lock stack capacity is exceeded.
 - ... and 42 more: https://git.openjdk.org/jdk/compare/783ae566...866171e8

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

Changes: https://git.openjdk.org/jdk/pull/16606/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16606&range=16
  Stats: 867 lines in 13 files changed: 817 ins; 7 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/16606.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16606/head:pull/16606

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

From aboldtch at openjdk.org  Fri Feb  2 10:20:40 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 2 Feb 2024 10:20:40 GMT
Subject: RFR: 8319801: Recursive lightweight locking: aarch64
 implementation [v13]
In-Reply-To: <AE1nsnyRCUHR970jjg4feUm5f6E1GPJvea0ooC6dCgI=.73fff610-c0f6-422a-a45d-88187b37b9a2@github.com>
References: <AE1nsnyRCUHR970jjg4feUm5f6E1GPJvea0ooC6dCgI=.73fff610-c0f6-422a-a45d-88187b37b9a2@github.com>
Message-ID: <tQBTilK3gaS97w0nL4pgf76dt4EjWhWkiCQFZCLsA1w=.e0e98db1-1d55-481c-8419-dc225e872921@github.com>

> Implements the aarch64 port of JDK-8319796.
> 
> There are two major parts for the port implementation. The C2 part, and the part shared by the interpreter, C1 and the native call wrapper.
> 
> The biggest change for both parts is that we check the lock stack first and if it is a recursive lightweight [un]lock and in that case simply pop/push and finish successfully.
> 
> Only if the recursive lightweight [un]lock fails does it look at the mark word. 
> 
> For the shared part if it is an unstructured exit, the monitor is inflated or the mark word transition fails it calls into the runtime.
> 
> The C2 operates under a few more assumptions, that the locking is structured and balanced. This means that some checks can be elided. 
> 
> First this means that in C2 unlock if the obj is not on the top of the lock stack, it must be inflated. And reversely if we reach the inflated C2 unlock the obj is not on the lock stack. This second property makes it possible to avoid reading the owner (and checking if it is anonymous). Instead it can either just do an un-contended unlock by writing null to the owner, or if contention happens, simply write the thread to the owner and jump to the runtime. 
> 
> The aarch64 C2 port tries to avoid stronger memory semantics where ever possible. In C2 lock it first does a relaxed load of the mark word to check for inflation. Both lock and unlock uses a load/store exclusive register pair to transition the mark word.

Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319801
 - Update src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp
   
   Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>
 - Clarify the rscratch1 assert
 - Comments and nits
 - Update copyright years
 - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319801
 - Drop memory order comments
 - Preloads markWord unconditionally
 - Revert "Add preload_mark to MacroAssembler::lightweight_lock"
   
   This reverts commit 8950f503aa5dba0e203613bd9737ea0d50388ca3.
 - Add preload_mark to MacroAssembler::lightweight_lock
 - ... and 12 more: https://git.openjdk.org/jdk/compare/580387f7...2d4ba75d

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16608/files
  - new: https://git.openjdk.org/jdk/pull/16608/files/130cf4b7..2d4ba75d

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

  Stats: 19589 lines in 1224 files changed: 7474 ins; 1792 del; 10323 mod
  Patch: https://git.openjdk.org/jdk/pull/16608.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16608/head:pull/16608

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

From aboldtch at openjdk.org  Fri Feb  2 10:19:49 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 2 Feb 2024 10:19:49 GMT
Subject: RFR: 8319799: Recursive lightweight locking: x86 implementation
 [v16]
In-Reply-To: <ymgsUW7sq02C2r82WrLYof5Eb7BB5Lh8M-kGoHx_Zjg=.a5a76651-4931-489f-8ea1-158716614119@github.com>
References: <ymgsUW7sq02C2r82WrLYof5Eb7BB5Lh8M-kGoHx_Zjg=.a5a76651-4931-489f-8ea1-158716614119@github.com>
Message-ID: <tskIi-qUzPDiB_VUBOsnvjZLKtF1L04Elq4QBs5PEGE=.ac62d4f7-4493-4c65-bbeb-edcd32b843f6@github.com>

> Implements the x86 port of JDK-8319796.
> 
> There are two major parts for the port implementation. The C2 part, and the part shared by the interpreter, C1 and the native call wrapper.
> 
> The biggest change for both parts is that we check the lock stack first and if it is a recursive lightweight [un]lock and in that case simply pop/push and finish successfully.
> 
> Only if the recursive lightweight [un]lock fails does it look at the mark word. 
> 
> For the shared part if it is an unstructured exit, the monitor is inflated or the mark word transition fails it calls into the runtime.
> 
> The C2 operates under a few more assumptions, that the locking is structured and balanced. This means that some checks can be elided. 
> 
> First this means that in C2 unlock if the obj is not on the top of the lock stack, it must be inflated. And reversely if we reach the inflated C2 unlock the obj is not on the lock stack. This second property makes it possible to avoid reading the owner (and checking if it is anonymous). Instead it can either just do an un-contended unlock by writing null to the owner, or if contention happens, simply write the thread to the owner and jump to the runtime. 
> 
> The x86 C2 port also has some extra oddities. 
> 
> The mark word read is done early as it showed better scaling in hyper-threaded scenarios on certain intel hardware, and no noticeable downside on other tested x86 hardware. 
> 
> The fast path is written to avoid going through conditional branches. This in combination with keeping the ZF output correct, the code does some actions eagerly, decrementing the held monitor count, popping from the lock stack. And jumps to a code stub if a slow path is required which restores the thread local state to a correct state before jumping to the runtime.
> 
> The contended unlock was also moved to the code stub.

Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 26 additional commits since the last revision:

 - Comment indent
 - Update copyright years
 - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319799
 - Update MacroAssembler::lightweight_unlock comments.
 - Update comments and asserts
 - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319799
 - Update variable names in ad files
 - Preload markWord unconditionally
 - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319799
 - Add more expressive stub continuation names
 - ... and 16 more: https://git.openjdk.org/jdk/compare/23730e88...36895d2a

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16607/files
  - new: https://git.openjdk.org/jdk/pull/16607/files/d845e31d..36895d2a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16607&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16607&range=14-15

  Stats: 19600 lines in 1231 files changed: 7474 ins; 1792 del; 10334 mod
  Patch: https://git.openjdk.org/jdk/pull/16607.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16607/head:pull/16607

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

From ihse at openjdk.org  Fri Feb  2 10:53:06 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Feb 2024 10:53:06 GMT
Subject: RFR: 8314488: Compile the JDK as C++17 [v6]
In-Reply-To: <b4HhbT5caIfCbrVveI6NDObiwUI2Sr0so68JBG6C0YU=.1734aaa7-aed4-478c-bbb6-de9af5c04ef9@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
 <b4HhbT5caIfCbrVveI6NDObiwUI2Sr0so68JBG6C0YU=.1734aaa7-aed4-478c-bbb6-de9af5c04ef9@github.com>
Message-ID: <max72aOIe8eZq_UWLHt0vxJWYl1y8K8GelV-0Wwuphw=.03b9b0d8-91bf-4047-988b-594d66515623@github.com>

On Thu, 11 Jan 2024 13:23:45 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Compile the JDK as C++17, enabling the use of all C++17 language features
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Require clang 13 in toolchain.m4

Nobody complained about raising gcc to 10, see https://mail.openjdk.org/pipermail/build-dev/2024-January/042802.html.

@TheShermanTanker Can you update this PR so it sets the minimum gcc to 10.0 instead of 9.0?

@shipilev Are you okay with us moving forward with this? If not, I'd like to see an concrete example of where this will create a problem, so we can discuss if the general good for the platform can be dictated by that use case.

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

PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1923553875

From ihse at openjdk.org  Fri Feb  2 11:00:05 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Feb 2024 11:00:05 GMT
Subject: RFR: 8314488: Compile the JDK as C++17 [v6]
In-Reply-To: <dPy4l9uw0sxvaaDrmDXLvtnfMBnfq6NN4_iGRZ47chA=.1cd2983b-6a75-4b92-a7b1-5a8f96e4b623@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
 <b4HhbT5caIfCbrVveI6NDObiwUI2Sr0so68JBG6C0YU=.1734aaa7-aed4-478c-bbb6-de9af5c04ef9@github.com>
 <dPy4l9uw0sxvaaDrmDXLvtnfMBnfq6NN4_iGRZ47chA=.1cd2983b-6a75-4b92-a7b1-5a8f96e4b623@github.com>
Message-ID: <UT9u7dzmczU75H7RImYDO6rEQ_5AtWwrvs6PfUR_HqE=.52a325d7-06a7-4fef-9d1f-1a821be9b98e@github.com>

On Fri, 19 Jan 2024 12:08:21 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Require clang 13 in toolchain.m4
>
> Should I split the compiler upgrades into a different change and integrate that first? Going off the conversation in this thread it would seem like the compiler upgrade would benefit us a lot more than just having C++17 (The noreturn attribute is one big motivating factor for instance) and it might help if the compiler upgrades were not delayed by the discussion of when to jump to C++17

Also, @TheShermanTanker, can you please incorporate this patch that updates the build documentation to match the changes in configure?


diff --git a/doc/building.html b/doc/building.html
index 7fd530e9dbc..bb5fda24ba7 100644
--- a/doc/building.html
+++ b/doc/building.html
@@ -599,14 +599,14 @@ <h2 id="native-compiler-toolchain-requirements">Native Compiler
 <p>All compilers are expected to be able to handle the C11 language
 standard for C, and C++14 for C++.</p>
 <h3 id="gcc">gcc</h3>
-<p>The minimum accepted version of gcc is 6.0. Older versions will not
+<p>The minimum accepted version of gcc is 10.0. Older versions will not
 be accepted by <code>configure</code>.</p>
 <p>The JDK is currently known to compile successfully with gcc version
 13.2 or newer.</p>
 <p>In general, any version between these two should be usable.</p>
 <h3 id="clang">clang</h3>
-<p>The minimum accepted version of clang is 3.5. Older versions will not
-be accepted by <code>configure</code>.</p>
+<p>The minimum accepted version of clang is 13.0. Older versions will
+not be accepted by <code>configure</code>.</p>
 <p>To use clang instead of gcc on Linux, use
 <code>--with-toolchain-type=clang</code>.</p>
 <h3 id="apple-xcode">Apple Xcode</h3>
@@ -672,7 +672,9 @@ <h3 id="microsoft-visual-studio">Microsoft Visual Studio</h3>
 <code>BuildTools</code>, but e.g. <code>Professional</code>, adjust the
 product ID accordingly.</p>
 <h3 id="ibm-xl-cc">IBM XL C/C++</h3>
-<p>Please consult the AIX section of the <a
+<p>The minimum accepted version of xlc is 17.1.1.4. Older versions will
+not be accepted by <code>configure</code>.</p>
+<p>For further information, please consult the AIX section of the <a
 href="https://wiki.openjdk.org/display/Build/Supported+Build+Platforms">Supported
 Build Platforms</a> OpenJDK Build Wiki page for details about which
 versions of XLC are supported.</p>
diff --git a/doc/building.md b/doc/building.md
index de410439446..9113e0243bd 100644
--- a/doc/building.md
+++ b/doc/building.md
@@ -403,7 +403,7 @@ ## Native Compiler (Toolchain) Requirements
 
 ### gcc
 
-The minimum accepted version of gcc is 6.0. Older versions will not be accepted
+The minimum accepted version of gcc is 10.0. Older versions will not be accepted
 by `configure`.
 
 The JDK is currently known to compile successfully with gcc version 13.2 or
@@ -413,7 +413,7 @@ ### gcc
 
 ### clang
 
-The minimum accepted version of clang is 3.5. Older versions will not be
+The minimum accepted version of clang is 13.0. Older versions will not be
 accepted by `configure`.
 
 To use clang instead of gcc on Linux, use `--with-toolchain-type=clang`.
@@ -489,9 +489,12 @@ ### Microsoft Visual Studio
 
 ### IBM XL C/C++
 
-Please consult the AIX section of the [Supported Build Platforms](
-https://wiki.openjdk.org/display/Build/Supported+Build+Platforms) OpenJDK Build
-Wiki page for details about which versions of XLC are supported.
+The minimum accepted version of xlc is 17.1.1.4. Older versions will not be
+accepted by `configure`.
+
+For further information, please consult the AIX section of the [Supported Build
+Platforms](https://wiki.openjdk.org/display/Build/Supported+Build+Platforms)
+OpenJDK Build Wiki page for details about which versions of XLC are supported.
 
 ## Boot JDK Requirements

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

PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1923565064

From redestad at openjdk.org  Fri Feb  2 12:30:00 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 2 Feb 2024 12:30:00 GMT
Subject: RFR: 8321468: Remove StringUTF16::equals
In-Reply-To: <CySSsfGkTiz_6q09rb7VCW_rGwin9V8NN-Ugh8Wltds=.9a4652c2-4b0a-4644-8a48-f9ee6dd5abc4@github.com>
References: <CySSsfGkTiz_6q09rb7VCW_rGwin9V8NN-Ugh8Wltds=.9a4652c2-4b0a-4644-8a48-f9ee6dd5abc4@github.com>
Message-ID: <4uEu7i9FQoNW8OSV-CaTvINOHXPfhoBSFx4pXygZTec=.92203df2-18b1-4697-942a-7424c43bbc95@github.com>

On Wed, 6 Dec 2023 14:20:14 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8215017 removed the only use of `StringUTF16::equals`. At the time I did some performance verification focused on x86 showing that simplifying and only using `StringLatin1::equals` was either neutral or a win. 
> 
> I repeated this experiment recently, adding some focused tests on aarch64 where the code generation actually tries to take advantage and generate slightly more efficient code for `StringUTF16::equals`: 
> https://github.com/openjdk/jdk/pull/16933#discussion_r1414118658
> 
> The indication here is that disabling use of `StringUTF16::equals` was the right choice: any effect from the low-level optimization (one less branch at the tail end) was offset by the `isLatin1()` branch and added code generation (that all gets inlined).
> 
> In a `-XX:-CompactStrings` configuration the slightly improved code generation in `StringUTF16::equals` might help, since the `isLatin1()` test and subsequent call to `StringLatin1::equals` would be DCEd. To get the best of both worlds the code in `String::equals` _could_ be sharpened so that we statically pick the best implementation based on `CompactStrings` mode (see comment below). This shows a tiny win when testing with `-XX:-CompactStrings` on M1 (up to -0.2ns/op per `String::equals`; neutral on x86). But is all this complexity worth it for a gain that will get lost in the noise on anything realistic?
> 
> This PR instead proposes removing `StringUTF16::equals` and simplifying the mechanisms to support the `StringLatin1/UTF16::equals` pair of intrinsics in hotspot.

Can I please get a review for this cleanup?

This PR does not cause a regression to `-XX:-CompactStrings`; a very minor regression as detailed in comments was caused by https://bugs.openjdk.org/browse/JDK-8215017  -- If this regression is a real concern we can recuperate this by making the emitted intrinsics use `-CompactStrings` as a signal to optimize away the one-byte tail checks in a follow-up PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/16995#issuecomment-1923705005

From rriggs at openjdk.org  Fri Feb  2 14:56:01 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 2 Feb 2024 14:56:01 GMT
Subject: RFR: 8321468: Remove StringUTF16::equals
In-Reply-To: <CySSsfGkTiz_6q09rb7VCW_rGwin9V8NN-Ugh8Wltds=.9a4652c2-4b0a-4644-8a48-f9ee6dd5abc4@github.com>
References: <CySSsfGkTiz_6q09rb7VCW_rGwin9V8NN-Ugh8Wltds=.9a4652c2-4b0a-4644-8a48-f9ee6dd5abc4@github.com>
Message-ID: <r1LAh7XD4O2D1vvsQTkMqoXGNSxEhx7CYt3yWixuPnQ=.08ca0342-3686-46e1-9196-75794ce783cb@github.com>

On Wed, 6 Dec 2023 14:20:14 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8215017 removed the only use of `StringUTF16::equals`. At the time I did some performance verification focused on x86 showing that simplifying and only using `StringLatin1::equals` was either neutral or a win. 
> 
> I repeated this experiment recently, adding some focused tests on aarch64 where the code generation actually tries to take advantage and generate slightly more efficient code for `StringUTF16::equals`: 
> https://github.com/openjdk/jdk/pull/16933#discussion_r1414118658
> 
> The indication here is that disabling use of `StringUTF16::equals` was the right choice: any effect from the low-level optimization (one less branch at the tail end) was offset by the `isLatin1()` branch and added code generation (that all gets inlined).
> 
> In a `-XX:-CompactStrings` configuration the slightly improved code generation in `StringUTF16::equals` might help, since the `isLatin1()` test and subsequent call to `StringLatin1::equals` would be DCEd. To get the best of both worlds the code in `String::equals` _could_ be sharpened so that we statically pick the best implementation based on `CompactStrings` mode (see comment below). This shows a tiny win when testing with `-XX:-CompactStrings` on M1 (up to -0.2ns/op per `String::equals`; neutral on x86). But is all this complexity worth it for a gain that will get lost in the noise on anything realistic?
> 
> This PR instead proposes removing `StringUTF16::equals` and simplifying the mechanisms to support the `StringLatin1/UTF16::equals` pair of intrinsics in hotspot.

LGTM for the core-libs point of view. (And what I understand of the assembler)

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16995#pullrequestreview-1859448983

From redestad at openjdk.org  Fri Feb  2 15:00:09 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 2 Feb 2024 15:00:09 GMT
Subject: RFR: 8321468: Remove StringUTF16::equals
In-Reply-To: <r1LAh7XD4O2D1vvsQTkMqoXGNSxEhx7CYt3yWixuPnQ=.08ca0342-3686-46e1-9196-75794ce783cb@github.com>
References: <CySSsfGkTiz_6q09rb7VCW_rGwin9V8NN-Ugh8Wltds=.9a4652c2-4b0a-4644-8a48-f9ee6dd5abc4@github.com>
 <r1LAh7XD4O2D1vvsQTkMqoXGNSxEhx7CYt3yWixuPnQ=.08ca0342-3686-46e1-9196-75794ce783cb@github.com>
Message-ID: <GKGhNXsZ1htX9awhAPWt4UcC0SP5pFZ44nrJL_b8n38=.b6efb955-6f23-41fe-974c-13b181d1ee12@github.com>

On Fri, 2 Feb 2024 14:53:51 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> LGTM for the core-libs point of view. (And what I understand of the assembler)

Thanks!

I'll try to get someone from the compiler team to look over the assembler change. @TobiHartmann, can you help get some eyes on this?

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

PR Comment: https://git.openjdk.org/jdk/pull/16995#issuecomment-1924049126

From rrich at openjdk.org  Fri Feb  2 15:00:10 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Fri, 2 Feb 2024 15:00:10 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v5]
In-Reply-To: <_q0C7Lvuh3iNoqEOn-uwqhTxkM7j8PAS4U1peSPbQ-s=.f2472ab9-b802-4286-8e59-aeb667d798be@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
 <8ZG3rV3o0aWMghASjxkM0qLsha99DcXD-paj7UZXn6k=.b0ffccc4-bf8b-4908-9f88-8476153ebe7c@github.com>
 <6q3ZHJtx7qg9SFnAGa36P2hzECOXcbCq83lv6evq11A=.c9aa9e23-ddc8-4b45-a565-c68136e76b05@github.com>
 <LVfnz9eaFOPWaq8n0R5_4bAwGErrWWJ1i4m9BDkfAeo=.255868e5-12b0-419b-ae43-0406ad8e15d6@github.com>
 <_q0C7Lvuh3iNoqEOn-uwqhTxkM7j8PAS4U1peSPbQ-s=.f2472ab9-b802-4286-8e59-aeb667d798be@github.com>
Message-ID: <jcNvyPaD_RFHjENtzmKTktw3H95xYv1NcyRLQpZOaoo=.f9d8ad89-e56c-4a37-9568-67fe564523ed@github.com>

On Fri, 2 Feb 2024 09:14:58 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Given the extra test that @reinrich provided that is exactly what occurs. A nested eliminated lock is re-locked. But the lock is already escaped and contended by another thread.

We didn't reach there with LM_LIGHTWEIGHT. The lock got inflated during warm-up because of the recursive monitorenter in the interpreter. The owner was set to the current thread then. I've improved the test to use a new instance after warm-up. If you want you can cherry-pick here: https://github.com/reinrich/jdk/commit/c28181d585e5ceeaa34e7e6afb4311d59cf990b2

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17626#discussion_r1476165717

From rkennke at openjdk.org  Fri Feb  2 15:02:15 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 2 Feb 2024 15:02:15 GMT
Subject: RFR: 8139457: Relax alignment of array elements [v63]
In-Reply-To: <WV_VV81FK5KX-ubcyxrsmQzQf8ZpMh05wX-k0i9BKXM=.2b85ee3c-b1ee-42ec-9ce8-649fba4a65a8@github.com>
References: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
 <WV_VV81FK5KX-ubcyxrsmQzQf8ZpMh05wX-k0i9BKXM=.2b85ee3c-b1ee-42ec-9ce8-649fba4a65a8@github.com>
Message-ID: <2j5u-tfXGoiqrC7_Wa4L7ODCjl3jlQmec-PB1Nad18M=.24be9580-66b3-4f5f-8643-f8d143978471@github.com>

On Thu, 9 Nov 2023 19:59:51 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details.
>> 
>> Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements.
>> 
>> Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16.
>> 
>> Testing:
>>  - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390)
>>  - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390)
>>  - [x] tier1 (x86_64, x86_32, aarch64, riscv)
>>  - [x] tier2 (x86_64, aarch64, riscv)
>>  - [x] tier3 (x86_64, riscv)
>
> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 92 commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into JDK-8139457
>  - Update copyright headers
>  - Merge branch 'master' into JDK-8139457
>  - Fix ARM build
>  - Merge remote-tracking branch 'upstream/master' into JDK-8139457
>  - Various cleanups
>  - RISC changes
>  - Move gap init into allocate_header() (x86)
>  - Fix gtest failure on x86
>  - Merge remote-tracking branch 'upstream/master' into JDK-8139457
>  - ... and 82 more: https://git.openjdk.org/jdk/compare/38745eca...bb16aeda

Not yet, bot.

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

PR Comment: https://git.openjdk.org/jdk/pull/11044#issuecomment-1924052988

From aboldtch at openjdk.org  Fri Feb  2 15:11:19 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 2 Feb 2024 15:11:19 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v8]
In-Reply-To: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
Message-ID: <zLj4iQnZnflZHsPmnWqIEHrtudnRFCTYTheh88mjnYg=.522c38c6-8e1a-4869-be04-8a7efc0d28cf@github.com>

> The `ObjectSynchronizer` has always assumed that the `current` parameters are both the current thread as well as the thread that is doing the locking. The only time that we are entering on behalf of another thread is when doing re-locking in deoptimization. This has worked because the deoptee thread is suspended. However ResourceMarks have been using the wrong thread when logging is enabled.
> 
> This change `ObjectSynchronizer` instruments the relevant methods with both a `JavaThread* locking_thread` as well as `[Java]Thread* current` to be able to use the correct thread for ResourceMarks. 
> 
> Having the `inflate` care about a `locking_thread` is a little unpleasant in my opinion. But it is required for LM_LIGHTWEIGHT. 
> Would probably be cleaner if the inflate for LM_LIGHTWEIGHT was it's own thing, as it does not share the whole INFLATING protocol. But seems like a future RFE to refactor this code.
> 
> Can reproduce a crash by modifying `test/jdk/com/sun/jdi/EATests.java` and using `-XX:DiagnoseSyncOnValueBasedClasses=2` with LM_LEGACY or running `test/jdk/com/sun/jdi/EATests.java` with LM_LIGHTWEIGHT/LM_MONITOR and `-Xlog:monitorinflation=trace`. 
> 
> Could extend this test to capture this regression in the future (or creating a new test based on the same infrastructure). Will give it an attempt, so we have a regression test for this. But these tests get rather involved as the require a lot of jvmti setup.

Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:

  Improve EARelockingNestedInflated_03 for LM_LIGHTWEIGHT

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17626/files
  - new: https://git.openjdk.org/jdk/pull/17626/files/be717d5e..8ff8a248

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

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

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

From dcubed at openjdk.org  Fri Feb  2 15:21:03 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 2 Feb 2024 15:21:03 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v4]
In-Reply-To: <8mDvJP40GSADPLCqFzc_WEOi9OJT7L795K4Q1PBPZg8=.7ffd90f2-8d28-4daa-8e06-183669bf1178@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
 <v3omYG7AsGlssh7MwE1E_MJOZPyNfkd4tyIj0FWWtjA=.88c1d7ac-856d-47d4-ad40-1699613ae678@github.com>
 <Y6pFdDojApfPAMCqxr5RWKhjahJN0dnqqIOKRkLoejY=.953b5371-d937-4d63-8766-8b9d95dd3740@github.com>
 <qv-Us4BNwC3tUBqV2DY4hph0E6vvh3viI8Xlx43Ei0A=.4ede78cb-2cb6-48e1-aff0-93fcf7e0d322@github.com>
 <nqoyXYV6zzbgdHscKXlHI6doU378EaDd6Dk1d3Y70F8=.225b062d-e2e1-423e-9575-3e0c5d1d9713@github.com>
 <YIDwx2b78BJXqRw79SvpWU-_hZqacXsHCUz7RKpS6j4=.88e26782-a237-4c6f-9926-479a45482430@github.com>
 <zE4IIOmsCO2GbA1GiucCWLL5QUw8ZC-Ly0s63uvuEPs=.67613252-bdf3-42cb-9db3-ecbeaa760d5b@github.com>
 <Pd1YajFHrxpt4ZCy-cwxq7HM76xoSbDCVqRr4lNYg_M=.4d1b755c-13c3-443a-86d9-646bd11c6398@github.com>
 <8mDvJP40GSADPLCqFzc_WEOi9OJT7L795K4Q1PBPZg8=.7ffd90f2-8d28-4daa-8e06-183669bf1178@github.com>
Message-ID: <TAn-4vCM81op-ejxMCXm_UGP1ENQb6dzkA7_7Y64ELY=.5076056c-76ae-4217-8dd7-9ba506317b8a@github.com>

On Fri, 2 Feb 2024 08:00:39 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Ummm... Here's the comment line I'm talking about:
>>> I thought you would have to handle `LockingMode == LM_LEGACY && locking_thread->is_lock_owned((address)prev_owner) == true`. 
>> 
>> and the code that I referred to on L350 is exactly that line of code. Again, what am I missing?
>
> Axel added that line after my comment.

Thanks for figuring out that's what I was missing! You made the comment, Axel changed
the code well below your comment in the PR, GitHub didn't connect the comment and
the code change together to flag anything as "outdated". And most importantly, I missed
that there was a commit made in response to your comment from the history.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17626#discussion_r1476192497

From eosterlund at openjdk.org  Fri Feb  2 15:37:05 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 2 Feb 2024 15:37:05 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v6]
In-Reply-To: <hFpFmzWDdWxfypartYE2f5AwrEbxSwkFOJU6Y8UgAeA=.60a57599-de15-4e6c-8a86-1352ba2918c3@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
 <hFpFmzWDdWxfypartYE2f5AwrEbxSwkFOJU6Y8UgAeA=.60a57599-de15-4e6c-8a86-1352ba2918c3@github.com>
Message-ID: <xHS-6n1bU_W6rbYEY1t8aFUeiNKY2CsojdhTdqkeklE=.64c2ad99-394d-4e0c-862b-2f996a3e82bc@github.com>

On Fri, 2 Feb 2024 03:52:04 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Thanks for the improvements! Tests are still passing on SAP supported platforms.

Thank you for running through your tests!

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

PR Comment: https://git.openjdk.org/jdk/pull/17495#issuecomment-1924112606

From rrich at openjdk.org  Fri Feb  2 16:38:04 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Fri, 2 Feb 2024 16:38:04 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v4]
In-Reply-To: <TAn-4vCM81op-ejxMCXm_UGP1ENQb6dzkA7_7Y64ELY=.5076056c-76ae-4217-8dd7-9ba506317b8a@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
 <v3omYG7AsGlssh7MwE1E_MJOZPyNfkd4tyIj0FWWtjA=.88c1d7ac-856d-47d4-ad40-1699613ae678@github.com>
 <Y6pFdDojApfPAMCqxr5RWKhjahJN0dnqqIOKRkLoejY=.953b5371-d937-4d63-8766-8b9d95dd3740@github.com>
 <qv-Us4BNwC3tUBqV2DY4hph0E6vvh3viI8Xlx43Ei0A=.4ede78cb-2cb6-48e1-aff0-93fcf7e0d322@github.com>
 <nqoyXYV6zzbgdHscKXlHI6doU378EaDd6Dk1d3Y70F8=.225b062d-e2e1-423e-9575-3e0c5d1d9713@github.com>
 <YIDwx2b78BJXqRw79SvpWU-_hZqacXsHCUz7RKpS6j4=.88e26782-a237-4c6f-9926-479a45482430@github.com>
 <zE4IIOmsCO2GbA1GiucCWLL5QUw8ZC-Ly0s63uvuEPs=.67613252-bdf3-42cb-9db3-ecbeaa760d5b@github.com>
 <Pd1YajFHrxpt4ZCy-cwxq7HM76xoSbDCVqRr4lNYg_M=.4d1b755c-13c3-443a-86d9-646bd11c6398@github.com>
 <8mDvJP40GSADPLCqFzc_WEOi9OJT7L795K4Q1PBPZg8=.7ffd90f2-8d28-4daa-8e06-183669bf1178@github.com>
 <TAn-4vCM81op-ejxMCXm_UGP1ENQb6dzkA7_7Y64ELY=.5076056c-76ae-4217-8dd7-9ba506317b8a@github.com>
Message-ID: <QPQBmjkfXBoh0ll8CgfNJxyowGa366AgprmQN57gc1w=.bd07f647-c115-494a-aae6-17d3f5058e41@github.com>

On Fri, 2 Feb 2024 15:18:37 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Axel added that line after my comment.
>
> Thanks for figuring out that's what I was missing! You made the comment, Axel changed
> the code well below your comment in the PR, GitHub didn't connect the comment and
> the code change together to flag anything as "outdated". And most importantly, I missed
> that there was a commit made in response to your comment from the history.

I do find it difficult to follow what's going on once there are more than just a few comments and commits.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17626#discussion_r1476288059

From rrich at openjdk.org  Fri Feb  2 17:15:04 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Fri, 2 Feb 2024 17:15:04 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v8]
In-Reply-To: <zLj4iQnZnflZHsPmnWqIEHrtudnRFCTYTheh88mjnYg=.522c38c6-8e1a-4869-be04-8a7efc0d28cf@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
 <zLj4iQnZnflZHsPmnWqIEHrtudnRFCTYTheh88mjnYg=.522c38c6-8e1a-4869-be04-8a7efc0d28cf@github.com>
Message-ID: <3E33a2wSUt_OvLwlifIBux9_aiu8p1muqLqh1GktBYY=.c6d77e4d-145a-43b4-b3d3-fe6129b439e1@github.com>

On Fri, 2 Feb 2024 15:11:19 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The `ObjectSynchronizer` has always assumed that the `current` parameters are both the current thread as well as the thread that is doing the locking. The only time that we are entering on behalf of another thread is when doing re-locking in deoptimization. This has worked because the deoptee thread is suspended. However ResourceMarks have been using the wrong thread when logging is enabled.
>> 
>> This change `ObjectSynchronizer` instruments the relevant methods with both a `JavaThread* locking_thread` as well as `[Java]Thread* current` to be able to use the correct thread for ResourceMarks. 
>> 
>> Having the `inflate` care about a `locking_thread` is a little unpleasant in my opinion. But it is required for LM_LIGHTWEIGHT. 
>> Would probably be cleaner if the inflate for LM_LIGHTWEIGHT was it's own thing, as it does not share the whole INFLATING protocol. But seems like a future RFE to refactor this code.
>> 
>> Can reproduce a crash by modifying `test/jdk/com/sun/jdi/EATests.java` and using `-XX:DiagnoseSyncOnValueBasedClasses=2` with LM_LEGACY or running `test/jdk/com/sun/jdi/EATests.java` with LM_LIGHTWEIGHT/LM_MONITOR and `-Xlog:monitorinflation=trace`. 
>> 
>> Could extend this test to capture this regression in the future (or creating a new test based on the same infrastructure). Will give it an attempt, so we have a regression test for this. But these tests get rather involved as the require a lot of jvmti setup.
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve EARelockingNestedInflated_03 for LM_LIGHTWEIGHT

Besides 2 minor comments the change looks good to me.
Thanks, Richard.

src/hotspot/share/runtime/synchronizer.cpp line 528:

> 526:     }
> 527:   }
> 528: 

Empty line not needed.

src/hotspot/share/runtime/synchronizer.hpp line 98:

> 96:   static void exit(oop obj, BasicLock* lock, JavaThread* current);
> 97:   // Used to enter a monitor for another thread. This requires that the
> 98:   // that the locking_thread is suspended, and that entering on a potential

Suggestion:

  // Used to enter a monitor for another thread. This requires that the
  // locking_thread is suspended, and that entering on a potential

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

Marked as reviewed by rrich (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17626#pullrequestreview-1859751594
PR Review Comment: https://git.openjdk.org/jdk/pull/17626#discussion_r1476369352
PR Review Comment: https://git.openjdk.org/jdk/pull/17626#discussion_r1476338191

From kvn at openjdk.org  Fri Feb  2 18:30:05 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 2 Feb 2024 18:30:05 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v5]
In-Reply-To: <jcNvyPaD_RFHjENtzmKTktw3H95xYv1NcyRLQpZOaoo=.f9d8ad89-e56c-4a37-9568-67fe564523ed@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
 <8ZG3rV3o0aWMghASjxkM0qLsha99DcXD-paj7UZXn6k=.b0ffccc4-bf8b-4908-9f88-8476153ebe7c@github.com>
 <6q3ZHJtx7qg9SFnAGa36P2hzECOXcbCq83lv6evq11A=.c9aa9e23-ddc8-4b45-a565-c68136e76b05@github.com>
 <LVfnz9eaFOPWaq8n0R5_4bAwGErrWWJ1i4m9BDkfAeo=.255868e5-12b0-419b-ae43-0406ad8e15d6@github.com>
 <_q0C7Lvuh3iNoqEOn-uwqhTxkM7j8PAS4U1peSPbQ-s=.f2472ab9-b802-4286-8e59-aeb667d798be@github.com>
 <jcNvyPaD_RFHjENtzmKTktw3H95xYv1NcyRLQpZOaoo=.f9d8ad89-e56c-4a37-9568-67fe564523ed@github.com>
Message-ID: <eJaIDT78o-Sd9tUEAeCr61x3hNsLo8YhuO_zx8OoFRs=.418f6f99-cda0-4b8d-a784-aafb03cab30e@github.com>

On Fri, 2 Feb 2024 14:57:20 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Given the extra test that @reinrich provided that is exactly what occurs. A nested eliminated lock is re-locked. But the lock is already escaped and contended by another thread.
>
>> Given the extra test that @reinrich provided that is exactly what occurs. A nested eliminated lock is re-locked. But the lock is already escaped and contended by another thread.
> 
> We didn't reach there with LM_LIGHTWEIGHT. The lock got inflated during warm-up because of the recursive monitorenter in the interpreter. The owner was set to the current thread then. I've improved the test to use a new instance after warm-up. If you want you can cherry-pick here: https://github.com/reinrich/jdk/commit/c28181d585e5ceeaa34e7e6afb4311d59cf990b2

C2 can eliminate 3 types of lock/unlock:
1. Locked object does not escape compiled code (it can escape after deoptimization when we return into Interpreter). "Stupid" code example I start seeing in recent bugs:

   synchronized (new Object())

  
2. Nested locks. There is already held outer lock of the same object (or class) in compiled code.

    synchronized (obj) {
         // code
         synchronized (obj) {
               // code

3. Adjacent unlock/lock pairs if C2 determines it is safe (no control branches or safepoint which can deoptimize between them). We call it `coarsened` locks. You should not see such elimination during deoptimization because no safepoint between.

    synchronized (obj) { // code1 }
    synchronized (obj) { // code2 }

will be converted to

    synchronized (obj) {
       // code1
       // code2
    }


Whenever we eliminate lock we mark it in debug info as eliminated so that during deoptimization we can re-lock them.
It safe to do re-locking for nested locks because deoptee thread already holds lock by outer lock.
It safe to do re-locking for not-escaped object because other threads do not see it until we return into Interpreter.

At least that it what happens during normal execution without JVMTI involvement.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17626#discussion_r1476512783

From kvn at openjdk.org  Fri Feb  2 18:48:01 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 2 Feb 2024 18:48:01 GMT
Subject: RFR: 8321468: Remove StringUTF16::equals
In-Reply-To: <CySSsfGkTiz_6q09rb7VCW_rGwin9V8NN-Ugh8Wltds=.9a4652c2-4b0a-4644-8a48-f9ee6dd5abc4@github.com>
References: <CySSsfGkTiz_6q09rb7VCW_rGwin9V8NN-Ugh8Wltds=.9a4652c2-4b0a-4644-8a48-f9ee6dd5abc4@github.com>
Message-ID: <7I-SN7RC5JdW0PWegMBa6c7idd27jT6oV2I7nvgRTi4=.86acebe9-5b2d-4b8d-9ce7-abc88ef80013@github.com>

On Wed, 6 Dec 2023 14:20:14 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8215017 removed the only use of `StringUTF16::equals`. At the time I did some performance verification focused on x86 showing that simplifying and only using `StringLatin1::equals` was either neutral or a win. 
> 
> I repeated this experiment recently, adding some focused tests on aarch64 where the code generation actually tries to take advantage and generate slightly more efficient code for `StringUTF16::equals`: 
> https://github.com/openjdk/jdk/pull/16933#discussion_r1414118658
> 
> The indication here is that disabling use of `StringUTF16::equals` was the right choice: any effect from the low-level optimization (one less branch at the tail end) was offset by the `isLatin1()` branch and added code generation (that all gets inlined).
> 
> In a `-XX:-CompactStrings` configuration the slightly improved code generation in `StringUTF16::equals` might help, since the `isLatin1()` test and subsequent call to `StringLatin1::equals` would be DCEd. To get the best of both worlds the code in `String::equals` _could_ be sharpened so that we statically pick the best implementation based on `CompactStrings` mode (see comment below). This shows a tiny win when testing with `-XX:-CompactStrings` on M1 (up to -0.2ns/op per `String::equals`; neutral on x86). But is all this complexity worth it for a gain that will get lost in the noise on anything realistic?
> 
> This PR instead proposes removing `StringUTF16::equals` and simplifying the mechanisms to support the `StringLatin1/UTF16::equals` pair of intrinsics in hotspot.

I don't see x86 changes. Why?

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

Changes requested by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16995#pullrequestreview-1860078647

From never at openjdk.org  Fri Feb  2 21:19:02 2024
From: never at openjdk.org (Tom Rodriguez)
Date: Fri, 2 Feb 2024 21:19:02 GMT
Subject: RFR: 8324983: race in CompileBroker::possibly_add_compiler_threads
 [v2]
In-Reply-To: <xoMpIv8mywi3DseOrxlst3fbjJ0B4iU4dTS_o8lcLMk=.5abd5066-5f01-461a-9ed6-8bb5c9d52f0d@github.com>
References: <qd8qOUxvTRbavq4rQT5kvA5ujZFdENBsJr_Ggie9hSM=.f88cdff5-4c45-434c-ad70-7faf7981d7f4@github.com>
 <xoMpIv8mywi3DseOrxlst3fbjJ0B4iU4dTS_o8lcLMk=.5abd5066-5f01-461a-9ed6-8bb5c9d52f0d@github.com>
Message-ID: <oVOWjFwE8OipfG7eUpUmjk-2IHfjlNY__k17xXCfBdg=.2abf0ac7-8829-4606-a337-f94a50a3f9df@github.com>

On Thu, 1 Feb 2024 07:08:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Tom Rodriguez has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Convert guarantee to assert
>
> Changes requested by dholmes (Reviewer).

@dholmes-ora are you planning to approve or should I go ahead and integrate?

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

PR Comment: https://git.openjdk.org/jdk/pull/17662#issuecomment-1924707950

From dlong at openjdk.org  Fri Feb  2 21:28:07 2024
From: dlong at openjdk.org (Dean Long)
Date: Fri, 2 Feb 2024 21:28:07 GMT
Subject: RFR: 8324833: Signed integer overflows in ABS [v2]
In-Reply-To: <1c16YOU0xxYgPbXiw6kqIDK8GGVD8S3lUOctnQ9zw5o=.29353a1d-cdc8-4732-874d-b0da2ffd07b3@github.com>
References: <ohwAn6GqM7FIgYTJNy40VBYSCVEBrrNSqBaz2akN54M=.f9660235-3047-47ee-aad0-ef598d6ebdcc@github.com>
 <keBLe_kqh25x7IdMWimvIQshpubvKZrP0KPf4Lphoy4=.447c2d2e-3c08-4d85-a9c3-3bd356cfc8a4@github.com>
 <1c16YOU0xxYgPbXiw6kqIDK8GGVD8S3lUOctnQ9zw5o=.29353a1d-cdc8-4732-874d-b0da2ffd07b3@github.com>
Message-ID: <3vK0unjL-Lab0MjO56pPZmKeW1EzhjNWoaxWkRs7bzY=.588a0d59-aec9-4e80-ae76-fe701a8a063b@github.com>

On Fri, 2 Feb 2024 06:20:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Yes, I think we care. I would try a build with `Wsigned-conversion` and look where we should sprinkle more `checked_cast`-s.

Let me try your latest with -Wsigned-conversion turned on.  If I remember correctly, checked_cast doesn't always work right when the "signed-ness" changes (signed --> unsigned or unsigned --> signed).

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

PR Comment: https://git.openjdk.org/jdk/pull/17617#issuecomment-1924721635

From redestad at openjdk.org  Fri Feb  2 22:02:11 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 2 Feb 2024 22:02:11 GMT
Subject: RFR: 8321468: Remove StringUTF16::equals
In-Reply-To: <7I-SN7RC5JdW0PWegMBa6c7idd27jT6oV2I7nvgRTi4=.86acebe9-5b2d-4b8d-9ce7-abc88ef80013@github.com>
References: <CySSsfGkTiz_6q09rb7VCW_rGwin9V8NN-Ugh8Wltds=.9a4652c2-4b0a-4644-8a48-f9ee6dd5abc4@github.com>
 <7I-SN7RC5JdW0PWegMBa6c7idd27jT6oV2I7nvgRTi4=.86acebe9-5b2d-4b8d-9ce7-abc88ef80013@github.com>
Message-ID: <Z9_Wk0oe_864oNWV68WRM4s3p2KVW67lE7_LI5RqaOw=.136abe32-c977-4b42-94df-db99a5c44a1b@github.com>

On Fri, 2 Feb 2024 18:45:22 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> I don't see x86 changes. Why?

The 2-byte variants for `string_equals`, if they ever existed, seems to be gone:

// fast string equals
instruct string_equals(rdi_RegP str1, rsi_RegP str2, rcx_RegI cnt, rax_RegI result,
                       legRegD tmp1, legRegD tmp2, rbx_RegI tmp3, rFlagsReg cr)
%{
  predicate(!VM_Version::supports_avx512vlbw());
  match(Set result (StrEquals (Binary str1 str2) cnt));
  effect(TEMP tmp1, TEMP tmp2, USE_KILL str1, USE_KILL str2, USE_KILL cnt, KILL tmp3, KILL cr);

  format %{ "String Equals $str1,$str2,$cnt -> $result    // KILL $tmp1, $tmp2, $tmp3" %}
  ins_encode %{
    __ arrays_equals(false, $str1$$Register, $str2$$Register,
                     $cnt$$Register, $result$$Register, $tmp3$$Register,
                     $tmp1$$XMMRegister, $tmp2$$XMMRegister, false /* char */, knoreg);
  %}
  ins_pipe( pipe_slow );
%}


So AFAICT there is nothing to change on x86.

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

PR Comment: https://git.openjdk.org/jdk/pull/16995#issuecomment-1924766391

From kvn at openjdk.org  Fri Feb  2 22:52:02 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 2 Feb 2024 22:52:02 GMT
Subject: RFR: 8321468: Remove StringUTF16::equals
In-Reply-To: <CySSsfGkTiz_6q09rb7VCW_rGwin9V8NN-Ugh8Wltds=.9a4652c2-4b0a-4644-8a48-f9ee6dd5abc4@github.com>
References: <CySSsfGkTiz_6q09rb7VCW_rGwin9V8NN-Ugh8Wltds=.9a4652c2-4b0a-4644-8a48-f9ee6dd5abc4@github.com>
Message-ID: <3Kl1Lnl7taMhJBnhxwEutDn9ed0FUh_ERnj-bK_J904=.8ddf9d82-625a-4056-a8be-20922afc47b0@github.com>

On Wed, 6 Dec 2023 14:20:14 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8215017 removed the only use of `StringUTF16::equals`. At the time I did some performance verification focused on x86 showing that simplifying and only using `StringLatin1::equals` was either neutral or a win. 
> 
> I repeated this experiment recently, adding some focused tests on aarch64 where the code generation actually tries to take advantage and generate slightly more efficient code for `StringUTF16::equals`: 
> https://github.com/openjdk/jdk/pull/16933#discussion_r1414118658
> 
> The indication here is that disabling use of `StringUTF16::equals` was the right choice: any effect from the low-level optimization (one less branch at the tail end) was offset by the `isLatin1()` branch and added code generation (that all gets inlined).
> 
> In a `-XX:-CompactStrings` configuration the slightly improved code generation in `StringUTF16::equals` might help, since the `isLatin1()` test and subsequent call to `StringLatin1::equals` would be DCEd. To get the best of both worlds the code in `String::equals` _could_ be sharpened so that we statically pick the best implementation based on `CompactStrings` mode (see comment below). This shows a tiny win when testing with `-XX:-CompactStrings` on M1 (up to -0.2ns/op per `String::equals`; neutral on x86). But is all this complexity worth it for a gain that will get lost in the noise on anything realistic?
> 
> This PR instead proposes removing `StringUTF16::equals` and simplifying the mechanisms to support the `StringLatin1/UTF16::equals` pair of intrinsics in hotspot.

You are right. I mistook `string_compareU*`  instructions for it.
Can you check history why we don't have it in x86*.ad?

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

PR Comment: https://git.openjdk.org/jdk/pull/16995#issuecomment-1924855153

From dlong at openjdk.org  Fri Feb  2 23:50:02 2024
From: dlong at openjdk.org (Dean Long)
Date: Fri, 2 Feb 2024 23:50:02 GMT
Subject: RFR: 8324833: Signed integer overflows in ABS [v3]
In-Reply-To: <6kxKhJVXB2X7ni4SLMtL--Pt5O8bUOazcI9F3FJgG8o=.55b0e9bd-075c-4b76-bcc6-732951e8a512@github.com>
References: <ohwAn6GqM7FIgYTJNy40VBYSCVEBrrNSqBaz2akN54M=.f9660235-3047-47ee-aad0-ef598d6ebdcc@github.com>
 <6kxKhJVXB2X7ni4SLMtL--Pt5O8bUOazcI9F3FJgG8o=.55b0e9bd-075c-4b76-bcc6-732951e8a512@github.com>
Message-ID: <kx1I4koOmVIM9rAHoX2WpQv4jVCh3qgKgMkmL3ve9Ns=.6b0a46f8-3b87-4d2e-9125-2e262a09dbfc@github.com>

On Fri, 2 Feb 2024 09:47:28 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the details in the bug. I think current `ABS` implementation is beyond repair, and we should just switch to `uabs`.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug, `all` with `-ftrapv` (now fully passes!)
>>  - [x] Linux x86_64 fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Touchups

src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 1062:

> 1060:   if (target_addr != 0x0) {
> 1061:     jlong off_low = (jlong)target_addr - ((jlong)CodeCache::low_bound() + sizeof(int));
> 1062:     jlong off_high = (jlong)target_addr - ((jlong)CodeCache::high_bound() + sizeof(int));

Suggestion:

    jlong off_low = (jlong)(target_addr - (CodeCache::low_bound() + sizeof(int)));
    jlong off_high = (jlong)(target_addr - (CodeCache::high_bound() + sizeof(int)));

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17617#discussion_r1476877531

From dlong at openjdk.org  Sat Feb  3 00:07:03 2024
From: dlong at openjdk.org (Dean Long)
Date: Sat, 3 Feb 2024 00:07:03 GMT
Subject: RFR: 8324833: Signed integer overflows in ABS [v3]
In-Reply-To: <6kxKhJVXB2X7ni4SLMtL--Pt5O8bUOazcI9F3FJgG8o=.55b0e9bd-075c-4b76-bcc6-732951e8a512@github.com>
References: <ohwAn6GqM7FIgYTJNy40VBYSCVEBrrNSqBaz2akN54M=.f9660235-3047-47ee-aad0-ef598d6ebdcc@github.com>
 <6kxKhJVXB2X7ni4SLMtL--Pt5O8bUOazcI9F3FJgG8o=.55b0e9bd-075c-4b76-bcc6-732951e8a512@github.com>
Message-ID: <jhK6TNMKlimTl4hIhwzV_6vZDUYSSwk2J0XuPqCIxs0=.4f4bd7aa-4cc0-49c0-ad06-56ab3e166127@github.com>

On Fri, 2 Feb 2024 09:47:28 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the details in the bug. I think current `ABS` implementation is beyond repair, and we should just switch to `uabs`.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug, `all` with `-ftrapv` (now fully passes!)
>>  - [x] Linux x86_64 fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Touchups

I think it's confusing and error-prone to use uabs() for signed values.  Using `checked_cast` silences warnings but doesn't handle the undefined behavior caused by values such as min_jint and min_jlong.  I suggest fixing ABS so that it first calls uabs and then safely converts to signed, checking for negative values caused by MIN INT inputs.  However, that will cause some new asserts where we are relying on undefine behavior, like in exact_limit() described in JBS, so it seems like that caller needs to be fixed.
Fixing all the -Wsigned-conversion warnings in these files, or even in the changed functions, seems out of scope for this fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/17617#issuecomment-1924922608

From redestad at openjdk.org  Sat Feb  3 00:09:01 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sat, 3 Feb 2024 00:09:01 GMT
Subject: RFR: 8321468: Remove StringUTF16::equals
In-Reply-To: <CySSsfGkTiz_6q09rb7VCW_rGwin9V8NN-Ugh8Wltds=.9a4652c2-4b0a-4644-8a48-f9ee6dd5abc4@github.com>
References: <CySSsfGkTiz_6q09rb7VCW_rGwin9V8NN-Ugh8Wltds=.9a4652c2-4b0a-4644-8a48-f9ee6dd5abc4@github.com>
Message-ID: <QimiT7RdYW85mEc6bpJTRr4dQACHoKhukFh7WOXtorU=.0a051098-292f-4e12-b321-fc4a9a108308@github.com>

On Wed, 6 Dec 2023 14:20:14 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8215017 removed the only use of `StringUTF16::equals`. At the time I did some performance verification focused on x86 showing that simplifying and only using `StringLatin1::equals` was either neutral or a win. 
> 
> I repeated this experiment recently, adding some focused tests on aarch64 where the code generation actually tries to take advantage and generate slightly more efficient code for `StringUTF16::equals`: 
> https://github.com/openjdk/jdk/pull/16933#discussion_r1414118658
> 
> The indication here is that disabling use of `StringUTF16::equals` was the right choice: any effect from the low-level optimization (one less branch at the tail end) was offset by the `isLatin1()` branch and added code generation (that all gets inlined).
> 
> In a `-XX:-CompactStrings` configuration the slightly improved code generation in `StringUTF16::equals` might help, since the `isLatin1()` test and subsequent call to `StringLatin1::equals` would be DCEd. To get the best of both worlds the code in `String::equals` _could_ be sharpened so that we statically pick the best implementation based on `CompactStrings` mode (see comment below). This shows a tiny win when testing with `-XX:-CompactStrings` on M1 (up to -0.2ns/op per `String::equals`; neutral on x86). But is all this complexity worth it for a gain that will get lost in the noise on anything realistic?
> 
> This PR instead proposes removing `StringUTF16::equals` and simplifying the mechanisms to support the `StringLatin1/UTF16::equals` pair of intrinsics in hotspot.

The x86 `string_equals` instruction pre-dates and was updated for the Compact Strings JEP. No specialized 2-byte variants: https://github.com/openjdk/jdk/commit/7af927f9c10923b61f746eb6e566bcda853dd95a#diff-89791d4b051172965f7ba8f0cb7afbeb7e141f6de924dc07167c5ceefdce6bbe 

A bit strange since distinct 1-byte `array_equalsB` and 2-byte `array_equalsC` were introduced at this time, sharing code. So either an unintended omission, or the benefit of having both variants didn't manifest in benchmarks.

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

PR Comment: https://git.openjdk.org/jdk/pull/16995#issuecomment-1924924403

From amenkov at openjdk.org  Sat Feb  3 00:14:15 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Sat, 3 Feb 2024 00:14:15 GMT
Subject: RFR: JDK-8318566: Heap walking functions should not use
 FilteredFieldStream [v4]
In-Reply-To: <OAXy0kdJSDJ3b4TPhYjHBHbemHVhd40WzY-1j32rSP8=.f9c73209-0667-4f3e-9f38-e4a20c271c29@github.com>
References: <OAXy0kdJSDJ3b4TPhYjHBHbemHVhd40WzY-1j32rSP8=.f9c73209-0667-4f3e-9f38-e4a20c271c29@github.com>
Message-ID: <7px5fMfSU7Yeb-vJqp-20PUkX3Dh9Tr1PjeLlUcbq1g=.55b3d029-1be7-49ce-9d41-44ff2113b9b1@github.com>

> FilteredFieldStream used by heap walking functions to iterate through klass/superclasses/interfaces fields are known to have poor performance (see [JDK-8317692](https://bugs.openjdk.org/browse/JDK-8317692) for details).
> Heap walking API implementation is the last user of the klasses.
> The fix reworks iteration through klass/superclasses/interfaces fields and drops FilteredFieldStream-related code.
> Additionally removed/updated includes of reflectionUtils.hpp.
> 
> Testing:
>   - tier1..4;
>   - test/hotspot/jtreg/vmTestbase/nsk/jvmti (contains tests for different heap walking functions);
>   - new test from #17580 (now the test runs several times faster).

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  updated comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17661/files
  - new: https://git.openjdk.org/jdk/pull/17661/files/d6ab43b4..1152e718

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

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

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

From amenkov at openjdk.org  Sat Feb  3 00:14:15 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Sat, 3 Feb 2024 00:14:15 GMT
Subject: RFR: JDK-8318566: Heap walking functions should not use
 FilteredFieldStream [v3]
In-Reply-To: <bGUrfOmFxmdr9ELXZlMsSDLtufJwiaeDkj53F8cbfX4=.cec6abd8-6a05-416b-95c5-fdac912ea45c@github.com>
References: <OAXy0kdJSDJ3b4TPhYjHBHbemHVhd40WzY-1j32rSP8=.f9c73209-0667-4f3e-9f38-e4a20c271c29@github.com>
 <qWNgrR_H8lG6DxhpC04CQYO-4rY5mp0ljH4RnPgs3mU=.b2d49368-a7d0-4e0d-9ea3-b9711785aff6@github.com>
 <bGUrfOmFxmdr9ELXZlMsSDLtufJwiaeDkj53F8cbfX4=.cec6abd8-6a05-416b-95c5-fdac912ea45c@github.com>
Message-ID: <GKNA8vryCRTMjK8_j_3oy6OSZgeCRKf1mddsGrx-Wj8=.71ce42c7-95f0-465f-a7d7-5271b8ea21d1@github.com>

On Fri, 2 Feb 2024 08:05:06 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   jcheck
>
> src/hotspot/share/prims/jvmtiTagMap.cpp line 499:
> 
>> 497:     }
>> 498:     // update total_field_number for superclass
>> 499:     total_field_number = start_index;
> 
> Nit: The local variable name `total_field_number` is a little bit confusing because it is instantly decreased here (see also the line 490). I'm not sure what name to suggest though. Maybe the comment at line 498 needs an update to say this number is decreased here.

done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17661#discussion_r1476887153

From dlong at openjdk.org  Sat Feb  3 00:15:06 2024
From: dlong at openjdk.org (Dean Long)
Date: Sat, 3 Feb 2024 00:15:06 GMT
Subject: RFR: 8324833: Signed integer overflows in ABS [v3]
In-Reply-To: <6kxKhJVXB2X7ni4SLMtL--Pt5O8bUOazcI9F3FJgG8o=.55b0e9bd-075c-4b76-bcc6-732951e8a512@github.com>
References: <ohwAn6GqM7FIgYTJNy40VBYSCVEBrrNSqBaz2akN54M=.f9660235-3047-47ee-aad0-ef598d6ebdcc@github.com>
 <6kxKhJVXB2X7ni4SLMtL--Pt5O8bUOazcI9F3FJgG8o=.55b0e9bd-075c-4b76-bcc6-732951e8a512@github.com>
Message-ID: <7UlchnWsTfzG5J9VsPJM-ipnl5lYvdzrMhY0DFFWUws=.8a13b2bb-fcc7-43ad-a866-70d7d0a67232@github.com>

On Fri, 2 Feb 2024 09:47:28 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the details in the bug. I think current `ABS` implementation is beyond repair, and we should just switch to `uabs`.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug, `all` with `-ftrapv` (now fully passes!)
>>  - [x] Linux x86_64 fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Touchups

Another alternative, leave ABS as is, but have it check for invalid inputs, and again fix the callers that are passing values like MIN_VALUE.

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

PR Comment: https://git.openjdk.org/jdk/pull/17617#issuecomment-1924928081

From sspitsyn at openjdk.org  Sat Feb  3 00:40:03 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 3 Feb 2024 00:40:03 GMT
Subject: RFR: JDK-8318566: Heap walking functions should not use
 FilteredFieldStream [v4]
In-Reply-To: <7px5fMfSU7Yeb-vJqp-20PUkX3Dh9Tr1PjeLlUcbq1g=.55b3d029-1be7-49ce-9d41-44ff2113b9b1@github.com>
References: <OAXy0kdJSDJ3b4TPhYjHBHbemHVhd40WzY-1j32rSP8=.f9c73209-0667-4f3e-9f38-e4a20c271c29@github.com>
 <7px5fMfSU7Yeb-vJqp-20PUkX3Dh9Tr1PjeLlUcbq1g=.55b3d029-1be7-49ce-9d41-44ff2113b9b1@github.com>
Message-ID: <Jx3cr2TXmzB8aHuOSYxmg7eWwKpTzfsQiVN_jZeDKYw=.65308155-9f07-48dc-a1a7-d25c6d463932@github.com>

On Sat, 3 Feb 2024 00:14:15 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> FilteredFieldStream used by heap walking functions to iterate through klass/superclasses/interfaces fields are known to have poor performance (see [JDK-8317692](https://bugs.openjdk.org/browse/JDK-8317692) for details).
>> Heap walking API implementation is the last user of the klasses.
>> The fix reworks iteration through klass/superclasses/interfaces fields and drops FilteredFieldStream-related code.
>> Additionally removed/updated includes of reflectionUtils.hpp.
>> 
>> Testing:
>>   - tier1..4;
>>   - test/hotspot/jtreg/vmTestbase/nsk/jvmti (contains tests for different heap walking functions);
>>   - new test from #17580 (now the test runs several times faster).
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated comment

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17661#pullrequestreview-1860685491

From kvn at openjdk.org  Sat Feb  3 00:41:06 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sat, 3 Feb 2024 00:41:06 GMT
Subject: RFR: 8321468: Remove StringUTF16::equals
In-Reply-To: <CySSsfGkTiz_6q09rb7VCW_rGwin9V8NN-Ugh8Wltds=.9a4652c2-4b0a-4644-8a48-f9ee6dd5abc4@github.com>
References: <CySSsfGkTiz_6q09rb7VCW_rGwin9V8NN-Ugh8Wltds=.9a4652c2-4b0a-4644-8a48-f9ee6dd5abc4@github.com>
Message-ID: <ByvelQotv6iGInDsAiTv-0oc3ZonT4l9McVv4Q-31B0=.a9980f90-7e11-481e-8895-2a7b3c11936c@github.com>

On Wed, 6 Dec 2023 14:20:14 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8215017 removed the only use of `StringUTF16::equals`. At the time I did some performance verification focused on x86 showing that simplifying and only using `StringLatin1::equals` was either neutral or a win. 
> 
> I repeated this experiment recently, adding some focused tests on aarch64 where the code generation actually tries to take advantage and generate slightly more efficient code for `StringUTF16::equals`: 
> https://github.com/openjdk/jdk/pull/16933#discussion_r1414118658
> 
> The indication here is that disabling use of `StringUTF16::equals` was the right choice: any effect from the low-level optimization (one less branch at the tail end) was offset by the `isLatin1()` branch and added code generation (that all gets inlined).
> 
> In a `-XX:-CompactStrings` configuration the slightly improved code generation in `StringUTF16::equals` might help, since the `isLatin1()` test and subsequent call to `StringLatin1::equals` would be DCEd. To get the best of both worlds the code in `String::equals` _could_ be sharpened so that we statically pick the best implementation based on `CompactStrings` mode (see comment below). This shows a tiny win when testing with `-XX:-CompactStrings` on M1 (up to -0.2ns/op per `String::equals`; neutral on x86). But is all this complexity worth it for a gain that will get lost in the noise on anything realistic?
> 
> This PR instead proposes removing `StringUTF16::equals` and simplifying the mechanisms to support the `StringLatin1/UTF16::equals` pair of intrinsics in hotspot.

Good.

Thank you for checking.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16995#pullrequestreview-1860686125
PR Comment: https://git.openjdk.org/jdk/pull/16995#issuecomment-1924943916

From aph at openjdk.org  Sat Feb  3 18:43:01 2024
From: aph at openjdk.org (Andrew Haley)
Date: Sat, 3 Feb 2024 18:43:01 GMT
Subject: RFR: 8324833: Signed integer overflows in ABS [v2]
In-Reply-To: <3vK0unjL-Lab0MjO56pPZmKeW1EzhjNWoaxWkRs7bzY=.588a0d59-aec9-4e80-ae76-fe701a8a063b@github.com>
References: <ohwAn6GqM7FIgYTJNy40VBYSCVEBrrNSqBaz2akN54M=.f9660235-3047-47ee-aad0-ef598d6ebdcc@github.com>
 <keBLe_kqh25x7IdMWimvIQshpubvKZrP0KPf4Lphoy4=.447c2d2e-3c08-4d85-a9c3-3bd356cfc8a4@github.com>
 <1c16YOU0xxYgPbXiw6kqIDK8GGVD8S3lUOctnQ9zw5o=.29353a1d-cdc8-4732-874d-b0da2ffd07b3@github.com>
 <3vK0unjL-Lab0MjO56pPZmKeW1EzhjNWoaxWkRs7bzY=.588a0d59-aec9-4e80-ae76-fe701a8a063b@github.com>
Message-ID: <GsplpB1E9YJK0VMCwKApVqgGHpe9xX1wbQC_ta7j0Z0=.3eb25cf8-d25e-4257-8900-d2b57608a00f@github.com>

On Fri, 2 Feb 2024 21:25:08 GMT, Dean Long <dlong at openjdk.org> wrote:

> > Yes, I think we care. I would try a build with `Wsigned-conversion` and look where we should sprinkle more `checked_cast`-s.
> 
> Let me try your latest with -Wsigned-conversion turned on. If I remember correctly, checked_cast doesn't always work right when the "signed-ness" changes (signed --> unsigned or unsigned --> signed).

It should work. The checked_cast from signed --> unsigned can never overflow and is always well-defined, but the overflow behaviour in the other direction is implementation defined. Having said that, it's defined the same way on every compiler we use AFAIK

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

PR Comment: https://git.openjdk.org/jdk/pull/17617#issuecomment-1925425205

From aph at openjdk.org  Sat Feb  3 19:17:02 2024
From: aph at openjdk.org (Andrew Haley)
Date: Sat, 3 Feb 2024 19:17:02 GMT
Subject: RFR: 8324833: Signed integer overflows in ABS [v3]
In-Reply-To: <jhK6TNMKlimTl4hIhwzV_6vZDUYSSwk2J0XuPqCIxs0=.4f4bd7aa-4cc0-49c0-ad06-56ab3e166127@github.com>
References: <ohwAn6GqM7FIgYTJNy40VBYSCVEBrrNSqBaz2akN54M=.f9660235-3047-47ee-aad0-ef598d6ebdcc@github.com>
 <6kxKhJVXB2X7ni4SLMtL--Pt5O8bUOazcI9F3FJgG8o=.55b0e9bd-075c-4b76-bcc6-732951e8a512@github.com>
 <jhK6TNMKlimTl4hIhwzV_6vZDUYSSwk2J0XuPqCIxs0=.4f4bd7aa-4cc0-49c0-ad06-56ab3e166127@github.com>
Message-ID: <5kgtFYu0BR73lbSSncYgXJMsqorb8iXf8AMgbkoyR3Y=.5b05afe8-3517-4708-90fa-2207823ff0f1@github.com>

On Sat, 3 Feb 2024 00:04:27 GMT, Dean Long <dlong at openjdk.org> wrote:

> I think it's confusing and error-prone to use uabs() for signed values. Using `checked_cast` silences warnings but doesn't handle the undefined behavior caused by values such as min_jint and min_jlong.

uabs itself has no UB. I don't think checked_cast has either: at worst it's implementation defined.

> I suggest fixing ABS so that it first calls uabs and then safely converts to signed, checking for negative values caused by MIN INT inputs.

That's a good idea too, but it doesn't solve the problems uabs was designed to solve.

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

PR Comment: https://git.openjdk.org/jdk/pull/17617#issuecomment-1925433009

From mli at openjdk.org  Sun Feb  4 09:57:15 2024
From: mli at openjdk.org (Hamlin Li)
Date: Sun, 4 Feb 2024 09:57:15 GMT
Subject: RFR: 8320646: RISC-V: C2 VectorCastHF2F
Message-ID: <kqLQR-bD3v7iF7LgH0PzwIH_m6QH_2b371pKz9_Ovq8=.9c07c165-2a97-4a6b-9e82-6a6de0b81328@github.com>

Hi,
Can you review this patch to add instrinsics for VectorCastHF2F/VectorCastF2HF?
Thanks!

## Test

test/jdk/java/lang/Float/Binary16ConversionNaN.java
test/jdk/java/lang/Float/Binary16Conversion.java

hotspot/jtreg/compiler/intrinsics/float16
hotspot/jtreg/compiler/vectorization/TestFloatConversionsVectorjava
hotspot/jtreg/compiler/vectorization/TestFloatConversionsVectorNaN.java

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

Commit messages:
 - fix jcheck error
 - clean code
 - Merge branch 'master' into float16-to-float-v
 - Refine tests
 - Initial commit: VectorCastF2HF
 - fix issues
 - fix widening vector register to even one
 - merge master
 - fix stub size
 - merge master
 - ... and 1 more: https://git.openjdk.org/jdk/compare/a18b03b8...521c2221

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

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

From duke at openjdk.org  Sun Feb  4 13:49:04 2024
From: duke at openjdk.org (duke)
Date: Sun, 4 Feb 2024 13:49:04 GMT
Subject: Withdrawn: 8321640: Move the method barrier_stubs_init from
 BarrierSetAssembler to BarrierSet
In-Reply-To: <UxbBX0dqZMa-vmXUnsxFixPwn2vLcClmlfPvZ7DqK38=.259ff8ea-a919-435d-82b1-0e1ee57f08cc@github.com>
References: <UxbBX0dqZMa-vmXUnsxFixPwn2vLcClmlfPvZ7DqK38=.259ff8ea-a919-435d-82b1-0e1ee57f08cc@github.com>
Message-ID: <3w451rVOtSWN9--pYsyJ8czcqAcl9-YsKTDDyOBuiUc=.0bb01e80-3b5e-4014-a518-e581827ade43@github.com>

On Sun, 10 Dec 2023 05:23:00 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
>  This patch moves the method `barrier_stubs_init` from `BarrierSetAssembler` to `BarrierSet`.
> The `BarrierSetAssembler` is an assember which is like `MacroAssembler`, but the method 
> `barrier_stubs_init` generates and stores the stubs which is like `StubGenerator`.
> So it is not good to place it in `BarrierSetAssembler`.
> 
> Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoixong

This pull request has been closed without being integrated.

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

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

From aturbanov at openjdk.org  Sun Feb  4 17:25:05 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sun, 4 Feb 2024 17:25:05 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v8]
In-Reply-To: <zLj4iQnZnflZHsPmnWqIEHrtudnRFCTYTheh88mjnYg=.522c38c6-8e1a-4869-be04-8a7efc0d28cf@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
 <zLj4iQnZnflZHsPmnWqIEHrtudnRFCTYTheh88mjnYg=.522c38c6-8e1a-4869-be04-8a7efc0d28cf@github.com>
Message-ID: <zO0sJe_M3bvBtV2zsck4D97v9GxuviLNbuDZrkkRE4c=.ad8cf4e6-57a7-408f-a975-d4fc0ba88556@github.com>

On Fri, 2 Feb 2024 15:11:19 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The `ObjectSynchronizer` has always assumed that the `current` parameters are both the current thread as well as the thread that is doing the locking. The only time that we are entering on behalf of another thread is when doing re-locking in deoptimization. This has worked because the deoptee thread is suspended. However ResourceMarks have been using the wrong thread when logging is enabled.
>> 
>> This change `ObjectSynchronizer` instruments the relevant methods with both a `JavaThread* locking_thread` as well as `[Java]Thread* current` to be able to use the correct thread for ResourceMarks. 
>> 
>> Having the `inflate` care about a `locking_thread` is a little unpleasant in my opinion. But it is required for LM_LIGHTWEIGHT. 
>> Would probably be cleaner if the inflate for LM_LIGHTWEIGHT was it's own thing, as it does not share the whole INFLATING protocol. But seems like a future RFE to refactor this code.
>> 
>> Can reproduce a crash by modifying `test/jdk/com/sun/jdi/EATests.java` and using `-XX:DiagnoseSyncOnValueBasedClasses=2` with LM_LEGACY or running `test/jdk/com/sun/jdi/EATests.java` with LM_LIGHTWEIGHT/LM_MONITOR and `-Xlog:monitorinflation=trace`. 
>> 
>> Could extend this test to capture this regression in the future (or creating a new test based on the same infrastructure). Will give it an attempt, so we have a regression test for this. But these tests get rather involved as the require a lot of jvmti setup.
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve EARelockingNestedInflated_03 for LM_LIGHTWEIGHT

test/jdk/com/sun/jdi/EATests.java line 2007:

> 2005:         // Start thread that tries to enter lockInflatedByContention while the main thread owns it -> inflation
> 2006:         DebuggeeWrapper.newThread(() -> {
> 2007:             while(true) {

Suggestion:

            while (true) {

test/jdk/com/sun/jdi/EATests.java line 2008:

> 2006:         DebuggeeWrapper.newThread(() -> {
> 2007:             while(true) {
> 2008:                 synchronized(testCase) {

Suggestion:

                synchronized (testCase) {

test/jdk/com/sun/jdi/EATests.java line 2045:

> 2043:             return;
> 2044:         }
> 2045:         synchronized(testCase) {

Suggestion:

        synchronized (testCase) {

test/jdk/com/sun/jdi/EATests.java line 2049:

> 2047:             testCase.notify();
> 2048:             // wait for other thread to reset doLockNow again
> 2049:             while(doLockNow) {

Suggestion:

            while (doLockNow) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17626#discussion_r1477398146
PR Review Comment: https://git.openjdk.org/jdk/pull/17626#discussion_r1477398137
PR Review Comment: https://git.openjdk.org/jdk/pull/17626#discussion_r1477398165
PR Review Comment: https://git.openjdk.org/jdk/pull/17626#discussion_r1477398172

From eastigeevich at openjdk.org  Sun Feb  4 20:24:14 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Sun, 4 Feb 2024 20:24:14 GMT
Subject: RFR: 8324874: AArch64: crypto pmull based CRC32/CRC32C intrinsics
 clobber V8-V15 registers
Message-ID: <I4SlF2m1-uY5cH3AsdBhVqbTJ1m7GXfThpCgfx_6N5k=.b7a84fc0-198c-4bf0-a26b-bbe3c3ed2558@github.com>

[JDK-8302113](https://bugs.openjdk.org/browse/JDK-8302113) and [JDK-8302783](https://bugs.openjdk.org/browse/JDK-8302783) enhanced CRC32/CRC32C intrinsics with crypto pmull which is enabled for Neoverse V1 and V2. The intrinsics use `kernel_crc32_common_fold_using_crypto_pmull` which uses v8-v15 registers and potentially clobbers them if they are not saved before CRC32/CRC32C intrinsics are called.

According to the latest ?ABI for the Arm 64-bit Architecture with SVE support?: https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst


Registers v8-v15 must be preserved by a callee across subroutine calls;
the remaining registers (v0-v7, v16-v31) do not need to be preserved
(or should be preserved by the caller).


This PR reallocates registers to avoid v8-v15 registers:
- v0-v7 are used for data.
- v16-v32 are tmp registers.

Regression tests are added.
Tested a fastdebug build on Graviton 3:
- `gtest`: Passed
- `tier1..tier3`: Passed

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

Commit messages:
 - 8324874: AArch64: crypto pmull based CRC32/CRC32C intrinsics clobber V8-V15 registers

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

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

From eastigeevich at openjdk.org  Sun Feb  4 20:30:26 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Sun, 4 Feb 2024 20:30:26 GMT
Subject: RFR: 8324874: AArch64: crypto pmull based CRC32/CRC32C intrinsics
 clobber V8-V15 registers [v2]
In-Reply-To: <I4SlF2m1-uY5cH3AsdBhVqbTJ1m7GXfThpCgfx_6N5k=.b7a84fc0-198c-4bf0-a26b-bbe3c3ed2558@github.com>
References: <I4SlF2m1-uY5cH3AsdBhVqbTJ1m7GXfThpCgfx_6N5k=.b7a84fc0-198c-4bf0-a26b-bbe3c3ed2558@github.com>
Message-ID: <T_qG0AQ3r_AxzbtUm1HZTDQ-tjokSs1wcHiz4V2WGl4=.987ff437-ff99-49b0-8707-d7b46fca2caa@github.com>

> [JDK-8302113](https://bugs.openjdk.org/browse/JDK-8302113) and [JDK-8302783](https://bugs.openjdk.org/browse/JDK-8302783) enhanced CRC32/CRC32C intrinsics with crypto pmull which is enabled for Neoverse V1 and V2. The intrinsics use `kernel_crc32_common_fold_using_crypto_pmull` which uses v8-v15 registers and potentially clobbers them if they are not saved before CRC32/CRC32C intrinsics are called.
> 
> According to the latest ?ABI for the Arm 64-bit Architecture with SVE support?: https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst
> 
> 
> Registers v8-v15 must be preserved by a callee across subroutine calls;
> the remaining registers (v0-v7, v16-v31) do not need to be preserved
> (or should be preserved by the caller).
> 
> 
> This PR reallocates registers to avoid v8-v15 registers:
> - v0-v7 are used for data.
> - v16-v32 are tmp registers.
> 
> Regression tests are added.
> Tested a fastdebug build on Graviton 3:
> - `gtest`: Passed
> - `tier1..tier3`: Passed

Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:

  Fix code comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17701/files
  - new: https://git.openjdk.org/jdk/pull/17701/files/048c0fdf..c24906b9

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

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

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

From eastigeevich at openjdk.org  Sun Feb  4 20:37:00 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Sun, 4 Feb 2024 20:37:00 GMT
Subject: RFR: 8324874: AArch64: crypto pmull based CRC32/CRC32C intrinsics
 clobber V8-V15 registers [v2]
In-Reply-To: <T_qG0AQ3r_AxzbtUm1HZTDQ-tjokSs1wcHiz4V2WGl4=.987ff437-ff99-49b0-8707-d7b46fca2caa@github.com>
References: <I4SlF2m1-uY5cH3AsdBhVqbTJ1m7GXfThpCgfx_6N5k=.b7a84fc0-198c-4bf0-a26b-bbe3c3ed2558@github.com>
 <T_qG0AQ3r_AxzbtUm1HZTDQ-tjokSs1wcHiz4V2WGl4=.987ff437-ff99-49b0-8707-d7b46fca2caa@github.com>
Message-ID: <brWKA7DtK1MS7y7Hs42TkVmMtJvuVs_hXKAAsBlPmOk=.e1a03cee-2420-449d-9a0d-99a5d2adc598@github.com>

On Sun, 4 Feb 2024 20:30:26 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> [JDK-8302113](https://bugs.openjdk.org/browse/JDK-8302113) and [JDK-8302783](https://bugs.openjdk.org/browse/JDK-8302783) enhanced CRC32/CRC32C intrinsics with crypto pmull which is enabled for Neoverse V1 and V2. The intrinsics use `kernel_crc32_common_fold_using_crypto_pmull` which uses v8-v15 registers and potentially clobbers them if they are not saved before CRC32/CRC32C intrinsics are called.
>> 
>> According to the latest ?ABI for the Arm 64-bit Architecture with SVE support?: https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst
>> 
>> 
>> Registers v8-v15 must be preserved by a callee across subroutine calls;
>> the remaining registers (v0-v7, v16-v31) do not need to be preserved
>> (or should be preserved by the caller).
>> 
>> 
>> This PR reallocates registers to avoid v8-v15 registers:
>> - v0-v7 are used for data.
>> - v16-v32 are tmp registers.
>> 
>> Regression tests are added.
>> Tested a fastdebug build on Graviton 3:
>> - `gtest`: Passed
>> - `tier1..tier3`: Passed
>
> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix code comments

@theRealAph @nick-arm  Could you please review the PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/17701#issuecomment-1925906527

From dholmes at openjdk.org  Sun Feb  4 23:07:02 2024
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 4 Feb 2024 23:07:02 GMT
Subject: RFR: 8316930: HotSpot should use noexcept instead of throw() [v4]
In-Reply-To: <2sW1ZQ333qSkLQRk_e-f4g-sOwvW2bKshy8cszUoDrw=.bca141f1-d832-4f95-ad68-47c5fc3d068b@github.com>
References: <kc_cq_sBCqn-iAwHCEaTqgMVYrnT6tKsk3SZnD_qP-s=.1b5d24dd-a925-4f6d-aefb-67b4df6bddac@github.com>
 <VScr4niHiJs_5LG0Npi39l3fdOa47am0zftg3jO-IsQ=.0905fa3e-2b66-41a5-b015-2bbd9f7b3940@github.com>
 <2sW1ZQ333qSkLQRk_e-f4g-sOwvW2bKshy8cszUoDrw=.bca141f1-d832-4f95-ad68-47c5fc3d068b@github.com>
Message-ID: <X522HC3ke8LtoI1xQspLXQDc2Drkc_gmYZKap_TS7pQ=.f0a5177a-187e-4f4e-88df-fc84dec67eb2@github.com>

On Fri, 2 Feb 2024 08:38:40 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
>> 
>>  - Merge branch 'openjdk:master' into noexcept
>>  - Typo in GensrcAdlc.gmk
>>  - Merge branch 'openjdk:master' into noexcept
>>  - Merge branch 'master' into noexcept
>>  - ic in compiledIC.hpp
>>  - Revert compiledIC.cpp
>>  - Revert compiledIC.hpp
>>  - Partially Revert parse.hpp
>>  - Merge branch 'master' into noexcept
>>  - Merge branch 'master' into noexcept
>>  - ... and 3 more: https://git.openjdk.org/jdk/compare/a474b372...0d2fe966
>
> src/hotspot/share/c1/c1_Instruction.hpp line 337:
> 
>> 335: 
>> 336:  public:
>> 337:   void* operator new(size_t size) noexcept {
> 
> Should the noexcept specifiers on both operator new in this file be removed? They both call Amalloc with the default parameter of EXIT_OOM, which means they both crash instead of returning nullptr when failing to allocate memory

I think EXIT_OOM is an implementation detail. The key point is that these methods do not throw.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15910#discussion_r1477473088

From dholmes at openjdk.org  Sun Feb  4 23:12:01 2024
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 4 Feb 2024 23:12:01 GMT
Subject: RFR: 8316930: HotSpot should use noexcept instead of throw() [v4]
In-Reply-To: <X522HC3ke8LtoI1xQspLXQDc2Drkc_gmYZKap_TS7pQ=.f0a5177a-187e-4f4e-88df-fc84dec67eb2@github.com>
References: <kc_cq_sBCqn-iAwHCEaTqgMVYrnT6tKsk3SZnD_qP-s=.1b5d24dd-a925-4f6d-aefb-67b4df6bddac@github.com>
 <VScr4niHiJs_5LG0Npi39l3fdOa47am0zftg3jO-IsQ=.0905fa3e-2b66-41a5-b015-2bbd9f7b3940@github.com>
 <2sW1ZQ333qSkLQRk_e-f4g-sOwvW2bKshy8cszUoDrw=.bca141f1-d832-4f95-ad68-47c5fc3d068b@github.com>
 <X522HC3ke8LtoI1xQspLXQDc2Drkc_gmYZKap_TS7pQ=.f0a5177a-187e-4f4e-88df-fc84dec67eb2@github.com>
Message-ID: <zEG6cI-mqmOGle_U_psjrGOlJysZTex7Xw5fal3un-c=.e1beed32-9efa-4dbd-94c2-7ae6f9a24287@github.com>

On Sun, 4 Feb 2024 23:04:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/c1/c1_Instruction.hpp line 337:
>> 
>>> 335: 
>>> 336:  public:
>>> 337:   void* operator new(size_t size) noexcept {
>> 
>> Should the noexcept specifiers on both operator new in this file be removed? They both call Amalloc with the default parameter of EXIT_OOM, which means they both crash instead of returning nullptr when failing to allocate memory
>
> I think EXIT_OOM is an implementation detail. The key point is that these methods do not throw.

Or do I have that backwards ... the key point of `no_except` is that callers of these method must check for `nullptr`, but with EXIT_OOM that is not the case - and we don't want it to appear that the allocation can actually fail and we continue execution!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15910#discussion_r1477473934

From dholmes at openjdk.org  Mon Feb  5 01:22:04 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 5 Feb 2024 01:22:04 GMT
Subject: RFR: 8320302: compiler/arguments/TestC1Globals.java hits SIGSEGV
 in ContinuationEntry::set_enter_code [v2]
In-Reply-To: <ZOVtuk95Hi4niHlne8p1XUGV-s-sApR0M4zR1uGoiQ0=.57d6812f-c02f-4a45-bf92-ec92a60dec39@github.com>
References: <1Cm1SGGaZsYxM-RfPNDeAvnGijQ-taVe438SS6bZ3YI=.d64abde2-f9a0-4589-ab40-eba7c3c02992@github.com>
 <rsC787zJZXqxpRt-8zRKUDysucFHUvklklhmD_YvE2U=.9ef04c16-99e1-4f19-8d87-7dbe897c5b74@github.com>
 <ZOVtuk95Hi4niHlne8p1XUGV-s-sApR0M4zR1uGoiQ0=.57d6812f-c02f-4a45-bf92-ec92a60dec39@github.com>
Message-ID: <HC8HB43N1_Br738385uDFSeJ7PWmyL4cEWW4JzNGurI=.d663c664-81f7-48a8-a339-a53564a1ab2d@github.com>

On Thu, 1 Feb 2024 20:55:16 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 1394:
>> 
>>> 1392:                                               oop_maps,
>>> 1393:                                               exception_offset);
>>> 1394:     if (nm == nullptr) fatal("Initial size of CodeCache is too small");
>> 
>> It is a pity we can't just use a return of `nullptr` up the call chain to then have `create_vm` call `vm_exit_during_initialization` rather than using a `fatal` here.
>> 
>> I suppose we could use `vm_exit_during_initialization` here, but it is not obvious this code path can only be executed during the initialization process.
>
> It should be called during vm initialization time only. I can change it to use vm_exit_during_initialization() instead and add an assert in Method::link_method() where create_native_wrapper() is called for these methods to assert vm is initializing. What do you think?

Sounds good to me! Thanks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17455#discussion_r1477543582

From dholmes at openjdk.org  Mon Feb  5 01:47:02 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 5 Feb 2024 01:47:02 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v5]
In-Reply-To: <eJaIDT78o-Sd9tUEAeCr61x3hNsLo8YhuO_zx8OoFRs=.418f6f99-cda0-4b8d-a784-aafb03cab30e@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
 <8ZG3rV3o0aWMghASjxkM0qLsha99DcXD-paj7UZXn6k=.b0ffccc4-bf8b-4908-9f88-8476153ebe7c@github.com>
 <6q3ZHJtx7qg9SFnAGa36P2hzECOXcbCq83lv6evq11A=.c9aa9e23-ddc8-4b45-a565-c68136e76b05@github.com>
 <LVfnz9eaFOPWaq8n0R5_4bAwGErrWWJ1i4m9BDkfAeo=.255868e5-12b0-419b-ae43-0406ad8e15d6@github.com>
 <_q0C7Lvuh3iNoqEOn-uwqhTxkM7j8PAS4U1peSPbQ-s=.f2472ab9-b802-4286-8e59-aeb667d798be@github.com>
 <jcNvyPaD_RFHjENtzmKTktw3H95xYv1NcyRLQpZOaoo=.f9d8ad89-e56c-4a37-9568-67fe564523ed@github.com>
 <eJaIDT78o-Sd9tUEAeCr61x3hNsLo8YhuO_zx8OoFRs=.418f6f99-cda0-4b8d-a784-aafb03cab30e@github.com>
Message-ID: <kKZyWEDK8QdtEI4zkktwLSK4IytQKMNee9sGbREvAQg=.e42966af-592a-4ef1-b3eb-d4e5b606598a@github.com>

On Fri, 2 Feb 2024 18:26:55 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>>> Given the extra test that @reinrich provided that is exactly what occurs. A nested eliminated lock is re-locked. But the lock is already escaped and contended by another thread.
>> 
>> We didn't reach there with LM_LIGHTWEIGHT. The lock got inflated during warm-up because of the recursive monitorenter in the interpreter. The owner was set to the current thread then. I've improved the test to use a new instance after warm-up. If you want you can cherry-pick here: https://github.com/reinrich/jdk/commit/c28181d585e5ceeaa34e7e6afb4311d59cf990b2
>
> C2 can eliminate 3 types of lock/unlock:
> 1. Locked object does not escape compiled code (it can escape after deoptimization when we return into Interpreter). "Stupid" code example I start seeing in recent bugs:
> 
>    synchronized (new Object())
> 
>   
> 2. Nested locks. There is already held outer lock of the same object (or class) in compiled code.
> 
>     synchronized (obj) {
>          // code
>          synchronized (obj) {
>                // code
> 
> 3. Adjacent unlock/lock pairs if C2 determines it is safe (no control branches or safepoint which can deoptimize between them). We call it `coarsened` locks. You should not see such elimination during deoptimization because no safepoint between.
> 
>     synchronized (obj) { // code1 }
>     synchronized (obj) { // code2 }
> 
> will be converted to
> 
>     synchronized (obj) {
>        // code1
>        // code2
>     }
> 
> 
> Whenever we eliminate lock we mark it in debug info as eliminated so that during deoptimization we can re-lock them.
> It safe to do re-locking for nested locks because deoptee thread already holds lock by outer lock.
> It safe to do re-locking for not-escaped object because other threads do not see it until we return into Interpreter.
> 
> At least that it what happens during normal execution without JVMTI involvement.

> I thought one of the invariants of lightweight locking was that a transition from anonymously owned to actual owner, can only be performed by the actual owner?

To follow up to my own query, this is not quite the case. We introduced the notion of being anonymously owned because under normal conditions if a thread B tries to lock a monitor fast-locked by thread A, it has to inflate the monitor, but it does not know who the owning thread is. Hence it sets it to anonymous. Then when thread A goes to release the monitor, it seems it is inflated, and anonymously owned and so sets the owner to itself, then unlocks.

So as long as we know who the owner thread is, then it should be safe to update the owner from being anonymous.

Also thanks for clarifying the nested lock elimination case, which can lead to the inflation case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17626#discussion_r1477557201

From dholmes at openjdk.org  Mon Feb  5 02:14:04 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 5 Feb 2024 02:14:04 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v8]
In-Reply-To: <zLj4iQnZnflZHsPmnWqIEHrtudnRFCTYTheh88mjnYg=.522c38c6-8e1a-4869-be04-8a7efc0d28cf@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
 <zLj4iQnZnflZHsPmnWqIEHrtudnRFCTYTheh88mjnYg=.522c38c6-8e1a-4869-be04-8a7efc0d28cf@github.com>
Message-ID: <N-9i1cHZREh-dAuwiw3X3-uVipgGGjOGRWETp9Asx4I=.d88ebae7-d04d-4a50-808f-e369aecd9ee6@github.com>

On Fri, 2 Feb 2024 15:11:19 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The `ObjectSynchronizer` has always assumed that the `current` parameters are both the current thread as well as the thread that is doing the locking. The only time that we are entering on behalf of another thread is when doing re-locking in deoptimization. This has worked because the deoptee thread is suspended. However ResourceMarks have been using the wrong thread when logging is enabled.
>> 
>> This change `ObjectSynchronizer` instruments the relevant methods with both a `JavaThread* locking_thread` as well as `[Java]Thread* current` to be able to use the correct thread for ResourceMarks. 
>> 
>> Having the `inflate` care about a `locking_thread` is a little unpleasant in my opinion. But it is required for LM_LIGHTWEIGHT. 
>> Would probably be cleaner if the inflate for LM_LIGHTWEIGHT was it's own thing, as it does not share the whole INFLATING protocol. But seems like a future RFE to refactor this code.
>> 
>> Can reproduce a crash by modifying `test/jdk/com/sun/jdi/EATests.java` and using `-XX:DiagnoseSyncOnValueBasedClasses=2` with LM_LEGACY or running `test/jdk/com/sun/jdi/EATests.java` with LM_LIGHTWEIGHT/LM_MONITOR and `-Xlog:monitorinflation=trace`. 
>> 
>> Could extend this test to capture this regression in the future (or creating a new test based on the same infrastructure). Will give it an attempt, so we have a regression test for this. But these tests get rather involved as the require a lot of jvmti setup.
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve EARelockingNestedInflated_03 for LM_LIGHTWEIGHT

A few minor comment tweaks. Thanks

src/hotspot/share/runtime/synchronizer.cpp line 518:

> 516: 
> 517:     // An async deflation can race after the inflate_for() call and before
> 518:     // enter() can make the ObjectMonitor busy. enter_for() returns false if

s/enter()/enter_for()/ ?

src/hotspot/share/runtime/synchronizer.cpp line 589:

> 587:           return true;
> 588:         }
> 589:         // Fall through to inflate() ...

This comment and the one at line 579 are no longer clear because we don't inflate in this function.

src/hotspot/share/runtime/synchronizer.cpp line 1410:

> 1408:       bool own = inflating_thread != nullptr && inflating_thread->lock_stack().contains(object);
> 1409:       if (own) {
> 1410:         // Owned by us.

"us" is not appropriate when no longer dealing with the current thread.

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17626#pullrequestreview-1861739571
PR Review Comment: https://git.openjdk.org/jdk/pull/17626#discussion_r1477572871
PR Review Comment: https://git.openjdk.org/jdk/pull/17626#discussion_r1477574300
PR Review Comment: https://git.openjdk.org/jdk/pull/17626#discussion_r1477575900

From dholmes at openjdk.org  Mon Feb  5 02:17:01 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 5 Feb 2024 02:17:01 GMT
Subject: RFR: 8324983: race in CompileBroker::possibly_add_compiler_threads
 [v2]
In-Reply-To: <H1Tdo8BVGgjadqg-WL5zE_9tftk7Nfsl5pffxHofLKk=.8b659942-1e54-4071-b9e9-4c932a07dc3e@github.com>
References: <qd8qOUxvTRbavq4rQT5kvA5ujZFdENBsJr_Ggie9hSM=.f88cdff5-4c45-434c-ad70-7faf7981d7f4@github.com>
 <H1Tdo8BVGgjadqg-WL5zE_9tftk7Nfsl5pffxHofLKk=.8b659942-1e54-4071-b9e9-4c932a07dc3e@github.com>
Message-ID: <Ac2QywX1NZ9XLTfSjvI-JBcF62dxJBup7y23Cca29ds=.d881f38d-acf7-474c-824f-1247309e22ee@github.com>

On Thu, 1 Feb 2024 17:37:28 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> The number of active compiler threads is decremented before the compiler thread has actually activated so possibly_add_compiler_thread might start a new thread on the existing JavaThread.  This adds a check that it's really exiting before proceeding and some new guarantees that ensure threads aren't started on top running threads.
>
> Tom Rodriguez has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Convert guarantee to assert

Thanks for the update. Thumbs up on the shared changes.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17662#pullrequestreview-1861751213

From fyang at openjdk.org  Mon Feb  5 06:18:03 2024
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 5 Feb 2024 06:18:03 GMT
Subject: RFR: 8322179: RISC-V: Implement SHA-1 intrinsic [v8]
In-Reply-To: <Wo72eRLr-epmBJmQ1AGdy8xQKcSh1dJVjCP14Shi5LU=.2bd881d5-57f9-4474-afa6-d13b0d00fed9@github.com>
References: <PyIXzENfiHysFS3IyZn3FDNQpV7Ua2L6OmjiXq9wRoU=.cf74a45e-c94b-4f7b-8768-d10d55e2ce1d@github.com>
 <Wo72eRLr-epmBJmQ1AGdy8xQKcSh1dJVjCP14Shi5LU=.2bd881d5-57f9-4474-afa6-d13b0d00fed9@github.com>
Message-ID: <fnEWD25Z0oRc4_Ge1wH8cQXa5DIEpnPkzosIHZaw4SI=.855c5361-afb2-4d49-9f69-cbc94bf08ec5@github.com>

On Thu, 1 Feb 2024 12:23:31 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you review this patch to implement SHA-1 intrinsic for riscv?
>> Thanks!
>> 
>> 
>> ## Test
>> 
>> ### Functionality
>> 
>> tests under `test/hotspot/jtreg/compiler/intrinsics/sha`
>> tests found via `find test/jdk -iname "*SHA1*.java"`
>> 
>> ### Performance
>> 
>> tested on `T-HEAD Light Lichee Pi 4A`
>> 
>> JMH_PARAMS="-f 1 -wi 10 -i 20" // for every loop of jmh test
>> 
>> benchmark tests `MessageDigests.java GetMessageDigest.java MessageDigestBench.java MacBench.java` which are under `test/micro/org/openjdk/bench/`, more spcifically `TESTS="MessageDigests.digest MessageDigests.getAndDigest MessageDigestBench.digest"`
>> 
>> 
>> // After
>> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1        64     DEFAULT  avgt   20      1845.446 ?     27.052  ns/op
>> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    181455.350 ?    532.258  ns/op
>> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2447.674 ?     10.239  ns/op
>> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    182896.083 ?   1242.774  ns/op
>> o.o.b.javax.crypto.small.MessageDigestBench.digest         SHA1     1048576             N/A       N/A              avgt   20  11599227.792 ? 121442.390  ns/op
>> // Before
>> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2352.475 ?    11.198  ns/op
>> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    188495.684 ?  1467.942  ns/op
>> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2437.347 ?     6.398  ns/op
>> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    196086.570 ?  1140.998  ns/op
>> o.o.b.javax.crypto.small.MessageDigestBench.digest         SHA1     1048576             N/A       N/A              avgt   20  12362160.119 ? 38788.109  ns/op
>> 
>> 
>> **getAndDigest when size == 64**
>> The data is not stable for test getAndDigest when size == 64, which I think is introduced by  j.s.MessageDigest.getInstance itself, which we don't touch in this patch.
>> Check more details at [1](ht...
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use x9 as src

src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 4954:

> 4952:       __ add(cur_w, cur_k, cur_w);
> 4953:       __ add(t, t, cur_w);
> 4954:       __ rolw_imm(tmp1, a, 5, tmp2);

I am a bit concerned about the register usage here. I see the caller passes `t0` for `tmp1` and it's alive across `sha1_f` which is non-trivial. I think it could be error-prone since `t0` and `t1` are implictly used as temp registers by various assember functions. My suggestion is to remove `tmp1` and `tmp2` formal parameters and use both `t0` and `t1` directly in this function (and declare that this function will clobber both `t0` and `t1` in the preceding code comment). Then we can use the input `tmp3` here instead. Similar for `sha1_prepare_w` and `sha1_preserve_prev_abcde`. Could you please consider?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17130#discussion_r1477703803

From amitkumar at openjdk.org  Mon Feb  5 06:33:07 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Mon, 5 Feb 2024 06:33:07 GMT
Subject: RFR: 8315762: Update subtype check profile collection on s390x
 following 8308869 [v2]
In-Reply-To: <67cqHtFszZQRHZGhqR7LThot4PciYc1tznqzMTV348s=.1c6acb58-170d-44e8-a9ab-171be82f160a@github.com>
References: <RhTHep7_5gj7u-skAq-BT1NmLc6cB7i7qq0Dj-ks-lc=.d73379ed-06f5-4294-9926-c54a88198312@github.com>
 <67cqHtFszZQRHZGhqR7LThot4PciYc1tznqzMTV348s=.1c6acb58-170d-44e8-a9ab-171be82f160a@github.com>
Message-ID: <EgAFJtJFSIbeNMQ9HrJAApFJ_4TJoI3W8-r39LGcGbk=.361f9a1c-159e-4ba5-b143-4363695febe9@github.com>

On Thu, 25 Jan 2024 15:20:59 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> s390x Implementation for https://github.com/openjdk/jdk/pull/14375
>> 
>> Benchmark Result with patch: 
>> 
>> Benchmark                                         (typePollution)  (typePollutionNotInternalType)   Mode  Cnt     Score    Error   Units
>> RequireNonNullCheckcastScalability.isDuplicated1            false                           false  thrpt   20  1155.409 ? 43.844  ops/us
>> RequireNonNullCheckcastScalability.isDuplicated1            false                            true  thrpt   20   726.923 ? 54.536  ops/us
>> RequireNonNullCheckcastScalability.isDuplicated1             true                           false  thrpt   20   676.462 ? 23.503  ops/us
>> RequireNonNullCheckcastScalability.isDuplicated1             true                            true  thrpt   20   118.650 ?  2.653  ops/us
>> 
>> 
>> Without Patch: 
>> 
>> Benchmark                                         (typePollution)  (typePollutionNotInternalType)   Mode  Cnt     Score     Error   Units
>> RequireNonNullCheckcastScalability.isDuplicated1            false                           false  thrpt   20  1101.248 ? 103.559  ops/us
>> RequireNonNullCheckcastScalability.isDuplicated1            false                            true  thrpt   20   109.690 ?   3.312  ops/us
>> RequireNonNullCheckcastScalability.isDuplicated1             true                           false  thrpt   20   110.790 ?   7.927  ops/us
>> RequireNonNullCheckcastScalability.isDuplicated1             true                            true  thrpt   20   112.244 ?   6.889  ops/us
>> 
>> 
>> Testing : Fastdebug build + tier1 tests
>
> Amit Kumar 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' of https://git.openjdk.org/jdk into subtype_v0
>  - s390 Port

I ran the test again and didn't see new failure. So moving ahead with integration. 
Thanks @RealLucy @TheRealMDoerr for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/17461#issuecomment-1926311491

From amitkumar at openjdk.org  Mon Feb  5 06:33:07 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Mon, 5 Feb 2024 06:33:07 GMT
Subject: Integrated: 8315762: Update subtype check profile collection on s390x
 following 8308869
In-Reply-To: <RhTHep7_5gj7u-skAq-BT1NmLc6cB7i7qq0Dj-ks-lc=.d73379ed-06f5-4294-9926-c54a88198312@github.com>
References: <RhTHep7_5gj7u-skAq-BT1NmLc6cB7i7qq0Dj-ks-lc=.d73379ed-06f5-4294-9926-c54a88198312@github.com>
Message-ID: <jCCNjEOrRG2aGN16Qxt_R_SxWSeEJgTFPbEPVnCp26Q=.f2ab4ff5-0007-40fc-b29d-80334ecab3c5@github.com>

On Wed, 17 Jan 2024 12:06:13 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> s390x Implementation for https://github.com/openjdk/jdk/pull/14375
> 
> Benchmark Result with patch: 
> 
> Benchmark                                         (typePollution)  (typePollutionNotInternalType)   Mode  Cnt     Score    Error   Units
> RequireNonNullCheckcastScalability.isDuplicated1            false                           false  thrpt   20  1155.409 ? 43.844  ops/us
> RequireNonNullCheckcastScalability.isDuplicated1            false                            true  thrpt   20   726.923 ? 54.536  ops/us
> RequireNonNullCheckcastScalability.isDuplicated1             true                           false  thrpt   20   676.462 ? 23.503  ops/us
> RequireNonNullCheckcastScalability.isDuplicated1             true                            true  thrpt   20   118.650 ?  2.653  ops/us
> 
> 
> Without Patch: 
> 
> Benchmark                                         (typePollution)  (typePollutionNotInternalType)   Mode  Cnt     Score     Error   Units
> RequireNonNullCheckcastScalability.isDuplicated1            false                           false  thrpt   20  1101.248 ? 103.559  ops/us
> RequireNonNullCheckcastScalability.isDuplicated1            false                            true  thrpt   20   109.690 ?   3.312  ops/us
> RequireNonNullCheckcastScalability.isDuplicated1             true                           false  thrpt   20   110.790 ?   7.927  ops/us
> RequireNonNullCheckcastScalability.isDuplicated1             true                            true  thrpt   20   112.244 ?   6.889  ops/us
> 
> 
> Testing : Fastdebug build + tier1 tests

This pull request has now been integrated.

Changeset: 8796f43c
Author:    Amit Kumar <amitkumar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8796f43c6c64d1b91b92db8c44b0672027807c10
Stats:     116 lines in 4 files changed: 20 ins; 67 del; 29 mod

8315762: Update subtype check profile collection on s390x following 8308869

Reviewed-by: mdoerr, lucy

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

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

From aboldtch at openjdk.org  Mon Feb  5 06:44:18 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 5 Feb 2024 06:44:18 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v9]
In-Reply-To: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
Message-ID: <_GGWmJtp4DdVRxbNmmtzeuBAQkFw6yXqfbTQMCbETiI=.954ecccb-85b4-443a-b30c-8d742501206c@github.com>

> The `ObjectSynchronizer` has always assumed that the `current` parameters are both the current thread as well as the thread that is doing the locking. The only time that we are entering on behalf of another thread is when doing re-locking in deoptimization. This has worked because the deoptee thread is suspended. However ResourceMarks have been using the wrong thread when logging is enabled.
> 
> This change `ObjectSynchronizer` instruments the relevant methods with both a `JavaThread* locking_thread` as well as `[Java]Thread* current` to be able to use the correct thread for ResourceMarks. 
> 
> Having the `inflate` care about a `locking_thread` is a little unpleasant in my opinion. But it is required for LM_LIGHTWEIGHT. 
> Would probably be cleaner if the inflate for LM_LIGHTWEIGHT was it's own thing, as it does not share the whole INFLATING protocol. But seems like a future RFE to refactor this code.
> 
> Can reproduce a crash by modifying `test/jdk/com/sun/jdi/EATests.java` and using `-XX:DiagnoseSyncOnValueBasedClasses=2` with LM_LEGACY or running `test/jdk/com/sun/jdi/EATests.java` with LM_LIGHTWEIGHT/LM_MONITOR and `-Xlog:monitorinflation=trace`. 
> 
> Could extend this test to capture this regression in the future (or creating a new test based on the same infrastructure). Will give it an attempt, so we have a regression test for this. But these tests get rather involved as the require a lot of jvmti setup.

Axel Boldt-Christmas has updated the pull request incrementally with six additional commits since the last revision:

 - Update test/jdk/com/sun/jdi/EATests.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Update test/jdk/com/sun/jdi/EATests.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Update test/jdk/com/sun/jdi/EATests.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Update test/jdk/com/sun/jdi/EATests.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Remove newline
 - Update src/hotspot/share/runtime/synchronizer.hpp
   
   Co-authored-by: Richard Reingruber <richard.reingruber at sap.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17626/files
  - new: https://git.openjdk.org/jdk/pull/17626/files/8ff8a248..a30e3910

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

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

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

From aboldtch at openjdk.org  Mon Feb  5 06:51:22 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 5 Feb 2024 06:51:22 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v10]
In-Reply-To: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
Message-ID: <wL168lSWSS1EHp_v9lraUQySJ3WzFD7uoWOIolAtUaU=.cea57d21-687c-44e9-86f7-7ca38930fc87@github.com>

> The `ObjectSynchronizer` has always assumed that the `current` parameters are both the current thread as well as the thread that is doing the locking. The only time that we are entering on behalf of another thread is when doing re-locking in deoptimization. This has worked because the deoptee thread is suspended. However ResourceMarks have been using the wrong thread when logging is enabled.
> 
> This change `ObjectSynchronizer` instruments the relevant methods with both a `JavaThread* locking_thread` as well as `[Java]Thread* current` to be able to use the correct thread for ResourceMarks. 
> 
> Having the `inflate` care about a `locking_thread` is a little unpleasant in my opinion. But it is required for LM_LIGHTWEIGHT. 
> Would probably be cleaner if the inflate for LM_LIGHTWEIGHT was it's own thing, as it does not share the whole INFLATING protocol. But seems like a future RFE to refactor this code.
> 
> Can reproduce a crash by modifying `test/jdk/com/sun/jdi/EATests.java` and using `-XX:DiagnoseSyncOnValueBasedClasses=2` with LM_LEGACY or running `test/jdk/com/sun/jdi/EATests.java` with LM_LIGHTWEIGHT/LM_MONITOR and `-Xlog:monitorinflation=trace`. 
> 
> Could extend this test to capture this regression in the future (or creating a new test based on the same infrastructure). Will give it an attempt, so we have a regression test for this. But these tests get rather involved as the require a lot of jvmti setup.

Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8324881
 - Update comment
 - Fix comments
 - Update test/jdk/com/sun/jdi/EATests.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Update test/jdk/com/sun/jdi/EATests.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Update test/jdk/com/sun/jdi/EATests.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Update test/jdk/com/sun/jdi/EATests.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Remove newline
 - Update src/hotspot/share/runtime/synchronizer.hpp
   
   Co-authored-by: Richard Reingruber <richard.reingruber at sap.com>
 - Improve EARelockingNestedInflated_03 for LM_LIGHTWEIGHT
 - ... and 12 more: https://git.openjdk.org/jdk/compare/dd3f5d6e...b3cc401c

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17626/files
  - new: https://git.openjdk.org/jdk/pull/17626/files/a30e3910..b3cc401c

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

  Stats: 2596 lines in 143 files changed: 1531 ins; 324 del; 741 mod
  Patch: https://git.openjdk.org/jdk/pull/17626.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17626/head:pull/17626

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

From dholmes at openjdk.org  Mon Feb  5 07:00:08 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 5 Feb 2024 07:00:08 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v10]
In-Reply-To: <wL168lSWSS1EHp_v9lraUQySJ3WzFD7uoWOIolAtUaU=.cea57d21-687c-44e9-86f7-7ca38930fc87@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
 <wL168lSWSS1EHp_v9lraUQySJ3WzFD7uoWOIolAtUaU=.cea57d21-687c-44e9-86f7-7ca38930fc87@github.com>
Message-ID: <vf7t17S7kTABTQQeDbbgBCmfUiQvLEFOOkZk_Y8yv9Q=.963e32ea-a66a-4134-b053-c738752b93fe@github.com>

On Mon, 5 Feb 2024 06:51:22 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The `ObjectSynchronizer` has always assumed that the `current` parameters are both the current thread as well as the thread that is doing the locking. The only time that we are entering on behalf of another thread is when doing re-locking in deoptimization. This has worked because the deoptee thread is suspended. However ResourceMarks have been using the wrong thread when logging is enabled.
>> 
>> This change `ObjectSynchronizer` instruments the relevant methods with both a `JavaThread* locking_thread` as well as `[Java]Thread* current` to be able to use the correct thread for ResourceMarks. 
>> 
>> Having the `inflate` care about a `locking_thread` is a little unpleasant in my opinion. But it is required for LM_LIGHTWEIGHT. 
>> Would probably be cleaner if the inflate for LM_LIGHTWEIGHT was it's own thing, as it does not share the whole INFLATING protocol. But seems like a future RFE to refactor this code.
>> 
>> Can reproduce a crash by modifying `test/jdk/com/sun/jdi/EATests.java` and using `-XX:DiagnoseSyncOnValueBasedClasses=2` with LM_LEGACY or running `test/jdk/com/sun/jdi/EATests.java` with LM_LIGHTWEIGHT/LM_MONITOR and `-Xlog:monitorinflation=trace`. 
>> 
>> Could extend this test to capture this regression in the future (or creating a new test based on the same infrastructure). Will give it an attempt, so we have a regression test for this. But these tests get rather involved as the require a lot of jvmti setup.
>
> Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8324881
>  - Update comment
>  - Fix comments
>  - Update test/jdk/com/sun/jdi/EATests.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update test/jdk/com/sun/jdi/EATests.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update test/jdk/com/sun/jdi/EATests.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update test/jdk/com/sun/jdi/EATests.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Remove newline
>  - Update src/hotspot/share/runtime/synchronizer.hpp
>    
>    Co-authored-by: Richard Reingruber <richard.reingruber at sap.com>
>  - Improve EARelockingNestedInflated_03 for LM_LIGHTWEIGHT
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/e0c930a4...b3cc401c

Thanks for the tweaks. Nothing further from me. Many thanks for taking on this cleanup.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17626#pullrequestreview-1861998419

From mdoerr at openjdk.org  Mon Feb  5 08:30:04 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 5 Feb 2024 08:30:04 GMT
Subject: RFR: 8314488: Compile the JDK as C++17 [v5]
In-Reply-To: <EOE6UCFGWlTNsizD1fjPn_-rVy02Rdq4s8g8H471iPM=.37940ce8-ff5a-4f41-8851-02095ae0be4a@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
 <aFP4brPqhix6XQsDaH2dxokMi2yTEoClwBt4JqAVOtQ=.04e313b1-70d7-4f28-8354-77bd4fb398c1@github.com>
 <ZmBzXcxwndh1ZO9_vbsdY3KoHmUx0LSycjzh3JDLbTo=.3cb30ad4-a4d9-4c92-82f7-118d6cc6702e@github.com>
 <EOE6UCFGWlTNsizD1fjPn_-rVy02Rdq4s8g8H471iPM=.37940ce8-ff5a-4f41-8851-02095ae0be4a@github.com>
Message-ID: <0Ga1XPW8G48Dip-k3vLbvFg8sI-ywjcMQytuQRAvSLo=.0cbcfa73-0b32-4ec5-bfbc-a15a27e7f1f2@github.com>

On Thu, 11 Jan 2024 13:04:35 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> There is a typo in adlc:
> 
> ```
> diff --git a/make/hotspot/gensrc/GensrcAdlc.gmk b/make/hotspot/gensrc/GensrcAdlc.gmk
> index 0898d91e1c2..bb356476847 100644
> --- a/make/hotspot/gensrc/GensrcAdlc.gmk
> +++ b/make/hotspot/gensrc/GensrcAdlc.gmk
> @@ -51,7 +51,7 @@ ifeq ($(call check-jvm-feature, compiler2), true)
>    endif
>  
>    # Set the C++ standard
> -  ADLC_CFLAGS += $(ADLC_LANGSTD_CXXFLAG)
> +  ADLC_CFLAGS += $(ADLC_LANGSTD_CXXFLAGS)
>  
>    # NOTE: The old build didn't set -DASSERT for windows but it doesn't seem to
>    # hurt.
> ```

Created a PR for that: https://github.com/openjdk/jdk/pull/17705

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

PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1926450195

From sroy at openjdk.org  Mon Feb  5 08:52:21 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 5 Feb 2024 08:52:21 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v14]
In-Reply-To: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
Message-ID: <cNyV9jVxZtoIf9qgQbTQ86Syu95kql6wC5C1DzgiRPs=.8d2f1d5b-b64a-41b8-87f2-c8d31b0e98c0@github.com>

> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am.
> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX.
> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails.

Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:

  Change logging

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16604/files
  - new: https://git.openjdk.org/jdk/pull/16604/files/af761abb..f4c1788b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=12-13

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

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

From mdoerr at openjdk.org  Mon Feb  5 09:04:08 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 5 Feb 2024 09:04:08 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v14]
In-Reply-To: <cNyV9jVxZtoIf9qgQbTQ86Syu95kql6wC5C1DzgiRPs=.8d2f1d5b-b64a-41b8-87f2-c8d31b0e98c0@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <cNyV9jVxZtoIf9qgQbTQ86Syu95kql6wC5C1DzgiRPs=.8d2f1d5b-b64a-41b8-87f2-c8d31b0e98c0@github.com>
Message-ID: <VDnWgKmkKKxKGDnT3_7xmpl6wVqrs6n0Z_mOVWsesCg=.cd4a8667-4086-450e-8fe1-df023ad0acb5@github.com>

On Mon, 5 Feb 2024 08:52:21 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am.
>> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX.
>> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails.
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change logging

The trailing whitespace errors must get fixed (integration blocker).

src/hotspot/os/aix/os_aix.cpp line 1183:

> 1181:   // If the load fails,we try to reload by changing the extension to .a for .so files only.
> 1182:   if (result == nullptr) {
> 1183:     if (strcmp(pointer_to_dot, ".so") == 0) {

We could possibly reach here with `pointer_to_dot` == nullptr. Invoking strcmp causes undefined behavior!

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

Changes requested by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16604#pullrequestreview-1862189297
PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1477856818

From aph at openjdk.org  Mon Feb  5 09:08:03 2024
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 5 Feb 2024 09:08:03 GMT
Subject: RFR: 8324874: AArch64: crypto pmull based CRC32/CRC32C intrinsics
 clobber V8-V15 registers [v2]
In-Reply-To: <T_qG0AQ3r_AxzbtUm1HZTDQ-tjokSs1wcHiz4V2WGl4=.987ff437-ff99-49b0-8707-d7b46fca2caa@github.com>
References: <I4SlF2m1-uY5cH3AsdBhVqbTJ1m7GXfThpCgfx_6N5k=.b7a84fc0-198c-4bf0-a26b-bbe3c3ed2558@github.com>
 <T_qG0AQ3r_AxzbtUm1HZTDQ-tjokSs1wcHiz4V2WGl4=.987ff437-ff99-49b0-8707-d7b46fca2caa@github.com>
Message-ID: <0SyT_VJe-wuDQqutiEy8bSjxvECduPSEuqP0tnrBSfI=.75eee8c5-466a-437e-a38e-0c0ed38df080@github.com>

On Sun, 4 Feb 2024 20:30:26 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> [JDK-8302113](https://bugs.openjdk.org/browse/JDK-8302113) and [JDK-8302783](https://bugs.openjdk.org/browse/JDK-8302783) enhanced CRC32/CRC32C intrinsics with crypto pmull which is enabled for Neoverse V1 and V2. The intrinsics use `kernel_crc32_common_fold_using_crypto_pmull` which uses v8-v15 registers and potentially clobbers them if they are not saved before CRC32/CRC32C intrinsics are called.
>> 
>> According to the latest ?ABI for the Arm 64-bit Architecture with SVE support?: https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst
>> 
>> 
>> Registers v8-v15 must be preserved by a callee across subroutine calls;
>> the remaining registers (v0-v7, v16-v31) do not need to be preserved
>> (or should be preserved by the caller).
>> 
>> 
>> This PR reallocates registers to avoid v8-v15 registers:
>> - v0-v7 are used for data.
>> - v16-v32 are tmp registers.
>> 
>> Regression tests are added.
>> Tested a fastdebug build on Graviton 3:
>> - `gtest`: Passed
>> - `tier1..tier3`: Passed
>
> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix code comments

Thanks. This bug really shouldn't have got through review.

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

Marked as reviewed by aph (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17701#pullrequestreview-1862197344

From mdoerr at openjdk.org  Mon Feb  5 09:16:06 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 5 Feb 2024 09:16:06 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v11]
In-Reply-To: <odz-rX0Gz897NF26n2ZEXl9vz35IJ8TUSFUKU5gPYdo=.92a5106b-c6cc-4522-bcfb-ec14b0a19638@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <m0w6Rh_2nNuZ_vmFcBRok-cK5XDJtgZMGwKrl_VzrQE=.b469dc8d-50c2-44b4-8c3e-99036f6acb31@github.com>
 <oafXeyNylwlnKFzjgMkN4HdB_dEL0Qfu8MlL3kDtI5g=.e529938b-d393-4777-a4cf-50977fbdbb14@github.com>
 <aNgfepuaa1Z7omQhZ7Ywl6FeegnSZ3gUc97Sbo-fQYw=.d7ca62a8-496f-4f51-8f64-8bdf679c89ca@github.com>
 <odz-rX0Gz897NF26n2ZEXl9vz35IJ8TUSFUKU5gPYdo=.92a5106b-c6cc-4522-bcfb-ec14b0a19638@github.com>
Message-ID: <SI6D7-kkk_nLWRXwflFfxTVJO94l6x14lG-gYKlFYaM=.267ed85e-4266-48f5-8ebe-8eecbb6f7be0@github.com>

On Wed, 31 Jan 2024 11:22:27 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> The load library gets the entire library name, after construction from dll_build_name. This is always a .so file name. When .so file name fails to load, we fallback to .a filename. 
>> Do i need to mention the filename as libfilename.so then ?
>
> Yes, I think this would make it clear.

Please use space after comma.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1477871269

From aph at openjdk.org  Mon Feb  5 09:20:04 2024
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 5 Feb 2024 09:20:04 GMT
Subject: RFR: 8314488: Compile the JDK as C++17 [v6]
In-Reply-To: <i3bo22m6I5cYhAMfktX-W_4-rrtyK6EPyK57QUi6Tco=.a18ddecb-440b-4c70-95ec-4b21fd1b3144@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
 <b4HhbT5caIfCbrVveI6NDObiwUI2Sr0so68JBG6C0YU=.1734aaa7-aed4-478c-bbb6-de9af5c04ef9@github.com>
 <i3bo22m6I5cYhAMfktX-W_4-rrtyK6EPyK57QUi6Tco=.a18ddecb-440b-4c70-95ec-4b21fd1b3144@github.com>
Message-ID: <KCC78U2X_if2XTRu1qNkeVXSQ672EyZFHbkl-OtP3U8=.9695b185-dc76-4d26-ae32-ceb254f5f275@github.com>

On Wed, 17 Jan 2024 11:19:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> We have been stuck on a very old gcc for a long time, due to various reasons. Partly because old gcc versions were not as terrible as old versions of cl.exe, and partly to support odd linux platforms where newer gcc versions were not available.
> 
> It is tempting to raise the bar to get better functionality available on all platforms. In the end, it is a balance between supporting older platforms, and getting a better common language level for the code.
> 
> gcc 10 was released 3+ years ago. I guess that is good enough to consider it a reasonable new minimum.

I guess so, but that sounds rather aggressive to me. Sure, you can always install a newer GCC than the system one, but it's another thing that makes it harder for people to build OpenJDK. Having said that, C++17 is nice to have.

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

PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1926533675

From sroy at openjdk.org  Mon Feb  5 09:26:08 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 5 Feb 2024 09:26:08 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v14]
In-Reply-To: <VDnWgKmkKKxKGDnT3_7xmpl6wVqrs6n0Z_mOVWsesCg=.cd4a8667-4086-450e-8fe1-df023ad0acb5@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <cNyV9jVxZtoIf9qgQbTQ86Syu95kql6wC5C1DzgiRPs=.8d2f1d5b-b64a-41b8-87f2-c8d31b0e98c0@github.com>
 <VDnWgKmkKKxKGDnT3_7xmpl6wVqrs6n0Z_mOVWsesCg=.cd4a8667-4086-450e-8fe1-df023ad0acb5@github.com>
Message-ID: <tBlwJcdCIL3WO9U1vQkRQaEiq--nWkhyLHthR4FOoqs=.92b28970-4ed5-4841-856f-89b9060bc3be@github.com>

On Mon, 5 Feb 2024 09:01:06 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change logging
>
> src/hotspot/os/aix/os_aix.cpp line 1183:
> 
>> 1181:   // If the load fails,we try to reload by changing the extension to .a for .so files only.
>> 1182:   if (result == nullptr) {
>> 1183:     if (strcmp(pointer_to_dot, ".so") == 0) {
> 
> We could possibly reach here with `pointer_to_dot` == nullptr. Invoking strcmp causes undefined behavior!

Yes. Do we exit when there is no extension in the file ..or we can just append an extension manually and let the program flow go through.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1477884033

From ihse at openjdk.org  Mon Feb  5 09:47:05 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Feb 2024 09:47:05 GMT
Subject: RFR: 8314488: Compile the JDK as C++17 [v6]
In-Reply-To: <KCC78U2X_if2XTRu1qNkeVXSQ672EyZFHbkl-OtP3U8=.9695b185-dc76-4d26-ae32-ceb254f5f275@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
 <b4HhbT5caIfCbrVveI6NDObiwUI2Sr0so68JBG6C0YU=.1734aaa7-aed4-478c-bbb6-de9af5c04ef9@github.com>
 <i3bo22m6I5cYhAMfktX-W_4-rrtyK6EPyK57QUi6Tco=.a18ddecb-440b-4c70-95ec-4b21fd1b3144@github.com>
 <KCC78U2X_if2XTRu1qNkeVXSQ672EyZFHbkl-OtP3U8=.9695b185-dc76-4d26-ae32-ceb254f5f275@github.com>
Message-ID: <yq-FT47x7QF7L78fMxw3VvYAo_osUWzeUzxb5iJU3hE=.1899b72a-41f7-44b7-946f-84ca1339f1f8@github.com>

On Mon, 5 Feb 2024 09:17:11 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Sure, you can always install a newer GCC than the system one, but it's another thing that makes it harder for people to build OpenJDK. Having said that, C++17 is nice to have.

@theRealAph  I am still just hearing hand-waving "perhaps someone somewhere will have a somewhat harder time building the JDK". Yes, perhaps that is so. But that is very uncertain, and I have still not heard a single concrete example of where this would apply. In contrast, going to gcc 10 will clearly bring a benefit to all other platforms, since it allows us to synchronize the code base at C++17.

In light of this, I think we need to hear some really compelling evidence of problems that would ensue if we raise the minimum to gcc 10. If nobody can produce such evidence, then to me it is a sign that this fear is not well-grounded, and we should proceed with this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1926580836

From ngasson at openjdk.org  Mon Feb  5 10:04:02 2024
From: ngasson at openjdk.org (Nick Gasson)
Date: Mon, 5 Feb 2024 10:04:02 GMT
Subject: RFR: 8324874: AArch64: crypto pmull based CRC32/CRC32C intrinsics
 clobber V8-V15 registers [v2]
In-Reply-To: <T_qG0AQ3r_AxzbtUm1HZTDQ-tjokSs1wcHiz4V2WGl4=.987ff437-ff99-49b0-8707-d7b46fca2caa@github.com>
References: <I4SlF2m1-uY5cH3AsdBhVqbTJ1m7GXfThpCgfx_6N5k=.b7a84fc0-198c-4bf0-a26b-bbe3c3ed2558@github.com>
 <T_qG0AQ3r_AxzbtUm1HZTDQ-tjokSs1wcHiz4V2WGl4=.987ff437-ff99-49b0-8707-d7b46fca2caa@github.com>
Message-ID: <ShvEmBpxi1dxJ9LfoX37ZLbkgcupF2nhhsZPEJXVR64=.ae86a594-f475-4604-977b-3ac9dca53754@github.com>

On Sun, 4 Feb 2024 20:30:26 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> [JDK-8302113](https://bugs.openjdk.org/browse/JDK-8302113) and [JDK-8302783](https://bugs.openjdk.org/browse/JDK-8302783) enhanced CRC32/CRC32C intrinsics with crypto pmull which is enabled for Neoverse V1 and V2. The intrinsics use `kernel_crc32_common_fold_using_crypto_pmull` which uses v8-v15 registers and potentially clobbers them if they are not saved before CRC32/CRC32C intrinsics are called.
>> 
>> According to the latest ?ABI for the Arm 64-bit Architecture with SVE support?: https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst
>> 
>> 
>> Registers v8-v15 must be preserved by a callee across subroutine calls;
>> the remaining registers (v0-v7, v16-v31) do not need to be preserved
>> (or should be preserved by the caller).
>> 
>> 
>> This PR reallocates registers to avoid v8-v15 registers:
>> - v0-v7 are used for data.
>> - v16-v32 are tmp registers.
>> 
>> Regression tests are added.
>> Tested a fastdebug build on Graviton 3:
>> - `gtest`: Passed
>> - `tier1..tier3`: Passed
>
> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix code comments

Marked as reviewed by ngasson (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17701#pullrequestreview-1862315171

From aph at openjdk.org  Mon Feb  5 10:12:16 2024
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 5 Feb 2024 10:12:16 GMT
Subject: RFR: 8319801: Recursive lightweight locking: aarch64
 implementation [v13]
In-Reply-To: <tQBTilK3gaS97w0nL4pgf76dt4EjWhWkiCQFZCLsA1w=.e0e98db1-1d55-481c-8419-dc225e872921@github.com>
References: <AE1nsnyRCUHR970jjg4feUm5f6E1GPJvea0ooC6dCgI=.73fff610-c0f6-422a-a45d-88187b37b9a2@github.com>
 <tQBTilK3gaS97w0nL4pgf76dt4EjWhWkiCQFZCLsA1w=.e0e98db1-1d55-481c-8419-dc225e872921@github.com>
Message-ID: <xe8JA4mPencun9Vy6apQCn4ZNkk2WQ_39ohDs4gonZs=.1b5b8d37-daef-451b-8f51-a9e5bb3e2a2a@github.com>

On Fri, 2 Feb 2024 10:20:40 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Implements the aarch64 port of JDK-8319796.
>> 
>> There are two major parts for the port implementation. The C2 part, and the part shared by the interpreter, C1 and the native call wrapper.
>> 
>> The biggest change for both parts is that we check the lock stack first and if it is a recursive lightweight [un]lock and in that case simply pop/push and finish successfully.
>> 
>> Only if the recursive lightweight [un]lock fails does it look at the mark word. 
>> 
>> For the shared part if it is an unstructured exit, the monitor is inflated or the mark word transition fails it calls into the runtime.
>> 
>> The C2 operates under a few more assumptions, that the locking is structured and balanced. This means that some checks can be elided. 
>> 
>> First this means that in C2 unlock if the obj is not on the top of the lock stack, it must be inflated. And reversely if we reach the inflated C2 unlock the obj is not on the lock stack. This second property makes it possible to avoid reading the owner (and checking if it is anonymous). Instead it can either just do an un-contended unlock by writing null to the owner, or if contention happens, simply write the thread to the owner and jump to the runtime. 
>> 
>> The aarch64 C2 port tries to avoid stronger memory semantics where ever possible. In C2 lock it first does a relaxed load of the mark word to check for inflation. Both lock and unlock uses a load/store exclusive register pair to transition the mark word.
>
> Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319801
>  - Update src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp
>    
>    Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>
>  - Clarify the rscratch1 assert
>  - Comments and nits
>  - Update copyright years
>  - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319801
>  - Drop memory order comments
>  - Preloads markWord unconditionally
>  - Revert "Add preload_mark to MacroAssembler::lightweight_lock"
>    
>    This reverts commit 8950f503aa5dba0e203613bd9737ea0d50388ca3.
>  - Add preload_mark to MacroAssembler::lightweight_lock
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/ac59e417...2d4ba75d

Ping?

> The `testContendedLock` is showing so much Error that I can't take any of it seriously. However, there's no significant advantage for LL/SC, and therefore it should not be part of this patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/16608#issuecomment-1926629486

From mli at openjdk.org  Mon Feb  5 10:19:14 2024
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 5 Feb 2024 10:19:14 GMT
Subject: RFR: 8322179: RISC-V: Implement SHA-1 intrinsic [v9]
In-Reply-To: <PyIXzENfiHysFS3IyZn3FDNQpV7Ua2L6OmjiXq9wRoU=.cf74a45e-c94b-4f7b-8768-d10d55e2ce1d@github.com>
References: <PyIXzENfiHysFS3IyZn3FDNQpV7Ua2L6OmjiXq9wRoU=.cf74a45e-c94b-4f7b-8768-d10d55e2ce1d@github.com>
Message-ID: <pLyu5iq-MnLJ6HzD3V-ecpYIUxjNFgy1OfOgK8H0k1Y=.f58bb714-0da3-4e1d-96b7-81001903e67d@github.com>

> Hi,
> Can you review this patch to implement SHA-1 intrinsic for riscv?
> Thanks!
> 
> 
> ## Test
> 
> ### Functionality
> 
> tests under `test/hotspot/jtreg/compiler/intrinsics/sha`
> tests found via `find test/jdk -iname "*SHA1*.java"`
> 
> ### Performance
> 
> tested on `T-HEAD Light Lichee Pi 4A`
> 
> JMH_PARAMS="-f 1 -wi 10 -i 20" // for every loop of jmh test
> 
> benchmark tests `MessageDigests.java GetMessageDigest.java MessageDigestBench.java MacBench.java` which are under `test/micro/org/openjdk/bench/`, more spcifically `TESTS="MessageDigests.digest MessageDigests.getAndDigest MessageDigestBench.digest"`
> 
> 
> // After
> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1        64     DEFAULT  avgt   20      1845.446 ?     27.052  ns/op
> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    181455.350 ?    532.258  ns/op
> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2447.674 ?     10.239  ns/op
> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    182896.083 ?   1242.774  ns/op
> o.o.b.javax.crypto.small.MessageDigestBench.digest         SHA1     1048576             N/A       N/A              avgt   20  11599227.792 ? 121442.390  ns/op
> // Before
> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2352.475 ?    11.198  ns/op
> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    188495.684 ?  1467.942  ns/op
> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2437.347 ?     6.398  ns/op
> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    196086.570 ?  1140.998  ns/op
> o.o.b.javax.crypto.small.MessageDigestBench.digest         SHA1     1048576             N/A       N/A              avgt   20  12362160.119 ? 38788.109  ns/op
> 
> 
> **getAndDigest when size == 64**
> The data is not stable for test getAndDigest when size == 64, which I think is introduced by  j.s.MessageDigest.getInstance itself, which we don't touch in this patch.
> Check more details at [1](https://github.com/openjdk/jdk/pull/17130#issuecomment-1886805614)
> 
> 
> loop ... ...

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  not pass in temp register explicitly

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17130/files
  - new: https://git.openjdk.org/jdk/pull/17130/files/50b4e110..e8b01b64

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

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

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

From mli at openjdk.org  Mon Feb  5 10:19:15 2024
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 5 Feb 2024 10:19:15 GMT
Subject: RFR: 8322179: RISC-V: Implement SHA-1 intrinsic [v8]
In-Reply-To: <fnEWD25Z0oRc4_Ge1wH8cQXa5DIEpnPkzosIHZaw4SI=.855c5361-afb2-4d49-9f69-cbc94bf08ec5@github.com>
References: <PyIXzENfiHysFS3IyZn3FDNQpV7Ua2L6OmjiXq9wRoU=.cf74a45e-c94b-4f7b-8768-d10d55e2ce1d@github.com>
 <Wo72eRLr-epmBJmQ1AGdy8xQKcSh1dJVjCP14Shi5LU=.2bd881d5-57f9-4474-afa6-d13b0d00fed9@github.com>
 <fnEWD25Z0oRc4_Ge1wH8cQXa5DIEpnPkzosIHZaw4SI=.855c5361-afb2-4d49-9f69-cbc94bf08ec5@github.com>
Message-ID: <5Fj8i_fnc4Phm38A6UroSdWmAV4O_lklbqo3crt0jb0=.5af4cdb7-904f-48a2-bc91-d11b9a44ae8b@github.com>

On Mon, 5 Feb 2024 06:01:51 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use x9 as src
>
> src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 4954:
> 
>> 4952:       __ add(cur_w, cur_k, cur_w);
>> 4953:       __ add(t, t, cur_w);
>> 4954:       __ rolw_imm(tmp1, a, 5, tmp2);
> 
> I am a bit concerned about the register usage here. I see the caller passes `t0` for `tmp1` and it's alive across `sha1_f` which is non-trivial. I think it could be error-prone since `t0` and `t1` are implictly used as temp registers by various assember functions. My suggestion is to remove `tmp1` and `tmp2` formal parameters and use both `t0` and `t1` directly in this function (and declare that this function will clobber both `t0` and `t1` in the preceding code comment). Then we can use the input `tmp3` here instead. Similar for `sha1_prepare_w` and `sha1_preserve_prev_abcde`. Could you please consider?

Updated, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17130#discussion_r1477951621

From sspitsyn at openjdk.org  Mon Feb  5 10:22:01 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 5 Feb 2024 10:22:01 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage
In-Reply-To: <Y9kuHAY_5xidLLP1P3cwT5MJBdhWMvQ-XZi5QBbthSs=.80273e1d-1c71-4bbf-be61-e7e6ff0ee96d@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <Y9kuHAY_5xidLLP1P3cwT5MJBdhWMvQ-XZi5QBbthSs=.80273e1d-1c71-4bbf-be61-e7e6ff0ee96d@github.com>
Message-ID: <c9P8rqkFtc6G1BswSZ83rXZBTGC_qdC6YZC1Weewzq4=.f14b7ad5-8218-4901-9e54-a4292c7a3810@github.com>

On Fri, 2 Feb 2024 02:22:54 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
>> The function returns the following structure:
>> 
>> 
>> typedef struct {
>>     jthread owner;
>>     jint entry_count;
>>     jint waiter_count;
>>     jthread* waiters;
>>     jint notify_waiter_count;
>>     jthread* notify_waiters;
>> } jvmtiMonitorUsage;
>> 
>> 
>> The following four fields are defined this way:
>> 
>> waiter_count  [jint] The number of threads waiting to own this monitor
>> waiters  [jthread*] The waiter_count waiting threads
>> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
>> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
>> 
>> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
>> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
>> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
>> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
>> This update makes it right.
>> 
>> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
>> 
>> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
>> 
>>   jvmti/GetObjectMonitorUsage/objmonusage001
>>   jvmti/GetObjectMonitorUsage/objmonusage003
>> 
>> 
>> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
>> 
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
>> 
>> 
>> 
>> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository by a separate sub-task before integration of this update.
>> 
>> Also, please see and review the related CSR:
>>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
>>  
>> Testing:
>>  - tested with mach5 tiers 1-6
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1553:
> 
>> 1551:             Handle th(current_thread, get_vthread_or_thread_oop(w));
>> 1552:             if (java_lang_Thread::get_thread_status(w->threadObj()) ==
>> 1553:                 JavaThreadStatus::BLOCKED_ON_MONITOR_ENTER) {
> 
> I don't think this is possible. `BLOCKED_ON_MONITOR_ENTER` is only set after the target has been removed from the wait-set and added to the cxq queue - see `ObjectMonitor::INotify`. As per the comment just above:
> 
> // If the thread was found on the ObjectWaiter list, then
> // it has not been notified.
> 
> which means it can't be trying to acquire the monitor either.

Thank you for looking at it and the comment, David! Will check what is possible here.
Do you have any suggestions?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1477954550

From aboldtch at openjdk.org  Mon Feb  5 10:36:06 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 5 Feb 2024 10:36:06 GMT
Subject: RFR: 8319801: Recursive lightweight locking: aarch64
 implementation [v13]
In-Reply-To: <xe8JA4mPencun9Vy6apQCn4ZNkk2WQ_39ohDs4gonZs=.1b5b8d37-daef-451b-8f51-a9e5bb3e2a2a@github.com>
References: <AE1nsnyRCUHR970jjg4feUm5f6E1GPJvea0ooC6dCgI=.73fff610-c0f6-422a-a45d-88187b37b9a2@github.com>
 <tQBTilK3gaS97w0nL4pgf76dt4EjWhWkiCQFZCLsA1w=.e0e98db1-1d55-481c-8419-dc225e872921@github.com>
 <xe8JA4mPencun9Vy6apQCn4ZNkk2WQ_39ohDs4gonZs=.1b5b8d37-daef-451b-8f51-a9e5bb3e2a2a@github.com>
Message-ID: <OPEbC1AmUbwWJ90BtOJNZ6r_twTzefDvRMrOXEMObI8=.d615f5ed-ff8f-41ee-8bc0-72a0f710820e@github.com>

On Mon, 5 Feb 2024 10:09:56 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Ping?
> 
> > The `testContendedLock` is showing so much Error that I can't take any of it seriously. However, there's no significant advantage for LL/SC, and therefore it should not be part of this patch.

Sorry should have sent a comment/reply as well but switched back to only use CAS instead of LL/SC in 3ec54648728e7d879bc5633536500c64fe79b80f

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

PR Comment: https://git.openjdk.org/jdk/pull/16608#issuecomment-1926673877

From aph at openjdk.org  Mon Feb  5 11:03:06 2024
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 5 Feb 2024 11:03:06 GMT
Subject: RFR: 8319801: Recursive lightweight locking: aarch64
 implementation [v13]
In-Reply-To: <tQBTilK3gaS97w0nL4pgf76dt4EjWhWkiCQFZCLsA1w=.e0e98db1-1d55-481c-8419-dc225e872921@github.com>
References: <AE1nsnyRCUHR970jjg4feUm5f6E1GPJvea0ooC6dCgI=.73fff610-c0f6-422a-a45d-88187b37b9a2@github.com>
 <tQBTilK3gaS97w0nL4pgf76dt4EjWhWkiCQFZCLsA1w=.e0e98db1-1d55-481c-8419-dc225e872921@github.com>
Message-ID: <MKV0x9o64AWGbHl10QOKupqeuk3RhQFasSd6DFz7zO0=.38d5a763-a821-4ce2-a3f4-2f9d0e64274f@github.com>

On Fri, 2 Feb 2024 10:20:40 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Implements the aarch64 port of JDK-8319796.
>> 
>> There are two major parts for the port implementation. The C2 part, and the part shared by the interpreter, C1 and the native call wrapper.
>> 
>> The biggest change for both parts is that we check the lock stack first and if it is a recursive lightweight [un]lock and in that case simply pop/push and finish successfully.
>> 
>> Only if the recursive lightweight [un]lock fails does it look at the mark word. 
>> 
>> For the shared part if it is an unstructured exit, the monitor is inflated or the mark word transition fails it calls into the runtime.
>> 
>> The C2 operates under a few more assumptions, that the locking is structured and balanced. This means that some checks can be elided. 
>> 
>> First this means that in C2 unlock if the obj is not on the top of the lock stack, it must be inflated. And reversely if we reach the inflated C2 unlock the obj is not on the lock stack. This second property makes it possible to avoid reading the owner (and checking if it is anonymous). Instead it can either just do an un-contended unlock by writing null to the owner, or if contention happens, simply write the thread to the owner and jump to the runtime. 
>> 
>> The aarch64 C2 port tries to avoid stronger memory semantics where ever possible. In C2 lock it first does a relaxed load of the mark word to check for inflation. Both lock and unlock uses a load/store exclusive register pair to transition the mark word.
>
> Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319801
>  - Update src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp
>    
>    Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>
>  - Clarify the rscratch1 assert
>  - Comments and nits
>  - Update copyright years
>  - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319801
>  - Drop memory order comments
>  - Preloads markWord unconditionally
>  - Revert "Add preload_mark to MacroAssembler::lightweight_lock"
>    
>    This reverts commit 8950f503aa5dba0e203613bd9737ea0d50388ca3.
>  - Add preload_mark to MacroAssembler::lightweight_lock
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/2d4d5e76...2d4ba75d

> > Ping?
> > > The `testContendedLock` is showing so much Error that I can't take any of it seriously. However, there's no significant advantage for LL/SC, and therefore it should not be part of this patch.
> 
> Sorry should have sent a comment/reply as well but switched back to only use CAS instead of LL/SC in [3ec5464](https://github.com/openjdk/jdk/commit/3ec54648728e7d879bc5633536500c64fe79b80f)

Great, thanks. I was wondering if this patch had got completely stuck.

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

PR Comment: https://git.openjdk.org/jdk/pull/16608#issuecomment-1926720405

From lkorinth at openjdk.org  Mon Feb  5 11:05:02 2024
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 5 Feb 2024 11:05:02 GMT
Subject: RFR: 8320750: Allow a testcase to run with multiple -Xlog
In-Reply-To: <LzqG8tmHZgoSqxPjEnULam9uGycRNpdBuPoUjXAdze0=.df98f685-7800-475e-ad3e-7d555c1470ea@github.com>
References: <LzqG8tmHZgoSqxPjEnULam9uGycRNpdBuPoUjXAdze0=.df98f685-7800-475e-ad3e-7d555c1470ea@github.com>
Message-ID: <7rk-ANNg8Q6mKiLMcjAR-ISWWxspNuTGRzPtH5cHXUg=.5fbbba6b-afb2-4aa9-8c92-62f6ab9e7353@github.com>

On Mon, 27 Nov 2023 13:32:52 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Running a testcase with muliple -Xlog crashes JTREG test cases. This is because `Collector.toMap` is not given a merge strategy.
> 
> When the same argument is passed multiple times, I have added a merge strategy to use the latter value. This is similar to how it is implemented for `vm.opt.*` in JTREG.
> 
> If the flag tested is `-Xlog`, replace the value part with a dummy value "NONEMPTY_TEST_SENTINEL". This is because in the case of multiple `-Xlog` all values are used, and JTREG does not give a satisfactory way to represent them. This dummy value should make it hard to try to `@require` on specific values by mistake.
> 
> Tested with:
> 
>  @requires vm.opt.x.Xlog == "NONEMPTY_TEST_SENTINEL"
>  @requires vm.opt.x.Xlog == "NONEMPTY_TEST_SENTINELXXX"
>  @requires vm.opt.x.Xms == "3g"
> 
> and
> 
> JAVA_OPTIONS=-Xms3g -Xms4g
> JAVA_OPTIONS=-Xms4g -Xms3g
> JAVA_OPTIONS=-Xlog:gc* -Xlog:gc*
> ``` 
> 
> Running tier1

Hi again, is there any opposition to me integrating this? If not I will integrate with only one reviewer (as this is not hotspot code). If I need to clarify the changes, I can and will do that.

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

PR Comment: https://git.openjdk.org/jdk/pull/16824#issuecomment-1926723750

From ayang at openjdk.org  Mon Feb  5 11:19:10 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 5 Feb 2024 11:19:10 GMT
Subject: RFR: 8325221: Obsolete TLABStats
Message-ID: <OgGNoY6jWx3-W6IN8vOEoFRUvW9s7i3QE8LZw1tlZgQ=.7a7e456c-8180-484d-aa27-e2f4cb43c362@github.com>

Simple obsoletion of a jvm flag.

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

Commit messages:
 - obsolete

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

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

From jsjolen at openjdk.org  Mon Feb  5 12:58:03 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 5 Feb 2024 12:58:03 GMT
Subject: RFR: 8320750: Allow a testcase to run with multiple -Xlog
In-Reply-To: <LzqG8tmHZgoSqxPjEnULam9uGycRNpdBuPoUjXAdze0=.df98f685-7800-475e-ad3e-7d555c1470ea@github.com>
References: <LzqG8tmHZgoSqxPjEnULam9uGycRNpdBuPoUjXAdze0=.df98f685-7800-475e-ad3e-7d555c1470ea@github.com>
Message-ID: <CkWSO_4e4SvM5T3mbOMkjiXvHzBA1lhqc0H1c7BT0Hs=.912b1673-8791-4313-8d5a-7497b2cbc38b@github.com>

On Mon, 27 Nov 2023 13:32:52 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Running a testcase with muliple -Xlog crashes JTREG test cases. This is because `Collector.toMap` is not given a merge strategy.
> 
> When the same argument is passed multiple times, I have added a merge strategy to use the latter value. This is similar to how it is implemented for `vm.opt.*` in JTREG.
> 
> If the flag tested is `-Xlog`, replace the value part with a dummy value "NONEMPTY_TEST_SENTINEL". This is because in the case of multiple `-Xlog` all values are used, and JTREG does not give a satisfactory way to represent them. This dummy value should make it hard to try to `@require` on specific values by mistake.
> 
> Tested with:
> 
>  @requires vm.opt.x.Xlog == "NONEMPTY_TEST_SENTINEL"
>  @requires vm.opt.x.Xlog == "NONEMPTY_TEST_SENTINELXXX"
>  @requires vm.opt.x.Xms == "3g"
> 
> and
> 
> JAVA_OPTIONS=-Xms3g -Xms4g
> JAVA_OPTIONS=-Xms4g -Xms3g
> JAVA_OPTIONS=-Xlog:gc* -Xlog:gc*
> ``` 
> 
> Running tier1

test/jtreg-ext/requires/VMProps.java line 732:

> 730:      * Multiple invocations of the same flag will overwrite the flag
> 731:      * value with the latest value. Except for -Xlog where the value
> 732:      * will always be NONEMPTY_TEST_SENTINEL (when pressent).

Can you fix the typo "pressent" to "present"?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16824#discussion_r1478186697

From fbredberg at openjdk.org  Mon Feb  5 15:29:36 2024
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Mon, 5 Feb 2024 15:29:36 GMT
Subject: RFR: 8322535: Change default AArch64 SpinPause instruction [v2]
In-Reply-To: <JV7H6vybR8ANCBume69ImM9-bnYpiGpWMfhnzm_hz1I=.51c5bd49-ede4-43b4-8ea0-522b5a70a98d@github.com>
References: <JV7H6vybR8ANCBume69ImM9-bnYpiGpWMfhnzm_hz1I=.51c5bd49-ede4-43b4-8ea0-522b5a70a98d@github.com>
Message-ID: <OsC2nv6OmkEApnjjW6cwEa5G2wBAtdz8TZjP_aY0k-M=.4a72be80-cef9-4a13-af33-7a2007f1a230@github.com>

> The Java options OnSpinWaitInst lets you choose which AArch64 instruction should be used in `SpinPause()`. Valid values are "none", "nop", "isb" and "yield". Today the default value for OnSpinWaitInst is unfortunately "none".
> 
> However some CPUs changes the default SpinPause instruction to something better if the user hasn't used the OnSpinWaitInst option. For instance if you run a Neoverse N1, N2, V1 or V2, the default SpinPause instruction will be changed to "isb". After doing some measurements on Apple's M1-M3 CPUs it also seems like "isb" is the best yielding instruction on on those CPUs.
> 
> This PR changes the default SpinPause instruction to "yield" on all AArch64 platforms except on Apple's M1, M2 and M3 CPUs on which the default value will be "isb".
> 
> Tested tier1-tier7 successfully on linux-aarch64 and macosx-aarch64.

Fredrik Bredberg 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:

 - Removed isb as default SpinPause instruction for Apple silicon
 - Merge branch 'master' into 8322535_default_spinpause_inst
 - Merge branch 'master' into 8322535_default_spinpause_inst
 - 8322535: Change default AArch64 SpinPause instruction

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17430/files
  - new: https://git.openjdk.org/jdk/pull/17430/files/21fb5d26..c839a3da

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

  Stats: 51437 lines in 2089 files changed: 24772 ins; 12372 del; 14293 mod
  Patch: https://git.openjdk.org/jdk/pull/17430.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17430/head:pull/17430

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

From erik.osterlund at oracle.com  Mon Feb  5 15:35:21 2024
From: erik.osterlund at oracle.com (Erik Osterlund)
Date: Mon, 5 Feb 2024 15:35:21 +0000
Subject: RFC: CDS Streaming object loader
Message-ID: <74112770-89E8-4D35-84E1-2F6E415B4D4F@oracle.com>

Hi,

I heard from Stefan Karlsson that there was some interest among several committers external to Oracle
 (Thomas St?fe, and some more) from OCW about what I?m currently doing with a new streaming object
loader for CDS. Sounded like some people would like a bit more visibility into it. So this isn?t at all a
review request, but more of a heads-up about what I?m working on, for any interested readers.

First of all, the state of my work is that it?s a prototype that I?m trying to iron out rough corners on, and
upstream it to mainline. I?m getting closer, but I don?t mind giving a sneak peak at the current state right
now. It might look a bit messy though.
PR:  https://github.com/fisk/jdk/commits/8310823_object_streaming/
Bug tracking the changes: https://bugs.openjdk.org/browse/JDK-8310823

The spirit of the new mechanism is being GC agnostic and loading and linking on object granularity,
letting the GC decide how to lay it all out in the heap. Indeed, it works for all our GCs. However, the
 initial plan I have, is to enable it for ZGC. We don?t have any object loader that works with ZGC at all
today, so this will be an obvious improvement when using ZGC. As for the other GCs with a loader, we
have something that already works, and I?d like to give the new mechanism some mileage, especially in
combination with things cooking in Leyden, before we make any decisions at all about what to do about
 the existing solution. Heuristically though, I?m turning on the new mode when dumping an archive without
 compressed oops, because then anyone can load from that format, regardless of GC choice, indeed
 including ZGC. That seems to make sense to me.

The streaming archive heap loader loads Java objects using normal allocations. It requires the objects
to be ordered in DFS order already at dump time, given the set of roots into the archived heap.
Since the objects are ordered in DFS order, that means that walking them linearly through the archive
is equivalent to performing a DFS traversal, but without pushing and popping anything.

The advantage of this pre-ordering, other than the obvious locality improvement, is that we can have
a separate thread, the CDSThread, perform this walk, in a way that allows us to split the archived
heap into three separate zones. The first zone contains objects that have been transitively materialized,
the second zone contains objects that are currently being materialized, and the last zone contains
objects that have not and are not about to be touched by the CDS thread.
Whenever a new root is traversed by the CDS thread, the zones are shifted atomically under a lock.

ASCII visualization of the three zones:

|      transitively materialized        |       currently materializing        |        not yet materialized         |

Being able to split the memory into these three zones, allows the bootstrapping thread and potential
other threads to be able to, under a lock, traverse a root, and know how to coordinate with the
concurrent CDS thread. Whenever the traversal finds an object in the "transitively materialized"
zone, then we know such objects don't need any processing at all. As for "currently materializing",
we know that if we just stay out of the way and let the CDSThread finish its current root, then
the transitive closure of such objects will be materialized. And the CDSThread can materialize faster
then the rest as it doesn't need to perform any traversal. Finally, as for objects in the "not yet
materialized" zone, we know that we can trace through it without stepping on the feed of the CDSThread
which has published it won't be tracing anything in there.

What we get from this, is fast iterative traversal from the CDS thread (IterativeObjectLoader)
while allowing lazyness and concurrency with the rest of the program (TracingObjectLoader).
This way the CDS thread can remove the bulk of the work of materializing the Java objects from
the critical bootstrapping thread.

When we start materializing objects, we have not yet come to the point in the bootstrapping where
GC is allowed. This is a two edged sword. On the one hand side, we can materialize objects faster
when we know there is no GC to coordinate with, but on the other hand side, if we need to perform
a GC when allocating memory for archived objects, we will bring down the entire JVM. To deal with this,
the CDS thread asks the GC for a budget of bytes it is allowed to allocate before GC is allowed.
When we get to the point in the bootstrapping where GC is allowed, we resume materializing objects
that didn't fit in the budget. Before we let the application run, we force materialization of any
remaining objects that have not been materialized by the CDS thread yet, so that we don't get
surprising OOMs due to object materialization while the program is running.

The object format of the archived heap is similar to a normal object. However, references are encoded
as DFS indices, which in the end map to what index the object is in the buffer, as they are laid out
in DFS order. The DFS indices start at 1 for the first object, and hence the number 0 represents
null. The DFS index of objects is a core identifier of objects in this approach. From this index
it is possible to find out what offset the archived object has into the buffer, as well as finding
mappings to Java heap objects that have been materialized.

The table mapping DFS indices to Java heap objects is filled in when an object is allocated.
Materializing objects involves allocating the object, initializing it, and linking it with other
objects. Since linking the object requires whatever is being referenced to be at least allocated,
the iterative traversal will first allocate all of the objects in its zone being worked on, and then
perform initialization and linking in a second pass. What these passes have in common is that they
are trivially parallelizable, should we ever need to do that. The tracing materialization links
objects when going "back" in the DFS traversal.

The forwarding information for the mechanism contains raw oops before GC is allowed, and as we
enable GC in the bootstrapping, all raw oops are handleified using OopStorage. All handles are
handed back from the CDS thread when materialization has finished. The switch from raw oops to
using OopStorage handles, happens under a lock while no iteration nor tracing is allowed.

The initialization code is also performed in a faster way when the GC is not allowed. In particular,
before GC is allowed, we perform raw memcpy of the archived object into the Java heap. Then the
object is initialized with IS_DEST_UNINITIALIZED stores. The assumption made here is that before
any GC activity is allowed, we shouldn't have to worry about concurrent GC threads scanning the
memory and getting tripped up by that. Once GC is enabled, we revert to a bit more careful approach
that uses a pre-computed bitmap to find the holes where oops go, and carefully copy only the
non-oop information with memcpy, while the oops are set separately with HeapAccess stores that
should be able to cope well with concurrent activity.

The same bitmap that tracks where there are oops, is reused also for signalling which string
objects should be interned. From the dump, some referenced strings were interned. This is
really an identity property. We don't need to dump the entire string table as a way of communicating
this identity property. Instead we intern strings on-the-fly, exploiting the dynamic object
level linking that this approach has chosen to our advantage.

An advantage of separating the on-disk object format descriptions from the in-memory format in the
heap, is that the objects can also be compressed in the disk format. I haven?t explored this yet, but
I suspect it can be quite beneficial for cold starts, at a cost of warm starts probably performing a bit worse.

I?m currently working my way through tests to get things looking green, as well as cleaning up the
code to prepare it for eventual upstreaming.

In terms of results, as long as my CDS thread gets a core to run on, startup latency for the
bootstrapping thread is ~1 ms, even when the archive gets inflated to ~5 MB. The concurrent
thread soaks up ~11 ms worth of work that is performed efficiently way before we are about to
start running any user code really.

If anyone has any feedback or wants to help exploring for example compression or something like that,
feel free to help out if you think it sounds interesting. Another thing I know is very helpful is to map the
CDS regions with MAP_POPULATE when available. That?s also something I wouldn?t mind help with
upstreaming, if anyone is interested in having a look at that.

Either way, hope making the current thoughts on this visible in this relatively early stage, is helpful.
I?m open to any feedback, if there is any. Hope people like the approach.

Thanks,
/Erik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20240205/535fe500/attachment-0001.htm>

From eosterlund at openjdk.org  Mon Feb  5 15:40:03 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 5 Feb 2024 15:40:03 GMT
Subject: RFR: 8322535: Change default AArch64 SpinPause instruction [v2]
In-Reply-To: <OsC2nv6OmkEApnjjW6cwEa5G2wBAtdz8TZjP_aY0k-M=.4a72be80-cef9-4a13-af33-7a2007f1a230@github.com>
References: <JV7H6vybR8ANCBume69ImM9-bnYpiGpWMfhnzm_hz1I=.51c5bd49-ede4-43b4-8ea0-522b5a70a98d@github.com>
 <OsC2nv6OmkEApnjjW6cwEa5G2wBAtdz8TZjP_aY0k-M=.4a72be80-cef9-4a13-af33-7a2007f1a230@github.com>
Message-ID: <Rbo90BToauN9eYQAPWHdEFOgjHkDxaI7xSPn5yrrong=.24556399-9e80-4f2d-9d3f-46af3b32e7a7@github.com>

On Mon, 5 Feb 2024 15:29:36 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> The Java options OnSpinWaitInst lets you choose which AArch64 instruction should be used in `SpinPause()`. Valid values are "none", "nop", "isb" and "yield". Today the default value for OnSpinWaitInst is unfortunately "none".
>> 
>> However some CPUs changes the default SpinPause instruction to something better if the user hasn't used the OnSpinWaitInst option. For instance if you run a Neoverse N1, N2, V1 or V2, the default SpinPause instruction will be changed to "isb". After doing some measurements on Apple's M1-M3 CPUs it also seems like "isb" is the best yielding instruction on on those CPUs.
>> 
>> This PR changes the default SpinPause instruction to "yield" on all AArch64 platforms except on Apple's M1, M2 and M3 CPUs on which the default value will be "isb".
>> 
>> Tested tier1-tier7 successfully on linux-aarch64 and macosx-aarch64.
>
> Fredrik Bredberg 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:
> 
>  - Removed isb as default SpinPause instruction for Apple silicon
>  - Merge branch 'master' into 8322535_default_spinpause_inst
>  - Merge branch 'master' into 8322535_default_spinpause_inst
>  - 8322535: Change default AArch64 SpinPause instruction

Marked as reviewed by eosterlund (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17430#pullrequestreview-1863121833

From aboldtch at openjdk.org  Mon Feb  5 15:50:08 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 5 Feb 2024 15:50:08 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v6]
In-Reply-To: <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
Message-ID: <SRV5dch2yCa_0V3zfAtGQcShXFVzIQfoZojLiKaPxFs=.47d544fa-c4e4-4c6e-a473-74a4f13da3ef@github.com>

On Tue, 30 Jan 2024 09:08:01 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> ICStubs solve an atomicity problem when setting both the destination and data of an inline cache. Unfortunately, it also leads to occasional safepoint carpets when multiple threads need to ICRefill the stubs at the same time, and spurious GuaranteedSafepointInterval "Cleanup" safepoints every second. This patch changes inline caches to not change the data part at all during the nmethod life cycle, hence removing the need for ICStubs.
>> 
>> The new scheme is less stateful. Instead of adding and removing callsite metadata back and forth when transitioning inline cache states, it installs all state any shape of call will ever need at resolution time in a struct that I call CompiledICData. This reduces inline cache state changes to simply changing the destination of the call, and it doesn't really matter what state transitions to what other state.
>> 
>> With this patch, we get rid of ICStub and ICBuffer classes and the related ICRefill and almost all Cleanup safepoints in practice. It also makes the inline cache code much simpler.
>> 
>> I have tested the changes from tier1-7, and run through full aurora performance tests.
>
> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ARM32 fixes

All my comments have been addressed. 
As previously mentioned as long as the performance is there, then this looks good.

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

Marked as reviewed by aboldtch (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17495#pullrequestreview-1863145854

From redestad at openjdk.org  Mon Feb  5 16:33:11 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 5 Feb 2024 16:33:11 GMT
Subject: Integrated: 8321468: Remove StringUTF16::equals
In-Reply-To: <CySSsfGkTiz_6q09rb7VCW_rGwin9V8NN-Ugh8Wltds=.9a4652c2-4b0a-4644-8a48-f9ee6dd5abc4@github.com>
References: <CySSsfGkTiz_6q09rb7VCW_rGwin9V8NN-Ugh8Wltds=.9a4652c2-4b0a-4644-8a48-f9ee6dd5abc4@github.com>
Message-ID: <dnDrNPdofA4zqn6SHVr4BmG4ikY-TUKEM8p2Q7Zpmfc=.2bf8e457-525e-456c-9e53-bab4f6286792@github.com>

On Wed, 6 Dec 2023 14:20:14 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8215017 removed the only use of `StringUTF16::equals`. At the time I did some performance verification focused on x86 showing that simplifying and only using `StringLatin1::equals` was either neutral or a win. 
> 
> I repeated this experiment recently, adding some focused tests on aarch64 where the code generation actually tries to take advantage and generate slightly more efficient code for `StringUTF16::equals`: 
> https://github.com/openjdk/jdk/pull/16933#discussion_r1414118658
> 
> The indication here is that disabling use of `StringUTF16::equals` was the right choice: any effect from the low-level optimization (one less branch at the tail end) was offset by the `isLatin1()` branch and added code generation (that all gets inlined).
> 
> In a `-XX:-CompactStrings` configuration the slightly improved code generation in `StringUTF16::equals` might help, since the `isLatin1()` test and subsequent call to `StringLatin1::equals` would be DCEd. To get the best of both worlds the code in `String::equals` _could_ be sharpened so that we statically pick the best implementation based on `CompactStrings` mode (see comment below). This shows a tiny win when testing with `-XX:-CompactStrings` on M1 (up to -0.2ns/op per `String::equals`; neutral on x86). But is all this complexity worth it for a gain that will get lost in the noise on anything realistic?
> 
> This PR instead proposes removing `StringUTF16::equals` and simplifying the mechanisms to support the `StringLatin1/UTF16::equals` pair of intrinsics in hotspot.

This pull request has now been integrated.

Changeset: 55c1446b
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/55c1446b68db6c4734420124b5f26278389fdf2b
Stats:     138 lines in 14 files changed: 0 ins; 113 del; 25 mod

8321468: Remove StringUTF16::equals

Reviewed-by: rriggs, kvn

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

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

From redestad at openjdk.org  Mon Feb  5 16:33:10 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 5 Feb 2024 16:33:10 GMT
Subject: RFR: 8321468: Remove StringUTF16::equals
In-Reply-To: <CySSsfGkTiz_6q09rb7VCW_rGwin9V8NN-Ugh8Wltds=.9a4652c2-4b0a-4644-8a48-f9ee6dd5abc4@github.com>
References: <CySSsfGkTiz_6q09rb7VCW_rGwin9V8NN-Ugh8Wltds=.9a4652c2-4b0a-4644-8a48-f9ee6dd5abc4@github.com>
Message-ID: <DK1IxCKZUfncsvZ6GPz_NZHKll-nyE58pklcCixX32o=.d44a7f9a-352f-41a0-9ccd-bcc8a3669213@github.com>

On Wed, 6 Dec 2023 14:20:14 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8215017 removed the only use of `StringUTF16::equals`. At the time I did some performance verification focused on x86 showing that simplifying and only using `StringLatin1::equals` was either neutral or a win. 
> 
> I repeated this experiment recently, adding some focused tests on aarch64 where the code generation actually tries to take advantage and generate slightly more efficient code for `StringUTF16::equals`: 
> https://github.com/openjdk/jdk/pull/16933#discussion_r1414118658
> 
> The indication here is that disabling use of `StringUTF16::equals` was the right choice: any effect from the low-level optimization (one less branch at the tail end) was offset by the `isLatin1()` branch and added code generation (that all gets inlined).
> 
> In a `-XX:-CompactStrings` configuration the slightly improved code generation in `StringUTF16::equals` might help, since the `isLatin1()` test and subsequent call to `StringLatin1::equals` would be DCEd. To get the best of both worlds the code in `String::equals` _could_ be sharpened so that we statically pick the best implementation based on `CompactStrings` mode (see comment below). This shows a tiny win when testing with `-XX:-CompactStrings` on M1 (up to -0.2ns/op per `String::equals`; neutral on x86). But is all this complexity worth it for a gain that will get lost in the noise on anything realistic?
> 
> This PR instead proposes removing `StringUTF16::equals` and simplifying the mechanisms to support the `StringLatin1/UTF16::equals` pair of intrinsics in hotspot.

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/16995#issuecomment-1927385726

From dlong at openjdk.org  Mon Feb  5 23:50:32 2024
From: dlong at openjdk.org (Dean Long)
Date: Mon, 5 Feb 2024 23:50:32 GMT
Subject: RFR: 8324833: Signed integer overflows in ABS [v3]
In-Reply-To: <6kxKhJVXB2X7ni4SLMtL--Pt5O8bUOazcI9F3FJgG8o=.55b0e9bd-075c-4b76-bcc6-732951e8a512@github.com>
References: <ohwAn6GqM7FIgYTJNy40VBYSCVEBrrNSqBaz2akN54M=.f9660235-3047-47ee-aad0-ef598d6ebdcc@github.com>
 <6kxKhJVXB2X7ni4SLMtL--Pt5O8bUOazcI9F3FJgG8o=.55b0e9bd-075c-4b76-bcc6-732951e8a512@github.com>
Message-ID: <a91fiKxlZb2seS1Ql2geW4NppZTHNaPeQhxjGpcYjsk=.652f08c0-a72f-4f3d-9639-ac489b1b4eac@github.com>

On Fri, 2 Feb 2024 09:47:28 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the details in the bug. I think current `ABS` implementation is beyond repair, and we should just switch to `uabs`.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug, `all` with `-ftrapv` (now fully passes!)
>>  - [x] Linux x86_64 fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Touchups

The undefined behavior I was talking about is what abs(INT_MIN) returns on two's complement, and the problem with checked_cast is that checked_cast<int,uint>(0x80000000u) won't complain, because the bits match, but having the sign change to negative may not be what the caller wants, especially when using ABS.

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

PR Comment: https://git.openjdk.org/jdk/pull/17617#issuecomment-1928053407

From never at openjdk.org  Mon Feb  5 23:51:13 2024
From: never at openjdk.org (Tom Rodriguez)
Date: Mon, 5 Feb 2024 23:51:13 GMT
Subject: RFR: 8317368: [JVMCI] SIGSEGV in JVMCIEnv::initialize_installed_code
 on libgraal
Message-ID: <mjkX-rG6apf-VSRRuovOjK5kjPilRLXTQBnGz2y2D8I=.08dcce97-ac29-4b61-913c-29dd7429f0aa@github.com>

This fixes some lurking issues with JVMCI and nmethod related both BarrierSetNMethod and the garbage collection of nmethods.  In particular the stack walking in c2v_iterateFrames visits many frames and needs a KeepStackGCProcessedMark for safety.  Additionally, JVMCI interacts with nmethods in complex ways and needs some sort of strong root during these interactions.  A new JavaThread field has been added that mirrors the way JVMTI keeps nmethods alive.

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

Commit messages:
 - Move BarrierSetNMethod call into JVMCINMethodHandle::set_nmethod
 - 8317368: [JVMCI] SIGSEGV in JVMCIEnv::initialize_installed_code on libgraal

Changes: https://git.openjdk.org/jdk/pull/17714/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17714&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317368
  Stats: 92 lines in 7 files changed: 72 ins; 8 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/17714.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17714/head:pull/17714

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

From eosterlund at openjdk.org  Mon Feb  5 23:51:34 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 5 Feb 2024 23:51:34 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v6]
In-Reply-To: <SRV5dch2yCa_0V3zfAtGQcShXFVzIQfoZojLiKaPxFs=.47d544fa-c4e4-4c6e-a473-74a4f13da3ef@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
 <SRV5dch2yCa_0V3zfAtGQcShXFVzIQfoZojLiKaPxFs=.47d544fa-c4e4-4c6e-a473-74a4f13da3ef@github.com>
Message-ID: <jQw7UcewZi0_XLKLezFOHziWNrIi9CGH1aVTJwsBeKU=.fc2ae3dd-04ff-4cda-83f3-1cf2cf505766@github.com>

On Mon, 5 Feb 2024 15:47:29 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> All my comments have been addressed. 
> 
> As previously mentioned as long as the performance is there, then this looks good.

Thanks for the review, @xmas92. Any other takers?

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

PR Comment: https://git.openjdk.org/jdk/pull/17495#issuecomment-1928143097

From pchilanomate at openjdk.org  Mon Feb  5 23:52:11 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 5 Feb 2024 23:52:11 GMT
Subject: RFR: 8320302: compiler/arguments/TestC1Globals.java hits SIGSEGV
 in ContinuationEntry::set_enter_code [v3]
In-Reply-To: <1Cm1SGGaZsYxM-RfPNDeAvnGijQ-taVe438SS6bZ3YI=.d64abde2-f9a0-4589-ab40-eba7c3c02992@github.com>
References: <1Cm1SGGaZsYxM-RfPNDeAvnGijQ-taVe438SS6bZ3YI=.d64abde2-f9a0-4589-ab40-eba7c3c02992@github.com>
Message-ID: <9mMLOqVHnFrYcKY5FLgIwd_j9RQtk68s9vdqaABGt_o=.bd743e24-484e-4120-9be3-a81f7022d332@github.com>

> When creating Continuation.enterSpecial/doYield special native nmethods we currently assume the call to nmethod::new_native_nmethod() always succeeds. If the CodeCache happens to be full though, creating the nmethod will fail and we'll hit a SIGSEGV when trying to dereference the return value. 
> 
> Since this happens the first time those methods are resolved, throwing an exception at that point implying that we cannot run virtual threads looks odd from a user perspective. So instead I added a step to initialize the Continuation class at startup so that failure to create those nmethods is treated early as a fatal error as we do with any other critical resource needed by the VM. I measured the added step to the startup sequence to be ~90us, or about 0.3% of the total?startup time.
> 
> I verified the fix by running the test mentioned in the bug plus I also run tiers1-5 in mach5.
> 
> Thanks,
> Patricio

Patricio Chilano Mateo 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 JDK-8320302
 - use vm_exit_during_initialization instead of fatal
 - inline call to initialize cont class
 - v1

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17455/files
  - new: https://git.openjdk.org/jdk/pull/17455/files/be77c877..3c96d8ae

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

  Stats: 34174 lines in 1737 files changed: 16155 ins; 5201 del; 12818 mod
  Patch: https://git.openjdk.org/jdk/pull/17455.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17455/head:pull/17455

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

From amenkov at openjdk.org  Mon Feb  5 23:57:22 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Mon, 5 Feb 2024 23:57:22 GMT
Subject: Integrated: JDK-8318566: Heap walking functions should not use
 FilteredFieldStream
In-Reply-To: <OAXy0kdJSDJ3b4TPhYjHBHbemHVhd40WzY-1j32rSP8=.f9c73209-0667-4f3e-9f38-e4a20c271c29@github.com>
References: <OAXy0kdJSDJ3b4TPhYjHBHbemHVhd40WzY-1j32rSP8=.f9c73209-0667-4f3e-9f38-e4a20c271c29@github.com>
Message-ID: <gB8Rgu2xeKScsGcSz_dlQSOWyPS4V2Fl8s9SKYLmTCs=.3eab06ed-838c-4159-b427-e46e4795e674@github.com>

On Wed, 31 Jan 2024 21:28:34 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> FilteredFieldStream used by heap walking functions to iterate through klass/superclasses/interfaces fields are known to have poor performance (see [JDK-8317692](https://bugs.openjdk.org/browse/JDK-8317692) for details).
> Heap walking API implementation is the last user of the klasses.
> The fix reworks iteration through klass/superclasses/interfaces fields and drops FilteredFieldStream-related code.
> Additionally removed/updated includes of reflectionUtils.hpp.
> 
> Testing:
>   - tier1..4;
>   - test/hotspot/jtreg/vmTestbase/nsk/jvmti (contains tests for different heap walking functions);
>   - new test from #17580 (now the test runs several times faster).

This pull request has now been integrated.

Changeset: fd3042a0
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fd3042a04b2d76180cb90f688e8b33156fdf3d18
Stats:     272 lines in 10 files changed: 27 ins; 221 del; 24 mod

8318566: Heap walking functions should not use FilteredFieldStream

Reviewed-by: cjplummer, sspitsyn

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

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

From duke at openjdk.org  Mon Feb  5 23:58:33 2024
From: duke at openjdk.org (duke)
Date: Mon, 5 Feb 2024 23:58:33 GMT
Subject: Withdrawn: 8312425: [vectorapi] AArch64: Optimize vector math
 operations with SLEEF
In-Reply-To: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
Message-ID: <C13TewWQ_H-Jq44YTNJbvNHU3rHmzz0FR9sAMHsnbZQ=.568298f5-82a2-4a88-9444-c64477af020d@github.com>

On Wed, 18 Oct 2023 06:12:29 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]).
> 
> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead.
> 
> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly.
> 
> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts.
> 
> [1] https://github.com/openjdk/jdk/pull/3638
> [2] https://sleef.org/
> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/
> [4] https://packages.debian.org/bookworm/libsleef3
> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Mon Feb  5 23:59:20 2024
From: duke at openjdk.org (duke)
Date: Mon, 5 Feb 2024 23:59:20 GMT
Subject: Withdrawn: 8316180: Thread-local backoff for secondary_super_cache
 updates
In-Reply-To: <i7ObyN2vlRF62E0UpHD2qzFlbp95vnNTW-0SQDYg3yY=.a58d6d86-c743-4415-a60c-5affe653b72f@github.com>
References: <i7ObyN2vlRF62E0UpHD2qzFlbp95vnNTW-0SQDYg3yY=.a58d6d86-c743-4415-a60c-5affe653b72f@github.com>
Message-ID: <3wvi86Xrnn5clZnVqx-R6CIu3F1PuXo29aLPns6bVVU=.855700d6-3377-4e85-ae5e-603e6969704d@github.com>

On Wed, 13 Sep 2023 14:02:19 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See more details in the bug and related issues.
> 
> This is the attempt to mitigate [JDK-8180450](https://bugs.openjdk.org/browse/JDK-8180450), while the more complex fix that would obviate the need for `secondary_super_cache` is being worked out. The goal for this fix is to improve performance in pathological cases, while keeping non-pathological cases out of extra risk, *and* staying simple enough and reliable for backports to currently supported JDK releases.
> 
> This implements mitigation on most current architectures:
>   - ? x86_64: implemented
>   - ? x86_32: considered, abandoned; cannot be easily done without blowing up code size
>   - ? AArch64: implemented
>   - ? ARM32: considered, abandoned; needs cleanups and testing; see [JDK-8318414](https://bugs.openjdk.org/browse/JDK-8318414)
>   - ? PPC64: implemented, thanks @TheRealMDoerr 
>   - ? S390: implemented, thanks @offamitkumar 
>   - ? RISC-V: implemented, thanks @RealFYang 
>   - ? Zero: does not need implementation
> 
> Note that the code is supposed to be rather compact, because it is inlined in generated code. That is why, for example, we cannot easily do x86_32 version: we need a thread, so the easiest way would be to call into VM. But we cannot that easily: the code blowout would make some forward branches in external code non-short. I think we we cannot implement this mitigation on some architectures, so be it, it would be a sensible tradeoff for simplicity.
> 
> Setting backoff at `0` effectively disables the mitigation, and gives us safety hatch if something goes wrong.
> 
> I believe we can go in with `1000` as the default, given the experimental results mentioned in this PR.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, `tier1 tier2 tier3`
>  - [x] Linux AArch64 fastdebug, `tier1 tier2 tier3`

This pull request has been closed without being integrated.

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

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

From never at openjdk.org  Tue Feb  6 01:10:07 2024
From: never at openjdk.org (Tom Rodriguez)
Date: Tue, 6 Feb 2024 01:10:07 GMT
Subject: RFR: 8317368: [JVMCI] SIGSEGV in
 JVMCIEnv::initialize_installed_code on libgraal [v2]
In-Reply-To: <mjkX-rG6apf-VSRRuovOjK5kjPilRLXTQBnGz2y2D8I=.08dcce97-ac29-4b61-913c-29dd7429f0aa@github.com>
References: <mjkX-rG6apf-VSRRuovOjK5kjPilRLXTQBnGz2y2D8I=.08dcce97-ac29-4b61-913c-29dd7429f0aa@github.com>
Message-ID: <eupd4UgZty_Vwn0ZkqB37ldOTbSB_Qcw3Cbs2otHJMA=.101bde4c-f2f7-4fcd-a879-3a0cf4eea5fb@github.com>

> This fixes some lurking issues with JVMCI and nmethod related both BarrierSetNMethod and the garbage collection of nmethods.  In particular the stack walking in c2v_iterateFrames visits many frames and needs a KeepStackGCProcessedMark for safety.  Additionally, JVMCI interacts with nmethods in complex ways and needs some sort of strong root during these interactions.  A new JavaThread field has been added that mirrors the way JVMTI keeps nmethods alive.

Tom Rodriguez has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Merge branch 'master' into tkr-nmethod-keep-alive
 - Move BarrierSetNMethod call into JVMCINMethodHandle::set_nmethod
 - 8317368: [JVMCI] SIGSEGV in JVMCIEnv::initialize_installed_code on libgraal

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

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

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

From dholmes at openjdk.org  Tue Feb  6 05:18:00 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 6 Feb 2024 05:18:00 GMT
Subject: RFR: 8320302: compiler/arguments/TestC1Globals.java hits SIGSEGV
 in ContinuationEntry::set_enter_code [v3]
In-Reply-To: <9mMLOqVHnFrYcKY5FLgIwd_j9RQtk68s9vdqaABGt_o=.bd743e24-484e-4120-9be3-a81f7022d332@github.com>
References: <1Cm1SGGaZsYxM-RfPNDeAvnGijQ-taVe438SS6bZ3YI=.d64abde2-f9a0-4589-ab40-eba7c3c02992@github.com>
 <9mMLOqVHnFrYcKY5FLgIwd_j9RQtk68s9vdqaABGt_o=.bd743e24-484e-4120-9be3-a81f7022d332@github.com>
Message-ID: <6eYoo4WQi_LO5YFtxZQbpxFeNxQFnpTjgfIvyPukWNA=.1448ac51-5e4a-43f3-ae17-aa5eeeee0538@github.com>

On Mon, 5 Feb 2024 23:52:11 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> When creating Continuation.enterSpecial/doYield special native nmethods we currently assume the call to nmethod::new_native_nmethod() always succeeds. If the CodeCache happens to be full though, creating the nmethod will fail and we'll hit a SIGSEGV when trying to dereference the return value. 
>> 
>> Since this happens the first time those methods are resolved, throwing an exception at that point implying that we cannot run virtual threads looks odd from a user perspective. So instead I added a step to initialize the Continuation class at startup so that failure to create those nmethods is treated early as a fatal error as we do with any other critical resource needed by the VM. I measured the added step to the startup sequence to be ~90us, or about 0.3% of the total?startup time.
>> 
>> I verified the fix by running the test mentioned in the bug plus I also run tiers1-5 in mach5.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo 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 JDK-8320302
>  - use vm_exit_during_initialization instead of fatal
>  - inline call to initialize cont class
>  - v1

src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp line 1747:

> 1745:                                               oop_maps,
> 1746:                                               exception_offset);
> 1747:     if (nm == nullptr) vm_exit_during_initialization("Initial size of CodeCache is too small");

IIUC `AdapterHandlerLibrary::create_native_wrapper`  is the only caller of `generate_native_wrapper` so it is only called during VM init now. But not sure it wouldn't be better/cleaner to simply return nullptr here and have `AdapterHandlerLibrary::create_native_wrapper` do the `vm_exit_during_initialization`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17455#discussion_r1479230718

From dholmes at openjdk.org  Tue Feb  6 05:29:00 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 6 Feb 2024 05:29:00 GMT
Subject: RFR: 8320750: Allow a testcase to run with multiple -Xlog
In-Reply-To: <LzqG8tmHZgoSqxPjEnULam9uGycRNpdBuPoUjXAdze0=.df98f685-7800-475e-ad3e-7d555c1470ea@github.com>
References: <LzqG8tmHZgoSqxPjEnULam9uGycRNpdBuPoUjXAdze0=.df98f685-7800-475e-ad3e-7d555c1470ea@github.com>
Message-ID: <IS8s1Xp6quE2a8CEBDDvvkjM7YNlefT2CxAPPouVdvA=.2813b9db-d5b8-4b14-bc12-7dcf38216237@github.com>

On Mon, 27 Nov 2023 13:32:52 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Running a testcase with muliple -Xlog crashes JTREG test cases. This is because `Collector.toMap` is not given a merge strategy.
> 
> When the same argument is passed multiple times, I have added a merge strategy to use the latter value. This is similar to how it is implemented for `vm.opt.*` in JTREG.
> 
> If the flag tested is `-Xlog`, replace the value part with a dummy value "NONEMPTY_TEST_SENTINEL". This is because in the case of multiple `-Xlog` all values are used, and JTREG does not give a satisfactory way to represent them. This dummy value should make it hard to try to `@require` on specific values by mistake.
> 
> Tested with:
> 
>  @requires vm.opt.x.Xlog == "NONEMPTY_TEST_SENTINEL"
>  @requires vm.opt.x.Xlog == "NONEMPTY_TEST_SENTINELXXX"
>  @requires vm.opt.x.Xms == "3g"
> 
> and
> 
> JAVA_OPTIONS=-Xms3g -Xms4g
> JAVA_OPTIONS=-Xms4g -Xms3g
> JAVA_OPTIONS=-Xlog:gc* -Xlog:gc*
> ``` 
> 
> Running tier1

As I said previously I have no objection to this fix dealing with the bug that was introduced by [JDK-8317228](https://bugs.openjdk.org/browse/JDK-8317228). But I think [JDK-8317228](https://bugs.openjdk.org/browse/JDK-8317228) needs revisiting in itself.

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

PR Comment: https://git.openjdk.org/jdk/pull/16824#issuecomment-1928810185

From sspitsyn at openjdk.org  Tue Feb  6 05:45:00 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 6 Feb 2024 05:45:00 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v2]
In-Reply-To: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
Message-ID: <PJxLCcXEuAn8djRria8KpHOHAvkFcu4pcWKmyPu57hw=.43ef832c-9dd5-44d7-9efb-d542edbc8757@github.com>

> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
> The function returns the following structure:
> 
> 
> typedef struct {
>     jthread owner;
>     jint entry_count;
>     jint waiter_count;
>     jthread* waiters;
>     jint notify_waiter_count;
>     jthread* notify_waiters;
> } jvmtiMonitorUsage;
> 
> 
> The following four fields are defined this way:
> 
> waiter_count  [jint] The number of threads waiting to own this monitor
> waiters  [jthread*] The waiter_count waiting threads
> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
> 
> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
> This update makes it right.
> 
> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
> 
> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
> 
>   jvmti/GetObjectMonitorUsage/objmonusage001
>   jvmti/GetObjectMonitorUsage/objmonusage003
> 
> 
> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
> 
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
> 
> 
> 
> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository by a separate sub-task before integration of this update.
> 
> Also, please see and review the related CSR:
>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
>  
> Testing:
>  - tested with mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: thread in notify waiter list can't be BLOCKED

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17680/files
  - new: https://git.openjdk.org/jdk/pull/17680/files/80225516..abe82a6c

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

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

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

From jwaters at openjdk.org  Tue Feb  6 07:04:00 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 6 Feb 2024 07:04:00 GMT
Subject: RFR: 8316930: HotSpot should use noexcept instead of throw() [v5]
In-Reply-To: <kc_cq_sBCqn-iAwHCEaTqgMVYrnT6tKsk3SZnD_qP-s=.1b5d24dd-a925-4f6d-aefb-67b4df6bddac@github.com>
References: <kc_cq_sBCqn-iAwHCEaTqgMVYrnT6tKsk3SZnD_qP-s=.1b5d24dd-a925-4f6d-aefb-67b4df6bddac@github.com>
Message-ID: <9k00GYxtEiNBgrtIsIYJUIdwwPjynEm6aONdchZreP4=.0ad54916-180e-4317-8385-e339595a340a@github.com>

> throw() has been deprecated since C++11 alongside dynamic exception specifications, we should replace all instances of it with noexcept to prepare HotSpot for later versions of C++

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

 - Merge branch 'openjdk:master' into noexcept
 - Merge branch 'openjdk:master' into noexcept
 - Typo in GensrcAdlc.gmk
 - Merge branch 'openjdk:master' into noexcept
 - Merge branch 'master' into noexcept
 - ic in compiledIC.hpp
 - Revert compiledIC.cpp
 - Revert compiledIC.hpp
 - Partially Revert parse.hpp
 - Merge branch 'master' into noexcept
 - ... and 4 more: https://git.openjdk.org/jdk/compare/9ee9f288...b73a6882

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

Changes: https://git.openjdk.org/jdk/pull/15910/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15910&range=04
  Stats: 87 lines in 37 files changed: 0 ins; 0 del; 87 mod
  Patch: https://git.openjdk.org/jdk/pull/15910.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15910/head:pull/15910

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

From qpzhang at openjdk.org  Tue Feb  6 07:23:04 2024
From: qpzhang at openjdk.org (Patrick Zhang)
Date: Tue, 6 Feb 2024 07:23:04 GMT
Subject: RFR: 8324824: AArch64: Detect Ampere-1B core and update default
 options for Ampere CPUs
Message-ID: <N9ZCzxRwamt4YTT5wNJottgQ7FYJX4SQrrFxv11Ramg=.4881b622-6d73-4c12-beb3-d65ce465f076@github.com>

Added CPU detection for Ampere-1B, and updated the default options for AmpereOne, Ampere-1A/1B to have `-XX:+UseSIMDForMemoryOps` and `-XX:OnSpinWaitInst=isb -XX:OnSpinWaitInstCount=2`.

Tests done:
1. GitHub Actions (GHA) sanity tests: https://github.com/cnqpzhang/jdk/actions/runs/7786881426
2. OpenJDK bundled JMH, `make run-test TEST="jtreg:hotspot/jtreg/compiler/onSpinWait*"` , `make run-test TEST="micro:ThreadOnSpinWait*"`, no issue found, and `ThreadOnSpinWaitProducerConsumer.trial` showed ~3x better scores (us/op).
3. Jtreg tier1/tier2 sanity check on AmpereOne AArch64 platforms, Ampere-1A systems as well, no new issues found.

Signed-off-by: Patrick Zhang [patrick at os.amperecomputing.com](mailto:patrick at os.amperecomputing.com)

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

Commit messages:
 - 8324824: AArch64: Detect Ampere-1B core and update default options for Ampere CPUs

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

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

From ihse at openjdk.org  Tue Feb  6 08:07:28 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 Feb 2024 08:07:28 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v9]
In-Reply-To: <b96RhEmwIImjWS3oyk9PxePfyguzdnMH99r5ehZymyM=.713daa09-855a-48e7-9aff-af671cc947c9@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <hd3QLWKom9VFSeX9AxaD6vzAN0goIoUn74UDH3cdumY=.e7c4a01c-620a-4686-be89-4ad82ba1f340@github.com>
 <b96RhEmwIImjWS3oyk9PxePfyguzdnMH99r5ehZymyM=.713daa09-855a-48e7-9aff-af671cc947c9@github.com>
Message-ID: <nnJLdTCIakaXM-E8YEJcXbH0S3JHfM96703ogcfeyxk=.72dbeffd-7401-4707-9b54-b21b0c9377ad@github.com>

On Fri, 8 Dec 2023 00:50:59 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix potential attribute issue
>
>> Build changes finally look good. Great, actually! Thanks for persisting, despite the many rounds of review.
>> 
>> You will still need the 2 hotspot reviews for the hotspot part of the patch.
>> 
>> /reviewers 3
> 
> Thanks for the review and all the comments!

@XiaohongGong What happened? Did you not intend to continue working to get this integrated?

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1928968764

From xgong at openjdk.org  Tue Feb  6 08:15:08 2024
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 6 Feb 2024 08:15:08 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v9]
In-Reply-To: <hd3QLWKom9VFSeX9AxaD6vzAN0goIoUn74UDH3cdumY=.e7c4a01c-620a-4686-be89-4ad82ba1f340@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <hd3QLWKom9VFSeX9AxaD6vzAN0goIoUn74UDH3cdumY=.e7c4a01c-620a-4686-be89-4ad82ba1f340@github.com>
Message-ID: <fd1bzFHzekbbS36hdUrlmmOz0K9aMt7vID_xZkfVL1s=.4036c93c-ed88-401c-b083-044c520504d6@github.com>

On Thu, 7 Dec 2023 09:30:01 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]).
>> 
>> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead.
>> 
>> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly.
>> 
>> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts.
>> 
>> [1] https://github.com/openjdk/jdk/pull/3638
>> [2] https://sleef.org/
>> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/
>> [4] https://packages.debian.org/bookworm/libsleef3
>> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix potential attribute issue

Yeah, I,m so sorry for that due to some uncontrollable changes to my work. I have to stop it. Maybe others from Arm will revisit this feature in future. Thanks for your time on this PR and all your comments!

---- Replied Message ----
| From | Magnus Ihse ***@***.***> |
| Date | 02/06/2024 16:02 |
| To | openjdk/jdk ***@***.***> |
| Cc | XiaohongGong ***@***.***>,
Mention ***@***.***> |
| Subject | Re: [openjdk/jdk] 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF (PR #16234) |

@XiaohongGong What happened? Did you not intend to continue working to get this integrated?

?
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: ***@***.***>

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1928983785

From ihse at openjdk.org  Tue Feb  6 08:20:05 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 Feb 2024 08:20:05 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v9]
In-Reply-To: <hd3QLWKom9VFSeX9AxaD6vzAN0goIoUn74UDH3cdumY=.e7c4a01c-620a-4686-be89-4ad82ba1f340@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <hd3QLWKom9VFSeX9AxaD6vzAN0goIoUn74UDH3cdumY=.e7c4a01c-620a-4686-be89-4ad82ba1f340@github.com>
Message-ID: <_Md9YBUxFkpVBHq4CwX1S5qFkQKiqiQ40rem3OA_zUU=.20785d53-06ad-4d15-9b06-42ed1061a818@github.com>

On Thu, 7 Dec 2023 09:30:01 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]).
>> 
>> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead.
>> 
>> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly.
>> 
>> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts.
>> 
>> [1] https://github.com/openjdk/jdk/pull/3638
>> [2] https://sleef.org/
>> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/
>> [4] https://packages.debian.org/bookworm/libsleef3
>> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix potential attribute issue

Ooookay. I hope someone picks it up. I've spent quite a lot of time trying to get this PR into shape.

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1928991506

From ihse at openjdk.org  Tue Feb  6 08:23:05 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 Feb 2024 08:23:05 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v6]
In-Reply-To: <l5WD1cEIW8M7NHd72gK16F1_2cglU3Leeie4zdyCdR4=.6bb73168-2f49-4091-960c-e332694586fa@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <xOklXGR_QdSJHh3lcUxV1k4kLWs0TC9wWKZ_eUenbZQ=.5b13ac21-4d7c-482c-b985-a35e19bd89e5@github.com>
 <3cK9QjVQNIgZoWWhrWKEb3XxfbLjprjRMBbStWegH7M=.6df92651-b97d-445a-aa42-302ea791bbea@github.com>
 <lQJoZ_hXjfLO-MRGDLar9L0yD6xAXF1QAu2AIAjwnKk=.390b6b58-3e5d-42af-90e6-2dd76b29172f@github.com>
 <AnHvp-NR-sLPEha8BivPv-pBAmquGjSge4TIludLVHM=.e2866a94-78bb-40d7-8506-9807c5a3d786@github.com>
 <l5WD1cEIW8M7NHd72gK16F1_2cglU3Leeie4zdyCdR4=.6bb73168-2f49-4091-960c-e332694586fa@github.com>
Message-ID: <3jgZL57F_aikTsAnrGINeQgFHryGBNJZI24-WusdYKM=.f1f64b34-bfbb-4222-afba-c200152075dc@github.com>

On Mon, 11 Dec 2023 18:25:09 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> @theRealAph 
>>> Or is there likely to be a plan to e.g. build Oracle's releases with SLEEF support?
>> 
>> I can't say anything for sure, but I picked up some positive vibes from our internal chat. I think the idea was that libsleef could potentially cover up vector math for all platforms that the current Intel lib solution is missing (basically, everything but linux+windows x64). So I this can be seen as a bit of a trial balloon if it is worth a more complete integration of libsleef in the JDK.
>> 
>> And I can't say anything at all about what Oracle JDKs are going to release with, but I am fully open towards adding libsleef to the GHA builds. And I'm guessing that Adoptium has no reason not to include libsleef, but then again, I cannot of course speak for them.
>
>> I can't say anything for sure, but I picked up some positive vibes from our internal chat. I think the idea was that libsleef could potentially cover up vector math for all platforms that the current Intel lib solution is missing (basically, everything but linux+windows x64). So I this can be seen as a bit of a trial balloon if it is worth a more complete integration of libsleef in the JDK.
> 
> I can add that we are interested to use that for Linux + RISC-V support given the RISC-V support was recently merged into sleef upstream. https://github.com/shibatch/sleef/pull/477

@luhenry Maybe you are interested in helping with bringing this forward? I can assist with risc-v related fixes in the makefiles. I'd just hate to see all this work go to waste.

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1928995458

From sroy at openjdk.org  Tue Feb  6 08:45:12 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Tue, 6 Feb 2024 08:45:12 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v15]
In-Reply-To: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
Message-ID: <NcB8LLqVwjhZjvyVED8tqzZMpcwkwnpTFri01A72Izw=.c3655357-8f81-4f27-a332-480b0dfe5855@github.com>

> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am.
> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX.
> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails.

Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:

  change control flow

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16604/files
  - new: https://git.openjdk.org/jdk/pull/16604/files/f4c1788b..14e0ed39

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=13-14

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

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

From eastigeevich at openjdk.org  Tue Feb  6 08:56:59 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Tue, 6 Feb 2024 08:56:59 GMT
Subject: Integrated: 8324874: AArch64: crypto pmull based CRC32/CRC32C
 intrinsics clobber V8-V15 registers
In-Reply-To: <I4SlF2m1-uY5cH3AsdBhVqbTJ1m7GXfThpCgfx_6N5k=.b7a84fc0-198c-4bf0-a26b-bbe3c3ed2558@github.com>
References: <I4SlF2m1-uY5cH3AsdBhVqbTJ1m7GXfThpCgfx_6N5k=.b7a84fc0-198c-4bf0-a26b-bbe3c3ed2558@github.com>
Message-ID: <blOLDGY_zlVYHj-gL8KWSp2_YVIrwtc6HTGBoso2ODE=.f22d3a53-c912-4ef3-8919-8c1938abf7af@github.com>

On Sun, 4 Feb 2024 20:19:40 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

> [JDK-8302113](https://bugs.openjdk.org/browse/JDK-8302113) and [JDK-8302783](https://bugs.openjdk.org/browse/JDK-8302783) enhanced CRC32/CRC32C intrinsics with crypto pmull which is enabled for Neoverse V1 and V2. The intrinsics use `kernel_crc32_common_fold_using_crypto_pmull` which uses v8-v15 registers and potentially clobbers them if they are not saved before CRC32/CRC32C intrinsics are called.
> 
> According to the latest ?ABI for the Arm 64-bit Architecture with SVE support?: https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst
> 
> 
> Registers v8-v15 must be preserved by a callee across subroutine calls;
> the remaining registers (v0-v7, v16-v31) do not need to be preserved
> (or should be preserved by the caller).
> 
> 
> This PR reallocates registers to avoid v8-v15 registers:
> - v0-v7 are used for data.
> - v16-v31 are tmp registers.
> 
> Regression tests are added.
> Tested a fastdebug build on Graviton 3:
> - `gtest`: Passed
> - `tier1..tier3`: Passed

This pull request has now been integrated.

Changeset: 4cd31875
Author:    Evgeny Astigeevich <eastigeevich at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4cd318756d4a8de64d25fb6512ecba9a008edfa1
Stats:     254 lines in 2 files changed: 172 ins; 0 del; 82 mod

8324874: AArch64: crypto pmull based CRC32/CRC32C intrinsics clobber V8-V15 registers

Reviewed-by: aph, ngasson

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

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

From aph at openjdk.org  Tue Feb  6 09:09:55 2024
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 6 Feb 2024 09:09:55 GMT
Subject: RFR: 8324833: Signed integer overflows in ABS [v3]
In-Reply-To: <a91fiKxlZb2seS1Ql2geW4NppZTHNaPeQhxjGpcYjsk=.652f08c0-a72f-4f3d-9639-ac489b1b4eac@github.com>
References: <ohwAn6GqM7FIgYTJNy40VBYSCVEBrrNSqBaz2akN54M=.f9660235-3047-47ee-aad0-ef598d6ebdcc@github.com>
 <6kxKhJVXB2X7ni4SLMtL--Pt5O8bUOazcI9F3FJgG8o=.55b0e9bd-075c-4b76-bcc6-732951e8a512@github.com>
 <a91fiKxlZb2seS1Ql2geW4NppZTHNaPeQhxjGpcYjsk=.652f08c0-a72f-4f3d-9639-ac489b1b4eac@github.com>
Message-ID: <vNp_WRnKtEyMlfKDtZmahudZ1VKXe9dyvCd9zZ1StAo=.509471c0-3bc4-4683-8e25-0fbd72ae782d@github.com>

On Mon, 5 Feb 2024 20:37:48 GMT, Dean Long <dlong at openjdk.org> wrote:

> The undefined behavior I was talking about is what abs(INT_MIN) returns on two's complement

I don't believe ABS is undefined if we go from signed to unsigned, via uabs, and back to signed. The conversion from signed->unsigned is well defined, as is the negation of the unsigned value, and the conversion from unsigned back to signed is at worst implementation defined. ABS is undefined when there is an arithmetic overflow, and in this case there is none.

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

PR Comment: https://git.openjdk.org/jdk/pull/17617#issuecomment-1929070367

From dnsimon at openjdk.org  Tue Feb  6 09:20:54 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 6 Feb 2024 09:20:54 GMT
Subject: RFR: 8317368: [JVMCI] SIGSEGV in
 JVMCIEnv::initialize_installed_code on libgraal [v2]
In-Reply-To: <eupd4UgZty_Vwn0ZkqB37ldOTbSB_Qcw3Cbs2otHJMA=.101bde4c-f2f7-4fcd-a879-3a0cf4eea5fb@github.com>
References: <mjkX-rG6apf-VSRRuovOjK5kjPilRLXTQBnGz2y2D8I=.08dcce97-ac29-4b61-913c-29dd7429f0aa@github.com>
 <eupd4UgZty_Vwn0ZkqB37ldOTbSB_Qcw3Cbs2otHJMA=.101bde4c-f2f7-4fcd-a879-3a0cf4eea5fb@github.com>
Message-ID: <Ve9B3TM2F2mBFF2cl8QFnetj3EYfs-3OPMv_Ds0badE=.86406665-dd2e-428b-b84e-29b95ccefddf@github.com>

On Tue, 6 Feb 2024 01:10:07 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> This fixes some lurking issues with JVMCI and nmethod related both BarrierSetNMethod and the garbage collection of nmethods.  In particular the stack walking in c2v_iterateFrames visits many frames and needs a KeepStackGCProcessedMark for safety.  Additionally, JVMCI interacts with nmethods in complex ways and needs some sort of strong root during these interactions.  A new JavaThread field has been added that mirrors the way JVMTI keeps nmethods alive.
>
> Tom Rodriguez has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge branch 'master' into tkr-nmethod-keep-alive
>  - Move BarrierSetNMethod call into JVMCINMethodHandle::set_nmethod
>  - 8317368: [JVMCI] SIGSEGV in JVMCIEnv::initialize_installed_code on libgraal

Marked as reviewed by dnsimon (Reviewer).

I don't see an easy way to avoid the extra field in `JavaThread` given that any Java thread can install JVMCI code, not just CompilerThreads.

src/hotspot/share/jvmci/jvmciEnv.hpp line 391:

> 389:   CodeBlob* get_code_blob(JVMCIObject code);
> 390: 
> 391:   // Given an instance of HotSpotInstalledCode return the corresponding nmethod.

Can you please improve the comment while here, adding a `,` after `HotSpotInstalledCode`.

src/hotspot/share/runtime/javaThread.hpp line 384:

> 382:   oop        _jvmci_reserved_oop0;
> 383: 
> 384:   // This field is used to keep an nmethod visible to the GC so that it can be kept alive

suggestion: `so that it can be kept alive` -> `so that it and its contained oops can be kept alive`

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

PR Review: https://git.openjdk.org/jdk/pull/17714#pullrequestreview-1864621953
PR Comment: https://git.openjdk.org/jdk/pull/17714#issuecomment-1929086985
PR Review Comment: https://git.openjdk.org/jdk/pull/17714#discussion_r1479442770
PR Review Comment: https://git.openjdk.org/jdk/pull/17714#discussion_r1479438498

From jwaters at openjdk.org  Tue Feb  6 09:53:01 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 6 Feb 2024 09:53:01 GMT
Subject: RFR: 8325316: Enable -pedantic -Wpedantic for gcc
Message-ID: <5-fL8vy-065EhMR2SzE21o7UFrOOoDVfnhDG06G-kkE=.0c2dab10-c458-4178-89f7-004f8f921a3f@github.com>

Similarly to [JDK-8325163](https://bugs.openjdk.org/browse/JDK-8325163), this enables pedantic mode for gcc, ensuring stricter Standard conformance and allowing for buggy and broken code previously undetectable by gcc to be caught

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

Commit messages:
 - Semicolon in compilerWarnings_gcc.hpp
 - compilerWarnings_gcc.hpp
 - 8325316

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

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

From mdoerr at openjdk.org  Tue Feb  6 10:15:01 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 6 Feb 2024 10:15:01 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v15]
In-Reply-To: <NcB8LLqVwjhZjvyVED8tqzZMpcwkwnpTFri01A72Izw=.c3655357-8f81-4f27-a332-480b0dfe5855@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <NcB8LLqVwjhZjvyVED8tqzZMpcwkwnpTFri01A72Izw=.c3655357-8f81-4f27-a332-480b0dfe5855@github.com>
Message-ID: <PCDEvwn08rbnQYdpAOpeoFAbKg_rSCxuKsEaZTHnY-U=.86eb3135-29c6-4f7c-bfb8-21b2003abb77@github.com>

On Tue, 6 Feb 2024 08:45:12 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am.
>> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX.
>> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails.
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change control flow

src/hotspot/os/aix/os_aix.cpp line 1178:

> 1176:   if (pointer_to_dot == nullptr) {
> 1177:     log_info(os)("Attempting to load a shared object without extension %s", filename);
> 1178:     return result;

Memory leak: `file_path` not freed before returning.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1479524411

From jkern at openjdk.org  Tue Feb  6 10:28:59 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Tue, 6 Feb 2024 10:28:59 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v15]
In-Reply-To: <NcB8LLqVwjhZjvyVED8tqzZMpcwkwnpTFri01A72Izw=.c3655357-8f81-4f27-a332-480b0dfe5855@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <NcB8LLqVwjhZjvyVED8tqzZMpcwkwnpTFri01A72Izw=.c3655357-8f81-4f27-a332-480b0dfe5855@github.com>
Message-ID: <zSvrYlWnij9OTaiPov8OcJ-Go47cYfKNqHXBDiqFw0A=.392aac62-a505-4ad8-8b75-fe2dd7c534c1@github.com>

On Tue, 6 Feb 2024 08:45:12 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am.
>> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX.
>> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails.
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change control flow

May be this is academical:
Your code works for plain libraries replacing the .so extension by .a.
Suppose the case the goal is to load a member of an archive libname.a(member.o), but as in the plain case you get as input libname.so(member.o).
In this case you will cut of the member producing the resulting string libname.a instead of libname.a(member.o).
Should this situation also be handled or is this forbidden?

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

PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1929210294

From ihse at openjdk.org  Tue Feb  6 11:39:57 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 Feb 2024 11:39:57 GMT
Subject: RFR: 8325109: Sort method modifiers in canonical order
In-Reply-To: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
References: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
Message-ID: <hMv74_Mz6j4w5HMKHfGqeYuSNKUfu3ywR8Zdxv3nUBQ=.8965f0fa-9ea6-467b-b8a3-4a1dc59c2d76@github.com>

On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a follow-up on [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the bin/blessed-modifier-order.sh on the entire code base, and manually checked the result. I have reverted all but these trivial and uncontroversial changes.
> 
> Almost all of these are about moving `static` to its proper position; a few do not involve `static` but instead puts `final` or `abstract` in the correct place.
> 
> I have deliberately stayed away from `default` in this PR, since they should probably get a more thorough treatment, see https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473.

@DougLea Doug, do you have anything to say about the changes in `java.util.concurrent`?

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

PR Comment: https://git.openjdk.org/jdk/pull/17670#issuecomment-1929336942

From ngasson at openjdk.org  Tue Feb  6 12:48:06 2024
From: ngasson at openjdk.org (Nick Gasson)
Date: Tue, 6 Feb 2024 12:48:06 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v9]
In-Reply-To: <hd3QLWKom9VFSeX9AxaD6vzAN0goIoUn74UDH3cdumY=.e7c4a01c-620a-4686-be89-4ad82ba1f340@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <hd3QLWKom9VFSeX9AxaD6vzAN0goIoUn74UDH3cdumY=.e7c4a01c-620a-4686-be89-4ad82ba1f340@github.com>
Message-ID: <DYz4aZBnVpwvFLOoaV_cbUgrkgNF-SFMeakpXTs4dfQ=.e78ee5fa-70f6-49dc-8ef5-3861f31a79bd@github.com>

On Thu, 7 Dec 2023 09:30:01 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]).
>> 
>> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead.
>> 
>> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly.
>> 
>> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts.
>> 
>> [1] https://github.com/openjdk/jdk/pull/3638
>> [2] https://sleef.org/
>> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/
>> [4] https://packages.debian.org/bookworm/libsleef3
>> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix potential attribute issue

We are planning to pick this up again later in the year, thanks for your help so far!

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1929451905

From fbredberg at openjdk.org  Tue Feb  6 12:49:56 2024
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Tue, 6 Feb 2024 12:49:56 GMT
Subject: RFR: 8322535: Change default AArch64 SpinPause instruction [v2]
In-Reply-To: <OsC2nv6OmkEApnjjW6cwEa5G2wBAtdz8TZjP_aY0k-M=.4a72be80-cef9-4a13-af33-7a2007f1a230@github.com>
References: <JV7H6vybR8ANCBume69ImM9-bnYpiGpWMfhnzm_hz1I=.51c5bd49-ede4-43b4-8ea0-522b5a70a98d@github.com>
 <OsC2nv6OmkEApnjjW6cwEa5G2wBAtdz8TZjP_aY0k-M=.4a72be80-cef9-4a13-af33-7a2007f1a230@github.com>
Message-ID: <ij5Gy9OfAPDkx7EGqmleVvkBNBGErZExniR4hG_G8aw=.fd630e3f-288f-4187-b3d4-ce6e1d2997a5@github.com>

On Mon, 5 Feb 2024 15:29:36 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> The Java options OnSpinWaitInst lets you choose which AArch64 instruction should be used in `SpinPause()`. Valid values are "none", "nop", "isb" and "yield". Today the default value for OnSpinWaitInst is unfortunately "none".
>> 
>> However some CPUs changes the default SpinPause instruction to something better if the user hasn't used the OnSpinWaitInst option. For instance if you run a Neoverse N1, N2, V1 or V2, the default SpinPause instruction will be changed to "isb". After doing some measurements on Apple's M1-M3 CPUs it also seems like "isb" is the best yielding instruction on on those CPUs.
>> 
>> This PR changes the default SpinPause instruction to "yield" on all AArch64 platforms except on Apple's M1, M2 and M3 CPUs on which the default value will be "isb".
>> 
>> Tested tier1-tier7 successfully on linux-aarch64 and macosx-aarch64.
>
> Fredrik Bredberg 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:
> 
>  - Removed isb as default SpinPause instruction for Apple silicon
>  - Merge branch 'master' into 8322535_default_spinpause_inst
>  - Merge branch 'master' into 8322535_default_spinpause_inst
>  - 8322535: Change default AArch64 SpinPause instruction

Thank you guys for review comments. If anyone wants to continue to evaluate different `SpinPause()` instructions I've attached a file (`spin_pause.c`) to [JDK-8322535](https://bugs.openjdk.org/browse/JDK-8322535)  which can be used to measure the execution time for different instructions that are more or less suitable for use in `SpinPause()`, e.g. `nop`, `pause`, `yield` and `isb`.

If no one else has anything to add, I'll integrate (as soon as I can convince a sponsor).

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

PR Comment: https://git.openjdk.org/jdk/pull/17430#issuecomment-1929456497

From coleenp at openjdk.org  Tue Feb  6 13:28:05 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 6 Feb 2024 13:28:05 GMT
Subject: RFR: 8322535: Change default AArch64 SpinPause instruction [v2]
In-Reply-To: <OsC2nv6OmkEApnjjW6cwEa5G2wBAtdz8TZjP_aY0k-M=.4a72be80-cef9-4a13-af33-7a2007f1a230@github.com>
References: <JV7H6vybR8ANCBume69ImM9-bnYpiGpWMfhnzm_hz1I=.51c5bd49-ede4-43b4-8ea0-522b5a70a98d@github.com>
 <OsC2nv6OmkEApnjjW6cwEa5G2wBAtdz8TZjP_aY0k-M=.4a72be80-cef9-4a13-af33-7a2007f1a230@github.com>
Message-ID: <hMHV32j8Dk3QDMm-OlIFcobLkaGJO7I_qydJifWgnAs=.ea2a640e-2493-4df1-9ea5-d601ad04a97d@github.com>

On Mon, 5 Feb 2024 15:29:36 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> The Java options OnSpinWaitInst lets you choose which AArch64 instruction should be used in `SpinPause()`. Valid values are "none", "nop", "isb" and "yield". Today the default value for OnSpinWaitInst is unfortunately "none".
>> 
>> However some CPUs changes the default SpinPause instruction to something better if the user hasn't used the OnSpinWaitInst option. For instance if you run a Neoverse N1, N2, V1 or V2, the default SpinPause instruction will be changed to "isb". After doing some measurements on Apple's M1-M3 CPUs it also seems like "isb" is the best yielding instruction on on those CPUs.
>> 
>> This PR changes the default SpinPause instruction to "yield" on all AArch64 platforms except on Apple's M1, M2 and M3 CPUs on which the default value will be "isb".
>> 
>> Tested tier1-tier7 successfully on linux-aarch64 and macosx-aarch64.
>
> Fredrik Bredberg 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:
> 
>  - Removed isb as default SpinPause instruction for Apple silicon
>  - Merge branch 'master' into 8322535_default_spinpause_inst
>  - Merge branch 'master' into 8322535_default_spinpause_inst
>  - 8322535: Change default AArch64 SpinPause instruction

Marked as reviewed by coleenp (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17430#pullrequestreview-1865164171

From fbredberg at openjdk.org  Tue Feb  6 13:28:06 2024
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Tue, 6 Feb 2024 13:28:06 GMT
Subject: Integrated: 8322535: Change default AArch64 SpinPause instruction
In-Reply-To: <JV7H6vybR8ANCBume69ImM9-bnYpiGpWMfhnzm_hz1I=.51c5bd49-ede4-43b4-8ea0-522b5a70a98d@github.com>
References: <JV7H6vybR8ANCBume69ImM9-bnYpiGpWMfhnzm_hz1I=.51c5bd49-ede4-43b4-8ea0-522b5a70a98d@github.com>
Message-ID: <zPN4w7HoO589NBUjL-Q_-iiPd7s-kkDbp4y46bHJIgQ=.f94364e5-66d5-4895-a606-840d9d26bae0@github.com>

On Mon, 15 Jan 2024 16:25:08 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> The Java options OnSpinWaitInst lets you choose which AArch64 instruction should be used in `SpinPause()`. Valid values are "none", "nop", "isb" and "yield". Today the default value for OnSpinWaitInst is unfortunately "none".
> 
> However some CPUs changes the default SpinPause instruction to something better if the user hasn't used the OnSpinWaitInst option. For instance if you run a Neoverse N1, N2, V1 or V2, the default SpinPause instruction will be changed to "isb". After doing some measurements on Apple's M1-M3 CPUs it also seems like "isb" is the best yielding instruction on on those CPUs.
> 
> This PR changes the default SpinPause instruction to "yield" on all AArch64 platforms except on Apple's M1, M2 and M3 CPUs on which the default value will be "isb".
> 
> Tested tier1-tier7 successfully on linux-aarch64 and macosx-aarch64.

This pull request has now been integrated.

Changeset: f356970b
Author:    Fredrik Bredberg <fbredberg at openjdk.org>
Committer: Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f356970b8930c6ec122d797d84503a6e86d67526
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8322535: Change default AArch64 SpinPause instruction

Reviewed-by: eastigeevich, eosterlund, coleenp

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

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

From coleenp at openjdk.org  Tue Feb  6 13:29:01 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 6 Feb 2024 13:29:01 GMT
Subject: RFR: 8308745: ObjArrayKlass::allocate_objArray_klass may call into
 java while holding a lock
In-Reply-To: <HpX_QOzL2oYheoEgqM20D63b72-GXXYve75PNSyRRV0=.55ad9299-cc8e-494a-a03a-dbb36b68776f@github.com>
References: <zsgIr8-Xrh0jfgEEvfwhmlCViCSJuC5-NhUiSGgycgs=.c54cd0a0-11f4-4963-a976-8c63907cdae3@github.com>
 <HpX_QOzL2oYheoEgqM20D63b72-GXXYve75PNSyRRV0=.55ad9299-cc8e-494a-a03a-dbb36b68776f@github.com>
Message-ID: <TIA0BYtxmHpSmB5reOUOofUSZ7DmOpMQZStHTAPkrMk=.51220979-d013-4a39-874b-56db3b83c78a@github.com>

On Thu, 1 Feb 2024 05:22:24 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This change uses a claim token to allocate multi dimensional arrays rather than holding MultiArray_lock around metaspace allocation.  We can't hold a mutex around metaspace allocation because it can create an OOM object and it can also call into JVMTI for a resource exhausted event.  Also, we were creating mirrors and more metadata arrays while holding this lock.   See the bug for more details and other ideas considered and rejected.
>> 
>> Tested with tier1-7.
>
> ~~Can't you just use a Monitor to implement the claim token, rather than this lock-free approach? (Similar to how class initialization is handled.)~~
> 
> Sorry lost the forest in the trees.

I'm going to do a bit of rework as discussed with @dholmes-ora .

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

PR Comment: https://git.openjdk.org/jdk/pull/17660#issuecomment-1929599218

From coleenp at openjdk.org  Tue Feb  6 13:29:02 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 6 Feb 2024 13:29:02 GMT
Subject: Withdrawn: 8308745: ObjArrayKlass::allocate_objArray_klass may call
 into java while holding a lock
In-Reply-To: <zsgIr8-Xrh0jfgEEvfwhmlCViCSJuC5-NhUiSGgycgs=.c54cd0a0-11f4-4963-a976-8c63907cdae3@github.com>
References: <zsgIr8-Xrh0jfgEEvfwhmlCViCSJuC5-NhUiSGgycgs=.c54cd0a0-11f4-4963-a976-8c63907cdae3@github.com>
Message-ID: <LrmxLySKxw0DpatarlPr__iBDjccuTdGdAqSehD8p4w=.6a82d507-58d9-4c58-b214-18a6123e2841@github.com>

On Wed, 31 Jan 2024 18:57:23 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change uses a claim token to allocate multi dimensional arrays rather than holding MultiArray_lock around metaspace allocation.  We can't hold a mutex around metaspace allocation because it can create an OOM object and it can also call into JVMTI for a resource exhausted event.  Also, we were creating mirrors and more metadata arrays while holding this lock.   See the bug for more details and other ideas considered and rejected.
> 
> Tested with tier1-7.

This pull request has been closed without being integrated.

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

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

From jsjolen at openjdk.org  Tue Feb  6 13:34:54 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 6 Feb 2024 13:34:54 GMT
Subject: RFR: 8322476: Remove GrowableArray C-Heap version,
 replace usages with GrowableArrayCHeap
In-Reply-To: <7BF6OZ3vRH791MKbVeJqQ5foScHax_gLMFjSKkm3J68=.f29e5b1c-0751-4257-b253-261c6e20a7b9@github.com>
References: <7BF6OZ3vRH791MKbVeJqQ5foScHax_gLMFjSKkm3J68=.f29e5b1c-0751-4257-b253-261c6e20a7b9@github.com>
Message-ID: <0b-TYV3j49IRIUZzRDTDtDxniKa3PB-DqoAV8N3VpDs=.6d63d89a-0868-4b2a-9f42-024e42c54892@github.com>

On Tue, 19 Dec 2023 16:59:05 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> [JDK-8247755](https://bugs.openjdk.org/browse/JDK-8247755) introduced the `GrowableArrayCHeap`. This duplicates the current C-Heap allocation capability in `GrowableArray`. I now remove that from `GrowableArray` and move all usages to `GrowableArrayCHeap`.
> 
> This has a few advantages:
> - Clear separation between arena (and resource area) allocating array and C-heap allocating array.
> - We can prevent assigning / copying between arrays of different allocation strategies already at compile time, and not only with asserts at runtime.
> - We should not have multiple implementations of the same thing (C-Heap backed array).
> - `GrowableArrayCHeap` is NONCOPYABLE. This is a nice restriction, we now know that C-Heap backed arrays do not get copied unknowingly.
> 
> **Bonus**
> We can now restrict `GrowableArray` element type `E` to be `std::is_trivially_destructible<E>::value == true`. The idea is that arena / resource allocated arrays get abandoned, often without being even cleared. Hence, the elements in the array are never destructed. But if we only use elements that are trivially destructible, then it makes no difference if the destructors are ever called, or the elements simply abandoned.
> 
> For `GrowableArrayCHeap`, we expect that the user eventually calls the destructor for the array, which in turn calls the destructors of the remaining elements. Hence, it is up to the user to ensure the cleanup. And so we can allow non-trivial destructors.
> 
> **Testing**
> Tier1-3 + stress testing: pending

Not yet bot!

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

PR Comment: https://git.openjdk.org/jdk/pull/17160#issuecomment-1929617168

From aboldtch at openjdk.org  Tue Feb  6 14:04:59 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 6 Feb 2024 14:04:59 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v10]
In-Reply-To: <wL168lSWSS1EHp_v9lraUQySJ3WzFD7uoWOIolAtUaU=.cea57d21-687c-44e9-86f7-7ca38930fc87@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
 <wL168lSWSS1EHp_v9lraUQySJ3WzFD7uoWOIolAtUaU=.cea57d21-687c-44e9-86f7-7ca38930fc87@github.com>
Message-ID: <bMARY84_ABMxyQbuNbmNgK_g3FT1X5zRKBV-cljn_C8=.f5899412-f682-4599-88fd-3f3552e4b11d@github.com>

On Mon, 5 Feb 2024 06:51:22 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The `ObjectSynchronizer` has always assumed that the `current` parameters are both the current thread as well as the thread that is doing the locking. The only time that we are entering on behalf of another thread is when doing re-locking in deoptimization. This has worked because the deoptee thread is suspended. However ResourceMarks have been using the wrong thread when logging is enabled.
>> 
>> This change `ObjectSynchronizer` instruments the relevant methods with both a `JavaThread* locking_thread` as well as `[Java]Thread* current` to be able to use the correct thread for ResourceMarks. 
>> 
>> Having the `inflate` care about a `locking_thread` is a little unpleasant in my opinion. But it is required for LM_LIGHTWEIGHT. 
>> Would probably be cleaner if the inflate for LM_LIGHTWEIGHT was it's own thing, as it does not share the whole INFLATING protocol. But seems like a future RFE to refactor this code.
>> 
>> Can reproduce a crash by modifying `test/jdk/com/sun/jdi/EATests.java` and using `-XX:DiagnoseSyncOnValueBasedClasses=2` with LM_LEGACY or running `test/jdk/com/sun/jdi/EATests.java` with LM_LIGHTWEIGHT/LM_MONITOR and `-Xlog:monitorinflation=trace`. 
>> 
>> Could extend this test to capture this regression in the future (or creating a new test based on the same infrastructure). Will give it an attempt, so we have a regression test for this. But these tests get rather involved as the require a lot of jvmti setup.
>
> Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8324881
>  - Update comment
>  - Fix comments
>  - Update test/jdk/com/sun/jdi/EATests.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update test/jdk/com/sun/jdi/EATests.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update test/jdk/com/sun/jdi/EATests.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update test/jdk/com/sun/jdi/EATests.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Remove newline
>  - Update src/hotspot/share/runtime/synchronizer.hpp
>    
>    Co-authored-by: Richard Reingruber <richard.reingruber at sap.com>
>  - Improve EARelockingNestedInflated_03 for LM_LIGHTWEIGHT
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/b7fe007d...b3cc401c

Ran through tier1-tier7. All green.

Saw one test on an earlier run (commit be717d5e888b168039c29bc31163e3949d1cc7b1) which threw:

Test: vmTestbase/nsk/jdi/ThreadReference/ownedMonitorsAndFrames/ownedMonitorsAndFrames003/ownedMonitorsAndFrames003.java
Exception: nsk.share.TestFailure: Number of expected monitors and actual ones differs
``` 

Reran the `vmTestbase/nsk/jdi/` a couple of hundred times in the CI and ran the specific test a couple of thousand times locally, but was unable to reproduce the issue. 

_The test output is attached below_

Looking at the stack trace the thread seem to be about be leave `java.lang.Object.wait, line: 384`. The successful stack trace should contain 

java.lang.Object.wait0, line: -1
java.lang.Object.wait, line: 375


and be inside the wait0. As the current stack trace is on the way out wait then the monitor should be expected to be locked, which it is. Maybe this is a case of a `spurious wakeup`?

I fail to see how this change could have caused this behaviour. However I can not find any record of this sort of test failure since Java 9.  So I am a bit cautious. Regardless it looks to be very intermittent. 

My plan is to integrate this tomorrow unless anyone objects.

<details><summary>Test Output</summary>
<pre>
binder> VirtualMachineManager: version 23.0
binder> Finding connector: default
binder> LaunchingConnector:
binder>     name: com.sun.jdi.CommandLineLaunch
binder>     description: Launches target using Sun Java VM command line and attaches to it
binder>     transport: com.sun.tools.jdi.SunCommandLineLauncher$2 at 20b19474
binder> Connector arguments:
binder>     main=nsk.share.MainWrapper Virtual nsk.share.jdi.OwnedMonitorsDebuggee \u0000-verbose\u0000 \u0000-arch=linux-x64\u0000 \u0000-waittime=5\u0000 \u0000-debugee.vmkind=java\u0000 \u0000-transport.address=dynamic\u0000 \u0000-debugee.vmkeys="-XX:MaxRAMPercentage=4.16667 -Dtest.boot.jdk=<omitted> -Djava.io.tmpdir=<omitted> -Duse.JTREG_TEST_THREAD_FACTORY=Virtual -XX:+UseZGC -XX:+ZGenerational -XX:-VerifyContinuations"\u0000 \u0000-pipe.port=51475\u0000
binder>     includevirtualthreads=y
binder>     quote=\u0000
binder>     home=<omitted>
binder>     vmexec=java
binder>     suspend=true
binder>     options=-XX:MaxRAMPercentage=4.16667 -Dtest.boot.jdk=<omitted> -Djava.io.tmpdir=<omitted> -Duse.JTREG_TEST_THREAD_FACTORY=Virtual -XX:+UseZGC -XX:+ZGenerational -XX:-VerifyContinuations -Djdk.virtualThreadScheduler.parallelism=15
binder> Launching debugee
binder> Waiting for VM initialized
Initial VMStartEvent received: VMStartEvent in thread main
debugee.stderr> Debuggee nsk.share.jdi.OwnedMonitorsDebuggee : sending the command: ready
binder> Breakpoint set:
	breakpoint request nsk.share.jpda.AbstractDebuggeeTest:63 (disabled)
debugee.stderr> Debuggee: received the command: createLockingThread:ownedMonitorsAndFrames003_LockingThread1:SYNCHRONIZED_METHOD:SYNCHRONIZED_THREAD_METHOD:SYNCHRONIZED_STATIC_THREAD_METHOD:SYNCHRONIZED_OBJECT_BLOCK:SYNCHRONIZED_STATIC_METHOD
debugee.stderr> ownedMonitorsAndFrames003_LockingThread1: Enter synchronized method
debugee.stderr> ownedMonitorsAndFrames003_LockingThread1: Enter synchronized thread method
debugee.stderr> ownedMonitorsAndFrames003_LockingThread1: Enter synchronized static thread method
debugee.stderr> ownedMonitorsAndFrames003_LockingThread1: Enter synchronized(object) block
debugee.stderr> ownedMonitorsAndFrames003_LockingThread1: Enter synchronized static method
debugee.stderr> Debuggee nsk.share.jdi.OwnedMonitorsDebuggee : sending the command: ready
binder> Waiting for event by request:
	breakpoint request nsk.share.jpda.AbstractDebuggeeTest:63 (enabled)
debugee.stderr> Debuggee: received the command: forceBreakpoint
binder> Got requested event:
	BreakpointEvent at nsk.share.jpda.AbstractDebuggeeTest:63 in thread OwnedMonitorDebuggeeMainThread
debugee.stderr> In breakpoint method: 'AbstractDebuggeeTest.breakpointMethod()'
debugee.stderr> Debuggee nsk.share.jdi.OwnedMonitorsDebuggee : sending the command: ready
debugee.stderr> Debuggee: received the command: relinquishMonitor:ownedMonitorsAndFrames003_LockingThread1:0
debugee.stderr> ownedMonitorsAndFrames003_LockingThread1: Relinquish monitor: nsk.share.locks.ClassWithSynchronizedMethods at 553383f8
debugee.stderr> Debuggee nsk.share.jdi.OwnedMonitorsDebuggee : sending the command: ready
binder> Waiting for event by request:
	breakpoint request nsk.share.jpda.AbstractDebuggeeTest:63 (enabled)
debugee.stderr> Debuggee: received the command: forceBreakpoint
binder> Got requested event:
	BreakpointEvent at nsk.share.jpda.AbstractDebuggeeTest:63 in thread OwnedMonitorDebuggeeMainThread
debugee.stderr> In breakpoint method: 'AbstractDebuggeeTest.breakpointMethod()'
debugee.stderr> Debuggee nsk.share.jdi.OwnedMonitorsDebuggee : sending the command: ready
debugee.stderr> Debuggee: received the command: acquireRelinquishedMonitor:ownedMonitorsAndFrames003_LockingThread1
debugee.stderr> ownedMonitorsAndFrames003_LockingThread1: Acquire relinquished monitor: nsk.share.locks.ClassWithSynchronizedMethods at 553383f8
debugee.stderr> Debuggee nsk.share.jdi.OwnedMonitorsDebuggee : sending the command: ready
binder> Waiting for event by request:
	breakpoint request nsk.share.jpda.AbstractDebuggeeTest:63 (enabled)
debugee.stderr> Debuggee: received the command: forceBreakpoint
binder> Got requested event:
	BreakpointEvent at nsk.share.jpda.AbstractDebuggeeTest:63 in thread OwnedMonitorDebuggeeMainThread
debugee.stderr> In breakpoint method: 'AbstractDebuggeeTest.breakpointMethod()'
debugee.stderr> Debuggee nsk.share.jdi.OwnedMonitorsDebuggee : sending the command: ready
debugee.stderr> Debuggee: received the command: relinquishMonitor:ownedMonitorsAndFrames003_LockingThread1:1
debugee.stderr> ownedMonitorsAndFrames003_LockingThread1: Relinquish monitor: Thread[#63,ownedMonitorsAndFrames003_LockingThread1,5,VirtualThreads]
binder> Waiting for event by request:
	breakpoint request nsk.share.jpda.AbstractDebuggeeTest:63 (enabled)
debugee.stderr> Debuggee nsk.share.jdi.OwnedMonitorsDebuggee : sending the command: ready
debugee.stderr> Debuggee: received the command: forceBreakpoint
binder> Got requested event:
	BreakpointEvent at nsk.share.jpda.AbstractDebuggeeTest:63 in thread OwnedMonitorDebuggeeMainThread
# ERROR: Number of expected monitors and actual ones differs
The following stacktrace is for failure analysis.
nsk.share.TestFailure: Number of expected monitors and actual ones differs
	at nsk.share.Log.logExceptionForFailureAnalysis(Log.java:431)
	at nsk.share.Log.complain(Log.java:402)
	at nsk.share.jdi.OwnedMonitorsDebugger.compare(OwnedMonitorsDebugger.java:161)
	at nsk.share.jdi.OwnedMonitorsDebugger.checkMonitorInfo(OwnedMonitorsDebugger.java:266)
	at nsk.jdi.ThreadReference.ownedMonitorsAndFrames.ownedMonitorsAndFrames003.ownedMonitorsAndFrames003.doTest(ownedMonitorsAndFrames003.java:130)
	at nsk.share.jdi.TestDebuggerType2.runIt(TestDebuggerType2.java:214)
	at nsk.jdi.ThreadReference.ownedMonitorsAndFrames.ownedMonitorsAndFrames003.ownedMonitorsAndFrames003.run(ownedMonitorsAndFrames003.java:77)
	at nsk.jdi.ThreadReference.ownedMonitorsAndFrames.ownedMonitorsAndFrames003.ownedMonitorsAndFrames003.main(ownedMonitorsAndFrames003.java:73)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
	at java.base/java.lang.VirtualThread.run(VirtualThread.java:329)
# ERROR: Expected: 4, actual: 5
# ERROR: Unexpected monitor in result of ownedMonitorsAndFrames(): instance of nsk.share.locks.LockingThread(name='ownedMonitorsAndFrames003_LockingThread1', id=953) Depth: 9 Thread: instance of nsk.share.locks.LockingThread(name='ownedMonitorsAndFrames003_LockingThread1', id=953)
ACTUAL MONITORS (total 5):
Monitor: instance of java.lang.Class(reflected class=nsk.share.locks.ClassWithSynchronizedMethods, id=954)
Depth: 3
Thread: instance of nsk.share.locks.LockingThread(name='ownedMonitorsAndFrames003_LockingThread1', id=953)
Monitor: instance of java.lang.Object(id=980)
Depth: 5
Thread: instance of nsk.share.locks.LockingThread(name='ownedMonitorsAndFrames003_LockingThread1', id=953)
Monitor: instance of java.lang.Class(reflected class=nsk.share.locks.LockingThread, id=950)
Depth: 7
Thread: instance of nsk.share.locks.LockingThread(name='ownedMonitorsAndFrames003_LockingThread1', id=953)
Monitor: instance of nsk.share.locks.LockingThread(name='ownedMonitorsAndFrames003_LockingThread1', id=953)
Depth: 9
Thread: instance of nsk.share.locks.LockingThread(name='ownedMonitorsAndFrames003_LockingThread1', id=953)
Monitor: instance of nsk.share.locks.ClassWithSynchronizedMethods(id=981)
Depth: 11
Thread: instance of nsk.share.locks.LockingThread(name='ownedMonitorsAndFrames003_LockingThread1', id=953)
EXPECTED MONITORS (total 4):
Monitor: instance of java.lang.Object(id=980)
Depth: 5
Thread: instance of nsk.share.locks.LockingThread(name='ownedMonitorsAndFrames003_LockingThread1', id=953)
Monitor: instance of java.lang.Class(reflected class=nsk.share.locks.LockingThread, id=950)
Depth: 7
Thread: instance of nsk.share.locks.LockingThread(name='ownedMonitorsAndFrames003_LockingThread1', id=953)
Monitor: instance of nsk.share.locks.ClassWithSynchronizedMethods(id=981)
Depth: 11
Thread: instance of nsk.share.locks.LockingThread(name='ownedMonitorsAndFrames003_LockingThread1', id=953)
Monitor: instance of java.lang.Class(reflected class=nsk.share.locks.ClassWithSynchronizedMethods, id=954)
Depth: 3
Thread: instance of nsk.share.locks.LockingThread(name='ownedMonitorsAndFrames003_LockingThread1', id=953)
Thread frames:
java.lang.Object.wait, line: 384
nsk.share.locks.LockingThread.doWait, line: 443
nsk.share.locks.LockingThread.createStackFrame, line: 285
nsk.share.locks.ClassWithSynchronizedMethods.synchronizedStaticMethod, line: 633
nsk.share.locks.LockingThread.createStackFrame, line: 271
nsk.share.locks.LockingThread.synchronizedObjectBlock, line: 591
nsk.share.locks.LockingThread.createStackFrame, line: 277
nsk.share.locks.LockingThread.synchronizedStaticMethod, line: 481
nsk.share.locks.LockingThread.createStackFrame, line: 273
nsk.share.locks.LockingThread.synchronizedMethod, line: 504
nsk.share.locks.LockingThread.createStackFrame, line: 269
nsk.share.locks.ClassWithSynchronizedMethods.synchronizedMethod, line: 619
nsk.share.locks.LockingThread.createStackFrame, line: 267
nsk.share.locks.LockingThread.run, line: 467
debugee.stderr> In breakpoint method: 'AbstractDebuggeeTest.breakpointMethod()'
debugee.stderr> Debuggee nsk.share.jdi.OwnedMonitorsDebuggee : sending the command: ready
debugee.stderr> Debuggee: received the command: acquireRelinquishedMonitor:ownedMonitorsAndFrames003_LockingThread1
debugee.stderr> ownedMonitorsAndFrames003_LockingThread1: Acquire relinquished monitor: Thread[#63,ownedMonitorsAndFrames003_LockingThread1,5,VirtualThreads]
debugee.stderr> Debuggee nsk.share.jdi.OwnedMonitorsDebuggee : sending the command: ready
binder> Waiting for event by request:
	breakpoint request nsk.share.jpda.AbstractDebuggeeTest:63 (enabled)
debugee.stderr> Debuggee: received the command: forceBreakpoint
binder> Got requested event:
	BreakpointEvent at nsk.share.jpda.AbstractDebuggeeTest:63 in thread OwnedMonitorDebuggeeMainThread
debugee.stderr> In breakpoint method: 'AbstractDebuggeeTest.breakpointMethod()'
debugee.stderr> Debuggee nsk.share.jdi.OwnedMonitorsDebuggee : sending the command: ready
debugee.stderr> Debuggee: received the command: relinquishMonitor:ownedMonitorsAndFrames003_LockingThread1:2
debugee.stderr> ownedMonitorsAndFrames003_LockingThread1: Relinquish monitor: class nsk.share.locks.LockingThread
debugee.stderr> Debuggee nsk.share.jdi.OwnedMonitorsDebuggee : sending the command: ready
binder> Waiting for event by request:
	breakpoint request nsk.share.jpda.AbstractDebuggeeTest:63 (enabled)
debugee.stderr> Debuggee: received the command: forceBreakpoint
binder> Got requested event:
	BreakpointEvent at nsk.share.jpda.AbstractDebuggeeTest:63 in thread OwnedMonitorDebuggeeMainThread
debugee.stderr> In breakpoint method: 'AbstractDebuggeeTest.breakpointMethod()'
debugee.stderr> Debuggee nsk.share.jdi.OwnedMonitorsDebuggee : sending the command: ready
debugee.stderr> Debuggee: received the command: acquireRelinquishedMonitor:ownedMonitorsAndFrames003_LockingThread1
debugee.stderr> ownedMonitorsAndFrames003_LockingThread1: Acquire relinquished monitor: class nsk.share.locks.LockingThread
debugee.stderr> Debuggee nsk.share.jdi.OwnedMonitorsDebuggee : sending the command: ready
binder> Waiting for event by request:
	breakpoint request nsk.share.jpda.AbstractDebuggeeTest:63 (enabled)
debugee.stderr> Debuggee: received the command: forceBreakpoint
binder> Got requested event:
	BreakpointEvent at nsk.share.jpda.AbstractDebuggeeTest:63 in thread OwnedMonitorDebuggeeMainThread
debugee.stderr> In breakpoint method: 'AbstractDebuggeeTest.breakpointMethod()'
debugee.stderr> Debuggee nsk.share.jdi.OwnedMonitorsDebuggee : sending the command: ready
debugee.stderr> Debuggee: received the command: relinquishMonitor:ownedMonitorsAndFrames003_LockingThread1:3
debugee.stderr> ownedMonitorsAndFrames003_LockingThread1: Relinquish monitor: java.lang.Object at 2441ad00
debugee.stderr> Debuggee nsk.share.jdi.OwnedMonitorsDebuggee : sending the command: ready
binder> Waiting for event by request:
	breakpoint request nsk.share.jpda.AbstractDebuggeeTest:63 (enabled)
debugee.stderr> Debuggee: received the command: forceBreakpoint
binder> Got requested event:
	BreakpointEvent at nsk.share.jpda.AbstractDebuggeeTest:63 in thread OwnedMonitorDebuggeeMainThread
debugee.stderr> In breakpoint method: 'AbstractDebuggeeTest.breakpointMethod()'
debugee.stderr> Debuggee nsk.share.jdi.OwnedMonitorsDebuggee : sending the command: ready
debugee.stderr> Debuggee: received the command: acquireRelinquishedMonitor:ownedMonitorsAndFrames003_LockingThread1
debugee.stderr> ownedMonitorsAndFrames003_LockingThread1: Acquire relinquished monitor: java.lang.Object at 2441ad00
debugee.stderr> Debuggee nsk.share.jdi.OwnedMonitorsDebuggee : sending the command: ready
binder> Waiting for event by request:
	breakpoint request nsk.share.jpda.AbstractDebuggeeTest:63 (enabled)
debugee.stderr> Debuggee: received the command: forceBreakpoint
binder> Got requested event:
	BreakpointEvent at nsk.share.jpda.AbstractDebuggeeTest:63 in thread OwnedMonitorDebuggeeMainThread
debugee.stderr> In breakpoint method: 'AbstractDebuggeeTest.breakpointMethod()'
debugee.stderr> Debuggee nsk.share.jdi.OwnedMonitorsDebuggee : sending the command: ready
debugee.stderr> Debuggee: received the command: relinquishMonitor:ownedMonitorsAndFrames003_LockingThread1:4
debugee.stderr> ownedMonitorsAndFrames003_LockingThread1: Relinquish monitor: class nsk.share.locks.ClassWithSynchronizedMethods
debugee.stderr> Debuggee nsk.share.jdi.OwnedMonitorsDebuggee : sending the command: ready
binder> Waiting for event by request:
	breakpoint request nsk.share.jpda.AbstractDebuggeeTest:63 (enabled)
debugee.stderr> Debuggee: received the command: forceBreakpoint
binder> Got requested event:
	BreakpointEvent at nsk.share.jpda.AbstractDebuggeeTest:63 in thread OwnedMonitorDebuggeeMainThread
debugee.stderr> In breakpoint method: 'AbstractDebuggeeTest.breakpointMethod()'
debugee.stderr> Debuggee nsk.share.jdi.OwnedMonitorsDebuggee : sending the command: ready
debugee.stderr> Debuggee: received the command: acquireRelinquishedMonitor:ownedMonitorsAndFrames003_LockingThread1
debugee.stderr> ownedMonitorsAndFrames003_LockingThread1: Acquire relinquished monitor: class nsk.share.locks.ClassWithSynchronizedMethods
debugee.stderr> Debuggee nsk.share.jdi.OwnedMonitorsDebuggee : sending the command: ready
binder> Waiting for event by request:
	breakpoint request nsk.share.jpda.AbstractDebuggeeTest:63 (enabled)
debugee.stderr> Debuggee: received the command: forceBreakpoint
binder> Got requested event:
	BreakpointEvent at nsk.share.jpda.AbstractDebuggeeTest:63 in thread OwnedMonitorDebuggeeMainThread
debugee.stderr> In breakpoint method: 'AbstractDebuggeeTest.breakpointMethod()'
debugee.stderr> Debuggee nsk.share.jdi.OwnedMonitorsDebuggee : sending the command: ready
debugee.stderr> Debuggee: received the command: stopLockingThread:ownedMonitorsAndFrames003_LockingThread1
debugee.stderr> ownedMonitorsAndFrames003_LockingThread1: Exit synchronized static method
debugee.stderr> ownedMonitorsAndFrames003_LockingThread1: Exit synchronized(object) block
debugee.stderr> ownedMonitorsAndFrames003_LockingThread1: Exit synchronized static thread method
debugee.stderr> ownedMonitorsAndFrames003_LockingThread1: Exit synchronized thread method
debugee.stderr> ownedMonitorsAndFrames003_LockingThread1: Exit synchronized method
debugee.stderr> Debuggee nsk.share.jdi.OwnedMonitorsDebuggee : sending the command: ready
binder> Waiting for event by request:
	breakpoint request nsk.share.jpda.AbstractDebuggeeTest:63 (enabled)
debugee.stderr> Debuggee: received the command: forceBreakpoint
binder> Got requested event:
	BreakpointEvent at nsk.share.jpda.AbstractDebuggeeTest:63 in thread OwnedMonitorDebuggeeMainThread
debugee.stderr> In breakpoint method: 'AbstractDebuggeeTest.breakpointMethod()'
debugee.stderr> Debuggee nsk.share.jdi.OwnedMonitorsDebuggee : sending the command: ready
debugee.stderr> Debuggee: received the command: quit
debugee.stderr> Debuggee: exiting
Debuggee's process finished with status: 95
TEST FAILED
</pre>
</details>

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

PR Comment: https://git.openjdk.org/jdk/pull/17626#issuecomment-1929735364

From luhenry at openjdk.org  Tue Feb  6 14:20:05 2024
From: luhenry at openjdk.org (Ludovic Henry)
Date: Tue, 6 Feb 2024 14:20:05 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v6]
In-Reply-To: <3jgZL57F_aikTsAnrGINeQgFHryGBNJZI24-WusdYKM=.f1f64b34-bfbb-4222-afba-c200152075dc@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <xOklXGR_QdSJHh3lcUxV1k4kLWs0TC9wWKZ_eUenbZQ=.5b13ac21-4d7c-482c-b985-a35e19bd89e5@github.com>
 <3cK9QjVQNIgZoWWhrWKEb3XxfbLjprjRMBbStWegH7M=.6df92651-b97d-445a-aa42-302ea791bbea@github.com>
 <lQJoZ_hXjfLO-MRGDLar9L0yD6xAXF1QAu2AIAjwnKk=.390b6b58-3e5d-42af-90e6-2dd76b29172f@github.com>
 <AnHvp-NR-sLPEha8BivPv-pBAmquGjSge4TIludLVHM=.e2866a94-78bb-40d7-8506-9807c5a3d786@github.com>
 <l5WD1cEIW8M7NHd72gK16F1_2cglU3Leeie4zdyCdR4=.6bb73168-2f49-4091-960c-e332694586fa@github.com>
 <3jgZL57F_aikTsAnrGINeQgFHryGBNJZI24-WusdYKM=.f1f64b34-bfbb-4222-afba-c200152075dc@github.com>
Message-ID: <a96a9JuTN8h-WV32oy8r-GQuX3V0pTid2RtMbihwWu4=.373b1b97-0d26-47fc-b0ce-1fbccb8f7596@github.com>

On Tue, 6 Feb 2024 08:20:39 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I'd just hate to see all this work go to waste.

Same here!

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1929780538

From bkilambi at openjdk.org  Tue Feb  6 14:42:03 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Tue, 6 Feb 2024 14:42:03 GMT
Subject: RFR: JDK-8325264: two compiler/intrinsics/float16 tests fail after
 JDK-8324724
Message-ID: <eoR3U5uw7lee-9UJA2qwsyF9u89D_vW83xykuszAMcU=.f70552a1-d96a-4895-99ac-33dfd0942de2@github.com>

Fix for two JTREG test failures on OS_X after this commit - https://github.com/openjdk/jdk/commit/51853f7488afa69c0d14b0e96f1da84822cd83f1.

This is due to no permission to execute the stub code in the code cache. This patch fixes this problem by acquiring "WXExec" to be able to execute the instructions in code cache.

Both the tests - compiler/intrinsics/float16/TestAllFloat16ToFloat.java and compiler/intrinsics/float16/Binary16ConversionNaN.java pass on a MacOS machine.

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

Commit messages:
 - JDK-8325264: two compiler/intrinsics/float16 tests fail after JDK-8324724

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

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

From fyang at openjdk.org  Tue Feb  6 15:03:56 2024
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 6 Feb 2024 15:03:56 GMT
Subject: RFR: 8322179: RISC-V: Implement SHA-1 intrinsic [v9]
In-Reply-To: <pLyu5iq-MnLJ6HzD3V-ecpYIUxjNFgy1OfOgK8H0k1Y=.f58bb714-0da3-4e1d-96b7-81001903e67d@github.com>
References: <PyIXzENfiHysFS3IyZn3FDNQpV7Ua2L6OmjiXq9wRoU=.cf74a45e-c94b-4f7b-8768-d10d55e2ce1d@github.com>
 <pLyu5iq-MnLJ6HzD3V-ecpYIUxjNFgy1OfOgK8H0k1Y=.f58bb714-0da3-4e1d-96b7-81001903e67d@github.com>
Message-ID: <ymJJV73Q8dExbbVRx7GhNVFcP-r_OJzqmviM0f6ymUw=.970efcaa-0221-4198-92ee-9e27f868aa0c@github.com>

On Mon, 5 Feb 2024 10:19:14 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you review this patch to implement SHA-1 intrinsic for riscv?
>> Thanks!
>> 
>> 
>> ## Test
>> 
>> ### Functionality
>> 
>> tests under `test/hotspot/jtreg/compiler/intrinsics/sha`
>> tests found via `find test/jdk -iname "*SHA1*.java"`
>> 
>> ### Performance
>> 
>> tested on `T-HEAD Light Lichee Pi 4A`
>> 
>> JMH_PARAMS="-f 1 -wi 10 -i 20" // for every loop of jmh test
>> 
>> benchmark tests `MessageDigests.java GetMessageDigest.java MessageDigestBench.java MacBench.java` which are under `test/micro/org/openjdk/bench/`, more spcifically `TESTS="MessageDigests.digest MessageDigests.getAndDigest MessageDigestBench.digest"`
>> 
>> 
>> // After
>> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1        64     DEFAULT  avgt   20      1845.446 ?     27.052  ns/op
>> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    181455.350 ?    532.258  ns/op
>> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2447.674 ?     10.239  ns/op
>> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    182896.083 ?   1242.774  ns/op
>> o.o.b.javax.crypto.small.MessageDigestBench.digest         SHA1     1048576             N/A       N/A              avgt   20  11599227.792 ? 121442.390  ns/op
>> // Before
>> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2352.475 ?    11.198  ns/op
>> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    188495.684 ?  1467.942  ns/op
>> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2437.347 ?     6.398  ns/op
>> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    196086.570 ?  1140.998  ns/op
>> o.o.b.javax.crypto.small.MessageDigestBench.digest         SHA1     1048576             N/A       N/A              avgt   20  12362160.119 ? 38788.109  ns/op
>> 
>> 
>> **getAndDigest when size == 64**
>> The data is not stable for test getAndDigest when size == 64, which I think is introduced by  j.s.MessageDigest.getInstance itself, which we don't touch in this patch.
>> Check more details at [1](ht...
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   not pass in temp register explicitly

Thanks for the update. A few more minor comments.

src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 4832:

> 4830:   //    M't,                                      0 <=  t <= 15
> 4831:   //    ROTL'1(W't-3 ^ W't-8 ^ W't-14 ^ W't-16),  16 <= t <= 79
> 4832:   void sha1_prepare_w(int round, Register cur_w, Register ws[], Register buf, Register tmp) {

It seems that we could use `t1` in places where `tmp` is used. Maybe we could further remove this `tmp` formal param (and thus frees `t2`)?

src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 4951:

> 4949:       __ add(cur_w, cur_k, cur_w);
> 4950:       __ add(t, t, cur_w);
> 4951:       __ rolw_imm(cur_w, a, 5, t1);

Since `rolw_imm` uses `t0` as the default temp register, I think a more simpler `__ rolw_imm(cur_w, a, 5);` will do? This also makes `t1` available in places where `tmp` is used. Hopefully, we can free register `t2` and let `src` alias this instead of `x9` thus saving one register saving/restoring respectively on stub entry/exit.

test/hotspot/jtreg/compiler/testlibrary/sha/predicate/IntrinsicPredicates.java line 72:

> 70:     public static final BooleanSupplier SHA1_INSTRUCTION_AVAILABLE
> 71:             = new OrPredicate(new CPUSpecificPredicate("aarch64.*", new String[] { "sha1" }, null),
> 72:               // on riscv64, SHA-1 intrinsic is implemented with basic instructions

How about rephasing this as: `// SHA-1 intrinsic is implemented with scalar instructions on riscv64`?

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

PR Review: https://git.openjdk.org/jdk/pull/17130#pullrequestreview-1862634576
PR Review Comment: https://git.openjdk.org/jdk/pull/17130#discussion_r1479949713
PR Review Comment: https://git.openjdk.org/jdk/pull/17130#discussion_r1478182348
PR Review Comment: https://git.openjdk.org/jdk/pull/17130#discussion_r1478138172

From mli at openjdk.org  Tue Feb  6 15:24:57 2024
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 6 Feb 2024 15:24:57 GMT
Subject: RFR: 8322179: RISC-V: Implement SHA-1 intrinsic [v9]
In-Reply-To: <ymJJV73Q8dExbbVRx7GhNVFcP-r_OJzqmviM0f6ymUw=.970efcaa-0221-4198-92ee-9e27f868aa0c@github.com>
References: <PyIXzENfiHysFS3IyZn3FDNQpV7Ua2L6OmjiXq9wRoU=.cf74a45e-c94b-4f7b-8768-d10d55e2ce1d@github.com>
 <pLyu5iq-MnLJ6HzD3V-ecpYIUxjNFgy1OfOgK8H0k1Y=.f58bb714-0da3-4e1d-96b7-81001903e67d@github.com>
 <ymJJV73Q8dExbbVRx7GhNVFcP-r_OJzqmviM0f6ymUw=.970efcaa-0221-4198-92ee-9e27f868aa0c@github.com>
Message-ID: <Uq_0vrWFodOEX0weaJQeCacgSMKaWESoq6T53EkRjRo=.c3d33329-2b16-4578-9ef4-a2c5c585aec2@github.com>

On Mon, 5 Feb 2024 12:51:24 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   not pass in temp register explicitly
>
> src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 4951:
> 
>> 4949:       __ add(cur_w, cur_k, cur_w);
>> 4950:       __ add(t, t, cur_w);
>> 4951:       __ rolw_imm(cur_w, a, 5, t1);
> 
> Since `rolw_imm` uses `t0` as the default temp register, I think a more simpler `__ rolw_imm(cur_w, a, 5);` will do? This also makes `t1` available in places where `tmp` is used (and thus frees t2).

Not sure, as t0/t1 already used in sha1_f, so `tmp` (`dst` in sha1_f) seems must be another passed-in register.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17130#discussion_r1480023134

From mli at openjdk.org  Tue Feb  6 15:32:57 2024
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 6 Feb 2024 15:32:57 GMT
Subject: RFR: 8322179: RISC-V: Implement SHA-1 intrinsic [v9]
In-Reply-To: <ymJJV73Q8dExbbVRx7GhNVFcP-r_OJzqmviM0f6ymUw=.970efcaa-0221-4198-92ee-9e27f868aa0c@github.com>
References: <PyIXzENfiHysFS3IyZn3FDNQpV7Ua2L6OmjiXq9wRoU=.cf74a45e-c94b-4f7b-8768-d10d55e2ce1d@github.com>
 <pLyu5iq-MnLJ6HzD3V-ecpYIUxjNFgy1OfOgK8H0k1Y=.f58bb714-0da3-4e1d-96b7-81001903e67d@github.com>
 <ymJJV73Q8dExbbVRx7GhNVFcP-r_OJzqmviM0f6ymUw=.970efcaa-0221-4198-92ee-9e27f868aa0c@github.com>
Message-ID: <Zbp4glm4ZTXDCMW_5Wv4lBWT4G7hi0FHnX-kvT0LyjI=.df6b25dd-ee98-4f5c-97a6-d6244109e122@github.com>

On Tue, 6 Feb 2024 14:42:43 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   not pass in temp register explicitly
>
> src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 4832:
> 
>> 4830:   //    M't,                                      0 <=  t <= 15
>> 4831:   //    ROTL'1(W't-3 ^ W't-8 ^ W't-14 ^ W't-16),  16 <= t <= 79
>> 4832:   void sha1_prepare_w(int round, Register cur_w, Register ws[], Register buf, Register tmp) {
> 
> It seems that we could use `t1` in places where `tmp` is used. Maybe we could further remove this `tmp` formal param (and thus frees `t2`)? Together with the above comment, hopefully, we can free register `t2` and let `src` alias this instead of `x9` thus saving one register saving/restoring respectively on stub entry/exit.

Updated, thanks!
But still kept t2, as we need it in sha1_process_round/sha1_f.

> test/hotspot/jtreg/compiler/testlibrary/sha/predicate/IntrinsicPredicates.java line 72:
> 
>> 70:     public static final BooleanSupplier SHA1_INSTRUCTION_AVAILABLE
>> 71:             = new OrPredicate(new CPUSpecificPredicate("aarch64.*", new String[] { "sha1" }, null),
>> 72:               // on riscv64, SHA-1 intrinsic is implemented with basic instructions
> 
> How about rephasing this as: `// SHA-1 intrinsic is implemented with scalar instructions on riscv64`?

Yes, it's better.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17130#discussion_r1480040300
PR Review Comment: https://git.openjdk.org/jdk/pull/17130#discussion_r1480036728

From mli at openjdk.org  Tue Feb  6 15:32:58 2024
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 6 Feb 2024 15:32:58 GMT
Subject: RFR: 8322179: RISC-V: Implement SHA-1 intrinsic [v9]
In-Reply-To: <Uq_0vrWFodOEX0weaJQeCacgSMKaWESoq6T53EkRjRo=.c3d33329-2b16-4578-9ef4-a2c5c585aec2@github.com>
References: <PyIXzENfiHysFS3IyZn3FDNQpV7Ua2L6OmjiXq9wRoU=.cf74a45e-c94b-4f7b-8768-d10d55e2ce1d@github.com>
 <pLyu5iq-MnLJ6HzD3V-ecpYIUxjNFgy1OfOgK8H0k1Y=.f58bb714-0da3-4e1d-96b7-81001903e67d@github.com>
 <ymJJV73Q8dExbbVRx7GhNVFcP-r_OJzqmviM0f6ymUw=.970efcaa-0221-4198-92ee-9e27f868aa0c@github.com>
 <Uq_0vrWFodOEX0weaJQeCacgSMKaWESoq6T53EkRjRo=.c3d33329-2b16-4578-9ef4-a2c5c585aec2@github.com>
Message-ID: <I69Bz7HRj61xclJFc1l2K1ejpSO4-S_z4tWnblVFe7Q=.a0c25366-f2c7-46f8-9df7-e9d19a0b6fae@github.com>

On Tue, 6 Feb 2024 15:22:42 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 4951:
>> 
>>> 4949:       __ add(cur_w, cur_k, cur_w);
>>> 4950:       __ add(t, t, cur_w);
>>> 4951:       __ rolw_imm(cur_w, a, 5, t1);
>> 
>> Since `rolw_imm` uses `t0` as the default temp register, I think a more simpler `__ rolw_imm(cur_w, a, 5);` will do? This also makes `t1` available in places where `tmp` is used (and thus frees t2).
>
> Not sure, as t0/t1 already used in sha1_f, so `tmp` (`dst` in sha1_f) seems must be another passed-in register.

It's changed to `rolw_imm(cur_w, a, 5, t0);`, as IMHO implicit default temp register is error-prone.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17130#discussion_r1480038816

From mli at openjdk.org  Tue Feb  6 15:36:12 2024
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 6 Feb 2024 15:36:12 GMT
Subject: RFR: 8322179: RISC-V: Implement SHA-1 intrinsic [v10]
In-Reply-To: <PyIXzENfiHysFS3IyZn3FDNQpV7Ua2L6OmjiXq9wRoU=.cf74a45e-c94b-4f7b-8768-d10d55e2ce1d@github.com>
References: <PyIXzENfiHysFS3IyZn3FDNQpV7Ua2L6OmjiXq9wRoU=.cf74a45e-c94b-4f7b-8768-d10d55e2ce1d@github.com>
Message-ID: <bAQOJj5ESbBOFxTqNRBDf36jquSMydvN_ey2CleFmD0=.8d3ff5c7-3c78-4113-af39-7dbba435f591@github.com>

> Hi,
> Can you review this patch to implement SHA-1 intrinsic for riscv?
> Thanks!
> 
> 
> ## Test
> 
> ### Functionality
> 
> tests under `test/hotspot/jtreg/compiler/intrinsics/sha`
> tests found via `find test/jdk -iname "*SHA1*.java"`
> 
> ### Performance
> 
> tested on `T-HEAD Light Lichee Pi 4A`
> 
> JMH_PARAMS="-f 1 -wi 10 -i 20" // for every loop of jmh test
> 
> benchmark tests `MessageDigests.java GetMessageDigest.java MessageDigestBench.java MacBench.java` which are under `test/micro/org/openjdk/bench/`, more spcifically `TESTS="MessageDigests.digest MessageDigests.getAndDigest MessageDigestBench.digest"`
> 
> 
> // After
> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1        64     DEFAULT  avgt   20      1845.446 ?     27.052  ns/op
> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    181455.350 ?    532.258  ns/op
> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2447.674 ?     10.239  ns/op
> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    182896.083 ?   1242.774  ns/op
> o.o.b.javax.crypto.small.MessageDigestBench.digest         SHA1     1048576             N/A       N/A              avgt   20  11599227.792 ? 121442.390  ns/op
> // Before
> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2352.475 ?    11.198  ns/op
> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    188495.684 ?  1467.942  ns/op
> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2437.347 ?     6.398  ns/op
> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    196086.570 ?  1140.998  ns/op
> o.o.b.javax.crypto.small.MessageDigestBench.digest         SHA1     1048576             N/A       N/A              avgt   20  12362160.119 ? 38788.109  ns/op
> 
> 
> **getAndDigest when size == 64**
> The data is not stable for test getAndDigest when size == 64, which I think is introduced by  j.s.MessageDigest.getInstance itself, which we don't touch in this patch.
> Check more details at [1](https://github.com/openjdk/jdk/pull/17130#issuecomment-1886805614)
> 
> 
> loop ... ...

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  refine register usage and comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17130/files
  - new: https://git.openjdk.org/jdk/pull/17130/files/e8b01b64..f2976596

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

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

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

From never at openjdk.org  Tue Feb  6 16:25:04 2024
From: never at openjdk.org (Tom Rodriguez)
Date: Tue, 6 Feb 2024 16:25:04 GMT
Subject: RFR: 8317368: [JVMCI] SIGSEGV in
 JVMCIEnv::initialize_installed_code on libgraal [v3]
In-Reply-To: <mjkX-rG6apf-VSRRuovOjK5kjPilRLXTQBnGz2y2D8I=.08dcce97-ac29-4b61-913c-29dd7429f0aa@github.com>
References: <mjkX-rG6apf-VSRRuovOjK5kjPilRLXTQBnGz2y2D8I=.08dcce97-ac29-4b61-913c-29dd7429f0aa@github.com>
Message-ID: <BcrptS75SKoTMZXMoUba9SsJDhLXuUAv0Smnl8FDoiA=.71bb5405-be68-4aa3-8f13-5e5750c56761@github.com>

> This fixes some lurking issues with JVMCI and nmethod related both BarrierSetNMethod and the garbage collection of nmethods.  In particular the stack walking in c2v_iterateFrames visits many frames and needs a KeepStackGCProcessedMark for safety.  Additionally, JVMCI interacts with nmethods in complex ways and needs some sort of strong root during these interactions.  A new JavaThread field has been added that mirrors the way JVMTI keeps nmethods alive.

Tom Rodriguez has updated the pull request incrementally with one additional commit since the last revision:

  Comment updates

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17714/files
  - new: https://git.openjdk.org/jdk/pull/17714/files/429a769f..2a2142fb

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

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

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

From never at openjdk.org  Tue Feb  6 16:30:01 2024
From: never at openjdk.org (Tom Rodriguez)
Date: Tue, 6 Feb 2024 16:30:01 GMT
Subject: RFR: 8324983: race in CompileBroker::possibly_add_compiler_threads
 [v2]
In-Reply-To: <H1Tdo8BVGgjadqg-WL5zE_9tftk7Nfsl5pffxHofLKk=.8b659942-1e54-4071-b9e9-4c932a07dc3e@github.com>
References: <qd8qOUxvTRbavq4rQT5kvA5ujZFdENBsJr_Ggie9hSM=.f88cdff5-4c45-434c-ad70-7faf7981d7f4@github.com>
 <H1Tdo8BVGgjadqg-WL5zE_9tftk7Nfsl5pffxHofLKk=.8b659942-1e54-4071-b9e9-4c932a07dc3e@github.com>
Message-ID: <2GLyulsRx_88eVSDektavuIAt2APTG1AI5NMnFqsuuM=.a67d354d-4528-40a6-8e2c-b15de6a8ad5e@github.com>

On Thu, 1 Feb 2024 17:37:28 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> The number of active compiler threads is decremented before the compiler thread has actually activated so possibly_add_compiler_thread might start a new thread on the existing JavaThread.  This adds a check that it's really exiting before proceeding and some new guarantees that ensure threads aren't started on top running threads.
>
> Tom Rodriguez has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Convert guarantee to assert

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/17662#issuecomment-1927574059

From dnsimon at openjdk.org  Tue Feb  6 16:30:01 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 6 Feb 2024 16:30:01 GMT
Subject: RFR: 8324983: race in CompileBroker::possibly_add_compiler_threads
 [v2]
In-Reply-To: <ls_y-xW9K3FWopI3U1ScWfWAM5d4pdB66b9B48tf0IE=.634b0d48-c95a-4ed2-91e9-0b8f3fc79062@github.com>
References: <qd8qOUxvTRbavq4rQT5kvA5ujZFdENBsJr_Ggie9hSM=.f88cdff5-4c45-434c-ad70-7faf7981d7f4@github.com>
 <ls_y-xW9K3FWopI3U1ScWfWAM5d4pdB66b9B48tf0IE=.634b0d48-c95a-4ed2-91e9-0b8f3fc79062@github.com>
Message-ID: <AAD6sIxGbsl9ZM47AN6IwatEHY8b27S3qKltXzFGczg=.13cf0eb2-2c21-43f6-b64f-536dc75f3e1f@github.com>

On Thu, 1 Feb 2024 03:02:45 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Tom Rodriguez has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Convert guarantee to assert
>
> Good.

Thanks @vnkozlov for approving the backport.

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

PR Comment: https://git.openjdk.org/jdk/pull/17662#issuecomment-1930238168

From never at openjdk.org  Tue Feb  6 16:30:02 2024
From: never at openjdk.org (Tom Rodriguez)
Date: Tue, 6 Feb 2024 16:30:02 GMT
Subject: Integrated: 8324983: race in
 CompileBroker::possibly_add_compiler_threads
In-Reply-To: <qd8qOUxvTRbavq4rQT5kvA5ujZFdENBsJr_Ggie9hSM=.f88cdff5-4c45-434c-ad70-7faf7981d7f4@github.com>
References: <qd8qOUxvTRbavq4rQT5kvA5ujZFdENBsJr_Ggie9hSM=.f88cdff5-4c45-434c-ad70-7faf7981d7f4@github.com>
Message-ID: <BJR8xY8LUGI1q9wEsO2srmeLBXnTIa5iRUoeNqMZo2U=.31e2cabf-bbf1-46e2-990e-1984b9c5c935@github.com>

On Wed, 31 Jan 2024 21:35:05 GMT, Tom Rodriguez <never at openjdk.org> wrote:

> The number of active compiler threads is decremented before the compiler thread has actually activated so possibly_add_compiler_thread might start a new thread on the existing JavaThread.  This adds a check that it's really exiting before proceeding and some new guarantees that ensure threads aren't started on top running threads.

This pull request has now been integrated.

Changeset: 19936526
Author:    Tom Rodriguez <never at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1993652653eab8dd7ce2221a97cd2e401f2dcf56
Stats:     12 lines in 2 files changed: 10 ins; 1 del; 1 mod

8324983: race in CompileBroker::possibly_add_compiler_threads

Reviewed-by: kvn, dholmes, dnsimon

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

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

From tschatzl at openjdk.org  Tue Feb  6 16:30:55 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 6 Feb 2024 16:30:55 GMT
Subject: RFR: 8325221: Obsolete TLABStats
In-Reply-To: <OgGNoY6jWx3-W6IN8vOEoFRUvW9s7i3QE8LZw1tlZgQ=.7a7e456c-8180-484d-aa27-e2f4cb43c362@github.com>
References: <OgGNoY6jWx3-W6IN8vOEoFRUvW9s7i3QE8LZw1tlZgQ=.7a7e456c-8180-484d-aa27-e2f4cb43c362@github.com>
Message-ID: <1rFEkw1OXuBE1TBwvfjUm9bVDUqe5VFo3bJXkyhdpTg=.a25e0611-7e27-46e7-a0f4-d3c5a7d9d701@github.com>

On Mon, 5 Feb 2024 11:12:03 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple obsoletion of a jvm flag.

lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17707#pullrequestreview-1865773975

From dnsimon at openjdk.org  Tue Feb  6 16:51:18 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 6 Feb 2024 16:51:18 GMT
Subject: [jdk22] RFR: 8324983: Race in
 CompileBroker::possibly_add_compiler_threads
Message-ID: <bHbfz7J6XcX_Nbdxm_Bm7DYb2edTsyVi4-TmqZdQLfA=.530b12f0-6d76-4642-880f-4417ba75f89d@github.com>

Hi all,

This pull request contains a backport of commit [19936526](https://github.com/openjdk/jdk/commit/1993652653eab8dd7ce2221a97cd2e401f2dcf56) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Tom Rodriguez on 5 Feb 2024 and was reviewed by Vladimir Kozlov, David Holmes and Doug Simon.

Thanks!

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

Commit messages:
 - Backport 1993652653eab8dd7ce2221a97cd2e401f2dcf56

Changes: https://git.openjdk.org/jdk22/pull/108/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=108&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8324983
  Stats: 12 lines in 2 files changed: 10 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk22/pull/108.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/108/head:pull/108

PR: https://git.openjdk.org/jdk22/pull/108

From kvn at openjdk.org  Tue Feb  6 17:24:06 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 6 Feb 2024 17:24:06 GMT
Subject: [jdk22] RFR: 8324983: Race in
 CompileBroker::possibly_add_compiler_threads
In-Reply-To: <bHbfz7J6XcX_Nbdxm_Bm7DYb2edTsyVi4-TmqZdQLfA=.530b12f0-6d76-4642-880f-4417ba75f89d@github.com>
References: <bHbfz7J6XcX_Nbdxm_Bm7DYb2edTsyVi4-TmqZdQLfA=.530b12f0-6d76-4642-880f-4417ba75f89d@github.com>
Message-ID: <jEXWQEsHvAPpBIzSD-HLJscPy04ZVvfxrDr7r76t778=.3a2138ca-e17c-4854-807f-01ace8fae196@github.com>

On Tue, 6 Feb 2024 16:46:23 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [19936526](https://github.com/openjdk/jdk/commit/1993652653eab8dd7ce2221a97cd2e401f2dcf56) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Tom Rodriguez on 5 Feb 2024 and was reviewed by Vladimir Kozlov, David Holmes and Doug Simon.
> 
> Thanks!

Good.

Was it "clean" backport?

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk22/pull/108#pullrequestreview-1865914906

From dnsimon at openjdk.org  Tue Feb  6 17:24:06 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 6 Feb 2024 17:24:06 GMT
Subject: [jdk22] RFR: 8324983: Race in
 CompileBroker::possibly_add_compiler_threads
In-Reply-To: <jEXWQEsHvAPpBIzSD-HLJscPy04ZVvfxrDr7r76t778=.3a2138ca-e17c-4854-807f-01ace8fae196@github.com>
References: <bHbfz7J6XcX_Nbdxm_Bm7DYb2edTsyVi4-TmqZdQLfA=.530b12f0-6d76-4642-880f-4417ba75f89d@github.com>
 <jEXWQEsHvAPpBIzSD-HLJscPy04ZVvfxrDr7r76t778=.3a2138ca-e17c-4854-807f-01ace8fae196@github.com>
Message-ID: <Jck9opQ5R31fe4G3uzC3hA2XhE-T67sUH3cIkuRCfuE=.c8d6f270-0057-4705-9f6b-b02954d577a2@github.com>

On Tue, 6 Feb 2024 17:19:09 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Was it "clean" backport?

This PR was automatically generated by the `/backport` Skara command so I believe that means the backport was "clean". Is that right?

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

PR Comment: https://git.openjdk.org/jdk22/pull/108#issuecomment-1930411361

From rrich at openjdk.org  Tue Feb  6 17:35:58 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Tue, 6 Feb 2024 17:35:58 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v10]
In-Reply-To: <wL168lSWSS1EHp_v9lraUQySJ3WzFD7uoWOIolAtUaU=.cea57d21-687c-44e9-86f7-7ca38930fc87@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
 <wL168lSWSS1EHp_v9lraUQySJ3WzFD7uoWOIolAtUaU=.cea57d21-687c-44e9-86f7-7ca38930fc87@github.com>
Message-ID: <RD2g7osBOIHA89_ACtO3yeuzawPqx-LnIhIqco-z8Kw=.f09ded76-da8b-4fa1-8955-f2283d52eafa@github.com>

On Mon, 5 Feb 2024 06:51:22 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The `ObjectSynchronizer` has always assumed that the `current` parameters are both the current thread as well as the thread that is doing the locking. The only time that we are entering on behalf of another thread is when doing re-locking in deoptimization. This has worked because the deoptee thread is suspended. However ResourceMarks have been using the wrong thread when logging is enabled.
>> 
>> This change `ObjectSynchronizer` instruments the relevant methods with both a `JavaThread* locking_thread` as well as `[Java]Thread* current` to be able to use the correct thread for ResourceMarks. 
>> 
>> Having the `inflate` care about a `locking_thread` is a little unpleasant in my opinion. But it is required for LM_LIGHTWEIGHT. 
>> Would probably be cleaner if the inflate for LM_LIGHTWEIGHT was it's own thing, as it does not share the whole INFLATING protocol. But seems like a future RFE to refactor this code.
>> 
>> Can reproduce a crash by modifying `test/jdk/com/sun/jdi/EATests.java` and using `-XX:DiagnoseSyncOnValueBasedClasses=2` with LM_LEGACY or running `test/jdk/com/sun/jdi/EATests.java` with LM_LIGHTWEIGHT/LM_MONITOR and `-Xlog:monitorinflation=trace`. 
>> 
>> Could extend this test to capture this regression in the future (or creating a new test based on the same infrastructure). Will give it an attempt, so we have a regression test for this. But these tests get rather involved as the require a lot of jvmti setup.
>
> Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8324881
>  - Update comment
>  - Fix comments
>  - Update test/jdk/com/sun/jdi/EATests.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update test/jdk/com/sun/jdi/EATests.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update test/jdk/com/sun/jdi/EATests.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update test/jdk/com/sun/jdi/EATests.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Remove newline
>  - Update src/hotspot/share/runtime/synchronizer.hpp
>    
>    Co-authored-by: Richard Reingruber <richard.reingruber at sap.com>
>  - Improve EARelockingNestedInflated_03 for LM_LIGHTWEIGHT
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/de588318...b3cc401c

I've had a look at the test. It could be a spurious wakeup. But that's not very likely I reckon. Could it also be that the thread was interrupted? Was the runtime close to the timeout? But it's again very unlikely that the monitor information is captured right at that location while the interrupt is being thrown.

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

PR Comment: https://git.openjdk.org/jdk/pull/17626#issuecomment-1930437526

From kvn at openjdk.org  Tue Feb  6 17:50:00 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 6 Feb 2024 17:50:00 GMT
Subject: [jdk22] RFR: 8324983: Race in
 CompileBroker::possibly_add_compiler_threads
In-Reply-To: <Jck9opQ5R31fe4G3uzC3hA2XhE-T67sUH3cIkuRCfuE=.c8d6f270-0057-4705-9f6b-b02954d577a2@github.com>
References: <bHbfz7J6XcX_Nbdxm_Bm7DYb2edTsyVi4-TmqZdQLfA=.530b12f0-6d76-4642-880f-4417ba75f89d@github.com>
 <jEXWQEsHvAPpBIzSD-HLJscPy04ZVvfxrDr7r76t778=.3a2138ca-e17c-4854-807f-01ace8fae196@github.com>
 <Jck9opQ5R31fe4G3uzC3hA2XhE-T67sUH3cIkuRCfuE=.c8d6f270-0057-4705-9f6b-b02954d577a2@github.com>
Message-ID: <8ahAFXmJGc-3UwGkiEFlfQV9nQBLq1aL4FOM-FtjiE0=.a9bdf4d7-afc3-47f0-807e-307fd9f090e4@github.com>

On Tue, 6 Feb 2024 17:21:27 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> > Was it "clean" backport?
> 
> This PR was automatically generated by the `/backport` Skara command so I believe that means the backport was "clean". Is that right?

Yes, I missed that it was auto-generated.

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

PR Comment: https://git.openjdk.org/jdk22/pull/108#issuecomment-1930460637

From kcr at openjdk.org  Tue Feb  6 19:33:05 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 6 Feb 2024 19:33:05 GMT
Subject: [jdk22] RFR: 8324983: Race in
 CompileBroker::possibly_add_compiler_threads
In-Reply-To: <8ahAFXmJGc-3UwGkiEFlfQV9nQBLq1aL4FOM-FtjiE0=.a9bdf4d7-afc3-47f0-807e-307fd9f090e4@github.com>
References: <bHbfz7J6XcX_Nbdxm_Bm7DYb2edTsyVi4-TmqZdQLfA=.530b12f0-6d76-4642-880f-4417ba75f89d@github.com>
 <jEXWQEsHvAPpBIzSD-HLJscPy04ZVvfxrDr7r76t778=.3a2138ca-e17c-4854-807f-01ace8fae196@github.com>
 <Jck9opQ5R31fe4G3uzC3hA2XhE-T67sUH3cIkuRCfuE=.c8d6f270-0057-4705-9f6b-b02954d577a2@github.com>
 <8ahAFXmJGc-3UwGkiEFlfQV9nQBLq1aL4FOM-FtjiE0=.a9bdf4d7-afc3-47f0-807e-307fd9f090e4@github.com>
Message-ID: <SW1zTih_qHc6cGTQYKZ8dPRLY3dH35R92oFSNxl1-LA=.3bfc55e7-ea9a-4408-945e-9ca3602d8a7f@github.com>

On Tue, 6 Feb 2024 17:46:55 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> This PR was automatically generated by the `/backport` Skara command so I believe that means the backport was "clean". Is that right?

Mote to the point, Skara checks all PRs (whether or not generated via the `/backport` command) and adds the `clean` label if the backport is clean, which it did in this case. See [this comment above](https://github.com/openjdk/jdk22/pull/108#issuecomment-1930331071).

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

PR Comment: https://git.openjdk.org/jdk22/pull/108#issuecomment-1930616584

From never at openjdk.org  Tue Feb  6 20:04:54 2024
From: never at openjdk.org (Tom Rodriguez)
Date: Tue, 6 Feb 2024 20:04:54 GMT
Subject: [jdk22] RFR: 8324983: Race in
 CompileBroker::possibly_add_compiler_threads
In-Reply-To: <bHbfz7J6XcX_Nbdxm_Bm7DYb2edTsyVi4-TmqZdQLfA=.530b12f0-6d76-4642-880f-4417ba75f89d@github.com>
References: <bHbfz7J6XcX_Nbdxm_Bm7DYb2edTsyVi4-TmqZdQLfA=.530b12f0-6d76-4642-880f-4417ba75f89d@github.com>
Message-ID: <J28SZFggF9YmSGwWf9LSgY2MBgQJkTEN0QlIe-qbvnA=.84b0fb40-b9e7-49c0-ad80-984983450cda@github.com>

On Tue, 6 Feb 2024 16:46:23 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [19936526](https://github.com/openjdk/jdk/commit/1993652653eab8dd7ce2221a97cd2e401f2dcf56) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Tom Rodriguez on 5 Feb 2024 and was reviewed by Vladimir Kozlov, David Holmes and Doug Simon.
> 
> Thanks!

Marked as reviewed by never (Reviewer).

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

PR Review: https://git.openjdk.org/jdk22/pull/108#pullrequestreview-1866214529

From pchilanomate at openjdk.org  Tue Feb  6 20:14:56 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 6 Feb 2024 20:14:56 GMT
Subject: RFR: 8320302: compiler/arguments/TestC1Globals.java hits SIGSEGV
 in ContinuationEntry::set_enter_code [v3]
In-Reply-To: <6eYoo4WQi_LO5YFtxZQbpxFeNxQFnpTjgfIvyPukWNA=.1448ac51-5e4a-43f3-ae17-aa5eeeee0538@github.com>
References: <1Cm1SGGaZsYxM-RfPNDeAvnGijQ-taVe438SS6bZ3YI=.d64abde2-f9a0-4589-ab40-eba7c3c02992@github.com>
 <9mMLOqVHnFrYcKY5FLgIwd_j9RQtk68s9vdqaABGt_o=.bd743e24-484e-4120-9be3-a81f7022d332@github.com>
 <6eYoo4WQi_LO5YFtxZQbpxFeNxQFnpTjgfIvyPukWNA=.1448ac51-5e4a-43f3-ae17-aa5eeeee0538@github.com>
Message-ID: <mYespY0oqvVFcx468YZJ80YqCSnEuk3FAz-W839Q4qM=.df0dcd66-543e-4039-bc24-6e809cf4b381@github.com>

On Tue, 6 Feb 2024 05:15:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo 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 JDK-8320302
>>  - use vm_exit_during_initialization instead of fatal
>>  - inline call to initialize cont class
>>  - v1
>
> src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp line 1747:
> 
>> 1745:                                               oop_maps,
>> 1746:                                               exception_offset);
>> 1747:     if (nm == nullptr) vm_exit_during_initialization("Initial size of CodeCache is too small");
> 
> IIUC `AdapterHandlerLibrary::create_native_wrapper`  is the only caller of `generate_native_wrapper` so it is only called during VM init now. But not sure it wouldn't be better/cleaner to simply return nullptr here and have `AdapterHandlerLibrary::create_native_wrapper` do the `vm_exit_during_initialization`?

We could do that too. We have to check for nullptr && method->is_continuation_native_intrinsic() since AdapterHandlerLibrary::create_native_wrapper() itself is called from 2 other places which should not fail with vm_exit_during_initialization() if creation of the native nmethod failed. I don't have a preference, both ways are fine with me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17455#discussion_r1480481182

From fweimer at redhat.com  Tue Feb  6 20:31:56 2024
From: fweimer at redhat.com (Florian Weimer)
Date: Tue, 06 Feb 2024 21:31:56 +0100
Subject: Use of C++ dynamic global object initialization with thread guards
In-Reply-To: <CC98742A-876D-4D7B-B20D-C6ED77059B0A@oracle.com> (Kim Barrett's
 message of "Tue, 19 Dec 2023 17:23:38 +0000")
References: <87fs0izasf.fsf@oldenburg.str.redhat.com>
 <514F5A61-E3C2-4B24-A567-EF19C4292989@oracle.com>
 <87lea7d2o7.fsf@oldenburg.str.redhat.com>
 <CC98742A-876D-4D7B-B20D-C6ED77059B0A@oracle.com>
Message-ID: <87a5ode3lv.fsf@oldenburg.str.redhat.com>

* Kim Barrett:

>> On Dec 6, 2023, at 5:51 AM, Florian Weimer <fweimer at redhat.com> wrote:
>> 
>> * Kim Barrett:
>> 
>>>> The implementation of __cxa_guard_acquire is not entirely trivial
>>>> because it detects recursive initialization and throws
>>>> __gnu_cxx::recursive_init_error, which means that it pulls in the C++
>>>> unwinder (at least with a traditional GNU/Linux build of libstdc++.a).
>>> 
>>> Does it?  Seems like it shouldn?t.  We build with -fno-exceptions, and
>>> the definition of throw_recursive_init_exception is conditionalized on
>>> __cpp_exceptions, only throwing when that macro is defined.  It calls
>>> __builtin_trap() if that macro isn?t defined.
>> 
>> With upstream GCC (and presumably most distributions), there's one
>> libstdc++.a with one implementation of __cxa_guard_acquire, and it's
>> built with exception support.
>> 
>> It's supposed to be possible to build libstdc++ without exception
>> support, but upstream GCC doesn't do this automatically for you if the
>> target supports exception handling.  In principle, the GCC specs
>> mechanism allows you to treat -fno-exceptions as a linker flag and link
>> against a custom no-exceptions build of libstdc++.a.
>> 
>> Maybe this is what your toolchain is doing if you don't see the unwinder
>> symbols in your builds?  It should be easy enough to check if you have a
>> build with a symbol table: look for a call in __cxa_throw in the
>> disassembly of __cxa_guard_acquire.cold or __cxa_guard_acquire.  One of
>> our builds looks like this:
>
> I've verified that the same is happening in Oracle builds.  We don't build an
> exception-disabled libstdc++ as part of our devkit either.
>
> So my next question is, exactly what is the harm, and how serious is it? So
> far, I don't know of anyone noticing a problem arising from this.

I had hoped that I could introduce this piece by piece. 8-)

I was investigating a way to backdate the glibc version requirement to
glibc 2.12 (or glibc 2.17 for AArch64 and POWER) without a devkit.  The
idea is to use a system toolchain on a modern system (I used glibc 2.34
with GCC 11 on RHEL 9) and end up with a binary that can run ancient
systems.  This is based on the observation that OpenJDK uses a subset of
glibc which has a stable ABI across symbol versions (no glob, for
example), so it's only necessary to supply stub .so files for linking,
plus a few statically linked stubs for the old __xstat interfaces.  The
system headers can be used as is for compiling OpenJDK.  Even the
current glibc startup files work because the main executables do not
depend on the execution of their ELF constructors.  Among the directly
linked in shared objects, only glibc has symbol versioning information,
so no other stubs were needed.  All in all it was pleasently
straightforward.

But I did not expect the significant dependencies on libstdc++.  The
__cxa_guard_acquire function is just one aspect of this.  It forced me
to stick with a glibc 2.34 system because with GCC 12/glibc 2.35 and
later, the ELF-specific part of the unwinder is gone from libgcc_eh.a
and is now dynamically linked from glibc (via the _dl_find_object
function).  Obviously, _dl_find_object does not exist in older glibc
versions, so this rather trivial backdating approach does not work.  I
could supply an always-failing stub for _dl_find_object to address this
issue because we do not expect unwinding to occur, and this should allow
building against later glibc/GCC combinations.  It's still ugly because
it's not a forward-looking change.  With extensive dependencies on
libstdc++ functionality and more expected to come, glibc or GCC updates
will likely require further changes.  If it were just about adhering to
-fno-exceptions, we could probably change GCC upstream to link with a
-fno-exceptions build of libstdc++.a, turning -fno-exceptions into a
linker flag as well (I already asked).  But based on your comments, I
get the impression that limited use of libstdc++ is probably a temporary
affair.

A complicated dependency that cannot simply be stubbed out already
exists: thread_local variables with destructors introduce a dependency
on __cxa_thread_atexit_impl at GLIBC_2.18.  I believe use of thread_local
destructors is probably not worth the hidden complexity.  Hotspot
already uses pthread_key_create with a destructor callback function
elsewhere.  For deterministic shutdown ordering independent of glibc
version, all shutdown activities should probably be called from there.
(On glibc 2.17 and earlier, GCC uses a pthread_key_create-based
emulation internally, with potentially different invocation order with
the other pthread_key_create destructor.  That seems an unnecessary
divergence even with the existing devkit builds.)  For my experiment I
just replaced the thread_local destructor callback with another
pthread_key_create (similar to what must happen with the devkit builds).

The stub generation is really simple, much easier than maintaining a
full toolchain (e.g., if you use a system toolchain, you get the
recent-ish AArch64 backend changes and subsequent fixes automatically;
they are not included in GCC 11.3).  But it seems the idea is rooted in
on a false premise regarding Hotspot's libstdc++ usage.

I hope this explains why I was looking into this.

Thanks,
Florian


From dnsimon at openjdk.org  Tue Feb  6 21:59:08 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 6 Feb 2024 21:59:08 GMT
Subject: [jdk22] RFR: 8324983: Race in
 CompileBroker::possibly_add_compiler_threads
In-Reply-To: <bHbfz7J6XcX_Nbdxm_Bm7DYb2edTsyVi4-TmqZdQLfA=.530b12f0-6d76-4642-880f-4417ba75f89d@github.com>
References: <bHbfz7J6XcX_Nbdxm_Bm7DYb2edTsyVi4-TmqZdQLfA=.530b12f0-6d76-4642-880f-4417ba75f89d@github.com>
Message-ID: <MZdRXcKUqg3dro3k0fNrsQq8yKlcPFaojckKe8RBcBM=.89647bfe-c784-4c76-980b-bf39bfd32681@github.com>

On Tue, 6 Feb 2024 16:46:23 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [19936526](https://github.com/openjdk/jdk/commit/1993652653eab8dd7ce2221a97cd2e401f2dcf56) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Tom Rodriguez on 5 Feb 2024 and was reviewed by Vladimir Kozlov, David Holmes and Doug Simon.
> 
> Thanks!

Mach5 testing clean. Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk22/pull/108#issuecomment-1930816856

From dnsimon at openjdk.org  Tue Feb  6 21:59:08 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 6 Feb 2024 21:59:08 GMT
Subject: [jdk22] Integrated: 8324983: Race in
 CompileBroker::possibly_add_compiler_threads
In-Reply-To: <bHbfz7J6XcX_Nbdxm_Bm7DYb2edTsyVi4-TmqZdQLfA=.530b12f0-6d76-4642-880f-4417ba75f89d@github.com>
References: <bHbfz7J6XcX_Nbdxm_Bm7DYb2edTsyVi4-TmqZdQLfA=.530b12f0-6d76-4642-880f-4417ba75f89d@github.com>
Message-ID: <BOr3jHCBJFHejefibKOyJ9nnKAvoAcGlf9AUtugx3dI=.12a1728f-3a9a-4639-b414-b10ce5a903ee@github.com>

On Tue, 6 Feb 2024 16:46:23 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [19936526](https://github.com/openjdk/jdk/commit/1993652653eab8dd7ce2221a97cd2e401f2dcf56) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Tom Rodriguez on 5 Feb 2024 and was reviewed by Vladimir Kozlov, David Holmes and Doug Simon.
> 
> Thanks!

This pull request has now been integrated.

Changeset: d8dc7118
Author:    Doug Simon <dnsimon at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/d8dc7118fd39e0be9ce0606ad41bf4fb3853a747
Stats:     12 lines in 2 files changed: 10 ins; 1 del; 1 mod

8324983: Race in CompileBroker::possibly_add_compiler_threads

Reviewed-by: kvn, never
Backport-of: 1993652653eab8dd7ce2221a97cd2e401f2dcf56

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

PR: https://git.openjdk.org/jdk22/pull/108

From kbarrett at openjdk.org  Tue Feb  6 22:13:09 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 6 Feb 2024 22:13:09 GMT
Subject: RFR: 8325347: Rename native_thread.h
Message-ID: <mybH8Z22XNxVRmvpqmsw57qeCZ_3Z2jfj1R73ysksZM=.e8d9382f-2533-41e1-8e50-7237bca878e0@github.com>

Please review this trivial change that renames the file
test/hotspot/jtreg/vmTestbase/nsk/share/native/native_thread.h
to native_thread.hpp. and replaces uses of NULL in that file.

Testing: mach5 tier1

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

Commit messages:
 - rename NULLs in native_thread.hpp
 - rename native_thread.h

Changes: https://git.openjdk.org/jdk/pull/17737/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17737&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8325347
  Stats: 171 lines in 14 files changed: 78 ins; 78 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/17737.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17737/head:pull/17737

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

From kbarrett at openjdk.org  Tue Feb  6 22:22:53 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 6 Feb 2024 22:22:53 GMT
Subject: RFR: 8325221: Obsolete TLABStats
In-Reply-To: <OgGNoY6jWx3-W6IN8vOEoFRUvW9s7i3QE8LZw1tlZgQ=.7a7e456c-8180-484d-aa27-e2f4cb43c362@github.com>
References: <OgGNoY6jWx3-W6IN8vOEoFRUvW9s7i3QE8LZw1tlZgQ=.7a7e456c-8180-484d-aa27-e2f4cb43c362@github.com>
Message-ID: <jOCSMp49gP0tyaM9Gfw7mo5q8T7THUYUhrdxRbhKPYE=.705c50b3-b1de-41a6-85a2-3104dee8eaa7@github.com>

On Mon, 5 Feb 2024 11:12:03 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple obsoletion of a jvm flag.

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17707#pullrequestreview-1866434149

From coleenp at openjdk.org  Tue Feb  6 22:32:53 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 6 Feb 2024 22:32:53 GMT
Subject: RFR: 8325347: Rename native_thread.h
In-Reply-To: <mybH8Z22XNxVRmvpqmsw57qeCZ_3Z2jfj1R73ysksZM=.e8d9382f-2533-41e1-8e50-7237bca878e0@github.com>
References: <mybH8Z22XNxVRmvpqmsw57qeCZ_3Z2jfj1R73ysksZM=.e8d9382f-2533-41e1-8e50-7237bca878e0@github.com>
Message-ID: <EN1k8mHGJ6H11kSEFH9zO-ugpRaDh1kYib1SQidQq-M=.31fc9d6b-835d-4b9f-b68d-fdb7e111094b@github.com>

On Tue, 6 Feb 2024 22:08:18 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this trivial change that renames the file
> test/hotspot/jtreg/vmTestbase/nsk/share/native/native_thread.h
> to native_thread.hpp. and replaces uses of NULL in that file.
> 
> Testing: mach5 tier1

Agree this looks trivial, if tests complete.

edit: I think the test build would fail if one of these .h includes was missed.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17737#pullrequestreview-1866446137

From lmesnik at openjdk.org  Tue Feb  6 23:07:59 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 6 Feb 2024 23:07:59 GMT
Subject: RFR: 8325347: Rename native_thread.h
In-Reply-To: <mybH8Z22XNxVRmvpqmsw57qeCZ_3Z2jfj1R73ysksZM=.e8d9382f-2533-41e1-8e50-7237bca878e0@github.com>
References: <mybH8Z22XNxVRmvpqmsw57qeCZ_3Z2jfj1R73ysksZM=.e8d9382f-2533-41e1-8e50-7237bca878e0@github.com>
Message-ID: <Yt7mzaq12ugnICZIm4mtBxcHTT_ODBDt8BWtwCGucQw=.e8512092-78d1-4743-a17b-c10d413bab94@github.com>

On Tue, 6 Feb 2024 22:08:18 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this trivial change that renames the file
> test/hotspot/jtreg/vmTestbase/nsk/share/native/native_thread.h
> to native_thread.hpp. and replaces uses of NULL in that file.
> 
> Testing: mach5 tier1

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17737#pullrequestreview-1866483869

From kbarrett at openjdk.org  Tue Feb  6 23:46:57 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 6 Feb 2024 23:46:57 GMT
Subject: RFR: 8325347: Rename native_thread.h
In-Reply-To: <EN1k8mHGJ6H11kSEFH9zO-ugpRaDh1kYib1SQidQq-M=.31fc9d6b-835d-4b9f-b68d-fdb7e111094b@github.com>
References: <mybH8Z22XNxVRmvpqmsw57qeCZ_3Z2jfj1R73ysksZM=.e8d9382f-2533-41e1-8e50-7237bca878e0@github.com>
 <EN1k8mHGJ6H11kSEFH9zO-ugpRaDh1kYib1SQidQq-M=.31fc9d6b-835d-4b9f-b68d-fdb7e111094b@github.com>
Message-ID: <nX4N0HSM8OsMWwzDAYVgyb3D6Q4N5pZglBtQprUZ8gs=.e9500f67-f356-4b97-bb42-c7ab1c291ec7@github.com>

On Tue, 6 Feb 2024 22:30:18 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this trivial change that renames the file
>> test/hotspot/jtreg/vmTestbase/nsk/share/native/native_thread.h
>> to native_thread.hpp. and replaces uses of NULL in that file.
>> 
>> Testing: mach5 tier1
>
> Agree this looks trivial, if tests complete.
> 
> edit: I think the test build would fail if one of these .h includes was missed.

Thanks for reviews, @coleenp and @lmesnik .

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

PR Comment: https://git.openjdk.org/jdk/pull/17737#issuecomment-1930952491

From kbarrett at openjdk.org  Tue Feb  6 23:46:58 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 6 Feb 2024 23:46:58 GMT
Subject: Integrated: 8325347: Rename native_thread.h
In-Reply-To: <mybH8Z22XNxVRmvpqmsw57qeCZ_3Z2jfj1R73ysksZM=.e8d9382f-2533-41e1-8e50-7237bca878e0@github.com>
References: <mybH8Z22XNxVRmvpqmsw57qeCZ_3Z2jfj1R73ysksZM=.e8d9382f-2533-41e1-8e50-7237bca878e0@github.com>
Message-ID: <naCbxy4aXIUgy64RytOiXcqv56J2p2Z8biupQdD1LhI=.73102bf8-8886-4e2e-90b7-db9365793b53@github.com>

On Tue, 6 Feb 2024 22:08:18 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this trivial change that renames the file
> test/hotspot/jtreg/vmTestbase/nsk/share/native/native_thread.h
> to native_thread.hpp. and replaces uses of NULL in that file.
> 
> Testing: mach5 tier1

This pull request has now been integrated.

Changeset: f2f63444
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f2f634448e2095f2be1c220d7c10355ab4888439
Stats:     171 lines in 14 files changed: 78 ins; 78 del; 15 mod

8325347: Rename native_thread.h

Reviewed-by: coleenp, lmesnik

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

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

From dcubed at openjdk.org  Tue Feb  6 23:53:00 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 6 Feb 2024 23:53:00 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v10]
In-Reply-To: <wL168lSWSS1EHp_v9lraUQySJ3WzFD7uoWOIolAtUaU=.cea57d21-687c-44e9-86f7-7ca38930fc87@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
 <wL168lSWSS1EHp_v9lraUQySJ3WzFD7uoWOIolAtUaU=.cea57d21-687c-44e9-86f7-7ca38930fc87@github.com>
Message-ID: <Z9WlSkk7UrfNrU903GCPL4CwyzkoOVMhpSUe1nxKs4s=.ff15cd0e-8c45-454d-9c9b-7935134e6249@github.com>

On Mon, 5 Feb 2024 06:51:22 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The `ObjectSynchronizer` has always assumed that the `current` parameters are both the current thread as well as the thread that is doing the locking. The only time that we are entering on behalf of another thread is when doing re-locking in deoptimization. This has worked because the deoptee thread is suspended. However ResourceMarks have been using the wrong thread when logging is enabled.
>> 
>> This change `ObjectSynchronizer` instruments the relevant methods with both a `JavaThread* locking_thread` as well as `[Java]Thread* current` to be able to use the correct thread for ResourceMarks. 
>> 
>> Having the `inflate` care about a `locking_thread` is a little unpleasant in my opinion. But it is required for LM_LIGHTWEIGHT. 
>> Would probably be cleaner if the inflate for LM_LIGHTWEIGHT was it's own thing, as it does not share the whole INFLATING protocol. But seems like a future RFE to refactor this code.
>> 
>> Can reproduce a crash by modifying `test/jdk/com/sun/jdi/EATests.java` and using `-XX:DiagnoseSyncOnValueBasedClasses=2` with LM_LEGACY or running `test/jdk/com/sun/jdi/EATests.java` with LM_LIGHTWEIGHT/LM_MONITOR and `-Xlog:monitorinflation=trace`. 
>> 
>> Could extend this test to capture this regression in the future (or creating a new test based on the same infrastructure). Will give it an attempt, so we have a regression test for this. But these tests get rather involved as the require a lot of jvmti setup.
>
> Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8324881
>  - Update comment
>  - Fix comments
>  - Update test/jdk/com/sun/jdi/EATests.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update test/jdk/com/sun/jdi/EATests.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update test/jdk/com/sun/jdi/EATests.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update test/jdk/com/sun/jdi/EATests.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Remove newline
>  - Update src/hotspot/share/runtime/synchronizer.hpp
>    
>    Co-authored-by: Richard Reingruber <richard.reingruber at sap.com>
>  - Improve EARelockingNestedInflated_03 for LM_LIGHTWEIGHT
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/71bd9124...b3cc401c

I previously reviewed the V04 full webrev and this time I reviewed the v09 full webrev. Thumbs up. I have just one question about an assert below, a comment suggestion and a spacing nit.

Very nice job on this gnarly fix.

src/hotspot/share/runtime/synchronizer.cpp line 525:

> 523:         return;
> 524:       }
> 525:       assert(monitor->is_being_async_deflated(), "must be");

You've added this assertion here after the `enter_for` must have lost the
race to async deflation, but you didn't add the same assertion below
after L540 -> L542. Why not?

src/hotspot/share/runtime/synchronizer.cpp line 546:

> 544:           return;
> 545:         }
> 546:         // Fall through to inflate() ...

You removed this comment here, but there is also this comment:
L578: // All other paths fall-through to inflate-enter.

For both of those, I would have updated to say something about
falling through to returning false instead of deletion.

test/jdk/com/sun/jdi/EATests.java line 2019:

> 2017:                 }
> 2018:             }
> 2019:             synchronized(lockInflatedByContention) { // will block and trigger inflation

nit space after `synchronized`.

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

Marked as reviewed by dcubed (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17626#pullrequestreview-1866519912
PR Review Comment: https://git.openjdk.org/jdk/pull/17626#discussion_r1480662827
PR Review Comment: https://git.openjdk.org/jdk/pull/17626#discussion_r1480665913
PR Review Comment: https://git.openjdk.org/jdk/pull/17626#discussion_r1480670313

From dlong at openjdk.org  Tue Feb  6 23:54:53 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 6 Feb 2024 23:54:53 GMT
Subject: RFR: 8324824: AArch64: Detect Ampere-1B core and update default
 options for Ampere CPUs
In-Reply-To: <N9ZCzxRwamt4YTT5wNJottgQ7FYJX4SQrrFxv11Ramg=.4881b622-6d73-4c12-beb3-d65ce465f076@github.com>
References: <N9ZCzxRwamt4YTT5wNJottgQ7FYJX4SQrrFxv11Ramg=.4881b622-6d73-4c12-beb3-d65ce465f076@github.com>
Message-ID: <5Nd9-utKMTrZl2HjpiYkdJJIq9U0dtPBmX5iBpfHOdY=.0bfe4fa1-793b-4bf3-a176-78b0a2dcb02b@github.com>

On Tue, 6 Feb 2024 07:13:22 GMT, Patrick Zhang <qpzhang at openjdk.org> wrote:

> Added CPU detection for Ampere-1B, and updated the default options for AmpereOne, Ampere-1A/1B to have `-XX:+UseSIMDForMemoryOps` and `-XX:OnSpinWaitInst=isb -XX:OnSpinWaitInstCount=2`.
> 
> Tests done:
> 1. GitHub Actions (GHA) sanity tests: https://github.com/cnqpzhang/jdk/actions/runs/7786881426
> 2. OpenJDK bundled JMH, `make run-test TEST="jtreg:hotspot/jtreg/compiler/onSpinWait*"` , `make run-test TEST="micro:ThreadOnSpinWait*"`, no issue found, and `ThreadOnSpinWaitProducerConsumer.trial` showed ~3x better scores (us/op).
> 3. Jtreg tier1/tier2 sanity check on AmpereOne AArch64 platforms, Ampere-1A systems as well, no new issues found.
> 
> Signed-off-by: Patrick Zhang [patrick at os.amperecomputing.com](mailto:patrick at os.amperecomputing.com)

Marked as reviewed by dlong (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17722#pullrequestreview-1866563089

From qpzhang at openjdk.org  Wed Feb  7 01:35:54 2024
From: qpzhang at openjdk.org (Patrick Zhang)
Date: Wed, 7 Feb 2024 01:35:54 GMT
Subject: RFR: 8324824: AArch64: Detect Ampere-1B core and update default
 options for Ampere CPUs
In-Reply-To: <5Nd9-utKMTrZl2HjpiYkdJJIq9U0dtPBmX5iBpfHOdY=.0bfe4fa1-793b-4bf3-a176-78b0a2dcb02b@github.com>
References: <N9ZCzxRwamt4YTT5wNJottgQ7FYJX4SQrrFxv11Ramg=.4881b622-6d73-4c12-beb3-d65ce465f076@github.com>
 <5Nd9-utKMTrZl2HjpiYkdJJIq9U0dtPBmX5iBpfHOdY=.0bfe4fa1-793b-4bf3-a176-78b0a2dcb02b@github.com>
Message-ID: <PsYq5UjxlXX_e3UQ1Xu7EVuLmZod_cjuyCWRTkVixt0=.1a75377c-b129-4f41-888f-3c0562b5fff6@github.com>

On Tue, 6 Feb 2024 23:52:43 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Added CPU detection for Ampere-1B, and updated the default options for AmpereOne, Ampere-1A/1B to have `-XX:+UseSIMDForMemoryOps` and `-XX:OnSpinWaitInst=isb -XX:OnSpinWaitInstCount=2`.
>> 
>> Tests done:
>> 1. GitHub Actions (GHA) sanity tests: https://github.com/cnqpzhang/jdk/actions/runs/7786881426
>> 2. OpenJDK bundled JMH, `make run-test TEST="jtreg:hotspot/jtreg/compiler/onSpinWait*"` , `make run-test TEST="micro:ThreadOnSpinWait*"`, no issue found, and `ThreadOnSpinWaitProducerConsumer.trial` showed ~3x better scores (us/op).
>> 3. Jtreg tier1/tier2 sanity check on AmpereOne AArch64 platforms, Ampere-1A systems as well, no new issues found.
>> 
>> Signed-off-by: Patrick Zhang [patrick at os.amperecomputing.com](mailto:patrick at os.amperecomputing.com)
>
> Marked as reviewed by dlong (Reviewer).

Thanks for your review, @dean-long , could you please help sponsor and integrate it?

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

PR Comment: https://git.openjdk.org/jdk/pull/17722#issuecomment-1931089159

From dlong at openjdk.org  Wed Feb  7 02:57:56 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 7 Feb 2024 02:57:56 GMT
Subject: RFR: 8324824: AArch64: Detect Ampere-1B core and update default
 options for Ampere CPUs
In-Reply-To: <N9ZCzxRwamt4YTT5wNJottgQ7FYJX4SQrrFxv11Ramg=.4881b622-6d73-4c12-beb3-d65ce465f076@github.com>
References: <N9ZCzxRwamt4YTT5wNJottgQ7FYJX4SQrrFxv11Ramg=.4881b622-6d73-4c12-beb3-d65ce465f076@github.com>
Message-ID: <5wKh0mEu3ajj-SzqQ9XqzOp-Dyhve-VvWSd6iyRYxlU=.2c7aab70-450d-4ed8-9e7a-9590e6ab0d41@github.com>

On Tue, 6 Feb 2024 07:13:22 GMT, Patrick Zhang <qpzhang at openjdk.org> wrote:

> Added CPU detection for Ampere-1B, and updated the default options for AmpereOne, Ampere-1A/1B to have `-XX:+UseSIMDForMemoryOps` and `-XX:OnSpinWaitInst=isb -XX:OnSpinWaitInstCount=2`.
> 
> Tests done:
> 1. GitHub Actions (GHA) sanity tests: https://github.com/cnqpzhang/jdk/actions/runs/7786881426
> 2. OpenJDK bundled JMH, `make run-test TEST="jtreg:hotspot/jtreg/compiler/onSpinWait*"` , `make run-test TEST="micro:ThreadOnSpinWait*"`, no issue found, and `ThreadOnSpinWaitProducerConsumer.trial` showed ~3x better scores (us/op).
> 3. Jtreg tier1/tier2 sanity check on AmpereOne AArch64 platforms, Ampere-1A systems as well, no new issues found.
> 
> Signed-off-by: Patrick Zhang [patrick at os.amperecomputing.com](mailto:patrick at os.amperecomputing.com)

Normally I would say that this looks trivial, but Oracle was recently bit by JDK-8325264, because aarch64 changes in JDK-8324724 caused problems on macos-aarch64, and for some reason github testing did not catch the problem.

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

PR Comment: https://git.openjdk.org/jdk/pull/17722#issuecomment-1931179843

From dlong at openjdk.org  Wed Feb  7 02:59:58 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 7 Feb 2024 02:59:58 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v6]
In-Reply-To: <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
Message-ID: <Wl_7N3kkJNmksh-ofV4FTWQqrWD3_cDAJAdSjdKLCwM=.c2bf6cad-d867-42bb-ae77-e1645a95e5d8@github.com>

On Tue, 30 Jan 2024 09:08:01 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> ICStubs solve an atomicity problem when setting both the destination and data of an inline cache. Unfortunately, it also leads to occasional safepoint carpets when multiple threads need to ICRefill the stubs at the same time, and spurious GuaranteedSafepointInterval "Cleanup" safepoints every second. This patch changes inline caches to not change the data part at all during the nmethod life cycle, hence removing the need for ICStubs.
>> 
>> The new scheme is less stateful. Instead of adding and removing callsite metadata back and forth when transitioning inline cache states, it installs all state any shape of call will ever need at resolution time in a struct that I call CompiledICData. This reduces inline cache state changes to simply changing the destination of the call, and it doesn't really matter what state transitions to what other state.
>> 
>> With this patch, we get rid of ICStub and ICBuffer classes and the related ICRefill and almost all Cleanup safepoints in practice. It also makes the inline cache code much simpler.
>> 
>> I have tested the changes from tier1-7, and run through full aurora performance tests.
>
> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ARM32 fixes

I saw an earlier version, but I plan to look at your latest, soon.

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

PR Comment: https://git.openjdk.org/jdk/pull/17495#issuecomment-1931181620

From qpzhang at openjdk.org  Wed Feb  7 05:55:54 2024
From: qpzhang at openjdk.org (Patrick Zhang)
Date: Wed, 7 Feb 2024 05:55:54 GMT
Subject: RFR: 8324824: AArch64: Detect Ampere-1B core and update default
 options for Ampere CPUs
In-Reply-To: <N9ZCzxRwamt4YTT5wNJottgQ7FYJX4SQrrFxv11Ramg=.4881b622-6d73-4c12-beb3-d65ce465f076@github.com>
References: <N9ZCzxRwamt4YTT5wNJottgQ7FYJX4SQrrFxv11Ramg=.4881b622-6d73-4c12-beb3-d65ce465f076@github.com>
Message-ID: <HEnSqCTmAyBF2abkOoRFLaE88qnAuYdHV_bIq3E708g=.6a81b172-01cb-4cb1-a730-7ab612d3cfe3@github.com>

On Tue, 6 Feb 2024 07:13:22 GMT, Patrick Zhang <qpzhang at openjdk.org> wrote:

> Added CPU detection for Ampere-1B, and updated the default options for AmpereOne, Ampere-1A/1B to have `-XX:+UseSIMDForMemoryOps` and `-XX:OnSpinWaitInst=isb -XX:OnSpinWaitInstCount=2`.
> 
> Tests done:
> 1. GitHub Actions (GHA) sanity tests: https://github.com/cnqpzhang/jdk/actions/runs/7786881426
> 2. OpenJDK bundled JMH, `make run-test TEST="jtreg:hotspot/jtreg/compiler/onSpinWait*"` , `make run-test TEST="micro:ThreadOnSpinWait*"`, no issue found, and `ThreadOnSpinWaitProducerConsumer.trial` showed ~3x better scores (us/op).
> 3. Jtreg tier1/tier2 sanity check on AmpereOne AArch64 platforms, Ampere-1A systems as well, no new issues found.
> 
> Signed-off-by: Patrick Zhang [patrick at os.amperecomputing.com](mailto:patrick at os.amperecomputing.com)

It is of lower risk since the updates are limited to particular Ampere new CPU cores.

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

PR Comment: https://git.openjdk.org/jdk/pull/17722#issuecomment-1931338800

From thartmann at openjdk.org  Wed Feb  7 06:07:53 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 7 Feb 2024 06:07:53 GMT
Subject: RFR: 8324824: AArch64: Detect Ampere-1B core and update default
 options for Ampere CPUs
In-Reply-To: <N9ZCzxRwamt4YTT5wNJottgQ7FYJX4SQrrFxv11Ramg=.4881b622-6d73-4c12-beb3-d65ce465f076@github.com>
References: <N9ZCzxRwamt4YTT5wNJottgQ7FYJX4SQrrFxv11Ramg=.4881b622-6d73-4c12-beb3-d65ce465f076@github.com>
Message-ID: <q6QhEzsRD0rPq2IOJDpJ4JY-jEMhW0-EugtlsTvQVxo=.8c245abe-5856-43e5-a325-1fe39ae20293@github.com>

On Tue, 6 Feb 2024 07:13:22 GMT, Patrick Zhang <qpzhang at openjdk.org> wrote:

> Added CPU detection for Ampere-1B, and updated the default options for AmpereOne, Ampere-1A/1B to have `-XX:+UseSIMDForMemoryOps` and `-XX:OnSpinWaitInst=isb -XX:OnSpinWaitInstCount=2`.
> 
> Tests done:
> 1. GitHub Actions (GHA) sanity tests: https://github.com/cnqpzhang/jdk/actions/runs/7786881426
> 2. OpenJDK bundled JMH, `make run-test TEST="jtreg:hotspot/jtreg/compiler/onSpinWait*"` , `make run-test TEST="micro:ThreadOnSpinWait*"`, no issue found, and `ThreadOnSpinWaitProducerConsumer.trial` showed ~3x better scores (us/op).
> 3. Jtreg tier1/tier2 sanity check on AmpereOne AArch64 platforms, Ampere-1A systems as well, no new issues found.
> 
> Signed-off-by: Patrick Zhang [patrick at os.amperecomputing.com](mailto:patrick at os.amperecomputing.com)

I've submitted testing and will report back once it passed.

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

PR Comment: https://git.openjdk.org/jdk/pull/17722#issuecomment-1931349212

From thartmann at openjdk.org  Wed Feb  7 06:40:53 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 7 Feb 2024 06:40:53 GMT
Subject: RFR: JDK-8325264: two compiler/intrinsics/float16 tests fail after
 JDK-8324724
In-Reply-To: <eoR3U5uw7lee-9UJA2qwsyF9u89D_vW83xykuszAMcU=.f70552a1-d96a-4895-99ac-33dfd0942de2@github.com>
References: <eoR3U5uw7lee-9UJA2qwsyF9u89D_vW83xykuszAMcU=.f70552a1-d96a-4895-99ac-33dfd0942de2@github.com>
Message-ID: <SSOw-ENktKWuAIMFSmO0n2w4_Dz-VFzrzWu7nc3twkQ=.de8f7a3c-8e3c-4a95-b128-a60b36202c35@github.com>

On Tue, 6 Feb 2024 14:37:11 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

> Fix for two JTREG test failures on OS_X after this commit - https://github.com/openjdk/jdk/commit/51853f7488afa69c0d14b0e96f1da84822cd83f1.
> 
> This is due to no permission to execute the stub code in the code cache. This patch fixes this problem by acquiring "WXExec" to be able to execute the instructions in code cache.
> 
> Both the tests - compiler/intrinsics/float16/TestAllFloat16ToFloat.java and compiler/intrinsics/float16/Binary16ConversionNaN.java pass on a MacOS machine.

Looks good. I'm running some sanity testing and will report back once it passed.

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

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17733#pullrequestreview-1867001703

From sspitsyn at openjdk.org  Wed Feb  7 07:02:11 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 7 Feb 2024 07:02:11 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v3]
In-Reply-To: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
Message-ID: <bIMfwFEuiZ1CbUtq3NzEeNuW72i4jAqAHGJKMb_VZdg=.4e228b57-af29-4a78-9534-bae11fa6bb2d@github.com>

> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
> The function returns the following structure:
> 
> 
> typedef struct {
>     jthread owner;
>     jint entry_count;
>     jint waiter_count;
>     jthread* waiters;
>     jint notify_waiter_count;
>     jthread* notify_waiters;
> } jvmtiMonitorUsage;
> 
> 
> The following four fields are defined this way:
> 
> waiter_count  [jint] The number of threads waiting to own this monitor
> waiters  [jthread*] The waiter_count waiting threads
> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
> 
> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
> This update makes it right.
> 
> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
> 
> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
> 
>   jvmti/GetObjectMonitorUsage/objmonusage001
>   jvmti/GetObjectMonitorUsage/objmonusage003
> 
> 
> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
> 
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
> 
> 
> 
> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository.
> 
> Also, please see and review the related CSR:
>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
> 
> The Release-Note is:
> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage
>  
> Testing:
>  - tested with mach5 tiers 1-6

Serguei Spitsyn 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
 - review: thread in notify waiter list can't be BLOCKED
 - 8324677: Specification clarification needed for JVM TI GetObjectMonitorUsage

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17680/files
  - new: https://git.openjdk.org/jdk/pull/17680/files/abe82a6c..3d735722

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

  Stats: 7346 lines in 273 files changed: 4294 ins; 1478 del; 1574 mod
  Patch: https://git.openjdk.org/jdk/pull/17680.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17680/head:pull/17680

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

From eosterlund at openjdk.org  Wed Feb  7 07:04:58 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Wed, 7 Feb 2024 07:04:58 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v6]
In-Reply-To: <Wl_7N3kkJNmksh-ofV4FTWQqrWD3_cDAJAdSjdKLCwM=.c2bf6cad-d867-42bb-ae77-e1645a95e5d8@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
 <Wl_7N3kkJNmksh-ofV4FTWQqrWD3_cDAJAdSjdKLCwM=.c2bf6cad-d867-42bb-ae77-e1645a95e5d8@github.com>
Message-ID: <EwAD2vp3hrZG-jLajqrliSiu_IB72Ym8bXLyfGqlCKY=.5c1d622a-0128-4306-844f-f429b3f4de7f@github.com>

On Wed, 7 Feb 2024 02:56:54 GMT, Dean Long <dlong at openjdk.org> wrote:

> I saw an earlier version, but I plan to look at your latest, soon.

Thank you @dean-long I appreciate it.

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

PR Comment: https://git.openjdk.org/jdk/pull/17495#issuecomment-1931405479

From dlong at openjdk.org  Wed Feb  7 08:56:57 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 7 Feb 2024 08:56:57 GMT
Subject: RFR: 8324833: Signed integer overflows in ABS [v3]
In-Reply-To: <6kxKhJVXB2X7ni4SLMtL--Pt5O8bUOazcI9F3FJgG8o=.55b0e9bd-075c-4b76-bcc6-732951e8a512@github.com>
References: <ohwAn6GqM7FIgYTJNy40VBYSCVEBrrNSqBaz2akN54M=.f9660235-3047-47ee-aad0-ef598d6ebdcc@github.com>
 <6kxKhJVXB2X7ni4SLMtL--Pt5O8bUOazcI9F3FJgG8o=.55b0e9bd-075c-4b76-bcc6-732951e8a512@github.com>
Message-ID: <0nt6jll4FpIqr3pP7LZo8Cxf9U0dNR159cLS8tSWb24=.51b7d389-8dbc-4e48-b34a-7da2bbd61c45@github.com>

On Fri, 2 Feb 2024 09:47:28 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the details in the bug. I think current `ABS` implementation is beyond repair, and we should just switch to `uabs`.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug, `all` with `-ftrapv` (now fully passes!)
>>  - [x] Linux x86_64 fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Touchups

I didn't mean to say ABS() can't be implemented in C++ without UB.  But if it returns a negative number, then that seems surprising.  For reference, the  Linux man page for the abs(3) library call says "Trying to take the absolute value of the most negative integer is not defined."

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

PR Comment: https://git.openjdk.org/jdk/pull/17617#issuecomment-1931559874

From luhenry at openjdk.org  Wed Feb  7 10:32:55 2024
From: luhenry at openjdk.org (Ludovic Henry)
Date: Wed, 7 Feb 2024 10:32:55 GMT
Subject: RFR: 8320646: RISC-V: C2 VectorCastHF2F
In-Reply-To: <kqLQR-bD3v7iF7LgH0PzwIH_m6QH_2b371pKz9_Ovq8=.9c07c165-2a97-4a6b-9e82-6a6de0b81328@github.com>
References: <kqLQR-bD3v7iF7LgH0PzwIH_m6QH_2b371pKz9_Ovq8=.9c07c165-2a97-4a6b-9e82-6a6de0b81328@github.com>
Message-ID: <bnbGMlL-ugSiK4TnQWG27Qrp6t4upI4cSWSakCIPvB8=.d5fff64c-8dfa-4a0b-b8c6-6ef1b8741a2a@github.com>

On Sun, 4 Feb 2024 09:38:48 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you review this patch to add instrinsics for VectorCastHF2F/VectorCastF2HF?
> Thanks!
> 
> ## Test
> 
> test/jdk/java/lang/Float/Binary16ConversionNaN.java
> test/jdk/java/lang/Float/Binary16Conversion.java
> 
> hotspot/jtreg/compiler/intrinsics/float16
> hotspot/jtreg/compiler/vectorization/TestFloatConversionsVectorjava
> hotspot/jtreg/compiler/vectorization/TestFloatConversionsVectorNaN.java

Changes requested by luhenry (Committer).

src/hotspot/cpu/riscv/assembler_riscv.hpp line 1617:

> 1615:   INSN(vadd_vi,   0b1010111, 0b011, 0b000000);
> 1616:   INSN(vrsub_vi,  0b1010111, 0b011, 0b000011);
> 1617:   INSN(vnsra_wi,  0b1010111, 0b011, 0b101101);

You can put it up with `vnsra_wx` in the "Vector Narrowing Integer Right Shift Instructions" at https://github.com/openjdk/jdk/pull/17698/files#diff-314214875276cd9a11ecdfd52b68403ded286710ba0820461b0b510506f61a33R1528

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

PR Review: https://git.openjdk.org/jdk/pull/17698#pullrequestreview-1866369917
PR Review Comment: https://git.openjdk.org/jdk/pull/17698#discussion_r1480571940

From ayang at openjdk.org  Wed Feb  7 12:25:58 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 7 Feb 2024 12:25:58 GMT
Subject: RFR: 8325221: Obsolete TLABStats
In-Reply-To: <OgGNoY6jWx3-W6IN8vOEoFRUvW9s7i3QE8LZw1tlZgQ=.7a7e456c-8180-484d-aa27-e2f4cb43c362@github.com>
References: <OgGNoY6jWx3-W6IN8vOEoFRUvW9s7i3QE8LZw1tlZgQ=.7a7e456c-8180-484d-aa27-e2f4cb43c362@github.com>
Message-ID: <nM4W1e9EG2TAIY3zyJBh5heH1bAEvEcJRL6E9eHQOqY=.94173a38-6a52-4722-aa49-a14a81caaeff@github.com>

On Mon, 5 Feb 2024 11:12:03 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple obsoletion of a jvm flag.

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/17707#issuecomment-1931932367

From ayang at openjdk.org  Wed Feb  7 12:25:59 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 7 Feb 2024 12:25:59 GMT
Subject: Integrated: 8325221: Obsolete TLABStats
In-Reply-To: <OgGNoY6jWx3-W6IN8vOEoFRUvW9s7i3QE8LZw1tlZgQ=.7a7e456c-8180-484d-aa27-e2f4cb43c362@github.com>
References: <OgGNoY6jWx3-W6IN8vOEoFRUvW9s7i3QE8LZw1tlZgQ=.7a7e456c-8180-484d-aa27-e2f4cb43c362@github.com>
Message-ID: <noxub4oKNs_gwR1eYeibpGp9JQBp7WMXZwy9L8pj0nM=.497cbf06-9f56-46d2-82ff-391b78682b8c@github.com>

On Mon, 5 Feb 2024 11:12:03 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple obsoletion of a jvm flag.

This pull request has now been integrated.

Changeset: 77ee7f0e
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/77ee7f0e2494f01cf55c2b11152c2f0d98d80280
Stats:     7 lines in 4 files changed: 1 ins; 6 del; 0 mod

8325221: Obsolete TLABStats

Reviewed-by: tschatzl, kbarrett

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

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

From dcubed at openjdk.org  Wed Feb  7 13:37:53 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 7 Feb 2024 13:37:53 GMT
Subject: RFR: 8324824: AArch64: Detect Ampere-1B core and update default
 options for Ampere CPUs
In-Reply-To: <5wKh0mEu3ajj-SzqQ9XqzOp-Dyhve-VvWSd6iyRYxlU=.2c7aab70-450d-4ed8-9e7a-9590e6ab0d41@github.com>
References: <N9ZCzxRwamt4YTT5wNJottgQ7FYJX4SQrrFxv11Ramg=.4881b622-6d73-4c12-beb3-d65ce465f076@github.com>
 <5wKh0mEu3ajj-SzqQ9XqzOp-Dyhve-VvWSd6iyRYxlU=.2c7aab70-450d-4ed8-9e7a-9590e6ab0d41@github.com>
Message-ID: <KSRnIURdmBz8tq4J_o5CWEkDReDjqhZB6PlU5PcikHc=.1cfc4a60-4cd8-4014-b1f1-9ad61438bbc7@github.com>

On Wed, 7 Feb 2024 02:55:17 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Added CPU detection for Ampere-1B, and updated the default options for AmpereOne, Ampere-1A/1B to have `-XX:+UseSIMDForMemoryOps` and `-XX:OnSpinWaitInst=isb -XX:OnSpinWaitInstCount=2`.
>> 
>> Tests done:
>> 1. GitHub Actions (GHA) sanity tests: https://github.com/cnqpzhang/jdk/actions/runs/7786881426
>> 2. OpenJDK bundled JMH, `make run-test TEST="jtreg:hotspot/jtreg/compiler/onSpinWait*"` , `make run-test TEST="micro:ThreadOnSpinWait*"`, no issue found, and `ThreadOnSpinWaitProducerConsumer.trial` showed ~3x better scores (us/op).
>> 3. Jtreg tier1/tier2 sanity check on AmpereOne AArch64 platforms, Ampere-1A systems as well, no new issues found.
>> 
>> Signed-off-by: Patrick Zhang [patrick at os.amperecomputing.com](mailto:patrick at os.amperecomputing.com)
>
> Normally I would say that this looks trivial, but Oracle was recently bit by JDK-8325264, because aarch64 changes in JDK-8324724 caused problems on macos-aarch64, and for some reason github testing did not catch the problem.

@dean-long:
> for some reason github testing did not catch the problem.

GHA was not doing macosx-aarch64 testing until yesterday (2024.02.06) at 0830 ET.

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

PR Comment: https://git.openjdk.org/jdk/pull/17722#issuecomment-1932065208

From aboldtch at openjdk.org  Wed Feb  7 14:33:15 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 7 Feb 2024 14:33:15 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v11]
In-Reply-To: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
Message-ID: <Eag9wT75Jlj6FIoT5lrUKpZxwtKLjxwlLyu51kCEUeY=.f814c2ad-0f74-4a28-8766-51a9cffd8818@github.com>

> The `ObjectSynchronizer` has always assumed that the `current` parameters are both the current thread as well as the thread that is doing the locking. The only time that we are entering on behalf of another thread is when doing re-locking in deoptimization. This has worked because the deoptee thread is suspended. However ResourceMarks have been using the wrong thread when logging is enabled.
> 
> This change `ObjectSynchronizer` instruments the relevant methods with both a `JavaThread* locking_thread` as well as `[Java]Thread* current` to be able to use the correct thread for ResourceMarks. 
> 
> Having the `inflate` care about a `locking_thread` is a little unpleasant in my opinion. But it is required for LM_LIGHTWEIGHT. 
> Would probably be cleaner if the inflate for LM_LIGHTWEIGHT was it's own thing, as it does not share the whole INFLATING protocol. But seems like a future RFE to refactor this code.
> 
> Can reproduce a crash by modifying `test/jdk/com/sun/jdi/EATests.java` and using `-XX:DiagnoseSyncOnValueBasedClasses=2` with LM_LEGACY or running `test/jdk/com/sun/jdi/EATests.java` with LM_LIGHTWEIGHT/LM_MONITOR and `-Xlog:monitorinflation=trace`. 
> 
> Could extend this test to capture this regression in the future (or creating a new test based on the same infrastructure). Will give it an attempt, so we have a regression test for this. But these tests get rather involved as the require a lot of jvmti setup.

Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 25 additional commits since the last revision:

 - Add comment about failed to fast lock.
 - Missing space
 - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8324881
 - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8324881
 - Update comment
 - Fix comments
 - Update test/jdk/com/sun/jdi/EATests.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Update test/jdk/com/sun/jdi/EATests.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Update test/jdk/com/sun/jdi/EATests.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Update test/jdk/com/sun/jdi/EATests.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - ... and 15 more: https://git.openjdk.org/jdk/compare/882549fb...216680c9

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17626/files
  - new: https://git.openjdk.org/jdk/pull/17626/files/b3cc401c..216680c9

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

  Stats: 5287 lines in 178 files changed: 3044 ins; 1316 del; 927 mod
  Patch: https://git.openjdk.org/jdk/pull/17626.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17626/head:pull/17626

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

From duke at openjdk.org  Wed Feb  7 14:40:03 2024
From: duke at openjdk.org (Yuri Gaevsky)
Date: Wed, 7 Feb 2024 14:40:03 GMT
Subject: RFR: 8324124: RISC-V: implement _vectorizedMismatch intrinsic
Message-ID: <dxSBhJiLeVkLF8PvHW3MMg69vwXU0VshECCMz5HnhhI=.e0cbda8b-f7f6-44ff-806b-1f21496911be@github.com>

Hello All,

Please review these changes to enable the __vectorizedMismatch_ intrinsic on RISC-V platform with RVV instructions supported.

Thank you,
-Yuri Gaevsky

**Correctness checks:**
  hotspot/jtreg/compiler/{intrinsic/c1/c2}/ under QEMU-8.1 with RVV v1.0.0 and -XX:TieredStopAtLevel=1/2/3/4.

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

Commit messages:
 - 8324124: RISC-V: implement _vectorizedMismatch intrinsic

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

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

From mli at openjdk.org  Wed Feb  7 14:43:06 2024
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 7 Feb 2024 14:43:06 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v9]
In-Reply-To: <hd3QLWKom9VFSeX9AxaD6vzAN0goIoUn74UDH3cdumY=.e7c4a01c-620a-4686-be89-4ad82ba1f340@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <hd3QLWKom9VFSeX9AxaD6vzAN0goIoUn74UDH3cdumY=.e7c4a01c-620a-4686-be89-4ad82ba1f340@github.com>
Message-ID: <1BPmeP4mK5G40pZ8X6Hu64DXMgQVvBk_CayhmP9Dj5I=.fafa29a2-3ad6-4ac0-9d89-244c739e4598@github.com>

On Thu, 7 Dec 2023 09:30:01 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]).
>> 
>> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead.
>> 
>> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly.
>> 
>> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts.
>> 
>> [1] https://github.com/openjdk/jdk/pull/3638
>> [2] https://sleef.org/
>> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/
>> [4] https://packages.debian.org/bookworm/libsleef3
>> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix potential attribute issue

I could also take a look at it by the end of this month if no one are going to do it.

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1932188622

From aboldtch at openjdk.org  Wed Feb  7 14:44:00 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 7 Feb 2024 14:44:00 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v10]
In-Reply-To: <Z9WlSkk7UrfNrU903GCPL4CwyzkoOVMhpSUe1nxKs4s=.ff15cd0e-8c45-454d-9c9b-7935134e6249@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
 <wL168lSWSS1EHp_v9lraUQySJ3WzFD7uoWOIolAtUaU=.cea57d21-687c-44e9-86f7-7ca38930fc87@github.com>
 <Z9WlSkk7UrfNrU903GCPL4CwyzkoOVMhpSUe1nxKs4s=.ff15cd0e-8c45-454d-9c9b-7935134e6249@github.com>
Message-ID: <GWE_wSRQbFEe8IYljoEA9ipFuz-UcF-hMwJoPmmgedE=.8f2ef6ad-5a0c-4472-8232-4a440f50bd0b@github.com>

On Tue, 6 Feb 2024 23:37:32 GMT, Daniel D. Daugherty <dcubed 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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8324881
>>  - Update comment
>>  - Fix comments
>>  - Update test/jdk/com/sun/jdi/EATests.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - Update test/jdk/com/sun/jdi/EATests.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - Update test/jdk/com/sun/jdi/EATests.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - Update test/jdk/com/sun/jdi/EATests.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - Remove newline
>>  - Update src/hotspot/share/runtime/synchronizer.hpp
>>    
>>    Co-authored-by: Richard Reingruber <richard.reingruber at sap.com>
>>  - Improve EARelockingNestedInflated_03 for LM_LIGHTWEIGHT
>>  - ... and 12 more: https://git.openjdk.org/jdk/compare/8d6ba3bf...b3cc401c
>
> src/hotspot/share/runtime/synchronizer.cpp line 525:
> 
>> 523:         return;
>> 524:       }
>> 525:       assert(monitor->is_being_async_deflated(), "must be");
> 
> You've added this assertion here after the `enter_for` must have lost the
> race to async deflation, but you didn't add the same assertion below
> after L540 -> L542. Why not?

The assert was added because `ObjectMonitor::enter_for` was initially not constrained by only racing with deflation. Now however `ObjectMonitor::enter_for` does assert that it succeeds if it manage to lock out deflation. This assert should never be reached but I kept it as it shows intent.

I did not added it to the `ObjectSynchronizer::enter` at the time because it did not seem needed. But given that I kept it in 'ObjectSynchronizer::enter_for' to show intent, the same argument could be made for `ObjectSynchronizer::enter`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17626#discussion_r1481579128

From duke at openjdk.org  Wed Feb  7 14:48:55 2024
From: duke at openjdk.org (Yuri Gaevsky)
Date: Wed, 7 Feb 2024 14:48:55 GMT
Subject: RFR: 8324124: RISC-V: implement _vectorizedMismatch intrinsic
In-Reply-To: <dxSBhJiLeVkLF8PvHW3MMg69vwXU0VshECCMz5HnhhI=.e0cbda8b-f7f6-44ff-806b-1f21496911be@github.com>
References: <dxSBhJiLeVkLF8PvHW3MMg69vwXU0VshECCMz5HnhhI=.e0cbda8b-f7f6-44ff-806b-1f21496911be@github.com>
Message-ID: <GgY6O7wIPZHxiao2_nUdz6KeauSQO6C9NjviAGVxgzs=.a1bdf21b-11e7-4ba9-9832-57aa10f1c44d@github.com>

On Wed, 7 Feb 2024 14:35:55 GMT, Yuri Gaevsky <duke at openjdk.org> wrote:

> Hello All,
> 
> Please review these changes to enable the __vectorizedMismatch_ intrinsic on RISC-V platform with RVV instructions supported.
> 
> Thank you,
> -Yuri Gaevsky
> 
> **Correctness checks:**
>   hotspot/jtreg/compiler/{intrinsic/c1/c2}/ under QEMU-8.1 with RVV v1.0.0 and -XX:TieredStopAtLevel=1/2/3/4.

NB: I have no access to "real" RVV v1.0.0 hardware so to estimate performance improvements
adopted the patch to RVV v0.7.1 ISA [1] under OpenJDK-21 and run the JMH test
org.openjdk.bench.java.util.VectorizedMismatch on LicheePi-4A TH1520 which does support
RVV v.0.7.1.

[1] https://mail.openjdk.org/pipermail/riscv-port-dev/2024-January/001220.html

The results are below.

Legend: UseVMI ==> UseVectorizedMismatchIntrinsic

ArraysMismatch.Byte

-----------------------------------------------------------------------
                                   [-UseVMI]       [+UseVMI]
Benchmark      (size)  Mode  Cnt   Score   Error   Score   Error  Units
mismatchStart       7  avgt   20  26.859 ? 0.051  26.378 ? 0.152  ns/op
mismatchStart       8  avgt   20  26.105 ? 0.043  66.174 ? 0.102  ns/op
mismatchStart       9  avgt   20  26.076 ? 0.031  70.042 ? 0.190  ns/op
mismatchStart      15  avgt   20  26.078 ? 0.043  70.055 ? 0.168  ns/op
mismatchStart      16  avgt   20  26.230 ? 0.040  70.043 ? 0.207  ns/op
mismatchStart      17  avgt   20  25.736 ? 0.075  65.643 ? 0.120  ns/op
mismatchStart      31  avgt   20  25.949 ? 0.072  54.216 ? 0.202  ns/op
mismatchStart      32  avgt   20  26.083 ? 0.060  54.190 ? 0.171  ns/op
mismatchStart      33  avgt   20  26.130 ? 0.082  64.681 ? 0.203  ns/op
mismatchStart      63  avgt   20  25.718 ? 0.030  65.310 ? 0.241  ns/op
mismatchStart      64  avgt   20  26.078 ? 0.042  65.357 ? 0.272  ns/op
mismatchStart      65  avgt   20  26.265 ? 0.039  61.773 ? 0.137  ns/op
mismatchStart     128  avgt   20  26.073 ? 0.040  62.401 ? 0.204  ns/op
mismatchStart     129  avgt   20  26.082 ? 0.038  61.901 ? 0.232  ns/op
mismatchStart     256  avgt   20  26.084 ? 0.061  54.098 ? 0.092  ns/op
mismatchStart     257  avgt   20  25.735 ? 0.040  61.772 ? 0.116  ns/op
mismatchStart     512  avgt   20  26.070 ? 0.036  54.112 ? 0.048  ns/op
mismatchStart     513  avgt   20  26.082 ? 0.035  61.801 ? 0.125  ns/op
mismatchStart    1024  avgt   20  26.097 ? 0.071  62.402 ? 0.173  ns/op
mismatchStart    1025  avgt   20  26.169 ? 0.101  61.972 ? 0.215  ns/op
mismatchStart    2048  avgt   20  26.094 ? 0.046  54.367 ? 0.258  ns/op
mismatchStart    2049  avgt   20  26.081 ? 0.031  62.383 ? 0.129  ns/op
mismatchStart    4096  avgt   20  26.125 ? 0.076  54.114 ? 0.110  ns/op
mismatchStart    4097  avgt   20  26.080 ? 0.047  61.771 ? 0.150  ns/op
mismatchStart    8191  avgt   20  25.723 ? 0.041  62.386 ? 0.084  ns/op
mismatchStart    8192  avgt   20  25.726 ? 0.067  54.094 ? 0.098  ns/op
mismatchStart    8193  avgt   20  25.698 ? 0.039  61.815 ? 0.053  ns/op
-----------------------------------------------------------------------
                                  [-UseVMI]        [+UseVMI]
Benchmark    (size)  Mode  Cnt    Score   Error    Score   Error  Units
mismatchMid       7  avgt   20   27.377 ? 0.018   27.355 ? 0.046  ns/op
mismatchMid       8  avgt   20   26.524 ? 0.159   54.192 ? 0.073  ns/op
mismatchMid       9  avgt   20   26.469 ? 0.065   55.944 ? 6.784  ns/op
mismatchMid      15  avgt   20   26.619 ? 0.053   70.057 ? 0.159  ns/op
mismatchMid      16  avgt   20   27.892 ? 0.064   54.293 ? 0.200  ns/op
mismatchMid      17  avgt   20   27.366 ? 0.072   70.147 ? 0.198  ns/op
mismatchMid      31  avgt   20   28.416 ? 0.126   67.369 ? 0.131  ns/op
mismatchMid      32  avgt   20   27.913 ? 0.068   67.422 ? 0.191  ns/op
mismatchMid      33  avgt   20   27.858 ? 0.046   54.154 ? 0.181  ns/op
mismatchMid      63  avgt   20   31.170 ? 0.060   54.177 ? 0.168  ns/op
mismatchMid      64  avgt   20   31.167 ? 0.085   54.205 ? 0.160  ns/op
mismatchMid      65  avgt   20   31.006 ? 0.132   65.233 ? 0.142  ns/op
mismatchMid     128  avgt   20   34.483 ? 0.086   56.083 ? 7.124  ns/op
mismatchMid     129  avgt   20   34.550 ? 0.183   63.129 ? 0.312  ns/op
mismatchMid     256  avgt   20   43.425 ? 0.058   74.976 ? 0.126  ns/op
mismatchMid     257  avgt   20   43.532 ? 0.069   75.511 ? 0.137  ns/op
mismatchMid     512  avgt   20   87.619 ? 0.109   72.178 ? 0.153  ns/op
mismatchMid     513  avgt   20   87.569 ? 0.102  108.922 ? 0.244  ns/op
mismatchMid    1024  avgt   20  103.914 ? 0.150  132.788 ? 0.165  ns/op
mismatchMid    1025  avgt   20  103.868 ? 0.205  133.023 ? 0.124  ns/op
mismatchMid    2048  avgt   20  179.546 ? 0.198  129.567 ? 0.129  ns/op
mismatchMid    2049  avgt   20  177.637 ? 0.316  174.123 ? 0.115  ns/op
mismatchMid    4096  avgt   20  325.257 ? 0.406  225.116 ? 1.898  ns/op
mismatchMid    4097  avgt   20  323.888 ? 1.284  223.202 ? 1.630  ns/op
mismatchMid    8191  avgt   20  605.531 ? 0.631  349.250 ? 0.769  ns/op
mismatchMid    8192  avgt   20  605.379 ? 0.771  686.644 ? 2.755  ns/op
mismatchMid    8193  avgt   20  599.691 ? 0.801  686.875 ? 0.736  ns/op
---------------------------------------------------------------------------
                                   [-UseVMI]          [+UseVMI]
Benchmark    (size)  Mode  Cnt     Score    Error     Score    Error  Units
mismatchEnd       7  avgt   20    26.817 ?  0.040    26.808 ?  0.038  ns/op
mismatchEnd       8  avgt   20    26.059 ?  0.063    66.319 ?  0.161  ns/op
mismatchEnd       9  avgt   20    26.454 ?  0.035    70.107 ?  0.174  ns/op
mismatchEnd      15  avgt   20    42.827 ?  0.158    54.243 ?  0.138  ns/op
mismatchEnd      16  avgt   20    27.915 ?  0.070    69.997 ?  0.145  ns/op
mismatchEnd      17  avgt   20    27.918 ?  0.049    66.225 ?  0.302  ns/op
mismatchEnd      31  avgt   20    31.742 ?  0.076    67.339 ?  0.215  ns/op
mismatchEnd      32  avgt   20    31.699 ?  0.065    54.122 ?  0.059  ns/op
mismatchEnd      33  avgt   20    31.472 ?  0.078    63.532 ?  0.234  ns/op
mismatchEnd      63  avgt   20    36.950 ?  0.063    65.204 ?  0.254  ns/op
mismatchEnd      64  avgt   20    36.172 ?  0.149    65.120 ?  0.189  ns/op
mismatchEnd      65  avgt   20    36.681 ?  0.124    61.858 ?  0.164  ns/op
mismatchEnd     128  avgt   20    47.459 ?  0.161    54.162 ?  0.141  ns/op
mismatchEnd     129  avgt   20    45.173 ?  0.079    62.455 ?  0.182  ns/op
mismatchEnd     256  avgt   20    84.839 ?  0.137    92.530 ?  0.155  ns/op
mismatchEnd     257  avgt   20    82.749 ?  0.149    81.377 ?  0.267  ns/op
mismatchEnd     512  avgt   20   109.664 ?  2.308   114.271 ?  0.143  ns/op
mismatchEnd     513  avgt   20   115.172 ?  0.264   102.913 ?  0.155  ns/op
mismatchEnd    1024  avgt   20   185.254 ?  0.134   121.601 ?  0.185  ns/op
mismatchEnd    1025  avgt   20   184.594 ?  1.473   121.588 ?  0.357  ns/op
mismatchEnd    2048  avgt   20   330.985 ?  0.662   232.113 ?  0.453  ns/op
mismatchEnd    2049  avgt   20   330.994 ?  0.311   232.701 ?  0.488  ns/op
mismatchEnd    4096  avgt   20   607.884 ?  0.988   349.221 ?  0.947  ns/op
mismatchEnd    4097  avgt   20   608.472 ?  0.844   537.718 ?  7.562  ns/op
mismatchEnd    8191  avgt   20  1172.123 ?  1.283  1329.150 ?  3.545  ns/op
mismatchEnd    8192  avgt   20  1176.383 ?  2.170   644.301 ? 12.636  ns/op
mismatchEnd    8193  avgt   20  1179.004 ? 12.464   937.827 ?  1.341  ns/op

ArraysMismatch.Short

-----------------------------------------------------------------------
                                   [-UseVMI]       [+UseVMI]
Benchmark      (size)  Mode  Cnt   Score   Error   Score   Error  Units
mismatchStart       7  avgt   20  26.504 ? 0.128  68.446 ? 0.125  ns/op
mismatchStart       8  avgt   20  26.463 ? 0.038  52.465 ? 0.092  ns/op
mismatchStart       9  avgt   20  26.459 ? 0.043  64.816 ? 0.301  ns/op
mismatchStart      15  avgt   20  26.488 ? 0.029  65.821 ? 0.166  ns/op
mismatchStart      16  avgt   20  26.420 ? 0.048  53.618 ? 0.142  ns/op
mismatchStart      17  avgt   20  26.432 ? 0.032  62.225 ? 0.249  ns/op
mismatchStart      31  avgt   20  26.438 ? 0.062  63.451 ? 0.197  ns/op
mismatchStart      32  avgt   20  26.455 ? 0.064  63.458 ? 0.101  ns/op
mismatchStart      33  avgt   20  26.409 ? 0.042  60.147 ? 0.066  ns/op
mismatchStart      63  avgt   20  26.464 ? 0.064  60.733 ? 0.210  ns/op
mismatchStart      64  avgt   20  26.442 ? 0.092  60.720 ? 0.112  ns/op
mismatchStart      65  avgt   20  26.475 ? 0.052  61.258 ? 0.080  ns/op
mismatchStart     128  avgt   20  26.455 ? 0.035  52.719 ? 0.191  ns/op
mismatchStart     129  avgt   20  26.464 ? 0.065  60.199 ? 0.147  ns/op
mismatchStart     256  avgt   20  26.437 ? 0.072  60.848 ? 0.237  ns/op
mismatchStart     257  avgt   20  26.428 ? 0.031  60.182 ? 0.110  ns/op
mismatchStart     512  avgt   20  26.438 ? 0.037  60.843 ? 0.134  ns/op
mismatchStart     513  avgt   20  26.426 ? 0.027  60.225 ? 0.203  ns/op
mismatchStart    1024  avgt   20  26.433 ? 0.066  60.811 ? 0.041  ns/op
mismatchStart    1025  avgt   20  26.419 ? 0.048  60.814 ? 0.160  ns/op
mismatchStart    2048  avgt   20  26.454 ? 0.073  60.764 ? 0.114  ns/op
mismatchStart    2049  avgt   20  26.450 ? 0.035  60.340 ? 0.162  ns/op
mismatchStart    4096  avgt   20  26.437 ? 0.035  61.017 ? 0.189  ns/op
mismatchStart    4097  avgt   20  26.439 ? 0.040  60.326 ? 0.140  ns/op
mismatchStart    8191  avgt   20  26.449 ? 0.077  52.491 ? 0.050  ns/op
mismatchStart    8192  avgt   20  26.419 ? 0.027  61.850 ? 0.072  ns/op
mismatchStart    8193  avgt   20  26.413 ? 0.034  62.363 ? 0.207  ns/op
---------------------------------------------------------------------------
                                   [-UseVMI]         [+UseVMI]
Benchmark    (size)  Mode  Cnt     Score    Error     Score    Error  Units
mismatchMid       7  avgt   20    26.508 ?  0.148    52.628 ?  0.117  ns/op
mismatchMid       8  avgt   20    27.388 ?  0.079    52.589 ?  0.050  ns/op
mismatchMid       9  avgt   20    27.353 ?  0.032    69.488 ?  0.182  ns/op
mismatchMid      15  avgt   20    27.905 ?  0.029    66.777 ?  0.183  ns/op
mismatchMid      16  avgt   20    28.019 ?  0.064    52.507 ?  0.091  ns/op
mismatchMid      17  avgt   20    28.020 ?  0.037    65.619 ?  0.154  ns/op
mismatchMid      31  avgt   20    30.644 ?  0.108    52.707 ?  0.204  ns/op
mismatchMid      32  avgt   20    30.859 ?  0.058    63.543 ?  0.205  ns/op
mismatchMid      33  avgt   20    30.917 ?  0.049    53.594 ?  0.093  ns/op
mismatchMid      63  avgt   20    34.269 ?  0.132    52.720 ?  0.180  ns/op
mismatchMid      64  avgt   20    34.455 ?  0.048    52.560 ?  0.153  ns/op
mismatchMid      65  avgt   20    34.484 ?  0.090    52.617 ?  0.281  ns/op
mismatchMid     128  avgt   20    42.681 ?  0.063    61.842 ?  0.170  ns/op
mismatchMid     129  avgt   20    43.251 ?  0.052    61.872 ?  0.139  ns/op
mismatchMid     256  avgt   20    79.509 ?  0.335    92.928 ?  0.254  ns/op
mismatchMid     257  avgt   20    79.866 ?  0.181    92.983 ?  0.143  ns/op
mismatchMid     512  avgt   20   105.535 ?  0.192   131.530 ?  0.439  ns/op
mismatchMid     513  avgt   20   105.529 ?  0.187    89.155 ?  0.191  ns/op
mismatchMid    1024  avgt   20   174.790 ?  0.508   206.822 ?  0.319  ns/op
mismatchMid    1025  avgt   20   177.107 ?  0.214   171.583 ?  0.316  ns/op
mismatchMid    2048  avgt   20   323.895 ?  0.532   222.394 ?  1.406  ns/op
mismatchMid    2049  avgt   20   322.641 ?  0.494   390.688 ?  1.218  ns/op
mismatchMid    4096  avgt   20   604.134 ?  1.767   356.821 ?  0.560  ns/op
mismatchMid    4097  avgt   20   600.134 ?  0.452   356.340 ?  1.026  ns/op
mismatchMid    8191  avgt   20  1300.201 ? 21.257   734.397 ? 24.208  ns/op
mismatchMid    8192  avgt   20  1296.464 ? 15.849   771.202 ? 25.394  ns/op
mismatchMid    8193  avgt   20  1243.546 ? 25.099  1500.175 ? 25.342  ns/op
--------------------------------------------------------------------------
                                   [-UseVMI]         [+UseVMI]
Benchmark    (size)  Mode  Cnt     Score   Error     Score    Error  Units
mismatchEnd       7  avgt   20    26.491 ? 0.100    53.638 ?  0.117  ns/op
mismatchEnd       8  avgt   20    26.411 ? 0.102    68.876 ?  0.182  ns/op
mismatchEnd       9  avgt   20    27.324 ? 0.048    64.359 ?  0.185  ns/op
mismatchEnd      15  avgt   20    28.621 ? 0.040    66.827 ?  0.226  ns/op
mismatchEnd      16  avgt   20    28.433 ? 0.062    52.708 ?  0.153  ns/op
mismatchEnd      17  avgt   20    31.589 ? 0.048    61.956 ?  0.218  ns/op
mismatchEnd      31  avgt   20    35.283 ? 0.099    52.598 ?  0.215  ns/op
mismatchEnd      32  avgt   20    34.474 ? 0.046    53.540 ?  0.079  ns/op
mismatchEnd      33  avgt   20    36.643 ? 0.032    60.249 ?  0.119  ns/op
mismatchEnd      63  avgt   20    42.715 ? 0.062    52.613 ?  0.170  ns/op
mismatchEnd      64  avgt   20    43.235 ? 0.097    60.763 ?  0.077  ns/op
mismatchEnd      65  avgt   20    44.814 ? 0.052    60.245 ?  0.167  ns/op
mismatchEnd     128  avgt   20    83.400 ? 0.255    62.436 ?  0.145  ns/op
mismatchEnd     129  avgt   20    82.695 ? 0.310    79.398 ?  0.159  ns/op
mismatchEnd     256  avgt   20   109.686 ? 0.701    79.760 ?  0.215  ns/op
mismatchEnd     257  avgt   20   106.839 ? 0.214   102.398 ?  0.226  ns/op
mismatchEnd     512  avgt   20   179.041 ? 0.315   194.417 ?  0.306  ns/op
mismatchEnd     513  avgt   20   196.063 ? 1.059   120.285 ?  0.205  ns/op
mismatchEnd    1024  avgt   20   325.552 ? 0.308   228.808 ?  1.533  ns/op
mismatchEnd    1025  avgt   20   338.941 ? 1.940   231.754 ?  0.625  ns/op
mismatchEnd    2048  avgt   20   606.574 ? 0.708   665.116 ?  1.584  ns/op
mismatchEnd    2049  avgt   20   627.944 ? 1.076   499.117 ?  0.689  ns/op
mismatchEnd    4096  avgt   20  1168.854 ? 1.897   646.402 ?  1.469  ns/op
mismatchEnd    4097  avgt   20  1193.711 ? 1.462   946.456 ? 13.655  ns/op
mismatchEnd    8191  avgt   20  2346.392 ? 7.793  1257.871 ? 14.715  ns/op
mismatchEnd    8192  avgt   20  2328.621 ? 5.346  2524.486 ?  6.931  ns/op
mismatchEnd    8193  avgt   20  2332.721 ? 2.013  1832.337 ?  2.021  ns/op

ArraysMismatch.Int

------------------------------------------------------------------------
                                   [-UseVMI]       [+UseVMI]
Benchmark      (size)  Mode  Cnt   Score   Error   Score    Error  Units
mismatchStart       7  avgt   20  27.098 ? 0.067  65.827 ?  0.314  ns/op
mismatchStart       8  avgt   20  27.098 ? 0.050  65.906 ?  0.184  ns/op
mismatchStart       9  avgt   20  27.064 ? 0.034  63.019 ?  0.123  ns/op
mismatchStart      15  avgt   20  27.088 ? 0.063  63.511 ?  0.169  ns/op
mismatchStart      16  avgt   20  27.097 ? 0.092  63.487 ?  0.084  ns/op
mismatchStart      17  avgt   20  27.112 ? 0.084  60.558 ?  0.248  ns/op
mismatchStart      31  avgt   20  27.108 ? 0.110  52.560 ?  0.104  ns/op
mismatchStart      32  avgt   20  27.045 ? 0.036  52.605 ?  0.110  ns/op
mismatchStart      33  avgt   20  27.089 ? 0.067  60.276 ?  0.184  ns/op
mismatchStart      63  avgt   20  27.074 ? 0.039  60.751 ?  0.144  ns/op
mismatchStart      64  avgt   20  27.088 ? 0.031  52.554 ?  0.199  ns/op
mismatchStart      65  avgt   20  27.063 ? 0.040  60.276 ?  0.121  ns/op
mismatchStart     128  avgt   20  27.082 ? 0.054  52.647 ?  0.105  ns/op
mismatchStart     129  avgt   20  27.068 ? 0.053  60.150 ?  0.125  ns/op
mismatchStart     256  avgt   20  27.118 ? 0.147  52.579 ?  0.148  ns/op
mismatchStart     257  avgt   20  27.041 ? 0.037  60.312 ?  0.183  ns/op
mismatchStart     512  avgt   20  27.095 ? 0.054  60.761 ?  0.114  ns/op
mismatchStart     513  avgt   20  27.075 ? 0.040  52.474 ?  0.054  ns/op
mismatchStart    1024  avgt   20  27.112 ? 0.058  52.513 ?  0.086  ns/op
mismatchStart    1025  avgt   20  27.078 ? 0.031  60.225 ?  0.131  ns/op
mismatchStart    2048  avgt   20  26.817 ? 0.026  60.924 ?  0.155  ns/op
mismatchStart    2049  avgt   20  26.809 ? 0.034  60.163 ?  0.071  ns/op
mismatchStart    4096  avgt   20  26.823 ? 0.064  52.599 ?  0.078  ns/op
mismatchStart    4097  avgt   20  26.830 ? 0.076  60.231 ?  0.129  ns/op
mismatchStart    8191  avgt   20  26.801 ? 0.022  60.773 ?  0.093  ns/op
mismatchStart    8192  avgt   20  26.793 ? 0.039  66.196 ? 15.138  ns/op
mismatchStart    8193  avgt   20  26.833 ? 0.050  63.198 ? 11.830  ns/op
---------------------------------------------------------------------------
                                   [-UseVMI]          [+UseVMI]
Benchmark    (size)  Mode  Cnt     Score    Error     Score    Error  Units
mismatchMid       7  avgt   20    27.266 ?  0.060    52.904 ?  0.168  ns/op
mismatchMid       8  avgt   20    28.185 ?  0.042    52.768 ?  0.205  ns/op
mismatchMid       9  avgt   20    28.195 ?  0.061    52.631 ?  0.118  ns/op
mismatchMid      15  avgt   20    29.593 ?  0.045    52.625 ?  0.243  ns/op
mismatchMid      16  avgt   20    29.554 ?  0.062    63.470 ?  0.186  ns/op
mismatchMid      17  avgt   20    29.514 ?  0.041    63.535 ?  0.209  ns/op
mismatchMid      31  avgt   20    34.121 ?  0.106    60.886 ?  0.309  ns/op
mismatchMid      32  avgt   20    34.509 ?  0.070    52.593 ?  0.088  ns/op
mismatchMid      33  avgt   20    34.472 ?  0.041    52.572 ?  0.229  ns/op
mismatchMid      63  avgt   20    43.197 ?  0.186    60.785 ?  0.200  ns/op
mismatchMid      64  avgt   20    43.232 ?  0.085    73.379 ?  0.146  ns/op
mismatchMid      65  avgt   20    43.199 ?  0.050    73.268 ?  0.173  ns/op
mismatchMid     128  avgt   20    79.260 ?  0.182    92.517 ?  0.149  ns/op
mismatchMid     129  avgt   20    79.405 ?  0.067    75.556 ?  0.115  ns/op
mismatchMid     256  avgt   20   105.472 ?  0.223   131.389 ?  0.265  ns/op
mismatchMid     257  avgt   20   105.502 ?  0.148    88.643 ?  0.155  ns/op
mismatchMid     512  avgt   20   178.320 ?  0.222   128.123 ?  0.185  ns/op
mismatchMid     513  avgt   20   174.414 ?  0.256   178.487 ?  0.197  ns/op
mismatchMid    1024  avgt   20   324.065 ?  0.487   432.474 ?  1.475  ns/op
mismatchMid    1025  avgt   20   319.162 ?  0.443   218.608 ?  1.571  ns/op
mismatchMid    2048  avgt   20   604.794 ?  1.826   688.263 ?  0.417  ns/op
mismatchMid    2049  avgt   20   598.749 ?  0.525   690.281 ?  2.480  ns/op
mismatchMid    4096  avgt   20  1303.515 ? 19.864  1396.482 ? 24.848  ns/op
mismatchMid    4097  avgt   20  1236.637 ? 17.324  1450.771 ? 25.739  ns/op
mismatchMid    8191  avgt   20  2567.522 ? 19.046  1452.557 ? 26.459  ns/op
mismatchMid    8192  avgt   20  2556.190 ? 15.588  1475.063 ? 27.504  ns/op
mismatchMid    8193  avgt   20  2668.605 ? 23.387  1421.295 ? 17.188  ns/op
---------------------------------------------------------------------------
                                       [-UseVMI]          [+UseVMI]
Benchmark    (size)  Mode  Cnt     Score    Error     Score    Error  Units
mismatchEnd       7  avgt   20    27.094 ?  0.057    52.601 ?  0.150  ns/op
mismatchEnd       8  avgt   20    27.150 ?  0.045    65.669 ?  0.095  ns/op
mismatchEnd       9  avgt   20    28.051 ?  0.104    63.044 ?  0.136  ns/op
mismatchEnd      15  avgt   20    31.719 ?  0.051    52.593 ?  0.146  ns/op
mismatchEnd      16  avgt   20    32.267 ?  0.051    52.622 ?  0.120  ns/op
mismatchEnd      17  avgt   20    33.920 ?  0.019    60.419 ?  0.207  ns/op
mismatchEnd      31  avgt   20    40.028 ?  0.168    60.743 ?  0.112  ns/op
mismatchEnd      32  avgt   20    41.077 ?  0.075    52.575 ?  0.129  ns/op
mismatchEnd      33  avgt   20    42.113 ?  0.076    61.258 ?  0.052  ns/op
mismatchEnd      63  avgt   20    77.585 ?  0.128    89.401 ?  0.126  ns/op
mismatchEnd      64  avgt   20    77.721 ?  0.089    86.435 ?  0.231  ns/op
mismatchEnd      65  avgt   20    80.621 ?  0.315    77.725 ?  0.150  ns/op
mismatchEnd     128  avgt   20   102.283 ?  0.274    79.531 ?  0.230  ns/op
mismatchEnd     129  avgt   20   104.539 ?  0.262   101.622 ?  0.222  ns/op
mismatchEnd     256  avgt   20   182.748 ?  2.517   120.635 ?  0.456  ns/op
mismatchEnd     257  avgt   20   178.289 ?  0.478   115.772 ?  0.256  ns/op
mismatchEnd     512  avgt   20   318.475 ?  0.442   227.350 ?  0.531  ns/op
mismatchEnd     513  avgt   20   325.110 ?  1.248   378.399 ?  0.961  ns/op
mismatchEnd    1024  avgt   20   609.902 ?  2.539   665.156 ?  2.408  ns/op
mismatchEnd    1025  avgt   20   607.581 ?  1.160   498.861 ?  0.685  ns/op
mismatchEnd    2048  avgt   20  1175.314 ?  3.483  1285.923 ?  1.967  ns/op
mismatchEnd    2049  avgt   20  1175.812 ?  2.733   941.132 ?  0.955  ns/op
mismatchEnd    4096  avgt   20  2317.976 ?  7.545  2618.651 ? 25.386  ns/op
mismatchEnd    4097  avgt   20  2403.044 ? 10.723  1843.361 ? 20.513  ns/op
mismatchEnd    8191  avgt   20  5304.666 ? 24.810  3067.622 ?  9.863  ns/op
mismatchEnd    8192  avgt   20  5343.027 ? 15.349  3039.747 ? 26.420  ns/op
mismatchEnd    8193  avgt   20  5308.661 ? 28.187  4410.391 ? 69.160  ns/op

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

PR Comment: https://git.openjdk.org/jdk/pull/17750#issuecomment-1932197818
PR Comment: https://git.openjdk.org/jdk/pull/17750#issuecomment-1932198358
PR Comment: https://git.openjdk.org/jdk/pull/17750#issuecomment-1932199716
PR Comment: https://git.openjdk.org/jdk/pull/17750#issuecomment-1932201386

From luhenry at openjdk.org  Wed Feb  7 14:52:57 2024
From: luhenry at openjdk.org (Ludovic Henry)
Date: Wed, 7 Feb 2024 14:52:57 GMT
Subject: RFR: 8320646: RISC-V: C2 VectorCastHF2F
In-Reply-To: <bnbGMlL-ugSiK4TnQWG27Qrp6t4upI4cSWSakCIPvB8=.d5fff64c-8dfa-4a0b-b8c6-6ef1b8741a2a@github.com>
References: <kqLQR-bD3v7iF7LgH0PzwIH_m6QH_2b371pKz9_Ovq8=.9c07c165-2a97-4a6b-9e82-6a6de0b81328@github.com>
 <bnbGMlL-ugSiK4TnQWG27Qrp6t4upI4cSWSakCIPvB8=.d5fff64c-8dfa-4a0b-b8c6-6ef1b8741a2a@github.com>
Message-ID: <_CH8edSIFXCvKE9UNFj9cYMf7SJXEZyqROw6hI1udQM=.e69faf1a-992f-46ff-90ac-d1902c759b8b@github.com>

On Tue, 6 Feb 2024 21:40:57 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> Hi,
>> Can you review this patch to add instrinsics for VectorCastHF2F/VectorCastF2HF?
>> Thanks!
>> 
>> ## Test
>> 
>> test/jdk/java/lang/Float/Binary16ConversionNaN.java
>> test/jdk/java/lang/Float/Binary16Conversion.java
>> 
>> hotspot/jtreg/compiler/intrinsics/float16
>> hotspot/jtreg/compiler/vectorization/TestFloatConversionsVectorjava
>> hotspot/jtreg/compiler/vectorization/TestFloatConversionsVectorNaN.java
>
> src/hotspot/cpu/riscv/assembler_riscv.hpp line 1617:
> 
>> 1615:   INSN(vadd_vi,   0b1010111, 0b011, 0b000000);
>> 1616:   INSN(vrsub_vi,  0b1010111, 0b011, 0b000011);
>> 1617:   INSN(vnsra_wi,  0b1010111, 0b011, 0b101101);
> 
> ~~You can put it up with `vnsra_wx` in the "Vector Narrowing Integer Right Shift Instructions" at https://github.com/openjdk/jdk/pull/17698/files#diff-314214875276cd9a11ecdfd52b68403ded286710ba0820461b0b510506f61a33R1528~~

Let's add a comment to make it more clear what these are
Suggestion:


  // Vector Single-Width Floating-Point Add/Subtract Instructions
  INSN(vnsra_wi,  0b1010111, 0b011, 0b101101);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17698#discussion_r1481592353

From duke at openjdk.org  Wed Feb  7 14:57:56 2024
From: duke at openjdk.org (Yuri Gaevsky)
Date: Wed, 7 Feb 2024 14:57:56 GMT
Subject: RFR: 8324124: RISC-V: implement _vectorizedMismatch intrinsic
In-Reply-To: <dxSBhJiLeVkLF8PvHW3MMg69vwXU0VshECCMz5HnhhI=.e0cbda8b-f7f6-44ff-806b-1f21496911be@github.com>
References: <dxSBhJiLeVkLF8PvHW3MMg69vwXU0VshECCMz5HnhhI=.e0cbda8b-f7f6-44ff-806b-1f21496911be@github.com>
Message-ID: <OrJ6ubyQaFLoWpCEEg2yta8993aaFPtCG6VVxdeyGGk=.521e4411-7ed3-4cde-8429-591f3e4638c8@github.com>

On Wed, 7 Feb 2024 14:35:55 GMT, Yuri Gaevsky <duke at openjdk.org> wrote:

> Hello All,
> 
> Please review these changes to enable the __vectorizedMismatch_ intrinsic on RISC-V platform with RVV instructions supported.
> 
> Thank you,
> -Yuri Gaevsky
> 
> **Correctness checks:**
>   hotspot/jtreg/compiler/{intrinsic/c1/c2}/ under QEMU-8.1 with RVV v1.0.0 and -XX:TieredStopAtLevel=1/2/3/4.

src/hotspot/cpu/riscv/c1_LIRGenerator_riscv.cpp line 805:

> 803: }
> 804: 
> 805: void LIRGenerator::do_vectorizedMismatch(Intrinsic* x) {

NB: This code is similar to X86.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17750#discussion_r1481601446

From mli at openjdk.org  Wed Feb  7 15:22:09 2024
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 7 Feb 2024 15:22:09 GMT
Subject: RFR: 8320646: RISC-V: C2 VectorCastHF2F [v2]
In-Reply-To: <kqLQR-bD3v7iF7LgH0PzwIH_m6QH_2b371pKz9_Ovq8=.9c07c165-2a97-4a6b-9e82-6a6de0b81328@github.com>
References: <kqLQR-bD3v7iF7LgH0PzwIH_m6QH_2b371pKz9_Ovq8=.9c07c165-2a97-4a6b-9e82-6a6de0b81328@github.com>
Message-ID: <fTvkUqcIsICvOIRWhqcICR8OYfaiOsOgSoaJsgUUm94=.09bb33c2-ce00-4943-bed0-0a1906395ee4@github.com>

> Hi,
> Can you review this patch to add instrinsics for VectorCastHF2F/VectorCastF2HF?
> Thanks!
> 
> ## Test
> 
> test/jdk/java/lang/Float/Binary16ConversionNaN.java
> test/jdk/java/lang/Float/Binary16Conversion.java
> 
> hotspot/jtreg/compiler/intrinsics/float16
> hotspot/jtreg/compiler/vectorization/TestFloatConversionsVectorjava
> hotspot/jtreg/compiler/vectorization/TestFloatConversionsVectorNaN.java

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  add some comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17698/files
  - new: https://git.openjdk.org/jdk/pull/17698/files/521c2221..5964bb60

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

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

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

From mli at openjdk.org  Wed Feb  7 15:22:09 2024
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 7 Feb 2024 15:22:09 GMT
Subject: RFR: 8320646: RISC-V: C2 VectorCastHF2F [v2]
In-Reply-To: <_CH8edSIFXCvKE9UNFj9cYMf7SJXEZyqROw6hI1udQM=.e69faf1a-992f-46ff-90ac-d1902c759b8b@github.com>
References: <kqLQR-bD3v7iF7LgH0PzwIH_m6QH_2b371pKz9_Ovq8=.9c07c165-2a97-4a6b-9e82-6a6de0b81328@github.com>
 <bnbGMlL-ugSiK4TnQWG27Qrp6t4upI4cSWSakCIPvB8=.d5fff64c-8dfa-4a0b-b8c6-6ef1b8741a2a@github.com>
 <_CH8edSIFXCvKE9UNFj9cYMf7SJXEZyqROw6hI1udQM=.e69faf1a-992f-46ff-90ac-d1902c759b8b@github.com>
Message-ID: <CwLQp8X5LYxC8wMIRy0Ja_SiYr0uuXx3pFHfbp0YQkw=.06396f8c-4ef5-44c8-a56d-9833b2a9b02d@github.com>

On Wed, 7 Feb 2024 14:49:23 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> src/hotspot/cpu/riscv/assembler_riscv.hpp line 1617:
>> 
>>> 1615:   INSN(vadd_vi,   0b1010111, 0b011, 0b000000);
>>> 1616:   INSN(vrsub_vi,  0b1010111, 0b011, 0b000011);
>>> 1617:   INSN(vnsra_wi,  0b1010111, 0b011, 0b101101);
>> 
>> ~~You can put it up with `vnsra_wx` in the "Vector Narrowing Integer Right Shift Instructions" at https://github.com/openjdk/jdk/pull/17698/files#diff-314214875276cd9a11ecdfd52b68403ded286710ba0820461b0b510506f61a33R1528~~
>
> Let's add a comment to make it more clear what these are
> Suggestion:
> 
> 
>   // Vector Single-Width Floating-Point Add/Subtract Instructions
>   INSN(vnsra_wi,  0b1010111, 0b011, 0b101101);

Thanks, it's done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17698#discussion_r1481639709

From mli at openjdk.org  Wed Feb  7 15:25:01 2024
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 7 Feb 2024 15:25:01 GMT
Subject: RFR: 8320646: RISC-V: C2 VectorCastHF2F
In-Reply-To: <kqLQR-bD3v7iF7LgH0PzwIH_m6QH_2b371pKz9_Ovq8=.9c07c165-2a97-4a6b-9e82-6a6de0b81328@github.com>
References: <kqLQR-bD3v7iF7LgH0PzwIH_m6QH_2b371pKz9_Ovq8=.9c07c165-2a97-4a6b-9e82-6a6de0b81328@github.com>
Message-ID: <SxdwgoAsQR3ENLYZls5bKFPL9TQbEZdcqGRu15ozqDM=.b1b1091d-c0ff-45ab-9fdb-851ef686946d@github.com>

On Sun, 4 Feb 2024 09:38:48 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you review this patch to add instrinsics for VectorCastHF2F/VectorCastF2HF?
> Thanks!
> 
> ## Test
> 
> test/jdk/java/lang/Float/Binary16ConversionNaN.java
> test/jdk/java/lang/Float/Binary16Conversion.java
> 
> hotspot/jtreg/compiler/intrinsics/float16
> hotspot/jtreg/compiler/vectorization/TestFloatConversionsVectorjava
> hotspot/jtreg/compiler/vectorization/TestFloatConversionsVectorNaN.java

Hey, I'll be on vacation for a while, so maybe slow in response.
But please leave your comments freely as usual.

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

PR Comment: https://git.openjdk.org/jdk/pull/17698#issuecomment-1932275163

From mli at openjdk.org  Wed Feb  7 15:25:02 2024
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 7 Feb 2024 15:25:02 GMT
Subject: RFR: 8322179: RISC-V: Implement SHA-1 intrinsic [v10]
In-Reply-To: <bAQOJj5ESbBOFxTqNRBDf36jquSMydvN_ey2CleFmD0=.8d3ff5c7-3c78-4113-af39-7dbba435f591@github.com>
References: <PyIXzENfiHysFS3IyZn3FDNQpV7Ua2L6OmjiXq9wRoU=.cf74a45e-c94b-4f7b-8768-d10d55e2ce1d@github.com>
 <bAQOJj5ESbBOFxTqNRBDf36jquSMydvN_ey2CleFmD0=.8d3ff5c7-3c78-4113-af39-7dbba435f591@github.com>
Message-ID: <d39OyZ_A6h83YK0Wbl30gL6bv1y7huZV87hrmRjem5g=.0691d764-1d8a-48eb-9afb-b7397107ec9c@github.com>

On Tue, 6 Feb 2024 15:36:12 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you review this patch to implement SHA-1 intrinsic for riscv?
>> Thanks!
>> 
>> 
>> ## Test
>> 
>> ### Functionality
>> 
>> tests under `test/hotspot/jtreg/compiler/intrinsics/sha`
>> tests found via `find test/jdk -iname "*SHA1*.java"`
>> 
>> ### Performance
>> 
>> tested on `T-HEAD Light Lichee Pi 4A`
>> 
>> JMH_PARAMS="-f 1 -wi 10 -i 20" // for every loop of jmh test
>> 
>> benchmark tests `MessageDigests.java GetMessageDigest.java MessageDigestBench.java MacBench.java` which are under `test/micro/org/openjdk/bench/`, more spcifically `TESTS="MessageDigests.digest MessageDigests.getAndDigest MessageDigestBench.digest"`
>> 
>> 
>> // After
>> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1        64     DEFAULT  avgt   20      1845.446 ?     27.052  ns/op
>> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    181455.350 ?    532.258  ns/op
>> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2447.674 ?     10.239  ns/op
>> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    182896.083 ?   1242.774  ns/op
>> o.o.b.javax.crypto.small.MessageDigestBench.digest         SHA1     1048576             N/A       N/A              avgt   20  11599227.792 ? 121442.390  ns/op
>> // Before
>> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2352.475 ?    11.198  ns/op
>> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    188495.684 ?  1467.942  ns/op
>> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2437.347 ?     6.398  ns/op
>> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    196086.570 ?  1140.998  ns/op
>> o.o.b.javax.crypto.small.MessageDigestBench.digest         SHA1     1048576             N/A       N/A              avgt   20  12362160.119 ? 38788.109  ns/op
>> 
>> 
>> **getAndDigest when size == 64**
>> The data is not stable for test getAndDigest when size == 64, which I think is introduced by  j.s.MessageDigest.getInstance itself, which we don't touch in this patch.
>> Check more details at [1](ht...
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   refine register usage and comment

Hey, I'll be on vacation for a while, so maybe slow in response.
But please leave your comments freely as usual.

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

PR Comment: https://git.openjdk.org/jdk/pull/17130#issuecomment-1932277048

From aboldtch at openjdk.org  Wed Feb  7 15:52:05 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 7 Feb 2024 15:52:05 GMT
Subject: RFR: 8324881: ObjectSynchronizer::inflate(Thread* current...) is
 invoked for non-current thread [v11]
In-Reply-To: <Eag9wT75Jlj6FIoT5lrUKpZxwtKLjxwlLyu51kCEUeY=.f814c2ad-0f74-4a28-8766-51a9cffd8818@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
 <Eag9wT75Jlj6FIoT5lrUKpZxwtKLjxwlLyu51kCEUeY=.f814c2ad-0f74-4a28-8766-51a9cffd8818@github.com>
Message-ID: <GoNx-oDoLl_lE48UDk9txGVmyyTIP-hLF8GR5__tooM=.000f09fc-1716-402f-aedb-5db9a462d1ea@github.com>

On Wed, 7 Feb 2024 14:33:15 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The `ObjectSynchronizer` has always assumed that the `current` parameters are both the current thread as well as the thread that is doing the locking. The only time that we are entering on behalf of another thread is when doing re-locking in deoptimization. This has worked because the deoptee thread is suspended. However ResourceMarks have been using the wrong thread when logging is enabled.
>> 
>> This change `ObjectSynchronizer` instruments the relevant methods with both a `JavaThread* locking_thread` as well as `[Java]Thread* current` to be able to use the correct thread for ResourceMarks. 
>> 
>> Having the `inflate` care about a `locking_thread` is a little unpleasant in my opinion. But it is required for LM_LIGHTWEIGHT. 
>> Would probably be cleaner if the inflate for LM_LIGHTWEIGHT was it's own thing, as it does not share the whole INFLATING protocol. But seems like a future RFE to refactor this code.
>> 
>> Can reproduce a crash by modifying `test/jdk/com/sun/jdi/EATests.java` and using `-XX:DiagnoseSyncOnValueBasedClasses=2` with LM_LEGACY or running `test/jdk/com/sun/jdi/EATests.java` with LM_LIGHTWEIGHT/LM_MONITOR and `-Xlog:monitorinflation=trace`. 
>> 
>> Could extend this test to capture this regression in the future (or creating a new test based on the same infrastructure). Will give it an attempt, so we have a regression test for this. But these tests get rather involved as the require a lot of jvmti setup.
>
> Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 25 additional commits since the last revision:
> 
>  - Add comment about failed to fast lock.
>  - Missing space
>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8324881
>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8324881
>  - Update comment
>  - Fix comments
>  - Update test/jdk/com/sun/jdi/EATests.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update test/jdk/com/sun/jdi/EATests.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update test/jdk/com/sun/jdi/EATests.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update test/jdk/com/sun/jdi/EATests.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - ... and 15 more: https://git.openjdk.org/jdk/compare/d0bb75a4...216680c9

Thanks for all the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/17626#issuecomment-1932332366

From aboldtch at openjdk.org  Wed Feb  7 15:52:05 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 7 Feb 2024 15:52:05 GMT
Subject: Integrated: 8324881: ObjectSynchronizer::inflate(Thread* current...)
 is invoked for non-current thread
In-Reply-To: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
References: <zJ1sEDC1678_HmSIK0TqVttqfXw6HaX24bJ96VPg0MA=.1aea39cc-5e9a-4d1e-aaa1-85ce3bfb2ae7@github.com>
Message-ID: <Jm0igqVLGjQovch_h-BEbTw2TIUhh8WrwqC4n-g6iW0=.48476224-5b1d-4f08-a483-bbf08b51a876@github.com>

On Tue, 30 Jan 2024 10:03:41 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> The `ObjectSynchronizer` has always assumed that the `current` parameters are both the current thread as well as the thread that is doing the locking. The only time that we are entering on behalf of another thread is when doing re-locking in deoptimization. This has worked because the deoptee thread is suspended. However ResourceMarks have been using the wrong thread when logging is enabled.
> 
> This change `ObjectSynchronizer` instruments the relevant methods with both a `JavaThread* locking_thread` as well as `[Java]Thread* current` to be able to use the correct thread for ResourceMarks. 
> 
> Having the `inflate` care about a `locking_thread` is a little unpleasant in my opinion. But it is required for LM_LIGHTWEIGHT. 
> Would probably be cleaner if the inflate for LM_LIGHTWEIGHT was it's own thing, as it does not share the whole INFLATING protocol. But seems like a future RFE to refactor this code.
> 
> Can reproduce a crash by modifying `test/jdk/com/sun/jdi/EATests.java` and using `-XX:DiagnoseSyncOnValueBasedClasses=2` with LM_LEGACY or running `test/jdk/com/sun/jdi/EATests.java` with LM_LIGHTWEIGHT/LM_MONITOR and `-Xlog:monitorinflation=trace`. 
> 
> Could extend this test to capture this regression in the future (or creating a new test based on the same infrastructure). Will give it an attempt, so we have a regression test for this. But these tests get rather involved as the require a lot of jvmti setup.

This pull request has now been integrated.

Changeset: a3a2b1fb
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a3a2b1fbbf00577ce1d0e3a44e9537e997b30b05
Stats:     362 lines in 6 files changed: 304 ins; 10 del; 48 mod

8324881: ObjectSynchronizer::inflate(Thread* current...) is invoked for non-current thread

Reviewed-by: rrich, dholmes, coleenp, dcubed

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

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

From ihse at openjdk.org  Wed Feb  7 15:53:59 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 7 Feb 2024 15:53:59 GMT
Subject: RFR: 8325109: Sort method modifiers in canonical order
In-Reply-To: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
References: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
Message-ID: <AbyHgk1wHchuCkp0snusjEkqPmCzyc_IRaEbP8f9tNE=.eb528716-b511-4d83-a3a9-480f8487ff6d@github.com>

On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a follow-up on [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the bin/blessed-modifier-order.sh on the entire code base, and manually checked the result. I have reverted all but these trivial and uncontroversial changes.
> 
> Almost all of these are about moving `static` to its proper position; a few do not involve `static` but instead puts `final` or `abstract` in the correct place.
> 
> I have deliberately stayed away from `default` in this PR, since they should probably get a more thorough treatment, see https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473.

Just to confirm publicly, there is no need for any special handling of `java.util.concurrent` any longer; the JDK repo is the single source of truth nowadays.

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

PR Comment: https://git.openjdk.org/jdk/pull/17670#issuecomment-1932335281

From ihse at openjdk.org  Wed Feb  7 15:53:59 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 7 Feb 2024 15:53:59 GMT
Subject: Integrated: 8325109: Sort method modifiers in canonical order
In-Reply-To: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
References: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
Message-ID: <xk3ADOyZQDY-sxr5Ph7VYQTzRabzGFg0kBCsVxThQro=.b8764313-7ea0-4939-93a5-8e9501b63756@github.com>

On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a follow-up on [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the bin/blessed-modifier-order.sh on the entire code base, and manually checked the result. I have reverted all but these trivial and uncontroversial changes.
> 
> Almost all of these are about moving `static` to its proper position; a few do not involve `static` but instead puts `final` or `abstract` in the correct place.
> 
> I have deliberately stayed away from `default` in this PR, since they should probably get a more thorough treatment, see https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473.

This pull request has now been integrated.

Changeset: 18e24d06
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/18e24d0619ffef7c6dbfc419105faba9f7ba1874
Stats:     61 lines in 39 files changed: 0 ins; 0 del; 61 mod

8325109: Sort method modifiers in canonical order

Reviewed-by: aivanov, rriggs, darcy, prappo

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

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

From rkennke at openjdk.org  Wed Feb  7 18:37:29 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 7 Feb 2024 18:37:29 GMT
Subject: RFR: 8305898: Alternative self-forwarding mechanism
Message-ID: <N4eX8S-btv0VD19kl2W9RigVsaw58ZVXDZllFwykZ04=.a9456aa8-b294-480a-b7f0-07616c972f62@github.com>

Currently, the Serial, Parallel and G1 GCs store a pointer to self into object headers to indicate promotion failure. This is problematic for compact object headers ([JDK-8294992](https://bugs.openjdk.org/browse/JDK-8294992)) because it would (temporarily) over-write the crucial class information, which we need for heap parsing. I would like to propose an alternative: use the currently unused 3rd header bit (previously biased-locking bit) to indicate that an object is 'self-forwarded'. That preserves the crucial class information in the upper bits of the header until the full header gets restored.

This is a trimmed-down/simplified version of the original proposal #13779:
 - It doesn't use/introduce any flags and avoids the associated branching.
 - It doesn't (need to) deal with displaced headers. (Current code would preserve header if necessary, Lilliput code would not use displaced headers and set the 3rd bit directly in existing header.)

Testing:
 - [x] hotspot_gc
 - [x] tier1
 - [x] tier2

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

Commit messages:
 - 8305898: Alternative self-forwarding mechanism

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

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

From lkorinth at openjdk.org  Wed Feb  7 20:37:15 2024
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 7 Feb 2024 20:37:15 GMT
Subject: RFR: 8320750: Allow a testcase to run with multiple -Xlog [v2]
In-Reply-To: <LzqG8tmHZgoSqxPjEnULam9uGycRNpdBuPoUjXAdze0=.df98f685-7800-475e-ad3e-7d555c1470ea@github.com>
References: <LzqG8tmHZgoSqxPjEnULam9uGycRNpdBuPoUjXAdze0=.df98f685-7800-475e-ad3e-7d555c1470ea@github.com>
Message-ID: <XvF3_iQLanMjMxlu_bS1vcMgYSXYcbFX_mAClOvv6tM=.08c68c1b-3654-467a-8c4c-3ba09e6f6832@github.com>

> Running a testcase with muliple -Xlog crashes JTREG test cases. This is because `Collector.toMap` is not given a merge strategy.
> 
> When the same argument is passed multiple times, I have added a merge strategy to use the latter value. This is similar to how it is implemented for `vm.opt.*` in JTREG.
> 
> If the flag tested is `-Xlog`, replace the value part with a dummy value "NONEMPTY_TEST_SENTINEL". This is because in the case of multiple `-Xlog` all values are used, and JTREG does not give a satisfactory way to represent them. This dummy value should make it hard to try to `@require` on specific values by mistake.
> 
> Tested with:
> 
>  @requires vm.opt.x.Xlog == "NONEMPTY_TEST_SENTINEL"
>  @requires vm.opt.x.Xlog == "NONEMPTY_TEST_SENTINELXXX"
>  @requires vm.opt.x.Xms == "3g"
> 
> and
> 
> JAVA_OPTIONS=-Xms3g -Xms4g
> JAVA_OPTIONS=-Xms4g -Xms3g
> JAVA_OPTIONS=-Xlog:gc* -Xlog:gc*
> ``` 
> 
> Running tier1

Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:

  Added test, reworked code structure after suggestions from Stefan and Johan

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16824/files
  - new: https://git.openjdk.org/jdk/pull/16824/files/a31b90a2..d129a0fb

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

  Stats: 122 lines in 2 files changed: 107 ins; 5 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/16824.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16824/head:pull/16824

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

From lkorinth at openjdk.org  Wed Feb  7 20:39:55 2024
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 7 Feb 2024 20:39:55 GMT
Subject: RFR: 8320750: Allow a testcase to run with multiple -Xlog [v2]
In-Reply-To: <XvF3_iQLanMjMxlu_bS1vcMgYSXYcbFX_mAClOvv6tM=.08c68c1b-3654-467a-8c4c-3ba09e6f6832@github.com>
References: <LzqG8tmHZgoSqxPjEnULam9uGycRNpdBuPoUjXAdze0=.df98f685-7800-475e-ad3e-7d555c1470ea@github.com>
 <XvF3_iQLanMjMxlu_bS1vcMgYSXYcbFX_mAClOvv6tM=.08c68c1b-3654-467a-8c4c-3ba09e6f6832@github.com>
Message-ID: <nz6sPMRGLYJvyn9StRmVaBvbIjFGSwfHL3wemojp9og=.6a52c16d-4f8f-412b-9906-b8bb28573d2e@github.com>

On Wed, 7 Feb 2024 20:37:15 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Running a testcase with muliple -Xlog crashes JTREG test cases. This is because `Collector.toMap` is not given a merge strategy.
>> 
>> When the same argument is passed multiple times, I have added a merge strategy to use the latter value. This is similar to how it is implemented for `vm.opt.*` in JTREG.
>> 
>> If the flag tested is `-Xlog`, replace the value part with a dummy value "NONEMPTY_TEST_SENTINEL". This is because in the case of multiple `-Xlog` all values are used, and JTREG does not give a satisfactory way to represent them. This dummy value should make it hard to try to `@require` on specific values by mistake.
>> 
>> Tested with:
>> 
>>  @requires vm.opt.x.Xlog == "NONEMPTY_TEST_SENTINEL"
>>  @requires vm.opt.x.Xlog == "NONEMPTY_TEST_SENTINELXXX"
>>  @requires vm.opt.x.Xms == "3g"
>> 
>> and
>> 
>> JAVA_OPTIONS=-Xms3g -Xms4g
>> JAVA_OPTIONS=-Xms4g -Xms3g
>> JAVA_OPTIONS=-Xlog:gc* -Xlog:gc*
>> ``` 
>> 
>> Running tier1
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added test, reworked code structure after suggestions from Stefan and Johan

I have changed the code after suggestions from Stefan and Johan. I have added a test. I have verified that the test runs in tier1. I am awaiting tier 1-3 to finish.

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

PR Comment: https://git.openjdk.org/jdk/pull/16824#issuecomment-1932828416

From jsjolen at openjdk.org  Wed Feb  7 20:45:56 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 7 Feb 2024 20:45:56 GMT
Subject: RFR: 8320750: Allow a testcase to run with multiple -Xlog [v2]
In-Reply-To: <XvF3_iQLanMjMxlu_bS1vcMgYSXYcbFX_mAClOvv6tM=.08c68c1b-3654-467a-8c4c-3ba09e6f6832@github.com>
References: <LzqG8tmHZgoSqxPjEnULam9uGycRNpdBuPoUjXAdze0=.df98f685-7800-475e-ad3e-7d555c1470ea@github.com>
 <XvF3_iQLanMjMxlu_bS1vcMgYSXYcbFX_mAClOvv6tM=.08c68c1b-3654-467a-8c4c-3ba09e6f6832@github.com>
Message-ID: <RggZw9IT4-2-bbf0fUWFtLALSh5PrUTGJmPUV8rz128=.5dca4dfb-ea3e-47fc-99d3-16b91a1cf349@github.com>

On Wed, 7 Feb 2024 20:37:15 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Running a testcase with muliple -Xlog crashes JTREG test cases. This is because `Collector.toMap` is not given a merge strategy.
>> 
>> When the same argument is passed multiple times, I have added a merge strategy to use the latter value. This is similar to how it is implemented for `vm.opt.*` in JTREG.
>> 
>> If the flag tested is `-Xlog`, replace the value part with a dummy value "NONEMPTY_TEST_SENTINEL". This is because in the case of multiple `-Xlog` all values are used, and JTREG does not give a satisfactory way to represent them. This dummy value should make it hard to try to `@require` on specific values by mistake.
>> 
>> Tested with:
>> 
>>  @requires vm.opt.x.Xlog == "NONEMPTY_TEST_SENTINEL"
>>  @requires vm.opt.x.Xlog == "NONEMPTY_TEST_SENTINELXXX"
>>  @requires vm.opt.x.Xms == "3g"
>> 
>> and
>> 
>> JAVA_OPTIONS=-Xms3g -Xms4g
>> JAVA_OPTIONS=-Xms4g -Xms3g
>> JAVA_OPTIONS=-Xlog:gc* -Xlog:gc*
>> ``` 
>> 
>> Running tier1
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added test, reworked code structure after suggestions from Stefan and Johan

Looks excellent to me!

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

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16824#pullrequestreview-1868753530

From amenkov at openjdk.org  Wed Feb  7 20:59:16 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 7 Feb 2024 20:59:16 GMT
Subject: RFR: JDK-8311076: RedefineClasses doesn't check for ConstantPool
 overflow
Message-ID: <Z_Hq-oct8XO3DtKivbPa-5VbLjLhPiXjSMJfrupUA5U=.ecd68153-3b48-44c0-a06f-c791e334ca6f@github.com>

The fix adds check that merged constant pool does not overflow u2 (two-byte unsigned).
The check is added after merging `the_class` and `scratch_class` constant pools, but before rewriting constant pool references.

testing:
 - sanity tier1;
 - all RedefineClasses/RetransformClasses tests:
   - test/jdk/java/lang/instrument
   - test/hotspot/jtreg/serviceability/jvmti/RedefineClasses
   - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses
   - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses

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

Commit messages:
 - merge_cp_length overflow check

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

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

From dcubed at openjdk.org  Wed Feb  7 23:03:58 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 7 Feb 2024 23:03:58 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v3]
In-Reply-To: <bIMfwFEuiZ1CbUtq3NzEeNuW72i4jAqAHGJKMb_VZdg=.4e228b57-af29-4a78-9534-bae11fa6bb2d@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <bIMfwFEuiZ1CbUtq3NzEeNuW72i4jAqAHGJKMb_VZdg=.4e228b57-af29-4a78-9534-bae11fa6bb2d@github.com>
Message-ID: <tpoboI2WVbmvE1sR9D-7qsm_Mh8m01-Uwt8tA_pNI5g=.c8219d3c-3acd-4a20-9091-5e9cc911617b@github.com>

On Wed, 7 Feb 2024 07:02:11 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
>> The function returns the following structure:
>> 
>> 
>> typedef struct {
>>     jthread owner;
>>     jint entry_count;
>>     jint waiter_count;
>>     jthread* waiters;
>>     jint notify_waiter_count;
>>     jthread* notify_waiters;
>> } jvmtiMonitorUsage;
>> 
>> 
>> The following four fields are defined this way:
>> 
>> waiter_count  [jint] The number of threads waiting to own this monitor
>> waiters  [jthread*] The waiter_count waiting threads
>> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
>> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
>> 
>> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
>> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
>> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
>> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
>> This update makes it right.
>> 
>> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
>> 
>> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
>> 
>>   jvmti/GetObjectMonitorUsage/objmonusage001
>>   jvmti/GetObjectMonitorUsage/objmonusage003
>> 
>> 
>> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
>> 
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
>> 
>> 
>> 
>> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository.
>> 
>> Also, please see and review the related CSR:
>>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
>> 
>> The Release-Note is:
>> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage
>>  
>> Testing:
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn 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
>  - review: thread in notify waiter list can't be BLOCKED
>  - 8324677: Specification clarification needed for JVM TI GetObjectMonitorUsage

Okay... so we might have an incorrect implementation of JVM TI
GetObjectMonitorUsage, but I'm not convinced that it is broken
in the way that we think it is broken.

Please read thru my unfortunately long comments on the complicated
logic in `JvmtiEnvBase::get_object_monitor_usage()`. I _think_ things
are broken in a different way than what we're talking about in this bug.

In particular, the logic that populates the `waiters` array and reduces
the `waiter_count` value overrides the value that we think we're fixing
in the beginning of the function.

Similarly, the logic that populates the `notify_waiters` array and reduces
the `notify_waiter_count` value also overrides the value that we think
we're fixing in the beginning of the function.

src/hotspot/share/prims/jvmtiEnvBase.cpp line 1489:

> 1487:     nWait = mon->waiters();     // # of threads in Object.wait()
> 1488:     ret.waiter_count = nWant;
> 1489:     ret.notify_waiter_count = nWait;

Please note that the comment on L1487 is accurate. The `waiters` count is
incremented just before the thread that has called `wait()` drops the monitor
and that increased count remains in effect until after the thread has reentered
the monitor after being notified or the wait timeout has expired.

The `contentions` count is not incremented in the re-entry path so a thread
that is in `wait()` that has been notified or the wait timeout has expired is not
counted as a contending thread.

So if we really want the `waiter_count` field to include threads that have been
notified or the wait timeout has expired, then we have to add some logic to
carefully increment the `contentions` count.

This old logic:
 ```    ret.waiter_count = nWant + nWait;```
over counts because it also includes threads in `wait()` that have not yet
been notified and the wait timeout has not expired. However, including
`nWait` is correct for the situation when all of the waiting threads have
been notified or their wait timeouts have expired.

This also means that `nWait` and the `ret.notify_waiter_count` value are
over counting waiters because that value will include threads that (have
been notified or the wait timeout has expired) AND have not reentered
the monitor. I _think_ we're saying that is NOT what we want. However,
I _think_ that the `nWait` value is fixed below when we're gathering up
the list of waiters.

src/hotspot/share/prims/jvmtiEnvBase.cpp line 1521:

> 1519:       // we have contending and/or waiting threads
> 1520:       if (nWant > 0) {
> 1521:         // we have contending threads

This block includes this logic:

        // get_pending_threads returns only java thread so we do not need to
        // check for non java threads.
        GrowableArray<JavaThread*>* wantList = Threads::get_pending_threads(tlh.list(), nWant, (address)mon);
        if (wantList->length() < nWant) {
          // robustness: the pending list has gotten smaller
          nWant = wantList->length();
        }

`Threads::get_pending_threads()` only returns threads where the
`current_pending_monitor` field is set for the specific monitor. That
happens only on contended enter and does not happen on contended
re-enter so this logic will already strip out any threads in `wait()` that
have not been notified and have not had their wait timers expire.
It will also strip out any waiters that have been notified or had
their wait timeouts expire.

This means even if we fix the reenter code to increment the contentions
field, this logic will reduce that `nWant` value. Of course, the way around
that is to also update the reenter code to properly set the `current_pending_monitor`
field and then the reentering threads won't be filtered out...

src/hotspot/share/prims/jvmtiEnvBase.cpp line 1560:

> 1558:     // Adjust count. nWant and nWait count values may be less than original.
> 1559:     ret.waiter_count = nWant;
> 1560:     ret.notify_waiter_count = nWait;

This old logic:
```    ret.waiter_count = nWant + nWait;```
over counts because it also includes threads in wait() that have not yet
been notified and the wait timeout has not expired. However, including
nWait is correct for the situation when all of the waiting threads have
been notified or their wait timeouts have expired.

If we have fixed the increment of contentions like the comment above
mentions, then `nWant` will properly reflect the semantics that I think
we're talking about.

When we're gathering up the entries for `waiters` above, we traverse
the list of waiters and we reduce the `nWait` when the list is shorter
than what we expected earlier. See L1540 -> L1544.

test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage001/objmonusage001.cpp line 95:

> 93: 
> 94: JNIEXPORT void JNICALL
> 95: Java_nsk_jvmti_GetObjectMonitorUsage_objmonusage001_check(JNIEnv *env,

I would have expected a modification to an objmonusage001.java file to update
the parameters to that test's `check()` function.

test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage001/objmonusage001.cpp line 161:

> 159: 
> 160:     if (inf.notify_waiter_count != notifyWaiterCount) {
> 161:         printf("(%d) waiter_count expected: %d, actually: %d\n",

nit typo: s/waiter_count/notify_waiter_count/

test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage003/objmonusage003.cpp line 150:

> 148: 
> 149:     if (inf.notify_waiter_count != notifyWaiterCount) {
> 150:         printf("(%d) waiter_count expected: %d, actually: %d\n",

nit typo: s/waiter_count/notify_waiter_count/

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

Changes requested by dcubed (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17680#pullrequestreview-1868875636
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1482144591
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1482180688
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1482155914
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1482189539
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1482185062
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1482185460

From dholmes at openjdk.org  Thu Feb  8 06:27:55 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 8 Feb 2024 06:27:55 GMT
Subject: RFR: 8320302: compiler/arguments/TestC1Globals.java hits SIGSEGV
 in ContinuationEntry::set_enter_code [v3]
In-Reply-To: <mYespY0oqvVFcx468YZJ80YqCSnEuk3FAz-W839Q4qM=.df0dcd66-543e-4039-bc24-6e809cf4b381@github.com>
References: <1Cm1SGGaZsYxM-RfPNDeAvnGijQ-taVe438SS6bZ3YI=.d64abde2-f9a0-4589-ab40-eba7c3c02992@github.com>
 <9mMLOqVHnFrYcKY5FLgIwd_j9RQtk68s9vdqaABGt_o=.bd743e24-484e-4120-9be3-a81f7022d332@github.com>
 <6eYoo4WQi_LO5YFtxZQbpxFeNxQFnpTjgfIvyPukWNA=.1448ac51-5e4a-43f3-ae17-aa5eeeee0538@github.com>
 <mYespY0oqvVFcx468YZJ80YqCSnEuk3FAz-W839Q4qM=.df0dcd66-543e-4039-bc24-6e809cf4b381@github.com>
Message-ID: <daJ-h7P1tSdc_sU9-27BWIMwIo066F_UNvx6j-sUyoI=.b331badc-f0bb-49a6-af8a-a19745c96034@github.com>

On Tue, 6 Feb 2024 20:11:55 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp line 1747:
>> 
>>> 1745:                                               oop_maps,
>>> 1746:                                               exception_offset);
>>> 1747:     if (nm == nullptr) vm_exit_during_initialization("Initial size of CodeCache is too small");
>> 
>> IIUC `AdapterHandlerLibrary::create_native_wrapper`  is the only caller of `generate_native_wrapper` so it is only called during VM init now. But not sure it wouldn't be better/cleaner to simply return nullptr here and have `AdapterHandlerLibrary::create_native_wrapper` do the `vm_exit_during_initialization`?
>
> We could do that too. We have to check for nullptr && method->is_continuation_native_intrinsic() since AdapterHandlerLibrary::create_native_wrapper() itself is called from 2 other places which should not fail with vm_exit_during_initialization() if creation of the native nmethod failed. I don't have a preference, both ways are fine with me.

Sorry for the delay. I've been looking at the proposed initialization sequence:

Threads::create_vm
  initialize_class(vmSymbols::jdk_internal_vm_Continuation(), CHECK
    // causes linking of Continuation
    InstanceKlass::link_class_impl(TRAPS)
      InstanceKlass::link_methods(TRAPS)
        Method::link_method(mh, TRAPS)
          AdapterHandlerLibrary::create_native_wrapper
            SharedRuntime::generate_native_wrapper

and it seems to me that if `generate_native_wrapper` returns null then `create_native_wrapper` can check for that and also return early. Then `link_method` can do what other callers of `create_native_wrapper` do and simply check the resulting method and throw an exception:

if (!h_method->has_compiled_code()) {
  // throw OOME
}

that exception will propagate up and terminate the VM the same as any other exception during vm init would.

What do you think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17455#discussion_r1482462165

From dholmes at openjdk.org  Thu Feb  8 06:42:00 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 8 Feb 2024 06:42:00 GMT
Subject: RFR: 8320750: Allow a testcase to run with multiple -Xlog [v2]
In-Reply-To: <XvF3_iQLanMjMxlu_bS1vcMgYSXYcbFX_mAClOvv6tM=.08c68c1b-3654-467a-8c4c-3ba09e6f6832@github.com>
References: <LzqG8tmHZgoSqxPjEnULam9uGycRNpdBuPoUjXAdze0=.df98f685-7800-475e-ad3e-7d555c1470ea@github.com>
 <XvF3_iQLanMjMxlu_bS1vcMgYSXYcbFX_mAClOvv6tM=.08c68c1b-3654-467a-8c4c-3ba09e6f6832@github.com>
Message-ID: <SYtZqhKzEuy-hKS_6i10NVVnDgUoW8MweRYxZmu8ySA=.8347cb81-5c7f-4449-b573-3bfdaf144ada@github.com>

On Wed, 7 Feb 2024 20:37:15 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Running a testcase with muliple -Xlog crashes JTREG test cases. This is because `Collector.toMap` is not given a merge strategy.
>> 
>> When the same argument is passed multiple times, I have added a merge strategy to use the latter value. This is similar to how it is implemented for `vm.opt.*` in JTREG.
>> 
>> If the flag tested is `-Xlog`, replace the value part with a dummy value "NONEMPTY_TEST_SENTINEL". This is because in the case of multiple `-Xlog` all values are used, and JTREG does not give a satisfactory way to represent them. This dummy value should make it hard to try to `@require` on specific values by mistake.
>> 
>> Tested with:
>> 
>>  @requires vm.opt.x.Xlog == "NONEMPTY_TEST_SENTINEL"
>>  @requires vm.opt.x.Xlog == "NONEMPTY_TEST_SENTINELXXX"
>>  @requires vm.opt.x.Xms == "3g"
>> 
>> and
>> 
>> JAVA_OPTIONS=-Xms3g -Xms4g
>> JAVA_OPTIONS=-Xms4g -Xms3g
>> JAVA_OPTIONS=-Xlog:gc* -Xlog:gc*
>> ``` 
>> 
>> Running tier1
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added test, reworked code structure after suggestions from Stefan and Johan

test/jtreg-ext/requires/VMProps.java line 727:

> 725:      * Split an -Xflag string into a name part (without leading dash)
> 726:        and a value part ("true" if no value was given)
> 727:      */

May I suggest sparing the reader some effort and adding a couple of examples e.g.:

-Xmx4g => (Xmx, 4g)
-Xcheck:jni => (Xcheck, :jni)
-Xbootclasspath/a:<path> => (Xbootclasspath, /a:<path>)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16824#discussion_r1482470909

From dholmes at openjdk.org  Thu Feb  8 07:07:55 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 8 Feb 2024 07:07:55 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v3]
In-Reply-To: <bIMfwFEuiZ1CbUtq3NzEeNuW72i4jAqAHGJKMb_VZdg=.4e228b57-af29-4a78-9534-bae11fa6bb2d@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <bIMfwFEuiZ1CbUtq3NzEeNuW72i4jAqAHGJKMb_VZdg=.4e228b57-af29-4a78-9534-bae11fa6bb2d@github.com>
Message-ID: <G0pqYyJ_-DfljxP29xptnPh5n76msoUpITc8kXDPrNo=.72e64c5e-2200-4bc7-8e67-632c318f7d25@github.com>

On Wed, 7 Feb 2024 07:02:11 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
>> The function returns the following structure:
>> 
>> 
>> typedef struct {
>>     jthread owner;
>>     jint entry_count;
>>     jint waiter_count;
>>     jthread* waiters;
>>     jint notify_waiter_count;
>>     jthread* notify_waiters;
>> } jvmtiMonitorUsage;
>> 
>> 
>> The following four fields are defined this way:
>> 
>> waiter_count  [jint] The number of threads waiting to own this monitor
>> waiters  [jthread*] The waiter_count waiting threads
>> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
>> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
>> 
>> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
>> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
>> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
>> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
>> This update makes it right.
>> 
>> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
>> 
>> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
>> 
>>   jvmti/GetObjectMonitorUsage/objmonusage001
>>   jvmti/GetObjectMonitorUsage/objmonusage003
>> 
>> 
>> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
>> 
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
>> 
>> 
>> 
>> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository.
>> 
>> Also, please see and review the related CSR:
>>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
>> 
>> The Release-Note is:
>> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage
>>  
>> Testing:
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn 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
>  - review: thread in notify waiter list can't be BLOCKED
>  - 8324677: Specification clarification needed for JVM TI GetObjectMonitorUsage

Based on Dan's analysis I would have to go back and redo the complete analysis for myself. :( I think the only way to make sense of this is to actually set up scenarios where we have different threads contending on entry, different threads waiting and different threads re-entering after being notified, and see what values actually get returned in each case.

I think the `pending_current_monitor` issue may be a distinct/different issue. I can easily imagine that this was overlooked when we introduced the "wait morphing" rather than have the notified/timed-out/interrupted waiters actually place themselves on the entry queue.

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

PR Comment: https://git.openjdk.org/jdk/pull/17680#issuecomment-1933469232

From thartmann at openjdk.org  Thu Feb  8 07:26:59 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 8 Feb 2024 07:26:59 GMT
Subject: RFR: 8324186: Use "dmb.ishst+dmb.ishld" for release barrier [v4]
In-Reply-To: <mEDRJOCCKOBNaDk_m6yjFElCqSV7PE9934eGIjTF8po=.f265f265-ed89-4468-962c-807a3bef5e45@github.com>
References: <XZrDipOH9HF2OKvIextkB_Mcoi5Qb5w5OAn-FvnGvCY=.81067554-26eb-4876-ad37-e5a42596cdb1@github.com>
 <LrOAOXuZOtletxXe3sELJVfsyQYhF5MLImEEi3NEIe8=.47fda591-c73e-4aeb-b465-6dca323f6717@github.com>
 <iLpgzQhQj69WOZZYpd-t9ku2SRk5_7mFauLboNUMhYA=.f95ecccd-e839-407b-94d1-60b13a6da3f0@github.com>
 <ya_gz2XNHlXoxynYl5E99U9J3frKK_RSJifBvBy0ZpI=.6870c267-e5e2-4691-9bbb-8e41367eb301@github.com>
 <NdP71n-TYPswKhGANbbKw2_uyujL1OFDP8L1UFswzME=.690dc936-0136-4dd2-8f2a-5c05e1748020@github.com>
 <V3n9i9msuDBvaBDCIsv00Z36LikHCIIB3SbjB5Nt0NA=.dd803f90-4ede-43f1-9b62-9f52f7fb9d0e@github.com>
 <qPKqwnrRsp-ByIC3aFs1WtDskO9Ri6TeNV_9KtQPJvM=.6cf5ea4b-d41c-4b3f-b24f-92c57f6d7705@github.com>
 <mEDRJOCCKOBNaDk_m6yjFElCqSV7PE9934eGIjTF8po=.f265f265-ed89-4468-962c-807a3bef5e45@github.com>
Message-ID: <po4QfOcUfArCyv_LjWBTasTPiZ-1q_QbUtR4Y6uvj0M=.6e6b2231-2084-4b92-afff-1d81360ffe04@github.com>

On Mon, 29 Jan 2024 02:11:43 GMT, kuaiwei <duke at openjdk.org> wrote:

>>> > I wonder if this was tested on other vendors' hardware? I witnessed some negative impact at least on HiSilicon TSV110 running the same JMH. So I guess it might be safer to go as a vendor-specific change.
>>> 
>>> I tried a number of different machines and saw regressions only on Kunpeng-920 (same CPU?) and A57 which is quite niche at this point.
>> 
>> Right, so it's probably a low-end, mostly-in-order thing. That makes sense because we're trading a weaker barrier for more instructions, and perhaps some cores implement barriers in a crude one-size-fits-all way.
>
> @theRealAph @RealFYang Could you help to sponsor it? Thanks

This introduced a performance regression, see [JDK-8325449](https://bugs.openjdk.org/browse/JDK-8325449) and [JDK-8325269](https://bugs.openjdk.org/browse/JDK-8325269). @kuaiwei, could you please have a look?

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

PR Comment: https://git.openjdk.org/jdk/pull/17511#issuecomment-1933492323

From thartmann at openjdk.org  Thu Feb  8 09:00:55 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 8 Feb 2024 09:00:55 GMT
Subject: RFR: 8324824: AArch64: Detect Ampere-1B core and update default
 options for Ampere CPUs
In-Reply-To: <N9ZCzxRwamt4YTT5wNJottgQ7FYJX4SQrrFxv11Ramg=.4881b622-6d73-4c12-beb3-d65ce465f076@github.com>
References: <N9ZCzxRwamt4YTT5wNJottgQ7FYJX4SQrrFxv11Ramg=.4881b622-6d73-4c12-beb3-d65ce465f076@github.com>
Message-ID: <YFiApTWjgrmaReoL72N5UwzyyOEjDSD48qaJluj7siA=.adef8cdd-9e28-4060-89b3-c8010792b179@github.com>

On Tue, 6 Feb 2024 07:13:22 GMT, Patrick Zhang <qpzhang at openjdk.org> wrote:

> Added CPU detection for Ampere-1B, and updated the default options for AmpereOne, Ampere-1A/1B to have `-XX:+UseSIMDForMemoryOps` and `-XX:OnSpinWaitInst=isb -XX:OnSpinWaitInstCount=2`.
> 
> Tests done:
> 1. GitHub Actions (GHA) sanity tests: https://github.com/cnqpzhang/jdk/actions/runs/7786881426
> 2. OpenJDK bundled JMH, `make run-test TEST="jtreg:hotspot/jtreg/compiler/onSpinWait*"` , `make run-test TEST="micro:ThreadOnSpinWait*"`, no issue found, and `ThreadOnSpinWaitProducerConsumer.trial` showed ~3x better scores (us/op).
> 3. Jtreg tier1/tier2 sanity check on AmpereOne AArch64 platforms, Ampere-1A systems as well, no new issues found.
> 
> Signed-off-by: Patrick Zhang [patrick at os.amperecomputing.com](mailto:patrick at os.amperecomputing.com)

Marked as reviewed by thartmann (Reviewer).

All tests passed.

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

PR Review: https://git.openjdk.org/jdk/pull/17722#pullrequestreview-1869587235
PR Comment: https://git.openjdk.org/jdk/pull/17722#issuecomment-1933622819

From aboldtch at openjdk.org  Thu Feb  8 09:04:06 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 8 Feb 2024 09:04:06 GMT
Subject: RFR: 8325471: CHeapBitMap(MEMFLAGS flags) constructor misleading use
 of super-constructor
Message-ID: <HFv_Fx_7ml0p-FbO1TFm0FVE1TX-XstivvIF8Z8kADM=.8aea76d5-c511-4dd6-ab40-2a4e3a7efe9c@github.com>

The `explicit CHeapBitMap(MEMFLAGS flags)` calls the `GrowableBitMap(bm_word_t* map, idx_t size_in_bits)` super-constructor with `GrowableBitMap(0, false)`. This works because `0` gets converted to `nullptr` and `false` gets converted to `0`. However this seems to have be a miss in the most recent refactoring and is misleading.

`explicit CHeapBitMap(MEMFLAGS flags)` should use `GrowableBitMap()` directly which creates an empty (uninitialised) bitmap.

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

Commit messages:
 - 8325471: CHeapBitMap(MEMFLAGS flags) constructor misleading use of super-constructor

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

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

From stefank at openjdk.org  Thu Feb  8 09:06:58 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 8 Feb 2024 09:06:58 GMT
Subject: RFR: 8320750: Allow a testcase to run with multiple -Xlog [v2]
In-Reply-To: <XvF3_iQLanMjMxlu_bS1vcMgYSXYcbFX_mAClOvv6tM=.08c68c1b-3654-467a-8c4c-3ba09e6f6832@github.com>
References: <LzqG8tmHZgoSqxPjEnULam9uGycRNpdBuPoUjXAdze0=.df98f685-7800-475e-ad3e-7d555c1470ea@github.com>
 <XvF3_iQLanMjMxlu_bS1vcMgYSXYcbFX_mAClOvv6tM=.08c68c1b-3654-467a-8c4c-3ba09e6f6832@github.com>
Message-ID: <MOBf6oqCvgJxUPAL8rTpwlwjP4-ypivX_cQYaTLtYYw=.d8e440e0-5084-497d-b0ad-4f8c87bf350b@github.com>

On Wed, 7 Feb 2024 20:37:15 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Running a testcase with muliple -Xlog crashes JTREG test cases. This is because `Collector.toMap` is not given a merge strategy.
>> 
>> When the same argument is passed multiple times, I have added a merge strategy to use the latter value. This is similar to how it is implemented for `vm.opt.*` in JTREG.
>> 
>> If the flag tested is `-Xlog`, replace the value part with a dummy value "NONEMPTY_TEST_SENTINEL". This is because in the case of multiple `-Xlog` all values are used, and JTREG does not give a satisfactory way to represent them. This dummy value should make it hard to try to `@require` on specific values by mistake.
>> 
>> Tested with:
>> 
>>  @requires vm.opt.x.Xlog == "NONEMPTY_TEST_SENTINEL"
>>  @requires vm.opt.x.Xlog == "NONEMPTY_TEST_SENTINELXXX"
>>  @requires vm.opt.x.Xms == "3g"
>> 
>> and
>> 
>> JAVA_OPTIONS=-Xms3g -Xms4g
>> JAVA_OPTIONS=-Xms4g -Xms3g
>> JAVA_OPTIONS=-Xlog:gc* -Xlog:gc*
>> ``` 
>> 
>> Running tier1
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added test, reworked code structure after suggestions from Stefan and Johan

I find this version much easier to quickly read and understand. I've added a few suggestions that you consider, but only the comments around -Xbootclasspath/a is a blocker for integration.

test/jtreg-ext/requires/VMProps.java line 143:

> 141:         map.put("vm.flagless", this::isFlagless);
> 142:         map.put("jdk.foreign.linker", this::jdkForeignLinker);
> 143:         map.putAll(xFlags()); // -Xmx4g -> @requires vm.opt.x.Xmx == "4g" )

This has a slightly different style than the vmOptFinalFlags:

map.putAll(xFlags()); // -Xmx4g -> @requires vm.opt.x.Xmx == "4g" )

vs

vmOptFinalFlags(map);


It could be nice to unify the style so that we have:

vmOptXFlags(map);
vmOptFinalFlags(map);

test/jtreg-ext/requires/VMProps.java line 752:

> 750:      */
> 751:     private static boolean isXFlag(String flag) {
> 752:         return flag.startsWith("-X") && !flag.startsWith("-XX:") && !flag.equals("-X");

`-XX:` is not wrong, but I wonder if this could/should be `-XX` instead.

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

Changes requested by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16824#pullrequestreview-1869568027
PR Review Comment: https://git.openjdk.org/jdk/pull/16824#discussion_r1482622913
PR Review Comment: https://git.openjdk.org/jdk/pull/16824#discussion_r1482624108

From stefank at openjdk.org  Thu Feb  8 09:06:59 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 8 Feb 2024 09:06:59 GMT
Subject: RFR: 8320750: Allow a testcase to run with multiple -Xlog [v2]
In-Reply-To: <SYtZqhKzEuy-hKS_6i10NVVnDgUoW8MweRYxZmu8ySA=.8347cb81-5c7f-4449-b573-3bfdaf144ada@github.com>
References: <LzqG8tmHZgoSqxPjEnULam9uGycRNpdBuPoUjXAdze0=.df98f685-7800-475e-ad3e-7d555c1470ea@github.com>
 <XvF3_iQLanMjMxlu_bS1vcMgYSXYcbFX_mAClOvv6tM=.08c68c1b-3654-467a-8c4c-3ba09e6f6832@github.com>
 <SYtZqhKzEuy-hKS_6i10NVVnDgUoW8MweRYxZmu8ySA=.8347cb81-5c7f-4449-b573-3bfdaf144ada@github.com>
Message-ID: <DlPrubzyzxIb0QUAHPwZU0yaYGrP93czpJcAJ3cPgoI=.9eabd3f2-8ff8-4e11-96ad-3f98e8fa495c@github.com>

On Thu, 8 Feb 2024 06:39:33 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added test, reworked code structure after suggestions from Stefan and Johan
>
> test/jtreg-ext/requires/VMProps.java line 727:
> 
>> 725:      * Split an -Xflag string into a name part (without leading dash)
>> 726:        and a value part ("true" if no value was given)
>> 727:      */
> 
> May I suggest sparing the reader some effort and adding a couple of examples e.g.:
> 
> -Xmx4g => (Xmx, 4g)
> -Xcheck:jni => (Xcheck, :jni)
> -Xbootclasspath/a:<path> => (Xbootclasspath, /a:<path>)

The last example is interesting. Is it supposed to be:

-Xbootclasspath/a:<path> => (Xbootclasspath, /a:<path>

or should it be:

-Xbootclasspath/a:<path> => (Xbootclasspath/a, <path>)

I think it should be the latter and if that's the case then the regex should be updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16824#discussion_r1482609140

From stefank at openjdk.org  Thu Feb  8 09:13:56 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 8 Feb 2024 09:13:56 GMT
Subject: RFR: 8325471: CHeapBitMap(MEMFLAGS flags) constructor misleading
 use of super-constructor
In-Reply-To: <HFv_Fx_7ml0p-FbO1TFm0FVE1TX-XstivvIF8Z8kADM=.8aea76d5-c511-4dd6-ab40-2a4e3a7efe9c@github.com>
References: <HFv_Fx_7ml0p-FbO1TFm0FVE1TX-XstivvIF8Z8kADM=.8aea76d5-c511-4dd6-ab40-2a4e3a7efe9c@github.com>
Message-ID: <_W5Uatqrvi9nyS_1NZhal88lvGCVTJbICiMgSQ_X9vg=.bf661e4b-fbcb-42fc-99d0-68a89b1c21ca@github.com>

On Thu, 8 Feb 2024 09:00:35 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> The `explicit CHeapBitMap(MEMFLAGS flags)` calls the `GrowableBitMap(bm_word_t* map, idx_t size_in_bits)` super-constructor with `GrowableBitMap(0, false)`. This works because `0` gets converted to `nullptr` and `false` gets converted to `0`. However this seems to have be a miss in the most recent refactoring and is misleading.
> 
> `explicit CHeapBitMap(MEMFLAGS flags)` should use `GrowableBitMap()` directly which creates an empty (uninitialised) bitmap.

Looks good.

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

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17768#pullrequestreview-1869610273

From dlong at openjdk.org  Thu Feb  8 09:21:00 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 8 Feb 2024 09:21:00 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v6]
In-Reply-To: <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
Message-ID: <ntKnOaWbggDKycTJ6tC0zucfA1eEokg3OsIGh-Z0GkQ=.76bf6dc3-552c-4833-b04a-89ef34746a51@github.com>

On Tue, 30 Jan 2024 09:08:01 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> ICStubs solve an atomicity problem when setting both the destination and data of an inline cache. Unfortunately, it also leads to occasional safepoint carpets when multiple threads need to ICRefill the stubs at the same time, and spurious GuaranteedSafepointInterval "Cleanup" safepoints every second. This patch changes inline caches to not change the data part at all during the nmethod life cycle, hence removing the need for ICStubs.
>> 
>> The new scheme is less stateful. Instead of adding and removing callsite metadata back and forth when transitioning inline cache states, it installs all state any shape of call will ever need at resolution time in a struct that I call CompiledICData. This reduces inline cache state changes to simply changing the destination of the call, and it doesn't really matter what state transitions to what other state.
>> 
>> With this patch, we get rid of ICStub and ICBuffer classes and the related ICRefill and almost all Cleanup safepoints in practice. It also makes the inline cache code much simpler.
>> 
>> I have tested the changes from tier1-7, and run through full aurora performance tests.
>
> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ARM32 fixes

src/hotspot/cpu/aarch64/aarch64.ad line 2224:

> 2222:   // This is the unverified entry point.
> 2223:   C2_MacroAssembler _masm(&cbuf);
> 2224:   __ ic_check(CodeEntryAlignment);

I'm not sure we want to increase the alignement to CodeEntryAlignment here.  I believe C2 already aligns the root block to CodeEntryAlignment.  @theRealAph, what do you think?

src/hotspot/share/opto/output.cpp line 3416:

> 3414:     } else {
> 3415:       if (!target->is_static()) {
> 3416:         _code_offsets.set_value(CodeOffsets::Entry, _first_block_size - MacroAssembler::ic_check_size());

This looks tricky. I think it means CodeOffsets::Entry starts after the alignment padding NOPs. If that's true then the `ic_check` functions could use a comment explaining that alignment needs to come first, not last. A comment here wouldn't hurt either.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1482646992
PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1482643531

From dlong at openjdk.org  Thu Feb  8 09:23:57 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 8 Feb 2024 09:23:57 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v6]
In-Reply-To: <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
Message-ID: <D1Y_8WDs5xHoA0Hq2BlErSMMHpkhT0B_G7CiE2Oxgkg=.c28b09cb-5a45-4729-98d5-b9101856be4f@github.com>

On Tue, 30 Jan 2024 09:08:01 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> ICStubs solve an atomicity problem when setting both the destination and data of an inline cache. Unfortunately, it also leads to occasional safepoint carpets when multiple threads need to ICRefill the stubs at the same time, and spurious GuaranteedSafepointInterval "Cleanup" safepoints every second. This patch changes inline caches to not change the data part at all during the nmethod life cycle, hence removing the need for ICStubs.
>> 
>> The new scheme is less stateful. Instead of adding and removing callsite metadata back and forth when transitioning inline cache states, it installs all state any shape of call will ever need at resolution time in a struct that I call CompiledICData. This reduces inline cache state changes to simply changing the destination of the call, and it doesn't really matter what state transitions to what other state.
>> 
>> With this patch, we get rid of ICStub and ICBuffer classes and the related ICRefill and almost all Cleanup safepoints in practice. It also makes the inline cache code much simpler.
>> 
>> I have tested the changes from tier1-7, and run through full aurora performance tests.
>
> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ARM32 fixes

src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp line 295:

> 293: // inline cache check; done before the frame is built.
> 294: int LIR_Assembler::check_icache() {
> 295:   return __ ic_check(CodeEntryAlignment);

Do we really want to remove the optimization that skips alignment for small methods?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1482653192

From dlong at openjdk.org  Thu Feb  8 09:28:01 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 8 Feb 2024 09:28:01 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v6]
In-Reply-To: <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
Message-ID: <OgOxE-XTO2K2bF8Form29cAxKWcv8_8nGlpUYMA2Hp4=.194c9f44-4249-4a8a-bc8f-a54908694993@github.com>

On Tue, 30 Jan 2024 09:08:01 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> ICStubs solve an atomicity problem when setting both the destination and data of an inline cache. Unfortunately, it also leads to occasional safepoint carpets when multiple threads need to ICRefill the stubs at the same time, and spurious GuaranteedSafepointInterval "Cleanup" safepoints every second. This patch changes inline caches to not change the data part at all during the nmethod life cycle, hence removing the need for ICStubs.
>> 
>> The new scheme is less stateful. Instead of adding and removing callsite metadata back and forth when transitioning inline cache states, it installs all state any shape of call will ever need at resolution time in a struct that I call CompiledICData. This reduces inline cache state changes to simply changing the destination of the call, and it doesn't really matter what state transitions to what other state.
>> 
>> With this patch, we get rid of ICStub and ICBuffer classes and the related ICRefill and almost all Cleanup safepoints in practice. It also makes the inline cache code much simpler.
>> 
>> I have tested the changes from tier1-7, and run through full aurora performance tests.
>
> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ARM32 fixes

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 1016:

> 1014:   Register tmp1 = rscratch1;
> 1015:   Register tmp2 = r10;
> 1016: 

It would be nice if we could still call `verify_oop(receiver)` here, but I see that would complicate `ic_check_size()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1482659111

From tschatzl at openjdk.org  Thu Feb  8 09:41:53 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 8 Feb 2024 09:41:53 GMT
Subject: RFR: 8325471: CHeapBitMap(MEMFLAGS flags) constructor misleading
 use of super-constructor
In-Reply-To: <HFv_Fx_7ml0p-FbO1TFm0FVE1TX-XstivvIF8Z8kADM=.8aea76d5-c511-4dd6-ab40-2a4e3a7efe9c@github.com>
References: <HFv_Fx_7ml0p-FbO1TFm0FVE1TX-XstivvIF8Z8kADM=.8aea76d5-c511-4dd6-ab40-2a4e3a7efe9c@github.com>
Message-ID: <sWgWBi1pSoERzyxMuEhEiN1Qnb6oYOKTCcEaweG4GhY=.0f129a73-2759-4b32-9d99-fefbdde0eb4e@github.com>

On Thu, 8 Feb 2024 09:00:35 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> The `explicit CHeapBitMap(MEMFLAGS flags)` calls the `GrowableBitMap(bm_word_t* map, idx_t size_in_bits)` super-constructor with `GrowableBitMap(0, false)`. This works because `0` gets converted to `nullptr` and `false` gets converted to `0`. However this seems to have be a miss in the most recent refactoring and is misleading.
> 
> `explicit CHeapBitMap(MEMFLAGS flags)` should use `GrowableBitMap()` directly which creates an empty (uninitialised) bitmap.

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17768#pullrequestreview-1869672797

From sspitsyn at openjdk.org  Thu Feb  8 09:54:56 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 8 Feb 2024 09:54:56 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v3]
In-Reply-To: <tpoboI2WVbmvE1sR9D-7qsm_Mh8m01-Uwt8tA_pNI5g=.c8219d3c-3acd-4a20-9091-5e9cc911617b@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <bIMfwFEuiZ1CbUtq3NzEeNuW72i4jAqAHGJKMb_VZdg=.4e228b57-af29-4a78-9534-bae11fa6bb2d@github.com>
 <tpoboI2WVbmvE1sR9D-7qsm_Mh8m01-Uwt8tA_pNI5g=.c8219d3c-3acd-4a20-9091-5e9cc911617b@github.com>
Message-ID: <7qxBGiPcbwyhFMbHpQOmRsgmg1qJFfL875Yyax6OZtM=.962c9c81-b613-49dd-a6c3-92efb256f0e4@github.com>

On Wed, 7 Feb 2024 21:56:01 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Serguei Spitsyn 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
>>  - review: thread in notify waiter list can't be BLOCKED
>>  - 8324677: Specification clarification needed for JVM TI GetObjectMonitorUsage
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1489:
> 
>> 1487:     nWait = mon->waiters();     // # of threads in Object.wait()
>> 1488:     ret.waiter_count = nWant;
>> 1489:     ret.notify_waiter_count = nWait;
> 
> Please note that the comment on L1487 is accurate. The `waiters` count is
> incremented just before the thread that has called `wait()` drops the monitor
> and that increased count remains in effect until after the thread has reentered
> the monitor after being notified or the wait timeout has expired.
> 
> The `contentions` count is not incremented in the re-entry path so a thread
> that is in `wait()` that has been notified or the wait timeout has expired is not
> counted as a contending thread.
> 
> So if we really want the `waiter_count` field to include threads that have been
> notified or the wait timeout has expired, then we have to add some logic to
> carefully increment the `contentions` count.
> 
> This old logic:
>  ```    ret.waiter_count = nWant + nWait;```
> over counts because it also includes threads in `wait()` that have not yet
> been notified and the wait timeout has not expired. However, including
> `nWait` is correct for the situation when all of the waiting threads have
> been notified or their wait timeouts have expired.
> 
> This also means that `nWait` and the `ret.notify_waiter_count` value are
> over counting waiters because that value will include threads that (have
> been notified or the wait timeout has expired) AND have not reentered
> the monitor. I _think_ we're saying that is NOT what we want. However,
> I _think_ that the `nWait` value is fixed below when we're gathering up
> the list of waiters.

Thank you for reviewing this, Dan!
> The contentions count is not incremented in the re-entry path so a thread
that is in wait() that has been notified or the wait timeout has expired is not
counted as a contending thread.

Right. I've discovered this after reading your first comment above this comment. :)
I agree with the whole comment. I understand this over counting now. It is a good catch! Will work on fixing this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1482696229

From sspitsyn at openjdk.org  Thu Feb  8 09:58:56 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 8 Feb 2024 09:58:56 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v3]
In-Reply-To: <tpoboI2WVbmvE1sR9D-7qsm_Mh8m01-Uwt8tA_pNI5g=.c8219d3c-3acd-4a20-9091-5e9cc911617b@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <bIMfwFEuiZ1CbUtq3NzEeNuW72i4jAqAHGJKMb_VZdg=.4e228b57-af29-4a78-9534-bae11fa6bb2d@github.com>
 <tpoboI2WVbmvE1sR9D-7qsm_Mh8m01-Uwt8tA_pNI5g=.c8219d3c-3acd-4a20-9091-5e9cc911617b@github.com>
Message-ID: <VUgSWKzNBrSB5opqUdeqatsp1ExGq1k4qw8y1Xpagss=.3836aee9-2a00-4a1b-b00e-bb2dd271da1b@github.com>

On Wed, 7 Feb 2024 22:43:36 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Serguei Spitsyn 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
>>  - review: thread in notify waiter list can't be BLOCKED
>>  - 8324677: Specification clarification needed for JVM TI GetObjectMonitorUsage
>
> test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage001/objmonusage001.cpp line 161:
> 
>> 159: 
>> 160:     if (inf.notify_waiter_count != notifyWaiterCount) {
>> 161:         printf("(%d) waiter_count expected: %d, actually: %d\n",
> 
> nit typo: s/waiter_count/notify_waiter_count/

Nice catch, thanks!

> test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage003/objmonusage003.cpp line 150:
> 
>> 148: 
>> 149:     if (inf.notify_waiter_count != notifyWaiterCount) {
>> 150:         printf("(%d) waiter_count expected: %d, actually: %d\n",
> 
> nit typo: s/waiter_count/notify_waiter_count/

Nice catch, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1482702600
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1482702844

From sroy at openjdk.org  Thu Feb  8 09:59:11 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Thu, 8 Feb 2024 09:59:11 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v16]
In-Reply-To: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
Message-ID: <LAum4KZc3Nu2FbHyQ9g3CcPR9GjLN4Uj421kec_t2iI=.ba34a1bd-00f8-4992-a5dd-40682867e93f@github.com>

> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am.
> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX.
> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails.

Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:

  Free the buffer

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16604/files
  - new: https://git.openjdk.org/jdk/pull/16604/files/14e0ed39..0503ed8f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=14-15

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

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

From jkern at openjdk.org  Thu Feb  8 10:03:59 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Thu, 8 Feb 2024 10:03:59 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v16]
In-Reply-To: <LAum4KZc3Nu2FbHyQ9g3CcPR9GjLN4Uj421kec_t2iI=.ba34a1bd-00f8-4992-a5dd-40682867e93f@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <LAum4KZc3Nu2FbHyQ9g3CcPR9GjLN4Uj421kec_t2iI=.ba34a1bd-00f8-4992-a5dd-40682867e93f@github.com>
Message-ID: <gZXke41VpWpOTV7vqaFnh7txt3GOXr6_J_JGqE2phFE=.247bc2cc-c891-4e3c-8060-b3c1e21c7423@github.com>

On Thu, 8 Feb 2024 09:59:11 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am.
>> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX.
>> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails.
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Free the buffer

src/hotspot/os/aix/os_aix.cpp line 1114:

> 1112: 
> 1113:   log_info(os)("attempting shared library load of %s", filename);
> 1114:   printf("Loading the filename %s\n",filename);

Is this just accidentally remaining debug code or do you want to protocol each dlopen on stdout?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1482709076

From lkorinth at openjdk.org  Thu Feb  8 10:07:02 2024
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 8 Feb 2024 10:07:02 GMT
Subject: RFR: 8320750: Allow a testcase to run with multiple -Xlog [v2]
In-Reply-To: <MOBf6oqCvgJxUPAL8rTpwlwjP4-ypivX_cQYaTLtYYw=.d8e440e0-5084-497d-b0ad-4f8c87bf350b@github.com>
References: <LzqG8tmHZgoSqxPjEnULam9uGycRNpdBuPoUjXAdze0=.df98f685-7800-475e-ad3e-7d555c1470ea@github.com>
 <XvF3_iQLanMjMxlu_bS1vcMgYSXYcbFX_mAClOvv6tM=.08c68c1b-3654-467a-8c4c-3ba09e6f6832@github.com>
 <MOBf6oqCvgJxUPAL8rTpwlwjP4-ypivX_cQYaTLtYYw=.d8e440e0-5084-497d-b0ad-4f8c87bf350b@github.com>
Message-ID: <mV2HqnZOxotnBNNvHt0pqooVGpeb9tMmHJjPACdASbQ=.9e46e0be-bd21-4425-a6ed-89cdbe38ae12@github.com>

On Thu, 8 Feb 2024 08:59:25 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added test, reworked code structure after suggestions from Stefan and Johan
>
> test/jtreg-ext/requires/VMProps.java line 143:
> 
>> 141:         map.put("vm.flagless", this::isFlagless);
>> 142:         map.put("jdk.foreign.linker", this::jdkForeignLinker);
>> 143:         map.putAll(xFlags()); // -Xmx4g -> @requires vm.opt.x.Xmx == "4g" )
> 
> This has a slightly different style than the vmOptFinalFlags:
> 
> map.putAll(xFlags()); // -Xmx4g -> @requires vm.opt.x.Xmx == "4g" )
> 
> vs
> 
> vmOptFinalFlags(map);
> 
> 
> It could be nice to unify the style so that we have:
> 
> vmOptXFlags(map);
> vmOptFinalFlags(map);

In this case I much prefer my functional style of returning a map value instead of mutating a map argument. I feel I will never finish this if I follow the rabbit hole of updating `vmOptFinalFlags(map)`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16824#discussion_r1482712044

From sspitsyn at openjdk.org  Thu Feb  8 10:08:03 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 8 Feb 2024 10:08:03 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v3]
In-Reply-To: <tpoboI2WVbmvE1sR9D-7qsm_Mh8m01-Uwt8tA_pNI5g=.c8219d3c-3acd-4a20-9091-5e9cc911617b@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <bIMfwFEuiZ1CbUtq3NzEeNuW72i4jAqAHGJKMb_VZdg=.4e228b57-af29-4a78-9534-bae11fa6bb2d@github.com>
 <tpoboI2WVbmvE1sR9D-7qsm_Mh8m01-Uwt8tA_pNI5g=.c8219d3c-3acd-4a20-9091-5e9cc911617b@github.com>
Message-ID: <UOQdfcbEVxBulzsfOtPiQyj-DCtV5O8CTdvREAdfcCY=.fa84cee7-abd4-4aa2-a4a0-a4d4372153f8@github.com>

On Wed, 7 Feb 2024 22:49:31 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Serguei Spitsyn 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
>>  - review: thread in notify waiter list can't be BLOCKED
>>  - 8324677: Specification clarification needed for JVM TI GetObjectMonitorUsage
>
> test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage001/objmonusage001.cpp line 95:
> 
>> 93: 
>> 94: JNIEXPORT void JNICALL
>> 95: Java_nsk_jvmti_GetObjectMonitorUsage_objmonusage001_check(JNIEnv *env,
> 
> I would have expected a modification to an objmonusage001.java file to update
> the parameters to that test's `check()` function.

The parameters of the `check()` method are named short. It is why I decided to skip this update.
Now, I decided to rename parameters to keep them consistent with the other test `objmonusage003`.
So, it has been fixed now, thank you for the suggestion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1482714109

From lkorinth at openjdk.org  Thu Feb  8 10:09:57 2024
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 8 Feb 2024 10:09:57 GMT
Subject: RFR: 8320750: Allow a testcase to run with multiple -Xlog [v2]
In-Reply-To: <MOBf6oqCvgJxUPAL8rTpwlwjP4-ypivX_cQYaTLtYYw=.d8e440e0-5084-497d-b0ad-4f8c87bf350b@github.com>
References: <LzqG8tmHZgoSqxPjEnULam9uGycRNpdBuPoUjXAdze0=.df98f685-7800-475e-ad3e-7d555c1470ea@github.com>
 <XvF3_iQLanMjMxlu_bS1vcMgYSXYcbFX_mAClOvv6tM=.08c68c1b-3654-467a-8c4c-3ba09e6f6832@github.com>
 <MOBf6oqCvgJxUPAL8rTpwlwjP4-ypivX_cQYaTLtYYw=.d8e440e0-5084-497d-b0ad-4f8c87bf350b@github.com>
Message-ID: <OrX97tXd_sl0NSVTRe5X7kQPTBqDZkeEwXYtlbve59Y=.6921adb6-9fbc-4ee3-930a-a99cf5925f84@github.com>

On Thu, 8 Feb 2024 09:00:22 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added test, reworked code structure after suggestions from Stefan and Johan
>
> test/jtreg-ext/requires/VMProps.java line 752:
> 
>> 750:      */
>> 751:     private static boolean isXFlag(String flag) {
>> 752:         return flag.startsWith("-X") && !flag.startsWith("-XX:") && !flag.equals("-X");
> 
> `-XX:` is not wrong, but I wonder if this could/should be `-XX` instead.

Arguably `-XXSomeFlag` is a an x flag and not an xx flag, but I will change it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16824#discussion_r1482716346

From lkorinth at openjdk.org  Thu Feb  8 10:15:24 2024
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 8 Feb 2024 10:15:24 GMT
Subject: RFR: 8320750: Allow a testcase to run with multiple -Xlog [v3]
In-Reply-To: <LzqG8tmHZgoSqxPjEnULam9uGycRNpdBuPoUjXAdze0=.df98f685-7800-475e-ad3e-7d555c1470ea@github.com>
References: <LzqG8tmHZgoSqxPjEnULam9uGycRNpdBuPoUjXAdze0=.df98f685-7800-475e-ad3e-7d555c1470ea@github.com>
Message-ID: <5X9jP4sjy5xySO3hGJI62s-0L6708818Q3MRhxgYvsw=.cde8ba69-80ef-495a-9d81-ec45e5133816@github.com>

> Running a testcase with muliple -Xlog crashes JTREG test cases. This is because `Collector.toMap` is not given a merge strategy.
> 
> When the same argument is passed multiple times, I have added a merge strategy to use the latter value. This is similar to how it is implemented for `vm.opt.*` in JTREG.
> 
> If the flag tested is `-Xlog`, replace the value part with a dummy value "NONEMPTY_TEST_SENTINEL". This is because in the case of multiple `-Xlog` all values are used, and JTREG does not give a satisfactory way to represent them. This dummy value should make it hard to try to `@require` on specific values by mistake.
> 
> Tested with:
> 
>  @requires vm.opt.x.Xlog == "NONEMPTY_TEST_SENTINEL"
>  @requires vm.opt.x.Xlog == "NONEMPTY_TEST_SENTINELXXX"
>  @requires vm.opt.x.Xms == "3g"
> 
> and
> 
> JAVA_OPTIONS=-Xms3g -Xms4g
> JAVA_OPTIONS=-Xms4g -Xms3g
> JAVA_OPTIONS=-Xlog:gc* -Xlog:gc*
> ``` 
> 
> Running tier1

Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:

  fix after comments from David

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16824/files
  - new: https://git.openjdk.org/jdk/pull/16824/files/d129a0fb..53a3bc2c

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

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

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

From lkorinth at openjdk.org  Thu Feb  8 10:15:24 2024
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 8 Feb 2024 10:15:24 GMT
Subject: RFR: 8320750: Allow a testcase to run with multiple -Xlog [v2]
In-Reply-To: <OrX97tXd_sl0NSVTRe5X7kQPTBqDZkeEwXYtlbve59Y=.6921adb6-9fbc-4ee3-930a-a99cf5925f84@github.com>
References: <LzqG8tmHZgoSqxPjEnULam9uGycRNpdBuPoUjXAdze0=.df98f685-7800-475e-ad3e-7d555c1470ea@github.com>
 <XvF3_iQLanMjMxlu_bS1vcMgYSXYcbFX_mAClOvv6tM=.08c68c1b-3654-467a-8c4c-3ba09e6f6832@github.com>
 <MOBf6oqCvgJxUPAL8rTpwlwjP4-ypivX_cQYaTLtYYw=.d8e440e0-5084-497d-b0ad-4f8c87bf350b@github.com>
 <OrX97tXd_sl0NSVTRe5X7kQPTBqDZkeEwXYtlbve59Y=.6921adb6-9fbc-4ee3-930a-a99cf5925f84@github.com>
Message-ID: <lz48_7QncJZu6dr6PEko_u-Mwx49BZUW2lh0kRjIeno=.36bfda85-9c24-496d-8a69-8e2a69dc5f33@github.com>

On Thu, 8 Feb 2024 10:07:32 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> test/jtreg-ext/requires/VMProps.java line 752:
>> 
>>> 750:      */
>>> 751:     private static boolean isXFlag(String flag) {
>>> 752:         return flag.startsWith("-X") && !flag.startsWith("-XX:") && !flag.equals("-X");
>> 
>> `-XX:` is not wrong, but I wonder if this could/should be `-XX` instead.
>
> Arguably `-XXSomeFlag` is a an x flag and not an xx flag, but I will change it.

After looking a bit more at the code, I will keep the original code as the `"-XX:"` is used in many places in VMProps.java

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16824#discussion_r1482719843

From sroy at openjdk.org  Thu Feb  8 10:23:17 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Thu, 8 Feb 2024 10:23:17 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v17]
In-Reply-To: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
Message-ID: <j2Axb6V6JiBlWz7bxrPxXu0lyOaVitwjTs8L0lL_9LI=.73817667-6a04-4b18-81aa-07cfb1345275@github.com>

> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am.
> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX.
> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails.

Suchismith Roy has updated the pull request incrementally with three additional commits since the last revision:

 - spaces and comma
 - debug lines
 - remove debug lines

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16604/files
  - new: https://git.openjdk.org/jdk/pull/16604/files/0503ed8f..f4b85357

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=15-16

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

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

From sroy at openjdk.org  Thu Feb  8 10:25:58 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Thu, 8 Feb 2024 10:25:58 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v15]
In-Reply-To: <zSvrYlWnij9OTaiPov8OcJ-Go47cYfKNqHXBDiqFw0A=.392aac62-a505-4ad8-8b75-fe2dd7c534c1@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <NcB8LLqVwjhZjvyVED8tqzZMpcwkwnpTFri01A72Izw=.c3655357-8f81-4f27-a332-480b0dfe5855@github.com>
 <zSvrYlWnij9OTaiPov8OcJ-Go47cYfKNqHXBDiqFw0A=.392aac62-a505-4ad8-8b75-fe2dd7c534c1@github.com>
Message-ID: <o9tgdeAcWnwp-qg-0G9D7sga8ON0zDFHUBh6ukRbQU8=.9eb8f9f6-7159-4ea1-9447-a699a2027408@github.com>

On Tue, 6 Feb 2024 10:26:36 GMT, Joachim Kern <jkern at openjdk.org> wrote:

> May be this is academical: Your code works for plain libraries replacing the .so extension by .a. Suppose the case the goal is to load a member of an archive libname.a(member.o), but as in the plain case you get as input libname.so(member.o). In this case you will cut of the member producing the resulting string libname.a instead of libname.a(member.o). Should this situation also be handled or is this forbidden?

Hi Joachim 
I think the case for member archives exists in dl_open. 
It checks for braces and sets the RTLD_MEMBER flag. (Lines 1132-1134)

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

PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1933769585

From sroy at openjdk.org  Thu Feb  8 10:28:59 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Thu, 8 Feb 2024 10:28:59 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v14]
In-Reply-To: <VDnWgKmkKKxKGDnT3_7xmpl6wVqrs6n0Z_mOVWsesCg=.cd4a8667-4086-450e-8fe1-df023ad0acb5@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <cNyV9jVxZtoIf9qgQbTQ86Syu95kql6wC5C1DzgiRPs=.8d2f1d5b-b64a-41b8-87f2-c8d31b0e98c0@github.com>
 <VDnWgKmkKKxKGDnT3_7xmpl6wVqrs6n0Z_mOVWsesCg=.cd4a8667-4086-450e-8fe1-df023ad0acb5@github.com>
Message-ID: <JBjZF1htM8fykk9uKOcxDq3SUQq2oZ9d2kgitPGcpsY=.34d1e014-65a8-443d-9c62-04ba8fd8819b@github.com>

On Mon, 5 Feb 2024 09:01:38 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> The trailing whitespace errors must get fixed (integration blocker).

I am unable to resolve this. The spaces seem fine as i see it in the terminal. Could it be some other error ?

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

PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1933774774

From jkern at openjdk.org  Thu Feb  8 10:32:58 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Thu, 8 Feb 2024 10:32:58 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v15]
In-Reply-To: <o9tgdeAcWnwp-qg-0G9D7sga8ON0zDFHUBh6ukRbQU8=.9eb8f9f6-7159-4ea1-9447-a699a2027408@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <NcB8LLqVwjhZjvyVED8tqzZMpcwkwnpTFri01A72Izw=.c3655357-8f81-4f27-a332-480b0dfe5855@github.com>
 <zSvrYlWnij9OTaiPov8OcJ-Go47cYfKNqHXBDiqFw0A=.392aac62-a505-4ad8-8b75-fe2dd7c534c1@github.com>
 <o9tgdeAcWnwp-qg-0G9D7sga8ON0zDFHUBh6ukRbQU8=.9eb8f9f6-7159-4ea1-9447-a699a2027408@github.com>
Message-ID: <ioQSabaVfZoSJxTnjgwTUJzCJbkdx1NRJf-6yMHz5zc=.2cb4e7ba-54de-459d-b932-657477fc004e@github.com>

On Thu, 8 Feb 2024 10:22:53 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

> > May be this is academical: Your code works for plain libraries replacing the .so extension by .a. Suppose the case the goal is to load a member of an archive libname.a(member.o), but as in the plain case you get as input libname.so(member.o). In this case you will cut of the member producing the resulting string libname.a instead of libname.a(member.o). Should this situation also be handled or is this forbidden?
> 
> Hi Joachim I think the case for member archives exists in dl_open. It checks for braces and sets the RTLD_MEMBER flag. (Lines 1132-1134)

Hi Suchi, but **before** you call dll_load_library, you remove the member part in my mentioned case

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

PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1933782205

From sspitsyn at openjdk.org  Thu Feb  8 10:36:57 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 8 Feb 2024 10:36:57 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v3]
In-Reply-To: <tpoboI2WVbmvE1sR9D-7qsm_Mh8m01-Uwt8tA_pNI5g=.c8219d3c-3acd-4a20-9091-5e9cc911617b@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <bIMfwFEuiZ1CbUtq3NzEeNuW72i4jAqAHGJKMb_VZdg=.4e228b57-af29-4a78-9534-bae11fa6bb2d@github.com>
 <tpoboI2WVbmvE1sR9D-7qsm_Mh8m01-Uwt8tA_pNI5g=.c8219d3c-3acd-4a20-9091-5e9cc911617b@github.com>
Message-ID: <fXc7nXhy_40lRvUzV35Ofv5sAMPGnjeoWMy1QOmKZuI=.abbf125d-656d-4f27-9700-330ae8a77beb@github.com>

On Wed, 7 Feb 2024 22:37:55 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Serguei Spitsyn 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
>>  - review: thread in notify waiter list can't be BLOCKED
>>  - 8324677: Specification clarification needed for JVM TI GetObjectMonitorUsage
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1521:
> 
>> 1519:       // we have contending and/or waiting threads
>> 1520:       if (nWant > 0) {
>> 1521:         // we have contending threads
> 
> This block includes this logic:
> 
>         // get_pending_threads returns only java thread so we do not need to
>         // check for non java threads.
>         GrowableArray<JavaThread*>* wantList = Threads::get_pending_threads(tlh.list(), nWant, (address)mon);
>         if (wantList->length() < nWant) {
>           // robustness: the pending list has gotten smaller
>           nWant = wantList->length();
>         }
> 
> `Threads::get_pending_threads()` only returns threads where the
> `current_pending_monitor` field is set for the specific monitor. That
> happens only on contended enter and does not happen on contended
> re-enter so this logic will already strip out any threads in `wait()` that
> have not been notified and have not had their wait timers expire.
> It will also strip out any waiters that have been notified or had
> their wait timeouts expire.
> 
> This means even if we fix the reenter code to increment the contentions
> field, this logic will reduce that `nWant` value. Of course, the way around
> that is to also update the reenter code to properly set the `current_pending_monitor`
> field and then the reentering threads won't be filtered out...

Yes, I've figured this out now. Thank you for pointing to it.
It feels, the counts can be calculated correctly without touching the implementation of `current_pending_monitor()`, `current_waiting_monitor()`, `_contensions` and `_waiters`.
At least, I'll try to fix it locally in the `JvmtiEnvBase::get_object_monitor_usage()`.
Please, let me know what do you prefer.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1482749279

From dfenacci at openjdk.org  Thu Feb  8 10:36:59 2024
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Thu, 8 Feb 2024 10:36:59 GMT
Subject: RFR: JDK-8325264: two compiler/intrinsics/float16 tests fail after
 JDK-8324724
In-Reply-To: <eoR3U5uw7lee-9UJA2qwsyF9u89D_vW83xykuszAMcU=.f70552a1-d96a-4895-99ac-33dfd0942de2@github.com>
References: <eoR3U5uw7lee-9UJA2qwsyF9u89D_vW83xykuszAMcU=.f70552a1-d96a-4895-99ac-33dfd0942de2@github.com>
Message-ID: <M0rTewgJ5HXWlAysDqYk-KiFyZzmweHXLGR_0nfGlTA=.4e0bff92-5547-4e0f-9cc1-6a0f4de24d52@github.com>

On Tue, 6 Feb 2024 14:37:11 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

> Fix for two JTREG test failures on OS_X after this commit - https://github.com/openjdk/jdk/commit/51853f7488afa69c0d14b0e96f1da84822cd83f1.
> 
> This is due to no permission to execute the stub code in the code cache. This patch fixes this problem by acquiring "WXExec" to be able to execute the instructions in code cache.
> 
> Both the tests - compiler/intrinsics/float16/TestAllFloat16ToFloat.java and compiler/intrinsics/float16/Binary16ConversionNaN.java pass on a MacOS machine.

The change looks ok to me. I also tested it locally.

src/hotspot/share/runtime/stubRoutines.hpp line 457:

> 455:   static jshort f2hf(jfloat x) {
> 456:     MACOS_AARCH64_ONLY(ThreadWXEnable wx(WXExec, Thread::current());) // About to call into code cache
> 457:     assert(_f2hf != nullptr, "stub is not implemented on this platform");

Would it make sense to have the assert as first thing in the method?

src/hotspot/share/runtime/stubRoutines.hpp line 463:

> 461:   static jfloat hf2f(jshort x) {
> 462:     MACOS_AARCH64_ONLY(ThreadWXEnable wx(WXExec, Thread::current());) // About to call into code cache
> 463:     assert(_hf2f != nullptr, "stub is not implemented on this platform");

Same here?

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

PR Review: https://git.openjdk.org/jdk/pull/17733#pullrequestreview-1869784057
PR Review Comment: https://git.openjdk.org/jdk/pull/17733#discussion_r1482746238
PR Review Comment: https://git.openjdk.org/jdk/pull/17733#discussion_r1482747329

From aboldtch at openjdk.org  Thu Feb  8 10:37:13 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 8 Feb 2024 10:37:13 GMT
Subject: RFR: 8319797: Recursive lightweight locking: Runtime
 implementation [v18]
In-Reply-To: <ZWyjRIBdi5FeGTDfaIEmT_lBfg1n9MDl3vxA5g-FKbc=.cb26afcc-555b-4a80-b4f2-319c5422646b@github.com>
References: <ZWyjRIBdi5FeGTDfaIEmT_lBfg1n9MDl3vxA5g-FKbc=.cb26afcc-555b-4a80-b4f2-319c5422646b@github.com>
Message-ID: <JSwpvtOSOCMkejITJFXnsJGjTMO8NOz7nZk6ck-2I-U=.a582232b-4fd4-474c-9951-17111f7942ed@github.com>

> Implements the runtime part of JDK-8319796.
> The different CPU implementations are/will be created as dependent pull requests.
> 
> This enhancement proposes introducing the ability for LM_LIGHTWEIGHT to handle consecutive recursive monitor enter. Limiting the implementation to only consecutive monitor enters allows for more efficient emitted code which only needs to look at the two top most entires on the lock stack to determine what to do in a monitor exit.
> 
> A high level overview:
>   * Locking is still performed on the mark word
>     * Unlocked (0b01) <=> Locked (0b00)
>   * Monitor enter on Obj with mark word Unlocked (0b01) is the same
>     * Transition Obj's mark word Unlocked (0b01) => Locked (0b00)
>     * Push Obj onto the lock stack
>     * Success
>   * Monitor enter on Obj with mark word Locked (0b00) will check the top entry on the lock stack
>     * If top entry is Obj
>       * Push Obj on the lock stack
>       * Success
>     * If top entry is not Obj
>       * Inflate and call ObjectMonitor::enter
>   * Monitor exit on Obj with mark word Locked (0b00) will check the two top entries on the lock stack
>     * If just the top entry is Obj
>       * Transition Obj's mark word Locked (0b00) => Unlocked (0b01)
>       * Pop the entry
>       * Success
>     * If both entries are Obj
>       * Pop the top entry
>       * Success
>     * Any other case only occurs for unstructured locking, then just inflate and call ObjectMonitor::exit
>   * If the monitor has been inflated for object Obj which is owned by the current thread
>     * All corresponding entries for Obj is removed from the lock stack
>     * The monitor recursions is set to the number of removed entries - 1
>     * The owner is changed from anonymous to the thread
>     * The regular ObjectMonitor::action is called.

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 54 commits:

 - Running out of LogTagSets, stick with monitorinflation
 - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8319797
 - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8319797
 - Fix assert comment
 - Update copyright
 - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8319797
 - Add verify calls
 - Assert valid lock stack offset
 - Typos, wording and whitespace
 - Fix miss in is_recursive improvement
 - ... and 44 more: https://git.openjdk.org/jdk/compare/1fb9e3d6...6f76413d

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

Changes: https://git.openjdk.org/jdk/pull/16606/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16606&range=17
  Stats: 863 lines in 13 files changed: 815 ins; 7 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/16606.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16606/head:pull/16606

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

From stefank at openjdk.org  Thu Feb  8 10:37:59 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 8 Feb 2024 10:37:59 GMT
Subject: RFR: 8320750: Allow a testcase to run with multiple -Xlog [v2]
In-Reply-To: <mV2HqnZOxotnBNNvHt0pqooVGpeb9tMmHJjPACdASbQ=.9e46e0be-bd21-4425-a6ed-89cdbe38ae12@github.com>
References: <LzqG8tmHZgoSqxPjEnULam9uGycRNpdBuPoUjXAdze0=.df98f685-7800-475e-ad3e-7d555c1470ea@github.com>
 <XvF3_iQLanMjMxlu_bS1vcMgYSXYcbFX_mAClOvv6tM=.08c68c1b-3654-467a-8c4c-3ba09e6f6832@github.com>
 <MOBf6oqCvgJxUPAL8rTpwlwjP4-ypivX_cQYaTLtYYw=.d8e440e0-5084-497d-b0ad-4f8c87bf350b@github.com>
 <mV2HqnZOxotnBNNvHt0pqooVGpeb9tMmHJjPACdASbQ=.9e46e0be-bd21-4425-a6ed-89cdbe38ae12@github.com>
Message-ID: <baksZMWExgWZT-lVypKtz8UALvZQqonNiFzqZXJrS-8=.57c90691-de2d-4f87-965c-ed8957db6d65@github.com>

On Thu, 8 Feb 2024 10:03:50 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> test/jtreg-ext/requires/VMProps.java line 143:
>> 
>>> 141:         map.put("vm.flagless", this::isFlagless);
>>> 142:         map.put("jdk.foreign.linker", this::jdkForeignLinker);
>>> 143:         map.putAll(xFlags()); // -Xmx4g -> @requires vm.opt.x.Xmx == "4g" )
>> 
>> This has a slightly different style than the vmOptFinalFlags:
>> 
>> map.putAll(xFlags()); // -Xmx4g -> @requires vm.opt.x.Xmx == "4g" )
>> 
>> vs
>> 
>> vmOptFinalFlags(map);
>> 
>> 
>> It could be nice to unify the style so that we have:
>> 
>> vmOptXFlags(map);
>> vmOptFinalFlags(map);
>
> In this case I much prefer my functional style of returning a map value instead of mutating a map argument. I feel I will never finish this if I follow the rabbit hole of updating `vmOptFinalFlags(map)`.

I can unify this code after you get this integrated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16824#discussion_r1482751059

From sroy at openjdk.org  Thu Feb  8 10:41:01 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Thu, 8 Feb 2024 10:41:01 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v15]
In-Reply-To: <ioQSabaVfZoSJxTnjgwTUJzCJbkdx1NRJf-6yMHz5zc=.2cb4e7ba-54de-459d-b932-657477fc004e@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <NcB8LLqVwjhZjvyVED8tqzZMpcwkwnpTFri01A72Izw=.c3655357-8f81-4f27-a332-480b0dfe5855@github.com>
 <zSvrYlWnij9OTaiPov8OcJ-Go47cYfKNqHXBDiqFw0A=.392aac62-a505-4ad8-8b75-fe2dd7c534c1@github.com>
 <o9tgdeAcWnwp-qg-0G9D7sga8ON0zDFHUBh6ukRbQU8=.9eb8f9f6-7159-4ea1-9447-a699a2027408@github.com>
 <ioQSabaVfZoSJxTnjgwTUJzCJbkdx1NRJf-6yMHz5zc=.2cb4e7ba-54de-459d-b932-657477fc004e@github.com>
Message-ID: <W1HRgphjyL_iuMlWsgxl707FGg6w9Kco_-LL_sv3H48=.eb0e4325-09a3-407c-ae45-f22ce9d4e783@github.com>

On Thu, 8 Feb 2024 10:30:43 GMT, Joachim Kern <jkern at openjdk.org> wrote:

> > > May be this is academical: Your code works for plain libraries replacing the .so extension by .a. Suppose the case the goal is to load a member of an archive libname.a(member.o), but as in the plain case you get as input libname.so(member.o). In this case you will cut of the member producing the resulting string libname.a instead of libname.a(member.o). Should this situation also be handled or is this forbidden?
> > 
> > 
> > Hi Joachim I think the case for member archives exists in dl_open. It checks for braces and sets the RTLD_MEMBER flag. (Lines 1132-1134)
> 
> Hi Suchi, but **before** you call dll_load_library, you remove the member part in my mentioned case

Do we have a case where a .so files has braces mentioning the archive members ? I think not.

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

PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1933795230

From aboldtch at openjdk.org  Thu Feb  8 10:43:12 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 8 Feb 2024 10:43:12 GMT
Subject: RFR: 8319799: Recursive lightweight locking: x86 implementation
 [v17]
In-Reply-To: <ymgsUW7sq02C2r82WrLYof5Eb7BB5Lh8M-kGoHx_Zjg=.a5a76651-4931-489f-8ea1-158716614119@github.com>
References: <ymgsUW7sq02C2r82WrLYof5Eb7BB5Lh8M-kGoHx_Zjg=.a5a76651-4931-489f-8ea1-158716614119@github.com>
Message-ID: <OWYJJ_f9eIo5jWGEHafwGOcN2eTvSCtag4MSo3DNhkQ=.49eebb1a-facd-4a35-9674-82d4800a6bef@github.com>

> Implements the x86 port of JDK-8319796.
> 
> There are two major parts for the port implementation. The C2 part, and the part shared by the interpreter, C1 and the native call wrapper.
> 
> The biggest change for both parts is that we check the lock stack first and if it is a recursive lightweight [un]lock and in that case simply pop/push and finish successfully.
> 
> Only if the recursive lightweight [un]lock fails does it look at the mark word. 
> 
> For the shared part if it is an unstructured exit, the monitor is inflated or the mark word transition fails it calls into the runtime.
> 
> The C2 operates under a few more assumptions, that the locking is structured and balanced. This means that some checks can be elided. 
> 
> First this means that in C2 unlock if the obj is not on the top of the lock stack, it must be inflated. And reversely if we reach the inflated C2 unlock the obj is not on the lock stack. This second property makes it possible to avoid reading the owner (and checking if it is anonymous). Instead it can either just do an un-contended unlock by writing null to the owner, or if contention happens, simply write the thread to the owner and jump to the runtime. 
> 
> The x86 C2 port also has some extra oddities. 
> 
> The mark word read is done early as it showed better scaling in hyper-threaded scenarios on certain intel hardware, and no noticeable downside on other tested x86 hardware. 
> 
> The fast path is written to avoid going through conditional branches. This in combination with keeping the ZF output correct, the code does some actions eagerly, decrementing the held monitor count, popping from the lock stack. And jumps to a code stub if a slow path is required which restores the thread local state to a correct state before jumping to the runtime.
> 
> The contended unlock was also moved to the code stub.

Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 27 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319799
 - Comment indent
 - Update copyright years
 - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319799
 - Update MacroAssembler::lightweight_unlock comments.
 - Update comments and asserts
 - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319799
 - Update variable names in ad files
 - Preload markWord unconditionally
 - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319799
 - ... and 17 more: https://git.openjdk.org/jdk/compare/6860b1ca...41bac421

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16607/files
  - new: https://git.openjdk.org/jdk/pull/16607/files/36895d2a..41bac421

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16607&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16607&range=15-16

  Stats: 7423 lines in 403 files changed: 4546 ins; 1505 del; 1372 mod
  Patch: https://git.openjdk.org/jdk/pull/16607.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16607/head:pull/16607

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

From aboldtch at openjdk.org  Thu Feb  8 10:44:14 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 8 Feb 2024 10:44:14 GMT
Subject: RFR: 8319801: Recursive lightweight locking: aarch64
 implementation [v14]
In-Reply-To: <AE1nsnyRCUHR970jjg4feUm5f6E1GPJvea0ooC6dCgI=.73fff610-c0f6-422a-a45d-88187b37b9a2@github.com>
References: <AE1nsnyRCUHR970jjg4feUm5f6E1GPJvea0ooC6dCgI=.73fff610-c0f6-422a-a45d-88187b37b9a2@github.com>
Message-ID: <iC92w1y38RpuDCYuxFHV85skIW6MeGeXy_bMUvG8eFQ=.be791bcf-d426-44a6-b984-01d16a4fed4c@github.com>

> Implements the aarch64 port of JDK-8319796.
> 
> There are two major parts for the port implementation. The C2 part, and the part shared by the interpreter, C1 and the native call wrapper.
> 
> The biggest change for both parts is that we check the lock stack first and if it is a recursive lightweight [un]lock and in that case simply pop/push and finish successfully.
> 
> Only if the recursive lightweight [un]lock fails does it look at the mark word. 
> 
> For the shared part if it is an unstructured exit, the monitor is inflated or the mark word transition fails it calls into the runtime.
> 
> The C2 operates under a few more assumptions, that the locking is structured and balanced. This means that some checks can be elided. 
> 
> First this means that in C2 unlock if the obj is not on the top of the lock stack, it must be inflated. And reversely if we reach the inflated C2 unlock the obj is not on the lock stack. This second property makes it possible to avoid reading the owner (and checking if it is anonymous). Instead it can either just do an un-contended unlock by writing null to the owner, or if contention happens, simply write the thread to the owner and jump to the runtime. 
> 
> The aarch64 C2 port tries to avoid stronger memory semantics where ever possible. In C2 lock it first does a relaxed load of the mark word to check for inflation. Both lock and unlock uses a load/store exclusive register pair to transition the mark word.

Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 23 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319801
 - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319801
 - Update src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp
   
   Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>
 - Clarify the rscratch1 assert
 - Comments and nits
 - Update copyright years
 - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319801
 - Drop memory order comments
 - Preloads markWord unconditionally
 - Revert "Add preload_mark to MacroAssembler::lightweight_lock"
   
   This reverts commit 8950f503aa5dba0e203613bd9737ea0d50388ca3.
 - ... and 13 more: https://git.openjdk.org/jdk/compare/d2b6a037...9b9e1927

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16608/files
  - new: https://git.openjdk.org/jdk/pull/16608/files/2d4ba75d..9b9e1927

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16608&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16608&range=12-13

  Stats: 7423 lines in 403 files changed: 4546 ins; 1505 del; 1372 mod
  Patch: https://git.openjdk.org/jdk/pull/16608.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16608/head:pull/16608

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

From jkern at openjdk.org  Thu Feb  8 10:48:58 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Thu, 8 Feb 2024 10:48:58 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v15]
In-Reply-To: <W1HRgphjyL_iuMlWsgxl707FGg6w9Kco_-LL_sv3H48=.eb0e4325-09a3-407c-ae45-f22ce9d4e783@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <NcB8LLqVwjhZjvyVED8tqzZMpcwkwnpTFri01A72Izw=.c3655357-8f81-4f27-a332-480b0dfe5855@github.com>
 <zSvrYlWnij9OTaiPov8OcJ-Go47cYfKNqHXBDiqFw0A=.392aac62-a505-4ad8-8b75-fe2dd7c534c1@github.com>
 <o9tgdeAcWnwp-qg-0G9D7sga8ON0zDFHUBh6ukRbQU8=.9eb8f9f6-7159-4ea1-9447-a699a2027408@github.com>
 <ioQSabaVfZoSJxTnjgwTUJzCJbkdx1NRJf-6yMHz5zc=.2cb4e7ba-54de-459d-b932-657477fc004e@github.com>
 <W1HRgphjyL_iuMlWsgxl707FGg6w9Kco_-LL_sv3H48=.eb0e4325-09a3-407c-ae45-f22ce9d4e783@github.com>
Message-ID: <3SJSb4UmmbrEz3Lwb8onh4qcDnLJ-XER8Sk9jnjqV3I=.63c5aa4e-5f15-4249-abc4-271a50b537d4@github.com>

On Thu, 8 Feb 2024 10:38:37 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

> > > > May be this is academical: Your code works for plain libraries replacing the .so extension by .a. Suppose the case the goal is to load a member of an archive libname.a(member.o), but as in the plain case you get as input libname.so(member.o). In this case you will cut of the member producing the resulting string libname.a instead of libname.a(member.o). Should this situation also be handled or is this forbidden?
> > > 
> > > 
> > > Hi Joachim I think the case for member archives exists in dl_open. It checks for braces and sets the RTLD_MEMBER flag. (Lines 1132-1134)
> > 
> > 
> > Hi Suchi, but **before** you call dll_load_library, you remove the member part in my mentioned case
> 
> Do we have a case where a .so files has braces mentioning the archive members ? I think not.

That's why I am asking. If not this is an academical concern. But it should be mentioned in a comment, that this is not expected to work.

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

PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1933808741

From sroy at openjdk.org  Thu Feb  8 11:04:00 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Thu, 8 Feb 2024 11:04:00 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v15]
In-Reply-To: <3SJSb4UmmbrEz3Lwb8onh4qcDnLJ-XER8Sk9jnjqV3I=.63c5aa4e-5f15-4249-abc4-271a50b537d4@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <NcB8LLqVwjhZjvyVED8tqzZMpcwkwnpTFri01A72Izw=.c3655357-8f81-4f27-a332-480b0dfe5855@github.com>
 <zSvrYlWnij9OTaiPov8OcJ-Go47cYfKNqHXBDiqFw0A=.392aac62-a505-4ad8-8b75-fe2dd7c534c1@github.com>
 <o9tgdeAcWnwp-qg-0G9D7sga8ON0zDFHUBh6ukRbQU8=.9eb8f9f6-7159-4ea1-9447-a699a2027408@github.com>
 <ioQSabaVfZoSJxTnjgwTUJzCJbkdx1NRJf-6yMHz5zc=.2cb4e7ba-54de-459d-b932-657477fc004e@github.com>
 <W1HRgphjyL_iuMlWsgxl707FGg6w9Kco_-LL_sv3H48=.eb0e4325-09a3-407c-ae45-f22ce9d4e783@github.com>
 <3SJSb4UmmbrEz3Lwb8onh4qcDnLJ-XER8Sk9jnjqV3I=.63c5aa4e-5f15-4249-abc4-271a50b537d4@github.com>
Message-ID: <vl2ME-lNIJF7tEkX2MMrSJRouK6t4AqFQwhlXtrbM3w=.44b623b6-cc77-43ae-a269-e1bb4c7f2142@github.com>

On Thu, 8 Feb 2024 10:46:37 GMT, Joachim Kern <jkern at openjdk.org> wrote:

> > > > > May be this is academical: Your code works for plain libraries replacing the .so extension by .a. Suppose the case the goal is to load a member of an archive libname.a(member.o), but as in the plain case you get as input libname.so(member.o). In this case you will cut of the member producing the resulting string libname.a instead of libname.a(member.o). Should this situation also be handled or is this forbidden?
> > > > 
> > > > 
> > > > Hi Joachim I think the case for member archives exists in dl_open. It checks for braces and sets the RTLD_MEMBER flag. (Lines 1132-1134)
> > > 
> > > 
> > > Hi Suchi, but **before** you call dll_load_library, you remove the member part in my mentioned case
> > 
> > 
> > Do we have a case where a .so files has braces mentioning the archive members ? I think not.
> 
> That's why I am asking. If not this is an academical concern. But it should be mentioned in a comment, that this is not expected to work.

Yes, but i was also asking if at all there is a case ,which i am not aware of. Sure i will mention it in comments. 
But there is one case that keep me thinking, is that ..will a particular .so file have an .a file with same name, but also referred to a member ?

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

PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1933833986

From bkilambi at openjdk.org  Thu Feb  8 11:07:53 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Thu, 8 Feb 2024 11:07:53 GMT
Subject: RFR: JDK-8325264: two compiler/intrinsics/float16 tests fail after
 JDK-8324724
In-Reply-To: <M0rTewgJ5HXWlAysDqYk-KiFyZzmweHXLGR_0nfGlTA=.4e0bff92-5547-4e0f-9cc1-6a0f4de24d52@github.com>
References: <eoR3U5uw7lee-9UJA2qwsyF9u89D_vW83xykuszAMcU=.f70552a1-d96a-4895-99ac-33dfd0942de2@github.com>
 <M0rTewgJ5HXWlAysDqYk-KiFyZzmweHXLGR_0nfGlTA=.4e0bff92-5547-4e0f-9cc1-6a0f4de24d52@github.com>
Message-ID: <d6aCSQ6ivkgfAQ5pnSNXHIOlZz6GtIiski002-T3cus=.ec07eee9-0712-4bc4-a79a-fdb2ee371f89@github.com>

On Thu, 8 Feb 2024 10:31:48 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> Fix for two JTREG test failures on OS_X after this commit - https://github.com/openjdk/jdk/commit/51853f7488afa69c0d14b0e96f1da84822cd83f1.
>> 
>> This is due to no permission to execute the stub code in the code cache. This patch fixes this problem by acquiring "WXExec" to be able to execute the instructions in code cache.
>> 
>> Both the tests - compiler/intrinsics/float16/TestAllFloat16ToFloat.java and compiler/intrinsics/float16/Binary16ConversionNaN.java pass on a MacOS machine.
>
> src/hotspot/share/runtime/stubRoutines.hpp line 457:
> 
>> 455:   static jshort f2hf(jfloat x) {
>> 456:     MACOS_AARCH64_ONLY(ThreadWXEnable wx(WXExec, Thread::current());) // About to call into code cache
>> 457:     assert(_f2hf != nullptr, "stub is not implemented on this platform");
> 
> Would it make sense to have the assert as first thing in the method?

Yes, probably a better idea to make sure the address (of the stub) being accessed is valid before making that memory region executable. Will make changes and update. Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17733#discussion_r1482791010

From eastigeevich at openjdk.org  Thu Feb  8 12:06:59 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Thu, 8 Feb 2024 12:06:59 GMT
Subject: RFR: 8324874: AArch64: crypto pmull based CRC32/CRC32C intrinsics
 clobber V8-V15 registers [v2]
In-Reply-To: <0SyT_VJe-wuDQqutiEy8bSjxvECduPSEuqP0tnrBSfI=.75eee8c5-466a-437e-a38e-0c0ed38df080@github.com>
References: <I4SlF2m1-uY5cH3AsdBhVqbTJ1m7GXfThpCgfx_6N5k=.b7a84fc0-198c-4bf0-a26b-bbe3c3ed2558@github.com>
 <T_qG0AQ3r_AxzbtUm1HZTDQ-tjokSs1wcHiz4V2WGl4=.987ff437-ff99-49b0-8707-d7b46fca2caa@github.com>
 <0SyT_VJe-wuDQqutiEy8bSjxvECduPSEuqP0tnrBSfI=.75eee8c5-466a-437e-a38e-0c0ed38df080@github.com>
Message-ID: <8AsHXgebJSWht-EmMYJLRPfdSeYln3H5lK2Xtb1eNUw=.44c04800-6af6-412c-b3a8-221365ecc088@github.com>

On Mon, 5 Feb 2024 09:05:11 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix code comments
>
> Thanks. This bug really shouldn't have got through review.

@theRealAph @nick-arm Thank you for reviewing.

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

PR Comment: https://git.openjdk.org/jdk/pull/17701#issuecomment-1933974054

From rkennke at openjdk.org  Thu Feb  8 12:42:22 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 8 Feb 2024 12:42:22 GMT
Subject: RFR: 8305898: Alternative self-forwarding mechanism [v2]
In-Reply-To: <N4eX8S-btv0VD19kl2W9RigVsaw58ZVXDZllFwykZ04=.a9456aa8-b294-480a-b7f0-07616c972f62@github.com>
References: <N4eX8S-btv0VD19kl2W9RigVsaw58ZVXDZllFwykZ04=.a9456aa8-b294-480a-b7f0-07616c972f62@github.com>
Message-ID: <ZaPKfYdKwtvm1IggDFQbhhpQvDxtqQcSsJ6USDN1HFk=.14a14666-ed50-46f1-9ec5-e1ef9d2eb165@github.com>

> Currently, the Serial, Parallel and G1 GCs store a pointer to self into object headers to indicate promotion failure. This is problematic for compact object headers ([JDK-8294992](https://bugs.openjdk.org/browse/JDK-8294992)) because it would (temporarily) over-write the crucial class information, which we need for heap parsing. I would like to propose an alternative: use the currently unused 3rd header bit (previously biased-locking bit) to indicate that an object is 'self-forwarded'. That preserves the crucial class information in the upper bits of the header until the full header gets restored.
> 
> This is a trimmed-down/simplified version of the original proposal #13779:
>  - It doesn't use/introduce any flags and avoids the associated branching.
>  - It doesn't (need to) deal with displaced headers. (Current code would preserve header if necessary, Lilliput code would not use displaced headers and set the 3rd bit directly in existing header.)
> 
> Testing:
>  - [x] hotspot_gc
>  - [x] tier1
>  - [x] tier2

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Align fake-oop in gtest

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17755/files
  - new: https://git.openjdk.org/jdk/pull/17755/files/aa5e9876..c7ddf821

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

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

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

From tschatzl at openjdk.org  Thu Feb  8 12:52:07 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 8 Feb 2024 12:52:07 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v6]
In-Reply-To: <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
Message-ID: <QvyeIdmQWBfw6n_wbTK0uaPQzMJsdOBslw80YxjSqC4=.dc3269e8-fe40-4390-ba88-bbd3e4f76a2a@github.com>

On Tue, 30 Jan 2024 09:08:01 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> ICStubs solve an atomicity problem when setting both the destination and data of an inline cache. Unfortunately, it also leads to occasional safepoint carpets when multiple threads need to ICRefill the stubs at the same time, and spurious GuaranteedSafepointInterval "Cleanup" safepoints every second. This patch changes inline caches to not change the data part at all during the nmethod life cycle, hence removing the need for ICStubs.
>> 
>> The new scheme is less stateful. Instead of adding and removing callsite metadata back and forth when transitioning inline cache states, it installs all state any shape of call will ever need at resolution time in a struct that I call CompiledICData. This reduces inline cache state changes to simply changing the destination of the call, and it doesn't really matter what state transitions to what other state.
>> 
>> With this patch, we get rid of ICStub and ICBuffer classes and the related ICRefill and almost all Cleanup safepoints in practice. It also makes the inline cache code much simpler.
>> 
>> I have tested the changes from tier1-7, and run through full aurora performance tests.
>
> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ARM32 fixes

First, I'm a bit hesitant to approve this because while it looks good to me, I'm no expert in that code and in particular how it interacts with other things all around.
Also I only looked at x86 assembler code (and a bit aarch64), so this is not a complete review anyway.
The only comments I can contribute is some additional refactoring, so I'm keeping this review as Comment.

src/hotspot/share/code/compiledIC.hpp line 57:

> 55: };
> 56: 
> 57: // A CompiledICData* is a helper object for the inline cache implementation.

Suggestion:

// A CompiledICData is a helper object for the inline cache implementation.

src/hotspot/share/code/compiledMethod.cpp line 457:

> 455:   if (clean_all || !cm->is_in_use() || cm->is_unloading() || cm->method()->code() != cm) {
> 456:     cdc->set_to_clean();
> 457:   }

Maybe a single `clean_if_nmethod_is_unloaded()` with the destination address as a parameter would avoid the code duplication with the other variant; otherwise another static helper function would be great.

src/hotspot/share/code/nmethod.cpp line 2310:

> 2308:       } else {
> 2309:         CompiledDirectCall::at(call_site);
> 2310:       }

Since `CompiledICLocker` does not lock anyway if it is safe (using the `is_safe` method), isn't the `if` superfluous here (and just keeping the `else` part does the same)?

src/hotspot/share/oops/oopsHierarchy.hpp line 182:

> 180: class   Method;
> 181: class   ConstantPool;
> 182: //      class CHeapObj

Not sure why this is here, but maybe also remove this line.

src/hotspot/share/runtime/sharedRuntime.cpp line 1369:

> 1367:   } else {
> 1368:     // Callsite is a direct call - set it to the destination method
> 1369:     CompiledICLocker ml(caller_nm);

Not sure if it makes sense to factor out the `CompiledICLocker ml(caller_nm); call in both if branches.

src/hotspot/share/runtime/sharedRuntime.cpp line 1665:

> 1663: 
> 1664:     // Check relocations for the matching call to 1) avoid false positives,
> 1665:     // and 2) determine the type.

To me the comment is confusing (probably pre-existing): There does not seem to be a result of the code checking the relocations containing the "type" of the following code. I.e. the only reason this seems to be done here is reason 1), reason 2) seems obsolete.

src/hotspot/share/runtime/sharedRuntime.cpp line 1803:

> 1801:   RelocIterator iter(caller, callsite_addr, callsite_addr + 1);
> 1802:   if (!iter.next()) {
> 1803:     // No reloc entry found; not a static or opt virutal call

Suggestion:

    // No reloc entry found; not a static or optimized virtual call

(actually s/virutal/virtual is as fine. Or maybe use `opt_virtual` as in line 1798 above)

src/hotspot/share/runtime/sharedRuntime.cpp line 1807:

> 1805:   }
> 1806: 
> 1807:   assert(iter.has_current(), "must have a reloc at java call site");

This assert seems to be superfluous after the `if (!iter.next())` bailout just above.

src/hotspot/share/runtime/sharedRuntime.cpp line 1837:

> 1835:   CompiledMethod* caller_nm = cb->as_compiled_method();
> 1836: 
> 1837:   for (;;) {

I think the comment in line 1826 about


  // Transitioning IC caches may require transition stubs. If we run out
  // of transition stubs, we have to drop locks and perform a safepoint
  // that refills them.

is out of date and should be removed. At least the code that generates the IC stubs below has been removed...

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

PR Review: https://git.openjdk.org/jdk/pull/17495#pullrequestreview-1869869238
PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1482897763
PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1482895770
PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1482870537
PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1482845871
PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1482825184
PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1482810188
PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1482820114
PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1482822437
PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1482796779

From stefank at openjdk.org  Thu Feb  8 13:33:05 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 8 Feb 2024 13:33:05 GMT
Subject: RFR: 8305898: Alternative self-forwarding mechanism [v2]
In-Reply-To: <ZaPKfYdKwtvm1IggDFQbhhpQvDxtqQcSsJ6USDN1HFk=.14a14666-ed50-46f1-9ec5-e1ef9d2eb165@github.com>
References: <N4eX8S-btv0VD19kl2W9RigVsaw58ZVXDZllFwykZ04=.a9456aa8-b294-480a-b7f0-07616c972f62@github.com>
 <ZaPKfYdKwtvm1IggDFQbhhpQvDxtqQcSsJ6USDN1HFk=.14a14666-ed50-46f1-9ec5-e1ef9d2eb165@github.com>
Message-ID: <atx4XgigGbLJYnUdajEX19oe31vUTjGuk2xRxXFfGI0=.23191dba-ffcb-4a7e-9601-9bc1f067068c@github.com>

On Thu, 8 Feb 2024 12:42:22 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Currently, the Serial, Parallel and G1 GCs store a pointer to self into object headers to indicate promotion failure. This is problematic for compact object headers ([JDK-8294992](https://bugs.openjdk.org/browse/JDK-8294992)) because it would (temporarily) over-write the crucial class information, which we need for heap parsing. I would like to propose an alternative: use the currently unused 3rd header bit (previously biased-locking bit) to indicate that an object is 'self-forwarded'. That preserves the crucial class information in the upper bits of the header until the full header gets restored.
>> 
>> This is a trimmed-down/simplified version of the original proposal #13779:
>>  - It doesn't use/introduce any flags and avoids the associated branching.
>>  - It doesn't (need to) deal with displaced headers. (Current code would preserve header if necessary, Lilliput code would not use displaced headers and set the 3rd bit directly in existing header.)
>> 
>> Testing:
>>  - [x] hotspot_gc
>>  - [x] tier1
>>  - [x] tier2
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Align fake-oop in gtest

src/hotspot/share/oops/markWord.hpp line 119:

> 117:   static const uintptr_t lock_mask_in_place       = lock_mask << lock_shift;
> 118:   static const uintptr_t self_forwarded_mask      = right_n_bits(self_forwarded_bits);
> 119:   static const uintptr_t self_forwarded_mask_in_place = self_forwarded_mask << self_forwarded_shift;

Could you readjust the rest of the assignment so that we keep these nice and tidy?

src/hotspot/share/oops/oop.inline.hpp line 294:

> 292: }
> 293: 
> 294: oop oopDesc::forward_to_self_atomic(markWord compare, atomic_memory_order order) {

The new `forward_to_self_atomic` shares most of the code with `forward_to_atomic`. Would it make sense to extract the shared part into a helper? Maybe a:


oop oopDesc::cas_set_forwardee(markWord new_mark, markWord compare, atomic_memory_order order) {
  markWord old_mark = cas_set_mark(new_mark, compare, order);
  if (old_mark == compare) {
    return nullptr;
  } else {
    assert(old_mark.is_marked(), "must be marked here");
    return forwardee(old_mark);
  }
}


and then:

oop oopDesc::forward_to_atomic(oop to, markWord compare, atomic_memory_order order) {
  markWord new_mark = markWord::encode_pointer_as_mark(to);
  assert(forwardee(new_mark) == to, "encoding must be reversible");
  
  return cas_set_forwardee(new_mark, compare, order);
}

oop oopDesc::forward_to_self_atomic(markWord compare, atomic_memory_order order) {
  markWord new_mark = markWord::prototype().set_self_forwarded();
  assert(forwardee(new_mark) == cast_to_oop(this), "encoding must be reversible");
  
  return cas_set_forwardee(new_mark, compare, order);

src/hotspot/share/oops/oop.inline.hpp line 306:

> 304: }
> 305: oop oopDesc::forwardee(markWord mark) const {
> 306:   assert(mark.is_marked(), "only decode when actually forwarded");

I think it would be nice if this assert could instead be written as:

assert(mark.is_forwarded(), "only decode when actually forwarded");


Would people be opposed to adding a `markWord::is_forwarded` function? We already have one for oopDesc:

bool oopDesc::is_forwarded() const {
  // The extra heap check is needed since the obj might be locked, in which case the
  // mark would point to a stack location and have the sentinel bit cleared
  return mark().is_marked();
}

(which also could use `is_forwarded` instead of `is_marked`. (BTW, the comment is old and should probably be removed) ).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17755#discussion_r1482958735
PR Review Comment: https://git.openjdk.org/jdk/pull/17755#discussion_r1482973817
PR Review Comment: https://git.openjdk.org/jdk/pull/17755#discussion_r1482979620

From jkern at openjdk.org  Thu Feb  8 14:25:59 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Thu, 8 Feb 2024 14:25:59 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v15]
In-Reply-To: <vl2ME-lNIJF7tEkX2MMrSJRouK6t4AqFQwhlXtrbM3w=.44b623b6-cc77-43ae-a269-e1bb4c7f2142@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <NcB8LLqVwjhZjvyVED8tqzZMpcwkwnpTFri01A72Izw=.c3655357-8f81-4f27-a332-480b0dfe5855@github.com>
 <zSvrYlWnij9OTaiPov8OcJ-Go47cYfKNqHXBDiqFw0A=.392aac62-a505-4ad8-8b75-fe2dd7c534c1@github.com>
 <o9tgdeAcWnwp-qg-0G9D7sga8ON0zDFHUBh6ukRbQU8=.9eb8f9f6-7159-4ea1-9447-a699a2027408@github.com>
 <ioQSabaVfZoSJxTnjgwTUJzCJbkdx1NRJf-6yMHz5zc=.2cb4e7ba-54de-459d-b932-657477fc004e@github.com>
 <W1HRgphjyL_iuMlWsgxl707FGg6w9Kco_-LL_sv3H48=.eb0e4325-09a3-407c-ae45-f22ce9d4e783@github.com>
 <3SJSb4UmmbrEz3Lwb8onh4qcDnLJ-XER8Sk9jnjqV3I=.63c5aa4e-5f15-4249-abc4-271a50b537d4@github.com>
 <vl2ME-lNIJF7tEkX2MMrSJRouK6t4AqFQwhlXtrbM3w=.44b623b6-cc77-43ae-a269-e1bb4c7f2142@github.com>
Message-ID: <5C9t4TRNHNH5DOj7GP3_Lmg6FVFXT0OqZwf5LHRMf4M=.3f5766da-6ba2-486e-8330-855b63300b4e@github.com>

On Thu, 8 Feb 2024 11:01:25 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

> > > > > > May be this is academical: Your code works for plain libraries replacing the .so extension by .a. Suppose the case the goal is to load a member of an archive libname.a(member.o), but as in the plain case you get as input libname.so(member.o). In this case you will cut of the member producing the resulting string libname.a instead of libname.a(member.o). Should this situation also be handled or is this forbidden?
> > > > > 
> > > > > 
> > > > > Hi Joachim I think the case for member archives exists in dl_open. It checks for braces and sets the RTLD_MEMBER flag. (Lines 1132-1134)
> > > > 
> > > > 
> > > > Hi Suchi, but **before** you call dll_load_library, you remove the member part in my mentioned case
> > > 
> > > 
> > > Do we have a case where a .so files has braces mentioning the archive members ? I think not.
> > 
> > 
> > That's why I am asking. If not this is an academical concern. But it should be mentioned in a comment, that this is not expected to work.
> 
> Yes, but i was also asking if at all there is a case ,which i am not aware of. Sure i will mention it in comments. But there is one case that keep me thinking, is that ..will a particular .so file have an .a file with same name, but also referred to a member ?

No, there is no case I'm aware of. Just theoretical thinking.

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

PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1934227854

From rkennke at openjdk.org  Thu Feb  8 14:32:16 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 8 Feb 2024 14:32:16 GMT
Subject: RFR: 8305898: Alternative self-forwarding mechanism [v3]
In-Reply-To: <N4eX8S-btv0VD19kl2W9RigVsaw58ZVXDZllFwykZ04=.a9456aa8-b294-480a-b7f0-07616c972f62@github.com>
References: <N4eX8S-btv0VD19kl2W9RigVsaw58ZVXDZllFwykZ04=.a9456aa8-b294-480a-b7f0-07616c972f62@github.com>
Message-ID: <cqvYzXFCN3-4iukDlK5xnf1IcaOyraZqcDBjTqYcDxc=.1c232227-954c-44be-8aff-83db1bc6524e@github.com>

> Currently, the Serial, Parallel and G1 GCs store a pointer to self into object headers to indicate promotion failure. This is problematic for compact object headers ([JDK-8294992](https://bugs.openjdk.org/browse/JDK-8294992)) because it would (temporarily) over-write the crucial class information, which we need for heap parsing. I would like to propose an alternative: use the currently unused 3rd header bit (previously biased-locking bit) to indicate that an object is 'self-forwarded'. That preserves the crucial class information in the upper bits of the header until the full header gets restored.
> 
> This is a trimmed-down/simplified version of the original proposal #13779:
>  - It doesn't use/introduce any flags and avoids the associated branching.
>  - It doesn't (need to) deal with displaced headers. (Current code would preserve header if necessary, Lilliput code would not use displaced headers and set the 3rd bit directly in existing header.)
> 
> Testing:
>  - [x] hotspot_gc
>  - [x] tier1
>  - [x] tier2

Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:

 - Address @stefank's review-comments
 - Fix alignas to use constant expression

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17755/files
  - new: https://git.openjdk.org/jdk/pull/17755/files/c7ddf821..fbfb1e73

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

  Stats: 37 lines in 4 files changed: 15 ins; 8 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/17755.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17755/head:pull/17755

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

From rkennke at openjdk.org  Thu Feb  8 14:32:17 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 8 Feb 2024 14:32:17 GMT
Subject: RFR: 8305898: Alternative self-forwarding mechanism [v2]
In-Reply-To: <atx4XgigGbLJYnUdajEX19oe31vUTjGuk2xRxXFfGI0=.23191dba-ffcb-4a7e-9601-9bc1f067068c@github.com>
References: <N4eX8S-btv0VD19kl2W9RigVsaw58ZVXDZllFwykZ04=.a9456aa8-b294-480a-b7f0-07616c972f62@github.com>
 <ZaPKfYdKwtvm1IggDFQbhhpQvDxtqQcSsJ6USDN1HFk=.14a14666-ed50-46f1-9ec5-e1ef9d2eb165@github.com>
 <atx4XgigGbLJYnUdajEX19oe31vUTjGuk2xRxXFfGI0=.23191dba-ffcb-4a7e-9601-9bc1f067068c@github.com>
Message-ID: <Gn_kIxabaDJdZlfJqwa52VlbLLxXZK1ejnsHvP4MqgA=.bdc308ea-5e55-4d21-b5b7-6b64d7a667d6@github.com>

On Thu, 8 Feb 2024 13:13:25 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Align fake-oop in gtest
>
> src/hotspot/share/oops/markWord.hpp line 119:
> 
>> 117:   static const uintptr_t lock_mask_in_place       = lock_mask << lock_shift;
>> 118:   static const uintptr_t self_forwarded_mask      = right_n_bits(self_forwarded_bits);
>> 119:   static const uintptr_t self_forwarded_mask_in_place = self_forwarded_mask << self_forwarded_shift;
> 
> Could you readjust the rest of the assignment so that we keep these nice and tidy?

I am shortening it to 'self_fwd_*' instead, otherwise it all gets too wide, IMO. I hope that's ok?

> src/hotspot/share/oops/oop.inline.hpp line 294:
> 
>> 292: }
>> 293: 
>> 294: oop oopDesc::forward_to_self_atomic(markWord compare, atomic_memory_order order) {
> 
> The new `forward_to_self_atomic` shares most of the code with `forward_to_atomic`. Would it make sense to extract the shared part into a helper? Maybe a:
> 
> 
> oop oopDesc::cas_set_forwardee(markWord new_mark, markWord compare, atomic_memory_order order) {
>   markWord old_mark = cas_set_mark(new_mark, compare, order);
>   if (old_mark == compare) {
>     return nullptr;
>   } else {
>     assert(old_mark.is_marked(), "must be marked here");
>     return forwardee(old_mark);
>   }
> }
> 
> 
> and then:
> 
> oop oopDesc::forward_to_atomic(oop to, markWord compare, atomic_memory_order order) {
>   markWord new_mark = markWord::encode_pointer_as_mark(to);
>   assert(forwardee(new_mark) == to, "encoding must be reversible");
>   
>   return cas_set_forwardee(new_mark, compare, order);
> }
> 
> oop oopDesc::forward_to_self_atomic(markWord compare, atomic_memory_order order) {
>   markWord new_mark = markWord::prototype().set_self_forwarded();
>   assert(forwardee(new_mark) == cast_to_oop(this), "encoding must be reversible");
>   
>   return cas_set_forwardee(new_mark, compare, order);

Good suggestion, I am doing that.

> src/hotspot/share/oops/oop.inline.hpp line 306:
> 
>> 304: }
>> 305: oop oopDesc::forwardee(markWord mark) const {
>> 306:   assert(mark.is_marked(), "only decode when actually forwarded");
> 
> I think it would be nice if this assert could instead be written as:
> 
> assert(mark.is_forwarded(), "only decode when actually forwarded");
> 
> 
> Would people be opposed to adding a `markWord::is_forwarded` function? We already have one for oopDesc:
> 
> bool oopDesc::is_forwarded() const {
>   // The extra heap check is needed since the obj might be locked, in which case the
>   // mark would point to a stack location and have the sentinel bit cleared
>   return mark().is_marked();
> }
> 
> (which also could use `is_forwarded` instead of `is_marked`. (BTW, the comment is old and should probably be removed) ).

Yes, I prefer that, too. Also, once the SerialGC gets its new (compressor) GC (see #17312), we can remove the 'marked' language altogether, because the bit-pattern no longer means 'marked' but only 'forwarded'. In-fact, we could even (finally?) rename the markWord to header (or a variant like objectHeader) because it would no longer be used for marking at all.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17755#discussion_r1483064248
PR Review Comment: https://git.openjdk.org/jdk/pull/17755#discussion_r1483064658
PR Review Comment: https://git.openjdk.org/jdk/pull/17755#discussion_r1483068393

From rkennke at openjdk.org  Thu Feb  8 14:37:20 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 8 Feb 2024 14:37:20 GMT
Subject: RFR: 8305898: Alternative self-forwarding mechanism [v4]
In-Reply-To: <N4eX8S-btv0VD19kl2W9RigVsaw58ZVXDZllFwykZ04=.a9456aa8-b294-480a-b7f0-07616c972f62@github.com>
References: <N4eX8S-btv0VD19kl2W9RigVsaw58ZVXDZllFwykZ04=.a9456aa8-b294-480a-b7f0-07616c972f62@github.com>
Message-ID: <OC2HtdWXXKiV3OLkz39XVG7bickA31IZZVgpZpZy3GU=.04506b71-994c-4dc6-a39f-cf0d0c908977@github.com>

> Currently, the Serial, Parallel and G1 GCs store a pointer to self into object headers to indicate promotion failure. This is problematic for compact object headers ([JDK-8294992](https://bugs.openjdk.org/browse/JDK-8294992)) because it would (temporarily) over-write the crucial class information, which we need for heap parsing. I would like to propose an alternative: use the currently unused 3rd header bit (previously biased-locking bit) to indicate that an object is 'self-forwarded'. That preserves the crucial class information in the upper bits of the header until the full header gets restored.
> 
> This is a trimmed-down/simplified version of the original proposal #13779:
>  - It doesn't use/introduce any flags and avoids the associated branching.
>  - It doesn't (need to) deal with displaced headers. (Current code would preserve header if necessary, Lilliput code would not use displaced headers and set the 3rd bit directly in existing header.)
> 
> Testing:
>  - [x] hotspot_gc
>  - [x] tier1
>  - [x] tier2

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  More consistent use of markWord::is_forwarded()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17755/files
  - new: https://git.openjdk.org/jdk/pull/17755/files/fbfb1e73..f844954f

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

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

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

From mdoerr at openjdk.org  Thu Feb  8 14:42:07 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 8 Feb 2024 14:42:07 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v14]
In-Reply-To: <JBjZF1htM8fykk9uKOcxDq3SUQq2oZ9d2kgitPGcpsY=.34d1e014-65a8-443d-9c62-04ba8fd8819b@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <cNyV9jVxZtoIf9qgQbTQ86Syu95kql6wC5C1DzgiRPs=.8d2f1d5b-b64a-41b8-87f2-c8d31b0e98c0@github.com>
 <VDnWgKmkKKxKGDnT3_7xmpl6wVqrs6n0Z_mOVWsesCg=.cd4a8667-4086-450e-8fe1-df023ad0acb5@github.com>
 <JBjZF1htM8fykk9uKOcxDq3SUQq2oZ9d2kgitPGcpsY=.34d1e014-65a8-443d-9c62-04ba8fd8819b@github.com>
Message-ID: <1kzsCJOR4U-lc77vCBrS_Oa4YCoBv5a7Zz8gKDHDuXg=.9471c3b3-cea7-415b-aa18-79aa76f508d1@github.com>

On Thu, 8 Feb 2024 10:26:05 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

> > The trailing whitespace errors must get fixed (integration blocker).
> 
> I am unable to resolve this. The spaces seem fine as i see it in the terminal. Could it be some other error ?

Strange. I don't see any whitespace problem, either. Maybe it's possible to rerun jcheck (GitHub Actions). Otherwise, you may need to create a new PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1934260353

From dcubed at openjdk.org  Thu Feb  8 15:32:03 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 8 Feb 2024 15:32:03 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v3]
In-Reply-To: <fXc7nXhy_40lRvUzV35Ofv5sAMPGnjeoWMy1QOmKZuI=.abbf125d-656d-4f27-9700-330ae8a77beb@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <bIMfwFEuiZ1CbUtq3NzEeNuW72i4jAqAHGJKMb_VZdg=.4e228b57-af29-4a78-9534-bae11fa6bb2d@github.com>
 <tpoboI2WVbmvE1sR9D-7qsm_Mh8m01-Uwt8tA_pNI5g=.c8219d3c-3acd-4a20-9091-5e9cc911617b@github.com>
 <fXc7nXhy_40lRvUzV35Ofv5sAMPGnjeoWMy1QOmKZuI=.abbf125d-656d-4f27-9700-330ae8a77beb@github.com>
Message-ID: <yZc4kRjeFsvrCkhso6p_uU4_v-R5cvvOlBzABm-bDV8=.40d038c7-f8f9-4bf2-ac9d-33c75cdc6825@github.com>

On Thu, 8 Feb 2024 10:34:14 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1521:
>> 
>>> 1519:       // we have contending and/or waiting threads
>>> 1520:       if (nWant > 0) {
>>> 1521:         // we have contending threads
>> 
>> This block includes this logic:
>> 
>>         // get_pending_threads returns only java thread so we do not need to
>>         // check for non java threads.
>>         GrowableArray<JavaThread*>* wantList = Threads::get_pending_threads(tlh.list(), nWant, (address)mon);
>>         if (wantList->length() < nWant) {
>>           // robustness: the pending list has gotten smaller
>>           nWant = wantList->length();
>>         }
>> 
>> `Threads::get_pending_threads()` only returns threads where the
>> `current_pending_monitor` field is set for the specific monitor. That
>> happens only on contended enter and does not happen on contended
>> re-enter so this logic will already strip out any threads in `wait()` that
>> have not been notified and have not had their wait timers expire.
>> It will also strip out any waiters that have been notified or had
>> their wait timeouts expire.
>> 
>> This means even if we fix the reenter code to increment the contentions
>> field, this logic will reduce that `nWant` value. Of course, the way around
>> that is to also update the reenter code to properly set the `current_pending_monitor`
>> field and then the reentering threads won't be filtered out...
>
> Yes, I've figured this out now. Thank you for pointing to it.
> It feels, the counts can be calculated correctly without touching the implementation of `current_pending_monitor()`, `current_waiting_monitor()`, `_contensions` and `_waiters`.
> At least, I'll try to fix it locally in the `JvmtiEnvBase::get_object_monitor_usage()`.
> Please, let me know what do you prefer.

I don't have a preference (yet). Like what David suggested, I think we need to
determine the list of thread and monitor interaction scenarios that want to
exercise with this API. Once we're happy that those scenarios represent the
complete list of possible combinations we should double check that against the
API spec to make sure that those scenarios cover the API spec. Finally, we need
to make sure that we have a test that covers all those scenarios.

It has been a long, long time since I've looked at those NSK tests... :-(

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1483168890

From kvn at openjdk.org  Thu Feb  8 17:39:04 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 8 Feb 2024 17:39:04 GMT
Subject: RFR: JDK-8325264: two compiler/intrinsics/float16 tests fail after
 JDK-8324724
In-Reply-To: <eoR3U5uw7lee-9UJA2qwsyF9u89D_vW83xykuszAMcU=.f70552a1-d96a-4895-99ac-33dfd0942de2@github.com>
References: <eoR3U5uw7lee-9UJA2qwsyF9u89D_vW83xykuszAMcU=.f70552a1-d96a-4895-99ac-33dfd0942de2@github.com>
Message-ID: <I9V6Oe3fao_AzD7yUPDWTTDlVWm5uXs5v5Weudl6KL8=.ee337305-0352-460f-a778-b20f6bc0e66c@github.com>

On Tue, 6 Feb 2024 14:37:11 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

> Fix for two JTREG test failures on OS_X after this commit - https://github.com/openjdk/jdk/commit/51853f7488afa69c0d14b0e96f1da84822cd83f1.
> 
> This is due to no permission to execute the stub code in the code cache. This patch fixes this problem by acquiring "WXExec" to be able to execute the instructions in code cache.
> 
> Both the tests - compiler/intrinsics/float16/TestAllFloat16ToFloat.java and compiler/intrinsics/float16/Binary16ConversionNaN.java pass on a MacOS machine.

Good.

C2 can call `StubRoutines::f2hf()` and `hf2f()` when the value is constant to get constant value.
Usually C2 executed C++ code from `SharedRuntime` for such cases.
But to get the same result in Interpreter, C1 and C2 I added call to stub  [JDK-8302976](https://bugs.openjdk.org/browse/JDK-8302976).
An other solution would be just remove this optimization so that only compiled code will call these stubs. As I remember this is the only place it is called from runtime code.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17733#pullrequestreview-1870859365

From dcubed at openjdk.org  Thu Feb  8 18:12:06 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 8 Feb 2024 18:12:06 GMT
Subject: RFR: 8319797: Recursive lightweight locking: Runtime
 implementation [v18]
In-Reply-To: <JSwpvtOSOCMkejITJFXnsJGjTMO8NOz7nZk6ck-2I-U=.a582232b-4fd4-474c-9951-17111f7942ed@github.com>
References: <ZWyjRIBdi5FeGTDfaIEmT_lBfg1n9MDl3vxA5g-FKbc=.cb26afcc-555b-4a80-b4f2-319c5422646b@github.com>
 <JSwpvtOSOCMkejITJFXnsJGjTMO8NOz7nZk6ck-2I-U=.a582232b-4fd4-474c-9951-17111f7942ed@github.com>
Message-ID: <vqRt0w65mD7hbGfzu3qocdc2MLhgxauiNTghUm_s9qo=.1b28ab30-1353-4998-89b5-ec8890afd54b@github.com>

On Thu, 8 Feb 2024 10:37:13 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Implements the runtime part of JDK-8319796.
>> The different CPU implementations are/will be created as dependent pull requests.
>> 
>> This enhancement proposes introducing the ability for LM_LIGHTWEIGHT to handle consecutive recursive monitor enter. Limiting the implementation to only consecutive monitor enters allows for more efficient emitted code which only needs to look at the two top most entires on the lock stack to determine what to do in a monitor exit.
>> 
>> A high level overview:
>>   * Locking is still performed on the mark word
>>     * Unlocked (0b01) <=> Locked (0b00)
>>   * Monitor enter on Obj with mark word Unlocked (0b01) is the same
>>     * Transition Obj's mark word Unlocked (0b01) => Locked (0b00)
>>     * Push Obj onto the lock stack
>>     * Success
>>   * Monitor enter on Obj with mark word Locked (0b00) will check the top entry on the lock stack
>>     * If top entry is Obj
>>       * Push Obj on the lock stack
>>       * Success
>>     * If top entry is not Obj
>>       * Inflate and call ObjectMonitor::enter
>>   * Monitor exit on Obj with mark word Locked (0b00) will check the two top entries on the lock stack
>>     * If just the top entry is Obj
>>       * Transition Obj's mark word Locked (0b00) => Unlocked (0b01)
>>       * Pop the entry
>>       * Success
>>     * If both entries are Obj
>>       * Pop the top entry
>>       * Success
>>     * Any other case only occurs for unstructured locking, then just inflate and call ObjectMonitor::exit
>>   * If the monitor has been inflated for object Obj which is owned by the current thread
>>     * All corresponding entries for Obj is removed from the lock stack
>>     * The monitor recursions is set to the number of removed entries - 1
>>     * The owner is changed from anonymous to the thread
>>     * The regular ObjectMonitor::action is called.
>
> 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 54 commits:
> 
>  - Running out of LogTagSets, stick with monitorinflation
>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8319797
>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8319797
>  - Fix assert comment
>  - Update copyright
>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8319797
>  - Add verify calls
>  - Assert valid lock stack offset
>  - Typos, wording and whitespace
>  - Fix miss in is_recursive improvement
>  - ... and 44 more: https://git.openjdk.org/jdk/compare/1fb9e3d6...6f76413d

I last reviewed v15 of this PR so I reviewed the incremental v17.

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

Marked as reviewed by dcubed (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16606#pullrequestreview-1870926645

From dcubed at openjdk.org  Thu Feb  8 18:15:11 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 8 Feb 2024 18:15:11 GMT
Subject: RFR: 8319799: Recursive lightweight locking: x86 implementation
 [v17]
In-Reply-To: <OWYJJ_f9eIo5jWGEHafwGOcN2eTvSCtag4MSo3DNhkQ=.49eebb1a-facd-4a35-9674-82d4800a6bef@github.com>
References: <ymgsUW7sq02C2r82WrLYof5Eb7BB5Lh8M-kGoHx_Zjg=.a5a76651-4931-489f-8ea1-158716614119@github.com>
 <OWYJJ_f9eIo5jWGEHafwGOcN2eTvSCtag4MSo3DNhkQ=.49eebb1a-facd-4a35-9674-82d4800a6bef@github.com>
Message-ID: <qpFdYG2qmOyBhEWtPmMnP8KiOn46LyFdtLhYAliszKQ=.0420edd7-4056-4c56-90c8-9418be657cbd@github.com>

On Thu, 8 Feb 2024 10:43:12 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Implements the x86 port of JDK-8319796.
>> 
>> There are two major parts for the port implementation. The C2 part, and the part shared by the interpreter, C1 and the native call wrapper.
>> 
>> The biggest change for both parts is that we check the lock stack first and if it is a recursive lightweight [un]lock and in that case simply pop/push and finish successfully.
>> 
>> Only if the recursive lightweight [un]lock fails does it look at the mark word. 
>> 
>> For the shared part if it is an unstructured exit, the monitor is inflated or the mark word transition fails it calls into the runtime.
>> 
>> The C2 operates under a few more assumptions, that the locking is structured and balanced. This means that some checks can be elided. 
>> 
>> First this means that in C2 unlock if the obj is not on the top of the lock stack, it must be inflated. And reversely if we reach the inflated C2 unlock the obj is not on the lock stack. This second property makes it possible to avoid reading the owner (and checking if it is anonymous). Instead it can either just do an un-contended unlock by writing null to the owner, or if contention happens, simply write the thread to the owner and jump to the runtime. 
>> 
>> The x86 C2 port also has some extra oddities. 
>> 
>> The mark word read is done early as it showed better scaling in hyper-threaded scenarios on certain intel hardware, and no noticeable downside on other tested x86 hardware. 
>> 
>> The fast path is written to avoid going through conditional branches. This in combination with keeping the ZF output correct, the code does some actions eagerly, decrementing the held monitor count, popping from the lock stack. And jumps to a code stub if a slow path is required which restores the thread local state to a correct state before jumping to the runtime.
>> 
>> The contended unlock was also moved to the code stub.
>
> Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 27 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319799
>  - Comment indent
>  - Update copyright years
>  - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319799
>  - Update MacroAssembler::lightweight_unlock comments.
>  - Update comments and asserts
>  - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319799
>  - Update variable names in ad files
>  - Preload markWord unconditionally
>  - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319799
>  - ... and 17 more: https://git.openjdk.org/jdk/compare/49249b63...41bac421

I last reviewed v14 of this PR so I reviewed the incremental v16.

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

Marked as reviewed by dcubed (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16607#pullrequestreview-1870931985

From dcubed at openjdk.org  Thu Feb  8 18:19:07 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 8 Feb 2024 18:19:07 GMT
Subject: RFR: 8319801: Recursive lightweight locking: aarch64
 implementation [v14]
In-Reply-To: <iC92w1y38RpuDCYuxFHV85skIW6MeGeXy_bMUvG8eFQ=.be791bcf-d426-44a6-b984-01d16a4fed4c@github.com>
References: <AE1nsnyRCUHR970jjg4feUm5f6E1GPJvea0ooC6dCgI=.73fff610-c0f6-422a-a45d-88187b37b9a2@github.com>
 <iC92w1y38RpuDCYuxFHV85skIW6MeGeXy_bMUvG8eFQ=.be791bcf-d426-44a6-b984-01d16a4fed4c@github.com>
Message-ID: <xfDNf_lHfJRbqeOc4G2_Pt-h9Zvo0OSqnJsVR_Xl7tw=.7e5262a3-b185-4bd5-8042-e01bb6fc33a4@github.com>

On Thu, 8 Feb 2024 10:44:14 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Implements the aarch64 port of JDK-8319796.
>> 
>> There are two major parts for the port implementation. The C2 part, and the part shared by the interpreter, C1 and the native call wrapper.
>> 
>> The biggest change for both parts is that we check the lock stack first and if it is a recursive lightweight [un]lock and in that case simply pop/push and finish successfully.
>> 
>> Only if the recursive lightweight [un]lock fails does it look at the mark word. 
>> 
>> For the shared part if it is an unstructured exit, the monitor is inflated or the mark word transition fails it calls into the runtime.
>> 
>> The C2 operates under a few more assumptions, that the locking is structured and balanced. This means that some checks can be elided. 
>> 
>> First this means that in C2 unlock if the obj is not on the top of the lock stack, it must be inflated. And reversely if we reach the inflated C2 unlock the obj is not on the lock stack. This second property makes it possible to avoid reading the owner (and checking if it is anonymous). Instead it can either just do an un-contended unlock by writing null to the owner, or if contention happens, simply write the thread to the owner and jump to the runtime. 
>> 
>> The aarch64 C2 port tries to avoid stronger memory semantics where ever possible. In C2 lock it first does a relaxed load of the mark word to check for inflation. Both lock and unlock uses a load/store exclusive register pair to transition the mark word.
>
> Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 23 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319801
>  - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319801
>  - Update src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp
>    
>    Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>
>  - Clarify the rscratch1 assert
>  - Comments and nits
>  - Update copyright years
>  - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319801
>  - Drop memory order comments
>  - Preloads markWord unconditionally
>  - Revert "Add preload_mark to MacroAssembler::lightweight_lock"
>    
>    This reverts commit 8950f503aa5dba0e203613bd9737ea0d50388ca3.
>  - ... and 13 more: https://git.openjdk.org/jdk/compare/a3a66e5c...9b9e1927

I last reviewed v10 of this PR so I reviewed the incremental v13.

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

Marked as reviewed by dcubed (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16608#pullrequestreview-1870939959

From bkilambi at openjdk.org  Thu Feb  8 20:37:07 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Thu, 8 Feb 2024 20:37:07 GMT
Subject: RFR: JDK-8325264: two compiler/intrinsics/float16 tests fail after
 JDK-8324724 [v2]
In-Reply-To: <eoR3U5uw7lee-9UJA2qwsyF9u89D_vW83xykuszAMcU=.f70552a1-d96a-4895-99ac-33dfd0942de2@github.com>
References: <eoR3U5uw7lee-9UJA2qwsyF9u89D_vW83xykuszAMcU=.f70552a1-d96a-4895-99ac-33dfd0942de2@github.com>
Message-ID: <LnFMyXzIC9apHPZ4tmsza3ZLspxrTnMBxkATW53OPMg=.46eb6dd2-7cdf-411f-9ea5-edea24b5fefd@github.com>

> Fix for two JTREG test failures on OS_X after this commit - https://github.com/openjdk/jdk/commit/51853f7488afa69c0d14b0e96f1da84822cd83f1.
> 
> This is due to no permission to execute the stub code in the code cache. This patch fixes this problem by acquiring "WXExec" to be able to execute the instructions in code cache.
> 
> Both the tests - compiler/intrinsics/float16/TestAllFloat16ToFloat.java and compiler/intrinsics/float16/Binary16ConversionNaN.java pass on a MacOS machine.

Bhavana Kilambi has updated the pull request incrementally with one additional commit since the last revision:

  Make assert the first statement in the function

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17733/files
  - new: https://git.openjdk.org/jdk/pull/17733/files/affabc19..36e121c0

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

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

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

From bkilambi at openjdk.org  Thu Feb  8 20:37:08 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Thu, 8 Feb 2024 20:37:08 GMT
Subject: RFR: JDK-8325264: two compiler/intrinsics/float16 tests fail after
 JDK-8324724 [v2]
In-Reply-To: <d6aCSQ6ivkgfAQ5pnSNXHIOlZz6GtIiski002-T3cus=.ec07eee9-0712-4bc4-a79a-fdb2ee371f89@github.com>
References: <eoR3U5uw7lee-9UJA2qwsyF9u89D_vW83xykuszAMcU=.f70552a1-d96a-4895-99ac-33dfd0942de2@github.com>
 <M0rTewgJ5HXWlAysDqYk-KiFyZzmweHXLGR_0nfGlTA=.4e0bff92-5547-4e0f-9cc1-6a0f4de24d52@github.com>
 <d6aCSQ6ivkgfAQ5pnSNXHIOlZz6GtIiski002-T3cus=.ec07eee9-0712-4bc4-a79a-fdb2ee371f89@github.com>
Message-ID: <cTz7hj1-Fla4UhtOdC-UuPvWYckBKJ8MlljpQeM74jo=.28cfdcc6-6c9b-4a01-83b0-c10424dbbd09@github.com>

On Thu, 8 Feb 2024 11:04:51 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

>> src/hotspot/share/runtime/stubRoutines.hpp line 457:
>> 
>>> 455:   static jshort f2hf(jfloat x) {
>>> 456:     MACOS_AARCH64_ONLY(ThreadWXEnable wx(WXExec, Thread::current());) // About to call into code cache
>>> 457:     assert(_f2hf != nullptr, "stub is not implemented on this platform");
>> 
>> Would it make sense to have the assert as first thing in the method?
>
> Yes, probably a better idea to make sure the address (of the stub) being accessed is valid before making that memory region executable. Will make changes and update. Thanks!

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17733#discussion_r1483560838

From bkilambi at openjdk.org  Thu Feb  8 20:37:08 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Thu, 8 Feb 2024 20:37:08 GMT
Subject: RFR: JDK-8325264: two compiler/intrinsics/float16 tests fail after
 JDK-8324724 [v2]
In-Reply-To: <M0rTewgJ5HXWlAysDqYk-KiFyZzmweHXLGR_0nfGlTA=.4e0bff92-5547-4e0f-9cc1-6a0f4de24d52@github.com>
References: <eoR3U5uw7lee-9UJA2qwsyF9u89D_vW83xykuszAMcU=.f70552a1-d96a-4895-99ac-33dfd0942de2@github.com>
 <M0rTewgJ5HXWlAysDqYk-KiFyZzmweHXLGR_0nfGlTA=.4e0bff92-5547-4e0f-9cc1-6a0f4de24d52@github.com>
Message-ID: <x_-fktUb11AajvGgBL4Sb9TgTsPuAmvPb3oKYVg_6bY=.e0652ba4-a3c7-4651-ae38-694968f43644@github.com>

On Thu, 8 Feb 2024 10:32:35 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> Bhavana Kilambi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make assert the first statement in the function
>
> src/hotspot/share/runtime/stubRoutines.hpp line 463:
> 
>> 461:   static jfloat hf2f(jshort x) {
>> 462:     MACOS_AARCH64_ONLY(ThreadWXEnable wx(WXExec, Thread::current());) // About to call into code cache
>> 463:     assert(_hf2f != nullptr, "stub is not implemented on this platform");
> 
> Same here?

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17733#discussion_r1483560754

From dfenacci at openjdk.org  Thu Feb  8 20:54:03 2024
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Thu, 8 Feb 2024 20:54:03 GMT
Subject: RFR: JDK-8325264: two compiler/intrinsics/float16 tests fail after
 JDK-8324724 [v2]
In-Reply-To: <LnFMyXzIC9apHPZ4tmsza3ZLspxrTnMBxkATW53OPMg=.46eb6dd2-7cdf-411f-9ea5-edea24b5fefd@github.com>
References: <eoR3U5uw7lee-9UJA2qwsyF9u89D_vW83xykuszAMcU=.f70552a1-d96a-4895-99ac-33dfd0942de2@github.com>
 <LnFMyXzIC9apHPZ4tmsza3ZLspxrTnMBxkATW53OPMg=.46eb6dd2-7cdf-411f-9ea5-edea24b5fefd@github.com>
Message-ID: <3Xd4wVkhysNTkwjiDmPN0GwdTdve_B6wlqcdDP9QxP8=.29c1457e-4f2a-4ed4-afe6-c3baf9c7d7e8@github.com>

On Thu, 8 Feb 2024 20:37:07 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

>> Fix for two JTREG test failures on OS_X after this commit - https://github.com/openjdk/jdk/commit/51853f7488afa69c0d14b0e96f1da84822cd83f1.
>> 
>> This is due to no permission to execute the stub code in the code cache. This patch fixes this problem by acquiring "WXExec" to be able to execute the instructions in code cache.
>> 
>> Both the tests - compiler/intrinsics/float16/TestAllFloat16ToFloat.java and compiler/intrinsics/float16/Binary16ConversionNaN.java pass on a MacOS machine.
>
> Bhavana Kilambi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make assert the first statement in the function

Marked as reviewed by dfenacci (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/17733#pullrequestreview-1871235047

From dlong at openjdk.org  Thu Feb  8 21:27:07 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 8 Feb 2024 21:27:07 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v6]
In-Reply-To: <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
Message-ID: <8HWf9TJDmMH3OM8EfOn2joR2-CnOtzaawAfuOQigB6w=.9c0489a9-79e8-43e1-b274-2c7f48b8c95b@github.com>

On Tue, 30 Jan 2024 09:08:01 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> ICStubs solve an atomicity problem when setting both the destination and data of an inline cache. Unfortunately, it also leads to occasional safepoint carpets when multiple threads need to ICRefill the stubs at the same time, and spurious GuaranteedSafepointInterval "Cleanup" safepoints every second. This patch changes inline caches to not change the data part at all during the nmethod life cycle, hence removing the need for ICStubs.
>> 
>> The new scheme is less stateful. Instead of adding and removing callsite metadata back and forth when transitioning inline cache states, it installs all state any shape of call will ever need at resolution time in a struct that I call CompiledICData. This reduces inline cache state changes to simply changing the destination of the call, and it doesn't really matter what state transitions to what other state.
>> 
>> With this patch, we get rid of ICStub and ICBuffer classes and the related ICRefill and almost all Cleanup safepoints in practice. It also makes the inline cache code much simpler.
>> 
>> I have tested the changes from tier1-7, and run through full aurora performance tests.
>
> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ARM32 fixes

src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 770:

> 768:     // Method might have been compiled since the call site was patched to
> 769:     // interpreted; if that is the case treat it as a miss so we can get
> 770:     // the call site corrected.

This comment is still relevant, isn't it?

src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 1555:

> 1553:   __ far_jump(RuntimeAddress(SharedRuntime::get_ic_miss_stub()));
> 1554: 
> 1555:   // Verified entry point must be aligned

Keep this comment?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1483603879
PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1483607156

From dlong at openjdk.org  Thu Feb  8 21:30:59 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 8 Feb 2024 21:30:59 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v6]
In-Reply-To: <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
Message-ID: <KDviofJEEAHQEsPZe-pHNA2Yq9Af88SCHis4qDJDTqM=.876ae44e-9cff-4ec6-89d1-8f6c376bbd42@github.com>

On Tue, 30 Jan 2024 09:08:01 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> ICStubs solve an atomicity problem when setting both the destination and data of an inline cache. Unfortunately, it also leads to occasional safepoint carpets when multiple threads need to ICRefill the stubs at the same time, and spurious GuaranteedSafepointInterval "Cleanup" safepoints every second. This patch changes inline caches to not change the data part at all during the nmethod life cycle, hence removing the need for ICStubs.
>> 
>> The new scheme is less stateful. Instead of adding and removing callsite metadata back and forth when transitioning inline cache states, it installs all state any shape of call will ever need at resolution time in a struct that I call CompiledICData. This reduces inline cache state changes to simply changing the destination of the call, and it doesn't really matter what state transitions to what other state.
>> 
>> With this patch, we get rid of ICStub and ICBuffer classes and the related ICRefill and almost all Cleanup safepoints in practice. It also makes the inline cache code much simpler.
>> 
>> I have tested the changes from tier1-7, and run through full aurora performance tests.
>
> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ARM32 fixes

src/hotspot/cpu/arm/arm.ad line 880:

> 878: void MachUEPNode::emit(CodeBuffer &cbuf, PhaseRegAlloc *ra_) const {
> 879:   C2_MacroAssembler _masm(&cbuf);
> 880:   __ ic_check(CodeEntryAlignment);

Do we care about CodeEntryAlignment here if the old code didn't?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1483610763

From dlong at openjdk.org  Thu Feb  8 21:35:01 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 8 Feb 2024 21:35:01 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v6]
In-Reply-To: <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
Message-ID: <04ntORhQBIEdsks9kJSNyR2iqdsTfwmAFWG36z5ilOo=.6b91fe2f-3573-4e31-97fb-62ead3720487@github.com>

On Tue, 30 Jan 2024 09:08:01 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> ICStubs solve an atomicity problem when setting both the destination and data of an inline cache. Unfortunately, it also leads to occasional safepoint carpets when multiple threads need to ICRefill the stubs at the same time, and spurious GuaranteedSafepointInterval "Cleanup" safepoints every second. This patch changes inline caches to not change the data part at all during the nmethod life cycle, hence removing the need for ICStubs.
>> 
>> The new scheme is less stateful. Instead of adding and removing callsite metadata back and forth when transitioning inline cache states, it installs all state any shape of call will ever need at resolution time in a struct that I call CompiledICData. This reduces inline cache state changes to simply changing the destination of the call, and it doesn't really matter what state transitions to what other state.
>> 
>> With this patch, we get rid of ICStub and ICBuffer classes and the related ICRefill and almost all Cleanup safepoints in practice. It also makes the inline cache code much simpler.
>> 
>> I have tested the changes from tier1-7, and run through full aurora performance tests.
>
> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ARM32 fixes

src/hotspot/cpu/arm/sharedRuntime_arm.cpp line 831:

> 829:   __ jump(SharedRuntime::get_ic_miss_stub(), relocInfo::runtime_call_type, Rtemp);
> 830:   __ align(CodeEntryAlignment);
> 831: 

Keep the CodeEntryAlignment and VEP comment?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1483614619

From dlong at openjdk.org  Thu Feb  8 21:41:00 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 8 Feb 2024 21:41:00 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v6]
In-Reply-To: <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
Message-ID: <0fQX2S37e-tHVt-IwRk8X95k0JYUmsBYr37oobhIagc=.92e45b75-b673-4022-b752-6359ee672976@github.com>

On Tue, 30 Jan 2024 09:08:01 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> ICStubs solve an atomicity problem when setting both the destination and data of an inline cache. Unfortunately, it also leads to occasional safepoint carpets when multiple threads need to ICRefill the stubs at the same time, and spurious GuaranteedSafepointInterval "Cleanup" safepoints every second. This patch changes inline caches to not change the data part at all during the nmethod life cycle, hence removing the need for ICStubs.
>> 
>> The new scheme is less stateful. Instead of adding and removing callsite metadata back and forth when transitioning inline cache states, it installs all state any shape of call will ever need at resolution time in a struct that I call CompiledICData. This reduces inline cache state changes to simply changing the destination of the call, and it doesn't really matter what state transitions to what other state.
>> 
>> With this patch, we get rid of ICStub and ICBuffer classes and the related ICRefill and almost all Cleanup safepoints in practice. It also makes the inline cache code much simpler.
>> 
>> I have tested the changes from tier1-7, and run through full aurora performance tests.
>
> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ARM32 fixes

src/hotspot/cpu/x86/macroAssembler_x86.cpp line 1360:

> 1358:   Register data = rax;
> 1359:   Register temp = LP64_ONLY(rscratch1) NOT_LP64(rbx);
> 1360: 

It would be nice if VerifyOops check could be added back, maybe as a follow-up RFE?

src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp line 1463:

> 1461:   __ jump(RuntimeAddress(SharedRuntime::get_ic_miss_stub()));
> 1462: 
> 1463:   // verified entry must be aligned for code patching.

This comment still seems relevant.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1483619612
PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1483621209

From dlong at openjdk.org  Thu Feb  8 21:44:05 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 8 Feb 2024 21:44:05 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v6]
In-Reply-To: <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
Message-ID: <J5Cbpc9h-GU9mkrECwDXl-Ubf13AcMU7vUAI-E-jLxk=.af60b540-94ec-4e49-a7b8-45cd13b46e4d@github.com>

On Tue, 30 Jan 2024 09:08:01 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> ICStubs solve an atomicity problem when setting both the destination and data of an inline cache. Unfortunately, it also leads to occasional safepoint carpets when multiple threads need to ICRefill the stubs at the same time, and spurious GuaranteedSafepointInterval "Cleanup" safepoints every second. This patch changes inline caches to not change the data part at all during the nmethod life cycle, hence removing the need for ICStubs.
>> 
>> The new scheme is less stateful. Instead of adding and removing callsite metadata back and forth when transitioning inline cache states, it installs all state any shape of call will ever need at resolution time in a struct that I call CompiledICData. This reduces inline cache state changes to simply changing the destination of the call, and it doesn't really matter what state transitions to what other state.
>> 
>> With this patch, we get rid of ICStub and ICBuffer classes and the related ICRefill and almost all Cleanup safepoints in practice. It also makes the inline cache code much simpler.
>> 
>> I have tested the changes from tier1-7, and run through full aurora performance tests.
>
> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ARM32 fixes

src/hotspot/cpu/x86/x86_32.ad line 1386:

> 1384: void MachUEPNode::emit(CodeBuffer &cbuf, PhaseRegAlloc *ra_) const {
> 1385:   MacroAssembler masm(&cbuf);
> 1386:   masm.ic_check(CodeEntryAlignment);

I think there may still be a problem with OptoBreakpoint messing up the alignment.  I'll try to reproduce it on x64.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1483623693

From dlong at openjdk.org  Thu Feb  8 21:47:08 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 8 Feb 2024 21:47:08 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v6]
In-Reply-To: <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
Message-ID: <4Xcj3NXRRxEvGn3fIVpGYlZ5vCwyx7mdxaAEQ5myKKo=.aa1309ef-5289-476b-a285-306b307e1b85@github.com>

On Tue, 30 Jan 2024 09:08:01 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> ICStubs solve an atomicity problem when setting both the destination and data of an inline cache. Unfortunately, it also leads to occasional safepoint carpets when multiple threads need to ICRefill the stubs at the same time, and spurious GuaranteedSafepointInterval "Cleanup" safepoints every second. This patch changes inline caches to not change the data part at all during the nmethod life cycle, hence removing the need for ICStubs.
>> 
>> The new scheme is less stateful. Instead of adding and removing callsite metadata back and forth when transitioning inline cache states, it installs all state any shape of call will ever need at resolution time in a struct that I call CompiledICData. This reduces inline cache state changes to simply changing the destination of the call, and it doesn't really matter what state transitions to what other state.
>> 
>> With this patch, we get rid of ICStub and ICBuffer classes and the related ICRefill and almost all Cleanup safepoints in practice. It also makes the inline cache code much simpler.
>> 
>> I have tested the changes from tier1-7, and run through full aurora performance tests.
>
> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ARM32 fixes

src/hotspot/cpu/x86/x86_64.ad line 1487:

> 1485: {
> 1486:   MacroAssembler masm(&cbuf);
> 1487:   masm.ic_check(CodeEntryAlignment);

I'm concerned about OptoBreakpoint and friends messing up the alignment:
https://github.com/openjdk/jdk/blob/10beb3184e14e2714cd836029680a8b2d3fd5011/src/hotspot/share/opto/output.cpp#L317

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1483626164

From dlong at openjdk.org  Thu Feb  8 21:57:09 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 8 Feb 2024 21:57:09 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v6]
In-Reply-To: <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
Message-ID: <fIN-0H5pYnJdae6vqQxlpGQPg5t_VvYmooG1RpHuN10=.fdbcb251-227b-4d10-b5fc-8ddc9ffeb317@github.com>

On Tue, 30 Jan 2024 09:08:01 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> ICStubs solve an atomicity problem when setting both the destination and data of an inline cache. Unfortunately, it also leads to occasional safepoint carpets when multiple threads need to ICRefill the stubs at the same time, and spurious GuaranteedSafepointInterval "Cleanup" safepoints every second. This patch changes inline caches to not change the data part at all during the nmethod life cycle, hence removing the need for ICStubs.
>> 
>> The new scheme is less stateful. Instead of adding and removing callsite metadata back and forth when transitioning inline cache states, it installs all state any shape of call will ever need at resolution time in a struct that I call CompiledICData. This reduces inline cache state changes to simply changing the destination of the call, and it doesn't really matter what state transitions to what other state.
>> 
>> With this patch, we get rid of ICStub and ICBuffer classes and the related ICRefill and almost all Cleanup safepoints in practice. It also makes the inline cache code much simpler.
>> 
>> I have tested the changes from tier1-7, and run through full aurora performance tests.
>
> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ARM32 fixes

src/hotspot/share/c1/c1_LIRAssembler.cpp line 612:

> 610:       // init offsets
> 611:       offsets()->set_value(CodeOffsets::OSR_Entry, _masm->offset());
> 612:       _masm->align(CodeEntryAlignment);

So we used to unconditionally align here, but never set CodeOffsets::Entry, meaning we got the default offset of 0 and the entry had to execute the alignment NOPs.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1483634924

From pchilanomate at openjdk.org  Thu Feb  8 22:44:09 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 8 Feb 2024 22:44:09 GMT
Subject: RFR: 8320302: compiler/arguments/TestC1Globals.java hits SIGSEGV
 in ContinuationEntry::set_enter_code [v4]
In-Reply-To: <1Cm1SGGaZsYxM-RfPNDeAvnGijQ-taVe438SS6bZ3YI=.d64abde2-f9a0-4589-ab40-eba7c3c02992@github.com>
References: <1Cm1SGGaZsYxM-RfPNDeAvnGijQ-taVe438SS6bZ3YI=.d64abde2-f9a0-4589-ab40-eba7c3c02992@github.com>
Message-ID: <k9rz95AmHObnxGOmcjA6pt5fcOERxeXlgEUvxTr3LhI=.177371e9-3625-40af-9744-c7da29f1a592@github.com>

> When creating Continuation.enterSpecial/doYield special native nmethods we currently assume the call to nmethod::new_native_nmethod() always succeeds. If the CodeCache happens to be full though, creating the nmethod will fail and we'll hit a SIGSEGV when trying to dereference the return value. 
> 
> Since this happens the first time those methods are resolved, throwing an exception at that point implying that we cannot run virtual threads looks odd from a user perspective. So instead I added a step to initialize the Continuation class at startup so that failure to create those nmethods is treated early as a fatal error as we do with any other critical resource needed by the VM. I measured the added step to the startup sequence to be ~90us, or about 0.3% of the total?startup time.
> 
> I verified the fix by running the test mentioned in the bug plus I also run tiers1-5 in mach5.
> 
> Thanks,
> Patricio

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  Throw OOM from link_method()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17455/files
  - new: https://git.openjdk.org/jdk/pull/17455/files/3c96d8ae..438bd71c

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

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

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

From pchilanomate at openjdk.org  Thu Feb  8 22:44:09 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 8 Feb 2024 22:44:09 GMT
Subject: RFR: 8320302: compiler/arguments/TestC1Globals.java hits SIGSEGV
 in ContinuationEntry::set_enter_code [v3]
In-Reply-To: <daJ-h7P1tSdc_sU9-27BWIMwIo066F_UNvx6j-sUyoI=.b331badc-f0bb-49a6-af8a-a19745c96034@github.com>
References: <1Cm1SGGaZsYxM-RfPNDeAvnGijQ-taVe438SS6bZ3YI=.d64abde2-f9a0-4589-ab40-eba7c3c02992@github.com>
 <9mMLOqVHnFrYcKY5FLgIwd_j9RQtk68s9vdqaABGt_o=.bd743e24-484e-4120-9be3-a81f7022d332@github.com>
 <6eYoo4WQi_LO5YFtxZQbpxFeNxQFnpTjgfIvyPukWNA=.1448ac51-5e4a-43f3-ae17-aa5eeeee0538@github.com>
 <mYespY0oqvVFcx468YZJ80YqCSnEuk3FAz-W839Q4qM=.df0dcd66-543e-4039-bc24-6e809cf4b381@github.com>
 <daJ-h7P1tSdc_sU9-27BWIMwIo066F_UNvx6j-sUyoI=.b331badc-f0bb-49a6-af8a-a19745c96034@github.com>
Message-ID: <BsBiZE47TiqYr5cL4go-CsGdXx7Po8k7msa3ofoHUBw=.fbba54d3-750e-4d34-8e0c-4002dbb97e1e@github.com>

On Thu, 8 Feb 2024 06:25:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> We could do that too. We have to check for nullptr && method->is_continuation_native_intrinsic() since AdapterHandlerLibrary::create_native_wrapper() itself is called from 2 other places which should not fail with vm_exit_during_initialization() if creation of the native nmethod failed. I don't have a preference, both ways are fine with me.
>
> Sorry for the delay. I've been looking at the proposed initialization sequence:
> 
> Threads::create_vm
>   initialize_class(vmSymbols::jdk_internal_vm_Continuation(), CHECK
>     // causes linking of Continuation
>     InstanceKlass::link_class_impl(TRAPS)
>       InstanceKlass::link_methods(TRAPS)
>         Method::link_method(mh, TRAPS)
>           AdapterHandlerLibrary::create_native_wrapper
>             SharedRuntime::generate_native_wrapper
> 
> and it seems to me that if `generate_native_wrapper` returns null then `create_native_wrapper` can check for that and also return early. Then `link_method` can do what other callers of `create_native_wrapper` do and simply check the resulting method and throw an exception:
> 
> if (!h_method->has_compiled_code()) {
>   // throw OOME
> }
> 
> that exception will propagate up and terminate the VM the same as any other exception during vm init would.
> 
> What do you think?

Yes, I like that approach. I changed it in the last commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17455#discussion_r1483672643

From qpzhang at openjdk.org  Thu Feb  8 22:52:57 2024
From: qpzhang at openjdk.org (Patrick Zhang)
Date: Thu, 8 Feb 2024 22:52:57 GMT
Subject: Integrated: 8324824: AArch64: Detect Ampere-1B core and update default
 options for Ampere CPUs
In-Reply-To: <N9ZCzxRwamt4YTT5wNJottgQ7FYJX4SQrrFxv11Ramg=.4881b622-6d73-4c12-beb3-d65ce465f076@github.com>
References: <N9ZCzxRwamt4YTT5wNJottgQ7FYJX4SQrrFxv11Ramg=.4881b622-6d73-4c12-beb3-d65ce465f076@github.com>
Message-ID: <AuvLgVkZXm7ZwCyBhHtsA_Ej5nhGo95kiSdu-LS84nc=.eeb4f4a1-be36-4acb-8e3e-1386c7b91863@github.com>

On Tue, 6 Feb 2024 07:13:22 GMT, Patrick Zhang <qpzhang at openjdk.org> wrote:

> Added CPU detection for Ampere-1B, and updated the default options for AmpereOne, Ampere-1A/1B to have `-XX:+UseSIMDForMemoryOps` and `-XX:OnSpinWaitInst=isb -XX:OnSpinWaitInstCount=2`.
> 
> Tests done:
> 1. GitHub Actions (GHA) sanity tests: https://github.com/cnqpzhang/jdk/actions/runs/7786881426
> 2. OpenJDK bundled JMH, `make run-test TEST="jtreg:hotspot/jtreg/compiler/onSpinWait*"` , `make run-test TEST="micro:ThreadOnSpinWait*"`, no issue found, and `ThreadOnSpinWaitProducerConsumer.trial` showed ~3x better scores (us/op).
> 3. Jtreg tier1/tier2 sanity check on AmpereOne AArch64 platforms, Ampere-1A systems as well, no new issues found.
> 
> Signed-off-by: Patrick Zhang [patrick at os.amperecomputing.com](mailto:patrick at os.amperecomputing.com)

This pull request has now been integrated.

Changeset: 9936aeea
Author:    Patrick Zhang <qpzhang at openjdk.org>
Committer: Dean Long <dlong at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9936aeea32b71509151099e6d28905e0322b2bc2
Stats:     12 lines in 2 files changed: 9 ins; 0 del; 3 mod

8324824: AArch64: Detect Ampere-1B core and update default options for Ampere CPUs

Reviewed-by: dlong, thartmann

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

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

From dlong at openjdk.org  Fri Feb  9 00:56:02 2024
From: dlong at openjdk.org (Dean Long)
Date: Fri, 9 Feb 2024 00:56:02 GMT
Subject: RFR: 8323273: AArch64: Strengthen CompressedClassPointers
 initialization check for base
In-Reply-To: <Unuzwz0YLo2jvmvcYOF3tjDI7Tr4PuoU3vedUfdUrmA=.914474fb-292f-4eeb-a82b-b3a858ab65d0@github.com>
References: <Unuzwz0YLo2jvmvcYOF3tjDI7Tr4PuoU3vedUfdUrmA=.914474fb-292f-4eeb-a82b-b3a858ab65d0@github.com>
Message-ID: <_DT-mZ1o7jeRQ2Us-Bxv4yCjoQDimd73AH3EdVj7PuE=.e40314fb-1a11-43e1-b9bd-2c8bb537ac81@github.com>

On Tue, 16 Jan 2024 02:41:40 GMT, Yude Lin <duke at openjdk.org> wrote:

> Summary:
> Add a platform-dependent check for CompressedClassSpaceBaseAddress;
> Remove the "reserve anywhere" attempt after the initial mapping attempt failed---this is rarely used and will likely fail anyway, because the accepted mapping is very restricted on aarch64;
> Additional assertions after initialization.
> 
> Passed hotspot/jtreg/:tier1 on fastdebug

Don't you want to add a constraint function to CompressedClassSpaceBaseAddress in globals.hpp so invalid values are rejected during command-line parsing?

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

PR Comment: https://git.openjdk.org/jdk/pull/17437#issuecomment-1935162658

From dholmes at openjdk.org  Fri Feb  9 01:32:05 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 9 Feb 2024 01:32:05 GMT
Subject: RFR: 8320302: compiler/arguments/TestC1Globals.java hits SIGSEGV
 in ContinuationEntry::set_enter_code [v4]
In-Reply-To: <k9rz95AmHObnxGOmcjA6pt5fcOERxeXlgEUvxTr3LhI=.177371e9-3625-40af-9744-c7da29f1a592@github.com>
References: <1Cm1SGGaZsYxM-RfPNDeAvnGijQ-taVe438SS6bZ3YI=.d64abde2-f9a0-4589-ab40-eba7c3c02992@github.com>
 <k9rz95AmHObnxGOmcjA6pt5fcOERxeXlgEUvxTr3LhI=.177371e9-3625-40af-9744-c7da29f1a592@github.com>
Message-ID: <8lAV3bUyswP_pz_cay_j36xaLOA3exFrPXXBnFGbxyI=.b6e10049-1748-41e2-891b-d7046eea05dc@github.com>

On Thu, 8 Feb 2024 22:44:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> When creating Continuation.enterSpecial/doYield special native nmethods we currently assume the call to nmethod::new_native_nmethod() always succeeds. If the CodeCache happens to be full though, creating the nmethod will fail and we'll hit a SIGSEGV when trying to dereference the return value. 
>> 
>> Since this happens the first time those methods are resolved, throwing an exception at that point implying that we cannot run virtual threads looks odd from a user perspective. So instead I added a step to initialize the Continuation class at startup so that failure to create those nmethods is treated early as a fatal error as we do with any other critical resource needed by the VM. I measured the added step to the startup sequence to be ~90us, or about 0.3% of the total?startup time.
>> 
>> I verified the fix by running the test mentioned in the bug plus I also run tiers1-5 in mach5.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Throw OOM from link_method()

That looks much simpler/cleaner - thanks!

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17455#pullrequestreview-1871537277

From dlong at openjdk.org  Fri Feb  9 01:34:00 2024
From: dlong at openjdk.org (Dean Long)
Date: Fri, 9 Feb 2024 01:34:00 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v6]
In-Reply-To: <4Xcj3NXRRxEvGn3fIVpGYlZ5vCwyx7mdxaAEQ5myKKo=.aa1309ef-5289-476b-a285-306b307e1b85@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
 <4Xcj3NXRRxEvGn3fIVpGYlZ5vCwyx7mdxaAEQ5myKKo=.aa1309ef-5289-476b-a285-306b307e1b85@github.com>
Message-ID: <TXLIdVrjfirk92Nb6kjy0SsH0i-dGXQK4BypJnTAQjg=.0430a7f0-89a8-4ad6-8bd6-e51a3935d6e9@github.com>

On Thu, 8 Feb 2024 21:44:14 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   ARM32 fixes
>
> src/hotspot/cpu/x86/x86_64.ad line 1487:
> 
>> 1485: {
>> 1486:   MacroAssembler masm(&cbuf);
>> 1487:   masm.ic_check(CodeEntryAlignment);
> 
> I'm concerned about OptoBreakpoint and friends messing up the alignment:
> https://github.com/openjdk/jdk/blob/10beb3184e14e2714cd836029680a8b2d3fd5011/src/hotspot/share/opto/output.cpp#L317

It's fine, the breakpoint is insert *after* the prologue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1483776166

From dlong at openjdk.org  Fri Feb  9 01:41:06 2024
From: dlong at openjdk.org (Dean Long)
Date: Fri, 9 Feb 2024 01:41:06 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v6]
In-Reply-To: <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
Message-ID: <bHqPPuoq-BrRroH1icXNvwPEE8saqB35Avr_ovfpLG0=.025040ee-b3c7-4e5b-8574-2758ba7bc889@github.com>

On Tue, 30 Jan 2024 09:08:01 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> ICStubs solve an atomicity problem when setting both the destination and data of an inline cache. Unfortunately, it also leads to occasional safepoint carpets when multiple threads need to ICRefill the stubs at the same time, and spurious GuaranteedSafepointInterval "Cleanup" safepoints every second. This patch changes inline caches to not change the data part at all during the nmethod life cycle, hence removing the need for ICStubs.
>> 
>> The new scheme is less stateful. Instead of adding and removing callsite metadata back and forth when transitioning inline cache states, it installs all state any shape of call will ever need at resolution time in a struct that I call CompiledICData. This reduces inline cache state changes to simply changing the destination of the call, and it doesn't really matter what state transitions to what other state.
>> 
>> With this patch, we get rid of ICStub and ICBuffer classes and the related ICRefill and almost all Cleanup safepoints in practice. It also makes the inline cache code much simpler.
>> 
>> I have tested the changes from tier1-7, and run through full aurora performance tests.
>
> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ARM32 fixes

src/hotspot/share/runtime/vmStructs.cpp line 217:

> 215:   volatile_nonstatic_field(CompiledICData,     _speculated_klass,                             uintptr_t)                             \
> 216:   nonstatic_field(CompiledICData,              _itable_defc_klass,                            Klass*)                                \
> 217:   nonstatic_field(CompiledICData,              _itable_refc_klass,                            Klass*)                                \

I don't think it makes sense to export these fields and types until SA is changed to make use of them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1483780505

From lmesnik at openjdk.org  Fri Feb  9 02:37:02 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 9 Feb 2024 02:37:02 GMT
Subject: RFR: JDK-8311076: RedefineClasses doesn't check for ConstantPool
 overflow
In-Reply-To: <Z_Hq-oct8XO3DtKivbPa-5VbLjLhPiXjSMJfrupUA5U=.ecd68153-3b48-44c0-a06f-c791e334ca6f@github.com>
References: <Z_Hq-oct8XO3DtKivbPa-5VbLjLhPiXjSMJfrupUA5U=.ecd68153-3b48-44c0-a06f-c791e334ca6f@github.com>
Message-ID: <gAJNOQxXwpSo38srrI1H39LMHfNXW1Q5xpDRDFaiNvk=.904bd1d4-8a38-4a35-9cfa-d8c28d77101e@github.com>

On Wed, 7 Feb 2024 20:53:53 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix adds check that merged constant pool does not overflow u2 (two-byte unsigned).
> The check is added after merging `the_class` and `scratch_class` constant pools, but before rewriting constant pool references.
> 
> testing:
>  - sanity tier1;
>  - all RedefineClasses/RetransformClasses tests:
>    - test/jdk/java/lang/instrument
>    - test/hotspot/jtreg/serviceability/jvmti/RedefineClasses
>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses
>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses

src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 1828:

> 1826:   // ensure merged constant pool size does not overflow u2
> 1827:   if (merge_cp_length > 0xFFFF) {
> 1828:     return JVMTI_ERROR_INTERNAL;

Doesn't it make a sense to add some logging there so user could easier understand the problem?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17759#discussion_r1483803900

From coleenp at openjdk.org  Fri Feb  9 03:31:04 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 9 Feb 2024 03:31:04 GMT
Subject: RFR: JDK-8311076: RedefineClasses doesn't check for ConstantPool
 overflow
In-Reply-To: <Z_Hq-oct8XO3DtKivbPa-5VbLjLhPiXjSMJfrupUA5U=.ecd68153-3b48-44c0-a06f-c791e334ca6f@github.com>
References: <Z_Hq-oct8XO3DtKivbPa-5VbLjLhPiXjSMJfrupUA5U=.ecd68153-3b48-44c0-a06f-c791e334ca6f@github.com>
Message-ID: <rbGcV86Bt0E9Apj9hClomMJ84wr_K_XsWNPyBMBlS6U=.bc9df9f7-40af-4e14-907f-135f5c55274c@github.com>

On Wed, 7 Feb 2024 20:53:53 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix adds check that merged constant pool does not overflow u2 (two-byte unsigned).
> The check is added after merging `the_class` and `scratch_class` constant pools, but before rewriting constant pool references.
> 
> testing:
>  - sanity tier1;
>  - all RedefineClasses/RetransformClasses tests:
>    - test/jdk/java/lang/instrument
>    - test/hotspot/jtreg/serviceability/jvmti/RedefineClasses
>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses
>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses

Thank you for fixing this.  Looks good.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17759#pullrequestreview-1871604187

From coleenp at openjdk.org  Fri Feb  9 03:31:04 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 9 Feb 2024 03:31:04 GMT
Subject: RFR: JDK-8311076: RedefineClasses doesn't check for ConstantPool
 overflow
In-Reply-To: <gAJNOQxXwpSo38srrI1H39LMHfNXW1Q5xpDRDFaiNvk=.904bd1d4-8a38-4a35-9cfa-d8c28d77101e@github.com>
References: <Z_Hq-oct8XO3DtKivbPa-5VbLjLhPiXjSMJfrupUA5U=.ecd68153-3b48-44c0-a06f-c791e334ca6f@github.com>
 <gAJNOQxXwpSo38srrI1H39LMHfNXW1Q5xpDRDFaiNvk=.904bd1d4-8a38-4a35-9cfa-d8c28d77101e@github.com>
Message-ID: <8jAkfYsTL8RV4jg3_dXfQZaTp4BP_wx9scBRt1nWl6A=.85bc28e0-6c17-4964-91d0-d25d6cee4cca@github.com>

On Fri, 9 Feb 2024 02:34:26 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The fix adds check that merged constant pool does not overflow u2 (two-byte unsigned).
>> The check is added after merging `the_class` and `scratch_class` constant pools, but before rewriting constant pool references.
>> 
>> testing:
>>  - sanity tier1;
>>  - all RedefineClasses/RetransformClasses tests:
>>    - test/jdk/java/lang/instrument
>>    - test/hotspot/jtreg/serviceability/jvmti/RedefineClasses
>>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses
>>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses
>
> src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 1828:
> 
>> 1826:   // ensure merged constant pool size does not overflow u2
>> 1827:   if (merge_cp_length > 0xFFFF) {
>> 1828:     return JVMTI_ERROR_INTERNAL;
> 
> Doesn't it make a sense to add some logging there so user could easier understand the problem?

Seems like a good idea, you can use log_warning(redefine, class, constantpool)("...")

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17759#discussion_r1483825615

From cjplummer at openjdk.org  Fri Feb  9 03:43:54 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 9 Feb 2024 03:43:54 GMT
Subject: RFR: JDK-8311076: RedefineClasses doesn't check for ConstantPool
 overflow
In-Reply-To: <Z_Hq-oct8XO3DtKivbPa-5VbLjLhPiXjSMJfrupUA5U=.ecd68153-3b48-44c0-a06f-c791e334ca6f@github.com>
References: <Z_Hq-oct8XO3DtKivbPa-5VbLjLhPiXjSMJfrupUA5U=.ecd68153-3b48-44c0-a06f-c791e334ca6f@github.com>
Message-ID: <K4pdT_Dw-RP_EjZN3hUyd9eJ9SqEX4K9lfMiQ9Et680=.070febca-e8f9-40f5-9adf-7d07206c5eb1@github.com>

On Wed, 7 Feb 2024 20:53:53 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix adds check that merged constant pool does not overflow u2 (two-byte unsigned).
> The check is added after merging `the_class` and `scratch_class` constant pools, but before rewriting constant pool references.
> 
> testing:
>  - sanity tier1;
>  - all RedefineClasses/RetransformClasses tests:
>    - test/jdk/java/lang/instrument
>    - test/hotspot/jtreg/serviceability/jvmti/RedefineClasses
>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses
>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses

It looks like we don't have a reproducer for this issue. Please add the appropriate noreg label.

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

PR Review: https://git.openjdk.org/jdk/pull/17759#pullrequestreview-1871610809

From bkilambi at openjdk.org  Fri Feb  9 07:31:02 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Fri, 9 Feb 2024 07:31:02 GMT
Subject: RFR: JDK-8325264: two compiler/intrinsics/float16 tests fail after
 JDK-8324724 [v2]
In-Reply-To: <I9V6Oe3fao_AzD7yUPDWTTDlVWm5uXs5v5Weudl6KL8=.ee337305-0352-460f-a778-b20f6bc0e66c@github.com>
References: <eoR3U5uw7lee-9UJA2qwsyF9u89D_vW83xykuszAMcU=.f70552a1-d96a-4895-99ac-33dfd0942de2@github.com>
 <I9V6Oe3fao_AzD7yUPDWTTDlVWm5uXs5v5Weudl6KL8=.ee337305-0352-460f-a778-b20f6bc0e66c@github.com>
Message-ID: <hkaC17sLdcUHovRzFYZyv6XoGlPqllqqzf2aA2KZ160=.5107e40b-fbf8-4ea4-bcb4-65d5d1ecd2cd@github.com>

On Thu, 8 Feb 2024 17:36:15 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Bhavana Kilambi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make assert the first statement in the function
>
> Good.
> 
> C2 can call `StubRoutines::f2hf()` and `hf2f()` when the value is constant to get constant value.
> Usually C2 executed C++ code from `SharedRuntime` for such cases.
> But to get the same result in Interpreter, C1 and C2 I added call to stub  [JDK-8302976](https://bugs.openjdk.org/browse/JDK-8302976).
> An other solution would be just remove this optimization so that only compiled code will call these stubs. As I remember this is the only place it is called from runtime code.

@vnkozlov Thank you for the review and feedback comments. If we make changes so that the compiled code calls these stubs then the Conv* nodes wouldn't get reduced to Con* nodes early on (when their Value() functions are called) right? This could help with more compiler optimizations further down the lane when these nodes are used..

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

PR Comment: https://git.openjdk.org/jdk/pull/17733#issuecomment-1935449508

From bkilambi at openjdk.org  Fri Feb  9 07:31:03 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Fri, 9 Feb 2024 07:31:03 GMT
Subject: RFR: JDK-8325264: two compiler/intrinsics/float16 tests fail after
 JDK-8324724 [v2]
In-Reply-To: <SSOw-ENktKWuAIMFSmO0n2w4_Dz-VFzrzWu7nc3twkQ=.de8f7a3c-8e3c-4a95-b128-a60b36202c35@github.com>
References: <eoR3U5uw7lee-9UJA2qwsyF9u89D_vW83xykuszAMcU=.f70552a1-d96a-4895-99ac-33dfd0942de2@github.com>
 <SSOw-ENktKWuAIMFSmO0n2w4_Dz-VFzrzWu7nc3twkQ=.de8f7a3c-8e3c-4a95-b128-a60b36202c35@github.com>
Message-ID: <ZQ6w8gY7GId9TaGrrhMi0JZLXY0zsP8kFJn7zM5Joa8=.a8a92cd5-e168-4650-ae69-c8004b9be683@github.com>

On Wed, 7 Feb 2024 06:38:09 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Bhavana Kilambi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make assert the first statement in the function
>
> Looks good. I'm running some sanity testing and will report back once it passed.

@TobiHartmann Have the sanity tests passed? Thanks for testing.

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

PR Comment: https://git.openjdk.org/jdk/pull/17733#issuecomment-1935450546

From eosterlund at openjdk.org  Fri Feb  9 08:43:21 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 9 Feb 2024 08:43:21 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v7]
In-Reply-To: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
Message-ID: <bNpa4NgkwqfbiwfJZUYznEryPEa02_ecNUx0p9jz-Wg=.05bd975e-d50c-438e-96d3-d407b76bc083@github.com>

> ICStubs solve an atomicity problem when setting both the destination and data of an inline cache. Unfortunately, it also leads to occasional safepoint carpets when multiple threads need to ICRefill the stubs at the same time, and spurious GuaranteedSafepointInterval "Cleanup" safepoints every second. This patch changes inline caches to not change the data part at all during the nmethod life cycle, hence removing the need for ICStubs.
> 
> The new scheme is less stateful. Instead of adding and removing callsite metadata back and forth when transitioning inline cache states, it installs all state any shape of call will ever need at resolution time in a struct that I call CompiledICData. This reduces inline cache state changes to simply changing the destination of the call, and it doesn't really matter what state transitions to what other state.
> 
> With this patch, we get rid of ICStub and ICBuffer classes and the related ICRefill and almost all Cleanup safepoints in practice. It also makes the inline cache code much simpler.
> 
> I have tested the changes from tier1-7, and run through full aurora performance tests.

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

  Update src/hotspot/share/runtime/sharedRuntime.cpp
  
  Co-authored-by: Thomas Schatzl <59967451+tschatzl at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17495/files
  - new: https://git.openjdk.org/jdk/pull/17495/files/6dd64b50..01733b85

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

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

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

From eosterlund at openjdk.org  Fri Feb  9 08:43:22 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 9 Feb 2024 08:43:22 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v6]
In-Reply-To: <QvyeIdmQWBfw6n_wbTK0uaPQzMJsdOBslw80YxjSqC4=.dc3269e8-fe40-4390-ba88-bbd3e4f76a2a@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
 <QvyeIdmQWBfw6n_wbTK0uaPQzMJsdOBslw80YxjSqC4=.dc3269e8-fe40-4390-ba88-bbd3e4f76a2a@github.com>
Message-ID: <VirjyzehRQ3_SDa-HiYIWYVfXRdl8dP8PVV28MY4pW0=.fdf1ab22-86da-4d2d-b190-906787bc0212@github.com>

On Thu, 8 Feb 2024 11:52:51 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   ARM32 fixes
>
> src/hotspot/share/oops/oopsHierarchy.hpp line 182:
> 
>> 180: class   Method;
>> 181: class   ConstantPool;
>> 182: //      class CHeapObj
> 
> Not sure why this is here, but maybe also remove this line.

Okay, removing.

> src/hotspot/share/runtime/sharedRuntime.cpp line 1369:
> 
>> 1367:   } else {
>> 1368:     // Callsite is a direct call - set it to the destination method
>> 1369:     CompiledICLocker ml(caller_nm);
> 
> Not sure if it makes sense to factor out the `CompiledICLocker ml(caller_nm); call in both if branches.

Sure, I can do that.

> src/hotspot/share/runtime/sharedRuntime.cpp line 1665:
> 
>> 1663: 
>> 1664:     // Check relocations for the matching call to 1) avoid false positives,
>> 1665:     // and 2) determine the type.
> 
> To me the comment is confusing (probably pre-existing): There does not seem to be a result of the code checking the relocations containing the "type" of the following code. I.e. the only reason this seems to be done here is reason 1), reason 2) seems obsolete.

Yeah I don't really understand what the comment is trying to say at all. I'll remove it.

> src/hotspot/share/runtime/sharedRuntime.cpp line 1807:
> 
>> 1805:   }
>> 1806: 
>> 1807:   assert(iter.has_current(), "must have a reloc at java call site");
> 
> This assert seems to be superfluous after the `if (!iter.next())` bailout just above.

Good point. Removing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1484017440
PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1484016694
PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1484015431
PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1484015615

From eosterlund at openjdk.org  Fri Feb  9 08:43:22 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 9 Feb 2024 08:43:22 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v7]
In-Reply-To: <QvyeIdmQWBfw6n_wbTK0uaPQzMJsdOBslw80YxjSqC4=.dc3269e8-fe40-4390-ba88-bbd3e4f76a2a@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
 <QvyeIdmQWBfw6n_wbTK0uaPQzMJsdOBslw80YxjSqC4=.dc3269e8-fe40-4390-ba88-bbd3e4f76a2a@github.com>
Message-ID: <OEGVL4x0FTfgT3LJCzuSRsAZmpzj7yYERYW1CH5c1lQ=.f82fc516-0d49-4603-89e8-0d6e42dbc36b@github.com>

On Thu, 8 Feb 2024 11:09:30 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/hotspot/share/runtime/sharedRuntime.cpp
>>   
>>   Co-authored-by: Thomas Schatzl <59967451+tschatzl at users.noreply.github.com>
>
> src/hotspot/share/runtime/sharedRuntime.cpp line 1837:
> 
>> 1835:   CompiledMethod* caller_nm = cb->as_compiled_method();
>> 1836: 
>> 1837:   for (;;) {
> 
> I think the comment in line 1826 about
> 
> 
>   // Transitioning IC caches may require transition stubs. If we run out
>   // of transition stubs, we have to drop locks and perform a safepoint
>   // that refills them.
> 
> is out of date and should be removed. At least the code that generates the IC stubs below has been removed...

Good catch. I'll remove the comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1484014998

From eosterlund at openjdk.org  Fri Feb  9 08:48:05 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 9 Feb 2024 08:48:05 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v6]
In-Reply-To: <QvyeIdmQWBfw6n_wbTK0uaPQzMJsdOBslw80YxjSqC4=.dc3269e8-fe40-4390-ba88-bbd3e4f76a2a@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
 <QvyeIdmQWBfw6n_wbTK0uaPQzMJsdOBslw80YxjSqC4=.dc3269e8-fe40-4390-ba88-bbd3e4f76a2a@github.com>
Message-ID: <xmjSsdwr1i4otjTPHBWESRLVVsr3pWdNMuSAIeEQMSY=.56148f23-abb1-4258-8a5f-8253bde07eff@github.com>

On Thu, 8 Feb 2024 12:10:45 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   ARM32 fixes
>
> src/hotspot/share/code/nmethod.cpp line 2310:
> 
>> 2308:       } else {
>> 2309:         CompiledDirectCall::at(call_site);
>> 2310:       }
> 
> Since `CompiledICLocker` does not lock anyway if it is safe (using the `is_safe` method), isn't the `if` superfluous here (and just keeping the `else` part does the same)?

That is true for DefaultICProtectionBehaviour::lock, but not ZGC and Shenandoah.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1484022364

From aboldtch at openjdk.org  Fri Feb  9 09:03:02 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 9 Feb 2024 09:03:02 GMT
Subject: RFR: 8325471: CHeapBitMap(MEMFLAGS flags) constructor misleading
 use of super-constructor
In-Reply-To: <HFv_Fx_7ml0p-FbO1TFm0FVE1TX-XstivvIF8Z8kADM=.8aea76d5-c511-4dd6-ab40-2a4e3a7efe9c@github.com>
References: <HFv_Fx_7ml0p-FbO1TFm0FVE1TX-XstivvIF8Z8kADM=.8aea76d5-c511-4dd6-ab40-2a4e3a7efe9c@github.com>
Message-ID: <VFPR7jynCxyGKNTAvfkvp3GQtoWm3-Du1eOpAxLnl2o=.b9d46ebc-bb37-4eaa-b014-b1c4d5baecc4@github.com>

On Thu, 8 Feb 2024 09:00:35 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> The `explicit CHeapBitMap(MEMFLAGS flags)` calls the `GrowableBitMap(bm_word_t* map, idx_t size_in_bits)` super-constructor with `GrowableBitMap(0, false)`. This works because `0` gets converted to `nullptr` and `false` gets converted to `0`. However this seems to have be a miss in the most recent refactoring and is misleading.
> 
> `explicit CHeapBitMap(MEMFLAGS flags)` should use `GrowableBitMap()` directly which creates an empty (uninitialised) bitmap.

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/17768#issuecomment-1935553228

From aboldtch at openjdk.org  Fri Feb  9 09:03:03 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 9 Feb 2024 09:03:03 GMT
Subject: Integrated: 8325471: CHeapBitMap(MEMFLAGS flags) constructor
 misleading use of super-constructor
In-Reply-To: <HFv_Fx_7ml0p-FbO1TFm0FVE1TX-XstivvIF8Z8kADM=.8aea76d5-c511-4dd6-ab40-2a4e3a7efe9c@github.com>
References: <HFv_Fx_7ml0p-FbO1TFm0FVE1TX-XstivvIF8Z8kADM=.8aea76d5-c511-4dd6-ab40-2a4e3a7efe9c@github.com>
Message-ID: <TsXzRxXMv2_uM5UDZRqdbxJDkQ53AeuUqRJF6f5d8ME=.593e4861-6c0f-4a28-ac94-5ca03dbc8229@github.com>

On Thu, 8 Feb 2024 09:00:35 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> The `explicit CHeapBitMap(MEMFLAGS flags)` calls the `GrowableBitMap(bm_word_t* map, idx_t size_in_bits)` super-constructor with `GrowableBitMap(0, false)`. This works because `0` gets converted to `nullptr` and `false` gets converted to `0`. However this seems to have be a miss in the most recent refactoring and is misleading.
> 
> `explicit CHeapBitMap(MEMFLAGS flags)` should use `GrowableBitMap()` directly which creates an empty (uninitialised) bitmap.

This pull request has now been integrated.

Changeset: 71b46c38
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/71b46c38a820319851cade2a15d64a657d4d7284
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8325471: CHeapBitMap(MEMFLAGS flags) constructor misleading use of super-constructor

Reviewed-by: stefank, tschatzl

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

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

From eosterlund at openjdk.org  Fri Feb  9 09:05:20 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 9 Feb 2024 09:05:20 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v8]
In-Reply-To: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
Message-ID: <xGk22XNCd7TNBjYhyyQ0qlgPKOWByaYNHd1uIuLWaWc=.83438da3-1887-4f35-b23c-3100689e40e0@github.com>

> ICStubs solve an atomicity problem when setting both the destination and data of an inline cache. Unfortunately, it also leads to occasional safepoint carpets when multiple threads need to ICRefill the stubs at the same time, and spurious GuaranteedSafepointInterval "Cleanup" safepoints every second. This patch changes inline caches to not change the data part at all during the nmethod life cycle, hence removing the need for ICStubs.
> 
> The new scheme is less stateful. Instead of adding and removing callsite metadata back and forth when transitioning inline cache states, it installs all state any shape of call will ever need at resolution time in a struct that I call CompiledICData. This reduces inline cache state changes to simply changing the destination of the call, and it doesn't really matter what state transitions to what other state.
> 
> With this patch, we get rid of ICStub and ICBuffer classes and the related ICRefill and almost all Cleanup safepoints in practice. It also makes the inline cache code much simpler.
> 
> I have tested the changes from tier1-7, and run through full aurora performance tests.

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

  Update src/hotspot/share/code/compiledIC.hpp
  
  Co-authored-by: Thomas Schatzl <59967451+tschatzl at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17495/files
  - new: https://git.openjdk.org/jdk/pull/17495/files/01733b85..dfdcdcc3

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

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

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

From eosterlund at openjdk.org  Fri Feb  9 09:05:21 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 9 Feb 2024 09:05:21 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v6]
In-Reply-To: <QvyeIdmQWBfw6n_wbTK0uaPQzMJsdOBslw80YxjSqC4=.dc3269e8-fe40-4390-ba88-bbd3e4f76a2a@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
 <QvyeIdmQWBfw6n_wbTK0uaPQzMJsdOBslw80YxjSqC4=.dc3269e8-fe40-4390-ba88-bbd3e4f76a2a@github.com>
Message-ID: <hsWMW0QIc-stKvtLyecAPUvCa0UWlMovriPWh5vW7tY=.891ac981-ce32-4a21-a49c-d3bf12f07048@github.com>

On Thu, 8 Feb 2024 12:27:26 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   ARM32 fixes
>
> src/hotspot/share/code/compiledMethod.cpp line 457:
> 
>> 455:   if (clean_all || !cm->is_in_use() || cm->is_unloading() || cm->method()->code() != cm) {
>> 456:     cdc->set_to_clean();
>> 457:   }
> 
> Maybe a single `clean_if_nmethod_is_unloaded()` with the destination address as a parameter would avoid the code duplication with the other variant; otherwise another static helper function would be great.

Good point. I'll try on a template thing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1484040893

From eosterlund at openjdk.org  Fri Feb  9 09:10:05 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 9 Feb 2024 09:10:05 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v6]
In-Reply-To: <ntKnOaWbggDKycTJ6tC0zucfA1eEokg3OsIGh-Z0GkQ=.76bf6dc3-552c-4833-b04a-89ef34746a51@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
 <ntKnOaWbggDKycTJ6tC0zucfA1eEokg3OsIGh-Z0GkQ=.76bf6dc3-552c-4833-b04a-89ef34746a51@github.com>
Message-ID: <vvr5eSItoDfZupe3U0mnWRb_ZAi0EFBTOAo5GtR-7vk=.b61b0056-e842-4cce-a848-d9c14dccaaf5@github.com>

On Thu, 8 Feb 2024 09:16:36 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   ARM32 fixes
>
> src/hotspot/share/opto/output.cpp line 3416:
> 
>> 3414:     } else {
>> 3415:       if (!target->is_static()) {
>> 3416:         _code_offsets.set_value(CodeOffsets::Entry, _first_block_size - MacroAssembler::ic_check_size());
> 
> This looks tricky. I think it means CodeOffsets::Entry starts after the alignment padding NOPs. If that's true then the `ic_check` functions could use a comment explaining that alignment needs to come first, not last. A comment here wouldn't hurt either.

Yes that's exactly it. I found that I got a less fortunate nop encoding that actually did show up as a tiny regression. It was fixed by not running the nops. I'll write a comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1484046000

From eosterlund at openjdk.org  Fri Feb  9 09:32:01 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 9 Feb 2024 09:32:01 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v6]
In-Reply-To: <OgOxE-XTO2K2bF8Form29cAxKWcv8_8nGlpUYMA2Hp4=.194c9f44-4249-4a8a-bc8f-a54908694993@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
 <OgOxE-XTO2K2bF8Form29cAxKWcv8_8nGlpUYMA2Hp4=.194c9f44-4249-4a8a-bc8f-a54908694993@github.com>
Message-ID: <ESrbahUYtyzUXsIXQ9bxNoJ9OMO3YZNRN5-qtTsuz7Q=.59a894ad-143f-4212-b815-f2e4dab69072@github.com>

On Thu, 8 Feb 2024 09:25:33 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   ARM32 fixes
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 1016:
> 
>> 1014:   Register tmp1 = rscratch1;
>> 1015:   Register tmp2 = r10;
>> 1016: 
> 
> It would be nice if we could still call `verify_oop(receiver)` here, but I see that would complicate `ic_check_size()`.

Yeah I thought the same. As it's important for correctness that ic_check_size is accurate, I was hoping to have as few different modes in it as possible.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1484070401

From eosterlund at openjdk.org  Fri Feb  9 09:32:02 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 9 Feb 2024 09:32:02 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v8]
In-Reply-To: <8HWf9TJDmMH3OM8EfOn2joR2-CnOtzaawAfuOQigB6w=.9c0489a9-79e8-43e1-b274-2c7f48b8c95b@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
 <8HWf9TJDmMH3OM8EfOn2joR2-CnOtzaawAfuOQigB6w=.9c0489a9-79e8-43e1-b274-2c7f48b8c95b@github.com>
Message-ID: <6x7p-prxRRkFH8IRVsD3Ie5pp_Vvwk5R175c3tdE02s=.b7cbc61c-e4bb-4a32-a30f-1f2589f3027a@github.com>

On Thu, 8 Feb 2024 21:21:59 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/hotspot/share/code/compiledIC.hpp
>>   
>>   Co-authored-by: Thomas Schatzl <59967451+tschatzl at users.noreply.github.com>
>
> src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 770:
> 
>> 768:     // Method might have been compiled since the call site was patched to
>> 769:     // interpreted; if that is the case treat it as a miss so we can get
>> 770:     // the call site corrected.
> 
> This comment is still relevant, isn't it?

Unfortunately it is. I think it should be done in the subsequent patch_callers_callsite that has this exact same purpose for code dispatching through the VEP. But I think it's outside of scope for this PR to change that. I'm putting the comment back.

> src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 1555:
> 
>> 1553:   __ far_jump(RuntimeAddress(SharedRuntime::get_ic_miss_stub()));
>> 1554: 
>> 1555:   // Verified entry point must be aligned
> 
> Keep this comment?

Yeah, will do.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1484067761
PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1484070144

From eosterlund at openjdk.org  Fri Feb  9 09:37:10 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 9 Feb 2024 09:37:10 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v6]
In-Reply-To: <0fQX2S37e-tHVt-IwRk8X95k0JYUmsBYr37oobhIagc=.92e45b75-b673-4022-b752-6359ee672976@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
 <0fQX2S37e-tHVt-IwRk8X95k0JYUmsBYr37oobhIagc=.92e45b75-b673-4022-b752-6359ee672976@github.com>
Message-ID: <hcMakYleVQfEvcWxMyWsF6PtWOYJQt5ptgoPaQRTcT8=.811f2c00-c539-4a37-a411-c92593acf6f4@github.com>

On Thu, 8 Feb 2024 21:37:17 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   ARM32 fixes
>
> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 1360:
> 
>> 1358:   Register data = rax;
>> 1359:   Register temp = LP64_ONLY(rscratch1) NOT_LP64(rbx);
>> 1360: 
> 
> It would be nice if VerifyOops check could be added back, maybe as a follow-up RFE?

Good idea.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1484075750

From eosterlund at openjdk.org  Fri Feb  9 09:43:09 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 9 Feb 2024 09:43:09 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v6]
In-Reply-To: <TXLIdVrjfirk92Nb6kjy0SsH0i-dGXQK4BypJnTAQjg=.0430a7f0-89a8-4ad6-8bd6-e51a3935d6e9@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
 <4Xcj3NXRRxEvGn3fIVpGYlZ5vCwyx7mdxaAEQ5myKKo=.aa1309ef-5289-476b-a285-306b307e1b85@github.com>
 <TXLIdVrjfirk92Nb6kjy0SsH0i-dGXQK4BypJnTAQjg=.0430a7f0-89a8-4ad6-8bd6-e51a3935d6e9@github.com>
Message-ID: <9TObmpq_n39x7PFzb_jJYVvnAfGTcgiZio-GjlsVR7k=.4f4059b2-fe0e-4165-99b6-9604ae9611cc@github.com>

On Fri, 9 Feb 2024 01:31:25 GMT, Dean Long <dlong at openjdk.org> wrote:

>> src/hotspot/cpu/x86/x86_64.ad line 1487:
>> 
>>> 1485: {
>>> 1486:   MacroAssembler masm(&cbuf);
>>> 1487:   masm.ic_check(CodeEntryAlignment);
>> 
>> I'm concerned about OptoBreakpoint and friends messing up the alignment:
>> https://github.com/openjdk/jdk/blob/10beb3184e14e2714cd836029680a8b2d3fd5011/src/hotspot/share/opto/output.cpp#L317
>
> It's fine, the breakpoint is insert *after* the prologue.

Yeah, that did have me confused as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1484079876

From eosterlund at openjdk.org  Fri Feb  9 09:43:09 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 9 Feb 2024 09:43:09 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v8]
In-Reply-To: <0fQX2S37e-tHVt-IwRk8X95k0JYUmsBYr37oobhIagc=.92e45b75-b673-4022-b752-6359ee672976@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
 <0fQX2S37e-tHVt-IwRk8X95k0JYUmsBYr37oobhIagc=.92e45b75-b673-4022-b752-6359ee672976@github.com>
Message-ID: <gCNSjg6M1-o36k-UUVqCTihAvxmoOxlOnruZLT4IN14=.9575fd4f-5772-4350-964f-b1154f1a47d3@github.com>

On Thu, 8 Feb 2024 21:38:37 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/hotspot/share/code/compiledIC.hpp
>>   
>>   Co-authored-by: Thomas Schatzl <59967451+tschatzl at users.noreply.github.com>
>
> src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp line 1463:
> 
>> 1461:   __ jump(RuntimeAddress(SharedRuntime::get_ic_miss_stub()));
>> 1462: 
>> 1463:   // verified entry must be aligned for code patching.
> 
> This comment still seems relevant.

Good point, resurrecting the comment.

> src/hotspot/share/c1/c1_LIRAssembler.cpp line 612:
> 
>> 610:       // init offsets
>> 611:       offsets()->set_value(CodeOffsets::OSR_Entry, _masm->offset());
>> 612:       _masm->align(CodeEntryAlignment);
> 
> So we used to unconditionally align here, but never set CodeOffsets::Entry, meaning we got the default offset of 0 and the entry had to execute the alignment NOPs.

Yes. I found those nops to sometimes be expensive. So in the new model, it's a bug for the VEP to not already be aligned, from the UEP, so we can skip executing the padding nops.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1484078846
PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1484081379

From eosterlund at openjdk.org  Fri Feb  9 09:43:10 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 9 Feb 2024 09:43:10 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v6]
In-Reply-To: <bHqPPuoq-BrRroH1icXNvwPEE8saqB35Avr_ovfpLG0=.025040ee-b3c7-4e5b-8574-2758ba7bc889@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
 <bHqPPuoq-BrRroH1icXNvwPEE8saqB35Avr_ovfpLG0=.025040ee-b3c7-4e5b-8574-2758ba7bc889@github.com>
Message-ID: <AlSpcnebmZGtmuZUKouqV_C3o7XqyIhkTUl15HnJ_9g=.3e0a058e-0b4d-4933-8872-40c2a4edc131@github.com>

On Fri, 9 Feb 2024 01:38:00 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   ARM32 fixes
>
> src/hotspot/share/runtime/vmStructs.cpp line 217:
> 
>> 215:   volatile_nonstatic_field(CompiledICData,     _speculated_klass,                             uintptr_t)                             \
>> 216:   nonstatic_field(CompiledICData,              _itable_defc_klass,                            Klass*)                                \
>> 217:   nonstatic_field(CompiledICData,              _itable_refc_klass,                            Klass*)                                \
> 
> I don't think it makes sense to export these fields and types until SA is changed to make use of them.

Good point. I thought at least Graal needs them, but they have their own VM structs file where they are exposed. I'll remove this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1484082651

From eosterlund at openjdk.org  Fri Feb  9 09:56:10 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 9 Feb 2024 09:56:10 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v6]
In-Reply-To: <ntKnOaWbggDKycTJ6tC0zucfA1eEokg3OsIGh-Z0GkQ=.76bf6dc3-552c-4833-b04a-89ef34746a51@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
 <ntKnOaWbggDKycTJ6tC0zucfA1eEokg3OsIGh-Z0GkQ=.76bf6dc3-552c-4833-b04a-89ef34746a51@github.com>
Message-ID: <zm-A8OH6z1gNvLGJMYPaZZHbhKLmidwwwxQ77KpIJBU=.c524e06a-fda4-4f30-84a3-b7a19779cdc9@github.com>

On Thu, 8 Feb 2024 09:18:20 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   ARM32 fixes
>
> src/hotspot/cpu/aarch64/aarch64.ad line 2224:
> 
>> 2222:   // This is the unverified entry point.
>> 2223:   C2_MacroAssembler _masm(&cbuf);
>> 2224:   __ ic_check(CodeEntryAlignment);
> 
> I'm not sure we want to increase the alignement to CodeEntryAlignment here.  I believe C2 already aligns the root block to CodeEntryAlignment.  @theRealAph, what do you think?

I can change it to InteriorEntryAlignment which is what the VEP block is aligned to. I think it's still good that the root block is aligned to CodeEntryAlignment though. I heard some HW sheds some tears when their instruction cache lines also contain data that doesn't correspond to any actual instructions. But we can definitely align to InteriorEntryAlignment here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1484096298

From thartmann at openjdk.org  Fri Feb  9 10:17:04 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 9 Feb 2024 10:17:04 GMT
Subject: RFR: JDK-8325264: two compiler/intrinsics/float16 tests fail after
 JDK-8324724 [v2]
In-Reply-To: <LnFMyXzIC9apHPZ4tmsza3ZLspxrTnMBxkATW53OPMg=.46eb6dd2-7cdf-411f-9ea5-edea24b5fefd@github.com>
References: <eoR3U5uw7lee-9UJA2qwsyF9u89D_vW83xykuszAMcU=.f70552a1-d96a-4895-99ac-33dfd0942de2@github.com>
 <LnFMyXzIC9apHPZ4tmsza3ZLspxrTnMBxkATW53OPMg=.46eb6dd2-7cdf-411f-9ea5-edea24b5fefd@github.com>
Message-ID: <lPCajH47VgHvx-qm5bBG4hnD6mraWDp1sws_RMkfsNw=.9dfff39f-f336-4916-aaf2-c156138dc36e@github.com>

On Thu, 8 Feb 2024 20:37:07 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

>> Fix for two JTREG test failures on OS_X after this commit - https://github.com/openjdk/jdk/commit/51853f7488afa69c0d14b0e96f1da84822cd83f1.
>> 
>> This is due to no permission to execute the stub code in the code cache. This patch fixes this problem by acquiring "WXExec" to be able to execute the instructions in code cache.
>> 
>> Both the tests - compiler/intrinsics/float16/TestAllFloat16ToFloat.java and compiler/intrinsics/float16/Binary16ConversionNaN.java pass on a MacOS machine.
>
> Bhavana Kilambi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make assert the first statement in the function

Yes, all tests passed. This is good to go.

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

PR Comment: https://git.openjdk.org/jdk/pull/17733#issuecomment-1935657528

From stefank at openjdk.org  Fri Feb  9 10:43:00 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 9 Feb 2024 10:43:00 GMT
Subject: RFR: 8305898: Alternative self-forwarding mechanism [v4]
In-Reply-To: <OC2HtdWXXKiV3OLkz39XVG7bickA31IZZVgpZpZy3GU=.04506b71-994c-4dc6-a39f-cf0d0c908977@github.com>
References: <N4eX8S-btv0VD19kl2W9RigVsaw58ZVXDZllFwykZ04=.a9456aa8-b294-480a-b7f0-07616c972f62@github.com>
 <OC2HtdWXXKiV3OLkz39XVG7bickA31IZZVgpZpZy3GU=.04506b71-994c-4dc6-a39f-cf0d0c908977@github.com>
Message-ID: <0gyJ5qqcUDzNCW-Cops8vfk9a3ZtqsFxAXXQczrDsVs=.4debd346-1d1e-46e1-8ec0-1e3aa6c8a840@github.com>

On Thu, 8 Feb 2024 14:37:20 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Currently, the Serial, Parallel and G1 GCs store a pointer to self into object headers to indicate promotion failure. This is problematic for compact object headers ([JDK-8294992](https://bugs.openjdk.org/browse/JDK-8294992)) because it would (temporarily) over-write the crucial class information, which we need for heap parsing. I would like to propose an alternative: use the currently unused 3rd header bit (previously biased-locking bit) to indicate that an object is 'self-forwarded'. That preserves the crucial class information in the upper bits of the header until the full header gets restored.
>> 
>> This is a trimmed-down/simplified version of the original proposal #13779:
>>  - It doesn't use/introduce any flags and avoids the associated branching.
>>  - It doesn't (need to) deal with displaced headers. (Current code would preserve header if necessary, Lilliput code would not use displaced headers and set the 3rd bit directly in existing header.)
>> 
>> Testing:
>>  - [x] hotspot_gc
>>  - [x] tier1
>>  - [x] tier2
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More consistent use of markWord::is_forwarded()

This adds a branch to oopDesc::forwardee. Do you have an GC time measurements to show that this isn't causing a regression?

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

PR Review: https://git.openjdk.org/jdk/pull/17755#pullrequestreview-1872095699

From rkennke at openjdk.org  Fri Feb  9 13:16:05 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 9 Feb 2024 13:16:05 GMT
Subject: RFR: 8305898: Alternative self-forwarding mechanism [v4]
In-Reply-To: <0gyJ5qqcUDzNCW-Cops8vfk9a3ZtqsFxAXXQczrDsVs=.4debd346-1d1e-46e1-8ec0-1e3aa6c8a840@github.com>
References: <N4eX8S-btv0VD19kl2W9RigVsaw58ZVXDZllFwykZ04=.a9456aa8-b294-480a-b7f0-07616c972f62@github.com>
 <OC2HtdWXXKiV3OLkz39XVG7bickA31IZZVgpZpZy3GU=.04506b71-994c-4dc6-a39f-cf0d0c908977@github.com>
 <0gyJ5qqcUDzNCW-Cops8vfk9a3ZtqsFxAXXQczrDsVs=.4debd346-1d1e-46e1-8ec0-1e3aa6c8a840@github.com>
Message-ID: <SE-IzVSzlEfsoMSdQwVaYby_PuzT_keI-mshj47-3QI=.bd04ed6f-4424-48f4-8d16-429f8bc4f513@github.com>

On Fri, 9 Feb 2024 10:40:24 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> This adds a branch to oopDesc::forwardee. Do you have an GC time measurements to show that this isn't causing a regression?

I just ran the (young-GC-heavy) derby benchmark, with more iterations, which does about 1600 GC cycles. Those are the average GC times of young GCs, running with G1:
baseline: 2.88624ms
selffwd: 2.88000ms

With Parallel GC, I get:
baseline: 2.80709
selffwd:  2.74724

When repeating the experiment I get similar results, sometimes baseline is slightliy better, sometimes selffwd is slightly better, but I don't see anything that would support a 'regression' with selffwd.

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

PR Comment: https://git.openjdk.org/jdk/pull/17755#issuecomment-1935906844

From rehn at openjdk.org  Fri Feb  9 13:32:06 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Fri, 9 Feb 2024 13:32:06 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v6]
In-Reply-To: <zm-A8OH6z1gNvLGJMYPaZZHbhKLmidwwwxQ77KpIJBU=.c524e06a-fda4-4f30-84a3-b7a19779cdc9@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
 <ntKnOaWbggDKycTJ6tC0zucfA1eEokg3OsIGh-Z0GkQ=.76bf6dc3-552c-4833-b04a-89ef34746a51@github.com>
 <zm-A8OH6z1gNvLGJMYPaZZHbhKLmidwwwxQ77KpIJBU=.c524e06a-fda4-4f30-84a3-b7a19779cdc9@github.com>
Message-ID: <2digqyA8oO2r8CnmyFKAjlz6oYo_ReR1zQR-1TfkcOE=.b82a146a-4705-4afc-a53c-7b74448d3e11@github.com>

On Fri, 9 Feb 2024 09:53:29 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/aarch64.ad line 2224:
>> 
>>> 2222:   // This is the unverified entry point.
>>> 2223:   C2_MacroAssembler _masm(&cbuf);
>>> 2224:   __ ic_check(CodeEntryAlignment);
>> 
>> I'm not sure we want to increase the alignement to CodeEntryAlignment here.  I believe C2 already aligns the root block to CodeEntryAlignment.  @theRealAph, what do you think?
>
> I can change it to InteriorEntryAlignment which is what the VEP block is aligned to. I think it's still good that the root block is aligned to CodeEntryAlignment though. I heard some HW sheds some tears when their instruction cache lines also contain data that doesn't correspond to any actual instructions. But we can definitely align to InteriorEntryAlignment here.

To add to what Erik is saying here, we have notice that some CPU's have L1I and L1D exclusive, a cache-line can just be in of them. So you can end up with it bouncing between them.

Secondly, if an I-fetch gets data not intended to be decoded, the cpu can get upset in some cases.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1484319136

From eosterlund at openjdk.org  Fri Feb  9 14:24:09 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 9 Feb 2024 14:24:09 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v6]
In-Reply-To: <D1Y_8WDs5xHoA0Hq2BlErSMMHpkhT0B_G7CiE2Oxgkg=.c28b09cb-5a45-4729-98d5-b9101856be4f@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
 <D1Y_8WDs5xHoA0Hq2BlErSMMHpkhT0B_G7CiE2Oxgkg=.c28b09cb-5a45-4729-98d5-b9101856be4f@github.com>
Message-ID: <DbiA_xdYJEDy_NYiv4xo1L7NeG0V2mdFCCQ48HvqO4Y=.618d0674-f239-4fe1-b95a-98fee8606506@github.com>

On Thu, 8 Feb 2024 09:21:00 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   ARM32 fixes
>
> src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp line 295:
> 
>> 293: // inline cache check; done before the frame is built.
>> 294: int LIR_Assembler::check_icache() {
>> 295:   return __ ic_check(CodeEntryAlignment);
> 
> Do we really want to remove the optimization that skips alignment for small methods?

It's not obvious to me how likely this optimization is to kick in, and if it does, how many bytes it really saves. It optimizes accessor methods, when the UEP can be squeezed down to 4 instructions. The previous inline_cache_check was >= 2 instructions, there is a jump to skip the far jump, and the far_jump is >= 1 instructions. So it seems like it would kick in when far jumps can just branch and the compressed class encoding is simple enough. However, with the new ic_check we always have at least 5 instructions, sometimes 7. So it seemed to me like the intended optimization wouldn't apply any longer anyway.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1484387445

From eosterlund at openjdk.org  Fri Feb  9 14:30:11 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 9 Feb 2024 14:30:11 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v6]
In-Reply-To: <KDviofJEEAHQEsPZe-pHNA2Yq9Af88SCHis4qDJDTqM=.876ae44e-9cff-4ec6-89d1-8f6c376bbd42@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
 <KDviofJEEAHQEsPZe-pHNA2Yq9Af88SCHis4qDJDTqM=.876ae44e-9cff-4ec6-89d1-8f6c376bbd42@github.com>
Message-ID: <0sYzdHTXEglk5fD3YdSK_GOT27U-hcs5ybjFONloiLQ=.6bb975f7-411c-4cbf-9dd9-db5b8a4e7fcb@github.com>

On Thu, 8 Feb 2024 21:28:26 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   ARM32 fixes
>
> src/hotspot/cpu/arm/arm.ad line 880:
> 
>> 878: void MachUEPNode::emit(CodeBuffer &cbuf, PhaseRegAlloc *ra_) const {
>> 879:   C2_MacroAssembler _masm(&cbuf);
>> 880:   __ ic_check(CodeEntryAlignment);
> 
> Do we care about CodeEntryAlignment here if the old code didn't?

Perhaps not, but it seems weird not to align. But maybe I should use InteriorEntryAlignment here, so it's symmetric to AArch64.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1484390940

From eosterlund at openjdk.org  Fri Feb  9 14:30:12 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 9 Feb 2024 14:30:12 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v8]
In-Reply-To: <04ntORhQBIEdsks9kJSNyR2iqdsTfwmAFWG36z5ilOo=.6b91fe2f-3573-4e31-97fb-62ead3720487@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
 <04ntORhQBIEdsks9kJSNyR2iqdsTfwmAFWG36z5ilOo=.6b91fe2f-3573-4e31-97fb-62ead3720487@github.com>
Message-ID: <9qAWSeejCa2vE1t1zu-cegZbEGOuZKNWod0wgXGMh-A=.74bed6a1-30b8-464e-a779-2bd73b7e7ee1@github.com>

On Thu, 8 Feb 2024 21:32:22 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/hotspot/share/code/compiledIC.hpp
>>   
>>   Co-authored-by: Thomas Schatzl <59967451+tschatzl at users.noreply.github.com>
>
> src/hotspot/cpu/arm/sharedRuntime_arm.cpp line 831:
> 
>> 829:   __ jump(SharedRuntime::get_ic_miss_stub(), relocInfo::runtime_call_type, Rtemp);
>> 830:   __ align(CodeEntryAlignment);
>> 831: 
> 
> Keep the CodeEntryAlignment and VEP comment?

Okay, I will fix it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1484394428

From eosterlund at openjdk.org  Fri Feb  9 14:35:43 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 9 Feb 2024 14:35:43 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints
In-Reply-To: <T0dapsqbm30AmWJZMOaXry-kaNOyq5IqiqPHV4gmvaE=.a6075c1f-df8e-4f8a-ba35-b723760a7342@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <9GolX3m7SkG4Fs0KTN5qMRxVK47eAhPLdmlaO3oGSKc=.736c3053-abc5-45ce-bd54-85c4f70c3fc9@github.com>
 <T0dapsqbm30AmWJZMOaXry-kaNOyq5IqiqPHV4gmvaE=.a6075c1f-df8e-4f8a-ba35-b723760a7342@github.com>
Message-ID: <X5zT7x-6UR2M4HBD_oMiKzi6EoN5lSVgBE5VvyykL8c=.919a4126-fbbe-4c84-bf53-0cefd95a006e@github.com>

On Mon, 29 Jan 2024 09:38:52 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> On linux, the time for "Purge Unlinked NMethods" goes down when I comment out `delete ic->data();` and ignore the memory leak. (MacOS seems to be ok with it.)
>> Adding trace code to `purge_ic_callsites` shows that we often have 0 or 2 ICData instances, sometimes up to 30 ones.
>> It would be good to think a bit about the allocation scheme. Some ideas would be
>> 
>> - Allocate ICData in an array per nmethod instead of individually. That should help to some degree and also improve data locality (and hence cache efficiency). Would also save iterating over the relocations when purging unlinked NMethods. It's not very complex.
>> - Instead of freeing ICData instances, we could enqueue them and either reuse or free them during a concurrent phase. This may be a bit complicated. Not sure if it's worth it.
>> - Allocate in Metaspace?
>
>> On linux, the time for "Purge Unlinked NMethods" goes down when I comment out delete ic->data(); and ignore the memory leak. (MacOS seems to be ok with it.)
>>Adding trace code to purge_ic_callsites shows that we often have 0 or 2 ICData instances, sometimes up to 30 ones.
>>It would be good to think a bit about the allocation scheme. Some ideas would be
> 
>>    Allocate ICData in an array per nmethod instead of individually. That should help to some degree and also improve data locality (and hence cache efficiency). Would also save iterating over the relocations when purging unlinked NMethods. It's not very complex.
>>    Instead of freeing ICData instances, we could enqueue them and either reuse or free them during a concurrent phase. This may be a bit complicated. Not sure if it's worth it.
>>    Allocate in Metaspace?
> 
> Sorry for being unresponsive for a bit.
> 
> Yes, the issue is the new `delete ic->data()`; but also the iteration over the relocinfo here is almost as expensive in my tests.
> 
> So the idea to allocate ICData in a per nmethod basis (and actually some other existing C heap allocations that are also `delete`d in this phase) seems the most promising to me.
> 
> Also came up with the other suggestions, but I think that first one seems best to me at first glance. I did not really like the second because enqueuing adds another indirection for first gathering all of them and then separately free them.
> 
> Metaspace is something I do not know that well to comment on that option.
> 
> I am open to moving this improvement, if it is not easy to do, into a separate CR.

Thanks for the reviews @tschatzl and @dean-long. I have pushed changes reflecting your feedback.

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

PR Comment: https://git.openjdk.org/jdk/pull/17495#issuecomment-1936040466

From eosterlund at openjdk.org  Fri Feb  9 14:35:43 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 9 Feb 2024 14:35:43 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v9]
In-Reply-To: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
Message-ID: <V98qMF5Nt3FtxSWERvrDp0aoXh6D5n9O70hDYZ8x9AA=.de3befaf-db68-43af-9230-cc54f0455f4b@github.com>

> ICStubs solve an atomicity problem when setting both the destination and data of an inline cache. Unfortunately, it also leads to occasional safepoint carpets when multiple threads need to ICRefill the stubs at the same time, and spurious GuaranteedSafepointInterval "Cleanup" safepoints every second. This patch changes inline caches to not change the data part at all during the nmethod life cycle, hence removing the need for ICStubs.
> 
> The new scheme is less stateful. Instead of adding and removing callsite metadata back and forth when transitioning inline cache states, it installs all state any shape of call will ever need at resolution time in a struct that I call CompiledICData. This reduces inline cache state changes to simply changing the destination of the call, and it doesn't really matter what state transitions to what other state.
> 
> With this patch, we get rid of ICStub and ICBuffer classes and the related ICRefill and almost all Cleanup safepoints in practice. It also makes the inline cache code much simpler.
> 
> I have tested the changes from tier1-7, and run through full aurora performance tests.

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

  Feedback from Dean and Thomas

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17495/files
  - new: https://git.openjdk.org/jdk/pull/17495/files/dfdcdcc3..08c146b7

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

  Stats: 71 lines in 17 files changed: 37 ins; 26 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/17495.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17495/head:pull/17495

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

From stuefe at openjdk.org  Fri Feb  9 15:44:03 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 9 Feb 2024 15:44:03 GMT
Subject: RFR: 8323273: AArch64: Strengthen CompressedClassPointers
 initialization check for base
In-Reply-To: <Unuzwz0YLo2jvmvcYOF3tjDI7Tr4PuoU3vedUfdUrmA=.914474fb-292f-4eeb-a82b-b3a858ab65d0@github.com>
References: <Unuzwz0YLo2jvmvcYOF3tjDI7Tr4PuoU3vedUfdUrmA=.914474fb-292f-4eeb-a82b-b3a858ab65d0@github.com>
Message-ID: <srCJ10JsmjQg-IdQM1lNuJjOImZqm2SOl4cCDUVOCTk=.c0e0a44d-d955-4a76-8b5b-64f1733969ba@github.com>

On Tue, 16 Jan 2024 02:41:40 GMT, Yude Lin <duke at openjdk.org> wrote:

> Summary:
> Add a platform-dependent check for CompressedClassSpaceBaseAddress;
> Remove the "reserve anywhere" attempt after the initial mapping attempt failed---this is rarely used and will likely fail anyway, because the accepted mapping is very restricted on aarch64;
> Additional assertions after initialization.
> 
> Passed hotspot/jtreg/:tier1 on fastdebug

Hi @linade,

as part of Lilliput, we are planning larger changes to this code in mainline - see https://github.com/openjdk/lilliput/pull/128, which will also go in a bit different form into mainline. It would be nice if you could hold off your PR until then.

But I am also not convinced the changes are needed. I see some improvements to code clarity, but those I would rather see after Lilliput hits, in a separate RFE. For the two functional main points this PR addresses:

- `CompressedClassSpaceBaseAddress` is a development debug-only tool that should do exactly what's on the label: dumbly enforce an address. Its only purpose is to observe the JVM's handling of this address. If that handling includes asserting, I'd like to see that. There is no need for more complexity - it is a simple tool with sharp edges and it only exists for tests.
- I don't see what we gain by removing the "reserve anywhere" path. "It may fail with a high probability" is not enough reason - it also may succeed. At the cost of one additional mmap call (which we probably called before that point a hundred times) it still can prevent an early VM death.

Cheers, Thomas

src/hotspot/cpu/aarch64/compressedKlass_aarch64.cpp line 70:

> 68:     const int index = (start_index + ntry + alt_index) % num_immediates;
> 69:     const uint64_t immediate = ((uint64_t)immediates[index]) << 32;
> 70:     assert(immediate > 0 && MacroAssembler::eor_compatible_klass_encoding(immediate) >= 32,

The format of this helper is rather awkward. It returns 0 if the address is not compatible? Otherwise, the number of trailing zeros?

I think there is no strong need for any of this, since the original assert is already over-cautious (after all, we only test a range of hard-coded values). But if you like to add a test for the lower 32-bit, I'd just add that here, no need for these functions.

src/hotspot/cpu/aarch64/compressedKlass_aarch64.cpp line 134:

> 132:   _range = end - _base;
> 133: 
> 134:   DEBUG_ONLY(assert_is_valid_encoding(addr, len, _base, _shift);)

asserts are debug only, DEBUG_ONLY is not needed

src/hotspot/cpu/aarch64/compressedKlass_aarch64.cpp line 142:

> 140:           (1ULL << MacroAssembler::eor_compatible_klass_encoding((uint64_t)base) >= range) ||
> 141:           MacroAssembler::movk_compatible_klass_encoding((uint64_t)base)) &&
> 142:          (shift == -1 /* Not specified */ || shift == 0);

This duplicates the assert we have in MacroAssembler; why do this twice, in two places?

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 4682:

> 4680:     (uint64_t)CompressedKlassPointers::base() >> CompressedKlassPointers::shift();
> 4681:   guarantee(movk_compatible_klass_encoding(shifted_base),
> 4682:             "compressed class base bad alignment");

I also think this code can benefit from a bit cleanup some time in the future, but for now I ask you to hold off: there is no pressing need at the moment, and once Lilliput things have settled, this code should be easier to work with it. 

Also, there are a few more things we could improve, and I rather see those in a combined single RFE.

src/hotspot/share/memory/metaspace.cpp line 590:

> 588: 
> 589: #if !defined(AARCH64)
> 590:   // On aarch64, this likely wouldn't satisfy the encoding constraints.

Please don't add platform ifdefs here! We put much work into getting rid of platform-dependent sections. Also, as stated above, I think this change is not needed.

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

PR Review: https://git.openjdk.org/jdk/pull/17437#pullrequestreview-1872611278
PR Review Comment: https://git.openjdk.org/jdk/pull/17437#discussion_r1484464819
PR Review Comment: https://git.openjdk.org/jdk/pull/17437#discussion_r1484451905
PR Review Comment: https://git.openjdk.org/jdk/pull/17437#discussion_r1484466475
PR Review Comment: https://git.openjdk.org/jdk/pull/17437#discussion_r1484470480
PR Review Comment: https://git.openjdk.org/jdk/pull/17437#discussion_r1484446574

From kvn at openjdk.org  Fri Feb  9 16:59:59 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 9 Feb 2024 16:59:59 GMT
Subject: RFR: JDK-8325264: two compiler/intrinsics/float16 tests fail after
 JDK-8324724 [v2]
In-Reply-To: <I9V6Oe3fao_AzD7yUPDWTTDlVWm5uXs5v5Weudl6KL8=.ee337305-0352-460f-a778-b20f6bc0e66c@github.com>
References: <eoR3U5uw7lee-9UJA2qwsyF9u89D_vW83xykuszAMcU=.f70552a1-d96a-4895-99ac-33dfd0942de2@github.com>
 <I9V6Oe3fao_AzD7yUPDWTTDlVWm5uXs5v5Weudl6KL8=.ee337305-0352-460f-a778-b20f6bc0e66c@github.com>
Message-ID: <QrzrBzfrqDRySQNihyXBNpWHi2HgxvSqsEH0yxlHGZg=.12c821c7-5263-4a73-a7ba-98e9fbc3b093@github.com>

On Thu, 8 Feb 2024 17:36:15 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Bhavana Kilambi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make assert the first statement in the function
>
> Good.
> 
> C2 can call `StubRoutines::f2hf()` and `hf2f()` when the value is constant to get constant value.
> Usually C2 executed C++ code from `SharedRuntime` for such cases.
> But to get the same result in Interpreter, C1 and C2 I added call to stub  [JDK-8302976](https://bugs.openjdk.org/browse/JDK-8302976).
> An other solution would be just remove this optimization so that only compiled code will call these stubs. As I remember this is the only place it is called from runtime code.

> @vnkozlov Thank you for the review and feedback comments. If we make changes so that the compiled code calls these stubs then the Conv* nodes wouldn't get reduced to Con* nodes early on (when their Value() functions are called) right? This could help with more compiler optimizations further down the lane when these nodes are used..

Your fix is perfectly fine.

I was just grumbling that if we did not have this optimization we would not need this fix.
Yes, the optimization helps to simplify C2's IR graph.

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

PR Comment: https://git.openjdk.org/jdk/pull/17733#issuecomment-1936269771

From bkilambi at openjdk.org  Fri Feb  9 16:59:59 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Fri, 9 Feb 2024 16:59:59 GMT
Subject: Integrated: JDK-8325264: two compiler/intrinsics/float16 tests fail
 after JDK-8324724
In-Reply-To: <eoR3U5uw7lee-9UJA2qwsyF9u89D_vW83xykuszAMcU=.f70552a1-d96a-4895-99ac-33dfd0942de2@github.com>
References: <eoR3U5uw7lee-9UJA2qwsyF9u89D_vW83xykuszAMcU=.f70552a1-d96a-4895-99ac-33dfd0942de2@github.com>
Message-ID: <T6lxCC6uHQYzrKd4VHE2d5mpGW0ThYHVqHaZtfiOgVU=.5f35fe3d-5fb0-42c2-9a60-959546ed58d3@github.com>

On Tue, 6 Feb 2024 14:37:11 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

> Fix for two JTREG test failures on OS_X after this commit - https://github.com/openjdk/jdk/commit/51853f7488afa69c0d14b0e96f1da84822cd83f1.
> 
> This is due to no permission to execute the stub code in the code cache. This patch fixes this problem by acquiring "WXExec" to be able to execute the instructions in code cache.
> 
> Both the tests - compiler/intrinsics/float16/TestAllFloat16ToFloat.java and compiler/intrinsics/float16/Binary16ConversionNaN.java pass on a MacOS machine.

This pull request has now been integrated.

Changeset: 43684374
Author:    Bhavana Kilambi <bkilambi at openjdk.org>
Committer: Vladimir Kozlov <kvn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/43684374755d7446e224d16e6c40b903b6a6e91f
Stats:     7 lines in 2 files changed: 3 ins; 3 del; 1 mod

8325264: two compiler/intrinsics/float16 tests fail after JDK-8324724

Reviewed-by: thartmann, dfenacci, kvn

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

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

From amenkov at openjdk.org  Fri Feb  9 20:42:14 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 9 Feb 2024 20:42:14 GMT
Subject: RFR: JDK-8311076: RedefineClasses doesn't check for ConstantPool
 overflow [v2]
In-Reply-To: <Z_Hq-oct8XO3DtKivbPa-5VbLjLhPiXjSMJfrupUA5U=.ecd68153-3b48-44c0-a06f-c791e334ca6f@github.com>
References: <Z_Hq-oct8XO3DtKivbPa-5VbLjLhPiXjSMJfrupUA5U=.ecd68153-3b48-44c0-a06f-c791e334ca6f@github.com>
Message-ID: <PH2bS5jM9IslxES6R5xFw7Yi20mVVBg-iy4DxkDUDr8=.7a6a0763-c99d-407f-b0c8-ffbdd94a6734@github.com>

> The fix adds check that merged constant pool does not overflow u2 (two-byte unsigned).
> The check is added after merging `the_class` and `scratch_class` constant pools, but before rewriting constant pool references.
> 
> testing:
>  - sanity tier1;
>  - all RedefineClasses/RetransformClasses tests:
>    - test/jdk/java/lang/instrument
>    - test/hotspot/jtreg/serviceability/jvmti/RedefineClasses
>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses
>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  logging on cp overflow

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17759/files
  - new: https://git.openjdk.org/jdk/pull/17759/files/31b31fe8..a726ea8b

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

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

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

From dlong at openjdk.org  Fri Feb  9 21:31:08 2024
From: dlong at openjdk.org (Dean Long)
Date: Fri, 9 Feb 2024 21:31:08 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v9]
In-Reply-To: <V98qMF5Nt3FtxSWERvrDp0aoXh6D5n9O70hDYZ8x9AA=.de3befaf-db68-43af-9230-cc54f0455f4b@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <V98qMF5Nt3FtxSWERvrDp0aoXh6D5n9O70hDYZ8x9AA=.de3befaf-db68-43af-9230-cc54f0455f4b@github.com>
Message-ID: <yuZxiWcPqLZAIVAVuc39YZT33KESsc5-VVduN50w_uw=.d0798154-8cb0-47e1-ab39-2eea7f285db0@github.com>

On Fri, 9 Feb 2024 14:35:43 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> ICStubs solve an atomicity problem when setting both the destination and data of an inline cache. Unfortunately, it also leads to occasional safepoint carpets when multiple threads need to ICRefill the stubs at the same time, and spurious GuaranteedSafepointInterval "Cleanup" safepoints every second. This patch changes inline caches to not change the data part at all during the nmethod life cycle, hence removing the need for ICStubs.
>> 
>> The new scheme is less stateful. Instead of adding and removing callsite metadata back and forth when transitioning inline cache states, it installs all state any shape of call will ever need at resolution time in a struct that I call CompiledICData. This reduces inline cache state changes to simply changing the destination of the call, and it doesn't really matter what state transitions to what other state.
>> 
>> With this patch, we get rid of ICStub and ICBuffer classes and the related ICRefill and almost all Cleanup safepoints in practice. It also makes the inline cache code much simpler.
>> 
>> I have tested the changes from tier1-7, and run through full aurora performance tests.
>
> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback from Dean and Thomas

src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 1554:

> 1552:     __ far_jump(RuntimeAddress(SharedRuntime::get_handle_wrong_method_stub()));
> 1553: 
> 1554:     // Verified entry point must be aligned

I think this comment should come around line 1539.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1484819672

From dlong at openjdk.org  Fri Feb  9 21:36:16 2024
From: dlong at openjdk.org (Dean Long)
Date: Fri, 9 Feb 2024 21:36:16 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v9]
In-Reply-To: <V98qMF5Nt3FtxSWERvrDp0aoXh6D5n9O70hDYZ8x9AA=.de3befaf-db68-43af-9230-cc54f0455f4b@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <V98qMF5Nt3FtxSWERvrDp0aoXh6D5n9O70hDYZ8x9AA=.de3befaf-db68-43af-9230-cc54f0455f4b@github.com>
Message-ID: <F-mSCkmxplhctHkHQe3D9LpwemWH1vVop3OCTWJvncY=.c50c7ca8-d2fb-4419-8dff-8cf1eee1d2d6@github.com>

On Fri, 9 Feb 2024 14:35:43 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> ICStubs solve an atomicity problem when setting both the destination and data of an inline cache. Unfortunately, it also leads to occasional safepoint carpets when multiple threads need to ICRefill the stubs at the same time, and spurious GuaranteedSafepointInterval "Cleanup" safepoints every second. This patch changes inline caches to not change the data part at all during the nmethod life cycle, hence removing the need for ICStubs.
>> 
>> The new scheme is less stateful. Instead of adding and removing callsite metadata back and forth when transitioning inline cache states, it installs all state any shape of call will ever need at resolution time in a struct that I call CompiledICData. This reduces inline cache state changes to simply changing the destination of the call, and it doesn't really matter what state transitions to what other state.
>> 
>> With this patch, we get rid of ICStub and ICBuffer classes and the related ICRefill and almost all Cleanup safepoints in practice. It also makes the inline cache code much simpler.
>> 
>> I have tested the changes from tier1-7, and run through full aurora performance tests.
>
> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback from Dean and Thomas

src/hotspot/cpu/arm/sharedRuntime_arm.cpp line 823:

> 821:   __ ic_check(CodeEntryAlignment /* end_alignment */);
> 822: 
> 823:   int vep_offset = __ pc() - start;

Maybe add back
`// Verified entry point`
above this line.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1484823504

From lmesnik at openjdk.org  Fri Feb  9 21:49:05 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 9 Feb 2024 21:49:05 GMT
Subject: RFR: JDK-8311076: RedefineClasses doesn't check for ConstantPool
 overflow [v2]
In-Reply-To: <PH2bS5jM9IslxES6R5xFw7Yi20mVVBg-iy4DxkDUDr8=.7a6a0763-c99d-407f-b0c8-ffbdd94a6734@github.com>
References: <Z_Hq-oct8XO3DtKivbPa-5VbLjLhPiXjSMJfrupUA5U=.ecd68153-3b48-44c0-a06f-c791e334ca6f@github.com>
 <PH2bS5jM9IslxES6R5xFw7Yi20mVVBg-iy4DxkDUDr8=.7a6a0763-c99d-407f-b0c8-ffbdd94a6734@github.com>
Message-ID: <-mEjKepIWU-ts9a6UcEBaaHD5NblLIij7y5kUrvyNMU=.312555fb-b584-4f7a-92d2-a1cd418e8ff5@github.com>

On Fri, 9 Feb 2024 20:42:14 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix adds check that merged constant pool does not overflow u2 (two-byte unsigned).
>> The check is added after merging `the_class` and `scratch_class` constant pools, but before rewriting constant pool references.
>> 
>> testing:
>>  - sanity tier1;
>>  - all RedefineClasses/RetransformClasses tests:
>>    - test/jdk/java/lang/instrument
>>    - test/hotspot/jtreg/serviceability/jvmti/RedefineClasses
>>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses
>>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   logging on cp overflow

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17759#pullrequestreview-1873242113

From amenkov at openjdk.org  Fri Feb  9 21:49:06 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 9 Feb 2024 21:49:06 GMT
Subject: RFR: JDK-8311076: RedefineClasses doesn't check for ConstantPool
 overflow [v2]
In-Reply-To: <8jAkfYsTL8RV4jg3_dXfQZaTp4BP_wx9scBRt1nWl6A=.85bc28e0-6c17-4964-91d0-d25d6cee4cca@github.com>
References: <Z_Hq-oct8XO3DtKivbPa-5VbLjLhPiXjSMJfrupUA5U=.ecd68153-3b48-44c0-a06f-c791e334ca6f@github.com>
 <gAJNOQxXwpSo38srrI1H39LMHfNXW1Q5xpDRDFaiNvk=.904bd1d4-8a38-4a35-9cfa-d8c28d77101e@github.com>
 <8jAkfYsTL8RV4jg3_dXfQZaTp4BP_wx9scBRt1nWl6A=.85bc28e0-6c17-4964-91d0-d25d6cee4cca@github.com>
Message-ID: <PBmU2fW6_zhIUgvnwg9JeDhvJIdgtwELTmrawm21F9o=.02a3ea15-aa9f-4672-9be2-d66fe271e41d@github.com>

On Fri, 9 Feb 2024 03:27:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 1828:
>> 
>>> 1826:   // ensure merged constant pool size does not overflow u2
>>> 1827:   if (merge_cp_length > 0xFFFF) {
>>> 1828:     return JVMTI_ERROR_INTERNAL;
>> 
>> Doesn't it make a sense to add some logging there so user could easier understand the problem?
>
> Seems like a good idea, you can use log_warning(redefine, class, constantpool)("...")

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17759#discussion_r1484834110

From sspitsyn at openjdk.org  Fri Feb  9 22:01:07 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 9 Feb 2024 22:01:07 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v3]
In-Reply-To: <yZc4kRjeFsvrCkhso6p_uU4_v-R5cvvOlBzABm-bDV8=.40d038c7-f8f9-4bf2-ac9d-33c75cdc6825@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <bIMfwFEuiZ1CbUtq3NzEeNuW72i4jAqAHGJKMb_VZdg=.4e228b57-af29-4a78-9534-bae11fa6bb2d@github.com>
 <tpoboI2WVbmvE1sR9D-7qsm_Mh8m01-Uwt8tA_pNI5g=.c8219d3c-3acd-4a20-9091-5e9cc911617b@github.com>
 <fXc7nXhy_40lRvUzV35Ofv5sAMPGnjeoWMy1QOmKZuI=.abbf125d-656d-4f27-9700-330ae8a77beb@github.com>
 <yZc4kRjeFsvrCkhso6p_uU4_v-R5cvvOlBzABm-bDV8=.40d038c7-f8f9-4bf2-ac9d-33c75cdc6825@github.com>
Message-ID: <8loJ_hZVW1c4wCOAgx0CM9mP664mZ9CEKSvq_2Bj80o=.3952807a-c155-4a2f-860c-0fb3f4c13339@github.com>

On Thu, 8 Feb 2024 15:29:47 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Yes, I've figured this out now. Thank you for pointing to it.
>> It feels, the counts can be calculated correctly without touching the implementation of `current_pending_monitor()`, `current_waiting_monitor()`, `_contensions` and `_waiters`.
>> At least, I'll try to fix it locally in the `JvmtiEnvBase::get_object_monitor_usage()`.
>> Please, let me know what do you prefer.
>
> I don't have a preference (yet). Like what David suggested, I think we need to
> determine the list of thread and monitor interaction scenarios that want to
> exercise with this API. Once we're happy that those scenarios represent the
> complete list of possible combinations we should double check that against the
> API spec to make sure that those scenarios cover the API spec. Finally, we need
> to make sure that we have a test that covers all those scenarios.
> 
> It has been a long, long time since I've looked at those NSK tests... :-(

Thank you, Dan!
I have a fix and will push it after the mach5 tiers testing.
I've extended the test `test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage003` to have all combinations that David suggested but it was a little bit tricky to make it stable. It feels that an update of the current_pending_monitor() to report the re-entered monitors would make it more elegant. But I'm not sure how to do it correctly yet. Also, I've noticed we do not post the JVMTI events  `MonitorContendedEnter` and `MonitorContendedEntered` for the re-enter case. It looks like a bug to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1484843163

From dlong at openjdk.org  Fri Feb  9 22:05:13 2024
From: dlong at openjdk.org (Dean Long)
Date: Fri, 9 Feb 2024 22:05:13 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v6]
In-Reply-To: <2digqyA8oO2r8CnmyFKAjlz6oYo_ReR1zQR-1TfkcOE=.b82a146a-4705-4afc-a53c-7b74448d3e11@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
 <ntKnOaWbggDKycTJ6tC0zucfA1eEokg3OsIGh-Z0GkQ=.76bf6dc3-552c-4833-b04a-89ef34746a51@github.com>
 <zm-A8OH6z1gNvLGJMYPaZZHbhKLmidwwwxQ77KpIJBU=.c524e06a-fda4-4f30-84a3-b7a19779cdc9@github.com>
 <2digqyA8oO2r8CnmyFKAjlz6oYo_ReR1zQR-1TfkcOE=.b82a146a-4705-4afc-a53c-7b74448d3e11@github.com>
Message-ID: <LDIokk_CZPax2Z5O7Pddvog7TkRS-YUT-zN8cSCmBPg=.76cac941-be1c-4e63-ba2e-d0e0048d4a7b@github.com>

On Fri, 9 Feb 2024 13:29:41 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Secondly, if an I-fetch gets data not intended to be decoded, the cpu can get upset in some cases.

I've heard that in the past, and always wondered, does it matter if the data is "reachable"?  What if it's on the other side of an unconditional branch?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1484846150

From coleenp at openjdk.org  Fri Feb  9 22:29:04 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 9 Feb 2024 22:29:04 GMT
Subject: RFR: JDK-8311076: RedefineClasses doesn't check for ConstantPool
 overflow [v2]
In-Reply-To: <PH2bS5jM9IslxES6R5xFw7Yi20mVVBg-iy4DxkDUDr8=.7a6a0763-c99d-407f-b0c8-ffbdd94a6734@github.com>
References: <Z_Hq-oct8XO3DtKivbPa-5VbLjLhPiXjSMJfrupUA5U=.ecd68153-3b48-44c0-a06f-c791e334ca6f@github.com>
 <PH2bS5jM9IslxES6R5xFw7Yi20mVVBg-iy4DxkDUDr8=.7a6a0763-c99d-407f-b0c8-ffbdd94a6734@github.com>
Message-ID: <UDIjitS1K9UtgdKuz3kBeZYOnwvws0fvncYK4UNRT4o=.b2073725-d91e-4591-9a83-c8432f8af241@github.com>

On Fri, 9 Feb 2024 20:42:14 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix adds check that merged constant pool does not overflow u2 (two-byte unsigned).
>> The check is added after merging `the_class` and `scratch_class` constant pools, but before rewriting constant pool references.
>> 
>> testing:
>>  - sanity tier1;
>>  - all RedefineClasses/RetransformClasses tests:
>>    - test/jdk/java/lang/instrument
>>    - test/hotspot/jtreg/serviceability/jvmti/RedefineClasses
>>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses
>>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   logging on cp overflow

Yes, this should definitely be tagged noreg-hard.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17759#pullrequestreview-1873283771

From dlong at openjdk.org  Sat Feb 10 00:38:15 2024
From: dlong at openjdk.org (Dean Long)
Date: Sat, 10 Feb 2024 00:38:15 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v9]
In-Reply-To: <V98qMF5Nt3FtxSWERvrDp0aoXh6D5n9O70hDYZ8x9AA=.de3befaf-db68-43af-9230-cc54f0455f4b@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <V98qMF5Nt3FtxSWERvrDp0aoXh6D5n9O70hDYZ8x9AA=.de3befaf-db68-43af-9230-cc54f0455f4b@github.com>
Message-ID: <2zDHeeRc4pWQetiIzFMR0JwjZ5ExX7_OV8Yx9G4o_mg=.066b11a8-6a49-455e-a985-3fb5de974480@github.com>

On Fri, 9 Feb 2024 14:35:43 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> ICStubs solve an atomicity problem when setting both the destination and data of an inline cache. Unfortunately, it also leads to occasional safepoint carpets when multiple threads need to ICRefill the stubs at the same time, and spurious GuaranteedSafepointInterval "Cleanup" safepoints every second. This patch changes inline caches to not change the data part at all during the nmethod life cycle, hence removing the need for ICStubs.
>> 
>> The new scheme is less stateful. Instead of adding and removing callsite metadata back and forth when transitioning inline cache states, it installs all state any shape of call will ever need at resolution time in a struct that I call CompiledICData. This reduces inline cache state changes to simply changing the destination of the call, and it doesn't really matter what state transitions to what other state.
>> 
>> With this patch, we get rid of ICStub and ICBuffer classes and the related ICRefill and almost all Cleanup safepoints in practice. It also makes the inline cache code much simpler.
>> 
>> I have tested the changes from tier1-7, and run through full aurora performance tests.
>
> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback from Dean and Thomas

If I just look at the new code, everything looks very reasonable.  I tried to compare the new code to the old code, but quickly gave up.

Could you explain why opt_virtual can now be a direct call and CompiledIC is now only for virtual?  It seems like we could have done that even with the old code.

Also, why don't we have to check for method->is_old() anymore?

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

PR Comment: https://git.openjdk.org/jdk/pull/17495#issuecomment-1936773523

From dlong at openjdk.org  Sat Feb 10 00:51:09 2024
From: dlong at openjdk.org (Dean Long)
Date: Sat, 10 Feb 2024 00:51:09 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v9]
In-Reply-To: <V98qMF5Nt3FtxSWERvrDp0aoXh6D5n9O70hDYZ8x9AA=.de3befaf-db68-43af-9230-cc54f0455f4b@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <V98qMF5Nt3FtxSWERvrDp0aoXh6D5n9O70hDYZ8x9AA=.de3befaf-db68-43af-9230-cc54f0455f4b@github.com>
Message-ID: <PRwICk-Ap7J-Dy7pyDzSmjGOM5grrxr8PKIWjIK16H4=.bbacb96c-64de-49d5-b73b-1eacc1f9057f@github.com>

On Fri, 9 Feb 2024 14:35:43 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> ICStubs solve an atomicity problem when setting both the destination and data of an inline cache. Unfortunately, it also leads to occasional safepoint carpets when multiple threads need to ICRefill the stubs at the same time, and spurious GuaranteedSafepointInterval "Cleanup" safepoints every second. This patch changes inline caches to not change the data part at all during the nmethod life cycle, hence removing the need for ICStubs.
>> 
>> The new scheme is less stateful. Instead of adding and removing callsite metadata back and forth when transitioning inline cache states, it installs all state any shape of call will ever need at resolution time in a struct that I call CompiledICData. This reduces inline cache state changes to simply changing the destination of the call, and it doesn't really matter what state transitions to what other state.
>> 
>> With this patch, we get rid of ICStub and ICBuffer classes and the related ICRefill and almost all Cleanup safepoints in practice. It also makes the inline cache code much simpler.
>> 
>> I have tested the changes from tier1-7, and run through full aurora performance tests.
>
> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback from Dean and Thomas

src/hotspot/share/code/compiledIC.cpp line 347:

> 345: void CompiledDirectCall::set(const methodHandle& callee_method) {
> 346:   CompiledMethod* code = callee_method->code();
> 347:   CompiledMethod* caller = CodeCache::find_compiled(instruction_address());

Instead of doing the slow `find_compiled` unconditionally, I think it would be better to check `is_interpreted_call` first.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1484915701

From amenkov at openjdk.org  Sat Feb 10 00:59:58 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Sat, 10 Feb 2024 00:59:58 GMT
Subject: Integrated: JDK-8311076: RedefineClasses doesn't check for
 ConstantPool overflow
In-Reply-To: <Z_Hq-oct8XO3DtKivbPa-5VbLjLhPiXjSMJfrupUA5U=.ecd68153-3b48-44c0-a06f-c791e334ca6f@github.com>
References: <Z_Hq-oct8XO3DtKivbPa-5VbLjLhPiXjSMJfrupUA5U=.ecd68153-3b48-44c0-a06f-c791e334ca6f@github.com>
Message-ID: <jNyrolw83xRpGMQy2MCIoeme6NGGhDVSIBXKQs9IjiE=.092be51d-5333-4507-8c0a-2b02b6f342b1@github.com>

On Wed, 7 Feb 2024 20:53:53 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix adds check that merged constant pool does not overflow u2 (two-byte unsigned).
> The check is added after merging `the_class` and `scratch_class` constant pools, but before rewriting constant pool references.
> 
> testing:
>  - sanity tier1;
>  - all RedefineClasses/RetransformClasses tests:
>    - test/jdk/java/lang/instrument
>    - test/hotspot/jtreg/serviceability/jvmti/RedefineClasses
>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses
>    - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses

This pull request has now been integrated.

Changeset: e33d8a21
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e33d8a219811930492e684e19a73dadb09590052
Stats:     7 lines in 1 file changed: 6 ins; 0 del; 1 mod

8311076: RedefineClasses doesn't check for ConstantPool overflow

Reviewed-by: coleenp, lmesnik

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

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

From dlong at openjdk.org  Sat Feb 10 01:02:07 2024
From: dlong at openjdk.org (Dean Long)
Date: Sat, 10 Feb 2024 01:02:07 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v9]
In-Reply-To: <V98qMF5Nt3FtxSWERvrDp0aoXh6D5n9O70hDYZ8x9AA=.de3befaf-db68-43af-9230-cc54f0455f4b@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <V98qMF5Nt3FtxSWERvrDp0aoXh6D5n9O70hDYZ8x9AA=.de3befaf-db68-43af-9230-cc54f0455f4b@github.com>
Message-ID: <52h64zKHV_1xUjCJ_7cKHvTRwIFudtKdAWo6bv0T5_U=.ac193da2-837f-489b-8ec7-ea883b5c13c8@github.com>

On Fri, 9 Feb 2024 14:35:43 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> ICStubs solve an atomicity problem when setting both the destination and data of an inline cache. Unfortunately, it also leads to occasional safepoint carpets when multiple threads need to ICRefill the stubs at the same time, and spurious GuaranteedSafepointInterval "Cleanup" safepoints every second. This patch changes inline caches to not change the data part at all during the nmethod life cycle, hence removing the need for ICStubs.
>> 
>> The new scheme is less stateful. Instead of adding and removing callsite metadata back and forth when transitioning inline cache states, it installs all state any shape of call will ever need at resolution time in a struct that I call CompiledICData. This reduces inline cache state changes to simply changing the destination of the call, and it doesn't really matter what state transitions to what other state.
>> 
>> With this patch, we get rid of ICStub and ICBuffer classes and the related ICRefill and almost all Cleanup safepoints in practice. It also makes the inline cache code much simpler.
>> 
>> I have tested the changes from tier1-7, and run through full aurora performance tests.
>
> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback from Dean and Thomas

src/hotspot/share/code/nmethod.cpp line 1248:

> 1246:         if (nm != nullptr) {
> 1247:           // Verify that inline caches pointing to bad nmethods are clean
> 1248:           if (!nm->is_in_use() || nm->is_unloading()) {

Please explain this change.  It's not obvious.

src/hotspot/share/gc/x/xUnload.cpp line 104:

> 102: 
> 103:   virtual bool is_safe(CompiledMethod* method) {
> 104:     if (SafepointSynchronize::is_at_safepoint() || method->is_unloading()) {

Please explain why is_unloading() is needed now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1484917912
PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1484918466

From dlong at openjdk.org  Sat Feb 10 01:11:03 2024
From: dlong at openjdk.org (Dean Long)
Date: Sat, 10 Feb 2024 01:11:03 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v9]
In-Reply-To: <V98qMF5Nt3FtxSWERvrDp0aoXh6D5n9O70hDYZ8x9AA=.de3befaf-db68-43af-9230-cc54f0455f4b@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <V98qMF5Nt3FtxSWERvrDp0aoXh6D5n9O70hDYZ8x9AA=.de3befaf-db68-43af-9230-cc54f0455f4b@github.com>
Message-ID: <R_3Y_zhXprnJMVbW2e-r1q6oxEKmTGBWY8brNAMlng8=.12585a72-dcfe-4dae-aeeb-b4257f88fc98@github.com>

On Fri, 9 Feb 2024 14:35:43 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> ICStubs solve an atomicity problem when setting both the destination and data of an inline cache. Unfortunately, it also leads to occasional safepoint carpets when multiple threads need to ICRefill the stubs at the same time, and spurious GuaranteedSafepointInterval "Cleanup" safepoints every second. This patch changes inline caches to not change the data part at all during the nmethod life cycle, hence removing the need for ICStubs.
>> 
>> The new scheme is less stateful. Instead of adding and removing callsite metadata back and forth when transitioning inline cache states, it installs all state any shape of call will ever need at resolution time in a struct that I call CompiledICData. This reduces inline cache state changes to simply changing the destination of the call, and it doesn't really matter what state transitions to what other state.
>> 
>> With this patch, we get rid of ICStub and ICBuffer classes and the related ICRefill and almost all Cleanup safepoints in practice. It also makes the inline cache code much simpler.
>> 
>> I have tested the changes from tier1-7, and run through full aurora performance tests.
>
> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback from Dean and Thomas

src/hotspot/share/runtime/sharedRuntime.cpp line 1774:

> 1772: 
> 1773:   CodeBlob* cb = CodeCache::find_blob(caller_pc);
> 1774:   if (cb == nullptr || !cb->is_compiled() || !callee->is_in_use() || callee->is_unloading()) {

Checking for is_in_use() is just an optimization, right?

src/hotspot/share/runtime/sharedRuntime.cpp line 1808:

> 1806: 
> 1807:   CompiledDirectCall* callsite = CompiledDirectCall::before(return_pc);
> 1808:   callsite->set_to_clean();

Clever way to get rid of should_fixup_call_destination(), something I've wanted to do!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1484920202
PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1484920628

From sspitsyn at openjdk.org  Sat Feb 10 04:06:37 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 10 Feb 2024 04:06:37 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v4]
In-Reply-To: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
Message-ID: <bKkHh3R39JCXKuQGrduWdZhJ9jstNA6xfUnJgPgbslE=.c1e27529-af8c-4707-9d24-473952502459@github.com>

> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
> The function returns the following structure:
> 
> 
> typedef struct {
>     jthread owner;
>     jint entry_count;
>     jint waiter_count;
>     jthread* waiters;
>     jint notify_waiter_count;
>     jthread* notify_waiters;
> } jvmtiMonitorUsage;
> 
> 
> The following four fields are defined this way:
> 
> waiter_count  [jint] The number of threads waiting to own this monitor
> waiters  [jthread*] The waiter_count waiting threads
> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
> 
> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
> This update makes it right.
> 
> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
> 
> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
> 
>   jvmti/GetObjectMonitorUsage/objmonusage001
>   jvmti/GetObjectMonitorUsage/objmonusage003
> 
> 
> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
> 
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
> 
> 
> 
> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository.
> 
> Also, please see and review the related CSR:
>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
> 
> The Release-Note is:
> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage
>  
> Testing:
>  - tested with mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: fixed issues in get_object_monitor_usage; extended test coverage in objmonusage003

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17680/files
  - new: https://git.openjdk.org/jdk/pull/17680/files/3d735722..69ba5e7e

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

  Stats: 155 lines in 8 files changed: 64 ins; 36 del; 55 mod
  Patch: https://git.openjdk.org/jdk/pull/17680.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17680/head:pull/17680

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

From sspitsyn at openjdk.org  Sat Feb 10 07:55:07 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 10 Feb 2024 07:55:07 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v3]
In-Reply-To: <G0pqYyJ_-DfljxP29xptnPh5n76msoUpITc8kXDPrNo=.72e64c5e-2200-4bc7-8e67-632c318f7d25@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <bIMfwFEuiZ1CbUtq3NzEeNuW72i4jAqAHGJKMb_VZdg=.4e228b57-af29-4a78-9534-bae11fa6bb2d@github.com>
 <G0pqYyJ_-DfljxP29xptnPh5n76msoUpITc8kXDPrNo=.72e64c5e-2200-4bc7-8e67-632c318f7d25@github.com>
Message-ID: <d0V0uBx8svh4S5cayV_bgm97b_Gkz59H8TVuPZakYTw=.a3b0840f-673c-4adf-93fa-743b1dc6a7c9@github.com>

On Thu, 8 Feb 2024 07:05:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I think the only way to make sense of this is to actually set up scenarios where we have different threads contending on entry, different threads waiting and different threads re-entering after being notified, and see what values actually get returned in each case.

I've added this kind of test coverage to the test NSK test:
  `test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage003`
 
 > I think the `pending_current_monitor` issue may be a distinct/different issue.
 
 I tried to find a solution fix the `pending_current_monitor` to cover the monitor re-enter case and found that it is not clear how to do it in a straight-forward way. So, decide to leave it alone for now. However, it seems, it could be more elegant to fix this function. I still can make it a try to do that if you give me some hints or ideas on how to do it better.

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

PR Comment: https://git.openjdk.org/jdk/pull/17680#issuecomment-1936920693

From sspitsyn at openjdk.org  Sat Feb 10 08:17:02 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 10 Feb 2024 08:17:02 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v4]
In-Reply-To: <bKkHh3R39JCXKuQGrduWdZhJ9jstNA6xfUnJgPgbslE=.c1e27529-af8c-4707-9d24-473952502459@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <bKkHh3R39JCXKuQGrduWdZhJ9jstNA6xfUnJgPgbslE=.c1e27529-af8c-4707-9d24-473952502459@github.com>
Message-ID: <11HkrzU483RNyYcWEz5-6Qh9p7MlFoqNZu3kiGvwHOQ=.54d4bda7-16f2-4722-a8a3-b718071e40a7@github.com>

On Sat, 10 Feb 2024 04:06:37 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
>> The function returns the following structure:
>> 
>> 
>> typedef struct {
>>     jthread owner;
>>     jint entry_count;
>>     jint waiter_count;
>>     jthread* waiters;
>>     jint notify_waiter_count;
>>     jthread* notify_waiters;
>> } jvmtiMonitorUsage;
>> 
>> 
>> The following four fields are defined this way:
>> 
>> waiter_count  [jint] The number of threads waiting to own this monitor
>> waiters  [jthread*] The waiter_count waiting threads
>> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
>> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
>> 
>> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
>> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
>> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
>> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
>> This update makes it right.
>> 
>> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
>> 
>> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
>> 
>>   jvmti/GetObjectMonitorUsage/objmonusage001
>>   jvmti/GetObjectMonitorUsage/objmonusage003
>> 
>> 
>> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
>> 
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
>> 
>> 
>> 
>> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository.
>> 
>> Also, please see and review the related CSR:
>>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
>> 
>> The Release-Note is:
>> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage
>>  
>> Testing:
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: fixed issues in get_object_monitor_usage; extended test coverage in objmonusage003

I've pushed an update addressing review comments from Dan/David.
This is a short list describing the updates:
 - now the function `Threads::get_pending_threads()` in the `threads.cpp` is supporting the monitor re-enter case
 - introduced the function `oop JavaThread::vthread_or_thread()` used in the function `Threads::get_pending_threads()`
 - the fix in `jvmtiEnvBase.cpp` has been re-arranged to calculate early the right sizes of the `waiters` and `notify_waiters` array
 - the NSK test `test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage003` was extended to provide coverage suggested by David. It recreates a scenario with several threads blocked on the monitor enter, several threads blocked on re-enter and several thread waiting in the `Object.wait()` to be notified.
 - some small test fixes suggested in review

The mach5 tiers 1-6 are all passed except the four known to fail JCK tests in the tier 6.

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

PR Comment: https://git.openjdk.org/jdk/pull/17680#issuecomment-1936927038

From stuefe at openjdk.org  Sat Feb 10 09:52:20 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 10 Feb 2024 09:52:20 GMT
Subject: RFR: JDK-8323497: On x64,
 use 32-bit immediate moves for narrow klass base if possible [v2]
In-Reply-To: <HTQ6J0zq0B3MQRpECfAn_vbkV-rTWN_rsnEVVgkJN0k=.44afeb5e-63a1-4de0-911b-d6db9c5532de@github.com>
References: <HTQ6J0zq0B3MQRpECfAn_vbkV-rTWN_rsnEVVgkJN0k=.44afeb5e-63a1-4de0-911b-d6db9c5532de@github.com>
Message-ID: <toLuxM7q8f6ZxzIhTB4AbM8Z_aVOtz-Tk2BaxiJ7wO4=.394b6722-6223-4b0e-b77c-28301213481b@github.com>

> On x64, we always use the long form of mov immediate to load the klass base into a register. If the klass base fits into 32 bits, we could use the short form and save four instruction bytes. 
> 
> Before: mov uses 10 instruction bytes:
> 
> 
>    35  ;; decode_klass_not_null
>    36   0x00007f8b089e51c4:   movabs $0x82000000,%r11
>    37   0x00007f8b089e51ce:   add    %r11,%r10
> 
> 
> Now: mov uses 6 instruction bytes:
> 
> 
>    35  ;; decode_klass_not_null
>    36   0x00007fbe609e51c4:   mov    $0x82000000,%r11d
>    37   0x00007fbe609e51ca:   add    %r11,%r10
> 
> 
> Note that this also works with CDS enabled and gives us the motivation to allocate low-address ranges unconditionally, even if the zero-based encoding is not possible.
> 
> ----------
> 
> Tests: tier1 (GHA), tier 2 on x64 linux

Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge branch 'openjdk:master' into use-32bit-immediate-moves-on-x64-for-klass-encoding-base
 - remove obsolete comment
 - use-32bit-immediate-moves-on-x64-for-klass-encoding-base

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17340/files
  - new: https://git.openjdk.org/jdk/pull/17340/files/8fe4552b..023d80ce

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

  Stats: 16900 lines in 665 files changed: 11422 ins; 2641 del; 2837 mod
  Patch: https://git.openjdk.org/jdk/pull/17340.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17340/head:pull/17340

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

From aph at openjdk.org  Sat Feb 10 09:52:57 2024
From: aph at openjdk.org (Andrew Haley)
Date: Sat, 10 Feb 2024 09:52:57 GMT
Subject: RFR: JDK-8325264: two compiler/intrinsics/float16 tests fail after
 JDK-8324724 [v2]
In-Reply-To: <cTz7hj1-Fla4UhtOdC-UuPvWYckBKJ8MlljpQeM74jo=.28cfdcc6-6c9b-4a01-83b0-c10424dbbd09@github.com>
References: <eoR3U5uw7lee-9UJA2qwsyF9u89D_vW83xykuszAMcU=.f70552a1-d96a-4895-99ac-33dfd0942de2@github.com>
 <M0rTewgJ5HXWlAysDqYk-KiFyZzmweHXLGR_0nfGlTA=.4e0bff92-5547-4e0f-9cc1-6a0f4de24d52@github.com>
 <d6aCSQ6ivkgfAQ5pnSNXHIOlZz6GtIiski002-T3cus=.ec07eee9-0712-4bc4-a79a-fdb2ee371f89@github.com>
 <cTz7hj1-Fla4UhtOdC-UuPvWYckBKJ8MlljpQeM74jo=.28cfdcc6-6c9b-4a01-83b0-c10424dbbd09@github.com>
Message-ID: <TkBjh2Lrhg2yU5YoAXg6HO0TsJE3uoxYFNAKPWZPQ_w=.8ddc411b-8dd8-4ce8-9992-5b55d4075045@github.com>

On Thu, 8 Feb 2024 20:33:44 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

>> Yes, probably a better idea to make sure the address (of the stub) being accessed is valid before making that memory region executable. Will make changes and update. Thanks!
>
> Done

Flipping to execute and back during compilation seems to me to be a bad idea. I'd do it in inline asm instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17733#discussion_r1485037142

From duke at openjdk.org  Sun Feb 11 13:10:52 2024
From: duke at openjdk.org (Lei Zaakjyu)
Date: Sun, 11 Feb 2024 13:10:52 GMT
Subject: RFR: 8325082: Rename headers named 'heapRegion*' of G1 [v2]
In-Reply-To: <1MWMgluBwGY-FydUnpoksJ0q5sSvptrNMv6xwDszBQc=.a78cadad-1585-44d1-97d0-a7928fe34d67@github.com>
References: <1MWMgluBwGY-FydUnpoksJ0q5sSvptrNMv6xwDszBQc=.a78cadad-1585-44d1-97d0-a7928fe34d67@github.com>
Message-ID: <k0b9OzRc039GMlOB9-HakdBE2XcKljQ_0GC5mWJ2u0E=.9e13f5e7-bd42-4fb6-8fed-6ead29adf668@github.com>

> 8325082: Rename headers named 'heapRegion*' of G1

Lei Zaakjyu has updated the pull request incrementally with one additional commit since the last revision:

  reorder some headers

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17666/files
  - new: https://git.openjdk.org/jdk/pull/17666/files/2d38a1b7..7d105a58

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

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

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

From coleenp at openjdk.org  Sun Feb 11 19:27:56 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Sun, 11 Feb 2024 19:27:56 GMT
Subject: RFR: 8319797: Recursive lightweight locking: Runtime
 implementation [v18]
In-Reply-To: <JSwpvtOSOCMkejITJFXnsJGjTMO8NOz7nZk6ck-2I-U=.a582232b-4fd4-474c-9951-17111f7942ed@github.com>
References: <ZWyjRIBdi5FeGTDfaIEmT_lBfg1n9MDl3vxA5g-FKbc=.cb26afcc-555b-4a80-b4f2-319c5422646b@github.com>
 <JSwpvtOSOCMkejITJFXnsJGjTMO8NOz7nZk6ck-2I-U=.a582232b-4fd4-474c-9951-17111f7942ed@github.com>
Message-ID: <y-AMsyoIutgPV3A1jUf2KeD-FvdK4Rw3MMady65thLU=.86bc2f01-f460-40bf-b5ed-f96ef416e703@github.com>

On Thu, 8 Feb 2024 10:37:13 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Implements the runtime part of JDK-8319796.
>> The different CPU implementations are/will be created as dependent pull requests.
>> 
>> This enhancement proposes introducing the ability for LM_LIGHTWEIGHT to handle consecutive recursive monitor enter. Limiting the implementation to only consecutive monitor enters allows for more efficient emitted code which only needs to look at the two top most entires on the lock stack to determine what to do in a monitor exit.
>> 
>> A high level overview:
>>   * Locking is still performed on the mark word
>>     * Unlocked (0b01) <=> Locked (0b00)
>>   * Monitor enter on Obj with mark word Unlocked (0b01) is the same
>>     * Transition Obj's mark word Unlocked (0b01) => Locked (0b00)
>>     * Push Obj onto the lock stack
>>     * Success
>>   * Monitor enter on Obj with mark word Locked (0b00) will check the top entry on the lock stack
>>     * If top entry is Obj
>>       * Push Obj on the lock stack
>>       * Success
>>     * If top entry is not Obj
>>       * Inflate and call ObjectMonitor::enter
>>   * Monitor exit on Obj with mark word Locked (0b00) will check the two top entries on the lock stack
>>     * If just the top entry is Obj
>>       * Transition Obj's mark word Locked (0b00) => Unlocked (0b01)
>>       * Pop the entry
>>       * Success
>>     * If both entries are Obj
>>       * Pop the top entry
>>       * Success
>>     * Any other case only occurs for unstructured locking, then just inflate and call ObjectMonitor::exit
>>   * If the monitor has been inflated for object Obj which is owned by the current thread
>>     * All corresponding entries for Obj is removed from the lock stack
>>     * The monitor recursions is set to the number of removed entries - 1
>>     * The owner is changed from anonymous to the thread
>>     * The regular ObjectMonitor::action is called.
>
> 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 54 commits:
> 
>  - Running out of LogTagSets, stick with monitorinflation
>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8319797
>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8319797
>  - Fix assert comment
>  - Update copyright
>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8319797
>  - Add verify calls
>  - Assert valid lock stack offset
>  - Typos, wording and whitespace
>  - Fix miss in is_recursive improvement
>  - ... and 44 more: https://git.openjdk.org/jdk/compare/1fb9e3d6...6f76413d

We have done performance testing on the recursive locking implementation vs the existing lightweight locking implementation, and the results were much better on some worst cases, like J2DBench, reduces monitor inflation, and neutral on others, with a couple of small regressions on linux-aarch64 (Derby) that we will investigate as further work before making LM_LIGHTWEIGHT the default.  We at Oracle feel that this PR is ready for integration.  It's a nice implementation and improvement and great work.  Thank you!
This applies to the x86 and aarch64 implementation PRs as well, and we're looking forward to seeing the riscv and ppc ports and results from these platforms also.

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

PR Comment: https://git.openjdk.org/jdk/pull/16606#issuecomment-1937844874

From stefank at openjdk.org  Mon Feb 12 08:22:54 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 12 Feb 2024 08:22:54 GMT
Subject: RFR: 8325082: Rename headers named 'heapRegion*' of G1 [v2]
In-Reply-To: <k0b9OzRc039GMlOB9-HakdBE2XcKljQ_0GC5mWJ2u0E=.9e13f5e7-bd42-4fb6-8fed-6ead29adf668@github.com>
References: <1MWMgluBwGY-FydUnpoksJ0q5sSvptrNMv6xwDszBQc=.a78cadad-1585-44d1-97d0-a7928fe34d67@github.com>
 <k0b9OzRc039GMlOB9-HakdBE2XcKljQ_0GC5mWJ2u0E=.9e13f5e7-bd42-4fb6-8fed-6ead29adf668@github.com>
Message-ID: <vQ-b6TFNzx3nimeq4urpMlzOkHR5Sp4Mo1Tle6aQfmc=.0f95a11e-e3d4-4cdb-bc85-da832384a5e6@github.com>

On Sun, 11 Feb 2024 13:10:52 GMT, Lei Zaakjyu <duke at openjdk.org> wrote:

>> 8325082: Rename headers named 'heapRegion*' of G1
>
> Lei Zaakjyu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reorder some headers

Looks good to me. There's just a few sort-order issues that needs to be fixed. Please, wait for one of the G1 devs to also review the patch.

src/hotspot/share/gc/g1/g1HeapRegion.hpp line 31:

> 29: #include "gc/g1/g1HeapRegionTracer.hpp"
> 30: #include "gc/g1/g1HeapRegionType.hpp"
> 31: #include "gc/g1/g1HeapRegionTraceType.hpp"

Sort order needs to be fixed here.

src/hotspot/share/gc/g1/g1RemSet.cpp line 38:

> 36: #include "gc/g1/g1HeapRegion.inline.hpp"
> 37: #include "gc/g1/g1HeapRegionManager.inline.hpp"
> 38: #include "gc/g1/g1HeapRegionRemSet.inline.hpp"

Sort order. Should go after g1GC.

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

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17666#pullrequestreview-1874702381
PR Review Comment: https://git.openjdk.org/jdk/pull/17666#discussion_r1485846549
PR Review Comment: https://git.openjdk.org/jdk/pull/17666#discussion_r1485847673

From aboldtch at openjdk.org  Mon Feb 12 09:10:30 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 12 Feb 2024 09:10:30 GMT
Subject: RFR: 8319801: Recursive lightweight locking: aarch64
 implementation [v15]
In-Reply-To: <AE1nsnyRCUHR970jjg4feUm5f6E1GPJvea0ooC6dCgI=.73fff610-c0f6-422a-a45d-88187b37b9a2@github.com>
References: <AE1nsnyRCUHR970jjg4feUm5f6E1GPJvea0ooC6dCgI=.73fff610-c0f6-422a-a45d-88187b37b9a2@github.com>
Message-ID: <baEgD9pIHSZRgGBHK4gXRVtHULSBO3w1bfPwwc-6tRw=.8a159e65-2cf7-492b-aac0-e87aa0262ba9@github.com>

> Implements the aarch64 port of JDK-8319796.
> 
> There are two major parts for the port implementation. The C2 part, and the part shared by the interpreter, C1 and the native call wrapper.
> 
> The biggest change for both parts is that we check the lock stack first and if it is a recursive lightweight [un]lock and in that case simply pop/push and finish successfully.
> 
> Only if the recursive lightweight [un]lock fails does it look at the mark word. 
> 
> For the shared part if it is an unstructured exit, the monitor is inflated or the mark word transition fails it calls into the runtime.
> 
> The C2 operates under a few more assumptions, that the locking is structured and balanced. This means that some checks can be elided. 
> 
> First this means that in C2 unlock if the obj is not on the top of the lock stack, it must be inflated. And reversely if we reach the inflated C2 unlock the obj is not on the lock stack. This second property makes it possible to avoid reading the owner (and checking if it is anonymous). Instead it can either just do an un-contended unlock by writing null to the owner, or if contention happens, simply write the thread to the owner and jump to the runtime. 
> 
> The aarch64 C2 port tries to avoid stronger memory semantics where ever possible. In C2 lock it first does a relaxed load of the mark word to check for inflation. Both lock and unlock uses a load/store exclusive register pair to transition the mark word.

Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:

  Revert "Update src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp"
  
  This reverts commit 130cf4b7f5b37ecb9dda3ce07ed70c3da13b29b8.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16608/files
  - new: https://git.openjdk.org/jdk/pull/16608/files/9b9e1927..35d945a5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16608&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16608&range=13-14

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

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

From sroy at openjdk.org  Mon Feb 12 09:38:21 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 12 Feb 2024 09:38:21 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v18]
In-Reply-To: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
Message-ID: <I04hsx099FrxENJZ4KGSKb7kFNs2WkXfzVrIs229rW0=.ed7c0b54-9a92-4f0c-9843-d362b9c1d75a@github.com>

> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am.
> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX.
> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails.

Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:

  update comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16604/files
  - new: https://git.openjdk.org/jdk/pull/16604/files/f4b85357..ca75a337

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=16-17

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

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

From rehn at openjdk.org  Mon Feb 12 09:55:08 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 12 Feb 2024 09:55:08 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v6]
In-Reply-To: <LDIokk_CZPax2Z5O7Pddvog7TkRS-YUT-zN8cSCmBPg=.76cac941-be1c-4e63-ba2e-d0e0048d4a7b@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <Js-W9WYOu68u4cBZo9DuBjtFcnI99c-hJ76dfn15gmA=.ede77c5e-8be9-44b8-80ac-46e77e1bd10f@github.com>
 <ntKnOaWbggDKycTJ6tC0zucfA1eEokg3OsIGh-Z0GkQ=.76bf6dc3-552c-4833-b04a-89ef34746a51@github.com>
 <zm-A8OH6z1gNvLGJMYPaZZHbhKLmidwwwxQ77KpIJBU=.c524e06a-fda4-4f30-84a3-b7a19779cdc9@github.com>
 <2digqyA8oO2r8CnmyFKAjlz6oYo_ReR1zQR-1TfkcOE=.b82a146a-4705-4afc-a53c-7b74448d3e11@github.com>
 <LDIokk_CZPax2Z5O7Pddvog7TkRS-YUT-zN8cSCmBPg=.76cac941-be1c-4e63-ba2e-d0e0048d4a7b@github.com>
Message-ID: <XyEyNy-KOxBgvrBjmXRaSCA_8jJAK3DUkov33NhsgSo=.db1dba00-82ba-48d8-8d57-fa9be0f19955@github.com>

On Fri, 9 Feb 2024 22:02:47 GMT, Dean Long <dlong at openjdk.org> wrote:

> > Secondly, if an I-fetch gets data not intended to be decoded, the cpu can get upset in some cases.
> 
> I've heard that in the past, and always wondered, does it matter if the data is "reachable"? What if it's on the other side of an unconditional branch?

I don't think it's an guarantee. E.g. an uncond branch may be encoded with multiple instruction, so it might be seen as an indirect jump.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1485944023

From eosterlund at openjdk.org  Mon Feb 12 10:38:03 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 12 Feb 2024 10:38:03 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v9]
In-Reply-To: <yuZxiWcPqLZAIVAVuc39YZT33KESsc5-VVduN50w_uw=.d0798154-8cb0-47e1-ab39-2eea7f285db0@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <V98qMF5Nt3FtxSWERvrDp0aoXh6D5n9O70hDYZ8x9AA=.de3befaf-db68-43af-9230-cc54f0455f4b@github.com>
 <yuZxiWcPqLZAIVAVuc39YZT33KESsc5-VVduN50w_uw=.d0798154-8cb0-47e1-ab39-2eea7f285db0@github.com>
Message-ID: <GYxVIT0GsT6uRY-RyXAZ4HCnwxsm0Bg-Idb8E9fYfEg=.01c8266c-fe62-4fb8-8c0a-0f4b180878ec@github.com>

On Fri, 9 Feb 2024 21:27:58 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Feedback from Dean and Thomas
>
> src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 1554:
> 
>> 1552:     __ far_jump(RuntimeAddress(SharedRuntime::get_handle_wrong_method_stub()));
>> 1553: 
>> 1554:     // Verified entry point must be aligned
> 
> I think this comment should come around line 1539.

Okay, I will fix it.

> src/hotspot/cpu/arm/sharedRuntime_arm.cpp line 823:
> 
>> 821:   __ ic_check(CodeEntryAlignment /* end_alignment */);
>> 822: 
>> 823:   int vep_offset = __ pc() - start;
> 
> Maybe add back
> `// Verified entry point`
> above this line.

Sure.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1485997296
PR Review Comment: https://git.openjdk.org/jdk/pull/17495#discussion_r1485997474

From eosterlund at openjdk.org  Mon Feb 12 11:04:23 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 12 Feb 2024 11:04:23 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v10]
In-Reply-To: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
Message-ID: <S1rfjGVAu5fYdrqOyadzHXLRT99jKBW3urvQXYEuhZs=.e999799e-6cdf-4289-9f3c-9519e1c878a7@github.com>

> ICStubs solve an atomicity problem when setting both the destination and data of an inline cache. Unfortunately, it also leads to occasional safepoint carpets when multiple threads need to ICRefill the stubs at the same time, and spurious GuaranteedSafepointInterval "Cleanup" safepoints every second. This patch changes inline caches to not change the data part at all during the nmethod life cycle, hence removing the need for ICStubs.
> 
> The new scheme is less stateful. Instead of adding and removing callsite metadata back and forth when transitioning inline cache states, it installs all state any shape of call will ever need at resolution time in a struct that I call CompiledICData. This reduces inline cache state changes to simply changing the destination of the call, and it doesn't really matter what state transitions to what other state.
> 
> With this patch, we get rid of ICStub and ICBuffer classes and the related ICRefill and almost all Cleanup safepoints in practice. It also makes the inline cache code much simpler.
> 
> I have tested the changes from tier1-7, and run through full aurora performance tests.

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

  Some comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17495/files
  - new: https://git.openjdk.org/jdk/pull/17495/files/08c146b7..29790afe

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

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

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

From eosterlund at openjdk.org  Mon Feb 12 11:04:23 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 12 Feb 2024 11:04:23 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v9]
In-Reply-To: <2zDHeeRc4pWQetiIzFMR0JwjZ5ExX7_OV8Yx9G4o_mg=.066b11a8-6a49-455e-a985-3fb5de974480@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <V98qMF5Nt3FtxSWERvrDp0aoXh6D5n9O70hDYZ8x9AA=.de3befaf-db68-43af-9230-cc54f0455f4b@github.com>
 <2zDHeeRc4pWQetiIzFMR0JwjZ5ExX7_OV8Yx9G4o_mg=.066b11a8-6a49-455e-a985-3fb5de974480@github.com>
Message-ID: <Hd44pKQqK-nLCQOQ-3yxA6i_e8DmABPiqS-c5MmMcxw=.1b06996b-2362-411e-a0d6-0f09139eadc4@github.com>

On Sat, 10 Feb 2024 00:35:47 GMT, Dean Long <dlong at openjdk.org> wrote:

> If I just look at the new code, everything looks very reasonable. I tried to compare the new code to the old code, but quickly gave up.

:)

> Could you explain why opt_virtual can now be a direct call and CompiledIC is now only for virtual? It seems like we could have done that even with the old code.

Sure! So I think at some point we had static calls and virtual calls, with virtual calls using CompiledIC and static calls using CompiledStaticCall. I think there must have been some confusion at some point when introducing opt_virtual. They are virtual calls, so it might have seem "natural" to jam them into CompiledIC, and have CompiledIC deal with them. But since they in their code shapes are a lot more similar to static calls, with a direct call and a stub for interpreter entry, it never was a great fit. To deal with it we had to 1) ensure the data is always null as there is no data, because it isn't really an inline cache, 2) check for it everywhere to not spin up ICStubs when transitioning, because it isn't really an inline cache, and then when manipulating the callsite, have some some native call wrapper abstraction with virtual calls that would convert requests to update the inline cache to update the corresponding direct call and stub instead for optimized virtual calls, and 
 get out of the inline cache world.

To me this always seemed a bit backwards. So in my new implementation I instead accept that opt_virtual calls really are more like the static calls (generated code is identical), and have pretty much nothing to do with inline caches, despite being virtual calls, and made them both use a common DirectCall abstraction instead, that fit both of them, as they are both direct calls.

Could we have cleaned that up earlier? Yes, probably. But it was pretty ingrained and "interesting" to change with incremental changes. I figured this was my chance to do this right since I'm rewriting the CompiledIC file pretty much from scratch as you noticed. I hope you agree with this decision.

> Also, why don't we have to check for method->is_old() anymore?

The checks for is_old were there because when performing an inline cache transition, we had situations where we would need an ICStub, and after running out of ICStubs we would have to request a safepoint to refill ICStubs. That safepoint could sneak in a class redefinition operation, rendering the methods invalid, or at least is_old(). Since I removed ICStubs and don't need any ICStubs to transition inline caches, we also get any safepoints in this code. And therefore we can't get any class redefinition, and hence can remove all the is_old() checks, which are now effectively dead code.

Thanks for the review @dean-long! I updated the comments as requested.

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

PR Comment: https://git.openjdk.org/jdk/pull/17495#issuecomment-1938453986
PR Comment: https://git.openjdk.org/jdk/pull/17495#issuecomment-1938457516

From coleenp at openjdk.org  Mon Feb 12 13:59:05 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 12 Feb 2024 13:59:05 GMT
Subject: RFR: 8319801: Recursive lightweight locking: aarch64
 implementation [v15]
In-Reply-To: <baEgD9pIHSZRgGBHK4gXRVtHULSBO3w1bfPwwc-6tRw=.8a159e65-2cf7-492b-aac0-e87aa0262ba9@github.com>
References: <AE1nsnyRCUHR970jjg4feUm5f6E1GPJvea0ooC6dCgI=.73fff610-c0f6-422a-a45d-88187b37b9a2@github.com>
 <baEgD9pIHSZRgGBHK4gXRVtHULSBO3w1bfPwwc-6tRw=.8a159e65-2cf7-492b-aac0-e87aa0262ba9@github.com>
Message-ID: <9uZWOuw3VN4Jnd9typEd0nqw-RXtATbeDCPTSJ1NOUo=.6346c6d1-b208-4319-aa62-5ced8df9de38@github.com>

On Mon, 12 Feb 2024 09:10:30 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Implements the aarch64 port of JDK-8319796.
>> 
>> There are two major parts for the port implementation. The C2 part, and the part shared by the interpreter, C1 and the native call wrapper.
>> 
>> The biggest change for both parts is that we check the lock stack first and if it is a recursive lightweight [un]lock and in that case simply pop/push and finish successfully.
>> 
>> Only if the recursive lightweight [un]lock fails does it look at the mark word. 
>> 
>> For the shared part if it is an unstructured exit, the monitor is inflated or the mark word transition fails it calls into the runtime.
>> 
>> The C2 operates under a few more assumptions, that the locking is structured and balanced. This means that some checks can be elided. 
>> 
>> First this means that in C2 unlock if the obj is not on the top of the lock stack, it must be inflated. And reversely if we reach the inflated C2 unlock the obj is not on the lock stack. This second property makes it possible to avoid reading the owner (and checking if it is anonymous). Instead it can either just do an un-contended unlock by writing null to the owner, or if contention happens, simply write the thread to the owner and jump to the runtime. 
>> 
>> The aarch64 C2 port tries to avoid stronger memory semantics where ever possible. In C2 lock it first does a relaxed load of the mark word to check for inflation. Both lock and unlock uses a load/store exclusive register pair to transition the mark word.
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Update src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp"
>   
>   This reverts commit 130cf4b7f5b37ecb9dda3ce07ed70c3da13b29b8.

Why didn't the asserts below this find that ZR was not set?

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

PR Review: https://git.openjdk.org/jdk/pull/16608#pullrequestreview-1875295077

From aboldtch at openjdk.org  Mon Feb 12 14:14:55 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 12 Feb 2024 14:14:55 GMT
Subject: RFR: 8319801: Recursive lightweight locking: aarch64
 implementation [v15]
In-Reply-To: <9uZWOuw3VN4Jnd9typEd0nqw-RXtATbeDCPTSJ1NOUo=.6346c6d1-b208-4319-aa62-5ced8df9de38@github.com>
References: <AE1nsnyRCUHR970jjg4feUm5f6E1GPJvea0ooC6dCgI=.73fff610-c0f6-422a-a45d-88187b37b9a2@github.com>
 <baEgD9pIHSZRgGBHK4gXRVtHULSBO3w1bfPwwc-6tRw=.8a159e65-2cf7-492b-aac0-e87aa0262ba9@github.com>
 <9uZWOuw3VN4Jnd9typEd0nqw-RXtATbeDCPTSJ1NOUo=.6346c6d1-b208-4319-aa62-5ced8df9de38@github.com>
Message-ID: <MPLIux1CHGo9A0nsFU4gzxX2v7_eyTkIcjmHJWrFVZM=.47d10ee5-af27-4879-8aca-c63892c24d37@github.com>

On Mon, 12 Feb 2024 13:55:58 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Why didn't the asserts below this find that ZR was not set? Unless we don't hit this path with our testing in debug mode?

Had not run a proper run with `LockingMode == LM_LIGHTWEIGHT` as default since that commit. So found it when I sent of a run, and yes the C2 assert that checked this found it. 

GitHub actions has very limited non LM_LEGACY testing. Our LM_LIGHTWEIGHT teir3 testing would catch this. It had just not been ran since that commit.

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

PR Comment: https://git.openjdk.org/jdk/pull/16608#issuecomment-1938755365

From duke at openjdk.org  Mon Feb 12 15:13:07 2024
From: duke at openjdk.org (duke)
Date: Mon, 12 Feb 2024 15:13:07 GMT
Subject: Withdrawn: 8274051: remove supports_vtime()
In-Reply-To: <35gxEbiDfghFA2QnjBjp1PXw-D6mGyZA-eTT-k_kGgM=.a3f8337e-7142-42bc-81af-91afe8bf517e@github.com>
References: <35gxEbiDfghFA2QnjBjp1PXw-D6mGyZA-eTT-k_kGgM=.a3f8337e-7142-42bc-81af-91afe8bf517e@github.com>
Message-ID: <B5d8IvopeEe0Hxeog_XRETYX_2U4_6L_0x5a6P4Kjdw=.b3c70d87-9b15-4b9f-9d6f-8290aa206842@github.com>

On Fri, 15 Dec 2023 15:34:50 GMT, Lei Zaakjyu <duke at openjdk.org> wrote:

> 8274051: remove supports_vtime()

This pull request has been closed without being integrated.

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

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

From ihse at openjdk.org  Mon Feb 12 15:45:15 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 12 Feb 2024 15:45:15 GMT
Subject: RFR: 8252136: Several methods in hotspot are missing "static"
Message-ID: <dleKPT17nKiOOWVZg8Jm9pMPiUFe6KfqSfR-gDQK63c=.fbc6290d-eec4-43e8-8970-9d773a115eb6@github.com>

There are several places in hotspot where an internal function should have been declared static, but isn't. 

These were discovered by trying to use the gcc option `-Wmissing-declarations` and the corresponding clang option `-Wmissing-prototypes`. These warnings check that a function either:
a) is declared static, or
b) has a declaration before its definition. 

The rationale of this is that functions are either internal to a compilation unit, or exported to be linked by some other compilation unit. In the former case, it should be marked static. In the latter case, it should be declared in a header file, which should be included by the implementation as well. If there is a discrepancy between the exported prototype and the implemented prototype, this will be discovered during compilation (instead of as a runtime error). Additionally, marking internal methods as static allows the compiler to make better optimization, like inlining.

This seem to be to be a sane assumption, and I think Hotspot (and the entire JDK) would increase code quality by turning on these warnings. The absolute majority of the code already adheres to these rules, but there are still some places that needs to be fixed.

This is the first part of addressing these issues, where all places that are trivially missing static are fixed.

I have discovered these by running with the warnings mentioned above turned on. I have filtered out those places were an export was obviously missing. The remaining warnings I have manually inspected. About 1/4 of them were *_init() functions (which are directly declared in `init.cpp`) and another 1/4 were documented as "use in debugger"; these I have not touched. I also ignored functions with names suggesting it might be used in the debugger, even if not documented as such, or any places that even seemed remotely non-trivial. Finally I also reverted a few changes after it turned out that gcc complained about unused functions. These places are actually dead code, but it is not clear if they should be removed or if there is actually a call missing somewhere (I believe it is a mix of both). In any case, I did not want any such complexities in this PR.

When the functions where marked static, gcc started complaining if they were not used, since it consider it dead code. To address this, I had to add or fix some `#ifdef`s. Since this code were not actually used unless these criteria were fulfilled before either (it was just not discovered by the compiler), I think this is mostly a good thing.

Finally, I have manually searched for each and every one of these functions (tedious!) and verified that they are indeed only called from within the specific file. But in the end, the proof should be in the pudding -- if hotspot still compiles with these changes, then they should be correct. (The one exception to this is if the symbol is supposed to be used in e.g. the debugger, and I've missed that.)

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

Commit messages:
 - 8252136: Several methods in hotspot are missing "static"

Changes: https://git.openjdk.org/jdk/pull/17806/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17806&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8252136
  Stats: 204 lines in 72 files changed: 6 ins; 2 del; 196 mod
  Patch: https://git.openjdk.org/jdk/pull/17806.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17806/head:pull/17806

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

From coleenp at openjdk.org  Mon Feb 12 16:02:02 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 12 Feb 2024 16:02:02 GMT
Subject: RFR: 8252136: Several methods in hotspot are missing "static"
In-Reply-To: <dleKPT17nKiOOWVZg8Jm9pMPiUFe6KfqSfR-gDQK63c=.fbc6290d-eec4-43e8-8970-9d773a115eb6@github.com>
References: <dleKPT17nKiOOWVZg8Jm9pMPiUFe6KfqSfR-gDQK63c=.fbc6290d-eec4-43e8-8970-9d773a115eb6@github.com>
Message-ID: <naynULoIqgttnKEf5x-9WqLWp0ODiQsWm2EXiny2DcQ=.20ba4f93-1e27-41a2-9d0b-0c5f2f20aa82@github.com>

On Mon, 12 Feb 2024 12:43:09 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> There are several places in hotspot where an internal function should have been declared static, but isn't. 
> 
> These were discovered by trying to use the gcc option `-Wmissing-declarations` and the corresponding clang option `-Wmissing-prototypes`. These warnings check that a function either:
> a) is declared static, or
> b) has a declaration before its definition. 
> 
> The rationale of this is that functions are either internal to a compilation unit, or exported to be linked by some other compilation unit. In the former case, it should be marked static. In the latter case, it should be declared in a header file, which should be included by the implementation as well. If there is a discrepancy between the exported prototype and the implemented prototype, this will be discovered during compilation (instead of as a runtime error). Additionally, marking internal methods as static allows the compiler to make better optimization, like inlining.
> 
> This seem to be to be a sane assumption, and I think Hotspot (and the entire JDK) would increase code quality by turning on these warnings. The absolute majority of the code already adheres to these rules, but there are still some places that needs to be fixed.
> 
> This is the first part of addressing these issues, where all places that are trivially missing static are fixed.
> 
> I have discovered these by running with the warnings mentioned above turned on. I have filtered out those places were an export was obviously missing. The remaining warnings I have manually inspected. About 1/4 of them were *_init() functions (which are directly declared in `init.cpp`) and another 1/4 were documented as "use in debugger"; these I have not touched. I also ignored functions with names suggesting it might be used in the debugger, even if not documented as such, or any places that even seemed remotely non-trivial. Finally I also reverted a few changes after it turned out that gcc complained about unused functions. These places are actually dead code, but it is not clear if they should be removed or if there is actually a call missing somewhere (I believe it is a mix of both). In any case, I did not want any such complexities in this PR.
> 
> When the functions where marked static, gcc started complaining if they were not used, since it consider it dead code. To address this, I had to add or fix some `#ifdef`s. Since this code were not actually used unless these criteria were fulfilled before either (it was just not discovered by the compiler), I thi...

Nice change. I looked at the runtime files, and surprised there weren't more.  Thank you.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17806#pullrequestreview-1875580015

From coleenp at openjdk.org  Mon Feb 12 16:11:05 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 12 Feb 2024 16:11:05 GMT
Subject: RFR: 8319801: Recursive lightweight locking: aarch64
 implementation [v15]
In-Reply-To: <MPLIux1CHGo9A0nsFU4gzxX2v7_eyTkIcjmHJWrFVZM=.47d10ee5-af27-4879-8aca-c63892c24d37@github.com>
References: <AE1nsnyRCUHR970jjg4feUm5f6E1GPJvea0ooC6dCgI=.73fff610-c0f6-422a-a45d-88187b37b9a2@github.com>
 <baEgD9pIHSZRgGBHK4gXRVtHULSBO3w1bfPwwc-6tRw=.8a159e65-2cf7-492b-aac0-e87aa0262ba9@github.com>
 <9uZWOuw3VN4Jnd9typEd0nqw-RXtATbeDCPTSJ1NOUo=.6346c6d1-b208-4319-aa62-5ced8df9de38@github.com>
 <MPLIux1CHGo9A0nsFU4gzxX2v7_eyTkIcjmHJWrFVZM=.47d10ee5-af27-4879-8aca-c63892c24d37@github.com>
Message-ID: <LM-gRM-LyswJmETxiu1sGMBS5RNfPLKMznZcZ7kW1xk=.2037b84e-e2e8-4922-be7e-0e6a6a2566bb@github.com>

On Mon, 12 Feb 2024 14:12:14 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> GitHub actions has very limited non LM_LEGACY testing. Our LM_LIGHTWEIGHT teir3 testing would catch this. It had just not been ran since that commit.

Good, that's a relief. We don't have to add new testing for it.

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

PR Comment: https://git.openjdk.org/jdk/pull/16608#issuecomment-1939002400

From stefank at openjdk.org  Mon Feb 12 16:51:03 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 12 Feb 2024 16:51:03 GMT
Subject: RFR: 8252136: Several methods in hotspot are missing "static"
In-Reply-To: <dleKPT17nKiOOWVZg8Jm9pMPiUFe6KfqSfR-gDQK63c=.fbc6290d-eec4-43e8-8970-9d773a115eb6@github.com>
References: <dleKPT17nKiOOWVZg8Jm9pMPiUFe6KfqSfR-gDQK63c=.fbc6290d-eec4-43e8-8970-9d773a115eb6@github.com>
Message-ID: <Q3erX6U9Da2519qpJINXRwbnQhOIIguE3A7DbApjUvE=.b85f3d69-5903-4f9b-8564-508dfca152b6@github.com>

On Mon, 12 Feb 2024 12:43:09 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> There are several places in hotspot where an internal function should have been declared static, but isn't. 
> 
> These were discovered by trying to use the gcc option `-Wmissing-declarations` and the corresponding clang option `-Wmissing-prototypes`. These warnings check that a function either:
> a) is declared static, or
> b) has a declaration before its definition. 
> 
> The rationale of this is that functions are either internal to a compilation unit, or exported to be linked by some other compilation unit. In the former case, it should be marked static. In the latter case, it should be declared in a header file, which should be included by the implementation as well. If there is a discrepancy between the exported prototype and the implemented prototype, this will be discovered during compilation (instead of as a runtime error). Additionally, marking internal methods as static allows the compiler to make better optimization, like inlining.
> 
> This seem to be to be a sane assumption, and I think Hotspot (and the entire JDK) would increase code quality by turning on these warnings. The absolute majority of the code already adheres to these rules, but there are still some places that needs to be fixed.
> 
> This is the first part of addressing these issues, where all places that are trivially missing static are fixed.
> 
> I have discovered these by running with the warnings mentioned above turned on. I have filtered out those places were an export was obviously missing. The remaining warnings I have manually inspected. About 1/4 of them were *_init() functions (which are directly declared in `init.cpp`) and another 1/4 were documented as "use in debugger"; these I have not touched. I also ignored functions with names suggesting it might be used in the debugger, even if not documented as such, or any places that even seemed remotely non-trivial. Finally I also reverted a few changes after it turned out that gcc complained about unused functions. These places are actually dead code, but it is not clear if they should be removed or if there is actually a call missing somewhere (I believe it is a mix of both). In any case, I did not want any such complexities in this PR.
> 
> When the functions where marked static, gcc started complaining if they were not used, since it consider it dead code. To address this, I had to add or fix some `#ifdef`s. Since this code were not actually used unless these criteria were fulfilled before either (it was just not discovered by the compiler), I thi...

The argument alignment is wonky after this patch. Could you go over the patch and fix that?

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

Changes requested by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17806#pullrequestreview-1875713907

From sroy at openjdk.org  Mon Feb 12 17:25:15 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 12 Feb 2024 17:25:15 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v14]
In-Reply-To: <1kzsCJOR4U-lc77vCBrS_Oa4YCoBv5a7Zz8gKDHDuXg=.9471c3b3-cea7-415b-aa18-79aa76f508d1@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <cNyV9jVxZtoIf9qgQbTQ86Syu95kql6wC5C1DzgiRPs=.8d2f1d5b-b64a-41b8-87f2-c8d31b0e98c0@github.com>
 <VDnWgKmkKKxKGDnT3_7xmpl6wVqrs6n0Z_mOVWsesCg=.cd4a8667-4086-450e-8fe1-df023ad0acb5@github.com>
 <JBjZF1htM8fykk9uKOcxDq3SUQq2oZ9d2kgitPGcpsY=.34d1e014-65a8-443d-9c62-04ba8fd8819b@github.com>
 <1kzsCJOR4U-lc77vCBrS_Oa4YCoBv5a7Zz8gKDHDuXg=.9471c3b3-cea7-415b-aa18-79aa76f508d1@github.com>
Message-ID: <mYgHphufoa-3oRbdJw_65u4xktqnHA5OnrigSBC2NwI=.85ba4aa9-2143-4f68-8aa5-5100575ecafe@github.com>

On Thu, 8 Feb 2024 14:39:24 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> > > The trailing whitespace errors must get fixed (integration blocker).
> > 
> > 
> > I am unable to resolve this. The spaces seem fine as i see it in the terminal. Could it be some other error ?
> 
> Strange. I don't see any whitespace problem, either. Maybe it's possible to rerun jcheck (GitHub Actions). Otherwise, you may need to create a new PR.

Re running tests is not helping as i made more commits. Not sure why it arrived all of a sudden.

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

PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1939190557

From sroy at openjdk.org  Mon Feb 12 17:41:14 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 12 Feb 2024 17:41:14 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v19]
In-Reply-To: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
Message-ID: <RKJezvmq9TjOPsG3tdG_WeQuL1bjusewSQoJj-VNYf0=.e82671a1-ac60-48b7-aaa4-7d6cfd8fff7c@github.com>

> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am.
> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX.
> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails.

Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:

  Check to revert commit and do jcheck

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16604/files
  - new: https://git.openjdk.org/jdk/pull/16604/files/ca75a337..b5cf57d6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=17-18

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

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

From sroy at openjdk.org  Mon Feb 12 17:51:18 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 12 Feb 2024 17:51:18 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v20]
In-Reply-To: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
Message-ID: <YyhjobbO2W9pAWCCWWARi4GYjQPmcKUvsFTynoJcPc0=.597cfb2e-d563-4674-8533-050c6ac3bd25@github.com>

> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am.
> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX.
> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails.

Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:

  revert

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16604/files
  - new: https://git.openjdk.org/jdk/pull/16604/files/b5cf57d6..ecf8ad6c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=18-19

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

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

From sroy at openjdk.org  Mon Feb 12 17:55:23 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 12 Feb 2024 17:55:23 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v21]
In-Reply-To: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
Message-ID: <Z4Mgk8cTUmInqFWqZF6bwVlFa-gt5SS2H2IOnpiEk-Y=.31ef5f7c-7f40-4ca5-a0c8-4a7d043c5213@github.com>

> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am.
> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX.
> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails.

Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:

  revert log_info

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16604/files
  - new: https://git.openjdk.org/jdk/pull/16604/files/ecf8ad6c..d887ad73

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=19-20

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

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

From coleenp at openjdk.org  Mon Feb 12 18:01:04 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 12 Feb 2024 18:01:04 GMT
Subject: RFR: 8320302: compiler/arguments/TestC1Globals.java hits SIGSEGV
 in ContinuationEntry::set_enter_code [v4]
In-Reply-To: <k9rz95AmHObnxGOmcjA6pt5fcOERxeXlgEUvxTr3LhI=.177371e9-3625-40af-9744-c7da29f1a592@github.com>
References: <1Cm1SGGaZsYxM-RfPNDeAvnGijQ-taVe438SS6bZ3YI=.d64abde2-f9a0-4589-ab40-eba7c3c02992@github.com>
 <k9rz95AmHObnxGOmcjA6pt5fcOERxeXlgEUvxTr3LhI=.177371e9-3625-40af-9744-c7da29f1a592@github.com>
Message-ID: <uaaJgbgNTAJOpbkf-mXpJnd0-ZP4fwybtYPy2SVCQjA=.6f7bf598-ef64-4c3a-9751-41479155b420@github.com>

On Thu, 8 Feb 2024 22:44:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> When creating Continuation.enterSpecial/doYield special native nmethods we currently assume the call to nmethod::new_native_nmethod() always succeeds. If the CodeCache happens to be full though, creating the nmethod will fail and we'll hit a SIGSEGV when trying to dereference the return value. 
>> 
>> Since this happens the first time those methods are resolved, throwing an exception at that point implying that we cannot run virtual threads looks odd from a user perspective. So instead I added a step to initialize the Continuation class at startup so that failure to create those nmethods is treated early as a fatal error as we do with any other critical resource needed by the VM. I measured the added step to the startup sequence to be ~90us, or about 0.3% of the total?startup time.
>> 
>> I verified the fix by running the test mentioned in the bug plus I also run tiers1-5 in mach5.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Throw OOM from link_method()

This looks good.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17455#pullrequestreview-1875854424

From sroy at openjdk.org  Mon Feb 12 18:04:21 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 12 Feb 2024 18:04:21 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v22]
In-Reply-To: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
Message-ID: <LHKPKfz60cA4rddKKT51OUG7jxispd9M7A0io897pG0=.d8b3c965-755b-4500-a3f1-72b578045060@github.com>

> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am.
> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX.
> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails.

Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:

  Remove not matched trailing whitespaces

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16604/files
  - new: https://git.openjdk.org/jdk/pull/16604/files/d887ad73..c6332f67

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=20-21

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

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

From kvn at openjdk.org  Mon Feb 12 18:05:06 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 12 Feb 2024 18:05:06 GMT
Subject: RFR: 8252136: Several methods in hotspot are missing "static"
In-Reply-To: <dleKPT17nKiOOWVZg8Jm9pMPiUFe6KfqSfR-gDQK63c=.fbc6290d-eec4-43e8-8970-9d773a115eb6@github.com>
References: <dleKPT17nKiOOWVZg8Jm9pMPiUFe6KfqSfR-gDQK63c=.fbc6290d-eec4-43e8-8970-9d773a115eb6@github.com>
Message-ID: <8A0cHKrgXY3iuAIKiZx-SeqshSWLSMNtuE6wf86oiLE=.dcbd9e4d-428f-4a98-a0c3-8d9da9338dec@github.com>

On Mon, 12 Feb 2024 12:43:09 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> There are several places in hotspot where an internal function should have been declared static, but isn't. 
> 
> These were discovered by trying to use the gcc option `-Wmissing-declarations` and the corresponding clang option `-Wmissing-prototypes`. These warnings check that a function either:
> a) is declared static, or
> b) has a declaration before its definition. 
> 
> The rationale of this is that functions are either internal to a compilation unit, or exported to be linked by some other compilation unit. In the former case, it should be marked static. In the latter case, it should be declared in a header file, which should be included by the implementation as well. If there is a discrepancy between the exported prototype and the implemented prototype, this will be discovered during compilation (instead of as a runtime error). Additionally, marking internal methods as static allows the compiler to make better optimization, like inlining.
> 
> This seem to be to be a sane assumption, and I think Hotspot (and the entire JDK) would increase code quality by turning on these warnings. The absolute majority of the code already adheres to these rules, but there are still some places that needs to be fixed.
> 
> This is the first part of addressing these issues, where all places that are trivially missing static are fixed.
> 
> I have discovered these by running with the warnings mentioned above turned on. I have filtered out those places were an export was obviously missing. The remaining warnings I have manually inspected. About 1/4 of them were *_init() functions (which are directly declared in `init.cpp`) and another 1/4 were documented as "use in debugger"; these I have not touched. I also ignored functions with names suggesting it might be used in the debugger, even if not documented as such, or any places that even seemed remotely non-trivial. Finally I also reverted a few changes after it turned out that gcc complained about unused functions. These places are actually dead code, but it is not clear if they should be removed or if there is actually a call missing somewhere (I believe it is a mix of both). In any case, I did not want any such complexities in this PR.
> 
> When the functions where marked static, gcc started complaining if they were not used, since it consider it dead code. To address this, I had to add or fix some `#ifdef`s. Since this code were not actually used unless these criteria were fulfilled before either (it was just not discovered by the compiler), I thi...

I reviewed compiler code (cpu/, compiler/, c1/, opto/). Looks good to me.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17806#pullrequestreview-1875862288

From sroy at openjdk.org  Mon Feb 12 18:12:08 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 12 Feb 2024 18:12:08 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v14]
In-Reply-To: <mYgHphufoa-3oRbdJw_65u4xktqnHA5OnrigSBC2NwI=.85ba4aa9-2143-4f68-8aa5-5100575ecafe@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <cNyV9jVxZtoIf9qgQbTQ86Syu95kql6wC5C1DzgiRPs=.8d2f1d5b-b64a-41b8-87f2-c8d31b0e98c0@github.com>
 <VDnWgKmkKKxKGDnT3_7xmpl6wVqrs6n0Z_mOVWsesCg=.cd4a8667-4086-450e-8fe1-df023ad0acb5@github.com>
 <JBjZF1htM8fykk9uKOcxDq3SUQq2oZ9d2kgitPGcpsY=.34d1e014-65a8-443d-9c62-04ba8fd8819b@github.com>
 <1kzsCJOR4U-lc77vCBrS_Oa4YCoBv5a7Zz8gKDHDuXg=.9471c3b3-cea7-415b-aa18-79aa76f508d1@github.com>
 <mYgHphufoa-3oRbdJw_65u4xktqnHA5OnrigSBC2NwI=.85ba4aa9-2143-4f68-8aa5-5100575ecafe@github.com>
Message-ID: <iGNWHLQHXQ4y1rPKyjnDBNx9IucpopueYBiCqxeiCJo=.652e1a7c-dc8c-4c9f-b5ca-7b02dbf8e3a9@github.com>

On Mon, 12 Feb 2024 17:21:55 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

> > > > The trailing whitespace errors must get fixed (integration blocker).
> > > 
> > > 
> > > I am unable to resolve this. The spaces seem fine as i see it in the terminal. Could it be some other error ?
> > 
> > 
> > Strange. I don't see any whitespace problem, either. Maybe it's possible to rerun jcheck (GitHub Actions). Otherwise, you may need to create a new PR.
> 
> Re running tests is not helping as i made more commits. Not sure why it arrived all of a sudden.

I have resolved this, I reverted back to old commit where assert was present. Then brought it back to current state. 
Saw that there was one line with some trailing whitespaces, using sed command with valid regex.
But the jcheck was pointing at the wrong line , which was confusing.

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

PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1939268192

From pchilanomate at openjdk.org  Mon Feb 12 18:58:58 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 12 Feb 2024 18:58:58 GMT
Subject: RFR: 8320302: compiler/arguments/TestC1Globals.java hits SIGSEGV
 in ContinuationEntry::set_enter_code [v4]
In-Reply-To: <k9rz95AmHObnxGOmcjA6pt5fcOERxeXlgEUvxTr3LhI=.177371e9-3625-40af-9744-c7da29f1a592@github.com>
References: <1Cm1SGGaZsYxM-RfPNDeAvnGijQ-taVe438SS6bZ3YI=.d64abde2-f9a0-4589-ab40-eba7c3c02992@github.com>
 <k9rz95AmHObnxGOmcjA6pt5fcOERxeXlgEUvxTr3LhI=.177371e9-3625-40af-9744-c7da29f1a592@github.com>
Message-ID: <wFAGoPBr2RSgfotfTT5pCN5ymspIfKkWWXFEi4WyvRo=.79c809f5-472e-498d-a63d-b9b149898e3a@github.com>

On Thu, 8 Feb 2024 22:44:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> When creating Continuation.enterSpecial/doYield special native nmethods we currently assume the call to nmethod::new_native_nmethod() always succeeds. If the CodeCache happens to be full though, creating the nmethod will fail and we'll hit a SIGSEGV when trying to dereference the return value. 
>> 
>> Since this happens the first time those methods are resolved, throwing an exception at that point implying that we cannot run virtual threads looks odd from a user perspective. So instead I added a step to initialize the Continuation class at startup so that failure to create those nmethods is treated early as a fatal error as we do with any other critical resource needed by the VM. I measured the added step to the startup sequence to be ~90us, or about 0.3% of the total?startup time.
>> 
>> I verified the fix by running the test mentioned in the bug plus I also run tiers1-5 in mach5.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Throw OOM from link_method()

Thanks for the reviews David and Coleen!

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

PR Comment: https://git.openjdk.org/jdk/pull/17455#issuecomment-1939344632

From pchilanomate at openjdk.org  Mon Feb 12 18:58:58 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 12 Feb 2024 18:58:58 GMT
Subject: Integrated: 8320302: compiler/arguments/TestC1Globals.java hits
 SIGSEGV in ContinuationEntry::set_enter_code
In-Reply-To: <1Cm1SGGaZsYxM-RfPNDeAvnGijQ-taVe438SS6bZ3YI=.d64abde2-f9a0-4589-ab40-eba7c3c02992@github.com>
References: <1Cm1SGGaZsYxM-RfPNDeAvnGijQ-taVe438SS6bZ3YI=.d64abde2-f9a0-4589-ab40-eba7c3c02992@github.com>
Message-ID: <e-P2XPFBywZa3tF1ztC-sgKZGR9slkW4ehKRqkGll2M=.f8152e6f-53e4-4dda-9e6d-1e2089d901cc@github.com>

On Tue, 16 Jan 2024 23:33:58 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> When creating Continuation.enterSpecial/doYield special native nmethods we currently assume the call to nmethod::new_native_nmethod() always succeeds. If the CodeCache happens to be full though, creating the nmethod will fail and we'll hit a SIGSEGV when trying to dereference the return value. 
> 
> Since this happens the first time those methods are resolved, throwing an exception at that point implying that we cannot run virtual threads looks odd from a user perspective. So instead I added a step to initialize the Continuation class at startup so that failure to create those nmethods is treated early as a fatal error as we do with any other critical resource needed by the VM. I measured the added step to the startup sequence to be ~90us, or about 0.3% of the total?startup time.
> 
> I verified the fix by running the test mentioned in the bug plus I also run tiers1-5 in mach5.
> 
> Thanks,
> Patricio

This pull request has now been integrated.

Changeset: 46287630
Author:    Patricio Chilano Mateo <pchilanomate at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/462876300103feaccc078ec8694b7d861a9ed4f3
Stats:     28 lines in 7 files changed: 20 ins; 8 del; 0 mod

8320302: compiler/arguments/TestC1Globals.java hits SIGSEGV in ContinuationEntry::set_enter_code

Reviewed-by: dholmes, coleenp

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

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

From kbarrett at openjdk.org  Mon Feb 12 20:09:58 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 12 Feb 2024 20:09:58 GMT
Subject: RFR: 8252136: Several methods in hotspot are missing "static"
In-Reply-To: <dleKPT17nKiOOWVZg8Jm9pMPiUFe6KfqSfR-gDQK63c=.fbc6290d-eec4-43e8-8970-9d773a115eb6@github.com>
References: <dleKPT17nKiOOWVZg8Jm9pMPiUFe6KfqSfR-gDQK63c=.fbc6290d-eec4-43e8-8970-9d773a115eb6@github.com>
Message-ID: <qGxksLALrvcF8I7sxaPx4gqQ4la_7qJR-Y2e9UPglLk=.32a850c2-911a-4fb2-8f46-02f829978ce9@github.com>

On Mon, 12 Feb 2024 12:43:09 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> There are several places in hotspot where an internal function should have been declared static, but isn't. 
> 
> These were discovered by trying to use the gcc option `-Wmissing-declarations` and the corresponding clang option `-Wmissing-prototypes`. These warnings check that a function either:
> a) is declared static, or
> b) has a declaration before its definition. 
> 
> The rationale of this is that functions are either internal to a compilation unit, or exported to be linked by some other compilation unit. In the former case, it should be marked static. In the latter case, it should be declared in a header file, which should be included by the implementation as well. If there is a discrepancy between the exported prototype and the implemented prototype, this will be discovered during compilation (instead of as a runtime error). Additionally, marking internal methods as static allows the compiler to make better optimization, like inlining.
> 
> This seem to be to be a sane assumption, and I think Hotspot (and the entire JDK) would increase code quality by turning on these warnings. The absolute majority of the code already adheres to these rules, but there are still some places that needs to be fixed.
> 
> This is the first part of addressing these issues, where all places that are trivially missing static are fixed.
> 
> I have discovered these by running with the warnings mentioned above turned on. I have filtered out those places were an export was obviously missing. The remaining warnings I have manually inspected. About 1/4 of them were *_init() functions (which are directly declared in `init.cpp`) and another 1/4 were documented as "use in debugger"; these I have not touched. I also ignored functions with names suggesting it might be used in the debugger, even if not documented as such, or any places that even seemed remotely non-trivial. Finally I also reverted a few changes after it turned out that gcc complained about unused functions. These places are actually dead code, but it is not clear if they should be removed or if there is actually a call missing somewhere (I believe it is a mix of both). In any case, I did not want any such complexities in this PR.
> 
> When the functions where marked static, gcc started complaining if they were not used, since it consider it dead code. To address this, I had to add or fix some `#ifdef`s. Since this code were not actually used unless these criteria were fulfilled before either (it was just not discovered by the compiler), I thi...

Mostly good, other than the parameter indentation issue mentioned by @stefank .
Just a couple of minor comments.

src/hotspot/share/c1/c1_LinearScan.cpp line 1449:

> 1447: }
> 1448: 
> 1449: #ifdef ASSERT

I think the change from PRODUCT to ASSERT might be incorrect, and might break "optimize" builds.

src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleWriter.cpp line 202:

> 200: static RootDescriptionInfo* root_infos = nullptr;
> 201: 
> 202: static int __write_sample_info__(JfrCheckpointWriter* writer, const void* si) {

pre-existing: all these names starting with underscores are technically reserved names - C++14 17.6.4.3.2.
Shouldn't be changed as part of this PR, but perhaps there should be a bug report?  Don't know if anyone
would ever get around to doing anything about it though.

src/hotspot/share/runtime/sharedRuntimeTrans.cpp line 443:

> 441:         ivln2_l  =  1.92596299112661746887e-08; /* 0x3E54AE0B, 0xF85DDF44 =1/ln2 tail*/
> 442: 
> 443: static double __ieee754_pow(double x, double y) {

pre-existing: another batch of technically reserved names in this file.

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

PR Review: https://git.openjdk.org/jdk/pull/17806#pullrequestreview-1876043818
PR Review Comment: https://git.openjdk.org/jdk/pull/17806#discussion_r1486684672
PR Review Comment: https://git.openjdk.org/jdk/pull/17806#discussion_r1486678063
PR Review Comment: https://git.openjdk.org/jdk/pull/17806#discussion_r1486694230

From dlong at openjdk.org  Mon Feb 12 21:17:22 2024
From: dlong at openjdk.org (Dean Long)
Date: Mon, 12 Feb 2024 21:17:22 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v10]
In-Reply-To: <S1rfjGVAu5fYdrqOyadzHXLRT99jKBW3urvQXYEuhZs=.e999799e-6cdf-4289-9f3c-9519e1c878a7@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <S1rfjGVAu5fYdrqOyadzHXLRT99jKBW3urvQXYEuhZs=.e999799e-6cdf-4289-9f3c-9519e1c878a7@github.com>
Message-ID: <oV_tKfRTBww79UI1tZ0j3xhUy--YW2TDGD1KRke3CwQ=.6595a7a0-8925-4d73-a073-08339d7efde9@github.com>

On Mon, 12 Feb 2024 11:04:23 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> ICStubs solve an atomicity problem when setting both the destination and data of an inline cache. Unfortunately, it also leads to occasional safepoint carpets when multiple threads need to ICRefill the stubs at the same time, and spurious GuaranteedSafepointInterval "Cleanup" safepoints every second. This patch changes inline caches to not change the data part at all during the nmethod life cycle, hence removing the need for ICStubs.
>> 
>> The new scheme is less stateful. Instead of adding and removing callsite metadata back and forth when transitioning inline cache states, it installs all state any shape of call will ever need at resolution time in a struct that I call CompiledICData. This reduces inline cache state changes to simply changing the destination of the call, and it doesn't really matter what state transitions to what other state.
>> 
>> With this patch, we get rid of ICStub and ICBuffer classes and the related ICRefill and almost all Cleanup safepoints in practice. It also makes the inline cache code much simpler.
>> 
>> I have tested the changes from tier1-7, and run through full aurora performance tests.
>
> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Some comments

Marked as reviewed by dlong (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17495#pullrequestreview-1876321235

From coleenp at openjdk.org  Tue Feb 13 03:12:08 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 13 Feb 2024 03:12:08 GMT
Subject: RFR: 8319801: Recursive lightweight locking: aarch64
 implementation [v15]
In-Reply-To: <baEgD9pIHSZRgGBHK4gXRVtHULSBO3w1bfPwwc-6tRw=.8a159e65-2cf7-492b-aac0-e87aa0262ba9@github.com>
References: <AE1nsnyRCUHR970jjg4feUm5f6E1GPJvea0ooC6dCgI=.73fff610-c0f6-422a-a45d-88187b37b9a2@github.com>
 <baEgD9pIHSZRgGBHK4gXRVtHULSBO3w1bfPwwc-6tRw=.8a159e65-2cf7-492b-aac0-e87aa0262ba9@github.com>
Message-ID: <UMoVnzj46oiOZ64IEfJI_NXuzZUr0xrVQQP2LA4ZTSc=.8f451520-9858-4be0-bade-689acbb490d9@github.com>

On Mon, 12 Feb 2024 09:10:30 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Implements the aarch64 port of JDK-8319796.
>> 
>> There are two major parts for the port implementation. The C2 part, and the part shared by the interpreter, C1 and the native call wrapper.
>> 
>> The biggest change for both parts is that we check the lock stack first and if it is a recursive lightweight [un]lock and in that case simply pop/push and finish successfully.
>> 
>> Only if the recursive lightweight [un]lock fails does it look at the mark word. 
>> 
>> For the shared part if it is an unstructured exit, the monitor is inflated or the mark word transition fails it calls into the runtime.
>> 
>> The C2 operates under a few more assumptions, that the locking is structured and balanced. This means that some checks can be elided. 
>> 
>> First this means that in C2 unlock if the obj is not on the top of the lock stack, it must be inflated. And reversely if we reach the inflated C2 unlock the obj is not on the lock stack. This second property makes it possible to avoid reading the owner (and checking if it is anonymous). Instead it can either just do an un-contended unlock by writing null to the owner, or if contention happens, simply write the thread to the owner and jump to the runtime. 
>> 
>> The aarch64 C2 port tries to avoid stronger memory semantics where ever possible. In C2 lock it first does a relaxed load of the mark word to check for inflation. Both lock and unlock uses a load/store exclusive register pair to transition the mark word.
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Update src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp"
>   
>   This reverts commit 130cf4b7f5b37ecb9dda3ce07ed70c3da13b29b8.

I'm still redoing some testing but the Derby performance regression we saw seems to have gone away.

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

PR Comment: https://git.openjdk.org/jdk/pull/16608#issuecomment-1940350913

From sspitsyn at openjdk.org  Tue Feb 13 07:11:18 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 13 Feb 2024 07:11:18 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v5]
In-Reply-To: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
Message-ID: <EwIwVHOIpJbV6fpHsNuoepv90GjfdanfYZpctKgtJ80=.82eab452-6f0d-470d-8a55-07aaab0dbec8@github.com>

> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
> The function returns the following structure:
> 
> 
> typedef struct {
>     jthread owner;
>     jint entry_count;
>     jint waiter_count;
>     jthread* waiters;
>     jint notify_waiter_count;
>     jthread* notify_waiters;
> } jvmtiMonitorUsage;
> 
> 
> The following four fields are defined this way:
> 
> waiter_count  [jint] The number of threads waiting to own this monitor
> waiters  [jthread*] The waiter_count waiting threads
> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
> 
> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
> This update makes it right.
> 
> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
> 
> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
> 
>   jvmti/GetObjectMonitorUsage/objmonusage001
>   jvmti/GetObjectMonitorUsage/objmonusage003
> 
> 
> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
> 
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
> 
> 
> 
> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository.
> 
> Also, please see and review the related CSR:
>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
> 
> The Release-Note is:
> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage
>  
> Testing:
>  - tested with mach5 tiers 1-6

Serguei Spitsyn 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:

 - Merge
 - review: fixed issues in get_object_monitor_usage; extended test coverage in objmonusage003
 - Merge
 - review: thread in notify waiter list can't be BLOCKED
 - 8324677: Specification clarification needed for JVM TI GetObjectMonitorUsage

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17680/files
  - new: https://git.openjdk.org/jdk/pull/17680/files/69ba5e7e..182cd07c

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

  Stats: 6592 lines in 396 files changed: 3981 ins; 1259 del; 1352 mod
  Patch: https://git.openjdk.org/jdk/pull/17680.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17680/head:pull/17680

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

From dholmes at openjdk.org  Tue Feb 13 07:11:19 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 13 Feb 2024 07:11:19 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v4]
In-Reply-To: <bKkHh3R39JCXKuQGrduWdZhJ9jstNA6xfUnJgPgbslE=.c1e27529-af8c-4707-9d24-473952502459@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <bKkHh3R39JCXKuQGrduWdZhJ9jstNA6xfUnJgPgbslE=.c1e27529-af8c-4707-9d24-473952502459@github.com>
Message-ID: <5DPYtNaOL_44RemEpOUvNCJYISxC2bfUHakk7FVIj9k=.bd8baf61-bcf1-4c92-b31a-ef048e9dc64c@github.com>

On Sat, 10 Feb 2024 04:06:37 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
>> The function returns the following structure:
>> 
>> 
>> typedef struct {
>>     jthread owner;
>>     jint entry_count;
>>     jint waiter_count;
>>     jthread* waiters;
>>     jint notify_waiter_count;
>>     jthread* notify_waiters;
>> } jvmtiMonitorUsage;
>> 
>> 
>> The following four fields are defined this way:
>> 
>> waiter_count  [jint] The number of threads waiting to own this monitor
>> waiters  [jthread*] The waiter_count waiting threads
>> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
>> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
>> 
>> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
>> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
>> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
>> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
>> This update makes it right.
>> 
>> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
>> 
>> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
>> 
>>   jvmti/GetObjectMonitorUsage/objmonusage001
>>   jvmti/GetObjectMonitorUsage/objmonusage003
>> 
>> 
>> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
>> 
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
>> 
>> 
>> 
>> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository.
>> 
>> Also, please see and review the related CSR:
>>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
>> 
>> The Release-Note is:
>> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage
>>  
>> Testing:
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: fixed issues in get_object_monitor_usage; extended test coverage in objmonusage003

Sorry really struggling to understand this now. We have gone from a simple miscalculation to apparently doing everything wrong.

IIUC this API does not currently handle virtual threads correctly -i s that the case? If so I would like to see that fix factored out and done separately before this fix is done. Thanks.

src/hotspot/share/runtime/javaThread.cpp line 196:

> 194: oop JavaThread::vthread_or_thread() const {
> 195:     oop result = vthread();
> 196:     if (result == nullptr) {

Is that really sufficient? If so why do we have `is_vthread_mounted` which checks the continuation?

test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage003.java line 31:

> 29: 
> 30:     final static int JCK_STATUS_BASE = 95;
> 31:     final static int NUMBER_OF_ENTERER_THREADS = 4;

Nit: ENTERING not ENTERER

test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage003.java line 33:

> 31:     final static int NUMBER_OF_ENTERER_THREADS = 4;
> 32:     final static int NUMBER_OF_WAITER_THREADS  = 4;
> 33:     final static int NUMBER_OF_THREADS = NUMBER_OF_ENTERER_THREADS + NUMBER_OF_WAITER_THREADS;

This testing is not sufficient. We have three states of interest:
- entering the monitor directly
- waiting in the monitor via Object.wait
- re-rentering the monitor after being notified (or timed-out or interrupted)
- we need to check all of these conditions in permutations covering zero and non-zero for each one, and then see that we get the correct counts back from JVM TI.

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

PR Review: https://git.openjdk.org/jdk/pull/17680#pullrequestreview-1876986745
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1487299437
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1487304912
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1487311675

From mdoerr at openjdk.org  Tue Feb 13 07:28:07 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 13 Feb 2024 07:28:07 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v22]
In-Reply-To: <LHKPKfz60cA4rddKKT51OUG7jxispd9M7A0io897pG0=.d8b3c965-755b-4500-a3f1-72b578045060@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <LHKPKfz60cA4rddKKT51OUG7jxispd9M7A0io897pG0=.d8b3c965-755b-4500-a3f1-72b578045060@github.com>
Message-ID: <Wiee9NJczUk_RDnydijM9AFWoZ3GHcc1N5V4pCW_DaY=.05a53d9d-a9ac-4515-b178-ec5440b1caff@github.com>

On Mon, 12 Feb 2024 18:04:21 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am.
>> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX.
>> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails.
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove not matched trailing whitespaces

Thanks for improving it! My points have been addressed. Up to other reviewers, now.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16604#pullrequestreview-1877020968

From sspitsyn at openjdk.org  Tue Feb 13 08:07:04 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 13 Feb 2024 08:07:04 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v4]
In-Reply-To: <5DPYtNaOL_44RemEpOUvNCJYISxC2bfUHakk7FVIj9k=.bd8baf61-bcf1-4c92-b31a-ef048e9dc64c@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <bKkHh3R39JCXKuQGrduWdZhJ9jstNA6xfUnJgPgbslE=.c1e27529-af8c-4707-9d24-473952502459@github.com>
 <5DPYtNaOL_44RemEpOUvNCJYISxC2bfUHakk7FVIj9k=.bd8baf61-bcf1-4c92-b31a-ef048e9dc64c@github.com>
Message-ID: <puVcTJmgQEHR1c5sTqrI2cOZaYJjugBWCIOxoY5SyYk=.2656766e-5ddc-4b7a-9b72-6de5e5b2a809@github.com>

On Tue, 13 Feb 2024 07:00:41 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: fixed issues in get_object_monitor_usage; extended test coverage in objmonusage003
>
> test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage003.java line 31:
> 
>> 29: 
>> 30:     final static int JCK_STATUS_BASE = 95;
>> 31:     final static int NUMBER_OF_ENTERER_THREADS = 4;
> 
> Nit: ENTERING not ENTERER

Okay, thanks. Will rename it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1487366808

From sspitsyn at openjdk.org  Tue Feb 13 08:15:03 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 13 Feb 2024 08:15:03 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v4]
In-Reply-To: <5DPYtNaOL_44RemEpOUvNCJYISxC2bfUHakk7FVIj9k=.bd8baf61-bcf1-4c92-b31a-ef048e9dc64c@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <bKkHh3R39JCXKuQGrduWdZhJ9jstNA6xfUnJgPgbslE=.c1e27529-af8c-4707-9d24-473952502459@github.com>
 <5DPYtNaOL_44RemEpOUvNCJYISxC2bfUHakk7FVIj9k=.bd8baf61-bcf1-4c92-b31a-ef048e9dc64c@github.com>
Message-ID: <86Dgumz3_blIZl8YfNNNsAKef0po-ZwbZT9wbN5egjE=.df7dc8aa-3528-4992-a857-a29eb26cc35d@github.com>

On Tue, 13 Feb 2024 06:55:46 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: fixed issues in get_object_monitor_usage; extended test coverage in objmonusage003
>
> src/hotspot/share/runtime/javaThread.cpp line 196:
> 
>> 194: oop JavaThread::vthread_or_thread() const {
>> 195:     oop result = vthread();
>> 196:     if (result == nullptr) {
> 
> Is that really sufficient? If so why do we have `is_vthread_mounted` which checks the continuation?

Thank you for the question.
This function does not care if this is a vthread, or not and if it is mounted or not.
We just need a right oop of currently executed thread or vthread.
The `threadOop()` and `vthread()` can return the same oop.
If `vthread()` is not `nullptr` then it can point either to a `j.l.Thread` or a `j.lVirtualThread`.
If it is `nullptr` then we have to take `threadOop()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1487374609

From sspitsyn at openjdk.org  Tue Feb 13 08:39:03 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 13 Feb 2024 08:39:03 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v4]
In-Reply-To: <5DPYtNaOL_44RemEpOUvNCJYISxC2bfUHakk7FVIj9k=.bd8baf61-bcf1-4c92-b31a-ef048e9dc64c@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <bKkHh3R39JCXKuQGrduWdZhJ9jstNA6xfUnJgPgbslE=.c1e27529-af8c-4707-9d24-473952502459@github.com>
 <5DPYtNaOL_44RemEpOUvNCJYISxC2bfUHakk7FVIj9k=.bd8baf61-bcf1-4c92-b31a-ef048e9dc64c@github.com>
Message-ID: <dgTO2rNUQS0JvaHUtfifHa74B68HXzG0pC6dvT6QkKU=.b1930c72-90f6-4cb5-a070-35278d137a66@github.com>

On Tue, 13 Feb 2024 07:06:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: fixed issues in get_object_monitor_usage; extended test coverage in objmonusage003
>
> test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage003.java line 33:
> 
>> 31:     final static int NUMBER_OF_ENTERER_THREADS = 4;
>> 32:     final static int NUMBER_OF_WAITER_THREADS  = 4;
>> 33:     final static int NUMBER_OF_THREADS = NUMBER_OF_ENTERER_THREADS + NUMBER_OF_WAITER_THREADS;
> 
> This testing is not sufficient. We have three states of interest:
> - entering the monitor directly
> - waiting in the monitor via Object.wait
> - re-rentering the monitor after being notified (or timed-out or interrupted)
> - we need to check all of these conditions in permutations covering zero and non-zero for each one, and then see that we get the correct counts back from JVM TI.

Thank you for the comment, David.
Now the test checks:
- the threads waiting to enter the monitor are returned correctly with all permutations of threads waiting to be notified and threads waiting to re-enter the monitor
Initially, there are 4 threads waiting to be notified and zero threads waiting to re-enter the monitor.
They are notified one by with the subsequent checks, so all the pairs are checked `<re-enter,wait-for-notif>`: `<0,4>, <1,3>, <2,2>, <3,1>, <4,0>`

I'm not sure why do you think all permutations covering zero and non-zero for each one are needed.
At least, it looks like an overkill to me. But if you still think it is really important then I can add cases with zero threads waiting to enter the monitor with the same permutations of threads waiting to be notified and threads re-entering the monitor.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1487402314

From sspitsyn at openjdk.org  Tue Feb 13 08:42:02 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 13 Feb 2024 08:42:02 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v4]
In-Reply-To: <5DPYtNaOL_44RemEpOUvNCJYISxC2bfUHakk7FVIj9k=.bd8baf61-bcf1-4c92-b31a-ef048e9dc64c@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <bKkHh3R39JCXKuQGrduWdZhJ9jstNA6xfUnJgPgbslE=.c1e27529-af8c-4707-9d24-473952502459@github.com>
 <5DPYtNaOL_44RemEpOUvNCJYISxC2bfUHakk7FVIj9k=.bd8baf61-bcf1-4c92-b31a-ef048e9dc64c@github.com>
Message-ID: <FyUzHquSAC2WSUI0da52uhn7JQtJEsZiOGNWB9cEiIk=.0653f836-b00d-4b48-964a-cd8b6e0cb7aa@github.com>

On Tue, 13 Feb 2024 07:08:33 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Sorry really struggling to understand this now. We have gone from a simple miscalculation to apparently doing everything wrong. IIUC this API does not currently handle virtual threads correctly - is that the case? If so I would like to see that fix factored out and done separately before this fix is done. Thanks.

Thank you for the concern, David. But it is not clear what it is. Could you, please, explain a little bit?
Why do you think the virtual threads are handled incorrectly?

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

PR Comment: https://git.openjdk.org/jdk/pull/17680#issuecomment-1940760918

From eosterlund at openjdk.org  Tue Feb 13 09:15:28 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 13 Feb 2024 09:15:28 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v11]
In-Reply-To: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
Message-ID: <lDKB0lc74xsB7UiO1FhR99BaBhNjfVSaNCDdJ2U2tmU=.39ee614a-6515-4461-8291-ff058ad949f9@github.com>

> ICStubs solve an atomicity problem when setting both the destination and data of an inline cache. Unfortunately, it also leads to occasional safepoint carpets when multiple threads need to ICRefill the stubs at the same time, and spurious GuaranteedSafepointInterval "Cleanup" safepoints every second. This patch changes inline caches to not change the data part at all during the nmethod life cycle, hence removing the need for ICStubs.
> 
> The new scheme is less stateful. Instead of adding and removing callsite metadata back and forth when transitioning inline cache states, it installs all state any shape of call will ever need at resolution time in a struct that I call CompiledICData. This reduces inline cache state changes to simply changing the destination of the call, and it doesn't really matter what state transitions to what other state.
> 
> With this patch, we get rid of ICStub and ICBuffer classes and the related ICRefill and almost all Cleanup safepoints in practice. It also makes the inline cache code much simpler.
> 
> I have tested the changes from tier1-7, and run through full aurora performance tests.

Erik ?sterlund 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 'master' into 8310823_object_streaming
 - Some comments
 - Feedback from Dean and Thomas
 - Update src/hotspot/share/code/compiledIC.hpp
   
   Co-authored-by: Thomas Schatzl <59967451+tschatzl at users.noreply.github.com>
 - Update src/hotspot/share/runtime/sharedRuntime.cpp
   
   Co-authored-by: Thomas Schatzl <59967451+tschatzl at users.noreply.github.com>
 - ARM32 fixes
 - Add comment
 - Deal with short far branches on AArch64
 - Batch allocate and free CompiledICData
 - JVMCI support
 - ... and 9 more: https://git.openjdk.org/jdk/compare/62a4be03...29994286

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

Changes: https://git.openjdk.org/jdk/pull/17495/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17495&range=10
  Stats: 4253 lines in 142 files changed: 501 ins; 3226 del; 526 mod
  Patch: https://git.openjdk.org/jdk/pull/17495.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17495/head:pull/17495

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

From eosterlund at openjdk.org  Tue Feb 13 09:19:17 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 13 Feb 2024 09:19:17 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v9]
In-Reply-To: <2zDHeeRc4pWQetiIzFMR0JwjZ5ExX7_OV8Yx9G4o_mg=.066b11a8-6a49-455e-a985-3fb5de974480@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <V98qMF5Nt3FtxSWERvrDp0aoXh6D5n9O70hDYZ8x9AA=.de3befaf-db68-43af-9230-cc54f0455f4b@github.com>
 <2zDHeeRc4pWQetiIzFMR0JwjZ5ExX7_OV8Yx9G4o_mg=.066b11a8-6a49-455e-a985-3fb5de974480@github.com>
Message-ID: <il8BfvagjWdOl5xRniNIIWkwbz-AKygWT50_DvC5fPQ=.941eac1c-4c2a-44e8-8fd1-2f27c202c5b5@github.com>

On Sat, 10 Feb 2024 00:35:47 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Feedback from Dean and Thomas
>
> If I just look at the new code, everything looks very reasonable.  I tried to compare the new code to the old code, but quickly gave up.
> 
> Could you explain why opt_virtual can now be a direct call and CompiledIC is now only for virtual?  It seems like we could have done that even with the old code.
> 
> Also, why don't we have to check for method->is_old() anymore?

Thanks for the review, @dean-long! I pushed a trivial merge conflict with the next round of NULL -> nullptr changes. Running final round of tests now

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

PR Comment: https://git.openjdk.org/jdk/pull/17495#issuecomment-1940860792

From aboldtch at openjdk.org  Tue Feb 13 09:36:32 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 13 Feb 2024 09:36:32 GMT
Subject: RFR: 8319797: Recursive lightweight locking: Runtime
 implementation [v19]
In-Reply-To: <ZWyjRIBdi5FeGTDfaIEmT_lBfg1n9MDl3vxA5g-FKbc=.cb26afcc-555b-4a80-b4f2-319c5422646b@github.com>
References: <ZWyjRIBdi5FeGTDfaIEmT_lBfg1n9MDl3vxA5g-FKbc=.cb26afcc-555b-4a80-b4f2-319c5422646b@github.com>
Message-ID: <8YeHZzmCYw-SvOBX8VlP6uKmDFL7mLPU45ruzYKrm6w=.5107c920-4cf9-496f-a98d-a66a57c5ea2f@github.com>

> Implements the runtime part of JDK-8319796.
> The different CPU implementations are/will be created as dependent pull requests.
> 
> This enhancement proposes introducing the ability for LM_LIGHTWEIGHT to handle consecutive recursive monitor enter. Limiting the implementation to only consecutive monitor enters allows for more efficient emitted code which only needs to look at the two top most entires on the lock stack to determine what to do in a monitor exit.
> 
> A high level overview:
>   * Locking is still performed on the mark word
>     * Unlocked (0b01) <=> Locked (0b00)
>   * Monitor enter on Obj with mark word Unlocked (0b01) is the same
>     * Transition Obj's mark word Unlocked (0b01) => Locked (0b00)
>     * Push Obj onto the lock stack
>     * Success
>   * Monitor enter on Obj with mark word Locked (0b00) will check the top entry on the lock stack
>     * If top entry is Obj
>       * Push Obj on the lock stack
>       * Success
>     * If top entry is not Obj
>       * Inflate and call ObjectMonitor::enter
>   * Monitor exit on Obj with mark word Locked (0b00) will check the two top entries on the lock stack
>     * If just the top entry is Obj
>       * Transition Obj's mark word Locked (0b00) => Unlocked (0b01)
>       * Pop the entry
>       * Success
>     * If both entries are Obj
>       * Pop the top entry
>       * Success
>     * Any other case only occurs for unstructured locking, then just inflate and call ObjectMonitor::exit
>   * If the monitor has been inflated for object Obj which is owned by the current thread
>     * All corresponding entries for Obj is removed from the lock stack
>     * The monitor recursions is set to the number of removed entries - 1
>     * The owner is changed from anonymous to the thread
>     * The regular ObjectMonitor::action is called.

Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16606/files
  - new: https://git.openjdk.org/jdk/pull/16606/files/6f76413d..0e90ca3b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16606&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16606&range=17-18

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

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

From aboldtch at openjdk.org  Tue Feb 13 09:36:33 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 13 Feb 2024 09:36:33 GMT
Subject: RFR: 8319797: Recursive lightweight locking: Runtime
 implementation [v18]
In-Reply-To: <JSwpvtOSOCMkejITJFXnsJGjTMO8NOz7nZk6ck-2I-U=.a582232b-4fd4-474c-9951-17111f7942ed@github.com>
References: <ZWyjRIBdi5FeGTDfaIEmT_lBfg1n9MDl3vxA5g-FKbc=.cb26afcc-555b-4a80-b4f2-319c5422646b@github.com>
 <JSwpvtOSOCMkejITJFXnsJGjTMO8NOz7nZk6ck-2I-U=.a582232b-4fd4-474c-9951-17111f7942ed@github.com>
Message-ID: <tWEilzGVjLi3Y8QqZu8iNebd1l7iWXlsD7kJHPv_9mE=.3efbf073-5139-4e1e-97b2-2a465bbc68b1@github.com>

On Thu, 8 Feb 2024 10:37:13 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Implements the runtime part of JDK-8319796.
>> The different CPU implementations are/will be created as dependent pull requests.
>> 
>> This enhancement proposes introducing the ability for LM_LIGHTWEIGHT to handle consecutive recursive monitor enter. Limiting the implementation to only consecutive monitor enters allows for more efficient emitted code which only needs to look at the two top most entires on the lock stack to determine what to do in a monitor exit.
>> 
>> A high level overview:
>>   * Locking is still performed on the mark word
>>     * Unlocked (0b01) <=> Locked (0b00)
>>   * Monitor enter on Obj with mark word Unlocked (0b01) is the same
>>     * Transition Obj's mark word Unlocked (0b01) => Locked (0b00)
>>     * Push Obj onto the lock stack
>>     * Success
>>   * Monitor enter on Obj with mark word Locked (0b00) will check the top entry on the lock stack
>>     * If top entry is Obj
>>       * Push Obj on the lock stack
>>       * Success
>>     * If top entry is not Obj
>>       * Inflate and call ObjectMonitor::enter
>>   * Monitor exit on Obj with mark word Locked (0b00) will check the two top entries on the lock stack
>>     * If just the top entry is Obj
>>       * Transition Obj's mark word Locked (0b00) => Unlocked (0b01)
>>       * Pop the entry
>>       * Success
>>     * If both entries are Obj
>>       * Pop the top entry
>>       * Success
>>     * Any other case only occurs for unstructured locking, then just inflate and call ObjectMonitor::exit
>>   * If the monitor has been inflated for object Obj which is owned by the current thread
>>     * All corresponding entries for Obj is removed from the lock stack
>>     * The monitor recursions is set to the number of removed entries - 1
>>     * The owner is changed from anonymous to the thread
>>     * The regular ObjectMonitor::action is called.
>
> 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 54 commits:
> 
>  - Running out of LogTagSets, stick with monitorinflation
>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8319797
>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8319797
>  - Fix assert comment
>  - Update copyright
>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8319797
>  - Add verify calls
>  - Assert valid lock stack offset
>  - Typos, wording and whitespace
>  - Fix miss in is_recursive improvement
>  - ... and 44 more: https://git.openjdk.org/jdk/compare/1fb9e3d6...6f76413d

Thanks for all the reviews. tier1-7 has been run with both LM_LEGACY and LM_LIGHTWEIGHT both linux x86_64 and aarch64. And tier1-3 windows and macosx.

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

PR Comment: https://git.openjdk.org/jdk/pull/16606#issuecomment-1940911094

From aboldtch at openjdk.org  Tue Feb 13 09:36:34 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 13 Feb 2024 09:36:34 GMT
Subject: Integrated: 8319797: Recursive lightweight locking: Runtime
 implementation
In-Reply-To: <ZWyjRIBdi5FeGTDfaIEmT_lBfg1n9MDl3vxA5g-FKbc=.cb26afcc-555b-4a80-b4f2-319c5422646b@github.com>
References: <ZWyjRIBdi5FeGTDfaIEmT_lBfg1n9MDl3vxA5g-FKbc=.cb26afcc-555b-4a80-b4f2-319c5422646b@github.com>
Message-ID: <RBUgI3sbfAhNDhdeZMplcSqCfZ4Dc7iWjXJPRb4pP-M=.0235bdf5-d690-4617-a35d-c293046389bb@github.com>

On Fri, 10 Nov 2023 12:40:03 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Implements the runtime part of JDK-8319796.
> The different CPU implementations are/will be created as dependent pull requests.
> 
> This enhancement proposes introducing the ability for LM_LIGHTWEIGHT to handle consecutive recursive monitor enter. Limiting the implementation to only consecutive monitor enters allows for more efficient emitted code which only needs to look at the two top most entires on the lock stack to determine what to do in a monitor exit.
> 
> A high level overview:
>   * Locking is still performed on the mark word
>     * Unlocked (0b01) <=> Locked (0b00)
>   * Monitor enter on Obj with mark word Unlocked (0b01) is the same
>     * Transition Obj's mark word Unlocked (0b01) => Locked (0b00)
>     * Push Obj onto the lock stack
>     * Success
>   * Monitor enter on Obj with mark word Locked (0b00) will check the top entry on the lock stack
>     * If top entry is Obj
>       * Push Obj on the lock stack
>       * Success
>     * If top entry is not Obj
>       * Inflate and call ObjectMonitor::enter
>   * Monitor exit on Obj with mark word Locked (0b00) will check the two top entries on the lock stack
>     * If just the top entry is Obj
>       * Transition Obj's mark word Locked (0b00) => Unlocked (0b01)
>       * Pop the entry
>       * Success
>     * If both entries are Obj
>       * Pop the top entry
>       * Success
>     * Any other case only occurs for unstructured locking, then just inflate and call ObjectMonitor::exit
>   * If the monitor has been inflated for object Obj which is owned by the current thread
>     * All corresponding entries for Obj is removed from the lock stack
>     * The monitor recursions is set to the number of removed entries - 1
>     * The owner is changed from anonymous to the thread
>     * The regular ObjectMonitor::action is called.

This pull request has now been integrated.

Changeset: 5dbf1373
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5dbf13730ee2b57f089c57e9e7ee8ab65d4a67af
Stats:     863 lines in 13 files changed: 815 ins; 7 del; 41 mod

8319797: Recursive lightweight locking: Runtime implementation

Co-authored-by: Stefan Karlsson <stefank at openjdk.org>
Co-authored-by: Erik ?sterlund <eosterlund at openjdk.org>
Reviewed-by: rkennke, dcubed, coleenp, stefank

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

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

From aboldtch at openjdk.org  Tue Feb 13 10:17:30 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 13 Feb 2024 10:17:30 GMT
Subject: RFR: 8319799: Recursive lightweight locking: x86 implementation
 [v18]
In-Reply-To: <ymgsUW7sq02C2r82WrLYof5Eb7BB5Lh8M-kGoHx_Zjg=.a5a76651-4931-489f-8ea1-158716614119@github.com>
References: <ymgsUW7sq02C2r82WrLYof5Eb7BB5Lh8M-kGoHx_Zjg=.a5a76651-4931-489f-8ea1-158716614119@github.com>
Message-ID: <wK8Gb4I2WpMMSIw7cwy_hzttQm68PP3Oq1YJTxz2U6Q=.30cbde81-7f8e-4b03-af9c-bb273a9404d1@github.com>

> Implements the x86 port of JDK-8319796.
> 
> There are two major parts for the port implementation. The C2 part, and the part shared by the interpreter, C1 and the native call wrapper.
> 
> The biggest change for both parts is that we check the lock stack first and if it is a recursive lightweight [un]lock and in that case simply pop/push and finish successfully.
> 
> Only if the recursive lightweight [un]lock fails does it look at the mark word. 
> 
> For the shared part if it is an unstructured exit, the monitor is inflated or the mark word transition fails it calls into the runtime.
> 
> The C2 operates under a few more assumptions, that the locking is structured and balanced. This means that some checks can be elided. 
> 
> First this means that in C2 unlock if the obj is not on the top of the lock stack, it must be inflated. And reversely if we reach the inflated C2 unlock the obj is not on the lock stack. This second property makes it possible to avoid reading the owner (and checking if it is anonymous). Instead it can either just do an un-contended unlock by writing null to the owner, or if contention happens, simply write the thread to the owner and jump to the runtime. 
> 
> The x86 C2 port also has some extra oddities. 
> 
> The mark word read is done early as it showed better scaling in hyper-threaded scenarios on certain intel hardware, and no noticeable downside on other tested x86 hardware. 
> 
> The fast path is written to avoid going through conditional branches. This in combination with keeping the ZF output correct, the code does some actions eagerly, decrementing the held monitor count, popping from the lock stack. And jumps to a code stub if a slow path is required which restores the thread local state to a correct state before jumping to the runtime.
> 
> The contended unlock was also moved to the code stub.

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 82 commits:

 - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8319799
 - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319799
 - Running out of LogTagSets, stick with monitorinflation
 - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8319797
 - Comment indent
 - Update copyright years
 - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319799
 - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8319797
 - Fix assert comment
 - Update MacroAssembler::lightweight_unlock comments.
 - ... and 72 more: https://git.openjdk.org/jdk/compare/c266800a...4d97e88c

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

Changes: https://git.openjdk.org/jdk/pull/16607/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16607&range=17
  Stats: 696 lines in 14 files changed: 557 ins; 61 del; 78 mod
  Patch: https://git.openjdk.org/jdk/pull/16607.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16607/head:pull/16607

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

From ihse at openjdk.org  Tue Feb 13 10:34:19 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 13 Feb 2024 10:34:19 GMT
Subject: RFR: 8252136: Several methods in hotspot are missing "static"
In-Reply-To: <qGxksLALrvcF8I7sxaPx4gqQ4la_7qJR-Y2e9UPglLk=.32a850c2-911a-4fb2-8f46-02f829978ce9@github.com>
References: <dleKPT17nKiOOWVZg8Jm9pMPiUFe6KfqSfR-gDQK63c=.fbc6290d-eec4-43e8-8970-9d773a115eb6@github.com>
 <qGxksLALrvcF8I7sxaPx4gqQ4la_7qJR-Y2e9UPglLk=.32a850c2-911a-4fb2-8f46-02f829978ce9@github.com>
Message-ID: <hyyoLaKm_KVZD7uPk7b5kTJSea_90tJjh-OaDH4_8X8=.8b14d2e0-3448-4878-b0f4-acd2691fba05@github.com>

On Mon, 12 Feb 2024 19:44:46 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> There are several places in hotspot where an internal function should have been declared static, but isn't. 
>> 
>> These were discovered by trying to use the gcc option `-Wmissing-declarations` and the corresponding clang option `-Wmissing-prototypes`. These warnings check that a function either:
>> a) is declared static, or
>> b) has a declaration before its definition. 
>> 
>> The rationale of this is that functions are either internal to a compilation unit, or exported to be linked by some other compilation unit. In the former case, it should be marked static. In the latter case, it should be declared in a header file, which should be included by the implementation as well. If there is a discrepancy between the exported prototype and the implemented prototype, this will be discovered during compilation (instead of as a runtime error). Additionally, marking internal methods as static allows the compiler to make better optimization, like inlining.
>> 
>> This seem to be to be a sane assumption, and I think Hotspot (and the entire JDK) would increase code quality by turning on these warnings. The absolute majority of the code already adheres to these rules, but there are still some places that needs to be fixed.
>> 
>> This is the first part of addressing these issues, where all places that are trivially missing static are fixed.
>> 
>> I have discovered these by running with the warnings mentioned above turned on. I have filtered out those places were an export was obviously missing. The remaining warnings I have manually inspected. About 1/4 of them were *_init() functions (which are directly declared in `init.cpp`) and another 1/4 were documented as "use in debugger"; these I have not touched. I also ignored functions with names suggesting it might be used in the debugger, even if not documented as such, or any places that even seemed remotely non-trivial. Finally I also reverted a few changes after it turned out that gcc complained about unused functions. These places are actually dead code, but it is not clear if they should be removed or if there is actually a call missing somewhere (I believe it is a mix of both). In any case, I did not want any such complexities in this PR.
>> 
>> When the functions where marked static, gcc started complaining if they were not used, since it consider it dead code. To address this, I had to add or fix some `#ifdef`s. Since this code were not actually used unless these criteria were fulfilled before either (it was just not disc...
>
> src/hotspot/share/c1/c1_LinearScan.cpp line 1449:
> 
>> 1447: }
>> 1448: 
>> 1449: #ifdef ASSERT
> 
> I think the change from PRODUCT to ASSERT might be incorrect, and might break "optimize" builds.

Actually, it is the other way around. Without this change, optimized builds broke. This function is only called from within an assert(), and these are defined as no-ops  in optimized builds. Thus, this function was never called and gcc complained about dead code.

> src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleWriter.cpp line 202:
> 
>> 200: static RootDescriptionInfo* root_infos = nullptr;
>> 201: 
>> 202: static int __write_sample_info__(JfrCheckpointWriter* writer, const void* si) {
> 
> pre-existing: all these names starting with underscores are technically reserved names - C++14 17.6.4.3.2.
> Shouldn't be changed as part of this PR, but perhaps there should be a bug report?  Don't know if anyone
> would ever get around to doing anything about it though.

Please feel free to open a bug report. ? 

Unless there is a warning flag to avoid creating reserved names (is there?), it is more of a matter of coding style on the part of Hotspot, and that is basically where I draw the line of my meddling with Hotspot. :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17806#discussion_r1487573865
PR Review Comment: https://git.openjdk.org/jdk/pull/17806#discussion_r1487571483

From aboldtch at openjdk.org  Tue Feb 13 10:36:20 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 13 Feb 2024 10:36:20 GMT
Subject: RFR: 8319801: Recursive lightweight locking: aarch64
 implementation [v16]
In-Reply-To: <AE1nsnyRCUHR970jjg4feUm5f6E1GPJvea0ooC6dCgI=.73fff610-c0f6-422a-a45d-88187b37b9a2@github.com>
References: <AE1nsnyRCUHR970jjg4feUm5f6E1GPJvea0ooC6dCgI=.73fff610-c0f6-422a-a45d-88187b37b9a2@github.com>
Message-ID: <CSIkQw9NjfsFbuQ_P-gbX3iaKNQU5-YvGe6HWjRBkME=.ea80bc31-87b8-4299-a2dd-67497115c315@github.com>

> Implements the aarch64 port of JDK-8319796.
> 
> There are two major parts for the port implementation. The C2 part, and the part shared by the interpreter, C1 and the native call wrapper.
> 
> The biggest change for both parts is that we check the lock stack first and if it is a recursive lightweight [un]lock and in that case simply pop/push and finish successfully.
> 
> Only if the recursive lightweight [un]lock fails does it look at the mark word. 
> 
> For the shared part if it is an unstructured exit, the monitor is inflated or the mark word transition fails it calls into the runtime.
> 
> The C2 operates under a few more assumptions, that the locking is structured and balanced. This means that some checks can be elided. 
> 
> First this means that in C2 unlock if the obj is not on the top of the lock stack, it must be inflated. And reversely if we reach the inflated C2 unlock the obj is not on the lock stack. This second property makes it possible to avoid reading the owner (and checking if it is anonymous). Instead it can either just do an un-contended unlock by writing null to the owner, or if contention happens, simply write the thread to the owner and jump to the runtime. 
> 
> The aarch64 C2 port tries to avoid stronger memory semantics where ever possible. In C2 lock it first does a relaxed load of the mark word to check for inflation. Both lock and unlock uses a load/store exclusive register pair to transition the mark word.

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 79 commits:

 - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8319801
 - Revert "Update src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp"
   
   This reverts commit 130cf4b7f5b37ecb9dda3ce07ed70c3da13b29b8.
 - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319801
 - Running out of LogTagSets, stick with monitorinflation
 - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8319797
 - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319801
 - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8319797
 - Fix assert comment
 - Update src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp
   
   Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>
 - Clarify the rscratch1 assert
 - ... and 69 more: https://git.openjdk.org/jdk/compare/c266800a...20e92608

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

Changes: https://git.openjdk.org/jdk/pull/16608/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16608&range=15
  Stats: 492 lines in 9 files changed: 354 ins; 82 del; 56 mod
  Patch: https://git.openjdk.org/jdk/pull/16608.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16608/head:pull/16608

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

From ihse at openjdk.org  Tue Feb 13 11:05:30 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 13 Feb 2024 11:05:30 GMT
Subject: RFR: 8252136: Several methods in hotspot are missing "static" [v2]
In-Reply-To: <dleKPT17nKiOOWVZg8Jm9pMPiUFe6KfqSfR-gDQK63c=.fbc6290d-eec4-43e8-8970-9d773a115eb6@github.com>
References: <dleKPT17nKiOOWVZg8Jm9pMPiUFe6KfqSfR-gDQK63c=.fbc6290d-eec4-43e8-8970-9d773a115eb6@github.com>
Message-ID: <DNbZYvbu-rsTnx4RpupnNa_2AJqiAmFjUPZlQndIdus=.1d180787-500b-4b49-b3ef-809babf19330@github.com>

> There are several places in hotspot where an internal function should have been declared static, but isn't. 
> 
> These were discovered by trying to use the gcc option `-Wmissing-declarations` and the corresponding clang option `-Wmissing-prototypes`. These warnings check that a function either:
> a) is declared static, or
> b) has a declaration before its definition. 
> 
> The rationale of this is that functions are either internal to a compilation unit, or exported to be linked by some other compilation unit. In the former case, it should be marked static. In the latter case, it should be declared in a header file, which should be included by the implementation as well. If there is a discrepancy between the exported prototype and the implemented prototype, this will be discovered during compilation (instead of as a runtime error). Additionally, marking internal methods as static allows the compiler to make better optimization, like inlining.
> 
> This seem to be to be a sane assumption, and I think Hotspot (and the entire JDK) would increase code quality by turning on these warnings. The absolute majority of the code already adheres to these rules, but there are still some places that needs to be fixed.
> 
> This is the first part of addressing these issues, where all places that are trivially missing static are fixed.
> 
> I have discovered these by running with the warnings mentioned above turned on. I have filtered out those places were an export was obviously missing. The remaining warnings I have manually inspected. About 1/4 of them were *_init() functions (which are directly declared in `init.cpp`) and another 1/4 were documented as "use in debugger"; these I have not touched. I also ignored functions with names suggesting it might be used in the debugger, even if not documented as such, or any places that even seemed remotely non-trivial. Finally I also reverted a few changes after it turned out that gcc complained about unused functions. These places are actually dead code, but it is not clear if they should be removed or if there is actually a call missing somewhere (I believe it is a mix of both). In any case, I did not want any such complexities in this PR.
> 
> When the functions where marked static, gcc started complaining if they were not used, since it consider it dead code. To address this, I had to add or fix some `#ifdef`s. Since this code were not actually used unless these criteria were fulfilled before either (it was just not discovered by the compiler), I thi...

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Revert spurious changes in non-modified file
 - Fix indentation issues

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17806/files
  - new: https://git.openjdk.org/jdk/pull/17806/files/97595a3e..9702d84a

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

  Stats: 32 lines in 13 files changed: 3 ins; 0 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/17806.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17806/head:pull/17806

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

From ihse at openjdk.org  Tue Feb 13 11:05:30 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 13 Feb 2024 11:05:30 GMT
Subject: RFR: 8252136: Several methods in hotspot are missing "static" [v2]
In-Reply-To: <Q3erX6U9Da2519qpJINXRwbnQhOIIguE3A7DbApjUvE=.b85f3d69-5903-4f9b-8564-508dfca152b6@github.com>
References: <dleKPT17nKiOOWVZg8Jm9pMPiUFe6KfqSfR-gDQK63c=.fbc6290d-eec4-43e8-8970-9d773a115eb6@github.com>
 <Q3erX6U9Da2519qpJINXRwbnQhOIIguE3A7DbApjUvE=.b85f3d69-5903-4f9b-8564-508dfca152b6@github.com>
Message-ID: <lB1EQjA7MKdawT2M2Wc3ccwUt9eBRY4rPDw4FAr0Qes=.3589c61a-3b4a-4c51-ac3f-0cfa215d3b5a@github.com>

On Mon, 12 Feb 2024 16:47:59 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The argument alignment is wonky after this patch. Could you go over the patch and fix that?

I did not think of that, sorry. Fixed now. (It turned out that not all places were properly aligned even before my patch...)

There are some places with extremely long lines, but that seem to be the style in these files, so I did not introduce line breaks there.

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

PR Comment: https://git.openjdk.org/jdk/pull/17806#issuecomment-1941218340

From jkern at openjdk.org  Tue Feb 13 12:12:10 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Tue, 13 Feb 2024 12:12:10 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v22]
In-Reply-To: <LHKPKfz60cA4rddKKT51OUG7jxispd9M7A0io897pG0=.d8b3c965-755b-4500-a3f1-72b578045060@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <LHKPKfz60cA4rddKKT51OUG7jxispd9M7A0io897pG0=.d8b3c965-755b-4500-a3f1-72b578045060@github.com>
Message-ID: <kCPl9NuYZfBf4R-kWIiRwGtHV4BMG5Q2lGAAkaKv9B8=.23327df9-070a-41a6-a6ae-2f300e1196f9@github.com>

On Mon, 12 Feb 2024 18:04:21 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am.
>> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX.
>> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails.
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove not matched trailing whitespaces

Everything is OK for me now.

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

Marked as reviewed by jkern (Author).

PR Review: https://git.openjdk.org/jdk/pull/16604#pullrequestreview-1877784574

From aph at openjdk.org  Tue Feb 13 12:25:09 2024
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 13 Feb 2024 12:25:09 GMT
Subject: RFR: 8319801: Recursive lightweight locking: aarch64
 implementation [v16]
In-Reply-To: <CSIkQw9NjfsFbuQ_P-gbX3iaKNQU5-YvGe6HWjRBkME=.ea80bc31-87b8-4299-a2dd-67497115c315@github.com>
References: <AE1nsnyRCUHR970jjg4feUm5f6E1GPJvea0ooC6dCgI=.73fff610-c0f6-422a-a45d-88187b37b9a2@github.com>
 <CSIkQw9NjfsFbuQ_P-gbX3iaKNQU5-YvGe6HWjRBkME=.ea80bc31-87b8-4299-a2dd-67497115c315@github.com>
Message-ID: <Zf7ftbzhitkIkE34s5wBH-FbBXnVwl_31FfpByUD9y0=.2099b428-3f90-4029-89f4-00ac83622541@github.com>

On Tue, 13 Feb 2024 10:36:20 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Implements the aarch64 port of JDK-8319796.
>> 
>> There are two major parts for the port implementation. The C2 part, and the part shared by the interpreter, C1 and the native call wrapper.
>> 
>> The biggest change for both parts is that we check the lock stack first and if it is a recursive lightweight [un]lock and in that case simply pop/push and finish successfully.
>> 
>> Only if the recursive lightweight [un]lock fails does it look at the mark word. 
>> 
>> For the shared part if it is an unstructured exit, the monitor is inflated or the mark word transition fails it calls into the runtime.
>> 
>> The C2 operates under a few more assumptions, that the locking is structured and balanced. This means that some checks can be elided. 
>> 
>> First this means that in C2 unlock if the obj is not on the top of the lock stack, it must be inflated. And reversely if we reach the inflated C2 unlock the obj is not on the lock stack. This second property makes it possible to avoid reading the owner (and checking if it is anonymous). Instead it can either just do an un-contended unlock by writing null to the owner, or if contention happens, simply write the thread to the owner and jump to the runtime. 
>> 
>> The aarch64 C2 port tries to avoid stronger memory semantics where ever possible. In C2 lock it first does a relaxed load of the mark word to check for inflation. Both lock and unlock uses a load/store exclusive register pair to transition the mark word.
>
> 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 79 commits:
> 
>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8319801
>  - Revert "Update src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp"
>    
>    This reverts commit 130cf4b7f5b37ecb9dda3ce07ed70c3da13b29b8.
>  - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319801
>  - Running out of LogTagSets, stick with monitorinflation
>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8319797
>  - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319801
>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8319797
>  - Fix assert comment
>  - Update src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp
>    
>    Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>
>  - Clarify the rscratch1 assert
>  - ... and 69 more: https://git.openjdk.org/jdk/compare/c266800a...20e92608

src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 243:

> 241:     ldrw(t1, Address(t1, Klass::access_flags_offset()));
> 242:     tstw(t1, JVM_ACC_IS_VALUE_BASED_CLASS);
> 243:     br(Assembler::NE, slow_path);

Suggestion:

    tbnz(t1, exact_log2(JVM_ACC_IS_VALUE_BASED_CLASS));

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16608#discussion_r1487755443

From aph at openjdk.org  Tue Feb 13 12:33:15 2024
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 13 Feb 2024 12:33:15 GMT
Subject: RFR: 8319801: Recursive lightweight locking: aarch64
 implementation [v16]
In-Reply-To: <CSIkQw9NjfsFbuQ_P-gbX3iaKNQU5-YvGe6HWjRBkME=.ea80bc31-87b8-4299-a2dd-67497115c315@github.com>
References: <AE1nsnyRCUHR970jjg4feUm5f6E1GPJvea0ooC6dCgI=.73fff610-c0f6-422a-a45d-88187b37b9a2@github.com>
 <CSIkQw9NjfsFbuQ_P-gbX3iaKNQU5-YvGe6HWjRBkME=.ea80bc31-87b8-4299-a2dd-67497115c315@github.com>
Message-ID: <1Y-qNlja13eOzuj89K-9qAI5xthZpOKOQDp07fvGELk=.bf2286c6-a8df-4e62-9235-f9514416206d@github.com>

On Tue, 13 Feb 2024 10:36:20 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Implements the aarch64 port of JDK-8319796.
>> 
>> There are two major parts for the port implementation. The C2 part, and the part shared by the interpreter, C1 and the native call wrapper.
>> 
>> The biggest change for both parts is that we check the lock stack first and if it is a recursive lightweight [un]lock and in that case simply pop/push and finish successfully.
>> 
>> Only if the recursive lightweight [un]lock fails does it look at the mark word. 
>> 
>> For the shared part if it is an unstructured exit, the monitor is inflated or the mark word transition fails it calls into the runtime.
>> 
>> The C2 operates under a few more assumptions, that the locking is structured and balanced. This means that some checks can be elided. 
>> 
>> First this means that in C2 unlock if the obj is not on the top of the lock stack, it must be inflated. And reversely if we reach the inflated C2 unlock the obj is not on the lock stack. This second property makes it possible to avoid reading the owner (and checking if it is anonymous). Instead it can either just do an un-contended unlock by writing null to the owner, or if contention happens, simply write the thread to the owner and jump to the runtime. 
>> 
>> The aarch64 C2 port tries to avoid stronger memory semantics where ever possible. In C2 lock it first does a relaxed load of the mark word to check for inflation. Both lock and unlock uses a load/store exclusive register pair to transition the mark word.
>
> 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 79 commits:
> 
>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8319801
>  - Revert "Update src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp"
>    
>    This reverts commit 130cf4b7f5b37ecb9dda3ce07ed70c3da13b29b8.
>  - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319801
>  - Running out of LogTagSets, stick with monitorinflation
>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8319797
>  - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319801
>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8319797
>  - Fix assert comment
>  - Update src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp
>    
>    Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>
>  - Clarify the rscratch1 assert
>  - ... and 69 more: https://git.openjdk.org/jdk/compare/c266800a...20e92608

src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 384:

> 382:     br(Assembler::EQ, unlocked);
> 383: 
> 384:     // Load link store conditional exclusive failed.

Suggestion:

    // Compare and exchange failed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16608#discussion_r1487767401

From aboldtch at openjdk.org  Tue Feb 13 12:34:30 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 13 Feb 2024 12:34:30 GMT
Subject: RFR: 8319799: Recursive lightweight locking: x86 implementation
 [v19]
In-Reply-To: <ymgsUW7sq02C2r82WrLYof5Eb7BB5Lh8M-kGoHx_Zjg=.a5a76651-4931-489f-8ea1-158716614119@github.com>
References: <ymgsUW7sq02C2r82WrLYof5Eb7BB5Lh8M-kGoHx_Zjg=.a5a76651-4931-489f-8ea1-158716614119@github.com>
Message-ID: <0SII2Lg6tzQy1ovSuJR64oxgXvN2Sf5pWG3nofIpNk8=.2ee1da59-993e-445b-ae6c-6592800e33b4@github.com>

> Implements the x86 port of JDK-8319796.
> 
> There are two major parts for the port implementation. The C2 part, and the part shared by the interpreter, C1 and the native call wrapper.
> 
> The biggest change for both parts is that we check the lock stack first and if it is a recursive lightweight [un]lock and in that case simply pop/push and finish successfully.
> 
> Only if the recursive lightweight [un]lock fails does it look at the mark word. 
> 
> For the shared part if it is an unstructured exit, the monitor is inflated or the mark word transition fails it calls into the runtime.
> 
> The C2 operates under a few more assumptions, that the locking is structured and balanced. This means that some checks can be elided. 
> 
> First this means that in C2 unlock if the obj is not on the top of the lock stack, it must be inflated. And reversely if we reach the inflated C2 unlock the obj is not on the lock stack. This second property makes it possible to avoid reading the owner (and checking if it is anonymous). Instead it can either just do an un-contended unlock by writing null to the owner, or if contention happens, simply write the thread to the owner and jump to the runtime. 
> 
> The x86 C2 port also has some extra oddities. 
> 
> The mark word read is done early as it showed better scaling in hyper-threaded scenarios on certain intel hardware, and no noticeable downside on other tested x86 hardware. 
> 
> The fast path is written to avoid going through conditional branches. This in combination with keeping the ZF output correct, the code does some actions eagerly, decrementing the held monitor count, popping from the lock stack. And jumps to a code stub if a slow path is required which restores the thread local state to a correct state before jumping to the runtime.
> 
> The contended unlock was also moved to the code stub.

Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:

  Fix Merge

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16607/files
  - new: https://git.openjdk.org/jdk/pull/16607/files/4d97e88c..4b54751b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16607&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16607&range=17-18

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

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

From aboldtch at openjdk.org  Tue Feb 13 12:41:36 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 13 Feb 2024 12:41:36 GMT
Subject: RFR: 8319801: Recursive lightweight locking: aarch64
 implementation [v17]
In-Reply-To: <AE1nsnyRCUHR970jjg4feUm5f6E1GPJvea0ooC6dCgI=.73fff610-c0f6-422a-a45d-88187b37b9a2@github.com>
References: <AE1nsnyRCUHR970jjg4feUm5f6E1GPJvea0ooC6dCgI=.73fff610-c0f6-422a-a45d-88187b37b9a2@github.com>
Message-ID: <lVVNR7JVB_oTKzelOE9Ee5mJ76Q2luvEsp8Vk85raCI=.b187b1b6-d1bc-47db-908f-91a4c34ab6e9@github.com>

> Implements the aarch64 port of JDK-8319796.
> 
> There are two major parts for the port implementation. The C2 part, and the part shared by the interpreter, C1 and the native call wrapper.
> 
> The biggest change for both parts is that we check the lock stack first and if it is a recursive lightweight [un]lock and in that case simply pop/push and finish successfully.
> 
> Only if the recursive lightweight [un]lock fails does it look at the mark word. 
> 
> For the shared part if it is an unstructured exit, the monitor is inflated or the mark word transition fails it calls into the runtime.
> 
> The C2 operates under a few more assumptions, that the locking is structured and balanced. This means that some checks can be elided. 
> 
> First this means that in C2 unlock if the obj is not on the top of the lock stack, it must be inflated. And reversely if we reach the inflated C2 unlock the obj is not on the lock stack. This second property makes it possible to avoid reading the owner (and checking if it is anonymous). Instead it can either just do an un-contended unlock by writing null to the owner, or if contention happens, simply write the thread to the owner and jump to the runtime. 
> 
> The aarch64 C2 port tries to avoid stronger memory semantics where ever possible. In C2 lock it first does a relaxed load of the mark word to check for inflation. Both lock and unlock uses a load/store exclusive register pair to transition the mark word.

Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp
  
  Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16608/files
  - new: https://git.openjdk.org/jdk/pull/16608/files/20e92608..0eef1f46

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16608&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16608&range=15-16

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

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

From aboldtch at openjdk.org  Tue Feb 13 12:41:38 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 13 Feb 2024 12:41:38 GMT
Subject: RFR: 8319801: Recursive lightweight locking: aarch64
 implementation [v16]
In-Reply-To: <Zf7ftbzhitkIkE34s5wBH-FbBXnVwl_31FfpByUD9y0=.2099b428-3f90-4029-89f4-00ac83622541@github.com>
References: <AE1nsnyRCUHR970jjg4feUm5f6E1GPJvea0ooC6dCgI=.73fff610-c0f6-422a-a45d-88187b37b9a2@github.com>
 <CSIkQw9NjfsFbuQ_P-gbX3iaKNQU5-YvGe6HWjRBkME=.ea80bc31-87b8-4299-a2dd-67497115c315@github.com>
 <Zf7ftbzhitkIkE34s5wBH-FbBXnVwl_31FfpByUD9y0=.2099b428-3f90-4029-89f4-00ac83622541@github.com>
Message-ID: <TbgoSES6gs8XYmPH7Nu0Ru6HKyo7-H6IJVsIW08QXWg=.9f82b55e-6a6c-4588-b667-ec30ddafe71a@github.com>

On Tue, 13 Feb 2024 12:22:45 GMT, Andrew Haley <aph 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 79 commits:
>> 
>>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8319801
>>  - Revert "Update src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp"
>>    
>>    This reverts commit 130cf4b7f5b37ecb9dda3ce07ed70c3da13b29b8.
>>  - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319801
>>  - Running out of LogTagSets, stick with monitorinflation
>>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8319797
>>  - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319801
>>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8319797
>>  - Fix assert comment
>>  - Update src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp
>>    
>>    Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>
>>  - Clarify the rscratch1 assert
>>  - ... and 69 more: https://git.openjdk.org/jdk/compare/c266800a...20e92608
>
> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 243:
> 
>> 241:     ldrw(t1, Address(t1, Klass::access_flags_offset()));
>> 242:     tstw(t1, JVM_ACC_IS_VALUE_BASED_CLASS);
>> 243:     br(Assembler::NE, slow_path);
> 
> Suggestion:
> 
>     tbnz(t1, exact_log2(JVM_ACC_IS_VALUE_BASED_CLASS));

The condition flags must be correct when leaving `fast_lock` and `fast_unlock`. The test is used to set the proper NE condition when jumping out.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16608#discussion_r1487774734

From aph at openjdk.org  Tue Feb 13 12:41:38 2024
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 13 Feb 2024 12:41:38 GMT
Subject: RFR: 8319801: Recursive lightweight locking: aarch64
 implementation [v16]
In-Reply-To: <CSIkQw9NjfsFbuQ_P-gbX3iaKNQU5-YvGe6HWjRBkME=.ea80bc31-87b8-4299-a2dd-67497115c315@github.com>
References: <AE1nsnyRCUHR970jjg4feUm5f6E1GPJvea0ooC6dCgI=.73fff610-c0f6-422a-a45d-88187b37b9a2@github.com>
 <CSIkQw9NjfsFbuQ_P-gbX3iaKNQU5-YvGe6HWjRBkME=.ea80bc31-87b8-4299-a2dd-67497115c315@github.com>
Message-ID: <yMtyXpGAUu6rihQ81l6xXwXsSx3BCWD2nPnshE5VU5Y=.556278ed-64f6-477f-9366-b32f69b8b354@github.com>

On Tue, 13 Feb 2024 10:36:20 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Implements the aarch64 port of JDK-8319796.
>> 
>> There are two major parts for the port implementation. The C2 part, and the part shared by the interpreter, C1 and the native call wrapper.
>> 
>> The biggest change for both parts is that we check the lock stack first and if it is a recursive lightweight [un]lock and in that case simply pop/push and finish successfully.
>> 
>> Only if the recursive lightweight [un]lock fails does it look at the mark word. 
>> 
>> For the shared part if it is an unstructured exit, the monitor is inflated or the mark word transition fails it calls into the runtime.
>> 
>> The C2 operates under a few more assumptions, that the locking is structured and balanced. This means that some checks can be elided. 
>> 
>> First this means that in C2 unlock if the obj is not on the top of the lock stack, it must be inflated. And reversely if we reach the inflated C2 unlock the obj is not on the lock stack. This second property makes it possible to avoid reading the owner (and checking if it is anonymous). Instead it can either just do an un-contended unlock by writing null to the owner, or if contention happens, simply write the thread to the owner and jump to the runtime. 
>> 
>> The aarch64 C2 port tries to avoid stronger memory semantics where ever possible. In C2 lock it first does a relaxed load of the mark word to check for inflation. Both lock and unlock uses a load/store exclusive register pair to transition the mark word.
>
> 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 79 commits:
> 
>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8319801
>  - Revert "Update src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp"
>    
>    This reverts commit 130cf4b7f5b37ecb9dda3ce07ed70c3da13b29b8.
>  - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319801
>  - Running out of LogTagSets, stick with monitorinflation
>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8319797
>  - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319801
>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8319797
>  - Fix assert comment
>  - Update src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp
>    
>    Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>
>  - Clarify the rscratch1 assert
>  - ... and 69 more: https://git.openjdk.org/jdk/compare/c266800a...20e92608

src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 416:

> 414: 
> 415:     // mark contains the tagged ObjectMonitor*.
> 416:     const Register monitor = mark;

I wouldn't do this. Making `monitor` a register alias for `mark` is at best confusing and at worst dangerous. As a general rule, aliased register names have caused many bugs.

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 6371:

> 6369: 
> 6370:   // Check header for monitor (0b10).
> 6371:   tst(mark, markWord::monitor_value);

Do you need the flag here, or can you use `tbnz`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16608#discussion_r1487771125
PR Review Comment: https://git.openjdk.org/jdk/pull/16608#discussion_r1487778288

From aboldtch at openjdk.org  Tue Feb 13 12:41:38 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 13 Feb 2024 12:41:38 GMT
Subject: RFR: 8319801: Recursive lightweight locking: aarch64
 implementation [v16]
In-Reply-To: <TbgoSES6gs8XYmPH7Nu0Ru6HKyo7-H6IJVsIW08QXWg=.9f82b55e-6a6c-4588-b667-ec30ddafe71a@github.com>
References: <AE1nsnyRCUHR970jjg4feUm5f6E1GPJvea0ooC6dCgI=.73fff610-c0f6-422a-a45d-88187b37b9a2@github.com>
 <CSIkQw9NjfsFbuQ_P-gbX3iaKNQU5-YvGe6HWjRBkME=.ea80bc31-87b8-4299-a2dd-67497115c315@github.com>
 <Zf7ftbzhitkIkE34s5wBH-FbBXnVwl_31FfpByUD9y0=.2099b428-3f90-4029-89f4-00ac83622541@github.com>
 <TbgoSES6gs8XYmPH7Nu0Ru6HKyo7-H6IJVsIW08QXWg=.9f82b55e-6a6c-4588-b667-ec30ddafe71a@github.com>
Message-ID: <BcFGeLUbsOvh7DujM4NTByTxBk9uaefGe4BdRnCmpmI=.0543d37e-2601-485e-9bc8-107ef7910718@github.com>

On Tue, 13 Feb 2024 12:35:48 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 243:
>> 
>>> 241:     ldrw(t1, Address(t1, Klass::access_flags_offset()));
>>> 242:     tstw(t1, JVM_ACC_IS_VALUE_BASED_CLASS);
>>> 243:     br(Assembler::NE, slow_path);
>> 
>> Suggestion:
>> 
>>     tbnz(t1, exact_log2(JVM_ACC_IS_VALUE_BASED_CLASS));
>
> The condition flags must be correct when leaving `fast_lock` and `fast_unlock`. The test is used to set the proper NE condition when jumping out.

The condition flags must be correct when leaving `fast_lock` and `fast_unlock`. The test is used to set the proper NE condition when jumping out.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16608#discussion_r1487774869

From aboldtch at openjdk.org  Tue Feb 13 12:46:13 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 13 Feb 2024 12:46:13 GMT
Subject: RFR: 8319801: Recursive lightweight locking: aarch64
 implementation [v16]
In-Reply-To: <yMtyXpGAUu6rihQ81l6xXwXsSx3BCWD2nPnshE5VU5Y=.556278ed-64f6-477f-9366-b32f69b8b354@github.com>
References: <AE1nsnyRCUHR970jjg4feUm5f6E1GPJvea0ooC6dCgI=.73fff610-c0f6-422a-a45d-88187b37b9a2@github.com>
 <CSIkQw9NjfsFbuQ_P-gbX3iaKNQU5-YvGe6HWjRBkME=.ea80bc31-87b8-4299-a2dd-67497115c315@github.com>
 <yMtyXpGAUu6rihQ81l6xXwXsSx3BCWD2nPnshE5VU5Y=.556278ed-64f6-477f-9366-b32f69b8b354@github.com>
Message-ID: <YErOWtkXfC9QmAeqmlkM83U_AZ9LjmIoNOFhouWwJA8=.72bdde50-3968-4c9e-9e8d-f16528b0d9db@github.com>

On Tue, 13 Feb 2024 12:38:45 GMT, Andrew Haley <aph 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 79 commits:
>> 
>>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8319801
>>  - Revert "Update src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp"
>>    
>>    This reverts commit 130cf4b7f5b37ecb9dda3ce07ed70c3da13b29b8.
>>  - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319801
>>  - Running out of LogTagSets, stick with monitorinflation
>>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8319797
>>  - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319801
>>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8319797
>>  - Fix assert comment
>>  - Update src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp
>>    
>>    Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>
>>  - Clarify the rscratch1 assert
>>  - ... and 69 more: https://git.openjdk.org/jdk/compare/c266800a...20e92608
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 6371:
> 
>> 6369: 
>> 6370:   // Check header for monitor (0b10).
>> 6371:   tst(mark, markWord::monitor_value);
> 
> Do you need the flag here, or can you use `tbnz`?

Not after this change. (Will double check, but it should only be C2 that required this and C2 does no longer use `MacroAssembler::lightweight_lock`) It can be a `tbnz`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16608#discussion_r1487783659

From aph at openjdk.org  Tue Feb 13 12:53:08 2024
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 13 Feb 2024 12:53:08 GMT
Subject: RFR: 8319801: Recursive lightweight locking: aarch64
 implementation [v16]
In-Reply-To: <BcFGeLUbsOvh7DujM4NTByTxBk9uaefGe4BdRnCmpmI=.0543d37e-2601-485e-9bc8-107ef7910718@github.com>
References: <AE1nsnyRCUHR970jjg4feUm5f6E1GPJvea0ooC6dCgI=.73fff610-c0f6-422a-a45d-88187b37b9a2@github.com>
 <CSIkQw9NjfsFbuQ_P-gbX3iaKNQU5-YvGe6HWjRBkME=.ea80bc31-87b8-4299-a2dd-67497115c315@github.com>
 <Zf7ftbzhitkIkE34s5wBH-FbBXnVwl_31FfpByUD9y0=.2099b428-3f90-4029-89f4-00ac83622541@github.com>
 <TbgoSES6gs8XYmPH7Nu0Ru6HKyo7-H6IJVsIW08QXWg=.9f82b55e-6a6c-4588-b667-ec30ddafe71a@github.com>
 <BcFGeLUbsOvh7DujM4NTByTxBk9uaefGe4BdRnCmpmI=.0543d37e-2601-485e-9bc8-107ef7910718@github.com>
Message-ID: <pR2H0zlL-nQupIJHI5OX02VlNyLQNiDK1ldE2a5btME=.de8a6a3e-d981-444e-9243-6c3a90c00acf@github.com>

On Tue, 13 Feb 2024 12:35:56 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The condition flags must be correct when leaving `fast_lock` and `fast_unlock`. The test is used to set the proper NE condition when jumping out.
>
> The condition flags must be correct when leaving `fast_lock` and `fast_unlock`. The test is used to set the proper NE condition when jumping out.

Please add a comment to that effect.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16608#discussion_r1487795034

From aboldtch at openjdk.org  Tue Feb 13 13:03:07 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 13 Feb 2024 13:03:07 GMT
Subject: RFR: 8319801: Recursive lightweight locking: aarch64
 implementation [v16]
In-Reply-To: <pR2H0zlL-nQupIJHI5OX02VlNyLQNiDK1ldE2a5btME=.de8a6a3e-d981-444e-9243-6c3a90c00acf@github.com>
References: <AE1nsnyRCUHR970jjg4feUm5f6E1GPJvea0ooC6dCgI=.73fff610-c0f6-422a-a45d-88187b37b9a2@github.com>
 <CSIkQw9NjfsFbuQ_P-gbX3iaKNQU5-YvGe6HWjRBkME=.ea80bc31-87b8-4299-a2dd-67497115c315@github.com>
 <Zf7ftbzhitkIkE34s5wBH-FbBXnVwl_31FfpByUD9y0=.2099b428-3f90-4029-89f4-00ac83622541@github.com>
 <TbgoSES6gs8XYmPH7Nu0Ru6HKyo7-H6IJVsIW08QXWg=.9f82b55e-6a6c-4588-b667-ec30ddafe71a@github.com>
 <BcFGeLUbsOvh7DujM4NTByTxBk9uaefGe4BdRnCmpmI=.0543d37e-2601-485e-9bc8-107ef7910718@github.com>
 <pR2H0zlL-nQupIJHI5OX02VlNyLQNiDK1ldE2a5btME=.de8a6a3e-d981-444e-9243-6c3a90c00acf@github.com>
Message-ID: <7-bqABHbMRkFNt6G_S33SWxtE1gt68E_mlzE1LX2GHs=.d280be61-af50-48d6-8ae1-5f32a7c0a5ed@github.com>

On Tue, 13 Feb 2024 12:50:41 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> The condition flags must be correct when leaving `fast_lock` and `fast_unlock`. The test is used to set the proper NE condition when jumping out.
>
> Please add a comment to that effect.

The comments on the labels above is not enough. You would like comments on every branch?
```C++
  // Finish fast lock successfully. MUST branch to with flag == EQ
  Label locked;
  // Finish fast lock unsuccessfully. MUST branch to with flag == NE
  Label slow_path;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16608#discussion_r1487808480

From aboldtch at openjdk.org  Tue Feb 13 13:33:07 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 13 Feb 2024 13:33:07 GMT
Subject: RFR: 8319801: Recursive lightweight locking: aarch64
 implementation [v16]
In-Reply-To: <YErOWtkXfC9QmAeqmlkM83U_AZ9LjmIoNOFhouWwJA8=.72bdde50-3968-4c9e-9e8d-f16528b0d9db@github.com>
References: <AE1nsnyRCUHR970jjg4feUm5f6E1GPJvea0ooC6dCgI=.73fff610-c0f6-422a-a45d-88187b37b9a2@github.com>
 <CSIkQw9NjfsFbuQ_P-gbX3iaKNQU5-YvGe6HWjRBkME=.ea80bc31-87b8-4299-a2dd-67497115c315@github.com>
 <yMtyXpGAUu6rihQ81l6xXwXsSx3BCWD2nPnshE5VU5Y=.556278ed-64f6-477f-9366-b32f69b8b354@github.com>
 <YErOWtkXfC9QmAeqmlkM83U_AZ9LjmIoNOFhouWwJA8=.72bdde50-3968-4c9e-9e8d-f16528b0d9db@github.com>
Message-ID: <48XpFj7qeO1D8G_NEZPArK9u_eds9ncCdTbzVpVwCd4=.2e41dfad-741f-4cff-991a-49493dddbba6@github.com>

On Tue, 13 Feb 2024 12:42:14 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 6371:
>> 
>>> 6369: 
>>> 6370:   // Check header for monitor (0b10).
>>> 6371:   tst(mark, markWord::monitor_value);
>> 
>> Do you need the flag here, or can you use `tbnz`?
>
> Not after this change. (Will double check, but it should only be C2 that required this and C2 does no longer use `MacroAssembler::lightweight_lock`) It can be a `tbnz`.

Just did a quick sanity check. The destination will be to far away for `tbnz`. This behaviour rings a bell for me. I probably tried this before. Maybe should add a comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16608#discussion_r1487852305

From stefank at openjdk.org  Tue Feb 13 14:58:11 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 13 Feb 2024 14:58:11 GMT
Subject: RFR: 8325752: Remove badMetaWordVal
Message-ID: <v1BkRnvyaYCtHUIacFVTKCksyhfsztbOagcblclKqbo=.80fd7a70-bd50-4428-af18-c6a4495f8ea6@github.com>

This is another artifact from the permgen removal. At some point we used to zap Metaspace with badMetaWordVal, but we don't do that anymore and therefore we should stop looking for this value.

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

Commit messages:
 - 8325752: Remove badMetaWordVal

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

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

From coleenp at openjdk.org  Tue Feb 13 15:03:03 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 13 Feb 2024 15:03:03 GMT
Subject: RFR: 8325752: Remove badMetaWordVal
In-Reply-To: <v1BkRnvyaYCtHUIacFVTKCksyhfsztbOagcblclKqbo=.80fd7a70-bd50-4428-af18-c6a4495f8ea6@github.com>
References: <v1BkRnvyaYCtHUIacFVTKCksyhfsztbOagcblclKqbo=.80fd7a70-bd50-4428-af18-c6a4495f8ea6@github.com>
Message-ID: <uubBgWZZzFflIuQO5yNq-mkwrJ5Z3gZ2mCgkFL5705E=.df3563f1-149d-4ddb-ac09-17f3a336c941@github.com>

On Tue, 13 Feb 2024 14:53:23 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> This is another artifact from the permgen removal. At some point we used to zap Metaspace with badMetaWordVal, but we don't do that anymore and therefore we should stop looking for this value.

Nice cleanup and trivial.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17833#pullrequestreview-1878188534

From eosterlund at openjdk.org  Tue Feb 13 15:09:15 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 13 Feb 2024 15:09:15 GMT
Subject: RFR: 8324933: ConcurrentHashTable::statistics_calculate
 synchronization is expensive [v2]
In-Reply-To: <NJfgJhNA7l0K3gBr5MmE4RAxG2j4I_iv92Sjx12TXwA=.47dd95f2-25e9-4201-aecf-15f958a76617@github.com>
References: <BWI_sYMoH8SOp_kpYvkmFrHcBP38G_sMW4_LJR_8Ev0=.ffc95dc6-b110-4c22-ac32-6eaa10c7a6c1@github.com>
 <NJfgJhNA7l0K3gBr5MmE4RAxG2j4I_iv92Sjx12TXwA=.47dd95f2-25e9-4201-aecf-15f958a76617@github.com>
Message-ID: <QHi-hobncyCs167Kg5_yf-CF2MVefBXJwvcdp21cklE=.85f1015f-0db3-4220-af29-859386920304@github.com>

On Wed, 31 Jan 2024 11:12:08 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/hotspot/share/utilities/concurrentHashTable.inline.hpp
>>   
>>   Co-authored-by: Thomas Schatzl <59967451+tschatzl at users.noreply.github.com>
>
> Changes requested by tschatzl (Reviewer).

Thanks for the review @tschatzl! I liked your suggested change. It looks simpler now.

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

PR Comment: https://git.openjdk.org/jdk/pull/17629#issuecomment-1941723960

From eosterlund at openjdk.org  Tue Feb 13 15:09:15 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 13 Feb 2024 15:09:15 GMT
Subject: RFR: 8324933: ConcurrentHashTable::statistics_calculate
 synchronization is expensive [v2]
In-Reply-To: <BWI_sYMoH8SOp_kpYvkmFrHcBP38G_sMW4_LJR_8Ev0=.ffc95dc6-b110-4c22-ac32-6eaa10c7a6c1@github.com>
References: <BWI_sYMoH8SOp_kpYvkmFrHcBP38G_sMW4_LJR_8Ev0=.ffc95dc6-b110-4c22-ac32-6eaa10c7a6c1@github.com>
Message-ID: <gHRVBbP8P0EVcdwCK8P1oKW62VmOfl2zQbVNCespZhE=.dffdb303-0421-4720-9bbd-503c0d094a94@github.com>

> In the ConcurrentHashTable::statistics_calculate function, we enter and exit a ScopedCS with the global counter for every single bucket. This has showed up to be pretty intense on some machines. We should make the synchronization a bit less intense here. This patch adds simple batching so we synchronize once per 128 buckets instead of every single one.

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

  Update src/hotspot/share/utilities/concurrentHashTable.inline.hpp
  
  Co-authored-by: Thomas Schatzl <59967451+tschatzl at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17629/files
  - new: https://git.openjdk.org/jdk/pull/17629/files/f0b8f46a..a6a7e3c8

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

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

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

From eosterlund at openjdk.org  Tue Feb 13 15:22:16 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 13 Feb 2024 15:22:16 GMT
Subject: RFR: 8324933: ConcurrentHashTable::statistics_calculate
 synchronization is expensive [v3]
In-Reply-To: <BWI_sYMoH8SOp_kpYvkmFrHcBP38G_sMW4_LJR_8Ev0=.ffc95dc6-b110-4c22-ac32-6eaa10c7a6c1@github.com>
References: <BWI_sYMoH8SOp_kpYvkmFrHcBP38G_sMW4_LJR_8Ev0=.ffc95dc6-b110-4c22-ac32-6eaa10c7a6c1@github.com>
Message-ID: <LW8jCueDdE8uzFV7QPseNJbhrIsLdp39lwtJDEplD3s=.d437bc80-1b34-44a4-a1ce-723fe53703c1@github.com>

> In the ConcurrentHashTable::statistics_calculate function, we enter and exit a ScopedCS with the global counter for every single bucket. This has showed up to be pretty intense on some machines. We should make the synchronization a bit less intense here. This patch adds simple batching so we synchronize once per 128 buckets instead of every single one.

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

  Build fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17629/files
  - new: https://git.openjdk.org/jdk/pull/17629/files/a6a7e3c8..3b26cf9c

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

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

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

From coleenp at openjdk.org  Tue Feb 13 15:55:04 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 13 Feb 2024 15:55:04 GMT
Subject: RFR: 8324933: ConcurrentHashTable::statistics_calculate
 synchronization is expensive [v3]
In-Reply-To: <LW8jCueDdE8uzFV7QPseNJbhrIsLdp39lwtJDEplD3s=.d437bc80-1b34-44a4-a1ce-723fe53703c1@github.com>
References: <BWI_sYMoH8SOp_kpYvkmFrHcBP38G_sMW4_LJR_8Ev0=.ffc95dc6-b110-4c22-ac32-6eaa10c7a6c1@github.com>
 <LW8jCueDdE8uzFV7QPseNJbhrIsLdp39lwtJDEplD3s=.d437bc80-1b34-44a4-a1ce-723fe53703c1@github.com>
Message-ID: <ZmcThsGuqFE6syvpOmj03fAnZOk9lSZlMXGQnFOoYvI=.a481d80f-002c-4680-98a5-767dea8dbf97@github.com>

On Tue, 13 Feb 2024 15:22:16 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> In the ConcurrentHashTable::statistics_calculate function, we enter and exit a ScopedCS with the global counter for every single bucket. This has showed up to be pretty intense on some machines. We should make the synchronization a bit less intense here. This patch adds simple batching so we synchronize once per 128 buckets instead of every single one.
>
> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Build fix

This seems reasonable, as long as the critical section is held throughout a bucket iteration.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17629#pullrequestreview-1878335444

From aph at openjdk.org  Tue Feb 13 16:32:07 2024
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 13 Feb 2024 16:32:07 GMT
Subject: RFR: 8319801: Recursive lightweight locking: aarch64
 implementation [v16]
In-Reply-To: <7-bqABHbMRkFNt6G_S33SWxtE1gt68E_mlzE1LX2GHs=.d280be61-af50-48d6-8ae1-5f32a7c0a5ed@github.com>
References: <AE1nsnyRCUHR970jjg4feUm5f6E1GPJvea0ooC6dCgI=.73fff610-c0f6-422a-a45d-88187b37b9a2@github.com>
 <CSIkQw9NjfsFbuQ_P-gbX3iaKNQU5-YvGe6HWjRBkME=.ea80bc31-87b8-4299-a2dd-67497115c315@github.com>
 <Zf7ftbzhitkIkE34s5wBH-FbBXnVwl_31FfpByUD9y0=.2099b428-3f90-4029-89f4-00ac83622541@github.com>
 <TbgoSES6gs8XYmPH7Nu0Ru6HKyo7-H6IJVsIW08QXWg=.9f82b55e-6a6c-4588-b667-ec30ddafe71a@github.com>
 <BcFGeLUbsOvh7DujM4NTByTxBk9uaefGe4BdRnCmpmI=.0543d37e-2601-485e-9bc8-107ef7910718@github.com>
 <pR2H0zlL-nQupIJHI5OX02VlNyLQNiDK1ldE2a5btME=.de8a6a3e-d981-444e-9243-6c3a90c00acf@github.com>
 <7-bqABHbMRkFNt6G_S33SWxtE1gt68E_mlzE1LX2GHs=.d280be61-af50-48d6-8ae1-5f32a7c0a5ed@github.com>
Message-ID: <a0MdMc1e33cWA3c2tGihgvzcXp2Wv4r7jDWjZnPdvYE=.6685d97e-873f-4887-bd36-39954148d881@github.com>

On Tue, 13 Feb 2024 13:00:24 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Please add a comment to that effect.
>
> The comments on the labels above is not enough. You would like comments on every branch?
> ```C++
>   // Finish fast lock successfully. MUST branch to with flag == EQ
>   Label locked;
>   // Finish fast lock unsuccessfully. MUST branch to with flag == NE
>   Label slow_path;

I guess that's a fair point. Preserving flags across branches is very fragile, but I guess that's the way we've always done it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16608#discussion_r1488202392

From aph at openjdk.org  Tue Feb 13 16:32:07 2024
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 13 Feb 2024 16:32:07 GMT
Subject: RFR: 8319801: Recursive lightweight locking: aarch64
 implementation [v16]
In-Reply-To: <48XpFj7qeO1D8G_NEZPArK9u_eds9ncCdTbzVpVwCd4=.2e41dfad-741f-4cff-991a-49493dddbba6@github.com>
References: <AE1nsnyRCUHR970jjg4feUm5f6E1GPJvea0ooC6dCgI=.73fff610-c0f6-422a-a45d-88187b37b9a2@github.com>
 <CSIkQw9NjfsFbuQ_P-gbX3iaKNQU5-YvGe6HWjRBkME=.ea80bc31-87b8-4299-a2dd-67497115c315@github.com>
 <yMtyXpGAUu6rihQ81l6xXwXsSx3BCWD2nPnshE5VU5Y=.556278ed-64f6-477f-9366-b32f69b8b354@github.com>
 <YErOWtkXfC9QmAeqmlkM83U_AZ9LjmIoNOFhouWwJA8=.72bdde50-3968-4c9e-9e8d-f16528b0d9db@github.com>
 <48XpFj7qeO1D8G_NEZPArK9u_eds9ncCdTbzVpVwCd4=.2e41dfad-741f-4cff-991a-49493dddbba6@github.com>
Message-ID: <pRiaitbGbZc2dmxwZH4V1xTm40MU03Y15bGpI7-tfbw=.56295ee7-c959-4222-a224-cd2ecfb1a1a8@github.com>

On Tue, 13 Feb 2024 13:30:06 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Not after this change. (Will double check, but it should only be C2 that required this and C2 does no longer use `MacroAssembler::lightweight_lock`) It can be a `tbnz`.
>
> Just did a quick sanity check. The destination will be to far away for `tbnz`. This behaviour rings a bell for me. I probably tried this before. Maybe should add a comment.

I guess so, yes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16608#discussion_r1488203422

From cslucas at openjdk.org  Tue Feb 13 17:33:05 2024
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Tue, 13 Feb 2024 17:33:05 GMT
Subject: RFR: JDK-8316991: Reduce nullable allocation merges [v7]
In-Reply-To: <HXz9qbuYdO13U26jua8BNaw8R9GCPYhcY8HOhRA_jeY=.cb646c98-744b-4471-be23-7b4526f02c00@github.com>
References: <oA9n8Jdk9nSFnavcnYIx7psI1MFqajCuoaX-EXsIa-o=.20436bef-d784-49a6-a696-6f8b2e22e1dd@github.com>
 <HXz9qbuYdO13U26jua8BNaw8R9GCPYhcY8HOhRA_jeY=.cb646c98-744b-4471-be23-7b4526f02c00@github.com>
Message-ID: <Mxt2Uf1QGaE0cW6yMkuosQ6j2AEAo8EOAOpGqJDEs3c=.072adcf0-6c05-495f-afb9-540c7540be10@github.com>

On Fri, 15 Dec 2023 18:14:00 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> ### Description
>> 
>> Many, if not most, allocation merges (Phis) are nullable because they join object allocations with "NULL", or objects returned from method calls, etc. Please review this Pull Request that improves Reduce Allocation Merge implementation so that it can reduce at least some of these allocation merges.
>> 
>> Overall, the improvements are related to 1) making rematerialization of merges able to represent "NULL" objects, and 2) being able to reduce merges used by CmpP/N and CastPP. 
>> 
>> The approach to reducing CmpP/N and CastPP is pretty similar to that used in the `MemNode::split_through_phi` method: a clone of the node being split is added on each input of the Phi. I make use of `optimize_ptr_compare` and some type information to remove redundant CmpP and CastPP nodes. I added a bunch of ASCII diagrams illustrating what some of the more important methods are doing.
>> 
>> ### Benchmarking
>> 
>> **Note:** In some of these tests no reduction happens. I left them in to validate that no perf. regression happens in that case.
>> **Note 2:** Marging of error was negligible.
>> 
>> | Benchmark                            |  No RAM (ms/op)  |   Yes RAM (ms/op) |
>> |--------------------------------------|------------------|-------------------|
>> | TestTrapAfterMerge                   |      19.515      |      13.386       |
>> | TestArgEscape                        |      33.165      |      33.254       |
>> | TestCallTwoSide                      |      70.547      |      69.427       |
>> | TestCmpAfterMerge                    |      16.400      |       2.984       |
>> | TestCmpMergeWithNull_Second          |      27.204      |      27.293       |
>> | TestCmpMergeWithNull                 |       8.248      |       4.920       |
>> | TestCondAfterMergeWithAllocate       |      12.890      |       5.252       |
>> | TestCondAfterMergeWithNull           |       6.265      |       5.078       |
>> | TestCondLoadAfterMerge               |      12.713      |       5.163       |
>> | TestConsecutiveSimpleMerge           |      30.863      |       4.068       |
>> | TestDoubleIfElseMerge                |      16.069      |       2.444       |
>> | TestEscapeInCallAfterMerge           |      23.111      |      22.924       |
>> | TestGlobalEscape                     |      14.459      |      14.425       |
>> | TestIfElseInLoop                     |     246.061      |      42.786       |
>> | TestLoadAfterLoopAlias               |      45.808      |      45.812       |
>> ...
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix broken build.

Please, keep this open.

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

PR Comment: https://git.openjdk.org/jdk/pull/15825#issuecomment-1942064570

From lkorinth at openjdk.org  Tue Feb 13 18:18:02 2024
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 13 Feb 2024 18:18:02 GMT
Subject: RFR: 8320750: Allow a testcase to run with multiple -Xlog [v3]
In-Reply-To: <5X9jP4sjy5xySO3hGJI62s-0L6708818Q3MRhxgYvsw=.cde8ba69-80ef-495a-9d81-ec45e5133816@github.com>
References: <LzqG8tmHZgoSqxPjEnULam9uGycRNpdBuPoUjXAdze0=.df98f685-7800-475e-ad3e-7d555c1470ea@github.com>
 <5X9jP4sjy5xySO3hGJI62s-0L6708818Q3MRhxgYvsw=.cde8ba69-80ef-495a-9d81-ec45e5133816@github.com>
Message-ID: <E-ZckTqla3oxL3Uwu9A7GqMoDqpqLIbbOqvx0kCKlYA=.c4b51a04-82c6-4b46-9605-6ce0136f1d50@github.com>

On Thu, 8 Feb 2024 10:15:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Running a testcase with muliple -Xlog crashes JTREG test cases. This is because `Collector.toMap` is not given a merge strategy.
>> 
>> When the same argument is passed multiple times, I have added a merge strategy to use the latter value. This is similar to how it is implemented for `vm.opt.*` in JTREG.
>> 
>> If the flag tested is `-Xlog`, replace the value part with a dummy value "NONEMPTY_TEST_SENTINEL". This is because in the case of multiple `-Xlog` all values are used, and JTREG does not give a satisfactory way to represent them. This dummy value should make it hard to try to `@require` on specific values by mistake.
>> 
>> Tested with:
>> 
>>  @requires vm.opt.x.Xlog == "NONEMPTY_TEST_SENTINEL"
>>  @requires vm.opt.x.Xlog == "NONEMPTY_TEST_SENTINELXXX"
>>  @requires vm.opt.x.Xms == "3g"
>> 
>> and
>> 
>> JAVA_OPTIONS=-Xms3g -Xms4g
>> JAVA_OPTIONS=-Xms4g -Xms3g
>> JAVA_OPTIONS=-Xlog:gc* -Xlog:gc*
>> ``` 
>> 
>> Running tier1
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix after comments from David

I have created https://bugs.openjdk.org/browse/JDK-8325763. After I have fixed that I will close this, after much thinking, I think it is better to get rid of the feature.

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

PR Comment: https://git.openjdk.org/jdk/pull/16824#issuecomment-1942133020

From dchuyko at openjdk.org  Tue Feb 13 22:07:19 2024
From: dchuyko at openjdk.org (Dmitry Chuyko)
Date: Tue, 13 Feb 2024 22:07:19 GMT
Subject: RFR: 8309271: A way to align already compiled methods with
 compiler directives [v25]
In-Reply-To: <hB_b875iSEC03cyQZ-VoMEcny7ZaoBu_yeH9lohqF44=.5c8f186c-44f8-407a-941e-328ad077f14a@github.com>
References: <csWpTiZu4dQgyARmNGro8PYl8yLj6-dRjVdsh51jV0k=.c0e25efd-3ee0-4196-a05a-c54268f23660@github.com>
 <hB_b875iSEC03cyQZ-VoMEcny7ZaoBu_yeH9lohqF44=.5c8f186c-44f8-407a-941e-328ad077f14a@github.com>
Message-ID: <xGcdfeCzIJ4cp-0aW2QZu_P_Xj_tiQlf_mNEm7nrUGg=.897a6e24-b240-4862-899f-0f9073b61223@github.com>

On Wed, 31 Jan 2024 21:12:19 GMT, Dmitry Chuyko <dchuyko at openjdk.org> wrote:

>> Compiler Control (https://openjdk.org/jeps/165) provides method-context dependent control of the JVM compilers (C1 and C2). The active directive stack is built from the directive files passed with the `-XX:CompilerDirectivesFile` diagnostic command-line option and the Compiler.add_directives diagnostic command. It is also possible to clear all directives or remove the top from the stack.
>> 
>> A matching directive will be applied at method compilation time when such compilation is started. If directives are added or changed, but compilation does not start, then the state of compiled methods doesn't correspond to the rules. This is not an error, and it happens in long running applications when directives are added or removed after compilation of methods that could be matched. For example, the user decides that C2 compilation needs to be disabled for some method due to a compiler bug, issues such a directive but this does not affect the application behavior. In such case, the target application needs to be restarted, and such an operation can have high costs and risks. Another goal is testing/debugging compilers.
>> 
>> It would be convenient to optionally reconcile at least existing matching nmethods to the current stack of compiler directives (so bypass inlined methods).
>> 
>> Natural way to eliminate the discrepancy between the result of compilation and the broken rule is to discard the compilation result, i.e. deoptimization. Prior to that we can try to re-compile the method letting compile broker to perform it taking new directives stack into account. Re-compilation helps to prevent hot methods from execution in the interpreter.
>> 
>> A new flag `-r` has beed introduced for some directives related to compile commands: `Compiler.add_directives`, `Compiler.remove_directives`, `Compiler.clear_directives`. The default behavior has not changed (no flag). If the new flag is present, the command scans already compiled methods and puts methods that have any active non-default matching compiler directives to re-compilation if possible, otherwise marks them for deoptimization. There is currently no distinction which directives are found. In particular, this means that if there are rules for inlining into some method, it will be refreshed. On the other hand, if there are rules for a method and it was inlined, top-level methods won't be refreshed, but this can be achieved by having rules for them.
>> 
>> In addition, a new diagnostic command `Compiler.replace_directives...
>
> Dmitry Chuyko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 43 commits:
> 
>  - Merge branch 'openjdk:master' into compiler-directives-force-update
>  - Merge branch 'openjdk:master' into compiler-directives-force-update
>  - Merge branch 'openjdk:master' into compiler-directives-force-update
>  - Merge branch 'openjdk:master' into compiler-directives-force-update
>  - Merge branch 'openjdk:master' into compiler-directives-force-update
>  - Merge branch 'openjdk:master' into compiler-directives-force-update
>  - Deopt osr, cleanups
>  - Merge branch 'openjdk:master' into compiler-directives-force-update
>  - Merge branch 'openjdk:master' into compiler-directives-force-update
>  - Merge branch 'openjdk:master' into compiler-directives-force-update
>  - ... and 33 more: https://git.openjdk.org/jdk/compare/5b9b176c...ea0322cd

@sspitsyn Can I please have someone from serviceability group take a look at this? Comments from Paul and Andrei have been addressed a while ago.

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

PR Comment: https://git.openjdk.org/jdk/pull/14111#issuecomment-1942717023

From dcubed at openjdk.org  Tue Feb 13 22:34:03 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 13 Feb 2024 22:34:03 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v4]
In-Reply-To: <FyUzHquSAC2WSUI0da52uhn7JQtJEsZiOGNWB9cEiIk=.0653f836-b00d-4b48-964a-cd8b6e0cb7aa@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <bKkHh3R39JCXKuQGrduWdZhJ9jstNA6xfUnJgPgbslE=.c1e27529-af8c-4707-9d24-473952502459@github.com>
 <5DPYtNaOL_44RemEpOUvNCJYISxC2bfUHakk7FVIj9k=.bd8baf61-bcf1-4c92-b31a-ef048e9dc64c@github.com>
 <FyUzHquSAC2WSUI0da52uhn7JQtJEsZiOGNWB9cEiIk=.0653f836-b00d-4b48-964a-cd8b6e0cb7aa@github.com>
Message-ID: <dDiWEBRVCO6Jd5BrbOdhYKgDf1YFkMPvIHA1WLKcZ_c=.d64f726e-c131-4db2-aa3d-0a3da5f274f6@github.com>

On Tue, 13 Feb 2024 08:39:38 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Sorry really struggling to understand this now. We have gone from a simple miscalculation to apparently doing everything wrong.
>> 
>> IIUC this API does not currently handle virtual threads correctly -i s that the case? If so I would like to see that fix factored out and done separately before this fix is done. Thanks.
>
>> Sorry really struggling to understand this now. We have gone from a simple miscalculation to apparently doing everything wrong. IIUC this API does not currently handle virtual threads correctly - is that the case? If so I would like to see that fix factored out and done separately before this fix is done. Thanks.
> 
> Thank you for the concern, David. But it is not clear what it is. Could you, please, explain a little bit?
> Why do you think the virtual threads are handled incorrectly?

@sspitsyn - When you get the chance, can you checkout these possible
changes for the objmonusage001 test?

https://github.com/openjdk/jdk/pull/17839

Summary of my test changes:
- extend the check() function to verify more of the jvmtiMonitorUsage fields
- add detailed comments at each of the verification points so it's clear what is being verified and why
- add a better summary for the overall test
- make it clear which output lines document failures

I've also made some temporary debugging changes that are only useful
while updating this test:
- temporarily use the "printdump" parameter to enable test output
- add a flag to verify the current JVMs bad jvmtiMonitorUsage fields so that the test can pass with an unmodified JVM
- add a flag to add a delay that helps check for a lack of races in the verification points

These proposed test changes help document how I think the GetObjectMonitorUsage API
is supposed to work on a simple test case.

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

PR Comment: https://git.openjdk.org/jdk/pull/17680#issuecomment-1942747157

From sgibbons at openjdk.org  Wed Feb 14 00:48:18 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Wed, 14 Feb 2024 00:48:18 GMT
Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v8]
In-Reply-To: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
Message-ID: <ZodY1FIPk3VAbz3nRKDmnKGHByEj_ygOBUR4SbG-6oo=.864cf3ec-9399-4411-ab7e-a92f9c90858f@github.com>

> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
> 
> 
> Benchmark	                                               Score		Latest		
> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
> StringIndexOf.success	                                9.186		9.713		1.057369911x
> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Remove gcc lib fn; reduce spacial cases to 10 from 32

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/3e58d0c2..827ca245

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

  Stats: 2624 lines in 4 files changed: 320 ins; 1981 del; 323 mod
  Patch: https://git.openjdk.org/jdk/pull/16753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16753/head:pull/16753

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

From dholmes at openjdk.org  Wed Feb 14 02:26:05 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 14 Feb 2024 02:26:05 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v4]
In-Reply-To: <dgTO2rNUQS0JvaHUtfifHa74B68HXzG0pC6dvT6QkKU=.b1930c72-90f6-4cb5-a070-35278d137a66@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <bKkHh3R39JCXKuQGrduWdZhJ9jstNA6xfUnJgPgbslE=.c1e27529-af8c-4707-9d24-473952502459@github.com>
 <5DPYtNaOL_44RemEpOUvNCJYISxC2bfUHakk7FVIj9k=.bd8baf61-bcf1-4c92-b31a-ef048e9dc64c@github.com>
 <dgTO2rNUQS0JvaHUtfifHa74B68HXzG0pC6dvT6QkKU=.b1930c72-90f6-4cb5-a070-35278d137a66@github.com>
Message-ID: <2iPk6kfykXqnv2hTa6GyvRTcI71om0C6X3Z0bZZMaOM=.1b6f9718-dc85-4b09-8cb1-5d53f1cb0a36@github.com>

On Tue, 13 Feb 2024 08:34:57 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage003.java line 33:
>> 
>>> 31:     final static int NUMBER_OF_ENTERER_THREADS = 4;
>>> 32:     final static int NUMBER_OF_WAITER_THREADS  = 4;
>>> 33:     final static int NUMBER_OF_THREADS = NUMBER_OF_ENTERER_THREADS + NUMBER_OF_WAITER_THREADS;
>> 
>> This testing is not sufficient. We have three states of interest:
>> - entering the monitor directly
>> - waiting in the monitor via Object.wait
>> - re-rentering the monitor after being notified (or timed-out or interrupted)
>> - we need to check all of these conditions in permutations covering zero and non-zero for each one, and then see that we get the correct counts back from JVM TI.
>
> Thank you for the comment, David.
> Now the test checks:
> - the threads waiting to enter the monitor are returned correctly with all permutations of threads waiting to be notified and threads waiting to re-enter the monitor
> Initially, there are 4 threads waiting to be notified and zero threads waiting to re-enter the monitor.
> They are notified one by with the subsequent checks, so all the pairs are checked `<re-enter,wait-for-notif>`: `<0,4>, <1,3>, <2,2>, <3,1>, <4,0>`
> 
> I'm not sure why do you think all permutations covering zero and non-zero for each one are needed.
> At least, it looks like an overkill to me. But if you still think it is really important then I can add cases with zero threads waiting to enter the monitor with the same permutations of threads waiting to be notified and threads re-entering the monitor.

If you don't check all the zero/non-zero permutations for the three counts of interest then you don't know that you are combining them the right way to give the two counts reported by the API.
Note that checking "all the pairs" is not really necessary as all non-zero values fall in the same equivalence class for testing purposes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1488795667

From dholmes at openjdk.org  Wed Feb 14 02:26:05 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 14 Feb 2024 02:26:05 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v5]
In-Reply-To: <EwIwVHOIpJbV6fpHsNuoepv90GjfdanfYZpctKgtJ80=.82eab452-6f0d-470d-8a55-07aaab0dbec8@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <EwIwVHOIpJbV6fpHsNuoepv90GjfdanfYZpctKgtJ80=.82eab452-6f0d-470d-8a55-07aaab0dbec8@github.com>
Message-ID: <jBV90lLy2RsDhx27JWiRQxQ4YWONm8d-l94zK0Zq0UM=.3a8bd3f7-1189-4b1a-a755-01ceb62ce328@github.com>

On Tue, 13 Feb 2024 07:11:18 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
>> The function returns the following structure:
>> 
>> 
>> typedef struct {
>>     jthread owner;
>>     jint entry_count;
>>     jint waiter_count;
>>     jthread* waiters;
>>     jint notify_waiter_count;
>>     jthread* notify_waiters;
>> } jvmtiMonitorUsage;
>> 
>> 
>> The following four fields are defined this way:
>> 
>> waiter_count  [jint] The number of threads waiting to own this monitor
>> waiters  [jthread*] The waiter_count waiting threads
>> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
>> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
>> 
>> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
>> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
>> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
>> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
>> This update makes it right.
>> 
>> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
>> 
>> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
>> 
>>   jvmti/GetObjectMonitorUsage/objmonusage001
>>   jvmti/GetObjectMonitorUsage/objmonusage003
>> 
>> 
>> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
>> 
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
>> 
>> 
>> 
>> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository.
>> 
>> Also, please see and review the related CSR:
>>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
>> 
>> The Release-Note is:
>> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage
>>  
>> Testing:
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn 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:
> 
>  - Merge
>  - review: fixed issues in get_object_monitor_usage; extended test coverage in objmonusage003
>  - Merge
>  - review: thread in notify waiter list can't be BLOCKED
>  - 8324677: Specification clarification needed for JVM TI GetObjectMonitorUsage

> Why do you think the virtual threads are handled incorrectly?

Sorry my mistake. The `thread_or_vthread` changes had me confused.

src/hotspot/share/runtime/threads.cpp line 1200:

> 1198:     if (pending == monitor ||
> 1199:         (waiting == monitor && JavaThreadStatus::BLOCKED_ON_MONITOR_ENTER ==
> 1200:          java_lang_Thread::get_thread_status(p->vthread_or_thread()))

This code seems extremely racy. Is there anything that is stopping the target thread from running while we attempt this inspection of the oop state? If it was waiting and was interrupted or timed-out then we could mistakenly think it was still pending entry to this monitor when in fact it is not.
It is also a shame that we have to reach up into the oop thread state to figure out if if it is blocked on re-entry ...

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

PR Review: https://git.openjdk.org/jdk/pull/17680#pullrequestreview-1879239973
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1488808389

From thartmann at openjdk.org  Wed Feb 14 06:09:10 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 14 Feb 2024 06:09:10 GMT
Subject: RFR: 8325449: [BACKOUT] use "dmb.ishst+dmb.ishld" for release barrier
Message-ID: <ij8CZ6ZTaMUtjKYYEsHJEYDrw3gaieYIMgBE5lTkSg0=.73b53a66-44c7-4fa2-af27-ea834ec9376d@github.com>

Clean backout of [JDK-8324186](https://bugs.openjdk.org/browse/JDK-8324186) which caused performance regressions with several benchmarks (see [JDK-8325449](https://bugs.openjdk.org/browse/JDK-8325449) and [JDK-8325269](https://bugs.openjdk.org/browse/JDK-8325269)). REDO work is tracked by [JDK-8325821](https://bugs.openjdk.org/browse/JDK-8325821).

Thanks,
Tobias

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

Commit messages:
 - Revert "8324186: Use "dmb.ishst+dmb.ishld" for release barrier"

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

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

From aboldtch at openjdk.org  Wed Feb 14 07:21:08 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 14 Feb 2024 07:21:08 GMT
Subject: RFR: 8319799: Recursive lightweight locking: x86 implementation
 [v19]
In-Reply-To: <0SII2Lg6tzQy1ovSuJR64oxgXvN2Sf5pWG3nofIpNk8=.2ee1da59-993e-445b-ae6c-6592800e33b4@github.com>
References: <ymgsUW7sq02C2r82WrLYof5Eb7BB5Lh8M-kGoHx_Zjg=.a5a76651-4931-489f-8ea1-158716614119@github.com>
 <0SII2Lg6tzQy1ovSuJR64oxgXvN2Sf5pWG3nofIpNk8=.2ee1da59-993e-445b-ae6c-6592800e33b4@github.com>
Message-ID: <0-qJdtEvmn28_aP05ME67cCqo7NqIzBo_Skw51Fyp3c=.a69deb64-b7a2-4196-a6bf-f8cec2995dcb@github.com>

On Tue, 13 Feb 2024 12:34:30 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Implements the x86 port of JDK-8319796.
>> 
>> There are two major parts for the port implementation. The C2 part, and the part shared by the interpreter, C1 and the native call wrapper.
>> 
>> The biggest change for both parts is that we check the lock stack first and if it is a recursive lightweight [un]lock and in that case simply pop/push and finish successfully.
>> 
>> Only if the recursive lightweight [un]lock fails does it look at the mark word. 
>> 
>> For the shared part if it is an unstructured exit, the monitor is inflated or the mark word transition fails it calls into the runtime.
>> 
>> The C2 operates under a few more assumptions, that the locking is structured and balanced. This means that some checks can be elided. 
>> 
>> First this means that in C2 unlock if the obj is not on the top of the lock stack, it must be inflated. And reversely if we reach the inflated C2 unlock the obj is not on the lock stack. This second property makes it possible to avoid reading the owner (and checking if it is anonymous). Instead it can either just do an un-contended unlock by writing null to the owner, or if contention happens, simply write the thread to the owner and jump to the runtime. 
>> 
>> The x86 C2 port also has some extra oddities. 
>> 
>> The mark word read is done early as it showed better scaling in hyper-threaded scenarios on certain intel hardware, and no noticeable downside on other tested x86 hardware. 
>> 
>> The fast path is written to avoid going through conditional branches. This in combination with keeping the ZF output correct, the code does some actions eagerly, decrementing the held monitor count, popping from the lock stack. And jumps to a code stub if a slow path is required which restores the thread local state to a correct state before jumping to the runtime.
>> 
>> The contended unlock was also moved to the code stub.
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix Merge

Things looks green after the runtime change integration and master merge.
Thanks for all the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/16607#issuecomment-1943202885

From aboldtch at openjdk.org  Wed Feb 14 07:21:08 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 14 Feb 2024 07:21:08 GMT
Subject: Integrated: 8319799: Recursive lightweight locking: x86 implementation
In-Reply-To: <ymgsUW7sq02C2r82WrLYof5Eb7BB5Lh8M-kGoHx_Zjg=.a5a76651-4931-489f-8ea1-158716614119@github.com>
References: <ymgsUW7sq02C2r82WrLYof5Eb7BB5Lh8M-kGoHx_Zjg=.a5a76651-4931-489f-8ea1-158716614119@github.com>
Message-ID: <zCKD30Odxkeh6yQnfd1wT2HlkrBKam4BpZWk5xPZIe8=.ed2398f5-e7a3-4cf0-abaa-de25fd7db4e6@github.com>

On Fri, 10 Nov 2023 12:59:27 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Implements the x86 port of JDK-8319796.
> 
> There are two major parts for the port implementation. The C2 part, and the part shared by the interpreter, C1 and the native call wrapper.
> 
> The biggest change for both parts is that we check the lock stack first and if it is a recursive lightweight [un]lock and in that case simply pop/push and finish successfully.
> 
> Only if the recursive lightweight [un]lock fails does it look at the mark word. 
> 
> For the shared part if it is an unstructured exit, the monitor is inflated or the mark word transition fails it calls into the runtime.
> 
> The C2 operates under a few more assumptions, that the locking is structured and balanced. This means that some checks can be elided. 
> 
> First this means that in C2 unlock if the obj is not on the top of the lock stack, it must be inflated. And reversely if we reach the inflated C2 unlock the obj is not on the lock stack. This second property makes it possible to avoid reading the owner (and checking if it is anonymous). Instead it can either just do an un-contended unlock by writing null to the owner, or if contention happens, simply write the thread to the owner and jump to the runtime. 
> 
> The x86 C2 port also has some extra oddities. 
> 
> The mark word read is done early as it showed better scaling in hyper-threaded scenarios on certain intel hardware, and no noticeable downside on other tested x86 hardware. 
> 
> The fast path is written to avoid going through conditional branches. This in combination with keeping the ZF output correct, the code does some actions eagerly, decrementing the held monitor count, popping from the lock stack. And jumps to a code stub if a slow path is required which restores the thread local state to a correct state before jumping to the runtime.
> 
> The contended unlock was also moved to the code stub.

This pull request has now been integrated.

Changeset: 7f6bb71e
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7f6bb71eb302e8388c959bdaa914b758a766d299
Stats:     587 lines in 13 files changed: 448 ins; 61 del; 78 mod

8319799: Recursive lightweight locking: x86 implementation

Co-authored-by: Stefan Karlsson <stefank at openjdk.org>
Co-authored-by: Erik ?sterlund <eosterlund at openjdk.org>
Reviewed-by: rkennke, coleenp, dcubed

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

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

From chagedorn at openjdk.org  Wed Feb 14 07:28:53 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 14 Feb 2024 07:28:53 GMT
Subject: RFR: 8325449: [BACKOUT] use "dmb.ishst+dmb.ishld" for release
 barrier
In-Reply-To: <ij8CZ6ZTaMUtjKYYEsHJEYDrw3gaieYIMgBE5lTkSg0=.73b53a66-44c7-4fa2-af27-ea834ec9376d@github.com>
References: <ij8CZ6ZTaMUtjKYYEsHJEYDrw3gaieYIMgBE5lTkSg0=.73b53a66-44c7-4fa2-af27-ea834ec9376d@github.com>
Message-ID: <GUnJ0L3RRByqTVOoVmZbMWaxTiXk8I-6GnmOjiyCGyk=.15758990-ee07-4f08-896f-84209909e754@github.com>

On Wed, 14 Feb 2024 06:03:40 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Clean backout of [JDK-8324186](https://bugs.openjdk.org/browse/JDK-8324186) which caused performance regressions with several benchmarks (see [JDK-8325449](https://bugs.openjdk.org/browse/JDK-8325449) and [JDK-8325269](https://bugs.openjdk.org/browse/JDK-8325269)). REDO work is tracked by [JDK-8325821](https://bugs.openjdk.org/browse/JDK-8325821).
> 
> Thanks,
> Tobias

Make sense, looks good!

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

Marked as reviewed by chagedorn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17841#pullrequestreview-1879552205

From thartmann at openjdk.org  Wed Feb 14 07:37:05 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 14 Feb 2024 07:37:05 GMT
Subject: RFR: 8325449: [BACKOUT] use "dmb.ishst+dmb.ishld" for release
 barrier
In-Reply-To: <ij8CZ6ZTaMUtjKYYEsHJEYDrw3gaieYIMgBE5lTkSg0=.73b53a66-44c7-4fa2-af27-ea834ec9376d@github.com>
References: <ij8CZ6ZTaMUtjKYYEsHJEYDrw3gaieYIMgBE5lTkSg0=.73b53a66-44c7-4fa2-af27-ea834ec9376d@github.com>
Message-ID: <SNMwfFj2NU2Sdm1QlYH4zroPuu7Zbhdt1qTIgCuAWEE=.d33f76f5-869d-4b36-b26a-853dfa76db45@github.com>

On Wed, 14 Feb 2024 06:03:40 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Clean backout of [JDK-8324186](https://bugs.openjdk.org/browse/JDK-8324186) which caused performance regressions with several benchmarks (see [JDK-8325449](https://bugs.openjdk.org/browse/JDK-8325449) and [JDK-8325269](https://bugs.openjdk.org/browse/JDK-8325269)). REDO work is tracked by [JDK-8325821](https://bugs.openjdk.org/browse/JDK-8325821).
> 
> Thanks,
> Tobias

Thanks, Christian!

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

PR Comment: https://git.openjdk.org/jdk/pull/17841#issuecomment-1943218479

From thartmann at openjdk.org  Wed Feb 14 07:37:06 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 14 Feb 2024 07:37:06 GMT
Subject: Integrated: 8325449: [BACKOUT] use "dmb.ishst+dmb.ishld" for release
 barrier
In-Reply-To: <ij8CZ6ZTaMUtjKYYEsHJEYDrw3gaieYIMgBE5lTkSg0=.73b53a66-44c7-4fa2-af27-ea834ec9376d@github.com>
References: <ij8CZ6ZTaMUtjKYYEsHJEYDrw3gaieYIMgBE5lTkSg0=.73b53a66-44c7-4fa2-af27-ea834ec9376d@github.com>
Message-ID: <TAZQC4DMv9cl9U5QrdgZ2SHF3Z-tvr0O437e6DUZahk=.23cfbf45-757b-4f9b-aac2-8c67a19fd06d@github.com>

On Wed, 14 Feb 2024 06:03:40 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Clean backout of [JDK-8324186](https://bugs.openjdk.org/browse/JDK-8324186) which caused performance regressions with several benchmarks (see [JDK-8325449](https://bugs.openjdk.org/browse/JDK-8325449) and [JDK-8325269](https://bugs.openjdk.org/browse/JDK-8325269)). REDO work is tracked by [JDK-8325821](https://bugs.openjdk.org/browse/JDK-8325821).
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: ea98de63
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ea98de63f7aa4b9d7f95bea267a43619c5ce449e
Stats:     108 lines in 5 files changed: 0 ins; 98 del; 10 mod

8325449: [BACKOUT] use "dmb.ishst+dmb.ishld" for release barrier

Reviewed-by: chagedorn

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

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

From aboldtch at openjdk.org  Wed Feb 14 07:38:19 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 14 Feb 2024 07:38:19 GMT
Subject: RFR: 8319801: Recursive lightweight locking: aarch64
 implementation [v18]
In-Reply-To: <AE1nsnyRCUHR970jjg4feUm5f6E1GPJvea0ooC6dCgI=.73fff610-c0f6-422a-a45d-88187b37b9a2@github.com>
References: <AE1nsnyRCUHR970jjg4feUm5f6E1GPJvea0ooC6dCgI=.73fff610-c0f6-422a-a45d-88187b37b9a2@github.com>
Message-ID: <eFORJQjB_kExiAVmFTfB4drGfdGwFOMfGiYfJ68JBsU=.f8d58584-d566-44a6-8352-9e702953fa0f@github.com>

> Implements the aarch64 port of JDK-8319796.
> 
> There are two major parts for the port implementation. The C2 part, and the part shared by the interpreter, C1 and the native call wrapper.
> 
> The biggest change for both parts is that we check the lock stack first and if it is a recursive lightweight [un]lock and in that case simply pop/push and finish successfully.
> 
> Only if the recursive lightweight [un]lock fails does it look at the mark word. 
> 
> For the shared part if it is an unstructured exit, the monitor is inflated or the mark word transition fails it calls into the runtime.
> 
> The C2 operates under a few more assumptions, that the locking is structured and balanced. This means that some checks can be elided. 
> 
> First this means that in C2 unlock if the obj is not on the top of the lock stack, it must be inflated. And reversely if we reach the inflated C2 unlock the obj is not on the lock stack. This second property makes it possible to avoid reading the owner (and checking if it is anonymous). Instead it can either just do an un-contended unlock by writing null to the owner, or if contention happens, simply write the thread to the owner and jump to the runtime. 
> 
> The aarch64 C2 port tries to avoid stronger memory semantics where ever possible. In C2 lock it first does a relaxed load of the mark word to check for inflation. Both lock and unlock uses a load/store exclusive register pair to transition the mark word.

Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:

  Add comment about slow label offset.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16608/files
  - new: https://git.openjdk.org/jdk/pull/16608/files/0eef1f46..0ac730fd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16608&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16608&range=16-17

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

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

From aboldtch at openjdk.org  Wed Feb 14 08:45:07 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 14 Feb 2024 08:45:07 GMT
Subject: RFR: 8319801: Recursive lightweight locking: aarch64
 implementation [v16]
In-Reply-To: <yMtyXpGAUu6rihQ81l6xXwXsSx3BCWD2nPnshE5VU5Y=.556278ed-64f6-477f-9366-b32f69b8b354@github.com>
References: <AE1nsnyRCUHR970jjg4feUm5f6E1GPJvea0ooC6dCgI=.73fff610-c0f6-422a-a45d-88187b37b9a2@github.com>
 <CSIkQw9NjfsFbuQ_P-gbX3iaKNQU5-YvGe6HWjRBkME=.ea80bc31-87b8-4299-a2dd-67497115c315@github.com>
 <yMtyXpGAUu6rihQ81l6xXwXsSx3BCWD2nPnshE5VU5Y=.556278ed-64f6-477f-9366-b32f69b8b354@github.com>
Message-ID: <GZqZJAr2sWJFv4nsTZr636rg6g44jEQ95X7uyTucQzY=.395124cd-fcf2-4dc3-bd29-db438e946991@github.com>

On Tue, 13 Feb 2024 12:33:17 GMT, Andrew Haley <aph 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 79 commits:
>> 
>>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8319801
>>  - Revert "Update src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp"
>>    
>>    This reverts commit 130cf4b7f5b37ecb9dda3ce07ed70c3da13b29b8.
>>  - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319801
>>  - Running out of LogTagSets, stick with monitorinflation
>>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8319797
>>  - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319801
>>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8319797
>>  - Fix assert comment
>>  - Update src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp
>>    
>>    Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>
>>  - Clarify the rscratch1 assert
>>  - ... and 69 more: https://git.openjdk.org/jdk/compare/c266800a...20e92608
>
> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 416:
> 
>> 414: 
>> 415:     // mark contains the tagged ObjectMonitor*.
>> 416:     const Register monitor = mark;
> 
> I wouldn't do this. Making `monitor` a register alias for `mark` is at best confusing and at worst dangerous. As a general rule, aliased register names have caused many bugs.

I have been trying to think of alternatives which improve this situation. 

Is it the fact that monitor alias mark, or any of the aliases used for the in-parameters that is confusing?
If it is the first do you see the following as a solution:
```c++
    const Register monitor = t1;
    const uintptr_t monitor_tag = markWord::monitor_value;

    // Untag the monitor.
    sub(monitor, mark, monitor_tag);

and for the lock case
```c++
    const Register tagged_monitor = t1;
    mov(tagged_monitor, mark); 

where the mov will emit no instruction as they are the same register.
(These two variants seem somewhat equivalent to me, but it was not clear from your comment if this is the issue)

If it is the second, I feel like the best compromise would to still alias register via named variables, but give them names that show their origin (so you do not need a language server or scroll/grep to get the contextual information). 
E.g.
```c++
    const Register t1_monitor = t1;
    const uintptr_t monitor_tag = markWord::monitor_value;

    // Untag the monitor.
    sub(t1_monitor, t1_mark, monitor_tag);


I would like to hear if I have misunderstood something and / or if you have another proposed solution to this issue.

This seem to be the final issue blocking integration.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16608#discussion_r1489106434

From ihse at openjdk.org  Wed Feb 14 09:48:06 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 14 Feb 2024 09:48:06 GMT
Subject: RFR: 8252136: Several methods in hotspot are missing "static" [v2]
In-Reply-To: <Q3erX6U9Da2519qpJINXRwbnQhOIIguE3A7DbApjUvE=.b85f3d69-5903-4f9b-8564-508dfca152b6@github.com>
References: <dleKPT17nKiOOWVZg8Jm9pMPiUFe6KfqSfR-gDQK63c=.fbc6290d-eec4-43e8-8970-9d773a115eb6@github.com>
 <Q3erX6U9Da2519qpJINXRwbnQhOIIguE3A7DbApjUvE=.b85f3d69-5903-4f9b-8564-508dfca152b6@github.com>
Message-ID: <XBRGo1k5DtHs-WyrB0P5yfvmDk-SR2zACD2rWNk52y0=.f1a83c0a-647a-4ae0-8beb-14b448a03d39@github.com>

On Mon, 12 Feb 2024 16:47:59 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revert spurious changes in non-modified file
>>  - Fix indentation issues
>
> The argument alignment is wonky after this patch. Could you go over the patch and fix that?

@stefank Is this version okay?

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

PR Comment: https://git.openjdk.org/jdk/pull/17806#issuecomment-1943403850

From eosterlund at openjdk.org  Wed Feb 14 10:04:11 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Wed, 14 Feb 2024 10:04:11 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v11]
In-Reply-To: <lDKB0lc74xsB7UiO1FhR99BaBhNjfVSaNCDdJ2U2tmU=.39ee614a-6515-4461-8291-ff058ad949f9@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <lDKB0lc74xsB7UiO1FhR99BaBhNjfVSaNCDdJ2U2tmU=.39ee614a-6515-4461-8291-ff058ad949f9@github.com>
Message-ID: <NnnthtoXkMtpwq80y1EnMjROIzKsn6WekqE04bf0NfE=.8fe9238b-95b6-4543-ba5a-0e463ef5fb26@github.com>

On Tue, 13 Feb 2024 09:15:28 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> ICStubs solve an atomicity problem when setting both the destination and data of an inline cache. Unfortunately, it also leads to occasional safepoint carpets when multiple threads need to ICRefill the stubs at the same time, and spurious GuaranteedSafepointInterval "Cleanup" safepoints every second. This patch changes inline caches to not change the data part at all during the nmethod life cycle, hence removing the need for ICStubs.
>> 
>> The new scheme is less stateful. Instead of adding and removing callsite metadata back and forth when transitioning inline cache states, it installs all state any shape of call will ever need at resolution time in a struct that I call CompiledICData. This reduces inline cache state changes to simply changing the destination of the call, and it doesn't really matter what state transitions to what other state.
>> 
>> With this patch, we get rid of ICStub and ICBuffer classes and the related ICRefill and almost all Cleanup safepoints in practice. It also makes the inline cache code much simpler.
>> 
>> I have tested the changes from tier1-7, and run through full aurora performance tests.
>
> Erik ?sterlund 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 'master' into 8310823_object_streaming
>  - Some comments
>  - Feedback from Dean and Thomas
>  - Update src/hotspot/share/code/compiledIC.hpp
>    
>    Co-authored-by: Thomas Schatzl <59967451+tschatzl at users.noreply.github.com>
>  - Update src/hotspot/share/runtime/sharedRuntime.cpp
>    
>    Co-authored-by: Thomas Schatzl <59967451+tschatzl at users.noreply.github.com>
>  - ARM32 fixes
>  - Add comment
>  - Deal with short far branches on AArch64
>  - Batch allocate and free CompiledICData
>  - JVMCI support
>  - ... and 9 more: https://git.openjdk.org/jdk/compare/62a4be03...29994286

Tier1-7 test results look good.

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

PR Comment: https://git.openjdk.org/jdk/pull/17495#issuecomment-1943430726

From magnus.ihse.bursie at oracle.com  Wed Feb 14 10:06:00 2024
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 14 Feb 2024 11:06:00 +0100
Subject: Hotspot symbol visibility
Message-ID: <645132e0-687e-4f04-9e49-f90131294367@oracle.com>

I am currently pursuing improved build functionality for static 
libraries. One of the issues with static libraries are name collisions, 
which led me back to an old discussion about which symbols are exported 
from Hotspot, and how this is achieved. A long discussion is available 
in JDK-8017234 [1], which was created in 2013 and has been on the back 
burner ever since, coming back to life every now and then.

There are basically two different problems here. They are both distinct 
and interrelated, and we likely need to solve both in tandem.

The first problem is how Hotspot should say which symbols (functions) 
that should be exported from libjvm.so. The historical, and still used, 
system is to have a mapfile. In the "new" (not so new anymore) build 
system, this was simplified to a list of function names in 
make/data/hotspot-symbols, from which a mapfile is built.

This is in contrast with how all other libraries in the JDK are built, 
and also with modern best practices. A better approach would be to 
annotate the functions that should be exported in the source code. In 
fact, such annotation already exists, even in Hotspot, as JNIEXPORT, but 
this is currently not used in the compilation of Hotspot.

The second problem is that in addition to these explicitly exported 
functions, we also export basically all other functions as well in 
Hotspot. (So currently we could basically just forgo this complicated 
machinery and just export everything by default...)

The reason for this seem somewhat unclear. The specifics are probably 
forever lost in the mists of time past, but the essential point is that 
these symbols are needed for SA to do it's job.

So what we do is that we list all symbols in hotspot after compiling 
(but before linking), and selects some (most, I think) of them using 
regexp patterns, and add these to the mapfile.

As long as we're doing this, we cannot stop using a mapfile, and we're 
stuck from progressing on point 1.

My takeaway from the discussions is that we are most likely exporting a 
way too broad set of symbols to SA. It seems likely that this set can be 
drastically cut down. Actually getting an understanding of exactly which 
symbols SA need seem like a very good first step.

So, is this a journey anyone would be interested in embarkering on? I 
will help as much as I can from a build PoV, but I have no clue 
whatsoever about what SA needs.

/Magnus

[1] https://bugs.openjdk.org/browse/JDK-8017234


From stefank at openjdk.org  Wed Feb 14 10:47:04 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 14 Feb 2024 10:47:04 GMT
Subject: RFR: 8252136: Several methods in hotspot are missing "static" [v2]
In-Reply-To: <DNbZYvbu-rsTnx4RpupnNa_2AJqiAmFjUPZlQndIdus=.1d180787-500b-4b49-b3ef-809babf19330@github.com>
References: <dleKPT17nKiOOWVZg8Jm9pMPiUFe6KfqSfR-gDQK63c=.fbc6290d-eec4-43e8-8970-9d773a115eb6@github.com>
 <DNbZYvbu-rsTnx4RpupnNa_2AJqiAmFjUPZlQndIdus=.1d180787-500b-4b49-b3ef-809babf19330@github.com>
Message-ID: <qiQWbAPXSfu8Rkj6urNnqLIbRqdbKnR3hP1qR304el4=.001e5ef9-f1e3-4bc2-a661-435700309210@github.com>

On Tue, 13 Feb 2024 11:05:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> There are several places in hotspot where an internal function should have been declared static, but isn't. 
>> 
>> These were discovered by trying to use the gcc option `-Wmissing-declarations` and the corresponding clang option `-Wmissing-prototypes`. These warnings check that a function either:
>> a) is declared static, or
>> b) has a declaration before its definition. 
>> 
>> The rationale of this is that functions are either internal to a compilation unit, or exported to be linked by some other compilation unit. In the former case, it should be marked static. In the latter case, it should be declared in a header file, which should be included by the implementation as well. If there is a discrepancy between the exported prototype and the implemented prototype, this will be discovered during compilation (instead of as a runtime error). Additionally, marking internal methods as static allows the compiler to make better optimization, like inlining.
>> 
>> This seem to be to be a sane assumption, and I think Hotspot (and the entire JDK) would increase code quality by turning on these warnings. The absolute majority of the code already adheres to these rules, but there are still some places that needs to be fixed.
>> 
>> This is the first part of addressing these issues, where all places that are trivially missing static are fixed.
>> 
>> I have discovered these by running with the warnings mentioned above turned on. I have filtered out those places were an export was obviously missing. The remaining warnings I have manually inspected. About 1/4 of them were *_init() functions (which are directly declared in `init.cpp`) and another 1/4 were documented as "use in debugger"; these I have not touched. I also ignored functions with names suggesting it might be used in the debugger, even if not documented as such, or any places that even seemed remotely non-trivial. Finally I also reverted a few changes after it turned out that gcc complained about unused functions. These places are actually dead code, but it is not clear if they should be removed or if there is actually a call missing somewhere (I believe it is a mix of both). In any case, I did not want any such complexities in this PR.
>> 
>> When the functions where marked static, gcc started complaining if they were not used, since it consider it dead code. To address this, I had to add or fix some `#ifdef`s. Since this code were not actually used unless these criteria were fulfilled before either (it was just not disc...
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert spurious changes in non-modified file
>  - Fix indentation issues

Marked as reviewed by stefank (Reviewer).

Yes, the GC code looks good. Thanks!

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

PR Review: https://git.openjdk.org/jdk/pull/17806#pullrequestreview-1879939402
PR Comment: https://git.openjdk.org/jdk/pull/17806#issuecomment-1943501692

From tschatzl at openjdk.org  Wed Feb 14 11:33:10 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 14 Feb 2024 11:33:10 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints [v11]
In-Reply-To: <lDKB0lc74xsB7UiO1FhR99BaBhNjfVSaNCDdJ2U2tmU=.39ee614a-6515-4461-8291-ff058ad949f9@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <lDKB0lc74xsB7UiO1FhR99BaBhNjfVSaNCDdJ2U2tmU=.39ee614a-6515-4461-8291-ff058ad949f9@github.com>
Message-ID: <QGer5OO1RoAhVolAd392ybwPubxHohW1NRrHsUEbTbY=.1b4dc09c-462a-4a1a-b29e-87993b4b687b@github.com>

On Tue, 13 Feb 2024 09:15:28 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> ICStubs solve an atomicity problem when setting both the destination and data of an inline cache. Unfortunately, it also leads to occasional safepoint carpets when multiple threads need to ICRefill the stubs at the same time, and spurious GuaranteedSafepointInterval "Cleanup" safepoints every second. This patch changes inline caches to not change the data part at all during the nmethod life cycle, hence removing the need for ICStubs.
>> 
>> The new scheme is less stateful. Instead of adding and removing callsite metadata back and forth when transitioning inline cache states, it installs all state any shape of call will ever need at resolution time in a struct that I call CompiledICData. This reduces inline cache state changes to simply changing the destination of the call, and it doesn't really matter what state transitions to what other state.
>> 
>> With this patch, we get rid of ICStub and ICBuffer classes and the related ICRefill and almost all Cleanup safepoints in practice. It also makes the inline cache code much simpler.
>> 
>> I have tested the changes from tier1-7, and run through full aurora performance tests.
>
> Erik ?sterlund 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 'master' into 8310823_object_streaming
>  - Some comments
>  - Feedback from Dean and Thomas
>  - Update src/hotspot/share/code/compiledIC.hpp
>    
>    Co-authored-by: Thomas Schatzl <59967451+tschatzl at users.noreply.github.com>
>  - Update src/hotspot/share/runtime/sharedRuntime.cpp
>    
>    Co-authored-by: Thomas Schatzl <59967451+tschatzl at users.noreply.github.com>
>  - ARM32 fixes
>  - Add comment
>  - Deal with short far branches on AArch64
>  - Batch allocate and free CompiledICData
>  - JVMCI support
>  - ... and 9 more: https://git.openjdk.org/jdk/compare/62a4be03...29994286

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17495#pullrequestreview-1880048712

From eosterlund at openjdk.org  Wed Feb 14 11:48:11 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Wed, 14 Feb 2024 11:48:11 GMT
Subject: RFR: 8322630: Remove ICStubs and related safepoints
In-Reply-To: <T0dapsqbm30AmWJZMOaXry-kaNOyq5IqiqPHV4gmvaE=.a6075c1f-df8e-4f8a-ba35-b723760a7342@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
 <9GolX3m7SkG4Fs0KTN5qMRxVK47eAhPLdmlaO3oGSKc=.736c3053-abc5-45ce-bd54-85c4f70c3fc9@github.com>
 <T0dapsqbm30AmWJZMOaXry-kaNOyq5IqiqPHV4gmvaE=.a6075c1f-df8e-4f8a-ba35-b723760a7342@github.com>
Message-ID: <bEvSk-Zq-4KuAu4dc1nKZnY3hL84fCGLpTOLs42FQbU=.8e7f58d3-c208-44bc-9e22-31258e6b38c0@github.com>

On Mon, 29 Jan 2024 09:38:52 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> On linux, the time for "Purge Unlinked NMethods" goes down when I comment out `delete ic->data();` and ignore the memory leak. (MacOS seems to be ok with it.)
>> Adding trace code to `purge_ic_callsites` shows that we often have 0 or 2 ICData instances, sometimes up to 30 ones.
>> It would be good to think a bit about the allocation scheme. Some ideas would be
>> 
>> - Allocate ICData in an array per nmethod instead of individually. That should help to some degree and also improve data locality (and hence cache efficiency). Would also save iterating over the relocations when purging unlinked NMethods. It's not very complex.
>> - Instead of freeing ICData instances, we could enqueue them and either reuse or free them during a concurrent phase. This may be a bit complicated. Not sure if it's worth it.
>> - Allocate in Metaspace?
>
>> On linux, the time for "Purge Unlinked NMethods" goes down when I comment out delete ic->data(); and ignore the memory leak. (MacOS seems to be ok with it.)
>>Adding trace code to purge_ic_callsites shows that we often have 0 or 2 ICData instances, sometimes up to 30 ones.
>>It would be good to think a bit about the allocation scheme. Some ideas would be
> 
>>    Allocate ICData in an array per nmethod instead of individually. That should help to some degree and also improve data locality (and hence cache efficiency). Would also save iterating over the relocations when purging unlinked NMethods. It's not very complex.
>>    Instead of freeing ICData instances, we could enqueue them and either reuse or free them during a concurrent phase. This may be a bit complicated. Not sure if it's worth it.
>>    Allocate in Metaspace?
> 
> Sorry for being unresponsive for a bit.
> 
> Yes, the issue is the new `delete ic->data()`; but also the iteration over the relocinfo here is almost as expensive in my tests.
> 
> So the idea to allocate ICData in a per nmethod basis (and actually some other existing C heap allocations that are also `delete`d in this phase) seems the most promising to me.
> 
> Also came up with the other suggestions, but I think that first one seems best to me at first glance. I did not really like the second because enqueuing adds another indirection for first gathering all of them and then separately free them.
> 
> Metaspace is something I do not know that well to comment on that option.
> 
> I am open to moving this improvement, if it is not easy to do, into a separate CR.

Thanks for the review @tschatzl!

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

PR Comment: https://git.openjdk.org/jdk/pull/17495#issuecomment-1943609432

From eosterlund at openjdk.org  Wed Feb 14 11:48:12 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Wed, 14 Feb 2024 11:48:12 GMT
Subject: Integrated: 8322630: Remove ICStubs and related safepoints
In-Reply-To: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
References: <fBgJL9x-xOMJrtJsW0yPPeLWWj0OxJRoHS048kdtLF0=.0c09d267-c0ae-40d8-a186-1843228ba9c8@github.com>
Message-ID: <CmaZth2zrhfaSnh-hjfSHEgsghs7g5M2FaJrUojfphY=.3578de14-4eca-44ec-a856-0ff60a3ec555@github.com>

On Fri, 19 Jan 2024 06:25:20 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> ICStubs solve an atomicity problem when setting both the destination and data of an inline cache. Unfortunately, it also leads to occasional safepoint carpets when multiple threads need to ICRefill the stubs at the same time, and spurious GuaranteedSafepointInterval "Cleanup" safepoints every second. This patch changes inline caches to not change the data part at all during the nmethod life cycle, hence removing the need for ICStubs.
> 
> The new scheme is less stateful. Instead of adding and removing callsite metadata back and forth when transitioning inline cache states, it installs all state any shape of call will ever need at resolution time in a struct that I call CompiledICData. This reduces inline cache state changes to simply changing the destination of the call, and it doesn't really matter what state transitions to what other state.
> 
> With this patch, we get rid of ICStub and ICBuffer classes and the related ICRefill and almost all Cleanup safepoints in practice. It also makes the inline cache code much simpler.
> 
> I have tested the changes from tier1-7, and run through full aurora performance tests.

This pull request has now been integrated.

Changeset: 84965ea1
Author:    Erik ?sterlund <eosterlund at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/84965ea1a86703818410f11c8d284e4b824817dd
Stats:     4253 lines in 142 files changed: 501 ins; 3226 del; 526 mod

8322630: Remove ICStubs and related safepoints

Co-authored-by: Martin Doerr <mdoerr at openjdk.org>
Co-authored-by: Aleksey Shipilev <shade at openjdk.org>
Co-authored-by: Amit Kumar <amitkumar at openjdk.org>
Co-authored-by: Robbin Ehn <rehn at openjdk.org>
Co-authored-by: Aleksei Voitylov <avoitylov at openjdk.org>
Reviewed-by: tschatzl, aboldtch, dlong

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

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

From sspitsyn at openjdk.org  Wed Feb 14 11:59:10 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 14 Feb 2024 11:59:10 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v6]
In-Reply-To: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
Message-ID: <WWKuMPXazFiKC_OB7JQ31cKzZtS-IRjFna1RXPTDeZo=.551d6b89-ddbd-4bee-9780-25459e5775d5@github.com>

> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
> The function returns the following structure:
> 
> 
> typedef struct {
>     jthread owner;
>     jint entry_count;
>     jint waiter_count;
>     jthread* waiters;
>     jint notify_waiter_count;
>     jthread* notify_waiters;
> } jvmtiMonitorUsage;
> 
> 
> The following four fields are defined this way:
> 
> waiter_count  [jint] The number of threads waiting to own this monitor
> waiters  [jthread*] The waiter_count waiting threads
> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
> 
> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
> This update makes it right.
> 
> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
> 
> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
> 
>   jvmti/GetObjectMonitorUsage/objmonusage001
>   jvmti/GetObjectMonitorUsage/objmonusage003
> 
> 
> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
> 
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
> 
> 
> 
> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository.
> 
> Also, please see and review the related CSR:
>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
> 
> The Release-Note is:
> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage
>  
> Testing:
>  - tested with mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: imported the suggestion extending the nsk/jvmti  test objmonusage001

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17680/files
  - new: https://git.openjdk.org/jdk/pull/17680/files/182cd07c..070b15d1

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

  Stats: 133 lines in 3 files changed: 118 ins; 0 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/17680.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17680/head:pull/17680

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

From sspitsyn at openjdk.org  Wed Feb 14 11:59:10 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 14 Feb 2024 11:59:10 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v4]
In-Reply-To: <dDiWEBRVCO6Jd5BrbOdhYKgDf1YFkMPvIHA1WLKcZ_c=.d64f726e-c131-4db2-aa3d-0a3da5f274f6@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <bKkHh3R39JCXKuQGrduWdZhJ9jstNA6xfUnJgPgbslE=.c1e27529-af8c-4707-9d24-473952502459@github.com>
 <5DPYtNaOL_44RemEpOUvNCJYISxC2bfUHakk7FVIj9k=.bd8baf61-bcf1-4c92-b31a-ef048e9dc64c@github.com>
 <FyUzHquSAC2WSUI0da52uhn7JQtJEsZiOGNWB9cEiIk=.0653f836-b00d-4b48-964a-cd8b6e0cb7aa@github.com>
 <dDiWEBRVCO6Jd5BrbOdhYKgDf1YFkMPvIHA1WLKcZ_c=.d64f726e-c131-4db2-aa3d-0a3da5f274f6@github.com>
Message-ID: <GJelJwYje5lVWNf-wcINBhLvnCIDk6cxCzuv6SQkzg0=.8f6457fa-9f9f-4fd9-b104-2a460bd69037@github.com>

On Tue, 13 Feb 2024 22:30:56 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> When you get the chance, can you checkout these possible
changes for the objmonusage001 test?

Thanks, Dan. I've pushed the suggested test changes but refactored them a little bit.

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

PR Comment: https://git.openjdk.org/jdk/pull/17680#issuecomment-1943626874

From sspitsyn at openjdk.org  Wed Feb 14 12:03:09 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 14 Feb 2024 12:03:09 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v7]
In-Reply-To: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
Message-ID: <dx48UA38-S0BiAXSpiJEnqberOsYQ330QJ1Jok_KP7Y=.c01c83f7-0d76-4cb3-b072-fa2e62b89171@github.com>

> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
> The function returns the following structure:
> 
> 
> typedef struct {
>     jthread owner;
>     jint entry_count;
>     jint waiter_count;
>     jthread* waiters;
>     jint notify_waiter_count;
>     jthread* notify_waiters;
> } jvmtiMonitorUsage;
> 
> 
> The following four fields are defined this way:
> 
> waiter_count  [jint] The number of threads waiting to own this monitor
> waiters  [jthread*] The waiter_count waiting threads
> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
> 
> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
> This update makes it right.
> 
> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
> 
> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
> 
>   jvmti/GetObjectMonitorUsage/objmonusage001
>   jvmti/GetObjectMonitorUsage/objmonusage003
> 
> 
> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
> 
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
> 
> 
> 
> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository.
> 
> Also, please see and review the related CSR:
>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
> 
> The Release-Note is:
> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage
>  
> Testing:
>  - tested with mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  fixed trailing spaces in one line

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17680/files
  - new: https://git.openjdk.org/jdk/pull/17680/files/070b15d1..674da98c

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

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

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

From sspitsyn at openjdk.org  Wed Feb 14 12:19:05 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 14 Feb 2024 12:19:05 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v5]
In-Reply-To: <jBV90lLy2RsDhx27JWiRQxQ4YWONm8d-l94zK0Zq0UM=.3a8bd3f7-1189-4b1a-a755-01ceb62ce328@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <EwIwVHOIpJbV6fpHsNuoepv90GjfdanfYZpctKgtJ80=.82eab452-6f0d-470d-8a55-07aaab0dbec8@github.com>
 <jBV90lLy2RsDhx27JWiRQxQ4YWONm8d-l94zK0Zq0UM=.3a8bd3f7-1189-4b1a-a755-01ceb62ce328@github.com>
Message-ID: <dVaq7wekOcAHZqMOBX0vYYfqrctHh0aN7mVcNlSUvP8=.ab3c9632-9b13-4310-8aa6-b772519d6b16@github.com>

On Wed, 14 Feb 2024 02:18:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Serguei Spitsyn 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:
>> 
>>  - Merge
>>  - review: fixed issues in get_object_monitor_usage; extended test coverage in objmonusage003
>>  - Merge
>>  - review: thread in notify waiter list can't be BLOCKED
>>  - 8324677: Specification clarification needed for JVM TI GetObjectMonitorUsage
>
> src/hotspot/share/runtime/threads.cpp line 1200:
> 
>> 1198:     if (pending == monitor ||
>> 1199:         (waiting == monitor && JavaThreadStatus::BLOCKED_ON_MONITOR_ENTER ==
>> 1200:          java_lang_Thread::get_thread_status(p->vthread_or_thread()))
> 
> This code seems extremely racy. Is there anything that is stopping the target thread from running while we attempt this inspection of the oop state? If it was waiting and was interrupted or timed-out then we could mistakenly think it was still pending entry to this monitor when in fact it is not.
> It is also a shame that we have to reach up into the oop thread state to figure out if if it is blocked on re-entry ...

The function `get_pending_threads()` is executed only by the VM_GetObjectMonitorUsage operation.
I've added this assert there: 
    `assert(Thread::current()->is_VM_thread(), "Must be the VM thread");`
Does it address your concern?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1489379382

From tschatzl at openjdk.org  Wed Feb 14 12:24:03 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 14 Feb 2024 12:24:03 GMT
Subject: RFR: 8324933: ConcurrentHashTable::statistics_calculate
 synchronization is expensive [v3]
In-Reply-To: <LW8jCueDdE8uzFV7QPseNJbhrIsLdp39lwtJDEplD3s=.d437bc80-1b34-44a4-a1ce-723fe53703c1@github.com>
References: <BWI_sYMoH8SOp_kpYvkmFrHcBP38G_sMW4_LJR_8Ev0=.ffc95dc6-b110-4c22-ac32-6eaa10c7a6c1@github.com>
 <LW8jCueDdE8uzFV7QPseNJbhrIsLdp39lwtJDEplD3s=.d437bc80-1b34-44a4-a1ce-723fe53703c1@github.com>
Message-ID: <ySRZJV3AJuBnOfm0vfzSJcudappAS1j_ASnRMMqfmrg=.145ef80f-4fdc-4794-8a88-658a8aaad221@github.com>

On Tue, 13 Feb 2024 15:22:16 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> In the ConcurrentHashTable::statistics_calculate function, we enter and exit a ScopedCS with the global counter for every single bucket. This has showed up to be pretty intense on some machines. We should make the synchronization a bit less intense here. This patch adds simple batching so we synchronize once per 128 buckets instead of every single one.
>
> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Build fix

lgtm. A comment why we need to do the batched iteration (without looking at versioning system logs) would be nice.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17629#pullrequestreview-1880141210

From duke at openjdk.org  Wed Feb 14 12:51:05 2024
From: duke at openjdk.org (Lei Zaakjyu)
Date: Wed, 14 Feb 2024 12:51:05 GMT
Subject: RFR: 8325082: Rename headers named 'heapRegion*' of G1 [v3]
In-Reply-To: <1MWMgluBwGY-FydUnpoksJ0q5sSvptrNMv6xwDszBQc=.a78cadad-1585-44d1-97d0-a7928fe34d67@github.com>
References: <1MWMgluBwGY-FydUnpoksJ0q5sSvptrNMv6xwDszBQc=.a78cadad-1585-44d1-97d0-a7928fe34d67@github.com>
Message-ID: <p9f42d634nvSGvduMCBA3FUTq1V9ZIPUstJ8IpeuyWg=.6693e68b-0060-4f23-af4d-691dca3b94bb@github.com>

> 8325082: Rename headers named 'heapRegion*' of G1

Lei Zaakjyu has updated the pull request incrementally with one additional commit since the last revision:

  fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17666/files
  - new: https://git.openjdk.org/jdk/pull/17666/files/7d105a58..d65b6597

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

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

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

From sgibbons at openjdk.org  Wed Feb 14 14:34:07 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Wed, 14 Feb 2024 14:34:07 GMT
Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v8]
In-Reply-To: <ZodY1FIPk3VAbz3nRKDmnKGHByEj_ygOBUR4SbG-6oo=.864cf3ec-9399-4411-ab7e-a92f9c90858f@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <ZodY1FIPk3VAbz3nRKDmnKGHByEj_ygOBUR4SbG-6oo=.864cf3ec-9399-4411-ab7e-a92f9c90858f@github.com>
Message-ID: <vKgvRTfvDCx3oNJSnKNGqV0WtroCRPiEP3hEdHp1oek=.b4b5b97d-4233-48d3-9cf2-e75176ed36ca@github.com>

On Wed, 14 Feb 2024 00:48:18 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
>> 
>> 
>> Benchmark	                                               Score		Latest		
>> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
>> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
>> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
>> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
>> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
>> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
>> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
>> StringIndexOf.success	                                9.186		9.713		1.057369911x
>> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
>> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
>> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
>> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
>> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
>> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
>> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
>> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
>> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove gcc lib fn; reduce spacial cases to 10 from 32

Thank you all for the reviews.  I have been asked to simplify this code to facilitate easier review, and to remove the gcc library code I used for memcmp.  We also discovered that special-casing up to 31 bytes of needle was not necessary to get the performance gain.  I will be commenting the code and fixing the single build failure soon.

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

PR Comment: https://git.openjdk.org/jdk/pull/16753#issuecomment-1943904829

From eosterlund at openjdk.org  Wed Feb 14 15:05:30 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Wed, 14 Feb 2024 15:05:30 GMT
Subject: RFR: 8324933: ConcurrentHashTable::statistics_calculate
 synchronization is expensive [v3]
In-Reply-To: <ZmcThsGuqFE6syvpOmj03fAnZOk9lSZlMXGQnFOoYvI=.a481d80f-002c-4680-98a5-767dea8dbf97@github.com>
References: <BWI_sYMoH8SOp_kpYvkmFrHcBP38G_sMW4_LJR_8Ev0=.ffc95dc6-b110-4c22-ac32-6eaa10c7a6c1@github.com>
 <LW8jCueDdE8uzFV7QPseNJbhrIsLdp39lwtJDEplD3s=.d437bc80-1b34-44a4-a1ce-723fe53703c1@github.com>
 <ZmcThsGuqFE6syvpOmj03fAnZOk9lSZlMXGQnFOoYvI=.a481d80f-002c-4680-98a5-767dea8dbf97@github.com>
Message-ID: <yMhH_e66N59BW7Z7KyKUWY8VUU7v6hGWWAWFHKhCAYw=.b0521b7d-c28a-429d-b91d-2b315bea5901@github.com>

On Tue, 13 Feb 2024 15:52:13 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Build fix
>
> This seems reasonable, as long as the critical section is held throughout a bucket iteration.

Thanks for the reviews, @coleenp and @tschatzl! I will add a comment before integrating.

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

PR Comment: https://git.openjdk.org/jdk/pull/17629#issuecomment-1944002055

From eosterlund at openjdk.org  Wed Feb 14 15:05:30 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Wed, 14 Feb 2024 15:05:30 GMT
Subject: RFR: 8324933: ConcurrentHashTable::statistics_calculate
 synchronization is expensive [v4]
In-Reply-To: <BWI_sYMoH8SOp_kpYvkmFrHcBP38G_sMW4_LJR_8Ev0=.ffc95dc6-b110-4c22-ac32-6eaa10c7a6c1@github.com>
References: <BWI_sYMoH8SOp_kpYvkmFrHcBP38G_sMW4_LJR_8Ev0=.ffc95dc6-b110-4c22-ac32-6eaa10c7a6c1@github.com>
Message-ID: <lNbUjuj0z1-mJ-IDt2ONlvqFhiNctpJ67Q5CKYiUqGs=.5905b439-4ba6-4de5-a5e5-19413372d629@github.com>

> In the ConcurrentHashTable::statistics_calculate function, we enter and exit a ScopedCS with the global counter for every single bucket. This has showed up to be pretty intense on some machines. We should make the synchronization a bit less intense here. This patch adds simple batching so we synchronize once per 128 buckets instead of every single one.

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

  Comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17629/files
  - new: https://git.openjdk.org/jdk/pull/17629/files/3b26cf9c..cb71f9c8

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

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

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

From sspitsyn at openjdk.org  Wed Feb 14 15:25:33 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 14 Feb 2024 15:25:33 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v8]
In-Reply-To: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
Message-ID: <i4ilc2XEworX6I0J0trCxtd9jqZ4Q7SERhG0WJyRtl0=.cce47aa4-5833-4af0-a795-85701f346973@github.com>

> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
> The function returns the following structure:
> 
> 
> typedef struct {
>     jthread owner;
>     jint entry_count;
>     jint waiter_count;
>     jthread* waiters;
>     jint notify_waiter_count;
>     jthread* notify_waiters;
> } jvmtiMonitorUsage;
> 
> 
> The following four fields are defined this way:
> 
> waiter_count  [jint] The number of threads waiting to own this monitor
> waiters  [jthread*] The waiter_count waiting threads
> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
> 
> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
> This update makes it right.
> 
> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
> 
> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
> 
>   jvmti/GetObjectMonitorUsage/objmonusage001
>   jvmti/GetObjectMonitorUsage/objmonusage003
> 
> 
> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
> 
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
> 
> 
> 
> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository.
> 
> Also, please see and review the related CSR:
>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
> 
> The Release-Note is:
> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage
>  
> Testing:
>  - tested with mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: added assert to get_pending_threads; added suggested coverage to test objmonusage003

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17680/files
  - new: https://git.openjdk.org/jdk/pull/17680/files/674da98c..1ab5b349

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

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

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

From sspitsyn at openjdk.org  Wed Feb 14 15:25:35 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 14 Feb 2024 15:25:35 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v3]
In-Reply-To: <G0pqYyJ_-DfljxP29xptnPh5n76msoUpITc8kXDPrNo=.72e64c5e-2200-4bc7-8e67-632c318f7d25@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <bIMfwFEuiZ1CbUtq3NzEeNuW72i4jAqAHGJKMb_VZdg=.4e228b57-af29-4a78-9534-bae11fa6bb2d@github.com>
 <G0pqYyJ_-DfljxP29xptnPh5n76msoUpITc8kXDPrNo=.72e64c5e-2200-4bc7-8e67-632c318f7d25@github.com>
Message-ID: <CSDIB_KV6SPYiM8xOPeV7yfv_UAy1WAhAsFd1IH6BSg=.a19b8e75-6ecc-4830-b02e-a2bd8023178a@github.com>

On Thu, 8 Feb 2024 07:05:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Serguei Spitsyn 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
>>  - review: thread in notify waiter list can't be BLOCKED
>>  - 8324677: Specification clarification needed for JVM TI GetObjectMonitorUsage
>
> Based on Dan's analysis I would have to go back and redo the complete analysis for myself. :( I think the only way to make sense of this is to actually set up scenarios where we have different threads contending on entry, different threads waiting and different threads re-entering after being notified, and see what values actually get returned in each case.
> 
> I think the `pending_current_monitor` issue may be a distinct/different issue. I can easily imagine that this was overlooked when we introduced the "wait morphing" rather than have the notified/timed-out/interrupted waiters actually place themselves on the entry queue.

>From @dholmes-ora :
> If you don't check all the zero/non-zero permutations for the three counts of interest then you don't know that you are combining them the right way to give the two counts reported by the API.

Okay, thanks. I've added the suggested test cases to the `nsk/jvmti/GetObjectMonitorUsage/objmonusage003`.
One of the testcases is covered by the `nsk/jvmti/GetObjectMonitorUsage/objmonusage001`.

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

PR Comment: https://git.openjdk.org/jdk/pull/17680#issuecomment-1944052748

From kbarrett at openjdk.org  Wed Feb 14 16:03:08 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 14 Feb 2024 16:03:08 GMT
Subject: RFR: 8314488: Compile the JDK as C++17 [v6]
In-Reply-To: <bhrcRriVPrMI3BZd4M7MBIeFeF4vKhBbLVxbe0vfKPc=.c089032b-7420-4224-8186-d7d6e721856b@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
 <b4HhbT5caIfCbrVveI6NDObiwUI2Sr0so68JBG6C0YU=.1734aaa7-aed4-478c-bbb6-de9af5c04ef9@github.com>
 <bhrcRriVPrMI3BZd4M7MBIeFeF4vKhBbLVxbe0vfKPc=.c089032b-7420-4224-8186-d7d6e721856b@github.com>
Message-ID: <Kf3TPcBiwoF4IKXQSdVu8fPrmy_AUe6japArSVzHHGw=.ac49ae36-aa56-4590-ba46-e195b03445d1@github.com>

On Fri, 19 Jan 2024 14:04:50 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Well, the only additional thing this PR does except raise the compiler version is to change the `--std` flag. It is a bit unclear what that means. For the JDK libraries, there are already code present that relies on C++17. For hotspot, what C++ constructions to use is strictly limited by the code standard document. As long as it does not mention any C++17 constructs, it does not really matter what the `--std` flag says. But, otoh, to be able to say something about C++17, we need first have proper support from all compilers.
> 
> So I'd say just chill a bit, give folks some time to respond. My understanding of the situation is as follows:
> 
>     * Raising clang to 13.0 is uncontroversial
> 
>     * Raising xlc to 17.1.1.4 seems acceptable by the folks using it (I hope I got that right)
> 
>     * Raising gcc to 10.0 met some resistance. We could stop at gcc 9.0 for this PR (which is enough for C++17), and then continue discussing going to gcc 10.0 in a separate PR, or we can wait a bit more to see if @shipilev feels compelled by the arguments given in the discussion to accept going to 10.

I'd like to separate the version update discussions from C++17 specifics, so
we can have focused discussions on the version choices. Of course, that's
going to be informed by the possibility of C++17, but that's not the only
factor. That way this issue can be just about turning on C++17, when, and why.

In order to do that, I've filed the following issues about version updates:
https://bugs.openjdk.org/browse/JDK-8325881
Require minimum gcc version 10

https://bugs.openjdk.org/browse/JDK-8325878
Require minimum clang version 13

https://bugs.openjdk.org/browse/JDK-8325880
Require minimum OpenXL C/C++ version 17.1.1

PRs will follow shortly.

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

PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1944126546

From kbarrett at openjdk.org  Wed Feb 14 16:07:15 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 14 Feb 2024 16:07:15 GMT
Subject: RFR: 8252136: Several methods in hotspot are missing "static" [v2]
In-Reply-To: <DNbZYvbu-rsTnx4RpupnNa_2AJqiAmFjUPZlQndIdus=.1d180787-500b-4b49-b3ef-809babf19330@github.com>
References: <dleKPT17nKiOOWVZg8Jm9pMPiUFe6KfqSfR-gDQK63c=.fbc6290d-eec4-43e8-8970-9d773a115eb6@github.com>
 <DNbZYvbu-rsTnx4RpupnNa_2AJqiAmFjUPZlQndIdus=.1d180787-500b-4b49-b3ef-809babf19330@github.com>
Message-ID: <MBsH4DzvhK3ZtvDlmvWhgmY80Qa_pt3YjG8MZHgbtak=.9c86053b-1532-4315-b418-12b41c72d624@github.com>

On Tue, 13 Feb 2024 11:05:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> There are several places in hotspot where an internal function should have been declared static, but isn't. 
>> 
>> These were discovered by trying to use the gcc option `-Wmissing-declarations` and the corresponding clang option `-Wmissing-prototypes`. These warnings check that a function either:
>> a) is declared static, or
>> b) has a declaration before its definition. 
>> 
>> The rationale of this is that functions are either internal to a compilation unit, or exported to be linked by some other compilation unit. In the former case, it should be marked static. In the latter case, it should be declared in a header file, which should be included by the implementation as well. If there is a discrepancy between the exported prototype and the implemented prototype, this will be discovered during compilation (instead of as a runtime error). Additionally, marking internal methods as static allows the compiler to make better optimization, like inlining.
>> 
>> This seem to be to be a sane assumption, and I think Hotspot (and the entire JDK) would increase code quality by turning on these warnings. The absolute majority of the code already adheres to these rules, but there are still some places that needs to be fixed.
>> 
>> This is the first part of addressing these issues, where all places that are trivially missing static are fixed.
>> 
>> I have discovered these by running with the warnings mentioned above turned on. I have filtered out those places were an export was obviously missing. The remaining warnings I have manually inspected. About 1/4 of them were *_init() functions (which are directly declared in `init.cpp`) and another 1/4 were documented as "use in debugger"; these I have not touched. I also ignored functions with names suggesting it might be used in the debugger, even if not documented as such, or any places that even seemed remotely non-trivial. Finally I also reverted a few changes after it turned out that gcc complained about unused functions. These places are actually dead code, but it is not clear if they should be removed or if there is actually a call missing somewhere (I believe it is a mix of both). In any case, I did not want any such complexities in this PR.
>> 
>> When the functions where marked static, gcc started complaining if they were not used, since it consider it dead code. To address this, I had to add or fix some `#ifdef`s. Since this code were not actually used unless these criteria were fulfilled before either (it was just not disc...
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert spurious changes in non-modified file
>  - Fix indentation issues

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17806#pullrequestreview-1880692930

From ihse at openjdk.org  Wed Feb 14 16:32:59 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 14 Feb 2024 16:32:59 GMT
Subject: Integrated: 8252136: Several methods in hotspot are missing "static"
In-Reply-To: <dleKPT17nKiOOWVZg8Jm9pMPiUFe6KfqSfR-gDQK63c=.fbc6290d-eec4-43e8-8970-9d773a115eb6@github.com>
References: <dleKPT17nKiOOWVZg8Jm9pMPiUFe6KfqSfR-gDQK63c=.fbc6290d-eec4-43e8-8970-9d773a115eb6@github.com>
Message-ID: <dJq6bvScEFeFqQ_bbswbK6PnsBfHP7a0FzPwZGUWJgA=.24183714-60be-4920-abd3-80ac3cd8197e@github.com>

On Mon, 12 Feb 2024 12:43:09 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> There are several places in hotspot where an internal function should have been declared static, but isn't. 
> 
> These were discovered by trying to use the gcc option `-Wmissing-declarations` and the corresponding clang option `-Wmissing-prototypes`. These warnings check that a function either:
> a) is declared static, or
> b) has a declaration before its definition. 
> 
> The rationale of this is that functions are either internal to a compilation unit, or exported to be linked by some other compilation unit. In the former case, it should be marked static. In the latter case, it should be declared in a header file, which should be included by the implementation as well. If there is a discrepancy between the exported prototype and the implemented prototype, this will be discovered during compilation (instead of as a runtime error). Additionally, marking internal methods as static allows the compiler to make better optimization, like inlining.
> 
> This seem to be to be a sane assumption, and I think Hotspot (and the entire JDK) would increase code quality by turning on these warnings. The absolute majority of the code already adheres to these rules, but there are still some places that needs to be fixed.
> 
> This is the first part of addressing these issues, where all places that are trivially missing static are fixed.
> 
> I have discovered these by running with the warnings mentioned above turned on. I have filtered out those places were an export was obviously missing. The remaining warnings I have manually inspected. About 1/4 of them were *_init() functions (which are directly declared in `init.cpp`) and another 1/4 were documented as "use in debugger"; these I have not touched. I also ignored functions with names suggesting it might be used in the debugger, even if not documented as such, or any places that even seemed remotely non-trivial. Finally I also reverted a few changes after it turned out that gcc complained about unused functions. These places are actually dead code, but it is not clear if they should be removed or if there is actually a call missing somewhere (I believe it is a mix of both). In any case, I did not want any such complexities in this PR.
> 
> When the functions where marked static, gcc started complaining if they were not used, since it consider it dead code. To address this, I had to add or fix some `#ifdef`s. Since this code were not actually used unless these criteria were fulfilled before either (it was just not discovered by the compiler), I thi...

This pull request has now been integrated.

Changeset: 09d49366
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/09d4936657a0bdc122a4ab80735bd9c8c109839c
Stats:     228 lines in 71 files changed: 8 ins; 1 del; 219 mod

8252136: Several methods in hotspot are missing "static"

Reviewed-by: coleenp, stefank, kvn, kbarrett

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

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

From sgibbons at openjdk.org  Wed Feb 14 17:41:30 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Wed, 14 Feb 2024 17:41:30 GMT
Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v9]
In-Reply-To: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
Message-ID: <nGFjU1cDunvU2hjYflZNW3S4bARCDCbc_IBwKNcJV2Q=.9cebca18-ff57-40b1-8b90-7af860102213@github.com>

> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
> 
> 
> Benchmark	                                               Score		Latest		
> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
> StringIndexOf.success	                                9.186		9.713		1.057369911x
> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Move arrays_equals to MacroAssembler_x86.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/827ca245..e3e91953

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

  Stats: 736 lines in 8 files changed: 269 ins; 243 del; 224 mod
  Patch: https://git.openjdk.org/jdk/pull/16753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16753/head:pull/16753

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

From bkilambi at openjdk.org  Wed Feb 14 17:46:05 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Wed, 14 Feb 2024 17:46:05 GMT
Subject: RFR: JDK-8325264: two compiler/intrinsics/float16 tests fail after
 JDK-8324724 [v2]
In-Reply-To: <TkBjh2Lrhg2yU5YoAXg6HO0TsJE3uoxYFNAKPWZPQ_w=.8ddc411b-8dd8-4ce8-9992-5b55d4075045@github.com>
References: <eoR3U5uw7lee-9UJA2qwsyF9u89D_vW83xykuszAMcU=.f70552a1-d96a-4895-99ac-33dfd0942de2@github.com>
 <M0rTewgJ5HXWlAysDqYk-KiFyZzmweHXLGR_0nfGlTA=.4e0bff92-5547-4e0f-9cc1-6a0f4de24d52@github.com>
 <d6aCSQ6ivkgfAQ5pnSNXHIOlZz6GtIiski002-T3cus=.ec07eee9-0712-4bc4-a79a-fdb2ee371f89@github.com>
 <cTz7hj1-Fla4UhtOdC-UuPvWYckBKJ8MlljpQeM74jo=.28cfdcc6-6c9b-4a01-83b0-c10424dbbd09@github.com>
 <TkBjh2Lrhg2yU5YoAXg6HO0TsJE3uoxYFNAKPWZPQ_w=.8ddc411b-8dd8-4ce8-9992-5b55d4075045@github.com>
Message-ID: <CsqCawO06jpMW9U4dOH8TgepSu0VPsuzj_vt8DZUVn4=.6235edc7-d923-4ffd-a227-b55776e4146f@github.com>

On Sat, 10 Feb 2024 09:49:56 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Done
>
> Flipping to execute and back during compilation seems to me to be a bad idea. I'd do it in inline asm instead.

Thank you! That looks to be outside the scope of this task but I will definitely look into it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17733#discussion_r1489850350

From sgibbons at openjdk.org  Wed Feb 14 17:55:20 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Wed, 14 Feb 2024 17:55:20 GMT
Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v10]
In-Reply-To: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
Message-ID: <LF5f0oqS4Z3hMHX044B8VRPJGo8JJ5kDhI6oD3HHG28=.e46e93ff-e85a-498b-b84f-f49d5f5240a1@github.com>

> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
> 
> 
> Benchmark	                                               Score		Latest		
> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
> StringIndexOf.success	                                9.186		9.713		1.057369911x
> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Move arrays_equals out of LP_64 block

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/e3e91953..8638a5f4

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

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

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

From ayang at openjdk.org  Wed Feb 14 18:02:05 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 14 Feb 2024 18:02:05 GMT
Subject: RFR: 8325082: Rename headers named 'heapRegion*' of G1 [v3]
In-Reply-To: <p9f42d634nvSGvduMCBA3FUTq1V9ZIPUstJ8IpeuyWg=.6693e68b-0060-4f23-af4d-691dca3b94bb@github.com>
References: <1MWMgluBwGY-FydUnpoksJ0q5sSvptrNMv6xwDszBQc=.a78cadad-1585-44d1-97d0-a7928fe34d67@github.com>
 <p9f42d634nvSGvduMCBA3FUTq1V9ZIPUstJ8IpeuyWg=.6693e68b-0060-4f23-af4d-691dca3b94bb@github.com>
Message-ID: <SY0M3nUsgN0i5egqg28W4j6pICWWRZ2ixU_XU5oR8qI=.f21c44ff-5acd-4f8a-b7f0-e6332c1fbf81@github.com>

On Wed, 14 Feb 2024 12:51:05 GMT, Lei Zaakjyu <duke at openjdk.org> wrote:

>> 8325082: Rename headers named 'heapRegion*' of G1
>
> Lei Zaakjyu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix

`src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/HeapRegion.java` and related files should be updated as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/17666#issuecomment-1944330338

From dcubed at openjdk.org  Wed Feb 14 18:36:04 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 14 Feb 2024 18:36:04 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v4]
In-Reply-To: <GJelJwYje5lVWNf-wcINBhLvnCIDk6cxCzuv6SQkzg0=.8f6457fa-9f9f-4fd9-b104-2a460bd69037@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <bKkHh3R39JCXKuQGrduWdZhJ9jstNA6xfUnJgPgbslE=.c1e27529-af8c-4707-9d24-473952502459@github.com>
 <5DPYtNaOL_44RemEpOUvNCJYISxC2bfUHakk7FVIj9k=.bd8baf61-bcf1-4c92-b31a-ef048e9dc64c@github.com>
 <FyUzHquSAC2WSUI0da52uhn7JQtJEsZiOGNWB9cEiIk=.0653f836-b00d-4b48-964a-cd8b6e0cb7aa@github.com>
 <dDiWEBRVCO6Jd5BrbOdhYKgDf1YFkMPvIHA1WLKcZ_c=.d64f726e-c131-4db2-aa3d-0a3da5f274f6@github.com>
 <GJelJwYje5lVWNf-wcINBhLvnCIDk6cxCzuv6SQkzg0=.8f6457fa-9f9f-4fd9-b104-2a460bd69037@github.com>
Message-ID: <WTS55ClivOezUqudIjX3a3lGh7_KYaPf9wxiHbM_wLA=.73e0284a-0211-4f96-9935-9ce099cd8426@github.com>

On Wed, 14 Feb 2024 11:56:27 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Thanks, Dan. I've pushed the suggested test changes but refactored them a little bit.

You are welcome. I presume the revised test passes with your fix in place. I made the
test changes on a baseline repo and not a repo that had your changes which is why I
had temporary debug flags in the test..

Also, do you agree with my test assertion comments in the verification point comments?
Am I properly understanding how we are changing this API?

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

PR Comment: https://git.openjdk.org/jdk/pull/17680#issuecomment-1944382731

From duke at openjdk.org  Wed Feb 14 18:57:02 2024
From: duke at openjdk.org (duke)
Date: Wed, 14 Feb 2024 18:57:02 GMT
Subject: Withdrawn: 8319115: GrowableArray: Do not initialize up to capacity
In-Reply-To: <w7RWZs2WpxJZJlZh3RRu0N8F1ICcOwRteyvnTOgkTuo=.686a4b6e-130c-4aa3-9d32-4a0dbb48cf0d@github.com>
References: <w7RWZs2WpxJZJlZh3RRu0N8F1ICcOwRteyvnTOgkTuo=.686a4b6e-130c-4aa3-9d32-4a0dbb48cf0d@github.com>
Message-ID: <WepNElJ6_vne3hecC1AwIJsLdinUFlsl42lEfinUuGk=.cef5f1b8-1843-4a55-bc01-dbe42e2ffe83@github.com>

On Fri, 1 Dec 2023 07:56:04 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> Before this patch, we always initialized the GrowableArray up to its `capacity`, and not just up to `length`. This is problematic for a few reasons:
> 
> - It is not expected. `std::vector` also only initializes the elements up to its size, and not to capacity.
> - It requires a default-constructor for the element type. And the default-constructor is then used to fill in the elements between length and capacity. If the elements do any allocation themselves, then this is a waste of resources.
> - The implementation also required the copy-assignment-operator for the element type. This is a lesser restriction. But the copy-assignment-operator was used in cases like `append` (where placement copy-construct would be expected), and not just in true assignment kinds of cases like `at_put`.
> 
> For this reason, I reworked a lot of the methods to ensure that only the "slots" up to `length` are ever initialized, and the space between `length` and `capacity` is always garbage.
> 
> -----
> 
> Also, before this patch, one can CHeap allocate both with `GrowableArray` and `GrowableArrayCHeap`. This is unnecessary. It required more complex verification in `GrowableArray` to deal with all cases. And `GrowableArrayCHeap` is already explicitly a smaller object, and should hence be preferred. Hence I changed all CHeap allocating cases of `GrowableArray` to `GrowableArrayCHeap`. This also allows for a clear separation:
> - `GrowableArray` only deals with arena / resource area allocation. These are arrays that are regularly abandoned at the end of their use, rather than deleted or even cleared.
> - `GrowableArrayCHeap` only deals with CHeap allocated memory. We expect that the destructor for it is called eventually, either when it goes out of scope or when `delete` is explicitly called. We expect that the elements could be allocating resources internally, and hence rely on the destructors for the elements being called, which may free up those internally allocated resources.
> 
> Therefore, we now only allow `GrowableArrayCHeap` to have element types with non-trivial destructors, but `GrowableArray` checks that element types do not have non-trivial destructors (since it is common practice to just abandon arena / resource area allocated arrays, rather than calling the destructor or clearing the array, which also destructs all elements). This more clearly separates the two worlds: clean-up your own mess (CHeap) vs abandon your mess (arena / resource area).
> 
> -----
> 
> I also completely refactored and improved ...

This pull request has been closed without being integrated.

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

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

From sspitsyn at openjdk.org  Wed Feb 14 20:35:05 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 14 Feb 2024 20:35:05 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v4]
In-Reply-To: <WTS55ClivOezUqudIjX3a3lGh7_KYaPf9wxiHbM_wLA=.73e0284a-0211-4f96-9935-9ce099cd8426@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <bKkHh3R39JCXKuQGrduWdZhJ9jstNA6xfUnJgPgbslE=.c1e27529-af8c-4707-9d24-473952502459@github.com>
 <5DPYtNaOL_44RemEpOUvNCJYISxC2bfUHakk7FVIj9k=.bd8baf61-bcf1-4c92-b31a-ef048e9dc64c@github.com>
 <FyUzHquSAC2WSUI0da52uhn7JQtJEsZiOGNWB9cEiIk=.0653f836-b00d-4b48-964a-cd8b6e0cb7aa@github.com>
 <dDiWEBRVCO6Jd5BrbOdhYKgDf1YFkMPvIHA1WLKcZ_c=.d64f726e-c131-4db2-aa3d-0a3da5f274f6@github.com>
 <GJelJwYje5lVWNf-wcINBhLvnCIDk6cxCzuv6SQkzg0=.8f6457fa-9f9f-4fd9-b104-2a460bd69037@github.com>
 <WTS55ClivOezUqudIjX3a3lGh7_KYaPf9wxiHbM_wLA=.73e0284a-0211-4f96-9935-9ce099cd8426@github.com>
Message-ID: <mCyB_i3jAy548rnaeDtgXnZcc9DAWQbu_3bxPjEoVjM=.6bc0b13f-62e9-463f-af87-74881a6b21ae@github.com>

On Wed, 14 Feb 2024 18:33:19 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>>> When you get the chance, can you checkout these possible
>> changes for the objmonusage001 test?
>> 
>> Thanks, Dan. I've pushed the suggested test changes but refactored them a little bit.
>
>> Thanks, Dan. I've pushed the suggested test changes but refactored them a little bit.
> 
> You are welcome. I presume the revised test passes with your fix in place. I made the
> test changes on a baseline repo and not a repo that had your changes which is why I
> had temporary debug flags in the test..
> 
> Also, do you agree with my test assertion comments in the verification point comments?
> Am I properly understanding how we are changing this API?

>From @dcubed-ojdk : 
> Also, do you agree with my test assertion comments in the verification point comments?
> Am I properly understanding how we are changing this API?

Yes, I agree. All looks right to me.
Q: Do you want to keep the `CHECK_FOR_BAD_RESULTS` mode or it can be removed after the failing output was verified?

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

PR Comment: https://git.openjdk.org/jdk/pull/17680#issuecomment-1944545272

From dcubed at openjdk.org  Wed Feb 14 21:17:03 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 14 Feb 2024 21:17:03 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v8]
In-Reply-To: <i4ilc2XEworX6I0J0trCxtd9jqZ4Q7SERhG0WJyRtl0=.cce47aa4-5833-4af0-a795-85701f346973@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <i4ilc2XEworX6I0J0trCxtd9jqZ4Q7SERhG0WJyRtl0=.cce47aa4-5833-4af0-a795-85701f346973@github.com>
Message-ID: <225C3AcEAOR7Zd--eHOBiqFHVv6h3Vpqet9TvXM1t08=.a086aa88-bb89-4d2d-9186-9a22eab00db4@github.com>

On Wed, 14 Feb 2024 15:25:33 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
>> The function returns the following structure:
>> 
>> 
>> typedef struct {
>>     jthread owner;
>>     jint entry_count;
>>     jint waiter_count;
>>     jthread* waiters;
>>     jint notify_waiter_count;
>>     jthread* notify_waiters;
>> } jvmtiMonitorUsage;
>> 
>> 
>> The following four fields are defined this way:
>> 
>> waiter_count  [jint] The number of threads waiting to own this monitor
>> waiters  [jthread*] The waiter_count waiting threads
>> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
>> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
>> 
>> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
>> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
>> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
>> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
>> This update makes it right.
>> 
>> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
>> 
>> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
>> 
>>   jvmti/GetObjectMonitorUsage/objmonusage001
>>   jvmti/GetObjectMonitorUsage/objmonusage003
>> 
>> 
>> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
>> 
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
>> 
>> 
>> 
>> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository.
>> 
>> Also, please see and review the related CSR:
>>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
>> 
>> The Release-Note is:
>> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage
>>  
>> Testing:
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: added assert to get_pending_threads; added suggested coverage to test objmonusage003

CHECK_FOR_BAD_RESULTS and ADD_DELAYS_FOR_RACES flags and
their associated code paths are for temporary debugging only.

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

PR Comment: https://git.openjdk.org/jdk/pull/17680#issuecomment-1944611040

From sgibbons at openjdk.org  Thu Feb 15 01:27:21 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Thu, 15 Feb 2024 01:27:21 GMT
Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v11]
In-Reply-To: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
Message-ID: <Ga3s2pHcasNnnU47H5MiGqH0UsVi_eBeqXyYQS1r6DQ=.1cfc92e5-52bf-4b80-9c16-021ed135b2fb@github.com>

> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
> 
> 
> Benchmark	                                               Score		Latest		
> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
> StringIndexOf.success	                                9.186		9.713		1.057369911x
> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Change copy to stack to be only if hs size - needle size > 10

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/8638a5f4..71ebf9e7

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

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

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

From kbarrett at openjdk.org  Thu Feb 15 03:08:05 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 15 Feb 2024 03:08:05 GMT
Subject: RFR: 8252136: Several methods in hotspot are missing "static" [v2]
In-Reply-To: <hyyoLaKm_KVZD7uPk7b5kTJSea_90tJjh-OaDH4_8X8=.8b14d2e0-3448-4878-b0f4-acd2691fba05@github.com>
References: <dleKPT17nKiOOWVZg8Jm9pMPiUFe6KfqSfR-gDQK63c=.fbc6290d-eec4-43e8-8970-9d773a115eb6@github.com>
 <qGxksLALrvcF8I7sxaPx4gqQ4la_7qJR-Y2e9UPglLk=.32a850c2-911a-4fb2-8f46-02f829978ce9@github.com>
 <hyyoLaKm_KVZD7uPk7b5kTJSea_90tJjh-OaDH4_8X8=.8b14d2e0-3448-4878-b0f4-acd2691fba05@github.com>
Message-ID: <RAqArypIN64SkkPL0mVoZNuZD3uYLrwAQbkbCXZW_xg=.ab0aaa8e-2345-44b1-92f2-de6f57d46685@github.com>

On Tue, 13 Feb 2024 10:29:48 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleWriter.cpp line 202:
>> 
>>> 200: static RootDescriptionInfo* root_infos = nullptr;
>>> 201: 
>>> 202: static int __write_sample_info__(JfrCheckpointWriter* writer, const void* si) {
>> 
>> pre-existing: all these names starting with underscores are technically reserved names - C++14 17.6.4.3.2.
>> Shouldn't be changed as part of this PR, but perhaps there should be a bug report?  Don't know if anyone
>> would ever get around to doing anything about it though.
>
> Please feel free to open a bug report. ? 
> 
> Unless there is a warning flag to avoid creating reserved names (is there?), it is more of a matter of coding style on the part of Hotspot, and that is basically where I draw the line of my meddling with Hotspot. :)

I just discovered that Clang 13 added `-Wreserved-identifier`.  There's also an open gcc bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51437

And a discussion of the "chattiness" of the feature:
https://github.com/llvm/llvm-project/issues/57913#issuecomment-1255493025

Probably there's not much appetite for this sort of thing, and I shouldn't have brought it up.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17806#discussion_r1490315316

From duke at openjdk.org  Thu Feb 15 04:15:00 2024
From: duke at openjdk.org (Lei Zaakjyu)
Date: Thu, 15 Feb 2024 04:15:00 GMT
Subject: RFR: 8325082: Rename headers named 'heapRegion*' of G1 [v4]
In-Reply-To: <1MWMgluBwGY-FydUnpoksJ0q5sSvptrNMv6xwDszBQc=.a78cadad-1585-44d1-97d0-a7928fe34d67@github.com>
References: <1MWMgluBwGY-FydUnpoksJ0q5sSvptrNMv6xwDszBQc=.a78cadad-1585-44d1-97d0-a7928fe34d67@github.com>
Message-ID: <_9q2JtGO1SLGKbP4DwXABaUKitBh61loksYSy3LOMPw=.9da6009b-6d65-4d6e-925b-d667667008fc@github.com>

> 8325082: Rename headers named 'heapRegion*' of G1

Lei Zaakjyu has updated the pull request incrementally with one additional commit since the last revision:

  rename

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17666/files
  - new: https://git.openjdk.org/jdk/pull/17666/files/d65b6597..faa6f661

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

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

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

From mdoerr at openjdk.org  Thu Feb 15 04:39:06 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 15 Feb 2024 04:39:06 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v13]
In-Reply-To: <8OXB2hSdtUljShW9BxphktBQGlsmjGATVODGUxeKlho=.7c7f3ee8-bdaf-4723-a8e7-f9829bf3ae41@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <NhFxqbcwvsAtJJTLMrHRntKKl0EW4QqfHQ8rRyVtgCY=.7d7dd89c-dbd2-485e-b76c-dfe95eff10a2@github.com>
 <8OXB2hSdtUljShW9BxphktBQGlsmjGATVODGUxeKlho=.7c7f3ee8-bdaf-4723-a8e7-f9829bf3ae41@github.com>
Message-ID: <xim7ESVbgj6F2SMX2D_t7Ryggx5MFOnmCoeJHwXGng8=.a613924a-b18a-429f-b218-348d1d34642a@github.com>

On Thu, 1 Feb 2024 10:31:14 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   spelling
>
> I'm busy with FOSDEM this week and probably next. Will look at this end of next week or the week after.

@tstuefe, @offamitkumar: You had requested changes. Should we wait for your feedback regarding the latest version?

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

PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1945348564

From amitkumar at openjdk.org  Thu Feb 15 04:44:58 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Thu, 15 Feb 2024 04:44:58 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v22]
In-Reply-To: <LHKPKfz60cA4rddKKT51OUG7jxispd9M7A0io897pG0=.d8b3c965-755b-4500-a3f1-72b578045060@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <LHKPKfz60cA4rddKKT51OUG7jxispd9M7A0io897pG0=.d8b3c965-755b-4500-a3f1-72b578045060@github.com>
Message-ID: <lKnX9in6QSYP9B1JcNSvJ_Io4n6QK6wSowJjy_vQklU=.16382f47-52ed-43a4-afb9-6f813f1ff248@github.com>

On Mon, 12 Feb 2024 18:04:21 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am.
>> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX.
>> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails.
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove not matched trailing whitespaces

Maybe the copyright year could be updated. Nothing else on my side.

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

Marked as reviewed by amitkumar (Committer).

PR Review: https://git.openjdk.org/jdk/pull/16604#pullrequestreview-1881747083

From epeter at openjdk.org  Thu Feb 15 06:54:21 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 15 Feb 2024 06:54:21 GMT
Subject: RFR: 8325095: C2: bailout message broken: ResourceArea allocated
 string used after free
Message-ID: <8Bl6JSxb-fd1xAsKOMzBakRFuruoqJykP7JEn57k6qY=.717f89af-2aa7-439b-afd1-768dd39f51da@github.com>

**Problem**
Bailout `failure_reason` strings used to be either `nullptr` or a static string. But with [JDK-8303951](https://bugs.openjdk.org/browse/JDK-8303951) I had introduced dynamic strings (e.g. formatted using `stringStream::as_string()`). These dynamic strings were ResourceArea allocated, and have a very limited life-span, i.e. withing the most recent ResourceMark scope. The pointer is passed to `Compile::_failure_reason`, which already might leave that ResourceMark scope, and the pointer is invalid. And then the pointer is further passed to `ciEnv::_failure_reason`. And finally, it even gets passed up to `CompileBroker::invoke_compiler_on_method`. When the string is finally printed for the bailout message, we already left original `ResourceMark` scope, and also the `Compile` and `ciEnv` scopes. The pointer now points to basically random data.

**Solution**
Whenever a string is passed to an outer scope, I make a CHeap copy, and the outer scope is the owner of that copy.
This way every scope is the owner of its own copy, and can allocate and deallocate according to its own strategy safely.

I introduced a utility class `CHeapStringHolder`:
 - `set`: make local copy on CHeap.
 - `clear`: free local copy. We before `set`, and in the destructor. Thus, when the holder goes out of scope, the memory is automatically freed.

We have these 4 scopes:
- `ResourceMark`: It allocates from `ResourcArea`, and deallocation is taken care at the end of the ResourceMark scope.
- `Compile`: We turn the `_failure_reason` from a `char*` into a `CHeapStringHolder`. We set `_failure_reason` while the `ResourceMark` is live.
- `ciEnv`: We turn the `_failure_reason` from a `char*` into a `CHeapStringHolder`. We set `_failure_reason` while `Compile` is live.
- `CompileTask`: We used to just set `failure_reason`, which assumes that the string is static or elsewhere managed. Now I use pattern available in other places of `CompileBroker::invoke_compiler_on_method`: duplicate the string with `os::strdup` from some other scope, and set `reason_on_C_heap = true`, which means that we are the owner of that copy, and are responsible for freeing it later. Not sure if that is a nice pattern, but I don't want to refactor that code and it does what I need it to do.

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

Commit messages:
 - strcmp for MemStat
 - cleanup debug prints
 - Merge branch 'master' into JDK-8325095
 - more fix
 - copy string from ciEnv
 - remove use of resource_area
 - fixed ciEnv
 - add string holder class
 - use ResourceArea instead of Arena, to make lifetime smaller
 - 8325095

Changes: https://git.openjdk.org/jdk/pull/17710/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17710&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8325095
  Stats: 140 lines in 9 files changed: 118 ins; 3 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/17710.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17710/head:pull/17710

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

From jsjolen at openjdk.org  Thu Feb 15 06:54:21 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 15 Feb 2024 06:54:21 GMT
Subject: RFR: 8325095: C2: bailout message broken: ResourceArea allocated
 string used after free
In-Reply-To: <8Bl6JSxb-fd1xAsKOMzBakRFuruoqJykP7JEn57k6qY=.717f89af-2aa7-439b-afd1-768dd39f51da@github.com>
References: <8Bl6JSxb-fd1xAsKOMzBakRFuruoqJykP7JEn57k6qY=.717f89af-2aa7-439b-afd1-768dd39f51da@github.com>
Message-ID: <MaJUPYVkZicr3t7lBKkxPtL6niMnIZ2qkx5m59DscN0=.7bf063ff-d4d0-4e9d-87d3-1dcc106f2d2f@github.com>

On Mon, 5 Feb 2024 16:02:57 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> **Problem**
> Bailout `failure_reason` strings used to be either `nullptr` or a static string. But with [JDK-8303951](https://bugs.openjdk.org/browse/JDK-8303951) I had introduced dynamic strings (e.g. formatted using `stringStream::as_string()`). These dynamic strings were ResourceArea allocated, and have a very limited life-span, i.e. withing the most recent ResourceMark scope. The pointer is passed to `Compile::_failure_reason`, which already might leave that ResourceMark scope, and the pointer is invalid. And then the pointer is further passed to `ciEnv::_failure_reason`. And finally, it even gets passed up to `CompileBroker::invoke_compiler_on_method`. When the string is finally printed for the bailout message, we already left original `ResourceMark` scope, and also the `Compile` and `ciEnv` scopes. The pointer now points to basically random data.
> 
> **Solution**
> Whenever a string is passed to an outer scope, I make a CHeap copy, and the outer scope is the owner of that copy.
> This way every scope is the owner of its own copy, and can allocate and deallocate according to its own strategy safely.
> 
> I introduced a utility class `CHeapStringHolder`:
>  - `set`: make local copy on CHeap.
>  - `clear`: free local copy. We before `set`, and in the destructor. Thus, when the holder goes out of scope, the memory is automatically freed.
> 
> We have these 4 scopes:
> - `ResourceMark`: It allocates from `ResourcArea`, and deallocation is taken care at the end of the ResourceMark scope.
> - `Compile`: We turn the `_failure_reason` from a `char*` into a `CHeapStringHolder`. We set `_failure_reason` while the `ResourceMark` is live.
> - `ciEnv`: We turn the `_failure_reason` from a `char*` into a `CHeapStringHolder`. We set `_failure_reason` while `Compile` is live.
> - `CompileTask`: We used to just set `failure_reason`, which assumes that the string is static or elsewhere managed. Now I use pattern available in other places of `CompileBroker::invoke_compiler_on_method`: duplicate the string with `os::strdup` from some other scope, and set `reason_on_C_heap = true`, which means that we are the owner of that copy, and are responsible for freeing it later. Not sure if that is a nice pattern, but I don't want to refactor that code and it does what I need it to do.

Hi,

I don't agree with the way this patch works and I think we're bound for trouble. Why not store an instance of this class inside of the task instead? It takes a bit more space (136 bytes) but it actually handles its own lifetime.

```c++
class CompilationFailure {
  stringStream failure_reason;
  CompilationFailure() : failure_reason() {}
  void replace_failure(const char* reason) { 
    failure_reason.reset();
    failure_reason.print_raw(reason);
  }
  const stringStream& reason() const {
    return failure_reason;
  }
}

I don't like it because you're leaking memory over the lifetime of the `CompileTask` and because there are simpler solutions, as we only ever store one failure reason.

>Your suggestion would require that there is only a single failure_reason around at any given time. But I'm not sure if there is really only a single reason around, at least they are set at different places, and can be replaced... That is why I was looking for something that can keep the lifetime of multiple strings.

How would multiple strings be accessed through one const pointer :-)?

>Essencially, your solution would just be a better version of what we have with failure_reason_on_C_heap.

Yes, the lifetime is managed correctly and automatically by the RAII object. Plus, the bool can be removed. One issue is that you will probably have to add a bool `has_reason` to the class  I suggested, we can't depend on something being `nullptr` to indicate absence of reason anymore.

You don't need a new string class, you can use `stringStream` as that will hold the string memory and its local copy. I've looked at the code and we have 3 separate pointers to a failure reason (as you said), one in ciEnv, one in Compile, and one in CompileTask. Instead of using pointers, use the class I suggested and have these 3 have ownership of their own copies of these strings. The allocations' cost is irrelevant :-).

Depending on the usage you'll just have to use `.freeze()` or `.base()` which will give you the underlying string array, no copying needed!

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

PR Comment: https://git.openjdk.org/jdk/pull/17710#issuecomment-1929195534
PR Comment: https://git.openjdk.org/jdk/pull/17710#issuecomment-1929295815
PR Comment: https://git.openjdk.org/jdk/pull/17710#issuecomment-1929361362
PR Comment: https://git.openjdk.org/jdk/pull/17710#issuecomment-1929388369

From epeter at openjdk.org  Thu Feb 15 06:54:21 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 15 Feb 2024 06:54:21 GMT
Subject: RFR: 8325095: C2: bailout message broken: ResourceArea allocated
 string used after free
In-Reply-To: <MaJUPYVkZicr3t7lBKkxPtL6niMnIZ2qkx5m59DscN0=.7bf063ff-d4d0-4e9d-87d3-1dcc106f2d2f@github.com>
References: <8Bl6JSxb-fd1xAsKOMzBakRFuruoqJykP7JEn57k6qY=.717f89af-2aa7-439b-afd1-768dd39f51da@github.com>
 <MaJUPYVkZicr3t7lBKkxPtL6niMnIZ2qkx5m59DscN0=.7bf063ff-d4d0-4e9d-87d3-1dcc106f2d2f@github.com>
Message-ID: <BiBGidenKlJVmYTnMqMdTttoqiENlKNIvAXJx4xi6E0=.31718451-787f-40ca-a1b0-1dd53303236f@github.com>

On Tue, 6 Feb 2024 10:18:26 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> **Problem**
>> Bailout `failure_reason` strings used to be either `nullptr` or a static string. But with [JDK-8303951](https://bugs.openjdk.org/browse/JDK-8303951) I had introduced dynamic strings (e.g. formatted using `stringStream::as_string()`). These dynamic strings were ResourceArea allocated, and have a very limited life-span, i.e. withing the most recent ResourceMark scope. The pointer is passed to `Compile::_failure_reason`, which already might leave that ResourceMark scope, and the pointer is invalid. And then the pointer is further passed to `ciEnv::_failure_reason`. And finally, it even gets passed up to `CompileBroker::invoke_compiler_on_method`. When the string is finally printed for the bailout message, we already left original `ResourceMark` scope, and also the `Compile` and `ciEnv` scopes. The pointer now points to basically random data.
>> 
>> **Solution**
>> Whenever a string is passed to an outer scope, I make a CHeap copy, and the outer scope is the owner of that copy.
>> This way every scope is the owner of its own copy, and can allocate and deallocate according to its own strategy safely.
>> 
>> I introduced a utility class `CHeapStringHolder`:
>>  - `set`: make local copy on CHeap.
>>  - `clear`: free local copy. We before `set`, and in the destructor. Thus, when the holder goes out of scope, the memory is automatically freed.
>> 
>> We have these 4 scopes:
>> - `ResourceMark`: It allocates from `ResourcArea`, and deallocation is taken care at the end of the ResourceMark scope.
>> - `Compile`: We turn the `_failure_reason` from a `char*` into a `CHeapStringHolder`. We set `_failure_reason` while the `ResourceMark` is live.
>> - `ciEnv`: We turn the `_failure_reason` from a `char*` into a `CHeapStringHolder`. We set `_failure_reason` while `Compile` is live.
>> - `CompileTask`: We used to just set `failure_reason`, which assumes that the string is static or elsewhere managed. Now I use pattern available in other places of `CompileBroker::invoke_compiler_on_method`: duplicate the string with `os::strdup` from some other scope, and set `reason_on_C_heap = true`, which means that we are the owner of that copy, and are responsible for freeing it later. Not sure if that is a nice pattern, but I don't want to refactor that code and it does what I need it to do.
>
> Hi,
> 
> I don't agree with the way this patch works and I think we're bound for trouble. Why not store an instance of this class inside of the task instead? It takes a bit more space (136 bytes) but it actually handles its own lifetime.
> 
> ```c++
> class CompilationFailure {
>   stringStream failure_reason;
>   CompilationFailure() : failure_reason() {}
>   void replace_failure(const char* reason) { 
>     failure_reason.reset();
>     failure_reason.print_raw(reason);
>   }
>   const stringStream& reason() const {
>     return failure_reason;
>   }
> }

@jdksjolen
> I don't agree with the way this patch works and I think we're bound for trouble.

Why?

Essencially, your solution would just be a better version of what we have with `failure_reason_on_C_heap`.

Your suggestion would require that there is only a single failure_reason around at any given time. But I'm not sure if there is really only a single reason around, at least they are set at different places, and can be replaced... That is why I was looking for something that can keep the lifetime of multiple strings.

I'm not saying I'm proud of the draft-solution yet :rofl: 

These strings are stored at the level of the compilation, ciEnv (outlives compilation), and CompileTask (outlives ciEnv). So I need to allocate the string from somewhere that persists when I format the string, and then pass it into `record_method_not_compilable`. Currently, there is no clear ownership of the strings, and we did not need that as long as all the strings were static - but that has changed.

Maybe I can refactor it all and make sure there is only a single reason at any time. Not sure if that is feasible or how much work that would be.

One issue is that failure_reasons, and especially dynamic failure_reasons are rare, and not really tested. So it is hard to see if I would break things.

> I don't like it because you're leaking memory over the lifetime of the `CompileTask` and because there are simpler solutions, as we only ever store one failure reason.
> 
>>Your suggestion would require that there is only a single failure_reason around at any given time. But I'm not sure if there is really only a single reason around, at least they are set at different places, and can be replaced... That is why I was looking for something that can keep the lifetime of multiple strings.
> 
> How would multiple strings be accessed through one const pointer :-)?
> 
>>Essencially, your solution would just be a better version of what we have with failure_reason_on_C_heap.
> 
> Yes, the lifetime is managed correctly and automatically by the RAII object. Plus, the bool can be removed. One issue is that you will probably have to add a bool `has_reason` to the class  I suggested, we can't depend on something being `nullptr` to indicate absence of reason anymore.

@jdksjolen 
> How would multiple strings be accessed through one const pointer :-)?

Well, there are multiple pointers ? 
`grep "failure_reason" src/hotspot/share/ -r | grep "char*"`

I know that the strings are passed between `Compile`, `ciEnv` and `CompileTask`. This means we would have multiple owners, and that is not great. Again: maybe that can be refactored, but it would take me some time and it would be risky because we don't have good testing for failure_reason reporting. Feel free to dive into the different `record_method_not_compilable` methods yourself.

What about having a new `CHeapString` class? It could hold a string (or null, or even special case for static string). We pass that around. The copy-constructor just re-allocates the string on CHeap, the destructor frees the string (unless static or null). This all comes at the cost of some more (occasional, probably rare) allocations.

> You don't need a new string class, you can use `stringStream` as that will hold the string memory and its local copy. I've looked at the code and we have 3 separate pointers to a failure reason (as you said), one in ciEnv, one in Compile, and one in CompileTask. Instead of using pointers, use the class I suggested and have these 3 have ownership of their own copies of these strings. The allocations' cost is irrelevant :-).

@jdksjolen
Ok, so this new approach would have every place that currently has a pointer become a proper "owner" that manages the life-time of its string.

I think I prefer a new string-class, that also allows for null and possibly static strings (no allocation). Otherwise, if I use `stringStream`, then I would either have to initialize them as empty, and check for empty (-> no failure_reason). And I also would  have to always export the actual string over `as_string`, which copies one more time to either ResourceArea or CHeap.

Thanks for chiming in here, Johan :)

> Depending on the usage you'll just have to use `.freeze()` or `.base()` which will give you the underlying string array, no copying needed!

@jdksjolen I tried it with such a string class. And then I tried to use it for `ciEnv::_failure_reason`. But now I run into this:


/oracle-work/jdk-fork3/open/src/hotspot/share/runtime/vmStructs.cpp:729:3: note: in expansion of macro 'CHECK_NONSTATIC_VM_STRUCT_ENTRY'
  729 |   nonstatic_field(ciEnv,                       _failure_reason,                               const char*)                           \


Any suggestions with that?

Update: I think it is actually not used by the servicability agent, and I can just delete that reference.

Thanks @jdksjolen for your suggestions! I now found a solution I'm fine with, and that seems to work.

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

PR Comment: https://git.openjdk.org/jdk/pull/17710#issuecomment-1929217140
PR Comment: https://git.openjdk.org/jdk/pull/17710#issuecomment-1929317038
PR Comment: https://git.openjdk.org/jdk/pull/17710#issuecomment-1929381900
PR Comment: https://git.openjdk.org/jdk/pull/17710#issuecomment-1936517746
PR Comment: https://git.openjdk.org/jdk/pull/17710#issuecomment-1945464104

From epeter at openjdk.org  Thu Feb 15 06:54:21 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 15 Feb 2024 06:54:21 GMT
Subject: RFR: 8325095: C2: bailout message broken: ResourceArea allocated
 string used after free
In-Reply-To: <8Bl6JSxb-fd1xAsKOMzBakRFuruoqJykP7JEn57k6qY=.717f89af-2aa7-439b-afd1-768dd39f51da@github.com>
References: <8Bl6JSxb-fd1xAsKOMzBakRFuruoqJykP7JEn57k6qY=.717f89af-2aa7-439b-afd1-768dd39f51da@github.com>
Message-ID: <VJub3aI6xgBE-Pj8wLR1CIDdonYKVTAz5jncs70fxLo=.9682079a-0de3-4c18-98f3-928d7c9158ee@github.com>

On Mon, 5 Feb 2024 16:02:57 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> **Problem**
> Bailout `failure_reason` strings used to be either `nullptr` or a static string. But with [JDK-8303951](https://bugs.openjdk.org/browse/JDK-8303951) I had introduced dynamic strings (e.g. formatted using `stringStream::as_string()`). These dynamic strings were ResourceArea allocated, and have a very limited life-span, i.e. withing the most recent ResourceMark scope. The pointer is passed to `Compile::_failure_reason`, which already might leave that ResourceMark scope, and the pointer is invalid. And then the pointer is further passed to `ciEnv::_failure_reason`. And finally, it even gets passed up to `CompileBroker::invoke_compiler_on_method`. When the string is finally printed for the bailout message, we already left original `ResourceMark` scope, and also the `Compile` and `ciEnv` scopes. The pointer now points to basically random data.
> 
> **Solution**
> Whenever a string is passed to an outer scope, I make a CHeap copy, and the outer scope is the owner of that copy.
> This way every scope is the owner of its own copy, and can allocate and deallocate according to its own strategy safely.
> 
> I introduced a utility class `CHeapStringHolder`:
>  - `set`: make local copy on CHeap.
>  - `clear`: free local copy. We before `set`, and in the destructor. Thus, when the holder goes out of scope, the memory is automatically freed.
> 
> We have these 4 scopes:
> - `ResourceMark`: It allocates from `ResourcArea`, and deallocation is taken care at the end of the ResourceMark scope.
> - `Compile`: We turn the `_failure_reason` from a `char*` into a `CHeapStringHolder`. We set `_failure_reason` while the `ResourceMark` is live.
> - `ciEnv`: We turn the `_failure_reason` from a `char*` into a `CHeapStringHolder`. We set `_failure_reason` while `Compile` is live.
> - `CompileTask`: We used to just set `failure_reason`, which assumes that the string is static or elsewhere managed. Now I use pattern available in other places of `CompileBroker::invoke_compiler_on_method`: duplicate the string with `os::strdup` from some other scope, and set `reason_on_C_heap = true`, which means that we are the owner of that copy, and are responsible for freeing it later. Not sure if that is a nice pattern, but I don't want to refactor that code and it does what I need it to do.

src/hotspot/share/compiler/compilationMemoryStatistic.cpp line 408:

> 406:     const char* const failure_reason = env->failure_reason();
> 407:     if (failure_reason != nullptr) {
> 408:       result = (strcmp(failure_reason, failure_reason_memlimit()) == 0) ? "oom" : "err";

Note: Now that `ciEnv` makes a local copy, we cannot just compare pointers, we need to compare the content.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17710#discussion_r1489838048

From dholmes at openjdk.org  Thu Feb 15 07:12:04 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 15 Feb 2024 07:12:04 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v5]
In-Reply-To: <dVaq7wekOcAHZqMOBX0vYYfqrctHh0aN7mVcNlSUvP8=.ab3c9632-9b13-4310-8aa6-b772519d6b16@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <EwIwVHOIpJbV6fpHsNuoepv90GjfdanfYZpctKgtJ80=.82eab452-6f0d-470d-8a55-07aaab0dbec8@github.com>
 <jBV90lLy2RsDhx27JWiRQxQ4YWONm8d-l94zK0Zq0UM=.3a8bd3f7-1189-4b1a-a755-01ceb62ce328@github.com>
 <dVaq7wekOcAHZqMOBX0vYYfqrctHh0aN7mVcNlSUvP8=.ab3c9632-9b13-4310-8aa6-b772519d6b16@github.com>
Message-ID: <hSCdLBVZcvGHZpYye8gFnNhg4d9OY2sfD_v6zoxVJ8g=.08daa88b-9f4c-4556-a938-c440b4dea089@github.com>

On Wed, 14 Feb 2024 12:16:38 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/runtime/threads.cpp line 1200:
>> 
>>> 1198:     if (pending == monitor ||
>>> 1199:         (waiting == monitor && JavaThreadStatus::BLOCKED_ON_MONITOR_ENTER ==
>>> 1200:          java_lang_Thread::get_thread_status(p->vthread_or_thread()))
>> 
>> This code seems extremely racy. Is there anything that is stopping the target thread from running while we attempt this inspection of the oop state? If it was waiting and was interrupted or timed-out then we could mistakenly think it was still pending entry to this monitor when in fact it is not.
>> It is also a shame that we have to reach up into the oop thread state to figure out if if it is blocked on re-entry ...
>
> The function `get_pending_threads()` is executed only by the VM_GetObjectMonitorUsage operation.
> I've added this assert there: 
>     `assert(Thread::current()->is_VM_thread(), "Must be the VM thread");`
> Does it address your concern?

Yes thanks. Didn't realize we were in a safepoint VM op.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1490510763

From dlong at openjdk.org  Thu Feb 15 08:08:04 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 15 Feb 2024 08:08:04 GMT
Subject: RFR: 8325095: C2: bailout message broken: ResourceArea allocated
 string used after free
In-Reply-To: <8Bl6JSxb-fd1xAsKOMzBakRFuruoqJykP7JEn57k6qY=.717f89af-2aa7-439b-afd1-768dd39f51da@github.com>
References: <8Bl6JSxb-fd1xAsKOMzBakRFuruoqJykP7JEn57k6qY=.717f89af-2aa7-439b-afd1-768dd39f51da@github.com>
Message-ID: <5jZ1LNpPWlxMQ-P4d0XEqi320KzRmvlxc5lWLvUae_E=.ef584842-4d46-4292-8954-2650b777a55a@github.com>

On Mon, 5 Feb 2024 16:02:57 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> **Problem**
> Bailout `failure_reason` strings used to be either `nullptr` or a static string. But with [JDK-8303951](https://bugs.openjdk.org/browse/JDK-8303951) I had introduced dynamic strings (e.g. formatted using `stringStream::as_string()`). These dynamic strings were ResourceArea allocated, and have a very limited life-span, i.e. withing the most recent ResourceMark scope. The pointer is passed to `Compile::_failure_reason`, which already might leave that ResourceMark scope, and the pointer is invalid. And then the pointer is further passed to `ciEnv::_failure_reason`. And finally, it even gets passed up to `CompileBroker::invoke_compiler_on_method`. When the string is finally printed for the bailout message, we already left original `ResourceMark` scope, and also the `Compile` and `ciEnv` scopes. The pointer now points to basically random data.
> 
> **Solution**
> Whenever a string is passed to an outer scope, I make a CHeap copy, and the outer scope is the owner of that copy.
> This way every scope is the owner of its own copy, and can allocate and deallocate according to its own strategy safely.
> 
> I introduced a utility class `CHeapStringHolder`:
>  - `set`: make local copy on CHeap.
>  - `clear`: free local copy. We before `set`, and in the destructor. Thus, when the holder goes out of scope, the memory is automatically freed.
> 
> We have these 4 scopes:
> - `ResourceMark`: It allocates from `ResourcArea`, and deallocation is taken care at the end of the ResourceMark scope.
> - `Compile`: We turn the `_failure_reason` from a `char*` into a `CHeapStringHolder`. We set `_failure_reason` while the `ResourceMark` is live.
> - `ciEnv`: We turn the `_failure_reason` from a `char*` into a `CHeapStringHolder`. We set `_failure_reason` while `Compile` is live.
> - `CompileTask`: We used to just set `failure_reason`, which assumes that the string is static or elsewhere managed. Now I use pattern available in other places of `CompileBroker::invoke_compiler_on_method`: duplicate the string with `os::strdup` from some other scope, and set `reason_on_C_heap = true`, which means that we are the owner of that copy, and are responsible for freeing it later. Not sure if that is a nice pattern, but I don't want to refactor that code and it does what I need it to do.

Back when I filed JDK-8132354, I proposed that both C1 and C2 delegate to ciEnv.  Now there is a 3rd layer/scope of error reporting.  I don't think the solution needs to be so complicated.  Even with the new formatted strings, the maximum possible length can be determined (I don't see it using klass or method names).  So why can't the storage simply be `char[MAX_COMPILER_ERROR_LEN]` in `CompilerThread`, and setting it be a `strncpy`?

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

PR Comment: https://git.openjdk.org/jdk/pull/17710#issuecomment-1945544012

From stuefe at openjdk.org  Thu Feb 15 08:18:09 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 15 Feb 2024 08:18:09 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v22]
In-Reply-To: <LHKPKfz60cA4rddKKT51OUG7jxispd9M7A0io897pG0=.d8b3c965-755b-4500-a3f1-72b578045060@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <LHKPKfz60cA4rddKKT51OUG7jxispd9M7A0io897pG0=.d8b3c965-755b-4500-a3f1-72b578045060@github.com>
Message-ID: <F5C_TjQXv6KNpn3yN8J37_eSIOWtRYZT3RwNkSu-Xq0=.723d24c7-355e-42e6-80a7-b1b8aa476520@github.com>

On Mon, 12 Feb 2024 18:04:21 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am.
>> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX.
>> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails.
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove not matched trailing whitespaces

Hi,

some remarks:

- there is no need for a copy for the first call to dll_load_library. Just hand in the string 1:1.
- I would only do the *.a fallback loading if the error indicates that the *.so file had not been there. So, only if EACCESS or ENOENT; in all other cases I would not do the fallback. E.g. if the *.so file cannot be loaded due to a header mismatch. See https://www.ibm.com/docs/en/aix/7.1?topic=l-load-loadandinit-subroutines
- Please use os::strdup.
- Please assert that the replacement string is smaller than the original string (which it should be, *.so is longer than *.a, but this is insurance against anyone changing the code in the future)

Thank you, Thomas

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

Changes requested by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16604#pullrequestreview-1882051726

From mbaesken at openjdk.org  Thu Feb 15 08:31:14 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 15 Feb 2024 08:31:14 GMT
Subject: RFR: JDK-8325116: Amend jdk.ContainerConfiguration by swap related
 value
Message-ID: <0UFSBwJVq31ZaVhhm7ssaR5jNa2AALYUgHtBWIQxi9Y=.b3e42160-9d6f-4e99-83ee-7f08f85d04c1@github.com>

jdk.ContainerInformation event could get amended to report the host total swap values for Linux like was done in
https://bugs.openjdk.org/browse/JDK-8296671 by host total memory.
Two additional fields could be added hostSwapTotal, maybe hostSwapFree;
container free swap space in case we find a good implementation, could also be added to the implementation in os_linux.

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

Commit messages:
 - JDK-8325116

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

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

From sspitsyn at openjdk.org  Thu Feb 15 08:53:24 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 15 Feb 2024 08:53:24 GMT
Subject: RFR: 8324680: Replace NULL with nullptr in JVMTI generated code
Message-ID: <w1DMQMwGugoSs830xWYD6l7yoIR6v8dk5MnKYIY8t9w=.1ad08a17-8efc-4a71-88a5-78da29ce4ab4@github.com>

This enhancement replaces uses of NULL with nullptr in the XML-description files for JVMTI. These are the files `hotsport/share/prims/jvmti.xml` and `hotspot/share/prims/jvmti*.xls`.

The following files are auto-generated from the `jvmti.xml` and `*.xsl files` in the `build/<CFG>/variant-server/gensrc/jvmtifiles': `jvmti.h`, `jvmti.html`, `jvmtiEnter.cpp`, `jvmtiEnterTrace.cpp`, `jvmtiEnv.hpp`

This addresses a category of NULL uses that wasn't dealt with by:
 [JDK-8299837](https://bugs.openjdk.org/browse/JDK-8299837).
 
 Testing:
   - TBD: run mach5 tiers1-3

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

Commit messages:
 - 8324680: Replace NULL with nullptr in JVMTI generated code

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

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

From jwaters at openjdk.org  Thu Feb 15 09:15:11 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 15 Feb 2024 09:15:11 GMT
Subject: RFR: 8325932: Replace ATTRIBUTE_NORETURN with direct [[noreturn]]
Message-ID: <tTaR4IXFQKtg9-tmJ-JAC4hfHNxB8rMhEyl5uxHOh7A=.33c5a2dd-a760-43eb-8518-c066786ec72d@github.com>

With clang 13 being the minimum required JDK-8325878, the noreturn bug that requires the ATTRIBUTE_NORETURN workaround now vanishes, and we can use [[noreturn]] directly within HotSpot. We should remove the workaround as soon as possible, given the chance

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

Commit messages:
 - Replace ATTRIBUTE_NORETURN with direct [[noreturn]]

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

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

From eosterlund at openjdk.org  Thu Feb 15 09:30:07 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 15 Feb 2024 09:30:07 GMT
Subject: Integrated: 8324933: ConcurrentHashTable::statistics_calculate
 synchronization is expensive
In-Reply-To: <BWI_sYMoH8SOp_kpYvkmFrHcBP38G_sMW4_LJR_8Ev0=.ffc95dc6-b110-4c22-ac32-6eaa10c7a6c1@github.com>
References: <BWI_sYMoH8SOp_kpYvkmFrHcBP38G_sMW4_LJR_8Ev0=.ffc95dc6-b110-4c22-ac32-6eaa10c7a6c1@github.com>
Message-ID: <dKwvJhNCPy6xtIegvP-l2QVIlIoyG4EOzjz-4HZRFeM=.e244fc53-f17c-4f04-ad22-6fef7026ba62@github.com>

On Tue, 30 Jan 2024 10:48:18 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> In the ConcurrentHashTable::statistics_calculate function, we enter and exit a ScopedCS with the global counter for every single bucket. This has showed up to be pretty intense on some machines. We should make the synchronization a bit less intense here. This patch adds simple batching so we synchronize once per 128 buckets instead of every single one.

This pull request has now been integrated.

Changeset: 0e2fdc95
Author:    Erik ?sterlund <eosterlund at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0e2fdc95ae47c11e6a1e47cdc6190268e29a9d9c
Stats:     20 lines in 1 file changed: 8 ins; 1 del; 11 mod

8324933: ConcurrentHashTable::statistics_calculate synchronization is expensive

Reviewed-by: tschatzl, coleenp

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

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

From aph at openjdk.org  Thu Feb 15 09:35:59 2024
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 15 Feb 2024 09:35:59 GMT
Subject: RFR: 8319801: Recursive lightweight locking: aarch64
 implementation [v16]
In-Reply-To: <GZqZJAr2sWJFv4nsTZr636rg6g44jEQ95X7uyTucQzY=.395124cd-fcf2-4dc3-bd29-db438e946991@github.com>
References: <AE1nsnyRCUHR970jjg4feUm5f6E1GPJvea0ooC6dCgI=.73fff610-c0f6-422a-a45d-88187b37b9a2@github.com>
 <CSIkQw9NjfsFbuQ_P-gbX3iaKNQU5-YvGe6HWjRBkME=.ea80bc31-87b8-4299-a2dd-67497115c315@github.com>
 <yMtyXpGAUu6rihQ81l6xXwXsSx3BCWD2nPnshE5VU5Y=.556278ed-64f6-477f-9366-b32f69b8b354@github.com>
 <GZqZJAr2sWJFv4nsTZr636rg6g44jEQ95X7uyTucQzY=.395124cd-fcf2-4dc3-bd29-db438e946991@github.com>
Message-ID: <rr7mTGlhkf5Y1YkYgq2PUYEmvTIG_50JLDN3xpE1Jfw=.13c94b93-35a2-400a-bf36-2cfda98c9b84@github.com>

On Wed, 14 Feb 2024 08:42:16 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 416:
>> 
>>> 414: 
>>> 415:     // mark contains the tagged ObjectMonitor*.
>>> 416:     const Register monitor = mark;
>> 
>> I wouldn't do this. Making `monitor` a register alias for `mark` is at best confusing and at worst dangerous. As a general rule, aliased register names have caused many bugs.
>
> I have been trying to think of alternatives which improve this situation. 
> 
> Is it the fact that monitor alias mark, or any of the aliases used for the in-parameters that is confusing?
> If it is the first do you see the following as a solution:
> ```c++
>     const Register monitor = t1;
>     const uintptr_t monitor_tag = markWord::monitor_value;
> 
>     // Untag the monitor.
>     sub(monitor, mark, monitor_tag);
> 
> and for the lock case
> ```c++
>     const Register tagged_monitor = t1;
>     mov(tagged_monitor, mark); 
> 
> where the mov will emit no instruction as they are the same register.
> (These two variants seem somewhat equivalent to me, but it was not clear from your comment if this is the issue)
> 
> If it is the second, I feel like the best compromise would to still alias register via named variables, but give them names that show their origin (so you do not need a language server or scroll/grep to get the contextual information). 
> E.g.
> ```c++
>     const Register t1_monitor = t1;
>     const uintptr_t monitor_tag = markWord::monitor_value;
> 
>     // Untag the monitor.
>     sub(t1_monitor, t1_mark, monitor_tag);
> 
> 
> I would like to hear if I have misunderstood something and / or if you have another proposed solution to this issue.
> 
> This seem to be the final issue blocking integration.

These are both misleading to the reader. Sure, they're cute, but they're dangerous, as has proved in practice several times in the AArch64 port. Writing a `mov` that is known to do nothing is severely misleading. It can be mitigated with a "this mov does nothing" comment.

A prefix naming convention is a significant improvement, . It may also be a good idea to poison the no-longer-valid names (with a `#define`).

Bear in mind that the typical reader is skim-reading this stuff.

I've been trying a better way to do register allocation in hand-coded assembly, where a `RegSet` contains the currently-free registers. At the end of its live range, a value is pushed back into the free set. This avoids most of the pitfalls. (I'm not suggesting that here, it's something to think about for tr future.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16608#discussion_r1490704403

From aboldtch at openjdk.org  Thu Feb 15 10:15:06 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 15 Feb 2024 10:15:06 GMT
Subject: RFR: 8319801: Recursive lightweight locking: aarch64
 implementation [v16]
In-Reply-To: <rr7mTGlhkf5Y1YkYgq2PUYEmvTIG_50JLDN3xpE1Jfw=.13c94b93-35a2-400a-bf36-2cfda98c9b84@github.com>
References: <AE1nsnyRCUHR970jjg4feUm5f6E1GPJvea0ooC6dCgI=.73fff610-c0f6-422a-a45d-88187b37b9a2@github.com>
 <CSIkQw9NjfsFbuQ_P-gbX3iaKNQU5-YvGe6HWjRBkME=.ea80bc31-87b8-4299-a2dd-67497115c315@github.com>
 <yMtyXpGAUu6rihQ81l6xXwXsSx3BCWD2nPnshE5VU5Y=.556278ed-64f6-477f-9366-b32f69b8b354@github.com>
 <GZqZJAr2sWJFv4nsTZr636rg6g44jEQ95X7uyTucQzY=.395124cd-fcf2-4dc3-bd29-db438e946991@github.com>
 <rr7mTGlhkf5Y1YkYgq2PUYEmvTIG_50JLDN3xpE1Jfw=.13c94b93-35a2-400a-bf36-2cfda98c9b84@github.com>
Message-ID: <NuE_vuEB5sP1yTfVArZxxnJNvzWol6hSZtyciNU7mns=.f12e6f6d-4506-40d4-800b-cf8874a416f6@github.com>

On Thu, 15 Feb 2024 09:33:08 GMT, Andrew Haley <aph at openjdk.org> wrote:

> These are both misleading to the reader. Sure, they're cute, but they're dangerous, as has proved in practice several times in the AArch64 port. Writing a `mov` that is known to do nothing is severely misleading. It can be mitigated with a "this mov does nothing" comment.

I suspected that this interpretation of what you was asking was incorrect, but wanted to clarify. 

> A prefix naming convention is a significant improvement

I will go ahead with this approach then.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16608#discussion_r1490758797

From aboldtch at openjdk.org  Thu Feb 15 10:25:21 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 15 Feb 2024 10:25:21 GMT
Subject: RFR: 8319801: Recursive lightweight locking: aarch64
 implementation [v19]
In-Reply-To: <AE1nsnyRCUHR970jjg4feUm5f6E1GPJvea0ooC6dCgI=.73fff610-c0f6-422a-a45d-88187b37b9a2@github.com>
References: <AE1nsnyRCUHR970jjg4feUm5f6E1GPJvea0ooC6dCgI=.73fff610-c0f6-422a-a45d-88187b37b9a2@github.com>
Message-ID: <_tgqW432lHQOEre0xCE4U7OBoXoNUoWBtDZ0nHxJwV4=.507d9fb9-cf25-43ab-9c73-7c251f534996@github.com>

> Implements the aarch64 port of JDK-8319796.
> 
> There are two major parts for the port implementation. The C2 part, and the part shared by the interpreter, C1 and the native call wrapper.
> 
> The biggest change for both parts is that we check the lock stack first and if it is a recursive lightweight [un]lock and in that case simply pop/push and finish successfully.
> 
> Only if the recursive lightweight [un]lock fails does it look at the mark word. 
> 
> For the shared part if it is an unstructured exit, the monitor is inflated or the mark word transition fails it calls into the runtime.
> 
> The C2 operates under a few more assumptions, that the locking is structured and balanced. This means that some checks can be elided. 
> 
> First this means that in C2 unlock if the obj is not on the top of the lock stack, it must be inflated. And reversely if we reach the inflated C2 unlock the obj is not on the lock stack. This second property makes it possible to avoid reading the owner (and checking if it is anonymous). Instead it can either just do an un-contended unlock by writing null to the owner, or if contention happens, simply write the thread to the owner and jump to the runtime. 
> 
> The aarch64 C2 port tries to avoid stronger memory semantics where ever possible. In C2 lock it first does a relaxed load of the mark word to check for inflation. Both lock and unlock uses a load/store exclusive register pair to transition the mark word.

Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:

  Add common prefix for aliased Register variables

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16608/files
  - new: https://git.openjdk.org/jdk/pull/16608/files/0ac730fd..c73760d5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16608&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16608&range=17-18

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

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

From ayang at openjdk.org  Thu Feb 15 10:44:06 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 15 Feb 2024 10:44:06 GMT
Subject: RFR: 8305898: Alternative self-forwarding mechanism [v4]
In-Reply-To: <OC2HtdWXXKiV3OLkz39XVG7bickA31IZZVgpZpZy3GU=.04506b71-994c-4dc6-a39f-cf0d0c908977@github.com>
References: <N4eX8S-btv0VD19kl2W9RigVsaw58ZVXDZllFwykZ04=.a9456aa8-b294-480a-b7f0-07616c972f62@github.com>
 <OC2HtdWXXKiV3OLkz39XVG7bickA31IZZVgpZpZy3GU=.04506b71-994c-4dc6-a39f-cf0d0c908977@github.com>
Message-ID: <jLZhC17VXX8O-NCXl7E-P8oOJx9Zqye7i7tgPJGWuqg=.b78f4e67-d5b3-42a0-8710-7c75d04a98da@github.com>

On Thu, 8 Feb 2024 14:37:20 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Currently, the Serial, Parallel and G1 GCs store a pointer to self into object headers to indicate promotion failure. This is problematic for compact object headers ([JDK-8294992](https://bugs.openjdk.org/browse/JDK-8294992)) because it would (temporarily) over-write the crucial class information, which we need for heap parsing. I would like to propose an alternative: use the currently unused 3rd header bit (previously biased-locking bit) to indicate that an object is 'self-forwarded'. That preserves the crucial class information in the upper bits of the header until the full header gets restored.
>> 
>> This is a trimmed-down/simplified version of the original proposal #13779:
>>  - It doesn't use/introduce any flags and avoids the associated branching.
>>  - It doesn't (need to) deal with displaced headers. (Current code would preserve header if necessary, Lilliput code would not use displaced headers and set the 3rd bit directly in existing header.)
>> 
>> Testing:
>>  - [x] hotspot_gc
>>  - [x] tier1
>>  - [x] tier2
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More consistent use of markWord::is_forwarded()

test/hotspot/gtest/gc/shared/test_preservedMarks.cpp line 35:

> 33:   // could be interpreted as 'self-forwarded' when encoded as
> 34:   // forwardee in the mark-word.
> 35:   alignas(BytesPerLong) oopDesc _oop;

Could you explain why this is required? (I'd expect `oopDesc` to be properly aligned already, since it's >= 8 bytes.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17755#discussion_r1490797376

From rkennke at openjdk.org  Thu Feb 15 11:04:06 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 15 Feb 2024 11:04:06 GMT
Subject: RFR: 8305898: Alternative self-forwarding mechanism [v4]
In-Reply-To: <jLZhC17VXX8O-NCXl7E-P8oOJx9Zqye7i7tgPJGWuqg=.b78f4e67-d5b3-42a0-8710-7c75d04a98da@github.com>
References: <N4eX8S-btv0VD19kl2W9RigVsaw58ZVXDZllFwykZ04=.a9456aa8-b294-480a-b7f0-07616c972f62@github.com>
 <OC2HtdWXXKiV3OLkz39XVG7bickA31IZZVgpZpZy3GU=.04506b71-994c-4dc6-a39f-cf0d0c908977@github.com>
 <jLZhC17VXX8O-NCXl7E-P8oOJx9Zqye7i7tgPJGWuqg=.b78f4e67-d5b3-42a0-8710-7c75d04a98da@github.com>
Message-ID: <3-0BT7lKveQeoigS1TvKSBVJRfCjZ1sWahI_AJq_-IA=.59ec7de4-908c-4ea0-888d-dd858a997532@github.com>

On Thu, 15 Feb 2024 10:41:23 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More consistent use of markWord::is_forwarded()
>
> test/hotspot/gtest/gc/shared/test_preservedMarks.cpp line 35:
> 
>> 33:   // could be interpreted as 'self-forwarded' when encoded as
>> 34:   // forwardee in the mark-word.
>> 35:   alignas(BytesPerLong) oopDesc _oop;
> 
> Could you explain why this is required? (I'd expect `oopDesc` to be properly aligned already, since it's >= 8 bytes.)

This is a problem with x86_32 builds, where oopDesc is only 4 byte. It is only a problem in this test, in real world, objects in the heap are always at least 8-byte-aligned.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17755#discussion_r1490827573

From rkennke at openjdk.org  Thu Feb 15 11:46:39 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 15 Feb 2024 11:46:39 GMT
Subject: RFR: 8139457: Relax alignment of array elements [v64]
In-Reply-To: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
References: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
Message-ID: <L1FV4XUdDi491n22aiCfjk8SrnIJHYeDEQf2u2aY4i8=.6f73b2a6-8e7f-4f69-9d07-c2425ad484f3@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 with a new target base due to a merge or a rebase. The pull request now contains 93 commits:

 - Merge branch 'master' into JDK-8139457
 - Merge remote-tracking branch 'upstream/master' into JDK-8139457
 - Update copyright headers
 - Merge branch 'master' into JDK-8139457
 - Fix ARM build
 - Merge remote-tracking branch 'upstream/master' into JDK-8139457
 - Various cleanups
 - RISC changes
 - Move gap init into allocate_header() (x86)
 - Fix gtest failure on x86
 - ... and 83 more: https://git.openjdk.org/jdk/compare/a0e5e16a...d0ec1fa2

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

Changes: https://git.openjdk.org/jdk/pull/11044/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=63
  Stats: 628 lines in 33 files changed: 478 ins; 83 del; 67 mod
  Patch: https://git.openjdk.org/jdk/pull/11044.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/11044/head:pull/11044

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

From sspitsyn at openjdk.org  Thu Feb 15 11:49:07 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 15 Feb 2024 11:49:07 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v4]
In-Reply-To: <2iPk6kfykXqnv2hTa6GyvRTcI71om0C6X3Z0bZZMaOM=.1b6f9718-dc85-4b09-8cb1-5d53f1cb0a36@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <bKkHh3R39JCXKuQGrduWdZhJ9jstNA6xfUnJgPgbslE=.c1e27529-af8c-4707-9d24-473952502459@github.com>
 <5DPYtNaOL_44RemEpOUvNCJYISxC2bfUHakk7FVIj9k=.bd8baf61-bcf1-4c92-b31a-ef048e9dc64c@github.com>
 <dgTO2rNUQS0JvaHUtfifHa74B68HXzG0pC6dvT6QkKU=.b1930c72-90f6-4cb5-a070-35278d137a66@github.com>
 <2iPk6kfykXqnv2hTa6GyvRTcI71om0C6X3Z0bZZMaOM=.1b6f9718-dc85-4b09-8cb1-5d53f1cb0a36@github.com>
Message-ID: <hlSJ4q2THpm1UCnikxTwn0BDbG85uiUL1tbDJLP8I_0=.d16214b8-f769-4222-aa4c-d04f9e78b8b3@github.com>

On Wed, 14 Feb 2024 01:52:16 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Thank you for the comment, David.
>> Now the test checks:
>> - the threads waiting to enter the monitor are returned correctly with all permutations of threads waiting to be notified and threads waiting to re-enter the monitor
>> Initially, there are 4 threads waiting to be notified and zero threads waiting to re-enter the monitor.
>> They are notified one by with the subsequent checks, so all the pairs are checked `<re-enter,wait-for-notif>`: `<0,4>, <1,3>, <2,2>, <3,1>, <4,0>`
>> 
>> I'm not sure why do you think all permutations covering zero and non-zero for each one are needed.
>> At least, it looks like an overkill to me. But if you still think it is really important then I can add cases with zero threads waiting to enter the monitor with the same permutations of threads waiting to be notified and threads re-entering the monitor.
>
> If you don't check all the zero/non-zero permutations for the three counts of interest then you don't know that you are combining them the right way to give the two counts reported by the API.
> Note that checking "all the pairs" is not really necessary as all non-zero values fall in the same equivalence class for testing purposes.

The last suggestion has been addressed by adding missing test cases to the `nsk/jvmti/GetObjectMonitorUsage/objmonusage003` test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1490889210

From tschatzl at openjdk.org  Thu Feb 15 11:49:07 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 15 Feb 2024 11:49:07 GMT
Subject: RFR: 8305898: Alternative self-forwarding mechanism [v4]
In-Reply-To: <OC2HtdWXXKiV3OLkz39XVG7bickA31IZZVgpZpZy3GU=.04506b71-994c-4dc6-a39f-cf0d0c908977@github.com>
References: <N4eX8S-btv0VD19kl2W9RigVsaw58ZVXDZllFwykZ04=.a9456aa8-b294-480a-b7f0-07616c972f62@github.com>
 <OC2HtdWXXKiV3OLkz39XVG7bickA31IZZVgpZpZy3GU=.04506b71-994c-4dc6-a39f-cf0d0c908977@github.com>
Message-ID: <rZm-uQH9cUKf7rm_Atb1esbS6Z13QJyOsw0krqHYImk=.77c2dde6-bf9d-4c43-beb3-bb1d704343e6@github.com>

On Thu, 8 Feb 2024 14:37:20 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Currently, the Serial, Parallel and G1 GCs store a pointer to self into object headers to indicate promotion failure. This is problematic for compact object headers ([JDK-8294992](https://bugs.openjdk.org/browse/JDK-8294992)) because it would (temporarily) over-write the crucial class information, which we need for heap parsing. I would like to propose an alternative: use the currently unused 3rd header bit (previously biased-locking bit) to indicate that an object is 'self-forwarded'. That preserves the crucial class information in the upper bits of the header until the full header gets restored.
>> 
>> This is a trimmed-down/simplified version of the original proposal #13779:
>>  - It doesn't use/introduce any flags and avoids the associated branching.
>>  - It doesn't (need to) deal with displaced headers. (Current code would preserve header if necessary, Lilliput code would not use displaced headers and set the 3rd bit directly in existing header.)
>> 
>> Testing:
>>  - [x] hotspot_gc
>>  - [x] tier1
>>  - [x] tier2
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More consistent use of markWord::is_forwarded()

Please close out PR#13779.

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

PR Review: https://git.openjdk.org/jdk/pull/17755#pullrequestreview-1882570944

From tschatzl at openjdk.org  Thu Feb 15 11:52:56 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 15 Feb 2024 11:52:56 GMT
Subject: RFR: 8325752: Remove badMetaWordVal
In-Reply-To: <v1BkRnvyaYCtHUIacFVTKCksyhfsztbOagcblclKqbo=.80fd7a70-bd50-4428-af18-c6a4495f8ea6@github.com>
References: <v1BkRnvyaYCtHUIacFVTKCksyhfsztbOagcblclKqbo=.80fd7a70-bd50-4428-af18-c6a4495f8ea6@github.com>
Message-ID: <38n2Y3UptnUxUcUDv2CdifG6d5J62ATcBmWN6oy9UVw=.a19fa2ef-b219-49f2-af44-ffba03be7892@github.com>

On Tue, 13 Feb 2024 14:53:23 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> This is another artifact from the permgen removal. At some point we used to zap Metaspace with badMetaWordVal, but we don't do that anymore and therefore we should stop looking for this value.

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17833#pullrequestreview-1882578969

From rkennke at openjdk.org  Thu Feb 15 12:01:15 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 15 Feb 2024 12:01:15 GMT
Subject: RFR: 8139457: Relax alignment of array elements [v64]
In-Reply-To: <L1FV4XUdDi491n22aiCfjk8SrnIJHYeDEQf2u2aY4i8=.6f73b2a6-8e7f-4f69-9d07-c2425ad484f3@github.com>
References: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
 <L1FV4XUdDi491n22aiCfjk8SrnIJHYeDEQf2u2aY4i8=.6f73b2a6-8e7f-4f69-9d07-c2425ad484f3@github.com>
Message-ID: <ygzPDGiSun6ygSn9sGKzNwazeoN-rK9qeVDHXzZttWQ=.1dd934ca-cdca-4f0a-9705-32589fe044aa@github.com>

On Thu, 15 Feb 2024 11:46:39 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details.
>> 
>> Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements.
>> 
>> Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16.
>> 
>> Testing:
>>  - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390)
>>  - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390)
>>  - [x] tier1 (x86_64, x86_32, aarch64, riscv)
>>  - [x] tier2 (x86_64, aarch64, riscv)
>>  - [x] tier3 (x86_64, riscv)
>
> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 93 commits:
> 
>  - Merge branch 'master' into JDK-8139457
>  - Merge remote-tracking branch 'upstream/master' into JDK-8139457
>  - Update copyright headers
>  - Merge branch 'master' into JDK-8139457
>  - Fix ARM build
>  - Merge remote-tracking branch 'upstream/master' into JDK-8139457
>  - Various cleanups
>  - RISC changes
>  - Move gap init into allocate_header() (x86)
>  - Fix gtest failure on x86
>  - ... and 83 more: https://git.openjdk.org/jdk/compare/a0e5e16a...d0ec1fa2

CSR for this has been approved. I merged latest JDK code into the PR without conflicts. I am currently re-running tier1 and 2 tests with -CCP. Release note is in progress.
Is there anything else that needs to be done? @coleenp @stefank do you want to have another chance to review or run mach5 tests before I intergrate this?

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

PR Comment: https://git.openjdk.org/jdk/pull/11044#issuecomment-1945955229

From jkratochvil at openjdk.org  Thu Feb 15 12:18:17 2024
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Thu, 15 Feb 2024 12:18:17 GMT
Subject: RFR: 8317697: refactor-encapsulate x86 VM_Version::CpuidInfo [v4]
In-Reply-To: <JmIOcendwRGLAVKOQ4bFrDxwNVgt1KY5LKJ-Vz-SBjg=.edcccbcb-346c-4063-b75f-09d337fa9f66@github.com>
References: <JmIOcendwRGLAVKOQ4bFrDxwNVgt1KY5LKJ-Vz-SBjg=.edcccbcb-346c-4063-b75f-09d337fa9f66@github.com>
Message-ID: <ioaANin14rJBVL0cwwLg79zVULcK5IbFbbBfzpcl_GY=.1c2fb0ac-d8d5-4a04-b488-7e9e93e288bf@github.com>

> In OpenJDK project CRaC I had a [need to fetch new CpuidInfo without affecting the existing one](https://github.com/openjdk/crac/commit/ed4ad9ba31b77732dcede2eb743b2f389ec9a0fe#diff-6ed856c57ddbe33e49883adb7c52ec51ed377e5f697dfd6d8bea505a97bfc5a5R2743).
> Which led me to encapsulate the object more and I think this no-functionality-change patch is even appropriate for JDK.
> I am sure interested primarily to reduce the CRaC patchset boilerplate.

Jan Kratochvil has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge branch 'master' into flagsencaps
 - Remove the automatic zero-initialization
 - Make CpuidInfo a class
 - Merge branch 'master' into flagsencaps
 - 8317697: refactor-encapsulate x86 VM_Version::CpuidInfo

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

Changes: https://git.openjdk.org/jdk/pull/16093/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16093&range=03
  Stats: 125 lines in 2 files changed: 30 ins; 23 del; 72 mod
  Patch: https://git.openjdk.org/jdk/pull/16093.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16093/head:pull/16093

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

From stuefe at openjdk.org  Thu Feb 15 12:25:03 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 15 Feb 2024 12:25:03 GMT
Subject: RFR: 8325932: Replace ATTRIBUTE_NORETURN with direct [[noreturn]]
In-Reply-To: <tTaR4IXFQKtg9-tmJ-JAC4hfHNxB8rMhEyl5uxHOh7A=.33c5a2dd-a760-43eb-8518-c066786ec72d@github.com>
References: <tTaR4IXFQKtg9-tmJ-JAC4hfHNxB8rMhEyl5uxHOh7A=.33c5a2dd-a760-43eb-8518-c066786ec72d@github.com>
Message-ID: <-Ft3Juynh6QgMRnybyD6uprCsPqVaVyIdZxpJ9FsYV0=.31aa271d-ce7f-434f-a8ce-f1e914559a4b@github.com>

On Thu, 15 Feb 2024 09:10:51 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> We should remove the workaround as soon as possible, given the chance.

Why the hurry?

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

PR Comment: https://git.openjdk.org/jdk/pull/17868#issuecomment-1945991815

From ihse at openjdk.org  Thu Feb 15 12:29:23 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 15 Feb 2024 12:29:23 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck
Message-ID: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>

Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes).

I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base.

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

Commit messages:
 - 8325950: Make sure all files in the JDK pass jcheck

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

PR: https://git.openjdk.org/jdk/pull/17871

From ihse at openjdk.org  Thu Feb 15 12:29:24 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 15 Feb 2024 12:29:24 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck
In-Reply-To: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
Message-ID: <Ksqjgi78ueQiu4oDhQ2d2wVT7a9bBAoMDGQ3CZnxH3Q=.ac125065-25c8-4c8c-b66b-c86f7523203b@github.com>

On Thu, 15 Feb 2024 12:19:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes).
> 
> I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base.

Some general remarks: The problems in .m4 files where not properly detected and fixed when I added .m4 to the list of checked files. The properties files were recently checked by me, so these suprrised me. It turned out I had misunderstood the jcheck criteria: I thought only leading tabs were disallowed, but it is actually tabs anywhere in the file that are banned.

In general, I have replaced tab characters with spaces aligning to tab stops at 8 characters distance. 

I'll leave some remarks for individual files.

src/java.naming/share/classes/com/sun/jndi/ldap/jndiprovider.properties line 10:

> 8: java.naming.factory.object=com.sun.jndi.ldap.obj.AttrsToCorba:com.sun.jndi.ldap.obj.MarshalledToObject
> 9: 
> 10: # RemoteToAttrs: Turn RMI/JRMP and RMI/IIOP object into javaMarshalledObject or

I adjusted this tab stop (with one space) so it aligned properly with the line above; I think that was the intention.

src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdkinternals.properties line 41:

> 39: jdk.internal.ref.Cleaner=Use java.lang.ref.PhantomReference @since 1.2 or java.lang.ref.Cleaner @since 9
> 40: sun.awt.CausedFocusEvent=Use java.awt.event.FocusEvent::getCause @since 9
> 41: sun.font.FontUtilities=See java.awt.Font.textRequiresLayout	@since 9

This tab just looked out of place, so I replaced it with a space. (Rhyming not intentional...)

test/hotspot/jtreg/containers/docker/JfrReporter.java line 52:

> 50:             }
> 51:         }
> 52:     }

I'm not sure how a Java file ever got into the code base with trailing spaces, but a guess is that there have been a bug in jcheck that did not properly check for trailing whitespace at the end of the file, or something like that.

test/jdk/java/util/Currency/currency.properties line 18:

> 16: SB=EUR,111,2, 2099-01-01T00:00:00
> 17: US=euR,978,2,2001-01-01T00:00:00
> 18: ZZ	=	ZZZ	,	999	,	3

This looks weird, but so did the original code. I assume this is to clearly indicate this as a end of list marker.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17871#issuecomment-1945992837
PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1490931378
PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1490931979
PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1490933432
PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1490934063

From stuefe at openjdk.org  Thu Feb 15 13:04:07 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 15 Feb 2024 13:04:07 GMT
Subject: RFR: 8314488: Compile the JDK as C++17 [v6]
In-Reply-To: <b4HhbT5caIfCbrVveI6NDObiwUI2Sr0so68JBG6C0YU=.1734aaa7-aed4-478c-bbb6-de9af5c04ef9@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
 <b4HhbT5caIfCbrVveI6NDObiwUI2Sr0so68JBG6C0YU=.1734aaa7-aed4-478c-bbb6-de9af5c04ef9@github.com>
Message-ID: <Wx3S6B4fUk9k1Rez__mXIHAGYuNjPw8FqqoLxyzlK2Y=.f0a77d7e-6544-4601-a7ed-61556cb4c312@github.com>

On Thu, 11 Jan 2024 13:23:45 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Compile the JDK as C++17, enabling the use of all C++17 language features
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Require clang 13 in toolchain.m4

Just on a general note:

I would like it if toolchain version bumps were discussed somewhere else first, not in a PR. (And apologies if it was and I missed that discussion). Because PRs are usually followed only by active developers, but toolchain versions affect a broader part of the community. As we have seen in this PR, there are conflicting interests.

We have things like CSRs and JEPs. Both are not ideal - a JEP is way too massive, and a CSR is about the compatibility of the product, not about build-time. Still, maybe something like a CSR would make sense here.

I understand that with toolchain support, there will always be opposing parties, and I can see arguments on both sides. We don't want to end up like FreeBSD - stuck in time because of opinion stalemates. I just keep thinking that a PR is maybe not the perfect forum for this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1946053820

From ayang at openjdk.org  Thu Feb 15 13:52:56 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 15 Feb 2024 13:52:56 GMT
Subject: RFR: 8305898: Alternative self-forwarding mechanism [v4]
In-Reply-To: <3-0BT7lKveQeoigS1TvKSBVJRfCjZ1sWahI_AJq_-IA=.59ec7de4-908c-4ea0-888d-dd858a997532@github.com>
References: <N4eX8S-btv0VD19kl2W9RigVsaw58ZVXDZllFwykZ04=.a9456aa8-b294-480a-b7f0-07616c972f62@github.com>
 <OC2HtdWXXKiV3OLkz39XVG7bickA31IZZVgpZpZy3GU=.04506b71-994c-4dc6-a39f-cf0d0c908977@github.com>
 <jLZhC17VXX8O-NCXl7E-P8oOJx9Zqye7i7tgPJGWuqg=.b78f4e67-d5b3-42a0-8710-7c75d04a98da@github.com>
 <3-0BT7lKveQeoigS1TvKSBVJRfCjZ1sWahI_AJq_-IA=.59ec7de4-908c-4ea0-888d-dd858a997532@github.com>
Message-ID: <gKFy4NGUbQTIAnxu4BNn4UP0HzxJCb85pn6EWf1fmfc=.c2128e2a-be2d-42a1-a810-822e7476ba35@github.com>

On Thu, 15 Feb 2024 11:00:52 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> test/hotspot/gtest/gc/shared/test_preservedMarks.cpp line 35:
>> 
>>> 33:   // could be interpreted as 'self-forwarded' when encoded as
>>> 34:   // forwardee in the mark-word.
>>> 35:   alignas(BytesPerLong) oopDesc _oop;
>> 
>> Could you explain why this is required? (I'd expect `oopDesc` to be properly aligned already, since it's >= 8 bytes.)
>
> This is a problem with x86_32 builds, where oopDesc is only 4 byte. It is only a problem in this test, in real world, objects in the heap are always at least 8-byte-aligned.

Even on 32bits system, shouldn't `_mark` = 4 bytes and `_metadata` = 4 bytes, so the total size of `oopDesc` is 8 bytes?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17755#discussion_r1491039970

From erikj at openjdk.org  Thu Feb 15 14:05:12 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 15 Feb 2024 14:05:12 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck
In-Reply-To: <Ksqjgi78ueQiu4oDhQ2d2wVT7a9bBAoMDGQ3CZnxH3Q=.ac125065-25c8-4c8c-b66b-c86f7523203b@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
 <Ksqjgi78ueQiu4oDhQ2d2wVT7a9bBAoMDGQ3CZnxH3Q=.ac125065-25c8-4c8c-b66b-c86f7523203b@github.com>
Message-ID: <C2_NdHV3EpjVwEflvV6QcNdno8BgU9P3p2YZf1mQ3E8=.9e447ca9-8d6d-4ef4-9d99-14bd10d1c92e@github.com>

On Thu, 15 Feb 2024 12:26:11 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes).
>> 
>> I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base.
>
> test/jdk/java/util/Currency/currency.properties line 18:
> 
>> 16: SB=EUR,111,2, 2099-01-01T00:00:00
>> 17: US=euR,978,2,2001-01-01T00:00:00
>> 18: ZZ	=	ZZZ	,	999	,	3
> 
> This looks weird, but so did the original code. I assume this is to clearly indicate this as a end of list marker.

This looks weird indeed. Luckily it's just test code. Did you run the test after this change?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1491056108

From aboldtch at openjdk.org  Thu Feb 15 14:10:56 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 15 Feb 2024 14:10:56 GMT
Subject: RFR: 8305898: Alternative self-forwarding mechanism [v4]
In-Reply-To: <gKFy4NGUbQTIAnxu4BNn4UP0HzxJCb85pn6EWf1fmfc=.c2128e2a-be2d-42a1-a810-822e7476ba35@github.com>
References: <N4eX8S-btv0VD19kl2W9RigVsaw58ZVXDZllFwykZ04=.a9456aa8-b294-480a-b7f0-07616c972f62@github.com>
 <OC2HtdWXXKiV3OLkz39XVG7bickA31IZZVgpZpZy3GU=.04506b71-994c-4dc6-a39f-cf0d0c908977@github.com>
 <jLZhC17VXX8O-NCXl7E-P8oOJx9Zqye7i7tgPJGWuqg=.b78f4e67-d5b3-42a0-8710-7c75d04a98da@github.com>
 <3-0BT7lKveQeoigS1TvKSBVJRfCjZ1sWahI_AJq_-IA=.59ec7de4-908c-4ea0-888d-dd858a997532@github.com>
 <gKFy4NGUbQTIAnxu4BNn4UP0HzxJCb85pn6EWf1fmfc=.c2128e2a-be2d-42a1-a810-822e7476ba35@github.com>
Message-ID: <ETy54UUUir6e8SMOXMUxOlIJCA8m5gTKIqhXU2ygh2E=.5e1a7c18-2eb9-4cad-936c-d1c53104cdc2@github.com>

On Thu, 15 Feb 2024 13:50:39 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This is a problem with x86_32 builds, where oopDesc is only 4 byte. It is only a problem in this test, in real world, objects in the heap are always at least 8-byte-aligned.
>
> Even on 32bits system, shouldn't `_mark` = 4 bytes and `_metadata` = 4 bytes, so the total size of `oopDesc` is 8 bytes?

The alignment of a struct must just ensure that the alignments requirement of its fields are satisfied (in the general case) So a struct of two 4 byte ints will have an `alignof` 4 bytes and a `sizeof` 8 bytes
```c++
#include <cstdint>
struct S {
    uint32_t a;
    uint32_t b;
};

static_assert(alignof(S) == 4);
static_assert(sizeof(S) == 8);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17755#discussion_r1491064467

From ayang at openjdk.org  Thu Feb 15 14:34:54 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 15 Feb 2024 14:34:54 GMT
Subject: RFR: 8305898: Alternative self-forwarding mechanism [v4]
In-Reply-To: <ETy54UUUir6e8SMOXMUxOlIJCA8m5gTKIqhXU2ygh2E=.5e1a7c18-2eb9-4cad-936c-d1c53104cdc2@github.com>
References: <N4eX8S-btv0VD19kl2W9RigVsaw58ZVXDZllFwykZ04=.a9456aa8-b294-480a-b7f0-07616c972f62@github.com>
 <OC2HtdWXXKiV3OLkz39XVG7bickA31IZZVgpZpZy3GU=.04506b71-994c-4dc6-a39f-cf0d0c908977@github.com>
 <jLZhC17VXX8O-NCXl7E-P8oOJx9Zqye7i7tgPJGWuqg=.b78f4e67-d5b3-42a0-8710-7c75d04a98da@github.com>
 <3-0BT7lKveQeoigS1TvKSBVJRfCjZ1sWahI_AJq_-IA=.59ec7de4-908c-4ea0-888d-dd858a997532@github.com>
 <gKFy4NGUbQTIAnxu4BNn4UP0HzxJCb85pn6EWf1fmfc=.c2128e2a-be2d-42a1-a810-822e7476ba35@github.com>
 <ETy54UUUir6e8SMOXMUxOlIJCA8m5gTKIqhXU2ygh2E=.5e1a7c18-2eb9-4cad-936c-d1c53104cdc2@github.com>
Message-ID: <Ntc5Aj7rFb6KRgbF7Q6IgXFICzQ9ObaThmXrZPd4npk=.0673bb85-36d4-4c6b-851c-92674cb21377@github.com>

On Thu, 15 Feb 2024 14:08:00 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Even on 32bits system, shouldn't `_mark` = 4 bytes and `_metadata` = 4 bytes, so the total size of `oopDesc` is 8 bytes?
>
> The alignment of a struct must just ensure that the alignments requirement of its fields are satisfied (in the general case) So a struct of two 4 byte ints will have an `alignof` 4 bytes and a `sizeof` 8 bytes
> ```c++
> #include <cstdint>
> struct S {
>     uint32_t a;
>     uint32_t b;
> };
> 
> static_assert(alignof(S) == 4);
> static_assert(sizeof(S) == 8);

Thank you for the explanation; I mistakenly thought a struct is aligned to its size...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17755#discussion_r1491107746

From ayang at openjdk.org  Thu Feb 15 14:41:57 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 15 Feb 2024 14:41:57 GMT
Subject: RFR: 8305898: Alternative self-forwarding mechanism [v4]
In-Reply-To: <OC2HtdWXXKiV3OLkz39XVG7bickA31IZZVgpZpZy3GU=.04506b71-994c-4dc6-a39f-cf0d0c908977@github.com>
References: <N4eX8S-btv0VD19kl2W9RigVsaw58ZVXDZllFwykZ04=.a9456aa8-b294-480a-b7f0-07616c972f62@github.com>
 <OC2HtdWXXKiV3OLkz39XVG7bickA31IZZVgpZpZy3GU=.04506b71-994c-4dc6-a39f-cf0d0c908977@github.com>
Message-ID: <5fNErcF66u3PIk_Mp2dfykFhNy-c2QsfGA0MnA-HXKE=.8d9f6e3e-08d5-4bb8-b0ef-2f0767ef3e9d@github.com>

On Thu, 8 Feb 2024 14:37:20 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Currently, the Serial, Parallel and G1 GCs store a pointer to self into object headers to indicate promotion failure. This is problematic for compact object headers ([JDK-8294992](https://bugs.openjdk.org/browse/JDK-8294992)) because it would (temporarily) over-write the crucial class information, which we need for heap parsing. I would like to propose an alternative: use the currently unused 3rd header bit (previously biased-locking bit) to indicate that an object is 'self-forwarded'. That preserves the crucial class information in the upper bits of the header until the full header gets restored.
>> 
>> This is a trimmed-down/simplified version of the original proposal #13779:
>>  - It doesn't use/introduce any flags and avoids the associated branching.
>>  - It doesn't (need to) deal with displaced headers. (Current code would preserve header if necessary, Lilliput code would not use displaced headers and set the 3rd bit directly in existing header.)
>> 
>> Testing:
>>  - [x] hotspot_gc
>>  - [x] tier1
>>  - [x] tier2
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More consistent use of markWord::is_forwarded()

Marked as reviewed by ayang (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17755#pullrequestreview-1882965500

From ihse at openjdk.org  Thu Feb 15 15:50:57 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 15 Feb 2024 15:50:57 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck
In-Reply-To: <C2_NdHV3EpjVwEflvV6QcNdno8BgU9P3p2YZf1mQ3E8=.9e447ca9-8d6d-4ef4-9d99-14bd10d1c92e@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
 <Ksqjgi78ueQiu4oDhQ2d2wVT7a9bBAoMDGQ3CZnxH3Q=.ac125065-25c8-4c8c-b66b-c86f7523203b@github.com>
 <C2_NdHV3EpjVwEflvV6QcNdno8BgU9P3p2YZf1mQ3E8=.9e447ca9-8d6d-4ef4-9d99-14bd10d1c92e@github.com>
Message-ID: <osmSAGyuE-qyC6sjVT_UjfRd2CfUQHuKFjlvmDOW-3Y=.b8a009f9-e995-42e7-afed-af83a016ff2b@github.com>

On Thu, 15 Feb 2024 14:01:46 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> test/jdk/java/util/Currency/currency.properties line 18:
>> 
>>> 16: SB=EUR,111,2, 2099-01-01T00:00:00
>>> 17: US=euR,978,2,2001-01-01T00:00:00
>>> 18: ZZ	=	ZZZ	,	999	,	3
>> 
>> This looks weird, but so did the original code. I assume this is to clearly indicate this as a end of list marker.
>
> This looks weird indeed. Luckily it's just test code. Did you run the test after this change?

All the java/util/Currency tests pass. I also searched the code for "ZZ" but could not find any references in the test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1491227492

From ihse at openjdk.org  Thu Feb 15 15:57:57 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 15 Feb 2024 15:57:57 GMT
Subject: RFR: 8314488: Compile the JDK as C++17 [v6]
In-Reply-To: <Wx3S6B4fUk9k1Rez__mXIHAGYuNjPw8FqqoLxyzlK2Y=.f0a77d7e-6544-4601-a7ed-61556cb4c312@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
 <b4HhbT5caIfCbrVveI6NDObiwUI2Sr0so68JBG6C0YU=.1734aaa7-aed4-478c-bbb6-de9af5c04ef9@github.com>
 <Wx3S6B4fUk9k1Rez__mXIHAGYuNjPw8FqqoLxyzlK2Y=.f0a77d7e-6544-4601-a7ed-61556cb4c312@github.com>
Message-ID: <UJpm6tMqM1HHSg7Za-n0sHCZdMl5u6r3anC7Cty6VAQ=.000fac5d-00d6-4c71-846b-4c1aeedf4c70@github.com>

On Thu, 15 Feb 2024 13:00:58 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> I would like it if toolchain version bumps were discussed somewhere else first, not in a PR. (And apologies if it was and I missed that discussion). 

Yes, it definitely was. I posted a separate [mail to build-dev](https://mail.openjdk.org/pipermail/build-dev/2024-January/042802.html) with subject "Raising the minimum version of gcc, clang and xlc". I don't think we can make it more clear than that.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1946388775

From stuefe at openjdk.org  Thu Feb 15 16:01:57 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 15 Feb 2024 16:01:57 GMT
Subject: RFR: 8314488: Compile the JDK as C++17 [v6]
In-Reply-To: <UJpm6tMqM1HHSg7Za-n0sHCZdMl5u6r3anC7Cty6VAQ=.000fac5d-00d6-4c71-846b-4c1aeedf4c70@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
 <b4HhbT5caIfCbrVveI6NDObiwUI2Sr0so68JBG6C0YU=.1734aaa7-aed4-478c-bbb6-de9af5c04ef9@github.com>
 <Wx3S6B4fUk9k1Rez__mXIHAGYuNjPw8FqqoLxyzlK2Y=.f0a77d7e-6544-4601-a7ed-61556cb4c312@github.com>
 <UJpm6tMqM1HHSg7Za-n0sHCZdMl5u6r3anC7Cty6VAQ=.000fac5d-00d6-4c71-846b-4c1aeedf4c70@github.com>
Message-ID: <AXQxJs2SIwoi3xltheTzOwumeoCjvrcOc62WMOD9lnk=.7ba32dd8-680e-4cc0-8665-5ff90350eed9@github.com>

On Thu, 15 Feb 2024 15:54:56 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> > I would like it if toolchain version bumps were discussed somewhere else first, not in a PR. (And apologies if it was and I missed that discussion).
> 
> Yes, it definitely was. I posted a separate [mail to build-dev](https://mail.openjdk.org/pipermail/build-dev/2024-January/042802.html) with subject "Raising the minimum version of gcc, clang and xlc". I don't think we can make it more clear than that.

Okay, thank you for that clarification. I clearly missed it then.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1946396577

From aph at openjdk.org  Thu Feb 15 16:50:01 2024
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 15 Feb 2024 16:50:01 GMT
Subject: RFR: 8319801: Recursive lightweight locking: aarch64
 implementation [v19]
In-Reply-To: <_tgqW432lHQOEre0xCE4U7OBoXoNUoWBtDZ0nHxJwV4=.507d9fb9-cf25-43ab-9c73-7c251f534996@github.com>
References: <AE1nsnyRCUHR970jjg4feUm5f6E1GPJvea0ooC6dCgI=.73fff610-c0f6-422a-a45d-88187b37b9a2@github.com>
 <_tgqW432lHQOEre0xCE4U7OBoXoNUoWBtDZ0nHxJwV4=.507d9fb9-cf25-43ab-9c73-7c251f534996@github.com>
Message-ID: <OIeAt5pRE4QADEieh_HbB0rsj5EHf9N00_U62y_5FTE=.f49048ee-09da-40f0-9f80-077658695f7c@github.com>

On Thu, 15 Feb 2024 10:25:21 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Implements the aarch64 port of JDK-8319796.
>> 
>> There are two major parts for the port implementation. The C2 part, and the part shared by the interpreter, C1 and the native call wrapper.
>> 
>> The biggest change for both parts is that we check the lock stack first and if it is a recursive lightweight [un]lock and in that case simply pop/push and finish successfully.
>> 
>> Only if the recursive lightweight [un]lock fails does it look at the mark word. 
>> 
>> For the shared part if it is an unstructured exit, the monitor is inflated or the mark word transition fails it calls into the runtime.
>> 
>> The C2 operates under a few more assumptions, that the locking is structured and balanced. This means that some checks can be elided. 
>> 
>> First this means that in C2 unlock if the obj is not on the top of the lock stack, it must be inflated. And reversely if we reach the inflated C2 unlock the obj is not on the lock stack. This second property makes it possible to avoid reading the owner (and checking if it is anonymous). Instead it can either just do an un-contended unlock by writing null to the owner, or if contention happens, simply write the thread to the owner and jump to the runtime. 
>> 
>> The aarch64 C2 port tries to avoid stronger memory semantics where ever possible. In C2 lock it first does a relaxed load of the mark word to check for inflation. Both lock and unlock uses a load/store exclusive register pair to transition the mark word.
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add common prefix for aliased Register variables

OK, thank you.

-------------

Marked as reviewed by aph (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16608#pullrequestreview-1883339449

From forax at openjdk.org  Thu Feb 15 16:51:56 2024
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Thu, 15 Feb 2024 16:51:56 GMT
Subject: RFR: 8325932: Replace ATTRIBUTE_NORETURN with direct [[noreturn]]
In-Reply-To: <tTaR4IXFQKtg9-tmJ-JAC4hfHNxB8rMhEyl5uxHOh7A=.33c5a2dd-a760-43eb-8518-c066786ec72d@github.com>
References: <tTaR4IXFQKtg9-tmJ-JAC4hfHNxB8rMhEyl5uxHOh7A=.33c5a2dd-a760-43eb-8518-c066786ec72d@github.com>
Message-ID: <oGkSEoeds_LGbnO9UwckOaCTBQixrvguYQEnoF3G99U=.ff37acc1-4ee9-47ac-8db1-d33a05eca8d2@github.com>

On Thu, 15 Feb 2024 09:10:51 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> With clang 13 being the minimum required JDK-8325878, the noreturn bug that requires the ATTRIBUTE_NORETURN workaround now vanishes, and we can use [[noreturn]] directly within HotSpot. We should remove the workaround as soon as possible, given the chance

I believe "as soon as possible" should be "once JDK-8325878 is resolved" :)

Now, the reason to use [[noreturn]] instead of ATTRIBUTER_NORETURN macro is that IDEs recognize [[noreturn]] when doing static analysis on the code and that ATTRIBUTER_NORETURN was added as a workaround because a bug (crash) in clang < 12.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17868#issuecomment-1946562523

From jwaters at openjdk.org  Thu Feb 15 16:51:57 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 15 Feb 2024 16:51:57 GMT
Subject: RFR: 8325932: Replace ATTRIBUTE_NORETURN with direct [[noreturn]]
In-Reply-To: <oGkSEoeds_LGbnO9UwckOaCTBQixrvguYQEnoF3G99U=.ff37acc1-4ee9-47ac-8db1-d33a05eca8d2@github.com>
References: <tTaR4IXFQKtg9-tmJ-JAC4hfHNxB8rMhEyl5uxHOh7A=.33c5a2dd-a760-43eb-8518-c066786ec72d@github.com>
 <oGkSEoeds_LGbnO9UwckOaCTBQixrvguYQEnoF3G99U=.ff37acc1-4ee9-47ac-8db1-d33a05eca8d2@github.com>
Message-ID: <6yCOkWYJwt9x9CGS_LC_I5DKbazB5M5eksS220jxfwE=.a691969a-58f7-426b-a257-6ff05c1d5b76@github.com>

On Thu, 15 Feb 2024 16:47:21 GMT, R?mi Forax <forax at openjdk.org> wrote:

> I believe "as soon as possible" should be "once JDK-8325878 is resolved" :)
> 
> Now, the reason to use [[noreturn]] instead of ATTRIBUTER_NORETURN macro is that IDEs recognize [[noreturn]] when doing static analysis on the code and that ATTRIBUTER_NORETURN was added as a workaround because a bug (crash) in clang < 12.

Yes, I forgot to mention that this is only going in once the clang 13 requirement is integrated

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17868#issuecomment-1946566776

From naoto at openjdk.org  Thu Feb 15 17:12:55 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 Feb 2024 17:12:55 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck
In-Reply-To: <osmSAGyuE-qyC6sjVT_UjfRd2CfUQHuKFjlvmDOW-3Y=.b8a009f9-e995-42e7-afed-af83a016ff2b@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
 <Ksqjgi78ueQiu4oDhQ2d2wVT7a9bBAoMDGQ3CZnxH3Q=.ac125065-25c8-4c8c-b66b-c86f7523203b@github.com>
 <C2_NdHV3EpjVwEflvV6QcNdno8BgU9P3p2YZf1mQ3E8=.9e447ca9-8d6d-4ef4-9d99-14bd10d1c92e@github.com>
 <osmSAGyuE-qyC6sjVT_UjfRd2CfUQHuKFjlvmDOW-3Y=.b8a009f9-e995-42e7-afed-af83a016ff2b@github.com>
Message-ID: <oX6tKgqTMzsDdSFj-X-EXtJS-20BsyiMYBacmxBTzTk=.b6eb0e9d-9940-479e-b70b-75a446e43e1c@github.com>

On Thu, 15 Feb 2024 15:48:38 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This looks weird indeed. Luckily it's just test code. Did you run the test after this change?
>
> All the java/util/Currency tests pass. I also searched the code for "ZZ" but could not find any references in the test.

Please do not replace those tabs with spaces as they are intentional for testing the runtime to safely ignore them. I suggest replacing them with Unicode escapes (`\u000b`)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1491352359

From stuefe at openjdk.org  Thu Feb 15 17:15:57 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 15 Feb 2024 17:15:57 GMT
Subject: RFR: 8314488: Compile the JDK as C++17 [v6]
In-Reply-To: <yq-FT47x7QF7L78fMxw3VvYAo_osUWzeUzxb5iJU3hE=.1899b72a-41f7-44b7-946f-84ca1339f1f8@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
 <b4HhbT5caIfCbrVveI6NDObiwUI2Sr0so68JBG6C0YU=.1734aaa7-aed4-478c-bbb6-de9af5c04ef9@github.com>
 <i3bo22m6I5cYhAMfktX-W_4-rrtyK6EPyK57QUi6Tco=.a18ddecb-440b-4c70-95ec-4b21fd1b3144@github.com>
 <KCC78U2X_if2XTRu1qNkeVXSQ672EyZFHbkl-OtP3U8=.9695b185-dc76-4d26-ae32-ceb254f5f275@github.com>
 <yq-FT47x7QF7L78fMxw3VvYAo_osUWzeUzxb5iJU3hE=.1899b72a-41f7-44b7-946f-84ca1339f1f8@github.com>
Message-ID: <F7MGxuI0CLaL28Y7s7KhRW_NmgsCOnJLs5wnUlXjGk8=.f44adba9-e08c-4093-a13e-dd2851e94e97@github.com>

On Mon, 5 Feb 2024 09:44:02 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> > Sure, you can always install a newer GCC than the system one, but it's another thing that makes it harder for people to build OpenJDK. Having said that, C++17 is nice to have.
> 
> @theRealAph I am still just hearing hand-waving "perhaps someone somewhere will have a somewhat harder time building the JDK". Yes, perhaps that is so. But that is very uncertain, and I have still not heard a single concrete example of where this would apply. In contrast, going to gcc 10 will clearly bring a benefit to all other platforms, since it allows us to synchronize the code base at C++17.
> 
> In light of this, I think we need to hear some really compelling evidence of problems that would ensue if we raise the minimum to gcc 10. If nobody can produce such evidence, then to me it is a sign that this fear is not well-grounded, and we should proceed with this PR.

@magicus You put the onus of proving that problems could ensue strictly to the objectors. That is a bit one-sided. I do not see much effort - any, really - put into detailing the motivation for this move, neither in the PR description nor in the JBS issue text. I just read through the whole PR discussion and really the only helpful comment I found was from Kim ( https://github.com/openjdk/jdk/pull/14988#issuecomment-1858136247 ).

I think important decisions like enforcing C++17 would benefit from a more careful preparation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1946628523

From angorya at openjdk.org  Thu Feb 15 17:31:56 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 15 Feb 2024 17:31:56 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck
In-Reply-To: <oX6tKgqTMzsDdSFj-X-EXtJS-20BsyiMYBacmxBTzTk=.b6eb0e9d-9940-479e-b70b-75a446e43e1c@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
 <Ksqjgi78ueQiu4oDhQ2d2wVT7a9bBAoMDGQ3CZnxH3Q=.ac125065-25c8-4c8c-b66b-c86f7523203b@github.com>
 <C2_NdHV3EpjVwEflvV6QcNdno8BgU9P3p2YZf1mQ3E8=.9e447ca9-8d6d-4ef4-9d99-14bd10d1c92e@github.com>
 <osmSAGyuE-qyC6sjVT_UjfRd2CfUQHuKFjlvmDOW-3Y=.b8a009f9-e995-42e7-afed-af83a016ff2b@github.com>
 <oX6tKgqTMzsDdSFj-X-EXtJS-20BsyiMYBacmxBTzTk=.b6eb0e9d-9940-479e-b70b-75a446e43e1c@github.com>
Message-ID: <Si89vBx8-kmdHyp9_XHJyFMD5oVir2mKhgwOcO281CE=.c387b74a-b09c-4213-8561-8e111f08f855@github.com>

On Thu, 15 Feb 2024 17:09:17 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> All the java/util/Currency tests pass. I also searched the code for "ZZ" but could not find any references in the test.
>
> Please do not replace those tabs with spaces as they are intentional for testing the runtime to safely ignore them. I suggest replacing them with Unicode escapes (`\u000b`)

`\u000b` is VT   (vertical tab)  
`\u0009` or `\t` perhaps?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1491375928

From sroy at openjdk.org  Thu Feb 15 17:53:01 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Thu, 15 Feb 2024 17:53:01 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v22]
In-Reply-To: <F5C_TjQXv6KNpn3yN8J37_eSIOWtRYZT3RwNkSu-Xq0=.723d24c7-355e-42e6-80a7-b1b8aa476520@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <LHKPKfz60cA4rddKKT51OUG7jxispd9M7A0io897pG0=.d8b3c965-755b-4500-a3f1-72b578045060@github.com>
 <F5C_TjQXv6KNpn3yN8J37_eSIOWtRYZT3RwNkSu-Xq0=.723d24c7-355e-42e6-80a7-b1b8aa476520@github.com>
Message-ID: <3ypc8tpwlD08GbadhJOPw52Xdl82jHSs46kUTWXNAug=.1cc93da1-1db6-45a2-a8f4-9890a6078a53@github.com>

On Thu, 15 Feb 2024 08:15:16 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Hi,
> 
> some remarks:
> 
> * there is no need for a copy for the first call to dll_load_library. Just hand in the string 1:1.
> * I would only do the *.a fallback loading if the error indicates that the *.so file had not been there. So, only if EACCESS or ENOENT; in all other cases I would not do the fallback. E.g. if the *.so file cannot be loaded due to a header mismatch. See https://www.ibm.com/docs/en/aix/7.1?topic=l-load-loadandinit-subroutines
> * Please use os::strdup.
> * Please assert that the replacement string is smaller than the original string (which it should be, *.so is longer than *.a, but this is insurance against anyone changing the code in the future)
> 
> Thank you, Thomas

Sure working on them. 
May i know why we are using the load routine in the 2nd point ? . Currently we do a *.a fallback only when dlopen fails. Does load function save some steps here ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1946756694

From naoto at openjdk.org  Thu Feb 15 17:55:58 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 Feb 2024 17:55:58 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck
In-Reply-To: <Si89vBx8-kmdHyp9_XHJyFMD5oVir2mKhgwOcO281CE=.c387b74a-b09c-4213-8561-8e111f08f855@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
 <Ksqjgi78ueQiu4oDhQ2d2wVT7a9bBAoMDGQ3CZnxH3Q=.ac125065-25c8-4c8c-b66b-c86f7523203b@github.com>
 <C2_NdHV3EpjVwEflvV6QcNdno8BgU9P3p2YZf1mQ3E8=.9e447ca9-8d6d-4ef4-9d99-14bd10d1c92e@github.com>
 <osmSAGyuE-qyC6sjVT_UjfRd2CfUQHuKFjlvmDOW-3Y=.b8a009f9-e995-42e7-afed-af83a016ff2b@github.com>
 <oX6tKgqTMzsDdSFj-X-EXtJS-20BsyiMYBacmxBTzTk=.b6eb0e9d-9940-479e-b70b-75a446e43e1c@github.com>
 <Si89vBx8-kmdHyp9_XHJyFMD5oVir2mKhgwOcO281CE=.c387b74a-b09c-4213-8561-8e111f08f855@github.com>
Message-ID: <RtDj7nYzLQTAHvuthfA12JIjqYTM7LkXy92QXXib4jY=.62dbc402-ade5-48be-9e7a-1ca1091899d4@github.com>

On Thu, 15 Feb 2024 17:28:52 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Please do not replace those tabs with spaces as they are intentional for testing the runtime to safely ignore them. I suggest replacing them with Unicode escapes (`\u000b`)
>
> `\u000b` is VT   (vertical tab)  
> `\u0009` or `\t` perhaps?

Right. `\t` is better to avoid such a mistake.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1491403426

From epeter at openjdk.org  Thu Feb 15 18:08:54 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 15 Feb 2024 18:08:54 GMT
Subject: RFR: 8325095: C2: bailout message broken: ResourceArea allocated
 string used after free
In-Reply-To: <8Bl6JSxb-fd1xAsKOMzBakRFuruoqJykP7JEn57k6qY=.717f89af-2aa7-439b-afd1-768dd39f51da@github.com>
References: <8Bl6JSxb-fd1xAsKOMzBakRFuruoqJykP7JEn57k6qY=.717f89af-2aa7-439b-afd1-768dd39f51da@github.com>
Message-ID: <qnutyTCjwk_JFTIZcs-xW_PVAcFGogjJjCjeh1KAbTg=.fa1b659a-eac6-4f83-9eed-f9a0d4b239b5@github.com>

On Mon, 5 Feb 2024 16:02:57 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> **Problem**
> Bailout `failure_reason` strings used to be either `nullptr` or a static string. But with [JDK-8303951](https://bugs.openjdk.org/browse/JDK-8303951) I had introduced dynamic strings (e.g. formatted using `stringStream::as_string()`). These dynamic strings were ResourceArea allocated, and have a very limited life-span, i.e. withing the most recent ResourceMark scope. The pointer is passed to `Compile::_failure_reason`, which already might leave that ResourceMark scope, and the pointer is invalid. And then the pointer is further passed to `ciEnv::_failure_reason`. And finally, it even gets passed up to `CompileBroker::invoke_compiler_on_method`. When the string is finally printed for the bailout message, we already left original `ResourceMark` scope, and also the `Compile` and `ciEnv` scopes. The pointer now points to basically random data.
> 
> **Solution**
> Whenever a string is passed to an outer scope, I make a CHeap copy, and the outer scope is the owner of that copy.
> This way every scope is the owner of its own copy, and can allocate and deallocate according to its own strategy safely.
> 
> I introduced a utility class `CHeapStringHolder`:
>  - `set`: make local copy on CHeap.
>  - `clear`: free local copy. We before `set`, and in the destructor. Thus, when the holder goes out of scope, the memory is automatically freed.
> 
> We have these 4 scopes:
> - `ResourceMark`: It allocates from `ResourcArea`, and deallocation is taken care at the end of the ResourceMark scope.
> - `Compile`: We turn the `_failure_reason` from a `char*` into a `CHeapStringHolder`. We set `_failure_reason` while the `ResourceMark` is live.
> - `ciEnv`: We turn the `_failure_reason` from a `char*` into a `CHeapStringHolder`. We set `_failure_reason` while `Compile` is live.
> - `CompileTask`: We used to just set `failure_reason`, which assumes that the string is static or elsewhere managed. Now I use pattern available in other places of `CompileBroker::invoke_compiler_on_method`: duplicate the string with `os::strdup` from some other scope, and set `reason_on_C_heap = true`, which means that we are the owner of that copy, and are responsible for freeing it later. Not sure if that is a nice pattern, but I don't want to refactor that code and it does what I need it to do.

src/hotspot/share/ci/ciEnv.cpp line 1272:

> 1270:     // Reset failure reason; this one is more important.
> 1271:     _failure_reason.clear();
> 1272:     record_failure(reason);

@dean-long the tricky part is here, I think:
We are in `ciEnv::record_method_not_compilable`. Depending on above condition, we either update the failure reason, or don't. So there may already be an old failure reason (the first one) that we overwrite (with a second one) or leave.

This method is called from `Compile::record_method_not_compilable`. There, we also call `Compile::record_failure`, which sets `Compile::_failure_reason`, with no such condition.

We might for example decide to keep the old failure reason at ciEnv, but update the failure reason at Compile, at least that is how I read the code.

Hence, there can be multiple failure reasons around, I think. And I cannot fit multiple messages in a single buffer. Thus, I need some way to dynamically allocate.

Now: is this good or desirable? I don't know. Potentially having different failure messages at Compile and ciEnv - not sure if that is reasonable. We should probably discuss that. But for now I'm just trying to fix the code the way it works.

What do you think?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17710#discussion_r1491415589

From duke at openjdk.org  Thu Feb 15 18:55:16 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Thu, 15 Feb 2024 18:55:16 GMT
Subject: RFR: 8325991: Accelerate Poly1305 on x86_64 using AVX2 instructions
Message-ID: <IyoM1HY_rvNWwo4GxcV1yQleB3vrgaLwsAlOCEpLKqs=.1d50225c-8fe1-4a84-af56-274632b2b653@github.com>

The goal of this PR is to accelerate the Poly1305 algorithm using AVX2 instructions (including IFMA) for x86_64 CPUs.

This implementation is directly based on the AVX2 Poly1305 hash computation as implemented in Intel(R) Multi-Buffer Crypto for IPsec Library (url: https://github.com/intel/intel-ipsec-mb/blob/main/lib/avx2_t3/poly_fma_avx2.asm)

-------------

Commit messages:
 - 8325991: Accelerate Poly1305 on x86_64 using AVX2 instructions
 - fix typos in algorithm
 - add pseudo code algorithm
 - remove comment
 - response to safe review comments
 - cleanup copyright
 - add avx-ifma check
 - Add suggested comments
 - remove kmask from vpmadd instructions
 - Address Vlad's codereview comments
 - ... and 4 more: https://git.openjdk.org/jdk/compare/3d32c460...d3af573a

Changes: https://git.openjdk.org/jdk/pull/17881/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17881&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8325991
  Stats: 858 lines in 8 files changed: 844 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/17881.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17881/head:pull/17881

PR: https://git.openjdk.org/jdk/pull/17881

From duke at openjdk.org  Thu Feb 15 19:16:19 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Thu, 15 Feb 2024 19:16:19 GMT
Subject: RFR: 8325991: Accelerate Poly1305 on x86_64 using AVX2
 instructions [v2]
In-Reply-To: <IyoM1HY_rvNWwo4GxcV1yQleB3vrgaLwsAlOCEpLKqs=.1d50225c-8fe1-4a84-af56-274632b2b653@github.com>
References: <IyoM1HY_rvNWwo4GxcV1yQleB3vrgaLwsAlOCEpLKqs=.1d50225c-8fe1-4a84-af56-274632b2b653@github.com>
Message-ID: <wFtCW9VdSqFm7pfbxHy9_wAFgWPdSJ6tL4Pf7VukJq8=.1ed9c00a-3fe1-4c4b-8af4-6f8235a83f1b@github.com>

> The goal of this PR is to accelerate the Poly1305 algorithm using AVX2 instructions (including IFMA) for x86_64 CPUs.
> 
> This implementation is directly based on the AVX2 Poly1305 hash computation as implemented in Intel(R) Multi-Buffer Crypto for IPsec Library (url: https://github.com/intel/intel-ipsec-mb/blob/main/lib/avx2_t3/poly_fma_avx2.asm)

Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:

  update algo writeup for clarity

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17881/files
  - new: https://git.openjdk.org/jdk/pull/17881/files/d3af573a..039ceb97

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17881&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17881&range=00-01

  Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/17881.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17881/head:pull/17881

PR: https://git.openjdk.org/jdk/pull/17881

From sspitsyn at openjdk.org  Thu Feb 15 19:55:08 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 15 Feb 2024 19:55:08 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v9]
In-Reply-To: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
Message-ID: <FstoRCjpy6-9WOSrll3-SD9ChAsZ8KZ19LiEZEHmqvc=.d58aeafc-ddb4-4bc3-bb47-cc3471259cb5@github.com>

> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
> The function returns the following structure:
> 
> 
> typedef struct {
>     jthread owner;
>     jint entry_count;
>     jint waiter_count;
>     jthread* waiters;
>     jint notify_waiter_count;
>     jthread* notify_waiters;
> } jvmtiMonitorUsage;
> 
> 
> The following four fields are defined this way:
> 
> waiter_count  [jint] The number of threads waiting to own this monitor
> waiters  [jthread*] The waiter_count waiting threads
> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
> 
> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
> This update makes it right.
> 
> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
> 
> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
> 
>   jvmti/GetObjectMonitorUsage/objmonusage001
>   jvmti/GetObjectMonitorUsage/objmonusage003
> 
> 
> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
> 
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
> 
> 
> 
> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository.
> 
> Also, please see and review the related CSR:
>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
> 
> The Release-Note is:
> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage
>  
> Testing:
>  - tested with mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: JDWP monitor_info spec clarification; removed debugging code from objmonusage001

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17680/files
  - new: https://git.openjdk.org/jdk/pull/17680/files/1ab5b349..c8b8e376

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=07-08

  Stats: 25 lines in 2 files changed: 0 ins; 13 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/17680.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17680/head:pull/17680

PR: https://git.openjdk.org/jdk/pull/17680

From duke at openjdk.org  Thu Feb 15 20:09:06 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Thu, 15 Feb 2024 20:09:06 GMT
Subject: RFR: 8325991: Accelerate Poly1305 on x86_64 using AVX2
 instructions [v3]
In-Reply-To: <IyoM1HY_rvNWwo4GxcV1yQleB3vrgaLwsAlOCEpLKqs=.1d50225c-8fe1-4a84-af56-274632b2b653@github.com>
References: <IyoM1HY_rvNWwo4GxcV1yQleB3vrgaLwsAlOCEpLKqs=.1d50225c-8fe1-4a84-af56-274632b2b653@github.com>
Message-ID: <RcqlCw9bXCsxQf7dNaKVjFflrCvu41kJDkbbxpuCWaU=.d2cf9c21-2d34-4320-a76a-9ab0aa71c43e@github.com>

> The goal of this PR is to accelerate the Poly1305 algorithm using AVX2 instructions (including IFMA) for x86_64 CPUs.
> 
> This implementation is directly based on the AVX2 Poly1305 hash computation as implemented in Intel(R) Multi-Buffer Crypto for IPsec Library (url: https://github.com/intel/intel-ipsec-mb/blob/main/lib/avx2_t3/poly_fma_avx2.asm)

Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:

  change overloaded C to use COEFF

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17881/files
  - new: https://git.openjdk.org/jdk/pull/17881/files/039ceb97..6d97c53a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17881&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17881&range=01-02

  Stats: 15 lines in 1 file changed: 0 ins; 0 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/17881.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17881/head:pull/17881

PR: https://git.openjdk.org/jdk/pull/17881

From sspitsyn at openjdk.org  Thu Feb 15 20:09:54 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 15 Feb 2024 20:09:54 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v9]
In-Reply-To: <FstoRCjpy6-9WOSrll3-SD9ChAsZ8KZ19LiEZEHmqvc=.d58aeafc-ddb4-4bc3-bb47-cc3471259cb5@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <FstoRCjpy6-9WOSrll3-SD9ChAsZ8KZ19LiEZEHmqvc=.d58aeafc-ddb4-4bc3-bb47-cc3471259cb5@github.com>
Message-ID: <abOdUSXoPbqU-5_xHb-qNk3N2naLSFF9t3gX58bQe4M=.c621bb82-f6a8-4dc9-8016-88ede153231c@github.com>

On Thu, 15 Feb 2024 19:55:08 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
>> The function returns the following structure:
>> 
>> 
>> typedef struct {
>>     jthread owner;
>>     jint entry_count;
>>     jint waiter_count;
>>     jthread* waiters;
>>     jint notify_waiter_count;
>>     jthread* notify_waiters;
>> } jvmtiMonitorUsage;
>> 
>> 
>> The following four fields are defined this way:
>> 
>> waiter_count  [jint] The number of threads waiting to own this monitor
>> waiters  [jthread*] The waiter_count waiting threads
>> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
>> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
>> 
>> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
>> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
>> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
>> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
>> This update makes it right.
>> 
>> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
>> 
>> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
>> 
>>   jvmti/GetObjectMonitorUsage/objmonusage001
>>   jvmti/GetObjectMonitorUsage/objmonusage003
>> 
>> 
>> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
>> 
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
>> 
>> 
>> 
>> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository.
>> 
>> Also, please see and review the related CSR:
>>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
>> 
>> The Release-Note is:
>> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage
>>  
>> Testing:
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: JDWP monitor_info spec clarification; removed debugging code from objmonusage001

I've pushed an update that includes:
 - added minor spec clarification for JDWP `ObjectReference.MonitorInfo` command (please, see the CSR)
 - removed the CHECK_FOR_BAD_RESULTS debugging mode from the test: `nsk/jvmti/GetObjectMonitorUsage/objmonusage001`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17680#issuecomment-1947208935

From kvn at openjdk.org  Thu Feb 15 20:36:58 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 15 Feb 2024 20:36:58 GMT
Subject: RFR: 8317697: refactor-encapsulate x86 VM_Version::CpuidInfo [v4]
In-Reply-To: <ioaANin14rJBVL0cwwLg79zVULcK5IbFbbBfzpcl_GY=.1c2fb0ac-d8d5-4a04-b488-7e9e93e288bf@github.com>
References: <JmIOcendwRGLAVKOQ4bFrDxwNVgt1KY5LKJ-Vz-SBjg=.edcccbcb-346c-4063-b75f-09d337fa9f66@github.com>
 <ioaANin14rJBVL0cwwLg79zVULcK5IbFbbBfzpcl_GY=.1c2fb0ac-d8d5-4a04-b488-7e9e93e288bf@github.com>
Message-ID: <QWSIWN4T6sDfmmOYeYsz-dG02fPi3bP-Wbv9NcpMZXs=.6adf7e02-df40-4b7e-8032-d9ea8b087e18@github.com>

On Thu, 15 Feb 2024 12:18:17 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> In OpenJDK project CRaC I had a [need to fetch new CpuidInfo without affecting the existing one](https://github.com/openjdk/crac/commit/ed4ad9ba31b77732dcede2eb743b2f389ec9a0fe#diff-6ed856c57ddbe33e49883adb7c52ec51ed377e5f697dfd6d8bea505a97bfc5a5R2743).
>> Which led me to encapsulate the object more and I think this no-functionality-change patch is even appropriate for JDK.
>> I am sure interested primarily to reduce the CRaC patchset boilerplate.
>
> Jan Kratochvil has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into flagsencaps
>  - Remove the automatic zero-initialization
>  - Make CpuidInfo a class
>  - Merge branch 'master' into flagsencaps
>  - 8317697: refactor-encapsulate x86 VM_Version::CpuidInfo

Looks hood to me too.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16093#pullrequestreview-1883825212

From rkennke at openjdk.org  Thu Feb 15 21:42:08 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 15 Feb 2024 21:42:08 GMT
Subject: RFR: 8139457: Relax alignment of array elements [v64]
In-Reply-To: <L1FV4XUdDi491n22aiCfjk8SrnIJHYeDEQf2u2aY4i8=.6f73b2a6-8e7f-4f69-9d07-c2425ad484f3@github.com>
References: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
 <L1FV4XUdDi491n22aiCfjk8SrnIJHYeDEQf2u2aY4i8=.6f73b2a6-8e7f-4f69-9d07-c2425ad484f3@github.com>
Message-ID: <aUJxrq74LUnC57Ddm-_5UO2jYhFBSoD1D6DzPUtQOD4=.5e5a6a6c-887d-4a80-b0b3-437cd923fa9c@github.com>

On Thu, 15 Feb 2024 11:46:39 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details.
>> 
>> Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements.
>> 
>> Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16.
>> 
>> Testing:
>>  - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390)
>>  - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390)
>>  - [x] tier1 (x86_64, x86_32, aarch64, riscv)
>>  - [x] tier2 (x86_64, aarch64, riscv)
>>  - [x] tier3 (x86_64, riscv)
>
> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 93 commits:
> 
>  - Merge branch 'master' into JDK-8139457
>  - Merge remote-tracking branch 'upstream/master' into JDK-8139457
>  - Update copyright headers
>  - Merge branch 'master' into JDK-8139457
>  - Fix ARM build
>  - Merge remote-tracking branch 'upstream/master' into JDK-8139457
>  - Various cleanups
>  - RISC changes
>  - Move gap init into allocate_header() (x86)
>  - Fix gtest failure on x86
>  - ... and 83 more: https://git.openjdk.org/jdk/compare/a0e5e16a...d0ec1fa2

FWIW, I just ran tier1 and tier2 with this change and -CCP with no regressions. tier2 fails a number of tests with and without the change because it can not handle -CCP, but that is not specific to this change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/11044#issuecomment-1947382603

From kvn at openjdk.org  Thu Feb 15 21:57:54 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 15 Feb 2024 21:57:54 GMT
Subject: RFR: 8325095: C2: bailout message broken: ResourceArea allocated
 string used after free
In-Reply-To: <8Bl6JSxb-fd1xAsKOMzBakRFuruoqJykP7JEn57k6qY=.717f89af-2aa7-439b-afd1-768dd39f51da@github.com>
References: <8Bl6JSxb-fd1xAsKOMzBakRFuruoqJykP7JEn57k6qY=.717f89af-2aa7-439b-afd1-768dd39f51da@github.com>
Message-ID: <sAvUXhZYUJIBVaRD_06LWWw4D_3DjdeI4SIyCFXGkwg=.8f6a584a-eb6c-45e8-a91c-1da528f47a23@github.com>

On Mon, 5 Feb 2024 16:02:57 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> **Problem**
> Bailout `failure_reason` strings used to be either `nullptr` or a static string. But with [JDK-8303951](https://bugs.openjdk.org/browse/JDK-8303951) I had introduced dynamic strings (e.g. formatted using `stringStream::as_string()`). These dynamic strings were ResourceArea allocated, and have a very limited life-span, i.e. withing the most recent ResourceMark scope. The pointer is passed to `Compile::_failure_reason`, which already might leave that ResourceMark scope, and the pointer is invalid. And then the pointer is further passed to `ciEnv::_failure_reason`. And finally, it even gets passed up to `CompileBroker::invoke_compiler_on_method`. When the string is finally printed for the bailout message, we already left original `ResourceMark` scope, and also the `Compile` and `ciEnv` scopes. The pointer now points to basically random data.
> 
> **Solution**
> Whenever a string is passed to an outer scope, I make a CHeap copy, and the outer scope is the owner of that copy.
> This way every scope is the owner of its own copy, and can allocate and deallocate according to its own strategy safely.
> 
> I introduced a utility class `CHeapStringHolder`:
>  - `set`: make local copy on CHeap.
>  - `clear`: free local copy. We before `set`, and in the destructor. Thus, when the holder goes out of scope, the memory is automatically freed.
> 
> We have these 4 scopes:
> - `ResourceMark`: It allocates from `ResourcArea`, and deallocation is taken care at the end of the ResourceMark scope.
> - `Compile`: We turn the `_failure_reason` from a `char*` into a `CHeapStringHolder`. We set `_failure_reason` while the `ResourceMark` is live.
> - `ciEnv`: We turn the `_failure_reason` from a `char*` into a `CHeapStringHolder`. We set `_failure_reason` while `Compile` is live.
> - `CompileTask`: We used to just set `failure_reason`, which assumes that the string is static or elsewhere managed. Now I use pattern available in other places of `CompileBroker::invoke_compiler_on_method`: duplicate the string with `os::strdup` from some other scope, and set `reason_on_C_heap = true`, which means that we are the owner of that copy, and are responsible for freeing it later. Not sure if that is a nice pattern, but I don't want to refactor that code and it does what I need it to do.

I thought after our offline discussion that you will keep failure reasons in CompileTask.
What happened to that approach?

-------------

PR Review: https://git.openjdk.org/jdk/pull/17710#pullrequestreview-1883955791

From kvn at openjdk.org  Thu Feb 15 21:57:54 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 15 Feb 2024 21:57:54 GMT
Subject: RFR: 8325095: C2: bailout message broken: ResourceArea allocated
 string used after free
In-Reply-To: <qnutyTCjwk_JFTIZcs-xW_PVAcFGogjJjCjeh1KAbTg=.fa1b659a-eac6-4f83-9eed-f9a0d4b239b5@github.com>
References: <8Bl6JSxb-fd1xAsKOMzBakRFuruoqJykP7JEn57k6qY=.717f89af-2aa7-439b-afd1-768dd39f51da@github.com>
 <qnutyTCjwk_JFTIZcs-xW_PVAcFGogjJjCjeh1KAbTg=.fa1b659a-eac6-4f83-9eed-f9a0d4b239b5@github.com>
Message-ID: <By6S6aqP_qRgnLVbbC1HcY2xvlYVkbGztxV1JdeUWIg=.0504185b-8bba-46a7-bbd0-dbef9b10be47@github.com>

On Thu, 15 Feb 2024 18:04:20 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> **Problem**
>> Bailout `failure_reason` strings used to be either `nullptr` or a static string. But with [JDK-8303951](https://bugs.openjdk.org/browse/JDK-8303951) I had introduced dynamic strings (e.g. formatted using `stringStream::as_string()`). These dynamic strings were ResourceArea allocated, and have a very limited life-span, i.e. withing the most recent ResourceMark scope. The pointer is passed to `Compile::_failure_reason`, which already might leave that ResourceMark scope, and the pointer is invalid. And then the pointer is further passed to `ciEnv::_failure_reason`. And finally, it even gets passed up to `CompileBroker::invoke_compiler_on_method`. When the string is finally printed for the bailout message, we already left original `ResourceMark` scope, and also the `Compile` and `ciEnv` scopes. The pointer now points to basically random data.
>> 
>> **Solution**
>> Whenever a string is passed to an outer scope, I make a CHeap copy, and the outer scope is the owner of that copy.
>> This way every scope is the owner of its own copy, and can allocate and deallocate according to its own strategy safely.
>> 
>> I introduced a utility class `CHeapStringHolder`:
>>  - `set`: make local copy on CHeap.
>>  - `clear`: free local copy. We before `set`, and in the destructor. Thus, when the holder goes out of scope, the memory is automatically freed.
>> 
>> We have these 4 scopes:
>> - `ResourceMark`: It allocates from `ResourcArea`, and deallocation is taken care at the end of the ResourceMark scope.
>> - `Compile`: We turn the `_failure_reason` from a `char*` into a `CHeapStringHolder`. We set `_failure_reason` while the `ResourceMark` is live.
>> - `ciEnv`: We turn the `_failure_reason` from a `char*` into a `CHeapStringHolder`. We set `_failure_reason` while `Compile` is live.
>> - `CompileTask`: We used to just set `failure_reason`, which assumes that the string is static or elsewhere managed. Now I use pattern available in other places of `CompileBroker::invoke_compiler_on_method`: duplicate the string with `os::strdup` from some other scope, and set `reason_on_C_heap = true`, which means that we are the owner of that copy, and are responsible for freeing it later. Not sure if that is a nice pattern, but I don't want to refactor that code and it does what I need it to do.
>
> src/hotspot/share/ci/ciEnv.cpp line 1272:
> 
>> 1270:     // Reset failure reason; this one is more important.
>> 1271:     _failure_reason.clear();
>> 1272:     record_failure(reason);
> 
> @dean-long the tricky part is here, I think:
> We are in `ciEnv::record_method_not_compilable`. Depending on above condition, we either update the failure reason, or don't. So there may already be an old failure reason (the first one) that we overwrite (with a second one) or leave.
> 
> This method is called from `Compile::record_method_not_compilable`. There, we also call `Compile::record_failure`, which sets `Compile::_failure_reason`, with no such condition.
> 
> We might for example decide to keep the old failure reason at ciEnv, but update the failure reason at Compile, at least that is how I read the code.
> 
> Hence, there can be multiple failure reasons around, I think. And I cannot fit multiple messages in a single buffer. Thus, I need some way to dynamically allocate.
> 
> Now: is this good or desirable? I don't know. Potentially having different failure messages at Compile and ciEnv - not sure if that is reasonable. We should probably discuss that. But for now I'm just trying to fix the code the way it works.
> 
> What do you think?

I think initially we care only about "most" important failure because implementation allowed to report only one failure.
If you can keep all failures AND report all of them it would be nice, I think. May be in separate RFE.

We should have only one place where we keep failures.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17710#discussion_r1491714124

From eastigeevich at openjdk.org  Thu Feb 15 22:32:57 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Thu, 15 Feb 2024 22:32:57 GMT
Subject: RFR: 8311248: Refactor CodeCache::initialize_heaps to simplify
 adding new CodeCache segments [v6]
In-Reply-To: <qxAv0RZ-f98T5C_WY4wVLyTjEbDFAyFjMuUShnPstW8=.facce7d8-ec20-401d-b6d6-03da493822ed@github.com>
References: <-V_dgQKhDrt1n0Zbk3qNa276jZBO822NlSvUv9AhpEA=.7a23c712-4b01-4aa7-acbe-8f5b5cca9002@github.com>
 <qxAv0RZ-f98T5C_WY4wVLyTjEbDFAyFjMuUShnPstW8=.facce7d8-ec20-401d-b6d6-03da493822ed@github.com>
Message-ID: <wZ2nivDADeLJ8T8bt9bwZdnBbK_Mp4spXxd1zRIW1eY=.ab3b8a50-6ce5-4b12-92fb-d8f1eb24b301@github.com>

On Fri, 2 Feb 2024 09:33:31 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

>> These changes clean up the logic and the code of allocating codecache segments and add more testing of it, to open a door for further optimization of code cache segmentation.  The goal was to keep the behavior as close to the existing behavior as possible, even if it's not quite logical.
>> 
>> Also, these changes better account for alignment - PrintFlagsFinal shows the final aligned segment sizes, and the segments fill the ReservedCodeCacheSize without gaps caused by alignment.
>
> Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   set_size_of_unset_code_heap

src/hotspot/share/code/codeCache.cpp line 200:

> 198: };
> 199: 
> 200: static void report_cache_size_error(const CodeHeapInfo& non_nmethod, const CodeHeapInfo& profiled,

Add the comment:
// Exit with reporting an error that the sum of code heap sizes is not equal ReservedCodeCacheSize.

src/hotspot/share/code/codeCache.cpp line 201:

> 199: 
> 200: static void report_cache_size_error(const CodeHeapInfo& non_nmethod, const CodeHeapInfo& profiled,
> 201:                                     const CodeHeapInfo& non_profiled, size_t cache_size) {

You don't need `cache_size` as you assume it holds `ReservedCodeCacheSize`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17244#discussion_r1491742442
PR Review Comment: https://git.openjdk.org/jdk/pull/17244#discussion_r1491742958

From prr at openjdk.org  Thu Feb 15 22:40:56 2024
From: prr at openjdk.org (Phil Race)
Date: Thu, 15 Feb 2024 22:40:56 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck
In-Reply-To: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
Message-ID: <lmqQHpQrlQkG9kFB3GhPa0530wpWgAWXrVjKeKLrezM=.8050c3cd-2143-439e-ad8d-c3b27e82e59a@github.com>

On Thu, 15 Feb 2024 12:19:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes).
> 
> I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base.

desktop changes look fine to me.

-------------

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17871#pullrequestreview-1884009342

From eastigeevich at openjdk.org  Thu Feb 15 22:42:57 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Thu, 15 Feb 2024 22:42:57 GMT
Subject: RFR: 8311248: Refactor CodeCache::initialize_heaps to simplify
 adding new CodeCache segments [v6]
In-Reply-To: <qxAv0RZ-f98T5C_WY4wVLyTjEbDFAyFjMuUShnPstW8=.facce7d8-ec20-401d-b6d6-03da493822ed@github.com>
References: <-V_dgQKhDrt1n0Zbk3qNa276jZBO822NlSvUv9AhpEA=.7a23c712-4b01-4aa7-acbe-8f5b5cca9002@github.com>
 <qxAv0RZ-f98T5C_WY4wVLyTjEbDFAyFjMuUShnPstW8=.facce7d8-ec20-401d-b6d6-03da493822ed@github.com>
Message-ID: <g238prJeZJifjYvXhArq4pdWqINKt3hwMkgSQACy4aE=.b76328e7-beae-41b1-8695-32603728b7ad@github.com>

On Fri, 2 Feb 2024 09:33:31 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

>> These changes clean up the logic and the code of allocating codecache segments and add more testing of it, to open a door for further optimization of code cache segmentation.  The goal was to keep the behavior as close to the existing behavior as possible, even if it's not quite logical.
>> 
>> Also, these changes better account for alignment - PrintFlagsFinal shows the final aligned segment sizes, and the segments fill the ReservedCodeCacheSize without gaps caused by alignment.
>
> Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   set_size_of_unset_code_heap

src/hotspot/share/code/codeCache.cpp line 202:

> 200: static void report_cache_size_error(const CodeHeapInfo& non_nmethod, const CodeHeapInfo& profiled,
> 201:                                     const CodeHeapInfo& non_profiled, size_t cache_size) {
> 202:   size_t total = non_nmethod.size;

You have already calculated the total, why not to reuse it?
Also add an assert: `assert(total != ReservedCodeCacheSize, "Should be invoked to report an error")`

src/hotspot/share/code/codeCache.cpp line 220:

> 218:   }
> 219:   else {
> 220:     message.append(" is not equal to ReservedCodeCacheSize (" SIZE_FORMAT "K).", cache_size/K);

The correct message is " is less than ...". We call the function when they are not equal.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17244#discussion_r1491748816
PR Review Comment: https://git.openjdk.org/jdk/pull/17244#discussion_r1491750222

From eastigeevich at openjdk.org  Thu Feb 15 22:56:57 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Thu, 15 Feb 2024 22:56:57 GMT
Subject: RFR: 8311248: Refactor CodeCache::initialize_heaps to simplify
 adding new CodeCache segments [v6]
In-Reply-To: <qxAv0RZ-f98T5C_WY4wVLyTjEbDFAyFjMuUShnPstW8=.facce7d8-ec20-401d-b6d6-03da493822ed@github.com>
References: <-V_dgQKhDrt1n0Zbk3qNa276jZBO822NlSvUv9AhpEA=.7a23c712-4b01-4aa7-acbe-8f5b5cca9002@github.com>
 <qxAv0RZ-f98T5C_WY4wVLyTjEbDFAyFjMuUShnPstW8=.facce7d8-ec20-401d-b6d6-03da493822ed@github.com>
Message-ID: <KbFWudVwo5tRbF1PVHwUBdbR16X_2qOsbEBVoYLytpY=.73e4deb8-1c24-4cee-8dfc-dccbee998fe5@github.com>

On Fri, 2 Feb 2024 09:33:31 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

>> These changes clean up the logic and the code of allocating codecache segments and add more testing of it, to open a door for further optimization of code cache segmentation.  The goal was to keep the behavior as close to the existing behavior as possible, even if it's not quite logical.
>> 
>> Also, these changes better account for alignment - PrintFlagsFinal shows the final aligned segment sizes, and the segments fill the ReservedCodeCacheSize without gaps caused by alignment.
>
> Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   set_size_of_unset_code_heap

src/hotspot/share/code/codeCache.cpp line 205:

> 203: 
> 204:   err_msg message("NonNMethodCodeHeapSize (" SIZE_FORMAT "K)", non_nmethod.size/K);
> 205:   if (profiled.enabled) {

Is `profiled.size` zero if `profiled.enabled` is false?
If so, we can just pass: total and sizes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17244#discussion_r1491758668

From epeter at openjdk.org  Thu Feb 15 23:05:54 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 15 Feb 2024 23:05:54 GMT
Subject: RFR: 8325095: C2: bailout message broken: ResourceArea allocated
 string used after free
In-Reply-To: <sAvUXhZYUJIBVaRD_06LWWw4D_3DjdeI4SIyCFXGkwg=.8f6a584a-eb6c-45e8-a91c-1da528f47a23@github.com>
References: <8Bl6JSxb-fd1xAsKOMzBakRFuruoqJykP7JEn57k6qY=.717f89af-2aa7-439b-afd1-768dd39f51da@github.com>
 <sAvUXhZYUJIBVaRD_06LWWw4D_3DjdeI4SIyCFXGkwg=.8f6a584a-eb6c-45e8-a91c-1da528f47a23@github.com>
Message-ID: <_mji21ZxgPSNjPdNA-0aJMvyt-CZBjFR1H0LMpdeQXA=.538f06c0-3a8e-4432-ac45-a94f6ae9430a@github.com>

On Thu, 15 Feb 2024 21:54:57 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> **Problem**
>> Bailout `failure_reason` strings used to be either `nullptr` or a static string. But with [JDK-8303951](https://bugs.openjdk.org/browse/JDK-8303951) I had introduced dynamic strings (e.g. formatted using `stringStream::as_string()`). These dynamic strings were ResourceArea allocated, and have a very limited life-span, i.e. withing the most recent ResourceMark scope. The pointer is passed to `Compile::_failure_reason`, which already might leave that ResourceMark scope, and the pointer is invalid. And then the pointer is further passed to `ciEnv::_failure_reason`. And finally, it even gets passed up to `CompileBroker::invoke_compiler_on_method`. When the string is finally printed for the bailout message, we already left original `ResourceMark` scope, and also the `Compile` and `ciEnv` scopes. The pointer now points to basically random data.
>> 
>> **Solution**
>> Whenever a string is passed to an outer scope, I make a CHeap copy, and the outer scope is the owner of that copy.
>> This way every scope is the owner of its own copy, and can allocate and deallocate according to its own strategy safely.
>> 
>> I introduced a utility class `CHeapStringHolder`:
>>  - `set`: make local copy on CHeap.
>>  - `clear`: free local copy. We before `set`, and in the destructor. Thus, when the holder goes out of scope, the memory is automatically freed.
>> 
>> We have these 4 scopes:
>> - `ResourceMark`: It allocates from `ResourcArea`, and deallocation is taken care at the end of the ResourceMark scope.
>> - `Compile`: We turn the `_failure_reason` from a `char*` into a `CHeapStringHolder`. We set `_failure_reason` while the `ResourceMark` is live.
>> - `ciEnv`: We turn the `_failure_reason` from a `char*` into a `CHeapStringHolder`. We set `_failure_reason` while `Compile` is live.
>> - `CompileTask`: We used to just set `failure_reason`, which assumes that the string is static or elsewhere managed. Now I use pattern available in other places of `CompileBroker::invoke_compiler_on_method`: duplicate the string with `os::strdup` from some other scope, and set `reason_on_C_heap = true`, which means that we are the owner of that copy, and are responsible for freeing it later. Not sure if that is a nice pattern, but I don't want to refactor that code and it does what I need it to do.
>
> I thought after our offline discussion that you will keep failure reasons in CompileTask.
> What happened to that approach?

@vnkozlov yes, that was the plan. But then @jdksjolen objected, see his comments above. The new approach would be a bit more "clean", as the ownership is now clear.
The problem with the arena: I can't use a simple Arena at CompileTask, since an Arena only grows. A CompileTask is reused for many compilations, and so potentially we would have many failures on that Arena, leading to uncontrolled memory usage. A ResourceMark would require a ResourceMark - that could be done I guess. But creating such ad-hoc ResourceAreas with their own ResourceMarks seems a bit ... well ad-hoc. So that is why @jdksjolen proposed to just have a string-holder that simply allocates itself. Allocation and ownership are straight forward this way.

Any yes, there should probably be some refactoring. I'm not sure why there are `failure_reason` reportings at 3 layers (maybe even more?): `Compile, ciEnv, CompileTask`. Maybe we can log the failure reason only at `CompileTask` level? I'd have to see if that is a feasible refactoring.

Would it be ok to push this BugFix, and then come up with a refactoring RFE? We probably also want to refactor the strange `reason_on_C_heap` mechanism on `CompileTask` level. If someone sets that flag wrong, we have a bad free, or a memory leak.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17710#issuecomment-1947481272

From jianglizhou at google.com  Fri Feb 16 00:37:48 2024
From: jianglizhou at google.com (Jiangli Zhou)
Date: Thu, 15 Feb 2024 16:37:48 -0800
Subject: Hotspot symbol visibility
In-Reply-To: <645132e0-687e-4f04-9e49-f90131294367@oracle.com>
References: <645132e0-687e-4f04-9e49-f90131294367@oracle.com>
Message-ID: <CALrW1jzhh1ENV+nOno-d73Qj3xVCb6=B5WDN-6AH29rraA0V5g@mail.gmail.com>

Hi Magnus,

For hotspot symbols that need to be exported, when statically linking
the launcher executable using libjvm.a, we use lld's
`-Wl,--export-dynamic-symbol-list=` option. Those exported symbols can
be used outside the VM code, e.g. in agent. Our friend(s) in c++
compiler/toolchain added the support for --export-dynamic-symbol-list,
https://reviews.llvm.org/D107317. -Wl,--dynamic-list with gcc provides
similar support.

Best,
Jiangli

On Wed, Feb 14, 2024 at 2:06?AM Magnus Ihse Bursie
<magnus.ihse.bursie at oracle.com> wrote:
>
> I am currently pursuing improved build functionality for static
> libraries. One of the issues with static libraries are name collisions,
> which led me back to an old discussion about which symbols are exported
> from Hotspot, and how this is achieved. A long discussion is available
> in JDK-8017234 [1], which was created in 2013 and has been on the back
> burner ever since, coming back to life every now and then.
>
> There are basically two different problems here. They are both distinct
> and interrelated, and we likely need to solve both in tandem.
>
> The first problem is how Hotspot should say which symbols (functions)
> that should be exported from libjvm.so. The historical, and still used,
> system is to have a mapfile. In the "new" (not so new anymore) build
> system, this was simplified to a list of function names in
> make/data/hotspot-symbols, from which a mapfile is built.
>
> This is in contrast with how all other libraries in the JDK are built,
> and also with modern best practices. A better approach would be to
> annotate the functions that should be exported in the source code. In
> fact, such annotation already exists, even in Hotspot, as JNIEXPORT, but
> this is currently not used in the compilation of Hotspot.
>
> The second problem is that in addition to these explicitly exported
> functions, we also export basically all other functions as well in
> Hotspot. (So currently we could basically just forgo this complicated
> machinery and just export everything by default...)
>
> The reason for this seem somewhat unclear. The specifics are probably
> forever lost in the mists of time past, but the essential point is that
> these symbols are needed for SA to do it's job.
>
> So what we do is that we list all symbols in hotspot after compiling
> (but before linking), and selects some (most, I think) of them using
> regexp patterns, and add these to the mapfile.
>
> As long as we're doing this, we cannot stop using a mapfile, and we're
> stuck from progressing on point 1.
>
> My takeaway from the discussions is that we are most likely exporting a
> way too broad set of symbols to SA. It seems likely that this set can be
> drastically cut down. Actually getting an understanding of exactly which
> symbols SA need seem like a very good first step.
>
> So, is this a journey anyone would be interested in embarkering on? I
> will help as much as I can from a build PoV, but I have no clue
> whatsoever about what SA needs.
>
> /Magnus
>
> [1] https://bugs.openjdk.org/browse/JDK-8017234
>

From lmesnik at openjdk.org  Fri Feb 16 00:51:13 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 16 Feb 2024 00:51:13 GMT
Subject: RFR: 8326006: Allow TEST_VM_FLAGLESS to set flagless mode
Message-ID: <0uxFDONrkojHseqjpNszTa-0LmjDpOPKZYozPDJKyOo=.e89913fa-ff13-43f6-95db-bc85222d3c49@github.com>

Allow TEST_VM_FLAGLESS to enable/disable flagless tests execution explicitly.
Sometimes the tests are executed in the mode that is incompatible with flag-sensitive tests. This mode should be able to disable them explicitly.

-------------

Commit messages:
 - 8326006: Allow TEST_VM_FLAGLESS to set flagless mode

Changes: https://git.openjdk.org/jdk/pull/17886/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17886&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8326006
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17886.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17886/head:pull/17886

PR: https://git.openjdk.org/jdk/pull/17886

From wetmore at openjdk.org  Fri Feb 16 01:44:57 2024
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Fri, 16 Feb 2024 01:44:57 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck
In-Reply-To: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
Message-ID: <AG07BfABTTmZaZhAd9jHgMMgcaGRtP_31MVSJg8LUYo=.e9355b50-d5d1-4551-a161-15712bf6b1e8@github.com>

On Thu, 15 Feb 2024 12:19:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes).
> 
> I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base.

security properties looks ok.

-------------

Marked as reviewed by wetmore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17871#pullrequestreview-1884183930

From duke at openjdk.org  Fri Feb 16 02:29:12 2024
From: duke at openjdk.org (Lei Zaakjyu)
Date: Fri, 16 Feb 2024 02:29:12 GMT
Subject: RFR: 8325082: Rename headers named 'heapRegion*' of G1 [v5]
In-Reply-To: <1MWMgluBwGY-FydUnpoksJ0q5sSvptrNMv6xwDszBQc=.a78cadad-1585-44d1-97d0-a7928fe34d67@github.com>
References: <1MWMgluBwGY-FydUnpoksJ0q5sSvptrNMv6xwDszBQc=.a78cadad-1585-44d1-97d0-a7928fe34d67@github.com>
Message-ID: <Ewt6z3MSH1eJ8WgdlpCDLebEH7qVgBk-GDklBNAzQAc=.b55819b6-6783-48c6-8a7a-2495e900c8df@github.com>

> 8325082: Rename headers named 'heapRegion*' of G1

Lei Zaakjyu 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:

 - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8325082
 - rename
 - fix
 - reorder some headers
 - rename

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17666/files
  - new: https://git.openjdk.org/jdk/pull/17666/files/faa6f661..11628202

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17666&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17666&range=03-04

  Stats: 32057 lines in 1054 files changed: 14510 ins; 11387 del; 6160 mod
  Patch: https://git.openjdk.org/jdk/pull/17666.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17666/head:pull/17666

PR: https://git.openjdk.org/jdk/pull/17666

From amenkov at openjdk.org  Fri Feb 16 02:39:53 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 16 Feb 2024 02:39:53 GMT
Subject: RFR: 8324680: Replace NULL with nullptr in JVMTI generated code
In-Reply-To: <w1DMQMwGugoSs830xWYD6l7yoIR6v8dk5MnKYIY8t9w=.1ad08a17-8efc-4a71-88a5-78da29ce4ab4@github.com>
References: <w1DMQMwGugoSs830xWYD6l7yoIR6v8dk5MnKYIY8t9w=.1ad08a17-8efc-4a71-88a5-78da29ce4ab4@github.com>
Message-ID: <Z4jTlS1O_jO8Y6XkPJLB8QOg9t-kxBfxVaGSvkAS9hA=.38a305c7-4d5e-486e-82c3-187910966a81@github.com>

On Thu, 15 Feb 2024 08:46:43 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This enhancement replaces uses of NULL with nullptr in the XML-description files for JVMTI. These are the files `hotsport/share/prims/jvmti.xml` and `hotspot/share/prims/jvmti*.xls`.
> 
> The following files are auto-generated from the `jvmti.xml` and `*.xsl files` in the `build/<CFG>/variant-server/gensrc/jvmtifiles': `jvmti.h`, `jvmti.html`, `jvmtiEnter.cpp`, `jvmtiEnterTrace.cpp`, `jvmtiEnv.hpp`
> 
> This addresses a category of NULL uses that wasn't dealt with by:
>  [JDK-8299837](https://bugs.openjdk.org/browse/JDK-8299837).
>  
>  Testing:
>    - TBD: run mach5 tiers1-3

Marked as reviewed by amenkov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17866#pullrequestreview-1884223391

From stuefe at openjdk.org  Fri Feb 16 05:24:54 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 16 Feb 2024 05:24:54 GMT
Subject: RFR: 8325932: Replace ATTRIBUTE_NORETURN with direct [[noreturn]]
In-Reply-To: <tTaR4IXFQKtg9-tmJ-JAC4hfHNxB8rMhEyl5uxHOh7A=.33c5a2dd-a760-43eb-8518-c066786ec72d@github.com>
References: <tTaR4IXFQKtg9-tmJ-JAC4hfHNxB8rMhEyl5uxHOh7A=.33c5a2dd-a760-43eb-8518-c066786ec72d@github.com>
Message-ID: <-9MFtIvyTzruPUlYy0znroTYyTEHqGjJNNDz-MJw_ak=.bd006f33-791c-46e1-9373-3645cb359f85@github.com>

On Thu, 15 Feb 2024 09:10:51 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> With clang 13 being the minimum required JDK-8325878, the noreturn bug that requires the ATTRIBUTE_NORETURN workaround now vanishes, and we can use [[noreturn]] directly within HotSpot. We should remove the workaround as soon as possible, given the chance

Thank you for the explanations.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17868#issuecomment-1947777674

From stuefe at openjdk.org  Fri Feb 16 05:27:58 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 16 Feb 2024 05:27:58 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v22]
In-Reply-To: <3ypc8tpwlD08GbadhJOPw52Xdl82jHSs46kUTWXNAug=.1cc93da1-1db6-45a2-a8f4-9890a6078a53@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <LHKPKfz60cA4rddKKT51OUG7jxispd9M7A0io897pG0=.d8b3c965-755b-4500-a3f1-72b578045060@github.com>
 <F5C_TjQXv6KNpn3yN8J37_eSIOWtRYZT3RwNkSu-Xq0=.723d24c7-355e-42e6-80a7-b1b8aa476520@github.com>
 <3ypc8tpwlD08GbadhJOPw52Xdl82jHSs46kUTWXNAug=.1cc93da1-1db6-45a2-a8f4-9890a6078a53@github.com>
Message-ID: <MpzmVqcgU5R66UmGBnb_AmcmJvuX9XRxoYlEmvSs6zQ=.34de7d32-844b-40e0-adae-d100444fb605@github.com>

On Thu, 15 Feb 2024 17:50:23 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

> > Hi,
> > some remarks:
> > 
> > * there is no need for a copy for the first call to dll_load_library. Just hand in the string 1:1.
> > * I would only do the *.a fallback loading if the error indicates that the *.so file had not been there. So, only if EACCESS or ENOENT; in all other cases I would not do the fallback. E.g. if the *.so file cannot be loaded due to a header mismatch. See https://www.ibm.com/docs/en/aix/7.1?topic=l-load-loadandinit-subroutines
> > * Please use os::strdup.
> > * Please assert that the replacement string is smaller than the original string (which it should be, *.so is longer than *.a, but this is insurance against anyone changing the code in the future)
> > 
> > Thank you, Thomas
> 
> Sure working on them. May i know why we are using the load routine in the 2nd point ? . Currently we do a *.a fallback only when dlopen fails. Does load function save some steps here ?

I don't understand the question, sorry.

What I mean is when the first dlopen fails AND its error indicates the shared library had been missing, only then attempt the *.a fallback.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1947780121

From sspitsyn at openjdk.org  Fri Feb 16 06:12:54 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 16 Feb 2024 06:12:54 GMT
Subject: RFR: 8324680: Replace NULL with nullptr in JVMTI generated code
In-Reply-To: <w1DMQMwGugoSs830xWYD6l7yoIR6v8dk5MnKYIY8t9w=.1ad08a17-8efc-4a71-88a5-78da29ce4ab4@github.com>
References: <w1DMQMwGugoSs830xWYD6l7yoIR6v8dk5MnKYIY8t9w=.1ad08a17-8efc-4a71-88a5-78da29ce4ab4@github.com>
Message-ID: <trm635b41OSoXS93BSL9XdHbcqfRz1OFnQ8ypKf-k5Y=.db7edcc0-cd13-4b3d-891e-28703efbc9fa@github.com>

On Thu, 15 Feb 2024 08:46:43 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This enhancement replaces uses of NULL with nullptr in the XML-description files for JVMTI. These are the files `hotsport/share/prims/jvmti.xml` and `hotspot/share/prims/jvmti*.xls`.
> 
> The following files are auto-generated from the `jvmti.xml` and `*.xsl files` in the `build/<CFG>/variant-server/gensrc/jvmtifiles': `jvmti.h`, `jvmti.html`, `jvmtiEnter.cpp`, `jvmtiEnterTrace.cpp`, `jvmtiEnv.hpp`
> 
> This addresses a category of NULL uses that wasn't dealt with by:
>  [JDK-8299837](https://bugs.openjdk.org/browse/JDK-8299837).
>  
>  Testing:
>    - TBD: run mach5 tiers1-3

Thank you for review, Alex!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17866#issuecomment-1947814286

From dholmes at openjdk.org  Fri Feb 16 06:19:54 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 16 Feb 2024 06:19:54 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v9]
In-Reply-To: <FstoRCjpy6-9WOSrll3-SD9ChAsZ8KZ19LiEZEHmqvc=.d58aeafc-ddb4-4bc3-bb47-cc3471259cb5@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <FstoRCjpy6-9WOSrll3-SD9ChAsZ8KZ19LiEZEHmqvc=.d58aeafc-ddb4-4bc3-bb47-cc3471259cb5@github.com>
Message-ID: <zXOCQjxNT2WFopPpZYPqHrBqfm_uN12dAq0eBAa4CBg=.40c685be-e304-421c-b5cc-9c92f639ff89@github.com>

On Thu, 15 Feb 2024 19:55:08 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
>> The function returns the following structure:
>> 
>> 
>> typedef struct {
>>     jthread owner;
>>     jint entry_count;
>>     jint waiter_count;
>>     jthread* waiters;
>>     jint notify_waiter_count;
>>     jthread* notify_waiters;
>> } jvmtiMonitorUsage;
>> 
>> 
>> The following four fields are defined this way:
>> 
>> waiter_count  [jint] The number of threads waiting to own this monitor
>> waiters  [jthread*] The waiter_count waiting threads
>> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
>> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
>> 
>> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
>> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
>> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
>> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
>> This update makes it right.
>> 
>> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
>> 
>> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
>> 
>>   jvmti/GetObjectMonitorUsage/objmonusage001
>>   jvmti/GetObjectMonitorUsage/objmonusage003
>> 
>> 
>> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
>> 
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
>> 
>> 
>> 
>> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository.
>> 
>> Also, please see and review the related CSR:
>>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
>> 
>> The Release-Note is:
>> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage
>>  
>> Testing:
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: JDWP monitor_info spec clarification; removed debugging code from objmonusage001

Thanks for the test updates.

A couple of other queries.

src/hotspot/share/prims/jvmtiEnvBase.cpp line 1496:

> 1494:   nWant = wantList->length();
> 1495: 
> 1496:   if (mon != nullptr) {

Shouldn't the call to `get_pending_threads` only happen if `mon != nullptr`? Otherwise the `wantList` has to be empty.

src/hotspot/share/prims/jvmtiEnvBase.cpp line 1500:

> 1498:     for (int i = 0; i < nWait; i++) {
> 1499:       if (waiter == nullptr || (i != 0 && waiter == mon->first_waiter())) {
> 1500:         // robustness: the waiting list has gotten smaller

We are at a safepoint so I don't see how the wait list can shrink. I initially thought perhaps a waiter could timeout, but the code that does the timed park is wrapped in ` ThreadBlockInVMPreprocess` which will block at a safepoint if one is active.

-------------

PR Review: https://git.openjdk.org/jdk/pull/17680#pullrequestreview-1884365884
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1491992136
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1491997307

From dholmes at openjdk.org  Fri Feb 16 06:42:54 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 16 Feb 2024 06:42:54 GMT
Subject: RFR: 8325095: C2: bailout message broken: ResourceArea allocated
 string used after free
In-Reply-To: <8Bl6JSxb-fd1xAsKOMzBakRFuruoqJykP7JEn57k6qY=.717f89af-2aa7-439b-afd1-768dd39f51da@github.com>
References: <8Bl6JSxb-fd1xAsKOMzBakRFuruoqJykP7JEn57k6qY=.717f89af-2aa7-439b-afd1-768dd39f51da@github.com>
Message-ID: <rq3fN-YUemSSfCZsNcrhGHS96zHtYfFqrpEJy2J8rXs=.586eb2aa-a31a-4e31-b5b1-e79a0626ac84@github.com>

On Mon, 5 Feb 2024 16:02:57 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> **Problem**
> Bailout `failure_reason` strings used to be either `nullptr` or a static string. But with [JDK-8303951](https://bugs.openjdk.org/browse/JDK-8303951) I had introduced dynamic strings (e.g. formatted using `stringStream::as_string()`). These dynamic strings were ResourceArea allocated, and have a very limited life-span, i.e. withing the most recent ResourceMark scope. The pointer is passed to `Compile::_failure_reason`, which already might leave that ResourceMark scope, and the pointer is invalid. And then the pointer is further passed to `ciEnv::_failure_reason`. And finally, it even gets passed up to `CompileBroker::invoke_compiler_on_method`. When the string is finally printed for the bailout message, we already left original `ResourceMark` scope, and also the `Compile` and `ciEnv` scopes. The pointer now points to basically random data.
> 
> **Solution**
> Whenever a string is passed to an outer scope, I make a CHeap copy, and the outer scope is the owner of that copy.
> This way every scope is the owner of its own copy, and can allocate and deallocate according to its own strategy safely.
> 
> I introduced a utility class `CHeapStringHolder`:
>  - `set`: make local copy on CHeap.
>  - `clear`: free local copy. We before `set`, and in the destructor. Thus, when the holder goes out of scope, the memory is automatically freed.
> 
> We have these 4 scopes:
> - `ResourceMark`: It allocates from `ResourcArea`, and deallocation is taken care at the end of the ResourceMark scope.
> - `Compile`: We turn the `_failure_reason` from a `char*` into a `CHeapStringHolder`. We set `_failure_reason` while the `ResourceMark` is live.
> - `ciEnv`: We turn the `_failure_reason` from a `char*` into a `CHeapStringHolder`. We set `_failure_reason` while `Compile` is live.
> - `CompileTask`: We used to just set `failure_reason`, which assumes that the string is static or elsewhere managed. Now I use pattern available in other places of `CompileBroker::invoke_compiler_on_method`: duplicate the string with `os::strdup` from some other scope, and set `reason_on_C_heap = true`, which means that we are the owner of that copy, and are responsible for freeing it later. Not sure if that is a nice pattern, but I don't want to refactor that code and it does what I need it to do.

src/hotspot/share/utilities/cHeapStringHolder.cpp line 36:

> 34:     _string[len] = 0; // terminating null
> 35:     // Make sure it is written before the pointer is used again
> 36:     OrderAccess::storestore();

Is this internal string being exposed to other threads ??? That seems dangerous in general given this is a stackobj.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17710#discussion_r1492016569

From epeter at openjdk.org  Fri Feb 16 06:45:54 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 16 Feb 2024 06:45:54 GMT
Subject: RFR: 8325095: C2: bailout message broken: ResourceArea allocated
 string used after free
In-Reply-To: <rq3fN-YUemSSfCZsNcrhGHS96zHtYfFqrpEJy2J8rXs=.586eb2aa-a31a-4e31-b5b1-e79a0626ac84@github.com>
References: <8Bl6JSxb-fd1xAsKOMzBakRFuruoqJykP7JEn57k6qY=.717f89af-2aa7-439b-afd1-768dd39f51da@github.com>
 <rq3fN-YUemSSfCZsNcrhGHS96zHtYfFqrpEJy2J8rXs=.586eb2aa-a31a-4e31-b5b1-e79a0626ac84@github.com>
Message-ID: <-A0aftBX1F65cym1oz6To-OZaGQrrWvbkWEIFinVqYY=.07b2ac3a-f58e-4ea5-bf66-aa9b003545af@github.com>

On Fri, 16 Feb 2024 06:40:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> **Problem**
>> Bailout `failure_reason` strings used to be either `nullptr` or a static string. But with [JDK-8303951](https://bugs.openjdk.org/browse/JDK-8303951) I had introduced dynamic strings (e.g. formatted using `stringStream::as_string()`). These dynamic strings were ResourceArea allocated, and have a very limited life-span, i.e. withing the most recent ResourceMark scope. The pointer is passed to `Compile::_failure_reason`, which already might leave that ResourceMark scope, and the pointer is invalid. And then the pointer is further passed to `ciEnv::_failure_reason`. And finally, it even gets passed up to `CompileBroker::invoke_compiler_on_method`. When the string is finally printed for the bailout message, we already left original `ResourceMark` scope, and also the `Compile` and `ciEnv` scopes. The pointer now points to basically random data.
>> 
>> **Solution**
>> Whenever a string is passed to an outer scope, I make a CHeap copy, and the outer scope is the owner of that copy.
>> This way every scope is the owner of its own copy, and can allocate and deallocate according to its own strategy safely.
>> 
>> I introduced a utility class `CHeapStringHolder`:
>>  - `set`: make local copy on CHeap.
>>  - `clear`: free local copy. We before `set`, and in the destructor. Thus, when the holder goes out of scope, the memory is automatically freed.
>> 
>> We have these 4 scopes:
>> - `ResourceMark`: It allocates from `ResourcArea`, and deallocation is taken care at the end of the ResourceMark scope.
>> - `Compile`: We turn the `_failure_reason` from a `char*` into a `CHeapStringHolder`. We set `_failure_reason` while the `ResourceMark` is live.
>> - `ciEnv`: We turn the `_failure_reason` from a `char*` into a `CHeapStringHolder`. We set `_failure_reason` while `Compile` is live.
>> - `CompileTask`: We used to just set `failure_reason`, which assumes that the string is static or elsewhere managed. Now I use pattern available in other places of `CompileBroker::invoke_compiler_on_method`: duplicate the string with `os::strdup` from some other scope, and set `reason_on_C_heap = true`, which means that we are the owner of that copy, and are responsible for freeing it later. Not sure if that is a nice pattern, but I don't want to refactor that code and it does what I need it to do.
>
> src/hotspot/share/utilities/cHeapStringHolder.cpp line 36:
> 
>> 34:     _string[len] = 0; // terminating null
>> 35:     // Make sure it is written before the pointer is used again
>> 36:     OrderAccess::storestore();
> 
> Is this internal string being exposed to other threads ??? That seems dangerous in general given this is a stackobj.

@dholmes-ora I don't think it is exposed to other threads. It only goes as far up as CompileTask, so I think it always stays in the compile thread. I saw `OrderAccess::storestore()` in the `stringStream` code. But maybe I don't need it here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17710#discussion_r1492019459

From dholmes at openjdk.org  Fri Feb 16 07:02:54 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 16 Feb 2024 07:02:54 GMT
Subject: RFR: 8325095: C2: bailout message broken: ResourceArea allocated
 string used after free
In-Reply-To: <-A0aftBX1F65cym1oz6To-OZaGQrrWvbkWEIFinVqYY=.07b2ac3a-f58e-4ea5-bf66-aa9b003545af@github.com>
References: <8Bl6JSxb-fd1xAsKOMzBakRFuruoqJykP7JEn57k6qY=.717f89af-2aa7-439b-afd1-768dd39f51da@github.com>
 <rq3fN-YUemSSfCZsNcrhGHS96zHtYfFqrpEJy2J8rXs=.586eb2aa-a31a-4e31-b5b1-e79a0626ac84@github.com>
 <-A0aftBX1F65cym1oz6To-OZaGQrrWvbkWEIFinVqYY=.07b2ac3a-f58e-4ea5-bf66-aa9b003545af@github.com>
Message-ID: <XHuDGhMBxphmZQdgK0kiW3UGH2A_T9FFD5xnv-s_ssE=.ed4aed16-e511-415f-a8b6-3c88d8637b43@github.com>

On Fri, 16 Feb 2024 06:43:39 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> src/hotspot/share/utilities/cHeapStringHolder.cpp line 36:
>> 
>>> 34:     _string[len] = 0; // terminating null
>>> 35:     // Make sure it is written before the pointer is used again
>>> 36:     OrderAccess::storestore();
>> 
>> Is this internal string being exposed to other threads ??? That seems dangerous in general given this is a stackobj.
>
> @dholmes-ora I don't think it is exposed to other threads. It only goes as far up as CompileTask, so I think it always stays in the compile thread. I saw `OrderAccess::storestore()` in the `stringStream` code. But maybe I don't need it here?

`OrderAccess` is only needed for exchanging data across threads.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17710#discussion_r1492031296

From epeter at openjdk.org  Fri Feb 16 07:18:09 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 16 Feb 2024 07:18:09 GMT
Subject: RFR: 8325095: C2: bailout message broken: ResourceArea allocated
 string used after free [v2]
In-Reply-To: <XHuDGhMBxphmZQdgK0kiW3UGH2A_T9FFD5xnv-s_ssE=.ed4aed16-e511-415f-a8b6-3c88d8637b43@github.com>
References: <8Bl6JSxb-fd1xAsKOMzBakRFuruoqJykP7JEn57k6qY=.717f89af-2aa7-439b-afd1-768dd39f51da@github.com>
 <rq3fN-YUemSSfCZsNcrhGHS96zHtYfFqrpEJy2J8rXs=.586eb2aa-a31a-4e31-b5b1-e79a0626ac84@github.com>
 <-A0aftBX1F65cym1oz6To-OZaGQrrWvbkWEIFinVqYY=.07b2ac3a-f58e-4ea5-bf66-aa9b003545af@github.com>
 <XHuDGhMBxphmZQdgK0kiW3UGH2A_T9FFD5xnv-s_ssE=.ed4aed16-e511-415f-a8b6-3c88d8637b43@github.com>
Message-ID: <A_Za_x59z8RDKM4S4YFx-ErrGo7nSBSEG7cRavDFXNo=.72ade61a-1ebe-4df4-ab90-279841e5ac9c@github.com>

On Fri, 16 Feb 2024 07:00:26 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> @dholmes-ora I don't think it is exposed to other threads. It only goes as far up as CompileTask, so I think it always stays in the compile thread. I saw `OrderAccess::storestore()` in the `stringStream` code. But maybe I don't need it here?
>
> `OrderAccess` is only needed for exchanging data across threads.

@dholmes-ora ok, thanks for the comment! I removed it now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17710#discussion_r1492041569

From epeter at openjdk.org  Fri Feb 16 07:18:09 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 16 Feb 2024 07:18:09 GMT
Subject: RFR: 8325095: C2: bailout message broken: ResourceArea allocated
 string used after free [v2]
In-Reply-To: <8Bl6JSxb-fd1xAsKOMzBakRFuruoqJykP7JEn57k6qY=.717f89af-2aa7-439b-afd1-768dd39f51da@github.com>
References: <8Bl6JSxb-fd1xAsKOMzBakRFuruoqJykP7JEn57k6qY=.717f89af-2aa7-439b-afd1-768dd39f51da@github.com>
Message-ID: <iqVK2jP6-y3NweZYd_Y6Eo39GUH9hf8gFugp8aq3-dw=.54a735a9-9cf2-411d-89aa-19dcbef22937@github.com>

> **Problem**
> Bailout `failure_reason` strings used to be either `nullptr` or a static string. But with [JDK-8303951](https://bugs.openjdk.org/browse/JDK-8303951) I had introduced dynamic strings (e.g. formatted using `stringStream::as_string()`). These dynamic strings were ResourceArea allocated, and have a very limited life-span, i.e. withing the most recent ResourceMark scope. The pointer is passed to `Compile::_failure_reason`, which already might leave that ResourceMark scope, and the pointer is invalid. And then the pointer is further passed to `ciEnv::_failure_reason`. And finally, it even gets passed up to `CompileBroker::invoke_compiler_on_method`. When the string is finally printed for the bailout message, we already left original `ResourceMark` scope, and also the `Compile` and `ciEnv` scopes. The pointer now points to basically random data.
> 
> **Solution**
> Whenever a string is passed to an outer scope, I make a CHeap copy, and the outer scope is the owner of that copy.
> This way every scope is the owner of its own copy, and can allocate and deallocate according to its own strategy safely.
> 
> I introduced a utility class `CHeapStringHolder`:
>  - `set`: make local copy on CHeap.
>  - `clear`: free local copy. We before `set`, and in the destructor. Thus, when the holder goes out of scope, the memory is automatically freed.
> 
> We have these 4 scopes:
> - `ResourceMark`: It allocates from `ResourcArea`, and deallocation is taken care at the end of the ResourceMark scope.
> - `Compile`: We turn the `_failure_reason` from a `char*` into a `CHeapStringHolder`. We set `_failure_reason` while the `ResourceMark` is live.
> - `ciEnv`: We turn the `_failure_reason` from a `char*` into a `CHeapStringHolder`. We set `_failure_reason` while `Compile` is live.
> - `CompileTask`: We used to just set `failure_reason`, which assumes that the string is static or elsewhere managed. Now I use pattern available in other places of `CompileBroker::invoke_compiler_on_method`: duplicate the string with `os::strdup` from some other scope, and set `reason_on_C_heap = true`, which means that we are the owner of that copy, and are responsible for freeing it later. Not sure if that is a nice pattern, but I don't want to refactor that code and it does what I need it to do.

Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:

  remove OrderAccess::storestore() bc single threaded only

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17710/files
  - new: https://git.openjdk.org/jdk/pull/17710/files/c5b75b7c..127e08cc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17710&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17710&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17710.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17710/head:pull/17710

PR: https://git.openjdk.org/jdk/pull/17710

From aboldtch at openjdk.org  Fri Feb 16 07:21:02 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 16 Feb 2024 07:21:02 GMT
Subject: RFR: 8319801: Recursive lightweight locking: aarch64
 implementation [v19]
In-Reply-To: <_tgqW432lHQOEre0xCE4U7OBoXoNUoWBtDZ0nHxJwV4=.507d9fb9-cf25-43ab-9c73-7c251f534996@github.com>
References: <AE1nsnyRCUHR970jjg4feUm5f6E1GPJvea0ooC6dCgI=.73fff610-c0f6-422a-a45d-88187b37b9a2@github.com>
 <_tgqW432lHQOEre0xCE4U7OBoXoNUoWBtDZ0nHxJwV4=.507d9fb9-cf25-43ab-9c73-7c251f534996@github.com>
Message-ID: <k0RUezqq3fmHYZNLCi8BqnCGb_WqmgdOs_wdVCek2zg=.c864c8ae-6d21-487c-8df3-7c3703cb1c4d@github.com>

On Thu, 15 Feb 2024 10:25:21 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Implements the aarch64 port of JDK-8319796.
>> 
>> There are two major parts for the port implementation. The C2 part, and the part shared by the interpreter, C1 and the native call wrapper.
>> 
>> The biggest change for both parts is that we check the lock stack first and if it is a recursive lightweight [un]lock and in that case simply pop/push and finish successfully.
>> 
>> Only if the recursive lightweight [un]lock fails does it look at the mark word. 
>> 
>> For the shared part if it is an unstructured exit, the monitor is inflated or the mark word transition fails it calls into the runtime.
>> 
>> The C2 operates under a few more assumptions, that the locking is structured and balanced. This means that some checks can be elided. 
>> 
>> First this means that in C2 unlock if the obj is not on the top of the lock stack, it must be inflated. And reversely if we reach the inflated C2 unlock the obj is not on the lock stack. This second property makes it possible to avoid reading the owner (and checking if it is anonymous). Instead it can either just do an un-contended unlock by writing null to the owner, or if contention happens, simply write the thread to the owner and jump to the runtime. 
>> 
>> The aarch64 C2 port tries to avoid stronger memory semantics where ever possible. In C2 lock it first does a relaxed load of the mark word to check for inflation. Both lock and unlock uses a load/store exclusive register pair to transition the mark word.
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add common prefix for aliased Register variables

Thanks for all the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16608#issuecomment-1947871069

From aboldtch at openjdk.org  Fri Feb 16 07:21:02 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 16 Feb 2024 07:21:02 GMT
Subject: Integrated: 8319801: Recursive lightweight locking: aarch64
 implementation
In-Reply-To: <AE1nsnyRCUHR970jjg4feUm5f6E1GPJvea0ooC6dCgI=.73fff610-c0f6-422a-a45d-88187b37b9a2@github.com>
References: <AE1nsnyRCUHR970jjg4feUm5f6E1GPJvea0ooC6dCgI=.73fff610-c0f6-422a-a45d-88187b37b9a2@github.com>
Message-ID: <tbS-uB82TBJS-xdwFrlxUyR_x-7K_A779Me_l8j_tU0=.40e81709-0dba-4e99-a542-79daa20d4f12@github.com>

On Fri, 10 Nov 2023 13:00:52 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Implements the aarch64 port of JDK-8319796.
> 
> There are two major parts for the port implementation. The C2 part, and the part shared by the interpreter, C1 and the native call wrapper.
> 
> The biggest change for both parts is that we check the lock stack first and if it is a recursive lightweight [un]lock and in that case simply pop/push and finish successfully.
> 
> Only if the recursive lightweight [un]lock fails does it look at the mark word. 
> 
> For the shared part if it is an unstructured exit, the monitor is inflated or the mark word transition fails it calls into the runtime.
> 
> The C2 operates under a few more assumptions, that the locking is structured and balanced. This means that some checks can be elided. 
> 
> First this means that in C2 unlock if the obj is not on the top of the lock stack, it must be inflated. And reversely if we reach the inflated C2 unlock the obj is not on the lock stack. This second property makes it possible to avoid reading the owner (and checking if it is anonymous). Instead it can either just do an un-contended unlock by writing null to the owner, or if contention happens, simply write the thread to the owner and jump to the runtime. 
> 
> The aarch64 C2 port tries to avoid stronger memory semantics where ever possible. In C2 lock it first does a relaxed load of the mark word to check for inflation. Both lock and unlock uses a load/store exclusive register pair to transition the mark word.

This pull request has now been integrated.

Changeset: 18cea823
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/18cea823a173e1b8b48d276daeca67b2a5cf3584
Stats:     492 lines in 9 files changed: 354 ins; 80 del; 58 mod

8319801: Recursive lightweight locking: aarch64 implementation

Co-authored-by: Stefan Karlsson <stefank at openjdk.org>
Co-authored-by: Erik ?sterlund <eosterlund at openjdk.org>
Reviewed-by: rkennke, coleenp, dcubed, aph

-------------

PR: https://git.openjdk.org/jdk/pull/16608

From aph at openjdk.org  Fri Feb 16 08:37:58 2024
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 16 Feb 2024 08:37:58 GMT
Subject: RFR: 8314488: Compile the JDK as C++17 [v6]
In-Reply-To: <F7MGxuI0CLaL28Y7s7KhRW_NmgsCOnJLs5wnUlXjGk8=.f44adba9-e08c-4093-a13e-dd2851e94e97@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
 <b4HhbT5caIfCbrVveI6NDObiwUI2Sr0so68JBG6C0YU=.1734aaa7-aed4-478c-bbb6-de9af5c04ef9@github.com>
 <i3bo22m6I5cYhAMfktX-W_4-rrtyK6EPyK57QUi6Tco=.a18ddecb-440b-4c70-95ec-4b21fd1b3144@github.com>
 <KCC78U2X_if2XTRu1qNkeVXSQ672EyZFHbkl-OtP3U8=.9695b185-dc76-4d26-ae32-ceb254f5f275@github.com>
 <yq-FT47x7QF7L78fMxw3VvYAo_osUWzeUzxb5iJU3hE=.1899b72a-41f7-44b7-946f-84ca1339f1f8@github.com>
 <F7MGxuI0CLaL28Y7s7KhRW_NmgsCOnJLs5wnUlXjGk8=.f44adba9-e08c-4093-a13e-dd2851e94e97@github.com>
Message-ID: <NGRHe9BoTv7UWiYiu-kOQXbkFH7DbcS24syQFhhS3ag=.064ffdb5-10a6-4302-8b4a-e94c98bed0a3@github.com>

On Thu, 15 Feb 2024 17:11:34 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > Sure, you can always install a newer GCC than the system one, but it's another thing that makes it harder for people to build OpenJDK. Having said that, C++17 is nice to have.
> 
> @theRealAph I am still just hearing hand-waving "perhaps someone somewhere will have a somewhat harder time building the JDK". 

I'm going to ignore that rather insulting language.

> Yes, perhaps that is so. But that is very uncertain, and I have still not heard a single concrete example of where this would apply. In contrast, going to gcc 10 will clearly bring a benefit to all other platforms, since it allows us to synchronize the code base at C++17.

Well, hold on. You're implying that going to C++17 allows us to synchronize the code base at C++17. Sure, it does, but it's important also to discuss the pitfalls. And one of those pitfalls is that the system I'm typing this message on ? still in support ? won't be able to build the JDK without my first finding or building gcc 10 for it.

> In light of this, I think we need to hear some really compelling evidence of problems that would ensue if we raise the minimum to gcc 10. If nobody can produce such evidence, then to me it is a sign that this fear is not well-grounded, and we should proceed with this PR.

As the proposer of this change, the onus is on you to show the benefit. Certainly there are C++17 advantages, such as hex float constants. better templates, and so on. I guess the discussion of such advantages must have taken place elsewhere because it's not on the https://bugs.openjdk.org/browse/JDK-8314488 either.

To be clear: I do not object to this PR. I would like to use C++17.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1947960141

From thomas.stuefe at gmail.com  Fri Feb 16 08:49:15 2024
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Fri, 16 Feb 2024 09:49:15 +0100
Subject: Hotspot symbol visibility
In-Reply-To: <645132e0-687e-4f04-9e49-f90131294367@oracle.com>
References: <645132e0-687e-4f04-9e49-f90131294367@oracle.com>
Message-ID: <CAA-vtUy-VjCXmtUN6evZic9wRV7VHXzS-M6U+Jjqsy4zJkqx+A@mail.gmail.com>

I cannot contribute much to the discussion, but I think this is a valuable
effort. These broad exports from hotspot have always bemused me.

It is probably safe to hide C++ mangled symbols since those decorations are
compiler-specific anyway, no? So they cannot have worked in a reliable
fashion?

On Wed, Feb 14, 2024 at 11:06?AM Magnus Ihse Bursie <
magnus.ihse.bursie at oracle.com> wrote:

> I am currently pursuing improved build functionality for static
> libraries. One of the issues with static libraries are name collisions,
> which led me back to an old discussion about which symbols are exported
> from Hotspot, and how this is achieved. A long discussion is available
> in JDK-8017234 [1], which was created in 2013 and has been on the back
> burner ever since, coming back to life every now and then.
>
> There are basically two different problems here. They are both distinct
> and interrelated, and we likely need to solve both in tandem.
>
> The first problem is how Hotspot should say which symbols (functions)
> that should be exported from libjvm.so. The historical, and still used,
> system is to have a mapfile. In the "new" (not so new anymore) build
> system, this was simplified to a list of function names in
> make/data/hotspot-symbols, from which a mapfile is built.
>
> This is in contrast with how all other libraries in the JDK are built,
> and also with modern best practices. A better approach would be to
> annotate the functions that should be exported in the source code. In
> fact, such annotation already exists, even in Hotspot, as JNIEXPORT, but
> this is currently not used in the compilation of Hotspot.
>
> The second problem is that in addition to these explicitly exported
> functions, we also export basically all other functions as well in
> Hotspot. (So currently we could basically just forgo this complicated
> machinery and just export everything by default...)
>
> The reason for this seem somewhat unclear. The specifics are probably
> forever lost in the mists of time past, but the essential point is that
> these symbols are needed for SA to do it's job.
>
> So what we do is that we list all symbols in hotspot after compiling
> (but before linking), and selects some (most, I think) of them using
> regexp patterns, and add these to the mapfile.
>
> As long as we're doing this, we cannot stop using a mapfile, and we're
> stuck from progressing on point 1.
>
> My takeaway from the discussions is that we are most likely exporting a
> way too broad set of symbols to SA. It seems likely that this set can be
> drastically cut down. Actually getting an understanding of exactly which
> symbols SA need seem like a very good first step.
>
> So, is this a journey anyone would be interested in embarkering on? I
> will help as much as I can from a build PoV, but I have no clue
> whatsoever about what SA needs.
>
> /Magnus
>
> [1] https://bugs.openjdk.org/browse/JDK-8017234
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20240216/6dd7e581/attachment-0001.htm>

From aph at openjdk.org  Fri Feb 16 08:55:57 2024
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 16 Feb 2024 08:55:57 GMT
Subject: RFR: 8314488: Compile the JDK as C++17 [v6]
In-Reply-To: <NGRHe9BoTv7UWiYiu-kOQXbkFH7DbcS24syQFhhS3ag=.064ffdb5-10a6-4302-8b4a-e94c98bed0a3@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
 <b4HhbT5caIfCbrVveI6NDObiwUI2Sr0so68JBG6C0YU=.1734aaa7-aed4-478c-bbb6-de9af5c04ef9@github.com>
 <i3bo22m6I5cYhAMfktX-W_4-rrtyK6EPyK57QUi6Tco=.a18ddecb-440b-4c70-95ec-4b21fd1b3144@github.com>
 <KCC78U2X_if2XTRu1qNkeVXSQ672EyZFHbkl-OtP3U8=.9695b185-dc76-4d26-ae32-ceb254f5f275@github.com>
 <yq-FT47x7QF7L78fMxw3VvYAo_osUWzeUzxb5iJU3hE=.1899b72a-41f7-44b7-946f-84ca1339f1f8@github.com>
 <F7MGxuI0CLaL28Y7s7KhRW_NmgsCOnJLs5wnUlXjGk8=.f44adba9-e08c-4093-a13e-dd2851e94e97@github.com>
 <NGRHe9BoTv7UWiYiu-kOQXbkFH7DbcS24syQFhhS3ag=.064ffdb5-10a6-4302-8b4a-e94c98bed0a3@github.com>
Message-ID: <8W894WyNpek1tnlmVtRrGC8ZU3DXKzrPaDS24sQRwVM=.6dc95a73-6e0c-4cbd-b754-06d6ef3c1b34@github.com>

On Fri, 16 Feb 2024 08:35:29 GMT, Andrew Haley <aph at openjdk.org> wrote:

> 
> To be clear: I do not object to this PR. I would like to use C++17.

Maybe the advantages of C++17 have been discussed elsewhere, in which case all we need is a link to that discussion on the Bug page. Maybe it's just that we like to stay current, in which case all we need to do is say so on the Bug page.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1947984619

From sgehwolf at openjdk.org  Fri Feb 16 09:24:00 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 16 Feb 2024 09:24:00 GMT
Subject: RFR: JDK-8325116: Amend jdk.ContainerConfiguration by swap related
 value
In-Reply-To: <0UFSBwJVq31ZaVhhm7ssaR5jNa2AALYUgHtBWIQxi9Y=.b3e42160-9d6f-4e99-83ee-7f08f85d04c1@github.com>
References: <0UFSBwJVq31ZaVhhm7ssaR5jNa2AALYUgHtBWIQxi9Y=.b3e42160-9d6f-4e99-83ee-7f08f85d04c1@github.com>
Message-ID: <bh4_7uJBqRc5_HnwfyZp7_D2rifOVbKMO0O61EKnLkQ=.c212dac2-9eb3-488f-9e23-78541a7aa88f@github.com>

On Thu, 15 Feb 2024 08:26:40 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> jdk.ContainerInformation event could get amended to report the host total swap values for Linux like was done in
> https://bugs.openjdk.org/browse/JDK-8296671 by host total memory.
> Two additional fields could be added hostSwapTotal, maybe hostSwapFree;
> container free swap space in case we find a good implementation, could also be added to the implementation in os_linux.

Seems fine to me.

-------------

Marked as reviewed by sgehwolf (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17865#pullrequestreview-1884651112

From dlong at openjdk.org  Fri Feb 16 09:37:58 2024
From: dlong at openjdk.org (Dean Long)
Date: Fri, 16 Feb 2024 09:37:58 GMT
Subject: RFR: 8325095: C2: bailout message broken: ResourceArea allocated
 string used after free [v2]
In-Reply-To: <By6S6aqP_qRgnLVbbC1HcY2xvlYVkbGztxV1JdeUWIg=.0504185b-8bba-46a7-bbd0-dbef9b10be47@github.com>
References: <8Bl6JSxb-fd1xAsKOMzBakRFuruoqJykP7JEn57k6qY=.717f89af-2aa7-439b-afd1-768dd39f51da@github.com>
 <qnutyTCjwk_JFTIZcs-xW_PVAcFGogjJjCjeh1KAbTg=.fa1b659a-eac6-4f83-9eed-f9a0d4b239b5@github.com>
 <By6S6aqP_qRgnLVbbC1HcY2xvlYVkbGztxV1JdeUWIg=.0504185b-8bba-46a7-bbd0-dbef9b10be47@github.com>
Message-ID: <MBix7LMnmfO7Zh89a5LUN_jXroE12XATCOBhYe74nNI=.4342ad8e-1cd3-4b75-894d-7dabb32663d3@github.com>

On Thu, 15 Feb 2024 21:53:54 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> src/hotspot/share/ci/ciEnv.cpp line 1272:
>> 
>>> 1270:     // Reset failure reason; this one is more important.
>>> 1271:     _failure_reason.clear();
>>> 1272:     record_failure(reason);
>> 
>> @dean-long the tricky part is here, I think:
>> We are in `ciEnv::record_method_not_compilable`. Depending on above condition, we either update the failure reason, or don't. So there may already be an old failure reason (the first one) that we overwrite (with a second one) or leave.
>> 
>> This method is called from `Compile::record_method_not_compilable`. There, we also call `Compile::record_failure`, which sets `Compile::_failure_reason`, with no such condition.
>> 
>> We might for example decide to keep the old failure reason at ciEnv, but update the failure reason at Compile, at least that is how I read the code.
>> 
>> Hence, there can be multiple failure reasons around, I think. And I cannot fit multiple messages in a single buffer. Thus, I need some way to dynamically allocate.
>> 
>> Now: is this good or desirable? I don't know. Potentially having different failure messages at Compile and ciEnv - not sure if that is reasonable. We should probably discuss that. But for now I'm just trying to fix the code the way it works.
>> 
>> What do you think?
>
> I think initially we care only about "most" important failure because implementation allowed to report only one failure.
> If you can keep all failures AND report all of them it would be nice, I think. May be in separate RFE.
> 
> We should have only one place where we keep failures.

Reporting all failures might make sense for logging, but we can only report one reason, unless we want to do something like chained exceptions, which I don't think we need.  The different layers is already looking like a custom exception handling mechanism, unfortunately.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17710#discussion_r1492197115

From bulasevich at openjdk.org  Fri Feb 16 10:23:06 2024
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Fri, 16 Feb 2024 10:23:06 GMT
Subject: RFR: 8311248: Refactor CodeCache::initialize_heaps to simplify
 adding new CodeCache segments [v7]
In-Reply-To: <-V_dgQKhDrt1n0Zbk3qNa276jZBO822NlSvUv9AhpEA=.7a23c712-4b01-4aa7-acbe-8f5b5cca9002@github.com>
References: <-V_dgQKhDrt1n0Zbk3qNa276jZBO822NlSvUv9AhpEA=.7a23c712-4b01-4aa7-acbe-8f5b5cca9002@github.com>
Message-ID: <_HrFkS2z3Mk1RKtgVB010rsIx7aTolc_0iMDJox6eDc=.de2d7093-186f-48c0-859f-0769bf372b29@github.com>

> These changes clean up the logic and the code of allocating codecache segments and add more testing of it, to open a door for further optimization of code cache segmentation.  The goal was to keep the behavior as close to the existing behavior as possible, even if it's not quite logical.
> 
> Also, these changes better account for alignment - PrintFlagsFinal shows the final aligned segment sizes, and the segments fill the ReservedCodeCacheSize without gaps caused by alignment.

Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision:

  minor update. removed helper function as it caused many comments in the review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17244/files
  - new: https://git.openjdk.org/jdk/pull/17244/files/b54bbd9a..29e78046

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17244&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17244&range=05-06

  Stats: 39 lines in 1 file changed: 11 ins; 26 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17244.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17244/head:pull/17244

PR: https://git.openjdk.org/jdk/pull/17244

From bulasevich at openjdk.org  Fri Feb 16 10:23:07 2024
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Fri, 16 Feb 2024 10:23:07 GMT
Subject: RFR: 8311248: Refactor CodeCache::initialize_heaps to simplify
 adding new CodeCache segments [v6]
In-Reply-To: <g238prJeZJifjYvXhArq4pdWqINKt3hwMkgSQACy4aE=.b76328e7-beae-41b1-8695-32603728b7ad@github.com>
References: <-V_dgQKhDrt1n0Zbk3qNa276jZBO822NlSvUv9AhpEA=.7a23c712-4b01-4aa7-acbe-8f5b5cca9002@github.com>
 <qxAv0RZ-f98T5C_WY4wVLyTjEbDFAyFjMuUShnPstW8=.facce7d8-ec20-401d-b6d6-03da493822ed@github.com>
 <g238prJeZJifjYvXhArq4pdWqINKt3hwMkgSQACy4aE=.b76328e7-beae-41b1-8695-32603728b7ad@github.com>
Message-ID: <N6Tkuav5VeVdSnZcnbHOh34gLQ3KLfaMDmraIGaTgtA=.8c37bc2a-7c81-45f0-a873-c16b82ca1c87@github.com>

On Thu, 15 Feb 2024 22:38:21 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   set_size_of_unset_code_heap
>
> src/hotspot/share/code/codeCache.cpp line 202:
> 
>> 200: static void report_cache_size_error(const CodeHeapInfo& non_nmethod, const CodeHeapInfo& profiled,
>> 201:                                     const CodeHeapInfo& non_profiled, size_t cache_size) {
>> 202:   size_t total = non_nmethod.size;
> 
> You have already calculated the total, why not to reuse it?
> Also add an assert: `assert(total != ReservedCodeCacheSize, "Should be invoked to report an error")`

Okay. Let me remove this helper function. It complicates things more than it simplifies them.

> src/hotspot/share/code/codeCache.cpp line 220:
> 
>> 218:   }
>> 219:   else {
>> 220:     message.append(" is not equal to ReservedCodeCacheSize (" SIZE_FORMAT "K).", cache_size/K);
> 
> The correct message is " is less than ...". We call the function when they are not equal.

ok

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17244#discussion_r1492248284
PR Review Comment: https://git.openjdk.org/jdk/pull/17244#discussion_r1492250329

From sroy at openjdk.org  Fri Feb 16 12:27:58 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Fri, 16 Feb 2024 12:27:58 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v22]
In-Reply-To: <MpzmVqcgU5R66UmGBnb_AmcmJvuX9XRxoYlEmvSs6zQ=.34de7d32-844b-40e0-adae-d100444fb605@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <LHKPKfz60cA4rddKKT51OUG7jxispd9M7A0io897pG0=.d8b3c965-755b-4500-a3f1-72b578045060@github.com>
 <F5C_TjQXv6KNpn3yN8J37_eSIOWtRYZT3RwNkSu-Xq0=.723d24c7-355e-42e6-80a7-b1b8aa476520@github.com>
 <3ypc8tpwlD08GbadhJOPw52Xdl82jHSs46kUTWXNAug=.1cc93da1-1db6-45a2-a8f4-9890a6078a53@github.com>
 <MpzmVqcgU5R66UmGBnb_AmcmJvuX9XRxoYlEmvSs6zQ=.34de7d32-844b-40e0-adae-d100444fb605@github.com>
Message-ID: <mENLk-cgaGsIZ4gki3VJfC4qHzp2D3V3maLt5h5KASg=.6f2e5762-7b6b-49e9-be6d-8811aeed96fe@github.com>

On Fri, 16 Feb 2024 05:25:44 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > > Hi,
> > > some remarks:
> > > 
> > > * there is no need for a copy for the first call to dll_load_library. Just hand in the string 1:1.
> > > * I would only do the *.a fallback loading if the error indicates that the *.so file had not been there. So, only if EACCESS or ENOENT; in all other cases I would not do the fallback. E.g. if the *.so file cannot be loaded due to a header mismatch. See https://www.ibm.com/docs/en/aix/7.1?topic=l-load-loadandinit-subroutines
> > > * Please use os::strdup.
> > > * Please assert that the replacement string is smaller than the original string (which it should be, *.so is longer than *.a, but this is insurance against anyone changing the code in the future)
> > > 
> > > Thank you, Thomas
> > 
> > 
> > Sure working on them. May i know why we are using the load routine in the 2nd point ? . Currently we do a *.a fallback only when dlopen fails. Does load function save some steps here ?
> 
> I don't understand the question, sorry.
> 
> What I mean is when the first dlopen fails AND its error indicates the shared library had been missing, only then attempt the *.a fallback.

I see. I think i was referred to the init routine in the link. 
So you mean based on the errors inside dll_load_library, we set the errno to appropriate Error and then check for that before using the fallback , is that correct ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1948295997

From stuefe at openjdk.org  Fri Feb 16 12:37:56 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 16 Feb 2024 12:37:56 GMT
Subject: RFR: 8325095: C2: bailout message broken: ResourceArea allocated
 string used after free [v2]
In-Reply-To: <MBix7LMnmfO7Zh89a5LUN_jXroE12XATCOBhYe74nNI=.4342ad8e-1cd3-4b75-894d-7dabb32663d3@github.com>
References: <8Bl6JSxb-fd1xAsKOMzBakRFuruoqJykP7JEn57k6qY=.717f89af-2aa7-439b-afd1-768dd39f51da@github.com>
 <qnutyTCjwk_JFTIZcs-xW_PVAcFGogjJjCjeh1KAbTg=.fa1b659a-eac6-4f83-9eed-f9a0d4b239b5@github.com>
 <By6S6aqP_qRgnLVbbC1HcY2xvlYVkbGztxV1JdeUWIg=.0504185b-8bba-46a7-bbd0-dbef9b10be47@github.com>
 <MBix7LMnmfO7Zh89a5LUN_jXroE12XATCOBhYe74nNI=.4342ad8e-1cd3-4b75-894d-7dabb32663d3@github.com>
Message-ID: <fUIR8mpl31uEeB5_iI__2ZT8beBfRIIz6vhAwly60EE=.08bab015-655f-4ad1-b71f-018e1c1b79d8@github.com>

On Fri, 16 Feb 2024 09:35:23 GMT, Dean Long <dlong at openjdk.org> wrote:

>> I think initially we care only about "most" important failure because implementation allowed to report only one failure.
>> If you can keep all failures AND report all of them it would be nice, I think. May be in separate RFE.
>> 
>> We should have only one place where we keep failures.
>
> Reporting all failures might make sense for logging, but we can only report one reason, unless we want to do something like chained exceptions, which I don't think we need.  The different layers is already looking like a custom exception handling mechanism, unfortunately.

Piling on... I opt for keeping this code simple. A list of subsequent failure states could easily be part of logging.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17710#discussion_r1492391705

From stuefe at openjdk.org  Fri Feb 16 12:37:58 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 16 Feb 2024 12:37:58 GMT
Subject: RFR: 8325095: C2: bailout message broken: ResourceArea allocated
 string used after free [v2]
In-Reply-To: <iqVK2jP6-y3NweZYd_Y6Eo39GUH9hf8gFugp8aq3-dw=.54a735a9-9cf2-411d-89aa-19dcbef22937@github.com>
References: <8Bl6JSxb-fd1xAsKOMzBakRFuruoqJykP7JEn57k6qY=.717f89af-2aa7-439b-afd1-768dd39f51da@github.com>
 <iqVK2jP6-y3NweZYd_Y6Eo39GUH9hf8gFugp8aq3-dw=.54a735a9-9cf2-411d-89aa-19dcbef22937@github.com>
Message-ID: <jqqrLSVksbMxHDSRUlWJIn2RQBqJNmqX1zWJpimejZ4=.df378fba-ba92-48d9-a104-cc507b19471e@github.com>

On Fri, 16 Feb 2024 07:18:09 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> **Problem**
>> Bailout `failure_reason` strings used to be either `nullptr` or a static string. But with [JDK-8303951](https://bugs.openjdk.org/browse/JDK-8303951) I had introduced dynamic strings (e.g. formatted using `stringStream::as_string()`). These dynamic strings were ResourceArea allocated, and have a very limited life-span, i.e. withing the most recent ResourceMark scope. The pointer is passed to `Compile::_failure_reason`, which already might leave that ResourceMark scope, and the pointer is invalid. And then the pointer is further passed to `ciEnv::_failure_reason`. And finally, it even gets passed up to `CompileBroker::invoke_compiler_on_method`. When the string is finally printed for the bailout message, we already left original `ResourceMark` scope, and also the `Compile` and `ciEnv` scopes. The pointer now points to basically random data.
>> 
>> **Solution**
>> Whenever a string is passed to an outer scope, I make a CHeap copy, and the outer scope is the owner of that copy.
>> This way every scope is the owner of its own copy, and can allocate and deallocate according to its own strategy safely.
>> 
>> I introduced a utility class `CHeapStringHolder`:
>>  - `set`: make local copy on CHeap.
>>  - `clear`: free local copy. We before `set`, and in the destructor. Thus, when the holder goes out of scope, the memory is automatically freed.
>> 
>> We have these 4 scopes:
>> - `ResourceMark`: It allocates from `ResourcArea`, and deallocation is taken care at the end of the ResourceMark scope.
>> - `Compile`: We turn the `_failure_reason` from a `char*` into a `CHeapStringHolder`. We set `_failure_reason` while the `ResourceMark` is live.
>> - `ciEnv`: We turn the `_failure_reason` from a `char*` into a `CHeapStringHolder`. We set `_failure_reason` while `Compile` is live.
>> - `CompileTask`: We used to just set `failure_reason`, which assumes that the string is static or elsewhere managed. Now I use pattern available in other places of `CompileBroker::invoke_compiler_on_method`: duplicate the string with `os::strdup` from some other scope, and set `reason_on_C_heap = true`, which means that we are the owner of that copy, and are responsible for freeing it later. Not sure if that is a nice pattern, but I don't want to refactor that code and it does what I need it to do.
>
> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove OrderAccess::storestore() bc single threaded only

src/hotspot/share/utilities/cHeapStringHolder.hpp line 41:

> 39:     _memflags(memflags), _string(nullptr) {}
> 40:   ~CHeapStringHolder() { clear(); };
> 41:   NONCOPYABLE(CHeapStringHolder);

I'd opt for a use-case-specific class inside compiler. It would allow you to hard-code mtCompiler, simplifying the code, and to log with UL into the compiler log when the failure reason is changed.

A new generic string class opens a whole can of bikeshedding worms, e.g. whether to make it mutable, how best to specify MEMFLAGS etc... I would avoid that, especially since the added value fo this helper class is slim.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17710#discussion_r1492399102

From ihse at openjdk.org  Fri Feb 16 12:43:25 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 16 Feb 2024 12:43:25 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck [v2]
In-Reply-To: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
Message-ID: <ccnGBDgKifqtHAXAlfcdzACsqJG68fY7-TjtsAnN_p8=.afd45aec-c57f-4911-88d2-7988768ccad9@github.com>

> Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes).
> 
> I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Replace spaces with \t in test properties file

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17871/files
  - new: https://git.openjdk.org/jdk/pull/17871/files/3faa912e..e1c9c0f0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17871&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17871&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17871.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17871/head:pull/17871

PR: https://git.openjdk.org/jdk/pull/17871

From ihse at openjdk.org  Fri Feb 16 12:43:25 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 16 Feb 2024 12:43:25 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck [v2]
In-Reply-To: <RtDj7nYzLQTAHvuthfA12JIjqYTM7LkXy92QXXib4jY=.62dbc402-ade5-48be-9e7a-1ca1091899d4@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
 <Ksqjgi78ueQiu4oDhQ2d2wVT7a9bBAoMDGQ3CZnxH3Q=.ac125065-25c8-4c8c-b66b-c86f7523203b@github.com>
 <C2_NdHV3EpjVwEflvV6QcNdno8BgU9P3p2YZf1mQ3E8=.9e447ca9-8d6d-4ef4-9d99-14bd10d1c92e@github.com>
 <osmSAGyuE-qyC6sjVT_UjfRd2CfUQHuKFjlvmDOW-3Y=.b8a009f9-e995-42e7-afed-af83a016ff2b@github.com>
 <oX6tKgqTMzsDdSFj-X-EXtJS-20BsyiMYBacmxBTzTk=.b6eb0e9d-9940-479e-b70b-75a446e43e1c@github.com>
 <Si89vBx8-kmdHyp9_XHJyFMD5oVir2mKhgwOcO281CE=.c387b74a-b09c-4213-8561-8e111f08f855@github.com>
 <RtDj7nYzLQTAHvuthfA12JIjqYTM7LkXy92QXXib4jY=.62dbc402-ade5-48be-9e7a-1ca1091899d4@github.com>
Message-ID: <gQYN5tDVDEdGZVHhgOHMz2IvGZn4iam8xh4Xx3jKPFk=.55c92a6d-68dd-4838-a2f8-840b4a66e4c2@github.com>

On Thu, 15 Feb 2024 17:53:41 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> `\u000b` is VT   (vertical tab)  
>> `\u0009` or `\t` perhaps?
>
> Right. `\t` is better to avoid such a mistake.

Ok, fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1492403403

From aboldtch at openjdk.org  Fri Feb 16 12:44:07 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 16 Feb 2024 12:44:07 GMT
Subject: RFR: 8325870: Zap end padding bits for ArrayOops in non-release builds
Message-ID: <xgOWw0IQ0eQC0CDEqok0nnpLs4mxaJFL_rsUzutCnfI=.76d226fe-e9a4-4d05-8440-53df8d1dea00@github.com>

Make `ObjArrayAllocator` zap the end padding bits in not PRODUCT builds.

Issues like [JDK-8325074](https://bugs.openjdk.org/browse/JDK-8325074) / #17863 would then reproduce deterministically. Avoid future regressions.

Guarded `Copy::fill_to_bytes`, it was not clear if or how it handles `count == 0`. Given that almost all dispatch to memset, the `count == 0` would probably be alright, but as `obj_end - padding_in_bytes` may point beyond an object and thus outside the heap it seems prudent to guard it (I believe memset requires a valid pointer).

-------------

Commit messages:
 - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8325870
 - 8325870: Zap end padding bits for ArrayOops in non-release builds

Changes: https://git.openjdk.org/jdk/pull/17864/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17864&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8325870
  Stats: 23 lines in 4 files changed: 23 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17864.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17864/head:pull/17864

PR: https://git.openjdk.org/jdk/pull/17864

From ihse at openjdk.org  Fri Feb 16 12:45:59 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 16 Feb 2024 12:45:59 GMT
Subject: RFR: 8314488: Compile the JDK as C++17 [v6]
In-Reply-To: <b4HhbT5caIfCbrVveI6NDObiwUI2Sr0so68JBG6C0YU=.1734aaa7-aed4-478c-bbb6-de9af5c04ef9@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
 <b4HhbT5caIfCbrVveI6NDObiwUI2Sr0so68JBG6C0YU=.1734aaa7-aed4-478c-bbb6-de9af5c04ef9@github.com>
Message-ID: <thctbcato1Bz1XDUBDRZagYtDn4ycbwHLSEiD8p04vA=.1b758366-f4ef-430f-a7c2-0598f1161593@github.com>

On Thu, 11 Jan 2024 13:23:45 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Compile the JDK as C++17, enabling the use of all C++17 language features
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Require clang 13 in toolchain.m4

I think Kim's approach here -- to separate compiler upgrades from C++17 usage -- is the right way. Then we can discuss each part separately -- what version is suitable for each compiler, and then -- if or when we end up with all compilers supporting C++17 -- we can come back to the discussion of whether that is a good idea.

To be clear: my goal here was not as much the C++17 as getting a compiler bump, especially for getting rid of old buggy ones. I kind of piggybacked that discussion here, but once again, it is better to take that separately.

I also apologize for my hash expressions. :( I did not mean to insult anyone.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1948323482

From stuefe at openjdk.org  Fri Feb 16 12:53:01 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 16 Feb 2024 12:53:01 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v22]
In-Reply-To: <mENLk-cgaGsIZ4gki3VJfC4qHzp2D3V3maLt5h5KASg=.6f2e5762-7b6b-49e9-be6d-8811aeed96fe@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <LHKPKfz60cA4rddKKT51OUG7jxispd9M7A0io897pG0=.d8b3c965-755b-4500-a3f1-72b578045060@github.com>
 <F5C_TjQXv6KNpn3yN8J37_eSIOWtRYZT3RwNkSu-Xq0=.723d24c7-355e-42e6-80a7-b1b8aa476520@github.com>
 <3ypc8tpwlD08GbadhJOPw52Xdl82jHSs46kUTWXNAug=.1cc93da1-1db6-45a2-a8f4-9890a6078a53@github.com>
 <MpzmVqcgU5R66UmGBnb_AmcmJvuX9XRxoYlEmvSs6zQ=.34de7d32-844b-40e0-adae-d100444fb605@github.com>
 <mENLk-cgaGsIZ4gki3VJfC4qHzp2D3V3maLt5h5KASg=.6f2e5762-7b6b-49e9-be6d-8811aeed96fe@github.com>
Message-ID: <Fkts1yURlLD-wbc7mvHBNlhe2AilyyETaJuQ0QS2YEU=.2ad2349c-c774-4058-b3da-7a2cd9ea6f11@github.com>

On Fri, 16 Feb 2024 12:25:39 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

> > > > Hi,
> > > > some remarks:
> > > > 
> > > > * there is no need for a copy for the first call to dll_load_library. Just hand in the string 1:1.
> > > > * I would only do the *.a fallback loading if the error indicates that the *.so file had not been there. So, only if EACCESS or ENOENT; in all other cases I would not do the fallback. E.g. if the *.so file cannot be loaded due to a header mismatch. See https://www.ibm.com/docs/en/aix/7.1?topic=l-load-loadandinit-subroutines
> > > > * Please use os::strdup.
> > > > * Please assert that the replacement string is smaller than the original string (which it should be, *.so is longer than *.a, but this is insurance against anyone changing the code in the future)
> > > > 
> > > > Thank you, Thomas
> > > 
> > > 
> > > Sure working on them. May i know why we are using the load routine in the 2nd point ? . Currently we do a *.a fallback only when dlopen fails. Does load function save some steps here ?
> > 
> > 
> > I don't understand the question, sorry.
> > What I mean is when the first dlopen fails AND its error indicates the shared library had been missing, only then attempt the *.a fallback.
> 
> I see. I think i was referred to the init routine in the link.

Ah, okay. No, IBMs dlopen page for AIX refers to this page for the list of possible error codes; I assume dlopen just uses these functions under the hood.

> So you mean based on the errors inside dll_load_library, we set the errno to appropriate Error and then check for that before using the fallback , is that correct ?

No. I mean distinguish whether dlopen fails because it could not find the file (a valid reason to retry with *.a) or failed for another reason (which would not be a valid reason to retry with *.a).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1948333340

From coleenp at openjdk.org  Fri Feb 16 12:55:54 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 16 Feb 2024 12:55:54 GMT
Subject: RFR: 8324680: Replace NULL with nullptr in JVMTI generated code
In-Reply-To: <w1DMQMwGugoSs830xWYD6l7yoIR6v8dk5MnKYIY8t9w=.1ad08a17-8efc-4a71-88a5-78da29ce4ab4@github.com>
References: <w1DMQMwGugoSs830xWYD6l7yoIR6v8dk5MnKYIY8t9w=.1ad08a17-8efc-4a71-88a5-78da29ce4ab4@github.com>
Message-ID: <iMrxyWazwNAwTOEHDbIi-TQJffprJEDfh-xxLWWXaNQ=.52f1cdef-80ba-404a-a10e-a747b1e57c9e@github.com>

On Thu, 15 Feb 2024 08:46:43 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This enhancement replaces uses of NULL with nullptr in the XML-description files for JVMTI. These are the files `hotsport/share/prims/jvmti.xml` and `hotspot/share/prims/jvmti*.xls`.
> 
> The following files are auto-generated from the `jvmti.xml` and `*.xsl files` in the `build/<CFG>/variant-server/gensrc/jvmtifiles': `jvmti.h`, `jvmti.html`, `jvmtiEnter.cpp`, `jvmtiEnterTrace.cpp`, `jvmtiEnv.hpp`
> 
> This addresses a category of NULL uses that wasn't dealt with by:
>  [JDK-8299837](https://bugs.openjdk.org/browse/JDK-8299837).
>  
>  Testing:
>    - TBD: run mach5 tiers1-3

Looks good, thanks for fixing this.

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17866#pullrequestreview-1885068558

From stefank at openjdk.org  Fri Feb 16 12:57:53 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 16 Feb 2024 12:57:53 GMT
Subject: RFR: 8325870: Zap end padding bits for ArrayOops in non-release
 builds
In-Reply-To: <xgOWw0IQ0eQC0CDEqok0nnpLs4mxaJFL_rsUzutCnfI=.76d226fe-e9a4-4d05-8440-53df8d1dea00@github.com>
References: <xgOWw0IQ0eQC0CDEqok0nnpLs4mxaJFL_rsUzutCnfI=.76d226fe-e9a4-4d05-8440-53df8d1dea00@github.com>
Message-ID: <A6G19sxdEID2gPz4IrACb__TjeTplZQrarOCA2dx5Xo=.d895a653-4442-468e-b161-8ff088d3878a@github.com>

On Thu, 15 Feb 2024 07:25:48 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Make `ObjArrayAllocator` zap the end padding bits in not PRODUCT builds.
> 
> Issues like [JDK-8325074](https://bugs.openjdk.org/browse/JDK-8325074) / #17863 would then reproduce deterministically. Avoid future regressions.
> 
> Guarded `Copy::fill_to_bytes`, it was not clear if or how it handles `count == 0`. Given that almost all dispatch to memset, the `count == 0` would probably be alright, but as `obj_end - padding_in_bytes` may point beyond an object and thus outside the heap it seems prudent to guard it (I believe memset requires a valid pointer).

Marked as reviewed by stefank (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17864#pullrequestreview-1885076177

From erikj at openjdk.org  Fri Feb 16 13:39:56 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 16 Feb 2024 13:39:56 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck [v2]
In-Reply-To: <ccnGBDgKifqtHAXAlfcdzACsqJG68fY7-TjtsAnN_p8=.afd45aec-c57f-4911-88d2-7988768ccad9@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
 <ccnGBDgKifqtHAXAlfcdzACsqJG68fY7-TjtsAnN_p8=.afd45aec-c57f-4911-88d2-7988768ccad9@github.com>
Message-ID: <EG72V-Kg8FWuzTzqCGrfpb3fX_WIq4oybS3sljVlPGY=.400d3c9f-a361-4515-8c6f-6a465b89adc0@github.com>

On Fri, 16 Feb 2024 12:43:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes).
>> 
>> I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace spaces with \t in test properties file

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17871#pullrequestreview-1885177994

From ayang at openjdk.org  Fri Feb 16 13:46:54 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 16 Feb 2024 13:46:54 GMT
Subject: RFR: 8325870: Zap end padding bits for ArrayOops in non-release
 builds
In-Reply-To: <xgOWw0IQ0eQC0CDEqok0nnpLs4mxaJFL_rsUzutCnfI=.76d226fe-e9a4-4d05-8440-53df8d1dea00@github.com>
References: <xgOWw0IQ0eQC0CDEqok0nnpLs4mxaJFL_rsUzutCnfI=.76d226fe-e9a4-4d05-8440-53df8d1dea00@github.com>
Message-ID: <wTGLtEu_vKU902qhNVmZkQ6_-_N6LKaBSHA09lvvDe4=.0ba33c9b-abc9-43c2-b008-7ce931a85ced@github.com>

On Thu, 15 Feb 2024 07:25:48 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Make `ObjArrayAllocator` zap the end padding bits in not PRODUCT builds.
> 
> Issues like [JDK-8325074](https://bugs.openjdk.org/browse/JDK-8325074) / #17863 would then reproduce deterministically. Avoid future regressions.
> 
> Guarded `Copy::fill_to_bytes`, it was not clear if or how it handles `count == 0`. Given that almost all dispatch to memset, the `count == 0` would probably be alright, but as `obj_end - padding_in_bytes` may point beyond an object and thus outside the heap it seems prudent to guard it (I believe memset requires a valid pointer).

src/hotspot/share/gc/shared/memAllocator.cpp line 427:

> 425:   const address obj_end = reinterpret_cast<address>(mem) + size_in_bytes;
> 426: 
> 427:   const size_t padding_in_bytes = size_in_bytes - base_offset_in_bytes - length_in_bytes;

Since this is unsigned subtraction, could you add a assert that `size_in_bytes` is larger or equal? (Or calculate `zap_start = obj_start + offset + length` and compare it with `obj_end`.)

src/hotspot/share/utilities/globalDefinitions.hpp line 1038:

> 1036: const int      uninitBlockPad   = 0xF1;                     // value used to zap newly malloc'd blocks.
> 1037: const juint    uninitMetaWordVal= 0xf7f7f7f7;               // value used to zap newly allocated metachunk
> 1038: const jubyte   heapPaddingByte  = 0xBD;                     // value used to zap object padding in the heap

Could it have a `Val` suffix like its neighbors?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17864#discussion_r1492474049
PR Review Comment: https://git.openjdk.org/jdk/pull/17864#discussion_r1492468279

From ddong at openjdk.org  Fri Feb 16 13:51:04 2024
From: ddong at openjdk.org (Denghui Dong)
Date: Fri, 16 Feb 2024 13:51:04 GMT
Subject: RFR: 8326012: JFR: Event for safepoint timeout
Message-ID: <68hS0kQgtDIk4ioAJj_r0_GLT6h0lcif6Daj6WRwxlI=.40c2a6e7-70a8-4954-bcde-9318ee311028@github.com>

There are now some JFR events related to safepoint. When time-to-safepoint (aka ttsp) is too long, these events could not be very helpful since based on them we cannot know which threads cause it and what those threads are doing.

Users can use `-XX:+SafepointTimeout -XX:SafepointTimeoutDelay=100` to see the threads that don't reach safepoint in time but without stack traces. Using `-XX:+ AbortVMOnSafepointTimeout` can capture the stack traces but it crashes the process, hence it's not sensible to enable the flag in production.

This patch adds a new JFR event `EventSafepoint` to record the threads that causes ttsp too long.

This event includes two fields:

- safepointId: the relevant safepoint id
- timeExceeded: the amount of time exceeding `SafepointTimeoutDelay` used by the thread to reach safepoint

In the current version, this event records the stack of those problematic threads when they finally reach safepoint. Hence, there is a bias, but it's still helpful to deduce the root place.

A better implementation is to record a more accurate stack, but this will increase complexity. At the same time, the native stack may also be important for this problem, but it is not currently supported by JFR.

Any input would be greatly appreciated.

-------------

Commit messages:
 - update
 - 8326012: JFR: Event for safepoint timeout

Changes: https://git.openjdk.org/jdk/pull/17888/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17888&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8326012
  Stats: 143 lines in 7 files changed: 136 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/17888.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17888/head:pull/17888

PR: https://git.openjdk.org/jdk/pull/17888

From ddong at openjdk.org  Fri Feb 16 14:03:21 2024
From: ddong at openjdk.org (Denghui Dong)
Date: Fri, 16 Feb 2024 14:03:21 GMT
Subject: RFR: 8326012: JFR: Event for safepoint timeout [v2]
In-Reply-To: <68hS0kQgtDIk4ioAJj_r0_GLT6h0lcif6Daj6WRwxlI=.40c2a6e7-70a8-4954-bcde-9318ee311028@github.com>
References: <68hS0kQgtDIk4ioAJj_r0_GLT6h0lcif6Daj6WRwxlI=.40c2a6e7-70a8-4954-bcde-9318ee311028@github.com>
Message-ID: <MOBmQP7eddXhC1DclBriDy1zdy7xYQ8ZnvZ6XFv8mX8=.f54da08e-fb3b-47aa-b068-bc1f91815e61@github.com>

> There are now some JFR events related to safepoint. When time-to-safepoint (aka ttsp) is too long, these events could not be very helpful since based on them we cannot know which threads cause it and what those threads are doing.
> 
> Users can use `-XX:+SafepointTimeout -XX:SafepointTimeoutDelay=100` to see the threads that don't reach safepoint in time but without stack traces. Using `-XX:+ AbortVMOnSafepointTimeout` can capture the stack traces but it crashes the process, hence it's not sensible to enable the flag in production.
> 
> This patch adds a new JFR event `EventSafepoint` to record the threads that cause ttsp too long.
> 
> This event includes two fields:
> 
> - safepointId: the relevant safepoint id
> - timeExceeded: the amount of time exceeding `SafepointTimeoutDelay` used by the thread to reach safepoint
> 
> In the current version, this event records the stack of those problematic threads when they finally reach safepoint. Hence, there is a bias, but it's still helpful to deduce the root place.
> 
> A better implementation is to record a more accurate stack, but this will increase complexity. At the same time, the native stack may also be important for this problem, but it is not currently supported by JFR.
> 
> Any input would be greatly appreciated.
> 
> Testing: jdk/jdk/jfr

Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:

  remove debug code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17888/files
  - new: https://git.openjdk.org/jdk/pull/17888/files/5f374898..1e831de7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17888&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17888&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17888.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17888/head:pull/17888

PR: https://git.openjdk.org/jdk/pull/17888

From duke at openjdk.org  Fri Feb 16 14:16:56 2024
From: duke at openjdk.org (Lei Zaakjyu)
Date: Fri, 16 Feb 2024 14:16:56 GMT
Subject: RFR: 8325082: Rename headers named 'heapRegion*' of G1 [v3]
In-Reply-To: <SY0M3nUsgN0i5egqg28W4j6pICWWRZ2ixU_XU5oR8qI=.f21c44ff-5acd-4f8a-b7f0-e6332c1fbf81@github.com>
References: <1MWMgluBwGY-FydUnpoksJ0q5sSvptrNMv6xwDszBQc=.a78cadad-1585-44d1-97d0-a7928fe34d67@github.com>
 <p9f42d634nvSGvduMCBA3FUTq1V9ZIPUstJ8IpeuyWg=.6693e68b-0060-4f23-af4d-691dca3b94bb@github.com>
 <SY0M3nUsgN0i5egqg28W4j6pICWWRZ2ixU_XU5oR8qI=.f21c44ff-5acd-4f8a-b7f0-e6332c1fbf81@github.com>
Message-ID: <a-yGlCqCFaCddkLhkRAhcNCgaS9BOtLbTxLL-n8r-VI=.5375ca5a-ac46-4c24-a403-2a4fa9540e3a@github.com>

On Wed, 14 Feb 2024 17:59:31 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> `src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/HeapRegion.java` and related files should be updated as well.

I think we should let the cpp part go first. Could you please tell me the relationship between 'jdk.hotspot.agent' and the source files of hotspot?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17666#issuecomment-1948460429

From egahlin at openjdk.org  Fri Feb 16 14:26:54 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 16 Feb 2024 14:26:54 GMT
Subject: RFR: 8326012: JFR: Event for safepoint timeout [v2]
In-Reply-To: <MOBmQP7eddXhC1DclBriDy1zdy7xYQ8ZnvZ6XFv8mX8=.f54da08e-fb3b-47aa-b068-bc1f91815e61@github.com>
References: <68hS0kQgtDIk4ioAJj_r0_GLT6h0lcif6Daj6WRwxlI=.40c2a6e7-70a8-4954-bcde-9318ee311028@github.com>
 <MOBmQP7eddXhC1DclBriDy1zdy7xYQ8ZnvZ6XFv8mX8=.f54da08e-fb3b-47aa-b068-bc1f91815e61@github.com>
Message-ID: <TY0pv8iO2zqAUpVIhgShHYCONJYM9dcJCladEHoWDYw=.2d6d78e0-122a-46dc-be38-d3fc4cbd0272@github.com>

On Fri, 16 Feb 2024 14:03:21 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> There are now some JFR events related to safepoint. When time-to-safepoint (aka ttsp) is too long, these events could not be very helpful since based on them we cannot know which threads cause it and what those threads are doing.
>> 
>> Users can use `-XX:+SafepointTimeout -XX:SafepointTimeoutDelay=100` to see the threads that don't reach safepoint in time but without stack traces. Using `-XX:+ AbortVMOnSafepointTimeout` can capture the stack traces but it crashes the process, hence it's not sensible to enable the flag in production.
>> 
>> This patch adds a new JFR event `EventSafepoint` to record the threads that cause ttsp too long.
>> 
>> This event includes two fields:
>> 
>> - safepointId: the relevant safepoint id
>> - timeExceeded: the amount of time exceeding `SafepointTimeoutDelay` used by the thread to reach safepoint
>> 
>> In the current version, this event records the stack of those problematic threads when they finally reach safepoint. Hence, there is a bias, but it's still helpful to deduce the root place.
>> 
>> A better implementation is to record a more accurate stack, but this will increase complexity. At the same time, the native stack may also be important for this problem, but it is not currently supported by JFR.
>> 
>> Any input would be greatly appreciated.
>> 
>> Testing: jdk/jdk/jfr
>
> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove debug code

Can the event use the settings enabled and threshold instead of XX:+SafepointTimeout -XX:SafepointTimeoutDelay=x? Then the event can be configured from command line, a .jfc file and remotely over JMX. Perhaps the event can be enabled by default with a high threshold? Would this work, or am I missing something?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17888#issuecomment-1948475336

From johan.sjolen at oracle.com  Fri Feb 16 14:44:50 2024
From: johan.sjolen at oracle.com (Johan Sjolen)
Date: Fri, 16 Feb 2024 14:44:50 +0000
Subject: Request for Comment: Add a stalling mode to asynchronous UL
Message-ID: <BL3PR10MB6233AAD27450E7C441F3B29EFE4C2@BL3PR10MB6233.namprd10.prod.outlook.com>

Hello Hotspot,

Today, asynchronous UL depends on off-loading the work of logging to output devices by having log sites copying messages onto a buffer and an output thread swapping it with an empty buffer and emptying it.
If the current buffer runs out of room, then any attempt at logging leads to the message being dropped, that is: The message is not printed at all.
I'd like to suggest that we add a stalling mode to async UL where in no message dropping occurs and all log sites stall until there is sufficient room in the buffer for their respective message.

My purpose with this e-mail is twofold. First, I would like to know whether there is any interest in such a feature being added to Hotspot. Second, I'd like to discuss a change in the design of async UL which will permit this feature and other improvements.
I imagine that the user facing change for async UL would be to equip -Xlog:async with an option, as such:

```
$ java -Xlog:async:drop  ... # Drop messages
$ java -Xlog:async:stall ... # Stall log sites
$ java -Xlog:async       ... # Drop messages by default
```

The rest of this e-mail will describe the design changes and motivation behind these changes, so if you're mostly interested in answering whether or not you want there to be a stalling mode in async UL then you don't need to bother with the rest ?.

There's a draft PR for these changes, it runs on my Linux computer, but I have implemented the necessary changes for Mac and Windows also. The PR is available here: https://github.com/openjdk/jdk/pull/17757

I have described the current async protocol which is in mainline in appendix 0. There are two issues with this protocol:

1. During times when there is a high amount of logging in the system there is also high contention on the mutex. This can lead the output thread to suffer from starvation, as it cannot take the mutex to swap the buffers.
   This in turn leads to excessive dropping of messages and poor scaling of buffer increases.
2. Implementing stalling (as opposed to dropping messages) under this protocol leads to unnecessary waiting on the logsites.
   Stalling would mean that a log site has to wait for the entire log buffer to be emptied before logging.
   This may mean 1MiB of data having to be output before the swap can occur, and of course the swap requires the writing thread to acquire the mutex which has its own issues.

Issue number 1 can most easily be observed by inducing a (perhaps artificially so) high amount of logging through setting logging to all=trace in a slow-debug build:

```
$ slow-debug/jdk/bin/java -Xlog:async -Xlog:all=trace:file=asynctest::filecount=0
$ grep 'dropped due to' asynctest
[0.147s][warning][                       ]   1338 messages dropped due to async logging
[0.171s][warning][                       ]    496 messages dropped due to async logging
[0.511s][warning][                       ]     98 messages dropped due to async logging
[0.542s][warning][                       ]     13 messages dropped due to async logging
[0.762s][warning][                       ]   5620 messages dropped due to async logging
[1.286s][warning][                       ]  12440 messages dropped due to async logging
[1.316s][warning][                       ]   2610 messages dropped due to async logging
[1.352s][warning][                       ]   2497 messages dropped due to async logging
```

I'd like to suggest that we re-implement async logging using a producer/consumer protocol backed by circular buffers instead. This means that the output thread no longer suffers from starvation and can continously make progress.
It also means that we don't have to split up the buffer memory in two, both log threads and output thread can share the whole buffer at the same time.

My solution does seem to improve the dropping situation, as per the same test:

```
$ ul/jdk/bin/java -Xlog:async:drop -Xlog:all=trace:file=asyncdrop::filecount=0
$ grep 'dropped due to' asyncdrop
[0.295s][warning][                       ]    195 messages dropped due to async logging
[0.949s][warning][                       ]   3012 messages dropped due to async logging
[1.315s][warning][                       ]   7992 messages dropped due to async logging
```
That is a bit over 10 000 dropped messages, as opposed to over 20 000 in the old solution. I also did some throughput benchmarking, which shows that stalling has minimal impact on throughput, see appendix 2 for the throughput timings.


The new protocol is a basic producer/consumer pattern with two mutexes and a circular buffer with two variables: head and tail. The consumer reads tail and sets head, the producer reads head and writes to tail. In this case the producer are the log sites and the consumer is the output thread. See appendix 1 for a pseudo-code description of the protocol. There are some details ommitted, such as how stalling is implemented (hint: wait/notify on the producer lock), please read the code for details.

TL;DR:

1. Add a 'stall' strategy for the async logging so that we can guarantee 0 dropped messages at the expense of delays at log sites, this is exposed by changing the command line option. Before: -Xlog:async, after: -Xlog:async[:[drop|stall]]. Default is still drop.
2. Ping-pong buffers are not a good idea when also supporting stalling, because a log site can be stalled for far longer than in the synchronous case.
3. Therefore switch out ping-pong buffers and single mutex with a circular buffer and separate producer and consumer mutexes. This also has the benefit of reducing dropped messages in my testing.

Thank you for reading and I appreciate any input on this.
Johan Sj?l?n


Appendix 0, the old async protocol.

Nota bene: Any absence or presence of bugs may be the opposite in the actual source code.

```
Variables:
Mutex m;
Buffer* cb;
Buffer a;
Buffer b;
const char* message;

Methods:
void Buffer::write(const char* message) {
  if (has_space(strlen(message))) {
    internal_write(message);
  }
}

LogSite:
1. m.lock();
2. cb->write(message);
3. m.unlock();
4. m.notify();

OutputThread:
1. m.wait();
2. m.lock();
3. buffer := cb;
4. if cb == &a then cb = &b; else cb = &a;
5. m.unlock();
6. for each message in buffer: print to log site
7. go to 1.
```

Appendix 1, the new protocol.

Nota bene: Any absence or presence of bugs may be the opposite in the actual source code.
```
Mutex consumer;
Mutex producer;
CircularBuffer cb;
size_t head;
size_t tail;
const char* message;
char* out;

LogSite:
1. producer.lock();
2. t = tail; h = head; // Read the values
2. if unused_memory(h, t) < strlen(message) then drop_or_stall();
3. size_t bytes_written = cb.write(message); // Writes string and envelope
4. tail = (t + bytes_written) % cb.size(); // Message ready to consume, move tail.
5. producer.unlock();

OutputThread:
1. consumer.lock();
2. t = tail; h = head;
3. if h == t return; // No message available
4. size_t bytes_read = cb.read_bytes(out, h) // Write the next message
5. head = (h + bytes_read) % cb.size() // More memory available for producer
6. consumer.unlock();
```

Appendix 2, the throughput tests.

```
Testing requires the tool pv, example of how to try it yourself:
$ ./build/slow/jdk/bin/java -Xlog:async -Xlog:all=trace | (pv --rate --timer --bytes > /dev/null)

# Slow debug build
## Default sync logging
### /dev/null
48.5MiB 0:00:02 [17.5MiB/s]
### To file
48.5MiB 0:00:03 [14.4MiB/s]

## Old async logging
### /dev/null
51.1MiB 0:00:02 [20.9MiB/s]
### To file
57.1MiB 0:00:02 [19.7MiB/s]
Dropped messages:
[0.202s][warning][                       ]    350 messages dropped due to async logging
[1.302s][warning][                       ]   1981 messages dropped due to async logging
[1.328s][warning][                       ]   2193 messages dropped due to async logging
[1.354s][warning][                       ]   2464 messages dropped due to async logging
[1.379s][warning][                       ]   4158 messages dropped due to async logging
[1.405s][warning][                       ]   3017 messages dropped due to async logging
[1.435s][warning][                       ]   3818 messages dropped due to async logging
[1.479s][warning][                       ]   2286 messages dropped due to async logging

## New async logging (dropping mode)
### /dev/null
50.6MiB 0:00:02 [20.9MiB/s]
### To file
50.8MiB 0:00:02 [18.1MiB/s]
Dropped messages: 0 on this run.
Did another run as there is high variability in dropped messages:
50.2MiB 0:00:02 [18.3MiB/s]
[1.276s][warning][                       ]   4942 messages dropped due to async logging

## New async logging (stalling mode)
### /dev/null
51.3MiB 0:00:02 [19.9MiB/s]
### To file
50.9MiB 0:00:02 [18.8MiB/s]

# Release build Linux-x64 (to a tmpfs mounted file)
## New async drop
20,1MiB 0:00:00 [43,3MiB/s]
0 dropped messages
## New async stall
33,7MiB 0:00:00 [41,5MiB/s]
N/A dropped messages
0 dropped messages
## Old async
17,7MiB 0:00:00 [42,2MiB/s]
[0.059s][warning][                       ]   6860 messages dropped due to async logging
[0.082s][warning][                       ]  20601 messages dropped due to async logging
[0,107s][warning][                       ]   9147 messages dropped due to async logging
[0,131s][warning][                       ]  11113 messages dropped due to async logging
[0,154s][warning][                       ]  11845 messages dropped due to async logging
[0,178s][warning][                       ]  10383 messages dropped due to async logging
[0,197s][warning][                       ]   9376 messages dropped due to async logging
[0,216s][warning][                       ]  10997 messages dropped due to async logging
[0,234s][warning][                       ]   5978 messages dropped due to async logging
[0,252s][warning][                       ]  10439 messages dropped due to async logging
[0,270s][warning][                       ]   6562 messages dropped due to async logging
[0,325s][warning][                       ]    391 messages dropped due to async logging
[0,343s][warning][                       ]   3532 messages dropped due to async logging
[0,362s][warning][                       ]   3268 messages dropped due to async logging
[0,395s][warning][                       ]   4182 messages dropped due to async logging
[0,411s][warning][                       ]   2490 messages dropped due to async logging
```
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20240216/d0d7edb9/attachment-0001.htm>

From thomas.stuefe at gmail.com  Fri Feb 16 14:56:33 2024
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Fri, 16 Feb 2024 15:56:33 +0100
Subject: Request for Comment: Add a stalling mode to asynchronous UL
In-Reply-To: <BL3PR10MB6233AAD27450E7C441F3B29EFE4C2@BL3PR10MB6233.namprd10.prod.outlook.com>
References: <BL3PR10MB6233AAD27450E7C441F3B29EFE4C2@BL3PR10MB6233.namprd10.prod.outlook.com>
Message-ID: <CAA-vtUzXifcVVZvZZ3dPfgZe+A0-GZgk_AReY2pgk9gb5juozg@mail.gmail.com>

CC'ing Xin as original author.

At first glance, I like this. I also like the ringbuffer approach better.
Not sure if it had been discussed originally, but the original PR went on
for a while IIRC.

Do we even need the "drop" mode? I never liked the idea of losing output,
and maybe stalls are that rare that they won't matter. Arguably, if you
stall you should increase the log buffer size.

..Thomas


On Fri, Feb 16, 2024 at 3:45?PM Johan Sjolen <johan.sjolen at oracle.com>
wrote:

> Hello Hotspot,
>
> Today, asynchronous UL depends on off-loading the work of logging to
> output devices by having log sites copying messages onto a buffer and an
> output thread swapping it with an empty buffer and emptying it.
> If the current buffer runs out of room, then any attempt at logging leads
> to the message being dropped, that is: The message is not printed at all.
> I'd like to suggest that we add a stalling mode to async UL where in no
> message dropping occurs and all log sites stall until there is sufficient
> room in the buffer for their respective message.
>
> My purpose with this e-mail is twofold. First, I would like to know
> whether there is any interest in such a feature being added to Hotspot.
> Second, I'd like to discuss a change in the design of async UL which will
> permit this feature and other improvements.
> I imagine that the user facing change for async UL would be to equip
> -Xlog:async with an option, as such:
>
> ```
> $ java -Xlog:async:drop  ... # Drop messages
> $ java -Xlog:async:stall ... # Stall log sites
> $ java -Xlog:async       ... # Drop messages by default
> ```
>
> The rest of this e-mail will describe the design changes and motivation
> behind these changes, so if you're mostly interested in answering whether
> or not you want there to be a stalling mode in async UL then you don't need
> to bother with the rest ?.
>
> There's a draft PR for these changes, it runs on my Linux computer, but I
> have implemented the necessary changes for Mac and Windows also. The PR is
> available here: https://github.com/openjdk/jdk/pull/17757
>
> I have described the current async protocol which is in mainline in
> appendix 0. There are two issues with this protocol:
>
> 1. During times when there is a high amount of logging in the system there
> is also high contention on the mutex. This can lead the output thread to
> suffer from starvation, as it cannot take the mutex to swap the buffers.
>    This in turn leads to excessive dropping of messages and poor scaling
> of buffer increases.
> 2. Implementing stalling (as opposed to dropping messages) under this
> protocol leads to unnecessary waiting on the logsites.
>    Stalling would mean that a log site has to wait for the entire log
> buffer to be emptied before logging.
>    This may mean 1MiB of data having to be output before the swap can
> occur, and of course the swap requires the writing thread to acquire the
> mutex which has its own issues.
>
> Issue number 1 can most easily be observed by inducing a (perhaps
> artificially so) high amount of logging through setting logging to
> all=trace in a slow-debug build:
>
> ```
> $ slow-debug/jdk/bin/java -Xlog:async
> -Xlog:all=trace:file=asynctest::filecount=0
> $ grep 'dropped due to' asynctest
> [0.147s][warning][                       ]   1338 messages dropped due to
> async logging
> [0.171s][warning][                       ]    496 messages dropped due to
> async logging
> [0.511s][warning][                       ]     98 messages dropped due to
> async logging
> [0.542s][warning][                       ]     13 messages dropped due to
> async logging
> [0.762s][warning][                       ]   5620 messages dropped due to
> async logging
> [1.286s][warning][                       ]  12440 messages dropped due to
> async logging
> [1.316s][warning][                       ]   2610 messages dropped due to
> async logging
> [1.352s][warning][                       ]   2497 messages dropped due to
> async logging
> ```
>
> I'd like to suggest that we re-implement async logging using a
> producer/consumer protocol backed by circular buffers instead. This means
> that the output thread no longer suffers from starvation and can
> continously make progress.
> It also means that we don't have to split up the buffer memory in two,
> both log threads and output thread can share the whole buffer at the same
> time.
>
> My solution does seem to improve the dropping situation, as per the same
> test:
>
> ```
> $ ul/jdk/bin/java -Xlog:async:drop
> -Xlog:all=trace:file=asyncdrop::filecount=0
> $ grep 'dropped due to' asyncdrop
> [0.295s][warning][                       ]    195 messages dropped due to
> async logging
> [0.949s][warning][                       ]   3012 messages dropped due to
> async logging
> [1.315s][warning][                       ]   7992 messages dropped due to
> async logging
> ```
> That is a bit over 10 000 dropped messages, as opposed to over 20 000 in
> the old solution. I also did some throughput benchmarking, which shows that
> stalling has minimal impact on throughput, see appendix 2 for the
> throughput timings.
>
>
> The new protocol is a basic producer/consumer pattern with two mutexes and
> a circular buffer with two variables: head and tail. The consumer reads
> tail and sets head, the producer reads head and writes to tail. In this
> case the producer are the log sites and the consumer is the output thread.
> See appendix 1 for a pseudo-code description of the protocol. There are
> some details ommitted, such as how stalling is implemented (hint:
> wait/notify on the producer lock), please read the code for details.
>
> TL;DR:
>
> 1. Add a 'stall' strategy for the async logging so that we can guarantee 0
> dropped messages at the expense of delays at log sites, this is exposed by
> changing the command line option. Before: -Xlog:async, after:
> -Xlog:async[:[drop|stall]]. Default is still drop.
> 2. Ping-pong buffers are not a good idea when also supporting stalling,
> because a log site can be stalled for far longer than in the synchronous
> case.
> 3. Therefore switch out ping-pong buffers and single mutex with a circular
> buffer and separate producer and consumer mutexes. This also has the
> benefit of reducing dropped messages in my testing.
>
> Thank you for reading and I appreciate any input on this.
> Johan Sj?l?n
>
>
> Appendix 0, the old async protocol.
>
> Nota bene: Any absence or presence of bugs may be the opposite in the
> actual source code.
>
> ```
> Variables:
> Mutex m;
> Buffer* cb;
> Buffer a;
> Buffer b;
> const char* message;
>
> Methods:
> void Buffer::write(const char* message) {
>   if (has_space(strlen(message))) {
>     internal_write(message);
>   }
> }
>
> LogSite:
> 1. m.lock();
> 2. cb->write(message);
> 3. m.unlock();
> 4. m.notify();
>
> OutputThread:
> 1. m.wait();
> 2. m.lock();
> 3. buffer := cb;
> 4. if cb == &a then cb = &b; else cb = &a;
> 5. m.unlock();
> 6. for each message in buffer: print to log site
> 7. go to 1.
> ```
>
> Appendix 1, the new protocol.
>
> Nota bene: Any absence or presence of bugs may be the opposite in the
> actual source code.
> ```
> Mutex consumer;
> Mutex producer;
> CircularBuffer cb;
> size_t head;
> size_t tail;
> const char* message;
> char* out;
>
> LogSite:
> 1. producer.lock();
> 2. t = tail; h = head; // Read the values
> 2. if unused_memory(h, t) < strlen(message) then drop_or_stall();
> 3. size_t bytes_written = cb.write(message); // Writes string and envelope
> 4. tail = (t + bytes_written) % cb.size(); // Message ready to consume,
> move tail.
> 5. producer.unlock();
>
> OutputThread:
> 1. consumer.lock();
> 2. t = tail; h = head;
> 3. if h == t return; // No message available
> 4. size_t bytes_read = cb.read_bytes(out, h) // Write the next message
> 5. head = (h + bytes_read) % cb.size() // More memory available for
> producer
> 6. consumer.unlock();
> ```
>
> Appendix 2, the throughput tests.
>
> ```
> Testing requires the tool pv, example of how to try it yourself:
> $ ./build/slow/jdk/bin/java -Xlog:async -Xlog:all=trace | (pv --rate
> --timer --bytes > /dev/null)
>
> # Slow debug build
> ## Default sync logging
> ### /dev/null
> 48.5MiB 0:00:02 [17.5MiB/s]
> ### To file
> 48.5MiB 0:00:03 [14.4MiB/s]
>
> ## Old async logging
> ### /dev/null
> 51.1MiB 0:00:02 [20.9MiB/s]
> ### To file
> 57.1MiB 0:00:02 [19.7MiB/s]
> Dropped messages:
> [0.202s][warning][                       ]    350 messages dropped due to
> async logging
> [1.302s][warning][                       ]   1981 messages dropped due to
> async logging
> [1.328s][warning][                       ]   2193 messages dropped due to
> async logging
> [1.354s][warning][                       ]   2464 messages dropped due to
> async logging
> [1.379s][warning][                       ]   4158 messages dropped due to
> async logging
> [1.405s][warning][                       ]   3017 messages dropped due to
> async logging
> [1.435s][warning][                       ]   3818 messages dropped due to
> async logging
> [1.479s][warning][                       ]   2286 messages dropped due to
> async logging
>
> ## New async logging (dropping mode)
> ### /dev/null
> 50.6MiB 0:00:02 [20.9MiB/s]
> ### To file
> 50.8MiB 0:00:02 [18.1MiB/s]
> Dropped messages: 0 on this run.
> Did another run as there is high variability in dropped messages:
> 50.2MiB 0:00:02 [18.3MiB/s]
> [1.276s][warning][                       ]   4942 messages dropped due to
> async logging
>
> ## New async logging (stalling mode)
> ### /dev/null
> 51.3MiB 0:00:02 [19.9MiB/s]
> ### To file
> 50.9MiB 0:00:02 [18.8MiB/s]
>
> # Release build Linux-x64 (to a tmpfs mounted file)
> ## New async drop
> 20,1MiB 0:00:00 [43,3MiB/s]
> 0 dropped messages
> ## New async stall
> 33,7MiB 0:00:00 [41,5MiB/s]
> N/A dropped messages
> 0 dropped messages
> ## Old async
> 17,7MiB 0:00:00 [42,2MiB/s]
> [0.059s][warning][                       ]   6860 messages dropped due to
> async logging
> [0.082s][warning][                       ]  20601 messages dropped due to
> async logging
> [0,107s][warning][                       ]   9147 messages dropped due to
> async logging
> [0,131s][warning][                       ]  11113 messages dropped due to
> async logging
> [0,154s][warning][                       ]  11845 messages dropped due to
> async logging
> [0,178s][warning][                       ]  10383 messages dropped due to
> async logging
> [0,197s][warning][                       ]   9376 messages dropped due to
> async logging
> [0,216s][warning][                       ]  10997 messages dropped due to
> async logging
> [0,234s][warning][                       ]   5978 messages dropped due to
> async logging
> [0,252s][warning][                       ]  10439 messages dropped due to
> async logging
> [0,270s][warning][                       ]   6562 messages dropped due to
> async logging
> [0,325s][warning][                       ]    391 messages dropped due to
> async logging
> [0,343s][warning][                       ]   3532 messages dropped due to
> async logging
> [0,362s][warning][                       ]   3268 messages dropped due to
> async logging
> [0,395s][warning][                       ]   4182 messages dropped due to
> async logging
> [0,411s][warning][                       ]   2490 messages dropped due to
> async logging
> ```
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20240216/370e1a93/attachment-0001.htm>

From ddong at openjdk.org  Fri Feb 16 16:14:53 2024
From: ddong at openjdk.org (Denghui Dong)
Date: Fri, 16 Feb 2024 16:14:53 GMT
Subject: RFR: 8326012: JFR: Event for safepoint timeout [v2]
In-Reply-To: <TY0pv8iO2zqAUpVIhgShHYCONJYM9dcJCladEHoWDYw=.2d6d78e0-122a-46dc-be38-d3fc4cbd0272@github.com>
References: <68hS0kQgtDIk4ioAJj_r0_GLT6h0lcif6Daj6WRwxlI=.40c2a6e7-70a8-4954-bcde-9318ee311028@github.com>
 <MOBmQP7eddXhC1DclBriDy1zdy7xYQ8ZnvZ6XFv8mX8=.f54da08e-fb3b-47aa-b068-bc1f91815e61@github.com>
 <TY0pv8iO2zqAUpVIhgShHYCONJYM9dcJCladEHoWDYw=.2d6d78e0-122a-46dc-be38-d3fc4cbd0272@github.com>
Message-ID: <JC9G06y8gYfEqCRTgAZs4GMIM9s-exaz8nQvl_U_vO0=.9f08af80-5111-4163-b7c7-319dc8b21e40@github.com>

On Fri, 16 Feb 2024 14:24:00 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Can the event use the settings enabled and threshold instead of XX:+SafepointTimeout -XX:SafepointTimeoutDelay=x? Then the event can be configured from command line, a .jfc file and remotely over JMX. Perhaps the event can be enabled by default with a high threshold? Would this work, or am I missing something?

It works.

If implemented in this way, I think `EventTimeToSafepoint` is a more suitable name.

`start_time` of this event is `SafepointTracing::_last_safepoint_begin_time_ns`, and `end_time` is the time when vm_thread found the target thread is not running.

What do you think?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17888#issuecomment-1948766675

From naoto at openjdk.org  Fri Feb 16 16:55:57 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 16 Feb 2024 16:55:57 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck [v2]
In-Reply-To: <ccnGBDgKifqtHAXAlfcdzACsqJG68fY7-TjtsAnN_p8=.afd45aec-c57f-4911-88d2-7988768ccad9@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
 <ccnGBDgKifqtHAXAlfcdzACsqJG68fY7-TjtsAnN_p8=.afd45aec-c57f-4911-88d2-7988768ccad9@github.com>
Message-ID: <fV_QpLFoKMrAxR1VvhztN6ha6WJBO8iNcPzNbP-fgAo=.25e82e1c-ed8d-4b7f-9f76-a9ed2a08e62d@github.com>

On Fri, 16 Feb 2024 12:43:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes).
>> 
>> I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace spaces with \t in test properties file

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17871#pullrequestreview-1885586969

From aph at openjdk.org  Fri Feb 16 16:59:00 2024
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 16 Feb 2024 16:59:00 GMT
Subject: RFR: 8314488: Compile the JDK as C++17 [v6]
In-Reply-To: <thctbcato1Bz1XDUBDRZagYtDn4ycbwHLSEiD8p04vA=.1b758366-f4ef-430f-a7c2-0598f1161593@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
 <b4HhbT5caIfCbrVveI6NDObiwUI2Sr0so68JBG6C0YU=.1734aaa7-aed4-478c-bbb6-de9af5c04ef9@github.com>
 <thctbcato1Bz1XDUBDRZagYtDn4ycbwHLSEiD8p04vA=.1b758366-f4ef-430f-a7c2-0598f1161593@github.com>
Message-ID: <OjQDJCvSf10R34TusB7UUcMRSt06qeTdCvJMWT1fwTc=.0411535d-db35-496b-9ec1-4b35170257ee@github.com>

On Fri, 16 Feb 2024 12:43:29 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I think Kim's approach here -- to separate compiler upgrades from C++17 usage -- is the right way. Then we can discuss each part separately -- what version is suitable for each compiler, and then -- if or when we end up with all compilers supporting C++17 -- we can come back to the discussion of whether that is a good idea.

I agree with all that. I don't even object to upgrading to a recent(ish) GCC, but I do think we ought to at least get a mention of the downsides on the record, and sometimes that job falls to me. So I think I agree it's the right thing to do going forward, even though it might be a bit bumpy for those of us trying to build the JDK on a range of elderly long-term-support Linux systems.

> I also apologize for my hash expressions. :( I did not mean to insult anyone.

No problem. We're good.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1948879029

From ayang at openjdk.org  Fri Feb 16 17:54:54 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 16 Feb 2024 17:54:54 GMT
Subject: RFR: 8325082: Rename headers named 'heapRegion*' of G1 [v3]
In-Reply-To: <a-yGlCqCFaCddkLhkRAhcNCgaS9BOtLbTxLL-n8r-VI=.5375ca5a-ac46-4c24-a403-2a4fa9540e3a@github.com>
References: <1MWMgluBwGY-FydUnpoksJ0q5sSvptrNMv6xwDszBQc=.a78cadad-1585-44d1-97d0-a7928fe34d67@github.com>
 <p9f42d634nvSGvduMCBA3FUTq1V9ZIPUstJ8IpeuyWg=.6693e68b-0060-4f23-af4d-691dca3b94bb@github.com>
 <SY0M3nUsgN0i5egqg28W4j6pICWWRZ2ixU_XU5oR8qI=.f21c44ff-5acd-4f8a-b7f0-e6332c1fbf81@github.com>
 <a-yGlCqCFaCddkLhkRAhcNCgaS9BOtLbTxLL-n8r-VI=.5375ca5a-ac46-4c24-a403-2a4fa9540e3a@github.com>
Message-ID: <RQXTM91rpRSUNRPhhrhiAFI56UhYHWmiVEwNsXNdYZk=.2cf62228-bc78-4823-b84d-3982bf65d3bc@github.com>

On Fri, 16 Feb 2024 14:14:39 GMT, Lei Zaakjyu <duke at openjdk.org> wrote:

>  Could you please tell me the relationship between 'jdk.hotspot.agent' and the source files of hotspot?

I overlooked that this PR does only file renaming -- class names stay the same. The change inside `jdk.hotspot.agent` should be reverted for this PR.  (They should be done along with the class renaming, e.g. `HeapRegion` -> `G1HeapRegion`.) Sorry for the confusion.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17666#issuecomment-1948982916

From sspitsyn at openjdk.org  Fri Feb 16 20:40:52 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 16 Feb 2024 20:40:52 GMT
Subject: RFR: 8324680: Replace NULL with nullptr in JVMTI generated code
In-Reply-To: <w1DMQMwGugoSs830xWYD6l7yoIR6v8dk5MnKYIY8t9w=.1ad08a17-8efc-4a71-88a5-78da29ce4ab4@github.com>
References: <w1DMQMwGugoSs830xWYD6l7yoIR6v8dk5MnKYIY8t9w=.1ad08a17-8efc-4a71-88a5-78da29ce4ab4@github.com>
Message-ID: <-H0X-wr0VZPPE0LzKWCUKxwnETYQqVvTX-1UJGOIs3E=.641cb82e-e414-476e-8452-f0f2c473f473@github.com>

On Thu, 15 Feb 2024 08:46:43 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This enhancement replaces uses of NULL with nullptr in the XML-description files for JVMTI. These are the files `hotsport/share/prims/jvmti.xml` and `hotspot/share/prims/jvmti*.xls`.
> 
> The following files are auto-generated from the `jvmti.xml` and `*.xsl files` in the `build/<CFG>/variant-server/gensrc/jvmtifiles': `jvmti.h`, `jvmti.html`, `jvmtiEnter.cpp`, `jvmtiEnterTrace.cpp`, `jvmtiEnv.hpp`
> 
> This addresses a category of NULL uses that wasn't dealt with by:
>  [JDK-8299837](https://bugs.openjdk.org/browse/JDK-8299837).
>  
>  Testing:
>    - TBD: run mach5 tiers1-3

Thank you for review, Coleen!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17866#issuecomment-1949300764

From sspitsyn at openjdk.org  Fri Feb 16 21:25:01 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 16 Feb 2024 21:25:01 GMT
Subject: Integrated: 8324680: Replace NULL with nullptr in JVMTI generated code
In-Reply-To: <w1DMQMwGugoSs830xWYD6l7yoIR6v8dk5MnKYIY8t9w=.1ad08a17-8efc-4a71-88a5-78da29ce4ab4@github.com>
References: <w1DMQMwGugoSs830xWYD6l7yoIR6v8dk5MnKYIY8t9w=.1ad08a17-8efc-4a71-88a5-78da29ce4ab4@github.com>
Message-ID: <sAo2V8R-bwfnwKdwYHiSKykDkVHYdtijpXfhgLvdvGo=.2e51b76c-cda7-4e5d-b8a8-65e9804c5409@github.com>

On Thu, 15 Feb 2024 08:46:43 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This enhancement replaces uses of NULL with nullptr in the XML-description files for JVMTI. These are the files `hotsport/share/prims/jvmti.xml` and `hotspot/share/prims/jvmti*.xls`.
> 
> The following files are auto-generated from the `jvmti.xml` and `*.xsl files` in the `build/<CFG>/variant-server/gensrc/jvmtifiles': `jvmti.h`, `jvmti.html`, `jvmtiEnter.cpp`, `jvmtiEnterTrace.cpp`, `jvmtiEnv.hpp`
> 
> This addresses a category of NULL uses that wasn't dealt with by:
>  [JDK-8299837](https://bugs.openjdk.org/browse/JDK-8299837).
>  
>  Testing:
>    - TBD: run mach5 tiers1-3

This pull request has now been integrated.

Changeset: 267780bf
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/267780bf0adf4bfd831fbc04347e297fa8f3bb01
Stats:     110 lines in 5 files changed: 0 ins; 0 del; 110 mod

8324680: Replace NULL with nullptr in JVMTI generated code

Reviewed-by: amenkov, coleenp

-------------

PR: https://git.openjdk.org/jdk/pull/17866

From duke at openjdk.org  Fri Feb 16 22:12:11 2024
From: duke at openjdk.org (duke)
Date: Fri, 16 Feb 2024 22:12:11 GMT
Subject: Withdrawn: 8308994: C2: Re-implement experimental post loop
 vectorization
In-Reply-To: <amPQ0vlTo13A1AatfUAJsnOH0QdGJGiGMnjroyBn0kk=.b94be6f1-8ffb-4f2b-b028-163fc6833107@github.com>
References: <amPQ0vlTo13A1AatfUAJsnOH0QdGJGiGMnjroyBn0kk=.b94be6f1-8ffb-4f2b-b028-163fc6833107@github.com>
Message-ID: <PH89y2Cjkp7u4CeJjpn1OP98LFKAm1h5eGJejNf8E3w=.b64e365a-f484-4f43-8ffb-1b23c32935a7@github.com>

On Wed, 21 Jun 2023 08:24:19 GMT, Pengfei Li <pli at openjdk.org> wrote:

> ## TL;DR
> 
> This patch completely re-implements C2's experimental post loop vectorization for better stability, maintainability and performance. Compared with the original implementation, this new implementation adds a standalone loop phase in C2's ideal loop phases and can vectorize more post loops. The original implementation and all code related to multi-versioned post loops are deleted in this patch. More details about this patch can be found in the document replied in this pull request.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/14581

From kvn at openjdk.org  Fri Feb 16 23:36:58 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 16 Feb 2024 23:36:58 GMT
Subject: RFR: 8317697: refactor-encapsulate x86 VM_Version::CpuidInfo [v4]
In-Reply-To: <ioaANin14rJBVL0cwwLg79zVULcK5IbFbbBfzpcl_GY=.1c2fb0ac-d8d5-4a04-b488-7e9e93e288bf@github.com>
References: <JmIOcendwRGLAVKOQ4bFrDxwNVgt1KY5LKJ-Vz-SBjg=.edcccbcb-346c-4063-b75f-09d337fa9f66@github.com>
 <ioaANin14rJBVL0cwwLg79zVULcK5IbFbbBfzpcl_GY=.1c2fb0ac-d8d5-4a04-b488-7e9e93e288bf@github.com>
Message-ID: <6IuRvXEJkAs_sYFVtlgDw_quL8_5TEM8s3wS04Sqyc0=.18bb7582-fb70-437e-934f-8e8a935ad693@github.com>

On Thu, 15 Feb 2024 12:18:17 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> In OpenJDK project CRaC I had a [need to fetch new CpuidInfo without affecting the existing one](https://github.com/openjdk/crac/commit/ed4ad9ba31b77732dcede2eb743b2f389ec9a0fe#diff-6ed856c57ddbe33e49883adb7c52ec51ed377e5f697dfd6d8bea505a97bfc5a5R2743).
>> Which led me to encapsulate the object more and I think this no-functionality-change patch is even appropriate for JDK.
>> I am sure interested primarily to reduce the CRaC patchset boilerplate.
>
> Jan Kratochvil has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into flagsencaps
>  - Remove the automatic zero-initialization
>  - Make CpuidInfo a class
>  - Merge branch 'master' into flagsencaps
>  - 8317697: refactor-encapsulate x86 VM_Version::CpuidInfo

I submitted our internal testing before sponsoring.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16093#issuecomment-1949484016

From kvn at openjdk.org  Sat Feb 17 01:39:57 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sat, 17 Feb 2024 01:39:57 GMT
Subject: RFR: 8325095: C2: bailout message broken: ResourceArea allocated
 string used after free [v2]
In-Reply-To: <iqVK2jP6-y3NweZYd_Y6Eo39GUH9hf8gFugp8aq3-dw=.54a735a9-9cf2-411d-89aa-19dcbef22937@github.com>
References: <8Bl6JSxb-fd1xAsKOMzBakRFuruoqJykP7JEn57k6qY=.717f89af-2aa7-439b-afd1-768dd39f51da@github.com>
 <iqVK2jP6-y3NweZYd_Y6Eo39GUH9hf8gFugp8aq3-dw=.54a735a9-9cf2-411d-89aa-19dcbef22937@github.com>
Message-ID: <xqWyNkVeEGgmfeKRi85M_PhZjwfO4TT0dkVn8hova5s=.e7d9f390-56c8-4fe7-86f1-bab34a2cebcc@github.com>

On Fri, 16 Feb 2024 07:18:09 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> **Problem**
>> Bailout `failure_reason` strings used to be either `nullptr` or a static string. But with [JDK-8303951](https://bugs.openjdk.org/browse/JDK-8303951) I had introduced dynamic strings (e.g. formatted using `stringStream::as_string()`). These dynamic strings were ResourceArea allocated, and have a very limited life-span, i.e. withing the most recent ResourceMark scope. The pointer is passed to `Compile::_failure_reason`, which already might leave that ResourceMark scope, and the pointer is invalid. And then the pointer is further passed to `ciEnv::_failure_reason`. And finally, it even gets passed up to `CompileBroker::invoke_compiler_on_method`. When the string is finally printed for the bailout message, we already left original `ResourceMark` scope, and also the `Compile` and `ciEnv` scopes. The pointer now points to basically random data.
>> 
>> **Solution**
>> Whenever a string is passed to an outer scope, I make a CHeap copy, and the outer scope is the owner of that copy.
>> This way every scope is the owner of its own copy, and can allocate and deallocate according to its own strategy safely.
>> 
>> I introduced a utility class `CHeapStringHolder`:
>>  - `set`: make local copy on CHeap.
>>  - `clear`: free local copy. We before `set`, and in the destructor. Thus, when the holder goes out of scope, the memory is automatically freed.
>> 
>> We have these 4 scopes:
>> - `ResourceMark`: It allocates from `ResourcArea`, and deallocation is taken care at the end of the ResourceMark scope.
>> - `Compile`: We turn the `_failure_reason` from a `char*` into a `CHeapStringHolder`. We set `_failure_reason` while the `ResourceMark` is live.
>> - `ciEnv`: We turn the `_failure_reason` from a `char*` into a `CHeapStringHolder`. We set `_failure_reason` while `Compile` is live.
>> - `CompileTask`: We used to just set `failure_reason`, which assumes that the string is static or elsewhere managed. Now I use pattern available in other places of `CompileBroker::invoke_compiler_on_method`: duplicate the string with `os::strdup` from some other scope, and set `reason_on_C_heap = true`, which means that we are the owner of that copy, and are responsible for freeing it later. Not sure if that is a nice pattern, but I don't want to refactor that code and it does what I need it to do.
>
> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove OrderAccess::storestore() bc single threaded only

Few comments.

src/hotspot/share/compiler/compileBroker.cpp line 2333:

> 2331:       // Duplicate the failure reason string, so that it outlives ciEnv
> 2332:       failure_reason = os::strdup(ci_env.failure_reason(), mtCompiler);
> 2333:       bool reason_on_C_heap = true;

Did you mean: `failure_reason_on_C_heap = true;`?

src/hotspot/share/opto/compile.hpp line 367:

> 365:   DirectiveSet*         _directive;             // Compiler directive
> 366:   CompileLog*           _log;                   // from CompilerThread
> 367:   CHeapStringHolder     _failure_reason;       // for record_failure/failing pattern

wrong comment's indent

-------------

Changes requested by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17710#pullrequestreview-1886254977
PR Review Comment: https://git.openjdk.org/jdk/pull/17710#discussion_r1493100082
PR Review Comment: https://git.openjdk.org/jdk/pull/17710#discussion_r1493108890

From kvn at openjdk.org  Sat Feb 17 01:39:57 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sat, 17 Feb 2024 01:39:57 GMT
Subject: RFR: 8325095: C2: bailout message broken: ResourceArea allocated
 string used after free [v2]
In-Reply-To: <fUIR8mpl31uEeB5_iI__2ZT8beBfRIIz6vhAwly60EE=.08bab015-655f-4ad1-b71f-018e1c1b79d8@github.com>
References: <8Bl6JSxb-fd1xAsKOMzBakRFuruoqJykP7JEn57k6qY=.717f89af-2aa7-439b-afd1-768dd39f51da@github.com>
 <qnutyTCjwk_JFTIZcs-xW_PVAcFGogjJjCjeh1KAbTg=.fa1b659a-eac6-4f83-9eed-f9a0d4b239b5@github.com>
 <By6S6aqP_qRgnLVbbC1HcY2xvlYVkbGztxV1JdeUWIg=.0504185b-8bba-46a7-bbd0-dbef9b10be47@github.com>
 <MBix7LMnmfO7Zh89a5LUN_jXroE12XATCOBhYe74nNI=.4342ad8e-1cd3-4b75-894d-7dabb32663d3@github.com>
 <fUIR8mpl31uEeB5_iI__2ZT8beBfRIIz6vhAwly60EE=.08bab015-655f-4ad1-b71f-018e1c1b79d8@github.com>
Message-ID: <3vkOL-tts6lwRj1M4JYK5GdaAK6Tqc0-sOS6RG4nsac=.752d5dc9-6914-4ae6-958f-95049eafc441@github.com>

On Fri, 16 Feb 2024 12:27:45 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Reporting all failures might make sense for logging, but we can only report one reason, unless we want to do something like chained exceptions, which I don't think we need.  The different layers is already looking like a custom exception handling mechanism, unfortunately.
>
> Piling on... I opt for keeping this code simple. A list of subsequent failure states could easily be part of logging.

Okay, I am voting for UL to print all failures we hit during compilation and keep reporting only one reason at the end.

log_error(compilation) (failiure_reason);

Or `log_warning()`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17710#discussion_r1493120787

From kvn at openjdk.org  Sat Feb 17 01:39:58 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sat, 17 Feb 2024 01:39:58 GMT
Subject: RFR: 8325095: C2: bailout message broken: ResourceArea allocated
 string used after free [v2]
In-Reply-To: <jqqrLSVksbMxHDSRUlWJIn2RQBqJNmqX1zWJpimejZ4=.df378fba-ba92-48d9-a104-cc507b19471e@github.com>
References: <8Bl6JSxb-fd1xAsKOMzBakRFuruoqJykP7JEn57k6qY=.717f89af-2aa7-439b-afd1-768dd39f51da@github.com>
 <iqVK2jP6-y3NweZYd_Y6Eo39GUH9hf8gFugp8aq3-dw=.54a735a9-9cf2-411d-89aa-19dcbef22937@github.com>
 <jqqrLSVksbMxHDSRUlWJIn2RQBqJNmqX1zWJpimejZ4=.df378fba-ba92-48d9-a104-cc507b19471e@github.com>
Message-ID: <jeKUAzI09dUeQ3YjojKl9_Ub-mhB83-uDda83zXTI14=.85dfe959-3f79-4574-80d9-dc601666cdd1@github.com>

On Fri, 16 Feb 2024 12:34:24 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove OrderAccess::storestore() bc single threaded only
>
> src/hotspot/share/utilities/cHeapStringHolder.hpp line 41:
> 
>> 39:     _memflags(memflags), _string(nullptr) {}
>> 40:   ~CHeapStringHolder() { clear(); };
>> 41:   NONCOPYABLE(CHeapStringHolder);
> 
> I'd opt for a use-case-specific class inside compiler. It would allow you to hard-code mtCompiler, simplifying the code, and to log with UL into the compiler log when the failure reason is changed.
> 
> A new generic string class opens a whole can of bikeshedding worms, e.g. whether to make it mutable, how best to specify MEMFLAGS etc... I would avoid that, especially since the added value fo this helper class is slim.

I agree this should be in `compiler/`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17710#discussion_r1493109676

From kbarrett at openjdk.org  Sat Feb 17 08:37:57 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 17 Feb 2024 08:37:57 GMT
Subject: RFR: 8314488: Compile the JDK as C++17 [v6]
In-Reply-To: <Kf3TPcBiwoF4IKXQSdVu8fPrmy_AUe6japArSVzHHGw=.ac49ae36-aa56-4590-ba46-e195b03445d1@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
 <b4HhbT5caIfCbrVveI6NDObiwUI2Sr0so68JBG6C0YU=.1734aaa7-aed4-478c-bbb6-de9af5c04ef9@github.com>
 <bhrcRriVPrMI3BZd4M7MBIeFeF4vKhBbLVxbe0vfKPc=.c089032b-7420-4224-8186-d7d6e721856b@github.com>
 <Kf3TPcBiwoF4IKXQSdVu8fPrmy_AUe6japArSVzHHGw=.ac49ae36-aa56-4590-ba46-e195b03445d1@github.com>
Message-ID: <qvKzbx8UQHWBvn-Bjgzo3Es2SOjB2uKtjdKNElxJOIk=.e40e0553-eb0e-4f0e-bbd9-3b0cc3bcba85@github.com>

On Wed, 14 Feb 2024 15:59:50 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> I'd like to separate the version update discussions from C++17 specifics, so we can have focused discussions on the version choices. Of course, that's going to be informed by the possibility of C++17, but that's not the only factor. That way this issue can be just about turning on C++17, when, and why.
> 
> In order to do that, I've filed the following issues about version updates: https://bugs.openjdk.org/browse/JDK-8325881 Require minimum gcc version 10
> 
> https://bugs.openjdk.org/browse/JDK-8325878 Require minimum clang version 13
> 
> https://bugs.openjdk.org/browse/JDK-8325880 Require minimum OpenXL C/C++ version 17.1.1
> 
> PRs will follow shortly.

And here are the promised PRs:

8325881: Require minimum gcc version 10 
https://github.com/openjdk/jdk/pull/17899

8325878: Require minimum Clang version 13
https://github.com/openjdk/jdk/pull/17862

8325880: Require minimum Open XL C/C++ version 17.1.1
https://github.com/openjdk/jdk/pull/17857

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1949900566

From sspitsyn at openjdk.org  Sat Feb 17 12:07:14 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 17 Feb 2024 12:07:14 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v10]
In-Reply-To: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
Message-ID: <B9l-poSFV0mqShEw6t26ySzqhr3ud3ZAHLJG_KsnR_Q=.7629eb16-1134-4441-8853-a1bb55a315bc@github.com>

> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
> The function returns the following structure:
> 
> 
> typedef struct {
>     jthread owner;
>     jint entry_count;
>     jint waiter_count;
>     jthread* waiters;
>     jint notify_waiter_count;
>     jthread* notify_waiters;
> } jvmtiMonitorUsage;
> 
> 
> The following four fields are defined this way:
> 
> waiter_count  [jint] The number of threads waiting to own this monitor
> waiters  [jthread*] The waiter_count waiting threads
> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
> 
> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
> This update makes it right.
> 
> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
> 
> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
> 
>   jvmti/GetObjectMonitorUsage/objmonusage001
>   jvmti/GetObjectMonitorUsage/objmonusage003
> 
> 
> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
> 
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
> 
> 
> 
> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository.
> 
> Also, please see and review the related CSR:
>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
> 
> The Release-Note is:
> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage
>  
> Testing:
>  - tested with mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  cloned an nsk/jvmti test to provide test coverage for virtual threads; fixed vthread related issue

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17680/files
  - new: https://git.openjdk.org/jdk/pull/17680/files/c8b8e376..04da0cf8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=08-09

  Stats: 431 lines in 5 files changed: 415 ins; 11 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/17680.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17680/head:pull/17680

PR: https://git.openjdk.org/jdk/pull/17680

From jkratochvil at openjdk.org  Sat Feb 17 16:41:01 2024
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Sat, 17 Feb 2024 16:41:01 GMT
Subject: Integrated: 8317697: refactor-encapsulate x86 VM_Version::CpuidInfo
In-Reply-To: <JmIOcendwRGLAVKOQ4bFrDxwNVgt1KY5LKJ-Vz-SBjg=.edcccbcb-346c-4063-b75f-09d337fa9f66@github.com>
References: <JmIOcendwRGLAVKOQ4bFrDxwNVgt1KY5LKJ-Vz-SBjg=.edcccbcb-346c-4063-b75f-09d337fa9f66@github.com>
Message-ID: <7UcKdVSNIbrT3XmzF_bvs5tDbm4ICP1a6wpwGaE2d9w=.8a1e1ff4-761c-4f4c-8221-d6892772fd6c@github.com>

On Sat, 7 Oct 2023 17:44:06 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> In OpenJDK project CRaC I had a [need to fetch new CpuidInfo without affecting the existing one](https://github.com/openjdk/crac/commit/ed4ad9ba31b77732dcede2eb743b2f389ec9a0fe#diff-6ed856c57ddbe33e49883adb7c52ec51ed377e5f697dfd6d8bea505a97bfc5a5R2743).
> Which led me to encapsulate the object more and I think this no-functionality-change patch is even appropriate for JDK.
> I am sure interested primarily to reduce the CRaC patchset boilerplate.

This pull request has now been integrated.

Changeset: cf13086e
Author:    Jan Kratochvil <jkratochvil at openjdk.org>
Committer: Vladimir Kozlov <kvn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cf13086efe0a145d3fc84896473a39a863530629
Stats:     125 lines in 2 files changed: 30 ins; 23 del; 72 mod

8317697: refactor-encapsulate x86 VM_Version::CpuidInfo

Reviewed-by: dholmes, kvn

-------------

PR: https://git.openjdk.org/jdk/pull/16093

From kvn at openjdk.org  Sat Feb 17 16:41:00 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sat, 17 Feb 2024 16:41:00 GMT
Subject: RFR: 8317697: refactor-encapsulate x86 VM_Version::CpuidInfo [v4]
In-Reply-To: <ioaANin14rJBVL0cwwLg79zVULcK5IbFbbBfzpcl_GY=.1c2fb0ac-d8d5-4a04-b488-7e9e93e288bf@github.com>
References: <JmIOcendwRGLAVKOQ4bFrDxwNVgt1KY5LKJ-Vz-SBjg=.edcccbcb-346c-4063-b75f-09d337fa9f66@github.com>
 <ioaANin14rJBVL0cwwLg79zVULcK5IbFbbBfzpcl_GY=.1c2fb0ac-d8d5-4a04-b488-7e9e93e288bf@github.com>
Message-ID: <hCqVym3J6UtUUHcrZl77taRyrxmzyE2UJPrutfUGFZc=.87e6cfc0-2385-49c1-825f-92b8521a8e2a@github.com>

On Thu, 15 Feb 2024 12:18:17 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> In OpenJDK project CRaC I had a [need to fetch new CpuidInfo without affecting the existing one](https://github.com/openjdk/crac/commit/ed4ad9ba31b77732dcede2eb743b2f389ec9a0fe#diff-6ed856c57ddbe33e49883adb7c52ec51ed377e5f697dfd6d8bea505a97bfc5a5R2743).
>> Which led me to encapsulate the object more and I think this no-functionality-change patch is even appropriate for JDK.
>> I am sure interested primarily to reduce the CRaC patchset boilerplate.
>
> Jan Kratochvil has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into flagsencaps
>  - Remove the automatic zero-initialization
>  - Make CpuidInfo a class
>  - Merge branch 'master' into flagsencaps
>  - 8317697: refactor-encapsulate x86 VM_Version::CpuidInfo

My testing passed without new failures.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16093#issuecomment-1950251613

From ddong at openjdk.org  Sun Feb 18 02:58:21 2024
From: ddong at openjdk.org (Denghui Dong)
Date: Sun, 18 Feb 2024 02:58:21 GMT
Subject: RFR: 8326012: JFR: Event for time to safepoint [v3]
In-Reply-To: <68hS0kQgtDIk4ioAJj_r0_GLT6h0lcif6Daj6WRwxlI=.40c2a6e7-70a8-4954-bcde-9318ee311028@github.com>
References: <68hS0kQgtDIk4ioAJj_r0_GLT6h0lcif6Daj6WRwxlI=.40c2a6e7-70a8-4954-bcde-9318ee311028@github.com>
Message-ID: <rejpORxiPnxU6iwGHzaZEbCli_ZSglNq_AC3t9r4aMU=.697ddc39-3af4-43e3-ba82-7abdeece9cbe@github.com>

> There are now some JFR events related to safepoint. When time-to-safepoint (aka ttsp) is too long, these events could not be very helpful since based on them we cannot know which threads cause it and what those threads are doing.
> 
> Users can use `-XX:+SafepointTimeout -XX:SafepointTimeoutDelay=100` to see the threads that don't reach safepoint in time but without stack traces. Using `-XX:+ AbortVMOnSafepointTimeout` can capture the stack traces but it crashes the process, hence it's not sensible to enable the flag in production.
> 
> ~~This patch adds a new JFR event `EventSafepointTimeout` to record the threads that cause ttsp too long.~~
> 
> ~~This event includes two fields:~~
> 
> ~~- safepointId: the relevant safepoint id~~
> ~~- timeExceeded: the amount of time exceeding `SafepointTimeoutDelay` used by the thread to reach safepoint~~
> 
> ~~In the current version, this event records the stack of those problematic threads when they finally reach safepoint. Hence, there is a bias, but it's still helpful to deduce the root place.~~
> 
> A better implementation is to record a more accurate stack, but this will increase complexity. At the same time, the native stack may also be important for this problem, but it is not currently supported by JFR.
> 
> Any input would be greatly appreciated.
> 
> Testing: jdk/jdk/jfr

Denghui Dong has updated the pull request incrementally with ten additional commits since the last revision:

 - update
 - update
 - update
 - update
 - update
 - fix
 - update
 - whitespace
 - v2

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17888/files
  - new: https://git.openjdk.org/jdk/pull/17888/files/1e831de7..3033ca8b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17888&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17888&range=01-02

  Stats: 441 lines in 15 files changed: 301 ins; 113 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/17888.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17888/head:pull/17888

PR: https://git.openjdk.org/jdk/pull/17888

From ddong at openjdk.org  Sun Feb 18 02:58:21 2024
From: ddong at openjdk.org (Denghui Dong)
Date: Sun, 18 Feb 2024 02:58:21 GMT
Subject: RFR: 8326012: JFR: Event for time to safepoint [v2]
In-Reply-To: <MOBmQP7eddXhC1DclBriDy1zdy7xYQ8ZnvZ6XFv8mX8=.f54da08e-fb3b-47aa-b068-bc1f91815e61@github.com>
References: <68hS0kQgtDIk4ioAJj_r0_GLT6h0lcif6Daj6WRwxlI=.40c2a6e7-70a8-4954-bcde-9318ee311028@github.com>
 <MOBmQP7eddXhC1DclBriDy1zdy7xYQ8ZnvZ6XFv8mX8=.f54da08e-fb3b-47aa-b068-bc1f91815e61@github.com>
Message-ID: <A8Zdr-ZH1hgTsgHDiKK8-e7hWyRX0YoXRZisQJLOmFM=.1260e35e-a35e-4b6d-9353-20636e0151b8@github.com>

On Fri, 16 Feb 2024 14:03:21 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> There are now some JFR events related to safepoint. When time-to-safepoint (aka ttsp) is too long, these events could not be very helpful since based on them we cannot know which threads cause it and what those threads are doing.
>> 
>> Users can use `-XX:+SafepointTimeout -XX:SafepointTimeoutDelay=100` to see the threads that don't reach safepoint in time but without stack traces. Using `-XX:+ AbortVMOnSafepointTimeout` can capture the stack traces but it crashes the process, hence it's not sensible to enable the flag in production.
>> 
>> ~~This patch adds a new JFR event `EventSafepointTimeout` to record the threads that cause ttsp too long.~~
>> 
>> ~~This event includes two fields:~~
>> 
>> ~~- safepointId: the relevant safepoint id~~
>> ~~- timeExceeded: the amount of time exceeding `SafepointTimeoutDelay` used by the thread to reach safepoint~~
>> 
>> ~~In the current version, this event records the stack of those problematic threads when they finally reach safepoint. Hence, there is a bias, but it's still helpful to deduce the root place.~~
>> 
>> A better implementation is to record a more accurate stack, but this will increase complexity. At the same time, the native stack may also be important for this problem, but it is not currently supported by JFR.
>> 
>> Any input would be greatly appreciated.
>> 
>> Testing: jdk/jdk/jfr
>
> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove debug code

Convert to draft.

I improved the implementation and updated the issue title.

This patch introduces a new event `TimeToSafepoint` with the following fields:

- `safepointId`: like other safepoint-related events

- `thread`: the target Java thread

- `iterations`: the number of state check iterations for the thread

The implementation:

- First collect the ttsp information during the thread state check iterations. Note that even if the threshold is 0, the number of events may not be equal to the number of Java threads since the information will not be collected in the first `for` loop (it's not necessary in my opinion). 

- Then emit events at the end of `SafepointSynchronize::begin`, where the safepoint has been reached and stack traces can be walked safely. There is a bias, but it's still helpful.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17888#issuecomment-1950053636
PR Comment: https://git.openjdk.org/jdk/pull/17888#issuecomment-1950848310

From duke at openjdk.org  Sun Feb 18 03:27:54 2024
From: duke at openjdk.org (Yude Lin)
Date: Sun, 18 Feb 2024 03:27:54 GMT
Subject: RFR: 8323273: AArch64: Strengthen CompressedClassPointers
 initialization check for base
In-Reply-To: <7dAbar5X0NOWm-eDJPMsJH04RA0pPHf0NrjeyuMtc1Q=.5183e2d0-48c3-4f74-93aa-65f2f730fa6f@github.com>
References: <Unuzwz0YLo2jvmvcYOF3tjDI7Tr4PuoU3vedUfdUrmA=.914474fb-292f-4eeb-a82b-b3a858ab65d0@github.com>
 <7dAbar5X0NOWm-eDJPMsJH04RA0pPHf0NrjeyuMtc1Q=.5183e2d0-48c3-4f74-93aa-65f2f730fa6f@github.com>
Message-ID: <7LBqm-CobR6VfOcgCu_W_LiT1BYOOdkPexdPlNj0UXE=.18984857-3595-4e38-998f-c769d776ae28@github.com>

On Mon, 29 Jan 2024 02:25:34 GMT, Yude Lin <duke at openjdk.org> wrote:

>> Summary:
>> Add a platform-dependent check for CompressedClassSpaceBaseAddress;
>> Remove the "reserve anywhere" attempt after the initial mapping attempt failed---this is rarely used and will likely fail anyway, because the accepted mapping is very restricted on aarch64;
>> Additional assertions after initialization.
>> 
>> Passed hotspot/jtreg/:tier1 on fastdebug
>
> Ping. Can I get a review for this change?

> Hi @linade,
> 
> as part of Lilliput, we are planning larger changes to this code in mainline - see [openjdk/lilliput#128](https://github.com/openjdk/lilliput/pull/128), which will also go in a bit different form into mainline. It would be nice if you could hold off your PR until then.

Thanks for pointing out. If so, I will check again after the lilliput changes are in and see if the issue still persists. (I'll also address the review feedbacks then.) But I still think the changes are needed for the following reasons.

> But I am also not convinced the changes are needed. I see some improvements to code clarity, but those I would rather see after Lilliput hits, in a separate RFE. For the two functional main points this PR addresses:
> 
> * `CompressedClassSpaceBaseAddress` is a development debug-only tool that should do exactly what's on the label: dumbly enforce an address. Its only purpose is to observe the JVM's handling of this address. If that handling includes asserting, I'd like to see that. There is no need for more complexity - it is a simple tool with sharp edges and it only exists for tests.

The point at which the error handling happens is (init_globals->generate_stubs->..->load_klass->decode_klass_not_null), that is, trying to generate stubs. It doesn't look like a very good place to handle the errors from class space reservation (to me it looks like a double check). I would put asserts right after parsing the command-line value of CompressedClassSpaceBaseAddress, so that the reason of failing is clear.

However, since CompressedClassSpaceBaseAddress is develop, instead of adding dedicated asserts, we could also let illegal values hit the newly added assert in CompressedKlassPointers::initialize() which is the rendezvous of all reservation code.

> * I don't see what we gain by removing the "reserve anywhere" path. "It may fail with a high probability" is not enough reason - it also may succeed. At the cost of one additional mmap call (which we probably called before that point a hundred times) it still can prevent an early VM death.

The problem with the "reserve anywhere" path is that it allows illegal base address to pass (which subsequently crashes vm during generate_stubs). We could check the resulting address after we "reserve anywhere". But I just think the reservation itself is futile anyway since aarch64 imposes a strong constraint which is not easy to satisfy. So I would skip that path and then hit the added assert in CompressedKlassPointers::initialize()

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17437#issuecomment-1950892388

From duke at openjdk.org  Sun Feb 18 03:46:54 2024
From: duke at openjdk.org (Yude Lin)
Date: Sun, 18 Feb 2024 03:46:54 GMT
Subject: RFR: 8323273: AArch64: Strengthen CompressedClassPointers
 initialization check for base
In-Reply-To: <_DT-mZ1o7jeRQ2Us-Bxv4yCjoQDimd73AH3EdVj7PuE=.e40314fb-1a11-43e1-b9bd-2c8bb537ac81@github.com>
References: <Unuzwz0YLo2jvmvcYOF3tjDI7Tr4PuoU3vedUfdUrmA=.914474fb-292f-4eeb-a82b-b3a858ab65d0@github.com>
 <_DT-mZ1o7jeRQ2Us-Bxv4yCjoQDimd73AH3EdVj7PuE=.e40314fb-1a11-43e1-b9bd-2c8bb537ac81@github.com>
Message-ID: <iBR1TQQjucjbN4KaGqx_-PSWUCCaIfDhkesr_tPydls=.6949ff87-6da7-40ed-b6c1-d78073057a64@github.com>

On Fri, 9 Feb 2024 00:53:16 GMT, Dean Long <dlong at openjdk.org> wrote:

> Don't you want to add a constraint function to CompressedClassSpaceBaseAddress in globals.hpp so invalid values are rejected during command-line parsing?

Thank you. That might also work. We might not need to deliberately check for this develop value though but instead let it hit asserts in more common code (see a comment above).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17437#issuecomment-1950921130

From ddong at openjdk.org  Sun Feb 18 06:27:17 2024
From: ddong at openjdk.org (Denghui Dong)
Date: Sun, 18 Feb 2024 06:27:17 GMT
Subject: RFR: 8326012: JFR: Event for time to safepoint [v4]
In-Reply-To: <68hS0kQgtDIk4ioAJj_r0_GLT6h0lcif6Daj6WRwxlI=.40c2a6e7-70a8-4954-bcde-9318ee311028@github.com>
References: <68hS0kQgtDIk4ioAJj_r0_GLT6h0lcif6Daj6WRwxlI=.40c2a6e7-70a8-4954-bcde-9318ee311028@github.com>
Message-ID: <8Bgqu_B2NLtt2Kpz-veUhWDwp_wAaHLmm2PqNfyfDgY=.e97d88da-c274-49ec-bb7b-5c8d920307f2@github.com>

> There are now some JFR events related to safepoint. When time-to-safepoint (aka ttsp) is too long, these events could not be very helpful since based on them we cannot know which threads cause it and what those threads are doing.
> 
> Users can use `-XX:+SafepointTimeout -XX:SafepointTimeoutDelay=100` to see the threads that don't reach safepoint in time but without stack traces. Using `-XX:+ AbortVMOnSafepointTimeout` can capture the stack traces but it crashes the process, hence it's not sensible to enable the flag in production.
> 
> ~~This patch adds a new JFR event `EventSafepointTimeout` to record the threads that cause ttsp too long.~~
> 
> ~~This event includes two fields:~~
> 
> ~~- safepointId: the relevant safepoint id~~
> ~~- timeExceeded: the amount of time exceeding `SafepointTimeoutDelay` used by the thread to reach safepoint~~
> 
> ~~In the current version, this event records the stack of those problematic threads when they finally reach safepoint. Hence, there is a bias, but it's still helpful to deduce the root place.~~
> 
> A better implementation is to record a more accurate stack, but this will increase complexity. At the same time, the native stack may also be important for this problem, but it is not currently supported by JFR.
> 
> Any input would be greatly appreciated.
> 
> Testing: jdk/jdk/jfr

Denghui Dong has updated the pull request incrementally with two additional commits since the last revision:

 - update
 - update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17888/files
  - new: https://git.openjdk.org/jdk/pull/17888/files/3033ca8b..abd7bfb1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17888&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17888&range=02-03

  Stats: 34 lines in 3 files changed: 5 ins; 23 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/17888.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17888/head:pull/17888

PR: https://git.openjdk.org/jdk/pull/17888

From ddong at openjdk.org  Sun Feb 18 06:55:14 2024
From: ddong at openjdk.org (Denghui Dong)
Date: Sun, 18 Feb 2024 06:55:14 GMT
Subject: RFR: 8326012: JFR: Event for time to safepoint [v5]
In-Reply-To: <68hS0kQgtDIk4ioAJj_r0_GLT6h0lcif6Daj6WRwxlI=.40c2a6e7-70a8-4954-bcde-9318ee311028@github.com>
References: <68hS0kQgtDIk4ioAJj_r0_GLT6h0lcif6Daj6WRwxlI=.40c2a6e7-70a8-4954-bcde-9318ee311028@github.com>
Message-ID: <IkpdsjYW88zG159yYzcfcMkjsmkpPVDmE_9ZDuUlNkc=.ff0ed78f-93ac-4e40-aed9-2b01ea8cbaf5@github.com>

> There are now some JFR events related to safepoint. When time-to-safepoint (aka ttsp) is too long, these events could not be very helpful since based on them we cannot know which threads cause it and what those threads are doing.
> 
> Users can use `-XX:+SafepointTimeout -XX:SafepointTimeoutDelay=100` to see the threads that don't reach safepoint in time but without stack traces. Using `-XX:+ AbortVMOnSafepointTimeout` can capture the stack traces but it crashes the process, hence it's not sensible to enable the flag in production.
> 
> ~~This patch adds a new JFR event `EventSafepointTimeout` to record the threads that cause ttsp too long.~~
> 
> ~~This event includes two fields:~~
> 
> ~~- safepointId: the relevant safepoint id~~
> ~~- timeExceeded: the amount of time exceeding `SafepointTimeoutDelay` used by the thread to reach safepoint~~
> 
> ~~In the current version, this event records the stack of those problematic threads when they finally reach safepoint. Hence, there is a bias, but it's still helpful to deduce the root place.~~
> 
> A better implementation is to record a more accurate stack, but this will increase complexity. At the same time, the native stack may also be important for this problem, but it is not currently supported by JFR.
> 
> Any input would be greatly appreciated.
> 
> Testing: jdk/jdk/jfr

Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:

  update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17888/files
  - new: https://git.openjdk.org/jdk/pull/17888/files/abd7bfb1..9c7db130

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17888&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17888&range=03-04

  Stats: 7 lines in 2 files changed: 0 ins; 5 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17888.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17888/head:pull/17888

PR: https://git.openjdk.org/jdk/pull/17888

From ddong at openjdk.org  Sun Feb 18 08:01:00 2024
From: ddong at openjdk.org (Denghui Dong)
Date: Sun, 18 Feb 2024 08:01:00 GMT
Subject: RFR: 8326111: JFR: Cleanup for JFR_ONLY
Message-ID: <ejPq_N_6Trx4KaqeRZwBulHr-ndZb7MJqbZbHTO8MqM=.cc3d7239-9c2f-4556-939d-7fb72378a551@github.com>

Greeting,

Could I have a review of this trivial change that cleans up code where used JFR_ONLY incorrectly?

testing: build with --enable-jvm-feature-jfr and --disable-jvm-feature-jfr

Denghui

-------------

Commit messages:
 - 8326111: JFR: Cleanup for JFR_ONLY

Changes: https://git.openjdk.org/jdk/pull/17903/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17903&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8326111
  Stats: 9 lines in 5 files changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/17903.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17903/head:pull/17903

PR: https://git.openjdk.org/jdk/pull/17903

From ddong at openjdk.org  Sun Feb 18 08:10:16 2024
From: ddong at openjdk.org (Denghui Dong)
Date: Sun, 18 Feb 2024 08:10:16 GMT
Subject: RFR: 8326111: JFR: Cleanup for JFR_ONLY [v2]
In-Reply-To: <ejPq_N_6Trx4KaqeRZwBulHr-ndZb7MJqbZbHTO8MqM=.cc3d7239-9c2f-4556-939d-7fb72378a551@github.com>
References: <ejPq_N_6Trx4KaqeRZwBulHr-ndZb7MJqbZbHTO8MqM=.cc3d7239-9c2f-4556-939d-7fb72378a551@github.com>
Message-ID: <JkreW92RpA8VDWs1id6RrXd5sV2TZsLKvp36NepmE3s=.23102365-e003-4b3d-948e-8d4579668422@github.com>

> Greeting,
> 
> Could I have a review of this trivial change that cleans up code where used JFR_ONLY incorrectly?
> 
> testing: build with --enable-jvm-feature-jfr and --disable-jvm-feature-jfr
> 
> Denghui

Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:

  more cleanup

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17903/files
  - new: https://git.openjdk.org/jdk/pull/17903/files/fb3fcab2..75710690

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17903&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17903&range=00-01

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/17903.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17903/head:pull/17903

PR: https://git.openjdk.org/jdk/pull/17903

From aph at openjdk.org  Sun Feb 18 09:48:53 2024
From: aph at openjdk.org (Andrew Haley)
Date: Sun, 18 Feb 2024 09:48:53 GMT
Subject: RFR: 8323273: AArch64: Strengthen CompressedClassPointers
 initialization check for base
In-Reply-To: <7LBqm-CobR6VfOcgCu_W_LiT1BYOOdkPexdPlNj0UXE=.18984857-3595-4e38-998f-c769d776ae28@github.com>
References: <Unuzwz0YLo2jvmvcYOF3tjDI7Tr4PuoU3vedUfdUrmA=.914474fb-292f-4eeb-a82b-b3a858ab65d0@github.com>
 <7dAbar5X0NOWm-eDJPMsJH04RA0pPHf0NrjeyuMtc1Q=.5183e2d0-48c3-4f74-93aa-65f2f730fa6f@github.com>
 <7LBqm-CobR6VfOcgCu_W_LiT1BYOOdkPexdPlNj0UXE=.18984857-3595-4e38-998f-c769d776ae28@github.com>
Message-ID: <KtIavBkzLt4dhy69RMKGTaH8HuXvxMSUaiZ-0Tb0Ox8=.821e9fff-fbf1-4d8a-bf9c-33bc06f69266@github.com>

On Sun, 18 Feb 2024 03:25:12 GMT, Yude Lin <duke at openjdk.org> wrote:

>   `CompressedClassSpaceBaseAddress` is a development debug-only tool that should do exactly what's on the label: dumbly enforce an address. Its only purpose is to observe the JVM's handling of this address. If that handling includes asserting, I'd like to see that. There is no need for more complexity - it is a simple tool with sharp edges and it only exists for tests.

Exactly this. Not a bug.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17437#issuecomment-1951057703

From aph-open at littlepinkcloud.com  Sun Feb 18 10:15:49 2024
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Sun, 18 Feb 2024 10:15:49 +0000
Subject: Hotspot symbol visibility
In-Reply-To: <645132e0-687e-4f04-9e49-f90131294367@oracle.com>
References: <645132e0-687e-4f04-9e49-f90131294367@oracle.com>
Message-ID: <97081168-46cc-4b9c-9721-add8f8b0c21a@littlepinkcloud.com>

On 2/14/24 10:06, Magnus Ihse Bursie wrote:
> My takeaway from the discussions is that we are most likely exporting a
> way too broad set of symbols to SA. It seems likely that this set can be
> drastically cut down. Actually getting an understanding of exactly which
> symbols SA need seem like a very good first step.
> 
> So, is this a journey anyone would be interested in embarkering on? I
> will help as much as I can from a build PoV, but I have no clue
> whatsoever about what SA needs.

Alternatively, we have separate debuginfo. SA can use the debug symbols,
allowing us to strip all others. What's wrong with this reasoning?

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From ddong at openjdk.org  Sun Feb 18 18:31:24 2024
From: ddong at openjdk.org (Denghui Dong)
Date: Sun, 18 Feb 2024 18:31:24 GMT
Subject: RFR: 8326012: JFR: Event for time to safepoint [v6]
In-Reply-To: <68hS0kQgtDIk4ioAJj_r0_GLT6h0lcif6Daj6WRwxlI=.40c2a6e7-70a8-4954-bcde-9318ee311028@github.com>
References: <68hS0kQgtDIk4ioAJj_r0_GLT6h0lcif6Daj6WRwxlI=.40c2a6e7-70a8-4954-bcde-9318ee311028@github.com>
Message-ID: <CEHJyB8AQQFjUkL07QfHjBabtB31DnXxxcqPaWYoLEs=.fc38387b-24f3-4911-9cdb-5ff844396a43@github.com>

> There are now some JFR events related to safepoint. When time-to-safepoint (aka ttsp) is too long, these events could not be very helpful since based on them we cannot know which threads cause it and what those threads are doing.
> 
> Users can use `-XX:+SafepointTimeout -XX:SafepointTimeoutDelay=100` to see the threads that don't reach safepoint in time but without stack traces. Using `-XX:+ AbortVMOnSafepointTimeout` can capture the stack traces but it crashes the process, hence it's not sensible to enable the flag in production.
> 
> ~~This patch adds a new JFR event `EventSafepointTimeout` to record the threads that cause ttsp too long.~~
> 
> ~~This event includes two fields:~~
> 
> ~~- safepointId: the relevant safepoint id~~
> ~~- timeExceeded: the amount of time exceeding `SafepointTimeoutDelay` used by the thread to reach safepoint~~
> 
> ~~In the current version, this event records the stack of those problematic threads when they finally reach safepoint. Hence, there is a bias, but it's still helpful to deduce the root place.~~
> 
> A better implementation is to record a more accurate stack, but this will increase complexity. At the same time, the native stack may also be important for this problem, but it is not currently supported by JFR.
> 
> Any input would be greatly appreciated.
> 
> Testing: jdk/jdk/jfr

Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:

  refactor

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17888/files
  - new: https://git.openjdk.org/jdk/pull/17888/files/9c7db130..6e68c8b2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17888&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17888&range=04-05

  Stats: 214 lines in 5 files changed: 123 ins; 82 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/17888.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17888/head:pull/17888

PR: https://git.openjdk.org/jdk/pull/17888

From ddong at openjdk.org  Sun Feb 18 19:01:20 2024
From: ddong at openjdk.org (Denghui Dong)
Date: Sun, 18 Feb 2024 19:01:20 GMT
Subject: RFR: 8326012: JFR: Event for time to safepoint [v7]
In-Reply-To: <68hS0kQgtDIk4ioAJj_r0_GLT6h0lcif6Daj6WRwxlI=.40c2a6e7-70a8-4954-bcde-9318ee311028@github.com>
References: <68hS0kQgtDIk4ioAJj_r0_GLT6h0lcif6Daj6WRwxlI=.40c2a6e7-70a8-4954-bcde-9318ee311028@github.com>
Message-ID: <Gk0a3vASLkv_owDsWGp0tGDb6_8dMykIbwv2II3GyIA=.13952015-8f6c-40b7-b159-4643d249c1e0@github.com>

> There are now some JFR events related to safepoint. When time-to-safepoint (aka ttsp) is too long, these events could not be very helpful since based on them we cannot know which threads cause it and what those threads are doing.
> 
> Users can use `-XX:+SafepointTimeout -XX:SafepointTimeoutDelay=100` to see the threads that don't reach safepoint in time but without stack traces. Using `-XX:+ AbortVMOnSafepointTimeout` can capture the stack traces but it crashes the process, hence it's not sensible to enable the flag in production.
> 
> ~~This patch adds a new JFR event `EventSafepointTimeout` to record the threads that cause ttsp too long.~~
> 
> ~~This event includes two fields:~~
> 
> ~~- safepointId: the relevant safepoint id~~
> ~~- timeExceeded: the amount of time exceeding `SafepointTimeoutDelay` used by the thread to reach safepoint~~
> 
> ~~In the current version, this event records the stack of those problematic threads when they finally reach safepoint. Hence, there is a bias, but it's still helpful to deduce the root place.~~
> 
> A better implementation is to record a more accurate stack, but this will increase complexity. At the same time, the native stack may also be important for this problem, but it is not currently supported by JFR.
> 
> Any input would be greatly appreciated.
> 
> Testing: jdk/jdk/jfr

Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:

  update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17888/files
  - new: https://git.openjdk.org/jdk/pull/17888/files/6e68c8b2..af5537f0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17888&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17888&range=05-06

  Stats: 13 lines in 2 files changed: 9 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/17888.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17888/head:pull/17888

PR: https://git.openjdk.org/jdk/pull/17888

From ddong at openjdk.org  Mon Feb 19 01:10:18 2024
From: ddong at openjdk.org (Denghui Dong)
Date: Mon, 19 Feb 2024 01:10:18 GMT
Subject: RFR: 8326012: JFR: Event for time to safepoint [v8]
In-Reply-To: <68hS0kQgtDIk4ioAJj_r0_GLT6h0lcif6Daj6WRwxlI=.40c2a6e7-70a8-4954-bcde-9318ee311028@github.com>
References: <68hS0kQgtDIk4ioAJj_r0_GLT6h0lcif6Daj6WRwxlI=.40c2a6e7-70a8-4954-bcde-9318ee311028@github.com>
Message-ID: <8Kdd3sZB_lb83jNJnt-vderdH94ai-wRA8I9cjojIlQ=.065b1c44-419f-4f77-9374-aadb46f987ce@github.com>

> There are now some JFR events related to safepoint. When time-to-safepoint (aka ttsp) is too long, these events could not be very helpful since based on them we cannot know which threads cause it and what those threads are doing.
> 
> Users can use `-XX:+SafepointTimeout -XX:SafepointTimeoutDelay=100` to see the threads that don't reach safepoint in time but without stack traces. Using `-XX:+ AbortVMOnSafepointTimeout` can capture the stack traces but it crashes the process, hence it's not sensible to enable the flag in production.
> 
> ~~This patch adds a new JFR event `EventSafepointTimeout` to record the threads that cause ttsp too long.~~
> 
> ~~This event includes two fields:~~
> 
> ~~- safepointId: the relevant safepoint id~~
> ~~- timeExceeded: the amount of time exceeding `SafepointTimeoutDelay` used by the thread to reach safepoint~~
> 
> ~~In the current version, this event records the stack of those problematic threads when they finally reach safepoint. Hence, there is a bias, but it's still helpful to deduce the root place.~~
> 
> A better implementation is to record a more accurate stack, but this will increase complexity. At the same time, the native stack may also be important for this problem, but it is not currently supported by JFR.
> 
> Any input would be greatly appreciated.
> 
> Testing: jdk/jdk/jfr

Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:

  fix test failures

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17888/files
  - new: https://git.openjdk.org/jdk/pull/17888/files/af5537f0..1c006732

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17888&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17888&range=06-07

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17888.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17888/head:pull/17888

PR: https://git.openjdk.org/jdk/pull/17888

From fyang at openjdk.org  Mon Feb 19 03:37:57 2024
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 19 Feb 2024 03:37:57 GMT
Subject: RFR: 8322179: RISC-V: Implement SHA-1 intrinsic [v10]
In-Reply-To: <bAQOJj5ESbBOFxTqNRBDf36jquSMydvN_ey2CleFmD0=.8d3ff5c7-3c78-4113-af39-7dbba435f591@github.com>
References: <PyIXzENfiHysFS3IyZn3FDNQpV7Ua2L6OmjiXq9wRoU=.cf74a45e-c94b-4f7b-8768-d10d55e2ce1d@github.com>
 <bAQOJj5ESbBOFxTqNRBDf36jquSMydvN_ey2CleFmD0=.8d3ff5c7-3c78-4113-af39-7dbba435f591@github.com>
Message-ID: <GIFzLolfS5IlNcCGzsV7b0vjeqmNedCdQZubh-zywsg=.6239158c-d99e-45f7-954c-7c2f6ba834a2@github.com>

On Tue, 6 Feb 2024 15:36:12 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you review this patch to implement SHA-1 intrinsic for riscv?
>> Thanks!
>> 
>> 
>> ## Test
>> 
>> ### Functionality
>> 
>> tests under `test/hotspot/jtreg/compiler/intrinsics/sha`
>> tests found via `find test/jdk -iname "*SHA1*.java"`
>> 
>> ### Performance
>> 
>> tested on `T-HEAD Light Lichee Pi 4A`
>> 
>> JMH_PARAMS="-f 1 -wi 10 -i 20" // for every loop of jmh test
>> 
>> benchmark tests `MessageDigests.java GetMessageDigest.java MessageDigestBench.java MacBench.java` which are under `test/micro/org/openjdk/bench/`, more spcifically `TESTS="MessageDigests.digest MessageDigests.getAndDigest MessageDigestBench.digest"`
>> 
>> 
>> // After
>> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1        64     DEFAULT  avgt   20      1845.446 ?     27.052  ns/op
>> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    181455.350 ?    532.258  ns/op
>> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2447.674 ?     10.239  ns/op
>> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    182896.083 ?   1242.774  ns/op
>> o.o.b.javax.crypto.small.MessageDigestBench.digest         SHA1     1048576             N/A       N/A              avgt   20  11599227.792 ? 121442.390  ns/op
>> // Before
>> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2352.475 ?    11.198  ns/op
>> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    188495.684 ?  1467.942  ns/op
>> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2437.347 ?     6.398  ns/op
>> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    196086.570 ?  1140.998  ns/op
>> o.o.b.javax.crypto.small.MessageDigestBench.digest         SHA1     1048576             N/A       N/A              avgt   20  12362160.119 ? 38788.109  ns/op
>> 
>> 
>> **getAndDigest when size == 64**
>> The data is not stable for test getAndDigest when size == 64, which I think is introduced by  j.s.MessageDigest.getInstance itself, which we don't touch in this patch.
>> Check more details at [1](ht...
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   refine register usage and comment

Hi, Thanks for the quick update. A couple of minor comments remain after another look.

src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 4820:

> 4818:   //    8f1bbcdc, 40 <= t <= 59
> 4819:   //    ca62c1d6, 60 <= t <= 79
> 4820:   void sha1_prepare_k(int round, Register cur_k) {

Personally, I prefer to move `int round` as the last formal param. Similar for the other several assember funtions which also have this same param.

src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 4835:

> 4833:     assert(round >= 0 && round < 80, "must be");
> 4834: 
> 4835:     if (round < 16) {

Could you please also add a code comment about how the valid w't values are laid out in the w't registers for the first 16 rounds?

src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 4946:

> 4944:     {
> 4945:       // reuse e as a temporary register, as we will mv new value into it later
> 4946:       Register t = e;

For consistency, I would suggest register alias names like `tmp1`, `tmp2`, `tmp3`, instead of `t`. Could you please also create an alias for `cur_w`? I see it is used as a temp register here too.

src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 4953:

> 4951:       __ rolw_imm(cur_w, a, 5, t0);
> 4952:       // as pointed above, we can use cur_w as temporary register here.
> 4953:       sha1_f(round, tmp, b, c, d);

Could we also reuse `cur_k` in this function where input param `tmp` is used? I see `cur_k` will also be recalculated at the beginning of each round like `cur_w`. Hope this could help eliminate `tmp` param and finally free `t2`.

src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 5060:

> 5058:     // put two adjecent w's in one register:
> 5059:     //    one at high word part, another at low word part
> 5060:     // at different round (even or odd), w't value resdie in different items in ws[].

Typo: s/resdie/reside/

src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 5123:

> 5121: 
> 5122:     if (multi_block) {
> 5123:       __ bge(limit, buf, L_sha1_loop, true);

A small question: Is it OK to continue the loop when `limit` equals `buf`?

src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 5129:

> 5127:     __ mv(mask32, 0xffffffff);
> 5128:     // store back the state.
> 5129:     __ andr(a, a, mask32);

Why not emit one `__ zero_extend(a, a, 32)` here instead like you do in `sha1_preserve_prev_abcde`? This will save us one instruction (the preceding mov to mask32 instruction) when the `zext_w` from UseZba is available and will also help free `t2`.

src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 5133:

> 5131:     __ orr(a, a, b);
> 5132:     __ sd(a, Address(state, 0));
> 5133:     __ andr(c, c, mask32);

Similar here.

-------------

PR Review: https://git.openjdk.org/jdk/pull/17130#pullrequestreview-1873563008
PR Review Comment: https://git.openjdk.org/jdk/pull/17130#discussion_r1485015419
PR Review Comment: https://git.openjdk.org/jdk/pull/17130#discussion_r1493967123
PR Review Comment: https://git.openjdk.org/jdk/pull/17130#discussion_r1485013608
PR Review Comment: https://git.openjdk.org/jdk/pull/17130#discussion_r1493337316
PR Review Comment: https://git.openjdk.org/jdk/pull/17130#discussion_r1493341768
PR Review Comment: https://git.openjdk.org/jdk/pull/17130#discussion_r1493159778
PR Review Comment: https://git.openjdk.org/jdk/pull/17130#discussion_r1491927454
PR Review Comment: https://git.openjdk.org/jdk/pull/17130#discussion_r1491927796

From stuefe at openjdk.org  Mon Feb 19 07:56:57 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 19 Feb 2024 07:56:57 GMT
Subject: RFR: 8323273: AArch64: Strengthen CompressedClassPointers
 initialization check for base
In-Reply-To: <7LBqm-CobR6VfOcgCu_W_LiT1BYOOdkPexdPlNj0UXE=.18984857-3595-4e38-998f-c769d776ae28@github.com>
References: <Unuzwz0YLo2jvmvcYOF3tjDI7Tr4PuoU3vedUfdUrmA=.914474fb-292f-4eeb-a82b-b3a858ab65d0@github.com>
 <7dAbar5X0NOWm-eDJPMsJH04RA0pPHf0NrjeyuMtc1Q=.5183e2d0-48c3-4f74-93aa-65f2f730fa6f@github.com>
 <7LBqm-CobR6VfOcgCu_W_LiT1BYOOdkPexdPlNj0UXE=.18984857-3595-4e38-998f-c769d776ae28@github.com>
Message-ID: <zUtrsKJ_aocTf_XXsDO7T_c3IHPjo0FNyX6a4jcmF_8=.4f16d770-7e4a-4e6b-8538-570f8d4d1e67@github.com>

On Sun, 18 Feb 2024 03:25:12 GMT, Yude Lin <duke at openjdk.org> wrote:

> > But I am also not convinced the changes are needed. I see some improvements to code clarity, but those I would rather see after Lilliput hits, in a separate RFE. For the two functional main points this PR addresses:
> > 
> > * `CompressedClassSpaceBaseAddress` is a development debug-only tool that should do exactly what's on the label: dumbly enforce an address. Its only purpose is to observe the JVM's handling of this address. If that handling includes asserting, I'd like to see that. There is no need for more complexity - it is a simple tool with sharp edges and it only exists for tests.
> 
> The point at which the error handling happens is (init_globals->generate_stubs->..->load_klass->decode_klass_not_null), that is, trying to generate stubs. It doesn't look like a very good place to handle the errors from class space reservation (to me it looks like a double check). I would put asserts right after parsing the command-line value of CompressedClassSpaceBaseAddress, so that the reason of failing is clear.
> 
> However, since CompressedClassSpaceBaseAddress is develop, instead of adding dedicated asserts, we could also let illegal values hit the newly added assert in CompressedKlassPointers::initialize() which is the rendezvous of all reservation code.
> 
> > * I don't see what we gain by removing the "reserve anywhere" path. "It may fail with a high probability" is not enough reason - it also may succeed. At the cost of one additional mmap call (which we probably called before that point a hundred times) it still can prevent an early VM death.
> 
> The problem with the "reserve anywhere" path is that it allows illegal base address to pass (which subsequently crashes vm during generate_stubs). We could check the resulting address after we "reserve anywhere". But I just think the reservation itself is futile anyway since aarch64 imposes a strong constraint which is not easy to satisfy. So I would skip that path and then hit the added assert in CompressedKlassPointers::initialize()

I think most of your changes are unnecessary, sorry, for the reasons stated in my last answer. In your patch, I dislike the duplication of the assert logic, increasing the MacroAssembler API surface, and the strange return code contract of `eor_compatible_klass_encoding`. 

But lets step back a bit. We worked quite hard to make the class space reservation on Arm64 to work with an extremely high probability. Do you see the "reserve_anywhere" path hit somewhere for real? If so, I'd be interested in the context - which machine (an sbc?), which linux, which kernel, which settings, and so on.

Also, it would be a lot nicer to not have to worry about this at all. I took a stab last summer in adding a decoding mode that would just work with any address, similar to how PPC does it (https://github.com/openjdk/jdk/blob/3742bc626e80f597373913f02e79c5231e1b7dbc/src/hotspot/cpu/ppc/assembler_ppc.cpp#L467) but I found that I couldn't do it for the case where I only have one register to work with in `decode_klass_not_null()`, and it was not clear to me which registers were scratchable (I also did not try very hard, admittedly).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17437#issuecomment-1951884055

From lucy at openjdk.org  Mon Feb 19 08:27:54 2024
From: lucy at openjdk.org (Lutz Schmidt)
Date: Mon, 19 Feb 2024 08:27:54 GMT
Subject: RFR: JDK-8325116: Amend jdk.ContainerConfiguration by swap related
 value
In-Reply-To: <0UFSBwJVq31ZaVhhm7ssaR5jNa2AALYUgHtBWIQxi9Y=.b3e42160-9d6f-4e99-83ee-7f08f85d04c1@github.com>
References: <0UFSBwJVq31ZaVhhm7ssaR5jNa2AALYUgHtBWIQxi9Y=.b3e42160-9d6f-4e99-83ee-7f08f85d04c1@github.com>
Message-ID: <ClP5Fi04MWEyqnjthdPuyeEhZhfI6dwTRiqieAsKves=.353f496e-bc78-4575-b66b-488308a7f3af@github.com>

On Thu, 15 Feb 2024 08:26:40 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> jdk.ContainerInformation event could get amended to report the host total swap values for Linux like was done in
> https://bugs.openjdk.org/browse/JDK-8296671 by host total memory.
> Two additional fields could be added hostSwapTotal, maybe hostSwapFree;
> container free swap space in case we find a good implementation, could also be added to the implementation in os_linux.

Looks good.

-------------

Marked as reviewed by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17865#pullrequestreview-1887812667

From aph at openjdk.org  Mon Feb 19 09:03:54 2024
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 19 Feb 2024 09:03:54 GMT
Subject: RFR: 8323273: AArch64: Strengthen CompressedClassPointers
 initialization check for base
In-Reply-To: <zUtrsKJ_aocTf_XXsDO7T_c3IHPjo0FNyX6a4jcmF_8=.4f16d770-7e4a-4e6b-8538-570f8d4d1e67@github.com>
References: <Unuzwz0YLo2jvmvcYOF3tjDI7Tr4PuoU3vedUfdUrmA=.914474fb-292f-4eeb-a82b-b3a858ab65d0@github.com>
 <7dAbar5X0NOWm-eDJPMsJH04RA0pPHf0NrjeyuMtc1Q=.5183e2d0-48c3-4f74-93aa-65f2f730fa6f@github.com>
 <7LBqm-CobR6VfOcgCu_W_LiT1BYOOdkPexdPlNj0UXE=.18984857-3595-4e38-998f-c769d776ae28@github.com>
 <zUtrsKJ_aocTf_XXsDO7T_c3IHPjo0FNyX6a4jcmF_8=.4f16d770-7e4a-4e6b-8538-570f8d4d1e67@github.com>
Message-ID: <u8w796JBiWIQ_hsMLUV6-BAYtwGVHPygP1YRpBvxVlU=.ced35eb0-5554-4f6e-b17d-959402db3060@github.com>

On Mon, 19 Feb 2024 07:54:18 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Also, it would be a lot nicer to not have to worry about this at all. I took a stab last summer in adding a decoding mode that would just work with any address, similar to how PPC does it (

I think we should leave this stuff alone. Compressed klass pointer handling has been around the block a few times, and there's little possibility of providing much more benefit to our end users. We've got something that is highly reliable and almost maximally performant.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17437#issuecomment-1951986653

From stuefe at openjdk.org  Mon Feb 19 09:20:54 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 19 Feb 2024 09:20:54 GMT
Subject: RFR: 8323273: AArch64: Strengthen CompressedClassPointers
 initialization check for base
In-Reply-To: <u8w796JBiWIQ_hsMLUV6-BAYtwGVHPygP1YRpBvxVlU=.ced35eb0-5554-4f6e-b17d-959402db3060@github.com>
References: <Unuzwz0YLo2jvmvcYOF3tjDI7Tr4PuoU3vedUfdUrmA=.914474fb-292f-4eeb-a82b-b3a858ab65d0@github.com>
 <7dAbar5X0NOWm-eDJPMsJH04RA0pPHf0NrjeyuMtc1Q=.5183e2d0-48c3-4f74-93aa-65f2f730fa6f@github.com>
 <7LBqm-CobR6VfOcgCu_W_LiT1BYOOdkPexdPlNj0UXE=.18984857-3595-4e38-998f-c769d776ae28@github.com>
 <zUtrsKJ_aocTf_XXsDO7T_c3IHPjo0FNyX6a4jcmF_8=.4f16d770-7e4a-4e6b-8538-570f8d4d1e67@github.com>
 <u8w796JBiWIQ_hsMLUV6-BAYtwGVHPygP1YRpBvxVlU=.ced35eb0-5554-4f6e-b17d-959402db3060@github.com>
Message-ID: <oipZZvyodh2MGF-R-nnFn2OhDemQDjS-NlXBGCHHhNg=.ca7a3102-c350-4664-9cfa-dc06907cfd28@github.com>

On Mon, 19 Feb 2024 09:01:25 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > Also, it would be a lot nicer to not have to worry about this at all. I took a stab last summer in adding a decoding mode that would just work with any address, similar to how PPC does it (
> 
> I think we should leave this stuff alone. Compressed klass pointer handling has been around the block a few times, and there's little possibility of providing much more benefit to our end users. We've got something that is highly reliable and almost maximally performant.

Okay. Seeing how rare the failing of reservation is, I came to the same conclusion.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17437#issuecomment-1952016853

From epeter at openjdk.org  Mon Feb 19 09:29:54 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 19 Feb 2024 09:29:54 GMT
Subject: RFR: 8325095: C2: bailout message broken: ResourceArea allocated
 string used after free [v2]
In-Reply-To: <3vkOL-tts6lwRj1M4JYK5GdaAK6Tqc0-sOS6RG4nsac=.752d5dc9-6914-4ae6-958f-95049eafc441@github.com>
References: <8Bl6JSxb-fd1xAsKOMzBakRFuruoqJykP7JEn57k6qY=.717f89af-2aa7-439b-afd1-768dd39f51da@github.com>
 <qnutyTCjwk_JFTIZcs-xW_PVAcFGogjJjCjeh1KAbTg=.fa1b659a-eac6-4f83-9eed-f9a0d4b239b5@github.com>
 <By6S6aqP_qRgnLVbbC1HcY2xvlYVkbGztxV1JdeUWIg=.0504185b-8bba-46a7-bbd0-dbef9b10be47@github.com>
 <MBix7LMnmfO7Zh89a5LUN_jXroE12XATCOBhYe74nNI=.4342ad8e-1cd3-4b75-894d-7dabb32663d3@github.com>
 <fUIR8mpl31uEeB5_iI__2ZT8beBfRIIz6vhAwly60EE=.08bab015-655f-4ad1-b71f-018e1c1b79d8@github.com>
 <3vkOL-tts6lwRj1M4JYK5GdaAK6Tqc0-sOS6RG4nsac=.752d5dc9-6914-4ae6-958f-95049eafc441@github.com>
Message-ID: <Z5JnnrT3kvBpPlCBnyxssik_f4CV_0eSJ1h0nZ8lCkE=.2005ddc9-6cba-437e-9511-ff91b2f64ea7@github.com>

On Sat, 17 Feb 2024 01:34:56 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Piling on... I opt for keeping this code simple. A list of subsequent failure states could easily be part of logging.
>
> Okay, I am voting for UL to print all failures we hit during compilation and keep reporting only one reason at the end.
> 
> log_error(compilation) (failiure_reason);
> 
> Or `log_warning()`

@vnkozlov @dean-long @tstuefe 
Ok, I mean logging of additional failure reasons might even be done in a separate RFE, right?
But don't we already log the failures? I mean there is the `log()->elem(` code.

And should I still keep the "most important" failure reason?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17710#discussion_r1494243314

From epeter at openjdk.org  Mon Feb 19 09:35:59 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 19 Feb 2024 09:35:59 GMT
Subject: RFR: 8325095: C2: bailout message broken: ResourceArea allocated
 string used after free [v2]
In-Reply-To: <xqWyNkVeEGgmfeKRi85M_PhZjwfO4TT0dkVn8hova5s=.e7d9f390-56c8-4fe7-86f1-bab34a2cebcc@github.com>
References: <8Bl6JSxb-fd1xAsKOMzBakRFuruoqJykP7JEn57k6qY=.717f89af-2aa7-439b-afd1-768dd39f51da@github.com>
 <iqVK2jP6-y3NweZYd_Y6Eo39GUH9hf8gFugp8aq3-dw=.54a735a9-9cf2-411d-89aa-19dcbef22937@github.com>
 <xqWyNkVeEGgmfeKRi85M_PhZjwfO4TT0dkVn8hova5s=.e7d9f390-56c8-4fe7-86f1-bab34a2cebcc@github.com>
Message-ID: <9iU6MICSActd21DYiFo9nmoBWL3d83_Yb9ioP4YZGMg=.964ee7c7-5ac3-4e33-80b4-29f65476ceb2@github.com>

On Sat, 17 Feb 2024 00:34:58 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove OrderAccess::storestore() bc single threaded only
>
> src/hotspot/share/compiler/compileBroker.cpp line 2333:
> 
>> 2331:       // Duplicate the failure reason string, so that it outlives ciEnv
>> 2332:       failure_reason = os::strdup(ci_env.failure_reason(), mtCompiler);
>> 2333:       bool reason_on_C_heap = true;
> 
> Did you mean: `failure_reason_on_C_heap = true;`?

You are right. Fixing it.

Ha, copied this from above lines:

        failure_reason = os::strdup(err_msg("Error attaching to libjvmci (err: %d, %s)",
                                    env.init_error(), msg == nullptr ? "unknown" : msg), mtJVMCI);
        bool reason_on_C_heap = true;
        // In case of JNI_ENOMEM, there's a good chance a subsequent attempt to create libjvmci or attach to it
        // might succeed. Other errors most likely indicate a non-recoverable error in the JVMCI runtime.
        bool retryable = env.init_error() == JNI_ENOMEM;
        compile_state.set_failure(retryable, failure_reason, reason_on_C_heap);

I guess here the variable is local, and `compile_state.set_failure(` "eats" up the reference (i.e. becomes the owner). But the reference to the string is also held by `failure_reason`. This is so nasty ? :

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17710#discussion_r1494250826

From epeter at openjdk.org  Mon Feb 19 09:36:00 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 19 Feb 2024 09:36:00 GMT
Subject: RFR: 8325095: C2: bailout message broken: ResourceArea allocated
 string used after free [v2]
In-Reply-To: <jeKUAzI09dUeQ3YjojKl9_Ub-mhB83-uDda83zXTI14=.85dfe959-3f79-4574-80d9-dc601666cdd1@github.com>
References: <8Bl6JSxb-fd1xAsKOMzBakRFuruoqJykP7JEn57k6qY=.717f89af-2aa7-439b-afd1-768dd39f51da@github.com>
 <iqVK2jP6-y3NweZYd_Y6Eo39GUH9hf8gFugp8aq3-dw=.54a735a9-9cf2-411d-89aa-19dcbef22937@github.com>
 <jqqrLSVksbMxHDSRUlWJIn2RQBqJNmqX1zWJpimejZ4=.df378fba-ba92-48d9-a104-cc507b19471e@github.com>
 <jeKUAzI09dUeQ3YjojKl9_Ub-mhB83-uDda83zXTI14=.85dfe959-3f79-4574-80d9-dc601666cdd1@github.com>
Message-ID: <7ZsXMkV2LrAyJNc5WZKmh37hkond7IkeFzoCLNKZYFc=.048663e7-6afe-4ec1-b872-f7074a7990d0@github.com>

On Sat, 17 Feb 2024 00:55:15 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> src/hotspot/share/utilities/cHeapStringHolder.hpp line 41:
>> 
>>> 39:     _memflags(memflags), _string(nullptr) {}
>>> 40:   ~CHeapStringHolder() { clear(); };
>>> 41:   NONCOPYABLE(CHeapStringHolder);
>> 
>> I'd opt for a use-case-specific class inside compiler. It would allow you to hard-code mtCompiler, simplifying the code, and to log with UL into the compiler log when the failure reason is changed.
>> 
>> A new generic string class opens a whole can of bikeshedding worms, e.g. whether to make it mutable, how best to specify MEMFLAGS etc... I would avoid that, especially since the added value fo this helper class is slim.
>
> I agree this should be in `compiler/`

Ok, I can do that. Just wanted it to be shared code in case someone needs it in the future. But maybe that is too hard to do, due to bikeshedding... :/

Not sure I want to UL here, since I hold the string in multiple places, that would lead to multiple loggings.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17710#discussion_r1494256565

From sroy at openjdk.org  Mon Feb 19 10:05:17 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 19 Feb 2024 10:05:17 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v23]
In-Reply-To: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
Message-ID: <HN-bL-HmykOa-uJTej8Ud3tC6usQvPywTfUV7XO-t-o=.22f9b270-6d72-4e8c-a90b-97ab6c816888@github.com>

> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am.
> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX.
> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails.

Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16604/files
  - new: https://git.openjdk.org/jdk/pull/16604/files/c6332f67..f5693f47

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=21-22

  Stats: 16 lines in 1 file changed: 8 ins; 3 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/16604.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604

PR: https://git.openjdk.org/jdk/pull/16604

From sroy at openjdk.org  Mon Feb 19 10:09:00 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 19 Feb 2024 10:09:00 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v22]
In-Reply-To: <Fkts1yURlLD-wbc7mvHBNlhe2AilyyETaJuQ0QS2YEU=.2ad2349c-c774-4058-b3da-7a2cd9ea6f11@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <LHKPKfz60cA4rddKKT51OUG7jxispd9M7A0io897pG0=.d8b3c965-755b-4500-a3f1-72b578045060@github.com>
 <F5C_TjQXv6KNpn3yN8J37_eSIOWtRYZT3RwNkSu-Xq0=.723d24c7-355e-42e6-80a7-b1b8aa476520@github.com>
 <3ypc8tpwlD08GbadhJOPw52Xdl82jHSs46kUTWXNAug=.1cc93da1-1db6-45a2-a8f4-9890a6078a53@github.com>
 <MpzmVqcgU5R66UmGBnb_AmcmJvuX9XRxoYlEmvSs6zQ=.34de7d32-844b-40e0-adae-d100444fb605@github.com>
 <mENLk-cgaGsIZ4gki3VJfC4qHzp2D3V3maLt5h5KASg=.6f2e5762-7b6b-49e9-be6d-8811aeed96fe@github.com>
 <Fkts1yURlLD-wbc7mvHBNlhe2AilyyETaJuQ0QS2YEU=.2ad2349c-c774-4058-b3da-7a2cd9ea6f11@github.com>
Message-ID: <w-tjUgh8HRInIH4-YZTZ5NXLCtbK0ibuOIFXnaWA7vQ=.59120460-a540-4c5d-9ec6-2d98f4117232@github.com>

On Fri, 16 Feb 2024 12:50:37 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> * Please assert that the replacement string is smaller than the original string (which it should be, *.so is longer than *.a, but this is insurance against anyone changing the code in the future)

I have done it now. This is just  to make the developer aware that this was the design decision taken ? 
@tstuefe

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1952105754

From mdoerr at openjdk.org  Mon Feb 19 10:19:02 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 19 Feb 2024 10:19:02 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v23]
In-Reply-To: <HN-bL-HmykOa-uJTej8Ud3tC6usQvPywTfUV7XO-t-o=.22f9b270-6d72-4e8c-a90b-97ab6c816888@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <HN-bL-HmykOa-uJTej8Ud3tC6usQvPywTfUV7XO-t-o=.22f9b270-6d72-4e8c-a90b-97ab6c816888@github.com>
Message-ID: <hTD5gOAM4nj6-8zeuTFeW8fcQr2NLO77CnDioFLQXN4=.81239b08-5677-4cca-ba50-c46ceb516ae8@github.com>

On Mon, 19 Feb 2024 10:05:17 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am.
>> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX.
>> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails.
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

src/hotspot/os/aix/os_aix.cpp line 1185:

> 1183:   // Shared object in .so format dont have braces, hence they get removed for archives with members.
> 1184:   if (error_code == EACCES || error_code == ENOENT) {
> 1185:     if (strlen(new_extension) > strlen(old_extension)){

I think this should better be an assertion because the extensions are constants.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1494317702

From duke at openjdk.org  Mon Feb 19 10:40:54 2024
From: duke at openjdk.org (Yude Lin)
Date: Mon, 19 Feb 2024 10:40:54 GMT
Subject: RFR: 8323273: AArch64: Strengthen CompressedClassPointers
 initialization check for base
In-Reply-To: <Unuzwz0YLo2jvmvcYOF3tjDI7Tr4PuoU3vedUfdUrmA=.914474fb-292f-4eeb-a82b-b3a858ab65d0@github.com>
References: <Unuzwz0YLo2jvmvcYOF3tjDI7Tr4PuoU3vedUfdUrmA=.914474fb-292f-4eeb-a82b-b3a858ab65d0@github.com>
Message-ID: <F6E6K2xp_kBa1GNWUgabsF28Cvae05mq9sGDuWjWcNk=.61e6390a-8f2b-4055-88f7-b79477ed124c@github.com>

On Tue, 16 Jan 2024 02:41:40 GMT, Yude Lin <duke at openjdk.org> wrote:

> Summary:
> Add a platform-dependent check for CompressedClassSpaceBaseAddress;
> Remove the "reserve anywhere" attempt after the initial mapping attempt failed---this is rarely used and will likely fail anyway, because the accepted mapping is very restricted on aarch64;
> Additional assertions after initialization.
> 
> Passed hotspot/jtreg/:tier1 on fastdebug

I think the strangest thing to me is if the reservation fails (admittedly very rare if ever), the code choose to fire the error at stub generation. It's rather random---Maybe in another day, when initialization code changes and something that also decodes klass moves ahead of stub generation, the error could happen there. We would need time to associate all the appearances of the error with the root cause of the error. So why not add assertions right after reservation?

You might argue that this nearly never happens in product and not worth the complication. I currently cannot argue with that because I haven't observe one myself, and I will drop the patch. But note that a single assertion would help. Perhaps consider adding one in incoming class-space refactoring?

> .. strange return code contract of eor_compatible_klass_encoding.

It returns the number of bits allowed to encode a klass. So 0 means there is no space left for klass encoding. Thanks for the feedbacks though. I understand the frustration of seeing those platform dependent code in shared code. I'll try not to write anything like that again.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17437#issuecomment-1952166067

From jkern at openjdk.org  Mon Feb 19 10:45:00 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Mon, 19 Feb 2024 10:45:00 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v23]
In-Reply-To: <HN-bL-HmykOa-uJTej8Ud3tC6usQvPywTfUV7XO-t-o=.22f9b270-6d72-4e8c-a90b-97ab6c816888@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <HN-bL-HmykOa-uJTej8Ud3tC6usQvPywTfUV7XO-t-o=.22f9b270-6d72-4e8c-a90b-97ab6c816888@github.com>
Message-ID: <8ZuzOofIzdn0JgMmacWw6hPQ88V9hwHN8pJz8vcdEns=.7daa4550-52de-41b1-beb2-2c002fe2fbce@github.com>

On Mon, 19 Feb 2024 10:05:17 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am.
>> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX.
>> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails.
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

src/hotspot/os/aix/os_aix.cpp line 1181:

> 1179:   // First try to load the existing file.
> 1180:   result = dll_load_library(filename, ebuf, ebuflen);
> 1181:   int error_code = errno;

this might not necessarily be the `errno` of the underlying `dlopen()`, because there is to much code in-between and branches without a `dlopen()` call.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1494354118

From magnus.ihse.bursie at oracle.com  Mon Feb 19 10:55:37 2024
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 19 Feb 2024 11:55:37 +0100
Subject: Hotspot symbol visibility
In-Reply-To: <97081168-46cc-4b9c-9721-add8f8b0c21a@littlepinkcloud.com>
References: <645132e0-687e-4f04-9e49-f90131294367@oracle.com>
 <97081168-46cc-4b9c-9721-add8f8b0c21a@littlepinkcloud.com>
Message-ID: <4ba080b7-d18f-4fe4-91d2-f177542de158@oracle.com>

On 2024-02-18 11:15, Andrew Haley wrote:

> On 2/14/24 10:06, Magnus Ihse Bursie wrote:
>> My takeaway from the discussions is that we are most likely exporting a
>> way too broad set of symbols to SA. It seems likely that this set can be
>> drastically cut down. Actually getting an understanding of exactly which
>> symbols SA need seem like a very good first step.
>>
>> So, is this a journey anyone would be interested in embarkering on? I
>> will help as much as I can from a build PoV, but I have no clue
>> whatsoever about what SA needs.
>
> Alternatively, we have separate debuginfo. SA can use the debug symbols,
> allowing us to strip all others. What's wrong with this reasoning?
>
I don't know if there is anything wrong with that reasoning. It seems 
reasonable. I also hope that we won't need to take the detour of first 
generating the symbols and then strip them, but instead can add them 
directly to the debuginfo, if we should choose to do things this way.

Can anyone from serviceability chip in? Would it be okay for SA to 
require a .debuginfo or .diz file to be able to extract all the internal 
hotspot symbols?

/Magnus


From sroy at openjdk.org  Mon Feb 19 11:15:59 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 19 Feb 2024 11:15:59 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v23]
In-Reply-To: <8ZuzOofIzdn0JgMmacWw6hPQ88V9hwHN8pJz8vcdEns=.7daa4550-52de-41b1-beb2-2c002fe2fbce@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <HN-bL-HmykOa-uJTej8Ud3tC6usQvPywTfUV7XO-t-o=.22f9b270-6d72-4e8c-a90b-97ab6c816888@github.com>
 <8ZuzOofIzdn0JgMmacWw6hPQ88V9hwHN8pJz8vcdEns=.7daa4550-52de-41b1-beb2-2c002fe2fbce@github.com>
Message-ID: <iQ_9KV1Pl5s2AYFfYaF4oVuHE7d5SeNtk1coVwHadhk=.f7568310-f8f7-46ce-9e81-d5537531f3bb@github.com>

On Mon, 19 Feb 2024 10:42:03 GMT, Joachim Kern <jkern at openjdk.org> wrote:

> this might not necessarily be the `errno` of the underlying `dlopen()`, because there is to much code in-between and branches without a `dlopen()` call.

As i see the code in Aix_dlopen , there is no additional functional call after the dlopen which might change the errno . Could you tell me the how the errno would get overriden ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1494389934

From sroy at openjdk.org  Mon Feb 19 11:16:00 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 19 Feb 2024 11:16:00 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v23]
In-Reply-To: <hTD5gOAM4nj6-8zeuTFeW8fcQr2NLO77CnDioFLQXN4=.81239b08-5677-4cca-ba50-c46ceb516ae8@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <HN-bL-HmykOa-uJTej8Ud3tC6usQvPywTfUV7XO-t-o=.22f9b270-6d72-4e8c-a90b-97ab6c816888@github.com>
 <hTD5gOAM4nj6-8zeuTFeW8fcQr2NLO77CnDioFLQXN4=.81239b08-5677-4cca-ba50-c46ceb516ae8@github.com>
Message-ID: <dgKer4-2a75tuzWVBzxiJDq1Zl39c3pONlnxd-Nek2U=.f3ba660e-6714-4fec-9fe8-020199512825@github.com>

On Mon, 19 Feb 2024 10:15:59 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> src/hotspot/os/aix/os_aix.cpp line 1185:
> 
>> 1183:   // Shared object in .so format dont have braces, hence they get removed for archives with members.
>> 1184:   if (error_code == EACCES || error_code == ENOENT) {
>> 1185:     if (strlen(new_extension) > strlen(old_extension)){
> 
> I think this should better be an assertion because the extensions are constants.

As assertions are not supported in debug builds i did not use assert. May i know what is the purpose of assert,in general, as per design ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1494392043

From jkern at openjdk.org  Mon Feb 19 12:18:04 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Mon, 19 Feb 2024 12:18:04 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v23]
In-Reply-To: <iQ_9KV1Pl5s2AYFfYaF4oVuHE7d5SeNtk1coVwHadhk=.f7568310-f8f7-46ce-9e81-d5537531f3bb@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <HN-bL-HmykOa-uJTej8Ud3tC6usQvPywTfUV7XO-t-o=.22f9b270-6d72-4e8c-a90b-97ab6c816888@github.com>
 <8ZuzOofIzdn0JgMmacWw6hPQ88V9hwHN8pJz8vcdEns=.7daa4550-52de-41b1-beb2-2c002fe2fbce@github.com>
 <iQ_9KV1Pl5s2AYFfYaF4oVuHE7d5SeNtk1coVwHadhk=.f7568310-f8f7-46ce-9e81-d5537531f3bb@github.com>
Message-ID: <GXrQtKf5matzjc0POsR8QwJRc8UWI3U8SIN7-3a7iWU=.27b87d30-e424-4346-a740-37ca4b45a452@github.com>

On Mon, 19 Feb 2024 11:11:23 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> src/hotspot/os/aix/os_aix.cpp line 1181:
>> 
>>> 1179:   // First try to load the existing file.
>>> 1180:   result = dll_load_library(filename, ebuf, ebuflen);
>>> 1181:   int error_code = errno;
>> 
>> this might not necessarily be the `errno` of the underlying `dlopen()`, because there is to much code in-between and branches without a `dlopen()` call.
>
>> this might not necessarily be the `errno` of the underlying `dlopen()`, because there is to much code in-between and branches without a `dlopen()` call.
> 
> As i see the code in Aix_dlopen , there is no additional functional call after the dlopen which might change the errno . Could you tell me the how the errno would get overriden ?

Suchi, errno is a global static variable. If some runtime API sets it, it will continue to have this value until the next runtime call updates it. If you call dll_load_library, there are many execution paths not passing dlopen(). So you receive an errno from some unknown runtime API called before. The correct errno handling is:

errno = 0;
runtime_API_which_might_set_errno_in_error_case();
error_code = errno;

But what you really need is the result of the `search_file_in_LIBPATH(...)` call in `Aix_dlopen()`. If it is false, then the error_report starts with the string "Could not load module . ....."
This is called in any case. A `dlopen()` is not called in any case.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1494459722

From egahlin at openjdk.org  Mon Feb 19 12:22:56 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 19 Feb 2024 12:22:56 GMT
Subject: RFR: JDK-8325116: Amend jdk.ContainerConfiguration by swap related
 value
In-Reply-To: <0UFSBwJVq31ZaVhhm7ssaR5jNa2AALYUgHtBWIQxi9Y=.b3e42160-9d6f-4e99-83ee-7f08f85d04c1@github.com>
References: <0UFSBwJVq31ZaVhhm7ssaR5jNa2AALYUgHtBWIQxi9Y=.b3e42160-9d6f-4e99-83ee-7f08f85d04c1@github.com>
Message-ID: <vdOMQlvbsicechhdzJKWQfMa-v0xBnl3sh14dkJpQRg=.f2a866de-5f4a-467e-9b8f-190d72af9cc5@github.com>

On Thu, 15 Feb 2024 08:26:40 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> jdk.ContainerInformation event could get amended to report the host total swap values for Linux like was done in
> https://bugs.openjdk.org/browse/JDK-8296671 by host total memory.
> Two additional fields could be added hostSwapTotal, maybe hostSwapFree;
> container free swap space in case we find a good implementation, could also be added to the implementation in os_linux.

Marked as reviewed by egahlin (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17865#pullrequestreview-1888284279

From egahlin at openjdk.org  Mon Feb 19 12:26:53 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 19 Feb 2024 12:26:53 GMT
Subject: RFR: JDK-8325116: Amend jdk.ContainerConfiguration by swap related
 value
In-Reply-To: <0UFSBwJVq31ZaVhhm7ssaR5jNa2AALYUgHtBWIQxi9Y=.b3e42160-9d6f-4e99-83ee-7f08f85d04c1@github.com>
References: <0UFSBwJVq31ZaVhhm7ssaR5jNa2AALYUgHtBWIQxi9Y=.b3e42160-9d6f-4e99-83ee-7f08f85d04c1@github.com>
Message-ID: <LItShuGtl8wUDh23HDx3S1Yk-mrc6y0lwhyTPHCD54Y=.57d7dc77-4ffc-4a5c-9aad-2981c212f4a2@github.com>

On Thu, 15 Feb 2024 08:26:40 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> jdk.ContainerInformation event could get amended to report the host total swap values for Linux like was done in
> https://bugs.openjdk.org/browse/JDK-8296671 by host total memory.
> Two additional fields could be added hostSwapTotal, maybe hostSwapFree;
> container free swap space in case we find a good implementation, could also be added to the implementation in os_linux.

Marked as reviewed by egahlin (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17865#pullrequestreview-1888291533

From egahlin at openjdk.org  Mon Feb 19 12:27:53 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 19 Feb 2024 12:27:53 GMT
Subject: RFR: 8326111: JFR: Cleanup for JFR_ONLY [v2]
In-Reply-To: <JkreW92RpA8VDWs1id6RrXd5sV2TZsLKvp36NepmE3s=.23102365-e003-4b3d-948e-8d4579668422@github.com>
References: <ejPq_N_6Trx4KaqeRZwBulHr-ndZb7MJqbZbHTO8MqM=.cc3d7239-9c2f-4556-939d-7fb72378a551@github.com>
 <JkreW92RpA8VDWs1id6RrXd5sV2TZsLKvp36NepmE3s=.23102365-e003-4b3d-948e-8d4579668422@github.com>
Message-ID: <rzIU900CJWh_QiJ5wKLEGJ81a_A8h7ug5zt9XJU1R-U=.2569bed0-ac86-46b6-9141-f4203512f547@github.com>

On Sun, 18 Feb 2024 08:10:16 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> Greetings,
>> 
>> Could I have a review of this trivial change that cleans up code where used JFR_ONLY incorrectly?
>> 
>> testing: build with --enable-jvm-feature-jfr and --disable-jvm-feature-jfr
>> 
>> Denghui
>
> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more cleanup

Marked as reviewed by egahlin (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17903#pullrequestreview-1888292545

From stuefe at openjdk.org  Mon Feb 19 12:40:53 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 19 Feb 2024 12:40:53 GMT
Subject: RFR: 8323273: AArch64: Strengthen CompressedClassPointers
 initialization check for base
In-Reply-To: <F6E6K2xp_kBa1GNWUgabsF28Cvae05mq9sGDuWjWcNk=.61e6390a-8f2b-4055-88f7-b79477ed124c@github.com>
References: <Unuzwz0YLo2jvmvcYOF3tjDI7Tr4PuoU3vedUfdUrmA=.914474fb-292f-4eeb-a82b-b3a858ab65d0@github.com>
 <F6E6K2xp_kBa1GNWUgabsF28Cvae05mq9sGDuWjWcNk=.61e6390a-8f2b-4055-88f7-b79477ed124c@github.com>
Message-ID: <Cr47St00ieCbl3-K1nWIhx_z0PmphnxiT2-oSySqxIk=.2408e774-0397-4c01-a7cb-3127740500b8@github.com>

On Mon, 19 Feb 2024 10:38:31 GMT, Yude Lin <duke at openjdk.org> wrote:

> I think the strangest thing to me is if the reservation fails (admittedly very rare if ever), the code choose to fire the error at stub generation. It's rather random---Maybe in another day, when initialization code changes and something that also decodes klass moves ahead of stub generation, the error could happen there. We would need time to associate all the appearances of the error with the root cause of the error.

Okay, you convinced me. I'm still against changes to CompressedClassSpaceBaseAddress and the removal of reserve-anywhere patch, though.

> So why not add assertions right after reservation?

Yes, without code duplication.

1) The most straightforward and least invasive possibility would be to improve the assertion messages and/or add comments in `MacroAssembler::klass_decode_mode()`.

2) The next simple possibility would be to reuse `MacroAssembler::klass_decode_mode()` as part of verification after initialization.

> 
> You might argue that this nearly never happens in product and not worth the complication. I currently cannot argue with that because I haven't observe one myself, and I will drop the patch. But note that a single assertion would help. Perhaps consider adding one in incoming class-space refactoring?

A single assertion means I still need a way to know when it fires, so its condition needs to guess at the decoding logic that is hidden in MacroAssembler. I don't like that duplication.

> 
> > .. strange return code contract of eor_compatible_klass_encoding.
> 
> It returns the number of bits allowed to encode a klass. So 0 means there is no space left for klass encoding. Thanks for the feedbacks though. I understand the frustration of seeing those platform dependent code in shared code. I'll try not to write anything like that again.

Sorry for your frustration.

You get strong pushback here because this code, in particular, has been seeing platform ifdefs blooming like mushrooms over the years - it had often been easier to add one extra block than to look at the base structure. Which made the code complex and brittle over the years. We restructured this coding recently with https://bugs.openjdk.org/browse/JDK-8312018, and I would like to keep it somewhat clean and readable.

This coding is also rather tricky because it lives at the interjunction of three VM subsystems: metaspace/class space, JIT compiler (with its various CPU-specific idiosyncrasies) and CDS.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17437#issuecomment-1952365534

From mbaesken at openjdk.org  Mon Feb 19 12:54:58 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 19 Feb 2024 12:54:58 GMT
Subject: Integrated: JDK-8325116: Amend jdk.ContainerConfiguration by swap
 related value
In-Reply-To: <0UFSBwJVq31ZaVhhm7ssaR5jNa2AALYUgHtBWIQxi9Y=.b3e42160-9d6f-4e99-83ee-7f08f85d04c1@github.com>
References: <0UFSBwJVq31ZaVhhm7ssaR5jNa2AALYUgHtBWIQxi9Y=.b3e42160-9d6f-4e99-83ee-7f08f85d04c1@github.com>
Message-ID: <h0U4AqcojkH27BXelaEpptoCR9vsZ4Qo3NVJSbKiRhE=.ad910612-47c7-40f3-8d82-62e38a78cdc9@github.com>

On Thu, 15 Feb 2024 08:26:40 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> jdk.ContainerInformation event could get amended to report the host total swap values for Linux like was done in
> https://bugs.openjdk.org/browse/JDK-8296671 by host total memory.
> Two additional fields could be added hostSwapTotal, maybe hostSwapFree;
> container free swap space in case we find a good implementation, could also be added to the implementation in os_linux.

This pull request has now been integrated.

Changeset: dc17c268
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dc17c268e8e73a36a9914924ee5d0c99fb998f0f
Stats:     28 lines in 7 files changed: 25 ins; 0 del; 3 mod

8325116: Amend jdk.ContainerConfiguration by swap related value

Reviewed-by: sgehwolf, lucy, egahlin

-------------

PR: https://git.openjdk.org/jdk/pull/17865

From mbaesken at openjdk.org  Mon Feb 19 12:54:58 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 19 Feb 2024 12:54:58 GMT
Subject: RFR: JDK-8325116: Amend jdk.ContainerConfiguration by swap related
 value
In-Reply-To: <0UFSBwJVq31ZaVhhm7ssaR5jNa2AALYUgHtBWIQxi9Y=.b3e42160-9d6f-4e99-83ee-7f08f85d04c1@github.com>
References: <0UFSBwJVq31ZaVhhm7ssaR5jNa2AALYUgHtBWIQxi9Y=.b3e42160-9d6f-4e99-83ee-7f08f85d04c1@github.com>
Message-ID: <jkBiWpZgjrpnoFhmC4_lYmOD0Cu1ROMwcBKlOOHLJlI=.3eb97e1c-fb2c-4ed2-acbd-e07ec76447f4@github.com>

On Thu, 15 Feb 2024 08:26:40 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> jdk.ContainerInformation event could get amended to report the host total swap values for Linux like was done in
> https://bugs.openjdk.org/browse/JDK-8296671 by host total memory.
> Two additional fields could be added hostSwapTotal, maybe hostSwapFree;
> container free swap space in case we find a good implementation, could also be added to the implementation in os_linux.

Hi Erik, Lutz and Severin thanks for the reviews !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17865#issuecomment-1952386901

From sroy at openjdk.org  Mon Feb 19 13:02:59 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 19 Feb 2024 13:02:59 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v23]
In-Reply-To: <GXrQtKf5matzjc0POsR8QwJRc8UWI3U8SIN7-3a7iWU=.27b87d30-e424-4346-a740-37ca4b45a452@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <HN-bL-HmykOa-uJTej8Ud3tC6usQvPywTfUV7XO-t-o=.22f9b270-6d72-4e8c-a90b-97ab6c816888@github.com>
 <8ZuzOofIzdn0JgMmacWw6hPQ88V9hwHN8pJz8vcdEns=.7daa4550-52de-41b1-beb2-2c002fe2fbce@github.com>
 <iQ_9KV1Pl5s2AYFfYaF4oVuHE7d5SeNtk1coVwHadhk=.f7568310-f8f7-46ce-9e81-d5537531f3bb@github.com>
 <GXrQtKf5matzjc0POsR8QwJRc8UWI3U8SIN7-3a7iWU=.27b87d30-e424-4346-a740-37ca4b45a452@github.com>
Message-ID: <5A8gF2IxapOCnUg2bDQVcitnGgGXKAcul7danUNE2q4=.54b7ffb2-4ba0-47e8-8d8b-c986fac4e9c8@github.com>

On Mon, 19 Feb 2024 12:15:22 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>>> this might not necessarily be the `errno` of the underlying `dlopen()`, because there is to much code in-between and branches without a `dlopen()` call.
>> 
>> As i see the code in Aix_dlopen , there is no additional functional call after the dlopen which might change the errno . Could you tell me the how the errno would get overriden ?
>
> Suchi, errno is a global static variable. If some runtime API sets it, it will continue to have this value until the next runtime call updates it. If you call dll_load_library, there are many execution paths not passing dlopen(). So you receive an errno from some unknown runtime API called before. The correct errno handling is:
> 
> errno = 0;
> runtime_API_which_might_set_errno_in_error_case();
> error_code = errno;
> 
> But what you really need is the result of the `search_file_in_LIBPATH(...)` call in `Aix_dlopen()`. If it is false, then the error_report starts with the string "Could not load module . ....."
> This is called in any case. A `dlopen()` is not called in any case.

Thanks for the detailed explanation @JoKern65 . Do then in this errno check may not be necessary ? or can we still set errno and access it some way ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1494516185

From sspitsyn at openjdk.org  Mon Feb 19 13:13:25 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 19 Feb 2024 13:13:25 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v11]
In-Reply-To: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
Message-ID: <gckxe19ySYKH24T2U27nKp-IslqlzIV3Ti9SZJxB_Rw=.ae0f7144-cc3a-410c-9445-a4c0cecf980e@github.com>

> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
> The function returns the following structure:
> 
> 
> typedef struct {
>     jthread owner;
>     jint entry_count;
>     jint waiter_count;
>     jthread* waiters;
>     jint notify_waiter_count;
>     jthread* notify_waiters;
> } jvmtiMonitorUsage;
> 
> 
> The following four fields are defined this way:
> 
> waiter_count  [jint] The number of threads waiting to own this monitor
> waiters  [jthread*] The waiter_count waiting threads
> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
> 
> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
> This update makes it right.
> 
> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
> 
> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
> 
>   jvmti/GetObjectMonitorUsage/objmonusage001
>   jvmti/GetObjectMonitorUsage/objmonusage003
> 
> 
> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
> 
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
> 
> 
> 
> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository.
> 
> Also, please see and review the related CSR:
>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
> 
> The Release-Note is:
> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage
>  
> Testing:
>  - tested with mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  fixed minimal build issue

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17680/files
  - new: https://git.openjdk.org/jdk/pull/17680/files/04da0cf8..63706e51

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=09-10

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17680.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17680/head:pull/17680

PR: https://git.openjdk.org/jdk/pull/17680

From jkern at openjdk.org  Mon Feb 19 13:27:59 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Mon, 19 Feb 2024 13:27:59 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v23]
In-Reply-To: <5A8gF2IxapOCnUg2bDQVcitnGgGXKAcul7danUNE2q4=.54b7ffb2-4ba0-47e8-8d8b-c986fac4e9c8@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <HN-bL-HmykOa-uJTej8Ud3tC6usQvPywTfUV7XO-t-o=.22f9b270-6d72-4e8c-a90b-97ab6c816888@github.com>
 <8ZuzOofIzdn0JgMmacWw6hPQ88V9hwHN8pJz8vcdEns=.7daa4550-52de-41b1-beb2-2c002fe2fbce@github.com>
 <iQ_9KV1Pl5s2AYFfYaF4oVuHE7d5SeNtk1coVwHadhk=.f7568310-f8f7-46ce-9e81-d5537531f3bb@github.com>
 <GXrQtKf5matzjc0POsR8QwJRc8UWI3U8SIN7-3a7iWU=.27b87d30-e424-4346-a740-37ca4b45a452@github.com>
 <5A8gF2IxapOCnUg2bDQVcitnGgGXKAcul7danUNE2q4=.54b7ffb2-4ba0-47e8-8d8b-c986fac4e9c8@github.com>
Message-ID: <o21d_Bs2QT2-_SO9K7MoROvMs0mgpjLqX_8caNKxv1E=.a42210fd-b70d-412e-9e89-821242078895@github.com>

On Mon, 19 Feb 2024 13:00:01 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> Suchi, errno is a global static variable. If some runtime API sets it, it will continue to have this value until the next runtime call updates it. If you call dll_load_library, there are many execution paths not passing dlopen(). So you receive an errno from some unknown runtime API called before. The correct errno handling is:
>> 
>> errno = 0;
>> runtime_API_which_might_set_errno_in_error_case();
>> error_code = errno;
>> 
>> But what you really need is the result of the `search_file_in_LIBPATH(...)` call in `Aix_dlopen()`. If it is false, then the error_report starts with the string "Could not load module . ....."
>> This is called in any case. A `dlopen()` is not called in any case.
>
> Thanks for the detailed explanation @JoKern65 . Do then in this errno check may not be necessary ? or can we still set errno and access it some way ?

In this special case here I would not use errno, but the string returned in ebuf, in case the result is nullptr.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1494546476

From sspitsyn at openjdk.org  Mon Feb 19 13:28:56 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 19 Feb 2024 13:28:56 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v9]
In-Reply-To: <zXOCQjxNT2WFopPpZYPqHrBqfm_uN12dAq0eBAa4CBg=.40c685be-e304-421c-b5cc-9c92f639ff89@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <FstoRCjpy6-9WOSrll3-SD9ChAsZ8KZ19LiEZEHmqvc=.d58aeafc-ddb4-4bc3-bb47-cc3471259cb5@github.com>
 <zXOCQjxNT2WFopPpZYPqHrBqfm_uN12dAq0eBAa4CBg=.40c685be-e304-421c-b5cc-9c92f639ff89@github.com>
Message-ID: <hDf9XntiHdnfzxE0keJ7TrhygqQBONe0W9iz6OrzJsU=.a73b238c-36e0-4217-9b35-8b59aaa74d72@github.com>

On Fri, 16 Feb 2024 06:01:19 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: JDWP monitor_info spec clarification; removed debugging code from objmonusage001
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1496:
> 
>> 1494:   nWant = wantList->length();
>> 1495: 
>> 1496:   if (mon != nullptr) {
> 
> Shouldn't the call to `get_pending_threads` only happen if `mon != nullptr`? Otherwise the `wantList` has to be empty.

Good catch. I've moved it under the `if (mon != nullptr) {` condition.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1494547012

From sspitsyn at openjdk.org  Mon Feb 19 13:35:58 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 19 Feb 2024 13:35:58 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v9]
In-Reply-To: <zXOCQjxNT2WFopPpZYPqHrBqfm_uN12dAq0eBAa4CBg=.40c685be-e304-421c-b5cc-9c92f639ff89@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <FstoRCjpy6-9WOSrll3-SD9ChAsZ8KZ19LiEZEHmqvc=.d58aeafc-ddb4-4bc3-bb47-cc3471259cb5@github.com>
 <zXOCQjxNT2WFopPpZYPqHrBqfm_uN12dAq0eBAa4CBg=.40c685be-e304-421c-b5cc-9c92f639ff89@github.com>
Message-ID: <WtLo2mg7MKE93uNp3pVgH2IA1ktDzYL4ubOnQlilrqs=.db9f2376-9e60-4e6d-9f91-0867f6d2f1f0@github.com>

On Fri, 16 Feb 2024 06:09:40 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: JDWP monitor_info spec clarification; removed debugging code from objmonusage001
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1500:
> 
>> 1498:     for (int i = 0; i < nWait; i++) {
>> 1499:       if (waiter == nullptr || (i != 0 && waiter == mon->first_waiter())) {
>> 1500:         // robustness: the waiting list has gotten smaller
> 
> We are at a safepoint so I don't see how the wait list can shrink. I initially thought perhaps a waiter could timeout, but the code that does the timed park is wrapped in ` ThreadBlockInVMPreprocess` which will block at a safepoint if one is active.

Thank you for the question.
The `nWait` count we got from the `mon->waiters()` can include the threads that are re-entering the monitor after being notified. Here we are correcting the actual number of the waiting threads by excluding those re-entering the monitor. The comment need an update to explain it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1494556207

From stuefe at openjdk.org  Mon Feb 19 13:59:02 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 19 Feb 2024 13:59:02 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v23]
In-Reply-To: <o21d_Bs2QT2-_SO9K7MoROvMs0mgpjLqX_8caNKxv1E=.a42210fd-b70d-412e-9e89-821242078895@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <HN-bL-HmykOa-uJTej8Ud3tC6usQvPywTfUV7XO-t-o=.22f9b270-6d72-4e8c-a90b-97ab6c816888@github.com>
 <8ZuzOofIzdn0JgMmacWw6hPQ88V9hwHN8pJz8vcdEns=.7daa4550-52de-41b1-beb2-2c002fe2fbce@github.com>
 <iQ_9KV1Pl5s2AYFfYaF4oVuHE7d5SeNtk1coVwHadhk=.f7568310-f8f7-46ce-9e81-d5537531f3bb@github.com>
 <GXrQtKf5matzjc0POsR8QwJRc8UWI3U8SIN7-3a7iWU=.27b87d30-e424-4346-a740-37ca4b45a452@github.com>
 <5A8gF2IxapOCnUg2bDQVcitnGgGXKAcul7danUNE2q4=.54b7ffb2-4ba0-47e8-8d8b-c986fac4e9c8@github.com>
 <o21d_Bs2QT2-_SO9K7MoROvMs0mgpjLqX_8caNKxv1E=.a42210fd-b70d-412e-9e89-821242078895@github.com>
Message-ID: <75Cr_jXGHaVJVyHADMj5BNn1x12D56RtAprZ1AY3Q6E=.91bc8cc3-0f91-48b6-9509-7727cc6f8c81@github.com>

On Mon, 19 Feb 2024 13:25:28 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> Thanks for the detailed explanation @JoKern65 . Do then in this errno check may not be necessary ? or can we still set errno and access it some way ?
>
> In this special case here I would not use errno, but the string returned in ebuf, in case the result is nullptr.

Argh, I keep forgetting `dlopen` does not set errno (at least its not guaranteed by the standard).

Ok, in this case, I would not analyze the string either because it may be locale-dependent.

Never mind then; I'd thought this would be easy. One could probably use load() instead of dlopen() on AIX, but that change would require more investigations to see if load() and dlopen() are equivalent.

Okay, in that case just skip the errno test and call the second dlopen directly. Lets hope for the best then.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1494586044

From magnus.ihse.bursie at oracle.com  Mon Feb 19 14:25:06 2024
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 19 Feb 2024 15:25:06 +0100
Subject: Hotspot symbol visibility - surprising news!
In-Reply-To: <645132e0-687e-4f04-9e49-f90131294367@oracle.com>
References: <645132e0-687e-4f04-9e49-f90131294367@oracle.com>
Message-ID: <ba822e64-2a9c-447f-b545-b7fda01c47ef@oracle.com>

On 2024-02-14 11:06, Magnus Ihse Bursie wrote:

> I am currently pursuing improved build functionality for static 
> libraries. One of the issues with static libraries are name 
> collisions, which led me back to an old discussion about which symbols 
> are exported from Hotspot, and how this is achieved. A long discussion 
> is available in JDK-8017234 [1], which was created in 2013 and has 
> been on the back burner ever since, coming back to life every now and 
> then.
>
> There are basically two different problems here. They are both 
> distinct and interrelated, and we likely need to solve both in tandem.
>
> The first problem is how Hotspot should say which symbols (functions) 
> that should be exported from libjvm.so. The historical, and still 
> used, system is to have a mapfile. In the "new" (not so new anymore) 
> build system, this was simplified to a list of function names in 
> make/data/hotspot-symbols, from which a mapfile is built.
>
> This is in contrast with how all other libraries in the JDK are built, 
> and also with modern best practices. A better approach would be to 
> annotate the functions that should be exported in the source code. In 
> fact, such annotation already exists, even in Hotspot, as JNIEXPORT, 
> but this is currently not used in the compilation of Hotspot.
>
> The second problem is that in addition to these explicitly exported 
> functions, we also export basically all other functions as well in 
> Hotspot. (So currently we could basically just forgo this complicated 
> machinery and just export everything by default...)
>
> The reason for this seem somewhat unclear. The specifics are probably 
> forever lost in the mists of time past, but the essential point is 
> that these symbols are needed for SA to do it's job.
>
> So what we do is that we list all symbols in hotspot after compiling 
> (but before linking), and selects some (most, I think) of them using 
> regexp patterns, and add these to the mapfile.

Actually, we are not doing what I thought we're doing, and what I assume 
whoever wrote the original code thought we were doing. Seems no-one has 
ever bothered to check the effect of this massive generated mapfile. :-/ 
At least not on linux/gcc (which is the only platform I've looked at so 
far).

It turns out that the gcc linker never removes the "hidden" visibility 
from symbols. Even if you list them in a mapfile under "global:", if 
they were compiled with visibility "hidden", they will still be hidden. 
The only thing you can ever hope to achieve with a mapfile is to make 
symbols with "default" visibility be "hidden", by placing them under the 
"local:" header. In hotspot, only functions marked JNIEXPORT have the 
"default" visibility.

The upshot of all this is that the mapfile has very little impact on the 
resulting symbols in Hotspot, and a lot of the difference it makes seems 
to be incorrect. :-/

In other words, all the mapfile can ever do is hide stuff that would 
otherwise have been visible. So what symbols are then made hidden by the 
mapfile? In effect, symbols that are marked JNIEXPORT but are not listed 
in make/data/hotspot-symbols, and symbols that arise from outside 
hotspot source code. I have divided these symbols into four categories:

1) All symbols from debug.cpp that are marked JNIEXPORT (most of them).

2) All symbols from jvmciCompilerToVM.cpp and that are marked JNIEXPORT 
(most of them), and data from vmStructs_jvmci.cpp that are marked JNIEXPORT.

3) Assembly functions such as _Copy_arrayof_conjoint_bytes that are 
marked .globl

4) Symbols not present in hotspot source code, but which originates with 
the compiler or standard libraries, e.g. __bss_start, __cxa_begin_catch, 
_ZTIN10__cxxabiv117__class_type_infoE, 
_ZTSN9__gnu_cxx20recursive_init_errorE, etc.

My interpretation of this is:

a) It is actually an error not to export functions marked JNIEXPORT, so 
1 and 2 are actually more correct this way.

b) The assembly functions are incorrectly marked .globl. This should 
just be removed.

c) As for the symbols from compiler and standard libraries; I don't 
know. I assume these are exported by default by normal libs, so it 
should probably be fine to do the same with Hotspot. Possibly there are 
other ways to make these local, if we really want that (linker flags, or 
something like that?).

The most important observation, however, is that generating a long list 
of symbols from the object file to make them "available" to SA seems to 
be a complete misunderstanding of what is happening. No hidden symbols 
can ever be made visible in this manner.

/Magnus



From kevin.walls at oracle.com  Mon Feb 19 15:04:15 2024
From: kevin.walls at oracle.com (Kevin Walls)
Date: Mon, 19 Feb 2024 15:04:15 +0000
Subject: Hotspot symbol visibility
In-Reply-To: <4ba080b7-d18f-4fe4-91d2-f177542de158@oracle.com>
References: <645132e0-687e-4f04-9e49-f90131294367@oracle.com>
 <97081168-46cc-4b9c-9721-add8f8b0c21a@littlepinkcloud.com>
 <4ba080b7-d18f-4fe4-91d2-f177542de158@oracle.com>
Message-ID: <SN7PR10MB703200B9705FF49DB3DAE07497512@SN7PR10MB7032.namprd10.prod.outlook.com>

Hi -

I've observed it being problematic for customers have access to .debuginfo files, either to acquire the .debuginfo bundles or to get them in the relevant place/machine.  This has I'm sure been a sticking point for support many times.  It would be great to avoid that.

The SA needs the gHotSpotVM.... symbols, and the vtable symbols.  The symbols need to be in the binary, but not necessarily findable by "dlsym", as it does ELF symbol lookup work itself (notes in JDK-8017234).

We would need to test if there are SA failures if these symbols are not exported?...
(There are some issues mentioned in JDK-8017234, maybe they are still true.)



-----Original Message-----
From: serviceability-dev <serviceability-dev-retn at openjdk.org> On Behalf Of Magnus Ihse Bursie
Sent: 19 February 2024 10:56
To: Andrew Haley <aph-open at littlepinkcloud.com>; hotspot-dev at openjdk.org; serviceability-dev at openjdk.java.net
Subject: Re: Hotspot symbol visibility
Importance: High

On 2024-02-18 11:15, Andrew Haley wrote:

> On 2/14/24 10:06, Magnus Ihse Bursie wrote:
>> My takeaway from the discussions is that we are most likely exporting 
>> a way too broad set of symbols to SA. It seems likely that this set 
>> can be drastically cut down. Actually getting an understanding of 
>> exactly which symbols SA need seem like a very good first step.
>>
>> So, is this a journey anyone would be interested in embarkering on? I 
>> will help as much as I can from a build PoV, but I have no clue 
>> whatsoever about what SA needs.
>
> Alternatively, we have separate debuginfo. SA can use the debug 
> symbols, allowing us to strip all others. What's wrong with this reasoning?
>
I don't know if there is anything wrong with that reasoning. It seems reasonable. I also hope that we won't need to take the detour of first generating the symbols and then strip them, but instead can add them directly to the debuginfo, if we should choose to do things this way.

Can anyone from serviceability chip in? Would it be okay for SA to require a .debuginfo or .diz file to be able to extract all the internal hotspot symbols?

/Magnus


From sspitsyn at openjdk.org  Mon Feb 19 15:33:23 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 19 Feb 2024 15:33:23 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v12]
In-Reply-To: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
Message-ID: <P_SGQw9YGQvIDVikpCoUCZLSoumOSxbSwGJspCEb5pI=.e2cf601a-e89c-4e50-9d69-20ef18ff49e5@github.com>

> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
> The function returns the following structure:
> 
> 
> typedef struct {
>     jthread owner;
>     jint entry_count;
>     jint waiter_count;
>     jthread* waiters;
>     jint notify_waiter_count;
>     jthread* notify_waiters;
> } jvmtiMonitorUsage;
> 
> 
> The following four fields are defined this way:
> 
> waiter_count  [jint] The number of threads waiting to own this monitor
> waiters  [jthread*] The waiter_count waiting threads
> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
> 
> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
> This update makes it right.
> 
> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
> 
> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
> 
>   jvmti/GetObjectMonitorUsage/objmonusage001
>   jvmti/GetObjectMonitorUsage/objmonusage003
> 
> 
> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
> 
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
> 
> 
> 
> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository.
> 
> Also, please see and review the related CSR:
>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
> 
> The Release-Note is:
> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage
>  
> Testing:
>  - tested with mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: addressed comments from David

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17680/files
  - new: https://git.openjdk.org/jdk/pull/17680/files/63706e51..81b7787b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=10-11

  Stats: 12 lines in 1 file changed: 8 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17680.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17680/head:pull/17680

PR: https://git.openjdk.org/jdk/pull/17680

From ihse at openjdk.org  Mon Feb 19 16:16:00 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 19 Feb 2024 16:16:00 GMT
Subject: Integrated: 8325950: Make sure all files in the JDK pass jcheck
In-Reply-To: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
Message-ID: <8lQWgT0JhzAP5uuraMs8UjJXJcyTacHziySbnLN9XaQ=.16d4233d-1815-4cf8-8761-368fe425a131@github.com>

On Thu, 15 Feb 2024 12:19:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes).
> 
> I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base.

This pull request has now been integrated.

Changeset: 5c5a282f
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5c5a282f91dd28b306673ca2bcc30dec451e7a7d
Stats:     113 lines in 38 files changed: 0 ins; 10 del; 103 mod

8325950: Make sure all files in the JDK pass jcheck

Reviewed-by: prr, wetmore, erikj, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/17871

From sroy at openjdk.org  Mon Feb 19 17:16:34 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 19 Feb 2024 17:16:34 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v24]
In-Reply-To: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
Message-ID: <qwMbSmLF3tOFVkLkjtao2dwOR0KUBdUuhhjntYzDOPE=.d5b8dfc4-c476-44f3-81d2-e45b73cbad02@github.com>

> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am.
> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX.
> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails.

Suchismith Roy has updated the pull request incrementally with two additional commits since the last revision:

 - remove error_code
 - revert error code check

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16604/files
  - new: https://git.openjdk.org/jdk/pull/16604/files/f5693f47..c6b3deb3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=22-23

  Stats: 7 lines in 1 file changed: 0 ins; 5 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16604.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604

PR: https://git.openjdk.org/jdk/pull/16604

From sroy at openjdk.org  Mon Feb 19 17:20:02 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 19 Feb 2024 17:20:02 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v23]
In-Reply-To: <75Cr_jXGHaVJVyHADMj5BNn1x12D56RtAprZ1AY3Q6E=.91bc8cc3-0f91-48b6-9509-7727cc6f8c81@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <HN-bL-HmykOa-uJTej8Ud3tC6usQvPywTfUV7XO-t-o=.22f9b270-6d72-4e8c-a90b-97ab6c816888@github.com>
 <8ZuzOofIzdn0JgMmacWw6hPQ88V9hwHN8pJz8vcdEns=.7daa4550-52de-41b1-beb2-2c002fe2fbce@github.com>
 <iQ_9KV1Pl5s2AYFfYaF4oVuHE7d5SeNtk1coVwHadhk=.f7568310-f8f7-46ce-9e81-d5537531f3bb@github.com>
 <GXrQtKf5matzjc0POsR8QwJRc8UWI3U8SIN7-3a7iWU=.27b87d30-e424-4346-a740-37ca4b45a452@github.com>
 <5A8gF2IxapOCnUg2bDQVcitnGgGXKAcul7danUNE2q4=.54b7ffb2-4ba0-47e8-8d8b-c986fac4e9c8@github.com>
 <o21d_Bs2QT2-_SO9K7MoROvMs0mgpjLqX_8caNKxv1E=.a42210fd-b70d-412e-9e89-821242078895@github.com>
 <75Cr_jXGHaVJVyHADMj5BNn1x12D56RtAprZ1AY3Q6E=.91bc8cc3-0f91-48b6-9509-7727cc6f8c81@github.com>
Message-ID: <gs0K1PQTfFy6Ivl4NyRx8KynPBBrqEXSJLxf64Bc87w=.08d770f8-44f1-41bb-b232-ff6ec6b14ebf@github.com>

On Mon, 19 Feb 2024 13:55:58 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> In this special case here I would not use errno, but the string returned in ebuf, in case the result is nullptr.
>
> Argh, I keep forgetting `dlopen` does not set errno (at least its not guaranteed by the standard).
> 
> Ok, in this case, I would not analyze the string either because it may be locale-dependent.
> 
> Never mind then; I'd thought this would be easy. One could probably use load() instead of dlopen() on AIX, but that change would require more investigations to see if load() and dlopen() are equivalent.
> 
> Okay, in that case just skip the errno test and call the second dlopen directly. Lets hope for the best then.

Sure .thank for all the info. This is great learning.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1494859583

From eastigeevich at openjdk.org  Mon Feb 19 19:22:54 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 19 Feb 2024 19:22:54 GMT
Subject: RFR: 8311248: Refactor CodeCache::initialize_heaps to simplify
 adding new CodeCache segments [v7]
In-Reply-To: <_HrFkS2z3Mk1RKtgVB010rsIx7aTolc_0iMDJox6eDc=.de2d7093-186f-48c0-859f-0769bf372b29@github.com>
References: <-V_dgQKhDrt1n0Zbk3qNa276jZBO822NlSvUv9AhpEA=.7a23c712-4b01-4aa7-acbe-8f5b5cca9002@github.com>
 <_HrFkS2z3Mk1RKtgVB010rsIx7aTolc_0iMDJox6eDc=.de2d7093-186f-48c0-859f-0769bf372b29@github.com>
Message-ID: <WiCb1GzxJ3PXOZFreJ9uhqRWKYz2djdrnQ9nsOiqvVo=.52460363-0602-4b80-ac08-282d322a3a51@github.com>

On Fri, 16 Feb 2024 10:23:06 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

>> These changes clean up the logic and the code of allocating codecache segments and add more testing of it, to open a door for further optimization of code cache segmentation.  The goal was to keep the behavior as close to the existing behavior as possible, even if it's not quite logical.
>> 
>> Also, these changes better account for alignment - PrintFlagsFinal shows the final aligned segment sizes, and the segments fill the ReservedCodeCacheSize without gaps caused by alignment.
>
> Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor update. removed helper function as it caused many comments in the review

src/hotspot/share/code/codeCache.cpp line 297:

> 295: 
> 296:     vm_exit_during_initialization("Invalid code heap sizes", message);
> 297:     return;

`return` is not needed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17244#discussion_r1494948232

From eastigeevich at openjdk.org  Mon Feb 19 19:28:55 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 19 Feb 2024 19:28:55 GMT
Subject: RFR: 8311248: Refactor CodeCache::initialize_heaps to simplify
 adding new CodeCache segments [v7]
In-Reply-To: <_HrFkS2z3Mk1RKtgVB010rsIx7aTolc_0iMDJox6eDc=.de2d7093-186f-48c0-859f-0769bf372b29@github.com>
References: <-V_dgQKhDrt1n0Zbk3qNa276jZBO822NlSvUv9AhpEA=.7a23c712-4b01-4aa7-acbe-8f5b5cca9002@github.com>
 <_HrFkS2z3Mk1RKtgVB010rsIx7aTolc_0iMDJox6eDc=.de2d7093-186f-48c0-859f-0769bf372b29@github.com>
Message-ID: <PoWH2tK2DM68MW-7uXfIh9ArMNJMKaMEC0tZQHDXxZQ=.42c984ec-0c4e-4189-b6ed-68c71c18d5e8@github.com>

On Fri, 16 Feb 2024 10:23:06 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

>> These changes clean up the logic and the code of allocating codecache segments and add more testing of it, to open a door for further optimization of code cache segmentation.  The goal was to keep the behavior as close to the existing behavior as possible, even if it's not quite logical.
>> 
>> Also, these changes better account for alignment - PrintFlagsFinal shows the final aligned segment sizes, and the segments fill the ReservedCodeCacheSize without gaps caused by alignment.
>
> Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor update. removed helper function as it caused many comments in the review

src/hotspot/share/code/codeCache.cpp line 181:

> 179: GrowableArray<CodeHeap*>* CodeCache::_allocable_heaps = new(mtCode) GrowableArray<CodeHeap*> (static_cast<int>(CodeBlobType::All), mtCode);
> 180: 
> 181: static bool check_min_size(const char *codeheap, size_t size, size_t required_size) {

This function never returns `false`.
`return false` is not reachable because of `vm_exit_during_initialization`.
We don't need to return anything from it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17244#discussion_r1494951869

From eastigeevich at openjdk.org  Mon Feb 19 20:01:58 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 19 Feb 2024 20:01:58 GMT
Subject: RFR: 8311248: Refactor CodeCache::initialize_heaps to simplify
 adding new CodeCache segments [v7]
In-Reply-To: <_HrFkS2z3Mk1RKtgVB010rsIx7aTolc_0iMDJox6eDc=.de2d7093-186f-48c0-859f-0769bf372b29@github.com>
References: <-V_dgQKhDrt1n0Zbk3qNa276jZBO822NlSvUv9AhpEA=.7a23c712-4b01-4aa7-acbe-8f5b5cca9002@github.com>
 <_HrFkS2z3Mk1RKtgVB010rsIx7aTolc_0iMDJox6eDc=.de2d7093-186f-48c0-859f-0769bf372b29@github.com>
Message-ID: <AP0D5dCA6pxZ9ecYSVo2sk5mk3GgRBL1wpbdiumYh08=.0b460918-19f9-45a7-be9d-e1847ed82772@github.com>

On Fri, 16 Feb 2024 10:23:06 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

>> These changes clean up the logic and the code of allocating codecache segments and add more testing of it, to open a door for further optimization of code cache segmentation.  The goal was to keep the behavior as close to the existing behavior as possible, even if it's not quite logical.
>> 
>> Also, these changes better account for alignment - PrintFlagsFinal shows the final aligned segment sizes, and the segments fill the ReservedCodeCacheSize without gaps caused by alignment.
>
> Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor update. removed helper function as it caused many comments in the review

src/hotspot/share/code/codeCache.cpp line 231:

> 229:     // MethodNonProfiled heap is always available for segmented code heap
> 230:     ShouldNotReachHere();
> 231:   }

Should we make it an assert?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17244#discussion_r1494973973

From eastigeevich at openjdk.org  Mon Feb 19 20:24:54 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 19 Feb 2024 20:24:54 GMT
Subject: RFR: 8311248: Refactor CodeCache::initialize_heaps to simplify
 adding new CodeCache segments [v7]
In-Reply-To: <_HrFkS2z3Mk1RKtgVB010rsIx7aTolc_0iMDJox6eDc=.de2d7093-186f-48c0-859f-0769bf372b29@github.com>
References: <-V_dgQKhDrt1n0Zbk3qNa276jZBO822NlSvUv9AhpEA=.7a23c712-4b01-4aa7-acbe-8f5b5cca9002@github.com>
 <_HrFkS2z3Mk1RKtgVB010rsIx7aTolc_0iMDJox6eDc=.de2d7093-186f-48c0-859f-0769bf372b29@github.com>
Message-ID: <d6dQLniMFksXcupyErOU07AbMcCScbhoIbNUg2FoBgc=.8c4d633d-4fa6-455d-90e6-b798aa2039e7@github.com>

On Fri, 16 Feb 2024 10:23:06 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

>> These changes clean up the logic and the code of allocating codecache segments and add more testing of it, to open a door for further optimization of code cache segmentation.  The goal was to keep the behavior as close to the existing behavior as possible, even if it's not quite logical.
>> 
>> Also, these changes better account for alignment - PrintFlagsFinal shows the final aligned segment sizes, and the segments fill the ReservedCodeCacheSize without gaps caused by alignment.
>
> Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor update. removed helper function as it caused many comments in the review

src/hotspot/share/code/codeCache.cpp line 250:

> 248:   }
> 249: 
> 250:   if (!profiled.set && non_profiled.set) {

I prefer to show explicitly with `else if` that it is an alternative case. This prevents from inserting any code between these two IFs.

src/hotspot/share/code/codeCache.cpp line 255:

> 253: 
> 254:   // Compatibility.
> 255:   // Override Non-NMethod default size if two other segments are set explicitly

I don't think we need this comment because it is obvious from IF.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17244#discussion_r1494985940
PR Review Comment: https://git.openjdk.org/jdk/pull/17244#discussion_r1494986529

From eastigeevich at openjdk.org  Mon Feb 19 20:36:56 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 19 Feb 2024 20:36:56 GMT
Subject: RFR: 8311248: Refactor CodeCache::initialize_heaps to simplify
 adding new CodeCache segments [v7]
In-Reply-To: <_HrFkS2z3Mk1RKtgVB010rsIx7aTolc_0iMDJox6eDc=.de2d7093-186f-48c0-859f-0769bf372b29@github.com>
References: <-V_dgQKhDrt1n0Zbk3qNa276jZBO822NlSvUv9AhpEA=.7a23c712-4b01-4aa7-acbe-8f5b5cca9002@github.com>
 <_HrFkS2z3Mk1RKtgVB010rsIx7aTolc_0iMDJox6eDc=.de2d7093-186f-48c0-859f-0769bf372b29@github.com>
Message-ID: <nUhUPfjEU6k5xT9FHUfi_oaiFmThHBGhWp-IYywSK7I=.0cdefbca-ad66-4174-9eff-c54f06d189f5@github.com>

On Fri, 16 Feb 2024 10:23:06 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

>> These changes clean up the logic and the code of allocating codecache segments and add more testing of it, to open a door for further optimization of code cache segmentation.  The goal was to keep the behavior as close to the existing behavior as possible, even if it's not quite logical.
>> 
>> Also, these changes better account for alignment - PrintFlagsFinal shows the final aligned segment sizes, and the segments fill the ReservedCodeCacheSize without gaps caused by alignment.
>
> Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor update. removed helper function as it caused many comments in the review

src/hotspot/share/code/codeCache.cpp line 278:

> 276:   if (!check_min_size("non-nmethod code heap", non_nmethod.size, non_nmethod_min_size) ||
> 277:      (profiled.enabled && !check_min_size("profiled code heap", profiled.size, min_size)) ||
> 278:      (non_profiled.enabled && !check_min_size("non-profiled code heap", non_profiled.size, min_size)) ||

A redundant check: the non-profiled code heap is always enabled.

src/hotspot/share/code/codeCache.cpp line 289:

> 287:       message.append(" + ProfiledCodeHeapSize (" SIZE_FORMAT "K)", profiled.size/K);
> 288:     }
> 289:     if (non_profiled.enabled) {

A redundant check: the non-profiled code heap is always enabled.

src/hotspot/share/code/codeCache.cpp line 312:

> 310:   // last adjustment: leftovers from page alignment go to non_nmethod segment
> 311:   non_nmethod.size += non_profiled.size & alignment_mask(min_size);
> 312:   non_nmethod.size += profiled.size & alignment_mask(min_size);

Why do we need this code?

src/hotspot/share/code/codeCache.cpp line 343:

> 341:   add_heap(non_method_space, "CodeHeap 'non-nmethods'", CodeBlobType::NonNMethod);
> 342: 
> 343:   if (non_profiled.enabled) {

A redundant check: the non-profiled code heap is always enabled.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17244#discussion_r1494990084
PR Review Comment: https://git.openjdk.org/jdk/pull/17244#discussion_r1494990866
PR Review Comment: https://git.openjdk.org/jdk/pull/17244#discussion_r1494993633
PR Review Comment: https://git.openjdk.org/jdk/pull/17244#discussion_r1494994590

From eastigeevich at openjdk.org  Mon Feb 19 20:40:55 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 19 Feb 2024 20:40:55 GMT
Subject: RFR: 8311248: Refactor CodeCache::initialize_heaps to simplify
 adding new CodeCache segments [v7]
In-Reply-To: <_HrFkS2z3Mk1RKtgVB010rsIx7aTolc_0iMDJox6eDc=.de2d7093-186f-48c0-859f-0769bf372b29@github.com>
References: <-V_dgQKhDrt1n0Zbk3qNa276jZBO822NlSvUv9AhpEA=.7a23c712-4b01-4aa7-acbe-8f5b5cca9002@github.com>
 <_HrFkS2z3Mk1RKtgVB010rsIx7aTolc_0iMDJox6eDc=.de2d7093-186f-48c0-859f-0769bf372b29@github.com>
Message-ID: <Mv9c5mJZq7bMd-DYHlBewMNbigFL3tVd9Il5WybboIE=.75da6ce5-d02c-4206-8e6d-a282adfb609a@github.com>

On Fri, 16 Feb 2024 10:23:06 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

>> These changes clean up the logic and the code of allocating codecache segments and add more testing of it, to open a door for further optimization of code cache segmentation.  The goal was to keep the behavior as close to the existing behavior as possible, even if it's not quite logical.
>> 
>> Also, these changes better account for alignment - PrintFlagsFinal shows the final aligned segment sizes, and the segments fill the ReservedCodeCacheSize without gaps caused by alignment.
>
> Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor update. removed helper function as it caused many comments in the review

src/hotspot/share/code/codeCache.cpp line 323:

> 321:   FLAG_SET_ERGO(ProfiledCodeHeapSize, profiled.size);
> 322:   FLAG_SET_ERGO(NonProfiledCodeHeapSize, non_profiled.size);
> 323:   FLAG_SET_ERGO(ReservedCodeCacheSize, cache_size);

A potential problem here: code heap sizes are `min_size` aligned but `cache_size` might be not.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17244#discussion_r1494996463

From jbhateja at openjdk.org  Tue Feb 20 00:11:57 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 20 Feb 2024 00:11:57 GMT
Subject: RFR: 8325991: Accelerate Poly1305 on x86_64 using AVX2
 instructions [v3]
In-Reply-To: <RcqlCw9bXCsxQf7dNaKVjFflrCvu41kJDkbbxpuCWaU=.d2cf9c21-2d34-4320-a76a-9ab0aa71c43e@github.com>
References: <IyoM1HY_rvNWwo4GxcV1yQleB3vrgaLwsAlOCEpLKqs=.1d50225c-8fe1-4a84-af56-274632b2b653@github.com>
 <RcqlCw9bXCsxQf7dNaKVjFflrCvu41kJDkbbxpuCWaU=.d2cf9c21-2d34-4320-a76a-9ab0aa71c43e@github.com>
Message-ID: <qxL7PSNxJEV_m5tRP8Jr3xmdzj-gBn4ztwuwZL5s1JA=.8fde5eae-6fd4-432f-9c79-173201c3ef66@github.com>

On Thu, 15 Feb 2024 20:09:06 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> The goal of this PR is to accelerate the Poly1305 algorithm using AVX2 instructions (including IFMA) for x86_64 CPUs.
>> 
>> This implementation is directly based on the AVX2 Poly1305 hash computation as implemented in Intel(R) Multi-Buffer Crypto for IPsec Library (url: https://github.com/intel/intel-ipsec-mb/blob/main/lib/avx2_t3/poly_fma_avx2.asm)
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change overloaded C to use COEFF

src/hotspot/cpu/x86/assembler_x86.cpp line 5150:

> 5148: 
> 5149: void Assembler::vpmadd52luq(XMMRegister dst, XMMRegister src1, Address src2, bool merge, int vector_len) {
> 5150:   assert(VM_Version::supports_avxifma(), "");

Please add an assertion for vector_len to be either 128 or 256 bit.

src/hotspot/cpu/x86/assembler_x86.cpp line 5152:

> 5150:   assert(VM_Version::supports_avxifma(), "");
> 5151:   InstructionMark im(this);
> 5152:   InstructionAttr attributes(vector_len, /* rex_w */ true, /* legacy_mode */ false, /* no_mask_reg */ false, /* uses_vl */ true);

uses_vl should be false, its a VEX encoded instruction.

src/hotspot/cpu/x86/assembler_x86.cpp line 5155:

> 5153:   if (merge) {
> 5154:     attributes.reset_is_clear_context();
> 5155:   }

As of now, merge semantics are only applicable to AVX512 instructions accepting an opmask register.

src/hotspot/cpu/x86/assembler_x86.cpp line 5167:

> 5165: 
> 5166: void Assembler::vpmadd52luq(XMMRegister dst, XMMRegister src1, XMMRegister src2, bool merge, int vector_len) {
> 5167:   assert(VM_Version::supports_avxifma(), "");

assertion for vector lengths, same as above.

src/hotspot/cpu/x86/assembler_x86.cpp line 5221:

> 5219:     attributes.reset_is_clear_context();
> 5220:   }
> 5221: 

Above comments applicable to this routine also.

src/hotspot/cpu/x86/stubGenerator_x86_64_poly.cpp line 1367:

> 1365: 
> 1366:   // VECTOR LOOP: process 4 * 16-byte message blocks at a time
> 1367:   __ bind(L_process256Loop);

Add appropriate alignment at the beginning of vector loop.

src/hotspot/cpu/x86/vm_version_x86.hpp line 302:

> 300:     uint32_t value;
> 301:   };
> 302: 

We can avoid creating additional structures for SefCpuid7Ecx1Ebx, SefCpuid7Ecx1Ecx and SefCpuid7Ecx1Edx. They occupy space over stack and none of their bits are being used.

src/hotspot/cpu/x86/vm_version_x86.hpp line 482:

> 480:     SefCpuid7Ecx1Ebx sef_cpuid7_ecx1_ebx;
> 481:     SefCpuid7Ecx1Ecx sef_cpuid7_ecx1_ecx;
> 482:     SefCpuid7Ecx1Edx sef_cpuid7_ecx1_edx;

Please remove SefCpuid7Ecx1Ebx, SefCpuid7Ecx1Ecx and SefCpuid7Ecx1Edx field definitions.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17881#discussion_r1493768592
PR Review Comment: https://git.openjdk.org/jdk/pull/17881#discussion_r1493768466
PR Review Comment: https://git.openjdk.org/jdk/pull/17881#discussion_r1493768841
PR Review Comment: https://git.openjdk.org/jdk/pull/17881#discussion_r1493769528
PR Review Comment: https://git.openjdk.org/jdk/pull/17881#discussion_r1493770005
PR Review Comment: https://git.openjdk.org/jdk/pull/17881#discussion_r1495089745
PR Review Comment: https://git.openjdk.org/jdk/pull/17881#discussion_r1493760215
PR Review Comment: https://git.openjdk.org/jdk/pull/17881#discussion_r1493760487

From ddong at openjdk.org  Tue Feb 20 00:41:57 2024
From: ddong at openjdk.org (Denghui Dong)
Date: Tue, 20 Feb 2024 00:41:57 GMT
Subject: RFR: 8326111: JFR: Cleanup for JFR_ONLY [v2]
In-Reply-To: <JkreW92RpA8VDWs1id6RrXd5sV2TZsLKvp36NepmE3s=.23102365-e003-4b3d-948e-8d4579668422@github.com>
References: <ejPq_N_6Trx4KaqeRZwBulHr-ndZb7MJqbZbHTO8MqM=.cc3d7239-9c2f-4556-939d-7fb72378a551@github.com>
 <JkreW92RpA8VDWs1id6RrXd5sV2TZsLKvp36NepmE3s=.23102365-e003-4b3d-948e-8d4579668422@github.com>
Message-ID: <duHCoyaNY5rosXhEDzoVjeGyS2w7TCQpwKwcqfHfviE=.ae8faf1e-e221-4ff1-b54d-4e3ade7db306@github.com>

On Sun, 18 Feb 2024 08:10:16 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> Greetings,
>> 
>> Could I have a review of this trivial change that cleans up code where used JFR_ONLY incorrectly?
>> 
>> testing: build with --enable-jvm-feature-jfr and --disable-jvm-feature-jfr
>> 
>> Denghui
>
> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more cleanup

Thanks for the review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17903#issuecomment-1953317021

From ddong at openjdk.org  Tue Feb 20 00:41:57 2024
From: ddong at openjdk.org (Denghui Dong)
Date: Tue, 20 Feb 2024 00:41:57 GMT
Subject: Integrated: 8326111: JFR: Cleanup for JFR_ONLY
In-Reply-To: <ejPq_N_6Trx4KaqeRZwBulHr-ndZb7MJqbZbHTO8MqM=.cc3d7239-9c2f-4556-939d-7fb72378a551@github.com>
References: <ejPq_N_6Trx4KaqeRZwBulHr-ndZb7MJqbZbHTO8MqM=.cc3d7239-9c2f-4556-939d-7fb72378a551@github.com>
Message-ID: <62Lb_E6CpMkzkn_YBCdTteY2G0rKazp6lVoWeq2-9c0=.dfedb812-e3de-4632-8687-9d240dfebcd2@github.com>

On Sun, 18 Feb 2024 07:54:57 GMT, Denghui Dong <ddong at openjdk.org> wrote:

> Greetings,
> 
> Could I have a review of this trivial change that cleans up code where used JFR_ONLY incorrectly?
> 
> testing: build with --enable-jvm-feature-jfr and --disable-jvm-feature-jfr
> 
> Denghui

This pull request has now been integrated.

Changeset: 7d32a1a8
Author:    Denghui Dong <ddong at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7d32a1a8293f6d82f4d5959a4c929f96244cc057
Stats:     13 lines in 7 files changed: 0 ins; 0 del; 13 mod

8326111: JFR: Cleanup for JFR_ONLY

Reviewed-by: egahlin

-------------

PR: https://git.openjdk.org/jdk/pull/17903

From ddong at openjdk.org  Tue Feb 20 05:27:22 2024
From: ddong at openjdk.org (Denghui Dong)
Date: Tue, 20 Feb 2024 05:27:22 GMT
Subject: RFR: 8326012: JFR: Event for time to safepoint [v9]
In-Reply-To: <68hS0kQgtDIk4ioAJj_r0_GLT6h0lcif6Daj6WRwxlI=.40c2a6e7-70a8-4954-bcde-9318ee311028@github.com>
References: <68hS0kQgtDIk4ioAJj_r0_GLT6h0lcif6Daj6WRwxlI=.40c2a6e7-70a8-4954-bcde-9318ee311028@github.com>
Message-ID: <DwJb1JrYg4IMe_3d5MAjEkiwdTDhYHFCx0qVxDCmLmc=.47673420-7467-42e6-8231-e37d9e8882f9@github.com>

> There are now some JFR events related to safepoint. When time-to-safepoint (aka ttsp) is too long, these events could not be very helpful since based on them we cannot know which threads cause it and what those threads are doing.
> 
> Users can use `-XX:+SafepointTimeout -XX:SafepointTimeoutDelay=100` to see the threads that don't reach safepoint in time but without stack traces. Using `-XX:+ AbortVMOnSafepointTimeout` can capture the stack traces but it crashes the process, hence it's not sensible to enable the flag in production.
> 
> ~~This patch adds a new JFR event `EventSafepointTimeout` to record the threads that cause ttsp too long.~~
> 
> ~~This event includes two fields:~~
> 
> ~~- safepointId: the relevant safepoint id~~
> ~~- timeExceeded: the amount of time exceeding `SafepointTimeoutDelay` used by the thread to reach safepoint~~
> 
> ~~In the current version, this event records the stack of those problematic threads when they finally reach safepoint. Hence, there is a bias, but it's still helpful to deduce the root place.~~
> 
> A better implementation is to record a more accurate stack, but this will increase complexity. At the same time, the native stack may also be important for this problem, but it is not currently supported by JFR.
> 
> Any input would be greatly appreciated.
> 
> Testing: jdk/jdk/jfr

Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:

  delete _entries when disabled

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17888/files
  - new: https://git.openjdk.org/jdk/pull/17888/files/1c006732..75ca854a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17888&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17888&range=07-08

  Stats: 8 lines in 1 file changed: 5 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17888.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17888/head:pull/17888

PR: https://git.openjdk.org/jdk/pull/17888

From dholmes at openjdk.org  Tue Feb 20 06:17:55 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 20 Feb 2024 06:17:55 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v12]
In-Reply-To: <P_SGQw9YGQvIDVikpCoUCZLSoumOSxbSwGJspCEb5pI=.e2cf601a-e89c-4e50-9d69-20ef18ff49e5@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <P_SGQw9YGQvIDVikpCoUCZLSoumOSxbSwGJspCEb5pI=.e2cf601a-e89c-4e50-9d69-20ef18ff49e5@github.com>
Message-ID: <4B3DWXFwEnHy-pkzhr3L-LzQi3O0hdenzXqb5V1OejQ=.67044e45-777b-4fbc-af5e-de29348a2247@github.com>

On Mon, 19 Feb 2024 15:33:23 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
>> The function returns the following structure:
>> 
>> 
>> typedef struct {
>>     jthread owner;
>>     jint entry_count;
>>     jint waiter_count;
>>     jthread* waiters;
>>     jint notify_waiter_count;
>>     jthread* notify_waiters;
>> } jvmtiMonitorUsage;
>> 
>> 
>> The following four fields are defined this way:
>> 
>> waiter_count  [jint] The number of threads waiting to own this monitor
>> waiters  [jthread*] The waiter_count waiting threads
>> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
>> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
>> 
>> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
>> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
>> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
>> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
>> This update makes it right.
>> 
>> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
>> 
>> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
>> 
>>   jvmti/GetObjectMonitorUsage/objmonusage001
>>   jvmti/GetObjectMonitorUsage/objmonusage003
>> 
>> 
>> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
>> 
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
>> 
>> 
>> 
>> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository.
>> 
>> Also, please see and review the related CSR:
>>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
>> 
>> The Release-Note is:
>> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage
>>  
>> Testing:
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: addressed comments from David

test/hotspot/jtreg/serviceability/jvmti/GetObjectMonitorUsage/ObjectMonitorUsage.java line 54:

> 52: 
> 53:     static Object lockCheck = new Object();
> 54:     static Thread thr[] = new Thread[NUMBER_OF_THREADS];

Nit: the `[]` go on the type not the variable.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1495292810

From stuefe at openjdk.org  Tue Feb 20 06:31:12 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 20 Feb 2024 06:31:12 GMT
Subject: RFR: JDK-8323497: On x64,
 use 32-bit immediate moves for narrow klass base if possible [v3]
In-Reply-To: <HTQ6J0zq0B3MQRpECfAn_vbkV-rTWN_rsnEVVgkJN0k=.44afeb5e-63a1-4de0-911b-d6db9c5532de@github.com>
References: <HTQ6J0zq0B3MQRpECfAn_vbkV-rTWN_rsnEVVgkJN0k=.44afeb5e-63a1-4de0-911b-d6db9c5532de@github.com>
Message-ID: <ROMLODKlug0oMp4rU042kjZk79TPZZVrVp7fFxw6ISg=.98582e86-33b6-479e-84d2-b722b87b346d@github.com>

> On x64, we always use the long form of mov immediate to load the klass base into a register. If the klass base fits into 32 bits, we could use the short form and save four instruction bytes. 
> 
> Before: mov uses 10 instruction bytes:
> 
> 
>    35  ;; decode_klass_not_null
>    36   0x00007f8b089e51c4:   movabs $0x82000000,%r11
>    37   0x00007f8b089e51ce:   add    %r11,%r10
> 
> 
> Now: mov uses 6 instruction bytes:
> 
> 
>    35  ;; decode_klass_not_null
>    36   0x00007fbe609e51c4:   mov    $0x82000000,%r11d
>    37   0x00007fbe609e51ca:   add    %r11,%r10
> 
> 
> Note that this optimization does not depend on zero-based addressing, and therefore we change class space reservation: we now always look in low-address regions first.
> 
> ----------
> 
> Tests: tier1 (GHA), tier 2 on x64 linux

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 four additional commits since the last revision:

 - Merge branch 'openjdk:master' into use-32bit-immediate-moves-on-x64-for-klass-encoding-base
 - Merge branch 'openjdk:master' into use-32bit-immediate-moves-on-x64-for-klass-encoding-base
 - remove obsolete comment
 - use-32bit-immediate-moves-on-x64-for-klass-encoding-base

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17340/files
  - new: https://git.openjdk.org/jdk/pull/17340/files/023d80ce..7a9f0ccc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17340&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17340&range=01-02

  Stats: 25380 lines in 707 files changed: 9185 ins; 10979 del; 5216 mod
  Patch: https://git.openjdk.org/jdk/pull/17340.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17340/head:pull/17340

PR: https://git.openjdk.org/jdk/pull/17340

From stuefe at openjdk.org  Tue Feb 20 06:31:14 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 20 Feb 2024 06:31:14 GMT
Subject: RFR: JDK-8323497: On x64,
 use 32-bit immediate moves for narrow klass base if possible [v2]
In-Reply-To: <toLuxM7q8f6ZxzIhTB4AbM8Z_aVOtz-Tk2BaxiJ7wO4=.394b6722-6223-4b0e-b77c-28301213481b@github.com>
References: <HTQ6J0zq0B3MQRpECfAn_vbkV-rTWN_rsnEVVgkJN0k=.44afeb5e-63a1-4de0-911b-d6db9c5532de@github.com>
 <toLuxM7q8f6ZxzIhTB4AbM8Z_aVOtz-Tk2BaxiJ7wO4=.394b6722-6223-4b0e-b77c-28301213481b@github.com>
Message-ID: <_68ECcw_OokuD26uZFKcvye35P8Y8uMqyS8GNQ8iRNs=.cd727de1-f0ed-47ce-8b2e-0957dfa8f390@github.com>

On Sat, 10 Feb 2024 09:52:20 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> On x64, we always use the long form of mov immediate to load the klass base into a register. If the klass base fits into 32 bits, we could use the short form and save four instruction bytes. 
>> 
>> Before: mov uses 10 instruction bytes:
>> 
>> 
>>    35  ;; decode_klass_not_null
>>    36   0x00007f8b089e51c4:   movabs $0x82000000,%r11
>>    37   0x00007f8b089e51ce:   add    %r11,%r10
>> 
>> 
>> Now: mov uses 6 instruction bytes:
>> 
>> 
>>    35  ;; decode_klass_not_null
>>    36   0x00007fbe609e51c4:   mov    $0x82000000,%r11d
>>    37   0x00007fbe609e51ca:   add    %r11,%r10
>> 
>> 
>> Note that this optimization does not depend on zero-based addressing, and therefore we change class space reservation: we now always look in low-address regions first.
>> 
>> ----------
>> 
>> Tests: tier1 (GHA), tier 2 on x64 linux
>
> Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into use-32bit-immediate-moves-on-x64-for-klass-encoding-base
>  - remove obsolete comment
>  - use-32bit-immediate-moves-on-x64-for-klass-encoding-base

@shipilev ,  @merykitty ? Could you please review?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17340#issuecomment-1953563943

From rehn at openjdk.org  Tue Feb 20 08:33:00 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 20 Feb 2024 08:33:00 GMT
Subject: RFR: 8326235: RISC-V: Size CodeCache for short calls encoding
Message-ID: <MHf3cpwm83ITBdp9IbzDbEvWjye3zKRLpxO0cCV9OVQ=.fc534a38-6d2b-4fb2-8a2f-b9b498dc1414@github.com>

Hi, please consider.

This limits the code cache to a size such that all code cache -> code cache calls and jump may always use auipc+jalr.
(this is what we do in practice)
Thus we can fix the encoding for those and not have variable encoding.
The reduction of the size is just 2k, but due to option passing the real reduction is probably 1M.
-XX:ReservedCodeCacheSize=2047M (down from 2048)

Note, specifying '2G' gives the message:

> Invalid ReservedCodeCacheSize=2048M. Must be at most 2047M.

Manually test, no test I found uses this large code cache.

-------------

Commit messages:
 - Change RV code cache size.

Changes: https://git.openjdk.org/jdk/pull/17924/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17924&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8326235
  Stats: 10 lines in 2 files changed: 8 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17924.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17924/head:pull/17924

PR: https://git.openjdk.org/jdk/pull/17924

From sroy at openjdk.org  Tue Feb 20 08:59:00 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Tue, 20 Feb 2024 08:59:00 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v23]
In-Reply-To: <gs0K1PQTfFy6Ivl4NyRx8KynPBBrqEXSJLxf64Bc87w=.08d770f8-44f1-41bb-b232-ff6ec6b14ebf@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <HN-bL-HmykOa-uJTej8Ud3tC6usQvPywTfUV7XO-t-o=.22f9b270-6d72-4e8c-a90b-97ab6c816888@github.com>
 <8ZuzOofIzdn0JgMmacWw6hPQ88V9hwHN8pJz8vcdEns=.7daa4550-52de-41b1-beb2-2c002fe2fbce@github.com>
 <iQ_9KV1Pl5s2AYFfYaF4oVuHE7d5SeNtk1coVwHadhk=.f7568310-f8f7-46ce-9e81-d5537531f3bb@github.com>
 <GXrQtKf5matzjc0POsR8QwJRc8UWI3U8SIN7-3a7iWU=.27b87d30-e424-4346-a740-37ca4b45a452@github.com>
 <5A8gF2IxapOCnUg2bDQVcitnGgGXKAcul7danUNE2q4=.54b7ffb2-4ba0-47e8-8d8b-c986fac4e9c8@github.com>
 <o21d_Bs2QT2-_SO9K7MoROvMs0mgpjLqX_8caNKxv1E=.a42210fd-b70d-412e-9e89-821242078895@github.com>
 <75Cr_jXGHaVJVyHADMj5BNn1x12D56RtAprZ1AY3Q6E=.91bc8cc3-0f91-48b6-9509-7727cc6f8c81@github.com>
 <gs0K1PQTfFy6Ivl4NyRx8KynPBBrqEXSJLxf64Bc87w=.08d770f8-44f1-41bb-b232-ff6ec6b14ebf@github.com>
Message-ID: <YXiwbEAYVsD2nMzRvsXmZkGkLgMsKTdRM8TIHp61Fjs=.9e58fa08-f743-4e1f-9eb5-3a10d1ae6345@github.com>

On Mon, 19 Feb 2024 17:16:53 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> Argh, I keep forgetting `dlopen` does not set errno (at least its not guaranteed by the standard).
>> 
>> Ok, in this case, I would not analyze the string either because it may be locale-dependent.
>> 
>> Never mind then; I'd thought this would be easy. One could probably use load() instead of dlopen() on AIX, but that change would require more investigations to see if load() and dlopen() are equivalent.
>> 
>> Okay, in that case just skip the errno test and call the second dlopen directly. Lets hope for the best then.
>
> Sure .thank for all the info. This is great learning.

reverted the error code handling.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1495450839

From mdoerr at openjdk.org  Tue Feb 20 09:17:02 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 20 Feb 2024 09:17:02 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v24]
In-Reply-To: <qwMbSmLF3tOFVkLkjtao2dwOR0KUBdUuhhjntYzDOPE=.d5b8dfc4-c476-44f3-81d2-e45b73cbad02@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <qwMbSmLF3tOFVkLkjtao2dwOR0KUBdUuhhjntYzDOPE=.d5b8dfc4-c476-44f3-81d2-e45b73cbad02@github.com>
Message-ID: <QOwHKlxg_HZevpBg7IAzLhI5LepEb20Ah8b0pRd7XKg=.eff7270f-e8e3-441f-a010-fcafa068cca3@github.com>

On Mon, 19 Feb 2024 17:16:34 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am.
>> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX.
>> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails.
>
> Suchismith Roy has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove error_code
>  - revert error code check

src/hotspot/os/aix/os_aix.cpp line 1185:

> 1183:   // Shared object in .so format dont have braces, hence they get removed for archives with members.
> 1184:   if (result == nullptr) {
> 1185:     assert(strlen(new_extension) < strlen(old_extension),"New extension length must be less than existing one");

`<=` would be sufficient. Please add a whitespace after `,`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1495478067

From aph at openjdk.org  Tue Feb 20 09:26:55 2024
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 20 Feb 2024 09:26:55 GMT
Subject: RFR: JDK-8323497: On x64,
 use 32-bit immediate moves for narrow klass base if possible [v3]
In-Reply-To: <S9ZdqB5BFahvGlYr97TKIQwqx-L4y1rHwiUCGymj1OY=.a5d71b8c-b71b-46c7-9b18-c95565eca9bb@github.com>
References: <HTQ6J0zq0B3MQRpECfAn_vbkV-rTWN_rsnEVVgkJN0k=.44afeb5e-63a1-4de0-911b-d6db9c5532de@github.com>
 <vffaNPh7l-CbJfCu6gv9-wE8qeQMMyxVgrBBxuK8WEo=.f442678e-e2e5-4688-9641-a6eb02159f75@github.com>
 <LHKSVXVFTaFh_w8O_v-vC4saEiZARh5XiFTze_bnZlw=.ad9964d2-c77f-4a7d-ba1c-03c7c838d3e2@github.com>
 <t85bGH5zyi54zfJc1JHD4inDE4fKKoISQCavlPsUdKk=.8a1e869c-09f9-4730-9e8a-10a8bc2e55bd@github.com>
 <EHqa2vjBRE-foHVowIcR1VNcnXezeigS8P8PYyTS51Y=.9f7ababe-cf1d-488b-9041-badb5d23a81c@github.com>
 <_FLlMLBU4zkxG6w5aXIfSijAtCQ_YvInW45FVdoLl1Q=.079e54d7-b0e2-4aa0-8d08-175e5db48ae5@github.com>
 <7uVyobQMUlm5ER3En2_-VbgKdbACFSLXnFYdm4weXpc=.b0e7afcd-bb3e-412b-ad85-7136ffa5695d@github.com>
 <mPn-7ab1CaUsmHTfwyKpr38NeyEH4hgR-m9ZxJQGCbY=.7eda3db2-90d2-4214-8b84-9960847ef277@github.com>
 <EPj3FOIX1ezdynWOllbXZA6X-U_oGyeuzZEy92_vhpo=.5402d9ce-b156-4e1e-b3ca-51e3ca36d88e@github.com>
 <LzYGg5oW1-lxdgcFyujYzRtSu7aUQoI53xfpGq-PzS4=.d7dbd3ce-711c-411e-bc17-a7102b3cee47@github.com>
 <-8ulfVGVzYoXW18mnfuFxhZKWkW9YszZyFG
 uK8jHbmc=.5fca00d4-5d62-4d3b-ba04-f5fe6fbe0b17@github.com>
 <03VyCix7YEqESyJV0KEmOD4acCr1ZBkvxwkBPaqBrCM=.d42eee52-160f-481e-9f1f-9a54de45d70e@github.com>
 <RUk0OKii8VIgeVckE9ygwyfl1Ng4TK19UsOW7PbqvzI=.1afc8388-523f-427b-889e-8f2aaa298e68@github.com>
 <dXdGf2KqurJPj7lmlT3hG3K0tZEHBwueZeeDaOssxEk=.042a9199-1660-48b5-8de4-be761644d125@github.com>
 <lFtyqZgBciKWOGR5TlbZhxA4rYf5PLy6gTX6wJOC0v4=.a0f9767a-e589-45e8-95df-bb3264ecae2a@github.com>
 <q68owU5hgGb92578GhXV-WMZAySmibV0WXlCl_HnNm8=.171a76ac-a9a7-40ec-ab82-16aed8620a45@github.com>
 <S9ZdqB5BFahvGlYr97TKIQwqx-L4y1rHwiUCGymj1OY=.a5d71b8c-b71b-46c7-9b18-c95565eca9bb@github.com>
Message-ID: <L96gzBSVsJiKKCHhXUFF9byP7HJJNzhQDDy6vqVBqLI=.e0a73859-dd17-4b64-bcf6-7a6022316760@github.com>

On Thu, 11 Jan 2024 11:30:24 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> With the new movptr variant, things look good:
>> 
>> < 2g
>> 
>> 
>>  ;; decode_klass_not_null
>>   0x00007fcb608681c4:   mov    $0x18000000,%r11d
>> 0x00007fcb608681c4:   41 bb 00 00 00 18 
>>   0x00007fcb608681ca:   add    %r11,%r10
>> 0x00007fcb608681ca:   4d 03 d3 
>> 
>> 
>> < 4g
>> 
>> 
>>  ;; decode_klass_not_null
>>   0x00007f382c8681c4:   mov    $0x85000000,%r11d
>> 0x00007f382c8681c4:   41 bb 00 00 00 85 
>>   0x00007f382c8681ca:   add    %r11,%r10
>> 0x00007f382c8681ca:   4d 03 d3 
>> 
>> 
>>> 4g
>> 
>> 
>>  ;; decode_klass_not_null
>>   0x00007fd8908681c4:   movabs $0x7fd7b6000000,%r11
>> 0x00007fd8908681c4:   49 bb 00 00 00 b6 d7 7f 00 00 
>>   0x00007fd8908681ce:   add    %r11,%r10
>> 0x00007fd8908681ce:   4d 03 d3 
>> 
>> 
>> I assume if the 32-bit mov variants were to use non-Rxx registers, the REX prefix could also be omitted? Giving us another byte back.
>> 
>> I'll run tests with the new variant.
>
> BTW, I think it would be useful for PrintAssembly to also optionally print the raw bytes in addition to the decoded instruction. It certainly helps me understanding stuff. Do you agree? If yes, I'll prepare a patch.

I'm pretty marginal on this. If I ever have needed to see bytes, I've used the debugger.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17340#discussion_r1495493867

From sroy at openjdk.org  Tue Feb 20 09:27:15 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Tue, 20 Feb 2024 09:27:15 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v25]
In-Reply-To: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
Message-ID: <xemN0ZxPQvRMrO-v4824K36DyT1c42nuOYzLtyUtGnI=.bb7c2f33-cb3c-466b-9d00-76ad3e3fa677@github.com>

> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am.
> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX.
> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails.

Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:

   remove space

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16604/files
  - new: https://git.openjdk.org/jdk/pull/16604/files/c6b3deb3..664e41a4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=23-24

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16604.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604

PR: https://git.openjdk.org/jdk/pull/16604

From jbhateja at openjdk.org  Tue Feb 20 09:51:57 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 20 Feb 2024 09:51:57 GMT
Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v8]
In-Reply-To: <vKgvRTfvDCx3oNJSnKNGqV0WtroCRPiEP3hEdHp1oek=.b4b5b97d-4233-48d3-9cf2-e75176ed36ca@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <ZodY1FIPk3VAbz3nRKDmnKGHByEj_ygOBUR4SbG-6oo=.864cf3ec-9399-4411-ab7e-a92f9c90858f@github.com>
 <vKgvRTfvDCx3oNJSnKNGqV0WtroCRPiEP3hEdHp1oek=.b4b5b97d-4233-48d3-9cf2-e75176ed36ca@github.com>
Message-ID: <I7EqdqNzJRToGpBfODbuNA5DtqTuCzQvgpGgFc8aeVw=.340e86b3-f7bc-42f0-8e85-f5d1f174b3a0@github.com>

On Wed, 14 Feb 2024 14:31:03 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove gcc lib fn; reduce spacial cases to 10 from 32
>
> Thank you all for the reviews.  I have been asked to simplify this code to facilitate easier review, and to remove the gcc library code I used for memcmp.  We also discovered that special-casing up to 31 bytes of needle was not necessary to get the performance gain.  I will be commenting the code and fixing the single build failure soon.

Hi @asgibbons ,

I am getting following error with slowdebug build on Meteor Lake system.


ERROR: Build failed for target 'images' in configuration 'linux-x86_64-server-slowdebug' (exit code 2) 

=== Output from failing command(s) repeated here ===
* For target buildtools_create_symbols_javac__the.COMPILE_CREATE_SYMBOLS_batch:
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/home/jatinbha/sandboxes/jdk-reviews/jdk/src/hotspot/share/asm/assembler.hpp:169), pid=237140, tid=237235
#  assert(is_bound() || is_unused()) failed: Label was never bound to a location, but it was used as a jmp target
#
# JRE version: OpenJDK Runtime Environment (23.0) (slowdebug build 23-internal-adhoc.sdp.jdk)
# Java VM: OpenJDK 64-Bit Server VM (slowdebug 23-internal-adhoc.sdp.jdk, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x4c9e3e]  Label::~Label()+0x5c
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to /home/jatinbha/sandboxes/jdk-reviews/jdk/make/core.237140)
#
# An error report file with more information is saved as:
# /home/jatinbha/sandboxes/jdk-reviews/jdk/make/hs_err_pid237140.log
   ... (rest of output omitted)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16753#issuecomment-1953840322

From fyang at openjdk.org  Tue Feb 20 11:08:53 2024
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 20 Feb 2024 11:08:53 GMT
Subject: RFR: 8326235: RISC-V: Size CodeCache for short calls encoding
In-Reply-To: <MHf3cpwm83ITBdp9IbzDbEvWjye3zKRLpxO0cCV9OVQ=.fc534a38-6d2b-4fb2-8a2f-b9b498dc1414@github.com>
References: <MHf3cpwm83ITBdp9IbzDbEvWjye3zKRLpxO0cCV9OVQ=.fc534a38-6d2b-4fb2-8a2f-b9b498dc1414@github.com>
Message-ID: <BsTqc_mXzoF8wj4xed4mfRVdCnBVF0RSDmYtIuZL2xI=.7fb7b03f-55d6-429c-ab70-15324d055a7e@github.com>

On Tue, 20 Feb 2024 08:28:18 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Hi, please consider.
> 
> This limits the code cache to a size such that all code cache -> code cache calls and jump may always use auipc+jalr.
> (this is what we do in practice)
> Thus we can fix the encoding for those and not have variable encoding.
> The reduction of the size is just 2k, but due to option passing the real reduction is probably 1M.
> -XX:ReservedCodeCacheSize=2047M (down from 2048)
> 
> Note, specifying '2G' gives the message:
> 
>> Invalid ReservedCodeCacheSize=2048M. Must be at most 2047M.
> 
> Manually test, no test I found uses this large code cache.

Thanks for fixing this potential risk. We will be more certain in code emitted for a cc -> cc call. In fact, I was also planning to do a similar fix for this very uncommon case :-)

-------------

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17924#pullrequestreview-1890147505

From fyang at openjdk.org  Tue Feb 20 11:14:55 2024
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 20 Feb 2024 11:14:55 GMT
Subject: RFR: 8324124: RISC-V: implement _vectorizedMismatch intrinsic
In-Reply-To: <dxSBhJiLeVkLF8PvHW3MMg69vwXU0VshECCMz5HnhhI=.e0cbda8b-f7f6-44ff-806b-1f21496911be@github.com>
References: <dxSBhJiLeVkLF8PvHW3MMg69vwXU0VshECCMz5HnhhI=.e0cbda8b-f7f6-44ff-806b-1f21496911be@github.com>
Message-ID: <LHoFBLghiIk-dJMOtZSY6Ca3erRXda8a_C1IrboorGU=.51730c35-3e86-4eac-a972-c4f9509ae7f9@github.com>

On Wed, 7 Feb 2024 14:35:55 GMT, Yuri Gaevsky <duke at openjdk.org> wrote:

> Hello All,
> 
> Please review these changes to enable the __vectorizedMismatch_ intrinsic on RISC-V platform with RVV instructions supported.
> 
> Thank you,
> -Yuri Gaevsky
> 
> **Correctness checks:**
>   hotspot/jtreg/compiler/{intrinsic/c1/c2}/ under QEMU-8.1 with RVV v1.0.0 and -XX:TieredStopAtLevel=1/2/3/4.

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 4256:

> 4254: 
> 4255:   bind(VEC_LOOP);
> 4256:   vsetvli(t0, cnt, Assembler::e8, Assembler::m8);

I see `e8` element size is always used here for all cases. Maybe we could make use of some larger element size (according to `log2_array_indxscale` input) to improve the code? Especiall, the part for handling `idx`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17750#discussion_r1495640750

From qamai at openjdk.org  Tue Feb 20 11:27:57 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 20 Feb 2024 11:27:57 GMT
Subject: RFR: JDK-8323497: On x64,
 use 32-bit immediate moves for narrow klass base if possible [v3]
In-Reply-To: <ROMLODKlug0oMp4rU042kjZk79TPZZVrVp7fFxw6ISg=.98582e86-33b6-479e-84d2-b722b87b346d@github.com>
References: <HTQ6J0zq0B3MQRpECfAn_vbkV-rTWN_rsnEVVgkJN0k=.44afeb5e-63a1-4de0-911b-d6db9c5532de@github.com>
 <ROMLODKlug0oMp4rU042kjZk79TPZZVrVp7fFxw6ISg=.98582e86-33b6-479e-84d2-b722b87b346d@github.com>
Message-ID: <mglIjkgFXSmoyWh-NS1KubJrhbJS_iTiBAiA1MuVk8s=.ee747541-6812-4528-9190-78beb245a3d2@github.com>

On Tue, 20 Feb 2024 06:31:12 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> On x64, we always use the long form of mov immediate to load the klass base into a register. If the klass base fits into 32 bits, we could use the short form and save four instruction bytes. 
>> 
>> Before: mov uses 10 instruction bytes:
>> 
>> 
>>    35  ;; decode_klass_not_null
>>    36   0x00007f8b089e51c4:   movabs $0x82000000,%r11
>>    37   0x00007f8b089e51ce:   add    %r11,%r10
>> 
>> 
>> Now: mov uses 6 instruction bytes:
>> 
>> 
>>    35  ;; decode_klass_not_null
>>    36   0x00007fbe609e51c4:   mov    $0x82000000,%r11d
>>    37   0x00007fbe609e51ca:   add    %r11,%r10
>> 
>> 
>> Note that this optimization does not depend on zero-based addressing, and therefore we change class space reservation: we now always look in low-address regions first.
>> 
>> ----------
>> 
>> Tests: tier1 (GHA), tier 2 on x64 linux
>
> 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 four additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into use-32bit-immediate-moves-on-x64-for-klass-encoding-base
>  - Merge branch 'openjdk:master' into use-32bit-immediate-moves-on-x64-for-klass-encoding-base
>  - remove obsolete comment
>  - use-32bit-immediate-moves-on-x64-for-klass-encoding-base

I have taken a look and left some comments. Thanks.

src/hotspot/cpu/x86/compressedKlass_x86.cpp line 44:

> 42:       result = reserve_address_space_for_zerobased_encoding(size, aslr);
> 43:     }
> 44:   } else {

This should be:

    if (result == nullptr) {
        // If we cannot use zero-based encoding (when CDS is enabled), optimizing for an
        ...
    }

src/hotspot/cpu/x86/macroAssembler_x86.cpp line 5596:

> 5594:   if (CompressedKlassPointers::base() != nullptr) {
> 5595:     // Uses 32-bit mov if base is small enough
> 5596:     movptr(tmp, (intptr_t)CompressedKlassPointers::base());

If we can reserve the base in the low 2G then this could be optimized further to `addq(r, CompressedKlassPointers::base())` and if `LogKlassAlignmentInBytes` is 8 (as asserted in `decode_and_move_klass_not_null` below), we can shorten the whole sequence into `leaq(r, Address(noreg, r, Address::times_8, CompressedKlassPointers::base())`

src/hotspot/cpu/x86/macroAssembler_x86.cpp line 5620:

> 5618:     } else {
> 5619:       xorq(dst, dst);
> 5620:     }

This can also be 1 instruction when the base is smaller than $2^{31}$.

-------------

PR Review: https://git.openjdk.org/jdk/pull/17340#pullrequestreview-1890167182
PR Review Comment: https://git.openjdk.org/jdk/pull/17340#discussion_r1495647551
PR Review Comment: https://git.openjdk.org/jdk/pull/17340#discussion_r1495654933
PR Review Comment: https://git.openjdk.org/jdk/pull/17340#discussion_r1495657740

From bulasevich at openjdk.org  Tue Feb 20 12:46:57 2024
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Tue, 20 Feb 2024 12:46:57 GMT
Subject: RFR: 8311248: Refactor CodeCache::initialize_heaps to simplify
 adding new CodeCache segments [v7]
In-Reply-To: <PoWH2tK2DM68MW-7uXfIh9ArMNJMKaMEC0tZQHDXxZQ=.42c984ec-0c4e-4189-b6ed-68c71c18d5e8@github.com>
References: <-V_dgQKhDrt1n0Zbk3qNa276jZBO822NlSvUv9AhpEA=.7a23c712-4b01-4aa7-acbe-8f5b5cca9002@github.com>
 <_HrFkS2z3Mk1RKtgVB010rsIx7aTolc_0iMDJox6eDc=.de2d7093-186f-48c0-859f-0769bf372b29@github.com>
 <PoWH2tK2DM68MW-7uXfIh9ArMNJMKaMEC0tZQHDXxZQ=.42c984ec-0c4e-4189-b6ed-68c71c18d5e8@github.com>
Message-ID: <ta-uzgNNMiuDoMmDSFFrIPk31UcBMqGA72dquaRJybY=.8acdd648-4127-46f5-9263-1f28bad54cb4@github.com>

On Mon, 19 Feb 2024 19:26:44 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor update. removed helper function as it caused many comments in the review
>
> src/hotspot/share/code/codeCache.cpp line 181:
> 
>> 179: GrowableArray<CodeHeap*>* CodeCache::_allocable_heaps = new(mtCode) GrowableArray<CodeHeap*> (static_cast<int>(CodeBlobType::All), mtCode);
>> 180: 
>> 181: static bool check_min_size(const char *codeheap, size_t size, size_t required_size) {
> 
> This function never returns `false`.
> `return false` is not reachable because of `vm_exit_during_initialization`.
> We don't need to return anything from it.

ok. thank you

> src/hotspot/share/code/codeCache.cpp line 231:
> 
>> 229:     // MethodNonProfiled heap is always available for segmented code heap
>> 230:     ShouldNotReachHere();
>> 231:   }
> 
> Should we make it an assert?

Ok

> src/hotspot/share/code/codeCache.cpp line 255:
> 
>> 253: 
>> 254:   // Compatibility.
>> 255:   // Override Non-NMethod default size if two other segments are set explicitly
> 
> I don't think we need this comment because it is obvious from IF.

ok

> src/hotspot/share/code/codeCache.cpp line 297:
> 
>> 295: 
>> 296:     vm_exit_during_initialization("Invalid code heap sizes", message);
>> 297:     return;
> 
> `return` is not needed.

right. thanks

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17244#discussion_r1495759721
PR Review Comment: https://git.openjdk.org/jdk/pull/17244#discussion_r1495760549
PR Review Comment: https://git.openjdk.org/jdk/pull/17244#discussion_r1495760913
PR Review Comment: https://git.openjdk.org/jdk/pull/17244#discussion_r1495759279

From bulasevich at openjdk.org  Tue Feb 20 12:57:56 2024
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Tue, 20 Feb 2024 12:57:56 GMT
Subject: RFR: 8311248: Refactor CodeCache::initialize_heaps to simplify
 adding new CodeCache segments [v7]
In-Reply-To: <nUhUPfjEU6k5xT9FHUfi_oaiFmThHBGhWp-IYywSK7I=.0cdefbca-ad66-4174-9eff-c54f06d189f5@github.com>
References: <-V_dgQKhDrt1n0Zbk3qNa276jZBO822NlSvUv9AhpEA=.7a23c712-4b01-4aa7-acbe-8f5b5cca9002@github.com>
 <_HrFkS2z3Mk1RKtgVB010rsIx7aTolc_0iMDJox6eDc=.de2d7093-186f-48c0-859f-0769bf372b29@github.com>
 <nUhUPfjEU6k5xT9FHUfi_oaiFmThHBGhWp-IYywSK7I=.0cdefbca-ad66-4174-9eff-c54f06d189f5@github.com>
Message-ID: <DlmG66emjkIuGbNOb8naO19gTRcWmyB8A9EwDShwApo=.8762be05-65e1-4d47-983b-bb333ef690b3@github.com>

On Mon, 19 Feb 2024 20:32:41 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor update. removed helper function as it caused many comments in the review
>
> src/hotspot/share/code/codeCache.cpp line 312:
> 
>> 310:   // last adjustment: leftovers from page alignment go to non_nmethod segment
>> 311:   non_nmethod.size += non_profiled.size & alignment_mask(min_size);
>> 312:   non_nmethod.size += profiled.size & alignment_mask(min_size);
> 
> Why do we need this code?

Let us assume that with the previous calculations we have this layout:
- {cache_size=18004KB, non_profiled.size = 6002KB, profiled.size = 6002KB, non_nmethod.size=6000KB}

With next align_down for profiled and non_profiled segments, we get:
- {cache_size=18004KB, non_profiled.size = 6000KB, profiled.size = 6000KB, non_nmethod.size=6000KB}

My intention here is to put 4KB into the non_nmethod segment to make the sum of the segment sizes equal to cache_size:
- {cache_size=18004KB, non_profiled.size = 6000KB, profiled.size = 6000KB, non_nmethod.size=6004KB}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17244#discussion_r1495775846

From bulasevich at openjdk.org  Tue Feb 20 13:26:22 2024
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Tue, 20 Feb 2024 13:26:22 GMT
Subject: RFR: 8311248: Refactor CodeCache::initialize_heaps to simplify
 adding new CodeCache segments [v8]
In-Reply-To: <-V_dgQKhDrt1n0Zbk3qNa276jZBO822NlSvUv9AhpEA=.7a23c712-4b01-4aa7-acbe-8f5b5cca9002@github.com>
References: <-V_dgQKhDrt1n0Zbk3qNa276jZBO822NlSvUv9AhpEA=.7a23c712-4b01-4aa7-acbe-8f5b5cca9002@github.com>
Message-ID: <zZYSSyxTm0zfZMjql-liQAWb4UDFTS4FEM0FUN6E_V4=.371ff797-f1dd-489e-8a7e-fcd7a6c62e34@github.com>

> These changes clean up the logic and the code of allocating codecache segments and add more testing of it, to open a door for further optimization of code cache segmentation.  The goal was to keep the behavior as close to the existing behavior as possible, even if it's not quite logical.
> 
> Also, these changes better account for alignment - PrintFlagsFinal shows the final aligned segment sizes, and the segments fill the ReservedCodeCacheSize without gaps caused by alignment.

Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision:

  one another cleanup round

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17244/files
  - new: https://git.openjdk.org/jdk/pull/17244/files/29e78046..d70aa718

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17244&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17244&range=06-07

  Stats: 18 lines in 1 file changed: 4 ins; 6 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/17244.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17244/head:pull/17244

PR: https://git.openjdk.org/jdk/pull/17244

From duke at openjdk.org  Tue Feb 20 14:09:54 2024
From: duke at openjdk.org (Yuri Gaevsky)
Date: Tue, 20 Feb 2024 14:09:54 GMT
Subject: RFR: 8324124: RISC-V: implement _vectorizedMismatch intrinsic
In-Reply-To: <LHoFBLghiIk-dJMOtZSY6Ca3erRXda8a_C1IrboorGU=.51730c35-3e86-4eac-a972-c4f9509ae7f9@github.com>
References: <dxSBhJiLeVkLF8PvHW3MMg69vwXU0VshECCMz5HnhhI=.e0cbda8b-f7f6-44ff-806b-1f21496911be@github.com>
 <LHoFBLghiIk-dJMOtZSY6Ca3erRXda8a_C1IrboorGU=.51730c35-3e86-4eac-a972-c4f9509ae7f9@github.com>
Message-ID: <L0RBLvCLxpIXkSHyDRYXgWctmGIWxrOXi6hCy7bkcj8=.5c982427-029f-46e5-a373-29a4389c6aab@github.com>

On Tue, 20 Feb 2024 11:11:33 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hello All,
>> 
>> Please review these changes to enable the __vectorizedMismatch_ intrinsic on RISC-V platform with RVV instructions supported.
>> 
>> Thank you,
>> -Yuri Gaevsky
>> 
>> **Correctness checks:**
>>   hotspot/jtreg/compiler/{intrinsic/c1/c2}/ under QEMU-8.1 with RVV v1.0.0 and -XX:TieredStopAtLevel=1/2/3/4.
>
> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 4256:
> 
>> 4254: 
>> 4255:   bind(VEC_LOOP);
>> 4256:   vsetvli(t0, cnt, Assembler::e8, Assembler::m8);
> 
> I see `e8` element size is always used here for all cases. Maybe we could make use of some larger element size (according to `log2_array_indxscale` input) to improve the code? Especiall, the part for handling `idx`.

The ```e8``` is used here to avoid "unaligned-access-penalties" because:
(a)
[jdk.internal.util.ArraysSupport::vectorizedMismatch()](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java#L92) doesn't require that the given arrays are aligned to the size of array elements:

     * <p>The given offsets, in bytes, need not be aligned according to the
     * given log<sub>2</sub> size the array elements.  More specifically, an
     * offset modulus the size need not be zero.

and
(b) RVV specification states:

8. Vector Memory Alignment Constraints
...
If an element accessed by a vector memory instruction is not naturally aligned to the size of the element, either the element
is transferred successfully or an address misaligned exception is raised on that element.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17750#discussion_r1495881809

From duke at openjdk.org  Tue Feb 20 14:12:54 2024
From: duke at openjdk.org (Yuri Gaevsky)
Date: Tue, 20 Feb 2024 14:12:54 GMT
Subject: RFR: 8324124: RISC-V: implement _vectorizedMismatch intrinsic
In-Reply-To: <L0RBLvCLxpIXkSHyDRYXgWctmGIWxrOXi6hCy7bkcj8=.5c982427-029f-46e5-a373-29a4389c6aab@github.com>
References: <dxSBhJiLeVkLF8PvHW3MMg69vwXU0VshECCMz5HnhhI=.e0cbda8b-f7f6-44ff-806b-1f21496911be@github.com>
 <LHoFBLghiIk-dJMOtZSY6Ca3erRXda8a_C1IrboorGU=.51730c35-3e86-4eac-a972-c4f9509ae7f9@github.com>
 <L0RBLvCLxpIXkSHyDRYXgWctmGIWxrOXi6hCy7bkcj8=.5c982427-029f-46e5-a373-29a4389c6aab@github.com>
Message-ID: <Goo36L2AU57vuroO5D-NKRlCB8LPtigx5eL7FAnCn00=.ac6a8f18-417c-43fd-b52b-26053f72f6ec@github.com>

On Tue, 20 Feb 2024 14:07:04 GMT, Yuri Gaevsky <duke at openjdk.org> wrote:

>> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 4256:
>> 
>>> 4254: 
>>> 4255:   bind(VEC_LOOP);
>>> 4256:   vsetvli(t0, cnt, Assembler::e8, Assembler::m8);
>> 
>> I see `e8` element size is always used here for all cases. Maybe we could make use of some larger element size (according to `log2_array_indxscale` input) to improve the code? Especiall, the part for handling `idx`.
>
> The ```e8``` is used here to avoid "unaligned-access-penalties" because:
> (a)
> [jdk.internal.util.ArraysSupport::vectorizedMismatch()](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java#L92) doesn't require that the given arrays are aligned to the size of array elements:
> 
>      * <p>The given offsets, in bytes, need not be aligned according to the
>      * given log<sub>2</sub> size the array elements.  More specifically, an
>      * offset modulus the size need not be zero.
> 
> and
> (b) RVV specification states:
> 
> 8. Vector Memory Alignment Constraints
> ...
> If an element accessed by a vector memory instruction is not naturally aligned to the size of the element, either the element
> is transferred successfully or an address misaligned exception is raised on that element.

Please also notice that the method's java code also use `Unsafe::getLongUnaligned/getIntUnaligned` for accesses.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17750#discussion_r1495886712

From rehn at openjdk.org  Tue Feb 20 14:27:54 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 20 Feb 2024 14:27:54 GMT
Subject: RFR: 8326235: RISC-V: Size CodeCache for short calls encoding
In-Reply-To: <BsTqc_mXzoF8wj4xed4mfRVdCnBVF0RSDmYtIuZL2xI=.7fb7b03f-55d6-429c-ab70-15324d055a7e@github.com>
References: <MHf3cpwm83ITBdp9IbzDbEvWjye3zKRLpxO0cCV9OVQ=.fc534a38-6d2b-4fb2-8a2f-b9b498dc1414@github.com>
 <BsTqc_mXzoF8wj4xed4mfRVdCnBVF0RSDmYtIuZL2xI=.7fb7b03f-55d6-429c-ab70-15324d055a7e@github.com>
Message-ID: <dSaTSUWNyHnckVVgPpmpKvOcrmS3WqKxK_mIOlUlXDk=.3db1776e-ce9c-4f22-85f5-f6a41f8b5384@github.com>

On Tue, 20 Feb 2024 11:06:26 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Thanks for fixing this potential risk. We will be more certain in code emitted for a cc -> cc call. In fact, I was also planning to do a similar fix for this very uncommon case :-)

Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17924#issuecomment-1954326324

From kvn at openjdk.org  Tue Feb 20 17:01:55 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 20 Feb 2024 17:01:55 GMT
Subject: RFR: 8325095: C2: bailout message broken: ResourceArea allocated
 string used after free [v2]
In-Reply-To: <iqVK2jP6-y3NweZYd_Y6Eo39GUH9hf8gFugp8aq3-dw=.54a735a9-9cf2-411d-89aa-19dcbef22937@github.com>
References: <8Bl6JSxb-fd1xAsKOMzBakRFuruoqJykP7JEn57k6qY=.717f89af-2aa7-439b-afd1-768dd39f51da@github.com>
 <iqVK2jP6-y3NweZYd_Y6Eo39GUH9hf8gFugp8aq3-dw=.54a735a9-9cf2-411d-89aa-19dcbef22937@github.com>
Message-ID: <fdijEO4HOMxS2z2kj0PKvK9HfGBjSk4MqjMZVAS-MDY=.f8715719-f21c-4ed4-a3f5-7fee830b667b@github.com>

On Fri, 16 Feb 2024 07:18:09 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> **Problem**
>> Bailout `failure_reason` strings used to be either `nullptr` or a static string. But with [JDK-8303951](https://bugs.openjdk.org/browse/JDK-8303951) I had introduced dynamic strings (e.g. formatted using `stringStream::as_string()`). These dynamic strings were ResourceArea allocated, and have a very limited life-span, i.e. withing the most recent ResourceMark scope. The pointer is passed to `Compile::_failure_reason`, which already might leave that ResourceMark scope, and the pointer is invalid. And then the pointer is further passed to `ciEnv::_failure_reason`. And finally, it even gets passed up to `CompileBroker::invoke_compiler_on_method`. When the string is finally printed for the bailout message, we already left original `ResourceMark` scope, and also the `Compile` and `ciEnv` scopes. The pointer now points to basically random data.
>> 
>> **Solution**
>> Whenever a string is passed to an outer scope, I make a CHeap copy, and the outer scope is the owner of that copy.
>> This way every scope is the owner of its own copy, and can allocate and deallocate according to its own strategy safely.
>> 
>> I introduced a utility class `CHeapStringHolder`:
>>  - `set`: make local copy on CHeap.
>>  - `clear`: free local copy. We before `set`, and in the destructor. Thus, when the holder goes out of scope, the memory is automatically freed.
>> 
>> We have these 4 scopes:
>> - `ResourceMark`: It allocates from `ResourcArea`, and deallocation is taken care at the end of the ResourceMark scope.
>> - `Compile`: We turn the `_failure_reason` from a `char*` into a `CHeapStringHolder`. We set `_failure_reason` while the `ResourceMark` is live.
>> - `ciEnv`: We turn the `_failure_reason` from a `char*` into a `CHeapStringHolder`. We set `_failure_reason` while `Compile` is live.
>> - `CompileTask`: We used to just set `failure_reason`, which assumes that the string is static or elsewhere managed. Now I use pattern available in other places of `CompileBroker::invoke_compiler_on_method`: duplicate the string with `os::strdup` from some other scope, and set `reason_on_C_heap = true`, which means that we are the owner of that copy, and are responsible for freeing it later. Not sure if that is a nice pattern, but I don't want to refactor that code and it does what I need it to do.
>
> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove OrderAccess::storestore() bc single threaded only

UL should be done in separate RFE. Current logging (`log()->elem()`) is for `-XX:+LogCompilation` output into file. UL is for terminal.
UL should report immediately, the same way we do for `-XX:+LogCompilation`.

Different failures are recorded in ciEnv and Compiler, only after compilation is finish we record compiler's failure in ciEnv.
There is also ciTypefFow failure which recorded in Compiler.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17710#issuecomment-1954648120

From aboldtch at openjdk.org  Tue Feb 20 18:19:16 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 20 Feb 2024 18:19:16 GMT
Subject: RFR: 8319901: Recursive lightweight locking: ppc64le implementation
Message-ID: <3LduAyBU7SzwJawH73jO5cAjVr5I0HJzs8y_jO9r3N4=.42388751-25b0-43fe-97c3-c4f95334bcfc@github.com>

Draft implementation of recursive lightweight JDK-8319796 for ppc64le.

Porters feel free to discard this and implement something from scratch, take this initial draft and run with it, or send patches to me and if you want me to drive the PR.

Some notes:
ppc64le deviates from the other ports, it shares it C2 locking code with the native call wrapper. This draft unifies the behavior across the ports by using the C1/interpreter locking for native call wrapper. If it is important to have a fast path for the inflated monitor case for native call wrapper, it could be done without having it share its implementation with C2. 
It would also be possible to change this behavior on all ports (share the C2 code), as I believe the C2 assumptions always hold for the native call wrapper, the monitor exit and monitor enter will be balanced and structured.

-------------

Commit messages:
 - TheRealMDoerr: Cleanups
 - Apply patch
 - Unify ldx usage between unlock and lock.
 - Unify ldx usage between unlock and lock
 - Fix usage of R0 in MacroAssembler::compiler_fast_lock_lightweight_object
 - Revert "Avoid R0 as input to compiler_fast_*"
 - Fix usage of R0 in MacroAssembler::lightweight_lock
 - Avoid R0 as input to compiler_fast_*
 - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8319901
 - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319901
 - ... and 39 more: https://git.openjdk.org/jdk/compare/71ff2d71...6eec9a2e

Changes: https://git.openjdk.org/jdk/pull/16611/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16611&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8319901
  Stats: 509 lines in 9 files changed: 409 ins; 65 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/16611.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16611/head:pull/16611

PR: https://git.openjdk.org/jdk/pull/16611

From mdoerr at openjdk.org  Tue Feb 20 18:19:17 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 20 Feb 2024 18:19:17 GMT
Subject: RFR: 8319901: Recursive lightweight locking: ppc64le
 implementation
In-Reply-To: <3LduAyBU7SzwJawH73jO5cAjVr5I0HJzs8y_jO9r3N4=.42388751-25b0-43fe-97c3-c4f95334bcfc@github.com>
References: <3LduAyBU7SzwJawH73jO5cAjVr5I0HJzs8y_jO9r3N4=.42388751-25b0-43fe-97c3-c4f95334bcfc@github.com>
Message-ID: <nFROEF8HI0J0Pjdr0YOTIqhF3WTXcuwNqkrh_qAFac8=.ed22838f-1cf9-4718-8cbe-0eeebf6733fd@github.com>

On Fri, 10 Nov 2023 13:21:58 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Draft implementation of recursive lightweight JDK-8319796 for ppc64le.
> 
> Porters feel free to discard this and implement something from scratch, take this initial draft and run with it, or send patches to me and if you want me to drive the PR.
> 
> Some notes:
> ppc64le deviates from the other ports, it shares it C2 locking code with the native call wrapper. This draft unifies the behavior across the ports by using the C1/interpreter locking for native call wrapper. If it is important to have a fast path for the inflated monitor case for native call wrapper, it could be done without having it share its implementation with C2. 
> It would also be possible to change this behavior on all ports (share the C2 code), as I believe the C2 assumptions always hold for the native call wrapper, the monitor exit and monitor enter will be balanced and structured.

Looks great! I only have some questions and suggestions.

Tests have passed. I think this PR can be set to open in order to get reviews. I have some minor suggestions, but it looks correct to me.
Please add me as contributor.

Nice! This is the biggest PPC64 change from Oracle I've ever seen :-)
My first impression is pretty good. I'll take a closer look when I find more time.
I guess you have created new functions because the old ones (for legacy locking) are supposed to get removed at some point of time?
I need to think about removing the monitor locking from the native wrapper. That may cause a performance regression if the locks are contended. Is there a specific reason to change that or just to make it more similar to some other platforms?
Note that s390 does it like PPC64.

Thanks for rebasing it! We noticed that the register usage is invalid at some points. Using R0 doesn't work for memory base addresses or as source operand for addi instructions. It should work like this:

diff --git a/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp b/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp
index 6a7428ebd04..6f131467595 100644
--- a/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp
+++ b/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp
@@ -2471,7 +2471,7 @@ void MacroAssembler::compiler_fast_lock_lightweight_object(ConditionRegister fla
   }
 
   const Register mark = tmp1;
-  const Register t = tmp3;
+  const Register t = tmp3; // Usage of R0 allowed!
 
   { // Lightweight locking
 
@@ -2489,8 +2489,8 @@ void MacroAssembler::compiler_fast_lock_lightweight_object(ConditionRegister fla
     // when the lock stack is empty because of the _bad_oop_sentinel field.
 
     // Check if recursive.
-    subi(t, top, oopSize);
-    ldx(t, t, R16_thread);
+    subi(tmp1, top, oopSize);
+    ldx(t, tmp1, R16_thread);
     cmpd(flag, obj, t);
     beq(flag, push);
 
@@ -2541,13 +2541,13 @@ void MacroAssembler::compiler_fast_lock_lightweight_object(ConditionRegister fla
     bne(flag, slow_path);
 
     // Recursive.
-    ld(t, in_bytes(ObjectMonitor::recursions_offset() - ObjectMonitor::owner_offset()), owner_addr);
-    addi(t, t, 1);
-    std(t, in_bytes(ObjectMonitor::recursions_offset() - ObjectMonitor::owner_offset()), owner_addr);
+    ld(tmp1, in_bytes(ObjectMonitor::recursions_offset() - ObjectMonitor::owner_offset()), owner_addr);
+    addi(tmp1, tmp1, 1);
+    std(tmp1, in_bytes(ObjectMonitor::recursions_offset() - ObjectMonitor::owner_offset()), owner_addr);
   }
 
   bind(locked);
-  inc_held_monitor_count(t);
+  inc_held_monitor_count(tmp1);
 
 #ifdef ASSERT
   // Check that locked label is reached with flags == EQ.
@@ -4361,8 +4361,8 @@ void MacroAssembler::lightweight_lock(Register obj, Register t1, Register t2, La
   // when the lock stack is empty because of the _bad_oop_sentinel field.
 
   // Check for recursion.
-  subi(t, top, oopSize);
-  ldx(t, t, R16_thread);
+  subi(t2, top, oopSize);
+  ldx(t, t2, R16_thread);
   cmpd(CCR0, obj, t);
   beq(CCR0, push);
 

We may want to do further improvements to make register usage less confusing. Please take a look!

Your update doesn't solve all the problems and I'd prefer to keep the `box` free in case we need it again. I suggest using my patch instead.
If you want to minimize register reusage, you can change `ldx(t, t, R16_thread);` to `ldx(t, R16_thread, t);` which is equivalent and can be used with R0.
What I do like is not to pass R0 explicitly any more.

You forgot to turn the ldx operands in `MacroAssembler::lightweight_lock`. I suggest making them all consistent (regardless if they use R0 or not). I believe that is the preferred form by the ISA, anyway.

diff --git a/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp b/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp
index 05bb0f59605..c28f1712abd 100644
--- a/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp
+++ b/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp
@@ -2490,7 +2490,7 @@ void MacroAssembler::compiler_fast_lock_lightweight_object(ConditionRegister fla
 
     // Check if recursive.
     subi(t, top, oopSize);
-    ldx(t, t, R16_thread);
+    ldx(t, R16_thread, t);
     cmpd(flag, obj, t);
     beq(flag, push);
 
@@ -2587,7 +2587,7 @@ void MacroAssembler::compiler_fast_unlock_lightweight_object(ConditionRegister f
     // Check if obj is top of lock-stack.
     lwz(top, in_bytes(JavaThread::lock_stack_top_offset()), R16_thread);
     subi(top, top, oopSize);
-    ldx(t, top, R16_thread);
+    ldx(t, R16_thread, top);
     cmpd(flag, obj, t);
     // Top of lock stack was not obj. Must be monitor.
     bne(flag, inflated_load_monitor);
@@ -2602,7 +2602,7 @@ void MacroAssembler::compiler_fast_unlock_lightweight_object(ConditionRegister f
 
     // Check if recursive.
     subi(t, top, oopSize);
-    ldx(t, t, R16_thread);
+    ldx(t, R16_thread, t);
     cmpd(flag, obj, t);
     beq(flag, unlocked);
 
@@ -2650,7 +2650,7 @@ void MacroAssembler::compiler_fast_unlock_lightweight_object(ConditionRegister f
     subi(top, top, oopSize);
     cmplwi(CCR0, top, in_bytes(JavaThread::lock_stack_base_offset()));
     blt(CCR0, check_done);
-    ldx(t, top, R16_thread);
+    ldx(t, R16_thread, top);
     cmpd(flag, obj, t);
     bne(flag, inflated);
     stop("Fast Unlock lock on stack");
@@ -4362,7 +4362,7 @@ void MacroAssembler::lightweight_lock(Register obj, Register t1, Register t2, La
 
   // Check for recursion.
   subi(t, top, oopSize);
-  ldx(t, t, R16_thread);
+  ldx(t, R16_thread, t);
   cmpd(CCR0, obj, t);
   beq(CCR0, push);

Ok, thanks for the updates! I'll rerun tests.

Regarding the C2 code for Lilliput, we may consider implementing it in graph kit. That would avoid platform specific C2 code and potentially enable better optimization ("shorten branches"). I guess that has not yet been discussed.

We don't need to kill `box`. I've also made the stdx instructions consistent with ldx:

diff --git a/src/hotspot/cpu/ppc/c1_MacroAssembler_ppc.cpp b/src/hotspot/cpu/ppc/c1_MacroAssembler_ppc.cpp
index 8e50a5c7aab..97c4adae321 100644
--- a/src/hotspot/cpu/ppc/c1_MacroAssembler_ppc.cpp
+++ b/src/hotspot/cpu/ppc/c1_MacroAssembler_ppc.cpp
@@ -155,7 +155,7 @@ void C1_MacroAssembler::unlock_object(Register Rmark, Register Roop, Register Rb
   verify_oop(Roop, FILE_AND_LINE);
 
   if (LockingMode == LM_LIGHTWEIGHT) {
-    lightweight_unlock(Roop, Rmark, Rbox, slow_int);
+    lightweight_unlock(Roop, Rmark, slow_int);
   } else if (LockingMode == LM_LEGACY) {
     // Check if it is still a light weight lock, this is is true if we see
     // the stack address of the basicLock in the markWord of the object.
diff --git a/src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp b/src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp
index 9eb5c15f390..94ef1b3c9d2 100644
--- a/src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp
+++ b/src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp
@@ -1114,7 +1114,7 @@ void InterpreterMacroAssembler::unlock_object(Register monitor) {
     ld(object, in_bytes(BasicObjectLock::obj_offset()), monitor);
 
     if (LockingMode == LM_LIGHTWEIGHT) {
-      lightweight_unlock(object, header, current_header, slow_case);
+      lightweight_unlock(object, header, slow_case);
     } else {
       addi(object_mark_addr, object, oopDesc::mark_offset_in_bytes());
 
diff --git a/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp b/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp
index 6a0a8f0951e..d94fae5b42e 100644
--- a/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp
+++ b/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp
@@ -2509,7 +2509,7 @@ void MacroAssembler::compiler_fast_lock_lightweight_object(ConditionRegister fla
 
     bind(push);
     // After successful lock, push object on lock-stack.
-    stdx(obj, top, R16_thread);
+    stdx(obj, R16_thread, top);
     addi(top, top, oopSize);
     stw(top, in_bytes(JavaThread::lock_stack_top_offset()), R16_thread);
     b(locked);
@@ -2594,7 +2594,7 @@ void MacroAssembler::compiler_fast_unlock_lightweight_object(ConditionRegister f
 
     // Pop lock-stack.
     DEBUG_ONLY(li(t, 0);)
-    DEBUG_ONLY(stdx(t, top, R16_thread);)
+    DEBUG_ONLY(stdx(t, R16_thread, top);)
     stw(top, in_bytes(JavaThread::lock_stack_top_offset()), R16_thread);
 
     // The underflow check is elided. The recursive check will always fail
@@ -2628,7 +2628,7 @@ void MacroAssembler::compiler_fast_unlock_lightweight_object(ConditionRegister f
 
     bind(push_and_slow);
     // Restore lock-stack and handle the unlock in runtime.
-    DEBUG_ONLY(stdx(obj, top, R16_thread);)
+    DEBUG_ONLY(stdx(obj, R16_thread, top);)
     addi(top, top, oopSize);
     stw(top, in_bytes(JavaThread::lock_stack_top_offset()), R16_thread);
     b(slow_path);
@@ -4377,7 +4377,7 @@ void MacroAssembler::lightweight_lock(Register obj, Register t1, Register t2, La
 
   bind(push);
   // After successful lock, push object on lock-stack
-  stdx(obj, top, R16_thread);
+  stdx(obj, R16_thread, top);
   addi(top, top, oopSize);
   stw(top, in_bytes(JavaThread::lock_stack_top_offset()), R16_thread);
 }
@@ -4385,10 +4385,10 @@ void MacroAssembler::lightweight_lock(Register obj, Register t1, Register t2, La
 // Implements lightweight-unlocking.
 //
 // - obj: the object to be unlocked
-//  - t1, t2: temporary register
-void MacroAssembler::lightweight_unlock(Register obj, Register t1, Register t2, Label& slow) {
+//  - t1: temporary register
+void MacroAssembler::lightweight_unlock(Register obj, Register t1, Label& slow) {
   assert(LockingMode == LM_LIGHTWEIGHT, "only used with new lightweight locking");
-  assert_different_registers(obj, t1, t2);
+  assert_different_registers(obj, t1, R0);
 
 #ifdef ASSERT
   {
@@ -4408,8 +4408,8 @@ void MacroAssembler::lightweight_unlock(Register obj, Register t1, Register t2,
 
   Label unlocked, push_and_slow;
   const Register top = t1;
-  const Register mark = t2;
-  Register t = t2;
+  const Register mark = R0;
+  Register t = R0;
 
   // Check if obj is top of lock-stack.
   lwz(top, in_bytes(JavaThread::lock_stack_top_offset()), R16_thread);
@@ -4420,7 +4420,7 @@ void MacroAssembler::lightweight_unlock(Register obj, Register t1, Register t2,
 
   // Pop lock-stack.
   DEBUG_ONLY(li(t, 0);)
-  DEBUG_ONLY(stdx(t, top, R16_thread);)
+  DEBUG_ONLY(stdx(t, R16_thread, top);)
   stw(top, in_bytes(JavaThread::lock_stack_top_offset()), R16_thread);
 
   // The underflow check is elided. The recursive check will always fail
@@ -4450,16 +4450,14 @@ void MacroAssembler::lightweight_unlock(Register obj, Register t1, Register t2,
 #endif
 
   // Try to unlock. Transition lock bits 0b00 => 0b01
-  atomically_flip_locked_state(/* is_unlock */ true, obj, mark, push_and_slow, MacroAssembler::MemBarRel);
+  atomically_flip_locked_state(/* is_unlock */ true, obj, t, push_and_slow, MacroAssembler::MemBarRel);
   b(unlocked);
 
   bind(push_and_slow);
-  // Use mark as tmp
-  t = mark;
 
   // Restore lock-stack and handle the unlock in runtime.
   lwz(top, in_bytes(JavaThread::lock_stack_top_offset()), R16_thread);
-  DEBUG_ONLY(stdx(obj, top, R16_thread);)
+  DEBUG_ONLY(stdx(obj, R16_thread, top);)
   addi(top, top, oopSize);
   stw(top, in_bytes(JavaThread::lock_stack_top_offset()), R16_thread);
   b(slow);
diff --git a/src/hotspot/cpu/ppc/macroAssembler_ppc.hpp b/src/hotspot/cpu/ppc/macroAssembler_ppc.hpp
index 81d64bdb6a8..92db8a86b42 100644
--- a/src/hotspot/cpu/ppc/macroAssembler_ppc.hpp
+++ b/src/hotspot/cpu/ppc/macroAssembler_ppc.hpp
@@ -616,7 +616,7 @@ class MacroAssembler: public Assembler {
   void dec_held_monitor_count(Register tmp);
   void atomically_flip_locked_state(bool is_unlock, Register obj, Register tmp, Label& failed, int semantics);
   void lightweight_lock(Register obj, Register t1, Register t2, Label& slow);
-  void lightweight_unlock(Register obj, Register t1, Register t2, Label& slow);
+  void lightweight_unlock(Register obj, Register t1, Label& slow);
 
   // allocation (for C1)
   void tlab_allocate(

Thanks! I'll rerun tests.

src/hotspot/cpu/ppc/c1_MacroAssembler_ppc.cpp line 181:

> 179: 
> 180:   if (LockingMode == LM_LIGHTWEIGHT) {
> 181:     lightweight_unlock(Roop, Rmark, Rbox, slow_int);

I think using `Rbox` as temp register is not legal. `Runtime1::monitorexit` receives it as argument, so it must not be killed. I'll check if we can live with 1 temp reg less.

src/hotspot/cpu/ppc/c2_MacroAssembler_ppc.cpp line 32:

> 30: #include "opto/intrinsicnode.hpp"
> 31: #include "register_ppc.hpp"
> 32: #include "runtime/objectMonitor.hpp"

We're not using any of these new includes.

Actually, we don't need to touch this file at all because it only delegates. If you want to keep it, ok.

src/hotspot/cpu/ppc/c2_MacroAssembler_ppc.cpp line 45:

> 43: void C2_MacroAssembler::fast_lock_lightweight(ConditionRegister flag, Register obj, Register box,
> 44:                                               Register tmp1, Register tmp2, Register tmp3) {
> 45:   // TODO: Current implementation does not use box, consider removing a TEMP and use box instead.

The `box` is only used by legacy locking for the displaced mark word. I think the related code can get cleaned up (including removal of the argument and the extra stack slot) when legacy locking gets removed.

src/hotspot/cpu/ppc/c2_MacroAssembler_ppc.cpp line 51:

> 49: void C2_MacroAssembler::fast_unlock_lightweight(ConditionRegister flag, Register obj, Register box,
> 50:                                                 Register tmp1, Register tmp2, Register tmp3) {
> 51:   // TODO: Current implementation does not use box, consider removing a TEMP and use box instead.

Same here.

src/hotspot/cpu/ppc/c2_MacroAssembler_ppc.cpp line 79:

> 77:     bgt(flag, slow_path);
> 78: 
> 79:     // Check if recursive.

Would be good to mention the `_bad_oop_sentinel` in the comment.

src/hotspot/cpu/ppc/c2_MacroAssembler_ppc.cpp line 140:

> 138:   inc_held_monitor_count(t);
> 139: 
> 140:   #ifdef ASSERT

Whitespaces.

src/hotspot/cpu/ppc/c2_MacroAssembler_ppc.cpp line 202:

> 200:     bne(CCR0, inflated);
> 201: 
> 202:   #ifdef ASSERT

Whitespaces.

src/hotspot/cpu/ppc/macroAssembler_ppc.cpp line 50:

> 48: #include "runtime/stubRoutines.hpp"
> 49: #include "runtime/vm_version.hpp"
> 50: #include "utilities/globalDefinitions.hpp"

Done by IDE? Added inclusions not needed.

src/hotspot/cpu/ppc/macroAssembler_ppc.cpp line 2190:

> 2188:   assert(LockingMode != LM_LIGHTWEIGHT, "uses fast_lock_lightweight");
> 2189:   assert_different_registers(oop, box, temp, displaced_header, current_header);
> 2190:   assert(LockingMode != LM_LIGHTWEIGHT || flag == CCR0, "bad condition register");

This assertion is redundant, now.

src/hotspot/cpu/ppc/macroAssembler_ppc.cpp line 2301:

> 2299:   assert(LockingMode != LM_LIGHTWEIGHT, "uses fast_unlock_lightweight");
> 2300:   assert_different_registers(oop, box, temp, displaced_header, current_header);
> 2301:   assert(LockingMode != LM_LIGHTWEIGHT || flag == CCR0, "bad condition register");

Same here.

src/hotspot/cpu/ppc/ppc.ad line 12189:

> 12187:   ins_encode %{
> 12188:     __ fast_lock_lightweight($crx$$CondRegister, $oop$$Register, $box$$Register,
> 12189:                              $tmp1$$Register, $tmp2$$Register, /*tmp3*/ R0);

You could avoid duplicating the nodes and distinguish the locking modes here if the register usage is the same.

src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp line 51:

> 49: #include "runtime/vframeArray.hpp"
> 50: #include "utilities/align.hpp"
> 51: #include "utilities/globalDefinitions.hpp"

Was this added by your IDE? We usually don't include this one everywhere explicitly.

src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp line 2478:

> 2476:       __ compiler_fast_lock_object(CCR0, r_oop, r_box, r_temp_1, r_temp_2, r_temp_3);
> 2477:       __ beq(CCR0, locked);
> 2478:     }

I appreciate your effort to make it more similar among all platforms. However, I think that using the C2 version is better because the native wrapper is the highest tier. Can we keep it as before with this PR and use a separate issue to clean it up for all platforms?
That will allow us to check performance impact individually. Mixing 2 performance related changes is not ideal.

-------------

PR Review: https://git.openjdk.org/jdk/pull/16611#pullrequestreview-1727358085
PR Review: https://git.openjdk.org/jdk/pull/16611#pullrequestreview-1889653803
PR Comment: https://git.openjdk.org/jdk/pull/16611#issuecomment-1806466004
PR Comment: https://git.openjdk.org/jdk/pull/16611#issuecomment-1945402654
PR Comment: https://git.openjdk.org/jdk/pull/16611#issuecomment-1945673628
PR Comment: https://git.openjdk.org/jdk/pull/16611#issuecomment-1946498366
PR Comment: https://git.openjdk.org/jdk/pull/16611#issuecomment-1948071736
PR Comment: https://git.openjdk.org/jdk/pull/16611#issuecomment-1951962249
PR Comment: https://git.openjdk.org/jdk/pull/16611#issuecomment-1952533067
PR Review Comment: https://git.openjdk.org/jdk/pull/16611#discussion_r1494141543
PR Review Comment: https://git.openjdk.org/jdk/pull/16611#discussion_r1495346725
PR Review Comment: https://git.openjdk.org/jdk/pull/16611#discussion_r1391140394
PR Review Comment: https://git.openjdk.org/jdk/pull/16611#discussion_r1495346176
PR Review Comment: https://git.openjdk.org/jdk/pull/16611#discussion_r1391143014
PR Review Comment: https://git.openjdk.org/jdk/pull/16611#discussion_r1391159178
PR Review Comment: https://git.openjdk.org/jdk/pull/16611#discussion_r1391159561
PR Review Comment: https://git.openjdk.org/jdk/pull/16611#discussion_r1495356358
PR Review Comment: https://git.openjdk.org/jdk/pull/16611#discussion_r1495359317
PR Review Comment: https://git.openjdk.org/jdk/pull/16611#discussion_r1495359725
PR Review Comment: https://git.openjdk.org/jdk/pull/16611#discussion_r1391177674
PR Review Comment: https://git.openjdk.org/jdk/pull/16611#discussion_r1495353922
PR Review Comment: https://git.openjdk.org/jdk/pull/16611#discussion_r1391184003

From amitkumar at openjdk.org  Tue Feb 20 18:19:18 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Tue, 20 Feb 2024 18:19:18 GMT
Subject: RFR: 8319901: Recursive lightweight locking: ppc64le
 implementation
In-Reply-To: <nFROEF8HI0J0Pjdr0YOTIqhF3WTXcuwNqkrh_qAFac8=.ed22838f-1cf9-4718-8cbe-0eeebf6733fd@github.com>
References: <3LduAyBU7SzwJawH73jO5cAjVr5I0HJzs8y_jO9r3N4=.42388751-25b0-43fe-97c3-c4f95334bcfc@github.com>
 <nFROEF8HI0J0Pjdr0YOTIqhF3WTXcuwNqkrh_qAFac8=.ed22838f-1cf9-4718-8cbe-0eeebf6733fd@github.com>
Message-ID: <5MS3_s3eGVy2GvPQ9ocP4tdNkbhArryBFkEHNkMjmfo=.098441a4-8b5c-4d5e-9956-f8e284916617@github.com>

On Fri, 10 Nov 2023 21:37:49 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>Note that s390 does it like PPC64.

Just to know, should we expect similar changes for s390x as well ?? I do not see JBS issue for s390.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16611#issuecomment-1807522318

From aboldtch at openjdk.org  Tue Feb 20 18:19:18 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 20 Feb 2024 18:19:18 GMT
Subject: RFR: 8319901: Recursive lightweight locking: ppc64le
 implementation
In-Reply-To: <nFROEF8HI0J0Pjdr0YOTIqhF3WTXcuwNqkrh_qAFac8=.ed22838f-1cf9-4718-8cbe-0eeebf6733fd@github.com>
References: <3LduAyBU7SzwJawH73jO5cAjVr5I0HJzs8y_jO9r3N4=.42388751-25b0-43fe-97c3-c4f95334bcfc@github.com>
 <nFROEF8HI0J0Pjdr0YOTIqhF3WTXcuwNqkrh_qAFac8=.ed22838f-1cf9-4718-8cbe-0eeebf6733fd@github.com>
Message-ID: <GQ-gM8QDWVryN6HnerwLhQYbKq9qyw_2t4Oe5pdZpME=.2e26cf8e-e07b-4cec-a973-62f85452d42a@github.com>

On Fri, 10 Nov 2023 21:37:49 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> guess you have created new functions because the old ones (for legacy locking) are supposed to get removed at some point of time? 

Yes. Also the reduce the clutter. It became overly restrictive to have one place handle all locking modes. (x86 was the worst which has {32bit, 64bt} x {LM_MONITOR, LM_LEGACY, LM_LIGHTWEIGHT} x {RTM_OFF, RMT_ON, RTM_ON + RMT_stack}).

> need to think about removing the monitor locking from the native wrapper. That may cause a performance regression if the locks are contended. Is there a specific reason to change that or just to make it more similar to some other platforms? Note that s390 does it like PPC64.

I thought about this as I was motivating what I did in the draft. And I believe that it would be correct to also use the C2 implementation for the native wrapper. The difference between the C2 and the shared code is wether it can handle unstructured (monitorenter A, monitorenter B, monitorexit A, monitorexit B) type of scenarios. As the native wrapper always emits a structured monitorenter, monitorexit pair and any synchronisation in the native must either be inflated (JNI synchronisation) or balanced (java upcalls), there should always be the case that fast_unlock does not see the object on the top of its lock stack.

Have to think about this some more, but it might be that all the other platforms should adopt this approach as well.

Also not that this is about supporting inflated monitors without going into the runtime. Not for handle contended locking, for contended locking the current ppc implementation always go into the runtime.

AFAICT only x86_64 does anything when it comes to contended locking. Where it tries to handoff the lock without going into the runtime.

> Your update doesn't solve all the problems and I'd prefer to keep the `box` free in case we need it again. I suggest using my patch instead. If you want to minimize register reusage, you can change `ldx(t, t, R16_thread);` to `ldx(t, R16_thread, t);` which is equivalent and can be used with R0. What I do like is not to pass R0 explicitly any more.

Right, I missed the `MacroAssembler::lightweight_lock` part of the diff. 

I'll revert and go with yours for now. It does start to mix styles. Also given that R0 behaves differently than other registers, maybe it should not be aliased. (Or made more clear that it alias R0)

If you want to go over and find a unified style here which fits better with how the PPC port usually does it, it would be appreciated.

> You forgot to turn the ldx operands in `MacroAssembler::lightweight_lock`. I suggest making them all consistent (regardless if they use R0 or not). I believe that is the preferred form by the ISA, anyway.

The lock changes were already pushed in an earlier commit (60fc40f8ca53be5f12700f33816419142e7faaa9). Unified the unlock `ldx` as well. 

> Are you planning to do more for Lilliput on PPC64?

I am working on creating a actionable sub-task list of work items for Locking and ObjectMonitors in Lilliput. Extending supports to other ports will be on this list. It will not be the main priority I will be working on, however for ports which already have a recursive lightweight locking implementation, only the ObjectMonitor cache needs to be implemented, which is a fairly simple adaption.  I will get to it if time permits and no one gets to it first. So short answer maybe.

> src/hotspot/cpu/ppc/c2_MacroAssembler_ppc.cpp line 79:
> 
>> 77:     bgt(flag, slow_path);
>> 78: 
>> 79:     // Check if recursive.
> 
> Would be good to mention the `_bad_oop_sentinel` in the comment.

Done.

> src/hotspot/cpu/ppc/c2_MacroAssembler_ppc.cpp line 140:
> 
>> 138:   inc_held_monitor_count(t);
>> 139: 
>> 140:   #ifdef ASSERT
> 
> Whitespaces.

Done.

> src/hotspot/cpu/ppc/c2_MacroAssembler_ppc.cpp line 202:
> 
>> 200:     bne(CCR0, inflated);
>> 201: 
>> 202:   #ifdef ASSERT
> 
> Whitespaces.

Done.

> src/hotspot/cpu/ppc/ppc.ad line 12189:
> 
>> 12187:   ins_encode %{
>> 12188:     __ fast_lock_lightweight($crx$$CondRegister, $oop$$Register, $box$$Register,
>> 12189:                              $tmp1$$Register, $tmp2$$Register, /*tmp3*/ R0);
> 
> You could avoid duplicating the nodes and distinguish the locking modes here if the register usage is the same.

Wanted to keep it separate all the way up. It makes changing the regiester allocations easier without having the different implementations requirements affect each other. If there is a noticeable runtime downside to having multiple nodes matching on different predicates we should revert this. 

Unsure what C2's assumptions about the state of the box is. But the idea is to eventually remove it or just kill it and use it as a temp register. (Thus allocating one less register for the node)

> src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp line 2478:
> 
>> 2476:       __ compiler_fast_lock_object(CCR0, r_oop, r_box, r_temp_1, r_temp_2, r_temp_3);
>> 2477:       __ beq(CCR0, locked);
>> 2478:     }
> 
> I appreciate your effort to make it more similar among all platforms. However, I think that using the C2 version is better because the native wrapper is the highest tier. Can we keep it as before with this PR and use a separate issue to clean it up for all platforms?
> That will allow us to check performance impact individually. Mixing 2 performance related changes is not ideal.

I changed it so that the native wrapper also uses the same fast lock/unlock as the C2 code. 
Added the assert code which checks that lock stack does not contain the object when handling the inflated case. Would be nice to run some stress tests and validate the assumptions made by the fast lock/unlock.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16611#issuecomment-1807632775
PR Comment: https://git.openjdk.org/jdk/pull/16611#issuecomment-1946058087
PR Comment: https://git.openjdk.org/jdk/pull/16611#issuecomment-1947834459
PR Review Comment: https://git.openjdk.org/jdk/pull/16611#discussion_r1394144690
PR Review Comment: https://git.openjdk.org/jdk/pull/16611#discussion_r1394144784
PR Review Comment: https://git.openjdk.org/jdk/pull/16611#discussion_r1394144851
PR Review Comment: https://git.openjdk.org/jdk/pull/16611#discussion_r1394152850
PR Review Comment: https://git.openjdk.org/jdk/pull/16611#discussion_r1394147579

From aboldtch at openjdk.org  Tue Feb 20 18:19:18 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 20 Feb 2024 18:19:18 GMT
Subject: RFR: 8319901: Recursive lightweight locking: ppc64le
 implementation
In-Reply-To: <5MS3_s3eGVy2GvPQ9ocP4tdNkbhArryBFkEHNkMjmfo=.098441a4-8b5c-4d5e-9956-f8e284916617@github.com>
References: <3LduAyBU7SzwJawH73jO5cAjVr5I0HJzs8y_jO9r3N4=.42388751-25b0-43fe-97c3-c4f95334bcfc@github.com>
 <nFROEF8HI0J0Pjdr0YOTIqhF3WTXcuwNqkrh_qAFac8=.ed22838f-1cf9-4718-8cbe-0eeebf6733fd@github.com>
 <5MS3_s3eGVy2GvPQ9ocP4tdNkbhArryBFkEHNkMjmfo=.098441a4-8b5c-4d5e-9956-f8e284916617@github.com>
Message-ID: <rtaG0BL13k5wHZtsQYfCCyzpchx_WUGeM0pqP8mgjAs=.94f09691-1e41-47c7-b044-154a49c79930@github.com>

On Mon, 13 Nov 2023 06:00:52 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> > Note that s390 does it like PPC64.
> 
> Just to know, should we expect similar changes for s390x as well ?? I do not see JBS issue for s390.

The goal is to eventually only support one mode. The current runtime implementation handles the transition period. I have no draft version for s390. But I will create sub-tasks for the other ports as well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16611#issuecomment-1807644325

From mdoerr at openjdk.org  Tue Feb 20 18:19:18 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 20 Feb 2024 18:19:18 GMT
Subject: RFR: 8319901: Recursive lightweight locking: ppc64le
 implementation
In-Reply-To: <nFROEF8HI0J0Pjdr0YOTIqhF3WTXcuwNqkrh_qAFac8=.ed22838f-1cf9-4718-8cbe-0eeebf6733fd@github.com>
References: <3LduAyBU7SzwJawH73jO5cAjVr5I0HJzs8y_jO9r3N4=.42388751-25b0-43fe-97c3-c4f95334bcfc@github.com>
 <nFROEF8HI0J0Pjdr0YOTIqhF3WTXcuwNqkrh_qAFac8=.ed22838f-1cf9-4718-8cbe-0eeebf6733fd@github.com>
Message-ID: <6v3SuWmFoKUP1mWqmgTqcxZ9gPq74vXVODDolg18jK0=.be7deaca-8402-41b6-b545-140cc301f190@github.com>

On Mon, 13 Nov 2023 13:49:30 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Draft implementation of recursive lightweight JDK-8319796 for ppc64le.
>> 
>> Porters feel free to discard this and implement something from scratch, take this initial draft and run with it, or send patches to me and if you want me to drive the PR.
>> 
>> Some notes:
>> ppc64le deviates from the other ports, it shares it C2 locking code with the native call wrapper. This draft unifies the behavior across the ports by using the C1/interpreter locking for native call wrapper. If it is important to have a fast path for the inflated monitor case for native call wrapper, it could be done without having it share its implementation with C2. 
>> It would also be possible to change this behavior on all ports (share the C2 code), as I believe the C2 assumptions always hold for the native call wrapper, the monitor exit and monitor enter will be balanced and structured.
>
> src/hotspot/cpu/ppc/c2_MacroAssembler_ppc.cpp line 45:
> 
>> 43: void C2_MacroAssembler::fast_lock_lightweight(ConditionRegister flag, Register obj, Register box,
>> 44:                                               Register tmp1, Register tmp2, Register tmp3) {
>> 45:   // TODO: Current implementation does not use box, consider removing a TEMP and use box instead.
> 
> The `box` is only used by legacy locking for the displaced mark word. I think the related code can get cleaned up (including removal of the argument and the extra stack slot) when legacy locking gets removed.

The comment should get improved. It is currently not legal to kill `box` because the mach nodes don't use a KILL effect. This is currently wrong on aarch64, but correct on x86_64.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16611#discussion_r1495346019

From aboldtch at openjdk.org  Tue Feb 20 18:19:18 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 20 Feb 2024 18:19:18 GMT
Subject: RFR: 8319901: Recursive lightweight locking: ppc64le
 implementation
In-Reply-To: <3LduAyBU7SzwJawH73jO5cAjVr5I0HJzs8y_jO9r3N4=.42388751-25b0-43fe-97c3-c4f95334bcfc@github.com>
References: <3LduAyBU7SzwJawH73jO5cAjVr5I0HJzs8y_jO9r3N4=.42388751-25b0-43fe-97c3-c4f95334bcfc@github.com>
Message-ID: <nR4HlhJusyhyjl80wWhBtDZFdJFem1LbfEradvwisZA=.ebde21f3-f4d2-478d-a39b-d0aa60f67971@github.com>

On Fri, 10 Nov 2023 13:21:58 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Draft implementation of recursive lightweight JDK-8319796 for ppc64le.
> 
> Porters feel free to discard this and implement something from scratch, take this initial draft and run with it, or send patches to me and if you want me to drive the PR.
> 
> Some notes:
> ppc64le deviates from the other ports, it shares it C2 locking code with the native call wrapper. This draft unifies the behavior across the ports by using the C1/interpreter locking for native call wrapper. If it is important to have a fast path for the inflated monitor case for native call wrapper, it could be done without having it share its implementation with C2. 
> It would also be possible to change this behavior on all ports (share the C2 code), as I believe the C2 assumptions always hold for the native call wrapper, the monitor exit and monitor enter will be balanced and structured.

> Thanks for rebasing it! We noticed that the register usage is invalid at some points. Using R0 doesn't work for memory base addresses or as source operand for addi instructions. It should work like this:
> 
> ```diff
> diff --git a/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp b/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp
> index 6a7428ebd04..6f131467595 100644
> --- a/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp
> +++ b/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp
> @@ -2471,7 +2471,7 @@ void MacroAssembler::compiler_fast_lock_lightweight_object(ConditionRegister fla
>    }
>  
>    const Register mark = tmp1;
> -  const Register t = tmp3;
> +  const Register t = tmp3; // Usage of R0 allowed!
>  
>    { // Lightweight locking
>  
> @@ -2489,8 +2489,8 @@ void MacroAssembler::compiler_fast_lock_lightweight_object(ConditionRegister fla
>      // when the lock stack is empty because of the _bad_oop_sentinel field.
>  
>      // Check if recursive.
> -    subi(t, top, oopSize);
> -    ldx(t, t, R16_thread);
> +    subi(tmp1, top, oopSize);
> +    ldx(t, tmp1, R16_thread);
>      cmpd(flag, obj, t);
>      beq(flag, push);
>  
> @@ -2541,13 +2541,13 @@ void MacroAssembler::compiler_fast_lock_lightweight_object(ConditionRegister fla
>      bne(flag, slow_path);
>  
>      // Recursive.
> -    ld(t, in_bytes(ObjectMonitor::recursions_offset() - ObjectMonitor::owner_offset()), owner_addr);
> -    addi(t, t, 1);
> -    std(t, in_bytes(ObjectMonitor::recursions_offset() - ObjectMonitor::owner_offset()), owner_addr);
> +    ld(tmp1, in_bytes(ObjectMonitor::recursions_offset() - ObjectMonitor::owner_offset()), owner_addr);
> +    addi(tmp1, tmp1, 1);
> +    std(tmp1, in_bytes(ObjectMonitor::recursions_offset() - ObjectMonitor::owner_offset()), owner_addr);
>    }
>  
>    bind(locked);
> -  inc_held_monitor_count(t);
> +  inc_held_monitor_count(tmp1);
>  
>  #ifdef ASSERT
>    // Check that locked label is reached with flags == EQ.
> @@ -4361,8 +4361,8 @@ void MacroAssembler::lightweight_lock(Register obj, Register t1, Register t2, La
>    // when the lock stack is empty because of the _bad_oop_sentinel field.
>  
>    // Check for recursion.
> -  subi(t, top, oopSize);
> -  ldx(t, t, R16_thread);
> +  subi(t2, top, oopSize);
> +  ldx(t, t2, R16_thread);
>    cmpd(CCR0, obj, t);
>    beq(CCR0, push);
>  
> ```
> 
> We may want to do further improvements to make register usage less confusing. Please take a look!

I was not aware of the specific semantics of R0. 

This register comes from the expansion of the FastLockNode in the .ad file. I just copied the register allocation from the current implementation. Maybe this should be hoisted, such that none of the temp registers are allowed to be R0. None is when called from the shared runtime, this only occurs from the .ad file.

The .ad file allocates a register for the box which is just dropped. We could use this instead as tmp3.

I pushed a change along those lines.

There are still some room for cleanups here with regards to the register allocation.

I will keep this in mind for Lilliput as well. There we still want to use the box, so will have to do some register juggling, or change the register allocation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16611#issuecomment-1945546958

From aboldtch at openjdk.org  Tue Feb 20 18:19:18 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 20 Feb 2024 18:19:18 GMT
Subject: RFR: 8319901: Recursive lightweight locking: ppc64le
 implementation
In-Reply-To: <nR4HlhJusyhyjl80wWhBtDZFdJFem1LbfEradvwisZA=.ebde21f3-f4d2-478d-a39b-d0aa60f67971@github.com>
References: <3LduAyBU7SzwJawH73jO5cAjVr5I0HJzs8y_jO9r3N4=.42388751-25b0-43fe-97c3-c4f95334bcfc@github.com>
 <nR4HlhJusyhyjl80wWhBtDZFdJFem1LbfEradvwisZA=.ebde21f3-f4d2-478d-a39b-d0aa60f67971@github.com>
Message-ID: <wo9BId7F4mGfOPt9n05FzJZuPJqY4dAnTPwfXfmGqX8=.897e6510-d616-40da-a1ce-0845dd2617cf@github.com>

On Thu, 15 Feb 2024 08:08:00 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> I was not aware of the specific semantics of R0.

I just though it was a zero register and completely glossed over that it was used as a parameter for the ad file.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16611#issuecomment-1945548325

From mdoerr at openjdk.org  Tue Feb 20 18:19:18 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 20 Feb 2024 18:19:18 GMT
Subject: RFR: 8319901: Recursive lightweight locking: ppc64le
 implementation
In-Reply-To: <GQ-gM8QDWVryN6HnerwLhQYbKq9qyw_2t4Oe5pdZpME=.2e26cf8e-e07b-4cec-a973-62f85452d42a@github.com>
References: <3LduAyBU7SzwJawH73jO5cAjVr5I0HJzs8y_jO9r3N4=.42388751-25b0-43fe-97c3-c4f95334bcfc@github.com>
 <nFROEF8HI0J0Pjdr0YOTIqhF3WTXcuwNqkrh_qAFac8=.ed22838f-1cf9-4718-8cbe-0eeebf6733fd@github.com>
 <GQ-gM8QDWVryN6HnerwLhQYbKq9qyw_2t4Oe5pdZpME=.2e26cf8e-e07b-4cec-a973-62f85452d42a@github.com>
Message-ID: <cmsFtdrJemjolHvweNAHHznxnDVbuyJ7oUKcPjqEM0Q=.df698524-a467-4f9b-9ab9-86a1f18fbae8@github.com>

On Thu, 15 Feb 2024 13:03:37 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> If you want to go over and find a unified style here which fits better with how the PPC port usually does it, it would be appreciated.

Sure, I'll go over it when I find more time. I'd like to get it correct first, so I can run more tests before thinking about improvements.
I'm still a bit surprised that you invest into PPC64 :-) I appreciate it!
Are you planning to do more for Lilliput on PPC64? I'm also planning to look into the remaining parts when I find time.

>> src/hotspot/cpu/ppc/ppc.ad line 12189:
>> 
>>> 12187:   ins_encode %{
>>> 12188:     __ fast_lock_lightweight($crx$$CondRegister, $oop$$Register, $box$$Register,
>>> 12189:                              $tmp1$$Register, $tmp2$$Register, /*tmp3*/ R0);
>> 
>> You could avoid duplicating the nodes and distinguish the locking modes here if the register usage is the same.
>
> Wanted to keep it separate all the way up. It makes changing the regiester allocations easier without having the different implementations requirements affect each other. If there is a noticeable runtime downside to having multiple nodes matching on different predicates we should revert this. 
> 
> Unsure what C2's assumptions about the state of the box is. But the idea is to eventually remove it or just kill it and use it as a temp register. (Thus allocating one less register for the node)

That's ok for now. We can clean everything up when removing the legacy locking. Unfortunately, `BoxLockNode` is not easy to remove completely because they are used for analyzing properties of the graph. That would need a redesign. But at least, we could implement them as empty nodes such that they don't emit any code.

>> src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp line 2478:
>> 
>>> 2476:       __ compiler_fast_lock_object(CCR0, r_oop, r_box, r_temp_1, r_temp_2, r_temp_3);
>>> 2477:       __ beq(CCR0, locked);
>>> 2478:     }
>> 
>> I appreciate your effort to make it more similar among all platforms. However, I think that using the C2 version is better because the native wrapper is the highest tier. Can we keep it as before with this PR and use a separate issue to clean it up for all platforms?
>> That will allow us to check performance impact individually. Mixing 2 performance related changes is not ideal.
>
> I changed it so that the native wrapper also uses the same fast lock/unlock as the C2 code. 
> Added the assert code which checks that lock stack does not contain the object when handling the inflated case. Would be nice to run some stress tests and validate the assumptions made by the fast lock/unlock.

Thanks! I'll take a look and run tests. The assertion makes sense anyway.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16611#issuecomment-1946511790
PR Review Comment: https://git.openjdk.org/jdk/pull/16611#discussion_r1394182643
PR Review Comment: https://git.openjdk.org/jdk/pull/16611#discussion_r1394183901

From eastigeevich at openjdk.org  Tue Feb 20 21:47:58 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Tue, 20 Feb 2024 21:47:58 GMT
Subject: RFR: 8311248: Refactor CodeCache::initialize_heaps to simplify
 adding new CodeCache segments [v8]
In-Reply-To: <zZYSSyxTm0zfZMjql-liQAWb4UDFTS4FEM0FUN6E_V4=.371ff797-f1dd-489e-8a7e-fcd7a6c62e34@github.com>
References: <-V_dgQKhDrt1n0Zbk3qNa276jZBO822NlSvUv9AhpEA=.7a23c712-4b01-4aa7-acbe-8f5b5cca9002@github.com>
 <zZYSSyxTm0zfZMjql-liQAWb4UDFTS4FEM0FUN6E_V4=.371ff797-f1dd-489e-8a7e-fcd7a6c62e34@github.com>
Message-ID: <BWGsTpMtsjvEhwOE4n3lDZYEK1xghhQUOqQqsRXHByU=.a3de1214-fee8-436e-81a3-b68681d35c68@github.com>

On Tue, 20 Feb 2024 13:26:22 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

>> These changes clean up the logic and the code of allocating codecache segments and add more testing of it, to open a door for further optimization of code cache segmentation.  The goal was to keep the behavior as close to the existing behavior as possible, even if it's not quite logical.
>> 
>> Also, these changes better account for alignment - PrintFlagsFinal shows the final aligned segment sizes, and the segments fill the ReservedCodeCacheSize without gaps caused by alignment.
>
> Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   one another cleanup round

src/hotspot/share/code/codeCache.cpp line 227:

> 225:   if (!heap_available(CodeBlobType::MethodNonProfiled)) {
> 226:     assert(false, "MethodNonProfiled heap is always available for segmented code heap");
> 227:   }

It's just:

assert(heap_available(CodeBlobType::MethodNonProfiled), "MethodNonProfiled heap must be always available for segmented code heap");

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17244#discussion_r1496562558

From eastigeevich at openjdk.org  Tue Feb 20 22:24:58 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Tue, 20 Feb 2024 22:24:58 GMT
Subject: RFR: 8311248: Refactor CodeCache::initialize_heaps to simplify
 adding new CodeCache segments [v8]
In-Reply-To: <zZYSSyxTm0zfZMjql-liQAWb4UDFTS4FEM0FUN6E_V4=.371ff797-f1dd-489e-8a7e-fcd7a6c62e34@github.com>
References: <-V_dgQKhDrt1n0Zbk3qNa276jZBO822NlSvUv9AhpEA=.7a23c712-4b01-4aa7-acbe-8f5b5cca9002@github.com>
 <zZYSSyxTm0zfZMjql-liQAWb4UDFTS4FEM0FUN6E_V4=.371ff797-f1dd-489e-8a7e-fcd7a6c62e34@github.com>
Message-ID: <wz6XqwfQ9Zd9B2tOcyBlrjca-bnbuzS9b1F8Mq8qTj0=.c3ee514f-6350-475f-97fd-434506f6439d@github.com>

On Tue, 20 Feb 2024 13:26:22 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

>> These changes clean up the logic and the code of allocating codecache segments and add more testing of it, to open a door for further optimization of code cache segmentation.  The goal was to keep the behavior as close to the existing behavior as possible, even if it's not quite logical.
>> 
>> Also, these changes better account for alignment - PrintFlagsFinal shows the final aligned segment sizes, and the segments fill the ReservedCodeCacheSize without gaps caused by alignment.
>
> Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   one another cleanup round

src/hotspot/share/code/codeCache.cpp line 275:

> 273:     check_min_size("profiled code heap", profiled.size, min_size);
> 274:   }
> 275:   if (non_profiled.enabled) {

It's redundant  because it is always true.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17244#discussion_r1496611416

From eastigeevich at openjdk.org  Tue Feb 20 23:09:55 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Tue, 20 Feb 2024 23:09:55 GMT
Subject: RFR: 8311248: Refactor CodeCache::initialize_heaps to simplify
 adding new CodeCache segments [v7]
In-Reply-To: <DlmG66emjkIuGbNOb8naO19gTRcWmyB8A9EwDShwApo=.8762be05-65e1-4d47-983b-bb333ef690b3@github.com>
References: <-V_dgQKhDrt1n0Zbk3qNa276jZBO822NlSvUv9AhpEA=.7a23c712-4b01-4aa7-acbe-8f5b5cca9002@github.com>
 <_HrFkS2z3Mk1RKtgVB010rsIx7aTolc_0iMDJox6eDc=.de2d7093-186f-48c0-859f-0769bf372b29@github.com>
 <nUhUPfjEU6k5xT9FHUfi_oaiFmThHBGhWp-IYywSK7I=.0cdefbca-ad66-4174-9eff-c54f06d189f5@github.com>
 <DlmG66emjkIuGbNOb8naO19gTRcWmyB8A9EwDShwApo=.8762be05-65e1-4d47-983b-bb333ef690b3@github.com>
Message-ID: <ogdZtjDznU596HqLCYHgTX8E0W62H6tzq-SZ1JR1HCQ=.3713e9ad-77a7-4036-87dd-bf559d5f27b6@github.com>

On Tue, 20 Feb 2024 12:54:59 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

>> src/hotspot/share/code/codeCache.cpp line 312:
>> 
>>> 310:   // last adjustment: leftovers from page alignment go to non_nmethod segment
>>> 311:   non_nmethod.size += non_profiled.size & alignment_mask(min_size);
>>> 312:   non_nmethod.size += profiled.size & alignment_mask(min_size);
>> 
>> Why do we need this code?
>
> Let us assume that with the previous calculations we have this layout:
> - {cache_size=18004KB, non_profiled.size = 6002KB, profiled.size = 6002KB, non_nmethod.size=6000KB}
> 
> With next align_down for profiled and non_profiled segments, we get:
> - {cache_size=18004KB, non_profiled.size = 6000KB, profiled.size = 6000KB, non_nmethod.size=6000KB}
> 
> My intention here is to put 4KB into the non_nmethod segment to make the sum of the segment sizes equal to cache_size:
> - {cache_size=18004KB, non_profiled.size = 6000KB, profiled.size = 6000KB, non_nmethod.size=6004KB}

Why has `non_nmethod` been chosen? I have not seen it running out of space. It usually has a lot of free space. Also in case of large pages, e.g. 2M, it can get even more space than needed.
I'd rather give additional space to `profiled` or `non_profiled`. As `profiled` is optional, to simplify the code we can have:

  non_nmethod.size = align_up(non_nmethod.size, min_size);
  profiled.size = align_down(profiled.size, min_size);
  profiled.size = align_down(cache_size - profiled.size - non_nmethod.size, min_size);


For you example, we will have:

{cache_size=18004KB, non_profiled.size = 6004KB, profiled.size = 6000KB, non_nmethod.size=6000KB}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17244#discussion_r1496663761

From eastigeevich at openjdk.org  Tue Feb 20 23:14:56 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Tue, 20 Feb 2024 23:14:56 GMT
Subject: RFR: 8311248: Refactor CodeCache::initialize_heaps to simplify
 adding new CodeCache segments [v8]
In-Reply-To: <zZYSSyxTm0zfZMjql-liQAWb4UDFTS4FEM0FUN6E_V4=.371ff797-f1dd-489e-8a7e-fcd7a6c62e34@github.com>
References: <-V_dgQKhDrt1n0Zbk3qNa276jZBO822NlSvUv9AhpEA=.7a23c712-4b01-4aa7-acbe-8f5b5cca9002@github.com>
 <zZYSSyxTm0zfZMjql-liQAWb4UDFTS4FEM0FUN6E_V4=.371ff797-f1dd-489e-8a7e-fcd7a6c62e34@github.com>
Message-ID: <gHmMrl4FsWjphbcHyc7At28behHg-uRRHIsUzC9nC-c=.0b4d9dff-9ab3-459e-b8cd-c7644cc4f411@github.com>

On Tue, 20 Feb 2024 13:26:22 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

>> These changes clean up the logic and the code of allocating codecache segments and add more testing of it, to open a door for further optimization of code cache segmentation.  The goal was to keep the behavior as close to the existing behavior as possible, even if it's not quite logical.
>> 
>> Also, these changes better account for alignment - PrintFlagsFinal shows the final aligned segment sizes, and the segments fill the ReservedCodeCacheSize without gaps caused by alignment.
>
> Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   one another cleanup round

src/hotspot/share/code/codeCache.cpp line 197:

> 195: };
> 196: 
> 197: static void set_size_of_unset_code_heap(CodeHeapInfo* heap, size_t available_size, size_t known_segments_size, size_t min_size) {

Suggest renaming: `known_segments_size` -> `used_size`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17244#discussion_r1496667518

From sspitsyn at openjdk.org  Tue Feb 20 23:48:06 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 20 Feb 2024 23:48:06 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v13]
In-Reply-To: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
Message-ID: <bpyapA636CevyF7zlYxxhEYa-rcPW-04QL3Tud_5bzs=.53c46cb2-bf47-4d1c-aad0-20c979ee2eb2@github.com>

> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
> The function returns the following structure:
> 
> 
> typedef struct {
>     jthread owner;
>     jint entry_count;
>     jint waiter_count;
>     jthread* waiters;
>     jint notify_waiter_count;
>     jthread* notify_waiters;
> } jvmtiMonitorUsage;
> 
> 
> The following four fields are defined this way:
> 
> waiter_count  [jint] The number of threads waiting to own this monitor
> waiters  [jthread*] The waiter_count waiting threads
> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
> 
> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
> This update makes it right.
> 
> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
> 
> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
> 
>   jvmti/GetObjectMonitorUsage/objmonusage001
>   jvmti/GetObjectMonitorUsage/objmonusage003
> 
> 
> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
> 
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
> 
> 
> 
> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository.
> 
> Also, please see and review the related CSR:
>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
> 
> The Release-Note is:
> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage
>  
> Testing:
>  - tested with mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: addressed minor issue with use of []; corrected the test desctiption

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17680/files
  - new: https://git.openjdk.org/jdk/pull/17680/files/81b7787b..e095cffe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=11-12

  Stats: 13 lines in 1 file changed: 5 ins; 5 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/17680.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17680/head:pull/17680

PR: https://git.openjdk.org/jdk/pull/17680

From sspitsyn at openjdk.org  Tue Feb 20 23:48:06 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 20 Feb 2024 23:48:06 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v12]
In-Reply-To: <4B3DWXFwEnHy-pkzhr3L-LzQi3O0hdenzXqb5V1OejQ=.67044e45-777b-4fbc-af5e-de29348a2247@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <P_SGQw9YGQvIDVikpCoUCZLSoumOSxbSwGJspCEb5pI=.e2cf601a-e89c-4e50-9d69-20ef18ff49e5@github.com>
 <4B3DWXFwEnHy-pkzhr3L-LzQi3O0hdenzXqb5V1OejQ=.67044e45-777b-4fbc-af5e-de29348a2247@github.com>
Message-ID: <HGl8lumNeQ2ZAp_66CCGQRzo3WhftT7l4WQtqPSXtEY=.f84220b5-8783-4a6c-89a8-3d9171f1c9d4@github.com>

On Tue, 20 Feb 2024 06:15:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: addressed comments from David
>
> test/hotspot/jtreg/serviceability/jvmti/GetObjectMonitorUsage/ObjectMonitorUsage.java line 54:
> 
>> 52: 
>> 53:     static Object lockCheck = new Object();
>> 54:     static Thread thr[] = new Thread[NUMBER_OF_THREADS];
> 
> Nit: the `[]` go on the type not the variable.

Thanks, fixed now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1496688629

From coleenp at openjdk.org  Tue Feb 20 23:58:07 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 20 Feb 2024 23:58:07 GMT
Subject: RFR: 8139457: Relax alignment of array elements [v64]
In-Reply-To: <L1FV4XUdDi491n22aiCfjk8SrnIJHYeDEQf2u2aY4i8=.6f73b2a6-8e7f-4f69-9d07-c2425ad484f3@github.com>
References: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
 <L1FV4XUdDi491n22aiCfjk8SrnIJHYeDEQf2u2aY4i8=.6f73b2a6-8e7f-4f69-9d07-c2425ad484f3@github.com>
Message-ID: <sEbS9nZzkg3JqhLrNfqnAbEc3j4HvYmbsTMgCX40qPE=.4d309ea0-b56f-42cb-8557-a282b1215fcd@github.com>

On Thu, 15 Feb 2024 11:46:39 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details.
>> 
>> Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements.
>> 
>> Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16.
>> 
>> Testing:
>>  - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390)
>>  - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390)
>>  - [x] tier1 (x86_64, x86_32, aarch64, riscv)
>>  - [x] tier2 (x86_64, aarch64, riscv)
>>  - [x] tier3 (x86_64, riscv)
>
> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 93 commits:
> 
>  - Merge branch 'master' into JDK-8139457
>  - Merge remote-tracking branch 'upstream/master' into JDK-8139457
>  - Update copyright headers
>  - Merge branch 'master' into JDK-8139457
>  - Fix ARM build
>  - Merge remote-tracking branch 'upstream/master' into JDK-8139457
>  - Various cleanups
>  - RISC changes
>  - Move gap init into allocate_header() (x86)
>  - Fix gtest failure on x86
>  - ... and 83 more: https://git.openjdk.org/jdk/compare/a0e5e16a...d0ec1fa2

I'm still re-reading the change and comments.  Don't forget to update the copyrights.
Also, I'm rerunning tier1-7 on this change.

-------------

PR Review: https://git.openjdk.org/jdk/pull/11044#pullrequestreview-1885127137

From coleenp at openjdk.org  Tue Feb 20 23:58:08 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 20 Feb 2024 23:58:08 GMT
Subject: RFR: 8139457: Relax alignment of array elements [v23]
In-Reply-To: <0-lVZpSsP2FUCAiK6Oo2CrI9FNIg-vyq0G5mdoEh1JQ=.50c51610-7efd-4752-8ea5-b8da19f7cce8@github.com>
References: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
 <P0PwRAtYFnr1vQUuGzlDCb5pFahSsfeUxCtYgTIlt9Q=.851a5929-973c-41a8-9066-cd5743a8d54d@github.com>
 <0-lVZpSsP2FUCAiK6Oo2CrI9FNIg-vyq0G5mdoEh1JQ=.50c51610-7efd-4752-8ea5-b8da19f7cce8@github.com>
Message-ID: <GkMD0dyADxWBDnIHt2J8ve2KUBVfyNUR0_LlCr1DkEg=.b511b673-ba60-499f-b442-dbad9e6aaa8e@github.com>

On Wed, 15 Feb 2023 14:51:19 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clarify comment on arrayOopDesc::max_array_length()
>
> src/hotspot/share/opto/type.cpp line 5010:
> 
>> 5008:   if( _offset != 0 ) {
>> 5009:     BasicType basic_elem_type = elem()->basic_type();
>> 5010:     int header_size = arrayOopDesc::base_offset_in_bytes(basic_elem_type);
> 
> This function now calls base_offset_in_bytes twice. One to set header_size and the other to set the array_base. Maybe clean that up?

At line 5181. re: Stefan's comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/11044#discussion_r1492437784

From ddong at openjdk.org  Wed Feb 21 02:26:55 2024
From: ddong at openjdk.org (Denghui Dong)
Date: Wed, 21 Feb 2024 02:26:55 GMT
Subject: RFR: 8326012: JFR: Event for time to safepoint [v9]
In-Reply-To: <DwJb1JrYg4IMe_3d5MAjEkiwdTDhYHFCx0qVxDCmLmc=.47673420-7467-42e6-8231-e37d9e8882f9@github.com>
References: <68hS0kQgtDIk4ioAJj_r0_GLT6h0lcif6Daj6WRwxlI=.40c2a6e7-70a8-4954-bcde-9318ee311028@github.com>
 <DwJb1JrYg4IMe_3d5MAjEkiwdTDhYHFCx0qVxDCmLmc=.47673420-7467-42e6-8231-e37d9e8882f9@github.com>
Message-ID: <m6kr7L15W9I-Wzl29Ru70tWC00YOtUjF6gv33zQHVJ8=.05c9c818-ce09-41fd-ae73-fc88adffb41e@github.com>

On Tue, 20 Feb 2024 05:27:22 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> There are now some JFR events related to safepoint. When time-to-safepoint (aka ttsp) is too long, these events could not be very helpful since based on them we cannot know which threads cause it and what those threads are doing.
>> 
>> Users can use `-XX:+SafepointTimeout -XX:SafepointTimeoutDelay=100` to see the threads that don't reach safepoint in time but without stack traces. Using `-XX:+ AbortVMOnSafepointTimeout` can capture the stack traces but it crashes the process, hence it's not sensible to enable the flag in production.
>> 
>> ~~This patch adds a new JFR event `EventSafepointTimeout` to record the threads that cause ttsp too long.~~
>> 
>> ~~This event includes two fields:~~
>> 
>> ~~- safepointId: the relevant safepoint id~~
>> ~~- timeExceeded: the amount of time exceeding `SafepointTimeoutDelay` used by the thread to reach safepoint~~
>> 
>> ~~In the current version, this event records the stack of those problematic threads when they finally reach safepoint. Hence, there is a bias, but it's still helpful to deduce the root place.~~
>> 
>> A better implementation is to record a more accurate stack, but this will increase complexity. At the same time, the native stack may also be important for this problem, but it is not currently supported by JFR.
>> 
>> Any input would be greatly appreciated.
>> 
>> Testing: jdk/jdk/jfr
>
> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   delete _entries when disabled

src/hotspot/share/jfr/support/jfrTimeToSafepoint.hpp line 42:

> 40:     JavaThread* thread;
> 41:     JfrTicks end;
> 42:     int iterations;

Maybe we can think about putting them into JfrThreadLocal.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17888#discussion_r1496788017

From mdoerr at openjdk.org  Wed Feb 21 04:50:56 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 21 Feb 2024 04:50:56 GMT
Subject: RFR: 8319901: Recursive lightweight locking: ppc64le
 implementation
In-Reply-To: <3LduAyBU7SzwJawH73jO5cAjVr5I0HJzs8y_jO9r3N4=.42388751-25b0-43fe-97c3-c4f95334bcfc@github.com>
References: <3LduAyBU7SzwJawH73jO5cAjVr5I0HJzs8y_jO9r3N4=.42388751-25b0-43fe-97c3-c4f95334bcfc@github.com>
Message-ID: <lQLqmGQi0FedU0TBA2zB_gq4nnNlMrthDcBhGztCp8Q=.f65a596e-7b3f-4ba8-89e1-48ea8c7bd374@github.com>

On Fri, 10 Nov 2023 13:21:58 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Draft implementation of recursive lightweight JDK-8319796 for ppc64le.
> 
> Porters feel free to discard this and implement something from scratch, take this initial draft and run with it, or send patches to me and if you want me to drive the PR.
> 
> Some notes:
> ppc64le deviates from the other ports, it shares it C2 locking code with the native call wrapper. This draft unifies the behavior across the ports by using the C1/interpreter locking for native call wrapper. If it is important to have a fast path for the inflated monitor case for native call wrapper, it could be done without having it share its implementation with C2. 
> It would also be possible to change this behavior on all ports (share the C2 code), as I believe the C2 assumptions always hold for the native call wrapper, the monitor exit and monitor enter will be balanced and structured.

Thanks a lot! LGTM.

Regarding aarch64: Should we file a JBS issue for the usage of `box`?
https://github.com/openjdk/jdk/blob/d31fd78d963d5d103b1b1bf66ae0bdbe4be2b790/src/hotspot/cpu/aarch64/aarch64.ad#L16470
has no kill effect for `box`, but `C2_MacroAssembler::fast_lock_lightweight` kills it. It may be never used, but it's a trap someone might run into. x86_64 uses `USE_KILL box`.

-------------

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16611#pullrequestreview-1892100633

From duke at openjdk.org  Wed Feb 21 05:40:13 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 21 Feb 2024 05:40:13 GMT
Subject: RFR: 8325991: Accelerate Poly1305 on x86_64 using AVX2
 instructions [v4]
In-Reply-To: <IyoM1HY_rvNWwo4GxcV1yQleB3vrgaLwsAlOCEpLKqs=.1d50225c-8fe1-4a84-af56-274632b2b653@github.com>
References: <IyoM1HY_rvNWwo4GxcV1yQleB3vrgaLwsAlOCEpLKqs=.1d50225c-8fe1-4a84-af56-274632b2b653@github.com>
Message-ID: <LLvSSnrEIYHk49CCs14ZPwXiBJYndwUwRSl6X-kajqI=.2ad38d7a-47fd-4e37-9db6-49e812ce97c5@github.com>

> The goal of this PR is to accelerate the Poly1305 algorithm using AVX2 instructions (including IFMA) for x86_64 CPUs.
> 
> This implementation is directly based on the AVX2 Poly1305 hash computation as implemented in Intel(R) Multi-Buffer Crypto for IPsec Library (url: https://github.com/intel/intel-ipsec-mb/blob/main/lib/avx2_t3/poly_fma_avx2.asm)

Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:

  remove unused uniions and fix uses_vl

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17881/files
  - new: https://git.openjdk.org/jdk/pull/17881/files/6d97c53a..f1b18567

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17881&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17881&range=02-03

  Stats: 33 lines in 2 files changed: 0 ins; 27 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/17881.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17881/head:pull/17881

PR: https://git.openjdk.org/jdk/pull/17881

From duke at openjdk.org  Wed Feb 21 05:40:14 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 21 Feb 2024 05:40:14 GMT
Subject: RFR: 8325991: Accelerate Poly1305 on x86_64 using AVX2
 instructions [v3]
In-Reply-To: <qxL7PSNxJEV_m5tRP8Jr3xmdzj-gBn4ztwuwZL5s1JA=.8fde5eae-6fd4-432f-9c79-173201c3ef66@github.com>
References: <IyoM1HY_rvNWwo4GxcV1yQleB3vrgaLwsAlOCEpLKqs=.1d50225c-8fe1-4a84-af56-274632b2b653@github.com>
 <RcqlCw9bXCsxQf7dNaKVjFflrCvu41kJDkbbxpuCWaU=.d2cf9c21-2d34-4320-a76a-9ab0aa71c43e@github.com>
 <qxL7PSNxJEV_m5tRP8Jr3xmdzj-gBn4ztwuwZL5s1JA=.8fde5eae-6fd4-432f-9c79-173201c3ef66@github.com>
Message-ID: <ohfgF4dATKmGLOAagMRjPNm214kysBTSQbQa0W2z9kQ=.fcc987e1-554d-44bd-a17b-b437deb605a3@github.com>

On Sun, 18 Feb 2024 13:37:16 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   change overloaded C to use COEFF
>
> src/hotspot/cpu/x86/assembler_x86.cpp line 5150:
> 
>> 5148: 
>> 5149: void Assembler::vpmadd52luq(XMMRegister dst, XMMRegister src1, Address src2, bool merge, int vector_len) {
>> 5150:   assert(VM_Version::supports_avxifma(), "");
> 
> Please add an assertion for vector_len to be either 128 or 256 bit.

Please see the assertions added.

> src/hotspot/cpu/x86/assembler_x86.cpp line 5152:
> 
>> 5150:   assert(VM_Version::supports_avxifma(), "");
>> 5151:   InstructionMark im(this);
>> 5152:   InstructionAttr attributes(vector_len, /* rex_w */ true, /* legacy_mode */ false, /* no_mask_reg */ false, /* uses_vl */ true);
> 
> uses_vl should be false, its a VEX encoded instruction.

Updated uses_vl to false.

> src/hotspot/cpu/x86/assembler_x86.cpp line 5155:
> 
>> 5153:   if (merge) {
>> 5154:     attributes.reset_is_clear_context();
>> 5155:   }
> 
> As of now, merge semantics are only applicable to AVX512 instructions accepting an opmask register.

Pls see the merge semantics removed.

> src/hotspot/cpu/x86/assembler_x86.cpp line 5167:
> 
>> 5165: 
>> 5166: void Assembler::vpmadd52luq(XMMRegister dst, XMMRegister src1, XMMRegister src2, bool merge, int vector_len) {
>> 5167:   assert(VM_Version::supports_avxifma(), "");
> 
> assertion for vector lengths, same as above.

Added the assertions.

> src/hotspot/cpu/x86/assembler_x86.cpp line 5221:
> 
>> 5219:     attributes.reset_is_clear_context();
>> 5220:   }
>> 5221: 
> 
> Above comments applicable to this routine also.

Done.

> src/hotspot/cpu/x86/stubGenerator_x86_64_poly.cpp line 1367:
> 
>> 1365: 
>> 1366:   // VECTOR LOOP: process 4 * 16-byte message blocks at a time
>> 1367:   __ bind(L_process256Loop);
> 
> Add appropriate alignment at the beginning of vector loop.

Please see the stack setup and alignment is being done in lines 1170-1176.

> src/hotspot/cpu/x86/vm_version_x86.hpp line 302:
> 
>> 300:     uint32_t value;
>> 301:   };
>> 302: 
> 
> We can avoid creating additional structures for SefCpuid7Ecx1Ebx, SefCpuid7Ecx1Ecx and SefCpuid7Ecx1Edx. They occupy space over stack and none of their bits are being used.

Please see the unused unions removed in the latest commit pushed.

> src/hotspot/cpu/x86/vm_version_x86.hpp line 482:
> 
>> 480:     SefCpuid7Ecx1Ebx sef_cpuid7_ecx1_ebx;
>> 481:     SefCpuid7Ecx1Ecx sef_cpuid7_ecx1_ecx;
>> 482:     SefCpuid7Ecx1Edx sef_cpuid7_ecx1_edx;
> 
> Please remove SefCpuid7Ecx1Ebx, SefCpuid7Ecx1Ecx and SefCpuid7Ecx1Edx field definitions.

Please see the field declarations removed in the latest commit pushed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17881#discussion_r1496934558
PR Review Comment: https://git.openjdk.org/jdk/pull/17881#discussion_r1496934387
PR Review Comment: https://git.openjdk.org/jdk/pull/17881#discussion_r1496934855
PR Review Comment: https://git.openjdk.org/jdk/pull/17881#discussion_r1496934999
PR Review Comment: https://git.openjdk.org/jdk/pull/17881#discussion_r1496935129
PR Review Comment: https://git.openjdk.org/jdk/pull/17881#discussion_r1496936195
PR Review Comment: https://git.openjdk.org/jdk/pull/17881#discussion_r1496933154
PR Review Comment: https://git.openjdk.org/jdk/pull/17881#discussion_r1496933829

From aboldtch at openjdk.org  Wed Feb 21 07:15:55 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 21 Feb 2024 07:15:55 GMT
Subject: RFR: 8319901: Recursive lightweight locking: ppc64le
 implementation
In-Reply-To: <lQLqmGQi0FedU0TBA2zB_gq4nnNlMrthDcBhGztCp8Q=.f65a596e-7b3f-4ba8-89e1-48ea8c7bd374@github.com>
References: <3LduAyBU7SzwJawH73jO5cAjVr5I0HJzs8y_jO9r3N4=.42388751-25b0-43fe-97c3-c4f95334bcfc@github.com>
 <lQLqmGQi0FedU0TBA2zB_gq4nnNlMrthDcBhGztCp8Q=.f65a596e-7b3f-4ba8-89e1-48ea8c7bd374@github.com>
Message-ID: <N69apmSfVOx0YAosQFY1W7-UFbJVjqF8C4lTc5YmyD0=.ec2b151c-0fa3-4264-b233-be86a7707bdd@github.com>

On Wed, 21 Feb 2024 04:48:30 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Thanks a lot! LGTM.
> 
> Regarding aarch64: Should we file a JBS issue for the usage of `box`?
> 
> https://github.com/openjdk/jdk/blob/d31fd78d963d5d103b1b1bf66ae0bdbe4be2b790/src/hotspot/cpu/aarch64/aarch64.ad#L16470
> 
> 
> has no kill effect for `box`, but `C2_MacroAssembler::fast_lock_lightweight` kills it. It may be never used, but it's a trap someone might run into. x86_64 uses `USE_KILL box`.
> I think that it currently works, but I'd prefer to use a temp register and hopefully remove the `box` completely at some point of time. It could also be cleaned up together with other changes if you prefer that.

This came up in the review as well. The issue with `USE_KILL` and `KILL` is that they require a bound register to use. So we must restrict the box to a specific real register. (Works on x86 because it box is bound to `RAX`/`EAX`).

Should create a JBS issue for this. And maybe it is to dangerous to leave it as is until we can create a C2 Node that does not require the box.

The only potential fix I see is to actually bind the register.  i.e.

diff --git a/src/hotspot/cpu/aarch64/aarch64.ad b/src/hotspot/cpu/aarch64/aarch64.ad
index a07ff041c48..97d7898ceba 100644
--- a/src/hotspot/cpu/aarch64/aarch64.ad
+++ b/src/hotspot/cpu/aarch64/aarch64.ad
@@ -16463,14 +16463,14 @@ instruct cmpFastUnlock(rFlagsReg cr, iRegP object, iRegP box, iRegPNoSp tmp, iRe
   ins_pipe(pipe_serial);
 %}
 
-instruct cmpFastLockLightweight(rFlagsReg cr, iRegP object, iRegP box, iRegPNoSp tmp, iRegPNoSp tmp2)
+instruct cmpFastLockLightweight(rFlagsReg cr, iRegP object, iRegP_R0 box, iRegPNoSp tmp, iRegPNoSp tmp2)
 %{
   predicate(LockingMode == LM_LIGHTWEIGHT);
   match(Set cr (FastLock object box));
-  effect(TEMP tmp, TEMP tmp2);
+  effect(TEMP tmp, TEMP tmp2, USE_KILL box);
 
   ins_cost(5 * INSN_COST);
-  format %{ "fastlock $object,$box\t! kills $tmp,$tmp2" %}
+  format %{ "fastlock $object,$box\t! kills $tmp,$tmp2,$box" %}
 
   ins_encode %{
     __ fast_lock_lightweight($object$$Register, $box$$Register, $tmp$$Register, $tmp2$$Register);
@@ -16479,14 +16479,14 @@ instruct cmpFastLockLightweight(rFlagsReg cr, iRegP object, iRegP box, iRegPNoSp
   ins_pipe(pipe_serial);
 %}
 
-instruct cmpFastUnlockLightweight(rFlagsReg cr, iRegP object, iRegP box, iRegPNoSp tmp, iRegPNoSp tmp2)
+instruct cmpFastUnlockLightweight(rFlagsReg cr, iRegP object, iRegP_R0 box, iRegPNoSp tmp, iRegPNoSp tmp2)
 %{
   predicate(LockingMode == LM_LIGHTWEIGHT);
   match(Set cr (FastUnlock object box));
-  effect(TEMP tmp, TEMP tmp2);
+  effect(TEMP tmp, TEMP tmp2, USE_KILL box);
 
   ins_cost(5 * INSN_COST);
-  format %{ "fastunlock $object,$box\t! kills $tmp, $tmp2" %}
+  format %{ "fastunlock $object,$box\t! kills $tmp, $tmp2, $box" %}
 
   ins_encode %{
     __ fast_unlock_lightweight($object$$Register, $box$$Register, $tmp$$Register, $tmp2$$Register);


Maybe someone with better knowledge of the ADLC knows a better solution.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16611#issuecomment-1956024759

From stuefe at openjdk.org  Wed Feb 21 07:37:56 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 21 Feb 2024 07:37:56 GMT
Subject: RFR: JDK-8323497: On x64,
 use 32-bit immediate moves for narrow klass base if possible [v3]
In-Reply-To: <mglIjkgFXSmoyWh-NS1KubJrhbJS_iTiBAiA1MuVk8s=.ee747541-6812-4528-9190-78beb245a3d2@github.com>
References: <HTQ6J0zq0B3MQRpECfAn_vbkV-rTWN_rsnEVVgkJN0k=.44afeb5e-63a1-4de0-911b-d6db9c5532de@github.com>
 <ROMLODKlug0oMp4rU042kjZk79TPZZVrVp7fFxw6ISg=.98582e86-33b6-479e-84d2-b722b87b346d@github.com>
 <mglIjkgFXSmoyWh-NS1KubJrhbJS_iTiBAiA1MuVk8s=.ee747541-6812-4528-9190-78beb245a3d2@github.com>
Message-ID: <bvfiGC6cWXO2ZgvaNi4O9gehTX8KhvNcdqQ9HubYqEU=.d33c906f-a6e4-41d3-a6ab-cbbe159ca7c0@github.com>

On Tue, 20 Feb 2024 11:16:29 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into use-32bit-immediate-moves-on-x64-for-klass-encoding-base
>>  - Merge branch 'openjdk:master' into use-32bit-immediate-moves-on-x64-for-klass-encoding-base
>>  - remove obsolete comment
>>  - use-32bit-immediate-moves-on-x64-for-klass-encoding-base
>
> src/hotspot/cpu/x86/compressedKlass_x86.cpp line 44:
> 
>> 42:       result = reserve_address_space_for_zerobased_encoding(size, aslr);
>> 43:     }
>> 44:   } else {
> 
> This should be:
> 
>     if (result == nullptr) {
>         // If we cannot use zero-based encoding (when CDS is enabled), optimizing for an
>         ...
>     }

I don't think so. Why?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17340#discussion_r1497027400

From stuefe at openjdk.org  Wed Feb 21 07:47:08 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 21 Feb 2024 07:47:08 GMT
Subject: RFR: JDK-8323497: On x64,
 use 32-bit immediate moves for narrow klass base if possible [v4]
In-Reply-To: <HTQ6J0zq0B3MQRpECfAn_vbkV-rTWN_rsnEVVgkJN0k=.44afeb5e-63a1-4de0-911b-d6db9c5532de@github.com>
References: <HTQ6J0zq0B3MQRpECfAn_vbkV-rTWN_rsnEVVgkJN0k=.44afeb5e-63a1-4de0-911b-d6db9c5532de@github.com>
Message-ID: <2B4V5iFCuY7vBrFKa_UfVcMd-wg3ZcqQKtJMT9GqsME=.2f94f07e-9279-4e91-b863-d2c38772d68c@github.com>

> On x64, we always use the long form of mov immediate to load the klass base into a register. If the klass base fits into 32 bits, we could use the short form and save four instruction bytes. 
> 
> Before: mov uses 10 instruction bytes:
> 
> 
>    35  ;; decode_klass_not_null
>    36   0x00007f8b089e51c4:   movabs $0x82000000,%r11
>    37   0x00007f8b089e51ce:   add    %r11,%r10
> 
> 
> Now: mov uses 6 instruction bytes:
> 
> 
>    35  ;; decode_klass_not_null
>    36   0x00007fbe609e51c4:   mov    $0x82000000,%r11d
>    37   0x00007fbe609e51ca:   add    %r11,%r10
> 
> 
> Note that this optimization does not depend on zero-based addressing, and therefore we change class space reservation: we now always look in low-address regions first.
> 
> ----------
> 
> Tests: tier1 (GHA), tier 2 on x64 linux

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:

 - Merge branch 'openjdk:master' into use-32bit-immediate-moves-on-x64-for-klass-encoding-base
 - Merge branch 'openjdk:master' into use-32bit-immediate-moves-on-x64-for-klass-encoding-base
 - Merge branch 'openjdk:master' into use-32bit-immediate-moves-on-x64-for-klass-encoding-base
 - remove obsolete comment
 - use-32bit-immediate-moves-on-x64-for-klass-encoding-base

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17340/files
  - new: https://git.openjdk.org/jdk/pull/17340/files/7a9f0ccc..80069d0a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17340&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17340&range=02-03

  Stats: 1106 lines in 94 files changed: 653 ins; 164 del; 289 mod
  Patch: https://git.openjdk.org/jdk/pull/17340.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17340/head:pull/17340

PR: https://git.openjdk.org/jdk/pull/17340

From stuefe at openjdk.org  Wed Feb 21 07:47:09 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 21 Feb 2024 07:47:09 GMT
Subject: RFR: JDK-8323497: On x64,
 use 32-bit immediate moves for narrow klass base if possible [v3]
In-Reply-To: <mglIjkgFXSmoyWh-NS1KubJrhbJS_iTiBAiA1MuVk8s=.ee747541-6812-4528-9190-78beb245a3d2@github.com>
References: <HTQ6J0zq0B3MQRpECfAn_vbkV-rTWN_rsnEVVgkJN0k=.44afeb5e-63a1-4de0-911b-d6db9c5532de@github.com>
 <ROMLODKlug0oMp4rU042kjZk79TPZZVrVp7fFxw6ISg=.98582e86-33b6-479e-84d2-b722b87b346d@github.com>
 <mglIjkgFXSmoyWh-NS1KubJrhbJS_iTiBAiA1MuVk8s=.ee747541-6812-4528-9190-78beb245a3d2@github.com>
Message-ID: <EhjLTkNPBGhyYWTdvVxH2LwDgj6b7KiAQPlQJRS5RQY=.253bea2f-09ee-4f74-a301-f086dc2e2cf9@github.com>

On Tue, 20 Feb 2024 11:22:19 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into use-32bit-immediate-moves-on-x64-for-klass-encoding-base
>>  - Merge branch 'openjdk:master' into use-32bit-immediate-moves-on-x64-for-klass-encoding-base
>>  - remove obsolete comment
>>  - use-32bit-immediate-moves-on-x64-for-klass-encoding-base
>
> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 5596:
> 
>> 5594:   if (CompressedKlassPointers::base() != nullptr) {
>> 5595:     // Uses 32-bit mov if base is small enough
>> 5596:     movptr(tmp, (intptr_t)CompressedKlassPointers::base());
> 
> If we can reserve the base in the low 2G then this could be optimized further to `addq(r, CompressedKlassPointers::base())` and if `LogKlassAlignmentInBytes` is 8 (as asserted in `decode_and_move_klass_not_null` below), we can shorten the whole sequence into `leaq(r, Address(noreg, r, Address::times_8, CompressedKlassPointers::base())`

Nice! But could we do this in a follow-up RFE? I don't have any more time to spend on this atm, and I would like to get this PR at least integrated. It has been sitting in review for 7 weeks now.

I opened a follow-up RFE: https://bugs.openjdk.org/browse/JDK-8326383

(about the leaq, we may move to a different encoding scheme with a different shift value with Lilliput, so I am hesitant to put in too much work that relies on a 8-byte shift)

> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 5620:
> 
>> 5618:     } else {
>> 5619:       xorq(dst, dst);
>> 5620:     }
> 
> This can also be 1 instruction when the base is smaller than $2^{31}$.

See my remark above.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17340#discussion_r1497034895
PR Review Comment: https://git.openjdk.org/jdk/pull/17340#discussion_r1497035134

From duke at openjdk.org  Wed Feb 21 08:31:59 2024
From: duke at openjdk.org (kuaiwei)
Date: Wed, 21 Feb 2024 08:31:59 GMT
Subject: RFR: 8324186: Use "dmb.ishst+dmb.ishld" for release barrier [v4]
In-Reply-To: <mEDRJOCCKOBNaDk_m6yjFElCqSV7PE9934eGIjTF8po=.f265f265-ed89-4468-962c-807a3bef5e45@github.com>
References: <XZrDipOH9HF2OKvIextkB_Mcoi5Qb5w5OAn-FvnGvCY=.81067554-26eb-4876-ad37-e5a42596cdb1@github.com>
 <LrOAOXuZOtletxXe3sELJVfsyQYhF5MLImEEi3NEIe8=.47fda591-c73e-4aeb-b465-6dca323f6717@github.com>
 <iLpgzQhQj69WOZZYpd-t9ku2SRk5_7mFauLboNUMhYA=.f95ecccd-e839-407b-94d1-60b13a6da3f0@github.com>
 <ya_gz2XNHlXoxynYl5E99U9J3frKK_RSJifBvBy0ZpI=.6870c267-e5e2-4691-9bbb-8e41367eb301@github.com>
 <NdP71n-TYPswKhGANbbKw2_uyujL1OFDP8L1UFswzME=.690dc936-0136-4dd2-8f2a-5c05e1748020@github.com>
 <V3n9i9msuDBvaBDCIsv00Z36LikHCIIB3SbjB5Nt0NA=.dd803f90-4ede-43f1-9b62-9f52f7fb9d0e@github.com>
 <qPKqwnrRsp-ByIC3aFs1WtDskO9Ri6TeNV_9KtQPJvM=.6cf5ea4b-d41c-4b3f-b24f-92c57f6d7705@github.com>
 <mEDRJOCCKOBNaDk_m6yjFElCqSV7PE9934eGIjTF8po=.f265f265-ed89-4468-962c-807a3bef5e45@github.com>
Message-ID: <MjIqrcqY_0YKXP8mu3PlQIuK4UcHF1RvGD_ztMS5w4E=.1d619679-7910-44cc-805a-52d1a03c46c2@github.com>

On Mon, 29 Jan 2024 02:11:43 GMT, kuaiwei <duke at openjdk.org> wrote:

>>> > I wonder if this was tested on other vendors' hardware? I witnessed some negative impact at least on HiSilicon TSV110 running the same JMH. So I guess it might be safer to go as a vendor-specific change.
>>> 
>>> I tried a number of different machines and saw regressions only on Kunpeng-920 (same CPU?) and A57 which is quite niche at this point.
>> 
>> Right, so it's probably a low-end, mostly-in-order thing. That makes sense because we're trading a weaker barrier for more instructions, and perhaps some cores implement barriers in a crude one-size-fits-all way.
>
> @theRealAph @RealFYang Could you help to sponsor it? Thanks

> This introduced a performance regression, see [JDK-8325449](https://bugs.openjdk.org/browse/JDK-8325449) and [JDK-8325269](https://bugs.openjdk.org/browse/JDK-8325269). @kuaiwei, could you please have a look?

I missed the message. I will look these issues.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17511#issuecomment-1956125733

From mdoerr at openjdk.org  Wed Feb 21 08:47:57 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 21 Feb 2024 08:47:57 GMT
Subject: RFR: 8319901: Recursive lightweight locking: ppc64le
 implementation
In-Reply-To: <3LduAyBU7SzwJawH73jO5cAjVr5I0HJzs8y_jO9r3N4=.42388751-25b0-43fe-97c3-c4f95334bcfc@github.com>
References: <3LduAyBU7SzwJawH73jO5cAjVr5I0HJzs8y_jO9r3N4=.42388751-25b0-43fe-97c3-c4f95334bcfc@github.com>
Message-ID: <MaomaGVFDu0Gi4KMNlsQJCDZp2zNsnUpSRLrNfS5K5U=.b1dc8c51-07f9-4e8a-b3ca-c7a8947f3a30@github.com>

On Fri, 10 Nov 2023 13:21:58 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Draft implementation of recursive lightweight JDK-8319796 for ppc64le.
> 
> Porters feel free to discard this and implement something from scratch, take this initial draft and run with it, or send patches to me and if you want me to drive the PR.
> 
> Some notes:
> ppc64le deviates from the other ports, it shares it C2 locking code with the native call wrapper. This draft unifies the behavior across the ports by using the C1/interpreter locking for native call wrapper. If it is important to have a fast path for the inflated monitor case for native call wrapper, it could be done without having it share its implementation with C2. 
> It would also be possible to change this behavior on all ports (share the C2 code), as I believe the C2 assumptions always hold for the native call wrapper, the monitor exit and monitor enter will be balanced and structured.

> > Thanks a lot! LGTM.
> > Regarding aarch64: Should we file a JBS issue for the usage of `box`?
> > https://github.com/openjdk/jdk/blob/d31fd78d963d5d103b1b1bf66ae0bdbe4be2b790/src/hotspot/cpu/aarch64/aarch64.ad#L16470
> > 
> > has no kill effect for `box`, but `C2_MacroAssembler::fast_lock_lightweight` kills it. It may be never used, but it's a trap someone might run into. x86_64 uses `USE_KILL box`.
> > I think that it currently works, but I'd prefer to use a temp register and hopefully remove the `box` completely at some point of time. It could also be cleaned up together with other changes if you prefer that.
> 
> This came up in the review as well. The issue with `USE_KILL` and `KILL` is that they require a bound register to use. So we must restrict the box to a specific real register. (Works on x86 because it box is bound to `RAX`/`EAX`).
> 
> Should create a JBS issue for this. And maybe it is to dangerous to leave it as is until we can create a C2 Node that does not require the box.
> 
> The only potential fix I see is to actually bind the register. i.e.
> 
> ```diff
> diff --git a/src/hotspot/cpu/aarch64/aarch64.ad b/src/hotspot/cpu/aarch64/aarch64.ad
> index a07ff041c48..97d7898ceba 100644
> --- a/src/hotspot/cpu/aarch64/aarch64.ad
> +++ b/src/hotspot/cpu/aarch64/aarch64.ad
> @@ -16463,14 +16463,14 @@ instruct cmpFastUnlock(rFlagsReg cr, iRegP object, iRegP box, iRegPNoSp tmp, iRe
>    ins_pipe(pipe_serial);
>  %}
>  
> -instruct cmpFastLockLightweight(rFlagsReg cr, iRegP object, iRegP box, iRegPNoSp tmp, iRegPNoSp tmp2)
> +instruct cmpFastLockLightweight(rFlagsReg cr, iRegP object, iRegP_R0 box, iRegPNoSp tmp, iRegPNoSp tmp2)
>  %{
>    predicate(LockingMode == LM_LIGHTWEIGHT);
>    match(Set cr (FastLock object box));
> -  effect(TEMP tmp, TEMP tmp2);
> +  effect(TEMP tmp, TEMP tmp2, USE_KILL box);
>  
>    ins_cost(5 * INSN_COST);
> -  format %{ "fastlock $object,$box\t! kills $tmp,$tmp2" %}
> +  format %{ "fastlock $object,$box\t! kills $tmp,$tmp2,$box" %}
>  
>    ins_encode %{
>      __ fast_lock_lightweight($object$$Register, $box$$Register, $tmp$$Register, $tmp2$$Register);
> @@ -16479,14 +16479,14 @@ instruct cmpFastLockLightweight(rFlagsReg cr, iRegP object, iRegP box, iRegPNoSp
>    ins_pipe(pipe_serial);
>  %}
>  
> -instruct cmpFastUnlockLightweight(rFlagsReg cr, iRegP object, iRegP box, iRegPNoSp tmp, iRegPNoSp tmp2)
> +instruct cmpFastUnlockLightweight(rFlagsReg cr, iRegP object, iRegP_R0 box, iRegPNoSp tmp, iRegPNoSp tmp2)
>  %{
>    predicate(LockingMode == LM_LIGHTWEIGHT);
>    match(Set cr (FastUnlock object box));
> -  effect(TEMP tmp, TEMP tmp2);
> +  effect(TEMP tmp, TEMP tmp2, USE_KILL box);
>  
>    ins_cost(5 * INSN_COST);
> -  format %{ "fastunlock $object,$box\t! kills $tmp, $tmp2" %}
> +  format %{ "fastunlock $object,$box\t! kills $tmp, $tmp2, $box" %}
>  
>    ins_encode %{
>      __ fast_unlock_lightweight($object$$Register, $box$$Register, $tmp$$Register, $tmp2$$Register);
> ```
> 
> Maybe someone with better knowledge of the ADLC knows a better solution.

That is a known limitation. I've filed https://bugs.openjdk.org/browse/JDK-8326385. We should better continue discussions there.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16611#issuecomment-1956152214

From sspitsyn at openjdk.org  Wed Feb 21 10:36:05 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 21 Feb 2024 10:36:05 GMT
Subject: RFR: 8256314: JVM TI GetCurrentContendedMonitor is implemented
 incorrectly
Message-ID: <-Yf2Qj_kbyZAA-LDK96IIOcHWMh8__QT1XfnD9jR8kU=.507d5503-1544-44fb-9e81-438ba3458dcd@github.com>

The implementation of the JVM TI `GetCurrentContendedMonitor` does not match the spec. It can sometimes return an incorrect information about the contended monitor. Such a behavior does not match the function spec. 
With this update the `GetCurrentContendedMonitor` is returning the monitor only when the specified thread is waiting to enter or re-enter the monitor, and the monitor is not returned when the specified thread is waiting in the `java.lang.Object.wait` to be notified.

The implementation of the JDWP `ThreadReference.CurrentContendedMonitor` command is based and depends on this JVMTI function. The command was both specified incorrectly and had an incorrect behavior. The fix slightly corrects the JDWP spec to make it right (the JDWP implementation has been fixed by the JVM TI update). Please, see and review the related CSR and Release-Note.

CSR: [8326024](https://bugs.openjdk.org/browse/JDK-8326024): JVM TI GetCurrentContendedMonitor is implemented incorrectly
RN:   [8326038](https://bugs.openjdk.org/browse/JDK-8326038): Release Note: JVM TI GetCurrentContendedMonitor is implemented incorrectly

Testing:
 - tested with the mach5 tiers 1-6

-------------

Commit messages:
 - 8256314: JVM TI GetCurrentContendedMonitor is implemented incorrectly

Changes: https://git.openjdk.org/jdk/pull/17944/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17944&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8256314
  Stats: 46 lines in 5 files changed: 27 ins; 10 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/17944.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17944/head:pull/17944

PR: https://git.openjdk.org/jdk/pull/17944

From shade at openjdk.org  Wed Feb 21 10:49:55 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 21 Feb 2024 10:49:55 GMT
Subject: RFR: JDK-8323497: On x64,
 use 32-bit immediate moves for narrow klass base if possible [v4]
In-Reply-To: <2B4V5iFCuY7vBrFKa_UfVcMd-wg3ZcqQKtJMT9GqsME=.2f94f07e-9279-4e91-b863-d2c38772d68c@github.com>
References: <HTQ6J0zq0B3MQRpECfAn_vbkV-rTWN_rsnEVVgkJN0k=.44afeb5e-63a1-4de0-911b-d6db9c5532de@github.com>
 <2B4V5iFCuY7vBrFKa_UfVcMd-wg3ZcqQKtJMT9GqsME=.2f94f07e-9279-4e91-b863-d2c38772d68c@github.com>
Message-ID: <Vmy2UKV3fg7hpKBT-SWPMcZoMWLKtOmYp_wbAHZsBIc=.236f315d-d8f8-4acf-911e-76fb88767dbc@github.com>

On Wed, 21 Feb 2024 07:47:08 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> On x64, we always use the long form of mov immediate to load the klass base into a register. If the klass base fits into 32 bits, we could use the short form and save four instruction bytes. 
>> 
>> Before: mov uses 10 instruction bytes:
>> 
>> 
>>    35  ;; decode_klass_not_null
>>    36   0x00007f8b089e51c4:   movabs $0x82000000,%r11
>>    37   0x00007f8b089e51ce:   add    %r11,%r10
>> 
>> 
>> Now: mov uses 6 instruction bytes:
>> 
>> 
>>    35  ;; decode_klass_not_null
>>    36   0x00007fbe609e51c4:   mov    $0x82000000,%r11d
>>    37   0x00007fbe609e51ca:   add    %r11,%r10
>> 
>> 
>> Note that this optimization does not depend on zero-based addressing, and therefore we change class space reservation: we now always look in low-address regions first.
>> 
>> ----------
>> 
>> Tests: tier1 (GHA), tier 2 on x64 linux
>
> 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:
> 
>  - Merge branch 'openjdk:master' into use-32bit-immediate-moves-on-x64-for-klass-encoding-base
>  - Merge branch 'openjdk:master' into use-32bit-immediate-moves-on-x64-for-klass-encoding-base
>  - Merge branch 'openjdk:master' into use-32bit-immediate-moves-on-x64-for-klass-encoding-base
>  - remove obsolete comment
>  - use-32bit-immediate-moves-on-x64-for-klass-encoding-base

This looks reasonable to me, but it keeps me wondering if any code anywhere relies on compressed oops decoding path to take the exact amount of bytes. Could you please run `make test TEST=all` on at least one arch before integrating?

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17340#pullrequestreview-1892777200

From shade at openjdk.org  Wed Feb 21 10:49:56 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 21 Feb 2024 10:49:56 GMT
Subject: RFR: JDK-8323497: On x64,
 use 32-bit immediate moves for narrow klass base if possible [v3]
In-Reply-To: <bvfiGC6cWXO2ZgvaNi4O9gehTX8KhvNcdqQ9HubYqEU=.d33c906f-a6e4-41d3-a6ab-cbbe159ca7c0@github.com>
References: <HTQ6J0zq0B3MQRpECfAn_vbkV-rTWN_rsnEVVgkJN0k=.44afeb5e-63a1-4de0-911b-d6db9c5532de@github.com>
 <ROMLODKlug0oMp4rU042kjZk79TPZZVrVp7fFxw6ISg=.98582e86-33b6-479e-84d2-b722b87b346d@github.com>
 <mglIjkgFXSmoyWh-NS1KubJrhbJS_iTiBAiA1MuVk8s=.ee747541-6812-4528-9190-78beb245a3d2@github.com>
 <bvfiGC6cWXO2ZgvaNi4O9gehTX8KhvNcdqQ9HubYqEU=.d33c906f-a6e4-41d3-a6ab-cbbe159ca7c0@github.com>
Message-ID: <MkEmR811n1NI9xOvqGV4hktm6oAXe5cTU38vrXiiOOE=.c556f126-1941-4e23-b01d-79c7eb38e30c@github.com>

On Wed, 21 Feb 2024 07:35:23 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/cpu/x86/compressedKlass_x86.cpp line 44:
>> 
>>> 42:       result = reserve_address_space_for_zerobased_encoding(size, aslr);
>>> 43:     }
>>> 44:   } else {
>> 
>> This should be:
>> 
>>     if (result == nullptr) {
>>         // If we cannot use zero-based encoding (when CDS is enabled), optimizing for an
>>         ...
>>     }
>
> I don't think so. Why?

I think the point is to reflow this into the series of ifs:


char* result = nullptr;
if (optimize_for_zero_base) {
   result = ...
}

if (result == nullptr) {
   result = ...
}


Probably good for future maintenance if we want to add more cases in this block.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17340#discussion_r1497302551

From stuefe at openjdk.org  Wed Feb 21 11:14:54 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 21 Feb 2024 11:14:54 GMT
Subject: RFR: JDK-8323497: On x64,
 use 32-bit immediate moves for narrow klass base if possible [v3]
In-Reply-To: <MkEmR811n1NI9xOvqGV4hktm6oAXe5cTU38vrXiiOOE=.c556f126-1941-4e23-b01d-79c7eb38e30c@github.com>
References: <HTQ6J0zq0B3MQRpECfAn_vbkV-rTWN_rsnEVVgkJN0k=.44afeb5e-63a1-4de0-911b-d6db9c5532de@github.com>
 <ROMLODKlug0oMp4rU042kjZk79TPZZVrVp7fFxw6ISg=.98582e86-33b6-479e-84d2-b722b87b346d@github.com>
 <mglIjkgFXSmoyWh-NS1KubJrhbJS_iTiBAiA1MuVk8s=.ee747541-6812-4528-9190-78beb245a3d2@github.com>
 <bvfiGC6cWXO2ZgvaNi4O9gehTX8KhvNcdqQ9HubYqEU=.d33c906f-a6e4-41d3-a6ab-cbbe159ca7c0@github.com>
 <MkEmR811n1NI9xOvqGV4hktm6oAXe5cTU38vrXiiOOE=.c556f126-1941-4e23-b01d-79c7eb38e30c@github.com>
Message-ID: <e4xllDP_zJgFU0ntB4D35G3rim5HJqrLKXwOS0t7jKU=.54366222-ea2a-468c-a87b-5e2d2799d724@github.com>

On Wed, 21 Feb 2024 10:46:27 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> I don't think so. Why?
>
> I think the point is to reflow this into the series of ifs:
> 
> 
> char* result = nullptr;
> if (optimize_for_zero_base) {
>    result = ...
> }
> 
> if (result == nullptr) {
>    result = ...
> }
> 
> 
> Probably good for future maintenance if we want to add more cases in this block.

Ah okay. But that's wrong, since for the optimize_for_zero_base case, we would search the low address regions twice.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17340#discussion_r1497344358

From rkennke at openjdk.org  Wed Feb 21 11:36:34 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 21 Feb 2024 11:36:34 GMT
Subject: RFR: 8139457: Relax alignment of array elements [v65]
In-Reply-To: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
References: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
Message-ID: <474Cp5qDgHyppRBgkl1OHixEpCacSZfZoQrzuHRowAg=.f5a7cfa2-c300-4e07-b594-34d6351eafb4@github.com>

> See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details.
> 
> Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements.
> 
> Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16.
> 
> Testing:
>  - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390)
>  - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390)
>  - [x] tier1 (x86_64, x86_32, aarch64, riscv)
>  - [x] tier2 (x86_64, aarch64, riscv)
>  - [x] tier3 (x86_64, riscv)

Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:

 - Update copyright years
 - Remove duplicate code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11044/files
  - new: https://git.openjdk.org/jdk/pull/11044/files/d0ec1fa2..eb303719

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=64
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=63-64

  Stats: 26 lines in 24 files changed: 0 ins; 1 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/11044.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/11044/head:pull/11044

PR: https://git.openjdk.org/jdk/pull/11044

From fbredberg at openjdk.org  Wed Feb 21 12:16:05 2024
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 21 Feb 2024 12:16:05 GMT
Subject: RFR: 8325153: SEGV in stackChunkOopDesc::derelativize_address(int)
Message-ID: <qc0gmrEb_xZ8mtY1wIa0odNvUOkZL1GmjfLD25px9uY=.fd3a5704-a89c-46fb-bb16-7d988c8fc435@github.com>

The JVM used to SEGV when running jdk/internal/vm/Continuation/Fuzz.java with '-Xlog:all=trace:file=hotspot.%p.log'

The problem was this line in StackWalk::fetchNextBatch() at src/hotspot/share/prims/stackwalk.cpp:547:

log_debug(stackwalk)("advanced past %s", stream.method()->external_name());

It is not always safe to dig out the name of the last frame here. The second batch is resource allocated on top of the first batch, so there is no crash when we dig out the last name from the first batch. However the third batch, is resource allocated on the same stack level as the second, which means that the second batch has been reclaimed. Thus trying to reach into the second batch when processing the third will cause a segmentation violation.

Now passes:
jdk/internal/vm/Continuation/Fuzz.java with '-Xlog:all=trace:file=hotspot.%p.log'
As well as tier1-tier5

-------------

Commit messages:
 - 8325153_segv_in_derelativize_address

Changes: https://git.openjdk.org/jdk/pull/17942/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17942&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8325153
  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17942.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17942/head:pull/17942

PR: https://git.openjdk.org/jdk/pull/17942

From stefank at openjdk.org  Wed Feb 21 12:48:05 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 21 Feb 2024 12:48:05 GMT
Subject: RFR: 8139457: Relax alignment of array elements [v65]
In-Reply-To: <474Cp5qDgHyppRBgkl1OHixEpCacSZfZoQrzuHRowAg=.f5a7cfa2-c300-4e07-b594-34d6351eafb4@github.com>
References: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
 <474Cp5qDgHyppRBgkl1OHixEpCacSZfZoQrzuHRowAg=.f5a7cfa2-c300-4e07-b594-34d6351eafb4@github.com>
Message-ID: <jUPtSiJRrjfrPAbhJfJA0p1DjSalqr1tNrrFZk-xcro=.8e3a1485-0231-40e4-a2ee-a956aa687571@github.com>

On Wed, 21 Feb 2024 11:36:34 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details.
>> 
>> Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements.
>> 
>> Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16.
>> 
>> Testing:
>>  - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390)
>>  - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390)
>>  - [x] tier1 (x86_64, x86_32, aarch64, riscv)
>>  - [x] tier2 (x86_64, aarch64, riscv)
>>  - [x] tier3 (x86_64, riscv)
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright years
>  - Remove duplicate code

I re-reviewed the the `src/hotspot/share` changes. It think those changes look good.

-------------

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/11044#pullrequestreview-1893108274

From qamai at openjdk.org  Wed Feb 21 12:54:55 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 21 Feb 2024 12:54:55 GMT
Subject: RFR: JDK-8323497: On x64,
 use 32-bit immediate moves for narrow klass base if possible [v3]
In-Reply-To: <EhjLTkNPBGhyYWTdvVxH2LwDgj6b7KiAQPlQJRS5RQY=.253bea2f-09ee-4f74-a301-f086dc2e2cf9@github.com>
References: <HTQ6J0zq0B3MQRpECfAn_vbkV-rTWN_rsnEVVgkJN0k=.44afeb5e-63a1-4de0-911b-d6db9c5532de@github.com>
 <ROMLODKlug0oMp4rU042kjZk79TPZZVrVp7fFxw6ISg=.98582e86-33b6-479e-84d2-b722b87b346d@github.com>
 <mglIjkgFXSmoyWh-NS1KubJrhbJS_iTiBAiA1MuVk8s=.ee747541-6812-4528-9190-78beb245a3d2@github.com>
 <EhjLTkNPBGhyYWTdvVxH2LwDgj6b7KiAQPlQJRS5RQY=.253bea2f-09ee-4f74-a301-f086dc2e2cf9@github.com>
Message-ID: <vld9osOtsWn3fXXKLdoFm8M6dI1SfmVdwTY6GW4tsag=.86ebb9d5-4126-475c-845e-12fe346ffa9f@github.com>

On Wed, 21 Feb 2024 07:42:45 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 5596:
>> 
>>> 5594:   if (CompressedKlassPointers::base() != nullptr) {
>>> 5595:     // Uses 32-bit mov if base is small enough
>>> 5596:     movptr(tmp, (intptr_t)CompressedKlassPointers::base());
>> 
>> If we can reserve the base in the low 2G then this could be optimized further to `addq(r, CompressedKlassPointers::base())` and if `LogKlassAlignmentInBytes` is 8 (as asserted in `decode_and_move_klass_not_null` below), we can shorten the whole sequence into `leaq(r, Address(noreg, r, Address::times_8, CompressedKlassPointers::base())`
>
> Nice! But could we do this in a follow-up RFE? I don't have any more time to spend on this atm, and I would like to get this PR at least integrated. It has been sitting in review for 7 weeks now.
> 
> I opened a follow-up RFE: https://bugs.openjdk.org/browse/JDK-8326383
> 
> (about the leaq, we may move to a different encoding scheme with a different shift value with Lilliput, so I am hesitant to put in too much work that relies on a 8-byte shift)

I agree with that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17340#discussion_r1497489620

From qamai at openjdk.org  Wed Feb 21 13:48:55 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 21 Feb 2024 13:48:55 GMT
Subject: RFR: JDK-8323497: On x64,
 use 32-bit immediate moves for narrow klass base if possible [v3]
In-Reply-To: <e4xllDP_zJgFU0ntB4D35G3rim5HJqrLKXwOS0t7jKU=.54366222-ea2a-468c-a87b-5e2d2799d724@github.com>
References: <HTQ6J0zq0B3MQRpECfAn_vbkV-rTWN_rsnEVVgkJN0k=.44afeb5e-63a1-4de0-911b-d6db9c5532de@github.com>
 <ROMLODKlug0oMp4rU042kjZk79TPZZVrVp7fFxw6ISg=.98582e86-33b6-479e-84d2-b722b87b346d@github.com>
 <mglIjkgFXSmoyWh-NS1KubJrhbJS_iTiBAiA1MuVk8s=.ee747541-6812-4528-9190-78beb245a3d2@github.com>
 <bvfiGC6cWXO2ZgvaNi4O9gehTX8KhvNcdqQ9HubYqEU=.d33c906f-a6e4-41d3-a6ab-cbbe159ca7c0@github.com>
 <MkEmR811n1NI9xOvqGV4hktm6oAXe5cTU38vrXiiOOE=.c556f126-1941-4e23-b01d-79c7eb38e30c@github.com>
 <e4xllDP_zJgFU0ntB4D35G3rim5HJqrLKXwOS0t7jKU=.54366222-ea2a-468c-a87b-5e2d2799d724@github.com>
Message-ID: <8uv53a3AFQzlrACYltkOhH3w8x4GTa5BVvEBj2CKlE8=.2e9c8906-3657-4be6-8d93-fc044073f3df@github.com>

On Wed, 21 Feb 2024 11:12:27 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> I think the point is to reflow this into the series of ifs:
>> 
>> 
>> char* result = nullptr;
>> if (optimize_for_zero_base) {
>>    result = ...
>> }
>> 
>> if (result == nullptr) {
>>    result = ...
>> }
>> 
>> 
>> Probably good for future maintenance if we want to add more cases in this block.
>
> Ah okay. But that's wrong, since for the optimize_for_zero_base case, we would search the low address regions twice.

Why do you need to whole space to lie between 0 and 4G then, it seems you only want to have the base being < 4G, then the top of the klass space can be upto size + 4G

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17340#discussion_r1497586913

From tonyp at openjdk.org  Wed Feb 21 13:58:53 2024
From: tonyp at openjdk.org (Antonios Printezis)
Date: Wed, 21 Feb 2024 13:58:53 GMT
Subject: RFR: 8326235: RISC-V: Size CodeCache for short calls encoding
In-Reply-To: <MHf3cpwm83ITBdp9IbzDbEvWjye3zKRLpxO0cCV9OVQ=.fc534a38-6d2b-4fb2-8a2f-b9b498dc1414@github.com>
References: <MHf3cpwm83ITBdp9IbzDbEvWjye3zKRLpxO0cCV9OVQ=.fc534a38-6d2b-4fb2-8a2f-b9b498dc1414@github.com>
Message-ID: <aFTi13APrwJDxHIfH-dUZPD7xipbseo7UC6HlPmvXY4=.4a49b483-8985-4127-a59e-34ca99736c9c@github.com>

On Tue, 20 Feb 2024 08:28:18 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Hi, please consider.
> 
> This limits the code cache to a size such that all code cache -> code cache calls and jump may always use auipc+jalr.
> (this is what we do in practice)
> Thus we can fix the encoding for those and not have variable encoding.
> The reduction of the size is just 2k, but due to option passing the real reduction is probably 1M.
> -XX:ReservedCodeCacheSize=2047M (down from 2048)
> 
> Note, specifying '2G' gives the message:
> 
>> Invalid ReservedCodeCacheSize=2048M. Must be at most 2047M.
> 
> Manually test, no test I found uses this large code cache.

Marked as reviewed by tonyp (Reviewer).

Looks good.

-------------

PR Review: https://git.openjdk.org/jdk/pull/17924#pullrequestreview-1893275418
PR Comment: https://git.openjdk.org/jdk/pull/17924#issuecomment-1956699876

From rehn at openjdk.org  Wed Feb 21 13:58:54 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 21 Feb 2024 13:58:54 GMT
Subject: RFR: 8326235: RISC-V: Size CodeCache for short calls encoding
In-Reply-To: <aFTi13APrwJDxHIfH-dUZPD7xipbseo7UC6HlPmvXY4=.4a49b483-8985-4127-a59e-34ca99736c9c@github.com>
References: <MHf3cpwm83ITBdp9IbzDbEvWjye3zKRLpxO0cCV9OVQ=.fc534a38-6d2b-4fb2-8a2f-b9b498dc1414@github.com>
 <aFTi13APrwJDxHIfH-dUZPD7xipbseo7UC6HlPmvXY4=.4a49b483-8985-4127-a59e-34ca99736c9c@github.com>
Message-ID: <xgjbZIJPdkK6TS4MXrsfc5rjzYIbApWhEtF68DKuy1c=.b2bf455f-93d7-49f8-9679-c14bf30d199d@github.com>

On Wed, 21 Feb 2024 13:52:03 GMT, Antonios Printezis <tonyp at openjdk.org> wrote:

> Looks good.

Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17924#issuecomment-1956702356

From stuefe at openjdk.org  Wed Feb 21 13:59:55 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 21 Feb 2024 13:59:55 GMT
Subject: RFR: JDK-8323497: On x64,
 use 32-bit immediate moves for narrow klass base if possible [v3]
In-Reply-To: <8uv53a3AFQzlrACYltkOhH3w8x4GTa5BVvEBj2CKlE8=.2e9c8906-3657-4be6-8d93-fc044073f3df@github.com>
References: <HTQ6J0zq0B3MQRpECfAn_vbkV-rTWN_rsnEVVgkJN0k=.44afeb5e-63a1-4de0-911b-d6db9c5532de@github.com>
 <ROMLODKlug0oMp4rU042kjZk79TPZZVrVp7fFxw6ISg=.98582e86-33b6-479e-84d2-b722b87b346d@github.com>
 <mglIjkgFXSmoyWh-NS1KubJrhbJS_iTiBAiA1MuVk8s=.ee747541-6812-4528-9190-78beb245a3d2@github.com>
 <bvfiGC6cWXO2ZgvaNi4O9gehTX8KhvNcdqQ9HubYqEU=.d33c906f-a6e4-41d3-a6ab-cbbe159ca7c0@github.com>
 <MkEmR811n1NI9xOvqGV4hktm6oAXe5cTU38vrXiiOOE=.c556f126-1941-4e23-b01d-79c7eb38e30c@github.com>
 <e4xllDP_zJgFU0ntB4D35G3rim5HJqrLKXwOS0t7jKU=.54366222-ea2a-468c-a87b-5e2d2799d724@github.com>
 <8uv53a3AFQzlrACYltkOhH3w8x4GTa5BVvEBj2CKlE8=.2e9c8906-3657-4be6-8d93-fc044073f3df@github.com>
Message-ID: <tmoMMq3LICbVF4TFbSj_pl3YhQzaqyzYnzG495oI6uM=.67e0e778-8476-4b8c-8a4c-b4b95c01fe8f@github.com>

On Wed, 21 Feb 2024 13:46:20 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Ah okay. But that's wrong, since for the optimize_for_zero_base case, we would search the low address regions twice.
>
> Why do you need to whole space to lie between 0 and 4G then, it seems you only want to have the base being < 4G, then the top of the klass space can be upto size + 4G

Ah, right, good catch.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17340#discussion_r1497607865

From qamai at openjdk.org  Wed Feb 21 14:03:54 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 21 Feb 2024 14:03:54 GMT
Subject: RFR: JDK-8323497: On x64,
 use 32-bit immediate moves for narrow klass base if possible [v3]
In-Reply-To: <tmoMMq3LICbVF4TFbSj_pl3YhQzaqyzYnzG495oI6uM=.67e0e778-8476-4b8c-8a4c-b4b95c01fe8f@github.com>
References: <HTQ6J0zq0B3MQRpECfAn_vbkV-rTWN_rsnEVVgkJN0k=.44afeb5e-63a1-4de0-911b-d6db9c5532de@github.com>
 <ROMLODKlug0oMp4rU042kjZk79TPZZVrVp7fFxw6ISg=.98582e86-33b6-479e-84d2-b722b87b346d@github.com>
 <mglIjkgFXSmoyWh-NS1KubJrhbJS_iTiBAiA1MuVk8s=.ee747541-6812-4528-9190-78beb245a3d2@github.com>
 <bvfiGC6cWXO2ZgvaNi4O9gehTX8KhvNcdqQ9HubYqEU=.d33c906f-a6e4-41d3-a6ab-cbbe159ca7c0@github.com>
 <MkEmR811n1NI9xOvqGV4hktm6oAXe5cTU38vrXiiOOE=.c556f126-1941-4e23-b01d-79c7eb38e30c@github.com>
 <e4xllDP_zJgFU0ntB4D35G3rim5HJqrLKXwOS0t7jKU=.54366222-ea2a-468c-a87b-5e2d2799d724@github.com>
 <8uv53a3AFQzlrACYltkOhH3w8x4GTa5BVvEBj2CKlE8=.2e9c8906-3657-4be6-8d93-fc044073f3df@github.com>
 <tmoMMq3LICbVF4TFbSj_pl3YhQzaqyzYnzG495oI6uM=.67e0e778-8476-4b8c-8a4c-b4b95c01fe8f@github.com>
Message-ID: <I831DYFnMnk9LXj5LVOcA7Xd3I-ztKEkYL10jwaxQIY=.a22f4a23-a12b-44fd-abf8-4dc068af3588@github.com>

On Wed, 21 Feb 2024 13:57:23 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Why do you need to whole space to lie between 0 and 4G then, it seems you only want to have the base being < 4G, then the top of the klass space can be upto size + 4G
>
> Ah, right, good catch.

And yes, you are correct that this only applies when `optimize_for_zero_base` is `false`. Since in the other case we have already tried a much larger space up to $2^{32 + LogKlassAlignmentInBytes}$.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17340#discussion_r1497614800

From stefank at openjdk.org  Wed Feb 21 14:08:55 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 21 Feb 2024 14:08:55 GMT
Subject: RFR: 8325153: SEGV in stackChunkOopDesc::derelativize_address(int)
In-Reply-To: <qc0gmrEb_xZ8mtY1wIa0odNvUOkZL1GmjfLD25px9uY=.fd3a5704-a89c-46fb-bb16-7d988c8fc435@github.com>
References: <qc0gmrEb_xZ8mtY1wIa0odNvUOkZL1GmjfLD25px9uY=.fd3a5704-a89c-46fb-bb16-7d988c8fc435@github.com>
Message-ID: <txJ8smiz3an0VCVFK7M0RUxqZbHlitEWSDVJS2XFcQc=.32aa5afc-9f18-43b9-8402-53360ee01367@github.com>

On Wed, 21 Feb 2024 09:21:11 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> The JVM used to SEGV when running jdk/internal/vm/Continuation/Fuzz.java with '-Xlog:all=trace:file=hotspot.%p.log'
> 
> The problem was this line in StackWalk::fetchNextBatch() at src/hotspot/share/prims/stackwalk.cpp:547:
> 
> log_debug(stackwalk)("advanced past %s", stream.method()->external_name());
> 
> It is not always safe to dig out the name of the last frame here. The second batch is resource allocated on top of the first batch, so there is no crash when we dig out the last name from the first batch. However the third batch, is resource allocated on the same stack level as the second, which means that the second batch has been reclaimed. Thus trying to reach into the second batch when processing the third will cause a segmentation violation.
> 
> Now passes:
> jdk/internal/vm/Continuation/Fuzz.java with '-Xlog:all=trace:file=hotspot.%p.log'
> As well as tier1-tier5

Marked as reviewed by stefank (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17942#pullrequestreview-1893302794

From rehn at openjdk.org  Wed Feb 21 14:35:59 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 21 Feb 2024 14:35:59 GMT
Subject: Integrated: 8326235: RISC-V: Size CodeCache for short calls encoding
In-Reply-To: <MHf3cpwm83ITBdp9IbzDbEvWjye3zKRLpxO0cCV9OVQ=.fc534a38-6d2b-4fb2-8a2f-b9b498dc1414@github.com>
References: <MHf3cpwm83ITBdp9IbzDbEvWjye3zKRLpxO0cCV9OVQ=.fc534a38-6d2b-4fb2-8a2f-b9b498dc1414@github.com>
Message-ID: <SEFRM_h4K6VcRUmtLNO1_GkgFWp3oYp8w19I3xGe1eU=.391bc4b3-f1eb-44de-8e94-4638d254a6b1@github.com>

On Tue, 20 Feb 2024 08:28:18 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Hi, please consider.
> 
> This limits the code cache to a size such that all code cache -> code cache calls and jump may always use auipc+jalr.
> (this is what we do in practice)
> Thus we can fix the encoding for those and not have variable encoding.
> The reduction of the size is just 2k, but due to option passing the real reduction is probably 1M.
> -XX:ReservedCodeCacheSize=2047M (down from 2048)
> 
> Note, specifying '2G' gives the message:
> 
>> Invalid ReservedCodeCacheSize=2048M. Must be at most 2047M.
> 
> Manually test, no test I found uses this large code cache.

This pull request has now been integrated.

Changeset: 51e2dde0
Author:    Robbin Ehn <rehn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/51e2dde018746f419922ae40cd039cd6f27f1b75
Stats:     10 lines in 2 files changed: 8 ins; 2 del; 0 mod

8326235: RISC-V: Size CodeCache for short calls encoding

Reviewed-by: fyang, tonyp

-------------

PR: https://git.openjdk.org/jdk/pull/17924

From coleenp at openjdk.org  Wed Feb 21 14:36:07 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 21 Feb 2024 14:36:07 GMT
Subject: RFR: 8139457: Relax alignment of array elements [v65]
In-Reply-To: <474Cp5qDgHyppRBgkl1OHixEpCacSZfZoQrzuHRowAg=.f5a7cfa2-c300-4e07-b594-34d6351eafb4@github.com>
References: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
 <474Cp5qDgHyppRBgkl1OHixEpCacSZfZoQrzuHRowAg=.f5a7cfa2-c300-4e07-b594-34d6351eafb4@github.com>
Message-ID: <CCGkDMhhWYDxJrl2dPS0LTIVaFCdB0qARcbGuzOMBbM=.ba6fb463-7ccf-4654-9f8e-0ec1a8824944@github.com>

On Wed, 21 Feb 2024 11:36:34 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details.
>> 
>> Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements.
>> 
>> Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16.
>> 
>> Testing:
>>  - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390)
>>  - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390)
>>  - [x] tier1 (x86_64, x86_32, aarch64, riscv)
>>  - [x] tier2 (x86_64, aarch64, riscv)
>>  - [x] tier3 (x86_64, riscv)
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright years
>  - Remove duplicate code

My testing for tiers 1-7 had 100% passing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/11044#issuecomment-1956784401

From aboldtch at openjdk.org  Wed Feb 21 14:40:05 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 21 Feb 2024 14:40:05 GMT
Subject: RFR: 8325870: Zap end padding bits for ArrayOops in non-release
 builds [v2]
In-Reply-To: <xgOWw0IQ0eQC0CDEqok0nnpLs4mxaJFL_rsUzutCnfI=.76d226fe-e9a4-4d05-8440-53df8d1dea00@github.com>
References: <xgOWw0IQ0eQC0CDEqok0nnpLs4mxaJFL_rsUzutCnfI=.76d226fe-e9a4-4d05-8440-53df8d1dea00@github.com>
Message-ID: <uaOTZ1Fy2T-T_lg6zmczYcREvcTgWMq01gl7eb16fFk=.3a16fa3d-5d7e-46bc-bd59-dacab77a3218@github.com>

> Make `ObjArrayAllocator` zap the end padding bits in not PRODUCT builds.
> 
> Issues like [JDK-8325074](https://bugs.openjdk.org/browse/JDK-8325074) / #17863 would then reproduce deterministically. Avoid future regressions.
> 
> Guarded `Copy::fill_to_bytes`, it was not clear if or how it handles `count == 0`. Given that almost all dispatch to memset, the `count == 0` would probably be alright, but as `obj_end - padding_in_bytes` may point beyond an object and thus outside the heap it seems prudent to guard it (I believe memset requires a valid pointer).

Axel Boldt-Christmas has updated the pull request incrementally with three additional commits since the last revision:

 - Update copyright years
 - Use *_end pointers and add assert
 - Rename heapPaddingByte to heapPaddingByteVal

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17864/files
  - new: https://git.openjdk.org/jdk/pull/17864/files/9504304e..eec91e9e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17864&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17864&range=00-01

  Stats: 24 lines in 4 files changed: 2 ins; 0 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/17864.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17864/head:pull/17864

PR: https://git.openjdk.org/jdk/pull/17864

From ayang at openjdk.org  Wed Feb 21 14:55:54 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 21 Feb 2024 14:55:54 GMT
Subject: RFR: 8325870: Zap end padding bits for ArrayOops in non-release
 builds [v2]
In-Reply-To: <uaOTZ1Fy2T-T_lg6zmczYcREvcTgWMq01gl7eb16fFk=.3a16fa3d-5d7e-46bc-bd59-dacab77a3218@github.com>
References: <xgOWw0IQ0eQC0CDEqok0nnpLs4mxaJFL_rsUzutCnfI=.76d226fe-e9a4-4d05-8440-53df8d1dea00@github.com>
 <uaOTZ1Fy2T-T_lg6zmczYcREvcTgWMq01gl7eb16fFk=.3a16fa3d-5d7e-46bc-bd59-dacab77a3218@github.com>
Message-ID: <vZb-zWDGSkl2H7fqEJt8QNUYF19wks_wTVN9rwYzIBs=.2a74b62c-2868-4ae9-bd53-450c6d1b7088@github.com>

On Wed, 21 Feb 2024 14:40:05 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Make `ObjArrayAllocator` zap the end padding bits in not PRODUCT builds.
>> 
>> Issues like [JDK-8325074](https://bugs.openjdk.org/browse/JDK-8325074) / #17863 would then reproduce deterministically. Avoid future regressions.
>> 
>> Guarded `Copy::fill_to_bytes`, it was not clear if or how it handles `count == 0`. Given that almost all dispatch to memset, the `count == 0` would probably be alright, but as `obj_end - padding_in_bytes` may point beyond an object and thus outside the heap it seems prudent to guard it (I believe memset requires a valid pointer).
>
> Axel Boldt-Christmas has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update copyright years
>  - Use *_end pointers and add assert
>  - Rename heapPaddingByte to heapPaddingByteVal

Marked as reviewed by ayang (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17864#pullrequestreview-1893430310

From coleenp at openjdk.org  Wed Feb 21 15:00:54 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 21 Feb 2024 15:00:54 GMT
Subject: RFR: 8325153: SEGV in stackChunkOopDesc::derelativize_address(int)
In-Reply-To: <qc0gmrEb_xZ8mtY1wIa0odNvUOkZL1GmjfLD25px9uY=.fd3a5704-a89c-46fb-bb16-7d988c8fc435@github.com>
References: <qc0gmrEb_xZ8mtY1wIa0odNvUOkZL1GmjfLD25px9uY=.fd3a5704-a89c-46fb-bb16-7d988c8fc435@github.com>
Message-ID: <VBQvZPR2sjjdgieJnLaeJthL6IH3QiiLDWRicJKdguQ=.fce9c329-7b0e-4274-9357-fb5a1c2cd01b@github.com>

On Wed, 21 Feb 2024 09:21:11 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> The JVM used to SEGV when running jdk/internal/vm/Continuation/Fuzz.java with '-Xlog:all=trace:file=hotspot.%p.log'
> 
> The problem was this line in StackWalk::fetchNextBatch() at src/hotspot/share/prims/stackwalk.cpp:547:
> 
> log_debug(stackwalk)("advanced past %s", stream.method()->external_name());
> 
> It is not always safe to dig out the name of the last frame here. The second batch is resource allocated on top of the first batch, so there is no crash when we dig out the last name from the first batch. However the third batch, is resource allocated on the same stack level as the second, which means that the second batch has been reclaimed. Thus trying to reach into the second batch when processing the third will cause a segmentation violation.
> 
> Now passes:
> jdk/internal/vm/Continuation/Fuzz.java with '-Xlog:all=trace:file=hotspot.%p.log'
> As well as tier1-tier5

src/hotspot/share/prims/stackwalk.cpp line 551:

> 549:       // have been reclaimed by HandleMark::pop_and_restore() together
> 550:       // with the rest of the previous batch.
> 551:       log_debug(stackwalk)("advanced past last frame decoded in the previous batch");

Your description says ResourceMark but this comment says HandleMark.  Stream is native memory allocated as a secret field of the frames_array somewhere (resource allocated?), and frames_array is a Handle subject to HandleMark.  I don't understand which got deallocated with this comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17942#discussion_r1497737210

From patrick at os.amperecomputing.com  Wed Feb 21 15:25:22 2024
From: patrick at os.amperecomputing.com (Patrick Zhang OS)
Date: Wed, 21 Feb 2024 15:25:22 +0000
Subject: Question: 8324776: How to safely tell if MADV_POPULATE_WRITE is
 supported
Message-ID: <CO1PR01MB6694E52F1968421CE1D8E2968F572@CO1PR01MB6694.prod.exchangelabs.com>

Hi,

I have a question regarding the regression reported by [1] which was caused by the commit [2].

The root cause can be briefly described as: MADV_POPULATE_WRITE has been supported since Linux 5.14. It is suggested to call madvise(0, 0, advice) to tell if this madvise mode is valid, which "will return zero iff advice is supported by the kernel and can be relied on to probe for support" [3]. However Oracle UEKR6 5.4.17 has a duplicate definition of the number 23: MADV_DONTEXEC [4]. As a result, the test passes on Linux 5.4 mainline, while fails on UEK 5.4.17, because madvise(0, 0, 23) gives different return values. See details at [5].

It is a dilemma that how to fix so inside JVM. Thanks for any advice.

[1] https://bugs.openjdk.org/browse/JDK-8324776 runtime/os/TestTransparentHugePageUsage.java fails with The usage of THP is not enough
[2] https://bugs.openjdk.org/browse/JDK-8315923 pretouch_memory by atomic-add-0 fragments huge pages unexpectedly
[3] https://www.man7.org/linux/man-pages/man2/madvise.2.html
[4] https://yum.oracle.com/repo/OracleLinux/OL8/developer/UEKR6/aarch64/getPackageSource/kernel-uek-5.4.17-2136.327.2.el8uek.src.rpm, linux-5.4.17/include/uapi/asm-generic/mman-common.h#L75
[5] https://bugs.openjdk.org/browse/JDK-8324776?focusedId=14651275&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14651275.

Regards
Patrick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20240221/221ee6a5/attachment-0001.htm>

From sgibbons at openjdk.org  Wed Feb 21 15:51:09 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Wed, 21 Feb 2024 15:51:09 GMT
Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v12]
In-Reply-To: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
Message-ID: <V2VKX__XWo0uluz7ch6pZl-JpvBcS3kbNSYxPQK4Pjg=.0103d479-5b0f-4f43-b104-fd7315f350b2@github.com>

> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
> 
> 
> Benchmark	                                               Score		Latest		
> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
> StringIndexOf.success	                                9.186		9.713		1.057369911x
> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Fix slowdebug compile issues.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/71ebf9e7..62e4e8b1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=10-11

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16753/head:pull/16753

PR: https://git.openjdk.org/jdk/pull/16753

From sgibbons at openjdk.org  Wed Feb 21 15:53:56 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Wed, 21 Feb 2024 15:53:56 GMT
Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v8]
In-Reply-To: <I7EqdqNzJRToGpBfODbuNA5DtqTuCzQvgpGgFc8aeVw=.340e86b3-f7bc-42f0-8e85-f5d1f174b3a0@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <ZodY1FIPk3VAbz3nRKDmnKGHByEj_ygOBUR4SbG-6oo=.864cf3ec-9399-4411-ab7e-a92f9c90858f@github.com>
 <vKgvRTfvDCx3oNJSnKNGqV0WtroCRPiEP3hEdHp1oek=.b4b5b97d-4233-48d3-9cf2-e75176ed36ca@github.com>
 <I7EqdqNzJRToGpBfODbuNA5DtqTuCzQvgpGgFc8aeVw=.340e86b3-f7bc-42f0-8e85-f5d1f174b3a0@github.com>
Message-ID: <0FJI4QE-PYy7kUh6b76dZ1jsGQRGP3yR9UhkRsX9U3g=.0900c557-97ce-4be0-829b-79cf007b39c2@github.com>

On Tue, 20 Feb 2024 09:49:23 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Thank you all for the reviews.  I have been asked to simplify this code to facilitate easier review, and to remove the gcc library code I used for memcmp.  We also discovered that special-casing up to 31 bytes of needle was not necessary to get the performance gain.  I will be commenting the code and fixing the single build failure soon.
>
> Hi @asgibbons ,
> 
> I am getting following error with slowdebug build on Meteor Lake system.
> 
> 
> ERROR: Build failed for target 'images' in configuration 'linux-x86_64-server-slowdebug' (exit code 2) 
> 
> === Output from failing command(s) repeated here ===
> * For target buildtools_create_symbols_javac__the.COMPILE_CREATE_SYMBOLS_batch:
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (/home/jatinbha/sandboxes/jdk-reviews/jdk/src/hotspot/share/asm/assembler.hpp:169), pid=237140, tid=237235
> #  assert(is_bound() || is_unused()) failed: Label was never bound to a location, but it was used as a jmp target
> #
> # JRE version: OpenJDK Runtime Environment (23.0) (slowdebug build 23-internal-adhoc.sdp.jdk)
> # Java VM: OpenJDK 64-Bit Server VM (slowdebug 23-internal-adhoc.sdp.jdk, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
> # Problematic frame:
> # V  [libjvm.so+0x4c9e3e]  Label::~Label()+0x5c
> #
> # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to /home/jatinbha/sandboxes/jdk-reviews/jdk/make/core.237140)
> #
> # An error report file with more information is saved as:
> # /home/jatinbha/sandboxes/jdk-reviews/jdk/make/hs_err_pid237140.log
>    ... (rest of output omitted)

@jatin-bhateja Thanks for the note.  Fixed a couple of slowdebug compile issues.  Now builds successfully on Meteor Lake system.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16753#issuecomment-1957038856

From mli at openjdk.org  Wed Feb 21 16:10:22 2024
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 21 Feb 2024 16:10:22 GMT
Subject: RFR: 8322179: RISC-V: Implement SHA-1 intrinsic [v11]
In-Reply-To: <PyIXzENfiHysFS3IyZn3FDNQpV7Ua2L6OmjiXq9wRoU=.cf74a45e-c94b-4f7b-8768-d10d55e2ce1d@github.com>
References: <PyIXzENfiHysFS3IyZn3FDNQpV7Ua2L6OmjiXq9wRoU=.cf74a45e-c94b-4f7b-8768-d10d55e2ce1d@github.com>
Message-ID: <aSyCTamtdqjTThv2t6sOnXe8XDTwj2G-BIHGNQmZ3M4=.41f939b4-2a38-4e1d-94ea-0b283f1c8560@github.com>

> Hi,
> Can you review this patch to implement SHA-1 intrinsic for riscv?
> Thanks!
> 
> 
> ## Test
> 
> ### Functionality
> 
> tests under `test/hotspot/jtreg/compiler/intrinsics/sha`
> tests found via `find test/jdk -iname "*SHA1*.java"`
> 
> ### Performance
> 
> tested on `T-HEAD Light Lichee Pi 4A`
> 
> JMH_PARAMS="-f 1 -wi 10 -i 20" // for every loop of jmh test
> 
> benchmark tests `MessageDigests.java GetMessageDigest.java MessageDigestBench.java MacBench.java` which are under `test/micro/org/openjdk/bench/`, more spcifically `TESTS="MessageDigests.digest MessageDigests.getAndDigest MessageDigestBench.digest"`
> 
> 
> // After
> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1        64     DEFAULT  avgt   20      1845.446 ?     27.052  ns/op
> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    181455.350 ?    532.258  ns/op
> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2447.674 ?     10.239  ns/op
> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    182896.083 ?   1242.774  ns/op
> o.o.b.javax.crypto.small.MessageDigestBench.digest         SHA1     1048576             N/A       N/A              avgt   20  11599227.792 ? 121442.390  ns/op
> // Before
> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2352.475 ?    11.198  ns/op
> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    188495.684 ?  1467.942  ns/op
> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2437.347 ?     6.398  ns/op
> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    196086.570 ?  1140.998  ns/op
> o.o.b.javax.crypto.small.MessageDigestBench.digest         SHA1     1048576             N/A       N/A              avgt   20  12362160.119 ? 38788.109  ns/op
> 
> 
> **getAndDigest when size == 64**
> The data is not stable for test getAndDigest when size == 64, which I think is introduced by  j.s.MessageDigest.getInstance itself, which we don't touch in this patch.
> Check more details at [1](https://github.com/openjdk/jdk/pull/17130#issuecomment-1886805614)
> 
> 
> loop ... ...

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  refine code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17130/files
  - new: https://git.openjdk.org/jdk/pull/17130/files/f2976596..abbf7c20

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17130&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17130&range=09-10

  Stats: 29 lines in 1 file changed: 11 ins; 4 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/17130.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17130/head:pull/17130

PR: https://git.openjdk.org/jdk/pull/17130

From mli at openjdk.org  Wed Feb 21 16:10:22 2024
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 21 Feb 2024 16:10:22 GMT
Subject: RFR: 8322179: RISC-V: Implement SHA-1 intrinsic [v10]
In-Reply-To: <GIFzLolfS5IlNcCGzsV7b0vjeqmNedCdQZubh-zywsg=.6239158c-d99e-45f7-954c-7c2f6ba834a2@github.com>
References: <PyIXzENfiHysFS3IyZn3FDNQpV7Ua2L6OmjiXq9wRoU=.cf74a45e-c94b-4f7b-8768-d10d55e2ce1d@github.com>
 <bAQOJj5ESbBOFxTqNRBDf36jquSMydvN_ey2CleFmD0=.8d3ff5c7-3c78-4113-af39-7dbba435f591@github.com>
 <GIFzLolfS5IlNcCGzsV7b0vjeqmNedCdQZubh-zywsg=.6239158c-d99e-45f7-954c-7c2f6ba834a2@github.com>
Message-ID: <onszIThxLBX_x3IvS-Lw03Qj8xUgFEat-D6wKRN5YRQ=.1758ff56-45f8-4f65-b090-d2f991b38365@github.com>

On Sat, 17 Feb 2024 13:27:19 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   refine register usage and comment
>
> src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 4953:
> 
>> 4951:       __ rolw_imm(cur_w, a, 5, t0);
>> 4952:       // as pointed above, we can use cur_w as temporary register here.
>> 4953:       sha1_f(round, tmp, b, c, d);
> 
> Could we also reuse `cur_k` in this function where input param `tmp` is used? I see `cur_k` will also be recalculated at the beginning of each round like `cur_w`. Hope this could help eliminate `tmp` param and finally free `t2`.

Seems not, as cur_k is only calculated when `(round % 20) == 0`.

Other comments are all resolved.

> src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 5123:
> 
>> 5121: 
>> 5122:     if (multi_block) {
>> 5123:       __ bge(limit, buf, L_sha1_loop, true);
> 
> A small question: Is it OK to continue the loop when `limit` equals `buf`?

I think the answer to your question is at https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/provider/DigestBase.java#L130, the `limit` is indeed `limit - blockSize`, hope this answer your question?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17130#discussion_r1497850315
PR Review Comment: https://git.openjdk.org/jdk/pull/17130#discussion_r1497850122

From mli at openjdk.org  Wed Feb 21 16:34:55 2024
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 21 Feb 2024 16:34:55 GMT
Subject: RFR: 8320646: RISC-V: C2 VectorCastHF2F [v2]
In-Reply-To: <fTvkUqcIsICvOIRWhqcICR8OYfaiOsOgSoaJsgUUm94=.09bb33c2-ce00-4943-bed0-0a1906395ee4@github.com>
References: <kqLQR-bD3v7iF7LgH0PzwIH_m6QH_2b371pKz9_Ovq8=.9c07c165-2a97-4a6b-9e82-6a6de0b81328@github.com>
 <fTvkUqcIsICvOIRWhqcICR8OYfaiOsOgSoaJsgUUm94=.09bb33c2-ce00-4943-bed0-0a1906395ee4@github.com>
Message-ID: <RI4Ie55LpiEeTV6nOcMsCTCxKc0AFajqJ3xYVg6p0oU=.ea7d5343-03df-4e01-acd9-36eac7716e5d@github.com>

On Wed, 7 Feb 2024 15:22:09 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you review this patch to add instrinsics for VectorCastHF2F/VectorCastF2HF?
>> Thanks!
>> 
>> ## Test
>> 
>> test/jdk/java/lang/Float/Binary16ConversionNaN.java
>> test/jdk/java/lang/Float/Binary16Conversion.java
>> 
>> hotspot/jtreg/compiler/intrinsics/float16
>> hotspot/jtreg/compiler/vectorization/TestFloatConversionsVectorjava
>> hotspot/jtreg/compiler/vectorization/TestFloatConversionsVectorNaN.java
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add some comments

Hi, Can I get more reviews? Thanks

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17698#issuecomment-1957214750

From fbredberg at openjdk.org  Wed Feb 21 16:41:53 2024
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 21 Feb 2024 16:41:53 GMT
Subject: RFR: 8325153: SEGV in stackChunkOopDesc::derelativize_address(int)
In-Reply-To: <VBQvZPR2sjjdgieJnLaeJthL6IH3QiiLDWRicJKdguQ=.fce9c329-7b0e-4274-9357-fb5a1c2cd01b@github.com>
References: <qc0gmrEb_xZ8mtY1wIa0odNvUOkZL1GmjfLD25px9uY=.fd3a5704-a89c-46fb-bb16-7d988c8fc435@github.com>
 <VBQvZPR2sjjdgieJnLaeJthL6IH3QiiLDWRicJKdguQ=.fce9c329-7b0e-4274-9357-fb5a1c2cd01b@github.com>
Message-ID: <9oANx1yQI-uSOWxU2BzTkhVEAoBpmceUKAYHC-1XLyY=.188384e5-7d93-45ce-990f-b35b60d914b9@github.com>

On Wed, 21 Feb 2024 14:58:13 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The JVM used to SEGV when running jdk/internal/vm/Continuation/Fuzz.java with '-Xlog:all=trace:file=hotspot.%p.log'
>> 
>> The problem was this line in StackWalk::fetchNextBatch() at src/hotspot/share/prims/stackwalk.cpp:547:
>> 
>> log_debug(stackwalk)("advanced past %s", stream.method()->external_name());
>> 
>> It is not always safe to dig out the name of the last frame here. The second batch is resource allocated on top of the first batch, so there is no crash when we dig out the last name from the first batch. However the third batch, is resource allocated on the same stack level as the second, which means that the second batch has been reclaimed. Thus trying to reach into the second batch when processing the third will cause a segmentation violation.
>> 
>> Now passes:
>> jdk/internal/vm/Continuation/Fuzz.java with '-Xlog:all=trace:file=hotspot.%p.log'
>> As well as tier1-tier5
>
> src/hotspot/share/prims/stackwalk.cpp line 551:
> 
>> 549:       // have been reclaimed by HandleMark::pop_and_restore() together
>> 550:       // with the rest of the previous batch.
>> 551:       log_debug(stackwalk)("advanced past last frame decoded in the previous batch");
> 
> Your description says ResourceMark but this comment says HandleMark.  Stream is native memory allocated as a secret field of the frames_array somewhere (resource allocated?), and frames_array is a Handle subject to HandleMark.  I don't understand which got deallocated with this comment.

Sorry I mixed up things in the description. But HandleMark is correct. There are two stack backtraces in [JDK-8325153](https://bugs.openjdk.org/browse/JDK-8325153) that show the actual details.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17942#discussion_r1497902682

From thomas.stuefe at gmail.com  Wed Feb 21 16:56:28 2024
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 21 Feb 2024 17:56:28 +0100
Subject: Question: 8324776: How to safely tell if MADV_POPULATE_WRITE is
 supported
In-Reply-To: <CO1PR01MB6694E52F1968421CE1D8E2968F572@CO1PR01MB6694.prod.exchangelabs.com>
References: <CO1PR01MB6694E52F1968421CE1D8E2968F572@CO1PR01MB6694.prod.exchangelabs.com>
Message-ID: <CAA-vtUwQAboHB5je940HJrsjB7ZM9ZxzEqeiwp=0xJfLcXOZvA@mail.gmail.com>

Hi,

I am trying to understand this better.

MADV_POPULATE_READ and MADV_POPULATE_WRITE were added to mainline with

```
 commit 4ca9b3859dac14bbef0c27d00667bb5b10917adb
 Author: David Hildenbrand <david at redhat.com>
 Date:   Wed Jun 30 18:52:28 2021 -0700
     mm/madvise: introduce MADV_POPULATE_(READ|WRITE) to prefault page
tables
```

and they used 22/23 as numerical identifier:

```
+#define MADV_POPULATE_READ     22      /* populate (prefault) page tables
readable */
+#define MADV_POPULATE_WRITE    23      /* populate (prefault) page tables
writable */
```

But I don't see a patch in mainline for MADV_DOEXEC. I do see a very
lengthy RFR thread that seemed to end in patent disputes (?):
https://lore.kernel.org/all/1595869887-23307-1-git-send-email-anthony.yznaga at oracle.com/T/#u

Is this a downstream-only patch specific to the Oracle Linux kernel?

Cheers, Thomas



On Wed, Feb 21, 2024 at 4:25?PM Patrick Zhang OS <
patrick at os.amperecomputing.com> wrote:

> Hi,
>
>
>
> I have a question regarding the regression reported by [1] which was
> caused by the commit [2].
>
>
>
> The root cause can be briefly described as: MADV_POPULATE_WRITE has been
> supported since Linux 5.14. It is suggested to call madvise(0, 0, advice)
> to tell if this madvise mode is valid, which ?will return zero iff advice
> is supported by the kernel and can be relied on to probe for support? [3].
> However Oracle UEKR6 5.4.17 has a duplicate definition of the number 23:
> MADV_DONTEXEC [4]. As a result, the test passes on Linux 5.4 mainline,
> while fails on UEK 5.4.17, because madvise(0, 0, 23) gives different return
> values. See details at [5].
>
>
>
> It is a dilemma that how to fix so inside JVM. Thanks for any advice.
>
>
>
> [1] https://bugs.openjdk.org/browse/JDK-8324776
> runtime/os/TestTransparentHugePageUsage.java fails with The usage of THP is
> not enough
>
> [2] https://bugs.openjdk.org/browse/JDK-8315923 pretouch_memory by
> atomic-add-0 fragments huge pages unexpectedly
>
> [3] https://www.man7.org/linux/man-pages/man2/madvise.2.html
>
> [4]
> https://yum.oracle.com/repo/OracleLinux/OL8/developer/UEKR6/aarch64/getPackageSource/kernel-uek-5.4.17-2136.327.2.el8uek.src.rpm,
> linux-5.4.17/include/uapi/asm-generic/mman-common.h#L75
>
> [5]
> https://bugs.openjdk.org/browse/JDK-8324776?focusedId=14651275&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14651275
> .
>
>
>
> Regards
>
> Patrick
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20240221/1ef5b4ea/attachment-0001.htm>

From duke at openjdk.org  Wed Feb 21 16:59:59 2024
From: duke at openjdk.org (duke)
Date: Wed, 21 Feb 2024 16:59:59 GMT
Subject: Withdrawn: 8319115: GrowableArray: Do not initialize up to capacity
In-Reply-To: <VJHBiMB7tY8YJMKCuZ7jii9xFVV-dCngoFwB7zI0S_M=.ccfdaaa8-e629-4d1f-9fb8-ef208405db62@github.com>
References: <VJHBiMB7tY8YJMKCuZ7jii9xFVV-dCngoFwB7zI0S_M=.ccfdaaa8-e629-4d1f-9fb8-ef208405db62@github.com>
Message-ID: <7ZWJZQ7v2_c0jDIw1YB4_CwnNd--rBhtMFM8vMD1KAs=.24e5f554-f47e-45e7-a3a2-bf9536633c51@github.com>

On Mon, 30 Oct 2023 14:49:25 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> There's no reason to initialize the memory for the elements in the range `[_len, _capacity)` on resize, so let's not do it.
> 
> Currently running testing tier1-3.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/16418

From coleenp at openjdk.org  Wed Feb 21 18:08:55 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 21 Feb 2024 18:08:55 GMT
Subject: RFR: 8325153: SEGV in stackChunkOopDesc::derelativize_address(int)
In-Reply-To: <qc0gmrEb_xZ8mtY1wIa0odNvUOkZL1GmjfLD25px9uY=.fd3a5704-a89c-46fb-bb16-7d988c8fc435@github.com>
References: <qc0gmrEb_xZ8mtY1wIa0odNvUOkZL1GmjfLD25px9uY=.fd3a5704-a89c-46fb-bb16-7d988c8fc435@github.com>
Message-ID: <b9qz7xkuV0qOvev_3GUj6cdjLv-EdjA3D83PBJDxkNE=.9b2929ff-881d-4c0f-ae0c-5c41f76150b2@github.com>

On Wed, 21 Feb 2024 09:21:11 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> The JVM used to SEGV when running jdk/internal/vm/Continuation/Fuzz.java with '-Xlog:all=trace:file=hotspot.%p.log'
> 
> The problem was this line in StackWalk::fetchNextBatch() at src/hotspot/share/prims/stackwalk.cpp:547:
> 
> log_debug(stackwalk)("advanced past %s", stream.method()->external_name());
> 
> It is not always safe to dig out the name of the last frame here. The second batch is allocated on top of the first batch, so there is no crash when we dig out the last name from the first batch. However the third batch, is allocated on the same stack level as the second, which means that the second batch has been reclaimed. Thus trying to reach into the second batch when processing the third will cause a segmentation violation.
> 
> Now passes:
> jdk/internal/vm/Continuation/Fuzz.java with '-Xlog:all=trace:file=hotspot.%p.log'
> As well as tier1-tier5

Reading your comment now in the bug report makes sense.  This memory was removed with a HandleMark dtor.  Thanks.

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17942#pullrequestreview-1894095283

From alanb at openjdk.org  Wed Feb 21 19:15:56 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 21 Feb 2024 19:15:56 GMT
Subject: RFR: 8256314: JVM TI GetCurrentContendedMonitor is implemented
 incorrectly
In-Reply-To: <-Yf2Qj_kbyZAA-LDK96IIOcHWMh8__QT1XfnD9jR8kU=.507d5503-1544-44fb-9e81-438ba3458dcd@github.com>
References: <-Yf2Qj_kbyZAA-LDK96IIOcHWMh8__QT1XfnD9jR8kU=.507d5503-1544-44fb-9e81-438ba3458dcd@github.com>
Message-ID: <B2vq9tWBtbh9dlbW6UXs21h3CUK821LT_05NID77ZPg=.d6fa3aa5-1052-455f-b24f-e84d8f1eff7a@github.com>

On Wed, 21 Feb 2024 10:28:49 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The implementation of the JVM TI `GetCurrentContendedMonitor` does not match the spec. It can sometimes return an incorrect information about the contended monitor. Such a behavior does not match the function spec. 
> With this update the `GetCurrentContendedMonitor` is returning the monitor only when the specified thread is waiting to enter or re-enter the monitor, and the monitor is not returned when the specified thread is waiting in the `java.lang.Object.wait` to be notified.
> 
> The implementation of the JDWP `ThreadReference.CurrentContendedMonitor` command is based and depends on this JVMTI function. The command was both specified incorrectly and had an incorrect behavior. The fix slightly corrects the JDWP spec to make it right (the JDWP implementation has been fixed by the JVM TI update). Please, see and review the related CSR and Release-Note.
> 
> CSR: [8326024](https://bugs.openjdk.org/browse/JDK-8326024): JVM TI GetCurrentContendedMonitor is implemented incorrectly
> RN:   [8326038](https://bugs.openjdk.org/browse/JDK-8326038): Release Note: JVM TI GetCurrentContendedMonitor is implemented incorrectly
> 
> Testing:
>  - tested with the mach5 tiers 1-6

src/java.se/share/data/jdwp/jdwp.spec line 1985:

> 1983:         "thread may be waiting to enter a monitor, or it may be waiting, via "
> 1984:         "the java.lang.Object.wait method, to re-enter a monitor after being "
> 1985:         "notified by another thread. "

Interrupted or timeout in Object.wait are other reasons to be waiting to reenter. I'm wondering if this should be spelled out here. I see the JVMTI spec uses the phrase "regain" to cover the scenarios where a thread is waiting to reenter.

In any case, I think the wording could be a smoother as reenter case isn't very clear. Here's an attempt as smoothing out the wording but it may be more than you want to include:

"The thread may be waiting to enter the object's monitor, in the monitor's wait set and waiting in Object.wait, or in Object.wait waiting to reenter the monitor after being notified, interrupted, or timeout."

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17944#discussion_r1498160800

From fbredberg at openjdk.org  Wed Feb 21 19:52:53 2024
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 21 Feb 2024 19:52:53 GMT
Subject: RFR: 8325153: SEGV in stackChunkOopDesc::derelativize_address(int)
In-Reply-To: <qc0gmrEb_xZ8mtY1wIa0odNvUOkZL1GmjfLD25px9uY=.fd3a5704-a89c-46fb-bb16-7d988c8fc435@github.com>
References: <qc0gmrEb_xZ8mtY1wIa0odNvUOkZL1GmjfLD25px9uY=.fd3a5704-a89c-46fb-bb16-7d988c8fc435@github.com>
Message-ID: <T0mOjUq3koh4aF0M3-IW_OD59NlBx-P031S8j_Pr-ww=.e7e8e957-a9b0-451e-b856-5c1ffd157d6c@github.com>

On Wed, 21 Feb 2024 09:21:11 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> The JVM used to SEGV when running jdk/internal/vm/Continuation/Fuzz.java with '-Xlog:all=trace:file=hotspot.%p.log'
> 
> The problem was this line in StackWalk::fetchNextBatch() at src/hotspot/share/prims/stackwalk.cpp:547:
> 
> log_debug(stackwalk)("advanced past %s", stream.method()->external_name());
> 
> It is not always safe to dig out the name of the last frame here. The second batch is allocated on top of the first batch, so there is no crash when we dig out the last name from the first batch. However the third batch, is allocated on the same stack level as the second, which means that the second batch has been reclaimed. Thus trying to reach into the second batch when processing the third will cause a segmentation violation.
> 
> Now passes:
> jdk/internal/vm/Continuation/Fuzz.java with '-Xlog:all=trace:file=hotspot.%p.log'
> As well as tier1-tier5

Thanks for the review. Let's integrate.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17942#issuecomment-1957788121

From shade at openjdk.org  Wed Feb 21 20:05:12 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 21 Feb 2024 20:05:12 GMT
Subject: RFR: 8324833: Signed integer overflows in ABS [v4]
In-Reply-To: <ohwAn6GqM7FIgYTJNy40VBYSCVEBrrNSqBaz2akN54M=.f9660235-3047-47ee-aad0-ef598d6ebdcc@github.com>
References: <ohwAn6GqM7FIgYTJNy40VBYSCVEBrrNSqBaz2akN54M=.f9660235-3047-47ee-aad0-ef598d6ebdcc@github.com>
Message-ID: <EsmovABEwx2RHZ-gF6JQxFtA8WiYyUkPvqVXRfqdix0=.8c106dfc-e644-4134-81a8-2f29259f114c@github.com>

> See the details in the bug. I think current `ABS` implementation is beyond repair, and we should just switch to `uabs`.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, `all` with `-ftrapv` (now fully passes!)
>  - [x] Linux x86_64 fastdebug, `all`

Aleksey Shipilev 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:

 - Review comments
 - Merge branch 'master' into JDK-8324833-uabs
 - Touchups
 - Unnecessary comment
 - Also handle the -stride_con with proper uabs
 - Another attempt at JVMCI fix
 - Work
 - Cleaner version
 - Merge branch 'master' into JDK-8324833-uabs
 - Rewrite JVMCI usage to avoid the messy overload
 - ... and 1 more: https://git.openjdk.org/jdk/compare/7090bd75...272fb16b

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17617/files
  - new: https://git.openjdk.org/jdk/pull/17617/files/96a1987c..272fb16b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17617&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17617&range=02-03

  Stats: 43512 lines in 1367 files changed: 21343 ins; 13810 del; 8359 mod
  Patch: https://git.openjdk.org/jdk/pull/17617.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17617/head:pull/17617

PR: https://git.openjdk.org/jdk/pull/17617

From shade at openjdk.org  Wed Feb 21 20:05:12 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 21 Feb 2024 20:05:12 GMT
Subject: RFR: 8324833: Signed integer overflows in ABS [v3]
In-Reply-To: <kx1I4koOmVIM9rAHoX2WpQv4jVCh3qgKgMkmL3ve9Ns=.6b0a46f8-3b87-4d2e-9125-2e262a09dbfc@github.com>
References: <ohwAn6GqM7FIgYTJNy40VBYSCVEBrrNSqBaz2akN54M=.f9660235-3047-47ee-aad0-ef598d6ebdcc@github.com>
 <6kxKhJVXB2X7ni4SLMtL--Pt5O8bUOazcI9F3FJgG8o=.55b0e9bd-075c-4b76-bcc6-732951e8a512@github.com>
 <kx1I4koOmVIM9rAHoX2WpQv4jVCh3qgKgMkmL3ve9Ns=.6b0a46f8-3b87-4d2e-9125-2e262a09dbfc@github.com>
Message-ID: <Gbn5-tx3n3yBz9IcwS1Gkfk1pWHEwbn_Xff-nJQMyvE=.37c8d6d1-4ab9-490f-84f0-f9937942988e@github.com>

On Fri, 2 Feb 2024 23:47:33 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Touchups
>
> src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 1062:
> 
>> 1060:   if (target_addr != 0x0) {
>> 1061:     jlong off_low = (jlong)target_addr - ((jlong)CodeCache::low_bound() + sizeof(int));
>> 1062:     jlong off_high = (jlong)target_addr - ((jlong)CodeCache::high_bound() + sizeof(int));
> 
> Suggestion:
> 
>     jlong off_low = (jlong)(target_addr - (CodeCache::low_bound() + sizeof(int)));
>     jlong off_high = (jlong)(target_addr - (CodeCache::high_bound() + sizeof(int)));

Done!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17617#discussion_r1498230649

From aboldtch at openjdk.org  Wed Feb 21 20:19:07 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 21 Feb 2024 20:19:07 GMT
Subject: RFR: 8139457: Relax alignment of array elements [v65]
In-Reply-To: <474Cp5qDgHyppRBgkl1OHixEpCacSZfZoQrzuHRowAg=.f5a7cfa2-c300-4e07-b594-34d6351eafb4@github.com>
References: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
 <474Cp5qDgHyppRBgkl1OHixEpCacSZfZoQrzuHRowAg=.f5a7cfa2-c300-4e07-b594-34d6351eafb4@github.com>
Message-ID: <pNHNOr21oYN8aqgBkSj3L3JofLs5COreCfKpy6YcxPc=.65763aa5-3c00-4337-a703-0d8e863b2e4b@github.com>

On Wed, 21 Feb 2024 11:36:34 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details.
>> 
>> Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements.
>> 
>> Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16.
>> 
>> Testing:
>>  - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390)
>>  - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390)
>>  - [x] tier1 (x86_64, x86_32, aarch64, riscv)
>>  - [x] tier2 (x86_64, aarch64, riscv)
>>  - [x] tier3 (x86_64, riscv)
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright years
>  - Remove duplicate code

These changes look correct. Tried to look around the code for indirect assumptions surrounding the `klass_offset` and the `length_offset` w.r.t. the `base_offset`. It seem to work out. (But some of this implicit assumptions might want to be cleaned up in the future.)

I only looked at changes since my last comments, seems like my nits from then have been fixed.

There are preexisting issues with regards to naming (and their meaning) which this change exacerbates.

I do not believe this should be a blocker (done in future RFEs). However the more code movement there is with regards to this, the more I feel this needs to be overhauled. (Lilliput shakes this up even more.)

I know @albertnetymk already touched on this but some thoughts on the unclear boundaries between the header and the data. My feeling is that the most pragmatic solution would be to have the header initialization always initialize up to the word aligned (up) `header_size_in_bytes`. (Similarly to how it is done for the `instanceOop` where the klass gap gets initialized with the header, even if it may be data.) And have the body initialization do the rest (word aligned to word aligned clear).

This seems preferable than adding these extra alignment shims in-between the header and body/payload/data initialization. (I also tried moving the alignment fix into the body initialization, but it seems a little bit messier in the implementation.)

Maybe something similar for copying and cloning. But there are already so much shims and patching code surrounding copying and cloning. E.g. in ZGC (depending on UseCompressClassPointers) we have to sub 1 from the length node in C2 to apply the proper barriers. This is required because when C2 takes out the base offset it does not know the element type, so it starts the clone from the word aligned (up) length offset (which may or may not start in the header). It would be a larger project to overhaul, but we have seen a couple of bugs related to this.

Some things that I think we should always try and strive for is when introducing new code (that talks about heap memory sizes/offsets):
 * Any named property/variable ending in `_size_in_bytes`/`_offset_in_bytes` is not required to be word aligned.
 * Any named property/variable ending in just `_size`/`_offset` must be in words. And their name should not lie. i.e. `aligned_header_size = align_up(header_size_in_bytes(),HeapWordSize) / HeapWordSize;` instead of `header_size = align_up(header_size_in_bytes(),HeapWordSize) / HeapWordSize;` unless `header_size * HeapWordSize == header_size_in_bytes()` is invariant.
Again a pragmatic choice, as it seems to be the predominant choice in hotspot.
An absolutely wonderful change would be to add (and use/enforce) typed size_t enum classes for `ByteSize` and `WordSize`. (We already have these in the code base but they use 32-bit int and only `ByteSize` sees any use). The idea is then that you can just use `_size`/`_offset` suffixes with the correct types.

<details>
<summary>Some thoughts on future naming</summary>
This is just one way that things could be named.

Note: `padding` and `klass_gap` may be 0 here.

arrayOop: After This PR
<pre>
  Layout:
|<---------------header-------------->|<---------------payload---------------->|
|<-mark/klass->|<-length->|<-padding->|<---------elements--------->|<-padding->|
  Names:
|<-header_size_in_bytes-->|
|<-------base_offset_in_bytes-------->|
|<----------------------object_size/object_size_in_bytes---------------------->|
</pre>

The `***` just means that the alignment will end up somewhere here.
`base_offset_in_bytes + elements_size_in_bytes == aligned_base_offset + aligned_element_size` is invariant.
arrayOop: Potential Future
<pre>
  Layout:
|<--------header--------->|<---------------------payload---------------------->|
|<-mark/klass->|<-length->|<-padding->|<---------elements--------->|<-padding->|
  Names:
|<-header_size_in_bytes-->|
|<-------base_offset_in_bytes-------->|<--elements_size_in_bytes-->|
|<--aligned_header_size---****************>| // Word Aligned (UP) May include elements
|<--aligned_base_offset---****************>| // Word Aligned (UP) May include elements
                                      |<****-aligned_element_size->| // Word Aligned (Down)
|<----------------------object_size/object_size_in_bytes---------------------->|
|<-Header Initialization--***************>|
                                      |<****-Body Initialization-->|
</pre>

instanceOop: Current
<pre>
  Layout:
|<--------header-------->|<-header/body->|<---------------body---------------->|
|<------mark/klass------>|<--klass_gap-->|
                         |<------------------fields/padding------------------->|
  Names:
|<---header_size/header_size_in_bytes--->|
|<-base_offset_in_bytes->|
|<----------------------object_size/object_size_in_bytes---------------------->|
</pre>

Not sure what a good ambiguous name for the field and/or padding should be.
The `***` has a similar role.
instanceOop: Potential Future
<pre>
  Layout:
|<--------header-------->|<-----------------------body------------------------>|
|<------mark/klass------>|<------------------fields/padding------------------->|
                         |<--klass_gap-->|
   Names:
|<-header_size_in_bytes->|
|<-base_offset_in_bytes->|<------------------X_size_in_bytes------------------>|
|<----------------------object_size/object_size_in_bytes---------------------->|
|<--aligned_header_size---**************>| // Word Aligned (UP) May include elements
|<--aligned_base_offset---**************>| // Word Aligned (UP) May include elements
                         |<***************-----------aligned_X_size----------->|
|<-Header Initialization--**************>|
                         |<***************--------Body Initialization--------->|
</pre>
</details>

-------------

Marked as reviewed by aboldtch (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/11044#pullrequestreview-1894323275

From amenkov at openjdk.org  Wed Feb 21 21:34:19 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 21 Feb 2024 21:34:19 GMT
Subject: RFR: JDK-8325530: Vague error message when
 com.sun.tools.attach.VirtualMachine fails to load agent library
Message-ID: <s1rZKr_Bt8tzCP2cMyFv0oe7pTD1DNzGLaIsGZdXffY=.596d50f2-12b6-4bba-ab30-a26b697fb970@github.com>

VirtualMachine.loadAgentPath/loadAgentLibrary can fail with AgentLoadException in 2 cases:
- attach listener returns error; in the case the exception is thrown from HotSpotVirtualMachine.processCompletionStatus (called from HotSpotVirtualMachine.execute);
- attach listener returns success, but reply does not contain Agent_onAttach return code ("return code: %d" message).

before jdk21 if attach listener fails to load required library, it returned error (case 1)
from jdk21 attach listener always returns success (case 2)
Both cases are ok, but for 2nd case HotSpotVirtualMachine.loadAgentLibrary read only single line of the response message, so exception message didn't contain error details.

The fix updates HotSpotVirtualMachine.loadAgentLibrary to read the whole response message.
Walking through the code, fixed some other minor things in attach listener and attach API implementation (commented in the code)

Testing:
  - test/jdk/com/sun/tools;
  - tier1,tier2,tier5-svc

-------------

Commit messages:
 - fix

Changes: https://git.openjdk.org/jdk/pull/17954/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17954&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8325530
  Stats: 146 lines in 6 files changed: 106 ins; 16 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/17954.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17954/head:pull/17954

PR: https://git.openjdk.org/jdk/pull/17954

From amenkov at openjdk.org  Wed Feb 21 21:34:19 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 21 Feb 2024 21:34:19 GMT
Subject: RFR: JDK-8325530: Vague error message when
 com.sun.tools.attach.VirtualMachine fails to load agent library
In-Reply-To: <s1rZKr_Bt8tzCP2cMyFv0oe7pTD1DNzGLaIsGZdXffY=.596d50f2-12b6-4bba-ab30-a26b697fb970@github.com>
References: <s1rZKr_Bt8tzCP2cMyFv0oe7pTD1DNzGLaIsGZdXffY=.596d50f2-12b6-4bba-ab30-a26b697fb970@github.com>
Message-ID: <ckD4vWU_PLeLZpDeZQuCk7m1wqMTV_2E8n_1vjYWEx0=.0dd628a0-cbdc-43f6-8e85-84d6b7ff0363@github.com>

On Wed, 21 Feb 2024 21:13:36 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> VirtualMachine.loadAgentPath/loadAgentLibrary can fail with AgentLoadException in 2 cases:
> - attach listener returns error; in the case the exception is thrown from HotSpotVirtualMachine.processCompletionStatus (called from HotSpotVirtualMachine.execute);
> - attach listener returns success, but reply does not contain Agent_onAttach return code ("return code: %d" message).
> 
> before jdk21 if attach listener fails to load required library, it returned error (case 1)
> from jdk21 attach listener always returns success (case 2)
> Both cases are ok, but for 2nd case HotSpotVirtualMachine.loadAgentLibrary read only single line of the response message, so exception message didn't contain error details.
> 
> The fix updates HotSpotVirtualMachine.loadAgentLibrary to read the whole response message.
> Walking through the code, fixed some other minor things in attach listener and attach API implementation (commented in the code)
> 
> Testing:
>   - test/jdk/com/sun/tools;
>   - tier1,tier2,tier5-svc

src/hotspot/share/prims/jvmtiAgentList.cpp line 127:

> 125: }
> 126: 
> 127: void JvmtiAgentList::add(const char* name, const char* options, bool absolute_path) {

`options` parameter should be const

src/hotspot/share/prims/jvmtiAgentList.cpp line 131:

> 129: }
> 130: 
> 131: void JvmtiAgentList::add_xrun(const char* name, const char* options, bool absolute_path) {

`options` parameter should be const

src/hotspot/share/prims/jvmtiAgentList.cpp line 201:

> 199: 
> 200: // Invokes Agent_OnAttach for agents loaded dynamically during runtime.
> 201: jint JvmtiAgentList::load_agent(const char* agent_name, const char* absParam,

The method never returns error, dropped value return type

src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java line 402:

> 400:             }
> 401: 
> 402:             // Special-case the "load" command so that the right exception is

We had special logic for "load" command in 2 places (here and in the loadAgentLibrary method)
For simplification moved all logic to loadAgentLibrary()

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17954#discussion_r1498320621
PR Review Comment: https://git.openjdk.org/jdk/pull/17954#discussion_r1498320775
PR Review Comment: https://git.openjdk.org/jdk/pull/17954#discussion_r1498321476
PR Review Comment: https://git.openjdk.org/jdk/pull/17954#discussion_r1498333650

From amenkov at openjdk.org  Wed Feb 21 21:34:19 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 21 Feb 2024 21:34:19 GMT
Subject: RFR: JDK-8325530: Vague error message when
 com.sun.tools.attach.VirtualMachine fails to load agent library
In-Reply-To: <ckD4vWU_PLeLZpDeZQuCk7m1wqMTV_2E8n_1vjYWEx0=.0dd628a0-cbdc-43f6-8e85-84d6b7ff0363@github.com>
References: <s1rZKr_Bt8tzCP2cMyFv0oe7pTD1DNzGLaIsGZdXffY=.596d50f2-12b6-4bba-ab30-a26b697fb970@github.com>
 <ckD4vWU_PLeLZpDeZQuCk7m1wqMTV_2E8n_1vjYWEx0=.0dd628a0-cbdc-43f6-8e85-84d6b7ff0363@github.com>
Message-ID: <VZI9SB49BufKxRPjCt1oevBQ-MYVoMuVermI04YSvHQ=.edf458e2-ece1-4864-90b5-6353ab60f1ad@github.com>

On Wed, 21 Feb 2024 21:16:46 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> VirtualMachine.loadAgentPath/loadAgentLibrary can fail with AgentLoadException in 2 cases:
>> - attach listener returns error; in the case the exception is thrown from HotSpotVirtualMachine.processCompletionStatus (called from HotSpotVirtualMachine.execute);
>> - attach listener returns success, but reply does not contain Agent_onAttach return code ("return code: %d" message).
>> 
>> before jdk21 if attach listener fails to load required library, it returned error (case 1)
>> from jdk21 attach listener always returns success (case 2)
>> Both cases are ok, but for 2nd case HotSpotVirtualMachine.loadAgentLibrary read only single line of the response message, so exception message didn't contain error details.
>> 
>> The fix updates HotSpotVirtualMachine.loadAgentLibrary to read the whole response message.
>> Walking through the code, fixed some other minor things in attach listener and attach API implementation (commented in the code)
>> 
>> Testing:
>>   - test/jdk/com/sun/tools;
>>   - tier1,tier2,tier5-svc
>
> src/hotspot/share/prims/jvmtiAgentList.cpp line 201:
> 
>> 199: 
>> 200: // Invokes Agent_OnAttach for agents loaded dynamically during runtime.
>> 201: jint JvmtiAgentList::load_agent(const char* agent_name, const char* absParam,
> 
> The method never returns error, dropped value return type

only 1 caller (load_agent() from attachListener) extract `absParam` from attach command, other pass constants ("true" or "false")
Moved conversion from string to bool there.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17954#discussion_r1498327164

From amenkov at openjdk.org  Wed Feb 21 21:42:08 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 21 Feb 2024 21:42:08 GMT
Subject: RFR: JDK-8325530: Vague error message when
 com.sun.tools.attach.VirtualMachine fails to load agent library [v2]
In-Reply-To: <s1rZKr_Bt8tzCP2cMyFv0oe7pTD1DNzGLaIsGZdXffY=.596d50f2-12b6-4bba-ab30-a26b697fb970@github.com>
References: <s1rZKr_Bt8tzCP2cMyFv0oe7pTD1DNzGLaIsGZdXffY=.596d50f2-12b6-4bba-ab30-a26b697fb970@github.com>
Message-ID: <yAR3Q8ArdoO4KivB9gu_SenT7P3tEccuZrEjvwAAF_M=.c8a0fe1b-9c7d-4de9-8288-b0c684ab0ccc@github.com>

> VirtualMachine.loadAgentPath/loadAgentLibrary can fail with AgentLoadException in 2 cases:
> - attach listener returns error; in the case the exception is thrown from HotSpotVirtualMachine.processCompletionStatus (called from HotSpotVirtualMachine.execute);
> - attach listener returns success, but reply does not contain Agent_onAttach return code ("return code: %d" message).
> 
> before jdk21 if attach listener fails to load required library, it returned error (case 1)
> from jdk21 attach listener always returns success (case 2)
> Both cases are ok, but for 2nd case HotSpotVirtualMachine.loadAgentLibrary read only single line of the response message, so exception message didn't contain error details.
> 
> The fix updates HotSpotVirtualMachine.loadAgentLibrary to read the whole response message.
> Walking through the code, fixed some other minor things in attach listener and attach API implementation (commented in the code)
> 
> Testing:
>   - test/jdk/com/sun/tools;
>   - tier1,tier2,tier5-svc

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  uncaught error

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17954/files
  - new: https://git.openjdk.org/jdk/pull/17954/files/19f0822e..0304bae2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17954&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17954&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17954.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17954/head:pull/17954

PR: https://git.openjdk.org/jdk/pull/17954

From coleenp at openjdk.org  Wed Feb 21 22:20:55 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 21 Feb 2024 22:20:55 GMT
Subject: RFR: 8325153: SEGV in stackChunkOopDesc::derelativize_address(int)
In-Reply-To: <qc0gmrEb_xZ8mtY1wIa0odNvUOkZL1GmjfLD25px9uY=.fd3a5704-a89c-46fb-bb16-7d988c8fc435@github.com>
References: <qc0gmrEb_xZ8mtY1wIa0odNvUOkZL1GmjfLD25px9uY=.fd3a5704-a89c-46fb-bb16-7d988c8fc435@github.com>
Message-ID: <plQML3mkAlvXw7gfWVaP2A4jJVbRDHZn21cT9hnC2ss=.d9a7828b-b923-450d-9988-fd478750f8a1@github.com>

On Wed, 21 Feb 2024 09:21:11 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> The JVM used to SEGV when running jdk/internal/vm/Continuation/Fuzz.java with '-Xlog:all=trace:file=hotspot.%p.log'
> 
> The problem was this line in StackWalk::fetchNextBatch() at src/hotspot/share/prims/stackwalk.cpp:547:
> 
> log_debug(stackwalk)("advanced past %s", stream.method()->external_name());
> 
> It is not always safe to dig out the name of the last frame here. The second batch is allocated on top of the first batch, so there is no crash when we dig out the last name from the first batch. However the third batch, is allocated on the same stack level as the second, which means that the second batch has been reclaimed. Thus trying to reach into the second batch when processing the third will cause a segmentation violation.
> 
> Now passes:
> jdk/internal/vm/Continuation/Fuzz.java with '-Xlog:all=trace:file=hotspot.%p.log'
> As well as tier1-tier5

I'll sponsor it tomorrow when you can watch it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17942#issuecomment-1958119371

From lmesnik at openjdk.org  Wed Feb 21 22:48:59 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 21 Feb 2024 22:48:59 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v13]
In-Reply-To: <bpyapA636CevyF7zlYxxhEYa-rcPW-04QL3Tud_5bzs=.53c46cb2-bf47-4d1c-aad0-20c979ee2eb2@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <bpyapA636CevyF7zlYxxhEYa-rcPW-04QL3Tud_5bzs=.53c46cb2-bf47-4d1c-aad0-20c979ee2eb2@github.com>
Message-ID: <Cco030vThwW1VBFo5yhwotYyTsGBPFZPTCr0ULq03ww=.dab5a82c-011f-4d2c-8127-92f8695a4007@github.com>

On Tue, 20 Feb 2024 23:48:06 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
>> The function returns the following structure:
>> 
>> 
>> typedef struct {
>>     jthread owner;
>>     jint entry_count;
>>     jint waiter_count;
>>     jthread* waiters;
>>     jint notify_waiter_count;
>>     jthread* notify_waiters;
>> } jvmtiMonitorUsage;
>> 
>> 
>> The following four fields are defined this way:
>> 
>> waiter_count  [jint] The number of threads waiting to own this monitor
>> waiters  [jthread*] The waiter_count waiting threads
>> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
>> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
>> 
>> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
>> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
>> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
>> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
>> This update makes it right.
>> 
>> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
>> 
>> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
>> 
>>   jvmti/GetObjectMonitorUsage/objmonusage001
>>   jvmti/GetObjectMonitorUsage/objmonusage003
>> 
>> 
>> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
>> 
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
>> 
>> 
>> 
>> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository.
>> 
>> Also, please see and review the related CSR:
>>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
>> 
>> The Release-Note is:
>> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage
>>  
>> Testing:
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: addressed minor issue with use of []; corrected the test desctiption

Changes requested by lmesnik (Reviewer).

test/hotspot/jtreg/serviceability/jvmti/GetObjectMonitorUsage/ObjectMonitorUsage.java line 42:

> 40:  *       - all the above is checked for both platform and virtual threads
> 41:  * @requires vm.jvmti
> 42:  * @compile ObjectMonitorUsage.java

No need to have explicit compile for the test code.

test/hotspot/jtreg/serviceability/jvmti/GetObjectMonitorUsage/ObjectMonitorUsage.java line 48:

> 46: public class ObjectMonitorUsage {
> 47: 
> 48:     final static int JCK_STATUS_BASE = 95;

JCK_STATUS_BASE is not used, need to be removed.

test/hotspot/jtreg/serviceability/jvmti/GetObjectMonitorUsage/ObjectMonitorUsage.java line 72:

> 70:      * - zero threads waiting to be notified
> 71:      */
> 72:     static void test1(boolean isVirtual) throws Error {

no need to add throws for unchecked excption

test/hotspot/jtreg/serviceability/jvmti/GetObjectMonitorUsage/ObjectMonitorUsage.java line 204:

> 202: 
> 203:         // test virtual threads
> 204:         test1(false);

shouldn't be true here?

test/hotspot/jtreg/serviceability/jvmti/GetObjectMonitorUsage/libObjectMonitorUsage.cpp line 37:

> 35: static jvmtiCapabilities caps;
> 36: static jint result = PASSED;
> 37: static jboolean printdump = JNI_FALSE;

if there are not too much logging, better just to enable log by default and remove this variable

test/hotspot/jtreg/serviceability/jvmti/GetObjectMonitorUsage/libObjectMonitorUsage.cpp line 105:

> 103:   err = jvmti->GetObjectMonitorUsage(obj, &inf);
> 104:   if (err == JVMTI_ERROR_MUST_POSSESS_CAPABILITY && !caps.can_get_monitor_info) {
> 105:     return; /* Ok, it's expected */

I think we don't need this path.

test/hotspot/jtreg/serviceability/jvmti/GetObjectMonitorUsage/libObjectMonitorUsage.cpp line 107:

> 105:     return; /* Ok, it's expected */
> 106:   } else if (err != JVMTI_ERROR_NONE) {
> 107:     LOG("(GetMonitorInfo#%d) unexpected error: %s (%d)\n",

you could use check_jvmti_status

test/hotspot/jtreg/serviceability/jvmti/GetObjectMonitorUsage/libObjectMonitorUsage.cpp line 117:

> 115:       LOG(">>> [%2d]    owner: none (0x0)\n", count);
> 116:     } else {
> 117:       err = jvmti->GetThreadInfo(inf.owner, &tinf);

need to check err status.

test/hotspot/jtreg/serviceability/jvmti/GetObjectMonitorUsage/libObjectMonitorUsage.cpp line 126:

> 124:         LOG(">>>       waiters:\n");
> 125:         for (j = 0; j < inf.waiter_count; j++) {
> 126:           err = jvmti->GetThreadInfo(inf.waiters[j], &tinf);

need to check err.

test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage003.java line 31:

> 29: 
> 30:     final static int JCK_STATUS_BASE = 95;
> 31:     final static int NUMBER_OF_THREADS = 16;

Better to remove the test if it already converted to avoid mess.

-------------

PR Review: https://git.openjdk.org/jdk/pull/17680#pullrequestreview-1894528980
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1498395120
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1498385978
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1498396928
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1498388601
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1498391687
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1498392633
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1498393662
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1498393291
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1498404333
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1498394741

From sspitsyn at openjdk.org  Wed Feb 21 22:54:55 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 21 Feb 2024 22:54:55 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v13]
In-Reply-To: <bpyapA636CevyF7zlYxxhEYa-rcPW-04QL3Tud_5bzs=.53c46cb2-bf47-4d1c-aad0-20c979ee2eb2@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <bpyapA636CevyF7zlYxxhEYa-rcPW-04QL3Tud_5bzs=.53c46cb2-bf47-4d1c-aad0-20c979ee2eb2@github.com>
Message-ID: <CCMv-tgJybGdvm3dSVDaiosUcBnuWBMkKaWgOf1Hh10=.95666911-dbe2-4d1a-a14c-a3b3add29d54@github.com>

On Tue, 20 Feb 2024 23:48:06 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
>> The function returns the following structure:
>> 
>> 
>> typedef struct {
>>     jthread owner;
>>     jint entry_count;
>>     jint waiter_count;
>>     jthread* waiters;
>>     jint notify_waiter_count;
>>     jthread* notify_waiters;
>> } jvmtiMonitorUsage;
>> 
>> 
>> The following four fields are defined this way:
>> 
>> waiter_count  [jint] The number of threads waiting to own this monitor
>> waiters  [jthread*] The waiter_count waiting threads
>> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
>> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
>> 
>> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
>> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
>> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
>> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
>> This update makes it right.
>> 
>> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
>> 
>> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
>> 
>>   jvmti/GetObjectMonitorUsage/objmonusage001
>>   jvmti/GetObjectMonitorUsage/objmonusage003
>> 
>> 
>> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
>> 
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
>> 
>> 
>> 
>> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository.
>> 
>> Also, please see and review the related CSR:
>>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
>> 
>> The Release-Note is:
>> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage
>>  
>> Testing:
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: addressed minor issue with use of []; corrected the test desctiption

Leonid, thank you for the comments. Will work on addressing them.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17680#issuecomment-1958221870

From ihse at openjdk.org  Wed Feb 21 23:37:00 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 21 Feb 2024 23:37:00 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
Message-ID: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>

**Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and JNIEXPORT on all platforms.

The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.

This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.

I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.

-------------

Commit messages:
 - 8017234: Hotspot should stop using mapfiles

Changes: https://git.openjdk.org/jdk/pull/17955/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17955&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8017234
  Stats: 990 lines in 32 files changed: 229 ins; 578 del; 183 mod
  Patch: https://git.openjdk.org/jdk/pull/17955.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17955/head:pull/17955

PR: https://git.openjdk.org/jdk/pull/17955

From ihse at openjdk.org  Wed Feb 21 23:37:01 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 21 Feb 2024 23:37:01 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
Message-ID: <g0ZVkeeR7P1e4_8Z0-nQ8at63jrtZySDk8bKtub0mLw=.db5e4e9c-9ca6-4d5a-b31b-17f84981e14f@github.com>

On Wed, 21 Feb 2024 23:32:15 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and JNIEXPORT on all platforms.
> 
> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
> 
> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
> 
> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.

First some general notes on related build changes: This was the last place in the build system where mapfiles where used. It will now be possible to clean up a lot of this framework, but I will do that separately after this has been integrated. Also, Hotspot is now built much closer to the rest of the native libraries in the JDK, so there is potential for more unification (e.g. placing `--exclude-libs,ALL` in a common location). This too will be done separately. 

On Windows, we still need to do the dance of finding symbols from the object files, and add them to a list of exported files (included by `-def:`). I decoupled this logic away from the old mapfile stuff, so we can safely delete the mapfile code later on. So what might look like new code in `CompileJvm.gmk` is actually just old code from `JvmMapfile.gmk` that I have cleaned up somewhat. These symbols are consumed by SA. It might be that we can limit the amount of symbols exported this way, or maybe that we can find another solution completely in SA, but that will have to be a future topic for research. For now, we keep the same exported symbols.

I have checked the resulting libjvm.so/jvm.dll using the `COMPARE_BUILD` functionality, which (among other things) analyzes differences between native libraries before and after a patch. This has verified that there is no change in the symbols of the Hotspot dynamic library on macOS/x64, macOS/aarch64 or Windows/x64. I have also gotten help from @MBaesken and @JoKern65 to confirmed that there is no effect on AIX (in fact, AIX never used the mapfile it created...). There are, however, a few minor changes on linux/x64 and linux/aarch64. I will discuss these below.

When I first started doing this conversion, I got a lot more differences. 

First of all, the `-fvisibility=hidden` flag does not apply to assembly files, so the symbols marked `.global` in these files also needed to be marked `.hidden`. (On macOS, Apple's clang assembler uses the directive `.private_extern` instead.) The assembly files had some inconsistent whitespace (using tabs instead of spaces every once in a while), which my editor kept changing, so I gave up and fixed all of them. This makes the diff artificially larger; if someone objects to this I can revert the whitespace changes.

Secondly, it turned out that there were several symbols declared `JNIEXPORT` that were not included in the symbol list, and hence were not exported on Linux. In contrast to Windows, which only relies on `JNIEXPORT`, on Linux it was necessary to both use `JNIEXPORT` and declare the symbol in the symbol list to get it actually exported. 

To be consistent with the old behavior, I have undefined `JNIEXPORT` in these files. It works to keep the output the same, but it does not look very nice. I suggest we either:

a) say we want to remove this `#undef` and actually export the functions annotated `JNIEXPORT`. This is what I would recommend. If so, let's keep the ugly undef for now, and I'll remove it in a follow-up bug. (I really would like not to change any behavior with this patch; it is intrusive enough as it is.)

b) say we really don't want to export these functions on Linux, only on Windows. In that case, we should probably replace `JNIEXPORT` with `FOO_EXPORT`, and define `FOO_EXPORT` to be `JNIEXPORT` on Windows, and blank on Linux.

This is a decision for the Hotspot team; let me know which solution you chose. (It can be different in different places, of course).

And thirdly, there seem to be a bug in gcc, which ignores the `-fvisibility=hidden` flag in certain circumstances involving templates. I could not pinpoint what conditions were necessary to trigger this bug, but in `accessBackend.cpp` I have manually added a `HIDDEN` attribute to a bunch of `arraycopy_conjoint` functions to keep them from being exported. It looks ugly; and we might be willing to accept that these functions are exported even though they should not be, to get rid of this. Or it might be that someone finds out if what is different with this declarations that trigger this bug, and constructs a work-around. (I gave up on it, though...)

About the  changes on linux/x64 and linux/aarch64: I believe the new values are in some way more correct, but I also think the difference is insignificant. The difference is that the  data (variable) symbols  `__bss_start`, `_edata` and `_end`, and the text (function) symbols `_fini` and `_init` has changed from local to global. Afaik, these are symbols created by the linker. Also, when we used a mapfile, the symbol `SUNWprivate_1.1` that was part of the mapfile definition was included in libjvm.so, and this is no longer the case. 

Finally, in the gtest libjvmo.so there are some additional differences as well. I did not really care about these, since this is only used for testing, but for the sake of completeness, here are the differences. They belong to two different categories. 

Group 1 includes four symbols like `_Z9type_nameIiEPKcv`. These come from this definition:

  template <typename T> const char* type_name();

in `test_parse_memory_size.cpp`, and is seemingly the same issue as with the `arraycopy_conjoint` functions in `accessBackend.cpp`. They have changed from local to global.

Group 2 includes symbols that seem to originate in the googletest library. They have changed
from local to global, but also to weak symbols. They match some different patterns:

* Seven symbols like `_ZNSt15_Sp_counted_ptrIPKN7testing8internal2REELN9__gnu_cxx12_Lock_policyE2EED2Ev`.
Demangled, these read `std::_Sp_counted_ptr<testing::internal::RE const*, (__gnu_cxx::_Lock_policy)2>`.

* One symbol `_ZN7testing15AssertionResultlsIA12_cEERS0_RKT_` (demangled: `testing::AssertionResult& testing::AssertionResult::operator<< <char [12]>(char const (&) [12])`)

* And finally, only on x64 (but not aarch64), one symbol `_ZN7testing4Test10HasFailureEv` (demangled: `testing::Test::HasFailure()`).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1958337547

From magnus.ihse.bursie at oracle.com  Wed Feb 21 23:56:18 2024
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 00:56:18 +0100
Subject: Hotspot symbol visibility - surprising news!
In-Reply-To: <CAMrH03K+fB1p5cEyEwo-QL3BfEC6iuugdd9P=nDkHy8FCRAr0Q@mail.gmail.com>
References: <645132e0-687e-4f04-9e49-f90131294367@oracle.com>
 <ba822e64-2a9c-447f-b545-b7fda01c47ef@oracle.com>
 <CAMrH03K+fB1p5cEyEwo-QL3BfEC6iuugdd9P=nDkHy8FCRAr0Q@mail.gmail.com>
Message-ID: <542d7939-19f3-4e66-946e-a1470c36f2d5@oracle.com>

On 2024-02-19 17:43, Daniel Jeli?ski wrote:

> Hi Magnus,
>
> The "massive generated mapfile" is used on Windows. As you noticed, on
> Linux symbols are exported if they are both JNIEXPORT and listed in
> the mapfile. On Windows, the symbols are exported if they are either
> JNIEXPORT or listed in the mapfile. The Windows symbolicator needs to
> see the vftables to tell apart different object types, and these
> tables are only made available in the produced binaries through the
> mapfile. The Windows mapfile exports the vftables of every virtual
> class in libjvm, which is much more than the symbolicator actually
> needs, but that's probably a separate topic.
>
> The symbolicator on Linux does not need the mapfile.
>
> The assembly functions are correctly labelled with .globl; if we
> remove these declarations or change them to local, the code won't
> link. The right solution here is to also label them as .hidden, for
> example using this script:
>
>       sed -i -n 'p;s/\.globa\?l/.hidden/p' src/hotspot/os_cpu/*/*.S
>
> The symbols from the standard libraries are not exported by any of our
> binaries. Libjvm removes them via the use of mapfile, and all other
> libraries are linked with  -Wl,--exclude-libs,ALL; if you choose to
> remove the mapfile from libjvm, you'll need to add that parameter.

Thanks Daniel. It is clear that you have studied this in detail. I 
rediscovered most of what you said here on my journey to fix 
JDK-8017234. :-)

I guess that after the mapfile removal, it would make sense to see if we 
can simplify the process for SA on Windows. Maybe it is possible to 
steal a page from the Linux book and look into the .DLL file directly. 
And also see if there is a way to get the macOS symbolicator to work 
with core dumps, and not only live processes. This is apparently not 
working.

/Magnus



From dholmes at openjdk.org  Thu Feb 22 00:20:52 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 22 Feb 2024 00:20:52 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <g0ZVkeeR7P1e4_8Z0-nQ8at63jrtZySDk8bKtub0mLw=.db5e4e9c-9ca6-4d5a-b31b-17f84981e14f@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <g0ZVkeeR7P1e4_8Z0-nQ8at63jrtZySDk8bKtub0mLw=.db5e4e9c-9ca6-4d5a-b31b-17f84981e14f@github.com>
Message-ID: <Cd8440seSvfWXHBcZ8cx5K1qWcpf-qyET1IdFY8eWUo=.a64a2d4c-bd34-49fb-9167-8e4583add959@github.com>

On Wed, 21 Feb 2024 23:32:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> it turned out that there were several symbols declared JNIEXPORT that were not included in the symbol list, 

There appear to be two main categories of functions here:

1. Those intended for use from a debugger

Have you verified those functions can still be called from the debugger?

2. JVMCI

The Graal folk will need to chime in here as it may be that these are needed for libgraal.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1958435740

From dholmes at openjdk.org  Thu Feb 22 00:32:52 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 22 Feb 2024 00:32:52 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
Message-ID: <qD5Ael_CjnuLVdZOdQ863VqU1KBJp1x7J1f3OPOJjcI=.fc651d8a-8640-405d-8339-bffc91b23050@github.com>

On Wed, 21 Feb 2024 23:32:15 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
> 
> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
> 
> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
> 
> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.

My main concern with a change like this as that it likely has little effect on the OpenJDK itself, but we may be changing something that 3rd party applications linking with libjvm are relying on.  I realize this is a bit "hand wavy" but are we sure this presents the exact same view of libjvm as before?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1958447138

From sviswanathan at openjdk.org  Thu Feb 22 01:23:55 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 22 Feb 2024 01:23:55 GMT
Subject: RFR: 8325991: Accelerate Poly1305 on x86_64 using AVX2
 instructions [v4]
In-Reply-To: <LLvSSnrEIYHk49CCs14ZPwXiBJYndwUwRSl6X-kajqI=.2ad38d7a-47fd-4e37-9db6-49e812ce97c5@github.com>
References: <IyoM1HY_rvNWwo4GxcV1yQleB3vrgaLwsAlOCEpLKqs=.1d50225c-8fe1-4a84-af56-274632b2b653@github.com>
 <LLvSSnrEIYHk49CCs14ZPwXiBJYndwUwRSl6X-kajqI=.2ad38d7a-47fd-4e37-9db6-49e812ce97c5@github.com>
Message-ID: <pfpRvKzkyOUQ1GYYtHNgqJcHmkT_ei28ZQZKVgZeCBU=.e0250c7b-f8c9-47fb-99f3-ca8504e36578@github.com>

On Wed, 21 Feb 2024 05:40:13 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> The goal of this PR is to accelerate the Poly1305 algorithm using AVX2 instructions (including IFMA) for x86_64 CPUs.
>> 
>> This implementation is directly based on the AVX2 Poly1305 hash computation as implemented in Intel(R) Multi-Buffer Crypto for IPsec Library (url: https://github.com/intel/intel-ipsec-mb/blob/main/lib/avx2_t3/poly_fma_avx2.asm)
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unused uniions and fix uses_vl

src/hotspot/cpu/x86/stubGenerator_x86_64_poly.cpp line 1252:

> 1250: 
> 1251:   // Calculate R^2
> 1252:   __ movq(t0, c1); // c1 = R1 + (R1 >> 2)

This move is not required. Function poly1305_multiply_scalar() is not using t0.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17881#discussion_r1498501498

From patrick at os.amperecomputing.com  Thu Feb 22 02:54:37 2024
From: patrick at os.amperecomputing.com (Patrick Zhang OS)
Date: Thu, 22 Feb 2024 02:54:37 +0000
Subject: Question: 8324776: How to safely tell if MADV_POPULATE_WRITE is
 supported
In-Reply-To: <CAA-vtUwQAboHB5je940HJrsjB7ZM9ZxzEqeiwp=0xJfLcXOZvA@mail.gmail.com>
References: <CO1PR01MB6694E52F1968421CE1D8E2968F572@CO1PR01MB6694.prod.exchangelabs.com>
 <CAA-vtUwQAboHB5je940HJrsjB7ZM9ZxzEqeiwp=0xJfLcXOZvA@mail.gmail.com>
Message-ID: <SA1PR01MB670167540DFC1BA099C8B2DA8F562@SA1PR01MB6701.prod.exchangelabs.com>


>> Is this a downstream-only patch specific to the Oracle Linux kernel?
Yes, I think so.
At linux-uek repo [1], it says that the uek6/u2 branch is for kernel v5.4 on Oracle Linux 7 and 8. Looking into the header file, we could see the definitions of 22/23, the commit is [2]. At the same time, Linux mainline?s max mode number was 21 and did not have 22/23. I have an attached PDF describing the diffs with various kernels, mainline vs uek, see [3].

By the way, uek kernel v5.15 used numbers 24/25 [4] for these two customized modes which would generate another conflict with mainline since 5.18-rc1 and 6.1 where the same numbers got used. I would suggest that uek kernel should put customized modes into a separate range, e.g., 100+, to avoid conflict.

[1] https://github.com/oracle/linux-uek/
[2] https://github.com/oracle/linux-uek/commit/a91ae4fa327d8957e2f806420b8b835269b85bd4
mm: introduce MADV_DOEXEC
madvise MADV_DOEXEC preserves a memory range across exec.  Initially
only supported for non-executable, non-stack, anonymous memory.
MADV_DOEXEC is single-use and after exec madvise must done again to
preserve memory for a subsequent exec.
MADV_DONTEXEC reverts the effect of a previous MADV_DOEXEC call and
undoes the preservation of the range.

#define MADV_DOEXEC                 22                           /* do inherit across exec */
#define MADV_DONTEXEC          23                           /* don't inherit across exec */

[3] https://bugs.openjdk.org/secure/attachment/108337/madvise_return_values.pdf, at https://bugs.openjdk.org/browse/JDK-8324776
[4] https://github.com/oracle/linux-uek/commit/4693c5d9d799eb4803c5afc781cc60e2b645e398

Regards, Patrick

From: Thomas St?fe <thomas.stuefe at gmail.com>
Sent: Thursday, February 22, 2024 0:56
To: Patrick Zhang OS <patrick at os.amperecomputing.com>
Cc: hotspot-dev developers <hotspot-dev at openjdk.java.net>; hotspot-gc-dev at openjdk.java.net
Subject: Re: Question: 8324776: How to safely tell if MADV_POPULATE_WRITE is supported

Hi,

I am trying to understand this better.

MADV_POPULATE_READ and MADV_POPULATE_WRITE were added to mainline with

```
 commit 4ca9b3859dac14bbef0c27d00667bb5b10917adb
 Author: David Hildenbrand <david at redhat.com<mailto:david at redhat.com>>
 Date:   Wed Jun 30 18:52:28 2021 -0700
     mm/madvise: introduce MADV_POPULATE_(READ|WRITE) to prefault page tables
```

and they used 22/23 as numerical identifier:

```
+#define MADV_POPULATE_READ     22      /* populate (prefault) page tables readable */
+#define MADV_POPULATE_WRITE    23      /* populate (prefault) page tables writable */
```

But I don't see a patch in mainline for MADV_DOEXEC. I do see a very lengthy RFR thread that seemed to end in patent disputes (?):
https://lore.kernel.org/all/1595869887-23307-1-git-send-email-anthony.yznaga at oracle.com/T/#u

Is this a downstream-only patch specific to the Oracle Linux kernel?

Cheers, Thomas



On Wed, Feb 21, 2024 at 4:25?PM Patrick Zhang OS <patrick at os.amperecomputing.com<mailto:patrick at os.amperecomputing.com>> wrote:
Hi,

I have a question regarding the regression reported by [1] which was caused by the commit [2].

The root cause can be briefly described as: MADV_POPULATE_WRITE has been supported since Linux 5.14. It is suggested to call madvise(0, 0, advice) to tell if this madvise mode is valid, which ?will return zero iff advice is supported by the kernel and can be relied on to probe for support? [3]. However Oracle UEKR6 5.4.17 has a duplicate definition of the number 23: MADV_DONTEXEC [4]. As a result, the test passes on Linux 5.4 mainline, while fails on UEK 5.4.17, because madvise(0, 0, 23) gives different return values. See details at [5].

It is a dilemma that how to fix so inside JVM. Thanks for any advice.

[1] https://bugs.openjdk.org/browse/JDK-8324776 runtime/os/TestTransparentHugePageUsage.java fails with The usage of THP is not enough
[2] https://bugs.openjdk.org/browse/JDK-8315923 pretouch_memory by atomic-add-0 fragments huge pages unexpectedly
[3] https://www.man7.org/linux/man-pages/man2/madvise.2.html
[4] https://yum.oracle.com/repo/OracleLinux/OL8/developer/UEKR6/aarch64/getPackageSource/kernel-uek-5.4.17-2136.327.2.el8uek.src.rpm, linux-5.4.17/include/uapi/asm-generic/mman-common.h#L75
[5] https://bugs.openjdk.org/browse/JDK-8324776?focusedId=14651275&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14651275.

Regards
Patrick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20240222/9404f7f8/attachment-0001.htm>

From sgibbons at openjdk.org  Thu Feb 22 03:15:10 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Thu, 22 Feb 2024 03:15:10 GMT
Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v13]
In-Reply-To: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
Message-ID: <MZj_08eJiTVFJyis-u7V8SBGal_cJ-6tIYr0oFseVpY=.329ca24b-48e3-4c3d-80ec-a395d9d8a4d5@github.com>

> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
> 
> 
> Benchmark	                                               Score		Latest		
> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
> StringIndexOf.success	                                9.186		9.713		1.057369911x
> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Addressed some review coments; replaced hard-coded registers with descriptive names.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/62e4e8b1..82bcd8b3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=11-12

  Stats: 484 lines in 3 files changed: 174 ins; 80 del; 230 mod
  Patch: https://git.openjdk.org/jdk/pull/16753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16753/head:pull/16753

PR: https://git.openjdk.org/jdk/pull/16753

From mdoerr at openjdk.org  Thu Feb 22 04:29:57 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 22 Feb 2024 04:29:57 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission [v8]
In-Reply-To: <VfsMOk5B0CnE0uPPvNjjBAMqNvc27-sEN2X4y_tcVO8=.a8f062f4-f15f-46d1-a22b-27c7ee9ff3d0@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
 <VfsMOk5B0CnE0uPPvNjjBAMqNvc27-sEN2X4y_tcVO8=.a8f062f4-f15f-46d1-a22b-27c7ee9ff3d0@github.com>
Message-ID: <yvaETVAXXKlTMGf9MlJo-YckVD4eoPYdbhsMqnOXXQU=.5cf29542-e38f-4b1c-a728-4962eb4a5a3c@github.com>

On Wed, 24 Jan 2024 17:46:46 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> # Description
>> 
>> Please review this PR with a patch to re-use the same C2_MacroAssembler object to emit all instructions in the same compilation unit.
>> 
>> Overall, the change is pretty simple. However, due to the renaming of the variable to access C2_MacroAssembler, from `_masm.` to `masm->`, and also some method prototype changes, the patch became quite large.
>> 
>> # Help Needed for Testing
>> 
>> I don't have access to all platforms necessary to test this. I hope some other folks can help with testing on `S390`, `RISC-V` and `PPC`.
>> 
>> # Tier-1 Testing status
>> 
>> |          |   Win   |   Mac   |  Linux  |
>> |----------|---------|---------|---------|
>> | ARM64    |    ?     |    ?     |         |
>> | ARM32    |    n/a     |     n/a    |         |
>> | x86      |         |         |    ?     |
>> | x64      |    ?     |    ?     |     ?    |
>> | PPC64    |  n/a       |   n/a      |         |
>> | S390x    |   n/a      |   n/a      |         |
>> | RiscV    |    n/a     |    n/a     |    ?     |
>
> 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 ten commits:
> 
>  - Catching up with origin/master
>  - Catch up with origin/master
>  - Merge with origin/master
>  - Fix build, copyright dates, m4 files.
>  - Fix merge
>  - Catch up with master branch.
>    
>    Merge remote-tracking branch 'origin/master' into reuse-macroasm
>  - Some inst_mark fixes; Catch up with master.
>  - Catch up with changes on master
>  - Reuse same C2_MacroAssembler object to emit instructions.

Seems like this PR got stuck because nobody has time to review such a large change. Maybe we should split the review work? I could review the PPC64 part if that helps.
Unfortunately, there are whitespace errors and a merge-conflict which need to get resolved.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16484#issuecomment-1958677211

From sspitsyn at openjdk.org  Thu Feb 22 05:44:55 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 22 Feb 2024 05:44:55 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v13]
In-Reply-To: <Cco030vThwW1VBFo5yhwotYyTsGBPFZPTCr0ULq03ww=.dab5a82c-011f-4d2c-8127-92f8695a4007@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <bpyapA636CevyF7zlYxxhEYa-rcPW-04QL3Tud_5bzs=.53c46cb2-bf47-4d1c-aad0-20c979ee2eb2@github.com>
 <Cco030vThwW1VBFo5yhwotYyTsGBPFZPTCr0ULq03ww=.dab5a82c-011f-4d2c-8127-92f8695a4007@github.com>
Message-ID: <_U8xyOmY0TPvWjiU5R3GTVMTArlPVmBmAJx-SjuMHUw=.0074abe0-1ce1-41fd-bbca-6257024dc868@github.com>

On Wed, 21 Feb 2024 22:23:27 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: addressed minor issue with use of []; corrected the test desctiption
>
> test/hotspot/jtreg/serviceability/jvmti/GetObjectMonitorUsage/ObjectMonitorUsage.java line 48:
> 
>> 46: public class ObjectMonitorUsage {
>> 47: 
>> 48:     final static int JCK_STATUS_BASE = 95;
> 
> JCK_STATUS_BASE is not used, need to be removed.

Thanks, done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1498672751

From sspitsyn at openjdk.org  Thu Feb 22 06:03:57 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 22 Feb 2024 06:03:57 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v13]
In-Reply-To: <Cco030vThwW1VBFo5yhwotYyTsGBPFZPTCr0ULq03ww=.dab5a82c-011f-4d2c-8127-92f8695a4007@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <bpyapA636CevyF7zlYxxhEYa-rcPW-04QL3Tud_5bzs=.53c46cb2-bf47-4d1c-aad0-20c979ee2eb2@github.com>
 <Cco030vThwW1VBFo5yhwotYyTsGBPFZPTCr0ULq03ww=.dab5a82c-011f-4d2c-8127-92f8695a4007@github.com>
Message-ID: <0_Cy_pSvPNQClMDFQDkz4z5LBK1ajGJbNdywx4kiyKQ=.fa711b33-8b76-4b5f-9817-e42c613109e8@github.com>

On Wed, 21 Feb 2024 22:36:31 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: addressed minor issue with use of []; corrected the test desctiption
>
> test/hotspot/jtreg/serviceability/jvmti/GetObjectMonitorUsage/ObjectMonitorUsage.java line 72:
> 
>> 70:      * - zero threads waiting to be notified
>> 71:      */
>> 72:     static void test1(boolean isVirtual) throws Error {
> 
> no need to add throws for unchecked excption

Fixed, thanks.

> test/hotspot/jtreg/serviceability/jvmti/GetObjectMonitorUsage/libObjectMonitorUsage.cpp line 117:
> 
>> 115:       LOG(">>> [%2d]    owner: none (0x0)\n", count);
>> 116:     } else {
>> 117:       err = jvmti->GetThreadInfo(inf.owner, &tinf);
> 
> need to check err status.

Fixed, thanks.

> test/hotspot/jtreg/serviceability/jvmti/GetObjectMonitorUsage/libObjectMonitorUsage.cpp line 126:
> 
>> 124:         LOG(">>>       waiters:\n");
>> 125:         for (j = 0; j < inf.waiter_count; j++) {
>> 126:           err = jvmti->GetThreadInfo(inf.waiters[j], &tinf);
> 
> need to check err.

Done, thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1498688861
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1498690913
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1498688037

From sspitsyn at openjdk.org  Thu Feb 22 06:08:56 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 22 Feb 2024 06:08:56 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v13]
In-Reply-To: <Cco030vThwW1VBFo5yhwotYyTsGBPFZPTCr0ULq03ww=.dab5a82c-011f-4d2c-8127-92f8695a4007@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <bpyapA636CevyF7zlYxxhEYa-rcPW-04QL3Tud_5bzs=.53c46cb2-bf47-4d1c-aad0-20c979ee2eb2@github.com>
 <Cco030vThwW1VBFo5yhwotYyTsGBPFZPTCr0ULq03ww=.dab5a82c-011f-4d2c-8127-92f8695a4007@github.com>
Message-ID: <GwB7XrWMl4y3imOk6vZrMt0E9BqGN64Cqa3xa0gitqE=.b6fca6b5-f3df-4ff5-bd24-5120539371fb@github.com>

On Wed, 21 Feb 2024 22:34:19 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: addressed minor issue with use of []; corrected the test desctiption
>
> test/hotspot/jtreg/serviceability/jvmti/GetObjectMonitorUsage/ObjectMonitorUsage.java line 42:
> 
>> 40:  *       - all the above is checked for both platform and virtual threads
>> 41:  * @requires vm.jvmti
>> 42:  * @compile ObjectMonitorUsage.java
> 
> No need to have explicit compile for the test code.

Fixed, thanks.

> test/hotspot/jtreg/serviceability/jvmti/GetObjectMonitorUsage/ObjectMonitorUsage.java line 204:
> 
>> 202: 
>> 203:         // test virtual threads
>> 204:         test1(false);
> 
> shouldn't be true here?

Nice catch, thanks. Fixed now.

> test/hotspot/jtreg/serviceability/jvmti/GetObjectMonitorUsage/libObjectMonitorUsage.cpp line 105:
> 
>> 103:   err = jvmti->GetObjectMonitorUsage(obj, &inf);
>> 104:   if (err == JVMTI_ERROR_MUST_POSSESS_CAPABILITY && !caps.can_get_monitor_info) {
>> 105:     return; /* Ok, it's expected */
> 
> I think we don't need this path.

Yes. Fixed, thanks.

> test/hotspot/jtreg/serviceability/jvmti/GetObjectMonitorUsage/libObjectMonitorUsage.cpp line 107:
> 
>> 105:     return; /* Ok, it's expected */
>> 106:   } else if (err != JVMTI_ERROR_NONE) {
>> 107:     LOG("(GetMonitorInfo#%d) unexpected error: %s (%d)\n",
> 
> you could use check_jvmti_status

Fixed, thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1498694748
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1498694426
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1498693585
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1498693206

From jwaters at openjdk.org  Thu Feb 22 06:44:53 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Feb 2024 06:44:53 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
Message-ID: <BAVHdaJzKtovZ1f0mrdLQI0AL_vGXRJJ2UG_w9DuCfs=.33111872-8fd0-4c06-9b23-0b41556a2cff@github.com>

On Wed, 21 Feb 2024 23:32:15 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
> 
> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
> 
> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
> 
> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.

src/hotspot/share/oops/accessBackend.cpp line 36:

> 34: 
> 35: #if defined(TARGET_COMPILER_gcc)
> 36: #define HIDDEN __attribute__ ((visibility ("hidden")))

Couldn't this use [[gnu::visibility("hidden")]] instead, since HotSpot now allows C++14 Attributes? But this doesn't look like a very nice solution regardless

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1498728906

From jwaters at openjdk.org  Thu Feb 22 07:15:53 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Feb 2024 07:15:53 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
Message-ID: <17uxknoRrcfnUlWwJndQk2AWqvZv4v34JZMVQPpl81w=.34a2c1a8-d251-4f8c-bd12-2f024b4914e6@github.com>

On Wed, 21 Feb 2024 23:32:15 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
> 
> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
> 
> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
> 
> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.

make/hotspot/lib/CompileJvm.gmk line 149:

> 147: 
> 148: ifeq ($(call isTargetOs, windows), true)
> 149:   WIN_EXPORT_FILE := $(JVM_OUTPUTDIR)/win-exports.txt

Why not .def?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1498758500

From sspitsyn at openjdk.org  Thu Feb 22 07:30:58 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 22 Feb 2024 07:30:58 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v13]
In-Reply-To: <Cco030vThwW1VBFo5yhwotYyTsGBPFZPTCr0ULq03ww=.dab5a82c-011f-4d2c-8127-92f8695a4007@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <bpyapA636CevyF7zlYxxhEYa-rcPW-04QL3Tud_5bzs=.53c46cb2-bf47-4d1c-aad0-20c979ee2eb2@github.com>
 <Cco030vThwW1VBFo5yhwotYyTsGBPFZPTCr0ULq03ww=.dab5a82c-011f-4d2c-8127-92f8695a4007@github.com>
Message-ID: <aGChdFfKGQWioEjxRMngMOc7F996NITSzSfAjqmjMdY=.d5df4086-970c-40e9-b8f0-bb9038649001@github.com>

On Wed, 21 Feb 2024 22:33: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:
>> 
>>   review: addressed minor issue with use of []; corrected the test desctiption
>
> test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage003.java line 31:
> 
>> 29: 
>> 30:     final static int JCK_STATUS_BASE = 95;
>> 31:     final static int NUMBER_OF_THREADS = 16;
> 
> Better to remove the test if it already converted to avoid mess.

Agreed. I was thinking about the same.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1498773675

From dholmes at openjdk.org  Thu Feb 22 07:41:07 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 22 Feb 2024 07:41:07 GMT
Subject: RFR: 8318302: ThreadCountLimit.java failed with
 "Native memory allocation (mprotect) failed to protect 16384 bytes for memory
 to guard stack pages"
Message-ID: <owqAt1_7CSCVlCen_Lp7b3q1jMSjsU-D2SKq5ciBDgo=.1ec82f53-23b1-477d-887c-280b3721a505@github.com>

The test tries to create as many threads as possible in 5 seconds, with the intention of hitting platform limits on the maximum number of threads that can be created, so that we see that the VM reacts in a reasonable way. However on Linux, if the thread creation limit is high enough, and things run fast enough, then we can instead hit a fatal error when a mmap/mprotect returns E_NOMEM because the maximum number of memory mappings (default 65530) has been exceeded.

The fix to the test (courtesy @stefank ) is to re-exec the test on Linux with `ulimit -u` set to a much smaller value than the default (I chose 4096 as it still showed over 2000 threads were created before failure). This means we are unlikely to hit the default memory mapping limit before we hit the max threads limit.

I also updated the VM's OOM error message to include exceeding the maximum number of memory mappings as a possible cause (with a hint as to what to look for in the hs_err log).

Testing:
 - ran the test 10x on all platforms in our CI (plus local testing)

Thanks

-------------

Commit messages:
 - rtypo
 - 8318302: ThreadCountLimit.java failed with "Native memory allocation (mprotect) failed to protect 16384 bytes for memory to guard stack pages"

Changes: https://git.openjdk.org/jdk/pull/17959/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17959&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318302
  Stats: 48 lines in 2 files changed: 34 ins; 5 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/17959.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17959/head:pull/17959

PR: https://git.openjdk.org/jdk/pull/17959

From kvn at openjdk.org  Thu Feb 22 07:49:57 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 22 Feb 2024 07:49:57 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission [v8]
In-Reply-To: <VfsMOk5B0CnE0uPPvNjjBAMqNvc27-sEN2X4y_tcVO8=.a8f062f4-f15f-46d1-a22b-27c7ee9ff3d0@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
 <VfsMOk5B0CnE0uPPvNjjBAMqNvc27-sEN2X4y_tcVO8=.a8f062f4-f15f-46d1-a22b-27c7ee9ff3d0@github.com>
Message-ID: <UKbayJiqzP8mWdAYpVXCF6v2Um8rwxU6hAsTvf-rrh0=.25984456-7d63-478d-8039-620d0410f78b@github.com>

On Wed, 24 Jan 2024 17:46:46 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> # Description
>> 
>> Please review this PR with a patch to re-use the same C2_MacroAssembler object to emit all instructions in the same compilation unit.
>> 
>> Overall, the change is pretty simple. However, due to the renaming of the variable to access C2_MacroAssembler, from `_masm.` to `masm->`, and also some method prototype changes, the patch became quite large.
>> 
>> # Help Needed for Testing
>> 
>> I don't have access to all platforms necessary to test this. I hope some other folks can help with testing on `S390`, `RISC-V` and `PPC`.
>> 
>> # Tier-1 Testing status
>> 
>> |          |   Win   |   Mac   |  Linux  |
>> |----------|---------|---------|---------|
>> | ARM64    |    ?     |    ?     |         |
>> | ARM32    |    n/a     |     n/a    |         |
>> | x86      |         |         |    ?     |
>> | x64      |    ?     |    ?     |     ?    |
>> | PPC64    |  n/a       |   n/a      |         |
>> | S390x    |   n/a      |   n/a      |         |
>> | RiscV    |    n/a     |    n/a     |    ?     |
>
> 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 ten commits:
> 
>  - Catching up with origin/master
>  - Catch up with origin/master
>  - Merge with origin/master
>  - Fix build, copyright dates, m4 files.
>  - Fix merge
>  - Catch up with master branch.
>    
>    Merge remote-tracking branch 'origin/master' into reuse-macroasm
>  - Some inst_mark fixes; Catch up with master.
>  - Catch up with changes on master
>  - Reuse same C2_MacroAssembler object to emit instructions.

Yes, I have the same issue. When I have time to test it - it does not merge. I reviewed x86.
I think `NULL` -> `nullptr` can be removed from these changes since they are already fixed in main sources.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16484#issuecomment-1958878271

From djelinski at openjdk.org  Thu Feb 22 07:52:55 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 22 Feb 2024 07:52:55 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
Message-ID: <vXCbCZSVLYSkkeXQTOvMSxst4Yfi2ZaHikbUPhuTiME=.8995f473-11cd-4265-afa3-0e4376be88e8@github.com>

On Wed, 21 Feb 2024 23:32:15 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
> 
> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
> 
> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
> 
> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.

Thanks for doing this! This is a good improvement IMO.

If the `SUNWprivate_1.1` part of the symbols is still needed, it can be added using `--default-symver` ld parameter.

You might want to run tier1-5 tests; compilation-related changes are often detected by higher-level builds and tests only.

src/hotspot/os_cpu/linux_arm/linux_arm_32.S line 35:

> 33:         .type SpinPause, %function
> 34:         .globl _Copy_conjoint_bytes
> 35:         .hidden _Copy_conjoint_bytes

This triggered a GHA failure... apparently the method `_Copy_conjoint_bytes` was removed a long time ago, and the `.globl` / `.type` declarations are the only things left. They should also be removed.

src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 74:

> 72: 
> 73: #if defined(TARGET_COMPILER_gcc)
> 74: #undef JNIEXPORT

Based on the suggestion in [this JBS comment](https://bugs.openjdk.org/browse/JDK-8017234?focusedId=14601421&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14601421), I think we can remove JNIEXPORT from all the functions in this file.

We need to keep the JNICALL though; the deprecated Win32 port needs it, not sure if it's used anywhere else.

src/hotspot/share/utilities/debug.cpp line 71:

> 69: 
> 70: #if defined(TARGET_COMPILER_gcc)
> 71: #undef JNIEXPORT

This partially reverts [JDK-8264593](https://bugs.openjdk.org/browse/JDK-8264593); @kevinjwalls will this work for you?

-------------

PR Review: https://git.openjdk.org/jdk/pull/17955#pullrequestreview-1895071246
PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1498753308
PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1498794516
PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1498786497

From dnsimon at openjdk.org  Thu Feb 22 08:48:54 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 22 Feb 2024 08:48:54 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <Cd8440seSvfWXHBcZ8cx5K1qWcpf-qyET1IdFY8eWUo=.a64a2d4c-bd34-49fb-9167-8e4583add959@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <g0ZVkeeR7P1e4_8Z0-nQ8at63jrtZySDk8bKtub0mLw=.db5e4e9c-9ca6-4d5a-b31b-17f84981e14f@github.com>
 <Cd8440seSvfWXHBcZ8cx5K1qWcpf-qyET1IdFY8eWUo=.a64a2d4c-bd34-49fb-9167-8e4583add959@github.com>
Message-ID: <WgT5R65Kbubtx35Uyw2XAILZQZufGVOXOeS6oFk7tEk=.30c8ff36-82c7-4066-9a9e-ee3293f46810@github.com>

On Thu, 22 Feb 2024 00:18:16 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The Graal folk will need to chime in here as it may be that these are needed for libgraal.

They should be fine. JNI linkage is only used by the native methods in `CompilerToVM.java`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1958966709

From shade at openjdk.org  Thu Feb 22 08:53:24 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 22 Feb 2024 08:53:24 GMT
Subject: RFR: 8324833: Signed integer overflows in ABS [v5]
In-Reply-To: <ohwAn6GqM7FIgYTJNy40VBYSCVEBrrNSqBaz2akN54M=.f9660235-3047-47ee-aad0-ef598d6ebdcc@github.com>
References: <ohwAn6GqM7FIgYTJNy40VBYSCVEBrrNSqBaz2akN54M=.f9660235-3047-47ee-aad0-ef598d6ebdcc@github.com>
Message-ID: <mAJDTIVvBG-4AX5TX7ucgVzlGZ7g4dtVB0Lk0EZjNWM=.84424e17-99b7-47be-bab0-0f5b7701755d@github.com>

> See the details in the bug. I think current `ABS` implementation is beyond repair, and we should just switch to `uabs`.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, `all` with `-ftrapv` (now fully passes!)
>  - [x] Linux x86_64 fastdebug, `all`

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Fix a place where we cast to jlong after uabs

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17617/files
  - new: https://git.openjdk.org/jdk/pull/17617/files/272fb16b..b9422420

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17617&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17617&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17617.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17617/head:pull/17617

PR: https://git.openjdk.org/jdk/pull/17617

From shade at openjdk.org  Thu Feb 22 08:59:54 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 22 Feb 2024 08:59:54 GMT
Subject: RFR: 8324833: Signed integer overflows in ABS [v3]
In-Reply-To: <5kgtFYu0BR73lbSSncYgXJMsqorb8iXf8AMgbkoyR3Y=.5b05afe8-3517-4708-90fa-2207823ff0f1@github.com>
References: <ohwAn6GqM7FIgYTJNy40VBYSCVEBrrNSqBaz2akN54M=.f9660235-3047-47ee-aad0-ef598d6ebdcc@github.com>
 <6kxKhJVXB2X7ni4SLMtL--Pt5O8bUOazcI9F3FJgG8o=.55b0e9bd-075c-4b76-bcc6-732951e8a512@github.com>
 <jhK6TNMKlimTl4hIhwzV_6vZDUYSSwk2J0XuPqCIxs0=.4f4bd7aa-4cc0-49c0-ad06-56ab3e166127@github.com>
 <5kgtFYu0BR73lbSSncYgXJMsqorb8iXf8AMgbkoyR3Y=.5b05afe8-3517-4708-90fa-2207823ff0f1@github.com>
Message-ID: <2rWRNfo87Wzb7VQF3GDVDJTh0W8Ry4d4xBFvDRIwhI0=.77554aa9-5559-4811-ab4b-4534bd0e8961@github.com>

On Sat, 3 Feb 2024 19:14:40 GMT, Andrew Haley <aph at openjdk.org> wrote:

> I think it's confusing and error-prone to use uabs() for signed values. Using `checked_cast` silences warnings but doesn't handle the undefined behavior caused by values such as min_jint and min_jlong. 

Getting back to this...

AFAICS, `uabs` is well-defined: all possible values of `jlong` passed there, including `min_jlong` would be mapped to a correct unsigned value. We "only" need to make sure that the math is then done over unsigned values. I agree that immediately casting to `jlong` after `uabs` is dodgy when we can reasonably get the unsigned `julong` value from uabs that would not fit in `jlong`, making it negative. I think I fixed a single place where it can possibly happen.

I am re-running tests with -ftrapv now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17617#issuecomment-1958982089

From stefank at openjdk.org  Thu Feb 22 09:10:56 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 22 Feb 2024 09:10:56 GMT
Subject: RFR: 8325870: Zap end padding bits for ArrayOops in non-release
 builds [v2]
In-Reply-To: <uaOTZ1Fy2T-T_lg6zmczYcREvcTgWMq01gl7eb16fFk=.3a16fa3d-5d7e-46bc-bd59-dacab77a3218@github.com>
References: <xgOWw0IQ0eQC0CDEqok0nnpLs4mxaJFL_rsUzutCnfI=.76d226fe-e9a4-4d05-8440-53df8d1dea00@github.com>
 <uaOTZ1Fy2T-T_lg6zmczYcREvcTgWMq01gl7eb16fFk=.3a16fa3d-5d7e-46bc-bd59-dacab77a3218@github.com>
Message-ID: <22LR9HkvFOWqYGuC6Ux7ICjYxfU7mEpxpuKIVLeNK3I=.4981074c-bfc2-41c3-b5ec-9929c3825aee@github.com>

On Wed, 21 Feb 2024 14:40:05 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Make `ObjArrayAllocator` zap the end padding bits in not PRODUCT builds.
>> 
>> Issues like [JDK-8325074](https://bugs.openjdk.org/browse/JDK-8325074) / #17863 would then reproduce deterministically. Avoid future regressions.
>> 
>> Guarded `Copy::fill_to_bytes`, it was not clear if or how it handles `count == 0`. Given that almost all dispatch to memset, the `count == 0` would probably be alright, but as `obj_end - padding_in_bytes` may point beyond an object and thus outside the heap it seems prudent to guard it (I believe memset requires a valid pointer).
>
> Axel Boldt-Christmas has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update copyright years
>  - Use *_end pointers and add assert
>  - Rename heapPaddingByte to heapPaddingByteVal

Marked as reviewed by stefank (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17864#pullrequestreview-1895298559

From aboldtch at openjdk.org  Thu Feb 22 09:16:59 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 22 Feb 2024 09:16:59 GMT
Subject: RFR: 8325870: Zap end padding bits for ArrayOops in non-release
 builds [v2]
In-Reply-To: <uaOTZ1Fy2T-T_lg6zmczYcREvcTgWMq01gl7eb16fFk=.3a16fa3d-5d7e-46bc-bd59-dacab77a3218@github.com>
References: <xgOWw0IQ0eQC0CDEqok0nnpLs4mxaJFL_rsUzutCnfI=.76d226fe-e9a4-4d05-8440-53df8d1dea00@github.com>
 <uaOTZ1Fy2T-T_lg6zmczYcREvcTgWMq01gl7eb16fFk=.3a16fa3d-5d7e-46bc-bd59-dacab77a3218@github.com>
Message-ID: <7QTLyUhPq16k1fP7P-j7cuDCnCq8rqkZcER7wCUtmSk=.8fc673c2-ba87-4ec1-bd1e-d1d4949b4581@github.com>

On Wed, 21 Feb 2024 14:40:05 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Make `ObjArrayAllocator` zap the end padding bits in not PRODUCT builds.
>> 
>> Issues like [JDK-8325074](https://bugs.openjdk.org/browse/JDK-8325074) / #17863 would then reproduce deterministically. Avoid future regressions.
>> 
>> Guarded `Copy::fill_to_bytes`, it was not clear if or how it handles `count == 0`. Given that almost all dispatch to memset, the `count == 0` would probably be alright, but as `obj_end - padding_in_bytes` may point beyond an object and thus outside the heap it seems prudent to guard it (I believe memset requires a valid pointer).
>
> Axel Boldt-Christmas has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update copyright years
>  - Use *_end pointers and add assert
>  - Rename heapPaddingByte to heapPaddingByteVal

Thanks for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17864#issuecomment-1959011491

From aboldtch at openjdk.org  Thu Feb 22 09:17:00 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 22 Feb 2024 09:17:00 GMT
Subject: Integrated: 8325870: Zap end padding bits for ArrayOops in non-release
 builds
In-Reply-To: <xgOWw0IQ0eQC0CDEqok0nnpLs4mxaJFL_rsUzutCnfI=.76d226fe-e9a4-4d05-8440-53df8d1dea00@github.com>
References: <xgOWw0IQ0eQC0CDEqok0nnpLs4mxaJFL_rsUzutCnfI=.76d226fe-e9a4-4d05-8440-53df8d1dea00@github.com>
Message-ID: <H_9cWMStAZ3N5SBAaMAC6kXql8K4r1limnxJIpD3ltg=.1816540d-690e-4ed5-9a3b-f0d64b0c6a3d@github.com>

On Thu, 15 Feb 2024 07:25:48 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Make `ObjArrayAllocator` zap the end padding bits in not PRODUCT builds.
> 
> Issues like [JDK-8325074](https://bugs.openjdk.org/browse/JDK-8325074) / #17863 would then reproduce deterministically. Avoid future regressions.
> 
> Guarded `Copy::fill_to_bytes`, it was not clear if or how it handles `count == 0`. Given that almost all dispatch to memset, the `count == 0` would probably be alright, but as `obj_end - padding_in_bytes` may point beyond an object and thus outside the heap it seems prudent to guard it (I believe memset requires a valid pointer).

This pull request has now been integrated.

Changeset: 10eafdc6
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/10eafdc62e8216e6ef69773fe491a21346c8682d
Stats:     42 lines in 4 files changed: 25 ins; 0 del; 17 mod

8325870: Zap end padding bits for ArrayOops in non-release builds

Reviewed-by: stefank, ayang

-------------

PR: https://git.openjdk.org/jdk/pull/17864

From shade at openjdk.org  Thu Feb 22 09:19:57 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 22 Feb 2024 09:19:57 GMT
Subject: RFR: 8318302: ThreadCountLimit.java failed with
 "Native memory allocation (mprotect) failed to protect 16384 bytes for memory
 to guard stack pages"
In-Reply-To: <owqAt1_7CSCVlCen_Lp7b3q1jMSjsU-D2SKq5ciBDgo=.1ec82f53-23b1-477d-887c-280b3721a505@github.com>
References: <owqAt1_7CSCVlCen_Lp7b3q1jMSjsU-D2SKq5ciBDgo=.1ec82f53-23b1-477d-887c-280b3721a505@github.com>
Message-ID: <98Z3mMnDM6NuPlwduJ0MN9KnlP7NYdIxqXikHZE5JuE=.973a703f-9bf0-437f-93ab-ac01f385b824@github.com>

On Thu, 22 Feb 2024 07:36:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The test tries to create as many threads as possible in 5 seconds, with the intention of hitting platform limits on the maximum number of threads that can be created, so that we see that the VM reacts in a reasonable way. However on Linux, if the thread creation limit is high enough, and things run fast enough, then we can instead hit a fatal error when a mmap/mprotect returns E_NOMEM because the maximum number of memory mappings (default 65530) has been exceeded.
> 
> The fix to the test (courtesy @stefank ) is to re-exec the test on Linux with `ulimit -u` set to a much smaller value than the default (I chose 4096 as it still showed over 2000 threads were created before failure). This means we are unlikely to hit the default memory mapping limit before we hit the max threads limit.
> 
> I also updated the VM's OOM error message to include exceeding the maximum number of memory mappings as a possible cause (with a hint as to what to look for in the hs_err log).
> 
> Testing:
>  - ran the test 10x on all platforms in our CI (plus local testing)
> 
> Thanks

Looks fine to me, with nits.

Maybe deserves a little synopsis change: "8318302: ThreadCountLimit.java failed due to too many memory mappings"

test/hotspot/jtreg/runtime/Thread/ThreadCountLimit.java line 80:

> 78:         final String ULIMIT_CMD = "ulimit -u 4096";
> 79:         ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder(ThreadCountLimit.class.getName());
> 80:         String java_cmd = ProcessTools.getCommandLine(pb);

Nit: `java_cmd` -> `javaCmd`.

test/hotspot/jtreg/runtime/Thread/ThreadCountLimit.java line 82:

> 80:         String java_cmd = ProcessTools.getCommandLine(pb);
> 81:         // Relaunch the test with args.length > 0, and the ulimit set
> 82:         ProcessTools.executeCommand("bash", "-c", ULIMIT_CMD + " && " + java_cmd + " dummy")

I think this assumes `bash` is installed, which is true 99% of the time, but not actually guaranteed. Maybe we should check `if (Platform.isLinux() && new File("/bin/bash").exists())` explicitly.

test/hotspot/jtreg/runtime/Thread/ThreadCountLimit.java line 142:

> 140:     // Now that all threads have joined, we are away from dangerous
> 141:     // VM state and have enough memory to perform any other things.
> 142:     if (!reachedNativeOOM) {

Cleanup: flip this around to avoid negation in `!reachedNativeOOM`.

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17959#pullrequestreview-1895288969
PR Comment: https://git.openjdk.org/jdk/pull/17959#issuecomment-1959016262
PR Review Comment: https://git.openjdk.org/jdk/pull/17959#discussion_r1498901287
PR Review Comment: https://git.openjdk.org/jdk/pull/17959#discussion_r1498907529
PR Review Comment: https://git.openjdk.org/jdk/pull/17959#discussion_r1498895112

From stefank at openjdk.org  Thu Feb 22 09:24:54 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 22 Feb 2024 09:24:54 GMT
Subject: RFR: 8318302: ThreadCountLimit.java failed with
 "Native memory allocation (mprotect) failed to protect 16384 bytes for memory
 to guard stack pages"
In-Reply-To: <owqAt1_7CSCVlCen_Lp7b3q1jMSjsU-D2SKq5ciBDgo=.1ec82f53-23b1-477d-887c-280b3721a505@github.com>
References: <owqAt1_7CSCVlCen_Lp7b3q1jMSjsU-D2SKq5ciBDgo=.1ec82f53-23b1-477d-887c-280b3721a505@github.com>
Message-ID: <Be6feUpIZgdY7fWXo_ieltQ8aF9zla2-bHupaA8T0UQ=.cd5a226f-30e7-48e4-9d47-3f3d56fdccfe@github.com>

On Thu, 22 Feb 2024 07:36:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The test tries to create as many threads as possible in 5 seconds, with the intention of hitting platform limits on the maximum number of threads that can be created, so that we see that the VM reacts in a reasonable way. However on Linux, if the thread creation limit is high enough, and things run fast enough, then we can instead hit a fatal error when a mmap/mprotect returns E_NOMEM because the maximum number of memory mappings (default 65530) has been exceeded.
> 
> The fix to the test (courtesy @stefank ) is to re-exec the test on Linux with `ulimit -u` set to a much smaller value than the default (I chose 4096 as it still showed over 2000 threads were created before failure). This means we are unlikely to hit the default memory mapping limit before we hit the max threads limit.
> 
> I also updated the VM's OOM error message to include exceeding the maximum number of memory mappings as a possible cause (with a hint as to what to look for in the hs_err log).
> 
> Testing:
>  - ran the test 10x on all platforms in our CI (plus local testing)
> 
> Thanks

Thanks for handling this issue.

-------------

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17959#pullrequestreview-1895327648

From ihse at openjdk.org  Thu Feb 22 09:28:56 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 09:28:56 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <Cd8440seSvfWXHBcZ8cx5K1qWcpf-qyET1IdFY8eWUo=.a64a2d4c-bd34-49fb-9167-8e4583add959@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <g0ZVkeeR7P1e4_8Z0-nQ8at63jrtZySDk8bKtub0mLw=.db5e4e9c-9ca6-4d5a-b31b-17f84981e14f@github.com>
 <Cd8440seSvfWXHBcZ8cx5K1qWcpf-qyET1IdFY8eWUo=.a64a2d4c-bd34-49fb-9167-8e4583add959@github.com>
Message-ID: <-pzo3-C5dN9IRd4dv7k_j8E0i7jR578u1gst0U6iAFI=.34ce218c-3d3f-409a-9c60-315eaab370fa@github.com>

On Thu, 22 Feb 2024 00:18:16 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > it turned out that there were several symbols declared JNIEXPORT that were not included in the symbol list,
> 
> There appear to be two main categories of functions here:
> 
>     1. Those intended for use from a debugger
> 
> 
> Have you verified those functions can still be called from the debugger?
> 
>     2. JVMCI
> 
> 
> The Graal folk will need to chime in here as it may be that these are needed for libgraal.

I tried to be clear, but apparently I failed: There is *no* change to these symbols in the patch! So everything should work just as before!

The reason I even brought it up to discussion is that it required a bit of a "hack" to keep the functionality identical, and this looks suspicious in the source code.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1959032516

From ihse at openjdk.org  Thu Feb 22 09:32:57 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 09:32:57 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <17uxknoRrcfnUlWwJndQk2AWqvZv4v34JZMVQPpl81w=.34a2c1a8-d251-4f8c-bd12-2f024b4914e6@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <17uxknoRrcfnUlWwJndQk2AWqvZv4v34JZMVQPpl81w=.34a2c1a8-d251-4f8c-bd12-2f024b4914e6@github.com>
Message-ID: <28TkIQvEbOiKscThXtUGZ24pcHI4wqrVgy6C2P6_f-4=.ae8dcc41-aedd-441c-a8ad-1526dd56db14@github.com>

On Thu, 22 Feb 2024 07:13:03 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
>> 
>> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
>> 
>> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
>> 
>> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.
>
> make/hotspot/lib/CompileJvm.gmk line 149:
> 
>> 147: 
>> 148: ifeq ($(call isTargetOs, windows), true)
>> 149:   WIN_EXPORT_FILE := $(JVM_OUTPUTDIR)/win-exports.txt
> 
> Why not .def?

I try to stick to established file suffixes if possible. I have never heard of .def before, but maybe that is a standard name for these kinds of files on Windows? If so, I will change it.

> src/hotspot/share/oops/accessBackend.cpp line 36:
> 
>> 34: 
>> 35: #if defined(TARGET_COMPILER_gcc)
>> 36: #define HIDDEN __attribute__ ((visibility ("hidden")))
> 
> Couldn't this use [[gnu::visibility("hidden")]] instead, since HotSpot now allows C++14 Attributes? But this doesn't look like a very nice solution regardless

We're currently using __attribute__ ((visibility ("X"))) elsewhere, so I think I should stick with that.

And, as I said in my long explanation, this is definitely a hack. The reason it is here is that I want to make sure the symbol table is 100% identical before and after this patch. 

Why this is needed, I don't know. I believe it is a bug in GCC, since we compile with -fvisibility=hidden. But I don't really know. Maybe there is something in the C++ standard that makes these functions behave differently. Perhaps they are even slightly incorrectly defined?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1498935395
PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1498933843

From ihse at openjdk.org  Thu Feb 22 09:39:53 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 09:39:53 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <vXCbCZSVLYSkkeXQTOvMSxst4Yfi2ZaHikbUPhuTiME=.8995f473-11cd-4265-afa3-0e4376be88e8@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <vXCbCZSVLYSkkeXQTOvMSxst4Yfi2ZaHikbUPhuTiME=.8995f473-11cd-4265-afa3-0e4376be88e8@github.com>
Message-ID: <z5hne_1-iA5I6aud_Z1pqiiQh7lkKs-lPIVHKn8r8DY=.cd39b73b-ed93-4000-9fe3-9480fd75af9e@github.com>

On Thu, 22 Feb 2024 07:50:34 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Thanks for doing this! This is a good improvement IMO.

Thanks! 

> If the `SUNWprivate_1.1` part of the symbols is still needed, it can be added using `--default-symver` ld parameter.

Ah, good to know. In the spirit of making as minimal changes as possible in this PR, I will add it.

> You might want to run tier1-5 tests; compilation-related changes are often detected by higher-level builds and tests only.

I can run tier 4 and 5 also. But once again, the entire point of this PR being so convoluted is that there should be a minimum of differences in compilation. 

On macOS and Windows, the binaries before and after this patch are almost identical; just a few hundred assembler instructions have been reordered slightly. (Why this is even so I don't know, but in the end I did not care to dig into the details.)

On Linux, more code is shuffled around, making for a greater bit-by-bit difference. Still, the symbol tables are (almost) identical, and these changes should only affect symbol visibility, so I believe this is mostly an artifact of how the linker organises stuff.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1959051714

From ihse at openjdk.org  Thu Feb 22 09:43:55 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 09:43:55 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <vXCbCZSVLYSkkeXQTOvMSxst4Yfi2ZaHikbUPhuTiME=.8995f473-11cd-4265-afa3-0e4376be88e8@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <vXCbCZSVLYSkkeXQTOvMSxst4Yfi2ZaHikbUPhuTiME=.8995f473-11cd-4265-afa3-0e4376be88e8@github.com>
Message-ID: <2wcpOdg70sjre1ULOsoeTKxu7Axq46zoU9qo_bkMgdM=.87d80995-09f3-417a-9270-56dd365d2b06@github.com>

On Thu, 22 Feb 2024 07:39:51 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
>> 
>> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
>> 
>> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
>> 
>> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.
>
> src/hotspot/share/utilities/debug.cpp line 71:
> 
>> 69: 
>> 70: #if defined(TARGET_COMPILER_gcc)
>> 71: #undef JNIEXPORT
> 
> This partially reverts [JDK-8264593](https://bugs.openjdk.org/browse/JDK-8264593); @kevinjwalls will this work for you?

No, it doesn't. Even after [JDK-8264593](https://bugs.openjdk.org/browse/JDK-8264593) the symbols from debug.cpp were not exported on Linux, since they were not mentioned in `make/data/hotspot-symbols`, and thus were made local.

The reason I put this in was to keep parity with the symbol table before and after the patch.

My guess is that it was only on Windows it was necessary that the functions where JNIEXPORTed, otherwise someone would have complained after JDK-8264593. But for platform consistency, it might make sense to export these even on gcc as well. After this PR is integrated, this is easy to do -- just remove the above hack.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1498952946

From ihse at openjdk.org  Thu Feb 22 09:48:53 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 09:48:53 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <WgT5R65Kbubtx35Uyw2XAILZQZufGVOXOeS6oFk7tEk=.30c8ff36-82c7-4066-9a9e-ee3293f46810@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <g0ZVkeeR7P1e4_8Z0-nQ8at63jrtZySDk8bKtub0mLw=.db5e4e9c-9ca6-4d5a-b31b-17f84981e14f@github.com>
 <Cd8440seSvfWXHBcZ8cx5K1qWcpf-qyET1IdFY8eWUo=.a64a2d4c-bd34-49fb-9167-8e4583add959@github.com>
 <WgT5R65Kbubtx35Uyw2XAILZQZufGVOXOeS6oFk7tEk=.30c8ff36-82c7-4066-9a9e-ee3293f46810@github.com>
Message-ID: <5TGec4SbupSAMfO0HYHGPm5zoIRUTKq6OMNVFMJnA5Q=.f9ccc438-2a59-448d-8ee7-b146b9fc01c3@github.com>

On Thu, 22 Feb 2024 08:46:16 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> > The Graal folk will need to chime in here as it may be that these are needed for libgraal.
> 
> They should be fine. JNI linkage is only used by the native methods in `CompilerToVM.java`.

Once again, it is a misunderstanding that anything here changes. These functions will stay the same before and after this PR.

However, I interpret your comment as that it is possible to remove the JNIEXPORT from these functions in a follow-up PR. And that is good to know!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1959067420

From ihse at openjdk.org  Thu Feb 22 09:48:54 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 09:48:54 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <vXCbCZSVLYSkkeXQTOvMSxst4Yfi2ZaHikbUPhuTiME=.8995f473-11cd-4265-afa3-0e4376be88e8@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <vXCbCZSVLYSkkeXQTOvMSxst4Yfi2ZaHikbUPhuTiME=.8995f473-11cd-4265-afa3-0e4376be88e8@github.com>
Message-ID: <5TgE0AwpCtgs4yEzn8QcO4iH4M__Sn9w2sREKBMwmwo=.49a8a5e0-f5a1-49bc-8e61-dcaa89eb4c40@github.com>

On Thu, 22 Feb 2024 07:44:48 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
>> 
>> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
>> 
>> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
>> 
>> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.
>
> src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 74:
> 
>> 72: 
>> 73: #if defined(TARGET_COMPILER_gcc)
>> 74: #undef JNIEXPORT
> 
> Based on the suggestion in [this JBS comment](https://bugs.openjdk.org/browse/JDK-8017234?focusedId=14601421&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14601421), I think we can remove JNIEXPORT from all the functions in this file.
> 
> We need to keep the JNICALL though; the deprecated Win32 port needs it, not sure if it's used anywhere else.

I think so too. 

However, I would *really* like to do that separately as a follow up. My goal with this PR has been to make no changes in the product. Consider what would happen if we removed this, and there was some strange failure down the line. There is a high risk the entire PR would be backed out. 

If instead we remove the JNIEXPORT in a separate change, and this causes failures, then it is a much easier backout, and we would be much better informed at exactly what failed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1498956646

From jwaters at openjdk.org  Thu Feb 22 09:51:55 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Feb 2024 09:51:55 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <28TkIQvEbOiKscThXtUGZ24pcHI4wqrVgy6C2P6_f-4=.ae8dcc41-aedd-441c-a8ad-1526dd56db14@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <17uxknoRrcfnUlWwJndQk2AWqvZv4v34JZMVQPpl81w=.34a2c1a8-d251-4f8c-bd12-2f024b4914e6@github.com>
 <28TkIQvEbOiKscThXtUGZ24pcHI4wqrVgy6C2P6_f-4=.ae8dcc41-aedd-441c-a8ad-1526dd56db14@github.com>
Message-ID: <dQ9bYEF3EilMsNU0t8Zp_UCpnlIwGodiF2pYBVKGKdg=.b1878de3-593c-4e06-b4e0-f5beb41889b9@github.com>

On Thu, 22 Feb 2024 09:30:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/hotspot/lib/CompileJvm.gmk line 149:
>> 
>>> 147: 
>>> 148: ifeq ($(call isTargetOs, windows), true)
>>> 149:   WIN_EXPORT_FILE := $(JVM_OUTPUTDIR)/win-exports.txt
>> 
>> Why not .def?
>
> I try to stick to established file suffixes if possible. I have never heard of .def before, but maybe that is a standard name for these kinds of files on Windows? If so, I will change it.

The -def option is for accepting definition files, which are usually suffixed with .def. See for instance https://github.com/openjdk/jdk/blob/10eafdc62e8216e6ef69773fe491a21346c8682d/make/modules/jdk.accessibility/Lib.gmk#L80
.def file contents typically look like this:
https://github.com/openjdk/jdk/blob/master/src/jdk.accessibility/windows/native/libwindowsaccessbridge/WinAccessBridge.DEF

The Microsoft documentation for them is here: https://learn.microsoft.com/en-us/cpp/build/reference/module-definition-dot-def-files?view=msvc-170

If the contents of WinAccessBridge.def look similar enough to the Windows exports file that is created from the dumpbin object file process, feel free to rename it

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1498963562

From djelinski at openjdk.org  Thu Feb 22 09:51:56 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 22 Feb 2024 09:51:56 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <2wcpOdg70sjre1ULOsoeTKxu7Axq46zoU9qo_bkMgdM=.87d80995-09f3-417a-9270-56dd365d2b06@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <vXCbCZSVLYSkkeXQTOvMSxst4Yfi2ZaHikbUPhuTiME=.8995f473-11cd-4265-afa3-0e4376be88e8@github.com>
 <2wcpOdg70sjre1ULOsoeTKxu7Axq46zoU9qo_bkMgdM=.87d80995-09f3-417a-9270-56dd365d2b06@github.com>
Message-ID: <iD9Cps1c81g7BYImEu15xOQvY3Mq9IFZp5_iWU0pm0o=.abd92460-a728-48e3-a6d9-12d8a32b9e7d@github.com>

On Thu, 22 Feb 2024 09:41:45 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> src/hotspot/share/utilities/debug.cpp line 71:
>> 
>>> 69: 
>>> 70: #if defined(TARGET_COMPILER_gcc)
>>> 71: #undef JNIEXPORT
>> 
>> This partially reverts [JDK-8264593](https://bugs.openjdk.org/browse/JDK-8264593); @kevinjwalls will this work for you?
>
> No, it doesn't. Even after [JDK-8264593](https://bugs.openjdk.org/browse/JDK-8264593) the symbols from debug.cpp were not exported on Linux, since they were not mentioned in `make/data/hotspot-symbols`, and thus were made local.
> 
> The reason I put this in was to keep parity with the symbol table before and after the patch.
> 
> My guess is that it was only on Windows it was necessary that the functions where JNIEXPORTed, otherwise someone would have complained after JDK-8264593. But for platform consistency, it might make sense to export these even on gcc as well. After this PR is integrated, this is easy to do -- just remove the above hack.

they were absent from .dynsym but available in .symtab as bind: local, visibility: default. Now they are completely gone.

The symbols were supposed to be used from gdb. I'm not sure if gdb can access local symbols, so it's possible that they didn't work even before this change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1498964087

From ihse at openjdk.org  Thu Feb 22 09:57:54 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 09:57:54 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <qD5Ael_CjnuLVdZOdQ863VqU1KBJp1x7J1f3OPOJjcI=.fc651d8a-8640-405d-8339-bffc91b23050@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <qD5Ael_CjnuLVdZOdQ863VqU1KBJp1x7J1f3OPOJjcI=.fc651d8a-8640-405d-8339-bffc91b23050@github.com>
Message-ID: <7j108nQLaK4cLUE4ANl8gAsJby-Dg90ry1MH83Htkh0=.e7732c94-48e5-4e2b-ad08-90d3dba1bd82@github.com>

On Thu, 22 Feb 2024 00:29:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

> My main concern with a change like this as that it likely has little effect on the OpenJDK itself, but we may be changing something that 3rd party applications linking with libjvm are relying on. I realize this is a bit "hand wavy" but are we sure this presents the exact same view of libjvm as before?

I realize that my essay-style comment was a bit TL;DR, but I tried to answer questions like this ahead of time in it. Let me quote:

> I have checked the resulting libjvm.so/jvm.dll using the COMPARE_BUILD functionality, which (among other things) analyzes differences between native libraries before and after a patch. This has verified that there is no change in the symbols of the Hotspot dynamic library on macOS/x64, macOS/aarch64 or Windows/x64. I have also gotten help from @MBaesken and @JoKern65 to confirmed that there is no effect on AIX.

On linux/x64 and linux/aarch64 there are some very minor changes:

> The difference is that the data (variable) symbols __bss_start, _edata and _end, and the text (function) symbols _fini and _init has changed from local to global. Afaik, these are symbols created by the linker. Also, when we used a mapfile, the symbol SUNWprivate_1.1 that was part of the mapfile definition was included in libjvm.so, and this is no longer the case.

So yes, I have worked hard to make sure the resulting libjvm.so/jvm.dll is as close as humanly possible before and after this PR. I cannot think of a way in which 3rd party applications could even spot the difference before and after this patch. (Except for a contrived counterexample like explicitly looking up the visibility of `_init` and checking that it is indeed local...)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1959081384

From jwaters at openjdk.org  Thu Feb 22 09:57:55 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Feb 2024 09:57:55 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <28TkIQvEbOiKscThXtUGZ24pcHI4wqrVgy6C2P6_f-4=.ae8dcc41-aedd-441c-a8ad-1526dd56db14@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <17uxknoRrcfnUlWwJndQk2AWqvZv4v34JZMVQPpl81w=.34a2c1a8-d251-4f8c-bd12-2f024b4914e6@github.com>
 <28TkIQvEbOiKscThXtUGZ24pcHI4wqrVgy6C2P6_f-4=.ae8dcc41-aedd-441c-a8ad-1526dd56db14@github.com>
Message-ID: <FfaU4QcwSZnSxWSys6H3lqIO1UHBFKCb5dJ2tmNsR00=.6d492146-71d7-4530-bcdd-e0875bf02927@github.com>

On Thu, 22 Feb 2024 09:29:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> src/hotspot/share/oops/accessBackend.cpp line 36:
>> 
>>> 34: 
>>> 35: #if defined(TARGET_COMPILER_gcc)
>>> 36: #define HIDDEN __attribute__ ((visibility ("hidden")))
>> 
>> Couldn't this use [[gnu::visibility("hidden")]] instead, since HotSpot now allows C++14 Attributes? But this doesn't look like a very nice solution regardless
>
> We're currently using __attribute__ ((visibility ("X"))) elsewhere, so I think I should stick with that.
> 
> And, as I said in my long explanation, this is definitely a hack. The reason it is here is that I want to make sure the symbol table is 100% identical before and after this patch. 
> 
> Why this is needed, I don't know. I believe it is a bug in GCC, since we compile with -fvisibility=hidden. But I don't really know. Maybe there is something in the C++ standard that makes these functions behave differently. Perhaps they are even slightly incorrectly defined?

Ah, I should have clarified that I did read the explaination, just that it slipped my mind at the time. I can't remember if C++14 or C++17 is the version for compilers ignoring unknown attributes though

Also, you can escape the underscores with \ to avoid GitHub formatting. GitHub can get annoying with its formatting sometimes

Is there a chance this can be fixed in a followup somehow? I could help with that, given I have access to WSL2 for Linux

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1498972139

From ihse at openjdk.org  Thu Feb 22 10:02:54 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 10:02:54 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
Message-ID: <Fmx9r9fzQ4B-8Rho8HWl8QRY3KkP835i67amQFp6Kik=.caf9a9c5-5087-4817-b30e-4b06953b144b@github.com>

On Wed, 21 Feb 2024 23:32:15 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
> 
> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
> 
> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
> 
> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.

Let me also add some background to the *why* of this PR. 

A good reason is to get rid of a lot of weird code and special cases in the build. It will also speed up the build since we needed to scan all .o files with nm after they were compiled but before they were linked, adding to the slow path of linking hotspot. But for the 10+ years this has been a JBS issue it has never completely pushed the scales.

The triggering factor now is the Hermetic Java project. We need to make properly supported static libraries for all native code in the JDK. One of the main issues with creating a single static library from all the native code is symbol visibility. If the same symbol name is exported from two different libraries, this will cause a failure. This weird "dance" in Hotspot makes it much harder to reason about, or fix, issues related to symbol visibility. That is why I want to have this fixed, once and for all.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1959089592

From jwaters at openjdk.org  Thu Feb 22 10:02:54 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Feb 2024 10:02:54 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <iD9Cps1c81g7BYImEu15xOQvY3Mq9IFZp5_iWU0pm0o=.abd92460-a728-48e3-a6d9-12d8a32b9e7d@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <vXCbCZSVLYSkkeXQTOvMSxst4Yfi2ZaHikbUPhuTiME=.8995f473-11cd-4265-afa3-0e4376be88e8@github.com>
 <2wcpOdg70sjre1ULOsoeTKxu7Axq46zoU9qo_bkMgdM=.87d80995-09f3-417a-9270-56dd365d2b06@github.com>
 <iD9Cps1c81g7BYImEu15xOQvY3Mq9IFZp5_iWU0pm0o=.abd92460-a728-48e3-a6d9-12d8a32b9e7d@github.com>
Message-ID: <EhViMvCbwUI2HUVsMdUAgr3tB4S1luXqdrG8cNbwtlA=.7b8ddcb7-ea13-4955-9b83-76ed79f1adce@github.com>

On Thu, 22 Feb 2024 09:49:41 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> No, it doesn't. Even after [JDK-8264593](https://bugs.openjdk.org/browse/JDK-8264593) the symbols from debug.cpp were not exported on Linux, since they were not mentioned in `make/data/hotspot-symbols`, and thus were made local.
>> 
>> The reason I put this in was to keep parity with the symbol table before and after the patch.
>> 
>> My guess is that it was only on Windows it was necessary that the functions where JNIEXPORTed, otherwise someone would have complained after JDK-8264593. But for platform consistency, it might make sense to export these even on gcc as well. After this PR is integrated, this is easy to do -- just remove the above hack.
>
> they were absent from .dynsym but available in .symtab as bind: local, visibility: default. Now they are completely gone.
> 
> The symbols were supposed to be used from gdb. I'm not sure if gdb can access local symbols, so it's possible that they didn't work even before this change.

> But for platform consistency, it might make sense to export these even on gcc as well.

JDK-8288293 would definitely like that a lot

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1498978685

From ihse at openjdk.org  Thu Feb 22 10:20:54 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 10:20:54 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <FfaU4QcwSZnSxWSys6H3lqIO1UHBFKCb5dJ2tmNsR00=.6d492146-71d7-4530-bcdd-e0875bf02927@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <17uxknoRrcfnUlWwJndQk2AWqvZv4v34JZMVQPpl81w=.34a2c1a8-d251-4f8c-bd12-2f024b4914e6@github.com>
 <28TkIQvEbOiKscThXtUGZ24pcHI4wqrVgy6C2P6_f-4=.ae8dcc41-aedd-441c-a8ad-1526dd56db14@github.com>
 <FfaU4QcwSZnSxWSys6H3lqIO1UHBFKCb5dJ2tmNsR00=.6d492146-71d7-4530-bcdd-e0875bf02927@github.com>
Message-ID: <A1r4AEShJI_4GfYz3lxkxopCNYuaMF-zhmhuhd493gY=.c112b7c1-5d21-4074-8967-48b48387bd23@github.com>

On Thu, 22 Feb 2024 09:55:21 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> We're currently using __attribute__ ((visibility ("X"))) elsewhere, so I think I should stick with that.
>> 
>> And, as I said in my long explanation, this is definitely a hack. The reason it is here is that I want to make sure the symbol table is 100% identical before and after this patch. 
>> 
>> Why this is needed, I don't know. I believe it is a bug in GCC, since we compile with -fvisibility=hidden. But I don't really know. Maybe there is something in the C++ standard that makes these functions behave differently. Perhaps they are even slightly incorrectly defined?
>
> Ah, I should have clarified that I did read the explaination, just that it slipped my mind at the time. I can't remember if C++14 or C++17 is the version for compilers ignoring unknown attributes though
> 
> Also, you can escape the underscores with \ to avoid GitHub formatting. GitHub can get annoying with its formatting sometimes
> 
> Is there a chance this can be fixed in a followup somehow? I could help with that, given I have access to WSL2 for Linux

You mean making a search/replace from `__attribute__ ((foo))` to `[[gnu::foo)]]` in the code base? It seems a bit like unnecessary churn to me. We have 100+ places in the code with `__attribute__`. If you really want to try to push that agenda, be my guest. But do it in a separate PR. ;-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1499001259

From jwaters at openjdk.org  Thu Feb 22 10:20:54 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Feb 2024 10:20:54 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <A1r4AEShJI_4GfYz3lxkxopCNYuaMF-zhmhuhd493gY=.c112b7c1-5d21-4074-8967-48b48387bd23@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <17uxknoRrcfnUlWwJndQk2AWqvZv4v34JZMVQPpl81w=.34a2c1a8-d251-4f8c-bd12-2f024b4914e6@github.com>
 <28TkIQvEbOiKscThXtUGZ24pcHI4wqrVgy6C2P6_f-4=.ae8dcc41-aedd-441c-a8ad-1526dd56db14@github.com>
 <FfaU4QcwSZnSxWSys6H3lqIO1UHBFKCb5dJ2tmNsR00=.6d492146-71d7-4530-bcdd-e0875bf02927@github.com>
 <A1r4AEShJI_4GfYz3lxkxopCNYuaMF-zhmhuhd493gY=.c112b7c1-5d21-4074-8967-48b48387bd23@github.com>
Message-ID: <bCCiR8BHjfb_LNAuneO4lfRx1VY4UE8f1irt43V97vQ=.0010380e-f54d-439e-8877-5ba9a75fe71f@github.com>

On Thu, 22 Feb 2024 10:15:54 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Ah, I should have clarified that I did read the explaination, just that it slipped my mind at the time. I can't remember if C++14 or C++17 is the version for compilers ignoring unknown attributes though
>> 
>> Also, you can escape the underscores with \ to avoid GitHub formatting. GitHub can get annoying with its formatting sometimes
>> 
>> Is there a chance this can be fixed in a followup somehow? I could help with that, given I have access to WSL2 for Linux
>
> You mean making a search/replace from `__attribute__ ((foo))` to `[[gnu::foo)]]` in the code base? It seems a bit like unnecessary churn to me. We have 100+ places in the code with `__attribute__`. If you really want to try to push that agenda, be my guest. But do it in a separate PR. ;-)

Oh no, by fix I meant removing the HIDDEN attribute and somehow fixing that issue differently, not replacing everything with C++ Attributes!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1499004595

From ihse at openjdk.org  Thu Feb 22 10:27:06 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 10:27:06 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v2]
In-Reply-To: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
Message-ID: <12hoUFbZkWHBpiXs0TPiMYGW3sSvBX_536mvSSG-y-8=.21abcef9-9a2b-4558-ba19-dddfd7931f9f@github.com>

> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
> 
> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
> 
> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
> 
> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Rename the Windows export file to .def
 - Remove unused symbol _Copy_conjoint_bytes on linux/arm32

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17955/files
  - new: https://git.openjdk.org/jdk/pull/17955/files/04857e8e..27b4df53

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17955&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17955&range=00-01

  Stats: 4 lines in 2 files changed: 0 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17955.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17955/head:pull/17955

PR: https://git.openjdk.org/jdk/pull/17955

From ihse at openjdk.org  Thu Feb 22 10:37:54 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 10:37:54 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v2]
In-Reply-To: <z5hne_1-iA5I6aud_Z1pqiiQh7lkKs-lPIVHKn8r8DY=.cd39b73b-ed93-4000-9fe3-9480fd75af9e@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <vXCbCZSVLYSkkeXQTOvMSxst4Yfi2ZaHikbUPhuTiME=.8995f473-11cd-4265-afa3-0e4376be88e8@github.com>
 <z5hne_1-iA5I6aud_Z1pqiiQh7lkKs-lPIVHKn8r8DY=.cd39b73b-ed93-4000-9fe3-9480fd75af9e@github.com>
Message-ID: <g1RnggtuOtSZtr923djUJzeXYx53NZuZYJgOjqN36WM=.5eecdf1f-6d23-4e3e-9368-e1fe00fd2f98@github.com>

On Thu, 22 Feb 2024 09:37:38 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> > If the `SUNWprivate_1.1` part of the symbols is still needed, it can be added using `--default-symver` ld parameter.
> 
> Ah, good to know. In the spirit of making as minimal changes as possible in this PR, I will add it.

Unfortunately, that was not so easy. :( `--default-symver` is only available on the bfd ld, not on gold (which is what Oracle uses). :-(

https://sourceware.org/bugzilla/show_bug.cgi?id=15910

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1959157991

From kevinw at openjdk.org  Thu Feb 22 11:18:54 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 22 Feb 2024 11:18:54 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v2]
In-Reply-To: <EhViMvCbwUI2HUVsMdUAgr3tB4S1luXqdrG8cNbwtlA=.7b8ddcb7-ea13-4955-9b83-76ed79f1adce@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <vXCbCZSVLYSkkeXQTOvMSxst4Yfi2ZaHikbUPhuTiME=.8995f473-11cd-4265-afa3-0e4376be88e8@github.com>
 <2wcpOdg70sjre1ULOsoeTKxu7Axq46zoU9qo_bkMgdM=.87d80995-09f3-417a-9270-56dd365d2b06@github.com>
 <iD9Cps1c81g7BYImEu15xOQvY3Mq9IFZp5_iWU0pm0o=.abd92460-a728-48e3-a6d9-12d8a32b9e7d@github.com>
 <EhViMvCbwUI2HUVsMdUAgr3tB4S1luXqdrG8cNbwtlA=.7b8ddcb7-ea13-4955-9b83-76ed79f1adce@github.com>
Message-ID: <lIVvvltNqX9EzhzaitISyBocIyA3C4ZjJv83ldUnmeg=.a21613ca-ba82-4412-8040-2058fba56661@github.com>

On Thu, 22 Feb 2024 09:59:48 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> they were absent from .dynsym but available in .symtab as bind: local, visibility: default. Now they are completely gone.
>> 
>> The symbols were supposed to be used from gdb. I'm not sure if gdb can access local symbols, so it's possible that they didn't work even before this change.
>
>> But for platform consistency, it might make sense to export these even on gcc as well.
> 
> JDK-8288293 would definitely like that a lot

Thanks - when I last tried, e.g. "call universe()" would work on Linux/gdb, so I think gdb did resolve a local symbol (which cannot be found by callling dlsym, but can be found in the binary symboltable).
On Windows the debug.cpp symbols just weren't in the binary at all, then with JDK-8264593 JNIEXPORT they were, and appeared in the .map file we generate also.

So I am saying I added the JNIEXPORT for Windows, to get the debug.cpp symbols into the binary.
This removes JNIEXPORT for gcc, which already had the debug.cpp symbols in the binary.

But I will go check this...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1499086833

From sspitsyn at openjdk.org  Thu Feb 22 11:22:26 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 22 Feb 2024 11:22:26 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v14]
In-Reply-To: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
Message-ID: <zBdPDsd5vnzME2dvzjFFZsEUhF52cbTgjJJvuOk-DcE=.e6d423fc-e8a0-49ac-8ed2-00c945190732@github.com>

> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
> The function returns the following structure:
> 
> 
> typedef struct {
>     jthread owner;
>     jint entry_count;
>     jint waiter_count;
>     jthread* waiters;
>     jint notify_waiter_count;
>     jthread* notify_waiters;
> } jvmtiMonitorUsage;
> 
> 
> The following four fields are defined this way:
> 
> waiter_count  [jint] The number of threads waiting to own this monitor
> waiters  [jthread*] The waiter_count waiting threads
> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
> 
> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
> This update makes it right.
> 
> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
> 
> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
> 
>   jvmti/GetObjectMonitorUsage/objmonusage001
>   jvmti/GetObjectMonitorUsage/objmonusage003
> 
> 
> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
> 
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
> 
> 
> 
> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository.
> 
> Also, please see and review the related CSR:
>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
> 
> The Release-Note is:
> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage
>  
> Testing:
>  - tested with mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: remove test objmonusage003; improve test ObjectMonitorUsage

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17680/files
  - new: https://git.openjdk.org/jdk/pull/17680/files/e095cffe..ef779169

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=12-13

  Stats: 1353 lines in 9 files changed: 454 ins; 899 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17680.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17680/head:pull/17680

PR: https://git.openjdk.org/jdk/pull/17680

From sspitsyn at openjdk.org  Thu Feb 22 11:29:57 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 22 Feb 2024 11:29:57 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v14]
In-Reply-To: <zBdPDsd5vnzME2dvzjFFZsEUhF52cbTgjJJvuOk-DcE=.e6d423fc-e8a0-49ac-8ed2-00c945190732@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <zBdPDsd5vnzME2dvzjFFZsEUhF52cbTgjJJvuOk-DcE=.e6d423fc-e8a0-49ac-8ed2-00c945190732@github.com>
Message-ID: <sj4Aiq2KuQA0oUIDme3JAgrTf8LVAGHzMtNjP3GCfU0=.7e0279a0-e7c5-47bf-8df5-25e5abe6f2ac@github.com>

On Thu, 22 Feb 2024 11:22:26 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
>> The function returns the following structure:
>> 
>> 
>> typedef struct {
>>     jthread owner;
>>     jint entry_count;
>>     jint waiter_count;
>>     jthread* waiters;
>>     jint notify_waiter_count;
>>     jthread* notify_waiters;
>> } jvmtiMonitorUsage;
>> 
>> 
>> The following four fields are defined this way:
>> 
>> waiter_count  [jint] The number of threads waiting to own this monitor
>> waiters  [jthread*] The waiter_count waiting threads
>> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
>> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
>> 
>> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
>> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
>> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
>> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
>> This update makes it right.
>> 
>> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
>> 
>> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
>> 
>>   jvmti/GetObjectMonitorUsage/objmonusage001
>>   jvmti/GetObjectMonitorUsage/objmonusage003
>> 
>> 
>> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
>> 
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
>> 
>> 
>> 
>> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository.
>> 
>> Also, please see and review the related CSR:
>>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
>> 
>> The Release-Note is:
>> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage
>>  
>> Testing:
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: remove test objmonusage003; improve test ObjectMonitorUsage

I've pushed an update which addresses test related review comments from Leonid and adds some test improvements:
 - remove the `nsk/jvmti` test `objmonusage003` which was converted into ObjectMonitorUsage
 - rename the test folder from `GetObjectMonitorUsage` to `ObjectMonitorUsage` for naming unification
 - add one more testing scenario: `test0`
 - add test specific thread names
 - address several minor review comments from Leonid
 - add better organized log messages

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17680#issuecomment-1959255417

From rkennke at openjdk.org  Thu Feb 22 11:49:34 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 22 Feb 2024 11:49:34 GMT
Subject: RFR: 8139457: Relax alignment of array elements [v66]
In-Reply-To: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
References: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
Message-ID: <W7DKn34NGJmUM24YBYfC6WpsT9sxuq14tYMLEbVFiYk=.14e54bfd-7edc-4014-b66c-6d5c058c7c73@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:

  Move shim into initialize_header()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11044/files
  - new: https://git.openjdk.org/jdk/pull/11044/files/eb303719..f2f02bdd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=65
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=64-65

  Stats: 24 lines in 1 file changed: 11 ins; 13 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11044.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/11044/head:pull/11044

PR: https://git.openjdk.org/jdk/pull/11044

From rkennke at openjdk.org  Thu Feb 22 11:49:37 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 22 Feb 2024 11:49:37 GMT
Subject: RFR: 8139457: Relax alignment of array elements [v59]
In-Reply-To: <Si8YRjDz512url5FI49fSrOWoKaKXe4P4s-QU1WXeHk=.d8ab409e-2ec4-4641-9347-59957e31a5c0@github.com>
References: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
 <vrF2sgN9cbZJR44AjuJ-1wREeCuoooK_WMJEiAaFmpY=.84de9b0a-519f-4c08-93f3-d7de7a89da25@github.com>
 <Si8YRjDz512url5FI49fSrOWoKaKXe4P4s-QU1WXeHk=.d8ab409e-2ec4-4641-9347-59957e31a5c0@github.com>
Message-ID: <GSNv6p4DjGi_fc_kYIxDMc6-M7Gyy9xnDu1fDJrzDdw=.a07118a2-74cb-49e0-9bee-506354bac51c@github.com>

On Mon, 25 Sep 2023 13:23:48 GMT, Albert Mingkun Yang <ayang 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 88 commits:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into JDK-8139457
>>  - Various cleanups
>>  - RISC changes
>>  - Move gap init into allocate_header() (x86)
>>  - Fix gtest failure on x86
>>  - Merge remote-tracking branch 'upstream/master' into JDK-8139457
>>  - Fix comments
>>  - Fix inconsistencies in argument naming C1_MacroAssembler::allocate_array()
>>  - Fix call to arrayOopDesc::header_size() in arm port
>>  - Fix wrong alignment
>>  - ... and 78 more: https://git.openjdk.org/jdk/compare/0f0c5b2d...8617a596
>
> Much of my confusion is caused by the unclear definition of 'header/body' ? specifically, whether the alignment gap is included as part of the header. It's a preexisting issue for instance objs, though.
> 
> Since some parts of this will be fixed in upcoming PRs, as indicated by `// TODO: This could perhaps go into initialize_body()...`, I believe it can be merged to move this forward.
> 
> A comprehensive explanation of the memory representation of instances and arrays, including the mark word, klass-pointer, optional alignment gap, and possible squeezed-into fields, would be greatly appreciated in future PRs in this area. That would help clarify the boundary between the header and body.

> I know @albertnetymk already touched on this but some thoughts on the unclear boundaries between the header and the data. My feeling is that the most pragmatic solution would be to have the header initialization always initialize up to the word aligned (up) `header_size_in_bytes`. (Similarly to how it is done for the `instanceOop` where the klass gap gets initialized with the header, even if it may be data.) And have the body initialization do the rest (word aligned to word aligned clear).

Like what I did for x86 in latest commit? If you agree that should be the way to go, then I'll do the same for aarch64.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/11044#issuecomment-1959283824

From dnsimon at openjdk.org  Thu Feb 22 11:59:54 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 22 Feb 2024 11:59:54 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <5TGec4SbupSAMfO0HYHGPm5zoIRUTKq6OMNVFMJnA5Q=.f9ccc438-2a59-448d-8ee7-b146b9fc01c3@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <g0ZVkeeR7P1e4_8Z0-nQ8at63jrtZySDk8bKtub0mLw=.db5e4e9c-9ca6-4d5a-b31b-17f84981e14f@github.com>
 <Cd8440seSvfWXHBcZ8cx5K1qWcpf-qyET1IdFY8eWUo=.a64a2d4c-bd34-49fb-9167-8e4583add959@github.com>
 <WgT5R65Kbubtx35Uyw2XAILZQZufGVOXOeS6oFk7tEk=.30c8ff36-82c7-4066-9a9e-ee3293f46810@github.com>
 <5TGec4SbupSAMfO0HYHGPm5zoIRUTKq6OMNVFMJnA5Q=.f9ccc438-2a59-448d-8ee7-b146b9fc01c3@github.com>
Message-ID: <bjUm6YFU-0Z9wxg8EM7CWtHsP4yNp4VSYjmIcTjJQjw=.fa383933-82bf-44d6-815a-916698a2b804@github.com>

On Thu, 22 Feb 2024 09:46:00 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> However, I interpret your comment as that it is possible to remove the JNIEXPORT from these functions in a follow-up PR. And that is good to know!

I believe you're right. In any case, most of the JVMCI tests will fail if JNIEXPORT is removed and it turns out to be needed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1959300756

From jesper.wilhelmsson at oracle.com  Thu Feb 22 12:14:16 2024
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Thu, 22 Feb 2024 12:14:16 +0000
Subject: =?utf-8?B?Q0ZWOiBOZXcgSG90U3BvdCBHcm91cCBNZW1iZXI6IEpvaGFuIFNqw7Zsw6lu?=
Message-ID: <041D6781-CFE6-41BD-A8F5-7E25C2EFFD52@oracle.com>

I hereby nominate Johan Sj?l?n (jsjolen) to Membership in the HotSpot Group.

Johan is a Reviewer in the JDK project, and a member of the Oracle JVM Runtime team. Johan has done major work in the Unified Logging framework and is today the de facto owner of that area. He has done major cleanups and bug fixes throughout the JVM, and does a lot of work in the Native Memory Tracking area.

Votes are due by Thursday March 7.

Only current Members of the HotSpot Group [1] are eligible to vote on this nomination.  Votes must be cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [2].

Thanks,
/Jesper

[1] https://openjdk.org/census
[2] https://openjdk.org/groups/#member-vote
-------------- 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/20240222/b9cff860/signature.asc>

From ihse at openjdk.org  Thu Feb 22 12:26:53 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 12:26:53 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v2]
In-Reply-To: <lIVvvltNqX9EzhzaitISyBocIyA3C4ZjJv83ldUnmeg=.a21613ca-ba82-4412-8040-2058fba56661@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <vXCbCZSVLYSkkeXQTOvMSxst4Yfi2ZaHikbUPhuTiME=.8995f473-11cd-4265-afa3-0e4376be88e8@github.com>
 <2wcpOdg70sjre1ULOsoeTKxu7Axq46zoU9qo_bkMgdM=.87d80995-09f3-417a-9270-56dd365d2b06@github.com>
 <iD9Cps1c81g7BYImEu15xOQvY3Mq9IFZp5_iWU0pm0o=.abd92460-a728-48e3-a6d9-12d8a32b9e7d@github.com>
 <EhViMvCbwUI2HUVsMdUAgr3tB4S1luXqdrG8cNbwtlA=.7b8ddcb7-ea13-4955-9b83-76ed79f1adce@github.com>
 <lIVvvltNqX9EzhzaitISyBocIyA3C4ZjJv83ldUnmeg=.a21613ca-ba82-4412-8040-2058fba56661@github.com>
Message-ID: <E9y5WFeGqqskboveKh7YamHgbz6Ur5QdJji2uOxzt6c=.4aad38fd-6a31-4881-a2b8-b145d22a6763@github.com>

On Thu, 22 Feb 2024 11:16:37 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>>> But for platform consistency, it might make sense to export these even on gcc as well.
>> 
>> JDK-8288293 would definitely like that a lot
>
> Thanks - when I last tried, e.g. "call universe()" would work on Linux/gdb, so I think gdb did resolve a local symbol (which cannot be found by callling dlsym, but can be found in the binary symboltable).
> On Windows the debug.cpp symbols just weren't in the binary at all, then with JDK-8264593 JNIEXPORT they were, and appeared in the .map file we generate also.
> 
> So I am saying I added the JNIEXPORT for Windows, to get the debug.cpp symbols into the binary.
> This removes JNIEXPORT for gcc, which already had the debug.cpp symbols in the binary.
> 
> But I will go check this...

> they were absent from .dynsym but available in .symtab as bind: local, visibility: default. Now they are completely gone.

I don't think that statement is correct. Or else my understanding about symbol tables is incomplete. Both `nm` (which shows `.symtab`) and `nm -D` (which shows `.dynsym`) are identical for the libjvm.so before and after the patch wrt to the JNIEXPORTed debug.cpp functions.

Was this a statement of your understanding of the situation, or could you spot an actual difference? If it is the latter, please let me know how I can view this difference.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1499163789

From ihse at openjdk.org  Thu Feb 22 12:29:54 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 12:29:54 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v2]
In-Reply-To: <E9y5WFeGqqskboveKh7YamHgbz6Ur5QdJji2uOxzt6c=.4aad38fd-6a31-4881-a2b8-b145d22a6763@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <vXCbCZSVLYSkkeXQTOvMSxst4Yfi2ZaHikbUPhuTiME=.8995f473-11cd-4265-afa3-0e4376be88e8@github.com>
 <2wcpOdg70sjre1ULOsoeTKxu7Axq46zoU9qo_bkMgdM=.87d80995-09f3-417a-9270-56dd365d2b06@github.com>
 <iD9Cps1c81g7BYImEu15xOQvY3Mq9IFZp5_iWU0pm0o=.abd92460-a728-48e3-a6d9-12d8a32b9e7d@github.com>
 <EhViMvCbwUI2HUVsMdUAgr3tB4S1luXqdrG8cNbwtlA=.7b8ddcb7-ea13-4955-9b83-76ed79f1adce@github.com>
 <lIVvvltNqX9EzhzaitISyBocIyA3C4ZjJv83ldUnmeg=.a21613ca-ba82-4412-8040-2058fba56661@github.com>
 <E9y5WFeGqqskboveKh7YamHgbz6Ur5QdJji2uOxzt6c=.4aad38fd-6a31-4881-a2b8-b145d22a6763@github.com>
Message-ID: <Wo15zScdWr27VO2St0-ExVqddH1wWLdS2cnRF6Yq1wE=.505b59eb-9942-4b85-901d-97715025c078@github.com>

On Thu, 22 Feb 2024 12:24:09 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Thanks - when I last tried, e.g. "call universe()" would work on Linux/gdb, so I think gdb did resolve a local symbol (which cannot be found by callling dlsym, but can be found in the binary symboltable).
>> On Windows the debug.cpp symbols just weren't in the binary at all, then with JDK-8264593 JNIEXPORT they were, and appeared in the .map file we generate also.
>> 
>> So I am saying I added the JNIEXPORT for Windows, to get the debug.cpp symbols into the binary.
>> This removes JNIEXPORT for gcc, which already had the debug.cpp symbols in the binary.
>> 
>> But I will go check this...
>
>> they were absent from .dynsym but available in .symtab as bind: local, visibility: default. Now they are completely gone.
> 
> I don't think that statement is correct. Or else my understanding about symbol tables is incomplete. Both `nm` (which shows `.symtab`) and `nm -D` (which shows `.dynsym`) are identical for the libjvm.so before and after the patch wrt to the JNIEXPORTed debug.cpp functions.
> 
> Was this a statement of your understanding of the situation, or could you spot an actual difference? If it is the latter, please let me know how I can view this difference.

Your comment had me go and elfdump the entire libjvm.so and compare the entire output... :-) Now at least I understand why there were so many spurious changes in the linux binary -- the old symbols were named e.g. `JVM_MonitorWait@@SUNWprivate_1.1` while the new one are just named `JVM_MonitorWait`. This caused the segment to be shorter, and this in turned offsetted all following position, so the change cascaded down.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1499167151

From stefank at openjdk.org  Thu Feb 22 12:49:06 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 22 Feb 2024 12:49:06 GMT
Subject: RFR: 8139457: Relax alignment of array elements [v66]
In-Reply-To: <W7DKn34NGJmUM24YBYfC6WpsT9sxuq14tYMLEbVFiYk=.14e54bfd-7edc-4014-b66c-6d5c058c7c73@github.com>
References: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
 <W7DKn34NGJmUM24YBYfC6WpsT9sxuq14tYMLEbVFiYk=.14e54bfd-7edc-4014-b66c-6d5c058c7c73@github.com>
Message-ID: <7ccOXGrJ3wRj5X39Ici1Wd-3l5LoMzxTMuWirgJbp5o=.42b75f65-f8eb-49a5-a16e-9c807e1f3b79@github.com>

On Thu, 22 Feb 2024 11:49:34 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details.
>> 
>> Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements.
>> 
>> Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16.
>> 
>> Testing:
>>  - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390)
>>  - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390)
>>  - [x] tier1 (x86_64, x86_32, aarch64, riscv)
>>  - [x] tier2 (x86_64, aarch64, riscv)
>>  - [x] tier3 (x86_64, riscv)
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move shim into initialize_header()

src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp line 195:

> 193:       xorl(t1, t1);
> 194:       movl(Address(obj, arrayOopDesc::length_offset_in_bytes() + BytesPerInt), t1);
> 195:     }

There's two `arrayOopDesc::length_offset_in_bytes() + BytesPerInt` calculations in this block. Wouldn't it be better to use `base_offset` instead of the second calculation?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/11044#discussion_r1499189308

From rkennke at openjdk.org  Thu Feb 22 12:56:23 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 22 Feb 2024 12:56:23 GMT
Subject: RFR: 8139457: Relax alignment of array elements [v67]
In-Reply-To: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
References: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
Message-ID: <sSQJoLZ6SEqksgt1WPlcUE5BdyaT6X49SOcLgS_FZJw=.cbe9d19c-0b35-45d9-9f60-770e433ba044@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:

  Reuse base_offset

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11044/files
  - new: https://git.openjdk.org/jdk/pull/11044/files/f2f02bdd..8572f848

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=66
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=65-66

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11044.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/11044/head:pull/11044

PR: https://git.openjdk.org/jdk/pull/11044

From coleen.phillimore at oracle.com  Thu Feb 22 13:02:37 2024
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Thu, 22 Feb 2024 08:02:37 -0500
Subject: =?UTF-8?Q?Re=3A_CFV=3A_New_HotSpot_Group_Member=3A_Johan_Sj=C3=B6l?=
 =?UTF-8?B?w6lu?=
In-Reply-To: <041D6781-CFE6-41BD-A8F5-7E25C2EFFD52@oracle.com>
References: <041D6781-CFE6-41BD-A8F5-7E25C2EFFD52@oracle.com>
Message-ID: <8fa9335d-0217-4a02-a063-92f739b4b332@oracle.com>

Vote: yes

On 2/22/24 7:14 AM, Jesper Wilhelmsson wrote:
> I hereby nominate Johan Sj?l?n (jsjolen) to Membership in the HotSpot Group.
>
> Johan is a Reviewer in the JDK project, and a member of the Oracle JVM Runtime team. Johan has done major work in the Unified Logging framework and is today the de facto owner of that area. He has done major cleanups and bug fixes throughout the JVM, and does a lot of work in the Native Memory Tracking area.
>
> Votes are due by Thursday March 7.
>
> Only current Members of the HotSpot Group [1] are eligible to vote on this nomination.  Votes must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [2].
>
> Thanks,
> /Jesper
>
> [1] https://openjdk.org/census
> [2] https://openjdk.org/groups/#member-vote


From thomas.stuefe at gmail.com  Thu Feb 22 13:04:58 2024
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 22 Feb 2024 14:04:58 +0100
Subject: =?UTF-8?Q?Re=3A_CFV=3A_New_HotSpot_Group_Member=3A_Johan_Sj=C3=B6l=C3=A9n?=
In-Reply-To: <041D6781-CFE6-41BD-A8F5-7E25C2EFFD52@oracle.com>
References: <041D6781-CFE6-41BD-A8F5-7E25C2EFFD52@oracle.com>
Message-ID: <CAA-vtUynCALNJBE=KVsPGxQfDkdT_ddZjf8G=yq_Qjwzg2R_+g@mail.gmail.com>

Vote: yes

On Thu 22. Feb 2024 at 13:14, Jesper Wilhelmsson <
jesper.wilhelmsson at oracle.com> wrote:

> I hereby nominate Johan Sj?l?n (jsjolen) to Membership in the HotSpot
> Group.
>
> Johan is a Reviewer in the JDK project, and a member of the Oracle JVM
> Runtime team. Johan has done major work in the Unified Logging framework
> and is today the de facto owner of that area. He has done major cleanups
> and bug fixes throughout the JVM, and does a lot of work in the Native
> Memory Tracking area.
>
> Votes are due by Thursday March 7.
>
> Only current Members of the HotSpot Group [1] are eligible to vote on this
> nomination.  Votes must be cast in the open by replying to this mailing
> list.
>
> For Lazy Consensus voting instructions, see [2].
>
> Thanks,
> /Jesper
>
> [1] https://openjdk.org/census
> [2] https://openjdk.org/groups/#member-vote
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20240222/eb8d34b7/attachment-0001.htm>

From rkennke at openjdk.org  Thu Feb 22 13:05:21 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 22 Feb 2024 13:05:21 GMT
Subject: RFR: 8139457: Relax alignment of array elements [v68]
In-Reply-To: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
References: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
Message-ID: <c7Ao52lFl74Z4lgXCyKbHjkWTBHEseHS7hlv_rEU9N4=.de5e6b38-abdd-45b8-968a-5e8467f950a9@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:

  Move shim into initialize_header() (aarch64)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11044/files
  - new: https://git.openjdk.org/jdk/pull/11044/files/8572f848..e8c1e408

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=67
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=66-67

  Stats: 18 lines in 2 files changed: 7 ins; 8 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/11044.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/11044/head:pull/11044

PR: https://git.openjdk.org/jdk/pull/11044

From fbredberg at openjdk.org  Thu Feb 22 13:10:05 2024
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 22 Feb 2024 13:10:05 GMT
Subject: Integrated: 8325153: SEGV in
 stackChunkOopDesc::derelativize_address(int)
In-Reply-To: <qc0gmrEb_xZ8mtY1wIa0odNvUOkZL1GmjfLD25px9uY=.fd3a5704-a89c-46fb-bb16-7d988c8fc435@github.com>
References: <qc0gmrEb_xZ8mtY1wIa0odNvUOkZL1GmjfLD25px9uY=.fd3a5704-a89c-46fb-bb16-7d988c8fc435@github.com>
Message-ID: <LRvv6MRp9CERnDiOoda6IvinpeWUn-R-GXtbd6Ti4p4=.e8b88ed8-38b2-4529-9f4d-e24620bf105e@github.com>

On Wed, 21 Feb 2024 09:21:11 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> The JVM used to SEGV when running jdk/internal/vm/Continuation/Fuzz.java with '-Xlog:all=trace:file=hotspot.%p.log'
> 
> The problem was this line in StackWalk::fetchNextBatch() at src/hotspot/share/prims/stackwalk.cpp:547:
> 
> log_debug(stackwalk)("advanced past %s", stream.method()->external_name());
> 
> It is not always safe to dig out the name of the last frame here. The second batch is allocated on top of the first batch, so there is no crash when we dig out the last name from the first batch. However the third batch, is allocated on the same stack level as the second, which means that the second batch has been reclaimed. Thus trying to reach into the second batch when processing the third will cause a segmentation violation.
> 
> Now passes:
> jdk/internal/vm/Continuation/Fuzz.java with '-Xlog:all=trace:file=hotspot.%p.log'
> As well as tier1-tier5

This pull request has now been integrated.

Changeset: f365d807
Author:    Fredrik Bredberg <fbredberg at openjdk.org>
Committer: Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f365d807e5552a6ad9a36afd82db8f0881d62cc3
Stats:     6 lines in 1 file changed: 4 ins; 0 del; 2 mod

8325153: SEGV in stackChunkOopDesc::derelativize_address(int)

Reviewed-by: stefank, coleenp

-------------

PR: https://git.openjdk.org/jdk/pull/17942

From rkennke at openjdk.org  Thu Feb 22 13:10:11 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 22 Feb 2024 13:10:11 GMT
Subject: RFR: 8139457: Relax alignment of array elements [v66]
In-Reply-To: <7ccOXGrJ3wRj5X39Ici1Wd-3l5LoMzxTMuWirgJbp5o=.42b75f65-f8eb-49a5-a16e-9c807e1f3b79@github.com>
References: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
 <W7DKn34NGJmUM24YBYfC6WpsT9sxuq14tYMLEbVFiYk=.14e54bfd-7edc-4014-b66c-6d5c058c7c73@github.com>
 <7ccOXGrJ3wRj5X39Ici1Wd-3l5LoMzxTMuWirgJbp5o=.42b75f65-f8eb-49a5-a16e-9c807e1f3b79@github.com>
Message-ID: <GY91AlGICj7XPNpemSdbp7BjJU8GrRVBVorjV91Kbfs=.e1d51872-9285-4a88-838c-accf1ab9c565@github.com>

On Thu, 22 Feb 2024 12:46:15 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move shim into initialize_header()
>
> src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp line 195:
> 
>> 193:       xorl(t1, t1);
>> 194:       movl(Address(obj, arrayOopDesc::length_offset_in_bytes() + BytesPerInt), t1);
>> 195:     }
> 
> There's two `arrayOopDesc::length_offset_in_bytes() + BytesPerInt` calculations in this block. Wouldn't it be better to use `base_offset` instead of the second calculation?

Right. Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/11044#discussion_r1499215319

From rkennke at openjdk.org  Thu Feb 22 13:19:04 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 22 Feb 2024 13:19:04 GMT
Subject: RFR: 8139457: Relax alignment of array elements [v65]
In-Reply-To: <pNHNOr21oYN8aqgBkSj3L3JofLs5COreCfKpy6YcxPc=.65763aa5-3c00-4337-a703-0d8e863b2e4b@github.com>
References: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
 <474Cp5qDgHyppRBgkl1OHixEpCacSZfZoQrzuHRowAg=.f5a7cfa2-c300-4e07-b594-34d6351eafb4@github.com>
 <pNHNOr21oYN8aqgBkSj3L3JofLs5COreCfKpy6YcxPc=.65763aa5-3c00-4337-a703-0d8e863b2e4b@github.com>
Message-ID: <KrqMxXdMpVpGFomVbily-yJOoOqa4_fKx8xs74FQEeQ=.a8c56b3b-e2ba-40ce-8183-ec7865d20cad@github.com>

On Wed, 21 Feb 2024 20:15:55 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> These changes look correct. Tried to look around the code for indirect assumptions surrounding the `klass_offset` and the `length_offset` w.r.t. the `base_offset`. It seem to work out. (But some of this implicit assumptions might want to be cleaned up in the future.)
> 
> I only looked at changes since my last comments, seems like my nits from then have been fixed.
> 
> There are preexisting issues with regards to naming (and their meaning) which this change exacerbates.
> 
> I do not believe this should be a blocker (done in future RFEs). However the more code movement there is with regards to this, the more I feel this needs to be overhauled. (Lilliput shakes this up even more.)

Yes, there is still much to do. I just don't want to overload this PR with clutter.

> I know @albertnetymk already touched on this but some thoughts on the unclear boundaries between the header and the data. My feeling is that the most pragmatic solution would be to have the header initialization always initialize up to the word aligned (up) `header_size_in_bytes`. (Similarly to how it is done for the `instanceOop` where the klass gap gets initialized with the header, even if it may be data.) And have the body initialization do the rest (word aligned to word aligned clear).
> 
> This seems preferable than adding these extra alignment shims in-between the header and body/payload/data initialization. (I also tried moving the alignment fix into the body initialization, but it seems a little bit messier in the implementation.)

This seems indeed the most pragmatic way to deal with it. In the (very) long run, I hope we can settle on a single fixed object layout (e.g. 4-byte header, 4-byte length, then payload for arrays and 4-byte headers, then payload for objects), until then we need to live with the shims. Aligning initialization on word-boundaries makes sense, though.

> Maybe something similar for copying and cloning.

Ugh, yes. But not in this PR ;-)

> Some things that I think we should always try and strive for is when introducing new code (that talks about heap memory sizes/offsets):
> 
> * Any named property/variable ending in `_size_in_bytes`/`_offset_in_bytes` is not required to be word aligned.
> * Any named property/variable ending in just `_size`/`_offset` must be in words. And their name should not lie. i.e. `aligned_header_size = align_up(header_size_in_bytes(),HeapWordSize) / HeapWordSize;` instead of `header_size = align_up(header_size_in_bytes(),HeapWordSize) / HeapWordSize;` unless `header_size * HeapWordSize == header_size_in_bytes()` is invariant.
>   Again a pragmatic choice, as it seems to be the predominant choice in hotspot.
>   An absolutely wonderful change would be to add (and use/enforce) typed size_t enum classes for `ByteSize` and `WordSize`. (We already have these in the code base but they use 32-bit int and only `ByteSize` sees any use). The idea is then that you can just use `_size`/`_offset` suffixes with the correct types.

Agree with all of that.
 
> Some thoughts on future naming

Agree on that, too.

Also, another thing that should be cleaned-up/gotten right is arrayOopDesc::max_array_length() (use sane return type, not int32_t, fix maximum lengths to be less pessimistic, esp on 32bit platforms). But not here, and perhaps not until we're done with the various planned layout changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/11044#issuecomment-1959435914

From sspitsyn at openjdk.org  Thu Feb 22 13:24:56 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 22 Feb 2024 13:24:56 GMT
Subject: RFR: JDK-8325530: Vague error message when
 com.sun.tools.attach.VirtualMachine fails to load agent library [v2]
In-Reply-To: <yAR3Q8ArdoO4KivB9gu_SenT7P3tEccuZrEjvwAAF_M=.c8a0fe1b-9c7d-4de9-8288-b0c684ab0ccc@github.com>
References: <s1rZKr_Bt8tzCP2cMyFv0oe7pTD1DNzGLaIsGZdXffY=.596d50f2-12b6-4bba-ab30-a26b697fb970@github.com>
 <yAR3Q8ArdoO4KivB9gu_SenT7P3tEccuZrEjvwAAF_M=.c8a0fe1b-9c7d-4de9-8288-b0c684ab0ccc@github.com>
Message-ID: <H2tqimDMCSjPdW6JbbWsqgdU5zx-F1PK0QJ-pbagZm4=.8f2ac3ad-0a5d-43a1-849e-73f1a474b548@github.com>

On Wed, 21 Feb 2024 21:42:08 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> VirtualMachine.loadAgentPath/loadAgentLibrary can fail with AgentLoadException in 2 cases:
>> - attach listener returns error; in the case the exception is thrown from HotSpotVirtualMachine.processCompletionStatus (called from HotSpotVirtualMachine.execute);
>> - attach listener returns success, but reply does not contain Agent_onAttach return code ("return code: %d" message).
>> 
>> before jdk21 if attach listener fails to load required library, it returned error (case 1)
>> from jdk21 attach listener always returns success (case 2)
>> Both cases are ok, but for 2nd case HotSpotVirtualMachine.loadAgentLibrary read only single line of the response message, so exception message didn't contain error details.
>> 
>> The fix updates HotSpotVirtualMachine.loadAgentLibrary to read the whole response message.
>> Walking through the code, fixed some other minor things in attach listener and attach API implementation (commented in the code)
>> 
>> Testing:
>>   - test/jdk/com/sun/tools;
>>   - tier1,tier2,tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   uncaught error

src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java line 113:

> 111:                 }
> 112:             } else {
> 113:                 String msg = "Failed to load agent library";

Nit: The line 113 can be moved above the line 99, so the `msg` could be also used at line 122 instead of a literal use of the string.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17954#discussion_r1499234830

From ihse at openjdk.org  Thu Feb 22 13:30:55 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 13:30:55 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v2]
In-Reply-To: <Wo15zScdWr27VO2St0-ExVqddH1wWLdS2cnRF6Yq1wE=.505b59eb-9942-4b85-901d-97715025c078@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <vXCbCZSVLYSkkeXQTOvMSxst4Yfi2ZaHikbUPhuTiME=.8995f473-11cd-4265-afa3-0e4376be88e8@github.com>
 <2wcpOdg70sjre1ULOsoeTKxu7Axq46zoU9qo_bkMgdM=.87d80995-09f3-417a-9270-56dd365d2b06@github.com>
 <iD9Cps1c81g7BYImEu15xOQvY3Mq9IFZp5_iWU0pm0o=.abd92460-a728-48e3-a6d9-12d8a32b9e7d@github.com>
 <EhViMvCbwUI2HUVsMdUAgr3tB4S1luXqdrG8cNbwtlA=.7b8ddcb7-ea13-4955-9b83-76ed79f1adce@github.com>
 <lIVvvltNqX9EzhzaitISyBocIyA3C4ZjJv83ldUnmeg=.a21613ca-ba82-4412-8040-2058fba56661@github.com>
 <E9y5WFeGqqskboveKh7YamHgbz6Ur5QdJji2uOxzt6c=.4aad38fd-6a31-4881-a2b8-b145d22a6763@github.com>
 <Wo15zScdWr27VO2St0-ExVqddH1wWLdS2cnRF6Yq1wE=.505b59eb-9942-4b85-901d-97715025c078@github.com>
Message-ID: <Y9p2b3b_z8muEidBlBBrpCwLumHrKejUvxfzqZxnBjo=.a9119066-f460-4ec0-aa58-c8d78c721f6f@github.com>

On Thu, 22 Feb 2024 12:27:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>>> they were absent from .dynsym but available in .symtab as bind: local, visibility: default. Now they are completely gone.
>> 
>> I don't think that statement is correct. Or else my understanding about symbol tables is incomplete. Both `nm` (which shows `.symtab`) and `nm -D` (which shows `.dynsym`) are identical for the libjvm.so before and after the patch wrt to the JNIEXPORTed debug.cpp functions.
>> 
>> Was this a statement of your understanding of the situation, or could you spot an actual difference? If it is the latter, please let me know how I can view this difference.
>
> Your comment had me go and elfdump the entire libjvm.so and compare the entire output... :-) Now at least I understand why there were so many spurious changes in the linux binary -- the old symbols were named e.g. `JVM_MonitorWait@@SUNWprivate_1.1` while the new one are just named `JVM_MonitorWait`. This caused the segment to be shorter, and this in turned offsetted all following position, so the change cascaded down.

Ok, I see now that there is indeed a slight difference. The debug.cpp symbols are present as local symbols in the .symtab, both before and after this patch. However, before this patch they had visibility DEFAULT and now they have visibility HIDDEN. I don't think this matters for anything except the linker, but I should probably verify that they are still correctly usable from gcc.

I would appreciate it if someone could provide a step-by-step instruction on how to verify these functions on gdb (I haven't used it for 10-15 years so I apologize if I'm a bit rusty), or provide a pointer to where I can find such instructions. Is this supposed to work on core dumps, live attached processes or both?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1499242980

From stuefe at openjdk.org  Thu Feb 22 13:36:16 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 22 Feb 2024 13:36:16 GMT
Subject: RFR: JDK-8322475: Extend printing for System.map [v2]
In-Reply-To: <xXLpEw01_OAADNe6SFsw8sBYqjShMROIKQH3IflvgAM=.facb614e-cc97-441f-873f-e7453bd4338d@github.com>
References: <xXLpEw01_OAADNe6SFsw8sBYqjShMROIKQH3IflvgAM=.facb614e-cc97-441f-873f-e7453bd4338d@github.com>
Message-ID: <u9Z1-c_4ETMjL5TkEUe7-CFRUrj9J-o0z3Ve83mWMQc=.83a62276-7650-4103-b73c-6f282905ed7e@github.com>

> This is an expansion on the new `System.map` command introduced with JDK-8318636.
> 
> We now print valuable information per memory region, such as:
> 
> - the actual resident set size
> - the actual number of huge pages
> - the actual used page size
> - the THP state of the region (was advised, is eligible, uses THP, ...)
> - whether the region is shared
> - whether the region had been committed (backed by swap)
> - whether the region has been swapped out.
> 
> Example output:
> 
> 
> from                 to                       size        rss    hugetlb pgsz prot notes            vm info/file                                                                                                                                                                    
> 0x00000000c0000000 - 0x00000000ffe00000 1071644672          0    4194304 2M   rw-p huge             JAVAHEAP /anon_hugepage                                                                                                                                                         
> 0x00000000ffe00000 - 0x0000000100000000    2097152          0          0 2M   rw-p huge             JAVAHEAP /anon_hugepage                                                                                                                                                         
> 0x0000558016b67000 - 0x0000558016b68000       4096       4096          0 4K   r--p                  /shared/projects/openjdk/jdk-jdk/output-fastdebug/images/jdk/bin/java
> 0x0000558016b68000 - 0x0000558016b69000       4096       4096          0 4K   r-xp                  /shared/projects/openjdk/jdk-jdk/output-fastdebug/images/jdk/bin/java
> 0x00007f3a749f2000 - 0x00007f3a74c62000    2555904    2555904          0 4K   rwxp                  CODE(CodeHeap 'profiled nmethods')                               
> 0x00007f3a74c62000 - 0x00007f3a7be51000  119468032          0          0 4K   ---p nores            CODE(CodeHeap 'profiled nmethods')                               
> 0x00007f3a7be51000 - 0x00007f3a7c1c1000    3604480    3604480          0 4K   rwxp                  CODE(CodeHeap 'profiled nmethods')                               
> 0x00007f3a7c1c1000 - 0x00007f3a7c592000    4001792          0          0 4K   ---p nores            CODE(CodeHeap 'non-nmethods')                                    
> 0x00007f3a7c592000 - 0x00007f3a7c802000    2555904    2555904          0 4K   rwxp                  CODE(CodeHeap 'non-profiled nmethods')                           
> 0x00007f3a7c802000 - 0x00007f3a839f200...

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 six additional commits since the last revision:

 - wip
 - wip
 - wip
 - wip
 - Merge branch 'master' into System.maps-more-info
 - Extend System.map on Linux

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17158/files
  - new: https://git.openjdk.org/jdk/pull/17158/files/f9ee2c2f..db79ce06

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17158&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17158&range=00-01

  Stats: 105599 lines in 3577 files changed: 54098 ins; 27337 del; 24164 mod
  Patch: https://git.openjdk.org/jdk/pull/17158.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17158/head:pull/17158

PR: https://git.openjdk.org/jdk/pull/17158

From ihse at openjdk.org  Thu Feb 22 13:39:26 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 13:39:26 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v3]
In-Reply-To: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
Message-ID: <B5_kr9qJwfypMGingeJ0OGrxFl4ICJCNTwxyocqXo60=.8f13d5c6-9150-4dde-ba85-d6340d2c8dc7@github.com>

> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
> 
> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
> 
> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
> 
> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Restore linker script to linux/gcc builds

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17955/files
  - new: https://git.openjdk.org/jdk/pull/17955/files/27b4df53..26b1e194

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17955&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17955&range=01-02

  Stats: 14 lines in 2 files changed: 13 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17955.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17955/head:pull/17955

PR: https://git.openjdk.org/jdk/pull/17955

From ihse at openjdk.org  Thu Feb 22 13:39:26 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 13:39:26 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v2]
In-Reply-To: <12hoUFbZkWHBpiXs0TPiMYGW3sSvBX_536mvSSG-y-8=.21abcef9-9a2b-4558-ba19-dddfd7931f9f@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <12hoUFbZkWHBpiXs0TPiMYGW3sSvBX_536mvSSG-y-8=.21abcef9-9a2b-4558-ba19-dddfd7931f9f@github.com>
Message-ID: <0Inj4SqHl36K4FzxPfbfyA20_7x8GyGMngBfuNEGsf8=.9cba3073-cfdd-43a4-828a-4ec362dcaaf3@github.com>

On Thu, 22 Feb 2024 10:27:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
>> 
>> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
>> 
>> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
>> 
>> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Rename the Windows export file to .def
>  - Remove unused symbol _Copy_conjoint_bytes on linux/arm32

I just realized I could keep an extremely simplified linker script ("mapfile") for gcc, and thereby keeping the `@SUNWprivate_1.1` on the exported symbols, and keeping `__bss_start` and friends local. This further minimizes the difference to the existing libjvm.so for gcc builds. 

I think we can get rid of this as well going forward, but as with other cleanups, let's do that separately.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1959467819

From ihse at openjdk.org  Thu Feb 22 13:54:56 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 13:54:56 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v3]
In-Reply-To: <bCCiR8BHjfb_LNAuneO4lfRx1VY4UE8f1irt43V97vQ=.0010380e-f54d-439e-8877-5ba9a75fe71f@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <17uxknoRrcfnUlWwJndQk2AWqvZv4v34JZMVQPpl81w=.34a2c1a8-d251-4f8c-bd12-2f024b4914e6@github.com>
 <28TkIQvEbOiKscThXtUGZ24pcHI4wqrVgy6C2P6_f-4=.ae8dcc41-aedd-441c-a8ad-1526dd56db14@github.com>
 <FfaU4QcwSZnSxWSys6H3lqIO1UHBFKCb5dJ2tmNsR00=.6d492146-71d7-4530-bcdd-e0875bf02927@github.com>
 <A1r4AEShJI_4GfYz3lxkxopCNYuaMF-zhmhuhd493gY=.c112b7c1-5d21-4074-8967-48b48387bd23@github.com>
 <bCCiR8BHjfb_LNAuneO4lfRx1VY4UE8f1irt43V97vQ=.0010380e-f54d-439e-8877-5ba9a75fe71f@github.com>
Message-ID: <rSSQn-eaJbthjFJBhKKLm9-GuvWLPhA293t5_AThMoE=.7dc91c10-b655-4b24-830c-3bb61ca99ff6@github.com>

On Thu, 22 Feb 2024 10:18:21 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> You mean making a search/replace from `__attribute__ ((foo))` to `[[gnu::foo)]]` in the code base? It seems a bit like unnecessary churn to me. We have 100+ places in the code with `__attribute__`. If you really want to try to push that agenda, be my guest. But do it in a separate PR. ;-)
>
> Oh no, by fix I meant removing the HIDDEN attribute and somehow fixing that issue differently, not replacing everything with C++ Attributes!

Well, I hope that can be done, but it depends... As I see it, there are three possible ways to get rid of this `HIDDEN`.

1) Accept that we export these functions on gcc, and just remove the attribute. (Kind of capitulating to the bug.)

2) See if there is a way we can work around this problem, by changing something in how these functions are defined, that does not trigger this bug.

3) Have this bug fixed in gcc, and move to a minimum version of gcc that includes this fix.

I'm not terribly keen on any of these solutions. I think 2, if it is possible, would be the simplest and cleanest. Or 1, if we really think this HIDDEN workaround is worse than the problem it solves (unintentionally exporting symbols).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1499275242

From lois.foltan at oracle.com  Thu Feb 22 14:02:40 2024
From: lois.foltan at oracle.com (Lois Foltan)
Date: Thu, 22 Feb 2024 14:02:40 +0000
Subject: =?utf-8?B?UmU6IENGVjogTmV3IEhvdFNwb3QgR3JvdXAgTWVtYmVyOiBKb2hhbiBTasO2?=
 =?utf-8?B?bMOpbg==?=
In-Reply-To: <041D6781-CFE6-41BD-A8F5-7E25C2EFFD52@oracle.com>
References: <041D6781-CFE6-41BD-A8F5-7E25C2EFFD52@oracle.com>
Message-ID: <BLAPR10MB5156C2FF47165713F6A9B89C8A562@BLAPR10MB5156.namprd10.prod.outlook.com>

Vote: yes

On 2/22/24, 7:14?AM, "hotspot-dev" <hotspot-dev-retn at openjdk.org> wrote:
I hereby nominate Johan Sj?l?n (jsjolen) to Membership in the HotSpot Group.

Johan is a Reviewer in the JDK project, and a member of the Oracle JVM Runtime team. Johan has done major work in the Unified Logging framework and is today the de facto owner of that area. He has done major cleanups and bug fixes throughout the JVM, and does a lot of work in the Native Memory Tracking area.

Votes are due by Thursday March 7.

Only current Members of the HotSpot Group [1] are eligible to vote on this nomination.  Votes must be cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [2].

Thanks,
/Jesper

[1] https://openjdk.org/census
[2] https://openjdk.org/groups/#member-vote
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20240222/1f43e8ed/attachment-0001.htm>

From ChrisPhi at LGonQn.Org  Thu Feb 22 14:03:40 2024
From: ChrisPhi at LGonQn.Org (Chris Phillips)
Date: Thu, 22 Feb 2024 09:03:40 -0500
Subject: =?UTF-8?Q?Re=3A_CFV=3A_New_HotSpot_Group_Member=3A_Johan_Sj=C3=B6l?=
 =?UTF-8?B?w6lu?=
In-Reply-To: <041D6781-CFE6-41BD-A8F5-7E25C2EFFD52@oracle.com>
References: <041D6781-CFE6-41BD-A8F5-7E25C2EFFD52@oracle.com>
Message-ID: <5502c5a4-3abf-44d8-a2bf-7e42297990e9@LGonQn.Org>

Hi!
Vote: yes

Cheers!
ChrisPhi


On 2024-02-22 07:14, Jesper Wilhelmsson wrote:
> I hereby nominate Johan Sj?l?n (jsjolen) to Membership in the HotSpot Group.
> 
> Johan is a Reviewer in the JDK project, and a member of the Oracle JVM Runtime team. Johan has done major work in the Unified Logging framework and is today the de facto owner of that area. He has done major cleanups and bug fixes throughout the JVM, and does a lot of work in the Native Memory Tracking area.
> 
> Votes are due by Thursday March 7.
> 
> Only current Members of the HotSpot Group [1] are eligible to vote on this nomination.  Votes must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> Thanks,
> /Jesper
> 
> [1] https://openjdk.org/census
> [2] https://openjdk.org/groups/#member-vote

From kevinw at openjdk.org  Thu Feb 22 14:07:56 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 22 Feb 2024 14:07:56 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v3]
In-Reply-To: <Y9p2b3b_z8muEidBlBBrpCwLumHrKejUvxfzqZxnBjo=.a9119066-f460-4ec0-aa58-c8d78c721f6f@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <vXCbCZSVLYSkkeXQTOvMSxst4Yfi2ZaHikbUPhuTiME=.8995f473-11cd-4265-afa3-0e4376be88e8@github.com>
 <2wcpOdg70sjre1ULOsoeTKxu7Axq46zoU9qo_bkMgdM=.87d80995-09f3-417a-9270-56dd365d2b06@github.com>
 <iD9Cps1c81g7BYImEu15xOQvY3Mq9IFZp5_iWU0pm0o=.abd92460-a728-48e3-a6d9-12d8a32b9e7d@github.com>
 <EhViMvCbwUI2HUVsMdUAgr3tB4S1luXqdrG8cNbwtlA=.7b8ddcb7-ea13-4955-9b83-76ed79f1adce@github.com>
 <lIVvvltNqX9EzhzaitISyBocIyA3C4ZjJv83ldUnmeg=.a21613ca-ba82-4412-8040-2058fba56661@github.com>
 <E9y5WFeGqqskboveKh7YamHgbz6Ur5QdJji2uOxzt6c=.4aad38fd-6a31-4881-a2b8-b145d22a6763@github.com>
 <Wo15zScdWr27VO2St0-ExVqddH1wWLdS2cnRF6Yq1wE=.505b59eb-9942-4b85-901d-97715025c078@github.com>
 <Y9p2b3b_z8muEidBlBBrpCwLumHrKejUvxfzqZxnBjo=.a9119066-f460-4ec0-aa58-c8d78c721f6f@github.com>
Message-ID: <Kt8zuxrBV-xUzZI29-eMuQFoLU_phXcCB4qc63pe-PU=.06c7f6a1-0e01-4386-903e-bc81e5de1fb1@github.com>

On Thu, 22 Feb 2024 13:28:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Your comment had me go and elfdump the entire libjvm.so and compare the entire output... :-) Now at least I understand why there were so many spurious changes in the linux binary -- the old symbols were named e.g. `JVM_MonitorWait@@SUNWprivate_1.1` while the new one are just named `JVM_MonitorWait`. This caused the segment to be shorter, and this in turned offsetted all following position, so the change cascaded down.
>
> Ok, I see now that there is indeed a slight difference. The debug.cpp symbols are present as local symbols in the .symtab, both before and after this patch. However, before this patch they had visibility DEFAULT and now they have visibility HIDDEN. I don't think this matters for anything except the linker, but I should probably verify that they are still correctly usable from gcc.
> 
> I would appreciate it if someone could provide a step-by-step instruction on how to verify these functions on gdb (I haven't used it for 10-15 years so I apologize if I'm a bit rusty), or provide a pointer to where I can find such instructions. Is this supposed to work on core dumps, live attached processes or both?

On a latest JDK build today, in Linux I can attach to a live process (not a core dump):
  gdb --pid PID
..and type:
  call universe()
(I think you need to switch to a JavaThread first) and see on the JVM's output:

"Executing universe"
Heap
 garbage-first heap   total reserved 30932992K,  ...etc...
 

Removing JNIEXPORT here on Linux and rebuilding: still works.

readelf shows: 
existing build (using JNIEXPORT):
 32252: 0000000000698160   249 FUNC    LOCAL  DEFAULT   11 universe

without JNIEXPORT:
 32252: 0000000000698160   249 FUNC    LOCAL  HIDDEN    11 universe

So gdb on Linux can call a HIDDEN function, i.e. without the JNIEXPORT.  It seems happy either way, not affected by visibility.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1499294627

From jwaters at openjdk.org  Thu Feb 22 14:17:04 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Feb 2024 14:17:04 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v3]
In-Reply-To: <rSSQn-eaJbthjFJBhKKLm9-GuvWLPhA293t5_AThMoE=.7dc91c10-b655-4b24-830c-3bb61ca99ff6@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <17uxknoRrcfnUlWwJndQk2AWqvZv4v34JZMVQPpl81w=.34a2c1a8-d251-4f8c-bd12-2f024b4914e6@github.com>
 <28TkIQvEbOiKscThXtUGZ24pcHI4wqrVgy6C2P6_f-4=.ae8dcc41-aedd-441c-a8ad-1526dd56db14@github.com>
 <FfaU4QcwSZnSxWSys6H3lqIO1UHBFKCb5dJ2tmNsR00=.6d492146-71d7-4530-bcdd-e0875bf02927@github.com>
 <A1r4AEShJI_4GfYz3lxkxopCNYuaMF-zhmhuhd493gY=.c112b7c1-5d21-4074-8967-48b48387bd23@github.com>
 <bCCiR8BHjfb_LNAuneO4lfRx1VY4UE8f1irt43V97vQ=.0010380e-f54d-439e-8877-5ba9a75fe71f@github.com>
 <rSSQn-eaJbthjFJBhKKLm9-GuvWLPhA293t5_AThMoE=.7dc91c10-b655-4b24-830c-3bb61ca99ff6@github.com>
Message-ID: <eKOLOhDFnBx9Ne1hfOYleMnz5iGt8Nb5g6JJ3S7b63Q=.b2744208-182b-47a7-a0ef-5b44061cdfb4@github.com>

On Thu, 22 Feb 2024 13:52:26 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Oh no, by fix I meant removing the HIDDEN attribute and somehow fixing that issue differently, not replacing everything with C++ Attributes!
>
> Well, I hope that can be done, but it depends... As I see it, there are three possible ways to get rid of this `HIDDEN`.
> 
> 1) Accept that we export these functions on gcc, and just remove the attribute. (Kind of capitulating to the bug.)
> 
> 2) See if there is a way we can work around this problem, by changing something in how these functions are defined, that does not trigger this bug.
> 
> 3) Have this bug fixed in gcc, and move to a minimum version of gcc that includes this fix.
> 
> I'm not terribly keen on any of these solutions. I think 2, if it is possible, would be the simplest and cleanest. Or 1, if we really think this HIDDEN workaround is worse than the problem it solves (unintentionally exporting symbols).

I see, seems like it's an unfortunate situation where a fix is hard or even impossible. If we file a gcc bug for it now, it'll get fixed in some insanely new gcc version (such as gcc 15 or 16) and we'd have to jump to that version, which I'm sure no one is going to like :(

Nevertheless, since there are so many instances of it, I suggest #pragma GCC visibility push(hidden) instead of adding a new macro to this file, in my opinion it's somewhat cleaner and also makes the change smaller.

#pragma GCC visibility push(hidden)
// Junk that needs hidden visibility to work properly
#pragma GCC visibility pop

Also, why TARGET_COMPILER_gcc instead of __GNUC__? Does this have to work with Apple Clang on macOS as well?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1499309573

From ihse at openjdk.org  Thu Feb 22 14:32:12 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 14:32:12 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v4]
In-Reply-To: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
Message-ID: <QWOxD_Kcb04DD6jdgPIiJRcapXZtivFeoU0wlB0VNWA=.4509074e-ebf0-4332-a1fa-6e7458d6b7de@github.com>

> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
> 
> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
> 
> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
> 
> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Rename the version script to version-script.txt

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17955/files
  - new: https://git.openjdk.org/jdk/pull/17955/files/26b1e194..ad1d53c9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17955&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17955&range=02-03

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17955.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17955/head:pull/17955

PR: https://git.openjdk.org/jdk/pull/17955

From erikj at openjdk.org  Thu Feb 22 14:32:12 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 22 Feb 2024 14:32:12 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <7j108nQLaK4cLUE4ANl8gAsJby-Dg90ry1MH83Htkh0=.e7732c94-48e5-4e2b-ad08-90d3dba1bd82@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <qD5Ael_CjnuLVdZOdQ863VqU1KBJp1x7J1f3OPOJjcI=.fc651d8a-8640-405d-8339-bffc91b23050@github.com>
 <7j108nQLaK4cLUE4ANl8gAsJby-Dg90ry1MH83Htkh0=.e7732c94-48e5-4e2b-ad08-90d3dba1bd82@github.com>
Message-ID: <OlWBwMQB9opCYtf86_yTJ5-8zmwcgUuqyqVcaLzRCrM=.8448b5d5-928b-4755-81b8-69ccde611280@github.com>

On Thu, 22 Feb 2024 09:53:53 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The difference is that the data (variable) symbols __bss_start, _edata and _end, and the text (function) symbols _fini and _init has changed from local to global. Afaik, these are symbols created by the linker. Also, when we used a mapfile, the symbol SUNWprivate_1.1 that was part of the mapfile definition was included in libjvm.so, and this is no longer the case.

Regarding SUNWprivate_1.1, reading [JDK-4916160](https://bugs.openjdk.org/browse/JDK-4916160) it seems like it could cause problems for native user libraries linked against an older JDK version if we remove it. I think this is what David Holmes was referring to. So it seems like a good idea to figure out a way to keep it around.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1959567183

From stuefe at openjdk.org  Thu Feb 22 14:34:06 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 22 Feb 2024 14:34:06 GMT
Subject: RFR: 8139457: Relax alignment of array elements [v68]
In-Reply-To: <c7Ao52lFl74Z4lgXCyKbHjkWTBHEseHS7hlv_rEU9N4=.de5e6b38-abdd-45b8-968a-5e8467f950a9@github.com>
References: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
 <c7Ao52lFl74Z4lgXCyKbHjkWTBHEseHS7hlv_rEU9N4=.de5e6b38-abdd-45b8-968a-5e8467f950a9@github.com>
Message-ID: <Dwbt072JHK_WhAdpoQBpw6mrLHDuHcYx7CDkKCuBDBk=.6a460641-d347-49d4-aa92-c1e8a716c441@github.com>

On Thu, 22 Feb 2024 13:05:21 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details.
>> 
>> Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements.
>> 
>> Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16.
>> 
>> Testing:
>>  - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390)
>>  - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390)
>>  - [x] tier1 (x86_64, x86_32, aarch64, riscv)
>>  - [x] tier2 (x86_64, aarch64, riscv)
>>  - [x] tier3 (x86_64, riscv)
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move shim into initialize_header() (aarch64)

This looks good to me, Roman. Nice work.

-------------

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/11044#pullrequestreview-1895894482

From stuefe at openjdk.org  Thu Feb 22 14:34:08 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 22 Feb 2024 14:34:08 GMT
Subject: RFR: 8139457: Relax alignment of array elements [v53]
In-Reply-To: <s3A8buv6DBosgHl2g4EEes_ggFJzQsGf66LuEbTaNTQ=.13c916a1-5f75-4b93-a9ce-f3ccd58740e7@github.com>
References: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
 <OkgT6eFogO1aHEGtUJCURfxq0y5dMjKHdUbyCh9S0j0=.40d26993-d641-4a22-bb08-39bf5cf9d288@github.com>
 <s3A8buv6DBosgHl2g4EEes_ggFJzQsGf66LuEbTaNTQ=.13c916a1-5f75-4b93-a9ce-f3ccd58740e7@github.com>
Message-ID: <UT3eX-_Mui6eqZ0_9WpAYm3Q0jHAuhug7shzo0hQ72I=.535ccc3a-4acd-4937-8db0-884e00ff3bbe@github.com>

On Wed, 23 Aug 2023 18:05:17 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix wrong alignment
>
> src/hotspot/share/oops/arrayOop.hpp line 59:
> 
>> 57:   // aligned 0 mod 8.  The typeArrayOop itself must be aligned at least this
>> 58:   // strongly.
>> 59:   static bool element_type_should_be_aligned(BasicType type) {
> 
> The comment above makes it sound like this is only valid for `typeArrayOop`. Should be updated to reflect the change.

Really nitpicky, but why even say "of an arrayOop"? What other use of "element" within the class arrayOopDesc would make sense here? Also, it does not check (which implies asserts or similar). Why not just  

Given a type, return true if elements of that type must be aligned to 64-bit.

or similar.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/11044#discussion_r1499266276

From kevinw at openjdk.org  Thu Feb 22 14:35:55 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 22 Feb 2024 14:35:55 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v4]
In-Reply-To: <Kt8zuxrBV-xUzZI29-eMuQFoLU_phXcCB4qc63pe-PU=.06c7f6a1-0e01-4386-903e-bc81e5de1fb1@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <vXCbCZSVLYSkkeXQTOvMSxst4Yfi2ZaHikbUPhuTiME=.8995f473-11cd-4265-afa3-0e4376be88e8@github.com>
 <2wcpOdg70sjre1ULOsoeTKxu7Axq46zoU9qo_bkMgdM=.87d80995-09f3-417a-9270-56dd365d2b06@github.com>
 <iD9Cps1c81g7BYImEu15xOQvY3Mq9IFZp5_iWU0pm0o=.abd92460-a728-48e3-a6d9-12d8a32b9e7d@github.com>
 <EhViMvCbwUI2HUVsMdUAgr3tB4S1luXqdrG8cNbwtlA=.7b8ddcb7-ea13-4955-9b83-76ed79f1adce@github.com>
 <lIVvvltNqX9EzhzaitISyBocIyA3C4ZjJv83ldUnmeg=.a21613ca-ba82-4412-8040-2058fba56661@github.com>
 <E9y5WFeGqqskboveKh7YamHgbz6Ur5QdJji2uOxzt6c=.4aad38fd-6a31-4881-a2b8-b145d22a6763@github.com>
 <Wo15zScdWr27VO2St0-ExVqddH1wWLdS2cnRF6Yq1wE=.505b59eb-9942-4b85-901d-97715025c078@github.com>
 <Y9p2b3b_z8muEidBlBBrpCwLumHrKejUvxfzqZxnBjo=.a9119066-f460-4ec0-aa58-c8d78c721f6f@github.com>
 <Kt8zuxrBV-xUzZI29-eMuQFoLU_phXcCB4qc63pe-PU=.06c7f6a1-0e01-4386-903e-bc81e5de1fb1@github.com>
Message-ID: <vIH043hYabyI97214HCCxnzP2YcrCNr2pEkeLWs6tM4=.069f3df2-fa1d-4d2c-842e-5aa1e7d915ff@github.com>

On Thu, 22 Feb 2024 14:05:28 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Ok, I see now that there is indeed a slight difference. The debug.cpp symbols are present as local symbols in the .symtab, both before and after this patch. However, before this patch they had visibility DEFAULT and now they have visibility HIDDEN. I don't think this matters for anything except the linker, but I should probably verify that they are still correctly usable from gcc.
>> 
>> I would appreciate it if someone could provide a step-by-step instruction on how to verify these functions on gdb (I haven't used it for 10-15 years so I apologize if I'm a bit rusty), or provide a pointer to where I can find such instructions. Is this supposed to work on core dumps, live attached processes or both?
>
> On a latest JDK build today, in Linux I can attach to a live process (not a core dump):
>   gdb --pid PID
> ..and type:
>   call universe()
> (I think you need to switch to a JavaThread first) and see on the JVM's output:
> 
> "Executing universe"
> Heap
>  garbage-first heap   total reserved 30932992K,  ...etc...
>  
> 
> Removing JNIEXPORT here on Linux and rebuilding: still works.
> 
> readelf shows: 
> existing build (using JNIEXPORT):
>  32252: 0000000000698160   249 FUNC    LOCAL  DEFAULT   11 universe
> 
> without JNIEXPORT:
>  32252: 0000000000698160   249 FUNC    LOCAL  HIDDEN    11 universe
> 
> So gdb on Linux can call a HIDDEN function, i.e. without the JNIEXPORT.  It seems happy either way, not affected by visibility.

Windows:
Attach Visual Studio,
in the Immediate Window, type (funny VS syntax I do not claim to understand):

{,,JVM}universe()

...and on the JVM's console window I see:

"Executing universe"
Heap
 garbage-first heap   total reserved 8343552K,...etc...

(It actually did nothing on the first invocation for me, I have typed it 5 times, only got 4 sets of output.  But the symbol is working...)

In that working (JNIEXPORT) case, the map file jdk/bin/server/jvm.dll.map shows:

 0001:0027ff50       universe                   0000000180280f50 f   debug.obj

(I do like that we call it jvm.dll.map now, not just "jvm.map"!)

Test removing JNIEXPORT:
 
Without JNIEXPORT, on Windows, the symbol universe is just not there.  Nothing in the map file.  In Visual Studio:

{,,JVM}universe()
identifier "universe" is undefined

That confirms the expected Windows behaviour: we still need JNIEXPORT to make debug.cpp utils callable by a debugger.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1499341256

From jwaters at openjdk.org  Thu Feb 22 14:42:54 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Feb 2024 14:42:54 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v4]
In-Reply-To: <vIH043hYabyI97214HCCxnzP2YcrCNr2pEkeLWs6tM4=.069f3df2-fa1d-4d2c-842e-5aa1e7d915ff@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <vXCbCZSVLYSkkeXQTOvMSxst4Yfi2ZaHikbUPhuTiME=.8995f473-11cd-4265-afa3-0e4376be88e8@github.com>
 <2wcpOdg70sjre1ULOsoeTKxu7Axq46zoU9qo_bkMgdM=.87d80995-09f3-417a-9270-56dd365d2b06@github.com>
 <iD9Cps1c81g7BYImEu15xOQvY3Mq9IFZp5_iWU0pm0o=.abd92460-a728-48e3-a6d9-12d8a32b9e7d@github.com>
 <EhViMvCbwUI2HUVsMdUAgr3tB4S1luXqdrG8cNbwtlA=.7b8ddcb7-ea13-4955-9b83-76ed79f1adce@github.com>
 <lIVvvltNqX9EzhzaitISyBocIyA3C4ZjJv83ldUnmeg=.a21613ca-ba82-4412-8040-2058fba56661@github.com>
 <E9y5WFeGqqskboveKh7YamHgbz6Ur5QdJji2uOxzt6c=.4aad38fd-6a31-4881-a2b8-b145d22a6763@github.com>
 <Wo15zScdWr27VO2St0-ExVqddH1wWLdS2cnRF6Yq1wE=.505b59eb-9942-4b85-901d-97715025c078@github.com>
 <Y9p2b3b_z8muEidBlBBrpCwLumHrKejUvxfzqZxnBjo=.a9119066-f460-4ec0-aa58-c8d78c721f6f@github.com>
 <Kt8zuxrBV-xUzZI29-eMuQFoLU_phXcCB4qc63pe-PU=.06c7f6a1-0e01-4386-903e-bc81e5de1fb1@github.com>
 <vIH043hYabyI97214HCCxnzP2YcrCNr2pEk
 eLWs6tM4=.069f3df2-fa1d-4d2c-842e-5aa1e7d915ff@github.com>
Message-ID: <YI4DuNIo8Zg90K3vUxfbJMkihF299RgKWnoaiidPRDA=.9a4fb18b-28b0-4418-b887-f190077590d2@github.com>

On Thu, 22 Feb 2024 14:33:18 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> (I do like that we call it jvm.dll.map now, not just "jvm.map"!)

You can thank @fthevenet for that! :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1499355063

From pchilanomate at openjdk.org  Thu Feb 22 14:44:13 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 22 Feb 2024 14:44:13 GMT
Subject: RFR: 8322962: Upcall stub might go undetected when freezing frames
Message-ID: <9wGivvL8XaePg4yOjShuasS2RZzyT2bzUi8EKWs95yQ=.36456962-47a7-4920-9a3a-a15936d4f480@github.com>

Please review this simple fix. There is a missing push_cont_fastpath()/pop_cont_fastpath() around the call to Java in the upcall stub. Because of this, if from that upcall a virtual thread tries to yield, and all the other methods in the stack are compiled, we will incorrectly take the freeze fast path and freeze everything in the stack including the native frames. By forcing the slow path instead we will identify the upcall stub and pin the vthread.

The issue can be easily reproduced by running the modified version of test GetStackTraceALotWhenPinned.java included in this patch. I also tested the fix by running tiers1-3 in mach5. 

Thanks,
Patricio

-------------

Commit messages:
 - v1

Changes: https://git.openjdk.org/jdk/pull/17964/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17964&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322962
  Stats: 21 lines in 5 files changed: 18 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/17964.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17964/head:pull/17964

PR: https://git.openjdk.org/jdk/pull/17964

From sspitsyn at openjdk.org  Thu Feb 22 14:46:54 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 22 Feb 2024 14:46:54 GMT
Subject: RFR: 8256314: JVM TI GetCurrentContendedMonitor is implemented
 incorrectly
In-Reply-To: <B2vq9tWBtbh9dlbW6UXs21h3CUK821LT_05NID77ZPg=.d6fa3aa5-1052-455f-b24f-e84d8f1eff7a@github.com>
References: <-Yf2Qj_kbyZAA-LDK96IIOcHWMh8__QT1XfnD9jR8kU=.507d5503-1544-44fb-9e81-438ba3458dcd@github.com>
 <B2vq9tWBtbh9dlbW6UXs21h3CUK821LT_05NID77ZPg=.d6fa3aa5-1052-455f-b24f-e84d8f1eff7a@github.com>
Message-ID: <tT8YL7xUcoTb752hF4lkiLz_F9WTdYuQmgCGxkc_q8s=.eece00e3-39f4-483a-a228-2cbae44755f4@github.com>

On Wed, 21 Feb 2024 19:13:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The implementation of the JVM TI `GetCurrentContendedMonitor` does not match the spec. It can sometimes return an incorrect information about the contended monitor. Such a behavior does not match the function spec. 
>> With this update the `GetCurrentContendedMonitor` is returning the monitor only when the specified thread is waiting to enter or re-enter the monitor, and the monitor is not returned when the specified thread is waiting in the `java.lang.Object.wait` to be notified.
>> 
>> The implementation of the JDWP `ThreadReference.CurrentContendedMonitor` command is based and depends on this JVMTI function. The command was both specified incorrectly and had an incorrect behavior. The fix slightly corrects the JDWP spec to make it right (the JDWP implementation has been fixed by the JVM TI update). Please, see and review the related CSR and Release-Note.
>> 
>> CSR: [8326024](https://bugs.openjdk.org/browse/JDK-8326024): JVM TI GetCurrentContendedMonitor is implemented incorrectly
>> RN:   [8326038](https://bugs.openjdk.org/browse/JDK-8326038): Release Note: JVM TI GetCurrentContendedMonitor is implemented incorrectly
>> 
>> Testing:
>>  - tested with the mach5 tiers 1-6
>
> src/java.se/share/data/jdwp/jdwp.spec line 1985:
> 
>> 1983:         "thread may be waiting to enter a monitor, or it may be waiting, via "
>> 1984:         "the java.lang.Object.wait method, to re-enter a monitor after being "
>> 1985:         "notified by another thread. "
> 
> Interrupted or timeout in Object.wait are other reasons to be waiting to reenter. I'm wondering if this should be spelled out here. I see the JVMTI spec uses the phrase "regain" to cover the scenarios where a thread is waiting to reenter.
> 
> In any case, I think the wording could be a smoother as reenter case isn't very clear. Here's an attempt at smoothing out the wording but it may be more than you want to include:
> 
> "The thread may be waiting to enter the object's monitor, or in Object.wait waiting to reenter the monitor after being notified, interrupted, or timeout."

Good suggestion, thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17944#discussion_r1499360404

From patricio.chilano.mateo at oracle.com  Thu Feb 22 14:49:42 2024
From: patricio.chilano.mateo at oracle.com (Patricio Chilano Mateo)
Date: Thu, 22 Feb 2024 09:49:42 -0500
Subject: =?UTF-8?Q?Re=3a_CFV=3a_New_HotSpot_Group_Member=3a_Johan_Sj=c3=b6l?=
 =?UTF-8?B?w6lu?=
In-Reply-To: <041D6781-CFE6-41BD-A8F5-7E25C2EFFD52@oracle.com>
References: <041D6781-CFE6-41BD-A8F5-7E25C2EFFD52@oracle.com>
Message-ID: <ee33170b-4cae-6e19-7534-7425f39a9249@oracle.com>

Vote: yes

On 2/22/24 7:14 AM, Jesper Wilhelmsson wrote:
> I hereby nominate Johan Sj?l?n (jsjolen) to Membership in the HotSpot Group.
>
> Johan is a Reviewer in the JDK project, and a member of the Oracle JVM Runtime team. Johan has done major work in the Unified Logging framework and is today the de facto owner of that area. He has done major cleanups and bug fixes throughout the JVM, and does a lot of work in the Native Memory Tracking area.
>
> Votes are due by Thursday March 7.
>
> Only current Members of the HotSpot Group [1] are eligible to vote on this nomination.  Votes must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [2].
>
> Thanks,
> /Jesper
>
> [1] https://openjdk.org/census
> [2] https://openjdk.org/groups/#member-vote


From alanb at openjdk.org  Thu Feb 22 15:04:55 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 22 Feb 2024 15:04:55 GMT
Subject: RFR: 8256314: JVM TI GetCurrentContendedMonitor is implemented
 incorrectly
In-Reply-To: <-Yf2Qj_kbyZAA-LDK96IIOcHWMh8__QT1XfnD9jR8kU=.507d5503-1544-44fb-9e81-438ba3458dcd@github.com>
References: <-Yf2Qj_kbyZAA-LDK96IIOcHWMh8__QT1XfnD9jR8kU=.507d5503-1544-44fb-9e81-438ba3458dcd@github.com>
Message-ID: <wLiCX5FM7pNsWcjewGMDuQBJ51g1HxO28zrbW1NDpyw=.5897a353-1e38-4ebf-9ea0-eaf1e83a0040@github.com>

On Wed, 21 Feb 2024 10:28:49 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The implementation of the JVM TI `GetCurrentContendedMonitor` does not match the spec. It can sometimes return an incorrect information about the contended monitor. Such a behavior does not match the function spec. 
> With this update the `GetCurrentContendedMonitor` is returning the monitor only when the specified thread is waiting to enter or re-enter the monitor, and the monitor is not returned when the specified thread is waiting in the `java.lang.Object.wait` to be notified.
> 
> The implementation of the JDWP `ThreadReference.CurrentContendedMonitor` command is based and depends on this JVMTI function. The command was both specified incorrectly and had an incorrect behavior. The fix slightly corrects the JDWP spec to make it right (the JDWP implementation has been fixed by the JVM TI update). Please, see and review the related CSR and Release-Note.
> 
> CSR: [8326024](https://bugs.openjdk.org/browse/JDK-8326024): JVM TI GetCurrentContendedMonitor is implemented incorrectly
> RN:   [8326038](https://bugs.openjdk.org/browse/JDK-8326038): Release Note: JVM TI GetCurrentContendedMonitor is implemented incorrectly
> 
> Testing:
>  - tested with the mach5 tiers 1-6

Are you planning to update ThreadReference::currentContendedMonitor method description too?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17944#issuecomment-1959636693

From jvernee at openjdk.org  Thu Feb 22 15:04:55 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 22 Feb 2024 15:04:55 GMT
Subject: RFR: 8322962: Upcall stub might go undetected when freezing frames
In-Reply-To: <9wGivvL8XaePg4yOjShuasS2RZzyT2bzUi8EKWs95yQ=.36456962-47a7-4920-9a3a-a15936d4f480@github.com>
References: <9wGivvL8XaePg4yOjShuasS2RZzyT2bzUi8EKWs95yQ=.36456962-47a7-4920-9a3a-a15936d4f480@github.com>
Message-ID: <yWTMl97lFkIEkEFuNS_pYLfN-5I63rgyllud2Ng50ME=.bbdcae67-c26a-49f0-8a17-b1fac657af4d@github.com>

On Thu, 22 Feb 2024 14:28:18 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review this simple fix. There is a missing push_cont_fastpath()/pop_cont_fastpath() around the call to Java in the upcall stub. Because of this, if from that upcall a virtual thread tries to yield, and all the other methods in the stack are compiled, we will incorrectly take the freeze fast path and freeze everything in the stack including the native frames. By forcing the slow path instead we will identify the upcall stub and pin the vthread.
> 
> The issue can be easily reproduced by running the modified version of test GetStackTraceALotWhenPinned.java included in this patch. I also tested the fix by running tiers1-3 in mach5. 
> 
> Thanks,
> Patricio

x64 and aarch64 code look good to me. push/pop_cont_fastpath don't modify the register state or the stack ptr. (it looks like 32-bit x86 will use the fallback linker for now, so I'm not worried about that).

-------------

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17964#pullrequestreview-1896090108

From ihse at openjdk.org  Thu Feb 22 15:09:56 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 15:09:56 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <OlWBwMQB9opCYtf86_yTJ5-8zmwcgUuqyqVcaLzRCrM=.8448b5d5-928b-4755-81b8-69ccde611280@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <qD5Ael_CjnuLVdZOdQ863VqU1KBJp1x7J1f3OPOJjcI=.fc651d8a-8640-405d-8339-bffc91b23050@github.com>
 <7j108nQLaK4cLUE4ANl8gAsJby-Dg90ry1MH83Htkh0=.e7732c94-48e5-4e2b-ad08-90d3dba1bd82@github.com>
 <OlWBwMQB9opCYtf86_yTJ5-8zmwcgUuqyqVcaLzRCrM=.8448b5d5-928b-4755-81b8-69ccde611280@github.com>
Message-ID: <npFPREy6ZiUTGMH7oH-1PTOJkEy6TAtk4ZxUi9eG5vQ=.799f9c60-0757-48fd-b6de-b70d3bc32b02@github.com>

On Thu, 22 Feb 2024 14:28:48 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> Regarding SUNWprivate_1.1, reading [JDK-4916160](https://bugs.openjdk.org/browse/JDK-4916160) it seems like it could cause problems for native user libraries linked against an older JDK version if we remove it. I think this is what David Holmes was referring to. So it seems like a good idea to figure out a way to keep it around.

"Forward compatibility issue : 1.4.1_03 onwards". Wow, that's a blast from the past! The sins of the fathers, etc. :)

I'm not sure I understand JDK-4916160 completely, but it seems they had the opposite situation -- prior to 1.4.1_03 we did not link with version scripts, and from 1.4.1_03 we did. And this was closed as "not an issue".

Nevertheless, I have found a way to keep the `SUNWprivate_1.1` that is not too ugly, so with the latest commit to this PR I am doing that. I have now verified that this makes no visible difference in the symbol tables at all between the current libjvm.so and the one produced with this patch on gcc. There is still a difference in the ordering of symbols; it seems like the linker is using a hash table and something is making it different -- perhaps the explicit ordering given in the old mapfile affected the way the linker produced the output. So it is still not a bit-by-bit equality, but it is as far as it is reasonable to get.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1959646396

From ihse at openjdk.org  Thu Feb 22 15:28:57 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 15:28:57 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v4]
In-Reply-To: <eKOLOhDFnBx9Ne1hfOYleMnz5iGt8Nb5g6JJ3S7b63Q=.b2744208-182b-47a7-a0ef-5b44061cdfb4@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <17uxknoRrcfnUlWwJndQk2AWqvZv4v34JZMVQPpl81w=.34a2c1a8-d251-4f8c-bd12-2f024b4914e6@github.com>
 <28TkIQvEbOiKscThXtUGZ24pcHI4wqrVgy6C2P6_f-4=.ae8dcc41-aedd-441c-a8ad-1526dd56db14@github.com>
 <FfaU4QcwSZnSxWSys6H3lqIO1UHBFKCb5dJ2tmNsR00=.6d492146-71d7-4530-bcdd-e0875bf02927@github.com>
 <A1r4AEShJI_4GfYz3lxkxopCNYuaMF-zhmhuhd493gY=.c112b7c1-5d21-4074-8967-48b48387bd23@github.com>
 <bCCiR8BHjfb_LNAuneO4lfRx1VY4UE8f1irt43V97vQ=.0010380e-f54d-439e-8877-5ba9a75fe71f@github.com>
 <rSSQn-eaJbthjFJBhKKLm9-GuvWLPhA293t5_AThMoE=.7dc91c10-b655-4b24-830c-3bb61ca99ff6@github.com>
 <eKOLOhDFnBx9Ne1hfOYleMnz5iGt8Nb5g6JJ3S7b63Q=.b2744208-182b-47a7-a0ef-5b44061cdfb4@github.com>
Message-ID: <EIXdI32FQTr9GWePU0HfJjQEoQvJm_8u6wTFRo-7p6o=.8e4518c3-4533-43de-99f8-24b9cd5ffde5@github.com>

On Thu, 22 Feb 2024 14:11:54 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Well, I hope that can be done, but it depends... As I see it, there are three possible ways to get rid of this `HIDDEN`.
>> 
>> 1) Accept that we export these functions on gcc, and just remove the attribute. (Kind of capitulating to the bug.)
>> 
>> 2) See if there is a way we can work around this problem, by changing something in how these functions are defined, that does not trigger this bug.
>> 
>> 3) Have this bug fixed in gcc, and move to a minimum version of gcc that includes this fix.
>> 
>> I'm not terribly keen on any of these solutions. I think 2, if it is possible, would be the simplest and cleanest. Or 1, if we really think this HIDDEN workaround is worse than the problem it solves (unintentionally exporting symbols).
>
> I see, seems like it's an unfortunate situation where a fix is hard or even impossible. If we file a gcc bug for it now, it'll get fixed in some insanely new gcc version (such as gcc 15 or 16) and we'd have to jump to that version, which I'm sure no one is going to like :(
> 
> Nevertheless, since there are so many instances of it, I suggest #pragma GCC visibility push(hidden) instead of adding a new macro to this file, in my opinion it's somewhat cleaner and also makes the change smaller.
> 
> #pragma GCC visibility push(hidden)
> // Junk that needs hidden visibility to work properly
> #pragma GCC visibility pop
> 
> Also, why TARGET_COMPILER_gcc instead of __GNUC__? Does this have to work with Apple Clang on macOS as well?

This is not an issue with clang, only gcc.

My understanding was that the proper way to test for compiler in Hotspot code was by using `TARGET_COMPILER_gcc`.

I can try using the `#pragma` route instead; if it works I agree it is slightly better than to sprinkle `HIDDEN` all over the place.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1499427455

From ihse at openjdk.org  Thu Feb 22 15:32:56 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 15:32:56 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v4]
In-Reply-To: <YI4DuNIo8Zg90K3vUxfbJMkihF299RgKWnoaiidPRDA=.9a4fb18b-28b0-4418-b887-f190077590d2@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <vXCbCZSVLYSkkeXQTOvMSxst4Yfi2ZaHikbUPhuTiME=.8995f473-11cd-4265-afa3-0e4376be88e8@github.com>
 <2wcpOdg70sjre1ULOsoeTKxu7Axq46zoU9qo_bkMgdM=.87d80995-09f3-417a-9270-56dd365d2b06@github.com>
 <iD9Cps1c81g7BYImEu15xOQvY3Mq9IFZp5_iWU0pm0o=.abd92460-a728-48e3-a6d9-12d8a32b9e7d@github.com>
 <EhViMvCbwUI2HUVsMdUAgr3tB4S1luXqdrG8cNbwtlA=.7b8ddcb7-ea13-4955-9b83-76ed79f1adce@github.com>
 <lIVvvltNqX9EzhzaitISyBocIyA3C4ZjJv83ldUnmeg=.a21613ca-ba82-4412-8040-2058fba56661@github.com>
 <E9y5WFeGqqskboveKh7YamHgbz6Ur5QdJji2uOxzt6c=.4aad38fd-6a31-4881-a2b8-b145d22a6763@github.com>
 <Wo15zScdWr27VO2St0-ExVqddH1wWLdS2cnRF6Yq1wE=.505b59eb-9942-4b85-901d-97715025c078@github.com>
 <Y9p2b3b_z8muEidBlBBrpCwLumHrKejUvxfzqZxnBjo=.a9119066-f460-4ec0-aa58-c8d78c721f6f@github.com>
 <Kt8zuxrBV-xUzZI29-eMuQFoLU_phXcCB4qc63pe-PU=.06c7f6a1-0e01-4386-903e-bc81e5de1fb1@github.com>
 <vIH043hYabyI97214HCCxnzP2YcrCNr2pEk
 eLWs6tM4=.069f3df2-fa1d-4d2c-842e-5aa1e7d915ff@github.com>
 <YI4DuNIo8Zg90K3vUxfbJMkihF299RgKWnoaiidPRDA=.9a4fb18b-28b0-4418-b887-f190077590d2@github.com>
Message-ID: <VMHrBhtOTAzQXtAivx9ed688DfKy-ps37URGTgBNdzo=.4b9d2f7b-7010-4a26-87a7-0520f2c83350@github.com>

On Thu, 22 Feb 2024 14:40:36 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Windows:
>> Attach Visual Studio,
>> in the Immediate Window, type (funny VS syntax I do not claim to understand):
>> 
>> {,,JVM}universe()
>> 
>> ...and on the JVM's console window I see:
>> 
>> "Executing universe"
>> Heap
>>  garbage-first heap   total reserved 8343552K,...etc...
>> 
>> (It actually did nothing on the first invocation for me, I have typed it 5 times, only got 4 sets of output.  But the symbol is working...)
>> 
>> In that working (JNIEXPORT) case, the map file jdk/bin/server/jvm.dll.map shows:
>> 
>>  0001:0027ff50       universe                   0000000180280f50 f   debug.obj
>> 
>> (I do like that we call it jvm.dll.map now, not just "jvm.map"!)
>> 
>> Test removing JNIEXPORT:
>>  
>> Without JNIEXPORT, on Windows, the symbol universe is just not there.  Nothing in the map file.  In Visual Studio:
>> 
>> {,,JVM}universe()
>> identifier "universe" is undefined
>> 
>> That confirms the expected Windows behaviour: we still need JNIEXPORT to make debug.cpp utils callable by a debugger.
>
>> (I do like that we call it jvm.dll.map now, not just "jvm.map"!)
> 
> You can thank @fthevenet for that! :)

> Removing JNIEXPORT here on Linux and rebuilding: still works.
> 
> readelf shows: existing build (using JNIEXPORT): 32252: 0000000000698160 249 FUNC LOCAL DEFAULT 11 universe
> 
> without JNIEXPORT: 32252: 0000000000698160 249 FUNC LOCAL HIDDEN 11 universe
> 
> So gdb on Linux can call a HIDDEN function, i.e. without the JNIEXPORT. It seems happy either way, not affected by visibility.

@kevinjwalls Thank you for testing this for me!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1499434437

From stefank at openjdk.org  Thu Feb 22 16:05:20 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 22 Feb 2024 16:05:20 GMT
Subject: RFR: 8325752: Remove badMetaWordVal [v2]
In-Reply-To: <v1BkRnvyaYCtHUIacFVTKCksyhfsztbOagcblclKqbo=.80fd7a70-bd50-4428-af18-c6a4495f8ea6@github.com>
References: <v1BkRnvyaYCtHUIacFVTKCksyhfsztbOagcblclKqbo=.80fd7a70-bd50-4428-af18-c6a4495f8ea6@github.com>
Message-ID: <RFNBSAeR8oaVBVSj16IC1lmxxC_oFV4vIKDioFuzHpM=.4c7ddc48-30f5-4e95-b337-229b84be71a7@github.com>

> This is another artifact from the permgen removal. At some point we used to zap Metaspace with badMetaWordVal, but we don't do that anymore and therefore we should stop looking for this value.

Stefan Karlsson 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 8325752_remove_badMetaWordVal
 - 8325752: Remove badMetaWordVal

-------------

Changes: https://git.openjdk.org/jdk/pull/17833/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17833&range=01
  Stats: 7 lines in 3 files changed: 0 ins; 7 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17833.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17833/head:pull/17833

PR: https://git.openjdk.org/jdk/pull/17833

From stefank at openjdk.org  Thu Feb 22 16:05:21 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 22 Feb 2024 16:05:21 GMT
Subject: RFR: 8325752: Remove badMetaWordVal
In-Reply-To: <v1BkRnvyaYCtHUIacFVTKCksyhfsztbOagcblclKqbo=.80fd7a70-bd50-4428-af18-c6a4495f8ea6@github.com>
References: <v1BkRnvyaYCtHUIacFVTKCksyhfsztbOagcblclKqbo=.80fd7a70-bd50-4428-af18-c6a4495f8ea6@github.com>
Message-ID: <CMdPTrDipWCEUKu7fzMUL_w7U_0Zl5QiSi6_CviFI7w=.47920f75-0518-48ea-8dc3-91e8df47578b@github.com>

On Tue, 13 Feb 2024 14:53:23 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> This is another artifact from the permgen removal. At some point we used to zap Metaspace with badMetaWordVal, but we don't do that anymore and therefore we should stop looking for this value.

Thanks for reviewing!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17833#issuecomment-1959760065

From stefank at openjdk.org  Thu Feb 22 16:05:21 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 22 Feb 2024 16:05:21 GMT
Subject: Integrated: 8325752: Remove badMetaWordVal
In-Reply-To: <v1BkRnvyaYCtHUIacFVTKCksyhfsztbOagcblclKqbo=.80fd7a70-bd50-4428-af18-c6a4495f8ea6@github.com>
References: <v1BkRnvyaYCtHUIacFVTKCksyhfsztbOagcblclKqbo=.80fd7a70-bd50-4428-af18-c6a4495f8ea6@github.com>
Message-ID: <hKniYwswoehuUGthz8E8ZMfLFA-GhDjSFp-sUFThdCU=.f5abe647-499c-4708-95a0-9d3c3deb8a63@github.com>

On Tue, 13 Feb 2024 14:53:23 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> This is another artifact from the permgen removal. At some point we used to zap Metaspace with badMetaWordVal, but we don't do that anymore and therefore we should stop looking for this value.

This pull request has now been integrated.

Changeset: 9f9a732c
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9f9a732c38072b8168b3c0caee9069f34f6655a8
Stats:     7 lines in 3 files changed: 0 ins; 7 del; 0 mod

8325752: Remove badMetaWordVal

Reviewed-by: coleenp, tschatzl

-------------

PR: https://git.openjdk.org/jdk/pull/17833

From rkennke at openjdk.org  Thu Feb 22 16:08:33 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 22 Feb 2024 16:08:33 GMT
Subject: RFR: 8139457: Relax alignment of array elements [v69]
In-Reply-To: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
References: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
Message-ID: <ItpJ7eaRnBW0Be6y15yN5jzTORHGUBW3udpZG46Z2sI=.6247dbb9-34a1-4dfa-a997-6559ae5afd62@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:

  Improve comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11044/files
  - new: https://git.openjdk.org/jdk/pull/11044/files/e8c1e408..0a4e2f7c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=68
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=67-68

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11044.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/11044/head:pull/11044

PR: https://git.openjdk.org/jdk/pull/11044

From stefank at openjdk.org  Thu Feb 22 16:08:33 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 22 Feb 2024 16:08:33 GMT
Subject: RFR: 8139457: Relax alignment of array elements [v69]
In-Reply-To: <ItpJ7eaRnBW0Be6y15yN5jzTORHGUBW3udpZG46Z2sI=.6247dbb9-34a1-4dfa-a997-6559ae5afd62@github.com>
References: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
 <ItpJ7eaRnBW0Be6y15yN5jzTORHGUBW3udpZG46Z2sI=.6247dbb9-34a1-4dfa-a997-6559ae5afd62@github.com>
Message-ID: <kGywtU2V9qqhHYwOQT_Jfye27ffKCv6zm0n0VwFI2jA=.23abd5b8-940b-4fd1-b3ed-dbf48f28d839@github.com>

On Thu, 22 Feb 2024 16:05:23 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details.
>> 
>> Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements.
>> 
>> Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16.
>> 
>> Testing:
>>  - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390)
>>  - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390)
>>  - [x] tier1 (x86_64, x86_32, aarch64, riscv)
>>  - [x] tier2 (x86_64, aarch64, riscv)
>>  - [x] tier3 (x86_64, riscv)
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve comment

Marked as reviewed by stefank (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/11044#pullrequestreview-1896245081

From rkennke at openjdk.org  Thu Feb 22 16:08:33 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 22 Feb 2024 16:08:33 GMT
Subject: RFR: 8139457: Relax alignment of array elements [v53]
In-Reply-To: <UT3eX-_Mui6eqZ0_9WpAYm3Q0jHAuhug7shzo0hQ72I=.535ccc3a-4acd-4937-8db0-884e00ff3bbe@github.com>
References: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
 <OkgT6eFogO1aHEGtUJCURfxq0y5dMjKHdUbyCh9S0j0=.40d26993-d641-4a22-bb08-39bf5cf9d288@github.com>
 <s3A8buv6DBosgHl2g4EEes_ggFJzQsGf66LuEbTaNTQ=.13c916a1-5f75-4b93-a9ce-f3ccd58740e7@github.com>
 <UT3eX-_Mui6eqZ0_9WpAYm3Q0jHAuhug7shzo0hQ72I=.535ccc3a-4acd-4937-8db0-884e00ff3bbe@github.com>
Message-ID: <RNTFtRYgSo9ra_4LlUe_aElQIjTw5820ZqmSyBFuaJI=.650cb578-8e65-4f1c-8d44-df039b8ee37c@github.com>

On Thu, 22 Feb 2024 13:45:57 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/share/oops/arrayOop.hpp line 59:
>> 
>>> 57:   // aligned 0 mod 8.  The typeArrayOop itself must be aligned at least this
>>> 58:   // strongly.
>>> 59:   static bool element_type_should_be_aligned(BasicType type) {
>> 
>> The comment above makes it sound like this is only valid for `typeArrayOop`. Should be updated to reflect the change.
>
> Really nitpicky, but why even say "of an arrayOop"? What other use of "element" within the class arrayOopDesc would make sense here? Also, it does not check (which implies asserts or similar). Why not just  
> 
> Given a type, return true if elements of that type must be aligned to 64-bit.
> 
> or similar.

Ok.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/11044#discussion_r1499484217

From ihse at openjdk.org  Thu Feb 22 16:15:23 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 16:15:23 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v5]
In-Reply-To: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
Message-ID: <4EYRe8CRYOZ6oPcfyYh1j8XHlttjZJJnO4h2qDrk5q4=.d7588fb9-2f94-458c-bfa6-c3878fec411e@github.com>

> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
> 
> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
> 
> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
> 
> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Use #pragma instead of HIDDEN define

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17955/files
  - new: https://git.openjdk.org/jdk/pull/17955/files/ad1d53c9..00e40a7f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17955&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17955&range=03-04

  Stats: 33 lines in 1 file changed: 9 ins; 6 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/17955.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17955/head:pull/17955

PR: https://git.openjdk.org/jdk/pull/17955

From sspitsyn at openjdk.org  Thu Feb 22 16:29:55 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 22 Feb 2024 16:29:55 GMT
Subject: RFR: 8256314: JVM TI GetCurrentContendedMonitor is implemented
 incorrectly
In-Reply-To: <wLiCX5FM7pNsWcjewGMDuQBJ51g1HxO28zrbW1NDpyw=.5897a353-1e38-4ebf-9ea0-eaf1e83a0040@github.com>
References: <-Yf2Qj_kbyZAA-LDK96IIOcHWMh8__QT1XfnD9jR8kU=.507d5503-1544-44fb-9e81-438ba3458dcd@github.com>
 <wLiCX5FM7pNsWcjewGMDuQBJ51g1HxO28zrbW1NDpyw=.5897a353-1e38-4ebf-9ea0-eaf1e83a0040@github.com>
Message-ID: <VucWB0aEYjHPiBT_BEqtLa_NaHTZwx5Ts_L46f-MyVA=.efb4c6da-a98e-467c-ace4-07d685a3e263@github.com>

On Thu, 22 Feb 2024 15:02:18 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Are you planning to update ThreadReference::currentContendedMonitor method description too?

Initially, I wanted to address it separately. But it is better to fix all together.
I'll update my fix, the CSR and RN.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17944#issuecomment-1959810600

From ihse at openjdk.org  Thu Feb 22 16:31:55 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 16:31:55 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v5]
In-Reply-To: <4EYRe8CRYOZ6oPcfyYh1j8XHlttjZJJnO4h2qDrk5q4=.d7588fb9-2f94-458c-bfa6-c3878fec411e@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <4EYRe8CRYOZ6oPcfyYh1j8XHlttjZJJnO4h2qDrk5q4=.d7588fb9-2f94-458c-bfa6-c3878fec411e@github.com>
Message-ID: <HFkUkKFyXrNb5A-43YJGKnWMkOjy_sB3kU4NcA6iz0g=.6a08a4c1-17b5-40a5-937d-0ec81f2239bb@github.com>

On Thu, 22 Feb 2024 16:15:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
>> 
>> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
>> 
>> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
>> 
>> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use #pragma instead of HIDDEN define

I have created https://github.com/openjdk/jdk/pull/17967 as a dependent PR, to show the kind of changes I would like to see on top of this one. It will remove much of the ugliness in this patch, but at the cost of actually changing behavior.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1959815352

From ihse at openjdk.org  Thu Feb 22 16:33:16 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 16:33:16 GMT
Subject: RFR: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234
Message-ID: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>

Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) has been integrated, it is possible to do some cleanup. The goal of [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) was to not change any behavior, even if that behavior seemed odd.

Now let's try to fix that. We can:

a) remove JNIEXPORT from c2v functions.
b) make debug.cpp functions exported similarly on all platforms.
c) remove JNIEXPORT from aarch64 asm debug function.

Note that this PR is [dependent on](https://mail.openjdk.org/pipermail/jdk-dev/2021-March/005232.html) https://github.com/openjdk/jdk/pull/17955.

-------------

Depends on: https://git.openjdk.org/jdk/pull/17955

Commit messages:
 - 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234

Changes: https://git.openjdk.org/jdk/pull/17967/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17967&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8326509
  Stats: 29 lines in 4 files changed: 0 ins; 20 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/17967.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17967/head:pull/17967

PR: https://git.openjdk.org/jdk/pull/17967

From alanb at openjdk.org  Thu Feb 22 16:35:54 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 22 Feb 2024 16:35:54 GMT
Subject: RFR: 8322962: Upcall stub might go undetected when freezing frames
In-Reply-To: <9wGivvL8XaePg4yOjShuasS2RZzyT2bzUi8EKWs95yQ=.36456962-47a7-4920-9a3a-a15936d4f480@github.com>
References: <9wGivvL8XaePg4yOjShuasS2RZzyT2bzUi8EKWs95yQ=.36456962-47a7-4920-9a3a-a15936d4f480@github.com>
Message-ID: <CO5NoKkt5Gp-0OycuBT39jN2IXGu9wa5Pa6mc6POaT8=.5343b0da-84ec-4de0-b091-f31f42b1033e@github.com>

On Thu, 22 Feb 2024 14:28:18 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review this simple fix. There is a missing push_cont_fastpath()/pop_cont_fastpath() around the call to Java in the upcall stub. Because of this, if from that upcall a virtual thread tries to yield, and all the other methods in the stack are compiled, we will incorrectly take the freeze fast path and freeze everything in the stack including the native frames. By forcing the slow path instead we will identify the upcall stub and pin the vthread.
> 
> The issue can be easily reproduced by running the modified version of test GetStackTraceALotWhenPinned.java included in this patch. I also tested the fix by running tiers1-3 in mach5. 
> 
> Thanks,
> Patricio

x64 and aarch64 changes looks right to me.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17964#pullrequestreview-1896320547

From matsaave at openjdk.org  Thu Feb 22 17:12:04 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 22 Feb 2024 17:12:04 GMT
Subject: RFR: 8251330: Reorder CDS archived heap to speed up relocation
Message-ID: <ZesL5badknO18z5YBr0f1X7pYtMiSWHzKcRJuMfR5kM=.ef3bc428-2461-4501-a30e-e38980fcf5ad@github.com>

We should reorder the archived heap to segregate the objects that don't need marking. This will save space in the archive and improve start-up time

This patch reorders the archived heap to segregate the objects that don't need marking. The leading zeros present in the bitmaps thanks to the reordering can be easily removed, and this the size of the archive is reduced.

Given that the bitmaps are word aligned, some leading zeroes will remain.

Metrics, courtesy of @iklam :
```calculate_oopmap: objects = 15262 (507904 bytes, 332752 bytes don't need marking), embedded oops = 8408, nulls = 54
Oopmap = 15872 bytes

calculate_oopmap: objects = 4590 (335872 bytes, 178120 bytes don't need marking), embedded oops = 46487, nulls = 29019
Oopmap = 10496 bytes

(332752 + 178120) / (507904 + 335872.0) = 0.6054592688106796 
More than 60% of the space used by the archived heap doesn't need to be marked by the oopmap. 

$ java -Xshare:dump -Xlog:cds+map | grep lead
[3.777s][info][cds,map] - heap_oopmap_leading_zeros: 143286
[3.777s][info][cds,map] - heap_ptrmap_leading_zeros: 50713

So we can reduce the "bm" region by (143286 + 50713) / 8 = 24249 bytes.

Current output:
$ java -XX:+UseNewCode -Xshare:dump -Xlog:cds+map | grep lead 
[5.339s][info][cds,map] - heap_oopmap_leading_zeros:      26
[5.339s][info][cds,map] - heap_ptrmap_leading_zeros:      8

-------------

Commit messages:
 - Removed commented code
 - Adjusted word alignment in slice method
 - Merge branch 'master' into reorder_archive_heap_8251330
 - Merge branch 'master' into reorder_archive_heap_8251330
 - Fixed sorting of equal rank objs
 - Only set zeros once
 - Improved setting leading zeros
 - Merge branch 'master' into reorder_archive_heap_8251330
 - Initialized leading zeros
 - Merge branch 'master' into reorder_archive_heap_8251330
 - ... and 17 more: https://git.openjdk.org/jdk/compare/10beb318...bf759be8

Changes: https://git.openjdk.org/jdk/pull/17350/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17350&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8251330
  Stats: 248 lines in 11 files changed: 217 ins; 8 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/17350.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17350/head:pull/17350

PR: https://git.openjdk.org/jdk/pull/17350

From vladimir.kozlov at oracle.com  Thu Feb 22 17:47:52 2024
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 22 Feb 2024 09:47:52 -0800
Subject: =?UTF-8?Q?Re=3A_CFV=3A_New_HotSpot_Group_Member=3A_Johan_Sj=C3=B6l?=
 =?UTF-8?B?w6lu?=
In-Reply-To: <041D6781-CFE6-41BD-A8F5-7E25C2EFFD52@oracle.com>
References: <041D6781-CFE6-41BD-A8F5-7E25C2EFFD52@oracle.com>
Message-ID: <a9bb9edf-d1b5-43b9-a281-212134f40f44@oracle.com>

Vote: yes

Thanks,
Vladimir K

On 2/22/24 4:14 AM, Jesper Wilhelmsson wrote:
> I hereby nominate Johan Sj?l?n (jsjolen) to Membership in the HotSpot Group.
> 
> Johan is a Reviewer in the JDK project, and a member of the Oracle JVM Runtime team. Johan has done major work in the Unified Logging framework and is today the de facto owner of that area. He has done major cleanups and bug fixes throughout the JVM, and does a lot of work in the Native Memory Tracking area.
> 
> Votes are due by Thursday March 7.
> 
> Only current Members of the HotSpot Group [1] are eligible to vote on this nomination.  Votes must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> Thanks,
> /Jesper
> 
> [1] https://openjdk.org/census
> [2] https://openjdk.org/groups/#member-vote

From sspitsyn at openjdk.org  Thu Feb 22 18:53:19 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 22 Feb 2024 18:53:19 GMT
Subject: RFR: 8256314: JVM TI GetCurrentContendedMonitor is implemented
 incorrectly [v2]
In-Reply-To: <-Yf2Qj_kbyZAA-LDK96IIOcHWMh8__QT1XfnD9jR8kU=.507d5503-1544-44fb-9e81-438ba3458dcd@github.com>
References: <-Yf2Qj_kbyZAA-LDK96IIOcHWMh8__QT1XfnD9jR8kU=.507d5503-1544-44fb-9e81-438ba3458dcd@github.com>
Message-ID: <t9w1wUeWgJJ37Lx8CgIkwS4zdd8lOGmftRVBBU9wtQc=.aa9b2031-5c8b-45d2-a07f-37a4a2708ee1@github.com>

> The implementation of the JVM TI `GetCurrentContendedMonitor()` does not match the spec. It can sometimes return an incorrect information about the contended monitor. Such a behavior does not match the function spec. 
> With this update the `GetCurrentContendedMonitor()` is returning the monitor only when the specified thread is waiting to enter or re-enter the monitor, and the monitor is not returned when the specified thread is waiting in the `java.lang.Object.wait` to be notified.
> 
> The implementations of the JDWP `ThreadReference.CurrentContendedMonitor` command and JDI `ThreadReference.currentContendedMonitor()` method are based and depend on this JVMTI function. The JDWP command and the JDI method were specified incorrectly and had incorrect behavior. The fix slightly corrects both the JDWP and JDI specs. The JDWP and JDI implementations have been also fixed because they use this JVM TI update. Please, see and review the related CSR and Release-Note.
> 
> CSR: [8326024](https://bugs.openjdk.org/browse/JDK-8326024): JVM TI GetCurrentContendedMonitor is implemented incorrectly
> RN:   [8326038](https://bugs.openjdk.org/browse/JDK-8326038): Release Note: JVM TI GetCurrentContendedMonitor is implemented incorrectly
> 
> Testing:
>  - tested with the mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  fix specs: JDWP ThreadReference.CurrentContendedMonitor command, JDI ThreadReference.currentContendedMonitor method

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17944/files
  - new: https://git.openjdk.org/jdk/pull/17944/files/b8287a56..3ce67fa9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17944&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17944&range=00-01

  Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/17944.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17944/head:pull/17944

PR: https://git.openjdk.org/jdk/pull/17944

From dean.long at oracle.com  Thu Feb 22 19:31:59 2024
From: dean.long at oracle.com (dean.long at oracle.com)
Date: Thu, 22 Feb 2024 11:31:59 -0800
Subject: =?UTF-8?Q?Re=3A_CFV=3A_New_HotSpot_Group_Member=3A_Johan_Sj=C3=B6l?=
 =?UTF-8?B?w6lu?=
In-Reply-To: <041D6781-CFE6-41BD-A8F5-7E25C2EFFD52@oracle.com>
References: <041D6781-CFE6-41BD-A8F5-7E25C2EFFD52@oracle.com>
Message-ID: <b7c95621-0b8b-4c78-8520-27ff67ee40b9@oracle.com>

Vote: yes

On 2/22/24 4:14 AM, Jesper Wilhelmsson wrote:
> I hereby nominate Johan Sj?l?n (jsjolen) to Membership in the HotSpot Group.
>
> Johan is a Reviewer in the JDK project, and a member of the Oracle JVM Runtime team. Johan has done major work in the Unified Logging framework and is today the de facto owner of that area. He has done major cleanups and bug fixes throughout the JVM, and does a lot of work in the Native Memory Tracking area.
>
> Votes are due by Thursday March 7.
>
> Only current Members of the HotSpot Group [1] are eligible to vote on this nomination.  Votes must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [2].
>
> Thanks,
> /Jesper
>
> [1] https://openjdk.org/census
> [2] https://openjdk.org/groups/#member-vote

From kim.barrett at oracle.com  Thu Feb 22 20:25:49 2024
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 22 Feb 2024 20:25:49 +0000
Subject: =?utf-8?B?UmU6IENGVjogTmV3IEhvdFNwb3QgR3JvdXAgTWVtYmVyOiBKb2hhbiBTasO2?=
 =?utf-8?B?bMOpbg==?=
In-Reply-To: <041D6781-CFE6-41BD-A8F5-7E25C2EFFD52@oracle.com>
References: <041D6781-CFE6-41BD-A8F5-7E25C2EFFD52@oracle.com>
Message-ID: <C1A04750-68A6-4DBB-8953-C0D81DE8F1E3@oracle.com>

vote: yes

> On Feb 22, 2024, at 7:14 AM, Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com> wrote:
> 
> I hereby nominate Johan Sj?l?n (jsjolen) to Membership in the HotSpot Group.
> 
> Johan is a Reviewer in the JDK project, and a member of the Oracle JVM Runtime team. Johan has done major work in the Unified Logging framework and is today the de facto owner of that area. He has done major cleanups and bug fixes throughout the JVM, and does a lot of work in the Native Memory Tracking area.
> 
> Votes are due by Thursday March 7.
> 
> Only current Members of the HotSpot Group [1] are eligible to vote on this nomination.  Votes must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> Thanks,
> /Jesper
> 
> [1] https://openjdk.org/census
> [2] https://openjdk.org/groups/#member-vote


-------------- 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/20240222/2fd5e783/signature.asc>

From thomas.stuefe at gmail.com  Thu Feb 22 20:35:11 2024
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 22 Feb 2024 21:35:11 +0100
Subject: Question: 8324776: How to safely tell if MADV_POPULATE_WRITE is
 supported
In-Reply-To: <SA1PR01MB670167540DFC1BA099C8B2DA8F562@SA1PR01MB6701.prod.exchangelabs.com>
References: <CO1PR01MB6694E52F1968421CE1D8E2968F572@CO1PR01MB6694.prod.exchangelabs.com>
 <CAA-vtUwQAboHB5je940HJrsjB7ZM9ZxzEqeiwp=0xJfLcXOZvA@mail.gmail.com>
 <SA1PR01MB670167540DFC1BA099C8B2DA8F562@SA1PR01MB6701.prod.exchangelabs.com>
Message-ID: <CAA-vtUz0eMj2qOWf4rUNeJraKjp2GcR=6Kfk9hppjvKWFgJoLA@mail.gmail.com>

Hi Patrick,

So, if I understand this correctly, the Oracle kernels break binary
compatibility with mainline kernels. That's not good. Especially seeing
that you really don't want something like MADV_DOEXEC to accidentally being
enabled, especially from a security standpoint.

Funny how they just keep moving MADV_DOEXEC/DONTEXEC up to the end of the
numerical range. They quite literally just kick the can down the road :-(

I don't see a good way to solve this apart from starting to add
distro-specific recognition code, e.g. scanning for /etc/os-release, which
would be rather annoying. AFAICS, we avoided that so far.

Cheers, Thomas









On Thu, Feb 22, 2024 at 3:55?AM Patrick Zhang OS <
patrick at os.amperecomputing.com> wrote:

>
>
> >> Is this a downstream-only patch specific to the Oracle Linux kernel?
>
> Yes, I think so.
>
> At linux-uek repo [1], it says that the uek6/u2 branch is for kernel v5.4
> on Oracle Linux 7 and 8. Looking into the header file, we could see the
> definitions of 22/23, the commit is [2]. At the same time, Linux mainline?s
> max mode number was 21 and did not have 22/23. I have an attached PDF
> describing the diffs with various kernels, mainline vs uek, see [3].
>
>
>
> By the way, uek kernel v5.15 used numbers 24/25 [4] for these two
> customized modes which would generate another conflict with mainline since
> 5.18-rc1 and 6.1 where the same numbers got used. I would suggest that uek
> kernel should put customized modes into a separate range, e.g., 100+, to
> avoid conflict.
>
>
>
> [1] https://github.com/oracle/linux-uek/
>
> [2]
> https://github.com/oracle/linux-uek/commit/a91ae4fa327d8957e2f806420b8b835269b85bd4
>
> mm: introduce MADV_DOEXEC
>
> madvise MADV_DOEXEC preserves a memory range across exec.  Initially
>
> only supported for non-executable, non-stack, anonymous memory.
>
> MADV_DOEXEC is single-use and after exec madvise must done again to
>
> preserve memory for a subsequent exec.
>
> MADV_DONTEXEC reverts the effect of a previous MADV_DOEXEC call and
>
> undoes the preservation of the range.
>
>
>
> #define MADV_DOEXEC                 22                           /* do
> inherit across exec */
>
> #define MADV_DONTEXEC          23                           /* don't
> inherit across exec */
>
>
>
> [3]
> https://bugs.openjdk.org/secure/attachment/108337/madvise_return_values.pdf,
> at https://bugs.openjdk.org/browse/JDK-8324776
>
> [4]
> https://github.com/oracle/linux-uek/commit/4693c5d9d799eb4803c5afc781cc60e2b645e398
>
>
>
> Regards, Patrick
>
>
>
> *From:* Thomas St?fe <thomas.stuefe at gmail.com>
> *Sent:* Thursday, February 22, 2024 0:56
> *To:* Patrick Zhang OS <patrick at os.amperecomputing.com>
> *Cc:* hotspot-dev developers <hotspot-dev at openjdk.java.net>;
> hotspot-gc-dev at openjdk.java.net
> *Subject:* Re: Question: 8324776: How to safely tell if
> MADV_POPULATE_WRITE is supported
>
>
>
> Hi,
>
>
>
> I am trying to understand this better.
>
>
>
> MADV_POPULATE_READ and MADV_POPULATE_WRITE were added to mainline with
>
>
>
> ```
>
>  commit 4ca9b3859dac14bbef0c27d00667bb5b10917adb
>  Author: David Hildenbrand <david at redhat.com>
>  Date:   Wed Jun 30 18:52:28 2021 -0700
>      mm/madvise: introduce MADV_POPULATE_(READ|WRITE) to prefault page
> tables
>
> ```
>
>
>
> and they used 22/23 as numerical identifier:
>
>
>
> ```
>
> +#define MADV_POPULATE_READ     22      /* populate (prefault) page tables
> readable */
> +#define MADV_POPULATE_WRITE    23      /* populate (prefault) page tables
> writable */
>
> ```
>
>
>
> But I don't see a patch in mainline for MADV_DOEXEC. I do see a very
> lengthy RFR thread that seemed to end in patent disputes (?):
>
>
> https://lore.kernel.org/all/1595869887-23307-1-git-send-email-anthony.yznaga at oracle.com/T/#u
>
>
>
> Is this a downstream-only patch specific to the Oracle Linux kernel?
>
>
>
> Cheers, Thomas
>
>
>
>
>
>
>
> On Wed, Feb 21, 2024 at 4:25?PM Patrick Zhang OS <
> patrick at os.amperecomputing.com> wrote:
>
> Hi,
>
>
>
> I have a question regarding the regression reported by [1] which was
> caused by the commit [2].
>
>
>
> The root cause can be briefly described as: MADV_POPULATE_WRITE has been
> supported since Linux 5.14. It is suggested to call madvise(0, 0, advice)
> to tell if this madvise mode is valid, which ?will return zero iff advice
> is supported by the kernel and can be relied on to probe for support? [3].
> However Oracle UEKR6 5.4.17 has a duplicate definition of the number 23:
> MADV_DONTEXEC [4]. As a result, the test passes on Linux 5.4 mainline,
> while fails on UEK 5.4.17, because madvise(0, 0, 23) gives different return
> values. See details at [5].
>
>
>
> It is a dilemma that how to fix so inside JVM. Thanks for any advice.
>
>
>
> [1] https://bugs.openjdk.org/browse/JDK-8324776
> runtime/os/TestTransparentHugePageUsage.java fails with The usage of THP is
> not enough
>
> [2] https://bugs.openjdk.org/browse/JDK-8315923 pretouch_memory by
> atomic-add-0 fragments huge pages unexpectedly
>
> [3] https://www.man7.org/linux/man-pages/man2/madvise.2.html
>
> [4]
> https://yum.oracle.com/repo/OracleLinux/OL8/developer/UEKR6/aarch64/getPackageSource/kernel-uek-5.4.17-2136.327.2.el8uek.src.rpm,
> linux-5.4.17/include/uapi/asm-generic/mman-common.h#L75
>
> [5]
> https://bugs.openjdk.org/browse/JDK-8324776?focusedId=14651275&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14651275
> .
>
>
>
> Regards
>
> Patrick
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20240222/1a88cc16/attachment-0001.htm>

From mikael at openjdk.org  Thu Feb 22 20:41:55 2024
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Thu, 22 Feb 2024 20:41:55 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v5]
In-Reply-To: <4EYRe8CRYOZ6oPcfyYh1j8XHlttjZJJnO4h2qDrk5q4=.d7588fb9-2f94-458c-bfa6-c3878fec411e@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <4EYRe8CRYOZ6oPcfyYh1j8XHlttjZJJnO4h2qDrk5q4=.d7588fb9-2f94-458c-bfa6-c3878fec411e@github.com>
Message-ID: <GqHSMhaqW60MrimKY0DlSGt1Nl2B_vzPp_EjjH0T_oo=.b3d55d7b-e545-4cbf-bcd3-60b36283b878@github.com>

On Thu, 22 Feb 2024 16:15:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
>> 
>> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
>> 
>> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
>> 
>> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use #pragma instead of HIDDEN define

Not a review but I did want to mention that I proved to myself that your addition of `.hidden` for the assembly file symbols is the right thing to do. In particular, when we compile the .cpp files with the `-fvisibility=hidden` flag that's exactly what g++ does in the background.

Just a thought: Perhaps worth introducing some kind of macro that captures defining a symbol in assembly code (something that does `.globl` + `.hidden` on Linux and `.private_extern` on `__APPLE__`?

Also, separate from this change: perhaps worth turning on whitespace checking (no tabs) for .S files?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1960276436

From mli at openjdk.org  Thu Feb 22 20:54:18 2024
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 22 Feb 2024 20:54:18 GMT
Subject: RFR: 8322179: RISC-V: Implement SHA-1 intrinsic [v12]
In-Reply-To: <PyIXzENfiHysFS3IyZn3FDNQpV7Ua2L6OmjiXq9wRoU=.cf74a45e-c94b-4f7b-8768-d10d55e2ce1d@github.com>
References: <PyIXzENfiHysFS3IyZn3FDNQpV7Ua2L6OmjiXq9wRoU=.cf74a45e-c94b-4f7b-8768-d10d55e2ce1d@github.com>
Message-ID: <icvgyYZGnVSlcU8S-E5cZZ32gpetJdOygKawSx8JbDg=.dcb7ab51-d6ed-419c-b33d-1f0c13bd8ad8@github.com>

> Hi,
> Can you review this patch to implement SHA-1 intrinsic for riscv?
> Thanks!
> 
> 
> ## Test
> 
> ### Functionality
> 
> tests under `test/hotspot/jtreg/compiler/intrinsics/sha`
> tests found via `find test/jdk -iname "*SHA1*.java"`
> 
> ### Performance
> 
> tested on `T-HEAD Light Lichee Pi 4A`
> 
> JMH_PARAMS="-f 1 -wi 10 -i 20" // for every loop of jmh test
> 
> benchmark tests `MessageDigests.java GetMessageDigest.java MessageDigestBench.java MacBench.java` which are under `test/micro/org/openjdk/bench/`, more spcifically `TESTS="MessageDigests.digest MessageDigests.getAndDigest MessageDigestBench.digest"`
> 
> 
> // After
> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1        64     DEFAULT  avgt   20      1845.446 ?     27.052  ns/op
> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    181455.350 ?    532.258  ns/op
> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2447.674 ?     10.239  ns/op
> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    182896.083 ?   1242.774  ns/op
> o.o.b.javax.crypto.small.MessageDigestBench.digest         SHA1     1048576             N/A       N/A              avgt   20  11599227.792 ? 121442.390  ns/op
> // Before
> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2352.475 ?    11.198  ns/op
> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    188495.684 ?  1467.942  ns/op
> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2437.347 ?     6.398  ns/op
> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    196086.570 ?  1140.998  ns/op
> o.o.b.javax.crypto.small.MessageDigestBench.digest         SHA1     1048576             N/A       N/A              avgt   20  12362160.119 ? 38788.109  ns/op
> 
> 
> **getAndDigest when size == 64**
> The data is not stable for test getAndDigest when size == 64, which I think is introduced by  j.s.MessageDigest.getInstance itself, which we don't touch in this patch.
> Check more details at [1](https://github.com/openjdk/jdk/pull/17130#issuecomment-1886805614)
> 
> 
> loop ... ...

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  optimize code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17130/files
  - new: https://git.openjdk.org/jdk/pull/17130/files/abbf7c20..2c075a4f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17130&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17130&range=10-11

  Stats: 7 lines in 1 file changed: 0 ins; 4 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/17130.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17130/head:pull/17130

PR: https://git.openjdk.org/jdk/pull/17130

From mikael.vidstedt at oracle.com  Thu Feb 22 20:58:57 2024
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Thu, 22 Feb 2024 20:58:57 +0000
Subject: =?utf-8?B?UmU6IENGVjogTmV3IEhvdFNwb3QgR3JvdXAgTWVtYmVyOiBKb2hhbiBTasO2?=
 =?utf-8?B?bMOpbg==?=
In-Reply-To: <041D6781-CFE6-41BD-A8F5-7E25C2EFFD52@oracle.com>
References: <041D6781-CFE6-41BD-A8F5-7E25C2EFFD52@oracle.com>
Message-ID: <612E15B4-18FC-420A-873F-9AE2F4687296@oracle.com>


Vote: yes

Cheers,
Mikael

> On Feb 22, 2024, at 4:14?AM, Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com> wrote:
> 
> I hereby nominate Johan Sj?l?n (jsjolen) to Membership in the HotSpot Group.
> 
> Johan is a Reviewer in the JDK project, and a member of the Oracle JVM Runtime team. Johan has done major work in the Unified Logging framework and is today the de facto owner of that area. He has done major cleanups and bug fixes throughout the JVM, and does a lot of work in the Native Memory Tracking area.
> 
> Votes are due by Thursday March 7.
> 
> Only current Members of the HotSpot Group [1] are eligible to vote on this nomination.  Votes must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> Thanks,
> /Jesper
> 
> [1] https://openjdk.org/census
> [2] https://openjdk.org/groups/#member-vote


From ihse at openjdk.org  Thu Feb 22 21:07:04 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Feb 2024 21:07:04 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v5]
In-Reply-To: <GqHSMhaqW60MrimKY0DlSGt1Nl2B_vzPp_EjjH0T_oo=.b3d55d7b-e545-4cbf-bcd3-60b36283b878@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <4EYRe8CRYOZ6oPcfyYh1j8XHlttjZJJnO4h2qDrk5q4=.d7588fb9-2f94-458c-bfa6-c3878fec411e@github.com>
 <GqHSMhaqW60MrimKY0DlSGt1Nl2B_vzPp_EjjH0T_oo=.b3d55d7b-e545-4cbf-bcd3-60b36283b878@github.com>
Message-ID: <U9kUaw7Vtpdauxj-jFNXBNTVkbbQy2Gkh9axyk0N8cM=.2fab5edf-f63e-440b-892e-aac749600d90@github.com>

On Thu, 22 Feb 2024 20:38:42 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Just a thought: Perhaps worth introducing some kind of macro that captures defining a symbol in assembly code (something that does .globl + .hidden on Linux and .private_extern on __APPLE__?

I have thought the same. :) There seem to be room for improvement in a simple "framework" to reduce duplication across the .S files. (There is also plenty of room for improvement in coordinating the style across the .S files...) I believe one reason this has not yet happened is that up until a year or two ago, most Hotspot assembly files where .s (which are not preprocessed) as opposed to .S. I standardized on .S for all assembly code in the JDK project in JDK-8264188, and after that, the door has been open for the Hotspot developers to create such a macro.

> Also, separate from this change: perhaps worth turning on whitespace checking (no tabs) for .S files?

I'm [way ahead](https://github.com/magicus/jdk/tree/fix-jcheck-assembly-files) of you there. :) That is the next one up my pipeline in "turning on jcheck for all text files, one file type at the time". But is a chore, really, to get those kinds of fixes approved. And I wanted to get progress in the mapfile question first.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1960310460

From sviswanathan at openjdk.org  Thu Feb 22 21:26:55 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 22 Feb 2024 21:26:55 GMT
Subject: RFR: 8325991: Accelerate Poly1305 on x86_64 using AVX2
 instructions [v4]
In-Reply-To: <LLvSSnrEIYHk49CCs14ZPwXiBJYndwUwRSl6X-kajqI=.2ad38d7a-47fd-4e37-9db6-49e812ce97c5@github.com>
References: <IyoM1HY_rvNWwo4GxcV1yQleB3vrgaLwsAlOCEpLKqs=.1d50225c-8fe1-4a84-af56-274632b2b653@github.com>
 <LLvSSnrEIYHk49CCs14ZPwXiBJYndwUwRSl6X-kajqI=.2ad38d7a-47fd-4e37-9db6-49e812ce97c5@github.com>
Message-ID: <QEa_2tW2M433zv-FD5VP94g0ray-BzVLdGObOumlULA=.aa91eab7-2d6e-4e92-9230-78113b552588@github.com>

On Wed, 21 Feb 2024 05:40:13 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> The goal of this PR is to accelerate the Poly1305 algorithm using AVX2 instructions (including IFMA) for x86_64 CPUs.
>> 
>> This implementation is directly based on the AVX2 Poly1305 hash computation as implemented in Intel(R) Multi-Buffer Crypto for IPsec Library (url: https://github.com/intel/intel-ipsec-mb/blob/main/lib/avx2_t3/poly_fma_avx2.asm)
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unused uniions and fix uses_vl

src/hotspot/cpu/x86/stubGenerator_x86_64_poly.cpp line 1364:

> 1362:   __ movq(t0, length);
> 1363:   __ mov64(t1, 0xffffffffffffffc0);
> 1364:   __ andq(t0, t1);

We could directly  do andq(t0, 0xffffffc0) here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17881#discussion_r1499839228

From amenkov at openjdk.org  Thu Feb 22 21:43:23 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 22 Feb 2024 21:43:23 GMT
Subject: RFR: JDK-8325530: Vague error message when
 com.sun.tools.attach.VirtualMachine fails to load agent library [v3]
In-Reply-To: <s1rZKr_Bt8tzCP2cMyFv0oe7pTD1DNzGLaIsGZdXffY=.596d50f2-12b6-4bba-ab30-a26b697fb970@github.com>
References: <s1rZKr_Bt8tzCP2cMyFv0oe7pTD1DNzGLaIsGZdXffY=.596d50f2-12b6-4bba-ab30-a26b697fb970@github.com>
Message-ID: <T2Tn-S9_Edj8reggmh3RF4YGU3Lqq-FuHx9XZSpzPbk=.952cda7b-e160-476d-8871-59961df46fce@github.com>

> VirtualMachine.loadAgentPath/loadAgentLibrary can fail with AgentLoadException in 2 cases:
> - attach listener returns error; in the case the exception is thrown from HotSpotVirtualMachine.processCompletionStatus (called from HotSpotVirtualMachine.execute);
> - attach listener returns success, but reply does not contain Agent_onAttach return code ("return code: %d" message).
> 
> before jdk21 if attach listener fails to load required library, it returned error (case 1)
> from jdk21 attach listener always returns success (case 2)
> Both cases are ok, but for 2nd case HotSpotVirtualMachine.loadAgentLibrary read only single line of the response message, so exception message didn't contain error details.
> 
> The fix updates HotSpotVirtualMachine.loadAgentLibrary to read the whole response message.
> Walking through the code, fixed some other minor things in attach listener and attach API implementation (commented in the code)
> 
> Testing:
>   - test/jdk/com/sun/tools;
>   - tier1,tier2,tier5-svc

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17954/files
  - new: https://git.openjdk.org/jdk/pull/17954/files/0304bae2..dcb1db0d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17954&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17954&range=01-02

  Stats: 5 lines in 1 file changed: 1 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/17954.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17954/head:pull/17954

PR: https://git.openjdk.org/jdk/pull/17954

From calvin.cheung at oracle.com  Thu Feb 22 21:52:47 2024
From: calvin.cheung at oracle.com (Calvin Cheung)
Date: Thu, 22 Feb 2024 13:52:47 -0800
Subject: =?UTF-8?Q?Re=3A_CFV=3A_New_HotSpot_Group_Member=3A_Johan_Sj=C3=B6l?=
 =?UTF-8?B?w6lu?=
In-Reply-To: <041D6781-CFE6-41BD-A8F5-7E25C2EFFD52@oracle.com>
References: <041D6781-CFE6-41BD-A8F5-7E25C2EFFD52@oracle.com>
Message-ID: <6b3f9c95-6f31-4b56-a652-dfd3349a2483@oracle.com>

 ??? Vote: yes

On 2/22/24 4:14 AM, Jesper Wilhelmsson wrote:
> I hereby nominate Johan Sj?l?n (jsjolen) to Membership in the HotSpot Group.
>
> Johan is a Reviewer in the JDK project, and a member of the Oracle JVM Runtime team. Johan has done major work in the Unified Logging framework and is today the de facto owner of that area. He has done major cleanups and bug fixes throughout the JVM, and does a lot of work in the Native Memory Tracking area.
>
> Votes are due by Thursday March 7.
>
> Only current Members of the HotSpot Group [1] are eligible to vote on this nomination.  Votes must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [2].
>
> Thanks,
> /Jesper
>
> [1] https://openjdk.org/census
> [2] https://openjdk.org/groups/#member-vote

From dholmes at openjdk.org  Thu Feb 22 22:21:53 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 22 Feb 2024 22:21:53 GMT
Subject: RFR: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234
In-Reply-To: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
References: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
Message-ID: <TYE1ieXypz7WiaTQRwU3Zp-ICrZ2E4SIo4meD-h14LU=.884eb3e0-04e2-4728-bfc5-57b072e809bf@github.com>

On Thu, 22 Feb 2024 16:28:20 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) has been integrated, it is possible to do some cleanup. The goal of [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) was to not change any behavior, even if that behavior seemed odd.
> 
> Now let's try to fix that. We can:
> 
> a) remove JNIEXPORT from c2v functions.
> b) make debug.cpp functions exported similarly on all platforms.
> c) remove JNIEXPORT from aarch64 asm debug function.
> 
> Note that this PR is [dependent on](https://mail.openjdk.org/pipermail/jdk-dev/2021-March/005232.html) https://github.com/openjdk/jdk/pull/17955.

src/hotspot/cpu/aarch64/assembler_aarch64.cpp line 122:

> 120:   }
> 121: 
> 122:   void das1(uintptr_t insn) {

Doesn't this need to be exported for debugging on Windows-Aarch64?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17967#discussion_r1500001316

From dholmes at openjdk.org  Thu Feb 22 22:22:54 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 22 Feb 2024 22:22:54 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <-pzo3-C5dN9IRd4dv7k_j8E0i7jR578u1gst0U6iAFI=.34ce218c-3d3f-409a-9c60-315eaab370fa@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <g0ZVkeeR7P1e4_8Z0-nQ8at63jrtZySDk8bKtub0mLw=.db5e4e9c-9ca6-4d5a-b31b-17f84981e14f@github.com>
 <Cd8440seSvfWXHBcZ8cx5K1qWcpf-qyET1IdFY8eWUo=.a64a2d4c-bd34-49fb-9167-8e4583add959@github.com>
 <-pzo3-C5dN9IRd4dv7k_j8E0i7jR578u1gst0U6iAFI=.34ce218c-3d3f-409a-9c60-315eaab370fa@github.com>
Message-ID: <oNoc9WvyhmiWPyT54itZtCrX9AIB3A99b3L8jfUcZCA=.f208e657-a6b5-4b38-92ea-022dbaba7c52@github.com>

On Thu, 22 Feb 2024 09:26:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I tried to be clear, but apparently I failed: There is no change to these symbols in the patch! So everything should work just as before!

Yes but "should work" and "does work" may not be the same unless you have actually verified the functionality. That said I now see that we only actually need to export on Windows for the debugging functions to work, so I agree everything should work just fine in that regard.

Apologies - It took me a little while to click to the fact not all JNIEXPORT symbols were actually being exported due to their omission in the mapfile - hence the need to now actually hide them to keep things working the same. (FWIW I don't think it matters if we export the debug functions unnecessarily on some platforms - I'd go for code simplicity/consistency. EDIT and I see you went that way too.)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1960416613

From dholmes at openjdk.org  Thu Feb 22 22:25:54 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 22 Feb 2024 22:25:54 GMT
Subject: RFR: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234
In-Reply-To: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
References: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
Message-ID: <1qV4pOnr-4-d-Z_dFPFJ_sPN06vWCfE4yjRjHaLYsgA=.4f20d03f-92cd-46be-b224-f9d5c50aa3a1@github.com>

On Thu, 22 Feb 2024 16:28:20 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) has been integrated, it is possible to do some cleanup. The goal of [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) was to not change any behavior, even if that behavior seemed odd.
> 
> Now let's try to fix that. We can:
> 
> a) remove JNIEXPORT from c2v functions.
> b) make debug.cpp functions exported similarly on all platforms.
> c) remove JNIEXPORT from aarch64 asm debug function.
> 
> Note that this PR is [dependent on](https://mail.openjdk.org/pipermail/jdk-dev/2021-March/005232.html) https://github.com/openjdk/jdk/pull/17955.

With the one exception above I agree with these choices going forward. I don't think it matters that exporting for the debugger is not actually necessary on some platforms, and so code simplicity wins out for me. That said the litmus test will be whether hermetic Java encounters any conflicts.

Thanks

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17967#issuecomment-1960427179

From cjplummer at openjdk.org  Thu Feb 22 22:29:58 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 22 Feb 2024 22:29:58 GMT
Subject: RFR: JDK-8325530: Vague error message when
 com.sun.tools.attach.VirtualMachine fails to load agent library [v3]
In-Reply-To: <T2Tn-S9_Edj8reggmh3RF4YGU3Lqq-FuHx9XZSpzPbk=.952cda7b-e160-476d-8871-59961df46fce@github.com>
References: <s1rZKr_Bt8tzCP2cMyFv0oe7pTD1DNzGLaIsGZdXffY=.596d50f2-12b6-4bba-ab30-a26b697fb970@github.com>
 <T2Tn-S9_Edj8reggmh3RF4YGU3Lqq-FuHx9XZSpzPbk=.952cda7b-e160-476d-8871-59961df46fce@github.com>
Message-ID: <OSSDb1v9NhZEXcFSgIwnd2WMy-lQPBZiNeIjWHzbRzE=.33841dd7-1cf2-4818-8dcc-0701025eba54@github.com>

On Thu, 22 Feb 2024 21:43:23 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> VirtualMachine.loadAgentPath/loadAgentLibrary can fail with AgentLoadException in 2 cases:
>> - attach listener returns error; in the case the exception is thrown from HotSpotVirtualMachine.processCompletionStatus (called from HotSpotVirtualMachine.execute);
>> - attach listener returns success, but reply does not contain Agent_onAttach return code ("return code: %d" message).
>> 
>> before jdk21 if attach listener fails to load required library, it returned error (case 1)
>> from jdk21 attach listener always returns success (case 2)
>> Both cases are ok, but for 2nd case HotSpotVirtualMachine.loadAgentLibrary read only single line of the response message, so exception message didn't contain error details.
>> 
>> The fix updates HotSpotVirtualMachine.loadAgentLibrary to read the whole response message.
>> Walking through the code, fixed some other minor things in attach listener and attach API implementation (commented in the code)
>> 
>> Testing:
>>   - test/jdk/com/sun/tools;
>>   - tier1,tier2,tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback

In invoke_Agent_OnAttach(), I think the second print_cr() should start with a space:


      st->print_cr("%s was not loaded.", agent->name());
      if (*ebuf != '\0') {
        st->print_cr("%s", &ebuf[0]);
      }
      return false;


Otherwise in the output you see the reason for the failure start right after the period:

`com.sun.tools.attach.AgentLoadException: Failed to load agent library: FailedLoadAgentTestNotExists was not loaded.libFailedLoadAgentTestNotExists.so: cannot open shared object file: No such file or directory`

Also, ebuf is of size 1024 and is getting truncated sometimes. See your macosx log files on mdash. This doesn't necessarily have to be fixed, but something to consider.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17954#issuecomment-1960431370

From amenkov at openjdk.org  Thu Feb 22 23:27:54 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 22 Feb 2024 23:27:54 GMT
Subject: RFR: JDK-8325530: Vague error message when
 com.sun.tools.attach.VirtualMachine fails to load agent library [v3]
In-Reply-To: <OSSDb1v9NhZEXcFSgIwnd2WMy-lQPBZiNeIjWHzbRzE=.33841dd7-1cf2-4818-8dcc-0701025eba54@github.com>
References: <s1rZKr_Bt8tzCP2cMyFv0oe7pTD1DNzGLaIsGZdXffY=.596d50f2-12b6-4bba-ab30-a26b697fb970@github.com>
 <T2Tn-S9_Edj8reggmh3RF4YGU3Lqq-FuHx9XZSpzPbk=.952cda7b-e160-476d-8871-59961df46fce@github.com>
 <OSSDb1v9NhZEXcFSgIwnd2WMy-lQPBZiNeIjWHzbRzE=.33841dd7-1cf2-4818-8dcc-0701025eba54@github.com>
Message-ID: <L3uzLUl9EpgHMGPoQrXImW3UXX0CVb1QXuUaOvW0vEo=.695414d9-9c15-42bf-a1bc-d839e1c7cf45@github.com>

On Thu, 22 Feb 2024 22:27:04 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> In invoke_Agent_OnAttach(), I think the second print_cr() should start with a space:
> 
> ```
>       st->print_cr("%s was not loaded.", agent->name());
>       if (*ebuf != '\0') {
>         st->print_cr("%s", &ebuf[0]);
>       }
>       return false;
> ```
> 
> Otherwise in the output you see the reason for the failure start right after the period:
> 
> `com.sun.tools.attach.AgentLoadException: Failed to load agent library: FailedLoadAgentTestNotExists was not loaded.libFailedLoadAgentTestNotExists.so: cannot open shared object file: No such file or directory`

It may be other messages in the outputStream (like "Dynamic agent loading is not enabled.")
So I think it should be fixed in HotSpotVirtualMachine.readErrorMessage (it converts multi-line message to single string) by replacing CRs with spaces.

> 
> Also, ebuf is of size 1024 and is getting truncated sometimes. See your macosx log files on mdash. This doesn't necessarily have to be fixed, but something to consider.

I'll file a separate issue for this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17954#issuecomment-1960504459

From amenkov at openjdk.org  Thu Feb 22 23:31:16 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 22 Feb 2024 23:31:16 GMT
Subject: RFR: JDK-8325530: Vague error message when
 com.sun.tools.attach.VirtualMachine fails to load agent library [v4]
In-Reply-To: <s1rZKr_Bt8tzCP2cMyFv0oe7pTD1DNzGLaIsGZdXffY=.596d50f2-12b6-4bba-ab30-a26b697fb970@github.com>
References: <s1rZKr_Bt8tzCP2cMyFv0oe7pTD1DNzGLaIsGZdXffY=.596d50f2-12b6-4bba-ab30-a26b697fb970@github.com>
Message-ID: <BP-HsRnMDXD_m6sqmQMAdXOvQTCDFJ3SJ24pEXD8LzI=.6f4a2992-c6a5-497b-b0e8-2458513fc2cf@github.com>

> VirtualMachine.loadAgentPath/loadAgentLibrary can fail with AgentLoadException in 2 cases:
> - attach listener returns error; in the case the exception is thrown from HotSpotVirtualMachine.processCompletionStatus (called from HotSpotVirtualMachine.execute);
> - attach listener returns success, but reply does not contain Agent_onAttach return code ("return code: %d" message).
> 
> before jdk21 if attach listener fails to load required library, it returned error (case 1)
> from jdk21 attach listener always returns success (case 2)
> Both cases are ok, but for 2nd case HotSpotVirtualMachine.loadAgentLibrary read only single line of the response message, so exception message didn't contain error details.
> 
> The fix updates HotSpotVirtualMachine.loadAgentLibrary to read the whole response message.
> Walking through the code, fixed some other minor things in attach listener and attach API implementation (commented in the code)
> 
> Testing:
>   - test/jdk/com/sun/tools;
>   - tier1,tier2,tier5-svc

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  Fixed readErrorMessage()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17954/files
  - new: https://git.openjdk.org/jdk/pull/17954/files/dcb1db0d..66b24479

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17954&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17954&range=02-03

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17954.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17954/head:pull/17954

PR: https://git.openjdk.org/jdk/pull/17954

From sviswanathan at openjdk.org  Thu Feb 22 23:58:55 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 22 Feb 2024 23:58:55 GMT
Subject: RFR: 8325991: Accelerate Poly1305 on x86_64 using AVX2
 instructions [v4]
In-Reply-To: <LLvSSnrEIYHk49CCs14ZPwXiBJYndwUwRSl6X-kajqI=.2ad38d7a-47fd-4e37-9db6-49e812ce97c5@github.com>
References: <IyoM1HY_rvNWwo4GxcV1yQleB3vrgaLwsAlOCEpLKqs=.1d50225c-8fe1-4a84-af56-274632b2b653@github.com>
 <LLvSSnrEIYHk49CCs14ZPwXiBJYndwUwRSl6X-kajqI=.2ad38d7a-47fd-4e37-9db6-49e812ce97c5@github.com>
Message-ID: <gMijC2Y9pJNAg-yyTilMn1PjlQOiDufE5WXFhlCshpM=.3e712c88-11da-4ed2-92db-27c4ff2a4b7e@github.com>

On Wed, 21 Feb 2024 05:40:13 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> The goal of this PR is to accelerate the Poly1305 algorithm using AVX2 instructions (including IFMA) for x86_64 CPUs.
>> 
>> This implementation is directly based on the AVX2 Poly1305 hash computation as implemented in Intel(R) Multi-Buffer Crypto for IPsec Library (url: https://github.com/intel/intel-ipsec-mb/blob/main/lib/avx2_t3/poly_fma_avx2.asm)
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unused uniions and fix uses_vl

src/hotspot/cpu/x86/assembler_x86.cpp line 5195:

> 5193:   assert(VM_Version::supports_avxifma() && (vector_len == AVX_128bit || vector_len == AVX_256bit), "");
> 5194:   InstructionMark im(this);
> 5195:   InstructionAttr attributes(vector_len, /* rex_w */ true, /* legacy_mode */ false, /* no_mask_reg */ false, /* uses_vl */ false);

uses_vl should be true for all vpmadd52 instructions. 
The assert could be coded as:
assert(vector_len == AVX_512bit ? VM_Version::supports_evex() : VM_Version::supports_avxifma(), "");

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17881#discussion_r1500080836

From sviswanathan at openjdk.org  Fri Feb 23 00:04:55 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 23 Feb 2024 00:04:55 GMT
Subject: RFR: 8325991: Accelerate Poly1305 on x86_64 using AVX2
 instructions [v4]
In-Reply-To: <LLvSSnrEIYHk49CCs14ZPwXiBJYndwUwRSl6X-kajqI=.2ad38d7a-47fd-4e37-9db6-49e812ce97c5@github.com>
References: <IyoM1HY_rvNWwo4GxcV1yQleB3vrgaLwsAlOCEpLKqs=.1d50225c-8fe1-4a84-af56-274632b2b653@github.com>
 <LLvSSnrEIYHk49CCs14ZPwXiBJYndwUwRSl6X-kajqI=.2ad38d7a-47fd-4e37-9db6-49e812ce97c5@github.com>
Message-ID: <wP3cbRklxCrA3vjMC1Fr4FZnSDwQ8Q9sO6GwVPCtXdw=.59849e5a-39ca-402f-802c-b4a4ad122230@github.com>

On Wed, 21 Feb 2024 05:40:13 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> The goal of this PR is to accelerate the Poly1305 algorithm using AVX2 instructions (including IFMA) for x86_64 CPUs.
>> 
>> This implementation is directly based on the AVX2 Poly1305 hash computation as implemented in Intel(R) Multi-Buffer Crypto for IPsec Library (url: https://github.com/intel/intel-ipsec-mb/blob/main/lib/avx2_t3/poly_fma_avx2.asm)
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unused uniions and fix uses_vl

src/hotspot/cpu/x86/vm_version_x86.cpp line 1360:

> 1358: 
> 1359: #ifdef _LP64
> 1360:   if ((supports_avx512ifma() && supports_avx512vlbw() && MaxVectorSize >= 64) || (supports_avxifma() && MaxVectorSize >= 32))  {

This could be:
if ((supports_avx512ifma() && supports_avx512vlbw()) || (supports_avxifma()))  {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17881#discussion_r1500084463

From sviswanathan at openjdk.org  Fri Feb 23 00:08:55 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 23 Feb 2024 00:08:55 GMT
Subject: RFR: 8325991: Accelerate Poly1305 on x86_64 using AVX2
 instructions [v4]
In-Reply-To: <LLvSSnrEIYHk49CCs14ZPwXiBJYndwUwRSl6X-kajqI=.2ad38d7a-47fd-4e37-9db6-49e812ce97c5@github.com>
References: <IyoM1HY_rvNWwo4GxcV1yQleB3vrgaLwsAlOCEpLKqs=.1d50225c-8fe1-4a84-af56-274632b2b653@github.com>
 <LLvSSnrEIYHk49CCs14ZPwXiBJYndwUwRSl6X-kajqI=.2ad38d7a-47fd-4e37-9db6-49e812ce97c5@github.com>
Message-ID: <CSR2pFjPhmJA_7LmvdETc8EZY2w2OBp9j0endV72HHE=.b7818181-cc5c-40ed-9cec-1d206223d8da@github.com>

On Wed, 21 Feb 2024 05:40:13 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> The goal of this PR is to accelerate the Poly1305 algorithm using AVX2 instructions (including IFMA) for x86_64 CPUs.
>> 
>> This implementation is directly based on the AVX2 Poly1305 hash computation as implemented in Intel(R) Multi-Buffer Crypto for IPsec Library (url: https://github.com/intel/intel-ipsec-mb/blob/main/lib/avx2_t3/poly_fma_avx2.asm)
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unused uniions and fix uses_vl

You will also need to update the test/lib-test/jdk/test/whitebox/CPUInfoTest.java to handle avx_ifma.
Rest of the PR looks good to me.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17881#issuecomment-1960540531

From amenkov at openjdk.org  Fri Feb 23 01:32:54 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 23 Feb 2024 01:32:54 GMT
Subject: RFR: JDK-8325530: Vague error message when
 com.sun.tools.attach.VirtualMachine fails to load agent library [v3]
In-Reply-To: <L3uzLUl9EpgHMGPoQrXImW3UXX0CVb1QXuUaOvW0vEo=.695414d9-9c15-42bf-a1bc-d839e1c7cf45@github.com>
References: <s1rZKr_Bt8tzCP2cMyFv0oe7pTD1DNzGLaIsGZdXffY=.596d50f2-12b6-4bba-ab30-a26b697fb970@github.com>
 <T2Tn-S9_Edj8reggmh3RF4YGU3Lqq-FuHx9XZSpzPbk=.952cda7b-e160-476d-8871-59961df46fce@github.com>
 <OSSDb1v9NhZEXcFSgIwnd2WMy-lQPBZiNeIjWHzbRzE=.33841dd7-1cf2-4818-8dcc-0701025eba54@github.com>
 <L3uzLUl9EpgHMGPoQrXImW3UXX0CVb1QXuUaOvW0vEo=.695414d9-9c15-42bf-a1bc-d839e1c7cf45@github.com>
Message-ID: <YfAZppfLM4Ce-1K9YtmpQ9GEva24R15TVn43Fnp9mSg=.bdaaaf6d-4df4-4ad1-9541-b0f266f6beb0@github.com>

On Thu, 22 Feb 2024 23:25:06 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Also, ebuf is of size 1024 and is getting truncated sometimes. See your macosx log files on mdash. This doesn't necessarily have to be fixed, but something to consider.

All other callers of os::dll_load() also use buffer of 1024 chars.
Looks like dlerror() on macosx is very verbose.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17954#issuecomment-1960613948

From duke at openjdk.org  Fri Feb 23 01:43:08 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Fri, 23 Feb 2024 01:43:08 GMT
Subject: RFR: 8325991: Accelerate Poly1305 on x86_64 using AVX2
 instructions [v5]
In-Reply-To: <IyoM1HY_rvNWwo4GxcV1yQleB3vrgaLwsAlOCEpLKqs=.1d50225c-8fe1-4a84-af56-274632b2b653@github.com>
References: <IyoM1HY_rvNWwo4GxcV1yQleB3vrgaLwsAlOCEpLKqs=.1d50225c-8fe1-4a84-af56-274632b2b653@github.com>
Message-ID: <d_t3I4OB7zai-fzDoDbKk5IaDXarhCTRKnKQepwE3w8=.7c4cf857-4241-439c-93e1-48b8abca2ea9@github.com>

> The goal of this PR is to accelerate the Poly1305 algorithm using AVX2 instructions (including IFMA) for x86_64 CPUs.
> 
> This implementation is directly based on the AVX2 Poly1305 hash computation as implemented in Intel(R) Multi-Buffer Crypto for IPsec Library (url: https://github.com/intel/intel-ipsec-mb/blob/main/lib/avx2_t3/poly_fma_avx2.asm)

Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:

  removed unused merge, faster and, redundant mov

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17881/files
  - new: https://git.openjdk.org/jdk/pull/17881/files/f1b18567..a981c1dd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17881&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17881&range=03-04

  Stats: 24 lines in 3 files changed: 0 ins; 23 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17881.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17881/head:pull/17881

PR: https://git.openjdk.org/jdk/pull/17881

From duke at openjdk.org  Fri Feb 23 01:43:08 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Fri, 23 Feb 2024 01:43:08 GMT
Subject: RFR: 8325991: Accelerate Poly1305 on x86_64 using AVX2
 instructions [v4]
In-Reply-To: <pfpRvKzkyOUQ1GYYtHNgqJcHmkT_ei28ZQZKVgZeCBU=.e0250c7b-f8c9-47fb-99f3-ca8504e36578@github.com>
References: <IyoM1HY_rvNWwo4GxcV1yQleB3vrgaLwsAlOCEpLKqs=.1d50225c-8fe1-4a84-af56-274632b2b653@github.com>
 <LLvSSnrEIYHk49CCs14ZPwXiBJYndwUwRSl6X-kajqI=.2ad38d7a-47fd-4e37-9db6-49e812ce97c5@github.com>
 <pfpRvKzkyOUQ1GYYtHNgqJcHmkT_ei28ZQZKVgZeCBU=.e0250c7b-f8c9-47fb-99f3-ca8504e36578@github.com>
Message-ID: <wUaMtQp_HMwh-CYwtqQS3Vla80HN1dzHOEoY44jJ0-8=.70e4e1a1-4707-465c-b11a-b54e06121b57@github.com>

On Thu, 22 Feb 2024 01:21:30 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove unused uniions and fix uses_vl
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_poly.cpp line 1252:
> 
>> 1250: 
>> 1251:   // Calculate R^2
>> 1252:   __ movq(t0, c1); // c1 = R1 + (R1 >> 2)
> 
> This move is not required. Function poly1305_multiply_scalar() is not using t0.

Please see the redundant mov removed.

> src/hotspot/cpu/x86/stubGenerator_x86_64_poly.cpp line 1364:
> 
>> 1362:   __ movq(t0, length);
>> 1363:   __ mov64(t1, 0xffffffffffffffc0);
>> 1364:   __ andq(t0, t1);
> 
> We could directly  do andq(t0, 0xffffffc0) here?

Please see the code updated to andq(t0, 0xffffffc0)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17881#discussion_r1500138535
PR Review Comment: https://git.openjdk.org/jdk/pull/17881#discussion_r1500137672

From duke at openjdk.org  Fri Feb 23 02:33:07 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Fri, 23 Feb 2024 02:33:07 GMT
Subject: RFR: 8325991: Accelerate Poly1305 on x86_64 using AVX2
 instructions [v6]
In-Reply-To: <IyoM1HY_rvNWwo4GxcV1yQleB3vrgaLwsAlOCEpLKqs=.1d50225c-8fe1-4a84-af56-274632b2b653@github.com>
References: <IyoM1HY_rvNWwo4GxcV1yQleB3vrgaLwsAlOCEpLKqs=.1d50225c-8fe1-4a84-af56-274632b2b653@github.com>
Message-ID: <Wi_daJyOQxd93_AYYoF0OPDoFN-mKaHEHzO3lZo04fY=.62bbb36c-f282-490a-87ba-5b3b2df1db17@github.com>

> The goal of this PR is to accelerate the Poly1305 algorithm using AVX2 instructions (including IFMA) for x86_64 CPUs.
> 
> This implementation is directly based on the AVX2 Poly1305 hash computation as implemented in Intel(R) Multi-Buffer Crypto for IPsec Library (url: https://github.com/intel/intel-ipsec-mb/blob/main/lib/avx2_t3/poly_fma_avx2.asm)

Srinivas Vamsi Parasa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:

 - fix merge issues with avx_ifma
 - Merge branch 'master' of https://git.openjdk.java.net/jdk into jdk_poly
 - removed unused merge, faster and, redundant mov
 - remove unused uniions and fix uses_vl
 - change overloaded C to use COEFF
 - update algo writeup for clarity
 - 8325991: Accelerate Poly1305 on x86_64 using AVX2 instructions
 - fix typos in algorithm
 - add pseudo code algorithm
 - remove comment
 - ... and 10 more: https://git.openjdk.org/jdk/compare/54f09d73...d16a3b0b

-------------

Changes: https://git.openjdk.org/jdk/pull/17881/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17881&range=05
  Stats: 804 lines in 8 files changed: 795 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/17881.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17881/head:pull/17881

PR: https://git.openjdk.org/jdk/pull/17881

From duke at openjdk.org  Fri Feb 23 02:50:04 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Fri, 23 Feb 2024 02:50:04 GMT
Subject: RFR: 8325991: Accelerate Poly1305 on x86_64 using AVX2
 instructions [v7]
In-Reply-To: <IyoM1HY_rvNWwo4GxcV1yQleB3vrgaLwsAlOCEpLKqs=.1d50225c-8fe1-4a84-af56-274632b2b653@github.com>
References: <IyoM1HY_rvNWwo4GxcV1yQleB3vrgaLwsAlOCEpLKqs=.1d50225c-8fe1-4a84-af56-274632b2b653@github.com>
Message-ID: <j_MMVUznSiOuz4E5HQ4Ue5hbxrWmFasknyyKvYeLydQ=.5472e269-b151-4267-9a7b-6641797d42ed@github.com>

> The goal of this PR is to accelerate the Poly1305 algorithm using AVX2 instructions (including IFMA) for x86_64 CPUs.
> 
> This implementation is directly based on the AVX2 Poly1305 hash computation as implemented in Intel(R) Multi-Buffer Crypto for IPsec Library (url: https://github.com/intel/intel-ipsec-mb/blob/main/lib/avx2_t3/poly_fma_avx2.asm)

Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:

  fix use_vl to true for vpmadd52* instrs

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17881/files
  - new: https://git.openjdk.org/jdk/pull/17881/files/d16a3b0b..dddeb6fb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17881&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17881&range=05-06

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/17881.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17881/head:pull/17881

PR: https://git.openjdk.org/jdk/pull/17881

From dlong at openjdk.org  Fri Feb 23 03:14:54 2024
From: dlong at openjdk.org (Dean Long)
Date: Fri, 23 Feb 2024 03:14:54 GMT
Subject: RFR: 8324833: Signed integer overflows in ABS [v5]
In-Reply-To: <nqH9XVyMCcY0GPMWrCVgWT47TcE9tYo57sbv9V_EX6Y=.859fc693-23fd-4a6e-abf9-ba1f6f4bb9b5@github.com>
References: <ohwAn6GqM7FIgYTJNy40VBYSCVEBrrNSqBaz2akN54M=.f9660235-3047-47ee-aad0-ef598d6ebdcc@github.com>
 <keBLe_kqh25x7IdMWimvIQshpubvKZrP0KPf4Lphoy4=.447c2d2e-3c08-4d85-a9c3-3bd356cfc8a4@github.com>
 <r4Fyb__l1HBZZSIcLlGuRNA8ZDy7h67rOyCVkU23uZg=.b03dbedc-01bb-4e92-8f98-ebf40d51937d@github.com>
 <nqH9XVyMCcY0GPMWrCVgWT47TcE9tYo57sbv9V_EX6Y=.859fc693-23fd-4a6e-abf9-ba1f6f4bb9b5@github.com>
Message-ID: <F6207mUfepV67NsPVWIuKnTaGzogjfJPl688kWZEoaA=.99412a42-c4c1-4826-9912-ceb9bf3275b3@github.com>

On Fri, 2 Feb 2024 09:44:00 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 1054:
>> 
>>> 1052:     int64_t off_low = (int64_t)target_addr - ((int64_t)CodeCache::low_bound() + sizeof(int));
>>> 1053:     int64_t off_high = (int64_t)target_addr - ((int64_t)CodeCache::high_bound() + sizeof(int));
>>> 1054:     return MAX2(ABS(off_low), ABS(off_high));
>> 
>> Wouldn't this trigger a warning with -Wsign-conversion enabled?
>
> Maybe? I added `checked_cast` in this place in new commit.

checked_cast isn't really helping here.  It doesn't work when the input is the same size as the output.  We need a better way to check for bad input or bad outputs.  I suggested before doing those checks in the abs/ABS implementation, but we could also have something like u2i() (or u2s?) for unsigned to signed conversions instead of checked_cast.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17617#discussion_r1500172936

From dlong at openjdk.org  Fri Feb 23 03:27:56 2024
From: dlong at openjdk.org (Dean Long)
Date: Fri, 23 Feb 2024 03:27:56 GMT
Subject: RFR: 8324833: Signed integer overflows in ABS [v5]
In-Reply-To: <mAJDTIVvBG-4AX5TX7ucgVzlGZ7g4dtVB0Lk0EZjNWM=.84424e17-99b7-47be-bab0-0f5b7701755d@github.com>
References: <ohwAn6GqM7FIgYTJNy40VBYSCVEBrrNSqBaz2akN54M=.f9660235-3047-47ee-aad0-ef598d6ebdcc@github.com>
 <mAJDTIVvBG-4AX5TX7ucgVzlGZ7g4dtVB0Lk0EZjNWM=.84424e17-99b7-47be-bab0-0f5b7701755d@github.com>
Message-ID: <RBa4Zei69007HIIq6j9XENulZYK_GMkTUr5ySZRbx1o=.236d2a9f-81e0-4d95-9cd8-c7f04e723dce@github.com>

On Thu, 22 Feb 2024 08:53:24 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the details in the bug. I think current `ABS` implementation is beyond repair, and we should just switch to `uabs`.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug, `all` with `-ftrapv` (now fully passes!)
>>  - [x] Linux x86_64 fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix a place where we cast to jlong after uabs

src/hotspot/share/opto/loopnode.cpp line 805:

> 803:   // overflow: max_jint - stride_con max. -1 so there's no need for a
> 804:   // loop limit check if the exit test is <= or >=.
> 805:   int iters_limit = max_jint - uabs(stride_con) - 1;

It appears iters_limit can become -1 or -2 here, depending on the value of stride_con.  See below for the problem.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17617#discussion_r1500178001

From dlong at openjdk.org  Fri Feb 23 03:37:55 2024
From: dlong at openjdk.org (Dean Long)
Date: Fri, 23 Feb 2024 03:37:55 GMT
Subject: RFR: 8324833: Signed integer overflows in ABS [v5]
In-Reply-To: <mAJDTIVvBG-4AX5TX7ucgVzlGZ7g4dtVB0Lk0EZjNWM=.84424e17-99b7-47be-bab0-0f5b7701755d@github.com>
References: <ohwAn6GqM7FIgYTJNy40VBYSCVEBrrNSqBaz2akN54M=.f9660235-3047-47ee-aad0-ef598d6ebdcc@github.com>
 <mAJDTIVvBG-4AX5TX7ucgVzlGZ7g4dtVB0Lk0EZjNWM=.84424e17-99b7-47be-bab0-0f5b7701755d@github.com>
Message-ID: <hMh6OmDJ9sKZR8-YLSDOoKyvh8Sj9m3WLfnm_nijQqw=.60fea9a7-686b-4d5e-82d6-df8db805b5b4@github.com>

On Thu, 22 Feb 2024 08:53:24 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the details in the bug. I think current `ABS` implementation is beyond repair, and we should just switch to `uabs`.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug, `all` with `-ftrapv` (now fully passes!)
>>  - [x] Linux x86_64 fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix a place where we cast to jlong after uabs

src/hotspot/share/opto/loopnode.cpp line 812:

> 810: #endif
> 811:   // At least 2 iterations so counted loop construction doesn't fail
> 812:   if (iters_limit/uabs(stride_con) < 2) {

Previously negative values of iters_limit would cause us to return false here.  Now the comparison is unsigned, so we can get a different result:
stride_con is max_jint
iters_limit is -1
(unsigned) -1 / max_jint is 2
so we no longer return false here.
Using uabs with signed values is error-prone.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17617#discussion_r1500181710

From dlong at openjdk.org  Fri Feb 23 03:49:58 2024
From: dlong at openjdk.org (Dean Long)
Date: Fri, 23 Feb 2024 03:49:58 GMT
Subject: RFR: 8324833: Signed integer overflows in ABS [v5]
In-Reply-To: <mAJDTIVvBG-4AX5TX7ucgVzlGZ7g4dtVB0Lk0EZjNWM=.84424e17-99b7-47be-bab0-0f5b7701755d@github.com>
References: <ohwAn6GqM7FIgYTJNy40VBYSCVEBrrNSqBaz2akN54M=.f9660235-3047-47ee-aad0-ef598d6ebdcc@github.com>
 <mAJDTIVvBG-4AX5TX7ucgVzlGZ7g4dtVB0Lk0EZjNWM=.84424e17-99b7-47be-bab0-0f5b7701755d@github.com>
Message-ID: <S3X1_bH64u_4vfI2nib0DAnjQI4cr71QoQdDaty94fI=.47b6ef30-0577-4795-bf90-f07cea790658@github.com>

On Thu, 22 Feb 2024 08:53:24 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the details in the bug. I think current `ABS` implementation is beyond repair, and we should just switch to `uabs`.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug, `all` with `-ftrapv` (now fully passes!)
>>  - [x] Linux x86_64 fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix a place where we cast to jlong after uabs

src/hotspot/share/opto/loopnode.cpp line 1110:

> 1108:             loop->is_invariant(range) && loop->is_invariant(offset) &&
> 1109:             original_iters_limit / ABS(scale * stride_con) >= min_iters) {
> 1110:           reduced_iters_limit = MIN2(reduced_iters_limit, original_iters_limit/ABS(scale));

Mixing signed and unsigned can cause compiler warnings and a change in semantics.  And again, checked_cast is not better than a raw cast here.  I think it would be better to make min_iters, reduced_iters_limit, original_iters_limit all unsigned.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17617#discussion_r1500185753

From jzhu at openjdk.org  Fri Feb 23 04:05:01 2024
From: jzhu at openjdk.org (Joshua Zhu)
Date: Fri, 23 Feb 2024 04:05:01 GMT
Subject: RFR: 8326541: [AArch64] ZGC C2 load barrier stub considers the length
 of live registers when spilling registers
Message-ID: <Dh0nGDUQ3yO21ff9QdV9g5DNtzRfqbu0Fs32Q_qw3y8=.74b420a8-4b52-48ee-8776-f6a074d96500@github.com>

Currently ZGC C2 load barrier stub saves the whole live register regardless of what size of register is live on aarch64.
Considering the size of SVE register is an implementation-defined multiple of 128 bits, up to 2048 bits,
even the use of a floating point may cause the maximum 2048 bits stack occupied.
Hence I would like to introduce this change on aarch64: take the length of live registers into consideration in ZGC C2 load barrier stub.

In a floating point case on 2048 bits SVE machine, the following ZLoadBarrierStubC2 


  ......
  0x0000ffff684cfad8:   stp     x15, x18, [sp, #80]
  0x0000ffff684cfadc:   sub     sp, sp, #0x100
  0x0000ffff684cfae0:   str     z16, [sp]
  0x0000ffff684cfae4:   add     x1, x13, #0x10
  0x0000ffff684cfae8:   mov     x0, x16
 ;; 0xFFFF803F5414
  0x0000ffff684cfaec:   mov     x8, #0x5414                     // #21524
  0x0000ffff684cfaf0:   movk    x8, #0x803f, lsl #16
  0x0000ffff684cfaf4:   movk    x8, #0xffff, lsl #32
  0x0000ffff684cfaf8:   blr     x8
  0x0000ffff684cfafc:   mov     x16, x0
  0x0000ffff684cfb00:   ldr     z16, [sp]
  0x0000ffff684cfb04:   add     sp, sp, #0x100
  0x0000ffff684cfb08:   ptrue   p7.b
  0x0000ffff684cfb0c:   ldp     x4, x5, [sp, #16]
  ......


could be optimized into:


  ......  
  0x0000ffff684cfa50:   stp     x15, x18, [sp, #80]
  0x0000ffff684cfa54:   str     d16, [sp, #-16]!
  0x0000ffff684cfa58:   add     x1, x13, #0x10
  0x0000ffff684cfa5c:   mov     x0, x16
 ;; 0xFFFF7FA942A8
  0x0000ffff684cfa60:   mov     x8, #0x42a8                     // #17064
  0x0000ffff684cfa64:   movk    x8, #0x7fa9, lsl #16
  0x0000ffff684cfa68:   movk    x8, #0xffff, lsl #32
  0x0000ffff684cfa6c:   blr     x8
  0x0000ffff684cfa70:   mov     x16, x0
  0x0000ffff684cfa74:   ldr     d16, [sp], #16
  0x0000ffff684cfa78:   ptrue   p7.b
  0x0000ffff684cfa7c:   ldp     x4, x5, [sp, #16]
  ......


Besides the above benefit, when we know what size of register is live,
we could remove the unnecessary caller save in ZGC C2 load barrier stub when we meet C-ABI SOE fp registers.

-------------

Commit messages:
 - 8326541: [AArch64] ZGC C2 load barrier stub considers the length of live registers when spilling registers

Changes: https://git.openjdk.org/jdk/pull/17974/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17974&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8326541
  Stats: 301 lines in 6 files changed: 236 ins; 7 del; 58 mod
  Patch: https://git.openjdk.org/jdk/pull/17974.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17974/head:pull/17974

PR: https://git.openjdk.org/jdk/pull/17974

From david.holmes at oracle.com  Fri Feb 23 05:31:17 2024
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 23 Feb 2024 15:31:17 +1000
Subject: =?UTF-8?Q?Re=3A_CFV=3A_New_HotSpot_Group_Member=3A_Johan_Sj=C3=B6l?=
 =?UTF-8?B?w6lu?=
In-Reply-To: <041D6781-CFE6-41BD-A8F5-7E25C2EFFD52@oracle.com>
References: <041D6781-CFE6-41BD-A8F5-7E25C2EFFD52@oracle.com>
Message-ID: <d9c51e75-6f6e-47e7-b816-ed10a8c408ee@oracle.com>

Vote: yes

David

On 22/02/2024 10:14 pm, Jesper Wilhelmsson wrote:
> I hereby nominate Johan Sj?l?n (jsjolen) to Membership in the HotSpot Group.
> 
> Johan is a Reviewer in the JDK project, and a member of the Oracle JVM Runtime team. Johan has done major work in the Unified Logging framework and is today the de facto owner of that area. He has done major cleanups and bug fixes throughout the JVM, and does a lot of work in the Native Memory Tracking area.
> 
> Votes are due by Thursday March 7.
> 
> Only current Members of the HotSpot Group [1] are eligible to vote on this nomination.  Votes must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> Thanks,
> /Jesper
> 
> [1] https://openjdk.org/census
> [2] https://openjdk.org/groups/#member-vote

From tobias.hartmann at oracle.com  Fri Feb 23 06:08:45 2024
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Fri, 23 Feb 2024 07:08:45 +0100
Subject: =?UTF-8?Q?Re=3A_CFV=3A_New_HotSpot_Group_Member=3A_Johan_Sj=C3=B6l?=
 =?UTF-8?B?w6lu?=
In-Reply-To: <041D6781-CFE6-41BD-A8F5-7E25C2EFFD52@oracle.com>
References: <041D6781-CFE6-41BD-A8F5-7E25C2EFFD52@oracle.com>
Message-ID: <2630eaea-d472-4731-8ac4-c4ae002a82b5@oracle.com>

Vote: yes

Best regards,
Tobias

On 22.02.24 13:14, Jesper Wilhelmsson wrote:
> I hereby nominate Johan Sj?l?n (jsjolen) to Membership in the HotSpot Group.
> 
> Johan is a Reviewer in the JDK project, and a member of the Oracle JVM Runtime team. Johan has done major work in the Unified Logging framework and is today the de facto owner of that area. He has done major cleanups and bug fixes throughout the JVM, and does a lot of work in the Native Memory Tracking area.
> 
> Votes are due by Thursday March 7.
> 
> Only current Members of the HotSpot Group [1] are eligible to vote on this nomination.  Votes must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> Thanks,
> /Jesper
> 
> [1] https://openjdk.org/census
> [2] https://openjdk.org/groups/#member-vote

From djelinski at openjdk.org  Fri Feb 23 07:50:55 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 23 Feb 2024 07:50:55 GMT
Subject: RFR: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234
In-Reply-To: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
References: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
Message-ID: <-iT0dy_iA2G0QOIKTPzWbmAoq5R5nBztXQGadPM3Txg=.0e4db140-d4ef-482e-a9ef-55067d4ffbed@github.com>

On Thu, 22 Feb 2024 16:28:20 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) has been integrated, it is possible to do some cleanup. The goal of [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) was to not change any behavior, even if that behavior seemed odd.
> 
> Now let's try to fix that. We can:
> 
> a) remove JNIEXPORT from c2v functions.
> b) make debug.cpp functions exported similarly on all platforms.
> c) remove JNIEXPORT from aarch64 asm debug function.
> 
> Note that this PR is [dependent on](https://mail.openjdk.org/pipermail/jdk-dev/2021-March/005232.html) https://github.com/openjdk/jdk/pull/17955.

Nice cleanup!

src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 1027:

> 1025: 
> 1026: extern "C" {
> 1027: VMStructEntry* jvmciHotSpotVMStructs = JVMCIVMStructs::localHotSpotVMStructs;

All these globals are unused now. You can remove them.

-------------

PR Review: https://git.openjdk.org/jdk/pull/17967#pullrequestreview-1897492946
PR Review Comment: https://git.openjdk.org/jdk/pull/17967#discussion_r1500284610

From jzhu at openjdk.org  Fri Feb 23 08:15:13 2024
From: jzhu at openjdk.org (Joshua Zhu)
Date: Fri, 23 Feb 2024 08:15:13 GMT
Subject: RFR: 8326541: [AArch64] ZGC C2 load barrier stub considers the length
 of live registers when spilling registers
Message-ID: <r2f4Q3rOBQI7MZj98vsv9aZnAQtRfILkKXTapls0VXw=.6895abe4-526a-47af-b400-5d7c6bd100b2@github.com>

Currently ZGC C2 load barrier stub saves the whole live register regardless of what size of register is live on aarch64.
Considering the size of SVE register is an implementation-defined multiple of 128 bits, up to 2048 bits,
even the use of a floating point may cause the maximum 2048 bits stack occupied.
Hence I would like to introduce this change on aarch64: take the length of live registers into consideration in ZGC C2 load barrier stub.

In a floating point case on 2048 bits SVE machine, the following ZLoadBarrierStubC2 


  ......
  0x0000ffff684cfad8:   stp     x15, x18, [sp, #80]
  0x0000ffff684cfadc:   sub     sp, sp, #0x100
  0x0000ffff684cfae0:   str     z16, [sp]
  0x0000ffff684cfae4:   add     x1, x13, #0x10
  0x0000ffff684cfae8:   mov     x0, x16
 ;; 0xFFFF803F5414
  0x0000ffff684cfaec:   mov     x8, #0x5414                     // #21524
  0x0000ffff684cfaf0:   movk    x8, #0x803f, lsl #16
  0x0000ffff684cfaf4:   movk    x8, #0xffff, lsl #32
  0x0000ffff684cfaf8:   blr     x8
  0x0000ffff684cfafc:   mov     x16, x0
  0x0000ffff684cfb00:   ldr     z16, [sp]
  0x0000ffff684cfb04:   add     sp, sp, #0x100
  0x0000ffff684cfb08:   ptrue   p7.b
  0x0000ffff684cfb0c:   ldp     x4, x5, [sp, #16]
  ......


could be optimized into:


  ......  
  0x0000ffff684cfa50:   stp     x15, x18, [sp, #80]
  0x0000ffff684cfa54:   str     d16, [sp, #-16]!                   // extra 8 bytes to align 16 bytes in push_fp()
  0x0000ffff684cfa58:   add     x1, x13, #0x10
  0x0000ffff684cfa5c:   mov     x0, x16
 ;; 0xFFFF7FA942A8
  0x0000ffff684cfa60:   mov     x8, #0x42a8                     // #17064
  0x0000ffff684cfa64:   movk    x8, #0x7fa9, lsl #16
  0x0000ffff684cfa68:   movk    x8, #0xffff, lsl #32
  0x0000ffff684cfa6c:   blr     x8
  0x0000ffff684cfa70:   mov     x16, x0
  0x0000ffff684cfa74:   ldr     d16, [sp], #16
  0x0000ffff684cfa78:   ptrue   p7.b
  0x0000ffff684cfa7c:   ldp     x4, x5, [sp, #16]
  ......


Besides the above benefit, when we know what size of register is live,
we could remove the unnecessary caller save in ZGC C2 load barrier stub when we meet C-ABI SOE fp registers.

Passed jtreg with option "-XX:+UseZGC -XX:+ZGenerational" with no failures introduced.

-------------

Commit messages:
 - 8326541: [AArch64] ZGC C2 load barrier stub considers the length of live registers when spilling registers

Changes: https://git.openjdk.org/jdk/pull/17977/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17977&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8326541
  Stats: 301 lines in 6 files changed: 236 ins; 7 del; 58 mod
  Patch: https://git.openjdk.org/jdk/pull/17977.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17977/head:pull/17977

PR: https://git.openjdk.org/jdk/pull/17977

From jzhu at openjdk.org  Fri Feb 23 08:16:03 2024
From: jzhu at openjdk.org (Joshua Zhu)
Date: Fri, 23 Feb 2024 08:16:03 GMT
Subject: Withdrawn: 8326541: [AArch64] ZGC C2 load barrier stub considers the
 length of live registers when spilling registers
In-Reply-To: <Dh0nGDUQ3yO21ff9QdV9g5DNtzRfqbu0Fs32Q_qw3y8=.74b420a8-4b52-48ee-8776-f6a074d96500@github.com>
References: <Dh0nGDUQ3yO21ff9QdV9g5DNtzRfqbu0Fs32Q_qw3y8=.74b420a8-4b52-48ee-8776-f6a074d96500@github.com>
Message-ID: <xADnAFX8f04JnNt-MTEZNl9LeoboECIRp1aV3SyS1uU=.2283f76a-9a21-45bd-8cf4-5d8d2aa5eb5f@github.com>

On Fri, 23 Feb 2024 03:59:46 GMT, Joshua Zhu <jzhu at openjdk.org> wrote:

> Currently ZGC C2 load barrier stub saves the whole live register regardless of what size of register is live on aarch64.
> Considering the size of SVE register is an implementation-defined multiple of 128 bits, up to 2048 bits,
> even the use of a floating point may cause the maximum 2048 bits stack occupied.
> Hence I would like to introduce this change on aarch64: take the length of live registers into consideration in ZGC C2 load barrier stub.
> 
> In a floating point case on 2048 bits SVE machine, the following ZLoadBarrierStubC2 
> 
> 
>   ......
>   0x0000ffff684cfad8:   stp     x15, x18, [sp, #80]
>   0x0000ffff684cfadc:   sub     sp, sp, #0x100
>   0x0000ffff684cfae0:   str     z16, [sp]
>   0x0000ffff684cfae4:   add     x1, x13, #0x10
>   0x0000ffff684cfae8:   mov     x0, x16
>  ;; 0xFFFF803F5414
>   0x0000ffff684cfaec:   mov     x8, #0x5414                     // #21524
>   0x0000ffff684cfaf0:   movk    x8, #0x803f, lsl #16
>   0x0000ffff684cfaf4:   movk    x8, #0xffff, lsl #32
>   0x0000ffff684cfaf8:   blr     x8
>   0x0000ffff684cfafc:   mov     x16, x0
>   0x0000ffff684cfb00:   ldr     z16, [sp]
>   0x0000ffff684cfb04:   add     sp, sp, #0x100
>   0x0000ffff684cfb08:   ptrue   p7.b
>   0x0000ffff684cfb0c:   ldp     x4, x5, [sp, #16]
>   ......
> 
> 
> could be optimized into:
> 
> 
>   ......  
>   0x0000ffff684cfa50:   stp     x15, x18, [sp, #80]
>   0x0000ffff684cfa54:   str     d16, [sp, #-16]!                   // extra 8 bytes to align 16 bytes in push_fp()
>   0x0000ffff684cfa58:   add     x1, x13, #0x10
>   0x0000ffff684cfa5c:   mov     x0, x16
>  ;; 0xFFFF7FA942A8
>   0x0000ffff684cfa60:   mov     x8, #0x42a8                     // #17064
>   0x0000ffff684cfa64:   movk    x8, #0x7fa9, lsl #16
>   0x0000ffff684cfa68:   movk    x8, #0xffff, lsl #32
>   0x0000ffff684cfa6c:   blr     x8
>   0x0000ffff684cfa70:   mov     x16, x0
>   0x0000ffff684cfa74:   ldr     d16, [sp], #16
>   0x0000ffff684cfa78:   ptrue   p7.b
>   0x0000ffff684cfa7c:   ldp     x4, x5, [sp, #16]
>   ......
> 
> 
> Besides the above benefit, when we know what size of register is live,
> we could remove the unnecessary caller save in ZGC C2 load barrier stub when we meet C-ABI SOE fp registers.
> 
> Passed jtreg with option "-XX:+UseZGC -XX:+ZGenerational" with no failures introduced.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/17974

From jzhu at openjdk.org  Fri Feb 23 08:16:02 2024
From: jzhu at openjdk.org (Joshua Zhu)
Date: Fri, 23 Feb 2024 08:16:02 GMT
Subject: RFR: 8326541: [AArch64] ZGC C2 load barrier stub considers the
 length of live registers when spilling registers
In-Reply-To: <Dh0nGDUQ3yO21ff9QdV9g5DNtzRfqbu0Fs32Q_qw3y8=.74b420a8-4b52-48ee-8776-f6a074d96500@github.com>
References: <Dh0nGDUQ3yO21ff9QdV9g5DNtzRfqbu0Fs32Q_qw3y8=.74b420a8-4b52-48ee-8776-f6a074d96500@github.com>
Message-ID: <8_qPirtdOojpPB9rZRb_z0Pi-xaYBXDICNx_79dgXdg=.8d9b0377-09cd-492c-8bf7-1a071eeb694f@github.com>

On Fri, 23 Feb 2024 03:59:46 GMT, Joshua Zhu <jzhu at openjdk.org> wrote:

> Currently ZGC C2 load barrier stub saves the whole live register regardless of what size of register is live on aarch64.
> Considering the size of SVE register is an implementation-defined multiple of 128 bits, up to 2048 bits,
> even the use of a floating point may cause the maximum 2048 bits stack occupied.
> Hence I would like to introduce this change on aarch64: take the length of live registers into consideration in ZGC C2 load barrier stub.
> 
> In a floating point case on 2048 bits SVE machine, the following ZLoadBarrierStubC2 
> 
> 
>   ......
>   0x0000ffff684cfad8:   stp     x15, x18, [sp, #80]
>   0x0000ffff684cfadc:   sub     sp, sp, #0x100
>   0x0000ffff684cfae0:   str     z16, [sp]
>   0x0000ffff684cfae4:   add     x1, x13, #0x10
>   0x0000ffff684cfae8:   mov     x0, x16
>  ;; 0xFFFF803F5414
>   0x0000ffff684cfaec:   mov     x8, #0x5414                     // #21524
>   0x0000ffff684cfaf0:   movk    x8, #0x803f, lsl #16
>   0x0000ffff684cfaf4:   movk    x8, #0xffff, lsl #32
>   0x0000ffff684cfaf8:   blr     x8
>   0x0000ffff684cfafc:   mov     x16, x0
>   0x0000ffff684cfb00:   ldr     z16, [sp]
>   0x0000ffff684cfb04:   add     sp, sp, #0x100
>   0x0000ffff684cfb08:   ptrue   p7.b
>   0x0000ffff684cfb0c:   ldp     x4, x5, [sp, #16]
>   ......
> 
> 
> could be optimized into:
> 
> 
>   ......  
>   0x0000ffff684cfa50:   stp     x15, x18, [sp, #80]
>   0x0000ffff684cfa54:   str     d16, [sp, #-16]!                   // extra 8 bytes to align 16 bytes in push_fp()
>   0x0000ffff684cfa58:   add     x1, x13, #0x10
>   0x0000ffff684cfa5c:   mov     x0, x16
>  ;; 0xFFFF7FA942A8
>   0x0000ffff684cfa60:   mov     x8, #0x42a8                     // #17064
>   0x0000ffff684cfa64:   movk    x8, #0x7fa9, lsl #16
>   0x0000ffff684cfa68:   movk    x8, #0xffff, lsl #32
>   0x0000ffff684cfa6c:   blr     x8
>   0x0000ffff684cfa70:   mov     x16, x0
>   0x0000ffff684cfa74:   ldr     d16, [sp], #16
>   0x0000ffff684cfa78:   ptrue   p7.b
>   0x0000ffff684cfa7c:   ldp     x4, x5, [sp, #16]
>   ......
> 
> 
> Besides the above benefit, when we know what size of register is live,
> we could remove the unnecessary caller save in ZGC C2 load barrier stub when we meet C-ABI SOE fp registers.
> 
> Passed jtreg with option "-XX:+UseZGC -XX:+ZGenerational" with no failures introduced.

Improper private branch name. Close this PR. Reopen a new one.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17974#issuecomment-1960893276

From djelinski at openjdk.org  Fri Feb 23 08:20:55 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 23 Feb 2024 08:20:55 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v5]
In-Reply-To: <4EYRe8CRYOZ6oPcfyYh1j8XHlttjZJJnO4h2qDrk5q4=.d7588fb9-2f94-458c-bfa6-c3878fec411e@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <4EYRe8CRYOZ6oPcfyYh1j8XHlttjZJJnO4h2qDrk5q4=.d7588fb9-2f94-458c-bfa6-c3878fec411e@github.com>
Message-ID: <hqw0OeOo_jBuqfttrP7zJHFMTcN3yorEcF0Go214L-U=.65c0ea99-c55d-4ed4-ae27-1790e68b417d@github.com>

On Thu, 22 Feb 2024 16:15:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
>> 
>> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
>> 
>> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
>> 
>> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use #pragma instead of HIDDEN define

src/hotspot/share/oops/accessBackend.cpp line 40:

> 38: #if defined(TARGET_COMPILER_gcc)
> 39: // Needed to work around bug in gcc causing these symbols to be visible despite -fvisibility=hidden
> 40: #pragma GCC visibility push(hidden)

does it work for you? because it doesn't hide the arraycopy symbols for me. The explicit visibility(hidden) attribute did work.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1500329388

From epeter at openjdk.org  Fri Feb 23 08:44:24 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 23 Feb 2024 08:44:24 GMT
Subject: RFR: 8325095: C2: bailout message broken: ResourceArea allocated
 string used after free [v3]
In-Reply-To: <8Bl6JSxb-fd1xAsKOMzBakRFuruoqJykP7JEn57k6qY=.717f89af-2aa7-439b-afd1-768dd39f51da@github.com>
References: <8Bl6JSxb-fd1xAsKOMzBakRFuruoqJykP7JEn57k6qY=.717f89af-2aa7-439b-afd1-768dd39f51da@github.com>
Message-ID: <vmremGnlKTgos77moI3fPRgGmHDyS69Y9s4eecVp5Ac=.d8ca985f-907b-4a12-a983-f07fa6f69027@github.com>

> **Problem**
> Bailout `failure_reason` strings used to be either `nullptr` or a static string. But with [JDK-8303951](https://bugs.openjdk.org/browse/JDK-8303951) I had introduced dynamic strings (e.g. formatted using `stringStream::as_string()`). These dynamic strings were ResourceArea allocated, and have a very limited life-span, i.e. withing the most recent ResourceMark scope. The pointer is passed to `Compile::_failure_reason`, which already might leave that ResourceMark scope, and the pointer is invalid. And then the pointer is further passed to `ciEnv::_failure_reason`. And finally, it even gets passed up to `CompileBroker::invoke_compiler_on_method`. When the string is finally printed for the bailout message, we already left original `ResourceMark` scope, and also the `Compile` and `ciEnv` scopes. The pointer now points to basically random data.
> 
> **Solution**
> Whenever a string is passed to an outer scope, I make a CHeap copy, and the outer scope is the owner of that copy.
> This way every scope is the owner of its own copy, and can allocate and deallocate according to its own strategy safely.
> 
> I introduced a utility class `CHeapStringHolder`:
>  - `set`: make local copy on CHeap.
>  - `clear`: free local copy. We before `set`, and in the destructor. Thus, when the holder goes out of scope, the memory is automatically freed.
> 
> We have these 4 scopes:
> - `ResourceMark`: It allocates from `ResourcArea`, and deallocation is taken care at the end of the ResourceMark scope.
> - `Compile`: We turn the `_failure_reason` from a `char*` into a `CHeapStringHolder`. We set `_failure_reason` while the `ResourceMark` is live.
> - `ciEnv`: We turn the `_failure_reason` from a `char*` into a `CHeapStringHolder`. We set `_failure_reason` while `Compile` is live.
> - `CompileTask`: We used to just set `failure_reason`, which assumes that the string is static or elsewhere managed. Now I use pattern available in other places of `CompileBroker::invoke_compiler_on_method`: duplicate the string with `os::strdup` from some other scope, and set `reason_on_C_heap = true`, which means that we are the owner of that copy, and are responsible for freeing it later. Not sure if that is a nice pattern, but I don't want to refactor that code and it does what I need it to do.

Emanuel Peter has updated the pull request incrementally with three additional commits since the last revision:

 - restore code to previous shape
 - more review suggestion responses
 - address review suggestions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17710/files
  - new: https://git.openjdk.org/jdk/pull/17710/files/127e08cc..f37b66ba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17710&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17710&range=01-02

  Stats: 120 lines in 8 files changed: 52 ins; 61 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/17710.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17710/head:pull/17710

PR: https://git.openjdk.org/jdk/pull/17710

From epeter at openjdk.org  Fri Feb 23 08:51:57 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 23 Feb 2024 08:51:57 GMT
Subject: RFR: 8325095: C2: bailout message broken: ResourceArea allocated
 string used after free [v2]
In-Reply-To: <fdijEO4HOMxS2z2kj0PKvK9HfGBjSk4MqjMZVAS-MDY=.f8715719-f21c-4ed4-a3f5-7fee830b667b@github.com>
References: <8Bl6JSxb-fd1xAsKOMzBakRFuruoqJykP7JEn57k6qY=.717f89af-2aa7-439b-afd1-768dd39f51da@github.com>
 <iqVK2jP6-y3NweZYd_Y6Eo39GUH9hf8gFugp8aq3-dw=.54a735a9-9cf2-411d-89aa-19dcbef22937@github.com>
 <fdijEO4HOMxS2z2kj0PKvK9HfGBjSk4MqjMZVAS-MDY=.f8715719-f21c-4ed4-a3f5-7fee830b667b@github.com>
Message-ID: <22-O7o2m6ZAJx3YmbAuY2dYcN47gTdeAFUu0m7SKy5Q=.7909c9ed-872f-4d95-9e78-d725f5deb002@github.com>

On Tue, 20 Feb 2024 16:59:03 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove OrderAccess::storestore() bc single threaded only
>
> UL should be done in separate RFE. Current logging (`log()->elem()`) is for `-XX:+LogCompilation` output into file. UL is for terminal.
> UL should report immediately, the same way we do for `-XX:+LogCompilation`.
> 
> Different failures are recorded in ciEnv and Compiler, only after compilation is finish we record compiler's failure in ciEnv.
> There is also ciTypefFow failure which recorded in Compiler.

@vnkozlov @tstuefe thanks for the comments and suggestions!

What I did:
- Moved `utilities/cHeapStringHolder.hpp/cpp` -> `compiler/cHeapStringHolder.hpp/cpp`.
- Directly use `mtCompiler` for it, rather than constructor argument with `MEMFLAGS`.
- Fixed 2 issues (bugs and code style)

What I did not yet do:
Any changes to logging. I think we want to do that in a separate RFE anyway, and not backport it together with this bugfix.
Is there anything that you still need me to change for this bugfix here?

About Logging, in a future RFE:
@vnkozlov suggested to always UL failures immediately. The question is where I should do that. At `ciEnv::record_method_not_compilable` only? Or also in `Compile::record_method_not_compilable`?
And @vnkozlov also suggested only to report one (a single) failure reason at the very end, presumably at the `CompileTask` level. Does that mean you would still overwrite the less important failures with more important ones in `ciEnv`, like we do currently?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17710#issuecomment-1960938937

From tschatzl at openjdk.org  Fri Feb 23 08:58:54 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 23 Feb 2024 08:58:54 GMT
Subject: RFR: 8326006: Allow TEST_VM_FLAGLESS to set flagless mode
In-Reply-To: <0uxFDONrkojHseqjpNszTa-0LmjDpOPKZYozPDJKyOo=.e89913fa-ff13-43f6-95db-bc85222d3c49@github.com>
References: <0uxFDONrkojHseqjpNszTa-0LmjDpOPKZYozPDJKyOo=.e89913fa-ff13-43f6-95db-bc85222d3c49@github.com>
Message-ID: <YuSWvlmwgn75hGa81tRVM3hZYcBPgN6zWmz-ens3oFs=.530dfcb4-2425-40d2-b3c4-671e679956be@github.com>

On Fri, 16 Feb 2024 00:44:24 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Allow TEST_VM_FLAGLESS to enable/disable flagless tests execution explicitly.
> Sometimes the tests are executed in the mode that is incompatible with flag-sensitive tests. This mode should be able to disable them explicitly.

Marked as reviewed by tschatzl (Reviewer).

test/jtreg-ext/requires/VMProps.java line 668:

> 666:         boolean result = true;
> 667:         if (System.getenv("TEST_VM_FLAGLESS") != null) {
> 668:             return "" + "true".equalsIgnoreCase(System.getenv("TEST_VM_FLAGLESS"));

I would slightly prefer extracting the `System.getenv()` call into a local and reusing it, but this is fine as well.

-------------

PR Review: https://git.openjdk.org/jdk/pull/17886#pullrequestreview-1897641915
PR Review Comment: https://git.openjdk.org/jdk/pull/17886#discussion_r1500370050

From tschatzl at openjdk.org  Fri Feb 23 09:02:58 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 23 Feb 2024 09:02:58 GMT
Subject: RFR: 8325082: Rename headers named 'heapRegion*' of G1 [v3]
In-Reply-To: <p9f42d634nvSGvduMCBA3FUTq1V9ZIPUstJ8IpeuyWg=.6693e68b-0060-4f23-af4d-691dca3b94bb@github.com>
References: <1MWMgluBwGY-FydUnpoksJ0q5sSvptrNMv6xwDszBQc=.a78cadad-1585-44d1-97d0-a7928fe34d67@github.com>
 <p9f42d634nvSGvduMCBA3FUTq1V9ZIPUstJ8IpeuyWg=.6693e68b-0060-4f23-af4d-691dca3b94bb@github.com>
Message-ID: <AFpg2PsvEfXYnYRuGkBsXVYifCAzF1CdA85JH_OA7-Y=.f6aa40cc-4dcf-4109-9c6b-103eb0aa997c@github.com>

On Wed, 14 Feb 2024 12:51:05 GMT, Lei Zaakjyu <duke at openjdk.org> wrote:

>> 8325082: Rename headers named 'heapRegion*' of G1
>
> Lei Zaakjyu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix

Marked as reviewed by tschatzl (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17666#pullrequestreview-1897649930

From thomas.schatzl at oracle.com  Fri Feb 23 09:03:51 2024
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Fri, 23 Feb 2024 10:03:51 +0100
Subject: =?UTF-8?Q?Re=3A_CFV=3A_New_HotSpot_Group_Member=3A_Johan_Sj=C3=B6l?=
 =?UTF-8?B?w6lu?=
In-Reply-To: <041D6781-CFE6-41BD-A8F5-7E25C2EFFD52@oracle.com>
References: <041D6781-CFE6-41BD-A8F5-7E25C2EFFD52@oracle.com>
Message-ID: <4cae43f1-06ec-48fc-8b72-2cc3e44ce60e@oracle.com>

Vote: yes

From aboldtch at openjdk.org  Fri Feb 23 09:37:05 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 23 Feb 2024 09:37:05 GMT
Subject: RFR: 8139457: Relax alignment of array elements [v69]
In-Reply-To: <ItpJ7eaRnBW0Be6y15yN5jzTORHGUBW3udpZG46Z2sI=.6247dbb9-34a1-4dfa-a997-6559ae5afd62@github.com>
References: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
 <ItpJ7eaRnBW0Be6y15yN5jzTORHGUBW3udpZG46Z2sI=.6247dbb9-34a1-4dfa-a997-6559ae5afd62@github.com>
Message-ID: <FZxrRYzslvOJdCelPy241L1f0IG2PWvDE_BD2ccArJM=.11bd5431-2091-4255-bae5-c869682e222b@github.com>

On Thu, 22 Feb 2024 16:08:33 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details.
>> 
>> Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements.
>> 
>> Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16.
>> 
>> Testing:
>>  - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390)
>>  - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390)
>>  - [x] tier1 (x86_64, x86_32, aarch64, riscv)
>>  - [x] tier2 (x86_64, aarch64, riscv)
>>  - [x] tier3 (x86_64, riscv)
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve comment

Marked as reviewed by aboldtch (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/11044#pullrequestreview-1897706983

From tschatzl at openjdk.org  Fri Feb 23 09:50:57 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 23 Feb 2024 09:50:57 GMT
Subject: RFR: 8305898: Alternative self-forwarding mechanism [v4]
In-Reply-To: <OC2HtdWXXKiV3OLkz39XVG7bickA31IZZVgpZpZy3GU=.04506b71-994c-4dc6-a39f-cf0d0c908977@github.com>
References: <N4eX8S-btv0VD19kl2W9RigVsaw58ZVXDZllFwykZ04=.a9456aa8-b294-480a-b7f0-07616c972f62@github.com>
 <OC2HtdWXXKiV3OLkz39XVG7bickA31IZZVgpZpZy3GU=.04506b71-994c-4dc6-a39f-cf0d0c908977@github.com>
Message-ID: <yAVkOGZctk_X4BuGd4Oel6uM7n6iu9MrG5f0AnV2uFg=.e4cca1e1-e76b-4d46-a53f-b69e4f8973df@github.com>

On Thu, 8 Feb 2024 14:37:20 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Currently, the Serial, Parallel and G1 GCs store a pointer to self into object headers to indicate promotion failure. This is problematic for compact object headers ([JDK-8294992](https://bugs.openjdk.org/browse/JDK-8294992)) because it would (temporarily) over-write the crucial class information, which we need for heap parsing. I would like to propose an alternative: use the currently unused 3rd header bit (previously biased-locking bit) to indicate that an object is 'self-forwarded'. That preserves the crucial class information in the upper bits of the header until the full header gets restored.
>> 
>> This is a trimmed-down/simplified version of the original proposal #13779:
>>  - It doesn't use/introduce any flags and avoids the associated branching.
>>  - It doesn't (need to) deal with displaced headers. (Current code would preserve header if necessary, Lilliput code would not use displaced headers and set the 3rd bit directly in existing header.)
>> 
>> Testing:
>>  - [x] hotspot_gc
>>  - [x] tier1
>>  - [x] tier2
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More consistent use of markWord::is_forwarded()

Marked as reviewed by tschatzl (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17755#pullrequestreview-1897733504

From rkennke at openjdk.org  Fri Feb 23 10:08:16 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 23 Feb 2024 10:08:16 GMT
Subject: Integrated: 8139457: Relax alignment of array elements
In-Reply-To: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
References: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
Message-ID: <Hvxk8cEfErbxvnjtfRB1Nu6Vhovzhpp-iZP3ZaUSurU=.421623ae-4436-4d06-8ca7-948ba0e804e1@github.com>

On Tue, 8 Nov 2022 20:18:09 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details.
> 
> Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements.
> 
> Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16.
> 
> Testing:
>  - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390)
>  - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390)
>  - [x] tier1 (x86_64, x86_32, aarch64, riscv)
>  - [x] tier2 (x86_64, aarch64, riscv)
>  - [x] tier3 (x86_64, riscv)

This pull request has now been integrated.

Changeset: 336bbbe3
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/336bbbe3895214a772e0f3aafb36277c46645ded
Stats:     645 lines in 33 files changed: 474 ins; 85 del; 86 mod

8139457: Relax alignment of array elements

Co-authored-by: Fei Yang <fyang at openjdk.org>
Co-authored-by: Thomas Stuefe <stuefe at openjdk.org>
Reviewed-by: stuefe, stefank, shade, coleenp, kdnilsen, aboldtch

-------------

PR: https://git.openjdk.org/jdk/pull/11044

From rkennke at openjdk.org  Fri Feb 23 10:08:14 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 23 Feb 2024 10:08:14 GMT
Subject: RFR: 8139457: Relax alignment of array elements [v69]
In-Reply-To: <ItpJ7eaRnBW0Be6y15yN5jzTORHGUBW3udpZG46Z2sI=.6247dbb9-34a1-4dfa-a997-6559ae5afd62@github.com>
References: <vq1DJY-YpIUdsfGAw0ibRlCe84GxroK6y0z2MIVAjb4=.b45385cc-7d1b-4789-8344-2383911705ff@github.com>
 <ItpJ7eaRnBW0Be6y15yN5jzTORHGUBW3udpZG46Z2sI=.6247dbb9-34a1-4dfa-a997-6559ae5afd62@github.com>
Message-ID: <WCX7B7m6dtCnAP9nNBRk5ETzo-hm42ILMqIlYV7MRQo=.5ec51656-441e-4872-bef2-bef5aa88bf74@github.com>

On Thu, 22 Feb 2024 16:08:33 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details.
>> 
>> Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements.
>> 
>> Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16.
>> 
>> Testing:
>>  - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390)
>>  - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390)
>>  - [x] tier1 (x86_64, x86_32, aarch64, riscv)
>>  - [x] tier2 (x86_64, aarch64, riscv)
>>  - [x] tier3 (x86_64, riscv)
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve comment

Thanks, all!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/11044#issuecomment-1961043984

From duke at openjdk.org  Fri Feb 23 10:27:54 2024
From: duke at openjdk.org (Lei Zaakjyu)
Date: Fri, 23 Feb 2024 10:27:54 GMT
Subject: RFR: 8325082: Rename headers named 'heapRegion*' of G1 [v5]
In-Reply-To: <Ewt6z3MSH1eJ8WgdlpCDLebEH7qVgBk-GDklBNAzQAc=.b55819b6-6783-48c6-8a7a-2495e900c8df@github.com>
References: <1MWMgluBwGY-FydUnpoksJ0q5sSvptrNMv6xwDszBQc=.a78cadad-1585-44d1-97d0-a7928fe34d67@github.com>
 <Ewt6z3MSH1eJ8WgdlpCDLebEH7qVgBk-GDklBNAzQAc=.b55819b6-6783-48c6-8a7a-2495e900c8df@github.com>
Message-ID: <PBd0dzpusTAHRqQequDl8-2JjzWc04ry2Cgg8VZ1ADY=.25365170-63bc-4404-b606-27358c63d849@github.com>

On Fri, 16 Feb 2024 02:29:12 GMT, Lei Zaakjyu <duke at openjdk.org> wrote:

>> 8325082: Rename headers named 'heapRegion*' of G1
>
> Lei Zaakjyu has updated the pull request with a new target base due to a merge or a rebase.

thanks for the review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17666#issuecomment-1961074052

From fyang at openjdk.org  Fri Feb 23 10:55:00 2024
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 23 Feb 2024 10:55:00 GMT
Subject: RFR: 8322179: RISC-V: Implement SHA-1 intrinsic [v10]
In-Reply-To: <onszIThxLBX_x3IvS-Lw03Qj8xUgFEat-D6wKRN5YRQ=.1758ff56-45f8-4f65-b090-d2f991b38365@github.com>
References: <PyIXzENfiHysFS3IyZn3FDNQpV7Ua2L6OmjiXq9wRoU=.cf74a45e-c94b-4f7b-8768-d10d55e2ce1d@github.com>
 <bAQOJj5ESbBOFxTqNRBDf36jquSMydvN_ey2CleFmD0=.8d3ff5c7-3c78-4113-af39-7dbba435f591@github.com>
 <GIFzLolfS5IlNcCGzsV7b0vjeqmNedCdQZubh-zywsg=.6239158c-d99e-45f7-954c-7c2f6ba834a2@github.com>
 <onszIThxLBX_x3IvS-Lw03Qj8xUgFEat-D6wKRN5YRQ=.1758ff56-45f8-4f65-b090-d2f991b38365@github.com>
Message-ID: <vJPSqgZMFuAlG9vYdvcI4p08weu0ZG6IrVl91AugPFU=.cfc6dd1e-a18b-4424-81ca-68ee30131ac5@github.com>

On Wed, 21 Feb 2024 16:05:10 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 4953:
>> 
>>> 4951:       __ rolw_imm(cur_w, a, 5, t0);
>>> 4952:       // as pointed above, we can use cur_w as temporary register here.
>>> 4953:       sha1_f(round, tmp, b, c, d);
>> 
>> Could we also reuse `cur_k` in this function where input param `tmp` is used? I see `cur_k` will also be recalculated at the beginning of each round like `cur_w`. Hope this could help eliminate `tmp` param and finally free `t2`.
>
> Seems not, as cur_k is only calculated when `(round % 20) == 0`.
> 
> Other comments are all resolved.

Thanks. Could you please move `int round` as the last formal param for other assembler functions so that it will be more consistent? They are `sha1_prepare_w`, `sha1_f`, and `sha1_process_round`. BTW: I think it will be safer to add scratch register `t0`, `t1` to the list for `assert_different_registers` if they are used in those assembler functions.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17130#discussion_r1500497514

From ihse at openjdk.org  Fri Feb 23 11:03:58 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 23 Feb 2024 11:03:58 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v5]
In-Reply-To: <4EYRe8CRYOZ6oPcfyYh1j8XHlttjZJJnO4h2qDrk5q4=.d7588fb9-2f94-458c-bfa6-c3878fec411e@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <4EYRe8CRYOZ6oPcfyYh1j8XHlttjZJJnO4h2qDrk5q4=.d7588fb9-2f94-458c-bfa6-c3878fec411e@github.com>
Message-ID: <Bx5k6oYtUpIkRhI1c93vOpfTA5ECFQPfZ_BhW0hFtcM=.f26ded4c-d816-4be3-b1d0-b0b2aff61be6@github.com>

On Thu, 22 Feb 2024 16:15:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
>> 
>> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
>> 
>> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
>> 
>> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use #pragma instead of HIDDEN define

Just to confirm: this PR passes tier 1-5.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1961125415

From ihse at openjdk.org  Fri Feb 23 11:06:04 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 23 Feb 2024 11:06:04 GMT
Subject: RFR: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234 [v2]
In-Reply-To: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
References: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
Message-ID: <AiV2aNRCeWDaFG8nyNqQ9dYGr6WZyL_dwyLwfsicaik=.216fbdd3-ea34-41a9-9c44-b400fd33b3d8@github.com>

> Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) has been integrated, it is possible to do some cleanup. The goal of [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) was to not change any behavior, even if that behavior seemed odd.
> 
> Now let's try to fix that. We can:
> 
> a) remove JNIEXPORT from c2v functions.
> b) make debug.cpp functions exported similarly on all platforms.
> c) remove JNIEXPORT from aarch64 asm debug function.
> 
> Note that this PR is [dependent on](https://mail.openjdk.org/pipermail/jdk-dev/2021-March/005232.html) https://github.com/openjdk/jdk/pull/17955.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Remove jvmci globals

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17967/files
  - new: https://git.openjdk.org/jdk/pull/17967/files/18b3f1d6..216d0db5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17967&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17967&range=00-01

  Stats: 8 lines in 1 file changed: 0 ins; 8 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17967.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17967/head:pull/17967

PR: https://git.openjdk.org/jdk/pull/17967

From ihse at openjdk.org  Fri Feb 23 11:13:56 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 23 Feb 2024 11:13:56 GMT
Subject: RFR: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234 [v2]
In-Reply-To: <TYE1ieXypz7WiaTQRwU3Zp-ICrZ2E4SIo4meD-h14LU=.884eb3e0-04e2-4728-bfc5-57b072e809bf@github.com>
References: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
 <TYE1ieXypz7WiaTQRwU3Zp-ICrZ2E4SIo4meD-h14LU=.884eb3e0-04e2-4728-bfc5-57b072e809bf@github.com>
Message-ID: <cx6Me6MA3QwpLr2y2avGx3-we6Ej3UHQHRD10Km76HU=.bdf6dc1e-c9f3-4695-9687-4ed9d044741d@github.com>

On Thu, 22 Feb 2024 22:18:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove jvmci globals
>
> src/hotspot/cpu/aarch64/assembler_aarch64.cpp line 122:
> 
>> 120:   }
>> 121: 
>> 122:   void das1(uintptr_t insn) {
> 
> Doesn't this need to be exported for debugging on Windows-Aarch64?

Ah, right, there is a Windows/aarch64 port. Forgot about it. :(

I don't know who maintains/cares about that port anymore. Pinging @mo-beck @lewurm @luhenry. Do anyone of you care about this anymore? If not, do you know if anyone has taken up the baton? (Or maybe it's time to retire the Windows/aarch64 port)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17967#discussion_r1500517200

From mli at openjdk.org  Fri Feb 23 11:30:07 2024
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 23 Feb 2024 11:30:07 GMT
Subject: RFR: 8322179: RISC-V: Implement SHA-1 intrinsic [v13]
In-Reply-To: <PyIXzENfiHysFS3IyZn3FDNQpV7Ua2L6OmjiXq9wRoU=.cf74a45e-c94b-4f7b-8768-d10d55e2ce1d@github.com>
References: <PyIXzENfiHysFS3IyZn3FDNQpV7Ua2L6OmjiXq9wRoU=.cf74a45e-c94b-4f7b-8768-d10d55e2ce1d@github.com>
Message-ID: <3PjX6O1hKuQWqOV_mSS_a2o8pJJfyl5VeApdovyjSvk=.0dad6f46-ffac-49e2-91cc-94c88d569193@github.com>

> Hi,
> Can you review this patch to implement SHA-1 intrinsic for riscv?
> Thanks!
> 
> 
> ## Test
> 
> ### Functionality
> 
> tests under `test/hotspot/jtreg/compiler/intrinsics/sha`
> tests found via `find test/jdk -iname "*SHA1*.java"`
> 
> ### Performance
> 
> tested on `T-HEAD Light Lichee Pi 4A`
> 
> JMH_PARAMS="-f 1 -wi 10 -i 20" // for every loop of jmh test
> 
> benchmark tests `MessageDigests.java GetMessageDigest.java MessageDigestBench.java MacBench.java` which are under `test/micro/org/openjdk/bench/`, more spcifically `TESTS="MessageDigests.digest MessageDigests.getAndDigest MessageDigestBench.digest"`
> 
> 
> // After
> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1        64     DEFAULT  avgt   20      1845.446 ?     27.052  ns/op
> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    181455.350 ?    532.258  ns/op
> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2447.674 ?     10.239  ns/op
> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    182896.083 ?   1242.774  ns/op
> o.o.b.javax.crypto.small.MessageDigestBench.digest         SHA1     1048576             N/A       N/A              avgt   20  11599227.792 ? 121442.390  ns/op
> // Before
> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2352.475 ?    11.198  ns/op
> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    188495.684 ?  1467.942  ns/op
> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2437.347 ?     6.398  ns/op
> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    196086.570 ?  1140.998  ns/op
> o.o.b.javax.crypto.small.MessageDigestBench.digest         SHA1     1048576             N/A       N/A              avgt   20  12362160.119 ? 38788.109  ns/op
> 
> 
> **getAndDigest when size == 64**
> The data is not stable for test getAndDigest when size == 64, which I think is introduced by  j.s.MessageDigest.getInstance itself, which we don't touch in this patch.
> Check more details at [1](https://github.com/openjdk/jdk/pull/17130#issuecomment-1886805614)
> 
> 
> loop ... ...

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  assert register; move round param

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17130/files
  - new: https://git.openjdk.org/jdk/pull/17130/files/2c075a4f..3bba2b8d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17130&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17130&range=11-12

  Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/17130.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17130/head:pull/17130

PR: https://git.openjdk.org/jdk/pull/17130

From mli at openjdk.org  Fri Feb 23 11:30:07 2024
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 23 Feb 2024 11:30:07 GMT
Subject: RFR: 8322179: RISC-V: Implement SHA-1 intrinsic [v10]
In-Reply-To: <vJPSqgZMFuAlG9vYdvcI4p08weu0ZG6IrVl91AugPFU=.cfc6dd1e-a18b-4424-81ca-68ee30131ac5@github.com>
References: <PyIXzENfiHysFS3IyZn3FDNQpV7Ua2L6OmjiXq9wRoU=.cf74a45e-c94b-4f7b-8768-d10d55e2ce1d@github.com>
 <bAQOJj5ESbBOFxTqNRBDf36jquSMydvN_ey2CleFmD0=.8d3ff5c7-3c78-4113-af39-7dbba435f591@github.com>
 <GIFzLolfS5IlNcCGzsV7b0vjeqmNedCdQZubh-zywsg=.6239158c-d99e-45f7-954c-7c2f6ba834a2@github.com>
 <onszIThxLBX_x3IvS-Lw03Qj8xUgFEat-D6wKRN5YRQ=.1758ff56-45f8-4f65-b090-d2f991b38365@github.com>
 <vJPSqgZMFuAlG9vYdvcI4p08weu0ZG6IrVl91AugPFU=.cfc6dd1e-a18b-4424-81ca-68ee30131ac5@github.com>
Message-ID: <xs9MILb5CQDcQLHLzCn2c21VF4rQas1qpV5hoLIkJ2Q=.bd1a07ef-2dea-4913-921a-a368a52bd947@github.com>

On Fri, 23 Feb 2024 10:51:48 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Seems not, as cur_k is only calculated when `(round % 20) == 0`.
>> 
>> Other comments are all resolved.
>
> Thanks. Could you please move `int round` as the last formal param for other assembler functions so that it will be more consistent? They are `sha1_prepare_w`, `sha1_f`, and `sha1_process_round`. BTW: I think it will be safer to add scratch register `t0`, `t1` to the list for `assert_different_registers` if they are used in those assembler functions.

Sure, it's updated. Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17130#discussion_r1500534552

From burban at openjdk.org  Fri Feb 23 11:37:53 2024
From: burban at openjdk.org (Bernhard Urban-Forster)
Date: Fri, 23 Feb 2024 11:37:53 GMT
Subject: RFR: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234 [v2]
In-Reply-To: <cx6Me6MA3QwpLr2y2avGx3-we6Ej3UHQHRD10Km76HU=.bdf6dc1e-c9f3-4695-9687-4ed9d044741d@github.com>
References: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
 <TYE1ieXypz7WiaTQRwU3Zp-ICrZ2E4SIo4meD-h14LU=.884eb3e0-04e2-4728-bfc5-57b072e809bf@github.com>
 <cx6Me6MA3QwpLr2y2avGx3-we6Ej3UHQHRD10Km76HU=.bdf6dc1e-c9f3-4695-9687-4ed9d044741d@github.com>
Message-ID: <WAwoF5K4yWv40dWrX1VjUfeVGYy918KDHp4qvuRQ5xM=.2aa20484-2def-46dc-b20f-4e866748e048@github.com>

On Fri, 23 Feb 2024 11:11:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/assembler_aarch64.cpp line 122:
>> 
>>> 120:   }
>>> 121: 
>>> 122:   void das1(uintptr_t insn) {
>> 
>> Doesn't this need to be exported for debugging on Windows-Aarch64?
>
> Ah, right, there is a Windows/aarch64 port. Forgot about it. :(
> 
> I don't know who maintains/cares about that port anymore. Pinging @mo-beck @lewurm @luhenry. Do anyone of you care about this anymore? If not, do you know if anyone has taken up the baton? (Or maybe it's time to retire the Windows/aarch64 port)

cc @karianna @gdams, is there a Windows/AArch64 owner?

> Or maybe it's time to retire the Windows/aarch64 port

I guess Windows/AArch64 as a platform hasn't really taken off _yet_, give it a few more years ? I certainly would not advocate for removing it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17967#discussion_r1500542216

From ihse at openjdk.org  Fri Feb 23 11:43:53 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 23 Feb 2024 11:43:53 GMT
Subject: RFR: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234 [v2]
In-Reply-To: <WAwoF5K4yWv40dWrX1VjUfeVGYy918KDHp4qvuRQ5xM=.2aa20484-2def-46dc-b20f-4e866748e048@github.com>
References: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
 <TYE1ieXypz7WiaTQRwU3Zp-ICrZ2E4SIo4meD-h14LU=.884eb3e0-04e2-4728-bfc5-57b072e809bf@github.com>
 <cx6Me6MA3QwpLr2y2avGx3-we6Ej3UHQHRD10Km76HU=.bdf6dc1e-c9f3-4695-9687-4ed9d044741d@github.com>
 <WAwoF5K4yWv40dWrX1VjUfeVGYy918KDHp4qvuRQ5xM=.2aa20484-2def-46dc-b20f-4e866748e048@github.com>
Message-ID: <1enXmdMITwK96Lz35sCWmkob9sLgKKt1N2Lp0NSldNc=.81d72c1e-0f11-452d-a55a-674f775fee47@github.com>

On Fri, 23 Feb 2024 11:35:19 GMT, Bernhard Urban-Forster <burban at openjdk.org> wrote:

>> Ah, right, there is a Windows/aarch64 port. Forgot about it. :(
>> 
>> I don't know who maintains/cares about that port anymore. Pinging @mo-beck @lewurm @luhenry. Do anyone of you care about this anymore? If not, do you know if anyone has taken up the baton? (Or maybe it's time to retire the Windows/aarch64 port)
>
> cc @karianna @gdams, is there a Windows/AArch64 owner?
> 
>> Or maybe it's time to retire the Windows/aarch64 port
> 
> I guess Windows/AArch64 as a platform hasn't really taken off _yet_, give it a few more years ? I certainly would not advocate for removing it.

Instead of discussing removal of windows/aarch64 (although the general rule in OpenJDK is that ports that are not maintained by anyone should be removed); let's stick to the question here: do we need to export `das1()` for debugging?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17967#discussion_r1500547680

From jwaters at openjdk.org  Fri Feb 23 11:50:54 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 23 Feb 2024 11:50:54 GMT
Subject: RFR: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234 [v2]
In-Reply-To: <AiV2aNRCeWDaFG8nyNqQ9dYGr6WZyL_dwyLwfsicaik=.216fbdd3-ea34-41a9-9c44-b400fd33b3d8@github.com>
References: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
 <AiV2aNRCeWDaFG8nyNqQ9dYGr6WZyL_dwyLwfsicaik=.216fbdd3-ea34-41a9-9c44-b400fd33b3d8@github.com>
Message-ID: <Nf5G91Y0KH5h6V369Kg7mO3MTrZKe7GUp4bHfPbuP-0=.2c6d5485-82ef-44e9-84d7-d852a4558a4a@github.com>

On Fri, 23 Feb 2024 11:06:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) has been integrated, it is possible to do some cleanup. The goal of [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) was to not change any behavior, even if that behavior seemed odd.
>> 
>> Now let's try to fix that. We can:
>> 
>> a) remove JNIEXPORT from c2v functions.
>> b) make debug.cpp functions exported similarly on all platforms.
>> c) remove JNIEXPORT from aarch64 asm debug function.
>> 
>> Note that this PR is [dependent on](https://mail.openjdk.org/pipermail/jdk-dev/2021-March/005232.html) https://github.com/openjdk/jdk/pull/17955.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove jvmci globals

Marked as reviewed by jwaters (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17967#pullrequestreview-1897936208

From burban at openjdk.org  Fri Feb 23 12:05:57 2024
From: burban at openjdk.org (Bernhard Urban-Forster)
Date: Fri, 23 Feb 2024 12:05:57 GMT
Subject: RFR: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234 [v2]
In-Reply-To: <1enXmdMITwK96Lz35sCWmkob9sLgKKt1N2Lp0NSldNc=.81d72c1e-0f11-452d-a55a-674f775fee47@github.com>
References: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
 <TYE1ieXypz7WiaTQRwU3Zp-ICrZ2E4SIo4meD-h14LU=.884eb3e0-04e2-4728-bfc5-57b072e809bf@github.com>
 <cx6Me6MA3QwpLr2y2avGx3-we6Ej3UHQHRD10Km76HU=.bdf6dc1e-c9f3-4695-9687-4ed9d044741d@github.com>
 <WAwoF5K4yWv40dWrX1VjUfeVGYy918KDHp4qvuRQ5xM=.2aa20484-2def-46dc-b20f-4e866748e048@github.com>
 <1enXmdMITwK96Lz35sCWmkob9sLgKKt1N2Lp0NSldNc=.81d72c1e-0f11-452d-a55a-674f775fee47@github.com>
Message-ID: <bmgatRS3iZ6J35-pwQQ81ev8-lMBeyFcN6jzQFk_qno=.369060d2-3e1f-45c9-bad6-71bbc921b647@github.com>

On Fri, 23 Feb 2024 11:41:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> cc @karianna @gdams, is there a Windows/AArch64 owner?
>> 
>>> Or maybe it's time to retire the Windows/aarch64 port
>> 
>> I guess Windows/AArch64 as a platform hasn't really taken off _yet_, give it a few more years ? I certainly would not advocate for removing it.
>
> Instead of discussing removal of windows/aarch64 (although the general rule in OpenJDK is that ports that are not maintained by anyone should be removed); let's stick to the question here: do we need to export `das1()` for debugging?

Personally I have never used `das`/`das1` on any AArch64 port when debugging.  I guess it was somewhat handy when the backend was originally developed.  I would argue that the built-in disassembler of any debugger and `disnm` from `debug.cpp` are good enough, and thus `das`/`das1` can be removed.  What do you think @theRealAph ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17967#discussion_r1500568587

From sspitsyn at openjdk.org  Fri Feb 23 12:05:58 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 23 Feb 2024 12:05:58 GMT
Subject: RFR: JDK-8325530: Vague error message when
 com.sun.tools.attach.VirtualMachine fails to load agent library [v4]
In-Reply-To: <BP-HsRnMDXD_m6sqmQMAdXOvQTCDFJ3SJ24pEXD8LzI=.6f4a2992-c6a5-497b-b0e8-2458513fc2cf@github.com>
References: <s1rZKr_Bt8tzCP2cMyFv0oe7pTD1DNzGLaIsGZdXffY=.596d50f2-12b6-4bba-ab30-a26b697fb970@github.com>
 <BP-HsRnMDXD_m6sqmQMAdXOvQTCDFJ3SJ24pEXD8LzI=.6f4a2992-c6a5-497b-b0e8-2458513fc2cf@github.com>
Message-ID: <kyuPK03Kiw_AwiaU3vuWdbz0i4qLiMyBQe7aYMEtzbo=.b378cd1c-6879-47fe-8634-18668c472c3e@github.com>

On Thu, 22 Feb 2024 23:31:16 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> VirtualMachine.loadAgentPath/loadAgentLibrary can fail with AgentLoadException in 2 cases:
>> - attach listener returns error; in the case the exception is thrown from HotSpotVirtualMachine.processCompletionStatus (called from HotSpotVirtualMachine.execute);
>> - attach listener returns success, but reply does not contain Agent_onAttach return code ("return code: %d" message).
>> 
>> before jdk21 if attach listener fails to load required library, it returned error (case 1)
>> from jdk21 attach listener always returns success (case 2)
>> Both cases are ok, but for 2nd case HotSpotVirtualMachine.loadAgentLibrary read only single line of the response message, so exception message didn't contain error details.
>> 
>> The fix updates HotSpotVirtualMachine.loadAgentLibrary to read the whole response message.
>> Walking through the code, fixed some other minor things in attach listener and attach API implementation (commented in the code)
>> 
>> Testing:
>>   - test/jdk/com/sun/tools;
>>   - tier1,tier2,tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed readErrorMessage()

Thank you for the update.
The fix looks good.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17954#pullrequestreview-1897959055

From mbaesken at openjdk.org  Fri Feb 23 12:23:54 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 23 Feb 2024 12:23:54 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v5]
In-Reply-To: <Bx5k6oYtUpIkRhI1c93vOpfTA5ECFQPfZ_BhW0hFtcM=.f26ded4c-d816-4be3-b1d0-b0b2aff61be6@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <4EYRe8CRYOZ6oPcfyYh1j8XHlttjZJJnO4h2qDrk5q4=.d7588fb9-2f94-458c-bfa6-c3878fec411e@github.com>
 <Bx5k6oYtUpIkRhI1c93vOpfTA5ECFQPfZ_BhW0hFtcM=.f26ded4c-d816-4be3-b1d0-b0b2aff61be6@github.com>
Message-ID: <bS__uPDEKVk-0o6PvRBtOicHdBWcnQu_oBBLptF2Hvk=.904db0db-863d-4185-8db5-de6dbe90c9f2@github.com>

On Fri, 23 Feb 2024 11:01:47 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Just to confirm: this PR passes tier 1-5.

We had the PR in our SAP internal build/test queue, so issues seen with it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1961232277

From ihse at openjdk.org  Fri Feb 23 12:38:23 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 23 Feb 2024 12:38:23 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v6]
In-Reply-To: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
Message-ID: <wvVBVyQswVhKlZM7Ux8ifRbqpqCoebaGJjqWHzuW6Gw=.67f9d62d-e669-4ade-8d97-94df4eeceed8@github.com>

> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
> 
> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
> 
> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
> 
> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Revert "Use #pragma instead of HIDDEN define"
  
  This reverts commit 00e40a7f6e4cdef6592d72b3d08063cdcc41532a.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17955/files
  - new: https://git.openjdk.org/jdk/pull/17955/files/00e40a7f..7be8372a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17955&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17955&range=04-05

  Stats: 31 lines in 1 file changed: 4 ins; 7 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/17955.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17955/head:pull/17955

PR: https://git.openjdk.org/jdk/pull/17955

From ihse at openjdk.org  Fri Feb 23 12:38:23 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 23 Feb 2024 12:38:23 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v5]
In-Reply-To: <4EYRe8CRYOZ6oPcfyYh1j8XHlttjZJJnO4h2qDrk5q4=.d7588fb9-2f94-458c-bfa6-c3878fec411e@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <4EYRe8CRYOZ6oPcfyYh1j8XHlttjZJJnO4h2qDrk5q4=.d7588fb9-2f94-458c-bfa6-c3878fec411e@github.com>
Message-ID: <kW1yBSV9G1v638XVumotNDpFlqxWl6TrJxSADh0-o9A=.0b7bf068-90be-4a23-bdb3-8030dc7ffc6c@github.com>

On Thu, 22 Feb 2024 16:15:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
>> 
>> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
>> 
>> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
>> 
>> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use #pragma instead of HIDDEN define

> We had the PR in our SAP internal build/test queue, so issues seen with it.

What issues did you see? Or was that a typo for "no issues"?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1961248385

From mbaesken at openjdk.org  Fri Feb 23 12:38:23 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 23 Feb 2024 12:38:23 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v5]
In-Reply-To: <kW1yBSV9G1v638XVumotNDpFlqxWl6TrJxSADh0-o9A=.0b7bf068-90be-4a23-bdb3-8030dc7ffc6c@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <4EYRe8CRYOZ6oPcfyYh1j8XHlttjZJJnO4h2qDrk5q4=.d7588fb9-2f94-458c-bfa6-c3878fec411e@github.com>
 <kW1yBSV9G1v638XVumotNDpFlqxWl6TrJxSADh0-o9A=.0b7bf068-90be-4a23-bdb3-8030dc7ffc6c@github.com>
Message-ID: <pN1koUwdey6yogGOs3LmVbC7ZeJUVmJNpTtoCKwjRFo=.ac73851f-982c-48a0-b57d-bc62f7d143b9@github.com>

On Fri, 23 Feb 2024 12:33:48 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> > We had the PR in our SAP internal build/test queue, so issues seen with it.
> 
> What issues did you see? Or was that a typo for "no issues"?

Sorry Magnus, tests were fine no issues were observed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1961250951

From ihse at openjdk.org  Fri Feb 23 12:38:23 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 23 Feb 2024 12:38:23 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v5]
In-Reply-To: <hqw0OeOo_jBuqfttrP7zJHFMTcN3yorEcF0Go214L-U=.65c0ea99-c55d-4ed4-ae27-1790e68b417d@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <4EYRe8CRYOZ6oPcfyYh1j8XHlttjZJJnO4h2qDrk5q4=.d7588fb9-2f94-458c-bfa6-c3878fec411e@github.com>
 <hqw0OeOo_jBuqfttrP7zJHFMTcN3yorEcF0Go214L-U=.65c0ea99-c55d-4ed4-ae27-1790e68b417d@github.com>
Message-ID: <7o1sb2wW6T1LX8oN3G2J5JHrzBYCUwemoA6vqfxF5Og=.5fbe541a-371f-470a-a55e-a8a66c3ac630@github.com>

On Fri, 23 Feb 2024 08:18:17 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use #pragma instead of HIDDEN define
>
> src/hotspot/share/oops/accessBackend.cpp line 40:
> 
>> 38: #if defined(TARGET_COMPILER_gcc)
>> 39: // Needed to work around bug in gcc causing these symbols to be visible despite -fvisibility=hidden
>> 40: #pragma GCC visibility push(hidden)
> 
> does it work for you? because it doesn't hide the arraycopy symbols for me. The explicit visibility(hidden) attribute did work.

You are absolutely correct. I thought I checked that it did work, but I must have messed up somehow, because now that I retest, I see that it did not have any effect. I'm reverting that change. Thanks for being attentive!

(Presumably, gcc already knew that it where compiling with visibility hidden, so the pragma did nothing, in contrast with the explicit attribute on individual functions.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1500596597

From ihse at openjdk.org  Fri Feb 23 12:41:18 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 23 Feb 2024 12:41:18 GMT
Subject: RFR: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234 [v3]
In-Reply-To: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
References: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
Message-ID: <TsgvKQoINmIhgo92uwRwBynKrX4hwVicrl1TMoOSK6k=.b07ed6bf-15c7-4834-ba21-2e062d35c4fb@github.com>

> Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) has been integrated, it is possible to do some cleanup. The goal of [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) was to not change any behavior, even if that behavior seemed odd.
> 
> Now let's try to fix that. We can:
> 
> a) remove JNIEXPORT from c2v functions.
> b) make debug.cpp functions exported similarly on all platforms.
> c) remove JNIEXPORT from aarch64 asm debug function.
> 
> Note that this PR is [dependent on](https://mail.openjdk.org/pipermail/jdk-dev/2021-March/005232.html) https://github.com/openjdk/jdk/pull/17955.

Magnus Ihse Bursie 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:

 - Remove jvmci globals
 - 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17967/files
  - new: https://git.openjdk.org/jdk/pull/17967/files/216d0db5..b6bd5f22

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17967&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17967&range=01-02

  Stats: 31 lines in 1 file changed: 4 ins; 7 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/17967.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17967/head:pull/17967

PR: https://git.openjdk.org/jdk/pull/17967

From djelinski at openjdk.org  Fri Feb 23 12:41:55 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 23 Feb 2024 12:41:55 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v6]
In-Reply-To: <wvVBVyQswVhKlZM7Ux8ifRbqpqCoebaGJjqWHzuW6Gw=.67f9d62d-e669-4ade-8d97-94df4eeceed8@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <wvVBVyQswVhKlZM7Ux8ifRbqpqCoebaGJjqWHzuW6Gw=.67f9d62d-e669-4ade-8d97-94df4eeceed8@github.com>
Message-ID: <Q8u6EqPKibxDuixCm6i4jeM1nFybu-tkmoHtjfNKPQw=.2e7c8dfa-a8a1-401d-b772-146878710373@github.com>

On Fri, 23 Feb 2024 12:38:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
>> 
>> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
>> 
>> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
>> 
>> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Use #pragma instead of HIDDEN define"
>   
>   This reverts commit 00e40a7f6e4cdef6592d72b3d08063cdcc41532a.

Great. The only remaining difference I see is that the PR adds the following export:

_ZGRN14AsyncLogWriter4NoneE_@@SUNWprivate_1.1

Any idea what it might be? If not, I guess we can live with that.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1961255985

From jwaters at openjdk.org  Fri Feb 23 12:58:55 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 23 Feb 2024 12:58:55 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v6]
In-Reply-To: <EIXdI32FQTr9GWePU0HfJjQEoQvJm_8u6wTFRo-7p6o=.8e4518c3-4533-43de-99f8-24b9cd5ffde5@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <17uxknoRrcfnUlWwJndQk2AWqvZv4v34JZMVQPpl81w=.34a2c1a8-d251-4f8c-bd12-2f024b4914e6@github.com>
 <28TkIQvEbOiKscThXtUGZ24pcHI4wqrVgy6C2P6_f-4=.ae8dcc41-aedd-441c-a8ad-1526dd56db14@github.com>
 <FfaU4QcwSZnSxWSys6H3lqIO1UHBFKCb5dJ2tmNsR00=.6d492146-71d7-4530-bcdd-e0875bf02927@github.com>
 <A1r4AEShJI_4GfYz3lxkxopCNYuaMF-zhmhuhd493gY=.c112b7c1-5d21-4074-8967-48b48387bd23@github.com>
 <bCCiR8BHjfb_LNAuneO4lfRx1VY4UE8f1irt43V97vQ=.0010380e-f54d-439e-8877-5ba9a75fe71f@github.com>
 <rSSQn-eaJbthjFJBhKKLm9-GuvWLPhA293t5_AThMoE=.7dc91c10-b655-4b24-830c-3bb61ca99ff6@github.com>
 <eKOLOhDFnBx9Ne1hfOYleMnz5iGt8Nb5g6JJ3S7b63Q=.b2744208-182b-47a7-a0ef-5b44061cdfb4@github.com>
 <EIXdI32FQTr9GWePU0HfJjQEoQvJm_8u6wTFRo-7p6o=.8e4518c3-4533-43de-99f8-24b9cd5ffde5@github.com>
Message-ID: <6McYQFZjV07KjPrHScf7jKNAMtsmS9kbfWgI97_rUX8=.20999798-92e9-4e4c-a1ea-24787d2b88ba@github.com>

On Thu, 22 Feb 2024 15:26:34 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I see, seems like it's an unfortunate situation where a fix is hard or even impossible. If we file a gcc bug for it now, it'll get fixed in some insanely new gcc version (such as gcc 15 or 16) and we'd have to jump to that version, which I'm sure no one is going to like :(
>> 
>> Nevertheless, since there are so many instances of it, I suggest #pragma GCC visibility push(hidden) instead of adding a new macro to this file, in my opinion it's somewhat cleaner and also makes the change smaller.
>> 
>> #pragma GCC visibility push(hidden)
>> // Junk that needs hidden visibility to work properly
>> #pragma GCC visibility pop
>> 
>> Also, why TARGET_COMPILER_gcc instead of __GNUC__? Does this have to work with Apple Clang on macOS as well?
>
> This is not an issue with clang, only gcc.
> 
> My understanding was that the proper way to test for compiler in Hotspot code was by using `TARGET_COMPILER_gcc`.
> 
> I can try using the `#pragma` route instead; if it works I agree it is slightly better than to sprinkle `HIDDEN` all over the place.

Drat, I thought the pragma would work. Sorry.

I would file a bug for gcc, but I have no idea what to even describe it as

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1500624847

From sspitsyn at openjdk.org  Fri Feb 23 13:24:21 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 23 Feb 2024 13:24:21 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v15]
In-Reply-To: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
Message-ID: <gc96KK9kvYS-PN72HHvxRSTHJ0w-relQtn7Fy_GO9Eg=.b463e006-b331-4571-8843-cdc9a4e32e5c@github.com>

> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
> The function returns the following structure:
> 
> 
> typedef struct {
>     jthread owner;
>     jint entry_count;
>     jint waiter_count;
>     jthread* waiters;
>     jint notify_waiter_count;
>     jthread* notify_waiters;
> } jvmtiMonitorUsage;
> 
> 
> The following four fields are defined this way:
> 
> waiter_count  [jint] The number of threads waiting to own this monitor
> waiters  [jthread*] The waiter_count waiting threads
> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
> 
> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
> This update makes it right.
> 
> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
> 
> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
> 
>   jvmti/GetObjectMonitorUsage/objmonusage001
>   jvmti/GetObjectMonitorUsage/objmonusage003
> 
> 
> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
> 
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
> 
> 
> 
> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository.
> 
> Also, please see and review the related CSR:
>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
> 
> The Release-Note is:
> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage
>  
> Testing:
>  - tested with mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  improved the ObjectMonitorUsage test to make it more elegant

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17680/files
  - new: https://git.openjdk.org/jdk/pull/17680/files/ef779169..716deae2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=13-14

  Stats: 105 lines in 1 file changed: 39 ins; 44 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/17680.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17680/head:pull/17680

PR: https://git.openjdk.org/jdk/pull/17680

From ayang at openjdk.org  Fri Feb 23 13:30:53 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 23 Feb 2024 13:30:53 GMT
Subject: RFR: 8326006: Allow TEST_VM_FLAGLESS to set flagless mode
In-Reply-To: <0uxFDONrkojHseqjpNszTa-0LmjDpOPKZYozPDJKyOo=.e89913fa-ff13-43f6-95db-bc85222d3c49@github.com>
References: <0uxFDONrkojHseqjpNszTa-0LmjDpOPKZYozPDJKyOo=.e89913fa-ff13-43f6-95db-bc85222d3c49@github.com>
Message-ID: <JBD8HbO-6u6b5jHsC8ELfgQnGRxxdYRaretd-bOSZhc=.5b785ad4-632e-427c-916a-f6452099e362@github.com>

On Fri, 16 Feb 2024 00:44:24 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Allow TEST_VM_FLAGLESS to enable/disable flagless tests execution explicitly.
> Sometimes the tests are executed in the mode that is incompatible with flag-sensitive tests. This mode should be able to disable them explicitly.

Marked as reviewed by ayang (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17886#pullrequestreview-1898117130

From erikj at openjdk.org  Fri Feb 23 13:56:55 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 23 Feb 2024 13:56:55 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v2]
In-Reply-To: <0Inj4SqHl36K4FzxPfbfyA20_7x8GyGMngBfuNEGsf8=.9cba3073-cfdd-43a4-828a-4ec362dcaaf3@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <12hoUFbZkWHBpiXs0TPiMYGW3sSvBX_536mvSSG-y-8=.21abcef9-9a2b-4558-ba19-dddfd7931f9f@github.com>
 <0Inj4SqHl36K4FzxPfbfyA20_7x8GyGMngBfuNEGsf8=.9cba3073-cfdd-43a4-828a-4ec362dcaaf3@github.com>
Message-ID: <-Cqtxv3gK-PQ__1WEPOg_ls4KG0xAeU-yJV1668TUKI=.632a12f6-74c2-4e27-a448-0a5b469cc22e@github.com>

On Thu, 22 Feb 2024 13:36:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I just realized I could keep an extremely simplified linker script ("mapfile") for gcc, and thereby keeping the `@SUNWprivate_1.1` on the exported symbols, and keeping `__bss_start` and friends local. This further minimizes the difference to the existing libjvm.so for gcc builds.

Why do this just for GCC? Shouldn't this be for Linux as we are doing it for backwards compatibility with user JNI libraries.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1961367943

From pchilanomate at openjdk.org  Fri Feb 23 14:02:54 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 23 Feb 2024 14:02:54 GMT
Subject: RFR: 8322962: Upcall stub might go undetected when freezing frames
In-Reply-To: <9wGivvL8XaePg4yOjShuasS2RZzyT2bzUi8EKWs95yQ=.36456962-47a7-4920-9a3a-a15936d4f480@github.com>
References: <9wGivvL8XaePg4yOjShuasS2RZzyT2bzUi8EKWs95yQ=.36456962-47a7-4920-9a3a-a15936d4f480@github.com>
Message-ID: <lBUP2O9fYd2er31KEt5HEixXUryNwUj0cOp-WaYyVag=.96a76ee9-b101-45da-aad5-074e68c6513a@github.com>

On Thu, 22 Feb 2024 14:28:18 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review this simple fix. There is a missing push_cont_fastpath()/pop_cont_fastpath() around the call to Java in the upcall stub. Because of this, if from that upcall a virtual thread tries to yield, and all the other methods in the stack are compiled, we will incorrectly take the freeze fast path and freeze everything in the stack including the native frames. By forcing the slow path instead we will identify the upcall stub and pin the vthread.
> 
> The issue can be easily reproduced by running the modified version of test GetStackTraceALotWhenPinned.java included in this patch. I also tested the fix by running tiers1-3 in mach5. 
> 
> Thanks,
> Patricio

Thanks for the reviews Jorn and Alan.

Could I get a review from @TheRealMDoerr and @RealFYang for the ppc and risc-v changes?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17964#issuecomment-1961374257
PR Comment: https://git.openjdk.org/jdk/pull/17964#issuecomment-1961377180

From djelinski at openjdk.org  Fri Feb 23 14:12:56 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 23 Feb 2024 14:12:56 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v6]
In-Reply-To: <wvVBVyQswVhKlZM7Ux8ifRbqpqCoebaGJjqWHzuW6Gw=.67f9d62d-e669-4ade-8d97-94df4eeceed8@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <wvVBVyQswVhKlZM7Ux8ifRbqpqCoebaGJjqWHzuW6Gw=.67f9d62d-e669-4ade-8d97-94df4eeceed8@github.com>
Message-ID: <bE3-ecBvgYUgjgz58QwIYHW-f8L1332NOyQMH9rE-hQ=.302a7b23-e189-4926-8f10-2f3bfc758f87@github.com>

On Fri, 23 Feb 2024 12:38:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
>> 
>> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
>> 
>> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
>> 
>> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Use #pragma instead of HIDDEN define"
>   
>   This reverts commit 00e40a7f6e4cdef6592d72b3d08063cdcc41532a.

Windows-x64 and Linux-x64 look fine to me.

-------------

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17955#pullrequestreview-1898203882

From mdoerr at openjdk.org  Fri Feb 23 14:42:55 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 23 Feb 2024 14:42:55 GMT
Subject: RFR: 8322962: Upcall stub might go undetected when freezing frames
In-Reply-To: <9wGivvL8XaePg4yOjShuasS2RZzyT2bzUi8EKWs95yQ=.36456962-47a7-4920-9a3a-a15936d4f480@github.com>
References: <9wGivvL8XaePg4yOjShuasS2RZzyT2bzUi8EKWs95yQ=.36456962-47a7-4920-9a3a-a15936d4f480@github.com>
Message-ID: <tCsYqd6FAXA-khjAY_KkUp7WHbRSYEcHRbxMWF3fR9k=.58a348eb-2f70-4979-a864-498c76d8e962@github.com>

On Thu, 22 Feb 2024 14:28:18 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review this simple fix. There is a missing push_cont_fastpath()/pop_cont_fastpath() around the call to Java in the upcall stub. Because of this, if from that upcall a virtual thread tries to yield, and all the other methods in the stack are compiled, we will incorrectly take the freeze fast path and freeze everything in the stack including the native frames. By forcing the slow path instead we will identify the upcall stub and pin the vthread.
> 
> The issue can be easily reproduced by running the modified version of test GetStackTraceALotWhenPinned.java included in this patch. I also tested the fix by running tiers1-3 in mach5. 
> 
> Thanks,
> Patricio

LGTM. Test is passing on linux PPC64le.

-------------

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17964#pullrequestreview-1898269354

From epeter at openjdk.org  Fri Feb 23 15:29:24 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 23 Feb 2024 15:29:24 GMT
Subject: RFR: 8325095: C2: bailout message broken: ResourceArea allocated
 string used after free [v4]
In-Reply-To: <8Bl6JSxb-fd1xAsKOMzBakRFuruoqJykP7JEn57k6qY=.717f89af-2aa7-439b-afd1-768dd39f51da@github.com>
References: <8Bl6JSxb-fd1xAsKOMzBakRFuruoqJykP7JEn57k6qY=.717f89af-2aa7-439b-afd1-768dd39f51da@github.com>
Message-ID: <J8LWcJ4aGOwwgGNT2X4jYVptYA-mFQE1B0olF9zJFF4=.d71df70a-8424-463c-ae6c-3b0ffd1444dd@github.com>

> **Problem**
> Bailout `failure_reason` strings used to be either `nullptr` or a static string. But with [JDK-8303951](https://bugs.openjdk.org/browse/JDK-8303951) I had introduced dynamic strings (e.g. formatted using `stringStream::as_string()`). These dynamic strings were ResourceArea allocated, and have a very limited life-span, i.e. withing the most recent ResourceMark scope. The pointer is passed to `Compile::_failure_reason`, which already might leave that ResourceMark scope, and the pointer is invalid. And then the pointer is further passed to `ciEnv::_failure_reason`. And finally, it even gets passed up to `CompileBroker::invoke_compiler_on_method`. When the string is finally printed for the bailout message, we already left original `ResourceMark` scope, and also the `Compile` and `ciEnv` scopes. The pointer now points to basically random data.
> 
> **Solution**
> Whenever a string is passed to an outer scope, I make a CHeap copy, and the outer scope is the owner of that copy.
> This way every scope is the owner of its own copy, and can allocate and deallocate according to its own strategy safely.
> 
> I introduced a utility class `CHeapStringHolder`:
>  - `set`: make local copy on CHeap.
>  - `clear`: free local copy. We before `set`, and in the destructor. Thus, when the holder goes out of scope, the memory is automatically freed.
> 
> We have these 4 scopes:
> - `ResourceMark`: It allocates from `ResourcArea`, and deallocation is taken care at the end of the ResourceMark scope.
> - `Compile`: We turn the `_failure_reason` from a `char*` into a `CHeapStringHolder`. We set `_failure_reason` while the `ResourceMark` is live.
> - `ciEnv`: We turn the `_failure_reason` from a `char*` into a `CHeapStringHolder`. We set `_failure_reason` while `Compile` is live.
> - `CompileTask`: We used to just set `failure_reason`, which assumes that the string is static or elsewhere managed. Now I use pattern available in other places of `CompileBroker::invoke_compiler_on_method`: duplicate the string with `os::strdup` from some other scope, and set `reason_on_C_heap = true`, which means that we are the owner of that copy, and are responsible for freeing it later. Not sure if that is a nice pattern, but I don't want to refactor that code and it does what I need it to do.

Emanuel Peter 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 'master' into JDK-8325095
 - restore code to previous shape
 - more review suggestion responses
 - address review suggestions
 - remove OrderAccess::storestore() bc single threaded only
 - strcmp for MemStat
 - cleanup debug prints
 - Merge branch 'master' into JDK-8325095
 - more fix
 - copy string from ciEnv
 - ... and 5 more: https://git.openjdk.org/jdk/compare/02e7dee3...00bcb277

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17710/files
  - new: https://git.openjdk.org/jdk/pull/17710/files/f37b66ba..00bcb277

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17710&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17710&range=02-03

  Stats: 27581 lines in 664 files changed: 11671 ins; 11277 del; 4633 mod
  Patch: https://git.openjdk.org/jdk/pull/17710.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17710/head:pull/17710

PR: https://git.openjdk.org/jdk/pull/17710

From epeter at openjdk.org  Fri Feb 23 15:43:07 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 23 Feb 2024 15:43:07 GMT
Subject: RFR: 8325095: C2: bailout message broken: ResourceArea allocated
 string used after free [v5]
In-Reply-To: <8Bl6JSxb-fd1xAsKOMzBakRFuruoqJykP7JEn57k6qY=.717f89af-2aa7-439b-afd1-768dd39f51da@github.com>
References: <8Bl6JSxb-fd1xAsKOMzBakRFuruoqJykP7JEn57k6qY=.717f89af-2aa7-439b-afd1-768dd39f51da@github.com>
Message-ID: <H5L7dK8pvxeFWm36_PfFd7yRTDsD9ayhCVOQX1VOnPg=.d8466a65-7a1a-4429-838e-800b13671bd4@github.com>

> **Problem**
> Bailout `failure_reason` strings used to be either `nullptr` or a static string. But with [JDK-8303951](https://bugs.openjdk.org/browse/JDK-8303951) I had introduced dynamic strings (e.g. formatted using `stringStream::as_string()`). These dynamic strings were ResourceArea allocated, and have a very limited life-span, i.e. withing the most recent ResourceMark scope. The pointer is passed to `Compile::_failure_reason`, which already might leave that ResourceMark scope, and the pointer is invalid. And then the pointer is further passed to `ciEnv::_failure_reason`. And finally, it even gets passed up to `CompileBroker::invoke_compiler_on_method`. When the string is finally printed for the bailout message, we already left original `ResourceMark` scope, and also the `Compile` and `ciEnv` scopes. The pointer now points to basically random data.
> 
> **Solution**
> Whenever a string is passed to an outer scope, I make a CHeap copy, and the outer scope is the owner of that copy.
> This way every scope is the owner of its own copy, and can allocate and deallocate according to its own strategy safely.
> 
> I introduced a utility class `CHeapStringHolder`:
>  - `set`: make local copy on CHeap.
>  - `clear`: free local copy. We before `set`, and in the destructor. Thus, when the holder goes out of scope, the memory is automatically freed.
> 
> We have these 4 scopes:
> - `ResourceMark`: It allocates from `ResourcArea`, and deallocation is taken care at the end of the ResourceMark scope.
> - `Compile`: We turn the `_failure_reason` from a `char*` into a `CHeapStringHolder`. We set `_failure_reason` while the `ResourceMark` is live.
> - `ciEnv`: We turn the `_failure_reason` from a `char*` into a `CHeapStringHolder`. We set `_failure_reason` while `Compile` is live.
> - `CompileTask`: We used to just set `failure_reason`, which assumes that the string is static or elsewhere managed. Now I use pattern available in other places of `CompileBroker::invoke_compiler_on_method`: duplicate the string with `os::strdup` from some other scope, and set `reason_on_C_heap = true`, which means that we are the owner of that copy, and are responsible for freeing it later. Not sure if that is a nice pattern, but I don't want to refactor that code and it does what I need it to do.

Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:

  include precompiled.hpp, otherwise windows build fails

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17710/files
  - new: https://git.openjdk.org/jdk/pull/17710/files/00bcb277..894a642c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17710&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17710&range=03-04

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17710.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17710/head:pull/17710

PR: https://git.openjdk.org/jdk/pull/17710

From a.popov.tmb at gmail.com  Fri Feb 23 16:32:49 2024
From: a.popov.tmb at gmail.com (Aleksandr Popov)
Date: Fri, 23 Feb 2024 17:32:49 +0100
Subject: Resolving super interface in different contexts depending on the
 child class
Message-ID: <CAGzTNj5WxZbx0AeAkTeDpXNm83kn0_DX4d9bZ4CPDgvuJ17pZA@mail.gmail.com>

Hi! In the following test case I've investigated how Hotspot loads classes
into the loaders.
And found out that the inheritance chain could affect the result.

//--------------------------------------------------------------------------
public class SimpleTest {
    public static int compare(ScheduledFutureTask o1, ScheduledFutureTask
o2) {
        return o1.compareTo(o2);
    }

    public static void main(String[] args) {
        ScheduledFutureTask instances0 = new ScheduledFutureTask();
        ScheduledFutureTask instances1 = new ScheduledFutureTask();
        compare(instances0, instances1);
    }
}

final class ScheduledFutureTask implements ScheduledFuture<Void> {
...
    @Override
    public int compareTo(Delayed o) {
        if (this == o) {
            return 0;
        }
    }
}
//--------------------------------------------------------------------------


   - If *ScheduledFutureTask* class implements
   *java.util.concurrent.ScheduledFuture *interface,

which implements *java.util.concurrent.Delayed* interface: *[application
class -> core class -> core class],*
then the *Delayed *interface would be loaded into the boot class loader,
since it's resolved in the context of the core class.

I've added some logs to track class resolving:
# parse interfaces of class ScheduledFutureTask, [APP] loader
# parse interfaces of class java/util/concurrent/ScheduledFuture, [BOOT]
loader
# parse interfaces of class java/util/concurrent/Delayed, [BOOT] loader
# Adding java/util/concurrent/Delayed to dictionary [BOOT]


   - If we replace core class in the chain with an application one:
*[application
   class -> application class -> core class], *

then the *Delayed *interface would be loaded into both class loaders, since
it would be resolved in the context of the application class:

# parse interfaces of class ScheduledFutureTask, [application class loader]
# parse interfaces of class Interface1, [application class loader]
# parse interfaces of class java/util/concurrent/Delayed, [boot class
loader]
# Adding java/util/concurrent/Delayed to dictionary [boot class loader]
# Adding java/util/concurrent/Delayed to dictionary [application class
loader]


   - Theoretically, this difference could affect the result of the
   has_unloaded_classes_in_signature() call

for the ScheduledFutureTask::compareTo method.

final class ScheduledFutureTask implements ScheduledFuture<Void> {
...
    @Override
    public int compareTo(Delayed o) {
        if (this == o) {
            return 0;
        }
    }
}

Because in the first case (application class -> core class -> core class)
we have unloaded *java/util/concurrent/Delayed*
interface in the context of the accessing class, which was loaded into the
application class loader.

So my question is: why is it correct to have class loaded into different
class loaders depending on the inheritance chain?
Or maybe it's intentionally resolved somewhere in the code?

Note that SystemDictionary::check_signature_loaders doesn't add loader
constraints to the interface, since the caller and callee loaders are the
same in this case: both application loaders.
Thank you!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20240223/1de8a552/attachment-0001.htm>

From matsaave at openjdk.org  Fri Feb 23 16:59:13 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Fri, 23 Feb 2024 16:59:13 GMT
Subject: RFR: 8251330: Reorder CDS archived heap to speed up relocation
 [v2]
In-Reply-To: <ZesL5badknO18z5YBr0f1X7pYtMiSWHzKcRJuMfR5kM=.ef3bc428-2461-4501-a30e-e38980fcf5ad@github.com>
References: <ZesL5badknO18z5YBr0f1X7pYtMiSWHzKcRJuMfR5kM=.ef3bc428-2461-4501-a30e-e38980fcf5ad@github.com>
Message-ID: <Q0gZhpvj5HmF1FwO8CXv6XeRm4V_IcXkPXvGQi6o0EI=.6c226131-534e-4b0f-93e6-69963971f76e@github.com>

> We should reorder the archived heap to segregate the objects that don't need marking. This will save space in the archive and improve start-up time
> 
> This patch reorders the archived heap to segregate the objects that don't need marking. The leading zeros present in the bitmaps thanks to the reordering can be easily removed, and this the size of the archive is reduced.
> 
> Given that the bitmaps are word aligned, some leading zeroes will remain. Verified with tier 1-5 tests.
> 
> Metrics, courtesy of @iklam :
> ```calculate_oopmap: objects = 15262 (507904 bytes, 332752 bytes don't need marking), embedded oops = 8408, nulls = 54
> Oopmap = 15872 bytes
> 
> calculate_oopmap: objects = 4590 (335872 bytes, 178120 bytes don't need marking), embedded oops = 46487, nulls = 29019
> Oopmap = 10496 bytes
> 
> (332752 + 178120) / (507904 + 335872.0) = 0.6054592688106796 
> More than 60% of the space used by the archived heap doesn't need to be marked by the oopmap. 
> 
> $ java -Xshare:dump -Xlog:cds+map | grep lead
> [3.777s][info][cds,map] - heap_oopmap_leading_zeros: 143286
> [3.777s][info][cds,map] - heap_ptrmap_leading_zeros: 50713
> 
> So we can reduce the "bm" region by (143286 + 50713) / 8 = 24249 bytes.
> 
> Current output:
> $ java -XX:+UseNewCode -Xshare:dump -Xlog:cds+map | grep lead 
> [5.339s][info][cds,map] - heap_oopmap_leading_zeros:      26
> [5.339s][info][cds,map] - heap_ptrmap_leading_zeros:      8

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 29 additional commits since the last revision:

 - Added helper function
 - Merge branch 'master' into reorder_archive_heap_8251330
 - Removed commented code
 - Adjusted word alignment in slice method
 - Merge branch 'master' into reorder_archive_heap_8251330
 - Merge branch 'master' into reorder_archive_heap_8251330
 - Fixed sorting of equal rank objs
 - Only set zeros once
 - Improved setting leading zeros
 - Merge branch 'master' into reorder_archive_heap_8251330
 - ... and 19 more: https://git.openjdk.org/jdk/compare/8c9a72c9...bb1409dd

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17350/files
  - new: https://git.openjdk.org/jdk/pull/17350/files/bf759be8..bb1409dd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17350&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17350&range=00-01

  Stats: 31732 lines in 903 files changed: 13751 ins; 11726 del; 6255 mod
  Patch: https://git.openjdk.org/jdk/pull/17350.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17350/head:pull/17350

PR: https://git.openjdk.org/jdk/pull/17350

From cjplummer at openjdk.org  Fri Feb 23 17:01:55 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 23 Feb 2024 17:01:55 GMT
Subject: RFR: JDK-8325530: Vague error message when
 com.sun.tools.attach.VirtualMachine fails to load agent library [v4]
In-Reply-To: <BP-HsRnMDXD_m6sqmQMAdXOvQTCDFJ3SJ24pEXD8LzI=.6f4a2992-c6a5-497b-b0e8-2458513fc2cf@github.com>
References: <s1rZKr_Bt8tzCP2cMyFv0oe7pTD1DNzGLaIsGZdXffY=.596d50f2-12b6-4bba-ab30-a26b697fb970@github.com>
 <BP-HsRnMDXD_m6sqmQMAdXOvQTCDFJ3SJ24pEXD8LzI=.6f4a2992-c6a5-497b-b0e8-2458513fc2cf@github.com>
Message-ID: <ytLkqacqAtO9-Yd6ii4o__Pj5yqfkBIj9x5kpQoNKeA=.0569e2d2-6ab6-43b6-8564-d2fd682373c8@github.com>

On Thu, 22 Feb 2024 23:31:16 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> VirtualMachine.loadAgentPath/loadAgentLibrary can fail with AgentLoadException in 2 cases:
>> - attach listener returns error; in the case the exception is thrown from HotSpotVirtualMachine.processCompletionStatus (called from HotSpotVirtualMachine.execute);
>> - attach listener returns success, but reply does not contain Agent_onAttach return code ("return code: %d" message).
>> 
>> before jdk21 if attach listener fails to load required library, it returned error (case 1)
>> from jdk21 attach listener always returns success (case 2)
>> Both cases are ok, but for 2nd case HotSpotVirtualMachine.loadAgentLibrary read only single line of the response message, so exception message didn't contain error details.
>> 
>> The fix updates HotSpotVirtualMachine.loadAgentLibrary to read the whole response message.
>> Walking through the code, fixed some other minor things in attach listener and attach API implementation (commented in the code)
>> 
>> Testing:
>>   - test/jdk/com/sun/tools;
>>   - tier1,tier2,tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed readErrorMessage()

Marked as reviewed by cjplummer (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17954#pullrequestreview-1898562404

From sspitsyn at openjdk.org  Fri Feb 23 17:46:08 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 23 Feb 2024 17:46:08 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v16]
In-Reply-To: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
Message-ID: <5gGbuzIvk8-lozRDGmJlr4G1cnrsyyUXMOBOG_VB3i4=.b5ee3bb3-fd1c-4639-9ca1-0a2c7c8dd19b@github.com>

> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
> The function returns the following structure:
> 
> 
> typedef struct {
>     jthread owner;
>     jint entry_count;
>     jint waiter_count;
>     jthread* waiters;
>     jint notify_waiter_count;
>     jthread* notify_waiters;
> } jvmtiMonitorUsage;
> 
> 
> The following four fields are defined this way:
> 
> waiter_count  [jint] The number of threads waiting to own this monitor
> waiters  [jthread*] The waiter_count waiting threads
> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
> 
> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
> This update makes it right.
> 
> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
> 
> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
> 
>   jvmti/GetObjectMonitorUsage/objmonusage001
>   jvmti/GetObjectMonitorUsage/objmonusage003
> 
> 
> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
> 
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
> 
> 
> 
> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository.
> 
> Also, please see and review the related CSR:
>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
> 
> The Release-Note is:
> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage
>  
> Testing:
>  - tested with mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with two additional commits since the last revision:

 - fix potential sync gap in the test ObjectMonitorUsage
 - improve ObjectMonitorUsage test native agent output

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17680/files
  - new: https://git.openjdk.org/jdk/pull/17680/files/716deae2..fd507055

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=14-15

  Stats: 146 lines in 2 files changed: 114 ins; 20 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/17680.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17680/head:pull/17680

PR: https://git.openjdk.org/jdk/pull/17680

From lmesnik at openjdk.org  Fri Feb 23 18:06:18 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 23 Feb 2024 18:06:18 GMT
Subject: RFR: 8326006: Allow TEST_VM_FLAGLESS to set flagless mode [v2]
In-Reply-To: <0uxFDONrkojHseqjpNszTa-0LmjDpOPKZYozPDJKyOo=.e89913fa-ff13-43f6-95db-bc85222d3c49@github.com>
References: <0uxFDONrkojHseqjpNszTa-0LmjDpOPKZYozPDJKyOo=.e89913fa-ff13-43f6-95db-bc85222d3c49@github.com>
Message-ID: <4b9wPAvi4DEBKkgqEPA7_GmI8zCXCGP1JbWIyZHImAQ=.17dee3f2-6407-419c-a888-16c722fe39d9@github.com>

> Allow TEST_VM_FLAGLESS to enable/disable flagless tests execution explicitly.
> Sometimes the tests are executed in the mode that is incompatible with flag-sensitive tests. This mode should be able to disable them explicitly.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  fixed according to comments.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17886/files
  - new: https://git.openjdk.org/jdk/pull/17886/files/65859eed..b9aeeb77

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17886&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17886&range=00-01

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17886.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17886/head:pull/17886

PR: https://git.openjdk.org/jdk/pull/17886

From kvn at openjdk.org  Fri Feb 23 18:33:56 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 23 Feb 2024 18:33:56 GMT
Subject: RFR: 8325095: C2: bailout message broken: ResourceArea allocated
 string used after free [v2]
In-Reply-To: <22-O7o2m6ZAJx3YmbAuY2dYcN47gTdeAFUu0m7SKy5Q=.7909c9ed-872f-4d95-9e78-d725f5deb002@github.com>
References: <8Bl6JSxb-fd1xAsKOMzBakRFuruoqJykP7JEn57k6qY=.717f89af-2aa7-439b-afd1-768dd39f51da@github.com>
 <iqVK2jP6-y3NweZYd_Y6Eo39GUH9hf8gFugp8aq3-dw=.54a735a9-9cf2-411d-89aa-19dcbef22937@github.com>
 <fdijEO4HOMxS2z2kj0PKvK9HfGBjSk4MqjMZVAS-MDY=.f8715719-f21c-4ed4-a3f5-7fee830b667b@github.com>
 <22-O7o2m6ZAJx3YmbAuY2dYcN47gTdeAFUu0m7SKy5Q=.7909c9ed-872f-4d95-9e78-d725f5deb002@github.com>
Message-ID: <5TgeG3ZAKwf86zhRI10h3kGIO7-Dl_HTiHQjFe33iP4=.d47f443f-14db-458e-a449-d6775f7ef2dd@github.com>

On Fri, 23 Feb 2024 08:49:47 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>About Logging, in a future RFE:
@vnkozlov suggested to always UL failures immediately. The question is where I should do that. At ciEnv::record_method_not_compilable only? Or also in Compile::record_method_not_compilable?

`Compile::record_method_not_compilable()` calls `ciEnv::record_method_not_compilable()` so you need only add it to ciEnv.

>And @vnkozlov also suggested only to report one (a single) failure reason at the very end, presumably at the CompileTask level. Does that mean you would still overwrite the less important failures with more important ones in ciEnv, like we do currently?

I suggest to leave the normal report code as it is now (one failure). And if we need additional information we will use UL when we implement it.

Most ciEnv failures are recorded (`record_failure`) during publishing compiled code in `ciEnv::register_method()` after compilation is done and it did not have failures.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17710#issuecomment-1961804948

From sspitsyn at openjdk.org  Fri Feb 23 18:40:10 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 23 Feb 2024 18:40:10 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v17]
In-Reply-To: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
Message-ID: <kEiNDWiDbyYABSPUVtj2IL1bDqJtpb_YX_zVNNwGZ5s=.1107a5ab-4ce3-44ba-ac5d-bb266dd696f0@github.com>

> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
> The function returns the following structure:
> 
> 
> typedef struct {
>     jthread owner;
>     jint entry_count;
>     jint waiter_count;
>     jthread* waiters;
>     jint notify_waiter_count;
>     jthread* notify_waiters;
> } jvmtiMonitorUsage;
> 
> 
> The following four fields are defined this way:
> 
> waiter_count  [jint] The number of threads waiting to own this monitor
> waiters  [jthread*] The waiter_count waiting threads
> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
> 
> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
> This update makes it right.
> 
> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
> 
> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
> 
>   jvmti/GetObjectMonitorUsage/objmonusage001
>   jvmti/GetObjectMonitorUsage/objmonusage003
> 
> 
> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
> 
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
> 
> 
> 
> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository.
> 
> Also, please see and review the related CSR:
>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
> 
> The Release-Note is:
> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage
>  
> Testing:
>  - tested with mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  fix a typo in libObjectMonitorUsage.cpp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17680/files
  - new: https://git.openjdk.org/jdk/pull/17680/files/fd507055..091fd29c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=15-16

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17680.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17680/head:pull/17680

PR: https://git.openjdk.org/jdk/pull/17680

From duke at openjdk.org  Fri Feb 23 19:57:05 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Fri, 23 Feb 2024 19:57:05 GMT
Subject: RFR: 8325991: Accelerate Poly1305 on x86_64 using AVX2
 instructions [v8]
In-Reply-To: <IyoM1HY_rvNWwo4GxcV1yQleB3vrgaLwsAlOCEpLKqs=.1d50225c-8fe1-4a84-af56-274632b2b653@github.com>
References: <IyoM1HY_rvNWwo4GxcV1yQleB3vrgaLwsAlOCEpLKqs=.1d50225c-8fe1-4a84-af56-274632b2b653@github.com>
Message-ID: <prQNjTkFnG3QH0uay0E6mUCMr9DLeL-JN5vv8oXtXEE=.132b9b6c-880b-4327-a7b1-208869584c12@github.com>

> The goal of this PR is to accelerate the Poly1305 algorithm using AVX2 instructions (including IFMA) for x86_64 CPUs.
> 
> This implementation is directly based on the AVX2 Poly1305 hash computation as implemented in Intel(R) Multi-Buffer Crypto for IPsec Library (url: https://github.com/intel/intel-ipsec-mb/blob/main/lib/avx2_t3/poly_fma_avx2.asm)

Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:

  fix checks for vpmadd52*

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17881/files
  - new: https://git.openjdk.org/jdk/pull/17881/files/dddeb6fb..9c836e54

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17881&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17881&range=06-07

  Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/17881.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17881/head:pull/17881

PR: https://git.openjdk.org/jdk/pull/17881

From duke at openjdk.org  Fri Feb 23 19:57:06 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Fri, 23 Feb 2024 19:57:06 GMT
Subject: RFR: 8325991: Accelerate Poly1305 on x86_64 using AVX2
 instructions [v4]
In-Reply-To: <gMijC2Y9pJNAg-yyTilMn1PjlQOiDufE5WXFhlCshpM=.3e712c88-11da-4ed2-92db-27c4ff2a4b7e@github.com>
References: <IyoM1HY_rvNWwo4GxcV1yQleB3vrgaLwsAlOCEpLKqs=.1d50225c-8fe1-4a84-af56-274632b2b653@github.com>
 <LLvSSnrEIYHk49CCs14ZPwXiBJYndwUwRSl6X-kajqI=.2ad38d7a-47fd-4e37-9db6-49e812ce97c5@github.com>
 <gMijC2Y9pJNAg-yyTilMn1PjlQOiDufE5WXFhlCshpM=.3e712c88-11da-4ed2-92db-27c4ff2a4b7e@github.com>
Message-ID: <ldxBMS8teMhlvfAiKa9JPtT7Pg9uO79XBpPGPk8v0X8=.f7e858e6-fcd6-4b2a-92f0-0ca7c5eaa932@github.com>

On Thu, 22 Feb 2024 23:56:01 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove unused uniions and fix uses_vl
>
> src/hotspot/cpu/x86/assembler_x86.cpp line 5195:
> 
>> 5193:   assert(VM_Version::supports_avxifma() && (vector_len == AVX_128bit || vector_len == AVX_256bit), "");
>> 5194:   InstructionMark im(this);
>> 5195:   InstructionAttr attributes(vector_len, /* rex_w */ true, /* legacy_mode */ false, /* no_mask_reg */ false, /* uses_vl */ false);
> 
> uses_vl should be true for all vpmadd52 instructions. 
> The assert could be coded as:
> assert(vector_len == AVX_512bit ? VM_Version::supports_evex() : VM_Version::supports_avxifma(), "");

Please see the updated checks as suggested.

> src/hotspot/cpu/x86/vm_version_x86.cpp line 1360:
> 
>> 1358: 
>> 1359: #ifdef _LP64
>> 1360:   if ((supports_avx512ifma() && supports_avx512vlbw() && MaxVectorSize >= 64) || (supports_avxifma() && MaxVectorSize >= 32))  {
> 
> This could be:
> if ((supports_avx512ifma() && supports_avx512vlbw()) || (supports_avxifma()))  {

Please see the code updated as suggested.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17881#discussion_r1501108764
PR Review Comment: https://git.openjdk.org/jdk/pull/17881#discussion_r1501109029

From lmesnik at openjdk.org  Fri Feb 23 20:00:57 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 23 Feb 2024 20:00:57 GMT
Subject: Integrated: 8326006: Allow TEST_VM_FLAGLESS to set flagless mode
In-Reply-To: <0uxFDONrkojHseqjpNszTa-0LmjDpOPKZYozPDJKyOo=.e89913fa-ff13-43f6-95db-bc85222d3c49@github.com>
References: <0uxFDONrkojHseqjpNszTa-0LmjDpOPKZYozPDJKyOo=.e89913fa-ff13-43f6-95db-bc85222d3c49@github.com>
Message-ID: <5zoAKPHdHWxbYm6LH0LVlQlsElKS5lWTmZs10LbDsMg=.e98c1325-297b-4f35-bff3-d3ba0d2281be@github.com>

On Fri, 16 Feb 2024 00:44:24 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Allow TEST_VM_FLAGLESS to enable/disable flagless tests execution explicitly.
> Sometimes the tests are executed in the mode that is incompatible with flag-sensitive tests. This mode should be able to disable them explicitly.

This pull request has now been integrated.

Changeset: d10f277b
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d10f277bd39bb5ac9bd48939c916de607fef8ace
Stats:     4 lines in 1 file changed: 1 ins; 0 del; 3 mod

8326006: Allow TEST_VM_FLAGLESS to set flagless mode

Reviewed-by: tschatzl, ayang

-------------

PR: https://git.openjdk.org/jdk/pull/17886

From kvn at openjdk.org  Fri Feb 23 20:25:54 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 23 Feb 2024 20:25:54 GMT
Subject: RFR: 8325095: C2: bailout message broken: ResourceArea allocated
 string used after free [v5]
In-Reply-To: <H5L7dK8pvxeFWm36_PfFd7yRTDsD9ayhCVOQX1VOnPg=.d8466a65-7a1a-4429-838e-800b13671bd4@github.com>
References: <8Bl6JSxb-fd1xAsKOMzBakRFuruoqJykP7JEn57k6qY=.717f89af-2aa7-439b-afd1-768dd39f51da@github.com>
 <H5L7dK8pvxeFWm36_PfFd7yRTDsD9ayhCVOQX1VOnPg=.d8466a65-7a1a-4429-838e-800b13671bd4@github.com>
Message-ID: <a2TkPbfycsIrvwiy3AOu2upgSRxaBPkLcjx-m_erhBk=.dbf2beb3-cdf6-4c7e-b99c-f3197a5efcb8@github.com>

On Fri, 23 Feb 2024 15:43:07 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> **Problem**
>> Bailout `failure_reason` strings used to be either `nullptr` or a static string. But with [JDK-8303951](https://bugs.openjdk.org/browse/JDK-8303951) I had introduced dynamic strings (e.g. formatted using `stringStream::as_string()`). These dynamic strings were ResourceArea allocated, and have a very limited life-span, i.e. withing the most recent ResourceMark scope. The pointer is passed to `Compile::_failure_reason`, which already might leave that ResourceMark scope, and the pointer is invalid. And then the pointer is further passed to `ciEnv::_failure_reason`. And finally, it even gets passed up to `CompileBroker::invoke_compiler_on_method`. When the string is finally printed for the bailout message, we already left original `ResourceMark` scope, and also the `Compile` and `ciEnv` scopes. The pointer now points to basically random data.
>> 
>> **Solution**
>> Whenever a string is passed to an outer scope, I make a CHeap copy, and the outer scope is the owner of that copy.
>> This way every scope is the owner of its own copy, and can allocate and deallocate according to its own strategy safely.
>> 
>> I introduced a utility class `CHeapStringHolder`:
>>  - `set`: make local copy on CHeap.
>>  - `clear`: free local copy. We before `set`, and in the destructor. Thus, when the holder goes out of scope, the memory is automatically freed.
>> 
>> We have these 4 scopes:
>> - `ResourceMark`: It allocates from `ResourcArea`, and deallocation is taken care at the end of the ResourceMark scope.
>> - `Compile`: We turn the `_failure_reason` from a `char*` into a `CHeapStringHolder`. We set `_failure_reason` while the `ResourceMark` is live.
>> - `ciEnv`: We turn the `_failure_reason` from a `char*` into a `CHeapStringHolder`. We set `_failure_reason` while `Compile` is live.
>> - `CompileTask`: We used to just set `failure_reason`, which assumes that the string is static or elsewhere managed. Now I use pattern available in other places of `CompileBroker::invoke_compiler_on_method`: duplicate the string with `os::strdup` from some other scope, and set `reason_on_C_heap = true`, which means that we are the owner of that copy, and are responsible for freeing it later. Not sure if that is a nice pattern, but I don't want to refactor that code and it does what I need it to do.
>
> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   include precompiled.hpp, otherwise windows build fails

This version looks good to me.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17710#pullrequestreview-1898872202

From duke at openjdk.org  Fri Feb 23 22:11:15 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Fri, 23 Feb 2024 22:11:15 GMT
Subject: RFR: 8325991: Accelerate Poly1305 on x86_64 using AVX2
 instructions [v9]
In-Reply-To: <IyoM1HY_rvNWwo4GxcV1yQleB3vrgaLwsAlOCEpLKqs=.1d50225c-8fe1-4a84-af56-274632b2b653@github.com>
References: <IyoM1HY_rvNWwo4GxcV1yQleB3vrgaLwsAlOCEpLKqs=.1d50225c-8fe1-4a84-af56-274632b2b653@github.com>
Message-ID: <UjRcAmP61JeaSA1TNkF4Wqg-cN9QpJcpUzW0sh7kOic=.b2e4486f-9a15-49bb-865d-42f212b33475@github.com>

> The goal of this PR is to accelerate the Poly1305 algorithm using AVX2 instructions (including IFMA) for x86_64 CPUs.
> 
> This implementation is directly based on the AVX2 Poly1305 hash computation as implemented in Intel(R) Multi-Buffer Crypto for IPsec Library (url: https://github.com/intel/intel-ipsec-mb/blob/main/lib/avx2_t3/poly_fma_avx2.asm)

Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:

  add cpuinfo test for avx_ifma

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17881/files
  - new: https://git.openjdk.org/jdk/pull/17881/files/9c836e54..16712108

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17881&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17881&range=07-08

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17881.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17881/head:pull/17881

PR: https://git.openjdk.org/jdk/pull/17881

From duke at openjdk.org  Fri Feb 23 22:11:15 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Fri, 23 Feb 2024 22:11:15 GMT
Subject: RFR: 8325991: Accelerate Poly1305 on x86_64 using AVX2
 instructions [v4]
In-Reply-To: <CSR2pFjPhmJA_7LmvdETc8EZY2w2OBp9j0endV72HHE=.b7818181-cc5c-40ed-9cec-1d206223d8da@github.com>
References: <IyoM1HY_rvNWwo4GxcV1yQleB3vrgaLwsAlOCEpLKqs=.1d50225c-8fe1-4a84-af56-274632b2b653@github.com>
 <LLvSSnrEIYHk49CCs14ZPwXiBJYndwUwRSl6X-kajqI=.2ad38d7a-47fd-4e37-9db6-49e812ce97c5@github.com>
 <CSR2pFjPhmJA_7LmvdETc8EZY2w2OBp9j0endV72HHE=.b7818181-cc5c-40ed-9cec-1d206223d8da@github.com>
Message-ID: <wdBqIMxOFMjfKwMTRT6_zjYKKpB5237rXajv995OvcE=.119f284e-ce80-42d8-8a7e-33593fb1c3d4@github.com>

On Fri, 23 Feb 2024 00:06:28 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> You will also need to update the test/lib-test/jdk/test/whitebox/CPUInfoTest.java to handle avx_ifma. Rest of the PR looks good to me.

Please see the CPUInfoTest.java updated to use avx_ifma.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17881#issuecomment-1962066564

From tonyp at openjdk.org  Fri Feb 23 22:35:04 2024
From: tonyp at openjdk.org (Antonios Printezis)
Date: Fri, 23 Feb 2024 22:35:04 GMT
Subject: RFR: 8322179: RISC-V: Implement SHA-1 intrinsic [v13]
In-Reply-To: <3PjX6O1hKuQWqOV_mSS_a2o8pJJfyl5VeApdovyjSvk=.0dad6f46-ffac-49e2-91cc-94c88d569193@github.com>
References: <PyIXzENfiHysFS3IyZn3FDNQpV7Ua2L6OmjiXq9wRoU=.cf74a45e-c94b-4f7b-8768-d10d55e2ce1d@github.com>
 <3PjX6O1hKuQWqOV_mSS_a2o8pJJfyl5VeApdovyjSvk=.0dad6f46-ffac-49e2-91cc-94c88d569193@github.com>
Message-ID: <4OzT8N5D898swa1PZUiGcBkEQ5GMEINUd92aHFqWbMw=.3741f53c-e1c2-43fa-ae37-431ecb60689f@github.com>

On Fri, 23 Feb 2024 11:30:07 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you review this patch to implement SHA-1 intrinsic for riscv?
>> Thanks!
>> 
>> 
>> ## Test
>> 
>> ### Functionality
>> 
>> tests under `test/hotspot/jtreg/compiler/intrinsics/sha`
>> tests found via `find test/jdk -iname "*SHA1*.java"`
>> 
>> ### Performance
>> 
>> tested on `T-HEAD Light Lichee Pi 4A`
>> 
>> JMH_PARAMS="-f 1 -wi 10 -i 20" // for every loop of jmh test
>> 
>> benchmark tests `MessageDigests.java GetMessageDigest.java MessageDigestBench.java MacBench.java` which are under `test/micro/org/openjdk/bench/`, more spcifically `TESTS="MessageDigests.digest MessageDigests.getAndDigest MessageDigestBench.digest"`
>> 
>> 
>> // After
>> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1        64     DEFAULT  avgt   20      1845.446 ?     27.052  ns/op
>> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    181455.350 ?    532.258  ns/op
>> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2447.674 ?     10.239  ns/op
>> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    182896.083 ?   1242.774  ns/op
>> o.o.b.javax.crypto.small.MessageDigestBench.digest         SHA1     1048576             N/A       N/A              avgt   20  11599227.792 ? 121442.390  ns/op
>> // Before
>> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2352.475 ?    11.198  ns/op
>> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    188495.684 ?  1467.942  ns/op
>> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2437.347 ?     6.398  ns/op
>> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    196086.570 ?  1140.998  ns/op
>> o.o.b.javax.crypto.small.MessageDigestBench.digest         SHA1     1048576             N/A       N/A              avgt   20  12362160.119 ? 38788.109  ns/op
>> 
>> 
>> **getAndDigest when size == 64**
>> The data is not stable for test getAndDigest when size == 64, which I think is introduced by  j.s.MessageDigest.getInstance itself, which we don't touch in this patch.
>> Check more details at [1](ht...
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   assert register; move round param

Overall, pretty good! Only a few minor suggestions for your consideration!

src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 4856:

> 4854:     if (round == 16) {
> 4855:       int64_t block_bytes = round * 4;
> 4856:       __ addi(buf, buf, block_bytes);

Does `buf` need to be incremented here? And why at `round == 16` and not after all the rounds are done? Maybe you can do this in the loop in `generate_sha1_implCompress` to have the code that initializes and increments it in the same function? Also, does it need to be incremented if `!multi_block`?

src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 4884:

> 4882:     int idx = 17;
> 4883:     // W't = ROTL'1(W't-3 ^ W't-8 ^ W't-14 ^ W't-16),  16 <= t <= 79
> 4884:     __ srli(t0, ws[(idx-3)/2], 32);

I would use `t1` here for the `srli` result (similar to lines 4862-4863).

src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 4950:

> 4948:     // so, we can reuse it as a temp register here.
> 4949:     Register tmp2 = cur_w;
> 4950:     {

Why is this in a nested block?

src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 5024:

> 5022:   //   c_rarg3: int     limit
> 5023:   //
> 5024:   // Outpus:

Outputs

-------------

PR Review: https://git.openjdk.org/jdk/pull/17130#pullrequestreview-1896303312
PR Review Comment: https://git.openjdk.org/jdk/pull/17130#discussion_r1501227559
PR Review Comment: https://git.openjdk.org/jdk/pull/17130#discussion_r1500699344
PR Review Comment: https://git.openjdk.org/jdk/pull/17130#discussion_r1501235344
PR Review Comment: https://git.openjdk.org/jdk/pull/17130#discussion_r1501218177

From tonyp at openjdk.org  Fri Feb 23 22:35:05 2024
From: tonyp at openjdk.org (Antonios Printezis)
Date: Fri, 23 Feb 2024 22:35:05 GMT
Subject: RFR: 8322179: RISC-V: Implement SHA-1 intrinsic [v11]
In-Reply-To: <aSyCTamtdqjTThv2t6sOnXe8XDTwj2G-BIHGNQmZ3M4=.41f939b4-2a38-4e1d-94ea-0b283f1c8560@github.com>
References: <PyIXzENfiHysFS3IyZn3FDNQpV7Ua2L6OmjiXq9wRoU=.cf74a45e-c94b-4f7b-8768-d10d55e2ce1d@github.com>
 <aSyCTamtdqjTThv2t6sOnXe8XDTwj2G-BIHGNQmZ3M4=.41f939b4-2a38-4e1d-94ea-0b283f1c8560@github.com>
Message-ID: <Ut6bsvlB6wrDZCuzzI119v4U8IsIbnJUDB7nFjR3vrk=.b6ff755d-eed0-4e53-8fc0-bbff26c78543@github.com>

On Wed, 21 Feb 2024 16:10:22 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you review this patch to implement SHA-1 intrinsic for riscv?
>> Thanks!
>> 
>> 
>> ## Test
>> 
>> ### Functionality
>> 
>> tests under `test/hotspot/jtreg/compiler/intrinsics/sha`
>> tests found via `find test/jdk -iname "*SHA1*.java"`
>> 
>> ### Performance
>> 
>> tested on `T-HEAD Light Lichee Pi 4A`
>> 
>> JMH_PARAMS="-f 1 -wi 10 -i 20" // for every loop of jmh test
>> 
>> benchmark tests `MessageDigests.java GetMessageDigest.java MessageDigestBench.java MacBench.java` which are under `test/micro/org/openjdk/bench/`, more spcifically `TESTS="MessageDigests.digest MessageDigests.getAndDigest MessageDigestBench.digest"`
>> 
>> 
>> // After
>> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1        64     DEFAULT  avgt   20      1845.446 ?     27.052  ns/op
>> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    181455.350 ?    532.258  ns/op
>> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2447.674 ?     10.239  ns/op
>> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    182896.083 ?   1242.774  ns/op
>> o.o.b.javax.crypto.small.MessageDigestBench.digest         SHA1     1048576             N/A       N/A              avgt   20  11599227.792 ? 121442.390  ns/op
>> // Before
>> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2352.475 ?    11.198  ns/op
>> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    188495.684 ?  1467.942  ns/op
>> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2437.347 ?     6.398  ns/op
>> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    196086.570 ?  1140.998  ns/op
>> o.o.b.javax.crypto.small.MessageDigestBench.digest         SHA1     1048576             N/A       N/A              avgt   20  12362160.119 ? 38788.109  ns/op
>> 
>> 
>> **getAndDigest when size == 64**
>> The data is not stable for test getAndDigest when size == 64, which I think is introduced by  j.s.MessageDigest.getInstance itself, which we don't touch in this patch.
>> Check more details at [1](ht...
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   refine code

src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 4843:

> 4841: 
> 4842:       if ((round % 2) == 0) {
> 4843:         __ ld(ws[round/2], Address(buf, round * 4));

(minor nit) It took me a couple of mins to understand why `round * 4` works here (`ld` loads 8 bytes and I was expecting the multiplier to be 8). Would `(round/2) * 8` be a bit clearer?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17130#discussion_r1499526942

From vladimir.x.ivanov at oracle.com  Sat Feb 24 02:00:53 2024
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 23 Feb 2024 18:00:53 -0800
Subject: Resolving super interface in different contexts depending on the
 child class
In-Reply-To: <CAGzTNj5WxZbx0AeAkTeDpXNm83kn0_DX4d9bZ4CPDgvuJ17pZA@mail.gmail.com>
References: <CAGzTNj5WxZbx0AeAkTeDpXNm83kn0_DX4d9bZ4CPDgvuJ17pZA@mail.gmail.com>
Message-ID: <6eb83154-ba8f-4d7e-8ef1-cedbdaa14cf6@oracle.com>

Hi Aleksandr,

I'd like to clarify the terminology: JVMS distinguishes initiating and 
defining loaders for a class (JVMS-5.3 [1]).

The effects you are looking at are specific to initiating loaders.

Even though a class is loaded only once (when well-behaved loaders are 
involved), it becomes visible in all descendant loaders on case-by-case 
basis. Each loader should initiate the loading to resolve the class in 
its context. (On implementation level it triggers the update of class 
loader dictionary.)

Classes are loaded on-demand and precise conditions when it happens in 
practice may be far from evident. As an example, I played with the 
sketch you provided and here are my observations (when 
ScheduledFutureTask implements ScheduledFuture):


  * for the following code shape, bytecode verifier triggers class 
loading of Delayed class as part of invokevirtual verification (it needs 
to prove ScheduledFutureTask <: Delayed):

       public static int compare(ScheduledFutureTask o1,
  ScheduledFutureTask o2) {
           return o1.compareTo(o2);
       }


  * if compare is adjusted as follows, then checkcast instruction 
triggers class loading for non-null object during execution:

     public static int compare(ScheduledFutureTask o1, Object o2) {
         return o1.compareTo((Delayed)o2);
     }

You mentioned that Delayed interface is not loaded by application loader 
in the first case, but I wasn't able to reproduce it based on your 
description. Please, share more details.


Personally, I was able to avoid class loading (and trigger 
has_unloaded_classes_in_signature() == false for compareTo(Delayed)) 
either by turning off verification (-Xverify:none) or always passing 
null as o2 [2]:

     public static void main(String[] args) {
         ScheduledFutureTask instances0 = new ScheduledFutureTask();
         for (int i = 0; i < 20_000; i++) {
             compare(instances0, null);
         }
     }

The issue with null argument is known (inlining failures due to unloaded 
class in method signature when corresponding values are always null). 
JDK-8294609 [3] improved the situation for most of scenarios, but 
covering nulls require more work. It may be improved in the future release.

Best regards,
Vladimir Ivanov

[1] https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-5.html#jvms-5.3

[2] https://gist.github.com/iwanowww/c33e49092bfa0e6a052f28ae139b55eb

[3] https://bugs.openjdk.org/browse/JDK-8294609

On 2/23/24 08:32, Aleksandr Popov wrote:
> Hi! In the following test case I've investigated how Hotspot loads 
> classes into the loaders.
> And found out that the inheritance chain could affect the result.
> 
> //--------------------------------------------------------------------------
> public class SimpleTest {
>  ? ? public static int compare(ScheduledFutureTask o1, 
> ScheduledFutureTask o2) {
>  ? ? ? ? return o1.compareTo(o2);
>  ? ? }
> 
>  ? ? public static void main(String[] args) {
>  ? ? ? ? ScheduledFutureTask instances0 = new ScheduledFutureTask();
>  ? ? ? ? ScheduledFutureTask instances1 = new ScheduledFutureTask();
>  ? ? ? ? compare(instances0, instances1);
>  ? ? }
> }
> 
> final class ScheduledFutureTask implements ScheduledFuture<Void> {
> ...
>  ? ? @Override
>  ? ? public int compareTo(Delayed o) {
>  ? ? ? ? if (this == o) {
>  ? ? ? ? ? ? return 0;
>  ? ? ? ? }
>  ? ? }
> }
> //--------------------------------------------------------------------------
> 
>   * If /ScheduledFutureTask/?class implements
>     /java.util.concurrent.ScheduledFuture /interface,
> 
> which implements /java.util.concurrent.Delayed/?interface: *[application 
> class -> core class -> core class],*
> then the /Delayed /interface would be loaded into the boot class loader, 
> since it's resolved in the context of the core class.
> 
> I've added some logs to track class resolving:
> # parse interfaces of class ScheduledFutureTask, [APP] loader
> # parse interfaces of class java/util/concurrent/ScheduledFuture, [BOOT] 
> loader
> # parse interfaces of class java/util/concurrent/Delayed, [BOOT] loader
> # Adding java/util/concurrent/Delayed to dictionary [BOOT]
> 
>   * If we replace core class in the chain with an application one:
>     *[application class -> application class -> core class], *
> 
> then the /Delayed /interface would be loaded into both class loaders, 
> since it would be resolved in the context of the application class:
> 
> # parse interfaces of class ScheduledFutureTask, [application class loader]
> # parse interfaces of class Interface1, [application class loader]
> # parse interfaces of class java/util/concurrent/Delayed, [boot class 
> loader]
> # Adding java/util/concurrent/Delayed to dictionary [boot class loader]
> # Adding java/util/concurrent/Delayed to dictionary [application class 
> loader]
> 
>   * Theoretically, this difference could affect the result of the
>     has_unloaded_classes_in_signature() call
> 
> for the ScheduledFutureTask::compareTo method.
> 
> final class ScheduledFutureTask implements ScheduledFuture<Void> {
> ...
>  ? ? @Override
>  ? ? public int compareTo(Delayed o) {
>  ? ? ? ? if (this == o) {
>  ? ? ? ? ? ? return 0;
>  ? ? ? ? }
>  ? ? }
> }
> 
> Because in the first case (application class -> core class -> core 
> class) we have unloaded /java/util/concurrent/Delayed/
> interface in the context of the accessing class, which was loaded into 
> the application class loader.
> 
> So my question is: why is it correct to have class loaded into different 
> class loaders depending on the inheritance chain?
> Or maybe it's intentionally resolved somewhere in the code?
> 
> Note that SystemDictionary::check_signature_loaders doesn't add loader 
> constraints to the interface, since the caller and callee loaders are 
> the same in this case: both application loaders.
> 
> Thank you!

From fyang at openjdk.org  Sat Feb 24 02:54:56 2024
From: fyang at openjdk.org (Fei Yang)
Date: Sat, 24 Feb 2024 02:54:56 GMT
Subject: RFR: 8322962: Upcall stub might go undetected when freezing frames
In-Reply-To: <9wGivvL8XaePg4yOjShuasS2RZzyT2bzUi8EKWs95yQ=.36456962-47a7-4920-9a3a-a15936d4f480@github.com>
References: <9wGivvL8XaePg4yOjShuasS2RZzyT2bzUi8EKWs95yQ=.36456962-47a7-4920-9a3a-a15936d4f480@github.com>
Message-ID: <KWSHdMtnr2pG1pNcV0ttQCZf2N3hVMoD2tDz6a9vlcQ=.bdd9f8ac-1841-4ea7-9017-b54a3c3cb496@github.com>

On Thu, 22 Feb 2024 14:28:18 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review this simple fix. There is a missing push_cont_fastpath()/pop_cont_fastpath() around the call to Java in the upcall stub. Because of this, if from that upcall a virtual thread tries to yield, and all the other methods in the stack are compiled, we will incorrectly take the freeze fast path and freeze everything in the stack including the native frames. By forcing the slow path instead we will identify the upcall stub and pin the vthread.
> 
> The issue can be easily reproduced by running the modified version of test GetStackTraceALotWhenPinned.java included in this patch. I also tested the fix by running tiers1-3 in mach5. 
> 
> Thanks,
> Patricio

LGTM. Test passed with or without -Xcomp flag on linux-riscv64 platform.

-------------

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17964#pullrequestreview-1899185144

From dlong at openjdk.org  Sat Feb 24 06:04:54 2024
From: dlong at openjdk.org (Dean Long)
Date: Sat, 24 Feb 2024 06:04:54 GMT
Subject: RFR: 8322962: Upcall stub might go undetected when freezing frames
In-Reply-To: <9wGivvL8XaePg4yOjShuasS2RZzyT2bzUi8EKWs95yQ=.36456962-47a7-4920-9a3a-a15936d4f480@github.com>
References: <9wGivvL8XaePg4yOjShuasS2RZzyT2bzUi8EKWs95yQ=.36456962-47a7-4920-9a3a-a15936d4f480@github.com>
Message-ID: <gIBJicb_Il9HfyglJMmJeNJBf6rbHK4YTWRKPZMQV5Q=.7cfab26c-922d-4c3c-ab0c-2ba58b6aa3be@github.com>

On Thu, 22 Feb 2024 14:28:18 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review this simple fix. There is a missing push_cont_fastpath()/pop_cont_fastpath() around the call to Java in the upcall stub. Because of this, if from that upcall a virtual thread tries to yield, and all the other methods in the stack are compiled, we will incorrectly take the freeze fast path and freeze everything in the stack including the native frames. By forcing the slow path instead we will identify the upcall stub and pin the vthread.
> 
> The issue can be easily reproduced by running the modified version of test GetStackTraceALotWhenPinned.java included in this patch. I also tested the fix by running tiers1-3 in mach5. 
> 
> Thanks,
> Patricio

Is there a way to automatically detect missing calls to push_cont_fastpath?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17964#issuecomment-1962269163

From dchuyko at openjdk.org  Sat Feb 24 11:22:17 2024
From: dchuyko at openjdk.org (Dmitry Chuyko)
Date: Sat, 24 Feb 2024 11:22:17 GMT
Subject: RFR: 8309271: A way to align already compiled methods with
 compiler directives [v26]
In-Reply-To: <csWpTiZu4dQgyARmNGro8PYl8yLj6-dRjVdsh51jV0k=.c0e25efd-3ee0-4196-a05a-c54268f23660@github.com>
References: <csWpTiZu4dQgyARmNGro8PYl8yLj6-dRjVdsh51jV0k=.c0e25efd-3ee0-4196-a05a-c54268f23660@github.com>
Message-ID: <CGpD9K9DLOAG7WkUfJ9MSIqyrJZeZucG69QekIe4KQM=.81719099-c20b-4961-bc17-11bc2e139b5c@github.com>

> Compiler Control (https://openjdk.org/jeps/165) provides method-context dependent control of the JVM compilers (C1 and C2). The active directive stack is built from the directive files passed with the `-XX:CompilerDirectivesFile` diagnostic command-line option and the Compiler.add_directives diagnostic command. It is also possible to clear all directives or remove the top from the stack.
> 
> A matching directive will be applied at method compilation time when such compilation is started. If directives are added or changed, but compilation does not start, then the state of compiled methods doesn't correspond to the rules. This is not an error, and it happens in long running applications when directives are added or removed after compilation of methods that could be matched. For example, the user decides that C2 compilation needs to be disabled for some method due to a compiler bug, issues such a directive but this does not affect the application behavior. In such case, the target application needs to be restarted, and such an operation can have high costs and risks. Another goal is testing/debugging compilers.
> 
> It would be convenient to optionally reconcile at least existing matching nmethods to the current stack of compiler directives (so bypass inlined methods).
> 
> Natural way to eliminate the discrepancy between the result of compilation and the broken rule is to discard the compilation result, i.e. deoptimization. Prior to that we can try to re-compile the method letting compile broker to perform it taking new directives stack into account. Re-compilation helps to prevent hot methods from execution in the interpreter.
> 
> A new flag `-r` has beed introduced for some directives related to compile commands: `Compiler.add_directives`, `Compiler.remove_directives`, `Compiler.clear_directives`. The default behavior has not changed (no flag). If the new flag is present, the command scans already compiled methods and puts methods that have any active non-default matching compiler directives to re-compilation if possible, otherwise marks them for deoptimization. There is currently no distinction which directives are found. In particular, this means that if there are rules for inlining into some method, it will be refreshed. On the other hand, if there are rules for a method and it was inlined, top-level methods won't be refreshed, but this can be achieved by having rules for them.
> 
> In addition, a new diagnostic command `Compiler.replace_directives`, has been added for ...

Dmitry Chuyko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits:

 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Deopt osr, cleanups
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - ... and 34 more: https://git.openjdk.org/jdk/compare/d10f277b...6d639ace

-------------

Changes: https://git.openjdk.org/jdk/pull/14111/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14111&range=25
  Stats: 381 lines in 15 files changed: 348 ins; 3 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/14111.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14111/head:pull/14111

PR: https://git.openjdk.org/jdk/pull/14111

From karianna at openjdk.org  Sat Feb 24 20:04:53 2024
From: karianna at openjdk.org (Martijn Verburg)
Date: Sat, 24 Feb 2024 20:04:53 GMT
Subject: RFR: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234 [v3]
In-Reply-To: <bmgatRS3iZ6J35-pwQQ81ev8-lMBeyFcN6jzQFk_qno=.369060d2-3e1f-45c9-bad6-71bbc921b647@github.com>
References: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
 <TYE1ieXypz7WiaTQRwU3Zp-ICrZ2E4SIo4meD-h14LU=.884eb3e0-04e2-4728-bfc5-57b072e809bf@github.com>
 <cx6Me6MA3QwpLr2y2avGx3-we6Ej3UHQHRD10Km76HU=.bdf6dc1e-c9f3-4695-9687-4ed9d044741d@github.com>
 <WAwoF5K4yWv40dWrX1VjUfeVGYy918KDHp4qvuRQ5xM=.2aa20484-2def-46dc-b20f-4e866748e048@github.com>
 <1enXmdMITwK96Lz35sCWmkob9sLgKKt1N2Lp0NSldNc=.81d72c1e-0f11-452d-a55a-674f775fee47@github.com>
 <bmgatRS3iZ6J35-pwQQ81ev8-lMBeyFcN6jzQFk_qno=.369060d2-3e1f-45c9-bad6-71bbc921b647@github.com>
Message-ID: <c-DwcGAX3JX-gnQ0CWuGzI09K5SCdQ_yxnBP-q9HT1o=.903a2615-8255-4bbf-aaa3-2e9fb0ae84f5@github.com>

On Fri, 23 Feb 2024 12:03:37 GMT, Bernhard Urban-Forster <burban at openjdk.org> wrote:

>> Instead of discussing removal of windows/aarch64 (although the general rule in OpenJDK is that ports that are not maintained by anyone should be removed); let's stick to the question here: do we need to export `das1()` for debugging?
>
> Personally I have never used `das`/`das1` on any AArch64 port when debugging.  I guess it was somewhat handy when the backend was originally developed.  I would argue that the built-in disassembler of any debugger and `disnm` from `debug.cpp` are good enough, and thus `das`/`das1` can be removed.  What do you think @theRealAph ?

Hi all - yes the Windows Arm port is maintained by Microsoft's JDK team. How can we help in this particular case?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17967#discussion_r1501690000

From karianna at openjdk.org  Sat Feb 24 20:04:53 2024
From: karianna at openjdk.org (Martijn Verburg)
Date: Sat, 24 Feb 2024 20:04:53 GMT
Subject: RFR: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234 [v3]
In-Reply-To: <c-DwcGAX3JX-gnQ0CWuGzI09K5SCdQ_yxnBP-q9HT1o=.903a2615-8255-4bbf-aaa3-2e9fb0ae84f5@github.com>
References: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
 <TYE1ieXypz7WiaTQRwU3Zp-ICrZ2E4SIo4meD-h14LU=.884eb3e0-04e2-4728-bfc5-57b072e809bf@github.com>
 <cx6Me6MA3QwpLr2y2avGx3-we6Ej3UHQHRD10Km76HU=.bdf6dc1e-c9f3-4695-9687-4ed9d044741d@github.com>
 <WAwoF5K4yWv40dWrX1VjUfeVGYy918KDHp4qvuRQ5xM=.2aa20484-2def-46dc-b20f-4e866748e048@github.com>
 <1enXmdMITwK96Lz35sCWmkob9sLgKKt1N2Lp0NSldNc=.81d72c1e-0f11-452d-a55a-674f775fee47@github.com>
 <bmgatRS3iZ6J35-pwQQ81ev8-lMBeyFcN6jzQFk_qno=.369060d2-3e1f-45c9-bad6-71bbc921b647@github.com>
 <c-DwcGAX3JX-gnQ0CWuGzI09K5SCdQ_yxnBP-q9HT1o=.903a2615-8255-4bbf-aaa3-2e9fb0ae84f5@github.com>
Message-ID: <o3KeCSV9VoJrmFKEsfKPCJ0cnuYbZZcjY18qYWSXZns=.fc08ab1b-d6f3-4158-8291-63e2663c2992@github.com>

On Sat, 24 Feb 2024 20:00:34 GMT, Martijn Verburg <karianna at openjdk.org> wrote:

>> Personally I have never used `das`/`das1` on any AArch64 port when debugging.  I guess it was somewhat handy when the backend was originally developed.  I would argue that the built-in disassembler of any debugger and `disnm` from `debug.cpp` are good enough, and thus `das`/`das1` can be removed.  What do you think @theRealAph ?
>
> Hi all - yes the Windows Arm port is maintained by Microsoft's JDK team. How can we help in this particular case?

I assume you want to know if we use DAS/DAS1 for debugging purposes on that platform?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17967#discussion_r1501690156

From stuefe at openjdk.org  Sun Feb 25 07:04:04 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sun, 25 Feb 2024 07:04:04 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v25]
In-Reply-To: <xemN0ZxPQvRMrO-v4824K36DyT1c42nuOYzLtyUtGnI=.bb7c2f33-cb3c-466b-9d00-76ad3e3fa677@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <xemN0ZxPQvRMrO-v4824K36DyT1c42nuOYzLtyUtGnI=.bb7c2f33-cb3c-466b-9d00-76ad3e3fa677@github.com>
Message-ID: <g8N9lwxRyXWYCt8OnndT8JwAqgJMFeSiqTa6_HS2e6Q=.eaef7669-c34c-4457-b22d-fdc96e43ba2a@github.com>

On Tue, 20 Feb 2024 09:27:15 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am.
>> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX.
>> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails.
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>    remove space

Changes requested by stuefe (Reviewer).

src/hotspot/os/aix/os_aix.cpp line 1167:

> 1165:  Load "libfilename.so" first, then load libfilename.a, on failure.
> 1166:  In OpenJ9, the libary with .so extension is loaded first and then .a extension, on failure.
> 1167: */

Wrong block comment, but the comment itself is also off now. Suggestion:

Suggestion:

// Load library named <filename>
// If filename matches <name>.so, and loading fails, repeat with <name>.a.

src/hotspot/os/aix/os_aix.cpp line 1173:

> 1171:   char* const pointer_to_dot = strrchr(file_path, '.');
> 1172:   char const *old_extension = ".so";
> 1173:   char const *new_extension = ".a";

Suggestion:

  char* const file_path = strdup(filename);
  char* const pointer_to_dot = strrchr(file_path, '.');
  const char old_extension[] = ".so";
  const char new_extension[] = ".a";
  STATIC_ASSERT(sizeof(old_exception) >= sizeof(new_exception));

and remove runtime-assert below

src/hotspot/os/aix/os_aix.cpp line 1178:

> 1176:     FREE_C_HEAP_ARRAY(char, file_path);
> 1177:     return result;
> 1178:   }

I would remove this whole section since it's a functional change not covered by the issue description and unnecessary for your fix. 

It may also be wrong: loading shared objects without extension may be perfectly valid. The extension is just a convention.

src/hotspot/os/aix/os_aix.cpp line 1183:

> 1181:   // If the load fails,we try to reload by changing the extension to .a for .so files only.
> 1182:   // Shared object in .so format dont have braces, hence they get removed for archives with members.
> 1183:   if (result == nullptr) {

Suggestion:

  if (result == nullptr && pointer_to_dot != nullptr && strcmp(pointer_to_dot, old_extension) == 0) {

src/hotspot/os/aix/os_aix.cpp line 1184:

> 1182:   // Shared object in .so format dont have braces, hence they get removed for archives with members.
> 1183:   if (result == nullptr) {
> 1184:     assert(strlen(new_extension) < strlen(old_extension), "New extension length must be less than existing one");

Can be removed if you do the STATIC_ASSERT suggested above.

src/hotspot/os/aix/os_aix.cpp line 1186:

> 1184:     assert(strlen(new_extension) < strlen(old_extension), "New extension length must be less than existing one");
> 1185:     if (strcmp(pointer_to_dot, old_extension) == 0) {
> 1186:       sprintf(pointer_to_dot, "%s", new_extension);

Use os::snprintf, and limit output buffer by size of old extension.

-------------

PR Review: https://git.openjdk.org/jdk/pull/16604#pullrequestreview-1899612274
PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1501757595
PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1501754431
PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1501754774
PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1501757736
PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1501757772
PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1501757844

From alanb at openjdk.org  Sun Feb 25 10:55:58 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 25 Feb 2024 10:55:58 GMT
Subject: RFR: 8324680: Replace NULL with nullptr in JVMTI generated code
In-Reply-To: <w1DMQMwGugoSs830xWYD6l7yoIR6v8dk5MnKYIY8t9w=.1ad08a17-8efc-4a71-88a5-78da29ce4ab4@github.com>
References: <w1DMQMwGugoSs830xWYD6l7yoIR6v8dk5MnKYIY8t9w=.1ad08a17-8efc-4a71-88a5-78da29ce4ab4@github.com>
Message-ID: <1LsvI6_C_bA6elUltTVR3xMY2Ro3vlUyp-ICt2Gzktw=.f20dc72a-7e46-4a3c-a7b1-20562cf0b215@github.com>

On Thu, 15 Feb 2024 08:46:43 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This enhancement replaces uses of NULL with nullptr in the XML-description files for JVMTI. These are the files `hotsport/share/prims/jvmti.xml` and `hotspot/share/prims/jvmti*.xls`.
> 
> The following files are auto-generated from the `jvmti.xml` and `*.xsl files` in the `build/<CFG>/variant-server/gensrc/jvmtifiles': `jvmti.h`, `jvmti.html`, `jvmtiEnter.cpp`, `jvmtiEnterTrace.cpp`, `jvmtiEnv.hpp`
> 
> This addresses a category of NULL uses that wasn't dealt with by:
>  [JDK-8299837](https://bugs.openjdk.org/browse/JDK-8299837).
>  
>  Testing:
>    - TBD: run mach5 tiers1-3

JVMTI agents can be developed in C or C++. If I read this changes correctly, then this will replace all the NULLs in the generated spec with nullptr. I wonder if this needs some setup in the Introduction section, e.g. the Function Return Values subsection, to make this clear.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17866#issuecomment-1962892766

From gcao at openjdk.org  Mon Feb 26 02:44:01 2024
From: gcao at openjdk.org (Gui Cao)
Date: Mon, 26 Feb 2024 02:44:01 GMT
Subject: RFR: 8319900: Recursive lightweight locking: riscv64 implementation
Message-ID: <OJTtw2p54KDzlRMC2qeNNHpodtRBRdA_4wvPxYfSX4Q=.76bf740b-d1ed-4586-8175-e759c13ca12b@github.com>

Implementation of recursive lightweight JDK-8319796 for linux-riscv64.

### Correctness testing:

- [x]  Run tier1-3, hotspot:tier4 tests with -XX:LockingMode=1 & -XX:LockingMode=2 on LicheePI 4A (release)
- [x]  Run tier1-3 tests with -XX:LockingMode=1 & -XX:LockingMode=2 on qemu 8.1.0 (fastdebug)

### JMH tested on LicheePI 4A:


Before (LockingMode = 2):

Benchmark                                (innerCount)  Mode  Cnt       Score      Error  Units
LockUnlock.testContendedLock                      100  avgt   12     281.603 ?    2.626  ns/op
LockUnlock.testRecursiveLockUnlock                100  avgt   12  196373.917 ? 4669.241  ns/op
LockUnlock.testRecursiveSynchronization           100  avgt   12     274.492 ?    6.049  ns/op
LockUnlock.testSerialLockUnlock                   100  avgt   12   11516.092 ?   69.964  ns/op
LockUnlock.testSimpleLockUnlock                   100  avgt   12   11490.789 ?   58.833  ns/op

After (LockingMode = 2):

Benchmark                                (innerCount)  Mode  Cnt      Score    Error  Units
LockUnlock.testContendedLock                      100  avgt   12    307.013 ?  3.259  ns/op
LockUnlock.testRecursiveLockUnlock                100  avgt   12  59047.222 ? 94.748  ns/op
LockUnlock.testRecursiveSynchronization           100  avgt   12    259.789 ?  1.698  ns/op
LockUnlock.testSerialLockUnlock                   100  avgt   12   6055.775 ? 13.518  ns/op
LockUnlock.testSimpleLockUnlock                   100  avgt   12   6090.986 ? 67.179  ns/op



Before (LockingMode = 1):

Benchmark                                (innerCount)  Mode  Cnt      Score     Error  Units
LockUnlock.testContendedLock                      100  avgt   12    286.144 ?   2.490  ns/op
LockUnlock.testRecursiveLockUnlock                100  avgt   12  68058.259 ? 286.262  ns/op
LockUnlock.testRecursiveSynchronization           100  avgt   12    263.132 ?   4.075  ns/op
LockUnlock.testSerialLockUnlock                   100  avgt   12   7521.777 ?  35.193  ns/op
LockUnlock.testSimpleLockUnlock                   100  avgt   12   7522.480 ?  26.310  ns/op

After (LockingMode = 1):

Benchmark                                (innerCount)  Mode  Cnt      Score     Error  Units
LockUnlock.testContendedLock                      100  avgt   12    289.034 ?   5.821  ns/op
LockUnlock.testRecursiveLockUnlock                100  avgt   12  68474.370 ? 495.135  ns/op
LockUnlock.testRecursiveSynchronization           100  avgt   12    261.052 ?   4.560  ns/op
LockUnlock.testSerialLockUnlock                   100  avgt   12   7513.187 ?  19.524  ns/op
LockUnlock.testSimpleLockUnlock                   100  avgt   12   7461.287 ? 118.634  ns/op

-------------

Commit messages:
 - Merge branch 'master' into JDK-8319900
 - improve code
 - Polish code comment
 - 8319900: Recursive lightweight locking: riscv64 implementation

Changes: https://git.openjdk.org/jdk/pull/17554/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17554&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8319900
  Stats: 613 lines in 9 files changed: 411 ins; 114 del; 88 mod
  Patch: https://git.openjdk.org/jdk/pull/17554.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17554/head:pull/17554

PR: https://git.openjdk.org/jdk/pull/17554

From fyang at openjdk.org  Mon Feb 26 05:13:53 2024
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 26 Feb 2024 05:13:53 GMT
Subject: RFR: 8319900: Recursive lightweight locking: riscv64
 implementation
In-Reply-To: <OJTtw2p54KDzlRMC2qeNNHpodtRBRdA_4wvPxYfSX4Q=.76bf740b-d1ed-4586-8175-e759c13ca12b@github.com>
References: <OJTtw2p54KDzlRMC2qeNNHpodtRBRdA_4wvPxYfSX4Q=.76bf740b-d1ed-4586-8175-e759c13ca12b@github.com>
Message-ID: <0FqyJDzVzUmzIMVTWE5_QLPVt-QknkZlKGxKwiOcH5E=.d915ec2a-75ba-4832-b9e2-a812f87ca73c@github.com>

On Wed, 24 Jan 2024 14:09:21 GMT, Gui Cao <gcao at openjdk.org> wrote:

> Implementation of recursive lightweight JDK-8319796 for linux-riscv64.
> 
> ### Correctness testing:
> 
> - [x]  Run tier1-3, hotspot:tier4 tests with -XX:LockingMode=1 & -XX:LockingMode=2 on LicheePI 4A (release)
> - [x]  Run tier1-3 tests with -XX:LockingMode=1 & -XX:LockingMode=2 on qemu 8.1.0 (fastdebug)
> 
> ### JMH tested on LicheePI 4A:
> 
> 
> Before (LockingMode = 2):
> 
> Benchmark                                (innerCount)  Mode  Cnt       Score      Error  Units
> LockUnlock.testContendedLock                      100  avgt   12     281.603 ?    2.626  ns/op
> LockUnlock.testRecursiveLockUnlock                100  avgt   12  196373.917 ? 4669.241  ns/op
> LockUnlock.testRecursiveSynchronization           100  avgt   12     274.492 ?    6.049  ns/op
> LockUnlock.testSerialLockUnlock                   100  avgt   12   11516.092 ?   69.964  ns/op
> LockUnlock.testSimpleLockUnlock                   100  avgt   12   11490.789 ?   58.833  ns/op
> 
> After (LockingMode = 2):
> 
> Benchmark                                (innerCount)  Mode  Cnt      Score    Error  Units
> LockUnlock.testContendedLock                      100  avgt   12    307.013 ?  3.259  ns/op
> LockUnlock.testRecursiveLockUnlock                100  avgt   12  59047.222 ? 94.748  ns/op
> LockUnlock.testRecursiveSynchronization           100  avgt   12    259.789 ?  1.698  ns/op
> LockUnlock.testSerialLockUnlock                   100  avgt   12   6055.775 ? 13.518  ns/op
> LockUnlock.testSimpleLockUnlock                   100  avgt   12   6090.986 ? 67.179  ns/op
> 
> 
> 
> Before (LockingMode = 1):
> 
> Benchmark                                (innerCount)  Mode  Cnt      Score     Error  Units
> LockUnlock.testContendedLock                      100  avgt   12    286.144 ?   2.490  ns/op
> LockUnlock.testRecursiveLockUnlock                100  avgt   12  68058.259 ? 286.262  ns/op
> LockUnlock.testRecursiveSynchronization           100  avgt   12    263.132 ?   4.075  ns/op
> LockUnlock.testSerialLockUnlock                   100  avgt   12   7521.777 ?  35.193  ns/op
> LockUnlock.testSimpleLockUnlock                   100  avgt   12   7522.480 ?  26.310  ns/op
> 
> After (LockingMode = 1):
> 
> Benchmark                                (innerCount)  Mode  Cnt      Score     Error  Units
> LockUnlock.testContendedLock                      100  avgt   12    289.034 ?   5.821  ns/op
> LockUnlock.testRecursiveLockUnlock                100  avgt   12  68474.370 ? 495.135  ns/op
> LockUnlock.testRecursiveSynchronization           100  avgt   12    261.052 ?   4.560  ns/op
> Loc...

This looks pretty good. Thanks.

-------------

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17554#pullrequestreview-1899965559

From dholmes at openjdk.org  Mon Feb 26 05:21:58 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 26 Feb 2024 05:21:58 GMT
Subject: RFR: 8324680: Replace NULL with nullptr in JVMTI generated code
In-Reply-To: <1LsvI6_C_bA6elUltTVR3xMY2Ro3vlUyp-ICt2Gzktw=.f20dc72a-7e46-4a3c-a7b1-20562cf0b215@github.com>
References: <w1DMQMwGugoSs830xWYD6l7yoIR6v8dk5MnKYIY8t9w=.1ad08a17-8efc-4a71-88a5-78da29ce4ab4@github.com>
 <1LsvI6_C_bA6elUltTVR3xMY2Ro3vlUyp-ICt2Gzktw=.f20dc72a-7e46-4a3c-a7b1-20562cf0b215@github.com>
Message-ID: <01ZDNOpK76C_6ZjuMDOND0dxH-CxRD0bCXXcYi5I8EQ=.8eea7dff-0f88-488c-865d-db56dd963766@github.com>

On Sun, 25 Feb 2024 10:53:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This enhancement replaces uses of NULL with nullptr in the XML-description files for JVMTI. These are the files `hotsport/share/prims/jvmti.xml` and `hotspot/share/prims/jvmti*.xls`.
>> 
>> The following files are auto-generated from the `jvmti.xml` and `*.xsl files` in the `build/<CFG>/variant-server/gensrc/jvmtifiles': `jvmti.h`, `jvmti.html`, `jvmtiEnter.cpp`, `jvmtiEnterTrace.cpp`, `jvmtiEnv.hpp`
>> 
>> This addresses a category of NULL uses that wasn't dealt with by:
>>  [JDK-8299837](https://bugs.openjdk.org/browse/JDK-8299837).
>>  
>>  Testing:
>>    - TBD: run mach5 tiers1-3
>
> JVMTI agents can be developed in C or C++. If I read this changes correctly, then this will replace all the NULLs in the generated spec with nullptr. I wonder if this needs some setup in the Introduction section, e.g. the Function Return Values subsection, to make this clear.

As with the other NULL -> nullptr changes, when it involves text (as opposed to code) and we are discussing the general concept of nullness, then the word "null" should be used rather than the programmatic values `NULL` or `nullptr`. But if the source here is used to generated both the spec's functional descriptions and the code functions themselves, then we cannot make that distinction. I'm not sure this change was actually a good idea. At a minimum we need something like @AlanBateman  suggests, something upfront to say that where the spec says `nullptr` it also means a C null pointer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17866#issuecomment-1963338009

From fyang at openjdk.org  Mon Feb 26 07:33:01 2024
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 26 Feb 2024 07:33:01 GMT
Subject: RFR: 8320646: RISC-V: C2 VectorCastHF2F [v2]
In-Reply-To: <fTvkUqcIsICvOIRWhqcICR8OYfaiOsOgSoaJsgUUm94=.09bb33c2-ce00-4943-bed0-0a1906395ee4@github.com>
References: <kqLQR-bD3v7iF7LgH0PzwIH_m6QH_2b371pKz9_Ovq8=.9c07c165-2a97-4a6b-9e82-6a6de0b81328@github.com>
 <fTvkUqcIsICvOIRWhqcICR8OYfaiOsOgSoaJsgUUm94=.09bb33c2-ce00-4943-bed0-0a1906395ee4@github.com>
Message-ID: <t_c0Y5w-aeOl4B_cfq93sXwDnm0lGPv04RFE6VvKrho=.75b9538f-a548-4600-97c6-ea94b43ea64a@github.com>

On Wed, 7 Feb 2024 15:22:09 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you review this patch to add instrinsics for VectorCastHF2F/VectorCastF2HF?
>> Thanks!
>> 
>> ## Test
>> 
>> test/jdk/java/lang/Float/Binary16ConversionNaN.java
>> test/jdk/java/lang/Float/Binary16Conversion.java
>> 
>> hotspot/jtreg/compiler/intrinsics/float16
>> hotspot/jtreg/compiler/vectorization/TestFloatConversionsVectorjava
>> hotspot/jtreg/compiler/vectorization/TestFloatConversionsVectorNaN.java
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add some comments

Seems that the spec is not in ratified status yet?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17698#issuecomment-1963474921

From azafari at openjdk.org  Mon Feb 26 07:46:02 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 26 Feb 2024 07:46:02 GMT
Subject: RFR: 8324849: Uniform use of synchronizations in NMT
Message-ID: <uikMP7BCa6Wro3F63W7C4qQZNMgDSjSYXzHEGCroSDA=.aef515a7-6352-41d5-8aa5-ac0c94e5886d@github.com>

In NMT, both `ThreadCritical` and `Tracker` objects are used to do synchronizations. `Tracker` class uses `ThreadCritical` internally and used only for uncommit and release memory operations.  In this change, `Tracker` class is replaced with explicit use of `ThreadCritical` to be the same as the other instances of sync'ing NMT operations.

tiers1-5 tests passed.

-------------

Commit messages:
 - 8324849: Uniform use of synchronizations in NMT

Changes: https://git.openjdk.org/jdk/pull/18000/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18000&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8324849
  Stats: 73 lines in 7 files changed: 16 ins; 40 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/18000.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18000/head:pull/18000

PR: https://git.openjdk.org/jdk/pull/18000

From jsjolen at openjdk.org  Mon Feb 26 07:55:53 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 26 Feb 2024 07:55:53 GMT
Subject: RFR: 8324849: Uniform use of synchronizations in NMT
In-Reply-To: <uikMP7BCa6Wro3F63W7C4qQZNMgDSjSYXzHEGCroSDA=.aef515a7-6352-41d5-8aa5-ac0c94e5886d@github.com>
References: <uikMP7BCa6Wro3F63W7C4qQZNMgDSjSYXzHEGCroSDA=.aef515a7-6352-41d5-8aa5-ac0c94e5886d@github.com>
Message-ID: <n_1OdA4LcLIvw-mkQ_U-2nItlBv9m0DGK62gb_p0xnQ=.137f48b6-f0cc-476e-b856-3c87b888d98a@github.com>

On Mon, 26 Feb 2024 07:41:45 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> In NMT, both `ThreadCritical` and `Tracker` objects are used to do synchronizations. `Tracker` class uses `ThreadCritical` internally and used only for uncommit and release memory operations.  In this change, `Tracker` class is replaced with explicit use of `ThreadCritical` to be the same as the other instances of sync'ing NMT operations.
> 
> tiers1-5 tests passed.

I never understood why we had this `Tracker` class  so I'm inclined to accept this PR, but I'd like to wait for other opinions before giving you an approval.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18000#issuecomment-1963507713

From aph at openjdk.org  Mon Feb 26 08:57:58 2024
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 26 Feb 2024 08:57:58 GMT
Subject: RFR: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234 [v3]
In-Reply-To: <o3KeCSV9VoJrmFKEsfKPCJ0cnuYbZZcjY18qYWSXZns=.fc08ab1b-d6f3-4158-8291-63e2663c2992@github.com>
References: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
 <TYE1ieXypz7WiaTQRwU3Zp-ICrZ2E4SIo4meD-h14LU=.884eb3e0-04e2-4728-bfc5-57b072e809bf@github.com>
 <cx6Me6MA3QwpLr2y2avGx3-we6Ej3UHQHRD10Km76HU=.bdf6dc1e-c9f3-4695-9687-4ed9d044741d@github.com>
 <WAwoF5K4yWv40dWrX1VjUfeVGYy918KDHp4qvuRQ5xM=.2aa20484-2def-46dc-b20f-4e866748e048@github.com>
 <1enXmdMITwK96Lz35sCWmkob9sLgKKt1N2Lp0NSldNc=.81d72c1e-0f11-452d-a55a-674f775fee47@github.com>
 <bmgatRS3iZ6J35-pwQQ81ev8-lMBeyFcN6jzQFk_qno=.369060d2-3e1f-45c9-bad6-71bbc921b647@github.com>
 <c-DwcGAX3JX-gnQ0CWuGzI09K5SCdQ_yxnBP-q9HT1o=.903a2615-8255-4bbf-aaa3-2e9fb0ae84f5@github.com>
 <o3KeCSV9VoJrmFKEsfKPCJ0cnuYbZZcjY18qYWSXZns=.fc08ab1b-d6f3-4158-8291-63e2663c2992@github.com>
Message-ID: <PjRWrB0x0vcYcQoa6EK62usvbNr_AFa_IN2ljCLrDDI=.4d69297c-6996-4cb7-9bd6-50f961c43686@github.com>

On Sat, 24 Feb 2024 20:01:50 GMT, Martijn Verburg <karianna at openjdk.org> wrote:

>> Hi all - yes the Windows Arm port is maintained by Microsoft's JDK team. How can we help in this particular case?
>
> I assume you want to know if we use DAS/DAS1 for debugging purposes on that platform?

I use `das` every day. In contrast, I don't know what `das1` is for.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17967#discussion_r1502240540

From mli at openjdk.org  Mon Feb 26 10:24:56 2024
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 26 Feb 2024 10:24:56 GMT
Subject: RFR: 8320646: RISC-V: C2 VectorCastHF2F [v2]
In-Reply-To: <t_c0Y5w-aeOl4B_cfq93sXwDnm0lGPv04RFE6VvKrho=.75b9538f-a548-4600-97c6-ea94b43ea64a@github.com>
References: <kqLQR-bD3v7iF7LgH0PzwIH_m6QH_2b371pKz9_Ovq8=.9c07c165-2a97-4a6b-9e82-6a6de0b81328@github.com>
 <fTvkUqcIsICvOIRWhqcICR8OYfaiOsOgSoaJsgUUm94=.09bb33c2-ce00-4943-bed0-0a1906395ee4@github.com>
 <t_c0Y5w-aeOl4B_cfq93sXwDnm0lGPv04RFE6VvKrho=.75b9538f-a548-4600-97c6-ea94b43ea64a@github.com>
Message-ID: <qkmJ7bs58gy-oQ3sff56sAvEPtV58gmFbIMAZSnXhuE=.89c047c1-c92d-4ab3-acc1-6abffeec96af@github.com>

On Mon, 26 Feb 2024 07:30:12 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Seems that the spec is not in ratified status yet?

Seems it is, please check https://wiki.riscv.org/display/HOME/Recently+Ratified+Extensions, or I misunderstand what you means?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17698#issuecomment-1963776556

From mli at openjdk.org  Mon Feb 26 10:32:10 2024
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 26 Feb 2024 10:32:10 GMT
Subject: RFR: 8322179: RISC-V: Implement SHA-1 intrinsic [v14]
In-Reply-To: <PyIXzENfiHysFS3IyZn3FDNQpV7Ua2L6OmjiXq9wRoU=.cf74a45e-c94b-4f7b-8768-d10d55e2ce1d@github.com>
References: <PyIXzENfiHysFS3IyZn3FDNQpV7Ua2L6OmjiXq9wRoU=.cf74a45e-c94b-4f7b-8768-d10d55e2ce1d@github.com>
Message-ID: <qOXJYauKdggsWmevBILNLDlWaL0rqQlXxlvbDRr9Sko=.cd488d1d-6ad8-4f19-8ad8-6ab4292638ce@github.com>

> Hi,
> Can you review this patch to implement SHA-1 intrinsic for riscv?
> Thanks!
> 
> 
> ## Test
> 
> ### Functionality
> 
> tests under `test/hotspot/jtreg/compiler/intrinsics/sha`
> tests found via `find test/jdk -iname "*SHA1*.java"`
> 
> ### Performance
> 
> tested on `T-HEAD Light Lichee Pi 4A`
> 
> JMH_PARAMS="-f 1 -wi 10 -i 20" // for every loop of jmh test
> 
> benchmark tests `MessageDigests.java GetMessageDigest.java MessageDigestBench.java MacBench.java` which are under `test/micro/org/openjdk/bench/`, more spcifically `TESTS="MessageDigests.digest MessageDigests.getAndDigest MessageDigestBench.digest"`
> 
> 
> // After
> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1        64     DEFAULT  avgt   20      1845.446 ?     27.052  ns/op
> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    181455.350 ?    532.258  ns/op
> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2447.674 ?     10.239  ns/op
> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    182896.083 ?   1242.774  ns/op
> o.o.b.javax.crypto.small.MessageDigestBench.digest         SHA1     1048576             N/A       N/A              avgt   20  11599227.792 ? 121442.390  ns/op
> // Before
> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2352.475 ?    11.198  ns/op
> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    188495.684 ?  1467.942  ns/op
> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2437.347 ?     6.398  ns/op
> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    196086.570 ?  1140.998  ns/op
> o.o.b.javax.crypto.small.MessageDigestBench.digest         SHA1     1048576             N/A       N/A              avgt   20  12362160.119 ? 38788.109  ns/op
> 
> 
> **getAndDigest when size == 64**
> The data is not stable for test getAndDigest when size == 64, which I think is introduced by  j.s.MessageDigest.getInstance itself, which we don't touch in this patch.
> Check more details at [1](https://github.com/openjdk/jdk/pull/17130#issuecomment-1886805614)
> 
> 
> loop ... ...

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  refine code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17130/files
  - new: https://git.openjdk.org/jdk/pull/17130/files/3bba2b8d..7278076f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17130&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17130&range=12-13

  Stats: 27 lines in 1 file changed: 8 ins; 11 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/17130.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17130/head:pull/17130

PR: https://git.openjdk.org/jdk/pull/17130

From mli at openjdk.org  Mon Feb 26 10:32:10 2024
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 26 Feb 2024 10:32:10 GMT
Subject: RFR: 8322179: RISC-V: Implement SHA-1 intrinsic [v13]
In-Reply-To: <4OzT8N5D898swa1PZUiGcBkEQ5GMEINUd92aHFqWbMw=.3741f53c-e1c2-43fa-ae37-431ecb60689f@github.com>
References: <PyIXzENfiHysFS3IyZn3FDNQpV7Ua2L6OmjiXq9wRoU=.cf74a45e-c94b-4f7b-8768-d10d55e2ce1d@github.com>
 <3PjX6O1hKuQWqOV_mSS_a2o8pJJfyl5VeApdovyjSvk=.0dad6f46-ffac-49e2-91cc-94c88d569193@github.com>
 <4OzT8N5D898swa1PZUiGcBkEQ5GMEINUd92aHFqWbMw=.3741f53c-e1c2-43fa-ae37-431ecb60689f@github.com>
Message-ID: <2hNB7tOXJl_r1X84tQvUWbm2EnB7BGgUq43c9ObTZP4=.858feff9-1ba0-4eb2-ad09-18518e3d4567@github.com>

On Fri, 23 Feb 2024 22:16:21 GMT, Antonios Printezis <tonyp at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   assert register; move round param
>
> src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 4856:
> 
>> 4854:     if (round == 16) {
>> 4855:       int64_t block_bytes = round * 4;
>> 4856:       __ addi(buf, buf, block_bytes);
> 
> Does `buf` need to be incremented here? And why at `round == 16` and not after all the rounds are done? Maybe you can do this in the loop in `generate_sha1_implCompress` to have the code that initializes and increments it in the same function? Also, does it need to be incremented if `!multi_block`?

Thanks, Good catch!

And other comments are also resolved.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17130#discussion_r1502372429

From ihse at openjdk.org  Mon Feb 26 10:59:57 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 Feb 2024 10:59:57 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v6]
In-Reply-To: <Q8u6EqPKibxDuixCm6i4jeM1nFybu-tkmoHtjfNKPQw=.2e7c8dfa-a8a1-401d-b772-146878710373@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <wvVBVyQswVhKlZM7Ux8ifRbqpqCoebaGJjqWHzuW6Gw=.67f9d62d-e669-4ade-8d97-94df4eeceed8@github.com>
 <Q8u6EqPKibxDuixCm6i4jeM1nFybu-tkmoHtjfNKPQw=.2e7c8dfa-a8a1-401d-b772-146878710373@github.com>
Message-ID: <lUGJBPTFMt9yVkPVMLmh8zDdXYkRtZm8Kk5xXnDpWOY=.ba653ee5-f1ca-4936-920b-43afd3e013d2@github.com>

On Fri, 23 Feb 2024 12:38:56 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Great. The only remaining difference I see is that the PR adds the following export:
> 
> ```
> _ZGRN14AsyncLogWriter4NoneE_@@SUNWprivate_1.1
> ```
> 
> Any idea what it might be? If not, I guess we can live with that.

No. I vaguely recognize this symbol as sticking out, but can't find it now in my runs. Which gcc version are you using?

I think this is another example of the gcc bug. `c++filt` says `reference temporary #0 for AsyncLogWriter::None`; I guess this is from `logAsyncWriter.cpp` line 47-49:

// LogDecorator::None applies to 'constant initialization' because of its constexpr constructor.
const LogDecorations& AsyncLogWriter::None = LogDecorations(LogLevel::Warning, LogTagSetMapping<LogTag::__NO_TAG>::tagset(),
                                      LogDecorators::None);


But I think we can live with that anyway, even if it gets exported for some gcc versions after this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1963855021

From sroy at openjdk.org  Mon Feb 26 11:24:13 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 26 Feb 2024 11:24:13 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v26]
In-Reply-To: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
Message-ID: <rzJcK8ej_SBTvT0ch_dy8b0DYLRKhBdas5HEI4TzHJ4=.d3a710bc-d754-418e-b9c6-114d5a66757b@github.com>

> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am.
> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX.
> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails.

Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:

   Address review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16604/files
  - new: https://git.openjdk.org/jdk/pull/16604/files/664e41a4..1943445d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=24-25

  Stats: 18 lines in 1 file changed: 0 ins; 10 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/16604.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604

PR: https://git.openjdk.org/jdk/pull/16604

From stuefe at openjdk.org  Mon Feb 26 11:24:54 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 26 Feb 2024 11:24:54 GMT
Subject: RFR: 8324849: Uniform use of synchronizations in NMT
In-Reply-To: <uikMP7BCa6Wro3F63W7C4qQZNMgDSjSYXzHEGCroSDA=.aef515a7-6352-41d5-8aa5-ac0c94e5886d@github.com>
References: <uikMP7BCa6Wro3F63W7C4qQZNMgDSjSYXzHEGCroSDA=.aef515a7-6352-41d5-8aa5-ac0c94e5886d@github.com>
Message-ID: <O4ICw3jcjddzbpY3sgDfIv-Wbbv7jlaO_30JQuL3Vk0=.3d0c213d-7cc6-4e6b-a406-ce01ae0a6331@github.com>

On Mon, 26 Feb 2024 07:41:45 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> In NMT, both `ThreadCritical` and `Tracker` objects are used to do synchronizations. `Tracker` class uses `ThreadCritical` internally and used only for uncommit and release memory operations.  In this change, `Tracker` class is replaced with explicit use of `ThreadCritical` to be the same as the other instances of sync'ing NMT operations.
> 
> tiers1-5 tests passed.

+1. Yes, please.

-------------

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18000#pullrequestreview-1900616208

From sroy at openjdk.org  Mon Feb 26 11:29:02 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 26 Feb 2024 11:29:02 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v25]
In-Reply-To: <g8N9lwxRyXWYCt8OnndT8JwAqgJMFeSiqTa6_HS2e6Q=.eaef7669-c34c-4457-b22d-fdc96e43ba2a@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <xemN0ZxPQvRMrO-v4824K36DyT1c42nuOYzLtyUtGnI=.bb7c2f33-cb3c-466b-9d00-76ad3e3fa677@github.com>
 <g8N9lwxRyXWYCt8OnndT8JwAqgJMFeSiqTa6_HS2e6Q=.eaef7669-c34c-4457-b22d-fdc96e43ba2a@github.com>
Message-ID: <BNmamq3P5QG9yN5a76PQjiaxpBMc_syshmA09xu4cj8=.a56d9526-85cd-4801-8680-f76fefb3dc23@github.com>

On Sun, 25 Feb 2024 06:32:20 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>    remove space
>
> src/hotspot/os/aix/os_aix.cpp line 1173:
> 
>> 1171:   char* const pointer_to_dot = strrchr(file_path, '.');
>> 1172:   char const *old_extension = ".so";
>> 1173:   char const *new_extension = ".a";
> 
> Suggestion:
> 
>   char* const file_path = strdup(filename);
>   char* const pointer_to_dot = strrchr(file_path, '.');
>   const char old_extension[] = ".so";
>   const char new_extension[] = ".a";
>   STATIC_ASSERT(sizeof(old_exception) >= sizeof(new_exception));
> 
> and remove runtime-assert below

@tstuefe  done. Anyreason why we use [] instead of the pointer. Doesn't [] convert into *(baseaddress) ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1502454196

From jsjolen at openjdk.org  Mon Feb 26 11:34:56 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 26 Feb 2024 11:34:56 GMT
Subject: RFR: 8324849: Uniform use of synchronizations in NMT
In-Reply-To: <uikMP7BCa6Wro3F63W7C4qQZNMgDSjSYXzHEGCroSDA=.aef515a7-6352-41d5-8aa5-ac0c94e5886d@github.com>
References: <uikMP7BCa6Wro3F63W7C4qQZNMgDSjSYXzHEGCroSDA=.aef515a7-6352-41d5-8aa5-ac0c94e5886d@github.com>
Message-ID: <1aeJYGWKpFN9D8YGxVE6mMd3N_yH5fjsZ60GuRMlk9I=.d892a0e1-6508-4c2a-8a3d-06734d70cb47@github.com>

On Mon, 26 Feb 2024 07:41:45 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> In NMT, both `ThreadCritical` and `Tracker` objects are used to do synchronizations. `Tracker` class uses `ThreadCritical` internally and used only for uncommit and release memory operations.  In this change, `Tracker` class is replaced with explicit use of `ThreadCritical` to be the same as the other instances of sync'ing NMT operations.
> 
> tiers1-5 tests passed.

Marked as reviewed by jsjolen (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18000#pullrequestreview-1900643793

From rkennke at openjdk.org  Mon Feb 26 12:45:56 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 26 Feb 2024 12:45:56 GMT
Subject: RFR: 8305898: Alternative self-forwarding mechanism [v4]
In-Reply-To: <OC2HtdWXXKiV3OLkz39XVG7bickA31IZZVgpZpZy3GU=.04506b71-994c-4dc6-a39f-cf0d0c908977@github.com>
References: <N4eX8S-btv0VD19kl2W9RigVsaw58ZVXDZllFwykZ04=.a9456aa8-b294-480a-b7f0-07616c972f62@github.com>
 <OC2HtdWXXKiV3OLkz39XVG7bickA31IZZVgpZpZy3GU=.04506b71-994c-4dc6-a39f-cf0d0c908977@github.com>
Message-ID: <hVWQLQn6rnJcFCVOTgHbXy2om-m6SToXmq6KPDjAlaM=.938eac76-e9ad-4b93-ac69-e17c0a039ed3@github.com>

On Thu, 8 Feb 2024 14:37:20 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Currently, the Serial, Parallel and G1 GCs store a pointer to self into object headers to indicate promotion failure. This is problematic for compact object headers ([JDK-8294992](https://bugs.openjdk.org/browse/JDK-8294992)) because it would (temporarily) over-write the crucial class information, which we need for heap parsing. I would like to propose an alternative: use the currently unused 3rd header bit (previously biased-locking bit) to indicate that an object is 'self-forwarded'. That preserves the crucial class information in the upper bits of the header until the full header gets restored.
>> 
>> This is a trimmed-down/simplified version of the original proposal #13779:
>>  - It doesn't use/introduce any flags and avoids the associated branching.
>>  - It doesn't (need to) deal with displaced headers. (Current code would preserve header if necessary, Lilliput code would not use displaced headers and set the 3rd bit directly in existing header.)
>> 
>> Testing:
>>  - [x] hotspot_gc
>>  - [x] tier1
>>  - [x] tier2
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More consistent use of markWord::is_forwarded()

A potential improvement to this might be that we could avoid preserving the header around self-forwarding/promo-failure (and therefore remove a bunch of code/complexity). What's needed for this is a fast way to detect is_forwarded() that includes both scenarios normal-forwarded and self-forwarded.

Currently I also set normal-forwarded bits when self-forwarding to facilitate simple (v & 3) == 3 test. We would need something like ((v & 4) != 0) || ((v & 3) == 3) test, but ideally without the branch. Since we don't really care about 0b111 (should not happen), we could test ((v + 1) & 4) != 0. That is one more op (e.g. single cycle) compared to the current test, but that should hardly be noticeable (dominated by the load of the header anyway).

Then, instead of init-ing the self-forwarded header, and restoring any 'interesting' marks (hashed, locked), we could simply flip-back the self-fwd bit and that'd be it.

1. Do we want this?
2. Do we want this in this PR, or better in a follow-up PR (including the removal of header-preservation around promo-failures)?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17755#issuecomment-1964062243

From tonyp at openjdk.org  Mon Feb 26 14:39:57 2024
From: tonyp at openjdk.org (Antonios Printezis)
Date: Mon, 26 Feb 2024 14:39:57 GMT
Subject: RFR: 8322179: RISC-V: Implement SHA-1 intrinsic [v14]
In-Reply-To: <qOXJYauKdggsWmevBILNLDlWaL0rqQlXxlvbDRr9Sko=.cd488d1d-6ad8-4f19-8ad8-6ab4292638ce@github.com>
References: <PyIXzENfiHysFS3IyZn3FDNQpV7Ua2L6OmjiXq9wRoU=.cf74a45e-c94b-4f7b-8768-d10d55e2ce1d@github.com>
 <qOXJYauKdggsWmevBILNLDlWaL0rqQlXxlvbDRr9Sko=.cd488d1d-6ad8-4f19-8ad8-6ab4292638ce@github.com>
Message-ID: <La2edu618Z9nC8L8qgw6CW94bP1BRA446T18iytGlMU=.dd5bbe89-fcee-4b34-a59b-a7cec29e30d4@github.com>

On Mon, 26 Feb 2024 10:32:10 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you review this patch to implement SHA-1 intrinsic for riscv?
>> Thanks!
>> 
>> 
>> ## Test
>> 
>> ### Functionality
>> 
>> tests under `test/hotspot/jtreg/compiler/intrinsics/sha`
>> tests found via `find test/jdk -iname "*SHA1*.java"`
>> 
>> ### Performance
>> 
>> tested on `T-HEAD Light Lichee Pi 4A`
>> 
>> JMH_PARAMS="-f 1 -wi 10 -i 20" // for every loop of jmh test
>> 
>> benchmark tests `MessageDigests.java GetMessageDigest.java MessageDigestBench.java MacBench.java` which are under `test/micro/org/openjdk/bench/`, more spcifically `TESTS="MessageDigests.digest MessageDigests.getAndDigest MessageDigestBench.digest"`
>> 
>> 
>> // After
>> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1        64     DEFAULT  avgt   20      1845.446 ?     27.052  ns/op
>> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    181455.350 ?    532.258  ns/op
>> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2447.674 ?     10.239  ns/op
>> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    182896.083 ?   1242.774  ns/op
>> o.o.b.javax.crypto.small.MessageDigestBench.digest         SHA1     1048576             N/A       N/A              avgt   20  11599227.792 ? 121442.390  ns/op
>> // Before
>> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2352.475 ?    11.198  ns/op
>> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    188495.684 ?  1467.942  ns/op
>> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2437.347 ?     6.398  ns/op
>> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    196086.570 ?  1140.998  ns/op
>> o.o.b.javax.crypto.small.MessageDigestBench.digest         SHA1     1048576             N/A       N/A              avgt   20  12362160.119 ? 38788.109  ns/op
>> 
>> 
>> **getAndDigest when size == 64**
>> The data is not stable for test getAndDigest when size == 64, which I think is introduced by  j.s.MessageDigest.getInstance itself, which we don't touch in this patch.
>> Check more details at [1](ht...
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   refine code

Thanks for applying the changes! PR LGTM.

-------------

Marked as reviewed by tonyp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17130#pullrequestreview-1901051840

From stuefe at openjdk.org  Mon Feb 26 14:40:53 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 26 Feb 2024 14:40:53 GMT
Subject: RFR: 8324849: Uniform use of synchronizations in NMT
In-Reply-To: <n_1OdA4LcLIvw-mkQ_U-2nItlBv9m0DGK62gb_p0xnQ=.137f48b6-f0cc-476e-b856-3c87b888d98a@github.com>
References: <uikMP7BCa6Wro3F63W7C4qQZNMgDSjSYXzHEGCroSDA=.aef515a7-6352-41d5-8aa5-ac0c94e5886d@github.com>
 <n_1OdA4LcLIvw-mkQ_U-2nItlBv9m0DGK62gb_p0xnQ=.137f48b6-f0cc-476e-b856-3c87b888d98a@github.com>
Message-ID: <79G0nNMiijlLGMJVEQ0m5U-8idyCGGdHLm4CNk-_npA=.5c520d29-9980-4e00-b956-1a54495afa0a@github.com>

On Mon, 26 Feb 2024 07:53:26 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> In NMT, both `ThreadCritical` and `Tracker` objects are used to do synchronizations. `Tracker` class uses `ThreadCritical` internally and used only for uncommit and release memory operations.  In this change, `Tracker` class is replaced with explicit use of `ThreadCritical` to be the same as the other instances of sync'ing NMT operations.
>> 
>> tiers1-5 tests passed.
>
> I never understood why we had this `Tracker` class  so I'm inclined to accept this PR, but I'd like to wait for other opinions before giving you an approval.

BTW, since you are here, and if @jdksjolen agrees:

Could we rename VirtualMemoryTracker::remove_uncommitted_region to something else (e.g. VirtualMemoryTracker::remove_committed_region or VirtualMemoryTracker::uncommit_region)? I always start wondering when reading this function name, since we don't remove an uncommitted region, we uncommit a region resp. remove a committed region.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18000#issuecomment-1964300369

From jsjolen at openjdk.org  Mon Feb 26 14:49:56 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 26 Feb 2024 14:49:56 GMT
Subject: RFR: 8324849: Uniform use of synchronizations in NMT
In-Reply-To: <n_1OdA4LcLIvw-mkQ_U-2nItlBv9m0DGK62gb_p0xnQ=.137f48b6-f0cc-476e-b856-3c87b888d98a@github.com>
References: <uikMP7BCa6Wro3F63W7C4qQZNMgDSjSYXzHEGCroSDA=.aef515a7-6352-41d5-8aa5-ac0c94e5886d@github.com>
 <n_1OdA4LcLIvw-mkQ_U-2nItlBv9m0DGK62gb_p0xnQ=.137f48b6-f0cc-476e-b856-3c87b888d98a@github.com>
Message-ID: <fA21LvS-wzafLsPkOwfeJyBKwk7Dbd4tTCAGZWfT98w=.d7256753-9451-4a78-927f-87cc79dfb80e@github.com>

On Mon, 26 Feb 2024 07:53:26 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> In NMT, both `ThreadCritical` and `Tracker` objects are used to do synchronizations. `Tracker` class uses `ThreadCritical` internally and used only for uncommit and release memory operations.  In this change, `Tracker` class is replaced with explicit use of `ThreadCritical` to be the same as the other instances of sync'ing NMT operations.
>> 
>> tiers1-5 tests passed.
>
> I never understood why we had this `Tracker` class  so I'm inclined to accept this PR, but I'd like to wait for other opinions before giving you an approval.

> BTW, since you are here, and if @jdksjolen agrees:
> 
> Could we rename VirtualMemoryTracker::remove_uncommitted_region to something else (e.g. VirtualMemoryTracker::remove_committed_region or VirtualMemoryTracker::uncommit_region)? I always start wondering when reading this function name, since we don't remove an uncommitted region, we uncommit a region resp. remove a committed region.

_**Yes!**_

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18000#issuecomment-1964320998

From jbhateja at openjdk.org  Mon Feb 26 14:54:58 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 26 Feb 2024 14:54:58 GMT
Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v13]
In-Reply-To: <MZj_08eJiTVFJyis-u7V8SBGal_cJ-6tIYr0oFseVpY=.329ca24b-48e3-4c3d-80ec-a395d9d8a4d5@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <MZj_08eJiTVFJyis-u7V8SBGal_cJ-6tIYr0oFseVpY=.329ca24b-48e3-4c3d-80ec-a395d9d8a4d5@github.com>
Message-ID: <oRt7NAJM09gHPJjvjfsIso3kemxAusH7mhNePnsGVbI=.e27e2420-4a20-436a-b33e-d95f15f09dd8@github.com>

On Thu, 22 Feb 2024 03:15:10 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions.  This change accelerates String.IndexOf on average 1.3x for AVX2.  The benchmark numbers:
>> 
>> 
>> Benchmark	                                               Score		Latest		
>> StringIndexOf.advancedWithMediumSub   343.573		317.934		0.925375393x
>> StringIndexOf.advancedWithShortSub1	  1039.081		1053.96		1.014319384x
>> StringIndexOf.advancedWithShortSub2	      55.828		110.541		1.980027943x
>> StringIndexOf.constantPattern	                9.361		11.906		1.271872663x
>> StringIndexOf.searchCharLongSuccess	        4.216		4.218		1.000474383x
>> StringIndexOf.searchCharMediumSuccess	3.133		3.216		1.02649218x
>> StringIndexOf.searchCharShortSuccess	3.76		        3.761		1.000265957x
>> StringIndexOf.success	                                9.186		9.713		1.057369911x
>> StringIndexOf.successBig	                      14.341		46.343		3.231504079x
>> StringIndexOfChar.latin1_AVX2_String	  6220.918		12154.52		1.953814533x
>> StringIndexOfChar.latin1_AVX2_char	  5503.556		5540.044		1.006629895x
>> StringIndexOfChar.latin1_SSE4_String	  6978.854		6818.689		0.977049957x
>> StringIndexOfChar.latin1_SSE4_char	  5657.499		5474.624		0.967675646x
>> StringIndexOfChar.latin1_Short_String	  7132.541		6863.359		0.962260014x
>> StringIndexOfChar.latin1_Short_char	16013.389	      16162.437		1.009307711x
>> StringIndexOfChar.latin1_mixed_String	  7386.123	      14771.622		1.999915517x
>> StringIndexOfChar.latin1_mixed_char	  9901.671		9782.245		0.987938803
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed some review coments; replaced hard-coded registers with descriptive names.

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 303:

> 301:       __ subq(rdi, rax);
> 302:       __ movq(rdx, rdi);
> 303:       __ andq(rdx, -16);

Hi @asgibbons , may I request you to please use meaningful names instead of directly using actual GRP names.

src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 777:

> 775:       __ movq(rax, rbx);
> 776:       __ movq(rbx, r14);
> 777:       __ leaq(r15, Address(r12, -0x2));

Kindly use semantically meaningful names instead of direct GPR names.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1502738843
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1502741451

From gcao at openjdk.org  Mon Feb 26 15:00:14 2024
From: gcao at openjdk.org (Gui Cao)
Date: Mon, 26 Feb 2024 15:00:14 GMT
Subject: RFR: 8319900: Recursive lightweight locking: riscv64
 implementation [v2]
In-Reply-To: <OJTtw2p54KDzlRMC2qeNNHpodtRBRdA_4wvPxYfSX4Q=.76bf740b-d1ed-4586-8175-e759c13ca12b@github.com>
References: <OJTtw2p54KDzlRMC2qeNNHpodtRBRdA_4wvPxYfSX4Q=.76bf740b-d1ed-4586-8175-e759c13ca12b@github.com>
Message-ID: <_5-zlOKwBm1j1itPVqA3MklCXH7SueaJDBxRB7ctvQc=.f0ef6364-bdff-428b-bbb9-60c9f9aae51e@github.com>

> Implementation of recursive lightweight JDK-8319796 for linux-riscv64.
> 
> ### Correctness testing:
> 
> - [x]  Run tier1-3, hotspot:tier4 tests with -XX:LockingMode=1 & -XX:LockingMode=2 on LicheePI 4A (release)
> - [x]  Run tier1-3 tests with -XX:LockingMode=1 & -XX:LockingMode=2 on qemu 8.1.0 (fastdebug)
> 
> ### JMH tested on LicheePI 4A:
> 
> 
> Before (LockingMode = 2):
> 
> Benchmark                                (innerCount)  Mode  Cnt       Score      Error  Units
> LockUnlock.testContendedLock                      100  avgt   12     281.603 ?    2.626  ns/op
> LockUnlock.testRecursiveLockUnlock                100  avgt   12  196373.917 ? 4669.241  ns/op
> LockUnlock.testRecursiveSynchronization           100  avgt   12     274.492 ?    6.049  ns/op
> LockUnlock.testSerialLockUnlock                   100  avgt   12   11516.092 ?   69.964  ns/op
> LockUnlock.testSimpleLockUnlock                   100  avgt   12   11490.789 ?   58.833  ns/op
> 
> After (LockingMode = 2):
> 
> Benchmark                                (innerCount)  Mode  Cnt      Score    Error  Units
> LockUnlock.testContendedLock                      100  avgt   12    307.013 ?  3.259  ns/op
> LockUnlock.testRecursiveLockUnlock                100  avgt   12  59047.222 ? 94.748  ns/op
> LockUnlock.testRecursiveSynchronization           100  avgt   12    259.789 ?  1.698  ns/op
> LockUnlock.testSerialLockUnlock                   100  avgt   12   6055.775 ? 13.518  ns/op
> LockUnlock.testSimpleLockUnlock                   100  avgt   12   6090.986 ? 67.179  ns/op
> 
> 
> 
> Before (LockingMode = 1):
> 
> Benchmark                                (innerCount)  Mode  Cnt      Score     Error  Units
> LockUnlock.testContendedLock                      100  avgt   12    286.144 ?   2.490  ns/op
> LockUnlock.testRecursiveLockUnlock                100  avgt   12  68058.259 ? 286.262  ns/op
> LockUnlock.testRecursiveSynchronization           100  avgt   12    263.132 ?   4.075  ns/op
> LockUnlock.testSerialLockUnlock                   100  avgt   12   7521.777 ?  35.193  ns/op
> LockUnlock.testSimpleLockUnlock                   100  avgt   12   7522.480 ?  26.310  ns/op
> 
> After (LockingMode = 1):
> 
> Benchmark                                (innerCount)  Mode  Cnt      Score     Error  Units
> LockUnlock.testContendedLock                      100  avgt   12    289.034 ?   5.821  ns/op
> LockUnlock.testRecursiveLockUnlock                100  avgt   12  68474.370 ? 495.135  ns/op
> LockUnlock.testRecursiveSynchronization           100  avgt   12    261.052 ?   4.560  ns/op
> Loc...

Gui Cao has updated the pull request incrementally with one additional commit since the last revision:

  fix comment typo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17554/files
  - new: https://git.openjdk.org/jdk/pull/17554/files/4bea5ddc..fc104a38

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17554&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17554&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17554.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17554/head:pull/17554

PR: https://git.openjdk.org/jdk/pull/17554

From pchilanomate at openjdk.org  Mon Feb 26 15:25:13 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 26 Feb 2024 15:25:13 GMT
Subject: RFR: 8322962: Upcall stub might go undetected when freezing frames
 [v2]
In-Reply-To: <9wGivvL8XaePg4yOjShuasS2RZzyT2bzUi8EKWs95yQ=.36456962-47a7-4920-9a3a-a15936d4f480@github.com>
References: <9wGivvL8XaePg4yOjShuasS2RZzyT2bzUi8EKWs95yQ=.36456962-47a7-4920-9a3a-a15936d4f480@github.com>
Message-ID: <-bOmKAxXt_yXqWPh7hAANv06XjWhInYG_1attwwz8zs=.b541dae6-06aa-4130-91e2-53904676dbde@github.com>

> Please review this simple fix. There is a missing push_cont_fastpath()/pop_cont_fastpath() around the call to Java in the upcall stub. Because of this, if from that upcall a virtual thread tries to yield, and all the other methods in the stack are compiled, we will incorrectly take the freeze fast path and freeze everything in the stack including the native frames. By forcing the slow path instead we will identify the upcall stub and pin the vthread.
> 
> The issue can be easily reproduced by running the modified version of test GetStackTraceALotWhenPinned.java included in this patch. I also tested the fix by running tiers1-3 in mach5. 
> 
> Thanks,
> Patricio

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  improve freeze fast path check

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17964/files
  - new: https://git.openjdk.org/jdk/pull/17964/files/5404cf02..cbd81b2b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17964&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17964&range=00-01

  Stats: 13 lines in 1 file changed: 3 ins; 4 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/17964.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17964/head:pull/17964

PR: https://git.openjdk.org/jdk/pull/17964

From pchilanomate at openjdk.org  Mon Feb 26 15:25:14 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 26 Feb 2024 15:25:14 GMT
Subject: RFR: 8322962: Upcall stub might go undetected when freezing frames
 [v2]
In-Reply-To: <tCsYqd6FAXA-khjAY_KkUp7WHbRSYEcHRbxMWF3fR9k=.58a348eb-2f70-4979-a864-498c76d8e962@github.com>
References: <9wGivvL8XaePg4yOjShuasS2RZzyT2bzUi8EKWs95yQ=.36456962-47a7-4920-9a3a-a15936d4f480@github.com>
 <tCsYqd6FAXA-khjAY_KkUp7WHbRSYEcHRbxMWF3fR9k=.58a348eb-2f70-4979-a864-498c76d8e962@github.com>
Message-ID: <jpMIPeiYFRXUCFs61maEmU_5q7vFd6PiJTeVIpevYEQ=.ae5a02a7-53ea-4021-83f0-963e90f36a3e@github.com>

On Fri, 23 Feb 2024 14:40:00 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   improve freeze fast path check
>
> LGTM. Test is passing on linux PPC64le.

Thanks for the reviews @TheRealMDoerr and @RealFYang.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17964#issuecomment-1964363519

From pchilanomate at openjdk.org  Mon Feb 26 15:25:15 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 26 Feb 2024 15:25:15 GMT
Subject: RFR: 8322962: Upcall stub might go undetected when freezing frames
In-Reply-To: <gIBJicb_Il9HfyglJMmJeNJBf6rbHK4YTWRKPZMQV5Q=.7cfab26c-922d-4c3c-ab0c-2ba58b6aa3be@github.com>
References: <9wGivvL8XaePg4yOjShuasS2RZzyT2bzUi8EKWs95yQ=.36456962-47a7-4920-9a3a-a15936d4f480@github.com>
 <gIBJicb_Il9HfyglJMmJeNJBf6rbHK4YTWRKPZMQV5Q=.7cfab26c-922d-4c3c-ab0c-2ba58b6aa3be@github.com>
Message-ID: <dkRg6U4fMfwPT3YqklXE6oQ6uC5yktB87y6E_5U1uXY=.c8849d6c-ca68-456f-b2f6-e3064ca82a7e@github.com>

On Sat, 24 Feb 2024 06:02:14 GMT, Dean Long <dlong at openjdk.org> wrote:

> Is there a way to automatically detect missing calls to push_cont_fastpath?
>
There is a check at the beginning of freeze that we don't have interpreter or native frames if we take the fast path. This missed that we can also go from native->Java using the Panama API rather than JNI. But I changed that check now to explicitly verify that all frames in the stack are compiled. Please take a look.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17964#issuecomment-1964391505

From ayang at openjdk.org  Mon Feb 26 15:29:00 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 26 Feb 2024 15:29:00 GMT
Subject: RFR: 8305898: Alternative self-forwarding mechanism [v4]
In-Reply-To: <OC2HtdWXXKiV3OLkz39XVG7bickA31IZZVgpZpZy3GU=.04506b71-994c-4dc6-a39f-cf0d0c908977@github.com>
References: <N4eX8S-btv0VD19kl2W9RigVsaw58ZVXDZllFwykZ04=.a9456aa8-b294-480a-b7f0-07616c972f62@github.com>
 <OC2HtdWXXKiV3OLkz39XVG7bickA31IZZVgpZpZy3GU=.04506b71-994c-4dc6-a39f-cf0d0c908977@github.com>
Message-ID: <nICORfXgD_s_a4YDdXzr2akkdzLKWodAdma7aaOVprk=.39162afc-b900-4013-a3aa-7a060c6d1a51@github.com>

On Thu, 8 Feb 2024 14:37:20 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Currently, the Serial, Parallel and G1 GCs store a pointer to self into object headers to indicate promotion failure. This is problematic for compact object headers ([JDK-8294992](https://bugs.openjdk.org/browse/JDK-8294992)) because it would (temporarily) over-write the crucial class information, which we need for heap parsing. I would like to propose an alternative: use the currently unused 3rd header bit (previously biased-locking bit) to indicate that an object is 'self-forwarded'. That preserves the crucial class information in the upper bits of the header until the full header gets restored.
>> 
>> This is a trimmed-down/simplified version of the original proposal #13779:
>>  - It doesn't use/introduce any flags and avoids the associated branching.
>>  - It doesn't (need to) deal with displaced headers. (Current code would preserve header if necessary, Lilliput code would not use displaced headers and set the 3rd bit directly in existing header.)
>> 
>> Testing:
>>  - [x] hotspot_gc
>>  - [x] tier1
>>  - [x] tier2
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More consistent use of markWord::is_forwarded()

I'm leaning towards doing that in a follow-up PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17755#issuecomment-1964416744

From ihse at openjdk.org  Mon Feb 26 16:18:14 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 Feb 2024 16:18:14 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v7]
In-Reply-To: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
Message-ID: <TQ6cEW0z4kPTgmO71_ngAknaBp52wY5RzAfA85eQ_Pg=.7406352f-c3b5-4198-b219-1a29c783e049@github.com>

> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
> 
> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
> 
> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
> 
> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.

Magnus Ihse Bursie 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 hotspot-symbols-proper
 - Revert "Use #pragma instead of HIDDEN define"
   
   This reverts commit 00e40a7f6e4cdef6592d72b3d08063cdcc41532a.
 - Use #pragma instead of HIDDEN define
 - Rename the version script to version-script.txt
 - Restore linker script to linux/gcc builds
 - Rename the Windows export file to .def
 - Remove unused symbol _Copy_conjoint_bytes on linux/arm32
 - 8017234: Hotspot should stop using mapfiles

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17955/files
  - new: https://git.openjdk.org/jdk/pull/17955/files/7be8372a..6100950b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17955&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17955&range=05-06

  Stats: 7746 lines in 141 files changed: 5392 ins; 1355 del; 999 mod
  Patch: https://git.openjdk.org/jdk/pull/17955.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17955/head:pull/17955

PR: https://git.openjdk.org/jdk/pull/17955

From djelinski at openjdk.org  Mon Feb 26 16:47:46 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 26 Feb 2024 16:47:46 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v7]
In-Reply-To: <TQ6cEW0z4kPTgmO71_ngAknaBp52wY5RzAfA85eQ_Pg=.7406352f-c3b5-4198-b219-1a29c783e049@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <TQ6cEW0z4kPTgmO71_ngAknaBp52wY5RzAfA85eQ_Pg=.7406352f-c3b5-4198-b219-1a29c783e049@github.com>
Message-ID: <S5IB9JPnGz2UBlJFInTjltwjbomfVvXytmAol_IATfA=.bfc67f99-7eef-42d4-a367-d8a281ebcfbe@github.com>

On Mon, 26 Feb 2024 16:18:14 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
>> 
>> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
>> 
>> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
>> 
>> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.
>
> Magnus Ihse Bursie 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 hotspot-symbols-proper
>  - Revert "Use #pragma instead of HIDDEN define"
>    
>    This reverts commit 00e40a7f6e4cdef6592d72b3d08063cdcc41532a.
>  - Use #pragma instead of HIDDEN define
>  - Rename the version script to version-script.txt
>  - Restore linker script to linux/gcc builds
>  - Rename the Windows export file to .def
>  - Remove unused symbol _Copy_conjoint_bytes on linux/arm32
>  - 8017234: Hotspot should stop using mapfiles

This is on GCC 9.4.0, Ubuntu 20.04.
I wonder if the reference to a temporary was intentional... but I guess that's a subject for another PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1964619969

From ihse at openjdk.org  Mon Feb 26 17:34:55 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 Feb 2024 17:34:55 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v8]
In-Reply-To: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
Message-ID: <_Gdp3pxakc2Q0rYlCnz0TK0o1WbSkM2CX_pKfd_QRsU=.d7129f84-2241-496b-9764-72aa4fc3b3cf@github.com>

> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
> 
> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
> 
> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
> 
> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Use --exclude-libs and -version-script on linux/clang too

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17955/files
  - new: https://git.openjdk.org/jdk/pull/17955/files/6100950b..c58764a8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17955&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17955&range=06-07

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/17955.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17955/head:pull/17955

PR: https://git.openjdk.org/jdk/pull/17955

From ihse at openjdk.org  Mon Feb 26 17:37:49 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 Feb 2024 17:37:49 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v2]
In-Reply-To: <-Cqtxv3gK-PQ__1WEPOg_ls4KG0xAeU-yJV1668TUKI=.632a12f6-74c2-4e27-a448-0a5b469cc22e@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <12hoUFbZkWHBpiXs0TPiMYGW3sSvBX_536mvSSG-y-8=.21abcef9-9a2b-4558-ba19-dddfd7931f9f@github.com>
 <0Inj4SqHl36K4FzxPfbfyA20_7x8GyGMngBfuNEGsf8=.9cba3073-cfdd-43a4-828a-4ec362dcaaf3@github.com>
 <-Cqtxv3gK-PQ__1WEPOg_ls4KG0xAeU-yJV1668TUKI=.632a12f6-74c2-4e27-a448-0a5b469cc22e@github.com>
Message-ID: <fqdz-3x241k4jmI02gP5fC7ax7L4R6lRUWiYcJcifJo=.b701061d-15e8-41e3-98b8-815ccbdd20ed@github.com>

On Fri, 23 Feb 2024 13:54:36 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> > I just realized I could keep an extremely simplified linker script ("mapfile") for gcc, and thereby keeping the `@SUNWprivate_1.1` on the exported symbols, and keeping `__bss_start` and friends local. This further minimizes the difference to the existing libjvm.so for gcc builds.
> 
> Why do this just for GCC? Shouldn't this be for Linux as we are doing it for backwards compatibility with user JNI libraries.

Good point. I did not really consider the case of clang on linux, since this is a secondary option, and I did not believe keeping consistency there was important. But as you say, the fix is trivial and makes a lot of sense. I have now verified that the symbols look identical when compiling with clang, between this PR and the latest (and hopefully last!) update, and mainline.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1964720104

From ihse at openjdk.org  Mon Feb 26 17:37:52 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 Feb 2024 17:37:52 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v7]
In-Reply-To: <TQ6cEW0z4kPTgmO71_ngAknaBp52wY5RzAfA85eQ_Pg=.7406352f-c3b5-4198-b219-1a29c783e049@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <TQ6cEW0z4kPTgmO71_ngAknaBp52wY5RzAfA85eQ_Pg=.7406352f-c3b5-4198-b219-1a29c783e049@github.com>
Message-ID: <4M3Qd_S0d-nR_m85Sd4Y1ynJl09XtwoJOSMVp5de1PA=.2798f37e-eabb-4dc6-80d6-92b2aa8889c5@github.com>

On Mon, 26 Feb 2024 16:18:14 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
>> 
>> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
>> 
>> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
>> 
>> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.
>
> Magnus Ihse Bursie 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 hotspot-symbols-proper
>  - Revert "Use #pragma instead of HIDDEN define"
>    
>    This reverts commit 00e40a7f6e4cdef6592d72b3d08063cdcc41532a.
>  - Use #pragma instead of HIDDEN define
>  - Rename the version script to version-script.txt
>  - Restore linker script to linux/gcc builds
>  - Rename the Windows export file to .def
>  - Remove unused symbol _Copy_conjoint_bytes on linux/arm32
>  - 8017234: Hotspot should stop using mapfiles

Can I get a second Hotspot reviewer for the Hotspot changes?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1964722207

From kvn at openjdk.org  Mon Feb 26 17:58:42 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 26 Feb 2024 17:58:42 GMT
Subject: RFR: 8324849: Uniform use of synchronizations in NMT
In-Reply-To: <uikMP7BCa6Wro3F63W7C4qQZNMgDSjSYXzHEGCroSDA=.aef515a7-6352-41d5-8aa5-ac0c94e5886d@github.com>
References: <uikMP7BCa6Wro3F63W7C4qQZNMgDSjSYXzHEGCroSDA=.aef515a7-6352-41d5-8aa5-ac0c94e5886d@github.com>
Message-ID: <EnnPhb1SV_E-FGrfqOyVmB3cFc7RUSpP3ax2ahxUgAs=.4bcacc1c-d15d-4bf9-8ec7-ac941c8dad88@github.com>

On Mon, 26 Feb 2024 07:41:45 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> In NMT, both `ThreadCritical` and `Tracker` objects are used to do synchronizations. `Tracker` class uses `ThreadCritical` internally and used only for uncommit and release memory operations.  In this change, `Tracker` class is replaced with explicit use of `ThreadCritical` to be the same as the other instances of sync'ing NMT operations.
> 
> tiers1-5 tests passed.

@afshin-zafari  Please, set correct RFE id number!!!!  See "Integration blockers" and "Issue".

-------------

Changes requested by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18000#pullrequestreview-1901631791

From stuefe at openjdk.org  Mon Feb 26 18:43:42 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 26 Feb 2024 18:43:42 GMT
Subject: RFR: 8324849: Uniform use of synchronizations in NMT
In-Reply-To: <EnnPhb1SV_E-FGrfqOyVmB3cFc7RUSpP3ax2ahxUgAs=.4bcacc1c-d15d-4bf9-8ec7-ac941c8dad88@github.com>
References: <uikMP7BCa6Wro3F63W7C4qQZNMgDSjSYXzHEGCroSDA=.aef515a7-6352-41d5-8aa5-ac0c94e5886d@github.com>
 <EnnPhb1SV_E-FGrfqOyVmB3cFc7RUSpP3ax2ahxUgAs=.4bcacc1c-d15d-4bf9-8ec7-ac941c8dad88@github.com>
Message-ID: <LuCDQJNok_GmZYSW5yjxl68cm1OCECnW4W_q7qlQ6Mc=.136c9a63-ed50-42ff-8dfd-f105a11b846d@github.com>

On Mon, 26 Feb 2024 17:55:43 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> @afshin-zafari  Please, set correct RFE id number!!!!  See "Integration blockers" and "Issue".

ow. But Skara bot did not catch this? How strange.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18000#issuecomment-1964870229

From kvn at openjdk.org  Mon Feb 26 19:32:45 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 26 Feb 2024 19:32:45 GMT
Subject: RFR: 8324849: Uniform use of synchronizations in NMT
In-Reply-To: <LuCDQJNok_GmZYSW5yjxl68cm1OCECnW4W_q7qlQ6Mc=.136c9a63-ed50-42ff-8dfd-f105a11b846d@github.com>
References: <uikMP7BCa6Wro3F63W7C4qQZNMgDSjSYXzHEGCroSDA=.aef515a7-6352-41d5-8aa5-ac0c94e5886d@github.com>
 <EnnPhb1SV_E-FGrfqOyVmB3cFc7RUSpP3ax2ahxUgAs=.4bcacc1c-d15d-4bf9-8ec7-ac941c8dad88@github.com>
 <LuCDQJNok_GmZYSW5yjxl68cm1OCECnW4W_q7qlQ6Mc=.136c9a63-ed50-42ff-8dfd-f105a11b846d@github.com>
Message-ID: <RKu9s5Zp_4Kw8Fr7MzvXq6uW3Z78tPwqK4b9OwKBP6g=.f70a1dd9-4b89-4774-8153-c251334078dc@github.com>

On Mon, 26 Feb 2024 18:40:42 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > @afshin-zafari  Please, set correct RFE id number!!!!  See "Integration blockers" and "Issue".
> 
> ow. But Skara bot did not catch this? How strange.

It catch - It will not allow you to integrate until you resolve "Integration blockers".

Yes, it would be better if Skara does not allow to create such PR but I am not sure Skara does these checks at that time.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18000#issuecomment-1965078008

From erikj at openjdk.org  Mon Feb 26 19:32:46 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 26 Feb 2024 19:32:46 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v8]
In-Reply-To: <_Gdp3pxakc2Q0rYlCnz0TK0o1WbSkM2CX_pKfd_QRsU=.d7129f84-2241-496b-9764-72aa4fc3b3cf@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <_Gdp3pxakc2Q0rYlCnz0TK0o1WbSkM2CX_pKfd_QRsU=.d7129f84-2241-496b-9764-72aa4fc3b3cf@github.com>
Message-ID: <G_FvCgiPHmG90CLV_iijU2YYwUtKnaCxXqiAPnHqmUo=.3414c8e4-c26c-4016-8aa8-0759c4e65d8d@github.com>

On Mon, 26 Feb 2024 17:34:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
>> 
>> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
>> 
>> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
>> 
>> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use --exclude-libs and -version-script on linux/clang too

>From a build point of view, I think this looks good now.

-------------

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17955#pullrequestreview-1901822546

From kcr at openjdk.org  Mon Feb 26 19:39:47 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 26 Feb 2024 19:39:47 GMT
Subject: RFR: 8324849: Uniform use of synchronizations in NMT
In-Reply-To: <uikMP7BCa6Wro3F63W7C4qQZNMgDSjSYXzHEGCroSDA=.aef515a7-6352-41d5-8aa5-ac0c94e5886d@github.com>
References: <uikMP7BCa6Wro3F63W7C4qQZNMgDSjSYXzHEGCroSDA=.aef515a7-6352-41d5-8aa5-ac0c94e5886d@github.com>
Message-ID: <pJimKUkV-M4tzamXMoQGD1OSVS9CXKrn_PkfXo5bjQI=.432af6c3-dab3-466b-a544-1c1a340f4300@github.com>

On Mon, 26 Feb 2024 07:41:45 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> In NMT, both `ThreadCritical` and `Tracker` objects are used to do synchronizations. `Tracker` class uses `ThreadCritical` internally and used only for uncommit and release memory operations.  In this change, `Tracker` class is replaced with explicit use of `ThreadCritical` to be the same as the other instances of sync'ing NMT operations.
> 
> tiers1-5 tests passed.

FWIW, the correct bug ID is "8324829"

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18000#issuecomment-1965104702

From dchuyko at openjdk.org  Mon Feb 26 20:08:46 2024
From: dchuyko at openjdk.org (Dmitry Chuyko)
Date: Mon, 26 Feb 2024 20:08:46 GMT
Subject: RFR: 8309271: A way to align already compiled methods with
 compiler directives [v26]
In-Reply-To: <CGpD9K9DLOAG7WkUfJ9MSIqyrJZeZucG69QekIe4KQM=.81719099-c20b-4961-bc17-11bc2e139b5c@github.com>
References: <csWpTiZu4dQgyARmNGro8PYl8yLj6-dRjVdsh51jV0k=.c0e25efd-3ee0-4196-a05a-c54268f23660@github.com>
 <CGpD9K9DLOAG7WkUfJ9MSIqyrJZeZucG69QekIe4KQM=.81719099-c20b-4961-bc17-11bc2e139b5c@github.com>
Message-ID: <T0Ccy5YZGXo42vp4sfm0q256eOZ30W7OmlvpAzpUCzE=.97d02831-0c3b-4abd-97b6-b8cd15055b46@github.com>

On Sat, 24 Feb 2024 11:22:17 GMT, Dmitry Chuyko <dchuyko at openjdk.org> wrote:

>> Compiler Control (https://openjdk.org/jeps/165) provides method-context dependent control of the JVM compilers (C1 and C2). The active directive stack is built from the directive files passed with the `-XX:CompilerDirectivesFile` diagnostic command-line option and the Compiler.add_directives diagnostic command. It is also possible to clear all directives or remove the top from the stack.
>> 
>> A matching directive will be applied at method compilation time when such compilation is started. If directives are added or changed, but compilation does not start, then the state of compiled methods doesn't correspond to the rules. This is not an error, and it happens in long running applications when directives are added or removed after compilation of methods that could be matched. For example, the user decides that C2 compilation needs to be disabled for some method due to a compiler bug, issues such a directive but this does not affect the application behavior. In such case, the target application needs to be restarted, and such an operation can have high costs and risks. Another goal is testing/debugging compilers.
>> 
>> It would be convenient to optionally reconcile at least existing matching nmethods to the current stack of compiler directives (so bypass inlined methods).
>> 
>> Natural way to eliminate the discrepancy between the result of compilation and the broken rule is to discard the compilation result, i.e. deoptimization. Prior to that we can try to re-compile the method letting compile broker to perform it taking new directives stack into account. Re-compilation helps to prevent hot methods from execution in the interpreter.
>> 
>> A new flag `-r` has beed introduced for some directives related to compile commands: `Compiler.add_directives`, `Compiler.remove_directives`, `Compiler.clear_directives`. The default behavior has not changed (no flag). If the new flag is present, the command scans already compiled methods and puts methods that have any active non-default matching compiler directives to re-compilation if possible, otherwise marks them for deoptimization. There is currently no distinction which directives are found. In particular, this means that if there are rules for inlining into some method, it will be refreshed. On the other hand, if there are rules for a method and it was inlined, top-level methods won't be refreshed, but this can be achieved by having rules for them.
>> 
>> In addition, a new diagnostic command `Compiler.replace_directives...
>
> Dmitry Chuyko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits:
> 
>  - Merge branch 'openjdk:master' into compiler-directives-force-update
>  - Merge branch 'openjdk:master' into compiler-directives-force-update
>  - Merge branch 'openjdk:master' into compiler-directives-force-update
>  - Merge branch 'openjdk:master' into compiler-directives-force-update
>  - Merge branch 'openjdk:master' into compiler-directives-force-update
>  - Merge branch 'openjdk:master' into compiler-directives-force-update
>  - Merge branch 'openjdk:master' into compiler-directives-force-update
>  - Deopt osr, cleanups
>  - Merge branch 'openjdk:master' into compiler-directives-force-update
>  - Merge branch 'openjdk:master' into compiler-directives-force-update
>  - ... and 34 more: https://git.openjdk.org/jdk/compare/d10f277b...6d639ace

As this is an extension of the existing compiler control mechanism.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14111#issuecomment-1965157823

From ihse at openjdk.org  Mon Feb 26 20:09:43 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 Feb 2024 20:09:43 GMT
Subject: RFR: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234 [v3]
In-Reply-To: <PjRWrB0x0vcYcQoa6EK62usvbNr_AFa_IN2ljCLrDDI=.4d69297c-6996-4cb7-9bd6-50f961c43686@github.com>
References: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
 <TYE1ieXypz7WiaTQRwU3Zp-ICrZ2E4SIo4meD-h14LU=.884eb3e0-04e2-4728-bfc5-57b072e809bf@github.com>
 <cx6Me6MA3QwpLr2y2avGx3-we6Ej3UHQHRD10Km76HU=.bdf6dc1e-c9f3-4695-9687-4ed9d044741d@github.com>
 <WAwoF5K4yWv40dWrX1VjUfeVGYy918KDHp4qvuRQ5xM=.2aa20484-2def-46dc-b20f-4e866748e048@github.com>
 <1enXmdMITwK96Lz35sCWmkob9sLgKKt1N2Lp0NSldNc=.81d72c1e-0f11-452d-a55a-674f775fee47@github.com>
 <bmgatRS3iZ6J35-pwQQ81ev8-lMBeyFcN6jzQFk_qno=.369060d2-3e1f-45c9-bad6-71bbc921b647@github.com>
 <c-DwcGAX3JX-gnQ0CWuGzI09K5SCdQ_yxnBP-q9HT1o=.903a2615-8255-4bbf-aaa3-2e9fb0ae84f5@github.com>
 <o3KeCSV9VoJrmFKEsfKPCJ0cnuYbZZcjY18qYWSXZns=.fc08ab1b-d6f3-4158-8291-63e2663c2992@github.com>
 <PjRWrB0x0vcYcQoa6EK62usvbNr_AFa_IN2ljCLrDDI=.4d69297c-6996-4cb7-9bd6-50f961c43686@github.com>
Message-ID: <2E0F9OsixwTZ_Mq9OfUx1BQUStc92p0evM8KCbhz3jc=.18fd874c-f02a-406a-a8b7-c2cea0be8074@github.com>

On Mon, 26 Feb 2024 08:55:04 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> I assume you want to know if we use DAS/DAS1 for debugging purposes on that platform?
>
> I use `das` every day. In contrast, I don't know what `das1` is for.

It does not sound like anyone object to the removal of `JNIEXPORT` for `das1`, then.

Or should I just remove the entire function, if it serves no purpose that any current maintainers know or care about?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17967#discussion_r1503232370

From sviswanathan at openjdk.org  Mon Feb 26 21:28:44 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Mon, 26 Feb 2024 21:28:44 GMT
Subject: RFR: 8325991: Accelerate Poly1305 on x86_64 using AVX2
 instructions [v9]
In-Reply-To: <UjRcAmP61JeaSA1TNkF4Wqg-cN9QpJcpUzW0sh7kOic=.b2e4486f-9a15-49bb-865d-42f212b33475@github.com>
References: <IyoM1HY_rvNWwo4GxcV1yQleB3vrgaLwsAlOCEpLKqs=.1d50225c-8fe1-4a84-af56-274632b2b653@github.com>
 <UjRcAmP61JeaSA1TNkF4Wqg-cN9QpJcpUzW0sh7kOic=.b2e4486f-9a15-49bb-865d-42f212b33475@github.com>
Message-ID: <elh6KClRfYM83e0u48LBPJfu7GOsMZTLB1wg1ABDL7w=.935cf300-05ca-4be0-ac3c-f4b791b5638f@github.com>

On Fri, 23 Feb 2024 22:11:15 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> The goal of this PR is to accelerate the Poly1305 algorithm using AVX2 instructions (including IFMA) for x86_64 CPUs.
>> 
>> This implementation is directly based on the AVX2 Poly1305 hash computation as implemented in Intel(R) Multi-Buffer Crypto for IPsec Library (url: https://github.com/intel/intel-ipsec-mb/blob/main/lib/avx2_t3/poly_fma_avx2.asm)
>> 
>> This PR shows upto 19x speedup on buffer sizes of 1MB.
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add cpuinfo test for avx_ifma

Thanks, the PR looks good to me now.

-------------

Marked as reviewed by sviswanathan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17881#pullrequestreview-1902054936

From dlong at openjdk.org  Mon Feb 26 22:23:43 2024
From: dlong at openjdk.org (Dean Long)
Date: Mon, 26 Feb 2024 22:23:43 GMT
Subject: RFR: 8322962: Upcall stub might go undetected when freezing frames
 [v2]
In-Reply-To: <-bOmKAxXt_yXqWPh7hAANv06XjWhInYG_1attwwz8zs=.b541dae6-06aa-4130-91e2-53904676dbde@github.com>
References: <9wGivvL8XaePg4yOjShuasS2RZzyT2bzUi8EKWs95yQ=.36456962-47a7-4920-9a3a-a15936d4f480@github.com>
 <-bOmKAxXt_yXqWPh7hAANv06XjWhInYG_1attwwz8zs=.b541dae6-06aa-4130-91e2-53904676dbde@github.com>
Message-ID: <gtKIssMEQxry4r7k6KcUM-dPciUINslewOpdqovhHqk=.8f74c3b8-c5ba-4030-8669-fd31f23201f8@github.com>

On Mon, 26 Feb 2024 15:25:13 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Please review this simple fix. There is a missing push_cont_fastpath()/pop_cont_fastpath() around the call to Java in the upcall stub. Because of this, if from that upcall a virtual thread tries to yield, and all the other methods in the stack are compiled, we will incorrectly take the freeze fast path and freeze everything in the stack including the native frames. By forcing the slow path instead we will identify the upcall stub and pin the vthread.
>> 
>> The issue can be easily reproduced by running the modified version of test GetStackTraceALotWhenPinned.java included in this patch. I also tested the fix by running tiers1-3 in mach5. 
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve freeze fast path check

Looks good!

-------------

Marked as reviewed by dlong (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17964#pullrequestreview-1902159231

From sspitsyn at openjdk.org  Mon Feb 26 22:54:46 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 26 Feb 2024 22:54:46 GMT
Subject: RFR: 8324680: Replace NULL with nullptr in JVMTI generated code
In-Reply-To: <w1DMQMwGugoSs830xWYD6l7yoIR6v8dk5MnKYIY8t9w=.1ad08a17-8efc-4a71-88a5-78da29ce4ab4@github.com>
References: <w1DMQMwGugoSs830xWYD6l7yoIR6v8dk5MnKYIY8t9w=.1ad08a17-8efc-4a71-88a5-78da29ce4ab4@github.com>
Message-ID: <zKyiCari8N2UQeSZ47tDjudkWfmpHXeOgLzVug_CAqo=.adcc7547-bfe4-407e-ab67-3e8587dc4464@github.com>

On Thu, 15 Feb 2024 08:46:43 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This enhancement replaces uses of NULL with nullptr in the XML-description files for JVMTI. These are the files `hotsport/share/prims/jvmti.xml` and `hotspot/share/prims/jvmti*.xls`.
> 
> The following files are auto-generated from the `jvmti.xml` and `*.xsl files` in the `build/<CFG>/variant-server/gensrc/jvmtifiles': `jvmti.h`, `jvmti.html`, `jvmtiEnter.cpp`, `jvmtiEnterTrace.cpp`, `jvmtiEnv.hpp`
> 
> This addresses a category of NULL uses that wasn't dealt with by:
>  [JDK-8299837](https://bugs.openjdk.org/browse/JDK-8299837).
>  
>  Testing:
>    - TBD: run mach5 tiers1-3

Now, we this section:

Function Return Values

JVM TI functions always return an [error code](http://100.110.26.5:8080/view/loom/job/loom-fibers-branch-build/lastSuccessfulBuild/artifact/loom/build/linux-x64/images/docs/specs/jvmti.html#ErrorSection) via the [jvmtiError](http://100.110.26.5:8080/view/loom/job/loom-fibers-branch-build/lastSuccessfulBuild/artifact/loom/build/linux-x64/images/docs/specs/jvmti.html#jvmtiError) function return value. Some functions can return additional values through pointers provided by the calling function. In some cases, JVM TI functions allocate memory that your program must explicitly deallocate. This is indicated in the individual JVM TI function descriptions. Empty lists, arrays, sequences, etc are returned as `nullptr`.
In the event that the JVM TI function encounters an error (any return value other than `JVMTI_ERROR_NONE`) the values of memory referenced by argument pointers is undefined, but no memory will have been allocated and no global references will have been allocated. If the error occurs because of invalid input, no action will have occurred.

The `nullptr` is mentioned here. As I understand from the Alan's and David's comments above we want to clarify what does it mean for C/C++ code.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17866#issuecomment-1965473360

From sspitsyn at openjdk.org  Mon Feb 26 23:05:47 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 26 Feb 2024 23:05:47 GMT
Subject: RFR: 8324680: Replace NULL with nullptr in JVMTI generated code
In-Reply-To: <w1DMQMwGugoSs830xWYD6l7yoIR6v8dk5MnKYIY8t9w=.1ad08a17-8efc-4a71-88a5-78da29ce4ab4@github.com>
References: <w1DMQMwGugoSs830xWYD6l7yoIR6v8dk5MnKYIY8t9w=.1ad08a17-8efc-4a71-88a5-78da29ce4ab4@github.com>
Message-ID: <MwkDpkRzs2ChWoSnObtM9U5F9hnIUP7XntSdjRR0uU0=.7beb1533-7884-4d82-9909-157281bd80ad@github.com>

On Thu, 15 Feb 2024 08:46:43 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This enhancement replaces uses of NULL with nullptr in the XML-description files for JVMTI. These are the files `hotsport/share/prims/jvmti.xml` and `hotspot/share/prims/jvmti*.xls`.
> 
> The following files are auto-generated from the `jvmti.xml` and `*.xsl files` in the `build/<CFG>/variant-server/gensrc/jvmtifiles': `jvmti.h`, `jvmti.html`, `jvmtiEnter.cpp`, `jvmtiEnterTrace.cpp`, `jvmtiEnv.hpp`
> 
> This addresses a category of NULL uses that wasn't dealt with by:
>  [JDK-8299837](https://bugs.openjdk.org/browse/JDK-8299837).
>  
>  Testing:
>    - TBD: run mach5 tiers1-3

Filed new Enhancement:
[8326716](https://bugs.openjdk.org/browse/JDK-8326716): JVMTI spec: clarify what nullptr means for C/C++ developers

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17866#issuecomment-1965485369

From amenkov at openjdk.org  Mon Feb 26 23:21:52 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Mon, 26 Feb 2024 23:21:52 GMT
Subject: Integrated: JDK-8325530: Vague error message when
 com.sun.tools.attach.VirtualMachine fails to load agent library
In-Reply-To: <s1rZKr_Bt8tzCP2cMyFv0oe7pTD1DNzGLaIsGZdXffY=.596d50f2-12b6-4bba-ab30-a26b697fb970@github.com>
References: <s1rZKr_Bt8tzCP2cMyFv0oe7pTD1DNzGLaIsGZdXffY=.596d50f2-12b6-4bba-ab30-a26b697fb970@github.com>
Message-ID: <W3h1viTuWRDw2nClPmEMSg021JfZSvtOK9-cpBUGgWA=.a6a08e7b-ca1e-45ad-b258-1a6a360c17f0@github.com>

On Wed, 21 Feb 2024 21:13:36 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> VirtualMachine.loadAgentPath/loadAgentLibrary can fail with AgentLoadException in 2 cases:
> - attach listener returns error; in the case the exception is thrown from HotSpotVirtualMachine.processCompletionStatus (called from HotSpotVirtualMachine.execute);
> - attach listener returns success, but reply does not contain Agent_onAttach return code ("return code: %d" message).
> 
> before jdk21 if attach listener fails to load required library, it returned error (case 1)
> from jdk21 attach listener always returns success (case 2)
> Both cases are ok, but for 2nd case HotSpotVirtualMachine.loadAgentLibrary read only single line of the response message, so exception message didn't contain error details.
> 
> The fix updates HotSpotVirtualMachine.loadAgentLibrary to read the whole response message.
> Walking through the code, fixed some other minor things in attach listener and attach API implementation (commented in the code)
> 
> Testing:
>   - test/jdk/com/sun/tools;
>   - tier1,tier2,tier5-svc

This pull request has now been integrated.

Changeset: fc67c2b4
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fc67c2b4f17216d4adcc0825d0f378ae4f150025
Stats:     150 lines in 6 files changed: 109 ins; 16 del; 25 mod

8325530: Vague error message when com.sun.tools.attach.VirtualMachine fails to load agent library

Reviewed-by: sspitsyn, cjplummer

-------------

PR: https://git.openjdk.org/jdk/pull/17954

From pchilanomate at openjdk.org  Mon Feb 26 23:28:44 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 26 Feb 2024 23:28:44 GMT
Subject: RFR: 8322962: Upcall stub might go undetected when freezing frames
 [v2]
In-Reply-To: <gtKIssMEQxry4r7k6KcUM-dPciUINslewOpdqovhHqk=.8f74c3b8-c5ba-4030-8669-fd31f23201f8@github.com>
References: <9wGivvL8XaePg4yOjShuasS2RZzyT2bzUi8EKWs95yQ=.36456962-47a7-4920-9a3a-a15936d4f480@github.com>
 <-bOmKAxXt_yXqWPh7hAANv06XjWhInYG_1attwwz8zs=.b541dae6-06aa-4130-91e2-53904676dbde@github.com>
 <gtKIssMEQxry4r7k6KcUM-dPciUINslewOpdqovhHqk=.8f74c3b8-c5ba-4030-8669-fd31f23201f8@github.com>
Message-ID: <MdtUv5Z_MVcgPI7qBLFYaJarhABrF9HCAtvgvV4Rzi8=.42bed8e5-44d9-4b3a-860b-a944570f83ec@github.com>

On Mon, 26 Feb 2024 22:21:26 GMT, Dean Long <dlong at openjdk.org> wrote:

> Looks good!
>
Thanks for the review Dean!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17964#issuecomment-1965509772

From pchilanomate at openjdk.org  Mon Feb 26 23:31:47 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 26 Feb 2024 23:31:47 GMT
Subject: Integrated: 8322962: Upcall stub might go undetected when freezing
 frames
In-Reply-To: <9wGivvL8XaePg4yOjShuasS2RZzyT2bzUi8EKWs95yQ=.36456962-47a7-4920-9a3a-a15936d4f480@github.com>
References: <9wGivvL8XaePg4yOjShuasS2RZzyT2bzUi8EKWs95yQ=.36456962-47a7-4920-9a3a-a15936d4f480@github.com>
Message-ID: <9R5DpcNRsXL87Kj1F1z2kjNaRP4qFmu1JOYp4F0mrNU=.0961f2f2-ac25-445c-be7d-866584ac04b5@github.com>

On Thu, 22 Feb 2024 14:28:18 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review this simple fix. There is a missing push_cont_fastpath()/pop_cont_fastpath() around the call to Java in the upcall stub. Because of this, if from that upcall a virtual thread tries to yield, and all the other methods in the stack are compiled, we will incorrectly take the freeze fast path and freeze everything in the stack including the native frames. By forcing the slow path instead we will identify the upcall stub and pin the vthread.
> 
> The issue can be easily reproduced by running the modified version of test GetStackTraceALotWhenPinned.java included in this patch. I also tested the fix by running tiers1-3 in mach5. 
> 
> Thanks,
> Patricio

This pull request has now been integrated.

Changeset: 93feda3d
Author:    Patricio Chilano Mateo <pchilanomate at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/93feda3d9a1807422c7f47703358aabd2e8639b8
Stats:     34 lines in 6 files changed: 21 ins; 4 del; 9 mod

8322962: Upcall stub might go undetected when freezing frames

Reviewed-by: jvernee, alanb, mdoerr, fyang, dlong

-------------

PR: https://git.openjdk.org/jdk/pull/17964

From a.popov.tmb at gmail.com  Mon Feb 26 23:49:55 2024
From: a.popov.tmb at gmail.com (Aleksandr Popov)
Date: Tue, 27 Feb 2024 00:49:55 +0100
Subject: Resolving super interface in different contexts depending on the
 child class
In-Reply-To: <6eb83154-ba8f-4d7e-8ef1-cedbdaa14cf6@oracle.com>
References: <CAGzTNj5WxZbx0AeAkTeDpXNm83kn0_DX4d9bZ4CPDgvuJ17pZA@mail.gmail.com>
 <6eb83154-ba8f-4d7e-8ef1-cedbdaa14cf6@oracle.com>
Message-ID: <CAGzTNj4pp70pxJnAQ_Xyo+gFHzgQA7T-j0VDiqvuWCUASGnN7g@mail.gmail.com>

Vladimir, thank you for clarifying this.

One more question here: should we add loader constraints to the Delayed
class when it is loaded into the boot class loader, while the
ScheduledFutureTask implementor is loaded into the application one?

Or do we need to rely on the fact that Delayed should also be loaded into
the application loader by some specific condition?

??, 24 ????. 2024??. ? 03:01, Vladimir Ivanov <vladimir.x.ivanov at oracle.com
>:

> Hi Aleksandr,
>
> I'd like to clarify the terminology: JVMS distinguishes initiating and
> defining loaders for a class (JVMS-5.3 [1]).
>
> The effects you are looking at are specific to initiating loaders.
>
> Even though a class is loaded only once (when well-behaved loaders are
> involved), it becomes visible in all descendant loaders on case-by-case
> basis. Each loader should initiate the loading to resolve the class in
> its context. (On implementation level it triggers the update of class
> loader dictionary.)
>
> Classes are loaded on-demand and precise conditions when it happens in
> practice may be far from evident. As an example, I played with the
> sketch you provided and here are my observations (when
> ScheduledFutureTask implements ScheduledFuture):
>
>
>   * for the following code shape, bytecode verifier triggers class
> loading of Delayed class as part of invokevirtual verification (it needs
> to prove ScheduledFutureTask <: Delayed):
>
>        public static int compare(ScheduledFutureTask o1,
>   ScheduledFutureTask o2) {
>            return o1.compareTo(o2);
>        }
>
>
>   * if compare is adjusted as follows, then checkcast instruction
> triggers class loading for non-null object during execution:
>
>      public static int compare(ScheduledFutureTask o1, Object o2) {
>          return o1.compareTo((Delayed)o2);
>      }
>
> You mentioned that Delayed interface is not loaded by application loader
> in the first case, but I wasn't able to reproduce it based on your
> description. Please, share more details.
>
>
> Personally, I was able to avoid class loading (and trigger
> has_unloaded_classes_in_signature() == false for compareTo(Delayed))
> either by turning off verification (-Xverify:none) or always passing
> null as o2 [2]:
>
>      public static void main(String[] args) {
>          ScheduledFutureTask instances0 = new ScheduledFutureTask();
>          for (int i = 0; i < 20_000; i++) {
>              compare(instances0, null);
>          }
>      }
>
> The issue with null argument is known (inlining failures due to unloaded
> class in method signature when corresponding values are always null).
> JDK-8294609 [3] improved the situation for most of scenarios, but
> covering nulls require more work. It may be improved in the future release.
>
> Best regards,
> Vladimir Ivanov
>
> [1]
> https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-5.html#jvms-5.3
>
> [2] https://gist.github.com/iwanowww/c33e49092bfa0e6a052f28ae139b55eb
>
> [3] https://bugs.openjdk.org/browse/JDK-8294609
>
> On 2/23/24 08:32, Aleksandr Popov wrote:
> > Hi! In the following test case I've investigated how Hotspot loads
> > classes into the loaders.
> > And found out that the inheritance chain could affect the result.
> >
> >
> //--------------------------------------------------------------------------
> > public class SimpleTest {
> >      public static int compare(ScheduledFutureTask o1,
> > ScheduledFutureTask o2) {
> >          return o1.compareTo(o2);
> >      }
> >
> >      public static void main(String[] args) {
> >          ScheduledFutureTask instances0 = new ScheduledFutureTask();
> >          ScheduledFutureTask instances1 = new ScheduledFutureTask();
> >          compare(instances0, instances1);
> >      }
> > }
> >
> > final class ScheduledFutureTask implements ScheduledFuture<Void> {
> > ...
> >      @Override
> >      public int compareTo(Delayed o) {
> >          if (this == o) {
> >              return 0;
> >          }
> >      }
> > }
> >
> //--------------------------------------------------------------------------
> >
> >   * If /ScheduledFutureTask/ class implements
> >     /java.util.concurrent.ScheduledFuture /interface,
> >
> > which implements /java.util.concurrent.Delayed/ interface: *[application
> > class -> core class -> core class],*
> > then the /Delayed /interface would be loaded into the boot class loader,
> > since it's resolved in the context of the core class.
> >
> > I've added some logs to track class resolving:
> > # parse interfaces of class ScheduledFutureTask, [APP] loader
> > # parse interfaces of class java/util/concurrent/ScheduledFuture, [BOOT]
> > loader
> > # parse interfaces of class java/util/concurrent/Delayed, [BOOT] loader
> > # Adding java/util/concurrent/Delayed to dictionary [BOOT]
> >
> >   * If we replace core class in the chain with an application one:
> >     *[application class -> application class -> core class], *
> >
> > then the /Delayed /interface would be loaded into both class loaders,
> > since it would be resolved in the context of the application class:
> >
> > # parse interfaces of class ScheduledFutureTask, [application class
> loader]
> > # parse interfaces of class Interface1, [application class loader]
> > # parse interfaces of class java/util/concurrent/Delayed, [boot class
> > loader]
> > # Adding java/util/concurrent/Delayed to dictionary [boot class loader]
> > # Adding java/util/concurrent/Delayed to dictionary [application class
> > loader]
> >
> >   * Theoretically, this difference could affect the result of the
> >     has_unloaded_classes_in_signature() call
> >
> > for the ScheduledFutureTask::compareTo method.
> >
> > final class ScheduledFutureTask implements ScheduledFuture<Void> {
> > ...
> >      @Override
> >      public int compareTo(Delayed o) {
> >          if (this == o) {
> >              return 0;
> >          }
> >      }
> > }
> >
> > Because in the first case (application class -> core class -> core
> > class) we have unloaded /java/util/concurrent/Delayed/
> > interface in the context of the accessing class, which was loaded into
> > the application class loader.
> >
> > So my question is: why is it correct to have class loaded into different
> > class loaders depending on the inheritance chain?
> > Or maybe it's intentionally resolved somewhere in the code?
> >
> > Note that SystemDictionary::check_signature_loaders doesn't add loader
> > constraints to the interface, since the caller and callee loaders are
> > the same in this case: both application loaders.
> >
> > Thank you!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20240227/4fa3c5d1/attachment-0001.htm>

From fyang at openjdk.org  Tue Feb 27 03:39:46 2024
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 27 Feb 2024 03:39:46 GMT
Subject: RFR: 8322179: RISC-V: Implement SHA-1 intrinsic [v14]
In-Reply-To: <qOXJYauKdggsWmevBILNLDlWaL0rqQlXxlvbDRr9Sko=.cd488d1d-6ad8-4f19-8ad8-6ab4292638ce@github.com>
References: <PyIXzENfiHysFS3IyZn3FDNQpV7Ua2L6OmjiXq9wRoU=.cf74a45e-c94b-4f7b-8768-d10d55e2ce1d@github.com>
 <qOXJYauKdggsWmevBILNLDlWaL0rqQlXxlvbDRr9Sko=.cd488d1d-6ad8-4f19-8ad8-6ab4292638ce@github.com>
Message-ID: <dyUKgtGbL86VKCFBG88xOXgZLmkhs2lWcEb7dR7LBbo=.6fe5d469-b261-49ae-8bd4-15f4b2ac4d62@github.com>

On Mon, 26 Feb 2024 10:32:10 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you review this patch to implement SHA-1 intrinsic for riscv?
>> Thanks!
>> 
>> 
>> ## Test
>> 
>> ### Functionality
>> 
>> tests under `test/hotspot/jtreg/compiler/intrinsics/sha`
>> tests found via `find test/jdk -iname "*SHA1*.java"`
>> 
>> ### Performance
>> 
>> tested on `T-HEAD Light Lichee Pi 4A`
>> 
>> JMH_PARAMS="-f 1 -wi 10 -i 20" // for every loop of jmh test
>> 
>> benchmark tests `MessageDigests.java GetMessageDigest.java MessageDigestBench.java MacBench.java` which are under `test/micro/org/openjdk/bench/`, more spcifically `TESTS="MessageDigests.digest MessageDigests.getAndDigest MessageDigestBench.digest"`
>> 
>> 
>> // After
>> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1        64     DEFAULT  avgt   20      1845.446 ?     27.052  ns/op
>> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    181455.350 ?    532.258  ns/op
>> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2447.674 ?     10.239  ns/op
>> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    182896.083 ?   1242.774  ns/op
>> o.o.b.javax.crypto.small.MessageDigestBench.digest         SHA1     1048576             N/A       N/A              avgt   20  11599227.792 ? 121442.390  ns/op
>> // Before
>> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2352.475 ?    11.198  ns/op
>> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    188495.684 ?  1467.942  ns/op
>> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2437.347 ?     6.398  ns/op
>> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    196086.570 ?  1140.998  ns/op
>> o.o.b.javax.crypto.small.MessageDigestBench.digest         SHA1     1048576             N/A       N/A              avgt   20  12362160.119 ? 38788.109  ns/op
>> 
>> 
>> **getAndDigest when size == 64**
>> The data is not stable for test getAndDigest when size == 64, which I think is introduced by  j.s.MessageDigest.getInstance itself, which we don't touch in this patch.
>> Check more details at [1](ht...
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   refine code

Looks good. Are there any changes on the performance numbers for the latest version? Thanks.

-------------

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17130#pullrequestreview-1902454605

From vladimir.x.ivanov at oracle.com  Tue Feb 27 03:54:42 2024
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Mon, 26 Feb 2024 19:54:42 -0800
Subject: Resolving super interface in different contexts depending on the
 child class
In-Reply-To: <CAGzTNj4pp70pxJnAQ_Xyo+gFHzgQA7T-j0VDiqvuWCUASGnN7g@mail.gmail.com>
References: <CAGzTNj5WxZbx0AeAkTeDpXNm83kn0_DX4d9bZ4CPDgvuJ17pZA@mail.gmail.com>
 <6eb83154-ba8f-4d7e-8ef1-cedbdaa14cf6@oracle.com>
 <CAGzTNj4pp70pxJnAQ_Xyo+gFHzgQA7T-j0VDiqvuWCUASGnN7g@mail.gmail.com>
Message-ID: <87358cf1-b6b0-41ba-a667-98e453d3c1b9@oracle.com>



> One more question here: should we add loader constraints to the Delayed
> class when it is loaded into the boot class loader, while the
> ScheduledFutureTask implementor is loaded into the application one?

There are no loader constraints needed in your particular case because 
SimpleTest.compare() and ScheduledFutureTask.compareTo(Delayed) are 
loaded by the very same class loader.

When caller and callee belong to different loaders, then all classes 
mentioned in their signature are subject to loader constraints between 
their loaders. JVMS-5.4.3 [1] has more details on the topic.

> Or do we need to rely on the fact that Delayed should also be loaded into
> the application loader by some specific condition?

There was a discussion on hotspot-compiler-dev at ojn mailing list some 
time ago about similar problem discovered in JRuby [2].

There are multiple subtle scenarios when class loading may be initiated 
(e.g., JIT-compilation initiates loading of all signature classes in the 
root method).

But, as it works now, the only reliable way to avoid inlining problems 
caused by not-yet-loaded signature classes in performance-critical code 
is to eagerly load them (for example, in class initializer).

Best regards,
Vladimir Ivanov

[1] 
https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-5.html#jvms-5.3.4

[2] 
https://mail.openjdk.org/pipermail/hotspot-compiler-dev/2020-September/039836.html

> 
> ??, 24 ????. 2024??. ? 03:01, Vladimir Ivanov 
> <vladimir.x.ivanov at oracle.com <mailto:vladimir.x.ivanov at oracle.com>>:
> 
>     Hi Aleksandr,
> 
>     I'd like to clarify the terminology: JVMS distinguishes initiating and
>     defining loaders for a class (JVMS-5.3 [1]).
> 
>     The effects you are looking at are specific to initiating loaders.
> 
>     Even though a class is loaded only once (when well-behaved loaders are
>     involved), it becomes visible in all descendant loaders on case-by-case
>     basis. Each loader should initiate the loading to resolve the class in
>     its context. (On implementation level it triggers the update of class
>     loader dictionary.)
> 
>     Classes are loaded on-demand and precise conditions when it happens in
>     practice may be far from evident. As an example, I played with the
>     sketch you provided and here are my observations (when
>     ScheduledFutureTask implements ScheduledFuture):
> 
> 
>      ? * for the following code shape, bytecode verifier triggers class
>     loading of Delayed class as part of invokevirtual verification (it
>     needs
>     to prove ScheduledFutureTask <: Delayed):
> 
>      ? ? ? ?public static int compare(ScheduledFutureTask o1,
>      ? ScheduledFutureTask o2) {
>      ? ? ? ? ? ?return o1.compareTo(o2);
>      ? ? ? ?}
> 
> 
>      ? * if compare is adjusted as follows, then checkcast instruction
>     triggers class loading for non-null object during execution:
> 
>      ? ? ?public static int compare(ScheduledFutureTask o1, Object o2) {
>      ? ? ? ? ?return o1.compareTo((Delayed)o2);
>      ? ? ?}
> 
>     You mentioned that Delayed interface is not loaded by application
>     loader
>     in the first case, but I wasn't able to reproduce it based on your
>     description. Please, share more details.
> 
> 
>     Personally, I was able to avoid class loading (and trigger
>     has_unloaded_classes_in_signature() == false for compareTo(Delayed))
>     either by turning off verification (-Xverify:none) or always passing
>     null as o2 [2]:
> 
>      ? ? ?public static void main(String[] args) {
>      ? ? ? ? ?ScheduledFutureTask instances0 = new ScheduledFutureTask();
>      ? ? ? ? ?for (int i = 0; i < 20_000; i++) {
>      ? ? ? ? ? ? ?compare(instances0, null);
>      ? ? ? ? ?}
>      ? ? ?}
> 
>     The issue with null argument is known (inlining failures due to
>     unloaded
>     class in method signature when corresponding values are always null).
>     JDK-8294609 [3] improved the situation for most of scenarios, but
>     covering nulls require more work. It may be improved in the future
>     release.
> 
>     Best regards,
>     Vladimir Ivanov
> 
>     [1]
>     https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-5.html#jvms-5.3 <https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-5.html#jvms-5.3>
> 
>     [2]
>     https://gist.github.com/iwanowww/c33e49092bfa0e6a052f28ae139b55eb
>     <https://urldefense.com/v3/__https://gist.github.com/iwanowww/c33e49092bfa0e6a052f28ae139b55eb__;!!ACWV5N9M2RV99hQ!JV9ZHd2pS1ntk1CM5Bdt4L7JU3zmTFW6NJJ2AN1GrxpreRDXRMIxojeDyRV9-pcnFRqHPEO1xQxiVIR37AQ4S1QvlA0$>
> 
>     [3] https://bugs.openjdk.org/browse/JDK-8294609
>     <https://bugs.openjdk.org/browse/JDK-8294609>
> 
>     On 2/23/24 08:32, Aleksandr Popov wrote:
>      > Hi! In the following test case I've investigated how Hotspot loads
>      > classes into the loaders.
>      > And found out that the inheritance chain could affect the result.
>      >
>      >
>     //--------------------------------------------------------------------------
>      > public class SimpleTest {
>      >? ? ? public static int compare(ScheduledFutureTask o1,
>      > ScheduledFutureTask o2) {
>      >? ? ? ? ? return o1.compareTo(o2);
>      >? ? ? }
>      >
>      >? ? ? public static void main(String[] args) {
>      >? ? ? ? ? ScheduledFutureTask instances0 = new ScheduledFutureTask();
>      >? ? ? ? ? ScheduledFutureTask instances1 = new ScheduledFutureTask();
>      >? ? ? ? ? compare(instances0, instances1);
>      >? ? ? }
>      > }
>      >
>      > final class ScheduledFutureTask implements ScheduledFuture<Void> {
>      > ...
>      >? ? ? @Override
>      >? ? ? public int compareTo(Delayed o) {
>      >? ? ? ? ? if (this == o) {
>      >? ? ? ? ? ? ? return 0;
>      >? ? ? ? ? }
>      >? ? ? }
>      > }
>      >
>     //--------------------------------------------------------------------------
>      >
>      >? ?* If /ScheduledFutureTask/?class implements
>      >? ? ?/java.util.concurrent.ScheduledFuture /interface,
>      >
>      > which implements /java.util.concurrent.Delayed/?interface:
>     *[application
>      > class -> core class -> core class],*
>      > then the /Delayed /interface would be loaded into the boot class
>     loader,
>      > since it's resolved in the context of the core class.
>      >
>      > I've added some logs to track class resolving:
>      > # parse interfaces of class ScheduledFutureTask, [APP] loader
>      > # parse interfaces of class java/util/concurrent/ScheduledFuture,
>     [BOOT]
>      > loader
>      > # parse interfaces of class java/util/concurrent/Delayed, [BOOT]
>     loader
>      > # Adding java/util/concurrent/Delayed to dictionary [BOOT]
>      >
>      >? ?* If we replace core class in the chain with an application one:
>      >? ? ?*[application class -> application class -> core class], *
>      >
>      > then the /Delayed /interface would be loaded into both class
>     loaders,
>      > since it would be resolved in the context of the application class:
>      >
>      > # parse interfaces of class ScheduledFutureTask, [application
>     class loader]
>      > # parse interfaces of class Interface1, [application class loader]
>      > # parse interfaces of class java/util/concurrent/Delayed, [boot
>     class
>      > loader]
>      > # Adding java/util/concurrent/Delayed to dictionary [boot class
>     loader]
>      > # Adding java/util/concurrent/Delayed to dictionary [application
>     class
>      > loader]
>      >
>      >? ?* Theoretically, this difference could affect the result of the
>      >? ? ?has_unloaded_classes_in_signature() call
>      >
>      > for the ScheduledFutureTask::compareTo method.
>      >
>      > final class ScheduledFutureTask implements ScheduledFuture<Void> {
>      > ...
>      >? ? ? @Override
>      >? ? ? public int compareTo(Delayed o) {
>      >? ? ? ? ? if (this == o) {
>      >? ? ? ? ? ? ? return 0;
>      >? ? ? ? ? }
>      >? ? ? }
>      > }
>      >
>      > Because in the first case (application class -> core class -> core
>      > class) we have unloaded /java/util/concurrent/Delayed/
>      > interface in the context of the accessing class, which was loaded
>     into
>      > the application class loader.
>      >
>      > So my question is: why is it correct to have class loaded into
>     different
>      > class loaders depending on the inheritance chain?
>      > Or maybe it's intentionally resolved somewhere in the code?
>      >
>      > Note that SystemDictionary::check_signature_loaders doesn't add
>     loader
>      > constraints to the interface, since the caller and callee loaders
>     are
>      > the same in this case: both application loaders.
>      >
>      > Thank you!
> 

From dholmes at openjdk.org  Tue Feb 27 05:31:51 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 27 Feb 2024 05:31:51 GMT
Subject: RFR: 8017234: Hotspot should stop using mapfiles [v8]
In-Reply-To: <_Gdp3pxakc2Q0rYlCnz0TK0o1WbSkM2CX_pKfd_QRsU=.d7129f84-2241-496b-9764-72aa4fc3b3cf@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
 <_Gdp3pxakc2Q0rYlCnz0TK0o1WbSkM2CX_pKfd_QRsU=.d7129f84-2241-496b-9764-72aa4fc3b3cf@github.com>
Message-ID: <fzFOimK2m4KMD9Q_8-x-WjdC1OjV5rwl7_Zt0MSLST4=.14e7e333-9c87-4d99-b9d1-df844e48d9b9@github.com>

On Mon, 26 Feb 2024 17:34:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
>> 
>> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
>> 
>> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
>> 
>> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use --exclude-libs and -version-script on linux/clang too

Given discussions and additional testing/validation, the hotspot changes appear okay. Thanks.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17955#pullrequestreview-1902551792

From stuefe at openjdk.org  Tue Feb 27 05:50:42 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 27 Feb 2024 05:50:42 GMT
Subject: RFR: 8324849: Uniform use of synchronizations in NMT
In-Reply-To: <RKu9s5Zp_4Kw8Fr7MzvXq6uW3Z78tPwqK4b9OwKBP6g=.f70a1dd9-4b89-4774-8153-c251334078dc@github.com>
References: <uikMP7BCa6Wro3F63W7C4qQZNMgDSjSYXzHEGCroSDA=.aef515a7-6352-41d5-8aa5-ac0c94e5886d@github.com>
 <EnnPhb1SV_E-FGrfqOyVmB3cFc7RUSpP3ax2ahxUgAs=.4bcacc1c-d15d-4bf9-8ec7-ac941c8dad88@github.com>
 <LuCDQJNok_GmZYSW5yjxl68cm1OCECnW4W_q7qlQ6Mc=.136c9a63-ed50-42ff-8dfd-f105a11b846d@github.com>
 <RKu9s5Zp_4Kw8Fr7MzvXq6uW3Z78tPwqK4b9OwKBP6g=.f70a1dd9-4b89-4774-8153-c251334078dc@github.com>
Message-ID: <5N3FuDaxf-vkusguUwcezaHOCNz8IbIiheFwybUw77E=.1d610b13-a0aa-47d8-9fda-44091c9d7a6f@github.com>

On Mon, 26 Feb 2024 19:30:08 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> > > @afshin-zafari  Please, set correct RFE id number!!!!  See "Integration blockers" and "Issue".
> > 
> > 
> > ow. But Skara bot did not catch this? How strange.
> 
> It catch - It will not allow you to integrate until you resolve "Integration blockers".
> 
> Yes, it would be better if Skara does not allow to create such PR but I am not sure Skara does these checks at that time.

Ah, okay. It would be cool for jcheck to pick this up and show an error in GHAs though. That way you notice it immediately.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18000#issuecomment-1965833666

From dholmes at openjdk.org  Tue Feb 27 05:55:55 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 27 Feb 2024 05:55:55 GMT
Subject: RFR: 8318302: ThreadCountLimit.java failed with
 "Native memory allocation (mprotect) failed to protect 16384 bytes for memory
 to guard stack pages" [v2]
In-Reply-To: <owqAt1_7CSCVlCen_Lp7b3q1jMSjsU-D2SKq5ciBDgo=.1ec82f53-23b1-477d-887c-280b3721a505@github.com>
References: <owqAt1_7CSCVlCen_Lp7b3q1jMSjsU-D2SKq5ciBDgo=.1ec82f53-23b1-477d-887c-280b3721a505@github.com>
Message-ID: <qgTWiu6o5t_MKTwceAc6JkY9l3CRB5yLz89fn3msUBU=.5a2f7a36-7111-471b-b4dd-dae91af7874a@github.com>

> The test tries to create as many threads as possible in 5 seconds, with the intention of hitting platform limits on the maximum number of threads that can be created, so that we see that the VM reacts in a reasonable way. However on Linux, if the thread creation limit is high enough, and things run fast enough, then we can instead hit a fatal error when a mmap/mprotect returns E_NOMEM because the maximum number of memory mappings (default 65530) has been exceeded.
> 
> The fix to the test (courtesy @stefank ) is to re-exec the test on Linux with `ulimit -u` set to a much smaller value than the default (I chose 4096 as it still showed over 2000 threads were created before failure). This means we are unlikely to hit the default memory mapping limit before we hit the max threads limit.
> 
> I also updated the VM's OOM error message to include exceeding the maximum number of memory mappings as a possible cause (with a hint as to what to look for in the hs_err log).
> 
> Testing:
>  - ran the test 10x on all platforms in our CI (plus local testing)
> 
> Thanks

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Invert logic to avoid negation.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17959/files
  - new: https://git.openjdk.org/jdk/pull/17959/files/b0ebf923..263c7c41

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17959&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17959&range=00-01

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/17959.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17959/head:pull/17959

PR: https://git.openjdk.org/jdk/pull/17959

From dholmes at openjdk.org  Tue Feb 27 05:55:55 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 27 Feb 2024 05:55:55 GMT
Subject: RFR: 8318302: ThreadCountLimit.java failed with
 "Native memory allocation (mprotect) failed to protect 16384 bytes for memory
 to guard stack pages"
In-Reply-To: <98Z3mMnDM6NuPlwduJ0MN9KnlP7NYdIxqXikHZE5JuE=.973a703f-9bf0-437f-93ab-ac01f385b824@github.com>
References: <owqAt1_7CSCVlCen_Lp7b3q1jMSjsU-D2SKq5ciBDgo=.1ec82f53-23b1-477d-887c-280b3721a505@github.com>
 <98Z3mMnDM6NuPlwduJ0MN9KnlP7NYdIxqXikHZE5JuE=.973a703f-9bf0-437f-93ab-ac01f385b824@github.com>
Message-ID: <s_KJsEiErJnq8KvCt7gbCj1fQuHNtMv0_3mtCHyPKXc=.5c221aef-7c7f-4330-bade-1a551a04d955@github.com>

On Thu, 22 Feb 2024 09:16:56 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Maybe deserves a little synopsis change: "8318302: ThreadCountLimit.java failed due to too many memory mappings"

I don't object to people renaming issues to reflect the actual cause of a bug but I also don't advocate it. I spend (too much) time mapping failures to bug reports and it is much easier when the bug title reflect the failure mode rather than the bug cause. So I will keep it as is thanks.

@shipilev , @stefank  thank you for the reviews, and apologies for the delay in getting back to this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17959#issuecomment-1965835439
PR Comment: https://git.openjdk.org/jdk/pull/17959#issuecomment-1965835935

From dholmes at openjdk.org  Tue Feb 27 05:55:55 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 27 Feb 2024 05:55:55 GMT
Subject: RFR: 8318302: ThreadCountLimit.java failed with
 "Native memory allocation (mprotect) failed to protect 16384 bytes for memory
 to guard stack pages" [v2]
In-Reply-To: <98Z3mMnDM6NuPlwduJ0MN9KnlP7NYdIxqXikHZE5JuE=.973a703f-9bf0-437f-93ab-ac01f385b824@github.com>
References: <owqAt1_7CSCVlCen_Lp7b3q1jMSjsU-D2SKq5ciBDgo=.1ec82f53-23b1-477d-887c-280b3721a505@github.com>
 <98Z3mMnDM6NuPlwduJ0MN9KnlP7NYdIxqXikHZE5JuE=.973a703f-9bf0-437f-93ab-ac01f385b824@github.com>
Message-ID: <y4RA6MrErd1aCVtlP_NlK6kON1W_JV1IEMvwzda_2NI=.983f0fb2-a699-4266-940d-35859697f4e4@github.com>

On Thu, 22 Feb 2024 09:13:19 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Invert logic to avoid negation.
>
> test/hotspot/jtreg/runtime/Thread/ThreadCountLimit.java line 82:
> 
>> 80:         String java_cmd = ProcessTools.getCommandLine(pb);
>> 81:         // Relaunch the test with args.length > 0, and the ulimit set
>> 82:         ProcessTools.executeCommand("bash", "-c", ULIMIT_CMD + " && " + java_cmd + " dummy")
> 
> I think this assumes `bash` is installed, which is true 99% of the time, but not actually guaranteed. Maybe we should check `if (Platform.isLinux() && new File("/bin/bash").exists())` explicitly.

Doesn't that presume to know where bash is installed? And if it isn't found then should we skip the test due to the risk of failure?

> test/hotspot/jtreg/runtime/Thread/ThreadCountLimit.java line 142:
> 
>> 140:     // Now that all threads have joined, we are away from dangerous
>> 141:     // VM state and have enough memory to perform any other things.
>> 142:     if (!reachedNativeOOM) {
> 
> Cleanup: flip this around to avoid negation in `!reachedNativeOOM`.

Okay. It was an arbitrary choice as to which flag I kept.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17959#discussion_r1503670957
PR Review Comment: https://git.openjdk.org/jdk/pull/17959#discussion_r1503670249

From stuefe at openjdk.org  Tue Feb 27 06:01:51 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 27 Feb 2024 06:01:51 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v26]
In-Reply-To: <rzJcK8ej_SBTvT0ch_dy8b0DYLRKhBdas5HEI4TzHJ4=.d3a710bc-d754-418e-b9c6-114d5a66757b@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <rzJcK8ej_SBTvT0ch_dy8b0DYLRKhBdas5HEI4TzHJ4=.d3a710bc-d754-418e-b9c6-114d5a66757b@github.com>
Message-ID: <8tlU2NkIBMWNzit84PSd8Oo8QsiD92EKw5auHY0nkro=.0ecc1cd5-d98a-4239-afd8-6163f785bc38@github.com>

On Mon, 26 Feb 2024 11:24:13 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am.
>> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX.
>> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails.
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>    Address review comments

Okay

-------------

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16604#pullrequestreview-1902581556

From stuefe at openjdk.org  Tue Feb 27 06:07:43 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 27 Feb 2024 06:07:43 GMT
Subject: RFR: 8318302: ThreadCountLimit.java failed with
 "Native memory allocation (mprotect) failed to protect 16384 bytes for memory
 to guard stack pages" [v2]
In-Reply-To: <qgTWiu6o5t_MKTwceAc6JkY9l3CRB5yLz89fn3msUBU=.5a2f7a36-7111-471b-b4dd-dae91af7874a@github.com>
References: <owqAt1_7CSCVlCen_Lp7b3q1jMSjsU-D2SKq5ciBDgo=.1ec82f53-23b1-477d-887c-280b3721a505@github.com>
 <qgTWiu6o5t_MKTwceAc6JkY9l3CRB5yLz89fn3msUBU=.5a2f7a36-7111-471b-b4dd-dae91af7874a@github.com>
Message-ID: <DAnE6rQqAsxizEPIbt98EEHpplIRpDeWujqQ6fW4PSc=.9dd32375-37f8-4a91-b57b-f0216280c12f@github.com>

On Tue, 27 Feb 2024 05:55:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The test tries to create as many threads as possible in 5 seconds, with the intention of hitting platform limits on the maximum number of threads that can be created, so that we see that the VM reacts in a reasonable way. However on Linux, if the thread creation limit is high enough, and things run fast enough, then we can instead hit a fatal error when a mmap/mprotect returns E_NOMEM because the maximum number of memory mappings (default 65530) has been exceeded.
>> 
>> The fix to the test (courtesy @stefank ) is to re-exec the test on Linux with `ulimit -u` set to a much smaller value than the default (I chose 4096 as it still showed over 2000 threads were created before failure). This means we are unlikely to hit the default memory mapping limit before we hit the max threads limit.
>> 
>> I also updated the VM's OOM error message to include exceeding the maximum number of memory mappings as a possible cause (with a hint as to what to look for in the hs_err log).
>> 
>> Testing:
>>  - ran the test 10x on all platforms in our CI (plus local testing)
>> 
>> Thanks
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Invert logic to avoid negation.

So... if we reach the limit "max processes per user" we expect OOM, but if we reach vm.max_map_count, a fatal error is okay?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17959#issuecomment-1965848918

From dholmes at openjdk.org  Tue Feb 27 06:14:43 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 27 Feb 2024 06:14:43 GMT
Subject: RFR: 8318302: ThreadCountLimit.java failed with
 "Native memory allocation (mprotect) failed to protect 16384 bytes for memory
 to guard stack pages" [v2]
In-Reply-To: <DAnE6rQqAsxizEPIbt98EEHpplIRpDeWujqQ6fW4PSc=.9dd32375-37f8-4a91-b57b-f0216280c12f@github.com>
References: <owqAt1_7CSCVlCen_Lp7b3q1jMSjsU-D2SKq5ciBDgo=.1ec82f53-23b1-477d-887c-280b3721a505@github.com>
 <qgTWiu6o5t_MKTwceAc6JkY9l3CRB5yLz89fn3msUBU=.5a2f7a36-7111-471b-b4dd-dae91af7874a@github.com>
 <DAnE6rQqAsxizEPIbt98EEHpplIRpDeWujqQ6fW4PSc=.9dd32375-37f8-4a91-b57b-f0216280c12f@github.com>
Message-ID: <PVGKvrI5dV_KBjbmB2zvyXV6HS-SEYFfB6aAY3XZsTY=.503443d0-2e6e-4654-929f-d18340f1b549@github.com>

On Tue, 27 Feb 2024 06:05:19 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> So... if we reach the limit "max processes per user" we expect OOM, but if we reach vm.max_map_count, a fatal error is okay?

Yes. We can recover from `max processes per user` being reached, but we can't always recover from the max mappings being reached (there is actually just one fatal case when a new thread creates its own stack guard pages - there is no way to report a failure of that, so it is a fatal error).

In any case this PR is just about preventing this test from hitting a different limit to what it is trying to check.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17959#issuecomment-1965855939

From jkern at openjdk.org  Tue Feb 27 07:03:51 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Tue, 27 Feb 2024 07:03:51 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v26]
In-Reply-To: <rzJcK8ej_SBTvT0ch_dy8b0DYLRKhBdas5HEI4TzHJ4=.d3a710bc-d754-418e-b9c6-114d5a66757b@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <rzJcK8ej_SBTvT0ch_dy8b0DYLRKhBdas5HEI4TzHJ4=.d3a710bc-d754-418e-b9c6-114d5a66757b@github.com>
Message-ID: <wxEuSh46VrskjE0nzziQSoEdR-g4W7eAPsAjeWeAYFg=.86d52fdc-c34c-4dd0-bc92-536f72a240ef@github.com>

On Mon, 26 Feb 2024 11:24:13 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am.
>> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX.
>> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails.
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>    Address review comments

src/hotspot/os/aix/os_aix.cpp line 1175:

> 1173:   // Shared object in .so format dont have braces, hence they get removed for archives with members.
> 1174:   if (result == nullptr && pointer_to_dot != nullptr && strcmp(pointer_to_dot, old_extension) == 0) {
> 1175:     if (strcmp(pointer_to_dot, old_extension) == 0) {

Can you please remove this redundancy?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1503728978

From jbhateja at openjdk.org  Tue Feb 27 07:12:47 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 27 Feb 2024 07:12:47 GMT
Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v8]
In-Reply-To: <0FJI4QE-PYy7kUh6b76dZ1jsGQRGP3yR9UhkRsX9U3g=.0900c557-97ce-4be0-829b-79cf007b39c2@github.com>
References: <uWi4QxH31hL93771gkl_GgvP0m84IRSoR_1Yi8hD17E=.bc6ed458-7081-4c3f-9348-f59358fa05a4@github.com>
 <ZodY1FIPk3VAbz3nRKDmnKGHByEj_ygOBUR4SbG-6oo=.864cf3ec-9399-4411-ab7e-a92f9c90858f@github.com>
 <vKgvRTfvDCx3oNJSnKNGqV0WtroCRPiEP3hEdHp1oek=.b4b5b97d-4233-48d3-9cf2-e75176ed36ca@github.com>
 <I7EqdqNzJRToGpBfODbuNA5DtqTuCzQvgpGgFc8aeVw=.340e86b3-f7bc-42f0-8e85-f5d1f174b3a0@github.com>
 <0FJI4QE-PYy7kUh6b76dZ1jsGQRGP3yR9UhkRsX9U3g=.0900c557-97ce-4be0-829b-79cf007b39c2@github.com>
Message-ID: <dCpa4TNtYhfvZdttOrUwwY7zHqP4H6fetwq1jcgXgbA=.f1401d43-cd76-4469-96f9-ba13dad62206@github.com>

On Wed, 21 Feb 2024 15:51:21 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Hi @asgibbons ,
>> 
>> I am getting following error with slowdebug build on Meteor Lake system.
>> 
>> 
>> ERROR: Build failed for target 'images' in configuration 'linux-x86_64-server-slowdebug' (exit code 2) 
>> 
>> === Output from failing command(s) repeated here ===
>> * For target buildtools_create_symbols_javac__the.COMPILE_CREATE_SYMBOLS_batch:
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  Internal Error (/home/jatinbha/sandboxes/jdk-reviews/jdk/src/hotspot/share/asm/assembler.hpp:169), pid=237140, tid=237235
>> #  assert(is_bound() || is_unused()) failed: Label was never bound to a location, but it was used as a jmp target
>> #
>> # JRE version: OpenJDK Runtime Environment (23.0) (slowdebug build 23-internal-adhoc.sdp.jdk)
>> # Java VM: OpenJDK 64-Bit Server VM (slowdebug 23-internal-adhoc.sdp.jdk, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
>> # Problematic frame:
>> # V  [libjvm.so+0x4c9e3e]  Label::~Label()+0x5c
>> #
>> # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to /home/jatinbha/sandboxes/jdk-reviews/jdk/make/core.237140)
>> #
>> # An error report file with more information is saved as:
>> # /home/jatinbha/sandboxes/jdk-reviews/jdk/make/hs_err_pid237140.log
>>    ... (rest of output omitted)
>
> @jatin-bhateja Thanks for the note.  Fixed a couple of slowdebug compile issues.  Now builds successfully on Meteor Lake system.

Hi @asgibbons , 

I am still getting build errors with latest patch on a MeteorLake system. Kindly check


ERROR: Build failed for target 'images' in configuration 'linux-x86_64-server-fastdebug' (exit code 2) 

=== Output from failing command(s) repeated here ===
* For target buildtools_create_symbols_javac__the.COMPILE_CREATE_SYMBOLS_batch:
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f7220495dec, pid=530719, tid=530722
#
# JRE version: OpenJDK Runtime Environment (23.0) (fastdebug build 23-internal-adhoc.root.jdk)
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 23-internal-adhoc.root.jdk, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# v  ~StubRoutines::stringIndexOf 0x00007f7220495dec
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to /home/jatinbha/sandboxes/jdk-reviews/jdk/make/core.530719)
#
# An error report file with more information is saved as:
# /home/jatinbha/sandboxes/jdk-reviews/jdk/make/hs_err_pid530719.log
[5.638s][warning][os] Loading hsdis library failed
   ... (rest of output omitted)

* All command lines available in /home/jatinbha/sandboxes/jdk-reviews/jdk/build/linux-x86_64-server-fastdebug/make-support/failure-logs.
=== End of repeated output ===

No indication of failed target found.
HELP: Try searching the build log for '] Error'.
HELP: Run 'make doctor' to diagnose build problems.

make[1]: *** [/home/jatinbha/sandboxes/jdk-reviews/jdk/make/Init.gmk:323: main] Error 2
make: *** [/home/jatinbha/sandboxes/jdk-reviews/jdk/make/Init.gmk:189: images] Error 2

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16753#issuecomment-1965916165

From stefank at openjdk.org  Tue Feb 27 07:24:44 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 27 Feb 2024 07:24:44 GMT
Subject: RFR: 8318302: ThreadCountLimit.java failed with
 "Native memory allocation (mprotect) failed to protect 16384 bytes for memory
 to guard stack pages" [v2]
In-Reply-To: <qgTWiu6o5t_MKTwceAc6JkY9l3CRB5yLz89fn3msUBU=.5a2f7a36-7111-471b-b4dd-dae91af7874a@github.com>
References: <owqAt1_7CSCVlCen_Lp7b3q1jMSjsU-D2SKq5ciBDgo=.1ec82f53-23b1-477d-887c-280b3721a505@github.com>
 <qgTWiu6o5t_MKTwceAc6JkY9l3CRB5yLz89fn3msUBU=.5a2f7a36-7111-471b-b4dd-dae91af7874a@github.com>
Message-ID: <jWsHo85fJSM3c2c08mi4tK_NClUpT8sBhBjiQRN3YX8=.e3ea2d10-0d31-472b-b792-fec27cfc35ff@github.com>

On Tue, 27 Feb 2024 05:55:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The test tries to create as many threads as possible in 5 seconds, with the intention of hitting platform limits on the maximum number of threads that can be created, so that we see that the VM reacts in a reasonable way. However on Linux, if the thread creation limit is high enough, and things run fast enough, then we can instead hit a fatal error when a mmap/mprotect returns E_NOMEM because the maximum number of memory mappings (default 65530) has been exceeded.
>> 
>> The fix to the test (courtesy @stefank ) is to re-exec the test on Linux with `ulimit -u` set to a much smaller value than the default (I chose 4096 as it still showed over 2000 threads were created before failure). This means we are unlikely to hit the default memory mapping limit before we hit the max threads limit.
>> 
>> I also updated the VM's OOM error message to include exceeding the maximum number of memory mappings as a possible cause (with a hint as to what to look for in the hs_err log).
>> 
>> Testing:
>>  - ran the test 10x on all platforms in our CI (plus local testing)
>> 
>> Thanks
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Invert logic to avoid negation.

Marked as reviewed by stefank (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17959#pullrequestreview-1902706017

From stuefe at openjdk.org  Tue Feb 27 07:31:42 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 27 Feb 2024 07:31:42 GMT
Subject: RFR: 8318302: ThreadCountLimit.java failed with
 "Native memory allocation (mprotect) failed to protect 16384 bytes for memory
 to guard stack pages" [v2]
In-Reply-To: <PVGKvrI5dV_KBjbmB2zvyXV6HS-SEYFfB6aAY3XZsTY=.503443d0-2e6e-4654-929f-d18340f1b549@github.com>
References: <owqAt1_7CSCVlCen_Lp7b3q1jMSjsU-D2SKq5ciBDgo=.1ec82f53-23b1-477d-887c-280b3721a505@github.com>
 <qgTWiu6o5t_MKTwceAc6JkY9l3CRB5yLz89fn3msUBU=.5a2f7a36-7111-471b-b4dd-dae91af7874a@github.com>
 <DAnE6rQqAsxizEPIbt98EEHpplIRpDeWujqQ6fW4PSc=.9dd32375-37f8-4a91-b57b-f0216280c12f@github.com>
 <PVGKvrI5dV_KBjbmB2zvyXV6HS-SEYFfB6aAY3XZsTY=.503443d0-2e6e-4654-929f-d18340f1b549@github.com>
Message-ID: <71H9P0YQ0w8jhVc7L5F6EWcf5TKJrrsXsBW1RFwjVcU=.0c775ad3-1f98-4de5-9d18-70bcd6a8750d@github.com>

On Tue, 27 Feb 2024 06:12:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > So... if we reach the limit "max processes per user" we expect OOM, but if we reach vm.max_map_count, a fatal error is okay?
> 
> Yes. We can recover from `max processes per user` being reached, but we can't always recover from the max mappings being reached (there is actually just one fatal case when a new thread creates its own stack guard pages - there is no way to report a failure of that, so it is a fatal error).
> 
> In any case this PR is just about preventing this test from hitting a different limit to what it is trying to check.

Thank you for the clarification. The fix seems good.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17959#issuecomment-1965940912

From sroy at openjdk.org  Tue Feb 27 07:48:00 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Tue, 27 Feb 2024 07:48:00 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v27]
In-Reply-To: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
Message-ID: <aXBzSVu8J9fLA_33UsbGzIa9XAKay4mdmNsJyhEDm5I=.02699642-c5a3-437b-9ce4-5cb83a544db9@github.com>

> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am.
> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX.
> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails.

Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:

   remove redundant logic

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16604/files
  - new: https://git.openjdk.org/jdk/pull/16604/files/1943445d..57914589

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=26
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=25-26

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16604.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604

PR: https://git.openjdk.org/jdk/pull/16604

From sroy at openjdk.org  Tue Feb 27 07:57:49 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Tue, 27 Feb 2024 07:57:49 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v27]
In-Reply-To: <aXBzSVu8J9fLA_33UsbGzIa9XAKay4mdmNsJyhEDm5I=.02699642-c5a3-437b-9ce4-5cb83a544db9@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <aXBzSVu8J9fLA_33UsbGzIa9XAKay4mdmNsJyhEDm5I=.02699642-c5a3-437b-9ce4-5cb83a544db9@github.com>
Message-ID: <vmXPasGJ3nvnbZBdvN9mkyg1hniPQcp-va-7lM2Hf2Q=.248d9455-29ff-44de-a1ff-7d91452b412b@github.com>

On Tue, 27 Feb 2024 07:48:00 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am.
>> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX.
>> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails.
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>    remove redundant logic

Thank you everyone for your inputs, It was great learning from all of them.  I understood about secure coding guidelines in practice, which was a great experience.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1965971937

From mli at openjdk.org  Tue Feb 27 08:21:48 2024
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 27 Feb 2024 08:21:48 GMT
Subject: RFR: 8322179: RISC-V: Implement SHA-1 intrinsic [v14]
In-Reply-To: <dyUKgtGbL86VKCFBG88xOXgZLmkhs2lWcEb7dR7LBbo=.6fe5d469-b261-49ae-8bd4-15f4b2ac4d62@github.com>
References: <PyIXzENfiHysFS3IyZn3FDNQpV7Ua2L6OmjiXq9wRoU=.cf74a45e-c94b-4f7b-8768-d10d55e2ce1d@github.com>
 <qOXJYauKdggsWmevBILNLDlWaL0rqQlXxlvbDRr9Sko=.cd488d1d-6ad8-4f19-8ad8-6ab4292638ce@github.com>
 <dyUKgtGbL86VKCFBG88xOXgZLmkhs2lWcEb7dR7LBbo=.6fe5d469-b261-49ae-8bd4-15f4b2ac4d62@github.com>
Message-ID: <QGyofCGTr1DziuCzmFRMCIqqLRejoShUZeCqvPjHma4=.e92a0791-acf1-4ccd-9581-51dc870adf4f@github.com>

On Tue, 27 Feb 2024 03:36:50 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Looks good. Are there any changes on the performance numbers for the latest version? Thanks.

I did not compare between all versions, but yes, there is further improvement especially when data size grow, e.g. comparing with `abbf7c2`, final version as below

# final
Benchmark                                           (algorithm)  (dataSize)  (digesterName)  (length)  (provider)  Mode  Cnt         Score        Error  Units
o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1        64     DEFAULT  avgt   10      1845.049 ?     46.909  ns/op
o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1     16384     DEFAULT  avgt   10    174383.296 ?    605.029  ns/op
o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1        64     DEFAULT  avgt   10      2478.380 ?     19.147  ns/op
o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1     16384     DEFAULT  avgt   10    176391.224 ?    489.730  ns/op
o.o.b.javax.crypto.small.MessageDigestBench.digest         SHA1     1048576             N/A       N/A              avgt   10  11591613.058 ? 310656.422  ns/op

# abbf7c2
Benchmark                                           (algorithm)  (dataSize)  (digesterName)  (length)  (provider)  Mode  Cnt         Score        Error  Units
o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1        64     DEFAULT  avgt   10      1856.090 ?     34.903  ns/op
o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1     16384     DEFAULT  avgt   10    181397.109 ?    446.396  ns/op
o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1        64     DEFAULT  avgt   10      2469.551 ?     23.858  ns/op
o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1     16384     DEFAULT  avgt   10    183116.724 ?    343.619  ns/op
o.o.b.javax.crypto.small.MessageDigestBench.digest         SHA1     1048576             N/A       N/A              avgt   10  12059508.183 ? 285536.713  ns/op



   benchmark                                        algorithm  dataSize  digesterName  length  provider        base                  comp                        diff
1  o.o.b.java.security.MessageDigests.digest              N/A       N/A         SHA-1      64   DEFAULT    1856.090   ?34.903    1845.049   ?46.909  ns/op    -11.041  -0.59%
2  o.o.b.java.security.MessageDigests.digest              N/A       N/A         SHA-1   16384   DEFAULT  181397.109  ?446.396  174383.296  ?605.029  ns/op  -7013.813  -3.87%  ?
3  o.o.b.java.security.MessageDigests.getAndDigest        N/A       N/A         SHA-1      64   DEFAULT    2469.551   ?23.858    2478.380   ?19.147  ns/op     +8.829  +0.36%
4  o.o.b.java.security.MessageDigests.getAndDigest        N/A       N/A         SHA-1   16384   DEFAULT  183116.724  ?343.619  176391.224  ?489.730  ns/op  -6725.500  -3.67%  ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17130#issuecomment-1966004339

From mli at openjdk.org  Tue Feb 27 08:21:49 2024
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 27 Feb 2024 08:21:49 GMT
Subject: RFR: 8322179: RISC-V: Implement SHA-1 intrinsic [v4]
In-Reply-To: <_KHcFGW7NvUC6HM6YCi0D5e-n9t11OZk4GBKCiIncQ4=.83dbe8c8-09ca-4919-81f0-6b0ca066075e@github.com>
References: <PyIXzENfiHysFS3IyZn3FDNQpV7Ua2L6OmjiXq9wRoU=.cf74a45e-c94b-4f7b-8768-d10d55e2ce1d@github.com>
 <OS9eR4Cknl5zBhudp73KIQVmAEXQMglEo2feWJRhSI4=.76db4dbe-3f17-4f69-beb7-29d951f5b246@github.com>
 <zhE3XaogyD-VCENzfa3SuxvVWnRbTmEriyBd7hPcLxU=.e7c5cabc-0a74-4794-8141-df94d0963bb4@github.com>
 <_KHcFGW7NvUC6HM6YCi0D5e-n9t11OZk4GBKCiIncQ4=.83dbe8c8-09ca-4919-81f0-6b0ca066075e@github.com>
Message-ID: <Q65JBxiYQLCuQkroDGGxP3A-FbKcylXqf7iS1yjalXA=.69dc29ef-6474-49c0-bed0-3886b484e5ac@github.com>

On Mon, 29 Jan 2024 08:08:03 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hey,
>> Can I get more reviews? Thanks
>
>> Hey, Can I get more reviews? Thanks
> 
> Hi, will take another look. Can you merge with master? I see bot added merge-conflicts label. Thanks.

Thanks @RealFYang @gctony for your detailed reviewing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17130#issuecomment-1966005662

From mli at openjdk.org  Tue Feb 27 08:21:49 2024
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 27 Feb 2024 08:21:49 GMT
Subject: Integrated: 8322179: RISC-V: Implement SHA-1 intrinsic
In-Reply-To: <PyIXzENfiHysFS3IyZn3FDNQpV7Ua2L6OmjiXq9wRoU=.cf74a45e-c94b-4f7b-8768-d10d55e2ce1d@github.com>
References: <PyIXzENfiHysFS3IyZn3FDNQpV7Ua2L6OmjiXq9wRoU=.cf74a45e-c94b-4f7b-8768-d10d55e2ce1d@github.com>
Message-ID: <64qxYm0-8caXgdKvvLaKi9Jm-ewAaEU4VfTF6D7ITUg=.1e0d3d94-ff5e-4a3e-9926-994fdbd6d816@github.com>

On Fri, 15 Dec 2023 17:46:46 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you review this patch to implement SHA-1 intrinsic for riscv?
> Thanks!
> 
> 
> ## Test
> 
> ### Functionality
> 
> tests under `test/hotspot/jtreg/compiler/intrinsics/sha`
> tests found via `find test/jdk -iname "*SHA1*.java"`
> 
> ### Performance
> 
> tested on `T-HEAD Light Lichee Pi 4A`
> 
> JMH_PARAMS="-f 1 -wi 10 -i 20" // for every loop of jmh test
> 
> benchmark tests `MessageDigests.java GetMessageDigest.java MessageDigestBench.java MacBench.java` which are under `test/micro/org/openjdk/bench/`, more spcifically `TESTS="MessageDigests.digest MessageDigests.getAndDigest MessageDigestBench.digest"`
> 
> 
> // After
> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1        64     DEFAULT  avgt   20      1845.446 ?     27.052  ns/op
> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    181455.350 ?    532.258  ns/op
> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2447.674 ?     10.239  ns/op
> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    182896.083 ?   1242.774  ns/op
> o.o.b.javax.crypto.small.MessageDigestBench.digest         SHA1     1048576             N/A       N/A              avgt   20  11599227.792 ? 121442.390  ns/op
> // Before
> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2352.475 ?    11.198  ns/op
> o.o.b.java.security.MessageDigests.digest                   N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    188495.684 ?  1467.942  ns/op
> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1        64     DEFAULT  avgt   20      2437.347 ?     6.398  ns/op
> o.o.b.java.security.MessageDigests.getAndDigest             N/A         N/A           SHA-1     16384     DEFAULT  avgt   20    196086.570 ?  1140.998  ns/op
> o.o.b.javax.crypto.small.MessageDigestBench.digest         SHA1     1048576             N/A       N/A              avgt   20  12362160.119 ? 38788.109  ns/op
> 
> 
> **getAndDigest when size == 64**
> The data is not stable for test getAndDigest when size == 64, which I think is introduced by  j.s.MessageDigest.getInstance itself, which we don't touch in this patch.
> Check more details at [1](https://github.com/openjdk/jdk/pull/17130#issuecomment-1886805614)
> 
> 
> loop ... ...

This pull request has now been integrated.

Changeset: a48f5966
Author:    Hamlin Li <mli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a48f5966be17dea1c69e1c66719e43828768dbc1
Stats:     417 lines in 4 files changed: 387 ins; 16 del; 14 mod

8322179: RISC-V: Implement SHA-1 intrinsic

Reviewed-by: tonyp, fyang

-------------

PR: https://git.openjdk.org/jdk/pull/17130

From sroy at openjdk.org  Tue Feb 27 08:31:15 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Tue, 27 Feb 2024 08:31:15 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v28]
In-Reply-To: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
Message-ID: <s9R8RSGvi_zc-cbNdJDe3fK1XNDZsvizFZ3E8rV6Hns=.f78773be-5146-4c95-ad8c-6456d02f5213@github.com>

> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am.
> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX.
> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails.

Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:

  indendt

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16604/files
  - new: https://git.openjdk.org/jdk/pull/16604/files/57914589..55090448

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=27
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16604&range=26-27

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16604.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16604/head:pull/16604

PR: https://git.openjdk.org/jdk/pull/16604

From mdoerr at openjdk.org  Tue Feb 27 08:31:15 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 27 Feb 2024 08:31:15 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v27]
In-Reply-To: <aXBzSVu8J9fLA_33UsbGzIa9XAKay4mdmNsJyhEDm5I=.02699642-c5a3-437b-9ce4-5cb83a544db9@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <aXBzSVu8J9fLA_33UsbGzIa9XAKay4mdmNsJyhEDm5I=.02699642-c5a3-437b-9ce4-5cb83a544db9@github.com>
Message-ID: <kGrlJx3wd7mlf7TREFp8kGEHa9UTGt4VaasaI8xkgQM=.8e98d558-1282-4b1b-b0ce-89444089f8b6@github.com>

On Tue, 27 Feb 2024 07:48:00 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am.
>> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX.
>> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails.
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>    remove redundant logic

src/hotspot/os/aix/os_aix.cpp line 1176:

> 1174:   if (result == nullptr && pointer_to_dot != nullptr && strcmp(pointer_to_dot, old_extension) == 0) {
> 1175:       snprintf(pointer_to_dot, sizeof(old_extension), "%s", new_extension);
> 1176:       result = dll_load_library(file_path, ebuf, ebuflen);

You should have adapted the indentation, too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1503817600

From sroy at openjdk.org  Tue Feb 27 08:31:15 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Tue, 27 Feb 2024 08:31:15 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v27]
In-Reply-To: <kGrlJx3wd7mlf7TREFp8kGEHa9UTGt4VaasaI8xkgQM=.8e98d558-1282-4b1b-b0ce-89444089f8b6@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <aXBzSVu8J9fLA_33UsbGzIa9XAKay4mdmNsJyhEDm5I=.02699642-c5a3-437b-9ce4-5cb83a544db9@github.com>
 <kGrlJx3wd7mlf7TREFp8kGEHa9UTGt4VaasaI8xkgQM=.8e98d558-1282-4b1b-b0ce-89444089f8b6@github.com>
Message-ID: <9WIpKnZsaZFkbXwAjKQvwmngSuU7WvhV2LY2mHJ-LN0=.10e88c8f-d1b8-4edb-8b75-204bcdb9ebb4@github.com>

On Tue, 27 Feb 2024 08:22:21 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>    remove redundant logic
>
> src/hotspot/os/aix/os_aix.cpp line 1176:
> 
>> 1174:   if (result == nullptr && pointer_to_dot != nullptr && strcmp(pointer_to_dot, old_extension) == 0) {
>> 1175:       snprintf(pointer_to_dot, sizeof(old_extension), "%s", new_extension);
>> 1176:       result = dll_load_library(file_path, ebuf, ebuflen);
> 
> You should have adapted the indentation, too.

Which indentation ?

@TheRealMDoerr adapted

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1503820212
PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1503824233

From sroy at openjdk.org  Tue Feb 27 08:31:15 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Tue, 27 Feb 2024 08:31:15 GMT
Subject: RFR: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX [v27]
In-Reply-To: <9WIpKnZsaZFkbXwAjKQvwmngSuU7WvhV2LY2mHJ-LN0=.10e88c8f-d1b8-4edb-8b75-204bcdb9ebb4@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
 <aXBzSVu8J9fLA_33UsbGzIa9XAKay4mdmNsJyhEDm5I=.02699642-c5a3-437b-9ce4-5cb83a544db9@github.com>
 <kGrlJx3wd7mlf7TREFp8kGEHa9UTGt4VaasaI8xkgQM=.8e98d558-1282-4b1b-b0ce-89444089f8b6@github.com>
 <9WIpKnZsaZFkbXwAjKQvwmngSuU7WvhV2LY2mHJ-LN0=.10e88c8f-d1b8-4edb-8b75-204bcdb9ebb4@github.com>
Message-ID: <3Ijn-7dIJ9bNeJSj_YC1nZMLk5uuiigLhfIXBYngovY=.e15eb974-9144-4e28-8f9f-932b1c26d1e3@github.com>

On Tue, 27 Feb 2024 08:23:58 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> src/hotspot/os/aix/os_aix.cpp line 1176:
>> 
>>> 1174:   if (result == nullptr && pointer_to_dot != nullptr && strcmp(pointer_to_dot, old_extension) == 0) {
>>> 1175:       snprintf(pointer_to_dot, sizeof(old_extension), "%s", new_extension);
>>> 1176:       result = dll_load_library(file_path, ebuf, ebuflen);
>> 
>> You should have adapted the indentation, too.
>
> Which indentation ?

oh! to reduce the spaces

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1503821531

From tschatzl at openjdk.org  Tue Feb 27 08:32:49 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 27 Feb 2024 08:32:49 GMT
Subject: RFR: 8305898: Alternative self-forwarding mechanism [v4]
In-Reply-To: <nICORfXgD_s_a4YDdXzr2akkdzLKWodAdma7aaOVprk=.39162afc-b900-4013-a3aa-7a060c6d1a51@github.com>
References: <N4eX8S-btv0VD19kl2W9RigVsaw58ZVXDZllFwykZ04=.a9456aa8-b294-480a-b7f0-07616c972f62@github.com>
 <OC2HtdWXXKiV3OLkz39XVG7bickA31IZZVgpZpZy3GU=.04506b71-994c-4dc6-a39f-cf0d0c908977@github.com>
 <nICORfXgD_s_a4YDdXzr2akkdzLKWodAdma7aaOVprk=.39162afc-b900-4013-a3aa-7a060c6d1a51@github.com>
Message-ID: <ZiieNtqlmj-Vx1f56R3QMlQJcAbUnjHid8Dq_bfG7yk=.1d72f07c-9c1c-4574-ac23-728027573677@github.com>

On Mon, 26 Feb 2024 15:26:35 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> I'm leaning towards doing that in a follow-up PR.

+1

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17755#issuecomment-1966026427

From luhenry at openjdk.org  Tue Feb 27 08:50:44 2024
From: luhenry at openjdk.org (Ludovic Henry)
Date: Tue, 27 Feb 2024 08:50:44 GMT
Subject: RFR: 8320646: RISC-V: C2 VectorCastHF2F [v2]
In-Reply-To: <fTvkUqcIsICvOIRWhqcICR8OYfaiOsOgSoaJsgUUm94=.09bb33c2-ce00-4943-bed0-0a1906395ee4@github.com>
References: <kqLQR-bD3v7iF7LgH0PzwIH_m6QH_2b371pKz9_Ovq8=.9c07c165-2a97-4a6b-9e82-6a6de0b81328@github.com>
 <fTvkUqcIsICvOIRWhqcICR8OYfaiOsOgSoaJsgUUm94=.09bb33c2-ce00-4943-bed0-0a1906395ee4@github.com>
Message-ID: <tX9EXdMM7H_ntn3ERpCh8M2n4HfcU8000mNuQIfoMj0=.3494461c-7fcf-419f-9ae4-282606175979@github.com>

On Wed, 7 Feb 2024 15:22:09 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you review this patch to add instrinsics for VectorCastHF2F/VectorCastF2HF?
>> Thanks!
>> 
>> ## Test
>> 
>> test/jdk/java/lang/Float/Binary16ConversionNaN.java
>> test/jdk/java/lang/Float/Binary16Conversion.java
>> 
>> hotspot/jtreg/compiler/intrinsics/float16
>> hotspot/jtreg/compiler/vectorization/TestFloatConversionsVectorjava
>> hotspot/jtreg/compiler/vectorization/TestFloatConversionsVectorNaN.java
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add some comments

Small changes.

src/hotspot/cpu/riscv/riscv_v.ad line 3691:

> 3689:   match(Set dst (VectorCastHF2F src));
> 3690:   effect(TEMP_DEF dst, TEMP v0);
> 3691:   format %{ "vfwcvt.f.f.v $dst, $src\t# convert half to single precision"

Unnecessary new-line:
Suggestion:

  format %{ "vfwcvt.f.f.v $dst, $src\t# convert half to single precision" %}

src/hotspot/cpu/riscv/riscv_v.ad line 3706:

> 3704:   match(Set dst (VectorCastF2HF src));
> 3705:   effect(TEMP_DEF dst, TEMP v0, TEMP tmp);
> 3706:   format %{ "vfncvt.f.f.w $dst, $src\t# convert single to half precision"

Unnecessary new-line:
Suggestion:

  format %{ "vfwcvt.f.f.v $dst, $src\t# convert half to single precision" %}

-------------

Marked as reviewed by luhenry (Committer).

PR Review: https://git.openjdk.org/jdk/pull/17698#pullrequestreview-1902878504
PR Review Comment: https://git.openjdk.org/jdk/pull/17698#discussion_r1503852770
PR Review Comment: https://git.openjdk.org/jdk/pull/17698#discussion_r1503853103

From duke at openjdk.org  Tue Feb 27 09:01:58 2024
From: duke at openjdk.org (Lei Zaakjyu)
Date: Tue, 27 Feb 2024 09:01:58 GMT
Subject: Integrated: 8325082: Rename headers named 'heapRegion*' of G1
In-Reply-To: <1MWMgluBwGY-FydUnpoksJ0q5sSvptrNMv6xwDszBQc=.a78cadad-1585-44d1-97d0-a7928fe34d67@github.com>
References: <1MWMgluBwGY-FydUnpoksJ0q5sSvptrNMv6xwDszBQc=.a78cadad-1585-44d1-97d0-a7928fe34d67@github.com>
Message-ID: <71BZdKO-kjui9hCBUv0pju5hxTEbD8hl2KcaFcJrz-8=.1f9c2832-c992-4508-bd6b-dd75f147ea1f@github.com>

On Thu, 1 Feb 2024 03:57:48 GMT, Lei Zaakjyu <duke at openjdk.org> wrote:

> 8325082: Rename headers named 'heapRegion*' of G1

This pull request has now been integrated.

Changeset: c5f1dccc
Author:    Lei Zaakjyu <lizbing07734 at icloud.com>
Committer: Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c5f1dcccfce7b943c1a91aa65709576038098e91
Stats:     356 lines in 105 files changed: 133 ins; 133 del; 90 mod

8325082: Rename headers named 'heapRegion*' of G1

Reviewed-by: stefank, tschatzl

-------------

PR: https://git.openjdk.org/jdk/pull/17666

From ddong at openjdk.org  Tue Feb 27 09:08:53 2024
From: ddong at openjdk.org (Denghui Dong)
Date: Tue, 27 Feb 2024 09:08:53 GMT
Subject: RFR: 8326012: JFR: Event for time to safepoint [v9]
In-Reply-To: <DwJb1JrYg4IMe_3d5MAjEkiwdTDhYHFCx0qVxDCmLmc=.47673420-7467-42e6-8231-e37d9e8882f9@github.com>
References: <68hS0kQgtDIk4ioAJj_r0_GLT6h0lcif6Daj6WRwxlI=.40c2a6e7-70a8-4954-bcde-9318ee311028@github.com>
 <DwJb1JrYg4IMe_3d5MAjEkiwdTDhYHFCx0qVxDCmLmc=.47673420-7467-42e6-8231-e37d9e8882f9@github.com>
Message-ID: <eQHl01aLhp6Obb23SmiWSvKjRgfi9muOtxSamo_misw=.ff6cf2ee-e336-4c8b-bbad-8fa98b0ff13d@github.com>

On Tue, 20 Feb 2024 05:27:22 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> There are now some JFR events related to safepoint. When time-to-safepoint (aka ttsp) is too long, these events could not be very helpful since based on them we cannot know which threads cause it and what those threads are doing.
>> 
>> Users can use `-XX:+SafepointTimeout -XX:SafepointTimeoutDelay=100` to see the threads that don't reach safepoint in time but without stack traces. Using `-XX:+ AbortVMOnSafepointTimeout` can capture the stack traces but it crashes the process, hence it's not sensible to enable the flag in production.
>> 
>> ~~This patch adds a new JFR event `EventSafepointTimeout` to record the threads that cause ttsp too long.~~
>> 
>> ~~This event includes two fields:~~
>> 
>> ~~- safepointId: the relevant safepoint id~~
>> ~~- timeExceeded: the amount of time exceeding `SafepointTimeoutDelay` used by the thread to reach safepoint~~
>> 
>> ~~In the current version, this event records the stack of those problematic threads when they finally reach safepoint. Hence, there is a bias, but it's still helpful to deduce the root place.~~
>> 
>> A better implementation is to record a more accurate stack, but this will increase complexity. At the same time, the native stack may also be important for this problem, but it is not currently supported by JFR.
>> 
>> Any input would be greatly appreciated.
>> 
>> Testing: jdk/jdk/jfr
>
> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   delete _entries when disabled

Any thoughts?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17888#issuecomment-1966086335

From azafari at openjdk.org  Tue Feb 27 09:14:43 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 27 Feb 2024 09:14:43 GMT
Subject: RFR: 8324829: Uniform use of synchronizations in NMT
In-Reply-To: <fA21LvS-wzafLsPkOwfeJyBKwk7Dbd4tTCAGZWfT98w=.d7256753-9451-4a78-927f-87cc79dfb80e@github.com>
References: <uikMP7BCa6Wro3F63W7C4qQZNMgDSjSYXzHEGCroSDA=.aef515a7-6352-41d5-8aa5-ac0c94e5886d@github.com>
 <n_1OdA4LcLIvw-mkQ_U-2nItlBv9m0DGK62gb_p0xnQ=.137f48b6-f0cc-476e-b856-3c87b888d98a@github.com>
 <fA21LvS-wzafLsPkOwfeJyBKwk7Dbd4tTCAGZWfT98w=.d7256753-9451-4a78-927f-87cc79dfb80e@github.com>
Message-ID: <ZTtUbQcn5UB0OVNU9u1iufOzzwOgQliNXfGH9o3BAQY=.36c813c6-0a76-45b8-b0e5-c0110a08a60b@github.com>

On Mon, 26 Feb 2024 14:47:26 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Could we rename VirtualMemoryTracker::remove_uncommitted_region to something else (e.g. VirtualMemoryTracker::remove_committed_region or VirtualMemoryTracker::uncommit_region)? I always start wondering when reading this function name, since we don't remove an uncommitted region, we uncommit a region resp. remove a committed region.

The `VirtualMemoryTracker` (VMT) API is used internally by the NMT itself. The `MemTracker` API are the ones used by other hotspot code. The *remove* in `VirtualMemoryTracking::remove_uncommitted_region` refers to editing of the linked list and not referring to the memory operations. When we uncommit a region we call `MemTracker::record_virtual_memory_uncommit` for recording that in NMT which is meaningful and correct. VMT APIs are not called/used by non-NMT hotspot code.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18000#issuecomment-1966096901

From sroy at openjdk.org  Tue Feb 27 09:19:01 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Tue, 27 Feb 2024 09:19:01 GMT
Subject: Integrated: JDK-8320005 :  Allow loading of shared objects with .a
 extension on AIX
In-Reply-To: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
References: <8-buFPL9W3149qcnluk_XqTQr-cJYqu_XvwU5ovyAIA=.396e5005-f896-48b9-919c-94164229d7bf@github.com>
Message-ID: <PDji4OZAu4Q0sKwWYIyIkEUc8so7fQ3sONdK9C17ZVo=.899be4f6-1277-47ae-9a66-52abeb65bbd8@github.com>

On Fri, 10 Nov 2023 12:28:46 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

> J2SE agent does not start and throws error when it tries to find the shared library ibm_16_am.
> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load fails.It fails to identify the shared library ibm_16_am.a shared archive file on AIX.
> Hence we are providing a function which will additionally search for .a file on AIX ,when the search for .so file fails.

This pull request has now been integrated.

Changeset: e85355ad
Author:    Suchismith Roy <sroy at openjdk.org>
Committer: Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e85355ada4ac1061c49ee9f1247d37a437c7b5ab
Stats:     22 lines in 1 file changed: 20 ins; 1 del; 1 mod

8320005: Allow loading of shared objects with .a extension on AIX

Reviewed-by: amitkumar, stuefe, jkern, mdoerr

-------------

PR: https://git.openjdk.org/jdk/pull/16604

From fyang at openjdk.org  Tue Feb 27 09:54:57 2024
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 27 Feb 2024 09:54:57 GMT
Subject: RFR: 8320646: RISC-V: C2 VectorCastHF2F [v2]
In-Reply-To: <fTvkUqcIsICvOIRWhqcICR8OYfaiOsOgSoaJsgUUm94=.09bb33c2-ce00-4943-bed0-0a1906395ee4@github.com>
References: <kqLQR-bD3v7iF7LgH0PzwIH_m6QH_2b371pKz9_Ovq8=.9c07c165-2a97-4a6b-9e82-6a6de0b81328@github.com>
 <fTvkUqcIsICvOIRWhqcICR8OYfaiOsOgSoaJsgUUm94=.09bb33c2-ce00-4943-bed0-0a1906395ee4@github.com>
Message-ID: <k_9SAB2dNMVxzI5kc2Hd_7Nou8CvA998lE1WJTkphhY=.3f85f4e9-5a40-40be-9c6d-4db89a42c182@github.com>

On Wed, 7 Feb 2024 15:22:09 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you review this patch to add instrinsics for VectorCastHF2F/VectorCastF2HF?
>> Thanks!
>> 
>> ## Test
>> 
>> test/jdk/java/lang/Float/Binary16ConversionNaN.java
>> test/jdk/java/lang/Float/Binary16Conversion.java
>> 
>> hotspot/jtreg/compiler/intrinsics/float16
>> hotspot/jtreg/compiler/vectorization/TestFloatConversionsVectorjava
>> hotspot/jtreg/compiler/vectorization/TestFloatConversionsVectorNaN.java
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add some comments

One comment after a brief look. Thanks.

src/hotspot/cpu/riscv/globals_riscv.hpp line 117:

> 115:   product(bool, UseZihintpause, false, EXPERIMENTAL,                             \
> 116:           "Use Zihintpause instructions")                                        \
> 117:   product(bool, UseZvfh, false, "Use Zvfh instructions")                         \

I don't think it's a good idea to have more and more experimental / disagnostic options for new RV extensions. I think it might be better to make use of the hwprobe syscall and take a vendor-specific approach. One example is https://github.com/openjdk/jdk/pull/17122 which adds instructions for RV Zcb extension.

-------------

PR Review: https://git.openjdk.org/jdk/pull/17698#pullrequestreview-1903034501
PR Review Comment: https://git.openjdk.org/jdk/pull/17698#discussion_r1503947198

From egahlin at openjdk.org  Tue Feb 27 09:55:57 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 27 Feb 2024 09:55:57 GMT
Subject: RFR: 8326012: JFR: Event for time to safepoint [v9]
In-Reply-To: <eQHl01aLhp6Obb23SmiWSvKjRgfi9muOtxSamo_misw=.ff6cf2ee-e336-4c8b-bbad-8fa98b0ff13d@github.com>
References: <68hS0kQgtDIk4ioAJj_r0_GLT6h0lcif6Daj6WRwxlI=.40c2a6e7-70a8-4954-bcde-9318ee311028@github.com>
 <DwJb1JrYg4IMe_3d5MAjEkiwdTDhYHFCx0qVxDCmLmc=.47673420-7467-42e6-8231-e37d9e8882f9@github.com>
 <eQHl01aLhp6Obb23SmiWSvKjRgfi9muOtxSamo_misw=.ff6cf2ee-e336-4c8b-bbad-8fa98b0ff13d@github.com>
Message-ID: <RLiSgY042io7u7cEvNeiYLmYXXXeiMmpHbbkmhyndUE=.8c6e2688-f6b3-4476-847b-7ada0a7284f7@github.com>

On Tue, 27 Feb 2024 09:06:31 GMT, Denghui Dong <ddong at openjdk.org> wrote:

> Any thoughts?

I haven't look at the implementation, mostly interested in the design for now. Should thread-local handshake be included in this event, or is it better done separately, or not at all?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17888#issuecomment-1966175491

From rkennke at openjdk.org  Tue Feb 27 10:08:54 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 27 Feb 2024 10:08:54 GMT
Subject: RFR: 8305898: Alternative self-forwarding mechanism [v4]
In-Reply-To: <ZiieNtqlmj-Vx1f56R3QMlQJcAbUnjHid8Dq_bfG7yk=.1d72f07c-9c1c-4574-ac23-728027573677@github.com>
References: <N4eX8S-btv0VD19kl2W9RigVsaw58ZVXDZllFwykZ04=.a9456aa8-b294-480a-b7f0-07616c972f62@github.com>
 <OC2HtdWXXKiV3OLkz39XVG7bickA31IZZVgpZpZy3GU=.04506b71-994c-4dc6-a39f-cf0d0c908977@github.com>
 <nICORfXgD_s_a4YDdXzr2akkdzLKWodAdma7aaOVprk=.39162afc-b900-4013-a3aa-7a060c6d1a51@github.com>
 <ZiieNtqlmj-Vx1f56R3QMlQJcAbUnjHid8Dq_bfG7yk=.1d72f07c-9c1c-4574-ac23-728027573677@github.com>
Message-ID: <frxeGJBJo98I48F4fqP5mLJGsiQs9bMlOtyRNSWsJpo=.48ae9d96-49ca-43c4-a629-4c1b4b0ff893@github.com>

On Tue, 27 Feb 2024 08:30:17 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> I'm leaning towards doing that in a follow-up PR.

Ok. But maybe this would be an incentive to do this change ahead of the Lilliput main JEP, in JDK23? This PR, as it is proposed now doesn't provide much value in itself, but with the proposed follow-up, it does improve/simplify promotion-failure handling, and restricts usage of the PreservedMarks stuff to the full-GCs only.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17755#issuecomment-1966198672

From ihse at openjdk.org  Tue Feb 27 10:30:05 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 27 Feb 2024 10:30:05 GMT
Subject: Integrated: 8017234: Hotspot should stop using mapfiles
In-Reply-To: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
References: <kg8dQz5aOK5UD29PxKOtdGjghM9b9e5DeKnEBjlP-vM=.a4564f25-154c-4418-a8af-336608d15a42@github.com>
Message-ID: <sEjTPQawLffg22H2dsPlfpeytizNb2ALmngDHyBk8_A=.4d288316-0892-43d4-abe7-5e7548c22d6c@github.com>

On Wed, 21 Feb 2024 23:32:15 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
> 
> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
> 
> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
> 
> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.

This pull request has now been integrated.

Changeset: da14aa46
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/da14aa463b8fcd56ba1f1a4cdb3e3f7b19f78964
Stats:     1001 lines in 33 files changed: 239 ins; 578 del; 184 mod

8017234: Hotspot should stop using mapfiles

Reviewed-by: djelinski, erikj, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/17955

From tschatzl at openjdk.org  Tue Feb 27 10:30:56 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 27 Feb 2024 10:30:56 GMT
Subject: RFR: 8305898: Alternative self-forwarding mechanism [v4]
In-Reply-To: <OC2HtdWXXKiV3OLkz39XVG7bickA31IZZVgpZpZy3GU=.04506b71-994c-4dc6-a39f-cf0d0c908977@github.com>
References: <N4eX8S-btv0VD19kl2W9RigVsaw58ZVXDZllFwykZ04=.a9456aa8-b294-480a-b7f0-07616c972f62@github.com>
 <OC2HtdWXXKiV3OLkz39XVG7bickA31IZZVgpZpZy3GU=.04506b71-994c-4dc6-a39f-cf0d0c908977@github.com>
Message-ID: <JwfFhxxaPdUF9rMWVtpz2t845n5jtjDThGmC85wLRrQ=.763879ea-4cfd-4c45-a1b8-f3de38f12264@github.com>

On Thu, 8 Feb 2024 14:37:20 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Currently, the Serial, Parallel and G1 GCs store a pointer to self into object headers to indicate promotion failure. This is problematic for compact object headers ([JDK-8294992](https://bugs.openjdk.org/browse/JDK-8294992)) because it would (temporarily) over-write the crucial class information, which we need for heap parsing. I would like to propose an alternative: use the currently unused 3rd header bit (previously biased-locking bit) to indicate that an object is 'self-forwarded'. That preserves the crucial class information in the upper bits of the header until the full header gets restored.
>> 
>> This is a trimmed-down/simplified version of the original proposal #13779:
>>  - It doesn't use/introduce any flags and avoids the associated branching.
>>  - It doesn't (need to) deal with displaced headers. (Current code would preserve header if necessary, Lilliput code would not use displaced headers and set the 3rd bit directly in existing header.)
>> 
>> Testing:
>>  - [x] hotspot_gc
>>  - [x] tier1
>>  - [x] tier2
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More consistent use of markWord::is_forwarded()

We often do preparatory changes separately from the main improvement for several reasons, one of them to reduce complexity of the follow-up.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17755#issuecomment-1966241228

From ihse at openjdk.org  Tue Feb 27 11:01:03 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 27 Feb 2024 11:01:03 GMT
Subject: RFR: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234 [v4]
In-Reply-To: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
References: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
Message-ID: <wHGBIhPuYhFHpOmp-pckQClVnS4sODTqkZHqNbI5tB4=.cd8f6adb-14a4-4160-92cc-41e7b871ad2d@github.com>

> Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) has been integrated, it is possible to do some cleanup. The goal of [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) was to not change any behavior, even if that behavior seemed odd.
> 
> Now let's try to fix that. We can:
> 
> a) remove JNIEXPORT from c2v functions.
> b) make debug.cpp functions exported similarly on all platforms.
> c) remove JNIEXPORT from aarch64 asm debug function.
> 
> Note that this PR is [dependent on](https://mail.openjdk.org/pipermail/jdk-dev/2021-March/005232.html) https://github.com/openjdk/jdk/pull/17955.

Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Merge branch 'master' into hotspot-symbols-followup
 - Remove jvmci globals
 - 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234
 - Revert "Use #pragma instead of HIDDEN define"
   
   This reverts commit 00e40a7f6e4cdef6592d72b3d08063cdcc41532a.
 - Use #pragma instead of HIDDEN define
 - Rename the version script to version-script.txt
 - Restore linker script to linux/gcc builds
 - Rename the Windows export file to .def
 - Remove unused symbol _Copy_conjoint_bytes on linux/arm32
 - 8017234: Hotspot should stop using mapfiles

-------------

Changes: https://git.openjdk.org/jdk/pull/17967/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17967&range=03
  Stats: 12 lines in 3 files changed: 0 ins; 8 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/17967.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17967/head:pull/17967

PR: https://git.openjdk.org/jdk/pull/17967

From ddong at openjdk.org  Tue Feb 27 11:09:53 2024
From: ddong at openjdk.org (Denghui Dong)
Date: Tue, 27 Feb 2024 11:09:53 GMT
Subject: RFR: 8326012: JFR: Event for time to safepoint [v9]
In-Reply-To: <RLiSgY042io7u7cEvNeiYLmYXXXeiMmpHbbkmhyndUE=.8c6e2688-f6b3-4476-847b-7ada0a7284f7@github.com>
References: <68hS0kQgtDIk4ioAJj_r0_GLT6h0lcif6Daj6WRwxlI=.40c2a6e7-70a8-4954-bcde-9318ee311028@github.com>
 <DwJb1JrYg4IMe_3d5MAjEkiwdTDhYHFCx0qVxDCmLmc=.47673420-7467-42e6-8231-e37d9e8882f9@github.com>
 <eQHl01aLhp6Obb23SmiWSvKjRgfi9muOtxSamo_misw=.ff6cf2ee-e336-4c8b-bbad-8fa98b0ff13d@github.com>
 <RLiSgY042io7u7cEvNeiYLmYXXXeiMmpHbbkmhyndUE=.8c6e2688-f6b3-4476-847b-7ada0a7284f7@github.com>
Message-ID: <4fTba8X9C9mI3PrFB2L48h0sL7oSxkmm9IWep1qvn9E=.153a5352-8452-4446-9019-b8728e9c7bdf@github.com>

On Tue, 27 Feb 2024 09:53:26 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Should thread-local handshake be included in this event, or is it better done separately, or not at all?

In my opinion, if we need to record information for thread-local handshake, we'd better do it separately.

We may need more than one event or different fields than the event that this feature focuses on. Some information that I think we need to record:
- requester thread
- target thread(s)
- the time when the target thread starts processing
- handshake reason
- isAsync
...

As for whether we need to add JFR events for thread-local handshake, I want to first see if there are any problems in real workloads due to slow thread-local handshake.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17888#issuecomment-1966306092

From dholmes at openjdk.org  Tue Feb 27 12:14:15 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 27 Feb 2024 12:14:15 GMT
Subject: RFR: 8318302: ThreadCountLimit.java failed with
 "Native memory allocation (mprotect) failed to protect 16384 bytes for memory
 to guard stack pages" [v3]
In-Reply-To: <owqAt1_7CSCVlCen_Lp7b3q1jMSjsU-D2SKq5ciBDgo=.1ec82f53-23b1-477d-887c-280b3721a505@github.com>
References: <owqAt1_7CSCVlCen_Lp7b3q1jMSjsU-D2SKq5ciBDgo=.1ec82f53-23b1-477d-887c-280b3721a505@github.com>
Message-ID: <xXcYEzhgYKMM3XB3XL3xcan6jd0qpoq9P2YAfeA-kok=.a112d7ee-881e-4d7a-a3a4-fcde7d66bdf7@github.com>

> The test tries to create as many threads as possible in 5 seconds, with the intention of hitting platform limits on the maximum number of threads that can be created, so that we see that the VM reacts in a reasonable way. However on Linux, if the thread creation limit is high enough, and things run fast enough, then we can instead hit a fatal error when a mmap/mprotect returns E_NOMEM because the maximum number of memory mappings (default 65530) has been exceeded.
> 
> The fix to the test (courtesy @stefank ) is to re-exec the test on Linux with `ulimit -u` set to a much smaller value than the default (I chose 4096 as it still showed over 2000 threads were created before failure). This means we are unlikely to hit the default memory mapping limit before we hit the max threads limit.
> 
> I also updated the VM's OOM error message to include exceeding the maximum number of memory mappings as a possible cause (with a hint as to what to look for in the hs_err log).
> 
> Testing:
>  - ran the test 10x on all platforms in our CI (plus local testing)
> 
> Thanks

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Style nit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17959/files
  - new: https://git.openjdk.org/jdk/pull/17959/files/263c7c41..addf08d8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17959&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17959&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17959.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17959/head:pull/17959

PR: https://git.openjdk.org/jdk/pull/17959

From dholmes at openjdk.org  Tue Feb 27 12:14:15 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 27 Feb 2024 12:14:15 GMT
Subject: RFR: 8318302: ThreadCountLimit.java failed with
 "Native memory allocation (mprotect) failed to protect 16384 bytes for memory
 to guard stack pages" [v3]
In-Reply-To: <98Z3mMnDM6NuPlwduJ0MN9KnlP7NYdIxqXikHZE5JuE=.973a703f-9bf0-437f-93ab-ac01f385b824@github.com>
References: <owqAt1_7CSCVlCen_Lp7b3q1jMSjsU-D2SKq5ciBDgo=.1ec82f53-23b1-477d-887c-280b3721a505@github.com>
 <98Z3mMnDM6NuPlwduJ0MN9KnlP7NYdIxqXikHZE5JuE=.973a703f-9bf0-437f-93ab-ac01f385b824@github.com>
Message-ID: <CeK89sKcCI9Q7n1ftuxhO9i1L0eGAyQ4pc61p7xt_xw=.7f54fbdd-b3b2-43ae-b8c9-9a044f786e92@github.com>

On Thu, 22 Feb 2024 09:08:45 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Style nit
>
> test/hotspot/jtreg/runtime/Thread/ThreadCountLimit.java line 80:
> 
>> 78:         final String ULIMIT_CMD = "ulimit -u 4096";
>> 79:         ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder(ThreadCountLimit.class.getName());
>> 80:         String java_cmd = ProcessTools.getCommandLine(pb);
> 
> Nit: `java_cmd` -> `javaCmd`.

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17959#discussion_r1504125359

From luhenry at openjdk.org  Tue Feb 27 14:50:45 2024
From: luhenry at openjdk.org (Ludovic Henry)
Date: Tue, 27 Feb 2024 14:50:45 GMT
Subject: RFR: 8320646: RISC-V: C2 VectorCastHF2F [v2]
In-Reply-To: <fTvkUqcIsICvOIRWhqcICR8OYfaiOsOgSoaJsgUUm94=.09bb33c2-ce00-4943-bed0-0a1906395ee4@github.com>
References: <kqLQR-bD3v7iF7LgH0PzwIH_m6QH_2b371pKz9_Ovq8=.9c07c165-2a97-4a6b-9e82-6a6de0b81328@github.com>
 <fTvkUqcIsICvOIRWhqcICR8OYfaiOsOgSoaJsgUUm94=.09bb33c2-ce00-4943-bed0-0a1906395ee4@github.com>
Message-ID: <2gw0Ku-173RNRXv1NvCQI2qUj3i1Ay_5ZMVWJOZwsDw=.3c9d78e1-413f-4df8-b30b-4771d2d4f112@github.com>

On Wed, 7 Feb 2024 15:22:09 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you review this patch to add instrinsics for VectorCastHF2F/VectorCastF2HF?
>> Thanks!
>> 
>> ## Test
>> 
>> test/jdk/java/lang/Float/Binary16ConversionNaN.java
>> test/jdk/java/lang/Float/Binary16Conversion.java
>> 
>> hotspot/jtreg/compiler/intrinsics/float16
>> hotspot/jtreg/compiler/vectorization/TestFloatConversionsVectorjava
>> hotspot/jtreg/compiler/vectorization/TestFloatConversionsVectorNaN.java
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add some comments

Changes requested by luhenry (Committer).

src/hotspot/cpu/riscv/globals_riscv.hpp line 117:

> 115:   product(bool, UseZihintpause, false, EXPERIMENTAL,                             \
> 116:           "Use Zihintpause instructions")                                        \
> 117:   product(bool, UseZvfh, false, "Use Zvfh instructions")                         \

If adding this flag, please mark as experimental as there is currently no hardware we can test that on (other than QEMU).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17698#pullrequestreview-1903725178
PR Review Comment: https://git.openjdk.org/jdk/pull/17698#discussion_r1504362532

From luhenry at openjdk.org  Tue Feb 27 14:50:46 2024
From: luhenry at openjdk.org (Ludovic Henry)
Date: Tue, 27 Feb 2024 14:50:46 GMT
Subject: RFR: 8320646: RISC-V: C2 VectorCastHF2F [v2]
In-Reply-To: <k_9SAB2dNMVxzI5kc2Hd_7Nou8CvA998lE1WJTkphhY=.3f85f4e9-5a40-40be-9c6d-4db89a42c182@github.com>
References: <kqLQR-bD3v7iF7LgH0PzwIH_m6QH_2b371pKz9_Ovq8=.9c07c165-2a97-4a6b-9e82-6a6de0b81328@github.com>
 <fTvkUqcIsICvOIRWhqcICR8OYfaiOsOgSoaJsgUUm94=.09bb33c2-ce00-4943-bed0-0a1906395ee4@github.com>
 <k_9SAB2dNMVxzI5kc2Hd_7Nou8CvA998lE1WJTkphhY=.3f85f4e9-5a40-40be-9c6d-4db89a42c182@github.com>
Message-ID: <ZwaoSyFg4BXYEZlZHnJ1rx6vdt8xAWzV4XQXRDriR5U=.47567d13-6df9-452c-baac-d376c1830df0@github.com>

On Tue, 27 Feb 2024 09:50:33 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add some comments
>
> src/hotspot/cpu/riscv/globals_riscv.hpp line 117:
> 
>> 115:   product(bool, UseZihintpause, false, EXPERIMENTAL,                             \
>> 116:           "Use Zihintpause instructions")                                        \
>> 117:   product(bool, UseZvfh, false, "Use Zvfh instructions")                         \
> 
> I don't think it's a good idea to have more and more experimental / disagnostic options for new RV extensions. I think it might be better to make use of the hwprobe syscall and take a vendor-specific approach. One example is https://github.com/openjdk/jdk/pull/17122 which adds instructions for RV Zcb extension.

We still want to give end users the ability to disable extensions if things are broken. The flags would be the only way if we rely on hwprobe + vendor specific flags (like https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp#L232-L260, and which I'm surprised not more hw vendors have added their own)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17698#discussion_r1504360368

From luhenry at openjdk.org  Tue Feb 27 15:38:53 2024
From: luhenry at openjdk.org (Ludovic Henry)
Date: Tue, 27 Feb 2024 15:38:53 GMT
Subject: RFR: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234 [v4]
In-Reply-To: <2E0F9OsixwTZ_Mq9OfUx1BQUStc92p0evM8KCbhz3jc=.18fd874c-f02a-406a-a8b7-c2cea0be8074@github.com>
References: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
 <TYE1ieXypz7WiaTQRwU3Zp-ICrZ2E4SIo4meD-h14LU=.884eb3e0-04e2-4728-bfc5-57b072e809bf@github.com>
 <cx6Me6MA3QwpLr2y2avGx3-we6Ej3UHQHRD10Km76HU=.bdf6dc1e-c9f3-4695-9687-4ed9d044741d@github.com>
 <WAwoF5K4yWv40dWrX1VjUfeVGYy918KDHp4qvuRQ5xM=.2aa20484-2def-46dc-b20f-4e866748e048@github.com>
 <1enXmdMITwK96Lz35sCWmkob9sLgKKt1N2Lp0NSldNc=.81d72c1e-0f11-452d-a55a-674f775fee47@github.com>
 <bmgatRS3iZ6J35-pwQQ81ev8-lMBeyFcN6jzQFk_qno=.369060d2-3e1f-45c9-bad6-71bbc921b647@github.com>
 <c-DwcGAX3JX-gnQ0CWuGzI09K5SCdQ_yxnBP-q9HT1o=.903a2615-8255-4bbf-aaa3-2e9fb0ae84f5@github.com>
 <o3KeCSV9VoJrmFKEsfKPCJ0cnuYbZZcjY18qYWSXZns=.fc08ab1b-d6f3-4158-8291-63e2663c2992@github.com>
 <PjRWrB0x0vcYcQoa6EK62usvbNr_AFa_IN2ljCLrDDI=.4d69297c-6996-4cb7-9bd6-50f961c43686@github.com>
 <2E0F9OsixwTZ_Mq9OfUx1BQUStc92p0evM8KCbhz3jc=.18fd874c-f02a-406a-a8b7-c2cea0be8074@github.com>
Message-ID: <mCVfkxElPQgZzHyyDrGxQEEzhc16HGL0WhZYEIRBwgM=.6b0383ff-0928-4b07-8688-2d0835bbb1c7@github.com>

On Mon, 26 Feb 2024 20:07:35 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I use `das` every day. In contrast, I don't know what `das1` is for.
>
> It does not sound like anyone object to the removal of `JNIEXPORT` for `das1`, then.
> 
> Or should I just remove the entire function, if it serves no purpose that any current maintainers know or care about?

You can probably remove the entire function given it's an indirection to `das` anyway. I remember using it for debugging during the first stages of the Windows-AArch64 port but I've long forgotten about it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17967#discussion_r1504463486

From adinn at openjdk.org  Tue Feb 27 16:13:54 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 27 Feb 2024 16:13:54 GMT
Subject: RFR: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234 [v4]
In-Reply-To: <mCVfkxElPQgZzHyyDrGxQEEzhc16HGL0WhZYEIRBwgM=.6b0383ff-0928-4b07-8688-2d0835bbb1c7@github.com>
References: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
 <TYE1ieXypz7WiaTQRwU3Zp-ICrZ2E4SIo4meD-h14LU=.884eb3e0-04e2-4728-bfc5-57b072e809bf@github.com>
 <cx6Me6MA3QwpLr2y2avGx3-we6Ej3UHQHRD10Km76HU=.bdf6dc1e-c9f3-4695-9687-4ed9d044741d@github.com>
 <WAwoF5K4yWv40dWrX1VjUfeVGYy918KDHp4qvuRQ5xM=.2aa20484-2def-46dc-b20f-4e866748e048@github.com>
 <1enXmdMITwK96Lz35sCWmkob9sLgKKt1N2Lp0NSldNc=.81d72c1e-0f11-452d-a55a-674f775fee47@github.com>
 <bmgatRS3iZ6J35-pwQQ81ev8-lMBeyFcN6jzQFk_qno=.369060d2-3e1f-45c9-bad6-71bbc921b647@github.com>
 <c-DwcGAX3JX-gnQ0CWuGzI09K5SCdQ_yxnBP-q9HT1o=.903a2615-8255-4bbf-aaa3-2e9fb0ae84f5@github.com>
 <o3KeCSV9VoJrmFKEsfKPCJ0cnuYbZZcjY18qYWSXZns=.fc08ab1b-d6f3-4158-8291-63e2663c2992@github.com>
 <PjRWrB0x0vcYcQoa6EK62usvbNr_AFa_IN2ljCLrDDI=.4d69297c-6996-4cb7-9bd6-50f961c43686@github.com>
 <2E0F9OsixwTZ_Mq9OfUx1BQUStc92p0evM8KCbhz3jc=.18fd874c-f02a-406a-a8b7-c2cea0be8074@github.com>
 <mCVfkxElPQgZzHyyDrGxQEEzhc16HGL0WhZ
 YEIRBwgM=.6b0383ff-0928-4b07-8688-2d0835bbb1c7@github.com>
Message-ID: <yrrTlGniHMLv8PraqWDbFjX5EhBRDgihfAAWxKNYQxY=.31e527b0-2942-4ca8-a729-8bc3636178a8@github.com>

On Tue, 27 Feb 2024 15:35:56 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> It does not sound like anyone object to the removal of `JNIEXPORT` for `das1`, then.
>> 
>> Or should I just remove the entire function, if it serves no purpose that any current maintainers know or care about?
>
> You can probably remove the entire function given it's an indirection to `das` anyway. I remember using it for debugging during the first stages of the Windows-AArch64 port but I've long forgotten about it.

@luhenry @magicus das1 was added when we were implementing the AArch64 port in order to help us integrate the debugger support we provided when running JITted code on our AArch64 simulator into gdb. Now that we have real hardware it is redundant.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17967#discussion_r1504535787

From matsaave at openjdk.org  Tue Feb 27 18:56:54 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 27 Feb 2024 18:56:54 GMT
Subject: RFR: 8251330: Reorder CDS archived heap to speed up relocation
 [v3]
In-Reply-To: <ZesL5badknO18z5YBr0f1X7pYtMiSWHzKcRJuMfR5kM=.ef3bc428-2461-4501-a30e-e38980fcf5ad@github.com>
References: <ZesL5badknO18z5YBr0f1X7pYtMiSWHzKcRJuMfR5kM=.ef3bc428-2461-4501-a30e-e38980fcf5ad@github.com>
Message-ID: <6uHMnMrwR9Dt4Xp0At-TQ33KgTPyBzLbeUwclaFLphU=.c6073b32-130b-40d5-894f-b73f23477286@github.com>

> We should reorder the archived heap to segregate the objects that don't need marking. This will save space in the archive and improve start-up time
> 
> This patch reorders the archived heap to segregate the objects that don't need marking. The leading zeros present in the bitmaps thanks to the reordering can be easily removed, and this the size of the archive is reduced.
> 
> Given that the bitmaps are word aligned, some leading zeroes will remain. Verified with tier 1-5 tests.
> 
> Metrics, courtesy of @iklam :
> ```calculate_oopmap: objects = 15262 (507904 bytes, 332752 bytes don't need marking), embedded oops = 8408, nulls = 54
> Oopmap = 15872 bytes
> 
> calculate_oopmap: objects = 4590 (335872 bytes, 178120 bytes don't need marking), embedded oops = 46487, nulls = 29019
> Oopmap = 10496 bytes
> 
> (332752 + 178120) / (507904 + 335872.0) = 0.6054592688106796 
> More than 60% of the space used by the archived heap doesn't need to be marked by the oopmap. 
> 
> $ java -Xshare:dump -Xlog:cds+map | grep lead
> [3.777s][info][cds,map] - heap_oopmap_leading_zeros: 143286
> [3.777s][info][cds,map] - heap_ptrmap_leading_zeros: 50713
> 
> So we can reduce the "bm" region by (143286 + 50713) / 8 = 24249 bytes.
> 
> Current output:
> $ java -XX:+UseNewCode -Xshare:dump -Xlog:cds+map | grep lead 
> [5.339s][info][cds,map] - heap_oopmap_leading_zeros:      26
> [5.339s][info][cds,map] - heap_ptrmap_leading_zeros:      8

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  Renamed variables and moved pointer patching shift

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17350/files
  - new: https://git.openjdk.org/jdk/pull/17350/files/bb1409dd..411bc1a8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17350&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17350&range=01-02

  Stats: 42 lines in 6 files changed: 1 ins; 5 del; 36 mod
  Patch: https://git.openjdk.org/jdk/pull/17350.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17350/head:pull/17350

PR: https://git.openjdk.org/jdk/pull/17350

From lmesnik at openjdk.org  Tue Feb 27 19:00:56 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 27 Feb 2024 19:00:56 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v17]
In-Reply-To: <kEiNDWiDbyYABSPUVtj2IL1bDqJtpb_YX_zVNNwGZ5s=.1107a5ab-4ce3-44ba-ac5d-bb266dd696f0@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <kEiNDWiDbyYABSPUVtj2IL1bDqJtpb_YX_zVNNwGZ5s=.1107a5ab-4ce3-44ba-ac5d-bb266dd696f0@github.com>
Message-ID: <nQssnkQJ3Pcpztp2w9UBzAyUz82qgk09muZQRAB8NBk=.bf1c4243-d628-4cf0-bb43-3ace4f600958@github.com>

On Fri, 23 Feb 2024 18:40:10 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
>> The function returns the following structure:
>> 
>> 
>> typedef struct {
>>     jthread owner;
>>     jint entry_count;
>>     jint waiter_count;
>>     jthread* waiters;
>>     jint notify_waiter_count;
>>     jthread* notify_waiters;
>> } jvmtiMonitorUsage;
>> 
>> 
>> The following four fields are defined this way:
>> 
>> waiter_count  [jint] The number of threads waiting to own this monitor
>> waiters  [jthread*] The waiter_count waiting threads
>> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
>> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
>> 
>> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
>> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
>> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
>> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
>> This update makes it right.
>> 
>> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
>> 
>> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
>> 
>>   jvmti/GetObjectMonitorUsage/objmonusage001
>>   jvmti/GetObjectMonitorUsage/objmonusage003
>> 
>> 
>> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
>> 
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
>> 
>> 
>> 
>> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository.
>> 
>> Also, please see and review the related CSR:
>>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
>> 
>> The Release-Note is:
>> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage
>>  
>> Testing:
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix a typo in libObjectMonitorUsage.cpp

There is one comment about changing #define for thread.hpp.
The test changes look good for me. Thanks for converting the test from vmTetbase.

src/hotspot/share/runtime/threads.cpp line 1185:

> 1183: }
> 1184: 
> 1185: #if INCLUDE_JVMTI

Is it needed to update thread.hpp also?

-------------

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17680#pullrequestreview-1904467409
PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1504740367

From sspitsyn at openjdk.org  Tue Feb 27 19:11:57 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 27 Feb 2024 19:11:57 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v17]
In-Reply-To: <kEiNDWiDbyYABSPUVtj2IL1bDqJtpb_YX_zVNNwGZ5s=.1107a5ab-4ce3-44ba-ac5d-bb266dd696f0@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <kEiNDWiDbyYABSPUVtj2IL1bDqJtpb_YX_zVNNwGZ5s=.1107a5ab-4ce3-44ba-ac5d-bb266dd696f0@github.com>
Message-ID: <2ZAm5hDpXOpLEGvHIjd2MeM1CXuAf9Kh2wLeMkdHPms=.5ddc053e-54b9-4b7d-9a8a-5f2798617f21@github.com>

On Fri, 23 Feb 2024 18:40:10 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
>> The function returns the following structure:
>> 
>> 
>> typedef struct {
>>     jthread owner;
>>     jint entry_count;
>>     jint waiter_count;
>>     jthread* waiters;
>>     jint notify_waiter_count;
>>     jthread* notify_waiters;
>> } jvmtiMonitorUsage;
>> 
>> 
>> The following four fields are defined this way:
>> 
>> waiter_count  [jint] The number of threads waiting to own this monitor
>> waiters  [jthread*] The waiter_count waiting threads
>> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
>> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
>> 
>> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
>> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
>> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
>> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
>> This update makes it right.
>> 
>> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
>> 
>> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
>> 
>>   jvmti/GetObjectMonitorUsage/objmonusage001
>>   jvmti/GetObjectMonitorUsage/objmonusage003
>> 
>> 
>> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
>> 
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
>> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
>> 
>> 
>> 
>> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository.
>> 
>> Also, please see and review the related CSR:
>>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
>> 
>> The Release-Note is:
>> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage
>>  
>> Testing:
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix a typo in libObjectMonitorUsage.cpp

Thank you for review, Leonid!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17680#issuecomment-1967416721

From sspitsyn at openjdk.org  Tue Feb 27 19:11:57 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 27 Feb 2024 19:11:57 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v17]
In-Reply-To: <nQssnkQJ3Pcpztp2w9UBzAyUz82qgk09muZQRAB8NBk=.bf1c4243-d628-4cf0-bb43-3ace4f600958@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
 <kEiNDWiDbyYABSPUVtj2IL1bDqJtpb_YX_zVNNwGZ5s=.1107a5ab-4ce3-44ba-ac5d-bb266dd696f0@github.com>
 <nQssnkQJ3Pcpztp2w9UBzAyUz82qgk09muZQRAB8NBk=.bf1c4243-d628-4cf0-bb43-3ace4f600958@github.com>
Message-ID: <r4wqIzieAT8Mi7mjHCjbMsEMwS1KV-UmayILDVSyytQ=.082e64a5-8941-47f9-8625-8a86f7ba4814@github.com>

On Tue, 27 Feb 2024 18:24:04 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix a typo in libObjectMonitorUsage.cpp
>
> src/hotspot/share/runtime/threads.cpp line 1185:
> 
>> 1183: }
>> 1184: 
>> 1185: #if INCLUDE_JVMTI
> 
> Is it needed to update thread.hpp also?

Thank you for the comment, will check it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1504802182

From duke at openjdk.org  Tue Feb 27 19:13:56 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Tue, 27 Feb 2024 19:13:56 GMT
Subject: RFR: 8325991: Accelerate Poly1305 on x86_64 using AVX2
 instructions [v9]
In-Reply-To: <UjRcAmP61JeaSA1TNkF4Wqg-cN9QpJcpUzW0sh7kOic=.b2e4486f-9a15-49bb-865d-42f212b33475@github.com>
References: <IyoM1HY_rvNWwo4GxcV1yQleB3vrgaLwsAlOCEpLKqs=.1d50225c-8fe1-4a84-af56-274632b2b653@github.com>
 <UjRcAmP61JeaSA1TNkF4Wqg-cN9QpJcpUzW0sh7kOic=.b2e4486f-9a15-49bb-865d-42f212b33475@github.com>
Message-ID: <XktjVFhZ2DT0dLcJLz2DM2UNRIZEKPy9w1TMTc1Qz20=.c2419312-c266-4cd9-9087-6dfd0cb1681f@github.com>

On Fri, 23 Feb 2024 22:11:15 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> The goal of this PR is to accelerate the Poly1305 algorithm using AVX2 instructions (including IFMA) for x86_64 CPUs.
>> 
>> This implementation is directly based on the AVX2 Poly1305 hash computation as implemented in Intel(R) Multi-Buffer Crypto for IPsec Library (url: https://github.com/intel/intel-ipsec-mb/blob/main/lib/avx2_t3/poly_fma_avx2.asm)
>> 
>> This PR shows upto 19x speedup on buffer sizes of 1MB.
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add cpuinfo test for avx_ifma

src/hotspot/cpu/x86/stubGenerator_x86_64_poly.cpp line 1053:

> 1051: 
> 1052:   Let R be the 16-byte secret key used for polynomial evaluation.
> 1053:   Let K be the 16-byte secret AES key.

Poly1305 is not restricted to AES. Just remove AES (call it 'second part of the secret key' or something). 

Per RFC https://datatracker.ietf.org/doc/html/rfc7539#section-2.5

Poly1305 takes a 32-byte one-time key and a message and produces a 16-byte tag.
...
Regardless of how the key is generated, the key is partitioned into two parts, called "r" and "s".

test/lib-test/jdk/test/whitebox/CPUInfoTest.java line 68:

> 66:                     "hv",           "fsrm",             "avx512_bitalg",     "gfni",
> 67:                     "f16c",         "pku",              "ospke",             "cet_ibt",
> 68:                     "cet_ss",       "avx512_ifma",      "serialize",         "avx_ifma"

Wouldn't `avx2_ifma` be a better name since we already have `avx512_ifma`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17881#discussion_r1504737750
PR Review Comment: https://git.openjdk.org/jdk/pull/17881#discussion_r1504730588

From duke at openjdk.org  Tue Feb 27 21:00:54 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Tue, 27 Feb 2024 21:00:54 GMT
Subject: RFR: 8325991: Accelerate Poly1305 on x86_64 using AVX2
 instructions [v9]
In-Reply-To: <XktjVFhZ2DT0dLcJLz2DM2UNRIZEKPy9w1TMTc1Qz20=.c2419312-c266-4cd9-9087-6dfd0cb1681f@github.com>
References: <IyoM1HY_rvNWwo4GxcV1yQleB3vrgaLwsAlOCEpLKqs=.1d50225c-8fe1-4a84-af56-274632b2b653@github.com>
 <UjRcAmP61JeaSA1TNkF4Wqg-cN9QpJcpUzW0sh7kOic=.b2e4486f-9a15-49bb-865d-42f212b33475@github.com>
 <XktjVFhZ2DT0dLcJLz2DM2UNRIZEKPy9w1TMTc1Qz20=.c2419312-c266-4cd9-9087-6dfd0cb1681f@github.com>
Message-ID: <rsBLoqymUPIYCXzNXhDWbxK9dqGvJ_VFYVxKUFqECxY=.3aab2af1-0bea-4ded-b098-04e54c0c5488@github.com>

On Tue, 27 Feb 2024 18:15:10 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add cpuinfo test for avx_ifma
>
> test/lib-test/jdk/test/whitebox/CPUInfoTest.java line 68:
> 
>> 66:                     "hv",           "fsrm",             "avx512_bitalg",     "gfni",
>> 67:                     "f16c",         "pku",              "ospke",             "cet_ibt",
>> 68:                     "cet_ss",       "avx512_ifma",      "serialize",         "avx_ifma"
> 
> Wouldn't `avx2_ifma` be a better name since we already have `avx512_ifma`?

The Intel software manual refers to the feature as `avx_ifma`. Hence the same name is being used.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17881#discussion_r1504978312

From duke at openjdk.org  Tue Feb 27 21:13:07 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Tue, 27 Feb 2024 21:13:07 GMT
Subject: RFR: 8325991: Accelerate Poly1305 on x86_64 using AVX2
 instructions [v10]
In-Reply-To: <IyoM1HY_rvNWwo4GxcV1yQleB3vrgaLwsAlOCEpLKqs=.1d50225c-8fe1-4a84-af56-274632b2b653@github.com>
References: <IyoM1HY_rvNWwo4GxcV1yQleB3vrgaLwsAlOCEpLKqs=.1d50225c-8fe1-4a84-af56-274632b2b653@github.com>
Message-ID: <9_AS9fKLjyVQzybg1915BX3xVVFwJRKjsqghjZ99hr0=.13a55d69-fc86-4109-a3be-934d1b8634d0@github.com>

> The goal of this PR is to accelerate the Poly1305 algorithm using AVX2 instructions (including IFMA) for x86_64 CPUs.
> 
> This implementation is directly based on the AVX2 Poly1305 hash computation as implemented in Intel(R) Multi-Buffer Crypto for IPsec Library (url: https://github.com/intel/intel-ipsec-mb/blob/main/lib/avx2_t3/poly_fma_avx2.asm)
> 
> This PR shows upto 19x speedup on buffer sizes of 1MB.

Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:

  Update description of Poly1305 algo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17881/files
  - new: https://git.openjdk.org/jdk/pull/17881/files/16712108..b869d874

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17881&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17881&range=08-09

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17881.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17881/head:pull/17881

PR: https://git.openjdk.org/jdk/pull/17881

From duke at openjdk.org  Tue Feb 27 21:13:07 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Tue, 27 Feb 2024 21:13:07 GMT
Subject: RFR: 8325991: Accelerate Poly1305 on x86_64 using AVX2
 instructions [v9]
In-Reply-To: <XktjVFhZ2DT0dLcJLz2DM2UNRIZEKPy9w1TMTc1Qz20=.c2419312-c266-4cd9-9087-6dfd0cb1681f@github.com>
References: <IyoM1HY_rvNWwo4GxcV1yQleB3vrgaLwsAlOCEpLKqs=.1d50225c-8fe1-4a84-af56-274632b2b653@github.com>
 <UjRcAmP61JeaSA1TNkF4Wqg-cN9QpJcpUzW0sh7kOic=.b2e4486f-9a15-49bb-865d-42f212b33475@github.com>
 <XktjVFhZ2DT0dLcJLz2DM2UNRIZEKPy9w1TMTc1Qz20=.c2419312-c266-4cd9-9087-6dfd0cb1681f@github.com>
Message-ID: <zhrL0nJ9wOQBY53JAHnYo8CG3Y-l3F5rL6HHvHwhsoY=.c14a9544-c48b-4c81-a532-11f09411756d@github.com>

On Tue, 27 Feb 2024 18:21:42 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add cpuinfo test for avx_ifma
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_poly.cpp line 1053:
> 
>> 1051: 
>> 1052:   Let R be the 16-byte secret key used for polynomial evaluation.
>> 1053:   Let K be the 16-byte secret AES key.
> 
> Poly1305 is not restricted to AES. Just remove AES (call it 'second part of the secret key' or something). 
> 
> Per RFC https://datatracker.ietf.org/doc/html/rfc7539#section-2.5
> 
> Poly1305 takes a 32-byte one-time key and a message and produces a 16-byte tag.
> ...
> Regardless of how the key is generated, the key is partitioned into two parts, called "r" and "s".

Please see the updated description in the latest commit as suggested. 
Replicating the updated part below for convenience:


/*
Let the 32-byte one-time key be partitioned into two equal parts R and K.
Let R be the 16-byte secret key used for polynomial evaluation.
Let K be the 16-byte secret key.
*/

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17881#discussion_r1504994493

From iklam at openjdk.org  Tue Feb 27 21:14:54 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 27 Feb 2024 21:14:54 GMT
Subject: RFR: 8251330: Reorder CDS archived heap to speed up relocation
 [v3]
In-Reply-To: <6uHMnMrwR9Dt4Xp0At-TQ33KgTPyBzLbeUwclaFLphU=.c6073b32-130b-40d5-894f-b73f23477286@github.com>
References: <ZesL5badknO18z5YBr0f1X7pYtMiSWHzKcRJuMfR5kM=.ef3bc428-2461-4501-a30e-e38980fcf5ad@github.com>
 <6uHMnMrwR9Dt4Xp0At-TQ33KgTPyBzLbeUwclaFLphU=.c6073b32-130b-40d5-894f-b73f23477286@github.com>
Message-ID: <frYEXzsKVWWenloXdwdmT4W499Njbf2ctAd8GiYBMWE=.6203607d-598b-4723-81fe-3fa3fd18c418@github.com>

On Tue, 27 Feb 2024 18:56:54 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> We should reorder the archived heap to segregate the objects that don't need marking. This will save space in the archive and improve start-up time
>> 
>> This patch reorders the archived heap to segregate the objects that don't need marking. The leading zeros present in the bitmaps thanks to the reordering can be easily removed, and this the size of the archive is reduced.
>> 
>> Given that the bitmaps are word aligned, some leading zeroes will remain. Verified with tier 1-5 tests.
>> 
>> Metrics, courtesy of @iklam :
>> ```calculate_oopmap: objects = 15262 (507904 bytes, 332752 bytes don't need marking), embedded oops = 8408, nulls = 54
>> Oopmap = 15872 bytes
>> 
>> calculate_oopmap: objects = 4590 (335872 bytes, 178120 bytes don't need marking), embedded oops = 46487, nulls = 29019
>> Oopmap = 10496 bytes
>> 
>> (332752 + 178120) / (507904 + 335872.0) = 0.6054592688106796 
>> More than 60% of the space used by the archived heap doesn't need to be marked by the oopmap. 
>> 
>> $ java -Xshare:dump -Xlog:cds+map | grep lead
>> [3.777s][info][cds,map] - heap_oopmap_leading_zeros: 143286
>> [3.777s][info][cds,map] - heap_ptrmap_leading_zeros: 50713
>> 
>> So we can reduce the "bm" region by (143286 + 50713) / 8 = 24249 bytes.
>> 
>> Current output:
>> $ java -XX:+UseNewCode -Xshare:dump -Xlog:cds+map | grep lead 
>> [5.339s][info][cds,map] - heap_oopmap_leading_zeros:      26
>> [5.339s][info][cds,map] - heap_ptrmap_leading_zeros:      8
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Renamed variables and moved pointer patching shift

Looks good. I have some minor remarks for refactoring.

src/hotspot/share/cds/archiveHeapLoader.cpp line 167:

> 165:   // Optimization: if dumptime shift is the same as runtime shift, we can perform a
> 166:   // quick conversion from "dumptime narrowOop" -> "runtime narrowOop".
> 167:   narrowOop* patching_start = (narrowOop*)region.start() + MetaspaceShared::oopmap_start_pos();

I think there is no need to introduce a new `MetaspaceShared::oopmap_start_pos()` API. You can get this info from


FileMapInfo::current_info()->header()->heap_oopmap_start_pos()


The same thing can be done for `MetaspaceShared::ptrmap_start_pos()`

src/hotspot/share/cds/archiveHeapWriter.cpp line 638:

> 636:   BitMap::idx_t idx = requested_field_addr - (Metadata**) _requested_bottom;
> 637:   // Leading zeros have been removed so some addresses may not be in the ptrmap
> 638:   if (idx < MetaspaceShared::ptrmap_start_pos()) {

This is now the only place you need to know `ptrmap_start_pos` during dump time (at runtime you can get the info from `FileMapInfo::current_info()`). I think it's better to store `ptrmap_start_pos` as a static field in the `ArchiveHeapWriter` class instead.

src/hotspot/share/cds/filemap.cpp line 293:

> 291:   st->print_cr("- heap_roots_offset:              " SIZE_FORMAT, _heap_roots_offset);
> 292:   st->print_cr("- _heap_oopmap_start_pos:      " SIZE_FORMAT, _heap_oopmap_start_pos);
> 293:   st->print_cr("- _heap_ptrmap_start_pos:      " SIZE_FORMAT, _heap_ptrmap_start_pos);

Need two more spaces before SIZE_FORMAT for alignment?

src/hotspot/share/cds/filemap.cpp line 1582:

> 1580:   size_t removed_zeros = old_zeros - new_zeros;
> 1581: 
> 1582:   assert(new_zeros <= old_zeros, "Should have removed leading zeros");

Maybe add this comment above:

// The start of the archived heap has many primitive arrays (String
// bodies) that are not marked by the oop/ptr maps. So we must have
// lots of leading zeros.

-------------

Changes requested by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17350#pullrequestreview-1904653435
PR Review Comment: https://git.openjdk.org/jdk/pull/17350#discussion_r1504859078
PR Review Comment: https://git.openjdk.org/jdk/pull/17350#discussion_r1504992213
PR Review Comment: https://git.openjdk.org/jdk/pull/17350#discussion_r1504862102
PR Review Comment: https://git.openjdk.org/jdk/pull/17350#discussion_r1504979171

From ihse at openjdk.org  Tue Feb 27 21:46:17 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 27 Feb 2024 21:46:17 GMT
Subject: RFR: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234 [v5]
In-Reply-To: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
References: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
Message-ID: <ApQbL-hj7jaPj5WBhIdDXBVXrM5mBHpPtBmrlHG13K0=.225315ae-8d9b-4842-a78a-b87fe888a5e5@github.com>

> Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) has been integrated, it is possible to do some cleanup. The goal of [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) was to not change any behavior, even if that behavior seemed odd.
> 
> Now let's try to fix that. We can:
> 
> a) remove JNIEXPORT from c2v functions.
> b) make debug.cpp functions exported similarly on all platforms.
> c) remove JNIEXPORT from aarch64 asm debug function.
> 
> Note that this PR is [dependent on](https://mail.openjdk.org/pipermail/jdk-dev/2021-March/005232.html) https://github.com/openjdk/jdk/pull/17955.

Magnus Ihse Bursie has updated the pull request incrementally with three additional commits since the last revision:

 - Why did these creep back in? Merge error?
 - Remove #undef JNIEXPORT
 - Remove das1()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17967/files
  - new: https://git.openjdk.org/jdk/pull/17967/files/43c3513b..387d243b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17967&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17967&range=03-04

  Stats: 24 lines in 4 files changed: 0 ins; 24 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17967.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17967/head:pull/17967

PR: https://git.openjdk.org/jdk/pull/17967

From ihse at openjdk.org  Tue Feb 27 21:46:18 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 27 Feb 2024 21:46:18 GMT
Subject: RFR: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234 [v4]
In-Reply-To: <wHGBIhPuYhFHpOmp-pckQClVnS4sODTqkZHqNbI5tB4=.cd8f6adb-14a4-4160-92cc-41e7b871ad2d@github.com>
References: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
 <wHGBIhPuYhFHpOmp-pckQClVnS4sODTqkZHqNbI5tB4=.cd8f6adb-14a4-4160-92cc-41e7b871ad2d@github.com>
Message-ID: <kK6vY0FUvUZkS0C34eTiBBYXYSe0xfpxyelXw8ZRVZ4=.2975cf18-696c-4955-9431-efbd9b5e93b1@github.com>

On Tue, 27 Feb 2024 11:01:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) has been integrated, it is possible to do some cleanup. The goal of [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) was to not change any behavior, even if that behavior seemed odd.
>> 
>> Now let's try to fix that. We can:
>> 
>> a) remove JNIEXPORT from c2v functions.
>> b) make debug.cpp functions exported similarly on all platforms.
>> c) remove JNIEXPORT from aarch64 asm debug function.
>> 
>> Note that this PR is [dependent on](https://mail.openjdk.org/pipermail/jdk-dev/2021-March/005232.html) https://github.com/openjdk/jdk/pull/17955.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge branch 'master' into hotspot-symbols-followup
>  - Remove jvmci globals
>  - 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234
>  - Revert "Use #pragma instead of HIDDEN define"
>    
>    This reverts commit 00e40a7f6e4cdef6592d72b3d08063cdcc41532a.
>  - Use #pragma instead of HIDDEN define
>  - Rename the version script to version-script.txt
>  - Restore linker script to linux/gcc builds
>  - Rename the Windows export file to .def
>  - Remove unused symbol _Copy_conjoint_bytes on linux/arm32
>  - 8017234: Hotspot should stop using mapfiles

There was a bit back and forth with this PR, but now I believe it is finally ready. Any reviewers?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17967#issuecomment-1967657651

From ihse at openjdk.org  Tue Feb 27 21:46:18 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 27 Feb 2024 21:46:18 GMT
Subject: RFR: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234 [v5]
In-Reply-To: <yrrTlGniHMLv8PraqWDbFjX5EhBRDgihfAAWxKNYQxY=.31e527b0-2942-4ca8-a729-8bc3636178a8@github.com>
References: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
 <TYE1ieXypz7WiaTQRwU3Zp-ICrZ2E4SIo4meD-h14LU=.884eb3e0-04e2-4728-bfc5-57b072e809bf@github.com>
 <cx6Me6MA3QwpLr2y2avGx3-we6Ej3UHQHRD10Km76HU=.bdf6dc1e-c9f3-4695-9687-4ed9d044741d@github.com>
 <WAwoF5K4yWv40dWrX1VjUfeVGYy918KDHp4qvuRQ5xM=.2aa20484-2def-46dc-b20f-4e866748e048@github.com>
 <1enXmdMITwK96Lz35sCWmkob9sLgKKt1N2Lp0NSldNc=.81d72c1e-0f11-452d-a55a-674f775fee47@github.com>
 <bmgatRS3iZ6J35-pwQQ81ev8-lMBeyFcN6jzQFk_qno=.369060d2-3e1f-45c9-bad6-71bbc921b647@github.com>
 <c-DwcGAX3JX-gnQ0CWuGzI09K5SCdQ_yxnBP-q9HT1o=.903a2615-8255-4bbf-aaa3-2e9fb0ae84f5@github.com>
 <o3KeCSV9VoJrmFKEsfKPCJ0cnuYbZZcjY18qYWSXZns=.fc08ab1b-d6f3-4158-8291-63e2663c2992@github.com>
 <PjRWrB0x0vcYcQoa6EK62usvbNr_AFa_IN2ljCLrDDI=.4d69297c-6996-4cb7-9bd6-50f961c43686@github.com>
 <2E0F9OsixwTZ_Mq9OfUx1BQUStc92p0evM8KCbhz3jc=.18fd874c-f02a-406a-a8b7-c2cea0be8074@github.com>
 <mCVfkxElPQgZzHyyDrGxQEEzhc16HGL0WhZ
 YEIRBwgM=.6b0383ff-0928-4b07-8688-2d0835bbb1c7@github.com>
 <yrrTlGniHMLv8PraqWDbFjX5EhBRDgihfAAWxKNYQxY=.31e527b0-2942-4ca8-a729-8bc3636178a8@github.com>
Message-ID: <5boFfR3_uytbIyM1w3SrApZ76sHIJmmfgKdeK4mWqNY=.5e299d88-0fb9-4d57-bbd7-f01a12bc651e@github.com>

On Tue, 27 Feb 2024 16:11:34 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> You can probably remove the entire function given it's an indirection to `das` anyway. I remember using it for debugging during the first stages of the Windows-AArch64 port but I've long forgotten about it.
>
> @luhenry @magicus das1 was added when we were implementing the AArch64 port in order to help us integrate the debugger support we provided when running JITted code on our AArch64 simulator into gdb. Now that we have real hardware it is redundant.

Thanks @adinn for the confirmation! I've now removed it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17967#discussion_r1505045060

From bstafford at openjdk.org  Tue Feb 27 22:06:52 2024
From: bstafford at openjdk.org (Brian Stafford)
Date: Tue, 27 Feb 2024 22:06:52 GMT
Subject: RFR: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234 [v5]
In-Reply-To: <bmgatRS3iZ6J35-pwQQ81ev8-lMBeyFcN6jzQFk_qno=.369060d2-3e1f-45c9-bad6-71bbc921b647@github.com>
References: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
 <TYE1ieXypz7WiaTQRwU3Zp-ICrZ2E4SIo4meD-h14LU=.884eb3e0-04e2-4728-bfc5-57b072e809bf@github.com>
 <cx6Me6MA3QwpLr2y2avGx3-we6Ej3UHQHRD10Km76HU=.bdf6dc1e-c9f3-4695-9687-4ed9d044741d@github.com>
 <WAwoF5K4yWv40dWrX1VjUfeVGYy918KDHp4qvuRQ5xM=.2aa20484-2def-46dc-b20f-4e866748e048@github.com>
 <1enXmdMITwK96Lz35sCWmkob9sLgKKt1N2Lp0NSldNc=.81d72c1e-0f11-452d-a55a-674f775fee47@github.com>
 <bmgatRS3iZ6J35-pwQQ81ev8-lMBeyFcN6jzQFk_qno=.369060d2-3e1f-45c9-bad6-71bbc921b647@github.com>
Message-ID: <lgop3BvNeg0qlKvQhqL01frqudmgOUU__Onz8HjNf_Q=.7d572f20-0e18-4ef9-b6ee-1bd07c9c27a6@github.com>

On Fri, 23 Feb 2024 12:03:37 GMT, Bernhard Urban-Forster <burban at openjdk.org> wrote:

>> Instead of discussing removal of windows/aarch64 (although the general rule in OpenJDK is that ports that are not maintained by anyone should be removed); let's stick to the question here: do we need to export `das1()` for debugging?
>
> Personally I have never used `das`/`das1` on any AArch64 port when debugging.  I guess it was somewhat handy when the backend was originally developed.  I would argue that the built-in disassembler of any debugger and `disnm` from `debug.cpp` are good enough, and thus `das`/`das1` can be removed.  What do you think @theRealAph ?

Removal makes sense - thank you @lewurm, @luhenry, and @adinn for your input!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17967#discussion_r1505070224

From kbarrett at openjdk.org  Wed Feb 28 01:24:41 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 28 Feb 2024 01:24:41 GMT
Subject: RFR: 8324799: Use correct extension for C++ test headers
Message-ID: <zacvqoEa_wLnC3CvPWKN2c2AR1yq_p72pUsLQLyzqTM=.05089090-fa08-4362-9a85-762716ca6132@github.com>

Please review this change that renames some test .h files to .hpp.  These
files contain C++ code and should be named accordingly.  Some of them contain
uses of NULL, which we change to nullptr.

The renamed files are:

test/hotspot/jtreg/vmTestbase/nsk/share/aod/aod.h
test/hotspot/jtreg/vmTestbase/nsk/share/jni/jni_tools.h  
test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.h
test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/JVMTITools.h
test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_tools.h 

test/lib/jdk/test/lib/jvmti/jvmti_thread.h
test/lib/jdk/test/lib/jvmti/jvmti_common.h
test/lib/native/testlib_threads.h 

The #include updates were performed mostly mechanically, and builds would fail
if there were mistakes.  The exception is test
test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp,
which was added after I'd done the mechanical update, so was updated by hand.

The copyright updates were similarly performed mechanically. All but a handful
of the including files have already had their copyrights updated recently,
likely as part of JDK-8324681.

Thus, the only "interesting" changes are to the renamed files.

Testing: mach5 tier1

-------------

Commit messages:
 - update new test
 - update copyrights
 - fix jvmti README
 - rename NULLs in jvmti_common.hpp
 - rename jvmti_common.h
 - rename NULLs in jvmti_thread.hpp
 - rename jvmti_thread.h
 - rename NULLs in testlib_threads.hpp
 - rename testlib_threads.h -- no copyright
 - rename nsk_tools.h -- no copyright
 - ... and 5 more: https://git.openjdk.org/jdk/compare/16d917a8...4154005e

Changes: https://git.openjdk.org/jdk/pull/18035/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18035&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8324799
  Stats: 1535 lines in 731 files changed: 133 ins; 133 del; 1269 mod
  Patch: https://git.openjdk.org/jdk/pull/18035.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18035/head:pull/18035

PR: https://git.openjdk.org/jdk/pull/18035

From dholmes at openjdk.org  Wed Feb 28 02:56:52 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 28 Feb 2024 02:56:52 GMT
Subject: RFR: 8318302: ThreadCountLimit.java failed with
 "Native memory allocation (mprotect) failed to protect 16384 bytes for memory
 to guard stack pages" [v3]
In-Reply-To: <98Z3mMnDM6NuPlwduJ0MN9KnlP7NYdIxqXikHZE5JuE=.973a703f-9bf0-437f-93ab-ac01f385b824@github.com>
References: <owqAt1_7CSCVlCen_Lp7b3q1jMSjsU-D2SKq5ciBDgo=.1ec82f53-23b1-477d-887c-280b3721a505@github.com>
 <98Z3mMnDM6NuPlwduJ0MN9KnlP7NYdIxqXikHZE5JuE=.973a703f-9bf0-437f-93ab-ac01f385b824@github.com>
Message-ID: <cTCz33a8SBGkTRYinWc74kwjfoc_T0g0Vx_zAw8jK6g=.a4fe5ef9-0fc2-4846-86f2-28eb12ec675f@github.com>

On Thu, 22 Feb 2024 09:13:19 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Style nit
>
> test/hotspot/jtreg/runtime/Thread/ThreadCountLimit.java line 82:
> 
>> 80:         String java_cmd = ProcessTools.getCommandLine(pb);
>> 81:         // Relaunch the test with args.length > 0, and the ulimit set
>> 82:         ProcessTools.executeCommand("bash", "-c", ULIMIT_CMD + " && " + java_cmd + " dummy")
> 
> I think this assumes `bash` is installed, which is true 99% of the time, but not actually guaranteed. Maybe we should check `if (Platform.isLinux() && new File("/bin/bash").exists())` explicitly.

@shipilev do you want this explored further?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17959#discussion_r1505266285

From dholmes at openjdk.org  Wed Feb 28 04:09:44 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 28 Feb 2024 04:09:44 GMT
Subject: RFR: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234 [v5]
In-Reply-To: <ApQbL-hj7jaPj5WBhIdDXBVXrM5mBHpPtBmrlHG13K0=.225315ae-8d9b-4842-a78a-b87fe888a5e5@github.com>
References: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
 <ApQbL-hj7jaPj5WBhIdDXBVXrM5mBHpPtBmrlHG13K0=.225315ae-8d9b-4842-a78a-b87fe888a5e5@github.com>
Message-ID: <YESDVVEaRi5rh5AjG8aFPF3hexsOyeEBX9wkP5vFGew=.24e174c8-d905-4177-af14-9d64a4985bd6@github.com>

On Tue, 27 Feb 2024 21:46:17 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) has been integrated, it is possible to do some cleanup. The goal of [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) was to not change any behavior, even if that behavior seemed odd.
>> 
>> Now let's try to fix that. We can:
>> 
>> a) remove JNIEXPORT from c2v functions.
>> b) make debug.cpp functions exported similarly on all platforms.
>> c) remove JNIEXPORT from aarch64 asm debug function.
>> 
>> Note that this PR is [dependent on](https://mail.openjdk.org/pipermail/jdk-dev/2021-March/005232.html) https://github.com/openjdk/jdk/pull/17955.
>
> Magnus Ihse Bursie has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Why did these creep back in? Merge error?
>  - Remove #undef JNIEXPORT
>  - Remove das1()

Seems fine to me. Thanks.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17967#pullrequestreview-1905265100

From fyang at openjdk.org  Wed Feb 28 05:03:53 2024
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 28 Feb 2024 05:03:53 GMT
Subject: RFR: 8320646: RISC-V: C2 VectorCastHF2F [v2]
In-Reply-To: <ZwaoSyFg4BXYEZlZHnJ1rx6vdt8xAWzV4XQXRDriR5U=.47567d13-6df9-452c-baac-d376c1830df0@github.com>
References: <kqLQR-bD3v7iF7LgH0PzwIH_m6QH_2b371pKz9_Ovq8=.9c07c165-2a97-4a6b-9e82-6a6de0b81328@github.com>
 <fTvkUqcIsICvOIRWhqcICR8OYfaiOsOgSoaJsgUUm94=.09bb33c2-ce00-4943-bed0-0a1906395ee4@github.com>
 <k_9SAB2dNMVxzI5kc2Hd_7Nou8CvA998lE1WJTkphhY=.3f85f4e9-5a40-40be-9c6d-4db89a42c182@github.com>
 <ZwaoSyFg4BXYEZlZHnJ1rx6vdt8xAWzV4XQXRDriR5U=.47567d13-6df9-452c-baac-d376c1830df0@github.com>
Message-ID: <8OQQo7cqVshZlOmFeWCLp_VrD3rizjsPDU4a1kGxokc=.75d8279c-ae2f-42fc-89e7-ccebb826e142@github.com>

On Tue, 27 Feb 2024 14:46:23 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

> We still want to give end users the ability to disable extensions if things are broken. The flags would be the only way if we rely on hwprobe + vendor specific flags (like 

That make sense to me. In the long run, we should depend on hwprobe + vendor specific code to auto-enable or disable certain RV extensions on certain hardwares. But I agree on that there should be some options of `DIAGNOSTIC` kind to help diagnose issues and find workarounds. I am OK to make this option an `EXPERIMENTAL` one at the current stage. But we should turn them into the `DIAGNOSTIC` kind in the future when we have the hardwares and hwprobe is capable to satisfy our needs. Mind you, we are lacking one option for https://github.com/openjdk/jdk/pull/17122 in that respect. Let me know if you going to add one.

> https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp#L232-L260, and which I'm surprised not more hw vendors have added their own)

That will depend on the vendors. Given that the current RV hardwares are not that rich in RV extensions, I guess there isn't much to tune.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17698#discussion_r1505364098

From jwaters at openjdk.org  Wed Feb 28 05:30:51 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 28 Feb 2024 05:30:51 GMT
Subject: RFR: 8324799: Use correct extension for C++ test headers
In-Reply-To: <zacvqoEa_wLnC3CvPWKN2c2AR1yq_p72pUsLQLyzqTM=.05089090-fa08-4362-9a85-762716ca6132@github.com>
References: <zacvqoEa_wLnC3CvPWKN2c2AR1yq_p72pUsLQLyzqTM=.05089090-fa08-4362-9a85-762716ca6132@github.com>
Message-ID: <I8kBIFk3pEjMhSjj2Da_GpSp3ab8fhK_sfyA5sYLOik=.3880cee2-6878-4e48-af63-f8708cfe1ce0@github.com>

On Wed, 28 Feb 2024 01:18:50 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that renames some test .h files to .hpp.  These
> files contain C++ code and should be named accordingly.  Some of them contain
> uses of NULL, which we change to nullptr.
> 
> The renamed files are:
> 
> test/hotspot/jtreg/vmTestbase/nsk/share/aod/aod.h
> test/hotspot/jtreg/vmTestbase/nsk/share/jni/jni_tools.h  
> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.h
> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/JVMTITools.h
> test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_tools.h 
> 
> test/lib/jdk/test/lib/jvmti/jvmti_thread.h
> test/lib/jdk/test/lib/jvmti/jvmti_common.h
> test/lib/native/testlib_threads.h 
> 
> The #include updates were performed mostly mechanically, and builds would fail
> if there were mistakes.  The exception is test
> test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp,
> which was added after I'd done the mechanical update, so was updated by hand.
> 
> The copyright updates were similarly performed mechanically. All but a handful
> of the including files have already had their copyrights updated recently,
> likely as part of JDK-8324681.
> 
> Thus, the only "interesting" changes are to the renamed files.
> 
> Testing: mach5 tier1

Was a blast looking through all 729 files, but have a +1

-------------

Marked as reviewed by jwaters (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18035#pullrequestreview-1905352841

From djelinski at openjdk.org  Wed Feb 28 05:46:53 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 28 Feb 2024 05:46:53 GMT
Subject: RFR: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234 [v5]
In-Reply-To: <ApQbL-hj7jaPj5WBhIdDXBVXrM5mBHpPtBmrlHG13K0=.225315ae-8d9b-4842-a78a-b87fe888a5e5@github.com>
References: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
 <ApQbL-hj7jaPj5WBhIdDXBVXrM5mBHpPtBmrlHG13K0=.225315ae-8d9b-4842-a78a-b87fe888a5e5@github.com>
Message-ID: <0kCemyTCfBScy9elbcKjZ_yfYDp6ZjXeo9L60tN0E6k=.36d1a7ae-f2e0-47ed-9de9-4c240a558324@github.com>

On Tue, 27 Feb 2024 21:46:17 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) has been integrated, it is possible to do some cleanup. The goal of [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) was to not change any behavior, even if that behavior seemed odd.
>> 
>> Now let's try to fix that. We can:
>> 
>> a) remove JNIEXPORT from c2v functions.
>> b) make debug.cpp functions exported similarly on all platforms.
>> c) remove JNIEXPORT from aarch64 asm debug function.
>> 
>> Note that this PR is [dependent on](https://mail.openjdk.org/pipermail/jdk-dev/2021-March/005232.html) https://github.com/openjdk/jdk/pull/17955.
>
> Magnus Ihse Bursie has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Why did these creep back in? Merge error?
>  - Remove #undef JNIEXPORT
>  - Remove das1()

Marked as reviewed by djelinski (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17967#pullrequestreview-1905367506

From gli at openjdk.org  Wed Feb 28 06:17:53 2024
From: gli at openjdk.org (Guoxiong Li)
Date: Wed, 28 Feb 2024 06:17:53 GMT
Subject: RFR: 8324799: Use correct extension for C++ test headers
In-Reply-To: <zacvqoEa_wLnC3CvPWKN2c2AR1yq_p72pUsLQLyzqTM=.05089090-fa08-4362-9a85-762716ca6132@github.com>
References: <zacvqoEa_wLnC3CvPWKN2c2AR1yq_p72pUsLQLyzqTM=.05089090-fa08-4362-9a85-762716ca6132@github.com>
Message-ID: <vw8vW3c2IjGmu0FDwA99y7bcnH7RwHvzP2XEookoCRo=.81ddab9d-4bc0-4ace-97ce-c529b214547b@github.com>

On Wed, 28 Feb 2024 01:18:50 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that renames some test .h files to .hpp.  These
> files contain C++ code and should be named accordingly.  Some of them contain
> uses of NULL, which we change to nullptr.
> 
> The renamed files are:
> 
> test/hotspot/jtreg/vmTestbase/nsk/share/aod/aod.h
> test/hotspot/jtreg/vmTestbase/nsk/share/jni/jni_tools.h  
> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.h
> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/JVMTITools.h
> test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_tools.h 
> 
> test/lib/jdk/test/lib/jvmti/jvmti_thread.h
> test/lib/jdk/test/lib/jvmti/jvmti_common.h
> test/lib/native/testlib_threads.h 
> 
> The #include updates were performed mostly mechanically, and builds would fail
> if there were mistakes.  The exception is test
> test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp,
> which was added after I'd done the mechanical update, so was updated by hand.
> 
> The copyright updates were similarly performed mechanically. All but a handful
> of the including files have already had their copyrights updated recently,
> likely as part of JDK-8324681.
> 
> Thus, the only "interesting" changes are to the renamed files.
> 
> Testing: mach5 tier1

So large patch. In order to easy to review, it is good to separate such large patch into several patches in the future.

Two trivial places need to be adjusted.

test/hotspot/jtreg/serviceability/jvmti/events/SingleStep/singlestep01/libsinglestep01.cpp line 28:

> 26: #include <string.h>
> 27: #include <jvmti.h>
> 28: #include "jvmti_common.hpp"

The copyright of this file is wrong.

>  * Copyright (c) 200
>  * git 3, 2022, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

test/hotspot/jtreg/serviceability/jvmti/thread/GetStackTrace/GetStackTraceAndRetransformTest/libGetStackTraceAndRetransformTest.cpp line 27:

> 25: #include <string.h>
> 26: #include "jvmti.h"
> 27: #include "jvmti_common.hpp"

The oracle copyright needs to be added in this file?

>  * Copyright (c) 2023, Datadog, Inc. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

-------------

Changes requested by gli (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18035#pullrequestreview-1905259144
PR Review Comment: https://git.openjdk.org/jdk/pull/18035#discussion_r1505322535
PR Review Comment: https://git.openjdk.org/jdk/pull/18035#discussion_r1505326445

From kbarrett at openjdk.org  Wed Feb 28 07:06:57 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 28 Feb 2024 07:06:57 GMT
Subject: RFR: 8324799: Use correct extension for C++ test headers
In-Reply-To: <vw8vW3c2IjGmu0FDwA99y7bcnH7RwHvzP2XEookoCRo=.81ddab9d-4bc0-4ace-97ce-c529b214547b@github.com>
References: <zacvqoEa_wLnC3CvPWKN2c2AR1yq_p72pUsLQLyzqTM=.05089090-fa08-4362-9a85-762716ca6132@github.com>
 <vw8vW3c2IjGmu0FDwA99y7bcnH7RwHvzP2XEookoCRo=.81ddab9d-4bc0-4ace-97ce-c529b214547b@github.com>
Message-ID: <6HffreZJ4swcv8-9QavfrV6On578RKqBPK1Ci9DK91g=.13a46a7c-90af-4b27-b150-5f4dc9731b0d@github.com>

On Wed, 28 Feb 2024 06:12:17 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> So large patch. In order to easy to review, it is good to separate such large patch into several patches in the future.

I was doing that in prior related changes (see the subtasks of JDK-8324799).  But reviewers requested I batch up
the remainder, hence this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18035#issuecomment-1968355666

From shade at openjdk.org  Wed Feb 28 08:03:53 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 28 Feb 2024 08:03:53 GMT
Subject: RFR: 8318302: ThreadCountLimit.java failed with
 "Native memory allocation (mprotect) failed to protect 16384 bytes for memory
 to guard stack pages" [v3]
In-Reply-To: <cTCz33a8SBGkTRYinWc74kwjfoc_T0g0Vx_zAw8jK6g=.a4fe5ef9-0fc2-4846-86f2-28eb12ec675f@github.com>
References: <owqAt1_7CSCVlCen_Lp7b3q1jMSjsU-D2SKq5ciBDgo=.1ec82f53-23b1-477d-887c-280b3721a505@github.com>
 <98Z3mMnDM6NuPlwduJ0MN9KnlP7NYdIxqXikHZE5JuE=.973a703f-9bf0-437f-93ab-ac01f385b824@github.com>
 <cTCz33a8SBGkTRYinWc74kwjfoc_T0g0Vx_zAw8jK6g=.a4fe5ef9-0fc2-4846-86f2-28eb12ec675f@github.com>
Message-ID: <ueD_NcXZtkV7AkavgCwPIuvskfsB9o8bXhUQAkTHc3U=.700eafe1-41c7-429c-89e2-f90011efef40@github.com>

On Wed, 28 Feb 2024 02:53:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> test/hotspot/jtreg/runtime/Thread/ThreadCountLimit.java line 82:
>> 
>>> 80:         String java_cmd = ProcessTools.getCommandLine(pb);
>>> 81:         // Relaunch the test with args.length > 0, and the ulimit set
>>> 82:         ProcessTools.executeCommand("bash", "-c", ULIMIT_CMD + " && " + java_cmd + " dummy")
>> 
>> I think this assumes `bash` is installed, which is true 99% of the time, but not actually guaranteed. Maybe we should check `if (Platform.isLinux() && new File("/bin/bash").exists())` explicitly.
>
> @shipilev do you want this explored further?

Not really. We can fix the test if bash-ism manifests as the problem.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17959#discussion_r1505511170

From ihse at openjdk.org  Wed Feb 28 10:35:56 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 28 Feb 2024 10:35:56 GMT
Subject: Integrated: 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234
In-Reply-To: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
References: <yyaXndCgrwQMWAuByS31e3S9msxbn5Ev6i1TETwmNSE=.d3e29ec9-5efe-4a2c-923f-11eede03c15e@github.com>
Message-ID: <AnciZWb0ft7evyF3yrQwUzMHaottyN5slfMiJQg2LzA=.88eca899-fb1d-4d4d-8c87-42edb71c3a79@github.com>

On Thu, 22 Feb 2024 16:28:20 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) has been integrated, it is possible to do some cleanup. The goal of [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) was to not change any behavior, even if that behavior seemed odd.
> 
> Now let's try to fix that. We can:
> 
> a) remove JNIEXPORT from c2v functions.
> b) make debug.cpp functions exported similarly on all platforms.
> c) remove JNIEXPORT from aarch64 asm debug function.
> 
> Note that this PR is [dependent on](https://mail.openjdk.org/pipermail/jdk-dev/2021-March/005232.html) https://github.com/openjdk/jdk/pull/17955.

This pull request has now been integrated.

Changeset: e6b3bda2
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e6b3bda2c30ea7932a8a20027e1ef2e805610f14
Stats:     35 lines in 4 files changed: 0 ins; 32 del; 3 mod

8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234

Reviewed-by: djelinski, jwaters, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/17967

From gcao at openjdk.org  Wed Feb 28 12:04:20 2024
From: gcao at openjdk.org (Gui Cao)
Date: Wed, 28 Feb 2024 12:04:20 GMT
Subject: RFR: 8319900: Recursive lightweight locking: riscv64
 implementation [v3]
In-Reply-To: <OJTtw2p54KDzlRMC2qeNNHpodtRBRdA_4wvPxYfSX4Q=.76bf740b-d1ed-4586-8175-e759c13ca12b@github.com>
References: <OJTtw2p54KDzlRMC2qeNNHpodtRBRdA_4wvPxYfSX4Q=.76bf740b-d1ed-4586-8175-e759c13ca12b@github.com>
Message-ID: <CFIlBx20s8IUonoSpz6cmkqewNxPNDOo_yB6Lq4nVlE=.6161f1c7-2f77-4837-b269-36acb4faea82@github.com>

> Implementation of recursive lightweight JDK-8319796 for linux-riscv64.
> 
> ### Correctness testing:
> 
> - [x]  Run tier1-3, hotspot:tier4 tests with -XX:LockingMode=1 & -XX:LockingMode=2 on LicheePI 4A (release)
> - [x]  Run tier1-3 tests with -XX:LockingMode=1 & -XX:LockingMode=2 on qemu 8.1.0 (fastdebug)
> 
> ### JMH tested on LicheePI 4A:
> 
> 
> Before (LockingMode = 2):
> 
> Benchmark                                (innerCount)  Mode  Cnt       Score      Error  Units
> LockUnlock.testContendedLock                      100  avgt   12     281.603 ?    2.626  ns/op
> LockUnlock.testRecursiveLockUnlock                100  avgt   12  196373.917 ? 4669.241  ns/op
> LockUnlock.testRecursiveSynchronization           100  avgt   12     274.492 ?    6.049  ns/op
> LockUnlock.testSerialLockUnlock                   100  avgt   12   11516.092 ?   69.964  ns/op
> LockUnlock.testSimpleLockUnlock                   100  avgt   12   11490.789 ?   58.833  ns/op
> 
> After (LockingMode = 2):
> 
> Benchmark                                (innerCount)  Mode  Cnt      Score    Error  Units
> LockUnlock.testContendedLock                      100  avgt   12    307.013 ?  3.259  ns/op
> LockUnlock.testRecursiveLockUnlock                100  avgt   12  59047.222 ? 94.748  ns/op
> LockUnlock.testRecursiveSynchronization           100  avgt   12    259.789 ?  1.698  ns/op
> LockUnlock.testSerialLockUnlock                   100  avgt   12   6055.775 ? 13.518  ns/op
> LockUnlock.testSimpleLockUnlock                   100  avgt   12   6090.986 ? 67.179  ns/op
> 
> 
> 
> Before (LockingMode = 1):
> 
> Benchmark                                (innerCount)  Mode  Cnt      Score     Error  Units
> LockUnlock.testContendedLock                      100  avgt   12    286.144 ?   2.490  ns/op
> LockUnlock.testRecursiveLockUnlock                100  avgt   12  68058.259 ? 286.262  ns/op
> LockUnlock.testRecursiveSynchronization           100  avgt   12    263.132 ?   4.075  ns/op
> LockUnlock.testSerialLockUnlock                   100  avgt   12   7521.777 ?  35.193  ns/op
> LockUnlock.testSimpleLockUnlock                   100  avgt   12   7522.480 ?  26.310  ns/op
> 
> After (LockingMode = 1):
> 
> Benchmark                                (innerCount)  Mode  Cnt      Score     Error  Units
> LockUnlock.testContendedLock                      100  avgt   12    289.034 ?   5.821  ns/op
> LockUnlock.testRecursiveLockUnlock                100  avgt   12  68474.370 ? 495.135  ns/op
> LockUnlock.testRecursiveSynchronization           100  avgt   12    261.052 ?   4.560  ns/op
> Loc...

Gui Cao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into JDK-8319900
 - fix comment typo
 - Merge branch 'master' into JDK-8319900
 - improve code
 - Polish code comment
 - 8319900: Recursive lightweight locking: riscv64 implementation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17554/files
  - new: https://git.openjdk.org/jdk/pull/17554/files/fc104a38..34acbb27

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17554&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17554&range=01-02

  Stats: 7249 lines in 811 files changed: 3948 ins; 1594 del; 1707 mod
  Patch: https://git.openjdk.org/jdk/pull/17554.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17554/head:pull/17554

PR: https://git.openjdk.org/jdk/pull/17554

From mli at openjdk.org  Wed Feb 28 14:19:06 2024
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 28 Feb 2024 14:19:06 GMT
Subject: RFR: 8320646: RISC-V: C2 VectorCastHF2F [v3]
In-Reply-To: <kqLQR-bD3v7iF7LgH0PzwIH_m6QH_2b371pKz9_Ovq8=.9c07c165-2a97-4a6b-9e82-6a6de0b81328@github.com>
References: <kqLQR-bD3v7iF7LgH0PzwIH_m6QH_2b371pKz9_Ovq8=.9c07c165-2a97-4a6b-9e82-6a6de0b81328@github.com>
Message-ID: <PVlTLryK6cYu387i2EZ5wu-3ojkPSj4r1Fzqk1zBfc4=.9395a587-348f-472a-a2d6-1434f4b10060@github.com>

> Hi,
> Can you review this patch to add instrinsics for VectorCastHF2F/VectorCastF2HF?
> Thanks!
> 
> ## Test
> 
> test/jdk/java/lang/Float/Binary16ConversionNaN.java
> test/jdk/java/lang/Float/Binary16Conversion.java
> 
> hotspot/jtreg/compiler/intrinsics/float16
> hotspot/jtreg/compiler/vectorization/TestFloatConversionsVectorjava
> hotspot/jtreg/compiler/vectorization/TestFloatConversionsVectorNaN.java

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  make UseZvfh experimatal; clean code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17698/files
  - new: https://git.openjdk.org/jdk/pull/17698/files/5964bb60..0dce1573

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17698&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17698&range=01-02

  Stats: 5 lines in 2 files changed: 0 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/17698.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17698/head:pull/17698

PR: https://git.openjdk.org/jdk/pull/17698

From mli at openjdk.org  Wed Feb 28 14:19:06 2024
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 28 Feb 2024 14:19:06 GMT
Subject: RFR: 8320646: RISC-V: C2 VectorCastHF2F [v2]
In-Reply-To: <tX9EXdMM7H_ntn3ERpCh8M2n4HfcU8000mNuQIfoMj0=.3494461c-7fcf-419f-9ae4-282606175979@github.com>
References: <kqLQR-bD3v7iF7LgH0PzwIH_m6QH_2b371pKz9_Ovq8=.9c07c165-2a97-4a6b-9e82-6a6de0b81328@github.com>
 <fTvkUqcIsICvOIRWhqcICR8OYfaiOsOgSoaJsgUUm94=.09bb33c2-ce00-4943-bed0-0a1906395ee4@github.com>
 <tX9EXdMM7H_ntn3ERpCh8M2n4HfcU8000mNuQIfoMj0=.3494461c-7fcf-419f-9ae4-282606175979@github.com>
Message-ID: <THH0lUjsiqXX6sDxJza_m6CO4lOObuU22EqCZ55WvzE=.69c081cb-971f-44bf-adc2-57da91ebe041@github.com>

On Tue, 27 Feb 2024 08:46:04 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add some comments
>
> src/hotspot/cpu/riscv/riscv_v.ad line 3706:
> 
>> 3704:   match(Set dst (VectorCastF2HF src));
>> 3705:   effect(TEMP_DEF dst, TEMP v0, TEMP tmp);
>> 3706:   format %{ "vfncvt.f.f.w $dst, $src\t# convert single to half precision"
> 
> Unnecessary new-line:
> Suggestion:
> 
>   format %{ "vfwcvt.f.f.v $dst, $src\t# convert half to single precision" %}

fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17698#discussion_r1506034334

From mli at openjdk.org  Wed Feb 28 14:22:54 2024
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 28 Feb 2024 14:22:54 GMT
Subject: RFR: 8320646: RISC-V: C2 VectorCastHF2F [v2]
In-Reply-To: <8OQQo7cqVshZlOmFeWCLp_VrD3rizjsPDU4a1kGxokc=.75d8279c-ae2f-42fc-89e7-ccebb826e142@github.com>
References: <kqLQR-bD3v7iF7LgH0PzwIH_m6QH_2b371pKz9_Ovq8=.9c07c165-2a97-4a6b-9e82-6a6de0b81328@github.com>
 <fTvkUqcIsICvOIRWhqcICR8OYfaiOsOgSoaJsgUUm94=.09bb33c2-ce00-4943-bed0-0a1906395ee4@github.com>
 <k_9SAB2dNMVxzI5kc2Hd_7Nou8CvA998lE1WJTkphhY=.3f85f4e9-5a40-40be-9c6d-4db89a42c182@github.com>
 <ZwaoSyFg4BXYEZlZHnJ1rx6vdt8xAWzV4XQXRDriR5U=.47567d13-6df9-452c-baac-d376c1830df0@github.com>
 <8OQQo7cqVshZlOmFeWCLp_VrD3rizjsPDU4a1kGxokc=.75d8279c-ae2f-42fc-89e7-ccebb826e142@github.com>
Message-ID: <fpYpk80yED5ih-DGMKoFBw_30nbYqzUczIlTDE3jSPs=.35876df6-67a1-4a62-b156-8ba20b4f2124@github.com>

On Wed, 28 Feb 2024 05:00:13 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> We still want to give end users the ability to disable extensions if things are broken. The flags would be the only way if we rely on hwprobe + vendor specific flags (like https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp#L232-L260, and which I'm surprised not more hw vendors have added their own)
>
>> We still want to give end users the ability to disable extensions if things are broken. The flags would be the only way if we rely on hwprobe + vendor specific flags (like 
> 
> That make sense to me. In the long run, we should depend on hwprobe + vendor specific code to auto-enable or disable certain RV extensions on certain hardwares. But I agree on that there should be some options of `DIAGNOSTIC` kind to help diagnose issues and find workarounds. I am OK to make this option an `EXPERIMENTAL` one at the current stage. But we should turn them into the `DIAGNOSTIC` kind in the future when we have the hardwares and hwprobe is capable to satisfy our needs. Mind you, we are lacking one option for https://github.com/openjdk/jdk/pull/17122 in that respect. Let me know if you going to add one.
> 
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp#L232-L260, and which I'm surprised not more hw vendors have added their own)
> 
> That will depend on the vendors. Given that the current RV hardwares are not that rich in RV extensions, I guess there isn't much to tune.

Thanks for comments and discussion, made UseZvfh experimental.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17698#discussion_r1506039298

From mli at openjdk.org  Wed Feb 28 14:22:56 2024
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 28 Feb 2024 14:22:56 GMT
Subject: RFR: 8320646: RISC-V: C2 VectorCastHF2F [v2]
In-Reply-To: <2gw0Ku-173RNRXv1NvCQI2qUj3i1Ay_5ZMVWJOZwsDw=.3c9d78e1-413f-4df8-b30b-4771d2d4f112@github.com>
References: <kqLQR-bD3v7iF7LgH0PzwIH_m6QH_2b371pKz9_Ovq8=.9c07c165-2a97-4a6b-9e82-6a6de0b81328@github.com>
 <fTvkUqcIsICvOIRWhqcICR8OYfaiOsOgSoaJsgUUm94=.09bb33c2-ce00-4943-bed0-0a1906395ee4@github.com>
 <2gw0Ku-173RNRXv1NvCQI2qUj3i1Ay_5ZMVWJOZwsDw=.3c9d78e1-413f-4df8-b30b-4771d2d4f112@github.com>
Message-ID: <XUAs7gCoUf5F3Rds3wIrzdNZQ0qGTatqEAh3VJGsu6s=.f8d1d813-02e6-4f83-ae92-fc061d719856@github.com>

On Tue, 27 Feb 2024 14:47:42 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add some comments
>
> src/hotspot/cpu/riscv/globals_riscv.hpp line 117:
> 
>> 115:   product(bool, UseZihintpause, false, EXPERIMENTAL,                             \
>> 116:           "Use Zihintpause instructions")                                        \
>> 117:   product(bool, UseZvfh, false, "Use Zvfh instructions")                         \
> 
> If adding this flag, please mark as experimental as there is currently no hardware we can test that on (other than QEMU).

done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17698#discussion_r1506040006

From coleenp at openjdk.org  Wed Feb 28 14:29:55 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 28 Feb 2024 14:29:55 GMT
Subject: RFR: 8324799: Use correct extension for C++ test headers
In-Reply-To: <EuPUnRfdrmz0S95Mmxx3edQd_Hv3bIwRoEFmH-mV1uc=.ed6dc428-adf1-48bb-afbc-c6be67e2ebf2@github.com>
References: <zacvqoEa_wLnC3CvPWKN2c2AR1yq_p72pUsLQLyzqTM=.05089090-fa08-4362-9a85-762716ca6132@github.com>
 <EuPUnRfdrmz0S95Mmxx3edQd_Hv3bIwRoEFmH-mV1uc=.ed6dc428-adf1-48bb-afbc-c6be67e2ebf2@github.com>
Message-ID: <mYIDtAgAU6pHUgIYjGUjwvJC-Zc62eueUWic5kFdK8g=.e29f8ba8-f5e4-4f0e-afa7-9e0e9036b26e@github.com>

On Wed, 28 Feb 2024 14:13:58 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change that renames some test .h files to .hpp.  These
>> files contain C++ code and should be named accordingly.  Some of them contain
>> uses of NULL, which we change to nullptr.
>> 
>> The renamed files are:
>> 
>> test/hotspot/jtreg/vmTestbase/nsk/share/aod/aod.h
>> test/hotspot/jtreg/vmTestbase/nsk/share/jni/jni_tools.h  
>> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.h
>> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/JVMTITools.h
>> test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_tools.h 
>> 
>> test/lib/jdk/test/lib/jvmti/jvmti_thread.h
>> test/lib/jdk/test/lib/jvmti/jvmti_common.h
>> test/lib/native/testlib_threads.h 
>> 
>> The #include updates were performed mostly mechanically, and builds would fail
>> if there were mistakes.  The exception is test
>> test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp,
>> which was added after I'd done the mechanical update, so was updated by hand.
>> 
>> The copyright updates were similarly performed mechanically. All but a handful
>> of the including files have already had their copyrights updated recently,
>> likely as part of JDK-8324681.
>> 
>> Thus, the only "interesting" changes are to the renamed files.
>> 
>> Testing: mach5 tier1
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/FollowReferences/libVThreadStackRefTest.cpp line 26:
> 
>> 24: #include <jni.h>
>> 25: #include <jvmti.h>
>> 26: #include <jvmti_common.hpp>
> 
> Should this be in quotes rather than <> ?

Suggestion:

#include "jvmti_common.hpp"

> test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadStateMountedTest/libGetThreadStateMountedTest.cpp line 26:
> 
>> 24: #include <jni.h>
>> 25: #include <jvmti.h>
>> 26: #include <jvmti_common.hpp>
> 
> Another.

Suggestion:

#include "jvmti_common.hpp"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18035#discussion_r1506033122
PR Review Comment: https://git.openjdk.org/jdk/pull/18035#discussion_r1506033741

From coleenp at openjdk.org  Wed Feb 28 14:29:55 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 28 Feb 2024 14:29:55 GMT
Subject: RFR: 8324799: Use correct extension for C++ test headers
In-Reply-To: <vw8vW3c2IjGmu0FDwA99y7bcnH7RwHvzP2XEookoCRo=.81ddab9d-4bc0-4ace-97ce-c529b214547b@github.com>
References: <zacvqoEa_wLnC3CvPWKN2c2AR1yq_p72pUsLQLyzqTM=.05089090-fa08-4362-9a85-762716ca6132@github.com>
 <vw8vW3c2IjGmu0FDwA99y7bcnH7RwHvzP2XEookoCRo=.81ddab9d-4bc0-4ace-97ce-c529b214547b@github.com>
Message-ID: <yM05QzjjBnbKY7XahBGj1eO3pDOk8okS4hJ7pe88u7A=.44039afa-785d-4ccb-9b95-1395f69ee8e3@github.com>

On Wed, 28 Feb 2024 03:58:39 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Please review this change that renames some test .h files to .hpp.  These
>> files contain C++ code and should be named accordingly.  Some of them contain
>> uses of NULL, which we change to nullptr.
>> 
>> The renamed files are:
>> 
>> test/hotspot/jtreg/vmTestbase/nsk/share/aod/aod.h
>> test/hotspot/jtreg/vmTestbase/nsk/share/jni/jni_tools.h  
>> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.h
>> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/JVMTITools.h
>> test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_tools.h 
>> 
>> test/lib/jdk/test/lib/jvmti/jvmti_thread.h
>> test/lib/jdk/test/lib/jvmti/jvmti_common.h
>> test/lib/native/testlib_threads.h 
>> 
>> The #include updates were performed mostly mechanically, and builds would fail
>> if there were mistakes.  The exception is test
>> test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp,
>> which was added after I'd done the mechanical update, so was updated by hand.
>> 
>> The copyright updates were similarly performed mechanically. All but a handful
>> of the including files have already had their copyrights updated recently,
>> likely as part of JDK-8324681.
>> 
>> Thus, the only "interesting" changes are to the renamed files.
>> 
>> Testing: mach5 tier1
>
> test/hotspot/jtreg/serviceability/jvmti/events/SingleStep/singlestep01/libsinglestep01.cpp line 28:
> 
>> 26: #include <string.h>
>> 27: #include <jvmti.h>
>> 28: #include "jvmti_common.hpp"
> 
> The copyright of this file is wrong.
> 
>>  * Copyright (c) 200
>>  * git 3, 2022, Oracle and/or its affiliates. All rights reserved.
>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

It's weird that our jcheck tools didn't find the broken copyright.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18035#discussion_r1506027798

From coleenp at openjdk.org  Wed Feb 28 14:29:54 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 28 Feb 2024 14:29:54 GMT
Subject: RFR: 8324799: Use correct extension for C++ test headers
In-Reply-To: <zacvqoEa_wLnC3CvPWKN2c2AR1yq_p72pUsLQLyzqTM=.05089090-fa08-4362-9a85-762716ca6132@github.com>
References: <zacvqoEa_wLnC3CvPWKN2c2AR1yq_p72pUsLQLyzqTM=.05089090-fa08-4362-9a85-762716ca6132@github.com>
Message-ID: <EuPUnRfdrmz0S95Mmxx3edQd_Hv3bIwRoEFmH-mV1uc=.ed6dc428-adf1-48bb-afbc-c6be67e2ebf2@github.com>

On Wed, 28 Feb 2024 01:18:50 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that renames some test .h files to .hpp.  These
> files contain C++ code and should be named accordingly.  Some of them contain
> uses of NULL, which we change to nullptr.
> 
> The renamed files are:
> 
> test/hotspot/jtreg/vmTestbase/nsk/share/aod/aod.h
> test/hotspot/jtreg/vmTestbase/nsk/share/jni/jni_tools.h  
> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.h
> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/JVMTITools.h
> test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_tools.h 
> 
> test/lib/jdk/test/lib/jvmti/jvmti_thread.h
> test/lib/jdk/test/lib/jvmti/jvmti_common.h
> test/lib/native/testlib_threads.h 
> 
> The #include updates were performed mostly mechanically, and builds would fail
> if there were mistakes.  The exception is test
> test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp,
> which was added after I'd done the mechanical update, so was updated by hand.
> 
> The copyright updates were similarly performed mechanically. All but a handful
> of the including files have already had their copyrights updated recently,
> likely as part of JDK-8324681.
> 
> Thus, the only "interesting" changes are to the renamed files.
> 
> Testing: mach5 tier1

I asked for these to be done together since it's the same scrolling for each of these.

I added suggestions, but please feel free to ignore them since it would be prudent pull down and to rebuild after making them and it's not worth it.

test/hotspot/jtreg/serviceability/jvmti/DynamicCodeGenerated/libDynamicCodeGenerated.cpp line 25:

> 23: 
> 24: #include <string.h>
> 25: #include <jvmti.h>

Is jvmti.h a C file?  Sometimes it has <> sometimes it's included with "".  I don't expect to see a change.  I was just curious.

test/hotspot/jtreg/serviceability/jvmti/vthread/FollowReferences/libVThreadStackRefTest.cpp line 26:

> 24: #include <jni.h>
> 25: #include <jvmti.h>
> 26: #include <jvmti_common.hpp>

Should this be in quotes rather than <> ?

test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadStateMountedTest/libGetThreadStateMountedTest.cpp line 26:

> 24: #include <jni.h>
> 25: #include <jvmti.h>
> 26: #include <jvmti_common.hpp>

Another.

test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassStatus/getclstat007/getclstat007.cpp line 28:

> 26: #include "jvmti.h"
> 27: #include "agent_common.hpp"
> 28: #include "JVMTITools.hpp"

There's a lower case jvmti_tools.hpp and an uppercase JVMTITools.hpp now.  Maybe someone could do a cleanup of these tests (please!)

test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses/retransform004/retransform004.cpp line 29:

> 27: #include <jvmti.h>
> 28: #include "agent_common.hpp"
> 29: #include <jvmti_tools.hpp>

Suggestion:

#include "jvmti_tools.hpp"

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18035#pullrequestreview-1906370538
PR Review Comment: https://git.openjdk.org/jdk/pull/18035#discussion_r1506026145
PR Review Comment: https://git.openjdk.org/jdk/pull/18035#discussion_r1506031049
PR Review Comment: https://git.openjdk.org/jdk/pull/18035#discussion_r1506031853
PR Review Comment: https://git.openjdk.org/jdk/pull/18035#discussion_r1506038573
PR Review Comment: https://git.openjdk.org/jdk/pull/18035#discussion_r1506045478

From smonteith at openjdk.org  Wed Feb 28 14:51:56 2024
From: smonteith at openjdk.org (Stuart Monteith)
Date: Wed, 28 Feb 2024 14:51:56 GMT
Subject: RFR: 8326541: [AArch64] ZGC C2 load barrier stub considers the
 length of live registers when spilling registers
In-Reply-To: <r2f4Q3rOBQI7MZj98vsv9aZnAQtRfILkKXTapls0VXw=.6895abe4-526a-47af-b400-5d7c6bd100b2@github.com>
References: <r2f4Q3rOBQI7MZj98vsv9aZnAQtRfILkKXTapls0VXw=.6895abe4-526a-47af-b400-5d7c6bd100b2@github.com>
Message-ID: <eQOYkD4MdH0ibsbPy2Ldo3Ydc04zdczpJXXD4aplJEM=.8afc4e4f-309d-4a1f-b735-86add0378fdf@github.com>

On Fri, 23 Feb 2024 08:11:24 GMT, Joshua Zhu <jzhu at openjdk.org> wrote:

> Currently ZGC C2 load barrier stub saves the whole live register regardless of what size of register is live on aarch64.
> Considering the size of SVE register is an implementation-defined multiple of 128 bits, up to 2048 bits,
> even the use of a floating point may cause the maximum 2048 bits stack occupied.
> Hence I would like to introduce this change on aarch64: take the length of live registers into consideration in ZGC C2 load barrier stub.
> 
> In a floating point case on 2048 bits SVE machine, the following ZLoadBarrierStubC2 
> 
> 
>   ......
>   0x0000ffff684cfad8:   stp     x15, x18, [sp, #80]
>   0x0000ffff684cfadc:   sub     sp, sp, #0x100
>   0x0000ffff684cfae0:   str     z16, [sp]
>   0x0000ffff684cfae4:   add     x1, x13, #0x10
>   0x0000ffff684cfae8:   mov     x0, x16
>  ;; 0xFFFF803F5414
>   0x0000ffff684cfaec:   mov     x8, #0x5414                     // #21524
>   0x0000ffff684cfaf0:   movk    x8, #0x803f, lsl #16
>   0x0000ffff684cfaf4:   movk    x8, #0xffff, lsl #32
>   0x0000ffff684cfaf8:   blr     x8
>   0x0000ffff684cfafc:   mov     x16, x0
>   0x0000ffff684cfb00:   ldr     z16, [sp]
>   0x0000ffff684cfb04:   add     sp, sp, #0x100
>   0x0000ffff684cfb08:   ptrue   p7.b
>   0x0000ffff684cfb0c:   ldp     x4, x5, [sp, #16]
>   ......
> 
> 
> could be optimized into:
> 
> 
>   ......  
>   0x0000ffff684cfa50:   stp     x15, x18, [sp, #80]
>   0x0000ffff684cfa54:   str     d16, [sp, #-16]!                   // extra 8 bytes to align 16 bytes in push_fp()
>   0x0000ffff684cfa58:   add     x1, x13, #0x10
>   0x0000ffff684cfa5c:   mov     x0, x16
>  ;; 0xFFFF7FA942A8
>   0x0000ffff684cfa60:   mov     x8, #0x42a8                     // #17064
>   0x0000ffff684cfa64:   movk    x8, #0x7fa9, lsl #16
>   0x0000ffff684cfa68:   movk    x8, #0xffff, lsl #32
>   0x0000ffff684cfa6c:   blr     x8
>   0x0000ffff684cfa70:   mov     x16, x0
>   0x0000ffff684cfa74:   ldr     d16, [sp], #16
>   0x0000ffff684cfa78:   ptrue   p7.b
>   0x0000ffff684cfa7c:   ldp     x4, x5, [sp, #16]
>   ......
> 
> 
> Besides the above benefit, when we know what size of register is live,
> we could remove the unnecessary caller save in ZGC C2 load barrier stub when we meet C-ABI SOE fp registers.
> 
> Passed jtreg with option "-XX:+UseZGC -XX:+ZGenerational" with no failures introduced.

That is a welcome change - in light of possibly very large registers, we don't want to save more than is necessary.
It looks OK, but have you run a specific test that demonstrates it working?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17977#issuecomment-1969148590

From duke at openjdk.org  Wed Feb 28 15:21:56 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Wed, 28 Feb 2024 15:21:56 GMT
Subject: RFR: 8325991: Accelerate Poly1305 on x86_64 using AVX2
 instructions [v10]
In-Reply-To: <9_AS9fKLjyVQzybg1915BX3xVVFwJRKjsqghjZ99hr0=.13a55d69-fc86-4109-a3be-934d1b8634d0@github.com>
References: <IyoM1HY_rvNWwo4GxcV1yQleB3vrgaLwsAlOCEpLKqs=.1d50225c-8fe1-4a84-af56-274632b2b653@github.com>
 <9_AS9fKLjyVQzybg1915BX3xVVFwJRKjsqghjZ99hr0=.13a55d69-fc86-4109-a3be-934d1b8634d0@github.com>
Message-ID: <HOgHqL8_U2QXXaUAXx519kerqePR_Y_TFDV36g_iaMw=.01373702-02a4-40f6-ba5b-3158a85e1353@github.com>

On Tue, 27 Feb 2024 21:13:07 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> The goal of this PR is to accelerate the Poly1305 algorithm using AVX2 instructions (including IFMA) for x86_64 CPUs.
>> 
>> This implementation is directly based on the AVX2 Poly1305 hash computation as implemented in Intel(R) Multi-Buffer Crypto for IPsec Library (url: https://github.com/intel/intel-ipsec-mb/blob/main/lib/avx2_t3/poly_fma_avx2.asm)
>> 
>> This PR shows upto 19x speedup on buffer sizes of 1MB.
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update description of Poly1305 algo

Thanks, the PR looks good to me

-------------

Marked as reviewed by vpaprotsk at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jdk/pull/17881#pullrequestreview-1906548793

From lmesnik at openjdk.org  Wed Feb 28 19:50:43 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 28 Feb 2024 19:50:43 GMT
Subject: RFR: 8324799: Use correct extension for C++ test headers
In-Reply-To: <zacvqoEa_wLnC3CvPWKN2c2AR1yq_p72pUsLQLyzqTM=.05089090-fa08-4362-9a85-762716ca6132@github.com>
References: <zacvqoEa_wLnC3CvPWKN2c2AR1yq_p72pUsLQLyzqTM=.05089090-fa08-4362-9a85-762716ca6132@github.com>
Message-ID: <SVmXHpECXzSYMz2luUW0A8Tyz2Sdl-EKvR-r4SS0vNI=.6d5f6a16-e407-4461-a43c-33d7dbfe561a@github.com>

On Wed, 28 Feb 2024 01:18:50 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that renames some test .h files to .hpp.  These
> files contain C++ code and should be named accordingly.  Some of them contain
> uses of NULL, which we change to nullptr.
> 
> The renamed files are:
> 
> test/hotspot/jtreg/vmTestbase/nsk/share/aod/aod.h
> test/hotspot/jtreg/vmTestbase/nsk/share/jni/jni_tools.h  
> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.h
> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/JVMTITools.h
> test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_tools.h 
> 
> test/lib/jdk/test/lib/jvmti/jvmti_thread.h
> test/lib/jdk/test/lib/jvmti/jvmti_common.h
> test/lib/native/testlib_threads.h 
> 
> The #include updates were performed mostly mechanically, and builds would fail
> if there were mistakes.  The exception is test
> test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp,
> which was added after I'd done the mechanical update, so was updated by hand.
> 
> The copyright updates were similarly performed mechanically. All but a handful
> of the including files have already had their copyrights updated recently,
> likely as part of JDK-8324681.
> 
> Thus, the only "interesting" changes are to the renamed files.
> 
> Testing: mach5 tier1

Marked as reviewed by lmesnik (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18035#pullrequestreview-1907166501

From dchuyko at openjdk.org  Wed Feb 28 21:17:03 2024
From: dchuyko at openjdk.org (Dmitry Chuyko)
Date: Wed, 28 Feb 2024 21:17:03 GMT
Subject: RFR: 8309271: A way to align already compiled methods with
 compiler directives [v27]
In-Reply-To: <csWpTiZu4dQgyARmNGro8PYl8yLj6-dRjVdsh51jV0k=.c0e25efd-3ee0-4196-a05a-c54268f23660@github.com>
References: <csWpTiZu4dQgyARmNGro8PYl8yLj6-dRjVdsh51jV0k=.c0e25efd-3ee0-4196-a05a-c54268f23660@github.com>
Message-ID: <uN6LgBpgLxeTzEnG9bThs8AgQ8oZa_YDFEFLk1Amgb8=.5a017f15-0ebb-4336-86b7-761c3cd3b106@github.com>

> Compiler Control (https://openjdk.org/jeps/165) provides method-context dependent control of the JVM compilers (C1 and C2). The active directive stack is built from the directive files passed with the `-XX:CompilerDirectivesFile` diagnostic command-line option and the Compiler.add_directives diagnostic command. It is also possible to clear all directives or remove the top from the stack.
> 
> A matching directive will be applied at method compilation time when such compilation is started. If directives are added or changed, but compilation does not start, then the state of compiled methods doesn't correspond to the rules. This is not an error, and it happens in long running applications when directives are added or removed after compilation of methods that could be matched. For example, the user decides that C2 compilation needs to be disabled for some method due to a compiler bug, issues such a directive but this does not affect the application behavior. In such case, the target application needs to be restarted, and such an operation can have high costs and risks. Another goal is testing/debugging compilers.
> 
> It would be convenient to optionally reconcile at least existing matching nmethods to the current stack of compiler directives (so bypass inlined methods).
> 
> Natural way to eliminate the discrepancy between the result of compilation and the broken rule is to discard the compilation result, i.e. deoptimization. Prior to that we can try to re-compile the method letting compile broker to perform it taking new directives stack into account. Re-compilation helps to prevent hot methods from execution in the interpreter.
> 
> A new flag `-r` has beed introduced for some directives related to compile commands: `Compiler.add_directives`, `Compiler.remove_directives`, `Compiler.clear_directives`. The default behavior has not changed (no flag). If the new flag is present, the command scans already compiled methods and puts methods that have any active non-default matching compiler directives to re-compilation if possible, otherwise marks them for deoptimization. There is currently no distinction which directives are found. In particular, this means that if there are rules for inlining into some method, it will be refreshed. On the other hand, if there are rules for a method and it was inlined, top-level methods won't be refreshed, but this can be achieved by having rules for them.
> 
> In addition, a new diagnostic command `Compiler.replace_directives`, has been added for ...

Dmitry Chuyko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 45 commits:

 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Deopt osr, cleanups
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - ... and 35 more: https://git.openjdk.org/jdk/compare/be2b92bd...9f1ea65d

-------------

Changes: https://git.openjdk.org/jdk/pull/14111/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14111&range=26
  Stats: 381 lines in 15 files changed: 348 ins; 3 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/14111.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14111/head:pull/14111

PR: https://git.openjdk.org/jdk/pull/14111

From matsaave at openjdk.org  Wed Feb 28 22:29:10 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 28 Feb 2024 22:29:10 GMT
Subject: RFR: 8251330: Reorder CDS archived heap to speed up relocation
 [v4]
In-Reply-To: <ZesL5badknO18z5YBr0f1X7pYtMiSWHzKcRJuMfR5kM=.ef3bc428-2461-4501-a30e-e38980fcf5ad@github.com>
References: <ZesL5badknO18z5YBr0f1X7pYtMiSWHzKcRJuMfR5kM=.ef3bc428-2461-4501-a30e-e38980fcf5ad@github.com>
Message-ID: <q9cZFBY7W_yHJWjblsVdrjiyzyBJAXqT3oXf9I4CkXw=.4a10f23c-1bde-4706-b0e1-4a1d9ab95b93@github.com>

> We should reorder the archived heap to segregate the objects that don't need marking. This will save space in the archive and improve start-up time
> 
> This patch reorders the archived heap to segregate the objects that don't need marking. The leading zeros present in the bitmaps thanks to the reordering can be easily removed, and this the size of the archive is reduced.
> 
> Given that the bitmaps are word aligned, some leading zeroes will remain. Verified with tier 1-5 tests.
> 
> Metrics, courtesy of @iklam :
> ```calculate_oopmap: objects = 15262 (507904 bytes, 332752 bytes don't need marking), embedded oops = 8408, nulls = 54
> Oopmap = 15872 bytes
> 
> calculate_oopmap: objects = 4590 (335872 bytes, 178120 bytes don't need marking), embedded oops = 46487, nulls = 29019
> Oopmap = 10496 bytes
> 
> (332752 + 178120) / (507904 + 335872.0) = 0.6054592688106796 
> More than 60% of the space used by the archived heap doesn't need to be marked by the oopmap. 
> 
> $ java -Xshare:dump -Xlog:cds+map | grep lead
> [3.777s][info][cds,map] - heap_oopmap_leading_zeros: 143286
> [3.777s][info][cds,map] - heap_ptrmap_leading_zeros: 50713
> 
> So we can reduce the "bm" region by (143286 + 50713) / 8 = 24249 bytes.
> 
> Current output:
> $ java -XX:+UseNewCode -Xshare:dump -Xlog:cds+map | grep lead 
> [5.339s][info][cds,map] - heap_oopmap_leading_zeros:      26
> [5.339s][info][cds,map] - heap_ptrmap_leading_zeros:      8

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 33 additional commits since the last revision:

 - Removed unused methods and reordered code
 - Merge branch 'master' into reorder_archive_heap_8251330
 - Slice method now copies and Ioi Comments
 - Renamed variables and moved pointer patching shift
 - Added helper function
 - Merge branch 'master' into reorder_archive_heap_8251330
 - Removed commented code
 - Adjusted word alignment in slice method
 - Merge branch 'master' into reorder_archive_heap_8251330
 - Merge branch 'master' into reorder_archive_heap_8251330
 - ... and 23 more: https://git.openjdk.org/jdk/compare/08c00258...029e602d

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17350/files
  - new: https://git.openjdk.org/jdk/pull/17350/files/411bc1a8..029e602d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17350&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17350&range=02-03

  Stats: 10536 lines in 908 files changed: 6043 ins; 2301 del; 2192 mod
  Patch: https://git.openjdk.org/jdk/pull/17350.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17350/head:pull/17350

PR: https://git.openjdk.org/jdk/pull/17350

From kbarrett at openjdk.org  Thu Feb 29 00:16:28 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 29 Feb 2024 00:16:28 GMT
Subject: RFR: 8324799: Use correct extension for C++ test headers [v2]
In-Reply-To: <zacvqoEa_wLnC3CvPWKN2c2AR1yq_p72pUsLQLyzqTM=.05089090-fa08-4362-9a85-762716ca6132@github.com>
References: <zacvqoEa_wLnC3CvPWKN2c2AR1yq_p72pUsLQLyzqTM=.05089090-fa08-4362-9a85-762716ca6132@github.com>
Message-ID: <EV5GTFXmtvaCKqyarstQ6DvKuCx5x813AZVH3oOC5P4=.2f6af7c6-3b74-4a72-aed4-2bacd2e74622@github.com>

> Please review this change that renames some test .h files to .hpp.  These
> files contain C++ code and should be named accordingly.  Some of them contain
> uses of NULL, which we change to nullptr.
> 
> The renamed files are:
> 
> test/hotspot/jtreg/vmTestbase/nsk/share/aod/aod.h
> test/hotspot/jtreg/vmTestbase/nsk/share/jni/jni_tools.h  
> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.h
> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/JVMTITools.h
> test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_tools.h 
> 
> test/lib/jdk/test/lib/jvmti/jvmti_thread.h
> test/lib/jdk/test/lib/jvmti/jvmti_common.h
> test/lib/native/testlib_threads.h 
> 
> The #include updates were performed mostly mechanically, and builds would fail
> if there were mistakes.  The exception is test
> test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp,
> which was added after I'd done the mechanical update, so was updated by hand.
> 
> The copyright updates were similarly performed mechanically. All but a handful
> of the including files have already had their copyrights updated recently,
> likely as part of JDK-8324681.
> 
> Thus, the only "interesting" changes are to the renamed files.
> 
> Testing: mach5 tier1

Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:

 - add Oracle copyright
 - fix busted copyright text

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18035/files
  - new: https://git.openjdk.org/jdk/pull/18035/files/4154005e..53f93950

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18035&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18035&range=00-01

  Stats: 3 lines in 2 files changed: 1 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18035.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18035/head:pull/18035

PR: https://git.openjdk.org/jdk/pull/18035

From kbarrett at openjdk.org  Thu Feb 29 00:16:29 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 29 Feb 2024 00:16:29 GMT
Subject: RFR: 8324799: Use correct extension for C++ test headers [v2]
In-Reply-To: <yM05QzjjBnbKY7XahBGj1eO3pDOk8okS4hJ7pe88u7A=.44039afa-785d-4ccb-9b95-1395f69ee8e3@github.com>
References: <zacvqoEa_wLnC3CvPWKN2c2AR1yq_p72pUsLQLyzqTM=.05089090-fa08-4362-9a85-762716ca6132@github.com>
 <vw8vW3c2IjGmu0FDwA99y7bcnH7RwHvzP2XEookoCRo=.81ddab9d-4bc0-4ace-97ce-c529b214547b@github.com>
 <yM05QzjjBnbKY7XahBGj1eO3pDOk8okS4hJ7pe88u7A=.44039afa-785d-4ccb-9b95-1395f69ee8e3@github.com>
Message-ID: <ibO29x8UBzEkUnzlRDz8XKE2qWflya-t_luzQ0hTr08=.39f40fe7-dcd1-4606-aca0-d4504d4933aa@github.com>

On Wed, 28 Feb 2024 14:11:49 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/jvmti/events/SingleStep/singlestep01/libsinglestep01.cpp line 28:
>> 
>>> 26: #include <string.h>
>>> 27: #include <jvmti.h>
>>> 28: #include "jvmti_common.hpp"
>> 
>> The copyright of this file is wrong.
>> 
>>>  * Copyright (c) 200
>>>  * git 3, 2022, Oracle and/or its affiliates. All rights reserved.
>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>
> It's weird that our jcheck tools didn't find the broken copyright.

I thought it was odd too, so started a discussion on an internal slack channel about copyright checking.
It turns out there are a number that need some work.  I'm fixing this one, removing the newline and "git "
and updating the second year.  The starting year of 2003 seems odd, since this file seems to be fairly
new (from Virtual Threads), but 2003 is also what's in the adjacent .java file.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18035#discussion_r1506813867

From kbarrett at openjdk.org  Thu Feb 29 00:16:29 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 29 Feb 2024 00:16:29 GMT
Subject: RFR: 8324799: Use correct extension for C++ test headers [v2]
In-Reply-To: <vw8vW3c2IjGmu0FDwA99y7bcnH7RwHvzP2XEookoCRo=.81ddab9d-4bc0-4ace-97ce-c529b214547b@github.com>
References: <zacvqoEa_wLnC3CvPWKN2c2AR1yq_p72pUsLQLyzqTM=.05089090-fa08-4362-9a85-762716ca6132@github.com>
 <vw8vW3c2IjGmu0FDwA99y7bcnH7RwHvzP2XEookoCRo=.81ddab9d-4bc0-4ace-97ce-c529b214547b@github.com>
Message-ID: <aYLzKVm-RF6ByVZpU-YzcazNqeILvNkRT4-gZpL18bs=.b0865746-4eb7-4ad2-9027-1f09b3d3c4d5@github.com>

On Wed, 28 Feb 2024 04:06:08 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - add Oracle copyright
>>  - fix busted copyright text
>
> test/hotspot/jtreg/serviceability/jvmti/thread/GetStackTrace/GetStackTraceAndRetransformTest/libGetStackTraceAndRetransformTest.cpp line 27:
> 
>> 25: #include <string.h>
>> 26: #include "jvmti.h"
>> 27: #include "jvmti_common.hpp"
> 
> The oracle copyright needs to be added in this file?
> 
>>  * Copyright (c) 2023, Datadog, Inc. All rights reserved.
>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

We've touched this a couple times recently.  Updating.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18035#discussion_r1506814342

From kbarrett at openjdk.org  Thu Feb 29 00:16:29 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 29 Feb 2024 00:16:29 GMT
Subject: RFR: 8324799: Use correct extension for C++ test headers [v2]
In-Reply-To: <mYIDtAgAU6pHUgIYjGUjwvJC-Zc62eueUWic5kFdK8g=.e29f8ba8-f5e4-4f0e-afa7-9e0e9036b26e@github.com>
References: <zacvqoEa_wLnC3CvPWKN2c2AR1yq_p72pUsLQLyzqTM=.05089090-fa08-4362-9a85-762716ca6132@github.com>
 <EuPUnRfdrmz0S95Mmxx3edQd_Hv3bIwRoEFmH-mV1uc=.ed6dc428-adf1-48bb-afbc-c6be67e2ebf2@github.com>
 <mYIDtAgAU6pHUgIYjGUjwvJC-Zc62eueUWic5kFdK8g=.e29f8ba8-f5e4-4f0e-afa7-9e0e9036b26e@github.com>
Message-ID: <NAB-AtpBzg3Upze8ku5uyoWM1buUmRoAKUm-z43NQkI=.f8b1f68d-b472-4a73-9705-b0026647b197@github.com>

On Wed, 28 Feb 2024 14:15:25 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/jvmti/vthread/FollowReferences/libVThreadStackRefTest.cpp line 26:
>> 
>>> 24: #include <jni.h>
>>> 25: #include <jvmti.h>
>>> 26: #include <jvmti_common.hpp>
>> 
>> Should this be in quotes rather than <> ?
>
> Suggestion:
> 
> #include "jvmti_common.hpp"

Not making those kinds of changes in this PR.  Also surprised this is using `<atomic>`.  It seems there
are a number of tests doing that.  I'll file a bug for that.
https://bugs.openjdk.org/browse/JDK-8326999

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18035#discussion_r1506821728

From kbarrett at openjdk.org  Thu Feb 29 00:16:29 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 29 Feb 2024 00:16:29 GMT
Subject: RFR: 8324799: Use correct extension for C++ test headers [v2]
In-Reply-To: <EuPUnRfdrmz0S95Mmxx3edQd_Hv3bIwRoEFmH-mV1uc=.ed6dc428-adf1-48bb-afbc-c6be67e2ebf2@github.com>
References: <zacvqoEa_wLnC3CvPWKN2c2AR1yq_p72pUsLQLyzqTM=.05089090-fa08-4362-9a85-762716ca6132@github.com>
 <EuPUnRfdrmz0S95Mmxx3edQd_Hv3bIwRoEFmH-mV1uc=.ed6dc428-adf1-48bb-afbc-c6be67e2ebf2@github.com>
Message-ID: <eipcGR-lwAZbN_wMGKL1EnyVIBYnQ9xgBm23uXe22ZM=.9a5facee-45f6-46ac-befa-3ed30da5aea8@github.com>

On Wed, 28 Feb 2024 14:18:58 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - add Oracle copyright
>>  - fix busted copyright text
>
> test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassStatus/getclstat007/getclstat007.cpp line 28:
> 
>> 26: #include "jvmti.h"
>> 27: #include "agent_common.hpp"
>> 28: #include "JVMTITools.hpp"
> 
> There's a lower case jvmti_tools.hpp and an uppercase JVMTITools.hpp now.  Maybe someone could do a cleanup of these tests (please!)

Agreed that's kind of odd, though not new (they were both previously .h files).  There are lots of odd
things in vmTestbase tests - recall what the README.md in that directory says.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18035#discussion_r1506824801

From gli at openjdk.org  Thu Feb 29 02:22:52 2024
From: gli at openjdk.org (Guoxiong Li)
Date: Thu, 29 Feb 2024 02:22:52 GMT
Subject: RFR: 8324799: Use correct extension for C++ test headers [v2]
In-Reply-To: <EV5GTFXmtvaCKqyarstQ6DvKuCx5x813AZVH3oOC5P4=.2f6af7c6-3b74-4a72-aed4-2bacd2e74622@github.com>
References: <zacvqoEa_wLnC3CvPWKN2c2AR1yq_p72pUsLQLyzqTM=.05089090-fa08-4362-9a85-762716ca6132@github.com>
 <EV5GTFXmtvaCKqyarstQ6DvKuCx5x813AZVH3oOC5P4=.2f6af7c6-3b74-4a72-aed4-2bacd2e74622@github.com>
Message-ID: <Caz-s4pyCPJuBtrnwfvwCGXxEoBnmTSk2vDlOb1qwc4=.d8b23954-bbff-4c46-bd53-15b4dd6e8d85@github.com>

On Thu, 29 Feb 2024 00:16:28 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change that renames some test .h files to .hpp.  These
>> files contain C++ code and should be named accordingly.  Some of them contain
>> uses of NULL, which we change to nullptr.
>> 
>> The renamed files are:
>> 
>> test/hotspot/jtreg/vmTestbase/nsk/share/aod/aod.h
>> test/hotspot/jtreg/vmTestbase/nsk/share/jni/jni_tools.h  
>> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.h
>> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/JVMTITools.h
>> test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_tools.h 
>> 
>> test/lib/jdk/test/lib/jvmti/jvmti_thread.h
>> test/lib/jdk/test/lib/jvmti/jvmti_common.h
>> test/lib/native/testlib_threads.h 
>> 
>> The #include updates were performed mostly mechanically, and builds would fail
>> if there were mistakes.  The exception is test
>> test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp,
>> which was added after I'd done the mechanical update, so was updated by hand.
>> 
>> The copyright updates were similarly performed mechanically. All but a handful
>> of the including files have already had their copyrights updated recently,
>> likely as part of JDK-8324681.
>> 
>> Thus, the only "interesting" changes are to the renamed files.
>> 
>> Testing: mach5 tier1
>
> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - add Oracle copyright
>  - fix busted copyright text

Looks good.

-------------

Marked as reviewed by gli (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18035#pullrequestreview-1907811813

From sspitsyn at openjdk.org  Thu Feb 29 04:11:24 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 29 Feb 2024 04:11:24 GMT
Subject: RFR: 8247972: incorrect implementation of JVM TI
 GetObjectMonitorUsage [v18]
In-Reply-To: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
References: <vrgaSI3Jr5slBd-XTVbMtrcfjQvfDNYsgqYcAypwteg=.162f87a3-afd9-46ca-a5f2-d60769470da0@github.com>
Message-ID: <R_KuuMIt1-k0TLlr8fvRww--8zLxtmRkJhGSbQZ0US0=.90314c56-f8e1-4c15-ae93-d30aae36ee44@github.com>

> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the spec.
> The function returns the following structure:
> 
> 
> typedef struct {
>     jthread owner;
>     jint entry_count;
>     jint waiter_count;
>     jthread* waiters;
>     jint notify_waiter_count;
>     jthread* notify_waiters;
> } jvmtiMonitorUsage;
> 
> 
> The following four fields are defined this way:
> 
> waiter_count  [jint] The number of threads waiting to own this monitor
> waiters  [jthread*] The waiter_count waiting threads
> notify_waiter_count  [jint]  The number of threads waiting to be notified by this monitor
> notify_waiters  [jthread*] The notify_waiter_count threads waiting to be notified
> 
> The `waiters` has to include all threads waiting to enter the monitor or to re-enter it in `Object.wait()`.
> The implementation also includes the threads waiting to be notified in `Object.wait()` which is wrong.
> The `notify_waiters` has to include all threads waiting to be notified in `Object.wait()`.
> The implementation also includes the threads waiting to re-enter the monitor in `Object.wait()` which is wrong.
> This update makes it right.
> 
> The implementation of the JDWP command `ObjectReference.MonitorInfo (5)` is based on the JVM TI `GetObjectMonitorInfo()`. This update has a tweak to keep the existing behavior of this command.
> 
> The follwoing JVMTI vmTestbase tests are fixed to adopt to the `GetObjectMonitorUsage()` correct behavior:
> 
>   jvmti/GetObjectMonitorUsage/objmonusage001
>   jvmti/GetObjectMonitorUsage/objmonusage003
> 
> 
> The following JVMTI JCK tests have to be fixed to adopt to correct behavior:
> 
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00101/gomu00101a.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102.html
> vm/jvmti/GetObjectMonitorUsage/gomu001/gomu00102/gomu00102a.html
> 
> 
> 
> A JCK bug will be filed and the tests have to be added into the JCK problem list located in the closed repository.
> 
> Also, please see and review the related CSR:
>  [8324677](https://bugs.openjdk.org/browse/JDK-8324677): incorrect implementation of JVM TI GetObjectMonitorUsage
> 
> The Release-Note is:
> [8325314](https://bugs.openjdk.org/browse/JDK-8325314): Release Note: incorrect implementation of JVM TI GetObjectMonitorUsage
>  
> Testing:
>  - tested with mach5 tiers 1-6

Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:

 - resolve merge conflict for deleted file objmonusage003.cpp
 - fix a typo in libObjectMonitorUsage.cpp
 - fix potential sync gap in the test ObjectMonitorUsage
 - improve ObjectMonitorUsage test native agent output
 - improved the ObjectMonitorUsage test to make it more elegant
 - review: remove test objmonusage003; improve test ObjectMonitorUsage
 - review: addressed minor issue with use of []; corrected the test desctiption
 - review: addressed comments from David
 - fixed minimal build issue
 - cloned an nsk/jvmti test to provide test coverage for virtual threads; fixed vthread related issue
 - ... and 9 more: https://git.openjdk.org/jdk/compare/5fa2bdc6...06711644

-------------

Changes: https://git.openjdk.org/jdk/pull/17680/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17680&range=17
  Stats: 1120 lines in 14 files changed: 684 ins; 389 del; 47 mod
  Patch: https://git.openjdk.org/jdk/pull/17680.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17680/head:pull/17680

PR: https://git.openjdk.org/jdk/pull/17680

From sspitsyn at openjdk.org  Thu Feb 29 04:17:09 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 29 Feb 2024 04:17:09 GMT
Subject: RFR: 8256314: JVM TI GetCurrentContendedMonitor is implemented
 incorrectly [v3]
In-Reply-To: <-Yf2Qj_kbyZAA-LDK96IIOcHWMh8__QT1XfnD9jR8kU=.507d5503-1544-44fb-9e81-438ba3458dcd@github.com>
References: <-Yf2Qj_kbyZAA-LDK96IIOcHWMh8__QT1XfnD9jR8kU=.507d5503-1544-44fb-9e81-438ba3458dcd@github.com>
Message-ID: <CBZj7aDkrUIrsBESROtQUouIACD0QFQ4KP0n0KdPj38=.a8365bb6-cd25-4754-8d15-83b5006ea9be@github.com>

> The implementation of the JVM TI `GetCurrentContendedMonitor()` does not match the spec. It can sometimes return an incorrect information about the contended monitor. Such a behavior does not match the function spec. 
> With this update the `GetCurrentContendedMonitor()` is returning the monitor only when the specified thread is waiting to enter or re-enter the monitor, and the monitor is not returned when the specified thread is waiting in the `java.lang.Object.wait` to be notified.
> 
> The implementations of the JDWP `ThreadReference.CurrentContendedMonitor` command and JDI `ThreadReference.currentContendedMonitor()` method are based and depend on this JVMTI function. The JDWP command and the JDI method were specified incorrectly and had incorrect behavior. The fix slightly corrects both the JDWP and JDI specs. The JDWP and JDI implementations have been also fixed because they use this JVM TI update. Please, see and review the related CSR and Release-Note.
> 
> CSR: [8326024](https://bugs.openjdk.org/browse/JDK-8326024): JVM TI GetCurrentContendedMonitor is implemented incorrectly
> RN:   [8326038](https://bugs.openjdk.org/browse/JDK-8326038): Release Note: JVM TI GetCurrentContendedMonitor is implemented incorrectly
> 
> Testing:
>  - tested with the mach5 tiers 1-6

Serguei Spitsyn 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
 - fix specs: JDWP ThreadReference.CurrentContendedMonitor command, JDI ThreadReference.currentContendedMonitor method
 - 8256314: JVM TI GetCurrentContendedMonitor is implemented incorrectly

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17944/files
  - new: https://git.openjdk.org/jdk/pull/17944/files/3ce67fa9..a4e8c5b5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17944&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17944&range=01-02

  Stats: 37718 lines in 1612 files changed: 17312 ins; 12835 del; 7571 mod
  Patch: https://git.openjdk.org/jdk/pull/17944.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17944/head:pull/17944

PR: https://git.openjdk.org/jdk/pull/17944

From dholmes at openjdk.org  Thu Feb 29 05:31:54 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 29 Feb 2024 05:31:54 GMT
Subject: RFR: 8318302: ThreadCountLimit.java failed with
 "Native memory allocation (mprotect) failed to protect 16384 bytes for memory
 to guard stack pages" [v3]
In-Reply-To: <ueD_NcXZtkV7AkavgCwPIuvskfsB9o8bXhUQAkTHc3U=.700eafe1-41c7-429c-89e2-f90011efef40@github.com>
References: <owqAt1_7CSCVlCen_Lp7b3q1jMSjsU-D2SKq5ciBDgo=.1ec82f53-23b1-477d-887c-280b3721a505@github.com>
 <98Z3mMnDM6NuPlwduJ0MN9KnlP7NYdIxqXikHZE5JuE=.973a703f-9bf0-437f-93ab-ac01f385b824@github.com>
 <cTCz33a8SBGkTRYinWc74kwjfoc_T0g0Vx_zAw8jK6g=.a4fe5ef9-0fc2-4846-86f2-28eb12ec675f@github.com>
 <ueD_NcXZtkV7AkavgCwPIuvskfsB9o8bXhUQAkTHc3U=.700eafe1-41c7-429c-89e2-f90011efef40@github.com>
Message-ID: <rO0mDTi7L_o6GPyITZHAOG96Unrwj6L0Ot8fCHR4VLw=.9472269a-9da7-41be-91f6-7d028393eff0@github.com>

On Wed, 28 Feb 2024 08:01:26 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> @shipilev do you want this explored further?
>
> Not really. We can fix the test if bash-ism manifests as the problem.

Okay thanks for the review!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17959#discussion_r1507029822

From dholmes at openjdk.org  Thu Feb 29 05:31:55 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 29 Feb 2024 05:31:55 GMT
Subject: Integrated: 8318302: ThreadCountLimit.java failed with
 "Native memory allocation (mprotect) failed to protect 16384 bytes for memory
 to guard stack pages"
In-Reply-To: <owqAt1_7CSCVlCen_Lp7b3q1jMSjsU-D2SKq5ciBDgo=.1ec82f53-23b1-477d-887c-280b3721a505@github.com>
References: <owqAt1_7CSCVlCen_Lp7b3q1jMSjsU-D2SKq5ciBDgo=.1ec82f53-23b1-477d-887c-280b3721a505@github.com>
Message-ID: <f4o2Z2jtrZJDWrr0VecrSu7-5tVA-YaKtzAc2FV46GE=.de60b830-df6e-4de8-953e-9b49f605e0d3@github.com>

On Thu, 22 Feb 2024 07:36:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The test tries to create as many threads as possible in 5 seconds, with the intention of hitting platform limits on the maximum number of threads that can be created, so that we see that the VM reacts in a reasonable way. However on Linux, if the thread creation limit is high enough, and things run fast enough, then we can instead hit a fatal error when a mmap/mprotect returns E_NOMEM because the maximum number of memory mappings (default 65530) has been exceeded.
> 
> The fix to the test (courtesy @stefank ) is to re-exec the test on Linux with `ulimit -u` set to a much smaller value than the default (I chose 4096 as it still showed over 2000 threads were created before failure). This means we are unlikely to hit the default memory mapping limit before we hit the max threads limit.
> 
> I also updated the VM's OOM error message to include exceeding the maximum number of memory mappings as a possible cause (with a hint as to what to look for in the hs_err log).
> 
> Testing:
>  - ran the test 10x on all platforms in our CI (plus local testing)
> 
> Thanks

This pull request has now been integrated.

Changeset: 0735c8ab
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0735c8ab266be9c580bd4434305ee1decfe8b589
Stats:     50 lines in 2 files changed: 34 ins; 5 del; 11 mod

8318302: ThreadCountLimit.java failed with "Native memory allocation (mprotect) failed to protect 16384 bytes for memory to guard stack pages"

Co-authored-by: Stefan Karlsson <stefank at openjdk.org>
Reviewed-by: shade, stefank

-------------

PR: https://git.openjdk.org/jdk/pull/17959

From kbarrett at openjdk.org  Thu Feb 29 06:24:44 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 29 Feb 2024 06:24:44 GMT
Subject: RFR: 8324799: Use correct extension for C++ test headers [v2]
In-Reply-To: <EV5GTFXmtvaCKqyarstQ6DvKuCx5x813AZVH3oOC5P4=.2f6af7c6-3b74-4a72-aed4-2bacd2e74622@github.com>
References: <zacvqoEa_wLnC3CvPWKN2c2AR1yq_p72pUsLQLyzqTM=.05089090-fa08-4362-9a85-762716ca6132@github.com>
 <EV5GTFXmtvaCKqyarstQ6DvKuCx5x813AZVH3oOC5P4=.2f6af7c6-3b74-4a72-aed4-2bacd2e74622@github.com>
Message-ID: <HOOsx2oFUwG3xuit0iTsW07FVeZEIIPk4rt1f6bPd64=.c83889a2-abbe-4781-aefd-5a024b531e9c@github.com>

On Thu, 29 Feb 2024 00:16:28 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change that renames some test .h files to .hpp.  These
>> files contain C++ code and should be named accordingly.  Some of them contain
>> uses of NULL, which we change to nullptr.
>> 
>> The renamed files are:
>> 
>> test/hotspot/jtreg/vmTestbase/nsk/share/aod/aod.h
>> test/hotspot/jtreg/vmTestbase/nsk/share/jni/jni_tools.h  
>> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.h
>> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/JVMTITools.h
>> test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_tools.h 
>> 
>> test/lib/jdk/test/lib/jvmti/jvmti_thread.h
>> test/lib/jdk/test/lib/jvmti/jvmti_common.h
>> test/lib/native/testlib_threads.h 
>> 
>> The #include updates were performed mostly mechanically, and builds would fail
>> if there were mistakes.  The exception is test
>> test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp,
>> which was added after I'd done the mechanical update, so was updated by hand.
>> 
>> The copyright updates were similarly performed mechanically. All but a handful
>> of the including files have already had their copyrights updated recently,
>> likely as part of JDK-8324681.
>> 
>> Thus, the only "interesting" changes are to the renamed files.
>> 
>> Testing: mach5 tier1
>
> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - add Oracle copyright
>  - fix busted copyright text

Thanks for all the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18035#issuecomment-1970485416

From kbarrett at openjdk.org  Thu Feb 29 06:28:01 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 29 Feb 2024 06:28:01 GMT
Subject: Integrated: 8324799: Use correct extension for C++ test headers
In-Reply-To: <zacvqoEa_wLnC3CvPWKN2c2AR1yq_p72pUsLQLyzqTM=.05089090-fa08-4362-9a85-762716ca6132@github.com>
References: <zacvqoEa_wLnC3CvPWKN2c2AR1yq_p72pUsLQLyzqTM=.05089090-fa08-4362-9a85-762716ca6132@github.com>
Message-ID: <jn9o5e6BnZCpotqQfbLXGmIMKxbDQ7grsgW1LN5tJG4=.ee284fb0-28b6-485f-bd56-10c2e01a8f0c@github.com>

On Wed, 28 Feb 2024 01:18:50 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that renames some test .h files to .hpp.  These
> files contain C++ code and should be named accordingly.  Some of them contain
> uses of NULL, which we change to nullptr.
> 
> The renamed files are:
> 
> test/hotspot/jtreg/vmTestbase/nsk/share/aod/aod.h
> test/hotspot/jtreg/vmTestbase/nsk/share/jni/jni_tools.h  
> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.h
> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/JVMTITools.h
> test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_tools.h 
> 
> test/lib/jdk/test/lib/jvmti/jvmti_thread.h
> test/lib/jdk/test/lib/jvmti/jvmti_common.h
> test/lib/native/testlib_threads.h 
> 
> The #include updates were performed mostly mechanically, and builds would fail
> if there were mistakes.  The exception is test
> test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp,
> which was added after I'd done the mechanical update, so was updated by hand.
> 
> The copyright updates were similarly performed mechanically. All but a handful
> of the including files have already had their copyrights updated recently,
> likely as part of JDK-8324681.
> 
> Thus, the only "interesting" changes are to the renamed files.
> 
> Testing: mach5 tier1

This pull request has now been integrated.

Changeset: 998d0baa
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/998d0baab0fd051c38d9fd6021628eb863b80554
Stats:     1538 lines in 731 files changed: 134 ins; 134 del; 1270 mod

8324799: Use correct extension for C++ test headers

Reviewed-by: jwaters, gli, coleenp, lmesnik

-------------

PR: https://git.openjdk.org/jdk/pull/18035

From azafari at openjdk.org  Thu Feb 29 08:41:54 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 29 Feb 2024 08:41:54 GMT
Subject: RFR: 8324829: Uniform use of synchronizations in NMT
In-Reply-To: <5N3FuDaxf-vkusguUwcezaHOCNz8IbIiheFwybUw77E=.1d610b13-a0aa-47d8-9fda-44091c9d7a6f@github.com>
References: <uikMP7BCa6Wro3F63W7C4qQZNMgDSjSYXzHEGCroSDA=.aef515a7-6352-41d5-8aa5-ac0c94e5886d@github.com>
 <EnnPhb1SV_E-FGrfqOyVmB3cFc7RUSpP3ax2ahxUgAs=.4bcacc1c-d15d-4bf9-8ec7-ac941c8dad88@github.com>
 <LuCDQJNok_GmZYSW5yjxl68cm1OCECnW4W_q7qlQ6Mc=.136c9a63-ed50-42ff-8dfd-f105a11b846d@github.com>
 <RKu9s5Zp_4Kw8Fr7MzvXq6uW3Z78tPwqK4b9OwKBP6g=.f70a1dd9-4b89-4774-8153-c251334078dc@github.com>
 <5N3FuDaxf-vkusguUwcezaHOCNz8IbIiheFwybUw77E=.1d610b13-a0aa-47d8-9fda-44091c9d7a6f@github.com>
Message-ID: <cH9D6cBDS-0uG4bMgIok_UIASYNQ36D5a23_2zAdO2Y=.bead7fcd-4a64-41bc-aea4-7403e45970f3@github.com>

On Tue, 27 Feb 2024 05:48:36 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>>> > @afshin-zafari  Please, set correct RFE id number!!!!  See "Integration blockers" and "Issue".
>>> 
>>> ow. But Skara bot did not catch this? How strange.
>> 
>> It catch - It will not allow you to integrate until you resolve "Integration blockers".
>> 
>> Yes, it would be better if Skara does not allow to create such PR but I am not sure Skara does these checks at that time.
>
>> > > @afshin-zafari  Please, set correct RFE id number!!!!  See "Integration blockers" and "Issue".
>> > 
>> > 
>> > ow. But Skara bot did not catch this? How strange.
>> 
>> It catch - It will not allow you to integrate until you resolve "Integration blockers".
>> 
>> Yes, it would be better if Skara does not allow to create such PR but I am not sure Skara does these checks at that time.
> 
> Ah, okay. It would be cool for jcheck to pick this up and show an error in GHAs though. That way you notice it immediately.

@tstuefe and @jdksjolen, if you agree on keeping the method name as it is, then I can integrate this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18000#issuecomment-1970659696

From jsjolen at openjdk.org  Thu Feb 29 09:43:53 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 29 Feb 2024 09:43:53 GMT
Subject: RFR: 8324829: Uniform use of synchronizations in NMT
In-Reply-To: <uikMP7BCa6Wro3F63W7C4qQZNMgDSjSYXzHEGCroSDA=.aef515a7-6352-41d5-8aa5-ac0c94e5886d@github.com>
References: <uikMP7BCa6Wro3F63W7C4qQZNMgDSjSYXzHEGCroSDA=.aef515a7-6352-41d5-8aa5-ac0c94e5886d@github.com>
Message-ID: <C_qQlXIDb3DVaZGqxyYMH0KHJKyzf71rN8lWOQD1VNI=.ef1e7550-51c6-4e3a-9ab0-c377c4b40464@github.com>

On Mon, 26 Feb 2024 07:41:45 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> In NMT, both `ThreadCritical` and `Tracker` objects are used to do synchronizations. `Tracker` class uses `ThreadCritical` internally and used only for uncommit and release memory operations.  In this change, `Tracker` class is replaced with explicit use of `ThreadCritical` to be the same as the other instances of sync'ing NMT operations.
> 
> tiers1-5 tests passed.

I'm fine with this being merged either way, @afshin-zafari

-------------

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18000#pullrequestreview-1908402814

From aph at openjdk.org  Thu Feb 29 09:51:02 2024
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 29 Feb 2024 09:51:02 GMT
Subject: RFR: JDK-8326974: ODR violation in macroAssembler_aarch64.cpp
Message-ID: <hOE6eK57BszOCaKAhIyFwGpSQIwA7aCHhsPHkFZ4iSQ=.1b6e9ff1-0c2c-4b1a-87ef-d52d61632649@github.com>

This is a slightly different patch from the one suggested by the bug reporter. It doesn't make any sense to export those classes globally, so I've given them internal linkage.

-------------

Commit messages:
 - JDK-8326974: ODR violation in macroAssembler_aarch64.cpp

Changes: https://git.openjdk.org/jdk/pull/18056/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18056&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8326974
  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18056.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18056/head:pull/18056

PR: https://git.openjdk.org/jdk/pull/18056

From adinn at openjdk.org  Thu Feb 29 10:25:42 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 29 Feb 2024 10:25:42 GMT
Subject: RFR: JDK-8326974: ODR violation in macroAssembler_aarch64.cpp
In-Reply-To: <hOE6eK57BszOCaKAhIyFwGpSQIwA7aCHhsPHkFZ4iSQ=.1b6e9ff1-0c2c-4b1a-87ef-d52d61632649@github.com>
References: <hOE6eK57BszOCaKAhIyFwGpSQIwA7aCHhsPHkFZ4iSQ=.1b6e9ff1-0c2c-4b1a-87ef-d52d61632649@github.com>
Message-ID: <KH3AGaPIk-xuHrEIywN7Qh6L-qBqOPFiWWIFUjjXamw=.07181ad2-d0ef-452f-95a5-2c4e6042498e@github.com>

On Thu, 29 Feb 2024 09:47:11 GMT, Andrew Haley <aph at openjdk.org> wrote:

> This is a slightly different patch from the one suggested by the bug reporter. It doesn't make any sense to export those classes globally, so I've given them internal linkage.

Looks good.

-------------

Marked as reviewed by adinn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18056#pullrequestreview-1908504788

From luhenry at openjdk.org  Thu Feb 29 11:56:46 2024
From: luhenry at openjdk.org (Ludovic Henry)
Date: Thu, 29 Feb 2024 11:56:46 GMT
Subject: RFR: 8320646: RISC-V: C2 VectorCastHF2F [v3]
In-Reply-To: <PVlTLryK6cYu387i2EZ5wu-3ojkPSj4r1Fzqk1zBfc4=.9395a587-348f-472a-a2d6-1434f4b10060@github.com>
References: <kqLQR-bD3v7iF7LgH0PzwIH_m6QH_2b371pKz9_Ovq8=.9c07c165-2a97-4a6b-9e82-6a6de0b81328@github.com>
 <PVlTLryK6cYu387i2EZ5wu-3ojkPSj4r1Fzqk1zBfc4=.9395a587-348f-472a-a2d6-1434f4b10060@github.com>
Message-ID: <KDJMdML9tvQ-wzscVHjcR1G_blV1eaxJUN68tEbTUog=.240cb548-c336-4573-8b6f-2e59efec6bc4@github.com>

On Wed, 28 Feb 2024 14:19:06 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you review this patch to add instrinsics for VectorCastHF2F/VectorCastF2HF?
>> Thanks!
>> 
>> ## Test
>> 
>> test/jdk/java/lang/Float/Binary16ConversionNaN.java
>> test/jdk/java/lang/Float/Binary16Conversion.java
>> 
>> hotspot/jtreg/compiler/intrinsics/float16
>> hotspot/jtreg/compiler/vectorization/TestFloatConversionsVectorjava
>> hotspot/jtreg/compiler/vectorization/TestFloatConversionsVectorNaN.java
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make UseZvfh experimatal; clean code

Marked as reviewed by luhenry (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17698#pullrequestreview-1908675942

From epeter at openjdk.org  Thu Feb 29 11:56:46 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 29 Feb 2024 11:56:46 GMT
Subject: RFR: 8325095: C2: bailout message broken: ResourceArea allocated
 string used after free
In-Reply-To: <5jZ1LNpPWlxMQ-P4d0XEqi320KzRmvlxc5lWLvUae_E=.ef584842-4d46-4292-8954-2650b777a55a@github.com>
References: <8Bl6JSxb-fd1xAsKOMzBakRFuruoqJykP7JEn57k6qY=.717f89af-2aa7-439b-afd1-768dd39f51da@github.com>
 <5jZ1LNpPWlxMQ-P4d0XEqi320KzRmvlxc5lWLvUae_E=.ef584842-4d46-4292-8954-2650b777a55a@github.com>
Message-ID: <RM4orfctba_mGFQc57w14bD9YoKZ8DqN18gKwPv0Cw8=.21f5e434-f8aa-4c99-ba55-ea73ae0b5508@github.com>

On Thu, 15 Feb 2024 08:05:43 GMT, Dean Long <dlong at openjdk.org> wrote:

>> **Problem**
>> Bailout `failure_reason` strings used to be either `nullptr` or a static string. But with [JDK-8303951](https://bugs.openjdk.org/browse/JDK-8303951) I had introduced dynamic strings (e.g. formatted using `stringStream::as_string()`). These dynamic strings were ResourceArea allocated, and have a very limited life-span, i.e. withing the most recent ResourceMark scope. The pointer is passed to `Compile::_failure_reason`, which already might leave that ResourceMark scope, and the pointer is invalid. And then the pointer is further passed to `ciEnv::_failure_reason`. And finally, it even gets passed up to `CompileBroker::invoke_compiler_on_method`. When the string is finally printed for the bailout message, we already left original `ResourceMark` scope, and also the `Compile` and `ciEnv` scopes. The pointer now points to basically random data.
>> 
>> **Solution**
>> Whenever a string is passed to an outer scope, I make a CHeap copy, and the outer scope is the owner of that copy.
>> This way every scope is the owner of its own copy, and can allocate and deallocate according to its own strategy safely.
>> 
>> I introduced a utility class `CHeapStringHolder`:
>>  - `set`: make local copy on CHeap.
>>  - `clear`: free local copy. We before `set`, and in the destructor. Thus, when the holder goes out of scope, the memory is automatically freed.
>> 
>> We have these 4 scopes:
>> - `ResourceMark`: It allocates from `ResourcArea`, and deallocation is taken care at the end of the ResourceMark scope.
>> - `Compile`: We turn the `_failure_reason` from a `char*` into a `CHeapStringHolder`. We set `_failure_reason` while the `ResourceMark` is live.
>> - `ciEnv`: We turn the `_failure_reason` from a `char*` into a `CHeapStringHolder`. We set `_failure_reason` while `Compile` is live.
>> - `CompileTask`: We used to just set `failure_reason`, which assumes that the string is static or elsewhere managed. Now I use pattern available in other places of `CompileBroker::invoke_compiler_on_method`: duplicate the string with `os::strdup` from some other scope, and set `reason_on_C_heap = true`, which means that we are the owner of that copy, and are responsible for freeing it later. Not sure if that is a nice pattern, but I don't want to refactor that code and it does what I need it to do.
>
> Back when I filed JDK-8132354, I proposed that both C1 and C2 delegate to ciEnv.  Now there is a 3rd layer/scope of error reporting.  I don't think the solution needs to be so complicated.  Even with the new formatted strings, the maximum possible length can be determined (I don't see it using klass or method names).  So why can't the storage simply be `char[MAX_COMPILER_ERROR_LEN]` in `CompilerThread`, and setting it be a `strncpy`?

@dean-long @tstuefe @dholmes-ora can anybody give me a second review, please?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17710#issuecomment-1970979150

From luhenry at openjdk.org  Thu Feb 29 11:56:46 2024
From: luhenry at openjdk.org (Ludovic Henry)
Date: Thu, 29 Feb 2024 11:56:46 GMT
Subject: RFR: 8320646: RISC-V: C2 VectorCastHF2F [v2]
In-Reply-To: <fpYpk80yED5ih-DGMKoFBw_30nbYqzUczIlTDE3jSPs=.35876df6-67a1-4a62-b156-8ba20b4f2124@github.com>
References: <kqLQR-bD3v7iF7LgH0PzwIH_m6QH_2b371pKz9_Ovq8=.9c07c165-2a97-4a6b-9e82-6a6de0b81328@github.com>
 <fTvkUqcIsICvOIRWhqcICR8OYfaiOsOgSoaJsgUUm94=.09bb33c2-ce00-4943-bed0-0a1906395ee4@github.com>
 <k_9SAB2dNMVxzI5kc2Hd_7Nou8CvA998lE1WJTkphhY=.3f85f4e9-5a40-40be-9c6d-4db89a42c182@github.com>
 <ZwaoSyFg4BXYEZlZHnJ1rx6vdt8xAWzV4XQXRDriR5U=.47567d13-6df9-452c-baac-d376c1830df0@github.com>
 <8OQQo7cqVshZlOmFeWCLp_VrD3rizjsPDU4a1kGxokc=.75d8279c-ae2f-42fc-89e7-ccebb826e142@github.com>
 <fpYpk80yED5ih-DGMKoFBw_30nbYqzUczIlTDE3jSPs=.35876df6-67a1-4a62-b156-8ba20b4f2124@github.com>
Message-ID: <ql0XQZM83wvmmpDf25gFSbDabU3cRbQEQQxrgqdznuA=.05705f80-59ed-40e2-84c6-e40c28b19669@github.com>

On Wed, 28 Feb 2024 14:19:26 GMT, Hamlin Li <mli at openjdk.org> wrote:

>>> We still want to give end users the ability to disable extensions if things are broken. The flags would be the only way if we rely on hwprobe + vendor specific flags (like 
>> 
>> That make sense to me. In the long run, we should depend on hwprobe + vendor specific code to auto-enable or disable certain RV extensions on certain hardwares. But I agree on that there should be some options of `DIAGNOSTIC` kind to help diagnose issues and find workarounds. I am OK to make this option an `EXPERIMENTAL` one at the current stage. But we should turn them into the `DIAGNOSTIC` kind in the future when we have the hardwares and hwprobe is capable to satisfy our needs. Mind you, we are lacking one option for https://github.com/openjdk/jdk/pull/17122 in that respect. Let me know if you going to add one.
>> 
>>> https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp#L232-L260, and which I'm surprised not more hw vendors have added their own)
>> 
>> That will depend on the vendors. Given that the current RV hardwares are not that rich in RV extensions, I guess there isn't much to tune.
>
> Thanks for comments and discussion, made UseZvfh experimental.

> That make sense to me. In the long run, we should depend on hwprobe + vendor specific code to auto-enable or disable certain RV extensions on certain hardwares. But I agree on that there should be some options of DIAGNOSTIC kind to help diagnose issues and find workarounds. I am OK to make this option an EXPERIMENTAL one at the current stage. But we should turn them into the DIAGNOSTIC kind in the future when we have the hardwares and hwprobe is capable to satisfy our needs. Mind you, we are lacking one option for https://github.com/openjdk/jdk/pull/17122 in that respect. Let me know if you going to add one.

Agreed on all of that! The lack of currently and widely available hardware with more of these extensions is what makes me want to keep them EXPERIMENTAL. But once we validated that these work on commercially available hardware, I would indeed move them out of EXPERIMENTAL, and I agree DIAGNOSTIC makes for a fine change.

Another question will be about backporting the EXPERIMENTAL -> DIAGNOSTIC. We can revisit later but I think we should be fairly proactive about that when the case arises. Do you see any issues that may come from it? Possibly we expect that's a breaking change as users would need to switch from `-XX:+UseExperimentalFeatures` to `-XX:+UseDiagnosticsFeatures`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17698#discussion_r1507456025

From jwaters at openjdk.org  Thu Feb 29 13:20:53 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 29 Feb 2024 13:20:53 GMT
Subject: RFR: JDK-8326974: ODR violation in macroAssembler_aarch64.cpp
In-Reply-To: <hOE6eK57BszOCaKAhIyFwGpSQIwA7aCHhsPHkFZ4iSQ=.1b6e9ff1-0c2c-4b1a-87ef-d52d61632649@github.com>
References: <hOE6eK57BszOCaKAhIyFwGpSQIwA7aCHhsPHkFZ4iSQ=.1b6e9ff1-0c2c-4b1a-87ef-d52d61632649@github.com>
Message-ID: <yOtBmjCLtzsAj5alVD-4CU7AfjGRkTpPo_RxGFJEfNo=.32afd17f-4d7a-4e66-87e0-368184d30294@github.com>

On Thu, 29 Feb 2024 09:47:11 GMT, Andrew Haley <aph at openjdk.org> wrote:

> This is a slightly different patch from the one suggested by the bug reporter. It doesn't make any sense to export those classes globally, so I've given them internal linkage.

Looks like this is causing Actions failures

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18056#issuecomment-1971120357

From shade at openjdk.org  Thu Feb 29 13:27:42 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 29 Feb 2024 13:27:42 GMT
Subject: RFR: JDK-8326974: ODR violation in macroAssembler_aarch64.cpp
In-Reply-To: <hOE6eK57BszOCaKAhIyFwGpSQIwA7aCHhsPHkFZ4iSQ=.1b6e9ff1-0c2c-4b1a-87ef-d52d61632649@github.com>
References: <hOE6eK57BszOCaKAhIyFwGpSQIwA7aCHhsPHkFZ4iSQ=.1b6e9ff1-0c2c-4b1a-87ef-d52d61632649@github.com>
Message-ID: <750f3_7W0J6J2z0XbgDhrGgOxOrUtWkVr4Clqg_L2yM=.a298711c-02cc-4998-8da0-97e012549e5d@github.com>

On Thu, 29 Feb 2024 09:47:11 GMT, Andrew Haley <aph at openjdk.org> wrote:

> This is a slightly different patch from the one suggested by the bug reporter. It doesn't make any sense to export those classes globally, so I've given them internal linkage.

I think the patch suggested in bug was better, and in line with [Hotspot Style Guide](https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md), which says: "Global names must be unique, to avoid [One Definition Rule](https://en.cppreference.com/w/cpp/language/definition) (ODR) violations. A common prefixing scheme for related global names is often used. (This is instead of using namespaces, which are mostly avoided in HotSpot.)"

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18056#issuecomment-1971133442

From ihse at openjdk.org  Thu Feb 29 13:28:15 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 29 Feb 2024 13:28:15 GMT
Subject: RFR: 8327049: Stop exporting debug.cpp functions on gcc
Message-ID: <Vrz-4Zrwml7-Zi1fE-1LL6iCOfEsnDIP7QWMxEIcPCg=.7da5ee48-3eaa-492f-bd94-e01edbea1590@github.com>

This is a partial backout of [JDK-8326509](https://bugs.openjdk.org/browse/JDK-8326509). It turned out that starting to export the functions from debug.cpp could have unintended consequences in certain circumstances, so revert back to the original situation where these functions were only exported on Windows.

-------------

Commit messages:
 - 8327049: Stop exporting debug.cpp functions on gcc

Changes: https://git.openjdk.org/jdk/pull/18062/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18062&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327049
  Stats: 37 lines in 1 file changed: 7 ins; 0 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/18062.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18062/head:pull/18062

PR: https://git.openjdk.org/jdk/pull/18062

From kbarrett at openjdk.org  Thu Feb 29 13:33:52 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 29 Feb 2024 13:33:52 GMT
Subject: RFR: JDK-8326974: ODR violation in macroAssembler_aarch64.cpp
In-Reply-To: <750f3_7W0J6J2z0XbgDhrGgOxOrUtWkVr4Clqg_L2yM=.a298711c-02cc-4998-8da0-97e012549e5d@github.com>
References: <hOE6eK57BszOCaKAhIyFwGpSQIwA7aCHhsPHkFZ4iSQ=.1b6e9ff1-0c2c-4b1a-87ef-d52d61632649@github.com>
 <750f3_7W0J6J2z0XbgDhrGgOxOrUtWkVr4Clqg_L2yM=.a298711c-02cc-4998-8da0-97e012549e5d@github.com>
Message-ID: <qAGWPG6GHm9D5_vX6M3oYacyJ29tLGVSVZu5DIYt968=.878b2058-7cba-4e5c-b799-bc133ec34475@github.com>

On Thu, 29 Feb 2024 13:25:20 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I think the patch suggested in bug was better, and in line with [Hotspot Style Guide](https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md), which says: "Global names must be unique, to avoid [One Definition Rule](https://en.cppreference.com/w/cpp/language/definition) (ODR) violations. A common prefixing scheme for related global names is often used. (This is instead of using namespaces, which are mostly avoided in HotSpot.)"

See also the section "Namespaces", and in particular the specific admonition against using anonymous namespaces.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18056#issuecomment-1971139662

From adinn at openjdk.org  Thu Feb 29 13:33:52 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 29 Feb 2024 13:33:52 GMT
Subject: RFR: JDK-8326974: ODR violation in macroAssembler_aarch64.cpp
In-Reply-To: <hOE6eK57BszOCaKAhIyFwGpSQIwA7aCHhsPHkFZ4iSQ=.1b6e9ff1-0c2c-4b1a-87ef-d52d61632649@github.com>
References: <hOE6eK57BszOCaKAhIyFwGpSQIwA7aCHhsPHkFZ4iSQ=.1b6e9ff1-0c2c-4b1a-87ef-d52d61632649@github.com>
Message-ID: <4gJHZaAYhzW-RmhY-sZR9M2RObjJouizJB6xz0Mv2-U=.cafff03a-7dca-4f1a-8de5-ab6355b426a2@github.com>

On Thu, 29 Feb 2024 09:47:11 GMT, Andrew Haley <aph at openjdk.org> wrote:

> This is a slightly different patch from the one suggested by the bug reporter. It doesn't make any sense to export those classes globally, so I've given them internal linkage.

Egad! the action failure messages on Windows include this:

Linking jvm.dll
jvm.exp : error LNK2001: unresolved external symbol "const `anonymous namespace'::Decoder::`vftable'" (??_7Decoder@?A0xe77b3496@@6B@)
jvm.exp : error LNK2001: unresolved external symbol "const `anonymous namespace'::Patcher::`vftable'" (??_7Patcher@?A0xe77b3496@@6B@)

So, clearly something in the guts of the (Windows) build does not like anonymous name spaces.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18056#issuecomment-1971152071

From jwaters at openjdk.org  Thu Feb 29 13:34:52 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 29 Feb 2024 13:34:52 GMT
Subject: RFR: 8327049: Stop exporting debug.cpp functions on gcc
In-Reply-To: <Vrz-4Zrwml7-Zi1fE-1LL6iCOfEsnDIP7QWMxEIcPCg=.7da5ee48-3eaa-492f-bd94-e01edbea1590@github.com>
References: <Vrz-4Zrwml7-Zi1fE-1LL6iCOfEsnDIP7QWMxEIcPCg=.7da5ee48-3eaa-492f-bd94-e01edbea1590@github.com>
Message-ID: <ZkQguxeJ_ZIYzdZx0HuMai-pe0Y7NTU2gxnN9O4Hx90=.12b551fe-b60e-4dbb-86f5-d8e3f0214175@github.com>

On Thu, 29 Feb 2024 12:50:33 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a partial backout of [JDK-8326509](https://bugs.openjdk.org/browse/JDK-8326509). It turned out that starting to export the functions from debug.cpp could have unintended consequences in certain circumstances, so revert back to the original situation where these functions were only exported on Windows.

Wouldn't it be better to do WINDOWS_ONLY(JNIEXPORT) instead? Other than that, +1

-------------

Marked as reviewed by jwaters (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18062#pullrequestreview-1908892931

From ihse at openjdk.org  Thu Feb 29 13:55:56 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 29 Feb 2024 13:55:56 GMT
Subject: RFR: 8327049: Stop exporting debug.cpp functions on gcc [v2]
In-Reply-To: <Vrz-4Zrwml7-Zi1fE-1LL6iCOfEsnDIP7QWMxEIcPCg=.7da5ee48-3eaa-492f-bd94-e01edbea1590@github.com>
References: <Vrz-4Zrwml7-Zi1fE-1LL6iCOfEsnDIP7QWMxEIcPCg=.7da5ee48-3eaa-492f-bd94-e01edbea1590@github.com>
Message-ID: <feq8nt9mktvqVqYjsupRUBWE8MZnaqhthxAd_gNnU_Q=.c0e9e9ad-7ff6-4893-9f57-3b096aca48dd@github.com>

> This is a partial backout of [JDK-8326509](https://bugs.openjdk.org/browse/JDK-8326509). It turned out that starting to export the functions from debug.cpp could have unintended consequences in certain circumstances, so revert back to the original situation where these functions were only exported on Windows.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Use WINDOWS_ONLY instead

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18062/files
  - new: https://git.openjdk.org/jdk/pull/18062/files/04cacdfa..3323265e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18062&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18062&range=00-01

  Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18062.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18062/head:pull/18062

PR: https://git.openjdk.org/jdk/pull/18062

From ihse at openjdk.org  Thu Feb 29 13:55:56 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 29 Feb 2024 13:55:56 GMT
Subject: RFR: 8327049: Stop exporting debug.cpp functions on gcc
In-Reply-To: <Vrz-4Zrwml7-Zi1fE-1LL6iCOfEsnDIP7QWMxEIcPCg=.7da5ee48-3eaa-492f-bd94-e01edbea1590@github.com>
References: <Vrz-4Zrwml7-Zi1fE-1LL6iCOfEsnDIP7QWMxEIcPCg=.7da5ee48-3eaa-492f-bd94-e01edbea1590@github.com>
Message-ID: <PgQCSZEhYsqwVBrwvqbK9QLvOrdj6wG3Wd8oo79JlT8=.ee4ac714-ebd8-467c-8840-8549d1fcd21f@github.com>

On Thu, 29 Feb 2024 12:50:33 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a partial backout of [JDK-8326509](https://bugs.openjdk.org/browse/JDK-8326509). It turned out that starting to export the functions from debug.cpp could have unintended consequences in certain circumstances, so revert back to the original situation where these functions were only exported on Windows.

I guess that is mostly a matter of style, but sure, it is a bit shorter. And coming from you, I assume it is more relevant wrt a non-Microsoft-toolchain Windows port.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18062#issuecomment-1971193501

From jwaters at openjdk.org  Thu Feb 29 13:58:53 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 29 Feb 2024 13:58:53 GMT
Subject: RFR: 8327049: Stop exporting debug.cpp functions on gcc [v2]
In-Reply-To: <feq8nt9mktvqVqYjsupRUBWE8MZnaqhthxAd_gNnU_Q=.c0e9e9ad-7ff6-4893-9f57-3b096aca48dd@github.com>
References: <Vrz-4Zrwml7-Zi1fE-1LL6iCOfEsnDIP7QWMxEIcPCg=.7da5ee48-3eaa-492f-bd94-e01edbea1590@github.com>
 <feq8nt9mktvqVqYjsupRUBWE8MZnaqhthxAd_gNnU_Q=.c0e9e9ad-7ff6-4893-9f57-3b096aca48dd@github.com>
Message-ID: <n_ZI1CmdQ0lDBDscANOxL2juHEP457d2TFmbybKSFgk=.f1a988c1-48b1-4d7c-8e10-8840418e0d19@github.com>

On Thu, 29 Feb 2024 13:55:56 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is a partial backout of [JDK-8326509](https://bugs.openjdk.org/browse/JDK-8326509). It turned out that starting to export the functions from debug.cpp could have unintended consequences in certain circumstances, so revert back to the original situation where these functions were only exported on Windows.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use WINDOWS_ONLY instead

Marked as reviewed by jwaters (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/18062#pullrequestreview-1908956527

From jwaters at openjdk.org  Thu Feb 29 13:58:53 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 29 Feb 2024 13:58:53 GMT
Subject: RFR: 8327049: Stop exporting debug.cpp functions on gcc
In-Reply-To: <PgQCSZEhYsqwVBrwvqbK9QLvOrdj6wG3Wd8oo79JlT8=.ee4ac714-ebd8-467c-8840-8549d1fcd21f@github.com>
References: <Vrz-4Zrwml7-Zi1fE-1LL6iCOfEsnDIP7QWMxEIcPCg=.7da5ee48-3eaa-492f-bd94-e01edbea1590@github.com>
 <PgQCSZEhYsqwVBrwvqbK9QLvOrdj6wG3Wd8oo79JlT8=.ee4ac714-ebd8-467c-8840-8549d1fcd21f@github.com>
Message-ID: <7QwaE75rHnZOREvzg2hZdreihTHzei9oKKK4yyLkY2w=.f8721447-c010-408e-8a16-3ad30a8ba306@github.com>

On Thu, 29 Feb 2024 13:53:29 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I guess that is mostly a matter of style, but sure, it is a bit shorter. And coming from you, I assume it is more relevant wrt a non-Microsoft-toolchain Windows port.

Not at all, was just trying to help out since there are utility macros in HotSpot that make this sort of thing less cumbersome :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18062#issuecomment-1971198037

From sroy at openjdk.org  Thu Feb 29 14:11:01 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Thu, 29 Feb 2024 14:11:01 GMT
Subject: RFR: JDK-8324682 Remove redefinition of NULL for XLC compiler
Message-ID: <ZPDrB-7TnAKvaUN29joo9ui9s8CP-XtAKdbSy4v20TE=.62d3e34b-a26c-44af-ad72-aa5a3dea4c6a@github.com>

Remove redefinition of NULL for XLC compiler

JBS ISSUE : [JDK-8324682](https://bugs.openjdk.org/browse/JDK-8324682)

-------------

Commit messages:
 - Redefine NULL word
 - Remove NULL definition

Changes: https://git.openjdk.org/jdk/pull/18064/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18064&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8324682
  Stats: 17 lines in 3 files changed: 0 ins; 14 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/18064.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18064/head:pull/18064

PR: https://git.openjdk.org/jdk/pull/18064

From sroy at openjdk.org  Thu Feb 29 14:45:05 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Thu, 29 Feb 2024 14:45:05 GMT
Subject: RFR: JDK-8324682 Remove redefinition of NULL for XLC compiler [v2]
In-Reply-To: <ZPDrB-7TnAKvaUN29joo9ui9s8CP-XtAKdbSy4v20TE=.62d3e34b-a26c-44af-ad72-aa5a3dea4c6a@github.com>
References: <ZPDrB-7TnAKvaUN29joo9ui9s8CP-XtAKdbSy4v20TE=.62d3e34b-a26c-44af-ad72-aa5a3dea4c6a@github.com>
Message-ID: <IfvjNen8nbFZYQSG4N1nCv2aw5jjoaC1P2YH34zSkmA=.ed61bbc6-483f-47c7-bd29-8b6315763965@github.com>

> Remove redefinition of NULL for XLC compiler
> 
> JBS ISSUE : [JDK-8324682](https://bugs.openjdk.org/browse/JDK-8324682)

Suchismith Roy has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  Redefine NULL word

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18064/files
  - new: https://git.openjdk.org/jdk/pull/18064/files/630144ce..eb8faf93

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18064&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18064&range=00-01

  Stats: 226 lines in 1 file changed: 0 ins; 226 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18064.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18064/head:pull/18064

PR: https://git.openjdk.org/jdk/pull/18064

From ddong at openjdk.org  Thu Feb 29 15:06:05 2024
From: ddong at openjdk.org (Denghui Dong)
Date: Thu, 29 Feb 2024 15:06:05 GMT
Subject: RFR: 8327056: Remove unused static char array in
 JvmtiAgentList::lookup
Message-ID: <aGnUAnm3uCvjx1Gajsx76Vj2TLX6nVuS79OKcjuivZs=.66deb056-6ac9-4e0c-8cdb-2ca36e768963@github.com>

Hi,

Please help review this trivial change that removed an unused static char array in JvmtiAgentList::lookup.

Thanks

-------------

Commit messages:
 - 8327056: Remove unused static char array in JvmtiAgentList::lookup

Changes: https://git.openjdk.org/jdk/pull/18066/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18066&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327056
  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18066.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18066/head:pull/18066

PR: https://git.openjdk.org/jdk/pull/18066

From mli at openjdk.org  Thu Feb 29 15:16:55 2024
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 29 Feb 2024 15:16:55 GMT
Subject: RFR: 8320646: RISC-V: C2 VectorCastHF2F [v2]
In-Reply-To: <ql0XQZM83wvmmpDf25gFSbDabU3cRbQEQQxrgqdznuA=.05705f80-59ed-40e2-84c6-e40c28b19669@github.com>
References: <kqLQR-bD3v7iF7LgH0PzwIH_m6QH_2b371pKz9_Ovq8=.9c07c165-2a97-4a6b-9e82-6a6de0b81328@github.com>
 <fTvkUqcIsICvOIRWhqcICR8OYfaiOsOgSoaJsgUUm94=.09bb33c2-ce00-4943-bed0-0a1906395ee4@github.com>
 <k_9SAB2dNMVxzI5kc2Hd_7Nou8CvA998lE1WJTkphhY=.3f85f4e9-5a40-40be-9c6d-4db89a42c182@github.com>
 <ZwaoSyFg4BXYEZlZHnJ1rx6vdt8xAWzV4XQXRDriR5U=.47567d13-6df9-452c-baac-d376c1830df0@github.com>
 <8OQQo7cqVshZlOmFeWCLp_VrD3rizjsPDU4a1kGxokc=.75d8279c-ae2f-42fc-89e7-ccebb826e142@github.com>
 <fpYpk80yED5ih-DGMKoFBw_30nbYqzUczIlTDE3jSPs=.35876df6-67a1-4a62-b156-8ba20b4f2124@github.com>
 <ql0XQZM83wvmmpDf25gFSbDabU3cRbQEQQxrgqdznuA=.05705f80-59ed-40e2-84c6-e40c28b19669@github.com>
Message-ID: <kAzK7W_fbXd6w-SSvQ_0l-m4P68i94uGU2fHPY2h4FE=.87bc1819-5b5f-48bb-8ca6-87f8522d952f@github.com>

On Thu, 29 Feb 2024 11:53:20 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

> Mind you, we are lacking one option for https://github.com/openjdk/jdk/pull/17122 in that respect. Let me know if you going to add one.

@RealFYang I can do that. FYI, tested on lichipi and VF2, seems both does not support Zcb yet, tracked by https://bugs.openjdk.org/browse/JDK-8327058

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17698#discussion_r1507747553

From aph at openjdk.org  Thu Feb 29 15:43:43 2024
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 29 Feb 2024 15:43:43 GMT
Subject: RFR: JDK-8326974: ODR violation in macroAssembler_aarch64.cpp
In-Reply-To: <qAGWPG6GHm9D5_vX6M3oYacyJ29tLGVSVZu5DIYt968=.878b2058-7cba-4e5c-b799-bc133ec34475@github.com>
References: <hOE6eK57BszOCaKAhIyFwGpSQIwA7aCHhsPHkFZ4iSQ=.1b6e9ff1-0c2c-4b1a-87ef-d52d61632649@github.com>
 <750f3_7W0J6J2z0XbgDhrGgOxOrUtWkVr4Clqg_L2yM=.a298711c-02cc-4998-8da0-97e012549e5d@github.com>
 <qAGWPG6GHm9D5_vX6M3oYacyJ29tLGVSVZu5DIYt968=.878b2058-7cba-4e5c-b799-bc133ec34475@github.com>
Message-ID: <StSGYkIfzRsEtb3cmpuycK2LBKHtQdi87l--r9tV_1w=.53a5052c-f0d2-4590-90d0-370a71162bbf@github.com>

On Thu, 29 Feb 2024 13:27:59 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> > I think the patch suggested in bug was better, and in line with [Hotspot Style Guide](https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md), which says: "Global names must be unique, to avoid [One Definition Rule](https://en.cppreference.com/w/cpp/language/definition) (ODR) violations. A common prefixing scheme for related global names is often used. (This is instead of using namespaces, which are mostly avoided in HotSpot.)"
> 
> See also the section "Namespaces", and in particular the specific admonition against using anonymous namespaces.

Mmm, that's a shame. It seems to me that an anonymous namespace is best here, given that the classes should not be visible outside this translation unit, but implementation bugs in debuggers and linkers are a show stopper.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18056#issuecomment-1971410464

From aph at openjdk.org  Thu Feb 29 16:04:03 2024
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 29 Feb 2024 16:04:03 GMT
Subject: RFR: JDK-8326974: ODR violation in macroAssembler_aarch64.cpp [v2]
In-Reply-To: <hOE6eK57BszOCaKAhIyFwGpSQIwA7aCHhsPHkFZ4iSQ=.1b6e9ff1-0c2c-4b1a-87ef-d52d61632649@github.com>
References: <hOE6eK57BszOCaKAhIyFwGpSQIwA7aCHhsPHkFZ4iSQ=.1b6e9ff1-0c2c-4b1a-87ef-d52d61632649@github.com>
Message-ID: <AYW0ESsZyA8B67HpwrDW6hgboWwpfGNkvITM0ZwC9F4=.1d28e387-a2dc-4c23-9332-12d30ecb2fda@github.com>

> This is a slightly different patch from the one suggested by the bug reporter. It doesn't make any sense to export those classes globally, so I've given them internal linkage.

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8326974: ODR violation in macroAssembler_aarch64.cpp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18056/files
  - new: https://git.openjdk.org/jdk/pull/18056/files/a3fc57b5..7f38d070

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18056&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18056&range=00-01

  Stats: 8 lines in 1 file changed: 0 ins; 2 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/18056.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18056/head:pull/18056

PR: https://git.openjdk.org/jdk/pull/18056

From shade at openjdk.org  Thu Feb 29 17:00:53 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 29 Feb 2024 17:00:53 GMT
Subject: RFR: JDK-8326974: ODR violation in macroAssembler_aarch64.cpp [v2]
In-Reply-To: <AYW0ESsZyA8B67HpwrDW6hgboWwpfGNkvITM0ZwC9F4=.1d28e387-a2dc-4c23-9332-12d30ecb2fda@github.com>
References: <hOE6eK57BszOCaKAhIyFwGpSQIwA7aCHhsPHkFZ4iSQ=.1b6e9ff1-0c2c-4b1a-87ef-d52d61632649@github.com>
 <AYW0ESsZyA8B67HpwrDW6hgboWwpfGNkvITM0ZwC9F4=.1d28e387-a2dc-4c23-9332-12d30ecb2fda@github.com>
Message-ID: <IjHhJfcnOE0jbN1Hv9Wf4D0cPEGb7CRJ8IqwCgpgwQY=.2a20e202-8236-4997-94e1-b6691376d0f8@github.com>

On Thu, 29 Feb 2024 16:04:03 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This is a slightly different patch from the one suggested by the bug reporter. It doesn't make any sense to export those classes globally, so I've given them internal linkage.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8326974: ODR violation in macroAssembler_aarch64.cpp

Looks fine.

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 151:

> 149: //       110___10100 (i.e. requires insn[31:21] == 11010010100)
> 150: //
> 151: 

Is this newline addition necessary?

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18056#pullrequestreview-1909411315
PR Review Comment: https://git.openjdk.org/jdk/pull/18056#discussion_r1507901707

From adinn at openjdk.org  Thu Feb 29 17:09:53 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 29 Feb 2024 17:09:53 GMT
Subject: RFR: JDK-8326974: ODR violation in macroAssembler_aarch64.cpp [v2]
In-Reply-To: <AYW0ESsZyA8B67HpwrDW6hgboWwpfGNkvITM0ZwC9F4=.1d28e387-a2dc-4c23-9332-12d30ecb2fda@github.com>
References: <hOE6eK57BszOCaKAhIyFwGpSQIwA7aCHhsPHkFZ4iSQ=.1b6e9ff1-0c2c-4b1a-87ef-d52d61632649@github.com>
 <AYW0ESsZyA8B67HpwrDW6hgboWwpfGNkvITM0ZwC9F4=.1d28e387-a2dc-4c23-9332-12d30ecb2fda@github.com>
Message-ID: <iRpPVTmMxMOOh_-7akXJzdL_AFjin7hxgJnsV7v5Ok0=.6fb64815-b98d-4577-8c03-52c156470cef@github.com>

On Thu, 29 Feb 2024 16:04:03 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This is a slightly different patch from the one suggested by the bug reporter. It doesn't make any sense to export those classes globally, so I've given them internal linkage.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8326974: ODR violation in macroAssembler_aarch64.cpp

Also looks good. If the actions fail with this version then surely it has to be a case of "Houston we have a problem  . . . with the actions".

-------------

PR Review: https://git.openjdk.org/jdk/pull/18056#pullrequestreview-1909431552

From aph at openjdk.org  Thu Feb 29 17:16:04 2024
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 29 Feb 2024 17:16:04 GMT
Subject: RFR: JDK-8326974: ODR violation in macroAssembler_aarch64.cpp [v3]
In-Reply-To: <hOE6eK57BszOCaKAhIyFwGpSQIwA7aCHhsPHkFZ4iSQ=.1b6e9ff1-0c2c-4b1a-87ef-d52d61632649@github.com>
References: <hOE6eK57BszOCaKAhIyFwGpSQIwA7aCHhsPHkFZ4iSQ=.1b6e9ff1-0c2c-4b1a-87ef-d52d61632649@github.com>
Message-ID: <kDiemj7S7FYkBqW9uqSom6LLSUFSmUYR9dC9DCpRe_E=.0eaac40e-a6ac-4e16-8d81-4004088e58fd@github.com>

> This is a slightly different patch from the one suggested by the bug reporter. It doesn't make any sense to export those classes globally, so I've given them internal linkage.

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8326974: ODR violation in macroAssembler_aarch64.cpp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18056/files
  - new: https://git.openjdk.org/jdk/pull/18056/files/7f38d070..b326b902

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18056&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18056&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18056.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18056/head:pull/18056

PR: https://git.openjdk.org/jdk/pull/18056

From aph at openjdk.org  Thu Feb 29 17:16:05 2024
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 29 Feb 2024 17:16:05 GMT
Subject: RFR: JDK-8326974: ODR violation in macroAssembler_aarch64.cpp [v2]
In-Reply-To: <IjHhJfcnOE0jbN1Hv9Wf4D0cPEGb7CRJ8IqwCgpgwQY=.2a20e202-8236-4997-94e1-b6691376d0f8@github.com>
References: <hOE6eK57BszOCaKAhIyFwGpSQIwA7aCHhsPHkFZ4iSQ=.1b6e9ff1-0c2c-4b1a-87ef-d52d61632649@github.com>
 <AYW0ESsZyA8B67HpwrDW6hgboWwpfGNkvITM0ZwC9F4=.1d28e387-a2dc-4c23-9332-12d30ecb2fda@github.com>
 <IjHhJfcnOE0jbN1Hv9Wf4D0cPEGb7CRJ8IqwCgpgwQY=.2a20e202-8236-4997-94e1-b6691376d0f8@github.com>
Message-ID: <vl8aCBrnM-d5sqlLk7JaX1TeLPMBcv4Ihp-Fmm0kMDs=.1e6f6efa-8140-4f15-8425-2585abd1fdd0@github.com>

On Thu, 29 Feb 2024 16:57:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8326974: ODR violation in macroAssembler_aarch64.cpp
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 151:
> 
>> 149: //       110___10100 (i.e. requires insn[31:21] == 11010010100)
>> 150: //
>> 151: 
> 
> Is this newline addition necessary?

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18056#discussion_r1507922145

From mli at openjdk.org  Thu Feb 29 17:37:14 2024
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 29 Feb 2024 17:37:14 GMT
Subject: RFR: 8327058: RISC-V: make Zcb experimental
Message-ID: <-vwMZiS-BUC2ZR2u5eMlnC9lkEghpJebOJs8TNxik8Q=.851c72e9-34ac-4bb3-b0bc-c4421da7672e@github.com>

Hi,
Can you review the patch to add a flag for Zcb extension to enable user to control it?
Thanks.

As discussed in [1], it's good to give a flag to control Zcb, and currently it's good to make it experimental.

[1] https://github.com/openjdk/jdk/pull/17698#discussion_r1505364098

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/18070/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18070&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327058
  Stats: 3 lines in 3 files changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/18070.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18070/head:pull/18070

PR: https://git.openjdk.org/jdk/pull/18070

From amenkov at openjdk.org  Thu Feb 29 17:51:47 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 29 Feb 2024 17:51:47 GMT
Subject: RFR: 8327056: Remove unused static char array in
 JvmtiAgentList::lookup
In-Reply-To: <aGnUAnm3uCvjx1Gajsx76Vj2TLX6nVuS79OKcjuivZs=.66deb056-6ac9-4e0c-8cdb-2ca36e768963@github.com>
References: <aGnUAnm3uCvjx1Gajsx76Vj2TLX6nVuS79OKcjuivZs=.66deb056-6ac9-4e0c-8cdb-2ca36e768963@github.com>
Message-ID: <b-I8Pol-AfsKP_2Nj9WPAT8s53IIhHi5dhvRV2xC5dc=.d4c20e6c-63db-4495-a8ae-d993d1dc2483@github.com>

On Thu, 29 Feb 2024 15:02:02 GMT, Denghui Dong <ddong at openjdk.org> wrote:

> Hi,
> 
> Please help review this trivial change that removed an unused static char array in JvmtiAgentList::lookup.
> 
> Thanks

Marked as reviewed by amenkov (Reviewer).

Looks good and trivial

-------------

PR Review: https://git.openjdk.org/jdk/pull/18066#pullrequestreview-1909512768
PR Comment: https://git.openjdk.org/jdk/pull/18066#issuecomment-1971652795

From sspitsyn at openjdk.org  Thu Feb 29 17:59:51 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 29 Feb 2024 17:59:51 GMT
Subject: RFR: 8327056: Remove unused static char array in
 JvmtiAgentList::lookup
In-Reply-To: <aGnUAnm3uCvjx1Gajsx76Vj2TLX6nVuS79OKcjuivZs=.66deb056-6ac9-4e0c-8cdb-2ca36e768963@github.com>
References: <aGnUAnm3uCvjx1Gajsx76Vj2TLX6nVuS79OKcjuivZs=.66deb056-6ac9-4e0c-8cdb-2ca36e768963@github.com>
Message-ID: <ejc8qvMwVaUMidzFgdsmCdMYhkwWRjEw3zH-fEpC29U=.01377cd1-51c3-4bde-b955-dffe30c65fea@github.com>

On Thu, 29 Feb 2024 15:02:02 GMT, Denghui Dong <ddong at openjdk.org> wrote:

> Hi,
> 
> Please help review this trivial change that removed an unused static char array in JvmtiAgentList::lookup.
> 
> Thanks

Looks good and trivial.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18066#pullrequestreview-1909529185

From daniel.daugherty at oracle.com  Thu Feb 29 20:33:40 2024
From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com)
Date: Thu, 29 Feb 2024 15:33:40 -0500
Subject: =?UTF-8?Q?Re=3A_CFV=3A_New_HotSpot_Group_Member=3A_Johan_Sj=C3=B6l?=
 =?UTF-8?B?w6lu?=
In-Reply-To: <041D6781-CFE6-41BD-A8F5-7E25C2EFFD52@oracle.com>
References: <041D6781-CFE6-41BD-A8F5-7E25C2EFFD52@oracle.com>
Message-ID: <5912b332-45b0-446c-b0db-36b093506f72@oracle.com>

Vote: yes

Dan


On 2/22/24 7:14 AM, Jesper Wilhelmsson wrote:
> I hereby nominate Johan Sj?l?n (jsjolen) to Membership in the HotSpot Group.
>
> Johan is a Reviewer in the JDK project, and a member of the Oracle JVM Runtime team. Johan has done major work in the Unified Logging framework and is today the de facto owner of that area. He has done major cleanups and bug fixes throughout the JVM, and does a lot of work in the Native Memory Tracking area.
>
> Votes are due by Thursday March 7.
>
> Only current Members of the HotSpot Group [1] are eligible to vote on this nomination.  Votes must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [2].
>
> Thanks,
> /Jesper
>
> [1] https://openjdk.org/census
> [2] https://openjdk.org/groups/#member-vote


From dholmes at openjdk.org  Thu Feb 29 21:21:52 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 29 Feb 2024 21:21:52 GMT
Subject: RFR: 8327049: Stop exporting debug.cpp functions on gcc [v2]
In-Reply-To: <feq8nt9mktvqVqYjsupRUBWE8MZnaqhthxAd_gNnU_Q=.c0e9e9ad-7ff6-4893-9f57-3b096aca48dd@github.com>
References: <Vrz-4Zrwml7-Zi1fE-1LL6iCOfEsnDIP7QWMxEIcPCg=.7da5ee48-3eaa-492f-bd94-e01edbea1590@github.com>
 <feq8nt9mktvqVqYjsupRUBWE8MZnaqhthxAd_gNnU_Q=.c0e9e9ad-7ff6-4893-9f57-3b096aca48dd@github.com>
Message-ID: <uwlkOwJbDJtAKIrk4tVM-LdQ2ci_we77MDhWySTenmU=.56210510-1680-4777-9e3b-b241b5e4177f@github.com>

On Thu, 29 Feb 2024 13:55:56 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is a partial backout of [JDK-8326509](https://bugs.openjdk.org/browse/JDK-8326509). It turned out that starting to export the functions from debug.cpp could have unintended consequences in certain circumstances, so revert back to the original situation where these functions were only exported on Windows.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use WINDOWS_ONLY instead

I had expected to see an actual reversion to the undef of JNIEXPORT but this will do albeit more extensive a change.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18062#pullrequestreview-1909892167

From dholmes at openjdk.org  Thu Feb 29 21:32:51 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 29 Feb 2024 21:32:51 GMT
Subject: RFR: 8327049: Stop exporting debug.cpp functions on gcc [v2]
In-Reply-To: <feq8nt9mktvqVqYjsupRUBWE8MZnaqhthxAd_gNnU_Q=.c0e9e9ad-7ff6-4893-9f57-3b096aca48dd@github.com>
References: <Vrz-4Zrwml7-Zi1fE-1LL6iCOfEsnDIP7QWMxEIcPCg=.7da5ee48-3eaa-492f-bd94-e01edbea1590@github.com>
 <feq8nt9mktvqVqYjsupRUBWE8MZnaqhthxAd_gNnU_Q=.c0e9e9ad-7ff6-4893-9f57-3b096aca48dd@github.com>
Message-ID: <O7zx86GCX1WzohmfNPLNfst8_qND0t4FBxRE0OAy6Po=.626f41c1-983b-457a-b903-9acd279ca139@github.com>

On Thu, 29 Feb 2024 13:55:56 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is a partial backout of [JDK-8326509](https://bugs.openjdk.org/browse/JDK-8326509). It turned out that starting to export the functions from debug.cpp could have unintended consequences in certain circumstances, so revert back to the original situation where these functions were only exported on Windows.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use WINDOWS_ONLY instead

Actually what about non-Windows non-gcc? Shouldn't this only affect Linux?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18062#issuecomment-1971994810

From sviswanathan at openjdk.org  Thu Feb 29 21:42:53 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 29 Feb 2024 21:42:53 GMT
Subject: RFR: 8325991: Accelerate Poly1305 on x86_64 using AVX2
 instructions [v10]
In-Reply-To: <9_AS9fKLjyVQzybg1915BX3xVVFwJRKjsqghjZ99hr0=.13a55d69-fc86-4109-a3be-934d1b8634d0@github.com>
References: <IyoM1HY_rvNWwo4GxcV1yQleB3vrgaLwsAlOCEpLKqs=.1d50225c-8fe1-4a84-af56-274632b2b653@github.com>
 <9_AS9fKLjyVQzybg1915BX3xVVFwJRKjsqghjZ99hr0=.13a55d69-fc86-4109-a3be-934d1b8634d0@github.com>
Message-ID: <8ydLOdXg7gP8BVn7po0KBXFBvfTWhzKCR2wc2fy70Ac=.158e8bbe-cedf-4f29-9ad5-a89d032dc534@github.com>

On Tue, 27 Feb 2024 21:13:07 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> The goal of this PR is to accelerate the Poly1305 algorithm using AVX2 instructions (including IFMA) for x86_64 CPUs.
>> 
>> This implementation is directly based on the AVX2 Poly1305 hash computation as implemented in Intel(R) Multi-Buffer Crypto for IPsec Library (url: https://github.com/intel/intel-ipsec-mb/blob/main/lib/avx2_t3/poly_fma_avx2.asm)
>> 
>> This PR shows upto 19x speedup on buffer sizes of 1MB.
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update description of Poly1305 algo

@TobiHartmann @vnkozlov Could you please run this through your testing? Also if you have any feedback on the PR please let us know. We are hoping to integrate this by next week.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17881#issuecomment-1972008414

From dlong at openjdk.org  Thu Feb 29 23:20:52 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 29 Feb 2024 23:20:52 GMT
Subject: RFR: JDK-8326974: ODR violation in macroAssembler_aarch64.cpp [v3]
In-Reply-To: <kDiemj7S7FYkBqW9uqSom6LLSUFSmUYR9dC9DCpRe_E=.0eaac40e-a6ac-4e16-8d81-4004088e58fd@github.com>
References: <hOE6eK57BszOCaKAhIyFwGpSQIwA7aCHhsPHkFZ4iSQ=.1b6e9ff1-0c2c-4b1a-87ef-d52d61632649@github.com>
 <kDiemj7S7FYkBqW9uqSom6LLSUFSmUYR9dC9DCpRe_E=.0eaac40e-a6ac-4e16-8d81-4004088e58fd@github.com>
Message-ID: <wjqAo9awmas0PEzSH0_5kwCArpF7OBk_gGLocEWLeKw=.0a499d08-e634-427e-9800-b5ecbdf47950@github.com>

On Thu, 29 Feb 2024 17:16:04 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This is a slightly different patch from the one suggested by the bug reporter. It doesn't make any sense to export those classes globally, so I've given them internal linkage.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8326974: ODR violation in macroAssembler_aarch64.cpp

How about making Decoder into a nested class of MacroAssembler?  You just need a forward declaration in macroAssembler_aarch64.hpp.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18056#issuecomment-1972134435

From ddong at openjdk.org  Thu Feb 29 23:45:53 2024
From: ddong at openjdk.org (Denghui Dong)
Date: Thu, 29 Feb 2024 23:45:53 GMT
Subject: RFR: 8327056: Remove unused static char array in
 JvmtiAgentList::lookup
In-Reply-To: <aGnUAnm3uCvjx1Gajsx76Vj2TLX6nVuS79OKcjuivZs=.66deb056-6ac9-4e0c-8cdb-2ca36e768963@github.com>
References: <aGnUAnm3uCvjx1Gajsx76Vj2TLX6nVuS79OKcjuivZs=.66deb056-6ac9-4e0c-8cdb-2ca36e768963@github.com>
Message-ID: <YW_CSZA4ShxMTECMHaDuiPTak8tJdSEUGjHYe6rYFCM=.77c37dff-e705-4c9a-a5be-1fd4fdb9c393@github.com>

On Thu, 29 Feb 2024 15:02:02 GMT, Denghui Dong <ddong at openjdk.org> wrote:

> Hi,
> 
> Please help review this trivial change that removed an unused static char array in JvmtiAgentList::lookup.
> 
> Thanks

Thanks for the review. The GHA failure ([linux-cross-compile / build (riscv64)](https://github.com/D-D-H/jdk/actions/runs/8098012554/job/22132022050)) is not caused by the change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18066#issuecomment-1972158788

From ddong at openjdk.org  Thu Feb 29 23:49:46 2024
From: ddong at openjdk.org (Denghui Dong)
Date: Thu, 29 Feb 2024 23:49:46 GMT
Subject: Integrated: 8327056: Remove unused static char array in
 JvmtiAgentList::lookup
In-Reply-To: <aGnUAnm3uCvjx1Gajsx76Vj2TLX6nVuS79OKcjuivZs=.66deb056-6ac9-4e0c-8cdb-2ca36e768963@github.com>
References: <aGnUAnm3uCvjx1Gajsx76Vj2TLX6nVuS79OKcjuivZs=.66deb056-6ac9-4e0c-8cdb-2ca36e768963@github.com>
Message-ID: <Izd3rf79cO3jPjEQg9OduBkGeOE1AePTMjDmYKkK45c=.1ccd1afb-b0a0-4c44-a287-7fa783d35834@github.com>

On Thu, 29 Feb 2024 15:02:02 GMT, Denghui Dong <ddong at openjdk.org> wrote:

> Hi,
> 
> Please help review this trivial change that removed an unused static char array in JvmtiAgentList::lookup.
> 
> Thanks

This pull request has now been integrated.

Changeset: 8d6f7849
Author:    Denghui Dong <ddong at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8d6f7849ff870e87c088ba38c21a8207d6883a2f
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8327056: Remove unused static char array in JvmtiAgentList::lookup

Reviewed-by: amenkov, sspitsyn

-------------

PR: https://git.openjdk.org/jdk/pull/18066